From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 05:05:07 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99998106566B for ; Sun, 8 Jul 2012 05:05:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 83FEF8FC12 for ; Sun, 8 Jul 2012 05:05:06 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so18403192pbb.13 for ; Sat, 07 Jul 2012 22:05:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=TW9rTklz1TjMt39Mu+Qv/XscBwApKQZokjtafvl8Tzc=; b=N8D1EYGQzg1zz2TBWmEgiNhovg8qGSokBo6F2X2/XrU1XBhZvRRnfP026WvNYAJeze l+o5PO29exZ6geaEMLxzXeT7vx6NIGs9aUsVl3oZKI4ec0XrOciQudLMed++x+jk/XDU Qn6g3ds2fuziYnYtjBRvRujTurzdIemu0eQML2wHhXkhfIwaPS2YyWtxuVUhVHP3uzCV VyWa4ZSsHCu1M6qi9DqrP87rq4Z6vY1SteykScTSHMhhUGuf7Jz4BX4U6B8B7qZadR46 jDfwE2tjft9IKkKkxZHs5J5WPqIGPOpsCdoyEviOO6JmXK4BGCgbip02F0KWzC9a8142 xvRg== Received: by 10.66.84.71 with SMTP id w7mr56525402pay.33.1341723900265; Sat, 07 Jul 2012 22:05:00 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id tj8sm25088132pbc.10.2012.07.07.22.04.59 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 Jul 2012 22:04:59 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 7 Jul 2012 23:04:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1341601751.70246.7.camel@revolution.hippie.lan> <1341686865.70246.22.camel@revolution.hippie.lan> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnFxLCpF0D6W0oLot+zAa3PrFj+BzA/2WGVLO479ZDYDtVX2g/5sCXNStsjw8WFHDLXbC13 Cc: Ian Lepore , FreeBSD Current , FreeBSD Hackers Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 05:05:07 -0000 On Jul 7, 2012, at 9:45 PM, Arnaud Lacombe wrote: > Hi, >=20 > 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, >>>=20 >>> 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, >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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 ? >>>>>=20 >>>>> AFAIK, you can not. >>>>>=20 >>>>> 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... >>>>>=20 >>>>> - Arnaud >>>>=20 >>>> 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. >>>>=20 >>> 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. >>>=20 >>>> 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? >>>>=20 >>>> 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. >>>>=20 >>> 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)" :/ >>>=20 >>> - Arnaud >>=20 >> 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. >>=20 >> 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. >>=20 >> I think we have two semi-related aspects to this problem... >>=20 >> 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.) >>=20 >> How do devices use that symbolic representation to locate the = provider >> of the resource, and how is the sharing of those resources managed? >>=20 > I'd say FDT answer both question, take the DTS for "Freescale i.MX53 > Smart Mobile Reference Design Board"[0], >=20 > We first have SoC generic definition in `imx53.dtsi': >=20 > soc { > compatible =3D "simple-bus"; > aips@50000000 { /* AIPS1 */ > compatible =3D "fsl,aips-bus", "simple-bus"; >=20 > spba@50000000 { > compatible =3D "fsl,spba-bus", "simple-bus"; >=20 > esdhc@50004000 { /* ESDHC1 */ > compatible =3D "fsl,imx53-esdhc"; > reg =3D <0x50004000 0x4000>; > interrupts =3D <1>; > status =3D "disabled"; > }; >=20 > [...] >=20 > gpio2: gpio@53f8c000 { /* GPIO3 */ > compatible =3D "fsl,imx53-gpio", "fsl,imx31-gpio"; > reg =3D <0x53f8c000 0x4000>; > }; >=20 > gpio3: gpio@53f90000 { /* GPIO4 */ > compatible =3D "fsl,imx53-gpio", "fsl,imx31-gpio"; > reg =3D <0x53f90000 0x4000>; > }; >=20 > [...] > } >=20 > then board specific definition overriding its parent's in = `imx53-smd.dts': >=20 > soc { > aips@50000000 { /* AIPS1 */ > spba@50000000 { > esdhc@50004000 { /* ESDHC1 */ > cd-gpios =3D <&gpio2 13 0>; /* GPIO3_13 */ > wp-gpios =3D <&gpio3 11 0>; /* GPIO4_11 */ > status =3D "okay"; > }; >=20 > [...] > } >=20 > Now the challenge is to make this to work within newbus. >=20 > 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... I'm starting to think that newbus device names aren't a good fit here. = gpio2 isn't a newbus name, but an fdt one. I think that you'll the gpio = driver providing GPIO services that can map these pins to actions. = Trying to do it all within newbus likely is a mistake. At the very = least you'll want to make the providers have an earlier pass number than = the devices that are provided for. The GPIO driver should provide a = GPIO service or resource that other devices can access and use. This = would make it non unloadable (or effectively so), must like the PCI bus = is effectively non-unloadable since too many things will depend on this = device.... I face similar challenges in my work to refactor the Atmel GPIO stuff. Warner > - Arnaud >=20 > [0]: see Linux' arch/arm/boot/dts/imx53* >=20 >> -- Ian >>=20 >>=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org"