From owner-freebsd-mips@freebsd.org Mon Jan 18 14:49:14 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 83A0DA866E5; Mon, 18 Jan 2016 14:49:14 +0000 (UTC) (envelope-from sgalabov@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0836E110D; Mon, 18 Jan 2016 14:49:14 +0000 (UTC) (envelope-from sgalabov@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id r129so54320431wmr.0; Mon, 18 Jan 2016 06:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=xsCBtJ+J4k129Lk9LTngm4CJufA9dMMBTNTeThUgyoM=; b=vZkSUtnLqnpw8lCkjFSe6oZ9vtpDnax1MysZwwWEbYRQLLCS4oEminTl+M+Vw5I5qM aZbFPPGQKTFBYy0yQWMxHnTGvRzeKghYzeVe6DXCQAsi2XJK9q9lfNA6d27hxIIaPcv1 eSh+siQMpj0mjOppuGfbPe/3fb+Jjxh/+X4rNycMLgHgUks8WXhuNQ34DiYEwxPj+xw5 5SR8eedVVWvEgZ+yYamh0mPp0+MeOgOSj+9uohpedH3InloeHdmZob5tV2SSVgSgY5DO /IIJnObAn8Yi5oYseMJ++klGBiaO5gOlweABZgtr86V/wsbHj6CPOUnyYMdr5gdzCKtJ vewA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=xsCBtJ+J4k129Lk9LTngm4CJufA9dMMBTNTeThUgyoM=; b=NCwKj41DHBvkMGhhq0n6+wFW954xr2ZpKahxfpfHDY8wQ35DIz0hVYbYO1qaSehcit o+dudoH5ipVa/cKtkSS5nJtAZpvW1l6iaqSaClVVN8oKnReh1WOPzBW3rrue01kL6gJX H4Os4KLfWntwsNEfrxWuNxybAKd6r+ySOOIF+rCREtX+NHxaiCCpap+JZyNe7sWRRsaN Cu+OSQHbkP/ALWr6q8hdnB0/NqYNLPvrKcyFB2/xCxr9WigUTBhmUygRTk/uZUUcdTws cBHT5xR9ej7hrVb7vRcik37bFa5vQQEgtw4g/2r9zDXwmdJ8fzgWNggsDI8gAL0Gu4AG DUdg== X-Gm-Message-State: AG10YOQE8Gdyuxc6BPP5Qho+6JBj1Bn+qb6N0Ko4ThuCRec4kJATlQM4sYg0z0l1tPV1QQ== X-Received: by 10.28.144.10 with SMTP id s10mr13064869wmd.97.1453128552530; Mon, 18 Jan 2016 06:49:12 -0800 (PST) Received: from macbookpro-894a.hsmt ([193.178.153.131]) by smtp.gmail.com with ESMTPSA id q129sm16187706wmd.14.2016.01.18.06.49.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Jan 2016 06:49:11 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Subject: Re: SPI geom_flashmap/fdt_slicer support, FDT 'resets=' support and a move of ohci_fdt.c From: Stanislav Galabov In-Reply-To: Date: Mon, 18 Jan 2016 16:49:10 +0200 Cc: Stanislav Galabov , "freebsd-mips@freebsd.org" , "freebsd-arm@freebsd.org" Message-Id: <2AB9D6E1-BFF8-4EEE-B366-C980B72C4779@gmail.com> References: To: Warner Losh X-Mailer: Apple Mail (2.3094) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Mon, 18 Jan 2016 14:49:14 -0000 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 = =E2=80=98resets=E2=80=99 property and looked at the documentation for = it: = https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bin= dings/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 =3D <&sysctl 10>; or resets =3D <&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=E2=80=A6 Then, if I wanted to (de)assert reset for a peripheral block that has = this property defined I=E2=80=99d 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. Best wishes Stanislav > On Jan 18, 2016, at 02:04, Warner Losh wrote: >=20 > I don't see how resets help. Maybe I missed where it was documented, = could you send that to me? >=20 > Even with that, it seems that a generic ohci_fdt driver isn't = possible. >=20 > Warner >=20 > On Thu, Jan 14, 2016 at 2:01 AM, Stanislav Galabov > wrote: > Hi all, >=20 > First off, sorry for the cross-post, I wasn=E2=80=99t very sure where = this should go=E2=80=A6 >=20 > I=E2=80=99ve created 3 PRs, which enable some functionality that my = work on Ralink/Mediatek SoCs would benefit from. >=20 > 1. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206227 = > - This enables geom_flashmap and fdt_slicer support for SPI flash = chips supported by the mx25l driver (sys/dev/flash/mx25l.c) >=20 > 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206228 = > - This adds support for FDT =E2=80=98resets=3D=E2=80=99 property in = much the same way as ian@=E2=80=99s sys/dev/fdt/fdt_clock* supports FDT = =E2=80=98clocks=3D=E2=80=98 property. In fact this work is basically a = modified version of fdt_clock* :-) >=20 > 3. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206229 = > - 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. >=20 > Patches are attached to the PRs. >=20 > I would appreciate any feedback on the PRs and would also appreciate = it if someone could commit these if the proposed changes are = appropriate. >=20 > Best wishes, > Stanislav > _______________________________________________ > 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 = " >=20