Re: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On 25/08/15 23:46, Rafael J. Wysocki wrote: > On 8/25/2015 11:37 AM, Jon Hunter wrote: [snip] >> Vinod, thinking about this some more, I am wondering if it is just >> better to get rid of the suspend/resume callbacks and simply handling >> the state in the runtime suspend/resume callbacks. I think that would be >> safe too, because once the clock has been disabled, then who knows what >> the context state will be. > > One caveat here: system suspend may be invoked at any time, so you need > to ensure that the device is properly suspended when that happens. > > I believe you at least need a ->suspend callback for that. Thanks, makes sense. On a related note, I see a few drivers, including this DMA driver doing the following in the driver ->remove callback. pm_runtime_disable(>dev); !pm_runtime_status_suspended(>dev)) tegra_dma_runtime_suspend(>dev); I understand that the code is trying to ensure that the device is suspended regardless of whether rpm is enabled or not in the kernel config. However, looking at the pm_runtime_status_suspended() function, AFAICT, it will always return false above as the disable_depth will be greater than 0. So I am concerned that the tegra_dma_runtime_suspend() is called even when not needed? However, I could also be missing something here. Cheers Jon -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On 25/08/15 23:46, Rafael J. Wysocki wrote: On 8/25/2015 11:37 AM, Jon Hunter wrote: [snip] Vinod, thinking about this some more, I am wondering if it is just better to get rid of the suspend/resume callbacks and simply handling the state in the runtime suspend/resume callbacks. I think that would be safe too, because once the clock has been disabled, then who knows what the context state will be. One caveat here: system suspend may be invoked at any time, so you need to ensure that the device is properly suspended when that happens. I believe you at least need a -suspend callback for that. Thanks, makes sense. On a related note, I see a few drivers, including this DMA driver doing the following in the driver -remove callback. pm_runtime_disable(pdev-dev); !pm_runtime_status_suspended(pdev-dev)) tegra_dma_runtime_suspend(pdev-dev); I understand that the code is trying to ensure that the device is suspended regardless of whether rpm is enabled or not in the kernel config. However, looking at the pm_runtime_status_suspended() function, AFAICT, it will always return false above as the disable_depth will be greater than 0. So I am concerned that the tegra_dma_runtime_suspend() is called even when not needed? However, I could also be missing something here. Cheers Jon -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On 8/25/2015 11:37 AM, Jon Hunter wrote: On 25/08/15 01:04, Rafael J. Wysocki wrote: On Monday, August 24, 2015 07:51:43 PM Vinod Koul wrote: On Mon, Aug 24, 2015 at 02:22:49PM +0100, Jon Hunter wrote: On 24/08/15 10:22, Vinod Koul wrote: On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote: On 23/08/15 15:17, Vinod Koul wrote: On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev) int ret; /* Enable clock before accessing register */ - ret = tegra_dma_runtime_resume(dev); + ret = pm_runtime_get_sync(dev); why is this required ? Because the clock could be disabled when this function is called. This function saves the DMA context so that if the context is lost during suspend, it can be restored. Have you verified this? Coz my understanding is that when PM does suspend it will esnure you are runtime resume if runtime suspended and then will do suspend. So you do not need to do above I see what you are saying. I did some testing with ftrace today to trace rpm and suspend/resume calls. If the dma controller is runtime suspended and I do not call pm_runtime_get_sync() above then I do not see any runtime resume of the dma controller prior to suspend. Now I was hoping that this would cause a complete kernel crash but it did not and so the DMA clock did not appear to be needed here (at least on the one board I tested). However, I would not go as far as to remove this and prefer to keep as above. Okay am adding Rafael here for his recommendations. Well, and what is the question I'm supposed to answer, exactly? I was in Seattle last week, so haven't been following this closely. I have tested in past and if my driver was runtime suspended we were resumed prior to being suspended. So I am not sure why you did not see that behaviour, and if that is right we don't need to force resume here We're adding code for skipping runtime-resume-before-system-suspend, because it is not desirable in general. The rule of thumb is that if you know you need to change the device's settings (eg. because of wakeup being enabled or not) for system suspend and that requires the device to be resumed, resume it. It can stay suspended otherwise. Thanks Rafael. Vinod, thinking about this some more, I am wondering if it is just better to get rid of the suspend/resume callbacks and simply handling the state in the runtime suspend/resume callbacks. I think that would be safe too, because once the clock has been disabled, then who knows what the context state will be. One caveat here: system suspend may be invoked at any time, so you need to ensure that the device is properly suspended when that happens. I believe you at least need a ->suspend callback for that. Cheers, Rafael -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On 25/08/15 01:04, Rafael J. Wysocki wrote: > On Monday, August 24, 2015 07:51:43 PM Vinod Koul wrote: >> On Mon, Aug 24, 2015 at 02:22:49PM +0100, Jon Hunter wrote: >>> >>> On 24/08/15 10:22, Vinod Koul wrote: On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote: > > On 23/08/15 15:17, Vinod Koul wrote: >> On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: >> >>> @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device >>> *dev) >>> int ret; >>> >>> /* Enable clock before accessing register */ >>> - ret = tegra_dma_runtime_resume(dev); >>> + ret = pm_runtime_get_sync(dev); >> >> why is this required ? > > Because the clock could be disabled when this function is called. This > function saves the DMA context so that if the context is lost during > suspend, it can be restored. Have you verified this? Coz my understanding is that when PM does suspend it will esnure you are runtime resume if runtime suspended and then will do suspend. So you do not need to do above >>> >>> I see what you are saying. I did some testing with ftrace today to trace >>> rpm and suspend/resume calls. If the dma controller is runtime suspended >>> and I do not call pm_runtime_get_sync() above then I do not see any >>> runtime resume of the dma controller prior to suspend. Now I was hoping >>> that this would cause a complete kernel crash but it did not and so the >>> DMA clock did not appear to be needed here (at least on the one board I >>> tested). However, I would not go as far as to remove this and prefer to >>> keep as above. >> >> Okay am adding Rafael here for his recommendations. > > Well, and what is the question I'm supposed to answer, exactly? > > I was in Seattle last week, so haven't been following this closely. > >> I have tested in past and if my driver was runtime suspended we were resumed >> prior to being suspended. So I am not sure why you did not see that >> behaviour, and if that is right we don't need to force resume here > > We're adding code for skipping runtime-resume-before-system-suspend, because > it is not desirable in general. > > The rule of thumb is that if you know you need to change the device's settings > (eg. because of wakeup being enabled or not) for system suspend and that > requires the device to be resumed, resume it. It can stay suspended > otherwise. Thanks Rafael. Vinod, thinking about this some more, I am wondering if it is just better to get rid of the suspend/resume callbacks and simply handling the state in the runtime suspend/resume callbacks. I think that would be safe too, because once the clock has been disabled, then who knows what the context state will be. Cheers Jon -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On 25/08/15 01:04, Rafael J. Wysocki wrote: On Monday, August 24, 2015 07:51:43 PM Vinod Koul wrote: On Mon, Aug 24, 2015 at 02:22:49PM +0100, Jon Hunter wrote: On 24/08/15 10:22, Vinod Koul wrote: On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote: On 23/08/15 15:17, Vinod Koul wrote: On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev) int ret; /* Enable clock before accessing register */ - ret = tegra_dma_runtime_resume(dev); + ret = pm_runtime_get_sync(dev); why is this required ? Because the clock could be disabled when this function is called. This function saves the DMA context so that if the context is lost during suspend, it can be restored. Have you verified this? Coz my understanding is that when PM does suspend it will esnure you are runtime resume if runtime suspended and then will do suspend. So you do not need to do above I see what you are saying. I did some testing with ftrace today to trace rpm and suspend/resume calls. If the dma controller is runtime suspended and I do not call pm_runtime_get_sync() above then I do not see any runtime resume of the dma controller prior to suspend. Now I was hoping that this would cause a complete kernel crash but it did not and so the DMA clock did not appear to be needed here (at least on the one board I tested). However, I would not go as far as to remove this and prefer to keep as above. Okay am adding Rafael here for his recommendations. Well, and what is the question I'm supposed to answer, exactly? I was in Seattle last week, so haven't been following this closely. I have tested in past and if my driver was runtime suspended we were resumed prior to being suspended. So I am not sure why you did not see that behaviour, and if that is right we don't need to force resume here We're adding code for skipping runtime-resume-before-system-suspend, because it is not desirable in general. The rule of thumb is that if you know you need to change the device's settings (eg. because of wakeup being enabled or not) for system suspend and that requires the device to be resumed, resume it. It can stay suspended otherwise. Thanks Rafael. Vinod, thinking about this some more, I am wondering if it is just better to get rid of the suspend/resume callbacks and simply handling the state in the runtime suspend/resume callbacks. I think that would be safe too, because once the clock has been disabled, then who knows what the context state will be. Cheers Jon -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On 8/25/2015 11:37 AM, Jon Hunter wrote: On 25/08/15 01:04, Rafael J. Wysocki wrote: On Monday, August 24, 2015 07:51:43 PM Vinod Koul wrote: On Mon, Aug 24, 2015 at 02:22:49PM +0100, Jon Hunter wrote: On 24/08/15 10:22, Vinod Koul wrote: On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote: On 23/08/15 15:17, Vinod Koul wrote: On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev) int ret; /* Enable clock before accessing register */ - ret = tegra_dma_runtime_resume(dev); + ret = pm_runtime_get_sync(dev); why is this required ? Because the clock could be disabled when this function is called. This function saves the DMA context so that if the context is lost during suspend, it can be restored. Have you verified this? Coz my understanding is that when PM does suspend it will esnure you are runtime resume if runtime suspended and then will do suspend. So you do not need to do above I see what you are saying. I did some testing with ftrace today to trace rpm and suspend/resume calls. If the dma controller is runtime suspended and I do not call pm_runtime_get_sync() above then I do not see any runtime resume of the dma controller prior to suspend. Now I was hoping that this would cause a complete kernel crash but it did not and so the DMA clock did not appear to be needed here (at least on the one board I tested). However, I would not go as far as to remove this and prefer to keep as above. Okay am adding Rafael here for his recommendations. Well, and what is the question I'm supposed to answer, exactly? I was in Seattle last week, so haven't been following this closely. I have tested in past and if my driver was runtime suspended we were resumed prior to being suspended. So I am not sure why you did not see that behaviour, and if that is right we don't need to force resume here We're adding code for skipping runtime-resume-before-system-suspend, because it is not desirable in general. The rule of thumb is that if you know you need to change the device's settings (eg. because of wakeup being enabled or not) for system suspend and that requires the device to be resumed, resume it. It can stay suspended otherwise. Thanks Rafael. Vinod, thinking about this some more, I am wondering if it is just better to get rid of the suspend/resume callbacks and simply handling the state in the runtime suspend/resume callbacks. I think that would be safe too, because once the clock has been disabled, then who knows what the context state will be. One caveat here: system suspend may be invoked at any time, so you need to ensure that the device is properly suspended when that happens. I believe you at least need a -suspend callback for that. Cheers, Rafael -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On Monday, August 24, 2015 07:51:43 PM Vinod Koul wrote: > On Mon, Aug 24, 2015 at 02:22:49PM +0100, Jon Hunter wrote: > > > > On 24/08/15 10:22, Vinod Koul wrote: > > > On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote: > > >> > > >> On 23/08/15 15:17, Vinod Koul wrote: > > >>> On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: > > >>> > > @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device > > *dev) > > int ret; > > > > /* Enable clock before accessing register */ > > - ret = tegra_dma_runtime_resume(dev); > > + ret = pm_runtime_get_sync(dev); > > >>> > > >>> why is this required ? > > >> > > >> Because the clock could be disabled when this function is called. This > > >> function saves the DMA context so that if the context is lost during > > >> suspend, it can be restored. > > > > > > Have you verified this? Coz my understanding is that when PM does suspend > > > it > > > will esnure you are runtime resume if runtime suspended and then will do > > > suspend. > > > So you do not need to do above > > > > I see what you are saying. I did some testing with ftrace today to trace > > rpm and suspend/resume calls. If the dma controller is runtime suspended > > and I do not call pm_runtime_get_sync() above then I do not see any > > runtime resume of the dma controller prior to suspend. Now I was hoping > > that this would cause a complete kernel crash but it did not and so the > > DMA clock did not appear to be needed here (at least on the one board I > > tested). However, I would not go as far as to remove this and prefer to > > keep as above. > > Okay am adding Rafael here for his recommendations. Well, and what is the question I'm supposed to answer, exactly? I was in Seattle last week, so haven't been following this closely. > I have tested in past and if my driver was runtime suspended we were resumed > prior to being suspended. So I am not sure why you did not see that > behaviour, and if that is right we don't need to force resume here We're adding code for skipping runtime-resume-before-system-suspend, because it is not desirable in general. The rule of thumb is that if you know you need to change the device's settings (eg. because of wakeup being enabled or not) for system suspend and that requires the device to be resumed, resume it. It can stay suspended otherwise. Thanks, Rafael -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On Mon, Aug 24, 2015 at 02:22:49PM +0100, Jon Hunter wrote: > > On 24/08/15 10:22, Vinod Koul wrote: > > On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote: > >> > >> On 23/08/15 15:17, Vinod Koul wrote: > >>> On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: > >>> > @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev) > int ret; > > /* Enable clock before accessing register */ > -ret = tegra_dma_runtime_resume(dev); > +ret = pm_runtime_get_sync(dev); > >>> > >>> why is this required ? > >> > >> Because the clock could be disabled when this function is called. This > >> function saves the DMA context so that if the context is lost during > >> suspend, it can be restored. > > > > Have you verified this? Coz my understanding is that when PM does suspend it > > will esnure you are runtime resume if runtime suspended and then will do > > suspend. > > So you do not need to do above > > I see what you are saying. I did some testing with ftrace today to trace > rpm and suspend/resume calls. If the dma controller is runtime suspended > and I do not call pm_runtime_get_sync() above then I do not see any > runtime resume of the dma controller prior to suspend. Now I was hoping > that this would cause a complete kernel crash but it did not and so the > DMA clock did not appear to be needed here (at least on the one board I > tested). However, I would not go as far as to remove this and prefer to > keep as above. Okay am adding Rafael here for his recommendations. I have tested in past and if my driver was runtime suspended we were resumed prior to being suspended. So I am not sure why you did not see that behaviour, and if that is right we don't need to force resume here -- ~Vinod -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On 24/08/15 10:22, Vinod Koul wrote: > On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote: >> >> On 23/08/15 15:17, Vinod Koul wrote: >>> On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: >>> @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev) int ret; /* Enable clock before accessing register */ - ret = tegra_dma_runtime_resume(dev); + ret = pm_runtime_get_sync(dev); >>> >>> why is this required ? >> >> Because the clock could be disabled when this function is called. This >> function saves the DMA context so that if the context is lost during >> suspend, it can be restored. > > Have you verified this? Coz my understanding is that when PM does suspend it > will esnure you are runtime resume if runtime suspended and then will do > suspend. > So you do not need to do above I see what you are saying. I did some testing with ftrace today to trace rpm and suspend/resume calls. If the dma controller is runtime suspended and I do not call pm_runtime_get_sync() above then I do not see any runtime resume of the dma controller prior to suspend. Now I was hoping that this would cause a complete kernel crash but it did not and so the DMA clock did not appear to be needed here (at least on the one board I tested). However, I would not go as far as to remove this and prefer to keep as above. Furthermore, other drivers do similar things, including the sirf dma controller (see sirf-dma.c). Cheers Jon -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote: > > On 23/08/15 15:17, Vinod Koul wrote: > > On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: > > > >> @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev) > >>int ret; > >> > >>/* Enable clock before accessing register */ > >> - ret = tegra_dma_runtime_resume(dev); > >> + ret = pm_runtime_get_sync(dev); > > > > why is this required ? > > Because the clock could be disabled when this function is called. This > function saves the DMA context so that if the context is lost during > suspend, it can be restored. Have you verified this? Coz my understanding is that when PM does suspend it will esnure you are runtime resume if runtime suspended and then will do suspend. So you do not need to do above -- ~Vinod -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On 23/08/15 15:17, Vinod Koul wrote: > On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: > >> @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev) >> int ret; >> >> /* Enable clock before accessing register */ >> -ret = tegra_dma_runtime_resume(dev); >> +ret = pm_runtime_get_sync(dev); > > why is this required ? Because the clock could be disabled when this function is called. This function saves the DMA context so that if the context is lost during suspend, it can be restored. Cheers Jon -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On 24/08/15 10:22, Vinod Koul wrote: On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote: On 23/08/15 15:17, Vinod Koul wrote: On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev) int ret; /* Enable clock before accessing register */ - ret = tegra_dma_runtime_resume(dev); + ret = pm_runtime_get_sync(dev); why is this required ? Because the clock could be disabled when this function is called. This function saves the DMA context so that if the context is lost during suspend, it can be restored. Have you verified this? Coz my understanding is that when PM does suspend it will esnure you are runtime resume if runtime suspended and then will do suspend. So you do not need to do above I see what you are saying. I did some testing with ftrace today to trace rpm and suspend/resume calls. If the dma controller is runtime suspended and I do not call pm_runtime_get_sync() above then I do not see any runtime resume of the dma controller prior to suspend. Now I was hoping that this would cause a complete kernel crash but it did not and so the DMA clock did not appear to be needed here (at least on the one board I tested). However, I would not go as far as to remove this and prefer to keep as above. Furthermore, other drivers do similar things, including the sirf dma controller (see sirf-dma.c). Cheers Jon -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On Mon, Aug 24, 2015 at 02:22:49PM +0100, Jon Hunter wrote: On 24/08/15 10:22, Vinod Koul wrote: On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote: On 23/08/15 15:17, Vinod Koul wrote: On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev) int ret; /* Enable clock before accessing register */ -ret = tegra_dma_runtime_resume(dev); +ret = pm_runtime_get_sync(dev); why is this required ? Because the clock could be disabled when this function is called. This function saves the DMA context so that if the context is lost during suspend, it can be restored. Have you verified this? Coz my understanding is that when PM does suspend it will esnure you are runtime resume if runtime suspended and then will do suspend. So you do not need to do above I see what you are saying. I did some testing with ftrace today to trace rpm and suspend/resume calls. If the dma controller is runtime suspended and I do not call pm_runtime_get_sync() above then I do not see any runtime resume of the dma controller prior to suspend. Now I was hoping that this would cause a complete kernel crash but it did not and so the DMA clock did not appear to be needed here (at least on the one board I tested). However, I would not go as far as to remove this and prefer to keep as above. Okay am adding Rafael here for his recommendations. I have tested in past and if my driver was runtime suspended we were resumed prior to being suspended. So I am not sure why you did not see that behaviour, and if that is right we don't need to force resume here -- ~Vinod -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On 23/08/15 15:17, Vinod Koul wrote: On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev) int ret; /* Enable clock before accessing register */ -ret = tegra_dma_runtime_resume(dev); +ret = pm_runtime_get_sync(dev); why is this required ? Because the clock could be disabled when this function is called. This function saves the DMA context so that if the context is lost during suspend, it can be restored. Cheers Jon -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote: On 23/08/15 15:17, Vinod Koul wrote: On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev) int ret; /* Enable clock before accessing register */ - ret = tegra_dma_runtime_resume(dev); + ret = pm_runtime_get_sync(dev); why is this required ? Because the clock could be disabled when this function is called. This function saves the DMA context so that if the context is lost during suspend, it can be restored. Have you verified this? Coz my understanding is that when PM does suspend it will esnure you are runtime resume if runtime suspended and then will do suspend. So you do not need to do above -- ~Vinod -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On Monday, August 24, 2015 07:51:43 PM Vinod Koul wrote: On Mon, Aug 24, 2015 at 02:22:49PM +0100, Jon Hunter wrote: On 24/08/15 10:22, Vinod Koul wrote: On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote: On 23/08/15 15:17, Vinod Koul wrote: On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev) int ret; /* Enable clock before accessing register */ - ret = tegra_dma_runtime_resume(dev); + ret = pm_runtime_get_sync(dev); why is this required ? Because the clock could be disabled when this function is called. This function saves the DMA context so that if the context is lost during suspend, it can be restored. Have you verified this? Coz my understanding is that when PM does suspend it will esnure you are runtime resume if runtime suspended and then will do suspend. So you do not need to do above I see what you are saying. I did some testing with ftrace today to trace rpm and suspend/resume calls. If the dma controller is runtime suspended and I do not call pm_runtime_get_sync() above then I do not see any runtime resume of the dma controller prior to suspend. Now I was hoping that this would cause a complete kernel crash but it did not and so the DMA clock did not appear to be needed here (at least on the one board I tested). However, I would not go as far as to remove this and prefer to keep as above. Okay am adding Rafael here for his recommendations. Well, and what is the question I'm supposed to answer, exactly? I was in Seattle last week, so haven't been following this closely. I have tested in past and if my driver was runtime suspended we were resumed prior to being suspended. So I am not sure why you did not see that behaviour, and if that is right we don't need to force resume here We're adding code for skipping runtime-resume-before-system-suspend, because it is not desirable in general. The rule of thumb is that if you know you need to change the device's settings (eg. because of wakeup being enabled or not) for system suspend and that requires the device to be resumed, resume it. It can stay suspended otherwise. Thanks, Rafael -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: > @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev) > int ret; > > /* Enable clock before accessing register */ > - ret = tegra_dma_runtime_resume(dev); > + ret = pm_runtime_get_sync(dev); why is this required ? -- ~Vinod -- 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: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev) int ret; /* Enable clock before accessing register */ - ret = tegra_dma_runtime_resume(dev); + ret = pm_runtime_get_sync(dev); why is this required ? -- ~Vinod -- 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/
[RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
The tegra-apb DMA driver enables runtime-pm but never calls
pm_runtime_get/put and hence the runtime-pm callbacks are never invoked.
The driver manages the clocks by directly calling clk_prepare_enable()
and clk_unprepare_disable().
Fix this by replacing the clk_prepare_enable() and clk_disable_unprepare()
with pm_runtime_get_sync() and pm_runtime_put(), respectively. Note that
the consequence of this is that if runtime-pm is disabled, then the clocks
will remain on the entire time the driver is loaded. However, if
runtime-pm is disabled, then power is not most likely not a concern.
Signed-off-by: Jon Hunter
---
drivers/dma/tegra20-apb-dma.c | 36
1 file changed, 12 insertions(+), 24 deletions(-)
diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index c8f79dcaaee8..097432ea89fa 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -1182,14 +1182,11 @@ static int tegra_dma_alloc_chan_resources(struct
dma_chan *dc)
{
struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
struct tegra_dma *tdma = tdc->tdma;
- int ret;
dma_cookie_init(>dma_chan);
tdc->config_init = false;
- ret = clk_prepare_enable(tdma->dma_clk);
- if (ret < 0)
- dev_err(tdc2dev(tdc), "clk_prepare_enable failed: %d\n", ret);
- return ret;
+
+ return pm_runtime_get_sync(tdma->dev);
}
static void tegra_dma_free_chan_resources(struct dma_chan *dc)
@@ -1232,7 +1229,7 @@ static void tegra_dma_free_chan_resources(struct dma_chan
*dc)
list_del(_req->node);
kfree(sg_req);
}
- clk_disable_unprepare(tdma->dma_clk);
+ pm_runtime_put(tdma->dev);
tdc->slave_id = 0;
}
@@ -1356,21 +1353,13 @@ static int tegra_dma_probe(struct platform_device *pdev)
spin_lock_init(>global_lock);
pm_runtime_enable(>dev);
- if (!pm_runtime_enabled(>dev)) {
+ if (!pm_runtime_enabled(>dev))
ret = tegra_dma_runtime_resume(>dev);
- if (ret) {
- dev_err(>dev, "dma_runtime_resume failed %d\n",
- ret);
- goto err_pm_disable;
- }
- }
+ else
+ ret = pm_runtime_get_sync(>dev);
- /* Enable clock before accessing registers */
- ret = clk_prepare_enable(tdma->dma_clk);
- if (ret < 0) {
- dev_err(>dev, "clk_prepare_enable failed: %d\n", ret);
+ if (ret)
goto err_pm_disable;
- }
/* Reset DMA controller */
reset_control_assert(tdma->rst);
@@ -1382,7 +1371,7 @@ static int tegra_dma_probe(struct platform_device *pdev)
tdma_write(tdma, TEGRA_APBDMA_CONTROL, 0);
tdma_write(tdma, TEGRA_APBDMA_IRQ_MASK_SET, 0xul);
- clk_disable_unprepare(tdma->dma_clk);
+ pm_runtime_put(>dev);
INIT_LIST_HEAD(>dma_dev.channels);
for (i = 0; i < cdata->nr_channels; i++) {
@@ -1484,7 +1473,6 @@ err_irq:
struct tegra_dma_channel *tdc = >channels[i];
tasklet_kill(>tasklet);
}
-
err_pm_disable:
pm_runtime_disable(>dev);
if (!pm_runtime_status_suspended(>dev))
@@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev)
int ret;
/* Enable clock before accessing register */
- ret = tegra_dma_runtime_resume(dev);
+ ret = pm_runtime_get_sync(dev);
if (ret < 0)
return ret;
@@ -1560,7 +1548,7 @@ static int tegra_dma_pm_suspend(struct device *dev)
}
/* Disable clock */
- tegra_dma_runtime_suspend(dev);
+ pm_runtime_put(dev);
return 0;
}
@@ -1571,7 +1559,7 @@ static int tegra_dma_pm_resume(struct device *dev)
int ret;
/* Enable clock before accessing register */
- ret = tegra_dma_runtime_resume(dev);
+ ret = pm_runtime_get_sync(dev);
if (ret < 0)
return ret;
@@ -1592,7 +1580,7 @@ static int tegra_dma_pm_resume(struct device *dev)
}
/* Disable clock */
- tegra_dma_runtime_suspend(dev);
+ pm_runtime_put(dev);
return 0;
}
#endif
--
2.1.4
--
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/
[RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
The tegra-apb DMA driver enables runtime-pm but never calls
pm_runtime_get/put and hence the runtime-pm callbacks are never invoked.
The driver manages the clocks by directly calling clk_prepare_enable()
and clk_unprepare_disable().
Fix this by replacing the clk_prepare_enable() and clk_disable_unprepare()
with pm_runtime_get_sync() and pm_runtime_put(), respectively. Note that
the consequence of this is that if runtime-pm is disabled, then the clocks
will remain on the entire time the driver is loaded. However, if
runtime-pm is disabled, then power is not most likely not a concern.
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
drivers/dma/tegra20-apb-dma.c | 36
1 file changed, 12 insertions(+), 24 deletions(-)
diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index c8f79dcaaee8..097432ea89fa 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -1182,14 +1182,11 @@ static int tegra_dma_alloc_chan_resources(struct
dma_chan *dc)
{
struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
struct tegra_dma *tdma = tdc-tdma;
- int ret;
dma_cookie_init(tdc-dma_chan);
tdc-config_init = false;
- ret = clk_prepare_enable(tdma-dma_clk);
- if (ret 0)
- dev_err(tdc2dev(tdc), clk_prepare_enable failed: %d\n, ret);
- return ret;
+
+ return pm_runtime_get_sync(tdma-dev);
}
static void tegra_dma_free_chan_resources(struct dma_chan *dc)
@@ -1232,7 +1229,7 @@ static void tegra_dma_free_chan_resources(struct dma_chan
*dc)
list_del(sg_req-node);
kfree(sg_req);
}
- clk_disable_unprepare(tdma-dma_clk);
+ pm_runtime_put(tdma-dev);
tdc-slave_id = 0;
}
@@ -1356,21 +1353,13 @@ static int tegra_dma_probe(struct platform_device *pdev)
spin_lock_init(tdma-global_lock);
pm_runtime_enable(pdev-dev);
- if (!pm_runtime_enabled(pdev-dev)) {
+ if (!pm_runtime_enabled(pdev-dev))
ret = tegra_dma_runtime_resume(pdev-dev);
- if (ret) {
- dev_err(pdev-dev, dma_runtime_resume failed %d\n,
- ret);
- goto err_pm_disable;
- }
- }
+ else
+ ret = pm_runtime_get_sync(pdev-dev);
- /* Enable clock before accessing registers */
- ret = clk_prepare_enable(tdma-dma_clk);
- if (ret 0) {
- dev_err(pdev-dev, clk_prepare_enable failed: %d\n, ret);
+ if (ret)
goto err_pm_disable;
- }
/* Reset DMA controller */
reset_control_assert(tdma-rst);
@@ -1382,7 +1371,7 @@ static int tegra_dma_probe(struct platform_device *pdev)
tdma_write(tdma, TEGRA_APBDMA_CONTROL, 0);
tdma_write(tdma, TEGRA_APBDMA_IRQ_MASK_SET, 0xul);
- clk_disable_unprepare(tdma-dma_clk);
+ pm_runtime_put(pdev-dev);
INIT_LIST_HEAD(tdma-dma_dev.channels);
for (i = 0; i cdata-nr_channels; i++) {
@@ -1484,7 +1473,6 @@ err_irq:
struct tegra_dma_channel *tdc = tdma-channels[i];
tasklet_kill(tdc-tasklet);
}
-
err_pm_disable:
pm_runtime_disable(pdev-dev);
if (!pm_runtime_status_suspended(pdev-dev))
@@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev)
int ret;
/* Enable clock before accessing register */
- ret = tegra_dma_runtime_resume(dev);
+ ret = pm_runtime_get_sync(dev);
if (ret 0)
return ret;
@@ -1560,7 +1548,7 @@ static int tegra_dma_pm_suspend(struct device *dev)
}
/* Disable clock */
- tegra_dma_runtime_suspend(dev);
+ pm_runtime_put(dev);
return 0;
}
@@ -1571,7 +1559,7 @@ static int tegra_dma_pm_resume(struct device *dev)
int ret;
/* Enable clock before accessing register */
- ret = tegra_dma_runtime_resume(dev);
+ ret = pm_runtime_get_sync(dev);
if (ret 0)
return ret;
@@ -1592,7 +1580,7 @@ static int tegra_dma_pm_resume(struct device *dev)
}
/* Disable clock */
- tegra_dma_runtime_suspend(dev);
+ pm_runtime_put(dev);
return 0;
}
#endif
--
2.1.4
--
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/
