From owner-freebsd-mips@freebsd.org Fri Jan 22 05:35:55 2016 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9F79A8CD79; Fri, 22 Jan 2016 05:35:55 +0000 (UTC) (envelope-from mmel@freebsd.org) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) by mx1.freebsd.org (Postfix) with ESMTP id 8208D12F1; Fri, 22 Jan 2016 05:35:55 +0000 (UTC) (envelope-from mmel@freebsd.org) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id 5F5EF3AC9A; Fri, 22 Jan 2016 06:35:54 +0100 (CET) Subject: Re: SPI geom_flashmap/fdt_slicer support, FDT 'resets=' support and a move of ohci_fdt.c To: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org References: <2AB9D6E1-BFF8-4EEE-B366-C980B72C4779@gmail.com> Cc: "freebsd-mips@freebsd.org" From: Michal Meloun X-Enigmail-Draft-Status: N0020 Organization: freebsd.org Message-ID: <56A1BFBB.8050204@freebsd.org> Date: Fri, 22 Jan 2016 06:35:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Fri, 22 Jan 2016 06:35:54 +0100 (CET) X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 05:35:55 -0000 Dne 22.01.2016 v 5:43 Warner Losh napsal(a): > On Thu, Jan 21, 2016 at 8:35 PM, Adrian Chadd > wrote: > >> On 18 January 2016 at 06:49, Stanislav Galabov 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 >> -a >> >>> Best wishes >>> Stanislav >>> >>>> On Jan 18, 2016, at 02:04, Warner Losh 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 > > 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 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 >> " >>>> >>> >>> _______________________________________________ >>> 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" >