Re: [Letux-kernel] [PATCH v3 3/3] arm: omap_hwmod disable ick autoidling when a hwmod requires that
On 19/01/19 1:28 PM, J, KEERTHY wrote: > > > On 1/19/2019 12:42 PM, Andreas Kemnade wrote: >> On Sat, 19 Jan 2019 12:09:48 +0530 >> "J, KEERTHY" wrote: >> >>> On 1/19/2019 1:18 AM, Tony Lindgren wrote: * Andreas Kemnade [190118 19:42]: > On Fri, 18 Jan 2019 20:38:47 +0100 > Andreas Kemnade wrote: > >> Hi, >> >> On Fri, 18 Jan 2019 10:36:30 -0800 >> Tony Lindgren wrote: >> >> [...] >>> til the next workaround. >>> That flags also causes the iclk being enabled/disabled manually. >>> >>> Yes but SWSUP_IDLE for the interface clock to me currently >>> just means: >>> >>> "manually enable and disable ocp interface clock" >>> >> well, if we want to manually disable it and not automatically, >> we have to disable autoidle or it will be automatically disabled. >> >> Disabling it manually when it is already auto-disabled (by >> autoidle) is >> just practically a no-op towards the clock. >> >>> and with your changes it becomes: >>> >>> "manually enable and disable ocp interface clock and block >>> autoidle while in use". >>> >>> So aren't we now changing the way things behave in general >>> for SWSUP_IDLE? >>> >> Yes, we are, so proper testing is needed. But If I read those >> comments >> it was always intended this way but not fully implemented because it >> appeared to be more work like needing a usecounter (which my patchset >> also adds) for that autoidle flag. >> > and there are quite few hwmods marked by this flag. > And then there are those clocks marked by this flags (on am33xx) which > do not have that autoidle feature at all, so the risk is not too high. Keerthy, can you please test this series on top of the related clock patches with your am335x PM test cases? >>> >>> Can you point me to the clock series that needs to be tested >>> along with this? >>> >> >> https://patchwork.kernel.org/project/linux-clk/list/?series=66691 > > Thanks Andreas. I will test both series and get back. Tested for DS0 (deeps sleep 0 on am33/am43 boards) No issues seen with the current patch series on top of clock series. Tested-by: Keerthy > >> >> Regards, >> Andreas >>
Re: [Letux-kernel] [PATCH v3 3/3] arm: omap_hwmod disable ick autoidling when a hwmod requires that
On 1/19/2019 12:42 PM, Andreas Kemnade wrote: On Sat, 19 Jan 2019 12:09:48 +0530 "J, KEERTHY" wrote: On 1/19/2019 1:18 AM, Tony Lindgren wrote: * Andreas Kemnade [190118 19:42]: On Fri, 18 Jan 2019 20:38:47 +0100 Andreas Kemnade wrote: Hi, On Fri, 18 Jan 2019 10:36:30 -0800 Tony Lindgren wrote: [...] til the next workaround. That flags also causes the iclk being enabled/disabled manually. Yes but SWSUP_IDLE for the interface clock to me currently just means: "manually enable and disable ocp interface clock" well, if we want to manually disable it and not automatically, we have to disable autoidle or it will be automatically disabled. Disabling it manually when it is already auto-disabled (by autoidle) is just practically a no-op towards the clock. and with your changes it becomes: "manually enable and disable ocp interface clock and block autoidle while in use". So aren't we now changing the way things behave in general for SWSUP_IDLE? Yes, we are, so proper testing is needed. But If I read those comments it was always intended this way but not fully implemented because it appeared to be more work like needing a usecounter (which my patchset also adds) for that autoidle flag. and there are quite few hwmods marked by this flag. And then there are those clocks marked by this flags (on am33xx) which do not have that autoidle feature at all, so the risk is not too high. Keerthy, can you please test this series on top of the related clock patches with your am335x PM test cases? Can you point me to the clock series that needs to be tested along with this? https://patchwork.kernel.org/project/linux-clk/list/?series=66691 Thanks Andreas. I will test both series and get back. Regards, Andreas
Re: [Letux-kernel] [PATCH v3 3/3] arm: omap_hwmod disable ick autoidling when a hwmod requires that
On Sat, 19 Jan 2019 12:09:48 +0530 "J, KEERTHY" wrote: > On 1/19/2019 1:18 AM, Tony Lindgren wrote: > > * Andreas Kemnade [190118 19:42]: > >> On Fri, 18 Jan 2019 20:38:47 +0100 > >> Andreas Kemnade wrote: > >> > >>> Hi, > >>> > >>> On Fri, 18 Jan 2019 10:36:30 -0800 > >>> Tony Lindgren wrote: > >>> > >>> [...] > til the next workaround. > > > That flags also causes the iclk being enabled/disabled > > manually. > > Yes but SWSUP_IDLE for the interface clock to me currently > just means: > > "manually enable and disable ocp interface clock" > > >>> well, if we want to manually disable it and not automatically, > >>> we have to disable autoidle or it will be automatically disabled. > >>> > >>> Disabling it manually when it is already auto-disabled (by autoidle) is > >>> just practically a no-op towards the clock. > >>> > and with your changes it becomes: > > "manually enable and disable ocp interface clock and block > autoidle while in use". > > So aren't we now changing the way things behave in general > for SWSUP_IDLE? > > >>> Yes, we are, so proper testing is needed. But If I read those comments > >>> it was always intended this way but not fully implemented because it > >>> appeared to be more work like needing a usecounter (which my patchset > >>> also adds) for that autoidle flag. > >>> > >> and there are quite few hwmods marked by this flag. > >> And then there are those clocks marked by this flags (on am33xx) which > >> do not have that autoidle feature at all, so the risk is not too high. > > > > Keerthy, can you please test this series on top of the > > related clock patches with your am335x PM test cases? > > Can you point me to the clock series that needs to be tested > along with this? > https://patchwork.kernel.org/project/linux-clk/list/?series=66691 Regards, Andreas pgp4LvnaSuOLj.pgp Description: OpenPGP digital signature
Re: [Letux-kernel] [PATCH v3 3/3] arm: omap_hwmod disable ick autoidling when a hwmod requires that
On 1/19/2019 1:18 AM, Tony Lindgren wrote: * Andreas Kemnade [190118 19:42]: On Fri, 18 Jan 2019 20:38:47 +0100 Andreas Kemnade wrote: Hi, On Fri, 18 Jan 2019 10:36:30 -0800 Tony Lindgren wrote: [...] til the next workaround. That flags also causes the iclk being enabled/disabled manually. Yes but SWSUP_IDLE for the interface clock to me currently just means: "manually enable and disable ocp interface clock" well, if we want to manually disable it and not automatically, we have to disable autoidle or it will be automatically disabled. Disabling it manually when it is already auto-disabled (by autoidle) is just practically a no-op towards the clock. and with your changes it becomes: "manually enable and disable ocp interface clock and block autoidle while in use". So aren't we now changing the way things behave in general for SWSUP_IDLE? Yes, we are, so proper testing is needed. But If I read those comments it was always intended this way but not fully implemented because it appeared to be more work like needing a usecounter (which my patchset also adds) for that autoidle flag. and there are quite few hwmods marked by this flag. And then there are those clocks marked by this flags (on am33xx) which do not have that autoidle feature at all, so the risk is not too high. Keerthy, can you please test this series on top of the related clock patches with your am335x PM test cases? Can you point me to the clock series that needs to be tested along with this? - Keerthy Regards, Tony
Re: [Letux-kernel] [PATCH v3 3/3] arm: omap_hwmod disable ick autoidling when a hwmod requires that
* Andreas Kemnade [190118 19:42]: > On Fri, 18 Jan 2019 20:38:47 +0100 > Andreas Kemnade wrote: > > > Hi, > > > > On Fri, 18 Jan 2019 10:36:30 -0800 > > Tony Lindgren wrote: > > > > [...] > > > til the next workaround. > > > > > > > That flags also causes the iclk being enabled/disabled > > > > manually. > > > > > > Yes but SWSUP_IDLE for the interface clock to me currently > > > just means: > > > > > > "manually enable and disable ocp interface clock" > > > > > well, if we want to manually disable it and not automatically, > > we have to disable autoidle or it will be automatically disabled. > > > > Disabling it manually when it is already auto-disabled (by autoidle) is > > just practically a no-op towards the clock. > > > > > and with your changes it becomes: > > > > > > "manually enable and disable ocp interface clock and block > > > autoidle while in use". > > > > > > So aren't we now changing the way things behave in general > > > for SWSUP_IDLE? > > > > > Yes, we are, so proper testing is needed. But If I read those comments > > it was always intended this way but not fully implemented because it > > appeared to be more work like needing a usecounter (which my patchset > > also adds) for that autoidle flag. > > > and there are quite few hwmods marked by this flag. > And then there are those clocks marked by this flags (on am33xx) which > do not have that autoidle feature at all, so the risk is not too high. Keerthy, can you please test this series on top of the related clock patches with your am335x PM test cases? Regards, Tony
Re: [Letux-kernel] [PATCH v3 3/3] arm: omap_hwmod disable ick autoidling when a hwmod requires that
On Fri, 18 Jan 2019 20:38:47 +0100 Andreas Kemnade wrote: > Hi, > > On Fri, 18 Jan 2019 10:36:30 -0800 > Tony Lindgren wrote: > > [...] > > til the next workaround. > > > > > That flags also causes the iclk being enabled/disabled > > > manually. > > > > Yes but SWSUP_IDLE for the interface clock to me currently > > just means: > > > > "manually enable and disable ocp interface clock" > > > well, if we want to manually disable it and not automatically, > we have to disable autoidle or it will be automatically disabled. > > Disabling it manually when it is already auto-disabled (by autoidle) is > just practically a no-op towards the clock. > > > and with your changes it becomes: > > > > "manually enable and disable ocp interface clock and block > > autoidle while in use". > > > > So aren't we now changing the way things behave in general > > for SWSUP_IDLE? > > > Yes, we are, so proper testing is needed. But If I read those comments > it was always intended this way but not fully implemented because it > appeared to be more work like needing a usecounter (which my patchset > also adds) for that autoidle flag. > and there are quite few hwmods marked by this flag. And then there are those clocks marked by this flags (on am33xx) which do not have that autoidle feature at all, so the risk is not too high. Regards, Andreas pgpVazDNrVtmx.pgp Description: OpenPGP digital signature