Re: [PATCH 03/10] tty: pxa: configure pin

[Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1989 bytes --]

On Tue, Oct 23, 2012 at 11:59:30AM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 11:37 AM, Mark Brown
> > On Tue, Oct 23, 2012 at 11:26:40AM +0200, Linus Walleij wrote:

> > Can we handle this with power domains - if different devices require
> > different orderings they can be placed in power domains which implement
> > the appropriate orderings for them?

> clocks, regulators, pins and all in power domains?

> Then we should rename them "device resource domains" or
> something...

We can call them Ichabod for all I care...

> I have a strong sense of system-wide all-or-nothing approaches
> to this problem.

> - Either we use "power" domains to handle every resource the
>  device has.
> - Or the device driver manages it's own resources.

> I find it pretty hard to build consensus around either idea.

Well, I don't think we want all or nothing approaches here.  One problem
is that we don't have a home for the SoC integration so we're trying to
shove it all into the drivers which just leads to a stack of pointless
boilerplate when the driver isn't actually doing anything beyond the
basic pattern of turning everything off when it goes idle and turning it
on again when it needs to do something.  Having to open code that stuff
in the drivers and then deal with the stubbing and error handling so the
error handling in the drivers is painful.  There's also another axis
where things aren't part of a SoC but are separate devices so you want
to carry things along with the driver rather than have a separate bit of
code which is required to glue things into the platform.

For example it seems fairly clear to me that things like the pinctrl
integration I see in something like sound/soc/fsl/imx-audmux.c shouldn't
really be there as we're just setting up a static configration on boot.
On the other hand where things are directly involved with the active
operation of a device like changing clock rates then clearly the driver
needs to know about and manage things.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss