SI5338 is a programmable clock generator. It has 4 sets of inputs,
PLL, multisynth and dividers to make 4 outputs. This driver splits
them into multiple clocks to comply with common clock framework.
See Documentation/devicetree/bindings/clock/silabs,si5338.txt for
details.
Export
On Wed, Jun 17, 2015 at 12:01:47PM -0700, York Sun wrote:
COMMON_CLK has been a bool value, selected by the platforms who need
common clock framework. If a CCF driver is needed on an add-on device
such as PCIe card, COMMON_CLK can be selected individually as a
tristate value.
Signed-off-by:
On 06/17/2015 12:05 PM, Wolfram Sang wrote:
On Wed, Jun 17, 2015 at 12:01:47PM -0700, York Sun wrote:
COMMON_CLK has been a bool value, selected by the platforms who need
common clock framework. If a CCF driver is needed on an add-on device
such as PCIe card, COMMON_CLK can be selected
Hello Felipe,
On 17/06/15 20:00, Felipe Balbi wrote:
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with certain duty cycles.
One such example is TPS65218 PMIC which fails
to change
Hi!
On 17/06/15 20:29, Felipe Balbi wrote:
- if (dev-speed 400 ||
-dev-flags OMAP_I2C_FLAG_FORCE_19200_INT_CLK)
- internal_clk = 19200;
Let's compare, what it waas before in this case...
- else if (dev-speed 100)
-
On Wed, Jun 17, 2015 at 01:00:52PM -0500, Felipe Balbi wrote:
Hi,
On Wed, Jun 17, 2015 at 11:19:28AM +0200, Alexander Sverdlin wrote:
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with
Hello!
On 17/06/15 20:57, Felipe Balbi wrote:
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with certain duty cycles.
One such example is TPS65218 PMIC which fails
to change voltages when running @ 400kHz and
duty
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with certain duty cycles.
One such example is TPS65218 PMIC which fails
to change voltages when running @ 400kHz and
duty cycle is lower than 34%.
The idea of
Hi,
On Wed, Jun 17, 2015 at 11:19:28AM +0200, Alexander Sverdlin wrote:
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with certain duty cycles.
One such example is TPS65218 PMIC which fails
On Wed, Jun 17, 2015 at 8:23 AM, Michael Berger mikeaber...@gmail.com wrote:
I cannot access an I2C device located behind two or more nested
PCA9545 muxes if the muxes are configured to use a deselect function.
...
Address 0x50 --- At this point I see an error/NACK with the SDA
floating high
Hi,
On Wed, Jun 17, 2015 at 08:38:42PM +0200, Alexander Sverdlin wrote:
Hello Felipe,
On 17/06/15 20:00, Felipe Balbi wrote:
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with certain
On Wed, Jun 17, 2015 at 09:00:53PM +0200, Alexander Sverdlin wrote:
Hi!
On 17/06/15 20:29, Felipe Balbi wrote:
- if (dev-speed 400 ||
- dev-flags OMAP_I2C_FLAG_FORCE_19200_INT_CLK)
- internal_clk = 19200;
Let's compare, what it
cp2112_i2c_xfer() only reads up to 61 bytes, returning EIO
on longers reads. The fix is to wrap a loop around
cp2112_read() to pick up all the returned data.
Signed-off-by: Ellen Wang el...@cumulusnetworks.com
---
This is like the previous patch but with the controversial
part left out.
---
So, I must look further into the interactions with the other devices
on the bus to determine why my bus misbehaves shortly after boot - the
SCLK is being held low by something beyond the top mux.
Good luck with that and thank you for the update!
signature.asc
Description: Digital signature
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with certain duty cycles.
One such example is TPS65218 PMIC which fails
to change voltages when running @ 400kHz and
duty cycle is lower than 34%.
The idea of
COMMON_CLK has been a bool value, selected by the platforms who need
common clock framework. If a CCF driver is needed on an add-on device
such as PCIe card, COMMON_CLK can be selected individually as a
tristate value.
Signed-off-by: York Sun york...@freescale.com
CC: Paul Bolle
From: Wolfram Sang wsa+rene...@sang-engineering.com
When debugging embedded systems, it is often nice to simply TFTP the
desired i2ctool to the target without the hazzle of dealing with shared
libs. Using -static is overkill, too, so let's add a switch which will
only link functions from libi2c
Based on i2c-mux-gpio driver, similarly the register based mux
switch from one bus to another by setting a single register.
The register can be on PCIe bus, local bus, or any memory-mapped
address.
Signed-off-by: York Sun york...@freescale.com
CC: Wolfram Sang w...@the-dreams.de
CC: Paul Bolle
Hello,
On Thu, Jun 11, 2015 at 09:50:04AM +0800, Gao Pan wrote:
In our former i2c driver, i2c clk is enabled and disabled in
xfer function, which contributes to power saving. However,
the clk enable process brings a busy wait delay until the core
is stable. As a result, the performance is
On 06/15/2015 02:10 AM, Antonio Borneo wrote:
On Sat, Jun 13, 2015 at 4:26 PM, Ellen Wang el...@cumulusnetworks.com wrote:
cp2112_i2c_xfer() only supports a single i2c_msg and only
reads up to 61 bytes. More than one message at a time
and longers reads just return errors. This breaks certain
+ if (pm_runtime_suspended(i2c_imx-adapter.dev.parent))
+ return IRQ_NONE;
+
I don't claim to understand the runtime pm stuff, but I agree to the
previous reviewer that this smells fishy. If this is required it needs a
comment why.
In fact, I agree you two reviewers'
From: Uwe Kleine-König u.kleine-koe...@pengutronix.de Sent: Thursday, June
18, 2015 5:49 AM
To: Gao Pan-B54642
Cc: w...@the-dreams.de; linux-i2c@vger.kernel.org; Li Frank-B20596; Duan
Fugang-B38611
Subject: Re: [Patch v1] i2c: imx: add runtime pm support to improve the
performance
Hello,
On 06/17/2015 02:29 AM, Paul Bolle wrote:
On Tue, 2015-06-16 at 09:31 -0700, York Sun wrote:
COMMON_CLK in Kconfig is changed from bool to tristate so all common
clock framework drivers can be selected by users.
A bool to tristate change isn't needed to make it possible to set a
symbol
On Wed, 17 Jun 2015 21:26:45 +0200, Wolfram Sang wrote:
From: Wolfram Sang wsa+rene...@sang-engineering.com
When debugging embedded systems, it is often nice to simply TFTP the
desired i2ctool to the target without the hazzle of dealing with shared
libs. Using -static is overkill, too, so
On Tue, Jun 16, 2015 at 05:40:59PM +0200, Silvan Wicki wrote:
The Datasheet mentions on page 31 that the bits 10-31 must be read as
don't care and written as 0.
https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
We cannot guarantee that we reed bits 10-31 as
On Wed, 17 Jun 2015 12:38:54 +0200, Angelo Compagnucci wrote:
Hi Wolfram,
2015-06-17 12:29 GMT+02:00 Wolfram Sang w...@the-dreams.de:
Now if anyone has a more educated view on this than I do, please speak
up. Android is really not my thing (as a developer, I mean.)
While working
Am 16.06.2015 um 21:17 schrieb Felipe Balbi:
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with certain duty cycles.
One such example is TPS65218 PMIC which fails
to change voltages when running @ 400kHz
Hi,
On Mon, Jun 15, 2015 at 08:47:52PM +0530, Shubhrajyoti Datta wrote:
Handle error cases in the Rx path
Signed-off-by: Shubhrajyoti Datta shubh...@xilinx.com
Your patch descriptions need improvement. They describe what you do,
but this can be seen in the patch as well. What you need to
I cannot access an I2C device located behind two or more nested
PCA9545 muxes if the muxes are configured to use a deselect function.
I'm not sure whether this is a bug in i2c-mux.c, i2c-mux-pca954x.c,
the interaction between the two, or whether it's a quirk of my
particular hardware. I'm hoping
On Fri, Jun 12, 2015 at 12:47:14PM +0530, Sudip Mukherjee wrote:
Start using pr_fmt and convert all remaining printk to use
pr_* family of macros.
I heard you introduced the driver model to parport. So, isn't there a
struct device we could use for dev_err() and friends?
Thanks,
Wolfram
On Fri, Jun 12, 2015 at 02:40:37PM +0200, Alexander Sverdlin wrote:
Newly introduced quirks infrastructure doesn't work for the devices behind
MUXes because MUX's master_xfer() calls parent's master_xfer() directly
without checking the quirks. Instead of duplicating check code in MUX just
call
On Fri, Jun 12, 2015 at 02:41:00PM +0200, Alexander Sverdlin wrote:
pca9541 and pca954x are calling master_xfer() of the parent adapter directly
thus bypassing the quirks checks of the adapter. Use __i2c_transfer() instead.
Signed-off-by: Alexander Sverdlin alexander.sverd...@nokia.com
Hallo Wolfram,
On Tue, 16 Jun 2015 04:01:19 +0200, Wolfram Sang wrote:
From: Wolfram Sang wsa+rene...@sang-engineering.com
When debugging embedded systems, it is often nice to simply TFTP the
desired i2ctool to the target without the hazzle of dealing with shared
libs. Using -static is
On Tue, 2015-06-16 at 09:31 -0700, York Sun wrote:
COMMON_CLK in Kconfig is changed from bool to tristate so all common
clock framework drivers can be selected by users.
A bool to tristate change isn't needed to make it possible to set a
symbol manually. That's achieved by adding a prompt
Now if anyone has a more educated view on this than I do, please speak
up. Android is really not my thing (as a developer, I mean.)
While working again on adding i2ctransfer to i2c-tools, it became clear
that this android makefile would need an update for it, too. And since
nobody of us is
I think it's more a matter of a makefile approach. They use a non
recursive one (recommended by several papers[1]) and it's up to
external projects if embrace it or no. Honestly I think that a
minuscule file with really low maintenance should be added.
Isn't there a central place where these
On Mon, Jun 15, 2015 at 07:51:46PM +0200, Wolfram Sang wrote:
From: Wolfram Sang wsa+rene...@sang-engineering.com
I copied the wrong shell code into the documentation. Sorry to all who
tried to get sense out of this current example :/ Slight rewording while
we are here.
Reported-by: Tim
On Wed, 17 Jun 2015 11:23:38 +0200, Angelo Compagnucci wrote:
Please, please, find that time! I really would like to package
i2c-tools 3.1 with python3 support in buildroot!
OK, releasing i2c-tools 3.1.2 was easy after all, it's done now.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from
The driver calls pm_runtime_put() right before pm_runtime_disable() in its
-remove() hook to make sure clock is gated etc. However, it turns out that
pm_runtime_put() only calls -idle() hook without actually suspending
anything. The following pm_runtime_disable() will prevent the driver from
On Wed, Jun 17, 2015 at 12:16:45PM +0200, Wolfram Sang wrote:
On Wed, Jun 17, 2015 at 12:08:38PM +0300, Mika Westerberg wrote:
The driver calls pm_runtime_put() right before pm_runtime_disable() in its
-remove() hook to make sure clock is gated etc. However, it turns out that
Hi Wolfram,
2015-06-17 12:29 GMT+02:00 Wolfram Sang w...@the-dreams.de:
Now if anyone has a more educated view on this than I do, please speak
up. Android is really not my thing (as a developer, I mean.)
While working again on adding i2ctransfer to i2c-tools, it became clear
that this
Hello!
On 16/06/15 21:20, ext Felipe Balbi wrote:
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with certain duty cycles.
One such example is TPS65218 PMIC which fails
to change voltages when
Hi Angelo,
On Tue, 26 May 2015 09:56:47 +0200, Angelo Compagnucci wrote:
Dear Jean Delvare,
Now that python3 support was added to python-smbus, could you release
a new stable version with it?
This way, py-smbus with python3 support could be included in
distributions that usually don't
Hi Jean,
2015-06-17 11:18 GMT+02:00 Jean Delvare jdelv...@suse.de:
Hi Angelo,
On Tue, 26 May 2015 09:56:47 +0200, Angelo Compagnucci wrote:
Dear Jean Delvare,
Now that python3 support was added to python-smbus, could you release
a new stable version with it?
This way, py-smbus with
On Mon, Jun 08, 2015 at 07:48:25PM -0600, Stephen Warren wrote:
On 06/06/2015 12:18 PM, Silvan Wicki wrote:
Adds: make sure bits 16-31 of DIV register are always 0
Adds: assume minimal divider of 2 if divider resulted in 0
(bcm2835 sets divider to 32768 if cdiv is set to 0)
See
On Wed, Jun 17, 2015 at 12:08:38PM +0300, Mika Westerberg wrote:
The driver calls pm_runtime_put() right before pm_runtime_disable() in its
-remove() hook to make sure clock is gated etc. However, it turns out that
pm_runtime_put() only calls -idle() hook without actually suspending
anything.
A nit and a question follow.
On Tue, 2015-06-16 at 10:28 -0700, York Sun wrote:
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-mux-reg.c
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by
On Tue, Jun 09, 2015 at 04:14:38PM +0900, Wolfram Sang wrote:
This series moves the errata handling from the setup function into the driver.
It has been tested that this changeset does not cause a regression on the
armadillo board we had access to. Unfortunately, this board did not need the
Hi Jean,
When debugging embedded systems, it is often nice to simply TFTP the
desired i2ctool to the target without the hazzle of dealing with shared
libs. Using -static is overkill, too, so let's add a switch which will
only link functions from libi2c statically.
Fine with me.
You mean that USE_STATIC_LIB = 1 would silently imply
BUILD_STATIC_LIB = 1? Yes, that's much better than my proposal.
Yes, I meant that.
I'm wondering if we should make it even more flexible, but I'm not sure
if it's worth the effort... Are you calling make install after that?
I guess not.
Having said that, I am still not convinced that the driver should be in the
kernel
to start with. Browsing through Intel's datasheets, the registers are
supported
in E5-2600 v1, v2, and v3. However, in v3 Intel added a note saying that
the registers
should not be accessed by the
On Fri, Jun 12, 2015 at 02:41:16PM +0200, Alexander Sverdlin wrote:
Inherit parent adapter quirks in MUX in case the devices on the multiplexed
buses are interested in the adapter limitations.
Signed-off-by: Łukasz Gemborowski lukasz.gemborow...@nokia.com
Signed-off-by: Alexander Sverdlin
On Thu, Jun 11, 2015 at 11:35:26AM +0200, Alexander Sverdlin wrote:
There are several cases where current clock configuration algorithm produces
not optimal results:
- truncation in clk calculation leads to the fact that actual BUS frequency
will be always higher than spec except two exact
Hi Wolfram, Nicholas,
On 17/06/2015 15:00, Wolfram Sang wrote:
On Thu, Jun 11, 2015 at 05:27:33PM +0200, Nicholas Mc Guire wrote:
'commit d295a86eab20 (i2c: mv64xxx: work around signals causing I2C
transactions to be aborted)' removed the wait_event_interruptible_timeout
to prevent
-Original Message-
From: Wolfram Sang [mailto:w...@the-dreams.de]
Sent: Wednesday, June 17, 2015 5:12 PM
To: Shubhrajyoti Datta
Cc: linux-i2c@vger.kernel.org; Shubhrajyoti Datta
Subject: Re: [PATCH 1/9] i2c: xiic: Do not continue in case of errors in Rx
Hi,
On Mon, Jun 15, 2015
Your patch descriptions need improvement. They describe what you do, but
this can be seen in the patch as well. What you need to describe is WHY you
need this change.
In case the slave nacks the transaction in the middle of the transfer The
driver continues.
What was wrong before,
On Wed, 17 Jun 2015 12:53:09 +0200, Wolfram Sang wrote:
Hi Jean,
When debugging embedded systems, it is often nice to simply TFTP the
desired i2ctool to the target without the hazzle of dealing with shared
libs. Using -static is overkill, too, so let's add a switch which will
only
On Wed, 17 Jun 2015, Gregory CLEMENT wrote:
Hi Wolfram, Nicholas,
On 17/06/2015 15:00, Wolfram Sang wrote:
On Thu, Jun 11, 2015 at 05:27:33PM +0200, Nicholas Mc Guire wrote:
'commit d295a86eab20 (i2c: mv64xxx: work around signals causing I2C
transactions to be aborted)' removed the
On Thu, Jun 11, 2015 at 05:27:33PM +0200, Nicholas Mc Guire wrote:
'commit d295a86eab20 (i2c: mv64xxx: work around signals causing I2C
transactions to be aborted)' removed the wait_event_interruptible_timeout
to prevent half/mixed i2c messages from being sent/received but forgot to
drop the
On Wed, Jun 17, 2015 at 01:46:17PM +0200, Wolfram Sang wrote:
On Fri, Jun 12, 2015 at 12:47:14PM +0530, Sudip Mukherjee wrote:
Start using pr_fmt and convert all remaining printk to use
pr_* family of macros.
I heard you introduced the driver model to parport. So, isn't there a
struct
Hi!
On 16/06/15 19:57, ext Wolfram Sang wrote:
payload_size is a 12 bit field in the HW register, so add a limit for
this size. That way we gracefully reject the message beforehand instead
of generating an OOPS while transferring. Verified using some older
Tegra2 documentation and a more
Hi!
On 16/06/15 19:28, ext York Sun wrote:
Based on i2c-mux-gpio driver, similarly the register based mux
switch from one bus to another by setting a single register.
The register can be on PCIe bus, local bus, or any memory-mapped
address.
Signed-off-by: York Sun york...@freescale.com
Currently before every transfer the controller is reinitialised.
We are already resetting the controller upon errors so upon every
transfer is a performance kill.
Remove the same.
Signed-off-by: Shubhrajyoti Datta shubh...@xilinx.com
---
drivers/i2c/busses/i2c-xiic.c |1 -
1 files changed, 0
Hi!
On 17/06/15 10:54, ext Paul Bolle wrote:
+MODULE_ALIAS(platform:i2c-mux-reg);
As far as I understand it, this alias is only useful if there's a
corresponding struct platform_device, somewhere. Ie, this alias needs a
platform_device that will fire of a MODALIAS=platform:i2c-mux-reg
uevent
On Wed, Jun 17, 2015 at 03:18:42PM +0200, Wolfram Sang wrote:
Having said that, I am still not convinced that the driver should be in
the kernel
to start with. Browsing through Intel's datasheets, the registers are
supported
in E5-2600 v1, v2, and v3. However, in v3 Intel added
Currently before every transfer the interrupts are disabled.
So incase the slave nacks in the middle of the transfer the
current transfer is not aborted. Upon enabling the interrupts
conditions like NACK , arbitration lost will not be masked.
Remove the disabling of the interrupts.
Signed-off-by:
Currently only one interrupt is serviced in the isr.
In case the multiple interrupts happen simultenously we service and ack
only one of them. Check for all the causes in the isr and service them.
Signed-off-by: Shubhrajyoti Datta shubh...@xilinx.com
---
drivers/i2c/busses/i2c-xiic.c | 24
In case of error conditions like Arbitration lost or NACK lets signal
the waiting process.
Handle error cases in the Rx path
Signed-off-by: Shubhrajyoti Datta shubh...@xilinx.com
---
drivers/i2c/busses/i2c-xiic.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
Currently we return silently upon a timeout.
Adding an error message to aid debugability. Not
a functional change.
Signed-off-by: Shubhrajyoti Datta shubh...@xilinx.com
---
drivers/i2c/busses/i2c-xiic.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
This is a series of cleanups for the axi iic.
tested on zc702 and microblaze.
Changes from v1
Updated the commit message.
Shubhrajyoti Datta (9):
i2c: xiic: Remove the disabling of interrupts
i2c: xiic: move the xiic_process to thread context
i2c: xiic: Do not reset controller before
Remove the busy loop while waiting for bus busy.
Instead let the processor sleep.
Signed-off-by: Shubhrajyoti Datta shubh...@xilinx.com
---
drivers/i2c/busses/i2c-xiic.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-xiic.c
Currently the interrupts are disabled at the start of the
isr and enabled at the end of the isr. Remove the same.
In case the slave device NACKs the transaction while in the isr
the transfer will continue and the NACK interrupt will arrive
only after the isr is serviced.
Signed-off-by:
On 06/17/2015 08:03 AM, Alexander Sverdlin wrote:
Hi!
On 16/06/15 19:28, ext York Sun wrote:
Based on i2c-mux-gpio driver, similarly the register based mux
switch from one bus to another by setting a single register.
The register can be on PCIe bus, local bus, or any memory-mapped
Currently there is no slave mode support in the driver
also in the isr we just ack it and do nothing.
So disable the AAS interrupt.
Signed-off-by: Shubhrajyoti Datta shubh...@xilinx.com
---
drivers/i2c/busses/i2c-xiic.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
The xiic_process is a 154 line code that runs in isr context currently
move it to thread context. Also the name xiic_process suggests that the
intension was to run in process context.
Signed-off-by: Shubhrajyoti Datta shubh...@xilinx.com
---
drivers/i2c/busses/i2c-xiic.c | 33
Hi,
On Wed, Jun 17, 2015 at 01:09:53PM +0200, Michael Lawnick wrote:
Am 16.06.2015 um 21:17 schrieb Felipe Balbi:
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with certain duty cycles.
One such
On Wed, 2015-06-17 at 17:00 +0200, Alexander Sverdlin wrote:
You do not see the platform_device, because there are no users yet, put
this MODULE_ALIAS() is perfectly fine, it will allow automatic module loading
in non-DT case.
Do you mean that it will allow automatic module loading once the
77 matches
Mail list logo
