dev_err(>dev,
> "could not map DMA registers\n");
> - return -ENOMEM;
> + return PTR_ERR(lp->sdma_regs);
> }
> if (pdata->dma_little_endian) {
> lp->dma_in = temac_dma_in32_le;
Acked-by: Esben Haabendal
This series inlcudes two fixes for issues when using uio_pdrv_genirq
without device tree, and support for using uio_pdrv_genirq with
non-page-aligned memory resources.
Esben Haabendal (3):
uio_pdrv_genirq: Remove warning when irq is not specified
uio_pdrv_genirq: fix use without device tree
quot;uio: Remove uio_pdrv and use uio_pdrv_genirq instead")
Signed-off-by: Esben Haabendal
Cc: sta...@vger.kernel.org
---
drivers/uio/uio_pdrv_genirq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/uio/uio_pdrv_genirq.c b/drivers/uio/uio_pdrv_genirq.c
index 1d6
in libuio).
Signed-off-by: Esben Haabendal
---
drivers/uio/uio_pdrv_genirq.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/uio/uio_pdrv_genirq.c b/drivers/uio/uio_pdrv_genirq.c
index b60173bc93ce..86f75a4fe0e3 100644
--- a/drivers/uio/uio_pdrv_genirq.c
+++ b/d
c5ecdb ("driver core: platform: Add an error message to
platform_get_irq*()")
Signed-off-by: Esben Haabendal
Cc: sta...@vger.kernel.org
---
drivers/uio/uio_pdrv_genirq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/uio/uio_pdrv_genirq.c b/drivers/uio/uio_pd
Fixes: 1b3fa5cf859b ("net: ll_temac: Cleanup multicast filter on change")
Signed-off-by: Esben Haabendal
---
drivers/net/ethernet/xilinx/ll_temac_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/ll_temac_main.c
b/drivers/ne
Avoid leaving old address table entries when using multicast. If more than
one multicast address were removed, only the first removed address would
actually be cleared.
Signed-off-by: Esben Haabendal
---
drivers/net/ethernet/xilinx/ll_temac_main.c | 7 +--
1 file changed, 5 insertions
Multicast support have been tested and is working now.
Signed-off-by: Esben Haabendal
---
drivers/net/ethernet/xilinx/ll_temac_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/ll_temac_main.c
b/drivers/net/ethernet/xilinx/ll_temac_main.c
in
temac_indirect_busywait().
To avoid excessive holding of the lock, which is now a spinlock, the
temac_device_reset() function is changed to only hold the lock for short
periods. With timeouts, it could be holding the spinlock for more than
2 seconds.
Signed-off-by: Esben Haabendal
---
drivers/net
.
Signed-off-by: Esben Haabendal
---
drivers/net/ethernet/xilinx/ll_temac_main.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/ll_temac_main.c
b/drivers/net/ethernet/xilinx/ll_temac_main.c
index 47c4515..05195ff 100644
--- a/drivers/net/ethernet/xilinx
This patch series makes the necessary fixes to ll_temac driver to make
multicast work, and enables support for it.so that multicast support can
The main change is the change from mutex to spinlock of the lock used to
synchronize access to the shared indirect register access.
Esben Haabendal (4
Greg Kroah-Hartman writes:
> On Tue, May 21, 2019 at 01:34:26PM +0200, Esben Haabendal wrote:
>> Allow getting memory resource (mapbase or iobase) as well as irq from
>> platform_device resources.
>>
>> The UPF_DEV_RESOURCES flag must be set for devices where p
Andy Shevchenko writes:
> On Tue, May 21, 2019 at 01:34:26PM +0200, Esben Haabendal wrote:
>> Allow getting memory resource (mapbase or iobase) as well as irq from
>> platform_device resources.
>>
>> The UPF_DEV_RESOURCES flag must be set for devices where p
Greg Kroah-Hartman writes:
> On Tue, May 21, 2019 at 01:50:25PM +0200, Esben Haabendal wrote:
>> Greg Kroah-Hartman writes:
>>
>> > On Tue, May 21, 2019 at 01:11:08PM +0200, Esben Haabendal wrote:
>> >> Greg Kroah-Hartman writes:
>> >>
>>
Greg Kroah-Hartman writes:
> On Tue, May 21, 2019 at 01:11:08PM +0200, Esben Haabendal wrote:
>> Greg Kroah-Hartman writes:
>>
>> >> I will try ad hold back with this thread until you get back to it.
>> >
>> > Ok, I have no idea what is
to the device.
Signed-off-by: Esben Haabendal
---
drivers/tty/serial/8250/8250_core.c | 56 +
drivers/tty/serial/8250/8250_port.c | 15 ++
include/linux/serial_core.h | 1 +
3 files changed, 62 insertions(+), 10 deletions(-)
diff --git a/drivers/tty
Greg Kroah-Hartman writes:
>> I will try ad hold back with this thread until you get back to it.
>
> Ok, I have no idea what is going on here, sorry. This is a really long
> and meandering thread, and I can't even find the original patches in my
> queue.
>
> So can you resend things and we can
Greg Kroah-Hartman writes:
> On Tue, May 14, 2019 at 11:47:41AM +0100, Lee Jones wrote:
>> On Tue, 14 May 2019, Esben Haabendal wrote:
>>
>> > Lee Jones writes:
>> >
>> > > On Tue, 07 May 2019, Esben Haabendal wrote:
>> > >
>>
Andy Shevchenko writes:
> On Tue, May 14, 2019 at 10:24 AM Esben Haabendal wrote:
>> Andy Shevchenko writes:
>> > On Tue, May 07, 2019 at 02:22:18PM +0200, Esben Haabendal wrote:
>
>> We are on repeat here. I don't agree with you here. I have a simple
>>
Andy Shevchenko writes:
> On Tue, May 14, 2019 at 12:23 PM Andy Shevchenko
> wrote:
>> On Tue, May 14, 2019 at 10:24 AM Esben Haabendal wrote:
>
>> > Please take a look at https://lkml.org/lkml/2019/4/9/576
>> > ("[PATCH v2 2/4] mfd: ioc3: Add driv
Lee Jones writes:
> On Tue, 07 May 2019, Esben Haabendal wrote:
>
>> Lee Jones writes:
>>
>> > On Fri, 26 Apr 2019, Esben Haabendal wrote:
>> >
>> >> The serial8250-mfd driver is for adding 8250/16550 UART ports as functions
>> >>
Andy Shevchenko writes:
> On Tue, May 07, 2019 at 02:22:18PM +0200, Esben Haabendal wrote:
>> Andy Shevchenko writes:
>> > On Tue, May 07, 2019 at 01:35:58PM +0200, Esben Haabendal wrote:
>> >> Lee Jones writes:
>> >> > On Thu, 02 May 2019, Esbe
Andy Shevchenko writes:
> On Tue, May 07, 2019 at 02:22:18PM +0200, Esben Haabendal wrote:
>> Andy Shevchenko writes:
>> > On Tue, May 07, 2019 at 01:35:58PM +0200, Esben Haabendal wrote:
>> >> Lee Jones writes:
>> >> > On Thu, 02 May 2019, Esbe
Andy Shevchenko writes:
> On Tue, May 07, 2019 at 01:35:58PM +0200, Esben Haabendal wrote:
>> Lee Jones writes:
>> > On Thu, 02 May 2019, Esben Haabendal wrote:
>> >
>> >> Could you help clarify whether or not this patch is trying to do
>>
Lee Jones writes:
> On Fri, 26 Apr 2019, Esben Haabendal wrote:
>
>> The serial8250-mfd driver is for adding 8250/16550 UART ports as functions
>> to an MFD driver.
>>
>> When calling mfd_add_device(), platform_data should be a pointer to a
>> struct plat_s
Lee Jones writes:
> On Thu, 02 May 2019, Esben Haabendal wrote:
>
>> Could you help clarify whether or not this patch is trying to do
>> something odd/wrong?
>>
>> I might be misunderstanding Andy (probably is), but the discussion
>> revolves around
Lee Jones writes:
> On Tue, 07 May 2019, Lee Jones wrote:
>> On Thu, 02 May 2019, Esben Haabendal wrote:
>>
>> > Could you help clarify whether or not this patch is trying to do
>> > something odd/wrong?
>> >
>> > I might be misunderstanding A
> On Mon, May 06, 2019 at 05:46:56PM +0200, Esben Haabendal wrote:
>> Andy Shevchenko writes:
>> >> > On Wed, May 01, 2019 at 09:17:37AM +0200, Esben Haabendal wrote:
>> >> >> Andy Shevchenko writes:
>
>> As an example, the sm501.c driver, the o
Andy Shevchenko writes:
>> > On Wed, May 01, 2019 at 09:17:37AM +0200, Esben Haabendal wrote:
>> >> Andy Shevchenko writes:
>> >
>> >> > Hmm... Currently it's done inside individual port drivers, like
>> >> > 8250_dw.c.
>> >&
"Enrico Weigelt, metux IT consult" writes:
> On 30.04.19 16:04, Esben Haabendal wrote:
>> Allow getting memory resource (mapbase or iobase) as well as irq from
>> platform_device resources.
>>
>> The UPF_DEV_RESOURCES flag must be set for devic
Wed, May 01, 2019 at 09:17:37AM +0200, Esben Haabendal wrote:
>> Andy Shevchenko writes:
>
>> > Hmm... Currently it's done inside individual port drivers, like 8250_dw.c.
>> > Each of the drivers can do it differently, for example 8250_lpss.c or
>> > 8250_pnp.c
Andy Shevchenko writes:
> On Tue, Apr 30, 2019 at 04:04:13PM +0200, Esben Haabendal wrote:
>> Remaining platform_data fields (other than mapbase, iobase, mapsize and
>> irq) are used just as before. Note
>
> Note what?
Note nothing. I will remove it, sorry about
with devices with
resources added by platform_device_add_resources(), such as mfd child
devices added with mfd_add_devices().
Remaining platform_data fields (other than mapbase, iobase, mapsize and
irq) are used just as before. Note
Signed-off-by: Esben Haabendal
---
drivers/tty/serial/8250/8250_core.c
Andy Shevchenko writes:
> On Mon, Apr 29, 2019 at 11:29:05AM +0200, Esben Haabendal wrote:
>> Andy Shevchenko writes:
>> > On Mon, Apr 29, 2019 at 9:27 AM Esben Haabendal wrote:
>> >> Andy Shevchenko writes:
>> >> > On Sat, Apr 27, 20
Andy Shevchenko writes:
> On Mon, Apr 29, 2019 at 9:27 AM Esben Haabendal wrote:
>> Andy Shevchenko writes:
>> > On Sat, Apr 27, 2019 at 12:01 PM Esben Haabendal
>> > wrote:
>> >> Andy Shevchenko writes:
>> >> > On Fri, Apr 26, 2019 at
"Enrico Weigelt, metux IT consult" writes:
> On 27.04.19 10:58, Esben Haabendal wrote:
>
> Hi folks,
>
>> That said, the purpose of UPF_BOOT_AUTOCONF (for 8250 driver) is to
>> request and map the register memory. So when that is already done by
>> th
Andy Shevchenko writes:
> On Sat, Apr 27, 2019 at 12:01 PM Esben Haabendal wrote:
>> Andy Shevchenko writes:
>> > On Fri, Apr 26, 2019 at 06:54:05PM +0200, Esben Haabendal wrote:
>> >> Andy Shevchenko writes:
>> >> The reason for this patch
Andy Shevchenko writes:
> On Fri, Apr 26, 2019 at 06:54:05PM +0200, Esben Haabendal wrote:
>> Andy Shevchenko writes:
>> > On Fri, Apr 26, 2019 at 10:40:37AM +0200, Esben Haabendal wrote:
>> >> With serial8250_register_8250_port() forcing UPF_BOOT_AUTOCONF bi
Andy Shevchenko writes:
> On Fri, Apr 26, 2019 at 10:40:36AM +0200, Esben Haabendal wrote:
>> This series adds a driver for adding 8250/16550 UART ports as functions to
>> MFD devices.
>>
>
> The patch 2/2 disappeared.
Yes, seems like that. I have resent it by itse
Andy Shevchenko writes:
> On Fri, Apr 26, 2019 at 10:40:37AM +0200, Esben Haabendal wrote:
>> With serial8250_register_8250_port() forcing UPF_BOOT_AUTOCONF bit on, it
>> is not possible to register a port without having
>> serial8250_request_std_resource() called.
>>
should be
passed as cell resources.
Do not include UPF_BOOT_AUTOCONF in platform_data.flags.
Signed-off-by: Esben Haabendal
---
drivers/tty/serial/8250/8250_mfd.c | 119 +
drivers/tty/serial/8250/Kconfig| 12
drivers/tty/serial/8250/Makefile | 1
(and rightly so)
has requested the region. For this case, the 8250 port should accept
having passed mapbase and membase, and just use that.
Signed-off-by: Esben Haabendal
---
drivers/tty/serial/8250/8250_core.c | 36 +---
include/linux/serial_8250.h | 2 ++
2
This series adds a driver for adding 8250/16550 UART ports as functions to
MFD devices.
Esben Haabendal (2):
serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF
serial: 8250: Add support for 8250/16550 as MFD function
drivers/tty/serial/8250/8250_core.c | 36
should be
passed as cell resources.
Do not include UPF_BOOT_AUTOCONF in platform_data.flags.
Signed-off-by: Esben Haabendal
---
drivers/tty/serial/8250/8250_mfd.c | 119 +
drivers/tty/serial/8250/Kconfig| 12
drivers/tty/serial/8250/Makefile | 1
(and rightly so)
has requested the region. For this case, the 8250 port should accept
having passed mapbase and membase, and just use that.
Signed-off-by: Esben Haabendal
---
drivers/tty/serial/8250/8250_core.c | 36 +---
include/linux/serial_8250.h | 2 ++
2
onfig | 9
> drivers/watchdog/watchdog_dev.c | 42 +++
> 3 files changed, 53 insertions(+), 7 deletions(-)
For the whole series:
Acked-by: Esben Haabendal
Chuanhua Han writes:
>> I am using XSPI mode on LS1021A, talking to a lot of different SPI devices.
>> And they all work, and I believe everything is quite "normal".
>>
> Since I don't have the board of LS1021, I can't test it. I use other boards
> with DSPI (such as LS1043, LS2088, etc.),
>
Chuanhua Han writes:
>> I am using XSPI mode on LS1021A, talking to a lot of different SPI devices.
>> And they all work, and I believe everything is quite "normal".
>>
> Since I don't have the board of LS1021, I can't test it. I use other boards
> with DSPI (such as LS1043, LS2088, etc.),
>
Mark Brown writes:
> On Tue, Oct 09, 2018 at 12:05:22PM +0200, Boris Brezillon wrote:
>> On Tue, 9 Oct 2018 09:52:23 +
>> Chuanhua Han wrote:
>
>> > 1. In the dspi driver (spi controller), bits_per_word
>> > (dspi->bits_per_word = transfer->bits_per_word) passed from the upper
>> > layer
Mark Brown writes:
> On Tue, Oct 09, 2018 at 12:05:22PM +0200, Boris Brezillon wrote:
>> On Tue, 9 Oct 2018 09:52:23 +
>> Chuanhua Han wrote:
>
>> > 1. In the dspi driver (spi controller), bits_per_word
>> > (dspi->bits_per_word = transfer->bits_per_word) passed from the upper
>> > layer
Chuanhua Han writes:
>> -Original Message-
>> From: Boris Brezillon
>> Sent: 2018年10月9日 18:05
>> To: Chuanhua Han
>> Cc: broo...@kernel.org; linux-...@vger.kernel.org;
>> linux-kernel@vger.kernel.org; e...@deif.com
>> Subject: Re: [PATCH 1/2] spi: spi-mem: Add the spi_set_xfer_bpw
Chuanhua Han writes:
>> -Original Message-
>> From: Boris Brezillon
>> Sent: 2018年10月9日 18:05
>> To: Chuanhua Han
>> Cc: broo...@kernel.org; linux-...@vger.kernel.org;
>> linux-kernel@vger.kernel.org; e...@deif.com
>> Subject: Re: [PATCH 1/2] spi: spi-mem: Add the spi_set_xfer_bpw
Chuanhua Han writes:
> 1. In the dspi driver (spi controller), bits_per_word (dspi->bits_per_word =
> transfer->bits_per_word) passed from the upper layer (spi-mem.c) is used.
> In this way, I can only assign the appropriate value of
> transfer->bits_per_word before passing to the controller,
Chuanhua Han writes:
> 1. In the dspi driver (spi controller), bits_per_word (dspi->bits_per_word =
> transfer->bits_per_word) passed from the upper layer (spi-mem.c) is used.
> In this way, I can only assign the appropriate value of
> transfer->bits_per_word before passing to the controller,
Boris Brezillon writes:
> On Sun, 30 Sep 2018 10:10:14 +
> Chuanhua Han wrote:
>
>> > -Original Message-
>> > From: Boris Brezillon
>> > Sent: 2018年9月30日 18:07
>> > To: Chuanhua Han
>> > Cc: broo...@kernel.org; linux-...@vger.kernel.org;
>> > linux-kernel@vger.kernel.org;
Boris Brezillon writes:
> On Sun, 30 Sep 2018 10:10:14 +
> Chuanhua Han wrote:
>
>> > -Original Message-
>> > From: Boris Brezillon
>> > Sent: 2018年9月30日 18:07
>> > To: Chuanhua Han
>> > Cc: broo...@kernel.org; linux-...@vger.kernel.org;
>> > linux-kernel@vger.kernel.org;
Chuanhua Han writes:
> This patch fixes the problem of invalid data writing during the XSPI
> mode transfer of the dspi controller.
> In XSPI mode,When I executed TX FIFO first and then CMD FIFO for XSPI
> transmission, I found that SPIx_SR[TFIWF]=1(Invalid Data present in TX
> FIFO since CMD
Chuanhua Han writes:
> This patch fixes the problem of invalid data writing during the XSPI
> mode transfer of the dspi controller.
> In XSPI mode,When I executed TX FIFO first and then CMD FIFO for XSPI
> transmission, I found that SPIx_SR[TFIWF]=1(Invalid Data present in TX
> FIFO since CMD
Chuanhua Han writes:
> This patch fixes the problem of rxdata being equal to 0 during the XSPI
> mode transfer of the dspi controller.
> In XSPI mode, If it is not deleted, the value of rxdata will be equal
> to 0, and the data received will not be received correctly, causing the
> receiving
Chuanhua Han writes:
> This patch fixes the problem of rxdata being equal to 0 during the XSPI
> mode transfer of the dspi controller.
> In XSPI mode, If it is not deleted, the value of rxdata will be equal
> to 0, and the data received will not be received correctly, causing the
> receiving
Chuanhua Han writes:
> This patch fixes the byte order inversion problem in the XSPI mode of
> the dspi controller during data transfer.
> In XSPI mode,When I read and write data without converting the byte
> order of the data, and read and write the data directly, I tested spi
> flash connected
Chuanhua Han writes:
> This patch fixes the byte order inversion problem in the XSPI mode of
> the dspi controller during data transfer.
> In XSPI mode,When I read and write data without converting the byte
> order of the data, and read and write the data directly, I tested spi
> flash connected
Boris Brezillon writes:
> Hi Chuanhua,
>
> On Sun, 30 Sep 2018 17:25:32 +0800
> Chuanhua Han wrote:
>
>> Before we add this spi_transfer to the spi_message chain table, we need
>> bits_per_word_mask based on spi_control to set the bits_per_word of
>> this spi_transfer.
>
> Let's make it
Boris Brezillon writes:
> Hi Chuanhua,
>
> On Sun, 30 Sep 2018 17:25:32 +0800
> Chuanhua Han wrote:
>
>> Before we add this spi_transfer to the spi_message chain table, we need
>> bits_per_word_mask based on spi_control to set the bits_per_word of
>> this spi_transfer.
>
> Let's make it
Chuanhua Han writes:
> This patch fixes the problem that the XSPI mode of the dspi controller
> cannot transfer data properly.
> In XSPI mode, cmd_fifo is written before tx_fifo, which transforms the
> byte order of sending and receiving data.
Did you find documentation on proper ordering of
Chuanhua Han writes:
> This patch fixes the problem that the XSPI mode of the dspi controller
> cannot transfer data properly.
> In XSPI mode, cmd_fifo is written before tx_fifo, which transforms the
> byte order of sending and receiving data.
Did you find documentation on proper ordering of
Wolfram Sang writes:
> On Thu, Aug 16, 2018 at 10:43:14AM +0200, Esben Haabendal wrote:
>> From: Esben Haabendal
>>
>> Gives substantial performance improvement for transfers larger than 16
>> bytes (DMA_THRESHOLD). Smaller transfers are unaffected.
>>
Wolfram Sang writes:
> On Thu, Aug 16, 2018 at 10:43:14AM +0200, Esben Haabendal wrote:
>> From: Esben Haabendal
>>
>> Gives substantial performance improvement for transfers larger than 16
>> bytes (DMA_THRESHOLD). Smaller transfers are unaffected.
>>
Wolfram Sang writes:
> On Thu, Aug 16, 2018 at 10:43:13AM +0200, Esben Haabendal wrote:
>> From: Esben Haabendal
>>
>> Always update the stopped state when busy status have been checked.
>> This is identical to what was done before, with the exception of er
Wolfram Sang writes:
> On Thu, Aug 16, 2018 at 10:43:13AM +0200, Esben Haabendal wrote:
>> From: Esben Haabendal
>>
>> Always update the stopped state when busy status have been checked.
>> This is identical to what was done before, with the exception of er
From: Esben Haabendal
This fixes a race condition, where the DMAEN bit ends up being set after
I2C slave has transmitted a byte following the dummy read. When that
happens, an interrupt is generated instead, and no DMA request is generated
to kickstart the DMA read, and a timeout happens after
From: Esben Haabendal
Gives substantial performance improvement for transfers larger than 16
bytes (DMA_THRESHOLD). Smaller transfers are unaffected.
Signed-off-by: Esben Haabendal
---
arch/arm/boot/dts/ls1021a.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts
From: Esben Haabendal
Always update the stopped state when busy status have been checked.
This is identical to what was done before, with the exception of error
handling.
Without this change, some errors cause the stopped state to be left in
incorrect state in i2c_imx_stop(), i2c_imx_dma_read
From: Esben Haabendal
This fixes a race condition, where the DMAEN bit ends up being set after
I2C slave has transmitted a byte following the dummy read. When that
happens, an interrupt is generated instead, and no DMA request is generated
to kickstart the DMA read, and a timeout happens after
From: Esben Haabendal
Gives substantial performance improvement for transfers larger than 16
bytes (DMA_THRESHOLD). Smaller transfers are unaffected.
Signed-off-by: Esben Haabendal
---
arch/arm/boot/dts/ls1021a.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts
From: Esben Haabendal
Always update the stopped state when busy status have been checked.
This is identical to what was done before, with the exception of error
handling.
Without this change, some errors cause the stopped state to be left in
incorrect state in i2c_imx_stop(), i2c_imx_dma_read
Uwe Kleine-König writes:
> On Thu, Aug 09, 2018 at 02:06:43PM +0200, Esben Haabendal wrote:
>> Uwe Kleine-König writes:
>>
>> > On Mon, Jul 09, 2018 at 11:43:03AM +0200, Esben Haabendal wrote:
>> >> From: Esben Haabendal
>> >>
>> >>
Uwe Kleine-König writes:
> On Thu, Aug 09, 2018 at 02:06:43PM +0200, Esben Haabendal wrote:
>> Uwe Kleine-König writes:
>>
>> > On Mon, Jul 09, 2018 at 11:43:03AM +0200, Esben Haabendal wrote:
>> >> From: Esben Haabendal
>> >>
>> >>
From: Esben Haabendal
Gives substantial performance improvement for transfers larger than 16
bytes (DMA_THRESHOLD). Smaller transfers are unaffected.
Signed-off-by: Esben Haabendal
---
arch/arm/boot/dts/ls1021a.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts
From: Esben Haabendal
Gives substantial performance improvement for transfers larger than 16
bytes (DMA_THRESHOLD). Smaller transfers are unaffected.
Signed-off-by: Esben Haabendal
---
arch/arm/boot/dts/ls1021a.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts
From: Esben Haabendal
Always update the stopped state when busy status have been checked.
This is identical to what was done before, with the exception of error
handling.
Without this change, some errors cause the stopped state to be left in
incorrect state in i2c_imx_stop(), i2c_imx_dma_read
From: Esben Haabendal
Always update the stopped state when busy status have been checked.
This is identical to what was done before, with the exception of error
handling.
Without this change, some errors cause the stopped state to be left in
incorrect state in i2c_imx_stop(), i2c_imx_dma_read
From: Esben Haabendal
This fixes a race condition, where the DMAEN bit ends up being set after
I2C slave has transmitted a byte following the dummy read. When that
happens, an interrupt is generated instead, and no DMA request is generated
to kickstart the DMA read, and a timeout happens after
From: Esben Haabendal
This fixes a race condition, where the DMAEN bit ends up being set after
I2C slave has transmitted a byte following the dummy read. When that
happens, an interrupt is generated instead, and no DMA request is generated
to kickstart the DMA read, and a timeout happens after
Uwe Kleine-König writes:
> On Mon, Jul 09, 2018 at 11:43:03AM +0200, Esben Haabendal wrote:
>> From: Esben Haabendal
>>
>> Always update the stopped state when busy status have been checked.
>> This is identical to what was done before, with the exception of er
Uwe Kleine-König writes:
> On Mon, Jul 09, 2018 at 11:43:03AM +0200, Esben Haabendal wrote:
>> From: Esben Haabendal
>>
>> Always update the stopped state when busy status have been checked.
>> This is identical to what was done before, with the exception of er
Uwe Kleine-König writes:
> On Mon, Jul 09, 2018 at 11:43:02AM +0200, Esben Haabendal wrote:
>> From: Esben Haabendal
>>
>> This fixes a race condition, where the DMAEN bit ends up being set after
>> I2C slave has transmitted a byte following the dummy read. When th
Uwe Kleine-König writes:
> On Mon, Jul 09, 2018 at 11:43:02AM +0200, Esben Haabendal wrote:
>> From: Esben Haabendal
>>
>> This fixes a race condition, where the DMAEN bit ends up being set after
>> I2C slave has transmitted a byte following the dummy read. When th
From: Esben Haabendal
Always update the stopped state when busy status have been checked.
This is identical to what was done before, with the exception of error
handling.
Without this change, some errors cause the stopped state to be left in
incorrect state in i2c_imx_stop(), i2c_imx_dma_read
From: Esben Haabendal
Always update the stopped state when busy status have been checked.
This is identical to what was done before, with the exception of error
handling.
Without this change, some errors cause the stopped state to be left in
incorrect state in i2c_imx_stop(), i2c_imx_dma_read
From: Esben Haabendal
This fixes a race condition, where the DMAEN bit ends up being set after
I2C slave has transmitted a byte following the dummy read. When that
happens, an interrupt is generated instead, and no DMA request is generated
to kickstart the DMA read, and a timeout happens after
From: Esben Haabendal
Make sure to call reinit_completion() before dma is started to avoid race
condition where reinit_completion() is called after complete() and before
wait_for_completion_timeout().
Signed-off-by: Esben Haabendal
Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for free
From: Esben Haabendal
Gives substantial performance improvement for transfers larger than 16
bytes (DMA_THRESHOLD). Smaller transfers are unaffected.
Signed-off-by: Esben Haabendal
---
arch/arm/boot/dts/ls1021a.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts
From: Esben Haabendal
This fixes a race condition, where the DMAEN bit ends up being set after
I2C slave has transmitted a byte following the dummy read. When that
happens, an interrupt is generated instead, and no DMA request is generated
to kickstart the DMA read, and a timeout happens after
From: Esben Haabendal
Make sure to call reinit_completion() before dma is started to avoid race
condition where reinit_completion() is called after complete() and before
wait_for_completion_timeout().
Signed-off-by: Esben Haabendal
Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for free
From: Esben Haabendal
Gives substantial performance improvement for transfers larger than 16
bytes (DMA_THRESHOLD). Smaller transfers are unaffected.
Signed-off-by: Esben Haabendal
---
arch/arm/boot/dts/ls1021a.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts
Uwe Kleine-König writes:
> On Wed, May 23, 2018 at 11:56:21AM +0200, Esben Haabendal wrote:
>> From: Esben Haabendal
>>
>> This fixes a race condition, where the DMAEN bit ends up being set after
>> I2C slave has transmitted a byte following the dummy read. When th
Uwe Kleine-König writes:
> On Wed, May 23, 2018 at 11:56:21AM +0200, Esben Haabendal wrote:
>> From: Esben Haabendal
>>
>> This fixes a race condition, where the DMAEN bit ends up being set after
>> I2C slave has transmitted a byte following the dummy read. When th
Uwe Kleine-König writes:
> Cc += Yuan Yao who authored DMA support and the NXP team.
>
> On Wed, May 23, 2018 at 11:56:20AM +0200, Esben Haabendal wrote:
>> From: Esben Haabendal
>>
>> Make sure to call reinit_completion() before dma is started to av
Uwe Kleine-König writes:
> Cc += Yuan Yao who authored DMA support and the NXP team.
>
> On Wed, May 23, 2018 at 11:56:20AM +0200, Esben Haabendal wrote:
>> From: Esben Haabendal
>>
>> Make sure to call reinit_completion() before dma is started to av
1 - 100 of 188 matches
Mail list logo
