From: Vignesh R <vigneshr@ti.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/2] spi: Add DMA support for spi_flash_read()
Date: Tue, 12 Apr 2016 13:50:48 +0530 [thread overview]
Message-ID: <570CAFE0.1070604@ti.com> (raw)
In-Reply-To: <20160412043115.GV3351@sirena.org.uk>
On 04/12/2016 10:01 AM, Mark Brown wrote:
> On Tue, Apr 05, 2016 at 09:19:51AM +0530, Vignesh R wrote:
>
>> mutex_lock(&master->bus_lock_mutex);
>> + if (master->dma_rx) {
>> + rx_dev = master->dma_rx->device->dev;
>> + ret = spi_map_buf(master, rx_dev, &msg->rx_sg,
>> + msg->buf, msg->len,
>> + DMA_FROM_DEVICE);
>> + if (ret != 0)
>> + goto err;
>> + }
>
> This is unconditionally DMA mapping the buffer if DMA is supported.
> That's going to be common but I'm not sure it'll be universal, we need
> to think of something better here. I'm not immediately seeing what
> though. Possibly a flag...
>
Ok, I will introduced a flag along the lines of cur_msg_mapped currently
part of spi_message struct.
This reminds me the issue of possible kmap'd buffers(falling in
PKMAP_BASE - PAGE_OFFSET-1 region) that might be passed to
spi_map_buf() which are not currently being handled properly. Boris
attempted to fix this in generic way[1] but was rejected as it couldn't
handle all type of caches.
I was wondering whether you would accept a patch returning error when
kmap'd buffers are passed to spi_map_buf()? Or would it still make sense
to port changes from that series to handle kmap'd buffers to SPI core alone?
[1]https://lkml.org/lkml/2016/3/31/462
--
Regards
Vignesh
WARNING: multiple messages have this Message-ID (diff)
From: Vignesh R <vigneshr@ti.com>
To: Mark Brown <broonie@kernel.org>
Cc: <linux-spi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-omap@vger.kernel.org>
Subject: Re: [PATCH 1/2] spi: Add DMA support for spi_flash_read()
Date: Tue, 12 Apr 2016 13:50:48 +0530 [thread overview]
Message-ID: <570CAFE0.1070604@ti.com> (raw)
In-Reply-To: <20160412043115.GV3351@sirena.org.uk>
On 04/12/2016 10:01 AM, Mark Brown wrote:
> On Tue, Apr 05, 2016 at 09:19:51AM +0530, Vignesh R wrote:
>
>> mutex_lock(&master->bus_lock_mutex);
>> + if (master->dma_rx) {
>> + rx_dev = master->dma_rx->device->dev;
>> + ret = spi_map_buf(master, rx_dev, &msg->rx_sg,
>> + msg->buf, msg->len,
>> + DMA_FROM_DEVICE);
>> + if (ret != 0)
>> + goto err;
>> + }
>
> This is unconditionally DMA mapping the buffer if DMA is supported.
> That's going to be common but I'm not sure it'll be universal, we need
> to think of something better here. I'm not immediately seeing what
> though. Possibly a flag...
>
Ok, I will introduced a flag along the lines of cur_msg_mapped currently
part of spi_message struct.
This reminds me the issue of possible kmap'd buffers(falling in
PKMAP_BASE - PAGE_OFFSET-1 region) that might be passed to
spi_map_buf() which are not currently being handled properly. Boris
attempted to fix this in generic way[1] but was rejected as it couldn't
handle all type of caches.
I was wondering whether you would accept a patch returning error when
kmap'd buffers are passed to spi_map_buf()? Or would it still make sense
to port changes from that series to handle kmap'd buffers to SPI core alone?
[1]https://lkml.org/lkml/2016/3/31/462
--
Regards
Vignesh
next prev parent reply other threads:[~2016-04-12 8:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-05 3:49 [PATCH 0/2] spi: Add DMA support for ti-qspi Vignesh R
2016-04-05 3:49 ` Vignesh R
[not found] ` <1459828192-5531-1-git-send-email-vigneshr-l0cyMroinI0@public.gmane.org>
2016-04-05 3:49 ` [PATCH 1/2] spi: Add DMA support for spi_flash_read() Vignesh R
2016-04-05 3:49 ` Vignesh R
2016-04-05 3:49 ` Vignesh R
[not found] ` <1459828192-5531-2-git-send-email-vigneshr-l0cyMroinI0@public.gmane.org>
2016-04-12 4:31 ` Mark Brown
2016-04-12 4:31 ` Mark Brown
2016-04-12 8:20 ` Vignesh R [this message]
2016-04-12 8:20 ` Vignesh R
2016-04-05 3:49 ` [PATCH 2/2] spi: spi-ti-qspi: Add DMA support for QSPI mmap read Vignesh R
2016-04-05 3:49 ` Vignesh R
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=570CAFE0.1070604@ti.com \
--to=vigneshr@ti.com \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.