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 the
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) ar
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 i
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'
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
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 devic
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
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 st
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 see
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 = bu
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 },
>>
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
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
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
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
>
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 i2ctran
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 atta
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 di
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) {
>>
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() ins
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 rea
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, somethi
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.
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 reg
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
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
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 i2
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 patc
2007/5/24, e9hack <[EMAIL PROTECTED]>:
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
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 (acc
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 nor
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
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
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 t
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 I
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
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 datashe
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
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_dat
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-Star
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?
A
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 r
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
44 matches
Mail list logo
