From owner-freebsd-arm@freebsd.org Sat Jan 23 01:51:56 2016 Return-Path: Delivered-To: freebsd-arm@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 4E43DA8D81E for ; Sat, 23 Jan 2016 01:51:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 0B7A51B65 for ; Sat, 23 Jan 2016 01:51:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mail-oi0-x231.google.com with SMTP id k206so59215693oia.1 for ; Fri, 22 Jan 2016 17:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=I1Bi5CkCYk0K87jJdyQOteQmr12KcfdPwq1aaRwrnpo=; b=OrrYQNaCVkBilJzvkqUI8B0xVMK3SrXZsaDZOeLWa1Nm548LMxtCryf4lyhEHuL2kp U5YMggZCvpU0py18KzRGuB0BSRu1oLd7yA0iRQzdRj8TXKn3Udz8wAWKb620jYdXzWtf vN1BPIJ3v8ef7LcddRqhjdM5JXSmJFsacTlITh4JUdyYfRyNCFhoN3zc2fEBppqdujhF WlGK7gpfjuywb+Q1jy6ddpBQ8b+Lf2FAFjy9A+QYDkVbCg1VS4ak9T7u9ibHd0IVGe3d LpPBhw/LH/dQpChF7qN89ST4u+tSjRc/dNzGcCIZ9Vym4A/C2U3V6ClXhdhbXzNBEHjc st9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=I1Bi5CkCYk0K87jJdyQOteQmr12KcfdPwq1aaRwrnpo=; b=Y6kqc+svaV1uK4C8oSvXRk/yKFlldI2acQ5b35Z4ETKiKMb1ck7wTWmbr6zQRQotDL VW6bp/9LQB/lFwgLZLo34hoX1RE7cUzbvS00g5EGezXWuXsNb0k1BOE6zlD44ai/JOSm LKMVPzWZseoEqjEKls/D0ARVT+kTeB0HC5vlHY3W42kFhFCsH/OlLMzU/6TMV6Lm3lA0 ozZjmWjuzDdAiQMzgKn1eBxDYeD0ixbtvuVWXdNTDGkEGboOt4yxyr/1a2RhlawtX9Ny u7sFmXGral+itRUyKDFihRT3hXO/LzBmkNeh4St4mdtw76ju4ilsb7NPj5srMOcChLn1 cQuQ== X-Gm-Message-State: AG10YOTSGjxtm8X7yjn5XRirkv2bCmrzCXeWWtp+gWHjTOw7/mkSVokzvMG95riBLf+DiQ== X-Received: by 10.202.80.201 with SMTP id e192mr4755570oib.14.1453513914924; Fri, 22 Jan 2016 17:51:54 -0800 (PST) Received: from ?IPv6:2601:280:4900:3700:8c4e:fe46:fde5:e44f? ([2601:280:4900:3700:8c4e:fe46:fde5:e44f]) by smtp.gmail.com with ESMTPSA id k1sm4669962obz.22.2016.01.22.17.51.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 17:51:54 -0800 (PST) Sender: Warner Losh Subject: Re: SPI geom_flashmap/fdt_slicer support, FDT 'resets=' support and a move of ohci_fdt.c Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_24CDE167-DB4D-4F5F-ADFF-173724FA42B8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: <56A1BFBB.8050204@freebsd.org> Date: Fri, 22 Jan 2016 18:51:52 -0700 Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org Message-Id: <9175E4D1-85CD-482F-A867-E327966A22FC@bsdimp.com> References: <2AB9D6E1-BFF8-4EEE-B366-C980B72C4779@gmail.com> <56A1BFBB.8050204@freebsd.org> To: Michal Meloun X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 01:51:56 -0000 --Apple-Mail=_24CDE167-DB4D-4F5F-ADFF-173724FA42B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 21, 2016, at 10:35 PM, Michal Meloun wrote: >=20 > Dne 22.01.2016 v 5:43 Warner Losh napsal(a): >> On Thu, Jan 21, 2016 at 8:35 PM, Adrian Chadd = >> wrote: >>=20 >>> On 18 January 2016 at 06:49, Stanislav Galabov = wrote: >>>> Hi Warner, >>>>=20 >>>> I was thinking resets could help in general, not specifically in = the >>> case of trying to implement a generic ohci_fdt driver. >>>>=20 >>>> 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: >>>>=20 >>> = https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bin= dings/reset/reset.txt >>> < >>> = https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bin= dings/reset/reset.txt >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> So being able to write something like: >>>> resets =3D <&sysctl 10>; >>>> or >>>> resets =3D <&sysctl 11>; >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> I hope this clarifies a bit my reason for submitting the fdt_reset = patch. >>>=20 >>> This seems fine to me. Hm. Ian? Any comments? >>>=20 >>=20 >> 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... >>=20 >> Warner >>=20 >>=20 > 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 This looks fairly good. Bummer that Atmel doesn=E2=80=99t use it yet in = their FDT files. Warner > Michal >=20 >>> -a >>>=20 >>>> Best wishes >>>> Stanislav >>>>=20 >>>>> 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 < >>> 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 < >>> 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 < >>> 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 < >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm> >>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org >>> " >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 >=20 > _______________________________________________ > freebsd-mips@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to = "freebsd-mips-unsubscribe@freebsd.org" --Apple-Mail=_24CDE167-DB4D-4F5F-ADFF-173724FA42B8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWoty4AAoJEGwc0Sh9sBEAnnMP/2MrNmJvqgK6t8UT63cWCuim 6xZVTRivoZzEF4gJd+DdfAlvyGSmbvmzn+nGlcYjS/HKZbZtfbufzcYJfCng4iJn RcBf00pf7IuGkRMTuvZTIBhrNfo3lOhhg4wMVxQc1o3+7nxVMquOEG9rkqt1EIM1 kYAjCWGArAxObjkJ9I2WP/TXkFt4ltYVbltBTTpeWXcML0IxZpT4F/TcOuF7OJcN 0IjPYOAy4+pG6CWt3+jNi2LexyuuVT+y/NMd/QiG2dyz6ElPetniINe20ID2Cqaj xUCmkCkDJIouMhDxuJI9IPvn0XiFtpWun5NPI9ip0GNZinVH+vEemMsolInis+zb PuuVRrcTdtsMtnAV9TnABJldjHPuwAojaJx2VpdMncdO/EuSTXcfDztcS/wIr1An nMooQH9k7TxXHI76Lko01fBShNPdxdzMR2YYYDckDmtm/Y/YS+IpXqIjdZ9UiETP bZpf9jriq4ErV7dsNFfGgB5ucxHsQ2GYkLg8bfWqoLGBcxF8PlmVuMErU5uWdJgu ybIKmm5fRNpbAO9/y1UP64vxItWD69KZ9vYP0v/6EALl9OPYUwjNm8uKAzhDBstK yQvTIytwGvSoGkz174ay19nNsiyIfUmx97guuECvNvxmwku6Xu6cJDSCMZ0/X7um toBPZ3tXCQPcbCisFVtV =D+0m -----END PGP SIGNATURE----- --Apple-Mail=_24CDE167-DB4D-4F5F-ADFF-173724FA42B8--