All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.