Re: [RFT PATCH 0/4] usb: dwc2: Fix core reset and force mode delay problems

[Michael Niewoehner]

Am 08.04.2016 um 00:12 schrieb John Youn <john.y...@synopsys.com>:

> On 4/7/2016 1:36 PM, Michael Niewoehner wrote:
>> 
>> Am 07.04.2016 um 20:41 schrieb John Youn <john.y...@synopsys.com>:
>> 
>>> On 3/31/2016 2:44 PM, Michael Niewoehner wrote:
>>>> Hi John,
>>>> 
>>>> Am 29.03.2016 um 04:36 schrieb John Youn <johny...@synopsys.com>:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> The following patch series addresses the core reset and force mode
>>>>> delay problems we have been seeing on dwc2 for some platforms.
>>>>> 
>>>>> I think I have identified the source of the inconsistencies between
>>>>> platforms and this series attempts to address them.
>>>>> 
>>>>> Basically everything stems from the IDDIG debounce filter delay, which
>>>>> is a function of the PHY clock speed and can range from 5-50 ms if
>>>>> enabled. This delay must be taken into account on core reset and force
>>>>> modes. A full explanation is provided in the patch commit log and code
>>>>> comments.
>>>>> 
>>>>> The first two patches are prerequisites to the force mode fixes,
>>>>> including one patch that was sent separately by Przemek Rudy. I have
>>>>> resubmitted it with this series for convenience.
>>>>> 
>>>>> Please help by reviewing and testing on your platforms.
>>>>> 
>>>>> Patches were tested on:
>>>>> * Synopsys HAPS platform IP 3.20a OTG, dr_mode=OTG,HOST,PERIPHERAL
>>>>> 
>>>>> Regards,
>>>>> John
>>>>> 
>>>>> John Youn (3):
>>>>> usb: dwc2: gadget: Only initialize device if in device mode
>>>>> usb: dwc2: Add delay to core soft reset
>>>>> usb: dwc2: Properly account for the force mode delays
>>>>> 
>>>>> Przemek Rudy (1):
>>>>> usb: dwc2: do not override forced dr_mode in gadget setup
>>>>> 
>>>>> drivers/usb/dwc2/core.c | 195 
>>>>> 
>>>>> drivers/usb/dwc2/core.h |   2 +-
>>>>> drivers/usb/dwc2/gadget.c   |  30 +--
>>>>> drivers/usb/dwc2/hcd.c  |   6 +-
>>>>> drivers/usb/dwc2/hw.h   |   1 +
>>>>> drivers/usb/dwc2/platform.c |   9 +-
>>>>> 6 files changed, 161 insertions(+), 82 deletions(-)
>>>>> 
>>>>> -- 
>>>>> 2.7.4
>>>>> 
>>>> 
>>>> after applying your patch series on v4.6-rc1 usb keeps being broken on 
>>>> rk3188.
>>>> Besides that I get "dwc2 1018.usb: dwc2_wait_for_mode: Couldn't set 
>>>> host mode“ repeatedly.
>>>> 
>>>> Currently this works for me:
>>>> - Revert "usb: dwc2: Fix probe problem on bcm2835“
>>>> - Apply "usb: dwc2: Add a 10 ms delay to dwc2_core_reset()"
>>>> 
>>>> 
>>>> Best regards
>>>> Michael
>>>> 
>>> 
>>> Thanks Michael.
>>> 
>>> I won't be able to look at this again until next week. In the meantime
>>> could you provide a driver log? In particular I want to see the values
>>> of your GHWCFG registers, and where you are seeing the
>>> dwc2_wait_for_mode() failure.
>>> 
>>> Regards,
>>> John
>> 
>> Looks like the problem is gone on -rc2… on -rc1 the errors came up shortly 
>> after "dwc2 1018.usb“ messages.
>> USB keeps being broken, though. The USB hub is detected but nothing that is 
>> attached to it.
>> 
>> Here are the logs and register values for each test with Doug’s and your 
>> patches.
>> 
>> Michael
>> 
>> 
>> good usb, Doug's patches
>> 
>> [0.420125] usbcore: registered new interface driver usbfs
>>
>> [0.426246] usbcore: registered new interface driver hub  
>>
>> [0.432296] usbcore: registered new device driver usb
>> [...]
>> [0.853769] 1018.usb supply vusb_d not found, using dummy regulator   
>>
>> [0.860560] 1018.usb supply vusb_a not found, using dummy regulator   
>>
>> [0.867365] dwc2 1018.usb: Configuration mismatch. dr_mode forced to 
>> host
>> [0.977737] dwc2 1018.usb: 128 i

Re: [RFT PATCH 0/4] usb: dwc2: Fix core reset and force mode delay problems

[Michael Niewoehner]

Am 08.04.2016 um 00:12 schrieb John Youn :

> On 4/7/2016 1:36 PM, Michael Niewoehner wrote:
>> 
>> Am 07.04.2016 um 20:41 schrieb John Youn :
>> 
>>> On 3/31/2016 2:44 PM, Michael Niewoehner wrote:
>>>> Hi John,
>>>> 
>>>> Am 29.03.2016 um 04:36 schrieb John Youn :
>>>> 
>>>>> Hi,
>>>>> 
>>>>> The following patch series addresses the core reset and force mode
>>>>> delay problems we have been seeing on dwc2 for some platforms.
>>>>> 
>>>>> I think I have identified the source of the inconsistencies between
>>>>> platforms and this series attempts to address them.
>>>>> 
>>>>> Basically everything stems from the IDDIG debounce filter delay, which
>>>>> is a function of the PHY clock speed and can range from 5-50 ms if
>>>>> enabled. This delay must be taken into account on core reset and force
>>>>> modes. A full explanation is provided in the patch commit log and code
>>>>> comments.
>>>>> 
>>>>> The first two patches are prerequisites to the force mode fixes,
>>>>> including one patch that was sent separately by Przemek Rudy. I have
>>>>> resubmitted it with this series for convenience.
>>>>> 
>>>>> Please help by reviewing and testing on your platforms.
>>>>> 
>>>>> Patches were tested on:
>>>>> * Synopsys HAPS platform IP 3.20a OTG, dr_mode=OTG,HOST,PERIPHERAL
>>>>> 
>>>>> Regards,
>>>>> John
>>>>> 
>>>>> John Youn (3):
>>>>> usb: dwc2: gadget: Only initialize device if in device mode
>>>>> usb: dwc2: Add delay to core soft reset
>>>>> usb: dwc2: Properly account for the force mode delays
>>>>> 
>>>>> Przemek Rudy (1):
>>>>> usb: dwc2: do not override forced dr_mode in gadget setup
>>>>> 
>>>>> drivers/usb/dwc2/core.c | 195 
>>>>> 
>>>>> drivers/usb/dwc2/core.h |   2 +-
>>>>> drivers/usb/dwc2/gadget.c   |  30 +--
>>>>> drivers/usb/dwc2/hcd.c  |   6 +-
>>>>> drivers/usb/dwc2/hw.h   |   1 +
>>>>> drivers/usb/dwc2/platform.c |   9 +-
>>>>> 6 files changed, 161 insertions(+), 82 deletions(-)
>>>>> 
>>>>> -- 
>>>>> 2.7.4
>>>>> 
>>>> 
>>>> after applying your patch series on v4.6-rc1 usb keeps being broken on 
>>>> rk3188.
>>>> Besides that I get "dwc2 1018.usb: dwc2_wait_for_mode: Couldn't set 
>>>> host mode“ repeatedly.
>>>> 
>>>> Currently this works for me:
>>>> - Revert "usb: dwc2: Fix probe problem on bcm2835“
>>>> - Apply "usb: dwc2: Add a 10 ms delay to dwc2_core_reset()"
>>>> 
>>>> 
>>>> Best regards
>>>> Michael
>>>> 
>>> 
>>> Thanks Michael.
>>> 
>>> I won't be able to look at this again until next week. In the meantime
>>> could you provide a driver log? In particular I want to see the values
>>> of your GHWCFG registers, and where you are seeing the
>>> dwc2_wait_for_mode() failure.
>>> 
>>> Regards,
>>> John
>> 
>> Looks like the problem is gone on -rc2… on -rc1 the errors came up shortly 
>> after "dwc2 1018.usb“ messages.
>> USB keeps being broken, though. The USB hub is detected but nothing that is 
>> attached to it.
>> 
>> Here are the logs and register values for each test with Doug’s and your 
>> patches.
>> 
>> Michael
>> 
>> 
>> good usb, Doug's patches
>> 
>> [0.420125] usbcore: registered new interface driver usbfs
>>
>> [0.426246] usbcore: registered new interface driver hub  
>>
>> [0.432296] usbcore: registered new device driver usb
>> [...]
>> [0.853769] 1018.usb supply vusb_d not found, using dummy regulator   
>>
>> [0.860560] 1018.usb supply vusb_a not found, using dummy regulator   
>>
>> [0.867365] dwc2 1018.usb: Configuration mismatch. dr_mode forced to 
>> host
>> [0.977737] dwc2 1018.usb: 128 invalid for host_nperio_tx_fifo_size. 
>> Check H.
>> [0.986562] dwc2 101

Re: [RFT PATCH 0/4] usb: dwc2: Fix core reset and force mode delay problems

[Michael Niewoehner]

Am 07.04.2016 um 20:41 schrieb John Youn <john.y...@synopsys.com>:

> On 3/31/2016 2:44 PM, Michael Niewoehner wrote:
>> Hi John,
>> 
>> Am 29.03.2016 um 04:36 schrieb John Youn <johny...@synopsys.com>:
>> 
>>> Hi,
>>> 
>>> The following patch series addresses the core reset and force mode
>>> delay problems we have been seeing on dwc2 for some platforms.
>>> 
>>> I think I have identified the source of the inconsistencies between
>>> platforms and this series attempts to address them.
>>> 
>>> Basically everything stems from the IDDIG debounce filter delay, which
>>> is a function of the PHY clock speed and can range from 5-50 ms if
>>> enabled. This delay must be taken into account on core reset and force
>>> modes. A full explanation is provided in the patch commit log and code
>>> comments.
>>> 
>>> The first two patches are prerequisites to the force mode fixes,
>>> including one patch that was sent separately by Przemek Rudy. I have
>>> resubmitted it with this series for convenience.
>>> 
>>> Please help by reviewing and testing on your platforms.
>>> 
>>> Patches were tested on:
>>> * Synopsys HAPS platform IP 3.20a OTG, dr_mode=OTG,HOST,PERIPHERAL
>>> 
>>> Regards,
>>> John
>>> 
>>> John Youn (3):
>>> usb: dwc2: gadget: Only initialize device if in device mode
>>> usb: dwc2: Add delay to core soft reset
>>> usb: dwc2: Properly account for the force mode delays
>>> 
>>> Przemek Rudy (1):
>>> usb: dwc2: do not override forced dr_mode in gadget setup
>>> 
>>> drivers/usb/dwc2/core.c | 195 
>>> 
>>> drivers/usb/dwc2/core.h |   2 +-
>>> drivers/usb/dwc2/gadget.c   |  30 +--
>>> drivers/usb/dwc2/hcd.c  |   6 +-
>>> drivers/usb/dwc2/hw.h   |   1 +
>>> drivers/usb/dwc2/platform.c |   9 +-
>>> 6 files changed, 161 insertions(+), 82 deletions(-)
>>> 
>>> -- 
>>> 2.7.4
>>> 
>> 
>> after applying your patch series on v4.6-rc1 usb keeps being broken on 
>> rk3188.
>> Besides that I get "dwc2 1018.usb: dwc2_wait_for_mode: Couldn't set host 
>> mode“ repeatedly.
>> 
>> Currently this works for me:
>> - Revert "usb: dwc2: Fix probe problem on bcm2835“
>> - Apply "usb: dwc2: Add a 10 ms delay to dwc2_core_reset()"
>> 
>> 
>> Best regards
>> Michael
>> 
> 
> Thanks Michael.
> 
> I won't be able to look at this again until next week. In the meantime
> could you provide a driver log? In particular I want to see the values
> of your GHWCFG registers, and where you are seeing the
> dwc2_wait_for_mode() failure.
> 
> Regards,
> John

Looks like the problem is gone on -rc2… on -rc1 the errors came up shortly 
after "dwc2 1018.usb“ messages.
USB keeps being broken, though. The USB hub is detected but nothing that is 
attached to it.

Here are the logs and register values for each test with Doug’s and your 
patches.

Michael


good usb, Doug's patches

[0.420125] usbcore: registered new interface driver usbfs   

[0.426246] usbcore: registered new interface driver hub 

[0.432296] usbcore: registered new device driver usb
[...]
[0.853769] 1018.usb supply vusb_d not found, using dummy regulator  

[0.860560] 1018.usb supply vusb_a not found, using dummy regulator  

[0.867365] dwc2 1018.usb: Configuration mismatch. dr_mode forced to 
host
[0.977737] dwc2 1018.usb: 128 invalid for host_nperio_tx_fifo_size. 
Check H.
[0.986562] dwc2 1018.usb: 256 invalid for host_perio_tx_fifo_size. 
Check HW.
[1.047959] dwc2 1018.usb: DWC OTG Controller

[1.052732] dwc2 1018.usb: new USB bus registered, assigned bus number 1 

[1.059868] dwc2 1018.usb: irq 24, io mem 0x 

[1.065586] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002

[1.072430] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1   
[1.079706] usb usb1: Product: DWC OTG Controller

[1.084432] usb usb1: Manufacturer: Linux 4.6.0-rc2+ dwc2_hsotg  

[1.090390] usb usb1: SerialNumber: 1018.usb 

[1.096000] hub 1-0:1.0: USB hub found   

