* [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
* 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] 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
* [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] 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
* 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] 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
* [PATCH] irqchip/stm32: fix non-SMP build warning
From: Ludovic BARRE @ 2018-06-05 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605114347.1347128-1-arnd@arndb.de>
On 06/05/2018 01:43 PM, Arnd Bergmann wrote:
> Without CONFIG_SMP, we get a harmless compile-time warning:
>
> drivers/irqchip/irq-stm32-exti.c:495:12: error: 'stm32_exti_h_set_affinity' defined but not used [-Werror=unused-function]
>
> The #ifdef is inconsistent here, and it's better to use an IS_ENABLED() check
> that lets the compiler silently drop that function.
>
> Fixes: 927abfc4461e ("irqchip/stm32: Add stm32mp1 support with hierarchy domain")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/irqchip/irq-stm32-exti.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c
> index 5089c1e2838d..3a7e8905a97e 100644
> --- a/drivers/irqchip/irq-stm32-exti.c
> +++ b/drivers/irqchip/irq-stm32-exti.c
> @@ -552,9 +552,7 @@ static struct irq_chip stm32_exti_h_chip = {
> .irq_set_type = stm32_exti_h_set_type,
> .irq_set_wake = stm32_exti_h_set_wake,
> .flags = IRQCHIP_MASK_ON_SUSPEND,
> -#ifdef CONFIG_SMP
> - .irq_set_affinity = stm32_exti_h_set_affinity,
> -#endif
> + .irq_set_affinity = IS_ENABLED(CONFIG_SMP) ? stm32_exti_h_set_affinity : NULL,
thanks Arnd, sorry to forgotten config flag test
Reviewed-by: Ludovic Barre <ludovic.barre@st.com>
> };
>
> static int stm32_exti_h_domain_alloc(struct irq_domain *dm,
>
^ permalink raw reply
* [PATCH V4] PCI: move early dump functionality from x86 arch into the common code
From: okaya at codeaurora.org @ 2018-06-05 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VdD0Ds6dFdYWF8YpY04hiKY-LmfOU7+dPs7PkTOjbRKbw@mail.gmail.com>
On 2018-06-05 05:12, Andy Shevchenko wrote:
> On Tue, Jun 5, 2018 at 5:16 AM, Sinan Kaya <okaya@codeaurora.org>
> wrote:
>> Move early dump functionality into common code so that it is available
>> for
>> all archtiectures. No need to carry arch specific reads around as the
>> read
>> hooks are already initialized by the time pci_setup_device() is
>> getting
>> called during scan.
>>
>
> Makes sense.
>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>
> One style comment below, though.
>
> If you wait a bit, I perhaps would be able to test on x86.
Sure, no rush. This is a nice to have feature with no urgency.
>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 2 +-
>> arch/x86/include/asm/pci-direct.h | 4 ---
>> arch/x86/kernel/setup.c | 5 ---
>> arch/x86/pci/common.c | 4 ---
>> arch/x86/pci/early.c | 44
>> -------------------------
>> drivers/pci/pci.c | 5 +++
>> drivers/pci/pci.h | 1 +
>> drivers/pci/probe.c | 19 +++++++++++
>> 8 files changed, 26 insertions(+), 58 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>> b/Documentation/admin-guide/kernel-parameters.txt
>> index e490902..e64f1d8 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -2995,7 +2995,7 @@
>> See also Documentation/blockdev/paride.txt.
>>
>> pci=option[,option...] [PCI] various PCI subsystem options:
>> - earlydump [X86] dump PCI config space before the
>> kernel
>> + earlydump dump PCI config space before the
>> kernel
>> changes anything
>> off [X86] don't probe for the PCI bus
>> bios [X86-32] force use of PCI BIOS, don't
>> access
>> diff --git a/arch/x86/include/asm/pci-direct.h
>> b/arch/x86/include/asm/pci-direct.h
>> index e1084f7..94597a3 100644
>> --- a/arch/x86/include/asm/pci-direct.h
>> +++ b/arch/x86/include/asm/pci-direct.h
>> @@ -15,8 +15,4 @@ extern void write_pci_config_byte(u8 bus, u8 slot,
>> u8 func, u8 offset, u8 val);
>> extern void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset,
>> u16 val);
>>
>> extern int early_pci_allowed(void);
>> -
>> -extern unsigned int pci_early_dump_regs;
>> -extern void early_dump_pci_device(u8 bus, u8 slot, u8 func);
>> -extern void early_dump_pci_devices(void);
>> #endif /* _ASM_X86_PCI_DIRECT_H */
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index 2f86d88..480f250 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -991,11 +991,6 @@ void __init setup_arch(char **cmdline_p)
>> setup_clear_cpu_cap(X86_FEATURE_APIC);
>> }
>>
>> -#ifdef CONFIG_PCI
>> - if (pci_early_dump_regs)
>> - early_dump_pci_devices();
>> -#endif
>> -
>> e820__reserve_setup_data();
>> e820__finish_early_params();
>>
>> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
>> index 563049c..d4ec117 100644
>> --- a/arch/x86/pci/common.c
>> +++ b/arch/x86/pci/common.c
>> @@ -22,7 +22,6 @@
>> unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 |
>> PCI_PROBE_CONF2 |
>> PCI_PROBE_MMCONF;
>>
>> -unsigned int pci_early_dump_regs;
>> static int pci_bf_sort;
>> int pci_routeirq;
>> int noioapicquirk;
>> @@ -599,9 +598,6 @@ char *__init pcibios_setup(char *str)
>> pci_probe |= PCI_BIG_ROOT_WINDOW;
>> return NULL;
>> #endif
>> - } else if (!strcmp(str, "earlydump")) {
>> - pci_early_dump_regs = 1;
>> - return NULL;
>> } else if (!strcmp(str, "routeirq")) {
>> pci_routeirq = 1;
>> return NULL;
>> diff --git a/arch/x86/pci/early.c b/arch/x86/pci/early.c
>> index e5f753c..f5fc953 100644
>> --- a/arch/x86/pci/early.c
>> +++ b/arch/x86/pci/early.c
>> @@ -57,47 +57,3 @@ int early_pci_allowed(void)
>> PCI_PROBE_CONF1;
>> }
>>
>> -void early_dump_pci_device(u8 bus, u8 slot, u8 func)
>> -{
>> - u32 value[256 / 4];
>> - int i;
>> -
>> - pr_info("pci 0000:%02x:%02x.%d config space:\n", bus, slot,
>> func);
>> -
>> - for (i = 0; i < 256; i += 4)
>> - value[i / 4] = read_pci_config(bus, slot, func, i);
>> -
>> - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1,
>> value, 256, false);
>> -}
>> -
>> -void early_dump_pci_devices(void)
>> -{
>> - unsigned bus, slot, func;
>> -
>> - if (!early_pci_allowed())
>> - return;
>> -
>> - for (bus = 0; bus < 256; bus++) {
>> - for (slot = 0; slot < 32; slot++) {
>> - for (func = 0; func < 8; func++) {
>> - u32 class;
>> - u8 type;
>> -
>> - class = read_pci_config(bus, slot,
>> func,
>> -
>> PCI_CLASS_REVISION);
>> - if (class == 0xffffffff)
>> - continue;
>> -
>> - early_dump_pci_device(bus, slot,
>> func);
>> -
>> - if (func == 0) {
>> - type =
>> read_pci_config_byte(bus, slot,
>> -
>> func,
>> -
>> PCI_HEADER_TYPE);
>> - if (!(type & 0x80))
>> - break;
>> - }
>> - }
>> - }
>> - }
>> -}
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index 97acba7..04052dc 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -115,6 +115,9 @@ static bool pcie_ari_disabled;
>> /* If set, the PCIe ATS capability will not be used. */
>> static bool pcie_ats_disabled;
>>
>> +/* If set, the PCI config space of each device is printed during
>> boot. */
>> +bool pci_early_dump;
>> +
>> bool pci_ats_disabled(void)
>> {
>> return pcie_ats_disabled;
>> @@ -5805,6 +5808,8 @@ static int __init pci_setup(char *str)
>> pcie_ats_disabled = true;
>> } else if (!strcmp(str, "noaer")) {
>> pci_no_aer();
>> + } else if (!strcmp(str, "earlydump")) {
>> + pci_early_dump = true;
>> } else if (!strncmp(str, "realloc=", 8)) {
>> pci_realloc_get_opt(str + 8);
>> } else if (!strncmp(str, "realloc", 7)) {
>> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
>> index c358e7a0..c33265e 100644
>> --- a/drivers/pci/pci.h
>> +++ b/drivers/pci/pci.h
>> @@ -7,6 +7,7 @@
>> #define PCI_VSEC_ID_INTEL_TBT 0x1234 /* Thunderbolt */
>>
>> extern const unsigned char pcie_link_speed[];
>> +extern bool pci_early_dump;
>>
>> bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
>>
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 56771f3..3678f0a 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -1545,6 +1545,23 @@ static int pci_intx_mask_broken(struct pci_dev
>> *dev)
>> return 0;
>> }
>>
>> +static void early_dump_pci_device(struct pci_dev *pdev)
>> +{
>> + u32 value[256 / 4];
>> + int i;
>> +
>> + if (!pci_early_dump)
>> + return;
>> +
>> + pci_info(pdev, "config space:\n");
>> +
>> + for (i = 0; i < 256; i += 4)
>> + pci_read_config_dword(pdev, i, &value[i / 4]);
>> +
>
>> + print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1,
>> value,
>> + 256, false);
>
> Logically better either to move value to second line, or move 256 on
> the first line.
>
>> +}
>> +
>> /**
>> * pci_setup_device - Fill in class and map information of a device
>> * @dev: the device structure to fill
>> @@ -1594,6 +1611,8 @@ int pci_setup_device(struct pci_dev *dev)
>> pci_printk(KERN_DEBUG, dev, "[%04x:%04x] type %02x class
>> %#08x\n",
>> dev->vendor, dev->device, dev->hdr_type,
>> dev->class);
>>
>> + early_dump_pci_device(dev);
>> +
>> /* Need to have dev->class ready */
>> dev->cfg_size = pci_cfg_space_size(dev);
>>
>> --
>> 2.7.4
>>
^ permalink raw reply
* [PATCH] ARM: rpc: use designated initializers in ecard_default_ops
From: Arnd Bergmann @ 2018-06-05 11:53 UTC (permalink / raw)
To: linux-arm-kernel
When the randstruct plugin is enabled, we get a warning about the
use of traditional struct initializers for this structure, which
results in incorrect behavior:
arch/arm/mach-rpc/ecard.c:416:2: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
ecard_def_irq_enable,
^~~~~~~~~~~~~~~~~~~~
arch/arm/mach-rpc/ecard.c:416:2: note: (near initialization for 'ecard_default_ops')
arch/arm/mach-rpc/ecard.c:416:2: error: invalid initializer
arch/arm/mach-rpc/ecard.c:416:2: note: (near initialization for 'ecard_default_ops.<anonymous>')
arch/arm/mach-rpc/ecard.c:417:2: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
ecard_def_irq_disable,
^~~~~~~~~~~~~~~~~~~~~
This changes it to use designated initializers like we do for all
other structures.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-rpc/ecard.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-rpc/ecard.c b/arch/arm/mach-rpc/ecard.c
index 39aef4876ed4..d0c4e20de4f3 100644
--- a/arch/arm/mach-rpc/ecard.c
+++ b/arch/arm/mach-rpc/ecard.c
@@ -413,12 +413,12 @@ static int ecard_def_fiq_pending(ecard_t *ec)
}
static expansioncard_ops_t ecard_default_ops = {
- ecard_def_irq_enable,
- ecard_def_irq_disable,
- ecard_def_irq_pending,
- ecard_def_fiq_enable,
- ecard_def_fiq_disable,
- ecard_def_fiq_pending
+ .irqenable = ecard_def_irq_enable,
+ .irqdisable = ecard_def_irq_disable,
+ .irqpending = ecard_def_irq_pending,
+ .fiqenable = ecard_def_fiq_enable,
+ .fiqdisable = ecard_def_fiq_disable,
+ .fiqpending = ecard_def_fiq_pending
};
/*
--
2.9.0
^ permalink raw reply related
* [PATCH] arm64: cpu_errata: include required headers
From: Arnd Bergmann @ 2018-06-05 11:50 UTC (permalink / raw)
To: linux-arm-kernel
Without including psci.h and arm-smccc.h, we now get a build failure in
some configurations:
arch/arm64/kernel/cpu_errata.c: In function 'arm64_update_smccc_conduit':
arch/arm64/kernel/cpu_errata.c:278:10: error: 'psci_ops' undeclared (first use in this function); did you mean 'sysfs_ops'?
arch/arm64/kernel/cpu_errata.c: In function 'arm64_set_ssbd_mitigation':
arch/arm64/kernel/cpu_errata.c:311:3: error: implicit declaration of function 'arm_smccc_1_1_hvc' [-Werror=implicit-function-declaration]
arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_WORKAROUND_2, state, NULL);
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
This showed up only recently, but I have not bisected what caused it.
---
arch/arm64/kernel/cpu_errata.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 2b9a31a6a16a..1d2b6d768efe 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -16,6 +16,8 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/arm-smccc.h>
+#include <linux/psci.h>
#include <linux/types.h>
#include <asm/cpu.h>
#include <asm/cputype.h>
--
2.9.0
^ permalink raw reply related
* [PATCH] coresight: include vmalloc.h for vmap/vunmap
From: Arnd Bergmann @ 2018-06-05 11:48 UTC (permalink / raw)
To: linux-arm-kernel
The newly introduced code fails to build in some configurations
unless we include the right headers:
drivers/hwtracing/coresight/coresight-tmc-etr.c: In function 'tmc_free_table_pages':
drivers/hwtracing/coresight/coresight-tmc-etr.c:206:3: error: implicit declaration of function 'vunmap'; did you mean 'iounmap'? [-Werror=implicit-function-declaration]
Fixes: 79613ae8715a ("coresight: Add generic TMC sg table framework")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 6164eed0b5fe..3556d9a849e9 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -8,6 +8,7 @@
#include <linux/dma-mapping.h>
#include <linux/iommu.h>
#include <linux/slab.h>
+#include <linux/vmalloc.h>
#include "coresight-priv.h"
#include "coresight-tmc.h"
--
2.9.0
^ permalink raw reply related
* [PATCH] irqchip/stm32: fix non-SMP build warning
From: Arnd Bergmann @ 2018-06-05 11:43 UTC (permalink / raw)
To: linux-arm-kernel
Without CONFIG_SMP, we get a harmless compile-time warning:
drivers/irqchip/irq-stm32-exti.c:495:12: error: 'stm32_exti_h_set_affinity' defined but not used [-Werror=unused-function]
The #ifdef is inconsistent here, and it's better to use an IS_ENABLED() check
that lets the compiler silently drop that function.
Fixes: 927abfc4461e ("irqchip/stm32: Add stm32mp1 support with hierarchy domain")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/irqchip/irq-stm32-exti.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c
index 5089c1e2838d..3a7e8905a97e 100644
--- a/drivers/irqchip/irq-stm32-exti.c
+++ b/drivers/irqchip/irq-stm32-exti.c
@@ -552,9 +552,7 @@ static struct irq_chip stm32_exti_h_chip = {
.irq_set_type = stm32_exti_h_set_type,
.irq_set_wake = stm32_exti_h_set_wake,
.flags = IRQCHIP_MASK_ON_SUSPEND,
-#ifdef CONFIG_SMP
- .irq_set_affinity = stm32_exti_h_set_affinity,
-#endif
+ .irq_set_affinity = IS_ENABLED(CONFIG_SMP) ? stm32_exti_h_set_affinity : NULL,
};
static int stm32_exti_h_domain_alloc(struct irq_domain *dm,
--
2.9.0
^ permalink raw reply related
* [PATCH v4 3/3] ARM: dts: Renesas R9A06G032 SMP enable method
From: Michel Pollet @ 2018-06-05 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528198148-23308-1-git-send-email-michel.pollet@bp.renesas.com>
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>
---
arch/arm/boot/dts/r9a06g032.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
index 40827bb..9d7e74a 100644
--- a/arch/arm/boot/dts/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -1,3 +1,4 @@
+
// SPDX-License-Identifier: GPL-2.0
/*
* Base Device Tree Source for the Renesas RZ/N1D (R9A06G032)
@@ -30,6 +31,8 @@
compatible = "arm,cortex-a7";
reg = <1>;
clocks = <&sysctrl R9A06G032_CLK_A7MP>;
+ enable-method = "renesas,r9a06g032-smp";
+ cpu-release-addr = <0x4000c204>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Michel Pollet @ 2018-06-05 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528198148-23308-1-git-send-email-michel.pollet@bp.renesas.com>
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>
---
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/smp-r9a06g032.c | 79 ++++++++++++++++++++++++++++++++++
2 files changed, 80 insertions(+)
create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 1939f52..d7fc98f 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0) += smp-sh73a0.o headsmp-scu.o platsmp-scu.o
smp-$(CONFIG_ARCH_R8A7779) += smp-r8a7779.o headsmp-scu.o platsmp-scu.o
smp-$(CONFIG_ARCH_R8A7790) += smp-r8a7790.o
smp-$(CONFIG_ARCH_R8A7791) += smp-r8a7791.o
+smp-$(CONFIG_ARCH_R9A06G032) += smp-r9a06g032.o
smp-$(CONFIG_ARCH_EMEV2) += smp-emev2.o headsmp-scu.o platsmp-scu.o
# PM objects
diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c b/arch/arm/mach-shmobile/smp-r9a06g032.c
new file mode 100644
index 0000000..cd40e6e
--- /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
+ */
+
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/smp.h>
+
+/*
+ * The second CPU is parked in ROM at boot time. It requires waking it after
+ * writing an address into the BOOTADDR register of sysctrl.
+ *
+ * So the default value of the "cpu-release-addr" corresponds to BOOTADDR...
+ *
+ * *However* the BOOTADDR register is not available when the kernel
+ * starts in NONSEC mode.
+ *
+ * So for NONSEC mode, the bootloader re-parks the second CPU into a pen
+ * in SRAM, and changes the "cpu-release-addr" of linux's DT to a SRAM address,
+ * which is not restricted.
+ */
+
+static void __iomem *cpu_bootaddr;
+
+static DEFINE_SPINLOCK(cpu_lock);
+
+static int r9a06g032_smp_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+ if (!cpu_bootaddr)
+ return -ENODEV;
+
+ spin_lock(&cpu_lock);
+
+ writel(__pa_symbol(secondary_startup), cpu_bootaddr);
+ arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+
+ spin_unlock(&cpu_lock);
+
+ return 0;
+}
+
+static void __init r9a06g032_smp_prepare_cpus(unsigned int max_cpus)
+{
+ struct device_node *dn;
+ int ret;
+ u32 bootaddr;
+
+ dn = of_get_cpu_node(1, NULL);
+ if (!dn) {
+ pr_err("CPU#1: missing device tree node\n");
+ return;
+ }
+ /*
+ * Determine the address from which the CPU is polling.
+ * The bootloader *does* change this property
+ */
+ ret = of_property_read_u32(dn, "cpu-release-addr", &bootaddr);
+ of_node_put(dn);
+ if (ret) {
+ pr_err("CPU#1: invalid cpu-release-addr property\n");
+ return;
+ }
+ pr_info("CPU#1: cpu-release-addr %08x\n", bootaddr);
+
+ cpu_bootaddr = ioremap(bootaddr, sizeof(bootaddr));
+}
+
+static const struct smp_operations r9a06g032_smp_ops __initconst = {
+ .smp_prepare_cpus = r9a06g032_smp_prepare_cpus,
+ .smp_boot_secondary = r9a06g032_smp_boot_secondary,
+};
+CPU_METHOD_OF_DECLARE(r9a06g032_smp, "renesas,r9a06g032-smp", &r9a06g032_smp_ops);
--
2.7.4
^ permalink raw reply related
* [PATCH v4 1/3] dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method.
From: Michel Pollet @ 2018-06-05 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528198148-23308-1-git-send-email-michel.pollet@bp.renesas.com>
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>
---
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 29e1dc5..b395d107 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -219,6 +219,7 @@ described below.
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
"renesas,apmu"
+ "renesas,r9a06g032-smp"
"rockchip,rk3036-smp"
"rockchip,rk3066-smp"
"ste,dbx500-smp"
--
2.7.4
^ permalink raw reply related
* [PATCH v4 0/3] Renesas R9A06G032 SMP enabler
From: Michel Pollet @ 2018-06-05 11:28 UTC (permalink / raw)
To: linux-arm-kernel
*WARNING -- this requires the base R9A06G032 support patches
already posted
This patch series is for enabling the second CA7 of the R9A06G032.
It's based on a spin_table method, and it reuses the same binding
property as that driver.
v4:
+ Geert's comments adressed.
+ Renamed symbols to r9a06g032 to match the rest of patchset
+ Rebased on base patch v8
v3:
+ Removed mentions of rz/?n1d?
+ Rebased on base patch v7
v2:
+ Added suggestions from Florian Fainelli
+ Use __pa_symbol()
+ Simplified logic in prepare_cpu()
+ Reordered the patches
+ Rebased on RZN1 Base patch v5
Michel Pollet (3):
dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method.
arm: shmobile: Add the R9A06G032 SMP enabler driver
ARM: dts: Renesas R9A06G032 SMP enable method
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/boot/dts/r9a06g032.dtsi | 3 +
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/smp-r9a06g032.c | 79 ++++++++++++++++++++++++++
4 files changed, 84 insertions(+)
create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
--
2.7.4
^ permalink raw reply
* [PATCH v3 1/3] cpufreq: imx6q: check speed grades for i.MX6ULL
From: Fabio Estevam @ 2018-06-05 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522062853.24799-1-sebastien.szymanski@armadeus.com>
On Tue, May 22, 2018 at 3:28 AM, S?bastien Szymanski
<sebastien.szymanski@armadeus.com> wrote:
> Check the max speed supported from the fuses for i.MX6ULL and update the
> operating points table accordingly.
>
> Signed-off-by: S?bastien Szymanski <sebastien.szymanski@armadeus.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH v4.9-stable] serial: pl011: add console matching function
From: Greg KH @ 2018-06-05 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604131612.14407-1-ard.biesheuvel@linaro.org>
On Mon, Jun 04, 2018 at 03:16:12PM +0200, Ard Biesheuvel wrote:
> From: Aleksey Makarov <aleksey.makarov@linaro.org>
>
> Commit 10879ae5f12e9cab3c4e8e9504c1aaa8a033bde7 upstream.
>
> This patch adds function pl011_console_match() that implements
> method match of struct console. It allows to match consoles against
> data specified in a string, for example taken from command line or
> compiled by ACPI SPCR table handler.
>
> This patch was merged to tty-next but then reverted because of
> conflict with
>
> commit 46e36683f433 ("serial: earlycon: Extend earlycon command line option to support 64-bit addresses")
>
> Now it is fixed.
>
> Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
> Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
> Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
> Tested-by: Christopher Covington <cov@codeaurora.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>
> Please consider for v4.9-stable. It is the missing puzzle piece for SPCR
> support on arm64 ACPI systems, which got merged for v4.9 [0]. Now that more
> systems are becoming available to people working in the kernel community, it
> turns out that v4.9 distro installers (e.g., Debian Stretch) won't work
> unless you pass a 'console=' parameter explicitly, which is annoying.
> Given that it was clearly the intent to include this code at the time,
> I hope it will be considered for backporting.
>
> [0] To quote the tty maintainer:
>
> Also in here is the long-suffering ACPI SPCR patchset, which was
> passed around from maintainer to maintainer like a hot-potato. Seems I
> was the sucker^Wlucky one. All of those patches have been acked by the
> various subsystem maintainers as well.
Now queued up, thanks.
greg k-h
^ permalink raw reply
* [PATCH] irqchip/gic-v3-its: fix ITS queue timeout
From: Julien Thierry @ 2018-06-05 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528180225-16144-1-git-send-email-yangyingliang@huawei.com>
Hi Yang,
On 05/06/18 07:30, Yang Yingliang wrote:
> When the kernel booted with maxcpus=x, 'x' is smaller
> than actual cpu numbers, the TAs of offline cpus won't
> be set to its->collection.
>
> If LPI is bind to offline cpu, sync cmd will use zero TA,
> it leads to ITS queue timeout. Fix this by choosing a
> online cpu, if there is no online cpu in cpu_mask.
>
> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 5416f2b..edd92a9 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -2309,7 +2309,9 @@ static int its_irq_domain_activate(struct irq_domain *domain,
> cpu_mask = cpumask_of_node(its_dev->its->numa_node);
>
> /* Bind the LPI to the first possible CPU */
> - cpu = cpumask_first(cpu_mask);
> + cpu = cpumask_first_and(cpu_mask, cpu_online_mask);
> + if (!cpu_online(cpu))
Testing for cpu being online here feels a bit redundant.
Since cpu is online if the cpumask_first_and returns a valid cpu, I
think you could replace this test with:
if (cpu >= nr_cpu_ids)
> + cpu = cpumask_first(cpu_online_mask);
> its_dev->event_map.col_map[event] = cpu;
> irq_data_update_effective_affinity(d, cpumask_of(cpu));
>
> @@ -2466,7 +2468,10 @@ static int its_vpe_set_affinity(struct irq_data *d,
> bool force)
> {
> struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
> - int cpu = cpumask_first(mask_val);
> + int cpu = cpumask_first_and(mask_val, cpu_online_mask);
> +
> + if (!cpu_online(cpu))
Same thing here.
> + cpu = cpumask_first(cpu_online_mask);
>
> /*
> * Changing affinity is mega expensive, so let's be as lazy as
>
Cheers,
--
Julien Thierry
^ permalink raw reply
* [PATCH v2] ARM: dts: da850: Fix interrups property for gpio
From: Keerthy @ 2018-06-05 10:07 UTC (permalink / raw)
To: linux-arm-kernel
The intc #interrupt-cells is equal to 1. Currently gpio
node has 2 cells per IRQ which is wrong. Remove the additional
cell for each of the interrupts.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Fixes: 2e38b946dc54 ("ARM: davinci: da850: add GPIO DT node")
---
Changes in v2:
* Fixed $Subject
arch/arm/boot/dts/da850.dtsi | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f6f1597..0f4f817 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -549,11 +549,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x226000 0x1000>;
- interrupts = <42 IRQ_TYPE_EDGE_BOTH
- 43 IRQ_TYPE_EDGE_BOTH 44 IRQ_TYPE_EDGE_BOTH
- 45 IRQ_TYPE_EDGE_BOTH 46 IRQ_TYPE_EDGE_BOTH
- 47 IRQ_TYPE_EDGE_BOTH 48 IRQ_TYPE_EDGE_BOTH
- 49 IRQ_TYPE_EDGE_BOTH 50 IRQ_TYPE_EDGE_BOTH>;
+ interrupts = <42 43 44 45 46 47 48 49 50>;
ti,ngpio = <144>;
ti,davinci-gpio-unbanked = <0>;
status = "disabled";
--
1.9.1
^ permalink raw reply related
* [PATCH] ARM: davinci: da850: Fix interrups property for gpio
From: Keerthy @ 2018-06-05 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528193152-10657-1-git-send-email-j-keerthy@ti.com>
On Tuesday 05 June 2018 03:35 PM, Keerthy wrote:
> The intc #interrupt-cells is equal to 1. Currently gpio
> node has 2 cells per IRQ which is wrong. Remove the additional
> cell for each of the interrupts.
Just noticed $Subject is not quite right. I will fix and send a v2 in a bit.
>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> Fixes: 2e38b946dc54 ("ARM: davinci: da850: add GPIO DT node")
> ---
> arch/arm/boot/dts/da850.dtsi | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index f6f1597..0f4f817 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -549,11 +549,7 @@
> gpio-controller;
> #gpio-cells = <2>;
> reg = <0x226000 0x1000>;
> - interrupts = <42 IRQ_TYPE_EDGE_BOTH
> - 43 IRQ_TYPE_EDGE_BOTH 44 IRQ_TYPE_EDGE_BOTH
> - 45 IRQ_TYPE_EDGE_BOTH 46 IRQ_TYPE_EDGE_BOTH
> - 47 IRQ_TYPE_EDGE_BOTH 48 IRQ_TYPE_EDGE_BOTH
> - 49 IRQ_TYPE_EDGE_BOTH 50 IRQ_TYPE_EDGE_BOTH>;
> + interrupts = <42 43 44 45 46 47 48 49 50>;
> ti,ngpio = <144>;
> ti,davinci-gpio-unbanked = <0>;
> status = "disabled";
>
^ permalink raw reply
* [PATCH] ARM: davinci: da850: Fix interrups property for gpio
From: Keerthy @ 2018-06-05 10:05 UTC (permalink / raw)
To: linux-arm-kernel
The intc #interrupt-cells is equal to 1. Currently gpio
node has 2 cells per IRQ which is wrong. Remove the additional
cell for each of the interrupts.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Fixes: 2e38b946dc54 ("ARM: davinci: da850: add GPIO DT node")
---
arch/arm/boot/dts/da850.dtsi | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f6f1597..0f4f817 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -549,11 +549,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x226000 0x1000>;
- interrupts = <42 IRQ_TYPE_EDGE_BOTH
- 43 IRQ_TYPE_EDGE_BOTH 44 IRQ_TYPE_EDGE_BOTH
- 45 IRQ_TYPE_EDGE_BOTH 46 IRQ_TYPE_EDGE_BOTH
- 47 IRQ_TYPE_EDGE_BOTH 48 IRQ_TYPE_EDGE_BOTH
- 49 IRQ_TYPE_EDGE_BOTH 50 IRQ_TYPE_EDGE_BOTH>;
+ interrupts = <42 43 44 45 46 47 48 49 50>;
ti,ngpio = <144>;
ti,davinci-gpio-unbanked = <0>;
status = "disabled";
--
1.9.1
^ permalink raw reply related
* [PATCH V3] ARM: shmobile: Rework the PMIC IRQ line quirk
From: Marek Vasut @ 2018-06-05 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605092151.57ezynjgf23yunkf@ninjato>
On 06/05/2018 11:21 AM, Wolfram Sang wrote:
> Hi Marek,
>
> On Tue, Jun 05, 2018 at 10:07:28AM +0200, Simon Horman wrote:
>> On Mon, Jun 04, 2018 at 07:59:11PM +0200, Marek Vasut wrote:
>>> Rather than hard-coding the quirk topology, which stopped scaling,
>>> parse the information from DT. The code looks for all compatible
>>> PMICs -- da9036 and da9210 -- and checks if their IRQ line is tied
>>> to the same pin. If so, the code sends a matching sequence to the
>>> PMIC to deassert the IRQ.
>>>
>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>>> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>>> Cc: Simon Horman <horms+renesas@verge.net.au>
>>> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> From an I2C point of view:
>
> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> Minor nits:
>
>>> @@ -122,7 +143,13 @@ static struct notifier_block regulator_quirk_nb = {
>>>
>>> static int __init rcar_gen2_regulator_quirk(void)
>>> {
>>> - u32 mon;
>>> + struct device_node *np;
>>> + const struct of_device_id *id;
>>> + struct regulator_quirk *quirk;
>>> + struct regulator_quirk *pos;
>
> Merge the last two lines into one?
>
>>> + struct of_phandle_args *argsa, *argsb;
>>> + u32 mon, addr;
>>> + int ret;
>>>
>>> if (!of_machine_is_compatible("renesas,koelsch") &&
>>> !of_machine_is_compatible("renesas,lager") &&
>>> @@ -130,6 +157,45 @@ static int __init rcar_gen2_regulator_quirk(void)
>>> !of_machine_is_compatible("renesas,gose"))
>>> return -ENODEV;
>>>
>>> + for_each_matching_node_and_match(np, rcar_gen2_quirk_match, &id) {
>>> + if (!np || !of_device_is_available(np))
>
> Can '!np' actually happen? This is the exit condition of the for-loop,
> or am I overlooking something?
I had to take a look again, no, it's not needed.
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH V3] ARM: shmobile: Rework the PMIC IRQ line quirk
From: Marek Vasut @ 2018-06-05 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605080727.ygh25rmjsrs3dmlq@verge.net.au>
On 06/05/2018 10:07 AM, Simon Horman wrote:
> On Mon, Jun 04, 2018 at 07:59:11PM +0200, Marek Vasut wrote:
>> Rather than hard-coding the quirk topology, which stopped scaling,
>> parse the information from DT. The code looks for all compatible
>> PMICs -- da9036 and da9210 -- and checks if their IRQ line is tied
>> to the same pin. If so, the code sends a matching sequence to the
>> PMIC to deassert the IRQ.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>> Cc: Simon Horman <horms+renesas@verge.net.au>
>> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
>> Cc: linux-renesas-soc at vger.kernel.org
>> ---
>> V2: - Replace the DT shared IRQ check loop with memcmp()
>> - Send the I2C message to deassert the IRQ line to all PMICs
>> in the list with shared IRQ line instead of just one
>> - Add comment that this works only in case all the PMICs are
>> on the same I2C bus
>> V3: - Drop the addr = 0x00 init
>> - Drop reinit of argsa in rcar_gen2_regulator_quirk
>> ---
>> arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 114 ++++++++++++++++-----
>> 1 file changed, 90 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
>> index 93f628acfd94..b919073aa27e 100644
>> --- a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
>> +++ b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
>> @@ -31,8 +31,10 @@
>> #include <linux/i2c.h>
>> #include <linux/init.h>
>> #include <linux/io.h>
>> +#include <linux/list.h>
>> #include <linux/notifier.h>
>> #include <linux/of.h>
>> +#include <linux/of_irq.h>
>> #include <linux/mfd/da9063/registers.h>
>>
>>
>> @@ -44,34 +46,45 @@
>> /* start of DA9210 System Control and Event Registers */
>> #define DA9210_REG_MASK_A 0x54
>>
>> +struct regulator_quirk {
>> + struct list_head list;
>> + const struct of_device_id *id;
>> + struct of_phandle_args irq_args;
>> + struct i2c_msg i2c_msg;
>> + bool shared; /* IRQ line is shared */
>> +};
>> +
>> +static LIST_HEAD(quirk_list);
>> static void __iomem *irqc;
>>
>> /* first byte sets the memory pointer, following are consecutive reg values */
>> static u8 da9063_irq_clr[] = { DA9063_REG_IRQ_MASK_A, 0xff, 0xff, 0xff, 0xff };
>> static u8 da9210_irq_clr[] = { DA9210_REG_MASK_A, 0xff, 0xff };
>>
>> -static struct i2c_msg da9xxx_msgs[3] = {
>> - {
>> - .addr = 0x58,
>> - .len = ARRAY_SIZE(da9063_irq_clr),
>> - .buf = da9063_irq_clr,
>> - }, {
>> - .addr = 0x68,
>> - .len = ARRAY_SIZE(da9210_irq_clr),
>> - .buf = da9210_irq_clr,
>> - }, {
>> - .addr = 0x70,
>> - .len = ARRAY_SIZE(da9210_irq_clr),
>> - .buf = da9210_irq_clr,
>> - },
>> +static struct i2c_msg da9063_msgs = {
>> + .len = ARRAY_SIZE(da9063_irq_clr),
>> + .buf = da9063_irq_clr,
>> +};
>> +
>> +static struct i2c_msg da9210_msgs = {
>> + .len = ARRAY_SIZE(da9210_irq_clr),
>> + .buf = da9210_irq_clr,
>> +};
>> +
>> +static const struct of_device_id rcar_gen2_quirk_match[] = {
>> + { .compatible = "dlg,da9063", .data = &da9063_msgs },
>> + { .compatible = "dlg,da9210", .data = &da9210_msgs },
>> + {},
>> };
>>
>> static int regulator_quirk_notify(struct notifier_block *nb,
>> unsigned long action, void *data)
>> {
>> + struct regulator_quirk *pos, *tmp;
>> struct device *dev = data;
>> struct i2c_client *client;
>> static bool done;
>> + int ret;
>> u32 mon;
>>
>> if (done)
>> @@ -88,17 +101,20 @@ static int regulator_quirk_notify(struct notifier_block *nb,
>> client = to_i2c_client(dev);
>> dev_dbg(dev, "Detected %s\n", client->name);
>>
>> - if ((client->addr == 0x58 && !strcmp(client->name, "da9063")) ||
>> - (client->addr == 0x68 && !strcmp(client->name, "da9210")) ||
>> - (client->addr == 0x70 && !strcmp(client->name, "da9210"))) {
>> - int ret, len;
>> + /*
>> + * Send message to all PMICs that share an IRQ line to deassert it.
>> + *
>> + * WARNING: This works only if all the PMICs are on the same I2C bus.
>> + */
>> + list_for_each_entry(pos, &quirk_list, list) {
>> + if (!pos->shared)
>> + continue;
>>
>> - /* There are two DA9210 on Stout, one on the other boards. */
>> - len = of_machine_is_compatible("renesas,stout") ? 3 : 2;
>> + dev_info(&client->dev, "clearing %s at 0x%02x interrupts\n",
>> + pos->id->compatible, pos->i2c_msg.addr);
>>
>> - dev_info(&client->dev, "clearing da9063/da9210 interrupts\n");
>> - ret = i2c_transfer(client->adapter, da9xxx_msgs, len);
>> - if (ret != len)
>> + ret = i2c_transfer(client->adapter, &pos->i2c_msg, 1);
>> + if (ret != 1)
>> dev_err(&client->dev, "i2c error %d\n", ret);
>> }
>>
>> @@ -111,6 +127,11 @@ static int regulator_quirk_notify(struct notifier_block *nb,
>> remove:
>> dev_info(dev, "IRQ2 is not asserted, removing quirk\n");
>>
>> + list_for_each_entry_safe(pos, tmp, &quirk_list, list) {
>> + list_del(&pos->list);
>> + kfree(pos);
>> + }
>> +
>> done = true;
>> iounmap(irqc);
>> return 0;
>> @@ -122,7 +143,13 @@ static struct notifier_block regulator_quirk_nb = {
>>
>> static int __init rcar_gen2_regulator_quirk(void)
>> {
>> - u32 mon;
>> + struct device_node *np;
>> + const struct of_device_id *id;
>> + struct regulator_quirk *quirk;
>> + struct regulator_quirk *pos;
>> + struct of_phandle_args *argsa, *argsb;
>> + u32 mon, addr;
>> + int ret;
>>
>> if (!of_machine_is_compatible("renesas,koelsch") &&
>> !of_machine_is_compatible("renesas,lager") &&
>> @@ -130,6 +157,45 @@ static int __init rcar_gen2_regulator_quirk(void)
>> !of_machine_is_compatible("renesas,gose"))
>> return -ENODEV;
>>
>> + for_each_matching_node_and_match(np, rcar_gen2_quirk_match, &id) {
>> + if (!np || !of_device_is_available(np))
>> + break;
>> +
>> + quirk = kzalloc(sizeof(*quirk), GFP_KERNEL);
>> +
>> + argsa = &quirk->irq_args;
>> + memcpy(&quirk->i2c_msg, id->data, sizeof(quirk->i2c_msg));
>> +
>> + ret = of_property_read_u32(np, "reg", &addr);
>> + if (ret)
>> + return ret;
>> +
>> + quirk->id = id;
>> + quirk->i2c_msg.addr = addr;
>> + quirk->shared = false;
>> +
>> + ret = of_irq_parse_one(np, 0, &quirk->irq_args);
>
> As per my comment on v2,
> &quirk->irq_args is assigned to argsa above and used directly here.
>
Hum, OK
--
Best regards,
Marek Vasut
^ 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