20:57 <samueldr> not sure where else I can ask this, I have this allwinner (f1c100s) system, and a WIP branch rebasing assumed working DE stuff back onto 5.17

20:58 <samueldr> the panel is connected through the multiplexed pins, as RGB 565

20:58 <samueldr> I see the (dubious, and bad) vendor code configures the pins as GPIO to send commands to the panel

20:59 <samueldr> the panel commands *look* like DSI, but AFAICT there's no actual DSI involved

21:00 <samueldr> anyway, where can I find more information about *somehow* wrangling the pinctrl subsystems of Linux into providing me some form of GPIO access to the panel to configure it on panel init?

21:00 <samueldr> note that I'm not really experienced with DRM, panel, and pinctrl stuff

21:01 <samueldr> I have to assume (I know) that the panel is not already configured properly by the previous boot stage... which is U-Boot, so I am working under the assumption that `simple-panel` isn't useful here

21:01 <samueldr> s/simple-panel/panel-simple/

21:03 <samueldr> I'm also concerned about the fact that the panel configuration implementation would be allwinner-dependent, if not f1c100s-dependent

21:05 <smaeul> you're saying the panel uses the same pins for parallel RGB data and configuration commands?

21:06 <samueldr> yes

21:07 <samueldr> I don't have schematics of this particular device, but I have one from the device it's cloned from

21:07 <samueldr> been a while I looked at it, but IIRC there is nothing more connected to the panel

21:08 <samueldr> though I know for a fact the driver does switch gpios in gpio out, write configuration commands using the parallel interface, then flips it back to LCD

21:09 <samueldr> (I also have a bitbanged GPIO driver working, but it's obviously not ideal)

21:12 <smaeul> can you share the schematic you have?

21:13 <samueldr> another note, those schematics use another LCD module, but same principles; configured through GPIO commands, then flipped into LCD mode

21:15 <samueldr> https://github.com/steward-fu/miyoo/releases/download/v1.0/sch_v1.2.pdf

21:16 <samueldr> actual panel is st7789s

21:16 <samueldr> actual product is powkiddy v90

21:17 <samueldr> the vendor hasn't actually released sources, but there are source floating around which include vendor-flavoured drivers for it

21:19 <samueldr> oh, and also all of that is a personal learning experience

21:20 <smaeul> that looks like 8080 panel interface. the TCON has hardware support for driving it (see TCON0_CPU_IF_CTRL_REG/TCON0_CPU_WR_REG/TCON0_CPU_RD_REG)

21:20 <samueldr> 8080 is a term used in the ST7789S docs, so I assume you're right

21:21 <smaeul> if you do need to bitbang, then I assume you'd use pinctrl_select_state() to switch between two pinctrl nodes from the devicetree

21:22 <samueldr> those are helpful pointers

21:22 <samueldr> I can't say for sure if sun4i_tcon implements the required glue

21:24 <smaeul> it looks like most of the command logic is present in drivers/gpu/drm/drm_mipi_dbi.c, but that only supports SPI

21:24 <smaeul> so you could possibly extend that, or expose a SPI bus from the TCON

21:25 <samueldr> oh, mipi_dbi, that's what it is, so mipi commands (which I already know it is), but not DSI, but DBI

21:26 <samueldr> and 8080-type parallel bus in the driver doc

22:04 <samueldr> another avenue I want(ed) to explore was whether the panel-simple config *should* work, assuming the panel is setup appropriately by the previous boot stage

22:04 <samueldr> but having issues understanding how to configure the drm_display_mode values

22:12 <smaeul> there's a diagram in include/drm/drm_modes.h

22:15 <samueldr> good, that confirms what I had found, though I don't know what to set the clock at

22:16 <samueldr> for some displays it looks like it's in the ballpark of htotal*vtotal*fps,

22:18 <smaeul> yes, that's exactly what it is

22:18 <samueldr> "round off the total at a nice round~ish value"?

22:19 <samueldr> and/or adjust the porches values until it gets near to a nice clock value?

22:20 <smaeul> some panels seem to do that, some not. some might be adjusted for the actual clock frequency generated by some SoC

22:21 <samueldr> okay, seems to confirm that there was no strict relationship