[1.099884] hub 1-0:1.0: 1 port detected 

[1

Re: [RFT PATCH 0/4] usb: dwc2: Fix core reset and force mode delay problems

[Michael Niewoehner]

Am 07.04.2016 um 20:41 schrieb John Youn :

> On 3/31/2016 2:44 PM, Michael Niewoehner wrote:
>> Hi John,
>> 
>> Am 29.03.2016 um 04:36 schrieb John Youn :
>> 
>>> Hi,
>>> 
>>> The following patch series addresses the core reset and force mode
>>> delay problems we have been seeing on dwc2 for some platforms.
>>> 
>>> I think I have identified the source of the inconsistencies between
>>> platforms and this series attempts to address them.
>>> 
>>> Basically everything stems from the IDDIG debounce filter delay, which
>>> is a function of the PHY clock speed and can range from 5-50 ms if
>>> enabled. This delay must be taken into account on core reset and force
>>> modes. A full explanation is provided in the patch commit log and code
>>> comments.
>>> 
>>> The first two patches are prerequisites to the force mode fixes,
>>> including one patch that was sent separately by Przemek Rudy. I have
>>> resubmitted it with this series for convenience.
>>> 
>>> Please help by reviewing and testing on your platforms.
>>> 
>>> Patches were tested on:
>>> * Synopsys HAPS platform IP 3.20a OTG, dr_mode=OTG,HOST,PERIPHERAL
>>> 
>>> Regards,
>>> John
>>> 
>>> John Youn (3):
>>> usb: dwc2: gadget: Only initialize device if in device mode
>>> usb: dwc2: Add delay to core soft reset
>>> usb: dwc2: Properly account for the force mode delays
>>> 
>>> Przemek Rudy (1):
>>> usb: dwc2: do not override forced dr_mode in gadget setup
>>> 
>>> drivers/usb/dwc2/core.c | 195 
>>> 
>>> drivers/usb/dwc2/core.h |   2 +-
>>> drivers/usb/dwc2/gadget.c   |  30 +--
>>> drivers/usb/dwc2/hcd.c  |   6 +-
>>> drivers/usb/dwc2/hw.h   |   1 +
>>> drivers/usb/dwc2/platform.c |   9 +-
>>> 6 files changed, 161 insertions(+), 82 deletions(-)
>>> 
>>> -- 
>>> 2.7.4
>>> 
>> 
>> after applying your patch series on v4.6-rc1 usb keeps being broken on 
>> rk3188.
>> Besides that I get "dwc2 1018.usb: dwc2_wait_for_mode: Couldn't set host 
>> mode“ repeatedly.
>> 
>> Currently this works for me:
>> - Revert "usb: dwc2: Fix probe problem on bcm2835“
>> - Apply "usb: dwc2: Add a 10 ms delay to dwc2_core_reset()"
>> 
>> 
>> Best regards
>> Michael
>> 
> 
> Thanks Michael.
> 
> I won't be able to look at this again until next week. In the meantime
> could you provide a driver log? In particular I want to see the values
> of your GHWCFG registers, and where you are seeing the
> dwc2_wait_for_mode() failure.
> 
> Regards,
> John

Looks like the problem is gone on -rc2… on -rc1 the errors came up shortly 
after "dwc2 1018.usb“ messages.
USB keeps being broken, though. The USB hub is detected but nothing that is 
attached to it.

Here are the logs and register values for each test with Doug’s and your 
patches.

Michael


good usb, Doug's patches

[0.420125] usbcore: registered new interface driver usbfs   

[0.426246] usbcore: registered new interface driver hub 

[0.432296] usbcore: registered new device driver usb
[...]
[0.853769] 1018.usb supply vusb_d not found, using dummy regulator  

[0.860560] 1018.usb supply vusb_a not found, using dummy regulator  

[0.867365] dwc2 1018.usb: Configuration mismatch. dr_mode forced to 
host
[0.977737] dwc2 1018.usb: 128 invalid for host_nperio_tx_fifo_size. 
Check H.
[0.986562] dwc2 1018.usb: 256 invalid for host_perio_tx_fifo_size. 
Check HW.
[1.047959] dwc2 1018.usb: DWC OTG Controller

[1.052732] dwc2 1018.usb: new USB bus registered, assigned bus number 1 

[1.059868] dwc2 1018.usb: irq 24, io mem 0x 

[1.065586] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002

[1.072430] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1   
[1.079706] usb usb1: Product: DWC OTG Controller

[1.084432] usb usb1: Manufacturer: Linux 4.6.0-rc2+ dwc2_hsotg  

[1.090390] usb usb1: SerialNumber: 1018.usb 

[1.096000] hub 1-0:1.0: USB hub found   

[1.099884] hub 1-0:1.0: 1 port detected 

[1.104668] 101c.usb supply vusb_d not found, using dummy regulator

Re: [RFT PATCH 0/4] usb: dwc2: Fix core reset and force mode delay problems

[Michael Niewoehner]

Hi John,

Am 29.03.2016 um 04:36 schrieb John Youn :

> Hi,
> 
> The following patch series addresses the core reset and force mode
> delay problems we have been seeing on dwc2 for some platforms.
> 
> I think I have identified the source of the inconsistencies between
> platforms and this series attempts to address them.
> 
> Basically everything stems from the IDDIG debounce filter delay, which
> is a function of the PHY clock speed and can range from 5-50 ms if
> enabled. This delay must be taken into account on core reset and force
> modes. A full explanation is provided in the patch commit log and code
> comments.
> 
> The first two patches are prerequisites to the force mode fixes,
> including one patch that was sent separately by Przemek Rudy. I have
> resubmitted it with this series for convenience.
> 
> Please help by reviewing and testing on your platforms.
> 
> Patches were tested on:
> * Synopsys HAPS platform IP 3.20a OTG, dr_mode=OTG,HOST,PERIPHERAL
> 
> Regards,
> John
> 
> John Youn (3):
> usb: dwc2: gadget: Only initialize device if in device mode
> usb: dwc2: Add delay to core soft reset
> usb: dwc2: Properly account for the force mode delays
> 
> Przemek Rudy (1):
> usb: dwc2: do not override forced dr_mode in gadget setup
> 
> drivers/usb/dwc2/core.c | 195 
> drivers/usb/dwc2/core.h |   2 +-
> drivers/usb/dwc2/gadget.c   |  30 +--
> drivers/usb/dwc2/hcd.c  |   6 +-
> drivers/usb/dwc2/hw.h   |   1 +
> drivers/usb/dwc2/platform.c |   9 +-
> 6 files changed, 161 insertions(+), 82 deletions(-)
> 
> -- 
> 2.7.4
> 

after applying your patch series on v4.6-rc1 usb keeps being broken on rk3188.
Besides that I get "dwc2 1018.usb: dwc2_wait_for_mode: Couldn't set host 
mode“ repeatedly.

Currently this works for me:
- Revert "usb: dwc2: Fix probe problem on bcm2835“
- Apply "usb: dwc2: Add a 10 ms delay to dwc2_core_reset()"


Best regards
Michael

Re: [RFT PATCH 0/4] usb: dwc2: Fix core reset and force mode delay problems

[Michael Niewoehner]

Hi John,

Am 29.03.2016 um 04:36 schrieb John Youn :

> Hi,
> 
> The following patch series addresses the core reset and force mode
> delay problems we have been seeing on dwc2 for some platforms.
> 
> I think I have identified the source of the inconsistencies between
> platforms and this series attempts to address them.
> 
> Basically everything stems from the IDDIG debounce filter delay, which
> is a function of the PHY clock speed and can range from 5-50 ms if
> enabled. This delay must be taken into account on core reset and force
> modes. A full explanation is provided in the patch commit log and code
> comments.
> 
> The first two patches are prerequisites to the force mode fixes,
> including one patch that was sent separately by Przemek Rudy. I have
> resubmitted it with this series for convenience.
> 
> Please help by reviewing and testing on your platforms.
> 
> Patches were tested on:
> * Synopsys HAPS platform IP 3.20a OTG, dr_mode=OTG,HOST,PERIPHERAL
> 
> Regards,
> John
> 
> John Youn (3):
> usb: dwc2: gadget: Only initialize device if in device mode
> usb: dwc2: Add delay to core soft reset
> usb: dwc2: Properly account for the force mode delays
> 
> Przemek Rudy (1):
> usb: dwc2: do not override forced dr_mode in gadget setup
> 
> drivers/usb/dwc2/core.c | 195 
> drivers/usb/dwc2/core.h |   2 +-
> drivers/usb/dwc2/gadget.c   |  30 +--
> drivers/usb/dwc2/hcd.c  |   6 +-
> drivers/usb/dwc2/hw.h   |   1 +
> drivers/usb/dwc2/platform.c |   9 +-
> 6 files changed, 161 insertions(+), 82 deletions(-)
> 
> -- 
> 2.7.4
> 

after applying your patch series on v4.6-rc1 usb keeps being broken on rk3188.
Besides that I get "dwc2 1018.usb: dwc2_wait_for_mode: Couldn't set host 
mode“ repeatedly.

Currently this works for me:
- Revert "usb: dwc2: Fix probe problem on bcm2835“
- Apply "usb: dwc2: Add a 10 ms delay to dwc2_core_reset()"


Best regards
Michael

Re: [RFT PATCH 0/4] usb: dwc2: Fix core reset and force mode delay problems

[Michael Niewoehner]

Hi John,

Am 29.03.2016 um 04:36 schrieb John Youn :

> Hi,
> 
> The following patch series addresses the core reset and force mode
> delay problems we have been seeing on dwc2 for some platforms.
> 
> I think I have identified the source of the inconsistencies between
> platforms and this series attempts to address them.
> 
> Basically everything stems from the IDDIG debounce filter delay, which
> is a function of the PHY clock speed and can range from 5-50 ms if
> enabled. This delay must be taken into account on core reset and force
> modes. A full explanation is provided in the patch commit log and code
> comments.
> 
> The first two patches are prerequisites to the force mode fixes,
> including one patch that was sent separately by Przemek Rudy. I have
> resubmitted it with this series for convenience.
> 
> Please help by reviewing and testing on your platforms.
> 
> Patches were tested on:
> * Synopsys HAPS platform IP 3.20a OTG, dr_mode=OTG,HOST,PERIPHERAL
> 
> Regards,
> John
> 
> John Youn (3):
>  usb: dwc2: gadget: Only initialize device if in device mode
>  usb: dwc2: Add delay to core soft reset
>  usb: dwc2: Properly account for the force mode delays
> 
> Przemek Rudy (1):
>  usb: dwc2: do not override forced dr_mode in gadget setup
> 
> drivers/usb/dwc2/core.c | 195 
> drivers/usb/dwc2/core.h |   2 +-
> drivers/usb/dwc2/gadget.c   |  30 +--
> drivers/usb/dwc2/hcd.c  |   6 +-
> drivers/usb/dwc2/hw.h   |   1 +
> drivers/usb/dwc2/platform.c |   9 +-
> 6 files changed, 161 insertions(+), 82 deletions(-)
> 
> -- 
> 2.7.4
> 

after applying your patch series on v4.6-rc1 usb keeps being broken on rk3188.
Besides that I get "dwc2 1018.usb: dwc2_wait_for_mode: Couldn't set host 
mode“ repeatedly.

Currently this works for me:
- Revert "usb: dwc2: Fix probe problem on bcm2835“
- Apply "usb: dwc2: Add a 10 ms delay to dwc2_core_reset()"


Best regards
Michael

Re: [RFT PATCH 0/4] usb: dwc2: Fix core reset and force mode delay problems

[Michael Niewoehner]

Hi John,

Am 29.03.2016 um 04:36 schrieb John Youn :

> Hi,
> 
> The following patch series addresses the core reset and force mode
> delay problems we have been seeing on dwc2 for some platforms.
> 
> I think I have identified the source of the inconsistencies between
> platforms and this series attempts to address them.
> 
> Basically everything stems from the IDDIG debounce filter delay, which
> is a function of the PHY clock speed and can range from 5-50 ms if
> enabled. This delay must be taken into account on core reset and force
> modes. A full explanation is provided in the patch commit log and code
> comments.
> 
> The first two patches are prerequisites to the force mode fixes,
> including one patch that was sent separately by Przemek Rudy. I have
> resubmitted it with this series for convenience.
> 
> Please help by reviewing and testing on your platforms.
> 
> Patches were tested on:
> * Synopsys HAPS platform IP 3.20a OTG, dr_mode=OTG,HOST,PERIPHERAL
> 
> Regards,
> John
> 
> John Youn (3):
>  usb: dwc2: gadget: Only initialize device if in device mode
>  usb: dwc2: Add delay to core soft reset
>  usb: dwc2: Properly account for the force mode delays
> 
> Przemek Rudy (1):
>  usb: dwc2: do not override forced dr_mode in gadget setup
> 
> drivers/usb/dwc2/core.c | 195 
> drivers/usb/dwc2/core.h |   2 +-
> drivers/usb/dwc2/gadget.c   |  30 +--
> drivers/usb/dwc2/hcd.c  |   6 +-
> drivers/usb/dwc2/hw.h   |   1 +
> drivers/usb/dwc2/platform.c |   9 +-
> 6 files changed, 161 insertions(+), 82 deletions(-)
> 
> -- 
> 2.7.4
> 

after applying your patch series on v4.6-rc1 usb keeps being broken on rk3188.
Besides that I get "dwc2 1018.usb: dwc2_wait_for_mode: Couldn't set host 
mode“ repeatedly.

Currently this works for me:
- Revert "usb: dwc2: Fix probe problem on bcm2835“
- Apply "usb: dwc2: Add a 10 ms delay to dwc2_core_reset()"


Best regards
Michael

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

[Michael Niewoehner]

Hi Douglas,
Hi John,

Am 05.03.2016 um 01:33 schrieb Doug Anderson <diand...@chromium.org>:

> Michael,
> 
> On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner <li...@mniewoehner.de> 
> wrote:
>>>> From testing and trying to make sense of the documentation, it appears
>>>> that a 10 ms delay is needed after resetting the core to make sure that
>>>> everything is stable and consistent.  Let's add it.
>>>> 
>>>> In my testing (on rk3288) this allows us to revert commit
>>>> 192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835").  Though I
>>>> could never reproduce the problems on my board, this might also allow us
>>>> to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
>>>> dr_mode").
>>>> 
>>>> Signed-off-by: Douglas Anderson <diand...@chromium.org>
>>> 
>>> Tested-by: Michael Niewoehner <li...@mniewoehner.de>
> 
> Thanks!  That's great news!
> 
> 
>>> I’m a bit confused since git log says bd84f4ae9986 has been merged in 
>>> 62718e304aa6 but looking at drivers/usb/dwc2/core.c it seems the patch has 
>>> not been applied anyways ...
>>> However, I tested you your two patches with „magically reverted“ 
>>> bd84f4ae9986 (msleep 50) on rk3188.
>>> The sdcard keeps being detected and boots just fine.
>> I meant usb stick of course… too much sdcards in my head today \o/.
> 
> Odd.  It looks to be there for me...
> 
> $ git checkout 62718e304aa6
> HEAD is now at 62718e304aa6... Merge tag 'usb-4.5-rc6' of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
> 
> $ git grep -C3 "NOTE: This is required" -- drivers/usb/dwc2/core.c
> drivers/usb/dwc2/core.c-}
> drivers/usb/dwc2/core.c-
> drivers/usb/dwc2/core.c-/*
> drivers/usb/dwc2/core.c: * NOTE: This is required for some
> rockchip soc based
> drivers/usb/dwc2/core.c- * platforms.
> drivers/usb/dwc2/core.c- */
> drivers/usb/dwc2/core.c-msleep(50);

I unfortunately have bad news.
After some more testing it turned out that usb does NOT work (always) on rk3188 
when reverting bd84f4ae9986.
It looks like that is dependent on which device / vendor is plugged in.
The usb stick I tested yesterday worked once but today just blinks shortly and 
then stops working.
Another usb stick I tested today doesn’t blink or work at all. Maybe I should 
have tested booting some more times :-(

Best regards
Michael

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

[Michael Niewoehner]

Hi Douglas,
Hi John,

Am 05.03.2016 um 01:33 schrieb Doug Anderson :

> Michael,
> 
> On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner  
> wrote:
>>>> From testing and trying to make sense of the documentation, it appears
>>>> that a 10 ms delay is needed after resetting the core to make sure that
>>>> everything is stable and consistent.  Let's add it.
>>>> 
>>>> In my testing (on rk3288) this allows us to revert commit
>>>> 192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835").  Though I
>>>> could never reproduce the problems on my board, this might also allow us
>>>> to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
>>>> dr_mode").
>>>> 
>>>> Signed-off-by: Douglas Anderson 
>>> 
>>> Tested-by: Michael Niewoehner 
> 
> Thanks!  That's great news!
> 
> 
>>> I’m a bit confused since git log says bd84f4ae9986 has been merged in 
>>> 62718e304aa6 but looking at drivers/usb/dwc2/core.c it seems the patch has 
>>> not been applied anyways ...
>>> However, I tested you your two patches with „magically reverted“ 
>>> bd84f4ae9986 (msleep 50) on rk3188.
>>> The sdcard keeps being detected and boots just fine.
>> I meant usb stick of course… too much sdcards in my head today \o/.
> 
> Odd.  It looks to be there for me...
> 
> $ git checkout 62718e304aa6
> HEAD is now at 62718e304aa6... Merge tag 'usb-4.5-rc6' of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
> 
> $ git grep -C3 "NOTE: This is required" -- drivers/usb/dwc2/core.c
> drivers/usb/dwc2/core.c-}
> drivers/usb/dwc2/core.c-
> drivers/usb/dwc2/core.c-/*
> drivers/usb/dwc2/core.c: * NOTE: This is required for some
> rockchip soc based
> drivers/usb/dwc2/core.c- * platforms.
> drivers/usb/dwc2/core.c- */
> drivers/usb/dwc2/core.c-msleep(50);

