Date: Fri, 22 Jan 2016 18:51:52 -0700 From: Warner Losh <imp@bsdimp.com> To: Michal Meloun <mmel@FreeBSD.org> Cc: freebsd-arm@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: <9175E4D1-85CD-482F-A867-E327966A22FC@bsdimp.com> In-Reply-To: <56A1BFBB.8050204@freebsd.org> 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> <CANCZdfr4frLMAfRiaHoVFPhi8hDa8rXSr5xjTyMQpUqoS-RT7g@mail.gmail.com> <56A1BFBB.8050204@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] > On Jan 21, 2016, at 10:35 PM, Michal Meloun <mmel@FreeBSD.org> wrote: > > Dne 22.01.2016 v 5:43 Warner Losh napsal(a): >> 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 to >>> possibly make some more sense), I saw that Linux makes use of the ‘resets’ >>> property and looked at the documentation for it: >>>> >>> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/reset/reset.txt >>> < >>> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/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 very >>> 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 with >>> USB reset controlled by bit 12. >>>> >>>> So being able to write something like: >>>> resets = <&sysctl 10>; >>>> or >>>> resets = <&sysctl 11>; >>>> >>>> in my dts/dtsi files helps me immensely, instead of having to check what >>> chip I am running on and based on that use a different register layout… >>>> Then, if I wanted to (de)assert reset for a peripheral block that has >>> this property defined I’d 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 patch. >>> >>> 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 >> >> > I think that i have more complete implementation of reset framework > ready to commit. Just waiting for mentor approval. > Please see https://github.com/strejda/tegra/tree/master/sys/dev/reset This looks fairly good. Bummer that Atmel doesn’t use it yet in their FDT files. Warner > Michal > >>> -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’t very sure where this >>> should go… >>>>> >>>>> I’ve created 3 PRs, which enable some functionality that my work on >>> Ralink/Mediatek SoCs would benefit from. >>>>> >>>>> 1. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206227 < >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206227>; >>>>> - This enables geom_flashmap and fdt_slicer support for SPI flash chips >>> supported by the mx25l driver (sys/dev/flash/mx25l.c) >>>>> >>>>> 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206228 < >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206228>; >>>>> - This adds support for FDT ‘resets=’ property in much the same way as >>> ian@’s sys/dev/fdt/fdt_clock* supports FDT ‘clocks=‘ property. In fact >>> this work is basically a modified version of fdt_clock* :-) >>>>> >>>>> 3. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206229 < >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206229>; >>>>> - 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 and >>> 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 it >>> 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" >>> >> _______________________________________________ >> 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" >> > > _______________________________________________ > freebsd-mips@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWoty4AAoJEGwc0Sh9sBEAnnMP/2MrNmJvqgK6t8UT63cWCuim 6xZVTRivoZzEF4gJd+DdfAlvyGSmbvmzn+nGlcYjS/HKZbZtfbufzcYJfCng4iJn RcBf00pf7IuGkRMTuvZTIBhrNfo3lOhhg4wMVxQc1o3+7nxVMquOEG9rkqt1EIM1 kYAjCWGArAxObjkJ9I2WP/TXkFt4ltYVbltBTTpeWXcML0IxZpT4F/TcOuF7OJcN 0IjPYOAy4+pG6CWt3+jNi2LexyuuVT+y/NMd/QiG2dyz6ElPetniINe20ID2Cqaj xUCmkCkDJIouMhDxuJI9IPvn0XiFtpWun5NPI9ip0GNZinVH+vEemMsolInis+zb PuuVRrcTdtsMtnAV9TnABJldjHPuwAojaJx2VpdMncdO/EuSTXcfDztcS/wIr1An nMooQH9k7TxXHI76Lko01fBShNPdxdzMR2YYYDckDmtm/Y/YS+IpXqIjdZ9UiETP bZpf9jriq4ErV7dsNFfGgB5ucxHsQ2GYkLg8bfWqoLGBcxF8PlmVuMErU5uWdJgu ybIKmm5fRNpbAO9/y1UP64vxItWD69KZ9vYP0v/6EALl9OPYUwjNm8uKAzhDBstK yQvTIytwGvSoGkz174ay19nNsiyIfUmx97guuECvNvxmwku6Xu6cJDSCMZ0/X7um toBPZ3tXCQPcbCisFVtV =D+0m -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9175E4D1-85CD-482F-A867-E327966A22FC>