On 2018-01-28 00:14, Poul-Henning Kamp wrote:
--------
In message <20180127210801.37b8001125dd0a2c92372...@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 <m...@bidouilliste.com> <m...@freebsd.org>
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
