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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
