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

[Emmanuel Vadot]

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.
> 
> First, as a general rule, I think you should leave it to me to
> express what I think and feel, because you truly suck at it.

  Noted.

> FDT may or may not be the right technology to use, I take no position
> on that, because I am not the one doing all the work to implement
> it, and I certainly don't propose to do the work to come up with
> an alternative.
> 
>> - Now we have a crappy driver in the tree.
> 
> 1. Hardly our first

  Not a good reason

> 2. "Crappy driver" is not pass/fail, we grade that on a curve.
> 
> 3. You confuse "I don't like" with "crappy"

  On that case no.

>> - We still have this driver that doesn't follow the standard we said 
>> we
>> want to adhere to.
> 
> And part of that decision, clearly explained for all who participated
> in making it, was that we should time-warp back to FreeBSD 1.X where
> hardware changes always required a reboot ?
> 
> Right, I didn't think so...

  Sometimes it makes sense to reboot.

> Maybe we *also* need to make some decisions about *how* we want
> this FDT stuff to work for us in practice?
> 
> My summary of the situation:
> 
> Everybody I have communicated with over the last couple of months
> have given me clear indication that nothing significant will happen
> on the RPi platform, which people see as inferior and not worth
> the/any effort.

  Mostly true yes.

> 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.

> 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 stuff (clock manager, pin manager, runtime overlays) you are
> upset about me not using, does not exist on the RPi platform in
> FreeBSD at this point in time, which is why I don't use them.

  I'm not upset at you for not using, I'm "upset" at you for not wanting 
to make the effort to implement them. Some are hard, some are easy.

> There is no documentation anywhere to be found, how to implement
> these hypothetical pieces of code, which is why I don't implement
> them.

  Yes and as I already say we all know that arm documentation sucks but 
it didn't prevent any of the other developer to implement stuff on other 
SoCs.

> I am quite tempted to quote Gen. Patton on you and say "Lead me,
> Follow me, or get out of my way", but that would be a bit too rude.
> 
> Instead I will repeat what I have already said to you several times:
> 
> The moment the correct infrastructure appears on the RPi platform,
> if it ever does, I will change my driver to use that infrastructure.

  This is where I (and probably) other don't agree, this is backward.
  We must implement first proper pinctrl driver and clock management 
instead of introduce hacks.

> Until then, you are wasting everybodys time pointing accusingly
> into your book of unwritten rules.
> 
> Poul-Henning

  What's funny though is that even with a pinctrl and clock management, 
we still don't have what is necessary to implement what you want 
(kldloading a driver and directly use pwm). For that we need overlays at 
runtime, pinmuxing at runtime and probably other things too.

  I think we are both adults (not sure for me or if I want to be one but 
let's pretend that I am), so let me ask you one more time to backout 
your commit and let's work together to extend arm support toward what 
you want to do.

  Thanks,

-- 
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>