From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754365AbbINIrc (ORCPT ); Mon, 14 Sep 2015 04:47:32 -0400 Received: from gloria.sntech.de ([95.129.55.99]:33210 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752190AbbINIra (ORCPT ); Mon, 14 Sep 2015 04:47:30 -0400 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Sjoerd Simons Cc: Javier Martinez Canillas , Mark Rutland , "devicetree@vger.kernel.org" , Russell King , Pawel Moll , Ian Campbell , Linux Kernel , linux-rockchip@lists.infradead.org, Rob Herring , Kumar Gala , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 2/2] ARM: dts: rockchip: Add dtb for the Radxa Rock 2 Square board Date: Mon, 14 Sep 2015 10:47:19 +0200 Message-ID: <7783425.5jykIre40o@diego> User-Agent: KMail/4.14.10 (Linux/4.1.0-2-amd64; KDE/4.14.10; x86_64; ; ) In-Reply-To: <1442217958.8778.103.camel@collabora.co.uk> References: <1442011005-4828-1-git-send-email-sjoerd.simons@collabora.co.uk> <1442217958.8778.103.camel@collabora.co.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Montag, 14. September 2015, 10:05:58 schrieb Sjoerd Simons: > Hey Javier, > > On Mon, 2015-09-14 at 09:50 +0200, Javier Martinez Canillas wrote: > > Hello Sjoerd, > > > > On Mon, Sep 14, 2015 at 9:30 AM, Sjoerd Simons > > > > wrote: > > > For the first patch i do prefer to keep them on so we can have get > > > some > > > more testing with this board before fine-tuning those things > > > (fwiw, > > > > Ok. > > > > > the rockchip evb board and others with essentially the same pmic > > > setup > > > all also have them always-on) > > > > Yes but I believe that's because it was easier and there are > > regulators on these boards that don't need to be always-on as well. > > Yes what i was trying to say is that it's not an uncommon to keep these > on for convenience while fine-tuning the device-tree setups ;) Also, a lot of drivers do not yet do proper regulator handling (our drm/kms driver as a prime example), so the number of regulators able to being actually turned off is quite slim. So I guess I'm ok, with handling these once driver components can actually do something with their supplies :-) . Heiko