SPI geom_flashmap/fdt_slicer support, FDT 'resets=' support and a move of ohci_fdt.c

Sat Jan 23 08:28:17 UTC 2016

> On Jan 22, 2016, at 07:35, Michal Meloun <mmel at 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 at gmail.com>
>> wrote:
>> 
>>>> On 18 January 2016 at 06:49, Stanislav Galabov <sgalabov at 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
> 
> Michal

I have no objections to using Michal's framework, especially if the patch from PR 206516 is applied:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206516

His framework is really more complete than what I did.

Best wishes,
Stanislav

>>> -a
>>> 
>>>> Best wishes
>>>> Stanislav
>>>> 
>>>>> On Jan 18, 2016, at 02:04, Warner Losh <imp at 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 at gmail.com
>>> <mailto:sgalabov at 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 at freebsd.org <mailto:freebsd-arm at 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 at freebsd.org
>>> <mailto:freebsd-arm-unsubscribe at freebsd.org>"
>>>> 
>>>> _______________________________________________
>>>> freebsd-arm at freebsd.org mailing list
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>> _______________________________________________
>> freebsd-arm at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
> 
> _______________________________________________
> freebsd-mips at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-mips
> To unsubscribe, send any mail to "freebsd-mips-unsubscribe at freebsd.org"