From owner-svn-src-head@freebsd.org Sun Jan 28 18:35:02 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D64DDED8024; Sun, 28 Jan 2018 18:35:01 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E40EF69398; Sun, 28 Jan 2018 18:35:00 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 5487b4c9; Sun, 28 Jan 2018 18:34:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; s=mail; bh=QjuWIT NZ4WqRyDj31+V9ALoeHvM=; b=IssP0+mC9W73RPoIOuOM7jKH2sKq+fq1lXDhX8 RgtNQ2pA9342DwoPGdBcqbAH4TcPHpNs1FWGUBsG6lDOvGjUppBPW9yN1knpetdn y5SucITtE+jWfzS0RV3dOq3UAWf1EEgUaG/6ochO+tEd9L0OrkChTuafNCAml4Hc 0gMqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; q=dns; s=mail; b= Ra23rHBRhFKoCRP3ygDtkSZT/zKXcdEnl9NXjYZkixK1Wyc8YCjH9tYzpO1o7A4w wxT/eo76EVvrwnsOb7VaZGZ5JoRbXAH3TWr6dUN+62k6AdQ1sU815qiuXNDw6Ax0 Sb9t94uHSHKafWuj18pO9i1MScNgqhla9f5chLjBk28= Received: from webmail.megadrive.org (www1.blih.net [212.83.177.180]) by mail.blih.net (OpenSMTPD) with ESMTP id 65c42984; Sun, 28 Jan 2018 18:34:59 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 28 Jan 2018 18:34:59 +0100 From: Emmanuel Vadot To: Poul-Henning Kamp Cc: Warner Losh , John Baldwin , Ravi Pokala , src-committers , 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 Organization: Bidouilliste In-Reply-To: <72042.1517094867@critter.freebsd.dk> References: <201801220710.w0M7AUm9091853@repo.freebsd.org> <90451.1516663240@critter.freebsd.dk> <2987003.eeGRFBb6N8@ralph.baldwin.cx> <93949.1516733748@critter.freebsd.dk> <20180127210801.37b8001125dd0a2c92372f98@bidouilliste.com> <72042.1517094867@critter.freebsd.dk> Message-ID: <8d8ae9d10058fd72ce3ec467181c9f22@megadrive.org> X-Sender: manu@bidouilliste.com User-Agent: Roundcube Webmail/1.1.1 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 18:35:02 -0000 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