* [PATCH] arm: cntvoff: Add a function definition when !SMP
From: Maxime Ripard @ 2018-06-05 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605064944.524bblnhhkwhr34i@verge.net.au>
On Tue, Jun 05, 2018 at 08:49:44AM +0200, Simon Horman wrote:
> On Mon, Jun 04, 2018 at 06:26:03PM +0200, Maxime Ripard wrote:
> > On Mon, May 28, 2018 at 10:40:16AM +0200, Maxime Ripard wrote:
> > > The secure_cntvoff_init function is only compiled if CONFIG_SMP is set to
> > > true. However, that will lead to linking errors if one uses this function
> > > without an ifdef CONFIG_SMP guard, which isn't ideal.
> > >
> > > Provide a dumb implementation when CONFIG_SMP is false so that we don't end
> > > up with a compilation error on our hands.
>
> What are the errors that this patch fixes?
There's a linking error when CONFIG_SMP is not enabled since the
function will not be implemented anywhere.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180605/716b6265/attachment-0001.sig>
^ permalink raw reply
* VMA/Paging apis broken on ARM/ARM64, possible work-arounds?
From: Kamil Leoniak @ 2018-06-05 12:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I have this problem with the kernel I'm working with. Normally PTEs
are made for every VM addr (ktext, modules and so on). On ARM/ARM64
certain VM addrs (in kernel) are allocated only with PMDs, they not
have a corresponding PTE cells.
This breaks a whole range of kernel APIs, for example "set_memory_rw".
It will work for any region that has a PTE, but if it's a direct PMD
mapping, it will fail.
Is there some simple work-around for that? Can I somehow remap a
specific VM address into a specific physical address? (to override the
"simple" PMD mapping).
Thank you!
^ permalink raw reply
* [PATCH V2] ARM: dts: armada388-helios4
From: Dennis Gilmore @ 2018-06-05 12:47 UTC (permalink / raw)
To: linux-arm-kernel
The helios4 is a Armada388 based nas board designed by SolidRun and
based on their SOM. It is sold by kobol.io the dts file came from
https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-device-tree.patch
I added a SPDX license line to match the clearfog it says it was based
on and a compatible line for "kobol,helios4"
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
changes since first submission
change solidrun to kobol in compatible line based on feedback
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-helios4.dts | 315 +++++++++++++++++++++++
2 files changed, 316 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-388-helios4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..490bfd586198 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1123,6 +1123,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-388-clearfog-pro.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
+ armada-388-helios4.dtb \
armada-388-rd.dtb
dtb-$(CONFIG_MACH_ARMADA_39X) += \
armada-398-db.dtb
diff --git a/arch/arm/boot/dts/armada-388-helios4.dts b/arch/arm/boot/dts/armada-388-helios4.dts
new file mode 100644
index 000000000000..16026bedc380
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-helios4.dts
@@ -0,0 +1,315 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Helios4
+ * based on SolidRun Clearfog revision A1 rev 2.0 (88F6828)
+ *
+ * Copyright (C) 2017
+ *
+ */
+
+/dts-v1/;
+#include "armada-388.dtsi"
+#include "armada-38x-solidrun-microsom.dtsi"
+
+/ {
+ model = "Helios4";
+ compatible = "kobol,helios4", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x80000000>; /* 2 GB */
+ };
+
+ aliases {
+ /* So that mvebu u-boot can update the MAC addresses */
+ ethernet1 = ð0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_12v: regulator-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "power_brick_12V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_hdd: regulator-5v-hdd {
+ compatible = "regulator-fixed";
+ regulator-name = "5V_HDD";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_usb: regulator-5v-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "USB-PWR";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ enable-active-high;
+ gpio = <&expander0 6 GPIO_ACTIVE_HIGH>;
+ vin-supply = <®_12v>;
+ };
+
+ system-leds {
+ compatible = "gpio-leds";
+ status-led {
+ label = "helios4:green:status";
+ gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ fault-led {
+ label = "helios4:red:fault";
+ gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+ };
+
+ io-leds {
+ compatible = "gpio-leds";
+ sata1-led {
+ label = "helios4:green:ata1";
+ gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata1";
+ default-state = "off";
+ };
+ sata2-led {
+ label = "helios4:green:ata2";
+ gpios = <&gpio1 18 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata2";
+ default-state = "off";
+ };
+ sata3-led {
+ label = "helios4:green:ata3";
+ gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata3";
+ default-state = "off";
+ };
+ sata4-led {
+ label = "helios4:green:ata4";
+ gpios = <&gpio1 21 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata4";
+ default-state = "off";
+ };
+ usb-led {
+ label = "helios4:green:usb";
+ gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "usb-host";
+ default-state = "off";
+ };
+ };
+
+ fan1: j10-pwm {
+ compatible = "pwm-fan";
+ pwms = <&gpio1 9 40000>; /* Target freq:25 kHz */
+ };
+
+ fan2: j17-pwm {
+ compatible = "pwm-fan";
+ pwms = <&gpio1 23 40000>; /* Target freq:25 kHz */
+ };
+
+ usb2_phy: usb2-phy {
+ compatible = "usb-nop-xceiv";
+ vbus-regulator = <®_5p0v_usb>;
+ };
+
+ usb3_phy: usb3-phy {
+ compatible = "usb-nop-xceiv";
+ //vbus-regulator = <®_5p0v_usb>;
+ };
+
+ soc {
+ internal-regs {
+ i2c at 11000 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ /*
+ * PCA9655 GPIO expander, up to 1MHz clock.
+ * 0-Board Revision bit 0 #
+ * 1-Board Revision bit 1 #
+ * 5-USB3 overcurrent
+ * 6-USB3 power
+ */
+ expander0: gpio-expander at 20 {
+ /*
+ * This is how it should be:
+ * compatible = "onnn,pca9655",
+ * "nxp,pca9555";
+ * but you can't do this because of
+ * the way I2C works.
+ */
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pca0_pins>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ board_rev_bit_0 {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "board-rev-0";
+ };
+ board_rev_bit_1 {
+ gpio-hog;
+ gpios = <1 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "board-rev-1";
+ };
+ usb3_ilimit {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "usb-overcurrent-status";
+ };
+ };
+
+ temp_sensor: temp at 4c {
+ compatible = "ti,lm75";
+ reg = <0x4c>;
+ vcc-supply = <®_3p3v>;
+ };
+ };
+
+ i2c at 11100 {
+ /*
+ * External I2C Bus for user peripheral
+ */
+ clock-frequency = <400000>;
+ pinctrl-0 = <&helios_i2c1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ sata at a8000 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata0: sata-port at 0 {
+ reg = <0>;
+ };
+
+ sata1: sata-port at 1 {
+ reg = <1>;
+ };
+ };
+
+ sata at e0000 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata2: sata-port at 0 {
+ reg = <0>;
+ };
+
+ sata3: sata-port at 1 {
+ reg = <1>;
+ };
+ };
+
+ spi at 10680 {
+ pinctrl-0 = <&spi1_pins
+ µsom_spi1_cs_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ sdhci at d8000 {
+ bus-width = <4>;
+ cd-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ pinctrl-0 = <&helios_sdhci_pins
+ &helios_sdhci_cd_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ vmmc = <®_3p3v>;
+ wp-inverted;
+ };
+
+ usb at 58000 {
+ //vcc-supply = <®_5p0v_usb>;
+ usb-phy = <&usb2_phy>;
+ status = "okay";
+ };
+
+ usb3 at f0000 {
+ status = "okay";
+ };
+
+ usb3 at f8000 {
+ status = "okay";
+ };
+
+ pinctrl at 18000 {
+ pca0_pins: pca0-pins {
+ marvell,pins = "mpp23";
+ marvell,function = "gpio";
+ };
+ microsom_phy0_int_pins: microsom-phy0-int-pins {
+ marvell,pins = "mpp18";
+ marvell,function = "gpio";
+ };
+ helios_i2c1_pins: i2c1-pins {
+ marvell,pins = "mpp26", "mpp27";
+ marvell,function = "i2c1";
+ };
+ helios_sdhci_cd_pins: helios-sdhci-cd-pins {
+ marvell,pins = "mpp20";
+ marvell,function = "gpio";
+ };
+ helios_sdhci_pins: helios-sdhci-pins {
+ marvell,pins = "mpp21", "mpp28",
+ "mpp37", "mpp38",
+ "mpp39", "mpp40";
+ marvell,function = "sd0";
+ };
+ helios_led_pins: helios-led-pins {
+ marvell,pins = "mpp24", "mpp25",
+ "mpp49", "mpp50",
+ "mpp52", "mpp53",
+ "mpp54";
+ marvell,function = "gpio";
+ };
+ helios_fan_pins: helios-fan-pins {
+ marvell,pins = "mpp41", "mpp43",
+ "mpp48", "mpp55";
+ marvell,function = "gpio";
+ };
+ microsom_spi1_cs_pins: spi1-cs-pins {
+ marvell,pins = "mpp59";
+ marvell,function = "spi1";
+ };
+ };
+ };
+ };
+};
--
2.17.1
^ permalink raw reply related
* [linux-sunxi] Re: [PATCH v2 00/26] arm64: allwinner: Add A64 DE2 HDMI support
From: Jagan Teki @ 2018-06-05 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518095913.nzl3sr5wn6cg4ra5@flea>
On Fri, May 18, 2018 at 3:29 PM, Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
> On Fri, May 18, 2018 at 03:15:10PM +0530, Jagan Teki wrote:
>> Allwinner A64 has display engine pipeline like other Allwinner SOC's A83T/H3/H5.
>>
>> A64 behaviour similar to Allwinner A83T where
>> Mixer0 => TCON0 => LVDS/RGB/MIPI-DSI
>> Mixer1 => TCON1 => HDMI
>> as per Display System Block DiagramAllwinner_A64_User_Manual_V1.1.pdf
>>
>> This is second patch-set followed with previous RFC[1] and first series[2]
>> and merely concentrated on HDMI pipeline through TCON1 and rest will add eventually.
>>
>> This series fixed previous version comments
>> - about documenting fallback compatibles
>> - adding new compatible for mixer1
>> - support for multiple DW HDMI PHY clock parents (thanks, to Jernej)
>>
>> Note:
>> Pine64 boards are unable to get edid by default like other A64 boards,
>> but forcing 'video=HDMI-A-1:1920x1080 at 60D' kernel command line can
>> create edid with display on penel.
>
> There's no point in trying to push this without the SRAM issue being
> solved. It is required, and won't be merged unless this is addressed.
is SRAM issue resolved? if so may be I will try to test it on top.
Jagan.
--
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* [PATCH v2] DMA: OMAP: fix OMAP1510 incorrect residue_granularity
From: Peter Ujfalusi @ 2018-06-05 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180602152719.28464-1-jmkrzyszt@gmail.com>
On 06/02/2018 06:27 PM, Janusz Krzysztofik wrote:
> Commit 0198d7bb8a0c ("ASoC: omap-mcbsp: Convert to use the sdma-pcm
> instead of omap-pcm") resulted in broken audio playback on OMAP1510
> (discovered on Amstrad Delta).
Good catch.
can you fix up the subject:
dmaengine: ti: omap-dma: Fix OMAP1510...
Otherwise:
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> When running on OMAP1510, omap-pcm used to obtain DMA offset from
> snd_dmaengine_pcm_pointer_no_residue() based on DMA interrupt triggered
> software calculations instead of snd_dmaengine_pcm_pointer() which
> depended on residue value calculated from omap_dma_get_src_pos().
> Similar code path is still available in now used
> sound/soc/soc-generic-dmaengine-pcm.c but it is not triggered.
>
> It was verified already before that omap_get_dma_src_pos() from
> arch/arm/plat-omap/dma.c didn't work correctly for OMAP1510 - see
> commit 1bdd7419910c ("ASoC: OMAP: fix OMAP1510 broken PCM pointer
> callback") for details. Apparently the same applies to its successor,
> omap_dma_get_src_pos() from drivers/dma/ti/omap-dma.c.
>
> On the other hand, snd_dmaengine_pcm_pointer_no_residue() is described
> as depreciated and discouraged for use in new drivers because of its
> unreliable accuracy. However, it seems the only working option for
> OPAM1510 now, as long as a software calculated residue is not
> implemented as OMAP1510 fallback in omap-dma.
>
> Using snd_dmaengine_pcm_pointer_no_residue() code path instead of
> snd_dmaengine_pcm_pointer() in sound/soc/soc-generic-dmaengine-pcm.c
> can be triggered in two ways:
> - by passing pcm->flags |= SND_DMAENGINE_PCM_FLAG_NO_RESIDUE from
> sound/soc/omap/sdma-pcm.c,
> - by passing dma_caps.residue_granularity =
> DMA_RESIDUE_GRANULARITY_DESCRIPTOR from DMA engine.
>
> Let's do the latter.
>
> Created and tested against next-20180531 tag from linux-next tree.
>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
> ---
> Changelog:
> v2: apply the patch against omap-dma.c moved to drivers/dma/ti/
>
> drivers/dma/ti/omap-dma.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/ti/omap-dma.c b/drivers/dma/ti/omap-dma.c
> index b73fb51fbc81..96b5096c26dd 100644
> --- a/drivers/dma/ti/omap-dma.c
> +++ b/drivers/dma/ti/omap-dma.c
> @@ -1485,7 +1485,11 @@ static int omap_dma_probe(struct platform_device *pdev)
> od->ddev.src_addr_widths = OMAP_DMA_BUSWIDTHS;
> od->ddev.dst_addr_widths = OMAP_DMA_BUSWIDTHS;
> od->ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
> - od->ddev.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
> + if (__dma_omap15xx(od->plat->dma_attr))
> + od->ddev.residue_granularity =
> + DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
> + else
> + od->ddev.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
> od->ddev.max_burst = SZ_16M - 1; /* CCEN: 24bit unsigned */
> od->ddev.dev = &pdev->dev;
> INIT_LIST_HEAD(&od->ddev.channels);
>
--
P?ter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* VMA/Paging apis broken on ARM/ARM64, possible work-arounds?
From: Russell King - ARM Linux @ 2018-06-05 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOq87KqGmH92TOvxR1duCkiMqw+ZPH=NuBUAEhAztLxgRyW1TQ@mail.gmail.com>
On Tue, Jun 05, 2018 at 02:40:28PM +0200, Kamil Leoniak wrote:
> I have this problem with the kernel I'm working with. Normally PTEs
> are made for every VM addr (ktext, modules and so on). On ARM/ARM64
> certain VM addrs (in kernel) are allocated only with PMDs, they not
> have a corresponding PTE cells.
>
> This breaks a whole range of kernel APIs, for example "set_memory_rw".
These return -EINVAL if you try to use them on a region that isn't
supported by the implementation. Their use on the kernel is not
supported, sorry.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH V2] ARM: dts: armada388-helios4
From: Gregory CLEMENT @ 2018-06-05 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605124738.24844-1-dennis@ausil.us>
Hi Dennis,
On mar., juin 05 2018, Dennis Gilmore <dennis@ausil.us> wrote:
> The helios4 is a Armada388 based nas board designed by SolidRun and
> based on their SOM. It is sold by kobol.io the dts file came from
> https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-device-tree.patch
> I added a SPDX license line to match the clearfog it says it was based
> on and a compatible line for "kobol,helios4"
This patch looks good, I have only two remarks for now.
> + usb3_phy: usb3-phy {
> + compatible = "usb-nop-xceiv";
> + //vbus-regulator = <®_5p0v_usb>;
Why did you comment this line?
What about removing it, if you don't need it?
[...]
> +
> + usb at 58000 {
> + //vcc-supply = <®_5p0v_usb>;
Same here
> + usb-phy = <&usb2_phy>;
> + status = "okay";
> + };
> +
Gregory
--
Gregory Clement, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
^ permalink raw reply
* [PATCH v4 1/3] dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method.
From: Geert Uytterhoeven @ 2018-06-05 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528198148-23308-2-git-send-email-michel.pollet@bp.renesas.com>
On Tue, Jun 5, 2018 at 1:28 PM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> Add a special enable method for second CA7 of the R9A06G032
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Geert Uytterhoeven @ 2018-06-05 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528198148-23308-3-git-send-email-michel.pollet@bp.renesas.com>
On Tue, Jun 5, 2018 at 1:28 PM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time, it
> requires a special enable method to get it started.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- /dev/null
> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * R9A06G032 Second CA7 enabler.
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
> + * Derived from action,s500-smp
actions
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v4 3/3] ARM: dts: Renesas R9A06G032 SMP enable method
From: Geert Uytterhoeven @ 2018-06-05 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528198148-23308-4-git-send-email-michel.pollet@bp.renesas.com>
On Tue, Jun 5, 2018 at 1:28 PM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> Add a special enable method for the second CA7 of the R9A06G032
> as well as the default value for the "cpu-release-addr" property.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v4 3/3] ARM: dts: Renesas R9A06G032 SMP enable method
From: Geert Uytterhoeven @ 2018-06-05 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528198148-23308-4-git-send-email-michel.pollet@bp.renesas.com>
On Tue, Jun 5, 2018 at 1:28 PM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> Add a special enable method for the second CA7 of the R9A06G032
> as well as the default value for the "cpu-release-addr" property.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- a/arch/arm/boot/dts/r9a06g032.dtsi
> +++ b/arch/arm/boot/dts/r9a06g032.dtsi
> @@ -1,3 +1,4 @@
> +
Bogus change
> // SPDX-License-Identifier: GPL-2.0
> /*
> * Base Device Tree Source for the Renesas RZ/N1D (R9A06G032)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v2 00/26] arm64: allwinner: Add A64 DE2 HDMI support
From: Maxime Ripard @ 2018-06-05 13:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMty3ZC13J+bCWK_=9816Lu-5ctC0UfF4-XR3yNSpHdH8q8Faw@mail.gmail.com>
On Tue, Jun 05, 2018 at 06:23:57PM +0530, Jagan Teki wrote:
> On Fri, May 18, 2018 at 3:29 PM, Maxime Ripard
> <maxime.ripard@bootlin.com> wrote:
> > On Fri, May 18, 2018 at 03:15:10PM +0530, Jagan Teki wrote:
> >> Allwinner A64 has display engine pipeline like other Allwinner SOC's A83T/H3/H5.
> >>
> >> A64 behaviour similar to Allwinner A83T where
> >> Mixer0 => TCON0 => LVDS/RGB/MIPI-DSI
> >> Mixer1 => TCON1 => HDMI
> >> as per Display System Block DiagramAllwinner_A64_User_Manual_V1.1.pdf
> >>
> >> This is second patch-set followed with previous RFC[1] and first series[2]
> >> and merely concentrated on HDMI pipeline through TCON1 and rest will add eventually.
> >>
> >> This series fixed previous version comments
> >> - about documenting fallback compatibles
> >> - adding new compatible for mixer1
> >> - support for multiple DW HDMI PHY clock parents (thanks, to Jernej)
> >>
> >> Note:
> >> Pine64 boards are unable to get edid by default like other A64 boards,
> >> but forcing 'video=HDMI-A-1:1920x1080 at 60D' kernel command line can
> >> create edid with display on penel.
> >
> > There's no point in trying to push this without the SRAM issue being
> > solved. It is required, and won't be merged unless this is addressed.
>
> is SRAM issue resolved? if so may be I will try to test it on top.
I'd expect the one working on this to push a solution to solve this.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180605/60278b7a/attachment.sig>
^ permalink raw reply
* [PATCH v7 1/5] drm/rockchip: add transfer function for cdn-dp
From: Heiko Stübner @ 2018-06-05 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527061353-16902-1-git-send-email-hl@rock-chips.com>
Hi,
Am Mittwoch, 23. Mai 2018, 09:42:29 CEST schrieb Lin Huang:
> From: Chris Zhong <zyw@rock-chips.com>
>
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> Reviewed-by: Sean Paul <seanpaul@chromium.org>
> Reviewed-by: Enric Balletbo <enric.balletbo@collabora.com>
> @@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct
> device *master, void *data) dp->active = false;
> dp->active_port = -1;
> dp->fw_loaded = false;
> + dp->aux.name = "DP-AUX";
> + dp->aux.transfer = cdn_dp_aux_transfer;
> + dp->aux.dev = dev;
> +
> + ret = drm_dp_aux_register(&dp->aux);
> + if (ret)
> + return ret;
this is missing matching drm_dp_aux_unregister calls both in the error path as
well as in the unbind callback.
With the code as is, the kernel gives warnings about it trying to initialize
an already initialized object ... in cases like probe-deferrals.
Heiko
^ permalink raw reply
* [PATCH 1/3] Revert "arm64: topology: divorce MC scheduling domain from core_siblings"
From: Sudeep Holla @ 2018-06-05 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWJWj3a0MZgEi7VJTUJRNoeR+X3eoN8A-sW6fwimEr6Fg@mail.gmail.com>
This reverts commit 37c3ec2d810f87eac73822f76b30391a83bded19.
Currently on ARM64 platforms, we don't update the CPU topology masks
on each hotplug operation. However, the updates to cpu_coregroup_mask
done as part of ACPI PPTT support, in particular the commit being
reverted makes use of cpumask_of_node which returns the cpu_oneline_mask
instead of core_sibling as core_sibling masks are not updated for CPU
hotplug operations and the comparision to find NUMA in package or LLC
siblings fails.
The original commit is technically correct and since it depends on the
not yet supported feature, let's revert this for now. We can put it back
once we have the support for CPU topology masks update on hotplug merged.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/include/asm/topology.h | 2 --
arch/arm64/kernel/topology.c | 36 +-----------------------------------
2 files changed, 1 insertion(+), 37 deletions(-)
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index df48212f767b..6b10459e6905 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -8,10 +8,8 @@ struct cpu_topology {
int thread_id;
int core_id;
int package_id;
- int llc_id;
cpumask_t thread_sibling;
cpumask_t core_sibling;
- cpumask_t llc_siblings;
};
extern struct cpu_topology cpu_topology[NR_CPUS];
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 7415c166281f..047d98e68502 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -13,7 +13,6 @@
#include <linux/acpi.h>
#include <linux/arch_topology.h>
-#include <linux/cacheinfo.h>
#include <linux/cpu.h>
#include <linux/cpumask.h>
#include <linux/init.h>
@@ -215,19 +214,7 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
-
- /* Find the smaller of NUMA, core or LLC siblings */
- if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
- /* not numa in package, lets use the package siblings */
- core_mask = &cpu_topology[cpu].core_sibling;
- }
- if (cpu_topology[cpu].llc_id != -1) {
- if (cpumask_subset(&cpu_topology[cpu].llc_siblings, core_mask))
- core_mask = &cpu_topology[cpu].llc_siblings;
- }
-
- return core_mask;
+ return &cpu_topology[cpu].core_sibling;
}
static void update_siblings_masks(unsigned int cpuid)
@@ -239,9 +226,6 @@ static void update_siblings_masks(unsigned int cpuid)
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
- if (cpuid_topo->llc_id == cpu_topo->llc_id)
- cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
-
if (cpuid_topo->package_id != cpu_topo->package_id)
continue;
@@ -307,10 +291,6 @@ static void __init reset_cpu_topology(void)
cpu_topo->core_id = 0;
cpu_topo->package_id = -1;
- cpu_topo->llc_id = -1;
- cpumask_clear(&cpu_topo->llc_siblings);
- cpumask_set_cpu(cpu, &cpu_topo->llc_siblings);
-
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
@@ -331,8 +311,6 @@ static int __init parse_acpi_topology(void)
is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
for_each_possible_cpu(cpu) {
- int i, cache_id;
-
topology_id = find_acpi_cpu_topology(cpu, 0);
if (topology_id < 0)
return topology_id;
@@ -347,18 +325,6 @@ static int __init parse_acpi_topology(void)
}
topology_id = find_acpi_cpu_topology_package(cpu);
cpu_topology[cpu].package_id = topology_id;
-
- i = acpi_find_last_cache_level(cpu);
-
- if (i > 0) {
- /*
- * this is the only part of cpu_topology that has
- * a direct relationship with the cache topology
- */
- cache_id = find_acpi_cpu_cache_topology(cpu, i);
- if (cache_id > 0)
- cpu_topology[cpu].llc_id = cache_id;
- }
}
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ACPI / PPTT: fix build when CONFIG_ACPI_PPTT is not enabled
From: Sudeep Holla @ 2018-06-05 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528206938-2702-1-git-send-email-sudeep.holla@arm.com>
Though CONFIG_ACPI_PPTT is selected by platforms and nor user visible,
it may be useful to support the build with CONFIG_ACPI_PPTT disabled.
This patch adds the missing dummy/boiler plate implementation to fix
the build.
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
include/linux/acpi.h | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
Hi Rafael,
If you are fine with this, can you provide Ack, so that we route this
through ARM64 tree where most of the ACPI PPTT support is present.
Regards,
Sudeep
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 8f2cdb0eca71..0fa28265d095 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1299,8 +1299,28 @@ static inline int lpit_read_residency_count_address(u64 *address)
}
#endif
+#ifdef CONFIG_ACPI_PPTT
int find_acpi_cpu_topology(unsigned int cpu, int level);
int find_acpi_cpu_topology_package(unsigned int cpu);
int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
+int acpi_find_last_cache_level(unsigned int cpu);
+#else
+static inline int find_acpi_cpu_topology(unsigned int cpu, int level)
+{
+ return -EINVAL;
+}
+static inline int find_acpi_cpu_topology_package(unsigned int cpu)
+{
+ return -EINVAL;
+}
+static inline int find_acpi_cpu_cache_topology(unsigned int cpu, int level)
+{
+ return -EINVAL;
+}
+static inline int acpi_find_last_cache_level(unsigned int cpu)
+{
+ return -EINVAL;
+}
+#endif
#endif /*_LINUX_ACPI_H*/
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] arm64: disable ACPI PPTT support temporarily
From: Sudeep Holla @ 2018-06-05 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528206938-2702-1-git-send-email-sudeep.holla@arm.com>
Currently, ARM64 doesn't support updating the CPU topology masks on
CPU hotplug operations. ACPI PPTT support rely on that missing feature
which is technically not incorrect. Instead of reverting all the PPTT
support, let's keep it simple and disable ACPI PPTT support on ARM64
for time-being until the topology updates are added for CPU hotplug
operations.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9fd4a8ccce07..98a5c78a80f9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -7,7 +7,6 @@ config ARM64
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ACPI_MCFG if ACPI
select ACPI_SPCR_TABLE if ACPI
- select ACPI_PPTT if ACPI
select ARCH_CLOCKSOURCE_DATA
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
--
2.7.4
^ permalink raw reply related
* [PATCH 09/10] dpaa_eth: add support for hardware timestamping
From: Richard Cochran @ 2018-06-05 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB6PR0401MB2536376432EC481473A5B4A3F8660@DB6PR0401MB2536.eurprd04.prod.outlook.com>
On Tue, Jun 05, 2018 at 03:35:28AM +0000, Y.b. Lu wrote:
> [Y.b. Lu] Actually these timestamping codes affected DPAA networking performance in our previous performance test.
> That's why we used ifdef for it.
How much does time stamping hurt performance?
If the time stamping is compiled in but not enabled at run time, does
it still affect performace?
Thanks,
Richard
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v2 00/26] arm64: allwinner: Add A64 DE2 HDMI support
From: Icenowy Zheng @ 2018-06-05 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605132539.m54xwfzfs6btrmtc@flea>
? 2018?6?5? GMT+08:00 ??9:25:39, Maxime Ripard <maxime.ripard@bootlin.com> ??:
>On Tue, Jun 05, 2018 at 06:23:57PM +0530, Jagan Teki wrote:
>> On Fri, May 18, 2018 at 3:29 PM, Maxime Ripard
>> <maxime.ripard@bootlin.com> wrote:
>> > On Fri, May 18, 2018 at 03:15:10PM +0530, Jagan Teki wrote:
>> >> Allwinner A64 has display engine pipeline like other Allwinner
>SOC's A83T/H3/H5.
>> >>
>> >> A64 behaviour similar to Allwinner A83T where
>> >> Mixer0 => TCON0 => LVDS/RGB/MIPI-DSI
>> >> Mixer1 => TCON1 => HDMI
>> >> as per Display System Block
>DiagramAllwinner_A64_User_Manual_V1.1.pdf
>> >>
>> >> This is second patch-set followed with previous RFC[1] and first
>series[2]
>> >> and merely concentrated on HDMI pipeline through TCON1 and rest
>will add eventually.
>> >>
>> >> This series fixed previous version comments
>> >> - about documenting fallback compatibles
>> >> - adding new compatible for mixer1
>> >> - support for multiple DW HDMI PHY clock parents (thanks, to
>Jernej)
>> >>
>> >> Note:
>> >> Pine64 boards are unable to get edid by default like other A64
>boards,
>> >> but forcing 'video=HDMI-A-1:1920x1080 at 60D' kernel command line can
>> >> create edid with display on penel.
>> >
>> > There's no point in trying to push this without the SRAM issue
>being
>> > solved. It is required, and won't be merged unless this is
>addressed.
>>
>> is SRAM issue resolved? if so may be I will try to test it on top.
>
>I'd expect the one working on this to push a solution to solve this.
I'll do it soon. Currently I'm a little busy.
>
>Maxime
^ permalink raw reply
* [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
From: Rob Herring @ 2018-06-05 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605060510.32473-1-nm@ti.com>
On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon <nm@ti.com> wrote:
> The AM654 SoC is a lead device of the K3 Multicore SoC architecture
> platform, targeted for broad market and industrial control with aim to
> meet the complex processing needs of modern embedded products.
>
> Some highlights of this SoC are:
> * Quad ARMv8 A53 cores split over two clusters
> * GICv3 compliant GIC500
> * Configurable L3 Cache and IO-coherent architecture
> * Dual lock-step capable R5F uC for safety-critical applications
> * High data throughput capable distributed DMA architecture under NAVSS
> * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
> PRUs and dual RTUs
> * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
> * Centralized System Controller for Security, Power, and Resource
> management.
> * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
> * Flash subystem with OSPI and Hyperbus interfaces
> * Multimedia capability with CAL, DSS7-UL, SGX544, McASP
> * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
> GPIO
>
> See AM65x Technical Reference Manual (SPRUID7, April 2018)
> for further details: http://www.ti.com/lit/pdf/spruid7
>
> We introduce the Kconfig symbol for the SoC along with this patch since
> it is logically relevant point, however the usage is in subsequent
> patches.
>
> NOTE: AM654 is the first of the device variants, hence we introduce a
> generic am6.dtsi.
>
> Signed-off-by: Benjamin Fair <b-fair@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> MAINTAINERS | 1 +
> arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++++++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 ++++++++++++++++++++++++++++
> drivers/soc/ti/Kconfig | 14 ++++
> 4 files changed, 276 insertions(+)
> create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cfb35b252ac7..5f5c4eddec7a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com>
> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S: Supported
> F: Documentation/devicetree/bindings/arm/ti/k3.txt
> +F: arch/arm64/boot/dts/ti/k3-*
>
> ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
> M: Santosh Shilimkar <ssantosh@kernel.org>
> diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi
> new file mode 100644
> index 000000000000..cdfa12173aac
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi
> @@ -0,0 +1,144 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM6 SoC Family
> + *
> + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> + model = "Texas Instruments K3 AM654 SoC";
> + compatible = "ti,am654";
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = &wkup_uart0;
> + serial1 = &mcu_uart0;
> + serial2 = &main_uart0;
> + serial3 = &main_uart1;
> + serial4 = &main_uart2;
> + };
> +
> + chosen { };
> +
> + firmware {
> + optee {
> + compatible = "linaro,optee-tz";
> + method = "smc";
> + };
> +
> + psci: psci {
> + compatible = "arm,psci-1.0";
> + method = "smc";
> + };
> + };
> +
> + soc0: soc0 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
Really need 64-bit addresses and sizes? Use ranges to limit the
address space if possible.
> +
> + a53_timer0: timer-cl0-cpu0 {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
> + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
> + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
> + };
> +
> + pmu: pmu {
> + compatible = "arm,armv8-pmuv3";
> + /* Recommendation from GIC500 TRM Table A.3 */
> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + };
These 2 nodes aren't on the bus, so move them up a level.
> +
> + gic: interrupt-controller at 1800000 {
> + compatible = "arm,gic-v3";
gic-500?
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + /*
> + * NOTE: we are NOT gicv2 backward compat, so no GICC,
> + * GICH or GICV
The compatible should imply this.
> + */
> + reg = <0x0 0x01800000 0x0 0x10000>, /* GICD */
> + <0x0 0x01880000 0x0 0x90000>; /* GICR */
> +
> + /*
> + * vcpumntirq:
> + * virtual CPU interface maintenance interrupt
> + */
> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +
> + gic_its: gic-its at 1000000 {
> + compatible = "arm,gic-v3-its";
> + reg = <0x0 0x1820000 0x0 0x10000>;
> + msi-controller;
> + #msi-cells = <1>;
> + };
> + };
> +
> + wkup_uart0: serial at 42300000 {
> + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
> + reg = <0x0 0x42300000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 697 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + mcu_uart0: serial at 40a00000 {
> + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
> + reg = <0x0 0x40a00000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <96000000>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + main_uart0: serial at 2800000 {
> + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
> + reg = <0x0 0x02800000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + main_uart1: serial at 2810000 {
> + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
> + reg = <0x0 0x02810000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + main_uart2: serial at 2820000 {
> + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
> + reg = <0x0 0x02820000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi b/arch/arm64/boot/dts/ti/k3-am654.dtsi
> new file mode 100644
> index 000000000000..d9b70081daba
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi
> @@ -0,0 +1,117 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM6 SoC family in Quad core configuration
> + *
> + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
> + */
> +
> +#include "k3-am6.dtsi"
> +
> +/ {
> + cpus: cpus {
Really need a label?
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu-map {
IIRC, this goes at the top level.
> + cluster0: cluster0 {
> + core0 {
> + cpu = <&cpu0>;
> + };
> +
> + core1 {
> + cpu = <&cpu1>;
> + };
> + };
> +
> + cluster1: cluster1 {
> + core0 {
> + cpu = <&cpu2>;
> + };
> +
> + core1 {
> + cpu = <&cpu3>;
> + };
> + };
> + };
> +
> + cpu0: cpu at 0 {
> + compatible = "arm,cortex-a53","arm,armv8";
space between compatibles.
> + reg = <0x000>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
All this should be discoverable.
> + next-level-cache = <&L2_0>;
> + };
> +
> + cpu1: cpu at 1 {
> + compatible = "arm,cortex-a53","arm,armv8";
> + reg = <0x001>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_0>;
> + };
> +
> + cpu2: cpu at 100 {
> + compatible = "arm,cortex-a53","arm,armv8";
> + reg = <0x100>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_1>;
> + };
> +
> + cpu3: cpu at 101 {
> + compatible = "arm,cortex-a53","arm,armv8";
> + reg = <0x101>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_1>;
> + };
> + };
> +};
> +
> +&soc0 {
> + L2_0: l2-cache0 {
> + compatible = "cache";
Is this documented?
> + cache-level = <2>;
> + cache-size = <0x80000>;
> + cache-line-size = <64>;
> + cache-sets = <512>;
Discoverable?
> + next-level-cache = <&msmc_l3>;
> + };
> +
> + L2_1: l2-cache1 {
> + compatible = "cache";
> + cache-level = <2>;
> + cache-size = <0x80000>;
> + cache-line-size = <64>;
> + cache-sets = <512>;
> + next-level-cache = <&msmc_l3>;
> + };
> +
> + msmc_l3: l3-cache0 {
> + compatible = "cache";
Is this something TI specific or follows the (ARM) architecture?
> + cache-level = <3>;
> + };
> +};
> diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
> index 92770d84a288..be4570baad96 100644
> --- a/drivers/soc/ti/Kconfig
> +++ b/drivers/soc/ti/Kconfig
> @@ -1,3 +1,17 @@
> +# 64-bit ARM SoCs from TI
> +if ARM64
> +
> +if ARCH_K3
> +
> +config ARCH_K3_AM6_SOC
This should be in another patch (or dropped?).
> + bool "K3 AM6 SoC"
> + help
> + Enable support for TI's AM6 SoC Family support
> +
> +endif
> +
> +endif
> +
> #
> # TI SOC drivers
> #
> --
> 2.15.1
>
^ permalink raw reply
* [PATCH 1/3] Revert "arm64: topology: divorce MC scheduling domain from core_siblings"
From: Geert Uytterhoeven @ 2018-06-05 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528206938-2702-1-git-send-email-sudeep.holla@arm.com>
Hi Sudeep,
On Tue, Jun 5, 2018 at 3:55 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> This reverts commit 37c3ec2d810f87eac73822f76b30391a83bded19.
>
> Currently on ARM64 platforms, we don't update the CPU topology masks
> on each hotplug operation. However, the updates to cpu_coregroup_mask
I would add
"leading to e.g. a system hang during system suspend."
to avoid people thinking this is purely a small bookkeeping issue without any
percussions.
> done as part of ACPI PPTT support, in particular the commit being
> reverted makes use of cpumask_of_node which returns the cpu_oneline_mask
> instead of core_sibling as core_sibling masks are not updated for CPU
> hotplug operations and the comparision to find NUMA in package or LLC
> siblings fails.
>
> The original commit is technically correct and since it depends on the
> not yet supported feature, let's revert this for now. We can put it back
> once we have the support for CPU topology masks update on hotplug merged.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 1/3] Revert "arm64: topology: divorce MC scheduling domain from core_siblings"
From: Sudeep Holla @ 2018-06-05 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVPRLt34SUDsbbHvEG2OzvbJoT6id7Rb_2j32=zb1TuKg@mail.gmail.com>
On 05/06/18 15:09, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Tue, Jun 5, 2018 at 3:55 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> This reverts commit 37c3ec2d810f87eac73822f76b30391a83bded19.
>>
>> Currently on ARM64 platforms, we don't update the CPU topology masks
>> on each hotplug operation. However, the updates to cpu_coregroup_mask
>
> I would add
>
> "leading to e.g. a system hang during system suspend."
>
> to avoid people thinking this is purely a small bookkeeping issue without any
> percussions.
>
Sure, thanks. Sorry for missing that.
--
Regards,
Sudeep
^ permalink raw reply
* [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
From: Tony Lindgren @ 2018-06-05 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJusWTvr4A_-Bk81meYddMHBMJ4=Fch6L0MFoF7HfBW2w@mail.gmail.com>
* Rob Herring <robh+dt@kernel.org> [180605 14:08]:
> On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon <nm@ti.com> wrote:
> > + soc0: soc0 {
> > + compatible = "simple-bus";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
>
> Really need 64-bit addresses and sizes? Use ranges to limit the
> address space if possible.
And in addition to using ranges, please set up separate bus instances
for the interconnects. This will then allow you to probe WKUP or
similar instance first and the other bus instances after. And that
pretty much allows you to get rid of the annoying -EPROBE_DEFER
ping pong and allows making clocks proper device drivers ;)
Regards,
Tony
^ permalink raw reply
* [PATCH v2 1/3] Revert "arm64: topology: divorce MC scheduling domain from core_siblings"
From: Sudeep Holla @ 2018-06-05 14:35 UTC (permalink / raw)
To: linux-arm-kernel
This reverts commit 37c3ec2d810f87eac73822f76b30391a83bded19.
Currently on ARM64 platforms, we don't update the CPU topology masks
on each hotplug operation. However, the updates to cpu_coregroup_mask
done as part of ACPI PPTT support, in particular the commit being
reverted makes use of cpumask_of_node which returns the cpu_oneline_mask
instead of core_sibling as core_sibling masks are not updated for CPU
hotplug operations and the comparision to find NUMA in package or LLC
siblings fails.
This often leads to system hang or crash during CPU hotplug and system
suspend operation. This is mostly observed on HMP systems where the
CPU compute capacities are different and ends up in different scheduler
domains. Since cpumask_of_node is returned instead core_sibling, the
scheduler is confused with incorrect cpumasks(e.g. one CPU in two
different sched domains at the same time) on CPU hotplug.
The original commit is technically correct and since it depends on the
not yet supported feature, let's revert this for now. We can put it back
once we have the support for CPU topology masks update on hotplug merged.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/include/asm/topology.h | 2 --
arch/arm64/kernel/topology.c | 36 +-----------------------------------
2 files changed, 1 insertion(+), 37 deletions(-)
v1->v2:
- Updated commit log to describe the observations made as a
consequence of the issue as suggested by Geert's
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index df48212f767b..6b10459e6905 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -8,10 +8,8 @@ struct cpu_topology {
int thread_id;
int core_id;
int package_id;
- int llc_id;
cpumask_t thread_sibling;
cpumask_t core_sibling;
- cpumask_t llc_siblings;
};
extern struct cpu_topology cpu_topology[NR_CPUS];
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 7415c166281f..047d98e68502 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -13,7 +13,6 @@
#include <linux/acpi.h>
#include <linux/arch_topology.h>
-#include <linux/cacheinfo.h>
#include <linux/cpu.h>
#include <linux/cpumask.h>
#include <linux/init.h>
@@ -215,19 +214,7 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
-
- /* Find the smaller of NUMA, core or LLC siblings */
- if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
- /* not numa in package, lets use the package siblings */
- core_mask = &cpu_topology[cpu].core_sibling;
- }
- if (cpu_topology[cpu].llc_id != -1) {
- if (cpumask_subset(&cpu_topology[cpu].llc_siblings, core_mask))
- core_mask = &cpu_topology[cpu].llc_siblings;
- }
-
- return core_mask;
+ return &cpu_topology[cpu].core_sibling;
}
static void update_siblings_masks(unsigned int cpuid)
@@ -239,9 +226,6 @@ static void update_siblings_masks(unsigned int cpuid)
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
- if (cpuid_topo->llc_id == cpu_topo->llc_id)
- cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
-
if (cpuid_topo->package_id != cpu_topo->package_id)
continue;
@@ -307,10 +291,6 @@ static void __init reset_cpu_topology(void)
cpu_topo->core_id = 0;
cpu_topo->package_id = -1;
- cpu_topo->llc_id = -1;
- cpumask_clear(&cpu_topo->llc_siblings);
- cpumask_set_cpu(cpu, &cpu_topo->llc_siblings);
-
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
@@ -331,8 +311,6 @@ static int __init parse_acpi_topology(void)
is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
for_each_possible_cpu(cpu) {
- int i, cache_id;
-
topology_id = find_acpi_cpu_topology(cpu, 0);
if (topology_id < 0)
return topology_id;
@@ -347,18 +325,6 @@ static int __init parse_acpi_topology(void)
}
topology_id = find_acpi_cpu_topology_package(cpu);
cpu_topology[cpu].package_id = topology_id;
-
- i = acpi_find_last_cache_level(cpu);
-
- if (i > 0) {
- /*
- * this is the only part of cpu_topology that has
- * a direct relationship with the cache topology
- */
- cache_id = find_acpi_cpu_cache_topology(cpu, i);
- if (cache_id > 0)
- cpu_topology[cpu].llc_id = cache_id;
- }
}
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] ACPI / PPTT: fix build when CONFIG_ACPI_PPTT is not enabled
From: Sudeep Holla @ 2018-06-05 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528209304-3280-1-git-send-email-sudeep.holla@arm.com>
Though CONFIG_ACPI_PPTT is selected by platforms and nor user visible,
it may be useful to support the build with CONFIG_ACPI_PPTT disabled.
This patch adds the missing dummy/boiler plate implementation to fix
the build.
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
include/linux/acpi.h | 15 +++++++++++++++
include/linux/cacheinfo.h | 2 +-
2 files changed, 16 insertions(+), 1 deletion(-)
Hi Rafael,
If you are fine with this, can you provide Ack, so that we route this
through ARM64 tree where most of the ACPI PPTT support is present.
Regards,
Sudeep
v1->v2:
- removed duplicate definition for acpi_find_last_cache_level
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 8f2cdb0eca71..4b35a66383f9 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1299,8 +1299,23 @@ static inline int lpit_read_residency_count_address(u64 *address)
}
#endif
+#ifdef CONFIG_ACPI_PPTT
int find_acpi_cpu_topology(unsigned int cpu, int level);
int find_acpi_cpu_topology_package(unsigned int cpu);
int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
+#else
+static inline int find_acpi_cpu_topology(unsigned int cpu, int level)
+{
+ return -EINVAL;
+}
+static inline int find_acpi_cpu_topology_package(unsigned int cpu)
+{
+ return -EINVAL;
+}
+static inline int find_acpi_cpu_cache_topology(unsigned int cpu, int level)
+{
+ return -EINVAL;
+}
+#endif
#endif /*_LINUX_ACPI_H*/
diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
index 89397e30e269..70e19bc6cc9f 100644
--- a/include/linux/cacheinfo.h
+++ b/include/linux/cacheinfo.h
@@ -98,7 +98,7 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu);
int init_cache_level(unsigned int cpu);
int populate_cache_leaves(unsigned int cpu);
int cache_setup_acpi(unsigned int cpu);
-#ifndef CONFIG_ACPI
+#ifndef CONFIG_ACPI_PPTT
/*
* acpi_find_last_cache_level is only called on ACPI enabled
* platforms using the PPTT for topology. This means that if
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] arm64: disable ACPI PPTT support temporarily
From: Sudeep Holla @ 2018-06-05 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528209304-3280-1-git-send-email-sudeep.holla@arm.com>
Currently, ARM64 doesn't support updating the CPU topology masks on
CPU hotplug operations. ACPI PPTT support rely on that missing feature
which is technically not incorrect. Instead of reverting all the PPTT
support, let's keep it simple and disable ACPI PPTT support on ARM64
for time-being until the topology updates are added for CPU hotplug
operations.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9fd4a8ccce07..98a5c78a80f9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -7,7 +7,6 @@ config ARM64
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ACPI_MCFG if ACPI
select ACPI_SPCR_TABLE if ACPI
- select ACPI_PPTT if ACPI
select ARCH_CLOCKSOURCE_DATA
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
--
2.7.4
^ 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