I unfortunately have bad news.
After some more testing it turned out that usb does NOT work (always) on rk3188 
when reverting bd84f4ae9986.
It looks like that is dependent on which device / vendor is plugged in.
The usb stick I tested yesterday worked once but today just blinks shortly and 
then stops working.
Another usb stick I tested today doesn’t blink or work at all. Maybe I should 
have tested booting some more times :-(

Best regards
Michael

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

[Michael Niewoehner]

Hi Douglas,

Am 04.03.2016 um 23:54 schrieb Michael Niewoehner <li...@mniewoehner.de>:

> Hi Douglas,
> 
> Am 04.03.2016 um 19:23 schrieb Douglas Anderson <diand...@chromium.org>:
> 
>> From testing and trying to make sense of the documentation, it appears
>> that a 10 ms delay is needed after resetting the core to make sure that
>> everything is stable and consistent.  Let's add it.
>> 
>> In my testing (on rk3288) this allows us to revert commit
>> 192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835").  Though I
>> could never reproduce the problems on my board, this might also allow us
>> to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
>> dr_mode").
>> 
>> Signed-off-by: Douglas Anderson <diand...@chromium.org>
> 
> Tested-by: Michael Niewoehner <li...@mniewoehner.de>
> 
>> ---
>> drivers/usb/dwc2/core.c | 20 
>> 1 file changed, 20 insertions(+)
>> 
>> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
>> index 5e5a0f135b5a..8710b2d3e770 100644
>> --- a/drivers/usb/dwc2/core.c
>> +++ b/drivers/usb/dwc2/core.c
>> @@ -277,6 +277,26 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
>>  }
>>  } while (!(greset & GRSTCTL_AHBIDLE));
>> 
>> +/*
>> + * Sleep for 10-15 ms after the reset to let it finish.
>> + *
>> + * It's been confirmed on at least one version of the controller
>> + * that this is a requirement that this is a requirement in order for
>> + * everything to settle.  Specifically if you:
>> + * - change GNPTXFSIZ or HPTXFSIZ before the reset
>> + * - do the reset
>> + * - read GNPTXFSIZ or HPTXFSIZ in a loop
>> + * ...you'll find that it takes almost exactly 10 ms for the registers
>> + * to return to their reset defaults.
>> + *
>> + * Note that it's possible that this 10 ms is the time referred to
>> + * in "Host Initialization" where it says to "Wait at least 10 ms for
>> + * the reset process to complete".  In "Device Initialization" there
>> + * is also talk of a reset lasting 10 ms.  That may be the source of
>> + * this delay.
>> + */
>> +usleep_range(1, 15000);
>> +
>>  return 0;
>> }
>> 
>> -- 
>> 2.7.0.rc3.207.g0ac5344
>> 
> 
> I’m a bit confused since git log says bd84f4ae9986 has been merged in 
> 62718e304aa6 but looking at drivers/usb/dwc2/core.c it seems the patch has 
> not been applied anyways ...
> However, I tested you your two patches with „magically reverted“ bd84f4ae9986 
> (msleep 50) on rk3188.
> The sdcard keeps being detected and boots just fine.
> 
> Best regards
> Michael

