Re: Tegra3 ehci_suspend and ehci_resume
On 12/12/2012 07:34 PM, Alan Stern wrote: Okay. Then how about this: Unplug both the power connector and the slave connector. After the N7 goes into deep sleep, plug the power connector back in but leave the slave unplugged. Then a few seconds later, plug in the slave. This always fails (-71 / SET_ADDRESS). The issues can then only be solved, by unplugging the OTG adapter. In other words, by switching to peripheral mode (and back). Also try doing the same thing, but don't wait for the N7 to go into deep sleep. If this works but the other test doesn't, then clearly the slave is working correctly and the problem lies in the host controller. This works well most of the time. Some issues in a few cases, not sure why. (It is possible to debug over WiFi. But doing so would prevent LP0.) Timur -- 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: Tegra3 ehci_suspend and ehci_resume
On Thu, 13 Dec 2012, Timur wrote: On 12/12/2012 07:34 PM, Alan Stern wrote: Okay. Then how about this: Unplug both the power connector and the slave connector. After the N7 goes into deep sleep, plug the power connector back in but leave the slave unplugged. Then a few seconds later, plug in the slave. This always fails (-71 / SET_ADDRESS). The issues can then only be solved, by unplugging the OTG adapter. In other words, by switching to peripheral mode (and back). Also try doing the same thing, but don't wait for the N7 to go into deep sleep. If this works but the other test doesn't, then clearly the slave is working correctly and the problem lies in the host controller. This works well most of the time. Some issues in a few cases, not sure why. (It is possible to debug over WiFi. But doing so would prevent LP0.) So it seems clear that the problem is the deep sleep implementation in ehci-tegra. That implementation is very non-standard in the 3.7 kernel. To fix it will require assistance from the people responsible for the ehci-tegra driver. I can be of only limited help because I don't have any Tegra hardware and I don't know how it's supposed to work. 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: Tegra3 ehci_suspend and ehci_resume
On Wed, 12 Dec 2012, Timur wrote: - Unplugging and re-plugging the slave device works well. - Unplugging the Y-cable (disconnecting slave and external power at the same time) then re-plugging the Y-cable works well. - Disconnecting external power to both devices, then waiting for the host screen to go off and waiting for up to 20 seconds longer (staying in light sleep) does also work well. Please note: slave device was completely off power for roughly 20 seconds and is not causing any issues. The problem only occurs, when I pull external power, wait for the host screen to go off, then wait another 60s or 10 minutes, this way making sure the host will indeed transition into deep sleep. Plugging external power then will wake both devices, but the host can no longer talk to the slave. What happens if you: pull external power, wait for the host screen to go off, then wait another 60s or 10 minutes, then plug external power back to both devices (but leave the USB connection between the host and slave unplugged), then wait 10 seconds, then plug in the USB connection? Is this not strong evidence the problem is with the host? Yes, it is. Can you force the host to go into deep sleep while the external power remains connected? 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: Tegra3 ehci_suspend and ehci_resume
On 12.12.2012 16:20, Alan Stern wrote: On Wed, 12 Dec 2012, Timur wrote: - Unplugging and re-plugging the slave device works well. - Unplugging the Y-cable (disconnecting slave and external power at the same time) then re-plugging the Y-cable works well. - Disconnecting external power to both devices, then waiting for the host screen to go off and waiting for up to 20 seconds longer (staying in light sleep) does also work well. Please note: slave device was completely off power for roughly 20 seconds and is not causing any issues. The problem only occurs, when I pull external power, wait for the host screen to go off, then wait another 60s or 10 minutes, this way making sure the host will indeed transition into deep sleep. Plugging external power then will wake both devices, but the host can no longer talk to the slave. What happens if you: pull external power, wait for the host screen to go off, then wait another 60s or 10 minutes, then plug external power back to both devices (but leave the USB connection between the host and slave unplugged), then wait 10 seconds, then plug in the USB connection? Nexus 7 and USB slave get their power via USB cable. This makes it a little difficult to connect power, but leave the USB connection unplugged. I'm not sure how to proceed with this. This is the USB Y-adapter I am using: https://sites.google.com/site/sonicboomworld/_/rsrc/1345753009582/my-projects/otg-diagrams/Y_OTG_CABLE.png A photo of all components (USB cables excluded): http://mehrvarz.github.com/img/n7-otg-power.png Is this not strong evidence the problem is with the host? Yes, it is. Can you force the host to go into deep sleep while the external power remains connected? Alan Stern I investigated this. Unfortunately, the answer seems to be no. I cannot convince the Nexus 7 to move into deep sleep mode (LP0), when a powered USB cable is connected to it (despite WiFi, Bt, ADB, etc. being off). A new finding: when the N7 is coming out of deep sleep (in the problematic scenario), I see that method hub_port_reset() is being called. It seems to succeed. Because the following shows up in the log: usb 2-1: new full speed USB device number 3 using tegra-ehci. However, this is then followed by hub_set_address() failing and tegra-ehci tegra-ehci.0: detected XactErr len 0/8 retry x and device not accepting address 3, error -71 being logged. I ran this modified test: while the N7 was in deep sleep, I unplugged (stole) the USB slave. Then I plugged external power and this time hub_port_reset() did not succeed and no entry usb 2-1: new full speed USB device number 3 using tegra-ehci was logged. I think this shows that, after LP0, a connected USB slave device _is_ still detectable. The problem strikes a moment later, when the host tries to set the address. Can I try anything in code, to reset the slave, so it will accept an address? Timur -- 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: Tegra3 ehci_suspend and ehci_resume
On Wed, 12 Dec 2012, Timur wrote: Nexus 7 and USB slave get their power via USB cable. This makes it a little difficult to connect power, but leave the USB connection unplugged. I'm not sure how to proceed with this. This is the USB Y-adapter I am using: https://sites.google.com/site/sonicboomworld/_/rsrc/1345753009582/my-projects/otg-diagrams/Y_OTG_CABLE.png A photo of all components (USB cables excluded): http://mehrvarz.github.com/img/n7-otg-power.png Ah, now I understand. Is this not strong evidence the problem is with the host? Yes, it is. Can you force the host to go into deep sleep while the external power remains connected? Alan Stern I investigated this. Unfortunately, the answer seems to be no. I cannot convince the Nexus 7 to move into deep sleep mode (LP0), when a powered USB cable is connected to it (despite WiFi, Bt, ADB, etc. being off). Okay. Then how about this: Unplug both the power connector and the slave connector. After the N7 goes into deep sleep, plug the power connector back in but leave the slave unplugged. Then a few seconds later, plug in the slave. Also try doing the same thing, but don't wait for the N7 to go into deep sleep. If this works but the other test doesn't, then clearly the slave is working correctly and the problem lies in the host controller. A new finding: when the N7 is coming out of deep sleep (in the problematic scenario), I see that method hub_port_reset() is being called. It seems to succeed. Because the following shows up in the log: usb 2-1: new full speed USB device number 3 using tegra-ehci. However, this is then followed by hub_set_address() failing and tegra-ehci tegra-ehci.0: detected XactErr len 0/8 retry x and device not accepting address 3, error -71 being logged. I ran this modified test: while the N7 was in deep sleep, I unplugged (stole) the USB slave. Then I plugged external power and this time hub_port_reset() did not succeed and no entry usb 2-1: new full speed USB device number 3 using tegra-ehci was logged. I think this shows that, after LP0, a connected USB slave device _is_ still detectable. The problem strikes a moment later, when the host tries to set the address. Can I try anything in code, to reset the slave, so it will accept an address? The hub driver already does this, in hub_port_reset(). It wouldn't be surprising if the deep-sleep code in the ehci-tegra driver has some bugs. I don't know how much it has been tested. 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: Tegra3 ehci_suspend and ehci_resume
On Mon, 10 Dec 2012, Timur wrote: N7 is not using a vanilla kernel. It is one thing to apply modifications to the given code base. It would be far more difficult (I think) to replace the kernel as a whole. Maybe I should back port just as little code as possible? Or maybe I should try to back port some full building blocks? Where to make the cut? I also wonder how to make the system take advantage of ehci_suspend() and ehci_resume(), both marked as __maybe_unused. Who is calling these methods? Why are you concerned about those routines? The problem most likely lies in your slave devices -- they don't recover properly from a sudden power loss. You should try unplugging the slave, waiting a few seconds, and then plugging it back in again. 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: Tegra3 ehci_suspend and ehci_resume
On Tue, Dec 11, 2012 at 01:29:19AM +0100, Timur wrote: On 12/11/2012 12:04 AM, Greg KH wrote: On Mon, Dec 10, 2012 at 11:53:27PM +0100, Timur wrote: N7 is not using a vanilla kernel. Yes, I know that quite well :) It is one thing to apply modifications to the given code base. It would be far more difficult (I think) to replace the kernel as a whole. Maybe I should back port just as little code as possible? Or maybe I should try to back port some full building blocks? Where to make the cut? I also wonder how to make the system take advantage of ehci_suspend() and ehci_resume(), both marked as __maybe_unused. Who is calling these methods? Look at the newer kernels for what is going on there. As for which is easier, that's up to you, there has been a lot of work to integrate the out-of-tree tegra and android code and get it merged to the main kernel since 3.1 was released over a year ago, so it depends on what you feel comfortable with doing. Wow, I was not aware of this. Can you please point me to a N7-compatible configuration for a more recent kernel? Your existing configuration should work, but you need to verify that all of the board support patches are upstream already, that might be the hard part. good luck, 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: Tegra3 ehci_suspend and ehci_resume
On 12/11/2012 04:34 PM, Alan Stern wrote: On Mon, 10 Dec 2012, Timur wrote: N7 is not using a vanilla kernel. It is one thing to apply modifications to the given code base. It would be far more difficult (I think) to replace the kernel as a whole. Maybe I should back port just as little code as possible? Or maybe I should try to back port some full building blocks? Where to make the cut? I also wonder how to make the system take advantage of ehci_suspend() and ehci_resume(), both marked as __maybe_unused. Who is calling these methods? Why are you concerned about those routines? The problem most likely lies in your slave devices -- they don't recover properly from a sudden power loss. You should try unplugging the slave, waiting a few seconds, and then plugging it back in again. Alan Stern Thank you for your response. Yes, unplugging helps. But host and slave should also function in a fixed installation setup, where cables are hidden. I tried different slave devices and they are all not accepting address xx, error -71 after power was lost. I think it is the host causing the issue, not working properly through it's deep sleep cycle. Something is wrong or missing in N7's tegra_ehci_resume() / tegra_ehci_suspend() methods. These methods exist (found them!) and they are being called: https://github.com/mehrvarz/android_kernel_grouper/blob/android-tegra3-grouper-3.1-jb-mr0/drivers/usb/host/ehci-tegra.c#L1246 Timur -- 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: Tegra3 ehci_suspend and ehci_resume
On 12/11/2012 06:36 PM, Timur wrote: On 12/11/2012 04:34 PM, Alan Stern wrote: On Mon, 10 Dec 2012, Timur wrote: N7 is not using a vanilla kernel. It is one thing to apply modifications to the given code base. It would be far more difficult (I think) to replace the kernel as a whole. Maybe I should back port just as little code as possible? Or maybe I should try to back port some full building blocks? Where to make the cut? I also wonder how to make the system take advantage of ehci_suspend() and ehci_resume(), both marked as __maybe_unused. Who is calling these methods? Why are you concerned about those routines? The problem most likely lies in your slave devices -- they don't recover properly from a sudden power loss. You should try unplugging the slave, waiting a few seconds, and then plugging it back in again. Alan Stern Thank you for your response. Yes, unplugging helps. But host and slave should also function in a fixed installation setup, where cables are hidden. I tried different slave devices and they are all not accepting address xx, error -71 after power was lost. I think it is the host causing the issue, not working properly through it's deep sleep cycle. Something is wrong or missing in N7's tegra_ehci_resume() / tegra_ehci_suspend() methods. These methods exist (found them!) and they are being called: https://github.com/mehrvarz/android_kernel_grouper/blob/android-tegra3-grouper-3.1-jb-mr0/drivers/usb/host/ehci-tegra.c#L1246 A power loss of under 20s will make the host only go into light sleep and does not result in error -71. -- 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: Tegra3 ehci_suspend and ehci_resume
On Tue, 11 Dec 2012, Timur wrote: Thank you for your response. Yes, unplugging helps. But host and slave should also function in a fixed installation setup, where cables are hidden. I tried different slave devices and they are all not accepting address xx, error -71 after power was lost. I think it is the host causing the issue, not working properly through it's deep sleep cycle. Something is wrong or missing in N7's tegra_ehci_resume() / tegra_ehci_suspend() methods. These methods exist (found them!) and they are being called: https://github.com/mehrvarz/android_kernel_grouper/blob/android-tegra3-grouper-3.1-jb-mr0/drivers/usb/host/ehci-tegra.c#L1246 A power loss of under 20s will make the host only go into light sleep and does not result in error -71. Are you talking about a loss of power to the host or a loss of power to the slave? What is the cause of this power loss? If you think this problem is specifically related to the Tegra, why not ask the person responsible for maintaining the Tegra code? (Hint: Look in the MAINTAINERS file at the top level of the kernel source 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: Tegra3 ehci_suspend and ehci_resume
On 12/11/2012 08:13 PM, Alan Stern wrote: On Tue, 11 Dec 2012, Timur wrote: Thank you for your response. Yes, unplugging helps. But host and slave should also function in a fixed installation setup, where cables are hidden. I tried different slave devices and they are all not accepting address xx, error -71 after power was lost. I think it is the host causing the issue, not working properly through it's deep sleep cycle. Something is wrong or missing in N7's tegra_ehci_resume() / tegra_ehci_suspend() methods. These methods exist (found them!) and they are being called: https://github.com/mehrvarz/android_kernel_grouper/blob/android-tegra3-grouper-3.1-jb-mr0/drivers/usb/host/ehci-tegra.c#L1246 A power loss of under 20s will make the host only go into light sleep and does not result in error -71. Are you talking about a loss of power to the host or a loss of power to the slave? What is the cause of this power loss? If you think this problem is specifically related to the Tegra, why not ask the person responsible for maintaining the Tegra code? (Hint: Look in the MAINTAINERS file at the top level of the kernel source code.) Alan Stern I am talking about both devices loosing external power at the same time. The N7 will then switch to it's internal battery. I guess anything could cause a loss of power. Turning off the car ignition, for example. Good hint. I found a reference to linux-tegra and will contact them. Allow me to say that I got a little scared when you told me to try unplugging the slave as a solution. Maybe you weren't all serious with a list newbie? Timur -- 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: Tegra3 ehci_suspend and ehci_resume
On Tue, 11 Dec 2012, Timur wrote: I am talking about both devices loosing external power at the same time. Losing external power is different from losing power. The N7 will then switch to it's internal battery. Right. It will continue running, because the battery continues to supply power. There is no interruption in the power flow. I guess anything could cause a loss of power. Turning off the car ignition, for example. What happens if the N7 doesn't lose its external power but the slave does? If there's still a problem, that's a pretty good indication that the N7 is working okay but the slave isn't. Good hint. I found a reference to linux-tegra and will contact them. Allow me to say that I got a little scared when you told me to try unplugging the slave as a solution. Maybe you weren't all serious with a list newbie? I was perfectly serious. It's a legitimate debugging technique. Unplug the USB cable, then plug it back in, then see what happens. 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: Tegra3 ehci_suspend and ehci_resume
On 12/11/2012 11:24 PM, Alan Stern wrote: On Tue, 11 Dec 2012, Timur wrote: I am talking about both devices loosing external power at the same time. Losing external power is different from losing power. I'm trying to be as precise as I can. The N7 will then switch to it's internal battery. Right. It will continue running, because the battery continues to supply power. There is no interruption in the power flow. Correct. Due to the internal battery, there is at no time an interruption in the power flow of the host. I guess anything could cause a loss of power. Turning off the car ignition, for example. What happens if the N7 doesn't lose its external power but the slave does? If there's still a problem, that's a pretty good indication that the N7 is working okay but the slave isn't. I am using a regular OTG Y-cable. Both devices are using the same external power source. When I disconnect and reconnect only the slave (USB wise), there is no problem (see below). Good hint. I found a reference to linux-tegra and will contact them. Allow me to say that I got a little scared when you told me to try unplugging the slave as a solution. Maybe you weren't all serious with a list newbie? I was perfectly serious. It's a legitimate debugging technique. Unplug the USB cable, then plug it back in, then see what happens. I got this wrong. It was your last sentence and I thought you were suggesting this as a solution to the problem. I'm very sorry for misreading you. - Unplugging and re-plugging the slave device works well. - Unplugging the Y-cable (disconnecting slave and external power at the same time) then re-plugging the Y-cable works well. - Disconnecting external power to both devices, then waiting for the host screen to go off and waiting for up to 20 seconds longer (staying in light sleep) does also work well. Please note: slave device was completely off power for roughly 20 seconds and is not causing any issues. The problem only occurs, when I pull external power, wait for the host screen to go off, then wait another 60s or 10 minutes, this way making sure the host will indeed transition into deep sleep. Plugging external power then will wake both devices, but the host can no longer talk to the slave. Is this not strong evidence the problem is with the host? Timur -- 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
Tegra3 ehci_suspend and ehci_resume
Hi. I created a replacement kernel for the Nexus 7. Together with a USB Y-cable, this mod enables charging the N7, while running the device in USB host mode. People are using this to operate N7 + USB DAC devices in their cars and other things. It's a fun project. I'm currently trying to solve an issue with slave devices not being detectable after a sudden power loss. Slave devices will restart, when external power comes back, but will be not accepting address xx, error -71. Would it make sense to try to back port some code from a newer versions of ehci-hcd.c, including ehci_suspend() and ehci_resume(), not existing in the 3.1.10 kernel of the N7? Thanks a lot. Timur Can you charge USB Host mode simultaneously? http://rootzwiki.com/forum/512-nexus-7 Project on github: http://mehrvarz.github.com/usb-host-mode-power-management-nexus7 -- 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: Tegra3 ehci_suspend and ehci_resume
On Mon, Dec 10, 2012 at 10:42:50PM +0100, Timur wrote: Hi. I created a replacement kernel for the Nexus 7. Together with a USB Y-cable, this mod enables charging the N7, while running the device in USB host mode. People are using this to operate N7 + USB DAC devices in their cars and other things. It's a fun project. I'm currently trying to solve an issue with slave devices not being detectable after a sudden power loss. Slave devices will restart, when external power comes back, but will be not accepting address xx, error -71. Would it make sense to try to back port some code from a newer versions of ehci-hcd.c, including ehci_suspend() and ehci_resume(), not existing in the 3.1.10 kernel of the N7? Why not just try a newer kernel and see if that works properly for you or not? There's nothing forcing the N7 to use the 3.1 kernel, is there? 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: Tegra3 ehci_suspend and ehci_resume
On 12/10/2012 11:08 PM, Greg KH wrote: On Mon, Dec 10, 2012 at 10:42:50PM +0100, Timur wrote: Hi. I created a replacement kernel for the Nexus 7. Together with a USB Y-cable, this mod enables charging the N7, while running the device in USB host mode. People are using this to operate N7 + USB DAC devices in their cars and other things. It's a fun project. I'm currently trying to solve an issue with slave devices not being detectable after a sudden power loss. Slave devices will restart, when external power comes back, but will be not accepting address xx, error -71. Would it make sense to try to back port some code from a newer versions of ehci-hcd.c, including ehci_suspend() and ehci_resume(), not existing in the 3.1.10 kernel of the N7? Why not just try a newer kernel and see if that works properly for you or not? There's nothing forcing the N7 to use the 3.1 kernel, is there? greg k-h N7 is not using a vanilla kernel. It is one thing to apply modifications to the given code base. It would be far more difficult (I think) to replace the kernel as a whole. Maybe I should back port just as little code as possible? Or maybe I should try to back port some full building blocks? Where to make the cut? I also wonder how to make the system take advantage of ehci_suspend() and ehci_resume(), both marked as __maybe_unused. Who is calling these methods? Timur -- 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: Tegra3 ehci_suspend and ehci_resume
On Mon, Dec 10, 2012 at 11:53:27PM +0100, Timur wrote: On 12/10/2012 11:08 PM, Greg KH wrote: On Mon, Dec 10, 2012 at 10:42:50PM +0100, Timur wrote: Hi. I created a replacement kernel for the Nexus 7. Together with a USB Y-cable, this mod enables charging the N7, while running the device in USB host mode. People are using this to operate N7 + USB DAC devices in their cars and other things. It's a fun project. I'm currently trying to solve an issue with slave devices not being detectable after a sudden power loss. Slave devices will restart, when external power comes back, but will be not accepting address xx, error -71. Would it make sense to try to back port some code from a newer versions of ehci-hcd.c, including ehci_suspend() and ehci_resume(), not existing in the 3.1.10 kernel of the N7? Why not just try a newer kernel and see if that works properly for you or not? There's nothing forcing the N7 to use the 3.1 kernel, is there? greg k-h N7 is not using a vanilla kernel. Yes, I know that quite well :) It is one thing to apply modifications to the given code base. It would be far more difficult (I think) to replace the kernel as a whole. Maybe I should back port just as little code as possible? Or maybe I should try to back port some full building blocks? Where to make the cut? I also wonder how to make the system take advantage of ehci_suspend() and ehci_resume(), both marked as __maybe_unused. Who is calling these methods? Look at the newer kernels for what is going on there. As for which is easier, that's up to you, there has been a lot of work to integrate the out-of-tree tegra and android code and get it merged to the main kernel since 3.1 was released over a year ago, so it depends on what you feel comfortable with doing. However, unless you are running the latest kernel.org release, there's usually not much we can help you out with here, as we don't know, or remember, what is going on in that very old release + odd-random-android patches. good luck, 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: Tegra3 ehci_suspend and ehci_resume
On 12/11/2012 12:04 AM, Greg KH wrote: On Mon, Dec 10, 2012 at 11:53:27PM +0100, Timur wrote: N7 is not using a vanilla kernel. Yes, I know that quite well :) It is one thing to apply modifications to the given code base. It would be far more difficult (I think) to replace the kernel as a whole. Maybe I should back port just as little code as possible? Or maybe I should try to back port some full building blocks? Where to make the cut? I also wonder how to make the system take advantage of ehci_suspend() and ehci_resume(), both marked as __maybe_unused. Who is calling these methods? Look at the newer kernels for what is going on there. As for which is easier, that's up to you, there has been a lot of work to integrate the out-of-tree tegra and android code and get it merged to the main kernel since 3.1 was released over a year ago, so it depends on what you feel comfortable with doing. Wow, I was not aware of this. Can you please point me to a N7-compatible configuration for a more recent kernel? However, unless you are running the latest kernel.org release, there's usually not much we can help you out with here, as we don't know, or remember, what is going on in that very old release + odd-random-android patches. good luck, Thank you. Timur 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
