On 04/09/2016 04:52 AM, Alessandro Radicati wrote:
On Sat, Apr 9, 2016 at 3:22 AM, Antti Palosaari <crope@xxxxxx> wrote:
Here is patches to test:
http://git.linuxtv.org/anttip/media_tree.git/log/?h=af9035
I've done this already in my testing, and it works for getting a
correct chip_id response, but only because it's avoiding the issue
with the write/read case in the af9035 driver. Don't have an
af9015... perhaps there's a similar issue with that code or we are
dealing with two separate issues since af9035 never does a repeated
start?
I am pretty sure mxl5007t requires stop between read and write. Usually
chips are not caring too much if it is repeated start or not, whilst
datasheets are often register read is S Wr S Rw P.
Even af9035 i2c adapter implementation implements repeated start wrong,
I would not like to add anymore hacks there. It is currently ugly and
complex as hell. I should be re-written totally in any case. Those tuner
I2C adapters should be moved to demod. Demod has 1 I2C adapter.
USB-bridge has 2 adapters, one for each demod.
I have to find out af9015 datasheets and check how it is there. But I
still remember one case where I implemented one FX2 firmware and that
same issues raises there as well.
After that both af9015+mxl5007t and af9035+mxl5007t started working. Earlier
both were returning bogus values for chip id read.
Also I am interested to known which kind of communication there is actually
seen on I2C bus?
With this or the patch I proposed, you see exactly what you expect on
the I2C bus with repeated stops, as detailed in my previous mails.
So it is good?
If it starts working then have to find out way to fix it properly so that
any earlier device didn't broke.
I hope that by now I've made abundantly clear that my mxl5007t locks
up after *any* read. It doesn't matter if we are reading the correct
register after any of the proposed patches.
So it still locks up after any read after the chip id read? And does not
work then? On my devices I can add multiple mxl5007t_get_chip_id() calls
and all are returning correct values.
Could you test what happens if you use that CMD_GENERIC_I2C_WR +
CMD_GENERIC_I2C_RD ? I suspect it is lower level I2C xfer than those
CMD_I2C_RD + CMD_I2C_WR, which are likely somehow handled by demod core.
regards
Antti
--
http://palosaari.fi/
--
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
