[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <91db8934-bfd6-8fc4-74e3-4844ef3bd3e7@ti.com>
Date: Fri, 30 Sep 2016 22:19:21 +0300
From: Peter Ujfalusi <peter.ujfalusi@...com>
To: Bartosz Golaszewski <bgolaszewski@...libre.com>
CC: Kevin Hilman <khilman@...libre.com>,
Michael Turquette <mturquette@...libre.com>,
Sekhar Nori <nsekhar@...com>, Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Russell King <linux@...linux.org.uk>,
LKML <linux-kernel@...r.kernel.org>,
arm-soc <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 6/6] ARM: da850: adjust memory settings for tilcdc
On 09/30/2016 06:06 PM, Bartosz Golaszewski wrote:
> 2016-09-30 14:59 GMT+02:00 Peter Ujfalusi <peter.ujfalusi@...com>:
>> On 09/29/16 19:31, Bartosz Golaszewski wrote:
>>> Default memory settings of da850 do not meet the throughput/latency
>>> requirements of tilcdc. This results in the image displayed being
>>> incorrect and the following warning being displayed by the LCDC
>>> drm driver:
>>>
>>> tilcdc da8xx_lcdc.0: tilcdc_crtc_irq(0x00000020): FIFO underfow
>>>
>>> Reconfigure the LCDC priority to the highest. This is a workaround
>>> for the da850-lcdk board which has the LCD controller enabled in
>>> the device tree, but a long-term, system-wide fix is needed for
>>> all davinci boards.
>>>
>>> This patch has been modified for mainline linux. It comes from a
>>> downstream TI release for da850[1].
>>>
>>> Original author: Vishwanathrao Badarkhe, Manish <manishv.b@...com>
>>>
>
> [snip]
>
>>
>> Is this safe to do for all da850 boards (to change PR_OLD_COUNT from 0xff to
>> 0x20)? Most probably it is, but this setting has nothing to do with LCDC.
>>
>> The whole priority configuration has nothing to do with the LCDC, it is a
>> system level priority.
>>
>> Now you have lowered the eDMA3_0-TPTC0/1 priority. Audio is serviced by
>> eDMA3_0-TPTC1. So are we going to see issues in audio if LCDC is taking the
>> highest priority?
>>
>
> Just ran a quick test with speaker-test -c2 -twav. Besides the fact
> that the left and right channels are inverted (I'm looking into that),
> I didn't notice any problems. Even at 1024x768 resolution, playing
> audio at the same time seems to work fine.
That's good to hear, but I think the priorities should be set:
LCDC and EDMA30TC1 to highest priority
EDMA30TC0 to priority 2
The 0TC0 is used by MMC and if you want to play a video you might need the
servicing TC to be higher priority then other masters.
If audio playback would trigger sync losts in lcdc then we might need to move
0TC1 to priority 1.
I agree that LCDC priority needs to be higher, but I do wonder why the default
(5) is not working and if it is not working why it is 5...
My guess is that the change in the PBBPR register is the one actually helping
here.
--
Péter
Powered by blists - more mailing lists