Hello!
On 18/06/15 13:12, ext Sekhar Nori wrote:
Ah, beyond the evalboards, there are device-trees not linked into the
kernel,
but flashed into the boards, as originally in OF. They are part of
the HW, its
description. Not part or description of the Kernel. And you have no
way to
Checks if the cdiv value is in between min (0x2) and max (0xFFFE)
supported values by the bcm2835. If not, it returns -ENODEV.
See page 33/34 of BCM2835-ARM-Peripherals.pdf for the DIV register.
https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
Signed-off-by:
Now parport is using device model so use dev_* macros instead of printk.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/i2c/busses/i2c-parport.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-parport.c
Hello!
On 17/06/15 23:13, ext York Sun wrote:
+ switch (mux-data.reg_size) {
+ case 4:
+ iowrite32(mux-data.values[chan], mux-data.reg);
+ break;
+ case 2:
+ iowrite16(mux-data.values[chan], mux-data.reg);
+ break;
+ case 1:
Start using pr_fmt and convert all remaining printk to use
pr_* family of macros.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/i2c/busses/i2c-parport.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-parport.c
On Thursday 18 June 2015 03:34 PM, Alexander Sverdlin wrote:
Hi!
On 18/06/15 11:47, ext Sekhar Nori wrote:
Ah, beyond the evalboards, there are device-trees not linked into the
kernel,
but flashed into the boards, as originally in OF. They are part of the HW,
its
description. Not part
Linus,
here is a small documentation fix for I2C. We already had a user who
unsuccessfully tried to get the new slave framework running with the
currently broken example. So, before this happens again, I'd like to
have this how-to-use section fixed for 4.1 already. So that no more
hacking time is
On 06/18/2015 05:35 AM, Alexander Sverdlin wrote:
Hello!
On 17/06/15 23:13, ext York Sun wrote:
+switch (mux-data.reg_size) {
+case 4:
+iowrite32(mux-data.values[chan], mux-data.reg);
+break;
+case 2:
+iowrite16(mux-data.values[chan],
On 06/18/2015 05:00 AM, Sekhar Nori wrote:
On Thursday 18 June 2015 02:23 PM, Alexander Sverdlin wrote:
According to KeyStone Architecture I2C User Guide,
module clock frequency
master clock frequency = --
(ICCL + 6) +
On Thu, Jun 18, 2015 at 08:39:11AM +0200, Michael Lawnick wrote:
Am 17.06.2015 um 17:38 schrieb Felipe Balbi:
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
Am 18.06.2015 um 19:24 schrieb Felipe Balbi:
On Thu, Jun 18, 2015 at 08:39:11AM +0200, Michael Lawnick wrote:
Am 17.06.2015 um 17:38 schrieb Felipe Balbi:
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
On Thu, Jun 18, 2015 at 10:09:59AM +0200, Alexander Sverdlin wrote:
Hello Felipe,
On 17/06/15 21:31, 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
From: Wolfram Sang mailto:w...@the-dreams.de sent: Thursday, June 18, 2015
12:24 PM
To: Gao Pan-B54642
Cc: Uwe Kleine-König; 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
+ if
Am 17.06.2015 um 17:38 schrieb Felipe Balbi:
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
On Thu, 2015-06-18 at 11:42 +0200, Alexander Sverdlin wrote:
Most of the usual drivers in the Kernel have this line.
Perhaps people copy and paste without really realizing what this macro
is supposed to be for. (I didn't know until a few days ago. I needed you
to confirm that I figured it out
cp2112_i2c_xfer() only supports a single i2c_msg. More than
one message at a time just returns EIO. This breaks certain
important cases. For example, the at24 eeprom driver generates
paired write and read messages (for eeprom address and data).
Since the device doesn't support i2c repeated
Hi!
On 18/06/15 11:47, ext Sekhar Nori wrote:
Ah, beyond the evalboards, there are device-trees not linked into the kernel,
but flashed into the boards, as originally in OF. They are part of the HW,
its
description. Not part or description of the Kernel. And you have no way to
introduce
Hi!
On 17/06/15 18:03, ext Paul Bolle 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 patch
that
I'll do that, and use the quirks mechanism, too.
Stay tuned.
On 06/18/2015 01:26 AM, Wolfram Sang wrote:
Mine is rev 1 !!!
Found also that in the datasheet chapter 12 reports the differences
between the two revisions.
In 12.1 it states that revision 1 does not implement repeated start.
Hello!
On 17/06/15 18:43, ext York Sun wrote:
Yeah, this is really bad idea. You maybe want something like
__iomem cookie here instead of this bare pointer.
Let me try.
Could you think about different access widths, please?
Not all buses are 32-bits wide and even on 64-bit CPUs one might
Hi Alexander,
On Thu, 2015-06-18 at 09:40 +0200, Alexander Sverdlin wrote:
On 17/06/15 18:03, ext Paul Bolle 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.
Hello Felipe,
On 17/06/15 21:31, 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
On Thu, Jun 18, 2015 at 4:26 PM, Wolfram Sang w...@the-dreams.de wrote:
Mine is rev 1 !!!
Found also that in the datasheet chapter 12 reports the differences
between the two revisions.
In 12.1 it states that revision 1 does not implement repeated start. Perfect!
I will try to replace my
On Thu, Jun 18, 2015 at 8:55 AM, Ellen Wang el...@cumulusnetworks.com wrote:
...
Since the the long-read fix is less controversial, I've split it out and
sent it as a separate patch.
Hi Ellen,
got it, will check soon
As for repeated start, it's not that easy for me to check it. The chip
Mine is rev 1 !!!
Found also that in the datasheet chapter 12 reports the differences
between the two revisions.
In 12.1 it states that revision 1 does not implement repeated start. Perfect!
I will try to replace my device with a newer one.
Can this be checked in the code?
signature.asc
Hi!
On 18/06/15 11:00, ext Sekhar Nori wrote:
+if (davinci_i2c_read_reg(dev, DAVINCI_I2C_ICPID2_REG) == 0x2206) {
+ dev_dbg(dev-dev, Keystone SoC detected\n);
+ d = 6;
+ }
I think its better to use a different compatible string for i2c on
keystone devices rather
Hi Alexander,
On Thursday 18 June 2015 02:39 PM, Alexander Sverdlin wrote:
Hi!
On 18/06/15 11:00, ext Sekhar Nori wrote:
+ if (davinci_i2c_read_reg(dev, DAVINCI_I2C_ICPID2_REG) == 0x2206) {
+ dev_dbg(dev-dev, Keystone SoC detected\n);
+ d = 6;
+ }
I think its better
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 sacrificed.
To weigh the power consumption and i2c bus performance,
On Thu, 2015-06-18 at 11:04 +0200, Alexander Sverdlin wrote:
Maybe (and hopefully) there will never be a legacy user of this driver. But
this macro
is perfectly fine, adds no overhead (but modinfo)
(The test for any line of code is whether it adds value. Adding no
overhead is not adding
Hello!
On 18/06/15 11:25, ext Sekhar Nori wrote:
+ if (davinci_i2c_read_reg(dev, DAVINCI_I2C_ICPID2_REG) == 0x2206) {
+dev_dbg(dev-dev, Keystone SoC detected\n);
+d = 6;
+}
I think its better to use a different compatible string for i2c on
keystone devices
Hi!
On 18/06/15 11:32, ext Paul Bolle wrote:
As I understand it, we've established that:
- this macro setups up udev, and modprobe, and friends, to listen to a
MODALIAS=platform:i2c-mux-reg message; and
- that there's currently no code in the kernel that will send out this
message.
Did I
On Thursday 18 June 2015 03:07 PM, Alexander Sverdlin wrote:
Hello!
On 18/06/15 11:25, ext Sekhar Nori wrote:
+ if (davinci_i2c_read_reg(dev, DAVINCI_I2C_ICPID2_REG) == 0x2206) {
+dev_dbg(dev-dev, Keystone SoC detected\n);
+d = 6;
+}
I think its better to use a
According to KeyStone Architecture I2C User Guide,
module clock frequency
master clock frequency = --
(ICCL + 6) + (ICCH + 6)
i.e. d in i2c_davinci_calc_clk_dividers() should be fixed and
not dependent from module clock
On Thursday 18 June 2015 02:23 PM, Alexander Sverdlin wrote:
According to KeyStone Architecture I2C User Guide,
module clock frequency
master clock frequency = --
(ICCL + 6) + (ICCH + 6)
i.e. d in
Hi!
On 18/06/15 10:08, ext Paul Bolle 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
35 matches
Mail list logo
