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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 10 Jun 2013 12:51:42 -0500
From:	Nishanth Menon <nm@...com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Paul Walmsley <paul@...an.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Tony Lindgren <tony@...mide.com>,
	devicetree-discuss@...ts.ozlabs.org,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>, linux-doc@...r.kernel.org,
	lkml <linux-kernel@...r.kernel.org>,
	linux-omap <linux-omap@...r.kernel.org>,
	Grygorii Strashko <grygorii.strashko@...com>
Subject: Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control
 PMIC over VC/VP

On Mon, Jun 10, 2013 at 11:49 AM, Mark Brown <broonie@...nel.org> wrote:
> On Mon, Jun 10, 2013 at 11:16:59AM -0500, Nishanth Menon wrote:
>> On Mon, Jun 10, 2013 at 5:31 AM, Mark Brown <broonie@...nel.org> wrote:
>> > On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote:
>
>> > So, the biggest problem here has been patch 4 (having to have a hack to
>> > deploy this stuff is a bit worrying) plus the general not having a real
>> > driver thing.
>
>> Patch #4 in this series was a hack as it was not properly split up and
>> organized as a proper DTS series -it was meant as a proof of concept -
>> not entirely meant to indicate the remaining 1-3 patches were hacks
>> :).
>
> The way it reads is that you're building up to a hack - if what you've
> done isn't enabling a sensible solution there might be a problem with
> the earlier steps.

Understood, I should have taken extra steps to split up the patch into
it's logical series, but wanted to get a quick feel from community
about the approach before spending time on it. I apologize for the
confusion caused.

>
>> I think you mean http://marc.info/?t=137059249100003&r=1&w=2 series. I
>> will dig into it. if it is possible for Tegra and OMAP to use the same
>> framework and strategy to deal with these kind of h/w blocks, all the
>> more better.
>
> Not just better, if each system doing this sort of thing needs to
> reinvent the wheel something is going wrong.
Fair enough, I did spend a short while digging through the discussion
in the series, I need to find Tegra TRM to see if there is commonolity
between OMAP and what Tegra does at hardware level.
a) Tegra seems to use Lookup Table for sending predefinied voltage
values to PMIC. OMAP has no concept of lookup table.
b) Tegra and OMAP h/w blocks seem to use I2C - that is good.
c) How about the i2c slave and register addresses, slew rates, start,
end voltages, max voltages that SoC can support etc, I am yet to
understand those.
d) OMAP has 3 modules - AVS (SmartReflex), Voltage Processor(VP),
Voltage Controller(VC) - I am not yet sure about the Tegra hardware
blocks involved.

maybe Paul could comment as well, I suppose if we could take a common
approach between Tegra and OMAP.

Regards,
Nishanth Menon
--
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/

Powered by blists - more mailing lists