svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules

[Oleksandr Tymoshenko]

Poul-Henning Kamp (phk at phk.freebsd.dk) wrote:
> --------
> In message <20180129063950.GA59901 at 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