Date: Sat, 7 Jul 2012 23:04:55 -0600 From: Warner Losh <imp@bsdimp.com> To: Arnaud Lacombe <lacombar@gmail.com> Cc: Ian Lepore <freebsd@damnhippie.dyndns.org>, FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Interfacing devices with multiple parents within newbus Message-ID: <FF1E15B6-3AD7-4691-9036-6B66E4CB0AA3@bsdimp.com> In-Reply-To: <CACqU3MUewcBSzf6feUoeRFLNQaVhuEparApv-dO5R0Ht3YmEpQ@mail.gmail.com> 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> <CACqU3MUewcBSzf6feUoeRFLNQaVhuEparApv-dO5R0Ht3YmEpQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 7, 2012, at 9:45 PM, Arnaud Lacombe wrote:
> Hi,
>=20
> 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,
>>>=20
>>> 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,
>>>>>=20
>>>>> 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.
>>>>>=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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FF1E15B6-3AD7-4691-9036-6B66E4CB0AA3>