On Wednesday, December 15, 2010 00:50:44 Laurent Pinchart wrote: > Hi Clemens, > > On Tuesday 14 December 2010 14:49:15 Clemens Ladisch wrote: > > Laurent Pinchart wrote: > > > On Tuesday 14 December 2010 13:40:21 Hans Verkuil wrote: > > >> > On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: > > >> >> * Entity types > > >> >> > > >> >> TYPE_NODE was renamed to TYPE_DEVICE because "node" sounds like a > > >> >> node in a graph, which does not distinguish it from other entity > > >> >> types because all entities are part of the topology graph. I chose > > >> >> "device" as this type describes entities that are visible as some > > >> >> device node to other software. > > >> > > > >> > What this type describes is a device node. Both NODE and DEVICE can be > > >> > confusing in my opinion, but DEVICE_NODE is a bit long. > > >> > > >> What about DEVNODE? I think that would be a good alternative. > > > > > > Fine with me. Clemens, any opinion on that ? > > > > Fine with me too. > > OK I'll use that name. > > > > > >> TYPE_EXT describes entities that represent some interface to the > > > > >> external world, TYPE_INT those that are internal to the entire > > > > >> device. (I'm not sure if that distinction is very useful, but > > > > >> TYPE_SUBDEV seems to be an even more meaningless name.) > > > > > > > > > > SUBDEV comes from the V4L2 world, and I agree that it might not be a > > > > > very good name. > > > > > > > > SUBDEV refers to a specific type of driver. Within the v4l world it is > > > > well defined. So I prefer to keep this. Perhaps some additional > > > > comments or documentation can be added to clarify this. > > > > > > Should this be clarified by using V4L2_SUBDEV instead then ? > > > > If the "SUBDEV" concept doesn't exist outside V4L, that would indeed be > > better. > > > > I don't want to rename things that come out of existing frameworks; this > > naming discussion makes sense only for those entity (sub)types that can > > be shared between them. Are there any, besides jacks? > > Some entities like TV tuners play a dual audio/video role. I'm not sure how to > handle them, I lack experience in that field. It is very important to distinguish between the actual tuner device and the physical connector. ALSA doesn't program a tuner device, that's the domain of V4L and DVB. ALSA just sees an input pin. Regarding tuners there are roughly two types of hardware: one where the audio goes to an output jack (and the user has to use a loopback cable to hook it up to an audio input), or it goes to memory using DMA and an ALSA driver. In the first scenario the MC would model a TV_ANTENNA connector and an AUDIO_OUT connector. The TV_ANTENNA connector would typically link to a V4L2_SUBDEV_TUNER, which would link to a V4L2_SUBDEV_AUDIO_DEMOD (in turn linked to the AUDIO_OUT connector). The tuner would also link to a V4L2_SUBDEV_VIDEO_DIGITIZER (in turn linked to a DEVNODE_V4L). In the second scenario there is no AUDIO_OUT connector, instead there is a DEVNODE_ALSA. It can get more complex: in the case of MPEG encoders the audio from the tuner goes to an audio demod, the video goes to a digitizer, and the output of those subdevs both go into the same MPEG encoder subdev. When modeling hardware like audio or video devices it is important to remember to separate I/O pins from actually physical connectors. E.g. an audio device may have many possible input pins, but how they are hooked up to which physical connectors is something that is board specific and not part of the audio driver itself. Anyway, what we need is a 'connector' entity. And just like the other entities, connectors can have multiple input pads so I don't see any problems in modeling antenna connectors. Regards, Hans > > > What about ALSA entities, should they use MEDIA_ENTITY_TYPE_ALSA_* ? > > > > The entity types representing ALSA devices are already named "ALSA". > > I was talking about the INT_* types. They're ALSA-specific, but have no ALSA > in the type name. > > -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
