Hi Wolfram,
On Thu, 3 May 2012 13:35:46 +0200, Wolfram Sang wrote:
On Thu, May 03, 2012 at 11:53:36AM +0100, Mark Brown wrote:
Since there are uses for I2C_M_NOSTART which are much more sensible and
standard than most of the protocol mangling functionality (the main one
being gather writes
Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
protocol Rev. 03 section 3.16 titled Bus clear.
http://www.nxp.com/documents/user_manual/UM10204.pdf
Sometimes during operation i2c bus hangs and we need to give dummy clocks to
slave device to start the transfer again.
Hi Wolfram,
This patchset adds i2c bus recovery infrastructure to i2c adapters as specified
in the i2c protocol Rev. 03 section 3.16 titled Bus clear.
http://www.nxp.com/documents/user_manual/UM10204.pdf
This patch was earlier part of a separate thread:
Add bus recovery support for designware_i2c controller. It uses generic gpio
based i2c_gpio_recover_bus() routine.
Signed-off-by: Vincenzo Frascino vincenzo.frasc...@st.com
Signed-off-by: Shiraz Hashim shiraz.has...@st.com
Signed-off-by: Viresh Kumar viresh.ku...@st.com
---
On Thu, May 03, 2012 at 08:36:17PM +0200, Jean Delvare wrote:
You must also update the description of I2C_FUNC_PROTOCOL_MANGLING to
no longer mention I2C_M_NOSTART.
For backwards ABI compatibility _PROTCOL_MANGING still has to imply
_NOSTART, though it's unclear if that should be documented
On Thu, May 03, 2012 at 08:36:17PM +0200, Jean Delvare wrote:
This is all correct, but it should be documented in
Documentation/i2c/i2c-protocol. At the moment documentation still says
that I2C_M_NOSTART is a weird protocol quirk nobody should be using.
When you update the documentation, I
On Thu, May 03, 2012 at 09:25:37PM +0200, Rafael J. Wysocki wrote:
On Thursday, May 03, 2012, Mark Brown wrote:
This seems like a really useful idiom in general - might it be worth
supporting as a standard framework feature?
The generic PM domains framework does this, it's not
Hello,
this v3 patchset is now pending for more than 1 month without
seeing comments for it. Are there no more issues?
Should I rebase it (if no further comments occur), as it is
pending so long? (If so, against which tree?)
Thanks.
bye,
Heiko
Heiko Schocher wrote:
This patchserie add
Here's your next back of DT related doings for the ux500,
along with some bugs encountered fixed along the way.
arch/arm/boot/dts/db8500.dtsi | 103 +-
arch/arm/boot/dts/snowball.dts |3 +
arch/arm/configs/u8500_defconfig |1 +
arch/arm/mach-ux500/board-mop500.c |
Now that u5500 is obsolete, u8500 is the only user of the Nomadik
i2c driver. As such there is no requirement to differentiate between
initialisation values. By the time a new SoC is released, almost all
of the ux500 platform will be DT:ed, so we can make decisions based
on the compatible property
Code exists in the mop500 board file (used for HREF and
Snowball) to initialise Snowball's user LED via the
leds-gpio driver. However, the driver isn't currently
built when using the default configuration file. This
patch aims to change that behavior.
Signed-off-by: Lee Jones lee.jo...@linaro.org
In their current state the ab8500 power devices explode if platform data
isn't provided. This patch prevents this from happening and informs the
user of what has happened.
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
drivers/power/ab8500_btemp.c | 12
This patch will enable probing to occur during a Device Tree enabled
boot. The IRQ base is expected to be located in and will be fetched
from the DT itself. We also prevent any of the db8500 regulators
from being registered here, as they will be enabled via DT instead.
Signed-off-by: Lee Jones
This applies a supply alias for the db8500's fifth Nomadik i2c port.
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/db8500-prcmu.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 9bc75a8..d534449 100644
---
ab8500's probe() function is becoming quite large, so in the lead
up to Device Tree enablement which will fork the thread of execution
this patch splits it into 3 main areas; basic error checking will
remain in probe(), but regulator register initialisation and regulator
registration have been
The final piece of the ab8500 puzzle. Here we prevent any of the ab8500-*
drivers from being registered from platform code when Device Tree is
enabled, as we expect DT do probe each of these individually. We also
provide the relevant compatible strings, so that DT knows which nodes
it needs to pay
Hi Heiko,
On 5/4/2012 9:03 PM, Heiko Schocher wrote:
Hello,
this v3 patchset is now pending for more than 1 month without
seeing comments for it. Are there no more issues?
I am yet to get to them. I have mostly cleared my backlog and will be
looking into these next. Sorry about the delay.
On Friday, May 04, 2012, Mark Brown wrote:
On Thu, May 03, 2012 at 09:25:37PM +0200, Rafael J. Wysocki wrote:
On Thursday, May 03, 2012, Mark Brown wrote:
This seems like a really useful idiom in general - might it be worth
supporting as a standard framework feature?
The generic PM
On Friday 04 May 2012, Lee Jones wrote:
ab8500-i2c is used as core code to register the ab8500 device.
After allocating ab8500 memory, it immediately calls into
ab8500-core where the real initialisation takes place. This
patch moves all core registration and memory allocation into
the true
19 matches
Mail list logo
