Date: Sun, 28 Jan 2018 18:34:59 +0100 From: Emmanuel Vadot <manu@bidouilliste.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Warner Losh <imp@bsdimp.com>, John Baldwin <jhb@freebsd.org>, Ravi Pokala <rpokala@mac.com>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org, owner-src-committers@freebsd.org Subject: Re: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules Message-ID: <8d8ae9d10058fd72ce3ec467181c9f22@megadrive.org> In-Reply-To: <72042.1517094867@critter.freebsd.dk> References: <201801220710.w0M7AUm9091853@repo.freebsd.org> <CANCZdfpq2QoG4EAj0VW2FF=4VXRv-qQKFfJTJerWH9YOwVoVBA@mail.gmail.com> <90451.1516663240@critter.freebsd.dk> <2987003.eeGRFBb6N8@ralph.baldwin.cx> <CANCZdfrh0NHq7cbkq_genEdzo%2BB3G4TTAcEzpgh11sr%2B82e9aw@mail.gmail.com> <93949.1516733748@critter.freebsd.dk> <20180127210801.37b8001125dd0a2c92372f98@bidouilliste.com> <72042.1517094867@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-01-28 00:14, Poul-Henning Kamp wrote: > -------- > In message <20180127210801.37b8001125dd0a2c92372f98@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@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8d8ae9d10058fd72ce3ec467181c9f22>