public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Shawn Guo <shawn.guo@freescale.com>
To: Chen Peter-B29397 <Peter.Chen@freescale.com>
Cc: Philippe Reynes <tremyfr@gmail.com>,
	"Linux-kernel@vger.kernel.org" <Linux-kernel@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"gwenhael.goavec-merou@trabucayre.com" 
	<gwenhael.goavec-merou@trabucayre.com>
Subject: Re: [RFC] usb issue on imx27: 3 clocks are needed
Date: Mon, 18 Aug 2014 19:48:53 +0800	[thread overview]
Message-ID: <20140818114850.GJ2114@dragon> (raw)
In-Reply-To: <782c806acb464f5781deb32e94548882@BN1PR0301MB0772.namprd03.prod.outlook.com>

On Mon, Aug 18, 2014 at 06:35:53PM +0800, Chen Peter-B29397 wrote:
>  
> > On Mon, Aug 18, 2014 at 05:00:59PM +0800, Peter Chen wrote:
> > > On Sat, Aug 16, 2014 at 05:38:30PM +0200, Philippe Reynes wrote:
> > > > Hi all,
> > > >
> > > > i.MX27's usb needs three clocks (usb_ipg_gate, usb_ahb_gate and
> > > > usb_div) but the current chipidea driver implementation, and
> > > > devicetree, provides only ipg and ahb. Consequently, if the
> > > > bootloader don't enable the last one, the kernel will crash.
> > > >
> > > > Our approach/idea is to add a second, optionnal, clock in
> > > > ci_hdrc_imx.c with 'per' name in devicetree  and to add  clock name
> > 'main_clk' for mandatory clock.
> > > > This approach it correct? Or an other approach seems better?
> > > > Thank you very much for your point of view.
> > > >
> > >
> > > It is ok for me to have ipg, ahb and per clocks at driver, but how can
> > > you maintain DT consistent?
> > 
> > Adding new clock as optional one will just maintain the DT compatibility.
> > 
> 
> How to handle node_usb_soc1's clock which is without clk name to consistent with three
> clocks for node_usb_soc2 at driver? Except for adding some platform judge code at
> driver, do you have other solutions?
> 
> node_usb_soc1: {
> 	clocks = <&clks IMX6_CLK_USBOH3>;
> };
> 
> node_usb_soc2: {
> 	clocks = <&clks IMX27_CLK_USBIPG>, <&clks IMX27_CLK_USBOH3>, <&clks IMX27_CLK_USBPER>;
> 	clock-names = "ipg", "ahb", "per";
> };

Oh, what I was talking about is we need to ensure the new kernel
(handling additional clocks) doesn't break old/existing DTB.  That's
what we call DT compatibility.

There is no DT consistency to maintain.  If there is only one clock for
USB on i.MX6 while 3 clocks on i.MX27, that's something USB driver needs
to handle, as clearly these two SoCs have different programming model on
USB device.

Shawn

  reply	other threads:[~2014-08-18 11:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-16 15:38 [RFC] usb issue on imx27: 3 clocks are needed Philippe Reynes
2014-08-16 16:01 ` Fabio Estevam
2014-08-16 16:22   ` Philippe Reynes
2014-08-18  9:00 ` Peter Chen
2014-08-18  9:26   ` Shawn Guo
2014-08-18 10:35     ` Peter Chen
2014-08-18 11:48       ` Shawn Guo [this message]
2014-08-18 11:49       ` gwenhael.goavec
     [not found]         ` <20140819001816.GC2928@peterchendt>
2014-08-19  8:47           ` gwenhael.goavec

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=20140818114850.GJ2114@dragon \
    --to=shawn.guo@freescale.com \
    --cc=Linux-kernel@vger.kernel.org \
    --cc=Peter.Chen@freescale.com \
    --cc=gwenhael.goavec-merou@trabucayre.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=tremyfr@gmail.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