* [v2 PATCH 1/6] usb: mtu3: fix error code for getting extcon device
From: Chunfeng Yun @ 2018-01-03 8:53 UTC (permalink / raw)
To: linux-arm-kernel
When failing to get extcon device, extcon_get_edev_by_phandle()
may return different error codes, but not only -EPROBE_DEFER,
so can't always return -EPROBE_DEFER, and fix it.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3_plat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 3650fd1..5b2110b 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -308,7 +308,7 @@ static int get_ssusb_rscs(struct platform_device *pdev, struct ssusb_mtk *ssusb)
otg_sx->edev = extcon_get_edev_by_phandle(ssusb->dev, 0);
if (IS_ERR(otg_sx->edev)) {
dev_err(ssusb->dev, "couldn't get extcon device\n");
- return -EPROBE_DEFER;
+ return PTR_ERR(otg_sx->edev);
}
}
--
1.9.1
^ permalink raw reply related
* [PATCH RESEND] phy: sun4i-usb: add support for R40 USB PHY
From: Icenowy Zheng @ 2018-01-03 8:49 UTC (permalink / raw)
To: linux-arm-kernel
Allwinner R40 features a USB PHY like the one in A64, but with 3 PHYs.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
---
When resending, the ACK's by Maxime and Rob are added.
Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
drivers/phy/allwinner/phy-sun4i-usb.c | 12 ++++++++++++
2 files changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index c1ce5a0a652e..07ca4ec4a745 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -11,6 +11,7 @@ Required properties:
* allwinner,sun8i-a33-usb-phy
* allwinner,sun8i-a83t-usb-phy
* allwinner,sun8i-h3-usb-phy
+ * allwinner,sun8i-r40-usb-phy
* allwinner,sun8i-v3s-usb-phy
* allwinner,sun50i-a64-usb-phy
- reg : a list of offset + length pairs
diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c
index aa857be692cf..bee798892b21 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -112,6 +112,7 @@ enum sun4i_usb_phy_type {
sun8i_a33_phy,
sun8i_a83t_phy,
sun8i_h3_phy,
+ sun8i_r40_phy,
sun8i_v3s_phy,
sun50i_a64_phy,
};
@@ -919,6 +920,16 @@ static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
.phy0_dual_route = true,
};
+static const struct sun4i_usb_phy_cfg sun8i_r40_cfg = {
+ .num_phys = 3,
+ .type = sun8i_r40_phy,
+ .disc_thresh = 3,
+ .phyctl_offset = REG_PHYCTL_A33,
+ .dedicated_clocks = true,
+ .enable_pmu_unk1 = true,
+ .phy0_dual_route = true,
+};
+
static const struct sun4i_usb_phy_cfg sun8i_v3s_cfg = {
.num_phys = 1,
.type = sun8i_v3s_phy,
@@ -948,6 +959,7 @@ static const struct of_device_id sun4i_usb_phy_of_match[] = {
{ .compatible = "allwinner,sun8i-a33-usb-phy", .data = &sun8i_a33_cfg },
{ .compatible = "allwinner,sun8i-a83t-usb-phy", .data = &sun8i_a83t_cfg },
{ .compatible = "allwinner,sun8i-h3-usb-phy", .data = &sun8i_h3_cfg },
+ { .compatible = "allwinner,sun8i-r40-usb-phy", .data = &sun8i_r40_cfg },
{ .compatible = "allwinner,sun8i-v3s-usb-phy", .data = &sun8i_v3s_cfg },
{ .compatible = "allwinner,sun50i-a64-usb-phy",
.data = &sun50i_a64_cfg},
--
2.14.2
^ permalink raw reply related
* [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
From: vkilari at codeaurora.org @ 2018-01-03 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0hBZQ-vYbobOYtKFVg9hAtUo4GU==napcJ-btQhMvn+5g@mail.gmail.com>
Hi Jeremy,
Sorry, I don't have your previous patch emails to reply on right patch
context.
So commenting on top of this patch.
AFAIU, the PPTT v5 patches still rely on CLIDR_EL1 register to know the type
of
Caches enabled/available on the platform. With PPTT, it should not rely on
architecture
registers. There can be platforms which can report cache availability in
PPTT but not in
architecture registers.
The following code snippet shows usage of CLIDR_EL1
In arch/arm64/kernel/cacheinfo.c
static inline enum cache_type get_cache_type(int level)
{
u64 clidr;
if (level > MAX_CACHE_LEVEL)
return CACHE_TYPE_NOCACHE;
clidr = read_sysreg(clidr_el1);
return CLIDR_CTYPE(clidr, level);
}
static int __populate_cache_leaves(unsigned int cpu)
{
unsigned int level, idx;
enum cache_type type;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
struct cacheinfo *this_leaf = this_cpu_ci->info_list;
for (idx = 0, level = 1; level <= this_cpu_ci->num_levels &&
idx < this_cpu_ci->num_leaves; idx++, level++) {
type = get_cache_type(level);
if (type == CACHE_TYPE_SEPARATE) {
ci_leaf_init(this_leaf++, CACHE_TYPE_DATA, level);
ci_leaf_init(this_leaf++, CACHE_TYPE_INST, level);
} else {
ci_leaf_init(this_leaf++, type, level);
}
}
return 0;
}
In populate_cache_leaves() the cache type is read from CLIDR_EL1 register.
If CLIDR_EL1 reports CACHE_TYPE_NOCACHE for a particular level then sysfs
entry
/sys/devices/system/cpu/cpu0/index<n>/type is not created and hence
userspace tools
like lstopo will not report this cache level.
Regards
Vijay
> -----Original Message-----
> From: linux-arm-kernel
[mailto:linux-arm-kernel-bounces at lists.infradead.org]
> On Behalf Of Rafael J. Wysocki
> Sent: Thursday, December 14, 2017 4:40 AM
> To: Jeremy Linton <jeremy.linton@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>; Jonathan.Zhang at cavium.com;
> Jayachandran.Nair at cavium.com; Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com>; Catalin Marinas <catalin.marinas@arm.com>;
> Rafael J. Wysocki <rafael@kernel.org>; jhugo at codeaurora.org; Will Deacon
> <will.deacon@arm.com>; Linux PM <linux-pm@vger.kernel.org>; Rafael J.
> Wysocki <rjw@rjwysocki.net>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Linux Kernel Mailing List <linux-
> kernel at vger.kernel.org>; ACPI Devel Maling List
<linux-acpi@vger.kernel.org>;
> Viresh Kumar <viresh.kumar@linaro.org>; Hanjun Guo
> <hanjun.guo@linaro.org>; Al Stone <ahs3@redhat.com>; Sudeep Holla
> <sudeep.holla@arm.com>; austinwc at codeaurora.org;
> wangxiongfeng2 at huawei.com; linux-arm-kernel at lists.infradead.org; Len
> Brown <lenb@kernel.org>
> Subject: Re: [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
>
> On Thu, Dec 14, 2017 at 12:06 AM, Jeremy Linton <jeremy.linton@arm.com>
> wrote:
> > Hi,
> >
> >
> > On 12/13/2017 04:28 PM, Rafael J. Wysocki wrote:
> >>
> >> On Wed, Dec 13, 2017 at 6:38 PM, Lorenzo Pieralisi
> >> <lorenzo.pieralisi@arm.com> wrote:
> >>>
> >>> On Tue, Dec 12, 2017 at 10:13:08AM -0600, Jeremy Linton wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> First, thanks for taking a look at this.
> >>>>
> >>>> On 12/11/2017 07:12 PM, Rafael J. Wysocki wrote:
> >>>>>
> >>>>> On Friday, December 1, 2017 11:23:27 PM CET Jeremy Linton wrote:
> >>>>>>
> >>>>>> The PPTT can be used to determine the groupings of CPU's at given
> >>>>>> levels in the system. Lets add a few routines to the PPTT parsing
> >>>>>> code to return a unique id for each unique level in the processor
> >>>>>> hierarchy. This can then be matched to build
> >>>>>> thread/core/cluster/die/package/etc mappings for each processing
> >>>>>> element in the system.
> >>>>>>
> >>>>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> >>>>>
> >>>>>
> >>>>> Why can't this be folded into patch [2/9]?
> >>>>
> >>>>
> >>>> It can, and I will be happy squash it.
> >>>>
> >>>> It was requested that the topology portion of the parser be split
> >>>> out back in v3.
> >>>>
> >>>> https://www.spinics.net/lists/linux-acpi/msg78487.html
> >>>
> >>>
> >>> I asked to split cache/topology since I am not familiar with cache
> >>> code and Sudeep - who looks after the cache code - won't be able to
> >>> review this series in time for v4.16.
> >>
> >>
> >> OK, so why do we need it in 4.16?
> >
> >
> > I think its more case of as soon as possible. That is because there
> > are machines where the topology is completely incorrect due to
> > assumptions the kernel makes based on registers that aren't defined
> > for that purpose (say describing which cores are in a physical socket,
> > or LLC's attached to interconnects or memory controllers).
> >
> > This incorrect topology information is reported to things like the
> > kernel scheduler, which then makes poor scheduling decisions resulting
> > in sub-optimal system performance.
> >
> > This patchset (and ACPI 6.2) clears up a lot of those problems.
>
> As long as the ACPI tables are as expected that is, I suppose?
>
> Anyway, fair enough, but I don't want to rush it in.
>
> Thanks,
> Rafael
>
> _______________________________________________
> 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] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
From: Marc Zyngier @ 2018-01-03 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103063224.9965-1-ganapatrao.kulkarni@cavium.com>
On 03/01/18 06:32, Ganapatrao Kulkarni wrote:
> When an interrupt is moved across node collections on ThunderX2
node collections?
> multi Socket platform, an interrupt stops routed to new collection
> and results in loss of interrupts.
>
> Adding workaround to issue INV after MOVI for cross-node collection
> move to flush out the cached entry.
>
> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
> ---
> Documentation/arm64/silicon-errata.txt | 1 +
> arch/arm64/Kconfig | 11 +++++++++++
> drivers/irqchip/irq-gic-v3-its.c | 24 ++++++++++++++++++++++++
> 3 files changed, 36 insertions(+)
>
> diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
> index fc1c884..fb27cb5 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -63,6 +63,7 @@ stable kernels.
> | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
> | Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
> | Cavium | ThunderX SMMUv2 | #27704 | N/A |
> +| Cavium | ThunderX2 ITS | #174 | CAVIUM_ERRATUM_174 |
> | Cavium | ThunderX2 SMMUv3| #74 | N/A |
> | Cavium | ThunderX2 SMMUv3| #126 | N/A |
> | | | | |
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index c9a7e9e..71a7e30 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419
>
> If unsure, say Y.
>
> +config CAVIUM_ERRATUM_174
> + bool "Cavium ThunderX2 erratum 174"
> + depends on NUMA
Why? This system will be affected no matter whether NUMA is selected or not.
> + default y
> + help
> + LPI stops routed to redistributors after inter node collection
> + move in ITS. Enable workaround to invalidate ITS entry after
> + inter-node collection move.
That's a very terse description. Nobody knows what an LPI, a
redistributor or a collection is. Please explain what the erratum is in
layman's terms (Cavium ThunderX2 systems may loose interrupts on
affinity change) so that people understand whether or not they are affected.
> +
> + If unsure, say Y.
> +
> config CAVIUM_ERRATUM_22375
> bool "Cavium erratum 22375, 24313"
> default y
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 06f025f..d8b9c96 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -46,6 +46,7 @@
> #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1ULL << 0)
> #define ITS_FLAGS_WORKAROUND_CAVIUM_22375 (1ULL << 1)
> #define ITS_FLAGS_WORKAROUND_CAVIUM_23144 (1ULL << 2)
> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174 (1ULL << 3)
>
> #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0)
>
> @@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
> if (cpu != its_dev->event_map.col_map[id]) {
> target_col = &its_dev->its->collections[cpu];
> its_send_movi(its_dev, target_col, id);
> + if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_174) {
> + /* Issue INV for cross node collection move. */
> + if (cpu_to_node(cpu) !=
> + cpu_to_node(its_dev->event_map.col_map[id]))
> + its_send_inv(its_dev, id);
> + }
What happens if an interrupt happens after the MOV, but before the INV?
> its_dev->event_map.col_map[id] = cpu;
> irq_data_update_effective_affinity(d, cpumask_of(cpu));
> }
> @@ -2904,6 +2911,15 @@ static int its_force_quiescent(void __iomem *base)
> }
> }
>
> +static bool __maybe_unused its_enable_quirk_cavium_174(void *data)
> +{
> + struct its_node *its = data;
> +
> + its->flags |= ITS_FLAGS_WORKAROUND_CAVIUM_174;
> +
> + return true;
> +}
> +
> static bool __maybe_unused its_enable_quirk_cavium_22375(void *data)
> {
> struct its_node *its = data;
> @@ -3031,6 +3047,14 @@ static const struct gic_quirk its_quirks[] = {
> .init = its_enable_quirk_hip07_161600802,
> },
> #endif
> +#ifdef CONFIG_CAVIUM_ERRATUM_174
> + {
> + .desc = "ITS: Cavium ThunderX2 erratum 174",
> + .iidr = 0x13f, /* ThunderX2 pass A1/A2/B0 */
Do all 3 revisions have the same IIDR?
> + .mask = 0xffffffff,
> + .init = its_enable_quirk_cavium_174,
> + },
> +#endif
> {
> }
> };
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 1/6] phy: sun4i-usb: add support for R40 USB PHY
From: Kishon Vijay Abraham I @ 2018-01-03 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4846846.1ddJIksgpP@ice-x220i>
Hi,
On Saturday 30 December 2017 05:08 PM, Icenowy Zheng wrote:
> ? 2017?10?18???? CST ??7:46:08?Kishon Vijay Abraham I ???
>> On Wednesday 18 October 2017 05:12 PM, Maxime Ripard wrote:
>>> On Wed, Oct 18, 2017 at 05:09:00PM +0530, Kishon Vijay Abraham I wrote:
>>>> Hi,
>>>>
>>>> On Tuesday 10 October 2017 02:28 AM, Maxime Ripard wrote:
>>>>> On Sun, Oct 08, 2017 at 04:29:01AM +0000, Icenowy Zheng wrote:
>>>>>> Allwinner R40 features a USB PHY like the one in A64, but with 3 PHYs.
>>>>>>
>>>>>> Add support for it.
>>>>>>
>>>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>>>
>>>>> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>>>
>>>> Is this patch good to be merged? I see you have pending comments on the
>>>> other patch in the series.
>>>
>>> Yeah, but I guess you can merge this one, it's pretty harmless, and it
>>> will reduce the amount of patches to review / merge later on.
>>
>> Thank you for the quick reply.
>>
>> merged with Maxime's and Rob's Ack.
>
> Sorry, but I didn't see the patch appears in linux-next for such long time.
>
> Is it lost?
yeah, looks like it. Can you post it again?
sorry about that :-/
Thanks
Kishon
^ permalink raw reply
* [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
From: Julian Calaby @ 2018-01-03 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWYDz_jHNxQ-B8944520R-myzHkjkL1rKWUjA38inU7cw@mail.gmail.com>
Hi All,
On Wed, Jan 3, 2018 at 6:49 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Michael,
>
> On Wed, Jan 3, 2018 at 7:24 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>>
>>> On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>>>> Christoph Hellwig <hch@lst.de> writes:
>>>>
>>>>> We want to use the dma_direct_ namespace for a generic implementation,
>>>>> so rename powerpc to the second best choice: dma_nommu_.
>>>>
>>>> I'm not a fan of "nommu". Some of the users of direct ops *are* using an
>>>> IOMMU, they're just setting up a 1:1 mapping once at init time, rather
>>>> than mapping dynamically.
>>>>
>>>> Though I don't have a good idea for a better name, maybe "1to1",
>>>> "linear", "premapped" ?
>>>
>>> "identity"?
>>
>> I think that would be wrong, but thanks for trying to help :)
>>
>> The address on the device side is sometimes (often?) offset from the CPU
>> address. So eg. the device can DMA to RAM address 0x0 using address
>> 0x800000000000000.
>>
>> Identity would imply 0 == 0 etc.
>>
>> I think "bijective" is the correct term, but that's probably a bit
>> esoteric.
>
> OK, didn't know about the offset.
> Then "linear" is what we tend to use, right?
If this is indeed a linear mapping, can we just remove this and
replace it with the new "generic" mapping being introduced by this
patchset?
Thanks,
--
Julian Calaby
Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* [PATCH] pinctrl: imx6ul: add IOMUXC SNVS pinctrl driver for i.MX 6ULL
From: Linus Walleij @ 2018-01-03 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102164059.14641-1-stefan@agner.ch>
On Tue, Jan 2, 2018 at 5:40 PM, Stefan Agner <stefan@agner.ch> wrote:
> From: Bai Ping <ping.bai@nxp.com>
>
> On i.MX 6ULL, the BOOT_MODEx and TAMPERx pin MUX and CTRL registers
> are available in a separate IOMUXC_SNVS module. Add support for the
> IOMUXC_SNVS module to the i.MX 6UL pinctrl driver.
>
> Signed-off-by: Bai Ping <ping.bai@nxp.com>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
So 6 unsigned long 32 bit is succeeded by 6 unsigned long long, 64 bit?
Someone is having fun naming these platforms I see.
> Required properties:
> -- compatible: "fsl,imx6ul-iomuxc"
> +- compatible: "fsl,imx6ul-iomuxc" for main IOMUX controller or
> + "fsl,imx6ull-iomuxc-snvs" for i.MX 6ULL's SNVS IOMUX controller.
Pretty uncontroversial change but still nice to give the DT people a chance
to ACK it.
> static int imx6ul_pinctrl_probe(struct platform_device *pdev)
> {
> - return imx_pinctrl_probe(pdev, &imx6ul_pinctrl_info);
> + const struct of_device_id *match;
> + struct imx_pinctrl_soc_info *pinctrl_info;
> +
> + match = of_match_device(imx6ul_pinctrl_of_match, &pdev->dev);
> +
> + if (!match)
> + return -ENODEV;
> +
> + pinctrl_info = (struct imx_pinctrl_soc_info *) match->data;
1. Do not use a cast on void * pointers.
2. Use this function:
extern const void *of_device_get_match_data(const struct device *dev);
>From <linux/of_device.h>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 05/12] pinctrl: armada-37xx: account for const type of of_device_id.data
From: Linus Walleij @ 2018-01-03 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514899688-27844-6-git-send-email-Julia.Lawall@lip6.fr>
On Tue, Jan 2, 2018 at 2:28 PM, Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> The data field of an of_device_id structure has type const void *, so
> there is no need for a const-discarding cast when putting const values
> into such a structure.
>
> Done using Coccinelle.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Patch applied with Gregory's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual OpenFrame Cap 7 initial support
From: Jagan Teki @ 2018-01-03 8:00 UTC (permalink / raw)
To: linux-arm-kernel
i.CoreM6 Quad/Dual OpenFrame modules are "system on modules plus
openframe display carriers" which are good solution for develop user
friendly graphic user interface.
ofcap 7 general features:
CPU NXP Freescale i.MX6Q rev1.5 at 792 MHz
RAM 1GB, 32, 64 bit, DDR3-800/1066
NAND SLC, 512MB
LVDS Display TFT 7" industrial, 800x480 resolution
Touchscreen EP0700M06 EDT Polytouch capacitive touch screen
Backlight LED backlight, brightness 300 Cd/m2
Power supply 15 to 30 Vdc
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-icore-ofcap7.dts | 100 +++++++++++++++++++++++++++++++
2 files changed, 101 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-icore-ofcap7.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0bb8db3..11d0544 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -451,6 +451,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-icore.dtb \
imx6q-icore-ofcap10.dtb \
imx6q-icore-ofcap12.dtb \
+ imx6q-icore-ofcap7.dtb \
imx6q-icore-rqs.dtb \
imx6q-marsboard.dtb \
imx6q-mccmon6.dtb \
diff --git a/arch/arm/boot/dts/imx6q-icore-ofcap7.dts b/arch/arm/boot/dts/imx6q-icore-ofcap7.dts
new file mode 100644
index 0000000..f0be682
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-icore-ofcap7.dts
@@ -0,0 +1,100 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-icore.dtsi"
+
+/ {
+ model = "Engicam i.CoreM6 Quad/Dual OpenFrame Capacitive touch 7 Kit";
+ compatible = "engicam,imx6-icore", "fsl,imx6q";
+
+ panel {
+ compatible = "ampire,am-800480aytzqw-00h";
+ backlight = <&backlight_lvds>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
+};
+
+&i2c3 {
+ ep0700m06: touchscreen at 38 {
+ compatible = "edt,edt-ft5406";
+ reg = <0x38>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_edt_ft5x06>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <30 IRQ_TYPE_NONE>;
+ reset-gpios = <&gpio6 0 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel at 0 {
+ reg = <0>;
+ status = "okay";
+
+ port at 4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl_edt_ft5x06: edt-ft5x06grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT12__GPIO5_IO30 0x1b0b0 /*interrupt*/
+ MX6QDL_PAD_CSI0_DAT14__GPIO6_IO00 0x1b0b0 /*reset edt*/
+ >;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 02/12] pinctrl: at91-pio4: account for const type of of_device_id.data
From: Linus Walleij @ 2018-01-03 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514899688-27844-3-git-send-email-Julia.Lawall@lip6.fr>
On Tue, Jan 2, 2018 at 2:27 PM, Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> This driver creates a const structure that it stores in the data field
> of an of_device_id array.
>
> Adding const to the declaration of the location that receives the
> const value from the data field ensures that the compiler will
> continue to check that the value is not modified. Furthermore, the
> const-discarding cast on the extraction from the data field is no
> longer needed.
>
> Done using Coccinelle.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
From: Geert Uytterhoeven @ 2018-01-03 7:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87h8s3cvel.fsf@concordia.ellerman.id.au>
Hi Michael,
On Wed, Jan 3, 2018 at 7:24 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>
>> On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>>> Christoph Hellwig <hch@lst.de> writes:
>>>
>>>> We want to use the dma_direct_ namespace for a generic implementation,
>>>> so rename powerpc to the second best choice: dma_nommu_.
>>>
>>> I'm not a fan of "nommu". Some of the users of direct ops *are* using an
>>> IOMMU, they're just setting up a 1:1 mapping once at init time, rather
>>> than mapping dynamically.
>>>
>>> Though I don't have a good idea for a better name, maybe "1to1",
>>> "linear", "premapped" ?
>>
>> "identity"?
>
> I think that would be wrong, but thanks for trying to help :)
>
> The address on the device side is sometimes (often?) offset from the CPU
> address. So eg. the device can DMA to RAM address 0x0 using address
> 0x800000000000000.
>
> Identity would imply 0 == 0 etc.
>
> I think "bijective" is the correct term, but that's probably a bit
> esoteric.
OK, didn't know about the offset.
Then "linear" is what we tend to use, right?
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 00/12] Marvell NAND controller rework with ->exec_op()
From: Miquel RAYNAL @ 2018-01-03 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d12scbiy.fsf@belgarion.home>
On Tue, 02 Jan 2018 20:21:09 +0100
Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Miquel RAYNAL <miquel.raynal@free-electrons.com> writes:
>
> > I think the ECC issue you faced was related to pages being written
> > *and* empty. If this guess is right, the board should boot fine with
> > these changes.
> >
> > Otherwise, please add the DEBUG define as before in both the core
> > and the driver and do not hesitate to add another dump_stack()
> > where it crashes (if applicable).
>
> The problem looks still the same :
> [ 3.560163] Bad block table not found for chip 0
Mmmmh ok.
Can you please add this patch:
http://code.bulix.org/61at9p-254626
Thanks,
Miqu?l
>
> Cheers.
>
> --
> Robert
>
^ permalink raw reply
* [PATCH] nokia N9: Add support for magnetometer and touchscreen
From: Filip Matijević @ 2018-01-03 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102172720.ghtez4d3d2fgcmj6@earth.universe>
Hi,
On 01/02/2018 06:27 PM, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Jan 02, 2018 at 02:17:22PM +0100, Pavel Machek wrote:
>> This adds dts support for magnetometer and touchscreen on Nokia N9.
>
> I think it makes sense to have this splitted.
>
>> Signed-off-by: Pavel Machek <pavel@ucw.cz>
>>
>> diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
>> index 39e35f8..57a6679 100644
>> --- a/arch/arm/boot/dts/omap3-n9.dts
>> +++ b/arch/arm/boot/dts/omap3-n9.dts
>> @@ -36,6 +57,22 @@
>> };
>> };
>> };
>> +
>> + touch at 4b {
>
> touchscreen@
>
>> + compatible = "atmel,maxtouch";
>> + reg = <0x4b>;
>> + interrupt-parent = <&gpio2>;
>> + interrupts = <29 2>; /* gpio_61, IRQF_TRIGGER_FALLING*/
>
> reset-gpios = <&gpio3 17 GPIO_ACTIVE_SOMETHING>;
>
I'm using reset-gpios = <&gpio3 17 0>;
>> + vdd-supply = <&vio>;
>> + avdd-supply = <&vaux1>;
>
> Those two are not mentioned in the binding and not supported by the
> driver as far as I can see?
>
Right, but vio and vaux1 need to be on - the reason why it's working at
all is because lis302 uses the same regulators and turns them on. IMHO
either we add the support for regulators to maxtouch driver or we add
regulator-always-on to vio and vaux1.
>> + };
>> +};
>
> Touchscreen with the same settings is required for n950, so it
> should be in the shared n950 + n9 file.
>
As a side-note, there is no pinmux mentioned and usually I'd use
OMAP3_CORE1_IOPAD(0x20c8, PIN_INPUT | MUX_MODE4) /* gpio_61*/
OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE4) /* gpio_81*/
For reasons that I can't explain, first line (gpmc_nbe1->gpio_61) breaks
it for me, so I've commented it out. Still, if anyone has an idea what
is wrong with that please let me know.
>> +&i2c3 {
>> + ak8975 at 0f {
>> + compatible = "asahi-kasei,ak8975";
>> + reg = <0x0f>;
>> + };
>> };
>
> Looking at the N9 board file this is missing a rotation matrix. This
> is supported by the binding:
>
> Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
>
>>
>> &isp {
>
> -- Sebastian
>
Best regards,
Filip
^ permalink raw reply
* [PATCH v2 4/4] dmaengine: xilinx_dma: Free BD consistent memory
From: Kedareswara rao Appana @ 2018-01-03 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514961731-1916-1-git-send-email-appanad@xilinx.com>
Free BD consistent memory while freeing the channel
i.e in free_chan_resources.
Signed-off-by: Radhey Shyam Pandey <radheys@xilinx.com>
Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
---
Changes for v2:
--> None.
drivers/dma/xilinx/xilinx_dma.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 845e638..a9edbd8 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -764,6 +764,11 @@ static void xilinx_dma_free_chan_resources(struct dma_chan *dchan)
INIT_LIST_HEAD(&chan->free_seg_list);
spin_unlock_irqrestore(&chan->lock, flags);
+ /* Free memory that is allocated for BD */
+ dma_free_coherent(chan->dev, sizeof(*chan->seg_v) *
+ XILINX_DMA_NUM_DESCS, chan->seg_v,
+ chan->seg_p);
+
/* Free Memory that is allocated for cyclic DMA Mode */
dma_free_coherent(chan->dev, sizeof(*chan->cyclic_seg_v),
chan->cyclic_seg_v, chan->cyclic_seg_p);
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/4] dmaengine: xilinx_dma: Fix warning variable prev set but not used
From: Kedareswara rao Appana @ 2018-01-03 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514961731-1916-1-git-send-email-appanad@xilinx.com>
This patch fixes the below sparse warning in the driver
drivers/dma/xilinx/xilinx_dma.c: In function ?xilinx_vdma_dma_prep_interleaved?:
drivers/dma/xilinx/xilinx_dma.c:1614:43: warning: variable ?prev? set but not used [-Wunused-but-set-variable]
struct xilinx_vdma_tx_segment *segment, *prev = NULL;
Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
---
Changes for v2:
--> Improved commit message title and description
as suggested by Vinod.
drivers/dma/xilinx/xilinx_dma.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 8467671..845e638 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -1611,7 +1611,7 @@ xilinx_vdma_dma_prep_interleaved(struct dma_chan *dchan,
{
struct xilinx_dma_chan *chan = to_xilinx_chan(dchan);
struct xilinx_dma_tx_descriptor *desc;
- struct xilinx_vdma_tx_segment *segment, *prev = NULL;
+ struct xilinx_vdma_tx_segment *segment;
struct xilinx_vdma_desc_hw *hw;
if (!is_slave_direction(xt->dir))
@@ -1665,8 +1665,6 @@ xilinx_vdma_dma_prep_interleaved(struct dma_chan *dchan,
/* Insert the segment into the descriptor segments list. */
list_add_tail(&segment->node, &desc->segments);
- prev = segment;
-
/* Link the last hardware descriptor with the first. */
segment = list_first_entry(&desc->segments,
struct xilinx_vdma_tx_segment, node);
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/4] dmaengine: xilinx_dma: properly configure the SG mode bit in the driver for cdma
From: Kedareswara rao Appana @ 2018-01-03 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514961731-1916-1-git-send-email-appanad@xilinx.com>
If the hardware is configured for Scatter Gather(SG) mode,
and hardware is idle, in the control register SG mode bit
must be set to a 0 then back to 1 by the software, to force
the CDMA SG engine to use a new value written to the CURDESC_PNTR
register, failure to do so could result errors from the dmaengine.
This patch updates the same.
Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
---
Changes for v2:
--> Improved commit message title and description
as suggested by Vinod.
drivers/dma/xilinx/xilinx_dma.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 21ac954..8467671 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -1204,6 +1204,12 @@ static void xilinx_cdma_start_transfer(struct xilinx_dma_chan *chan)
}
if (chan->has_sg) {
+ dma_ctrl_clr(chan, XILINX_DMA_REG_DMACR,
+ XILINX_CDMA_CR_SGMODE);
+
+ dma_ctrl_set(chan, XILINX_DMA_REG_DMACR,
+ XILINX_CDMA_CR_SGMODE);
+
xilinx_write(chan, XILINX_DMA_REG_CURDESC,
head_desc->async_tx.phys);
@@ -2052,6 +2058,10 @@ static int xilinx_dma_terminate_all(struct dma_chan *dchan)
chan->cyclic = false;
}
+ if ((chan->xdev->dma_config->dmatype == XDMA_TYPE_CDMA) && chan->has_sg)
+ dma_ctrl_clr(chan, XILINX_DMA_REG_DMACR,
+ XILINX_CDMA_CR_SGMODE);
+
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/4] dmaengine: xilinx_dma: populate dma caps properly
From: Kedareswara rao Appana @ 2018-01-03 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514961731-1916-1-git-send-email-appanad@xilinx.com>
When client driver uses dma_get_slave_caps() api,
it checks for certain fields of dma_device struct
currently driver is not settings the directions and addr_widths
fields resulting dma_get_slave_caps() returning failure.
This patch fixes this issue by populating proper values
to the struct dma_device directions and addr_widths fields.
Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
---
Changes for v2:
--> Improved commit message title and description
as suggested by Vinod.
drivers/dma/xilinx/xilinx_dma.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 88d317d..21ac954 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -2398,6 +2398,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
chan->direction = DMA_MEM_TO_DEV;
chan->id = chan_id;
chan->tdest = chan_id;
+ xdev->common.directions = BIT(DMA_MEM_TO_DEV);
chan->ctrl_offset = XILINX_DMA_MM2S_CTRL_OFFSET;
if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
@@ -2415,6 +2416,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
chan->direction = DMA_DEV_TO_MEM;
chan->id = chan_id;
chan->tdest = chan_id - xdev->nr_channels;
+ xdev->common.directions |= BIT(DMA_DEV_TO_MEM);
chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
@@ -2629,6 +2631,8 @@ static int xilinx_dma_probe(struct platform_device *pdev)
dma_cap_set(DMA_PRIVATE, xdev->common.cap_mask);
}
+ xdev->common.dst_addr_widths = BIT(addr_width / 8);
+ xdev->common.src_addr_widths = BIT(addr_width / 8);
xdev->common.device_alloc_chan_resources =
xilinx_dma_alloc_chan_resources;
xdev->common.device_free_chan_resources =
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/4] dmaengine: xilinx_dma: Bug fixes
From: Kedareswara rao Appana @ 2018-01-03 6:42 UTC (permalink / raw)
To: linux-arm-kernel
This patch series does the below
--> Fixes sparse warnings in the driver.
--> properly configures the SG mode bit in the driver for cdma.
--> populates dma caps properly.
This patch series got created on top of linux tag 4.15-rc4
i.e slave-dma.git next branch
Kedareswara rao Appana (4):
dmaengine: xilinx_dma: populate dma caps properly
dmaengine: xilinx_dma: properly configure the SG mode bit in the
driver for cdma
dmaengine: xilinx_dma: Fix warning variable prev set but not used
dmaengine: xilinx_dma: Free BD consistent memory
drivers/dma/xilinx/xilinx_dma.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v5 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622
From: Honghui Zhang @ 2018-01-03 6:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102105659.GB10536@red-moon>
On Tue, 2018-01-02 at 10:56 +0000, Lorenzo Pieralisi wrote:
> On Thu, Dec 28, 2017 at 09:39:12AM +0800, Honghui Zhang wrote:
> > On Wed, 2017-12-27 at 12:45 -0600, Bjorn Helgaas wrote:
> > > On Wed, Dec 27, 2017 at 08:59:54AM +0800, honghui.zhang at mediatek.com wrote:
> > > > From: Honghui Zhang <honghui.zhang@mediatek.com>
> > > >
> > > > + /* Set up class code for MT7622 */
> > > > + val = PCI_CLASS_BRIDGE_PCI << 16;
> > > > + writel(val, port->base + PCIE_CONF_CLASS);
> > >
> > > 1) Your comments mention MT7622 specifically, but this code is run for
> > > both mt2712-pcie and mt7622-pcie. If this code is safe and necessary
> > > for both mt2712-pcie and mt7622-pcie, please remove the mention of
> > > MT7622.
> >
> > Hmm, the code snippet added here will only be executed by MT7622, since
> > MT2712 will not enter this "if (pcie->base) {" condition.
> > Should the mention of MT7622 must be removed in this case?
>
> You should add an explicit way (eg of_device_is_compatible() match for
> instance) to apply the quirk just on the platform that requires it.
>
> Checking for "if (pcie->base)" is really not the way to do it.
>
hi, Lorenzo,
Thanks very much for your advise.
Passing the compatible string or platform data into this function needed
to add some new field in the struct mtk_pcie_port, then I guess both set
it for MT2712 and MT7622 is an easy way, since re-setting those values
for MT2712 is safe.
> > > 2) The first comment mentions both "vendor ID and device ID" but you
> > > don't write the device ID. Since this code applies to both
> > > mt2712-pcie and mt7622-pcie, my guess is that you don't *want* to
> > > write the device ID. If that's the case, please fix the comment.
> > >
> >
> > My bad, I did not check the comments carefully.
> > Thanks.
> >
> > > 3) If you only need to set the vendor ID, you're performing a 32-bit
> > > write (writel()) to update a 16-bit value. Please use writew()
> > > instead.
> > >
> >
> > Ok, thanks, I guess I could use the following code snippet in the next
> > version:
> > val = readl(port->base + PCIE_CONF_VENDOR_ID)
> > val &= ~GENMASK(15, 0);
> > val |= PCI_VENDOR_ID_MEDIATEK;
> > writel(val, port->base + PCIE_CONF_VENDOR_ID);
>
> Have you read Bjorn's comment ? Or there is a problem with using
> a writew() ?
>
This control register is a 32bit register, I'm not sure whether the apb
bus support write an 16bit value with 16bit but not 32bit address
alignment. I prefer the more safety old way of writel.
I need to do more test about the writew if the code elegant is more
important.
thanks.
> Lorenzo
>
> > > 4) If you only need to set the vendor ID, please use a definition like
> > > "PCIE_CONF_VENDOR_ID" instead of the ambiguous "PCIE_CONF_ID".
> > >
> > > 5) If you only need to set the vendor ID, please update the changelog
> > > to mention "vendor ID" specifically instead of the ambiguous "IDs".
> >
> > > 6) Please add a space before the closing "*/" of the first comment.
> > >
> > > 7) PCI_CLASS_BRIDGE_PCI is for a PCI-to-PCI bridge, i.e., one that has
> > > PCI on both the primary (upstream) side and the secondary (downstream)
> > > side. That kind of bridge has a type 1 config header (see
> > > PCI_HEADER_TYPE) and the PCI_PRIMARY_BUS and PCI_SECONDARY_BUS
> > > registers tell us the bus number of the primary and secondary sides.
> > >
> > > I don't believe this device is a PCI-to-PCI bridge. I think it's a
> > > *host* bridge that has some non-PCI interface on the upstream side and
> > > should have a type 0 config header. If that's the case you should use
> > > PCI_CLASS_BRIDGE_HOST instead.
> > >
> >
> > Thanks very much for your help with the review, I will fix the other
> > issue in the next version.
> >
> > > > }
> > > >
> > > > /* Assert all reset signals */
> > > > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > > > index ab20dc5..2480b0e 100644
> > > > --- a/include/linux/pci_ids.h
> > > > +++ b/include/linux/pci_ids.h
> > > > @@ -2113,6 +2113,8 @@
> > > >
> > > > #define PCI_VENDOR_ID_MYRICOM 0x14c1
> > > >
> > > > +#define PCI_VENDOR_ID_MEDIATEK 0x14c3
> > > > +
> > > > #define PCI_VENDOR_ID_TITAN 0x14D2
> > > > #define PCI_DEVICE_ID_TITAN_010L 0x8001
> > > > #define PCI_DEVICE_ID_TITAN_100L 0x8010
> > > > --
> > > > 2.6.4
> > > >
> >
> >
^ permalink raw reply
* [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
From: Ganapatrao Kulkarni @ 2018-01-03 6:32 UTC (permalink / raw)
To: linux-arm-kernel
When an interrupt is moved across node collections on ThunderX2
multi Socket platform, an interrupt stops routed to new collection
and results in loss of interrupts.
Adding workaround to issue INV after MOVI for cross-node collection
move to flush out the cached entry.
Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
---
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 11 +++++++++++
drivers/irqchip/irq-gic-v3-its.c | 24 ++++++++++++++++++++++++
3 files changed, 36 insertions(+)
diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index fc1c884..fb27cb5 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -63,6 +63,7 @@ stable kernels.
| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
| Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
| Cavium | ThunderX SMMUv2 | #27704 | N/A |
+| Cavium | ThunderX2 ITS | #174 | CAVIUM_ERRATUM_174 |
| Cavium | ThunderX2 SMMUv3| #74 | N/A |
| Cavium | ThunderX2 SMMUv3| #126 | N/A |
| | | | |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c9a7e9e..71a7e30 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419
If unsure, say Y.
+config CAVIUM_ERRATUM_174
+ bool "Cavium ThunderX2 erratum 174"
+ depends on NUMA
+ default y
+ help
+ LPI stops routed to redistributors after inter node collection
+ move in ITS. Enable workaround to invalidate ITS entry after
+ inter-node collection move.
+
+ If unsure, say Y.
+
config CAVIUM_ERRATUM_22375
bool "Cavium erratum 22375, 24313"
default y
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 06f025f..d8b9c96 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -46,6 +46,7 @@
#define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1ULL << 0)
#define ITS_FLAGS_WORKAROUND_CAVIUM_22375 (1ULL << 1)
#define ITS_FLAGS_WORKAROUND_CAVIUM_23144 (1ULL << 2)
+#define ITS_FLAGS_WORKAROUND_CAVIUM_174 (1ULL << 3)
#define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0)
@@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
if (cpu != its_dev->event_map.col_map[id]) {
target_col = &its_dev->its->collections[cpu];
its_send_movi(its_dev, target_col, id);
+ if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_174) {
+ /* Issue INV for cross node collection move. */
+ if (cpu_to_node(cpu) !=
+ cpu_to_node(its_dev->event_map.col_map[id]))
+ its_send_inv(its_dev, id);
+ }
its_dev->event_map.col_map[id] = cpu;
irq_data_update_effective_affinity(d, cpumask_of(cpu));
}
@@ -2904,6 +2911,15 @@ static int its_force_quiescent(void __iomem *base)
}
}
+static bool __maybe_unused its_enable_quirk_cavium_174(void *data)
+{
+ struct its_node *its = data;
+
+ its->flags |= ITS_FLAGS_WORKAROUND_CAVIUM_174;
+
+ return true;
+}
+
static bool __maybe_unused its_enable_quirk_cavium_22375(void *data)
{
struct its_node *its = data;
@@ -3031,6 +3047,14 @@ static const struct gic_quirk its_quirks[] = {
.init = its_enable_quirk_hip07_161600802,
},
#endif
+#ifdef CONFIG_CAVIUM_ERRATUM_174
+ {
+ .desc = "ITS: Cavium ThunderX2 erratum 174",
+ .iidr = 0x13f, /* ThunderX2 pass A1/A2/B0 */
+ .mask = 0xffffffff,
+ .init = its_enable_quirk_cavium_174,
+ },
+#endif
{
}
};
--
2.9.4
^ permalink raw reply related
* [PATCH] ARM: dts: sun8i: a83t: bananapi-m3: Add LED device nodes
From: Chen-Yu Tsai @ 2018-01-03 6:28 UTC (permalink / raw)
To: linux-arm-kernel
The Bananapi M3 has two controllable LEDs, blue and green, that are tied
to the PMIC's two GPIO pins.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 6550bf0e594b..78fe61d97790 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -60,6 +60,20 @@
stdout-path = "serial0:115200n8";
};
+ leds {
+ compatible = "gpio-leds";
+
+ blue {
+ label = "bananapi-m3:blue:usr";
+ gpios = <&axp_gpio 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ green {
+ label = "bananapi-m3:green:usr";
+ gpios = <&axp_gpio 0 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
reg_usb1_vbus: reg-usb1-vbus {
compatible = "regulator-fixed";
regulator-name = "usb1-vbus";
--
2.15.1
^ permalink raw reply related
* [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
From: Michael Ellerman @ 2018-01-03 6:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWWus2kNSOzS94k-3678826W1YjKwCWTquu3hBLZ80cvw@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>> Christoph Hellwig <hch@lst.de> writes:
>>
>>> We want to use the dma_direct_ namespace for a generic implementation,
>>> so rename powerpc to the second best choice: dma_nommu_.
>>
>> I'm not a fan of "nommu". Some of the users of direct ops *are* using an
>> IOMMU, they're just setting up a 1:1 mapping once at init time, rather
>> than mapping dynamically.
>>
>> Though I don't have a good idea for a better name, maybe "1to1",
>> "linear", "premapped" ?
>
> "identity"?
I think that would be wrong, but thanks for trying to help :)
The address on the device side is sometimes (often?) offset from the CPU
address. So eg. the device can DMA to RAM address 0x0 using address
0x800000000000000.
Identity would imply 0 == 0 etc.
I think "bijective" is the correct term, but that's probably a bit
esoteric.
cheers
^ permalink raw reply
* [LINUX PATCH 3/4] dmaengine: xilinx_dma: Fix compilation warning
From: Appana Durga Kedareswara Rao @ 2018-01-03 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103052746.GI18649@localhost>
Hi Vinod,
>On Wed, Jan 03, 2018 at 05:13:29AM +0000, Appana Durga Kedareswara Rao
>wrote:
>> Hi Vinod,
>>
>> Thanks for the review...
>>
>> >
>> >On Thu, Dec 21, 2017 at 03:41:37PM +0530, Kedareswara rao Appana wrote:
>> >
>> >Fix title here too
>>
>> Sure will fix in v2...
>>
>> >
>> >BTW whats with LINUX tag in patches, pls drop them
>>
>> Ok will mention the Linux tag info in the cover letter patch from the
>> next patch series on wards...
>
>Please wrap your replies within 80chars. It is very hard to read! I have reflown for
>readability
Sure will take care of it next time onwards...
>
>Can you explain what you mean by that info, what are you trying to convey?
What I mean here is will mention the Linux kernel tag
Information in the cover letter patch...
Regards,
Kedar.
>
>--
>~Vinod
^ permalink raw reply
* [GIT PULL 5/5] i.MX defconfig updates for 4.16
From: Shawn Guo @ 2018-01-03 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514959040-9992-1-git-send-email-shawnguo@kernel.org>
The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36:
Linux 4.15-rc3 (2017-12-10 17:56:26 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-defconfig-4.16
for you to fetch changes up to 189114b47b1cfcc5da02db9bcafebd2042aa7ab8:
ARM: imx_v6_v7_defconfig: enable CONFIG_CPU_FREQ_STAT (2017-12-26 17:04:13 +0800)
----------------------------------------------------------------
i.MX defconfig updates for 4.16:
- Enable CPU_FREQ_STAT for cpufreq transtion statistics support.
- Enable SRTC driver RTC_DRV_MXC_V2 for i.MX53.
- Turn on a few drivers useful for DART-MX6 SoM support, SERDEV
bluetooth, SERIAL_DEV_BUS, WL18XX, and DEFAULT_ON LED Trigger.
----------------------------------------------------------------
Dong Aisheng (1):
ARM: imx_v6_v7_defconfig: enable CONFIG_CPU_FREQ_STAT
Neil Armstrong (1):
ARM: imx_v6_v7_defconfig: Add missing config for DART-MX6 SoM
Patrick Bruenn (1):
ARM: imx_v6_v7_defconfig: enable RTC_DRV_MXC_V2
arch/arm/configs/imx_v6_v7_defconfig | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
^ permalink raw reply
* [GIT PULL 4/5] Freescale arm64 device tree updates for 4.16
From: Shawn Guo @ 2018-01-03 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514959040-9992-1-git-send-email-shawnguo@kernel.org>
The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36:
Linux 4.15-rc3 (2017-12-10 17:56:26 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-dt64-4.16
for you to fetch changes up to 1e33300782235ae6fdc891d9c3ba04ba59da6f3d:
arm64: dts: ls208xa: add power monitor chip node (2017-12-26 17:14:13 +0800)
----------------------------------------------------------------
Freescale arm64 device tree updates for 4.16:
- LS1088A updates: add device support for DCFG, qoriq-mc, and USB.
- Add power monitor device INA220 for ls208xa-rdb board.
----------------------------------------------------------------
Ashish Kumar (1):
arm64: dts: ls1088a: Added dcfg node in ls1088a dtsi
Ioana Ciornei (1):
arm64: dts: ls1088a: add fsl-mc hardware resource manager node
Yuantian Tang (1):
arm64: dts: ls208xa: add power monitor chip node
yinbo.zhu (1):
arm64: dts: ls1088a: Add USB support
arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts | 8 ++
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 97 ++++++++++++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi | 12 +++
3 files changed, 117 insertions(+)
^ 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