On Jul 7, 2012, at 9:45 PM, Arnaud Lacombe wrote: > Hi, > > On Sat, Jul 7, 2012 at 2:47 PM, Ian Lepore > <freebsd_at_damnhippie.dyndns.org> 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 >>> <freebsd_at_damnhippie.dyndns.org> 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 <lacombar_at_gmail.com> 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_at_50000000 { /* AIPS1 */ > compatible = "fsl,aips-bus", "simple-bus"; > > spba_at_50000000 { > compatible = "fsl,spba-bus", "simple-bus"; > > esdhc_at_50004000 { /* ESDHC1 */ > compatible = "fsl,imx53-esdhc"; > reg = <0x50004000 0x4000>; > interrupts = <1>; > status = "disabled"; > }; > > [...] > > gpio2: gpio_at_53f8c000 { /* GPIO3 */ > compatible = "fsl,imx53-gpio", "fsl,imx31-gpio"; > reg = <0x53f8c000 0x4000>; > }; > > gpio3: gpio_at_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_at_50000000 { /* AIPS1 */ > spba_at_50000000 { > esdhc_at_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... 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 > > [0]: see Linux' arch/arm/boot/dts/imx53* > >> -- Ian >> >> > _______________________________________________ > freebsd-hackers_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe_at_freebsd.org"Received on Sun Jul 08 2012 - 03:05:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:28 UTC