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 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.