I meant usb stick of course… too much sdcards in my head today \o/.

Regards
Michael

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

[Michael Niewoehner]

Hi Douglas,

Am 04.03.2016 um 23:54 schrieb Michael Niewoehner :

> Hi Douglas,
> 
> Am 04.03.2016 um 19:23 schrieb Douglas Anderson :
> 
>> From testing and trying to make sense of the documentation, it appears
>> that a 10 ms delay is needed after resetting the core to make sure that
>> everything is stable and consistent.  Let's add it.
>> 
>> In my testing (on rk3288) this allows us to revert commit
>> 192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835").  Though I
>> could never reproduce the problems on my board, this might also allow us
>> to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
>> dr_mode").
>> 
>> Signed-off-by: Douglas Anderson 
> 
> Tested-by: Michael Niewoehner 
> 
>> ---
>> drivers/usb/dwc2/core.c | 20 
>> 1 file changed, 20 insertions(+)
>> 
>> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
>> index 5e5a0f135b5a..8710b2d3e770 100644
>> --- a/drivers/usb/dwc2/core.c
>> +++ b/drivers/usb/dwc2/core.c
>> @@ -277,6 +277,26 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
>>  }
>>  } while (!(greset & GRSTCTL_AHBIDLE));
>> 
>> +/*
>> + * Sleep for 10-15 ms after the reset to let it finish.
>> + *
>> + * It's been confirmed on at least one version of the controller
>> + * that this is a requirement that this is a requirement in order for
>> + * everything to settle.  Specifically if you:
>> + * - change GNPTXFSIZ or HPTXFSIZ before the reset
>> + * - do the reset
>> + * - read GNPTXFSIZ or HPTXFSIZ in a loop
>> + * ...you'll find that it takes almost exactly 10 ms for the registers
>> + * to return to their reset defaults.
>> + *
>> + * Note that it's possible that this 10 ms is the time referred to
>> + * in "Host Initialization" where it says to "Wait at least 10 ms for
>> + * the reset process to complete".  In "Device Initialization" there
>> + * is also talk of a reset lasting 10 ms.  That may be the source of
>> + * this delay.
>> + */
>> +usleep_range(1, 15000);
>> +
>>  return 0;
>> }
>> 
>> -- 
>> 2.7.0.rc3.207.g0ac5344
>> 
> 
> I’m a bit confused since git log says bd84f4ae9986 has been merged in 
> 62718e304aa6 but looking at drivers/usb/dwc2/core.c it seems the patch has 
> not been applied anyways ...
> However, I tested you your two patches with „magically reverted“ bd84f4ae9986 
> (msleep 50) on rk3188.
> The sdcard keeps being detected and boots just fine.
> 
> Best regards
> Michael

I meant usb stick of course… too much sdcards in my head today \o/.

Regards
Michael

Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"

[Michael Niewoehner]

Am 04.03.2016 um 19:23 schrieb Douglas Anderson <diand...@chromium.org>:

> This reverts commit 192cb07f7928 ("usb: dwc2: Fix probe problem on
> bcm2835") now that we've found the root cause.  See the change
> titled ("usb: dwc2: Add a 10 ms delay to dwc2_core_reset()").
> 
> Signed-off-by: Douglas Anderson <diand...@chromium.org>

Tested-by: Michael Niewoehner <li...@mniewoehner.de>

> ---
> drivers/usb/dwc2/core.c | 6 ++
> 1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 8710b2d3e770..7c4a6cf4c73a 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -353,6 +353,12 @@ static bool dwc2_force_mode(struct dwc2_hsotg *hsotg, 
> bool host)
>   set = host ? GUSBCFG_FORCEHOSTMODE : GUSBCFG_FORCEDEVMODE;
>   clear = host ? GUSBCFG_FORCEDEVMODE : GUSBCFG_FORCEHOSTMODE;
> 
> + /*
> + * If the force mode bit is already set, don't set it.
> + */
> + if ((gusbcfg & set) && !(gusbcfg & clear))
> + return false;
> +
>   gusbcfg &= ~clear;
>   gusbcfg |= set;
>   dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
> -- 
> 2.7.0.rc3.207.g0ac5344
> 

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

[Michael Niewoehner]

Hi Douglas,

Am 04.03.2016 um 19:23 schrieb Douglas Anderson <diand...@chromium.org>:

> From testing and trying to make sense of the documentation, it appears
> that a 10 ms delay is needed after resetting the core to make sure that
> everything is stable and consistent.  Let's add it.
> 
> In my testing (on rk3288) this allows us to revert commit
> 192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835").  Though I
> could never reproduce the problems on my board, this might also allow us
> to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
> dr_mode").
> 
> Signed-off-by: Douglas Anderson <diand...@chromium.org>

Tested-by: Michael Niewoehner <li...@mniewoehner.de>

> ---
> drivers/usb/dwc2/core.c | 20 
> 1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 5e5a0f135b5a..8710b2d3e770 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -277,6 +277,26 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
>   }
>   } while (!(greset & GRSTCTL_AHBIDLE));
> 
> + /*
> +  * Sleep for 10-15 ms after the reset to let it finish.
> +  *
> +  * It's been confirmed on at least one version of the controller
> +  * that this is a requirement that this is a requirement in order for
> +  * everything to settle.  Specifically if you:
> +  * - change GNPTXFSIZ or HPTXFSIZ before the reset
> +  * - do the reset
> +  * - read GNPTXFSIZ or HPTXFSIZ in a loop
> +  * ...you'll find that it takes almost exactly 10 ms for the registers
> +  * to return to their reset defaults.
> +  *
> +  * Note that it's possible that this 10 ms is the time referred to
> +  * in "Host Initialization" where it says to "Wait at least 10 ms for
> +  * the reset process to complete".  In "Device Initialization" there
> +  * is also talk of a reset lasting 10 ms.  That may be the source of
> +  * this delay.
> +  */
> + usleep_range(1, 15000);
> +
>   return 0;
> }
> 
> -- 
> 2.7.0.rc3.207.g0ac5344
> 

I’m a bit confused since git log says bd84f4ae9986 has been merged in 
62718e304aa6 but looking at drivers/usb/dwc2/core.c it seems the patch has not 
been applied anyways ...
However, I tested you your two patches with „magically reverted“ bd84f4ae9986 
(msleep 50) on rk3188.
The sdcard keeps being detected and boots just fine.

Best regards
Michael

Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"

[Michael Niewoehner]

Am 04.03.2016 um 19:23 schrieb Douglas Anderson :

> This reverts commit 192cb07f7928 ("usb: dwc2: Fix probe problem on
> bcm2835") now that we've found the root cause.  See the change
> titled ("usb: dwc2: Add a 10 ms delay to dwc2_core_reset()").
> 
> Signed-off-by: Douglas Anderson 

Tested-by: Michael Niewoehner 

> ---
> drivers/usb/dwc2/core.c | 6 ++
> 1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 8710b2d3e770..7c4a6cf4c73a 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -353,6 +353,12 @@ static bool dwc2_force_mode(struct dwc2_hsotg *hsotg, 
> bool host)
>   set = host ? GUSBCFG_FORCEHOSTMODE : GUSBCFG_FORCEDEVMODE;
>   clear = host ? GUSBCFG_FORCEDEVMODE : GUSBCFG_FORCEHOSTMODE;
> 
> + /*
> + * If the force mode bit is already set, don't set it.
> + */
> + if ((gusbcfg & set) && !(gusbcfg & clear))
> + return false;
> +
>   gusbcfg &= ~clear;
>   gusbcfg |= set;
>   dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
> -- 
> 2.7.0.rc3.207.g0ac5344
> 

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

[Michael Niewoehner]

Hi Douglas,

Am 04.03.2016 um 19:23 schrieb Douglas Anderson :

> From testing and trying to make sense of the documentation, it appears
> that a 10 ms delay is needed after resetting the core to make sure that
> everything is stable and consistent.  Let's add it.
> 
> In my testing (on rk3288) this allows us to revert commit
> 192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835").  Though I
> could never reproduce the problems on my board, this might also allow us
> to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
> dr_mode").
> 
> Signed-off-by: Douglas Anderson 

Tested-by: Michael Niewoehner 

> ---
> drivers/usb/dwc2/core.c | 20 
> 1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 5e5a0f135b5a..8710b2d3e770 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -277,6 +277,26 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
>   }
>   } while (!(greset & GRSTCTL_AHBIDLE));
> 
> + /*
> +  * Sleep for 10-15 ms after the reset to let it finish.
> +  *
> +  * It's been confirmed on at least one version of the controller
> +  * that this is a requirement that this is a requirement in order for
> +  * everything to settle.  Specifically if you:
> +  * - change GNPTXFSIZ or HPTXFSIZ before the reset
> +  * - do the reset
> +  * - read GNPTXFSIZ or HPTXFSIZ in a loop
> +  * ...you'll find that it takes almost exactly 10 ms for the registers
> +  * to return to their reset defaults.
> +  *
> +  * Note that it's possible that this 10 ms is the time referred to
> +  * in "Host Initialization" where it says to "Wait at least 10 ms for
> +  * the reset process to complete".  In "Device Initialization" there
> +  * is also talk of a reset lasting 10 ms.  That may be the source of
> +  * this delay.
> +  */
> + usleep_range(1, 15000);
> +
>   return 0;
> }
> 
> -- 
> 2.7.0.rc3.207.g0ac5344
> 

I’m a bit confused since git log says bd84f4ae9986 has been merged in 
62718e304aa6 but looking at drivers/usb/dwc2/core.c it seems the patch has not 
been applied anyways ...
However, I tested you your two patches with „magically reverted“ bd84f4ae9986 
(msleep 50) on rk3188.
The sdcard keeps being detected and boots just fine.

Best regards
Michael

[PATCH v3] clk: rockchip: add pclk_cpu to the list of rk3188 critical clocks

[Michael Niewoehner]

pclk_cpu needs to keep running because it is needed for devices like
the act8865 regulator but with the recent gpio clock handling this is
not always the case anymore. So add it to the list of critical clocks.

Signed-off-by: Michael Niewoehner 
Reviewed-by: Heiko Stuebner 
---
Changes in v3:
- fix git format-patch problem

Changes in v2:
- adapt commit message
- add Linus Walleij to recipients, as the patch is related to the gpio clock
 change in the rockchip pinctrl driver it should go through his tree as well

 drivers/clk/rockchip/clk-rk3188.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk-rk3188.c 
b/drivers/clk/rockchip/clk-rk3188.c
index ed02bbc..f63a642 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -716,6 +716,7 @@ static const char *const rk3188_critical_clocks[] 
__initconst = {
"aclk_cpu",
"aclk_peri",
"hclk_peri",
+   "pclk_cpu",
 };
 
 static void __init rk3188_common_clk_init(struct device_node *np)
-- 
2.5.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] clk: rockchip: add pclk_cpu to the list of rk3188 critical clocks

[Michael Niewoehner]

pclk_cpu needs to keep running because it is needed for devices like
the act8865 regulator but with the recent gpio clock handling this is
not always the case anymore. So add it to the list of critical clocks.

Signed-off-by: Michael Niewoehner li...@mniewoehner.de
Reviewed-by: Heiko Stuebner he...@sntech.de
---
Changes in v3:
- fix git format-patch problem

Changes in v2:
- adapt commit message
- add Linus Walleij to recipients, as the patch is related to the gpio clock
 change in the rockchip pinctrl driver it should go through his tree as well

 drivers/clk/rockchip/clk-rk3188.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk-rk3188.c 
b/drivers/clk/rockchip/clk-rk3188.c
index ed02bbc..f63a642 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -716,6 +716,7 @@ static const char *const rk3188_critical_clocks[] 
__initconst = {
aclk_cpu,
aclk_peri,
hclk_peri,
+   pclk_cpu,
 };
 
 static void __init rk3188_common_clk_init(struct device_node *np)
-- 
2.5.0


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] clk: rockchip: add pclk_cpu to the list of rk3188 critical clocks

[Michael Niewoehner]

pclk_cpu needs to keep running because it is needed for devices like
the act8865 regulator but with the recent gpio clock handling this is
not always the case anymore. So add it to the list of critical clocks.

Signed-off-by: Michael Niewoehner 
---
Changes in v2:
- adapt commit message
- add Linus Walleij to recipients, as the patch is related to the gpio clock
  change in the rockchip pinctrl driver it should go through his tree as well

drivers/clk/rockchip/clk-rk3188.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk-rk3188.c 
b/drivers/clk/rockchip/clk-rk3188.c
index e4f9d47..1c93229 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -708,6 +708,7 @@ static const char *const rk3188_critical_clocks[] 
__initconst = {
"aclk_cpu",
"aclk_peri",
"hclk_peri",
+   "pclk_cpu",
};

static void __init rk3188_common_clk_init(struct device_node *np)
-- 
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: rockchip: add pclk_cpu to the list of rk3188 critical clocks

[Michael Niewoehner]

Hi Heiko,

I merged yours and mine :-)


pclk_cpu needs to keep running because it is needed for devices like
the act8865 regulator but with the recent gpio clock handling this is
not always the case anymore. So add it to the list of critical clocks.

