* DSS2: DSI: Check for TX FIFO emptiness when sending long packets
@ 2010-07-26 9:28 Taneja, Archit
2010-07-26 10:20 ` Tomi Valkeinen
0 siblings, 1 reply; 4+ messages in thread
From: Taneja, Archit @ 2010-07-26 9:28 UTC (permalink / raw)
To: tomi.valkeinen@nokia.com; +Cc: linux-omap@vger.kernel.org
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?
Thanks,
Archit
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: DSS2: DSI: Check for TX FIFO emptiness when sending long packets
2010-07-26 9:28 DSS2: DSI: Check for TX FIFO emptiness when sending long packets Taneja, Archit
@ 2010-07-26 10:20 ` Tomi Valkeinen
2010-07-26 11:18 ` Taneja, Archit
0 siblings, 1 reply; 4+ messages in thread
From: Tomi Valkeinen @ 2010-07-26 10:20 UTC (permalink / raw)
To: ext Taneja, Archit; +Cc: linux-omap@vger.kernel.org
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: DSS2: DSI: Check for TX FIFO emptiness when sending long packets
2010-07-26 10:20 ` Tomi Valkeinen
@ 2010-07-26 11:18 ` Taneja, Archit
2010-07-27 7:16 ` Tomi Valkeinen
0 siblings, 1 reply; 4+ messages in thread
From: Taneja, Archit @ 2010-07-26 11:18 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap@vger.kernel.org
> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@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 > 0xfffff 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: DSS2: DSI: Check for TX FIFO emptiness when sending long packets
2010-07-26 11:18 ` Taneja, Archit
@ 2010-07-27 7:16 ` Tomi Valkeinen
0 siblings, 0 replies; 4+ messages in thread
From: Tomi Valkeinen @ 2010-07-27 7:16 UTC (permalink / raw)
To: ext Taneja, Archit; +Cc: linux-omap@vger.kernel.org
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 > 0xfffff 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 0xfffff 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-07-27 7:17 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-07-26 9:28 DSS2: DSI: Check for TX FIFO emptiness when sending long packets Taneja, Archit
2010-07-26 10:20 ` Tomi Valkeinen
2010-07-26 11:18 ` Taneja, Archit
2010-07-27 7:16 ` Tomi Valkeinen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).