* [PATCH 03/11] i2c: mux: pca9541: switch to i2c_lock_segment
From: Peter Rosin @ 2018-06-15 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615101506.8012-1-peda@axentia.se>
Locking the root adapter for __i2c_transfer will deadlock if the
device sits behind a mux-locked I2C mux. Switch to the finer-grained
i2c_lock_segment. If the device does not sit behind a mux-locked mux,
the two locking variants are equivalent.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/i2c/muxes/i2c-mux-pca9541.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/muxes/i2c-mux-pca9541.c b/drivers/i2c/muxes/i2c-mux-pca9541.c
index 6a39adaf433f..74c560ed44cc 100644
--- a/drivers/i2c/muxes/i2c-mux-pca9541.c
+++ b/drivers/i2c/muxes/i2c-mux-pca9541.c
@@ -345,11 +345,11 @@ static int pca9541_probe(struct i2c_client *client,
/*
* I2C accesses are unprotected here.
- * We have to lock the adapter before releasing the bus.
+ * We have to lock the I2C segment before releasing the bus.
*/
- i2c_lock_adapter(adap);
+ i2c_lock_segment(adap);
pca9541_release_bus(client);
- i2c_unlock_adapter(adap);
+ i2c_unlock_segment(adap);
/* Create mux adapter */
--
2.11.0
^ permalink raw reply related
* [PATCH 02/11] tpm/tpm_i2c_infineon: switch to i2c_lock_segment
From: Peter Rosin @ 2018-06-15 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615101506.8012-1-peda@axentia.se>
Locking the root adapter for __i2c_transfer will deadlock if the
device sits behind a mux-locked I2C mux. Switch to the finer-grained
i2c_lock_segment. If the device does not sit behind a mux-locked mux,
the two locking variants are equivalent.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/char/tpm/tpm_i2c_infineon.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/tpm/tpm_i2c_infineon.c b/drivers/char/tpm/tpm_i2c_infineon.c
index 6116cd05e228..b2889405b4fa 100644
--- a/drivers/char/tpm/tpm_i2c_infineon.c
+++ b/drivers/char/tpm/tpm_i2c_infineon.c
@@ -117,7 +117,7 @@ static int iic_tpm_read(u8 addr, u8 *buffer, size_t len)
/* Lock the adapter for the duration of the whole sequence. */
if (!tpm_dev.client->adapter->algo->master_xfer)
return -EOPNOTSUPP;
- i2c_lock_adapter(tpm_dev.client->adapter);
+ i2c_lock_segment(tpm_dev.client->adapter);
if (tpm_dev.chip_type == SLB9645) {
/* use a combined read for newer chips
@@ -192,7 +192,7 @@ static int iic_tpm_read(u8 addr, u8 *buffer, size_t len)
}
out:
- i2c_unlock_adapter(tpm_dev.client->adapter);
+ i2c_unlock_segment(tpm_dev.client->adapter);
/* take care of 'guard time' */
usleep_range(SLEEP_DURATION_LOW, SLEEP_DURATION_HI);
@@ -224,7 +224,7 @@ static int iic_tpm_write_generic(u8 addr, u8 *buffer, size_t len,
if (!tpm_dev.client->adapter->algo->master_xfer)
return -EOPNOTSUPP;
- i2c_lock_adapter(tpm_dev.client->adapter);
+ i2c_lock_segment(tpm_dev.client->adapter);
/* prepend the 'register address' to the buffer */
tpm_dev.buf[0] = addr;
@@ -243,7 +243,7 @@ static int iic_tpm_write_generic(u8 addr, u8 *buffer, size_t len,
usleep_range(sleep_low, sleep_hi);
}
- i2c_unlock_adapter(tpm_dev.client->adapter);
+ i2c_unlock_segment(tpm_dev.client->adapter);
/* take care of 'guard time' */
usleep_range(SLEEP_DURATION_LOW, SLEEP_DURATION_HI);
--
2.11.0
^ permalink raw reply related
* [PATCH 01/11] i2c: add helpers for locking the I2C segment
From: Peter Rosin @ 2018-06-15 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615101506.8012-1-peda@axentia.se>
This is what almost all drivers want to do. By only advertising
i2c_lock_adapter, they are tricked into locking the root adapter
which is too big of a hammer in most cases.
While at it, convert all open-coded locking of the I2C segment.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/i2c/i2c-core-base.c | 6 +++---
drivers/i2c/i2c-core-smbus.c | 4 ++--
include/linux/i2c.h | 18 ++++++++++++++++++
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 1ba40bb2b966..3eb09dc20573 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1932,16 +1932,16 @@ int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
#endif
if (in_atomic() || irqs_disabled()) {
- ret = i2c_trylock_bus(adap, I2C_LOCK_SEGMENT);
+ ret = i2c_trylock_segment(adap);
if (!ret)
/* I2C activity is ongoing. */
return -EAGAIN;
} else {
- i2c_lock_bus(adap, I2C_LOCK_SEGMENT);
+ i2c_lock_segment(adap);
}
ret = __i2c_transfer(adap, msgs, num);
- i2c_unlock_bus(adap, I2C_LOCK_SEGMENT);
+ i2c_unlock_segment(adap);
return ret;
} else {
diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c
index b5aec33002c3..8a820fdef3e0 100644
--- a/drivers/i2c/i2c-core-smbus.c
+++ b/drivers/i2c/i2c-core-smbus.c
@@ -537,7 +537,7 @@ s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr, unsigned short flags,
flags &= I2C_M_TEN | I2C_CLIENT_PEC | I2C_CLIENT_SCCB;
if (adapter->algo->smbus_xfer) {
- i2c_lock_bus(adapter, I2C_LOCK_SEGMENT);
+ i2c_lock_segment(adapter);
/* Retry automatically on arbitration loss */
orig_jiffies = jiffies;
@@ -551,7 +551,7 @@ s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr, unsigned short flags,
orig_jiffies + adapter->timeout))
break;
}
- i2c_unlock_bus(adapter, I2C_LOCK_SEGMENT);
+ i2c_unlock_segment(adapter);
if (res != -EOPNOTSUPP || !adapter->algo->master_xfer)
goto trace;
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 44ad14e016b5..c9080d49e988 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -768,6 +768,24 @@ i2c_unlock_adapter(struct i2c_adapter *adapter)
i2c_unlock_bus(adapter, I2C_LOCK_ROOT_ADAPTER);
}
+static inline void
+i2c_lock_segment(struct i2c_adapter *adapter)
+{
+ i2c_lock_bus(adapter, I2C_LOCK_SEGMENT);
+}
+
+static inline int
+i2c_trylock_segment(struct i2c_adapter *adapter)
+{
+ return i2c_trylock_bus(adapter, I2C_LOCK_SEGMENT);
+}
+
+static inline void
+i2c_unlock_segment(struct i2c_adapter *adapter)
+{
+ i2c_unlock_bus(adapter, I2C_LOCK_SEGMENT);
+}
+
/*flags for the client struct: */
#define I2C_CLIENT_PEC 0x04 /* Use Packet Error Checking */
#define I2C_CLIENT_TEN 0x10 /* we have a ten bit chip address */
--
2.11.0
^ permalink raw reply related
* [PATCH 00/11] Split i2c_lock_adapter into i2c_lock_root and i2c_lock_segment
From: Peter Rosin @ 2018-06-15 10:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
With the introduction of mux-locked I2C muxes, the concept of
locking only a segment of the I2C adapter tree was added. At the
time, I did not want to cause a lot of extra churn, so left most
users of i2c_lock_adapter alone and aparently didn't think enough
about it; they simply continued to lock the whole adapter tree.
However, i2c_lock_adapter is in fact wrong for almost every caller
(there are naturally exceptions) that is itself not a driver for
a root adapter. What normal drivers generally want is to only
lock the segment of the adapter tree that their device sits on.
In fact, if a device sits behind a mux-locked I2C mux, and its
driver calls i2c_lock_adapter followed by an unlocked I2C transfer,
things will deadlock (since even a mux-locked I2C adapter will lock
its parent at some point). If the device is not sitting behind a
mux-locked I2C mux (i.e. either directly on the root adapter or
behind a (chain of) parent-locked I2C muxes) the root/segment
distinction is of no consequence; the root adapter is locked either
way.
Mux-locked I2C muxes are probably not that common, and putting any
of the affected devices behind one is probably even rarer, which
is why we have not seen any deadlocks. At least not that I know
of...
Since silently changing the semantics of i2c_lock_adapter might
be quite a surprise, especially for out-of-tree users, this
series instead introduces new helpers to make it easier to only
lock the I2C segment, then converts drivers over and finally
renames the remaining i2c_lock_adapter instances to i2c_lock_root.
I suggest that Wolfram takes this series through the I2C tree
and creates an immutable branch for the other subsystems. The
series is based on v4.17, but I did not find any new instances in
neither linus-master nor linux-next and the series still applies
cleanly to linus-master for me. linux-next has removed suspend
support from the i2c-tegra driver. A bit strange, I thought the
I2C changes was merged for this window? Anyway, the resolution
for that conflict is trivial, just remove the i2c-tegra hunk from
patch 11.
I do not have *any* of the affected devices, and have thus only
done build tests.
Cheers,
Peter
Peter Rosin (11):
i2c: add helpers for locking the I2C segment
tpm/tpm_i2c_infineon: switch to i2c_lock_segment
i2c: mux: pca9541: switch to i2c_lock_segment
input: rohm_bu21023: switch to i2c_lock_segment
media: af9013: switch to i2c_lock_segment
media: drxk_hard: switch to i2c_lock_segment
media: rtl2830: switch to i2c_lock_segment
media: tda1004x: switch to i2c_lock_segment
media: tda18271: switch to i2c_lock_segment
mfd: 88pm860x-i2c: switch to i2c_lock_segment
i2c: rename i2c_lock_adapter to i2c_lock_root
drivers/char/tpm/tpm_i2c_infineon.c | 8 ++++----
drivers/i2c/busses/i2c-brcmstb.c | 8 ++++----
drivers/i2c/busses/i2c-davinci.c | 4 ++--
drivers/i2c/busses/i2c-gpio.c | 12 ++++++------
drivers/i2c/busses/i2c-s3c2410.c | 4 ++--
drivers/i2c/busses/i2c-sprd.c | 8 ++++----
drivers/i2c/busses/i2c-tegra.c | 8 ++++----
drivers/i2c/i2c-core-base.c | 6 +++---
drivers/i2c/i2c-core-slave.c | 8 ++++----
drivers/i2c/i2c-core-smbus.c | 4 ++--
drivers/i2c/muxes/i2c-mux-pca9541.c | 6 +++---
drivers/iio/temperature/mlx90614.c | 4 ++--
drivers/input/touchscreen/rohm_bu21023.c | 4 ++--
drivers/media/dvb-frontends/af9013.c | 8 ++++----
drivers/media/dvb-frontends/drxk_hard.c | 4 ++--
drivers/media/dvb-frontends/rtl2830.c | 12 ++++++------
drivers/media/dvb-frontends/tda1004x.c | 6 +++---
drivers/media/tuners/tda18271-common.c | 8 ++++----
drivers/mfd/88pm860x-i2c.c | 8 ++++----
include/linux/i2c.h | 22 ++++++++++++++++++++--
20 files changed, 85 insertions(+), 67 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 1/4] arm: dts: add support for Laird WB45N cpu module and DVK
From: Ben Whitten @ 2018-06-15 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <03f0f635-3fc2-085b-20e0-e1fcaa9e8062@microchip.com>
> On 14/06/2018 at 10:51, Ben Whitten wrote:
> > Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> > ---
> > arch/arm/boot/dts/Makefile | 3 +-
> > arch/arm/boot/dts/at91-wb45n.dts | 66 +++++++++++++++
> > arch/arm/boot/dts/at91-wb45n.dtsi | 169
> ++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 237 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/boot/dts/at91-wb45n.dts
> > create mode 100644 arch/arm/boot/dts/at91-wb45n.dtsi
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 7e24249..1ee94ee 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -42,7 +42,8 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
> > at91sam9g25ek.dtb \
> > at91sam9g35ek.dtb \
> > at91sam9x25ek.dtb \
> > - at91sam9x35ek.dtb
> > + at91sam9x35ek.dtb \
> > + at91-wb45n.dtb
> > dtb-$(CONFIG_SOC_SAM_V7) += \
> > at91-kizbox2.dtb \
> > at91-nattis-2-natte-2.dtb \
> > diff --git a/arch/arm/boot/dts/at91-wb45n.dts b/arch/arm/boot/dts/at91-
> wb45n.dts
> > new file mode 100644
> > index 0000000..4e88815
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/at91-wb45n.dts
> > @@ -0,0 +1,66 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * at91-wb45n.dts - Device Tree file for WB45NBT board
> > + *
> > + * Copyright (C) 2018 Laird
> > + *
> > +*/
> > +/dts-v1/;
> > +#include "at91-wb45n.dtsi"
> > +
> > +/ {
> > + model = "Laird Workgroup Bridge 45N - Atmel AT91SAM (dt)";
> > + compatible = "laird,wb45n", "laird,wbxx", "atmel,at91sam9x5",
> "atmel,at91sam9";
>
> "laird" prefix must be added to
> Documentation/devicetree/bindings/vendor-prefixes.txt before using it:
> you can do a little patch as a first patch of this series.
> Otherwise it will trigger a warning message while running
> scripts/checkpatch.pl on top of your patch.
>
>
> > +
> > + ahb {
> > + apb {
> > + watchdog at fffffe40 {
> > + status = "okay";
> > + };
> > + };
> > + };
> > +
> > + gpio_keys {
> > + compatible = "gpio-keys";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + irqbtn at pb18 {
>
> I'm not sure that the @pb18 can be used like this. This address
> extension must be used in a "reg" property in the node. dtc used with
> warning switch on might trigger an error for this.
>
> > + label = "IRQBTN";
> > + linux,code = <99>;
> > + gpios = <&pioB 18 GPIO_ACTIVE_LOW>;
> > + gpio-key,wakeup = <1>;
> > + };
> > + };
> > +};
> > +
> > +&usb0 {
> > + status = "okay";
> > +};
> > +
> > +&mmc0 {
> > + status = "okay";
> > +};
> > +
> > +&spi0 {
> > + status = "okay";
> > +};
> > +
> > +&macb0 {
> > + status = "okay";
> > +};
> > +
> > +&dbgu {
> > + status = "okay";
> > +};
> > +
> > +&usart0 {
> > + status = "okay";
> > +};
> > +
> > +&usart3 {
> > + status = "okay";
> > +};
> > +
> > +&i2c1 {
> > + status = "okay";
> > +};
> > diff --git a/arch/arm/boot/dts/at91-wb45n.dtsi b/arch/arm/boot/dts/at91-
> wb45n.dtsi
> > new file mode 100644
> > index 0000000..2fa58e2
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/at91-wb45n.dtsi
> > @@ -0,0 +1,169 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * at91-wb45n.dtsi - Device Tree file for WB45NBT board
> > + *
> > + * Copyright (C) 2018 Laird
> > + *
> > + */
> > +
> > +#include "at91sam9g25.dtsi"
> > +
> > +/ {
> > + model = "Laird Workgroup Bridge 45N - Atmel AT91SAM (dt)";
> > + compatible = "laird,wb45n", "laird,wbxx", "atmel,at91sam9x5",
> "atmel,at91sam9";
> > +
> > + chosen {
> > + bootargs = "ubi.mtd=6 root=ubi0:rootfs rootfstype=ubifs
> rw";
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + memory {
> > + reg = <0x20000000 0x4000000>;
> > + };
> > +
> > + ahb {
> > + apb {
> > + shdwc at fffffe10 {
>
> I would advice you to take exactly the node name:
> "shutdown-controller at fffffe10"; Anyway, it will go away after you use
> the label notation as advised by Alexandre.
>
> > + atmel,wakeup-mode = "low";
> > + };
> > +
> > + pinctrl at fffff400 {
> > + usb2 {
> > + pinctrl_board_usb2: usb2-board {
> > + atmel,pins =
> > + <AT91_PIOB 11
> AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PB11 gpio
> vbus sense, deglitch */
> > + };
> > + };
> > + };
> > +
> > + rstc at fffffe00 {
> > + compatible = "atmel,sama5d3-rstc";
> > + };
>
> I don't think this node is needed.
I dug through our old code reviews and found this message relating to testing
reboot over several thousand times in our testbed:
After the slow clock has been enabled on the reset controller via upstream
changes, the dram disable access and power down code is causing the SAM9G25
to hang occasionally on reboot. Using the simple reset function provided
for SAMA5D3 instead.
So it appears to be a workaround for a bug that existed ~2 years ago, may still be
relevant as there haven't been many changes to the reset code in that time.
> > +
> > + };
> > + };
> > +
> > + atheros {
> > + compatible = "atheros,ath6kl";
> > + atheros,board-id = "SD32";
> > + };
> > +};
> > +
> > +&slow_xtal {
> > + clock-frequency = <32768>;
> > +};
> > +
> > +&main_xtal {
> > + clock-frequency = <12000000>;
> > +};
> > +
> > +&ebi {
> > + status = "okay";
> > + nand_controller: nand-controller {
> > + pinctrl-0 = <&pinctrl_nand_cs &pinctrl_nand_rb
> &pinctrl_nand_oe_we>;
> > + pinctrl-names = "default";
> > + status = "okay";
> > +
> > + nand at 3 {
> > + reg = <0x3 0x0 0x800000>;
> > + rb-gpios = <&pioD 5 GPIO_ACTIVE_HIGH>;
> > + cs-gpios = <&pioD 4 GPIO_ACTIVE_HIGH>;
> > + nand-bus-width = <8>;
> > + nand-ecc-mode = "hw";
> > + nand-ecc-strength = <4>;
> > + nand-ecc-step-size = <512>;
> > + nand-on-flash-bbt;
> > + label = "atmel_nand";
> > +
> > + partitions {
> > + compatible = "fixed-partitions";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + at91bootstrap at 0 {
> > + label = "at91bs";
> > + reg = <0x0 0x20000>;
> > + };
> > +
> > + uboot at 20000 {
> > + label = "u-boot";
> > + reg = <0x20000 0x80000>;
> > + };
> > +
> > + ubootenv at a0000 {
> > + label = "u-boot-env";
> > + reg = <0xa0000 0x20000>;
> > + };
> > +
> > + ubootenv at c0000 {
> > + label = "redund-env";
> > + reg = <0xc0000 0x20000>;
> > + };
> > +
> > + kernel-a at e0000 {
> > + label = "kernel-a";
> > + reg = <0xe0000 0x280000>;
> > + };
> > +
> > + kernel-b at 360000 {
> > + label = "kernel-b";
> > + reg = <0x360000 0x280000>;
> > + };
> > +
> > + rootfs-a at 5e0000 {
> > + label = "rootfs-a";
> > + reg = <0x5e0000 0x2600000>;
> > + };
> > +
> > + rootfs-b at 2be0000 {
> > + label = "rootfs-b";
> > + reg = <0x2be0000 0x2600000>;
> > + };
> > +
> > + user at 51e0000 {
> > + label = "user";
> > + reg = <0x51e0000 0x2dc0000>;
> > + };
> > +
> > + logs at 7fa0000 {
> > + label = "logs";
> > + reg = <0x7fa0000 0x60000>;
> > + };
> > +
> > + };
> > + };
> > + };
> > +};
> > +
> > +&usb0 {
>
> This must be &usb1 label, isn't it?
> Because you are referring to ohci binding I suspect (found by having a
> look at: atmel,oc-gpio property...).
I believe usb0 is correct, as this is a at91sam9x5 part, the node in dtsi is -ohci.
sama5d3 is usb1 for -ohci.
> > + num-ports = <2>;
> > + atmel,vbus-gpio = <
> > + &pioB 12 GPIO_ACTIVE_HIGH
> > + &pioA 31 GPIO_ACTIVE_HIGH
> > + >;
> > + atmel,oc-gpio = <&pioB 13 GPIO_ACTIVE_LOW>;
> > +};
> > +
> > +&macb0 {
> > + phy-mode = "rmii";
> > +};
> > +
> > +&spi0 {
> > + cs-gpios = <&pioA 14 0>, <&pioA 7 0>, <0>, <0>;
> > +};
> > +
> > +&usb2 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_board_usb2>;
> > + atmel,vbus-gpio = <&pioB 11 GPIO_ACTIVE_HIGH>;
> > +};
> > +
> > +&mmc0 {
> > + pinctrl-0 = <
> > + &pinctrl_mmc0_slot0_clk_cmd_dat0
> > + &pinctrl_mmc0_slot0_dat1_3>;
> > + slot at 0 {
> > + reg = <0>;
> > + bus-width = <4>;
> > + };
> > +};
> >
>
>
> --
> Nicolas Ferre
^ permalink raw reply
* [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings
From: Suzuki K Poulose @ 2018-06-15 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+0kExVY33kdDoR6bAxbr2VzRUzW2j0k+2wmv4CSNVnpQ@mail.gmail.com>
On 14/06/18 14:59, Rob Herring wrote:
> On Thu, Jun 14, 2018 at 2:53 AM, Suzuki K Poulose
> <Suzuki.Poulose@arm.com> wrote:
>> On 13/06/18 22:07, Matt Sealey wrote:
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>
>>>>> So, if the suggestion is to use an existing property "unit", I am fine
>>>>> with it, if people agree to it.
>>>>
>>>>
>>>> If we're going to have something sharply different than ACPI I prefer
>>>> Rob's idea.
>>
>>
>> No, the above comment is about using "unit" ( if it is a standard property
>> for specifying something specific to hardware) instead of "coresight,hwid".
>> I would prefer to stick to the DT graph bindings, because :
>
> "unit" is not a standard property and I don't like it either.
>
>>
>> 1) The connections are bi-directional => Well, not necessarily
>> bi-directional
>> in terms of the data flow. But the connection information is critical. i.e,
>> we need information about both the end-points of a connection, which the DT
>> graph bindings solves.
>>
>> All we are missing is a way for specifying the "hardware port" number and
>> the
>> direction of flow. I don't see why do we need to create something new just
>> for
>> these two properties for something that exists today and works reasonably
>> well
>> for the usecase.
Rob,
>
> If you have "in-ports" and "out-ports" nodes, then that gives you
> direction and you can use reg for the "hardware port".
>
> in-ports {
> port at 0 {
> reg = <0>;
> endpoint {...};
> };
> port at 1 {
> reg = <1>;
> endpoint {...};
> };
> };
> out-ports {
> port at 0 {
> reg = <0>;
> endpoint {...};
> };
> };
>
> I'll need to check, but dtc may need an update to not warn about this.
Ok, that looks good.
>
>>
>>>
>>> What are you trying to say about being sharply different than ACPI?
>>
>>
>> The proposed Coresight ACPI draft bindings are based on the ACPI Graph
>> bindings
>> (just like the DT graph bindings and is compatible with it, in terms of the
>> APIs.
>> i.e, fwnode_graph_* operations work for both ACPI and DT alike).
>>
>> So, what Mathieu, in turn means is, if we depart from the DT Graph bindings,
>> which
>> I personally don't see any benefit in.
>
> If DT bindings can be reused for ACPI, that's fine, but don't expect
> any DT bindings to be accepted simply because they match ACPI
> bindings.
The proposed bindings are not making it compatible with the ACPI. In fact,
the ACPI bindings do need something similar to give us an explicit hardware
port number, which needs to be worked out. The only common theme shared
between the proposed ACPI and current DT bindings are the Generic Graph
bindings for describing the connections, which allows sharing the parsing
code independent of the platform, using fwnode_ops.
Suzuki
^ permalink raw reply
* [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
From: Graeme Gregory @ 2018-06-15 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51d3d738-cdf5-2992-bba5-c3e1f34096c2@infradead.org>
On Wed, Jun 13, 2018 at 11:22:30AM -0700, Geoff Levand wrote:
> Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
> a work-around for HPE ProLiant m400 APEI firmware problems.
>
> The work-around disables APEI when CONFIG_ACPI_APEI is set and
> m400 firmware is detected. Without this fixup m400 systems
> experience errors like these on startup:
>
> [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
> [Hardware Error]: event severity: fatal
> [Hardware Error]: Error 0, type: fatal
> [Hardware Error]: section_type: memory error
> [Hardware Error]: error_status: 0x0000000000001300
> [Hardware Error]: error_type: 10, invalid address
> Kernel panic - not syncing: Fatal hardware error!
>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
> ---
> Hi,
>
> It seems unlikely there will be any m400 firmware updates to fix
> this problem. APEI support is desired for new ARM64 servers coming
> to market. Distros are now forced to have their own fixes, not
> enable APEI, or let m400 users fend for themselves.
>
> Please consider.
>
> -Geoff
>
> arch/arm64/kernel/acpi.c | 40 ++++++++++++++++++++++++++++++++++++----
> 1 file changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 7b09487ff8fb..3c315c2c7476 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -31,6 +31,8 @@
> #include <asm/cpu_ops.h>
> #include <asm/smp_plat.h>
>
> +#include <acpi/apei.h>
> +
> #ifdef CONFIG_ACPI_APEI
> # include <linux/efi.h>
> # include <asm/pgtable.h>
> @@ -177,6 +179,33 @@ static int __init acpi_fadt_sanity_check(void)
> return ret;
> }
>
> +/*
> + * acpi_fixup_m400_quirks - Work-around for HPE ProLiant m400 APEI firmware
> + * problems.
> + */
> +static void __init acpi_fixup_m400_quirks(void)
> +{
> + acpi_status status;
> + struct acpi_table_header *header;
> +#if !defined(CONFIG_ACPI_APEI)
> + int hest_disable = HEST_DISABLED;
> +#endif
> +
> + if (!IS_ENABLED(CONFIG_ACPI_APEI) || hest_disable != HEST_ENABLED)
> + return;
> +
> + status = acpi_get_table(ACPI_SIG_HEST, 0, &header);
> +
> + if (ACPI_SUCCESS(status) && !strncmp(header->oem_id, "HPE ", 6) &&
> + !strncmp(header->oem_table_id, "ProLiant", 8) &&
> + MIDR_IMPLEMENTOR(read_cpuid_id()) == ARM_CPU_IMP_APM) {
> + hest_disable = HEST_DISABLED;
> + pr_info("Disabled APEI for m400.\n");
> + }
> +
> + acpi_put_table(header);
> +}
> +
> /*
> * acpi_boot_table_init() called from setup_arch(), always.
> * 1. find RSDP and get its address, and then find XSDT
> @@ -232,11 +261,14 @@ void __init acpi_boot_table_init(void)
> if (acpi_disabled) {
> if (earlycon_acpi_spcr_enable)
> early_init_dt_scan_chosen_stdout();
> - } else {
> - acpi_parse_spcr(earlycon_acpi_spcr_enable, true);
> - if (IS_ENABLED(CONFIG_ACPI_BGRT))
> - acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
> + return;
> }
> +
> + acpi_parse_spcr(earlycon_acpi_spcr_enable, true);
> + if (IS_ENABLED(CONFIG_ACPI_BGRT))
> + acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
> +
> + acpi_fixup_m400_quirks();
> }
>
> #ifdef CONFIG_ACPI_APEI
Quirk actually make code nicer to read.
Reviewed-by: Graeme Gregory <graeme.gregory@linaro.org>
Thanks we needed this having 90+ m400s
Graeme
^ permalink raw reply
* [PATCH v2 4/4] mailbox: Add support for i.MX7D messaging unit
From: Oleksij Rempel @ 2018-06-15 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615095107.24610-1-o.rempel@pengutronix.de>
The Mailbox controller is able to send messages (up to 4 32 bit words)
between the endpoints.
This driver was tested using the mailbox-test driver sending messages
between the Cortex-A7 and the Cortex-M4.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
drivers/mailbox/Kconfig | 6 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/imx-mailbox.c | 288 ++++++++++++++++++++++++++++++++++
3 files changed, 296 insertions(+)
create mode 100644 drivers/mailbox/imx-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index a2bb27446dce..e1d2738a2e4c 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -15,6 +15,12 @@ config ARM_MHU
The controller has 3 mailbox channels, the last of which can be
used in Secure mode only.
+config IMX_MBOX
+ tristate "iMX Mailbox"
+ depends on SOC_IMX7D || COMPILE_TEST
+ help
+ Mailbox implementation for iMX7D Messaging Unit (MU).
+
config PLATFORM_MHU
tristate "Platform MHU Mailbox"
depends on OF
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index cc23c3a43fcd..ba2fe1b6dd62 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
obj-$(CONFIG_ARM_MHU) += arm_mhu.o
+obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
+
obj-$(CONFIG_PLATFORM_MHU) += platform_mhu.o
obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
new file mode 100644
index 000000000000..e3f621cb1d30
--- /dev/null
+++ b/drivers/mailbox/imx-mailbox.c
@@ -0,0 +1,288 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 Pengutronix, Oleksij Rempel <o.rempel@pengutronix.de>
+ */
+
+#include <linux/clk.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+
+/* Transmit Register */
+#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
+/* Receive Register */
+#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
+/* Status Register */
+#define IMX_MU_xSR 0x20
+#define IMX_MU_xSR_TEn(x) BIT(20 + (x))
+#define IMX_MU_xSR_RFn(x) BIT(24 + (x))
+#define IMX_MU_xSR_BRDIP BIT(9)
+
+/* Control Register */
+#define IMX_MU_xCR 0x24
+/* Transmit Interrupt Enable */
+#define IMX_MU_xCR_TIEn(x) BIT(20 + (x))
+/* Receive Interrupt Enable */
+#define IMX_MU_xCR_RIEn(x) BIT(24 + (x))
+
+#define IMX_MU_MAX_CHANS 4u
+
+struct imx_mu_priv;
+
+struct imx_mu_cfg {
+ unsigned int chans;
+ void (*init_hw)(struct imx_mu_priv *priv);
+};
+
+struct imx_mu_con_priv {
+ int irq;
+ unsigned int bidx;
+ unsigned int idx;
+};
+
+struct imx_mu_priv {
+ struct device *dev;
+ const struct imx_mu_cfg *dcfg;
+ void __iomem *base;
+
+ struct mbox_controller mbox;
+ struct mbox_chan mbox_chans[IMX_MU_MAX_CHANS];
+
+ struct imx_mu_con_priv con_priv[IMX_MU_MAX_CHANS];
+ struct clk *clk;
+};
+
+static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller *mbox)
+{
+ return container_of(mbox, struct imx_mu_priv, mbox);
+}
+
+static void imx_mu_write(struct imx_mu_priv *priv, u32 val, u32 offs)
+{
+ iowrite32(val, priv->base + offs);
+}
+
+static u32 imx_mu_read(struct imx_mu_priv *priv, u32 offs)
+{
+ return ioread32(priv->base + offs);
+}
+
+static u32 imx_mu_rmw(struct imx_mu_priv *priv, u32 offs, u32 set, u32 clr)
+{
+ u32 val;
+
+ val = imx_mu_read(priv, offs);
+ val &= ~clr;
+ val |= set;
+ imx_mu_write(priv, val, offs);
+
+ return val;
+}
+
+static irqreturn_t imx_mu_isr(int irq, void *p)
+{
+ struct mbox_chan *chan = p;
+ struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
+ struct imx_mu_con_priv *cp = chan->con_priv;
+
+ u32 val, dat;
+
+ val = imx_mu_read(priv, IMX_MU_xSR);
+ val &= IMX_MU_xSR_TEn(cp->bidx) | IMX_MU_xSR_RFn(cp->bidx);
+ if (!val)
+ return IRQ_NONE;
+
+ if (val & IMX_MU_xSR_TEn(cp->bidx)) {
+ imx_mu_rmw(priv, IMX_MU_xCR, 0, IMX_MU_xCR_TIEn(cp->bidx));
+ mbox_chan_txdone(chan, 0);
+ }
+
+ if (val & IMX_MU_xSR_RFn(cp->bidx)) {
+ dat = imx_mu_read(priv, IMX_MU_xRRn(cp->idx));
+ mbox_chan_received_data(chan, (void *)&dat);
+ }
+
+ return IRQ_HANDLED;
+}
+
+static bool imx_mu_last_tx_done(struct mbox_chan *chan)
+{
+ struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
+ struct imx_mu_con_priv *cp = chan->con_priv;
+ u32 val;
+
+ val = imx_mu_read(priv, IMX_MU_xSR);
+ /* test if transmit register is empty */
+ return (!!(val & IMX_MU_xSR_TEn(cp->bidx)));
+}
+
+static int imx_mu_send_data(struct mbox_chan *chan, void *data)
+{
+ struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
+ struct imx_mu_con_priv *cp = chan->con_priv;
+ u32 *arg = data;
+
+ if (!imx_mu_last_tx_done(chan))
+ return -EBUSY;
+
+ imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
+ imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xSR_TEn(cp->bidx), 0);
+
+ return 0;
+}
+
+static int imx_mu_startup(struct mbox_chan *chan)
+{
+ struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
+ struct imx_mu_con_priv *cp = chan->con_priv;
+ int ret;
+
+ ret = request_irq(cp->irq, imx_mu_isr,
+ IRQF_SHARED, "imx_mu_chan", chan);
+ if (ret) {
+ dev_err(chan->mbox->dev,
+ "Unable to acquire IRQ %d\n", cp->irq);
+ return ret;
+ }
+
+ imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xCR_RIEn(cp->bidx), 0);
+
+ return 0;
+}
+
+static void imx_mu_shutdown(struct mbox_chan *chan)
+{
+ struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
+ struct imx_mu_con_priv *cp = chan->con_priv;
+
+ imx_mu_rmw(priv, IMX_MU_xCR, 0,
+ IMX_MU_xCR_TIEn(cp->bidx) | IMX_MU_xCR_RIEn(cp->bidx));
+
+ free_irq(cp->irq, chan);
+}
+
+static const struct mbox_chan_ops imx_mu_ops = {
+ .send_data = imx_mu_send_data,
+ .startup = imx_mu_startup,
+ .shutdown = imx_mu_shutdown,
+};
+
+static int imx_mu_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct resource *iomem;
+ struct imx_mu_priv *priv;
+ const struct imx_mu_cfg *dcfg;
+ unsigned int i, chans;
+ int irq, ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ dcfg = of_device_get_match_data(dev);
+ if (!dcfg)
+ return -EINVAL;
+
+ priv->dcfg = dcfg;
+ priv->dev = dev;
+
+ iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->base = devm_ioremap_resource(&pdev->dev, iomem);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq <= 0)
+ return irq < 0 ? irq : -EINVAL;
+
+ priv->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(priv->clk)) {
+ if (PTR_ERR(priv->clk) == -ENOENT) {
+ priv->clk = NULL;
+ } else {
+ dev_err(dev, "Failed to get clock\n");
+ return PTR_ERR(priv->clk);
+ }
+ }
+
+ ret = clk_prepare_enable(priv->clk);
+ if (ret) {
+ dev_err(dev, "Failed to enable clock\n");
+ return ret;
+ }
+
+ chans = min(dcfg->chans, IMX_MU_MAX_CHANS);
+ /* Initialize channel identifiers */
+ for (i = 0; i < chans; i++) {
+ struct imx_mu_con_priv *cp = &priv->con_priv[i];
+
+ cp->bidx = 3 - i;
+ cp->idx = i;
+ cp->irq = irq;
+ priv->mbox_chans[i].con_priv = cp;
+ }
+
+ priv->mbox.dev = dev;
+ priv->mbox.ops = &imx_mu_ops;
+ priv->mbox.chans = priv->mbox_chans;
+ priv->mbox.num_chans = chans;
+ priv->mbox.txdone_irq = true;
+
+ platform_set_drvdata(pdev, priv);
+
+ if (priv->dcfg->init_hw)
+ priv->dcfg->init_hw(priv);
+
+ return mbox_controller_register(&priv->mbox);
+}
+
+static int imx_mu_remove(struct platform_device *pdev)
+{
+ struct imx_mu_priv *priv = platform_get_drvdata(pdev);
+
+ mbox_controller_unregister(&priv->mbox);
+ clk_disable_unprepare(priv->clk);
+
+ return 0;
+}
+
+
+static void imx_mu_init_imx7d_a(struct imx_mu_priv *priv)
+{
+ /* Set default config */
+ imx_mu_write(priv, 0, IMX_MU_xCR);
+}
+
+static const struct imx_mu_cfg imx_mu_cfg_imx7d_a = {
+ .chans = IMX_MU_MAX_CHANS,
+ .init_hw = imx_mu_init_imx7d_a,
+};
+
+static const struct imx_mu_cfg imx_mu_cfg_imx7d_b = {
+ .chans = IMX_MU_MAX_CHANS,
+};
+
+static const struct of_device_id imx_mu_dt_ids[] = {
+ { .compatible = "fsl,imx7s-mu-a", .data = &imx_mu_cfg_imx7d_a },
+ { .compatible = "fsl,imx7s-mu-b", .data = &imx_mu_cfg_imx7d_b },
+ { },
+};
+MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
+
+static struct platform_driver imx_mu_driver = {
+ .probe = imx_mu_probe,
+ .remove = imx_mu_remove,
+ .driver = {
+ .name = "imx_mu",
+ .of_match_table = imx_mu_dt_ids,
+ },
+};
+module_platform_driver(imx_mu_driver);
+
+MODULE_AUTHOR("Oleksij Rempel <o.rempel@pengutronix.de>");
+MODULE_DESCRIPTION("Message Unit driver for i.MX");
+MODULE_LICENSE("GPL v2");
--
2.17.1
^ permalink raw reply related
* [PATCH v2 3/4] ARM: dts: imx7s: add i.MX7 messaging unit support
From: Oleksij Rempel @ 2018-06-15 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615095107.24610-1-o.rempel@pengutronix.de>
Define the Messaging Unit (MU) for i.MX7 in the processor's dtsi.
The respective driver is added in the next commit.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/imx7s.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index d9437e773b37..87a82c1f4dfd 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -1008,6 +1008,24 @@
status = "disabled";
};
+ mu0a: mailbox at 30aa0000 {
+ compatible = "fsl,imx7s-mu-a";
+ reg = <0x30aa0000 0x10000>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX7D_MU_ROOT_CLK>;
+ #mbox-cells = <1>;
+ status = "disabled";
+ };
+
+ mu0b: mailbox at 30ab0000 {
+ compatible = "fsl,imx7s-mu-b";
+ reg = <0x30ab0000 0x10000>;
+ interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX7D_MU_ROOT_CLK>;
+ #mbox-cells = <1>;
+ status = "disabled";
+ };
+
usbotg1: usb at 30b10000 {
compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
reg = <0x30b10000 0x200>;
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/4] dt-bindings: mailbox: provide imx-mailbox documentation
From: Oleksij Rempel @ 2018-06-15 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615095107.24610-1-o.rempel@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
.../bindings/mailbox/imx-mailbox.txt | 35 +++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/imx-mailbox.txt b/Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
new file mode 100644
index 000000000000..1577b86f1206
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
@@ -0,0 +1,35 @@
+i.MX Messaging Unit
+===================
+
+The i.MX Messaging Unit (MU) contains two register sets: "A" and "B". In most
+cases they are accessible from all Processor Units. On one hand, at least for
+mailbox functionality, it makes no difference which application or processor is
+using which set of the MU. On other hand, the register sets for each of the MU
+parts are not identical.
+
+Required properties:
+- compatible : Shell be one of:
+ "fsl,imx7s-mu-a" and "fsl,imx7s-mu-b" for i.MX7S or i.MX7D
+- reg : physical base address of the mailbox and length of
+ memory mapped region.
+- #mbox-cells: Common mailbox binding property to identify the number
+ of cells required for the mailbox specifier. Should be 1.
+- interrupts : The interrupt number
+- clocks : phandle to the input clock.
+
+Example:
+ mu0a: mailbox at 30aa0000 {
+ compatible = "fsl,imx7s-mu-a";
+ reg = <0x30aa0000 0x28>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX7D_MU_ROOT_CLK>;
+ #mbox-cells = <1>;
+ };
+
+ mu0b: mailbox at 30ab0000 {
+ compatible = "fsl,imx7s-mu-b";
+ reg = <0x30ab0000 0x28>;
+ interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX7D_MU_ROOT_CLK>;
+ #mbox-cells = <1>;
+ };
--
2.17.1
^ permalink raw reply related
* [PATCH v2 1/4] clk: imx7d: add IMX7D_MU_ROOT_CLK
From: Oleksij Rempel @ 2018-06-15 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615095107.24610-1-o.rempel@pengutronix.de>
This clock is needed for iMX mailbox driver
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
drivers/clk/imx/clk-imx7d.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 975a20d3cc94..c7159bfac77a 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -795,6 +795,7 @@ static void __init imx7d_clocks_init(struct device_node *ccm_node)
clks[IMX7D_DRAM_ALT_ROOT_CLK] = imx_clk_gate4("dram_alt_root_clk", "dram_alt_post_div", base + 0x4130, 0);
clks[IMX7D_OCOTP_CLK] = imx_clk_gate4("ocotp_clk", "ipg_root_clk", base + 0x4230, 0);
clks[IMX7D_SNVS_CLK] = imx_clk_gate4("snvs_clk", "ipg_root_clk", base + 0x4250, 0);
+ clks[IMX7D_MU_ROOT_CLK] = imx_clk_gate4("mu_root_clk", "ipg_root_clk", base + 0x4270, 0);
clks[IMX7D_CAAM_CLK] = imx_clk_gate4("caam_clk", "ipg_root_clk", base + 0x4240, 0);
clks[IMX7D_USB_HSIC_ROOT_CLK] = imx_clk_gate4("usb_hsic_root_clk", "usb_hsic_post_div", base + 0x4690, 0);
clks[IMX7D_SDMA_CORE_CLK] = imx_clk_gate4("sdma_root_clk", "ahb_root_clk", base + 0x4480, 0);
--
2.17.1
^ permalink raw reply related
* [PATCH v2 0/4] add mailbox support for i.MX7D
From: Oleksij Rempel @ 2018-06-15 9:51 UTC (permalink / raw)
To: linux-arm-kernel
20180615 changes v2:
- DT: use mailbox@ instead of mu@
- DT: change interrupts description
- clk: use imx_clk_gate4 instead of imx_clk_gate2
- imx-mailbox: remove last_tx_done support
- imx-mailbox: fix module description
This patches are providing support for mailbox (Messaging Unit)
for i.MX7D.
Functionality was tested on PHYTEC phyBOARD-Zeta i.MX7D with
Linux running on all cores: ARM Cortex-A7 and ARM Cortex-M4.
Both parts of i.MX messaging Unit are visible for all CPUs available
on i.MX7D. Communication worked independent of MU side in combination
with CPU. For example MU-A used on ARM Cortex-A7 and MU-B used on ARM Cortex-M4
or other ways around.
The question to NXP developers: are there are limitations or
recommendations about MU vs CPU combination? The i.MX7D documentation
talks about "Processor A" and "Processor B". It is not quite clear what
processor it actually is (A7 or M4).
Oleksij Rempel (4):
clk: imx7d: add IMX7D_MU_ROOT_CLK
dt-bindings: mailbox: provide imx-mailbox documentation
ARM: dts: imx7s: add i.MX7 messaging unit support
mailbox: Add support for i.MX7D messaging unit
.../bindings/mailbox/imx-mailbox.txt | 35 +++
arch/arm/boot/dts/imx7s.dtsi | 18 ++
drivers/clk/imx/clk-imx7d.c | 1 +
drivers/mailbox/Kconfig | 6 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/imx-mailbox.c | 288 ++++++++++++++++++
6 files changed, 350 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
create mode 100644 drivers/mailbox/imx-mailbox.c
--
2.17.1
^ permalink raw reply
* [PATCH 4/4] KVM: arm64: Avoid mistaken attempts to save SVE state for vcpus
From: Dave Martin @ 2018-06-15 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87po0szb4h.fsf@linaro.org>
On Fri, Jun 15, 2018 at 09:50:54AM +0100, Alex Benn?e wrote:
>
> Dave Martin <Dave.Martin@arm.com> writes:
> > This patch ensures this my delaying restoration of current's
> > TIF_SVE until after the call to fpsimd_save().
>
> this *by* delaying
No Reviewed-my? ;)
I'll repost for the bh_disable/irqsave changes anyway, so I can fix
typos at low effort.
Cheers
---Dave
^ permalink raw reply
* [linux-sunxi] Re: [PATCH] crypto: sun4i-ss: prevent deadlock on emulated hardware
From: Corentin Labbe @ 2018-06-15 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615090412.xgw35ga5cvc6w3h3@flea>
On Fri, Jun 15, 2018 at 11:04:12AM +0200, Maxime Ripard wrote:
> On Fri, Jun 15, 2018 at 10:15:54AM +0200, Corentin Labbe wrote:
> > On Fri, Jun 15, 2018 at 09:57:54AM +0200, Maxime Ripard wrote:
> > > On Thu, Jun 14, 2018 at 09:36:59PM +0200, Corentin Labbe wrote:
> > > > Running a qemu emulated cubieboard with sun4i-ss driver enabled led to a never
> > > > ending boot.
> > > > This is due to sun4i-ss deadlocked and taking all cpu in an infinite loop.
> > > > Since the crypto hardware is not implemented, all registers are read as 0.
> > > > So sun4i-ss will never progress in any operations. (TX_CNT being always 0)
> > > >
> > > > The first idea is to add a "TX_CNT always zero timeout" but this made cipher/hash loops
> > > > more complex and prevent a case that never happen on real hardware.
> > > >
> > > > The best way to fix is to check at probe time if we run on a virtual
> > > > machine with hardware emulated but non-implemented and prevent
> > > > sun4i-ss to be loaded in that case.
> > > > Letting sun4i-ss to load is useless anyway since all crypto algorithm will be
> > > > disabled since they will fail crypto selftests.
> > > >
> > > > Tested-on: qemu-cubieboard
> > > > Tested-on: cubieboard2
> > > >
> > > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > ---
> > > > drivers/crypto/sunxi-ss/sun4i-ss-core.c | 10 ++++++++++
> > > > 1 file changed, 10 insertions(+)
> > > >
> > > > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > > > index a81d89b3b7d8..a178e80adcf3 100644
> > > > --- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > > > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > > > @@ -341,9 +341,18 @@ static int sun4i_ss_probe(struct platform_device *pdev)
> > > > * I expect to be a sort of Security System Revision number.
> > > > * Since the A80 seems to have an other version of SS
> > > > * this info could be useful
> > > > + * Detect virtual machine with non-implemented hardware
> > > > + * (qemu-cubieboard) by checking the register value after a write to it.
> > > > + * On non-implemented hardware, all registers are read as 0.
> > > > + * On real hardware we should have a value > 0.
> > > > */
> > > > writel(SS_ENABLED, ss->base + SS_CTL);
> > > > v = readl(ss->base + SS_CTL);
> > > > + if (!v) {
> > > > + dev_err(&pdev->dev, "Qemu with non-implemented SS detected.\n");
> > > > + err = -ENODEV;
> > > > + goto error_rst;
> > > > + }
> > >
> > > This is wrong way to tackle the issue. There's multiple reason why
> > > this could happen (for example the device not being clocked, or
> > > maintained in reset). There's nothing specific about qemu here, and
> > > the fundamental issue isn't that the device isn't functional in qemu,
> > > it's that qemu lies about which hardware it can emulate in the DT it
> > > passes to the kernel.
> > >
> > > There's no way this can scale, alone from the fact that qemu should
> > > patch the DT according to what it can do. Not trying to chase after
> > > each and every device that is broken in qemu.
> > >
> > > NAK.
> > >
> >
> > My fix detect also when the device is badly clocked.
>
> In which case, the proper fix is to enable the clock, not throw the
> kernel's arm up in the air.
>
By badly I mean "not clocked" or "with the wrong frequencies".
I could change the clock rate range test to exit (it issue only a warning for now).
But I think this fix detect all cases and still permit someone to play with overclocking/downclocking.
Regards
^ permalink raw reply
* [PATCH v3 0/4] allwinner: a64: add SRAM controller / system control
From: Maxime Ripard @ 2018-06-15 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614153548.9644-1-wens@csie.org>
On Thu, Jun 14, 2018 at 11:35:44PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> This series is the remaining A64 syscon changes from the R40 DWMAC
> series. The series aligns how the A64 system control exports a regmap
> for the sun8i DWMAC driver to access with what we've done for the R40.
>
> Originally the A64 used the generic syscon for this bit of hardware.
> But this block also contains mapping bits for the onboard SRAM, used
> by various peripherals, and other vendor specific bits we may use in
> the future. It is by no means generic. And we already have a device
> tree binding and driver for the SRAM part.
>
> The first patch make the SRAM control device export a regmap, exposing
> a single EMAC control register, for the DWMAC driver to consume.
>
> The second and third patches rename the A64 compatible string to read
> "system control", which is what the block is named in the user manual.
>
> The last patch fixes up the device node, and also adds the lone mappable
> SRAM block, which is needed by the Display Engine.
For the serie:
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
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/20180615/9fbf8015/attachment.sig>
^ permalink raw reply
* [PATCH v3 05/27] docs: Fix some broken references
From: Coly Li @ 2018-06-15 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <29adfe49571ad1395871a4f72154f45ef361297f.1528990947.git.mchehab+samsung@kernel.org>
On 2018/6/15 12:08 AM, Mauro Carvalho Chehab wrote:
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix
>
> Manually checked if the produced result is valid, removing a few
> false-positives.
>
> Acked-by: Takashi Iwai <tiwai@suse.de>
> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> .../admin-guide/kernel-parameters.txt | 4 ++--
> .../bindings/input/rotary-encoder.txt | 2 +-
> Documentation/driver-api/gpio/consumer.rst | 2 +-
> Documentation/kprobes.txt | 4 ++--
> Documentation/trace/coresight.txt | 2 +-
> Documentation/trace/ftrace-uses.rst | 2 +-
> Documentation/trace/histogram.txt | 2 +-
> Documentation/trace/intel_th.rst | 2 +-
> Documentation/trace/tracepoint-analysis.rst | 6 +++---
> Documentation/translations/ja_JP/howto.rst | 4 ++--
> .../translations/zh_CN/magic-number.txt | 4 ++--
> .../zh_CN/video4linux/omap3isp.txt | 4 ++--
> MAINTAINERS | 20 +++++++++----------
> arch/Kconfig | 2 +-
> arch/arm/include/asm/cacheflush.h | 2 +-
> arch/arm64/include/asm/cacheflush.h | 2 +-
> arch/microblaze/include/asm/cacheflush.h | 2 +-
> arch/um/Kconfig.um | 2 +-
> arch/unicore32/include/asm/cacheflush.h | 2 +-
> arch/x86/entry/vsyscall/vsyscall_64.c | 2 +-
> arch/xtensa/include/asm/cacheflush.h | 4 ++--
> block/Kconfig | 2 +-
> certs/Kconfig | 2 +-
> crypto/asymmetric_keys/asymmetric_type.c | 2 +-
> crypto/asymmetric_keys/signature.c | 2 +-
> drivers/char/Kconfig | 2 +-
> drivers/clk/clk.c | 4 ++--
> drivers/clk/ingenic/cgu.h | 2 +-
> drivers/gpu/vga/Kconfig | 2 +-
> drivers/gpu/vga/vgaarb.c | 2 +-
> drivers/input/joystick/Kconfig | 10 +++++-----
> drivers/input/joystick/walkera0701.c | 2 +-
> drivers/input/misc/Kconfig | 4 ++--
> drivers/input/misc/rotary_encoder.c | 2 +-
> drivers/input/mouse/Kconfig | 6 +++---
> drivers/input/mouse/alps.c | 2 +-
> drivers/input/touchscreen/wm97xx-core.c | 2 +-
> drivers/lightnvm/pblk-rb.c | 2 +-
> drivers/md/bcache/Kconfig | 2 +-
> drivers/md/bcache/btree.c | 2 +-
> drivers/md/bcache/extents.c | 2 +-
> drivers/media/dvb-core/dvb_ringbuffer.c | 2 +-
> drivers/media/pci/meye/Kconfig | 2 +-
> drivers/media/platform/pxa_camera.c | 4 ++--
> .../soc_camera/sh_mobile_ceu_camera.c | 2 +-
> drivers/media/radio/Kconfig | 2 +-
> drivers/media/radio/si470x/Kconfig | 2 +-
> drivers/media/usb/dvb-usb-v2/lmedm04.c | 2 +-
> drivers/media/usb/zr364xx/Kconfig | 2 +-
> drivers/parport/Kconfig | 6 +++---
> drivers/staging/media/bcm2048/TODO | 2 +-
> include/keys/asymmetric-subtype.h | 2 +-
> include/keys/asymmetric-type.h | 2 +-
> include/linux/assoc_array.h | 2 +-
> include/linux/assoc_array_priv.h | 2 +-
> include/linux/circ_buf.h | 2 +-
> include/linux/ftrace.h | 2 +-
> include/linux/rculist_nulls.h | 2 +-
> include/uapi/linux/prctl.h | 2 +-
> include/xen/interface/io/kbdif.h | 2 +-
> kernel/cgroup/cpuset.c | 2 +-
> kernel/trace/Kconfig | 16 +++++++--------
> lib/Kconfig | 2 +-
> security/selinux/hooks.c | 2 +-
> sound/core/Kconfig | 4 ++--
> sound/drivers/Kconfig | 4 ++--
> sound/pci/Kconfig | 10 +++++-----
> tools/include/uapi/linux/prctl.h | 2 +-
> tools/lib/api/fs/fs.c | 2 +-
> tools/perf/util/bpf-prologue.c | 2 +-
> .../config/custom-timeline-functions.cfg | 4 ++--
> 71 files changed, 113 insertions(+), 113 deletions(-)
[snip]
> diff --git a/drivers/md/bcache/Kconfig b/drivers/md/bcache/Kconfig
> index 4d200883c505..17bf109c58e9 100644
> --- a/drivers/md/bcache/Kconfig
> +++ b/drivers/md/bcache/Kconfig
> @@ -5,7 +5,7 @@ config BCACHE
> Allows a block device to be used as cache for other devices; uses
> a btree for indexing and the layout is optimized for SSDs.
>
> - See Documentation/bcache.txt for details.
> + See Documentation/admin-guide/bcache.rst for details.
>
> config BCACHE_DEBUG
> bool "Bcache debugging"
> diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
> index 2a0968c04e21..547c9eedc2f4 100644
> --- a/drivers/md/bcache/btree.c
> +++ b/drivers/md/bcache/btree.c
> @@ -18,7 +18,7 @@
> * as keys are inserted we only sort the pages that have not yet been written.
> * When garbage collection is run, we resort the entire node.
> *
> - * All configuration is done via sysfs; see Documentation/bcache.txt.
> + * All configuration is done via sysfs; see Documentation/admin-guide/bcache.rst.
> */
>
> #include "bcache.h"
> diff --git a/drivers/md/bcache/extents.c b/drivers/md/bcache/extents.c
> index c334e6666461..1d096742eb41 100644
> --- a/drivers/md/bcache/extents.c
> +++ b/drivers/md/bcache/extents.c
> @@ -18,7 +18,7 @@
> * as keys are inserted we only sort the pages that have not yet been written.
> * When garbage collection is run, we resort the entire node.
> *
> - * All configuration is done via sysfs; see Documentation/bcache.txt.
> + * All configuration is done via sysfs; see Documentation/admin-guide/bcache.rst.
> */
>
> #include "bcache.h"
For the bcache part, it is good to me.
Reviewed-by: Coly Li <colyli@suse.de>
Thanks for the fix.
Coly Li
^ permalink raw reply
* [PATCH] crypto: sun4i-ss: prevent deadlock on emulated hardware
From: Maxime Ripard @ 2018-06-15 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615081554.GA3047@Red>
On Fri, Jun 15, 2018 at 10:15:54AM +0200, Corentin Labbe wrote:
> On Fri, Jun 15, 2018 at 09:57:54AM +0200, Maxime Ripard wrote:
> > On Thu, Jun 14, 2018 at 09:36:59PM +0200, Corentin Labbe wrote:
> > > Running a qemu emulated cubieboard with sun4i-ss driver enabled led to a never
> > > ending boot.
> > > This is due to sun4i-ss deadlocked and taking all cpu in an infinite loop.
> > > Since the crypto hardware is not implemented, all registers are read as 0.
> > > So sun4i-ss will never progress in any operations. (TX_CNT being always 0)
> > >
> > > The first idea is to add a "TX_CNT always zero timeout" but this made cipher/hash loops
> > > more complex and prevent a case that never happen on real hardware.
> > >
> > > The best way to fix is to check at probe time if we run on a virtual
> > > machine with hardware emulated but non-implemented and prevent
> > > sun4i-ss to be loaded in that case.
> > > Letting sun4i-ss to load is useless anyway since all crypto algorithm will be
> > > disabled since they will fail crypto selftests.
> > >
> > > Tested-on: qemu-cubieboard
> > > Tested-on: cubieboard2
> > >
> > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > ---
> > > drivers/crypto/sunxi-ss/sun4i-ss-core.c | 10 ++++++++++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > > index a81d89b3b7d8..a178e80adcf3 100644
> > > --- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > > @@ -341,9 +341,18 @@ static int sun4i_ss_probe(struct platform_device *pdev)
> > > * I expect to be a sort of Security System Revision number.
> > > * Since the A80 seems to have an other version of SS
> > > * this info could be useful
> > > + * Detect virtual machine with non-implemented hardware
> > > + * (qemu-cubieboard) by checking the register value after a write to it.
> > > + * On non-implemented hardware, all registers are read as 0.
> > > + * On real hardware we should have a value > 0.
> > > */
> > > writel(SS_ENABLED, ss->base + SS_CTL);
> > > v = readl(ss->base + SS_CTL);
> > > + if (!v) {
> > > + dev_err(&pdev->dev, "Qemu with non-implemented SS detected.\n");
> > > + err = -ENODEV;
> > > + goto error_rst;
> > > + }
> >
> > This is wrong way to tackle the issue. There's multiple reason why
> > this could happen (for example the device not being clocked, or
> > maintained in reset). There's nothing specific about qemu here, and
> > the fundamental issue isn't that the device isn't functional in qemu,
> > it's that qemu lies about which hardware it can emulate in the DT it
> > passes to the kernel.
> >
> > There's no way this can scale, alone from the fact that qemu should
> > patch the DT according to what it can do. Not trying to chase after
> > each and every device that is broken in qemu.
> >
> > NAK.
> >
>
> My fix detect also when the device is badly clocked.
In which case, the proper fix is to enable the clock, not throw the
kernel's arm up in the air.
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/20180615/6969fcc6/attachment-0001.sig>
^ permalink raw reply
* [PATCH 4/4] arm: dts: add support for Laird SOM60 module and DVK boards
From: Ben Whitten @ 2018-06-15 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e1f730ca-da21-1756-b781-b6552fb28101@microchip.com>
Thanks all for the reviews and comments, I will work on a new series.
> On 14/06/2018 at 10:51, Ben Whitten wrote:
> > Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> > ---
> > arch/arm/boot/dts/Makefile | 3 +-
> > arch/arm/boot/dts/at91-dvk_som60.dts | 95 +++++++++++
> > arch/arm/boot/dts/at91-dvk_su60_somc.dtsi | 159
> ++++++++++++++++++
> > arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi | 96 +++++++++++
> > arch/arm/boot/dts/at91-som60.dtsi | 229
> ++++++++++++++++++++++++++
> > 5 files changed, 581 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/boot/dts/at91-dvk_som60.dts
> > create mode 100644 arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
> > create mode 100644 arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
> > create mode 100644 arch/arm/boot/dts/at91-som60.dtsi
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 486ab59..4d3d9ca 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -63,7 +63,8 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
> > at91-sama5d4ek.dtb \
> > at91-vinco.dtb \
>
> About where you added dtbs...
>
> > at91-wb50n.dtb \
> > - at91-gatwick.dtb
> > + at91-gatwick.dtb \
> > + at91-dvk_som60.dtb
>
> 1/ As they are based on sama5d3, I would like to see them between
> "at91-sama5d2_xplained.dtb" and "sama5d31ek.dtb"
> 2/ within this range, please sort all these 4 alphabetically
> 3/ don't laugh at me, I try to deal with our historical way of "sorting"
> entries in this Makefile for AT91... ;-)
>
> BTW, I realize now that your "at91-wb45n.dtb" entry from patch 1 should
> go just after the "at91-kizboxmini.dts" (alphabetical order in
> at91sam9x5 "location").
>
>
> > dtb-$(CONFIG_ARCH_ATLAS6) += \
> > atlas6-evb.dtb
> > dtb-$(CONFIG_ARCH_ATLAS7) += \
> > diff --git a/arch/arm/boot/dts/at91-dvk_som60.dts
> b/arch/arm/boot/dts/at91-dvk_som60.dts
> > new file mode 100644
> > index 0000000..ededd5b
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/at91-dvk_som60.dts
> > @@ -0,0 +1,95 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * at91-dvk_som60.dts - Device Tree file for the DVK SOM60 board
> > + *
> > + * Copyright (C) 2018 Laird,
> > + * 2018 Ben Whitten <ben.whitten@lairdtech.com>
> > + *
> > + */
> > +/dts-v1/;
> > +#include "at91-som60.dtsi"
> > +#include "at91-dvk_su60_somc.dtsi"
> > +#include "at91-dvk_su60_somc_lcm.dtsi"
> > +
> > +/ {
> > + model = "Laird DVK SOM60";
> > + compatible = "laird,dvk-som60", "laird,som60", "atmel,sama5d36",
> "atmel,sama5d3", "atmel,sama5";
> > +
> > + chosen {
> > + stdout-path = &dbgu;
> > + tick-timer = &pit;
> > + };
> > +};
> > +
> > +&mmc0 {
> > + status = "okay";
> > +};
> > +
> > +&spi0 {
> > + status = "okay";
> > +};
> > +
> > +&ssc0 {
> > + status = "okay";
> > +};
> > +
> > +&i2c0 {
> > + status = "okay";
> > +};
> > +
> > +&i2c1 {
> > + status = "okay";
> > +};
> > +
> > +&usart1 {
> > + status = "okay";
> > +};
> > +
> > +&usart2 {
> > + status = "okay";
> > +};
> > +
> > +&usart3 {
> > + status = "okay";
> > +};
> > +
> > +&uart0 {
> > + status = "okay";
> > +};
> > +
> > +&dbgu {
> > + status = "okay";
> > +};
> > +
> > +&pit {
> > + status = "okay";
> > +};
> > +
> > +&adc0 {
> > + status = "okay";
> > +};
> > +
> > +&can1 {
> > + status = "okay";
> > +};
> > +
> > +&macb0 {
> > + status = "okay";
> > +};
> > +
> > +&macb1 {
> > + status = "okay";
> > +};
> > +
> > +&usb0 {
> > + status = "okay";
> > +};
> > +
> > +&usb1 {
> > + status = "okay";
> > +};
> > +
> > +&usb2 {
> > + status = "okay";
> > +};
> > +
> > diff --git a/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
> b/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
> > new file mode 100644
> > index 0000000..6031c2f
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
> > @@ -0,0 +1,159 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * at91-dvk_su60_somc.dtsi - Device Tree file for the DVK SOM60 base
> board
> > + *
> > + * Copyright (C) 2018 Laird,
> > + * 2018 Ben Whitten <ben.whitten@lairdtech.com>
> > + *
> > + */
> > +
> > +/ {
> > + sound {
> > + compatible = "atmel,asoc-wm8904";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_pck2_as_audio_mck>;
> > +
> > + atmel,model = "wm8904 @ DVK-SOM60";
> > + atmel,audio-routing =
> > + "Headphone Jack", "HPOUTL",
> > + "Headphone Jack", "HPOUTR",
> > + "IN2L", "Line In Jack",
> > + "IN2R", "Line In Jack",
> > + "Mic", "MICBIAS",
> > + "IN1L", "Mic";
> > +
> > + atmel,ssc-controller = <&ssc0>;
> > + atmel,audio-codec = <&wm8904>;
> > +
> > + status = "okay";
> > + };
> > +};
> > +
> > +&mmc0 {
> > + status = "okay";
> > +
> > + pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3
> &pinctrl_mmc0_cd>;
> > + slot at 0 {
> > + bus-width = <4>;
> > + cd-gpios = <&pioE 31 GPIO_ACTIVE_HIGH>;
> > + cd-inverted;
> > + };
> > +};
> > +
> > +&spi0 {
> > + status = "okay";
> > +
> > + /* spi0.0: 4M Flash Macronix MX25R4035FM1IL0 */
> > + spi-flash at 0 {
> > + compatible = "mxicy,mx25u4035", "jedec,spi-nor";
> > + spi-max-frequency = <33000000>;
> > + reg = <0>;
> > + };
> > +};
> > +
> > +&ssc0 {
> > + atmel,clk-from-rk-pin;
> > + status = "okay";
> > +};
> > +
> > +&i2c0 {
> > + status = "okay";
> > +
> > + wm8904: wm8904 at 1a {
> > + compatible = "wlf,wm8904";
> > + reg = <0x1a>;
> > + clocks = <&pck2>;
> > + clock-names = "mclk";
> > + };
> > +};
> > +
> > +&i2c1 {
> > + status = "okay";
> > +
> > + eeprom at 87 {
> > + compatible = "giantec,24c32";
>
> It must work, however...
>
> I read in recent patches on dts directory that :
>
> "We now require all at24 users to use the "atmel,<model>" fallback in
> device tree for different manufacturers."
>
> Moreover, I don't see giantec in the vendor prefix list.
I see, I have added parts which are compatible and made note what the real
part is, should I typically be adding the real part to the compatible list and
update vendor prefixes if necessary?
>
> > + reg = <87>;
> > + pagesize = <32>;
> > + };
> > +};
> > +
> > +&usart1 {
> > + status = "okay";
> > +};
> > +
> > +&usart2 {
> > + status = "okay";
> > +};
> > +
> > +&usart3 {
> > + status = "okay";
> > +};
> > +
> > +&uart0 {
> > + status = "okay";
> > +};
> > +
> > +&dbgu {
> > + status = "okay";
> > +};
> > +
> > +&pit {
> > + status = "okay";
> > +};
> > +
> > +&adc0 {
> > + status = "okay";
> > +};
> > +
> > +&can1 {
> > + status = "okay";
> > +};
> > +
> > +&macb0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + status = "okay";
> > +
> > + ethernet-phy at 7 {
> > + reg = <7>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_geth_int>;
> > + interrupt-parent = <&pioB>;
> > + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> > + txen-skew-ps = <800>;
> > + txc-skew-ps = <3000>;
> > + rxdv-skew-ps = <400>;
> > + rxc-skew-ps = <3000>;
> > + rxd0-skew-ps = <400>;
> > + rxd1-skew-ps = <400>;
> > + rxd2-skew-ps = <400>;
> > + rxd3-skew-ps = <400>;
> > + };
> > +};
> > +
> > +&macb1 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + status = "okay";
> > +
> > + ethernet-phy at 1 {
> > + reg = <1>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_eth_int>;
> > + interrupt-parent = <&pioC>;
> > + interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
> > + };
> > +};
> > +
> > +&usb0 {
> > + status = "okay";
> > +};
> > +
> > +&usb1 {
> > + status = "okay";
> > +};
> > +
> > +&usb2 {
> > + status = "okay";
> > +};
> > +
> > diff --git a/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
> b/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
> > new file mode 100644
> > index 0000000..d98c644
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
> > @@ -0,0 +1,96 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * at91-dvk_su60_somc_lcm.dtsi - Device Tree file for the DVK SOM60 LCD
> board
> > + *
> > + * Copyright (C) 2018 Laird,
> > + * 2018 Ben Whitten <ben.whitten@lairdtech.com>
> > + *
> > + */
> > +
> > +/ {
> > + ahb {
> > + apb {
> > + pinctrl at fffff200 {
> > + board {
> > + pinctrl_lcd_ctp_int: lcd_ctp_int {
> > + atmel,pins =
> > + <AT91_PIOC 28
> AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
> > + };
> > + };
> > + };
> > + };
> > + };
> > +
> > + backlight: backlight {
> > + compatible = "pwm-backlight";
> > + pwms = <&hlcdc_pwm 0 50000 0>;
> > + brightness-levels = <0 4 8 16 32 64 128 255>;
> > + default-brightness-level = <6>;
> > + status = "okay";
> > + };
> > +
> > + panel: panel {
> > + /* Actually Winstar WF70GTIAGDNG0 */
> > + compatible = "innolux,at070tn92", "simple-panel";
> > + backlight = <&backlight>;
> > + power-supply = <&vcc_lcd_reg>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + status = "okay";
> > +
> > + port at 0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + panel_input: endpoint at 0 {
> > + reg = <0>;
> > + remote-endpoint = <&hlcdc_panel_output>;
> > + };
> > + };
> > + };
> > +
> > + vcc_lcd_reg: fixedregulator_lcd {
> > + compatible = "regulator-fixed";
> > + regulator-name = "VCC LCM";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + status = "okay";
> > + };
> > +};
> > +
> > +&i2c1 {
> > + status = "okay";
> > +
> > + ft5426 at 56 {
> > + /* Actually FT5426 */
> > + compatible = "edt,edt-ft5406";
> > + reg = <56>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lcd_ctp_int>;
> > +
> > + interrupt-parent = <&pioC>;
> > + interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
> > +
> > + touchscreen-size-x = <800>;
> > + touchscreen-size-y = <480>;
> > + };
> > +};
> > +
> > +&hlcdc {
> > + status = "okay";
> > +
> > + hlcdc-display-controller {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
> > +
> > + port at 0 {
> > + hlcdc_panel_output: endpoint at 0 {
> > + reg = <0>;
> > + remote-endpoint = <&panel_input>;
> > + };
> > + };
> > + };
> > +};
> > diff --git a/arch/arm/boot/dts/at91-som60.dtsi b/arch/arm/boot/dts/at91-
> som60.dtsi
> > new file mode 100644
> > index 0000000..1843284
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/at91-som60.dtsi
> > @@ -0,0 +1,229 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * at91-som60.dtsi - Device Tree file for the SOM60 module
> > + *
> > + * Copyright (C) 2018 Laird,
> > + * 2018 Ben Whitten <ben.whitten@lairdtech.com>
> > + *
> > + */
> > +#include "sama5d36.dtsi"
> > +
> > +/ {
> > + model = "Laird SOM60";
> > + compatible = "laird,som60", "atmel,sama5d36", "atmel,sama5d3",
> "atmel,sama5";
> > +
> > + chosen {
> > + stdout-path = &dbgu;
> > + };
> > +
> > + memory {
> > + reg = <0x20000000 0x8000000>;
> > + };
> > +
> > + clocks {
> > + slow_xtal {
> > + clock-frequency = <32768>;
> > + };
> > +
> > + main_xtal {
> > + clock-frequency = <12000000>;
> > + };
> > + };
> > +
> > + ahb {
> > + apb {
> > + pinctrl at fffff200 {
> > + board {
> > + pinctrl_mmc0_cd: mmc0_cd {
> > + atmel,pins =
> > + <AT91_PIOE 31
> AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
> > + };
> > +
> > + pinctrl_mmc0_en: mmc0_en {
> > + atmel,pins =
> > + <AT91_PIOE 30
> AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
> > + };
> > +
> > + pinctrl_nand0_wp: nand0_wp {
> > + atmel,pins =
> > + <AT91_PIOE 14
> AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
> > + };
> > +
> > + pinctrl_usb_vbus: usb_vbus {
> > + atmel,pins =
> > + <AT91_PIOE 20
> AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* Conflicts with USART2_SCK
> */
> > + };
> > +
> > + pinctrl_usart2_sck: usart2_sck {
> > + atmel,pins =
> > + <AT91_PIOE 20
> AT91_PERIPH_B AT91_PINCTRL_NONE>; /* Conflicts with USB_VBUS */
> > + };
> > +
> > + pinctrl_usb_oc: usb_oc {
> > + atmel,pins =
> > + <AT91_PIOE 15
> AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* Conflicts with
> USART3_SCK */
> > + };
> > +
> > + pinctrl_usart3_sck: usart3_sck {
> > + atmel,pins =
> > + <AT91_PIOE 15
> AT91_PERIPH_B AT91_PINCTRL_NONE>; /* Conflicts with USB_OC */
> > + };
> > +
> > + pinctrl_usba_vbus: usba_vbus {
> > + atmel,pins =
> > + <AT91_PIOC 14
> AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
> > + };
> > +
> > + pinctrl_geth_int: geth_int {
> > + atmel,pins =
> > + <AT91_PIOB 25
> AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* Conflicts with
> USART1_SCK */
> > + };
> > +
> > + pinctrl_usart1_sck: usart1_sck {
> > + atmel,pins =
> > + <AT91_PIOB 25
> AT91_PERIPH_A AT91_PINCTRL_NONE>; /* Conflicts with GETH_INT */
> > + };
> > +
> > + pinctrl_eth_int: eth_int {
> > + atmel,pins =
> > + <AT91_PIOC 10
> AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
> > + };
> > +
> > + pinctrl_pck2_as_audio_mck:
> pck2_as_audio_mck {
> > + atmel,pins =
> > + <AT91_PIOC 15
> AT91_PERIPH_B AT91_PINCTRL_NONE>;
> > + };
> > + };
> > + };
> > + };
> > + };
> > +};
> > +
> > +&mmc0 {
> > + slot at 0 {
> > + reg = <0>;
> > + bus-width = <8>;
> > + };
> > +};
> > +
> > +&mmc1 {
> > + status = "okay";
> > + slot at 0 {
> > + reg = <0>;
> > + bus-width = <4>;
> > + };
> > +};
> > +
> > +&spi0 {
> > + cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
> > +};
> > +
> > +&usart0 {
> > + atmel,use-dma-rx;
> > + atmel,use-dma-tx;
> > + status = "okay";
> > + pinctrl-0 = <&pinctrl_usart0 &pinctrl_usart0_rts_cts>;
> > +};
> > +
> > +&usart1 {
> > + pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
> > +};
> > +
> > +&usart2 {
> > + pinctrl-0 = <&pinctrl_usart2 &pinctrl_usart2_rts_cts>;
> > +};
> > +
> > +&usart3 {
> > + pinctrl-0 = <&pinctrl_usart3 &pinctrl_usart3_rts_cts>;
> > +};
> > +
> > +&adc0 {
> > + pinctrl-0 = <
> > + &pinctrl_adc0_adtrg
> > + &pinctrl_adc0_ad0
> > + &pinctrl_adc0_ad1
> > + &pinctrl_adc0_ad2
> > + &pinctrl_adc0_ad3
> > + &pinctrl_adc0_ad4
> > + &pinctrl_adc0_ad5
> > + >;
> > +};
> > +
> > +&macb0 {
> > + phy-mode = "rgmii";
> > +};
> > +
> > +&macb1 {
> > + phy-mode = "rmii";
> > +};
> > +
> > +
> > +&ebi {
> > + pinctrl-0 = <&pinctrl_ebi_nand_addr>;
> > + pinctrl-names = "default";
> > + status = "okay";
> > +};
> > +
> > +&nand_controller {
> > + status = "okay";
> > +
> > + nand: nand at 3 {
> > + reg = <0x3 0x0 0x2>;
> > + atmel,rb = <0>;
> > + nand-bus-width = <8>;
> > + nand-ecc-mode = "hw";
> > + nand-ecc-strength = <8>;
> > + nand-ecc-step-size = <512>;
> > + nand-on-flash-bbt;
> > + label = "atmel_nand";
> > +
> > + partitions {
> > + compatible = "fixed-partitions";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + ubootspl at 0 {
> > + label = "u-boot-spl";
> > + reg = <0x0 0x20000>;
> > + };
> > +
> > + uboot at 20000 {
> > + label = "u-boot";
> > + reg = <0x20000 0x80000>;
> > + };
> > +
> > + ubootenv at a0000 {
> > + label = "u-boot-env";
> > + reg = <0xa0000 0x20000>;
> > + };
> > +
> > + ubootenv at c0000 {
> > + label = "u-boot-env";
> > + reg = <0xc0000 0x20000>;
> > + };
> > +
> > + ubi at e0000 {
> > + label = "ubi";
> > + reg = <0xe0000 0xfe00000>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&usb0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usba_vbus>;
> > + atmel,vbus-gpio = <&pioC 14 GPIO_ACTIVE_HIGH>;
> > +};
> > +
> > +&usb1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usb_vbus &pinctrl_usb_oc>;
> > + num-ports = <3>;
> > + atmel,vbus-gpio = <0
> > + &pioE 20 GPIO_ACTIVE_HIGH
> > + 0>;
> > + atmel,oc-gpio = <0
> > + &pioE 15 GPIO_ACTIVE_LOW
> > + 0>;
> > +};
> >
>
>
> --
> Nicolas Ferre
^ permalink raw reply
* [PATCH v3 6/7] mmc: sunxi: Add runtime_pm support
From: Ulf Hansson @ 2018-06-15 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1caa07d2-17ad-18aa-9216-037c06b36281@arm.com>
On 14 June 2018 at 16:11, Marc Zyngier <marc.zyngier@arm.com> wrote:
> Hi Maxime,
>
> On 16/04/18 15:23, Maxime Ripard wrote:
>> So far, even if our card was not in use, we didn't shut down our MMC
>> controller, which meant that it was still active and clocking the bus.
>>
>> While this obviously means that we could save some power there, it also
>> creates issues when it comes to EMC control since we'll have a perfect peak
>> at the card clock rate.
>>
>> Let's implement runtime_pm with autosuspend so that we will shut down the
>> controller when it's not been in use for quite some time.
>>
>> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
>> ---
>> drivers/mmc/host/sunxi-mmc.c | 48 +++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 48 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>> index 0165da0d022a..0253deb153a4 100644
>> --- a/drivers/mmc/host/sunxi-mmc.c
>> +++ b/drivers/mmc/host/sunxi-mmc.c
>> @@ -35,6 +35,7 @@
>> #include <linux/of_gpio.h>
>> #include <linux/of_platform.h>
>> #include <linux/platform_device.h>
>> +#include <linux/pm_runtime.h>
>> #include <linux/regulator/consumer.h>
>> #include <linux/reset.h>
>> #include <linux/scatterlist.h>
>> @@ -969,6 +970,9 @@ static void sunxi_mmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
>> unsigned long flags;
>> u32 imask;
>>
>> + if (enable)
>> + pm_runtime_get_noresume(host->dev);
>> +
>> spin_lock_irqsave(&host->lock, flags);
>>
>> imask = mmc_readl(host, REG_IMASK);
>> @@ -981,6 +985,9 @@ static void sunxi_mmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
>> }
>> mmc_writel(host, REG_IMASK, imask);
>> spin_unlock_irqrestore(&host->lock, flags);
>> +
>> + if (!enable)
>> + pm_runtime_put_noidle(host->mmc->parent);
>> }
>>
>> static void sunxi_mmc_hw_reset(struct mmc_host *mmc)
>> @@ -1394,6 +1401,11 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
>> if (ret)
>> goto error_free_dma;
>>
>> + pm_runtime_set_active(&pdev->dev);
>> + pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
>> + pm_runtime_use_autosuspend(&pdev->dev);
>> + pm_runtime_enable(&pdev->dev);
>> +
>> ret = mmc_add_host(mmc);
>> if (ret)
>> goto error_free_dma;
>> @@ -1414,6 +1426,7 @@ static int sunxi_mmc_remove(struct platform_device *pdev)
>> struct sunxi_mmc_host *host = mmc_priv(mmc);
>>
>> mmc_remove_host(mmc);
>> + pm_runtime_force_suspend(&pdev->dev);
>> disable_irq(host->irq);
>> sunxi_mmc_disable(host);
>> dma_free_coherent(&pdev->dev, PAGE_SIZE, host->sg_cpu, host->sg_dma);
>> @@ -1422,10 +1435,45 @@ static int sunxi_mmc_remove(struct platform_device *pdev)
>> return 0;
>> }
>>
>> +static int sunxi_mmc_runtime_resume(struct device *dev)
>> +{
>> + struct mmc_host *mmc = dev_get_drvdata(dev);
>> + struct sunxi_mmc_host *host = mmc_priv(mmc);
>> + int ret;
>> +
>> + ret = sunxi_mmc_enable(host);
>> + if (ret)
>> + return ret;
>> +
>> + sunxi_mmc_init_host(host);
>> + sunxi_mmc_set_bus_width(host, mmc->ios.bus_width);
>> + sunxi_mmc_set_clk(host, &mmc->ios);
>> +
>> + return 0;
>> +}
>> +
>> +static int sunxi_mmc_runtime_suspend(struct device *dev)
>> +{
>> + struct mmc_host *mmc = dev_get_drvdata(dev);
>> + struct sunxi_mmc_host *host = mmc_priv(mmc);
>> +
>> + sunxi_mmc_reset_host(host);
>> + sunxi_mmc_disable(host);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct dev_pm_ops sunxi_mmc_pm_ops = {
>> + SET_RUNTIME_PM_OPS(sunxi_mmc_runtime_suspend,
>> + sunxi_mmc_runtime_resume,
>> + NULL)
>> +};
>> +
>> static struct platform_driver sunxi_mmc_driver = {
>> .driver = {
>> .name = "sunxi-mmc",
>> .of_match_table = of_match_ptr(sunxi_mmc_of_match),
>> + .pm = &sunxi_mmc_pm_ops,
>> },
>> .probe = sunxi_mmc_probe,
>> .remove = sunxi_mmc_remove,
>>
>
> This patch has the unfortunate impact of killing my A20 system
> (cubietruck), as of 9a8e1e8cc2c02c57c4e941651a8481a633506c91:
>
> [...]
> [ 3.286649] NET: Registered protocol family 10
> [ 3.291898] mmcblk0: p1
> [ 3.295297] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
> [ 3.302773] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
> [ 3.305787] Segment Routing with IPv6
> [ 3.312225] mip6: Mobile IPv6
> [ 3.316166] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> [ 3.316246] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
> [ 3.323721] ip6_gre: GRE over IPv6 tunneling driver
> [ 3.333954] NET: Registered protocol family 17
> [ 3.338837] 9pnet: Installing 9P2000 support
> [ 3.343379] NET: Registered protocol family 37
> [ 3.347885] Key type dns_resolver registered
> [ 3.352214] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
> [ 3.352217] openvswitch: Open vSwitch switching datapath
> [ 3.352620] mpls_gso: MPLS GSO support
> [ 3.367001] ThumbEE CPU extension supported.
>
> and that's where it stops. No message, just a hard lockup (I suppose
> that both the CPUs are trying to access some device that is now not
> clocked).
Seems like a reasonable analyze.
>
> With a working kernel, I see SATA and the wifi SDIO being probed.
>
> Happy to help testing stuff if you have any idea.
In principle I would start with avoiding having the sunxi-mmc driver
to probe. Or bail out early in probe, whichever is the easiest for
you.
The point is, if the sunxi-mmc driver doesn't even enable its clock,
it would be interesting to see if there are other that depends on it.
One could also play with clk_disable_unused(), the
late_initcall_sync(), which can be turned off with the module
parameter "clk_ignore_unused".
Anyway, to hide/fix the problem for now, we could add a call to
pm_runtime_get_noresume() before the sunxi-driver calls
pm_runtime_enable().
Kind regards
Uffe
^ permalink raw reply
* [PATCH v3 1/3] media: v4l2-ctrl: Change control for VP8 profile to menu control
From: Hans Verkuil @ 2018-06-15 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614074652.162796-2-keiichiw@chromium.org>
On 14/06/18 09:46, Keiichi Watanabe wrote:
> Add a menu control V4L2_CID_MPEG_VIDEO_VP8_PROFILE for VP8 profile and
> make V4L2_CID_MPEG_VIDEO_VPX_PROFILE an alias of it. This new control
> is used to select a desired profile for VP8 encoder, and query for
> supported profiles by VP8 encoder/decoder.
>
> Though we have originally a control V4L2_CID_MPEG_VIDEO_VPX_PROFILE and its name
> contains 'VPX', it works only for VP8 because supported profiles usually differ
> between VP8 and VP9. In addition, this contorol cannot be used for querying
typo: contorol -> control
> since it is not a menu control but an integer control, which cannot return an
> arbitrary set of supported profiles.
>
> The new control V4L2_CID_MPEG_VIDEO_VP8_PROFILE is a menu control as with
> controls for other codec profiles. (e.g. H264)
>
> In addition, this patch also fixes the use of
> V4L2_CID_MPEG_VIDEO_VPX_PROFILE in drivers of Qualcomm's venus and
> Samsung's s5p-mfc.
>
> Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
> ---
> .../media/uapi/v4l/extended-controls.rst | 27 ++++++++++++++++---
> drivers/media/platform/qcom/venus/core.h | 2 +-
> .../media/platform/qcom/venus/hfi_helper.h | 12 ++++-----
> .../media/platform/qcom/venus/vdec_ctrls.c | 10 ++++---
> drivers/media/platform/qcom/venus/venc.c | 14 +++++-----
> .../media/platform/qcom/venus/venc_ctrls.c | 12 +++++----
> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 15 +++++------
> drivers/media/v4l2-core/v4l2-ctrls.c | 12 ++++++++-
> include/uapi/linux/v4l2-controls.h | 11 +++++++-
> 9 files changed, 79 insertions(+), 36 deletions(-)
>
> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
> index 03931f9b1285..de99eafb0872 100644
> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> @@ -1955,9 +1955,30 @@ enum v4l2_vp8_golden_frame_sel -
> ``V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (integer)``
> Quantization parameter for a P frame for VP8.
>
> -``V4L2_CID_MPEG_VIDEO_VPX_PROFILE (integer)``
> - Select the desired profile for VPx encoder. Acceptable values are 0,
> - 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
> +.. _v4l2-mpeg-video-vp8-profile:
> +
> +``V4L2_CID_MPEG_VIDEO_VP8_PROFILE``
> + (enum)
> +
> +enum v4l2_mpeg_video_vp8_profile -
> + This control allows to select the profile for VP8 encoder.
> + This is also used to enumerate supported profiles by VP8 encoder or decoder.
> + Possible values are:
> +
> +
> +
One empty line is enough.
> +.. flat-table::
> + :header-rows: 0
> + :stub-columns: 0
> +
> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_0``
> + - Profile 0
> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_1``
> + - Profile 1
> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_2``
> + - Profile 2
> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_3``
> + - Profile 3
>
>
> High Efficiency Video Coding (HEVC/H.265) Control Reference
> diff --git a/drivers/media/platform/qcom/venus/core.h b/drivers/media/platform/qcom/venus/core.h
> index 0360d295f4c8..f242e7f9f6a2 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -159,7 +159,7 @@ struct venc_controls {
> struct {
> u32 mpeg4;
> u32 h264;
> - u32 vpx;
> + u32 vp8;
> } profile;
> struct {
> u32 mpeg4;
> diff --git a/drivers/media/platform/qcom/venus/hfi_helper.h b/drivers/media/platform/qcom/venus/hfi_helper.h
> index 55d8eb21403a..07bf49dd2ec6 100644
> --- a/drivers/media/platform/qcom/venus/hfi_helper.h
> +++ b/drivers/media/platform/qcom/venus/hfi_helper.h
> @@ -333,12 +333,12 @@
> #define HFI_VC1_LEVEL_3 0x00000040
> #define HFI_VC1_LEVEL_4 0x00000080
>
> -#define HFI_VPX_PROFILE_SIMPLE 0x00000001
> -#define HFI_VPX_PROFILE_ADVANCED 0x00000002
> -#define HFI_VPX_PROFILE_VERSION_0 0x00000004
> -#define HFI_VPX_PROFILE_VERSION_1 0x00000008
> -#define HFI_VPX_PROFILE_VERSION_2 0x00000010
> -#define HFI_VPX_PROFILE_VERSION_3 0x00000020
> +#define HFI_VP8_PROFILE_SIMPLE 0x00000001
> +#define HFI_VP8_PROFILE_ADVANCED 0x00000002
> +#define HFI_VP8_PROFILE_VERSION_0 0x00000004
> +#define HFI_VP8_PROFILE_VERSION_1 0x00000008
> +#define HFI_VP8_PROFILE_VERSION_2 0x00000010
> +#define HFI_VP8_PROFILE_VERSION_3 0x00000020
>
> #define HFI_DIVX_FORMAT_4 0x1
> #define HFI_DIVX_FORMAT_5 0x2
> diff --git a/drivers/media/platform/qcom/venus/vdec_ctrls.c b/drivers/media/platform/qcom/venus/vdec_ctrls.c
> index 032839bbc967..f4604b0cd57e 100644
> --- a/drivers/media/platform/qcom/venus/vdec_ctrls.c
> +++ b/drivers/media/platform/qcom/venus/vdec_ctrls.c
> @@ -29,7 +29,7 @@ static int vdec_op_s_ctrl(struct v4l2_ctrl *ctrl)
> break;
> case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
> case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
> - case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
> ctr->profile = ctrl->val;
> break;
> case V4L2_CID_MPEG_VIDEO_H264_LEVEL:
> @@ -54,7 +54,7 @@ static int vdec_op_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
> switch (ctrl->id) {
> case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
> case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
> - case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
> ret = hfi_session_get_property(inst, ptype, &hprop);
> if (!ret)
> ctr->profile = hprop.profile_level.profile;
> @@ -130,8 +130,10 @@ int vdec_ctrl_init(struct venus_inst *inst)
> if (ctrl)
> ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
>
> - ctrl = v4l2_ctrl_new_std(&inst->ctrl_handler, &vdec_ctrl_ops,
> - V4L2_CID_MPEG_VIDEO_VPX_PROFILE, 0, 3, 1, 0);
> + ctrl = v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &vdec_ctrl_ops,
> + V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
> + V4L2_MPEG_VIDEO_VP8_PROFILE_3,
> + 0, V4L2_MPEG_VIDEO_VP8_PROFILE_0);
> if (ctrl)
> ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
>
> diff --git a/drivers/media/platform/qcom/venus/venc.c b/drivers/media/platform/qcom/venus/venc.c
> index 6b2ce479584e..aa54dd005c3e 100644
> --- a/drivers/media/platform/qcom/venus/venc.c
> +++ b/drivers/media/platform/qcom/venus/venc.c
> @@ -223,17 +223,17 @@ static int venc_v4l2_to_hfi(int id, int value)
> case V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CABAC:
> return HFI_H264_ENTROPY_CABAC;
> }
> - case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
> switch (value) {
> case 0:
> default:
> - return HFI_VPX_PROFILE_VERSION_0;
> + return HFI_VP8_PROFILE_VERSION_0;
> case 1:
> - return HFI_VPX_PROFILE_VERSION_1;
> + return HFI_VP8_PROFILE_VERSION_1;
> case 2:
> - return HFI_VPX_PROFILE_VERSION_2;
> + return HFI_VP8_PROFILE_VERSION_2;
> case 3:
> - return HFI_VPX_PROFILE_VERSION_3;
> + return HFI_VP8_PROFILE_VERSION_3;
> }
> case V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_MODE:
> switch (value) {
> @@ -756,8 +756,8 @@ static int venc_set_properties(struct venus_inst *inst)
> level = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_H264_LEVEL,
> ctr->level.h264);
> } else if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_VP8) {
> - profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_VPX_PROFILE,
> - ctr->profile.vpx);
> + profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
> + ctr->profile.vp8);
> level = 0;
> } else if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_MPEG4) {
> profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE,
> diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c b/drivers/media/platform/qcom/venus/venc_ctrls.c
> index 21e938a28662..e5162b78609d 100644
> --- a/drivers/media/platform/qcom/venus/venc_ctrls.c
> +++ b/drivers/media/platform/qcom/venus/venc_ctrls.c
> @@ -101,8 +101,8 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
> case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
> ctr->profile.h264 = ctrl->val;
> break;
> - case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
> - ctr->profile.vpx = ctrl->val;
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
> + ctr->profile.vp8 = ctrl->val;
> break;
> case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
> ctr->level.mpeg4 = ctrl->val;
> @@ -248,6 +248,11 @@ int venc_ctrl_init(struct venus_inst *inst)
> V4L2_MPEG_VIDEO_MULTI_SICE_MODE_MAX_BYTES,
> 0, V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_SINGLE);
>
> + v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &venc_ctrl_ops,
> + V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
> + V4L2_MPEG_VIDEO_VP8_PROFILE_3,
> + 0, V4L2_MPEG_VIDEO_VP8_PROFILE_0);
> +
> v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
> V4L2_CID_MPEG_VIDEO_BITRATE, BITRATE_MIN, BITRATE_MAX,
> BITRATE_STEP, BITRATE_DEFAULT);
> @@ -256,9 +261,6 @@ int venc_ctrl_init(struct venus_inst *inst)
> V4L2_CID_MPEG_VIDEO_BITRATE_PEAK, BITRATE_MIN, BITRATE_MAX,
> BITRATE_STEP, BITRATE_DEFAULT_PEAK);
>
> - v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
> - V4L2_CID_MPEG_VIDEO_VPX_PROFILE, 0, 3, 1, 0);
> -
> v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
> V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP, 1, 51, 1, 26);
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> index 570f391f2cfd..3ad4f5073002 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> @@ -692,12 +692,12 @@ static struct mfc_control controls[] = {
> .default_value = 10,
> },
> {
> - .id = V4L2_CID_MPEG_VIDEO_VPX_PROFILE,
> - .type = V4L2_CTRL_TYPE_INTEGER,
> - .minimum = 0,
> - .maximum = 3,
> - .step = 1,
> - .default_value = 0,
> + .id = V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
> + .type = V4L2_CTRL_TYPE_MENU,
> + .minimum = V4L2_MPEG_VIDEO_VP8_PROFILE_0,
> + .maximum = V4L2_MPEG_VIDEO_VP8_PROFILE_3,
> + .default_value = V4L2_MPEG_VIDEO_VP8_PROFILE_0,
> + .menu_skip_mask = 0,
> },
> {
> .id = V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP,
> @@ -2057,7 +2057,7 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
> case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:
> p->codec.vp8.rc_p_frame_qp = ctrl->val;
> break;
> - case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
> p->codec.vp8.profile = ctrl->val;
> break;
> case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP:
> @@ -2711,4 +2711,3 @@ void s5p_mfc_enc_init(struct s5p_mfc_ctx *ctx)
> f.fmt.pix_mp.pixelformat = DEF_DST_FMT_ENC;
> ctx->dst_fmt = find_format(&f, MFC_FMT_ENC);
> }
> -
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
> index d29e45516eb7..e7e6340b395e 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -431,6 +431,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> "Use Previous Specific Frame",
> NULL,
> };
> + static const char * const vp8_profile[] = {
> + "0",
> + "1",
> + "2",
> + "3",
> + NULL,
> + };
>
> static const char * const flash_led_mode[] = {
> "Off",
> @@ -614,6 +621,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> return mpeg4_profile;
> case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
> return vpx_golden_frame_sel;
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
> + return vp8_profile;
> case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
> return jpeg_chroma_subsampling;
> case V4L2_CID_DV_TX_MODE:
> @@ -839,7 +848,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_MPEG_VIDEO_VPX_MAX_QP: return "VPX Maximum QP Value";
> case V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP: return "VPX I-Frame QP Value";
> case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP: return "VPX P-Frame QP Value";
> - case V4L2_CID_MPEG_VIDEO_VPX_PROFILE: return "VPX Profile";
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE: return "VP8 Profile";
>
> /* HEVC controls */
> case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC I-Frame QP Value";
> @@ -1180,6 +1189,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> case V4L2_CID_DEINTERLACING_MODE:
> case V4L2_CID_TUNE_DEEMPHASIS:
> case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
> case V4L2_CID_DETECT_MD_MODE:
> case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
> case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> index 8d473c979b61..2001823c3072 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -587,7 +587,16 @@ enum v4l2_vp8_golden_frame_sel {
> #define V4L2_CID_MPEG_VIDEO_VPX_MAX_QP (V4L2_CID_MPEG_BASE+508)
> #define V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP (V4L2_CID_MPEG_BASE+509)
> #define V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (V4L2_CID_MPEG_BASE+510)
> -#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE (V4L2_CID_MPEG_BASE+511)
> +
> +#define V4L2_CID_MPEG_VIDEO_VP8_PROFILE (V4L2_CID_MPEG_BASE+511)
> +enum v4l2_mpeg_video_vp8_profile {
> + V4L2_MPEG_VIDEO_VP8_PROFILE_0 = 0,
> + V4L2_MPEG_VIDEO_VP8_PROFILE_1 = 1,
> + V4L2_MPEG_VIDEO_VP8_PROFILE_2 = 2,
> + V4L2_MPEG_VIDEO_VP8_PROFILE_3 = 3,
> +};
> +/* Deprecated alias for compatibility reasons. */
> +#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE V4L2_CID_MPEG_VIDEO_VP8_PROFILE
>
> /* CIDs for HEVC encoding. */
>
> --
> 2.18.0.rc1.242.g61856ae69a-goog
>
Regards,
Hans
^ permalink raw reply
* [PATCH 4/4] KVM: arm64: Avoid mistaken attempts to save SVE state for vcpus
From: Alex Bennée @ 2018-06-15 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528976546-25999-4-git-send-email-Dave.Martin@arm.com>
Dave Martin <Dave.Martin@arm.com> writes:
> This patch ensures this my delaying restoration of current's
> TIF_SVE until after the call to fpsimd_save().
this *by* delaying
--
Alex Benn?e
^ permalink raw reply
* [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
From: Riku Voipio @ 2018-06-15 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51d3d738-cdf5-2992-bba5-c3e1f34096c2@infradead.org>
On Wed, 13 Jun 2018 at 21:22, Geoff Levand <geoff@infradead.org> wrote:
>
> Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
> a work-around for HPE ProLiant m400 APEI firmware problems.
>
> The work-around disables APEI when CONFIG_ACPI_APEI is set and
> m400 firmware is detected. Without this fixup m400 systems
> experience errors like these on startup:
>
> [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
> [Hardware Error]: event severity: fatal
> [Hardware Error]: Error 0, type: fatal
> [Hardware Error]: section_type: memory error
> [Hardware Error]: error_status: 0x0000000000001300
> [Hardware Error]: error_type: 10, invalid address
> Kernel panic - not syncing: Fatal hardware error!
>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
> ---
> Hi,
>
> It seems unlikely there will be any m400 firmware updates to fix
> this problem. APEI support is desired for new ARM64 servers coming
> to market. Distros are now forced to have their own fixes, not
> enable APEI, or let m400 users fend for themselves.
Thanks for working on this. This patch works well on m400 with APEI enabled.
Tested-by: Riku Voipio <riku.voipio@linaro.org>
> -Geoff
>
> arch/arm64/kernel/acpi.c | 40 ++++++++++++++++++++++++++++++++++++----
> 1 file changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 7b09487ff8fb..3c315c2c7476 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -31,6 +31,8 @@
> #include <asm/cpu_ops.h>
> #include <asm/smp_plat.h>
>
> +#include <acpi/apei.h>
> +
> #ifdef CONFIG_ACPI_APEI
> # include <linux/efi.h>
> # include <asm/pgtable.h>
> @@ -177,6 +179,33 @@ static int __init acpi_fadt_sanity_check(void)
> return ret;
> }
>
> +/*
> + * acpi_fixup_m400_quirks - Work-around for HPE ProLiant m400 APEI firmware
> + * problems.
> + */
> +static void __init acpi_fixup_m400_quirks(void)
> +{
> + acpi_status status;
> + struct acpi_table_header *header;
> +#if !defined(CONFIG_ACPI_APEI)
> + int hest_disable = HEST_DISABLED;
> +#endif
> +
> + if (!IS_ENABLED(CONFIG_ACPI_APEI) || hest_disable != HEST_ENABLED)
> + return;
> +
> + status = acpi_get_table(ACPI_SIG_HEST, 0, &header);
> +
> + if (ACPI_SUCCESS(status) && !strncmp(header->oem_id, "HPE ", 6) &&
> + !strncmp(header->oem_table_id, "ProLiant", 8) &&
> + MIDR_IMPLEMENTOR(read_cpuid_id()) == ARM_CPU_IMP_APM) {
> + hest_disable = HEST_DISABLED;
> + pr_info("Disabled APEI for m400.\n");
> + }
> +
> + acpi_put_table(header);
> +}
> +
> /*
> * acpi_boot_table_init() called from setup_arch(), always.
> * 1. find RSDP and get its address, and then find XSDT
> @@ -232,11 +261,14 @@ void __init acpi_boot_table_init(void)
> if (acpi_disabled) {
> if (earlycon_acpi_spcr_enable)
> early_init_dt_scan_chosen_stdout();
> - } else {
> - acpi_parse_spcr(earlycon_acpi_spcr_enable, true);
> - if (IS_ENABLED(CONFIG_ACPI_BGRT))
> - acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
> + return;
> }
> +
> + acpi_parse_spcr(earlycon_acpi_spcr_enable, true);
> + if (IS_ENABLED(CONFIG_ACPI_BGRT))
> + acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
> +
> + acpi_fixup_m400_quirks();
> }
>
> #ifdef CONFIG_ACPI_APEI
> --
> 2.14.1
>
^ permalink raw reply
* [PATCH v3 16/27] docs: Fix more broken references
From: Matthias Brugger @ 2018-06-15 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e1bf52a721005b2017434acc54ec5ddc152d6fe4.1528990947.git.mchehab+samsung@kernel.org>
On 14/06/18 18:09, Mauro Carvalho Chehab wrote:
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix
>
> Manually checked that produced results are valid.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
for mt6397.txt:
Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> .../devicetree/bindings/clock/st/st,clkgen.txt | 8 ++++----
> .../devicetree/bindings/clock/ti/gate.txt | 2 +-
> .../devicetree/bindings/clock/ti/interface.txt | 2 +-
> .../bindings/cpufreq/cpufreq-mediatek.txt | 2 +-
> .../devicetree/bindings/devfreq/rk3399_dmc.txt | 2 +-
> .../bindings/gpu/arm,mali-midgard.txt | 2 +-
> .../bindings/gpu/arm,mali-utgard.txt | 2 +-
> .../devicetree/bindings/mfd/mt6397.txt | 2 +-
> .../devicetree/bindings/mfd/sun6i-prcm.txt | 2 +-
> .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 2 +-
> .../devicetree/bindings/net/dsa/ksz.txt | 2 +-
> .../devicetree/bindings/net/dsa/mt7530.txt | 2 +-
> .../devicetree/bindings/power/fsl,imx-gpc.txt | 2 +-
> .../bindings/power/wakeup-source.txt | 2 +-
> .../devicetree/bindings/usb/rockchip,dwc3.txt | 2 +-
> Documentation/hwmon/ina2xx | 2 +-
> Documentation/maintainer/pull-requests.rst | 2 +-
> Documentation/translations/ko_KR/howto.rst | 2 +-
> MAINTAINERS | 18 +++++++++---------
> drivers/net/ethernet/intel/Kconfig | 8 ++++----
> drivers/soundwire/stream.c | 8 ++++----
> fs/Kconfig.binfmt | 2 +-
> fs/binfmt_misc.c | 2 +-
> 23 files changed, 40 insertions(+), 40 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt
> index 7364953d0d0b..45ac19bfa0a9 100644
> --- a/Documentation/devicetree/bindings/clock/st/st,clkgen.txt
> +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt
> @@ -31,10 +31,10 @@ This binding uses the common clock binding[1].
> Each subnode should use the binding described in [2]..[7]
>
> [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> -[3] Documentation/devicetree/bindings/clock/st,clkgen-mux.txt
> -[4] Documentation/devicetree/bindings/clock/st,clkgen-pll.txt
> -[7] Documentation/devicetree/bindings/clock/st,quadfs.txt
> -[8] Documentation/devicetree/bindings/clock/st,flexgen.txt
> +[3] Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
> +[4] Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
> +[7] Documentation/devicetree/bindings/clock/st/st,quadfs.txt
> +[8] Documentation/devicetree/bindings/clock/st/st,flexgen.txt
>
>
> Required properties:
> diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt b/Documentation/devicetree/bindings/clock/ti/gate.txt
> index 03f8fdee62a7..56d603c1f716 100644
> --- a/Documentation/devicetree/bindings/clock/ti/gate.txt
> +++ b/Documentation/devicetree/bindings/clock/ti/gate.txt
> @@ -10,7 +10,7 @@ will be controlled instead and the corresponding hw-ops for
> that is used.
>
> [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> -[2] Documentation/devicetree/bindings/clock/gate-clock.txt
> +[2] Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
> [3] Documentation/devicetree/bindings/clock/ti/clockdomain.txt
>
> Required properties:
> diff --git a/Documentation/devicetree/bindings/clock/ti/interface.txt b/Documentation/devicetree/bindings/clock/ti/interface.txt
> index 3111a409fea6..3f4704040140 100644
> --- a/Documentation/devicetree/bindings/clock/ti/interface.txt
> +++ b/Documentation/devicetree/bindings/clock/ti/interface.txt
> @@ -9,7 +9,7 @@ companion clock finding (match corresponding functional gate
> clock) and hardware autoidle enable / disable.
>
> [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> -[2] Documentation/devicetree/bindings/clock/gate-clock.txt
> +[2] Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
>
> Required properties:
> - compatible : shall be one of:
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> index d36f07e0a2bb..0551c78619de 100644
> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> @@ -8,7 +8,7 @@ Required properties:
> "intermediate" - A parent of "cpu" clock which is used as "intermediate" clock
> source (usually MAINPLL) when the original CPU PLL is under
> transition and not stable yet.
> - Please refer to Documentation/devicetree/bindings/clk/clock-bindings.txt for
> + Please refer to Documentation/devicetree/bindings/clock/clock-bindings.txt for
> generic clock consumer properties.
> - operating-points-v2: Please refer to Documentation/devicetree/bindings/opp/opp.txt
> for detail.
> diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> index d6d2833482c9..fc2bcbe26b1e 100644
> --- a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> @@ -12,7 +12,7 @@ Required properties:
> - clocks: Phandles for clock specified in "clock-names" property
> - clock-names : The name of clock used by the DFI, must be
> "pclk_ddr_mon";
> -- operating-points-v2: Refer to Documentation/devicetree/bindings/power/opp.txt
> +- operating-points-v2: Refer to Documentation/devicetree/bindings/opp/opp.txt
> for details.
> - center-supply: DMC supply node.
> - status: Marks the node enabled/disabled.
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> index 039219df05c5..18a2cde2e5f3 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> @@ -34,7 +34,7 @@ Optional properties:
> - mali-supply : Phandle to regulator for the Mali device. Refer to
> Documentation/devicetree/bindings/regulator/regulator.txt for details.
>
> -- operating-points-v2 : Refer to Documentation/devicetree/bindings/power/opp.txt
> +- operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt
> for details.
>
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> index c1f65d1dac1d..63cd91176a68 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> @@ -44,7 +44,7 @@ Optional properties:
>
> - memory-region:
> Memory region to allocate from, as defined in
> - Documentation/devicetree/bindi/reserved-memory/reserved-memory.txt
> + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>
> - mali-supply:
> Phandle to regulator for the Mali device, as defined in
> diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt
> index d1df77f4d655..0ebd08af777d 100644
> --- a/Documentation/devicetree/bindings/mfd/mt6397.txt
> +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
> @@ -12,7 +12,7 @@ MT6397/MT6323 is a multifunction device with the following sub modules:
> It is interfaced to host controller using SPI interface by a proprietary hardware
> called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap.
> See the following for pwarp node definitions:
> -Documentation/devicetree/bindings/soc/pwrap.txt
> +Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
>
> This document describes the binding for MFD device and its sub module.
>
> diff --git a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
> index dd2c06540485..4d21ffdb0fc1 100644
> --- a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
> +++ b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
> @@ -9,7 +9,7 @@ Required properties:
>
> The prcm node may contain several subdevices definitions:
> - see Documentation/devicetree/clk/sunxi.txt for clock devices
> - - see Documentation/devicetree/reset/allwinner,sunxi-clock-reset.txt for reset
> + - see Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt for reset
> controller devices
>
>
> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> index a58c173b7ab9..0419a63f73a0 100644
> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> @@ -62,7 +62,7 @@ Required properties for a slot (Deprecated - Recommend to use one slot per host)
> rest of the gpios (depending on the bus-width property) are the data lines in
> no particular order. The format of the gpio specifier depends on the gpio
> controller.
> -(Deprecated - Refer to Documentation/devicetree/binding/pinctrl/samsung-pinctrl.txt)
> +(Deprecated - Refer to Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt)
>
> Example:
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/ksz.txt b/Documentation/devicetree/bindings/net/dsa/ksz.txt
> index fd23904ac68e..a700943218ca 100644
> --- a/Documentation/devicetree/bindings/net/dsa/ksz.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/ksz.txt
> @@ -6,7 +6,7 @@ Required properties:
> - compatible: For external switch chips, compatible string must be exactly one
> of: "microchip,ksz9477"
>
> -See Documentation/devicetree/bindings/dsa/dsa.txt for a list of additional
> +See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
> required and optional properties.
>
> Examples:
> diff --git a/Documentation/devicetree/bindings/net/dsa/mt7530.txt b/Documentation/devicetree/bindings/net/dsa/mt7530.txt
> index a9bc27b93ee3..aa3527f71fdc 100644
> --- a/Documentation/devicetree/bindings/net/dsa/mt7530.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/mt7530.txt
> @@ -31,7 +31,7 @@ Required properties for the child nodes within ports container:
> - phy-mode: String, must be either "trgmii" or "rgmii" for port labeled
> "cpu".
>
> -See Documentation/devicetree/bindings/dsa/dsa.txt for a list of additional
> +See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
> required, optional properties and how the integrated switch subnodes must
> be specified.
>
> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
> index b31d6bbeee16..726ec2875223 100644
> --- a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
> @@ -14,7 +14,7 @@ Required properties:
> datasheet
> - interrupts: Should contain one interrupt specifier for the GPC interrupt
> - clocks: Must contain an entry for each entry in clock-names.
> - See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
> + See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> - clock-names: Must include the following entries:
> - ipg
>
> diff --git a/Documentation/devicetree/bindings/power/wakeup-source.txt b/Documentation/devicetree/bindings/power/wakeup-source.txt
> index 5d254ab13ebf..cfd74659fbed 100644
> --- a/Documentation/devicetree/bindings/power/wakeup-source.txt
> +++ b/Documentation/devicetree/bindings/power/wakeup-source.txt
> @@ -22,7 +22,7 @@ List of legacy properties and respective binding document
> 3. "has-tpo" Documentation/devicetree/bindings/rtc/rtc-opal.txt
> 4. "linux,wakeup" Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
> Documentation/devicetree/bindings/mfd/tc3589x.txt
> - Documentation/devicetree/bindings/input/ads7846.txt
> + Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
> 5. "linux,keypad-wakeup" Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
> 6. "linux,input-wakeup" Documentation/devicetree/bindings/input/samsung-keypad.txt
> 7. "nvidia,wakeup-source" Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
> diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
> index 50a31536e975..252a05c5d976 100644
> --- a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
> @@ -16,7 +16,7 @@ A child node must exist to represent the core DWC3 IP block. The name of
> the node is not important. The content of the node is defined in dwc3.txt.
>
> Phy documentation is provided in the following places:
> -Documentation/devicetree/bindings/phy/rockchip,dwc3-usb-phy.txt
> +Documentation/devicetree/bindings/phy/qcom-dwc3-usb-phy.txt
>
> Example device nodes:
>
> diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx
> index cfd31d94c872..72d16f08e431 100644
> --- a/Documentation/hwmon/ina2xx
> +++ b/Documentation/hwmon/ina2xx
> @@ -53,7 +53,7 @@ bus supply voltage.
>
> The shunt value in micro-ohms can be set via platform data or device tree at
> compile-time or via the shunt_resistor attribute in sysfs at run-time. Please
> -refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for bindings
> +refer to the Documentation/devicetree/bindings/hwmon/ina2xx.txt for bindings
> if the device tree is used.
>
> Additionally ina226 supports update_interval attribute as described in
> diff --git a/Documentation/maintainer/pull-requests.rst b/Documentation/maintainer/pull-requests.rst
> index a19db3458b56..22b271de0304 100644
> --- a/Documentation/maintainer/pull-requests.rst
> +++ b/Documentation/maintainer/pull-requests.rst
> @@ -41,7 +41,7 @@ named ``char-misc-next``, you would be using the following command::
>
> that will create a signed tag called ``char-misc-4.15-rc1`` based on the
> last commit in the ``char-misc-next`` branch, and sign it with your gpg key
> -(see :ref:`Documentation/maintainer/configure_git.rst <configuregit>`).
> +(see :ref:`Documentation/maintainer/configure-git.rst <configuregit>`).
>
> Linus will only accept pull requests based on a signed tag. Other
> maintainers may differ.
> diff --git a/Documentation/translations/ko_KR/howto.rst b/Documentation/translations/ko_KR/howto.rst
> index 624654bdcd8a..a8197e072599 100644
> --- a/Documentation/translations/ko_KR/howto.rst
> +++ b/Documentation/translations/ko_KR/howto.rst
> @@ -160,7 +160,7 @@ mtk.manpages at gmail.com? ??????? ?? ?? ????.
> ??? ??? ??? ?? ?? ???? ???? ???? ??
> ????.
>
> - :ref:`Documentation/process/stable_kernel_rules.rst <stable_kernel_rules>`
> + :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
> ? ??? ???? ?? ??? ????? ??? ???? ???
> ????? ??? ??? ? ??? ??? ?? ????
> ??? ?? ???? ????.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ec65e33e2cf1..5871dd5060f6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4513,7 +4513,7 @@ DRM DRIVER FOR ILITEK ILI9225 PANELS
> M: David Lechner <david@lechnology.com>
> S: Maintained
> F: drivers/gpu/drm/tinydrm/ili9225.c
> -F: Documentation/devicetree/bindings/display/ili9225.txt
> +F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
>
> DRM DRIVER FOR INTEL I810 VIDEO CARDS
> S: Orphan / Obsolete
> @@ -4599,13 +4599,13 @@ DRM DRIVER FOR SITRONIX ST7586 PANELS
> M: David Lechner <david@lechnology.com>
> S: Maintained
> F: drivers/gpu/drm/tinydrm/st7586.c
> -F: Documentation/devicetree/bindings/display/st7586.txt
> +F: Documentation/devicetree/bindings/display/sitronix,st7586.txt
>
> DRM DRIVER FOR SITRONIX ST7735R PANELS
> M: David Lechner <david@lechnology.com>
> S: Maintained
> F: drivers/gpu/drm/tinydrm/st7735r.c
> -F: Documentation/devicetree/bindings/display/st7735r.txt
> +F: Documentation/devicetree/bindings/display/sitronix,st7735r.txt
>
> DRM DRIVER FOR TDFX VIDEO CARDS
> S: Orphan / Obsolete
> @@ -4824,7 +4824,7 @@ M: Eric Anholt <eric@anholt.net>
> S: Supported
> F: drivers/gpu/drm/v3d/
> F: include/uapi/drm/v3d_drm.h
> -F: Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt
> +F: Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt
> T: git git://anongit.freedesktop.org/drm/drm-misc
>
> DRM DRIVERS FOR VC4
> @@ -5735,7 +5735,7 @@ M: Madalin Bucur <madalin.bucur@nxp.com>
> L: netdev at vger.kernel.org
> S: Maintained
> F: drivers/net/ethernet/freescale/fman
> -F: Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> +F: Documentation/devicetree/bindings/net/fsl-fman.txt
>
> FREESCALE QORIQ PTP CLOCK DRIVER
> M: Yangbo Lu <yangbo.lu@nxp.com>
> @@ -8700,7 +8700,7 @@ M: Guenter Roeck <linux@roeck-us.net>
> L: linux-hwmon at vger.kernel.org
> S: Maintained
> F: Documentation/hwmon/max6697
> -F: Documentation/devicetree/bindings/i2c/max6697.txt
> +F: Documentation/devicetree/bindings/hwmon/max6697.txt
> F: drivers/hwmon/max6697.c
> F: include/linux/platform_data/max6697.h
>
> @@ -9080,7 +9080,7 @@ M: Martin Donnelly <martin.donnelly@ge.com>
> M: Martyn Welch <martyn.welch@collabora.co.uk>
> S: Maintained
> F: drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c
> -F: Documentation/devicetree/bindings/video/bridge/megachips-stdpxxxx-ge-b850v3-fw.txt
> +F: Documentation/devicetree/bindings/display/bridge/megachips-stdpxxxx-ge-b850v3-fw.txt
>
> MEGARAID SCSI/SAS DRIVERS
> M: Kashyap Desai <kashyap.desai@broadcom.com>
> @@ -10728,7 +10728,7 @@ PARALLEL LCD/KEYPAD PANEL DRIVER
> M: Willy Tarreau <willy@haproxy.com>
> M: Ksenija Stanojevic <ksenija.stanojevic@gmail.com>
> S: Odd Fixes
> -F: Documentation/misc-devices/lcd-panel-cgram.txt
> +F: Documentation/auxdisplay/lcd-panel-cgram.txt
> F: drivers/misc/panel.c
>
> PARALLEL PORT SUBSYSTEM
> @@ -13291,7 +13291,7 @@ M: Vinod Koul <vkoul@kernel.org>
> L: alsa-devel at alsa-project.org (moderated for non-subscribers)
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> S: Supported
> -F: Documentation/sound/alsa/compress_offload.txt
> +F: Documentation/sound/designs/compress-offload.rst
> F: include/sound/compress_driver.h
> F: include/uapi/sound/compress_*
> F: sound/core/compress_offload.c
> diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
> index 14d287bed33c..1ab613eb5796 100644
> --- a/drivers/net/ethernet/intel/Kconfig
> +++ b/drivers/net/ethernet/intel/Kconfig
> @@ -33,7 +33,7 @@ config E100
> to identify the adapter.
>
> More specific information on configuring the driver is in
> - <file:Documentation/networking/e100.txt>.
> + <file:Documentation/networking/e100.rst>.
>
> To compile this driver as a module, choose M here. The module
> will be called e100.
> @@ -49,7 +49,7 @@ config E1000
> <http://support.intel.com>
>
> More specific information on configuring the driver is in
> - <file:Documentation/networking/e1000.txt>.
> + <file:Documentation/networking/e1000.rst>.
>
> To compile this driver as a module, choose M here. The module
> will be called e1000.
> @@ -94,7 +94,7 @@ config IGB
> <http://support.intel.com>
>
> More specific information on configuring the driver is in
> - <file:Documentation/networking/e1000.txt>.
> + <file:Documentation/networking/e1000.rst>.
>
> To compile this driver as a module, choose M here. The module
> will be called igb.
> @@ -130,7 +130,7 @@ config IGBVF
> <http://support.intel.com>
>
> More specific information on configuring the driver is in
> - <file:Documentation/networking/e1000.txt>.
> + <file:Documentation/networking/e1000.rst>.
>
> To compile this driver as a module, choose M here. The module
> will be called igbvf.
> diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c
> index 8974a0fcda1b..4b5e250e8615 100644
> --- a/drivers/soundwire/stream.c
> +++ b/drivers/soundwire/stream.c
> @@ -1291,7 +1291,7 @@ static int _sdw_prepare_stream(struct sdw_stream_runtime *stream)
> *
> * @stream: Soundwire stream
> *
> - * Documentation/soundwire/stream.txt explains this API in detail
> + * Documentation/driver-api/soundwire/stream.rst explains this API in detail
> */
> int sdw_prepare_stream(struct sdw_stream_runtime *stream)
> {
> @@ -1348,7 +1348,7 @@ static int _sdw_enable_stream(struct sdw_stream_runtime *stream)
> *
> * @stream: Soundwire stream
> *
> - * Documentation/soundwire/stream.txt explains this API in detail
> + * Documentation/driver-api/soundwire/stream.rst explains this API in detail
> */
> int sdw_enable_stream(struct sdw_stream_runtime *stream)
> {
> @@ -1400,7 +1400,7 @@ static int _sdw_disable_stream(struct sdw_stream_runtime *stream)
> *
> * @stream: Soundwire stream
> *
> - * Documentation/soundwire/stream.txt explains this API in detail
> + * Documentation/driver-api/soundwire/stream.rst explains this API in detail
> */
> int sdw_disable_stream(struct sdw_stream_runtime *stream)
> {
> @@ -1456,7 +1456,7 @@ static int _sdw_deprepare_stream(struct sdw_stream_runtime *stream)
> *
> * @stream: Soundwire stream
> *
> - * Documentation/soundwire/stream.txt explains this API in detail
> + * Documentation/driver-api/soundwire/stream.rst explains this API in detail
> */
> int sdw_deprepare_stream(struct sdw_stream_runtime *stream)
> {
> diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
> index 57a27c42b5ac..56df483de619 100644
> --- a/fs/Kconfig.binfmt
> +++ b/fs/Kconfig.binfmt
> @@ -168,7 +168,7 @@ config BINFMT_MISC
> will automatically feed it to the correct interpreter.
>
> You can do other nice things, too. Read the file
> - <file:Documentation/binfmt_misc.txt> to learn how to use this
> + <file:Documentation/admin-guide/binfmt-misc.rst> to learn how to use this
> feature, <file:Documentation/admin-guide/java.rst> for information about how
> to include Java support. and <file:Documentation/admin-guide/mono.rst> for
> information about how to include Mono-based .NET support.
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index 4de191563261..4b5fff31ef27 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -4,7 +4,7 @@
> * Copyright (C) 1997 Richard G?nther
> *
> * binfmt_misc detects binaries via a magic or filename extension and invokes
> - * a specified wrapper. See Documentation/binfmt_misc.txt for more details.
> + * a specified wrapper. See Documentation/admin-guide/binfmt-misc.rst for more details.
> */
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
From: Maxime Ripard @ 2018-06-15 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2481282.yoIGH2ksVh@jernej-laptop>
On Wed, Jun 13, 2018 at 06:03:21PM +0200, Jernej ?krabec wrote:
> > > +Required properties:
> > > + - compatible: value must be one of:
> > > + * allwinner,sun8i-r40-tcon-top
> > > + - reg: base address and size of the memory-mapped region.
> > > + - clocks: phandle to the clocks feeding the TCON TOP
> > > + * bus: TCON TOP interface clock
> > > + - clock-names: clock name mentioned above
> > > + - resets: phandle to the reset line driving the DRC
> >
> > s/DRC/TCON TOP/ ?
>
> Yes, copy & paste issue
>
> >
> > > + * rst: TCON TOP reset line
> >
> > Remaining consistent with the clock name would be great
>
> You mean "ahb"? I noticed that most other nodes with reset lines don't have a
> name associated. Maybe I could just drop it and use first specified reset?
It's called bus in the binding, but yes. And yeah, we can drop the
name as well.
> >
> > > + - reset-names: reset name mentioned above
> > > + - #clock-cells : must contain 1
> >
> > An example would be nice here
>
> You mean node example? with ports? In the past, Rob was against examples
> unless really necessary. Node from R40 DTSI can serve as an example.
Ok.
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/20180615/6770fcf3/attachment.sig>
^ permalink raw reply
* Charge counter on droid 4
From: Pavel Machek @ 2018-06-15 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615080014.GA29192@amd>
On Fri 2018-06-15 10:00:14, Pavel Machek wrote:
> Hi!
>
> Droid 4 has non-removable battery, yet the charge counter is reset to
> near zero on each boot of linux.
>
> Unfortunately, that makes charge counter pretty much useless on d4, as
> the "battery full" and "battery empty" limits will be different during
> each boot.
Hmm, and could we refrain from providing "power" values?
I was thinking great, we have hardware that does proper power
measuerement for us. No.... it is driver providing synthetic
values. As userland has enough information to do that itself, I
believe we should not do this in kernel.
diff --git a/drivers/power/supply/cpcap-battery.c b/drivers/power/supply/cpcap-battery.c
index 839e365..1610026 100644
--- a/drivers/power/supply/cpcap-battery.c
+++ b/drivers/power/supply/cpcap-battery.c
@@ -490,24 +490,6 @@ static int cpcap_battery_get_property(struct power_supply *psy,
case POWER_SUPPLY_PROP_CHARGE_COUNTER:
val->intval = latest->counter_uah;
break;
- case POWER_SUPPLY_PROP_POWER_NOW:
- tmp = (latest->voltage / 10000) * latest->current_ua;
- val->intval = div64_s64(tmp, 100);
- break;
- case POWER_SUPPLY_PROP_POWER_AVG:
- if (cached) {
- tmp = cpcap_battery_cc_get_avg_current(ddata);
- tmp *= (latest->voltage / 10000);
- val->intval = div64_s64(tmp, 100);
- break;
- }
- sample = latest->cc.sample - previous->cc.sample;
- accumulator = latest->cc.accumulator - previous->cc.accumulator;
- tmp = cpcap_battery_cc_to_ua(ddata, sample, accumulator,
- latest->cc.offset);
- tmp *= ((latest->voltage + previous->voltage) / 20000);
- val->intval = div64_s64(tmp, 100);
- break;
case POWER_SUPPLY_PROP_CAPACITY_LEVEL:
if (cpcap_battery_full(ddata))
val->intval = POWER_SUPPLY_CAPACITY_LEVEL_FULL;
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180615/2ce5a36e/attachment.sig>
^ 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