From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756050Ab0EQVSW (ORCPT ); Mon, 17 May 2010 17:18:22 -0400 Received: from opensource.wolfsonmicro.com ([80.75.67.52]:39389 "EHLO opensource2.wolfsonmicro.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754440Ab0EQVSV (ORCPT ); Mon, 17 May 2010 17:18:21 -0400 Subject: RE: [linux-pm] Power Domain Framework From: Mark Brown To: Linus WALLEIJ Cc: Sundar R IYER , Deepak Sikri , Viresh KUMAR , Rajeev KUMAR , Armando VISCONTI , "linux-kernel@vger.kernel.org" , Vipin KUMAR , Shiraz HASHIM , "linux-pm@lists.linux-foundation.org" , STEricsson_nomadik_linux In-Reply-To: (sfid-20100517_213915_202336_5BFAA478) References: <20100510140527.GG5199@sirena.org.uk> <20100517031613.GA3130@opensource.wolfsonmicro.com> <20100517143319.GC5257@opensource.wolfsonmicro.com> <1274114107.20589.64.camel@bnru01> (sfid-20100517_173524_963855_B42F2966) <1274115886.2698.22.camel@finisterre.wolfsonmicro.main> <1274118332.17303.17.camel@bnru01> (sfid-20100517_213915_202336_5BFAA478) Content-Type: text/plain; charset="UTF-8" Organization: Wolfson Microelectronics Date: Mon, 17 May 2010 14:18:28 -0700 Message-ID: <1274131108.2698.161.camel@finisterre.wolfsonmicro.main> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2010-05-17 at 22:38 +0200, Linus WALLEIJ wrote: > [Sundar] > > This is one of the most important aspect for such a change in the > > regulator framework: bringing in the domain aspect can encourage all > > newer (possibly older) architectures to come under a generic umbrella. > I have the same view, and I've been enouraging Sundar to bring this > discussion with the community in order to avoid code duplication. > Of course we can start inventing our own power-domain machine > like everyone else, but before we do that, let's atleast try to > do something generic, so bear with us... So, there's two separate issues here: one is if it makes sense to do a generic power domain framework and/or, and the other is if it makes sense for that generic power domain framework to be part of the regulator API. I do agree that separating out the common bits of power domain implementation would be good, my concerns here are around the level of integration with the regulator API.