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

[Poul-Henning Kamp]

--------
In message <CANCZdfrQg+k_3iH8QpM-1v-WbuDBwFutg5Lp+zN1hTKcqucZ9w at mail.gmail.com>, Warner Losh writes:

>> The moment the correct infrastructure appears on the RPi platform,
>> if it ever does, I will change my driver to use that infrastructure.
>
>The root of the problem is that we have the right infrastructure...
>Everywhere except RPi. It needs a proper pinmux/pinctl driver. That's the
>next step in fixing this issue. If you don't want to be part of fixing
>that, then get out of the way.

My driver is not built into any kernels, you have to kldload it AND
configure it via sysctls before it can possibly get in the way of
anything, so yes:  I am out of the way.

>The next step, though, is to bring the RPI's infrastructure up to speed
>with the rest of the arm ports... That's where time is best spent,
>honestly. Fighting a never ending series of one-off kludges is doomed to
>failure.

I don't think the two evenings I spent in my lap measuring and
figuring out what the datasheet didn't say and said wrong about the
PWM hardware is a failure just because a couple of hardware
unrelated lines of source code needs to be changed at a later date.

>We're there on
>boot on every other armv7/arm64 platform, just not there incrementally at
>runtime. Some work would be needed to make that happen, but I think I have a
>reasonable design that I've started to socialize... You're welcome to join in
>in making it happen, if you like....

With the limited time I have available, I will.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.