Color lookup support for the atmel-hlcdc driver

[Peter Rosin]

On 2017-06-15 12:15, Boris Brezillon wrote:
> On Thu, 15 Jun 2017 11:54:29 +0200
> Peter Rosin <peda at axentia.se> wrote:
> 
>> On 2017-06-13 17:30, Boris Brezillon wrote:
>>> Hi Peter,
>>>
>>> On Tue, 13 Jun 2017 16:34:25 +0200
>>> Peter Rosin <peda at axentia.se> wrote:
>>>   
>>>> Hi!
>>>>
>>>> I need color lookup support for the atmel-hlcdc driver, and had a peek
>>>> at the code. I also looked at the drivers/gpu/drm/stm driver and came
>>>> up with the below diff. It compiles, but I have not booted it for the
>>>> simple reason that I can't imagine it will work.
>>>>
>>>> Sure, the code fills the clut registers in the .load_lut helper function
>>>> and I think it might even do the right thing when setting up the mode.
>>>> I'm less sure DMA will work correctly? It might, but I haven't looked at
>>>> it for many seconds...
>>>>
>>>> The big question is how the color info gets into the new clut array
>>>> I created in atmel_hlcdc_crtc? When I look at the stm driver, which does
>>>> it just like this AFAICT I just don't see it. So, what I'm I missing?  
>>>
>>> You should look at drm_atomic_helper_legacy_gamma_set() and its users.  
>>
>> Ok, thanks. I had a long look and could not get it to work at all.
> 
> Probably because you're trying to set this up through the emulated
> fbdev interface. The solution I proposed is supposed to be accessed
> through DRM ioctls.

Yes, that seems like the root cause of most of my troubles. But, the apps
I have seem to use the fbdev interface, and if the emulation is poorly
done, they won't work right...

>> So,
>> I did as below instead. However, there are a few glaring problems...
> 
> Well, I doubt this will be accepted. The fbdev emulation layer is
> supposed to be rather dumb, partly because DRM people want developers
> to switch to the DRM interface.

Sigh.

> Also note that I won't accept a solution that supports setting the LUT
> table only through the fbdev interface, so please try to make it work
> the DRM way before you even consider modifying the fbdev emulation
> layer.

Ok, I'll have another look. But to me, it's a maze...

>>
>> Something, somewhere, sets up default entries for the 16 first entries
>> of the palette and seem to expect them to stay as some kind of safe
>> basic palette, and my applications don't handle it too well. When they
>> want to draw black, they get a poisonous cyan/green instead etc. But
>> it's pretty close. Can anyone provide some clue as to how that is
>> supposed to be handled?
>>
>> Also, I had to change the second argument of the drm_fbdev_cma_init...
>> call at the end of atmel_hlcdc_dc.c:atmel_hlcdc_dc_load() from 24 to 8
>> to make it possible to set 8-modes. However, doing so fucks up 24-bit
>> modes. Which made me suspect that no non-24-bit mode work w/o my patch.
>> And I could indeed only get 24-bit modes to work, unless I changed this
>> value to 16. Then RGB565 works like a charm, but RGB888 don't. What's
>> up with that? Seems like a rather silly limitation, but it's perhaps
>> just a bug?
> 
> I'm pretty sure this is not a bug. AFAIR, prefered_bpp is used when you
> don't explicitly specify the video mode you want to use on the cmdline
> [1].
> 
> [1]http://elixir.free-electrons.com/linux/v3.11/source/Documentation/fb/modedb.txt
> 

(Why refer to v3.11 docs?)

Let's start with some basics, I tried to add

	video=atmel-hclcd-dc:1024x768-16

and

	video=atmel_hclcd_dc:1024x768-16

to the kernel cmdline of an unpatched linux-next kernel. No dice, I can
still only access RBG888. I'm obviously in need of some hand-holding...

How am I supposed to get a 16-bit mode?

Cheers,
peda