Re: Hooking RPi PWM driver into tree

[Warner Losh]

On Mon, Jan 15, 2018 at 4:26 AM, Poul-Henning Kamp 
wrote:

> I wrote a device driver for PWM on the RPi's, but I have not yet
> hooked it into the tree, because I'm unsure how we would want that.
>
> I personally think by default it should be a module which is
> only compiled for RPi kernels, but how does one do that ?
>

We don't. We have no idea we're building for a particular kernel, so we
don't subset the modules based on the kernel UNLESS the kernel config gives
a list (MODULES_OVERRIDE). Compile it for armv[67] arm64 and we're fine
(since those are the archs we have it for). Even this level of subsetting
has grown painful, but there's not been a good fix for that yet either (and
arguably, no bad fixes, just bad hacks that have grown up and proliferated
to the point Something Must Be Done, but that turns out to be non-trivial
to do in a way that doesn't replace one thicket of kludge with another :()

In fact, on ARM, we've been moving to not building for specific boards, but
having a GENERIC kernel that can be used everywhere. I'll be augmenting
that with automatic driver loading based on the "plug and play" table data
that's marked in the driver.

(Needless to say, it should also be possible to compile it into the
> kernel for an RPi, but I know how to do that :-)
>

Your best bet if you are creating a tiny distribution for this is to use
MODULES_OVERRIDE in the kernel config so it's a module still, but not built
into the kernel so you can load / unload as need arises.


> And do we want it to live in sys/modules/rpi_pwm or sys/modules/rpi/pwm ?
>

Neither. rpi is just a board. It's really a pwm driver for the bcm family
of SoC, so it should be called bcm_pwm. Any connections / configuration for
rpi is handled via FDT, right?

There's work underway to enumerate the modules you need on a system so one
could automate the subsetting of the drivers (as well as the loading), but
I'm not quite ready to turn that on end-to-end yet. The base infrastructure
is there, we can find modules for unattached devices, but the have to have
their ID tables (plug and play data) decorated appropriately. And that's
taking a lot of doing. My goal is to be completely deployed by BSDcan.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Hooking RPi PWM driver into tree

[Poul-Henning Kamp]

I wrote a device driver for PWM on the RPi's, but I have not yet
hooked it into the tree, because I'm unsure how we would want that.

I personally think by default it should be a module which is
only compiled for RPi kernels, but how does one do that ?

(Needless to say, it should also be possible to compile it into the
kernel for an RPi, but I know how to do that :-)

And do we want it to live in sys/modules/rpi_pwm or sys/modules/rpi/pwm ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"