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
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
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
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
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
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: #
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
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
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
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
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 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
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
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:
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
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
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()
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
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
---
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
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
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 +++
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
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:
> > + /* 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
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
30 matches
Mail list logo
