* Re: [PATCH v2 4/5] fbdev/ssd1307fb: add support to enable VBAT
From: Tomi Valkeinen @ 2017-01-19 13:15 UTC (permalink / raw)
To: Rob Herring, Jyri Sarha
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
bcousson-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <20170118223310.kxbgq47v7cl33ls3@rob-hp-laptop>
[-- Attachment #1.1: Type: text/plain, Size: 1572 bytes --]
On 19/01/17 00:33, Rob Herring wrote:
> On Fri, Jan 13, 2017 at 12:35:48PM +0200, Jyri Sarha wrote:
>> From: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
>>
>> SSD1306 needs VBAT when it is wired in charge pump configuration. This
>> patch adds support to the driver to enable VBAT regulator at init time.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
>> Reviewed-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
>> Signed-off-by: Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>
>> ---
>> .../devicetree/bindings/display/ssd1307fb.txt | 1 +
>> drivers/video/fbdev/ssd1307fb.c | 20 +++++++++++++++++++-
>> 2 files changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/ssd1307fb.txt b/Documentation/devicetree/bindings/display/ssd1307fb.txt
>> index 6617df6..209d931 100644
>> --- a/Documentation/devicetree/bindings/display/ssd1307fb.txt
>> +++ b/Documentation/devicetree/bindings/display/ssd1307fb.txt
>> @@ -16,6 +16,7 @@ Required properties:
>> Optional properties:
>> - reset-gpios: The GPIO used to reset the OLED display, if available. See
>> Documentation/devicetree/bindings/gpio/gpio.txt for details.
>> + - vbat-supply: The supply for VBAT
>
> According to the datasheet, SSD1307 has 2 supplies: Vdd and Vcc
>
> I don't see any mention of a charge pump, so that must be an external
> component.
VBAT is for SSD1306. Perhaps the DT doc should mention it.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] Documentation: usb: fix wrong documentation paths
From: Rob Herring @ 2017-01-19 13:11 UTC (permalink / raw)
To: Yegor Yefremov
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170115121428.3255-1-yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On Sun, Jan 15, 2017 at 01:14:28PM +0100, Yegor Yefremov wrote:
> Fixes wrong spelled "pinctrl-bindings.txt" and "qcom-dwc3-usb-phy.txt"
> file names as also wrong specified "mt8173-mtu3.txt" file name.
>
> Signed-off-by: Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> Changes:
> v1 -> v2: add changelog text (Greg Kroah-Hartman)
>
> Documentation/devicetree/bindings/usb/dwc3-st.txt | 4 ++--
> Documentation/devicetree/bindings/usb/ehci-st.txt | 2 +-
> Documentation/devicetree/bindings/usb/mt8173-mtu3.txt | 2 +-
> Documentation/devicetree/bindings/usb/mt8173-xhci.txt | 4 ++--
> Documentation/devicetree/bindings/usb/qcom,dwc3.txt | 2 +-
> 5 files changed, 7 insertions(+), 7 deletions(-)
Applied, thanks.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] iio: max5481: Add support for Maxim digital potentiometers
From: Rob Herring @ 2017-01-19 13:09 UTC (permalink / raw)
To: Slawomir Stepien
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
matthew.weber-lFk7bPDcGtkY5TsXZYaR1UEOCMrvLtNR,
maury.anderson-lFk7bPDcGtkY5TsXZYaR1UEOCMrvLtNR,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland
In-Reply-To: <20170114212139.GA3418-SwUeJysX96B82hYKe6nXyg@public.gmane.org>
On Sat, Jan 14, 2017 at 10:21:39PM +0100, Slawomir Stepien wrote:
> From: Matt Weber <matthew.weber-lFk7bPDcGtkY5TsXZYaR1UEOCMrvLtNR@public.gmane.org>
>
> Add implementation for Maxim Integrated 5481, 5482, 5483,
> and 5484 digital potentiometer devices.
>
> Datasheet:
> http://datasheets.maximintegrated.com/en/ds/MAX5481-MAX5484.pdf
>
> Signed-off-by: Maury Anderson <maury.anderson-lFk7bPDcGtkY5TsXZYaR1UEOCMrvLtNR@public.gmane.org>
> Signed-off-by: Matthew Weber <matthew.weber-lFk7bPDcGtkY5TsXZYaR1UEOCMrvLtNR@public.gmane.org>
> Signed-off-by: Slawomir Stepien <sst-IjDXvh/HVVUAvxtiuMwx3w@public.gmane.org>
> ---
>
> This is my resubmission of this patch after original authors decided not to
> pursuit it inclusion into kernel.
>
> Tested using signal analyzer.
>
> Changes since v2:
> * spi write buffer moved to struct max5481_data and ____cacheline_aligned.
> * max5481_write_cmd now uses pointer to struct max5481_data as a first argument.
>
> Changes since v1:
> * removed not needed '``' and 'c' chars
> * includes are now sorted
> * added coma to last item in enum max5481_variant
> * removed maxpos from struct max5481_cfg
> * max5481_CHANNEL is no MAX5481_CHANNEL and it does not have 'ch' argument
> * max5481_write_cmd is now based around switch
> * removed not needed cast in max5481_write_cmd
> * wpier state is saved after iio_device_unregister
> * changed names in spi_device_id and acpi_device_id to be equal to names in of_device_id
>
> ---
> .../bindings/iio/potentiometer/max5481.txt | 23 +++
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/iio/potentiometer/Kconfig | 11 ++
> drivers/iio/potentiometer/Makefile | 1 +
> drivers/iio/potentiometer/max5481.c | 216 +++++++++++++++++++++
> 4 files changed, 251 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/potentiometer/max5481.txt
> create mode 100644 drivers/iio/potentiometer/max5481.c
^ permalink raw reply
* [PATCH 3/3] ARM: configs: omap2plus_defconfig: Enable support for RTC M41T80
From: Teresa Remmet @ 2017-01-19 13:07 UTC (permalink / raw)
To: linux-omap, devicetree, linux-arm-kernel
Cc: Tony Lindgren, Mark Rutland, Rob Herring, Wadim Egorov,
Benoît Cousson
In-Reply-To: <1484831270-7251-1-git-send-email-t.remmet@phytec.de>
The phyCORE-AM335x SoM has a RV4162 RTC populated which is supported
by the M41T80 driver. Enabled it so make the RTC support on the SoM
available.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
---
arch/arm/configs/omap2plus_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 0c2bf2d..75b5b73 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -414,6 +414,7 @@ CONFIG_LEDS_TRIGGER_GPIO=m
CONFIG_LEDS_TRIGGER_DEFAULT_ON=m
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_DS1307=m
+CONFIG_RTC_DRV_M41T80=m
CONFIG_RTC_DRV_TWL92330=y
CONFIG_RTC_DRV_TWL4030=m
CONFIG_RTC_DRV_PALMAS=m
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] ARM: configs: omap2plus_defconfig: Enable support for micrell phys
From: Teresa Remmet @ 2017-01-19 13:07 UTC (permalink / raw)
To: linux-omap, devicetree, linux-arm-kernel
Cc: Tony Lindgren, Mark Rutland, Rob Herring, Wadim Egorov,
Benoît Cousson
In-Reply-To: <1484831270-7251-1-git-send-email-t.remmet@phytec.de>
The phyCORE-AM335x SoM with PCM-953 carrierboard has a
KSZ9021 phy mounted. To add support for this we need to enable
the micrell phy driver in the config.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
---
arch/arm/configs/omap2plus_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 195c98b..0c2bf2d 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -168,6 +168,7 @@ CONFIG_TI_CPTS=y
# CONFIG_NET_VENDOR_VIA is not set
# CONFIG_NET_VENDOR_WIZNET is not set
CONFIG_AT803X_PHY=y
+CONFIG_MICREL_PHY=y
CONFIG_SMSC_PHY=y
CONFIG_USB_USBNET=m
CONFIG_USB_NET_SMSC75XX=m
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: Add support for phyCORE-AM335x PCM-953 carrier board
From: Teresa Remmet @ 2017-01-19 13:07 UTC (permalink / raw)
To: linux-omap, devicetree, linux-arm-kernel
Cc: Tony Lindgren, Mark Rutland, Rob Herring, Wadim Egorov,
Benoît Cousson
The phyCORE-AM335x development kit is a combination of the
phyCORE-AM335x SoM and a PCM-953 carrier board. The features
of the PCM-953 are:
* ETH phy on carrier board: 1x RGMII
* 1x CAN
* Up to 4x UART
* USB0 (otg)
* USB1 (host)
* SD slot
* User gpio-keys
* User LEDs
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
---
.../devicetree/bindings/arm/omap/omap.txt | 3 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/am335x-pcm-953.dtsi | 303 +++++++++++++++++++++
arch/arm/boot/dts/am335x-phycore-rdk.dts | 27 ++
4 files changed, 334 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-pcm-953.dtsi
create mode 100644 arch/arm/boot/dts/am335x-phycore-rdk.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 05f95c3..8219b2c 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -151,6 +151,9 @@ Boards:
- AM335X SBC-T335 : single board computer, built around the Sitara AM3352/4
compatible = "compulab,sbc-t335", "compulab,cm-t335", "ti,am33xx"
+- AM335X phyCORE-AM335x: Development kit
+ compatible = "phytec,am335x-pcm-953", "phytec,am335x-phycore-som", "ti,am33xx"
+
- OMAP5 EVM : Evaluation Module
compatible = "ti,omap5-evm", "ti,omap5"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7327250..dd71afe 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -573,6 +573,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-lxm.dtb \
am335x-nano.dtb \
am335x-pepper.dtb \
+ am335x-phycore-rdk.dtb \
am335x-shc.dtb \
am335x-sbc-t335.dtb \
am335x-sl50.dtb \
diff --git a/arch/arm/boot/dts/am335x-pcm-953.dtsi b/arch/arm/boot/dts/am335x-pcm-953.dtsi
new file mode 100644
index 0000000..54a171d
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-pcm-953.dtsi
@@ -0,0 +1,303 @@
+/*
+ * Copyright (C) 2014-2017 Phytec Messtechnik GmbH
+ * Author: Wadim Egorov <w.egorov@phytec.de>
+ * Teresa Remmet <t.remmet@phytec.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <dt-bindings/input/input.h>
+
+/ {
+ model = "Phytec AM335x PCM-953";
+ compatible = "phytec,am335x-pcm-953", "phytec,am335x-phycore-som", "ti,am33xx";
+
+ user_leds: user_leds {
+ compatible = "gpio-leds";
+ };
+
+ user_buttons: user_buttons {
+ compatible = "gpio-keys";
+ };
+
+ regulators {
+ compatible = "simple-bus";
+
+ vcc3v3: fixedregulator@1 {
+ compatible = "regulator-fixed";
+ };
+
+ vcc1v8: fixedregulator@2 {
+ compatible = "regulator-fixed";
+ };
+ };
+};
+
+/* CAN */
+&am33xx_pinmux {
+ dcan1_pins: pinmux_dcan1 {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x980, PIN_OUTPUT_PULLUP | MUX_MODE2) /* uart1_rxd.dcan1_tx_mux2 */
+ AM33XX_IOPAD(0x984, PIN_INPUT_PULLUP | MUX_MODE2) /* uart1_txd.dcan1_rx_mux2 */
+ >;
+ };
+};
+
+&dcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dcan1_pins>;
+ status = "okay";
+};
+
+/* Ethernet */
+&am33xx_pinmux {
+ ethernet1_pins: pinmux_ethernet1 {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x840, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* gpmc_a0.rgmii2_tctl */
+ AM33XX_IOPAD(0x844, PIN_INPUT_PULLDOWN | MUX_MODE2) /* gpmc_a1.rgmii2_rctl */
+ AM33XX_IOPAD(0x848, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* gpmc_a2.rgmii2_td3 */
+ AM33XX_IOPAD(0x84c, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* gpmc_a3.rgmii2_td2 */
+ AM33XX_IOPAD(0x850, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* gpmc_a4.rgmii2_td1 */
+ AM33XX_IOPAD(0x854, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* gpmc_a5.rgmii2_td0 */
+ AM33XX_IOPAD(0x858, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* gpmc_a6.rgmii2_tclk */
+ AM33XX_IOPAD(0x85c, PIN_INPUT_PULLDOWN | MUX_MODE2) /* gpmc_a7.rgmii2_rclk */
+ AM33XX_IOPAD(0x860, PIN_INPUT_PULLDOWN | MUX_MODE2) /* gpmc_a8.rgmii2_rd3 */
+ AM33XX_IOPAD(0x864, PIN_INPUT_PULLDOWN | MUX_MODE2) /* gpmc_a9.rgmii2_rd2 */
+ AM33XX_IOPAD(0x868, PIN_INPUT_PULLDOWN | MUX_MODE2) /* gpmc_a10.rgmii2_rd1 */
+ AM33XX_IOPAD(0x86c, PIN_INPUT_PULLDOWN | MUX_MODE2) /* gpmc_a11.rgmii2_rd0 */
+ >;
+ };
+};
+
+&cpsw_emac1 {
+ phy-handle = <&phy1>;
+ phy-mode = "rgmii-id";
+ dual_emac_res_vlan = <2>;
+ status = "okay";
+};
+
+&davinci_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <2>;
+
+ /* Register 260 (104h) – RGMII Clock and Control Pad Skew */
+ rxc-skew-ps = <1400>;
+ rxdv-skew-ps = <0>;
+ txc-skew-ps = <1400>;
+ txen-skew-ps = <0>;
+ /* Register 261 (105h) – RGMII RX Data Pad Skew */
+ rxd3-skew-ps = <0>;
+ rxd2-skew-ps = <0>;
+ rxd1-skew-ps = <0>;
+ rxd0-skew-ps = <0>;
+ /* Register 262 (106h) – RGMII TX Data Pad Skew */
+ txd3-skew-ps = <0>;
+ txd2-skew-ps = <0>;
+ txd1-skew-ps = <0>;
+ txd0-skew-ps = <0>;
+ };
+};
+
+&mac {
+ slaves = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <ðernet0_pins ðernet1_pins>;
+ dual_emac;
+};
+
+/* Misc */
+&am33xx_pinmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&cb_gpio_pins>;
+
+ cb_gpio_pins: pinmux_cb_gpio {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x968, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* uart0_ctsn.gpio1_8 */
+ AM33XX_IOPAD(0x96c, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* uart0_rtsn.gpio1_9 */
+ >;
+ };
+};
+
+/* MMC */
+&am33xx_pinmux {
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x8f0, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat3.mmc0_dat3 */
+ AM33XX_IOPAD(0x8f4, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat2.mmc0_dat2 */
+ AM33XX_IOPAD(0x8f8, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat1.mmc0_dat1 */
+ AM33XX_IOPAD(0x8fc, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat0.mmc0_dat0 */
+ AM33XX_IOPAD(0x900, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_clk.mmc0_clk */
+ AM33XX_IOPAD(0x904, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_cmd.mmc0_cmd */
+ AM33XX_IOPAD(0x960, PIN_INPUT_PULLUP | MUX_MODE7) /* spi0_cs1.mmc0_sdcd */
+ >;
+ };
+};
+
+&mmc1 {
+ vmmc-supply = <&vcc3v3>;
+ bus-width = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+/* Power */
+&vcc3v3 {
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+};
+
+&vcc1v8 {
+ regulator-name = "vcc1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+};
+
+/* UARTs */
+&am33xx_pinmux {
+ uart0_pins: pinmux_uart0 {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x970, PIN_INPUT_PULLUP | MUX_MODE0) /* uart0_rxd.uart0_rxd */
+ AM33XX_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* uart0_txd.uart0_txd */
+ >;
+ };
+
+ uart1_pins: pinmux_uart1 {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x980, PIN_INPUT_PULLUP | MUX_MODE0) /* uart1_rxd.uart1_rxd */
+ AM33XX_IOPAD(0x984, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* uart1_txd.uart1_txd */
+ AM33XX_IOPAD(0x978, PIN_INPUT | MUX_MODE0) /* uart1_ctsn.uart1_ctsn */
+ AM33XX_IOPAD(0x97c, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* uart1_rtsn.uart1_rtsn */
+ >;
+ };
+
+ uart2_pins: pinmux_uart2 {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x92c, PIN_INPUT_PULLUP | MUX_MODE1) /* mii1_tx_clk.uart2_rxd */
+ AM33XX_IOPAD(0x930, PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* mii1_rx_clk.uart2_txd */
+ >;
+ };
+
+ uart3_pins: pinmux_uart3 {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x934, PIN_INPUT_PULLUP | MUX_MODE1) /* mii1_rxd3.uart3_rxd */
+ AM33XX_IOPAD(0x938, PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* mii1_rxd2.uart3_txd */
+ >;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins>;
+ status = "okay";
+};
+
+/* USB */
+&cppi41dma {
+ status = "okay";
+};
+
+&usb_ctrl_mod {
+ status = "okay";
+};
+
+&usb {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb0_phy {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+ dr_mode = "host";
+};
+
+&usb1_phy {
+ status = "okay";
+};
+
+/* User IO */
+&am33xx_pinmux {
+ user_buttons_pins: pinmux_user_buttons {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x9e4, PIN_INPUT_PULLDOWN | MUX_MODE7) /* emu0.gpio3_7 */
+ AM33XX_IOPAD(0x9e8, PIN_INPUT_PULLDOWN | MUX_MODE7) /* emu1.gpio3_8 */
+ >;
+ };
+
+ user_leds_pins: pinmux_user_leds {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x880, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_csn1.gpio1_30 */
+ AM33XX_IOPAD(0x884, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_csn2.gpio1_31 */
+ >;
+ };
+};
+
+&user_buttons {
+ pinctrl-names = "default";
+ pinctrl-0 = <&user_buttons_pins>;
+ status = "okay";
+
+ button@0 {
+ label = "home";
+ linux,code = <KEY_HOME>;
+ gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+ gpio-key,wakeup;
+ };
+
+ button@1 {
+ label = "menu";
+ linux,code = <KEY_MENU>;
+ gpios = <&gpio3 8 GPIO_ACTIVE_HIGH>;
+ gpio-key,wakeup;
+ };
+};
+
+&user_leds {
+ pinctrl-names = "default";
+ pinctrl-0 = <&user_leds_pins>;
+ status = "okay";
+
+ green {
+ label = "green:user";
+ gpios = <&gpio1 30 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "gpio";
+ default-state = "on";
+ };
+
+ yellow {
+ label = "yellow:user";
+ gpios = <&gpio1 31 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "gpio";
+ default-state = "on";
+ };
+};
diff --git a/arch/arm/boot/dts/am335x-phycore-rdk.dts b/arch/arm/boot/dts/am335x-phycore-rdk.dts
new file mode 100644
index 0000000..305f0b3
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-phycore-rdk.dts
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2014 PHYTEC Messtechnik GmbH
+ * Author: Wadim Egorov <w.egorov@phytec.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include "am335x-phycore-som.dtsi"
+#include "am335x-pcm-953.dtsi"
+
+/* SoM */
+&i2c_eeprom {
+ status = "okay";
+};
+
+&i2c_rtc {
+ status = "okay";
+};
+
+&serial_flash {
+ status = "okay";
+
+};
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 09/13] sata: ahci: export ahci_do_hardreset() locally
From: Tejun Heo @ 2017-01-19 12:52 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Rob Herring, Mark Rutland, Russell King, David Lechner,
linux-ide-u79uwXL29TY76Z2rM5mHXA, linux-devicetree, LKML, arm-soc
In-Reply-To: <CAMpxmJULuF3cB7+Vy_qeWkTjooHvx8yk70w59Q=XNd0aAREcuw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Jan 19, 2017 at 11:55:24AM +0100, Bartosz Golaszewski wrote:
> 2017-01-18 19:28 GMT+01:00 Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> > Hello, Bartosz.
> >
> > On Wed, Jan 18, 2017 at 02:19:57PM +0100, Bartosz Golaszewski wrote:
> >> We need a way to retrieve the information about the online state of
> >> the link in the ahci-da850 driver.
> >>
> >> Create a new function: ahci_do_hardreset() which is called from
> >> ahci_hardreset() for backwards compatibility, but has an additional
> >> argument: 'online' - which can be used to check if the link is online
> >> after this function returns.
> >
> > Please just add @online to ahci_hardreset() and update the callers.
> > Other than that, the sata changes look good to me.
> >
>
> Are you sure? There are 23 places in drivers/ata/ where the .hardreset
> callback is assigned. I'd prefer not to change the drivers I can't
> test. Besides all other **reset callbacks take three arguments -
> should we really only change one of them for a single driver's needs?
Ah, didn't realize this was the callback, sorry. What you did is
perfect. Please disregard my comment.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Ulf Hansson @ 2017-01-19 12:50 UTC (permalink / raw)
To: Matt Ranostay
Cc: Shawn Lin, linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel, linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tony Lindgren
In-Reply-To: <CAJ_EiSSQF_2pRaYdUBbKzbHt=1pn3NBrz8C5B7Dta9x7xqZ8oA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 18 January 2017 at 08:50, Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org> wrote:
> On Sun, Jan 15, 2017 at 6:35 PM, Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
>> On 2017/1/16 5:41, Matt Ranostay wrote:
>>>
>>> On Thu, Jan 12, 2017 at 11:16 PM, Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>>> wrote:
>>>>
>>>> On 2017/1/13 13:29, Matt Ranostay wrote:
>>>>>
>>>>>
>>>>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>>>>> This can be abstracted to other chipsets if needed in the future.
>>>>>
>>>>> Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>>>>> Cc: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>>> Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
>>>>> ---
>>>>> drivers/mmc/core/Kconfig | 10 ++++
>>>>> drivers/mmc/core/Makefile | 1 +
>>>>> drivers/mmc/core/pwrseq_sd8787.c | 117
>>>>> +++++++++++++++++++++++++++++++++++++++
>>>>> 3 files changed, 128 insertions(+)
>>>>> create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>>>>
>>>>> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
>>>>> index cdfa8520a4b1..fc1ecdaaa9ca 100644
>>>>> --- a/drivers/mmc/core/Kconfig
>>>>> +++ b/drivers/mmc/core/Kconfig
>>>>> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
>>>>> This driver can also be built as a module. If so, the module
>>>>> will be called pwrseq_emmc.
>>>>>
>>>>> +config PWRSEQ_SD8787
>>>>> + tristate "HW reset support for SD8787 BT + Wifi module"
>>>>> + depends on OF && (MWIFIEX || BT_MRVL_SDIO)
>>>>> + help
>>>>> + This selects hardware reset support for the SD8787 BT + Wifi
>>>>> + module. By default this option is set to n.
>>>>> +
>>>>> + This driver can also be built as a module. If so, the module
>>>>> + will be called pwrseq_sd8787.
>>>>> +
>>>>
>>>>
>>>>
>>>> I don't like this way, as we have a chance to list lots
>>>> configure options here. wifi A,B,C,D...Z, all of them need a
>>>> new section here if needed?
>>>>
>>>> Instead, could you just extent pwrseq_simple.c and add you
>>>> .compatible = "mmc-pwrseq-sd8787", "mmc-pwrseq-simple"?
>>>
>>>
>>> You mean all the chipset pwrseqs linked into the pwrseq-simple module?
>>
>>
>> What I mean was if you just extent the pwrseq-simple a bit, you could
>> just add your chipset pwrseqs linked into the pwrseq-simple. But if you
>> need a different *pattern* of pwrseqs, you should need a new name, for
>> instance, pwrseq-sdio.c etc... But please don't use the name of
>> sd8787? So if I use a wifi named ABC but using the same pwrseq pattenr,
>> should I include your "mmc-pwrseq- sd8787" for that or I need a new
>> mmc-pwrseq-ABC.c?
>
> Ah so pwrseq-sdio.c seems reasonable and having chipsets functions
> defined in a structure. That could be abstracted out for other
> chipsets that could needed in the future.
I think get the idea and it seems reasonable. With that in mind, I
have looked at the code once more and I got some new ideas on how to
adopt pwrseq-simple for your case.
I post the comments separately.
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: dts: fix SolidRun iMX6 platforms
From: Russell King @ 2017-01-19 12:44 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer
Cc: Mark Rutland, devicetree, Rob Herring, Shawn Guo,
linux-arm-kernel
Removal of skeleton.dtsi from imx6qdl.dtsi caused a regression on
SolidRun platforms as the /chosen and /memory nodes are no longer
populated. Fix this by adding the nodes into the platform .dtsi
files.
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.10.0-rc3+ (rmk@rmk-PC.arm.linux.org.uk) (gcc version 4.7.4 (GCC) ) #2066 SMP Thu Jan 19 12:31:19 GMT 2017
CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt:Machine model: SolidRun Cubox-i Dual/Quad
INITRD: 0x20000000+0x001cd000 is not a memory region - disabling initrd
cma: Failed to reserve 256 MiB
Memory policy: Data cache writealloc
Kernel panic - not syncing: ERROR: Failed to allocate 0x2000 bytes below 0x0.
CPU: 0 PID: 0 Comm: swapper Not tainted 4.10.0-rc3+ #2066
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace: invalid frame pointer 0xc09e5e44c
---[ end Kernel panic - not syncing: ERROR: Failed to allocate 0x2000 bytes below 0x0.
Fixes: 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/imx6qdl-cubox-i.dtsi | 6 ++++++
arch/arm/boot/dts/imx6qdl-hummingboard.dtsi | 2 ++
2 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
index ff41f83551de..69e3a848ee74 100644
--- a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
@@ -44,6 +44,12 @@
#include <dt-bindings/gpio/gpio.h>
/ {
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ memory { device_type = "memory"; reg = <0 0>; };
+
ir_recv: ir-receiver {
compatible = "gpio-ir-receiver";
gpios = <&gpio3 9 1>;
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
index a5e5356cdc6a..ae2feb882193 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
@@ -46,6 +46,8 @@
stdout-path = &uart1;
};
+ memory { device_type = "memory"; reg = <0 0>; };
+
ir_recv: ir-receiver {
compatible = "gpio-ir-receiver";
gpios = <&gpio3 5 GPIO_ACTIVE_LOW>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 4/6] arm64: dts: mt8173: add reference clock for usb
From: Matthias Brugger @ 2017-01-19 12:23 UTC (permalink / raw)
To: Greg Kroah-Hartman, Chunfeng Yun
Cc: Mathias Nyman, Felipe Balbi, Rob Herring, Mark Rutland,
Ian Campbell, linux-kernel, linux-arm-kernel, linux-usb,
linux-mediatek, devicetree
In-Reply-To: <20170119093747.GA17213@kroah.com>
On 19/01/17 10:37, Greg Kroah-Hartman wrote:
> On Wed, Jan 18, 2017 at 02:08:25PM +0800, Chunfeng Yun wrote:
>> add 26M reference clock for ssusb and xhci nodes
>>
>> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> This patch doesn't apply to my tree :(
>
This patch should go through my tree, but take into account my comment
on patch 3/6. From my point of view this series is not ready to be merged.
Regards,
Matthias
^ permalink raw reply
* Re: [PATCH 2/6] usb: mtu3: add reference clock
From: Matthias Brugger @ 2017-01-19 12:22 UTC (permalink / raw)
To: Chunfeng Yun, Mathias Nyman, Felipe Balbi
Cc: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Ian Campbell,
linux-kernel, linux-arm-kernel, linux-usb, linux-mediatek,
devicetree
In-Reply-To: <1484719707-12107-2-git-send-email-chunfeng.yun@mediatek.com>
On 18/01/17 07:08, Chunfeng Yun wrote:
> usually, the reference clock comes from 26M oscillator directly,
> but some SoCs are not, add it for compatibility.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> drivers/usb/mtu3/mtu3.h | 1 +
> drivers/usb/mtu3/mtu3_plat.c | 21 +++++++++++++++++++--
> 2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
> index ba9df71..aa6fd6a 100644
> --- a/drivers/usb/mtu3/mtu3.h
> +++ b/drivers/usb/mtu3/mtu3.h
> @@ -225,6 +225,7 @@ struct ssusb_mtk {
> /* common power & clock */
> struct regulator *vusb33;
> struct clk *sys_clk;
> + struct clk *ref_clk;
> /* otg */
> struct otg_switch_mtk otg_switch;
> enum usb_dr_mode dr_mode;
> diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
> index 6344859..19a345d 100644
> --- a/drivers/usb/mtu3/mtu3_plat.c
> +++ b/drivers/usb/mtu3/mtu3_plat.c
> @@ -123,7 +123,13 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
> ret = clk_prepare_enable(ssusb->sys_clk);
> if (ret) {
> dev_err(ssusb->dev, "failed to enable sys_clk\n");
> - goto clk_err;
> + goto sys_clk_err;
> + }
> +
> + ret = clk_prepare_enable(ssusb->ref_clk);
> + if (ret) {
> + dev_err(ssusb->dev, "failed to enable ref_clk\n");
> + goto ref_clk_err;
> }
>
> ret = ssusb_phy_init(ssusb);
> @@ -143,8 +149,10 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
> phy_err:
> ssusb_phy_exit(ssusb);
> phy_init_err:
> + clk_disable_unprepare(ssusb->ref_clk);
> +ref_clk_err:
> clk_disable_unprepare(ssusb->sys_clk);
> -clk_err:
> +sys_clk_err:
> regulator_disable(ssusb->vusb33);
> vusb33_err:
>
> @@ -154,6 +162,7 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
> static void ssusb_rscs_exit(struct ssusb_mtk *ssusb)
> {
> clk_disable_unprepare(ssusb->sys_clk);
> + clk_disable_unprepare(ssusb->ref_clk);
> regulator_disable(ssusb->vusb33);
> ssusb_phy_power_off(ssusb);
> ssusb_phy_exit(ssusb);
> @@ -216,6 +225,12 @@ static int get_ssusb_rscs(struct platform_device *pdev, struct ssusb_mtk *ssusb)
> return PTR_ERR(ssusb->sys_clk);
> }
>
> + ssusb->ref_clk = devm_clk_get(dev, "ref_ck");
> + if (IS_ERR(ssusb->ref_clk)) {
> + dev_err(dev, "failed to get ref clock\n");
> + return PTR_ERR(ssusb->ref_clk);
> + }
> +
That would break older dts bindings, right?
ref_ck must be optional for the code.
Regards,
Matthias
^ permalink raw reply
* Re: [PATCH RESEND v8 1/4] arm64: arch_timer: Add device tree binding for hisilicon-161010101 erratum
From: Ding Tianhong @ 2017-01-19 12:18 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree, marc.zyngier, catalin.marinas, will.deacon,
stuart.yoder, linuxarm, oss, shawnguo, linux-arm-kernel
In-Reply-To: <20170119121008.GE11176@leverpostej>
On 2017/1/19 20:10, Mark Rutland wrote:
> On Thu, Jan 19, 2017 at 07:46:43PM +0800, Ding Tianhong wrote:
>> This erratum describes a bug in logic outside the core, so MIDR can't be
>> used to identify its presence, and reading an SoC-specific revision
>> register from common arch timer code would be awkward. So, describe it
>> in the device tree.
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> ---
>> Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
>> index ad440a2..9116934 100644
>> --- a/Documentation/devicetree/bindings/arm/arch_timer.txt
>> +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
>> @@ -31,6 +31,14 @@ to deliver its interrupts via SPIs.
>> This also affects writes to the tval register, due to the implicit
>> counter read.
>>
>> +- hisilicon,erratum-161010101 : A boolean property. Indicates the presence of
>> + erratum 161010101, which says that reading the counter is unreliable unless
>> + reading twice on the register and the value of the second read is larger
>> + than the first by less than 32. If the verification is unsuccessful, then
>> + discard the value of this read and repeat this procedure until the verification
>> + is successful. This also affects writes to the tval register, due to the
>> + implicit counter read.
>
> This describes the workaround, which shouldn't be necessary.
>
> My understanding (from the cover letter) is that reads of the
> {virtual,physical} counters may return a value precisely 32 above the
> true value.
>
> So it would be better to say:
>
> - hisilicon,erratum-161010101 : A boolean property. Indicates the
> presence of Hisilicon erratum 161010101, which says that reading the
> counters is unreliable in some cases, and reads may return a value 32
> beyond the correct value. This also affects writes to the tval
> registers, due to the implicit counter read.
>
> Thanks,
> Mark.
Looks more accurate.
Thanks.
Ding
>
> .
>
^ permalink raw reply
* Re: [PATCH v8 2/4] arm64: arch_timer: Introduce a generic erratum handing mechanism for fsl-a008585
From: Ding Tianhong @ 2017-01-19 12:16 UTC (permalink / raw)
To: Marc Zyngier, catalin.marinas, will.deacon, mark.rutland, oss,
devicetree, shawnguo, stuart.yoder, linux-arm-kernel, linuxarm
In-Reply-To: <eeab7907-77c3-163c-f489-319012a13913@arm.com>
On 2017/1/19 19:59, Marc Zyngier wrote:
> On 19/01/17 11:14, Ding Tianhong wrote:
>> The workaround for hisilicon,161010101 will check the return value of the system counter
>> by different way, in order to distinguish with the fsl-a008585 workaround, introduce
>> a new generic erratum handing mechanism for fsl-a008585 and rename some functions.
>>
>> After discussion with Marc and Will, a consensus decision was made to remove the commandline
>> parameter for enabling fsl,erratum-a008585 erratum.
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 9 --
>> arch/arm64/include/asm/arch_timer.h | 38 +++------
>> drivers/clocksource/Kconfig | 8 ++
>> drivers/clocksource/arm_arch_timer.c | 105 ++++++++++++++----------
>> 4 files changed, 84 insertions(+), 76 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 21e2d88..76437ad 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -539,15 +539,6 @@
>> loops can be debugged more effectively on production
>> systems.
>>
>> - clocksource.arm_arch_timer.fsl-a008585=
>> - [ARM64]
>> - Format: <bool>
>> - Enable/disable the workaround of Freescale/NXP
>> - erratum A-008585. This can be useful for KVM
>> - guests, if the guest device tree doesn't show the
>> - erratum. If unspecified, the workaround is
>> - enabled based on the device tree.
>> -
>> clearcpuid=BITNUM [X86]
>> Disable CPUID feature X for the kernel. See
>> arch/x86/include/asm/cpufeatures.h for the valid bit
>> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
>> index eaa5bbe..b4b3400 100644
>> --- a/arch/arm64/include/asm/arch_timer.h
>> +++ b/arch/arm64/include/asm/arch_timer.h
>> @@ -29,41 +29,29 @@
>>
>> #include <clocksource/arm_arch_timer.h>
>>
>> -#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
>> +#if IS_ENABLED(CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND)
>> extern struct static_key_false arch_timer_read_ool_enabled;
>> -#define needs_fsl_a008585_workaround() \
>> +#define needs_unstable_timer_counter_workaround() \
>> static_branch_unlikely(&arch_timer_read_ool_enabled)
>> #else
>> -#define needs_fsl_a008585_workaround() false
>> +#define needs_unstable_timer_counter_workaround() false
>> #endif
>>
>> -u32 __fsl_a008585_read_cntp_tval_el0(void);
>> -u32 __fsl_a008585_read_cntv_tval_el0(void);
>> -u64 __fsl_a008585_read_cntvct_el0(void);
>>
>> -/*
>> - * The number of retries is an arbitrary value well beyond the highest number
>> - * of iterations the loop has been observed to take.
>> - */
>> -#define __fsl_a008585_read_reg(reg) ({ \
>> - u64 _old, _new; \
>> - int _retries = 200; \
>> - \
>> - do { \
>> - _old = read_sysreg(reg); \
>> - _new = read_sysreg(reg); \
>> - _retries--; \
>> - } while (unlikely(_old != _new) && _retries); \
>> - \
>> - WARN_ON_ONCE(!_retries); \
>> - _new; \
>> -})
>> +struct arch_timer_erratum_workaround {
>> + const char *id; /* Indicate the Erratum ID */
>> + u32 (*read_cntp_tval_el0)(void);
>> + u32 (*read_cntv_tval_el0)(void);
>> + u64 (*read_cntvct_el0)(void);
>> +};
>> +
>> +extern const struct arch_timer_erratum_workaround *timer_unstable_counter_workaround;
>>
>> #define arch_timer_reg_read_stable(reg) \
>> ({ \
>> u64 _val; \
>> - if (needs_fsl_a008585_workaround()) \
>> - _val = __fsl_a008585_read_##reg(); \
>> + if (needs_unstable_timer_counter_workaround()) \
>> + _val = timer_unstable_counter_workaround->read_##reg();\
>> else \
>> _val = read_sysreg(reg); \
>> _val; \
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index 4866f7a..04c2b93 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -325,10 +325,18 @@ config ARM_ARCH_TIMER_EVTSTREAM
>> This must be disabled for hardware validation purposes to detect any
>> hardware anomalies of missing events.
>>
>> +config ARM_ARCH_TIMER_OOL_WORKAROUND
>> + bool "Workaround for arm arch timer unstable counter"
>
> Please drop the message. We don't want that option to be selectable by a
> user, but only selected if an erratum that depends on it is enabled.
>
OK
Thanks
Ding
>> + depends on FSL_ERRATUM_A008585
>> + help
>> + This option would only be enabled by Freescale/NXP Erratum A-008585
>> + or something else chip has similar erratum.
>> +
>> config FSL_ERRATUM_A008585
>> bool "Workaround for Freescale/NXP Erratum A-008585"
>> default y
>> depends on ARM_ARCH_TIMER && ARM64
>> + select ARM_ARCH_TIMER_OOL_WORKAROUND
>> help
>> This option enables a workaround for Freescale/NXP Erratum
>> A-008585 ("ARM generic timer may contain an erroneous
>
> Thanks,
>
> M.
>
^ permalink raw reply
* Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core
From: Roger Quadros @ 2017-01-19 12:15 UTC (permalink / raw)
To: Vivek Gautam, Felipe Balbi
Cc: Peter Chen, Yoshihiro Shimoda, peter.chen, Tony Lindgren, Greg KH,
dan.j.williams, Mathias Nyman, Joao.Pinto, Sergei Shtylyov,
jun.li, grygorii.strashko, Rob Herring, nsekhar, b-liu,
Joe Perches, Linux USB Mailing List, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <CAFp+6iEpnHTWQe196zWPJu3vqb+L=47rfU_8nfuUNC=Gjvc8Gg@mail.gmail.com>
Vivek,
On 19/01/17 13:56, Vivek Gautam wrote:
> Hi,
>
>
> On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros <rogerq@ti.com> wrote:
>
> Luckily hit this thread while checking about DRD role functionality for DWC3.
>
>> On 22/06/16 11:14, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Roger Quadros <rogerq@ti.com> writes:
>>>>>>>>>>>> For the real use case, some Carplay platforms need it.
>>>>>>>>>>>
>>>>>>>>>>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>>>>>>>>>>> specification which is not OTG-compliant.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
>>>>>>>>>> states to finish role swap.
>>>>>>>>>
>>>>>>>>> What are you referring to as "finish role swap"? I don't get that.
>>>>>>>>
>>>>>>>> Change current role from host to peripheral.
>>>>>>>
>>>>>>> Okay, we have two scenarios here:
>>>>>>>
>>>>>>> 1. You need full OTG compliance
>>>>>>>
>>>>>>> For this, granted, you need the state machine if your HW doesn't
>>>>>>> track it. This is a given. With only one user, however, perhaps
>>>>>>> we don't need a generic layer. There are not enough different
>>>>>>> setups to design a good enough generic layer. We will end up
>>>>>>> with a pseudo-generic framework which is coupled with its only
>>>>>>> user.
>>>>>>>
>>>>>>> 2. Dual-role support, without OTG compliance
>>>>>>>
>>>>>>> In this case, you don't need a stack. All you need is a signal
>>>>>>> to tell you state of ID pin and another to tell you state of
>>>>>>> VBUS level. If you have those, you don't need to walk an OTG
>>>>>>> state machine at all. You don't need any of those quirky OTG
>>>>>>> timers, agreed?
>>>>>>>
>>>>>>> Given the above, why would you even want to use a subset of OTG
>>>>>>> state machine to implement something that's _usually_ as simple
>>>>>>> as:
>>>>>>>
>>>>>>> 8<----------------------------------------------------------------------
>>>>>>> vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>>>>>>> id = read(ID_STATE); /* could be a gpio_get_value() */
>>>>>>>
>>>>>>> set_role(id);
>>>>>>> set_vbus(vbus);
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>
>>>>>> In fact, the individual driver can do it by itself. The chipidea driver
>>>>>> handles OTG and dual-role well currently. By considering this OTG/DRD
>>>>>> framework is worthwhile or not, we would like to see if it can
>>>>>> simplify DRD design for each driver, and can benefit the platforms which
>>>>>> has different drivers for host and peripheral to finish the role switch
>>>>>> well.
>>>>>
>>>>> simplify how? By adding unnecessary workqueues and a level indirection
>>>>> that just goes back to the same driver?
>>>>
>>>> What do you mean by same driver?
>>>
>>> dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
>>> layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
>>> layer jumps to a callback that goes back to dwc3 to e.g. start
>>> peripheral side.
>>>
>>> See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.
>>>
>>>> Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
>>>> be 3 totally independent drivers unlike dwc3 where you have a single
>>>> driver in control of both host and gadget.
>>>
>>> That's a totally different issue and one not being tackled by OTG
>>> layer, because there are no such users yet. We can't design anything
>>> based solely on speculation of what might happen.
>>>
>>> If there aren't enough users, there is no way to design a good generic
>>> layer.
>>>
>>>> Questions not clear to me are:
>>>>
>>>> 1) Which driver handles ID/VBUS events and makes a decision to do the
>>>> role swap? Probably the PHY/MUX driver?
>>>
>>> This is implementation dependent. For TI's USB subsystem, we have PMIC
>>> sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
>>> mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
>>> has no intervention.
>>>
>>> For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
>>> internal mux (much like TI's UTMI mailbox, but slightly different) to
>>> switch between a separate XHCI or a separate dwc3. The same mux can be
>>> put in HW-mode where SW has no intervention.
>>>
>>> In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
>>> driver just detects role (at least for Type-C based plats) and executes
>>> _DSM with correct arguments [1]. _DSM will program internal MUX, toggle
>>> VBUS and, for type-C, toggle VCONN when needed.
>>>
>>>> 2) How does it perform the role swap? Probably a register write to the
>>>> PHY/MUX without needing to stop/start controllers? Easy case is both
>>>> controllers can run in co-existence without interference. Is there any
>>>> platform other than dwc3 where this is not the case?
>>>
>>> Again speculation. But to answer your question, only dwc3 is in such a
>>> case today. But even for dwc3 we can have DRD with a much, much simpler
>>> setup as I have already explained.
>>>
>>>> 3) Even if host and gadget controllers can operate in coexistence,
>>>> there is no need for both to be running for embedded applications
>>>> which are usually power conservative. How can we achieve that?
>>>
>>> Now you're also speculating that you're running on embedded applications
>>> and that we _can_ power off parts of the IP. I happen to know that we
>>> can't power off XHCI part of dwc3 in TI's SoC because that's fed by same
>>> Clocks and power rails as the peripheral side.
>>>
>>> [1] https://lkml.org/lkml/2016/6/21/658
>>>
>> For TI's case it is dwc3 and you are implementing the role swap in the dwc3
>> driver where you do intend to remove the XHCI platform device. So I'm not
>> much concerned about that.
>>
>> I was concerned about other platforms. I guess I'll let the other platform
>> people speak up as to what they need.
>
> I will talk about the msm platforms using dwc3 hardware.
> DWC3 controller on msm doesn't seem to have full otg functionality,
> and the driver makes use of switching between host and device
> using PRTCAPDIR register in of the core [1].
>
> We plan to support this DRD role switching (swapping host and device
> functionality based on id/vbus interrupts) in upstream.
>
> Do we see a valid case to have this framework?
Felipe wanted to have a minimal dual-role logic inside dwc3 which is
independent of any DRD/OTG framework.
I have implemented this and will send out patches today for review.
> Or, may be add a 'drd' layer for dwc3 that handles
> role switching (using PRTCAPDIR) based on the id/vbus extcon notifications.
>
>
> [1] https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/usb/dwc3/dwc3-msm.c?h=msm-3.18
> "dwc3_otg_start_host()"
> "dwc3_otg_start_peripheral()"
>
>
regards,
-roger
^ permalink raw reply
* Re: [PATCH RESEND v8 1/4] arm64: arch_timer: Add device tree binding for hisilicon-161010101 erratum
From: Mark Rutland @ 2017-01-19 12:10 UTC (permalink / raw)
To: Ding Tianhong
Cc: devicetree, marc.zyngier, catalin.marinas, will.deacon,
stuart.yoder, linuxarm, oss, shawnguo, linux-arm-kernel
In-Reply-To: <1484826406-16348-2-git-send-email-dingtianhong@huawei.com>
On Thu, Jan 19, 2017 at 07:46:43PM +0800, Ding Tianhong wrote:
> This erratum describes a bug in logic outside the core, so MIDR can't be
> used to identify its presence, and reading an SoC-specific revision
> register from common arch timer code would be awkward. So, describe it
> in the device tree.
>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
> index ad440a2..9116934 100644
> --- a/Documentation/devicetree/bindings/arm/arch_timer.txt
> +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
> @@ -31,6 +31,14 @@ to deliver its interrupts via SPIs.
> This also affects writes to the tval register, due to the implicit
> counter read.
>
> +- hisilicon,erratum-161010101 : A boolean property. Indicates the presence of
> + erratum 161010101, which says that reading the counter is unreliable unless
> + reading twice on the register and the value of the second read is larger
> + than the first by less than 32. If the verification is unsuccessful, then
> + discard the value of this read and repeat this procedure until the verification
> + is successful. This also affects writes to the tval register, due to the
> + implicit counter read.
This describes the workaround, which shouldn't be necessary.
My understanding (from the cover letter) is that reads of the
{virtual,physical} counters may return a value precisely 32 above the
true value.
So it would be better to say:
- hisilicon,erratum-161010101 : A boolean property. Indicates the
presence of Hisilicon erratum 161010101, which says that reading the
counters is unreliable in some cases, and reads may return a value 32
beyond the correct value. This also affects writes to the tval
registers, due to the implicit counter read.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: imx7: Add "LPSR" to LPSR iomux pin names
From: Fabio Estevam @ 2017-01-19 12:03 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Fabio Estevam, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Shawn Guo, Sascha Hauer
In-Reply-To: <20170119090924.19636-5-s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Thu, Jan 19, 2017 at 7:09 AM, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> The i.MX7 has two iomux controllers. the iomuxc and the iomuxc_lpsr.
> In a board dts we have to make sure that both controllers are supplied
> with the correct pins. It's way too easy to do this wrong since only
> a look into the reference manual can reveal which pins belong to which
> controller. To make this clearer add "LPSR" to the pin names which
> belong to the LPSR controller.
>
> Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
I like this idea!
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/4] ARM: dts: imx7d-cl-som: Fix OTG power pinctrl
From: Fabio Estevam @ 2017-01-19 12:02 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Fabio Estevam, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Shawn Guo, Sascha Hauer
In-Reply-To: <20170119090924.19636-4-s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Thu, Jan 19, 2017 at 7:09 AM, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> GPIO01_IO05 is controlled by the LPSR iomux controller, so attach
> the corresponding pin to this controller.
>
> Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/4] ARM: dts: imx7d-sdp: Fix watchdog and pwm pinmux
From: Fabio Estevam @ 2017-01-19 12:02 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Fabio Estevam, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Shawn Guo, Sascha Hauer
In-Reply-To: <20170119090924.19636-3-s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Thu, Jan 19, 2017 at 7:09 AM, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> The watchdog pin and the pwm output pin are controlled by the
> iomuxc_lpsr, not the regular iomux, so move the pins there.
>
> Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
Just two minor nits that probably Shawn can take care while applying it"
in Subject there is a typo "sdb".
> ---
> arch/arm/boot/dts/imx7d-sdb.dts | 26 ++++++++++++++------------
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
> index 2f33c463cbce..84f35a6cbb30 100644
> --- a/arch/arm/boot/dts/imx7d-sdb.dts
> +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> @@ -502,12 +502,6 @@
> >;
> };
>
> - pinctrl_pwm1: pwm1grp {
> - fsl,pins = <
> - MX7D_PAD_GPIO1_IO01__PWM1_OUT 0x110b0
> - >;
> - };
> -
> pinctrl_tsc2046_pendown: tsc2046_pendown {
> fsl,pins = <
> MX7D_PAD_EPDC_BDR1__GPIO2_IO29 0x59
> @@ -635,11 +629,19 @@
> MX7D_PAD_SD3_STROBE__SD3_STROBE 0x1b
> >;
> };
> -
> - pinctrl_wdog: wdoggrp {
> - fsl,pins = <
> - MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
> - >;
> - };
> };
> };
> +
> +&iomuxc_lpsr {
> + pinctrl_wdog: wdoggrp {
> + fsl,pins = <
> + MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
> + >;
> + };
> +
> + pinctrl_pwm1: pwm1grp {
> + fsl,pins = <
> + MX7D_PAD_GPIO1_IO01__PWM1_OUT 0x110b0
> + >;
> + };
> +};
> \ No newline at end of file
This could be fixed as well.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8 2/4] arm64: arch_timer: Introduce a generic erratum handing mechanism for fsl-a008585
From: Marc Zyngier @ 2017-01-19 11:59 UTC (permalink / raw)
To: Ding Tianhong, catalin.marinas, will.deacon, mark.rutland, oss,
devicetree, shawnguo, stuart.yoder, linux-arm-kernel, linuxarm
In-Reply-To: <1484824474-12172-3-git-send-email-dingtianhong@huawei.com>
On 19/01/17 11:14, Ding Tianhong wrote:
> The workaround for hisilicon,161010101 will check the return value of the system counter
> by different way, in order to distinguish with the fsl-a008585 workaround, introduce
> a new generic erratum handing mechanism for fsl-a008585 and rename some functions.
>
> After discussion with Marc and Will, a consensus decision was made to remove the commandline
> parameter for enabling fsl,erratum-a008585 erratum.
>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 9 --
> arch/arm64/include/asm/arch_timer.h | 38 +++------
> drivers/clocksource/Kconfig | 8 ++
> drivers/clocksource/arm_arch_timer.c | 105 ++++++++++++++----------
> 4 files changed, 84 insertions(+), 76 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 21e2d88..76437ad 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -539,15 +539,6 @@
> loops can be debugged more effectively on production
> systems.
>
> - clocksource.arm_arch_timer.fsl-a008585=
> - [ARM64]
> - Format: <bool>
> - Enable/disable the workaround of Freescale/NXP
> - erratum A-008585. This can be useful for KVM
> - guests, if the guest device tree doesn't show the
> - erratum. If unspecified, the workaround is
> - enabled based on the device tree.
> -
> clearcpuid=BITNUM [X86]
> Disable CPUID feature X for the kernel. See
> arch/x86/include/asm/cpufeatures.h for the valid bit
> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> index eaa5bbe..b4b3400 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -29,41 +29,29 @@
>
> #include <clocksource/arm_arch_timer.h>
>
> -#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
> +#if IS_ENABLED(CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND)
> extern struct static_key_false arch_timer_read_ool_enabled;
> -#define needs_fsl_a008585_workaround() \
> +#define needs_unstable_timer_counter_workaround() \
> static_branch_unlikely(&arch_timer_read_ool_enabled)
> #else
> -#define needs_fsl_a008585_workaround() false
> +#define needs_unstable_timer_counter_workaround() false
> #endif
>
> -u32 __fsl_a008585_read_cntp_tval_el0(void);
> -u32 __fsl_a008585_read_cntv_tval_el0(void);
> -u64 __fsl_a008585_read_cntvct_el0(void);
>
> -/*
> - * The number of retries is an arbitrary value well beyond the highest number
> - * of iterations the loop has been observed to take.
> - */
> -#define __fsl_a008585_read_reg(reg) ({ \
> - u64 _old, _new; \
> - int _retries = 200; \
> - \
> - do { \
> - _old = read_sysreg(reg); \
> - _new = read_sysreg(reg); \
> - _retries--; \
> - } while (unlikely(_old != _new) && _retries); \
> - \
> - WARN_ON_ONCE(!_retries); \
> - _new; \
> -})
> +struct arch_timer_erratum_workaround {
> + const char *id; /* Indicate the Erratum ID */
> + u32 (*read_cntp_tval_el0)(void);
> + u32 (*read_cntv_tval_el0)(void);
> + u64 (*read_cntvct_el0)(void);
> +};
> +
> +extern const struct arch_timer_erratum_workaround *timer_unstable_counter_workaround;
>
> #define arch_timer_reg_read_stable(reg) \
> ({ \
> u64 _val; \
> - if (needs_fsl_a008585_workaround()) \
> - _val = __fsl_a008585_read_##reg(); \
> + if (needs_unstable_timer_counter_workaround()) \
> + _val = timer_unstable_counter_workaround->read_##reg();\
> else \
> _val = read_sysreg(reg); \
> _val; \
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 4866f7a..04c2b93 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -325,10 +325,18 @@ config ARM_ARCH_TIMER_EVTSTREAM
> This must be disabled for hardware validation purposes to detect any
> hardware anomalies of missing events.
>
> +config ARM_ARCH_TIMER_OOL_WORKAROUND
> + bool "Workaround for arm arch timer unstable counter"
Please drop the message. We don't want that option to be selectable by a
user, but only selected if an erratum that depends on it is enabled.
> + depends on FSL_ERRATUM_A008585
> + help
> + This option would only be enabled by Freescale/NXP Erratum A-008585
> + or something else chip has similar erratum.
> +
> config FSL_ERRATUM_A008585
> bool "Workaround for Freescale/NXP Erratum A-008585"
> default y
> depends on ARM_ARCH_TIMER && ARM64
> + select ARM_ARCH_TIMER_OOL_WORKAROUND
> help
> This option enables a workaround for Freescale/NXP Erratum
> A-008585 ("ARM generic timer may contain an erroneous
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core
From: Vivek Gautam @ 2017-01-19 11:56 UTC (permalink / raw)
To: Roger Quadros, Felipe Balbi
Cc: Peter Chen, Yoshihiro Shimoda, peter.chen, Tony Lindgren, Greg KH,
dan.j.williams, Mathias Nyman, Joao.Pinto, Sergei Shtylyov,
jun.li, grygorii.strashko, Rob Herring, nsekhar, b-liu,
Joe Perches, Linux USB Mailing List, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <576A4C95.4080202@ti.com>
Hi,
On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros <rogerq@ti.com> wrote:
Luckily hit this thread while checking about DRD role functionality for DWC3.
> On 22/06/16 11:14, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Roger Quadros <rogerq@ti.com> writes:
>>>>>>>>>>> For the real use case, some Carplay platforms need it.
>>>>>>>>>>
>>>>>>>>>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>>>>>>>>>> specification which is not OTG-compliant.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
>>>>>>>>> states to finish role swap.
>>>>>>>>
>>>>>>>> What are you referring to as "finish role swap"? I don't get that.
>>>>>>>
>>>>>>> Change current role from host to peripheral.
>>>>>>
>>>>>> Okay, we have two scenarios here:
>>>>>>
>>>>>> 1. You need full OTG compliance
>>>>>>
>>>>>> For this, granted, you need the state machine if your HW doesn't
>>>>>> track it. This is a given. With only one user, however, perhaps
>>>>>> we don't need a generic layer. There are not enough different
>>>>>> setups to design a good enough generic layer. We will end up
>>>>>> with a pseudo-generic framework which is coupled with its only
>>>>>> user.
>>>>>>
>>>>>> 2. Dual-role support, without OTG compliance
>>>>>>
>>>>>> In this case, you don't need a stack. All you need is a signal
>>>>>> to tell you state of ID pin and another to tell you state of
>>>>>> VBUS level. If you have those, you don't need to walk an OTG
>>>>>> state machine at all. You don't need any of those quirky OTG
>>>>>> timers, agreed?
>>>>>>
>>>>>> Given the above, why would you even want to use a subset of OTG
>>>>>> state machine to implement something that's _usually_ as simple
>>>>>> as:
>>>>>>
>>>>>> 8<----------------------------------------------------------------------
>>>>>> vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>>>>>> id = read(ID_STATE); /* could be a gpio_get_value() */
>>>>>>
>>>>>> set_role(id);
>>>>>> set_vbus(vbus);
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>
>>>>> In fact, the individual driver can do it by itself. The chipidea driver
>>>>> handles OTG and dual-role well currently. By considering this OTG/DRD
>>>>> framework is worthwhile or not, we would like to see if it can
>>>>> simplify DRD design for each driver, and can benefit the platforms which
>>>>> has different drivers for host and peripheral to finish the role switch
>>>>> well.
>>>>
>>>> simplify how? By adding unnecessary workqueues and a level indirection
>>>> that just goes back to the same driver?
>>>
>>> What do you mean by same driver?
>>
>> dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
>> layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
>> layer jumps to a callback that goes back to dwc3 to e.g. start
>> peripheral side.
>>
>> See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.
>>
>>> Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
>>> be 3 totally independent drivers unlike dwc3 where you have a single
>>> driver in control of both host and gadget.
>>
>> That's a totally different issue and one not being tackled by OTG
>> layer, because there are no such users yet. We can't design anything
>> based solely on speculation of what might happen.
>>
>> If there aren't enough users, there is no way to design a good generic
>> layer.
>>
>>> Questions not clear to me are:
>>>
>>> 1) Which driver handles ID/VBUS events and makes a decision to do the
>>> role swap? Probably the PHY/MUX driver?
>>
>> This is implementation dependent. For TI's USB subsystem, we have PMIC
>> sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
>> mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
>> has no intervention.
>>
>> For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
>> internal mux (much like TI's UTMI mailbox, but slightly different) to
>> switch between a separate XHCI or a separate dwc3. The same mux can be
>> put in HW-mode where SW has no intervention.
>>
>> In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
>> driver just detects role (at least for Type-C based plats) and executes
>> _DSM with correct arguments [1]. _DSM will program internal MUX, toggle
>> VBUS and, for type-C, toggle VCONN when needed.
>>
>>> 2) How does it perform the role swap? Probably a register write to the
>>> PHY/MUX without needing to stop/start controllers? Easy case is both
>>> controllers can run in co-existence without interference. Is there any
>>> platform other than dwc3 where this is not the case?
>>
>> Again speculation. But to answer your question, only dwc3 is in such a
>> case today. But even for dwc3 we can have DRD with a much, much simpler
>> setup as I have already explained.
>>
>>> 3) Even if host and gadget controllers can operate in coexistence,
>>> there is no need for both to be running for embedded applications
>>> which are usually power conservative. How can we achieve that?
>>
>> Now you're also speculating that you're running on embedded applications
>> and that we _can_ power off parts of the IP. I happen to know that we
>> can't power off XHCI part of dwc3 in TI's SoC because that's fed by same
>> Clocks and power rails as the peripheral side.
>>
>> [1] https://lkml.org/lkml/2016/6/21/658
>>
> For TI's case it is dwc3 and you are implementing the role swap in the dwc3
> driver where you do intend to remove the XHCI platform device. So I'm not
> much concerned about that.
>
> I was concerned about other platforms. I guess I'll let the other platform
> people speak up as to what they need.
I will talk about the msm platforms using dwc3 hardware.
DWC3 controller on msm doesn't seem to have full otg functionality,
and the driver makes use of switching between host and device
using PRTCAPDIR register in of the core [1].
We plan to support this DRD role switching (swapping host and device
functionality based on id/vbus interrupts) in upstream.
Do we see a valid case to have this framework?
Or, may be add a 'drd' layer for dwc3 that handles
role switching (using PRTCAPDIR) based on the id/vbus extcon notifications.
[1] https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/usb/dwc3/dwc3-msm.c?h=msm-3.18
"dwc3_otg_start_host()"
"dwc3_otg_start_peripheral()"
Regards
Vivek
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 1/4] ARM: dts: imx7s-warp: Fix watchdog pinmux
From: Fabio Estevam @ 2017-01-19 11:56 UTC (permalink / raw)
To: Sascha Hauer
Cc: Fabio Estevam, devicetree@vger.kernel.org, Shawn Guo,
Sascha Hauer, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170119090924.19636-2-s.hauer@pengutronix.de>
On Thu, Jan 19, 2017 at 7:09 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> The watchdog pin is controlled by the iomuxc_lpsr, not the regular
> iomux, so move it there.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Laurent Pinchart @ 2017-01-19 11:49 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: Mark Rutland, Martyn Welch, Daniel Vetter, Peter Senna Tschudin,
Peter Senna Tschudin, dri-devel, linux-kernel@vger.kernel.org ,
Yakir Yang, Jiri Slaby, Rob Herring, Mauro Carvalho Chehab,
Russell King, Javier Martinez Canillas, Thierry Reding,
Guenter Roeck, martin.donnelly, devicetree@vger.kernel.org,
Pawel Moll, Ian Campbell, Fabio Estevam, Russell King,
linux-arm-kernel
In-Reply-To: <20170119092532.GB29457@collabora.com>
Hi Peter,
On Thursday 19 Jan 2017 10:25:32 Peter Senna Tschudin wrote:
> On Thu, Jan 19, 2017 at 10:17:45AM +0200, Laurent Pinchart wrote:
> > On Thursday 19 Jan 2017 09:12:14 Peter Senna Tschudin wrote:
> >> On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote:
> >>> On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote:
> >>>> On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote:
> >>>>> On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote:
> >>>>>> On 04 January, 2017 21:39 CET, Rob Herring wrote:
> >>>>>>> On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote:
> >>>>>>>> On 03 January, 2017 23:51 CET, Rob Herring <robh@kernel.org> wrote:
> >>>>>>>>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin
> > wrote:
> >>>>>>>>>> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> >>>>>>>>>> display bridge.
> >>>>>>>>>>
> >>>>>>>>>> Cc: Martyn Welch <martyn.welch@collabora.co.uk>
> >>>>>>>>>> Cc: Martin Donnelly <martin.donnelly@ge.com>
> >>>>>>>>>> Cc: Javier Martinez Canillas <javier@dowhile0.org>
> >>>>>>>>>> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >>>>>>>>>> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> >>>>>>>>>> Cc: Rob Herring <robh@kernel.org>
> >>>>>>>>>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> >>>>>>>>>> Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
> >>>>>>>>> ---
> >>>>>>>>>> There was an Acked-by from Rob Herring <robh@kernel.org> for
> >>>>>>>>>> V6, but I changed the bindings to use i2c_new_secondary_device()
> >>>>>>>>>> so I removed it from the commit message.
> >>
> >> [...]
> >>
> >>>>>>>>>> .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 +++++++++
> >>>>>>>>>
> >>>>>>>>> Isn't '-lvds-dp' redundant? The part# should be enough.
> >>>>>>>>
> >>>>>>>> b850v3 is the name of the product, this is why the proposed name.
> >>>>>>>> What about, b850v3-dp2 dp2 indicating the second DP output?
> >>>>>>>
> >>>>>> Humm, b850v3 is the board name? This node should be the name of
> >>>>>>> the bridge chip.
> >>>>>>
> >>>>>> From the cover letter:
> >>>>>>
> >>>>>> -- // --
> >>>>>> There are two physical bridges on the video signal pipeline: a
> >>>>>> STDP4028(LVDS to DP) and a STDP2690(DP to DP++). The hardware and
> >>>>>> firmware made it complicated for this binding to comprise two
> >>>>>> device tree nodes, as the design goal is to configure both bridges
> >>>>>> based on the LVDS signal, which leave the driver powerless to control
> >>>>>> the video processing pipeline. The two bridges behaves as a single
> >>>>>> bridge, and the driver is only needed for telling the host about EDID
> >>>>>> / HPD, and for giving the host powers to ack interrupts. The video
> >>>>>> signal pipeline
> >>>>>>
> >>>>>> is as follows:
> >>>>>> Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video
> >>>>>> output
> >>>>>>
> >>>>>> -- // --
> >>>>>
> >>>>> You forgot to prefix your patch series with [HACK] ;-)
> >>>>>
> >>>>> How about fixing the issues that make the two DT nodes solution
> >>>>> difficult ? What are they ?
> >>>>
> >>>> The Firmware and the hardware design. Both bridges, with stock
> >>>> firmware, are fully capable of providig EDID information and handling
> >>>> interrupts. But on this specific design, with this specific firmware, I
> >>>> need to read EDID from one bridge, and handle interrupts on the other.
> >>>
> >>> Which firmware are you talking about ? Firmware running on the
> >>> bridges, or somewhere else ?
> >>
> >> Each bridge has it's own external flash containing a binary firmware.
> >> The goal of the firmware is to configure the output end based on the
> >> input end. This is part of what makes handling EDID and HPD challenging.
> >>
> >>>> Back when I was starting the development I could not come up with a
> >>>> proper way to split EDID and interrupts between two bridges in a way
> >>>> that would result in a fully functional connector. Did I miss
> >>>> something?
> >>>
> >>> You didn't, we did :-) I've been telling for quite some time now that
> >>> we must decouple bridges from connectors, and this is another example of
> >>> why we have such a need. Bridges should expose additional functions
> >>> needed to implement connector operations, and the connector should be
> >>> instantiated by the display driver with the help of bridge operations.
> >>> You could then create a connector that relies on one bridge to read the
> >>> EDID and on the other bridge to handle HPD.
> >>
> >> Ah thanks. So for now the single DT node approach is acceptable, right?
> >> The problem is that even if the driver is getting better on each
> >> iteration, the single DT node for two chips issue comes back often and I
> >> believe is _the_ issue preventing the driver from getting upstream. V1
> >> was sent ~ 8 months ago...
> >>
> >> Can I have some blessing on the single DT node approach for now?
> >
> > With the "DT as an ABI" approach, I'm afraid not. Temporary hacks are
> > acceptable on the driver side, but you need two nodes in DT.
>
> So can I make two node DT "in the right way" and work around current
> connectors vs. bridge limitations on the driver side? This seems to be
> doable.
>
> Then I could fix bridge API, with my own driver and update API clients
> affected by the change...
I'm willing to discuss that as long as the DT bindings are correct, yes.
> >> I'm one of the 3 proposed maintainers for the driver, and I'm willing to
> >> maintain the driver on the long run, as is the same with the other two
> >> proposed maintainers. So when the time to split the node in two comes,
> >> we will be around, and willing to do it ourselves.
> >
> > How about putting that team of 3 maintainers to work on fixing the problem
> > in the bridge API ? :-)
>
> Guess you would be a good lawyer! My point was not exactly that we could
> work in parallel. Point was that there is redundancy in case one or two
> of us loose interest. But nice try! :-)
>
> Chances of having resources to fix bridge API and clients were better 6
> months ago, but let me see what I can get. Last blocking issue was the
> migration to atomic, now this. I'm going to need to answer what the next
> blocking issue is going to be.
>
> Actually in these ~8 months one bit of the required changes was
> accepted: dc80d7038883, but this was generic and not related to our
> specific use case.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH RESEND v8 4/4] arm64: arch timer: Add timer erratum property for Hip05-d02 and Hip06-d03
From: Ding Tianhong @ 2017-01-19 11:46 UTC (permalink / raw)
To: catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
marc.zyngier-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
oss-fOR+EgIDQEHk1uMJSBkQmQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, stuart.yoder-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxarm-hv44wF8Li93QT0dZR+AlfA
Cc: Ding Tianhong
In-Reply-To: <1484826406-16348-1-git-send-email-dingtianhong-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Enable workaround for hisilicon erratum 161010101 on Hip05-d02 and Hip06-d03 board.
Signed-off-by: Ding Tianhong <dingtianhong-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 +
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
index 4b472a3..6b76f3a 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
@@ -281,6 +281,7 @@
<GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
<GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
<GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ hisilicon,erratum-161010101;
};
pmu {
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index a049b64..cf8b9db 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -260,6 +260,7 @@
<GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
<GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
<GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ hisilicon,erratum-161010101;
};
pmu {
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH RESEND v8 3/4] arm64: arch_timer: Work around Erratum Hisilicon-161010101
From: Ding Tianhong @ 2017-01-19 11:46 UTC (permalink / raw)
To: catalin.marinas, will.deacon, marc.zyngier, mark.rutland, oss,
devicetree, shawnguo, stuart.yoder, linux-arm-kernel, linuxarm
Cc: Ding Tianhong
In-Reply-To: <1484826406-16348-1-git-send-email-dingtianhong@huawei.com>
Erratum Hisilicon-161010101 says that the ARM generic timer counter "has the
potential to contain an erroneous value when the timer value changes".
Accesses to TVAL (both read and write) are also affected due to the implicit counter
read. Accesses to CVAL are not affected.
The workaround is to reread the system count registers until the value of the second
read is larger than the first one by less than 32, the system counter can be guaranteed
not to return wrong value twice by back-to-back read and the error value is always larger
than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL.
The hisilicon erratum CONFIG name is too long, breaking the line format in silicon-errata.txt,
so extended the character spacing to fit all the erratum config.
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
Documentation/arm64/silicon-errata.txt | 43 ++++++++++++++---------------
drivers/clocksource/Kconfig | 12 ++++++++-
drivers/clocksource/arm_arch_timer.c | 49 ++++++++++++++++++++++++++++++++++
3 files changed, 82 insertions(+), 22 deletions(-)
diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index 405da11..0aaae35 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -42,24 +42,25 @@ file acts as a registry of software workarounds in the Linux Kernel and
will be updated when new workarounds are committed and backported to
stable kernels.
-| Implementor | Component | Erratum ID | Kconfig |
-+----------------+-----------------+-----------------+-------------------------+
-| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
-| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
-| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
-| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
-| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
-| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
-| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
-| ARM | Cortex-A57 | #852523 | N/A |
-| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
-| ARM | Cortex-A72 | #853709 | N/A |
-| ARM | MMU-500 | #841119,#826419 | N/A |
-| | | | |
-| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
-| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
-| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
-| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
-| Cavium | ThunderX SMMUv2 | #27704 | N/A |
-| | | | |
-| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
+| Implementor | Component | Erratum ID | Kconfig |
++----------------+-----------------+-----------------+---------------------------------+
+| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
+| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
+| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
+| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
+| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
+| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
+| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
+| ARM | Cortex-A57 | #852523 | N/A |
+| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
+| ARM | Cortex-A72 | #853709 | N/A |
+| ARM | MMU-500 | #841119,#826419 | N/A |
+| | | | |
+| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
+| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
+| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
+| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
+| Cavium | ThunderX SMMUv2 | #27704 | N/A |
+| | | | |
+| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
+| Hisilicon | Hip0{5,6,7} | #161010101 | HISILICON_ERRATUM_161010101 |
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 04c2b93..628cb44 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -327,7 +327,7 @@ config ARM_ARCH_TIMER_EVTSTREAM
config ARM_ARCH_TIMER_OOL_WORKAROUND
bool "Workaround for arm arch timer unstable counter"
- depends on FSL_ERRATUM_A008585
+ depends on FSL_ERRATUM_A008585 || HISILICON_ERRATUM_161010101
help
This option would only be enabled by Freescale/NXP Erratum A-008585
or something else chip has similar erratum.
@@ -343,6 +343,16 @@ config FSL_ERRATUM_A008585
value"). The workaround will only be active if the
fsl,erratum-a008585 property is found in the timer node.
+config HISILICON_ERRATUM_161010101
+ bool "Workaround for Hisilicon Erratum 161010101"
+ default y
+ select ARM_ARCH_TIMER_OOL_WORKAROUND
+ depends on ARM_ARCH_TIMER && ARM64
+ help
+ This option enables a workaround for Hisilicon Erratum
+ 161010101. The workaround will be active if the hisilicon,erratum-161010101
+ property is found in the timer node.
+
config ARM_GLOBAL_TIMER
bool "Support for the ARM global timer" if COMPILE_TEST
select CLKSRC_OF if OF
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 2487c66..7451b62 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -131,6 +131,47 @@ static u64 notrace fsl_a008585_read_cntvct_el0(void)
}
#endif
+#ifdef CONFIG_HISILICON_ERRATUM_161010101
+/*
+ * Verify whether the value of the second read is larger than the first by
+ * less than 32 is the only way to confirm the value is correct, so clear the
+ * lower 5 bits to check whether the difference is greater than 32 or not.
+ * Theoretically the erratum should not occur more than twice in succession
+ * when reading the system counter, but it is possible that some interrupts
+ * may lead to more than twice read errors, triggering the warning, so setting
+ * the number of retries far beyond the number of iterations the loop has been
+ * observed to take.
+ */
+#define __hisi_161010101_read_reg(reg) ({ \
+ u64 _old, _new; \
+ int _retries = 50; \
+ \
+ do { \
+ _old = read_sysreg(reg); \
+ _new = read_sysreg(reg); \
+ _retries--; \
+ } while (unlikely((_new - _old) >> 5) && _retries); \
+ \
+ WARN_ON_ONCE(!_retries); \
+ _new; \
+})
+
+static u32 notrace hisi_161010101_read_cntp_tval_el0(void)
+{
+ return __hisi_161010101_read_reg(cntp_tval_el0);
+}
+
+static u32 notrace hisi_161010101_read_cntv_tval_el0(void)
+{
+ return __hisi_161010101_read_reg(cntv_tval_el0);
+}
+
+static u64 notrace hisi_161010101_read_cntvct_el0(void)
+{
+ return __hisi_161010101_read_reg(cntvct_el0);
+}
+#endif
+
#ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND
const struct arch_timer_erratum_workaround *timer_unstable_counter_workaround = NULL;
EXPORT_SYMBOL_GPL(timer_unstable_counter_workaround);
@@ -147,6 +188,14 @@ static u64 notrace fsl_a008585_read_cntvct_el0(void)
.read_cntvct_el0 = fsl_a008585_read_cntvct_el0,
},
#endif
+#ifdef CONFIG_HISILICON_ERRATUM_161010101
+ {
+ .id = "hisilicon,erratum-161010101",
+ .read_cntp_tval_el0 = hisi_161010101_read_cntp_tval_el0,
+ .read_cntv_tval_el0 = hisi_161010101_read_cntv_tval_el0,
+ .read_cntvct_el0 = hisi_161010101_read_cntvct_el0,
+ },
+#endif
};
#endif /* CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND */
--
1.9.0
^ permalink raw reply related
* [PATCH RESEND v8 2/4] arm64: arch_timer: Introduce a generic erratum handing mechanism for fsl-a008585
From: Ding Tianhong @ 2017-01-19 11:46 UTC (permalink / raw)
To: catalin.marinas, will.deacon, marc.zyngier, mark.rutland, oss,
devicetree, shawnguo, stuart.yoder, linux-arm-kernel, linuxarm
Cc: Ding Tianhong
In-Reply-To: <1484826406-16348-1-git-send-email-dingtianhong@huawei.com>
The workaround for hisilicon,161010101 will check the return value of the system counter
by different way, in order to distinguish with the fsl-a008585 workaround, introduce
a new generic erratum handing mechanism for fsl-a008585 and rename some functions.
After discussion with Marc and Will, a consensus decision was made to remove the commandline
parameter for enabling fsl,erratum-a008585 erratum.
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
Documentation/admin-guide/kernel-parameters.txt | 9 --
arch/arm64/include/asm/arch_timer.h | 38 +++------
drivers/clocksource/Kconfig | 8 ++
drivers/clocksource/arm_arch_timer.c | 105 ++++++++++++++----------
4 files changed, 84 insertions(+), 76 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 21e2d88..76437ad 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -539,15 +539,6 @@
loops can be debugged more effectively on production
systems.
- clocksource.arm_arch_timer.fsl-a008585=
- [ARM64]
- Format: <bool>
- Enable/disable the workaround of Freescale/NXP
- erratum A-008585. This can be useful for KVM
- guests, if the guest device tree doesn't show the
- erratum. If unspecified, the workaround is
- enabled based on the device tree.
-
clearcpuid=BITNUM [X86]
Disable CPUID feature X for the kernel. See
arch/x86/include/asm/cpufeatures.h for the valid bit
diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
index eaa5bbe..b4b3400 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -29,41 +29,29 @@
#include <clocksource/arm_arch_timer.h>
-#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
+#if IS_ENABLED(CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND)
extern struct static_key_false arch_timer_read_ool_enabled;
-#define needs_fsl_a008585_workaround() \
+#define needs_unstable_timer_counter_workaround() \
static_branch_unlikely(&arch_timer_read_ool_enabled)
#else
-#define needs_fsl_a008585_workaround() false
+#define needs_unstable_timer_counter_workaround() false
#endif
-u32 __fsl_a008585_read_cntp_tval_el0(void);
-u32 __fsl_a008585_read_cntv_tval_el0(void);
-u64 __fsl_a008585_read_cntvct_el0(void);
-/*
- * The number of retries is an arbitrary value well beyond the highest number
- * of iterations the loop has been observed to take.
- */
-#define __fsl_a008585_read_reg(reg) ({ \
- u64 _old, _new; \
- int _retries = 200; \
- \
- do { \
- _old = read_sysreg(reg); \
- _new = read_sysreg(reg); \
- _retries--; \
- } while (unlikely(_old != _new) && _retries); \
- \
- WARN_ON_ONCE(!_retries); \
- _new; \
-})
+struct arch_timer_erratum_workaround {
+ const char *id; /* Indicate the Erratum ID */
+ u32 (*read_cntp_tval_el0)(void);
+ u32 (*read_cntv_tval_el0)(void);
+ u64 (*read_cntvct_el0)(void);
+};
+
+extern const struct arch_timer_erratum_workaround *timer_unstable_counter_workaround;
#define arch_timer_reg_read_stable(reg) \
({ \
u64 _val; \
- if (needs_fsl_a008585_workaround()) \
- _val = __fsl_a008585_read_##reg(); \
+ if (needs_unstable_timer_counter_workaround()) \
+ _val = timer_unstable_counter_workaround->read_##reg();\
else \
_val = read_sysreg(reg); \
_val; \
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 4866f7a..04c2b93 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -325,10 +325,18 @@ config ARM_ARCH_TIMER_EVTSTREAM
This must be disabled for hardware validation purposes to detect any
hardware anomalies of missing events.
+config ARM_ARCH_TIMER_OOL_WORKAROUND
+ bool "Workaround for arm arch timer unstable counter"
+ depends on FSL_ERRATUM_A008585
+ help
+ This option would only be enabled by Freescale/NXP Erratum A-008585
+ or something else chip has similar erratum.
+
config FSL_ERRATUM_A008585
bool "Workaround for Freescale/NXP Erratum A-008585"
default y
depends on ARM_ARCH_TIMER && ARM64
+ select ARM_ARCH_TIMER_OOL_WORKAROUND
help
This option enables a workaround for Freescale/NXP Erratum
A-008585 ("ARM generic timer may contain an erroneous
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 02fef68..2487c66 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -96,41 +96,59 @@ static int __init early_evtstrm_cfg(char *buf)
*/
#ifdef CONFIG_FSL_ERRATUM_A008585
-DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled);
-EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
-
-static int fsl_a008585_enable = -1;
-
-static int __init early_fsl_a008585_cfg(char *buf)
-{
- int ret;
- bool val;
- ret = strtobool(buf, &val);
- if (ret)
- return ret;
-
- fsl_a008585_enable = val;
- return 0;
-}
-early_param("clocksource.arm_arch_timer.fsl-a008585", early_fsl_a008585_cfg);
-
-u32 __fsl_a008585_read_cntp_tval_el0(void)
+/*
+ * The number of retries is an arbitrary value well beyond the highest number
+ * of iterations the loop has been observed to take.
+ */
+#define __fsl_a008585_read_reg(reg) ({ \
+ u64 _old, _new; \
+ int _retries = 200; \
+ \
+ do { \
+ _old = read_sysreg(reg); \
+ _new = read_sysreg(reg); \
+ _retries--; \
+ } while (unlikely(_old != _new) && _retries); \
+ \
+ WARN_ON_ONCE(!_retries); \
+ _new; \
+})
+
+static u32 notrace fsl_a008585_read_cntp_tval_el0(void)
{
return __fsl_a008585_read_reg(cntp_tval_el0);
}
-u32 __fsl_a008585_read_cntv_tval_el0(void)
+static u32 notrace fsl_a008585_read_cntv_tval_el0(void)
{
return __fsl_a008585_read_reg(cntv_tval_el0);
}
-u64 __fsl_a008585_read_cntvct_el0(void)
+static u64 notrace fsl_a008585_read_cntvct_el0(void)
{
return __fsl_a008585_read_reg(cntvct_el0);
}
-EXPORT_SYMBOL(__fsl_a008585_read_cntvct_el0);
-#endif /* CONFIG_FSL_ERRATUM_A008585 */
+#endif
+
+#ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND
+const struct arch_timer_erratum_workaround *timer_unstable_counter_workaround = NULL;
+EXPORT_SYMBOL_GPL(timer_unstable_counter_workaround);
+
+DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled);
+EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
+
+static const struct arch_timer_erratum_workaround ool_workarounds[] = {
+#ifdef CONFIG_FSL_ERRATUM_A008585
+ {
+ .id = "fsl,erratum-a008585",
+ .read_cntp_tval_el0 = fsl_a008585_read_cntp_tval_el0,
+ .read_cntv_tval_el0 = fsl_a008585_read_cntv_tval_el0,
+ .read_cntvct_el0 = fsl_a008585_read_cntvct_el0,
+ },
+#endif
+};
+#endif /* CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND */
static __always_inline
void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val,
@@ -281,8 +299,8 @@ static __always_inline void set_next_event(const int access, unsigned long evt,
arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
}
-#ifdef CONFIG_FSL_ERRATUM_A008585
-static __always_inline void fsl_a008585_set_next_event(const int access,
+#ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND
+static __always_inline void erratum_set_next_event_generic(const int access,
unsigned long evt, struct clock_event_device *clk)
{
unsigned long ctrl;
@@ -300,20 +318,20 @@ static __always_inline void fsl_a008585_set_next_event(const int access,
arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
}
-static int fsl_a008585_set_next_event_virt(unsigned long evt,
+static int erratum_set_next_event_virt(unsigned long evt,
struct clock_event_device *clk)
{
- fsl_a008585_set_next_event(ARCH_TIMER_VIRT_ACCESS, evt, clk);
+ erratum_set_next_event_generic(ARCH_TIMER_VIRT_ACCESS, evt, clk);
return 0;
}
-static int fsl_a008585_set_next_event_phys(unsigned long evt,
+static int erratum_set_next_event_phys(unsigned long evt,
struct clock_event_device *clk)
{
- fsl_a008585_set_next_event(ARCH_TIMER_PHYS_ACCESS, evt, clk);
+ erratum_set_next_event_generic(ARCH_TIMER_PHYS_ACCESS, evt, clk);
return 0;
}
-#endif /* CONFIG_FSL_ERRATUM_A008585 */
+#endif /* CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND */
static int arch_timer_set_next_event_virt(unsigned long evt,
struct clock_event_device *clk)
@@ -343,16 +361,16 @@ static int arch_timer_set_next_event_phys_mem(unsigned long evt,
return 0;
}
-static void fsl_a008585_set_sne(struct clock_event_device *clk)
+static void erratum_workaround_set_sne(struct clock_event_device *clk)
{
-#ifdef CONFIG_FSL_ERRATUM_A008585
+#ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND
if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
return;
if (arch_timer_uses_ppi == VIRT_PPI)
- clk->set_next_event = fsl_a008585_set_next_event_virt;
+ clk->set_next_event = erratum_set_next_event_virt;
else
- clk->set_next_event = fsl_a008585_set_next_event_phys;
+ clk->set_next_event = erratum_set_next_event_phys;
#endif
}
@@ -385,7 +403,7 @@ static void __arch_timer_setup(unsigned type,
BUG();
}
- fsl_a008585_set_sne(clk);
+ erratum_workaround_set_sne(clk);
} else {
clk->features |= CLOCK_EVT_FEAT_DYNIRQ;
clk->name = "arch_mem_timer";
@@ -605,7 +623,7 @@ static void __init arch_counter_register(unsigned type)
clocksource_counter.archdata.vdso_direct = true;
-#ifdef CONFIG_FSL_ERRATUM_A008585
+#ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND
/*
* Don't use the vdso fastpath if errata require using
* the out-of-line counter accessor.
@@ -893,12 +911,15 @@ static int __init arch_timer_of_init(struct device_node *np)
arch_timer_c3stop = !of_property_read_bool(np, "always-on");
-#ifdef CONFIG_FSL_ERRATUM_A008585
- if (fsl_a008585_enable < 0)
- fsl_a008585_enable = of_property_read_bool(np, "fsl,erratum-a008585");
- if (fsl_a008585_enable) {
- static_branch_enable(&arch_timer_read_ool_enabled);
- pr_info("Enabling workaround for FSL erratum A-008585\n");
+#ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND
+ for (i = 0; i < ARRAY_SIZE(ool_workarounds); i++) {
+ if (of_property_read_bool(np, ool_workarounds[i].id)) {
+ timer_unstable_counter_workaround = &ool_workarounds[i];
+ static_branch_enable(&arch_timer_read_ool_enabled);
+ pr_info("arch_timer: Enabling workaround for %s\n",
+ timer_unstable_counter_workaround->id);
+ break;
+ }
}
#endif
--
1.9.0
^ 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