From owner-svn-src-all@freebsd.org Sun Jan 28 21:21:18 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AF24EDFC06 for ; Sun, 28 Jan 2018 21:21:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 A804A6F18F for ; Sun, 28 Jan 2018 21:21:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id x128so6024639ite.0 for ; Sun, 28 Jan 2018 13:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2oa3yEGGm7zDUc+/KQZRJZvD4EfyjNCKHcTEoFH8WC8=; b=UysyVbLdPal48POoU+aMV7gLglkdw9zJf9Co3PC6mp6bE2e8wpbgHxNpGXjrRAIPZX pYc46H6w77jpu9D0xWgLliuKTR+qiaoN6/gLas6DPkFliioWwplU+8/HrZHW0zKwM8IQ 6KS6c0qjUGaR+ylUDxKVpDTnguDzywvvCSIpHP2exvcC95g4cGov1CGQu2a+QR2LK7Uq wvB/1qahMhuYWT0SDuoTdAoOaPlyJg9ZdSubW0X3Ll1UpyOssEpyht1UgbxpojOrTtLQ /z+Ov9I9Q3TVXypdgUvGvnt8+b9mTmMbVLWqY7U+52Q/zWjQepSRLI8aTOMQhK0bXdHC i0sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2oa3yEGGm7zDUc+/KQZRJZvD4EfyjNCKHcTEoFH8WC8=; b=r3RGY+xyZmuAMhG9jMAB1Jb24YO0PsnYfl9ibBZS9XW3+CmXfA+RDS30RSsHO/SDvD mjQDEWkM8bMbZstv9deegIMSMJGnPyo2tXURT4qcjdE7SjgYtpPXYnKI2qplkOaBC+Es gxH9rEpHpz4c/T0JVJJpkmwFhcyFU8bJef5H/n/BLmP+ficGNAI1eMPljCJtTOUWlJPR q+M64Cu6TO7q87RcC0qSrzfWLpWNPwxgldeE106EuArn3XazIIO70cHaWU9vPIX+74vg AQnzre9/r4AyS9wN1shONP7raGdPUX+HvjYjW3YNUxRNAyO/Wat9gooGddirm7O/Vrrk UR6w== X-Gm-Message-State: AKwxyteIPgVZ+44QYOU4oXj8GgBcSZoSUYTMdh/eLWC5vZbBbI1fZBIN Wqw03S9Wn88sL1Ui9BOAy5tWbkYeVqCcEWJq3mbJDA== X-Google-Smtp-Source: AH8x225aKu/gP/k1vNzPF0mZfj2JsGt2mFV+uPEKMr2fEu0abi7LUsuFAjjLHcH6NY38Spw57bDKbL7B6wJKAm6om54= X-Received: by 10.36.104.210 with SMTP id v201mr23042988itb.64.1517174477031; Sun, 28 Jan 2018 13:21:17 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Sun, 28 Jan 2018 13:21:16 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <8d8ae9d10058fd72ce3ec467181c9f22@megadrive.org> References: <201801220710.w0M7AUm9091853@repo.freebsd.org> <90451.1516663240@critter.freebsd.dk> <2987003.eeGRFBb6N8@ralph.baldwin.cx> <93949.1516733748@critter.freebsd.dk> <20180127210801.37b8001125dd0a2c92372f98@bidouilliste.com> <72042.1517094867@critter.freebsd.dk> <8d8ae9d10058fd72ce3ec467181c9f22@megadrive.org> From: Warner Losh Date: Sun, 28 Jan 2018 14:21:16 -0700 X-Google-Sender-Auth: xiUC-ub-Zjb1mMT26WZ8gm_ub6Y Message-ID: Subject: Re: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules To: Emmanuel Vadot Cc: Poul-Henning Kamp , John Baldwin , Ravi Pokala , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org, owner-src-committers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 21:21:18 -0000 On Sun, Jan 28, 2018 at 10:34 AM, Emmanuel Vadot wrote: > On 2018-01-28 00:14, Poul-Henning Kamp wrote: > >> -------- >> In message <20180127210801.37b8001125dd0a2c92372f98@bidouilliste.com>, >> Emmanuel Vadot writes: >> >> - We have a commiter that commited something for his own need: he >>> wanted to use the pwm on his rpi, coded a driver (this part is good) >>> but feel that the standard we were using was crap and commited his work >>> without talking with arm developper on what the proper way to do it was. >>> >> I don't entirely agree about that, I think RPi is a platform we >> > as project ignore at our peril, so I have started to do a little >> bit of an effort, as I find time and information for it. >> > > And we all thank you for that. The problems with RPi aren't going to be solved with simple quick hacks. The port pre-dates our evolved views on using DTB, the upstream linux DTB and the need to have more complete pinmux / clock / power support. Each driver does it in an ad-hoc way now, meaning there's a lot of code in the drivers that needs to be burned down before we can stand up a replacement... Hopefully, these discussions will bear fruit in the near term. You keep yelling at me for not adhering to an entirely undocumented >> design vision, which we don't even have a single compliant reference >> platform for yet. >> > > Reference platform doesn't make much sense in the embedded world. > Even if you take the JUNO hardware (ARMv8 reference design, which I think > we support to some extent), we don't support the GPIO/Pinmuxing I think and > even if we do it's different than the controller on RPI (Or any other SoC). > Well more like same-same but different stuff. > If you want a reference platform take the Allwinner code or IMX (I > sometime look at the IMX code to check stuff because I know ian@ knows > his stuff). The embedded space is a high-context, fast moving space relative to x86. As such, there will always be a certain amount of undocumentedness. It requires closely working with the community of embedded developers in a way that we've not had to do in x86 world since the patch-kit / 1.x days. A long time ago, though, FreeBSD evolved a whole new VM w/o it having much of a published design. Newbus went to market w/o good docs published, yet everybody was expected to adopt it. The problems of documentation have largely been corrected after things were built. The evolution of the embedded space and how we can best support it with the minimal resources the project has is similar. While there's no over-arching design document, the broad outlines are there, and the interfaces we want to implement have published specs, even if they aren't all implemented yet. In an ideal world this would all be documented, published and anybody that shows up would know the next steps to take. I'd love for that to be the case here, but we don't have that today. Warner