On Wed, 6 Jun 2007, Oliver Endriss wrote:
e9hack wrote:
Trent Piepho wrote:
Does the stv0297 require that no other i2c traffic, to a different device,
appear between the write and the read? Something like:
S stv_addr_W A reg_addr A P
S tuner_addr_W A tuner_data1 A tuner_data2
Johannes Stezenbach writes:
What Jean writes only applies if you have a struct i2c_client
and i2c_driver to work with. the you can do lokcing in the
i2c_driver.
But we don't, IIRC because of problems with bus probing
done yb the i2c-core.
Not having an i2c_client is also the reason
On Tue, Jun 05, 2007 at 09:16:26PM -0700, Trent Piepho wrote:
On Sat, 2 Jun 2007, Johannes Stezenbach wrote:
Then I2C_M_STOP still makes sense, but the patch should document
that it's used only a workaround for broken hardware.
Well, I tried but no one on the i2c list liked the
Trent Piepho wrote:
Does the stv0297 require that no other i2c traffic, to a different device,
appear between the write and the read? Something like:
S stv_addr_W A reg_addr A P
S tuner_addr_W A tuner_data1 A tuner_data2 A P
S stv_addr_R A reg_data NA P
Will the i2c message to the
Trent Piepho wrote:
I'm still unclear on exactly what the stv0297 requires. The datasheet says
one can't use a repeated start, but must have a stop between a read and a
write. That's simple enough, but has anyone actually verified that the
datasheet is really correct? I know many datasheets
e9hack wrote:
Trent Piepho wrote:
Does the stv0297 require that no other i2c traffic, to a different device,
appear between the write and the read? Something like:
S stv_addr_W A reg_addr A P
S tuner_addr_W A tuner_data1 A tuner_data2 A P
S stv_addr_R A reg_data NA P
Will
Oliver Endriss wrote:
Could you please test whether this works:
S stv_addr_W A reg_addr A Sr stv_addr_R A reg_data NA P
It doesn't work.
The following does work, if the Stop-Start isn't located in the same upload
command of the saa7146:
S stv_addr_W A reg_addr A P S stv_addr_R A reg_data
e9hack wrote:
Oliver Endriss wrote:
Could you please test whether this works:
S stv_addr_W A reg_addr A Sr stv_addr_R A reg_data NA P
It doesn't work.
Hm, I wonder how stv0297_readregsI() in stv0297_cs2.c could ever work.
Any idea?
The following does work, if the Stop-Start isn't
Oliver Endriss wrote:
e9hack wrote:
Oliver Endriss wrote:
Could you please test whether this works:
S stv_addr_W A reg_addr A Sr stv_addr_R A reg_data NA P
It doesn't work.
Hm, I wonder how stv0297_readregsI() in stv0297_cs2.c could ever work.
Any idea?
Answering myself:
On Sat, 2 Jun 2007, Johannes Stezenbach wrote:
On Fri, Jun 01, 2007, Oliver Endriss wrote:
Any news about this?
Imho Trent's patch to add I2C_M_STOP makes sense.
According to the stv0299 datasheet, the stv0299 requires this STOP
condition, too. This chip seems to be more tolerant
Manu Abraham wrote:
On 6/2/07, Johannes Stezenbach [EMAIL PROTECTED] wrote:
On Fri, Jun 01, 2007, Oliver Endriss wrote:
e9hack wrote:
Manu Abraham wrote:
e9hack wrote:
Manu Abraham wrote:
Trent Piepho wrote:
What the stv0297 wants is:
S Addr Wr [A] Comm [A] P S
On Fri, Jun 01, 2007, Oliver Endriss wrote:
e9hack wrote:
Manu Abraham wrote:
e9hack wrote:
Manu Abraham wrote:
Trent Piepho wrote:
What the stv0297 wants is:
S Addr Wr [A] Comm [A] P S Addr Rd [A] [Data] NA P
The STV0297 is just a normal demod like the others, nothing
e9hack wrote:
Manu Abraham wrote:
e9hack wrote:
Manu Abraham wrote:
Trent Piepho wrote:
What the stv0297 wants is:
S Addr Wr [A] Comm [A] P S Addr Rd [A] [Data] NA P
The STV0297 is just a normal demod like the others, nothing special
about it (according to ST). Well of course
Manu Abraham wrote:
Johannes Stezenbach wrote:
On Sun, May 20, 2007, e9hack wrote:
With the attached patch, it works for the stv0297 functions. It
doesn't solve the problem, why I've wrote the initial patch. I need a
dump from the registers of the stv0297. I've attach a second patch.
Johannes Stezenbach wrote:
On Sun, May 20, 2007, e9hack wrote:
With the attached patch, it works for the stv0297 functions. It
doesn't solve the problem, why I've wrote the initial patch. I need a
dump from the registers of the stv0297. I've attach a second patch.
stv0297_attach() inserts a
Manu Abraham wrote:
I have been looking at the STV0297D/E datasheets specifically to check
this issue (and i don't see any differences than how it is potentially'
differently from other devices):
I didn't say, that something is implemented differently. I said, something
(random address read)
e9hack wrote:
Manu Abraham wrote:
I have been looking at the STV0297D/E datasheets specifically to check
this issue (and i don't see any differences than how it is potentially'
differently from other devices):
I didn't say, that something is implemented differently. I said, something
On Wed, 23 May 2007, Manu Abraham wrote:
Johannes Stezenbach wrote:
On Sun, May 20, 2007, e9hack wrote:
With the attached patch, it works for the stv0297 functions. It
doesn't solve the problem, why I've wrote the initial patch. I need a
dump from the registers of the stv0297. I've attach
Trent Piepho wrote:
On Wed, 23 May 2007, Manu Abraham wrote:
Johannes Stezenbach wrote:
On Sun, May 20, 2007, e9hack wrote:
With the attached patch, it works for the stv0297 functions. It
doesn't solve the problem, why I've wrote the initial patch. I need a
dump from the registers of the
Manu Abraham wrote:
Trent Piepho wrote:
What the stv0297 wants is:
S Addr Wr [A] Comm [A] P S Addr Rd [A] [Data] NA P
The STV0297 is just a normal demod like the others, nothing special
about it (according to ST). Well of course i2cdump can be wrong.
The stv0297 cannot handle a repeated
e9hack wrote:
Manu Abraham wrote:
Trent Piepho wrote:
What the stv0297 wants is:
S Addr Wr [A] Comm [A] P S Addr Rd [A] [Data] NA P
The STV0297 is just a normal demod like the others, nothing special
about it (according to ST). Well of course i2cdump can be wrong.
The stv0297 cannot
Manu Abraham wrote:
e9hack wrote:
Manu Abraham wrote:
Trent Piepho wrote:
What the stv0297 wants is:
S Addr Wr [A] Comm [A] P S Addr Rd [A] [Data] NA P
The STV0297 is just a normal demod like the others, nothing special
about it (according to ST). Well of course i2cdump can be wrong.
Trent Piepho wrote:
On Sun, 20 May 2007, Manu Abraham wrote:
Don't you think that the STV0297 (the obvious case that i looked at was
b2c2 flexcop) B2C2 cablestar.
In this case looking at flexcop-i2c.c flexcop_i2c_read4(foobar)
if ((ret = flexcop_i2c_operation(fc, r100)) != 0) {
/* The
On Sat, May 19, 2007, Trent Piepho wrote:
I've written a patch that implements I2C_M_STOP. It would be used like this:
char buf1[2] = {0x0b,0x3c}, buf2[1];
struct i2c_msg msgs[2] = {
{ .addr = 0x61, .buf = buf1, .len = 2, .flags = I2C_M_STOP },
{ .addr = 0x61, .buf = buf2,
Johannes Stezenbach wrote:
On Sat, May 19, 2007, Trent Piepho wrote:
I've written a patch that implements I2C_M_STOP. It would be used like this:
char buf1[2] = {0x0b,0x3c}, buf2[1];
struct i2c_msg msgs[2] = {
{ .addr = 0x61, .buf = buf1, .len = 2, .flags = I2C_M_STOP },
{ .addr
Trent Piepho wrote:
On Sat, 19 May 2007, e9hack wrote:
Trent Piepho wrote:
On Fri, 18 May 2007, Johannes Stezenbach wrote:
Or you could propose a change to i2c-core to add
a I2C_M_STOP flag (analogous to I2C_M_NOSTART), which
then would have to be implemented by all i2c bus drivers.
It
Manu Abraham wrote:
Trent Piepho wrote:
On Sat, 19 May 2007, e9hack wrote:
Trent Piepho wrote:
On Fri, 18 May 2007, Johannes Stezenbach wrote:
Or you could propose a change to i2c-core to add
a I2C_M_STOP flag (analogous to I2C_M_NOSTART), which
then would have to be implemented by all i2c
Trent Piepho wrote:
This would work for stv0297, wouldn't it?
diff -r 56b4c3e8f350 drivers/i2c/i2c-core.c
--- a/drivers/i2c/i2c-core.c Sat May 19 05:00:32 2007 +
+++ b/drivers/i2c/i2c-core.c Sat May 19 17:35:19 2007
e9hack wrote:
Manu Abraham wrote:
Trent Piepho wrote:
On Sat, 19 May 2007, e9hack wrote:
Trent Piepho wrote:
On Fri, 18 May 2007, Johannes Stezenbach wrote:
Or you could propose a change to i2c-core to add
a I2C_M_STOP flag (analogous to I2C_M_NOSTART), which
then would have to be
On Sun, May 20, 2007, e9hack wrote:
With the attached patch, it works for the stv0297 functions. It
doesn't solve the problem, why I've wrote the initial patch. I need a
dump from the registers of the stv0297. I've attach a second patch.
stv0297_attach() inserts a wrapper between
On Sun, 20 May 2007, e9hack wrote:
Trent Piepho wrote:
This would work for stv0297, wouldn't it?
With the attached patch, it works for the stv0297 functions. It doesn't solve
the problem, why I've wrote the initial
patch. I need a dump from the registers of the stv0297. I've attach a
On Sun, 20 May 2007, Manu Abraham wrote:
Don't you think that the STV0297 (the obvious case that i looked at was
b2c2 flexcop) B2C2 cablestar.
In this case looking at flexcop-i2c.c flexcop_i2c_read4(foobar)
if ((ret = flexcop_i2c_operation(fc, r100)) != 0) {
/* The cablestar needs a
On Fri, 18 May 2007, Johannes Stezenbach wrote:
On Fri, May 18, 2007 at 04:48:13PM +0200, e9hack wrote:
Johannes Stezenbach wrote:
According to linux/Documentation/i2c/i2c-protocol.txt the correct
way to get a STOP condition between two I2C messages is send them
in seperate I2C
Trent Piepho wrote:
On Fri, 18 May 2007, Johannes Stezenbach wrote:
Or you could propose a change to i2c-core to add
a I2C_M_STOP flag (analogous to I2C_M_NOSTART), which
then would have to be implemented by all i2c bus drivers.
It seems like this is the only way to send multiple stops in a
On Sat, 19 May 2007, e9hack wrote:
Trent Piepho wrote:
On Fri, 18 May 2007, Johannes Stezenbach wrote:
Or you could propose a change to i2c-core to add
a I2C_M_STOP flag (analogous to I2C_M_NOSTART), which
then would have to be implemented by all i2c bus drivers.
It seems like this is
Hi,
the stv0297 doesn't understand the repeated start condition on the i2c-bus from
a saa7146. The current frontend driver
(stv0297.c) handles this problem by splitting the read request into a write and
a read request. Other applications (e.g.
i2cdump) are not able to read the registers from
On Fri, May 18, 2007, e9hack wrote:
the stv0297 doesn't understand the repeated start condition on the
i2c-bus from a saa7146. The current frontend driver (stv0297.c)
handles this problem by splitting the read request into a write and a
read request. Other applications (e.g. i2cdump) are
Johannes Stezenbach wrote:
According to linux/Documentation/i2c/i2c-protocol.txt the correct
way to get a STOP condition between two I2C messages is send them
in seperate I2C transactions.
I don't find this description in i2c-protocol. IMHO, it isn't possible to split
a read request into a
On Fri, May 18, 2007 at 04:48:13PM +0200, e9hack wrote:
Johannes Stezenbach wrote:
According to linux/Documentation/i2c/i2c-protocol.txt the correct
way to get a STOP condition between two I2C messages is send them
in seperate I2C transactions.
I don't find this description in
Johannes Stezenbach wrote:
On Fri, May 18, 2007 at 04:48:13PM +0200, e9hack wrote:
Johannes Stezenbach wrote:
According to linux/Documentation/i2c/i2c-protocol.txt the correct
way to get a STOP condition between two I2C messages is send them
in seperate I2C transactions.
I don't find this
On Fri, May 18, 2007, Manu Abraham wrote:
Johannes Stezenbach wrote:
On Fri, May 18, 2007 at 04:48:13PM +0200, e9hack wrote:
IMHO, it isn't possible
to split a read request into a single write and a single read request
outside of the core device. The device must be locked during both
Johannes Stezenbach wrote:
On Fri, May 18, 2007, Manu Abraham wrote:
Johannes Stezenbach wrote:
On Fri, May 18, 2007 at 04:48:13PM +0200, e9hack wrote:
IMHO, it isn't possible
to split a read request into a single write and a single read request
outside of the core device. The device must
42 matches
Mail list logo
