* [U-Boot] [PATCH 2/7] mtd: nand: add support for the TC58NVG2S0H chip
From: Hans de Goede @ 2016-11-14 11:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <b535d6b27a3af2d2a927de1a788a12455c523b3d.1478621974.git-series.maxime.ripard@free-electrons.com>
Hi,
On 08-11-16 17:21, Maxime Ripard wrote:
> From: Boris Brezillon <boris.brezillon@free-electrons.com>
>
> Add the description of the Toshiba TC58NVG2S0H SLC nand to the nand_ids
> table so we can use the NAND ECC infos and the ONFI timings.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Looks good to me:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
> ---
> drivers/mtd/nand/nand_ids.c | 3 +++
> 1 file changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
> index ce0a14e28abb..d36f9006c99d 100644
> --- a/drivers/mtd/nand/nand_ids.c
> +++ b/drivers/mtd/nand/nand_ids.c
> @@ -46,6 +46,9 @@ struct nand_flash_dev nand_flash_ids[] = {
> {"TC58NVG2S0F 4G 3.3V 8-bit",
> { .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08} },
> SZ_4K, SZ_512, SZ_256K, 0, 8, 224, NAND_ECC_INFO(4, SZ_512) },
> + {"TC58NVG2S0H 4G 3.3V 8-bit",
> + { .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x16, 0x08, 0x00} },
> + SZ_4K, SZ_512, SZ_256K, 0, 8, 256, NAND_ECC_INFO(8, SZ_512) },
> {"TC58NVG3S0F 8G 3.3V 8-bit",
> { .id = {0x98, 0xd3, 0x90, 0x26, 0x76, 0x15, 0x02, 0x08} },
> SZ_4K, SZ_1K, SZ_256K, 0, 8, 232, NAND_ECC_INFO(4, SZ_512) },
>
^ permalink raw reply
* [U-Boot] [PATCH 1/7] sunxi: Sync GR8 DTS and AXP209 with the kernel
From: Hans de Goede @ 2016-11-14 11:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <5cdae97716aea75af27488d2bb4ac58bd99eb946.1478621974.git-series.maxime.ripard@free-electrons.com>
Hi,
On 08-11-16 17:21, Maxime Ripard wrote:
> Those DT will be part of 4.10, sync them so we can have our own config.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Looks good to me:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
> ---
> arch/arm/dts/Makefile | 1 +-
> arch/arm/dts/axp209.dtsi | 6 +-
> arch/arm/dts/ntc-gr8-chip-pro.dts | 266 +++++++-
> arch/arm/dts/ntc-gr8.dtsi | 1132 ++++++++++++++++++++++++++++++-
> 4 files changed, 1405 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/dts/ntc-gr8-chip-pro.dts
> create mode 100644 arch/arm/dts/ntc-gr8.dtsi
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 836a8c4d1ee2..932dbe07cf14 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -180,6 +180,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
> sun4i-a10-pcduino2.dtb \
> sun4i-a10-pov-protab2-ips9.dtb
> dtb-$(CONFIG_MACH_SUN5I) += \
> + ntc-gr8-chip-pro.dtb \
> sun5i-a10s-auxtek-t003.dtb \
> sun5i-a10s-auxtek-t004.dtb \
> sun5i-a10s-mk802.dtb \
> diff --git a/arch/arm/dts/axp209.dtsi b/arch/arm/dts/axp209.dtsi
> index afbe89c01df5..675bb0f30825 100644
> --- a/arch/arm/dts/axp209.dtsi
> +++ b/arch/arm/dts/axp209.dtsi
> @@ -53,6 +53,12 @@
> interrupt-controller;
> #interrupt-cells = <1>;
>
> + axp_gpio: gpio {
> + compatible = "x-powers,axp209-gpio";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> +
> regulators {
> /* Default work frequency for buck regulators */
> x-powers,dcdc-freq = <1500>;
> diff --git a/arch/arm/dts/ntc-gr8-chip-pro.dts b/arch/arm/dts/ntc-gr8-chip-pro.dts
> new file mode 100644
> index 000000000000..c4be912df481
> --- /dev/null
> +++ b/arch/arm/dts/ntc-gr8-chip-pro.dts
> @@ -0,0 +1,266 @@
> +/*
> + * Copyright 2016 Free Electrons
> + * Copyright 2016 NextThing Co
> + *
> + * Maxime Ripard <maxime.ripard@free-electrons.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "ntc-gr8.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/ {
> + model = "NextThing C.H.I.P. Pro";
> + compatible = "nextthing,chip-pro", "nextthing,gr8";
> +
> + aliases {
> + i2c0 = &i2c0;
> + i2c1 = &i2c1;
> + serial0 = &uart1;
> + serial1 = &uart2;
> + serial2 = &uart3;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + status {
> + label = "chip-pro:white:status";
> + gpios = <&axp_gpio 2 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> + };
> +
> + mmc0_pwrseq: mmc0_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";
> + pinctrl-0 = <&wifi_reg_on_pin_chip_pro>;
> + reset-gpios = <&pio 1 10 GPIO_ACTIVE_LOW>; /* PB10 */
> + };
> +};
> +
> +&codec {
> + status = "okay";
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
> +
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pins_a>;
> + status = "okay";
> +
> + axp209: pmic at 34 {
> + reg = <0x34>;
> +
> + /*
> + * The interrupt is routed through the "External Fast
> + * Interrupt Request" pin (ball G13 of the module)
> + * directly to the main interrupt controller, without
> + * any other controller interfering.
> + */
> + interrupts = <0>;
> + };
> +};
> +
> +#include "axp209.dtsi"
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins_a>;
> + status = "disabled";
> +};
> +
> +&i2s0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2s0_mclk_pins_a>, <&i2s0_data_pins_a>;
> + status = "disabled";
> +};
> +
> +&mmc0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins_a>;
> + vmmc-supply = <®_vcc3v3>;
> + mmc-pwrseq = <&mmc0_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +};
> +
> +&nfc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&nand_pins_a &nand_cs0_pins_a &nand_rb0_pins_a>;
> + status = "okay";
> +
> + nand at 0 {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + reg = <0>;
> + allwinner,rb = <0>;
> + nand-ecc-mode = "hw";
> + };
> +};
> +
> +&ohci0 {
> + status = "okay";
> +};
> +
> +&otg_sram {
> + status = "okay";
> +};
> +
> +&pio {
> + usb0_id_pin_chip_pro: usb0-id-pin at 0 {
> + allwinner,pins = "PG2";
> + allwinner,function = "gpio_in";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + wifi_reg_on_pin_chip_pro: wifi-reg-on-pin at 0 {
> + allwinner,pins = "PB10";
> + allwinner,function = "gpio_out";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +};
> +
> +&pwm {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwm0_pins_a>, <&pwm1_pins>;
> + status = "disabled";
> +};
> +
> +®_dcdc2 {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1400000>;
> + regulator-name = "vdd-cpu";
> + regulator-always-on;
> +};
> +
> +®_dcdc3 {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-name = "vdd-sys";
> + regulator-always-on;
> +};
> +
> +®_ldo1 {
> + regulator-name = "vdd-rtc";
> +};
> +
> +®_ldo2 {
> + regulator-min-microvolt = <2700000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "avcc";
> + regulator-always-on;
> +};
> +
> +/*
> + * Both LDO3 and LDO4 are used in parallel to power up the
> + * WiFi/BT chip.
> + */
> +®_ldo3 {
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc-wifi-1";
> + regulator-always-on;
> +};
> +
> +®_ldo4 {
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc-wifi-2";
> + regulator-always-on;
> +};
> +
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart1_pins_a>, <&uart1_cts_rts_pins_a>;
> + status = "okay";
> +};
> +
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart2_pins_a>, <&uart2_cts_rts_pins_a>;
> + status = "disabled";
> +};
> +
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart3_pins_a>, <&uart3_cts_rts_pins_a>;
> + status = "okay";
> +};
> +
> +&usb_otg {
> + /*
> + * The CHIP Pro doesn't have a controllable VBUS, nor does it
> + * have any 5v rail on the board itself.
> + *
> + * If one wants to use it as a true OTG port, it should be
> + * done in the baseboard, and its DT / overlay will add it.
> + */
> + dr_mode = "otg";
> + status = "okay";
> +};
> +
> +&usb_power_supply {
> + status = "okay";
> +};
> +
> +&usbphy {
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb0_id_pin_chip_pro>;
> + usb0_id_det-gpio = <&pio 6 2 GPIO_ACTIVE_HIGH>; /* PG2 */
> + usb0_vbus_power-supply = <&usb_power_supply>;
> + usb1_vbus-supply = <®_vcc5v0>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/ntc-gr8.dtsi b/arch/arm/dts/ntc-gr8.dtsi
> new file mode 100644
> index 000000000000..ea86d4d58db6
> --- /dev/null
> +++ b/arch/arm/dts/ntc-gr8.dtsi
> @@ -0,0 +1,1132 @@
> +/*
> + * Copyright 2016 Myl?ne Josserand
> + *
> + * Myl?ne Josserand <mylene.josserand@free-electrons.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include <dt-bindings/clock/sun4i-a10-pll2.h>
> +#include <dt-bindings/dma/sun4i-a10.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +
> +/ {
> + interrupt-parent = <&intc>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a8";
> + reg = <0x0>;
> + clocks = <&cpu>;
> + };
> + };
> +
> + clocks {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + /*
> + * This is a dummy clock, to be used as placeholder on
> + * other mux clocks when a specific parent clock is not
> + * yet implemented. It should be dropped when the driver
> + * is complete.
> + */
> + dummy: dummy {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <0>;
> + };
> +
> + osc24M: clk at 01c20050 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-osc-clk";
> + reg = <0x01c20050 0x4>;
> + clock-frequency = <24000000>;
> + clock-output-names = "osc24M";
> + };
> +
> + osc3M: osc3M-clk {
> + compatible = "fixed-factor-clock";
> + #clock-cells = <0>;
> + clock-div = <8>;
> + clock-mult = <1>;
> + clocks = <&osc24M>;
> + clock-output-names = "osc3M";
> + };
> +
> + osc32k: clk at 0 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-output-names = "osc32k";
> + };
> +
> + pll1: clk at 01c20000 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-pll1-clk";
> + reg = <0x01c20000 0x4>;
> + clocks = <&osc24M>;
> + clock-output-names = "pll1";
> + };
> +
> + pll2: clk at 01c20008 {
> + #clock-cells = <1>;
> + compatible = "allwinner,sun5i-a13-pll2-clk";
> + reg = <0x01c20008 0x8>;
> + clocks = <&osc24M>;
> + clock-output-names = "pll2-1x", "pll2-2x",
> + "pll2-4x", "pll2-8x";
> + };
> +
> + pll3: clk at 01c20010 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-pll3-clk";
> + reg = <0x01c20010 0x4>;
> + clocks = <&osc3M>;
> + clock-output-names = "pll3";
> + };
> +
> + pll3x2: pll3x2-clk {
> + compatible = "allwinner,sun4i-a10-pll3-2x-clk";
> + #clock-cells = <0>;
> + clock-div = <1>;
> + clock-mult = <2>;
> + clocks = <&pll3>;
> + clock-output-names = "pll3-2x";
> + };
> +
> + pll4: clk at 01c20018 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-pll1-clk";
> + reg = <0x01c20018 0x4>;
> + clocks = <&osc24M>;
> + clock-output-names = "pll4";
> + };
> +
> + pll5: clk at 01c20020 {
> + #clock-cells = <1>;
> + compatible = "allwinner,sun4i-a10-pll5-clk";
> + reg = <0x01c20020 0x4>;
> + clocks = <&osc24M>;
> + clock-output-names = "pll5_ddr", "pll5_other";
> + };
> +
> + pll6: clk at 01c20028 {
> + #clock-cells = <1>;
> + compatible = "allwinner,sun4i-a10-pll6-clk";
> + reg = <0x01c20028 0x4>;
> + clocks = <&osc24M>;
> + clock-output-names = "pll6_sata", "pll6_other", "pll6";
> + };
> +
> + pll7: clk at 01c20030 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-pll3-clk";
> + reg = <0x01c20030 0x4>;
> + clocks = <&osc3M>;
> + clock-output-names = "pll7";
> + };
> +
> + pll7x2: pll7x2-clk {
> + compatible = "allwinner,sun4i-a10-pll3-2x-clk";
> + #clock-cells = <0>;
> + clock-div = <1>;
> + clock-mult = <2>;
> + clocks = <&pll7>;
> + clock-output-names = "pll7-2x";
> + };
> +
> + /* dummy is 200M */
> + cpu: cpu at 01c20054 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-cpu-clk";
> + reg = <0x01c20054 0x4>;
> + clocks = <&osc32k>, <&osc24M>, <&pll1>, <&dummy>;
> + clock-output-names = "cpu";
> + };
> +
> + axi: axi at 01c20054 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-axi-clk";
> + reg = <0x01c20054 0x4>;
> + clocks = <&cpu>;
> + clock-output-names = "axi";
> + };
> +
> + ahb: ahb at 01c20054 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun5i-a13-ahb-clk";
> + reg = <0x01c20054 0x4>;
> + clocks = <&axi>, <&cpu>, <&pll6 1>;
> + clock-output-names = "ahb";
> + /*
> + * Use PLL6 as parent, instead of CPU/AXI
> + * which has rate changes due to cpufreq
> + */
> + assigned-clocks = <&ahb>;
> + assigned-clock-parents = <&pll6 1>;
> + };
> +
> + apb0: apb0 at 01c20054 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-apb0-clk";
> + reg = <0x01c20054 0x4>;
> + clocks = <&ahb>;
> + clock-output-names = "apb0";
> + };
> +
> + apb1: clk at 01c20058 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-apb1-clk";
> + reg = <0x01c20058 0x4>;
> + clocks = <&osc24M>, <&pll6 1>, <&osc32k>;
> + clock-output-names = "apb1";
> + };
> +
> + axi_gates: clk at 01c2005c {
> + #clock-cells = <1>;
> + compatible = "allwinner,sun4i-a10-gates-clk";
> + reg = <0x01c2005c 0x4>;
> + clocks = <&axi>;
> + clock-indices = <0>;
> + clock-output-names = "axi_dram";
> + };
> +
> + ahb_gates: clk at 01c20060 {
> + #clock-cells = <1>;
> + compatible = "allwinner,sun5i-a13-ahb-gates-clk";
> + reg = <0x01c20060 0x8>;
> + clocks = <&ahb>;
> + clock-indices = <0>, <1>,
> + <2>, <5>, <6>,
> + <7>, <8>, <9>,
> + <10>, <13>,
> + <14>, <17>, <20>,
> + <21>, <22>,
> + <28>, <32>, <34>,
> + <36>, <40>, <44>,
> + <46>, <51>,
> + <52>;
> + clock-output-names = "ahb_usbotg", "ahb_ehci",
> + "ahb_ohci", "ahb_ss", "ahb_dma",
> + "ahb_bist", "ahb_mmc0", "ahb_mmc1",
> + "ahb_mmc2", "ahb_nand",
> + "ahb_sdram", "ahb_emac", "ahb_spi0",
> + "ahb_spi1", "ahb_spi2",
> + "ahb_hstimer", "ahb_ve", "ahb_tve",
> + "ahb_lcd", "ahb_csi", "ahb_de_be",
> + "ahb_de_fe", "ahb_iep",
> + "ahb_mali400";
> + };
> +
> + apb0_gates: clk at 01c20068 {
> + #clock-cells = <1>;
> + compatible = "allwinner,sun4i-a10-gates-clk";
> + reg = <0x01c20068 0x4>;
> + clocks = <&apb0>;
> + clock-indices = <0>, <3>,
> + <5>, <6>;
> + clock-output-names = "apb0_codec", "apb0_i2s0",
> + "apb0_pio", "apb0_ir";
> + };
> +
> + apb1_gates: clk at 01c2006c {
> + #clock-cells = <1>;
> + compatible = "allwinner,sun4i-a10-gates-clk";
> + reg = <0x01c2006c 0x4>;
> + clocks = <&apb1>;
> + clock-indices = <0>, <1>,
> + <2>, <17>,
> + <18>, <19>;
> + clock-output-names = "apb1_i2c0", "apb1_i2c1",
> + "apb1_i2c2", "apb1_uart1",
> + "apb1_uart2", "apb1_uart3";
> + };
> +
> + nand_clk: clk at 01c20080 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-mod0-clk";
> + reg = <0x01c20080 0x4>;
> + clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> + clock-output-names = "nand";
> + };
> +
> + ms_clk: clk at 01c20084 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-mod0-clk";
> + reg = <0x01c20084 0x4>;
> + clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> + clock-output-names = "ms";
> + };
> +
> + mmc0_clk: clk at 01c20088 {
> + #clock-cells = <1>;
> + compatible = "allwinner,sun4i-a10-mmc-clk";
> + reg = <0x01c20088 0x4>;
> + clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> + clock-output-names = "mmc0",
> + "mmc0_output",
> + "mmc0_sample";
> + };
> +
> + mmc1_clk: clk at 01c2008c {
> + #clock-cells = <1>;
> + compatible = "allwinner,sun4i-a10-mmc-clk";
> + reg = <0x01c2008c 0x4>;
> + clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> + clock-output-names = "mmc1",
> + "mmc1_output",
> + "mmc1_sample";
> + };
> +
> + mmc2_clk: clk at 01c20090 {
> + #clock-cells = <1>;
> + compatible = "allwinner,sun4i-a10-mmc-clk";
> + reg = <0x01c20090 0x4>;
> + clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> + clock-output-names = "mmc2",
> + "mmc2_output",
> + "mmc2_sample";
> + };
> +
> + ts_clk: clk at 01c20098 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-mod0-clk";
> + reg = <0x01c20098 0x4>;
> + clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> + clock-output-names = "ts";
> + };
> +
> + ss_clk: clk at 01c2009c {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-mod0-clk";
> + reg = <0x01c2009c 0x4>;
> + clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> + clock-output-names = "ss";
> + };
> +
> + spi0_clk: clk at 01c200a0 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-mod0-clk";
> + reg = <0x01c200a0 0x4>;
> + clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> + clock-output-names = "spi0";
> + };
> +
> + spi1_clk: clk at 01c200a4 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-mod0-clk";
> + reg = <0x01c200a4 0x4>;
> + clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> + clock-output-names = "spi1";
> + };
> +
> + spi2_clk: clk at 01c200a8 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-mod0-clk";
> + reg = <0x01c200a8 0x4>;
> + clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> + clock-output-names = "spi2";
> + };
> +
> + ir0_clk: clk at 01c200b0 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-mod0-clk";
> + reg = <0x01c200b0 0x4>;
> + clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> + clock-output-names = "ir0";
> + };
> +
> + i2s0_clk: clk at 01c200b8 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-mod1-clk";
> + reg = <0x01c200b8 0x4>;
> + clocks = <&pll2 SUN4I_A10_PLL2_8X>,
> + <&pll2 SUN4I_A10_PLL2_4X>,
> + <&pll2 SUN4I_A10_PLL2_2X>,
> + <&pll2 SUN4I_A10_PLL2_1X>;
> + clock-output-names = "i2s0";
> + };
> +
> + spdif_clk: clk at 01c200c0 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-mod1-clk";
> + reg = <0x01c200c0 0x4>;
> + clocks = <&pll2 SUN4I_A10_PLL2_8X>,
> + <&pll2 SUN4I_A10_PLL2_4X>,
> + <&pll2 SUN4I_A10_PLL2_2X>,
> + <&pll2 SUN4I_A10_PLL2_1X>;
> + clock-output-names = "spdif";
> + };
> +
> + usb_clk: clk at 01c200cc {
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + compatible = "allwinner,sun5i-a13-usb-clk";
> + reg = <0x01c200cc 0x4>;
> + clocks = <&pll6 1>;
> + clock-output-names = "usb_ohci0", "usb_phy";
> + };
> +
> + dram_gates: clk at 01c20100 {
> + #clock-cells = <1>;
> + compatible = "nextthing,gr8-dram-gates-clk",
> + "allwinner,sun4i-a10-gates-clk";
> + reg = <0x01c20100 0x4>;
> + clocks = <&pll5 0>;
> + clock-indices = <0>,
> + <1>,
> + <25>,
> + <26>,
> + <29>,
> + <31>;
> + clock-output-names = "dram_ve",
> + "dram_csi",
> + "dram_de_fe",
> + "dram_de_be",
> + "dram_ace",
> + "dram_iep";
> + };
> +
> + de_be_clk: clk at 01c20104 {
> + #clock-cells = <0>;
> + #reset-cells = <0>;
> + compatible = "allwinner,sun4i-a10-display-clk";
> + reg = <0x01c20104 0x4>;
> + clocks = <&pll3>, <&pll7>, <&pll5 1>;
> + clock-output-names = "de-be";
> + };
> +
> + de_fe_clk: clk at 01c2010c {
> + #clock-cells = <0>;
> + #reset-cells = <0>;
> + compatible = "allwinner,sun4i-a10-display-clk";
> + reg = <0x01c2010c 0x4>;
> + clocks = <&pll3>, <&pll7>, <&pll5 1>;
> + clock-output-names = "de-fe";
> + };
> +
> + tcon_ch0_clk: clk at 01c20118 {
> + #clock-cells = <0>;
> + #reset-cells = <1>;
> + compatible = "allwinner,sun4i-a10-tcon-ch0-clk";
> + reg = <0x01c20118 0x4>;
> + clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> + clock-output-names = "tcon-ch0-sclk";
> + };
> +
> + tcon_ch1_clk: clk at 01c2012c {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-tcon-ch1-clk";
> + reg = <0x01c2012c 0x4>;
> + clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> + clock-output-names = "tcon-ch1-sclk";
> + };
> +
> + codec_clk: clk at 01c20140 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-codec-clk";
> + reg = <0x01c20140 0x4>;
> + clocks = <&pll2 SUN4I_A10_PLL2_1X>;
> + clock-output-names = "codec";
> + };
> +
> + mbus_clk: clk at 01c2015c {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun5i-a13-mbus-clk";
> + reg = <0x01c2015c 0x4>;
> + clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> + clock-output-names = "mbus";
> + };
> + };
> +
> + display-engine {
> + compatible = "allwinner,sun5i-a13-display-engine";
> + allwinner,pipelines = <&fe0>;
> + };
> +
> + soc at 01c00000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + sram-controller at 01c00000 {
> + compatible = "allwinner,sun4i-a10-sram-controller";
> + reg = <0x01c00000 0x30>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + sram_a: sram at 00000000 {
> + compatible = "mmio-sram";
> + reg = <0x00000000 0xc000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x00000000 0xc000>;
> + };
> +
> + sram_d: sram at 00010000 {
> + compatible = "mmio-sram";
> + reg = <0x00010000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x00010000 0x1000>;
> +
> + otg_sram: sram-section at 0000 {
> + compatible = "allwinner,sun4i-a10-sram-d";
> + reg = <0x0000 0x1000>;
> + status = "disabled";
> + };
> + };
> + };
> +
> + dma: dma-controller at 01c02000 {
> + compatible = "allwinner,sun4i-a10-dma";
> + reg = <0x01c02000 0x1000>;
> + interrupts = <27>;
> + clocks = <&ahb_gates 6>;
> + #dma-cells = <2>;
> + };
> +
> + nfc: nand at 01c03000 {
> + compatible = "allwinner,sun4i-a10-nand";
> + reg = <0x01c03000 0x1000>;
> + interrupts = <37>;
> + clocks = <&ahb_gates 13>, <&nand_clk>;
> + clock-names = "ahb", "mod";
> + dmas = <&dma SUN4I_DMA_DEDICATED 3>;
> + dma-names = "rxtx";
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + spi0: spi at 01c05000 {
> + compatible = "allwinner,sun4i-a10-spi";
> + reg = <0x01c05000 0x1000>;
> + interrupts = <10>;
> + clocks = <&ahb_gates 20>, <&spi0_clk>;
> + clock-names = "ahb", "mod";
> + dmas = <&dma SUN4I_DMA_DEDICATED 27>,
> + <&dma SUN4I_DMA_DEDICATED 26>;
> + dma-names = "rx", "tx";
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + spi1: spi at 01c06000 {
> + compatible = "allwinner,sun4i-a10-spi";
> + reg = <0x01c06000 0x1000>;
> + interrupts = <11>;
> + clocks = <&ahb_gates 21>, <&spi1_clk>;
> + clock-names = "ahb", "mod";
> + dmas = <&dma SUN4I_DMA_DEDICATED 9>,
> + <&dma SUN4I_DMA_DEDICATED 8>;
> + dma-names = "rx", "tx";
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + tve0: tv-encoder at 01c0a000 {
> + compatible = "allwinner,sun4i-a10-tv-encoder";
> + reg = <0x01c0a000 0x1000>;
> + clocks = <&ahb_gates 34>;
> + resets = <&tcon_ch0_clk 0>;
> + status = "disabled";
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + tve0_in_tcon0: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&tcon0_out_tve0>;
> + };
> + };
> + };
> +
> + tcon0: lcd-controller at 01c0c000 {
> + compatible = "allwinner,sun5i-a13-tcon";
> + reg = <0x01c0c000 0x1000>;
> + interrupts = <44>;
> + resets = <&tcon_ch0_clk 1>;
> + reset-names = "lcd";
> + clocks = <&ahb_gates 36>,
> + <&tcon_ch0_clk>,
> + <&tcon_ch1_clk>;
> + clock-names = "ahb",
> + "tcon-ch0",
> + "tcon-ch1";
> + clock-output-names = "tcon-pixel-clock";
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + tcon0_in: port at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + tcon0_in_be0: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&be0_out_tcon0>;
> + };
> + };
> +
> + tcon0_out: port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + tcon0_out_tve0: endpoint at 1 {
> + reg = <1>;
> + remote-endpoint = <&tve0_in_tcon0>;
> + };
> + };
> + };
> + };
> +
> + mmc0: mmc at 01c0f000 {
> + compatible = "allwinner,sun5i-a13-mmc";
> + reg = <0x01c0f000 0x1000>;
> + clocks = <&ahb_gates 8>,
> + <&mmc0_clk 0>,
> + <&mmc0_clk 1>,
> + <&mmc0_clk 2>;
> + clock-names = "ahb",
> + "mmc",
> + "output",
> + "sample";
> + interrupts = <32>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + mmc1: mmc at 01c10000 {
> + compatible = "allwinner,sun5i-a13-mmc";
> + reg = <0x01c10000 0x1000>;
> + clocks = <&ahb_gates 9>,
> + <&mmc1_clk 0>,
> + <&mmc1_clk 1>,
> + <&mmc1_clk 2>;
> + clock-names = "ahb",
> + "mmc",
> + "output",
> + "sample";
> + interrupts = <33>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + mmc2: mmc at 01c11000 {
> + compatible = "allwinner,sun5i-a13-mmc";
> + reg = <0x01c11000 0x1000>;
> + clocks = <&ahb_gates 10>,
> + <&mmc2_clk 0>,
> + <&mmc2_clk 1>,
> + <&mmc2_clk 2>;
> + clock-names = "ahb",
> + "mmc",
> + "output",
> + "sample";
> + interrupts = <34>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + usb_otg: usb at 01c13000 {
> + compatible = "allwinner,sun4i-a10-musb";
> + reg = <0x01c13000 0x0400>;
> + clocks = <&ahb_gates 0>;
> + interrupts = <38>;
> + interrupt-names = "mc";
> + phys = <&usbphy 0>;
> + phy-names = "usb";
> + extcon = <&usbphy 0>;
> + allwinner,sram = <&otg_sram 1>;
> + status = "disabled";
> +
> + dr_mode = "otg";
> + };
> +
> + usbphy: phy at 01c13400 {
> + #phy-cells = <1>;
> + compatible = "allwinner,sun5i-a13-usb-phy";
> + reg = <0x01c13400 0x10 0x01c14800 0x4>;
> + reg-names = "phy_ctrl", "pmu1";
> + clocks = <&usb_clk 8>;
> + clock-names = "usb_phy";
> + resets = <&usb_clk 0>, <&usb_clk 1>;
> + reset-names = "usb0_reset", "usb1_reset";
> + status = "disabled";
> + };
> +
> + ehci0: usb at 01c14000 {
> + compatible = "allwinner,sun5i-a13-ehci", "generic-ehci";
> + reg = <0x01c14000 0x100>;
> + interrupts = <39>;
> + clocks = <&ahb_gates 1>;
> + phys = <&usbphy 1>;
> + phy-names = "usb";
> + status = "disabled";
> + };
> +
> + ohci0: usb at 01c14400 {
> + compatible = "allwinner,sun5i-a13-ohci", "generic-ohci";
> + reg = <0x01c14400 0x100>;
> + interrupts = <40>;
> + clocks = <&usb_clk 6>, <&ahb_gates 2>;
> + phys = <&usbphy 1>;
> + phy-names = "usb";
> + status = "disabled";
> + };
> +
> + spi2: spi at 01c17000 {
> + compatible = "allwinner,sun4i-a10-spi";
> + reg = <0x01c17000 0x1000>;
> + interrupts = <12>;
> + clocks = <&ahb_gates 22>, <&spi2_clk>;
> + clock-names = "ahb", "mod";
> + dmas = <&dma SUN4I_DMA_DEDICATED 29>,
> + <&dma SUN4I_DMA_DEDICATED 28>;
> + dma-names = "rx", "tx";
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + intc: interrupt-controller at 01c20400 {
> + compatible = "allwinner,sun4i-a10-ic";
> + reg = <0x01c20400 0x400>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> +
> + pio: pinctrl at 01c20800 {
> + compatible = "nextthing,gr8-pinctrl";
> + reg = <0x01c20800 0x400>;
> + interrupts = <28>;
> + clocks = <&apb0_gates 5>;
> + gpio-controller;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + #gpio-cells = <3>;
> +
> + i2c0_pins_a: i2c0 at 0 {
> + allwinner,pins = "PB0", "PB1";
> + allwinner,function = "i2c0";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + i2c1_pins_a: i2c1 at 0 {
> + allwinner,pins = "PB15", "PB16";
> + allwinner,function = "i2c1";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + i2c2_pins_a: i2c2 at 0 {
> + allwinner,pins = "PB17", "PB18";
> + allwinner,function = "i2c2";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + i2s0_data_pins_a: i2s0-data at 0 {
> + allwinner,pins = "PB6", "PB7", "PB8", "PB9";
> + allwinner,function = "i2s0";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + i2s0_mclk_pins_a: i2s0-mclk at 0 {
> + allwinner,pins = "PB5";
> + allwinner,function = "i2s0";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + ir0_rx_pins_a: ir0 at 0 {
> + allwinner,pins = "PB4";
> + allwinner,function = "ir0";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + lcd_rgb666_pins: lcd-rgb666 at 0 {
> + allwinner,pins = "PD2", "PD3", "PD4", "PD5", "PD6", "PD7",
> + "PD10", "PD11", "PD12", "PD13", "PD14", "PD15",
> + "PD18", "PD19", "PD20", "PD21", "PD22", "PD23",
> + "PD24", "PD25", "PD26", "PD27";
> + allwinner,function = "lcd0";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + mmc0_pins_a: mmc0 at 0 {
> + allwinner,pins = "PF0", "PF1", "PF2", "PF3",
> + "PF4", "PF5";
> + allwinner,function = "mmc0";
> + allwinner,drive = <SUN4I_PINCTRL_30_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + nand_pins_a: nand-base0 at 0 {
> + allwinner,pins = "PC0", "PC1", "PC2",
> + "PC5", "PC8", "PC9", "PC10",
> + "PC11", "PC12", "PC13", "PC14",
> + "PC15";
> + allwinner,function = "nand0";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + nand_cs0_pins_a: nand-cs at 0 {
> + allwinner,pins = "PC4";
> + allwinner,function = "nand0";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + nand_rb0_pins_a: nand-rb at 0 {
> + allwinner,pins = "PC6";
> + allwinner,function = "nand0";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + pwm0_pins_a: pwm0 at 0 {
> + allwinner,pins = "PB2";
> + allwinner,function = "pwm0";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + pwm1_pins: pwm1 {
> + allwinner,pins = "PG13";
> + allwinner,function = "pwm1";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + spdif_tx_pins_a: spdif at 0 {
> + allwinner,pins = "PB10";
> + allwinner,function = "spdif";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> + };
> +
> + uart1_pins_a: uart1 at 1 {
> + allwinner,pins = "PG3", "PG4";
> + allwinner,function = "uart1";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + uart1_cts_rts_pins_a: uart1-cts-rts at 0 {
> + allwinner,pins = "PG5", "PG6";
> + allwinner,function = "uart1";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + uart2_pins_a: uart2 at 1 {
> + allwinner,pins = "PD2", "PD3";
> + allwinner,function = "uart2";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + uart2_cts_rts_pins_a: uart2-cts-rts at 0 {
> + allwinner,pins = "PD4", "PD5";
> + allwinner,function = "uart2";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + uart3_pins_a: uart3 at 1 {
> + allwinner,pins = "PG9", "PG10";
> + allwinner,function = "uart3";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + uart3_cts_rts_pins_a: uart3-cts-rts at 0 {
> + allwinner,pins = "PG11", "PG12";
> + allwinner,function = "uart3";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> + };
> +
> + pwm: pwm at 01c20e00 {
> + compatible = "allwinner,sun5i-a10s-pwm";
> + reg = <0x01c20e00 0xc>;
> + clocks = <&osc24M>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + timer at 01c20c00 {
> + compatible = "allwinner,sun4i-a10-timer";
> + reg = <0x01c20c00 0x90>;
> + interrupts = <22>;
> + clocks = <&osc24M>;
> + };
> +
> + wdt: watchdog at 01c20c90 {
> + compatible = "allwinner,sun4i-a10-wdt";
> + reg = <0x01c20c90 0x10>;
> + };
> +
> + spdif: spdif at 01c21000 {
> + #sound-dai-cells = <0>;
> + compatible = "allwinner,sun4i-a10-spdif";
> + reg = <0x01c21000 0x400>;
> + interrupts = <13>;
> + clocks = <&apb0_gates 1>, <&spdif_clk>;
> + clock-names = "apb", "spdif";
> + dmas = <&dma SUN4I_DMA_NORMAL 2>,
> + <&dma SUN4I_DMA_NORMAL 2>;
> + dma-names = "rx", "tx";
> + status = "disabled";
> + };
> +
> + ir0: ir at 01c21800 {
> + compatible = "allwinner,sun4i-a10-ir";
> + clocks = <&apb0_gates 6>, <&ir0_clk>;
> + clock-names = "apb", "ir";
> + interrupts = <5>;
> + reg = <0x01c21800 0x40>;
> + status = "disabled";
> + };
> +
> + i2s0: i2s at 01c22400 {
> + #sound-dai-cells = <0>;
> + compatible = "allwinner,sun4i-a10-i2s";
> + reg = <0x01c22400 0x400>;
> + interrupts = <16>;
> + clocks = <&apb0_gates 3>, <&i2s0_clk>;
> + clock-names = "apb", "mod";
> + dmas = <&dma SUN4I_DMA_NORMAL 3>,
> + <&dma SUN4I_DMA_NORMAL 3>;
> + dma-names = "rx", "tx";
> + status = "disabled";
> + };
> +
> + lradc: lradc at 01c22800 {
> + compatible = "allwinner,sun4i-a10-lradc-keys";
> + reg = <0x01c22800 0x100>;
> + interrupts = <31>;
> + status = "disabled";
> + };
> +
> + codec: codec at 01c22c00 {
> + #sound-dai-cells = <0>;
> + compatible = "allwinner,sun4i-a10-codec";
> + reg = <0x01c22c00 0x40>;
> + interrupts = <30>;
> + clocks = <&apb0_gates 0>, <&codec_clk>;
> + clock-names = "apb", "codec";
> + dmas = <&dma SUN4I_DMA_NORMAL 19>,
> + <&dma SUN4I_DMA_NORMAL 19>;
> + dma-names = "rx", "tx";
> + status = "disabled";
> + };
> +
> + rtp: rtp at 01c25000 {
> + compatible = "allwinner,sun5i-a13-ts";
> + reg = <0x01c25000 0x100>;
> + interrupts = <29>;
> + #thermal-sensor-cells = <0>;
> + };
> +
> + uart1: serial at 01c28400 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28400 0x400>;
> + interrupts = <2>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&apb1_gates 17>;
> + status = "disabled";
> + };
> +
> + uart2: serial at 01c28800 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28800 0x400>;
> + interrupts = <3>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&apb1_gates 18>;
> + status = "disabled";
> + };
> +
> + uart3: serial at 01c28c00 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28c00 0x400>;
> + interrupts = <4>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&apb1_gates 19>;
> + status = "disabled";
> + };
> +
> + i2c0: i2c at 01c2ac00 {
> + compatible = "allwinner,sun4i-a10-i2c";
> + reg = <0x01c2ac00 0x400>;
> + interrupts = <7>;
> + clocks = <&apb1_gates 0>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c1: i2c at 01c2b000 {
> + compatible = "allwinner,sun4i-a10-i2c";
> + reg = <0x01c2b000 0x400>;
> + interrupts = <8>;
> + clocks = <&apb1_gates 1>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c2: i2c at 01c2b400 {
> + compatible = "allwinner,sun4i-a10-i2c";
> + reg = <0x01c2b400 0x400>;
> + interrupts = <9>;
> + clocks = <&apb1_gates 2>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + timer at 01c60000 {
> + compatible = "allwinner,sun5i-a13-hstimer";
> + reg = <0x01c60000 0x1000>;
> + interrupts = <82>, <83>;
> + clocks = <&ahb_gates 28>;
> + };
> +
> + fe0: display-frontend at 01e00000 {
> + compatible = "allwinner,sun5i-a13-display-frontend";
> + reg = <0x01e00000 0x20000>;
> + interrupts = <47>;
> + clocks = <&ahb_gates 46>, <&de_fe_clk>,
> + <&dram_gates 25>;
> + clock-names = "ahb", "mod",
> + "ram";
> + resets = <&de_fe_clk>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + fe0_out: port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + fe0_out_be0: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&be0_in_fe0>;
> + };
> + };
> + };
> + };
> +
> + be0: display-backend at 01e60000 {
> + compatible = "allwinner,sun5i-a13-display-backend";
> + reg = <0x01e60000 0x10000>;
> + clocks = <&ahb_gates 44>, <&de_be_clk>,
> + <&dram_gates 26>;
> + clock-names = "ahb", "mod",
> + "ram";
> + resets = <&de_be_clk>;
> + status = "disabled";
> +
> + assigned-clocks = <&de_be_clk>;
> + assigned-clock-rates = <300000000>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + be0_in: port at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + be0_in_fe0: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&fe0_out_be0>;
> + };
> + };
> +
> + be0_out: port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + be0_out_tcon0: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&tcon0_in_be0>;
> + };
> + };
> + };
> + };
> + };
> +};
>
^ permalink raw reply
* [U-Boot] [PATCH RESEND 0/9] sunxi: chip: Enable the DIP auto-detection
From: Hans de Goede @ 2016-11-14 11:14 UTC (permalink / raw)
To: u-boot
In-Reply-To: <cover.e445aa83aac1de200cdbb59f8a5572c43341f03d.1478600213.git-series.maxime.ripard@free-electrons.com>
Hi,
On 08-11-16 11:19, Maxime Ripard wrote:
> The NextThing's C.H.I.P. can have expansion boards called DIPs. Those DIPs
> are connected through the external headers, and comes with an
> identification mechanism based on 1-Wire EEPROMs.
>
> That auto-detection works great, because 1-Wire allows the enumeration, and
> the EEPROMs are guaranteed to have different addresses, which allows us to
> stack as many DIPs as possible, without any constraints.
>
> Since those DIPs can be close to anything, ranging from a simple PWM-based
> buzzer to a full featured device such as the PocketCHIP (which comes with a
> touchscreen, a keyboard, a battery, etc), some adjustments might be needed
> in U-Boot to be able to present something that just works to the user.
>
> In particular, we need to:
> - Apply an overlay if the device is something that should be dealt with
> early in the boot process (display, storage device)
> - Adjust the U-Boot environment if the DIP has a display to change the
> default video output
> - Adjust the kernel command line in previous case for Linux to have the
> same default
>
> In order to achieve that, we introduced some logic optionally hooked into
> the sunxi board, two new uclasses for 1-Wire and EEPROMs, and a bunch of
> new environment variables:
> - dip-auto-video to control the automatic video set up (default to yes)
> - dip_overlay_cmd that is a script to load the overlay $dip_overlay_name
> to $dip_addr_r, from whatever place it was stored in, and later apply
> it.
> - kernelarg_video to host the default kernel output in the kernel
> command line
>
> I think the biggest drawback at the moment is that we maintain a list of
> DIPs and the actions needed directly into the C code, which will make it
> quite hard to customise for end users and tedious to maintain in the long
> term. I couldn't really get my head around a better solution, so feel free
> to suggest alternative approaches.
>
> Let me know what you think,
The sunxi specific bits look fine to me. I will leave reviewing of the
uclass bits to Simon.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v3 2/3] PCI: qcom: add support to msm8996 PCIE controller
From: Vivek Gautam @ 2016-11-14 11:13 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: svarbanov, Bjorn Helgaas, linux-pci, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm
In-Reply-To: <2eae2624-fd5e-df55-5261-a49b3fe56a18@linaro.org>
Hi,
On Mon, Nov 14, 2016 at 4:02 PM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
>
>
> On 09/11/16 10:37, Vivek Gautam wrote:
>>
>> Hi,
>>
>> On Fri, Nov 4, 2016 at 6:29 PM, Srinivas Kandagatla
>> <srinivas.kandagatla@linaro.org> wrote:
>>>
>>> This patch adds support to msm8996/apq8096 pcie, MSM8996 supports
>>> Gen 1/2, One lane, 3 pcie root-complex with support to MSI and
>>> legacy interrupts and it conforms to PCI Express Base 2.1 specification.
>>>
>>> This patch adds post_init callback to qcom_pcie_ops, as this is pcie
>>> pipe clocks are only setup after the phy is powered on.
>>> It also adds ltssm_enable callback as it is very much different to other
>>> supported SOCs in the driver.
>>>
>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>> ---
>>
>>
>> Few minor nits.
>>
>>> .../devicetree/bindings/pci/qcom,pcie.txt | 68 +++++++-
>>> drivers/pci/host/pcie-qcom.c | 177
>>> ++++++++++++++++++++-
>>> 2 files changed, 239 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
>>> b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
>>> index 4059a6f..4a0538d 100644
>>> --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
>>> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
>>> @@ -7,6 +7,7 @@
>>> - "qcom,pcie-ipq8064" for ipq8064
>>> - "qcom,pcie-apq8064" for apq8064
>>> - "qcom,pcie-apq8084" for apq8084
>>> + - "qcom,pcie-msm8996" for msm8996 or apq8096
>>
>>
>> Since this works for both apq8096 and msm8996, compatible -
>> "qcom,pcie-apq8096" for uniformity ?
>
>
> AFAIK, compatible is selected based on SOC on which this IP is integrated
> first, So msm8996 seems to be correct, in that way.
>
> Also if we look at clk controller compatible strings, you would see them as
> *msm8996* rather than *8096*.
ok, cool. I didn't notice that. This looks good then.
Thanks
Vivek
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCHv5 2/2] xenfs: Use proc_create_mount_point() to create /proc/xen
From: David Vrabel @ 2016-11-14 11:12 UTC (permalink / raw)
To: xen-devel; +Cc: Juergen Gross, Seth Forshee, Boris Ostrovsky, David Vrabel
In-Reply-To: <1479121976-26568-1-git-send-email-david.vrabel@citrix.com>
From: Seth Forshee <seth.forshee@canonical.com>
Mounting proc in user namespace containers fails if the xenbus
filesystem is mounted on /proc/xen because this directory fails
the "permanently empty" test. proc_create_mount_point() exists
specifically to create such mountpoints in proc but is currently
proc-internal. Export this interface to modules, then use it in
xenbus when creating /proc/xen.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
drivers/xen/xenbus/xenbus_probe.c | 2 +-
fs/proc/generic.c | 1 +
fs/proc/internal.h | 1 -
include/linux/proc_fs.h | 2 ++
4 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 33a31cf..b5c1dec 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -826,7 +826,7 @@ static int __init xenbus_init(void)
* Create xenfs mountpoint in /proc for compatibility with
* utilities that expect to find "xenbus" under "/proc/xen".
*/
- proc_mkdir("xen", NULL);
+ proc_create_mount_point("xen");
#endif
out_error:
diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index 5f2dc20..7eb3cef 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -479,6 +479,7 @@ struct proc_dir_entry *proc_create_mount_point(const char *name)
}
return ent;
}
+EXPORT_SYMBOL(proc_create_mount_point);
struct proc_dir_entry *proc_create_data(const char *name, umode_t mode,
struct proc_dir_entry *parent,
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 5378441..7de6795 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -195,7 +195,6 @@ static inline bool is_empty_pde(const struct proc_dir_entry *pde)
{
return S_ISDIR(pde->mode) && !pde->proc_iops;
}
-struct proc_dir_entry *proc_create_mount_point(const char *name);
/*
* inode.c
diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
index b97bf2e..8bd2f72 100644
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -21,6 +21,7 @@ extern struct proc_dir_entry *proc_mkdir_data(const char *, umode_t,
struct proc_dir_entry *, void *);
extern struct proc_dir_entry *proc_mkdir_mode(const char *, umode_t,
struct proc_dir_entry *);
+struct proc_dir_entry *proc_create_mount_point(const char *name);
extern struct proc_dir_entry *proc_create_data(const char *, umode_t,
struct proc_dir_entry *,
@@ -56,6 +57,7 @@ static inline struct proc_dir_entry *proc_symlink(const char *name,
struct proc_dir_entry *parent,const char *dest) { return NULL;}
static inline struct proc_dir_entry *proc_mkdir(const char *name,
struct proc_dir_entry *parent) {return NULL;}
+static inline struct proc_dir_entry *proc_create_mount_point(const char *name) { return NULL; }
static inline struct proc_dir_entry *proc_mkdir_data(const char *name,
umode_t mode, struct proc_dir_entry *parent, void *data) { return NULL; }
static inline struct proc_dir_entry *proc_mkdir_mode(const char *name,
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH v5 0/2] xenfs: xenbus and container related bug fixes
From: David Vrabel @ 2016-11-14 11:12 UTC (permalink / raw)
To: xen-devel; +Cc: Juergen Gross, Boris Ostrovsky, David Vrabel
Using /proc/xen/xenbus can cause deadlocks on the atomic file position
mutex since this file should behave like a character device and not a
regular file. This is easiest to achive by clearing FMODE_ATOMIC_POS.
David
Changes in v5:
- Clear FMODE_ATOMIC_POS instead of using symlinks.
Changes in v4:
- Switch on file type in simple_fill_super()
- Make xen_xenus_fops and xen_privcmd_fops static
- Rebased on v4.9-rc2.
- Add patch from Seth for namespace support.
Changes in v3:
- Rebased on v4.7-rc5.
Changes in v2:
- Simplified simple_fill_super() change.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCHv5 1/2] xenbus: fix deadlock on writes to /proc/xen/xenbus
From: David Vrabel @ 2016-11-14 11:12 UTC (permalink / raw)
To: xen-devel; +Cc: Juergen Gross, Boris Ostrovsky, David Vrabel
In-Reply-To: <1479121976-26568-1-git-send-email-david.vrabel@citrix.com>
/proc/xen/xenbus does not work correctly. A read blocked waiting for
a xenstore message holds the mutex needed for atomic file position
updates. This blocks any writes on the same file handle, which can
deadlock if the write is needed to unblock the read.
Clear FMODE_ATOMIC_POS when opening this device to always get
character device like sematics.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
drivers/xen/xenbus/xenbus_dev_frontend.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
index 1e8be12..ce389b4 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -536,6 +536,8 @@ static int xenbus_file_open(struct inode *inode, struct file *filp)
if (xen_store_evtchn == 0)
return -ENOENT;
+ filp->f_mode &= ~FMODE_ATOMIC_POS; /* cdev-style semantics */
+
nonseekable_open(inode, filp);
u = kzalloc(sizeof(*u), GFP_KERNEL);
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* Re: [PATCH 1/1] kthread: don't abuse kthread_create_on_cpu() in __kthread_create_worker()
From: Petr Mladek @ 2016-11-14 11:12 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Thomas Gleixner, Andy Lutomirski, Roman Pen, Andy Lutomirski,
Peter Zijlstra, Ingo Molnar, Tejun Heo,
linux-kernel@vger.kernel.org, Chunming Zhou, Alex Deucher
In-Reply-To: <20161110172030.GB28264@redhat.com>
On Thu 2016-11-10 18:20:31, Oleg Nesterov wrote:
> kthread_create_on_cpu() sets KTHREAD_IS_PER_CPU and kthread->cpu, this
> only makes sense if this kthread can be parked/unparked by cpuhp code.
> kthread workers never call kthread_parkme() so this has no effect.
Yes.
> Change __kthread_create_worker() to simply call kthread_bind(task, cpu).
> The very fact that kthread_create_on_cpu() doesn't accept a generic fmt
> shows that it should not be used outside of smpboot.c.
>
> Now, the only reason we can not unexport this helper and move it into
> smpboot.c is that it sets kthread->cpu and struct kthread is not exported.
> And the only reason we can not kill kthread->cpu is that kthread_unpark()
> is used by drivers/gpu/drm/amd/scheduler/gpu_scheduler.c and thus we can
> not turn _unpark into kthread_unpark(struct smp_hotplug_thread *, cpu).
>
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
The change looks fine to me. Feel free to add one or both of these:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Tested-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* [PATCH] mm/pkeys: generate pkey system call code only if ARCH_HAS_PKEYS is selected
From: Heiko Carstens @ 2016-11-14 11:12 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-arch, linux-kernel, linux-mm, Dave Hansen, Mark Rutland
Having code for the pkey_mprotect, pkey_alloc and pkey_free system
calls makes only sense if ARCH_HAS_PKEYS is selected. If not selected
these system calls will always return -ENOSPC or -EINVAL.
To simplify things and have less code generate the pkey system call
code only if ARCH_HAS_PKEYS is selected.
For architectures which have already wired up the system calls, but do
not select ARCH_HAS_PKEYS this will result in less generated code and
a different return code: the three system calls will now always return
-ENOSYS, using the cond_syscall mechanism.
For architectures which have not wired up the system calls less
unreachable code will be generated.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
mm/mprotect.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 11936526b08b..a06e91c4de29 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -484,6 +484,8 @@ SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, len,
return do_mprotect_pkey(start, len, prot, -1);
}
+#ifdef CONFIG_ARCH_HAS_PKEYS
+
SYSCALL_DEFINE4(pkey_mprotect, unsigned long, start, size_t, len,
unsigned long, prot, int, pkey)
{
@@ -534,3 +536,5 @@ SYSCALL_DEFINE1(pkey_free, int, pkey)
*/
return ret;
}
+
+#endif /* CONFIG_ARCH_HAS_PKEYS */
--
2.8.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH] mm/pkeys: generate pkey system call code only if ARCH_HAS_PKEYS is selected
From: Heiko Carstens @ 2016-11-14 11:12 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-arch, linux-kernel, linux-mm, Dave Hansen, Mark Rutland
Having code for the pkey_mprotect, pkey_alloc and pkey_free system
calls makes only sense if ARCH_HAS_PKEYS is selected. If not selected
these system calls will always return -ENOSPC or -EINVAL.
To simplify things and have less code generate the pkey system call
code only if ARCH_HAS_PKEYS is selected.
For architectures which have already wired up the system calls, but do
not select ARCH_HAS_PKEYS this will result in less generated code and
a different return code: the three system calls will now always return
-ENOSYS, using the cond_syscall mechanism.
For architectures which have not wired up the system calls less
unreachable code will be generated.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
mm/mprotect.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 11936526b08b..a06e91c4de29 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -484,6 +484,8 @@ SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, len,
return do_mprotect_pkey(start, len, prot, -1);
}
+#ifdef CONFIG_ARCH_HAS_PKEYS
+
SYSCALL_DEFINE4(pkey_mprotect, unsigned long, start, size_t, len,
unsigned long, prot, int, pkey)
{
@@ -534,3 +536,5 @@ SYSCALL_DEFINE1(pkey_free, int, pkey)
*/
return ret;
}
+
+#endif /* CONFIG_ARCH_HAS_PKEYS */
--
2.8.4
^ permalink raw reply related
* Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: One Thousand Gnomes @ 2016-11-14 11:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, zhichang.yuan, catalin.marinas, will.deacon,
robh+dt, bhelgaas, olof, linux-arm-kernel, lorenzo.pieralisi,
linux-kernel, linuxarm, devicetree, linux-pci, linux-serial,
minyard, benh, liviu.dudau, zourongrong, john.garry,
gabriele.paoloni, zhichang.yuan02, kantyzc, xuwei5, marc.zyngier
In-Reply-To: <5900275.i4NZvtxTcC@wuerfel>
> > It's not a safe assumption for x86 at least. There are a few systems with
> > multiple ISA busses particularly older laptops with a docking station.
>
> But do they have multiple ISA domains? There is no real harm in supporting
> it, the (small) downsides I can think of are:
I don't believe they x86 class ones have multiple ISA domains. But as
I've said I don't know how the electronics in the older ThinkPad worked
when it used two PIIX4s with some LPC or ISA stuff on each.
It works in DOS and unmodified Linux so I'm pretty sure there are no
additional domains. Likewise the various x86 schemes that route some bits
of ISA bus off into strange places work in DOS and don't have any
overlaps.
yenta_socket handles PCI/PCMCIA bridging and routes a range of that flat
ISA space appropriately to the card.
Alan
^ permalink raw reply
* Re: [PATCH libdrm] xd86drm: read more than 128 bytes of uevent in drmParsePciBusInfo
From: Eric Engestrom @ 2016-11-14 11:11 UTC (permalink / raw)
To: Emil Velikov; +Cc: Mingcong Bai, dri-devel
In-Reply-To: <20161111190411.19239-1-emil.l.velikov@gmail.com>
On Friday, 2016-11-11 19:04:11 +0000, Emil Velikov wrote:
> From: Emil Velikov <emil.velikov@collabora.com>
>
> Some platforms (such as Macs using OF) can have more information in the
> uevent file thus reading only the first 128 might not be sufficient.
>
> Bump it to 512, which "should be enough for everybody" ;-)
>
> Cc: Mingcong Bai <jeffbai@aosc.xyz>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98629
> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
> ---
> Mingcong Bai, this should fix things but you'll need to apply it
> on top of your libdrm package. There's no need to rebuild mesa
> afterwords.
>
> Note to self:
> Strictly speaking we can rework drmGetDevice[s] to use [just] uevent...
> ---
> xf86drm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 676effc..80e2f27 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -2871,7 +2871,7 @@ static int drmParsePciBusInfo(int maj, int min, drmPciBusInfoPtr info)
> {
> #ifdef __linux__
> char path[PATH_MAX + 1];
> - char data[128 + 1];
> + char data[512 + 1];
> char *str;
> int domain, bus, dev, func;
> int fd, ret;
> @@ -2882,7 +2882,7 @@ static int drmParsePciBusInfo(int maj, int min, drmPciBusInfoPtr info)
> return -errno;
>
> ret = read(fd, data, sizeof(data));
> - data[128] = '\0';
> + data[512] = '\0';
How about `sizeof(data)-1`?
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
> close(fd);
> if (ret < 0)
> return -errno;
> --
> 2.10.2
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: One Thousand Gnomes @ 2016-11-14 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5900275.i4NZvtxTcC@wuerfel>
> > It's not a safe assumption for x86 at least. There are a few systems with
> > multiple ISA busses particularly older laptops with a docking station.
>
> But do they have multiple ISA domains? There is no real harm in supporting
> it, the (small) downsides I can think of are:
I don't believe they x86 class ones have multiple ISA domains. But as
I've said I don't know how the electronics in the older ThinkPad worked
when it used two PIIX4s with some LPC or ISA stuff on each.
It works in DOS and unmodified Linux so I'm pretty sure there are no
additional domains. Likewise the various x86 schemes that route some bits
of ISA bus off into strange places work in DOS and don't have any
overlaps.
yenta_socket handles PCI/PCMCIA bridging and routes a range of that flat
ISA space appropriately to the card.
Alan
^ permalink raw reply
* Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: One Thousand Gnomes @ 2016-11-14 11:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, zhichang.yuan, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, olof-nZhT3qVonbNeoWH0uzbU5w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
lorenzo.pieralisi-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA, minyard-HInyCGIudOg,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r, liviu.dudau-5wv7dgnIgG8,
zourongrong-Re5JQEeQqe8AvxtiuMwx3w,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
zhichang.yuan02-Re5JQEeQqe8AvxtiuMwx3w, kantyzc-9Onoh4P/yGk,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q, marc.zyngier-5wv7dgnIgG8
In-Reply-To: <5900275.i4NZvtxTcC@wuerfel>
> > It's not a safe assumption for x86 at least. There are a few systems with
> > multiple ISA busses particularly older laptops with a docking station.
>
> But do they have multiple ISA domains? There is no real harm in supporting
> it, the (small) downsides I can think of are:
I don't believe they x86 class ones have multiple ISA domains. But as
I've said I don't know how the electronics in the older ThinkPad worked
when it used two PIIX4s with some LPC or ISA stuff on each.
It works in DOS and unmodified Linux so I'm pretty sure there are no
additional domains. Likewise the various x86 schemes that route some bits
of ISA bus off into strange places work in DOS and don't have any
overlaps.
yenta_socket handles PCI/PCMCIA bridging and routes a range of that flat
ISA space appropriately to the card.
Alan
--
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/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver
From: Laurent Pinchart @ 2016-11-14 11:10 UTC (permalink / raw)
To: Jyri Sarha
Cc: devicetree, bcousson, khilman, dri-devel, bgolaszewski,
tomi.valkeinen
In-Reply-To: <d035c76e-ca7f-0503-87da-7e93783d1cd0@ti.com>
Hi Jyri,
On Monday 14 Nov 2016 10:49:43 Jyri Sarha wrote:
> On 11/03/16 19:46, Laurent Pinchart wrote:
> >> +Required properties:
> >> > + - compatible: "ti,tfp410"
> >
> > The device is an I2C slave, it should have a reg property. Given that the
> > chip can be used without being controlled through I2C, the reg property
> > should be optional. You should document this clearly, and explain how the
> > DT node can be instantiated as a child of an I2C controller when the I2C
> > interface is used, or in other parts of the device tree otherwise.
>
> Shouldn't I have two different compatible strings if want to make both
> platform driver probe and i2c client probe to work?
I don't think so, it's still the same chip.
> Or can it be done with single compatible string? Would you know of an
> example of such a driver?
You will need to register both a i2c_driver and a platform_driver in the
tfp410 driver. Both will advertise the same compatible string. As you'll have
two probe functions, it should be easy to handle the differences between the
two situations there, with common code shared in common functions. A quick
grep points to at least drivers/power/bq27x00_battery.c as an example (albeit
without DT support).
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [powerpc v4 1/3] Setup AMOR in HV mode
From: kbuild test robot @ 2016-11-14 11:09 UTC (permalink / raw)
To: Balbir Singh; +Cc: kbuild-all, linuxppc-dev
In-Reply-To: <1479101112-21120-2-git-send-email-bsingharora@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]
Hi Balbir,
[auto build test WARNING on powerpc/master]
url: https://github.com/0day-ci/linux/commits/Balbir-Singh/Enable-IAMR-storage-keys-for-radix/20161114-133434
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git master
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All warnings (new ones prefixed by >>):
>> WARNING: arch/powerpc/mm/built-in.o(.text+0xadac): Section mismatch in reference from the function .radix__early_init_mmu_secondary() to the function .init.text:.radix_init_amor()
The function .radix__early_init_mmu_secondary() references
the function __init .radix_init_amor().
This is often because .radix__early_init_mmu_secondary lacks a __init
annotation or the annotation of .radix_init_amor is wrong.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 50923 bytes --]
^ permalink raw reply
* [U-Boot] [PATCH 4/4] sunxi: sina33: Enable the LCD
From: Jaehoon Chung @ 2016-11-14 11:10 UTC (permalink / raw)
To: u-boot
In-Reply-To: <fdc8a28f-46e4-dcd9-2a48-0f2ee2cefc5f@redhat.com>
Hi Hans,
On 11/14/2016 03:51 AM, Hans de Goede wrote:
> Hi,
>
> On 04-11-16 16:18, Maxime Ripard wrote:
>> The SinA33 comes with an optional 7" display. Enable it in the
>> configuration.
>>
>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> LGTM:
>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This patch is not on MMC side. But i picked with other patches.
If there is other issue, let me know, plz.
Best Regards,
Jaehoon Chung
>
> Regards,
>
> Hans
>
>
>
>> ---
>> configs/Sinlinx_SinA33_defconfig | 4 ++++
>> 1 file changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/configs/Sinlinx_SinA33_defconfig b/configs/Sinlinx_SinA33_defconfig
>> index f4719db2d501..26b119a9b92f 100644
>> --- a/configs/Sinlinx_SinA33_defconfig
>> +++ b/configs/Sinlinx_SinA33_defconfig
>> @@ -6,6 +6,10 @@ CONFIG_DRAM_ZQ=15291
>> CONFIG_MMC0_CD_PIN="PB4"
>> CONFIG_MMC_SUNXI_SLOT_EXTRA=2
>> CONFIG_USB0_ID_DET="PH8"
>> +CONFIG_VIDEO_LCD_MODE="x:1024,y:600,depth:18,pclk_khz:66000,le:90,ri:160,up:3,lo:127,hs:70,vs:20,sync:3,vmode:0"
>> +CONFIG_VIDEO_LCD_DCLK_PHASE=0
>> +CONFIG_VIDEO_LCD_BL_EN="PH6"
>> +CONFIG_VIDEO_LCD_BL_PWM="PH0"
>> CONFIG_DEFAULT_DEVICE_TREE="sun8i-a33-sinlinx-sina33"
>> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>> CONFIG_SPL=y
>>
>
>
>
^ permalink raw reply
* Re: [RFC PATCH 1/2] net: use cmpxchg instead of spinlock in ptr rings
From: Jesper Dangaard Brouer @ 2016-11-14 11:09 UTC (permalink / raw)
To: John Fastabend
Cc: jasowang, netdev, linux-kernel, Michael S. Tsirkin, Jason Wang,
Mathieu Desnoyers
In-Reply-To: <20161111044408.1547.92737.stgit@john-Precision-Tower-5810>
On Thu, 10 Nov 2016 20:44:08 -0800 John Fastabend <john.fastabend@gmail.com> wrote:
> ---
> include/linux/ptr_ring_ll.h | 136 +++++++++++++++++++++++++++++++++++++++++++
> include/linux/skb_array.h | 25 ++++++++
> 2 files changed, 161 insertions(+)
> create mode 100644 include/linux/ptr_ring_ll.h
>
> diff --git a/include/linux/ptr_ring_ll.h b/include/linux/ptr_ring_ll.h
> new file mode 100644
> index 0000000..bcb11f3
> --- /dev/null
> +++ b/include/linux/ptr_ring_ll.h
> @@ -0,0 +1,136 @@
> +/*
> + * Definitions for the 'struct ptr_ring_ll' datastructure.
> + *
> + * Author:
> + * John Fastabend <john.r.fastabend@intel.com>
[...]
> + *
> + * This is a limited-size FIFO maintaining pointers in FIFO order, with
> + * one CPU producing entries and another consuming entries from a FIFO.
> + * extended from ptr_ring_ll to use cmpxchg over spin lock.
It sounds like this is Single Producer Single Consumer (SPSC)
implementation, but your implementation actually is Multi Producer
Multi Consumer (MPMC) capable.
The implementation looks a lot like my alf_queue[1] implementation:
[1] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/include/linux/alf_queue.h
If the primary use-case is one CPU producing and another consuming,
then the normal ptr_ring (skb_array) will actually be faster!
The reason is ptr_ring avoids bouncing a cache-line between the CPUs on
every ring access. This is achieved by having the checks for full
(__ptr_ring_full) and empty (__ptr_ring_empty) use the contents of the
array (NULL value).
I actually implemented two micro-benchmarks to measure the difference
between skb_array[2] and alf_queue[3]:
[2] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/lib/skb_array_parallel01.c
[3] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/lib/alf_queue_parallel01.c
> + */
> +
> +#ifndef _LINUX_PTR_RING_LL_H
> +#define _LINUX_PTR_RING_LL_H 1
> +
[...]
> +
> +struct ptr_ring_ll {
> + u32 prod_size;
> + u32 prod_mask;
> + u32 prod_head;
> + u32 prod_tail;
> + u32 cons_size;
> + u32 cons_mask;
> + u32 cons_head;
> + u32 cons_tail;
> +
> + void **queue;
> +};
Your implementation doesn't even split the consumer and producer into
different cachelines (which in practice doesn't help much due to how
the empty/full checks are performed).
> +
> +/* Note: callers invoking this in a loop must use a compiler barrier,
> + * for example cpu_relax(). Callers must hold producer_lock.
> + */
> +static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void *ptr)
> +{
> + u32 ret, head, tail, next, slots, mask;
> +
> + do {
> + head = READ_ONCE(r->prod_head);
> + mask = READ_ONCE(r->prod_mask);
> + tail = READ_ONCE(r->cons_tail);
Problem occur here, as the producer need to access/read the consumers
tail, to determine if the queue is not already full (slots avail).
Thus, the next "consumer-CPU" will see the cacheline in wrong state
(Modified/Invalid or Shared).
> +
> + slots = mask + tail - head;
> + if (slots < 1)
> + return -ENOMEM;
> +
> + next = head + 1;
> + ret = cmpxchg(&r->prod_head, head, next);
> + } while (ret != head);
> +
> + r->queue[head & mask] = ptr;
> + smp_wmb();
> +
> + while (r->prod_tail != head)
> + cpu_relax();
> +
> + r->prod_tail = next;
> + return 0;
> +}
> +
> +static inline void *__ptr_ring_ll_consume(struct ptr_ring_ll *r)
> +{
> + u32 ret, head, tail, next, slots, mask;
> + void *ptr;
> +
> + do {
> + head = READ_ONCE(r->cons_head);
> + mask = READ_ONCE(r->cons_mask);
> + tail = READ_ONCE(r->prod_tail);
Like wise the consumer is reading the producer tail (for the empty check).
> +
> + slots = tail - head;
> + if (slots < 1)
> + return ERR_PTR(-ENOMEM);
> +
> + next = head + 1;
> + ret = cmpxchg(&r->cons_head, head, next);
> + } while (ret != head);
> +
> + ptr = r->queue[head & mask];
> + smp_rmb();
> +
> + while (r->cons_tail != head)
> + cpu_relax();
> +
> + r->cons_tail = next;
> + return ptr;
> +}
> +
> +static inline void **__ptr_ring_ll_init_queue_alloc(int size, gfp_t gfp)
> +{
> + return kzalloc(ALIGN(size * sizeof(void *), SMP_CACHE_BYTES), gfp);
> +}
> +
> +static inline int ptr_ring_ll_init(struct ptr_ring_ll *r, int size, gfp_t gfp)
> +{
> + r->queue = __ptr_ring_init_queue_alloc(size, gfp);
> + if (!r->queue)
> + return -ENOMEM;
> +
> + r->prod_size = r->cons_size = size;
> + r->prod_mask = r->cons_mask = size - 1;
Shouldn't we have some check like is_power_of_2(size), as this code
looks like it depend on this.
> + r->prod_tail = r->prod_head = 0;
> + r->cons_tail = r->prod_tail = 0;
> +
> + return 0;
> +}
> +
[...]
> +#endif /* _LINUX_PTR_RING_LL_H */
> diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h
> index f4dfade..9b43dfd 100644
> --- a/include/linux/skb_array.h
> +++ b/include/linux/skb_array.h
[...]
>
> +static inline int skb_array_ll_produce(struct skb_array_ll *a, struct sk_buff *skb)
> +{
> + return __ptr_ring_ll_produce(&a->ring, skb);
> +}
> +
[...]
>
> +static inline struct sk_buff *skb_array_ll_consume(struct skb_array_ll *a)
> +{
> + return __ptr_ring_ll_consume(&a->ring);
> +}
> +
Note in the Multi Producer Multi Consumer (MPMC) use-case this type of
queue can be faster than normal ptr_ring. And in patch2 you implement
bulking, which is where the real benefit shows (in the MPMC case) for
this kind of queue.
What I would really like to see is a lock-free (locked cmpxchg) queue
implementation, what like ptr_ring use the array as empty/full check,
and still (somehow) support bulking.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH 0/1] kthread: don't abuse kthread_create_on_cpu() in __kthread_create_worker()
From: Petr Mladek @ 2016-11-14 11:09 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Thomas Gleixner, Andy Lutomirski, Roman Pen, Andy Lutomirski,
Peter Zijlstra, Ingo Molnar, Tejun Heo,
linux-kernel@vger.kernel.org, Chunming Zhou, Alex Deucher
In-Reply-To: <20161110171957.GA28264@redhat.com>
On Thu 2016-11-10 18:19:58, Oleg Nesterov wrote:
> On 11/09, Oleg Nesterov wrote:
> >
> > Yes, agreed. Again, I'll write another email. Perhaps we should even keep
> > park/unpark exported and change them to avoid the races with exit/itself,
> > I dunno.
> >
> > My real point was, imo the KTHREAD_IS_PER_CPU/__kthread_bind(kthread->cpu)
> > logic in kthread_unpark() should be private to smpboot.c/cpu.c.
> >
> > I'll send another patch tomorrow. kthread_create_worker_on_cpu() ab-uses
> > this logic too for no reason, but this is trivial.
>
> After this change we are almost ready to kill kthread->cpu and KTHREAD_IS_PER_CPU.
> (but the change itself doesn't depend on the previous patches).
>
> Petr, why do we need kthread_create_worker_on_cpu() ? It has no users and
> I can not imagine any "real" use-case for it. Perhaps it can be removed?
kthread_create_worker_on_cpu() is going to have some users. For
example, patches for intel_powerclamp are already flying around,
see
https://lkml.kernel.org/r/1476707572-32215-3-git-send-email-pmladek@suse.com
Best Regards,
Petr
^ permalink raw reply
* [bug report] iommu/vt-d: Fix IOMMU lookup for SR-IOV Virtual Functions
From: Dan Carpenter @ 2016-11-14 11:09 UTC (permalink / raw)
To: ashok.raj-ral2JQCrhuEAvxtiuMwx3w
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
Hello Ashok Raj,
This is a semi-automatic email about new static checker warnings.
The patch 1c387188c60f: "iommu/vt-d: Fix IOMMU lookup for SR-IOV
Virtual Functions" from Oct 21, 2016, leads to the following Smatch
complaint:
drivers/iommu/intel-iommu.c:918 device_to_iommu()
error: we previously assumed 'pdev' could be null (see line 908)
drivers/iommu/intel-iommu.c
907 for_each_active_iommu(iommu, drhd) {
908 if (pdev && segment != drhd->segment)
^^^^
Other code assumes pdev can be NULL.
909 continue;
910
911 for_each_active_dev_scope(drhd->devices,
912 drhd->devices_cnt, i, tmp) {
913 if (tmp == dev) {
914 /* For a VF use its original BDF# not that of the PF
915 * which we used for the IOMMU lookup. Strictly speaking
916 * we could do this for all PCI devices; we only need to
917 * get the BDF# from the scope table for ACPI matches. */
918 if (pdev->is_virtfn)
^^^^^^^^^^^^^^^
Not checked.
919 goto got_pdev;
920
921 *bus = drhd->devices[i].bus;
922 *devfn = drhd->devices[i].devfn;
923 goto out;
924 }
925
926 if (!pdev || !dev_is_pci(tmp))
^^^^
Checked here as well.
927 continue;
928
929 ptmp = to_pci_dev(tmp);
930 if (ptmp->subordinate &&
931 ptmp->subordinate->number <= pdev->bus->number &&
932 ptmp->subordinate->busn_res.end >= pdev->bus->number)
933 goto got_pdev;
934 }
935
936 if (pdev && drhd->include_all) {
937 got_pdev:
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v3 07/14] drm/i915/scheduler: Record all dependencies upon request construction
From: Tvrtko Ursulin @ 2016-11-14 11:09 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
In-Reply-To: <20161114085703.16540-7-chris@chris-wilson.co.uk>
On 14/11/2016 08:56, Chris Wilson wrote:
> The scheduler needs to know the dependencies of each request for the
> lifetime of the request, as it may choose to reschedule the requests at
> any time and must ensure the dependency tree is not broken. This is in
> additional to using the fence to only allow execution after all
> dependencies have been completed.
>
> One option was to extend the fence to support the bidirectional
> dependency tracking required by the scheduler. However the mismatch in
> lifetimes between the submit fence and the request essentially meant
> that we had to build a completely separate struct (and we could not
> simply reuse the existing waitqueue in the fence for one half of the
> dependency tracking). The extra dependency tracking simply did not mesh
> well with the fence, and keeping it separate both keeps the fence
> implementation simpler and allows us to extend the dependency tracking
> into a priority tree (whilst maintaining support for reordering the
> tree).
>
> To avoid the additional allocations and list manipulations, the use of
> the priotree is disabled when there are no schedulers to use it.
>
> v2: Create a dedicated slab for i915_dependency.
> Rename the lists.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gem.c | 11 +++-
> drivers/gpu/drm/i915/i915_gem_request.c | 91 ++++++++++++++++++++++++++++++++-
> drivers/gpu/drm/i915/i915_gem_request.h | 33 ++++++++++++
> 4 files changed, 134 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c0f1dfc7119e..ab4ad5522cf5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1778,6 +1778,7 @@ struct drm_i915_private {
> struct kmem_cache *objects;
> struct kmem_cache *vmas;
> struct kmem_cache *requests;
> + struct kmem_cache *dependencies;
>
> const struct intel_device_info info;
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index e1afa11609a0..b331e5966fe2 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4431,12 +4431,18 @@ i915_gem_load_init(struct drm_device *dev)
> if (!dev_priv->requests)
> goto err_vmas;
>
> + dev_priv->dependencies = KMEM_CACHE(i915_dependency,
> + SLAB_HWCACHE_ALIGN |
> + SLAB_RECLAIM_ACCOUNT);
> + if (!dev_priv->dependencies)
> + goto err_requests;
> +
> mutex_lock(&dev_priv->drm.struct_mutex);
> INIT_LIST_HEAD(&dev_priv->gt.timelines);
> err = i915_gem_timeline_init__global(dev_priv);
> mutex_unlock(&dev_priv->drm.struct_mutex);
> if (err)
> - goto err_requests;
> + goto err_dependencies;
>
> INIT_LIST_HEAD(&dev_priv->context_list);
> INIT_WORK(&dev_priv->mm.free_work, __i915_gem_free_work);
> @@ -4464,6 +4470,8 @@ i915_gem_load_init(struct drm_device *dev)
>
> return 0;
>
> +err_dependencies:
> + kmem_cache_destroy(dev_priv->dependencies);
> err_requests:
> kmem_cache_destroy(dev_priv->requests);
> err_vmas:
> @@ -4480,6 +4488,7 @@ void i915_gem_load_cleanup(struct drm_device *dev)
>
> WARN_ON(!llist_empty(&dev_priv->mm.free_list));
>
> + kmem_cache_destroy(dev_priv->dependencies);
> kmem_cache_destroy(dev_priv->requests);
> kmem_cache_destroy(dev_priv->vmas);
> kmem_cache_destroy(dev_priv->objects);
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c
> index 1118cf48d6f0..78c87d94d205 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -113,6 +113,77 @@ i915_gem_request_remove_from_client(struct drm_i915_gem_request *request)
> spin_unlock(&file_priv->mm.lock);
> }
>
> +static struct i915_dependency *
> +i915_dependency_alloc(struct drm_i915_private *i915)
> +{
> + return kmem_cache_alloc(i915->dependencies, GFP_KERNEL);
> +}
> +
> +static void
> +i915_dependency_free(struct drm_i915_private *i915,
> + struct i915_dependency *dep)
> +{
> + kmem_cache_free(i915->dependencies, dep);
> +}
> +
> +static void
> +__i915_priotree_add_dependency(struct i915_priotree *pt,
> + struct i915_priotree *signal,
> + struct i915_dependency *dep,
> + unsigned long flags)
> +{
> + list_add(&dep->wait_link, &signal->waiters_list);
> + list_add(&dep->signal_link, &pt->signalers_list);
> + dep->signaler = signal;
> + dep->flags = flags;
> +}
> +
> +static int
> +i915_priotree_add_dependency(struct drm_i915_private *i915,
> + struct i915_priotree *pt,
> + struct i915_priotree *signal)
> +{
> + struct i915_dependency *dep;
> +
> + dep = i915_dependency_alloc(i915);
> + if (!dep)
> + return -ENOMEM;
> +
> + __i915_priotree_add_dependency(pt, signal, dep, I915_DEPENDENCY_ALLOC);
> + return 0;
> +}
> +
> +static void
> +i915_priotree_fini(struct drm_i915_private *i915, struct i915_priotree *pt)
> +{
> + struct i915_dependency *dep, *next;
> +
> + /* Everyone we depended upon (the fences we wait to be signaled)
> + * should retire before us and remove themselves from our list.
> + * However, retirement is run independently on each timeline and
> + * so we may be called out-of-order.
> + */
> + list_for_each_entry_safe(dep, next, &pt->signalers_list, signal_link) {
> + list_del(&dep->wait_link);
> + if (dep->flags & I915_DEPENDENCY_ALLOC)
> + i915_dependency_free(i915, dep);
> + }
> +
> + /* Remove ourselves from everyone who depends upon us */
> + list_for_each_entry_safe(dep, next, &pt->waiters_list, wait_link) {
> + list_del(&dep->signal_link);
> + if (dep->flags & I915_DEPENDENCY_ALLOC)
> + i915_dependency_free(i915, dep);
> + }
> +}
> +
> +static void
> +i915_priotree_init(struct i915_priotree *pt)
> +{
> + INIT_LIST_HEAD(&pt->signalers_list);
> + INIT_LIST_HEAD(&pt->waiters_list);
> +}
> +
> void i915_gem_retire_noop(struct i915_gem_active *active,
> struct drm_i915_gem_request *request)
> {
> @@ -182,6 +253,8 @@ static void i915_gem_request_retire(struct drm_i915_gem_request *request)
> i915_gem_context_put(request->ctx);
>
> dma_fence_signal(&request->fence);
> +
> + i915_priotree_fini(request->i915, &request->priotree);
> i915_gem_request_put(request);
> }
>
> @@ -467,6 +540,8 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
> */
> i915_sw_fence_await_sw_fence(&req->execute, &req->submit, &req->execq);
>
> + i915_priotree_init(&req->priotree);
> +
> INIT_LIST_HEAD(&req->active_list);
> req->i915 = dev_priv;
> req->engine = engine;
> @@ -520,6 +595,14 @@ i915_gem_request_await_request(struct drm_i915_gem_request *to,
>
> GEM_BUG_ON(to == from);
>
> + if (to->engine->schedule) {
> + ret = i915_priotree_add_dependency(to->i915,
> + &to->priotree,
> + &from->priotree);
> + if (ret < 0)
> + return ret;
> + }
> +
> if (to->timeline == from->timeline)
> return 0;
>
> @@ -743,9 +826,15 @@ void __i915_add_request(struct drm_i915_gem_request *request, bool flush_caches)
>
> prev = i915_gem_active_raw(&timeline->last_request,
> &request->i915->drm.struct_mutex);
> - if (prev)
> + if (prev) {
> i915_sw_fence_await_sw_fence(&request->submit, &prev->submit,
> &request->submitq);
> + if (engine->schedule)
> + __i915_priotree_add_dependency(&request->priotree,
> + &prev->priotree,
> + &request->dep,
> + 0);
> + }
>
> spin_lock_irq(&timeline->lock);
> list_add_tail(&request->link, &timeline->requests);
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.h b/drivers/gpu/drm/i915/i915_gem_request.h
> index 4d2784633d9f..943c39d2a62a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.h
> +++ b/drivers/gpu/drm/i915/i915_gem_request.h
> @@ -44,6 +44,28 @@ struct intel_signal_node {
> struct intel_wait wait;
> };
>
> +struct i915_dependency {
> + struct i915_priotree *signaler;
> + struct list_head signal_link;
> + struct list_head wait_link;
> + unsigned long flags;
> +#define I915_DEPENDENCY_ALLOC BIT(0)
> +};
> +
> +/* Requests exist in a complex web of interdependencies. Each request
> + * has to wait for some other request to complete before it is ready to be run
> + * (e.g. we have to wait until the pixels have been rendering into a texture
> + * before we can copy from it). We track the readiness of a request in terms
> + * of fences, but we also need to keep the dependency tree for the lifetime
> + * of the request (beyond the life of an individual fence). We use the tree
> + * at various points to reorder the requests whilst keeping the requests
> + * in order with respect to their various dependencies.
> + */
> +struct i915_priotree {
> + struct list_head signalers_list; /* those before us, we depend upon */
> + struct list_head waiters_list; /* those after us, they depend upon us */
> +};
> +
> /**
> * Request queue structure.
> *
> @@ -105,6 +127,17 @@ struct drm_i915_gem_request {
> wait_queue_t submitq;
> wait_queue_t execq;
>
> + /* A list of everyone we wait upon, and everyone who waits upon us.
> + * Even though we will not be submitted to the hardware before the
> + * submit fence is signaled (it waits for all external events as well
> + * as our own requests), the scheduler still needs to know the
> + * dependency tree for the lifetime of the request (from execbuf
> + * to retirement), i.e. bidirectional dependency information for the
> + * request not tied to individual fences.
> + */
> + struct i915_priotree priotree;
> + struct i915_dependency dep;
> +
> u32 global_seqno;
>
> /** GEM sequence number associated with the previous request,
>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
From: Laszlo Ersek @ 2016-11-14 11:08 UTC (permalink / raw)
To: Daniel P. Berrange, Paolo Bonzini
Cc: Dave Young, Andrew Jones, bhe, qemu-devel, qiaonuohan, anderson
In-Reply-To: <20161114103342.GI8314@redhat.com>
On 11/14/16 11:33, Daniel P. Berrange wrote:
> On Mon, Nov 14, 2016 at 11:28:04AM +0100, Paolo Bonzini wrote:
>>
>>
>> On 14/11/2016 11:10, Daniel P. Berrange wrote:
>>> There's already patches posted to create a virtio-pstore device for
>>> QEMU, which is what led me to suggest this as an option:
>>>
>>> https://lists.nongnu.org/archive/html/qemu-devel/2016-09/msg00381.html
>>
>> It's also possible to use UEFI as a pstore backend.
>
> Presumably that'll also require some QEMU patches to provide storage
> for UEFI's pstore ?
Using UEFI non-volatile variables as a pstore backend is a guest kernel
feature, and it already works transparently with OVMF utilizing QEMU's
pflash device. If memory serves, the data to be written are broken into
1KB chunks, and saved as separate UEFI variables under a dedicated
namespace GUID.
https://bugzilla.redhat.com/show_bug.cgi?id=828497
(Private BZ -- I apologize to the non-RedHatter subscribers that read this.)
(Also, not everyone has been enthusiastic about this feature:
<https://bugzilla.redhat.com/show_bug.cgi?id=919485>.)
Anyway, when I say "it works", I mean it works for the direct purpose of
storing data (like saving dmesg at panic), and for retrieving data, from
within the guest. (At a subsequent guest boot, possibly.) This is the
scope of pstore in general, AIUI (see "Documentation/ABI/testing/pstore").
However, host-side insight into the OVMF/edk2 varstore format remains
something we don't, and shouldn't, implement. In this regard, the UEFI
variables that happen to contain pstore data are no different from other
kinds of UEFI variables; they are equally opaque from the host side.
(Unless we want to implement and maintain a large utility that reflects
and tracks the multi-layer variable driver stack in edk2. "Unless" is
rhetorical, we don't want that.)
If host-side access is needed to the guest's phys-base / virt-base, then
my first preference would be the guest agent (interrogated at guest
startup), and my second preference would be virtio-pstore. I reckon
virtio-pstore will take a new guest driver, and I suppose the host-side
on-disk format is being designed for easy parsing.
Thanks
Laszlo
^ permalink raw reply
* Re: [PATCH v3 0/2] arm64: Support systems without FP/ASIMD
From: Catalin Marinas @ 2016-11-14 11:08 UTC (permalink / raw)
To: Marc Zyngier
Cc: Suzuki K Poulose, mark.rutland, ard.biesheuvel, will.deacon,
linux-kernel, kvmarm, linux-arm-kernel
In-Reply-To: <d9b41cca-9a9c-ab92-d3e5-ee1870bb70d4@arm.com>
On Fri, Nov 11, 2016 at 01:41:37PM +0000, Marc Zyngier wrote:
> On 08/11/16 13:56, Suzuki K Poulose wrote:
> > This series adds supports to the kernel and KVM hyp to handle
> > systems without FP/ASIMD properly. At the moment the kernel
> > doesn't check if the FP unit is available before accessing
> > the registers (e.g during context switch). Also for KVM,
> > we trap the FP/ASIMD accesses and handle it by injecting an
> > undefined instruction into the VM on systems without FP.
> >
> > Tested on a FVP_Base-AEM-v8A model by disabling VFP on at
> > least one CPU ( -C clusterX.cpuY.vfp-present=0 ).
> >
> > Changes since V2:
> > - Dropped cleanup patch for arm64/crypto/aes-ce-ccm-glue.c
> > - Removed static_key check from cpus_have_cap. All users with
> > constant caps should use the new API to make use of static_keys.
> > - Removed a dedicated static_key used in irqchip-gic-v3.c for
> > Cavium errata with the new API.
> >
> > Applies on v4.9-rc4 + [1] (which is pushed for rc5)
> >
> > [1] http://marc.info/?l=linux-arm-kernel&m=147819889813214&w=2
> >
> >
> > Suzuki K Poulose (2):
> > arm64: Add hypervisor safe helper for checking constant capabilities
> > arm64: Support systems without FP/ASIMD
> >
> > arch/arm64/include/asm/cpucaps.h | 3 ++-
> > arch/arm64/include/asm/cpufeature.h | 24 +++++++++++++++++-------
> > arch/arm64/include/asm/neon.h | 3 ++-
> > arch/arm64/kernel/cpufeature.c | 17 ++++++++++++++++-
> > arch/arm64/kernel/fpsimd.c | 14 ++++++++++++++
> > arch/arm64/kernel/process.c | 2 +-
> > arch/arm64/kvm/handle_exit.c | 11 +++++++++++
> > arch/arm64/kvm/hyp/hyp-entry.S | 9 ++++++++-
> > arch/arm64/kvm/hyp/switch.c | 5 ++++-
> > drivers/irqchip/irq-gic-v3.c | 13 +------------
> > 10 files changed, 76 insertions(+), 25 deletions(-)
>
> For the series:
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
>
> How do we plan on merging this? Catalin, are you willing to take it all?
Happy to take it all through the arm64 tree. Thanks for the review.
--
Catalin
^ permalink raw reply
* [PATCH 5/5] net: thunderx: Fix memory leak and other issues upon interface toggle
From: sunil.kovvuri @ 2016-11-14 10:54 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, linux-arm-kernel, Sunil Goutham
In-Reply-To: <1479120886-13425-1-git-send-email-sunil.kovvuri@gmail.com>
From: Sunil Goutham <sgoutham@cavium.com>
This patch fixes the following
1. When interface is being teardown and queues are being cleaned up,
free pending SKBs that are in SQ which are either not transmitted
or freed as NAPI is disabled by that time.
2. While interface initialization, delay CFG_DONE notification till
the end to avoid corner cases where TXQs are enabled but CQ
interrupts are not which results blocking transmission and kicking
off watchdog.
3. Check for IFF_UP while re-enabling RBDR interrupts from tasklet.
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 11 +++++------
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 14 +++++++++++++-
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 9dc79c05..8a37012 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -473,9 +473,6 @@ int nicvf_set_real_num_queues(struct net_device *netdev,
static int nicvf_init_resources(struct nicvf *nic)
{
int err;
- union nic_mbx mbx = {};
-
- mbx.msg.msg = NIC_MBOX_MSG_CFG_DONE;
/* Enable Qset */
nicvf_qset_config(nic, true);
@@ -488,9 +485,6 @@ static int nicvf_init_resources(struct nicvf *nic)
return err;
}
- /* Send VF config done msg to PF */
- nicvf_write_to_mbx(nic, &mbx);
-
return 0;
}
@@ -1184,6 +1178,7 @@ int nicvf_open(struct net_device *netdev)
struct nicvf *nic = netdev_priv(netdev);
struct queue_set *qs = nic->qs;
struct nicvf_cq_poll *cq_poll = NULL;
+ union nic_mbx mbx = {};
netif_carrier_off(netdev);
@@ -1271,6 +1266,10 @@ int nicvf_open(struct net_device *netdev)
for (qidx = 0; qidx < qs->rbdr_cnt; qidx++)
nicvf_enable_intr(nic, NICVF_INTR_RBDR, qidx);
+ /* Send VF config done msg to PF */
+ mbx.msg.msg = NIC_MBOX_MSG_CFG_DONE;
+ nicvf_write_to_mbx(nic, &mbx);
+
return 0;
cleanup:
nicvf_disable_intr(nic, NICVF_INTR_MBOX, 0);
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index 86726ab..43ccc9d 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -271,7 +271,8 @@ static void nicvf_refill_rbdr(struct nicvf *nic, gfp_t gfp)
rbdr_idx, new_rb);
next_rbdr:
/* Re-enable RBDR interrupts only if buffer allocation is success */
- if (!nic->rb_alloc_fail && rbdr->enable)
+ if (!nic->rb_alloc_fail && rbdr->enable &&
+ netif_running(nic->pnicvf->netdev))
nicvf_enable_intr(nic, NICVF_INTR_RBDR, rbdr_idx);
if (rbdr_idx)
@@ -362,6 +363,8 @@ static int nicvf_init_snd_queue(struct nicvf *nic,
static void nicvf_free_snd_queue(struct nicvf *nic, struct snd_queue *sq)
{
+ struct sk_buff *skb;
+
if (!sq)
return;
if (!sq->dmem.base)
@@ -372,6 +375,15 @@ static void nicvf_free_snd_queue(struct nicvf *nic, struct snd_queue *sq)
sq->dmem.q_len * TSO_HEADER_SIZE,
sq->tso_hdrs, sq->tso_hdrs_phys);
+ /* Free pending skbs in the queue */
+ smp_rmb();
+ while (sq->head != sq->tail) {
+ skb = (struct sk_buff *)sq->skbuff[sq->head];
+ if (skb)
+ dev_kfree_skb_any(skb);
+ sq->head++;
+ sq->head &= (sq->dmem.q_len - 1);
+ }
kfree(sq->skbuff);
nicvf_free_q_desc_mem(nic, &sq->dmem);
}
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/2] arm64: Support systems without FP/ASIMD
From: Catalin Marinas @ 2016-11-14 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d9b41cca-9a9c-ab92-d3e5-ee1870bb70d4@arm.com>
On Fri, Nov 11, 2016 at 01:41:37PM +0000, Marc Zyngier wrote:
> On 08/11/16 13:56, Suzuki K Poulose wrote:
> > This series adds supports to the kernel and KVM hyp to handle
> > systems without FP/ASIMD properly. At the moment the kernel
> > doesn't check if the FP unit is available before accessing
> > the registers (e.g during context switch). Also for KVM,
> > we trap the FP/ASIMD accesses and handle it by injecting an
> > undefined instruction into the VM on systems without FP.
> >
> > Tested on a FVP_Base-AEM-v8A model by disabling VFP on at
> > least one CPU ( -C clusterX.cpuY.vfp-present=0 ).
> >
> > Changes since V2:
> > - Dropped cleanup patch for arm64/crypto/aes-ce-ccm-glue.c
> > - Removed static_key check from cpus_have_cap. All users with
> > constant caps should use the new API to make use of static_keys.
> > - Removed a dedicated static_key used in irqchip-gic-v3.c for
> > Cavium errata with the new API.
> >
> > Applies on v4.9-rc4 + [1] (which is pushed for rc5)
> >
> > [1] http://marc.info/?l=linux-arm-kernel&m=147819889813214&w=2
> >
> >
> > Suzuki K Poulose (2):
> > arm64: Add hypervisor safe helper for checking constant capabilities
> > arm64: Support systems without FP/ASIMD
> >
> > arch/arm64/include/asm/cpucaps.h | 3 ++-
> > arch/arm64/include/asm/cpufeature.h | 24 +++++++++++++++++-------
> > arch/arm64/include/asm/neon.h | 3 ++-
> > arch/arm64/kernel/cpufeature.c | 17 ++++++++++++++++-
> > arch/arm64/kernel/fpsimd.c | 14 ++++++++++++++
> > arch/arm64/kernel/process.c | 2 +-
> > arch/arm64/kvm/handle_exit.c | 11 +++++++++++
> > arch/arm64/kvm/hyp/hyp-entry.S | 9 ++++++++-
> > arch/arm64/kvm/hyp/switch.c | 5 ++++-
> > drivers/irqchip/irq-gic-v3.c | 13 +------------
> > 10 files changed, 76 insertions(+), 25 deletions(-)
>
> For the series:
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
>
> How do we plan on merging this? Catalin, are you willing to take it all?
Happy to take it all through the arm64 tree. Thanks for the review.
--
Catalin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.