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

[Warner Losh]

On Sun, Jan 28, 2018 at 10:34 AM, Emmanuel Vadot <manu at bidouilliste.com>
wrote:

> On 2018-01-28 00:14, Poul-Henning Kamp wrote:
>
>> --------
>> In message <20180127210801.37b8001125dd0a2c92372f98 at bidouilliste.com>,
>> Emmanuel Vadot writes:
>>
>> - We have a commiter that commited something for his own need: he
>>> wanted to use the pwm on his rpi, coded a driver (this part is good)
>>> but feel that the standard we were using was crap and commited his work
>>> without talking with arm developper on what the proper way to do it was.
>>>
>>  I don't entirely agree about that, I think RPi is a platform we
>>
> as project ignore at our peril, so I have started to do a little
>> bit of an effort, as I find time and information for it.
>>
>
>  And we all thank you for that.


The problems with RPi aren't going to be solved with simple quick hacks.
The port pre-dates our evolved views on using DTB, the upstream linux DTB
and the need to have more complete pinmux / clock / power support. Each
driver does it in an ad-hoc way now, meaning there's a lot of code in the
drivers that needs to be burned down before we can stand up a
replacement... Hopefully, these discussions will bear fruit in the near
term.

You keep yelling at me for not adhering to an entirely undocumented
>> design vision, which we don't even have a single compliant reference
>> platform for yet.
>>
>
>  Reference platform doesn't make much sense in the embedded world.
>  Even if you take the JUNO hardware (ARMv8 reference design, which I think
> we support to some extent), we don't support the GPIO/Pinmuxing I think and
> even if we do it's different than the controller on RPI (Or any other SoC).
> Well more like same-same but different stuff.
>  If you want a reference platform take the Allwinner code or IMX (I
> sometime look at the IMX code to check stuff because I know ian@ knows
> his stuff).


The embedded space is a high-context, fast moving space relative to x86. As
such, there will always be a certain amount of undocumentedness. It
requires closely working with the community of embedded developers in a way
that we've not had to do in x86 world since the patch-kit / 1.x days. A
long time ago, though, FreeBSD evolved a whole new VM w/o it having much of
a published design. Newbus went to market w/o good docs published, yet
everybody was expected to adopt it. The problems of documentation have
largely been corrected after things were built. The evolution of the
embedded space and how we can best support it with the minimal resources
the project has is similar. While there's no over-arching design document,
the broad outlines are there, and the interfaces we want to implement have
published specs, even if they aren't all implemented yet. In an ideal world
this would all be documented, published and anybody that shows up would
know the next steps to take. I'd love for that to be the case here, but we
don't have that today.

Warner