Re: [RFC/PATCH v6 03/12] media: Entities, pads and links

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

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)?

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.