[linux-sunxi] Re: [PATCH] i2c: mv64xxx: The n clockdiv factor is 0 based on sunxi SoCs

2015-11-30 Thread Wolfram Sang
On Mon, Nov 30, 2015 at 02:51:41PM +0100, Wolfram Sang wrote:
> On Sun, Sep 27, 2015 at 04:57:08PM +0200, Hans de Goede wrote:
> > According to the datasheets to n factor for dividing the tclk is
> > 2 to the power n on Allwinner SoCs, not 2 to the power n + 1 as it is
> > on other mv64xxx implementations.
> > 
> > I've contacted Allwinner about this and they have confirmed that the
> > datasheet is correct.
> > 
> > This commit fixes the clk-divider calculations for Allwinner SoCs
> > accordingly.
> > 
> > Signed-off-by: Hans de Goede <hdego...@redhat.com>
> 
> Applied to for-current, thanks!

And added stable...

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature


Re: [linux-sunxi] [PATCH] i2c: mv64xxx: The n clockdiv factor is 0 based on sunxi SoCs

2015-10-20 Thread Wolfram Sang

> WIth Hans having figured it out and fixing it, I'll absolutly will take a
> nother look and check with a scope if it all works out now.

Have you done this already? /me is always looking for Tested-by: tags :)

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature


[linux-sunxi] Re: [PATCH v2 1/4] i2c: sunxi: Add Reduced Serial Bus (RSB) support

2015-03-05 Thread Wolfram Sang

 From that regard, RSB is a multiple device bus, using addresses, just
 like I2C. The way it communicates is basically the one used by P2WI.

I am not keen to allow everything which is a bus and has addresses
into the I2C realm. The addresses are 12 bit, whilst I2C has at maximum
10 bit which is rarely used, so mostly 7 bit are used. It has a runtime
readdressing mechanism which is not present in standard I2C. And if you
look at the protocol with no acks but parities, IMO it doesn't look
closer to I2C than to other two wire protocols. So, being in I2C needs
more arguments.

And while the outcome could be that it really makes sense to add RSB to
I2C with I2C_FUNCS_RSB added, it could also be that there is a more
suitable place for custom busses in the kernel.

Also, the fact that P2WI is in I2C is not an argument IMO. It could have
been a mistake to pick it up.

 So really, it just is more I2C-alike than P2WI has ever been.

Because it has addresses? I disagree.

 Good thing that we are not talking about a full review then, but more
 a philosophical discussion.

Exactly. This is why I wanted to bring this in early.

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature


[linux-sunxi] Re: [PATCH v2 1/4] i2c: sunxi: Add Reduced Serial Bus (RSB) support

2015-03-05 Thread Wolfram Sang

  I don't have the bandwidth for a full review right now. However, I
  already wanted to tell you guys that my gut feeling is that this
  protocol is quite far away from I2C. P2WI was already at the edge.
  Maybe there is a better place for such custom stuff? I dunno yet.
 
 That's unfortunate, especially since it looks closer to SPI than what
 P2WI even was.

SPI? I assume you mean I2C. Can you elaborate your reasoning?

 What would be your suggestion?

Let me quote:

I don't have the bandwidth for a full review right now... I dunno
yet.

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature


[linux-sunxi] Re: [PATCH v2 1/4] i2c: sunxi: Add Reduced Serial Bus (RSB) support

2015-03-04 Thread Wolfram Sang
On Mon, Mar 02, 2015 at 04:24:43PM +0800, Chen-Yu Tsai wrote:
 The RSB controller looks like an SMBus controller which only supports byte
 and word data transfers. It can also do double-word data transfers, but the
 I2C subsystem does not support this, nor have we seen devices using this.
 
 The RSB differs from standard SMBus protocol on several aspects:
 - it uses addresses set at runtime to address slaves. Runtime addresses
   are sent to slaves using their 12bit hardware addresses. Up to 15
   runtime addresses are available.
 - it adds a parity bit every 8bits of data and address for read and
   write accesses; this replaces the ack bit
 - only one read access is required to read a byte (instead of a write
   followed by a read access in standard SMBus protocol)
 - there's no Ack bit after each read access
 
 This means this bus cannot be used to interface with standard SMBus
 devices (known devices supporting this interface are the AXP223, AXP806,
 AXP809 PMICs and the AC100 codec/RTC). However the RSB protocol is an
 extension of P2WI, which was close enough to SMBus to be integrated into
 the I2C subsystem in commit 3e833490fae5 (i2c: sunxi: add P2WI (Push/Pull
 2 Wire Interface) controller support).
 
 Signed-off-by: Chen-Yu Tsai w...@csie.org

