Re: Do any drivers access the cx25840 module in an atomic context?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 18 Jan 2010, Andy Walls wrote:

> On Mon, 2010-01-18 at 14:18 -0600, Mike Isely wrote:
> > On Mon, 18 Jan 2010, Andy Walls wrote:> 
> > > Any definitive confirmation anyone can give on any of these drivers
> > > would be helpful and would save me some time.
> 
> 
> Mike,
> 
> Great!  Thank you for the answers.

You're welcome.


> 
> If you would indulge one more (compound) question:
> 
> Looking at the I2C master implementation in pvrusb2, it looks like it
> would be OK for me to combine the i2c_master_write() and
> i2c_master_read() in cx25840_read() into a single 2 "msg" i2c_transfer()
> without the pvrusb2 driver having a problem.
> 
> a. Is that correct?

Yes, that is correct.


> b. Is there a limit on the combined payload, such that a the
> cx25840_read4() would not work as a combined i2c_transfer() ?

There is an overall limit on the size of the I2C transfer.  This is due 
to the underlying firmware on pvrusb2-support devices.  Essentially the 
entire outgoing transfer plus a few bytes of overhead has to fit inside 
a single 64 byte URB.  This also limits the atomic read size to roughly 
64 bytes as well (the URB size on the returned data).  You should be 
able to reliably write up to 48 bytes at a time, perhaps even a little 
more.

This issue caused a problem for the cx25840 module a few years back when 
it used to do firmware downloads with large (e.g. 1024 byte or larger) 
single I2C transfers.  Hans told me then it was that large because it 
allowed the ivtv driver to run more efficiently, but we cut it back to 
48 bytes since it triggered problems with I2C adapters (e.g. pvrusb2) 
which could not handle such larger transfers at all.

The pvrusb2 driver's I2C adapter is really just a proxy for the I2C 
implementation in the device at the far end of the USB cable.  So it 
works at a higher level than one might normally expect - it operates at 
the transfer level, no bit-banging.  The communications protocol 
required by the hardware limits the I2C transfers to be either a write 
of some size, or an atomic write followed by a read of various sizes.  
The pvrusb2 implementation looks at the incoming transfers and tries to 
map them as best it can over what the device protocol allows.  
Generally this means that if it is possible it will do the right thing.  
In the specific case you mentioned above, the result should in fact be 
exactly what you need.  (I'm saying that without having looked at that 
area of code for quite a while, but it's what I remember being in my 
head when I did that part..)

  -Mike


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux