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

[Adrian Chadd]

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?


-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"