ADV7511/13 implementing atomic ops and bus formats

[Dmitry Baryshkov]

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