Re: rt-mutex usage in i2c
On 03/15/2015 08:07 AM, Mike Rapoport wrote:
On Sat, Mar 14, 2015 at 1:32 PM, Wolfram Sang w...@the-dreams.de wrote:
On Sat, Mar 14, 2015 at 12:27:03PM +0100, Wolfram Sang wrote:
Hi Sebastian,
- i2c_transfer() has this piece:
2091 if (in_atomic() || irqs_disabled()) {
2092 ret = i2c_trylock_adapter(adap);
is this irqs_disabled() is what bothers me and should not be there.
pxa does a spin_lock_irq() which would enable interrupts on return /
too early.
mxs has a wait_for_completion() which needs irqs enabled _and_ makes
in_atomic() problematic, too. I have't checked other drivers but the
commit, that introduced it, does not explain why it is required.
That was some time ago, but as far as I remember, PIO in i2c_pxa was
required to enable communication with PMIC in interrupt context.
Let me add one thing I forgot: the locking is using raw locks which are
not irq safe. It usually works. But. If the wait_lock is hold during
the unlock's slow path (that means there is no owner but the owner
field is not yet NULL) and the interrupt handler gets here with a
try_lock attempt then and it will spin forever on the wait_lock.
I will try to lookup the threads later…
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] dts: msm8974: Add dma channels for blsp2_i2c1 node
Hi, On Fri, Mar 13, 2015 at 11:19:52PM +0530, Sricharan R wrote: Signed-off-by: Sricharan R sricha...@codeaurora.org --- Reviewed-by: Andy Gross agr...@codeaurora.org arch/arm/boot/dts/qcom-msm8974.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi index 3f648ae..1ec7ec5 100644 --- a/arch/arm/boot/dts/qcom-msm8974.dtsi +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi @@ -246,6 +246,8 @@ clock-names = core, iface; #address-cells = 1; #size-cells = 0; +dmas = blsp2_dma 20, blsp2_dma 21; +dma-names = bam-tx, bam-rx; more of a nit, but the bam- is unnecessary. it's just rx/tx. Ok, will change it. Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters
On Mon, Feb 16, 2015 at 01:09:51PM +0100, Wolfram Sang wrote: Hi Guenter, I wonder where we are with thisp patch; I don't recall a reply to my previous e-mail. Sorry for the late reply. I needed to recover from a HDD headcrash :( Do you need some more time to think about it ? Otherwise I'll publish an out-of-tree version of the at24 driver with the patch applied on github, for those who might need the functionality provided by this patch. Your last mail made me aware of why we were missing each other before. I see your point now, but yes, still need to think about it. My plan is to have a decision until the 3.21 merge window. Hi Wolfram, any news ? Thanks, Guenter -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] serial: sc16is7xx: bunch of small fixes
From: Jakub Kicinski kubak...@wp.pl This series fixes three small problems with the sc16is7xx driver and adds an ability to configure from user space the RTS inversion for RS-485 mode. None of the fixed issues is pressing so this seems like a -next material (based on tty.git/tty-next). Jakub Kicinski (4): sc16is7xx: remove ports on probe error path sc16is7xx: don't wipe out port configuration on shutdown sc16is7xx: expose RTS inversion in RS-485 mode sc16is7xx: enable the clock drivers/tty/serial/sc16is7xx.c | 44 ++ 1 file changed, 32 insertions(+), 12 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] sc16is7xx: don't wipe out port configuration on shutdown
From: Jakub Kicinski kubak...@wp.pl EFCR register contains RS-485 configuration which should not be changed by shutdown. Instead of doing a write only update the appropriate bits. Signed-off-by: Jakub Kicinski kubak...@wp.pl --- drivers/tty/serial/sc16is7xx.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index 11bb44039a57..e6b396e584f3 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -903,9 +903,11 @@ static void sc16is7xx_shutdown(struct uart_port *port) /* Disable all interrupts */ sc16is7xx_port_write(port, SC16IS7XX_IER_REG, 0); /* Disable TX/RX */ - sc16is7xx_port_write(port, SC16IS7XX_EFCR_REG, -SC16IS7XX_EFCR_RXDISABLE_BIT | -SC16IS7XX_EFCR_TXDISABLE_BIT); + sc16is7xx_port_update(port, SC16IS7XX_EFCR_REG, + SC16IS7XX_EFCR_RXDISABLE_BIT | + SC16IS7XX_EFCR_TXDISABLE_BIT, + SC16IS7XX_EFCR_RXDISABLE_BIT | + SC16IS7XX_EFCR_TXDISABLE_BIT); sc16is7xx_power(port, 0); } -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] sc16is7xx: expose RTS inversion in RS-485 mode
From: Jakub Kicinski kubak...@wp.pl
Hardware is capable of inverting RTS signal when working
in RS-485 mode. Expose this functionality to user space.
Relay on a matching combination of standard flags
(SER_RS485_RTS_ON_SEND and SER_RS485_RTS_AFTER_SEND) to
detect when user space is requesting inverted RTS mode.
Signed-off-by: Jakub Kicinski kubak...@wp.pl
---
drivers/tty/serial/sc16is7xx.c | 32 +++-
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
index e6b396e584f3..24902d589b07 100644
--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -829,16 +829,30 @@ static void sc16is7xx_set_termios(struct uart_port *port,
}
static int sc16is7xx_config_rs485(struct uart_port *port,
- struct serial_rs485 *rs485)
+ struct serial_rs485 *rs485)
{
- if (port-rs485.flags SER_RS485_ENABLED)
- sc16is7xx_port_update(port, SC16IS7XX_EFCR_REG,
- SC16IS7XX_EFCR_AUTO_RS485_BIT,
- SC16IS7XX_EFCR_AUTO_RS485_BIT);
- else
- sc16is7xx_port_update(port, SC16IS7XX_EFCR_REG,
- SC16IS7XX_EFCR_AUTO_RS485_BIT,
- 0);
+ const u32 mask = SC16IS7XX_EFCR_AUTO_RS485_BIT |
+SC16IS7XX_EFCR_RTS_INVERT_BIT;
+ u32 efcr = 0;
+
+ if (rs485-flags SER_RS485_ENABLED) {
+ bool rts_during_rx, rts_during_tx;
+
+ rts_during_rx = rs485-flags SER_RS485_RTS_AFTER_SEND;
+ rts_during_tx = rs485-flags SER_RS485_RTS_ON_SEND;
+
+ efcr |= SC16IS7XX_EFCR_AUTO_RS485_BIT;
+
+ if (!rts_during_rx rts_during_tx)
+ /* default */;
+ else if (rts_during_rx !rts_during_tx)
+ efcr |= SC16IS7XX_EFCR_RTS_INVERT_BIT;
+ else
+ return -EINVAL;
+ }
+
+ sc16is7xx_port_update(port, SC16IS7XX_EFCR_REG, mask, efcr);
+
port-rs485 = *rs485;
return 0;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] sc16is7xx: remove ports on probe error path
From: Jakub Kicinski kubak...@wp.pl If ports are not explicitly removed on the error path the device will not get properly unregistered leaving /dev/ttySC* nodes in the filesystem. Signed-off-by: Jakub Kicinski kubak...@wp.pl --- drivers/tty/serial/sc16is7xx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index df9a384dfbda..11bb44039a57 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -1120,6 +1120,9 @@ static int sc16is7xx_probe(struct device *dev, if (!ret) return 0; + for (i = 0; i s-uart.nr; i++) + uart_remove_one_port(s-uart, s-p[i].port); + mutex_destroy(s-mutex); #ifdef CONFIG_GPIOLIB -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] sc16is7xx: enable the clock
From: Jakub Kicinski kubak...@wp.pl
Although clk_disable_unprepare() is called both on .remove()
and in .probe() error path, the clock is never actually enabled.
Signed-off-by: Jakub Kicinski kubak...@wp.pl
---
drivers/tty/serial/sc16is7xx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
index 24902d589b07..20573d72715d 100644
--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -1064,6 +1064,7 @@ static int sc16is7xx_probe(struct device *dev,
else
return PTR_ERR(s-clk);
} else {
+ clk_prepare_enable(s-clk);
freq = clk_get_rate(s-clk);
}
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c-tools: add Android.mk
Dear Jean Delvare, The Android build system requires an Android.mk into the root dir of a package. Android simply doesn't use recursive makefile. So if you want to drop i2c-tools into the android source tree to having it compiled by the Android build system, you should add an Android.mk manually. Probably, the other projects you mention are compiled externelly from the Android build system with an external toolchain, so calling make with the right options is not a problem. I think that all projects potentially interesting in the Android world should adopt an Android.mk to be easily buildable into the Android build system. Sincerely, Angelo. 2015-03-16 10:16 GMT+01:00 Jean Delvare jdelv...@suse.de: Hi Angelo, On Fri, 27 Feb 2015 22:05:12 +0100, Angelo Compagnucci wrote: This patch adds an Android.mk to compile i2c-tools under Android. Hope this helps! I have to say I don't know what to do with this. For one thing, I don't really understand why Android needs a separate build mechanism when all other Linux and BSD incarnations seem to be fine with the standard Makefile. GNU make certainly runs on Android, right? And you would typically cross-compile for Android anyway. Also I have not seen an Android.mk file in any other project I'm working on, and I can't see why i2c-tools would be special in this respect. For another, the current build mechanism is a modular one where the main Makefile includes Module.mk files present in the different subdirectories. I like this design and having a single Android.mk file at the root of the project is inconsistent and breaks that design. As a summary I don't see why anything special is needed for Android, but if something like that is really needed then it should respect the existing modular design. 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.) Thanks, -- Jean Delvare SUSE L3 Support -- Profile: http://it.linkedin.com/in/compagnucciangelo -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] i2c: mux-pinctrl: Rework to honor disabled child nodes
On 10.03.2015 17:28, Stephen Warren wrote: On 03/09/2015 06:21 AM, Sebastian Hesselbarth wrote: I2C mux pinctrl driver currently determines the number of sub-busses by counting available pinctrl-names. Unfortunately, this requires each incarnation of the devicetree node with different available sub-busses to be rewritten. This patch reworks i2c-mux-pinctrl driver to count the number of available sub-nodes instead. The rework should be compatible to the old way of probing for sub-busses and additionally allows to disable unused sub-busses with standard DT property status = disabled. This also amends the corresponding devicetree binding documentation to reflect the new functionality to disable unused sub-nodes. While at it, also fix two references to binding documentation files that miss an i2c- prefix. The DT binding changes at least, Acked-by: Stephen Warren swar...@nvidia.com Wolfram, are you going to pick this patch through your tree now that Stephen ack'ed the binding documentation change, too? I can also split the patch up into driver/doc changes if you prefer. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c-tools: add Android.mk
Hi Angelo, On Fri, 27 Feb 2015 22:05:12 +0100, Angelo Compagnucci wrote: This patch adds an Android.mk to compile i2c-tools under Android. Hope this helps! I have to say I don't know what to do with this. For one thing, I don't really understand why Android needs a separate build mechanism when all other Linux and BSD incarnations seem to be fine with the standard Makefile. GNU make certainly runs on Android, right? And you would typically cross-compile for Android anyway. Also I have not seen an Android.mk file in any other project I'm working on, and I can't see why i2c-tools would be special in this respect. For another, the current build mechanism is a modular one where the main Makefile includes Module.mk files present in the different subdirectories. I like this design and having a single Android.mk file at the root of the project is inconsistent and breaks that design. As a summary I don't see why anything special is needed for Android, but if something like that is really needed then it should respect the existing modular design. 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.) Thanks, -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
