[RFC 0/2] drivers: spi/i2c: account completions as iowait

So, I recently learned that there is wait_for_completion_io_* because one I2C driver uses it instead of wait_for_completion_*. I want consistency, so technically the io-versions seem to be the correct ones to me, because, well, we are waiting for IO. However, researching the net, users currently

[RFC 2/2] spi: account completions as iowait

We are waiting for IO, so it should be accounted as such. Signed-off-by: Wolfram Sang w...@the-dreams.de --- drivers/spi/spi-altera.c | 2 +- drivers/spi/spi-atmel.c | 2 +- drivers/spi/spi-au1550.c | 4 ++-- drivers/spi/spi-bcm2835.c| 2 +-

[RFC 1/2] i2c: account completions as iowait

We are waiting for IO, so it should be accounted as such. Signed-off-by: Wolfram Sang w...@the-dreams.de --- drivers/i2c/busses/i2c-axxia.c | 4 ++-- drivers/i2c/busses/i2c-bcm-kona.c| 8 drivers/i2c/busses/i2c-bcm2835.c | 2 +-

Re: [RFC 0/2] drivers: spi/i2c: account completions as iowait

On Sun, Nov 02, 2014 at 02:58:07PM +0100, Wolfram Sang wrote: However, researching the net, users currently interpret iowait entirely as blkio wait. Furthermore, io_schedule() calls delayacct_blkio_{start|end}() which worked fine for my tests with I2C but might show that iowait was really

Re: Problem with multiple i2c multiplexers on the same bus

I rediscovered this series: http://www.spinics.net/lists/linux-i2c/msg11542.html (i2c-mux: expose i2c bus topology under sysfs) From a glimpse, I like this approach better. I wonder if we can maintain backward compatibility somehow. I need to play with it. But not today, this has to

[PATCH] i2c: mux: create proper topology in sysfs

The current implementation creates muxed i2c-n busses as immediate children of their i2c-n parent bus. In case of multiple muxes on one bus, it is impossible to determine which muxed bus comes from which mux. Change the topology so that they are created under the corresponding mux device. This

Re: [RFC 0/3] i2c: sh_mobile: add DMA support

Hi Wolfram, On Friday 31 October 2014 11:51:15 Wolfram Sang wrote: Here is my RFC to support DMA with the i2c-sh_mobile core. DMA works nicely with my tests so far and we save 1 interrupt per transferred byte, yay! Do we have an idea of how much power (or CPU time ?) DMA support could save ?

Re: [RFC 2/3] ARM: shmobile: r8a7790: add DMA nodes for IIC

Hi Wolfram, Thank you for the patch. On Friday 31 October 2014 11:51:17 Wolfram Sang wrote: From: Wolfram Sang wsa+rene...@sang-engineering.com Signed-off-by: Wolfram Sang wsa+rene...@sang-engineering.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com ---

Re: [RFC 3/3] ARM: shmobile: r8a7791: add DMA nodes for IIC

Hi Wolfram, Thank you for the patch. On Friday 31 October 2014 11:51:18 Wolfram Sang wrote: From: Wolfram Sang wsa+rene...@sang-engineering.com Signed-off-by: Wolfram Sang wsa+rene...@sang-engineering.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com ---

Re: [RFC 0/3] i2c: sh_mobile: add DMA support

Here is my RFC to support DMA with the i2c-sh_mobile core. DMA works nicely with my tests so far and we save 1 interrupt per transferred byte, yay! Do we have an idea of how much power (or CPU time ?) DMA support could save ? I have some numbers from the function tracer, but I don't trust

Re: [RFC 1/3] i2c: sh_mobile: add DMA support

Hi Wolfram, Thank you for the patch. On Friday 31 October 2014 11:51:16 Wolfram Sang wrote: From: Wolfram Sang wsa+rene...@sang-engineering.com Make it possible to transfer i2c message buffers via DMA. Start/Stop/Sending_Slave_Adress is still handled using the old state machine, it is

Re: [RFC 1/3] i2c: sh_mobile: add DMA support

@@ -33,6 +35,9 @@ #include linux/io.h #include linux/slab.h #include linux/of_device.h +#include linux/dmaengine.h +#include linux/dma-mapping.h +#include linux/sh_dma.h I would have tried to keep the headers alphabetically sorted, if they had been sorted in the first place