Re: [RFC v2 0/5] Common Display Framework

[Archit Taneja <archit@ti.com>]

On Monday 04 February 2013 03:35 PM, Marcus Lorentzon wrote:
> On 02/02/2013 12:35 AM, Laurent Pinchart wrote:
>> Hi Marcus,
>>
>> On Tuesday 08 January 2013 18:08:19 Marcus Lorentzon wrote:
>>> On 01/08/2013 05:36 PM, Tomasz Figa wrote:
>>>> On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote:
> [...]
>>>>> But it is not perfect. After a couple of products we realized that
>>>>> most
>>>>> panel drivers want an easy way to send a bunch of init commands in one
>>>>> go. So I think it should be an op for sending an array of commands at
>>>>> once. Something like
>>>>>
>>>>> struct dsi_cmd {
>>>>>        enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */
>>>>>        u8 cmd;
>>>>>        int dataLen;
>>>>>        u8 *data;
>>>>> }
>>>>>
>>>>> struct dsi_ops {
>>>>>        int dsi_write(source, int num_cmds, struct dsi_cmd *cmds);
>>>>>        ...
>>>>> }
>> Do you have DSI IP(s) that can handle a list of commands ? Or would
>> all DSI
>> transmitter drivers need to iterate over the commands manually ? In
>> the later
>> case a lower-level API might be easier to implement in DSI transmitter
>> drivers. Helper functions could provide the higher-level API you
>> proposed.
>
> The HW has a FIFO, so it can handle a few. Currently we use the low
> level type of call with one call per command. But we have found DSI
> command mode panels that don't accept any commands during the "update"
> (write start+continues). And so we must use a mutex/state machine to
> exclude any async calls to send DSI commands during update. But if you
> need to send more than one command per frame this will be hard (like
> CABC and backlight commands). It will be a ping pong between update and
> command calls. One option is to expose the mutex to the caller so it can
> make many calls before the next update grabs the mutex again.
> So maybe we could create a helper that handle the op for list of
> commands and another op for single command that you actually have to
> implement.

fyi, the DSI IP on OMAP3+ SoCs also has a FIFO. It can provide 
interrupts after each command is pushed out, and also when the FIFO gets 
empty(all commands are pushed). The only thing to take care is to not 
overflow FIFO.

DSI video mode panels generally have a few dozen internal registers 
which need to be configured via DSI commands. It's more fast(and 
convenient) to configure a handful of internal registers in one shot, 
and then perform a single BTA to know from the panel whether the 
commands were received correctly.

Regards,
Archit