From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/9] usb: chipidea: ci13xxx_imx: add 2nd and 3rd clock to support imx5x and newer
Date: Tue, 27 Nov 2012 08:34:22 +0100 [thread overview]
Message-ID: <20121127073422.GJ10369@pengutronix.de> (raw)
In-Reply-To: <20121127065026.GA18593@nchen-desktop>
On Tue, Nov 27, 2012 at 02:50:26PM +0800, Peter Chen wrote:
> On Mon, Nov 26, 2012 at 11:22:32AM +0100, Sascha Hauer wrote:
> > On Mon, Nov 26, 2012 at 05:29:31PM +0800, Peter Chen wrote:
> > > On Wed, Nov 14, 2012 at 05:19:03PM +0100, Michael Grzeschik wrote:
> > > > This patch adds support for a second and third clock to the chipidea driver. On
> > > > modern freescale ARM cores like the imx51, imx53 and imx6q three clocks ("ahb",
> > > > "ipg" and "per") must be enabled in order to access the USB core.
> > > >
> > > > In the original driver, the clock was requested without specifying the
> > > > connection id, further all mainline ARM archs with support for the chipidea
> > > > core (imx23, imx28) register their USB clock without a connection id.
> > > >
> > > > This patch first renames the existing clk variable to clk_ahb. The connection
> > > > id "ahb" is added to the devm_clk_get() call. Then the clocks "ipg" and "per"
> > > > are requested. As all archs don't specify a connection id, all clk_get return
> > > > the same clock. This ensures compatibility to existing USB support and adds
> > > > support for imx5x at the same time.
> > > >
> > > > This patch has been tested on imx28 and on imx53 with seperate "ahb", "ipg"
> > > > and "per" clocks.
> > > mx23, mx28, and mx6q has the same usb clock sources and different with
> > > mxc (mx5x, mx3x).
> > >
> > > I am not sure which method is better:
> > > - Add dummy clock at clock.c
> > > - Add platform information(id_table or something similar) at driver.
> > >
> > > Add dummy clock may confuse some users, for example, mx6q has no
> > > "per" and "ipg" clock at all.
> >
> > The general idea is: The USB core has different input clocks. The driver
> > has to be provided with these input clocks. When i.MX6 does not have
> > these clocks, it only means that this SoC has no software controllable
> > gates for these clocks, thus they are not documented. Still this SoC
> > has these clocks.
> > This way we can describe the differences between the SoC purely on SoC
> > level without bothering the driver.
> > You might want to ask your hardware guys to get more information what
> > input clocks the USB core actually has, there actually is a lot of
> > guesswork in it due to missing/inconsistent/confusing documentation.
> Discussed with USB IC module owner, some feedback like below:
> - You are correct, the input clock for controller is always same, there
> are three sources:
> - ahb
> - xcvr_clk
> - xcvr_ser_clk
> - ahb: the source is the system ipg and ahb source, but for usb subsystem,
> there is NO separate control for ipg and ahb, there is only one bit
> to control ipg and ahb clock together, just like we say usboh3_ipg_ahb bit
> at CCM for mx51. The USB controller internal will have two clocks, one for
> ipg (visit register), and the other is ahb (access DDR).
> From the system point, we only need to control usboh3_ipg_ahb,
> so, this clock is better as "usb_ahb". "ipg" clock for usb may only the
> system ipg clock.
The i.MX27 has separate gates for ipg (PCCR1[25]) and ahb PCCR1[11])
>
> -xcvr_clk: it is the phy output clk, the software can't control it,
> (for mx28/mx6q, it can be controlled from phy controller), the software
> can only choose the PHY clk source.
>
> -xcvr_ser_clk, it is used at serial phy mode, we need it as the default
> phy mode is serial.
> I find we take it as "usb_per" at mx5 platform, but this xcvr_ser_clk is
> fixed (60M), and can't be adjusted (it is not different with 54M TLL clock).
>
> So in order to consolidate i.mx usb clock, do you think below definitions
> are ok:
> usb_ahb: ahb clock used to visit register and access DDR
> usb_ipg: system ipg clock (mx28 usb no ipg clock)
> usb_per: serial phy clock, it is useless if serial phy is not supported, eg mx28, mx6q.
> usb_phy: phy clock source, either from 24M or PLL.
>
> So, in order to align with kinds of platforms, I suggest:
> If the clock exists and share the same bit at CCM with others
> (like usb_ahb and usb_ipg at some platforms), give the same clock num
> but different connection id.
Yes.
> If the clock does not exists, just give a dummy clock but with
> connection id (like usb_per at imx6q).
Yes.
Thanks for the informations, it's good to be able to get feedback from
the hardware people.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2012-11-27 7:34 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-14 16:19 [PATCH 0/9] chipidea fixes and features Michael Grzeschik
2012-11-14 16:19 ` [PATCH 1/9] usb: chipidea: pci: mark platformdata as static and __devinitdata Michael Grzeschik
2012-11-16 10:06 ` Alexander Shishkin
2012-11-16 10:17 ` Marc Kleine-Budde
2012-11-16 11:41 ` Alexander Shishkin
2012-11-16 12:02 ` Greg KH
2012-11-14 16:19 ` [PATCH 2/9] usb: chipidea: ci13xxx_imx: add 2nd and 3rd clock to support imx5x and newer Michael Grzeschik
2012-11-26 9:29 ` Peter Chen
2012-11-26 10:22 ` Sascha Hauer
2012-11-27 6:50 ` Peter Chen
2012-11-27 7:34 ` Sascha Hauer [this message]
2012-11-14 16:19 ` [PATCH 3/9] usb: chipidea: ci13xxx-imx: create dynamic platformdata Michael Grzeschik
2012-11-16 10:14 ` Alexander Shishkin
2012-11-16 10:19 ` Marc Kleine-Budde
2012-11-16 12:06 ` Alexander Shishkin
2012-11-14 16:19 ` [PATCH 4/9] usb: chipidea: ci13xxx-imx: add "dr_mode" property to device tree bindings Michael Grzeschik
2012-11-16 11:53 ` Alexander Shishkin
2012-11-16 11:55 ` Marc Kleine-Budde
2012-11-26 9:46 ` Peter Chen
2012-11-29 12:54 ` Alexander Shishkin
2012-11-14 16:19 ` [PATCH 5/9] usb: add phy connection by phy-mode Michael Grzeschik
2012-11-16 9:25 ` Alexander Shishkin
2012-11-16 11:28 ` Felipe Balbi
2012-11-16 11:31 ` Felipe Balbi
2012-11-16 11:44 ` Marc Kleine-Budde
2012-11-16 13:41 ` Felipe Balbi
2012-11-16 14:32 ` Marc Kleine-Budde
2012-11-26 9:56 ` Peter Chen
2012-11-14 16:19 ` [PATCH 6/9] usb: chipidea: add PTW and PTS handling Michael Grzeschik
2012-11-16 12:18 ` Alexander Shishkin
2012-11-16 12:45 ` Alexander Shishkin
2012-11-16 13:16 ` Michael Grzeschik
2012-11-16 13:34 ` Alexander Shishkin
2012-11-16 13:57 ` Michael Grzeschik
2012-11-16 14:06 ` Alexander Shishkin
2012-11-16 14:46 ` Matthieu CASTET
2012-11-16 15:39 ` Alexander Shishkin
2012-11-21 15:57 ` Michael Grzeschik
2012-11-21 16:06 ` Matthieu CASTET
2012-11-27 1:12 ` Peter Chen
2012-11-27 9:54 ` Michael Grzeschik
2012-11-28 1:26 ` Peter Chen
2012-11-14 16:19 ` [PATCH 7/9] usb: chipidea: udc: add force-full-speed option Michael Grzeschik
2012-11-16 12:51 ` Alexander Shishkin
2012-11-16 14:53 ` Matthieu CASTET
2012-11-14 16:19 ` [PATCH 8/9] usb: chipidea: udc: remove unlocked ep_queue which can lead to an race Michael Grzeschik
2012-11-16 12:55 ` Alexander Shishkin
2012-11-14 16:19 ` [PATCH 9/9] usb: chipidea: udc: configure iso endpoints Michael Grzeschik
2012-11-14 18:04 ` Sergei Shtylyov
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=20121127073422.GJ10369@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).