* Re: [PATCH v4 1/2] mailbox: Add driver for Broadcom FlexRM ring manager
From: Anup Patel @ 2017-01-19 3:15 UTC (permalink / raw)
To: Jassi Brar, Rob Herring
Cc: Mark Rutland, Device Tree, Anup Patel, Scott Branden, Ray Jui,
Linux Kernel, Pramod KUMAR, BCM Kernel Feedback, Rob Rice,
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
* Re: [PATCH v3 2/3] Documentation: devicetree: Add document bindings for mtk-cir
From: Sean Wang @ 2017-01-19 3:00 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree@vger.kernel.org, Ivaylo Dimitrov,
sean wang, Sean Young, Mauro Carvalho Chehab,
linux-kernel@vger.kernel.org, Andi Shyti, Hans Verkuil,
Hans de Goede, linux-mediatek, Matthias Brugger,
linux-media@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Heiner Kallweit
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@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@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
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Rob Herring @ 2017-01-19 2:51 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Boris Brezillon, Marek Vasut, Mark Rutland,
devicetree@vger.kernel.org, Guochun Mao, Richard Weinberger,
Russell King, linux-kernel@vger.kernel.org,
linux-mtd@lists.infradead.org, Matthias Brugger, linux-mediatek,
Cyrille Pitchen, Brian Norris, David Woodhouse,
linux-arm-kernel@lists.infradead.org
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
* [PATCH 2/2] ARM: dts: rockchip: add dts for RK3288-Tinker board
From: Eddie Cai @ 2017-01-19 2:11 UTC (permalink / raw)
To: robh+dt, mark.rutland, heiko, linux
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Eddie Cai
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@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@1;
+ };
+ };
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <400000>;
+
+ rk808: pmic@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@0;
+ };
+};
+
+&vopl_mmu {
+ status = "okay";
+};
+
+&wdt {
+ status = "okay";
+};
+
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: add Asus Tinker board
From: Eddie Cai @ 2017-01-19 2:11 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
heiko-4mtYJXux2i+zQB+pC5nmwQ, linux-I+IVW8TIWO2tmTQ+vhA3Yw
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Eddie Cai,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484791919-4665-1-git-send-email-eddie.cai-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Tinker board is a credit card size develop board designed by Asus.
Powered by RK3288.
Signed-off-by: Eddie Cai <eddie.cai-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
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 0/2] Add support for RK3288 Tinker board
From: Eddie Cai @ 2017-01-19 2:11 UTC (permalink / raw)
To: robh+dt, mark.rutland, heiko, linux
Cc: devicetree, Eddie Cai, linux-kernel, linux-arm-kernel,
linux-rockchip
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
* Re: [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: Rob Herring, christopher.lee.bostic
Cc: mark.rutland, devicetree, benh, geert+renesas, andrew, gregkh,
mturquette, linux, Chris Bostic, linux-kernel, joel, alistair,
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 v2 3/3] watchdog: zx2967: add watchdog controller driver for ZTE's zx2967 family
From: Baoyou Xie @ 2017-01-19 1:59 UTC (permalink / raw)
To: jun.nie, wim, linux, robh+dt, mark.rutland
Cc: devicetree, linux-watchdog, xie.baoyou, linux-kernel,
chen.chaokai, wang.qiang01, baoyou.xie, shawnguo,
linux-arm-kernel
In-Reply-To: <1484791192-31674-1-git-send-email-baoyou.xie@linaro.org>
This patch adds watchdog controller driver for ZTE's zx2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/watchdog/Kconfig | 10 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/zx2967_wdt.c | 383 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 394 insertions(+)
create mode 100644 drivers/watchdog/zx2967_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index acb00b5..05093a2 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -714,6 +714,16 @@ config ASPEED_WATCHDOG
To compile this driver as a module, choose M here: the
module will be called aspeed_wdt.
+config ZX2967_WATCHDOG
+ tristate "ZTE zx2967 SoCs watchdog support"
+ depends on ARCH_ZX
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for the watchdog timer
+ in ZTE zx2967 SoCs.
+ To compile this driver as a module, choose M here: the
+ module will be called zx2967_wdt.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 0c3d35e..bf2d296 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
obj-$(CONFIG_ATLAS7_WATCHDOG) += atlas7_wdt.o
obj-$(CONFIG_RENESAS_WDT) += renesas_wdt.o
obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
+obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/zx2967_wdt.c b/drivers/watchdog/zx2967_wdt.c
new file mode 100644
index 0000000..35eaecd
--- /dev/null
+++ b/drivers/watchdog/zx2967_wdt.c
@@ -0,0 +1,383 @@
+/*
+ * watchdog driver for ZTE's zx2967 family
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/reboot.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <linux/watchdog.h>
+
+#define ZX2967_WDT_CFG_REG 0x4
+#define ZX2967_WDT_LOAD_REG 0x8
+#define ZX2967_WDT_REFRESH_REG 0x18
+#define ZX2967_WDT_START_REG 0x1c
+
+#define ZX2967_WDT_REFRESH_MASK 0x3f
+
+#define ZX2967_WDT_CFG_DIV(n) ((((n) & 0xff) - 1) << 8)
+#define ZX2967_WDT_START_EN 0x1
+
+#define ZX2967_WDT_WRITEKEY 0x12340000
+
+#define ZX2967_WDT_DIV_DEFAULT 16
+#define ZX2967_WDT_DEFAULT_TIMEOUT 32
+#define ZX2967_WDT_MIN_TIMEOUT 1
+#define ZX2967_WDT_MAX_TIMEOUT 500
+#define ZX2967_WDT_MAX_COUNT 0xffff
+
+#define ZX2967_WDT_FLAG_REBOOT_MON (1 << 0)
+
+#define ZX2967_RESET_MASK_REG 0xb0
+
+struct zx2967_wdt {
+ struct device *dev;
+ struct clk *clock;
+ void __iomem *reg_base;
+ unsigned int conf;
+ unsigned int load;
+ unsigned int flags;
+ struct watchdog_device wdt_device;
+ struct notifier_block restart_handler;
+ struct notifier_block reboot_handler;
+};
+
+#define zx2967_wdt_read_reg(r) readl_relaxed(r)
+
+static inline void
+zx2967_wdt_write_reg(u32 val, void __iomem *addr)
+{
+ writel_relaxed(val | ZX2967_WDT_WRITEKEY, addr);
+}
+
+static void zx2967_wdt_refresh(struct zx2967_wdt *wdt)
+{
+ u32 val;
+
+ val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_REFRESH_REG);
+ val ^= ZX2967_WDT_REFRESH_MASK;
+ zx2967_wdt_write_reg(val, wdt->reg_base + ZX2967_WDT_REFRESH_REG);
+}
+
+static unsigned int
+__zx2967_wdt_set_timeout(struct zx2967_wdt *wdt, unsigned int timeout)
+{
+ unsigned int freq = clk_get_rate(wdt->clock);
+ unsigned int divisor = ZX2967_WDT_DIV_DEFAULT;
+ unsigned int count;
+
+ count = timeout * freq;
+ if (count > divisor * ZX2967_WDT_MAX_COUNT)
+ divisor = DIV_ROUND_UP(count, ZX2967_WDT_MAX_COUNT);
+ count = DIV_ROUND_UP(count, divisor);
+ zx2967_wdt_write_reg(ZX2967_WDT_CFG_DIV(divisor),
+ wdt->reg_base + ZX2967_WDT_CFG_REG);
+ zx2967_wdt_write_reg(count, wdt->reg_base + ZX2967_WDT_LOAD_REG);
+ zx2967_wdt_refresh(wdt);
+ wdt->load = count;
+
+ return (count * divisor) / freq;
+}
+
+static int zx2967_wdt_set_timeout(struct watchdog_device *wdd,
+ unsigned int timeout)
+{
+ struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ if (watchdog_timeout_invalid(&wdt->wdt_device, timeout)) {
+ dev_err(wdt->dev, "timeout %d is invalid\n", timeout);
+ return -EINVAL;
+ }
+
+ wdd->timeout = __zx2967_wdt_set_timeout(wdt, timeout);
+
+ return 0;
+}
+
+static void __zx2967_wdt_start(struct zx2967_wdt *wdt)
+{
+ u32 val;
+
+ val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_START_REG);
+ val |= ZX2967_WDT_START_EN;
+ zx2967_wdt_write_reg(val, wdt->reg_base + ZX2967_WDT_START_REG);
+}
+
+static void __zx2967_wdt_stop(struct zx2967_wdt *wdt)
+{
+ u32 val;
+
+ val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_START_REG);
+ val &= ~ZX2967_WDT_START_EN;
+ zx2967_wdt_write_reg(val, wdt->reg_base + ZX2967_WDT_START_REG);
+}
+
+static int zx2967_wdt_start(struct watchdog_device *wdd)
+{
+ struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ __zx2967_wdt_stop(wdt);
+ zx2967_wdt_set_timeout(wdd, wdd->timeout);
+ __zx2967_wdt_start(wdt);
+
+ return 0;
+}
+
+static int zx2967_wdt_stop(struct watchdog_device *wdd)
+{
+ struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ __zx2967_wdt_stop(wdt);
+
+ return 0;
+}
+
+static int zx2967_wdt_keepalive(struct watchdog_device *wdd)
+{
+ struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ zx2967_wdt_refresh(wdt);
+
+ return 0;
+}
+
+#define ZX2967_WDT_OPTIONS \
+ (WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE)
+static const struct watchdog_info zx2967_wdt_ident = {
+ .options = ZX2967_WDT_OPTIONS,
+ .firmware_version = 0,
+ .identity = "zx2967 watchdog",
+};
+
+static struct watchdog_ops zx2967_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = zx2967_wdt_start,
+ .stop = zx2967_wdt_stop,
+ .ping = zx2967_wdt_keepalive,
+ .set_timeout = zx2967_wdt_set_timeout,
+};
+
+static void zx2967_wdt_fix_sysdown(struct zx2967_wdt *wdt)
+{
+ __zx2967_wdt_stop(wdt);
+ __zx2967_wdt_set_timeout(wdt, 15);
+ __zx2967_wdt_start(wdt);
+}
+
+static int zx2967_wdt_notify_sys(struct notifier_block *this,
+ unsigned long code, void *unused)
+{
+ struct zx2967_wdt *wdt = container_of(this, struct zx2967_wdt,
+ reboot_handler);
+
+ wdt->flags |= ZX2967_WDT_FLAG_REBOOT_MON;
+ switch (code) {
+ case SYS_HALT:
+ case SYS_POWER_OFF:
+ case SYS_RESTART:
+ zx2967_wdt_fix_sysdown(wdt);
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
+static int zx2967_wdt_restart(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+ struct zx2967_wdt *wdt;
+
+ wdt = container_of(this, struct zx2967_wdt, restart_handler);
+
+ zx2967_wdt_stop(&wdt->wdt_device);
+
+ zx2967_wdt_write_reg(0x80, wdt->reg_base + ZX2967_WDT_LOAD_REG);
+ zx2967_wdt_refresh(wdt);
+ zx2967_wdt_write_reg(ZX2967_WDT_START_EN,
+ wdt->reg_base + ZX2967_WDT_START_REG);
+
+ zx2967_wdt_start(&wdt->wdt_device);
+ /* wait for reset*/
+ mdelay(500);
+
+ return NOTIFY_DONE;
+}
+
+static void zx2967_wdt_reset_sysctrl(struct device *dev)
+{
+ int ret;
+ struct device_node *np = NULL;
+ void __iomem *regmap;
+ unsigned int val, mask, config;
+ struct of_phandle_args out_args;
+
+ ret = of_parse_phandle_with_fixed_args(dev->of_node,
+ "wdt-reset-sysctrl", 2, 0, &out_args);
+ if (ret) {
+ dev_info(dev, "have no wdt-reset-sysctrl node");
+ return;
+ }
+ config = out_args.args[0];
+ mask = out_args.args[1];
+
+ regmap = syscon_node_to_regmap(out_args.np);
+ if (IS_ERR(regmap))
+ goto out;
+
+ ret = regmap_read(regmap, ZX2967_RESET_MASK_REG, &val);
+
+ val &= ~mask;
+ val |= config;
+ regmap_write(regmap, ZX2967_RESET_MASK_REG, val);
+out:
+ of_node_put(np);
+}
+
+static int zx2967_wdt_probe(struct platform_device *pdev)
+{
+ struct device *dev;
+ struct zx2967_wdt *wdt;
+ struct resource *base;
+ int err, ret = 0;
+ unsigned int rate;
+
+ struct reset_control *rstc;
+
+ dev = &pdev->dev;
+
+ wdt = devm_kzalloc(dev, sizeof(*wdt), GFP_KERNEL);
+ if (!wdt)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, wdt);
+
+ wdt->dev = dev;
+ wdt->wdt_device.info = &zx2967_wdt_ident;
+ wdt->wdt_device.ops = &zx2967_wdt_ops;
+ wdt->wdt_device.timeout = ZX2967_WDT_DEFAULT_TIMEOUT;
+ wdt->wdt_device.max_timeout = ZX2967_WDT_MAX_TIMEOUT;
+ wdt->wdt_device.min_timeout = ZX2967_WDT_MIN_TIMEOUT;
+ wdt->wdt_device.parent = &pdev->dev;
+
+ base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ wdt->reg_base = devm_ioremap_resource(dev, base);
+ if (IS_ERR(wdt->reg_base)) {
+ dev_err(dev, "ioremap failed\n");
+ return PTR_ERR(wdt->reg_base);
+ }
+
+ zx2967_wdt_reset_sysctrl(dev);
+
+ wdt->reboot_handler.notifier_call = zx2967_wdt_notify_sys;
+ ret = register_reboot_notifier(&wdt->reboot_handler);
+ wdt->clock = devm_clk_get(dev, "wdtclk");
+ if (IS_ERR(wdt->clock)) {
+ dev_err(dev, "failed to find watchdog clock source\n");
+ return PTR_ERR(wdt->clock);
+ }
+ ret = clk_prepare_enable(wdt->clock);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable clock\n");
+ return ret;
+ }
+
+ rate = clk_get_rate(wdt->clock);
+ if (rate == 24000000)
+ clk_set_rate(wdt->clock, 32768);
+
+ rstc = devm_reset_control_get(dev, "wdtrst");
+ if (!rstc) {
+ dev_err(dev, "rstc get failed");
+ } else {
+ reset_control_assert(rstc);
+ mdelay(10);
+ reset_control_deassert(rstc);
+ }
+
+ watchdog_set_drvdata(&wdt->wdt_device, wdt);
+
+ watchdog_init_timeout(&wdt->wdt_device,
+ ZX2967_WDT_DEFAULT_TIMEOUT, dev);
+ watchdog_set_nowayout(&wdt->wdt_device, WATCHDOG_NOWAYOUT);
+
+ zx2967_wdt_stop(&wdt->wdt_device);
+
+ err = watchdog_register_device(&wdt->wdt_device);
+ if (unlikely(err)) {
+ ret = err;
+ goto fail_register;
+ }
+
+ wdt->restart_handler.notifier_call = zx2967_wdt_restart;
+ wdt->restart_handler.priority = 128;
+ ret = register_restart_handler(&wdt->restart_handler);
+ if (ret) {
+ dev_err(dev, "cannot register restart handler, %d\n", ret);
+ goto fail_restart;
+ }
+
+ dev_info(dev, "watchdog enabled (timeout=%d sec, nowayout=%d)",
+ wdt->wdt_device.timeout, WATCHDOG_NOWAYOUT);
+
+ return 0;
+
+fail_restart:
+ watchdog_unregister_device(&wdt->wdt_device);
+fail_register:
+ clk_disable_unprepare(wdt->clock);
+ return ret;
+}
+
+static int zx2967_wdt_remove(struct platform_device *pdev)
+{
+ struct zx2967_wdt *wdt = platform_get_drvdata(pdev);
+
+ unregister_restart_handler(&wdt->restart_handler);
+ watchdog_unregister_device(&wdt->wdt_device);
+ clk_disable_unprepare(wdt->clock);
+
+ return 0;
+}
+
+static void zx2967_wdt_shutdown(struct platform_device *pdev)
+{
+ struct zx2967_wdt *wdt = platform_get_drvdata(pdev);
+
+ if (!(wdt->flags & ZX2967_WDT_FLAG_REBOOT_MON))
+ zx2967_wdt_stop(&wdt->wdt_device);
+}
+
+static const struct of_device_id zx2967_wdt_match[] = {
+ { .compatible = "zte,zx296718-wdt", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, zx2967_wdt_match);
+
+static struct platform_driver zx2967_wdt_driver = {
+ .probe = zx2967_wdt_probe,
+ .remove = zx2967_wdt_remove,
+ .shutdown = zx2967_wdt_shutdown,
+ .driver = {
+ .name = "zx2967-wdt",
+ .of_match_table = of_match_ptr(zx2967_wdt_match),
+ },
+};
+module_platform_driver(zx2967_wdt_driver);
+
+MODULE_AUTHOR("Baoyou Xie <baoyou.xie@linaro.org>");
+MODULE_DESCRIPTION("ZTE zx2967 Watchdog Device Driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] MAINTAINERS: add zx2967 watchdog controller driver to ARM ZTE architecture
From: Baoyou Xie @ 2017-01-19 1:59 UTC (permalink / raw)
To: jun.nie, wim, linux, robh+dt, mark.rutland
Cc: devicetree, linux-watchdog, xie.baoyou, linux-kernel,
chen.chaokai, wang.qiang01, baoyou.xie, shawnguo,
linux-arm-kernel
In-Reply-To: <1484791192-31674-1-git-send-email-baoyou.xie@linaro.org>
Add the zx2967 watchdog controller driver as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index edfdea3..275c434 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1990,11 +1990,13 @@ F: drivers/clk/zte/
F: drivers/reset/reset-zx2967.c
F: drivers/soc/zte/
F: drivers/thermal/zx*
+F: drivers/watchdog/zx2967_wdt.c
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
F: Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt
F: Documentation/devicetree/bindings/soc/zte/
F: Documentation/devicetree/bindings/thermal/zx*
+F: Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
F: include/dt-bindings/soc/zx*.h
ARM/ZYNQ ARCHITECTURE
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/3] dt: bindings: add documentation for zx2967 family watchdog controller
From: Baoyou Xie @ 2017-01-19 1:59 UTC (permalink / raw)
To: jun.nie, wim, linux, robh+dt, mark.rutland
Cc: devicetree, linux-watchdog, xie.baoyou, linux-kernel,
chen.chaokai, wang.qiang01, baoyou.xie, shawnguo,
linux-arm-kernel
This patch adds dt-binding documentation for zx2967 family
watchdog controller.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
.../bindings/watchdog/zte,zx2967-wdt.txt | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt b/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
new file mode 100644
index 0000000..6e35ce7
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
@@ -0,0 +1,32 @@
+ZTE zx2967 Watchdog timer
+
+Required properties:
+
+- compatible : should be one of the following.
+ * zte,zx296718-wdt
+- reg : Specifies base physical address and size of the registers.
+- clocks : Pairs of phandle and specifier referencing the controller's clocks.
+- clock-names: "wdtclk" for the watchdog clock.
+- resets : Reference to the reset controller controlling the watchdog
+ controller.
+- reset-names : Must include the following entries:
+ * wdtrst
+
+Optional properties:
+
+- wdt-reset-sysctrl : should include following fields.
+ * phandle of aon-sysctrl.
+ * configuare value that be wrote to aon-sysctrl.
+ * bit mask, corresponding bits will be affected.
+
+Example:
+
+wdt_ares: watchdog@1465000 {
+ compatible = "zte,zx296718-wdt";
+ reg = <0x1465000 0x1000>;
+ clocks = <&topcrm WDT_WCLK>;
+ clock-names = "wdtclk";
+ resets = <&toprst 35>;
+ reset-names = "wdtrst";
+ wdt-reset-sysctrl = <&aon_sysctrl 1 0x115>;
+};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 16/24] media: Add i.MX media core driver
From: Steve Longerbeam @ 2017-01-19 1:44 UTC (permalink / raw)
To: Philipp Zabel
Cc: mark.rutland, andrew-ct.chen, minghsiu.tsai, nick, songjun.wu,
hverkuil, Steve Longerbeam, robert.jarzmik, devel, markus.heiser,
laurent.pinchart+renesas, linux, geert, linux-media, devicetree,
arnd, mchehab, bparrot, robh+dt, horms+renesas, tiffany.lin,
linux-arm-kernel, niklas.soderlund+renesas, gregkh, linux-kernel,
jean-christophe.trotin, kernel, fabio.estevam, shawnguo,
sudipm.mukherjee
In-Reply-To: <2b1d2418-1ad4-6373-cb07-c3aeab48187f@gmail.com>
On 01/14/2017 02:42 PM, Steve Longerbeam wrote:
>
>>> +/* parse inputs property from a sensor node */
>>> +static void of_parse_sensor_inputs(struct imx_media_dev *imxmd,
>>> + struct imx_media_subdev *sensor,
>>> + struct device_node *sensor_np)
>>> +{
>>> + struct imx_media_sensor_input *sinput = &sensor->input;
>>> + int ret, i;
>>> +
>>> + for (i = 0; i < IMX_MEDIA_MAX_SENSOR_INPUTS; i++) {
>>> + const char *input_name;
>>> + u32 val;
>>> +
>>> + ret = of_property_read_u32_index(sensor_np, "inputs", i, &val);
>>> + if (ret)
>>> + break;
>>> +
>>> + sinput->value[i] = val;
>>> +
>>> + ret = of_property_read_string_index(sensor_np, "input-names",
>>> + i, &input_name);
>>> + /*
>>> + * if input-names not provided, they will be set using
>>> + * the subdev name once the sensor is known during
>>> + * async bind
>>> + */
>>> + if (!ret)
>>> + strncpy(sinput->name[i], input_name,
>>> + sizeof(sinput->name[i]));
>>> + }
>>> +
>>> + sinput->num = i;
>>> +
>>> + /* if no inputs provided just assume a single input */
>>> + if (sinput->num == 0)
>>> + sinput->num = 1;
>>> +}
>> This should be parsed by the sensor driver, not imx-media.
>
> you're probably right. I'll submit a patch for adv7180.c.
Actually, the problem here is that this parses an input routing value to
pass to s_routing, and an input name string. There would need to be
another subdev callback, maybe enum_imput, that would return this
information for the bridge driver, if this info were to be parsed and
maintained by the sensor.
But this info should really be known and parsed by the bridge anyway,
because as the header for s_routing states,
"An i2c device shouldn't know about whether an input pin is connected
to a Composite connector, because on another board or platform it
might be connected to something else entirely. The calling driver is
responsible for mapping a user-level input to the right pins on the i2c
device."
Steve
^ permalink raw reply
* Re: [PATCH v11 10/12] drm/mediatek: add non-continuous clock mode and EOT packet control
From: CK Hu @ 2017-01-19 1:42 UTC (permalink / raw)
To: YT Shen
Cc: Mark Rutland, devicetree, srv_heupstream, emil.l.velikov,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Matthias Brugger, yingjoe.chen, shaoming chen, linux-arm-kernel
In-Reply-To: <1484117473-46644-11-git-send-email-yt.shen@mediatek.com>
Hi, YT:
On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> This patch will update dsi clock control method.
> 1. dsi non-continue clock mode will enhance antistatic effect for panel
> 2. EOT packet control will judge whether dsi send end of packet or not
> by customize
>
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index b3c7fd8..85f22d2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -431,6 +431,9 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
> break;
> }
>
> + tmp_reg |= (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) << 6;
> + tmp_reg |= (dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET) >> 3;
> +
> writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
> }
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v2 3/3] ARM: dts: Enable Broadcom iProc mailbox controller
From: Jonathan Richardson @ 2017-01-19 1:39 UTC (permalink / raw)
To: Jassi Brar
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Russell King, Jonathan Richardson, Vikram Prakash,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
BCM Kernel Feedback
In-Reply-To: <1484789980-6812-1-git-send-email-jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Shreesha Rajashekar <shreesha.rajashekar-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Tested-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Vikram Prakash <vikram.prakash-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index fabc9f3..488bf42 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -114,6 +114,12 @@
<0x0301d24c 0x2c>;
};
+ mailbox: mailbox@03024024 {
+ compatible = "brcm,iproc-mailbox";
+ reg = <0x03024024 0x8>;
+ #mbox-cells = <1>;
+ };
+
gpio_crmu: gpio@03024800 {
compatible = "brcm,cygnus-crmu-gpio";
reg = <0x03024800 0x50>,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 2/3] mailbox: Add iProc mailbox controller driver
From: Jonathan Richardson @ 2017-01-19 1:39 UTC (permalink / raw)
To: Jassi Brar
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Russell King, Jonathan Richardson, Vikram Prakash,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
BCM Kernel Feedback
In-Reply-To: <1484789980-6812-1-git-send-email-jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
The Broadcom iProc mailbox controller handles all communication with a
Cortex-M0 MCU processor that provides support for power, clock, and
reset management.
Tested-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Vikram Prakash <vikram.prakash-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Shreesha Rajashekar <shreesha.rajashekar-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
drivers/mailbox/Kconfig | 10 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/bcm-iproc-mailbox.c | 199 ++++++++++++++++++++++++++++++
include/linux/mailbox/bcm_iproc_mailbox.h | 32 +++++
4 files changed, 243 insertions(+)
create mode 100644 drivers/mailbox/bcm-iproc-mailbox.c
create mode 100644 include/linux/mailbox/bcm_iproc_mailbox.h
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 11eebfe..284916d 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -143,4 +143,14 @@ config BCM_PDC_MBOX
Mailbox implementation for the Broadcom PDC ring manager,
which provides access to various offload engines on Broadcom
SoCs. Say Y here if you want to use the Broadcom PDC.
+
+config BCM_IPROC_MBOX
+ bool "Broadcom iProc Mailbox"
+ depends on ARCH_BCM_IPROC || COMPILE_TEST
+ default ARCH_BCM_IPROC
+ help
+ Broadcom iProc architected SoC's have an always on Cortex-M0 MCU processor
+ that handles support for power, clock, and reset management. The iProc
+ mailbox controller handles all communication with this processor.
+
endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index ace6fed..f96eab6 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -29,3 +29,5 @@ obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
obj-$(CONFIG_HI6220_MBOX) += hi6220-mailbox.o
obj-$(CONFIG_BCM_PDC_MBOX) += bcm-pdc-mailbox.o
+
+obj-$(CONFIG_BCM_IPROC_MBOX) += bcm-iproc-mailbox.o
diff --git a/drivers/mailbox/bcm-iproc-mailbox.c b/drivers/mailbox/bcm-iproc-mailbox.c
new file mode 100644
index 0000000..36ecad5
--- /dev/null
+++ b/drivers/mailbox/bcm-iproc-mailbox.c
@@ -0,0 +1,199 @@
+/*
+ * Copyright (C) 2017 Broadcom.
+ *
+ * This program 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/mailbox_controller.h>
+#include <linux/mailbox/bcm_iproc_mailbox.h>
+#include <linux/delay.h>
+
+#define IPROC_CRMU_MAILBOX0_OFFSET 0x0
+#define IPROC_CRMU_MAILBOX1_OFFSET 0x4
+
+#define M0_IPC_CMD_DONE_MASK 0x80000000
+#define M0_IPC_CMD_REPLY_MASK 0x3fff0000
+#define M0_IPC_CMD_REPLY_SHIFT 16
+
+/* Max time the M0 will take to respond to a message. */
+#define MAX_M0_TIMEOUT_MS 2
+
+struct iproc_mbox {
+ struct device *dev;
+ void __iomem *base;
+ spinlock_t lock;
+ struct mbox_controller controller;
+ u32 num_chans;
+};
+
+static const struct of_device_id iproc_mbox_of_match[] = {
+ { .compatible = "brcm,iproc-mailbox" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, iproc_mbox_of_match);
+
+/*
+ * Sends a message to M0. The mailbox framework prevents multiple accesses to
+ * the same channel but there is only one h/w "channel". This driver allows
+ * multiple clients to create channels to the controller but must serialize
+ * access to the mailbox registers used to communicate with the M0.
+ */
+static int iproc_mbox_send_data_m0(struct mbox_chan *chan, void *data)
+{
+ struct iproc_mbox *mbox = dev_get_drvdata(chan->mbox->dev);
+ struct iproc_mbox_msg *msg = (struct iproc_mbox_msg *)data;
+ unsigned long flags;
+ int err = 0;
+ const int poll_period_us = 5;
+ const int max_retries = (MAX_M0_TIMEOUT_MS * 1000) / poll_period_us;
+
+ if (!msg)
+ return -EINVAL;
+
+ spin_lock_irqsave(&mbox->lock, flags);
+
+ dev_dbg(mbox->dev, "Send msg to M0: cmd=0x%x, param=0x%x, wait_ack=%d\n",
+ msg->cmd, msg->param, msg->wait_ack);
+
+ writel(msg->cmd, mbox->base + IPROC_CRMU_MAILBOX0_OFFSET);
+ writel(msg->param, mbox->base + IPROC_CRMU_MAILBOX1_OFFSET);
+
+ if (msg->wait_ack) {
+ int retries;
+
+ err = msg->reply_code = -ETIMEDOUT;
+ for (retries = 0; retries < max_retries; retries++) {
+ u32 val = readl(
+ mbox->base + IPROC_CRMU_MAILBOX0_OFFSET);
+ if (val & M0_IPC_CMD_DONE_MASK) {
+ /*
+ * M0 replied - save reply code and
+ * clear error.
+ */
+ msg->reply_code = (val &
+ M0_IPC_CMD_REPLY_MASK) >>
+ M0_IPC_CMD_REPLY_SHIFT;
+ err = 0;
+ break;
+ }
+ udelay(poll_period_us);
+ }
+ }
+
+ spin_unlock_irqrestore(&mbox->lock, flags);
+
+ return err;
+}
+
+static int iproc_mbox_startup(struct mbox_chan *chan)
+{
+ /* Do nothing. */
+ return 0;
+}
+
+static void iproc_mbox_shutdown(struct mbox_chan *chan)
+{
+ /* Do nothing. */
+}
+
+static struct mbox_chan_ops iproc_mbox_ops = {
+ .send_data = iproc_mbox_send_data_m0,
+ .startup = iproc_mbox_startup,
+ .shutdown = iproc_mbox_shutdown,
+};
+
+static int iproc_mbox_probe(struct platform_device *pdev)
+{
+ int err;
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ struct iproc_mbox *iproc_mbox;
+ struct device_node *node;
+ const char *mbox_prop_name = "mboxes";
+ struct mbox_chan *chans;
+
+ dev_info(&pdev->dev, "Initializing iproc mailbox controller\n");
+
+ iproc_mbox = devm_kzalloc(dev, sizeof(*iproc_mbox), GFP_KERNEL);
+ if (!iproc_mbox)
+ return -ENOMEM;
+
+ iproc_mbox->dev = dev;
+ spin_lock_init(&iproc_mbox->lock);
+
+ platform_set_drvdata(pdev, iproc_mbox);
+
+ /* Count number of "mboxes" properties to determine # channels. */
+ for_each_of_allnodes(node) {
+ struct property *prop = of_find_property(
+ node, mbox_prop_name, NULL);
+ if (prop) {
+ struct device_node *mbox_phandle = of_parse_phandle(
+ node, mbox_prop_name, 0);
+ if (mbox_phandle == dev->of_node)
+ iproc_mbox->num_chans++;
+ }
+ }
+
+ if (iproc_mbox->num_chans == 0) {
+ dev_err(dev, "No mailbox clients configured\n");
+ return -ENODEV;
+ }
+
+ chans = devm_kzalloc(&pdev->dev,
+ sizeof(*chans) * iproc_mbox->num_chans, GFP_KERNEL);
+ if (!chans)
+ return -ENOMEM;
+
+ /* Initialize mailbox controller. */
+ iproc_mbox->controller.dev = iproc_mbox->dev;
+ iproc_mbox->controller.num_chans = iproc_mbox->num_chans;
+ iproc_mbox->controller.chans = chans;
+ iproc_mbox->controller.ops = &iproc_mbox_ops;
+ iproc_mbox->controller.txdone_irq = false;
+ iproc_mbox->controller.txdone_poll = false;
+ err = mbox_controller_register(&iproc_mbox->controller);
+ if (err) {
+ dev_err(&pdev->dev, "Register mailbox failed\n");
+ return err;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ iproc_mbox->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(iproc_mbox->base)) {
+ dev_err(&pdev->dev, "unable to map I/O memory\n");
+ return PTR_ERR(iproc_mbox->base);
+ }
+
+ return 0;
+}
+
+static struct platform_driver iproc_mbox_driver = {
+ .driver = {
+ .name = "brcm,iproc-mailbox",
+ .of_match_table = iproc_mbox_of_match,
+ },
+ .probe = iproc_mbox_probe,
+};
+
+static int __init iproc_mbox_init(void)
+{
+ return platform_driver_register(&iproc_mbox_driver);
+}
+arch_initcall(iproc_mbox_init);
+
+MODULE_AUTHOR("Broadcom");
+MODULE_DESCRIPTION("Broadcom iProc Mailbox Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/mailbox/bcm_iproc_mailbox.h b/include/linux/mailbox/bcm_iproc_mailbox.h
new file mode 100644
index 0000000..68f37e4
--- /dev/null
+++ b/include/linux/mailbox/bcm_iproc_mailbox.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2016 Broadcom.
+ *
+ * This program 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#ifndef _BCM_IPROC_MAILBOX_H_
+#define _BCM_IPROC_MAILBOX_H_
+
+/*
+ * A message to send to the M0 processor.
+ * @cmd Command to send.
+ * @param Parameter corresponding to command.
+ * @wait_ack true if mbox_send_message() should wait for a reply from the M0,
+ * false if the M0 doesn't reply. This depends on the message being sent.
+ * @reply_code The response code from the M0 for the command sent (wait_ack was
+ * set to true).
+ */
+struct iproc_mbox_msg {
+ u32 cmd;
+ u32 param;
+ bool wait_ack;
+ u32 reply_code;
+};
+
+#endif
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: Document Broadcom iProc mailbox controller driver
From: Jonathan Richardson @ 2017-01-19 1:39 UTC (permalink / raw)
To: Jassi Brar
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Russell King, Jonathan Richardson, Vikram Prakash,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
BCM Kernel Feedback
In-Reply-To: <1484789980-6812-1-git-send-email-jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Tested-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Vikram Prakash <vikram.prakash-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Shreesha Rajashekar <shreesha.rajashekar-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
.../devicetree/bindings/mailbox/brcm,iproc-mailbox.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt
new file mode 100644
index 0000000..f4c4f96
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt
@@ -0,0 +1,14 @@
+* Broadcom's iProc Mailbox Controller
+
+Required properties:
+- compatible: Must be "brcm,iproc-mailbox"
+- reg: Defines the base address of the mailbox controller.
+- #mbox-cells: Must be 1.
+
+Example:
+
+ mailbox: mailbox@03024024 {
+ compatible = "brcm,iproc-mailbox";
+ reg = <0x03024024 0x8>;
+ #mbox-cells = <1>;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 0/3] Add support for Broadcom iProc mailbox controller
From: Jonathan Richardson @ 2017-01-19 1:39 UTC (permalink / raw)
To: Jassi Brar
Cc: Mark Rutland, devicetree, Jonathan Richardson, Scott Branden,
Jon Mason, Ray Jui, Russell King, Vikram Prakash, Rob Herring,
BCM Kernel Feedback, linux-arm-kernel
This patch set contains mailbox support for Broadcom iProc based SoC's. The
mailbox controller handles all communication with a Cortex-M0 MCU processor that
provides support for power, clock, and reset management.
The patch set enables the mailbox controller for Cygnus and also interrupt
support for the Cygnus CRMU GPIO driver which requires use of the M0 processor.
Changes from v1:
- Interrupt handling has been removed and will be added to an interrupt
controller driver and sent out in a separate patchset.
- Moved location of bcm_iproc_mailbox.h to include/linux/mailbox as suggested by
Jassi.
- Removed reading of client timeout from driver and used canned timeout. This
removes the need of including the client mailbox header.
Jonathan Richardson (3):
dt-bindings: Document Broadcom iProc mailbox controller driver
mailbox: Add iProc mailbox controller driver
ARM: dts: Enable Broadcom iProc mailbox controller
.../bindings/mailbox/brcm,iproc-mailbox.txt | 14 ++
arch/arm/boot/dts/bcm-cygnus.dtsi | 6 +
drivers/mailbox/Kconfig | 10 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/bcm-iproc-mailbox.c | 199 +++++++++++++++++++++
include/linux/mailbox/bcm_iproc_mailbox.h | 32 ++++
6 files changed, 263 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt
create mode 100644 drivers/mailbox/bcm-iproc-mailbox.c
create mode 100644 include/linux/mailbox/bcm_iproc_mailbox.h
--
1.9.1
^ permalink raw reply
* Re: [PATCH v5] ARM64: dts: meson-gx: Add firmware reserved memory zones
From: Andreas Färber @ 2017-01-19 1:18 UTC (permalink / raw)
To: Neil Armstrong, xypron.glpk, khilman, carlo
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <2bdb6818-4620-53b1-112d-2d6a29e484d9@suse.de>
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@baylibre.com
>> [2] http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstrong@baylibre.com
>> [3] http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstrong@baylibre.com
>> [4] http://lkml.kernel.org/r/1484128540-22662-1-git-send-email-narmstrong@baylibre.com
>> [5] http://lkml.kernel.org/r/1484129414-23325-1-git-send-email-narmstrong@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.
>> + no-map;
>> + };
>> + };
>> +
>> cpus {
>> #address-cells = <0x2>;
>> #size-cells = <0x0>;
>
> Anyway, objection resolved,
>
> Reviewed-by: Andreas Färber <afaerber@suse.de>
>
> I don't expect breakage from these more confined additions, but I can
> try to test tomorrow.
>
> Thanks,
> Andreas
>
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCHv4 2/5] arm: mvebu: support for SMP on 98DX3336 SoC
From: Stephen Boyd @ 2017-01-19 0:47 UTC (permalink / raw)
To: Chris Packham
Cc: linux-arm-kernel, Rob Herring, Mark Rutland, Jason Cooper,
Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Russell King,
Geert Uytterhoeven, Florian Fainelli, Chris Brand, Juri Lelli,
Sudeep Holla, Jayachandran C, devicetree, linux-kernel
In-Reply-To: <20170113091222.7132-3-chris.packham@alliedtelesis.co.nz>
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>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy
From: Stephen Boyd @ 2017-01-19 0:40 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Vivek Gautam, Kishon Vijay Abraham I, robh+dt, linux-kernel,
devicetree, mark.rutland, srinivas.kandagatla, linux-arm-msm
In-Reply-To: <20170118182223.GP10531@minitux>
On 01/18, Bjorn Andersson wrote:
> On Tue 17 Jan 22:54 PST 2017, Vivek Gautam wrote:
> > On 01/16/2017 02:19 PM, Kishon Vijay Abraham I wrote:
> > > On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:
> [..]
> > > > + reset-names = "phy", "common", "cfg",
> > > > + "lane0", "lane1", "lane2";
> > > Each lane has a separate clock, separate reset.. why not create sub-nodes for
> > > each lane?
> >
> > Yes, each lane has separate pipe clock and resets.
> > I can have a binding such as written below.
>
> +1
>
> > Does it makes sense to pull in the tx, rx and pcs offsets as well
> > to the child node, and iomap the entire address space of the phy ?
> >
>
> Note that you don't have to follow the same structure in your device
> driver as you describe your hardware in devicetree.
>
> I would suggest that you replace the lane-offset and various lane
> specific resources with subnodes, but keep the driver "as is".
>
Didn't we already move away from subnodes for lanes in an earlier
revision of these patches? I seem to recall we did that because
lanes are not devices and the whole "phy as a bus" concept not
making sense.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 00/18] FSI device driver introduction
From: christopher.lee.bostic @ 2017-01-19 0:30 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, linux-kernel, andrew,
alistair, benh
Cc: Christopher Bostic
From: Christopher Bostic <christopher.lee.bostic@gmail.com>
Introduction of the IBM 'Flexible Support Interface' (FSI) bus device
driver. FSI is a high fan out serial bus consisting of a clock and a serial
data line capable of running at speeds up to 166 MHz.
This set provides the basic framework to add FSI extensions to the
Linux bus and device models. Master specific implementations are
defined to utilize the core FSI function.
In Linux, we have a core FSI "bus type", along with drivers for FSI
masters and engines.
The FSI master drivers expose a read/write interface to the bus address
space. The master drivers are under drivers/fsi/fsi-master-*.c.
The core handles probing and discovery of slaves and slave
engines, using those read/write interfaces. It is responsible for
creating the endpoint Linux devices corresponding to the discovered
engines on each slave.
Slave engines are identified by an 'engine' type, and an optional
version. Engine, a.k.a. client, drivers are matched and bound to these
engines during discovery.
This patch set does not include extended FSI function such as:
* Hub master support
* Cascaded master support
* Application layer hot plug notification
* Application layer FSI bus status interface
Common FSI terminology:
* Master
Controller of the FSI bus. Only the master is allowed to control the
clock line and is the initiator of all transactions on a bus.
* Slave
The receiver or target of a master initiated transaction. The slave
cannot initiate communications on a bus and must respond to any
master requests for data.
* CFAM
Stands for Common Field replaceable unit Access Macro. A CFAM is an
ASIC residing in any device requiring FSI communications. CFAMs
consist of an array of hardware 'engines' used for various purposes.
I2C masters, UARTs, General Purpose IO hardware are common types of
these engines.
* Configuration Space / Table
A table contained at the beginning of each CFAM address space.
This table lists information such as the CFAM's ID, which engine types
and versions it has available, as well as its addressing range.
* FSI Engine driver
A device driver that registers with the FSI core so that it can access
devices it owns on an FSI bus.
Chris Bostic (8):
drivers/fsi: Kick off master scan via sysfs
drivers/fsi: Set up links for slave communication
drivers/fsi: Set slave SMODE to init communication
drivers/fsi: Remove all scanned devices during master unregister
drivers/fsi: Add FSI bus documentation
drivers/fsi: Add documentation for GPIO based FSI master
drivers/fsi: Document FSI master sysfs files in ABI
drivers/fsi: Add GPIO based FSI master
Jeremy Kerr (10):
drivers/fsi: Add empty fsi bus definitions
drivers/fsi: Add device & driver definitions
drivers/fsi: add driver to device matches
drivers/fsi: Add fsi master definition
drivers/fsi: Add slave definition
drivers/fsi: Add empty master scan
drivers/fsi: Add FSI crc calculators to library
drivers/fsi: Implement slave initialisation
drivers/fsi: scan slaves & register devices
drivers/fsi: Add device read/write/peek functions
Changes for v3:
- Patch set contained an invalid 18/18 test patch not
meant for community review, corrected.
Changes for v2:
- Change from atomic global for master number to ida simple
interface.
- Add valid pointer checks on register and unregister utils.
- Move CRC calculation utilities out of driver to lib path.
- Clean up white space issues.
- Remove added list management of master devices and use
instead the device_for_each_child method available in the
bus.
- Add new patch to document FSI bus functionality.
- Add new patch documenting FSI gpio master.
- Rearrage patch set to have documentation earlier than code
implementing it.
- Document all compatible strings used in device tree bindings.
- Elaborate documentation definition of FSI GPIO master.
- Describe in more detail what each GPIO FSI master pin is for.
- Re-order compatible strings in example binding so that most
specific device comes first.
- Indicate proper activation order of all FSI GPIO master pins.
- Fix an unmatched '>' bracket in the example for binding.
- Bracket each element of the example bindings individually.
- Add new patch documenting sysfs-bus-fsi attributes.
- Merge FSI GPIO master init into probe function.
- Set pin initial values at time of pin request.
- Assign value of master->master.dev at probe time.
- Use get_optional interface for all optional GPIO pins.
Documentation/ABI/testing/sysfs-bus-fsi | 6 +
.../devicetree/bindings/fsi/fsi-master-gpio.txt | 71 +++
Documentation/devicetree/bindings/fsi/fsi.txt | 54 +++
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/fsi/Kconfig | 23 +
drivers/fsi/Makefile | 3 +
drivers/fsi/fsi-core.c | 494 +++++++++++++++++++
drivers/fsi/fsi-master-gpio.c | 530 +++++++++++++++++++++
drivers/fsi/fsi-master.h | 39 ++
include/linux/crc-fsi.h | 29 ++
include/linux/fsi.h | 60 +++
lib/Makefile | 1 +
lib/crc-fsi.c | 39 ++
14 files changed, 1352 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-fsi
create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
create mode 100644 Documentation/devicetree/bindings/fsi/fsi.txt
create mode 100644 drivers/fsi/Kconfig
create mode 100644 drivers/fsi/Makefile
create mode 100644 drivers/fsi/fsi-core.c
create mode 100644 drivers/fsi/fsi-master-gpio.c
create mode 100644 drivers/fsi/fsi-master.h
create mode 100644 include/linux/crc-fsi.h
create mode 100644 include/linux/fsi.h
create mode 100644 lib/crc-fsi.c
--
1.8.2.2
^ permalink raw reply
* [PATCH v5 2/2] cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs
From: Markus Mayer @ 2017-01-19 0:29 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Viresh Kumar, Rafael J . Wysocki, Arnd Bergmann
Cc: Device Tree List, Power Management List,
Linux Kernel Mailing List, Broadcom Kernel List, Markus Mayer,
Linux Clock List, ARM Kernel List
In-Reply-To: <20170119002933.7529-1-code@mmayer.net>
From: Markus Mayer <mmayer@broadcom.com>
This CPUfreq driver provides basic frequency scaling for older Broadcom
STB SoCs that do not use AVS firmware with DVFS support. There is no
support for voltage scaling.
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/Kconfig.arm | 12 ++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/brcmstb-cpufreq.c | 377 ++++++++++++++++++++++++++++++++++++++
3 files changed, 390 insertions(+)
create mode 100644 drivers/cpufreq/brcmstb-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 920c469..36422af 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -33,6 +33,18 @@ config ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
If in doubt, say N.
+config ARM_BRCMSTB_CPUFREQ
+ tristate "Broadcom STB CPUfreq driver"
+ depends on ARCH_BRCMSTB || COMPILE_TEST
+ default y
+ help
+ Some Broadcom SoCs offer multiple operating frequencies that CPUfreq
+ can take advantage of to improve energy efficiency.
+
+ Say Y, if you have a supported Broadcom SoC. If your Broadcom SoC
+ has AVS firmware with support for frequency and voltage scaling,
+ say N here and enable ARM_BRCMSTB_AVS_CPUFREQ instead.
+
config ARM_DT_BL_CPUFREQ
tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver"
depends on ARM_BIG_LITTLE_CPUFREQ && OF
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 1e46c39..23700aa 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ) += arm_big_little.o
obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o
obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ) += brcmstb-avs-cpufreq.o
+obj-$(CONFIG_ARM_BRCMSTB_CPUFREQ) += brcmstb-cpufreq.o
obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
diff --git a/drivers/cpufreq/brcmstb-cpufreq.c b/drivers/cpufreq/brcmstb-cpufreq.c
new file mode 100644
index 0000000..8849d56
--- /dev/null
+++ b/drivers/cpufreq/brcmstb-cpufreq.c
@@ -0,0 +1,377 @@
+/*
+ * CPU frequency scaling for Broadcom set top box SoCs
+ *
+ * Copyright (c) 2016-17 Broadcom
+ *
+ * This program 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/cpufreq.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+#define BRCMSTB_CPUFREQ_PREFIX "brcmstb"
+#define BRCMSTB_CPUFREQ_NAME BRCMSTB_CPUFREQ_PREFIX "-cpufreq"
+
+/* We search for these compatible strings. */
+#define BRCMSTB_DT_CPU_CLK_CTRL "brcm,brcmstb-cpu-clk-div"
+#define BRCMSTB_DT_MEMC_DDR "brcm,brcmstb-memc-ddr"
+#define BRCM_AVS_CPU_DATA "brcm,avs-cpu-data-mem"
+
+/*
+ * We also need a few clocks in device tree. They are referenced in the
+ * brcm,brcmstb-cpu-clk-div node in device tree, so we can look them up.
+ */
+#define BRCMSTB_CLK_MDIV_CH0 "cpu_mdiv_ch0"
+#define BRCMSTB_CLK_NDIV_INT "cpu_ndiv_int"
+#define BRCMSTB_CLK_SW_SCB "sw_scb"
+
+#define BRCMSTB_TBL_SAFE_MODE BIT(0)
+#define BRCMSTB_REG_SAFE_MODE BIT(4)
+
+#define TRANSITION_LATENCY (25 * 1000) /* 25 us */
+
+/* This is as low as we'll go in the frequency table. */
+#define MIN_CPU_FREQ (100 * 1000) /* in kHz */
+
+struct private_data {
+ void __iomem *cpu_clk_ctrl_reg;
+ struct clk *mdiv_clk;
+ struct clk *ndiv_clk;
+ struct clk *sw_scb_clk;
+ struct device *dev;
+};
+
+/* Count the active memory controllers in the system. */
+static int count_memory_controllers(void)
+{
+ struct device_node *np = NULL;
+ int i = 0;
+
+ do {
+ np = of_find_compatible_node(np, NULL, BRCMSTB_DT_MEMC_DDR);
+ if (of_device_is_available(np))
+ i++;
+ of_node_put(np);
+ } while (np);
+
+ return i;
+}
+
+static void get_frequencies(const struct cpufreq_policy *policy,
+ unsigned int *vco_freq, unsigned int *cpu_freq,
+ unsigned int *scb_freq)
+{
+ struct private_data *priv = policy->driver_data;
+
+ /* return frequencies in kHz */
+ *vco_freq = clk_get_rate(priv->ndiv_clk) / 1000;
+ *cpu_freq = clk_get_rate(priv->mdiv_clk) / 1000;
+ *scb_freq = clk_get_rate(priv->sw_scb_clk) / 1000;
+}
+
+/*
+ * Safe mode: When set, the CPU's bus unit is being throttled. This is done to
+ * avoid buffer overflows when the CPU-to-bus-clock ratio is low.
+ *
+ * The formula as to what constitutes a low CPU-to-bus-clock ratio takes into
+ * account the number of memory controllers active in the system and the SCB
+ * frequency. More memory controllers means safe mode is required starting at
+ * higher frequencies.
+ *
+ * For 1 memory controller, cpu_freq/scb_freq must be greater than or equal to
+ * 2 to not require safe mode.
+ *
+ * For 2 or 3 memory controllers, cpu_freq/scb_freq must be greater than or
+ * equal 3 to not require safe mode.
+ */
+
+static int freq_requires_safe_mode(unsigned int cpu_freq, unsigned int scb_freq,
+ int num_memc)
+{
+ unsigned int safe_ratio;
+
+ switch (num_memc) {
+ case 1:
+ safe_ratio = 2;
+ break;
+ case 2:
+ case 3:
+ safe_ratio = 3;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return ((cpu_freq / scb_freq) < safe_ratio);
+}
+
+static struct cpufreq_frequency_table *
+brcmstb_get_freq_table(const struct cpufreq_policy *policy)
+{
+ unsigned int cpu_freq, vco_freq, scb_freq, mdiv, init_mdiv, f;
+ struct cpufreq_frequency_table *table;
+ struct private_data *priv;
+ int num_memc, ret;
+ unsigned int i = 0;
+
+ priv = policy->driver_data;
+ num_memc = count_memory_controllers();
+ get_frequencies(policy, &vco_freq, &cpu_freq, &scb_freq);
+
+ /* Calculate the initial mdiv value. We'll increment mdiv from here. */
+ init_mdiv = vco_freq / cpu_freq;
+
+ /* Count how many frequencies we'll offer. */
+ f = cpu_freq;
+ for (mdiv = init_mdiv; f >= MIN_CPU_FREQ; mdiv++, f = vco_freq / mdiv) {
+ /* We only want to use "whole" MHz. */
+ if ((f % 1000) == 0)
+ i++;
+ }
+
+ table = devm_kzalloc(priv->dev, (i + 1) * sizeof(*table), GFP_KERNEL);
+ if (!table)
+ return ERR_PTR(-ENOMEM);
+
+ /* Now, fill the table. */
+ f = cpu_freq;
+ i = 0;
+ for (mdiv = init_mdiv; f >= MIN_CPU_FREQ; mdiv++, f = vco_freq / mdiv) {
+ if ((f % 1000) == 0) {
+ table[i].frequency = f;
+ ret = freq_requires_safe_mode(f, scb_freq, num_memc);
+ if (ret < 0)
+ return ERR_PTR(ret);
+ if (ret > 0)
+ table[i].driver_data |= BRCMSTB_TBL_SAFE_MODE;
+ i++;
+ }
+ }
+ table[i].frequency = CPUFREQ_TABLE_END;
+
+ return table;
+}
+
+static int brcmstb_target_index(struct cpufreq_policy *policy,
+ unsigned int index)
+{
+ struct cpufreq_frequency_table *entry;
+ struct private_data *priv;
+ int ret, safe_mode_needed;
+ u32 reg;
+
+ priv = policy->driver_data;
+ entry = &policy->freq_table[index];
+ safe_mode_needed = entry->driver_data & BRCMSTB_TBL_SAFE_MODE;
+
+ reg = readl(priv->cpu_clk_ctrl_reg);
+ if (safe_mode_needed && !(reg & BRCMSTB_REG_SAFE_MODE)) {
+ reg |= BRCMSTB_REG_SAFE_MODE;
+ writel(reg, priv->cpu_clk_ctrl_reg);
+ }
+ ret = clk_set_rate(policy->clk, entry->frequency * 1000);
+ if (!ret && !safe_mode_needed && (reg & BRCMSTB_REG_SAFE_MODE)) {
+ reg &= ~BRCMSTB_REG_SAFE_MODE;
+ writel(reg, priv->cpu_clk_ctrl_reg);
+ }
+
+ return ret;
+}
+
+/*
+ * All initialization code that we only want to execute once goes here. Setup
+ * code that can be re-tried on every core (if it failed before) can go into
+ * brcmstb_cpufreq_init().
+ */
+static int brcmstb_prepare_init(struct platform_device *pdev)
+{
+ struct private_data *priv;
+ struct resource *res;
+ struct device *dev;
+
+ /*
+ * If the BRCM STB AVS CPUfreq driver is supported, we bail, so that
+ * the more modern approach implementing DVFS in firmware can be used.
+ */
+ if (IS_ENABLED(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ)) {
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, BRCM_AVS_CPU_DATA);
+ if (np) {
+ of_node_put(np);
+ return -ENXIO;
+ }
+ }
+
+ dev = &pdev->dev;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->cpu_clk_ctrl_reg = devm_ioremap_resource(dev, res);
+ if (IS_ERR(priv->cpu_clk_ctrl_reg)) {
+ dev_err(dev, "couldn't map DT entry %s\n",
+ BRCMSTB_DT_CPU_CLK_CTRL);
+ return -ENODEV;
+ }
+
+ priv->mdiv_clk = devm_clk_get(dev, BRCMSTB_CLK_MDIV_CH0);
+ priv->ndiv_clk = devm_clk_get(dev, BRCMSTB_CLK_NDIV_INT);
+ priv->sw_scb_clk = devm_clk_get(dev, BRCMSTB_CLK_SW_SCB);
+
+ if (IS_ERR(priv->mdiv_clk))
+ return PTR_ERR(priv->mdiv_clk);
+ if (IS_ERR(priv->ndiv_clk))
+ return PTR_ERR(priv->ndiv_clk);
+ if (IS_ERR(priv->sw_scb_clk))
+ return PTR_ERR(priv->sw_scb_clk);
+
+ priv->dev = dev;
+ platform_set_drvdata(pdev, priv);
+
+ return 0;
+}
+
+static int brcmstb_cpufreq_init(struct cpufreq_policy *policy)
+{
+ struct cpufreq_frequency_table *freq_table;
+ struct platform_device *pdev;
+ struct private_data *priv;
+ struct device *dev;
+ int ret;
+
+ pdev = cpufreq_get_driver_data();
+ priv = platform_get_drvdata(pdev);
+ dev = &pdev->dev;
+
+ policy->clk = priv->mdiv_clk;
+ policy->driver_data = priv;
+
+ freq_table = brcmstb_get_freq_table(policy);
+ if (IS_ERR(freq_table)) {
+ ret = PTR_ERR(freq_table);
+ dev_err(dev, "Couldn't determine frequency table (%d).\n", ret);
+ if (ret == -EINVAL)
+ dev_emerg(dev,
+ "Invalid number of memory controllers -- %d!\n",
+ count_memory_controllers());
+ return ret;
+ }
+
+ ret = cpufreq_generic_init(policy, freq_table, TRANSITION_LATENCY);
+ if (!ret)
+ dev_info(dev, "registered\n");
+
+ return ret;
+}
+
+/* Shows the number of memory controllers. */
+static ssize_t show_brcmstb_num_memc(struct cpufreq_policy *policy, char *buf)
+{
+ return sprintf(buf, "%u\n", count_memory_controllers());
+}
+
+/* Shows vco_freq, cpu_freq, and scb_freq in kHz. */
+static ssize_t show_brcmstb_freqs(struct cpufreq_policy *policy, char *buf)
+{
+ unsigned int vco_freq, cpu_freq, scb_freq;
+
+ get_frequencies(policy, &vco_freq, &cpu_freq, &scb_freq);
+
+ return sprintf(buf, "%u %u %u\n", vco_freq, cpu_freq, scb_freq);
+}
+
+/* Shows the lowest frequency (in kHz) that can be used without "safe mode". */
+static ssize_t show_brcmstb_safe_freq(struct cpufreq_policy *policy, char *buf)
+{
+ struct cpufreq_frequency_table *entry;
+ unsigned int safe_freq = 0;
+
+ cpufreq_for_each_valid_entry(entry, policy->freq_table) {
+ if (!(entry->driver_data & BRCMSTB_TBL_SAFE_MODE))
+ safe_freq = entry->frequency;
+ }
+
+ return sprintf(buf, "%u\n", safe_freq);
+}
+
+cpufreq_freq_attr_ro(brcmstb_num_memc);
+cpufreq_freq_attr_ro(brcmstb_freqs);
+cpufreq_freq_attr_ro(brcmstb_safe_freq);
+
+static struct freq_attr *brcmstb_cpufreq_attr[] = {
+ &cpufreq_freq_attr_scaling_available_freqs,
+ &brcmstb_num_memc,
+ &brcmstb_freqs,
+ &brcmstb_safe_freq,
+ NULL
+};
+
+static struct cpufreq_driver brcmstb_driver = {
+ .flags = CPUFREQ_NEED_INITIAL_FREQ_CHECK,
+ .verify = cpufreq_generic_frequency_table_verify,
+ .target_index = brcmstb_target_index,
+ .get = cpufreq_generic_get,
+ .init = brcmstb_cpufreq_init,
+ .attr = brcmstb_cpufreq_attr,
+ .name = BRCMSTB_CPUFREQ_PREFIX,
+};
+
+static int brcmstb_cpufreq_probe(struct platform_device *pdev)
+{
+ int ret;
+
+ ret = brcmstb_prepare_init(pdev);
+ if (ret)
+ return ret;
+
+ brcmstb_driver.driver_data = pdev;
+
+ return cpufreq_register_driver(&brcmstb_driver);
+}
+
+static int brcmstb_cpufreq_remove(struct platform_device *pdev)
+{
+ int ret;
+
+ ret = cpufreq_unregister_driver(&brcmstb_driver);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, NULL);
+
+ return 0;
+}
+
+static const struct of_device_id brcmstb_cpufreq_match[] = {
+ { .compatible = BRCMSTB_DT_CPU_CLK_CTRL },
+ { }
+};
+MODULE_DEVICE_TABLE(of, brcmstb_cpufreq_match);
+
+static struct platform_driver brcmstb_cpufreq_platdrv = {
+ .driver = {
+ .name = BRCMSTB_CPUFREQ_NAME,
+ .of_match_table = brcmstb_cpufreq_match,
+ },
+ .probe = brcmstb_cpufreq_probe,
+ .remove = brcmstb_cpufreq_remove,
+};
+module_platform_driver(brcmstb_cpufreq_platdrv);
+
+MODULE_AUTHOR("Markus Mayer <mmayer@broadcom.com>");
+MODULE_DESCRIPTION("CPUfreq driver for Broadcom STB SoCs");
+MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
From: Markus Mayer @ 2017-01-19 0:29 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Viresh Kumar, Rafael J . Wysocki, Arnd Bergmann
Cc: Device Tree List, Power Management List,
Linux Kernel Mailing List, Broadcom Kernel List, Markus Mayer,
Linux Clock List, ARM Kernel List
In-Reply-To: <20170119002933.7529-1-code@mmayer.net>
From: Markus Mayer <mmayer@broadcom.com>
Add binding document for brcm,brcmstb-cpu-clk-div.
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
---
.../bindings/clock/brcm,brcmstb-cpu-clk-div.txt | 27 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
diff --git a/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
new file mode 100644
index 0000000..c4acb53
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
@@ -0,0 +1,27 @@
+The CPU divider node serves as the sole clock for the CPU complex. It supports
+power-of-2 clock division, with a divider of "1" as the default highest-speed
+setting.
+
+Required properties:
+- compatible: shall be "brcm,brcmstb-cpu-clk-div"
+- reg: address and width of the divider configuration register
+- #clock-cells: shall be set to 0
+- clocks: phandle of clock provider which provides the source clock
+ (this would typically be a "fixed-clock" type PLL)
+- div-table: list of (raw_value,divider) ordered pairs that correspond to the
+ allowed clock divider settings
+- div-shift-width: least-significant bit position and width of divider value
+
+Optional properties:
+- clock-names: the clock may be named
+
+Example:
+ cpuclkdiv: cpu-clk-div@f03e257c {
+ compatible = "brcm,brcmstb-cpu-clk-div";
+ reg = <0xf03e257c 0x4>;
+ div-table = <0x00 1>;
+ div-shift-width = <0 5>;
+ #clock-cells = <0>;
+ clocks = <&cpupll>;
+ clock-names = "cpupll";
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index cfff2c9..690761d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2786,6 +2786,7 @@ M: bcm-kernel-feedback-list@broadcom.com
L: linux-pm@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt
+F: Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
F: drivers/cpufreq/brcmstb*
BROADCOM SPECIFIC AMBA DRIVER (BCMA)
--
2.7.4
^ permalink raw reply related
* [PATCH v5 0/2] cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs
From: Markus Mayer @ 2017-01-19 0:29 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Viresh Kumar, Rafael J . Wysocki, Arnd Bergmann
Cc: Device Tree List, Power Management List,
Linux Kernel Mailing List, Broadcom Kernel List, Markus Mayer,
Linux Clock List, ARM Kernel List
From: Markus Mayer <mmayer@broadcom.com>
This CPUfreq driver provides basic frequency scaling for older Broadcom
STB SoCs that do not use AVS firmware with DVFS support. There is no
support for voltage scaling.
v4 of this patch can be found at: https://patchwork.kernel.org/patch/9482357/
Changes since v4:
- Simplified (and hopefully clarified) binding document
- No code changes
v3 of this patch can be found at: https://lkml.org/lkml/2016/11/22/747
Changes since v3:
- added binding document
- got rid of calls to __clk_lookup(), using devm_clk_get() instead
- re-worked clock lookup code a bit, along with switching to devm_clk_get()
- get_frequencies() became a void function, removing the need for some
error checking
- fixed CONFIG_ARM_BRCM_AVS_CPUFREQ typo
- fixed MODULE_DEVICE_TABLE declaration
Markus Mayer (2):
dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs
.../bindings/clock/brcm,brcmstb-cpu-clk-div.txt | 27 ++
MAINTAINERS | 1 +
drivers/cpufreq/Kconfig.arm | 12 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/brcmstb-cpufreq.c | 377 +++++++++++++++++++++
5 files changed, 418 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
create mode 100644 drivers/cpufreq/brcmstb-cpufreq.c
--
2.7.4
^ permalink raw reply
* Re: [PATCH v5] ARM64: dts: meson-gx: Add firmware reserved memory zones
From: Andreas Färber @ 2017-01-19 0:20 UTC (permalink / raw)
To: Neil Armstrong, xypron.glpk, khilman, carlo
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <1484758245-9354-1-git-send-email-narmstrong@baylibre.com>
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@baylibre.com
> [2] http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstrong@baylibre.com
> [3] http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstrong@baylibre.com
> [4] http://lkml.kernel.org/r/1484128540-22662-1-git-send-email-narmstrong@baylibre.com
> [5] http://lkml.kernel.org/r/1484129414-23325-1-git-send-email-narmstrong@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
> + reg = <0x0 0x10000000 0x0 0x200000>;
> + no-map;
> + };
> + };
> +
> cpus {
> #address-cells = <0x2>;
> #size-cells = <0x0>;
Anyway, objection resolved,
Reviewed-by: Andreas Färber <afaerber@suse.de>
I don't expect breakage from these more confined additions, but I can
try to test tomorrow.
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 2/4] Documentation: dt: misc: Add Aspeed ast2400/2500 LPC Control bindings
From: Cyril Bur @ 2017-01-19 0:19 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
joel-U3u1mxZcP9KHXe+LvDLADg, mark.rutland-5wv7dgnIgG8,
openbmc-uLR06cmDAlY/bJ5BZ2RsiQ, andrew-zrmu5oMJ5Fs,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r, xow-hpIqsD4AKlfQT0dZR+AlfA,
jk-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <20170118211645.v54xvmxcsfzxior2@rob-hp-laptop>
On Wed, 2017-01-18 at 15:16 -0600, Rob Herring wrote:
> On Thu, Jan 12, 2017 at 11:29:08AM +1100, Cyril Bur wrote:
> > Signed-off-by: Cyril Bur <cyrilbur-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > .../devicetree/bindings/misc/aspeed-lpc-ctrl.txt | 78 ++++++++++++++++++++++
> > 1 file changed, 78 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/misc/aspeed-lpc-ctrl.txt
> >
> > diff --git a/Documentation/devicetree/bindings/misc/aspeed-lpc-ctrl.txt b/Documentation/devicetree/bindings/misc/aspeed-lpc-ctrl.txt
> > new file mode 100644
> > index 000000000000..f84ac83211ec
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/misc/aspeed-lpc-ctrl.txt
> > @@ -0,0 +1,78 @@
> > +ASpeed LPC Control
> > +==================
> > +This binding defines the LPC control for ASpeed SoCs. Partitions of
> > +the LPC bus can be access by other processors on the system, address
> > +ranges on the bus can map accesses from another processor to regions
> > +of the ASpeed SoC memory space.
> > +
> > +Reserved Memory:
> > +================
> > +The driver provides functionality to map the LPC bus to a region of
> > +ASpeed ram. A phandle to a reserved memory node must be provided so
> > +that the driver can safely use this region.
> > +
> > +Flash:
> > +======
> > +The driver provides functionality to unmap the LPC bus from ASpeed
> > +RAM, historically the default mapping has been to the SPI flash
> > +controller on the ASpeed SoC, a phandle to this node should be
> > +supplied.
> > +
> > +Device Node:
> > +============
> > +
> > +As LPC bus configuration registers are at the start of the LPC bus
> > +memory space, it makes most sense for the device to be within the LPC
> > +host node. See Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> > +for more information. This does not have to be the case, provided the
> > +reg property can give the full address of the LPC bus.
>
> Same comment here.
>
Hi Rob,
Yes, thanks.
> > +
> > +Required properties:
> > +--------------------
> > +
> > +- compatible: "aspeed,ast2400-lpc-ctrl" for ASpeed ast2400 SoCs
> > + "aspeed,ast2500-lpc-ctrl" for ASpeed ast2500 SoCs
> > +
> > +- reg: Location and size of the configuration registers
> > + for the LPC bus. Note that if the device node is
> > + within the LPC host node then base is relative to
> > + that.
> > +
> > +- memory-region: phandle of the reserved memory region
> > +- flash: phandle of the SPI flash controller
> > +
> > +Example:
> > +--------
> > +
> > +reserved-memory {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > +
> > + ...
> > +
> > + flash_memory: region@54000000 {
> > + compatible = "aspeed,ast2400-lpc-ctrl";
>
> This doesn't look right?
>
Correct, my mistake, I'll remove.
> > + no-map;
> > + reg = <0x54000000 0x04000000>; /* 64M */
>
> Is this system RAM? reserved-memory is generally for carveouts in system
> RAM (e.g. the memory node).
>
Yes it will be a chunk of system RAM. Our intended use case is to use
system ram to buffer host accesses to system flash (on the bmc). This
provides control over concurrent access to the flash and place to add
security measures to prevent the host from backdooring through the
flash. With the use of a protocol through the platform mailbox.
Having said that I don't want to limit myself to just that - there has
been other ideas for a host<->bmc ram buffer which may or may not see
the light of day.
I hope that makes sense,
Thanks for the review,
Cyril
> > + };
> > +};
> > +
> > +host_pnor: spi@1e630000 {
> > + reg = < 0x1e630000 0x18
> > + 0x30000000 0x02000000 >;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "aspeed,ast2400-smc";
> > +
> > + ...
> > +
> > +};
> > +
> > +lpc-ctrl@0 {
> > + compatible = "aspeed,ast2400-lpc-ctrl";
> > + memory-region = <&flash_memory>;
> > + flash = <&host_pnor>;
> > + reg = <0x0 0x80>;
> > +};
> > +
> > --
> > 2.11.0
> >
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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