Hi Andy, On 28/07/2022 22:56, Andy Shevchenko wrote: > On Thu, Jul 28, 2022 at 3:23 PM Hans Verkuil <hverkuil-cisco@xxxxxxxxx> wrote: >> On 28/07/2022 14:02, Andy Shevchenko wrote: >>> On Thursday, July 28, 2022, Erling Ljunggren <hljunggr@xxxxxxxxx <mailto:hljunggr@xxxxxxxxx>> wrote: > >>> Support reading and writing the EDID EEPROM through the >>> v4l2 API. >>> >>> Why the normal way of representing as a memory (we have framework and drivers) can’t work? >> >> Because support for EDID for video sinks is already part of the media subsystem (V4L2). >> Normally it is integrated into an HDMI receiver, but in this case it is just the EDID >> support without the video receiver. It belongs in drivers/media in any case since EDIDs >> are closely tied to media. > > It's fine. From the Linux perspective we do not reduplicate the > drivers that are done by other frameworks, right? > >>> Moreover, this driver seems limited in support of variety of the eeprom chips. >> >> Not quite sure what you mean. The cat24c208 is what this was developed for and >> the only one we have. >> >> Note that an EDID EEPROM != a regular EEPROM: it has to support the VESA E-DDC >> standard, which a normal EEPROM doesn't. So these devices are specifically made >> for this use-case. > > What is the difference from a programming interface? > Can the nvmem driver(s) be reused (at24?)? No. EDID EEPROM devices are specific to storing EDIDs: they have two i2c ports, one connected to (typically) the HDMI bus (DDC lines) allowing a video source to read the EDID, the other is connected to the SoC to write to and configure the device. The HDMI bus side has two i2c addresses (reading the EEPROM and to write to the segment address for EDIDs > 256 bytes), the SoC side has three i2c addresses: to configure the behavior, the segment address, and to write the EDID from the SoC. So it is a much more complex device than a regular eeprom, and it really is dedicated to EDIDs only. Also note that the V4L2 API is already used to get/set EDIDs, everything is in place for supporting that, including support for parsing EDIDs for the physical address, which is something that is needed if this is combined with HDMI CEC hardware. It's not implemented in this driver since it is not needed in our use-case, but that might change in the future. And by using the V4L2 API you can use v4l2-ctl --get-edid and --set-edid out of the box, using the standard API for EDIDs. Regards, Hans > > ... > >>> drivers/media/i2c/cat24c208.c | 421 ++++++++++++++++++++++++++++++++++ > > It really seems silly to me to add so many LoCs for the existing > drivers and perhaps we need to extend the nvmem to support EDID rather > than copying everything again? > > Note, I can be well mistaken by not understanding some underlying > issues, perhaps there is some documentation to read... >
