Date: Sat, 7 Jul 2012 23:45:00 -0400 From: Arnaud Lacombe <lacombar@gmail.com> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Interfacing devices with multiple parents within newbus Message-ID: <CACqU3MUewcBSzf6feUoeRFLNQaVhuEparApv-dO5R0Ht3YmEpQ@mail.gmail.com> In-Reply-To: <1341686865.70246.22.camel@revolution.hippie.lan> References: <CACqU3MU6iv%2Bo26fCdL5M6Kg6XMM1uZPih5FBiBKPOD9WDx%2BNGg@mail.gmail.com> <FEAC4049-11B0-4B3D-BB7A-0946DBBFF530@bsdimp.com> <CACqU3MWTKSpVRbJracCjSLVHko8RSpXw6vpC3o3UaAyTizos3A@mail.gmail.com> <CACqU3MX_xoHQ2HbvhUdj%2BVM4Dt34jANnhGkRG_xO6DM69AFc2Q@mail.gmail.com> <1341601751.70246.7.camel@revolution.hippie.lan> <CACqU3MUbsGBaXqc%2BGUBq8OXDsLHj1UZdtbEg0kYf0nUA-0Z7Kw@mail.gmail.com> <1341686865.70246.22.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
On Sat, Jul 7, 2012 at 2:47 PM, Ian Lepore
<freebsd@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@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@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@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
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACqU3MUewcBSzf6feUoeRFLNQaVhuEparApv-dO5R0Ht3YmEpQ>