Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Jan 2016 21:43:32 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Adrian Chadd <adrian.chadd@gmail.com>
Cc:        Stanislav Galabov <sgalabov@gmail.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>,  "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org>
Subject:   Re: SPI geom_flashmap/fdt_slicer support, FDT 'resets=' support and a move of ohci_fdt.c
Message-ID:  <CANCZdfr4frLMAfRiaHoVFPhi8hDa8rXSr5xjTyMQpUqoS-RT7g@mail.gmail.com>
In-Reply-To: <CAJ-Vmo=DcfSXsuLUpcMvogjWNmNrniNsPxshhmHcGoWOxWM=CQ@mail.gmail.com>
References:  <B4B24B7D-B3EE-4F37-9E89-24FF17294C70@gmail.com> <CANCZdfrt-EdzFuXFSP2sTAX2vxP_RKAamKgUeL0u7hZYxeOF_A@mail.gmail.com> <2AB9D6E1-BFF8-4EEE-B366-C980B72C4779@gmail.com> <CAJ-Vmo=DcfSXsuLUpcMvogjWNmNrniNsPxshhmHcGoWOxWM=CQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 21, 2016 at 8:35 PM, Adrian Chadd <adrian.chadd@gmail.com>
wrote:

> On 18 January 2016 at 06:49, Stanislav Galabov <sgalabov@gmail.com> 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 <imp@bsdimp.com> 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 <sgalabov@gmail.com
> <mailto:sgalabov@gmail.com>> 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 <mailto: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
> <mailto: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"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr4frLMAfRiaHoVFPhi8hDa8rXSr5xjTyMQpUqoS-RT7g>