On Sat, Dec 28, 2024 at 09:20:17PM +0000, Jesse Van Gavere wrote: > Hey all, > > (Hope this is not a duplicate as my first mail didn't seem to have > gone through) For one of our new boards I have to get the ADV7513 chip > working with TIDSS, the driver for this expects a bridge chip to have > atomic ops and provide bus formats. Doing this for our own needs was > quite straightforward but I'd very much like to upstream this as I > think it could be helpful for others as well, I do have some questions > I hope to get some answers on that could help me in writing an initial > patch. I hope you'll forgive any ignorance on my end as it's my first > foray into DRI. > > - For all needed atomic ops I added the drm atomic ops helpers, except > for atomic_check, looking through the other implementations I can't > quite figure out what I'm expected to implement here, what is the > expectation for this function? The atomic_check() function verifies if the passed set of changes (in the form of drm_*_state) is valid from the driver's point of view. If you have nothing to check, it's fine to skip the function. > - Looking at the lontium 9611, only the input bus formats bridge > function are added there, which seems sensible as the output goes out > straight over HDMI, is it a correct assumption I'd only have to add > the input bus formats for the adv7511 driver? Part of me thinks this > might not necessarily be correct as it seems the chip can be chained > further than merely to a connector and I'm not sure what this would > (or could) expect I'd say, it's fine to ommit the output formats handling. From what I can see only dw-hdmi does sensible job of calculating output bus formats for HDMI Bus. The it66121 simply returns MEDIA_BUS_FMT_RGB888_1X24. > - Does Input justification matter for the bus format? My assumption is > that left/evenly/right does not matter for the format as it only > relates to which pins are used and it's e.g. MEDIA_BUS_FMT_UYVY8_2X8 > no matter which pins this is placed at so I should just focus on the > actively used pins. I'd say, yes, for non-DPI bridges. And I'm not even sure if justification also isn't applicable to DPI bridges. Wait... you have a DPI driver. Granted that Analog doesn't define D[23:0] format, I don't think I can answer your question. > - As it's a common driver for adv7511(w)/adv7513, would anyone know if > they all use the exact same types of input styles (of course with > varying color depth support) so that I could use ADV7511 as a sort of > superset for all possibilities and work > from there to define all the input formats? No, each bus (DSI, DPI, etc) have it's own data formats. This means ADV7511 (D[35:0]), ADV7513 (D[23:0]) and ADV7533/35 (4x D-PHY lanes + clock lane) have different input formats. > - There seem to be certain formats in there that don't exist yet, such > as YUV444 12-bit VYU (if I do this right and read highest data bits to > lowest, which I assume translates to MEDIA_BUS_FMT_VYU12_1X36), should > I just write a patch for all missing formats to the uapi > media-bus-format header or is there anything else to take into > consideration? Just uapi patch with explanation and justification. > > Best regards, > Jesse -- With best wishes Dmitry
