linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: oliver+list@schinagl.nl (Oliver Schinagl)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-sunxi] [PATCHv2 1/6] i2c: sunxi: Add Allwinner A1X i2c driver
Date: Sun, 26 May 2013 21:01:53 +0200	[thread overview]
Message-ID: <51A25C21.2060700@schinagl.nl> (raw)
In-Reply-To: <20130526132120.GJ17847@lukather>

On 05/26/13 15:21, Maxime Ripard wrote:

>>> +static void sunxi_i2c_write(struct sunxi_i2c_dev *i2c_dev, u16 reg, u8 value)
>>> +{
>>> +	writel(value, i2c_dev->membase + reg);
>> Why writel? and why without (u32)value? I thought iowrite* where the
>> preferred calls and in this case, wouldn't we want writeb since
>> value is u8?
>
> You're right, value should be a u32 here, thanks for noticing.
>
> For the iowrite* vs write*, there's no consensus, and as such no
> preferred way. write* functions are doing an MMIO only access,
> while iowrite functions can do MMIO and port I/O accesses.
>
> Note that it doesn't change anything on ARM, since there's no port IO on
> ARM.
Ah I see, missinformation on my end. Sorry.

But why write 32 bits? The register is only 8 wide, with the rest being 
'reserved'. Then again, the register IS 32 bits wide and probably will 
haev 32 bits written to it? Correct?

>
>>> +}
>>> +
>>> +static u32 sunxi_i2c_read(struct sunxi_i2c_dev *i2c_dev, u16 reg)
>>> +{
>>> +	return readl(i2c_dev->membase + reg);
>> And here, readl does match the return of u32, but aren't we always
>> reading 8 bits since the TWI Data Register only uses the first 8
>> bits?
>> So wouldn't we want to return u8 and readb?
>
> They are meant to be general purpose accessors, so we shouldn't focus
> only on the data register.
Ah yes, of course.

>
>>
>>> +static int sunxi_i2c_probe(struct platform_device *pdev)
>>> +{
>>> +	struct sunxi_i2c_dev *i2c_dev;
>>> +	struct device_node *np;
>>> +	u32 freq, div_m, div_n;
>>> +	struct resource res;
>> I feel stupid for questioning this, since it only shows my lack of
>> knowledge, but
>> If you declare all the memory here, isn't all the data lost after
>> exiting the _probe function? we pass a pointer to this memory in the
>> of_address_to_resource() function so that fills it, right?
>>
>> Or does after devm_ioremap_resource it no longer matter, since that
>> function got what it needed and useless after?
>
> The struct resource is only there to declare the base address and the
> size of memory address. Once we have mapped it, we don't care about it
> anymore.
Thanks for clarifying that, I will adapt my driver to do the same.
>
> Maxime
>

  reply	other threads:[~2013-05-26 19:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-26 10:20 [PATCHv2 0/6] Add I2C support for Allwinner SoCs Maxime Ripard
2013-05-26 10:20 ` [PATCHv2 1/6] i2c: sunxi: Add Allwinner A1X i2c driver Maxime Ripard
2013-05-26 10:53   ` [linux-sunxi] " Oliver Schinagl
2013-05-26 13:21     ` Maxime Ripard
2013-05-26 19:01       ` Oliver Schinagl [this message]
2013-05-27 10:04         ` Maxime Ripard
2013-05-26 14:44     ` Tomasz Figa
2013-05-26 19:05       ` Oliver Schinagl
2013-05-26 14:38   ` Tomasz Figa
2013-05-26 17:00     ` Maxime Ripard
2013-05-26 10:20 ` [PATCHv2 2/6] ARM: sunxi: dt: Add i2c controller nodes to the DTSI Maxime Ripard
2013-05-26 10:20 ` [PATCHv2 3/6] ARM: sun4i: dt: Add i2c muxing options Maxime Ripard
2013-05-26 10:20 ` [PATCHv2 4/6] ARM: sun5i: " Maxime Ripard
2013-05-26 10:20 ` [PATCHv2 5/6] ARM: sun5i: olinuxino: Enable the i2c controllers Maxime Ripard
2013-05-26 10:20 ` [PATCHv2 6/6] ARM: sun4i: cubieboard: " Maxime Ripard

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=51A25C21.2060700@schinagl.nl \
    --to=oliver+list@schinagl.nl \
    --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;
as well as URLs for NNTP newsgroup(s).