Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi, On Tuesday 07 December 2010 20:03:28 Mark Brown wrote: On Tue, Dec 07, 2010 at 07:11:39PM +0100, Hans Verkuil wrote: Ah, now I understand what you mean. Would 'activated' be better than 'active'? Better, yes, though it still sounds a bit like something should be actively (IYSWIM) happening. In the absence of better ideas I could go with this. Or perhaps just say: the link 'is on' or the link 'is switched on'? So: ...LINK_SWITCHED_ON (sorry, forgot what the prefix is). Actually, I think 'switched on' is a pretty good description of what is going on in the hardware. I prefer activated, this makes me think of power. Bear in mind that for most audio the power is a big portion of the control - either the audio is analogue or it looks like it. Do I understand it correctly that the outcome of this discussion is that I just need to rename active to activated when talking about links ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
On Friday, December 03, 2010 15:54:08 Mark Brown wrote: On Fri, Dec 03, 2010 at 02:50:58PM +0100, Laurent Pinchart wrote: On Friday 03 December 2010 13:06:18 Hans Verkuil wrote: Just to confirm thinks, Mark's proposal is to replace 'connected' by 'linked' and 'active' by 'connected'. Are we on the same page here ? Yes, but when I read it back it does not make me happy. 'Connected' and 'linked' basically have the same meaning in English. I unfortunately agree that it's a bit confusing :-( It feels like the problem here is that for whatever reason (I'm not sure what?) you're trying to come up with verbs for links that are currently disconnected - in ASoC we just say we've got paths that exist and then we talk about the paths that are connected. Verbing everything makes it all sound active which is confusing when you're talking about links that are idle. OK, let's try this again. The media controller has entities, entities have pads, and between pads there are links. Links can be active (data can flow) or inactive (no data can flow). Active links can be idle (no data is flowing) or streaming (data is flowing over the link). Personally I think this is perfectly clear. The original confusion came from the word 'active', which I understand means 'streaming' in alsa. By adding a 'streaming' flag in addition to the active flag I think it will be clear that 'active' and 'streaming' are two different things. Regarding 'active': an alternative could be 'connected'. I think it is not quite as good as 'active' since basically all links are always connected in the usual sense of the word. It is just that a mux decides which one is actually working. However, I won't object to using 'connected' instead of 'active' if others prefer that. Regards, Hans -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
On Tue, Dec 07, 2010 at 06:13:35PM +0100, Hans Verkuil wrote: Personally I think this is perfectly clear. The original confusion came from the word 'active', which I understand means 'streaming' in alsa. By adding a 'streaming' flag in addition to the active flag I think it will be clear that 'active' and 'streaming' are two different things. It's not that, it's the fact that active sounds to me like the link ought to be powered up which isn't the case - it's too verby. Like I say, I think I'd prefer a more passive name like connected. I guess if nobody else finds it confusing I can live with it. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
On Tuesday, December 07, 2010 18:55:05 Mark Brown wrote: On Tue, Dec 07, 2010 at 06:13:35PM +0100, Hans Verkuil wrote: Personally I think this is perfectly clear. The original confusion came from the word 'active', which I understand means 'streaming' in alsa. By adding a 'streaming' flag in addition to the active flag I think it will be clear that 'active' and 'streaming' are two different things. It's not that, it's the fact that active sounds to me like the link ought to be powered up which isn't the case - it's too verby. Like I say, I think I'd prefer a more passive name like connected. Ah, now I understand what you mean. Would 'activated' be better than 'active'? Or perhaps just say: the link 'is on' or the link 'is switched on'? So: ...LINK_SWITCHED_ON (sorry, forgot what the prefix is). Actually, I think 'switched on' is a pretty good description of what is going on in the hardware. Regards, Hans I guess if nobody else finds it confusing I can live with it. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
On Tue, Dec 07, 2010 at 07:11:39PM +0100, Hans Verkuil wrote: Ah, now I understand what you mean. Would 'activated' be better than 'active'? Better, yes, though it still sounds a bit like something should be actively (IYSWIM) happening. In the absence of better ideas I could go with this. Or perhaps just say: the link 'is on' or the link 'is switched on'? So: ...LINK_SWITCHED_ON (sorry, forgot what the prefix is). Actually, I think 'switched on' is a pretty good description of what is going on in the hardware. I prefer activated, this makes me think of power. Bear in mind that for most audio the power is a big portion of the control - either the audio is analogue or it looks like it. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Hans, Adding by the original CC list which was dropped by mistake. On Friday 03 December 2010 13:06:18 Hans Verkuil wrote: On Friday, December 03, 2010 11:19:36 Laurent Pinchart wrote: On Sunday 28 November 2010 16:57:00 you wrote: On Sunday, November 28, 2010 13:34:45 Laurent Pinchart wrote: On Friday 26 November 2010 15:14:42 Mark Brown wrote: On Fri, Nov 26, 2010 at 03:13:36PM +0100, Laurent Pinchart wrote: On Thursday 25 November 2010 16:49:52 Mark Brown wrote: On Thu, Nov 25, 2010 at 04:40:41PM +0100, Laurent Pinchart wrote: It's supposed to reflect whether the link can carry data. Think of the active flag as a valve on a pipe. If the valve is open, the link is active. If the valve is closed, the link is inactive. This is unrelated to whether water actually flows through the pipe. This seems a confusing name, then - I'd expect an active link to be one which is actually carrying data rather than one which is available to carry data. How a more neutrally worded name such as connected (which is what ASoC uses currently)? In our current vocabulary connected refers to entities between which a link exist, regardless of the link state (valve opened or valve closed). I'm not totally happy with active either, but if we replace it with connected we need another word to replace current uses of connected. Linked? That's a good option. Hans, do you want to comment on this ? Fine by me! It's better than 'active'. Just to confirm thinks, Mark's proposal is to replace 'connected' by 'linked' and 'active' by 'connected'. Are we on the same page here ? Yes, but when I read it back it does not make me happy. 'Connected' and 'linked' basically have the same meaning in English. I unfortunately agree that it's a bit confusing :-( I really like your analogy with valves, so perhaps we should use either 'linked' or 'connected' to describe that two entities are, well, linked/connected, and use the 'open' and 'closed' terminology to describe whether a link/connection is open (data can flow) or closed (no data can flow). I don't really like the open/closed terminology to describe links. I can think of two analogies: pipes with valves that can be opened/closed, or cables that can be connected/disconnected. In the first case, connected/linked can be used to specify the pipes that exist in the system, but I'm not happy with open/closed. In the second case, connected/linked can be used to specify whether a cable is connected, but in that case we will need another word to describe whether two pads are connectable or not. I have a slight preference for 'link' over 'connection', but that's mostly because it is a shorter word :-) Link refers to a pipe/possible cable connection. It's an object on both the kernel side and the userspace side. Using the above analogies, tt makes sense to use the word 'linked' to refer to two pads that are connected by a pipe, or between which a cable can be connected. Now we need a word to descripe whether the valve is opened or closed, or whether the cable is connected or not. I don't really like 'open'/'closed' for the first analogy. 'connected' would make sense for the second analogy, but it can indeed be a bit confusing. Thoughts ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
On Fri, Dec 03, 2010 at 02:50:58PM +0100, Laurent Pinchart wrote: On Friday 03 December 2010 13:06:18 Hans Verkuil wrote: Just to confirm thinks, Mark's proposal is to replace 'connected' by 'linked' and 'active' by 'connected'. Are we on the same page here ? Yes, but when I read it back it does not make me happy. 'Connected' and 'linked' basically have the same meaning in English. I unfortunately agree that it's a bit confusing :-( It feels like the problem here is that for whatever reason (I'm not sure what?) you're trying to come up with verbs for links that are currently disconnected - in ASoC we just say we've got paths that exist and then we talk about the paths that are connected. Verbing everything makes it all sound active which is confusing when you're talking about links that are idle. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Mark, On Friday 26 November 2010 15:14:42 Mark Brown wrote: On Fri, Nov 26, 2010 at 03:13:36PM +0100, Laurent Pinchart wrote: On Thursday 25 November 2010 16:49:52 Mark Brown wrote: On Thu, Nov 25, 2010 at 04:40:41PM +0100, Laurent Pinchart wrote: It's supposed to reflect whether the link can carry data. Think of the active flag as a valve on a pipe. If the valve is open, the link is active. If the valve is closed, the link is inactive. This is unrelated to whether water actually flows through the pipe. This seems a confusing name, then - I'd expect an active link to be one which is actually carrying data rather than one which is available to carry data. How a more neutrally worded name such as connected (which is what ASoC uses currently)? In our current vocabulary connected refers to entities between which a link exist, regardless of the link state (valve opened or valve closed). I'm not totally happy with active either, but if we replace it with connected we need another word to replace current uses of connected. Linked? That's a good option. Hans, do you want to comment on this ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
On Sunday, November 28, 2010 13:34:45 Laurent Pinchart wrote: Hi Mark, On Friday 26 November 2010 15:14:42 Mark Brown wrote: On Fri, Nov 26, 2010 at 03:13:36PM +0100, Laurent Pinchart wrote: On Thursday 25 November 2010 16:49:52 Mark Brown wrote: On Thu, Nov 25, 2010 at 04:40:41PM +0100, Laurent Pinchart wrote: It's supposed to reflect whether the link can carry data. Think of the active flag as a valve on a pipe. If the valve is open, the link is active. If the valve is closed, the link is inactive. This is unrelated to whether water actually flows through the pipe. This seems a confusing name, then - I'd expect an active link to be one which is actually carrying data rather than one which is available to carry data. How a more neutrally worded name such as connected (which is what ASoC uses currently)? In our current vocabulary connected refers to entities between which a link exist, regardless of the link state (valve opened or valve closed). I'm not totally happy with active either, but if we replace it with connected we need another word to replace current uses of connected. Linked? That's a good option. Hans, do you want to comment on this ? Fine by me! It's better than 'active'. Regards, Hans -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Mark, On Thursday 25 November 2010 16:49:52 Mark Brown wrote: On Thu, Nov 25, 2010 at 04:40:41PM +0100, Laurent Pinchart wrote: On Thursday 25 November 2010 14:36:50 Mark Brown wrote: On Thu, Nov 25, 2010 at 03:28:10AM +0100, Laurent Pinchart wrote: + MEDIA_LINK_FLAG_ACTIVE indicates that the link is active and can be + used to transfer media data. When two or more links target a sink pad, + only one of them can be active at a time. Is this supposed to reflect the current state (if the link is carrying data right now) or if it's possible for the link to carry data? It's supposed to reflect whether the link can carry data. Think of the active flag as a valve on a pipe. If the valve is open, the link is active. If the valve is closed, the link is inactive. This is unrelated to whether water actually flows through the pipe. This seems a confusing name, then - I'd expect an active link to be one which is actually carrying data rather than one which is available to carry data. How a more neutrally worded name such as connected (which is what ASoC uses currently)? In our current vocabulary connected refers to entities between which a link exist, regardless of the link state (valve opened or valve closed). I'm not totally happy with active either, but if we replace it with connected we need another word to replace current uses of connected. This also falls through into the power management stuff, we don't want to be powering things up unless they're actually doing something right now. Immutable links have no valve (in theory you could have an inactive immutable link, but that's not very useful, unless we define immutable as no user- controllable valve, in which case it might be better to rename it as read- only, or create separate immutable and read-only flags - just brainstorming here). That was what I was expecting immutable to mean - no user control. A link that's permanantly wired can have the data flow controlled through its inputs and outputs, even if it is not itself controllable. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
On Fri, Nov 26, 2010 at 03:13:36PM +0100, Laurent Pinchart wrote: On Thursday 25 November 2010 16:49:52 Mark Brown wrote: On Thu, Nov 25, 2010 at 04:40:41PM +0100, Laurent Pinchart wrote: It's supposed to reflect whether the link can carry data. Think of the active flag as a valve on a pipe. If the valve is open, the link is active. If the valve is closed, the link is inactive. This is unrelated to whether water actually flows through the pipe. This seems a confusing name, then - I'd expect an active link to be one which is actually carrying data rather than one which is available to carry data. How a more neutrally worded name such as connected (which is what ASoC uses currently)? In our current vocabulary connected refers to entities between which a link exist, regardless of the link state (valve opened or valve closed). I'm not totally happy with active either, but if we replace it with connected we need another word to replace current uses of connected. Linked? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
On Thu, Nov 25, 2010 at 03:28:10AM +0100, Laurent Pinchart wrote:
+Links have flags that describe the link capabilities and state.
+ MEDIA_LINK_FLAG_ACTIVE indicates that the link is active and can be
+ used to transfer media data. When two or more links target a sink pad,
+ only one of them can be active at a time.
Is this supposed to reflect the current state (if the link is carrying
data right now) or if it's possible for the link to carry data?
+struct media_entity {
+ struct list_head list;
+ struct media_device *parent;/* Media device this entity belongs to*/
+ u32 id; /* Entity ID, unique in the parent media
+ * device context */
+ const char *name; /* Entity name */
+ u32 type; /* Entity type (MEDIA_ENTITY_TYPE_*) */
+ u32 revision; /* Entity revision, driver specific */
+ unsigned long flags;/* Entity flags (MEDIA_ENTITY_FLAG_*) */
+ u32 group_id; /* Entity group ID */
+
+ u16 num_pads; /* Number of input and output pads */
+ u16 num_links; /* Number of existing links, both active
+ * and inactive */
+ u16 num_backlinks; /* Number of backlinks */
+ u16 max_links; /* Maximum number of links */
+
+ struct media_pad *pads; /* Pads array (num_pads elements) */
+ struct media_link *links; /* Links array (max_links elements)*/
Hrm. This is getting kind of large, especially considering the volume
of data we're holding per node and link already in ASoC. On the other
hand we may over time be able to refactor some of the existing stuff
(especially the link management) to use this structure.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Mark,
On Thursday 25 November 2010 14:36:50 Mark Brown wrote:
On Thu, Nov 25, 2010 at 03:28:10AM +0100, Laurent Pinchart wrote:
+Links have flags that describe the link capabilities and state.
+ MEDIA_LINK_FLAG_ACTIVE indicates that the link is active and can be
+ used to transfer media data. When two or more links target a sink pad,
+ only one of them can be active at a time.
Is this supposed to reflect the current state (if the link is carrying
data right now) or if it's possible for the link to carry data?
It's supposed to reflect whether the link can carry data. Think of the active
flag as a valve on a pipe. If the valve is open, the link is active. If the
valve is closed, the link is inactive. This is unrelated to whether water
actually flows through the pipe.
Immutable links have no valve (in theory you could have an inactive immutable
link, but that's not very useful, unless we define immutable as no user-
controllable valve, in which case it might be better to rename it as read-
only, or create separate immutable and read-only flags - just brainstorming
here).
+struct media_entity {
+ struct list_head list;
+ struct media_device *parent;/* Media device this entity belongs to*/
+ u32 id; /* Entity ID, unique in the parent media
+* device context */
+ const char *name; /* Entity name */
+ u32 type; /* Entity type (MEDIA_ENTITY_TYPE_*) */
+ u32 revision; /* Entity revision, driver specific */
+ unsigned long flags;/* Entity flags (MEDIA_ENTITY_FLAG_*) */
+ u32 group_id; /* Entity group ID */
+
+ u16 num_pads; /* Number of input and output pads */
+ u16 num_links; /* Number of existing links, both active
+* and inactive */
+ u16 num_backlinks; /* Number of backlinks */
+ u16 max_links; /* Maximum number of links */
+
+ struct media_pad *pads; /* Pads array (num_pads elements) */
+ struct media_link *links; /* Links array (max_links elements)*/
Hrm. This is getting kind of large, especially considering the volume
of data we're holding per node and link already in ASoC. On the other
hand we may over time be able to refactor some of the existing stuff
(especially the link management) to use this structure.
That's the idea :-) In the long term (hopefully not that long) I would like to
see both sources of information merged. That's why I'm interested in your
requirements to make sure this will be possible.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
