From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: [PATCH 03/10] tty: pxa: configure pin Date: Tue, 23 Oct 2012 12:58:07 +0100 Message-ID: <20121023115806.GX4477@opensource.wolfsonmicro.com> References: <1350551224-12857-1-git-send-email-haojian.zhuang@gmail.com> <1350551224-12857-3-git-send-email-haojian.zhuang@gmail.com> <508080CB.5010904@wwwdotorg.org> <5085AC06.8070508@wwwdotorg.org> <20121023093711.GS4477@opensource.wolfsonmicro.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0370986331441485147==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Linus Walleij Cc: Ulf Hansson , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, Magnus Damm , Rickard ANDERSSON , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org --===============0370986331441485147== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oIMVlEQ///Q2JYC7" Content-Disposition: inline --oIMVlEQ///Q2JYC7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. --oIMVlEQ///Q2JYC7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQhoZIAAoJELSic+t+oim9Rn0QAIRD5YundQzdF3j7jDXv3Ij/ hZAwKRQj6CbkCRd2VfwCNWelrYMwzBA0F7z6rX4OH2bHDBHSQkkX3cu86a1M+2HS 9vrIiS9eRlKEXKObIv8R7kBzdNqu2YEw5L3SkLriZGP3XKxahUONx0Rh/7mrxkoj UuuGMmplSlmohWga4hzlwHXbHmb3olZ6zTEg65IRjzGsWw7S7lHJNlWPxl+b49DL S3V2YjUNS5KfABszvfSNsyK8MQJr/T/U3TJZYrSkOIv/THcAekWZaJbX2urZG7AU cTXwJm9lpP+nrH3oe3cwET0VbGQTs+DCeDX19wRj03zk8GD5ck7F6q/K54CxMVXS vfFCat4/ZJCgIKZw0esFlcbcM/bPsvXpEdbq//0clIlBL/O1tQGxIXMV7RjKUAPE lGgfNQ8l8/Z88thuWJVJM9e8922HaXI7VAH9nDaY3A2cd7L1YChfC5tsWlB2WBP1 tDjE06UOKnfU6rfKRzAO9PRlppX9//RPxWCYS5IaADjTQO5hhTDHOmovMqutZbgq 3YM3bKtrPk3aM1DT+zcvNLAOOpZsDb6tg/h8BXT1fcEU3eJukx+5iP5+o1c44+tW GRIhRQgvdTxcaZZzmwPEKDEFe42CqTIrBihVnMl2gB/6o7tA8gcYRQwuOYEcwkq2 Y1CBQUTBCsnyeSgZ821a =NpSF -----END PGP SIGNATURE----- --oIMVlEQ///Q2JYC7-- --===============0370986331441485147== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org https://lists.ozlabs.org/listinfo/devicetree-discuss --===============0370986331441485147==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: broonie@opensource.wolfsonmicro.com (Mark Brown) Date: Tue, 23 Oct 2012 12:58:07 +0100 Subject: [PATCH 03/10] tty: pxa: configure pin In-Reply-To: References: <1350551224-12857-1-git-send-email-haojian.zhuang@gmail.com> <1350551224-12857-3-git-send-email-haojian.zhuang@gmail.com> <508080CB.5010904@wwwdotorg.org> <5085AC06.8070508@wwwdotorg.org> <20121023093711.GS4477@opensource.wolfsonmicro.com> Message-ID: <20121023115806.GX4477@opensource.wolfsonmicro.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: