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 > To: Joe Woodward > Cc: Jean Pihet , Paul Walmsley , > khil...@ti.com, Archit Taneja , 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)
-Original Message- From: Tomi Valkeinen To: Joe Woodward Cc: Jean Pihet , Paul Walmsley , khil...@ti.com, Archit Taneja , 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: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)
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 To: Paul Walmsley , Tomi Valkeinen Cc: Joe Woodward , khil...@ti.com, Archit Taneja , 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 > 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.) > > > &g
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 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. >> t
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,
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
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)
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)
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 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)
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)
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 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)
Tomi Valkeinen writes:
> On Mon, 2012-05-14 at 15:48 -0700, Kevin Hilman wrote:
>> Tomi Valkeinen 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)
On Mon, 2012-05-14 at 15:48 -0700, Kevin Hilman wrote: > Tomi Valkeinen 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 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 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)
Any news on this? This thread seems to have gone a little quiet... Cheers, Joe -Original Message- From: Tomi Valkeinen To: Paul Walmsley , khil...@ti.com Cc: Archit Taneja , linux-omap@vger.kernel.org, Joe Woodward 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 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
v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
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. I don't see the problem with v3.3, but as there has been a lot of DSS changes also, it could as well be a DSS change that has triggered the problem. It also looks that the sync lost happens when the system idles a bit. I compared count and time files in debugfs/pm_debug/ for both working (i.e. usb compiled in) and non-working cases, but they seem similar for the relevant parts. core_pwrdm is always ON, mpu_pwrdm has both RET and ON states, dss_pwrdm both RET and ON states (identical counts). Do you have anything in mind related to PM that has changed for v3.4 which could affect DSS? Any idea what effect USB gadget has? My understanding is that it keeps usbhost_pwrdm forcibly alive, maybe also something else, but I'm not sure why it would affect DSS. I also tested with my DSS OPP100 patches, which try to force OPP100 when DSS is enabled by adding a PM constraint for bus tput of 10, but it doesn't seem to have any effect. And, I guess, the constraint affects only core_pwrdm, and as seen it's anyway always on in both cases. Any debugging ideas are welcome. Tomi signature.asc Description: This is a digitally signed message part
Re: Problems with 3.4-rc5
-Original Message- From: Tomi Valkeinen To: Joe Woodward Cc: Archit Taneja , linux-omap@vger.kernel.org Date: Fri, 04 May 2012 17:01:12 +0300 Subject: Re: Problems with 3.4-rc5 > On Fri, 2012-05-04 at 16:50 +0300, Tomi Valkeinen wrote: > > On Fri, 2012-05-04 at 10:19 +0100, Joe Woodward wrote: > > > -Original Message- > > > From: Tomi Valkeinen > > > To: Joe Woodward > > > Cc: Archit Taneja , linux-omap@vger.kernel.org > > > Date: Thu, 03 May 2012 16:07:22 +0300 > > > Subject: Re: Problems with 3.4-rc5 > > > > > > > On Thu, 2012-05-03 at 09:49 +0100, Joe Woodward wrote: > > > > > > > > > Both patches together results in slightly different behaviour, > the > > > > display is still broken- > > > > > it flickers on and off with occassional underflows before > breaking > > > > completely. > > > > > > > > Beagle works fine for me with omap2plus based config, and I think > overo > > > > also although I can't test it now as I broke my micro mmc > adapter. > > > > > > > > Can you send your panel definition? Any other things that could > affect > > > > display? Do you have PM enabled? Can you share your kernel > config? > > > > > > > > Tomi > > > > > > > > > > I've gone back to a test setup others can replicate. > > > > 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 Cheers, Joe -- 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: Problems with 3.4-rc5
On Fri, 2012-05-04 at 16:50 +0300, Tomi Valkeinen wrote: > On Fri, 2012-05-04 at 10:19 +0100, Joe Woodward wrote: > > -Original Message- > > From: Tomi Valkeinen > > To: Joe Woodward > > Cc: Archit Taneja , linux-omap@vger.kernel.org > > Date: Thu, 03 May 2012 16:07:22 +0300 > > Subject: Re: Problems with 3.4-rc5 > > > > > On Thu, 2012-05-03 at 09:49 +0100, Joe Woodward wrote: > > > > > > > Both patches together results in slightly different behaviour, the > > > display is still broken- > > > > it flickers on and off with occassional underflows before breaking > > > completely. > > > > > > Beagle works fine for me with omap2plus based config, and I think overo > > > also although I can't test it now as I broke my micro mmc adapter. > > > > > > Can you send your panel definition? Any other things that could affect > > > display? Do you have PM enabled? Can you share your kernel config? > > > > > > Tomi > > > > > > > I've gone back to a test setup others can replicate. > > 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 signature.asc Description: This is a digitally signed message part
Re: Problems with 3.4-rc5
On Fri, 2012-05-04 at 10:19 +0100, Joe Woodward wrote: > -Original Message- > From: Tomi Valkeinen > To: Joe Woodward > Cc: Archit Taneja , linux-omap@vger.kernel.org > Date: Thu, 03 May 2012 16:07:22 +0300 > Subject: Re: Problems with 3.4-rc5 > > > On Thu, 2012-05-03 at 09:49 +0100, Joe Woodward wrote: > > > > > Both patches together results in slightly different behaviour, the > > display is still broken- > > > it flickers on and off with occassional underflows before breaking > > completely. > > > > Beagle works fine for me with omap2plus based config, and I think overo > > also although I can't test it now as I broke my micro mmc adapter. > > > > Can you send your panel definition? Any other things that could affect > > display? Do you have PM enabled? Can you share your kernel config? > > > > Tomi > > > > I've gone back to a test setup others can replicate. 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. Tomi signature.asc Description: This is a digitally signed message part
Re: Problems with 3.4-rc5
-Original Message-
From: Tomi Valkeinen
To: Joe Woodward
Cc: Archit Taneja , linux-omap@vger.kernel.org
Date: Thu, 03 May 2012 16:07:22 +0300
Subject: Re: Problems with 3.4-rc5
> On Thu, 2012-05-03 at 09:49 +0100, Joe Woodward wrote:
>
> > Both patches together results in slightly different behaviour, the
> display is still broken-
> > it flickers on and off with occassional underflows before breaking
> completely.
>
> Beagle works fine for me with omap2plus based config, and I think overo
> also although I can't test it now as I broke my micro mmc adapter.
>
> Can you send your panel definition? Any other things that could affect
> display? Do you have PM enabled? Can you share your kernel config?
>
> Tomi
>
I've gone back to a test setup others can replicate.
I have a GUSMTIX Overo Earth (OMAP3503-based), running in a
Chestnut43 board with a connect 4.3" Samsung LCD panel (480x320).
(my previous emails were using a GUMSTIX Overo AirSTORM (AM3703),
but the results seem to be the same with the Earth)
I've built stock 3.4-rc5 using the omap2plus_defconfig (using the
CodeSorcery toolchain: arm-2010.09-50-arm-none-linux-gnueabi.bin).
I've had to make the following changes to the defconfig for my RFS (I've
attached the defconfig for reference):
CONFIG_OMAP2_DSS=y
CONFIG_OMAP2_VRAM_SIZE=4
CONFIG_FB_OMAP2=y
CONFIG_PANEL_GENERIC_DPI=y
CONFIG_TUN=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_SQUASHFS=y
I've also set the LCD to the default display device in board-overo.c:
static struct omap_dss_board_info overo_dss_data = {
.num_devices = ARRAY_SIZE
(overo_dss_devices),
.devices = overo_dss_devices,
.default_device = &overo_lcd43_device, /* @@
Default to LCD*/
};
I'm booting using uBoot 2012.04.01, and run everything from RAM.
When booting I can see the Linux boot logo for a short time.
The log is pasted below, but you can see:
[6.621215] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling
the overlay
Cheers,
Joe
Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0
[0.00] Linux version 3.4.0-rc5 (joe@joe-VirtualBox) (gcc version
4.5.1 (Sourcery G++ Lite 2010.09-50) ) #6 SMP Thu May 3 15:38:04 BST
2012
[0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7),
cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing
instruction cache
[0.00] Machine: Gumstix Overo
[0.00] Reserving 4194304 bytes SDRAM for VRAM
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
[0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz
[0.00] PERCPU: Embedded 8 pages/cpu @c7408000 s11520 r8192
d13056 u32768
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 128768
[0.00] Kernel command line: console=ttyO2,115200
omapfb.rotate=0 root=/dev/ram0 rw ramdisk_size=98304
initrd=0x8100,96M rootfstype=squashfs
[0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144
bytes)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072
bytes)
[0.00] Memory: 507MB = 507MB total
[0.00] Memory: 403416k/403416k available, 120872k reserved, 0K
highmem
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB)
[0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB)
[0.00] lowmem : 0xc000 - 0xe000 ( 512 MB)
[0.00] modules : 0xbf00 - 0xc000 ( 16 MB)
[0.00] .text : 0xc0008000 - 0xc065e058 (6489 kB)
[0.00] .init : 0xc065f000 - 0xc06acd00 ( 312 kB)
[0.00] .data : 0xc06ae000 - 0xc0740d18 ( 588 kB)
[0.00].bss : 0xc0740d3c - 0xc0c96b20 (5464 kB)
[0.00] Hierarchical RCU implementation.
[0.00] NR_IRQS:474
[0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96
interrupts
[0.00] Total of 96 interrupts on 1 active controller
[0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz
[0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps
every 131071999ms
[0.00] Console: colour dummy device 80x30
[0.00] Lock dependency validator: Copyright (c) 2006 Red Hat,
Inc., Ingo Molnar
[0.00] ... MAX_LOCKDEP_SUBCLASSES: 8
[0.00] ... MAX_LOCK_DEPTH: 48
[0.00] ... MAX_LOCKDEP_KEYS:8191
[0.00] ... CLASSHASH_SIZE: 4096
[0.00] ... MAX_LOCKDEP_ENTRIES: 16384
[0.00] ... MAX_LOCKDEP_CHAINS: 32768
[0.
Re: Problems with 3.4-rc5
On Thu, 2012-05-03 at 09:49 +0100, Joe Woodward wrote: > Both patches together results in slightly different behaviour, the display is > still broken- > it flickers on and off with occassional underflows before breaking completely. Beagle works fine for me with omap2plus based config, and I think overo also although I can't test it now as I broke my micro mmc adapter. Can you send your panel definition? Any other things that could affect display? Do you have PM enabled? Can you share your kernel config? Tomi signature.asc Description: This is a digitally signed message part
Re: Problems with 3.4-rc5
On Thursday 03 May 2012 02:19 PM, Joe Woodward wrote:
-Original Message-
From: Tomi Valkeinen
To: Joe Woodward
Cc: Archit Taneja, linux-omap@vger.kernel.org
Date: Thu, 03 May 2012 11:28:41 +0300
Subject: Re: Problems with 3.4-rc5
On Wed, 2012-05-02 at 13:46 +0100, Joe Woodward wrote:
Secondly, I get the following when booted:
...
[4.701232] devtmpfs: mounted
[4.704772] Freeing init memory: 168K
[4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx,
disabling
the overlay
...
Could you add some dss debug prints? You can add "omapdss.debug=1
debug"
in the bootargs to get that.
There was a feature called fifo merge added in 3.4, this might lead
to
underflow, we had tested this using a DVI monitor on beagle but
didn't
see any underflows.
Are you trying this out on 3.4 for the first time? What was the
last
kernel revision on which you tested this and didn't see any issues?
Can you try the following changes (separately):
diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index ee30937..aca4eb1 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1091,13 +1091,8 @@ void dispc_ovl_compute_fifo_thresholds(enum
omap_plane plane,
* combined fifo size
*/
- if (dss_has_feature(FEAT_OMAP3_DSI_FIFO_BUG)) {
- *fifo_low = ovl_fifo_size - burst_size * 2;
- *fifo_high = total_fifo_size - burst_size;
- } else {
- *fifo_low = ovl_fifo_size - burst_size;
- *fifo_high = total_fifo_size - buf_unit;
- }
+ *fifo_low = ovl_fifo_size - burst_size;
+ *fifo_high = total_fifo_size - buf_unit;
}
static void dispc_ovl_set_fir(enum omap_plane plane,
---
The above patch fixes the problem (I no longer see any underflows).
Tomi,
Before FIFO merge was added, the special fifo_low/high calculation was
only done for DSI on OMAP3, now it seems to be done on OMAP3 and for all
interfaces. Maybe this is the difference between 3.3.
diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index ee30937..d63f1a3 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1077,13 +1077,7 @@ void dispc_ovl_compute_fifo_thresholds(enum
omap_plane plane,
burst_size = dispc_ovl_get_burst_size(plane);
ovl_fifo_size = dispc_ovl_get_fifo_size(plane);
- if (use_fifomerge) {
- total_fifo_size = 0;
- for (i = 0; i< omap_dss_get_num_overlays(); ++i)
- total_fifo_size += dispc_ovl_get_fifo_size(i);
- } else {
- total_fifo_size = ovl_fifo_size;
- }
+ total_fifo_size = ovl_fifo_size;
/*
* We use the same low threshold for both fifomerge and non-fifomerge
The above patch has no effect (I still see underflows).
Both patches together results in slightly different behaviour, the display is
still broken-
it flickers on and off with occassional underflows before breaking completely.
With both the patches combined, we are configuring DSS with FIFO merge
enabled, but configuring thresholds normally and not utilising the large
FIFO. Getting underflows with this is strange, because it's more or less
similar to what it was on 3.3 without FIFO merge.
Archit
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: Problems with 3.4-rc5
-Original Message-
From: Tomi Valkeinen
To: Joe Woodward
Cc: Archit Taneja , linux-omap@vger.kernel.org
Date: Thu, 03 May 2012 11:28:41 +0300
Subject: Re: Problems with 3.4-rc5
> On Wed, 2012-05-02 at 13:46 +0100, Joe Woodward wrote:
>
> > > > Secondly, I get the following when booted:
> > > > ...
> > > > [4.701232] devtmpfs: mounted
> > > > [4.704772] Freeing init memory: 168K
> > > > [4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx,
> disabling
> > > the overlay
> > > > ...
> > > >
> > >
> > > Could you add some dss debug prints? You can add "omapdss.debug=1
> > > debug"
> > > in the bootargs to get that.
> > >
> > > There was a feature called fifo merge added in 3.4, this might lead
> to
> > > underflow, we had tested this using a DVI monitor on beagle but
> didn't
> > > see any underflows.
> > >
> > > Are you trying this out on 3.4 for the first time? What was the
> last
> > > kernel revision on which you tested this and didn't see any issues?
>
> Can you try the following changes (separately):
>
>
> diff --git a/drivers/video/omap2/dss/dispc.c
> b/drivers/video/omap2/dss/dispc.c
> index ee30937..aca4eb1 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -1091,13 +1091,8 @@ void dispc_ovl_compute_fifo_thresholds(enum
> omap_plane plane,
>* combined fifo size
>*/
>
> - if (dss_has_feature(FEAT_OMAP3_DSI_FIFO_BUG)) {
> - *fifo_low = ovl_fifo_size - burst_size * 2;
> - *fifo_high = total_fifo_size - burst_size;
> - } else {
> - *fifo_low = ovl_fifo_size - burst_size;
> - *fifo_high = total_fifo_size - buf_unit;
> - }
> + *fifo_low = ovl_fifo_size - burst_size;
> + *fifo_high = total_fifo_size - buf_unit;
> }
>
> static void dispc_ovl_set_fir(enum omap_plane plane,
>
> ---
The above patch fixes the problem (I no longer see any underflows).
>
> diff --git a/drivers/video/omap2/dss/dispc.c
> b/drivers/video/omap2/dss/dispc.c
> index ee30937..d63f1a3 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -1077,13 +1077,7 @@ void dispc_ovl_compute_fifo_thresholds(enum
> omap_plane plane,
> burst_size = dispc_ovl_get_burst_size(plane);
> ovl_fifo_size = dispc_ovl_get_fifo_size(plane);
>
> - if (use_fifomerge) {
> - total_fifo_size = 0;
> - for (i = 0; i < omap_dss_get_num_overlays(); ++i)
> - total_fifo_size += dispc_ovl_get_fifo_size(i);
> - } else {
> - total_fifo_size = ovl_fifo_size;
> - }
> + total_fifo_size = ovl_fifo_size;
>
> /*
>* We use the same low threshold for both fifomerge and non-fifomerge
>
The above patch has no effect (I still see underflows).
Both patches together results in slightly different behaviour, the display is
still broken-
it flickers on and off with occassional underflows before breaking completely.
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: Problems with 3.4-rc5
On Wed, 2012-05-02 at 13:46 +0100, Joe Woodward wrote:
> > > Secondly, I get the following when booted:
> > > ...
> > > [4.701232] devtmpfs: mounted
> > > [4.704772] Freeing init memory: 168K
> > > [4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling
> > the overlay
> > > ...
> > >
> >
> > Could you add some dss debug prints? You can add "omapdss.debug=1
> > debug"
> > in the bootargs to get that.
> >
> > There was a feature called fifo merge added in 3.4, this might lead to
> > underflow, we had tested this using a DVI monitor on beagle but didn't
> > see any underflows.
> >
> > Are you trying this out on 3.4 for the first time? What was the last
> > kernel revision on which you tested this and didn't see any issues?
Can you try the following changes (separately):
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ee30937..aca4eb1 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1091,13 +1091,8 @@ void dispc_ovl_compute_fifo_thresholds(enum omap_plane
plane,
* combined fifo size
*/
- if (dss_has_feature(FEAT_OMAP3_DSI_FIFO_BUG)) {
- *fifo_low = ovl_fifo_size - burst_size * 2;
- *fifo_high = total_fifo_size - burst_size;
- } else {
- *fifo_low = ovl_fifo_size - burst_size;
- *fifo_high = total_fifo_size - buf_unit;
- }
+ *fifo_low = ovl_fifo_size - burst_size;
+ *fifo_high = total_fifo_size - buf_unit;
}
static void dispc_ovl_set_fir(enum omap_plane plane,
---
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ee30937..d63f1a3 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1077,13 +1077,7 @@ void dispc_ovl_compute_fifo_thresholds(enum omap_plane
plane,
burst_size = dispc_ovl_get_burst_size(plane);
ovl_fifo_size = dispc_ovl_get_fifo_size(plane);
- if (use_fifomerge) {
- total_fifo_size = 0;
- for (i = 0; i < omap_dss_get_num_overlays(); ++i)
- total_fifo_size += dispc_ovl_get_fifo_size(i);
- } else {
- total_fifo_size = ovl_fifo_size;
- }
+ total_fifo_size = ovl_fifo_size;
/*
* We use the same low threshold for both fifomerge and non-fifomerge
Tomi
signature.asc
Description: This is a digitally signed message part
Re: Problems with 3.4-rc5
-Original Message- From: Archit Taneja To: Joe Woodward Cc: Date: Wed, 2 May 2012 17:54:21 +0530 Subject: Re: Problems with 3.4-rc5 > Hi, > > On Wednesday 02 May 2012 05:22 PM, Joe Woodward wrote: > > I've just given 3.4-rc5 a quick run-through on my GUMSTIX Overo > (AM3703), and have noticed a couple of issues... > > > > Firstly, it fails to build "drivers/mfd/omap-usb-host.c" if you have: > > > > CONFIG_USB_EHCI_HCD=m > > CONFIG_USB_EHCI_ROOT_HUB_TT=y > > CONFIG_USB_EHCI_TT_NEWSCHED=y > > CONFIG_USB_EHCI_HCD_OMAP=y > > > > drivers/mfd/omap-usb-host.c: In function 'omap_usbhs_init': > > drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of > function 'cpu_is_omap3430' > > drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of > function 'omap_rev' > > drivers/mfd/omap-usb-host.c:524:43: error: 'OMAP3430_REV_ES2_1' > undeclared (first use in this function) > > drivers/mfd/omap-usb-host.c:524:43: note: each undeclared identifier > is reported only once for each function it appears in > > > > I'm assuming this has been spotted and I've missed the fix (just a > missing include?). > > > > Secondly, I get the following when booted: > > ... > > [4.701232] devtmpfs: mounted > > [4.704772] Freeing init memory: 168K > > [4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling > the overlay > > ... > > > > Could you add some dss debug prints? You can add "omapdss.debug=1 > debug" > in the bootargs to get that. > > There was a feature called fifo merge added in 3.4, this might lead to > underflow, we had tested this using a DVI monitor on beagle but didn't > see any underflows. > > Are you trying this out on 3.4 for the first time? What was the last > kernel revision on which you tested this and didn't see any issues? See below for a more complete trace with debug enabled. I have been using 3.3.0, which doesn't give me any DSS underflow problems at all. And yes, this is the first time I've tried anything 3.4-based. For reference, I'm running from a RAM-based file system which is the same as I use on 3.3.0. Cheers, Joe Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.4.0-rc5 (joe@joe-VirtualBox) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #4 SMP Wed May 2 12:43:38 BST 2012 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Gumstix Overo [0.00] Reserving 8388608 bytes SDRAM for VRAM [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 128768 [0.00] free_area_init_node: node 0, pgdat c06f4740, node_mem_map c700 [0.00] Normal zone: 1024 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 127744 pages, LIFO batch:31 [0.00] OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz [0.00] PERCPU: Embedded 8 pages/cpu @c7408000 s11520 r8192 d13056 u32768 [0.00] pcpu-alloc: s11520 r8192 d13056 u32768 alloc=8*4096 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 127744 [0.00] Kernel command line: console=ttyO2,115200 omapfb.rotate=0 omapdss.debug=1 debug root=/dev/ram0 rw ramdisk_size=98304 initrd=0x8100,96M rootfstype=squashfs [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 503MB = 503MB total [0.00] Memory: 399616k/399616k available, 124672k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc0614f30 (6196 kB) [0.00] .init : 0xc0615000 - 0xc0662d00 ( 312 kB) [0.00] .data : 0xc0664000 - 0xc06f63d8 ( 585 kB) [0.00].bss : 0xc06f63fc - 0xc0c4c020 (5464 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:474 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0
Re: Problems with 3.4-rc5
Hi, On Wednesday 02 May 2012 05:22 PM, Joe Woodward wrote: I've just given 3.4-rc5 a quick run-through on my GUMSTIX Overo (AM3703), and have noticed a couple of issues... Firstly, it fails to build "drivers/mfd/omap-usb-host.c" if you have: CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y CONFIG_USB_EHCI_HCD_OMAP=y drivers/mfd/omap-usb-host.c: In function 'omap_usbhs_init': drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of function 'cpu_is_omap3430' drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of function 'omap_rev' drivers/mfd/omap-usb-host.c:524:43: error: 'OMAP3430_REV_ES2_1' undeclared (first use in this function) drivers/mfd/omap-usb-host.c:524:43: note: each undeclared identifier is reported only once for each function it appears in I'm assuming this has been spotted and I've missed the fix (just a missing include?). Secondly, I get the following when booted: ... [4.701232] devtmpfs: mounted [4.704772] Freeing init memory: 168K [4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling the overlay ... Could you add some dss debug prints? You can add "omapdss.debug=1 debug" in the bootargs to get that. There was a feature called fifo merge added in 3.4, this might lead to underflow, we had tested this using a DVI monitor on beagle but didn't see any underflows. Are you trying this out on 3.4 for the first time? What was the last kernel revision on which you tested this and didn't see any issues? Thanks, Archit Which means that the display doesn't work. I am currently running 3.3, which works just fine and doesn't give an underflow. So was wondering what changes have been made that may affect this? There were problems in the 3.2-era due to runtime- PM causing a similar issue, has anything changed around here again? (as a side not: the panel I use is a custom 800x480 added to panel-generic-dpi.c, with board-overo.c updated to use it). Cheers, Joe Woodward -- 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 -- 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
Problems with 3.4-rc5
I've just given 3.4-rc5 a quick run-through on my GUMSTIX Overo (AM3703), and have noticed a couple of issues... Firstly, it fails to build "drivers/mfd/omap-usb-host.c" if you have: CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y CONFIG_USB_EHCI_HCD_OMAP=y drivers/mfd/omap-usb-host.c: In function 'omap_usbhs_init': drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of function 'cpu_is_omap3430' drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of function 'omap_rev' drivers/mfd/omap-usb-host.c:524:43: error: 'OMAP3430_REV_ES2_1' undeclared (first use in this function) drivers/mfd/omap-usb-host.c:524:43: note: each undeclared identifier is reported only once for each function it appears in I'm assuming this has been spotted and I've missed the fix (just a missing include?). Secondly, I get the following when booted: ... [4.701232] devtmpfs: mounted [4.704772] Freeing init memory: 168K [4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling the overlay ... Which means that the display doesn't work. I am currently running 3.3, which works just fine and doesn't give an underflow. So was wondering what changes have been made that may affect this? There were problems in the 3.2-era due to runtime- PM causing a similar issue, has anything changed around here again? (as a side not: the panel I use is a custom 800x480 added to panel-generic-dpi.c, with board-overo.c updated to use it). Cheers, Joe Woodward -- 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
