From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 03:45:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A31EC1065672; Sun, 8 Jul 2012 03:45:02 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 093218FC08; Sun, 8 Jul 2012 03:45:01 +0000 (UTC) Received: by werp13 with SMTP id p13so6946195wer.13 for ; Sat, 07 Jul 2012 20:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U+D6VfMM2kQNK9uaMHYA2P8UIhIpkPwnsCLznRT92Mo=; b=HebBeh8J8mi/23+/4aEtilloe6UXx9mJkGKZi2OHiur6X5kOhr952vQaPD6iDrN8ul M1waa7YGNOJ8P21PPBuLQKwlThaWi7vUars37SZgsjDWo5Wd5lMBH/p0fal+PVp+4Who hJzbT57757W8vebE1GAYiS+a40mY4Cj2SQupj/payopyEWK0s/O98Tq89Al39suUDxnj n5xFW5PdZiRppDixTlODv01o0/N1xbJSM2PR+tAEanrvfLNB596uxrgRqfrkNZJ4dm09 wIvd60brxMJ9Xxm2CoWyIV5qVafnLXtOhLPzwhVUJFx+tp5fARDrX60Wzs7fJb+SaF7r z8xw== MIME-Version: 1.0 Received: by 10.181.13.142 with SMTP id ey14mr19229386wid.19.1341719100905; Sat, 07 Jul 2012 20:45:00 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sat, 7 Jul 2012 20:45:00 -0700 (PDT) In-Reply-To: <1341686865.70246.22.camel@revolution.hippie.lan> References: <1341601751.70246.7.camel@revolution.hippie.lan> <1341686865.70246.22.camel@revolution.hippie.lan> Date: Sat, 7 Jul 2012 23:45:00 -0400 Message-ID: From: Arnaud Lacombe To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 08 Jul 2012 03:45:02 -0000 Hi, On Sat, Jul 7, 2012 at 2:47 PM, Ian Lepore wrote: > On Fri, 2012-07-06 at 16:45 -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore >> wrote: >> > On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: >> >> Hi, >> >> >> >> On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe wrote: >> >> > That's neither correct nor robust in a couple of way: >> >> > 1) you have no guarantee a device unit will always give you the same resource. >> >> this raises the following question: how can a device, today, figure >> >> out which parent in a given devclass would give it access to resources >> >> it needs. >> >> >> >> Say, you have gpiobus0 provided by a superio and gpiobus1 provided by >> >> the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 >> >> attachment is conditional to some BIOS setting. How can you tell >> >> gpioled(4) to attach on the chipset provided GPIO without hardcoding >> >> unit number either way ? >> >> >> >> AFAIK, you can not. >> >> >> >> Even hints provided layout description is defeated. Each device in a >> >> given devclass need to have a set of unique attribute to allow a child >> >> to distinguish it from other potential parent in the same devclass... >> >> >> >> - Arnaud >> > >> > Talking about a child being unable to choose the correct parent seems to >> > indicate that this whole problem is turned upside-down somehow; children >> > don't choose their parents. >> > >> actually, I think I was wrong, I thought device were attached to a >> devclass, but they are truly attached to a given device. My mistake. >> >> > Just blue-sky dreaming here on the fly... what we really have is a >> > resource-management problem. A device comes along that needs a GPIO >> > resource, how does it find and use that resource? >> > >> > Well, we have a resource manager, could that help somehow? Could a >> > driver that provides access to GPIO somehow register its availability so >> > that another driver can find and access it? The "resource" may be a >> > callable interface, it doesn't really matter, I'm just wondering if the >> > current rman stuff could be leveraged to help make the connection >> > between unrelated devices. I think that implies that there would have >> > to be something near the root of the hiearchy willing to be the >> > owner/manager of dynamic resources. >> > >> AFAIR, rman is mostly there to manage memory vs. i/o mapped resources. >> The more I think about it, the more FTD is the answer. The open >> question now being "how to map a flexible device structure (FTD) to a >> less flexible structure (Newbus)" :/ >> >> - Arnaud > > Memory- and IO-mapped regions and IRQs are the only current uses of rman > (that I know of), but it was designed to be fairly agnostic about the > resources it manages. It just works with ranges of values (that it > really doesn't know how to interpret at all), leaving lots of room to > define new types of things it can manage. > > The downside is that it's designed to be used hierarchically in the > context of newbus, specifically to help parents manage the resources > that they are able to provide to their children. Trying to use it in a > way that allows devices which are hierarchically unrelated to allocate > resources from each other may amount to a square-peg/round-hole > situation. But the alternative is writing a new facility to allow > registration and allocation of resources using some sort symbolic method > of representing the resources such that the new manager doesn't have to > know much about what it's managing. I think it would be better to find > a way to reuse what we've already got if that's possible. > > I think we have two semi-related aspects to this problem... > > How do we symbolically represent the resources that drivers can provide > to each other? (FDT may be the answer; I don't know much about it.) > > How do devices use that symbolic representation to locate the provider > of the resource, and how is the sharing of those resources managed? > I'd say FDT answer both question, take the DTS for "Freescale i.MX53 Smart Mobile Reference Design Board"[0], We first have SoC generic definition in `imx53.dtsi': soc { compatible = "simple-bus"; aips@50000000 { /* AIPS1 */ compatible = "fsl,aips-bus", "simple-bus"; spba@50000000 { compatible = "fsl,spba-bus", "simple-bus"; esdhc@50004000 { /* ESDHC1 */ compatible = "fsl,imx53-esdhc"; reg = <0x50004000 0x4000>; interrupts = <1>; status = "disabled"; }; [...] gpio2: gpio@53f8c000 { /* GPIO3 */ compatible = "fsl,imx53-gpio", "fsl,imx31-gpio"; reg = <0x53f8c000 0x4000>; }; gpio3: gpio@53f90000 { /* GPIO4 */ compatible = "fsl,imx53-gpio", "fsl,imx31-gpio"; reg = <0x53f90000 0x4000>; }; [...] } then board specific definition overriding its parent's in `imx53-smd.dts': soc { aips@50000000 { /* AIPS1 */ spba@50000000 { esdhc@50004000 { /* ESDHC1 */ cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */ wp-gpios = <&gpio3 11 0>; /* GPIO4_11 */ status = "okay"; }; [...] } Now the challenge is to make this to work within newbus. One of the problem I see is mixing FTD enumerated and bus (PCI, PnP ISA, ACPI, USB, ...) enumerated devices, in my specific case, a device using GPIO from a SuperIO and the chipset on the PCI bus. I would have to describe the SuperIO *and* the chipset GPIO in the FDT to be able to refer to them in my device... - Arnaud [0]: see Linux' arch/arm/boot/dts/imx53* > -- Ian > >