linux-kernel - Re: [PATCH 12/13] cpufreq: Add cpufreq driver for Tegra124

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53C002BE.90805@nvidia.com>
Date:	Fri, 11 Jul 2014 18:29:02 +0300
From:	Tuomas Tynkkynen <ttynkkynen@...dia.com>
To:	Thierry Reding <thierry.reding@...il.com>
CC:	Peter De Schrijver <pdeschrijver@...dia.com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Prashant Gaikwad <pgaikwad@...dia.com>,
	Mike Turquette <mturquette@...aro.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 12/13] cpufreq: Add cpufreq driver for Tegra124



On 11/07/14 18:15, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Fri, Jul 11, 2014 at 06:11:41PM +0300, Tuomas Tynkkynen wrote:
>> On 11/07/14 17:57, Thierry Reding wrote:
>>
>>>> I don't think that's going to work? The voltage scaling is handled in hw.
>>>
>>> Do we have to handle it in hardware or can we opt to do it in software,
>>> too?
>>>
>>
>> With the PLLX, voltage scaling is done entirely in SW. With the DFLL,
>> it's possible to stay in open-loop mode and do it in SW, but there's
>> not much point in that.
>
> It's kind of ugly how we need to pass the address of the PMU and the
> offset of the voltage control register to the DFLL which will then
> initiate I2C transactions itself. I'm wondering if that plays well with
> the I2C traffic originating from within the kernel.
>

On the hardware level, the two I2C controllers sharing the same pins
have knowledge of each other and won't start transmitting if the bus
is busy (something different from the usual I2C arbitration, that is).
I guess on the kernel side there could be a problem if the voltage 
register is marked cached in the PMIC driver's regmap.

-- 
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/