* [PATCH v2 15/18] drivers/fsi: Add documentation for GPIO based FSI master
From: Jeremy Kerr @ 2017-01-19 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118215755.xoamoc2rrzhy4kyz@rob-hp-laptop>
Hi Chris,
>From this:
>> +
>> +The standard FSI master node
>> +----------------------------
>> +This node describes a FSI master implmemented fully in hardware
>> +with dedicated input/output pins required for its function (i.e.
>> +not using generic GPIO pins).
>> +Required property:
>> + compatible = "ibm,fsi-master"
and this:
>> +Example:
>> +
>> +fsi-master {
>> + compatible = "ibm,fsi-master-gpio", "ibm,fsi-master";
>
> From the description, these should be mutually exclusive.
I agree with Rob here. The intention is for "ibm,fsi-master" to be an
abstract master -- simply indicating that this node describes a master,
with no specific implementation, and "ibm,fsi-master-gpio" to be a
GPIO-based implementation. A hardware-based FSI master would have a
different compatible value, based on the hardware.
We should remove references to implementations in the "The standard FSI
master node" section, because this is independent of implementation.
>> + clk-gpios = <&gpio 0>, <&gpio 6>;
>> + data-gpios = <&gpio 1>, <&gpio 7>;
>> + enable-gpios = <&gpio 2>, <&gpio 8>;
>> + trans-gpios = <&gpio 3>, <&gpio 9>;
>> + mux-gpios = <&gpio 4>, <&gpio 10>;
Do we support multiple-link masters? This example implies a 2-link
master.
Cheers,
Jeremy
^ permalink raw reply
* [PATCH 0/2] Add support for RK3288 Tinker board
From: Eddie Cai @ 2017-01-19 2:11 UTC (permalink / raw)
To: linux-arm-kernel
This patch set add support for RK3288 Tinker board.
Tinker board is a credit card size develop board powered by RK3288.
Eddie Cai (2):
dt-bindings: add Asus Tinker board
ARM: dts: rockchip: add dts for RK3288-Tinker board
Documentation/devicetree/bindings/arm/rockchip.txt | 3 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk3288-tinker.dts | 556 +++++++++++++++++++++
3 files changed, 560 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3288-tinker.dts
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] dt-bindings: add Asus Tinker board
From: Eddie Cai @ 2017-01-19 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484791919-4665-1-git-send-email-eddie.cai@rock-chips.com>
Tinker board is a credit card size develop board designed by Asus.
Powered by RK3288.
Signed-off-by: Eddie Cai <eddie.cai@rock-chips.com>
---
Documentation/devicetree/bindings/arm/rockchip.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
index cc4ace6..ce1f04a 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -1,5 +1,8 @@
Rockchip platforms device tree bindings
---------------------------------------
+- Asus Tinker board
+ Required root node properties:
+ - compatible = "rockchip,rk3288-tinker", "rockchip,rk3288";
- Kylin RK3036 board:
Required root node properties:
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: rockchip: add dts for RK3288-Tinker board
From: Eddie Cai @ 2017-01-19 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484791919-4665-1-git-send-email-eddie.cai@rock-chips.com>
This patch add basic support for RK3288-Tinker board. We can boot in to rootfs
with this patch.
Signed-off-by: Eddie Cai <eddie.cai@rock-chips.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk3288-tinker.dts | 556 ++++++++++++++++++++++++++++++++++++
2 files changed, 557 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3288-tinker.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7327250..4fc05b7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -679,6 +679,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-popmetal.dtb \
rk3288-r89.dtb \
rk3288-rock2-square.dtb \
+ rk3288-tinker.dtb \
rk3288-veyron-brain.dtb \
rk3288-veyron-jaq.dtb \
rk3288-veyron-jerry.dtb \
diff --git a/arch/arm/boot/dts/rk3288-tinker.dts b/arch/arm/boot/dts/rk3288-tinker.dts
new file mode 100644
index 0000000..37cb431
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-tinker.dts
@@ -0,0 +1,556 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ *
+ * 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 "rk3288.dtsi"
+
+/ {
+ model = "Rockchip RK3288 Tinker Board";
+ compatible = "rockchip,rk3288-tinker", "rockchip,rk3288";
+
+ memory {
+ reg = <0x0 0x80000000>;
+ device_type = "memory";
+ };
+
+ ext_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ clock-output-names = "ext_gmac";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwrbtn>;
+
+ button at 0 {
+ gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
+ linux,code = <116>;
+ label = "GPIO Key Power";
+ linux,input-type = <1>;
+ gpio-key,wakeup = <1>;
+ debounce-interval = <100>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ pwr-led {
+ gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ act-led {
+ gpios=<&gpio2 3 GPIO_ACTIVE_LOW>;
+ linux,default-trigger="mmc0";
+ };
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,name = "rockchip,tinker-codec";
+ simple-audio-card,mclk-fs = <512>;
+ simple-audio-card,cpu {
+ sound-dai = <&i2s>;
+ };
+ simple-audio-card,codec {
+ sound-dai = <&hdmi>;
+ };
+ };
+
+ vcc_sys: vsys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ /*
+ * NOTE: vcc_sd isn't hooked up on v1.0 boards where power comes from
+ * vcc_io directly. Those boards won't be able to power cycle SD cards
+ * but it shouldn't hurt to toggle this pin there anyway.
+ */
+ vcc_sd: sdmmc-regulator {
+ compatible = "regulator-fixed";
+ gpio = <&gpio7 11 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_pwr>;
+ regulator-name = "vcc_sd";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ startup-delay-us = <100000>;
+ vin-supply = <&vcc_io>;
+ };
+};
+
+&cpu0 {
+ cpu0-supply = <&vdd_cpu>;
+};
+
+&gmac {
+ phy-supply = <&vcc33_lan>;
+ phy-mode = "rgmii";
+ clock_in_out = "input";
+ snps,reset-gpio = <&gpio4 7 0>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 1000000>;
+ assigned-clocks = <&cru SCLK_MAC>;
+ assigned-clock-parents = <&ext_gmac>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ tx_delay = <0x30>;
+ rx_delay = <0x10>;
+ status = "ok";
+};
+
+&hdmi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <0>;
+ ddc-i2c-bus = <&i2c5>;
+ status = "okay";
+ /* Don't use vopl for HDMI */
+ ports {
+ hdmi_in: port {
+ /delete-node/ endpoint at 1;
+ };
+ };
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <400000>;
+
+ rk808: pmic at 1b {
+ compatible = "rockchip,rk808";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int &global_pwroff &dvs_1 &dvs_2>;
+ dvs-gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>,
+ <&gpio0 12 GPIO_ACTIVE_HIGH>;
+
+ rockchip,system-power-controller;
+ wakeup-source;
+ #clock-cells = <1>;
+ clock-output-names = "xin32k", "rk808-clkout2";
+
+ vcc1-supply = <&vcc_sys>;
+ vcc2-supply = <&vcc_sys>;
+ vcc3-supply = <&vcc_sys>;
+ vcc4-supply = <&vcc_sys>;
+ vcc6-supply = <&vcc_sys>;
+ vcc7-supply = <&vcc_sys>;
+ vcc8-supply = <&vcc_18>;
+ vcc9-supply = <&vcc_io>;
+ vcc10-supply = <&vcc_io>;
+ vcc11-supply = <&vcc_sys>;
+ vcc12-supply = <&vcc_io>;
+ vddio-supply = <&vcc18_ldo1>;
+
+ regulators {
+ vdd_cpu: DCDC_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-name = "vdd_arm";
+ regulator-ramp-delay = <6000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: DCDC_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-name = "vdd_gpu";
+ regulator-ramp-delay = <6000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1000000>;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vcc_ddr";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_io: DCDC_REG4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_io";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcc18_ldo1: LDO_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc18_ldo1";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc33_mipi: LDO_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc33_mipi";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_10: LDO_REG3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-name = "vdd_10";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1000000>;
+ };
+ };
+
+ vcc18_codec: LDO_REG4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc18_codec";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vccio_sd: LDO_REG5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_sd";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vdd10_lcd: LDO_REG6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-name = "vdd10_lcd";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1000000>;
+ };
+ };
+
+ vcc_18: LDO_REG7 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc_18";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc18_lcd: LDO_REG8 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc18_lcd";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc33_sd: SWITCH_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vcc33_sd";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc33_lan: SWITCH_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vcc33_lan";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c5 {
+ status = "okay";
+};
+
+&i2s {
+ #sound-dai-cells = <0>;
+ status = "okay";
+};
+
+&io_domains {
+ status = "okay";
+
+ sdcard-supply = <&vccio_sd>;
+};
+
+&pinctrl {
+ pcfg_pull_none_drv_8ma: pcfg-pull-none-drv-8ma {
+ drive-strength = <8>;
+ };
+
+ pcfg_pull_up_drv_8ma: pcfg-pull-up-drv-8ma {
+ bias-pull-up;
+ drive-strength = <8>;
+ };
+
+ backlight {
+ bl_en: bl-en {
+ rockchip,pins = <7 2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ buttons {
+ pwrbtn: pwrbtn {
+ rockchip,pins = <0 5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ eth_phy {
+ eth_phy_pwr: eth-phy-pwr {
+ rockchip,pins = <0 6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int: pmic-int {
+ rockchip,pins = <RK_GPIO0 4 RK_FUNC_GPIO \
+ &pcfg_pull_up>;
+ };
+
+ dvs_1: dvs-1 {
+ rockchip,pins = <RK_GPIO0 11 RK_FUNC_GPIO \
+ &pcfg_pull_down>;
+ };
+
+ dvs_2: dvs-2 {
+ rockchip,pins = <RK_GPIO0 12 RK_FUNC_GPIO \
+ &pcfg_pull_down>;
+ };
+ };
+
+ sdmmc {
+ /*
+ * Default drive strength isn't enough to achieve even
+ * high-speed mode on EVB board so bump up to 8ma.
+ */
+ sdmmc_bus4: sdmmc-bus4 {
+ rockchip,pins = <6 16 RK_FUNC_1 &pcfg_pull_up_drv_8ma>,
+ <6 17 RK_FUNC_1 &pcfg_pull_up_drv_8ma>,
+ <6 18 RK_FUNC_1 &pcfg_pull_up_drv_8ma>,
+ <6 19 RK_FUNC_1 &pcfg_pull_up_drv_8ma>;
+ };
+
+ sdmmc_clk: sdmmc-clk {
+ rockchip,pins = <6 20 RK_FUNC_1 \
+ &pcfg_pull_none_drv_8ma>;
+ };
+
+ sdmmc_cmd: sdmmc-cmd {
+ rockchip,pins = <6 21 RK_FUNC_1 &pcfg_pull_up_drv_8ma>;
+ };
+
+ sdmmc_pwr: sdmmc-pwr {
+ rockchip,pins = <7 11 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ usb {
+ host_vbus_drv: host-vbus-drv {
+ rockchip,pins = <0 14 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ pwr_3g: pwr-3g {
+ rockchip,pins = <7 8 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&pwm0 {
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&vcc18_ldo1>;
+ status ="okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ card-detect-delay = <200>;
+ disable-wp; /* wp not hooked up */
+ num-slots = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
+ status = "okay";
+ supports-sd;
+ vmmc-supply = <&vcc_sd>;
+ vqmmc-supply = <&vccio_sd>;
+};
+
+&tsadc {
+ rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
+ rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&uart4 {
+ status = "okay";
+};
+
+&usbphy {
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ no-relinquish-port;
+ status = "okay";
+};
+
+&usb_host1 {
+ status = "okay";
+};
+
+&usb_otg {
+ status= "okay";
+};
+
+&vopb {
+ status = "okay";
+};
+
+&vopb_mmu {
+ status = "okay";
+};
+
+&vopl {
+ status = "okay";
+ /* Don't use vopl for HDMI */
+ vopl_out: port {
+ /delete-node/ endpoint at 0;
+ };
+};
+
+&vopl_mmu {
+ status = "okay";
+};
+
+&wdt {
+ status = "okay";
+};
+
--
2.7.4
^ permalink raw reply related
* [PATCH v10 0/8] arm/arm64: vgic: Implement API for vGICv3 live migration
From: Shannon Zhao @ 2017-01-19 2:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480576187-5012-1-git-send-email-vijay.kilari@gmail.com>
Hi Vijaya,
On 2016/12/1 15:09, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>
> This patchset adds API for saving and restoring
> of VGICv3 registers to support live migration with new vgic feature.
> This API definition is as per version of VGICv3 specification
> Documentation/virtual/kvm/devices/arm-vgic-v3.txt
>
> The patch 3 & 4 are picked from the Pavel's previous implementation.
> http://www.spinics.net/lists/kvm/msg122040.html
>
> NOTE: Only compilation tested for AArch32. No hardware to test.
>
Where can I fetch the latest corresponding QEMU patches? I didn't find
them in qemu-devel/qemu-arm mail list.
Thanks,
--
Shannon
^ permalink raw reply
* [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Rob Herring @ 2017-01-19 2:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170119103829.524ce715@free-electrons.com>
On Wed, Jan 18, 2017 at 5:38 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Wed, 18 Jan 2017 16:20:10 -0600, Rob Herring wrote:
>
>> > > Rob, Mark, any opinion?
>> >
>>
>> Sigh, is how to do compatibles really not yet understood?
>
> Well, it seems like not everyone necessarily understands what is the
> best strategy to adopt (me included).
>
>> > I agree that a clarification would be good. There are really two
>> > options:
>> >
>> > 1. Have two compatible strings in the DT, the one that matches the
>> > exact SoC where the IP is found (first compatible string) and the
>> > one that matches some other SoC where the same IP is found (second
>> > compatible string). Originally, Linux only supports the second
>> > compatible string in its device driver, but if it happens that a
>> > difference is found between two IPs that we thought were the same,
>> > we can add support for the first compatible string in the driver,
>> > with a slightly different behavior.
>>
>> This. And no wildcards in the compatible string.
>
> OK. So it means that today we do something like:
>
> compatible = "baz,foo-12", "baz,foo-00";
>
> and support only baz,foo-00 in the driver. If tomorrow we discover
> that there is in fact a difference between the two IP blocks, we can
> add support for baz,foo-12 in the driver, and handle the differences.
>
> But then, the DT still contains:
>
> compatible = "baz,foo-12", "baz,foo-00";
>
> and therefore pretends that the IP block is compatible with
> "baz,foo-00" which is in fact *not* the case. It was a mistake to
> consider it as compatible. So we keep living with a DT that has
> incorrect information.
I wouldn't say it's a mistake necessarily. The old compatible would
probably work to some extent. I'd assume it was tested to some level.
Or it could be other changes exposing a difference.
>> > 2. Have a single compatible string in the DT, matching the exact SoC
>> > where the IP is found. This involves adding immediately this
>> > compatible string in the corresponding driver.
>>
>> I wouldn't object to this from a DT perspective as I have no clue
>> generally if IP blocks are "the same" or not. Subsystem maintainers will
>> object though.
>
> Knowing if IP blocks are "the same" is in fact not necessarily trivial.
> What appears to be identical IP blocks today might be discovered later
> as actually having subtle differences (sometimes not even visible in
> the datasheet).
Yes, I know. That's exactly when you should have multiple compatibles.
Trying to guarantee things are the same is just going to get you in
trouble. You only need to figure out if blocks are obviously different
and only drop the old compatible in that case.
>> > I've not really been able to figure out which of the two options is the
>> > most future-proof/appropriate.
>>
>> They are both future-proof. #2 has the disadvantage of requiring a
>> kernel update for a new SoC.
>
> Which is generally anyway needed because a new SoC will almost always
> require some new drivers, adjusting pin-muxing or clock drivers, etc.
Yes, but you don't want to have to update every single driver.
Rob
^ permalink raw reply
* [GIT PULL] ARM: aspeed: devicetree for 4.11
From: Joel Stanley @ 2017-01-19 2:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170119002711.GJ23725@localhost>
On Thu, Jan 19, 2017 at 11:27 AM, Olof Johansson <olof@lixom.net> wrote:
> On Wed, Jan 18, 2017 at 09:50:02AM +1100, Joel Stanley wrote:
>> These commits also add newly upstreamed drivers to the Palmetto BMC and ast2500
>> eval board. We now have working network, ipmi bt, gpio and pinmux on
>> all platforms.
>>
>> ARM: dts: aspeed: Add Romulus BMC platform
>> ARM: dts: aspeed: Add ftgmac100 to g4 and g5 platforms
>> ARM: dts: aspeed: Correct palmetto device tree
>> ARM: dts: aspeed: Reserve framebuffer memory
>> ARM: dts: aspeed-g5: Add gpio controller to devicetree
>> ARM: dts: aspeed-g5: Add syscon and pin controller nodes
>> ARM: dts: aspeed-g5: Add LPC Controller node
>> ARM: dts: aspeed-g5: Add SoC Display Controller node
>> ARM: dts: aspeed-g4: Add gpio controller to devicetree
>> ARM: dts: aspeed-g4: Add syscon and pin controller nodes
>
> Hi,
>
> Merged, but for the future there's no need for you to list the patches in the
> tag message, git inserts a list when we merge (--log), and git request-pull
> already provides the shortlog.
Thanks for the heads up. I've made a note of that for next time.
> (512MB RAM on a BMC? That's just insane :).
Yep :) It was 1GB in the first spin of the board.
Cheers,
Joel
^ permalink raw reply
* [PATCH v3 2/3] Documentation: devicetree: Add document bindings for mtk-cir
From: Sean Wang @ 2017-01-19 3:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKsxwY+v-8Q=o1ERpyfFkR7d+83kKUdfY=u21FHUX5UEw@mail.gmail.com>
On Wed, 2017-01-18 at 16:42 -0600, Rob Herring wrote:
> On Wed, Jan 18, 2017 at 4:23 PM, Rob Herring <robh@kernel.org> wrote:
> > On Fri, Jan 13, 2017 at 03:35:38PM +0800, sean.wang at mediatek.com wrote:
> >> From: Sean Wang <sean.wang@mediatek.com>
> >>
> >> This patch adds documentation for devicetree bindings for
> >> consumer Mediatek IR controller.
> >>
> >> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> >> ---
> >> .../devicetree/bindings/media/mtk-cir.txt | 24 ++++++++++++++++++++++
> >> 1 file changed, 24 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
> >
> > Acked-by: Rob Herring <robh@kernel.org>
>
> I guess I rescind my ack if this email doesn't work:
>
> "The response from the remote server was:
>
> 550 Relaying mail to sean.wang at mediatek.com is not allowed"
sorry for causing you inconvenience.
it should be able to work because i almost use this daily
maybe that's just a sudden problem from internal server (?)
but if the problem still continues, please let me know and
i will try to fix this.
^ permalink raw reply
* [PATCH v4 1/2] mailbox: Add driver for Broadcom FlexRM ring manager
From: Anup Patel @ 2017-01-19 3:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483614475-3442-2-git-send-email-anup.patel@broadcom.com>
Hi All,
Any comments on this patch ??
Regards,
Anup
^ permalink raw reply
* [PATCH v11 11/12] drm/mediatek: update DSI sub driver flow for sending commands to panel
From: CK Hu @ 2017-01-19 3:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484117473-46644-12-git-send-email-yt.shen@mediatek.com>
Hi, YT:
one comment inline.
On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
>
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 89 +++++++++++++++++++++++++++++++-------
> 1 file changed, 74 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 85f22d2..21392c4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -126,6 +126,10 @@
> #define CLK_HS_POST (0xff << 8)
> #define CLK_HS_EXIT (0xff << 16)
>
> +#define DSI_VM_CMD_CON 0x130
> +#define VM_CMD_EN BIT(0)
> +#define TS_VFP_EN BIT(5)
> +
> #define DSI_CMDQ0 0x180
> #define CONFIG (0xff << 0)
> #define SHORT_PACKET 0
> @@ -365,16 +369,23 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
> u32 vid_mode = CMD_MODE;
>
> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> - vid_mode = SYNC_PULSE_MODE;
> -
> - if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
> - !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> vid_mode = BURST_MODE;
> + else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + vid_mode = SYNC_PULSE_MODE;
> + else
> + vid_mode = SYNC_EVENT_MODE;
> }
>
> writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
> }
>
> +static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
> +{
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
> +}
> +
> static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
> {
> struct videomode *vm = &dsi->vm;
> @@ -512,6 +523,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
> writel(1, dsi->regs + DSI_START);
> }
>
> +static void mtk_dsi_stop(struct mtk_dsi *dsi)
> +{
> + writel(0, dsi->regs + DSI_START);
> +}
> +
> +static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
> +{
> + writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
> +}
> +
> static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> {
> u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> @@ -570,6 +591,19 @@ static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
> +{
> + mtk_dsi_irq_data_clear(dsi, irq_flag);
> + mtk_dsi_set_cmd_mode(dsi);
> +
> + if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
> + DRM_ERROR("failed to switch cmd mode\n");
> + return -ETIME;
> + } else {
> + return 0;
> + }
> +}
> +
> static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> {
> if (WARN_ON(dsi->refcount == 0))
> @@ -578,6 +612,17 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> if (--dsi->refcount != 0)
> return;
>
> + mtk_dsi_stop(dsi);
> + if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
> + if (dsi->panel) {
> + if (drm_panel_unprepare(dsi->panel)) {
Why drm_panel_unprepare() in mtk_dsi_poweroff() but drm_panel_prepare()
in mtk_output_dsi_enable()? This asymmetric design would easily cause
some bugs.
Regards,
CK
> + DRM_ERROR("failed to unprepare the panel\n");
> + return;
> + }
> + }
> + }
> +
> + mtk_dsi_reset_engine(dsi);
> mtk_dsi_lane0_ulp_mode_enter(dsi);
> mtk_dsi_clk_ulp_mode_enter(dsi);
>
> @@ -596,13 +641,6 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> if (dsi->enabled)
> return;
>
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to setup the panel\n");
> - return;
> - }
> - }
> -
> ret = mtk_dsi_poweron(dsi);
> if (ret < 0) {
> DRM_ERROR("failed to power on dsi\n");
> @@ -610,22 +648,43 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> }
>
> mtk_dsi_rxtx_control(dsi);
> + mtk_dsi_ps_control_vact(dsi);
> + mtk_dsi_set_vm_cmd(dsi);
> + mtk_dsi_config_vdo_timing(dsi);
> + mtk_dsi_set_interrupt_enable(dsi);
>
> mtk_dsi_clk_ulp_mode_leave(dsi);
> mtk_dsi_lane0_ulp_mode_leave(dsi);
> mtk_dsi_clk_hs_mode(dsi, 0);
> - mtk_dsi_set_mode(dsi);
>
> - mtk_dsi_ps_control_vact(dsi);
> - mtk_dsi_config_vdo_timing(dsi);
> - mtk_dsi_set_interrupt_enable(dsi);
> + if (dsi->panel) {
> + if (drm_panel_prepare(dsi->panel)) {
> + DRM_ERROR("failed to prepare the panel\n");
> + goto err_dsi_power_off;
> + }
> + }
>
> mtk_dsi_set_mode(dsi);
> mtk_dsi_clk_hs_mode(dsi, 1);
>
> mtk_dsi_start(dsi);
>
> + if (dsi->panel) {
> + if (drm_panel_enable(dsi->panel)) {
> + DRM_ERROR("failed to enable the panel\n");
> + goto err_panel_disable;
> + }
> + }
> +
> dsi->enabled = true;
> +
> + return;
> +err_panel_disable:
> + mtk_dsi_stop(dsi);
> + if (dsi->panel)
> + drm_panel_unprepare(dsi->panel);
> +err_dsi_power_off:
> + mtk_dsi_poweroff(dsi);
> }
>
> static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
^ permalink raw reply
* [PATCHv4 2/5] arm: mvebu: support for SMP on 98DX3336 SoC
From: Chris Packham @ 2017-01-19 3:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170119004750.GC4857@codeaurora.org>
On 19/01/17 13:48, Stephen Boyd wrote:
> On 01/13, Chris Packham wrote:
>> diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
>> index 46c742d3bd41..59be3ca0464f 100644
>> --- a/arch/arm/mach-mvebu/platsmp.c
>> +++ b/arch/arm/mach-mvebu/platsmp.c
>> @@ -184,3 +184,89 @@ const struct smp_operations armada_xp_smp_ops __initconst = {
>>
>> CPU_METHOD_OF_DECLARE(armada_xp_smp, "marvell,armada-xp-smp",
>> &armada_xp_smp_ops);
>> +
>> +struct resume_controller {
>> + u32 resume_control;
>> + u32 resume_boot_addr;
>> +};
>> +
>> +static const struct resume_controller mv98dx3336_resume_controller = {
>> + .resume_control = 0x08,
>> + .resume_boot_addr = 0x04,
>> +};
>> +
>> +static const struct of_device_id of_mv98dx3236_resume_table[] = {
>> + {
>> + .compatible = "marvell,98dx3336-resume-ctrl",
>> + .data = (void *)&mv98dx3336_resume_controller,
>
> Useless cast?
>
>> + },
>> + { /* end of list */ },
>> +};
>> +
>> +static int mv98dx3236_resume_set_cpu_boot_addr(int hw_cpu, void *boot_addr)
>> +{
>> + const struct of_device_id *match;
>> + struct device_node *np;
>> + void __iomem *base;
>> + struct resume_controller *rc;
>> +
>> + WARN_ON(hw_cpu != 1);
>> +
>> + np = of_find_matching_node_and_match(NULL, of_mv98dx3236_resume_table,
>> + &match);
>> + if (!np)
>> + return -ENODEV;
>> +
>> + base = of_io_request_and_map(np, 0, of_node_full_name(np));
>> + rc = (struct resume_controller *)match->data;
>
> Useless cast?
>
>> + of_node_put(np);
>> + if (IS_ERR(base))
>> + return PTR_ERR(base);
>> +
>> + writel(0, base + rc->resume_control);
>> + writel(virt_to_phys(boot_addr), base + rc->resume_boot_addr);
>> +
>
> Otherwise
>
> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
>
Thanks for the review. Changes will be in v5.
^ permalink raw reply
* [PATCHv4 1/5] clk: mvebu: support for 98DX3236 SoC
From: Chris Packham @ 2017-01-19 3:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118222508.prn5xk63nuc3ocr7@rob-hp-laptop>
On 19/01/17 11:25, Rob Herring wrote:
> On Fri, Jan 13, 2017 at 10:12:16PM +1300, Chris Packham wrote:
>> The 98DX3236, 98DX3336, 98DX4521 and variants have a different TCLK from
>> the Armada XP (200MHz vs 250MHz). The CPU core clock is fixed at 800MHz.
>>
>> The clock gating options are a subset of those on the Armada XP.
>>
>> The core clock divider is different to the Armada XP also.
>>
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>> ---
>>
>> Notes:
>> Changes in v2:
>> - Update devicetree binding documentation for new compatible string
>> Changes in v3:
>> - Add 98dx3236 support to mvebu/clk-corediv.c rather than creating a new
>> driver.
>> - Document mv98dx3236-corediv-clock binding
>> Changes in v4:
>> - None
>>
>> .../bindings/clock/mvebu-corediv-clock.txt | 1 +
>> .../devicetree/bindings/clock/mvebu-cpu-clock.txt | 1 +
>
> Please add acks when posting new versions.
>
> Acked-by: Rob Herring <robh@kernel.org>
>
Thanks Rob. I must have missed the earlier ack. Will be in v5.
^ permalink raw reply
* [PATCH] arm64: dts: msm8996: Add ADSP PIL node
From: Sarangdhar Joshi @ 2017-01-19 3:31 UTC (permalink / raw)
To: linux-arm-kernel
Add ADSP node required for Qualcomm ADSP Peripheral Image Loader.
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
This patch uses "xo_board" clock for now. We would have to move to
rpmcc once it is available.
arch/arm64/boot/dts/qcom/msm8996.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index c9c7fd7..7cebf63 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -181,6 +181,26 @@
method = "smc";
};
+ adsp-pil {
+ compatible = "qcom,msm8996-adsp-pil";
+
+ interrupts-extended = <&intc 0 162 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ clocks = <&xo_board>;
+ clock-names = "xo";
+
+ memory-region = <&adsp_region>;
+
+ qcom,smem-states = <&adsp_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+ };
+
adsp-smp2p {
compatible = "qcom,smp2p";
qcom,smem = <443>, <429>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [GIT PULL] DaVinci fix for v4.10
From: Sekhar Nori @ 2017-01-19 3:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170119001242.GB23725@localhost>
Hi Olof,
On Thursday 19 January 2017 05:42 AM, Olof Johansson wrote:
> Hi Sekhar,
>
> On Wed, Jan 18, 2017 at 04:23:55PM +0530, Sekhar Nori wrote:
>> The following changes since commit 49def1853334396f948dcb4cedb9347abb318df5:
>>
>> Linux 4.10-rc4 (2017-01-15 16:21:59 -0800)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v4.10-part2
>>
>> for you to fetch changes up to 6f042ee9cc09792c1c0f0cd8f275c2b4b29eaa96:
>>
>> ARM: dts: da850-evm: fix read access to SPI flash (2017-01-18 15:38:08 +0530)
>>
>> ----------------------------------------------------------------
>> This patch uses fast-read opcode to read the
>> SPI flash. This is needed for error-free read
>> at 30Mhz.
>>
>> ----------------------------------------------------------------
>> Fabien Parent (1):
>> ARM: dts: da850-evm: fix read access to SPI flash
>
> You're ahead of our branch since this is based on -rc4 when it doesn't
> have to. Want to respin, or should I cherry-pick the patch?
Cherry-picking is fine. Thanks!
Regards,
Sekhar
^ permalink raw reply
* [PATCH v13 1/7] arm64: Rename the common MADT parse routine
From: Hanjun Guo @ 2017-01-19 3:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484686210-7211-2-git-send-email-jeremy.linton@arm.com>
Hi Jeremy,
On 2017/1/18 4:50, Jeremy Linton wrote:
> The MADT parser in smp.c is now being used to parse
> out NUMA, PMU and ACPI parking protocol information as
> well as the GIC information for which it was originally
> created. Rename it to avoid a misleading name.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> arch/arm64/kernel/smp.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index cb87234..8ea244c 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -517,13 +517,14 @@ static unsigned int cpu_count = 1;
>
> #ifdef CONFIG_ACPI
> /*
> - * acpi_map_gic_cpu_interface - parse processor MADT entry
> + * acpi_verify_and_map_madt - parse processor MADT entry
> *
> * Carry out sanity checks on MADT processor entry and initialize
> - * cpu_logical_map on success
> + * cpu_logical_map, the ACPI parking protocol, NUMA mapping
> + * and the PMU interrupts on success
> */
> static void __init
> -acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
> +acpi_verify_and_map_madt(struct acpi_madt_generic_interrupt *processor)
Nit, MADT is a table includes multi type of table entries, we just
need to map the the processor type, how about updating it to
acpi_verify_and_map_madt_processor()?
Thanks
Hanjun
^ permalink raw reply
* [PATCH v13 0/7] Enable PMUs in ACPI systems
From: Hanjun Guo @ 2017-01-19 3:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484686210-7211-1-git-send-email-jeremy.linton@arm.com>
On 2017/1/18 4:50, Jeremy Linton wrote:
> This patch expands and reworks the patches published by Mark Salter
> in order to clean up a few of the previous review comments, as well as
> add support for newer CPUs and big/little configurations.
>
> v13:
> - Correct int/bool conversion bug in pmu_acpi_init()
I tested this patch set on Hisilicon D03 and using "perf list"
then I can get hardware event which it's not available before
adding this patch set, and "perf stat -e <event>" works fine
with available perf event.
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Thanks
Hanjun
^ permalink raw reply
* [PATCH net-next] macb: Common code to enable ptp support for SAMA5Dx platforms.
From: Harini Katakam @ 2017-01-19 4:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1c534b5a-25cb-a5d6-f87c-db9ed958a606@atmel.com>
On Wed, Jan 18, 2017 at 11:02 PM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> Le 18/01/2017 ? 09:57, Andrei Pistirica a ?crit :
>> This patch does the following:
>> - add GEM-PTP interface
>> - registers and bitfields for TSU are named according to SAMA5Dx data sheet
>> - PTP support based on platform capability
>
> The $subject will certainly never match reality, sadly "enable ptp
> support for SAMA5Dx platforms". So, you'd better change it.
> (no "." at the end BTW).
>
>> Signed-off-by: Andrei Pistirica <andrei.pistirica@microchip.com>
>> ---
>> This is just the common code for GEM-PTP support. Code is based on the comments
>> related to the following patch series:
>> - [RFC PATCH net-next v1-to-4 1/2] macb: Add 1588 support in Cadence GEM.
>> - [RFC PATCH net-next v1-to-4 2/2] macb: Enable 1588 support in SAMA5Dx platforms.
>>
>> Note: Patch on net-next: January 18.
>>
>> Rafal/Harini, you can continue the work for GME-GXL.
Thanks Andrei.
<snip>
>
> Otherwise, I'm okay with the rest.
>
> I suggest to people that will keep the ball rolling on this topic to
> take advantage of the chunks of code that Andrei developed with the help
> of Richard and the best practices discussed. I think particularly, if it
> makes sense with HW, about:
> - gem_ptp_do_[rt]xstamp(bp, skb) dereference scheme
> - gem_ptp_adjfine() rationale
> - gem_get_ptp_peer() if needed
>
Sure, will patch on top of this.
Regards,
Harini
> Regards,
> --
> Nicolas Ferre
^ permalink raw reply
* [PATCH v5] ARM64: dts: meson-gx: Add firmware reserved memory zones
From: Kevin Hilman @ 2017-01-19 4:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <eca803d3-1a67-cda5-554d-4313ae56635e@suse.de>
Andreas F?rber <afaerber@suse.de> writes:
> Am 19.01.2017 um 01:20 schrieb Andreas F?rber:
>> Hi,
>>
>> Am 18.01.2017 um 17:50 schrieb Neil Armstrong:
>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>> this patch adds these reserved zones.
>>>
>>> Without such reserved memory zones, running the following stress command :
>>> $ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
>>> multiple times:
>>>
>>> Could lead to the following kernel crashes :
>>> [ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
>>> ...
>>> [ 47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
>>> ...
>>> Instead of the OOM killer.
>>>
>>
>> I miss a Fixes: or Cc: here for the backport you desired. To have it
>> fixed back to my very introduction:
>>
>> Fixes: 4f24eda8401f ("ARM64: dts: Prepare configs for Amlogic Meson GXBaby")
>>
>> People backporting it would need to handle the meson-{gx => gxbb}.dtsi
>> transition for 4.9 down to 4.6, which seems fairly straightforward.
>>
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>> ---
>>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 18 ++++++++++++++++++
>>> 1 file changed, 18 insertions(+)
>>>
>>> Changes since v4 at [5]:
>>> - Move start of ddr memory to reserved-memory node
>>> - Drop memory node move
>>> - Fix typo in sizes
>>>
>>> Changes since resent v2 at [4]:
>>> - Fix invalid comment of useable memory attributes
>>>
>>> Changes since original v2 at [3]:
>>> - Typo in commit 2GiB -> 1GiB, 4GiB -> 2GiB
>>>
>>> Changes since v2 at [2]:
>>> - Moved all memory node out of dtsi
>>> - Added comment about useable memory
>>> - Fixed comment about secmon reserved zone
>>>
>>> Changes since v1 at [1] :
>>> - Renamed reg into linux,usable-memory to ovveride u-boot memory
>>> - only kept secmon memory zone
>>>
>>> [1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong at baylibre.com
>>> [2] http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstrong at baylibre.com
>>> [3] http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstrong at baylibre.com
>>> [4] http://lkml.kernel.org/r/1484128540-22662-1-git-send-email-narmstrong at baylibre.com
>>> [5] http://lkml.kernel.org/r/1484129414-23325-1-git-send-email-narmstrong at baylibre.com
>>>
>>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> index eada0b5..63d52b7 100644
>>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> @@ -55,6 +55,24 @@
>>> #address-cells = <2>;
>>> #size-cells = <2>;
>>>
>>> + reserved-memory {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + ranges;
>>> +
>>> + /* 16 MiB reserved for Hardware ROM Firmware */
>>> + hwrom: hwrom {
>>
>> Both sub-nodes get a label that is unused, but reserved-memory itself
>> does not (my v4 remark). Intentional?
>>
>>> + reg = <0x0 0x0 0x0 0x1000000>;
>>> + no-map;
>>> + };
>>> +
>>> + /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
>>> + secmon: secmon {
>>
>> I note that this .dtsi further down has a node /firmware/secure-monitor
>> with label sm.
>> a) Is there any naming convention such as secmon_mem to adopt here to
>> avoid mixups with sm?
>> b) Should this secmon node be referenced in the secure-monitor node via
>> memory-node = <&secmon>; to model their connection, thereby giving the
>> label a use? Or should we maybe merge the two nodes by moving the
>> compatible string here?
>>
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>
> Answering my own question: the example labels use _reserved suffix.
>
>>> + reg = <0x0 0x10000000 0x0 0x200000>;
>
> And since we use a reg property here, the node name should get a unit
> address to avoid future dtc warnings/errors. Ditto for hwrom.
OK, I added Fixes:, your Reviewed-by, added the _reserved suffix and
unit address and applied to v4.10/fixes.
Update patch below for reference.
Other cleanups/fixups (like adding a phandle from secure monitor) can be
done as add-ons, as they are not strictly related to this fix.
Kevin
>From ecb88f3001ed9ee8c53450d971de8c18bcbf7925 Mon Sep 17 00:00:00 2001
From: Neil Armstrong <narmstrong@baylibre.com>
Date: Wed, 18 Jan 2017 17:50:45 +0100
Subject: [PATCH] ARM64: dts: meson-gx: Add firmware reserved memory zones
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds these reserved zones.
Without such reserved memory zones, running the following stress command :
$ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
multiple times:
Could lead to the following kernel crashes :
[ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
...
[ 47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
...
Instead of the OOM killer.
Fixes: 4f24eda8401f ("ARM64: dts: Prepare configs for Amlogic Meson GXBaby")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Andreas F?rber <afaerber@suse.de>
[khilman: added Fixes tag, added _reserved and unit addresses]
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index eada0b58ba1c..0cbe24b49710 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -55,6 +55,24 @@
#address-cells = <2>;
#size-cells = <2>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 16 MiB reserved for Hardware ROM Firmware */
+ hwrom_reserved: hwrom at 0 {
+ reg = <0x0 0x0 0x0 0x1000000>;
+ no-map;
+ };
+
+ /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
+ secmon_reserved: secmon at 10000000 {
+ reg = <0x0 0x10000000 0x0 0x200000>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <0x2>;
#size-cells = <0x0>;
--
2.9.3
^ permalink raw reply related
* [PATCH v4 1/2] power: reset: add linkstation-reset driver
From: Sebastian Reichel @ 2017-01-19 4:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAEQ9gEkoKc0Yv+kLYGWgHZZW92u0tW8E9U0eT7ZhAx79yKxzLQ@mail.gmail.com>
Hi Roger,
On Wed, Jan 18, 2017 at 09:08:13PM +0900, Roger Shimizu wrote:
> On Sun, Jan 8, 2017 at 12:04 AM, Roger Shimizu <rogershimizu@gmail.com> wrote:
> > Buffalo Linkstation / KuroBox and their variants need magic command
> > sending to UART1 to power-off.
> >
> > Power driver linkstation-reset implements the magic command and I/O
> > routine, which come from files listed below:
> > - arch/arm/mach-orion5x/kurobox_pro-setup.c
> > - arch/arm/mach-orion5x/terastation_pro2-setup.c
>
> I think there's not much concern regarding to this series.
> Could you kindly help to apply this patch?
Well you dropped the DT binding, but still introduce new DT
properties. Since they are not documented without the binding
I won't merge this. DT binding documentation is not optional.
In other words: NAK on the binding effectively means NAK on
the driver in its current state.
If you want to see this merged rebase it to Rob's generic
serial bindings [0] and help to support him getting everything
into mainline ASAP. Currently the feedback seems to be quite
positive, so I hope to see it merged for 4.11.
[0] https://lwn.net/Articles/711794/ (current proposal from 2 days ago)
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170119/ef6a2441/attachment.sig>
^ permalink raw reply
* [PATCH v11 12/12] drm/mediatek: add support for Mediatek SoC MT2701
From: CK Hu @ 2017-01-19 5:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484117473-46644-13-git-send-email-yt.shen@mediatek.com>
Hi, YT:
On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701.
>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 8 ++++++++
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++++++
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 17 +++++++++++++++++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 7 +++++++
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 29 +++++++++++++++++++++++++++++
> drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 6 ++++++
> 7 files changed, 74 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 4552178..a14d7d6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -35,6 +35,7 @@
> #define DISP_REG_OVL_PITCH(n) (0x0044 + 0x20 * (n))
> #define DISP_REG_OVL_RDMA_CTRL(n) (0x00c0 + 0x20 * (n))
> #define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
> +#define DISP_REG_OVL_ADDR_MT2701 0x0040
> #define DISP_REG_OVL_ADDR_MT8173 0x0f40
> #define DISP_REG_OVL_ADDR(ovl, n) ((ovl)->data->addr + 0x20 * (n))
>
> @@ -303,12 +304,19 @@ static int mtk_disp_ovl_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT2701,
> + .fmt_rgb565_is_0 = false,
> +};
> +
> static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
> .addr = DISP_REG_OVL_ADDR_MT8173,
> .fmt_rgb565_is_0 = true,
> };
>
> static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-ovl",
> + .data = &mt2701_ovl_driver_data},
> { .compatible = "mediatek,mt8173-disp-ovl",
> .data = &mt8173_ovl_driver_data},
> {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index e5e5318..b68a513 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -236,11 +236,17 @@ static int mtk_disp_rdma_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct mtk_disp_rdma_data mt2701_rdma_driver_data = {
> + .fifo_size = SZ_4K,
> +};
> +
> static const struct mtk_disp_rdma_data mt8173_rdma_driver_data = {
> .fifo_size = SZ_8K,
> };
>
> static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-rdma",
> + .data = &mt2701_rdma_driver_data},
> { .compatible = "mediatek,mt8173-disp-rdma",
> .data = &mt8173_rdma_driver_data},
> {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index a9b209c..8130f3d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -60,6 +60,13 @@
> #define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
> #define MT8173_MUTEX_MOD_DISP_OD BIT(25)
>
> +#define MT2701_MUTEX_MOD_DISP_OVL BIT(3)
> +#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
> +#define MT2701_MUTEX_MOD_DISP_COLOR BIT(7)
> +#define MT2701_MUTEX_MOD_DISP_BLS BIT(9)
> +#define MT2701_MUTEX_MOD_DISP_RDMA0 BIT(10)
> +#define MT2701_MUTEX_MOD_DISP_RDMA1 BIT(12)
> +
> #define MUTEX_SOF_SINGLE_MODE 0
> #define MUTEX_SOF_DSI0 1
> #define MUTEX_SOF_DSI1 2
> @@ -92,6 +99,15 @@ struct mtk_ddp {
> const unsigned int *mutex_mod;
> };
>
> +static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
> + [DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
> + [DDP_COMPONENT_OVL0] = MT2701_MUTEX_MOD_DISP_OVL,
> + [DDP_COMPONENT_RDMA0] = MT2701_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT2701_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
> +};
> +
> static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
> [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> @@ -390,6 +406,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
> }
>
> static const struct of_device_id ddp_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
> { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
> {},
> };
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index f6e853a..8b52416 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -39,6 +39,7 @@
> #define DISP_REG_UFO_START 0x0000
>
> #define DISP_COLOR_CFG_MAIN 0x0400
> +#define DISP_COLOR_START_MT2701 0x0f00
> #define DISP_COLOR_START_MT8173 0x0c00
> #define DISP_COLOR_START(comp) ((comp)->data->color_offset)
> #define DISP_COLOR_WIDTH(comp) (DISP_COLOR_START(comp) + 0x50)
> @@ -285,11 +286,17 @@ struct mtk_ddp_comp_match {
> [DDP_COMPONENT_WDMA1] = { MTK_DISP_WDMA, 1, NULL },
> };
>
> +static const struct mtk_disp_color_data mt2701_color_driver_data = {
> + .color_offset = DISP_COLOR_START_MT2701,
> +};
> +
> static const struct mtk_disp_color_data mt8173_color_driver_data = {
> .color_offset = DISP_COLOR_START_MT8173,
> };
>
> static const struct of_device_id mtk_disp_color_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-color",
> + .data = &mt2701_color_driver_data},
> { .compatible = "mediatek,mt8173-disp-color",
> .data = &mt8173_color_driver_data},
> {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 074fe31..7daabae 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -128,6 +128,19 @@ static int mtk_atomic_commit(struct drm_device *drm,
> .atomic_commit = mtk_atomic_commit,
> };
>
> +static const enum mtk_ddp_comp_id mt2701_mtk_ddp_main[] = {
> + DDP_COMPONENT_OVL0,
> + DDP_COMPONENT_RDMA0,
> + DDP_COMPONENT_COLOR0,
> + DDP_COMPONENT_BLS,
> + DDP_COMPONENT_DSI0,
> +};
> +
> +static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
> + DDP_COMPONENT_RDMA1,
> + DDP_COMPONENT_DPI0,
> +};
> +
> static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_COLOR0,
> @@ -147,6 +160,14 @@ static int mtk_atomic_commit(struct drm_device *drm,
> DDP_COMPONENT_DPI0,
> };
>
> +static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
> + .main_path = mt2701_mtk_ddp_main,
> + .main_len = ARRAY_SIZE(mt2701_mtk_ddp_main),
> + .ext_path = mt2701_mtk_ddp_ext,
> + .ext_len = ARRAY_SIZE(mt2701_mtk_ddp_ext),
> + .shadow_register = true,
> +};
> +
> static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
> .main_path = mt8173_mtk_ddp_main,
> .main_len = ARRAY_SIZE(mt8173_mtk_ddp_main),
> @@ -340,16 +361,22 @@ static void mtk_drm_unbind(struct device *dev)
> };
>
> static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> + { .compatible = "mediatek,mt2701-disp-ovl", .data = (void *)MTK_DISP_OVL },
> { .compatible = "mediatek,mt8173-disp-ovl", .data = (void *)MTK_DISP_OVL },
> + { .compatible = "mediatek,mt2701-disp-rdma", .data = (void *)MTK_DISP_RDMA },
> { .compatible = "mediatek,mt8173-disp-rdma", .data = (void *)MTK_DISP_RDMA },
> { .compatible = "mediatek,mt8173-disp-wdma", .data = (void *)MTK_DISP_WDMA },
> + { .compatible = "mediatek,mt2701-disp-color", .data = (void *)MTK_DISP_COLOR },
> { .compatible = "mediatek,mt8173-disp-color", .data = (void *)MTK_DISP_COLOR },
> { .compatible = "mediatek,mt8173-disp-aal", .data = (void *)MTK_DISP_AAL},
> { .compatible = "mediatek,mt8173-disp-gamma", .data = (void *)MTK_DISP_GAMMA, },
> { .compatible = "mediatek,mt8173-disp-ufoe", .data = (void *)MTK_DISP_UFOE },
> + { .compatible = "mediatek,mt2701-dsi", .data = (void *)MTK_DSI },
> { .compatible = "mediatek,mt8173-dsi", .data = (void *)MTK_DSI },
> { .compatible = "mediatek,mt8173-dpi", .data = (void *)MTK_DPI },
> + { .compatible = "mediatek,mt2701-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
> { .compatible = "mediatek,mt8173-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
> + { .compatible = "mediatek,mt2701-disp-pwm", .data = (void *)MTK_DISP_BLS },
> { .compatible = "mediatek,mt8173-disp-pwm", .data = (void *)MTK_DISP_PWM },
> { .compatible = "mediatek,mt8173-disp-od", .data = (void *)MTK_DISP_OD },
> { }
> @@ -523,6 +550,8 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
> mtk_drm_sys_resume);
>
> static const struct of_device_id mtk_drm_of_ids[] = {
> + { .compatible = "mediatek,mt2701-mmsys",
> + .data = &mt2701_mmsys_driver_data},
> { .compatible = "mediatek,mt8173-mmsys",
> .data = &mt8173_mmsys_driver_data},
> { }
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 21392c4..e1832ea 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1228,6 +1228,7 @@ static int mtk_dsi_remove(struct platform_device *pdev)
> }
>
> static const struct of_device_id mtk_dsi_of_match[] = {
> + { .compatible = "mediatek,mt2701-dsi" },
> { .compatible = "mediatek,mt8173-dsi" },
> { },
> };
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index fd84914..90e9131 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -465,11 +465,17 @@ static int mtk_mipi_tx_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct mtk_mipitx_data mt2701_mipitx_data = {
> + .mppll_preserve = (3 << 8)
> +};
> +
> static const struct mtk_mipitx_data mt8173_mipitx_data = {
> .mppll_preserve = (0 << 8)
> };
>
> static const struct of_device_id mtk_mipi_tx_match[] = {
> + { .compatible = "mediatek,mt2701-mipi-tx",
> + .data = &mt2701_mipitx_data },
> { .compatible = "mediatek,mt8173-mipi-tx",
> .data = &mt8173_mipitx_data },
> {},
^ permalink raw reply
* [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs
From: Peter Chen @ 2017-01-19 6:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJw-nQj0LtLA_o_Upos_7Kg3bPDoCDghPyOEien_QCLSA@mail.gmail.com>
On Wed, Jan 18, 2017 at 02:57:27PM -0600, Rob Herring wrote:
> On Wed, Jan 18, 2017 at 2:54 PM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> > Quoting Peter Chen (2017-01-17 23:34:32)
> >> On Tue, Jan 17, 2017 at 09:58:33AM -0800, Stephen Boyd wrote:
> >> > Quoting Peter Chen (2017-01-15 19:45:51)
> >> > >
> >> > > At include/linux/usb/phy.h, we have .set_vbus interface, maybe you need
> >> > > to port it to generic phy framework.
> >> > >
> >> >
> >> > Ok. I'll look into that. Can the other patches in this series be picked
> >> > up? Otherwise I can resend them all again once I fix the phy_set_mode()
> >> > call location and introduce a new phy op.
> >>
> >> I can pick up chipidea patches after you test the patch I supplied at:
> >>
> >> [PATCH v6 11/25] usb: chipidea: vbus event may exist before starting
> >> gadget
> >
> > Ok. I've confirmed that this updated patch works fine for me. You can
> > have my Tested-by and Reviewed-by there.
> >
> >>
> >> You may ping other maintainers to pick up other patches.
> >>
> >
> > I was hoping you could pick the beginning of the series up until the PHY
> > drivers, which can go via Kishon's tree. That would mean applying the
> > drivers/of/ part. Rob is that ok?
>
> Peter, If there's a dependency then please take the patches I've
> acked. That's why I acked them.
>
Ok, I will do it.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH v6 03/25] usb: ulpi: Support device discovery via DT
From: Peter Chen @ 2017-01-19 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161228225711.698-4-stephen.boyd@linaro.org>
On Wed, Dec 28, 2016 at 02:56:49PM -0800, Stephen Boyd wrote:
> The qcom HSIC ULPI phy doesn't have any bits set in the vendor or
> product ID registers. This makes it impossible to make a ULPI
> driver match against the ID registers. Add support to discover
> the ULPI phys via DT help alleviate this problem. In the DT case,
> we'll look for a ULPI bus node underneath the device registering
> the ULPI viewport (or the parent of that device to support
> chipidea's device layout) and then match up the phy node
> underneath that with the ULPI device that's created.
>
> The side benefit of this is that we can use standard properties
> in the phy node like clks, regulators, gpios, etc. because we
> don't have firmware like ACPI to turn these things on for us. And
> we can use the DT phy binding to point our phy consumer to the
> phy provider.
>
> The ULPI bus code supports native enumeration by reading the
> vendor ID and product ID registers at device creation time, but
> we can't be certain that those register reads will succeed if the
> phy is not powered up. To avoid any problems with reading the ID
> registers before the phy is powered we fallback to DT matching
> when the ID reads fail.
>
> If the ULPI spec had some generic power sequencing for these
> registers we could put that into the ULPI bus layer and power up
> the device before reading the ID registers. Unfortunately this
> doesn't exist and the power sequence is usually device specific.
> By having the device matched up with DT we can avoid this
> problem.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> Cc: <devicetree@vger.kernel.org>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Greg, is it ok I pick up this patch, and send it with chipidea
changes together for 4.11-rc1 later?
Peter
> ---
> Documentation/devicetree/bindings/usb/ulpi.txt | 20 +++++++
> drivers/usb/common/ulpi.c | 79 ++++++++++++++++++++++++--
> 2 files changed, 93 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/ulpi.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/ulpi.txt b/Documentation/devicetree/bindings/usb/ulpi.txt
> new file mode 100644
> index 000000000000..ca179dc4bd50
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/ulpi.txt
> @@ -0,0 +1,20 @@
> +ULPI bus binding
> +----------------
> +
> +Phys that are behind a ULPI connection can be described with the following
> +binding. The host controller shall have a "ulpi" named node as a child, and
> +that node shall have one enabled node underneath it representing the ulpi
> +device on the bus.
> +
> +EXAMPLE
> +-------
> +
> +usb {
> + compatible = "vendor,usb-controller";
> +
> + ulpi {
> + phy {
> + compatible = "vendor,phy";
> + };
> + };
> +};
> diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> index 8b317702d761..c9480d77810c 100644
> --- a/drivers/usb/common/ulpi.c
> +++ b/drivers/usb/common/ulpi.c
> @@ -16,6 +16,9 @@
> #include <linux/module.h>
> #include <linux/slab.h>
> #include <linux/acpi.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/clk/clk-conf.h>
>
> /* -------------------------------------------------------------------------- */
>
> @@ -39,6 +42,10 @@ static int ulpi_match(struct device *dev, struct device_driver *driver)
> struct ulpi *ulpi = to_ulpi_dev(dev);
> const struct ulpi_device_id *id;
>
> + /* Some ULPI devices don't have a vendor id so rely on OF match */
> + if (ulpi->id.vendor == 0)
> + return of_driver_match_device(dev, driver);
> +
> for (id = drv->id_table; id->vendor; id++)
> if (id->vendor == ulpi->id.vendor &&
> id->product == ulpi->id.product)
> @@ -50,6 +57,11 @@ static int ulpi_match(struct device *dev, struct device_driver *driver)
> static int ulpi_uevent(struct device *dev, struct kobj_uevent_env *env)
> {
> struct ulpi *ulpi = to_ulpi_dev(dev);
> + int ret;
> +
> + ret = of_device_uevent_modalias(dev, env);
> + if (ret != -ENODEV)
> + return ret;
>
> if (add_uevent_var(env, "MODALIAS=ulpi:v%04xp%04x",
> ulpi->id.vendor, ulpi->id.product))
> @@ -60,6 +72,11 @@ static int ulpi_uevent(struct device *dev, struct kobj_uevent_env *env)
> static int ulpi_probe(struct device *dev)
> {
> struct ulpi_driver *drv = to_ulpi_driver(dev->driver);
> + int ret;
> +
> + ret = of_clk_set_defaults(dev->of_node, false);
> + if (ret < 0)
> + return ret;
>
> return drv->probe(to_ulpi_dev(dev));
> }
> @@ -87,8 +104,13 @@ static struct bus_type ulpi_bus = {
> static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
> char *buf)
> {
> + int len;
> struct ulpi *ulpi = to_ulpi_dev(dev);
>
> + len = of_device_get_modalias(dev, buf, PAGE_SIZE - 1);
> + if (len != -ENODEV)
> + return len;
> +
> return sprintf(buf, "ulpi:v%04xp%04x\n",
> ulpi->id.vendor, ulpi->id.product);
> }
> @@ -153,23 +175,45 @@ EXPORT_SYMBOL_GPL(ulpi_unregister_driver);
>
> /* -------------------------------------------------------------------------- */
>
> -static int ulpi_register(struct device *dev, struct ulpi *ulpi)
> +static int ulpi_of_register(struct ulpi *ulpi)
> {
> - int ret;
> + struct device_node *np = NULL, *child;
> + struct device *parent;
> +
> + /* Find a ulpi bus underneath the parent or the grandparent */
> + parent = ulpi->dev.parent;
> + if (parent->of_node)
> + np = of_find_node_by_name(parent->of_node, "ulpi");
> + else if (parent->parent && parent->parent->of_node)
> + np = of_find_node_by_name(parent->parent->of_node, "ulpi");
> + if (!np)
> + return 0;
> +
> + child = of_get_next_available_child(np, NULL);
> + of_node_put(np);
> + if (!child)
> + return -EINVAL;
>
> - ulpi->dev.parent = dev; /* needed early for ops */
> + ulpi->dev.of_node = child;
> +
> + return 0;
> +}
> +
> +static int ulpi_read_id(struct ulpi *ulpi)
> +{
> + int ret;
>
> /* Test the interface */
> ret = ulpi_write(ulpi, ULPI_SCRATCH, 0xaa);
> if (ret < 0)
> - return ret;
> + goto err;
>
> ret = ulpi_read(ulpi, ULPI_SCRATCH);
> if (ret < 0)
> return ret;
>
> if (ret != 0xaa)
> - return -ENODEV;
> + goto err;
>
> ulpi->id.vendor = ulpi_read(ulpi, ULPI_VENDOR_ID_LOW);
> ulpi->id.vendor |= ulpi_read(ulpi, ULPI_VENDOR_ID_HIGH) << 8;
> @@ -177,13 +221,35 @@ static int ulpi_register(struct device *dev, struct ulpi *ulpi)
> ulpi->id.product = ulpi_read(ulpi, ULPI_PRODUCT_ID_LOW);
> ulpi->id.product |= ulpi_read(ulpi, ULPI_PRODUCT_ID_HIGH) << 8;
>
> + /* Some ULPI devices don't have a vendor id so rely on OF match */
> + if (ulpi->id.vendor == 0)
> + goto err;
> +
> + request_module("ulpi:v%04xp%04x", ulpi->id.vendor, ulpi->id.product);
> + return 0;
> +err:
> + of_device_request_module(&ulpi->dev);
> + return 0;
> +}
> +
> +static int ulpi_register(struct device *dev, struct ulpi *ulpi)
> +{
> + int ret;
> +
> + ulpi->dev.parent = dev; /* needed early for ops */
> ulpi->dev.bus = &ulpi_bus;
> ulpi->dev.type = &ulpi_dev_type;
> dev_set_name(&ulpi->dev, "%s.ulpi", dev_name(dev));
>
> ACPI_COMPANION_SET(&ulpi->dev, ACPI_COMPANION(dev));
>
> - request_module("ulpi:v%04xp%04x", ulpi->id.vendor, ulpi->id.product);
> + ret = ulpi_of_register(ulpi);
> + if (ret)
> + return ret;
> +
> + ret = ulpi_read_id(ulpi);
> + if (ret)
> + return ret;
>
> ret = device_register(&ulpi->dev);
> if (ret)
> @@ -234,6 +300,7 @@ EXPORT_SYMBOL_GPL(ulpi_register_interface);
> */
> void ulpi_unregister_interface(struct ulpi *ulpi)
> {
> + of_node_put(ulpi->dev.of_node);
> device_unregister(&ulpi->dev);
> }
> EXPORT_SYMBOL_GPL(ulpi_unregister_interface);
> --
> 2.10.0.297.gf6727b0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH v7 2/3] input: tm2-touchkey: Add touchkey driver support for TM2
From: Krzysztof Kozlowski @ 2017-01-19 7:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118224711.GB11881@dtor-ws>
On Thu, Jan 19, 2017 at 12:47 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, Jan 17, 2017 at 08:10:56PM +0200, Krzysztof Kozlowski wrote:
>> On Tue, Jan 17, 2017 at 10:06:27AM -0800, Dmitry Torokhov wrote:
>> > On Tue, Jan 17, 2017 at 9:20 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> > > On Tue, Jan 17, 2017 at 02:54:38PM +0900, Jaechul Lee wrote:
>> > >> This patch adds support for the TM2 touch key and led
>> > >> functionality.
>> > >>
>> > >> The driver interfaces with userspace through an input device and
>> > >> reports KEY_PHONE and KEY_BACK event types. LED brightness can be
>> > >> controlled by "/sys/class/leds/tm2-touchkey/brightness".
>> > >>
>> > >> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
>> > >> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
>> > >> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> > >> Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
>> > >> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>> > >> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>> > >> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
>> > >> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>> > >
>> > > This looks unusual. How did Dmitry's Sob end here?
>> >
>> > I sent Jaechul a version of the patch to try out.
>>
>> Ah, makes sense then.
>
> I picked up (and folded) the binding doc and driver patches, DTS should
> go through some other tree I believe.
Yes, I will take it. I waited for driver and bindings to be accepted.
Thanks,
Krzysztof
^ permalink raw reply
* [PATCH v6 03/25] usb: ulpi: Support device discovery via DT
From: Greg Kroah-Hartman @ 2017-01-19 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170119063349.GB10621@b29397-desktop>
On Thu, Jan 19, 2017 at 02:33:49PM +0800, Peter Chen wrote:
> On Wed, Dec 28, 2016 at 02:56:49PM -0800, Stephen Boyd wrote:
> > The qcom HSIC ULPI phy doesn't have any bits set in the vendor or
> > product ID registers. This makes it impossible to make a ULPI
> > driver match against the ID registers. Add support to discover
> > the ULPI phys via DT help alleviate this problem. In the DT case,
> > we'll look for a ULPI bus node underneath the device registering
> > the ULPI viewport (or the parent of that device to support
> > chipidea's device layout) and then match up the phy node
> > underneath that with the ULPI device that's created.
> >
> > The side benefit of this is that we can use standard properties
> > in the phy node like clks, regulators, gpios, etc. because we
> > don't have firmware like ACPI to turn these things on for us. And
> > we can use the DT phy binding to point our phy consumer to the
> > phy provider.
> >
> > The ULPI bus code supports native enumeration by reading the
> > vendor ID and product ID registers at device creation time, but
> > we can't be certain that those register reads will succeed if the
> > phy is not powered up. To avoid any problems with reading the ID
> > registers before the phy is powered we fallback to DT matching
> > when the ID reads fail.
> >
> > If the ULPI spec had some generic power sequencing for these
> > registers we could put that into the ULPI bus layer and power up
> > the device before reading the ID registers. Unfortunately this
> > doesn't exist and the power sequence is usually device specific.
> > By having the device matched up with DT we can avoid this
> > problem.
> >
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > Cc: <devicetree@vger.kernel.org>
> > Acked-by: Rob Herring <robh@kernel.org>
> > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
>
> Greg, is it ok I pick up this patch, and send it with chipidea
> changes together for 4.11-rc1 later?
No objection from me.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-19 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118222010.ivc6jxpnrumemvdf@rob-hp-laptop>
On Wed, 18 Jan 2017 16:20:10 -0600
Rob Herring <robh@kernel.org> wrote:
> On Tue, Jan 17, 2017 at 02:36:50PM +1100, Thomas Petazzoni wrote:
> > Hello,
> >
> > (Side note: you guys should learn about stripping irrelevant parts of
> > an e-mail when replying!)
> >
> > On Mon, 16 Jan 2017 09:40:32 +0100, Boris Brezillon wrote:
> >
> > > > Well this is OK I guess, but then you can also use "mediatek,mt8173-nor"
> > > > as the oldest supported compatible and be done with it, no ? It looks a
> > > > bit crappy though, I admit that ...
> > >
> > > Let's stop bikeshedding and wait for DT maintainers feedback
> > > before taking a decision ;-).
> > >
> > > Rob, Mark, any opinion?
> >
>
> Sigh, is how to do compatibles really not yet understood?
Apparently not, and I fear this is not the last misunderstanding on my
side ;-).
>
> > I agree that a clarification would be good. There are really two
> > options:
> >
> > 1. Have two compatible strings in the DT, the one that matches the
> > exact SoC where the IP is found (first compatible string) and the
> > one that matches some other SoC where the same IP is found (second
> > compatible string). Originally, Linux only supports the second
> > compatible string in its device driver, but if it happens that a
> > difference is found between two IPs that we thought were the same,
> > we can add support for the first compatible string in the driver,
> > with a slightly different behavior.
>
> This. And no wildcards in the compatible string.
>
> > 2. Have a single compatible string in the DT, matching the exact SoC
> > where the IP is found. This involves adding immediately this
> > compatible string in the corresponding driver.
>
> I wouldn't object to this from a DT perspective as I have no clue
> generally if IP blocks are "the same" or not. Subsystem maintainers will
> object though.
>
> > I've not really been able to figure out which of the two options is the
> > most future-proof/appropriate.
>
> They are both future-proof. #2 has the disadvantage of requiring a
> kernel update for a new SoC.
>
> Rob
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox