Here is patches to test:
http://git.linuxtv.org/anttip/media_tree.git/log/?h=af9035
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?
If it starts working then have to find out way to fix it properly so
that any earlier device didn't broke.
regards
Antti
On 04/09/2016 03:50 AM, Antti Palosaari wrote:
uh, how it could be so hard?
I just made few tests and found 3 ways to read it. OK, one is that
Alessandro already pointed out and I don't feel it correct. But those 2
are one for look. CMD_I2C_WR / CMD_I2C_RD with 1st priority, then
CMD_GENERIC_I2C_WR / CMD_GENERIC_I2C_RD....
{
u8 buf[MAX_XFER_SIZE];
struct usb_req req = {0, 0, 0, buf, 0, buf};
#if 0
req.cmd = CMD_GENERIC_I2C_WR;
req.wlen = 3 + 2;
req.rlen = 0;
buf[0] = 2; // write len
buf[1] = 0x02; /* I2C bus */ // NOK 3, 1, 0
buf[2] = 0x60 << 1; // I2C addr
buf[3] = 0xfb; /* reg addr MSB */
buf[4] = 0xd9; /* reg addr LSB */
ret = af9035_ctrl_msg(d, &req);
dev_dbg(&d->udev->dev, "1mxl5007t %02x\n", 0);
req.cmd = CMD_GENERIC_I2C_RD;
req.wlen = 3;
req.rlen = 1;
buf[0] = 1; // read len
buf[1] = 0x02; /* I2C bus */ // NOK 3, 1, 0
buf[2] = 0x60 << 1; // I2C addr
ret = af9035_ctrl_msg(d, &req);
dev_dbg(&d->udev->dev, "1mxl5007t %02x\n", buf[0]);
#endif
#if 0
req.cmd = CMD_I2C_RD;
req.wlen = 5;
req.rlen = 1;
buf[0] = 1; // read len
buf[1] = 0x60 << 1; // I2C addr
buf[2] = 2; /* reg addr len */
buf[3] = 0xfb; /* reg addr MSB */
buf[4] = 0xd9; /* reg addr LSB */
ret = af9035_ctrl_msg(d, &req);
dev_dbg(&d->udev->dev, "4mxl5007t %02x\n", buf[0]);
#endif
#if 1
req.cmd = CMD_I2C_WR;
req.wlen = 7;
req.rlen = 0;
buf[0] = 2; // write len msg[0].len;
buf[1] = 0x60 << 1; // I2C addr
buf[2] = 0x00; /* reg addr len */
buf[3] = 0x00; /* reg addr MSB */
buf[4] = 0x00; /* reg addr LSB */
buf[5] = 0xfb;
buf[6] = 0xd9;
ret = af9035_ctrl_msg(d, &req);
dev_dbg(&d->udev->dev, "9mxl5007t %02x\n", buf[0]);
req.cmd = CMD_I2C_RD;
req.wlen = 5;
req.rlen = 1;
buf[0] = 1; // read len
buf[1] = 0x60 << 1; // I2C addr
buf[2] = 0x00; /* reg addr len */
buf[3] = 0x00; /* reg addr MSB */
buf[4] = 0x00; /* reg addr LSB */
ret = af9035_ctrl_msg(d, &req);
dev_dbg(&d->udev->dev, "9mxl5007t %02x\n", buf[0]);
#endif
}
On 04/09/2016 02:59 AM, Alessandro Radicati wrote:
Jose, Antti,
The no_probe option or similar is the only fix I could find (in fact i
was going to propose a similar patch to what you have). I've tried
all combinations of firmware and also tried issuing the read command
to the tuner in different states (e.g. sleep, just after soft/hard
reset) to no avail. I've modified AverMedia's linux driver to probe
as well, and the same thing happens. I found the following behavior
in further testing:
- I can arbitrarily read as many bytes as I want from any valid
register and the tuner will continue responding until the af9035
issues the expected NAK to signal the end of the read so that the
mxl5007t can release the bus. The bus doesn't get released and it
stays stuck either high or low indefinitely so subsequent I2C commands
fail.
- Hard reset of the tuner by cycling af9035 GPIOH12 seems like the
only way to recover. So mxl5007t is probably at fault. Perhaps I2C
speed is too fast (SCL cycles at ~100KHz)? Faulty hardware design of
the usb stick?
- Doesn't seem like the OEM drivers ever issue I2C read commands.
Maybe it's a known issue to them.
I'm pretty much out of ideas to test. Suggestions are welcome.
Otherwise I'll try to push through a patch for just "no_probe".
Thanks,
Alessandro
On Sat, Apr 9, 2016 at 1:13 AM, Jose Alberto Reguero
<jareguero@xxxxxxxxxxxxxx> wrote:
I made a patch long time ago, but it was not accepted.
https://patchwork.linuxtv.org/patch/16242/
Jose Alberto
El 06/04/2016 01:00, Alessandro Radicati <alessandro@xxxxxxxxxxxx>
escribió:
On Wed, Apr 6, 2016 at 12:33 AM, Antti Palosaari <crope@xxxxxx> wrote:
I found one stick having AF9035 + MXL5007T. It is HP branded A867,
so it
should be similar. It seems to work all three 12.13.15.0 6.20.15.0
firmwares:
http://palosaari.fi/linux/v4l-dvb/firmware/af9035/
mxl5007t 5-0060: creating new instance
mxl5007t_get_chip_id: unknown rev (3f)
mxl5007t_get_chip_id: MxL5007T detected @ 5-0060
That is what AF9035 reports (with debug) as a chip version:
dvb_usb_af9035: prechip_version=00 chip_version=03 chip_type=3802
Do you have different chip version?
I have a Sky Italy DVB stick with the same chip version. I see that
you get the 0x3f response as well... that should be fixed by the I2C
patch I proposed. However, your stick seems to handle the read
properly and process subsequent I2C commands - something that doesn't
happen with mine. The vendor drivers in linux and windows never seem
issue the USB I2C commands to read from the tuner. I'll test with
other firmware versions to see if something changes.
Regards,
Alessandro
--
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
--
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
