Re: [PATCHv2 0/5] OMAP SMPS regulator driver

2011-07-18 Thread Tony Lindgren
* Tero Kristo t-kri...@ti.com [110713 06:56]:
 Hello,
 
 Based on the comments for the previous version of this set, I implemented
 a regulator driver for the OMAP SMPS now. It could actually be moved under
 arch/arm/mach-omap2/ directory instead of drivers/regulator, I think it
 should work from there also. This would also require less hacking for the
 header files. Any thoughts on this?

If it's a driver it should be under drivers/ then.

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv2 0/5] OMAP SMPS regulator driver

2011-07-14 Thread Tero Kristo
On Thu, 2011-07-14 at 02:22 +0200, Hilman, Kevin wrote:
 Hi Tero,
 
 Tero Kristo t-kri...@ti.com writes:
 
  Based on the comments for the previous version of this set, I implemented
  a regulator driver for the OMAP SMPS now. 
 
 Could you rebase this on my pm-wip/voltdm branch where I've started the
 work to separate out the VC/VP layers into their own files.
 

I'll do this for next version.

 I've just rebased that branch on top of current l-o master, so it also
 includes all the PRCM core code changes queued for v3.1.
 
 Thanks,
 
 Kevin



Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. 
Kotipaikka: Helsinki
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCHv2 0/5] OMAP SMPS regulator driver

2011-07-13 Thread Tero Kristo
Hello,

Based on the comments for the previous version of this set, I implemented
a regulator driver for the OMAP SMPS now. It could actually be moved under
arch/arm/mach-omap2/ directory instead of drivers/regulator, I think it
should work from there also. This would also require less hacking for the
header files. Any thoughts on this?

-Tero


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. 
Kotipaikka: Helsinki
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv2 0/5] OMAP SMPS regulator driver

2011-07-13 Thread Kevin Hilman
+Paul

Tero Kristo t-kri...@ti.com writes:

 Based on the comments for the previous version of this set, I implemented
 a regulator driver for the OMAP SMPS now. It could actually be moved under
 arch/arm/mach-omap2/ directory instead of drivers/regulator, I think it
 should work from there also. This would also require less hacking for the
 header files. Any thoughts on this?

Actually, I'd prefer it stay in drivers/regulator.  We're trying to move
driver-type stuff out of arch/arm/* into the right place in drivers/*.
In fact, I wonder if our VP/VC layers might better live under
drivers/regulator also.

I'd appreciate any input from Mark/Liam on how to organize things.

For some background, see Figures 3-75 and 3-76 in the OMAP4430 Public
TRM[1].  The SMPSs are physically on an external PMIC, but all the
control is typically done via on-chip resources: voltage processor (VP),
voltage controller (VC).  There's also an optional SmartReflex (SR)
block involved which can drive the VP.  I'm not as familiar with other
non-OMAP SoCs, but I don't imagine this is unique to OMAP.

Currently, we have separate drivers for VC, VP and SR in
arch/arm/mach-omap2.  In mainline, these are currently more like
libraries than drivers and are a bit hackish and interwoven with each
other.  We're currently separating these out into separate VC, VP and SR
layers[2], and I'm wondering exactly how we should structure this, and
where they should live under drivers/*.

What Paul and I have discussed so far is that SR should just be
implemented as a sensor under hwmod.  For VC/VP, I think it makes the
most sense that these be part of drivers/regulator someplace.  In this
series, the proposed driver is just small shell that calls the VP
functions.  

Mark/Liam, are you OK with having some helper libraries in
drivers/regulator?  I'm thinking specifically of our VC/VP layers (see
arch/arm/mach-omap2/vc*.c and vp*.c here in my pm-wip/voltdm branch[2].)

So far, I'm just brainstorming on how to cleanup/restructure this stuff,
so any advice from you guys would be appreciated.

Thanks,

Kevin

[1] http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vU.zip
[2] latest are in pm-wip/voltdm branch of my git tree
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv2 0/5] OMAP SMPS regulator driver

2011-07-13 Thread Mark Brown
On Wed, Jul 13, 2011 at 12:00:37PM -0700, Kevin Hilman wrote:

 Actually, I'd prefer it stay in drivers/regulator.  We're trying to move
 driver-type stuff out of arch/arm/* into the right place in drivers/*.
 In fact, I wonder if our VP/VC layers might better live under
 drivers/regulator also.

Well, if they don't look hideous in the API then sure.  I'd guess it's
probably a case of lifting the implementation APIs that Tero's driver is
calling up into the regulator driver he's writing.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv2 0/5] OMAP SMPS regulator driver

2011-07-13 Thread Kevin Hilman
Mark Brown broo...@opensource.wolfsonmicro.com writes:

 On Wed, Jul 13, 2011 at 12:00:37PM -0700, Kevin Hilman wrote:

 Actually, I'd prefer it stay in drivers/regulator.  We're trying to move
 driver-type stuff out of arch/arm/* into the right place in drivers/*.
 In fact, I wonder if our VP/VC layers might better live under
 drivers/regulator also.

 Well, if they don't look hideous in the API then sure.  I'd guess it's
 probably a case of lifting the implementation APIs that Tero's driver is
 calling up into the regulator driver he's writing.

Basically, yes.  But it also would mean dragging the rest of the VC/VP
APIs along as well.

I'll work in this direction and hopefully have some better RFC type code
to show soonish.

Thanks,

Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv2 0/5] OMAP SMPS regulator driver

2011-07-13 Thread Kevin Hilman
Hi Tero,

Tero Kristo t-kri...@ti.com writes:

 Based on the comments for the previous version of this set, I implemented
 a regulator driver for the OMAP SMPS now. 

Could you rebase this on my pm-wip/voltdm branch where I've started the
work to separate out the VC/VP layers into their own files.

I've just rebased that branch on top of current l-o master, so it also
includes all the PRCM core code changes queued for v3.1.

Thanks,

Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html