From owner-freebsd-current@freebsd.org Mon Jan 15 15:40:08 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFB2BEB54B8 for ; Mon, 15 Jan 2018 15:40:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 867827CD37 for ; Mon, 15 Jan 2018 15:40:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 85B0CEB54B4; Mon, 15 Jan 2018 15:40:08 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 855E0EB54B3 for ; Mon, 15 Jan 2018 15:40:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 1BAEB7CD30 for ; Mon, 15 Jan 2018 15:40:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-wm0-x229.google.com with SMTP id 143so2642602wma.5 for ; Mon, 15 Jan 2018 07:40:08 -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=yc/7uGXCk8Z1VSNdx1tgpd/MIkDLj8HJbPeMeCq83JM=; b=jkv1R8xKgovlkUU7cVafLZ2pxsix2limU04tbfZ9wIpN10/N4oNAlxgTWtakVXU2z/ ODUmw38dlov1OlOAyRqOcDRUnM2ZU4Yq5D5hellGp28rtot6RidxHe7X2gN2Vj3IRoxq TSpvhjZDueQClDzQX84vMJDVBq7kNNUB/b6++lUOr4CoUtRqnWh61VMHu5LJ+K/5aBWF BP7Fw8JmEUtfZPyDSptECTLZSG0czQdI4MPZruQOEkLyKBcCmDDVyKEJlFwrADdAWXpU N1qxnO1182dylOSvri/didiqn/pdd/vHvXG74t9z4z4eXpXxSt453Y9u8HNFF4TqlF8O idWw== 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=yc/7uGXCk8Z1VSNdx1tgpd/MIkDLj8HJbPeMeCq83JM=; b=aa4g/q/c5o2IukmlGZEShfZdHMfleAHiLBJqwjI4Df6i2ibbXur5FgSMDVhofDZ2WW oVZ1nXixp4mH93Gwwf4AU/iSipTrCQdNrnHedCxhF/OwtMB7mwzr31WqqlPiEGGVyhXz Xx7j7EgRirYsXyiaKGDX0Lxs4FaIEFrG1bnWOndlSnciN/8VyL8llB3pZSBv6N9UOiGd +rqXYcw6FZFc7ysyBS7DKvZFLnUWkwtWJlrGrP8L9wABfx2hLn3TJ8j6ZBK94/v89Lmh NTI4ot3e3giYH9WPONHrEkXi7IDn9hvOv8PrLOOtFhZ01PiCdD0P1wfEejWa0UEKiEJl r7ZQ== X-Gm-Message-State: AKGB3mLd2lXmY2L5xvL/FTEglipUCwlU2QoAFfSnl73yK+jOUG1EJVk8 VRB1tFYWfQ2nNFljFMRVw/kIJEd1cjsj+kS1cOM6hQ== X-Google-Smtp-Source: ACJfBos4xfwnIRkvIkfTIajKRtKmwF+uSTGE4UkKD6RYtl/1brRyouaNUwZqDYArghCOZmoGXC6xlnff93wB89BlRnI= X-Received: by 10.80.190.9 with SMTP id a9mr48810171edi.258.1516030804641; Mon, 15 Jan 2018 07:40:04 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.80.195.88 with HTTP; Mon, 15 Jan 2018 07:40:04 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <7203.1516015610@critter.freebsd.dk> References: <7203.1516015610@critter.freebsd.dk> From: Warner Losh Date: Mon, 15 Jan 2018 08:40:04 -0700 X-Google-Sender-Auth: z3uzzf6N1AYEGxyQcg2OmQgewko Message-ID: Subject: Re: Hooking RPi PWM driver into tree To: Poul-Henning Kamp Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 15:40:08 -0000 On Mon, Jan 15, 2018 at 4:26 AM, Poul-Henning Kamp wrote: > I wrote a device driver for PWM on the RPi's, but I have not yet > hooked it into the tree, because I'm unsure how we would want that. > > I personally think by default it should be a module which is > only compiled for RPi kernels, but how does one do that ? > We don't. We have no idea we're building for a particular kernel, so we don't subset the modules based on the kernel UNLESS the kernel config gives a list (MODULES_OVERRIDE). Compile it for armv[67] arm64 and we're fine (since those are the archs we have it for). Even this level of subsetting has grown painful, but there's not been a good fix for that yet either (and arguably, no bad fixes, just bad hacks that have grown up and proliferated to the point Something Must Be Done, but that turns out to be non-trivial to do in a way that doesn't replace one thicket of kludge with another :() In fact, on ARM, we've been moving to not building for specific boards, but having a GENERIC kernel that can be used everywhere. I'll be augmenting that with automatic driver loading based on the "plug and play" table data that's marked in the driver. (Needless to say, it should also be possible to compile it into the > kernel for an RPi, but I know how to do that :-) > Your best bet if you are creating a tiny distribution for this is to use MODULES_OVERRIDE in the kernel config so it's a module still, but not built into the kernel so you can load / unload as need arises. > And do we want it to live in sys/modules/rpi_pwm or sys/modules/rpi/pwm ? > Neither. rpi is just a board. It's really a pwm driver for the bcm family of SoC, so it should be called bcm_pwm. Any connections / configuration for rpi is handled via FDT, right? There's work underway to enumerate the modules you need on a system so one could automate the subsetting of the drivers (as well as the loading), but I'm not quite ready to turn that on end-to-end yet. The base infrastructure is there, we can find modules for unattached devices, but the have to have their ID tables (plug and play data) decorated appropriately. And that's taking a lot of doing. My goal is to be completely deployed by BSDcan. Warner