I don't have the bandwidth for a full review right now. However, I
already wanted to tell you guys that my gut feeling is that this
protocol is quite far away from I2C. P2WI was already at the edge.
Maybe there is a better place for such custom stuff? I dunno yet.

Thanks,

   Wolfram

 ---
  drivers/i2c/busses/Kconfig |  12 +
  drivers/i2c/busses/Makefile|   1 +
  drivers/i2c/busses/i2c-sunxi-rsb.c | 458 
 +
  3 files changed, 471 insertions(+)
  create mode 100644 drivers/i2c/busses/i2c-sunxi-rsb.c
 
 diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
 index 22da9c2ffa22..cf9337877181 100644
 --- a/drivers/i2c/busses/Kconfig
 +++ b/drivers/i2c/busses/Kconfig
 @@ -840,6 +840,18 @@ config I2C_SUN6I_P2WI
 This interface is used to connect to specific PMIC devices (like the
 AXP221).
  
 +config I2C_SUNXI_RSB
 + tristate Allwinner Reduced Serial Bus controller
 + depends on RESET_CONTROLLER
 + depends on MACH_SUN8I || MACH_SUN9I || COMPILE_TEST
 + help
 +   If you say yes to this option, support will be included for the
 +   Reduced Serial Bus controller embedded in some sunxi SOCs.
 +   The RSB looks like an SMBus controller (which supports only byte
 +   accesses), but requires setting runtime addresses for slave devices.
 +   This interface is used to connect to specific PMIC devices (like the
 +   AXP223) or peripherals (like the AC100).
 +
  config I2C_TEGRA
   tristate NVIDIA Tegra internal I2C controller
   depends on ARCH_TEGRA
 diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
 index 3638feb6677e..f95d50315003 100644
 --- a/drivers/i2c/busses/Makefile
 +++ b/drivers/i2c/busses/Makefile
 @@ -81,6 +81,7 @@ obj-$(CONFIG_I2C_SIRF)  += i2c-sirf.o
  obj-$(CONFIG_I2C_ST) += i2c-st.o
  obj-$(CONFIG_I2C_STU300) += i2c-stu300.o
  obj-$(CONFIG_I2C_SUN6I_P2WI) += i2c-sun6i-p2wi.o
 +obj-$(CONFIG_I2C_SUNXI_RSB)  += i2c-sunxi-rsb.o
  obj-$(CONFIG_I2C_TEGRA)  += i2c-tegra.o
  obj-$(CONFIG_I2C_VERSATILE)  += i2c-versatile.o
  obj-$(CONFIG_I2C_WMT)+= i2c-wmt.o
 diff --git a/drivers/i2c/busses/i2c-sunxi-rsb.c 
 b/drivers/i2c/busses/i2c-sunxi-rsb.c
 new file mode 100644
 index ..7e9be3e14b8a
 --- /dev/null
 +++ b/drivers/i2c/busses/i2c-sunxi-rsb.c
 @@ -0,0 +1,458 @@
 +/*
 + * RSB (Reduced Serial Bus) driver.
 + *
 + * Author: Chen-Yu Tsai w...@csie.org
 + *
 + * This file is licensed under the terms of the GNU General Public License
 + * version 2.  This program is licensed as is without any warranty of any
 + * kind, whether express or implied.
 + *
 + * The RSB controller looks like an SMBus controller which only supports
 + * byte and word data transfers. But, it differs from standard SMBus
 + * protocol on several aspects:
 + * - it uses addresses set at runtime to address slaves. Runtime addresses
 + *   are sent to slaves using their 12bit hardware addresses. Up to 15
 + *   runtime addresses are available.
 + * - it adds a parity bit every 8bits of data and address for read and
 + *   write accesses; this replaces the ack bit
 + * - only one read access is required to read a byte (instead of a write
 + *   followed by a read access in standard SMBus protocol)
 + * - there's no Ack bit after each read access
 + *
 + * This means this bus cannot be used to interface with standard SMBus
 + * devices. Devices known to support this interface include the AXP223,
 + * AXP809, and AXP806 PMICs, and the AC100 audio codec, all from X-Powers.
 + *
 + * A description of the operation and wire protocol can be found in the
 + * RSB section of Allwinner's A80 

[linux-sunxi] Re: [PATCH v2] i2c: mv64xxx: continue probe when clock-frequency is missing

2014-09-02 Thread Wolfram Sang
On Mon, Sep 01, 2014 at 10:28:13PM +0800, Chen-Yu Tsai wrote:
 The clock-frequency DT property is listed as optional, However,
 the current code stores the return value of of_property_read_u32 in
 the return code of mv64xxx_of_config, but then forgets to clear it
 after setting the default value of clock-frequency. It is then
 passed out to the main probe function, resulting in a probe failure
 when clock-frequency is missing.
 
 This patch checks and then throws away the return value of
 of_property_read_u32, instead of storing it and having to clear it
 afterwards.
 
 This issue was discovered after the property was removed from all
 sunxi DTs.

Hmm, I don't like that removal. Probably I should take care that this
property is not optional but recommended. The default value is
depending on the driver, mostly because of historic reasons. It is
definately better to explicitly state it. Despite all that...

 
 Fixes: 4c730a06c19bb (i2c: mv64xxx: Set bus frequency to 100kHz if 
 clock-frequency is not provided)
 Signed-off-by: Chen-Yu Tsai w...@csie.org
 Cc: sta...@vger.kernel.org
 Acked-by: Andrew Lunn and...@lunn.ch
 Acked-by: Maxime Ripard maxime.rip...@free-electrons.com

Applied to for-current, thanks!



signature.asc
Description: Digital signature


[linux-sunxi] Re: [PATCH v3 1/5] i2c: mv64xxx: Add reset deassert call

2014-03-07 Thread Wolfram Sang

 Since RESET_CONTROLLER is not required for those platforms, it really
 should be optional - and I think the real fix is for the reset controller
 support to provide stub functions.

I agree; and I assumed it already does. Will resend a patch posted
earlier [1] to fix the issue. And still debugging why my build-tests
didn't get it :(

[1] https://lkml.org/lkml/2013/8/9/442



signature.asc
Description: Digital signature


Re: [linux-sunxi] Re: [PATCH v3 1/5] i2c: mv64xxx: Add reset deassert call

2014-03-07 Thread Wolfram Sang

  Since RESET_CONTROLLER is not required for those platforms, it really
  should be optional - and I think the real fix is for the reset controller
  support to provide stub functions.
 
 Philipp Zabel suggested that adding a _optional variant that provides stubs
 and doesn't depend on RESET_CONTROLLER is probably better. This keeps the
 compile time checks for drivers requiring it.
 
 See: https://lkml.org/lkml/2014/1/10/220
 
 I ended up dropping my patch though.

Thanks for the pointer. Well, looks like I need to revert the offending
i2c patches then until this issue is fixed? We can't have
RESET_CONTROLLER (circular dependency) and we can't skip it (build
failures).



signature.asc
Description: Digital signature


[linux-sunxi] Re: [PATCH v2 0/5] ARM: sun6i: Add support for the A31 I2C controller

2014-02-17 Thread Wolfram Sang

 It's been over a month now, and no sign of life from you on this patch
 so far... Should I just take this patchset through my tree? :)

Nope.



signature.asc
Description: Digital signature