public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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

  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