All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benoit Cousson <b-cousson@ti.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Felipe Balbi <balbi@ti.com>,
	linux-usb@vger.kernel.org, linux-omap@vger.kernel.org
Subject: Re: [RFC] am33xx: create child nodes for the two musb controllers
Date: Thu, 27 Jun 2013 13:23:59 +0200	[thread overview]
Message-ID: <51CC20CF.2080103@ti.com> (raw)
In-Reply-To: <20130626153325.GA24075@linutronix.de>

Hi Sebastian,

On 06/26/2013 05:33 PM, Sebastian Andrzej Siewior wrote:
> I've been thinkig about creating two child nodes for the independent musb
> controllers on the am33. I've been thinking about the following:
> 
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 8e1248f..6aa9506 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -326,21 +326,78 @@
>  			status = "disabled";
>  		};
>  
>  		usb@47400000 {
>  			compatible = "ti,musb-am33xx";
> -			reg = <0x47400000 0x1000	/* usbss */
> -			       0x47401000 0x800		/* musb instance 0 */
> -			       0x47401800 0x800>;	/* musb instance 1 */
> -			interrupts = <17		/* usbss */
> -				      18		/* musb instance 0 */
> -				      19>;		/* musb instance 1 */
> -			multipoint = <1>;
> -			num-eps = <16>;
> -			ram-bits = <12>;
> -			port0-mode = <3>;
> -			port1-mode = <3>;
> -			power = <250>;
> +			reg = <0x47400000 0x1000>;	/* usbss */
> +			interrupts = <17>;		
BTW, why do have so many DMA compared to the previous version?
/* usbss */
>  			ti,hwmods = "usb_otg_hs";
> +
> +			usb0@0x47401000 {
> +				reg = <0x47401000 0x800>;	/* musb instance 0 */
> +				interrupts = <18>;		/* musb instance 0 */
> +				multipoint = <1>;
> +				num-eps = <16>;
> +				ram-bits = <12>;
> +				port-mode = <3>;
> +				power = <250>;
> +
> +				phys = <&nopphy0>;
> +				dmas = <&cppi41dma 0
> +					&cppi41dma 1
> +					&cppi41dma 2
> +					&cppi41dma 3
> +					&cppi41dma 4
> +					&cppi41dma 32
> +					&cppi41dma 34
> +					&cppi41dma 36
> +					&cppi41dma 38
> +					&cppi41dma 40>;
> +				dma-names = "rx1", "rx2", "rx3", "rx4", "rx5",
> +					    "tx1", "tx2", "tx3", "tx4", "tx5";
> +			};
> +
> +			usb0@0x47401800 {
> +				reg = <0x47401800 0x800>;	/* musb instance 1 */
> +				interrupts = <19>;		/* musb instance 1 */
> +				multipoint = <1>;
> +				num-eps = <16>;
> +				ram-bits = <12>;
> +				port-mode = <3>;
> +				power = <250>;
> +
> +				phys = <&nopphy1>;
> +				dmas = <&cppi41dma 0
> +					&cppi41dma 1
> +					&cppi41dma 2
> +					&cppi41dma 3
> +					&cppi41dma 4
> +					&cppi41dma 62
> +					&cppi41dma 64
> +					&cppi41dma 66
> +					&cppi41dma 68
> +					&cppi41dma 70>;
> +				dma-names = "rx1", "rx2", "rx3", "rx4", "rx5",
> +					    "tx1", "tx2", "tx3", "tx4", "tx5";
> +			};
> +		};
> 
> Please keep in mind that his is not a proper patch it should point out
> what I have in mind.
> This would easy the for instance the dma channel assignment. Also, it will
> move back to the port-mode property instead of portX-mode one which it has
> now. This is kind of confusing since it is not a root hub or anything like
> that it is a complete musb controller. Plus for the phys property could
> easily take the one avaible and would not require which instance it
> really it is.

I don't know the HW in detail, but that looks indeed much better and
seems to reflect the partitioning with multiple instances accurately.

If Felipe is OK with that partitioning, I'll take it.

Thanks,
Benoit



  parent reply	other threads:[~2013-06-27 11:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-26 15:33 [RFC] am33xx: create child nodes for the two musb controllers Sebastian Andrzej Siewior
     [not found] ` <20130626153325.GA24075-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
2013-06-27  6:51   ` Felipe Balbi
2013-06-27  7:31     ` Sebastian Andrzej Siewior
     [not found]       ` <51CBEA56.4010806-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
2013-06-27  7:42         ` Felipe Balbi
2013-06-27 11:23 ` Benoit Cousson [this message]
2013-06-27 11:44   ` Sebastian Andrzej Siewior
2013-06-27 13:22   ` Felipe Balbi

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=51CC20CF.2080103@ti.com \
    --to=b-cousson@ti.com \
    --cc=balbi@ti.com \
    --cc=bigeasy@linutronix.de \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-usb@vger.kernel.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 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.