From owner-svn-src-head@freebsd.org Tue Jan 30 02:51:01 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 9A840ED022A; Tue, 30 Jan 2018 02:51:01 +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 2C95E76156; Tue, 30 Jan 2018 02:51:00 +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 1egM0Y-000Ki2-R6; Mon, 29 Jan 2018 18:50:52 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id w0U2omFX079609; Mon, 29 Jan 2018 18:50:48 -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 18:50:48 -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: <20180130025048.GA76676@bluezbox.com> References: <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> <20180129132736.GA66330@bluezbox.com> <33452.1517233531@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33452.1517233531@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 <20180129132736.GA66330@bluezbox.com>, Oleksandr Tymoshenko writes: > > >> If I pick a RPI[23] out of the box, download a FreeBSD [...] 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: Tue, 30 Jan 2018 02:51:01 -0000 Poul-Henning Kamp (phk@phk.freebsd.dk) wrote: > -------- > In message <20180129132736.GA66330@bluezbox.com>, Oleksandr Tymoshenko writes: > > >> 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. > > You seem to have skipped the bit about "without reboot" ? No I haven't. config.txt is parsed by VC firmware on boot time and pwm.dtbo is applied even before boot loader kicks in. When kernel starts pwm node has pinctl information ready and status property is set to "okay". So if you download next available image, flash and boot it and run kldload bcm2835_pwm it will give you working PWM device out of the box without reboot. It's end-user experience you described. This approach works well with soon to be added pinctl and does not require ofw_bus_status_okay hack. Please commit a fix for it. > >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. > > That's *exactly* why I want us to support them better. > > >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? > > At the very least have some place to point developers for a > resonably up-to-date idea of what the FDT related architecture > in FreeBSD is. Fair point. It can be chapter in Handbook. > Either documentation or source code (preferably with a bit of > contextual comments) on our chosen reference platform. (Source > code on ref-platform is probably more robust, as there is a > better chance that it will be kept current.) I don't think we have designated reference platform at the moment, but it's a good idea to have one. Pi's platform is too weird to be reference. TI's AM335x or iMX would be a good candidate I think They are complex enough to illustrate all the concepts yet not super complex. There is probably some bugs there from the dawn of FDT era but thery can be cleaned out. Nvidia's SoCs are not very accessible. And I don't have any knowledge about how complex Allwinner codebase is. > >You also ignored my question about clkman fix. Provided you have > >all the documentation you need [...] > > I don't. The information for the PWM case was based on an affine > transform of information for the GPIO clock some shrewed guesses > and finally in-lab measurement of what actually transpired when I > frobbed registers. > > But more importantly, I have no idea what servies *a* clock > manager offers, through which apis and to what clients and > at what level of abstraction and flexibility ? Wrong wording on my side. It should have been: "if somebody put together all required documentation on clk framework would you be up to fix clkmgr driver?" Doesn't matter now, mmel@ volunteered to look into this. -- gonzo