From: Philippe CORNU <philippe.cornu@st.com>
To: Peter Rosin <peda@axentia.se>,
Yannick FERTRE <yannick.fertre@st.com>,
Benjamin Gaignard <benjamin.gaignard@linaro.org>,
Vincent ABRIOU <vincent.abriou@st.com>,
David Airlie <airlied@linux.ie>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Fabien DESSENNE <fabien.dessenne@st.com>,
Mickael REULIER <mickael.reulier@st.com>,
Gabriel FERNANDEZ <gabriel.fernandez@st.com>,
Ludovic BARRE <ludovic.barre@st.com>,
Alexandre TORGUE <alexandre.torgue@st.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>
Subject: Re: [PATCH] drm/stm: ltdc: add clut mode support
Date: Mon, 13 Nov 2017 10:40:56 +0000 [thread overview]
Message-ID: <0b4cac6d-6f3a-7f60-a2fb-873898c9d5e4@st.com> (raw)
In-Reply-To: <8c428fe5-836c-24b5-3d94-7a294db49bf4@axentia.se>
Hi Peter,
On 11/12/2017 01:31 PM, Peter Rosin wrote:
> On 2017-11-10 17:12, Philippe CORNU wrote:
>> Hi Peter,
>>
>> On 11/07/2017 05:34 PM, Peter Rosin wrote:
>>> On 2017-11-07 16:53, Philippe CORNU wrote:
>>>> + Peter
>>>>
>>>> Hi Peter,
>>>>
>>>> CLUT support on STM32 has been removed thanks to your clean up patch
>>>
>>> Support is a bit strong for what I thought was a dead function, or
>>> are you saying that it used to work before my series? Really sorry
>>> if that is the case!
>>
>> As I wrote in the previous related thread
>> (https://lists.freedesktop.org/archives/dri-devel/2017-June/145070.html),
>> STM32 chipsets supports 8-bit CLUT mode but this driver version does not
>> support it "yet"...
>>
>> So, no worry regarding your clean up, I gave you an "acked-by" for that : )
>
> Ok, good. Thanks for clearing that up!
>
>>>
>>> Anyway, the function I removed seemed to indicate that the hardware
>>> could handle a separate clut for each layer, but your new version
>>> does not. Why is that?
>>
>> Yes I confirm the clut support is available for each layer... but I
>> thought the gamma_lut was only at the crtc level, not at layer level...
>> Maybe I am wrong.
>> Moreover, small test applications I used play only with clut at crtc
>> level...
>>
>> Anyway, could you please help me to "find" a per-layer clut
>> implementation because when I read "crtc->state->gamma_lut->data" it
>> looks like gamma_lut is per crtc, not per plane...? or maybe I have to
>> add extra properties for that...
>
> I wasn't clear enough. Yes, there is to my knowledge only one clut,
> not one per plane. What I noticed was that the function I removed
> seemed to touch clut registers for multiple layers, but your new
> function appears to only touch registers for one layer. So, I
> wondered if the "one and only" clut needed to be copied to the
> registers for the other layers, or if the old dead code was simply
> confused. Clearer?
>
The old code was a generic helper function (ie. for all layers) but used
only for the 1st layer. So, we could say that "old dead code was simply
confused" :-)
When I put back the clut support in this patch, I decided to update only
the 1st layer (because there is no API for handling it on other layers).
I also decided to not re-use the former generic helper function as the
update loop is pretty small.
This patch offers the clut mode feature for fbdev (only one plane in
fbdev) and for drm (single plane for many use cases, 2nd plane being
used mostly for video...)
If tomorrow the API offers clut support per plane, the update loop will
be moved to the plane update function, means the generic helper function
will not be require anymore too.
Many thanks
Philippe :)
> Cheers.
> Peter
>
next prev parent reply other threads:[~2017-11-13 10:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-26 11:17 Philippe Cornu
2017-11-07 15:53 ` Philippe CORNU
2017-11-07 16:34 ` Peter Rosin
2017-11-10 16:12 ` Philippe CORNU
2017-11-12 12:31 ` Peter Rosin
2017-11-13 10:40 ` Philippe CORNU [this message]
2017-11-24 13:54 ` Philippe CORNU
2017-11-24 15:44 ` Peter Rosin
2018-01-09 11:28 ` Philippe CORNU
2018-01-09 11:56 ` Peter Rosin
2018-01-09 13:05 ` Benjamin Gaignard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0b4cac6d-6f3a-7f60-a2fb-873898c9d5e4@st.com \
--to=philippe.cornu@st.com \
--cc=airlied@linux.ie \
--cc=alexandre.torgue@st.com \
--cc=benjamin.gaignard@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=fabien.dessenne@st.com \
--cc=gabriel.fernandez@st.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ludovic.barre@st.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=mickael.reulier@st.com \
--cc=peda@axentia.se \
--cc=vincent.abriou@st.com \
--cc=yannick.fertre@st.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®