From: "Raphaël Assénat" <raph@8d.com>
To: "Premi, Sanjeev" <premi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>, Paul Walmsley <paul@pwsan.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: AM3505/3517 support
Date: Wed, 06 Jul 2011 09:51:49 -0400 [thread overview]
Message-ID: <4E146875.1060802@8d.com> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024D91AB0A@dbde02.ent.ti.com>
On 06/07/11 04:54 AM, Premi, Sanjeev wrote:
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org
>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tony Lindgren
>> Sent: Wednesday, July 06, 2011 12:26 PM
>> To: Raphaël Assénat; Paul Walmsley
>> Cc: linux-omap@vger.kernel.org
>> Subject: Re: AM3505/3517 support
>>
>> * Raphaël Assénat <raph@8d.com> [110705 07:30]:
>>> On 05/07/11 07:19 AM, Tony Lindgren wrote:
>>>> * Raphaël Assénat <raph@8d.com> [110704 12:51]:
>>>>>
>>>>> The am3505 is apparently so similar to the 3430 that it
>> was treated as such
>>>>> (omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1).
>> There are however a
>>>>> few differences that need to be addressed. I have
>> therefore created a new
>>>>> CHIP_IS and patched clocks, hwmod and power management
>> related files
>>>>> consequently. My system now boots until it complains
>> that it is unable
>>>>> to mount its root filesystem.
>>>>
>>>> Can you please describe where you need CHIP_IS for
>> am3505? It seems that
>>>> your patches just enable the same CHIP_IS_OMAP3430
>> features for am3505 too?
>>>
>>> Actually it's only needed for the 3505/3517 specific UART 4
>> which should
>>> not be registered on real OMAP3430's. (see struct omap_hwmod
>>> am35xx_uart4_hwmod; in omap_hwmod_3xxx_data.c)
>>>
>>> But there are also cases where OMAP3430 hwmods must not be
>> registered
>>> on AM35xx. For instance, omap3xxx_timer12_hwmod since timer12 does
>>> not exist general purpose AM3505's.
>>
>> Sounds like we should be able to handle both uart and
>> gptimer12 the same way
>> as we'll be handling the hwmod reset for special cases like
>> gptimer12 for
>> secure mode. So addding Paul to Cc.
>>
>> Basically we can have a am35xx specific arch_initcall that
>> sets the special
>> flags for these devices like noreset, disabled or unavailable.
>>
>> In this case we would just set some devices as unavailable on am35xx.
>
> [sp] AM35x is already supported in the kernel. Specifically for the
> changes being discussed, see this commit:
>
> commit 3cc4a2fc2ed7727828f410ab092111cb56cefd61
> Author: Ranjith Lohithakshan <ranjithl@ti.com>
> Date: Wed Feb 24 12:05:55 2010 -0700
>
> AM35xx: Add clock support for new modules on AM35xx
>
> I believe this patch already contains most AM35xx specific changes
> related to clocks.
Indeed, most of these changes are present in the current kernel. But right now,
it does not work as-is. Only a few things are missing and that's what I'm
trying to address. I'll try Tony's suggestion. It should yield a much smaller
patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-07-06 13:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-04 19:29 AM3505/3517 support Raphaël Assénat
2011-07-05 9:59 ` Premi, Sanjeev
2011-07-06 13:59 ` Raphaël Assénat
2011-07-06 16:15 ` Premi, Sanjeev
2011-07-05 11:19 ` Tony Lindgren
2011-07-05 14:35 ` Raphaël Assénat
2011-07-06 6:56 ` Tony Lindgren
2011-07-06 8:54 ` Premi, Sanjeev
2011-07-06 13:51 ` Raphaël Assénat [this message]
2011-07-07 9:14 ` Paul Walmsley
2011-07-07 11:54 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E146875.1060802@8d.com \
--to=raph@8d.com \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=premi@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox