From: Benjamin Larsson <benjamin@southpole.se>
To: Antti Palosaari <crope@iki.fi>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH 2/2] mn88472: fix firmware loading
Date: Mon, 08 Dec 2014 19:54:11 +0100 [thread overview]
Message-ID: <5485F3D3.50403@southpole.se> (raw)
In-Reply-To: <5485E3E4.80005@iki.fi>
On 12/08/2014 06:46 PM, Antti Palosaari wrote:
> Hello!
> [...]
>> regmap_bulk_write(): Write multiple registers to the device
>>
>> In this case we want to write multiple bytes to the same register. So I
>> think that my patch is correct in principle.
>
> You haven't make any test whether it is possible to write that
> firmware in a large chunks *or* writing one byte (smallest possible
> ~chuck) at the time? I think it does not matter. I suspect you could
> even download whole firmware as one go - but rtl2832p I2C adapter does
> support only 22 bytes on one xfer.
>
> Even those are written to one register, chip knows how many bytes one
> message has and could increase its internal address counter. That is
> usually called register address auto-increment.
>
> A) writing:
> f6 00
> f6 01
> f6 02
> f6 03
> f6 04
> f6 05
> f6 06
> f6 07
> f6 08
> f6 09
>
> B) writing:
> f6 00 01 02 03 04
> f6 05 06 07 08 09
>
> will likely end up same. B is better as only 2 xfers are done - much
> less IO.
>
> regards
> Antti
>
Hello Antti.
I have now tried the following patch on top of my load defaults patch.
index a7d35bb..fd9796d
--- a/drivers/staging/media/mn88472/mn88472.c
+++ b/drivers/staging/media/mn88472/mn88472.c
@@ -467,7 +467,7 @@ static int mn88472_probe(struct i2c_client *client,
goto err;
}
- dev->i2c_wr_max = config->i2c_wr_max;
+ dev->i2c_wr_max = 2;
dev->xtal = config->xtal;
dev->ts_mode = config->ts_mode;
dev->ts_clock = config->ts_clock;
With this patch I get data, without it I don't. Based on that info I
started testing different i2c wr max values.
When I got to 18 it stopped working. So it seams like both you and me
where right. We can write several
values at once but only a maximum of 16.
I have a patch that adds parity check of the firmware and all the times
the check succeeded but the demodulator
didn't deliver data. So I guess that the parity checker is before the 16
byte buffer and if you write more the data is
just ignored.
I will send an updated patch based on this.
MvH
Benjamin Larsson
next prev parent reply other threads:[~2014-12-08 18:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-07 22:10 [PATCH 1/2] mn88472: load demodulator register defaults Benjamin Larsson
2014-12-07 22:10 ` [PATCH 2/2] mn88472: fix firmware loading Benjamin Larsson
2014-12-07 22:36 ` Antti Palosaari
2014-12-08 11:12 ` Benjamin Larsson
2014-12-08 17:35 ` Antti Palosaari
2014-12-08 16:04 ` Benjamin Larsson
2014-12-08 17:46 ` Antti Palosaari
2014-12-08 18:54 ` Benjamin Larsson [this message]
2014-12-07 22:25 ` [PATCH 1/2] mn88472: load demodulator register defaults Antti Palosaari
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=5485F3D3.50403@southpole.se \
--to=benjamin@southpole.se \
--cc=crope@iki.fi \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox