Re: [PATCH 2/3] mn88472: add work around for failing firmware loading

[Benjamin Larsson]

On 12/21/2015 03:52 AM, Antti Palosaari wrote:

Hello
I am not sure if problem is I2C adapter/bus or that demodulator I2C
slave. If it is demod, then that workaround is correct place, but if it
is not, then that is wrong and I2C adapter repeating logic should be used.

I did some testing again... Loading mn88472 firmware 1000 times, it failed:
61 times RC polling disabled
68 times RC polling enabled
83 times RC polling enabled, but repeated failed message due to that patch


At least this confirms there is an issue.



I don't want apply that patch until I find some time myself to examine
that problem - or someone else does some study to point out whats wrong.
There is many things to test in order to get better understanding.

regards
Antti


I do have other hardware with with a mn88472 demod on it. A CX23102 
bridge and a dibcom (Xbox one tuner). I think that running the same test 
on those hardware will tell where the issue is.


I know that Olli have worked on the Xbox one tuner, do you have any 
support patches that could help testing this? And did you observe any 
issues with the mn88472 demod when working on the Xbox one tuner ?


I am quite sure that I saw this on the mn88473 version of this hardware 
also. I just haven't had the time to test it. But I will postpone that 
until the tests on the other bridges are done.


MvH
Benjamin Larsson
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] mn88472: add work around for failing firmware loading

[Antti Palosaari]

Hello
I am not sure if problem is I2C adapter/bus or that demodulator I2C 
slave. If it is demod, then that workaround is correct place, but if it 
is not, then that is wrong and I2C adapter repeating logic should be used.


I did some testing again... Loading mn88472 firmware 1000 times, it failed:
61 times RC polling disabled
68 times RC polling enabled
83 times RC polling enabled, but repeated failed message due to that patch

I don't want apply that patch until I find some time myself to examine 
that problem - or someone else does some study to point out whats wrong. 
There is many things to test in order to get better understanding.


regards
Antti

On 11/29/2015 04:10 AM, Benjamin Larsson wrote:

Sometimes the firmware fails to load because of an i2c error.
Work around that by adding retry logic. This kind of logic
also exist in the binary driver and failures have been observed
there also. Thus this seems to be a property of the hardware
and a fix like this is needed.

Signed-off-by: Benjamin Larsson 
---
  drivers/staging/media/mn88472/mn88472.c | 15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/mn88472/mn88472.c 
b/drivers/staging/media/mn88472/mn88472.c
index cf2e96b..80c5807 100644
--- a/drivers/staging/media/mn88472/mn88472.c
+++ b/drivers/staging/media/mn88472/mn88472.c
@@ -282,7 +282,7 @@ static int mn88472_init(struct dvb_frontend *fe)
int ret, len, remaining;
const struct firmware *fw = NULL;
u8 *fw_file = MN88472_FIRMWARE;
-   unsigned int tmp;
+   unsigned int tmp, retry_cnt;

dev_dbg(>dev, "\n");

@@ -330,9 +330,22 @@ static int mn88472_init(struct dvb_frontend *fe)
if (len > (dev->i2c_wr_max - 1))
len = dev->i2c_wr_max - 1;

+   /* I2C transfers during firmware load might fail sometimes,
+* just retry in that case. 4 consecutive failures have
+* been observed thus a retry limit of 20 is used.
+*/
+   retry_cnt = 20;
+retry:
ret = regmap_bulk_write(dev->regmap[0], 0xf6,
>data[fw->size - remaining], len);
if (ret) {
+   if (retry_cnt) {
+   dev_dbg(>dev,
+   "i2c error, retry %d triggered\n", retry_cnt);
+   retry_cnt--;
+   usleep_range(200, 1);
+   goto retry;
+   }
dev_err(>dev,
"firmware download failed=%d\n", ret);
goto firmware_release;



--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html