* [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Bin Liu @ 2017-01-11 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <418251484165614@web21h.yandex.ru>
On Thu, Jan 12, 2017 at 04:13:34AM +0800, Icenowy Zheng wrote:
>
>
> 12.01.2017, 04:08, "Bin Liu" <b-liu@ti.com>:
> > On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
> >> ?11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
> >> ?> On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> >> ?>> ?Lichee Pi Zero features a USB OTG port.
> >> ?>>
> >> ?>> ?Add support for it.
> >> ?>>
> >> ?>> ?Note: in order to use the Host mode, the board must be powered via the
> >> ?>> ?+5V and GND pins.
> >> ?>>
> >> ?>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >> ?>> ?---
> >> ?>> ??arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
> >> ?>> ??1 file changed, 10 insertions(+)
> >> ?>>
> >> ?>> ?diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> ?>> ?index 0099affc6ce3..3d9168cbaeca 100644
> >> ?>> ?--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> ?>> ?+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> ?>> ?@@ -71,3 +71,13 @@
> >> ?>> ??????????pinctrl-names = "default";
> >> ?>> ??????????status = "okay";
> >> ?>> ??};
> >> ?>> ?+
> >> ?>> ?+&usb_otg {
> >> ?>> ?+ dr_mode = "otg";
> >> ?>
> >> ?> Why not set this default mode in dtsi instead?
> >> ?>
> >> ?> Regards,
> >> ?> -Bin.
> >>
> >> ?There's possibly boards which do not have OTG functions.
> >
> > That is board specific.
> >
> > You'd better to define the default dr_mode which the musb _controller_
> > supports in the dtsi, and then override it in a specific board dts if
> > necessary.
>
> Is there MUSB controllers which do not support a certain mode?
I am not aware of any. That is why I recommended to set "otg" in dtsi,
then override it in board dts if a port is specically designed to
host-only or device-only mode.
>
> (I remembered my omap3-n900 which do not work under OTG mode...)
I belive it is n900 board specific. omap3 itself doesn't have such
limitation, AFAIK.
Regards,
-Bin.
>
> >
> > Regards,
> > -Bin.
> >
> >> ?Even the official CDR design of V3s uses the USB controller to
> >> ?connect a UVC webcam to make the design a dual-cam design
> >> ?(V3s itself has a CSI).
> >>
> >> ?>
> >> ?>> ?+ status = "okay";
> >> ?>> ?+};
> >> ?>> ?+
> >> ?>> ?+&usbphy {
> >> ?>> ?+ usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> >> ?>> ?+ status = "okay";
> >> ?>> ?+};
> >> ?>> ?--
> >> ?>> ?2.11.0
^ permalink raw reply
* [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Icenowy Zheng @ 2017-01-11 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111200811.GA16865@uda0271908>
12.01.2017, 04:08, "Bin Liu" <b-liu@ti.com>:
> On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
>> ?11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
>> ?> On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
>> ?>> ?Lichee Pi Zero features a USB OTG port.
>> ?>>
>> ?>> ?Add support for it.
>> ?>>
>> ?>> ?Note: in order to use the Host mode, the board must be powered via the
>> ?>> ?+5V and GND pins.
>> ?>>
>> ?>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ?>> ?---
>> ?>> ??arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
>> ?>> ??1 file changed, 10 insertions(+)
>> ?>>
>> ?>> ?diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> ?>> ?index 0099affc6ce3..3d9168cbaeca 100644
>> ?>> ?--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> ?>> ?+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> ?>> ?@@ -71,3 +71,13 @@
>> ?>> ??????????pinctrl-names = "default";
>> ?>> ??????????status = "okay";
>> ?>> ??};
>> ?>> ?+
>> ?>> ?+&usb_otg {
>> ?>> ?+ dr_mode = "otg";
>> ?>
>> ?> Why not set this default mode in dtsi instead?
>> ?>
>> ?> Regards,
>> ?> -Bin.
>>
>> ?There's possibly boards which do not have OTG functions.
>
> That is board specific.
>
> You'd better to define the default dr_mode which the musb _controller_
> supports in the dtsi, and then override it in a specific board dts if
> necessary.
Is there MUSB controllers which do not support a certain mode?
(I remembered my omap3-n900 which do not work under OTG mode...)
>
> Regards,
> -Bin.
>
>> ?Even the official CDR design of V3s uses the USB controller to
>> ?connect a UVC webcam to make the design a dual-cam design
>> ?(V3s itself has a CSI).
>>
>> ?>
>> ?>> ?+ status = "okay";
>> ?>> ?+};
>> ?>> ?+
>> ?>> ?+&usbphy {
>> ?>> ?+ usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
>> ?>> ?+ status = "okay";
>> ?>> ?+};
>> ?>> ?--
>> ?>> ?2.11.0
^ permalink raw reply
* [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Bin Liu @ 2017-01-11 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2733831484164533@web1g.yandex.ru>
On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
>
>
> 11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
> > On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> >> ?Lichee Pi Zero features a USB OTG port.
> >>
> >> ?Add support for it.
> >>
> >> ?Note: in order to use the Host mode, the board must be powered via the
> >> ?+5V and GND pins.
> >>
> >> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >> ?---
> >> ??arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
> >> ??1 file changed, 10 insertions(+)
> >>
> >> ?diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> ?index 0099affc6ce3..3d9168cbaeca 100644
> >> ?--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> ?+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> ?@@ -71,3 +71,13 @@
> >> ??????????pinctrl-names = "default";
> >> ??????????status = "okay";
> >> ??};
> >> ?+
> >> ?+&usb_otg {
> >> ?+ dr_mode = "otg";
> >
> > Why not set this default mode in dtsi instead?
> >
> > Regards,
> > -Bin.
>
> There's possibly boards which do not have OTG functions.
That is board specific.
You'd better to define the default dr_mode which the musb _controller_
supports in the dtsi, and then override it in a specific board dts if
necessary.
Regards,
-Bin.
>
> Even the official CDR design of V3s uses the USB controller to
> connect a UVC webcam to make the design a dual-cam design
> (V3s itself has a CSI).
>
> >
> >> ?+ status = "okay";
> >> ?+};
> >> ?+
> >> ?+&usbphy {
> >> ?+ usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> >> ?+ status = "okay";
> >> ?+};
> >> ?--
> >> ?2.11.0
^ permalink raw reply
* [GIT PULL 2/2] SoCFPGA DTS updates for v4.11, part 1
From: Dinh Nguyen @ 2017-01-11 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484165237-26640-1-git-send-email-dinguyen@kernel.org>
Hi Arnd, Kevin, and Olof:
Please pull in these DTS updates for v4.11.
Thanks,
Dinh
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_dts_for_v4.11_part_1
for you to fetch changes up to 7f0f5460d46867a8f980683136a054cff1357780:
ARM: dts: socfpga: add missing compatible string for SDRAM controller (2017-01-06 01:42:06 -0600)
----------------------------------------------------------------
SoCFPGA DTS updates for v4.11, part 1
- Adds FPGA manager bits
- Enable I2C on Cyclone5 and Arria5 devkits
- Adds LED support on C5/A5 devkits
- Enables CAN on C5 devkit
- Enables watchdog
- Add NAND on Arria10
- Add the LTC2977 Power Monitor on Arria10 devkit
----------------------------------------------------------------
Alan Tull (1):
ARM: dts: socfpga: add base fpga region and fpga bridges
Dinh Nguyen (10):
ARM: dts: socfpga: enable GPIO and LEDs for Cyclone5 and Arria5 devkits
ARM: dts: socfpga: set desired i2c clock on Cyclone5 and Arria5 devkits
ARM: dts: socfpga: Add Rohm DH2228FV DAC
ARM: dts: socfpga: enable CAN on Cyclone5 devkit
ARM: dts: socfpga: enable watchdog timer on Arria5 and Arria10
ARM: dts: socfpga: add the LTC2977 power monitor on Arria10 devkit
ARM: dts: socfpga: add fpga-manager node for Arria10
ARM: dts: socfpga: fpga manager data is 32 bits
ARM: dts: socfpga: add fpga region support on Arria10
ARM: dts: socfpga: add missing compatible string for SDRAM controller
Graham Moore (1):
ARM: dts: socfpga: Add NAND device tree for Arria10
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/socfpga.dtsi | 31 +++++++++++++-
arch/arm/boot/dts/socfpga_arria10.dtsi | 32 +++++++++++++-
arch/arm/boot/dts/socfpga_arria10_socdk.dtsi | 9 ++++
arch/arm/boot/dts/socfpga_arria10_socdk_nand.dts | 31 ++++++++++++++
arch/arm/boot/dts/socfpga_arria5.dtsi | 4 ++
arch/arm/boot/dts/socfpga_arria5_socdk.dts | 43 +++++++++++++++++++
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 53 ++++++++++++++++++++++++
8 files changed, 201 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/boot/dts/socfpga_arria10_socdk_nand.dts
^ permalink raw reply
* [GIT PULL 1/2] SoCFPGA defconfig updates for v4.11
From: Dinh Nguyen @ 2017-01-11 20:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, and Olof:
Please pull in this defconfig update for v4.11.
Thanks,
Dinh
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_defconfig_updates_for_v4.11
for you to fetch changes up to 4fdf18242408cc0b32b3a1a06510376bf609fa60:
ARM: socfpga_defconfig: update defconfig for SoCFPGA (2017-01-03 20:29:08 -0600)
----------------------------------------------------------------
SoCFPGA defconfig updates for v4.11
- enables Marvell PHY support
- enable MTD(I2C EEPROM), and NAND support
- enable SPI, RTC and LED support
- enables OF CONFIGFS to support DTS overlays
- enables more FS options
- enables A10 hwmon support
----------------------------------------------------------------
Dinh Nguyen (1):
ARM: socfpga_defconfig: update defconfig for SoCFPGA
arch/arm/configs/socfpga_defconfig | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Icenowy Zheng @ 2017-01-11 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110202443.GC2479@uda0271908>
11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
> On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
>> ?Lichee Pi Zero features a USB OTG port.
>>
>> ?Add support for it.
>>
>> ?Note: in order to use the Host mode, the board must be powered via the
>> ?+5V and GND pins.
>>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ?---
>> ??arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
>> ??1 file changed, 10 insertions(+)
>>
>> ?diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> ?index 0099affc6ce3..3d9168cbaeca 100644
>> ?--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> ?+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> ?@@ -71,3 +71,13 @@
>> ??????????pinctrl-names = "default";
>> ??????????status = "okay";
>> ??};
>> ?+
>> ?+&usb_otg {
>> ?+ dr_mode = "otg";
>
> Why not set this default mode in dtsi instead?
>
> Regards,
> -Bin.
There's possibly boards which do not have OTG functions.
Even the official CDR design of V3s uses the USB controller to
connect a UVC webcam to make the design a dual-cam design
(V3s itself has a CSI).
>
>> ?+ status = "okay";
>> ?+};
>> ?+
>> ?+&usbphy {
>> ?+ usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
>> ?+ status = "okay";
>> ?+};
>> ?--
>> ?2.11.0
^ permalink raw reply
* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: Uwe Kleine-König @ 2017-01-11 19:49 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
on an Marvell Armada 385 based machine (Turris Omnia) with 4.9 the
ath10k driver fails to bind to the matching hardware if CONFIG_PCIEASPM
is enabled:
# dmesg | grep ath
[ 7.207770] ath10k_pci 0000:02:00.0: Refused to change power state, currently in D3
[ 7.237955] ath10k_pci 0000:02:00.0: failed to wake up device : -110
[ 7.238146] ath10k_pci: probe of 0000:02:00.0 failed with error -110
if however PCIEASPM is off, the driver probes correctly and the ath10k
adapter works fine.
I wonder if someone has an idea what needs to be done to fix this
problem. (OK, I could disable PCIEASPM, but I'd like to have a solution
for a distribution kernel where I think PCIEASPM=y is sensible in
general.)
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170111/91e57d62/attachment.sig>
^ permalink raw reply
* [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Icenowy Zheng @ 2017-01-11 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2705031484163593@web1g.yandex.ru>
12.01.2017, 03:40, "Icenowy Zheng" <icenowy@aosc.xyz>:
> 11.01.2017, 02:10, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>> ?On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
>>> ??V3s has a similar but cut-down CCU to H3.
>>>
>>> ??Add support for it.
>>>
>>> ??Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>
>> ?It looks like there's nothing different but the clocks that you
>> ?register with the H3, please just use the H3 driver.
>
> Nope.
>
> It has a different PLL (PLL_ISP) at different address, and some
> different muxes.
Forgot to mention the missing of PLL_DE and related misses.
>
>> ?Thanks!
>> ?Maxime
>>
>> ?--
>> ?Maxime Ripard, Free Electrons
>> ?Embedded Linux and Kernel engineering
>> ?http://free-electrons.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/5] arm: sunxi: add support for V3s SoC
From: Icenowy Zheng @ 2017-01-11 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110180926.ilqtygttpfgbetvu@lukather>
11.01.2017, 02:09, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Tue, Jan 03, 2017 at 11:16:25PM +0800, Icenowy Zheng wrote:
>> ?Allwinner V3s is a low-end single-core Cortex-A7 SoC, with 64MB
>> ?integrated DRAM, and several peripherals.
>>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ?---
>> ??Documentation/arm/sunxi/README | 4 ++++
>> ??arch/arm/mach-sunxi/sunxi.c | 1 +
>> ??2 files changed, 5 insertions(+)
>>
>> ?diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
>> ?index cd0243302bc1..91ec8f2055be 100644
>> ?--- a/Documentation/arm/sunxi/README
>> ?+++ b/Documentation/arm/sunxi/README
>> ?@@ -67,6 +67,10 @@ SunXi family
>> ??????????+ Datasheet
>> ????????????http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
>>
>> ?+ - Allwinner V3s (sun8i)
>> ?+ + Datasheet
>> ?+ https://www.goprawn.com/forum/allwinner-cams/783-allwinner-v3s-soc-datasheet
>> ?+
>
> Please don't put random links in there, but at least something that we
> know will be there in a couple of weeks/monthes/years
Is http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf acceptable?
>
> Thanks,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Icenowy Zheng @ 2017-01-11 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110181006.yrd6moy2mctzoc4c@lukather>
11.01.2017, 02:10, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
>> ?V3s has a similar but cut-down CCU to H3.
>>
>> ?Add support for it.
>>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>
> It looks like there's nothing different but the clocks that you
> register with the H3, please just use the H3 driver.
Nope.
It has a different PLL (PLL_ISP) at different address, and some
different muxes.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH v2] PCI: thunder-pem: Add support for cn81xx and cn83xx SoCs.
From: David Daney @ 2017-01-11 19:22 UTC (permalink / raw)
To: linux-arm-kernel
From: David Daney <david.daney@cavium.com>
The pci-thunder-pem driver was initially developed for cn88xx SoCs.
The cn81xx and cn83xx members of the same family of SoCs has a
slightly different configuration of interrupt resources in the PEM
hardware, which prevents the INTA legacy interrupt source from
functioning with the current driver.
There are two fixes required:
1) Don't fixup the PME interrupt on the newer SoCs as it already has
the proper value.
2) Report MSI-X Capability Table Size of 2 for the newer SoCs, so the
core MSI-X code doesn't inadvertently clobber the INTA machinery that
happens to reside immediately following the table.
Signed-off-by: David Daney <david.daney@cavium.com>
---
Changes from v1: Fixed comment typo.
drivers/pci/host/pci-thunder-pem.c | 25 ++++++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
index af722eb..52b5bdc 100644
--- a/drivers/pci/host/pci-thunder-pem.c
+++ b/drivers/pci/host/pci-thunder-pem.c
@@ -36,7 +36,7 @@ struct thunder_pem_pci {
static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 *val)
{
- u64 read_val;
+ u64 read_val, tmp_val;
struct pci_config_window *cfg = bus->sysdata;
struct thunder_pem_pci *pem_pci = (struct thunder_pem_pci *)cfg->priv;
@@ -65,13 +65,28 @@ static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
read_val |= 0x00007000; /* Skip MSI CAP */
break;
case 0x70: /* Express Cap */
- /* PME interrupt on vector 2*/
- read_val |= (2u << 25);
+ /*
+ * Change PME interrupt to vector 2 on T88 where it
+ * reads as 0, else leave it alone.
+ */
+ if (!(read_val & (0x1f << 25)))
+ read_val |= (2u << 25);
break;
case 0xb0: /* MSI-X Cap */
- /* TableSize=4, Next Cap is EA */
+ /* TableSize=2 or 4, Next Cap is EA */
read_val &= 0xc00000ff;
- read_val |= 0x0003bc00;
+ /*
+ * If Express Cap(0x70) raw PME vector reads as 0 we are on
+ * T88 and TableSize is reported as 4, else TableSize
+ * is 2.
+ */
+ writeq(0x70, pem_pci->pem_reg_base + PEM_CFG_RD);
+ tmp_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
+ tmp_val >>= 32;
+ if (!(tmp_val & (0x1f << 25)))
+ read_val |= 0x0003bc00;
+ else
+ read_val |= 0x0001bc00;
break;
case 0xb4:
/* Table offset=0, BIR=0 */
--
2.9.3
^ permalink raw reply related
* [PATCH] PCI: thunder-pem: Add support for cn81xx and cn83xx SoCs.
From: David Daney @ 2017-01-11 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111191141.28747-1-ddaney.cavm@gmail.com>
On 01/11/2017 11:11 AM, David Daney wrote:
> From: David Daney <david.daney@cavium.com>
>
> The pci-thunder-pem driver was initially developed for cn88xx SoCs.
> The cn81xx and cn83xx members of the same family of SoCs has a
> slightly different configuration of interrupt resources in the PEM
> hardware, which prevents the INTA legacy interrupt source from
> functioning with the current driver.
>
> There are two fixes required:
>
> 1) Don't fixup the PME interrupt on the newer SoCs as it already has
> the proper value.
>
> 2) Report MSI-X Capability Table Size of 2 for the newer SoCs, so the
> core MSI-X code doesn't inadvertently clobber the INTA machinery that
> happens to reside immediately following the table.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
> ---
> drivers/pci/host/pci-thunder-pem.c | 25 ++++++++++++++++++++-----
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
> index af722eb..eea466f 100644
> --- a/drivers/pci/host/pci-thunder-pem.c
> +++ b/drivers/pci/host/pci-thunder-pem.c
> @@ -36,7 +36,7 @@ struct thunder_pem_pci {
> static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
> int where, int size, u32 *val)
> {
> - u64 read_val;
> + u64 read_val, tmp_val;
> struct pci_config_window *cfg = bus->sysdata;
> struct thunder_pem_pci *pem_pci = (struct thunder_pem_pci *)cfg->priv;
>
> @@ -65,13 +65,28 @@ static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
> read_val |= 0x00007000; /* Skip MSI CAP */
> break;
> case 0x70: /* Express Cap */
> - /* PME interrupt on vector 2*/
> - read_val |= (2u << 25);
> + /*
> + * Change PME interrupt to vector 2 on T88 where it
> + * reads as 0, else leave it alone.
> + */
> + if (!(read_val & (0x1f << 25)))
> + read_val |= (2u << 25);
> break;
> case 0xb0: /* MSI-X Cap */
> - /* TableSize=4, Next Cap is EA */
> + /* TableSize=2 or 4, Next Cap is EA */
> read_val &= 0xc00000ff;
> - read_val |= 0x0003bc00;
> + /*
> + * If Express Cap(0x70) raw PME vector reads as 2 we are on
Crap! The comment is incorrect s/2/0/, I guess I will send a corrected
patch. The code is correct though.
> + * T88 and TableSize is reported as 4, else TableSize
> + * is 2.
> + */
> + writeq(0x70, pem_pci->pem_reg_base + PEM_CFG_RD);
> + tmp_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
> + tmp_val >>= 32;
> + if (!(tmp_val & (0x1f << 25)))
> + read_val |= 0x0003bc00;
> + else
> + read_val |= 0x0001bc00;
> break;
> case 0xb4:
> /* Table offset=0, BIR=0 */
>
^ permalink raw reply
* [PATCH] PCI/MSI: pci-xgene-msi: Fix CPU hotplug registration handling
From: Duc Dang @ 2017-01-11 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484130407-24707-1-git-send-email-marc.zyngier@arm.com>
On Wed, Jan 11, 2017 at 2:26 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> The conversion to the new hotplug state machine introduced a regression
> where a successful hotplug registration would be treated as an error,
> effectively disabling the MSI driver forever.
>
> Fix it by doing the proper check on the return value.
Thanks, Marc.
Tested-by: Duc Dang <dhdang@apm.com>
>
> Fixes: 9c248f8896e6 ("PCI/xgene-msi: Convert to hotplug state machine")
> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Cc: Duc Dang <dhdang@apm.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: stable at vger.kernel.org
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> drivers/pci/host/pci-xgene-msi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
> index 1f38d08..f1b633b 100644
> --- a/drivers/pci/host/pci-xgene-msi.c
> +++ b/drivers/pci/host/pci-xgene-msi.c
> @@ -517,7 +517,7 @@ static int xgene_msi_probe(struct platform_device *pdev)
>
> rc = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "pci/xgene:online",
> xgene_msi_hwirq_alloc, NULL);
> - if (rc)
> + if (rc < 0)
> goto err_cpuhp;
> pci_xgene_online = rc;
> rc = cpuhp_setup_state(CPUHP_PCI_XGENE_DEAD, "pci/xgene:dead", NULL,
> --
> 2.1.4
>
Regards,
Duc Dang.
^ permalink raw reply
* [PATCH] PCI: thunder-pem: Add support for cn81xx and cn83xx SoCs.
From: David Daney @ 2017-01-11 19:11 UTC (permalink / raw)
To: linux-arm-kernel
From: David Daney <david.daney@cavium.com>
The pci-thunder-pem driver was initially developed for cn88xx SoCs.
The cn81xx and cn83xx members of the same family of SoCs has a
slightly different configuration of interrupt resources in the PEM
hardware, which prevents the INTA legacy interrupt source from
functioning with the current driver.
There are two fixes required:
1) Don't fixup the PME interrupt on the newer SoCs as it already has
the proper value.
2) Report MSI-X Capability Table Size of 2 for the newer SoCs, so the
core MSI-X code doesn't inadvertently clobber the INTA machinery that
happens to reside immediately following the table.
Signed-off-by: David Daney <david.daney@cavium.com>
---
drivers/pci/host/pci-thunder-pem.c | 25 ++++++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
index af722eb..eea466f 100644
--- a/drivers/pci/host/pci-thunder-pem.c
+++ b/drivers/pci/host/pci-thunder-pem.c
@@ -36,7 +36,7 @@ struct thunder_pem_pci {
static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 *val)
{
- u64 read_val;
+ u64 read_val, tmp_val;
struct pci_config_window *cfg = bus->sysdata;
struct thunder_pem_pci *pem_pci = (struct thunder_pem_pci *)cfg->priv;
@@ -65,13 +65,28 @@ static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
read_val |= 0x00007000; /* Skip MSI CAP */
break;
case 0x70: /* Express Cap */
- /* PME interrupt on vector 2*/
- read_val |= (2u << 25);
+ /*
+ * Change PME interrupt to vector 2 on T88 where it
+ * reads as 0, else leave it alone.
+ */
+ if (!(read_val & (0x1f << 25)))
+ read_val |= (2u << 25);
break;
case 0xb0: /* MSI-X Cap */
- /* TableSize=4, Next Cap is EA */
+ /* TableSize=2 or 4, Next Cap is EA */
read_val &= 0xc00000ff;
- read_val |= 0x0003bc00;
+ /*
+ * If Express Cap(0x70) raw PME vector reads as 2 we are on
+ * T88 and TableSize is reported as 4, else TableSize
+ * is 2.
+ */
+ writeq(0x70, pem_pci->pem_reg_base + PEM_CFG_RD);
+ tmp_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
+ tmp_val >>= 32;
+ if (!(tmp_val & (0x1f << 25)))
+ read_val |= 0x0003bc00;
+ else
+ read_val |= 0x0001bc00;
break;
case 0xb4:
/* Table offset=0, BIR=0 */
--
2.9.3
^ permalink raw reply related
* kvm: deadlock in kvm_vgic_map_resources
From: Dmitry Vyukov @ 2017-01-11 19:01 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
While running syzkaller fuzzer I've got the following deadlock.
On commit 9c763584b7c8911106bb77af7e648bef09af9d80.
=============================================
[ INFO: possible recursive locking detected ]
4.9.0-rc6-xc2-00056-g08372dd4b91d-dirty #50 Not tainted
---------------------------------------------
syz-executor/20805 is trying to acquire lock:
(
&kvm->lock
){+.+.+.}
, at:
[< inline >] kvm_vgic_dist_destroy
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:271
[<ffff2000080ea4bc>] kvm_vgic_destroy+0x34/0x250
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:294
but task is already holding lock:
(&kvm->lock){+.+.+.}, at:
[<ffff2000080ea7e4>] kvm_vgic_map_resources+0x2c/0x108
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:343
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&kvm->lock);
lock(&kvm->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by syz-executor/20805:
#0:(&vcpu->mutex){+.+.+.}, at:
[<ffff2000080bcc30>] vcpu_load+0x28/0x1d0
arch/arm64/kvm/../../../virt/kvm/kvm_main.c:143
#1:(&kvm->lock){+.+.+.}, at:
[<ffff2000080ea7e4>] kvm_vgic_map_resources+0x2c/0x108
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:343
stack backtrace:
CPU: 2 PID: 20805 Comm: syz-executor Not tainted
4.9.0-rc6-xc2-00056-g08372dd4b91d-dirty #50
Hardware name: Hardkernel ODROID-C2 (DT)
Call trace:
[<ffff200008090560>] dump_backtrace+0x0/0x3c8 arch/arm64/kernel/traps.c:69
[<ffff200008090948>] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:219
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffff200008895840>] dump_stack+0x100/0x150 lib/dump_stack.c:51
[< inline >] print_deadlock_bug kernel/locking/lockdep.c:1728
[< inline >] check_deadlock kernel/locking/lockdep.c:1772
[< inline >] validate_chain kernel/locking/lockdep.c:2250
[<ffff2000081c8718>] __lock_acquire+0x1938/0x3440 kernel/locking/lockdep.c:3335
[<ffff2000081caa84>] lock_acquire+0xdc/0x1d8 kernel/locking/lockdep.c:3746
[< inline >] __mutex_lock_common kernel/locking/mutex.c:521
[<ffff200009700004>] mutex_lock_nested+0xdc/0x7b8 kernel/locking/mutex.c:621
[< inline >] kvm_vgic_dist_destroy
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:271
[<ffff2000080ea4bc>] kvm_vgic_destroy+0x34/0x250
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:294
[<ffff2000080ec290>] vgic_v2_map_resources+0x218/0x430
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c:295
[<ffff2000080ea884>] kvm_vgic_map_resources+0xcc/0x108
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:348
[< inline >] kvm_vcpu_first_run_init
arch/arm64/kvm/../../../arch/arm/kvm/arm.c:505
[<ffff2000080d2768>] kvm_arch_vcpu_ioctl_run+0xab8/0xce0
arch/arm64/kvm/../../../arch/arm/kvm/arm.c:591
[<ffff2000080c1fec>] kvm_vcpu_ioctl+0x434/0xc08
arch/arm64/kvm/../../../virt/kvm/kvm_main.c:2557
[< inline >] vfs_ioctl fs/ioctl.c:43
[<ffff200008450c38>] do_vfs_ioctl+0x128/0xfc0 fs/ioctl.c:679
[< inline >] SYSC_ioctl fs/ioctl.c:694
[<ffff200008451b78>] SyS_ioctl+0xa8/0xb8 fs/ioctl.c:685
[<ffff200008083ef0>] el0_svc_naked+0x24/0x28 arch/arm64/kernel/entry.S:755
INFO: task syz-executor:20805 blocked for more than 120 seconds.
Not tainted 4.9.0-rc6-xc2-00056-g08372dd4b91d-dirty #50
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor D 0 20805 1 0x00000001
Call trace:
[<ffff2000080894f4>] __switch_to+0x184/0x258 arch/arm64/kernel/process.c:345
[< inline >] context_switch kernel/sched/core.c:2899
[<ffff2000096fcc64>] __schedule+0x42c/0x1298 kernel/sched/core.c:3402
[<ffff2000096fdb98>] schedule+0xc8/0x260 kernel/sched/core.c:3457
[<ffff2000096fe654>] schedule_preempt_disabled+0x74/0x110
kernel/sched/core.c:3490
[< inline >] __mutex_lock_common kernel/locking/mutex.c:582
[<ffff200009700240>] mutex_lock_nested+0x318/0x7b8 kernel/locking/mutex.c:621
[< inline >] kvm_vgic_dist_destroy
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:271
[<ffff2000080ea4bc>] kvm_vgic_destroy+0x34/0x250
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:294
[<ffff2000080ec290>] vgic_v2_map_resources+0x218/0x430
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c:295
[<ffff2000080ea884>] kvm_vgic_map_resources+0xcc/0x108
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:348
[< inline >] kvm_vcpu_first_run_init
arch/arm64/kvm/../../../arch/arm/kvm/arm.c:505
[<ffff2000080d2768>] kvm_arch_vcpu_ioctl_run+0xab8/0xce0
arch/arm64/kvm/../../../arch/arm/kvm/arm.c:591
[<ffff2000080c1fec>] kvm_vcpu_ioctl+0x434/0xc08
arch/arm64/kvm/../../../virt/kvm/kvm_main.c:2557
[< inline >] vfs_ioctl fs/ioctl.c:43
[<ffff200008450c38>] do_vfs_ioctl+0x128/0xfc0 fs/ioctl.c:679
[< inline >] SYSC_ioctl fs/ioctl.c:694
[<ffff200008451b78>] SyS_ioctl+0xa8/0xb8 fs/ioctl.c:685
[<ffff200008083ef0>] el0_svc_naked+0x24/0x28 arch/arm64/kernel/entry.S:755
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Marc Zyngier @ 2017-01-11 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2069d58c-0b81-dad4-511f-05e7d002eb34@codeaurora.org>
[finally, some proper bikeshedding]
On 11/01/17 18:40, Timur Tabi wrote:
> On 01/11/2017 12:37 PM, Mark Rutland wrote:
>> The name, as it is, is perfectly descriptive.
>>
>> Let's not sacrifice legibility over a non-issue.
>
> I don't want to kick a dead horse or anything, but changing it to
> QCOM_FLKR_ERRATUM_1003 would eliminate all the spacing problems without
> sacrificing anything.
Other than not being able to grep for the core name in the source tree,
how do you suggest we pronounce FLKR? Because so far, it rolls off the
tongue in an interesting way...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Mark Rutland @ 2017-01-11 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2069d58c-0b81-dad4-511f-05e7d002eb34@codeaurora.org>
On Wed, Jan 11, 2017 at 12:40:42PM -0600, Timur Tabi wrote:
> On 01/11/2017 12:37 PM, Mark Rutland wrote:
> >The name, as it is, is perfectly descriptive.
> >
> >Let's not sacrifice legibility over a non-issue.
>
> I don't want to kick a dead horse or anything, but changing it to
> QCOM_FLKR_ERRATUM_1003 would eliminate all the spacing problems
> without sacrificing anything.
The CPU is called "Falkor", not "FLKR", and we're not coming up with an
ACPI table name...
The ARM Ltd. erratum numbers are global to all parts, so we don't
include the part name. Is the 1003 erratum number specific to Falkor?
If it's global, you could use QCOM_ERRATUM_1003 instead.
Otherwise, QCOM_FALKOR_ERRATUM_1003 is preferable.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 33/62] watchdog: meson_wdt: Convert to use device managed functions and other improvements
From: Kevin Hilman @ 2017-01-11 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484095516-12720-3-git-send-email-linux@roeck-us.net>
Guenter Roeck <linux@roeck-us.net> writes:
> Use device managed functions to simplify error handling, reduce
> source code size, improve readability, and reduce the likelyhood of bugs.
> Other improvements as listed below.
>
> The conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts used
> to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Drop assignments to otherwise unused variables
> - Drop remove function
> - Drop platform_set_drvdata()
> - Use devm_watchdog_register_driver() to register watchdog device
> - Replace shutdown function with call to watchdog_stop_on_reboot()
>
> Cc: Carlo Caione <carlo@caione.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [PATCH 32/62] watchdog: meson_gxbb_wdt: Convert to use device managed functions and other improvements
From: Kevin Hilman @ 2017-01-11 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484095516-12720-2-git-send-email-linux@roeck-us.net>
Guenter Roeck <linux@roeck-us.net> writes:
> Use device managed functions to simplify error handling, reduce
> source code size, improve readability, and reduce the likelyhood of bugs.
> Other improvements as listed below.
>
> The conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts used
> to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Use devm_add_action_or_reset() for calls to clk_disable_unprepare
> - Check return value from clk_prepare_enable()
> - Replace 'val = e; return val;' with 'return e;'
> - Replace 'if (e) return e; return 0;' with 'return e;'
> - Drop assignments to otherwise unused variables
> - Replace 'if (e) { return expr; }' with 'if (e) return expr;'
> - Drop remove function
> - Use devm_watchdog_register_driver() to register watchdog device
> - Replace shutdown function with call to watchdog_stop_on_reboot()
>
> Cc: Carlo Caione <carlo@caione.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Nice, thanks for the cleanup!
Acked-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Mark Rutland @ 2017-01-11 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <278a45c0-bd49-b8a2-63ae-80ad851bab9b@arm.com>
On Wed, Jan 11, 2017 at 06:22:08PM +0000, Marc Zyngier wrote:
> On 11/01/17 18:06, Catalin Marinas wrote:
> > On Wed, Jan 11, 2017 at 09:41:15AM -0500, Christopher Covington wrote:
> >> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> >> index 32682be..9ee46df 100644
> >> --- a/arch/arm64/mm/proc.S
> >> +++ b/arch/arm64/mm/proc.S
> >> @@ -23,6 +23,7 @@
> >> #include <asm/assembler.h>
> >> #include <asm/asm-offsets.h>
> >> #include <asm/hwcap.h>
> >> +#include <asm/mmu_context.h>
> >> #include <asm/pgtable.h>
> >> #include <asm/pgtable-hwdef.h>
> >> #include <asm/cpufeature.h>
> >> @@ -140,6 +141,18 @@ ENDPROC(cpu_do_resume)
> >> ENTRY(cpu_do_switch_mm)
> >> mmid x1, x1 // get mm->context.id
> >> bfi x0, x1, #48, #16 // set the ASID
> >> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
> >> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003
> >> + mrs x2, ttbr0_el1
> >> + mov x3, #FALKOR_RESERVED_ASID
> >> + bfi x2, x3, #48, #16 // reserved ASID + old BADDR
> >> + msr ttbr0_el1, x2
> >> + isb
> >> + bfi x2, x0, #0, #48 // reserved ASID + new BADDR
> >> + msr ttbr0_el1, x2
> >> + isb
> >> +alternative_else_nop_endif
> >> +#endif
> >> msr ttbr0_el1, x0 // set TTBR0
> >> isb
> >> post_ttbr0_update_workaround
> >
> > Please move the above hunk to a pre_ttbr0_update_workaround macro for
> > consistency with post_ttbr0_update_workaround.
>
> In which case (and also for consistency), should we add that pre_ttbr0
> macro to entry.S, just before __uaccess_ttbr0_enable? It may not be
> needed in the SW pan case, but it is probably worth entertaining the
> idea that there may be something to do there...
Likewise, I beleive we may need to modify cpu_set_reserved_ttbr0().
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Timur Tabi @ 2017-01-11 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111183738.GD29247@leverpostej>
On 01/11/2017 12:37 PM, Mark Rutland wrote:
> The name, as it is, is perfectly descriptive.
>
> Let's not sacrifice legibility over a non-issue.
I don't want to kick a dead horse or anything, but changing it to
QCOM_FLKR_ERRATUM_1003 would eliminate all the spacing problems without
sacrificing anything.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Mark Rutland @ 2017-01-11 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5da456f8-fcc5-b6e2-d58b-01a671da595b@codeaurora.org>
On Wed, Jan 11, 2017 at 12:35:55PM -0600, Timur Tabi wrote:
> On 01/11/2017 12:33 PM, Mark Rutland wrote:
> >It'll need to affect all lines since the kconfig column needs to expand
> >by at least one character to fit QCOM_FALKOR_ERRATUM_1003.
>
> Or we can make the macro shorter.
The name, as it is, is perfectly descriptive.
Let's not sacrifice legibility over a non-issue.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Timur Tabi @ 2017-01-11 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111183339.GC29247@leverpostej>
On 01/11/2017 12:33 PM, Mark Rutland wrote:
> It'll need to affect all lines since the kconfig column needs to expand
> by at least one character to fit QCOM_FALKOR_ERRATUM_1003.
Or we can make the macro shorter.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Mark Rutland @ 2017-01-11 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111180627.GG20288@e104818-lin.cambridge.arm.com>
On Wed, Jan 11, 2017 at 06:06:27PM +0000, Catalin Marinas wrote:
> On Wed, Jan 11, 2017 at 09:41:15AM -0500, Christopher Covington wrote:
> > -| Implementor | Component | Erratum ID | Kconfig |
> > +| Implementor | Component | Erratum ID | Kconfig |
> > +| Qualcomm | Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
>
> Please don't change the "Implementor" column width, there is no point
> and it makes the patch harder to read (i.e. this hunk should only have
> one line).
It'll need to affect all lines since the kconfig column needs to expand
by at least one character to fit QCOM_FALKOR_ERRATUM_1003.
I beleive the intent here was to keep the table fitting into a width of
80 characters.
IMO we should allow the table to expand past 80 chars (everyone reading
this file should be able to resize tehir terminal), and only expand the
kconfig column.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports
From: Nikita Yushchenko @ 2017-01-11 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484159512-28515-1-git-send-email-nikita.yoush@cogentembedded.com>
There are cases when device supports wide DMA addresses wider than
device's connection supports.
In this case driver sets DMA mask based on knowledge of device
capabilities. That must succeed to allow drivers to initialize.
However, swiotlb or iommu still need knowledge about actual device
capabilities. To avoid breakage, actual mask must not be set wider than
device connection allows.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Robin Murphy <robin.murphy@arm.com>
CC: Will Deacon <will.deacon@arm.com>
---
arch/arm64/Kconfig | 3 +++
arch/arm64/include/asm/device.h | 1 +
arch/arm64/include/asm/dma-mapping.h | 3 +++
arch/arm64/mm/dma-mapping.c | 40 ++++++++++++++++++++++++++++++++++++
4 files changed, 47 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1117421..afb2c08 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -216,6 +216,9 @@ config NEED_DMA_MAP_STATE
config NEED_SG_DMA_LENGTH
def_bool y
+config ARCH_HAS_DMA_SET_COHERENT_MASK
+ def_bool y
+
config SMP
def_bool y
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index 243ef25..a57e7bb 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -22,6 +22,7 @@ struct dev_archdata {
void *iommu; /* private IOMMU data */
#endif
bool dma_coherent;
+ u64 parent_dma_mask;
};
struct pdev_archdata {
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index ae1c23f..46b53e6 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -52,6 +52,9 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
bool coherent);
#define arch_setup_dma_ops arch_setup_dma_ops
+#define HAVE_ARCH_DMA_SET_MASK 1
+extern int dma_set_mask(struct device *dev, u64 dma_mask);
+
#ifdef CONFIG_IOMMU_DMA
void arch_teardown_dma_ops(struct device *dev);
#define arch_teardown_dma_ops arch_teardown_dma_ops
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index ea295f1..31b96fd 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -203,6 +203,37 @@ static void __dma_free(struct device *dev, size_t size,
__dma_free_coherent(dev, size, swiotlb_addr, dma_handle, attrs);
}
+int dma_set_mask(struct device *dev, u64 dma_mask)
+{
+ const struct dma_map_ops *ops = get_dma_ops(dev);
+
+ if (mask > dev->archdata.parent_dma_mask)
+ mask = dev->archdata.parent_dma_mask;
+
+ if (ops->set_dma_mask)
+ return ops->set_dma_mask(dev, mask);
+
+ if (!dev->dma_mask || !dma_supported(dev, mask))
+ return -EIO;
+
+ *dev->dma_mask = mask;
+ return 0;
+}
+EXPORT_SYMBOL(dma_set_mask);
+
+int dma_set_coherent_mask(struct device *dev, u64 mask)
+{
+ if (mask > dev->archdata.parent_dma_mask)
+ mask = dev->archdata.parent_dma_mask;
+
+ if (!dma_supported(dev, mask))
+ return -EIO;
+
+ dev->coherent_dma_mask = mask;
+ return 0;
+}
+EXPORT_SYMBOL(dma_set_coherent_mask);
+
static dma_addr_t __swiotlb_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
enum dma_data_direction dir,
@@ -959,6 +990,15 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
if (!dev->archdata.dma_ops)
dev->archdata.dma_ops = &swiotlb_dma_ops;
+ /*
+ * Whatever the parent bus can set. A device must not set
+ * a DMA mask larger than this.
+ */
+ if (enforce_range)
+ dev->archdata.parent_dma_mask = size - 1;
+ else
+ dev->archdata.parent_dma_mask = DMA_BIT_MASK(64);
+
dev->archdata.dma_coherent = coherent;
__iommu_setup_dma_ops(dev, dma_base, size, iommu);
}
--
2.1.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