Re: [PATCH 07/18] media controller: rename the tuner entity

[Hans Verkuil <hverkuil@xs4all.nl>]

On 05/11/2015 11:31 AM, Mauro Carvalho Chehab wrote:
> Em Sat, 09 May 2015 11:31:42 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> 
>>>>> Brainstorming:
>>>>>
>>>>> It might be better to map each device node to an entity and each hardware
>>>>> component (tuner, DMA engine) to an entity, and avoid this mixing of
>>>>> hw entity vs device node entity.
>>
>> There are two options here:
>>
>> either make each device node an entity, or expose the device node information
>> as properties of an entity.
>>
>> The latter would be backwards compatible with what we do today. I'm trying to
>> think of reasons why you would want to make each device node an entity in its
>> own right.
>>
>> The problem today is that a video_device representing a video/vbi/radio/swradio
>> device node is an entity, but it is really representing the dma engine. Which
>> is weird for radio devices since there is no dma engine there.
>>
>> Implementing device nodes as entities in their own right does solve this problem,
>> but implementing it as properties would be weird since a radio device node would
>> be a property of a radio tuner entity, which can be a subdevice driver which means
>> that the bridge driver would have to add the radio device property to a subdev
>> driver, which feels really wrong to me.
>>
>> With this in mind I do think representing device nodes as entities in their own
>> right makes sense.
> 
> I agree with that: devnodes should be entities, as they're the points to control
> the hardware, and need to be known by the Kernel, no matter if they have DMA
> engines associated with it or not. The better seems to map the DMA engine
> as a property on those entities.
> 
>> But I would do this also for a v4l-subdev node. It's very
>> inconsistent not to do that.
> 
> It should be easy to create an entity for each v4l-subdev node. I just
> don't see much usage on it, and this will almost double the number of
> entities.

The memory is already allocated for that since it is part of struct video_device,
which v4l-subdev uses. So I don't see this as a problem.

> Also, in order to keep it backward-compatible, both the subdev
> devnode and the subdev no-devnode entity should accept the same set of
> ioctls.

The ioctls always go through the video_device, that will not be changed by
this.

But I agree that there are other backward-compat issues. Unfortunately I cannot
dedicate much time on this at the moment.

Regards,

	Hans