On 05/30/2012 12:38 PM, Cousson, Benoit wrote:
> On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
>> Hi, Eduardo.
>>
>> On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
>>> This patch add device tree entries on OMAP4 based boards
>>> for System Control Module (SCM).
>>>
>>> Signed-off-by: Eduardo Valentin<eduardo.valen...@ti.com>
>>> ---
>>> arch/arm/boot/dts/omap4.dtsi | 13 +++++++++++++
>>> 1 files changed, 13 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>>> index 359c497..d2cb392 100644
>>> --- a/arch/arm/boot/dts/omap4.dtsi
>>> +++ b/arch/arm/boot/dts/omap4.dtsi
>>> @@ -272,5 +272,18 @@
>>> ti,hwmods = "mmc5";
>>> ti,needs-special-reset;
>>> };
>>> +
>>> + ctrl_module_core: ctrl_module_core@4a002000 {
>>> + compatible = "ti,omap4-control";
>>> + ti,hwmods = "ctrl_module_core";
>>> + bandgap {
>>> + compatible = "ti,omap4460-bandgap";
>>> + interrupts =<0 126 4>; /* talert */
>>> + ti,tshut-gpio =<86>; /* tshut */
>>> + };
>> I believe that CPU-specific bandgap definition should be moved to bard
>> specific dts.
>
> Mmm, why, since it is CPU specific and not board specific. I has to be in the
> SoC file.
Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if
omap4430 bandgap support will be added to omap-bandgap driver the version of
bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards,
that is why I'm suggesting to move bandgap description to probably board
specific file.
Another solution is to determine bandgap type in driver probe function, but in
that case "ti,omap4460-bandgap" in omap4.dtsi should be replaced to
"ti,omap4-bandgap".
BR,
Konstantin Baydarov.
> Regards,
> Benoit
--
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
