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?)? ... > > 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... -- With Best Regards, Andy Shevchenko
