roblems!
To be explicit, the patch ("soc: qcom: geni: More properly switch
to DMA mode") is a prerequisite for this one.
Fixes: 02b9aec59243 ("i2c: i2c-qcom-geni: Fix DMA transfer race")
Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
Reviewed-by: Akash Asthana
Tested
roblems!
To be explicit, the patch ("soc: qcom: geni: More properly switch
to DMA mode") is a prerequisite for this one.
Fixes: 02b9aec59243 ("i2c: i2c-qcom-geni: Fix DMA transfer race")
Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
Reviewed-by: Akash Asthana
Tested
> Sounds good, please find the series applied on top of v5.10-rc1 at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git
> tags/20201013212531.428538-1-diand...@chromium.org
Thanks, pulled.
signature.asc
Description: PGP signature
On Mon 26 Oct 10:13 CDT 2020, Wolfram Sang wrote:
>
> > Wolfram, would you like to pick this patch or would you prefer that it
> > goes together with the other two through the soc tree?
>
> Actually, I prefer the soc tree because of the functional dependency. I
> am not aware of any pending qcom
> Wolfram, would you like to pick this patch or would you prefer that it
> goes together with the other two through the soc tree?
Actually, I prefer the soc tree because of the functional dependency. I
am not aware of any pending qcom-geni patches, yet I think an immutable
branch for me to pull i
y) zero problems!
>
> To be explicit, the patch ("soc: qcom: geni: More properly switch
> to DMA mode") is a prerequisite for this one.
>
> Fixes: 02b9aec59243 ("i2c: i2c-qcom-geni: Fix DMA transfer race")
> Signed-off-by: Douglas Anderson
> Reviewed-by:
") is a prerequisite for this one.
Fixes: 02b9aec59243 ("i2c: i2c-qcom-geni: Fix DMA transfer race")
Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
Reviewed-by: Akash Asthana
Tested-by: Dmitry Baryshkov
---
(no changes since v1)
drivers/i2c/busses/i2c-qcom-geni.c | 6 +
oc: qcom: geni: More properly switch
to DMA mode") is a prerequisite for this one.
Fixes: 02b9aec59243 ("i2c: i2c-qcom-geni: Fix DMA transfer race")
Signed-off-by: Douglas Anderson
Reviewed-by: Akash Asthana
--
The Qualcomm Innovation Center, Inc. is a member of the Code
lems!
>
> To be explicit, the patch ("soc: qcom: geni: More properly switch
> to DMA mode") is a prerequisite for this one.
>
> Fixes: 02b9aec59243 ("i2c: i2c-qcom-geni: Fix DMA transfer race")
> Signed-off-by: Douglas Anderson
> ---
Reviewed-by: Stephen Boyd
") is a prerequisite for this one.
Fixes: 02b9aec59243 ("i2c: i2c-qcom-geni: Fix DMA transfer race")
Signed-off-by: Douglas Anderson
---
drivers/i2c/busses/i2c-qcom-geni.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b
In order to add an alternative method of DMA-based SPI transfer first we
need to detach the currently available one from the common code. Here we
move the normal DMA-based SPI transfer execution functionality into a
dedicated method. It will be utilized if either the DMA engine supports
an unlimite
DW APB SSI DMA driver doesn't use the native SPI core wait API since
commit bdbdf0f06337 ("spi: dw: Locally wait for the DMA transfers
completion"). Due to that the driver can now clear the DMAC register
in a single place synchronously with the DMA transactions completion
or failure. After that all
On Wed, Aug 05, 2020 at 09:02:08AM +0200, Alain Volmat wrote:
> From: Amelie Delaunay
>
> The rx dma is completed "after" the last data is received
> from spi. Thus, to avoid loss of rx data, it's mandatory to
> wait for the dma callback before tearing down the rx dma in
> stm32_spi_disable().
A
tx: dma channel for TX transfer
* @dma_rx: dma channel for RX transfer
+ * @dma_completion: completion to wait for end of DMA transfer
* @phys_addr: SPI registers physical base address
* @xfer_completion: completion to wait for end of transfer
* @xfer_status: current transfer status
@@ -304,6 +
DW APB SSI DMA driver doesn't use the native SPI core wait API since
commit bdbdf0f06337 ("spi: dw: Locally wait for the DMA transfers
completion"). Due to that the driver can now clear the DMAC register
in a single place synchronously with the DMA transactions completion
or failure. After that all
In order to add an alternative method of DMA-based SPI transfer first we
need to detach the currently available one from the common code. Here we
move the normal DMA-based SPI transfer execution functionality into a
dedicated method. It will be utilized if either the DMA engine supports
an unlimite
From: Douglas Anderson
[ Upstream commit 02b9aec59243c6240fc42884acc958602146ddf6 ]
When I have KASAN enabled on my kernel and I start stressing the
touchscreen my system tends to hang. The touchscreen is one of the
only things that does a lot of big i2c transfers and ends up hitting
the DMA pa
From: Douglas Anderson
[ Upstream commit 02b9aec59243c6240fc42884acc958602146ddf6 ]
When I have KASAN enabled on my kernel and I start stressing the
touchscreen my system tends to hang. The touchscreen is one of the
only things that does a lot of big i2c transfers and ends up hitting
the DMA pa
On 7/26/2020 6:17 PM, Wolfram Sang wrote:
On Thu, Jul 23, 2020 at 09:56:34PM +0200, Wolfram Sang wrote:
On Wed, Jul 22, 2020 at 03:00:21PM -0700, Douglas Anderson wrote:
When I have KASAN enabled on my kernel and I start stressing the
touchscreen my system tends to hang. The touchscreen is one
On Thu, Jul 23, 2020 at 09:56:34PM +0200, Wolfram Sang wrote:
> On Wed, Jul 22, 2020 at 03:00:21PM -0700, Douglas Anderson wrote:
> > When I have KASAN enabled on my kernel and I start stressing the
> > touchscreen my system tends to hang. The touchscreen is one of the
> > only things that does a
On Wed, Jul 22, 2020 at 03:00:21PM -0700, Douglas Anderson wrote:
> When I have KASAN enabled on my kernel and I start stressing the
> touchscreen my system tends to hang. The touchscreen is one of the
> only things that does a lot of big i2c transfers and ends up hitting
> the DMA paths in the ge
On 7/23/2020 6:20 AM, Stephen Boyd wrote:
Quoting Douglas Anderson (2020-07-22 15:00:21)
When I have KASAN enabled on my kernel and I start stressing the
touchscreen my system tends to hang. The touchscreen is one of the
only things that does a lot of big i2c transfers and ends up hitting
the
Quoting Douglas Anderson (2020-07-22 15:00:21)
> When I have KASAN enabled on my kernel and I start stressing the
> touchscreen my system tends to hang. The touchscreen is one of the
> only things that does a lot of big i2c transfers and ends up hitting
> the DMA paths in the geni i2c driver. It
he mode (DMA vs. FIFO) and only
> do writel() for DMA mode. If you're not convinced by my arguments
> about dma_map_single(), would you be good with just doing the
> non-relaxed version if we're in DMA mode?
OK, so I did some quick benchmarking and I couldn't find any
perf
When I have KASAN enabled on my kernel and I start stressing the
touchscreen my system tends to hang. The touchscreen is one of the
only things that does a lot of big i2c transfers and ends up hitting
the DMA paths in the geni i2c driver. It appears that KASAN adds
enough delay in my system to ti
Hi,
On Tue, Jul 21, 2020 at 11:55 AM Stephen Boyd wrote:
>
> Quoting Doug Anderson (2020-07-21 09:18:35)
> > On Tue, Jul 21, 2020 at 12:08 AM Stephen Boyd wrote:
> > >
> > > Quoting Stephen Boyd (2020-07-20 22:59:14)
> > > >
> > > > I worry that we also need a dmb() here to make sure the dma buf
Quoting Doug Anderson (2020-07-21 09:18:35)
> On Tue, Jul 21, 2020 at 12:08 AM Stephen Boyd wrote:
> >
> > Quoting Stephen Boyd (2020-07-20 22:59:14)
> > >
> > > I worry that we also need a dmb() here to make sure the dma buffer is
> > > properly mapped before this write to the device is attempted
Hi,
On Tue, Jul 21, 2020 at 12:08 AM Stephen Boyd wrote:
>
> Quoting Stephen Boyd (2020-07-20 22:59:14)
> >
> > I worry that we also need a dmb() here to make sure the dma buffer is
> > properly mapped before this write to the device is attempted. But it may
> > only matter to be before the I2C_R
On 7/21/2020 12:37 PM, Stephen Boyd wrote:
Quoting Stephen Boyd (2020-07-20 22:59:14)
I worry that we also need a dmb() here to make sure the dma buffer is
properly mapped before this write to the device is attempted. But it may
only matter to be before the I2C_READ.
I'm suggesting this patc
On 7/21/2020 5:54 AM, Douglas Anderson wrote:
When I have KASAN enabled on my kernel and I start stressing the
touchscreen my system tends to hang. The touchscreen is one of the
only things that does a lot of big i2c transfers and ends up hitting
the DMA paths in the geni i2c driver. It appea
Quoting Stephen Boyd (2020-07-20 22:59:14)
>
> I worry that we also need a dmb() here to make sure the dma buffer is
> properly mapped before this write to the device is attempted. But it may
> only matter to be before the I2C_READ.
>
I'm suggesting this patch instead where we make geni_se_setup
Quoting Douglas Anderson (2020-07-20 17:24:53)
> When I have KASAN enabled on my kernel and I start stressing the
> touchscreen my system tends to hang. The touchscreen is one of the
> only things that does a lot of big i2c transfers and ends up hitting
> the DMA paths in the geni i2c driver. It
On 2020-07-21 05:54, Douglas Anderson wrote:
When I have KASAN enabled on my kernel and I start stressing the
touchscreen my system tends to hang. The touchscreen is one of the
only things that does a lot of big i2c transfers and ends up hitting
the DMA paths in the geni i2c driver. It appears
When I have KASAN enabled on my kernel and I start stressing the
touchscreen my system tends to hang. The touchscreen is one of the
only things that does a lot of big i2c transfers and ends up hitting
the DMA paths in the geni i2c driver. It appears that KASAN adds
enough delay in my system to ti
Sugar Zhang (13):
dmaengine: pl330: Remove the burst limit for quirk 'NO-FLUSHP'
dmaengine: pl330: Add quirk 'arm,pl330-periph-burst'
dt-bindings: dma: pl330: Document the quirk 'arm,pl330-periph-burst'
ARM: dts: rk3036: Add 'arm,pl330-periph-burst' for dmac
ARM: dts: rk322x: Add 'arm
t; > + sconf.dst_addr = dma_dst;
> > + sconf.src_addr = dma_src;
> > + dmaengine_slave_config(chan, &sconf);
> > +
> > + buf = (dir == DMA_MEM_TO_DEV) ? dma_dst : dma_src;
> > + tx = dmaengine_prep_
On Fri, May 01, 2020 at 05:29:12PM -0700, Alan Mikhak wrote:
> From: Alan Mikhak
>
> Modify pci_epf_test_data_transfer() to also support slave DMA transfers.
> Adds a direction parameter so caller can specify one of the supported DMA
> transfer directions: DMA_MEM_TO_MEM, DMA_
From: Alan Mikhak
Modify pci_epf_test_data_transfer() to also support slave DMA transfers.
Adds a direction parameter so caller can specify one of the supported DMA
transfer directions: DMA_MEM_TO_MEM, DMA_MEM_TO_DEV, and DMA_DEV_TO_MEM.
For DMA_MEM_TO_MEM, the function calls
o SPI core provided DMA helpers, it missed to setup maximum
supported DMA transfer length for the controller and thus users
mistakenly try to send more data than supported with the following
warning:
ili9341 spi-PRP0001:01: DMA disabled for transfer length 153600 greater than
65536
Setup maximum
o SPI core provided DMA helpers, it missed to setup maximum
supported DMA transfer length for the controller and thus users
mistakenly try to send more data than supported with the following
warning:
ili9341 spi-PRP0001:01: DMA disabled for transfer length 153600 greater than
65536
Setup maximum
o SPI core provided DMA helpers, it missed to setup maximum
supported DMA transfer length for the controller and thus users
mistakenly try to send more data than supported with the following
warning:
ili9341 spi-PRP0001:01: DMA disabled for transfer length 153600 greater than
65536
Setup maximum
o SPI core provided DMA helpers, it missed to setup maximum
supported DMA transfer length for the controller and thus users
mistakenly try to send more data than supported with the following
warning:
ili9341 spi-PRP0001:01: DMA disabled for transfer length 153600 greater than
65536
Setup maximum
From: Cezary Gapinski
Add transfer_one_dma_start function to be more generic for other
stm32 SPI family drivers.
Signed-off-by: Cezary Gapinski
---
drivers/spi/spi-stm32.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/spi/spi-stm32.c b
The patch
spi: spi-fsl-dspi: Fill actual_length when doing DMA transfer
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
Upper layer users of SPI device drivers may rely on 'actual_length',
so it is important that information is correctly reported. One such
example is spi_mem_exec_op() function that will fail if
'actual_length' of the data transferred is not what was requested. Add
necessary code to populate 'actual_
On Mon, Jul 16, 2018 at 4:26 AM Mark Brown wrote:
>
> On Sun, Jul 15, 2018 at 11:25:08PM -0700, Andrey Smirnov wrote:
> > Users of SPI device drivers may rely on 'actual_length', so it is
> > important that information is correctly reported. One example would be
> > spi_mem_exec_op() which will fa
On Sun, Jul 15, 2018 at 11:25:08PM -0700, Andrey Smirnov wrote:
> Users of SPI device drivers may rely on 'actual_length', so it is
> important that information is correctly reported. One example would be
> spi_mem_exec_op() which will fail if 'actual_length' doesn't match
> requested transfer leng
Users of SPI device drivers may rely on 'actual_length', so it is
important that information is correctly reported. One example would be
spi_mem_exec_op() which will fail if 'actual_length' doesn't match
requested transfer length. To fix the problem, add necessary code to
populate 'actual_length'.
On Thu, Apr 19, 2018 at 10:00:46AM +0800, Baolin Wang wrote:
> From: Eric Long
>
> Define the DMA transfer step type to make code more readable.
Applied this one, thanks
--
~Vinod
From: Eric Long
Define the DMA transfer step type to make code more readable.
Signed-off-by: Eric Long
Signed-off-by: Baolin Wang
---
Changes since v1:
- Convert enum structure to macros definition for DMA step type.
---
drivers/dma/sprd-dma.c | 19 +--
1 file changed, 13
Hi Vinod,
On 11 April 2018 at 17:24, Vinod Koul wrote:
> On Tue, Apr 10, 2018 at 03:46:03PM +0800, Baolin Wang wrote:
>> From: Eric Long
>>
>> Define the DMA transfer step type to make code more readable.
>>
>> Signed-off-by: Eric Long
>> Signed-off-by: B
On Tue, Apr 10, 2018 at 03:46:03PM +0800, Baolin Wang wrote:
> From: Eric Long
>
> Define the DMA transfer step type to make code more readable.
>
> Signed-off-by: Eric Long
> Signed-off-by: Baolin Wang
> ---
> drivers/dma/sprd-dma.c | 28 ++
From: Eric Long
Define the DMA transfer step type to make code more readable.
Signed-off-by: Eric Long
Signed-off-by: Baolin Wang
---
drivers/dma/sprd-dma.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/sprd-dma.c b/drivers
Hi Stefan,
On Mon, Mar 19, 2018 at 11:16 PM, Stefan Agner wrote:
> Use enum dma_transfer_direction as required by dmaengine_prep_slave_sg
> instead of enum dma_data_direction. This won't change behavior in
> practice as the enum values are equivalent.
Thanks for catching!
BTW, spi-sh-msiof has
The patch
spi: rspi: use correct enum for DMA transfer direction
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
Use enum dma_transfer_direction as required by dmaengine_prep_slave_sg
instead of enum dma_data_direction. This won't change behavior in
practice as the enum values are equivalent.
This fixes two warnings when building with clang:
drivers/spi/spi-rspi.c:538:26: warning: implicit conversion from
On 19.03.2018 22:42, Stefan Agner wrote:
> Use enum dma_transfer_direction as required by dmaengine_prep_slave_sg
> instead of enum dma_data_direction.
>
> This fixes two warnings when building with clang:
> drivers/spi/spi-rspi.c:538:26: warning: implicit conversion from enumeration
> typ
Use enum dma_transfer_direction as required by dmaengine_prep_slave_sg
instead of enum dma_data_direction.
This fixes two warnings when building with clang:
drivers/spi/spi-rspi.c:538:26: warning: implicit conversion from enumeration
type 'enum dma_data_direction' to different enumeration
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Hiromitsu Yamasaki
[ Upstream commit 36735783fdb599c94b9c86824583df367c65900b ]
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2 register is 16bit.
Fixes: b0d0ce8b6b91 ("spi: sh-msi
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Hiromitsu Yamasaki
[ Upstream commit 36735783fdb599c94b9c86824583df367c65900b ]
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2 register is 16bit.
Fixes: b0d0ce8b6b91 ("spi: sh-ms
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Hiromitsu Yamasaki
[ Upstream commit 36735783fdb599c94b9c86824583df367c65900b ]
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2 register is 16bit.
Fixes: b0d0ce8b6b91 ("spi: sh-msi
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Hiromitsu Yamasaki
[ Upstream commit 36735783fdb599c94b9c86824583df367c65900b ]
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2 register is 16bit.
Fixes: b0d0ce8b6b91 ("spi: sh-ms
From: Hiromitsu Yamasaki
[ Upstream commit 36735783fdb599c94b9c86824583df367c65900b ]
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2 register is 16bit.
Fixes: b0d0ce8b6b91 ("spi: sh-msiof: Add DMA support")
Signed-off-by: Hiromitsu Yamasaki
Signed-off-by: Simon Horman
Acked-by: Ge
From: Hiromitsu Yamasaki
[ Upstream commit 36735783fdb599c94b9c86824583df367c65900b ]
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2 register is 16bit.
Fixes: b0d0ce8b6b91 ("spi: sh-msiof: Add DMA support")
Signed-off-by: Hiromitsu Yamasaki
Signed-off-by: Simon Horman
Acked-by: Ge
From: Hiromitsu Yamasaki
[ Upstream commit 36735783fdb599c94b9c86824583df367c65900b ]
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2 register is 16bit.
Fixes: b0d0ce8b6b91 ("spi: sh-msiof: Add DMA support")
Signed-off-by: Hiromitsu Yamasaki
Signed-off-by: Simon Horman
Acked-by: Ge
From: Hiromitsu Yamasaki
[ Upstream commit 36735783fdb599c94b9c86824583df367c65900b ]
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2 register is 16bit.
Fixes: b0d0ce8b6b91 ("spi: sh-msiof: Add DMA support")
Signed-off-by: Hiromitsu Yamasaki
Signed-off-by: Simon Horman
Acked-by: Ge
On Tue, 23 May 2017, steven_f...@realsil.com.cn wrote:
> From: Steven Feng
>
> The request should be resent when DMA transfer error occurred.
> For rts5227, the clock rate needs to be reduced when error occurred.
>
> Signed-off-by: Steven Feng
> ---
> drivers/m
From: Steven Feng
The request should be resent when DMA transfer error occurred.
For rts5227, the clock rate needs to be reduced when error occurred.
Signed-off-by: Steven Feng
---
drivers/mfd/rtsx_pcr.c | 17 +++--
include/linux/mfd/rtsx_pci.h | 5 +
2 files changed
On Tue, 23 May 2017, steven_f...@realsil.com.cn wrote:
> From: Steven Feng
>
> The request should be resent when DMA transfer error occurred.
> For rts5227, the clock rate needs to be reduced when error occurred.
>
> Signed-off-by: Steven Feng
> ---
> drivers/m
From: Steven Feng
The request should be resent when DMA transfer error occurred.
For rts5227, the clock rate needs to be reduced when error occurred.
Signed-off-by: Steven Feng
---
drivers/mfd/rtsx_pcr.c | 17 +++--
include/linux/mfd/rtsx_pci.h | 5 +
2 files changed
On Wed, 26 Apr 2017, steven_f...@realsil.com.cn wrote:
> From: Steven Feng
>
> The request should be resent when DMA transfer error occurred.
> For rts5227, the clock rate needs to be reduced when error occurred.
>
> Signed-off-by: Steven Feng
> ---
> drivers/m
e：181-6899-0403 Ext：57594
>
> On 2017年04月26日 10:47, 冯伟linux wrote:
> > From: Steven Feng
> >
> > The request should be resent when DMA transfer error occurred.
> > For rts5227, the clock rate needs to be reduced when error occurred.
> >
> > Signed-off-b
Hi lee.jones:
I have just now resented the patch V4, please review it.
steven feng
Realsil Microelectronics CO. LTD.
Mobile：181-6899-0403 Ext：57594
On 2017年04月26日 10:47, 冯伟linux wrote:
> From: Steven Feng
>
> The request should be resent when DMA transfer error occurred.
>
From: Steven Feng
The request should be resent when DMA transfer error occurred.
For rts5227, the clock rate needs to be reduced when error occurred.
Signed-off-by: Steven Feng
---
drivers/mfd/rtsx_pcr.c | 18 --
include/linux/mfd/rtsx_pci.h | 5 +
2 files changed
On Tue, 25 Apr 2017, 冯伟linux wrote:
> Hi Lee Jones:
> I send this email mainly for the fllowing two things;
> 1.Is there anything unclear about the patch "mfd:rtsx: do retry when
> dma transfer error"
> 2.Whether the pach I submitted in email "[PATCH v4]
Hi Lee Jones:
I send this email mainly for the fllowing two things;
1.Is there anything unclear about the patch "mfd:rtsx: do retry when
dma transfer error"
2.Whether the pach I submitted in email "[PATCH v4] mfd:rtsx: do
retry when DMA transfer error"
wil
> This errno need to be -EILSEQ.
> You need to explain why.
>
When DMA transfer error with -EILSEQ, the request will retry some times,
but when with errno -EINVAL, the request will be aborted directly.
At the same time the DMA transfer error truely beacuse of the Illegal
byte sequence,
s
DR104_MAX_DTR &&
> >>> + pcr->dma_error_count &&
> >>> + PCI_PID(pcr) == RTS5227_DEVICE_ID)
> >>> + card_clock = (UHS_SDR104_MAX_DTR -
> >>> + pcr->dma_error_count * 2000);
> > ... but won&
card_clock = (UHS_SDR104_MAX_DTR -
>>> + pcr->dma_error_count * 2000);
> ... but won't this only reduce the clock frequency just once?
>
> There is no point bracketing the whole statement.
>
> But you do need to bracket one (the second) section of it
From: Steven Feng
The request should be resent when DMA transfer error occurred.
For rts5227, the clock rate needs to be reduced when error occurred.
Signed-off-by: Steven Feng
---
drivers/mfd/rtsx_pcr.c | 18 --
include/linux/mfd/rtsx_pci.h | 5 +
2 files changed
ven feng
> Realsil Microelectronics CO. LTD.
> Mobile：181-6899-0403 Ext：57594
>
> On 2017年01月05日 17:01, 冯伟linux wrote:
> > From: steven_feng
Should be "Steven Feng"
> > the request should be reissued when dma transfer error.
> > for rts5227, the clock freq ne
:
> From: steven_feng
>
> the request should be reissued when dma transfer error.
> for rts5227, the clock freq need to step reduce when error occurred.
>
> Signed-off-by: steven_feng
> ---
> drivers/mfd/rtsx_pcr.c | 17 +++--
> include/linux/mfd/rtsx_
callback
used to inform that dma transfer is complete. However this is not
the case for all subsystems that use dma. Some subsystems use a
timer to check the dma status periodically.
Therefore the calculation was updated and residue is calculated
accordingly by a) update the residue calculation taking in
It is possible that DMA transfer is already complete but, completion
handler is yet to be called, when dmaengine_pause() is called in case of
error condition(like break/rx timeout). This leads to dmaengine_pause()
API to return EINVAL (as descriptor is already NULL) causing
rx_dma_broken flag to
It is possible that DMA transfer is already complete but, completion
handler is yet to be called, when dmaengine_pause() is called in case of
error condition(like break/rx timeout). This leads to dmaengine_pause()
API to return EINVAL (as descriptor is already NULL) causing
rx_dma_broken flag to
ecific?
>
> In which case, why isn't it in the SD card driver?
>
>> steven feng
>> Realsil Microelectronics CO. LTD.
>> Mobile：181-6899-0403 Ext：57594
>>
>> 在 2017年01月04日 20:12, Lee Jones 写道:
>>> On Wed, 04 Jan 2017, steven_f...@realsil.com.cn w
gt; 在 2017年01月04日 20:12, Lee Jones 写道:
> > On Wed, 04 Jan 2017, steven_f...@realsil.com.cn wrote:
> >
> >> From: steven_feng
> >>
> >> the request should be reissued when dma transfer error.
> >> for rts5227, the clock freq need to step reduce when e
y as much as possible.
steven feng
Realsil Microelectronics CO. LTD.
Mobile：181-6899-0403 Ext：57594
在 2017年01月04日 20:12, Lee Jones 写道:
> On Wed, 04 Jan 2017, steven_f...@realsil.com.cn wrote:
>
>> From: steven_feng
>>
>> the request should be reissued when dma transfer
From: steven_feng
the request should be reissued when dma transfer error.
for rts5227, the clock freq need to step reduce when error occurred.
Signed-off-by: steven_feng
---
drivers/mfd/rtsx_pcr.c | 17 +++--
include/linux/mfd/rtsx_pci.h | 5 +
2 files changed, 20
On Wed, 04 Jan 2017, steven_f...@realsil.com.cn wrote:
> From: steven_feng
>
> the request should be reissued when dma transfer error.
> for rts5227, the clock freq need to step reduce when error occurred.
>
> Signed-off-by: steven_feng
> ---
> drivers/m
From: steven_feng
the request should be reissued when dma transfer error.
for rts5227, the clock freq need to step reduce when error occurred.
Signed-off-by: steven_feng
---
drivers/mfd/rtsx_pcr.c | 16 ++--
include/linux/mfd/rtsx_pci.h | 4
2 files changed, 18
> This seems strange. What is the reason for using this error?
>
>> +if (pcr->dma_error_count < 8)
> Why 8?
dma_error_count record the number of dma transfer error,
card clock decreased by 20MHz *dma_error_count, when setting card clock
again.
while dma_error_
On Fri, 09 Dec 2016, steven_f...@realsil.com.cn wrote:
> From: steven_feng
>
> the request should be reissued when dma transfer error.
> for rts5227, the clock freq need to step reduce when error occurred.
>
> Signed-off-by: steven_feng
> ---
> drivers/m
On Fri, Dec 09, 2016 at 07:23:17PM +0100, Mason wrote:
> On 09/12/2016 18:56, Vinod Koul wrote:
> > Right, but in that case the fallback would be PIO mode, and if that is
> > not availble (IIRC some f your devices don't) then reject the usage with
> > EAGAIN.
> Maybe I'm missing something, but I
On Fri, Dec 09, 2016 at 07:23:17PM +0100, Mason wrote:
> [ Dropping Mans to preserve his peace-of-mind ]
>
> On 09/12/2016 18:56, Vinod Koul wrote:
> > On Fri, Dec 09, 2016 at 06:34:15PM +0100, Mason wrote:
> >> On 09/12/2016 18:17, Vinod Koul wrote:
> >>
> >>> On Fri, Dec 09, 2016 at 11:25:57AM +
[ Dropping Mans to preserve his peace-of-mind ]
On 09/12/2016 18:56, Vinod Koul wrote:
> On Fri, Dec 09, 2016 at 06:34:15PM +0100, Mason wrote:
>> On 09/12/2016 18:17, Vinod Koul wrote:
>>
>>> On Fri, Dec 09, 2016 at 11:25:57AM +0100, Sebastian Frias wrote:
What concrete solution do you
On Fri, Dec 09, 2016 at 11:26:06PM +0530, Vinod Koul wrote:
> On Fri, Dec 09, 2016 at 06:34:15PM +0100, Mason wrote:
> > On 09/12/2016 18:17, Vinod Koul wrote:
> >
> > > On Fri, Dec 09, 2016 at 11:25:57AM +0100, Sebastian Frias wrote:
> > >>
> > >> What concrete solution do you propose?
> > >
> >
On Fri, Dec 09, 2016 at 06:34:15PM +0100, Mason wrote:
> On 09/12/2016 18:17, Vinod Koul wrote:
>
> > On Fri, Dec 09, 2016 at 11:25:57AM +0100, Sebastian Frias wrote:
> >>
> >> What concrete solution do you propose?
> >
> > I have already proposed two solutions.
> >
> > A) Request a channel only
On Fri, Dec 09, 2016 at 05:28:01PM +, Måns Rullgård wrote:
> Vinod Koul writes:
>
> > On Fri, Dec 09, 2016 at 11:25:57AM +0100, Sebastian Frias wrote:
> >>
> >> What concrete solution do you propose?
> >
> > I have already proposed two solutions.
> >
> > A) Request a channel only when you ne
On 09/12/2016 18:17, Vinod Koul wrote:
> On Fri, Dec 09, 2016 at 11:25:57AM +0100, Sebastian Frias wrote:
>>
>> What concrete solution do you propose?
>
> I have already proposed two solutions.
>
> A) Request a channel only when you need it. Obviously we can't do virtual
> channels with this (th
1 - 100 of 249 matches
Mail list logo
