[alsa-devel] [PATCH RFC 0/2] drivers/base: simplify simple DT-based components
Russell King - ARM Linux
linux at arm.linux.org.uk
Fri Feb 7 19:59:11 CET 2014
On Fri, Feb 07, 2014 at 07:42:04PM +0100, Jean-Francois Moine wrote:
> On Fri, 7 Feb 2014 17:33:26 +0000
> Russell King - ARM Linux <linux at arm.linux.org.uk> wrote:
> > On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote:
> > > This patch series tries to simplify the code of simple devices in case
> > > they are part of componentised subsystems, are declared in a DT, and
> > > are not using the component bin/unbind functions.
> > I wonder - I said earlier today that this works absolutely fine without
> > modification with DT, so why are you messing about with it adding DT
> > support?
> > This is totally the wrong approach. The idea is that this deals with
> > /devices/ and /devices/ only. It groups up /devices/.
> > It's up to the add_component callback to the master device to decide
> > how to deal with that.
> > > Jean-Francois Moine (2):
> > > drivers/base: permit base components to omit the bind/unbind ops
> > And this patch has me wondering if you even understand how to use
> > this... The master bind/unbind callbacks are the ones which establish
> > the "card" based context with the subsystem.
> > Please, before buggering up this nicely designed implementation, please
> > /first/ look at the imx-drm rework which was posted back in early January
> > which illustrates how this is used in a DT context - which is something
> > I've already pointed you at once today already.
> As I told in a previous mail, your code works fine in my DT-based
> Cubox. I am rewriting the TDA988x as a normal encoder/connector, and,
> yes, the bind/unbind functions are useful in this case.
So, which bit of "I've already got that" was missed?
> But you opened a door. In a DT context, you know that the probe_defer
> mechanism does not work correctly. Your work permits to solve delicate
> cases: your component_add tells exactly when a device is available, and
> the master bind callback is the green signal for the device waiting for
> its resources. Indeed, your system was not created for such a usage,
> but it works as it is (anyway, the component bind/unbind functions may
> be empty...).
Sorry. Deferred probe does work, it's been tested with imx-drm, not
only from the master component but also the sub-components. There's
no problem here.
And no component bind/unbind function should ever be empty.
Again, I put it to you that you don't understand this layer.
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
More information about the Alsa-devel