All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antti Palosaari <crope@iki.fi>
To: "Antti Seppälä" <a.seppala@gmail.com>
Cc: Benjamin Larsson <benjamin@southpole.se>, linux-media@vger.kernel.org
Subject: Re: [RFC PATCH] mn88472: reduce firmware download chunk size
Date: Thu, 19 Feb 2015 22:32:08 +0200	[thread overview]
Message-ID: <54E64848.6010009@iki.fi> (raw)
In-Reply-To: <CAKv9HNaWqs5MAEAfKKGOeNLY_brUaj4DGrE_t9EK2JzBjhFREg@mail.gmail.com>



On 02/19/2015 08:42 PM, Antti Seppälä wrote:
> On 19 February 2015 at 18:14, Antti Palosaari <crope@iki.fi> wrote:
>> On 02/19/2015 06:01 PM, Antti Seppälä wrote:
>>>
>>> On 19 February 2015 at 17:38, Antti Palosaari <crope@iki.fi> wrote:
>>>>
>>>> On 02/19/2015 12:21 PM, Antti Seppälä wrote:
>>>>>
>>>>> On 19 February 2015 at 11:43, Benjamin Larsson <benjamin@southpole.se>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On 2015-02-19 10:13, Antti Seppälä wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It seems that currently the firmware download on the mn88472 is
>>>>>>> somehow wrong for my Astrometa HD-901T2.
>>>>>>>
>>>>>>> Reducing the download chunk size (mn88472_config.i2c_wr_max) to 2
>>>>>>> makes the firmware download consistently succeed.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi, try adding the workaround patch I sent for this.
>>>>>>
>>>>>> [PATCH 1/3] rtl28xxu: lower the rc poll time to mitigate i2c transfer
>>>>>> errors
>>>>>>
>>>>>> I now see that it hasn't been merged. But I have been running with this
>>>>>> patch for a few months now without any major issues.
>>>>>>
>>>>>
>>>>> The patch really did improve firmware loading. Weird...
>>>>>
>>>>> Even with it I still get occasional i2c errors from r820t:
>>>>>
>>>>> [   15.874402] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=0a
>>>>> len=1:
>>>>> da
>>>>> [   81.455517] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00
>>>>> len=4: 69 74 e6 df
>>>>> [   99.949702] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00
>>>>> len=4: 69 74 e6 df
>>>>>
>>>>> These errors seem to appear more often if I'm reading the signal
>>>>> strength values using e.g. femon.
>>>>
>>>>
>>>>
>>>> Could you disable whole IR polling and test
>>>> modprobe dvb_usb_v2 disable_rc_polling=1
>>>>
>>>> It is funny that *increasing* RC polling makes things better, though...
>>>>
>>>
>>> Hi.
>>>
>>> I tried loading the driver with polling disabled and it fails completely:
>>>
>>> [ 5526.693563] mn88472 7-0018: downloading firmware from file
>>> 'dvb-demod-mn88472-02.fw'
>>> [ 5527.032209] mn88472 7-0018: firmware download failed=-32
>>> [ 5527.033864] rtl2832 7-0010: i2c reg write failed -32
>>> [ 5527.033874] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=05 len=1:
>>> 83
>>> [ 5527.036014] rtl2832 7-0010: i2c reg write failed -32
>>>
>>> I have no idea why the device behaves so counter-intuitively. Is there
>>> maybe some sorf of internal power-save mode the device enters when
>>> there is no i2c traffic for a while or something?
>>
>>
>> IR polling does not use I2C but some own commands. Could you make more
>> tests. Use rtl28xxu module parameter to disable IR and test. It will disable
>> both IR interrupts and polling. Then make some tests with different IR
>> polling intervals to see how it behaves.
>>
>
> Hi Antti.
>
> I made some further tests for you. Here are the results:
>
> dvb_usb_v2 disable_rc_polling=1: firmware download FAILED
>
> dvb_usb_rtl28xxu disable_rc=1: firmware download FAILED
>
> Then I restored the module parameters to default values and tested
> with various rc->interval values:
>
> interval = 800: firmware download FAILED
> interval = 600: firmware download FAILED
> interval = 400: firmware download FAILED
> interval = 300: firmware download SUCCESS but I2C errors from tuner
> could be sometimes observed
> interval = 200: firmware download SUCCESS
> interval = 100: firmware download SUCCESS
>
> So somehow higher rc polling rate makes the firmware download succeed.
> This could indeed be some locking/timing related bug.
>
> Please let me know if there is something else I can test.

Sure you could do. Play with I2C settings. Test few values to I2C bus 
speed / clock is good start. Put oscilloscope to I2C bus and look what 
there happens on error cases. There is also 2 different I2C commands, 
test if there is any difference. And so. Increasing polling interval to 
something between 250-300 does not sound very bad, though.

regards
Antti

-- 
http://palosaari.fi/

      reply	other threads:[~2015-02-19 20:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-19  9:13 [RFC PATCH] mn88472: reduce firmware download chunk size Antti Seppälä
2015-02-19  9:43 ` Benjamin Larsson
2015-02-19 10:21   ` Antti Seppälä
2015-02-19 11:53     ` Benjamin Larsson
2015-02-19 15:38     ` Antti Palosaari
2015-02-19 16:01       ` Antti Seppälä
2015-02-19 16:14         ` Antti Palosaari
2015-02-19 16:25           ` Steven Toth
2015-02-19 16:44             ` Antti Palosaari
2015-02-19 18:42           ` Antti Seppälä
2015-02-19 20:32             ` Antti Palosaari [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54E64848.6010009@iki.fi \
    --to=crope@iki.fi \
    --cc=a.seppala@gmail.com \
    --cc=benjamin@southpole.se \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.