Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753172AbcDOHyi (ORCPT ); Fri, 15 Apr 2016 03:54:38 -0400 Received: from mail-ob0-f180.google.com ([209.85.214.180]:35517 "EHLO mail-ob0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752771AbcDOHyf (ORCPT ); Fri, 15 Apr 2016 03:54:35 -0400 MIME-Version: 1.0 In-Reply-To: <1460473007-11535-5-git-send-email-ldewangan@nvidia.com> References: <1460473007-11535-1-git-send-email-ldewangan@nvidia.com> <1460473007-11535-5-git-send-email-ldewangan@nvidia.com> Date: Fri, 15 Apr 2016 09:54:34 +0200 Message-ID: Subject: Re: [PATCH 4/7] soc/tegra: pmc: Add interface to set voltage of IO rails From: Linus Walleij To: Laxman Dewangan , Liam Girdwood , Mark Brown , Arnd Bergmann , Olof Johansson Cc: Stephen Warren , Thierry Reding , Alexandre Courbot , Rob Herring , Mark Rutland , Jon Hunter , "linux-tegra@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-gpio@vger.kernel.org" , Ulf Hansson Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1239 Lines: 31 On Tue, Apr 12, 2016 at 4:56 PM, Laxman Dewangan wrote: > NVIDIA Tegra210 supports some of the IO interface which can operate > at 1.8V or 3.3V I/O rail voltage levels. SW needs to configure > Tegra PMC register to set different voltage level of IO interface based > on IO rail voltage from power supply i.e. power regulators. > > Add APIs to set and get IO rail voltage from the client driver. > > Signed-off-by: Laxman Dewangan Nobody seems to mention the elephant in the room: why is this not using the regulator subsystem and instead using custom code under drivers/soc? We have worried before about drivers/soc becoming a dumping ground akin to drivers/misc IIRC in the past we tried to use regulators for this kind of fast switches at ST-Ericsson, and the problem we ran into was that regulators were kind of heavyweight and would need some locking and required to run in slowpath. But as complexity increases the question has to be asked again, because what we don't want is for every SOC to start reimplementing stuff from the regulator framework under drivers/soc. I'm asking you to make a case for this necessarily different, "we are special" custom code. Yours, Linus Walleij