From patchwork Wed Jun 26 15:33:26 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sebastian Andrzej Siewior X-Patchwork-Id: 2786691 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 83DF2C0AB1 for ; Wed, 26 Jun 2013 15:33:35 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D1CC2202AE for ; Wed, 26 Jun 2013 15:33:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 670C2202AB for ; Wed, 26 Jun 2013 15:33:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751646Ab3FZPd1 (ORCPT ); Wed, 26 Jun 2013 11:33:27 -0400 Received: from www.linutronix.de ([62.245.132.108]:35110 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751498Ab3FZPd0 (ORCPT ); Wed, 26 Jun 2013 11:33:26 -0400 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.72) (envelope-from ) id 1Urrio-0006R7-0e; Wed, 26 Jun 2013 17:33:26 +0200 Date: Wed, 26 Jun 2013 17:33:26 +0200 From: Sebastian Andrzej Siewior To: Benoit Cousson Cc: Felipe Balbi , linux-usb@vger.kernel.org, linux-omap@vger.kernel.org Subject: [RFC] am33xx: create child nodes for the two musb controllers Message-ID: <20130626153325.GA24075@linutronix.de> MIME-Version: 1.0 Content-Disposition: inline X-Key-Id: 97C4700B X-Key-Fingerprint: 09E2 D1F3 9A3A FF13 C3D3 961C 0688 1C1E 97C4 700B User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP I've been thinkig about creating two child nodes for the independent musb controllers on the am33. I've been thinking about the following: Acked-by: Felipe Balbi 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>; /* 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. Sebastian -- 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