Hi Wolfram,
On Thu, Jun 28, 2018 at 10:45 PM Wolfram Sang
wrote:
> On Gen3, we can only do RXDMA once per transfer reliably. For that, we
> must reset the device, then we can have RXDMA once. This patch
> implements this. When there is no reset controller or the reset fails,
> RXDMA will be block
> > + /* Gen3 needs a reset before allowing RXDMA once */
> > + if (priv->devtype == I2C_RCAR_GEN3) {
>
> So on R-Car Gen3 the device is always reset, even if no reads will be done?
> Or is that something you cannot check for at this point?
You got a point. I copied the behaviour fro
On Sat, Jun 16, 2018 at 09:56:36PM +0900, Wolfram Sang wrote:
> It seems that during the conversion from gpio* to gpiod*, the initial
> state of SCL was wrongly switched to LOW. Fix it to be HIGH again.
>
> Fixes: 7bb75029ef34 ("i2c: gpio: Enforce open drain through gpiolib")
> Signed-off-by: Wolf
Make the incomplete_transfer routine reusable, so we can add other test
cases with different patterns later. Prepare the docs for that, too.
Signed-off-by: Wolfram Sang
---
Documentation/i2c/gpio-fault-injection | 30 +---
drivers/i2c/busses/i2c-gpio.c | 36 +
Hi,
here comes another fault injector which stress tests I2C bus recovery
implementations. The generic_scl algorithm in the I2C core doesn't handle this
yet. I am at it. But first, here is the test environment for it.
Please share your thoughts if you have any.
Thanks,
Wolfram
Changes since
Add another injector for an incomplete transfer. As mentioned in the
docs, this one is important to check bus recovery algorithms with it.
Otherwise random data may be sent to devices!
Signed-off-by: Wolfram Sang
---
Documentation/i2c/gpio-fault-injection | 19 +++
drivers/i2c/bu
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Thursday, June 28, 2018 9:50 PM
>
> Hi Shimoda-san,
>
> On Thu, Jun 28, 2018 at 1:53 PM Yoshihiro Shimoda
> wrote:
> > This patch fixes an issue that lacks the dma_unmap_sg() calling in
> > the error patch of renesas_sdhi_internal_dmac_start_dma()
This patch is fixes an issue that the SDHI_INTERNAL_DMAC_RX_IN_USE
flag cannot be cleared because tmio_mmc_core sets the host->data
to NULL before the tmio_mmc_core calls tmio_mmc_abort_dma().
So, this patch clears the SDHI_INTERNAL_DMAC_RX_IN_USE in
the renesas_sdhi_internal_dmac_abort_dma() anyw
This patch set is based on the mmc.git / fixes branch.
Changes from v1:
- Add Reviewed-by Geert-san.
- Add a new goto label for error path.
Yoshihiro Shimoda (2):
mmc: renesas_sdhi_internal_dmac: Fix missing unmap in error patch
mmc: renesas_sdhi_internal_dmac: Cannot clear the RX_IN_USE in
This patch fixes an issue that lacks the dma_unmap_sg() calling in
the error patch of renesas_sdhi_internal_dmac_start_dma().
Fixes: 0cbc94daa554 ("mmc: renesas_sdhi_internal_dmac: limit DMA RX for old
SoCs")
Cc: # v4.17+
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
---
dr
On Thu, May 24, 2018 at 04:36:24PM +0200, Marek Vasut wrote:
> If anything fails past phy_init_fn() and the system is a Gen3 with
> a PHY, the PHY will be left on and inited. This is caused by the
> phy_init_fn, which is in fact a pointer to rcar_pcie_phy_init_gen3()
> function, which starts the PH
On Fri, May 25, 2018 at 08:33:26PM +0200, Marek Vasut wrote:
> If the Gen3 PHY fails to power up, the code does not undo the
> initialization caused by phy_init(). Add the missing failure
> handling to the rcar_pcie_phy_init_gen3() function.
>
> Signed-off-by: Marek Vasut
> Reported-by: Geert Uyt
Hi all,
This patch series fixes race conditions between DMA use and port
shutdown on Renesas "SCIF" serial ports, causing e.g.
sh-sci e655.serial: Failed preparing Tx DMA descriptor
Unable to handle kernel read from unreadable memory at virtual address
..
When the sh-sci driver detects an issue with DMA during operation, it
falls backs to PIO, and releases all DMA resources.
As releasing DMA resources immediately has no advantages, but
complicates the code, and is susceptible to races, it is better to
postpone this to port shutdown.
This allows to
The RX FIFO timer may be armed when the port is shut down, hence the
timer function may still be called afterwards.
Fix this race condition by deleting the timer during port shutdown.
Fixes: 039403765e5da3c6 ("serial: sh-sci: SCIFA/B RX FIFO software timeout")
Signed-off-by: Geert Uytterhoeven
-
The transmit DMA workqueue is never stopped, hence the work function may
be called after the port has been shut down.
Fix this race condition by cancelling queued work, if any, before DMA
release. Don't initialize the work if DMA initialization failed, as it
won't be used anyway.
Signed-off-by:
The transmit DMA workqueue is never stopped, hence the work function may
be called after the port has been shut down.
Fix this race condition by cancelling queued work, if any, before DMA
release. Don't initialize the work if DMA initialization failed, as it
won't be used anyway.
Signed-off-by:
When the sh-sci driver detects an issue with DMA during operation, it
falls backs to PIO, and releases all DMA resources.
As releasing DMA resources immediately has no advantages, but
complicates the code, and is susceptible to races, it is better to
postpone this to port shutdown.
This allows to
As of commit b36f09c3c441a6e5 ("dmaengine: Add transfer termination
synchronization support"), dmaengine_terminate_all() is deprecated.
Replace calls to dmaengine_terminate_all() in DMA release code by calls
to dmaengine_terminate_sync(), as the latter waits until all running
completion callbacks
As of commit b36f09c3c441a6e5 ("dmaengine: Add transfer termination
synchronization support"), dmaengine_terminate_all() is deprecated.
Replace calls to dmaengine_terminate_all() in DMA release code by calls
to dmaengine_terminate_sync(), as the latter waits until all running
completion callbacks
The RX FIFO timer may be armed when the port is shut down, hence the
timer function may still be called afterwards.
Fix this race condition by deleting the timer during port shutdown.
Fixes: 039403765e5da3c6 ("serial: sh-sci: SCIFA/B RX FIFO software timeout")
Signed-off-by: Geert Uytterhoeven
-
On Fri, Jun 29, 2018 at 4:25 PM Geert Uytterhoeven
wrote:
> As of commit b36f09c3c441a6e5 ("dmaengine: Add transfer termination
> synchronization support"), dmaengine_terminate_all() is deprecated.
>
> Replace calls to dmaengine_terminate_all() in DMA release code by calls
> to dmaengine_terminate
On Thu, Jun 28, 2018 at 03:33:59PM +0200, Geert Uytterhoeven wrote:
> On Thu, Jun 28, 2018 at 2:43 PM Simon Horman
> wrote:
> > This node is just a placeholder but fills that function better if it does
> > not trigger build warnings. This update satisfies the requirement that
> > nodes with #addr
On Fri, Jun 29, 2018 at 4:26 PM Geert Uytterhoeven
wrote:
> When the sh-sci driver detects an issue with DMA during operation, it
> falls backs to PIO, and releases all DMA resources.
>
> As releasing DMA resources immediately has no advantages, but
> complicates the code, and is susceptible to ra
On Fri, Jun 29, 2018 at 07:01:44PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that lacks the dma_unmap_sg() calling in
> the error patch of renesas_sdhi_internal_dmac_start_dma().
>
> Fixes: 0cbc94daa554 ("mmc: renesas_sdhi_internal_dmac: limit DMA RX for old
> SoCs")
> Cc: # v4
On Fri, Jun 29, 2018 at 07:01:45PM +0900, Yoshihiro Shimoda wrote:
> This patch is fixes an issue that the SDHI_INTERNAL_DMAC_RX_IN_USE
> flag cannot be cleared because tmio_mmc_core sets the host->data
> to NULL before the tmio_mmc_core calls tmio_mmc_abort_dma().
>
> So, this patch clears the SD
HSCIF is superior to SCIF (larger FIFOs, more accurate and wider
supported range of bitrates).
Signed-off-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/salvator-com
On Fri, Jun 29, 2018 at 04:28:03PM +0200, Geert Uytterhoeven wrote:
> The RX FIFO timer may be armed when the port is shut down, hence the
> timer function may still be called afterwards.
>
> Fix this race condition by deleting the timer during port shutdown.
>
> Fixes: 039403765e5da3c6 ("serial:
Hello,
This patch series is a prototype that attemps to solve the display performance
problem inherent to the virtio-gpu protocol when VIRGL support isn't available
on the host side.
The first patch is the latest version (I found) of the virtio-gpu protocol
specification patch from Gerd Hoffmann.
From: Gerd Hoffmann
Resuming the effort to get the gpu device specs merged.
Support for 2d mode (3d/virgl mode is not covered by this patch) has
been added to the linux kernel version 4.2 and to qemu version 2.4.
git branch:
https://www.kraxel.org/cgit/virtio-spec/commit/?h=virtio-gpu
Render
The virtio-gpu protocol is based on opaque host resources backed by
guest-allocated memory. This requires transferring data from guest
framebuffers to host display device buffers.
When the host supports VIRGL, the GPU is used for both 2D and 3D
rendering, in which case the memory transfer can take
31 matches
Mail list logo