From owner-freebsd-arm@FreeBSD.ORG Sun Feb 17 18:53:57 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1875B5E1 for ; Sun, 17 Feb 2013 18:53:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x229.google.com (ie-in-x0229.1e100.net [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id C160E2DB for ; Sun, 17 Feb 2013 18:53:56 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id 13so6634924iea.0 for ; Sun, 17 Feb 2013 10:53:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=K4TPT6F25Eu95bUAeph4920FIubvdLV30lPtOtZhGs0=; b=HBUeqUJx+DRGGL/6G7ZvNLfGhlC5qyxpiTI1qbfUvOY9mCFHiGFktg9d5FdQBpjZrb ULcVZzlh7J5rvJ07h44K0q/hGdEqrPETyEB559StEuX7KiT9M8gMpUoMrv1aOh7Y7INb PiDZ2LD+QZwcUsCDqIwu2/d7sVMArRCq4ocHb3rpybVjf0DMFF0F9uNVxCcF4/nUGykS fgqQs4uVE7SK55plZvdP9UP4dUh2RtIPHwJhdlJ1KVb/i2EQd1mzIBH+UUzKcb0iz8Yl LrWuOFSUEmU0a/qnvbpXYnFpD2bj3Jvqvx2KWNuFNcHBTMNhLXEjE8+lELowZ4OjG474 BgCw== X-Received: by 10.50.207.39 with SMTP id lt7mr1893864igc.110.1361127236088; Sun, 17 Feb 2013 10:53:56 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id xc3sm7135685igb.10.2013.02.17.10.53.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Feb 2013 10:53:55 -0800 (PST) Sender: Warner Losh Subject: Re: Beaglebone Serial Ports Progress Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <73B8F088-EE5C-471D-AEED-52D4E45153DA@kientzle.com> Date: Sun, 17 Feb 2013 11:53:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9849AAD0-1C71-487D-A0C7-582FAD95FD41@bsdimp.com> References: <511E1A08.4020105@g7iii.net> <5120A7AD.40903@g7iii.net> <73B8F088-EE5C-471D-AEED-52D4E45153DA@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmCNjo008Nj9F4NtK3F/7W3o0PlDuyU9x5f9eaw0CgAYPYiWJLAVG2w4jbCWh6GEE4ad7TR Cc: freebsd-arm@freebsd.org, Damjan Marion X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 18:53:57 -0000 On Feb 17, 2013, at 11:21 AM, Tim Kientzle wrote: >=20 > On Feb 17, 2013, at 1:49 AM, Iain Young wrote: >=20 >> Hi Damjan, >>=20 >> On 15/02/13 16:46, You wrote: >>=20 >>>>=20 >>>> I tried changing 0x1000 for 0x2000, as it seems the next reg is = also >>>> reserved for UART1. No more luck. So, thinking I needed to add it = as an >>>> alias (as UART0 is), I added that, but it still dumped me at the >>>> debugger on boot. >>>>=20 >>>> The only other thing is reg-shift. I must confess, I am a bit blind >>>> here. Not knowing what it actually did I left it as with UART0. I'm >>>> hoping it essentially includes the next register up for UART1, as >>>> while that's listed as "Reserved" in the memory map [Yes, I = consulted >>>> SPRUH73G :)] , it seems to be reserved for UART1, but I am just >>>> guessing (Yes, I know, not good practice when kernel hacking...) >>>>=20 >>>> I've attached the latest version of my patch, the output from the >>>> kernel until it blows up, as well as the trace. Patch is based on >>>> r246610 >>>>=20 >>>> Anyone able to point me in the right direction ? I can't be too far >>>> away, and I can then add UART2-5, and submit an actual working = patch! >>>>=20 >>>=20 >>> It is very likely that clock is disabled for USART1. Problem is that = usart uses >>> standard serial driver which is not requesting clock to be enabled = during the attach >>> by invoking ti_prcm_clk_enable(). >>>=20 >>> Can you try to put following at the end of am335x_prcm_attach()? >>>=20 >>> prcm_write_4(6c, 2); >>>=20 >>>=20 >>> This should be register CM_PER_UART1_CLKCTRL. >>=20 >> That indeed fixed it, and adding the other CLKCTRL registers in a >> similar way enabled them as well. >>=20 >> Have not been able to test fully, as my GPS units are 70 ft away in = the >> shed at the end of the garden, however, my radio clock receivers are = now >> happily twiddling CTS on UARTS3 and 4 (also tested on UART1), so I'm >> pretty sure all UARTS are fine. >>=20 >>=20 >> Before I send the full patch what are the FreeBSD standards wrt the >> above lines in am335x_prcm_attach() ? Should I leave as is ? Create >> a separate function, and call it from am335x_prcm_attach() ? Or do I >> create a #define in the same file, and create functions for each = UART, >> as I see some other clocks do ? >=20 > It would require a little more work but I think the natural > place to put this would be to put >=20 > uart1: serial@48022000 { > ... > clocks =3D "UART1"; > clock-parent =3D <&PRCM>; > }; >=20 > in the FDT (which is a straightforward way of > saying "this device needs the PRCM to turn on > "UART1" clocks) and then figure out how to > actually support it. ;-) >=20 > This is the same issue that we've been discussing > for pinmux, and the above is essentially the same solution > being discussed for pinmux. >=20 > It's not yet clear to me where/how this info should be acted on. > It could actually be handled in the simplebus driver, I > think, without modifying (in this case) the UART driver code > at all. That would need only a standard way for simplebus to > communicate the clock-init string to the designated > clock handler. Yes. We also need to augment our clock support a bit too... In linux = land, which may prove illustrative, you create the clocks as part of the = SoC, associate names in the FDT and then each device requests the proper = clock from their FDT node. There is (or was a few months ago) a move = afoot to make this more automatic by default. > The current handling for interrupt and memory resources > could also be used as a model, though that might > require modifying each driver to manage pinmux and > clock resources. >=20 > The nicest approach might be for simplebus to > handle the clock-init key transparently in > the many cases where there's a single clock and > the driver doesn't need any special management > and then provide a separate internal API for drivers > that want to manage multiple clock modes or enable/disable > clocks dynamically. I rather like this idea, frankly... Warner=