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