lkml.org 
[lkml]   [2012]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
Hi Jean,

>
> The initial motivation is to provide a generic framework for this type
> of drivers, by cleaning up the current OMAP code and by providing as
> much generic code as possible.
>
> Cf. the patch sets I submitted before this very one:
> - the SR code clean-up [1], which is needed to make the code ready for
> the integration of new features,
> - the SR class support [2], which is needed for new SR classes to be
> implemented.
>
> From the maintainer point of view it made more sense to move the code
> before cleaning it up and so it should happen before [1] and [2].
> The result is that [1] and [2] will need to be rebased when the move
> is accepted and merged in.
>
> [1] http://marc.info/?l=linux-omap&m=133055488908132&w=2
> [2] http://marc.info/?l=linux-omap&m=133163445926544&w=2

I am going through your patches and including some wiki pages. I
understand the SR can be connected in two ways - intelligent and dumb :)
For intelligent I mean you just configure SR and it will and program
PMIC, whereas in dumb scenarios application processor gets the
notification and then it goes and writes into PMIC based on some
floor/ceiling values. In the first case not much of apps. s/w but in the
later case whole lot.

>
>>>
>>> Where will you put that otherwise?
>>
>>
>> Couple of suggestions:
>>
>> drivers/platform/omap/avs?
>> drivers/misc/omap/avs?
>>
>> I prefer first one.
> Those paths are for OMAP specific code and not for a generic framework.
>
>>>
>>> IIRC, David Brownell was referring to the rule of three for such case.
>>> Meaning that it worth having a generic fmwk when at least three
>>> different drivers are doing the same kind of things.
>
> Do OMAP v1 and OMAP v2 implementations count as 2 drivers? ;-)
> More seriously, the OMAP code for SmartReflex is far from complete in
> mainline. There is a plan to provide the following features:
> - OMAP v1 IP,
> - OMAP v2 IP,
> - class 1.5,
> - class 3,
> - class 3.5,
> - and more support for the upcoming chipsets.

I don't understand much of these versions right now, but hopefully after
going through all these docs. My only contention point is to not create
any directory into the drivers/power, unless it is generic fwk and then
build up "client" drivers on top of it. Meanwhile we could move this
driver into above options as I have suggested.

---Trilok Soni

--
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.


\
 
 \ /
  Last update: 2012-04-05 11:37    [W:1.320 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site