[PATCH v3 1/7] drm: Add DSI bus infrastructure

[Bert Kenward]

On 11/18/2013 11:22, Thierry Reding wrote:
> On Thu, Nov 14, 2013 at 03:04:19PM +0000, Bert Kenward wrote:
> > #define DSI_WINDOW_VFP  (1 << 0)
> > #define DSI_WINDOW_ACT  (1 << 1)
> > #define DSI_WINDOW_VBP  (1 << 2)
> > #define DSI_WINDOW_VSY  (1 << 3)
> >
> > /**
> >  * struct dsi_msg - DSI command message
> >  * @channel: virtual channel to send the message to
> >  * @type: data ID of the message
> >  * @lp_mode: send in LP mode if non-zero
> 
> Perhaps a flags field would be more flexible here. I can easily imagine
> other I can imagine that other flags may be needed eventually.

Agreed. "TE synchronised" would be one such extra flag, for supporting command mode updates.

> >  * @window: video period when transfer is allowed - bitmask of
> DSI_WINDOW_*
> 
> I'm not sure if this is the right interface. What will happen for
> instance if the hardware doesn't support any of the bits in that mask?
> Perhaps a slightly better approach might be to expose the capabilities
> of the DSI host, so that the DSI core knows up front which windows can
> be used.

Exposing the capabilities seems like the smart thing to do, certainly - but you'd still need a way to specify which of those capabilities you want to use for each transfer.

I'd suggest that hardware would ignore bits that it couldn't support - in the limit, hardware that has no way to choose when to send a command during video would ignore this completely. I realise that could well cause confusion when trying to work out why a particularly display is misbehaving when you think you're sending commands at the right time.

Bert.

-- 
Bert Kenward
Software Engineer
Broadcom Mobile Platform Solutions
Cambridge, UK