From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Walleij Subject: Re: [PATCH 03/10] tty: pxa: configure pin Date: Wed, 24 Oct 2012 07:43:22 +0200 Message-ID: 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> <20121023115806.GX4477@opensource.wolfsonmicro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20121023115806.GX4477-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> 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: Mark Brown 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 On Tue, Oct 23, 2012 at 1:58 PM, Mark Brown wrote: > 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. I agree. I'm thinking about the approach of adding helpers into the PM runtime layer so state handling is centralized, while only the event trigger goes into the driver. Basically it's just the implicit triggers from pm_runtime_[get|put][[_sync] that is causing problems. Yours, Linus Walleij From mboxrd@z Thu Jan 1 00:00:00 1970 From: linus.walleij@linaro.org (Linus Walleij) Date: Wed, 24 Oct 2012 07:43:22 +0200 Subject: [PATCH 03/10] tty: pxa: configure pin In-Reply-To: <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> <20121023115806.GX4477@opensource.wolfsonmicro.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Oct 23, 2012 at 1:58 PM, Mark Brown wrote: > 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. I agree. I'm thinking about the approach of adding helpers into the PM runtime layer so state handling is centralized, while only the event trigger goes into the driver. Basically it's just the implicit triggers from pm_runtime_[get|put][[_sync] that is causing problems. Yours, Linus Walleij