* [PATCH v2 2/4] usb: musb: core: added helper function for parsing DT
From: David Lechner @ 2016-10-27 3:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477494237-22831-3-git-send-email-abailon@baylibre.com>
On 10/26/2016 10:03 AM, Alexandre Bailon wrote:
> From: Petr Kulhavy <petr@barix.com>
>
> This adds the function musb_get_mode() to get the DT property "dr_mode"
>
> Signed-off-by: Petr Kulhavy <petr@barix.com>
> Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
> ---
> drivers/usb/musb/musb_core.c | 19 +++++++++++++++++++
> drivers/usb/musb/musb_core.h | 5 +++++
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 27dadc0..bba07e7 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -100,6 +100,7 @@
> #include <linux/io.h>
> #include <linux/dma-mapping.h>
> #include <linux/usb.h>
> +#include <linux/usb/of.h>
>
> #include "musb_core.h"
> #include "musb_trace.h"
> @@ -130,6 +131,24 @@ static inline struct musb *dev_to_musb(struct device *dev)
> return dev_get_drvdata(dev);
> }
>
> +enum musb_mode musb_get_mode(struct device *dev)
> +{
> + enum usb_dr_mode mode;
> +
> + mode = usb_get_dr_mode(dev);
> + switch (mode) {
> + case USB_DR_MODE_HOST:
> + return MUSB_HOST;
> + case USB_DR_MODE_PERIPHERAL:
> + return MUSB_PERIPHERAL;
> + case USB_DR_MODE_OTG:
> + case USB_DR_MODE_UNKNOWN:
> + default:
> + return MUSB_OTG;
> + }
> +}
> +EXPORT_SYMBOL_GPL(musb_get_mode);
> +
> /*-------------------------------------------------------------------------*/
>
> #ifndef CONFIG_BLACKFIN
> diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
> index 2cb88a49..a406468 100644
> --- a/drivers/usb/musb/musb_core.h
> +++ b/drivers/usb/musb/musb_core.h
> @@ -617,4 +617,9 @@ static inline void musb_platform_post_root_reset_end(struct musb *musb)
> musb->ops->post_root_reset_end(musb);
> }
>
> +/* gets the "dr_mode" property from DT and converts it into musb_mode
> + * if the property is not found or not recognized returns MUSB_OTG
> + */
> +extern enum musb_mode musb_get_mode(struct device *dev);
> +
> #endif /* __MUSB_CORE_H__ */
>
Tested working on LEGO MINDSTORMS EV3 using dr_mode = "peripheral" and
no vbus-supply.
Tested-By: David Lechner <david@lechnology.com>
^ permalink raw reply
* [PATCH 1/2] ARM: dts: uniphier: add CPU clocks and OPP table for Pro5 SoC
From: Viresh Kumar @ 2016-10-27 3:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477499859-12415-1-git-send-email-yamada.masahiro@socionext.com>
On 27-10-16, 01:37, Masahiro Yamada wrote:
> Add a CPU clock to every CPU node and a CPU OPP table to use the
> generic cpufreq driver.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> arch/arm/boot/dts/uniphier-pro5.dtsi | 74 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 74 insertions(+)
For both patches.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH V3 6/8] arm: dma-mapping: Reset the device's dma_ops
From: Sricharan @ 2016-10-27 3:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a3d4533f-165d-f444-7681-141479617a18@arm.com>
Hi Robin,
>-----Original Message-----
>From: Robin Murphy [mailto:robin.murphy at arm.com]
>Sent: Wednesday, October 26, 2016 8:37 PM
>To: Sricharan R <sricharan@codeaurora.org>; will.deacon at arm.com; joro at 8bytes.org; iommu at lists.linux-foundation.org; linux-arm-
>kernel at lists.infradead.org; linux-arm-msm at vger.kernel.org; laurent.pinchart at ideasonboard.com; m.szyprowski at samsung.com;
>tfiga at chromium.org; srinivas.kandagatla at linaro.org
>Subject: Re: [PATCH V3 6/8] arm: dma-mapping: Reset the device's dma_ops
>
>On 04/10/16 18:03, Sricharan R wrote:
>> The dma_ops for the device is not getting set to NULL in
>> arch_tear_down_dma_ops and this causes an issue when the
>> device's probe gets deferred and retried. So reset the
>> dma_ops to NULL.
>
>Reviewed-by: Robin Murphy <robin.murphy@arm.com>
>
Thanks.
>This seems like it could stand independently from the rest of the series
>- might be worth rewording the commit message to more general terms,
>i.e. arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops()
>thus clearing the ops set by the latter, and sending it to Russell as a
>fix in its own right.
Ok, will reword the commit log and push this separately.
Regards,
Sricharan
^ permalink raw reply
* [PATCH 2/2] arm64/numa: support HAVE_MEMORYLESS_NODES
From: Leizhen (ThunderTown) @ 2016-10-27 3:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026183614.GJ15216@arm.com>
On 2016/10/27 2:36, Will Deacon wrote:
> On Tue, Oct 25, 2016 at 10:59:18AM +0800, Zhen Lei wrote:
>> Some numa nodes may have no memory. For example:
>> 1) a node has no memory bank plugged.
>> 2) a node has no memory bank slots.
>>
>> To ensure percpu variable areas and numa control blocks of the
>> memoryless numa nodes to be allocated from the nearest available node to
>> improve performance, defined node_distance_ready. And make its value to be
>> true immediately after node distances have been initialized.
>>
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>> ---
>> arch/arm64/Kconfig | 4 ++++
>> arch/arm64/include/asm/numa.h | 3 +++
>> arch/arm64/mm/numa.c | 6 +++++-
>> 3 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 30398db..648dd13 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -609,6 +609,10 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>> def_bool y
>> depends on NUMA
>>
>> +config HAVE_MEMORYLESS_NODES
>> + def_bool y
>> + depends on NUMA
>
> Given that patch 1 and the associated node_distance_ready stuff is all
> an unqualified performance optimisation, is there any merit in just
> enabling HAVE_MEMORYLESS_NODES in Kconfig and then optimising things as
> a separate series when you have numbers to back it up?
HAVE_MEMORYLESS_NODES is also an performance optimisation for memoryless scenario.
For example:
node0 is a memoryless node, node1 is the nearest node of node0.
We want to allocate memory from node0, normally memory manager will try node0 first, then node1.
But we have already kwown that node0 have no memory, so we can tell memory manager directly try
node1 first. So HAVE_MEMORYLESS_NODES is used to skip the memoryless nodes, don't try them.
So I think the title of this patch is misleading, I will rewrite it in V2.
Or, Do you mean separate it into a new patch?
>
> Will
>
> .
>
^ permalink raw reply
* [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
From: Y.B. Lu @ 2016-10-27 4:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477501566.6812.9.camel@buserror.net>
Hi Scott,
> -----Original Message-----
> From: Scott Wood [mailto:oss at buserror.net]
> Sent: Thursday, October 27, 2016 1:06 AM
> To: Y.B. Lu; linux-mmc at vger.kernel.org; ulf.hansson at linaro.org; Arnd
> Bergmann
> Cc: linuxppc-dev at lists.ozlabs.org; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-
> clk at vger.kernel.org; linux-i2c at vger.kernel.org; iommu at lists.linux-
> foundation.org; netdev at vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian
> Subject: Re: [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Wed, 2016-09-21 at 14:57 +0800, Yangbo Lu wrote:
> > diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig new
> > file mode 100644 index 0000000..b99764c
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Kconfig
> > @@ -0,0 +1,19 @@
> > +#
> > +# Freescale SOC drivers
> > +#
> > +
> > +source "drivers/soc/fsl/qe/Kconfig"
> > +
> > +config FSL_GUTS
> > + bool "Freescale QorIQ GUTS driver"
> > + select SOC_BUS
> > + help
> > + ??The global utilities block controls power management, I/O device
> > + ??enabling, power-onreset(POR) configuration monitoring, alternate
> > + ??function selection for multiplexed signals,and clock control.
> > + ??This driver is to manage and access global utilities block.
> > + ??Initially only reading SVR and registering soc device are
> > supported.
> > + ??Other guts accesses, such as reading RCW, should eventually be
> > moved
> > + ??into this driver as well.
> > +
> > + ??If you want GUTS driver support, you should say Y here.
>
> This is user-enablable without dependencies, which means it will break
> some randconfigs. ?If this is to be enabled via select then remove the
> text after "bool".
[Lu Yangbo-B47093] Will enable it via select and remove text after 'bool'.
>
> > +/* SoC die attribute definition for QorIQ platform */ static const
> > +struct fsl_soc_die_attr fsl_soc_die[] = { #ifdef CONFIG_PPC
> > + /*
> > + ?* Power Architecture-based SoCs T Series
> > + ?*/
> > +
> > + /* Die: T4240, SoC: T4240/T4160/T4080 */
> > + { .die = "T4240",
> > + ??.svr = 0x82400000,
> > + ??.mask = 0xfff00000,
> > + },
> > + /* Die: T1040, SoC: T1040/T1020/T1042/T1022 */
> > + { .die = "T1040",
> > + ??.svr = 0x85200000,
> > + ??.mask = 0xfff00000,
> > + },
> > + /* Die: T2080, SoC: T2080/T2081 */
> > + { .die = "T2080",
> > + ??.svr = 0x85300000,
> > + ??.mask = 0xfff00000,
> > + },
> > + /* Die: T1024, SoC: T1024/T1014/T1023/T1013 */
> > + { .die = "T1024",
> > + ??.svr = 0x85400000,
> > + ??.mask = 0xfff00000,
> > + },
> > +#endif /* CONFIG_PPC */
> > +#if defined(CONFIG_ARCH_MXC) || defined(CONFIG_ARCH_LAYERSCAPE)
>
> Will this driver ever be probed on MXC? ?Why do we need these ifdefs at
> all?
[Lu Yangbo-B47093] Will remove them. In the previous version, we use too many members for soc definition, so I add #ifdef for ARCH.
CONFIG_ARCH_MXC was for ls1021a.
>
>
> > + /*
> > + ?* ARM-based SoCs LS Series
> > + ?*/
> > +
> > + /* Die: LS1043A, SoC: LS1043A/LS1023A */
> > + { .die = "LS1043A",
> > + ??.svr = 0x87920000,
> > + ??.mask = 0xffff0000,
> > + },
> > + /* Die: LS2080A, SoC: LS2080A/LS2040A/LS2085A */
> > + { .die = "LS2080A",
> > + ??.svr = 0x87010000,
> > + ??.mask = 0xff3f0000,
> > + },
> > + /* Die: LS1088A, SoC: LS1088A/LS1048A/LS1084A/LS1044A */
> > + { .die = "LS1088A",
> > + ??.svr = 0x87030000,
> > + ??.mask = 0xff3f0000,
> > + },
> > + /* Die: LS1012A, SoC: LS1012A */
> > + { .die = "LS1012A",
> > + ??.svr = 0x87040000,
> > + ??.mask = 0xffff0000,
> > + },
> > + /* Die: LS1046A, SoC: LS1046A/LS1026A */
> > + { .die = "LS1046A",
> > + ??.svr = 0x87070000,
> > + ??.mask = 0xffff0000,
> > + },
> > + /* Die: LS2088A, SoC: LS2088A/LS2048A/LS2084A/LS2044A */
> > + { .die = "LS2088A",
> > + ??.svr = 0x87090000,
> > + ??.mask = 0xff3f0000,
> > + },
> > + /* Die: LS1021A, SoC: LS1021A/LS1020A/LS1022A
> > + ?* Note: Put this die at the end in cause of incorrect
> > identification
> > + ?*/
> > + { .die = "LS1021A",
> > + ??.svr = 0x87000000,
> > + ??.mask = 0xfff00000,
> > + },
> > +#endif /* CONFIG_ARCH_MXC || CONFIG_ARCH_LAYERSCAPE */
>
> Instead of relying on ordering, add more bits to the mask so that there's
> no overlap. ?I think 0xfff70000 would work.
[Lu Yangbo-B47093] Ok, Will do that. Then we add 3 bits of 'Various Personalities' field for ls1021a die identification.
>
> > +out:
> > + kfree(soc_dev_attr.machine);
> > + kfree(soc_dev_attr.family);
> > + kfree(soc_dev_attr.soc_id);
> > + kfree(soc_dev_attr.revision);
> > + iounmap(guts->regs);
> > +out_free:
> > + kfree(guts);
> > + return ret;
> > +}
>
> Please use devm.
[Lu Yangbo-B47093] Sorry for forgetting this. Will do that and send out the new version soon.
Thanks for your comments.
>
> -Scott
^ permalink raw reply
* [PATCH V3 7/8] arm/arm64: dma-mapping: Call iommu's remove_device callback during device detach
From: Sricharan @ 2016-10-27 5:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2873304f-8b2e-b519-b3e6-d2b452b1df60@arm.com>
Hi Robin,
>> dma_deconfigure calls arch_teardown_dma_ops in the device_detach path,
>> which is called when the device gets detached from the driver.
>> When the device was added, iommu's add_device callback was used to
>> add the device in to its iommu_group and setup the device to be ready
>> to use its iommu. Similarly, call remove_device callback to remove the
>> device from the group and reset any other device's iommu configurations.
>>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>> arch/arm/mm/dma-mapping.c | 8 ++++++++
>> arch/arm64/mm/dma-mapping.c | 7 +++++++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
>> index b9191f0..cbe22de 100644
>> --- a/arch/arm/mm/dma-mapping.c
>> +++ b/arch/arm/mm/dma-mapping.c
>> @@ -2289,11 +2289,19 @@ static bool arm_setup_iommu_dma_ops(struct device *dev, u64 dma_base, u64 size,
>> static void arm_teardown_iommu_dma_ops(struct device *dev)
>> {
>> struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
>> + const struct iommu_ops *ops;
>>
>> if (!mapping)
>> return;
>>
>> __arm_iommu_detach_device(dev);
>> +
>> + if (dev->iommu_fwspec) {
>> + ops = dev->iommu_fwspec->ops;
>> + if (ops->remove_device)
>> + ops->remove_device(dev);
>> + }
>> +
>
>Yuck. It's a little unfortunate that we have to do this at all, but I
>see why. Still, it should be done in common code, not duplicated across
>arch code, not least for symmetry with where the matching add_device
>happened (although I think of_dma_deconfigure() would suffice, I'm not
>sure we really need to add an of_iommu_deconfigure() just for this).
>
So one way is its already called via a the BUS_NOTIFY_REMOVED_DEVICE
notifier in iommu_bus_notifier. I put it here, one for symmetry and
another thinking that the remove_device callback should be done
before the dma_ops is set to NULL. If thats not required then the existing
iommu_bus_notifier itself can do the cleanup. The corresponding
add_device in that notifier is dummy now, i will add a patch to remove
that. If not the whole thing, we can add of_iommu_deconfigure as well.
>It's also broken for IOMMU drivers which rely on the
>of_iommu_configure() mechanism but have not yet been converted to use
>iommu_fwspec (Exynos, MSM, etc.)
>
I did this, because fwspec was the right way to get ops in the future,
but yes its getting broken for those which are not converted,
will have to use dev->bus->iommu_ops in those cases. Will address this
while changing the above.
Regards,
Sricharan
^ permalink raw reply
* [PATCH V3 8/8] arm64: dma-mapping: Remove the notifier trick to handle early setting of dma_ops
From: Sricharan @ 2016-10-27 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e4643826-3aa8-1e34-79a8-9e1fcf0fcb69@arm.com>
Hi Robin,
>On 04/10/16 18:03, Sricharan R wrote:
>> With arch_setup_dma_ops now being called late during device's probe after the
>> device's iommu is probed, the notifier trick required to handle the early
>> setup of dma_ops before the iommu group gets created is not required.
>> So removing the notifier's here.
>
>Hooray!
>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>> arch/arm64/mm/dma-mapping.c | 100 ++------------------------------------------
>> 1 file changed, 3 insertions(+), 97 deletions(-)
>>
>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>> index faf4b92..eb593af 100644
>> --- a/arch/arm64/mm/dma-mapping.c
>> +++ b/arch/arm64/mm/dma-mapping.c
>> @@ -799,24 +799,6 @@ static struct dma_map_ops iommu_dma_ops = {
>> .mapping_error = iommu_dma_mapping_error,
>> };
>>
>> -/*
>> - * TODO: Right now __iommu_setup_dma_ops() gets called too early to do
>> - * everything it needs to - the device is only partially created and the
>> - * IOMMU driver hasn't seen it yet, so it can't have a group. Thus we
>> - * need this delayed attachment dance. Once IOMMU probe ordering is sorted
>> - * to move the arch_setup_dma_ops() call later, all the notifier bits below
>> - * become unnecessary, and will go away.
>> - */
>> -struct iommu_dma_notifier_data {
>> - struct list_head list;
>> - struct device *dev;
>> - const struct iommu_ops *ops;
>> - u64 dma_base;
>> - u64 size;
>> -};
>> -static LIST_HEAD(iommu_dma_masters);
>> -static DEFINE_MUTEX(iommu_dma_notifier_lock);
>> -
>> static bool do_iommu_attach(struct device *dev, const struct iommu_ops *ops,
>> u64 dma_base, u64 size)
>
>This should go as well...
ok.
>
>> {
>> @@ -837,79 +819,9 @@ static bool do_iommu_attach(struct device *dev, const struct iommu_ops *ops,
>> return true;
>> }
>>
>> -static void queue_iommu_attach(struct device *dev, const struct iommu_ops *ops,
>> - u64 dma_base, u64 size)
>> -{
>> - struct iommu_dma_notifier_data *iommudata;
>> -
>> - iommudata = kzalloc(sizeof(*iommudata), GFP_KERNEL);
>> - if (!iommudata)
>> - return;
>> -
>> - iommudata->dev = dev;
>> - iommudata->ops = ops;
>> - iommudata->dma_base = dma_base;
>> - iommudata->size = size;
>> -
>> - mutex_lock(&iommu_dma_notifier_lock);
>> - list_add(&iommudata->list, &iommu_dma_masters);
>> - mutex_unlock(&iommu_dma_notifier_lock);
>> -}
>> -
>> -static int __iommu_attach_notifier(struct notifier_block *nb,
>> - unsigned long action, void *data)
>> -{
>> - struct iommu_dma_notifier_data *master, *tmp;
>> -
>> - if (action != BUS_NOTIFY_BIND_DRIVER)
>> - return 0;
>> -
>> - mutex_lock(&iommu_dma_notifier_lock);
>> - list_for_each_entry_safe(master, tmp, &iommu_dma_masters, list) {
>> - if (data == master->dev && do_iommu_attach(master->dev,
>> - master->ops, master->dma_base, master->size)) {
>> - list_del(&master->list);
>> - kfree(master);
>> - break;
>> - }
>> - }
>> - mutex_unlock(&iommu_dma_notifier_lock);
>> - return 0;
>> -}
>> -
>> -static int __init register_iommu_dma_ops_notifier(struct bus_type *bus)
>> -{
>> - struct notifier_block *nb = kzalloc(sizeof(*nb), GFP_KERNEL);
>> - int ret;
>> -
>> - if (!nb)
>> - return -ENOMEM;
>> -
>> - nb->notifier_call = __iommu_attach_notifier;
>> -
>> - ret = bus_register_notifier(bus, nb);
>> - if (ret) {
>> - pr_warn("Failed to register DMA domain notifier; IOMMU DMA ops unavailable on bus '%s'\n",
>> - bus->name);
>> - kfree(nb);
>> - }
>> - return ret;
>> -}
>> -
>> static int __init __iommu_dma_init(void)
>> {
>> - int ret;
>> -
>> - ret = iommu_dma_init();
>> - if (!ret)
>> - ret = register_iommu_dma_ops_notifier(&platform_bus_type);
>> - if (!ret)
>> - ret = register_iommu_dma_ops_notifier(&amba_bustype);
>> -#ifdef CONFIG_PCI
>> - if (!ret)
>> - ret = register_iommu_dma_ops_notifier(&pci_bus_type);
>> -#endif
>> - return ret;
>> + return iommu_dma_init();
>> }
>> arch_initcall(__iommu_dma_init);
>>
>> @@ -920,18 +832,12 @@ static void __iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>>
>> if (!ops)
>> return;
>> - /*
>> - * TODO: As a concession to the future, we're ready to handle being
>> - * called both early and late (i.e. after bus_add_device). Once all
>> - * the platform bus code is reworked to call us late and the notifier
>> - * junk above goes away, move the body of do_iommu_attach here.
>
>...per this commment. It has no need to be a separate function once this
>is the only call site (plus it has a misleadingly inaccurate name anyway).
ya, missed to remove that function as well. Will do it in the next.
Regards,
Sricharan
^ permalink raw reply
* [PATCH v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO
From: Archit Taneja @ 2016-10-27 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64=c5PFx+qJkfPeKYFQYLYoYfWgjg49O4Es5qVjuyf5gg@mail.gmail.com>
On 10/25/2016 02:29 PM, Chen-Yu Tsai wrote:
> On Tue, Oct 25, 2016 at 4:09 PM, Archit Taneja <architt@codeaurora.org> wrote:
>> Hi,
>>
>> On 10/20/2016 09:13 AM, Chen-Yu Tsai wrote:
>>>
>>> Some rgb-to-vga bridges have an enable GPIO, either directly tied to
>>> an enable pin on the bridge IC, or indirectly controlling a power
>>> switch.
>>>
>>> Add support for it.
>>
>>
>> Does the bridge on your platform have an active/passive DAC, or is it a
>> smarter encoder chip that is capable of doing more? If so, it might be
>> good to have a separate DT compatible string to it, like what's done
>> in the patch titled:
>>
>> drm: bridge: vga-dac: Add adi,adv7123 compatible string
>>
>> so that we can switch to a different driver later if needed.
>
> The chip is GM7123. It is not configurable. It just takes the LCD RGB/SYNC
> signals and converts them to analog. The only things you can change are
> putting it into sleep mode and tweaking the output drive strength by
Is sleep mode the thing that's controlled by this gpio?
> changing the external reference resistor. The latter would be a hardware
> design decision. I would say this qualifies as "dumb".
Yeah, I agree. I'd want feedback from Laurent too, since he had comments
on the usage of the original dumb-vga-dac driver.
>
> I revisited the board schematics, and the enable GPIO actually toggles
> an external LDO regulator. So this might be better modeled as a regulator
> supply?
If you model it as a regulator, how would you toggle the GPIO on your
platform?
Looking at the chip pin out, there is a 3.3V VDD supply needed for the
chip, so it would be good to have an optional 'power' regulator supply
anyway.
Archit
>
>
> Thanks
> ChenYu
>
>>
>> Thanks,
>> Archit
>>
>>
>>>
>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>> ---
>>> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
>>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 28
>>> ++++++++++++++++++++++
>>> 2 files changed, 30 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> index 003bc246a270..d3484822bf77 100644
>>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> @@ -16,6 +16,8 @@ graph bindings specified in
>>> Documentation/devicetree/bindings/graph.txt.
>>> - Video port 0 for RGB input
>>> - Video port 1 for VGA output
>>>
>>> +Optional properties:
>>> +- enable-gpios: GPIO pin to enable or disable the bridge
>>>
>>> Example
>>> -------
>>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> index afec232185a7..b487e5e9b56d 100644
>>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> @@ -10,6 +10,7 @@
>>> * the License, or (at your option) any later version.
>>> */
>>>
>>> +#include <linux/gpio/consumer.h>
>>> #include <linux/module.h>
>>> #include <linux/of_graph.h>
>>>
>>> @@ -23,6 +24,7 @@ struct dumb_vga {
>>> struct drm_connector connector;
>>>
>>> struct i2c_adapter *ddc;
>>> + struct gpio_desc *enable_gpio;
>>> };
>>>
>>> static inline struct dumb_vga *
>>> @@ -124,8 +126,26 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>>> return 0;
>>> }
>>>
>>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>>> +{
>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>> +
>>> + if (vga->enable_gpio)
>>> + gpiod_set_value_cansleep(vga->enable_gpio, 1);
>>> +}
>>> +
>>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>>> +{
>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>> +
>>> + if (vga->enable_gpio)
>>> + gpiod_set_value_cansleep(vga->enable_gpio, 0);
>>> +}
>>> +
>>> static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>>> .attach = dumb_vga_attach,
>>> + .enable = dumb_vga_enable,
>>> + .disable = dumb_vga_disable,
>>> };
>>>
>>> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>>> @@ -169,6 +189,14 @@ static int dumb_vga_probe(struct platform_device
>>> *pdev)
>>> return -ENOMEM;
>>> platform_set_drvdata(pdev, vga);
>>>
>>> + vga->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
>>> + GPIOD_OUT_LOW);
>>> + if (IS_ERR(vga->enable_gpio)) {
>>> + ret = PTR_ERR(vga->enable_gpio);
>>> + dev_err(&pdev->dev, "failed to request GPIO: %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
>>> if (IS_ERR(vga->ddc)) {
>>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>>>
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO
From: Chen-Yu Tsai @ 2016-10-27 6:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ca071d-c396-25b3-aff4-c838c9003f94@codeaurora.org>
On Thu, Oct 27, 2016 at 2:40 PM, Archit Taneja <architt@codeaurora.org> wrote:
>
>
> On 10/25/2016 02:29 PM, Chen-Yu Tsai wrote:
>>
>> On Tue, Oct 25, 2016 at 4:09 PM, Archit Taneja <architt@codeaurora.org>
>> wrote:
>>>
>>> Hi,
>>>
>>> On 10/20/2016 09:13 AM, Chen-Yu Tsai wrote:
>>>>
>>>>
>>>> Some rgb-to-vga bridges have an enable GPIO, either directly tied to
>>>> an enable pin on the bridge IC, or indirectly controlling a power
>>>> switch.
>>>>
>>>> Add support for it.
>>>
>>>
>>>
>>> Does the bridge on your platform have an active/passive DAC, or is it a
>>> smarter encoder chip that is capable of doing more? If so, it might be
>>> good to have a separate DT compatible string to it, like what's done
>>> in the patch titled:
>>>
>>> drm: bridge: vga-dac: Add adi,adv7123 compatible string
>>>
>>> so that we can switch to a different driver later if needed.
>>
>>
>> The chip is GM7123. It is not configurable. It just takes the LCD RGB/SYNC
>> signals and converts them to analog. The only things you can change are
>> putting it into sleep mode and tweaking the output drive strength by
>
>
> Is sleep mode the thing that's controlled by this gpio?
Not on this particular board. The gpio controls the external LDO that
supplies 3.3V to VDD.
>
>> changing the external reference resistor. The latter would be a hardware
>> design decision. I would say this qualifies as "dumb".
>
>
> Yeah, I agree. I'd want feedback from Laurent too, since he had comments
> on the usage of the original dumb-vga-dac driver.
>
>>
>> I revisited the board schematics, and the enable GPIO actually toggles
>> an external LDO regulator. So this might be better modeled as a regulator
>> supply?
>
>
> If you model it as a regulator, how would you toggle the GPIO on your
> platform?
>
> Looking at the chip pin out, there is a 3.3V VDD supply needed for the
> chip, so it would be good to have an optional 'power' regulator supply
> anyway.
Yes, that it what I plan to do. I'll drop the enable-gpios property,
and add a power-supply property for the regulator.
Regards
ChenYu
>
> Archit
>
>
>>
>>
>> Thanks
>> ChenYu
>>
>>>
>>> Thanks,
>>> Archit
>>>
>>>
>>>>
>>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>>> ---
>>>> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
>>>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 28
>>>> ++++++++++++++++++++++
>>>> 2 files changed, 30 insertions(+)
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>>> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>>> index 003bc246a270..d3484822bf77 100644
>>>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>>> @@ -16,6 +16,8 @@ graph bindings specified in
>>>> Documentation/devicetree/bindings/graph.txt.
>>>> - Video port 0 for RGB input
>>>> - Video port 1 for VGA output
>>>>
>>>> +Optional properties:
>>>> +- enable-gpios: GPIO pin to enable or disable the bridge
>>>>
>>>> Example
>>>> -------
>>>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>>> index afec232185a7..b487e5e9b56d 100644
>>>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>>> @@ -10,6 +10,7 @@
>>>> * the License, or (at your option) any later version.
>>>> */
>>>>
>>>> +#include <linux/gpio/consumer.h>
>>>> #include <linux/module.h>
>>>> #include <linux/of_graph.h>
>>>>
>>>> @@ -23,6 +24,7 @@ struct dumb_vga {
>>>> struct drm_connector connector;
>>>>
>>>> struct i2c_adapter *ddc;
>>>> + struct gpio_desc *enable_gpio;
>>>> };
>>>>
>>>> static inline struct dumb_vga *
>>>> @@ -124,8 +126,26 @@ static int dumb_vga_attach(struct drm_bridge
>>>> *bridge)
>>>> return 0;
>>>> }
>>>>
>>>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>>>> +{
>>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>>> +
>>>> + if (vga->enable_gpio)
>>>> + gpiod_set_value_cansleep(vga->enable_gpio, 1);
>>>> +}
>>>> +
>>>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>>>> +{
>>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>>> +
>>>> + if (vga->enable_gpio)
>>>> + gpiod_set_value_cansleep(vga->enable_gpio, 0);
>>>> +}
>>>> +
>>>> static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>>>> .attach = dumb_vga_attach,
>>>> + .enable = dumb_vga_enable,
>>>> + .disable = dumb_vga_disable,
>>>> };
>>>>
>>>> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>>>> @@ -169,6 +189,14 @@ static int dumb_vga_probe(struct platform_device
>>>> *pdev)
>>>> return -ENOMEM;
>>>> platform_set_drvdata(pdev, vga);
>>>>
>>>> + vga->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
>>>> + GPIOD_OUT_LOW);
>>>> + if (IS_ERR(vga->enable_gpio)) {
>>>> + ret = PTR_ERR(vga->enable_gpio);
>>>> + dev_err(&pdev->dev, "failed to request GPIO: %d\n",
>>>> ret);
>>>> + return ret;
>>>> + }
>>>> +
>>>> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
>>>> if (IS_ERR(vga->ddc)) {
>>>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>>>>
>>>
>>> --
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> a Linux Foundation Collaborative Project
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] ARM: shmobile: select errata 798181 for SoCs with CA15 cores
From: Simon Horman @ 2016-10-27 7:00 UTC (permalink / raw)
To: linux-arm-kernel
Select ARM errata 798181 on SoCs cores affected CA15 cores.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/Kconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index c48be1d332ed..6fbd9b7d2d67 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -60,6 +60,7 @@ config ARCH_R7S72100
config ARCH_R8A73A4
bool "R-Mobile APE6 (R8A73A40)"
select ARCH_RMOBILE
+ select ARM_ERRATA_798181 if SMP
select RENESAS_IRQC
config ARCH_R8A7740
@@ -70,6 +71,7 @@ config ARCH_R8A7740
config ARCH_R8A7743
bool "RZ/G1M (R8A77430)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
config ARCH_R8A7778
bool "R-Car M1A (R8A77781)"
@@ -82,20 +84,24 @@ config ARCH_R8A7779
config ARCH_R8A7790
bool "R-Car H2 (R8A77900)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
select I2C
config ARCH_R8A7791
bool "R-Car M2-W (R8A77910)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
select I2C
config ARCH_R8A7792
bool "R-Car V2H (R8A77920)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
config ARCH_R8A7793
bool "R-Car M2-N (R8A7793)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
select I2C
config ARCH_R8A7794
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH v4 0/7] Add R8A7743/SK-RZG1M board support
From: Simon Horman @ 2016-10-27 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWQegsEf_C=UGXpQiEAX0YQqy335teuvCZxBY6C=7QozA@mail.gmail.com>
On Wed, Oct 26, 2016 at 03:27:14PM +0200, Geert Uytterhoeven wrote:
> On Wed, Oct 26, 2016 at 3:23 PM, Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com> wrote:
> > On 10/26/2016 03:08 PM, Geert Uytterhoeven wrote:
> >>> Here's the set of 8 patches against Simon Horman's 'renesas.git'
> >>> repo's
> >>> 'renesas-devel-20161021-v4.9-rc1' tag. I'm adding the device tree support
> >>> for
> >>> the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the
> >>> board
> >>> seems identical to the R8A7791/Porter board. The device tree patches
> >>> depend on
> >>> the R8A7743 CPG/MSSR driver series just posted in order to compile and
> >>> work.
> >>
> >>
> >> They depend only on "[PATCH v3 1/2] ARM: shmobile: r8a7743: add CPG clock
> >> index macros" of that series, right?
> >>
> >> "[PATCH v3 2/2] clk: renesas: cpg-mssr: add R8A7743 support" is not
> >> needed,
> >
> > How would "clocks" props _work_ without this patch?
>
> Sorry, I was focusing too much on "compile"...
>
> Got my coke, switching brain to overdrive mode...
As we are talking about adding support for a new SoC I would be happy
to queue up code in my tree that compiles under the assumption that
in v4.10 the bits to make it run will appear in other branches.
^ permalink raw reply
* [PATCHv2] ARM: dts: socfpga: Enable QSPI on the Cyclone5 sockit
From: Steffen Trumtrar @ 2016-10-27 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477505112-26079-1-git-send-email-dinguyen@opensource.altera.com>
On Wed, Oct 26, 2016 at 01:05:12PM -0500, dinguyen at opensource.altera.com wrote:
> From: Dinh Nguyen <dinguyen@opensource.altera.com>
>
> Enable the QSPI node and add the flash chip.
>
> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
> ---
> v2: Remove partition entries for the SoCKIT
> ---
> arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
> index 02e22f5..2ce6736 100644
> --- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
> +++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
> @@ -175,6 +175,27 @@
> status = "okay";
> };
>
> +&qspi {
> + status = "okay";
> +
> + flash: flash at 0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "n25q256a";
Did you test if this works correctly? According to my datasheet (Rev. C)
the HPS qspi is a n25q00. The n25q256a is the other one.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] ARM: shmobile: select errata 798181 for SoCs with CA15 cores
From: Geert Uytterhoeven @ 2016-10-27 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477551606-6903-1-git-send-email-horms+renesas@verge.net.au>
On Thu, Oct 27, 2016 at 9:00 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Select ARM errata 798181 on SoCs cores affected CA15 cores.
... cores with ...
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] arm64: defconfig: Enable DRM DU and V4L2 FCP + VSP modules
From: Simon Horman @ 2016-10-27 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026052422.17283.57864.sendpatchset@little-apple>
On Wed, Oct 26, 2016 at 02:24:22PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
>
> Extend the ARM64 defconfig to enable the DU DRM device as module
> together with required dependencies of V4L2 FCP and VSP modules.
>
> This enables VGA output on the r8a7795 Salvator-X board.
>
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Thanks, I have queued this up.
^ permalink raw reply
* [PATCH] arm64: defconfig: Enable DRM DU and V4L2 FCP + VSP modules
From: Simon Horman @ 2016-10-27 7:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027070801.GB7706@verge.net.au>
On Thu, Oct 27, 2016 at 09:08:01AM +0200, Simon Horman wrote:
> On Wed, Oct 26, 2016 at 02:24:22PM +0900, Magnus Damm wrote:
> > From: Magnus Damm <damm+renesas@opensource.se>
> >
> > Extend the ARM64 defconfig to enable the DU DRM device as module
> > together with required dependencies of V4L2 FCP and VSP modules.
> >
> > This enables VGA output on the r8a7795 Salvator-X board.
> >
> > Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
>
> Thanks, I have queued this up.
Given discussion elsewhere on enabling DU I am holding off on this for a
little; it is not queued up for now.
^ permalink raw reply
* [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc
From: Michal Hocko @ 2016-10-27 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58116954.8080908@huawei.com>
On Thu 27-10-16 10:41:24, Leizhen (ThunderTown) wrote:
>
>
> On 2016/10/26 17:31, Michal Hocko wrote:
> > On Wed 26-10-16 11:10:44, Leizhen (ThunderTown) wrote:
> >>
> >>
> >> On 2016/10/25 21:23, Michal Hocko wrote:
> >>> On Tue 25-10-16 10:59:17, Zhen Lei wrote:
> >>>> If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
> >>>> actually exist. The percpu variable areas and numa control blocks of that
> >>>> memoryless numa nodes need to be allocated from the nearest available
> >>>> node to improve performance.
> >>>>
> >>>> Although memblock_alloc_try_nid and memblock_virt_alloc_try_nid try the
> >>>> specified nid at the first time, but if that allocation failed it will
> >>>> directly drop to use NUMA_NO_NODE. This mean any nodes maybe possible at
> >>>> the second time.
> >>>>
> >>>> To compatible the above old scene, I use a marco node_distance_ready to
> >>>> control it. By default, the marco node_distance_ready is not defined in
> >>>> any platforms, the above mentioned functions will work as normal as
> >>>> before. Otherwise, they will try the nearest node first.
> >>>
> >>> I am sorry but it is absolutely unclear to me _what_ is the motivation
> >>> of the patch. Is this a performance optimization, correctness issue or
> >>> something else? Could you please restate what is the problem, why do you
> >>> think it has to be fixed at memblock layer and describe what the actual
> >>> fix is please?
> >>
> >> This is a performance optimization.
> >
> > Do you have any numbers to back the improvements?
>
> I have not collected any performance data, but at least in theory,
> it's beneficial and harmless, except make code looks a bit
> urly.
The whole memoryless area is cluttered with hacks because everybody just
adds pieces here and there to make his particular usecase work IMHO.
Adding more on top for performance reasons which are even not measured
to prove a clear win is a no go. Please step back try to think how this
could be done with an existing infrastructure we have (some cleanups
while doing that would be hugely appreciated) and if that is not
possible then explain why and why it is not feasible to fix that before
you start adding a new API.
Thanks!
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH] ARM: shmobile: select errata 798181 for SoCs with CA15 cores
From: Magnus Damm @ 2016-10-27 7:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477551606-6903-1-git-send-email-horms+renesas@verge.net.au>
Hi Simon,
On Thu, Oct 27, 2016 at 4:00 PM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Select ARM errata 798181 on SoCs cores affected CA15 cores.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> arch/arm/mach-shmobile/Kconfig | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index c48be1d332ed..6fbd9b7d2d67 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -60,6 +60,7 @@ config ARCH_R7S72100
> config ARCH_R8A73A4
> bool "R-Mobile APE6 (R8A73A40)"
> select ARCH_RMOBILE
> + select ARM_ERRATA_798181 if SMP
> select RENESAS_IRQC
>
> config ARCH_R8A7740
> @@ -70,6 +71,7 @@ config ARCH_R8A7740
> config ARCH_R8A7743
> bool "RZ/G1M (R8A77430)"
> select ARCH_RCAR_GEN2
> + select ARM_ERRATA_798181 if SMP
>
> config ARCH_R8A7778
> bool "R-Car M1A (R8A77781)"
> @@ -82,20 +84,24 @@ config ARCH_R8A7779
> config ARCH_R8A7790
> bool "R-Car H2 (R8A77900)"
> select ARCH_RCAR_GEN2
> + select ARM_ERRATA_798181 if SMP
> select I2C
Thanks for your help.
I'm probably misunderstanding what this patch does and how the errata
effects the system, but the commit message says CA15 cores. The above
R-Car Gen1 and r8a7740 SoCs are not using CA15 - instead they use CA9.
Not sure if the errata still applies though.
So either the commit message or the list of the SoCs need to be updated.
Thanks,
/ magnus
^ permalink raw reply
* [PATCH] Revert "gpio/mvebu: convert to use irq_domain_add_simple()"
From: Gregory CLEMENT @ 2016-10-27 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdatYim3=tKeO-E1GazB7RV9XPdE-EBQs+FW+DrryATzRA@mail.gmail.com>
Hi Linus,
On lun., oct. 24 2016, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Oct 19, 2016 at 11:03 PM, Jason Gunthorpe
> <jgunthorpe@obsidianresearch.com> wrote:
>
>> From 7566f05ac445b652ba7607cc1899fed10fea1c76 Mon Sep 17 00:00:00 2001
>> From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>> Date: Wed, 19 Oct 2016 14:57:45 -0600
>> Subject: [PATCH] gpio/mvebu: Use irq_domain_add_linear
>>
>> This fixes the irq allocation in this driver to not print:
>> irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
>> irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated
>>
>> Which happens because the driver already called irq_alloc_descs()
>> and so the change to use irq_domain_add_simple resulted in calling
>> irq_alloc_descs() twice.
>>
>> Modernize the irq allocation in this driver to use the
>> irq_domain_add_linear flow directly and eliminate the use of
>> irq_domain_add_simple/legacy
>>
>> Fixes: ce931f571b6d ("gpio/mvebu: convert to use irq_domain_add_simple()")
>> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>
> So can I just apply this?
> Gregory?
For me it's OK.
Gregory
>
> Yours,
> Linus Walleij
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: shmobile: select errata 798181 for SoCs with CA15 cores
From: Geert Uytterhoeven @ 2016-10-27 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANqRtoSsKTvMjATz89nEY06Fp-J20VqjDzW0JD1NDLqEJQPwsQ@mail.gmail.com>
Hi Magnus,
On Thu, Oct 27, 2016 at 9:28 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> On Thu, Oct 27, 2016 at 4:00 PM, Simon Horman
> <horms+renesas@verge.net.au> wrote:
>> Select ARM errata 798181 on SoCs cores affected CA15 cores.
>>
>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>> ---
>> arch/arm/mach-shmobile/Kconfig | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
>> index c48be1d332ed..6fbd9b7d2d67 100644
>> --- a/arch/arm/mach-shmobile/Kconfig
>> +++ b/arch/arm/mach-shmobile/Kconfig
>> @@ -60,6 +60,7 @@ config ARCH_R7S72100
>> config ARCH_R8A73A4
>> bool "R-Mobile APE6 (R8A73A40)"
>> select ARCH_RMOBILE
>> + select ARM_ERRATA_798181 if SMP
>> select RENESAS_IRQC
>>
>> config ARCH_R8A7740
>> @@ -70,6 +71,7 @@ config ARCH_R8A7740
>> config ARCH_R8A7743
>> bool "RZ/G1M (R8A77430)"
>> select ARCH_RCAR_GEN2
>> + select ARM_ERRATA_798181 if SMP
>>
>> config ARCH_R8A7778
>> bool "R-Car M1A (R8A77781)"
>> @@ -82,20 +84,24 @@ config ARCH_R8A7779
>> config ARCH_R8A7790
>> bool "R-Car H2 (R8A77900)"
>> select ARCH_RCAR_GEN2
>> + select ARM_ERRATA_798181 if SMP
>> select I2C
>
> Thanks for your help.
>
> I'm probably misunderstanding what this patch does and how the errata
> effects the system, but the commit message says CA15 cores. The above
> R-Car Gen1 and r8a7740 SoCs are not using CA15 - instead they use CA9.
> Not sure if the errata still applies though.
Please don't become misled by the @@ context ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 1/4] arm64: arch_timer: Add device tree binding for hisilicon-161601 erratum
From: Ding Tianhong @ 2016-10-27 7:34 UTC (permalink / raw)
To: linux-arm-kernel
This erratum describes a bug in logic outside the core, so MIDR can't be
used to identify its presence, and reading an SoC-specific revision
register from common arch timer code would be awkward. So, describe it
in the device tree.
v2: Use the new erratum name and update the description.
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
index ef5fbe9..c27b2c4 100644
--- a/Documentation/devicetree/bindings/arm/arch_timer.txt
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -31,6 +31,14 @@ to deliver its interrupts via SPIs.
This also affects writes to the tval register, due to the implicit
counter read.
+- hisilicon,erratum-161601 : A boolean property. Indicates the presence of
+ erratum 161601, which says that reading the counter is unreliable unless
+ reading twice on the register and the value of the second read is larger
+ than the first by less than 32. If the verification is unsuccessful, then
+ discard the value of this read and repeat this procedure until the verification
+ is successful. This also affects writes to the tval register, due to the
+ implicit counter read.
+
** Optional properties:
- arm,cpu-registers-not-fw-configured : Firmware does not initialize
--
1.9.0
^ permalink raw reply related
* [PATCH v2 2/4] arm64: arch_timer: Introduce a generic erratum handing mechanism for fsl-a008585
From: Ding Tianhong @ 2016-10-27 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477553651-13428-1-git-send-email-dingtianhong@huawei.com>
The workaround for hisilicon,161601 will check the return value of the system counter
by different way, in order to distinguish with the fsl-a008585 workaround, introduce
a new generic erratum handing mechanism for fsl-a008585 and rename some functions.
v2: Introducing a new generic erratum handling mechanism for fsl erratum a008585.
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
arch/arm64/include/asm/arch_timer.h | 20 +++++++++-----
drivers/clocksource/arm_arch_timer.c | 51 +++++++++++++++++++++---------------
2 files changed, 43 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
index eaa5bbe..118719d8 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -31,15 +31,21 @@
#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
extern struct static_key_false arch_timer_read_ool_enabled;
-#define needs_fsl_a008585_workaround() \
+#define needs_timer_erratum_workaround() \
static_branch_unlikely(&arch_timer_read_ool_enabled)
#else
-#define needs_fsl_a008585_workaround() false
+#define needs_timer_erratum_workaround() false
#endif
-u32 __fsl_a008585_read_cntp_tval_el0(void);
-u32 __fsl_a008585_read_cntv_tval_el0(void);
-u64 __fsl_a008585_read_cntvct_el0(void);
+
+struct arch_timer_erratum_workaround {
+ int erratum;
+ u32 (*read_cntp_tval_el0)(void);
+ u32 (*read_cntv_tval_el0)(void);
+ u64 (*read_cntvct_el0)(void);
+};
+
+extern struct arch_timer_erratum_workaround *erratum_workaround;
/*
* The number of retries is an arbitrary value well beyond the highest number
@@ -62,8 +68,8 @@ u64 __fsl_a008585_read_cntvct_el0(void);
#define arch_timer_reg_read_stable(reg) \
({ \
u64 _val; \
- if (needs_fsl_a008585_workaround()) \
- _val = __fsl_a008585_read_##reg(); \
+ if (needs_timer_erratum_workaround()) \
+ _val = erratum_workaround->read_##reg(); \
else \
_val = read_sysreg(reg); \
_val; \
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 73c487d..e4f7fa1 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -95,10 +95,32 @@ early_param("clocksource.arm_arch_timer.evtstrm", early_evtstrm_cfg);
*/
#ifdef CONFIG_FSL_ERRATUM_A008585
+struct arch_timer_erratum_workaround *erratum_workaround = NULL;
+
DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled);
EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
-static int fsl_a008585_enable = -1;
+
+static u32 fsl_a008585_read_cntp_tval_el0(void)
+{
+ return __fsl_a008585_read_reg(cntp_tval_el0);
+}
+
+static u32 fsl_a008585_read_cntv_tval_el0(void)
+{
+ return __fsl_a008585_read_reg(cntv_tval_el0);
+}
+
+static u64 fsl_a008585_read_cntvct_el0(void)
+{
+ return __fsl_a008585_read_reg(cntvct_el0);
+}
+
+static struct arch_timer_erratum_workaround arch_timer_fsl_a008585 = {
+ .read_cntp_tval_el0 = fsl_a008585_read_cntp_tval_el0,
+ .read_cntv_tval_el0 = fsl_a008585_read_cntv_tval_el0,
+ .read_cntvct_el0 = fsl_a008585_read_cntvct_el0,
+};
static int __init early_fsl_a008585_cfg(char *buf)
{
@@ -109,26 +131,12 @@ static int __init early_fsl_a008585_cfg(char *buf)
if (ret)
return ret;
- fsl_a008585_enable = val;
+ if (val)
+ erratum_workaround = &arch_timer_fsl_a008585;
+
return 0;
}
early_param("clocksource.arm_arch_timer.fsl-a008585", early_fsl_a008585_cfg);
-
-u32 __fsl_a008585_read_cntp_tval_el0(void)
-{
- return __fsl_a008585_read_reg(cntp_tval_el0);
-}
-
-u32 __fsl_a008585_read_cntv_tval_el0(void)
-{
- return __fsl_a008585_read_reg(cntv_tval_el0);
-}
-
-u64 __fsl_a008585_read_cntvct_el0(void)
-{
- return __fsl_a008585_read_reg(cntvct_el0);
-}
-EXPORT_SYMBOL(__fsl_a008585_read_cntvct_el0);
#endif /* CONFIG_FSL_ERRATUM_A008585 */
static __always_inline
@@ -891,9 +899,10 @@ static int __init arch_timer_of_init(struct device_node *np)
arch_timer_c3stop = !of_property_read_bool(np, "always-on");
#ifdef CONFIG_FSL_ERRATUM_A008585
- if (fsl_a008585_enable < 0)
- fsl_a008585_enable = of_property_read_bool(np, "fsl,erratum-a008585");
- if (fsl_a008585_enable) {
+ if (!erratum_workaround && of_property_read_bool(np, "fsl,erratum-a008585"))
+ erratum_workaround = &arch_timer_fsl_a008585;
+
+ if (erratum_workaround) {
static_branch_enable(&arch_timer_read_ool_enabled);
pr_info("Enabling workaround for FSL erratum A-008585\n");
}
--
1.9.0
^ permalink raw reply related
* [PATCH v2 3/4] arm64: arch_timer: Work around Erratum Hisilicon-161601
From: Ding Tianhong @ 2016-10-27 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477553651-13428-1-git-send-email-dingtianhong@huawei.com>
Erratum Hisilicon-161601 says that the ARM generic timer counter "has the
potential to contain an erroneous value when the timer value changes".
Accesses to TVAL (both read and write) are also affected due to the implicit counter
read. Accesses to CVAL are not affected.
The workaround is to reread the system count registers until the value of the second
read is larger than the first one by less than 32, the system counter can be guaranteed
not to return wrong value twice by back-to-back read and the error value is always larger
than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL.
The workaround is enabled if the hisilicon,erratum-161601 property is found in
the timer node in the device tree. This can be overridden with the
clocksource.arm_arch_timer.hisilicon-161601 boot parameter, which allows KVM
users to enable the workaround until a mechanism is implemented to
automatically communicate this information.
Fix some description for fsl erratum a008585.
v2: Significant rework based on feedback, including seperate the fsl erratum a008585
to another patch, update the erratum name and remove unwanted code.
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
Documentation/arm64/silicon-errata.txt | 1 +
Documentation/kernel-parameters.txt | 9 ++++
arch/arm64/include/asm/arch_timer.h | 28 ++++++++++-
drivers/clocksource/Kconfig | 14 +++++-
drivers/clocksource/arm_arch_timer.c | 88 ++++++++++++++++++++++++++--------
5 files changed, 118 insertions(+), 22 deletions(-)
diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index 405da11..70c5d5e 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -63,3 +63,4 @@ stable kernels.
| Cavium | ThunderX SMMUv2 | #27704 | N/A |
| | | | |
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
+| Hisilicon | Hip05/Hip06/Hip07 | #161601 | HISILICON_ERRATUM_161601|
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 6fa1d8a..735b4b6 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -707,6 +707,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
erratum. If unspecified, the workaround is
enabled based on the device tree.
+ clocksource.arm_arch_timer.hisilicon-161601=
+ [ARM64]
+ Format: <bool>
+ Enable/disable the workaround of Hisilicon
+ erratum 161601. This can be useful for KVM
+ guests, if the guest device tree doesn't show the
+ erratum. If unspecified, the workaround is
+ enabled based on the device tree.
+
clearcpuid=BITNUM [X86]
Disable CPUID feature X for the kernel. See
arch/x86/include/asm/cpufeatures.h for the valid bit
diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
index 118719d8..49b3041 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -29,7 +29,7 @@
#include <clocksource/arm_arch_timer.h>
-#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
+#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
extern struct static_key_false arch_timer_read_ool_enabled;
#define needs_timer_erratum_workaround() \
static_branch_unlikely(&arch_timer_read_ool_enabled)
@@ -65,11 +65,35 @@ extern struct arch_timer_erratum_workaround *erratum_workaround;
_new; \
})
+
+
+/*
+ * The number of retries is an arbitrary value well beyond the highest number
+ * of iterations the loop has been observed to take.
+ * Verify whether the value of the second read is larger than the first by
+ * less than 32 is the only way to confirm the value is correct, the system
+ * counter can be guaranteed not to return wrong value twice by back-to-back read
+ * and the error value is always larger than the correct one by 32.
+ */
+#define __hisi_161601_read_reg(reg) ({ \
+ u64 _old, _new; \
+ int _retries = 200; \
+ \
+ do { \
+ _old = read_sysreg(reg); \
+ _new = read_sysreg(reg); \
+ _retries--; \
+ } while (unlikely((_new - _old) >> 5) && _retries); \
+ \
+ WARN_ON_ONCE(!_retries); \
+ _new; \
+})
+
#define arch_timer_reg_read_stable(reg) \
({ \
u64 _val; \
if (needs_timer_erratum_workaround()) \
- _val = erratum_workaround->read_##reg(); \
+ _val = erratum_workaround->read_##reg();\
else \
_val = read_sysreg(reg); \
_val; \
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 8a753fd..4aafb6a 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -312,8 +312,20 @@ config FSL_ERRATUM_A008585
help
This option enables a workaround for Freescale/NXP Erratum
A-008585 ("ARM generic timer may contain an erroneous
- value"). The workaround will only be active if the
+ value"). The workaround will be active if the
fsl,erratum-a008585 property is found in the timer node.
+ This can be overridden with the clocksource.arm_arch_timer.fsl-a008585
+ boot parameter.
+
+config HISILICON_ERRATUM_161601
+ bool "Workaround for Hisilicon Erratum 161601"
+ default y
+ depends on ARM_ARCH_TIMER && ARM64
+ help
+ This option enables a workaround for Hisilicon Erratum
+ 161601. The workaround will be active if the hisilicon,erratum-161601
+ property is found in the timer node. This can be overridden with
+ the clocksource.arm_arch_timer.hisilicon-161601 boot parameter.
config ARM_GLOBAL_TIMER
bool "Support for the ARM global timer" if COMPILE_TEST
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index e4f7fa1..89f1895 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -94,13 +94,14 @@ early_param("clocksource.arm_arch_timer.evtstrm", early_evtstrm_cfg);
* Architected system timer support.
*/
-#ifdef CONFIG_FSL_ERRATUM_A008585
+#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
struct arch_timer_erratum_workaround *erratum_workaround = NULL;
DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled);
EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
+#endif
-
+#ifdef CONFIG_FSL_ERRATUM_A008585
static u32 fsl_a008585_read_cntp_tval_el0(void)
{
return __fsl_a008585_read_reg(cntp_tval_el0);
@@ -139,6 +140,45 @@ static int __init early_fsl_a008585_cfg(char *buf)
early_param("clocksource.arm_arch_timer.fsl-a008585", early_fsl_a008585_cfg);
#endif /* CONFIG_FSL_ERRATUM_A008585 */
+#ifdef CONFIG_HISILICON_ERRATUM_161601
+static u32 hisi_161601_read_cntp_tval_el0(void)
+{
+ return __hisi_161601_read_reg(cntp_tval_el0);
+}
+
+static u32 hisi_161601_read_cntv_tval_el0(void)
+{
+ return __hisi_161601_read_reg(cntv_tval_el0);
+}
+
+static u64 hisi_161601_read_cntvct_el0(void)
+{
+ return __hisi_161601_read_reg(cntvct_el0);
+}
+
+static struct arch_timer_erratum_workaround arch_timer_hisi_161601 = {
+ .read_cntp_tval_el0 = hisi_161601_read_cntp_tval_el0,
+ .read_cntv_tval_el0 = hisi_161601_read_cntv_tval_el0,
+ .read_cntvct_el0 = hisi_161601_read_cntvct_el0,
+};
+
+static int __init early_hisi_161601_cfg(char *buf)
+{
+ int ret;
+ bool val;
+
+ ret = strtobool(buf, &val);
+ if (ret)
+ return ret;
+
+ if (val)
+ erratum_workaround = &arch_timer_hisi_161601;
+
+ return 0;
+}
+early_param("clocksource.arm_arch_timer.hisilicon-161601", early_hisi_161601_cfg);
+#endif /* CONFIG_HISILICON_ERRATUM_161601 */
+
static __always_inline
void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val,
struct clock_event_device *clk)
@@ -288,8 +328,8 @@ static __always_inline void set_next_event(const int access, unsigned long evt,
arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
}
-#ifdef CONFIG_FSL_ERRATUM_A008585
-static __always_inline void fsl_a008585_set_next_event(const int access,
+#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
+static __always_inline void erratum_set_next_event(const int access,
unsigned long evt, struct clock_event_device *clk)
{
unsigned long ctrl;
@@ -307,20 +347,20 @@ static __always_inline void fsl_a008585_set_next_event(const int access,
arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
}
-static int fsl_a008585_set_next_event_virt(unsigned long evt,
+static int erratum_set_next_event_virt(unsigned long evt,
struct clock_event_device *clk)
{
- fsl_a008585_set_next_event(ARCH_TIMER_VIRT_ACCESS, evt, clk);
+ erratum_set_next_event(ARCH_TIMER_VIRT_ACCESS, evt, clk);
return 0;
}
-static int fsl_a008585_set_next_event_phys(unsigned long evt,
+static int erratum_set_next_event_phys(unsigned long evt,
struct clock_event_device *clk)
{
- fsl_a008585_set_next_event(ARCH_TIMER_PHYS_ACCESS, evt, clk);
+ erratum_set_next_event(ARCH_TIMER_PHYS_ACCESS, evt, clk);
return 0;
}
-#endif /* CONFIG_FSL_ERRATUM_A008585 */
+#endif
static int arch_timer_set_next_event_virt(unsigned long evt,
struct clock_event_device *clk)
@@ -350,16 +390,16 @@ static int arch_timer_set_next_event_phys_mem(unsigned long evt,
return 0;
}
-static void fsl_a008585_set_sne(struct clock_event_device *clk)
+static void erratum_set_sne(struct clock_event_device *clk)
{
-#ifdef CONFIG_FSL_ERRATUM_A008585
+#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
return;
if (arch_timer_uses_ppi == VIRT_PPI)
- clk->set_next_event = fsl_a008585_set_next_event_virt;
+ clk->set_next_event = erratum_set_next_event_virt;
else
- clk->set_next_event = fsl_a008585_set_next_event_phys;
+ clk->set_next_event = erratum_set_next_event_phys;
#endif
}
@@ -392,7 +432,7 @@ static void __arch_timer_setup(unsigned type,
BUG();
}
- fsl_a008585_set_sne(clk);
+ erratum_set_sne(clk);
} else {
clk->features |= CLOCK_EVT_FEAT_DYNIRQ;
clk->name = "arch_mem_timer";
@@ -612,7 +652,7 @@ static void __init arch_counter_register(unsigned type)
clocksource_counter.archdata.vdso_direct = true;
-#ifdef CONFIG_FSL_ERRATUM_A008585
+#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
/*
* Don't use the vdso fastpath if errata require using
* the out-of-line counter accessor.
@@ -899,12 +939,22 @@ static int __init arch_timer_of_init(struct device_node *np)
arch_timer_c3stop = !of_property_read_bool(np, "always-on");
#ifdef CONFIG_FSL_ERRATUM_A008585
- if (!erratum_workaround && of_property_read_bool(np, "fsl,erratum-a008585"))
+ if (!erratum_workaround && of_property_read_bool(np, "fsl,erratum-a008585")) {
erratum_workaround = &arch_timer_fsl_a008585;
+ if (erratum_workaround) {
+ static_branch_enable(&arch_timer_read_ool_enabled);
+ pr_info("Enabling workaround for FSL erratum A-008585\n");
+ }
+ }
+#endif
- if (erratum_workaround) {
- static_branch_enable(&arch_timer_read_ool_enabled);
- pr_info("Enabling workaround for FSL erratum A-008585\n");
+#ifdef CONFIG_HISILICON_ERRATUM_161601
+ if (!erratum_workaround && of_property_read_bool(np, "hisilicon,erratum-161601")) {
+ erratum_workaround = &arch_timer_hisi_161601;
+ if (erratum_workaround) {
+ static_branch_enable(&arch_timer_read_ool_enabled);
+ pr_info("Enabling workaround for HISILICON erratum 161601\n");
+ }
}
#endif
--
1.9.0
^ permalink raw reply related
* [PATCH v2 4/4] arm64: arch timer: Add timer erratum property for Hip05-d02 and Hip06-d03
From: Ding Tianhong @ 2016-10-27 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477553651-13428-1-git-send-email-dingtianhong@huawei.com>
Enable workaround for hisilicon erratum 161601 on Hip05-d02 and Hip06-d03 board.
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 +
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
index bf322ed..f815d94 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
@@ -281,6 +281,7 @@
<GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
<GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
<GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ hisilicon,erratum-161601;
};
pmu {
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index 5927bc4..d63990b 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -260,6 +260,7 @@
<GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
<GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
<GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ hisilicon,erratum-161601;
};
pmu {
--
1.9.0
^ permalink raw reply related
* [PATCH] arm64: defconfig: Enable DRM DU and V4L2 FCP + VSP modules
From: Magnus Damm @ 2016-10-27 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027071523.GD7706@verge.net.au>
Hi Simon,
On Thu, Oct 27, 2016 at 4:15 PM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Oct 27, 2016 at 09:08:01AM +0200, Simon Horman wrote:
>> On Wed, Oct 26, 2016 at 02:24:22PM +0900, Magnus Damm wrote:
>> > From: Magnus Damm <damm+renesas@opensource.se>
>> >
>> > Extend the ARM64 defconfig to enable the DU DRM device as module
>> > together with required dependencies of V4L2 FCP and VSP modules.
>> >
>> > This enables VGA output on the r8a7795 Salvator-X board.
>> >
>> > Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
>>
>> Thanks, I have queued this up.
>
> Given discussion elsewhere on enabling DU I am holding off on this for a
> little; it is not queued up for now.
Sure, thanks for holding off the DT integration patches for r8a7796.
Please note that as of mainline v4.9-rc2 the r8a7795 Salvator-X board
has thanks to DU, FCP and VSP a working VGA port. So enabling those
devices in the defconfig from now on makes sense to me.
Cheers,
/ magnus
^ permalink raw reply
* [PATCH] ARM: shmobile: select errata 798181 for SoCs with CA15 cores
From: Magnus Damm @ 2016-10-27 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVKwg0SzEmu804UxTEE+N4atYjeKHNfCJ0eXf28fL+KJA@mail.gmail.com>
Hi Geert and Simon,
On Thu, Oct 27, 2016 at 4:33 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Magnus,
>
> On Thu, Oct 27, 2016 at 9:28 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
>> On Thu, Oct 27, 2016 at 4:00 PM, Simon Horman
>> <horms+renesas@verge.net.au> wrote:
>>> Select ARM errata 798181 on SoCs cores affected CA15 cores.
>>>
>>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>>> ---
>>> arch/arm/mach-shmobile/Kconfig | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
>>> index c48be1d332ed..6fbd9b7d2d67 100644
>>> --- a/arch/arm/mach-shmobile/Kconfig
>>> +++ b/arch/arm/mach-shmobile/Kconfig
>>> @@ -60,6 +60,7 @@ config ARCH_R7S72100
>>> config ARCH_R8A73A4
>>> bool "R-Mobile APE6 (R8A73A40)"
>>> select ARCH_RMOBILE
>>> + select ARM_ERRATA_798181 if SMP
>>> select RENESAS_IRQC
>>>
>>> config ARCH_R8A7740
>>> @@ -70,6 +71,7 @@ config ARCH_R8A7740
>>> config ARCH_R8A7743
>>> bool "RZ/G1M (R8A77430)"
>>> select ARCH_RCAR_GEN2
>>> + select ARM_ERRATA_798181 if SMP
>>>
>>> config ARCH_R8A7778
>>> bool "R-Car M1A (R8A77781)"
>>> @@ -82,20 +84,24 @@ config ARCH_R8A7779
>>> config ARCH_R8A7790
>>> bool "R-Car H2 (R8A77900)"
>>> select ARCH_RCAR_GEN2
>>> + select ARM_ERRATA_798181 if SMP
>>> select I2C
>>
>> Thanks for your help.
>>
>> I'm probably misunderstanding what this patch does and how the errata
>> effects the system, but the commit message says CA15 cores. The above
>> R-Car Gen1 and r8a7740 SoCs are not using CA15 - instead they use CA9.
>> Not sure if the errata still applies though.
>
> Please don't become misled by the @@ context ;-)
Ouch, right... Sorry for the noise. The patch looks good, please proceed.
Thanks,
/ magnus
^ 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