From: "Cousson, Benoit" <b-cousson@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Kyle Manna <kyle.manna@fuel7.com>,
Ranjith Lohithakshan <ranjithl@ti.com>,
"Mark A. Greer" <mgreer@animalcreek.com>
Subject: Re: [PATCH 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
Date: Fri, 11 May 2012 11:31:15 +0200 [thread overview]
Message-ID: <4FACDC63.7060605@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1205110316500.3201@utopia.booyaka.com>
On 5/11/2012 11:22 AM, Paul Walmsley wrote:
> Hi Benoît
>
> On Fri, 11 May 2012, Cousson, Benoit wrote:
>
>> I do not have any clue about that chip, but is this clock really what it is
>> supposed to be? I mean, isn't the uart1_fck the parent of all the UART fck or
>> something like that. Don't we just have an issue becasue the clock names are
>> not accurate?
>
> I guess that's what I'm trying to find out.
>
> According to the AM3517 TRM rev. B (SPRUGR0B) Figure 14-20 "UART
> Functional Integration" and Table 14-11 "UART Clocks", all of the UARTs
> appear to have independent functional clocks. The table even mentions a
> CM_FCLKEN1_CORE.EN_UART4 bit. But the PRCM chapter of this TRM doesn't
> mention that at all. So the documentation is not too useful here.
>
> On the rest of the OMAPs, as far as I know, the UART clocks are all
> separate.
In fact, not really. The same PER_48M_GFCLK clock is used for every UART
instances in OMAP4. We do have a separate modulemode for each UART but
as far as clocks are concerned, the source clock is the same.
Regards,
Benoit
--
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
WARNING: multiple messages have this Message-ID (diff)
From: b-cousson@ti.com (Cousson, Benoit)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
Date: Fri, 11 May 2012 11:31:15 +0200 [thread overview]
Message-ID: <4FACDC63.7060605@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1205110316500.3201@utopia.booyaka.com>
On 5/11/2012 11:22 AM, Paul Walmsley wrote:
> Hi Beno?t
>
> On Fri, 11 May 2012, Cousson, Benoit wrote:
>
>> I do not have any clue about that chip, but is this clock really what it is
>> supposed to be? I mean, isn't the uart1_fck the parent of all the UART fck or
>> something like that. Don't we just have an issue becasue the clock names are
>> not accurate?
>
> I guess that's what I'm trying to find out.
>
> According to the AM3517 TRM rev. B (SPRUGR0B) Figure 14-20 "UART
> Functional Integration" and Table 14-11 "UART Clocks", all of the UARTs
> appear to have independent functional clocks. The table even mentions a
> CM_FCLKEN1_CORE.EN_UART4 bit. But the PRCM chapter of this TRM doesn't
> mention that at all. So the documentation is not too useful here.
>
> On the rest of the OMAPs, as far as I know, the UART clocks are all
> separate.
In fact, not really. The same PER_48M_GFCLK clock is used for every UART
instances in OMAP4. We do have a separate modulemode for each UART but
as far as clocks are concerned, the source clock is the same.
Regards,
Benoit
next prev parent reply other threads:[~2012-05-11 9:32 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-10 17:29 [PATCH 0/3] ARM: OMAP: AM35xx: fix some boot warnings with AM3505/3517 Paul Walmsley
2012-05-10 17:29 ` Paul Walmsley
2012-05-10 17:29 ` [PATCH 1/3] ARM: OMAP AM35xx: clock and hwmod data: fix AM35xx HSOTGUSB hwmod Paul Walmsley
2012-05-10 17:29 ` Paul Walmsley
2012-05-10 19:08 ` Mark A. Greer
2012-05-10 19:08 ` Mark A. Greer
2012-05-10 17:29 ` [PATCH 2/3] ARM: OMAP AM35xx: clock and hwmod data: fix UART4 data Paul Walmsley
2012-05-10 17:29 ` Paul Walmsley
2012-05-10 19:36 ` Mark A. Greer
2012-05-10 19:36 ` Mark A. Greer
2012-05-10 17:29 ` [PATCH 3/3] ARM: OMAP: AM35xx: fix UART4 softreset Paul Walmsley
2012-05-10 17:29 ` Paul Walmsley
2012-05-10 19:37 ` Mark A. Greer
2012-05-10 19:37 ` Mark A. Greer
2012-05-11 8:48 ` Cousson, Benoit
2012-05-11 8:48 ` Cousson, Benoit
2012-05-11 9:22 ` Paul Walmsley
2012-05-11 9:22 ` Paul Walmsley
2012-05-11 9:31 ` Cousson, Benoit [this message]
2012-05-11 9:31 ` Cousson, Benoit
2012-05-11 9:35 ` Paul Walmsley
2012-05-11 9:35 ` Paul Walmsley
2012-05-11 9:41 ` Cousson, Benoit
2012-05-11 9:41 ` Cousson, Benoit
2012-05-11 10:36 ` Paul Walmsley
2012-05-11 10:36 ` Paul Walmsley
2012-05-10 18:41 ` [PATCH 0/3] ARM: OMAP: AM35xx: fix some boot warnings with AM3505/3517 Mark A. Greer
2012-05-10 18:41 ` Mark A. Greer
2012-05-10 18:46 ` Paul Walmsley
2012-05-10 18:46 ` Paul Walmsley
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=4FACDC63.7060605@ti.com \
--to=b-cousson@ti.com \
--cc=kyle.manna@fuel7.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=mgreer@animalcreek.com \
--cc=paul@pwsan.com \
--cc=ranjithl@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.