* support autofocus / autogain in libv4l2
From: Pavel Machek @ 2017-04-26 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493139207.19105.16.camel@ndufresne.ca>
On Tue 2017-04-25 12:53:27, Nicolas Dufresne wrote:
> Le mardi 25 avril 2017 ? 10:05 +0200, Pavel Machek a ?crit?:
> > Well, fd's are hard, because application can do fork() and now
> > interesting stuff happens. Threads are tricky, because now you have
> > locking etc.
> >
> > libv4l2 is designed to be LD_PRELOADED. That is not really feasible
> > with "complex" library.
>
> That is incorrect. The library propose an API where you simply replace
> certain low level calls, like ioctl -> v4l2_ioctl, open -> v4l2_open().
> You have to do that explicitly in your existing code. It does not
> abstract the API itself unlike libdrm.
You are right, no LD_PRELOAD. But same API as kernel, which is really
limiting -- see my other mail.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170426/022f73cb/attachment.sig>
^ permalink raw reply
* [PATCH v4 00/21] PCI: fix config space memory mappings
From: Dongdong Liu @ 2017-04-26 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2e24e205-d761-9172-9463-4a53e1a0de4d@jonmasters.org>
Tested-by: Dongdong Liu <liudongdong3@huawei.com>
I tested the patchset on HiSilicon ARM64 D05 board.It works ok with 82599 netcard.
Thanks,
Dongdong
? 2017/4/25 14:40, Jon Masters ??:
> On 04/19/2017 12:48 PM, Lorenzo Pieralisi wrote:
>
>> On some platforms (ie ARM/ARM64) ioremap fails to comply with the PCI
>> configuration non-posted write transactions requirement, because it
>> provides a memory mapping that issues "bufferable" or, in PCI terms
>> "posted" write transactions. Likewise, the current pci_remap_iospace()
>> implementation maps the physical address range that the PCI translates
>> to I/O space cycles to virtual address space through pgprot_device()
>> attributes that on eg ARM64 provides a memory mapping issuing
>> posted writes transactions, which is not PCI specifications compliant.
>
> Side note that I've pinged all of the ARM server vendors and asked them
> to verify this patch series on their platforms.
>
> Jon.
>
> .
>
^ permalink raw reply
* [patch] propagating controls in libv4l2 was Re: support autofocus / autogain in libv4l2
From: Pavel Machek @ 2017-04-26 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424224724.5bb52382@vento.lan>
Hi!
> > > IMO, the best place for autofocus is at libv4l2. Putting it on a
> > > separate "video server" application looks really weird for me.
> >
> > Well... let me see. libraries are quite limited -- it is hard to open
> > files, or use threads/have custom main loop. It may be useful to
> > switch resolutions -- do autofocus/autogain at lower resolution, then
> > switch to high one for taking picture. It would be good to have that
> > in "system" code, but I'm not at all sure libv4l2 design will allow
> > that.
>
> I don't see why it would be hard to open files or have threads inside
> a library. There are several libraries that do that already, specially
> the ones designed to be used on multimidia apps.
Well, This is what the libv4l2 says:
This file implements libv4l2, which offers v4l2_ prefixed versions
of
open/close/etc. The API is 100% the same as directly opening
/dev/videoX
using regular open/close/etc, the big difference is that format
conversion
but if I open additional files in v4l2_open(), API is no longer the
same, as unix open() is defined to open just one file descriptor.
Now. There is autogain support in libv4lconvert, but it expects to use
same fd for camera and for the gain... which does not work with
subdevs.
Of course, opening subdevs by name like this is not really
acceptable. But can you suggest a method that is?
Thanks,
Pavel
commit 4cf9d10ead014c0db25452e4bb9cd144632407c3
Author: Pavel <pavel@ucw.cz>
Date: Wed Apr 26 11:38:04 2017 +0200
Add subdevices.
diff --git a/lib/libv4l2/libv4l2-priv.h b/lib/libv4l2/libv4l2-priv.h
index 343db5e..a6bc48e 100644
--- a/lib/libv4l2/libv4l2-priv.h
+++ b/lib/libv4l2/libv4l2-priv.h
@@ -26,6 +26,7 @@
#include "../libv4lconvert/libv4lsyscall-priv.h"
#define V4L2_MAX_DEVICES 16
+#define V4L2_MAX_SUBDEVS 8
/* Warning when making this larger the frame_queued and frame_mapped members of
the v4l2_dev_info struct can no longer be a bitfield, so the code needs to
be adjusted! */
@@ -104,6 +105,7 @@ struct v4l2_dev_info {
void *plugin_library;
void *dev_ops_priv;
const struct libv4l_dev_ops *dev_ops;
+ int subdev_fds[V4L2_MAX_SUBDEVS];
};
/* From v4l2-plugin.c */
diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
index 0ba0a88..edc9642 100644
--- a/lib/libv4l2/libv4l2.c
+++ b/lib/libv4l2/libv4l2.c
@@ -1,3 +1,4 @@
+/* -*- c-file-style: "linux" -*- */
/*
# (C) 2008 Hans de Goede <hdegoede@redhat.com>
@@ -789,18 +790,25 @@ no_capture:
/* Note we always tell v4lconvert to optimize src fmt selection for
our default fps, the only exception is the app explicitly selecting
- a fram erate using the S_PARM ioctl after a S_FMT */
+ a frame rate using the S_PARM ioctl after a S_FMT */
if (devices[index].convert)
v4lconvert_set_fps(devices[index].convert, V4L2_DEFAULT_FPS);
v4l2_update_fps(index, &parm);
+ devices[index].subdev_fds[0] = SYS_OPEN("/dev/video_sensor", O_RDWR, 0);
+ devices[index].subdev_fds[1] = SYS_OPEN("/dev/video_focus", O_RDWR, 0);
+ devices[index].subdev_fds[2] = -1;
+
+ printf("Sensor: %d, focus: %d\n", devices[index].subdev_fds[0],
+ devices[index].subdev_fds[1]);
+
V4L2_LOG("open: %d\n", fd);
return fd;
}
/* Is this an fd for which we are emulating v4l1 ? */
-static int v4l2_get_index(int fd)
+int v4l2_get_index(int fd)
{
int index;
commit 1d6a9ce121f53e8f2e38549eed597a3c3dea5233
Author: Pavel <pavel@ucw.cz>
Date: Wed Apr 26 12:34:04 2017 +0200
Enable ioctl propagation.
diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
index edc9642..6dab661 100644
--- a/lib/libv4l2/libv4l2.c
+++ b/lib/libv4l2/libv4l2.c
@@ -1064,6 +1064,23 @@ static int v4l2_s_fmt(int index, struct v4l2_format *dest_fmt)
return 0;
}
+static int v4l2_propagate_ioctl(int index, unsigned long request, void *arg)
+{
+ int i = 0;
+ int result;
+ while (1) {
+ if (devices[index].subdev_fds[i] == -1)
+ return -1;
+ printf("g_ctrl failed, trying...\n");
+ result = SYS_IOCTL(devices[index].subdev_fds[i], request, arg);
+ printf("subdev %d result %d\n", i, result);
+ if (result == 0)
+ return 0;
+ i++;
+ }
+ return -1;
+}
+
int v4l2_ioctl(int fd, unsigned long int request, ...)
{
void *arg;
@@ -1193,14 +1210,20 @@ no_capture_request:
switch (request) {
case VIDIOC_QUERYCTRL:
result = v4lconvert_vidioc_queryctrl(devices[index].convert, arg);
+ if (result == -1)
+ result = v4l2_propagate_ioctl(index, request, arg);
break;
case VIDIOC_G_CTRL:
result = v4lconvert_vidioc_g_ctrl(devices[index].convert, arg);
+ if (result == -1)
+ result = v4l2_propagate_ioctl(index, request, arg);
break;
case VIDIOC_S_CTRL:
result = v4lconvert_vidioc_s_ctrl(devices[index].convert, arg);
+ if (result == -1)
+ result = v4l2_propagate_ioctl(index, request, arg);
break;
case VIDIOC_G_EXT_CTRLS:
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170426/d174a739/attachment-0001.sig>
^ permalink raw reply related
* [PATCH v2] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed
From: Sunil Kovvuri @ 2017-04-26 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426100150.GE21744@arm.com>
On Wed, Apr 26, 2017 at 3:31 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Sunil,
>
> On Tue, Apr 25, 2017 at 03:27:52PM +0530, sunil.kovvuri at gmail.com wrote:
>> From: Sunil Goutham <sgoutham@cavium.com>
>>
>> For software initiated address translation, when domain type is
>> IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior
>> i.e return the same IOVA as translated address.
>>
>> This patch is an extension to Will Deacon's patchset
>> "Implement SMMU passthrough using the default domain".
>>
>> Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
>> ---
>>
>> V2
>> - As per Will's suggestion applied fix to SMMUv3 driver as well.
>
> This follows what the AMD driver does, so:
>
> Acked-by: Will Deacon <will.deacon@arm.com>
Thanks,
>
> but I still think that having drivers/net/ethernet/cavium/thunder/nicvf_queues.c
> poke around with the physical address to get at the struct pages underlying
> a DMA buffer is really dodgy.
Driver is not dealing with page structures to be precise, just like
for any other NIC device, driver needs to know the virtual address
of the packet to where it's DMA'ed, so that SKB if framed and
handed over to network stack. Due to reasons mentioned below,
in this driver it's not possible to maintain a list of DMA addresses to
Virtual address mappings. Hence using IOMMU API, DMA address
is translated to physical address and finally to virtual address. I don't
see anything dodgy here.
> Is there no way this can be avoided, perhaps by tracking the pages some other way
I have explained that in the commit message
--
Also VNIC doesn't have a seperate receive buffer ring per receive
queue, so there is no 1:1 descriptor index matching between CQE_RX
and the index in buffer ring from where a buffer has been used for
DMA'ing. Unlike other NICs, here it's not possible to maintain dma
address to virt address mappings within the driver. This leaves us
no other choice but to use IOMMU's IOVA address conversion API to
get buffer's virtual address which can be given to network stack
for processing.
--
>(although I don't understand why you're having to mess with the page reference
>counts to start with)?
Not sure why you say it's a mess, adjusting page reference counts is quite
common if you check other NIC drivers. On ARM64 especially when using
64KB pages, if we have only one packet buffer for each page then we
will have to set aside a whole lot of memory which sometimes is not possible
on embedded platforms. Hence multiple pkt buffers per page, and page reference
is set accordingly.
>
> At least, I think you should be checking the domain type in
> nicvf_iova_to_phys, which clearly expects a DMA domain if one exists at all.
Probably, but I don't think network maintainers would be okay with it, since
such stuff should be hidden from a network driver's point of view. In reverse
the argument can be that NIC driver shouldn't even have to check if domain
is set or not.
Thanks,
Sunil.
>
> Joerg: sorry, this is another one for you to pick up if possible.
>
> Cheers,
>
> Will
>
>> drivers/iommu/arm-smmu-v3.c | 3 +++
>> drivers/iommu/arm-smmu.c | 3 +++
>> 2 files changed, 6 insertions(+)
>>
>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>> index 05b4592..d412bdd 100644
>> --- a/drivers/iommu/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm-smmu-v3.c
>> @@ -1714,6 +1714,9 @@ arm_smmu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova)
>> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
>> struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops;
>>
>> + if (domain->type == IOMMU_DOMAIN_IDENTITY)
>> + return iova;
>> +
>> if (!ops)
>> return 0;
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index bfab4f7..81088cd 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -1459,6 +1459,9 @@ static phys_addr_t arm_smmu_iova_to_phys(struct iommu_domain *domain,
>> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
>> struct io_pgtable_ops *ops= smmu_domain->pgtbl_ops;
>>
>> + if (domain->type == IOMMU_DOMAIN_IDENTITY)
>> + return iova;
>> +
>> if (!ops)
>> return 0;
>>
>> --
>> 2.7.4
>>
^ permalink raw reply
* [patch V2 00/24] cpu/hotplug: Convert get_online_cpus() to a percpu_rwsem
From: Mark Rutland @ 2017-04-26 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bad40d9a-2c81-5a6c-2c12-3bf7094549de@arm.com>
On Wed, Apr 26, 2017 at 10:40:47AM +0100, Suzuki K Poulose wrote:
> On 26/04/17 09:59, Mark Rutland wrote:
> >We only call cpus_set_cap() in the secondary boot path, where we know
> >that the rwsem is held by the thread orchestrating the onlining. Thus,
> >we can use the new static_branch_enable_cpuslocked() in cpus_set_cap(),
> >avoiding the above.
>
> Correction, we could call cpus_set_cap() from setup_cpu_features()
> for updating the system global capabilities, where we may not hold the
> cpu_hotplug_lock.
Argh, yes, I missed that when scanning.
> So we could end up calling static_branch_enable_cpuslocked()
> without actually holding the lock. Should we do a cpu_hotplug_begin/done in
> setup_cpu_feature_capabilities ? I agree it doesn't look that nice. Thoughts ?
I agree that's hideous, but it looks like the only choice given the
hotplug rwsem cahnges. :/
I can spin a v2 with that and the typo fixes.
Thanks,
Mark.
>
> Suzuki
>
> >
> >Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> >Reported-by: Catalin Marinas <catalin.marinas@arm.com>
> >Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> >Cc: Will Deacon <will.deacon@arm.com>
> >Cc: Suzuki Poulose <suzuki,poulose@arm.com>
> >---
> > arch/arm64/include/asm/cpufeature.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> >index f31c48d..349b5cd 100644
> >--- a/arch/arm64/include/asm/cpufeature.h
> >+++ b/arch/arm64/include/asm/cpufeature.h
> >@@ -145,7 +145,7 @@ static inline void cpus_set_cap(unsigned int num)
> > num, ARM64_NCAPS);
> > } else {
> > __set_bit(num, cpu_hwcaps);
> >- static_branch_enable(&cpu_hwcap_keys[num]);
> >+ static_branch_enable_cpuslocked(&cpu_hwcap_keys[num]);
> > }
> > }
> >
> >
>
^ permalink raw reply
* [PATCH v2] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed
From: Joerg Roedel @ 2017-04-26 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426100150.GE21744@arm.com>
On Wed, Apr 26, 2017 at 11:01:50AM +0100, Will Deacon wrote:
> Joerg: sorry, this is another one for you to pick up if possible.
Applied.
^ permalink raw reply
* [PATCH v4 7/7] ARM64: dts: marvell: armada37xx: add pinctrl definition
From: Gregory CLEMENT @ 2017-04-26 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7b07bd69cd506effa716c41f8ec3dda7a7c6c563.1491405475.git-series.gregory.clement@free-electrons.com>
Hi,
On mer., avril 05 2017, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> Start to populate the device tree of the Armada 37xx with the pincontrol
> configuration used on the board providing a dts.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Applied on mvebu/dt64
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-3720-db.dts | 8 +++++-
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 31 +++++++++++++++++++-
> 2 files changed, 39 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
> index 86602c907a61..e749c5727490 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
> @@ -63,6 +63,8 @@
> };
>
> &i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins>;
> status = "okay";
> };
>
> @@ -73,6 +75,8 @@
>
> &spi0 {
> status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi_quad_pins>;
>
> m25p80 at 0 {
> compatible = "jedec,spi-nor";
> @@ -103,6 +107,8 @@
>
> /* Exported on the micro USB connector CON32 through an FTDI */
> &uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart1_pins>;
> status = "okay";
> };
>
> @@ -128,6 +134,8 @@
> };
>
> ð0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii_pins>;
> phy-mode = "rgmii-id";
> phy = <&phy0>;
> status = "okay";
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index c02b13479458..2ac25f54d01d 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -186,6 +186,31 @@
> clock-output-names = "xtal";
> #clock-cells = <0>;
> };
> +
> + spi_quad_pins: spi-quad-pins {
> + groups = "spi_quad";
> + function = "spi";
> + };
> +
> + i2c1_pins: i2c1-pins {
> + groups = "i2c1";
> + function = "i2c";
> + };
> +
> + i2c2_pins: i2c2-pins {
> + groups = "i2c2";
> + function = "i2c";
> + };
> +
> + uart1_pins: uart1-pins {
> + groups = "uart1";
> + function = "uart";
> + };
> +
> + uart2_pins: uart2-pins {
> + groups = "uart2";
> + function = "uart";
> + };
> };
>
> pinctrl_sb: pinctrl-sb at 18800 {
> @@ -203,6 +228,12 @@
> <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
> };
> +
> + rgmii_pins: mii-pins {
> + groups = "rgmii";
> + function = "mii";
> + };
> +
> };
>
> eth0: ethernet at 30000 {
> --
> git-series 0.9.1
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v4 6/7] ARM64: dts: marvell: Add pinctrl nodes for Armada 3700
From: Gregory CLEMENT @ 2017-04-26 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1defc5c1925e819b28f2b3802aadc9a8e7be224a.1491405475.git-series.gregory.clement@free-electrons.com>
Hi,
On mer., avril 05 2017, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> Add the nodes for the two pin controller present in the Armada 37xx SoCs.
>
> Initially the node was named gpio1 using the same name that for the
> register range in the datasheet. However renaming it pinctr_nb (nb for
> North Bridge) makes more sens.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Applied on mvebu/dt64
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 42 +++++++++++++++++++--
> 1 file changed, 39 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index b48d668a6ab6..c02b13479458 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -157,10 +157,29 @@
> #clock-cells = <1>;
> };
>
> - gpio1: gpio at 13800 {
> - compatible = "marvell,mvebu-gpio-3700",
> + pinctrl_nb: pinctrl-nb at 13800 {
> + compatible = "marvell,armada3710-nb-pinctrl",
> "syscon", "simple-mfd";
> - reg = <0x13800 0x500>;
> + reg = <0x13800 0x100>, <0x13C00 0x20>;
> + gpionb: gpionb {
> + #gpio-cells = <2>;
> + gpio-ranges = <&pinctrl_nb 0 0 36>;
> + gpio-controller;
> + interrupts =
> + <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
> +
> + };
>
> xtalclk: xtal-clk {
> compatible = "marvell,armada-3700-xtal-clock";
> @@ -169,6 +188,23 @@
> };
> };
>
> + pinctrl_sb: pinctrl-sb at 18800 {
> + compatible = "marvell,armada3710-sb-pinctrl",
> + "syscon", "simple-mfd";
> + reg = <0x18800 0x100>, <0x18C00 0x20>;
> + gpiosb: gpiosb {
> + #gpio-cells = <2>;
> + gpio-ranges = <&pinctrl_sb 0 0 29>;
> + gpio-controller;
> + interrupts =
> + <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
> + };
> + };
> +
> eth0: ethernet at 30000 {
> compatible = "marvell,armada-3700-neta";
> reg = <0x30000 0x4000>;
> --
> git-series 0.9.1
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v4 2/7] arm64: marvell: enable the Armada 37xx pinctrl driver
From: Gregory CLEMENT @ 2017-04-26 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d5015ded3a76ae4b1d2d1ef43ab4cc2e51050a03.1491405475.git-series.gregory.clement@free-electrons.com>
Hi,
On mer., avril 05 2017, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> This commit makes sure the driver for the Armada 37xx pin controller is
> enabled.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Applied on mvebu/arm64
Thanks,
Gregory
> ---
> arch/arm64/Kconfig.platforms | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 129cc5ae4091..9aa71a3f3f50 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -103,8 +103,13 @@ config ARCH_MVEBU
> select ARMADA_AP806_SYSCON
> select ARMADA_CP110_SYSCON
> select ARMADA_37XX_CLK
> + select GPIOLIB
> + select GPIOLIB_IRQCHIP
> select MVEBU_ODMI
> select MVEBU_PIC
> + select OF_GPIO
> + select PINCTRL
> + select PINCTRL_ARMADA_37XX
> help
> This enables support for Marvell EBU familly, including:
> - Armada 3700 SoC Family
> --
> git-series 0.9.1
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP
From: Will Deacon @ 2017-04-26 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CY4PR07MB3415C0CEBB9D3DF0C249DC6793110@CY4PR07MB3415.namprd07.prod.outlook.com>
On Wed, Apr 26, 2017 at 07:22:46AM +0000, Pinski, Andrew wrote:
> On 4/25/2017 11:53 PM, Jayachandran C. wrote:
> > On Tue, Apr 25, 2017 at 10:23 PM, Will Deacon <will.deacon@arm.com> wrote:
> >> On Tue, Apr 25, 2017 at 09:13:40AM +0530, Ganapatrao Kulkarni wrote:
> >>> On Mon, Apr 24, 2017 at 9:15 PM, Will Deacon <will.deacon@arm.com> wrote:
> >>>> On Thu, Apr 20, 2017 at 02:56:50PM +0530, Ganapatrao Kulkarni wrote:
> >>>>> OK, if you are ok with sysfs part, i can send next version with that
> >>>>> change only?.
> >>>> I think the sysfs part is still a little dodgy, since you still expose the
> >>>> "exclude_hv" file with a value of 0 when not running at EL2, which would
> >>>> imply that exclude_hv is forced to zero. I don't think that's correct.
> >>> okay, i can make exclude_hv visible only when kernel booted in EL2.
> >>> is it ok to have empty directory "attr" when kernel booted to EL1?
> >>> attr can be place holder for any other miscellaneous attributes, that
> >>> can be added in future.
> >> Sounds good to me, although I'll seek comment from the other perf folks
> >> before merging anything with ABI implications.
> > Do you really think this is the solution given:
> > - this is an arm64 specific sysfs interface that is tied to the perf API
That's why I want feedback from others. The intention would be that this can
be used by other PMUs as well, since it's not uncommon that parts of the
sizeable perf_event_attr structure are not used by a given PMU.
> > - the perf API documentation has to be updated for this
So? If having to update documentation means we shouldn't change the kernel,
then we may as well all find new jobs.
> > - All the applications that use the perf API have to be modified to
> > check this sysfs interface
> > - If the application fails to do so, a very narrow corner case
> > (exclude_hv != exclude_kernel and VHE enabled) fails.
See below, but apparently people care about it.
> > Any application that really cares can already do see if exclude_hv !=
> > exclude_kernel case works by calling perf_open_event() with those
> > options and checking the return value.
That's a good point: there is *something* userspace can do, although that
would be arm64-specific and doesn't really help with the state-space
explosion you get with combinations of invalid/unused perf_event_attr
fields.
> An example of an application which needs to changed is HHVM. Currently
> it sets exclude_hv to true but exclude_kernel to false as it does not
> care about the hypervisor associated perf events associated with the
> code, only the kernel and userspace associated evnts.
> Yes we could submit a patch to use the sysfs interface to check but it
> would look funny and the facebook folks might reject the patch as it is
> ARM64 specific in generic code. Note this is how all of this discussion
> started was HHVM's call to perf_open_event was failing.
Hmm, if you're saying that HHVM won't be changed to use the sysfs stuff,
then why are we bothering?
Not sure where this leaves us.
Will
^ permalink raw reply
* [RFC PATCH 29/30] vfio: Add support for Shared Virtual Memory
From: Jean-Philippe Brucker @ 2017-04-26 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f5745241-83b0-0945-7616-4b59d7ebcd48@semihalf.com>
On 26/04/17 07:53, Tomasz Nowicki wrote:
>> + mutex_lock(&device->tasks_lock);
>> + list_for_each_entry(vfio_task, &device->tasks, list) {
>> + if (vfio_task->pasid != svm.pasid)
>> + continue;
>> +
>> + ret = iommu_unbind_task(device->dev, svm.pasid, flags);
>> + if (ret)
>> + dev_warn(device->dev, "failed to unbind PASID %u\n",
>> + vfio_task->pasid);
>> +
>> + list_del(&vfio_task->list);
>> + kfree(vfio_task);
>
> Please use list_for_each_entry_safe.
There is:
+ break;
right after kfree, so we'd never follow vfio_task->list.next after freeing
vfio_task. The code searches for the _only_ task matching the PASID,
removes it and leaves the loop.
Thanks,
Jean-Philippe
^ permalink raw reply
* [RFC PATCH 30/30] vfio: Allow to bind foreign task
From: Jean-Philippe Brucker @ 2017-04-26 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b937914a-d215-8223-0846-65271a568170@semihalf.com>
Hi Tomasz,
Thanks for looking at this.
On 26/04/17 08:25, Tomasz Nowicki wrote:
> On 27.02.2017 20:54, Jean-Philippe Brucker wrote:
>> Let the process that owns the device create an address space bond on
>> behalf of another process. We add a pid argument to the BIND_TASK ioctl,
>> allowing the caller to bind a foreign task. The expected program flow in
>> this case is:
>>
>> * Process A creates the VFIO context and initializes the device.
>> * Process B asks A to bind its address space.
>> * Process A issues an ioctl to the VFIO device fd with BIND_TASK(pid).
>> It may communicate the given PASID back to process B or keep track of it
>> internally.
>> * Process B asks A to perform transactions on its virtual address.
>> * Process A launches transaction tagged with the given PASID.
>>
>> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
>> ---
>> drivers/vfio/vfio.c | 35 +++++++++++++++++++++++++++++++++--
>> include/uapi/linux/vfio.h | 15 +++++++++++++++
>> 2 files changed, 48 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
>> index c4505d8f4c61..ecc5d07e3dbb 100644
>> --- a/drivers/vfio/vfio.c
>> +++ b/drivers/vfio/vfio.c
>> @@ -26,6 +26,7 @@
>> #include <linux/module.h>
>> #include <linux/mutex.h>
>> #include <linux/pci.h>
>> +#include <linux/ptrace.h>
>> #include <linux/rwsem.h>
>> #include <linux/sched.h>
>> #include <linux/slab.h>
>> @@ -1660,7 +1661,7 @@ static long vfio_svm_ioctl(struct vfio_device
>> *device, unsigned int cmd,
>> struct vfio_device_svm svm;
>> struct vfio_task *vfio_task;
>>
>> - minsz = offsetofend(struct vfio_device_svm, pasid);
>> + minsz = offsetofend(struct vfio_device_svm, pid);
>>
>> if (copy_from_user(&svm, (void __user *)arg, minsz))
>> return -EFAULT;
>> @@ -1669,9 +1670,39 @@ static long vfio_svm_ioctl(struct vfio_device
>> *device, unsigned int cmd,
>> return -EINVAL;
>>
>> if (cmd == VFIO_DEVICE_BIND_TASK) {
>> - struct task_struct *task = current;
>> + struct mm_struct *mm;
>> + struct task_struct *task;
>> +
>> + if (svm.flags & ~VFIO_SVM_PID)
>> + return -EINVAL;
>> +
>> + if (svm.flags & VFIO_SVM_PID) {
>> + rcu_read_lock();
>> + task = find_task_by_vpid(svm.pid);
>> + if (task)
>> + get_task_struct(task);
>> + rcu_read_unlock();
>> + if (!task)
>> + return -ESRCH;
>> +
>> + /*
>> + * Ensure process has RW access on the task's mm
>> + * FIXME:
>> + * - I think this ought to be in the IOMMU API
>> + * - I'm assuming permission is never revoked during the
>> + * task's lifetime. Might be mistaken.
>> + */
>> + mm = mm_access(task, PTRACE_MODE_ATTACH_REALCREDS);
>> + if (!mm || IS_ERR(mm))
>
> I know this is RFC patch but considering we will keep this as is, we need
> here:
> +put_task_struct(task);
Indeed. I considerably reworked the VFIO patches for next version, but
this bug was still in there.
Thanks,
Jean-Philippe
^ permalink raw reply
* [PATCH 9/9] ARM: dts: sh73a0: update PFC node name to pin-controller
From: Simon Horman @ 2017-04-26 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426100538.22060-1-horms+renesas@verge.net.au>
The device trees for Renesas SoCs use either pfc or pin-controller as the
node name for the PFC device. This patch is intended to take a step towards
unifying the node name used as pin-controller which appears to be the more
generic of the two and thus more in keeping with the DT specs.
My analysis is that this is a user-visible change to the extent that kernel
logs, and sysfs entries change from e6050000.pfc and pfc at e6050000 to
e6050000.pin-controller and pin-controller at e6050000.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/sh73a0.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index 6b01ab354e88..4ea5c5a16c57 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -444,7 +444,7 @@
status = "disabled";
};
- pfc: pfc at e6050000 {
+ pfc: pin-controller at e6050000 {
compatible = "renesas,pfc-sh73a0";
reg = <0xe6050000 0x8000>,
<0xe605801c 0x1c>;
--
2.12.2.816.g2cccc81164
^ permalink raw reply related
* [PATCH 8/9] ARM: dts: r8a7793: update PFC node name to pin-controller
From: Simon Horman @ 2017-04-26 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426100538.22060-1-horms+renesas@verge.net.au>
The device trees for Renesas SoCs use either pfc or pin-controller as the
node name for the PFC device. This patch is intended to take a step towards
unifying the node name used as pin-controller which appears to be the more
generic of the two and thus more in keeping with the DT specs.
My analysis is that this is a user-visible change to the extent that kernel
logs, and sysfs entries change from e6060000.pfc and pfc at e6060000 to
e6060000.pin-controller and pin-controller at e6060000.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7793.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 4de6041d61f9..728b5bca5bdb 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -529,7 +529,7 @@
status = "disabled";
};
- pfc: pfc at e6060000 {
+ pfc: pin-controller at e6060000 {
compatible = "renesas,pfc-r8a7793";
reg = <0 0xe6060000 0 0x250>;
};
--
2.12.2.816.g2cccc81164
^ permalink raw reply related
* [PATCH 7/9] ARM: dts: r8a7791: update PFC node name to pin-controller
From: Simon Horman @ 2017-04-26 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426100538.22060-1-horms+renesas@verge.net.au>
The device trees for Renesas SoCs use either pfc or pin-controller as the
node name for the PFC device. This patch is intended to take a step towards
unifying the node name used as pin-controller which appears to be the more
generic of the two and thus more in keeping with the DT specs.
My analysis is that this is a user-visible change to the extent that kernel
logs, and sysfs entries change from e6060000.pfc and pfc at e6060000 to
e6060000.pin-controller and pin-controller at e6060000.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7791.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 4d0c2ce59900..540c5b27b842 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -562,7 +562,7 @@
status = "disabled";
};
- pfc: pfc at e6060000 {
+ pfc: pin-controller at e6060000 {
compatible = "renesas,pfc-r8a7791";
reg = <0 0xe6060000 0 0x250>;
};
--
2.12.2.816.g2cccc81164
^ permalink raw reply related
* [PATCH 6/9] ARM: dts: r8a7790: update PFC node name to pin-controller
From: Simon Horman @ 2017-04-26 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426100538.22060-1-horms+renesas@verge.net.au>
The device trees for Renesas SoCs use either pfc or pin-controller as the
node name for the PFC device. This patch is intended to take a step towards
unifying the node name used as pin-controller which appears to be the more
generic of the two and thus more in keeping with the DT specs.
My analysis is that this is a user-visible change to the extent that kernel
logs, and sysfs entries change from e6060000.pfc and pfc at e6060000 to
e6060000.pin-controller and pin-controller at e6060000.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7790.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 99269aaca6fc..416956a42c93 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -614,7 +614,7 @@
max-frequency = <97500000>;
};
- pfc: pfc at e6060000 {
+ pfc: pin-controller at e6060000 {
compatible = "renesas,pfc-r8a7790";
reg = <0 0xe6060000 0 0x250>;
};
--
2.12.2.816.g2cccc81164
^ permalink raw reply related
* [PATCH 5/9] ARM: dts: r8a7779: update PFC node name to pin-controller
From: Simon Horman @ 2017-04-26 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426100538.22060-1-horms+renesas@verge.net.au>
The device trees for Renesas SoCs use either pfc or pin-controller as the
node name for the PFC device. This patch is intended to take a step towards
unifying the node name used as pin-controller which appears to be the more
generic of the two and thus more in keeping with the DT specs.
My analysis is that this is a user-visible change to the extent that kernel
logs, and sysfs entries change from fffc0000.pfc and pfc at fffc0000 to
fffc0000.pin-controller and pin-controller at fffc0000.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7779.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index ae2d9a9c65af..8ee0b2ca5d39 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -286,7 +286,7 @@
status = "disabled";
};
- pfc: pfc at fffc0000 {
+ pfc: pin-controller at fffc0000 {
compatible = "renesas,pfc-r8a7779";
reg = <0xfffc0000 0x23c>;
};
--
2.12.2.816.g2cccc81164
^ permalink raw reply related
* [PATCH 4/9] ARM: dts: r8a7778: update PFC node name to pin-controller
From: Simon Horman @ 2017-04-26 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426100538.22060-1-horms+renesas@verge.net.au>
The device trees for Renesas SoCs use either pfc or pin-controller as the
node name for the PFC device. This patch is intended to take a step towards
unifying the node name used as pin-controller which appears to be the more
generic of the two and thus more in keeping with the DT specs.
My analysis is that this is a user-visible change to the extent that kernel
logs, and sysfs entries change from fffc0000.pfc and pfc at fffc0000 to
fffc0000.pin-controller and pin-controller at fffc0000.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7778.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index 1e93c94a9eac..8f3156c0e575 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -142,7 +142,7 @@
interrupt-controller;
};
- pfc: pfc at fffc0000 {
+ pfc: pin-controller at fffc0000 {
compatible = "renesas,pfc-r8a7778";
reg = <0xfffc0000 0x118>;
};
--
2.12.2.816.g2cccc81164
^ permalink raw reply related
* [PATCH 3/9] ARM: dts: r8a7740: update PFC node name to pin-controller
From: Simon Horman @ 2017-04-26 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426100538.22060-1-horms+renesas@verge.net.au>
The device trees for Renesas SoCs use either pfc or pin-controller as the
node name for the PFC device. This patch is intended to take a step towards
unifying the node name used as pin-controller which appears to be the more
generic of the two and thus more in keeping with the DT specs.
My analysis is that this is a user-visible change to the extent that kernel
logs, and sysfs entries change from e6050000.pfc and pfc at e6050000 to
e6050000.pin-controller and pin-controller at e6050000.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7740.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 34159a8349de..d37d22682a63 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -299,7 +299,7 @@
status = "disabled";
};
- pfc: pfc at e6050000 {
+ pfc: pin-controller at e6050000 {
compatible = "renesas,pfc-r8a7740";
reg = <0xe6050000 0x8000>,
<0xe605800c 0x20>;
--
2.12.2.816.g2cccc81164
^ permalink raw reply related
* [PATCH 2/9] ARM: dts: r8a73a4: update PFC node name to pin-controller
From: Simon Horman @ 2017-04-26 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426100538.22060-1-horms+renesas@verge.net.au>
The device trees for Renesas SoCs use either pfc or pin-controller as the
node name for the PFC device. This patch is intended to take a step towards
unifying the node name used as pin-controller which appears to be the more
generic of the two and thus more in keeping with the DT specs.
My analysis is that this is a user-visible change to the extent that kernel
logs, and sysfs entries change from e6050000.pfc and pfc at e6050000 to
e6050000.pin-controller and pin-controller at e6050000.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a73a4.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 1f5c9f6dddba..310222634570 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -219,7 +219,7 @@
power-domains = <&pd_c4>;
};
- pfc: pfc at e6050000 {
+ pfc: pin-controller at e6050000 {
compatible = "renesas,pfc-r8a73a4";
reg = <0 0xe6050000 0 0x9000>;
gpio-controller;
--
2.12.2.816.g2cccc81164
^ permalink raw reply related
* [PATCH 1/9] ARM: dts: emev2: update PFC node name to pin-controller
From: Simon Horman @ 2017-04-26 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426100538.22060-1-horms+renesas@verge.net.au>
The device trees for Renesas SoCs use either pfc or pin-controller as the
node name for the PFC device. This patch is intended to take a step towards
unifying the node name used as pin-controller which appears to be the more
generic of the two and thus more in keeping with the DT specs.
My analysis is that this is a user-visible change to the extent that kernel
logs, and sysfs entries change from e0140200.pfc and pfc at e0140200 to
e0140200.pin-controller and pin-controller at e0140200.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/emev2.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/emev2.dtsi b/arch/arm/boot/dts/emev2.dtsi
index 0124faf175c8..42ea246e71cb 100644
--- a/arch/arm/boot/dts/emev2.dtsi
+++ b/arch/arm/boot/dts/emev2.dtsi
@@ -197,7 +197,7 @@
clock-names = "sclk";
};
- pfc: pfc at e0140200 {
+ pfc: pin-controller at e0140200 {
compatible = "renesas,pfc-emev2";
reg = <0xe0140200 0x100>;
};
--
2.12.2.816.g2cccc81164
^ permalink raw reply related
* [PATCH 0/9] ARM: dts: renesas: update PFC node name to pin-controller
From: Simon Horman @ 2017-04-26 10:05 UTC (permalink / raw)
To: linux-arm-kernel
The device trees for Renesas SoCs use either pfc or pin-controller as the
node name for the PFC device. This patch is intended to take a step towards
unifying the node name used as pin-controller which appears to be the more
generic of the two and thus more in keeping with the DT specs.
My analysis is that this is a user-visible change to the extent that kernel
logs, and sysfs entries change from XXX.pfc and pfc at XXX to
XXX.pin-controller and pin-controller at XXX.
Boot tested on:
r8a73a4/ape6evm
r8a7740/armadillo800evb
r8a7778/bockw
r8a7790/lager
r8a7791/koelsch
r8a7791/porter
r8a7793/gose
sh73a9/kzm9g
Not tested on (due to lack of hw access):
evm2/kzm9d
r8a7789/marzen
Simon Horman (9):
ARM: dts: emev2: update PFC node name to pin-controller
ARM: dts: r8a73a4: update PFC node name to pin-controller
ARM: dts: r8a7740: update PFC node name to pin-controller
ARM: dts: r8a7778: update PFC node name to pin-controller
ARM: dts: r8a7779: update PFC node name to pin-controller
ARM: dts: r8a7790: update PFC node name to pin-controller
ARM: dts: r8a7791: update PFC node name to pin-controller
ARM: dts: r8a7793: update PFC node name to pin-controller
ARM: dts: sh73a0: update PFC node name to pin-controller
arch/arm/boot/dts/emev2.dtsi | 2 +-
arch/arm/boot/dts/r8a73a4.dtsi | 2 +-
arch/arm/boot/dts/r8a7740.dtsi | 2 +-
arch/arm/boot/dts/r8a7778.dtsi | 2 +-
arch/arm/boot/dts/r8a7779.dtsi | 2 +-
arch/arm/boot/dts/r8a7790.dtsi | 2 +-
arch/arm/boot/dts/r8a7791.dtsi | 2 +-
arch/arm/boot/dts/r8a7793.dtsi | 2 +-
arch/arm/boot/dts/sh73a0.dtsi | 2 +-
9 files changed, 9 insertions(+), 9 deletions(-)
--
2.12.2.816.g2cccc81164
^ permalink raw reply
* [PATCH] ARM: V7M: Set cacheid iff DminLine or IminLine is nonzero
From: Vladimir Murzin @ 2017-04-26 10:04 UTC (permalink / raw)
To: linux-arm-kernel
Cache support is optional feature in M-class cores, thus DminLine or
IminLine of Cache Type Register is zero if caches are not implemented,
but we check the whole CTR which has other features encoded there.
Let's be more precise and check for DminLine and IminLine of CTR
before we set cacheid.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/kernel/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index f4e5450..231a1d83 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -315,7 +315,7 @@ static void __init cacheid_init(void)
if (arch >= CPU_ARCH_ARMv6) {
unsigned int cachetype = read_cpuid_cachetype();
- if ((arch == CPU_ARCH_ARMv7M) && !cachetype) {
+ if ((arch == CPU_ARCH_ARMv7M) && !(cachetype & 0xf000f)) {
cacheid = 0;
} else if ((cachetype & (7 << 29)) == 4 << 29) {
/* ARMv7 register format */
--
1.9.1
^ permalink raw reply related
* [PATCH v2] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed
From: Will Deacon @ 2017-04-26 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493114272-30093-1-git-send-email-sunil.kovvuri@gmail.com>
Hi Sunil,
On Tue, Apr 25, 2017 at 03:27:52PM +0530, sunil.kovvuri at gmail.com wrote:
> From: Sunil Goutham <sgoutham@cavium.com>
>
> For software initiated address translation, when domain type is
> IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior
> i.e return the same IOVA as translated address.
>
> This patch is an extension to Will Deacon's patchset
> "Implement SMMU passthrough using the default domain".
>
> Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
> ---
>
> V2
> - As per Will's suggestion applied fix to SMMUv3 driver as well.
This follows what the AMD driver does, so:
Acked-by: Will Deacon <will.deacon@arm.com>
but I still think that having drivers/net/ethernet/cavium/thunder/nicvf_queues.c
poke around with the physical address to get at the struct pages underlying
a DMA buffer is really dodgy. Is there no way this can be avoided, perhaps
by tracking the pages some other way (although I don't understand why you're
having to mess with the page reference counts to start with)?
At least, I think you should be checking the domain type in
nicvf_iova_to_phys, which clearly expects a DMA domain if one exists at all.
Joerg: sorry, this is another one for you to pick up if possible.
Cheers,
Will
> drivers/iommu/arm-smmu-v3.c | 3 +++
> drivers/iommu/arm-smmu.c | 3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 05b4592..d412bdd 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -1714,6 +1714,9 @@ arm_smmu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova)
> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
> struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops;
>
> + if (domain->type == IOMMU_DOMAIN_IDENTITY)
> + return iova;
> +
> if (!ops)
> return 0;
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index bfab4f7..81088cd 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1459,6 +1459,9 @@ static phys_addr_t arm_smmu_iova_to_phys(struct iommu_domain *domain,
> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
> struct io_pgtable_ops *ops= smmu_domain->pgtbl_ops;
>
> + if (domain->type == IOMMU_DOMAIN_IDENTITY)
> + return iova;
> +
> if (!ops)
> return 0;
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v5 02/22] KVM: arm/arm64: Add GICV3 pending table save API documentation
From: Auger Eric @ 2017-04-26 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426084830.GB2098@work-vm>
Hi Peter, Dave,
On 26/04/2017 10:48, Dr. David Alan Gilbert wrote:
> * Peter Maydell (peter.maydell at linaro.org) wrote:
>> On 26 April 2017 at 09:26, Auger Eric <eric.auger@redhat.com> wrote:
>>> On 25/04/2017 12:43, Peter Maydell wrote:
>>>> When does the -EFAULT return happen? (if the guest points GITS_BASER<n>
>>>> etc at invalid memory, presumably?)
>>>
>>> Yes that's correct, when GICR_PENDBASER contains a bad GPA.
>>>
>>>> How does the QEMU migration code
>>>> handle this case? Failing migration because the guest has done something
>>>> silly doesn't seem too palatable, but trying to avoid that could be
>>>> more effort than an obscure corner case really merits.
>>>
>>> The kvm_device_access will cause an abort() as for other errors returned
>>> by kvm_device_ioctl().
>>
>> That's pretty nasty. Guests shouldn't be able to provoke QEMU
>> into abort()ing, ideally. We don't necessarily have to produce
>> a successful migration, but we should at least fail it cleanly.
>
> Yes, no abort()'s during migration due to guest behaviour.
> They always end up coming back around to being filed as migration
> bugs and people worry why they've got cores.
>
> Ideally log a message into stderr to say that the guest state
> is inconsistent so that when someone comes to debug it then they
> can see it's obvious.
OK I agree. I will respin the QEMU part accordingly and in that
situation I won't abort and will print a message.
Thanks
Eric
>
> Dave
>
>> thanks
>> -- PMM
> --
> Dr. David Alan Gilbert / dgilbert at redhat.com / Manchester, UK
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox