Re: Non-enumerable devices on USB and other enumerable buses
On Tue, Aug 20, 2013 at 12:01 AM, Mark Brown broo...@kernel.org wrote: On Mon, Aug 19, 2013 at 08:17:53PM +0800, Ming Lei wrote: On Sat, Aug 17, 2013 at 9:29 AM, Alan Stern st...@rowland.harvard.edu wrote: Aong those lines, I would like to point out that the device concept embodied in the kernel's data structures can be pretty thin. For example, it might be little more than a port number or bus address. Maybe the principle behind drivers/usb/core/usb-acpi.c is helpful for the problem, and DT may refer to ACPI to describe on-board USB devices, and the way to retrieve platform data too. I can't parse this at all well - why would DT want to refer to ACPI, do you mean people may wish to look at the code as an example? As Grant I mean usb-acpi provides one approach to retrieve platform data for USB device during device enumeration, and the idea might be helpful for you to implement similar things based on DT. noted DT already has some mechanisms for enumerable buses which looking at the code appears to be broadly what that's doing. If the mechanism is ready now, so looks you might post code for review and discussion? Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Tue, Aug 20, 2013 at 09:19:07PM +0800, Ming Lei wrote: On Tue, Aug 20, 2013 at 12:01 AM, Mark Brown broo...@kernel.org wrote: I can't parse this at all well - why would DT want to refer to ACPI, do you mean people may wish to look at the code as an example? As Grant I mean usb-acpi provides one approach to retrieve platform data for USB device during device enumeration, and the idea might be helpful for you to implement similar things based on DT. Ah, OK. noted DT already has some mechanisms for enumerable buses which looking at the code appears to be broadly what that's doing. If the mechanism is ready now, so looks you might post code for review and discussion? There's nothing there for the problem I'm talking about here (devices that haven't been enumerated yet) and I don't off the top of my head know if the enumerated case is supported by any buses in Linux yet. It is part of the DT specifications and has been implemented on other OSs but I'd need to go check if Linux actually went and implemented any of that. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Fri, 16 Aug 2013, Mark Brown wrote: On Fri, Aug 16, 2013 at 03:27:58PM -0400, Alan Stern wrote: On Fri, 16 Aug 2013, Mark Brown wrote: or those for getting platform data to a device when it does enumerate. ? I can't make any sense out of that comment. For one thing, why do you need to send platform data to a device? (It's obvious that a _driver_ would need to use platform data; it's not so clear that a _device_ would.) The device in this context is a running instance of the driver. It's kind of difficult to understand what you're saying. Obviously the literal meaning is not what you had in mind, because a device can't be a driver (or even a running instance of a driver). Maybe you meant that the word device above should have been the word driver. So you seem to be saying that significant modifications would be needed to get platform information to the driver. I don't see why. Lots and lots of drivers use platform information right now. Besides, you need to get the platform information to the driver in any case, no matter how you decide to solve the chicken-and-egg problem. It shouldn't be a factor in deciding which solution to use. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Fri, 16 Aug 2013, Mark Brown wrote: The difficulty with the first proposal is that subsystems aren't designed to allow that sort of thing. They expect to be able to communicate with the devices they manage, during enumeration and probing at least. The difficulty with the second proposal is that it requires duplicating the power-on code. My feeling is that the second answer involves less work and less complexity than the first. Both proposals require additional run-once code (to do the partial instantiations or the initial power-ons), but the first proposal also requires the subsystem's detection and enumeration routines to be adjusted so that they can work even when the device is incommunicado. Right, but like I say I'm not sure that the modifications required are substantially different to those for handling a device powering up and down on the bus I believe they are. At the very least, a larger set of modifications would be needed, because the subsystem's device-init and enumeration routines would have to be changed to work with a powered-down device, as would the driver's probe routine. Whereas handling a device powering up and down on the bus merely requires the subsystem's connection-change routine to be modified. or those for getting platform data to a device when it does enumerate. ? I can't make any sense out of that comment. For one thing, why do you need to send platform data to a device? (It's obvious that a _driver_ would need to use platform data; it's not so clear that a _device_ would.) But even assuming you really do need to send platform data to the device when it enumerates, don't the subsystem and driver already take care of sending this data? If they didn't then presumably the device wouldn't be usable. Therefore it seems that _no_ modifications should be needed for this purpose. I'd also not be so sure about the run once code, that is only the case for devices that can't completely idle themselves at runtime. (The second proposal also has the advantage that the power-on code may be shared between the driver and the subsystem.) Can you explain in more detail please, I don't follow? Let's say the subsystem powers up the device when the bus is first registered, so that the device can be detected and enumerated. Let's also say that the driver wants to power-off and power-on the device from time to time, as part of normal runtime PM. Then instead of having its own power-on routine (which would be code duplication), the driver can simply call the subsystem's power-on routine. (Of course, this would mean that the routine would no longer be run-once.) Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Sat, Aug 17, 2013 at 9:29 AM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 16 Aug 2013, Mark Brown wrote: Besides, you need to get the platform information to the driver in any case, no matter how you decide to solve the chicken-and-egg problem. It shouldn't be a factor in deciding which solution to use. It's not that this is hard, it's that I don't see how if you already have some concept of the device in the kernel data structures (which you must have in order to be able to provide platform data when it's needed) anything is gained by not using that when dealing with bootstrapping issues. I agree. In fact, there's no choice but to use this device concept during startup. Otherwise there's no way to get the platform data to the driver when it is needed, because there's no way to tell which device the data applies to. The question is how elaborate the concept needs to be and how it gets used. Aong those lines, I would like to point out that the device concept embodied in the kernel's data structures can be pretty thin. For example, it might be little more than a port number or bus address. Maybe the principle behind drivers/usb/core/usb-acpi.c is helpful for the problem, and DT may refer to ACPI to describe on-board USB devices, and the way to retrieve platform data too. Anyway, I think it's time to try to implement something rather than talk about it. Hopefully this discussion has given you some ideas for alternative approachs, or at least helped to solidify your ideas. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Mon, Aug 19, 2013 at 08:17:53PM +0800, Ming Lei wrote: On Sat, Aug 17, 2013 at 9:29 AM, Alan Stern st...@rowland.harvard.edu wrote: Aong those lines, I would like to point out that the device concept embodied in the kernel's data structures can be pretty thin. For example, it might be little more than a port number or bus address. Maybe the principle behind drivers/usb/core/usb-acpi.c is helpful for the problem, and DT may refer to ACPI to describe on-board USB devices, and the way to retrieve platform data too. I can't parse this at all well - why would DT want to refer to ACPI, do you mean people may wish to look at the code as an example? As Grant noted DT already has some mechanisms for enumerable buses which looking at the code appears to be broadly what that's doing. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Thu, 15 Aug 2013, Mark Brown wrote: No, this really is something that's very much generic to the device and will apply to anywhere the silicon is used. The power on process for a device isn't something that changes, the mapping of resources that might be used in that sequence is but we've got good abstractions for pretty much all the resources that a device might need - clocks, power, GPIOs and so on - which do the mapping of those resources onto the device at board level so neither the provider not the user need to know about it. That's just data and is much easier to encode in DT or equivalent than actual sequences. We've got a bunch of existing drivers in the kernel which do this sort of stuff, they ask for resources and then know what to do with them and can also make use of these resources at runtime if they want. Okay, let's see if I understand your problem. You've got a driver that knows how to manage its devices, including how to power them on and off. But the driver can't bind to one of these devices until the device has appeared on the bus and been enumerated, and that won't happen until the device has been powered on. It's a chicken-and-egg sort of thing. You know about the existence of these devices beforehand because that knowledge is encapsulated in platform information somewhere. The question is how best to use this information to solve the chicken-and-egg problem. Is that it? One possible answer is to use the platform information to (partially) instantiate the device before it has been detected, so that the driver can bind to it. Another is to use the platform information to perform an initial power-up of the device, so that it can be detected, enumerated, and probed in the normal manner. The difficulty with the first proposal is that subsystems aren't designed to allow that sort of thing. They expect to be able to communicate with the devices they manage, during enumeration and probing at least. The difficulty with the second proposal is that it requires duplicating the power-on code. My feeling is that the second answer involves less work and less complexity than the first. Both proposals require additional run-once code (to do the partial instantiations or the initial power-ons), but the first proposal also requires the subsystem's detection and enumeration routines to be adjusted so that they can work even when the device is incommunicado. (The second proposal also has the advantage that the power-on code may be shared between the driver and the subsystem.) Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Fri, Aug 16, 2013 at 10:42:10AM -0400, Alan Stern wrote: Okay, let's see if I understand your problem. You've got a driver that ... Is that it? Yes, I think that's it. The difficulty with the first proposal is that subsystems aren't designed to allow that sort of thing. They expect to be able to communicate with the devices they manage, during enumeration and probing at least. The difficulty with the second proposal is that it requires duplicating the power-on code. My feeling is that the second answer involves less work and less complexity than the first. Both proposals require additional run-once code (to do the partial instantiations or the initial power-ons), but the first proposal also requires the subsystem's detection and enumeration routines to be adjusted so that they can work even when the device is incommunicado. Right, but like I say I'm not sure that the modifications required are substantially different to those for handling a device powering up and down on the bus or those for getting platform data to a device when it does enumerate. I'd also not be so sure about the run once code, that is only the case for devices that can't completely idle themselves at runtime. (The second proposal also has the advantage that the power-on code may be shared between the driver and the subsystem.) Can you explain in more detail please, I don't follow? signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Fri, Aug 16, 2013 at 03:27:58PM -0400, Alan Stern wrote: On Fri, 16 Aug 2013, Mark Brown wrote: or those for getting platform data to a device when it does enumerate. ? I can't make any sense out of that comment. For one thing, why do you need to send platform data to a device? (It's obvious that a _driver_ would need to use platform data; it's not so clear that a _device_ would.) The device in this context is a running instance of the driver. (The second proposal also has the advantage that the power-on code may be shared between the driver and the subsystem.) Can you explain in more detail please, I don't follow? Let's say the subsystem powers up the device when the bus is first registered, so that the device can be detected and enumerated. Let's also say that the driver wants to power-off and power-on the device from time to time, as part of normal runtime PM. Then instead of having its own power-on routine (which would be code duplication), the driver can simply call the subsystem's power-on routine. (Of course, this would mean that the routine would no longer be run-once.) Oh, OK. I don't think that's a meaningful difference, the driver is going to have the code and be able to reuse it one way or another anyway. In many cases if the device has been in a low power idle mode a slightly difference sequence would be needed anyway. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Fri, Aug 16, 2013 at 04:39:47PM -0400, Alan Stern wrote: On Fri, 16 Aug 2013, Mark Brown wrote: The device in this context is a running instance of the driver. It's kind of difficult to understand what you're saying. Obviously the literal meaning is not what you had in mind, because a device can't be a driver (or even a running instance of a driver). Maybe you meant that the word device above should have been the word driver. I don't think using device to refer to an instance of the running driver is that obscure a usage to be honest... So you seem to be saying that significant modifications would be needed to get platform information to the driver. I don't see why. Lots and lots of drivers use platform information right now. Besides, you need to get the platform information to the driver in any case, no matter how you decide to solve the chicken-and-egg problem. It shouldn't be a factor in deciding which solution to use. It's not that this is hard, it's that I don't see how if you already have some concept of the device in the kernel data structures (which you must have in order to be able to provide platform data when it's needed) anything is gained by not using that when dealing with bootstrapping issues. Anyway, I think it's time to try to implement something rather than talk about it. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Fri, 16 Aug 2013, Mark Brown wrote: Besides, you need to get the platform information to the driver in any case, no matter how you decide to solve the chicken-and-egg problem. It shouldn't be a factor in deciding which solution to use. It's not that this is hard, it's that I don't see how if you already have some concept of the device in the kernel data structures (which you must have in order to be able to provide platform data when it's needed) anything is gained by not using that when dealing with bootstrapping issues. I agree. In fact, there's no choice but to use this device concept during startup. Otherwise there's no way to get the platform data to the driver when it is needed, because there's no way to tell which device the data applies to. The question is how elaborate the concept needs to be and how it gets used. Aong those lines, I would like to point out that the device concept embodied in the kernel's data structures can be pretty thin. For example, it might be little more than a port number or bus address. Anyway, I think it's time to try to implement something rather than talk about it. Hopefully this discussion has given you some ideas for alternative approachs, or at least helped to solidify your ideas. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Thu, 15 Aug 2013, Mark Brown wrote: On Wed, Aug 14, 2013 at 03:39:20PM -0400, Alan Stern wrote: I don't see the point of all this. Obviously the device can't be used until it physically appears on the bus. What benefit do you get from registering it and making it available to userspace before that? Two things. One is that some devices have the ability to perform useful functions when powered down sufficiently that they can't run a complex bus, providing notification when they need to wake up (or being woken up if the power on comes from userspace). The other is that then userspace can just see the device and start using it when it needs it without having to have a mechanism to discover that there's something there with manual power control. This can also be an issue in cases where we compose multiple physical devices into composite ones for userspace (embedded audio and video do this a lot for example). A given bit of hardware may only be useful in some circumstances. Well, basic power this on stuff is pretty much all we have discussed in this thread so far. What other sorts of things are going to be needed for a general solution? If you look elsewhere at the stuff I've been saying about Slimbus that's the nastiest case I'm aware of in terms of the bus itself - that's got the devices with low power modes that do useful things with the device (and bus) mostly powered off and things like that. Things like activity detection of various kinds where the device is monitoring for activity in a low power state. Okay. Previously we agreed that a device on one of these buses could remain off-line except when the system needs to bring it to full power. To me, discovery and enumeration on the bus seem like a legitimate need. So why not bring the device to full power as soon as possible during boot, and have it registered on the bus in the usual way? Once that's done, the ordinary runtime PM mechanism will allow the device to go back off-line. I've also mentioned the devices that need platform data which is a part of this too; one reason for knowing that the device is there before it appears is so that we can pass platform data/DT/whatever to it. Can you pass this whatever data to the device as part of the initial bring-it-to-full-power procedure? By the way, you mentioned something earlier that some of this platform data might duplicate information that could be discovered through the usual bus probing mechanisms (for example, USB descriptors). IMO that's a bad idea. Not only is it wasteful, it also has the potential for causing confusion if the two sets of data should disagree for any reason. When possible, it's always better to get info about the hardware from the hardware itself. Now I'm getting confused. It seems we're talking about at least three very different things here: A: Devising a mechanism for platform code to do things involving devices that are dynamically registered on discoverable buses. If we need random platform code then we're failing, half the point of things like DT and ACPI is to avoid writing random board code. we do want to pass data to devices for their drivers to use but having to have random bits of per board code would be really sad. At the level of abstraction in this discussion, there's no need to discriminate between code and data. Just imagine that I simply wrote platform, meaning platform code and/or data. B: Telling the subsystem and driver code for a discoverable bus that a particular device is present before it has been detected. C: Implementing a mechanism whereby drivers can take a device off-line while still pretending to userspace that the device is still present, by bringing it back on-line as needed. I don't see much connection between these things. Perhaps you can explain in more detail. I think the solutions for these overlap so much they're the same thing. The situation we're in in in your case B is just the idle case for condition C - if we know about the device before it's been detected then if it's been removed we just go back into the situation where we know about it but it isn't powered. I imagine that teaching a subsystem to know about a device before it has been detected would require significant changes. My suggestion -- powering up the device, detecting it, and then powering it back down -- fits in very cleanly with existing designs and would require comparatively little work. Case B then becomes unnecessary; all the important stuff will be handled under Case C. (BTW, it's worth mentioning that C has already been done, in the form of runtime PM. The difference may be that you propose to take the device so far off-line that it disappears from the bus. AFAICS, this would be purely a private matter to be arranged between the subsystem and the driver; it does not need to be handled at the
Re: Non-enumerable devices on USB and other enumerable buses
On Thu, Aug 15, 2013 at 10:42:00AM -0400, Alan Stern wrote: On Thu, 15 Aug 2013, Mark Brown wrote: So why not bring the device to full power as soon as possible during boot, and have it registered on the bus in the usual way? Once that's done, the ordinary runtime PM mechanism will allow the device to go back off-line. That could be done, and is likely to happen anyway as a result of device initialisation. I'm not sure it buys much to force it to happen immediately, though. I've also mentioned the devices that need platform data which is a part of this too; one reason for knowing that the device is there before it appears is so that we can pass platform data/DT/whatever to it. Can you pass this whatever data to the device as part of the initial bring-it-to-full-power procedure? It is often going to be required as part of the bring it to full power procedure. By the way, you mentioned something earlier that some of this platform data might duplicate information that could be discovered through the usual bus probing mechanisms (for example, USB descriptors). IMO that's a bad idea. Not only is it wasteful, it also has the potential If you check the discussion it pretty much consisted of everyone saying that duplicating enumerable information was a terrible idea. A: Devising a mechanism for platform code to do things involving devices that are dynamically registered on discoverable buses. If we need random platform code then we're failing, half the point of things like DT and ACPI is to avoid writing random board code. we do want to pass data to devices for their drivers to use but having to have random bits of per board code would be really sad. At the level of abstraction in this discussion, there's no need to discriminate between code and data. Just imagine that I simply wrote platform, meaning platform code and/or data. There's a big difference between random glue outside the drivers and something the drivers know about themselves, it's important to be clear on this. Bodges for this often involve writing a bit of board code that the drivers don't know anything about. B: Telling the subsystem and driver code for a discoverable bus that a particular device is present before it has been detected. I think the solutions for these overlap so much they're the same thing. The situation we're in in in your case B is just the idle case for condition C - if we know about the device before it's been detected then if it's been removed we just go back into the situation where we know about it but it isn't powered. I imagine that teaching a subsystem to know about a device before it has been detected would require significant changes. My suggestion -- powering up the device, detecting it, and then powering it back down -- fits in very cleanly with existing designs and would require comparatively little work. Case B then becomes unnecessary; all the important stuff will be handled under Case C. To be honest I don't see how that helps much if you're going to handle the case where platform data is required to enumerate the device. You need to know about the device prior to enumeration in order to get the platform data to the driver when it does enumerate and you can't enumerate it until you do that anyway. A bus could insist on this if it needed the information from enumeration for some reason but really it seems like an implementation detail. There's one important factor to keep in mind: Are devices on the bus physically removable? If not, the situation is pretty straightforward. You just remember that the device used to be present, and reuse the old data structures when it reappears. Not the ones I'm talking about, though other removable devices may possibly be present on the same bus. My interest is in the case where we know the chip is there because we can see it soldered to the board. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Thu, 15 Aug 2013, Mark Brown wrote: On Thu, Aug 15, 2013 at 10:42:00AM -0400, Alan Stern wrote: On Thu, 15 Aug 2013, Mark Brown wrote: So why not bring the device to full power as soon as possible during boot, and have it registered on the bus in the usual way? Once that's done, the ordinary runtime PM mechanism will allow the device to go back off-line. That could be done, and is likely to happen anyway as a result of device initialisation. I'm not sure it buys much to force it to happen immediately, though. Not necessarily immediately, then. Let's say at the time when you would have wanted to tell the bus about the device's existence, even though it hadn't yet been detected. There's a big difference between random glue outside the drivers and something the drivers know about themselves, it's important to be clear on this. Bodges for this often involve writing a bit of board code that the drivers don't know anything about. Of course. Glue outside of drivers is very significant, whether that glue takes the form of code or data. I imagine that teaching a subsystem to know about a device before it has been detected would require significant changes. My suggestion -- powering up the device, detecting it, and then powering it back down -- fits in very cleanly with existing designs and would require comparatively little work. Case B then becomes unnecessary; all the important stuff will be handled under Case C. To be honest I don't see how that helps much if you're going to handle the case where platform data is required to enumerate the device. You need to know about the device prior to enumeration in order to get the platform data to the driver when it does enumerate and you can't enumerate it until you do that anyway. You're a little imprecise here. Which driver do you mean? The driver that will ultimately bind to the device, or the driver that will discover and enumerate it (which generally is bound to the device's upstream parent)? I'll assume the latter. Under what circumstances is platform data required to enumerate a device on a discoverable bus? We're assuming the platform has already taken care of everything required to make the device appear on the bus in the usual manner (such as bringing it to full power). Can you give an example where something more is needed? (Were you thinking of the case where the device's IRQ signal doesn't go over the bus but uses a different platform mechanism? I don't quite see how this can work. What about devices on the bus that aren't known to the platform beforehand? How do they send their IRQ signals?) A bus could insist on this if it needed the information from enumeration for some reason but really it seems like an implementation detail. It isn't an implementation detail. The power-up for initial detection scheme is a general solution to the problem of setting up a complicated communication path between the bus and the platform. (I.e., it gives a simple way to avoid the need for this communication, that can be used on any discoverable bus.) It also is a general solution for avoiding the problem of registering a device on a bus before that device has been discovered and enumerated. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Thu, Aug 15, 2013 at 01:55:18PM -0400, Alan Stern wrote: On Thu, 15 Aug 2013, Mark Brown wrote: On Thu, Aug 15, 2013 at 10:42:00AM -0400, Alan Stern wrote: To be honest I don't see how that helps much if you're going to handle the case where platform data is required to enumerate the device. You need to know about the device prior to enumeration in order to get the platform data to the driver when it does enumerate and you can't enumerate it until you do that anyway. You're a little imprecise here. Which driver do you mean? The driver that will ultimately bind to the device, or the driver that will discover and enumerate it (which generally is bound to the device's upstream parent)? I'll assume the latter. The driver that's binding to the device - obviously going through teaching all controller drivers about how to start up any random child device they might encounter is not going to be a good idea, this should be encapsulated in the child driver. Under what circumstances is platform data required to enumerate a device on a discoverable bus? We're assuming the platform has already taken care of everything required to make the device appear on the bus in the usual manner (such as bringing it to full power). Can you give an example where something more is needed? Powering on the device is exactly the sort of thing I'm talking about here. I'm not sure what you think the platform is here but it sounds awfully like the sort of random board specific bodge code that people currently use - something has got to know what's needed to get the device up and running and how to do it and the device driver seems like the sensible place to do that. (Were you thinking of the case where the device's IRQ signal doesn't go over the bus but uses a different platform mechanism? I don't quite see how this can work. What about devices on the bus that aren't known to the platform beforehand? How do they send their IRQ signals?) Either the bus doesn't support anything like interrupts at all or they'd use the standard bus mechanisms. Typical reasons for bypassing the bus include things like latency and power, or excessive cost for implementation on the device side. A bus could insist on this if it needed the information from enumeration for some reason but really it seems like an implementation detail. It isn't an implementation detail. The power-up for initial detection scheme is a general solution to the problem of setting up a complicated communication path between the bus and the platform. (I.e., it gives a simple way to avoid the need for this communication, that can be used on any discoverable bus.) It also is a general solution for avoiding the problem of registering a device on a bus before that device has been discovered and enumerated. I think I completely misunderstood what you mean by powering up on initial use. If you're saying that we should have some platform code for doing this I don't think that's a scalable solution. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Thu, 15 Aug 2013, Mark Brown wrote: On Thu, Aug 15, 2013 at 01:55:18PM -0400, Alan Stern wrote: On Thu, 15 Aug 2013, Mark Brown wrote: On Thu, Aug 15, 2013 at 10:42:00AM -0400, Alan Stern wrote: To be honest I don't see how that helps much if you're going to handle the case where platform data is required to enumerate the device. You need to know about the device prior to enumeration in order to get the platform data to the driver when it does enumerate and you can't enumerate it until you do that anyway. You're a little imprecise here. Which driver do you mean? The driver that will ultimately bind to the device, or the driver that will discover and enumerate it (which generally is bound to the device's upstream parent)? I'll assume the latter. The driver that's binding to the device - obviously going through teaching all controller drivers about how to start up any random child device they might encounter is not going to be a good idea, this should be encapsulated in the child driver. Okay. Here's a restatement of what you wrote above: In the case where platform data is required to enumerate the device, you need to know about the device prior to enumeration. Obviously true. You need to get the platform data to the driver when it does enumerate. Not necessarily; see below. Under what circumstances is platform data required to enumerate a device on a discoverable bus? We're assuming the platform has already taken care of everything required to make the device appear on the bus in the usual manner (such as bringing it to full power). Can you give an example where something more is needed? Powering on the device is exactly the sort of thing I'm talking about here. So something needs to power-on the device. But what? The driver that enumerates it, or some other part of the kernel? If some other part of the kernel takes care of this then you _don't_ have to get the platform data to the driver when it enumerates. I'm not sure what you think the platform is here but it sounds awfully like the sort of random board specific bodge code that people currently use - something has got to know what's needed to get the device up and running and how to do it and the device driver seems like the sensible place to do that. Just the reverse. The driver should deal with things it knows about: how to discover and enumerate devices on its bus. It should not contain anything platform-specific. Adding this in would be a logistical nightmare -- you'd have to stuff power-on procedures for all sorts of different platforms into this one poor driver! I think I completely misunderstood what you mean by powering up on initial use. If you're saying that we should have some platform code for doing this I don't think that's a scalable solution. How can it be avoided? The powering-up operation is platform-specific. By definition, whatever code carries out the operation is platform code. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Thu, Aug 15, 2013 at 04:42:01PM -0400, Alan Stern wrote: Okay. Here's a restatement of what you wrote above: In the case where platform data is required to enumerate the device, you need to know about the device prior to enumeration. Obviously true. You need to get the platform data to the driver when it does enumerate. Not necessarily; see below. I think this is pretty essential - there is no point in having platform data if you can't pass it to the device. It needs to make it to the driver at the very least by the time the probe function runs. Powering on the device is exactly the sort of thing I'm talking about here. So something needs to power-on the device. But what? The driver that enumerates it, or some other part of the kernel? If some other part of the kernel takes care of this then you _don't_ have to get the platform data to the driver when it enumerates. Right, but my contention would be that if it's not the driver for the device that is being instantiated it's probably not going to be anything scalable since that's where we generally put our knowledge of a given bit of silicon. I'm not sure what you think the platform is here but it sounds awfully like the sort of random board specific bodge code that people currently use - something has got to know what's needed to get the device up and running and how to do it and the device driver seems like the sensible place to do that. Just the reverse. The driver should deal with things it knows about: how to discover and enumerate devices on its bus. It should not For a bus controller of course, they should be totally out of this. contain anything platform-specific. Adding this in would be a logistical nightmare -- you'd have to stuff power-on procedures for all sorts of different platforms into this one poor driver! No, this really is something that's very much generic to the device and will apply to anywhere the silicon is used. The power on process for a device isn't something that changes, the mapping of resources that might be used in that sequence is but we've got good abstractions for pretty much all the resources that a device might need - clocks, power, GPIOs and so on - which do the mapping of those resources onto the device at board level so neither the provider not the user need to know about it. That's just data and is much easier to encode in DT or equivalent than actual sequences. We've got a bunch of existing drivers in the kernel which do this sort of stuff, they ask for resources and then know what to do with them and can also make use of these resources at runtime if they want. I think I completely misunderstood what you mean by powering up on initial use. If you're saying that we should have some platform code for doing this I don't think that's a scalable solution. How can it be avoided? The powering-up operation is platform-specific. By definition, whatever code carries out the operation is platform code. Like I say device power management isn't system specific, it's silicon specific - think of what's in the driver as being the power up sequence from the datasheet. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Mon, Aug 12, 2013 at 09:04:00PM -0400, Alan Stern wrote: The bus code would need hooks installed wherever the platform wants to do something extra. This could end up growing to a lot of hooks. How can the whole thing be done in a reasonable fashion? I'd expect that we're just looking at hooks around connection and disconnection here here - if we're looking at much more it seems like we must be doing something wrong. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Wed, 14 Aug 2013, Mark Brown wrote: On Mon, Aug 12, 2013 at 09:04:00PM -0400, Alan Stern wrote: The bus code would need hooks installed wherever the platform wants to do something extra. This could end up growing to a lot of hooks. How can the whole thing be done in a reasonable fashion? I'd expect that we're just looking at hooks around connection and disconnection here here - if we're looking at much more it seems like we must be doing something wrong. Connection and disconnection of what? In the example mentioned earlier, the GPIOs to power an on-board USB hub would have to be initialized when the host controller was started. You wouldn't want to wait for the on-board hub to be detected, because without those GPIOs set properly, it never would be discovered on the USB bus. Right? Perhaps the platform-level code would need to hook into the places where the discoverable bus is registered and unregistered. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Wed, Aug 14, 2013 at 10:27:26AM -0400, Alan Stern wrote: On Wed, 14 Aug 2013, Mark Brown wrote: I'd expect that we're just looking at hooks around connection and disconnection here here - if we're looking at much more it seems like we must be doing something wrong. Connection and disconnection of what? The device on the bus. In the example mentioned earlier, the GPIOs to power an on-board USB hub would have to be initialized when the host controller was started. You wouldn't want to wait for the on-board hub to be detected, because without those GPIOs set properly, it never would be discovered on the USB bus. Right? Yes, so you'd want callbacks when the device actually appears and disappears. Perhaps the platform-level code would need to hook into the places where the discoverable bus is registered and unregistered. We'd need some way to get information to the drivers still, and to handle drivers that want to stop and start things. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Wed, 14 Aug 2013, Mark Brown wrote: On Wed, Aug 14, 2013 at 10:27:26AM -0400, Alan Stern wrote: On Wed, 14 Aug 2013, Mark Brown wrote: I'd expect that we're just looking at hooks around connection and disconnection here here - if we're looking at much more it seems like we must be doing something wrong. Connection and disconnection of what? The device on the bus. In the example mentioned earlier, the GPIOs to power an on-board USB hub would have to be initialized when the host controller was started. You wouldn't want to wait for the on-board hub to be detected, because without those GPIOs set properly, it never would be discovered on the USB bus. Right? Yes, so you'd want callbacks when the device actually appears and disappears. No, no -- this is exactly the point I was trying to make. The on-board hub _won't_ appear on the USB bus until the GPIOs are set. Therefore the callback to set the GPIOs needs to be at a different place, not when the device appears. Perhaps the platform-level code would need to hook into the places where the discoverable bus is registered and unregistered. We'd need some way to get information to the drivers still, and to handle drivers that want to stop and start things. Um... What exactly does this mean? It's so generic, it could apply to anything under drivers/. After all, what driver doesn't want to stop and start things? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Wed, Aug 14, 2013 at 12:14:06PM -0400, Alan Stern wrote: On Wed, 14 Aug 2013, Mark Brown wrote: Yes, so you'd want callbacks when the device actually appears and disappears. No, no -- this is exactly the point I was trying to make. The on-board hub _won't_ appear on the USB bus until the GPIOs are set. Therefore the callback to set the GPIOs needs to be at a different place, not when the device appears. What I'm proposing is that we have a way of telling buses that devices exist via a mechanism other than their actually being visible on the bus at the current time. If you're doing that the driver can be running prior to the hardware being there, just like it does with all the non-enumerable buses. Perhaps the platform-level code would need to hook into the places where the discoverable bus is registered and unregistered. We'd need some way to get information to the drivers still, and to handle drivers that want to stop and start things. Um... What exactly does this mean? It's so generic, it could apply to anything under drivers/. After all, what driver doesn't want to stop and start things? It means that there are situations where a driver wants to take the hardware offline but still offer services to userspace which will require the hardware to be brought on line again. The fact that this is a very generic thing is exactly why I'm raising this as a generic issue. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Wed, 14 Aug 2013, Mark Brown wrote: On Wed, Aug 14, 2013 at 12:14:06PM -0400, Alan Stern wrote: On Wed, 14 Aug 2013, Mark Brown wrote: Yes, so you'd want callbacks when the device actually appears and disappears. No, no -- this is exactly the point I was trying to make. The on-board hub _won't_ appear on the USB bus until the GPIOs are set. Therefore the callback to set the GPIOs needs to be at a different place, not when the device appears. What I'm proposing is that we have a way of telling buses that devices exist via a mechanism other than their actually being visible on the bus at the current time. If you're doing that the driver can be running prior to the hardware being there, just like it does with all the non-enumerable buses. This may work for other buses, but it isn't feasible for USB. Not only do many of the drivers need to communicate with their device during their probe routine, the subsystem itself needs to communicate with the device before many of the important data structures can be constructed. Without these structures, the device can't be bound to a driver. We wouldn't even know which driver to bind it to! My impression is that much of what you want could be handled by a platform callback invoked when a particular bus -- i.e., one whose upstream controller is a particular platform device -- is registered. Is that correct? For example, in the USB case, the on-board hub's GPIOs could be set when the USB bus is registered (or perhaps when the bus's root hub is registered). It means that there are situations where a driver wants to take the hardware offline but still offer services to userspace which will require the hardware to be brought on line again. The fact that this is a very generic thing is exactly why I'm raising this as a generic issue. This is a separate issue, more or less independent of whether the platform needs to carry out special actions for the device in question. If you're suggesting these off-line/on-line transitions are appropriate places for a platform hook, then yes, that makes sense. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Wed, Aug 14, 2013 at 02:35:07PM -0400, Alan Stern wrote: On Wed, 14 Aug 2013, Mark Brown wrote: What I'm proposing is that we have a way of telling buses that devices exist via a mechanism other than their actually being visible on the bus at the current time. If you're doing that the driver can be running prior to the hardware being there, just like it does with all the non-enumerable buses. This may work for other buses, but it isn't feasible for USB. Not only do many of the drivers need to communicate with their device during their probe routine, the subsystem itself needs to communicate with the device before many of the important data structures can be constructed. Without these structures, the device can't be bound to a driver. We wouldn't even know which driver to bind it to! The identification information for the device would of course have to be provided as part of registering that the device was going to appear - I'd expect to provide the same information that's read out of the hardware during enumeration, with enumeration checking to see if it knows about the device already. My impression is that much of what you want could be handled by a platform callback invoked when a particular bus -- i.e., one whose upstream controller is a particular platform device -- is registered. Is that correct? For example, in the USB case, the on-board hub's GPIOs could be set when the USB bus is registered (or perhaps when the bus's root hub is registered). That sort of bodge is probably adequate for basic power this on stuff but it's not going to scale to a general solution, especially where the driver wants to use some of the information at runtime. Currently systems are doing things like bodging callbacks into controller drivers which is basically what you're talking about here. It means that there are situations where a driver wants to take the hardware offline but still offer services to userspace which will require the hardware to be brought on line again. The fact that this is a very generic thing is exactly why I'm raising this as a generic issue. This is a separate issue, more or less independent of whether the platform needs to carry out special actions for the device in question. If you're suggesting these off-line/on-line transitions are appropriate places for a platform hook, then yes, that makes sense. I think in the general case it's the same issue - grab all the resources and enable them at probe time is the simplest implementation but it's not the only one by a long stretch. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Wed, Aug 14, 2013 at 10:30:44AM -0600, Stephen Warren wrote: On 08/14/2013 10:14 AM, Alan Stern wrote: No, no -- this is exactly the point I was trying to make. The on-board hub _won't_ appear on the USB bus until the GPIOs are set. Therefore the callback to set the GPIOs needs to be at a different place, not when the device appears. The device Mark was talking about is the controller end of the bus (EHCI controller, or hub's downstream port) not the device end of the bus (any USB device's upstream port). Actually it genuinely is a hub - it's not part of the controller, though the startup does need to be synchronised with the controller. It ends up parenting some other devices but that's not suchan issue. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Wed, 14 Aug 2013, Mark Brown wrote: On Wed, Aug 14, 2013 at 02:35:07PM -0400, Alan Stern wrote: On Wed, 14 Aug 2013, Mark Brown wrote: What I'm proposing is that we have a way of telling buses that devices exist via a mechanism other than their actually being visible on the bus at the current time. If you're doing that the driver can be running prior to the hardware being there, just like it does with all the non-enumerable buses. This may work for other buses, but it isn't feasible for USB. Not only do many of the drivers need to communicate with their device during their probe routine, the subsystem itself needs to communicate with the device before many of the important data structures can be constructed. Without these structures, the device can't be bound to a driver. We wouldn't even know which driver to bind it to! The identification information for the device would of course have to be provided as part of registering that the device was going to appear - I'd expect to provide the same information that's read out of the hardware during enumeration, with enumeration checking to see if it knows about the device already. I don't see the point of all this. Obviously the device can't be used until it physically appears on the bus. What benefit do you get from registering it and making it available to userspace before that? My impression is that much of what you want could be handled by a platform callback invoked when a particular bus -- i.e., one whose upstream controller is a particular platform device -- is registered. Is that correct? For example, in the USB case, the on-board hub's GPIOs could be set when the USB bus is registered (or perhaps when the bus's root hub is registered). That sort of bodge is probably adequate for basic power this on stuff but it's not going to scale to a general solution, especially where the driver wants to use some of the information at runtime. Currently systems are doing things like bodging callbacks into controller drivers which is basically what you're talking about here. Well, basic power this on stuff is pretty much all we have discussed in this thread so far. What other sorts of things are going to be needed for a general solution? It means that there are situations where a driver wants to take the hardware offline but still offer services to userspace which will require the hardware to be brought on line again. The fact that this is a very generic thing is exactly why I'm raising this as a generic issue. This is a separate issue, more or less independent of whether the platform needs to carry out special actions for the device in question. If you're suggesting these off-line/on-line transitions are appropriate places for a platform hook, then yes, that makes sense. I think in the general case it's the same issue - grab all the resources and enable them at probe time is the simplest implementation but it's not the only one by a long stretch. Now I'm getting confused. It seems we're talking about at least three very different things here: A: Devising a mechanism for platform code to do things involving devices that are dynamically registered on discoverable buses. B: Telling the subsystem and driver code for a discoverable bus that a particular device is present before it has been detected. C: Implementing a mechanism whereby drivers can take a device off-line while still pretending to userspace that the device is still present, by bringing it back on-line as needed. I don't see much connection between these things. Perhaps you can explain in more detail. (BTW, it's worth mentioning that C has already been done, in the form of runtime PM. The difference may be that you propose to take the device so far off-line that it disappears from the bus. AFAICS, this would be purely a private matter to be arranged between the subsystem and the driver; it does not need to be handled at the level of the device-model or PM core.) Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Non-enumerable devices on USB and other enumerable buses
From: Alan Stern Sent: Wednesday, August 14, 2013 12:39 PM Now I'm getting confused. It seems we're talking about at least three very different things here: A: Devising a mechanism for platform code to do things involving devices that are dynamically registered on discoverable buses. B: Telling the subsystem and driver code for a discoverable bus that a particular device is present before it has been detected. C: Implementing a mechanism whereby drivers can take a device off-line while still pretending to userspace that the device is still present, by bringing it back on-line as needed. I don't see much connection between these things. Perhaps you can explain in more detail. (BTW, it's worth mentioning that C has already been done, in the form of runtime PM. The difference may be that you propose to take the device so far off-line that it disappears from the bus. AFAICS, this would be purely a private matter to be arranged between the subsystem and the driver; it does not need to be handled at the level of the device-model or PM core.) Mark's original complaint about USB was this: One example that's bugging me right now is that on the Insignal Arndale platform there's a USB hub connected to one of the USB ports on the SoC (not as a PHY, it seems we also need the internal PHY running to talk to the device). The hub needs to be plugged into the SoC after the SoC USB controller has started with some GPIOs so we need to tell the system that the hub exists and needs to be synchronised with the USB controller. This sounds to me like the normal discovery mechanism for USB isn't getting kicked off because no Connect Status Change is being triggered on the root port when the hub is brought online using the GPIOs. Maybe the port has been runtime suspended because no device was attached originally? So maybe the only thing needed for USB is a way to tell the parent port to frob its port control bits to try to determine if a device is now present. (set Wake on Connect Enable? Do a Port Reset? Cycle the Port Power bit if possible?) -- Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Wed, Aug 14, 2013 at 03:39:20PM -0400, Alan Stern wrote: I don't see the point of all this. Obviously the device can't be used until it physically appears on the bus. What benefit do you get from registering it and making it available to userspace before that? Two things. One is that some devices have the ability to perform useful functions when powered down sufficiently that they can't run a complex bus, providing notification when they need to wake up (or being woken up if the power on comes from userspace). The other is that then userspace can just see the device and start using it when it needs it without having to have a mechanism to discover that there's something there with manual power control. This can also be an issue in cases where we compose multiple physical devices into composite ones for userspace (embedded audio and video do this a lot for example). A given bit of hardware may only be useful in some circumstances. Well, basic power this on stuff is pretty much all we have discussed in this thread so far. What other sorts of things are going to be needed for a general solution? If you look elsewhere at the stuff I've been saying about Slimbus that's the nastiest case I'm aware of in terms of the bus itself - that's got the devices with low power modes that do useful things with the device (and bus) mostly powered off and things like that. Things like activity detection of various kinds where the device is monitoring for activity in a low power state. I've also mentioned the devices that need platform data which is a part of this too; one reason for knowing that the device is there before it appears is so that we can pass platform data/DT/whatever to it. Now I'm getting confused. It seems we're talking about at least three very different things here: A: Devising a mechanism for platform code to do things involving devices that are dynamically registered on discoverable buses. If we need random platform code then we're failing, half the point of things like DT and ACPI is to avoid writing random board code. we do want to pass data to devices for their drivers to use but having to have random bits of per board code would be really sad. B: Telling the subsystem and driver code for a discoverable bus that a particular device is present before it has been detected. C: Implementing a mechanism whereby drivers can take a device off-line while still pretending to userspace that the device is still present, by bringing it back on-line as needed. I don't see much connection between these things. Perhaps you can explain in more detail. I think the solutions for these overlap so much they're the same thing. The situation we're in in in your case B is just the idle case for condition C - if we know about the device before it's been detected then if it's been removed we just go back into the situation where we know about it but it isn't powered. (BTW, it's worth mentioning that C has already been done, in the form of runtime PM. The difference may be that you propose to take the device so far off-line that it disappears from the bus. AFAICS, this would be purely a private matter to be arranged between the subsystem and the driver; it does not need to be handled at the level of the device-model or PM core.) Actually runtime PM is actually already used for completely offlining devices on buses that are too blind to notice - it's only an issue on buses that can notice insertion and removal and want to do something about it. The use cases I'm describing already happen in mainline today for devices on the dumber buses. I think if we've got something which the hardware engineers can do on multiple buses then they probably will so we should have at least a pattern for how it's going to work over multiple buses rather than having to handle different models for different buses. I'll try to have a think about what that pattern might be at some point (in my copious free time). signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Wed, Aug 14, 2013 at 08:16:56PM +, Paul Zimmerman wrote: Mark's original complaint about USB was this: the device). The hub needs to be plugged into the SoC after the SoC USB controller has started with some GPIOs so we need to tell the system that the hub exists and needs to be synchronised with the USB controller. This sounds to me like the normal discovery mechanism for USB isn't getting kicked off because no Connect Status Change is being triggered on the root port when the hub is brought online using the GPIOs. Maybe the port has been runtime suspended because no device was attached originally? So maybe the only thing needed for USB is a way to tell the parent port to frob its port control bits to try to determine if a device is now present. (set Wake on Connect Enable? Do a Port Reset? Cycle the Port Power bit if possible?) No, that's not required in this case - the case is the opposite one to the one you describe. Host starting first then hub works fine, if the host does go into a low power mode it seems to notice the hub appearing just fine. Hub then host fails for some reason which I don't know. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Sun, Aug 11, 2013 at 09:53:01PM -0400, Alan Stern wrote: On Sun, 11 Aug 2013, Mark Brown wrote: One example that's bugging me right now is that on the Insignal Arndale platform there's a USB hub connected to one of the USB ports on the SoC (not as a PHY, it seems we also need the internal PHY running to talk to the device). The hub needs to be plugged into the SoC after the SoC USB controller has started with some GPIOs so we need to tell the system that the hub exists and needs to be synchronised with the USB controller. On the surface, this seems like a particularly simple case. Why wait until the SoC's USB controller has started? Why not plug in the hub via the GPIOs right from the beginning? I tried that, it doesn't seem to work - for some reason it seems that the hub is only successfully enumerated if it starts after its parent is running. I don't know enough about USB to speculate on why that might be, the GPIOs are brining the device out of reset not applying power or anything. Another case that's going to be problematic once it's in mainline is Slimbus - this is a bus used in some embedded audio subsystems which is enumerable in a similar manner to USB but where the devices on the bus are normally powered up only on demand (causing them to hotplug when used and unplug when idle) and have at least interrupt lines wired to the SoC using a normal interrupt outside the enumerable bus. That is indeed more difficult, because it requires geniune cooperation between the bus and platform subsystems. Yeah. You might want to do the same with for example a USB network controller when you're in flight only mode, that seems to be one of the more common reasons for doing this sort of thing with USB. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
[Adding Olof] On Mon, Aug 12, 2013 at 10:51:36AM +0100, Mark Brown wrote: On Sun, Aug 11, 2013 at 09:53:01PM -0400, Alan Stern wrote: On Sun, 11 Aug 2013, Mark Brown wrote: One example that's bugging me right now is that on the Insignal Arndale platform there's a USB hub connected to one of the USB ports on the SoC (not as a PHY, it seems we also need the internal PHY running to talk to the device). The hub needs to be plugged into the SoC after the SoC USB controller has started with some GPIOs so we need to tell the system that the hub exists and needs to be synchronised with the USB controller. On the surface, this seems like a particularly simple case. Why wait until the SoC's USB controller has started? Why not plug in the hub via the GPIOs right from the beginning? I tried that, it doesn't seem to work - for some reason it seems that the hub is only successfully enumerated if it starts after its parent is running. I don't know enough about USB to speculate on why that might be, the GPIOs are brining the device out of reset not applying power or anything. Another case that's going to be problematic once it's in mainline is Slimbus - this is a bus used in some embedded audio subsystems which is enumerable in a similar manner to USB but where the devices on the bus are normally powered up only on demand (causing them to hotplug when used and unplug when idle) and have at least interrupt lines wired to the SoC using a normal interrupt outside the enumerable bus. That is indeed more difficult, because it requires geniune cooperation between the bus and platform subsystems. Yeah. You might want to do the same with for example a USB network controller when you're in flight only mode, that seems to be one of the more common reasons for doing this sort of thing with USB. As I understand it, the wifi chip on the Snow Chromebook has a similar issue -- it hangs off of a probeable SDIO bus, but needs a regulator poked for it to turn on and become probeable (see exynos_wifi_bt_set_power in [1]). Thanks, Mark. [1] http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=blob;f=arch/arm/mach-exynos/mach-exynos5-dt.c;h=d131241ea78b7d89df21e676e284ddfd369b4da0;hb=refs/heads/chromeos-3.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Sun, Aug 11, 2013 at 07:02:57PM -0700, Greg Kroah-Hartman wrote: On Sun, Aug 11, 2013 at 08:08:26PM +0100, Mark Brown wrote: I know there's been some discussion of this topic but do we have any general consensus on how to handle such things both from a Linux driver model point of view and from a DT/ACPI point of view? As these are usually bus-specific things, and really, platform-specific I don't think they're bus specific - the main issue with a lot of this is that they're outside the infrastructure that the bus standardises so we should have a general way of understanding this. There will be bits where the bus needs to get involved but the overall pattern is generic. things, I'd fall back and just recommend a platform driver that knows about where these gpios are, and how/when to enable them, which will cause the discoverable bus logic to kick in now that it notices a device is present/removed. This doesn't work in general. These things aren't really platform specific at all, they're features of the devices that apply to any system using them and while for some use cases (like WiFi and BT power) an external thing that just manually applies power will be enough in other cases we want to know about the device even while it's off and the driver might be able to do extra things at runtime if it knows about for example having some control over signals to the device. For example in the Slimbus case we're normally talking about audio CODECs. In order to preserve the userspace API the device has to appear to be present at all times, the driver will remember the settings the user is making to be applied when it actually powers up and indeed the powering up should be kicked off as a result of userspac acting on the apparently present device. Another example here (including USB devices) is interrupt signals wired directly back to the processor, completely outside of the bus. Perhaps a semi-generic platform driver could be created, that knows how to handle these settings in the DT, but odds are, that might be difficult to make generic enough to cover a wide range of boards, but without specifics, it's hard to tell. There's things like the rfkill stuff already, and the reset controller on the way, but again this only covers a fairly small subset of the issues. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Mon, Aug 12, 2013 at 12:07:14PM +0100, Mark Rutland wrote: As I understand it, the wifi chip on the Snow Chromebook has a similar issue -- it hangs off of a probeable SDIO bus, but needs a regulator poked for it to turn on and become probeable (see exynos_wifi_bt_set_power in [1]). Yes, that's another example - this stuff is really common in practical systems, especially the power control for radios since that's how rfkill tends to end up being implemented. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On 08/12/2013 05:07 AM, Mark Rutland wrote: [Adding Olof] On Mon, Aug 12, 2013 at 10:51:36AM +0100, Mark Brown wrote: On Sun, Aug 11, 2013 at 09:53:01PM -0400, Alan Stern wrote: On Sun, 11 Aug 2013, Mark Brown wrote: One example that's bugging me right now is that on the Insignal Arndale platform there's a USB hub connected to one of the USB ports on the SoC (not as a PHY, it seems we also need the internal PHY running to talk to the device). The hub needs to be plugged into the SoC after the SoC USB controller has started with some GPIOs so we need to tell the system that the hub exists and needs to be synchronised with the USB controller. ... As I understand it, the wifi chip on the Snow Chromebook has a similar issue -- it hangs off of a probeable SDIO bus, but needs a regulator poked for it to turn on and become probeable (see exynos_wifi_bt_set_power in [1]). In this case, I wonder if it makes sense to model the extra requirements as part of the bus/socket/... itself rather than as part of the device that's attached to the bus. It seems quite common for SDIO-based WiFi devices to need a few things: * Regulator * 32KHz clock * Enable GPIO (- rfkill?) * Perhaps a reset GPIO Physically, these are provided to the socket into which the WiFi device plugs in. Perhaps we should try to explicitly model the socket (which I guess is really the SDIO bus in a way) rather than attaching these new resources to the controller or the device itself. In a similar way, I wonder if the USB case can be considered the same way? This seems less like a good fit since I don't expect the resources are always so similar there, and also there's the case of the bus being potentially behind a few levels of USB hub. And of course it all gets a little more messy when you get board-specific logic that needs setup, rather than something more common across multiple devices. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Mon, Aug 12, 2013 at 12:08:17PM -0600, Stephen Warren wrote: In a similar way, I wonder if the USB case can be considered the same way? This seems less like a good fit since I don't expect the resources are always so similar there, and also there's the case of the bus being potentially behind a few levels of USB hub. That won't work for the hub on Arndale in a system where it's fully wired up - it's got an I2C interface for control and the idea is that you bring it out of reset, write the configuration out via I2C and then you can complete startup using a GPIO or another I2C command. And of course it all gets a little more messy when you get board-specific logic that needs setup, rather than something more common across multiple devices. I think we could probably cover many cases by putting common things onto the bus but we still need to confront the cases where the device driver really does need to get involved in what's going on. Things like the SDIO WiFi cards seem very interchangable as you say and would probably benefit a lot but there's other applications that are less regular. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Mon, Aug 12, 2013 at 12:23:44PM +0100, Mark Brown wrote: On Sun, Aug 11, 2013 at 07:02:57PM -0700, Greg Kroah-Hartman wrote: On Sun, Aug 11, 2013 at 08:08:26PM +0100, Mark Brown wrote: I know there's been some discussion of this topic but do we have any general consensus on how to handle such things both from a Linux driver model point of view and from a DT/ACPI point of view? As these are usually bus-specific things, and really, platform-specific I don't think they're bus specific - the main issue with a lot of this is that they're outside the infrastructure that the bus standardises so we should have a general way of understanding this. There will be bits where the bus needs to get involved but the overall pattern is generic. The pattern is generic, yes, we've been dealing with that for well over a decade now (pci hotplug controllers are out of line and control when/if a PCI is device is added/removed.) I'd argue that each bus needs special logic to handle this, just like PCI hotplug did it with their hotplug controller logic. Due to the nature of this type of thing, it's all out-of-line hardware that is custom to each device type / bus. things, I'd fall back and just recommend a platform driver that knows about where these gpios are, and how/when to enable them, which will cause the discoverable bus logic to kick in now that it notices a device is present/removed. This doesn't work in general. These things aren't really platform specific at all, they're features of the devices that apply to any system using them and while for some use cases (like WiFi and BT power) an external thing that just manually applies power will be enough in other cases we want to know about the device even while it's off and the driver might be able to do extra things at runtime if it knows about for example having some control over signals to the device. No, the device isn't platform specific, but the logic needed to turn on/off is platform specific, otherwise the device would just work properly as the bus is self-discoverable. Much like rfkill is, as you point out. Those are all platform specific. For example in the Slimbus case we're normally talking about audio CODECs. In order to preserve the userspace API the device has to appear to be present at all times, the driver will remember the settings the user is making to be applied when it actually powers up and indeed the powering up should be kicked off as a result of userspac acting on the apparently present device. That's some horrible hardware, who thought of that? Another example here (including USB devices) is interrupt signals wired directly back to the processor, completely outside of the bus. Like rfkill switches that just power on/off a USB device built onto the laptop motherboard :) Perhaps a semi-generic platform driver could be created, that knows how to handle these settings in the DT, but odds are, that might be difficult to make generic enough to cover a wide range of boards, but without specifics, it's hard to tell. There's things like the rfkill stuff already, and the reset controller on the way, but again this only covers a fairly small subset of the issues. small subset? How common is this type of thing? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Mon, Aug 12, 2013 at 01:50:07PM -0700, Greg Kroah-Hartman wrote: On Mon, Aug 12, 2013 at 12:23:44PM +0100, Mark Brown wrote: I don't think they're bus specific - the main issue with a lot of this is that they're outside the infrastructure that the bus standardises so we should have a general way of understanding this. There will be bits where the bus needs to get involved but the overall pattern is generic. The pattern is generic, yes, we've been dealing with that for well over a decade now (pci hotplug controllers are out of line and control when/if a PCI is device is added/removed.) I'd argue that each bus needs special logic to handle this, just like PCI hotplug did it with their hotplug controller logic. Due to the nature of this type of thing, it's all out-of-line hardware that is custom to each device type / bus. I agree that the bus will need some logic to handle this and I also think Stephen is right that there are going to be some common patterns for some device classes. However I do think that this is a common problem for pretty much all buses so we should be factoring out as much as possible from the buses so they only have to deal with their bit of things. Most of the stuff that's worrying me is not anything the bus should have any idea about beyond tunnelling the data to the device. This doesn't work in general. These things aren't really platform specific at all, they're features of the devices that apply to any system using them and while for some use cases (like WiFi and BT power) an external thing that just manually applies power will be enough in other cases we want to know about the device even while it's off and the driver might be able to do extra things at runtime if it knows about for example having some control over signals to the device. No, the device isn't platform specific, but the logic needed to turn on/off is platform specific, otherwise the device would just work properly as the bus is self-discoverable. Much like rfkill is, as you point out. Those are all platform specific. This is not just about power control - that's one of the simpler applications but you're talking about essentially anything that might be handled by platform data (or by the configuration SEPROMs on a freestanding device for that matter, why would you put down an extra part to configure the device when you can just load things from the AP). For example in the Slimbus case we're normally talking about audio CODECs. In order to preserve the userspace API the device has to appear to be present at all times, the driver will remember the settings the user is making to be applied when it actually powers up and indeed the powering up should be kicked off as a result of userspac acting on the apparently present device. That's some horrible hardware, who thought of that? It's actually pretty nice hardware in many regards; the bus is a bit underspecified for maximum bandwidth in modern systems but it gives you standardised multi-drop data streaming over two wires muxed with control which helps with the pin counts and with simplifying the system hardware design. The disappearing from the bus thing is because you're aiming to hit low power idle (but still functioning) states consuming very small numbers of microamps, even having a clock running is measurable. Perhaps a semi-generic platform driver could be created, that knows how to handle these settings in the DT, but odds are, that might be difficult to make generic enough to cover a wide range of boards, but without specifics, it's hard to tell. There's things like the rfkill stuff already, and the reset controller on the way, but again this only covers a fairly small subset of the issues. small subset? How common is this type of thing? Well, for Slimbus it's absolutely the norm, I've never seen a Slimbus device that didn't have a need for platform data. The small subset there is of the problems rather than the devices - you'll cover a large set of devices with a common helper like rfkill but trying to handle everything with that pattern doesn't seem like it'll work. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Mon, 12 Aug 2013, Mark Brown wrote: On Mon, Aug 12, 2013 at 01:50:07PM -0700, Greg Kroah-Hartman wrote: On Mon, Aug 12, 2013 at 12:23:44PM +0100, Mark Brown wrote: I don't think they're bus specific - the main issue with a lot of this is that they're outside the infrastructure that the bus standardises so we should have a general way of understanding this. There will be bits where the bus needs to get involved but the overall pattern is generic. The pattern is generic, yes, we've been dealing with that for well over a decade now (pci hotplug controllers are out of line and control when/if a PCI is device is added/removed.) I'd argue that each bus needs special logic to handle this, just like PCI hotplug did it with their hotplug controller logic. Due to the nature of this type of thing, it's all out-of-line hardware that is custom to each device type / bus. I agree that the bus will need some logic to handle this and I also think Stephen is right that there are going to be some common patterns for some device classes. However I do think that this is a common problem for pretty much all buses so we should be factoring out as much as possible from the buses so they only have to deal with their bit of things. Most of the stuff that's worrying me is not anything the bus should have any idea about beyond tunnelling the data to the device. In theory, the matching of device IDs can be done in the driver core, provided the IDs are assigned based on the bus topology (as is the case for USB). But what should happen when there's a match? The bus code would need hooks installed wherever the platform wants to do something extra. This could end up growing to a lot of hooks. How can the whole thing be done in a reasonable fashion? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Non-enumerable devices on USB and other enumerable buses
Looking at the enumerable buses in the kernel I don't see any which have real support for any kind of registration of devices prior to their enumeration. Similarly currently all the DT bindings in the kernel I've been able to notice cover only non-enumerable buses. This generally makes sense where enumerable buses are used in standard fashions since the binding would be at best redundant and at worst inaccurate. However there are often corner cases in embedded systems where hardware has been hooked up outside of the normal enumeration mechanisms, for example with software power control or extra signals wired. One example that's bugging me right now is that on the Insignal Arndale platform there's a USB hub connected to one of the USB ports on the SoC (not as a PHY, it seems we also need the internal PHY running to talk to the device). The hub needs to be plugged into the SoC after the SoC USB controller has started with some GPIOs so we need to tell the system that the hub exists and needs to be synchronised with the USB controller. Another case that's going to be problematic once it's in mainline is Slimbus - this is a bus used in some embedded audio subsystems which is enumerable in a similar manner to USB but where the devices on the bus are normally powered up only on demand (causing them to hotplug when used and unplug when idle) and have at least interrupt lines wired to the SoC using a normal interrupt outside the enumerable bus. I know there's been some discussion of this topic but do we have any general consensus on how to handle such things both from a Linux driver model point of view and from a DT/ACPI point of view? signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Sun, Aug 11, 2013 at 8:08 PM, Mark Brown broo...@kernel.org wrote: I know there's been some discussion of this topic but do we have any general consensus on how to handle such things both from a Linux driver model point of view and from a DT/ACPI point of view? There is precedence for describing enumerated device in the device tree. Real OpenFirmware platforms can and will enumerate the PCI and USB busses and pass a full tree to the OS. I don't think we want to full enumerating like that with either ACPI or FDT, but we could allow for sparse population of devices when something is fixed like a soldered down USB hub or USB Ethernet MAC. To make it work would probably require a hook in the USB enumeration path to look for matching nodes in DT/ACPI and attach it to the struct device. g. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Sun, 11 Aug 2013, Mark Brown wrote: Looking at the enumerable buses in the kernel I don't see any which have real support for any kind of registration of devices prior to their enumeration. Similarly currently all the DT bindings in the kernel I've been able to notice cover only non-enumerable buses. This generally makes sense where enumerable buses are used in standard fashions since the binding would be at best redundant and at worst inaccurate. However there are often corner cases in embedded systems where hardware has been hooked up outside of the normal enumeration mechanisms, for example with software power control or extra signals wired. One example that's bugging me right now is that on the Insignal Arndale platform there's a USB hub connected to one of the USB ports on the SoC (not as a PHY, it seems we also need the internal PHY running to talk to the device). The hub needs to be plugged into the SoC after the SoC USB controller has started with some GPIOs so we need to tell the system that the hub exists and needs to be synchronised with the USB controller. On the surface, this seems like a particularly simple case. Why wait until the SoC's USB controller has started? Why not plug in the hub via the GPIOs right from the beginning? Another case that's going to be problematic once it's in mainline is Slimbus - this is a bus used in some embedded audio subsystems which is enumerable in a similar manner to USB but where the devices on the bus are normally powered up only on demand (causing them to hotplug when used and unplug when idle) and have at least interrupt lines wired to the SoC using a normal interrupt outside the enumerable bus. That is indeed more difficult, because it requires geniune cooperation between the bus and platform subsystems. I know there's been some discussion of this topic but do we have any general consensus on how to handle such things both from a Linux driver model point of view and from a DT/ACPI point of view? The discussion involved some sort of pattern matching based on the device name and the bus, but nothing was ever settled. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Sun, Aug 11, 2013 at 08:08:26PM +0100, Mark Brown wrote: Looking at the enumerable buses in the kernel I don't see any which have real support for any kind of registration of devices prior to their enumeration. Similarly currently all the DT bindings in the kernel I've been able to notice cover only non-enumerable buses. This generally makes sense where enumerable buses are used in standard fashions since the binding would be at best redundant and at worst inaccurate. However there are often corner cases in embedded systems where hardware has been hooked up outside of the normal enumeration mechanisms, for example with software power control or extra signals wired. Not just embedded, the Macbooks have this same issue as well I'm pretty sure, it's just that we don't know where those GPIOs are in order to be able to use them... One example that's bugging me right now is that on the Insignal Arndale platform there's a USB hub connected to one of the USB ports on the SoC (not as a PHY, it seems we also need the internal PHY running to talk to the device). The hub needs to be plugged into the SoC after the SoC USB controller has started with some GPIOs so we need to tell the system that the hub exists and needs to be synchronised with the USB controller. Another case that's going to be problematic once it's in mainline is Slimbus - this is a bus used in some embedded audio subsystems which is enumerable in a similar manner to USB but where the devices on the bus are normally powered up only on demand (causing them to hotplug when used and unplug when idle) and have at least interrupt lines wired to the SoC using a normal interrupt outside the enumerable bus. I know there's been some discussion of this topic but do we have any general consensus on how to handle such things both from a Linux driver model point of view and from a DT/ACPI point of view? As these are usually bus-specific things, and really, platform-specific things, I'd fall back and just recommend a platform driver that knows about where these gpios are, and how/when to enable them, which will cause the discoverable bus logic to kick in now that it notices a device is present/removed. Perhaps a semi-generic platform driver could be created, that knows how to handle these settings in the DT, but odds are, that might be difficult to make generic enough to cover a wide range of boards, but without specifics, it's hard to tell. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
