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

[Adrian Chadd]

ok, I think you've now hit the "please register for an account at
reviews.freebsd.org and publish patches there" step. :)


-a


On 23 January 2016 at 00:28, Stanislav Galabov <sgalabov at gmail.com> wrote:
>
>
>> 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"
> _______________________________________________
> 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"