If the i2c-parent bus driver is not loaded, returning
-EINVAL will force people to unload and then reload the
module again to get it working.
Also of_get_named_gpio could return -E_PROBE_DEFER or
another error code. This error should be passed further
instead of being ignored.
Signed-off-by: Ionu
On 08.10.2013 15:30, ext Peter Korsgaard wrote:
>> "IN" == Ionut Nicu writes:
>
> IN> If the i2c-parent bus driver is not loaded, returning
> IN> -EINVAL will force people to unload and then reload the
> IN> module again to get it working.
>
> IN> Also of_get_named_gpio could return -E_PROBE
> "IN" == Ionut Nicu writes:
IN> If the i2c-parent bus driver is not loaded, returning
IN> -EINVAL will force people to unload and then reload the
IN> module again to get it working.
IN> Also of_get_named_gpio could return -E_PROBE_DEFER or
IN> another error code. This error should be passed
If the i2c-parent bus driver is not loaded, returning
-EINVAL will force people to unload and then reload the
module again to get it working.
Signed-off-by: Ionut Nicu
---
drivers/i2c/muxes/i2c-mux-gpio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/muxes
of_get_named_gpio could return -E_PROBE_DEFER or another
error code. This error should be passed further instead
of being ignored.
Signed-off-by: Ionut Nicu
---
drivers/i2c/muxes/i2c-mux-gpio.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/muxes/i2
> "IN" == Ionut Nicu writes:
IN> If the i2c-parent bus driver is not loaded, returning
IN> -EINVAL will force people to unload and then reload the
IN> module again to get it working.
IN> Signed-off-by: Ionut Nicu
Acked-by: Peter Korsgaard
--
Sorry about disclaimer - It's out of my contro
> "IN" == Ionut Nicu writes:
IN> of_get_named_gpio could return -E_PROBE_DEFER or another
IN> error code. This error should be passed further instead
IN> of being ignored.
Acked-by: Peter Korsgaard
--
Sorry about disclaimer - It's out of my control.
Bye, Peter Korsgaard
This message is sub
This patch allows to set independantly SCL and SDA falling times.
The tLOW period is computed by taking into account the SCL falling time.
The tHIGH period is computed by taking into account the SDA falling time.
For instance in case the margin on tLOW is considered too small, it can
be increase
Some legacy devices support ony I2C standard mode at 100kHz.
This patch allows to select the standard mode through the DTS
with the use of the existing clock-frequency parameter.
When clock-frequency parameter is not set, the fast mode is selected.
Only when the parameter is set at 10, the s
This patch supplies I2C configuration to B2000 and B2020
based on either STiH415 or STiH416 SoCs.
Signed-off-by: Maxime Coquelin
---
arch/arm/boot/dts/stih41x-b2000.dtsi |9 +
arch/arm/boot/dts/stih41x-b2020.dtsi | 22 ++
2 files changed, 31 insertions(+)
diff
The goal of this series is to add I2C support to ST SoCs.
The DT definition is added for STiH415 and STiH416 SoCs on
B2000 and B2020 boards.
The series has been tested working on STiH416-B2020 board.
It applies on top of v3.12-rc4.
Changes since v3:
- Switch back to vendor specific DT propertie
This patch supplies I2C configuration to STiH416 SoC.
Signed-off-by: Maxime Coquelin
---
arch/arm/boot/dts/stih416-pinctrl.dtsi | 35 +
arch/arm/boot/dts/stih416.dtsi | 53
2 files changed, 88 insertions(+)
diff --git a/arch/arm/b
This patch adds support to SSC (Synchronous Serial Controller)
I2C driver. This IP also supports SPI protocol, but this is not
the aim of this driver.
This IP is embedded in all ST SoCs for Set-top box platorms, and
supports I2C Standard and Fast modes.
Signed-off-by: Maxime Coquelin
---
Docume
This patch supplies I2C configuration to STiH415 SoC.
Signed-off-by: Maxime Coquelin
---
arch/arm/boot/dts/stih415-pinctrl.dtsi | 36 ++
arch/arm/boot/dts/stih415.dtsi | 53
2 files changed, 89 insertions(+)
diff --git a/arch/arm/
We had some issues with deferred probing in the I2C subsystem. This series
attempts to fix a part of it. From the patch description:
===
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
funct
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Signed-of
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Signed-of
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Signed-of
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Signed-of
On Fri, Aug 30, 2013 at 01:27:13AM -0700, Tony Lindgren wrote:
> * zhangfei gao [130829 23:36]:
> > What about concerns from Wolfram:
> > " Other people might be
> > depending on subsys_initcall to get I2C active before they want to
> > activate, say, PMICs. So, I fear regressions, since deferred
Dear Wolfram Sang,
> Subsystems like pinctrl and gpio rightfully make use of deferred probing at
> core level. Now, deferred drivers won't be retried if they don't have a
> .probe function specified in the driver struct. Fix this driver to have
> that, so the devices it supports won't get lost in
On Tue, Oct 08, 2013 at 03:51:50PM +0200, Ionut Nicu wrote:
> If the i2c-parent bus driver is not loaded, returning
> -EINVAL will force people to unload and then reload the
> module again to get it working.
>
> Signed-off-by: Ionut Nicu
Doesn't the non-DT case need fixing, too?
> ---
> driver
* Wolfram Sang [131008 14:01]:
> On Fri, Aug 30, 2013 at 01:27:13AM -0700, Tony Lindgren wrote:
> > * zhangfei gao [130829 23:36]:
> > > What about concerns from Wolfram:
> > > " Other people might be
> > > depending on subsys_initcall to get I2C active before they want to
> > > activate, say, PM
On 10/09/2013 04:53 AM, Wolfram Sang wrote:
On Fri, Aug 30, 2013 at 01:27:13AM -0700, Tony Lindgren wrote:
* zhangfei gao [130829 23:36]:
What about concerns from Wolfram:
" Other people might be
depending on subsys_initcall to get I2C active before they want to
activate, say, PMICs. So, I f
> "WS" == Wolfram Sang writes:
WS> On Tue, Oct 08, 2013 at 03:51:50PM +0200, Ionut Nicu wrote:
>> If the i2c-parent bus driver is not loaded, returning
>> -EINVAL will force people to unload and then reload the
>> module again to get it working.
>>
>> Signed-off-by: Ionut Nicu
WS> Doesn't t
25 matches
Mail list logo
