[PATCH v8 1/5] video: rmk's HDMI notification prototype

[Hans Verkuil]

On 08/11/2016 05:03 PM, Russell King - ARM Linux wrote:
> On Thu, Aug 11, 2016 at 04:49:28PM +0200, Hans Verkuil wrote:
>> On 08/11/16 16:16, Russell King - ARM Linux wrote:
>>> On Thu, Aug 11, 2016 at 12:49:21PM +0200, Hans Verkuil wrote:
>>>> I thought this was the raw EDID data. But if you pass a struct edid around,
>>>> then why not make this const struct edid *edid? I fail to see why you would
>>>> want to use a void pointer here.
>>>
>>> struct edid is a DRM thing - it's not generic.  Using struct edid here
>>> would force everyone to use the DRM structure, whereas other subsystems
>>> use, eg, unsigned char.
>>
>> So how the edid pointer should be interpreted depends on which subsystem
>> sends it? That doesn't sound right. It makes it really hard for the drivers
>> receiving the notifications.
>
> No, that's wrong... and I really don't see why you're trying to make a
> meal of this.

It's a misunderstanding on my side. I thought that struct edid was an 'unpacked'
version of the EDID, but it is just an 'overlay' of the first block of the EDID.

Sorry about that, I never worked much with drm :-) And just forget about that
idea of an hdmi_event_new_phys_addr, that too came out of my misunderstanding.

Anyway, what do you think of using this:

struct hdmi_event_new_edid {
	struct hdmi_event_base base;
	union {
		const struct edid *drm_edid;
		const u8 *edid;
	};
	size_t size;
};

hdmi_event_new_edid is fine using a void pointer (well, I hate void pointers,
but I see no clean way around it).

Regards,

	Hans