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