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.