From owner-freebsd-arm@freebsd.org Fri Jan 22 04:43:33 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65893A8DA24 for ; Fri, 22 Jan 2016 04:43:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 22DF71D83 for ; Fri, 22 Jan 2016 04:43:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qg0-x231.google.com with SMTP id b35so49420909qge.0 for ; Thu, 21 Jan 2016 20:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VX2RTLm3uhEiTAhq4mI+RnmSZ7l6izerhrlBLAM6QpA=; b=PNqO8ZQ0fCWbtXDOkQSZi3eVf8IU9OSxdSC8L7e7OJL/fgXY6Z81ZYitP0yJ7hGAkr /wXMY+s5f2B1a7izTxbnMsxzDUwgN/5c5cGYeZGl5VBjIdxWUCAQcS5AfMFGQ3o0Af54 WF2CtrH2hFjdIfmSFYrb15GfMfIu8hMXEPf8AnOGJet4dyaoZIW65qLllyVH9C7X1Ey7 g2WEXk6oPNUMun7MYUeP0ZEbU2VrWNHAzrBuIaRId6hYJ1ang4ag8mnGWZWMU3Vi7G32 NRDN1ExClBoD6GJSh6lAaV4QcLtbqSn7i/hNTH3KcZbhIOirR0aRg7Wj9NB3ENKt4sPw plpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VX2RTLm3uhEiTAhq4mI+RnmSZ7l6izerhrlBLAM6QpA=; b=FWFnxw7axPebedNOIc/6xBw+eIn5qOwE9NUf8/qMJ7mFb1NijlTKRNHJLPfW8qRUKv tthjgUTX7uji2GdKxFYW8qVzivbo3jCoxurFCmDeMXTNfbCVzdJN1oZPMYTwYexP6uHw 5gTpmegvDhgngsiNM6D/29GzxLc2vafVIYsmHCeNdS9VRnxqIO6xvwd0FIQMd/Zvug12 eYF/Qx+Ftt4sTZ9OHmqXpJn4Xo0OBzrRSOratcfhGWkpM7vXDPvjlGh4bD45IlX9ldLc 5+FGL/+2mPeBPvY/Nx6kLwceU9Y5cLGSuYzAalfcXINwzUKng47hKcW3e2AnoyVaRwSO qfwA== X-Gm-Message-State: AG10YOSMhuIMh+dSINWdfk77oSggjv5pAls3/ACvBiojQUWyGzSsVeYzC8w9qxQ7Sot7aV3dI/6VO9vwWabAZg== MIME-Version: 1.0 X-Received: by 10.140.255.8 with SMTP id a8mr1281899qhd.20.1453437812119; Thu, 21 Jan 2016 20:43:32 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.30.166 with HTTP; Thu, 21 Jan 2016 20:43:32 -0800 (PST) X-Originating-IP: [2601:280:4900:3700:8400:bf66:d6e:dfb1] In-Reply-To: References: <2AB9D6E1-BFF8-4EEE-B366-C980B72C4779@gmail.com> Date: Thu, 21 Jan 2016 21:43:32 -0700 X-Google-Sender-Auth: CfYMvnogoZGSwqm1UEXE6tVYgS4 Message-ID: Subject: Re: SPI geom_flashmap/fdt_slicer support, FDT 'resets=' support and a move of ohci_fdt.c From: Warner Losh To: Adrian Chadd Cc: Stanislav Galabov , "freebsd-arm@freebsd.org" , "freebsd-mips@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 04:43:33 -0000 On Thu, Jan 21, 2016 at 8:35 PM, Adrian Chadd wrote: > On 18 January 2016 at 06:49, Stanislav Galabov wrote= : > > Hi Warner, > > > > I was thinking resets could help in general, not specifically in the > case of trying to implement a generic ohci_fdt driver. > > > > As I already mentioned to you off-list (and in order for this message t= o > possibly make some more sense), I saw that Linux makes use of the =E2=80= =98resets=E2=80=99 > property and looked at the documentation for it: > > > https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bi= ndings/reset/reset.txt > < > https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bi= ndings/reset/reset.txt > > > > > > For example, with the work I am currently doing on Ralink/Mediatek > support, I have over 10 different chips in the same family, that have ver= y > similar peripheral blocks, but their clocks and resets are controlled via > different bits in one of the SysCtl registers (the register itself is at > the same offset within the SysCtl block of each chip). So I may have chip= X > which has its USB (for example) reset controlled by bit 10 and chip Y wit= h > USB reset controlled by bit 12. > > > > So being able to write something like: > > resets =3D <&sysctl 10>; > > or > > resets =3D <&sysctl 11>; > > > > in my dts/dtsi files helps me immensely, instead of having to check wha= t > chip I am running on and based on that use a different register layout=E2= =80=A6 > > Then, if I wanted to (de)assert reset for a peripheral block that has > this property defined I=E2=80=99d just do fdt_reset_(de)assert_all(dev), = where dev > is the device_t for the peripheral in question. This would (de)assert all > reset pins associated with the peripheral. > > > > The same is the case for clock control (gating) in the Ralink/Mediatek > SoCs and this is the main reason I used fdt_clock that is already in > sys/dev/fdt and then thought about implementing the fdt_reset based on it= . > > > > I hope this clarifies a bit my reason for submitting the fdt_reset patc= h. > > This seems fine to me. Hm. Ian? Any comments? > I want to check on a few things before we head down this path. I've been traveling so haven't had a chance to look through it to see if Atmel uses this, and who else does... Warner > -a > > > Best wishes > > Stanislav > > > >> On Jan 18, 2016, at 02:04, Warner Losh wrote: > >> > >> I don't see how resets help. Maybe I missed where it was documented, > could you send that to me? > >> > >> Even with that, it seems that a generic ohci_fdt driver isn't possible= . > >> > >> Warner > >> > >> On Thu, Jan 14, 2016 at 2:01 AM, Stanislav Galabov > wrote: > >> Hi all, > >> > >> First off, sorry for the cross-post, I wasn=E2=80=99t very sure where = this > should go=E2=80=A6 > >> > >> I=E2=80=99ve created 3 PRs, which enable some functionality that my wo= rk on > Ralink/Mediatek SoCs would benefit from. > >> > >> 1. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206227 < > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206227> > >> - This enables geom_flashmap and fdt_slicer support for SPI flash chip= s > supported by the mx25l driver (sys/dev/flash/mx25l.c) > >> > >> 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206228 < > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206228> > >> - This adds support for FDT =E2=80=98resets=3D=E2=80=99 property in mu= ch the same way as > ian@=E2=80=99s sys/dev/fdt/fdt_clock* supports FDT =E2=80=98clocks=3D=E2= =80=98 property. In fact > this work is basically a modified version of fdt_clock* :-) > >> > >> 3. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206229 < > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206229> > >> - This simply moves the at91 specific sys/dev/usb/controller/ohci_fdt.= c > to sys/dev/usb/controller/at91ohci_fdt.c (and changes the filename in > sys/arm/at91/files.at91 as well). The current naming is misleading IMHO a= nd > also, I have some (vague-ish) plans to see if I can implement generic > ohci_fdt and ehci_fdt based on dwc_otg_fdt, so that systems with standard > ehci/ohci controllers can reuse these. > >> > >> Patches are attached to the PRs. > >> > >> I would appreciate any feedback on the PRs and would also appreciate i= t > if someone could commit these if the proposed changes are appropriate. > >> > >> Best wishes, > >> Stanislav > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm < > https://lists.freebsd.org/mailman/listinfo/freebsd-arm> > >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org > " > >> > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >