RE: DSS2: DSI: Check for TX FIFO emptiness when sending long packets
On Mon, 2010-07-26 at 13:18 +0200, ext Taneja, Archit wrote: I am not sure about this, it can be probably aligned with what is done in update_screen_l4(). I didn't exaclty get why you block till fifo_stalls 0xf and if we can have a similar reasoning for send_long? It would be great though if we can make dsi_vc_send_long() configurable enough to be actually used in dsi_update_screen_l4(), because they both have enough common code beween them. dsi_update_screen_l4() is quite old and unused code. I was mainly trying out how CPU can be used for DSI transfer, and trying out different ways to get better performance. You shouldn't look at it as any reference =). The 0xf was just a random number to abort the transfer if it didn't seem to go through. It worked for me, but probably won't work for other cases. I don't think that anyone really wants to update the screen with CPU, so the code could even be removed. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2: DSI: Check for TX FIFO emptiness when sending long packets
On Mon, 2010-07-26 at 11:28 +0200, ext Taneja, Archit wrote: Hi, I had a little query. We check for TX FIFO not full before sending a short packet in dsi_vc_send_short(), but we don't have a similar check in dsi_vc_send_long() before writing to the long packet header. There is a check of the static fifo size of the channel and the length of data we are pushing, but that does not reflect the state of the TX FIFO at that point of time. Do you think we should have a check using DSI_TX_FIFO_VC_EMPTINESS before writing to the long packet header? Yes, I think we should check that. Otherwise the transfer will break with DSI_VC_IRQ_FIFO_TX_OVF interrupt, although I think the lcd driver doesn't currently see this in any way. Although I'm not sure which would be better, return an error (EBUSY? EWOULDBLOCK?) if the FIFO cannot hold the whole message, or block until the FIFO can hold the whole message... Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: DSS2: DSI: Check for TX FIFO emptiness when sending long packets
-Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Monday, July 26, 2010 3:50 PM To: Taneja, Archit Cc: linux-omap@vger.kernel.org Subject: Re: DSS2: DSI: Check for TX FIFO emptiness when sending long packets On Mon, 2010-07-26 at 11:28 +0200, ext Taneja, Archit wrote: Hi, I had a little query. We check for TX FIFO not full before sending a short packet in dsi_vc_send_short(), but we don't have a similar check in dsi_vc_send_long() before writing to the long packet header. There is a check of the static fifo size of the channel and the length of data we are pushing, but that does not reflect the state of the TX FIFO at that point of time. Do you think we should have a check using DSI_TX_FIFO_VC_EMPTINESS before writing to the long packet header? Yes, I think we should check that. Otherwise the transfer will break with DSI_VC_IRQ_FIFO_TX_OVF interrupt, although I think the lcd driver doesn't currently see this in any way. Yes, the maximum number of bytes we send to taal panel using this fucntion is 5 bytes, hence it is quite unlikely to get a fifo overflow. Although I'm not sure which would be better, return an error (EBUSY? EWOULDBLOCK?) if the FIFO cannot hold the whole message, or block until the FIFO can hold the whole message... Tomi I am not sure about this, it can be probably aligned with what is done in update_screen_l4(). I didn't exaclty get why you block till fifo_stalls 0xf and if we can have a similar reasoning for send_long? It would be great though if we can make dsi_vc_send_long() configurable enough to be actually used in dsi_update_screen_l4(), because they both have enough common code beween them. Thanks, Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
