[linux-sunxi] Re: [PATCH] i2c: mv64xxx: The n clockdiv factor is 0 based on sunxi SoCs
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 > > 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
[linux-sunxi] Re: [PATCH] i2c: mv64xxx: The n clockdiv factor is 0 based on sunxi SoCs
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 Applied to for-current, thanks! -- 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
> 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
> 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
> > 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
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
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
> + *
> + * 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 operati
[linux-sunxi] Re: [PATCH v2] i2c: mv64xxx: continue probe when clock-frequency is missing
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
> Cc: sta...@vger.kernel.org
> Acked-by: Andrew Lunn
> Acked-by: Maxime Ripard
Applied to for-current, thanks!
signature.asc
Description: Digital signature
Re: [linux-sunxi] Re: [PATCH v3 1/5] i2c: mv64xxx: Add reset deassert call
> > 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 v3 1/5] i2c: mv64xxx: Add reset deassert call
> 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
[linux-sunxi] Re: [PATCH v3 2/5] i2c: mv64xxx: Add support for the Allwinner A31 I2C driver
On Tue, Mar 04, 2014 at 05:28:38PM +0100, Maxime Ripard wrote: > The Allwinner A31 I2C controller is almost identical to the one used in the > other Allwinner SoCs, except for the fact that it needs to clear the interrupt > by setting the INT_FLAGS bit in the control register, instead of clearing it. > > Signed-off-by: Maxime Ripard > Reviewed-by: Gregory CLEMENT > Tested-by: Gregory CLEMENT Applied to for-next, thanks! Still... > + if (of_device_is_compatible(np, "allwinner,sun6i-a31-i2c")) > + drv_data->irq_clear_inverted = true; ... next time an errata is needed, I think it makes sense to refactor all these checks into one struct which can be used as match->data directly. signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v3 1/5] i2c: mv64xxx: Add reset deassert call
On Tue, Mar 04, 2014 at 05:28:37PM +0100, Maxime Ripard wrote: > The Allwinner A31 SoC using that IP has a reset controller maintaining > it reset unless told otherwise. > > Add some optional reset support to the driver. > > Signed-off-by: Maxime Ripard > Reviewed-by: Gregory CLEMENT > Tested-by: Gregory CLEMENT Applied to for-next, thanks! signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v2 0/5] ARM: sun6i: Add support for the A31 I2C controller
On Mon, Feb 17, 2014 at 04:24:30PM +0100, Maxime Ripard wrote: > On Mon, Feb 17, 2014 at 03:26:12PM +0100, Wolfram Sang wrote: > > > > > 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. > > Then please review those 40 lines of code. They are due when they are due. If you want to speed it up, you are very welcome to review patches on the i2c mailing list. signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v2 0/5] ARM: sun6i: Add support for the A31 I2C controller
> 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
