On Thu, Nov 24, 2016 at 10:32:59PM +0200, Jyri Sarha wrote:
> On 11/24/16 14:56, Tomi Valkeinen wrote:
> > On 24/11/16 14:03, Jyri Sarha wrote:
> >
> >>> The suspend/resume you're talking there is the system suspend/resume.
> >>> That's quite different than the runtime suspend/resume, and they sho
On 11/24/16 14:56, Tomi Valkeinen wrote:
> On 24/11/16 14:03, Jyri Sarha wrote:
>
>>> The suspend/resume you're talking there is the system suspend/resume.
>>> That's quite different than the runtime suspend/resume, and they should
>>> do very different things.
>>>
>>> The current system suspend/r
On 24/11/16 14:03, Jyri Sarha wrote:
>> The suspend/resume you're talking there is the system suspend/resume.
>> That's quite different than the runtime suspend/resume, and they should
>> do very different things.
>>
>> The current system suspend/resume in tilcdc looks fine.
>>
>
> I don't undest
On 11/24/16 13:10, Tomi Valkeinen wrote:
> On 24/11/16 12:38, Jyri Sarha wrote:
>
>>> As long as the driver makes sure the device doesn't go to suspend (by
>>> having called pm_runtime_get).
>>
>> Runtime get has always been called when modeset_nofb() is called.
>
> Yes, runtime get is needed to
On 24/11/16 12:38, Jyri Sarha wrote:
>> As long as the driver makes sure the device doesn't go to suspend (by
>> having called pm_runtime_get).
>
> Runtime get has always been called when modeset_nofb() is called.
Yes, runtime get is needed to access the HW, but the question here was
"has runtim
On 11/24/16 12:25, Tomi Valkeinen wrote:
> On 24/11/16 12:03, Jyri Sarha wrote:
>> On 11/24/16 11:43, Tomi Valkeinen wrote:
>>> What is the difference? If mode changes, you need to disable and enable
>>> the crtc, right? What other cases there are to enable the display? After
>>> blank? Then the di
On 24/11/16 12:03, Jyri Sarha wrote:
> On 11/24/16 11:43, Tomi Valkeinen wrote:
>> What is the difference? If mode changes, you need to disable and enable
>> the crtc, right? What other cases there are to enable the display? After
>> blank? Then the display has been off, and I presume palette has t
On 11/24/16 11:43, Tomi Valkeinen wrote:
> What is the difference? If mode changes, you need to disable and enable
> the crtc, right? What other cases there are to enable the display? After
> blank? Then the display has been off, and I presume palette has to be
> loaded.
At the moment the palette
On 24/11/16 11:39, Jyri Sarha wrote:
> On 11/24/16 11:29, Tomi Valkeinen wrote:
>>> @@ -213,6 +274,13 @@ static void tilcdc_crtc_off(struct drm_crtc *crtc,
>>> bool shutdown)
__func__);
}
+ /*
+ * LCDC will not retain the palette when res
On 11/24/16 11:29, Tomi Valkeinen wrote:
>> @@ -213,6 +274,13 @@ static void tilcdc_crtc_off(struct drm_crtc *crtc, bool
>> shutdown)
>> >__func__);
>> >}
>> >
>> > + /*
>> > + * LCDC will not retain the palette when reset. Make sure it gets
>> > + * reloaded
On 22/11/16 18:54, Jyri Sarha wrote:
> From: Bartosz Golaszewski
>
> Revision 1 of the IP doesn't work if we don't load the palette (even
> if it's not used, which is the case for the RGB565 format).
>
> Add a function called from tilcdc_crtc_enable() which performs all
> required actions if we'
From: Bartosz Golaszewski
Revision 1 of the IP doesn't work if we don't load the palette (even
if it's not used, which is the case for the RGB565 format).
Add a function called from tilcdc_crtc_enable() which performs all
required actions if we're dealing with a rev1 chip.
Signed-off-by: Bartos
12 matches
Mail list logo
