Gopinath, Thara had written, on 09/17/2010 09:57 AM, the following:
[..]
From: Paul Walmsley <paul@xxxxxxxxx>
The OPP layer code should be independent of the PMIC,
introduce the TWL/TPS-specific code out to its own file.
I have been using this code for a while now. I really do not think wee need a separate
file for implementing the vsel to voltage in (uV) and vice versa formulas. Today only voltage
This split introduces a PMIC level abstraction already. Do you have a
suggestion which file it should go to? It is definitely not part of
opp.c, not part of other existing twl files as well. the job of this
file was to introduce conversion routines which can be used by any layer
(voltage layer if need be - it used to be srf and smartreflex before)..
in fact one of your voltage layer patches introduces capability for 6030
as well
http://marc.info/?l=linux-omap&m=128213020927919&w=2
Yes one of my patches has introduces this coz I had no other way
to add OMAP4 support. But I still do not understand why cant these
APIs be implemented in twl-core.c or twl4030-power.c?
Why there? Twl power does regulator operations not conversion
operations. core is not the place either as it is function independent.
Why do you say core is not the place. For me core is exactly
the place. It is the PMIC driver file.
See [1] - they are all generic without a specific domain implementation.
if we are so touchy about the location we want these api implementation,
I guess core might be a compromise enough.. personally even though I
believe core should remain specific functionality independent, I dont
think I have very strong opinions about adding helpers there.. i
would'nt put registration there though.. That should be in board files..
[1]
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=blob;f=drivers/mfd/twl4030-core.c;h=769b34bd48e445880ac0920423d9b73eabaf4cb7;hb=HEAD
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
