From owner-freebsd-mips@freebsd.org Fri Jan 22 03:35:11 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 66A52A8C387; Fri, 22 Jan 2016 03:35:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 2F75E117B; Fri, 22 Jan 2016 03:35:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x230.google.com with SMTP id h5so46199282igh.0; Thu, 21 Jan 2016 19:35:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WAvfeMqM564nwQImxPAjRPmKeQfCC2KGybK0YExOaYI=; b=e0VvUK3n7LgYohVAeaIxr8MlncQDada3JNZX7UbOoq4GgHjpkMICh8BoT2IYOqmrIG XvSHGXJ/S2dH5EpdZBLLS6FPofHR0ukamnuC6oXLiGWQBrSCKqY1RmHdZU6jOCTb3Ubx xFTH7sOK1ZaogQ1Y0bStlOkQl+1UJWXYA9aICYWYP+DB44dd5tuP1Ap5copBiDPMTrDp qnbvvHDuX3vfYHBTfq8UF5OZg8dfj86m466227FUTi2j2VhH4kbSntYTszflbOjzsPoi BPgGZcwixBNPSXnDoal9Py3sykxiUJCaycDzrlMgiAzulydoqOYNZNCqQsOokfMwxRhu FpMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WAvfeMqM564nwQImxPAjRPmKeQfCC2KGybK0YExOaYI=; b=nAvwcn1QWDpwBYZ5oMvoIScDZHVm4bcSHRN8eTvmGXMWYtIIEW8Mj1PKyg6fyAzD+5 96KRUe9sQUB2Ms3qUHDH4UiOW3zN4qlM2J9U+V4IFFxGhvY11AhmuukqPqa6eXeHo6au uSOrlhpf0emSdlyAr1w0WSwaGb9Cimsc4rruJQep++fseGRgt1ScRu3Qebo93MLOfiFc 8Eol0wiLhUQyAqIFYmWEklS8hfBaiKosCBkxtwOc4IYLr+DqG9crExdDE+H36hh83btt lWfYApWW21aonODNp+CpQrotijEMa77e6FP7tPcUcdCHwo2yL2yBsf4tMHT5HpC5JBuC n3lw== X-Gm-Message-State: AG10YOReGmKLpteKEFCp3O/L7jn0P1UJx+4bpqQqhWmkdRRv2SD3XjpUe5+6YXwnCcAV+qukIdQuZdjm53TTfA== MIME-Version: 1.0 X-Received: by 10.50.122.100 with SMTP id lr4mr1250847igb.37.1453433710638; Thu, 21 Jan 2016 19:35:10 -0800 (PST) Received: by 10.36.121.16 with HTTP; Thu, 21 Jan 2016 19:35:10 -0800 (PST) In-Reply-To: <2AB9D6E1-BFF8-4EEE-B366-C980B72C4779@gmail.com> References: <2AB9D6E1-BFF8-4EEE-B366-C980B72C4779@gmail.com> Date: Thu, 21 Jan 2016 19:35:10 -0800 Message-ID: Subject: Re: SPI geom_flashmap/fdt_slicer support, FDT 'resets=' support and a move of ohci_fdt.c From: Adrian Chadd To: Stanislav Galabov Cc: Warner Losh , "freebsd-arm@freebsd.org" , "freebsd-mips@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 03:35:11 -0000 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 =E2=80=98= resets=E2=80=99 property and looked at the documentation for it: > https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bi= ndings/reset/reset.txt > > For example, with the work I am currently doing on Ralink/Mediatek suppor= t, I have over 10 different chips in the same family, that have very simila= r peripheral blocks, but their clocks and resets are controlled via differe= nt 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 ha= s its USB (for example) reset controlled by bit 10 and chip Y with USB rese= t 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 thi= s 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 So= Cs 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 wrote: >> >> I don't see how resets help. Maybe I missed where it was documented, cou= ld 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=E2=80=99t very sure where th= is should go=E2=80=A6 >> >> I=E2=80=99ve 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=3D206227 >> - 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=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 v= ersion of fdt_clock* :-) >> >> 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/a= rm/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 >> 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"