From: Clemens Ladisch <clemens@ladisch.de>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: alsa-devel@alsa-project.org,
sakari.ailus@maxwell.research.nokia.com,
broonie@opensource.wolfsonmicro.com,
linux-kernel@vger.kernel.org, Hans Verkuil <hverkuil@xs4all.nl>,
lennart@poettering.net, linux-omap@vger.kernel.org,
linux-media@vger.kernel.org
Subject: Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
Date: Tue, 14 Dec 2010 14:49:15 +0100 [thread overview]
Message-ID: <4D0775DB.2020902@ladisch.de> (raw)
In-Reply-To: <201012141353.15749.laurent.pinchart@ideasonboard.com>
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.
> > >> 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?
> What about ALSA entities, should they use MEDIA_ENTITY_TYPE_ALSA_* ?
The entity types representing ALSA devices are already named "ALSA".
Regards,
Clemens
WARNING: multiple messages have this Message-ID (diff)
From: Clemens Ladisch <clemens@ladisch.de>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
alsa-devel@alsa-project.org,
sakari.ailus@maxwell.research.nokia.com,
broonie@opensource.wolfsonmicro.com,
linux-kernel@vger.kernel.org, lennart@poettering.net,
linux-omap@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Date: Tue, 14 Dec 2010 14:49:15 +0100 [thread overview]
Message-ID: <4D0775DB.2020902@ladisch.de> (raw)
In-Reply-To: <201012141353.15749.laurent.pinchart@ideasonboard.com>
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.
> > >> 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?
> What about ALSA entities, should they use MEDIA_ENTITY_TYPE_ALSA_* ?
The entity types representing ALSA devices are already named "ALSA".
Regards,
Clemens
next prev parent reply other threads:[~2010-12-14 13:49 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-25 2:28 [RFC/PATCH v6 00/12] Media controller (core and V4L2) Laurent Pinchart
2010-11-25 2:28 ` [RFC/PATCH v6 01/12] media: Media device node support Laurent Pinchart
2010-11-25 2:28 ` [RFC/PATCH v6 02/12] media: Media device Laurent Pinchart
2010-11-25 9:33 ` Clemens Ladisch
2010-11-25 14:42 ` Laurent Pinchart
2010-11-25 2:28 ` [RFC/PATCH v6 03/12] media: Entities, pads and links Laurent Pinchart
2010-11-25 9:38 ` Clemens Ladisch
2010-11-25 9:38 ` [RFC/PATCH v6 03/12] [alsa-devel] " Clemens Ladisch
2010-11-25 13:41 ` [RFC/PATCH v6 03/12] " Mark Brown
2010-11-25 13:41 ` [RFC/PATCH v6 03/12] [alsa-devel] " Mark Brown
2010-11-25 15:29 ` Laurent Pinchart
2010-11-25 15:35 ` [RFC/PATCH v6 03/12] " Mark Brown
2010-11-25 15:35 ` [RFC/PATCH v6 03/12] [alsa-devel] " Mark Brown
2010-11-25 15:21 ` Laurent Pinchart
2010-11-25 15:28 ` [RFC/PATCH v6 03/12] " Mark Brown
2010-11-25 15:28 ` [RFC/PATCH v6 03/12] [alsa-devel] " Mark Brown
2010-11-26 9:10 ` [RFC/PATCH v6 03/12] " Clemens Ladisch
2010-11-26 9:10 ` [RFC/PATCH v6 03/12] [alsa-devel] " Clemens Ladisch
2010-12-13 16:10 ` [RFC/PATCH v6 03/12] " Clemens Ladisch
2010-12-13 16:10 ` [alsa-devel] " Clemens Ladisch
2010-12-14 12:00 ` Laurent Pinchart
2010-12-14 12:40 ` Hans Verkuil
2010-12-14 12:53 ` Laurent Pinchart
2010-12-14 12:53 ` [alsa-devel] " Laurent Pinchart
2010-12-14 13:49 ` Clemens Ladisch [this message]
2010-12-14 13:49 ` Clemens Ladisch
2010-12-14 23:50 ` Laurent Pinchart
2010-12-14 23:50 ` [alsa-devel] " Laurent Pinchart
2010-12-21 16:49 ` Hans Verkuil
2010-12-14 13:31 ` Clemens Ladisch
2010-12-14 13:31 ` [alsa-devel] " Clemens Ladisch
2010-12-14 13:54 ` Takashi Iwai
2010-12-14 13:54 ` [alsa-devel] " Takashi Iwai
2010-12-14 14:25 ` Laurent Pinchart
2010-12-14 14:25 ` [alsa-devel] " Laurent Pinchart
2010-12-14 15:30 ` Clemens Ladisch
2010-12-14 15:30 ` [alsa-devel] " Clemens Ladisch
2010-12-14 23:30 ` Raymond Yau
2010-12-14 14:51 ` [alsa-devel] " Hans Verkuil
2010-12-14 14:57 ` Laurent Pinchart
2010-12-14 14:57 ` [alsa-devel] " Laurent Pinchart
2010-12-14 14:49 ` Sakari Ailus
2010-11-25 13:36 ` Mark Brown
2010-11-25 15:40 ` Laurent Pinchart
2010-11-25 15:49 ` Mark Brown
2010-11-26 14:13 ` Laurent Pinchart
2010-11-26 14:14 ` Mark Brown
2010-11-28 12:34 ` Laurent Pinchart
2010-11-28 15:57 ` Hans Verkuil
2010-11-25 2:28 ` [RFC/PATCH v6 04/12] media: Entity graph traversal Laurent Pinchart
2010-11-25 2:28 ` [RFC/PATCH v6 05/12] media: Reference count and power handling Laurent Pinchart
2010-11-25 13:49 ` Mark Brown
2010-11-25 15:43 ` Laurent Pinchart
2010-11-25 17:49 ` Sakari Ailus
2010-11-25 21:47 ` Mark Brown
2010-11-28 12:33 ` Laurent Pinchart
2010-11-28 18:25 ` Mark Brown
2010-11-25 2:28 ` [RFC/PATCH v6 06/12] media: Media device information query Laurent Pinchart
2010-11-25 2:28 ` [RFC/PATCH v6 07/12] media: Entities, pads and links enumeration Laurent Pinchart
2010-11-25 2:28 ` [RFC/PATCH v6 08/12] media: Links setup Laurent Pinchart
2010-11-25 2:28 ` [RFC/PATCH v6 09/12] media: Entity locking and pipeline management Laurent Pinchart
2010-11-25 13:53 ` Mark Brown
2010-11-25 15:47 ` Laurent Pinchart
2010-11-25 2:28 ` [RFC/PATCH v6 10/12] v4l: Add a media_device pointer to the v4l2_device structure Laurent Pinchart
2010-11-25 2:28 ` [RFC/PATCH v6 11/12] v4l: Make video_device inherit from media_entity Laurent Pinchart
2010-11-25 11:38 ` Hans Verkuil
2010-11-25 14:37 ` Laurent Pinchart
2010-11-25 2:28 ` [RFC/PATCH v6 12/12] v4l: Make v4l2_subdev " Laurent Pinchart
2010-11-25 14:28 ` [RFC/PATCH v6 00/12] Media controller (core and V4L2) Mark Brown
2010-11-26 14:07 ` Laurent Pinchart
[not found] ` <201012031119.36771.laurent.pinchart@ideasonboard.com>
[not found] ` <201012031306.18520.hverkuil@xs4all.nl>
2010-12-03 13:50 ` [RFC/PATCH v6 03/12] media: Entities, pads and links Laurent Pinchart
2010-12-03 14:54 ` Mark Brown
2010-12-07 17:13 ` Hans Verkuil
2010-12-07 17:55 ` Mark Brown
2010-12-07 18:11 ` Hans Verkuil
2010-12-07 19:03 ` Mark Brown
2010-12-09 12:53 ` Laurent Pinchart
2010-12-10 16:35 ` Sakari Ailus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D0775DB.2020902@ladisch.de \
--to=clemens@ladisch.de \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=lennart@poettering.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=sakari.ailus@maxwell.research.nokia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.