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

[Bert Kenward]

On 11/14/2013 14:16, Andrzej Hajda wrote:
> On 11/13/2013 10:38 PM, Thierry Reding wrote:
> >  Furthermore I think if we kept the transfer function proposed
> > in my patch should make it easier to address Bert's comments from your
> > posting.
> I am not sure which part of Barts comment you are addressing.
> Anyway I also prefer passing struct and returning ssize_t.
> I am not sure about splitting type and channel but this seems to be a
> minor detail.

Most of the comments I made about Andrzej's patch from last month apply here, and would result in extensions to struct dsi_msg. Some means of choosing whether the transfer should be in HS or LP mode is necessary. For video mode panels some means of specifying a period (VFP, VBP, etc) for sending the transfer is needed. Perhaps struct dsi_msg should include:

#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
 * @window: video period when transfer is allowed - bitmask of DSI_WINDOW_*
 * @tx_len: length of transmission buffer
 * @tx: transmission buffer
 * @rx_len: length of reception buffer
 * @rx: reception buffer
 */
struct dsi_msg {
	u8 channel;
	u8 type;
	u8 lp_mode;
	u8 window;

	size_t tx_len;
	void *tx;

	size_t rx_len;
	void *rx;
};

The ability to specify synchronisation with a tearing effect control signal for a command mode panel is obviously important. It's somewhat analogous to the "window" option for video mode.

They're little used, but a mechanism for sending triggers should be included. They're probably sufficiently different that it should be a different op.

All the best,

Bert.

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