From owner-svn-src-head@freebsd.org Mon Jan 29 13:27:45 2018 Return-Path: Delivered-To: svn-src-head@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 1D3C1EC70CA; Mon, 29 Jan 2018 13:27:45 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD80F72C10; Mon, 29 Jan 2018 13:27:44 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1eg9TG-000Hnm-Md; Mon, 29 Jan 2018 05:27:41 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id w0TDRaoP068433; Mon, 29 Jan 2018 05:27:36 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Mon, 29 Jan 2018 05:27:36 -0800 From: Oleksandr Tymoshenko To: Poul-Henning Kamp Cc: Emmanuel Vadot , Warner Losh , John Baldwin , Ravi Pokala , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org, owner-src-committers@freebsd.org Subject: Re: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules Message-ID: <20180129132736.GA66330@bluezbox.com> References: <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> <13025.1517179897@critter.freebsd.dk> <20180129063950.GA59901@bluezbox.com> <32793.1517221534@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32793.1517221534@critter.freebsd.dk> X-Operating-System: FreeBSD/11.1-RELEASE-p4 (amd64) User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Poul-Henning Kamp (phk@phk.freebsd.dk) wrote: > -------- > In message <20180129063950.GA59901@bluezbox.com>, Oleksandr Tymoshenko writes: > > >PWM drivers: https://reviews.freebsd.org/D14104 > > I'll [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 13:27:45 -0000 Poul-Henning Kamp (phk@phk.freebsd.dk) wrote: > -------- > In message <20180129063950.GA59901@bluezbox.com>, Oleksandr Tymoshenko writes: > > >PWM drivers: https://reviews.freebsd.org/D14104 > > I'll test this in my next timeslot. > > >We do not include these > >overlays in official snapshots and I think this should be fixed. > > That's one of the details I ran into: The DTS for the DTB > in the RaspBSD.org images is not in our tree. > > Even if they are vendor-supplied, should they be in our tree for > reasons of completeness/documentation/reproducible builds etc. ? The answer is: it's complicated. There is no single source of truth. Raspberry Pi's DTS in vendor tree is different from the one in mainline Linux and therefore ours (we lag a bit behind mainline Linux). As far as I know Nvidia is the same. DTS world is a mess and that's why people spend so much energy communicating between vendors, mainline Linux and FreeBSD to get this stuff standartized and to reduce chaos. Also FDT should be supplied by vendor by definition. Closest thing to FDT in beige box world is ACPI tables. It's just unfortunate state of affairs that standard is in constant flux and Linux monopolized distribution rights. > >Summary: adding ofw_bus_status_okay check in probe method doesn't > >require any additional functionality, ignoring it is inconsistent > >with majority of FDT-based drivers' behavior. There is trivial > >way to enable PWM device in platform-conformant way. Will you > >please commit fix for this bug? > > I prefer an architectural discussion about how we *want* this to > work in the long run first. > > My input: > > If I pick a RPI[23] out of the box, download a FreeBSD image, > put the card in and play around, I should be able to put a > LED in a breadboard and configure a line for PWM or attach > an I2C or SPI device without reboot between every single > experiment. No problem. We include pwm.dtbo in our snapshot and config.txt. We have PWM running out of the box. Problem solved, no need for any hacks. I'll gladly work with Glen and Brad to get this functionality in snapshots/builds. > If I mount any kind of "cape" board, requiring a reboot is > a perfectly reasonable requirement (not to mention it being > sane ESD procedure.) > > That may indicate an overall model where we distinguish between > "overlays loaded at boottime" and "no overlays loaded at > boot time" and behave more liberally in the second case. > > Or maybe we just need a well hidden but powerful switch that > lets people say "God, Root, What difference?" > > The crucial point is that we gain no friends or favours by enforcing > needless cumbersome procedures, like reboots, just because there > may some times be dangers without it, because very often the dangerous > things people want to do is getting their job done or develop > and improve FreeBSD. > > I kindly point you to the wisdom of Kernighans "There is no > escape" critique of PASCAL. > > (Service message to the non-ancient developers: That this bit of > advice came from the bloke who had read Kernighan and therefore > implemented "kern.geom.debugflags=0x10" to defeat the consistency > protections in his new-fangled GEOM subsystem, even if it was > dangerous - and he never once regretted it.) Design discussion on dynamic overlays is welcome. FreeBSD/arm can use more hands, brains, and set of fresh eyes. It's non-trivial topic and I am really glad someone is working on it. I gave up year ago. But committing bad hack and then requesting design discussion is a hostage situation and not a dialog. Raspberry Pi and other hobbyist ARM boards are basically Lego. They can be turned into multiple things and that's their selling point. They're hackers' toys. You approach them as a box product and you approach them from the wrong angle. If you want box product built with Lego, concentrate on how blocks are put together, not on how joints work. It looks to me like you apply your experience from x86 world and look at FDT-based platforms as a smaller and weirder PCs. They're not, they're completely different breed. They're not even embedded systems with ad-hoc hardware info from 10 years ago, they're order of magnitude more complex. With all due respect the fact that we're having this discussion or that I have to explain FDT/DTS files origins is an indicator of how little you understand current situation in hobbyist embedded world or embedded FreeBSD for that matters. I've been working on this stuff for last 5 years on and off, lately mostly off and I know I am behind all the latest developments. "Don't ignore status property unless you really, really, really have to" is not even a discussion point, it's a common knowledge that comes from years of people's work across multiple ARM platforms. It wasn't common knowledge 5 years ago but it is now. So to summarize: - Please revert PWM probe method to standard driver behavior - I'll work with Glen and Brad to get PWM working out of the box on snapshots and RaspBSD builds. > >All these best practices and guidelines are unwriteen, and > >they're not always implemented on older platforms. And it's the > >problem from which this situation has risen. > > With the added cherry on top that RPi is a horrible platform which > nobody loves - except thousands of teachers, students, hackers and > other potential FreeBSD recruits. You ignored my question: what would be authoritative source for this kind of info? World is not perfect, FreeBSD/arm support is not perfect. We have limited resources. Where we should apply them to guide new contributors? You also ignored my question about clkman fix. Provided you have all the documentation you need and no external obstacles would you be up to converting clkman to extres/clk framework in foreseeable future? -- gonzo