Signed-off-by: Michael Niewoehner 
---
drivers/clk/rockchip/clk-rk3188.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk-rk3188.c 
b/drivers/clk/rockchip/clk-rk3188.c
index e4f9d47..1c93229 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -708,6 +708,7 @@ static const char *const rk3188_critical_clocks[] 
__initconst = {
"aclk_cpu",
"aclk_peri",
"hclk_peri",
+   "pclk_cpu",
};

static void __init rk3188_common_clk_init(struct device_node *np)
-- 
2.5.0





Am 17.08.2015 um 20:01 schrieb Heiko Stuebner :

> Hi,
> 
> Am Montag, 17. August 2015, 19:38:22 schrieb Michael Niewoehner:
>> gpio clock is getting disabled to save power but pclk_cpu is needed for
>> act8865 regulator
> 
> Please refine the commit message a bit :-) . Something along
> 
> pclk_cpu needs to keep running and with the recent gpio clock
> handling this is not always the case anymore. So add it to the list
> of critical clocks.
> 
> 
> and also please add "Linus Walleij " to the list of 
> recipients. As the gpio clock handling change does go through his tree, the 
> matching critical clock handling should also go through him.
> 
> 
> Heiko
> 
>> 
>> Signed-off-by: Michael Niewoehner 
>> ---
>> drivers/clk/rockchip/clk-rk3188.c | 1 +
>> 1 file changed, 1 insertion(+)
>> 
>> diff --git a/drivers/clk/rockchip/clk-rk3188.c
>> b/drivers/clk/rockchip/clk-rk3188.c index e4f9d47..1c93229 100644
>> --- a/drivers/clk/rockchip/clk-rk3188.c
>> +++ b/drivers/clk/rockchip/clk-rk3188.c
>> @@ -708,6 +708,7 @@ static const char *const rk3188_critical_clocks[]
>> __initconst = { "aclk_cpu",
>>  "aclk_peri",
>>  "hclk_peri",
>> +"pclk_cpu",
>> };
>> 
>> static void __init rk3188_common_clk_init(struct device_node *np)
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] clk: rockchip: add pclk_cpu to the list of rk3188 critical clocks

[Michael Niewoehner]

gpio clock is getting disabled to save power but pclk_cpu is needed for act8865 
regulator

Signed-off-by: Michael Niewoehner 
---
 drivers/clk/rockchip/clk-rk3188.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk-rk3188.c 
b/drivers/clk/rockchip/clk-rk3188.c
index e4f9d47..1c93229 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -708,6 +708,7 @@ static const char *const rk3188_critical_clocks[] 
__initconst = {
"aclk_cpu",
"aclk_peri",
"hclk_peri",
+   "pclk_cpu",
 };
 
 static void __init rk3188_common_clk_init(struct device_node *np)
-- 
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] clk: rockchip: add pclk_cpu to the list of rk3188 critical clocks

[Michael Niewoehner]

gpio clock is getting disabled to save power but pclk_cpu is needed for act8865 
regulator

Signed-off-by: Michael Niewoehner li...@mniewoehner.de
---
 drivers/clk/rockchip/clk-rk3188.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk-rk3188.c 
b/drivers/clk/rockchip/clk-rk3188.c
index e4f9d47..1c93229 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -708,6 +708,7 @@ static const char *const rk3188_critical_clocks[] 
__initconst = {
aclk_cpu,
aclk_peri,
hclk_peri,
+   pclk_cpu,
 };
 
 static void __init rk3188_common_clk_init(struct device_node *np)
-- 
2.5.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: rockchip: add pclk_cpu to the list of rk3188 critical clocks

[Michael Niewoehner]

Hi Heiko,

I merged yours and mine :-)


pclk_cpu needs to keep running because it is needed for devices like
the act8865 regulator but with the recent gpio clock handling this is
not always the case anymore. So add it to the list of critical clocks.

Signed-off-by: Michael Niewoehner li...@mniewoehner.de
---
drivers/clk/rockchip/clk-rk3188.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk-rk3188.c 
b/drivers/clk/rockchip/clk-rk3188.c
index e4f9d47..1c93229 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -708,6 +708,7 @@ static const char *const rk3188_critical_clocks[] 
__initconst = {
aclk_cpu,
aclk_peri,
hclk_peri,
+   pclk_cpu,
};

static void __init rk3188_common_clk_init(struct device_node *np)
-- 
2.5.0





Am 17.08.2015 um 20:01 schrieb Heiko Stuebner he...@sntech.de:

 Hi,
 
 Am Montag, 17. August 2015, 19:38:22 schrieb Michael Niewoehner:
 gpio clock is getting disabled to save power but pclk_cpu is needed for
 act8865 regulator
 
 Please refine the commit message a bit :-) . Something along
 
 pclk_cpu needs to keep running and with the recent gpio clock
 handling this is not always the case anymore. So add it to the list
 of critical clocks.
 
 
 and also please add Linus Walleij linus.wall...@linaro.org to the list of 
 recipients. As the gpio clock handling change does go through his tree, the 
 matching critical clock handling should also go through him.
 
 
 Heiko
 
 
 Signed-off-by: Michael Niewoehner li...@mniewoehner.de
 ---
 drivers/clk/rockchip/clk-rk3188.c | 1 +
 1 file changed, 1 insertion(+)
 
 diff --git a/drivers/clk/rockchip/clk-rk3188.c
 b/drivers/clk/rockchip/clk-rk3188.c index e4f9d47..1c93229 100644
 --- a/drivers/clk/rockchip/clk-rk3188.c
 +++ b/drivers/clk/rockchip/clk-rk3188.c
 @@ -708,6 +708,7 @@ static const char *const rk3188_critical_clocks[]
 __initconst = { aclk_cpu,
  aclk_peri,
  hclk_peri,
 +pclk_cpu,
 };
 
 static void __init rk3188_common_clk_init(struct device_node *np)
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] clk: rockchip: add pclk_cpu to the list of rk3188 critical clocks

[Michael Niewoehner]

pclk_cpu needs to keep running because it is needed for devices like
the act8865 regulator but with the recent gpio clock handling this is
not always the case anymore. So add it to the list of critical clocks.

Signed-off-by: Michael Niewoehner li...@mniewoehner.de
---
Changes in v2:
- adapt commit message
- add Linus Walleij to recipients, as the patch is related to the gpio clock
  change in the rockchip pinctrl driver it should go through his tree as well

drivers/clk/rockchip/clk-rk3188.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk-rk3188.c 
b/drivers/clk/rockchip/clk-rk3188.c
index e4f9d47..1c93229 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -708,6 +708,7 @@ static const char *const rk3188_critical_clocks[] 
__initconst = {
aclk_cpu,
aclk_peri,
hclk_peri,
+   pclk_cpu,
};

static void __init rk3188_common_clk_init(struct device_node *np)
-- 
2.5.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/