On Thu, Feb 08, 2018 at 02:13:06PM -0600, Rob Herring wrote:
> On Fri, Feb 02, 2018 at 09:45:08PM +0300, Sergei Shtylyov wrote:
> > Document the Condor device tree bindings, listing it as a supported board.
> >
> > This allows to use checkpatch.pl to validate .dts files referring to the
> > Condor
Hi Wolfram,
As part of my work looking at using i2c_new_secondary_device() to move address
mappings into the device tree, it has become evident that the return code of the
i2c_new_secondary_device() is obfuscated, and is simply a valid client - or
NULL.
This means that we must 'guess' as to whet
On Thu, Feb 8, 2018 at 11:34 AM, Geert Uytterhoeven
wrote:
> This patch series enables the builtin watchdog timer on R-Car Gen2 SoCs
> on all supported boards, and builds on top of Fabrizio's "[RFC v4 00/26]
> Fix watchdog on Renesas R-Car Gen2 and RZ/G1". It is marked RFC as it
> is known not to
Hi Kieran,
On Friday, 9 February 2018 12:01:09 EET Kieran Bingham wrote:
> Hi Wolfram,
>
> As part of my work looking at using i2c_new_secondary_device() to move
> address mappings into the device tree, it has become evident that the
> return code of the i2c_new_secondary_device() is obfuscated,
From: Kieran Bingham
To allow dual pipelines utilising two WPF entities when available, the
VSP was updated to support header-mode display list in continuous
pipelines.
A small bug in the status check of the command register causes the
second pipeline to be directly afflicted by the running of t
Hi Kieran,
Thank you for the patch.
On Friday, 9 February 2018 15:18:25 EET Kieran Bingham wrote:
> From: Kieran Bingham
>
> To allow dual pipelines utilising two WPF entities when available, the
> VSP was updated to support header-mode display list in continuous
> pipelines.
>
> A small bug i
From: Kieran Bingham
To allow dual pipelines utilising two WPF entities when available, the
VSP was updated to support header-mode display list in continuous
pipelines.
A small bug in the status check of the command register causes the
second pipeline to be directly afflicted by the running of t
Hi Laurent,
On 09/02/18 13:27, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Friday, 9 February 2018 15:18:25 EET Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> To allow dual pipelines utilising two WPF entities when available, the
>> VSP was updated to support h
Enable VFIO_PLATFORM for platform device pass-through.
Enable VFIO_NOIOMMU for devices not part of an IOMMU group.
Not-Signed-off-by: Geert Uytterhoeven
---
Not intended for upstream merge.
---
arch/arm64/configs/renesas_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/
The GPIO6 block will be exported to a guest. As long as the guest won't
manage its module clock, it must be kept running by the host.
Not-Signed-off-by: Geert Uytterhoeven
---
TODO: Find a way to manage module clocks using PM Domains and Runtime
PM on the guest.
---
drivers/clk/renesas/r8
Currently reset_required can be configured using a module parameter.
But it cannot be overridden at runtime through sysfs, as the parameter
is read-only.
Make it writeable for root, as this is useful if vfio-platform is
builtin, so the following works:
echo 0 > /sys/module/vfio_platform/param
Hi all,
This RFC patch series is the Linux side of a GPIO Pass-Through prototype
for Renesas R-Car platforms using vfio-platform. Together with its
counterpart for QEMU, it provides direct access from a QEMU+KVM guest to
a GPIO controller in an R-Car Gen3 SoC. This allows the guest to
co
Add a simple defconfig for virtualized arm64 machines, based on an
OpenWRT config. This expects "initramfs.cpio" to exist, which can be
extracted from e.g. an OpenWRT image using binwalk.
CONFIG_GPIO_RCAR is enabled for testing GPIO pass-through on R-Car Gen3.
Not-Signed-off-by: Geert Uytterhoev
Allow the instantiation of a Renesas R-Car Gen3 GPIO controller device
from the QEMU command line:
-device vfio-platform,host=,manufacturer=renesas,model=rcar-gen3-gpio
-device vfio-platform,sysfsdev=,manufacturer=renesas,model=rcar-gen3-gpio
A specialized device tree node is created for the gues
From: Auger Eric
Up to now the vfio-platform device has been abstract and could not be
instantiated. The integration of a new vfio platform device required
to create a dummy derived device which only set the compatibility
string.
Following the few vfio-platform device integration we have seen
th
From: Xiao Feng Ren
Add qemu support for the newly introduced VFIO No-IOMMU driver.
We need to add special handling for:
- Group character device is /dev/vfio/noiommu-$GROUP.
- No-IOMMU does not rely on a memory listener.
- No IOMMU will be set for its group, so no need to call
vfio_kvm_device
From: Auger Eric
Up to now we have relied on the device type to identify a device tree
node creation function. Since we would like the VFIO-PLATFORM
device to be instantiable with different compatibility strings
we introduce the capability to specialize the node creation depending
on a manufactur
Allow the instantation of generic dynamic sysbus devices again, without
the need to create a new device-specific vfio type.
This is a partial revert of commit 6f2062b9758ebc64 ("hw/arm/virt:
Allow only supported dynamic sysbus devices").
Not-Yet-Signed-off-by: Geert Uytterhoeven
---
hw/arm/vir
Hi all,
This RFC patch series is the QEMU side of a GPIO Pass-Through prototype
for Renesas R-Car platforms using vfio-platform. Together with its
counterpart for Linux, it provides direct access from a QEMU+KVM guest
to a GPIO controller in an R-Car Gen3 SoC. This allows the guest to
co
Allow to enable the driver if virtualization is enabled.
Handle the absence of clocks and interrupts, to support guests that
don't provide these yet.
Not-Signed-off-by: Geert Uytterhoeven
---
To be dropped once clocks and interrupts are supported on the guest.
---
drivers/gpio/Kconfig | 2
Allow use of the No-IOMMU mode even if a real IOMMU is present.
This is useful in case the device is not part of an actual IOMMU group.
Not-Signed-off-by: Geert Uytterhoeven
---
Question:
- Some devices (e.g. rcar-gpio) don't use DMA, so why do they need an
IOMMU group?
- Even devices usi
On 9 February 2018 at 15:17, Geert Uytterhoeven wrote:
> Allow the instantation of generic dynamic sysbus devices again, without
> the need to create a new device-specific vfio type.
>
> This is a partial revert of commit 6f2062b9758ebc64 ("hw/arm/virt:
> Allow only supported dynamic sysbus devic
Hi Kieran,
Thanks for your patch.
On 2018-02-07 21:11:35 +, Kieran Bingham wrote:
> From: Kieran Bingham
>
> The error handling for the adv748x_identify_chip() call erroneously
> jumps to the err_cleanup_clients label before the clients have been
> established.
>
> Correct this by jumping
Hi Peter,
On Fri, Feb 9, 2018 at 4:27 PM, Peter Maydell wrote:
> On 9 February 2018 at 15:17, Geert Uytterhoeven
> wrote:
>> Allow the instantation of generic dynamic sysbus devices again, without
>> the need to create a new device-specific vfio type.
>>
>> This is a partial revert of commit 6
Hi Kieran,
Thanks for your patch.
On 2018-02-07 17:34:45 +, Kieran Bingham wrote:
> From: Kieran Bingham
>
> The ADV748x has identical map configurations for each register map. The
> duplication of each map can be simplified using a helper macro such that
> each map is represented on a sing
Hi Kieran,
Thanks for your patch,
On 2018-02-07 17:34:46 +, Kieran Bingham wrote:
> From: Kieran Bingham
>
> The ADV748x has 12 pages mapped onto I2C addresses.
>
> In the existing implementation only 11 are mapped correctly in the page
> enumerations, which causes an off-by-one fault on p
Hi Niklas,
On 09/02/18 15:39, Niklas Söderlund wrote:
> Hi Kieran,
>
> Thanks for your patch.
>
> On 2018-02-07 17:34:45 +, Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> The ADV748x has identical map configurations for each register map. The
>> duplication of each map can be simplifie
On 9 February 2018 at 15:37, Geert Uytterhoeven wrote:
> Hi Peter,
>
> On Fri, Feb 9, 2018 at 4:27 PM, Peter Maydell
> wrote:
>> On 9 February 2018 at 15:17, Geert Uytterhoeven
>> wrote:
>>> Allow the instantation of generic dynamic sysbus devices again, without
>>> the need to create a new de
On Fri, 9 Feb 2018 16:17:35 +0100
Geert Uytterhoeven wrote:
> From: Xiao Feng Ren
>
> Add qemu support for the newly introduced VFIO No-IOMMU driver.
>
> We need to add special handling for:
> - Group character device is /dev/vfio/noiommu-$GROUP.
> - No-IOMMU does not rely on a memory listene
On Mon, Jan 29, 2018 at 7:01 PM, Simon Horman
wrote:
> From: Takeshi Kihara
>
> This patch adds Z clock divider support for R-Car Gen3 SoC.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
I.e. will queue in clk-renesas-for-v4.17.
Gr{oetje,eeti
On Mon, Jan 29, 2018 at 7:01 PM, Simon Horman
wrote:
> From: Takeshi Kihara
>
> This patch adds Z2 clock divider support for R-Car Gen3 SoC.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
I.e. will queue in clk-renesas-for-v4.17.
Gr{oetje,eet
Hi Alex,
On Fri, Feb 9, 2018 at 4:50 PM, Alex Williamson
wrote:
> On Fri, 9 Feb 2018 16:17:35 +0100
> Geert Uytterhoeven wrote:
>> From: Xiao Feng Ren
>>
>> Add qemu support for the newly introduced VFIO No-IOMMU driver.
>>
>> We need to add special handling for:
>> - Group character device is
Hi Geert,
Please consider including this fix for the VSP1 in renesas-drivers.
--
Regards
Kieran
The following changes since commit d8a5b80568a9cb66810e75b182018e9edb68e8ff:
Linux 4.15 (2018-01-28 13:20:33 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/k
On Fri, 9 Feb 2018 17:06:34 +0100
Geert Uytterhoeven wrote:
> Hi Alex,
>
> On Fri, Feb 9, 2018 at 4:50 PM, Alex Williamson
> wrote:
> > On Fri, 9 Feb 2018 16:17:35 +0100
> > Geert Uytterhoeven wrote:
> >> From: Xiao Feng Ren
> >>
> >> Add qemu support for the newly introduced VFIO No-IOMMU
Enable PINCTRL_RZA1 option in shmobile_defconfig
Signed-off-by: Jacopo Mondi
---
Hi Simon,
this fixes the issue you reported on Genmai when applying shmobile_defconfig.
---
arch/arm/configs/shmobile_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/shmobile_defcon
Am 09.02.2018 um 11:01 schrieb Kieran Bingham:
> Hi Wolfram,
>
> As part of my work looking at using i2c_new_secondary_device() to move address
> mappings into the device tree, it has become evident that the return code of
> the
> i2c_new_secondary_device() is obfuscated, and is simply a valid cl
Hi Heiner,
On 09/02/18 17:59, Heiner Kallweit wrote:
> Am 09.02.2018 um 11:01 schrieb Kieran Bingham:
>> Hi Wolfram,
>>
>> As part of my work looking at using i2c_new_secondary_device() to move
>> address
>> mappings into the device tree, it has become evident that the return code of
>> the
>> i
On Tue, Feb 06, 2018 at 02:05:52PM +0100, Geert Uytterhoeven wrote:
> The Stream Buffer for EtherAVB-IF (STBE) is an optional component, and
> is not present on all SoCs.
>
> Document this in the DT bindings, including a list of SoCs that do have
> it.
>
> Fixes: 785ec87483d1e24a ("ravb: document
38 matches
Mail list logo