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 <20180129132736.GA66330 at 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