From: heiko@sntech.de (Heiko Stübner)
To: linux-arm-kernel@lists.infradead.org
Subject: Rockchip RK3188 I2C driver
Date: Tue, 15 Apr 2014 20:39:24 +0200 [thread overview]
Message-ID: <2863495.Gjdj6NpOm9@phil> (raw)
In-Reply-To: <20140415175504.GG12304@sirena.org.uk>
Am Dienstag, 15. April 2014, 18:55:04 schrieb Mark Brown:
> On Tue, Apr 15, 2014 at 07:25:28PM +0200, Heiko St?bner wrote:
> > Looking at the grf-handling of your i2c-driver [0] reminded me, that I'm
> > generally not sure how we should handle these registers. All of them use
> > what recently always got called a hiword-mask, with the upper 16 bit
> > indicating which lower 16 bit get changed.
> >
> > So while the
> >
> > regmap_write(grf, 4, BIT(11 + bus_idx) | BIT(27 + bus_idx));
> >
> > will most likely get the desired result at least once, I'm not sure how
> > this interacts with the caching regmap implements [and regmap in
> > general], as the bit(27 + bus_idx) is not a real value bit and will
> > always read 0.
>
> Can you be more specific what the wire format is here please? The above
> sounds like you're saying that the register value contains 32 bits, the
> top 16 being essentially an extension of the register field and the last
> 16 bits being a value but that just sounds like 16+n bit registers and
> 16 bit data so presumably isn't what you mean. Is there a datasheet
> somewhere?
ok, I'll try to explain better.
The register has 32 bit. The upper 16 bit [31:16] are a write enable mask, so
to change bit x, you also have to set (x+16) to 1.
There is a manual floating around the net, for example linked on [0] (the first
link to TRM v2.0) and in it for example on page 226 the GRF_SOC_CON2 register.
To cite the relevant bits 31:16:
bit0~bit15 write enable
When bit 16=1, bit 0 can be written by software .
When bit 16=0, bit 0 cannot be written by software;
When bit 17=1, bit 1 can be written by software .
When bit 17=0, bit 1 cannot be written by software;
...
And these "write enable" bits are reset to 0 after the write, so if you write
0x30001 you will get something like 0x1 on the next read, without the mask.
Thanks
Heiko
[0] http://hwswbits.blogspot.nl/2013/06/full-rk3066-technical-reference-manual.html
next prev parent reply other threads:[~2014-04-15 18:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-15 0:19 Rockchip RK3188 I2C driver Max Schwarz
2014-04-15 8:42 ` Heiko Stübner
2014-04-15 17:25 ` Heiko Stübner
2014-04-15 17:55 ` Mark Brown
2014-04-15 18:39 ` Heiko Stübner [this message]
2014-04-15 18:50 ` Mark Brown
2014-04-17 0:04 ` Max Schwarz
2014-04-17 13:27 ` Heiko Stübner
2014-04-17 23:10 ` Mark Brown
2014-04-17 18:38 ` Mark Brown
2014-04-17 23:06 ` Max Schwarz
2014-04-18 9:06 ` Heiko Stübner
2014-04-18 9:30 ` Max Schwarz
2014-04-18 10:03 ` Heiko Stübner
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=2863495.Gjdj6NpOm9@phil \
--to=heiko@sntech.de \
--cc=linux-arm-kernel@lists.infradead.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