- at least
for majority of our customers.
I write them by hand. Is there any other way?
Mike.
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69
On 04/07/2014 10:11 AM, Arnd Bergmann wrote:
On Monday 07 April 2014 08:38:28 Mike Looijmans wrote:
index 34aef81..43b90c1 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2972,6 +2972,8 @@ int sdhci_add_host(struct sdhci_host *host)
host->vq
that has an I2C regulator for one of the sdhcis
and no regulators at all for the other. This patch enables such a system
to work correctly.
v2: Do not change logging output
Signed-off-by: Mike Looijmans
---
drivers/mmc/host/sdhci.c |4
1 file changed, 4 insertions(+)
diff --git
that has an I2C regulator for one of the sdhcis
and no regulators at all for the other. This patch enables such a system
to work correctly.
Signed-off-by: Mike Looijmans
---
drivers/mmc/host/sdhci.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host
that has an I2C regulator for one of the sdhcis
and no regulators at all for the other. This patch enables such a system
to work correctly.
Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
---
drivers/mmc/host/sdhci.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff
that has an I2C regulator for one of the sdhcis
and no regulators at all for the other. This patch enables such a system
to work correctly.
v2: Do not change logging output
Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
---
drivers/mmc/host/sdhci.c |4
1 file changed, 4 insertions
On 04/07/2014 10:11 AM, Arnd Bergmann wrote:
On Monday 07 April 2014 08:38:28 Mike Looijmans wrote:
index 34aef81..43b90c1 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2972,6 +2972,8 @@ int sdhci_add_host(struct sdhci_host *host)
host-vqmmc
writing these DTS by hand which is not our case - at least
for majority of our customers.
I write them by hand. Is there any other way?
Mike.
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon
On 04/07/2014 02:25 PM, Arnd Bergmann wrote:
On Monday 07 April 2014 13:18:54 Ben Dooks wrote:
On 07/04/14 13:16, Ben Dooks wrote:
On 07/04/14 13:09, Mike Looijmans wrote:
On 04/07/2014 10:11 AM, Arnd Bergmann wrote:
On Monday 07 April 2014 08:38:28 Mike Looijmans wrote:
index 34aef81
On 04/07/2014 02:51 PM, Arnd Bergmann wrote:
On Monday 07 April 2014 14:32:20 Mike Looijmans wrote:
On 04/07/2014 02:25 PM, Arnd Bergmann wrote:
Judging from the kernel output, regulator_get_optional returns -ENODEV if the
supply wasn't found.
Maybe the API is confusing (or wrong?) here
If vmmc or vqmmc regulators are controlled by an I2C device, the
request for the regulator is likely to fail because the I2C bus has
not been probed yet. The sdhci then incorrectly assumes that the user
never wanted to use a regulator anyway and continues without ever
enabling or configuring the
If vmmc or vqmmc regulators are controlled by an I2C device, the
request for the regulator is likely to fail because the I2C bus has
not been probed yet. The sdhci then incorrectly assumes that the user
never wanted to use a regulator anyway and continues without ever
enabling or configuring the
On 26-3-2014 16:09, Georgi Djakov wrote:
On 03/07/2014 04:18 PM, Mike Looijmans wrote:
If vmmc or vqmmc regulators are controlled by an I2C device, the
request for the regulator is likely to fail because the I2C bus has
not been probed yet. The sdhci then incorrectly assumes that the user
never
On 26-3-2014 16:09, Georgi Djakov wrote:
On 03/07/2014 04:18 PM, Mike Looijmans wrote:
If vmmc or vqmmc regulators are controlled by an I2C device, the
request for the regulator is likely to fail because the I2C bus has
not been probed yet. The sdhci then incorrectly assumes that the user
never
ED.
# devmem 0XF8000830
0x002E
Register 0XF8000830 is SD0_WP_CD_SEL, and 0x002E sets CD to pin 46 and
WP to pin "0", not to EMIO as I specified in the design.
"
Eli: Maybe you have the same issue as Mike. Can you please check it?
Met vriendelijke groet / kind regards,
is SD0_WP_CD_SEL, and 0x002E sets CD to pin 46 and
WP to pin 0, not to EMIO as I specified in the design.
Eli: Maybe you have the same issue as Mike. Can you please check it?
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH
from that
driver as well.
Cool, thanks!
Are you going to update the davinci patch as well?
An amended patch is on its way now. I forgot to set the subject to "PATCHv2"
though.
Mike.
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-
recovery" storm and not being
able to communicate via I2C for several seconds. With this patch, I2C
transactions will not be interrupted or otherwise halfway completed.
v2: Completely ignore signals.
Signed-off-by: Mike Looijmans
---
drivers/i2c/busses/i2c-davinci.c | 17 +
to communicate via I2C for several seconds. With this patch, I2C
transactions will not be interrupted or otherwise halfway completed.
v2: Completely ignore signals.
Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
---
drivers/i2c/busses/i2c-davinci.c | 17 +
1 file changed, 9
from that
driver as well.
Cool, thanks!
Are you going to update the davinci patch as well?
An amended patch is on its way now. I forgot to set the subject to PATCHv2
though.
Mike.
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH
on this topic:
http://lkml.org/lkml/2014/1/9/246
Signed-off-by: Mike Looijmans
---
drivers/i2c/busses/i2c-cadence.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index 86713d6..c61c3c9 100644
On 03/11/2014 05:49 AM, Suneel Garapati wrote:
Hi Mike/Soren,
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69 70
E-mail
On 03/11/2014 05:49 AM, Suneel Garapati wrote:
Hi Mike/Soren,
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69 70
E-mail
on this topic:
http://lkml.org/lkml/2014/1/9/246
Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
---
drivers/i2c/busses/i2c-cadence.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index
Pressing CTRL-C while communicating with an I2C device leads to erratic
behaviour. The cause is that the controller will interrupt the I2C transfer
in progress, and leave the client device in an undefined state. Many
drivers do not handle error return codes on I2C transfers. The calling driver
has
On 03/09/2014 09:21 PM, Wolfram Sang wrote:
On Thu, Jan 09, 2014 at 12:11:25PM +0100, Mike Looijmans wrote:
When a signal is caught while the i2c-davinci bus driver is transferring,
the drive just "abandons" the transfer and leaves the controller to fend
for itself. The next I2C t
a 2.6.37 kernel, and that's currently the
only board we have with an OMAP-L1.
Mike.
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69 70
E-mail
On 03/09/2014 09:28 PM, Wolfram Sang wrote:
On Fri, Feb 28, 2014 at 11:32:05AM +0100, mike.looijm...@topic.nl wrote:
From: Mike Looijmans
Having a board where the I2C bus locks up occasionally made it clear
that the bus recovery in the i2c-davinci driver will only work on
some boards
On 03/09/2014 09:28 PM, Wolfram Sang wrote:
On Fri, Feb 28, 2014 at 11:32:05AM +0100, mike.looijm...@topic.nl wrote:
From: Mike Looijmans milo-softw...@users.sourceforge.net
Having a board where the I2C bus locks up occasionally made it clear
that the bus recovery in the i2c-davinci driver
a 2.6.37 kernel, and that's currently the
only board we have with an OMAP-L1.
Mike.
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69 70
E-mail
On 03/09/2014 09:21 PM, Wolfram Sang wrote:
On Thu, Jan 09, 2014 at 12:11:25PM +0100, Mike Looijmans wrote:
When a signal is caught while the i2c-davinci bus driver is transferring,
the drive just abandons the transfer and leaves the controller to fend
for itself. The next I2C transaction
Pressing CTRL-C while communicating with an I2C device leads to erratic
behaviour. The cause is that the controller will interrupt the I2C transfer
in progress, and leave the client device in an undefined state. Many
drivers do not handle error return codes on I2C transfers. The calling driver
has
If vmmc or vqmmc regulators are controlled by an I2C device, the
request for the regulator is likely to fail because the I2C bus has
not been probed yet. The sdhci then incorrectly assumes that the user
never wanted to use a regulator anyway and continues without ever
enabling or configuring the
If vmmc or vqmmc regulators are controlled by an I2C device, the
request for the regulator is likely to fail because the I2C bus has
not been probed yet. The sdhci then incorrectly assumes that the user
never wanted to use a regulator anyway and continues without ever
enabling or configuring the
are either) to which logic level
the wp happens to think it's wired. I just want to be able to tell the driver
that the WP line is
free-floating-and-might-have-any-random-value-at-any-given-moment which is a
bit long, so I'd go for disable-wp instead.
Mike.
Met vriendelijke groet / kind rega
logic level
the wp happens to think it's wired. I just want to be able to tell the driver
that the WP line is
free-floating-and-might-have-any-random-value-at-any-given-moment which is a
bit long, so I'd go for disable-wp instead.
Mike.
Met vriendelijke groet / kind regards,
Mike Looijmans
From: Mike Looijmans
Having a board where the I2C bus locks up occasionally made it clear
that the bus recovery in the i2c-davinci driver will only work on
some boards, because on regular boards, this will only toggle GPIO
lines that aren't muxed to the actual pins.
The I2C controller has
From: Mike Looijmans milo-softw...@users.sourceforge.net
Having a board where the I2C bus locks up occasionally made it clear
that the bus recovery in the i2c-davinci driver will only work on
some boards, because on regular boards, this will only toggle GPIO
lines that aren't muxed to the actual
When a board does not have the WP line wired at all, the card
may be detected as read-only. Add a quirk and a device property
to disable WP detection.
Signed-off-by: Mike Looijmans
---
drivers/mmc/host/sdhci-pltfm.c |3 +++
drivers/mmc/host/sdhci.c |3 ++-
include/linux/mmc
When a board does not have the WP line wired at all, the card
may be detected as read-only. Add a quirk and a device property
to disable WP detection.
Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
---
drivers/mmc/host/sdhci-pltfm.c |3 +++
drivers/mmc/host/sdhci.c |3
e messages.
Before this patch, reading an I2C device in a loop and interrupting it
often resulted in a "initiating i2c bus recovery" storm and not being
able to communicate via I2C for several seconds. With this patch, the
userspace call simply returns EINTR and the next I2C transaction
succe
an I2C device in a loop and interrupting it
often resulted in a initiating i2c bus recovery storm and not being
able to communicate via I2C for several seconds. With this patch, the
userspace call simply returns EINTR and the next I2C transaction
succeeds without errors.
Signed-off-by: Mike Looijmans
On 11/26/2013 01:28 PM, Wolfram Sang wrote:
CCing linux-pm, maybe they know more...
The extra I2C traffic consumes extra power. If the bus is terminated
using 2k resistors, approximately 1mA of current (assuming ~2V
signals) is flowing when the bus is pulled low. On low power
designs, this
On 11/26/2013 10:06 AM, Wolfram Sang wrote:
On Tue, Nov 26, 2013 at 07:32:00AM +0100, Mike Looijmans wrote:
Leaving the mux enabled causes needless I2C traffic on the downstream
bus. De-selecting after every request causes excess I2C traffic and
switching.
This patch implements a hybrid
On 11/26/2013 10:06 AM, Wolfram Sang wrote:
On Tue, Nov 26, 2013 at 07:32:00AM +0100, Mike Looijmans wrote:
Leaving the mux enabled causes needless I2C traffic on the downstream
bus. De-selecting after every request causes excess I2C traffic and
switching.
This patch implements a hybrid
On 11/26/2013 01:28 PM, Wolfram Sang wrote:
CCing linux-pm, maybe they know more...
The extra I2C traffic consumes extra power. If the bus is terminated
using 2k resistors, approximately 1mA of current (assuming ~2V
signals) is flowing when the bus is pulled low. On low power
designs, this
Leaving the mux enabled causes needless I2C traffic on the downstream
bus. De-selecting after every request causes excess I2C traffic and
switching.
This patch implements a hybrid solution: After 200ms of inactivity,
the mux is disabled.
Signed-off-by: Mike Looijmans
---
drivers/i2c/muxes/i2c
Leaving the mux enabled causes needless I2C traffic on the downstream
bus. De-selecting after every request causes excess I2C traffic and
switching.
This patch implements a hybrid solution: After 200ms of inactivity,
the mux is disabled.
Signed-off-by: Mike Looijmans
---
drivers/i2c/muxes/i2c
Leaving the mux enabled causes needless I2C traffic on the downstream
bus. De-selecting after every request causes excess I2C traffic and
switching.
This patch implements a hybrid solution: After 200ms of inactivity,
the mux is disabled.
Signed-off-by: Mike Looijmans
---
drivers/i2c/muxes/i2c
Leaving the mux enabled causes needless I2C traffic on the downstream
bus. De-selecting after every request causes excess I2C traffic and
switching.
This patch implements a hybrid solution: After 200ms of inactivity,
the mux is disabled.
Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
Leaving the mux enabled causes needless I2C traffic on the downstream
bus. De-selecting after every request causes excess I2C traffic and
switching.
This patch implements a hybrid solution: After 200ms of inactivity,
the mux is disabled.
Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
Leaving the mux enabled causes needless I2C traffic on the downstream
bus. De-selecting after every request causes excess I2C traffic and
switching.
This patch implements a hybrid solution: After 200ms of inactivity,
the mux is disabled.
Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
501 - 552 of 552 matches
Mail list logo
