* [PATCH 03/19] dt-bindings: mrvl, intc: Add a MMP3 interrupt controller
From: Lubomir Rintel @ 2019-08-09 9:31 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, Jason Cooper, Stephen Boyd,
Marc Zyngier, Michael Turquette, Russell King,
Kishon Vijay Abraham I, Lubomir Rintel, Rob Herring,
linux-arm-kernel, Thomas Gleixner, linux-clk, linux-kernel
In-Reply-To: <20190809093158.7969-1-lkundrak@v3.sk>
Similar to MMP2 one, but has an extra range for the other core. The
muxes stay the same.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
.../interrupt-controller/mrvl,intc.txt | 23 ++++++++++++++-----
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.txt b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.txt
index 608fee15a4cfc..41c131d026f94 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.txt
@@ -1,13 +1,15 @@
* Marvell MMP Interrupt controller
Required properties:
-- compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc" or
- "mrvl,mmp2-mux-intc"
+- compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc",
+ "marvell,mmp3-intc", "mrvl,mmp2-mux-intc"
- reg : Address and length of the register set of the interrupt controller.
If the interrupt controller is intc, address and length means the range
- of the whole interrupt controller. If the interrupt controller is mux-intc,
- address and length means one register. Since address of mux-intc is in the
- range of intc. mux-intc is secondary interrupt controller.
+ of the whole interrupt controller. The "marvell,mmp3-intc" controller
+ also has a secondary range for the second CPU core. If the interrupt
+ controller is mux-intc, address and length means one register. Since
+ address of mux-intc is in the range of intc. mux-intc is secondary
+ interrupt controller.
- reg-names : Name of the register set of the interrupt controller. It's
only required in mux-intc interrupt controller.
- interrupts : Should be the port interrupt shared by mux interrupts. It's
@@ -20,7 +22,7 @@ Required properties:
- mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
detection first.
-Example:
+Examples:
intc: interrupt-controller@d4282000 {
compatible = "mrvl,mmp2-intc";
interrupt-controller;
@@ -29,6 +31,15 @@ Example:
mrvl,intc-nr-irqs = <64>;
};
+ intc: interrupt-controller@d4282000 {
+ compatible = "marvell,mmp3-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0xd4282000 0x1000>,
+ <0xd4284000 0x100>;
+ mrvl,intc-nr-irqs = <64>;
+ };
+
intcmux4@d4282150 {
compatible = "mrvl,mmp2-mux-intc";
interrupts = <4>;
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 00/19] Initial support for Marvell MMP3 SoC
From: Lubomir Rintel @ 2019-08-09 9:31 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, Jason Cooper, Stephen Boyd,
Marc Zyngier, Michael Turquette, Russell King,
Kishon Vijay Abraham I, Rob Herring, linux-arm-kernel,
Thomas Gleixner, linux-clk, linux-kernel
Hi,
this patch set adds support for the Marvell MMP3 processor. MMP3 is used
in OLPC XO-4 laptops, Panasonic Toughpad FZ-A1 tablet and Dell Wyse 3020
Tx0D thin clients.
Apart from the adjustments in mach-mmp/, the patch makes necessary
changes to the irqchip driver and adds an USB2 PHY driver. The latter
has a dependency on the mach-mmp/ changes, so it can't be submitted
separately.
The patch set has been tested to work on Wyse Tx0D and not ruin MMP2
support on XO-1.75.
Lubo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/2] dt-bindings: net: meson-dwmac: convert to yaml
From: Neil Armstrong @ 2019-08-09 9:31 UTC (permalink / raw)
To: David Miller
Cc: devicetree, martin.blumenstingl, netdev, linux-kernel, robh+dt,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20190808.112033.180369877501058953.davem@davemloft.net>
Hi,
On 08/08/2019 20:20, David Miller wrote:
> From: Neil Armstrong <narmstrong@baylibre.com>
> Date: Thu, 8 Aug 2019 13:40:59 +0200
>
>> This patchsets converts the Amlogic Meson DWMAC glue bindings over to
>> YAML schemas using the already converted dwmac bindings.
>>
>> The first patch is needed because the Amlogic glue needs a supplementary
>> reg cell to access the DWMAC glue registers.
>>
>> Changes since v2:
>> - Added review tags
>> - Updated allwinner,sun7i-a20-gmac.yaml reg maxItems
>
> Where is this targetted to be merged, an ARM tree? Or one of my
> networking trees?
>
I assume you can take it in one of your net trees.
Thanks,
Neil
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/9] drm: meson: global clean-up (use proper macros, update comments ...)
From: Neil Armstrong @ 2019-08-09 9:29 UTC (permalink / raw)
To: Kevin Hilman, Julien Masson
Cc: linux-amlogic, dri-devel, linux-arm-kernel, linux-kernel
In-Reply-To: <61b73415-73be-bb72-37f4-0a6060f85ffa@baylibre.com>
Hi Julien,
On 08/08/2019 16:12, Neil Armstrong wrote:
> On 25/06/2019 01:24, Kevin Hilman wrote:
>> Julien Masson <jmasson@baylibre.com> writes:
>>
>>> This patch series aims to clean-up differents parts of the drm meson
>>> code source.
>>>
>>> Couple macros have been defined and used to set several registers
>>> instead of using magic constants.
>>>
>>> I also took the opportunity to:
>>> - add/remove/update comments
>>> - remove useless code
>>> - minor fix/improvment
>>
>> Nice set of cleanups, thanks! I especially like the extra in-code
>> comments.
>>
>> Could you also add to the cover-letter how this was tested, and on what
>> platforms so we know it's not going to introduce any regressions.
>>
>> Thanks,
>>
>> Kevin
>>
>
> Apart the wrong magic value in patch 4 that I'll fix while applying,
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
>
> I'll run a few tests on all the supported SoC versions:
> - GXBB
> - GXL
> - GXM
> - G12A/G12B
Tested on :
- 1024x768x60 DVI Dell monitor
- 3840x2160x60 HDMI2.0 Samsung TV
Tested :
- Simple DMT mode
- Advanced HDMI2.0 4k60 mode with SCDC negotiation and scrambling
- OSD layer and scaling
- Video layer and scaling
SoCs:
- GXBB: meson-gxbb-odroidc2
modetest -M meson -s 32:1024x768-60 -P 33@37:1024x768@AR24 -P 35@37:1024x768@NV12
modetest -M meson -s 32:1024x768-60 -P 33@37:1024x768@AR24 -P 35@37:1024x768*2@NV12
modetest -M meson -s 32:1024x768-60 -P 33@37:512x384*2@AR24 -P 35@37:2048x1536*0.5@NV12
modetest -M meson -s 32:3840x2160-60 -P 33@37:3840x2160@AR24 -P 35@37:3840x2160@NV12
modetest -M meson -s 32:3840x2160-60 -P 33@37:1920x1080*2@AR24 -P 35@37:3840x2160*0.8@NV12
No visual issues
- GXL: meson-gxl-s905x-libretech-cc
modetest -M meson -s 34:1024x768-60 -P 35@39:1024x768@AR24 -P 37@39:1024x768@NV12
modetest -M meson -s 34:1024x768-60 -P 35@39:1024x768@AR24 -P 37@39:1024x768*2@NV12
modetest -M meson -s 34:1024x768-60 -P 35@39:512x384*2@AR24 -P 37@39:2048x1536*0.5@NV12
modetest -M meson -s 34:3840x2160-60 -P 35@39:3840x2160@AR24 -P 37@39:3840x2160@NV12
modetest -M meson -s 34:3840x2160-60 -P 35@39:1920x1080*2@AR24 -P 37@39:3840x2160*0.8@NV12
No visual issues
- GXM: meson-gxm-khadas-vim2
modetest -M meson -s 32:1024x768-60 -P 33@37:1024x768@AR24 -P 35@37:1024x768@NV12
modetest -M meson -s 32:1024x768-60 -P 33@37:1024x768@AR24 -P 35@37:1024x768*2@NV12
modetest -M meson -s 32:1024x768-60 -P 33@37:512x384*2@AR24 -P 35@37:2048x1536*0.5@NV12
modetest -M meson -s 32:3840x2160-60 -P 33@37:3840x2160@AR24 -P 35@37:3840x2160@NV12
modetest -M meson -s 32:3840x2160-60 -P 33@37:1920x1080*2@AR24 -P 35@37:3840x2160*0.8@NV12
With the following fix on patch 4:
========><====================================
--- a/drivers/gpu/drm/meson/meson_vpp.c
+++ b/drivers/gpu/drm/meson/meson_vpp.c
@@ -98,7 +98,7 @@ void meson_vpp_init(struct meson_drm *priv)
priv->io_base + _REG(VIU_MISC_CTRL1));
writel_relaxed(VPP_PPS_DUMMY_DATA_MODE,
priv->io_base + _REG(VPP_DOLBY_CTRL));
- writel_relaxed(0x108080,
+ writel_relaxed(0x1020080,
priv->io_base + _REG(VPP_DUMMY_DATA1));
} else if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu"))
writel_relaxed(0xf, priv->io_base + _REG(DOLBY_PATH_CTRL));
========><====================================
No visual issues
- G12A/G12B: meson-g12a-sei510
Issue found in patch 5, the following fix will be applied while applying onto drm-misc-next :
========><====================================
--- a/drivers/gpu/drm/meson/meson_viu.c
+++ b/drivers/gpu/drm/meson/meson_viu.c
@@ -407,7 +407,7 @@ void meson_viu_init(struct meson_drm *priv)
VIU_OSD_BLEND_HOLD_LINES(4),
priv->io_base + _REG(VIU_OSD_BLEND_CTRL));
- writel_relaxed(VIU_OSD1_POSTBLD_SRC_OSD1,
+ writel_relaxed(OSD_BLEND_PATH_SEL_ENABLE,
priv->io_base + _REG(OSD1_BLEND_SRC_CTRL));
writel_relaxed(OSD_BLEND_PATH_SEL_ENABLE,
priv->io_base + _REG(OSD2_BLEND_SRC_CTRL));
========><====================================
modetest -M meson -s 34:800x600 -P 35@39:800x600@AR24 -P 37@39:800x600@NV12
modetest -M meson -s 34:800x600 -P 35@39:800x600@AR24 -P 37@39:800x600*2@NV12
modetest -M meson -s 34:800x600 -P 35@39:400x300*2@AR24 -P 37@39:1600x600*0.5@NV12
modetest -M meson -s 34:3840x2160-60 -P 35@39:3840x2160@AR24 -P 37@39:3840x2160@NV12
modetest -M meson -s 34:3840x2160-60 -P 35@39:1920x1080*2@AR24 -P 37@39:3840x2160*0.8@NV12
No visual issues
>
> and push to drm-misc-next.
>
> Neil
>
Applying to drm-misc-next with the fixes
Neil
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v19 00/15] arm64: untag user pointers passed to the kernel
From: Dave Martin @ 2019-08-09 9:28 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Rutland, kvm, Szabolcs Nagy, Will Deacon, dri-devel,
Kostya Serebryany, Khalid Aziz,
open list:KERNEL SELFTEST FRAMEWORK, Vincenzo Frascino,
Will Deacon, Jacob Bramley, Leon Romanovsky, linux-rdma, amd-gfx,
Christoph Hellwig, Jason Gunthorpe, Linux ARM,
Ramana Radhakrishnan, Evgeniy Stepanov, linux-media, Kees Cook,
Ruben Ayrapetyan, Andrey Konovalov, Kevin Brodsky,
Alex Williamson, Yishai Hadas, Mauro Carvalho Chehab,
Dmitry Vyukov, Linux Memory Management List, Greg Kroah-Hartman,
Felix Kuehling, Dave Hansen, LKML, Jens Wiklander, Lee Smith,
Alexander Deucher, Andrew Morton, enh, Robin Murphy,
Christian Koenig, Luc Van Oostenryck
In-Reply-To: <20190809090016.GA23083@arrakis.emea.arm.com>
On Fri, Aug 09, 2019 at 10:00:17AM +0100, Catalin Marinas wrote:
> On Thu, Aug 08, 2019 at 04:09:04PM -0700, Kees Cook wrote:
> > On Thu, Aug 08, 2019 at 03:33:00PM -0700, Andrew Morton wrote:
> > > On Thu, 8 Aug 2019 14:12:19 -0700 Kees Cook <keescook@chromium.org> wrote:
> > >
> > > > > The ones that are left are the mm ones: 4, 5, 6, 7 and 8.
> > > > >
> > > > > Andrew, could you take a look and give your Acked-by or pick them up directly?
> > > >
> > > > Given the subsystem Acks, it seems like 3-10 and 12 could all just go
> > > > via Andrew? I hope he agrees. :)
> > >
> > > I'll grab everything that has not yet appeared in linux-next. If more
> > > of these patches appear in linux-next I'll drop those as well.
> > >
> > > The review discussion against " [PATCH v19 02/15] arm64: Introduce
> > > prctl() options to control the tagged user addresses ABI" has petered
> > > out inconclusively. prctl() vs arch_prctl().
> >
> > I've always disliked arch_prctl() existing at all. Given that tagging is
> > likely to be a multi-architectural feature, it seems like the controls
> > should live in prctl() to me.
>
> It took a bit of grep'ing to figure out what Dave H meant by
> arch_prctl(). It's an x86-specific syscall which we do not have on arm64
> (and possibly any other architecture). Actually, we don't have any arm64
> specific syscalls, only the generic unistd.h, hence the confusion. For
> other arm64-specific prctls like SVE we used the generic sys_prctl() and
> I can see x86 not being consistent either (PR_MPX_ENABLE_MANAGEMENT).
>
> In general I disagree with adding any arm64-specific syscalls but in
> this instance it can't even be justified. I'd rather see some clean-up
> similar to arch_ptrace/ptrace_request than introducing new syscall
> numbers (but as I suggested in my reply to Dave, that's for another
> patch series).
I had a go at refactoring this a while ago, but it fell by the wayside.
I can try to resurrect it if it's still considered worthwhile.
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] coresight: tmc-etr: Remove perf_data check.
From: Suzuki K Poulose @ 2019-08-09 9:22 UTC (permalink / raw)
To: yabinc, mathieu.poirier, alexander.shishkin
Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20190808193122.76679-1-yabinc@google.com>
Hi Yabin,
Thank you for the analysis and the patch.
On 08/08/2019 20:31, Yabin Cui wrote:
> When tracing etm data of multiple threads on multiple cpus through
> perf interface, each cpu has a unique etr_perf_buffer while sharing
> the same etr device. There is no guarantee that the last cpu starts
> etm tracing also stops last. So the perf_data check is no longer valid.
>
> Signed-off-by: Yabin Cui <yabinc@google.com>
> ---
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 9 ---------
> drivers/hwtracing/coresight/coresight-tmc.h | 2 --
> 2 files changed, 11 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 17006705287a..0418440e0141 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -1484,20 +1484,12 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
> goto out;
> }
>
> - if (WARN_ON(drvdata->perf_data != etr_perf)) {
> - lost = true;
> - spin_unlock_irqrestore(&drvdata->spinlock, flags);
> - goto out;
> - }
> -
I think some sort of sanity check is a good idea to make sure we don't loose the
context. Even when different CPUs have different etr_perf buffer, the underlying
etr_buf should be the same. So, we should be able to simply convert the check
to, something like :
struct etr_perf_buffer *perf_buf = drvdata->perf_data;
...
if (WARN_ON(perf_buf->etr_buf != etr_perf->buf)) {
....
}
Does that solve the problem for you ?
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 10/22] usb: omap: avoid mach/*.h headers
From: Greg Kroah-Hartman @ 2019-08-09 5:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Felipe Balbi, linux-usb, Aaro Koskinen, Tony Lindgren,
Linus Walleij, Bartlomiej Zolnierkiewicz, linux-kernel,
Tomi Valkeinen, Alan Stern, linux-omap, linux-arm-kernel
In-Reply-To: <20190808212234.2213262-11-arnd@arndb.de>
On Thu, Aug 08, 2019 at 11:22:19PM +0200, Arnd Bergmann wrote:
> The omap usb drivers still rely on mach/*.h headers that
> are explicitly or implicitly included, but all the required
> definitions are now in include/linux/soc/ti/, so use those
> instead and allow compile-testing on other architectures.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/usb/gadget/udc/Kconfig | 2 +-
> drivers/usb/gadget/udc/omap_udc.c | 2 ++
> drivers/usb/host/Kconfig | 2 +-
> drivers/usb/host/ohci-omap.c | 7 +++----
> drivers/usb/phy/Kconfig | 3 ++-
> drivers/usb/phy/phy-isp1301-omap.c | 4 ++--
> 6 files changed, 11 insertions(+), 9 deletions(-)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH 0/3] Add basic support for RTC on Allwinner H6 SoC
From: Ondřej Jirman @ 2019-08-09 9:16 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Mark Rutland, Alessandro Zummo, devicetree, Maxime Ripard,
linux-sunxi, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel, linux-rtc
In-Reply-To: <20190808233930.GM3600@piout.net>
On Fri, Aug 09, 2019 at 01:39:30AM +0200, Alexandre Belloni wrote:
> On 08/08/2019 14:12:37+0200, Ondřej Jirman wrote:
> > On Wed, Aug 07, 2019 at 12:55:02PM +0200, Alexandre Belloni wrote:
> > > Hi,
> > >
> > > On 06/08/2019 20:30:45+0200, Ondřej Jirman wrote:
> > > > Maybe whether XO or DCXO is used also matters if you want to do some fine
> > > > tunning of DCXO (control register has pletny of options), but that's probably
> > > > better done in u-boot. And there's still no need to read HOSC source from DT.
> > > > The driver can just check compatible, and if it is H6 and OSC_CLK_SRC_SEL is 1,
> > > > it can do it's DCXO tunning, or whatever. But neither OS nor bootloader will
> > > > be using this info to gate/disable the osciallator.
> > > >
> > >
> > > It is actually useful to be able to tweak the crystal tuning at
> > > runtime to be able to reduce clock drift and compare with a reliable
> > > source (e.g. NTP).
> >
> > I don't think there's a Linux kernel API that you can use to achieve that, so
> > that's a rather theoretical concern at the moment.
> >
>
> There is /sys/class/rtc/rtcX/offset which is even properly documented.
>
> The reason I asked is that some RTCs have both analog (changing the
> oscillator capacitance) and digital (changing the RTC counter) so I'm
> wondering whether this interface should be extended.
As I wrote below, that can't be achieved by tuning DCXO.
> > Also there are multiple clocks, that can drive the RTC, and you usually don't
> > drive it from 24MHz DCXO oscillator. The reason is that you'd have to deal with
> > the fact that the clock for RTC then becomes 24000000/750 (750 is fixed
> > divider), which is 32000.
> >
> > So if you want to get 32768Hz for RTC by tuning the DCXO, it would have to have
> > 24 576 000 Hz. And even if you could achieve that (doubtful), it would throw off
> > timings in the rest of the system (say UART, USB, CPU, display ctl) in a major way.
> >
> > I guess you can try tuning 24MHz oscillator so that it's closer to the
> > real-world 24MHz via NTP reference for other reasons. But it would be
> > complicated, and require precise interaction with other components, like using
> > HW timers sourced from 24MHz HOSC clock, because you can't use CPU's timers,
> > because of inaccuracies introduced during DVFS, for example.
> >
> > regards,
> > o.
> >
> > > I'm curious, what kind of options does this RTC have?
> > >
> > > --
> > > Alexandre Belloni, Bootlin
> > > Embedded Linux and Kernel engineering
> > > https://bootlin.com
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v8 4/4] arm64: dts: allwinner: orange-pi-3: Enable HDMI output
From: Ondřej Jirman @ 2019-08-09 9:04 UTC (permalink / raw)
To: Code Kipper
Cc: Mark Rutland, devicetree, Maxime Ripard, Chen-Yu Tsai,
Jernej Škrabec, linux-kernel, David Airlie, linux-sunxi,
Rob Herring, dri-devel, Daniel Vetter, linux-arm-kernel
In-Reply-To: <CAEKpxBn1nF0t-M34iRSy1yYEuUxgNMUXFBhtjXBY8Qk+43zbDQ@mail.gmail.com>
On Fri, Aug 09, 2019 at 10:25:32AM +0200, Code Kipper wrote:
> On Tue, 6 Aug 2019 at 17:57, <megous@megous.com> wrote:
> >
> > From: Ondrej Jirman <megous@megous.com>
> >
> > Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables the DDC
> > I2C bus voltage shifter. Before EDID can be read, we need to pull PH2 high.
> > This is realized by the ddc-en-gpios property.
> Great work. Is there any chance you can move this to the
> arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi?, as all the H6
> based orange-pi's have this feature.
I plan to do that as a followup patch, once this is merged.
regards,
o.
> BR,
> CK
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > ---
> > .../dts/allwinner/sun50i-h6-orangepi-3.dts | 26 +++++++++++++++++++
> > 1 file changed, 26 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > index 2c6807b74ff6..01bb1bafe284 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > @@ -22,6 +22,18 @@
> > stdout-path = "serial0:115200n8";
> > };
> >
> > + connector {
> > + compatible = "hdmi-connector";
> > + ddc-en-gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
> > + type = "a";
> > +
> > + port {
> > + hdmi_con_in: endpoint {
> > + remote-endpoint = <&hdmi_out_con>;
> > + };
> > + };
> > + };
> > +
> > leds {
> > compatible = "gpio-leds";
> >
> > @@ -72,6 +84,10 @@
> > cpu-supply = <®_dcdca>;
> > };
> >
> > +&de {
> > + status = "okay";
> > +};
> > +
> > &ehci0 {
> > status = "okay";
> > };
> > @@ -91,6 +107,16 @@
> > status = "okay";
> > };
> >
> > +&hdmi {
> > + status = "okay";
> > +};
> > +
> > +&hdmi_out {
> > + hdmi_out_con: endpoint {
> > + remote-endpoint = <&hdmi_con_in>;
> > + };
> > +};
> > +
> > &mdio {
> > ext_rgmii_phy: ethernet-phy@1 {
> > compatible = "ethernet-phy-ieee802.3-c22";
> > --
> > 2.22.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> > To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190806155744.10263-5-megous%40megous.com.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: drm/amdgpu: replace readq/writeq with atomic64 operations
From: Koenig, Christian @ 2019-08-09 9:04 UTC (permalink / raw)
To: Alex Deucher, Guenter Roeck
Cc: kernel-build-reports@lists.linaro.org, Mark Brown, Zhou1, Tao,
amd-gfx list, Linux-Next Mailing List, Li, Dennis,
Deucher, Alexander, Andrew Morton, linux-arm-kernel,
Zhang, Hawking
In-Reply-To: <CADnq5_ONGvL0yMybsXCyYJO6zKRAi4aEPo8LwEwQjSP3aVbdJQ@mail.gmail.com>
Am 08.08.19 um 21:33 schrieb Alex Deucher:
> On Thu, Aug 8, 2019 at 3:31 PM Guenter Roeck <linux@roeck-us.net> wrote:
>> On Wed, Aug 07, 2019 at 10:56:40AM +0800, Tao Zhou wrote:
>>> readq/writeq are not supported on all architectures
>>>
>>> Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>> Regarding the claim that this would work for 32-bit x86 builds:
> I wasn't talking about readq/writeq, I was talking about the atomic64
> interfaces.
On quite a bunch of architectures atomic64 operations are actually
implemented with spinlocks or other architecture depended special handling.
So the approach of casting an iomem pointer to an atomic64 and then hope
for the best is actually completely nonsense.
If the hardware really needs a single 64bit write for doorbells or
registers, then we absolutely need to limit the driver to 64bit
architectures.
If the hardware doesn't need 64bit writes we should actually always use
two 32bit writes to not run into random and hard to debug problems
because of this.
Christian.
>
> Alex
>
>> make ARCH=i386 allmodconfig
>> make ARCH=i386 drivers/gpu/drm/amd/amdgpu/amdgpu_device.o
>>
>> results in:
>>
>> ...
>> CC [M] drivers/gpu/drm/amd/amdgpu/amdgpu_device.o
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: In function ‘amdgpu_mm_rreg64’:
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:279:9: error: implicit declaration of function ‘readq’;
>>
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: In function ‘amdgpu_mm_wreg64’:
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:298:3: error: implicit declaration of function ‘writeq’
>>
>> This is with next-20190808.
>>
>> Guenter
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64/cache: silence -Woverride-init warnings
From: Will Deacon @ 2019-08-09 9:04 UTC (permalink / raw)
To: Qian Cai
Cc: Mark Rutland, Catalin Marinas, Linux List Kernel Mailing,
linux-arm-kernel, clang-built-linux
In-Reply-To: <D2A2F2B9-0563-4DF6-8E77-F191A768CE4E@lca.pw>
On Thu, Aug 08, 2019 at 06:18:39PM -0400, Qian Cai wrote:
> > On Aug 8, 2019, at 6:38 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > Please just turn this off by default for clang.
>
> As mentioned before, it is very valuable to run “make W=1” given it found
> many real developer mistakes which will enable “-Woverride-init” for both
> compilers. Even “-Woverride-init” itself is useful find real issues as in,
Every single patch you've sent to me resulting from building with "W=1" has
been a false positive. Every. Single. One. That's not what I would call
"very valuable". It's probably what I'd call a "colossal waste of
everybody's time", especially as your tendancy to shoot from the hip when
writing these so-called fixes has resulted in some patches that ACTUALLY
INTRODUCED REAL BUGS. Do you see the insanity here?
> ae5e033d65a (“mfd: rk808: Fix RK818_IRQ_DISCHG_ILIM initializer”)
> 32df34d875bb (“[media] rc: img-ir: jvc: Remove unused no-leader timings”)
>
> Especially, to find redundant initializations in large structures. e.g.,
>
> e6ea0b917875 (“[media] dvb_frontend: Don't declare values twice at a table”)
>
> It is important to keep the noise-level as low as possible by keeping the
> amount of false positives under control to be truly benefit from those
> valuable compiler warnings.
So that's where you and I have a disagreement. I think maintainability
of the code is the single most important thing to consider after
correctness.
If code isn't maintainable, then it's liable to churn and be a constant
source of bugs as people keep tripping over whatever subtleties lie within.
In some cases, we have little choice and the combination of things like
performance requirements and compatibility force us down a path which we
wouldn't otherwise have considered. However, appeasing a compiler warning
that *doesn't even appear with the default build options* does not quality
for this sort of treatment in my opinion, so I will not be applying your
patch.
Please stop sending it. Real fixes, sure, but not this rubbish.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v19 00/15] arm64: untag user pointers passed to the kernel
From: Catalin Marinas @ 2019-08-09 9:00 UTC (permalink / raw)
To: Kees Cook
Cc: Mark Rutland, kvm, Christian Koenig, Szabolcs Nagy, Will Deacon,
dri-devel, Kostya Serebryany, Khalid Aziz, Lee Smith,
open list:KERNEL SELFTEST FRAMEWORK, Vincenzo Frascino,
Will Deacon, Jacob Bramley, Leon Romanovsky, linux-rdma, amd-gfx,
Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov, Dave Martin,
Evgeniy Stepanov, linux-media, Ruben Ayrapetyan, Andrey Konovalov,
Kevin Brodsky, Alex Williamson, Mauro Carvalho Chehab, Linux ARM,
Linux Memory Management List, Greg Kroah-Hartman, Felix Kuehling,
Dave Hansen, LKML, Jens Wiklander, Ramana Radhakrishnan,
Alexander Deucher, Andrew Morton, enh, Robin Murphy, Yishai Hadas,
Luc Van Oostenryck
In-Reply-To: <201908081608.A4F6711@keescook>
On Thu, Aug 08, 2019 at 04:09:04PM -0700, Kees Cook wrote:
> On Thu, Aug 08, 2019 at 03:33:00PM -0700, Andrew Morton wrote:
> > On Thu, 8 Aug 2019 14:12:19 -0700 Kees Cook <keescook@chromium.org> wrote:
> >
> > > > The ones that are left are the mm ones: 4, 5, 6, 7 and 8.
> > > >
> > > > Andrew, could you take a look and give your Acked-by or pick them up directly?
> > >
> > > Given the subsystem Acks, it seems like 3-10 and 12 could all just go
> > > via Andrew? I hope he agrees. :)
> >
> > I'll grab everything that has not yet appeared in linux-next. If more
> > of these patches appear in linux-next I'll drop those as well.
> >
> > The review discussion against " [PATCH v19 02/15] arm64: Introduce
> > prctl() options to control the tagged user addresses ABI" has petered
> > out inconclusively. prctl() vs arch_prctl().
>
> I've always disliked arch_prctl() existing at all. Given that tagging is
> likely to be a multi-architectural feature, it seems like the controls
> should live in prctl() to me.
It took a bit of grep'ing to figure out what Dave H meant by
arch_prctl(). It's an x86-specific syscall which we do not have on arm64
(and possibly any other architecture). Actually, we don't have any arm64
specific syscalls, only the generic unistd.h, hence the confusion. For
other arm64-specific prctls like SVE we used the generic sys_prctl() and
I can see x86 not being consistent either (PR_MPX_ENABLE_MANAGEMENT).
In general I disagree with adding any arm64-specific syscalls but in
this instance it can't even be justified. I'd rather see some clean-up
similar to arch_ptrace/ptrace_request than introducing new syscall
numbers (but as I suggested in my reply to Dave, that's for another
patch series).
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2 v2] tracing/arm64: Have max stack tracer handle the case of return address after data
From: Mark Rutland @ 2019-08-09 8:55 UTC (permalink / raw)
To: Steven Rostedt
Cc: Jiping Ma, catalin.marinas, will.deacon, linux-kernel, mingo,
Joel Fernandes, linux-arm-kernel
In-Reply-To: <20190807172907.155165959@goodmis.org>
On Wed, Aug 07, 2019 at 01:28:27PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
>
> Most archs (well at least x86) store the function call return address on the
> stack before storing the local variables for the function. The max stack
> tracer depends on this in its algorithm to display the stack size of each
> function it finds in the back trace.
>
> Some archs (arm64), may store the return address (from its link register)
> just before calling a nested function. There's no reason to save the link
> register on leaf functions, as it wont be updated. This breaks the algorithm
> of the max stack tracer.
>
> Add a new define ARCH_RET_ADDR_AFTER_LOCAL_VARS that an architecture may set
> if it stores the return address (link register) after it stores the
> function's local variables, and have the stack trace shift the values of the
> mapped stack size to the appropriate functions.
>
> Link: 20190802094103.163576-1-jiping.ma2@windriver.com
>
> Reported-by: Jiping Ma <jiping.ma2@windriver.com>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> ---
> arch/arm64/include/asm/ftrace.h | 13 +++++++++++++
> kernel/trace/trace_stack.c | 14 ++++++++++++++
> 2 files changed, 27 insertions(+)
>
> diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
> index 5ab5200b2bdc..961e98618db4 100644
> --- a/arch/arm64/include/asm/ftrace.h
> +++ b/arch/arm64/include/asm/ftrace.h
> @@ -14,6 +14,19 @@
> #define MCOUNT_ADDR ((unsigned long)_mcount)
> #define MCOUNT_INSN_SIZE AARCH64_INSN_SIZE
>
> +/*
> + * Currently, gcc tends to save the link register after the local variables
> + * on the stack. This causes the max stack tracer to report the function
> + * frame sizes for the wrong functions. By defining
> + * ARCH_RET_ADDR_AFTER_LOCAL_VARS, it will tell the stack tracer to expect
> + * to find the return address on the stack after the local variables have
> + * been set up.
> + *
> + * Note, this may change in the future, and we will need to deal with that
> + * if it were to happen.
> + */
> +#define ARCH_RET_ADDR_AFTER_LOCAL_VARS 1
FWIW (with whatever this got renamed to):
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64/cache: silence -Woverride-init warnings
From: Mark Rutland @ 2019-08-09 8:53 UTC (permalink / raw)
To: Qian Cai
Cc: Catalin Marinas, Will Deacon, Linux List Kernel Mailing,
linux-arm-kernel, clang-built-linux
In-Reply-To: <D2A2F2B9-0563-4DF6-8E77-F191A768CE4E@lca.pw>
On Thu, Aug 08, 2019 at 06:18:39PM -0400, Qian Cai wrote:
> > On Aug 8, 2019, at 6:38 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > On Wed, Aug 07, 2019 at 11:29:16PM -0400, Qian Cai wrote:
> >> The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
> >> VIVT I-caches") introduced some compiation warnings from GCC (and
> >> Clang) with -Winitializer-overrides),
> >>
> >> arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
> >> overwritten [-Woverride-init]
> >> [ICACHE_POLICY_VIPT] = "VIPT",
> >> ^~~~~~
> >> arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
> >> 'icache_policy_str[2]')
> >> arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
> >> overwritten [-Woverride-init]
> >> [ICACHE_POLICY_PIPT] = "PIPT",
> >> ^~~~~~
> >> arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
> >> 'icache_policy_str[3]')
> >> arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
> >> overwritten [-Woverride-init]
> >> [ICACHE_POLICY_VPIPT] = "VPIPT",
> >> ^~~~~~~
> >> arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
> >> 'icache_policy_str[0]')
> >>
> >> because it initializes icache_policy_str[0 ... 3] twice. Since
> >> arm64 developers are keen to keep the style of initializing a static
> >> array with a non-zero pattern first, just disable those warnings for
> >> both GCC and Clang of this file.
> >>
> >> Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches")
> >> Signed-off-by: Qian Cai <cai@lca.pw>
> >
> > This is _not_ a fix, and should not require backporting to stable trees.
>
> From my experience, the stable AI will pick up whatever they want to backport
> not matter if there Is a “Fixes” tag or not unless it is one of those subsystems like
> Networking that exclusively manually flag for. backporting by the maintainer.
My point is that this patch does not require backporting, and hence does
not require a fixes tag. The stable AI may choose the patch regardless,
so it's irrelevant.
[...]
> > What about all the other instances that we have in mainline?
>
> I have not had a chance to review all instances yet. It is not unusually to fix one
> warning at a time, and then go on fixing some more if time permit.
Given that:
* All the suggested code changes so far are harmful to legibility,
robustness, and maintainability of the code.
* The majority of the warnings (by orders of magnitude) occur for
intentional overrides, rather than unintentional overrides, as
assigning default values to arrays and structs is a common idiom.
* We have no known mechanism to selectively disable the warning on a
per-assignment basis.
... I do not think that is an appropriate strategy here.
For example, I'm fairly certain that if you try to "fix" the instances
in syscall tables, many more people will complain.
A much better approach would be to analyse the warnings, and either:
* find the _real_ bugs where we unintentionally override fields and fix
those first, or:
* Find the instances that produce the greatest set of false positives
(e.g. the syscall tables), and figure out how to suppress those
without harming the maintainability or robustness of the code.
> > I really don't think that we need to go down this road; we're just going
> > to end up adding this to every file that happens to include a header
> > using this scheme…
>
> How about disable them this way in a top level like arch/arm64/Makefile or
> arch/arm64/kernel/Makefile? Therefore, there is no need to add this to
> every file, but with a drawback that it could miss a few real issues there
> in the future which probably not many people are checking for them of
> the arm64 subsystem nowadays.
This isn't arm64-specific. We validly use duplicate assignments all over
the kernel, and my position is that we either:
* Find a mechanism to suppress the warning on a per-assignment (not
per-file) basis, without altering the structure of the existing code.
* Disable the warning tree-wide.
I would vastly prefer the former, as I do agree that this warning _can_
find real bugs, but similarly so can a script that warns "Line $N may
contain a bug" for every line of a C file.
> > Please just turn this off by default for clang.
>
> As mentioned before, it is very valuable to run “make W=1” given it found
> many real developer mistakes which will enable “-Woverride-init” for both
> compilers. Even “-Woverride-init” itself is useful find real issues as in,
>
> ae5e033d65a (“mfd: rk808: Fix RK818_IRQ_DISCHG_ILIM initializer”)
> 32df34d875bb (“[media] rc: img-ir: jvc: Remove unused no-leader timings”)
>
> Especially, to find redundant initializations in large structures. e.g.,
>
> e6ea0b917875 (“[media] dvb_frontend: Don't declare values twice at a table”)
>
> It is important to keep the noise-level as low as possible by keeping the
> amount of false positives under control to be truly benefit from those
> valuable compiler warnings.
I agree that we want to minimize the noise, but not at the expense of
the maintainability and robustness of the code, and not by disabling
warnings for arbitrary files.
> > If we want to enable this, we need a mechanism to permit overridable
> > assignments as we use range initializers for.
>
> I am not sure that it is worth filling a RFE for compilers of that feature.
If that's your position, then I see no point continuing this conversation.
> I feel like the range initializers just another way to initialize an array, and
> it is just easier to make mistakes with unintended double-initializations.
> The compiler developers probably recommend to enforce more of
> “-Woverride-init” for the range initializers rather than permitting it.
From my analysis in a prior reply, the vast majority of duplicate
assignments in the kernel are intentional. We do that for both arrays
and structures in order to have defaults that can be overridden.
If the compiler developers don't think that's worth supporting, then the
feature is not worth using.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites
From: Jan Kara @ 2019-08-09 8:43 UTC (permalink / raw)
To: Weiny, Ira
Cc: linux-fbdev@vger.kernel.org, Jan Kara, kvm@vger.kernel.org,
Dave Hansen, Dave Chinner, dri-devel@lists.freedesktop.org,
Michal Hocko, linux-mm@kvack.org, amd-gfx@lists.freedesktop.org,
sparclinux@vger.kernel.org, Williams, Dan J,
devel@driverdev.osuosl.org, rds-devel@oss.oracle.com,
linux-rdma@vger.kernel.org, x86@kernel.org, Matthew Wilcox,
Christoph Hellwig, Jason Gunthorpe,
xen-devel@lists.xenproject.org, devel@lists.orangefs.org,
linux-media@vger.kernel.org, John Hubbard,
intel-gfx@lists.freedesktop.org, linux-block@vger.kernel.org,
Jérôme Glisse, linux-rpi-kernel@lists.infradead.org,
ceph-devel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org, LKML,
linux-xfs@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Andrew Morton
In-Reply-To: <2807E5FD2F6FDA4886F6618EAC48510E79E79644@CRSMSX101.amr.corp.intel.com>
On Thu 08-08-19 16:25:04, Weiny, Ira wrote:
> > I thought I'd caught things early enough to get away with the
> > rename and deletion of that. You could either:
> >
> > a) open code an implementation of vaddr_put_pages_dirty_lock() that
> > doesn't call any of the *put_user_pages_dirty*() variants, or
> >
> > b) include my first patch ("") are part of your series, or
> >
> > c) base this on Andrews's tree, which already has merged in my first patch.
> >
>
> Yep I can do this. I did not realize that Andrew had accepted any of
> this work. I'll check out his tree. But I don't think he is going to
> accept this series through his tree. So what is the ETA on that landing
> in Linus' tree?
>
> To that point I'm still not sure who would take all this as I am now
> touching mm, procfs, rdma, ext4, and xfs.
MM tree would be one candidate for routing but there are other options that
would make sense as well - Dan's tree, VFS tree, or even I can pickup the
patches to my tree if needed. But let's worry about the routing after we
have working and reviewed patches...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites
From: Jan Kara @ 2019-08-09 8:34 UTC (permalink / raw)
To: Ira Weiny
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
Michal Hocko, linux-mm, amd-gfx, sparclinux, Dan Williams, devel,
rds-devel, linux-rdma, x86, Matthew Wilcox, Christoph Hellwig,
Jason Gunthorpe, xen-devel, devel, linux-media, John Hubbard,
intel-gfx, john.hubbard, linux-block, Jérôme Glisse,
linux-rpi-kernel, ceph-devel, linux-arm-kernel, linux-nfs, netdev,
LKML, linux-xfs, linux-crypto, linux-fsdevel, Andrew Morton
In-Reply-To: <20190808023637.GA1508@iweiny-DESK2.sc.intel.com>
On Wed 07-08-19 19:36:37, Ira Weiny wrote:
> On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> > > So I think your debug option and my suggested renaming serve a bit
> > > different purposes (and thus both make sense). If you do the renaming, you
> > > can just grep to see unconverted sites. Also when someone merges new GUP
> > > user (unaware of the new rules) while you switch GUP to use pins instead of
> > > ordinary references, you'll get compilation error in case of renaming
> > > instead of hard to debug refcount leak without the renaming. And such
> > > conflict is almost bound to happen given the size of GUP patch set... Also
> > > the renaming serves against the "coding inertia" - i.e., GUP is around for
> > > ages so people just use it without checking any documentation or comments.
> > > After switching how GUP works, what used to be correct isn't anymore so
> > > renaming the function serves as a warning that something has really
> > > changed.
> >
> > Fully agreed!
>
> Ok Prior to this I've been basing all my work for the RDMA/FS DAX stuff in
> Johns put_user_pages()... (Including when I proposed failing truncate with a
> lease in June [1])
>
> However, based on the suggestions in that thread it became clear that a new
> interface was going to need to be added to pass in the "RDMA file" information
> to GUP to associate file pins with the correct processes...
>
> I have many drawings on my white board with "a whole lot of lines" on them to
> make sure that if a process opens a file, mmaps it, pins it with RDMA, _closes_
> it, and ummaps it; that the resulting file pin can still be traced back to the
> RDMA context and all the processes which may have access to it.... No matter
> where the original context may have come from. I believe I have accomplished
> that.
>
> Before I go on, I would like to say that the "imbalance" of get_user_pages()
> and put_page() bothers me from a purist standpoint... However, since this
> discussion cropped up I went ahead and ported my work to Linus' current master
> (5.3-rc3+) and in doing so I only had to steal a bit of Johns code... Sorry
> John... :-(
>
> I don't have the commit messages all cleaned up and I know there may be some
> discussion on these new interfaces but I wanted to throw this series out there
> because I think it may be what Jan and Michal are driving at (or at least in
> that direction.
>
> Right now only RDMA and DAX FS's are supported. Other users of GUP will still
> fail on a DAX file and regular files will still be at risk.[2]
>
> I've pushed this work (based 5.3-rc3+ (33920f1ec5bf)) here[3]:
>
> https://github.com/weiny2/linux-kernel/tree/linus-rdmafsdax-b0-v3
>
> I think the most relevant patch to this conversation is:
>
> https://github.com/weiny2/linux-kernel/commit/5d377653ba5cf11c3b716f904b057bee6641aaf6
>
> I stole Jans suggestion for a name as the name I used while prototyping was
> pretty bad... So Thanks Jan... ;-)
For your function, I'd choose a name like vaddr_pin_leased_pages() so that
association with a lease is clear from the name :) Also I'd choose the
counterpart to be vaddr_unpin_leased_page[s](). Especially having put_page in
the name looks confusing to me...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Explicitly marking initializer overrides (was "Re: [PATCH] arm64/cache: silence -Woverride-init warnings")
From: Mark Rutland @ 2019-08-09 8:32 UTC (permalink / raw)
To: Nathan Chancellor
Cc: catalin.marinas, linux-kernel, clang-built-linux, Qian Cai, will,
linux-arm-kernel
In-Reply-To: <20190808170916.GA32668@archlinux-threadripper>
On Thu, Aug 08, 2019 at 10:09:16AM -0700, Nathan Chancellor wrote:
> On Thu, Aug 08, 2019 at 11:38:08AM +0100, Mark Rutland wrote:
> > On Wed, Aug 07, 2019 at 11:29:16PM -0400, Qian Cai wrote:
> > > The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
> > > VIVT I-caches") introduced some compiation warnings from GCC (and
> > > Clang) with -Winitializer-overrides),
> > >
> > > arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
> > > overwritten [-Woverride-init]
> > > [ICACHE_POLICY_VIPT] = "VIPT",
> > > ^~~~~~
> > > arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
> > > 'icache_policy_str[2]')
> > > arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
> > > overwritten [-Woverride-init]
> > > [ICACHE_POLICY_PIPT] = "PIPT",
> > > ^~~~~~
> > > arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
> > > 'icache_policy_str[3]')
> > > arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
> > > overwritten [-Woverride-init]
> > > [ICACHE_POLICY_VPIPT] = "VPIPT",
> > > ^~~~~~~
> > > arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
> > > 'icache_policy_str[0]')
> > >
> > > because it initializes icache_policy_str[0 ... 3] twice. Since
> > > arm64 developers are keen to keep the style of initializing a static
> > > array with a non-zero pattern first, just disable those warnings for
> > > both GCC and Clang of this file.
> > >
> > > Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches")
> > > Signed-off-by: Qian Cai <cai@lca.pw>
> >
> > This is _not_ a fix, and should not require backporting to stable trees.
> >
> > What about all the other instances that we have in mainline?
> >
> > I really don't think that we need to go down this road; we're just going
> > to end up adding this to every file that happens to include a header
> > using this scheme...
> >
> > Please just turn this off by default for clang.
> >
> > If we want to enable this, we need a mechanism to permit overridable
> > assignments as we use range initializers for.
> >
> > Thanks,
> > Mark.
> >
>
> For what it's worth, this is disabled by default for clang in the
> kernel:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.extrawarn?h=v5.3-rc3#n69
>
> It only becomes visible with clang at W=1 because that section doesn't
> get applied. It becomes visible with GCC at W=1 because of -Wextra.
Thanks for clarifying that!
Do you know if there's any existing mechanism that we can use to silence
the warning on a per-assignment basis? Either to say that an assignment
can be overridden, or that the assignment is expected to override an
existing assignment?
If not, who would be able to look at adding a mechanism to clang for
this?
If we could have some attribute or intrinsic that we could wrap like:
struct foo f = {
.bar __defaultval = <default>,
.bar = <newval>, // no warning
.bar = <anotherval>, // warning
};
... or:
struct foo f = {
.bar = <default>,
.bar __override = <newval>, // no warning
.bar = <anotherval>, // warning
};
... or:
.bar = OVERRIDE(<newval>), // no warning
... or:
OVERRIDE(.bar) = <newval>, // no warning
... then I think it would be possible to make use of the warning
effectively, as we could distinguish intentional overrides from
unintentional ones, and annotating assignments in this way doesn't seem
onerous to me.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 6/6] arm64: dts: k3-j721e: Add gpio-keys on common processor board
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
From: Nikhil Devshatwar <nikhil.nd@ti.com>
Common processor board for K3 J721E platform has two push buttons
namely SW10 and SW11.
Add a gpio-keys device node to model them as input keys in Linux.
Add required pinmux nodes to set GPIO pins as input.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../dts/ti/k3-j721e-common-proc-board.dts | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
index 509579ca3db2..d2894d55fbbe 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
@@ -6,12 +6,49 @@
/dts-v1/;
#include "k3-j721e-som-p0.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
/ {
chosen {
stdout-path = "serial2:115200n8";
bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000";
};
+
+ gpio_keys: gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sw10_button_pins_default &sw11_button_pins_default>;
+
+ sw10: sw10 {
+ label = "GPIO Key USER1";
+ linux,code = <BTN_0>;
+ gpios = <&main_gpio0 0 GPIO_ACTIVE_LOW>;
+ };
+
+ sw11: sw11 {
+ label = "GPIO Key USER2";
+ linux,code = <BTN_1>;
+ gpios = <&wkup_gpio0 7 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&main_pmx0 {
+ sw10_button_pins_default: sw10_button_pins_default {
+ pinctrl-single,pins = <
+ J721E_IOPAD(0x0, PIN_INPUT, 7) /* (AC18) EXTINTn.GPIO0_0 */
+ >;
+ };
+};
+
+&wkup_pmx0 {
+ sw11_button_pins_default: sw11_button_pins_default {
+ pinctrl-single,pins = <
+ J721E_WKUP_IOPAD(0xcc, PIN_INPUT, 7) /* (G28) WKUP_GPIO0_7 */
+ >;
+ };
};
&wkup_uart0 {
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/6] dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
Add pinctrl macros for J721E SoC. These macro definitions are
similar to that of AM6, but adding new definitions to avoid
any naming confusions in the soc dts files.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
---
include/dt-bindings/pinctrl/k3.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/dt-bindings/pinctrl/k3.h b/include/dt-bindings/pinctrl/k3.h
index 45e11b6170ca..499de6216581 100644
--- a/include/dt-bindings/pinctrl/k3.h
+++ b/include/dt-bindings/pinctrl/k3.h
@@ -32,4 +32,7 @@
#define AM65X_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
#define AM65X_WKUP_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
+#define J721E_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
+#define J721E_WKUP_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
+
#endif
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/6] arm64: dts: ti: k3-j721e-common-proc-board: Disable unused gpio modules
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
There are 10 gpio instances inside SoC with 3 groups as below:
- Group1: main_gpio0, main_gpio2, main_gpio4, main_gpio6
- Group2: main_gpio1, main_gpio3, main_gpio5, main_gpio7
- Group3: wkup_gpio0, wkup_gpio1
Only one instance can be used in each group at a time. So use main_gpio0,
main_gpio1 and wkup_gpio0 for the current linux context and mark other
gpio nodes as disabled.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../dts/ti/k3-j721e-common-proc-board.dts | 28 +++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
index 63b47b839388..509579ca3db2 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
@@ -52,3 +52,31 @@
/* UART not brought out */
status = "disabled";
};
+
+&main_gpio2 {
+ status = "disabled";
+};
+
+&main_gpio3 {
+ status = "disabled";
+};
+
+&main_gpio4 {
+ status = "disabled";
+};
+
+&main_gpio5 {
+ status = "disabled";
+};
+
+&main_gpio6 {
+ status = "disabled";
+};
+
+&main_gpio7 {
+ status = "disabled";
+};
+
+&wkup_gpio1 {
+ status = "disabled";
+};
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/6] arm64: dts: ti: k3-j721e: Add gpio nodes in main domain
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
There are 8 instances of gpio modules in main domain divided into 2 groups:
- Group1: gpio0, gpio2, gpio4, gpio6
- Group2: gpio1, gpio3, gpio5, gpio7
Groups are created to provide protection between two different processor
virtual worlds. There are x gpio lines coming out of each group. Each module
in a group has equal x gpio lines pinned out. There is a top level mux for
selecting the module instance for each pin coming out of group. Exactly
one module can be selected to control the corresponding pin. This muxing
can be controlled along the pad mux configuration registers.
Group1 pins out 128 lines(8 banks). Group 2 pins out 36 lines(2 banks).
Add DT nodes for each module instance in the main domain. Users should
make sure that correct gpio instance is selected in their pad configuration.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 132 ++++++++++++++++++++++
1 file changed, 132 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index 01661c22c39d..199bc9a00b20 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -240,4 +240,136 @@
clocks = <&k3_clks 286 0>;
clock-names = "fclk";
};
+
+ main_gpio0: gpio@600000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00600000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <105 0>, <105 1>, <105 2>, <105 3>,
+ <105 4>, <105 5>, <105 6>, <105 7>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <128>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 105 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio1: gpio@601000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00601000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <106 0>, <106 1>, <106 2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <36>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 106 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 106 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio2: gpio@610000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00610000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <107 0>, <107 1>, <107 2>, <107 3>,
+ <107 4>, <107 5>, <107 6>, <107 7>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <128>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 107 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 107 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio3: gpio@611000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00611000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <108 0>, <108 1>, <108 2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <36>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 108 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 108 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio4: gpio@620000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00620000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <109 0>, <109 1>, <109 2>, <109 3>,
+ <109 4>, <109 5>, <109 6>, <109 7>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <128>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 109 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 109 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio5: gpio@621000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00621000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <110 0>, <110 1>, <110 2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <36>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 110 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 110 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio6: gpio@630000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00630000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <111 0>, <111 1>, <111 2>, <111 3>,
+ <111 4>, <111 5>, <111 6>, <111 7>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <128>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 111 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 111 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio7: gpio@631000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00631000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <112 0>, <112 1>, <112 2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <36>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 112 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 112 0>;
+ clock-names = "gpio";
+ };
};
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/6] arm64: dts: ti: k3-j721e: Add gpio nodes in wakeup domain
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
Similar to the gpio groups in main domain, there is one gpio group
in wakup domain with 2 module instances in it. This gpio group pins
out 84 lines(6 banks). Add DT node for these 2 gpio module instances.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 34 +++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
index e616c2481f51..555dc7b7aedc 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
@@ -87,4 +87,38 @@
ti,sci-dst-id = <14>;
ti,sci-rm-range-girq = <0x5>;
};
+
+ wkup_gpio0: gpio@42110000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x42110000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&wkup_gpio_intr>;
+ interrupts = <113 0>, <113 1>, <113 2>,
+ <113 3>, <113 4>, <113 5>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <84>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 113 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 113 0>;
+ clock-names = "gpio";
+ };
+
+ wkup_gpio1: gpio@42100000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x42100000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&wkup_gpio_intr>;
+ interrupts = <114 0>, <114 1>, <114 2>,
+ <114 3>, <114 4>, <114 5>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <84>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 114 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 114 0>;
+ clock-names = "gpio";
+ };
};
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/6] arm64: dts: ti: k3-j721e: Add gpio nodes
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
This series adds gpio nodes for J721E SoC and enable gpio keys
in J72E common process board.
Tested Boot log: https://pastebin.ubuntu.com/p/P6QqmZYtSC/
This series depends on Power-domain cells update series:
https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=152109
Lokesh Vutla (5):
dt-bindings: gpio: davinci: Add new compatible for J721E SoCs
arm64: dts: ti: k3-j721e: Add gpio nodes in main domain
arm64: dts: ti: k3-j721e: Add gpio nodes in wakeup domain
arm64: dts: ti: k3-j721e-common-proc-board: Disable unused gpio
modules
dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E
Nikhil Devshatwar (1):
arm64: dts: k3-j721e: Add gpio-keys on common processor board
.../devicetree/bindings/gpio/gpio-davinci.txt | 1 +
.../dts/ti/k3-j721e-common-proc-board.dts | 65 +++++++++
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 132 ++++++++++++++++++
.../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 34 +++++
include/dt-bindings/pinctrl/k3.h | 3 +
5 files changed, 235 insertions(+)
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/6] dt-bindings: gpio: davinci: Add new compatible for J721E SoCs
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
J721e SoCs have same gpio IP as K2G davinci gpio. Add a new compatible to
handle J721E SoCs.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
Documentation/devicetree/bindings/gpio/gpio-davinci.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index bc6b4b62df83..cd91d61eac31 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -6,6 +6,7 @@ Required Properties:
66AK2E SoCs
"ti,k2g-gpio", "ti,keystone-gpio": for 66AK2G
"ti,am654-gpio", "ti,keystone-gpio": for TI K3 AM654
+ "ti,j721e-gpio", "ti,keystone-gpio": for J721E SoCs
- reg: Physical base address of the controller and the size of memory mapped
registers.
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [linux-sunxi] [PATCH v8 4/4] arm64: dts: allwinner: orange-pi-3: Enable HDMI output
From: Code Kipper @ 2019-08-09 8:25 UTC (permalink / raw)
To: megous
Cc: Mark Rutland, devicetree, Maxime Ripard, Chen-Yu Tsai,
Jernej Škrabec, linux-kernel, David Airlie, linux-sunxi,
Rob Herring, dri-devel, Daniel Vetter, linux-arm-kernel
In-Reply-To: <20190806155744.10263-5-megous@megous.com>
On Tue, 6 Aug 2019 at 17:57, <megous@megous.com> wrote:
>
> From: Ondrej Jirman <megous@megous.com>
>
> Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables the DDC
> I2C bus voltage shifter. Before EDID can be read, we need to pull PH2 high.
> This is realized by the ddc-en-gpios property.
Great work. Is there any chance you can move this to the
arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi?, as all the H6
based orange-pi's have this feature.
BR,
CK
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 26 +++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> index 2c6807b74ff6..01bb1bafe284 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> @@ -22,6 +22,18 @@
> stdout-path = "serial0:115200n8";
> };
>
> + connector {
> + compatible = "hdmi-connector";
> + ddc-en-gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&hdmi_out_con>;
> + };
> + };
> + };
> +
> leds {
> compatible = "gpio-leds";
>
> @@ -72,6 +84,10 @@
> cpu-supply = <®_dcdca>;
> };
>
> +&de {
> + status = "okay";
> +};
> +
> &ehci0 {
> status = "okay";
> };
> @@ -91,6 +107,16 @@
> status = "okay";
> };
>
> +&hdmi {
> + status = "okay";
> +};
> +
> +&hdmi_out {
> + hdmi_out_con: endpoint {
> + remote-endpoint = <&hdmi_con_in>;
> + };
> +};
> +
> &mdio {
> ext_rgmii_phy: ethernet-phy@1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> --
> 2.22.0
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190806155744.10263-5-megous%40megous.com.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox