From owner-svn-src-head@freebsd.org Sun Jan 28 21:21:18 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 98711EDFC09 for ; Sun, 28 Jan 2018 21:21:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B18296F193 for ; Sun, 28 Jan 2018 21:21:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id k131so6032314ith.4 for ; Sun, 28 Jan 2018 13:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2oa3yEGGm7zDUc+/KQZRJZvD4EfyjNCKHcTEoFH8WC8=; b=UysyVbLdPal48POoU+aMV7gLglkdw9zJf9Co3PC6mp6bE2e8wpbgHxNpGXjrRAIPZX pYc46H6w77jpu9D0xWgLliuKTR+qiaoN6/gLas6DPkFliioWwplU+8/HrZHW0zKwM8IQ 6KS6c0qjUGaR+ylUDxKVpDTnguDzywvvCSIpHP2exvcC95g4cGov1CGQu2a+QR2LK7Uq wvB/1qahMhuYWT0SDuoTdAoOaPlyJg9ZdSubW0X3Ll1UpyOssEpyht1UgbxpojOrTtLQ /z+Ov9I9Q3TVXypdgUvGvnt8+b9mTmMbVLWqY7U+52Q/zWjQepSRLI8aTOMQhK0bXdHC i0sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2oa3yEGGm7zDUc+/KQZRJZvD4EfyjNCKHcTEoFH8WC8=; b=cJgyjrG7++iG/A0gaG9/EaarInUXvIkLnNu56L3bKyV+BIBfjANQwMWrU+p71X6dWw Fq+zL2KyaTMeKX74+vUM/r37DqO6c0paM4PiRK1iF6lNzU70O5QcAvCqyZx38vTOuczc uKJOOEDfnDWyOzqOKs2m52pEC7qFqFffyOcDT5yeup9U80pHBt9Mpw2vYzkQcrSfO4fw rMoUp0IiBMEtwhEkPn1RxiU9H+pi1LOVtnIMk1JzJEqvjGSCQ8StceXG1cUXeI/oMjLd fGyxbCwKqIDNDZbbKeskjAxwAfdKg1NjM38brojTLF+czqIXVAL6yPAuh5fbmT9ytsUG E0Mg== X-Gm-Message-State: AKwxytfU2wstLQxm4Skk5vvJPl0Nwwe04K8Tv05Uo/gxoFFpiLAt0Arn ttO23jaTi0OA1w0hKRtwQmIPH7lBeqfP4PprFfOkZw== X-Google-Smtp-Source: AH8x225aKu/gP/k1vNzPF0mZfj2JsGt2mFV+uPEKMr2fEu0abi7LUsuFAjjLHcH6NY38Spw57bDKbL7B6wJKAm6om54= X-Received: by 10.36.104.210 with SMTP id v201mr23042988itb.64.1517174477031; Sun, 28 Jan 2018 13:21:17 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Sun, 28 Jan 2018 13:21:16 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <8d8ae9d10058fd72ce3ec467181c9f22@megadrive.org> 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> <8d8ae9d10058fd72ce3ec467181c9f22@megadrive.org> From: Warner Losh Date: Sun, 28 Jan 2018 14:21:16 -0700 X-Google-Sender-Auth: xiUC-ub-Zjb1mMT26WZ8gm_ub6Y Message-ID: Subject: Re: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules To: Emmanuel Vadot Cc: Poul-Henning Kamp , John Baldwin , Ravi Pokala , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org, owner-src-committers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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 21:21:18 -0000 On Sun, Jan 28, 2018 at 10:34 AM, Emmanuel Vadot wrote: > 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. >>> >> 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