Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
Was there ever a conclussion to this discussion? I'm assuming this is unlikely to be fixed in 3.5? Cheers, Joe -Original Message- From: Jean Pihet jean.pi...@newoldbits.com To: Paul Walmsley p...@pwsan.com, Tomi Valkeinen tomi.valkei...@ti.com Cc: Joe Woodward j...@terrafix.co.uk, khil...@ti.com, Archit Taneja a0393...@ti.com, linux-omap@vger.kernel.org Date: Fri, 25 May 2012 14:55:27 +0200 Subject: Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5) Hi Tomi, Paul! On Fri, May 25, 2012 at 10:24 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2012-05-24 at 18:39 -0600, Paul Walmsley wrote: cc Jean Hello Tomi, On Wed, 16 May 2012, Tomi Valkeinen wrote: I also suspect that this could be just a plain DSS bug. The default FIFO low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the FIFO when there are 960 or less bytes in the fifo, and stops at 1023. The fifo is 1024 bytes). The values are calculated with fifo_size - burst_size and fifo_size - 1. We are now using FIFO merge features, which combines multiple fifos into one when possible, making the fifo size 1024*3 = 3072. Using the same low threshold and increasing the high threshold to 960/3071 works fine. Changing the high threshold to 3008 causes underflows. Increasing the low threshold to ~1600 makes DSS work again. Just a few thoughts. In terms of the high threshold, it seems really strange to me that changing the high threshold would make such a difference. Naïvely, I'd assume that you'd want to set it as high as possible? I suppose in cases where the interconnect is congested, setting it lower might allow lower latency for other interconnect users, but I'd hope we don't have to worry much about that. So it doesn't seem to me that there would be any advantage to setting it lower than the maximum. It's true that the high threshold should be set as high as possible, and this is what we do. Except for DSI command mode output on OMAP3, where, for unknown reason, the highest value (fifosize - 1) doesn't work and we need to program it to fifosize - burstsize. And this was causing the original problem, fifosize - burstsize was not working for other outputs properly. I guess this also hints that there's something wrong with omap3 and the dss fifo thresholds. Probably the low threshold is the more important parameter, from a PM perspective. If you know the FIFO's drain rate and the low threshold, it should be possible to calculate the maximum latency that the FIFO can tolerate to avoid an underflow. This could be used to specify a device PM QoS constraint to prevent the interconnect latency from exceeding that value. Yes, this is how the low threshold should be adjusted. I have never tried to calculate the threshold need, though, as I haven't had all the information and understanding to properly calculate it. I'd guess the calculations would be something like this -- (I hope you can correct my relative ignorance of the DSS in the following estimates): Looking at mach-omap2/board-rx51-video.c, let's suppose that the FIFO drain rate would be 864 x 480 x 32 bits/second. Since the FIFO width is 32 bits, that's I think the DSS fifo entries are 8 bit on omap2/3, 128bits on omap4. At least those are the units used with fifo size, threshold sizes, burst size, etc. 864 x 480 = 414 780 FIFO entries/second, or (1 000 000 µs/s / 414 780 FIFO entries/s) = ~2.411 µs/FIFO entry. So if you need a low FIFO threshold at 960 entries, you could call the device PM QoS functions to set a wakeup latency constraint for the interconnect would be nothing greater than this: (2.411 µs/FIFO entry * 960 FIFO entries) = 2 314.96 µs (The reality is that it would need to be something less than this, to account for the time needed for the GFX DMA transfer to start supplying data, etc.) Makes sense. Another reason for underflows we have is the different rotation engines. VRFB on omap2/3, and TILER on omap4. Both increase the work needed to get pixels, although I'm not sure what the actual causes for the increased work are. The ultimate goal, with Jean's device PM QoS patches, is that these constraints could change the DPLL autoidle settings or powerdomain states to ensure the constraint was met. He's got a page here: Indeed! The core code is ready and the OMAP power domains code is under review for the moment. The ultimate goal is to split the overall latency of a device into the contributors (SW, HW SoC, HW external etc.), so the DPLL relock time would be taken into account. However without the submitted code in place there is no way to build the feature in incremental steps. http://omappedia.org/wiki/Power_Management_Device_Latencies_Measurement In the wiki page there is a link to the ELC/Fosdem
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Tue, 2012-06-12 at 11:15 +0100, Joe Woodward wrote: Was there ever a conclussion to this discussion? I'm assuming this is unlikely to be fixed in 3.5? If by conclusion you mean full understanding and a proper fix, then no. But the patch 3568f2a46f2a73bab18c914df06afd98a97e0e0e (OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays) has been merged, and that should circumvent the problem. Are you still seeing problems? Tomi signature.asc Description: This is a digitally signed message part
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
-Original Message- From: Tomi Valkeinen tomi.valkei...@ti.com To: Joe Woodward j...@terrafix.co.uk Cc: Jean Pihet jean.pi...@newoldbits.com, Paul Walmsley p...@pwsan.com, khil...@ti.com, Archit Taneja a0393...@ti.com, linux- o...@vger.kernel.org Date: Tue, 12 Jun 2012 13:37:04 +0300 Subject: Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5) On Tue, 2012-06-12 at 11:15 +0100, Joe Woodward wrote: Was there ever a conclussion to this discussion? I'm assuming this is unlikely to be fixed in 3.5? If by conclusion you mean full understanding and a proper fix, then no. But the patch 3568f2a46f2a73bab18c914df06afd98a97e0e0e (OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays) has been merged, and that should circumvent the problem. Are you still seeing problems? I haven't tested any kernels since 3.4, I normally wait till a later rc and had missed that patch... If I have any problems I'll report them, but assume it's fixed otherwise. Thanks for all the work on getting round this! Cheers, Joe Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Tue, 2012-06-12 at 11:50 +0100, Joe Woodward wrote: -Original Message- From: Tomi Valkeinen tomi.valkei...@ti.com To: Joe Woodward j...@terrafix.co.uk Cc: Jean Pihet jean.pi...@newoldbits.com, Paul Walmsley p...@pwsan.com, khil...@ti.com, Archit Taneja a0393...@ti.com, linux- o...@vger.kernel.org Date: Tue, 12 Jun 2012 13:37:04 +0300 Subject: Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5) On Tue, 2012-06-12 at 11:15 +0100, Joe Woodward wrote: Was there ever a conclussion to this discussion? I'm assuming this is unlikely to be fixed in 3.5? If by conclusion you mean full understanding and a proper fix, then no. But the patch 3568f2a46f2a73bab18c914df06afd98a97e0e0e (OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays) has been merged, and that should circumvent the problem. Are you still seeing problems? I haven't tested any kernels since 3.4, I normally wait till a later rc and had missed that patch... If I have any problems I'll report them, but assume it's fixed otherwise. If the problem is visible on plain 3.4 series (i.e. without any extras, like PM patch series or such), and the commit fixes the problem, perhaps I should the patch for 3.4 stable series? The commit applies cleanly to v3.4.2. Tomi signature.asc Description: This is a digitally signed message part
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Thu, 2012-05-24 at 18:39 -0600, Paul Walmsley wrote: cc Jean Hello Tomi, On Wed, 16 May 2012, Tomi Valkeinen wrote: I also suspect that this could be just a plain DSS bug. The default FIFO low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the FIFO when there are 960 or less bytes in the fifo, and stops at 1023. The fifo is 1024 bytes). The values are calculated with fifo_size - burst_size and fifo_size - 1. We are now using FIFO merge features, which combines multiple fifos into one when possible, making the fifo size 1024*3 = 3072. Using the same low threshold and increasing the high threshold to 960/3071 works fine. Changing the high threshold to 3008 causes underflows. Increasing the low threshold to ~1600 makes DSS work again. Just a few thoughts. In terms of the high threshold, it seems really strange to me that changing the high threshold would make such a difference. Naïvely, I'd assume that you'd want to set it as high as possible? I suppose in cases where the interconnect is congested, setting it lower might allow lower latency for other interconnect users, but I'd hope we don't have to worry much about that. So it doesn't seem to me that there would be any advantage to setting it lower than the maximum. It's true that the high threshold should be set as high as possible, and this is what we do. Except for DSI command mode output on OMAP3, where, for unknown reason, the highest value (fifosize - 1) doesn't work and we need to program it to fifosize - burstsize. And this was causing the original problem, fifosize - burstsize was not working for other outputs properly. I guess this also hints that there's something wrong with omap3 and the dss fifo thresholds. Probably the low threshold is the more important parameter, from a PM perspective. If you know the FIFO's drain rate and the low threshold, it should be possible to calculate the maximum latency that the FIFO can tolerate to avoid an underflow. This could be used to specify a device PM QoS constraint to prevent the interconnect latency from exceeding that value. Yes, this is how the low threshold should be adjusted. I have never tried to calculate the threshold need, though, as I haven't had all the information and understanding to properly calculate it. I'd guess the calculations would be something like this -- (I hope you can correct my relative ignorance of the DSS in the following estimates): Looking at mach-omap2/board-rx51-video.c, let's suppose that the FIFO drain rate would be 864 x 480 x 32 bits/second. Since the FIFO width is 32 bits, that's I think the DSS fifo entries are 8 bit on omap2/3, 128bits on omap4. At least those are the units used with fifo size, threshold sizes, burst size, etc. 864 x 480 = 414 780 FIFO entries/second, or (1 000 000 µs/s / 414 780 FIFO entries/s) = ~2.411 µs/FIFO entry. So if you need a low FIFO threshold at 960 entries, you could call the device PM QoS functions to set a wakeup latency constraint for the interconnect would be nothing greater than this: (2.411 µs/FIFO entry * 960 FIFO entries) = 2 314.96 µs (The reality is that it would need to be something less than this, to account for the time needed for the GFX DMA transfer to start supplying data, etc.) Makes sense. Another reason for underflows we have is the different rotation engines. VRFB on omap2/3, and TILER on omap4. Both increase the work needed to get pixels, although I'm not sure what the actual causes for the increased work are. The ultimate goal, with Jean's device PM QoS patches, is that these constraints could change the DPLL autoidle settings or powerdomain states to ensure the constraint was met. He's got a page here: http://omappedia.org/wiki/Power_Management_Device_Latencies_Measurement (Unfortunately it's not clear what the DPLL autoidle modes and voltage scaling bits are set to for many of the estimates, and we also know that there are many software optimizations possible for our idle path.) We're still working on getting the OMAP device PM QoS patches merged, but the Linux core support is there, so you should be able to patch your drivers to use them -- see for example dev_pm_qos_add_request(). Thanks for the pointers, I need to study that. Just paging through the DSS TRM section, some other settings that might be worth checking are: - is DISPC_GFX_ATTRIBUTES.GFXBURSTSIZE set to 16x32? Yes. (8 x 128 on omap4) I presume each DMA burst has a small overhead, so maximizing the burst size minimizes the overhead. Do you see any other effect with the burst size? I mean, do you see any need to know the burst size value when trying to calculate optimal thresholds? - is DISPC_GFX_ATTRIBUTES.GFXFIFOPRELOAD set to 1? No. We set it to 0 so that PRELOAD is used. If I've understood right, the problem with using GFXFIFOPRELOAD=1, i.e. high threshold is used for preload
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
Hi Tomi, Paul! On Fri, May 25, 2012 at 10:24 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2012-05-24 at 18:39 -0600, Paul Walmsley wrote: cc Jean Hello Tomi, On Wed, 16 May 2012, Tomi Valkeinen wrote: I also suspect that this could be just a plain DSS bug. The default FIFO low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the FIFO when there are 960 or less bytes in the fifo, and stops at 1023. The fifo is 1024 bytes). The values are calculated with fifo_size - burst_size and fifo_size - 1. We are now using FIFO merge features, which combines multiple fifos into one when possible, making the fifo size 1024*3 = 3072. Using the same low threshold and increasing the high threshold to 960/3071 works fine. Changing the high threshold to 3008 causes underflows. Increasing the low threshold to ~1600 makes DSS work again. Just a few thoughts. In terms of the high threshold, it seems really strange to me that changing the high threshold would make such a difference. Naïvely, I'd assume that you'd want to set it as high as possible? I suppose in cases where the interconnect is congested, setting it lower might allow lower latency for other interconnect users, but I'd hope we don't have to worry much about that. So it doesn't seem to me that there would be any advantage to setting it lower than the maximum. It's true that the high threshold should be set as high as possible, and this is what we do. Except for DSI command mode output on OMAP3, where, for unknown reason, the highest value (fifosize - 1) doesn't work and we need to program it to fifosize - burstsize. And this was causing the original problem, fifosize - burstsize was not working for other outputs properly. I guess this also hints that there's something wrong with omap3 and the dss fifo thresholds. Probably the low threshold is the more important parameter, from a PM perspective. If you know the FIFO's drain rate and the low threshold, it should be possible to calculate the maximum latency that the FIFO can tolerate to avoid an underflow. This could be used to specify a device PM QoS constraint to prevent the interconnect latency from exceeding that value. Yes, this is how the low threshold should be adjusted. I have never tried to calculate the threshold need, though, as I haven't had all the information and understanding to properly calculate it. I'd guess the calculations would be something like this -- (I hope you can correct my relative ignorance of the DSS in the following estimates): Looking at mach-omap2/board-rx51-video.c, let's suppose that the FIFO drain rate would be 864 x 480 x 32 bits/second. Since the FIFO width is 32 bits, that's I think the DSS fifo entries are 8 bit on omap2/3, 128bits on omap4. At least those are the units used with fifo size, threshold sizes, burst size, etc. 864 x 480 = 414 780 FIFO entries/second, or (1 000 000 µs/s / 414 780 FIFO entries/s) = ~2.411 µs/FIFO entry. So if you need a low FIFO threshold at 960 entries, you could call the device PM QoS functions to set a wakeup latency constraint for the interconnect would be nothing greater than this: (2.411 µs/FIFO entry * 960 FIFO entries) = 2 314.96 µs (The reality is that it would need to be something less than this, to account for the time needed for the GFX DMA transfer to start supplying data, etc.) Makes sense. Another reason for underflows we have is the different rotation engines. VRFB on omap2/3, and TILER on omap4. Both increase the work needed to get pixels, although I'm not sure what the actual causes for the increased work are. The ultimate goal, with Jean's device PM QoS patches, is that these constraints could change the DPLL autoidle settings or powerdomain states to ensure the constraint was met. He's got a page here: Indeed! The core code is ready and the OMAP power domains code is under review for the moment. The ultimate goal is to split the overall latency of a device into the contributors (SW, HW SoC, HW external etc.), so the DPLL relock time would be taken into account. However without the submitted code in place there is no way to build the feature in incremental steps. http://omappedia.org/wiki/Power_Management_Device_Latencies_Measurement In the wiki page there is a link to the ELC/Fosdem presentation [1] about the new model for the latency. [1] http://omappedia.org/wiki/File:ELC-2012-jpihet-DeviceLatencyModel.pdf (Unfortunately it's not clear what the DPLL autoidle modes and voltage scaling bits are set to for many of the estimates, and we also know that The code is from an l-o tree + the measurement code in, so the DPLL are allowed to auto-idle. In the new model the DPLL relock latency contribution should be split from the power domains latency. there are many software optimizations possible for our idle path.) Sure! Recently we have had the case with the C1 cpuidle state. Hopefully some
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Wed, 2012-05-16 at 12:09 +0200, Cousson, Benoit wrote: Hi Tomi, On 5/16/2012 11:08 AM, Tomi Valkeinen wrote: Disabling DPLL3 autoidle fixes the problem. Disabling DPLL4 autoidle doesn't affect the problem. The issues your are facing seems to be the well known DSS low power refresh mode we've been trying to use since OMAP2 :-). Hmm, so are you saying no one has managed to get fifomerge and autoidle working reliably? If so, no point for me to even try it =). If so, I wonder which is better to have: fifomerge or autoidle... I also suspect that this could be just a plain DSS bug. The default FIFO low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the FIFO when there are 960 or less bytes in the fifo, and stops at 1023. The fifo is 1024 bytes). The values are calculated with fifo_size - burst_size and fifo_size - 1. We are now using FIFO merge features, which combines multiple fifos into one when possible, making the fifo size 1024*3 = 3072. Using the same low threshold and increasing the high threshold to 960/3071 works fine. Changing the high threshold to 3008 causes underflows. Increasing the low threshold to ~1600 makes DSS work again. That's weird, in theory what should matter is only the diff between the high and low. Well the low value should be as high as possible as well to support the wakeup latency. Yep. That makes me think there's some kind of problem with DSS accessing the memory with particular fifo thresholds. Tomi signature.asc Description: This is a digitally signed message part
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Wed, 16 May 2012, Tomi Valkeinen wrote: JFYI, I also tested changing DISPC's SYSCONFIG:CLOCKACTIVITY, which, to me, sounds a bit related to dpll autoidle. By default it's 0, interface and functional clocks can be switched off. I tested the three other values, but none of them had any effect. As I understand it (which could very well be mistaken), the CLOCKACTIVITY bits are only useful in situations where we'd like to allow the interconnect to idle, but keep the functional clock of the IP block (or subsystem) running. Right now, we control an IP block's interface clock and functional clock together, so CLOCKACTIVITY should probably always be 0. But for drivers that want to do more fine-grained clock control, or if we create some notion of an autonomous IP block in our integration layer for devices that can function without its interconnect, it might be worth exploring whether it is worthwhile to change those bits. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
cc Jean Hello Tomi, On Wed, 16 May 2012, Tomi Valkeinen wrote: I also suspect that this could be just a plain DSS bug. The default FIFO low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the FIFO when there are 960 or less bytes in the fifo, and stops at 1023. The fifo is 1024 bytes). The values are calculated with fifo_size - burst_size and fifo_size - 1. We are now using FIFO merge features, which combines multiple fifos into one when possible, making the fifo size 1024*3 = 3072. Using the same low threshold and increasing the high threshold to 960/3071 works fine. Changing the high threshold to 3008 causes underflows. Increasing the low threshold to ~1600 makes DSS work again. Just a few thoughts. In terms of the high threshold, it seems really strange to me that changing the high threshold would make such a difference. Naïvely, I'd assume that you'd want to set it as high as possible? I suppose in cases where the interconnect is congested, setting it lower might allow lower latency for other interconnect users, but I'd hope we don't have to worry much about that. So it doesn't seem to me that there would be any advantage to setting it lower than the maximum. Probably the low threshold is the more important parameter, from a PM perspective. If you know the FIFO's drain rate and the low threshold, it should be possible to calculate the maximum latency that the FIFO can tolerate to avoid an underflow. This could be used to specify a device PM QoS constraint to prevent the interconnect latency from exceeding that value. I'd guess the calculations would be something like this -- (I hope you can correct my relative ignorance of the DSS in the following estimates): Looking at mach-omap2/board-rx51-video.c, let's suppose that the FIFO drain rate would be 864 x 480 x 32 bits/second. Since the FIFO width is 32 bits, that's 864 x 480 = 414 780 FIFO entries/second, or (1 000 000 µs/s / 414 780 FIFO entries/s) = ~2.411 µs/FIFO entry. So if you need a low FIFO threshold at 960 entries, you could call the device PM QoS functions to set a wakeup latency constraint for the interconnect would be nothing greater than this: (2.411 µs/FIFO entry * 960 FIFO entries) = 2 314.96 µs (The reality is that it would need to be something less than this, to account for the time needed for the GFX DMA transfer to start supplying data, etc.) The ultimate goal, with Jean's device PM QoS patches, is that these constraints could change the DPLL autoidle settings or powerdomain states to ensure the constraint was met. He's got a page here: http://omappedia.org/wiki/Power_Management_Device_Latencies_Measurement (Unfortunately it's not clear what the DPLL autoidle modes and voltage scaling bits are set to for many of the estimates, and we also know that there are many software optimizations possible for our idle path.) We're still working on getting the OMAP device PM QoS patches merged, but the Linux core support is there, so you should be able to patch your drivers to use them -- see for example dev_pm_qos_add_request(). ... Similarly, for the low-power refresh case, if you know the GFX FIFO drain rate and the various latencies, it should be possible to estimate the minimum low threshold value needed in order to avoid a FIFO underflow. (By various latencies, I mean the DPLL relock latency, the GFX DMA latency between initiating a transfer and receiving the first result data, etc. Some of these latencies may be difficult to estimate accurately. But if the major sources of variation can be identified, such as DPLL relock time or GFX DMA FIFO refill time, I'd hope we can just use trial and error to find some worst-case constant for the rest.) The goal in this ase would be to allow DPLL3 to stay unlocked for as long as possible, to save energy. This would imply finding the lowest possible FIFO low threshold that doesn't generate underflows. Using the lowest possible low threshold should leave as much room as possible in the FIFO for data, and thus maximize the amount of time that DPLL3 can stay unlocked after the high threshold is reached. Since the DPLL relock latency figures are known from the TRM section 4.7.6.7 Latencies, we can estimate the DPLL's contribution to the low threshold setting. The DPLL relock latency depends on the DPLL's input rate and some DPLL settings, so it can vary. (We probably need a function for the interconnect device that can estimate the worst-case wakeup latency for the DSS to use, based on the rest of the system settings.) Let's reuse the 2.411 µs/FIFO entry estimate from above. For convenience, let's suppose that the DPLL relock latency from DPLL-OFF is 1.5 ms = 1500 µs. So we know that the number of FIFO slots needed simply to endure the DPLL relock process is CEIL(1500 µs/relock / 2.411 µs/FIFO entry) = CEIL(622.14 ...) = 623 FIFO entries/relock This of course doesn't
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Tue, 2012-05-15 at 11:55 -0600, Paul Walmsley wrote: Hello Tomi, On Mon, 14 May 2012, Tomi Valkeinen wrote: I've been doing testing to understand the problem, but so far I don't have any idea why things go wrong. I haven't found out any logic in which configuration works and which doesn't. Looks to me that for some reason the PM prevents DSS from getting data fast enough with certain fifo thresholds. I have two ways to avoid the problem, but I've been reluctant to make patches for those because I feel it's just hiding the problem. One way is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The other is to use certain fifo threshold values, which just seem to work for unknown reasons. Considering that we already have a SIDLEMODE hack in DSS for omap3 when using DSI, I wonder if the omap3 PM + DSS combination is just plain broken, and we should disallow idle. I'm not quite sure what are the implications of that. I'd appreciate comments from the PM people =). This may be caused by one of the DPLLs going into autoidle. This can involve a significant wakeup latency. I'd suggest looking at DPLL3, which provides the DSS interface clock, and DPLL4, which can provide the DSS functional clock. Could you try: 1. applying something like the patch at the bottom of this message and seeing if it makes any difference? 2. if #1 does not work, changing the dpll3 in the patch to dpll4 ? 3. if #2 does not work, disabling autoidle on both dpll3 and dpll4? Disabling DPLL3 autoidle fixes the problem. Disabling DPLL4 autoidle doesn't affect the problem. But... Isn't the iface clock only needed to program DSS? When the DSS is just running independently, plain func clock should be enough, right? Or is iface clock used for the communication between DSS and CORE/DPLL/wakeup/something? I also suspect that this could be just a plain DSS bug. The default FIFO low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the FIFO when there are 960 or less bytes in the fifo, and stops at 1023. The fifo is 1024 bytes). The values are calculated with fifo_size - burst_size and fifo_size - 1. We are now using FIFO merge features, which combines multiple fifos into one when possible, making the fifo size 1024*3 = 3072. Using the same low threshold and increasing the high threshold to 960/3071 works fine. Changing the high threshold to 3008 causes underflows. Increasing the low threshold to ~1600 makes DSS work again. So I think that the high thresholds of 3071 and 3008 are so close to each other that there shouldn't be any real difference in practice, presuming everything works. But, for whatever reason, fetching of the pixels becomes much more inefficient or with much higher start latency, causing the underflows. I guess we'd need HW people to debug this, but their interest in OMAP3 is probably long gone. So I think I'll just have to use values that seem to work for the use cases we test. Tomi signature.asc Description: This is a digitally signed message part
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Wed, 2012-05-16 at 12:08 +0300, Tomi Valkeinen wrote: On Tue, 2012-05-15 at 11:55 -0600, Paul Walmsley wrote: Hello Tomi, On Mon, 14 May 2012, Tomi Valkeinen wrote: I've been doing testing to understand the problem, but so far I don't have any idea why things go wrong. I haven't found out any logic in which configuration works and which doesn't. Looks to me that for some reason the PM prevents DSS from getting data fast enough with certain fifo thresholds. I have two ways to avoid the problem, but I've been reluctant to make patches for those because I feel it's just hiding the problem. One way is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The other is to use certain fifo threshold values, which just seem to work for unknown reasons. Considering that we already have a SIDLEMODE hack in DSS for omap3 when using DSI, I wonder if the omap3 PM + DSS combination is just plain broken, and we should disallow idle. I'm not quite sure what are the implications of that. I'd appreciate comments from the PM people =). This may be caused by one of the DPLLs going into autoidle. This can involve a significant wakeup latency. I'd suggest looking at DPLL3, which provides the DSS interface clock, and DPLL4, which can provide the DSS functional clock. Could you try: 1. applying something like the patch at the bottom of this message and seeing if it makes any difference? 2. if #1 does not work, changing the dpll3 in the patch to dpll4 ? 3. if #2 does not work, disabling autoidle on both dpll3 and dpll4? Disabling DPLL3 autoidle fixes the problem. Disabling DPLL4 autoidle doesn't affect the problem. JFYI, I also tested changing DISPC's SYSCONFIG:CLOCKACTIVITY, which, to me, sounds a bit related to dpll autoidle. By default it's 0, interface and functional clocks can be switched off. I tested the three other values, but none of them had any effect. Tomi signature.asc Description: This is a digitally signed message part
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
Hi Tomi, On 5/16/2012 11:08 AM, Tomi Valkeinen wrote: On Tue, 2012-05-15 at 11:55 -0600, Paul Walmsley wrote: Hello Tomi, On Mon, 14 May 2012, Tomi Valkeinen wrote: I've been doing testing to understand the problem, but so far I don't have any idea why things go wrong. I haven't found out any logic in which configuration works and which doesn't. Looks to me that for some reason the PM prevents DSS from getting data fast enough with certain fifo thresholds. I have two ways to avoid the problem, but I've been reluctant to make patches for those because I feel it's just hiding the problem. One way is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The other is to use certain fifo threshold values, which just seem to work for unknown reasons. Considering that we already have a SIDLEMODE hack in DSS for omap3 when using DSI, I wonder if the omap3 PM + DSS combination is just plain broken, and we should disallow idle. I'm not quite sure what are the implications of that. I'd appreciate comments from the PM people =). This may be caused by one of the DPLLs going into autoidle. This can involve a significant wakeup latency. I'd suggest looking at DPLL3, which provides the DSS interface clock, and DPLL4, which can provide the DSS functional clock. Could you try: 1. applying something like the patch at the bottom of this message and seeing if it makes any difference? 2. if #1 does not work, changing the dpll3 in the patch to dpll4 ? 3. if #2 does not work, disabling autoidle on both dpll3 and dpll4? Disabling DPLL3 autoidle fixes the problem. Disabling DPLL4 autoidle doesn't affect the problem. The issues your are facing seems to be the well known DSS low power refresh mode we've been trying to use since OMAP2 :-). DPLL3 = CORE DPLL, whereas DPLL4 = PER DPLL, so that's normal that only the DPLL3 change is affecting the issue. But... Isn't the iface clock only needed to program DSS? When the DSS is just running independently, plain func clock should be enough, right? Or is iface clock used for the communication between DSS and CORE/DPLL/wakeup/something? No, the DSS does have two ports, the slave one for the register access and a master one for the DMA inside the DSS to fetch the data from the memory. So basically, what is happening is that as soon as you allow MSTANDBY to happen, the DSS will allow the iclk to be gated, and assuming the interconnect is not used by any other initiator (like USB), the CORE DPLL (DPLL3) can be gated. The issue is that when the DSS will reach the low threshold, it will de-assert the MSTANDBY to be able to get some fresh data. But since the DPLL3 was in idle, it will take several tens of us before the clock is re-enabled and thus before the interconnect can be used by the DSS to get the data. Meanwhile the DSS FIFO is still getting low. If the latency to re-enable the DPLL + interconnect is above the duration that the FIFO DSS can support, you do have some FIFO underflow. I also suspect that this could be just a plain DSS bug. The default FIFO low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the FIFO when there are 960 or less bytes in the fifo, and stops at 1023. The fifo is 1024 bytes). The values are calculated with fifo_size - burst_size and fifo_size - 1. We are now using FIFO merge features, which combines multiple fifos into one when possible, making the fifo size 1024*3 = 3072. Using the same low threshold and increasing the high threshold to 960/3071 works fine. Changing the high threshold to 3008 causes underflows. Increasing the low threshold to ~1600 makes DSS work again. That's weird, in theory what should matter is only the diff between the high and low. Well the low value should be as high as possible as well to support the wakeup latency. So I think that the high thresholds of 3071 and 3008 are so close to each other that there shouldn't be any real difference in practice, presuming everything works. But, for whatever reason, fetching of the pixels becomes much more inefficient or with much higher start latency, causing the underflows. I guess we'd need HW people to debug this, but their interest in OMAP3 is probably long gone. So I think I'll just have to use values that seem to work for the use cases we test. Anyway, in this case, a PM QoS constraint should be set on the interconnect to ensure that potentially the DPLL3 will not be autogated as soon as the iclk is gated. The point is that whereas you set the FIFO to support the wakeup latency or you prevent the idle mode because you conside the DSS cannot support that latency because FIFO cannot be merged. Except that I'm not sure the PM QoS OMAP is in mainline yet :-( Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Mon, 2012-05-14 at 15:48 -0700, Kevin Hilman wrote: Tomi Valkeinen tomi.valkei...@ti.com writes: On Mon, 2012-05-14 at 08:36 +0100, Joe Woodward wrote: Any news on this? This thread seems to have gone a little quiet... Hi, I've been doing testing to understand the problem, but so far I don't have any idea why things go wrong. I haven't found out any logic in which configuration works and which doesn't. Looks to me that for some reason the PM prevents DSS from getting data fast enough with certain fifo thresholds. I have two ways to avoid the problem, but I've been reluctant to make patches for those because I feel it's just hiding the problem. One way is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The other is to use certain fifo threshold values, which just seem to work for unknown reasons. Considering that we already have a SIDLEMODE hack in DSS for omap3 when using DSI, I wonder if the omap3 PM + DSS combination is just plain broken, and we should disallow idle. I'm not quite sure what are the implications of that. I'd appreciate comments from the PM people =). Unfortunately, without the bandwidth to dig into this deeply myself, I don't have much to add. Yes, that's understandable. However, can you shed some light about the PM in OMAP3. What is it that happens here regarding PM, which does not happen is USB gadget driver is compiled in? Or when I set DSS to no-idle or no-standby? Something about L3/core/memory going into idle state? I tried to look at the debugfs/pm_debug/ files, but I couldn't see a difference between working and non-working cases. At least the OFF/RET/ON/etc states were not affected. Are there some other debug files to look at? Are there power saving features that are not observable via debug files? As we know, it's not unheard of for various IPs to have bugs in smart-idle mode ;) The one thing I can say is that the reason it probably worked on earlier kernels was because the UART driver was not actually idling, so you were probably never hitting low power states. There is also a change in the DSS fifos, which probably triggered this. I think I can fall back to the old behavior. Tomi signature.asc Description: This is a digitally signed message part
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Mon, 2012-05-14 at 15:48 -0700, Kevin Hilman wrote:
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Mon, 2012-05-14 at 08:36 +0100, Joe Woodward wrote:
Any news on this?
This thread seems to have gone a little quiet...
Hi,
I've been doing testing to understand the problem, but so far I don't
have any idea why things go wrong. I haven't found out any logic in
which configuration works and which doesn't. Looks to me that for some
reason the PM prevents DSS from getting data fast enough with certain
fifo thresholds.
I have two ways to avoid the problem, but I've been reluctant to make
patches for those because I feel it's just hiding the problem. One way
is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The
other is to use certain fifo threshold values, which just seem to work
for unknown reasons.
Considering that we already have a SIDLEMODE hack in DSS for omap3 when
using DSI, I wonder if the omap3 PM + DSS combination is just plain
broken, and we should disallow idle. I'm not quite sure what are the
implications of that.
I'd appreciate comments from the PM people =).
Unfortunately, without the bandwidth to dig into this deeply myself, I
don't have much to add.
Yes, that's understandable.
However, can you shed some light about the PM in OMAP3. What is it that
happens here regarding PM, which does not happen is USB gadget driver is
compiled in? Or when I set DSS to no-idle or no-standby? Something about
L3/core/memory going into idle state?
My first guess would have been that in those two cases, CORE was
prevented from going into retention, but based on what you said earlier,
it sounds like CORE is always staying on.
Just to clarify: by USB gadget, I assume you mean MUSB? (a.k.a USB OTG,
or HS USB in the TRM)? I'm a bit confused because earlier you mentioned
keeping usbhost_pwrdm active, but USB host is separate IP in its own
powerdomain, whereas USB OTG is an IP in the CORE powerdomain.
I tried to look at the debugfs/pm_debug/ files, but I couldn't see a
difference between working and non-working cases. At least the
OFF/RET/ON/etc states were not affected. Are there some other debug
files to look at? Are there power saving features that are not
observable via debug files?
There may not be a difference in the actual states being hit, but there
may be subtle differences in latencies to enter/exit the various states.
An interesting experiment would be to disable the deeper C-states in
CPUidle and see if the problem still exists. Here's a little shell
snippet to do this via sysfs:
# CPUidle: disable everything but C1
cd /sys/devices/system/cpu/cpu0/cpuidle
for state in state[1-6]*; do
if [ -e ${state} ]; then
echo 1 ${state}/disable
fi
done
As we know, it's not unheard of for various IPs to have bugs in
smart-idle mode ;)
The one thing I can say is that the reason it probably worked on earlier
kernels was because the UART driver was not actually idling, so you were
probably never hitting low power states.
There is also a change in the DSS fifos, which probably triggered this.
I think I can fall back to the old behavior.
Because of the current boot defaults, the only pwrdm that is actively
transitioning during idle is the MPU pwrdm.
So if preventing the MPU pwrdm from hitting idle makes the problem go
away, we'd need to better understand this wakeup latency constraint and
possibly code it in the DSS driver.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
Hello Tomi, On Mon, 14 May 2012, Tomi Valkeinen wrote: I've been doing testing to understand the problem, but so far I don't have any idea why things go wrong. I haven't found out any logic in which configuration works and which doesn't. Looks to me that for some reason the PM prevents DSS from getting data fast enough with certain fifo thresholds. I have two ways to avoid the problem, but I've been reluctant to make patches for those because I feel it's just hiding the problem. One way is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The other is to use certain fifo threshold values, which just seem to work for unknown reasons. Considering that we already have a SIDLEMODE hack in DSS for omap3 when using DSI, I wonder if the omap3 PM + DSS combination is just plain broken, and we should disallow idle. I'm not quite sure what are the implications of that. I'd appreciate comments from the PM people =). This may be caused by one of the DPLLs going into autoidle. This can involve a significant wakeup latency. I'd suggest looking at DPLL3, which provides the DSS interface clock, and DPLL4, which can provide the DSS functional clock. Could you try: 1. applying something like the patch at the bottom of this message and seeing if it makes any difference? 2. if #1 does not work, changing the dpll3 in the patch to dpll4 ? 3. if #2 does not work, disabling autoidle on both dpll3 and dpll4? I regret that I haven't been able to focus more on DSS issues - - Paul Date: Wed, 14 Mar 2012 17:49:43 -0600 (MDT) From: Paul Walmsley p...@pwsan.com Subject: Patch that should disable DPLL3 autoidle Test patch to disable DPLL3 autoidle. --- arch/arm/plat-omap/clock.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c index 567e4b5..4b02b35 100644 --- a/arch/arm/plat-omap/clock.c +++ b/arch/arm/plat-omap/clock.c @@ -351,6 +351,13 @@ int omap_clk_enable_autoidle_all(void) if (c-ops-allow_idle) c-ops-allow_idle(c); + c = clk_get(NULL, dpll3_ck); + if (c c-ops-deny_idle) + c-ops-deny_idle(c); + else + WARN(1, Cannot disable autoidle on DPLL3\n); + clk_put(c); + spin_unlock_irqrestore(clockfw_lock, flags); return 0; -- 1.7.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
Any news on this? This thread seems to have gone a little quiet... Cheers, Joe -Original Message- From: Tomi Valkeinen tomi.valkei...@ti.com To: Paul Walmsley p...@pwsan.com, khil...@ti.com Cc: Archit Taneja a0393...@ti.com, linux-omap@vger.kernel.org, Joe Woodward j...@terrafix.co.uk Date: Tue, 08 May 2012 16:26:38 +0300 Subject: Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5) On Fri, 2012-05-04 at 17:58 +0300, Tomi Valkeinen wrote: On Fri, 2012-05-04 at 17:54 +0300, Tomi Valkeinen wrote: Hi Kevin, Paul, On Fri, 2012-05-04 at 15:09 +0100, Joe Woodward wrote: Ok, I can replicate it now. It seems to be somehow PM related. I normally have USB gadget stuff compiled into kernel so that I can boot via nfsroot with usb. After disabling USB support from the kernel, I can see synclosts. I have no idea yet what could be causing this. I've also tried adding the couple of DSS patches which are in queue for next merge window, that force OPP100 when DSS is enabled. They don't seem to help. Also, at least on my setup, the sync lost doesn't happen very quickly after starting the video output, but (I think) only when the system starts to idle. My init scripts generate keys for sshd and some other stuff, and no sync lost there, only just before the shell prompt do I get a sync lost. Tomi That sounds like the same as I'm seeing. It seems that the sync lost jumps around a bit, from almost immediately (when the graphics are enabled), to up to 3 or 4 seconds later (still just before the shell prompt). I'm assuming that setting the FIFO low and high points fixes your sync losts as well (as in the first patch you sent)? I've also noted that doing things in different orders can sometimes fix the sync lost (such as disabling or enabling DVI output), but this all seems a bit random. I'm just glad someone else has been able to replicate the problem :p Kevin, Paul, there seems to be a problem with DSS on v3.4-rc4 running on omap3, causing DSS losing sync. I didn't notice this earlier as I have USB gadget compiled into my kernel. Removing USB support from the kernel causes the problem to appear, which more or less hints at a PM related issue. Sorry, not sync lost, but FIFO underflow. So DSS is unable to fetch enough pixels to update the panel. And in this case the pixel clock is very low (small panel), so it's nowhere near any limit. And two more interesting points about the problem: Setting DISPC's SIDLEMODE to no-idle seems to remove the issue. With some DISPC's fifo high/low threshold values things seem to work, while with others we get underflows. And as the required bandwidth here is quite small, and the threshold values I tested are close to each other, I don't think it's really a proper bandwidth issue. I'm guessing that certain threshold values cause somehow un-optimal accesses to the memory, and with smart-idle this somehow causes problems. Archit, you looked into the thresholds some time ago. I recall that some threshold values were bad in some way? Were those only for OMAP4? Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Mon, 2012-05-14 at 08:36 +0100, Joe Woodward wrote: Any news on this? This thread seems to have gone a little quiet... Hi, I've been doing testing to understand the problem, but so far I don't have any idea why things go wrong. I haven't found out any logic in which configuration works and which doesn't. Looks to me that for some reason the PM prevents DSS from getting data fast enough with certain fifo thresholds. I have two ways to avoid the problem, but I've been reluctant to make patches for those because I feel it's just hiding the problem. One way is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The other is to use certain fifo threshold values, which just seem to work for unknown reasons. Considering that we already have a SIDLEMODE hack in DSS for omap3 when using DSI, I wonder if the omap3 PM + DSS combination is just plain broken, and we should disallow idle. I'm not quite sure what are the implications of that. I'd appreciate comments from the PM people =). Tomi signature.asc Description: This is a digitally signed message part
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
Tomi Valkeinen tomi.valkei...@ti.com writes: On Mon, 2012-05-14 at 08:36 +0100, Joe Woodward wrote: Any news on this? This thread seems to have gone a little quiet... Hi, I've been doing testing to understand the problem, but so far I don't have any idea why things go wrong. I haven't found out any logic in which configuration works and which doesn't. Looks to me that for some reason the PM prevents DSS from getting data fast enough with certain fifo thresholds. I have two ways to avoid the problem, but I've been reluctant to make patches for those because I feel it's just hiding the problem. One way is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The other is to use certain fifo threshold values, which just seem to work for unknown reasons. Considering that we already have a SIDLEMODE hack in DSS for omap3 when using DSI, I wonder if the omap3 PM + DSS combination is just plain broken, and we should disallow idle. I'm not quite sure what are the implications of that. I'd appreciate comments from the PM people =). Unfortunately, without the bandwidth to dig into this deeply myself, I don't have much to add. As we know, it's not unheard of for various IPs to have bugs in smart-idle mode ;) The one thing I can say is that the reason it probably worked on earlier kernels was because the UART driver was not actually idling, so you were probably never hitting low power states. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Fri, 2012-05-04 at 17:58 +0300, Tomi Valkeinen wrote: On Fri, 2012-05-04 at 17:54 +0300, Tomi Valkeinen wrote: Hi Kevin, Paul, On Fri, 2012-05-04 at 15:09 +0100, Joe Woodward wrote: Ok, I can replicate it now. It seems to be somehow PM related. I normally have USB gadget stuff compiled into kernel so that I can boot via nfsroot with usb. After disabling USB support from the kernel, I can see synclosts. I have no idea yet what could be causing this. I've also tried adding the couple of DSS patches which are in queue for next merge window, that force OPP100 when DSS is enabled. They don't seem to help. Also, at least on my setup, the sync lost doesn't happen very quickly after starting the video output, but (I think) only when the system starts to idle. My init scripts generate keys for sshd and some other stuff, and no sync lost there, only just before the shell prompt do I get a sync lost. Tomi That sounds like the same as I'm seeing. It seems that the sync lost jumps around a bit, from almost immediately (when the graphics are enabled), to up to 3 or 4 seconds later (still just before the shell prompt). I'm assuming that setting the FIFO low and high points fixes your sync losts as well (as in the first patch you sent)? I've also noted that doing things in different orders can sometimes fix the sync lost (such as disabling or enabling DVI output), but this all seems a bit random. I'm just glad someone else has been able to replicate the problem :p Kevin, Paul, there seems to be a problem with DSS on v3.4-rc4 running on omap3, causing DSS losing sync. I didn't notice this earlier as I have USB gadget compiled into my kernel. Removing USB support from the kernel causes the problem to appear, which more or less hints at a PM related issue. Sorry, not sync lost, but FIFO underflow. So DSS is unable to fetch enough pixels to update the panel. And in this case the pixel clock is very low (small panel), so it's nowhere near any limit. And two more interesting points about the problem: Setting DISPC's SIDLEMODE to no-idle seems to remove the issue. With some DISPC's fifo high/low threshold values things seem to work, while with others we get underflows. And as the required bandwidth here is quite small, and the threshold values I tested are close to each other, I don't think it's really a proper bandwidth issue. I'm guessing that certain threshold values cause somehow un-optimal accesses to the memory, and with smart-idle this somehow causes problems. Archit, you looked into the thresholds some time ago. I recall that some threshold values were bad in some way? Were those only for OMAP4? Tomi signature.asc Description: This is a digitally signed message part
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Fri, 2012-05-04 at 17:54 +0300, Tomi Valkeinen wrote: Hi Kevin, Paul, On Fri, 2012-05-04 at 15:09 +0100, Joe Woodward wrote: Ok, I can replicate it now. It seems to be somehow PM related. I normally have USB gadget stuff compiled into kernel so that I can boot via nfsroot with usb. After disabling USB support from the kernel, I can see synclosts. I have no idea yet what could be causing this. I've also tried adding the couple of DSS patches which are in queue for next merge window, that force OPP100 when DSS is enabled. They don't seem to help. Also, at least on my setup, the sync lost doesn't happen very quickly after starting the video output, but (I think) only when the system starts to idle. My init scripts generate keys for sshd and some other stuff, and no sync lost there, only just before the shell prompt do I get a sync lost. Tomi That sounds like the same as I'm seeing. It seems that the sync lost jumps around a bit, from almost immediately (when the graphics are enabled), to up to 3 or 4 seconds later (still just before the shell prompt). I'm assuming that setting the FIFO low and high points fixes your sync losts as well (as in the first patch you sent)? I've also noted that doing things in different orders can sometimes fix the sync lost (such as disabling or enabling DVI output), but this all seems a bit random. I'm just glad someone else has been able to replicate the problem :p Kevin, Paul, there seems to be a problem with DSS on v3.4-rc4 running on omap3, causing DSS losing sync. I didn't notice this earlier as I have USB gadget compiled into my kernel. Removing USB support from the kernel causes the problem to appear, which more or less hints at a PM related issue. Sorry, not sync lost, but FIFO underflow. So DSS is unable to fetch enough pixels to update the panel. And in this case the pixel clock is very low (small panel), so it's nowhere near any limit. Tomi signature.asc Description: This is a digitally signed message part
