| Message ID | 1385451313-1875-13-git-send-email-sourav.poddar@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Nov 26, 2013 at 01:05:08PM +0530, Sourav Poddar wrote: > Idea is to enable memory mapped by default at the end of the probe, > if the control reaches the "transfer" api, then the operation is > not a memory mapped one. Hence, we switch to Normal mode and at the > end of the "transfer" function. switch back to memory mapped mode. This doesn't see safe, what happens if something tries to use the map while a transfer is in progress?
Hi Mark, On Tuesday 26 November 2013 06:41 PM, Mark Brown wrote: > On Tue, Nov 26, 2013 at 01:05:08PM +0530, Sourav Poddar wrote: >> Idea is to enable memory mapped by default at the end of the probe, >> if the control reaches the "transfer" api, then the operation is >> not a memory mapped one. Hence, we switch to Normal mode and at the >> end of the "transfer" function. switch back to memory mapped mode. > This doesn't see safe, what happens if something tries to use the map > while a transfer is in progress? Transfer gets initiated with the following api "ti_qspi_start_transfer_one". At the beginning of this api, I am doing a "disable memory mapped", as becuase of the code implemntation, if the control has reaches this api, memory mapped is not the desired operation. Then, at the end of this api after "spi_finalize_current_message(master)", which indicated the current transfer complete, I issue a end of transfer command. Only after which, I enable memory mapped mode again. So, will the condition you mention above will hit.? Please help me understand if i am missing something? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 28, 2013 at 10:54:12AM +0530, Sourav Poddar wrote: > At the beginning of this api, I am doing a "disable memory mapped", > as becuase of > the code implemntation, if the control has reaches this api, memory > mapped is not > the desired operation. Then, at the end of this api after > "spi_finalize_current_message(master)", which indicated the current > transfer complete, I > issue a end of transfer command. Only after which, I enable memory > mapped mode again. > So, will the condition you mention above will hit.? Please help me > understand if i am > missing something? Removing the mapping isn't going to stop another context which has obtained a handle on the map trying to look at the mapping.
On Thursday 28 November 2013 04:19 PM, Mark Brown wrote: > On Thu, Nov 28, 2013 at 10:54:12AM +0530, Sourav Poddar wrote: > >> At the beginning of this api, I am doing a "disable memory mapped", >> as becuase of >> the code implemntation, if the control has reaches this api, memory >> mapped is not >> the desired operation. Then, at the end of this api after >> "spi_finalize_current_message(master)", which indicated the current >> transfer complete, I >> issue a end of transfer command. Only after which, I enable memory >> mapped mode again. >> So, will the condition you mention above will hit.? Please help me >> understand if i am >> missing something? > Removing the mapping isn't going to stop another context which has > obtained a handle on the map trying to look at the mapping. hmm..so the 'memcpy' part should be made atomic.(if possible?). -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 28, 2013 at 04:38:27PM +0530, Sourav Poddar wrote: > On Thursday 28 November 2013 04:19 PM, Mark Brown wrote: > >Removing the mapping isn't going to stop another context which has > >obtained a handle on the map trying to look at the mapping. > hmm..so the 'memcpy' part should be made atomic.(if possible?). Or holding the memory region should prevent normal SPI use (so any users ought to drop the memory region when they don't need it). I'm still a bit surprised there's no DMA controllers for this...
On Thursday 28 November 2013 05:29 PM, Mark Brown wrote: > On Thu, Nov 28, 2013 at 04:38:27PM +0530, Sourav Poddar wrote: >> On Thursday 28 November 2013 04:19 PM, Mark Brown wrote: >>> Removing the mapping isn't going to stop another context which has >>> obtained a handle on the map trying to look at the mapping. >> hmm..so the 'memcpy' part should be made atomic.(if possible?). > Or holding the memory region should prevent normal SPI use (so any users > ought to drop the memory region when they don't need it). hmm.ok i will unmap the memory region when not in use. > I'm still a bit surprised there's no DMA controllers for this... Yes, but thats the truth :( -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c index d21d40d..ba95d64 100644 --- a/drivers/spi/spi-ti-qspi.c +++ b/drivers/spi/spi-ti-qspi.c @@ -415,6 +415,8 @@ static int ti_qspi_start_transfer_one(struct spi_master *master, int status = 0, ret; int frame_length; + disable_qspi_memory_mapped(qspi); + /* setup device control reg */ qspi->dc = 0; @@ -460,6 +462,8 @@ static int ti_qspi_start_transfer_one(struct spi_master *master, ti_qspi_write(qspi, qspi->cmd | QSPI_INVAL, QSPI_SPI_CMD_REG); + enable_qspi_memory_mapped(qspi); + return status; } @@ -613,6 +617,8 @@ static int ti_qspi_probe(struct platform_device *pdev) if (ret) goto free_master; + enable_qspi_memory_mapped(qspi); + return 0; free_master:
Idea is to enable memory mapped by default at the end of the probe, if the control reaches the "transfer" api, then the operation is not a memory mapped one. Hence, we switch to Normal mode and at the end of the "transfer" function. switch back to memory mapped mode. Signed-off-by: Sourav Poddar <sourav.poddar@ti.com> --- drivers/spi/spi-ti-qspi.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)