On 05/11/2015 11:31 AM, Mauro Carvalho Chehab wrote: > Em Sat, 09 May 2015 11:31:42 +0200 > Hans Verkuil <hverkuil@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
