* [PATCH] arm64: alternative:flush cache with unpatched code
From: Rohit Khanna @ 2018-05-31 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530090044.GA2452@arm.com>
Will, thanks for the comments.
I will push a new patch set.
We want to avoid using __flush_icache_all as much as possible and hence trying to flush cache by range.
Thanks
Rohit
________________________________________
From: Will Deacon <will.deacon@arm.com>
Sent: Wednesday, May 30, 2018 2:00 AM
To: Rohit Khanna
Cc: catalin.marinas at arm.com; robin.murphy at arm.com; mark.rutland at arm.com; Suzuki.Poulose at arm.com; Bo Yan; Alexander Van Brunt; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH] arm64: alternative:flush cache with unpatched code
Hi Rohit,
Please keep me on cc for future versions of this patch. Comments inline.
On Tue, May 29, 2018 at 11:11:28AM -0700, Rohit Khanna wrote:
> In the current implementation, __apply_alternatives patches
> flush_icache_range and then executes it without invalidating the icache.
> Thus, icache can contain some of the old instructions for
> flush_icache_range. This can cause unpredictable behavior as during
> execution we can get a mix of old and new instructions for
> flush_icache_range.
>
> This patch :
> 1. Adds a new function flush_cache_kernel_range for flushing kernel
> memory range. This function uses non hot-patched code and can be
> safely used to flush cache during code patching.
>
> 2. Modifies __apply_alternatives so that it uses
> flush_cache_kernel_range to flush the cache range after patching code.
>
> Signed-off-by: Rohit Khanna <rokhanna@nvidia.com>
> ---
> arch/arm64/kernel/alternative.c | 31 +++++++++++++++++++++++++++++--
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
> index 5c4bce4ac381..e93cfd26a314 100644
> --- a/arch/arm64/kernel/alternative.c
> +++ b/arch/arm64/kernel/alternative.c
> @@ -122,6 +122,33 @@ static void patch_alternative(struct alt_instr *alt,
> }
> }
>
> +/* This is used for flushing kernel memory range after
> + * __apply_alternatives has patched kernel code
> + */
> +static void flush_cache_kernel_range(void *start, void *end)
> +{
How about something like clean_dcache_range_nopatch instead?
> + u64 d_start, i_start, d_size, i_size;
> +
> + /* use sanitized value of ctr_el0 rather than raw value from CPU */
> + d_size = 4 << ((arm64_ftr_reg_ctrel0.sys_val >> 0x10) & 0xF); /* bytes */
> + i_size = 4 << (arm64_ftr_reg_ctrel0.sys_val & 0xF); /* bytes */
You should be able to use read_sanitised_ftr_reg() and
cpuid_feature_extract_unsigned_field() here.
> + d_start = (u64)start & ~(d_size - 1);
> + while (d_start <= (u64)end) {
Please add a comment about the A53 erratum this is handling by using
clean+inv.
> + asm volatile("dc civac, %0" : : "r" (d_start));
> + d_start += d_size;
> + }
> + dsb(ish);
> +
> + i_start = (u64)start & ~(i_size - 1);
> + while (i_start <= (u64)end) {
> + asm volatile("ic ivau, %0" : : "r" (i_start));
> + i_start += i_size;
> + }
> + dsb(ish);
> + isb();
As I mentioned before, I think it would be simpler just to avoid doing the
I-cache invalidation by range and instead call __flush_icache_all once we've
exiting the loop in __apply_alternatives.
Will
^ permalink raw reply
* [PATCH v4 1/2] ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()
From: Robin Murphy @ 2018-05-31 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530140625.21247-2-thierry.reding@gmail.com>
On 30/05/18 15:06, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Instead of setting the DMA ops pointer to NULL, set the correct,
> non-IOMMU ops depending on the device's coherency setting.
It looks like it's probably been 4 or 5 years since that became subtly
wrong by virtue of the landscape changing around it, but it's clearly
not enough of a problem to consider stable backports :)
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> Changes in v4:
> - new patch to fix existing arm_iommu_detach_device() to do what we need
>
> arch/arm/mm/dma-mapping.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index af27f1c22d93..87a0037574e4 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1151,6 +1151,11 @@ int arm_dma_supported(struct device *dev, u64 mask)
> return __dma_supported(dev, mask, false);
> }
>
> +static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
> +{
> + return coherent ? &arm_coherent_dma_ops : &arm_dma_ops;
> +}
> +
> #ifdef CONFIG_ARM_DMA_USE_IOMMU
>
> static int __dma_info_to_prot(enum dma_data_direction dir, unsigned long attrs)
> @@ -2296,7 +2301,7 @@ void arm_iommu_detach_device(struct device *dev)
> iommu_detach_device(mapping->domain, dev);
> kref_put(&mapping->kref, release_iommu_mapping);
> to_dma_iommu_mapping(dev) = NULL;
> - set_dma_ops(dev, NULL);
> + set_dma_ops(dev, arm_get_dma_map_ops(dev->archdata.dma_coherent));
>
> pr_debug("Detached IOMMU controller from %s device.\n", dev_name(dev));
> }
> @@ -2357,11 +2362,6 @@ static void arm_teardown_iommu_dma_ops(struct device *dev) { }
>
> #endif /* CONFIG_ARM_DMA_USE_IOMMU */
>
> -static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
> -{
> - return coherent ? &arm_coherent_dma_ops : &arm_dma_ops;
> -}
> -
> void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> const struct iommu_ops *iommu, bool coherent)
> {
>
^ permalink raw reply
* [PATCH 06/15] drm/sun4i: tcon: Add support for tcon-top
From: Jernej Škrabec @ 2018-05-31 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531092133.3gqepoabvuruiztz@flea.home>
Dne ?etrtek, 31. maj 2018 ob 11:21:33 CEST je Maxime Ripard napisal(a):
> On Thu, May 24, 2018 at 03:01:09PM -0700, Chen-Yu Tsai wrote:
> > >> > > + if (tcon->quirks->needs_tcon_top) {
> > >> > > + struct device_node *np;
> > >> > > +
> > >> > > + np = of_parse_phandle(dev->of_node, "allwinner,tcon-top",
> > >> > > 0);
> > >> > > + if (np) {
> > >> > > + struct platform_device *pdev;
> > >> > > +
> > >> > > + pdev = of_find_device_by_node(np);
> > >> > > + if (pdev)
> > >> > > + tcon->tcon_top =
> > >> > > platform_get_drvdata(pdev);
> > >> > > + of_node_put(np);
> > >> > > +
> > >> > > + if (!tcon->tcon_top)
> > >> > > + return -EPROBE_DEFER;
> > >> > > + }
> > >> > > + }
> > >> > > +
> > >> >
> > >> > I might have missed it, but I've not seen the bindings additions for
> > >> > that property. This shouldn't really be done that way anyway, instead
> > >> > of using a direct phandle, you should be using the of-graph, with the
> > >> > TCON-top sitting where it belongs in the flow of data.
> > >>
> > >> Just to answer to the first question, it did describe it in "[PATCH
> > >> 07/15] dt- bindings: display: sun4i-drm: Add R40 HDMI pipeline".
> > >>
> > >> As why I designed it that way - HW representation could be described
> > >> that way> >>
> > >> (ASCII art makes sense when fixed width font is used to view it):
> > >> / LCD0/LVDS0
> > >>
> > >> / TCON-LCD0
> > >>
> > >> | \ MIPI DSI
> > >>
> > >> mixer0 |
> > >>
> > >> \ / TCON-LCD1 - LCD1/LVDS1
> > >>
> > >> TCON-TOP
> > >>
> > >> / \ TCON-TV0 - TVE0/RGB
> > >>
> > >> mixer1 | \
> > >>
> > >> | TCON-TOP - HDMI
> > >> |
> > >> | /
> > >>
> > >> \ TCON-TV1 - TVE1/RGB
> > >>
> > >> This is a bit simplified, since there is also TVE-TOP, which is
> > >> responsible
> > >> for sharing 4 DACs between both TVE encoders. You can have two TV outs
> > >> (PAL/ NTSC) or TVE0 as TV out and TVE1 as RGB or vice versa. It even
> > >> seems that you can arbitrarly choose which DAC is responsible for
> > >> which signal, so there is a ton of possible end combinations, but I'm
> > >> not 100% sure.
> > >>
> > >> Even though I wrote TCON-TOP twice, this is same unit in HW. R40 manual
> > >> suggest more possibilities, although some of them seem wrong, like RGB
> > >> feeding from LCD TCON. That is confirmed to be wrong when checking BSP
> > >> code.
> > >>
> > >> Additionally, TCON-TOP comes in the middle of TVE0 and LCD0, TVE1 and
> > >> LCD1 for pin muxing, although I'm not sure why is that needed at all,
> > >> since according to R40 datasheet, TVE0 and TVE1 pins are dedicated and
> > >> not on PORT D and PORT H, respectively, as TCON-TOP documentation
> > >> suggest. However, HSYNC and PSYNC lines might be shared between TVE
> > >> (when it works in RGB mode) and LCD. But that is just my guess since
> > >> I'm not really familiar with RGB and LCD interfaces.
> > >>
> > >> I'm really not sure what would be the best representation in OF-graph.
> > >> Can you suggest one?
> > >
> > > Rob might disagree on this one, but I don't see anything wrong with
> > > having loops in the graph. If the TCON-TOP can be both the input and
> > > output of the TCONs, then so be it, and have it described that way in
> > > the graph.
> > >
> > > The code is already able to filter out nodes that have already been
> > > added to the list of devices we need to wait for in the component
> > > framework, so that should work as well.
> > >
> > > And we'd need to describe TVE-TOP as well, even though we don't have a
> > > driver for it yet. That will simplify the backward compatibility later
> > > on.
> >
> > I'm getting the feeling that TCON-TOP / TVE-TOP is the glue layer that
> > binds everything together, and provides signal routing, kind of like
> > DE-TOP on A64. So the signal mux controls that were originally found
> > in TCON0 and TVE0 were moved out.
> >
> > The driver needs to know about that, but the graph about doesn't make
> > much sense directly. Without looking at the manual, I understand it to
> > likely be one mux between the mixers and TCONs, and one between the
> > TCON-TVs and HDMI. Would it make more sense to just have the graph
> > connections between the muxed components, and remove TCON-TOP from
> > it, like we had in the past? A phandle could be used to reference
> > the TCON-TOP for mux controls, in addition to the clocks and resets.
> >
> > For TVE, we would need something to represent each of the output pins,
> > so the device tree can actually describe what kind of signal, be it
> > each component of RGB/YUV or composite video, is wanted on each pin,
> > if any. This is also needed on the A20 for the Cubietruck, so we can
> > describe which pins are tied to the VGA connector, and which one does
> > R, G, or B.
>
> I guess we'll see how the DT maintainers feel about this, but my
> impression is that the OF graph should model the flow of data between
> the devices. If there's a mux somewhere, then the data is definitely
> going through it, and as such it should be part of the graph.
I concur, but I spent few days thinking how to represent this sanely in graph,
but I didn't find any good solution. I'll represent here my idea and please
tell your opinion before I start implementing it.
First, let me be clear that mixer0 and mixer1 don't have same capabilities
(different number of planes, mixer0 supports writeback, mixer1 does not,
etc.). Thus, it does matter which mixer is connected to which TCON/encoder.
mixer0 is meant to be connected to main display and mixer1 to auxiliary. That
obviously depends on end system.
So, TCON TOP has 3 muxes, which have to be represented in graph. Two of them
are for mixer/TCON relationship (each of them 1 input and 4 possible outputs)
and one for TV TCON/HDMI pair selection (2 possible inputs, 1 output).
According to current practice in sun4i-drm driver, graph has to have port 0,
representing input and port 1, representing output. This would mean that graph
looks something like that:
tcon_top: tcon-top at 1c70000 {
compatible = "allwinner,sun8i-r40-tcon-top";
...
ports {
#address-cells = <1>;
#size-cells = <0>;
tcon_top_in: port at 0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
tcon_top_in_mixer0: endpoint at 0 {
reg = <0>;
remote-endpoint = <&mixer0_out_tcon_top>;
};
tcon_top_in_mixer1: endpoint at 1 {
reg = <1>;
remote-endpoint = <&mixer1_out_tcon_top>;
};
tcon_top_in_tcon_tv: endpoint at 2 {
reg = <2>;
// here is HDMI input connection, part of board DTS
remote-endpoint = <board specific phandle to TV TCON output>;
};
};
tcon_top_out: port at 1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
tcon_top_out_tcon0: endpoint at 0 {
reg = <0>;
// here is mixer0 output connection, part of board DTS
remote-endpoint = <board specific phandle to TCON>;
};
tcon_top_out_tcon1: endpoint at 1 {
reg = <1>;
// here is mixer1 output connection, part of board DTS
remote-endpoint = <board specific phandle to TCON>;
};
tcon_top_out_hdmi: endpoint at 2 {
reg = <2>;
remote-endpoint = <&hdmi_in_tcon_top>;
};
};
};
};
tcon_tv0: lcd-controller at 1c73000 {
compatible = "allwinner,sun8i-r40-tcon-tv-0";
...
ports {
#address-cells = <1>;
#size-cells = <0>;
tcon_tv0_in: port at 0 {
reg = <0>;
tcon_tv0_in_tcon_top: endpoint {
// endpoint depends on board, part of board DTS
remote-endpoint = <phandle to one of tcon_top_out_tcon>;
};
};
tcon_tv0_out: port at 1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
// endpoints to TV TOP and TCON TOP HDMI input
...
};
};
};
tcon_tv1: lcd-controller at 1c74000 {
compatible = "allwinner,sun8i-r40-tcon-tv-1";
...
ports {
#address-cells = <1>;
#size-cells = <0>;
tcon_tv1_in: port at 0 {
reg = <0>;
tcon_tv1_in_tcon_top: endpoint {
// endpoint depends on board, part of board DTS
remote-endpoint = <phandle to one of tcon_top_out_tcon>;
};
};
tcon_tv1_out: port at 1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
// endpoints to TV TOP and TCON TOP HDMI input
...
};
};
};
tcon_lcd0 and tcon_lcd1 would have similar connections, except that for
outputs would be LCD or LVDS panels or MIPI DSI encoder.
Please note that each TCON (there are 4 of them) would need to have unique
compatible and have HW index stored in quirks data. It would be used by TCON
TOP driver for configuring muxes.
What do you think about above suggestion?
Best regards,
Jernej
^ permalink raw reply
* [PATCH v4 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
From: Robin Murphy @ 2018-05-31 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530140625.21247-3-thierry.reding@gmail.com>
On 30/05/18 15:06, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Depending on the kernel configuration, early ARM architecture setup code
> may have attached the GPU to a DMA/IOMMU mapping that transparently uses
> the IOMMU to back the DMA API. Tegra requires special handling for IOMMU
> backed buffers (a special bit in the GPU's MMU page tables indicates the
> memory path to take: via the SMMU or directly to the memory controller).
> Transparently backing DMA memory with an IOMMU prevents Nouveau from
> properly handling such memory accesses and causes memory access faults.
>
> As a side-note: buffers other than those allocated in instance memory
> don't need to be physically contiguous from the GPU's perspective since
> the GPU can map them into contiguous buffers using its own MMU. Mapping
> these buffers through the IOMMU is unnecessary and will even lead to
> performance degradation because of the additional translation. One
> exception to this are compressible buffers which need large pages. In
> order to enable these large pages, multiple small pages will have to be
> combined into one large (I/O virtually contiguous) mapping via the
> IOMMU. However, that is a topic outside the scope of this fix and isn't
> currently supported. An implementation will want to explicitly create
> these large pages in the Nouveau driver, so detaching from a DMA/IOMMU
> mapping would still be required.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> Changes in v4:
> - use existing APIs to detach from a DMA/IOMMU mapping
>
> Changes in v3:
> - clarify the use of IOMMU mapping for compressible buffers
> - squash multiple patches into this
>
> drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
> index 78597da6313a..0e372a190d3f 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
> @@ -23,6 +23,10 @@
> #ifdef CONFIG_NOUVEAU_PLATFORM_DRIVER
> #include "priv.h"
>
> +#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
> +#include <asm/dma-iommu.h>
> +#endif
> +
> static int
> nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev)
> {
> @@ -105,6 +109,15 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra *tdev)
> unsigned long pgsize_bitmap;
> int ret;
>
> +#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
> + if (dev->archdata.mapping) {
> + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
Nit: there's arguably little point using the helper here after you've
already shattered the illusion by poking dev->archdata.mapping directly,
but I guess this disappears again anyway once the refcounting gets
sorted out and the mapping releases itself properly, so:
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> +
> + arm_iommu_detach_device(dev);
> + arm_iommu_release_mapping(mapping);
> + }
> +#endif
> +
> if (!tdev->func->iommu_bit)
> return;
>
>
^ permalink raw reply
* [PATCH 0/3] Initial Spectre variant 1 patches
From: Tony Lindgren @ 2018-05-31 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531133047.GS17671@n2100.armlinux.org.uk>
* Russell King - ARM Linux <linux@armlinux.org.uk> [180531 13:34]:
> Hi,
>
> This series adds initial support for the Spectre variant 1 workarounds
> to the kernel. This does _not_ cover the user accessors, which are
> still in development.
>
> The series adds support for the array_index_mask_nospec() macro, used
> by generic kernel code to mask out of bounds pointers, and also adds
> the syscall table hardening.
For the series including v2 patch of 3/3:
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v2 0/2] Add R8A77980/Condor I2C support
From: Sergei Shtylyov @ 2018-05-31 20:18 UTC (permalink / raw)
To: linux-arm-kernel
Hello!
Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180529-v4.17-rc7' tag. We're adding the R8A77980 I2C nodes
and then describing 2 PCA9654 I/O expanders connected to the I2C0 bus on
the Condor board.
[1/2] arm64: dts: renesas: r8a77980: add I2C support
[2/2] arm64: dts: renesas: condor: add I2C0 support
WBR, Sergei
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: renesas: r8a77980: add I2C support
From: Sergei Shtylyov @ 2018-05-31 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2a88f4e9-0a86-8e6f-0ef2-20913dc9431d@cogentembedded.com>
Define the generic R8A77980 parts of the I2C[0-5] device nodes.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 2:
- removed the DMA props for I2C3/4;
- fixed a typo in the patch description;
- added Geert's tag.
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 105 ++++++++++++++++++++++++++++++
1 file changed, 105 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -16,6 +16,15 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -135,6 +144,102 @@
#power-domain-cells = <1>;
};
+ i2c0: i2c at e6500000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe6500000 0 0x40>;
+ interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 931>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 931>;
+ dmas = <&dmac1 0x91>, <&dmac1 0x90>,
+ <&dmac2 0x91>, <&dmac2 0x90>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c at e6508000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe6508000 0 0x40>;
+ interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 930>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 930>;
+ dmas = <&dmac1 0x93>, <&dmac1 0x92>,
+ <&dmac2 0x93>, <&dmac2 0x92>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c at e6510000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe6510000 0 0x40>;
+ interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 929>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 929>;
+ dmas = <&dmac1 0x95>, <&dmac1 0x94>,
+ <&dmac2 0x95>, <&dmac2 0x94>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c3: i2c at e66d0000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe66d0000 0 0x40>;
+ interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 928>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 928>;
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c4: i2c at e66d8000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe66d8000 0 0x40>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 927>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 927>;
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c5: i2c at e66e0000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe66e0000 0 0x40>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 919>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 919>;
+ dmas = <&dmac1 0x9b>, <&dmac1 0x9a>,
+ <&dmac2 0x9b>, <&dmac2 0x9a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
hscif0: serial at e6540000 {
compatible = "renesas,hscif-r8a77980",
"renesas,rcar-gen3-hscif",
^ permalink raw reply
* [PATCH 0/2] ARM: LEGO MINDSTORMS EV3 Bluetooth support
From: David Lechner @ 2018-05-31 20:25 UTC (permalink / raw)
To: linux-arm-kernel
This series adds Bluetooth support to LEGO MINDSTORMS EV3.
The pwm-clock depends on the common clock framework, so this requires the
recent davinci common clock series to switch to the common clock framework
before it will actually work.
David Lechner (2):
ARM: dts: da850-lego-ev3: Add Bluetooth nodes
ARM: davinci_all_defconfig: Enable Bluetooth
arch/arm/boot/dts/da850-lego-ev3.dts | 82 ++++++++++++++++++++++++++
arch/arm/configs/davinci_all_defconfig | 9 +++
2 files changed, 91 insertions(+)
--
2.17.0
^ permalink raw reply
* [PATCH 1/2] ARM: dts: da850-lego-ev3: Add Bluetooth nodes
From: David Lechner @ 2018-05-31 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531202549.11255-1-david@lechnology.com>
This adds nodes for describing the Bluetooth chip and connections on
LEGO MINDSTORMS EV3 to da850-lego-ev3.dts.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/da850-lego-ev3.dts | 82 ++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts b/arch/arm/boot/dts/da850-lego-ev3.dts
index bef42dc78817..fe4cc87394b9 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -187,6 +187,15 @@
rechargeable-gpios = <&gpio 136 GPIO_ACTIVE_LOW>;
};
+ bt_slow_clk: bt-clock {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ecap2_pins>, <&bt_clock_bias>;
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&ecap2 0 30518 0>;
+ };
+
/* ARM local RAM */
memory at ffff0000 {
compatible = "syscon", "simple-mfd";
@@ -251,6 +260,20 @@
bias-disable;
};
};
+
+ bt_clock_bias: bt-clock-bias-groups {
+ disable {
+ groups = "cp2";
+ bias-disable;
+ };
+ };
+
+ bt_pic_bias: bt-pic-bias-groups {
+ disable {
+ groups = "cp20";
+ bias-disable;
+ };
+ };
};
/* Input port 1 */
@@ -260,6 +283,22 @@
pinctrl-0 = <&serial1_rxtx_pins>;
};
+&serial2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&serial2_rxtx_pins>, <&serial2_rtscts_pins>, <&bt_pic_bias>;
+ status = "okay";
+
+ bluetooth {
+ compatible = "ti,cc2560";
+ clocks = <&bt_slow_clk>;
+ clock-names = "ext_clock";
+ enable-gpios = <&gpio 73 GPIO_ACTIVE_HIGH>;
+ max-speed = <2000000>;
+ nvmem-cells = <&bdaddr>;
+ nvmem-cell-names = "bd-address";
+ };
+};
+
&rtc0 {
status = "okay";
};
@@ -278,6 +317,12 @@
pagesize = <64>;
read-only;
reg = <0x50>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ bdaddr: bdaddr at 3f06 {
+ reg = <0x3f06 0x06>;
+ };
};
};
@@ -362,6 +407,10 @@
};
};
+&ecap2 {
+ status = "okay";
+};
+
&ehrpwm0 {
status = "okay";
};
@@ -375,6 +424,39 @@
gpios = <6 GPIO_ACTIVE_HIGH>;
output-high;
};
+
+ /* Don't impede Bluetooth clock signal */
+ bt_clock_en {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ input;
+ };
+
+ /*
+ * There is a PIC microcontroller for interfacing with an Apple MFi
+ * chip. This interferes with normal Bluetooth operation, so we need
+ * to make sure it is turned off. Note: The publicly available
+ * schematics from LEGO don't show that these pins are connected to
+ * anything, but they are present in the source code from LEGO.
+ */
+
+ bt_pic_en {
+ gpio-hog;
+ gpios = <51 GPIO_ACTIVE_HIGH>;
+ output-low;
+ };
+
+ bt_pic_rst {
+ gpio-hog;
+ gpios = <78 GPIO_ACTIVE_HIGH>;
+ output-high;
+ };
+
+ bt_pic_cts {
+ gpio-hog;
+ gpios = <87 GPIO_ACTIVE_HIGH>;
+ input;
+ };
};
&usb_phy {
--
2.17.0
^ permalink raw reply related
* [PATCH 2/2] ARM: davinci_all_defconfig: Enable Bluetooth
From: David Lechner @ 2018-05-31 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531202549.11255-1-david@lechnology.com>
This enables Bluetooth modules in davinic_all_defconfig needed for LEGO
MINDSTORMS EV3.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/configs/davinci_all_defconfig | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index a1b6e106b867..f8448c4703c1 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -54,6 +54,13 @@ CONFIG_INET=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_NETFILTER=y
+CONFIG_BT=m
+CONFIG_BT_RFCOMM=m
+CONFIG_BT_BNEP=m
+CONFIG_BT_HIDP=m
+CONFIG_BT_LEDS=y
+CONFIG_BT_HCIUART=m
+CONFIG_BT_HCIUART_LL=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_FW_LOADER=m
@@ -113,6 +120,7 @@ CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=3
CONFIG_SERIAL_8250_RUNTIME_UARTS=3
CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_SERIAL_DEV_BUS=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
@@ -212,6 +220,7 @@ CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_OMAP=m
CONFIG_DMADEVICES=y
CONFIG_TI_EDMA=y
+CONFIG_COMMON_CLK_PWM=m
CONFIG_REMOTEPROC=m
CONFIG_DA8XX_REMOTEPROC=m
CONFIG_MEMORY=y
--
2.17.0
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: renesas: condor: add I2C0 support
From: Sergei Shtylyov @ 2018-05-31 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2a88f4e9-0a86-8e6f-0ef2-20913dc9431d@cogentembedded.com>
Define the Condor board dependent part of the I2C0 device node.
The I2C0 bus is populated by 2 ON Semiconductor PCA9654 I/O expanders
and Analog Devices ADV7511W HDMI transmitter (but we're only describing
the former chips now).
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
---
Changes in version 2:
- added Simon's tag.
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 27 ++++++++++++++++++++++++
1 file changed, 27 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -80,6 +80,28 @@
clock-frequency = <32768>;
};
+&i2c0 {
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+ clock-frequency = <400000>;
+
+ io_expander0: gpio at 20 {
+ compatible = "onnn,pca9654";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ io_expander1: gpio at 21 {
+ compatible = "onnn,pca9654";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
&mmc0 {
pinctrl-0 = <&mmc_pins>;
pinctrl-1 = <&mmc_pins_uhs>;
@@ -104,6 +126,11 @@
function = "canfd0";
};
+ i2c0_pins: i2c0 {
+ groups = "i2c0";
+ function = "i2c0";
+ };
+
mmc_pins: mmc {
groups = "mmc_data8", "mmc_ctrl", "mmc_ds";
function = "mmc";
^ permalink raw reply
* [PATCH] MAINTAINERS: Add Actions Semi S900 clk entries
From: Stephen Boyd @ 2018-05-31 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527780180-15041-1-git-send-email-manivannan.sadhasivam@linaro.org>
Quoting Manivannan Sadhasivam (2018-05-31 08:23:00)
> Add S900 clk entries under ARCH_ACTIONS
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
Unless you wanted me to apply this?
^ permalink raw reply
* [PATCH] MAINTAINERS: Add Actions Semi S900 clk entries
From: Andreas Färber @ 2018-05-31 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152779875340.144038.4898809848995507014@swboyd.mtv.corp.google.com>
Am 31.05.2018 um 22:32 schrieb Stephen Boyd:
> Quoting Manivannan Sadhasivam (2018-05-31 08:23:00)
>> Add S900 clk entries under ARCH_ACTIONS
>>
>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>> ---
>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
>
> Unless you wanted me to apply this?
I'll take it once I have my 4.17 branches rebased to 4.18.
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH] arm64: alternative:flush cache with unpatched code
From: Rohit Khanna @ 2018-05-31 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In the current implementation, __apply_alternatives patches
flush_icache_range and then executes it without invalidating the icache.
Thus, icache can contain some of the old instructions for
flush_icache_range. This can cause unpredictable behavior as during
execution we can get a mix of old and new instructions for
flush_icache_range.
This patch :
1. Adds a new function clean_dcache_range_nopatch for flushing kernel
memory range. This function uses non hot-patched code and can be
safely used to flush cache during code patching.
2. Modifies __apply_alternatives so that it uses
clean_dcache_range_nopatch to flush the cache range after patching code.
Signed-off-by: Rohit Khanna <rokhanna@nvidia.com>
---
arch/arm64/include/asm/sysreg.h | 3 +++
arch/arm64/kernel/alternative.c | 37 ++++++++++++++++++++++++++++++++++++-
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 6171178075dc..9d1aee7c9aba 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -617,6 +617,9 @@
#define MVFR1_FPDNAN_SHIFT 4
#define MVFR1_FPFTZ_SHIFT 0
+/* SYS_CTR_EL0 */
+#define SYS_CTR_ISIZE_SHIFT 0
+#define SYS_CTR_DSIZE_SHIFT 16
#define ID_AA64MMFR0_TGRAN4_SHIFT 28
#define ID_AA64MMFR0_TGRAN64_SHIFT 24
diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
index 5c4bce4ac381..6b8c5438b37b 100644
--- a/arch/arm64/kernel/alternative.c
+++ b/arch/arm64/kernel/alternative.c
@@ -122,6 +122,41 @@ static void patch_alternative(struct alt_instr *alt,
}
}
+/* This is used for flushing kernel memory range after
+ * __apply_alternatives has patched kernel code
+ */
+static void clean_dcache_range_nopatch(void *start, void *end)
+{
+ u64 d_start, i_start, d_size, i_size, ctr_el0;
+
+ /* use sanitised value of ctr_el0 rather than raw value from CPU */
+ ctr_el0 = read_sanitised_ftr_reg(SYS_CTR_EL0);
+ /* size in bytes */
+ d_size = cpuid_feature_extract_unsigned_field(ctr_el0,
+ SYS_CTR_DSIZE_SHIFT);
+ i_size = cpuid_feature_extract_unsigned_field(ctr_el0,
+ SYS_CTR_ISIZE_SHIFT);
+
+ d_start = (u64)start & ~(d_size - 1);
+ while (d_start <= (u64)end) {
+ /* Use civac instead of cvau. This is required
+ * due to ARM errata 826319, 827319, 824069,
+ * 819472 on A53
+ */
+ asm volatile("dc civac, %0" : : "r" (d_start));
+ d_start += d_size;
+ }
+ dsb(ish);
+
+ i_start = (u64)start & ~(i_size - 1);
+ while (i_start <= (u64)end) {
+ asm volatile("ic ivau, %0" : : "r" (i_start));
+ i_start += i_size;
+ }
+ dsb(ish);
+ isb();
+}
+
static void __apply_alternatives(void *alt_region, bool use_linear_alias)
{
struct alt_instr *alt;
@@ -155,7 +190,7 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
alt_cb(alt, origptr, updptr, nr_inst);
- flush_icache_range((uintptr_t)origptr,
+ clean_dcache_range_nopatch((uintptr_t)origptr,
(uintptr_t)(origptr + nr_inst));
}
}
--
2.1.4
^ permalink raw reply related
* [PATCH v2 1/2] ARM: debug: Add Iproc UART3 debug addresses
From: Florian Fainelli @ 2018-05-31 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41bbf801-f060-2056-4015-b4d05c6831bb@broadcom.com>
On 05/31/2018 10:24 AM, Ray Jui wrote:
>
>
> On 5/31/2018 1:22 AM, Cl?ment P?ron wrote:
>> Hi Rai,
>>
>> On Wed, 30 May 2018 at 19:25, Ray Jui <ray.jui@broadcom.com> wrote:
>>>
>>> Hi Cl?ment,
>>>
>>> Correct me if I'm wrong, but I thought the trend is to move to use
>>> earlycon that can be activated from kernel command line for early print
>>> before the serial driver is loaded.
>>>
>>> Have you tried earlcon?
>> No, only tested this method.
>>
>> Thanks,
>> Clement
>>
>
> If I remember it correctly, I think the trend is to use earlycon. There
> are obvious shortcomings by making this configuration compile time based.
This is true, though on ARM 32-bit kernels DEBUG_LL gets used by the
kernel self-decompressor and also before earlycon has a chance to run,
this is useful to debugging memory issues where your memory
configuration is incorrect typically.
Either way is fine with me (accepting or dropping) the patch, though
there is probably minimal impact in just accepting such a change.
--
Florian
^ permalink raw reply
* linux-next: manual merge of the regulator tree with the arm-soc tree
From: Janusz Krzysztofik @ 2018-05-31 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaotBXbA4pPFHRH0S1SF7-XX_T6yAOwZcbsR3RBcj+-=Q@mail.gmail.com>
On Wednesday, May 30, 2018 9:29:24 AM CEST Linus Walleij wrote:
> On Wed, May 30, 2018 at 7:07 AM, Stephen Rothwell <sfr@canb.auug.org.au>
wrote:
> > Hi all,
> >
> > Today's linux-next merge of the regulator tree got a conflict in:
> > arch/arm/mach-omap1/board-ams-delta.c
> >
> > between commit:
> > 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables")
> >
> > from the arm-soc tree and commit:
> > 6059577cb28d ("regulator: fixed: Convert to use GPIO descriptor only")
> >
> > from the regulator tree.
> >
> > I fixed it up (see below - it may be better done) and can carry the fix
> > as necessary.
>
> OMG that patch on a patch makes my head spin.
>
> I think I just have to look at the eventual result in linux-next and see if
> it makes proper sense, and rely on Janusz to test the result and help
> to fix it up.
Hi,
I confirm the fix by Stephen works for me, however, the conflicting patch by
Linus breaks things a bit.
Lookup tables added to board files use function name "enable" while the
regulator uses NULL. As a result, GPIO descriptor is not matched and not
assigned to the regulator which ends up running with no control over GPIO pin.
Either the regulator driver should use the function name "enable" or that name
should be removed from lookup tables.
Thanks,
Janusz
^ permalink raw reply
* [RFC PATCH] PCI: mediatek: mtk_pcie_pm_ops can be static
From: kbuild test robot @ 2018-06-01 0:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527647736-19986-1-git-send-email-honghui.zhang@mediatek.com>
Fixes: 24dc21cd1e9d ("PCI: mediatek: Add system pm support for MT2712")
Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
---
pcie-mediatek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index e3b16b0..e01cc66 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -1256,7 +1256,7 @@ static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
return 0;
}
-const struct dev_pm_ops mtk_pcie_pm_ops = {
+static const struct dev_pm_ops mtk_pcie_pm_ops = {
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_pcie_suspend_noirq,
mtk_pcie_resume_noirq)
};
^ permalink raw reply related
* [PATCH] PCI: mediatek: Add system pm support for MT2712
From: kbuild test robot @ 2018-06-01 0:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527647736-19986-1-git-send-email-honghui.zhang@mediatek.com>
Hi Honghui,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on pci/next]
[also build test WARNING on next-20180531]
[cannot apply to v4.17-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/honghui-zhang-mediatek-com/PCI-mediatek-Add-system-pm-support-for-MT2712/20180601-053217
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/pci/host/pcie-mediatek.c:463:40: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile *address @@ got void [novoid volatile *address @@
drivers/pci/host/pcie-mediatek.c:463:40: expected void volatile *address
drivers/pci/host/pcie-mediatek.c:463:40: got void [noderef] <asn:2>*
drivers/pci/host/pcie-mediatek.c:586:44: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile *address @@ got void [novoid volatile *address @@
drivers/pci/host/pcie-mediatek.c:586:44: expected void volatile *address
drivers/pci/host/pcie-mediatek.c:586:44: got void [noderef] <asn:2>*
>> drivers/pci/host/pcie-mediatek.c:1259:25: sparse: symbol 'mtk_pcie_pm_ops' was not declared. Should it be static?
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH v3 2/5] gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
From: Levin @ 2018-06-01 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJK4vrmLBeN_ZeGCXAyqshshL16B0KN_+8uvt+=-O9TEw@mail.gmail.com>
Hi Rob,
On 2018-05-31 10:45 PM, Rob Herring wrote:
> On Wed, May 30, 2018 at 10:27 PM, <djw@t-chip.com.cn> wrote:
>> From: Levin Du <djw@t-chip.com.cn>
>>
>> In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
>> mute control, can also be used for general purpose. It is manipulated by
>> the GRF_SOC_CON10 register.
>>
>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>>
>> ---
>>
>> Changes in v3:
>> - Change from general gpio-syscon to specific rk3328-gpio-mute
>>
>> Changes in v2:
>> - Rename gpio_syscon10 to gpio_mute in doc
>>
>> Changes in v1:
>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>> - Add doc rockchip,gpio-syscon.txt
>>
>> .../bindings/gpio/rockchip,rk3328-gpio-mute.txt | 28 +++++++++++++++++++
>> drivers/gpio/gpio-syscon.c | 31 ++++++++++++++++++++++
>> 2 files changed, 59 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>> new file mode 100644
>> index 0000000..10bc632
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>> @@ -0,0 +1,28 @@
>> +Rockchip RK3328 GPIO controller dedicated for the GPIO_MUTE pin.
>> +
>> +In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec mute
>> +control, can also be used for general purpose. It is manipulated by the
>> +GRF_SOC_CON10 register.
>> +
>> +Required properties:
>> +- compatible: Should contain "rockchip,rk3328-gpio-mute".
>> +- gpio-controller: Marks the device node as a gpio controller.
>> +- #gpio-cells: Should be 2. The first cell is the pin number and
>> + the second cell is used to specify the gpio polarity:
>> + 0 = Active high,
>> + 1 = Active low.
>> +
>> +Example:
>> +
>> + grf: syscon at ff100000 {
>> + compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
>> +
>> + gpio_mute: gpio-mute {
> Node names should be generic:
>
> gpio {
>
> This also means you can't add another GPIO node in the future and
> you'll have to live with "rockchip,rk3328-gpio-mute" covering more
> than 1 GPIO if you do need to add more GPIOs.
As the first line describes, this GPIO controller is dedicated for the
GPIO_MUTE pin.
There's only one GPIO pin in the GRF_SOC_CON10 register. Therefore the
gpio_mute
name is proper IMHO.
>> + compatible = "rockchip,rk3328-gpio-mute";
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>> + };
>> +
>> +Note: The gpio_mute node should be declared as the child of the GRF (General
>> +Register File) node. The GPIO_MUTE pin is referred to as <&gpio_mute 0>.
> This is wrong because you should have 2 cells. The phandle doesn't
> count as a cell.
>
> Rob
>
Thanks for pointing that out. So it should be:
?? The GPIO_MUTE pin is referred to as <&gpio_mute 0 POLARITY>.
Thanks,
Levin
^ permalink raw reply
* [PATCH v3] PCI: mediatek: Add system pm support for MT2712
From: honghui.zhang at mediatek.com @ 2018-06-01 3:04 UTC (permalink / raw)
To: linux-arm-kernel
From: Honghui Zhang <honghui.zhang@mediatek.com>
The MTCMOS of PCIe Host for MT2712 will be off when system suspend, and all
the internal control register will be reset after system resume. The PCIe
link should be re-established and the related control register values
should be re-set after system resume.
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
CC: Ryder Lee <ryder.lee@mediatek.com>
---
drivers/pci/host/pcie-mediatek.c | 60 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index dabf1086..5363cc7 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -132,12 +132,14 @@ struct mtk_pcie_port;
/**
* struct mtk_pcie_soc - differentiate between host generations
* @need_fix_class_id: whether this host's class ID needed to be fixed or not
+ * @pm_support: whether the host's MTCMOS will be off when suspend
* @ops: pointer to configuration access functions
* @startup: pointer to controller setting functions
* @setup_irq: pointer to initialize IRQ functions
*/
struct mtk_pcie_soc {
bool need_fix_class_id;
+ bool pm_support;
struct pci_ops *ops;
int (*startup)(struct mtk_pcie_port *port);
int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
@@ -1179,12 +1181,69 @@ static int mtk_pcie_probe(struct platform_device *pdev)
return err;
}
+#ifdef CONFIG_PM_SLEEP
+static int mtk_pcie_suspend_noirq(struct device *dev)
+{
+ struct mtk_pcie *pcie = dev_get_drvdata(dev);
+ const struct mtk_pcie_soc *soc = pcie->soc;
+ struct mtk_pcie_port *port;
+
+ if (!soc->pm_support)
+ return 0;
+
+ list_for_each_entry(port, &pcie->ports, list) {
+ clk_disable_unprepare(port->ahb_ck);
+ clk_disable_unprepare(port->sys_ck);
+ phy_power_off(port->phy);
+ }
+
+ return 0;
+}
+
+static int mtk_pcie_resume_noirq(struct device *dev)
+{
+ struct mtk_pcie *pcie = dev_get_drvdata(dev);
+ const struct mtk_pcie_soc *soc = pcie->soc;
+ struct mtk_pcie_port *port;
+ int ret;
+
+ if (!soc->pm_support)
+ return 0;
+
+ list_for_each_entry(port, &pcie->ports, list) {
+ phy_power_on(port->phy);
+ clk_prepare_enable(port->sys_ck);
+ clk_prepare_enable(port->ahb_ck);
+
+ ret = soc->startup(port);
+ if (ret) {
+ dev_err(dev, "Port%d link down\n", port->slot);
+ phy_power_off(port->phy);
+ clk_disable_unprepare(port->sys_ck);
+ clk_disable_unprepare(port->ahb_ck);
+ return ret;
+ }
+
+ if (IS_ENABLED(CONFIG_PCI_MSI))
+ mtk_pcie_enable_msi(port);
+ }
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops mtk_pcie_pm_ops = {
+ SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_pcie_suspend_noirq,
+ mtk_pcie_resume_noirq)
+};
+
static const struct mtk_pcie_soc mtk_pcie_soc_v1 = {
.ops = &mtk_pcie_ops,
.startup = mtk_pcie_startup_port,
};
static const struct mtk_pcie_soc mtk_pcie_soc_mt2712 = {
+ .pm_support = true,
.ops = &mtk_pcie_ops_v2,
.startup = mtk_pcie_startup_port_v2,
.setup_irq = mtk_pcie_setup_irq,
@@ -1211,6 +1270,7 @@ static struct platform_driver mtk_pcie_driver = {
.name = "mtk-pcie",
.of_match_table = mtk_pcie_ids,
.suppress_bind_attrs = true,
+ .pm = &mtk_pcie_pm_ops,
},
};
builtin_platform_driver(mtk_pcie_driver);
--
2.6.4
^ permalink raw reply related
* [PATCH 6/6] arm64: dts: socionext: Add missing cooling device properties for CPUs
From: Masahiro Yamada @ 2018-06-01 3:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <744f4c0a9a6f0d3acfc36e49ef62f17f53831b3b.1527225682.git.viresh.kumar@linaro.org>
2018-05-25 14:40 GMT+09:00 Viresh Kumar <viresh.kumar@linaro.org>:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
>
> Add such missing properties.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Applied to linux-uniphier.
I had already sent a PR for v4.18-rc1 before I received this patch.
Please wait for v4.19-rc1.
Thanks.
> ---
> arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
> index 3a5ed789c056..10ffb5019013 100644
> --- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
> +++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
> @@ -58,6 +58,7 @@
> clocks = <&sys_clk 32>;
> enable-method = "psci";
> operating-points-v2 = <&cluster0_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu2: cpu at 100 {
> @@ -77,6 +78,7 @@
> clocks = <&sys_clk 33>;
> enable-method = "psci";
> operating-points-v2 = <&cluster1_opp>;
> + #cooling-cells = <2>;
> };
> };
>
> --
> 2.15.0.194.g9af6a3dea062
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH 05/15] arm: dts: uniphier: Add missing cooling device properties for CPUs
From: Masahiro Yamada @ 2018-06-01 3:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51ac4a5f0466aeed3f223663d9c34d6345b2a1f2.1527244201.git.viresh.kumar@linaro.org>
2018-05-25 19:31 GMT+09:00 Viresh Kumar <viresh.kumar@linaro.org>:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
>
> Add such missing properties.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Applied to linux-uniphier.
I had already sent a PR for v4.18-rc1 before I received this patch.
Please wait for v4.19-rc1.
Thanks.
> ---
> arch/arm/boot/dts/uniphier-pxs2.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> index debcbd15c24b..40ed15465095 100644
> --- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
> +++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> @@ -36,6 +36,7 @@
> enable-method = "psci";
> next-level-cache = <&l2>;
> operating-points-v2 = <&cpu_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu2: cpu at 2 {
> @@ -46,6 +47,7 @@
> enable-method = "psci";
> next-level-cache = <&l2>;
> operating-points-v2 = <&cpu_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu3: cpu at 3 {
> @@ -56,6 +58,7 @@
> enable-method = "psci";
> next-level-cache = <&l2>;
> operating-points-v2 = <&cpu_opp>;
> + #cooling-cells = <2>;
> };
> };
>
> --
> 2.15.0.194.g9af6a3dea062
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH 0/3] arm64: allwinner: a64: Add initial support for Pinebook
From: Vasily Khoruzhick @ 2018-06-01 6:28 UTC (permalink / raw)
To: linux-arm-kernel
This series adds dts for Pinebook with few prerequisites - PWM and R_I2C
devices nodes.
Andre Przywara (1):
dts: sunxi: A64: Add PWM controllers
Icenowy Zheng (2):
arm64: allwinner: a64: add R_I2C controller
arm64: dts: allwinner: add support for Pinebook
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../dts/allwinner/sun50i-a64-pinebook.dts | 285 ++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 45 +++
3 files changed, 331 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
--
2.17.1
^ permalink raw reply
* [PATCH 1/3] arm64: allwinner: a64: add R_I2C controller
From: Vasily Khoruzhick @ 2018-06-01 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601062901.8052-1-anarsoul@gmail.com>
From: Icenowy Zheng <icenowy@aosc.io>
Allwinner A64 has a I2C controller, which is in the R_ MMIO zone and has
two groups of pinmuxes on PL bank, so it's called R_I2C.
Add support for this I2C controller and the pinmux which doesn't conflict
with RSB.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 1b2ef28c42bd..b5e903ccf0ec 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -46,6 +46,7 @@
#include <dt-bindings/clock/sun8i-r-ccu.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/sun50i-a64-ccu.h>
+#include <dt-bindings/reset/sun8i-r-ccu.h>
/ {
interrupt-parent = <&gic>;
@@ -655,6 +656,17 @@
#reset-cells = <1>;
};
+ r_i2c: i2c at 1f02400 {
+ compatible = "allwinner,sun6i-a31-i2c";
+ reg = <0x01f02400 0x400>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu CLK_APB0_I2C>;
+ resets = <&r_ccu RST_APB0_I2C>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
r_pio: pinctrl at 1f02c00 {
compatible = "allwinner,sun50i-a64-r-pinctrl";
reg = <0x01f02c00 0x400>;
@@ -670,6 +682,11 @@
pins = "PL0", "PL1";
function = "s_rsb";
};
+
+ r_i2c_pins_a: i2c-a {
+ pins = "PL8", "PL9";
+ function = "s_i2c";
+ };
};
r_rsb: rsb at 1f03400 {
--
2.17.1
^ permalink raw reply related
* [PATCH 2/3] dts: sunxi: A64: Add PWM controllers
From: Vasily Khoruzhick @ 2018-06-01 6:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601062901.8052-1-anarsoul@gmail.com>
From: Andre Przywara <andre.przywara@arm.com>
The Allwinner A64 SoC features two PWM controllers, which are fully
compatible to the one used in the A13 and H3 chips.
Add the nodes for the devices (one for the "normal" PWM, the other for
the one in the CPUS domain) and the pins their outputs are connected to.
On the A64 the "normal" PWM is muxed together with one of the MDIO pins
used to communicate with the Ethernet PHY, so it won't be usable on many
boards. But the Pinebook laptop uses this pin for controlling the LCD
backlight.
On Pine64 the CPUS PWM pin however is routed to the "RPi2" header,
at the same location as the PWM pin on the RaspberryPi.
[vasily: fixed comment message as requested by Stefan Bruens]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> on Pinebook (only the "normal" PWM)
Tested-by: Harald Geyer <harald@ccbib.org> on Teres-I (only the "normal" PWM)
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 28 +++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index b5e903ccf0ec..e94bfa8477f6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -365,6 +365,11 @@
bias-pull-up;
};
+ pwm_pin: pwm_pin {
+ pins = "PD22";
+ function = "pwm";
+ };
+
rmii_pins: rmii_pins {
pins = "PD10", "PD11", "PD13", "PD14", "PD17",
"PD18", "PD19", "PD20", "PD22", "PD23";
@@ -630,6 +635,15 @@
#interrupt-cells = <3>;
};
+ pwm: pwm at 1c21400 {
+ compatible = "allwinner,sun50i-a64-pwm",
+ "allwinner,sun5i-a13-pwm";
+ reg = <0x01c21400 0x400>;
+ clocks = <&osc24M>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
rtc: rtc at 1f00000 {
compatible = "allwinner,sun6i-a31-rtc";
reg = <0x01f00000 0x54>;
@@ -667,6 +681,15 @@
#size-cells = <0>;
};
+ r_pwm: pwm at 1f03800 {
+ compatible = "allwinner,sun50i-a64-pwm",
+ "allwinner,sun5i-a13-pwm";
+ reg = <0x01f03800 0x400>;
+ clocks = <&osc24M>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
r_pio: pinctrl at 1f02c00 {
compatible = "allwinner,sun50i-a64-r-pinctrl";
reg = <0x01f02c00 0x400>;
@@ -687,6 +710,11 @@
pins = "PL8", "PL9";
function = "s_i2c";
};
+
+ r_pwm_pin: pwm {
+ pins = "PL10";
+ function = "s_pwm";
+ };
};
r_rsb: rsb at 1f03400 {
--
2.17.1
^ permalink raw reply related
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