Re: Interfacing devices with multiple parents within newbus
On Friday, July 06, 2012 4:45:55 pm 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)" :/ Note that IRQs are also managed in rman. However, that is a complicated beast. Generally there is some sideband way for interrupt controllers to register their available interrupt pins with the platform's nexus driver (often the actual PIC is not managed via new-bus). You then need something else to let a given device know which interrupt pin it wants (e.g. PCI interrupt routing). However, you could make a similar approach work for GPIO perhaps, where devices make GPIO pins available to a rman that other devices then allocate from. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interfacing devices with multiple parents within newbus
On Jul 7, 2012, at 9:45 PM, Arnaud Lacombe wrote:
> 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@5000 { /* AIPS1 */
>compatible = "fsl,aips-bus", "simple-bus";
>
>spba@5000 {
> 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@53f9 { /* GPIO4 */
> compatible = "fsl,imx53-gpio", "fsl,imx31-gpio";
> reg = <0x53f9
Re: Interfacing devices with multiple parents within newbus
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@5000 { /* AIPS1 */
compatible = "fsl,aips-bus", "simple-bus";
spba@5000 {
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@53f9 { /* GPIO4 */
compatible = "fsl,imx53-gpio", "fsl,imx31-gpio";
reg = <0x53f9 0x4000>;
};
[...]
}
then board specific definition overriding its parent's in `imx53-smd.dts':
soc {
aips@5000 { /* AIPS1 */
spba@5
Re: Interfacing devices with multiple parents within newbus
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? -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interfacing devices with multiple parents within newbus
On Jul 6, 2012, at 1:09 PM, Ian Lepore wrote: > 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? I rather like that idea. The connection between devices is more like meta-data needed to obtain the resources/services that other devices provide. You really want to talk in those terms, rather than in newbus attachments. The platform told me that pin AT91_PIOA_12 is my interrupt line. I'd like to wire up an ISR to that please. The platform told me that pin AT91_PIOC_33 is the data pin for my two wire bus. An error happened and to reset it I need to tell the pin muxing service to take it off line. then I need to tell the GPIO service I have to force it high, let it flow, and force it low. The platform told me that this NIC is connected to PHY 2 on miibus 3. I'm the NIC driver and want to connect. I'm the USB subsystem. I'd like to know if one or two usb ports are connected to the HUB. The hardware can't tell me, so the platform code has to give me hints. If I allocate the pins for each of those two ports I'll know. In some configurations, I can get both sets. In others, I can only get one set. All of those problems could be solved with newbus kobj connections. Or they could be solved by the platform and/or drivers registering resources and services and the other drivers in the system using it. Multipass would help a lot with that, since you could probe/attach all the service providers first, then everybody else could talk the higher level interfaces. Warner P.S. multipass could solve the dependency problem, but in kinda a poor way... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interfacing devices with multiple parents within newbus
On Jul 7, 2012, at 6:25 AM, Stefan Bethke wrote: > Am 06.07.2012 um 17:33 schrieb Arnaud Lacombe: > >> I assume you are talking about devclass_get_device()/device_find_child(). >> >> 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. >> 2) there is no reference counting on the returned device. >> 3) there is no track record of the reference being given. >> >> About (1), lower unit devices can fails to attach[0], thus newly >> attached bus will now have a negative offset. >> >> About (2) and (3), referenced device (think KLD) might go away and the >> child will not be told. In this situation, I want the child to be >> detached prior to its parent. >> >> As such, looking up other node by name would fit in what I call >> "bypassing newbus purpose". I might just as well export a damn >> function pointer and make my life easier. > > I believe there is one more thing that needs to be addressed, which I ran > into while trying to do the arge/mdio attachment: > > 4) the device attach method may require access to the other device to > complete the attachment, but that other might not be attached yet. > > Circular dependencies nonwithstanding, it would be highly desirable for a > device driver developer to be able to simply declare all prerequisites for > attachment, and have newbus call attach only after everything is there. Right > now, the drivers attach method is called by the parent bus as soon as > enumeration is completed. The device should go ahead and attach. When multiple devices need to communicate with each other, they need to coordinate things. newbus is a weak coordination mechanism. Stronger coordination mechanisms would be FDT or ACPI which can tie known devices to a device_t rather than to just a name. The device_t will be around even if that device is attached and detached. > A notification mechanism (similar to the devfs notification but with an > exposed KPI) might be an alternative, as mentioned in this thread. This would also work. However, many of proposed uses for this seem more and more to me to need a non-newbus mechanism to cope with. You'll absolutely require the notification method since devices can detach at any time. Circular dependencies are way too easy to create. In the Atmel work I'm doing and have done, there's devices that provide services to other devices (mostly pin muxing and GPIO). I don't try to get the GPIO device to attach first, but rather have routines that can be called to accomplish these things. During the early boot, I have to use the GPIO device to turn on pins so that I can even talk to things like the MII bus of the internal NIC. While the GPIO devices have device_t's to allocate resources and to create dev_t nodes, I don't marshal everything through newbus. When I want to map a pin as an interrupt source for the PHY chip, that call is made directly. When I need to shut off a device's pin and instead drive it via the GPIO logic, that's just a call. etc. Warner___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interfacing devices with multiple parents within newbus
Am 06.07.2012 um 17:33 schrieb Arnaud Lacombe: > I assume you are talking about devclass_get_device()/device_find_child(). > > 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. > 2) there is no reference counting on the returned device. > 3) there is no track record of the reference being given. > > About (1), lower unit devices can fails to attach[0], thus newly > attached bus will now have a negative offset. > > About (2) and (3), referenced device (think KLD) might go away and the > child will not be told. In this situation, I want the child to be > detached prior to its parent. > > As such, looking up other node by name would fit in what I call > "bypassing newbus purpose". I might just as well export a damn > function pointer and make my life easier. I believe there is one more thing that needs to be addressed, which I ran into while trying to do the arge/mdio attachment: 4) the device attach method may require access to the other device to complete the attachment, but that other might not be attached yet. Circular dependencies nonwithstanding, it would be highly desirable for a device driver developer to be able to simply declare all prerequisites for attachment, and have newbus call attach only after everything is there. Right now, the drivers attach method is called by the parent bus as soon as enumeration is completed. A notification mechanism (similar to the devfs notification but with an exposed KPI) might be an alternative, as mentioned in this thread. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interfacing devices with multiple parents within newbus
On 07/06/12 22:45, 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. I am unsure whether I understand the problem completely, but.. 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. I agree, that on a very abstract level, this is exactly how this should work. In my opinion, what we need here is: a) A way for a driver to locate the resource it needs. That can be done using FDT facility. If the driver knows, that it needs certain resource (like memory, gpio or whatever else), it could process DTB (using OF_*) looking up the node holding that resource. b) Knowing the node (phandle or name), OS could locate appropriate device_t (or even driver) in the tree-hierarchy created by fdtbus (e.g. by iterating by every device_t in the tree). Each device_t created by fdtbus (or simplebus) does keep the information about the DTS (or DTB) node name via ivars. So iterating through device_t-s, we could compare node names hold in ivars with the name of the node for needed resource, and thus find proper device_t. I think this is not currently possible. Note, that other way around -- getting node's phandle based on device_t *is* implemented via ofwbus(fdtbus_ofw_get_node()). I think if this is really needed, ofwbus(fdtbus) could be easily extended by adding a routine like fdtbus_ofw_get_device_for_node(). -LW 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 ___ freebsd-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" -- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interfacing devices with multiple parents within newbus
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interfacing devices with multiple parents within newbus
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. 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. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interfacing devices with multiple parents within newbus
On Jul 6, 2012, at 12:46 PM, 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... hints can hard-wire the device to a given bus. This also can hard-wire the unit number, which will be stable even if one of them fails to attach. But since the FDT language provides a richer set of connections than is possible with raw newbus, perhaps the solution to your problem should be handled in the FDT domain where you can look up a device name and have the FDT layer do the proper mapping into newbus rather than trying to guess at unit numbers. The reference count problem would still be there, but that's a different issue that we have all over the place and need to solve before we can properly lock NEWBUS. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interfacing devices with multiple parents within newbus
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interfacing devices with multiple parents within newbus
Hi,
On Fri, Jul 6, 2012 at 1:04 AM, Warner Losh wrote:
>
> On Jul 5, 2012, at 5:14 PM, Arnaud Lacombe wrote:
>
>> Hi folks,
>>
>> The problem has been raised in the last BSDCan during a talk, but no
>> clear answer has been given. Some (pseudo-)devices might require
>> resources from multiple other (pseudo-)devices.
>>
>> For example, a device is sitting on an SMBus, but need to access a
>> software controlled LED, sitting on a GPIO bus, itself sitting on an
>> LPC bus... Or a variant where everything is controlled on the same
>> chip, but different GPIO banks. For that specific example, all the
>> GPIO pin could be implement on the same GPIObus, however, gpiobus(4)
>> is limited to 32 pins and the chip provides 5 banks of 8 pins, ie. a
>> total of 40 pins[0]. In the same idea, a device sitting on GPIOs
>> controlled by two independant chips, say one being an ICH10R chipset
>> on a PCI device function, and the other being a
>> SuperIO on an LPC bus.
>>
>> This situation make me really dubious that FreeBSD will be able to
>> support configuration such as:
>>
>> esdhc@50004000 { /* ESDHC1 */
>>cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */
>>wp-gpios = <&gpio3 11 0>; /* GPIO4_11 */
>>status = "okay";
>> };
>>
>> or:
>>
>> ecspi@5001 { /* ECSPI1 */
>>fsl,spi-num-chipselects = <2>;
>>cs-gpios = <&gpio1 30 0>, /* GPIO2_30 */
>> <&gpio2 19 0>; /* GPIO3_19 */
>>status = "okay";
>> [...]
>>
>> This example is taken from Linux' `arch/arm/boot/dts/imx53-smd.dts'.
>> Here, SDHC or SPI controller are using different GPIO devices. Note
>> that these GPIO pins does not seem to be multi-function pins as
>> another .dts defines ESDHC1 as:
>>
>> esdhc@50004000 { /* ESDHC1 */
>>cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */
>>wp-gpios = <&gpio2 14 0>; /* GPIO3_14 */
>>status = "okay";
>> };
>>
>> AFAIK, newbus is unable to model any of the above situation without
>> being bypassed one way or another.
>>
>> any hints ?
>
> That's not correct. You don't need a parent-child relationship in newbus to
> interact with another node in the tree. You can look up the other node by
> name, and then call functions based on finding that other device.
>
I assume you are talking about devclass_get_device()/device_find_child().
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.
2) there is no reference counting on the returned device.
3) there is no track record of the reference being given.
About (1), lower unit devices can fails to attach[0], thus newly
attached bus will now have a negative offset.
About (2) and (3), referenced device (think KLD) might go away and the
child will not be told. In this situation, I want the child to be
detached prior to its parent.
As such, looking up other node by name would fit in what I call
"bypassing newbus purpose". I might just as well export a damn
function pointer and make my life easier.
What would be need is an interface where the child need to have a way
to say "resources I need are not complete, tell me when a new device
in devclass Z is attached that I can check if it fills my need", ala:
- dev0 is probed
- dev0 tells it is present, but need unavailable resource in devclass
X and devclass Y
- dev0 is marked as pending
- dev1 is attached in devclass X
- dev0 is asked if dev1 would suit it
- dev0 answers negatively
- dev2 is attached in devclass X
- dev0 is asked if dev2 would suit it
- dev0 answers positively
- dev0 continues its probe, but still need unavailable resource in devclass Y
- dev3 is attached in devclass Y
- dev0 is asked if dev3 would suit it
- dev0 answers positively
- dev0 finishes its probe
- dev0 is attached
[...]
- dev3 is to be detached
- dev0 is detached
- dev3 is detached
- Arnaud
[0]: for many reason; hardware failure, configuration change (think
GPIO on multi-function pin)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interfacing devices with multiple parents within newbus
On Jul 5, 2012, at 5:14 PM, Arnaud Lacombe wrote:
> Hi folks,
>
> The problem has been raised in the last BSDCan during a talk, but no
> clear answer has been given. Some (pseudo-)devices might require
> resources from multiple other (pseudo-)devices.
>
> For example, a device is sitting on an SMBus, but need to access a
> software controlled LED, sitting on a GPIO bus, itself sitting on an
> LPC bus... Or a variant where everything is controlled on the same
> chip, but different GPIO banks. For that specific example, all the
> GPIO pin could be implement on the same GPIObus, however, gpiobus(4)
> is limited to 32 pins and the chip provides 5 banks of 8 pins, ie. a
> total of 40 pins[0]. In the same idea, a device sitting on GPIOs
> controlled by two independant chips, say one being an ICH10R chipset
> on a PCI device function, and the other being a
> SuperIO on an LPC bus.
>
> This situation make me really dubious that FreeBSD will be able to
> support configuration such as:
>
> esdhc@50004000 { /* ESDHC1 */
>cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */
>wp-gpios = <&gpio3 11 0>; /* GPIO4_11 */
>status = "okay";
> };
>
> or:
>
> ecspi@5001 { /* ECSPI1 */
>fsl,spi-num-chipselects = <2>;
>cs-gpios = <&gpio1 30 0>, /* GPIO2_30 */
> <&gpio2 19 0>; /* GPIO3_19 */
>status = "okay";
> [...]
>
> This example is taken from Linux' `arch/arm/boot/dts/imx53-smd.dts'.
> Here, SDHC or SPI controller are using different GPIO devices. Note
> that these GPIO pins does not seem to be multi-function pins as
> another .dts defines ESDHC1 as:
>
> esdhc@50004000 { /* ESDHC1 */
>cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */
>wp-gpios = <&gpio2 14 0>; /* GPIO3_14 */
>status = "okay";
> };
>
> AFAIK, newbus is unable to model any of the above situation without
> being bypassed one way or another.
>
> any hints ?
That's not correct. You don't need a parent-child relationship in newbus to
interact with another node in the tree. You can look up the other node by
name, and then call functions based on finding that other device.
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
