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

Warner Losh imp at bsdimp.com
Sun Jan 28 21:11:08 UTC 2018


On Sun, Jan 28, 2018 at 2:01 PM, Adrian Chadd <adrian.chadd at gmail.com>
wrote:

> [snip]
>
> And this is the root bit that's missing - dynamic pinmux/pinctrl stuff
> at runtime.
>

Well, you gotta walk before you can run. We don't even have static pinmx on
rpi. Though someone else is working on that.


> Warner's already said he's WIP'ing it and phk seems like a good test
> case for kicking those tyres, so it sounds like those tyres are about
> to be kicked.
>
> In the meantime, hacks allow people to make some progress, and as long
> as they're not on by default, it's okay. The challenge is finding the
> middle ground between "right" and "working". Some people are happy to
> do the legwork to do things right first; others are happy to do the
> end bits and then backfill the supporting infrastructure.
>

No. Such hacks are actively getting in the way. My WIP already breaks PHK's
hacks (unintentionally, but discovered in hindsight) because they are
outside the mainstream. I have 0 interest in preserving short-term hacks
through the longer-term fixes, and while I'd rather not step on toes, I
don't really feel bad in cases like this... However, my WiP is more about
fixing some issues in NEWBUS / devctl and trying to have some order in the
"Let's change 'disabled' it at runtime" with enough hooks so that we do
more than just turn on the device driver for the device, but also integrate
the new state into the dependencies, like pinmux/pinctl. We'll need that
regardless of whether we need a quick hack to turn them on/off or we allow
loading DTB overlays at runtime. Unlike x86 where you might have not
attached fxp0 and just need to call fxp_attach() (basically) to make it
work, in the embedded space, you'll have lots of unhappy campers if you
don't also deal with the dependent power, clock and pin resources.


> Fun times, fun times! I'm just happy to see more RPI support. That
> platform still isn't dying.
>

Yea, otherwise we could kill armv6 completely.

Warner


More information about the svn-src-head mailing list