Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4 |
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
- From: Konstantin Baydarov <kbaidarov@xxxxxxxxxxxxx>
- Date: Thu, 31 May 2012 16:06:00 +0400
- Cc: Eduardo Valentin <eduardo.valentin@xxxxxx>, kishon@xxxxxx, santosh.shilimkar@xxxxxx, tony@xxxxxxxxxxx, paul@xxxxxxxxx, balbi@xxxxxx, amit.kucheria@xxxxxxxxxx, linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, linux-omap@xxxxxxxxxxxxxxx, amit.kachhap@xxxxxxxxxx
- In-reply-to: <4FC5E7DE.2060905@ti.com>
- User-agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
Hi.
On 05/30/2012 01:26 PM, Cousson, Benoit wrote:
> On 5/30/2012 11:05 AM, Konstantin Baydarov wrote:
>> 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).
>
> ...
>
>>>> 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.
>
> OK, I got your point, but in that case we could potentially define a omap4460.dtsi 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".
>
> Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-(
>
> The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460.
>
> The bitfield layout in that register is:
>
> IP_REV_MAJOR: 8..10
> IP_REV_CUSTOM: 6..7
> IP_REV_MINOR: 0..5
The value of CONTROL_GEN_CORE_REVISION register on my panda board(4430) is:
CONTROL_GEN_CORE_REVISION: 0x40000900
CONTROL_GEN_CORE_HWINFO: 0x0
Eduardo, could you check CONTROL_GEN_CORE_REVISION on your 4460 board.
BR,
Konstantin Baydarov.
>
> Regards,
> Benoit
--
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
[Linux Arm (vger)]
[ARM Kernel]
[ARM MSM]
[Linux Tegra]
[Maemo Users]
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Photo]
[Yosemite News]
[Yosemite Photos]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]