* [PATCHv3 2/5] arm: mvebu: support for SMP on 98DX3336 SoC
From: Chris Packham @ 2017-01-06 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106063602.GM17126@codeaurora.org>
On 06/01/17 19:44, Stephen Boyd wrote:
> On 01/06, Chris Packham wrote:
>> diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
>> index 46c742d3bd41..3c9ab9a008ad 100644
>> --- a/arch/arm/mach-mvebu/platsmp.c
>> +++ b/arch/arm/mach-mvebu/platsmp.c
>> @@ -182,5 +182,48 @@ const struct smp_operations armada_xp_smp_ops __initconst = {
>> #endif
>> };
>>
>> +static int mv98dx3236_boot_secondary(unsigned int cpu, struct task_struct *idle)
>> +{
>> + int ret, hw_cpu;
>> +
>> + pr_info("Booting CPU %d\n", cpu);
>
> Doesn't the core already print something when bringing up CPUs?
> This message seems redundant.
>
Copied from armada_xp_boot_secondary but that's no reason to keep it.
Will remove in v4.
>> +
>> + hw_cpu = cpu_logical_map(cpu);
>> + set_secondary_cpu_clock(hw_cpu);
>> + mv98dx3236_resume_set_cpu_boot_addr(hw_cpu,
>> + armada_xp_secondary_startup);
>> +
>> + /*
>> + * This is needed to wake up CPUs in the offline state after
>> + * using CPU hotplug.
>> + */
>> + arch_send_wakeup_ipi_mask(cpumask_of(cpu));
>> +
>> + /*
>> + * This is needed to take secondary CPUs out of reset on the
>> + * initial boot.
>> + */
>> + ret = mvebu_cpu_reset_deassert(hw_cpu);
>> + if (ret) {
>> + pr_warn("unable to boot CPU: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +struct smp_operations mv98dx3236_smp_ops __initdata = {
>
> static const __initconst?
>
Will do.
>> + .smp_init_cpus = armada_xp_smp_init_cpus,
>> + .smp_prepare_cpus = armada_xp_smp_prepare_cpus,
>> + .smp_boot_secondary = mv98dx3236_boot_secondary,
>> + .smp_secondary_init = armada_xp_secondary_init,
>> +#ifdef CONFIG_HOTPLUG_CPU
>> + .cpu_die = armada_xp_cpu_die,
>> + .cpu_kill = armada_xp_cpu_kill,
>> +#endif
>> +};
>> +
>> CPU_METHOD_OF_DECLARE(armada_xp_smp, "marvell,armada-xp-smp",
>> &armada_xp_smp_ops);
>> +CPU_METHOD_OF_DECLARE(mv98dx3236_smp, "marvell,98dx3236-smp",
>> + &mv98dx3236_smp_ops);
>> diff --git a/arch/arm/mach-mvebu/pmsu-98dx3236.c b/arch/arm/mach-mvebu/pmsu-98dx3236.c
>> new file mode 100644
>> index 000000000000..1052674dd439
>> --- /dev/null
>> +++ b/arch/arm/mach-mvebu/pmsu-98dx3236.c
>> @@ -0,0 +1,52 @@
>> +/**
>> + * CPU resume support for 98DX3236 internal CPU (a.k.a. MSYS).
>> + */
>> +
>> +#define pr_fmt(fmt) "mv98dx3236-resume: " fmt
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/init.h>
>> +#include <linux/of_address.h>
>> +#include <linux/io.h>
>> +#include "common.h"
>> +
>> +static void __iomem *mv98dx3236_resume_base;
>> +#define MV98DX3236_CPU_RESUME_CTRL_OFFSET 0x08
>> +#define MV98DX3236_CPU_RESUME_ADDR_OFFSET 0x04
>> +
>> +static const struct of_device_id of_mv98dx3236_resume_table[] = {
>> + {.compatible = "marvell,98dx3336-resume-ctrl",},
>> + { /* end of list */ },
>> +};
>> +
>> +void mv98dx3236_resume_set_cpu_boot_addr(int hw_cpu, void *boot_addr)
>> +{
>> + WARN_ON(hw_cpu != 1);
>> +
>> + writel(0, mv98dx3236_resume_base + MV98DX3236_CPU_RESUME_CTRL_OFFSET);
>> + writel(virt_to_phys(boot_addr), mv98dx3236_resume_base +
>> + MV98DX3236_CPU_RESUME_ADDR_OFFSET);
>> +}
>> +
>> +static int __init mv98dx3236_resume_init(void)
>> +{
>> + struct device_node *np;
>> + void __iomem *base;
>> +
>> + np = of_find_matching_node(NULL, of_mv98dx3236_resume_table);
>> + if (!np)
>> + return 0;
>
> Is there any reason we can't just look for this node from the
> smp_ops and map it if it isn't mapped yet? Seems simpler than a
> whole new file and initcall.
>
That's at least 2 votes for rolling it into platsmp.c. The amount of
code has been significantly reduced so I think I will do it for v4.
>> +
>> + base = of_io_request_and_map(np, 0, of_node_full_name(np));
>> + if (IS_ERR(base)) {
>> + pr_err("unable to map registers\n");
>
> Doesn't of_io_request_and_map() spit out an error on failure
> already?
>
Not that I can see. But as has been previously mentioned a CPU failing
to come online is reasonably obvious already.
>> + of_node_put(np);
>
> This could be done before the if statement and then the duplicate
> statement deleted.
>
Will do.
>> + return PTR_ERR(mv98dx3236_resume_base);
>
> Should be PTR_ERR(base)?
Yes. I decided to add the local variable at the last minute.
>
>> + }
>> +
>> + mv98dx3236_resume_base = base;
>> + of_node_put(np);
>> + return 0;
>> +}
>
^ permalink raw reply
* [PATCH v6 17/18] vfio/type1: Check MSI remapping at irq domain level
From: Bharat Bhushan @ 2017-01-06 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483643086-2883-18-git-send-email-eric.auger@redhat.com>
Hi Eric,
> -----Original Message-----
> From: Eric Auger [mailto:eric.auger at redhat.com]
> Sent: Friday, January 06, 2017 12:35 AM
> To: eric.auger at redhat.com; eric.auger.pro at gmail.com;
> christoffer.dall at linaro.org; marc.zyngier at arm.com;
> robin.murphy at arm.com; alex.williamson at redhat.com;
> will.deacon at arm.com; joro at 8bytes.org; tglx at linutronix.de;
> jason at lakedaemon.net; linux-arm-kernel at lists.infradead.org
> Cc: kvm at vger.kernel.org; drjones at redhat.com; linux-
> kernel at vger.kernel.org; pranav.sawargaonkar at gmail.com;
> iommu at lists.linux-foundation.org; punit.agrawal at arm.com; Diana Madalina
> Craciun <diana.craciun@nxp.com>; gpkulkarni at gmail.com;
> shankerd at codeaurora.org; Bharat Bhushan <bharat.bhushan@nxp.com>;
> geethasowjanya.akula at gmail.com
> Subject: [PATCH v6 17/18] vfio/type1: Check MSI remapping at irq domain
> level
>
> In case the IOMMU translates MSI transactions (typical case on ARM), we
> check MSI remapping capability at IRQ domain level. Otherwise it is checked
> at IOMMU level.
>
> At this stage the arm-smmu-(v3) still advertise the
> IOMMU_CAP_INTR_REMAP capability at IOMMU level. This will be removed
> in subsequent patches.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
>
> v6: rewrite test
> ---
> drivers/vfio/vfio_iommu_type1.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_type1.c
> b/drivers/vfio/vfio_iommu_type1.c index b473ef80..fa0b5c4 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -40,6 +40,7 @@
> #include <linux/mdev.h>
> #include <linux/notifier.h>
> #include <linux/dma-iommu.h>
> +#include <linux/irqdomain.h>
>
> #define DRIVER_VERSION "0.2"
> #define DRIVER_AUTHOR "Alex Williamson
> <alex.williamson@redhat.com>"
> @@ -1208,7 +1209,7 @@ static int vfio_iommu_type1_attach_group(void
> *iommu_data,
> struct vfio_domain *domain, *d;
> struct bus_type *bus = NULL, *mdev_bus;
> int ret;
> - bool resv_msi;
> + bool resv_msi, msi_remap;
> phys_addr_t resv_msi_base;
>
> mutex_lock(&iommu->lock);
> @@ -1284,8 +1285,10 @@ static int vfio_iommu_type1_attach_group(void
> *iommu_data,
> INIT_LIST_HEAD(&domain->group_list);
> list_add(&group->next, &domain->group_list);
>
> - if (!allow_unsafe_interrupts &&
> - !iommu_capable(bus, IOMMU_CAP_INTR_REMAP)) {
> + msi_remap = resv_msi ? irq_domain_check_msi_remap() :
There can be multiple interrupt-controller, at-least theoretically it is possible and not sure practically it exists and supported, where not all may support IRQ_REMAP. If that is the case be then should we check for IRQ-REMAP for that device-bus irq-domain?
Thanks
-Bharat
> + iommu_capable(bus,
> IOMMU_CAP_INTR_REMAP);
> +
> + if (!allow_unsafe_interrupts && !msi_remap) {
> pr_warn("%s: No interrupt remapping support. Use the
> module param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support
> on this platform\n",
> __func__);
> ret = -EPERM;
> --
> 1.9.1
^ permalink raw reply
* [PATCH v3 1/5] arm64: dts: exynos5433: TM2/E: Fix wrong information of ldo23 and ldo25
From: Krzysztof Kozlowski @ 2017-01-06 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <586F4554.6020206@samsung.com>
On Fri, Jan 06, 2017 at 04:20:52PM +0900, Chanwoo Choi wrote:
> On 2017? 01? 06? 16:05, Krzysztof Kozlowski wrote:
> > On Fri, Jan 06, 2017 at 12:59:05PM +0900, Jaechul Lee wrote:
> >> From: Chanwoo Choi <cw00.choi@samsung.com>
> >>
> >> This patch fixes the wrong information of ldo23 and ldo25 on both TM2 and TM2E.
> >
> > Please describe what is exactly wrong and how it affects the
> > system/user. This is going to the fixes so it needs a good explanation.
>
> When I posted the patch[1], I refer to the old schematic document of both TM2 and TM2E.
> [1] 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board")
>
> After checking the highest version of schematic document of both TM2 and TM2E,
> there is no difference of ldo23/ldo25 on both TM2 and TM2E.
> - ldo23 is used on TM2/TM2E, but the name/max-microvolt are wrong.
> - ldo25 isn't used on TM2/TM2E. (not connected)
>
> Because ldo23 and lod25 are not used on other device in Exynos5433 and TM2 board.
> this patch does not affect the operation to system/user.
If it does not affect anyone (including TM2/TM2E) then this do not have
to be a fix. Am I right?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/2] ARM: dts: da850: Add usb device node
From: Axel Haslam @ 2017-01-06 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0dd074af-a4ae-34fa-a404-1116b554135b@lechnology.com>
On Thu, Jan 5, 2017 at 11:49 PM, David Lechner <david@lechnology.com> wrote:
> Hi Sekhar,
>
> On 11/21/2016 10:59 AM, Axel Haslam wrote:
>>
>> Add the usb1 device node for the da850 soc.
>> This will allow boards to use the usb1 port
>> when booting through DT.
>>
>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
>> ---
>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index 1bb1f6d..fbd50d6 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -406,6 +406,14 @@
>> >;
>> status = "disabled";
>> };
>> + usb1: usb at 225000 {
>> + compatible = "ti,da830-ohci";
>> + reg = <0x225000 0x1000>;
>> + interrupts = <59>;
>> + phys = <&usb_phy 1>;
>> + phy-names = "usb-phy";
>> + status = "disabled";
>> + };
>> gpio: gpio at 226000 {
>> compatible = "ti,dm6441-gpio";
>> gpio-controller;
>>
>
>
> This patch can be pickup up now. I have just tested with next-20171015 +
> linux-davinci/master.
Yes, the regulator patches, are not actually needed for the lcdk, since
it does not have the over current pin connected to a gpio.
ill resend v2 removing the phy from the dts so that they can be both
applied.
-Axel.
^ permalink raw reply
* [PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle
From: Alexandre Belloni @ 2017-01-06 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106065947.30631-2-wenyou.yang@atmel.com>
Hi,
On 06/01/2017 at 14:59:45 +0800, Wenyou Yang wrote :
> For the SoCs such as SAMA5D2 and SAMA5D4 which have L2 cache,
> flush the L2 cache first before entering the cpu idle.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
>
> arch/arm/mach-at91/pm.c | 19 +++++++++++++++++++
> drivers/memory/atmel-sdramc.c | 1 +
> 2 files changed, 20 insertions(+)
>
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index b4332b727e9c..1a60dede1a01 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -289,6 +289,24 @@ static void at91_ddr_standby(void)
> at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
> }
>
> +static void at91_ddr_cache_standby(void)
> +{
> + u32 saved_lpr;
> +
> + flush_cache_all();
> + outer_disable();
> +
> + saved_lpr = at91_ramc_read(0, AT91_DDRSDRC_LPR);
> + at91_ramc_write(0, AT91_DDRSDRC_LPR, (saved_lpr &
> + (~AT91_DDRSDRC_LPCB)) | AT91_DDRSDRC_LPCB_SELF_REFRESH);
> +
> + cpu_do_idle();
> +
> + at91_ramc_write(0, AT91_DDRSDRC_LPR, saved_lpr);
> +
> + outer_resume();
> +}
> +
Seems good to me. Did you measure the added latency on sama5d3 if you
add the cache operations in at91_ddr_standby instead of having a new
function?
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 1/5] arm64: dts: exynos5433: TM2/E: Fix wrong information of ldo23 and ldo25
From: Chanwoo Choi @ 2017-01-06 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106085026.5pfwyxt2qipzbjpy@kozik-lap>
On 2017? 01? 06? 17:50, Krzysztof Kozlowski wrote:
> On Fri, Jan 06, 2017 at 04:20:52PM +0900, Chanwoo Choi wrote:
>> On 2017? 01? 06? 16:05, Krzysztof Kozlowski wrote:
>>> On Fri, Jan 06, 2017 at 12:59:05PM +0900, Jaechul Lee wrote:
>>>> From: Chanwoo Choi <cw00.choi@samsung.com>
>>>>
>>>> This patch fixes the wrong information of ldo23 and ldo25 on both TM2 and TM2E.
>>>
>>> Please describe what is exactly wrong and how it affects the
>>> system/user. This is going to the fixes so it needs a good explanation.
>>
>> When I posted the patch[1], I refer to the old schematic document of both TM2 and TM2E.
>> [1] 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board")
>>
>> After checking the highest version of schematic document of both TM2 and TM2E,
>> there is no difference of ldo23/ldo25 on both TM2 and TM2E.
>> - ldo23 is used on TM2/TM2E, but the name/max-microvolt are wrong.
>> - ldo25 isn't used on TM2/TM2E. (not connected)
>>
>> Because ldo23 and lod25 are not used on other device in Exynos5433 and TM2 board.
>> this patch does not affect the operation to system/user.
>
> If it does not affect anyone (including TM2/TM2E) then this do not have
> to be a fix. Am I right?
This patch does not affect the TM2/TM2E's operation
because ldo23/25 are not used on TM2/TM2E. Just fix the wrong information.
--
Best Regards,
Chanwoo Choi
S/W Center, Samsung Electronics
^ permalink raw reply
* [PATCH v6 17/18] vfio/type1: Check MSI remapping at irq domain level
From: Auger Eric @ 2017-01-06 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM5PR0401MB25454B0C8F6E610A50B299D19A630@AM5PR0401MB2545.eurprd04.prod.outlook.com>
Hi Bharat
On 06/01/2017 09:50, Bharat Bhushan wrote:
> Hi Eric,
>
>> -----Original Message-----
>> From: Eric Auger [mailto:eric.auger at redhat.com]
>> Sent: Friday, January 06, 2017 12:35 AM
>> To: eric.auger at redhat.com; eric.auger.pro at gmail.com;
>> christoffer.dall at linaro.org; marc.zyngier at arm.com;
>> robin.murphy at arm.com; alex.williamson at redhat.com;
>> will.deacon at arm.com; joro at 8bytes.org; tglx at linutronix.de;
>> jason at lakedaemon.net; linux-arm-kernel at lists.infradead.org
>> Cc: kvm at vger.kernel.org; drjones at redhat.com; linux-
>> kernel at vger.kernel.org; pranav.sawargaonkar at gmail.com;
>> iommu at lists.linux-foundation.org; punit.agrawal at arm.com; Diana Madalina
>> Craciun <diana.craciun@nxp.com>; gpkulkarni at gmail.com;
>> shankerd at codeaurora.org; Bharat Bhushan <bharat.bhushan@nxp.com>;
>> geethasowjanya.akula at gmail.com
>> Subject: [PATCH v6 17/18] vfio/type1: Check MSI remapping at irq domain
>> level
>>
>> In case the IOMMU translates MSI transactions (typical case on ARM), we
>> check MSI remapping capability at IRQ domain level. Otherwise it is checked
>> at IOMMU level.
>>
>> At this stage the arm-smmu-(v3) still advertise the
>> IOMMU_CAP_INTR_REMAP capability at IOMMU level. This will be removed
>> in subsequent patches.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>>
>> v6: rewrite test
>> ---
>> drivers/vfio/vfio_iommu_type1.c | 9 ++++++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/vfio/vfio_iommu_type1.c
>> b/drivers/vfio/vfio_iommu_type1.c index b473ef80..fa0b5c4 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -40,6 +40,7 @@
>> #include <linux/mdev.h>
>> #include <linux/notifier.h>
>> #include <linux/dma-iommu.h>
>> +#include <linux/irqdomain.h>
>>
>> #define DRIVER_VERSION "0.2"
>> #define DRIVER_AUTHOR "Alex Williamson
>> <alex.williamson@redhat.com>"
>> @@ -1208,7 +1209,7 @@ static int vfio_iommu_type1_attach_group(void
>> *iommu_data,
>> struct vfio_domain *domain, *d;
>> struct bus_type *bus = NULL, *mdev_bus;
>> int ret;
>> - bool resv_msi;
>> + bool resv_msi, msi_remap;
>> phys_addr_t resv_msi_base;
>>
>> mutex_lock(&iommu->lock);
>> @@ -1284,8 +1285,10 @@ static int vfio_iommu_type1_attach_group(void
>> *iommu_data,
>> INIT_LIST_HEAD(&domain->group_list);
>> list_add(&group->next, &domain->group_list);
>>
>> - if (!allow_unsafe_interrupts &&
>> - !iommu_capable(bus, IOMMU_CAP_INTR_REMAP)) {
>> + msi_remap = resv_msi ? irq_domain_check_msi_remap() :
>
> There can be multiple interrupt-controller, at-least theoretically it is possible and not sure practically it exists and supported, where not all may support IRQ_REMAP. If that is the case be then should we check for IRQ-REMAP for that device-bus irq-domain?
>
I mentioned in the cover letter that the approach was defensive and
rough today. As soon as we detect an MSI controller in the platform that
has no support for MSI remapping we flag the assignment as unsafe. I
think this approach was agreed on the ML. Such rough assessment was used
in the past on x86.
I am reluctant to add more complexity at that stage. This can be
improved latter I think when such platforms show up.
Best Regards
Eric
> Thanks
> -Bharat
>
>> + iommu_capable(bus,
>> IOMMU_CAP_INTR_REMAP);
>> +
>> + if (!allow_unsafe_interrupts && !msi_remap) {
>> pr_warn("%s: No interrupt remapping support. Use the
>> module param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support
>> on this platform\n",
>> __func__);
>> ret = -EPERM;
>> --
>> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v3 1/5] arm64: dts: exynos5433: TM2/E: Fix wrong information of ldo23 and ldo25
From: Krzysztof Kozlowski @ 2017-01-06 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <73639ec8-028a-56a2-0b47-3465974ec3f3@samsung.com>
On Fri, Jan 06, 2017 at 06:06:43PM +0900, Chanwoo Choi wrote:
> On 2017? 01? 06? 17:50, Krzysztof Kozlowski wrote:
> > On Fri, Jan 06, 2017 at 04:20:52PM +0900, Chanwoo Choi wrote:
> >> On 2017? 01? 06? 16:05, Krzysztof Kozlowski wrote:
> >>> On Fri, Jan 06, 2017 at 12:59:05PM +0900, Jaechul Lee wrote:
> >>>> From: Chanwoo Choi <cw00.choi@samsung.com>
> >>>>
> >>>> This patch fixes the wrong information of ldo23 and ldo25 on both TM2 and TM2E.
> >>>
> >>> Please describe what is exactly wrong and how it affects the
> >>> system/user. This is going to the fixes so it needs a good explanation.
> >>
> >> When I posted the patch[1], I refer to the old schematic document of both TM2 and TM2E.
> >> [1] 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board")
> >>
> >> After checking the highest version of schematic document of both TM2 and TM2E,
> >> there is no difference of ldo23/ldo25 on both TM2 and TM2E.
> >> - ldo23 is used on TM2/TM2E, but the name/max-microvolt are wrong.
> >> - ldo25 isn't used on TM2/TM2E. (not connected)
> >>
> >> Because ldo23 and lod25 are not used on other device in Exynos5433 and TM2 board.
> >> this patch does not affect the operation to system/user.
> >
> > If it does not affect anyone (including TM2/TM2E) then this do not have
> > to be a fix. Am I right?
>
> This patch does not affect the TM2/TM2E's operation
> because ldo23/25 are not used on TM2/TM2E. Just fix the wrong information.
Ah, okay, thanks for explanation. Please just rebase on current
next/dt64 (or for-next or just my
https://patchwork.kernel.org/patch/9500153/) so the always-off property
won't be copied.
I'll take it then for v4.11.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v7 1/5] dt-bindings: zte: add bindings document for zx2967 power domain controller
From: Baoyou Xie @ 2017-01-06 9:16 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds device tree bindings document for ZTE zx2967
family power domain controller.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
.../devicetree/bindings/soc/zte/pd-2967xx.txt | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
diff --git a/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
new file mode 100644
index 0000000..7629de1
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
@@ -0,0 +1,19 @@
+* ZTE zx2967 family Power Domains
+
+zx2967 family includes support for multiple power domains which are used
+to gate power to one or more peripherals on the processor.
+
+Required Properties:
+ - compatible: should be one of the following.
+ * zte,zx296718-pcu - for zx296718 power domain.
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - #power-domain-cells: Must be 1.
+
+Example:
+
+ pcu_domain: pcu at 117000 {
+ compatible = "zte,zx296718-pcu";
+ reg = <0x00117000 0x1000>;
+ #power-domain-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v7 2/5] MAINTAINERS: add zx2967 SoC drivers to ARM ZTE architecture
From: Baoyou Xie @ 2017-01-06 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483694164-7668-1-git-send-email-baoyou.xie@linaro.org>
Add the ZTE SoC drivers as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
By the way, this patch adds the maintainer for ARM
ZTE architecture to Baoyou Xie.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ad199da..64f04df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1975,12 +1975,16 @@ F: arch/arm/mach-pxa/include/mach/z2.h
ARM/ZTE ARCHITECTURE
M: Jun Nie <jun.nie@linaro.org>
+M: Baoyou Xie <baoyou.xie@linaro.org>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-zx/
F: drivers/clk/zte/
+F: drivers/soc/zte/
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
+F: Documentation/devicetree/bindings/soc/zte/
+F: include/dt-bindings/soc/zx*.h
ARM/ZYNQ ARCHITECTURE
M: Michal Simek <michal.simek@xilinx.com>
--
2.7.4
^ permalink raw reply related
* [PATCH v7 3/5] soc: zte: Add header for PM domains specifiers
From: Baoyou Xie @ 2017-01-06 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483694164-7668-1-git-send-email-baoyou.xie@linaro.org>
This patch adds header with values used for ZTE 2967
SoC's power domain driver.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
include/dt-bindings/soc/zte,pm_domains.h | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 include/dt-bindings/soc/zte,pm_domains.h
diff --git a/include/dt-bindings/soc/zte,pm_domains.h b/include/dt-bindings/soc/zte,pm_domains.h
new file mode 100644
index 0000000..a0b4019
--- /dev/null
+++ b/include/dt-bindings/soc/zte,pm_domains.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#ifndef _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
+#define _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
+
+#define DM_ZX296718_SAPPU 0
+#define DM_ZX296718_VDE 1 /* g1v6 */
+#define DM_ZX296718_VCE 2 /* h1v6 */
+#define DM_ZX296718_HDE 3 /* g2v2 */
+#define DM_ZX296718_VIU 4
+#define DM_ZX296718_USB20 5
+#define DM_ZX296718_USB21 6
+#define DM_ZX296718_USB30 7
+#define DM_ZX296718_HSIC 8
+#define DM_ZX296718_GMAC 9
+#define DM_ZX296718_TS 10
+#define DM_ZX296718_VOU 11
+
+#endif /* _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v7 4/5] soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family
From: Baoyou Xie @ 2017-01-06 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483694164-7668-1-git-send-email-baoyou.xie@linaro.org>
The ARMv8 zx2967 family (296718, 296716 etc) uses different value
for controlling the power domain on/off registers, Choose the
value depending on the compatible.
Multiple domains are prepared for the family, this patch prepares
the common functions.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/zte/Kconfig | 13 ++++
drivers/soc/zte/Makefile | 4 +
drivers/soc/zte/zx2967_pm_domains.c | 143 ++++++++++++++++++++++++++++++++++++
drivers/soc/zte/zx2967_pm_domains.h | 44 +++++++++++
6 files changed, 206 insertions(+)
create mode 100644 drivers/soc/zte/Kconfig
create mode 100644 drivers/soc/zte/Makefile
create mode 100644 drivers/soc/zte/zx2967_pm_domains.c
create mode 100644 drivers/soc/zte/zx2967_pm_domains.h
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index f31bceb..f09023f 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -11,5 +11,6 @@ source "drivers/soc/tegra/Kconfig"
source "drivers/soc/ti/Kconfig"
source "drivers/soc/ux500/Kconfig"
source "drivers/soc/versatile/Kconfig"
+source "drivers/soc/zte/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 50c23d0..05eae52 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_SOC_TI) += ti/
obj-$(CONFIG_ARCH_U8500) += ux500/
obj-$(CONFIG_PLAT_VERSATILE) += versatile/
+obj-$(CONFIG_ARCH_ZX) += zte/
diff --git a/drivers/soc/zte/Kconfig b/drivers/soc/zte/Kconfig
new file mode 100644
index 0000000..20bde38
--- /dev/null
+++ b/drivers/soc/zte/Kconfig
@@ -0,0 +1,13 @@
+#
+# ZTE SoC drivers
+#
+menuconfig SOC_ZTE
+ bool "ZTE SoC driver support"
+
+if SOC_ZTE
+
+config ZX2967_PM_DOMAINS
+ bool "ZX2967 PM domains"
+ depends on PM_GENERIC_DOMAINS
+
+endif
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
new file mode 100644
index 0000000..8a37f2f
--- /dev/null
+++ b/drivers/soc/zte/Makefile
@@ -0,0 +1,4 @@
+#
+# ZTE SOC drivers
+#
+obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
diff --git a/drivers/soc/zte/zx2967_pm_domains.c b/drivers/soc/zte/zx2967_pm_domains.c
new file mode 100644
index 0000000..61c8d84
--- /dev/null
+++ b/drivers/soc/zte/zx2967_pm_domains.c
@@ -0,0 +1,143 @@
+/*
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of.h>
+
+#include "zx2967_pm_domains.h"
+
+#define PCU_DM_CLKEN(zpd) ((zpd)->reg_offset[REG_CLKEN])
+#define PCU_DM_ISOEN(zpd) ((zpd)->reg_offset[REG_ISOEN])
+#define PCU_DM_RSTEN(zpd) ((zpd)->reg_offset[REG_RSTEN])
+#define PCU_DM_PWREN(zpd) ((zpd)->reg_offset[REG_PWREN])
+#define PCU_DM_ACK_SYNC(zpd) ((zpd)->reg_offset[REG_ACK_SYNC])
+
+static void __iomem *pcubase;
+
+static int zx2967_power_on(struct generic_pm_domain *domain)
+{
+ struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ if (zpd->polarity == PWREN)
+ val |= BIT(zpd->bit);
+ else
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
+
+ do {
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
+ & BIT(zpd->bit);
+ } while (--loop && !val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
+ udelay(5);
+
+ pr_debug("poweron %s\n", domain->name);
+
+ return 0;
+}
+
+static int zx2967_power_off(struct generic_pm_domain *domain)
+{
+ struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ if (zpd->polarity == PWREN)
+ val &= ~BIT(zpd->bit);
+ else
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
+
+ do {
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
+ & BIT(zpd->bit);
+ } while (--loop && val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ pr_debug("poweroff %s\n", domain->name);
+
+ return 0;
+}
+
+int zx2967_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num)
+{
+ struct genpd_onecell_data *genpd_data;
+ struct resource *res;
+ int i;
+
+ genpd_data = devm_kzalloc(&pdev->dev, sizeof(*genpd_data), GFP_KERNEL);
+ if (!genpd_data)
+ return -ENOMEM;
+
+ genpd_data->domains = zx_pm_domains;
+ genpd_data->num_domains = domain_num;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ pcubase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(pcubase)) {
+ dev_err(&pdev->dev, "ioremap fail.\n");
+ return PTR_ERR(pcubase);
+ }
+
+ for (i = 0; i < domain_num; ++i) {
+ zx_pm_domains[i]->power_on = zx2967_power_on;
+ zx_pm_domains[i]->power_off = zx2967_power_off;
+
+ pm_genpd_init(zx_pm_domains[i], NULL, false);
+ }
+
+ of_genpd_add_provider_onecell(pdev->dev.of_node, genpd_data);
+ dev_info(&pdev->dev, "powerdomain init ok\n");
+ return 0;
+}
diff --git a/drivers/soc/zte/zx2967_pm_domains.h b/drivers/soc/zte/zx2967_pm_domains.h
new file mode 100644
index 0000000..cb46595
--- /dev/null
+++ b/drivers/soc/zte/zx2967_pm_domains.h
@@ -0,0 +1,44 @@
+/*
+ * Header for ZTE's Power Domain Driver support
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#ifndef __ZTE_ZX2967_PM_DOMAIN_H
+#define __ZTE_ZX2967_PM_DOMAIN_H
+
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+
+enum {
+ REG_CLKEN,
+ REG_ISOEN,
+ REG_RSTEN,
+ REG_PWREN,
+ REG_PWRDN,
+ REG_ACK_SYNC,
+
+ /* The size of the array - must be last */
+ REG_ARRAY_SIZE,
+};
+
+enum zx2967_power_polarity {
+ PWREN,
+ PWRDN,
+};
+
+struct zx2967_pm_domain {
+ struct generic_pm_domain dm;
+ const u16 bit;
+ const enum zx2967_power_polarity polarity;
+ const u16 *reg_offset;
+};
+
+int zx2967_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num);
+
+#endif /* __ZTE_ZX2967_PM_DOMAIN_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v7 5/5] soc: zte: pm_domains: Add support for zx296718
From: Baoyou Xie @ 2017-01-06 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483694164-7668-1-git-send-email-baoyou.xie@linaro.org>
This patch introduces the power domain driver of zx296718
which belongs to zte's zx2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: Jun Nie <jun.nie@linaro.org>
---
drivers/soc/zte/Makefile | 1 +
drivers/soc/zte/zx296718_pm_domains.c | 182 ++++++++++++++++++++++++++++++++++
2 files changed, 183 insertions(+)
create mode 100644 drivers/soc/zte/zx296718_pm_domains.c
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
index 8a37f2f..96b7cd4 100644
--- a/drivers/soc/zte/Makefile
+++ b/drivers/soc/zte/Makefile
@@ -2,3 +2,4 @@
# ZTE SOC drivers
#
obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
+obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx296718_pm_domains.o
diff --git a/drivers/soc/zte/zx296718_pm_domains.c b/drivers/soc/zte/zx296718_pm_domains.c
new file mode 100644
index 0000000..5ed924f
--- /dev/null
+++ b/drivers/soc/zte/zx296718_pm_domains.c
@@ -0,0 +1,182 @@
+/*
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include <dt-bindings/soc/zte,pm_domains.h>
+#include "zx2967_pm_domains.h"
+
+static u16 zx296718_offsets[REG_ARRAY_SIZE] = {
+ [REG_CLKEN] = 0x18,
+ [REG_ISOEN] = 0x1c,
+ [REG_RSTEN] = 0x20,
+ [REG_PWREN] = 0x24,
+ [REG_ACK_SYNC] = 0x28,
+};
+
+enum {
+ PCU_DM_VOU = 0,
+ PCU_DM_SAPPU,
+ PCU_DM_VDE,
+ PCU_DM_VCE,
+ PCU_DM_HDE,
+ PCU_DM_VIU,
+ PCU_DM_USB20,
+ PCU_DM_USB21,
+ PCU_DM_USB30,
+ PCU_DM_HSIC,
+ PCU_DM_GMAC,
+ PCU_DM_TS,
+};
+
+static struct zx2967_pm_domain vou_domain = {
+ .dm = {
+ .name = "vou_domain",
+ },
+ .bit = PCU_DM_VOU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain sappu_domain = {
+ .dm = {
+ .name = "sappu_domain",
+ },
+ .bit = PCU_DM_SAPPU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain vde_domain = {
+ .dm = {
+ .name = "vde_domain",
+ },
+ .bit = PCU_DM_VDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain vce_domain = {
+ .dm = {
+ .name = "vce_domain",
+ },
+ .bit = PCU_DM_VCE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain hde_domain = {
+ .dm = {
+ .name = "hde_domain",
+ },
+ .bit = PCU_DM_HDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain viu_domain = {
+ .dm = {
+ .name = "viu_domain",
+ },
+ .bit = PCU_DM_VIU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain usb20_domain = {
+ .dm = {
+ .name = "usb20_domain",
+ },
+ .bit = PCU_DM_USB20,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain usb21_domain = {
+ .dm = {
+ .name = "usb21_domain",
+ },
+ .bit = PCU_DM_USB21,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain usb30_domain = {
+ .dm = {
+ .name = "usb30_domain",
+ },
+ .bit = PCU_DM_USB30,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain hsic_domain = {
+ .dm = {
+ .name = "hsic_domain",
+ },
+ .bit = PCU_DM_HSIC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain gmac_domain = {
+ .dm = {
+ .name = "gmac_domain",
+ },
+ .bit = PCU_DM_GMAC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain ts_domain = {
+ .dm = {
+ .name = "ts_domain",
+ },
+ .bit = PCU_DM_TS,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct generic_pm_domain *zx296718_pm_domains[] = {
+ [DM_ZX296718_VOU] = &vou_domain.dm,
+ [DM_ZX296718_SAPPU] = &sappu_domain.dm,
+ [DM_ZX296718_VDE] = &vde_domain.dm,
+ [DM_ZX296718_VCE] = &vce_domain.dm,
+ [DM_ZX296718_HDE] = &hde_domain.dm,
+ [DM_ZX296718_VIU] = &viu_domain.dm,
+ [DM_ZX296718_USB20] = &usb20_domain.dm,
+ [DM_ZX296718_USB21] = &usb21_domain.dm,
+ [DM_ZX296718_USB30] = &usb30_domain.dm,
+ [DM_ZX296718_HSIC] = &hsic_domain.dm,
+ [DM_ZX296718_GMAC] = &gmac_domain.dm,
+ [DM_ZX296718_TS] = &ts_domain.dm,
+};
+
+static int zx296718_pd_probe(struct platform_device *pdev)
+{
+ return zx2967_pd_probe(pdev,
+ zx296718_pm_domains,
+ ARRAY_SIZE(zx296718_pm_domains));
+}
+
+static const struct of_device_id zx296718_pm_domain_matches[] = {
+ { .compatible = "zte,zx296718-pcu", },
+ { },
+};
+
+static struct platform_driver zx296718_pd_driver = {
+ .driver = {
+ .name = "zx296718-powerdomain",
+ .owner = THIS_MODULE,
+ .of_match_table = zx296718_pm_domain_matches,
+ },
+ .probe = zx296718_pd_probe,
+};
+
+static int __init zx296718_pd_init(void)
+{
+ return platform_driver_register(&zx296718_pd_driver);
+}
+subsys_initcall(zx296718_pd_init);
--
2.7.4
^ permalink raw reply related
* [PATCH v6 17/18] vfio/type1: Check MSI remapping at irq domain level
From: Marc Zyngier @ 2017-01-06 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <af612e18-ca0b-b855-e198-d4c706f2febc@redhat.com>
On 06/01/17 09:08, Auger Eric wrote:
> Hi Bharat
>
> On 06/01/2017 09:50, Bharat Bhushan wrote:
>> Hi Eric,
>>
>>> -----Original Message-----
>>> From: Eric Auger [mailto:eric.auger at redhat.com]
>>> Sent: Friday, January 06, 2017 12:35 AM
>>> To: eric.auger at redhat.com; eric.auger.pro at gmail.com;
>>> christoffer.dall at linaro.org; marc.zyngier at arm.com;
>>> robin.murphy at arm.com; alex.williamson at redhat.com;
>>> will.deacon at arm.com; joro at 8bytes.org; tglx at linutronix.de;
>>> jason at lakedaemon.net; linux-arm-kernel at lists.infradead.org
>>> Cc: kvm at vger.kernel.org; drjones at redhat.com; linux-
>>> kernel at vger.kernel.org; pranav.sawargaonkar at gmail.com;
>>> iommu at lists.linux-foundation.org; punit.agrawal at arm.com; Diana Madalina
>>> Craciun <diana.craciun@nxp.com>; gpkulkarni at gmail.com;
>>> shankerd at codeaurora.org; Bharat Bhushan <bharat.bhushan@nxp.com>;
>>> geethasowjanya.akula at gmail.com
>>> Subject: [PATCH v6 17/18] vfio/type1: Check MSI remapping at irq domain
>>> level
>>>
>>> In case the IOMMU translates MSI transactions (typical case on ARM), we
>>> check MSI remapping capability at IRQ domain level. Otherwise it is checked
>>> at IOMMU level.
>>>
>>> At this stage the arm-smmu-(v3) still advertise the
>>> IOMMU_CAP_INTR_REMAP capability at IOMMU level. This will be removed
>>> in subsequent patches.
>>>
>>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>>
>>> ---
>>>
>>> v6: rewrite test
>>> ---
>>> drivers/vfio/vfio_iommu_type1.c | 9 ++++++---
>>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/vfio/vfio_iommu_type1.c
>>> b/drivers/vfio/vfio_iommu_type1.c index b473ef80..fa0b5c4 100644
>>> --- a/drivers/vfio/vfio_iommu_type1.c
>>> +++ b/drivers/vfio/vfio_iommu_type1.c
>>> @@ -40,6 +40,7 @@
>>> #include <linux/mdev.h>
>>> #include <linux/notifier.h>
>>> #include <linux/dma-iommu.h>
>>> +#include <linux/irqdomain.h>
>>>
>>> #define DRIVER_VERSION "0.2"
>>> #define DRIVER_AUTHOR "Alex Williamson
>>> <alex.williamson@redhat.com>"
>>> @@ -1208,7 +1209,7 @@ static int vfio_iommu_type1_attach_group(void
>>> *iommu_data,
>>> struct vfio_domain *domain, *d;
>>> struct bus_type *bus = NULL, *mdev_bus;
>>> int ret;
>>> - bool resv_msi;
>>> + bool resv_msi, msi_remap;
>>> phys_addr_t resv_msi_base;
>>>
>>> mutex_lock(&iommu->lock);
>>> @@ -1284,8 +1285,10 @@ static int vfio_iommu_type1_attach_group(void
>>> *iommu_data,
>>> INIT_LIST_HEAD(&domain->group_list);
>>> list_add(&group->next, &domain->group_list);
>>>
>>> - if (!allow_unsafe_interrupts &&
>>> - !iommu_capable(bus, IOMMU_CAP_INTR_REMAP)) {
>>> + msi_remap = resv_msi ? irq_domain_check_msi_remap() :
>>
>> There can be multiple interrupt-controller, at-least theoretically it is possible and not sure practically it exists and supported, where not all may support IRQ_REMAP. If that is the case be then should we check for IRQ-REMAP for that device-bus irq-domain?
>>
> I mentioned in the cover letter that the approach was defensive and
> rough today. As soon as we detect an MSI controller in the platform that
> has no support for MSI remapping we flag the assignment as unsafe. I
> think this approach was agreed on the ML. Such rough assessment was used
> in the past on x86.
>
> I am reluctant to add more complexity at that stage. This can be
> improved latter I think when such platforms show up.
I don't think this is worth it. If the system is so broken that the
designer cannot make up their mind about device isolation, too bad.
People will either disable the non-isolating MSI controller altogether,
or force the unsafe flag.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v3 2/5] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Andi Shyti @ 2017-01-06 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106083729.4odfu42knjxxudve@kozik-lap>
Hi Krzysztof,
> > > > .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 1118 +++++++++++++++++++
> > > > arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1153 +-------------------
> > >
> > > Like talking to a wall. Without any feedback. If my instructions were
> > > wrong (and it is not possible to detect rename) then please say it (you
> > > can add personal comments after separator ---).
> >
> > no Krzysztof, I'm sorry, but this patch has been formatted with
> > the diff algorithm *you* asked, -B50% both version 2 (where you
> > didn't comment) and version 3. If you still don't like it, please
> > don't blame me, blame the algorithm.
>
> If you wrote it in cover letter or after '---' I wouldn't complain
> because I would know that my feedback was ignored. But here it is like
> black hole - I do not know whether I was ignored or it was not working.
In the cover letter is written:
"- patch 3 diff has been generated with -B50%"
in "Changes in v2:". In v3 patch 3 has become patch 2.
> > Now we can stay here at trying random diff algorithms (as they
> > give more or less the same result) or you tell me which exact
> > algorithm you want me to use. Besides, for me it's clear,
> > tm2-common is all new, while in tm2 you have on one side the '-'
> > (if it applies nothing has changed) on the bottom the '+'.
>
> Maybe that depends on the git?
> $ git --version
> git version 2.9.3
> $ git format-patch -2 -B50%
> ...
> 21 ...ynos5433-tm2.dts => exynos5433-tm2-common.dtsi} | 24 +-
> 22 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1153 +-------------------
> 23 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 22 +-
> 24 3 files changed, 56 insertions(+), 1143 deletions(-)
> 25 copy arch/arm64/boot/dts/exynos/{exynos5433-tm2.dts => exynos5433-tm2-common.dtsi} (98%)
> 26 rewrite arch/arm64/boot/dts/exynos/exynos5433-tm2.dts (98%)
I guess you're right, this has been generated from Jaechul's PC
who perhaps has a different version. I have version 2.11.0 and I
have same output as you.
I will send the patch generated from my PC as reply to your mail.
Andi
^ permalink raw reply
* [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Teresa Remmet @ 2017-01-06 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105175619.GA56877@google.com>
Hello Brian,
Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:
> On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
> >
> > * Tony Lindgren <tony@atomide.com> [170105 07:37]:
> > >
> > > * Teresa Remmet <t.remmet@phytec.de> [170105 06:57]:
> > > >
> > > > To improve NAND safety we updated the partition layout.
> > > > Added barebox backup partition and removed kernel and oftree
> > > > partition. They are kept in ubi now.
> > > What about the users with earlier partition tables?
> > >
> > > Please read about "flag day" changes, typically they are not
> > > acceptable.
> > Adding Brian and Adam to Cc. Can you guys come up with some
> > solution on this?
> I don't have much context for this thread, and no I don't plan to
> solve
> your problems for you. But I can provide tips!
>
> >
> > I'm suggesting we leave the kernel nodes empty and let u-boot
> > populate them, so maybe you guys can discuss this on the related
> > lists.
> That's an option. I've worked with platforms that did something like
> this, and that's really one of the only ways you can handle putting
> partition information in the device tree. You're really hamstringing
> yourself when you put all the partition information in the device
> tree.
> And it's just dumb once that gets codified in the kernel source tree.
>
In our case the bootloader does pass the partition table to the kernel.
So it gets overwritten anyway. This was just more for backup,?
if someone uses a different bootloader. But I'm fine with removing the
nand partition table completely from the kernel device tree.
Same with the SPI nor partition table.
I will send patches for this.
Regards,
Teresa
> The best solution would be to try to migrate away from static device
> tree representations of partition info entirely. UBI volumes are best
> where possible. If not, then some other kind of on-flash data
> structures
> (along the lines of a GPT) with a corresponding MTD partition parser
> is
> an OK alternative. Unfortunately, there isn't any good standard
> format
> for this on MTD, so it's typically all custom -- and so people use
> the
> easiest approach: device tree. And it's even more difficult with
> NAND,
> which has reliability problems, especially with static data (e.g.,
> read
> disturb).
>
> Anyway, the parser solution is helpful only if one can properly fix
> the
> "flag day" first. And it requires a little bit more work to be
> generally
> useful; I posted some work for this over a year ago, but bikeshedding
> brought it down.
>
> >
> > The rest of the series looks fine to me so applying it into
> > omap-for-v4.11/dt.
> Brian
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 17/18] vfio/type1: Check MSI remapping at irq domain level
From: Bharat Bhushan @ 2017-01-06 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <845d7167-6734-03c9-4df6-2f82f1627dbc@arm.com>
> -----Original Message-----
> From: Marc Zyngier [mailto:marc.zyngier at arm.com]
> Sent: Friday, January 06, 2017 2:50 PM
> To: Auger Eric <eric.auger@redhat.com>; Bharat Bhushan
> <bharat.bhushan@nxp.com>; eric.auger.pro at gmail.com;
> christoffer.dall at linaro.org; robin.murphy at arm.com;
> alex.williamson at redhat.com; will.deacon at arm.com; joro at 8bytes.org;
> tglx at linutronix.de; jason at lakedaemon.net; linux-arm-
> kernel at lists.infradead.org
> Cc: kvm at vger.kernel.org; drjones at redhat.com; linux-
> kernel at vger.kernel.org; pranav.sawargaonkar at gmail.com;
> iommu at lists.linux-foundation.org; punit.agrawal at arm.com; Diana Madalina
> Craciun <diana.craciun@nxp.com>; gpkulkarni at gmail.com;
> shankerd at codeaurora.org; geethasowjanya.akula at gmail.com
> Subject: Re: [PATCH v6 17/18] vfio/type1: Check MSI remapping at irq
> domain level
>
> On 06/01/17 09:08, Auger Eric wrote:
> > Hi Bharat
> >
> > On 06/01/2017 09:50, Bharat Bhushan wrote:
> >> Hi Eric,
> >>
> >>> -----Original Message-----
> >>> From: Eric Auger [mailto:eric.auger at redhat.com]
> >>> Sent: Friday, January 06, 2017 12:35 AM
> >>> To: eric.auger at redhat.com; eric.auger.pro at gmail.com;
> >>> christoffer.dall at linaro.org; marc.zyngier at arm.com;
> >>> robin.murphy at arm.com; alex.williamson at redhat.com;
> >>> will.deacon at arm.com; joro at 8bytes.org; tglx at linutronix.de;
> >>> jason at lakedaemon.net; linux-arm-kernel at lists.infradead.org
> >>> Cc: kvm at vger.kernel.org; drjones at redhat.com; linux-
> >>> kernel at vger.kernel.org; pranav.sawargaonkar at gmail.com;
> >>> iommu at lists.linux-foundation.org; punit.agrawal at arm.com; Diana
> >>> Madalina Craciun <diana.craciun@nxp.com>; gpkulkarni at gmail.com;
> >>> shankerd at codeaurora.org; Bharat Bhushan
> <bharat.bhushan@nxp.com>;
> >>> geethasowjanya.akula at gmail.com
> >>> Subject: [PATCH v6 17/18] vfio/type1: Check MSI remapping at irq
> >>> domain level
> >>>
> >>> In case the IOMMU translates MSI transactions (typical case on ARM),
> >>> we check MSI remapping capability at IRQ domain level. Otherwise it
> >>> is checked at IOMMU level.
> >>>
> >>> At this stage the arm-smmu-(v3) still advertise the
> >>> IOMMU_CAP_INTR_REMAP capability at IOMMU level. This will be
> removed
> >>> in subsequent patches.
> >>>
> >>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> >>>
> >>> ---
> >>>
> >>> v6: rewrite test
> >>> ---
> >>> drivers/vfio/vfio_iommu_type1.c | 9 ++++++---
> >>> 1 file changed, 6 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/vfio/vfio_iommu_type1.c
> >>> b/drivers/vfio/vfio_iommu_type1.c index b473ef80..fa0b5c4 100644
> >>> --- a/drivers/vfio/vfio_iommu_type1.c
> >>> +++ b/drivers/vfio/vfio_iommu_type1.c
> >>> @@ -40,6 +40,7 @@
> >>> #include <linux/mdev.h>
> >>> #include <linux/notifier.h>
> >>> #include <linux/dma-iommu.h>
> >>> +#include <linux/irqdomain.h>
> >>>
> >>> #define DRIVER_VERSION "0.2"
> >>> #define DRIVER_AUTHOR "Alex Williamson
> >>> <alex.williamson@redhat.com>"
> >>> @@ -1208,7 +1209,7 @@ static int
> vfio_iommu_type1_attach_group(void
> >>> *iommu_data,
> >>> struct vfio_domain *domain, *d;
> >>> struct bus_type *bus = NULL, *mdev_bus;
> >>> int ret;
> >>> - bool resv_msi;
> >>> + bool resv_msi, msi_remap;
> >>> phys_addr_t resv_msi_base;
> >>>
> >>> mutex_lock(&iommu->lock);
> >>> @@ -1284,8 +1285,10 @@ static int
> vfio_iommu_type1_attach_group(void
> >>> *iommu_data,
> >>> INIT_LIST_HEAD(&domain->group_list);
> >>> list_add(&group->next, &domain->group_list);
> >>>
> >>> - if (!allow_unsafe_interrupts &&
> >>> - !iommu_capable(bus, IOMMU_CAP_INTR_REMAP)) {
> >>> + msi_remap = resv_msi ? irq_domain_check_msi_remap() :
> >>
> >> There can be multiple interrupt-controller, at-least theoretically it is
> possible and not sure practically it exists and supported, where not all may
> support IRQ_REMAP. If that is the case be then should we check for IRQ-
> REMAP for that device-bus irq-domain?
> >>
> > I mentioned in the cover letter that the approach was defensive and
> > rough today. As soon as we detect an MSI controller in the platform
> > that has no support for MSI remapping we flag the assignment as
> > unsafe. I think this approach was agreed on the ML. Such rough
> > assessment was used in the past on x86.
> >
> > I am reluctant to add more complexity at that stage. This can be
> > improved latter I think when such platforms show up.
>
> I don't think this is worth it. If the system is so broken that the designer
> cannot make up their mind about device isolation, too bad.
> People will either disable the non-isolating MSI controller altogether, or force
> the unsafe flag.
Understand, just want to be sure that this is a known limitation. It will be good if we have some comment around this function.
Thanks
-Bharat
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 0/2] ARM: davinvi: da850 add ohci DT nodes
From: Axel Haslam @ 2017-01-06 9:40 UTC (permalink / raw)
To: linux-arm-kernel
This adds the DT node for the ohci controller and
enables it for the omapl138-lckd platform.
Changes v1 -> v2
* remove usb-phy node as it was added in merged patches for usb0 (musb)
* remove dependency on regulator patches as these are not needed for
the lcdk board.
* remove dependency on merged ohci patches.
Axel Haslam (2):
ARM: dts: da850: Add usb device node
ARM: dts: da850-lcdk: Enable ohci for omapl138 lcdk
arch/arm/boot/dts/da850-lcdk.dts | 4 ++++
arch/arm/boot/dts/da850.dtsi | 8 ++++++++
2 files changed, 12 insertions(+)
--
2.9.3
^ permalink raw reply
* [PATCH v2 1/2] ARM: dts: da850: Add usb device node
From: Axel Haslam @ 2017-01-06 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106094054.27767-1-ahaslam@baylibre.com>
Add the usb1 device node for the da850 soc.
This will allow boards to use the usb1 port
when booting through DT.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 6205917..9f8ac8f 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -419,6 +419,14 @@
>;
status = "disabled";
};
+ usb1: usb at 225000 {
+ compatible = "ti,da830-ohci";
+ reg = <0x225000 0x1000>;
+ interrupts = <59>;
+ phys = <&usb_phy 1>;
+ phy-names = "usb-phy";
+ status = "disabled";
+ };
gpio: gpio at 226000 {
compatible = "ti,dm6441-gpio";
gpio-controller;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: da850-lcdk: Enable ohci for omapl138 lcdk
From: Axel Haslam @ 2017-01-06 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106094054.27767-1-ahaslam@baylibre.com>
Enable the usb1 controller (ohci) and phy for the lcdk board
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 03f9bfd..94f6ea9 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -166,6 +166,10 @@
status = "okay";
};
+&usb1 {
+ status = "okay";
+};
+
&aemif {
pinctrl-names = "default";
pinctrl-0 = <&nand_pins>;
--
2.9.3
^ permalink raw reply related
* [PATCH 0/3] mtd: nand: sunxi: Perfs improvements
From: Boris Brezillon @ 2017-01-06 9:42 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
These 3 patches aims at improving the sunxi NAND driver perfs and
avoiding busy waits on long operations to improve system reactivity.
Regards,
Boris
Boris Brezillon (3):
mtd: nand: sunxi: Fix the non-polling case in sunxi_nfc_wait_events()
mtd: nand: sunxi: Stop using polling mode when waiting for long
operations
mtd: nand: sunxi: Improve sunxi_nfc_cmd_ctrl()
drivers/mtd/nand/sunxi_nand.c | 36 ++++++++++++++++++++++++++----------
1 file changed, 26 insertions(+), 10 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] mtd: nand: sunxi: Fix the non-polling case in sunxi_nfc_wait_events()
From: Boris Brezillon @ 2017-01-06 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483695727-17415-1-git-send-email-boris.brezillon@free-electrons.com>
wait_for_completion_timeout() returns 0 if a timeout occurred, 1
otherwise. Fix the sunxi_nfc_wait_events() accordingly.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
drivers/mtd/nand/sunxi_nand.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index e40482a65de6..ba78e13a3570 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -321,6 +321,10 @@ static int sunxi_nfc_wait_events(struct sunxi_nfc *nfc, u32 events,
ret = wait_for_completion_timeout(&nfc->complete,
msecs_to_jiffies(timeout_ms));
+ if (!ret)
+ ret = -ETIMEDOUT;
+ else
+ ret = 0;
writel(0, nfc->regs + NFC_REG_INT);
} else {
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] mtd: nand: sunxi: Stop using polling mode when waiting for long operations
From: Boris Brezillon @ 2017-01-06 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483695727-17415-1-git-send-email-boris.brezillon@free-electrons.com>
Some operations, like read/write an entire page of data with the ECC
engine enabled, are known to take a lot of time. Use the interrupt-based
waiting mode in these situation.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
drivers/mtd/nand/sunxi_nand.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index ba78e13a3570..76449f79d4c5 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -522,6 +522,8 @@ static void sunxi_nfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
u32 tmp;
while (len > offs) {
+ bool poll = false;
+
cnt = min(len - offs, NFC_SRAM_SIZE);
ret = sunxi_nfc_wait_cmd_fifo_empty(nfc);
@@ -532,7 +534,11 @@ static void sunxi_nfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
tmp = NFC_DATA_TRANS | NFC_DATA_SWAP_METHOD;
writel(tmp, nfc->regs + NFC_REG_CMD);
- ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, true, 0);
+ /* Arbitrary limit for polling mode */
+ if (cnt < 64)
+ poll = true;
+
+ ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, poll, 0);
if (ret)
break;
@@ -555,6 +561,8 @@ static void sunxi_nfc_write_buf(struct mtd_info *mtd, const uint8_t *buf,
u32 tmp;
while (len > offs) {
+ bool poll = false;
+
cnt = min(len - offs, NFC_SRAM_SIZE);
ret = sunxi_nfc_wait_cmd_fifo_empty(nfc);
@@ -567,7 +575,11 @@ static void sunxi_nfc_write_buf(struct mtd_info *mtd, const uint8_t *buf,
NFC_ACCESS_DIR;
writel(tmp, nfc->regs + NFC_REG_CMD);
- ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, true, 0);
+ /* Arbitrary limit for polling mode */
+ if (cnt < 64)
+ poll = true;
+
+ ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, poll, 0);
if (ret)
break;
@@ -961,7 +973,7 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
writel(NFC_DATA_TRANS | NFC_DATA_SWAP_METHOD | NFC_ECC_OP,
nfc->regs + NFC_REG_CMD);
- ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, true, 0);
+ ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, false, 0);
sunxi_nfc_randomizer_disable(mtd);
if (ret)
return ret;
@@ -1073,7 +1085,7 @@ static int sunxi_nfc_hw_ecc_read_chunks_dma(struct mtd_info *mtd, uint8_t *buf,
writel(NFC_PAGE_OP | NFC_DATA_SWAP_METHOD | NFC_DATA_TRANS,
nfc->regs + NFC_REG_CMD);
- ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, true, 0);
+ ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, false, 0);
if (ret)
dmaengine_terminate_all(nfc->dmac);
@@ -1193,7 +1205,7 @@ static int sunxi_nfc_hw_ecc_write_chunk(struct mtd_info *mtd,
NFC_ACCESS_DIR | NFC_ECC_OP,
nfc->regs + NFC_REG_CMD);
- ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, true, 0);
+ ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, false, 0);
sunxi_nfc_randomizer_disable(mtd);
if (ret)
return ret;
@@ -1432,7 +1444,7 @@ static int sunxi_nfc_hw_ecc_write_page_dma(struct mtd_info *mtd,
NFC_DATA_TRANS | NFC_ACCESS_DIR,
nfc->regs + NFC_REG_CMD);
- ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, true, 0);
+ ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, false, 0);
if (ret)
dmaengine_terminate_all(nfc->dmac);
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] mtd: nand: sunxi: Improve sunxi_nfc_cmd_ctrl()
From: Boris Brezillon @ 2017-01-06 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483695727-17415-1-git-send-email-boris.brezillon@free-electrons.com>
We only need to call sunxi_nfc_wait_cmd_fifo_empty() if we want to send
a new command. Move the sunxi_nfc_wait_cmd_fifo_empty() call to right
place to avoid extra register reads.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
drivers/mtd/nand/sunxi_nand.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 76449f79d4c5..0eeeb8b889ea 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -604,10 +604,6 @@ static void sunxi_nfc_cmd_ctrl(struct mtd_info *mtd, int dat,
struct sunxi_nfc *nfc = to_sunxi_nfc(sunxi_nand->nand.controller);
int ret;
- ret = sunxi_nfc_wait_cmd_fifo_empty(nfc);
- if (ret)
- return;
-
if (dat == NAND_CMD_NONE && (ctrl & NAND_NCE) &&
!(ctrl & (NAND_CLE | NAND_ALE))) {
u32 cmd = 0;
@@ -637,6 +633,10 @@ static void sunxi_nfc_cmd_ctrl(struct mtd_info *mtd, int dat,
writel(sunxi_nand->addr[1],
nfc->regs + NFC_REG_ADDR_HIGH);
+ ret = sunxi_nfc_wait_cmd_fifo_empty(nfc);
+ if (ret)
+ return;
+
writel(cmd, nfc->regs + NFC_REG_CMD);
sunxi_nand->addr[0] = 0;
sunxi_nand->addr[1] = 0;
--
2.7.4
^ permalink raw reply related
* [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap
From: Marc Zyngier @ 2017-01-06 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM5PR0401MB2545B4A50ABE17B27C50B3099A630@AM5PR0401MB2545.eurprd04.prod.outlook.com>
On 06/01/17 04:27, Bharat Bhushan wrote:
> Hi Mark,
>
>> -----Original Message-----
>> From: Auger Eric [mailto:eric.auger at redhat.com]
>> Sent: Thursday, January 05, 2017 5:39 PM
>> To: Marc Zyngier <marc.zyngier@arm.com>; eric.auger.pro at gmail.com;
>> christoffer.dall at linaro.org; robin.murphy at arm.com;
>> alex.williamson at redhat.com; will.deacon at arm.com; joro at 8bytes.org;
>> tglx at linutronix.de; jason at lakedaemon.net; linux-arm-
>> kernel at lists.infradead.org
>> Cc: drjones at redhat.com; kvm at vger.kernel.org; punit.agrawal at arm.com;
>> linux-kernel at vger.kernel.org; geethasowjanya.akula at gmail.com; Diana
>> Madalina Craciun <diana.craciun@nxp.com>; iommu at lists.linux-
>> foundation.org; pranav.sawargaonkar at gmail.com; Bharat Bhushan
>> <bharat.bhushan@nxp.com>; shankerd at codeaurora.org;
>> gpkulkarni at gmail.com
>> Subject: Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap
>>
>> Hi Marc,
>>
>> On 05/01/2017 12:57, Marc Zyngier wrote:
>>> On 05/01/17 11:29, Auger Eric wrote:
>>>> Hi Marc,
>>>>
>>>> On 05/01/2017 12:25, Marc Zyngier wrote:
>>>>> On 05/01/17 10:45, Auger Eric wrote:
>>>>>> Hi Marc,
>>>>>>
>>>>>> On 04/01/2017 16:27, Marc Zyngier wrote:
>>>>>>> On 04/01/17 14:11, Auger Eric wrote:
>>>>>>>> Hi Marc,
>>>>>>>>
>>>>>>>> On 04/01/2017 14:46, Marc Zyngier wrote:
>>>>>>>>> Hi Eric,
>>>>>>>>>
>>>>>>>>> On 04/01/17 13:32, Eric Auger wrote:
>>>>>>>>>> This new function checks whether all platform and PCI MSI
>>>>>>>>>> domains implement IRQ remapping. This is useful to understand
>>>>>>>>>> whether VFIO passthrough is safe with respect to interrupts.
>>>>>>>>>>
>>>>>>>>>> On ARM typically an MSI controller can sit downstream to the
>>>>>>>>>> IOMMU without preventing VFIO passthrough.
>>>>>>>>>> As such any assigned device can write into the MSI doorbell.
>>>>>>>>>> In case the MSI controller implements IRQ remapping, assigned
>>>>>>>>>> devices will not be able to trigger interrupts towards the
>>>>>>>>>> host. On the contrary, the assignment must be emphasized as
>>>>>>>>>> unsafe with respect to interrupts.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> v4 -> v5:
>>>>>>>>>> - Handle DOMAIN_BUS_FSL_MC_MSI domains
>>>>>>>>>> - Check parents
>>>>>>>>>> ---
>>>>>>>>>> include/linux/irqdomain.h | 1 +
>>>>>>>>>> kernel/irq/irqdomain.c | 41
>> +++++++++++++++++++++++++++++++++++++++++
>>>>>>>>>> 2 files changed, 42 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/include/linux/irqdomain.h
>>>>>>>>>> b/include/linux/irqdomain.h index ab017b2..281a40f 100644
>>>>>>>>>> --- a/include/linux/irqdomain.h
>>>>>>>>>> +++ b/include/linux/irqdomain.h
>>>>>>>>>> @@ -219,6 +219,7 @@ struct irq_domain
>> *irq_domain_add_legacy(struct device_node *of_node,
>>>>>>>>>> void *host_data);
>>>>>>>>>> extern struct irq_domain *irq_find_matching_fwspec(struct
>> irq_fwspec *fwspec,
>>>>>>>>>> enum
>> irq_domain_bus_token bus_token);
>>>>>>>>>> +extern bool irq_domain_check_msi_remap(void);
>>>>>>>>>> extern void irq_set_default_host(struct irq_domain *host);
>>>>>>>>>> extern int irq_domain_alloc_descs(int virq, unsigned int nr_irqs,
>>>>>>>>>> irq_hw_number_t hwirq, int node,
>> diff --git
>>>>>>>>>> a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c index
>>>>>>>>>> 8c0a0ae..700caea 100644
>>>>>>>>>> --- a/kernel/irq/irqdomain.c
>>>>>>>>>> +++ b/kernel/irq/irqdomain.c
>>>>>>>>>> @@ -278,6 +278,47 @@ struct irq_domain
>>>>>>>>>> *irq_find_matching_fwspec(struct irq_fwspec *fwspec,
>>>>>>>>>> EXPORT_SYMBOL_GPL(irq_find_matching_fwspec);
>>>>>>>>>>
>>>>>>>>>> /**
>>>>>>>>>> + * irq_domain_is_msi_remap - Check if @domain or any parent
>>>>>>>>>> + * has MSI remapping support
>>>>>>>>>> + * @domain: domain pointer
>>>>>>>>>> + */
>>>>>>>>>> +static bool irq_domain_is_msi_remap(struct irq_domain
>> *domain)
>>>>>>>>>> +{
>>>>>>>>>> + struct irq_domain *h = domain;
>>>>>>>>>> +
>>>>>>>>>> + for (; h; h = h->parent) {
>>>>>>>>>> + if (h->flags & IRQ_DOMAIN_FLAG_MSI_REMAP)
>>>>>>>>>> + return true;
>>>>>>>>>> + }
>>>>>>>>>> + return false;
>>>>>>>>>> +}
>>>>>>>>>> +
>>>>>>>>>> +/**
>>>>>>>>>> + * irq_domain_check_msi_remap() - Checks whether all MSI
>>>>>>>>>> + * irq domains implement IRQ remapping */ bool
>>>>>>>>>> +irq_domain_check_msi_remap(void) {
>>>>>>>>>> + struct irq_domain *h;
>>>>>>>>>> + bool ret = true;
>>>>>>>>>> +
>>>>>>>>>> + mutex_lock(&irq_domain_mutex);
>>>>>>>>>> + list_for_each_entry(h, &irq_domain_list, link) {
>>>>>>>>>> + if (((h->bus_token & DOMAIN_BUS_PCI_MSI) ||
>>>>>>>>>> + (h->bus_token & DOMAIN_BUS_PLATFORM_MSI)
>> ||
>>>>>>>>>> + (h->bus_token & DOMAIN_BUS_FSL_MC_MSI))
>> &&
>>>>>>>>>> + !irq_domain_is_msi_remap(h)) {
>>>>>>>>>
>>>>>>>>> (h->bus_token & DOMAIN_BUS_PCI_MSI) and co looks quite
>> wrong.
>>>>>>>>> bus_token is not a bitmap, and DOMAIN_BUS_* not a single bit
>>>>>>>>> value (see enum irq_domain_bus_token). Surely this should read
>>>>>>>>> (h->bus_token == DOMAIN_BUS_PCI_MSI).
>>>>>>>> Oh I did not notice that. Thanks.
>>>>>>>>
>>>>>>>> Any other comments on the irqdomain side? Do you think the
>>>>>>>> current approach consisting in looking at those bus tokens and
>>>>>>>> their parents looks good?
>>>>>>>
>>>>>>> To be completely honest, I don't like it much, as having to
>>>>>>> enumerate all the bus types can come up with could become quite a
>>>>>>> burden in the long run. I'd rather be able to identify MSI capable
>>>>>>> domains by construction. I came up with the following approach (fully
>> untested):
>>>>>>>
>>>>>>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
>>>>>>> index 281a40f..7779796 100644
>>>>>>> --- a/include/linux/irqdomain.h
>>>>>>> +++ b/include/linux/irqdomain.h
>>>>>>> @@ -183,8 +183,11 @@ enum {
>>>>>>> /* Irq domain is an IPI domain with single virq */
>>>>>>> IRQ_DOMAIN_FLAG_IPI_SINGLE = (1 << 3),
>>>>>>>
>>>>>>> + /* Irq domain implements MSIs */
>>>>>>> + IRQ_DOMAIN_FLAG_MSI = (1 << 4),
>>>>>>> +
>>>>>>> /* Irq domain is MSI remapping capable */
>>>>>>> - IRQ_DOMAIN_FLAG_MSI_REMAP = (1 << 4),
>>>>>>> + IRQ_DOMAIN_FLAG_MSI_REMAP = (1 << 5),
>>>>>>>
>>>>>>> /*
>>>>>>> * Flags starting from IRQ_DOMAIN_FLAG_NONCORE are reserved
>> @@
>>>>>>> -450,6 +453,11 @@ static inline bool
>>>>>>> irq_domain_is_ipi_single(struct irq_domain *domain) {
>>>>>>> return domain->flags & IRQ_DOMAIN_FLAG_IPI_SINGLE; }
>>>>>>> +
>>>>>>> +static inline bool irq_domain_is_msi(struct irq_domain *domain) {
>>>>>>> + return domain->flags & IRQ_DOMAIN_FLAG_MSI; }
>>>>>>> #else /* CONFIG_IRQ_DOMAIN_HIERARCHY */
>>>>>>> static inline void irq_domain_activate_irq(struct irq_data *data)
>>>>>>> { } static inline void irq_domain_deactivate_irq(struct irq_data
>>>>>>> *data) { } @@ -481,6 +489,11 @@ static inline bool
>>>>>>> irq_domain_is_ipi_single(struct irq_domain *domain) {
>>>>>>> return false;
>>>>>>> }
>>>>>>> +
>>>>>>> +static inline bool irq_domain_is_msi(struct irq_domain *domain) {
>>>>>>> + return false;
>>>>>>> +}
>>>>>>> #endif /* CONFIG_IRQ_DOMAIN_HIERARCHY */
>>>>>>>
>>>>>>> #else /* CONFIG_IRQ_DOMAIN */
>>>>>>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c index
>>>>>>> 700caea..33b6921 100644
>>>>>>> --- a/kernel/irq/irqdomain.c
>>>>>>> +++ b/kernel/irq/irqdomain.c
>>>>>>> @@ -304,10 +304,7 @@ bool irq_domain_check_msi_remap(void)
>>>>>>>
>>>>>>> mutex_lock(&irq_domain_mutex);
>>>>>>> list_for_each_entry(h, &irq_domain_list, link) {
>>>>>>> - if (((h->bus_token & DOMAIN_BUS_PCI_MSI) ||
>>>>>>> - (h->bus_token & DOMAIN_BUS_PLATFORM_MSI)
>> ||
>>>>>>> - (h->bus_token & DOMAIN_BUS_FSL_MC_MSI))
>> &&
>>>>>>> - !irq_domain_is_msi_remap(h)) {
>>>>>>> + if (irq_domain_is_msi(h) &&
>> !irq_domain_is_msi_remap(h)) {
>>>>>>> ret = false;
>>>>>>> goto out;
>>>>>>> }
>>>>>>> diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c index
>>>>>>> ee23006..b637263 100644
>>>>>>> --- a/kernel/irq/msi.c
>>>>>>> +++ b/kernel/irq/msi.c
>>>>>>> @@ -270,7 +270,7 @@ struct irq_domain
>> *msi_create_irq_domain(struct fwnode_handle *fwnode,
>>>>>>> if (info->flags & MSI_FLAG_USE_DEF_CHIP_OPS)
>>>>>>> msi_domain_update_chip_ops(info);
>>>>>>>
>>>>>>> - return irq_domain_create_hierarchy(parent, 0, 0, fwnode,
>>>>>>> + return irq_domain_create_hierarchy(parent,
>> IRQ_DOMAIN_FLAG_MSI,
>>>>>>> +0, fwnode,
>>>>>>> &msi_domain_ops, info);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thoughts?
>>>>>>
>>>>>> Don't we need to set the IRQ_DOMAIN_FLAG_MSI flag in
>>>>>> platform_msi_create_device_domain too (drivers/base/platform-
>> msi.c)?
>>>> was mentioning platform_msi_create_*device*_domain.
>>>> it calls irq_domain_create_hierarchy and looks to be MSI irq domain
>>>> related. But I don't have a full understanding of the whole irq
>>>> domain hierarchy.
>>>
>>> Ah, sorry - I blame the ARM coffee.
>>>
>>> This function builds a domain for a single device on top of the MSI
>>> domain that has been already created (see the dev->msi_domain passed
>>> to irq_domain_create_hierarchy). The structure looks like this:
>>>
>>> device-domain -> platform MSI domain -> HW MSI domain -> whatever
>>>
>>> So what we're *really* interested in is the platform MSI domain, which
>>> is going to carry the IRQ_DOMAIN_FLAG_MSI flag. The device-domain only
>>> describes a portion of it, and can safely be ignored.
>>>
>>> In the end, what matters for this patch is that we can prove that from
>>> any domain carrying the IRQ_DOMAIN_FLAG_MSI flag, we can find a
>> domain
>>> carrying the IRQ_DOMAIN_FLAG_MSI_REMAP flag. If that property holds,
>>> we're safe. Otherwise, we disable the Guest MSI feature.
>>>
>>> Does it make sense?
>> Yes it makes sense. Thank you for the explanation!
>
> If I understood correctly then the domain hierarchy is
>
> -> "gic-irq-domain"
> -> "gic-its-irq-domain"
> -> "platform-msi-domain"
> -> "pci-msi-domain"
> -> "fsl-mc-msi-domain"
>
> "gic-its-irq-domain" carries IRQ_DOMAIN_FLAG_MSI_REMAP
>
> So we need to look for the IRQ_DOMAIN_FLAG_MSI_REMAP flag in
> "gic-its-irq-domain" when doing safety check for
> "platform/pci/fsl-mc"-msi-irqdomain, is this what you mentioned?
>
> Can we can pass this flags from "gic-its-irq-domain" to
> "platform/pci/fsl-mc"-msi-irqdomain during domain creation?
No, that's a very bad idea. It is not that domain that provides the
isolation, as it merely provides a software abstraction for a bus. On
the other hand, the underlying domain represents the HW that does
provide such isolation. Only that domain can claim that isolation will
be enforced.
So we only set the REMAP flag on the ITS domain, and place the MSI flag
on the top level MSI domains. And if we can prove that *all* MSI domains
have a parent implementing remapping, we're safe. Any other
configuration is unsafe.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ 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