Re: [PATCH V2 1/2] ARM: dts: DRA7: Add bandgap and related thermal nodes
On Tuesday 24 March 2015 01:09 AM, Nishanth Menon wrote:
From: Keerthy
Add bandgap and related thermal nodes. The patch adds 5 thermal
sensors. Only one cooling device for mpu as of now. The sensors are
the exact same on both dra72 and dra7. Introduce CPU, GPU, core nodes
for the moment as they are direct reuse of OMAP5 entities.
NOTE: OMAP4 has a finer counter granularity, which allows for a delay
of 1000ms in the thermal zone polling intervals. DRA7 have different
counter mechanism, which allows at maximum a 500ms timer. Adjust the
cpu thermal zone accordingly for DRA7.
Signed-off-by: Keerthy
[t-kri...@ti.com: few reuse from OMAP5 entities]
Signed-off-by: Tero Kristo
Signed-off-by: Nishanth Menon
---
Changes since V1:
- omap5-cpu-thermal.dtsi dropped
- approach similar to omap5
- added core and gpu thermal dtsi(they can be reused)
- Squashed patch #1 from v1 to patch #2 - this patch.
- Not carrying forward ack due to change
Thanks for updating Nishanth. Looks good to me.
- Keerthy
V1: http://marc.info/?t=14268810276&r=1&w=2
arch/arm/boot/dts/dra7.dtsi | 23 +++
arch/arm/boot/dts/dra72x.dtsi |5 +
arch/arm/boot/dts/dra74x.dtsi |5 +
3 files changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index eea4a54d6cb3..2d6a7e3e001f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -177,6 +177,18 @@
};
};
+ bandgap: bandgap@4a0021e0 {
+ reg = <0x4a0021e0 0xc
+ 0x4a00232c 0xc
+ 0x4a002380 0x2c
+ 0x4a0023C0 0x3c
+ 0x4a002564 0x8
+ 0x4a002574 0x50>;
+ compatible = "ti,dra752-bandgap";
+ interrupts = ;
+ #thermal-sensor-cells = <1>;
+ };
+
cm_core_aon: cm_core_aon@4a005000 {
compatible = "ti,dra7-cm-core-aon";
reg = <0x4a005000 0x2000>;
@@ -1419,6 +1431,17 @@
status = "disabled";
};
};
+
+ thermal_zones: thermal-zones {
+ #include "omap4-cpu-thermal.dtsi"
+ #include "omap5-gpu-thermal.dtsi"
+ #include "omap5-core-thermal.dtsi"
+ };
+
+};
+
+&cpu_thermal {
+ polling-delay = <500>; /* milliseconds */
};
/include/ "dra7xx-clocks.dtsi"
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index e5a3d23a3df1..6ac8e3601499 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -20,6 +20,11 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0>;
+
+ /* cooling options */
+ cooling-min-level = <0>;
+ cooling-max-level = <2>;
+ #cooling-cells = <2>; /* min followed by max */
};
};
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index 10173fab1a15..eef981f4bcd5 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -31,6 +31,11 @@
clock-names = "cpu";
clock-latency = <30>; /* From omap-cpufreq driver */
+
+ /* cooling options */
+ cooling-min-level = <0>;
+ cooling-max-level = <2>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu@1 {
device_type = "cpu";
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] arm: msm: Use timer DT node for qcom watchdog config
On 02/20, Mathieu Olivari wrote: > This change is done as a follow-up to the following thread: > https://lkml.org/lkml/2014/10/1/436 > > qcom-wdt is currently assuming the presence of a dedicated node in DT > to gets its configuration. However, on msm architecture, the watchdog is > usually part of the timer block. So this patch-set is changing the driver > and slightly enhancing the timer DT bindings to provide the relevant clocks > and interrupts. > > Mathieu Olivari (3): > watchdog: qcom: use timer devicetree binding > ARM: qcom: add description of KPSS WDT for IPQ8064 > ARM: msm: add watchdog entries to DT timer binding doc > > Documentation/devicetree/bindings/arm/msm/timer.txt | 16 +--- > arch/arm/boot/dts/qcom-ipq8064.dtsi | 14 +- > drivers/watchdog/qcom-wdt.c | 21 > +++-- > 3 files changed, 41 insertions(+), 10 deletions(-) > Can this patchset be applied? Or should we resend with collected acks? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] watchdog: digicolor: driver for Conexant Digicolor CX92755 SoC
On 03/26/2015 10:40 PM, Shubhrajyoti Datta wrote:
+
+static int dc_restart_handler(struct notifier_block *this, unsigned long
mode,
+ void *cmd)
+{
+ struct dc_wdt *wdt = container_of(this, struct dc_wdt,
restart_handler);
+
+ dc_wdt_set(wdt, 1);
+ /* wait for reset to assert... */
+ mdelay(500);
How is the 500 calculated ?
Also is it possible to sleep here?
sleep: No. It would also be pretty pointless, since this is after all the very
last step
of rebooting the system.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] watchdog: digicolor: driver for Conexant Digicolor CX92755 SoC
On 03/26/2015 12:59 AM, Baruch Siach wrote:
This commit add a driver for the watchdog functionality of the Conexant CX92755
SoC, from the Digicolor series of SoCs. Of 8 system timers provided by the
CX92755, the first one, timer A, can reset the chip when its counter reaches
zero. This driver uses this capability to provide userspace with a standard
watchdog, using the watchdog timer driver core framework. This driver also
implements a reboot handler for the reboot(2) system call.
The watchdog driver shares the timer registers with the CX92755 timer driver
(drivers/clocksource/timer-digicolor.c). The timer driver, however, uses only
timers other than A, so both drivers should coexist.
Signed-off-by: Baruch Siach
Almost there. Couple of nitpicks below.
Thanks,
Guenter
---
v2:
Address the comments of Guenter Roeck:
* Set default timeout to max_timeout
* Move watchdog timer set code to a helper routine to avoid code duplication
* Update watchdog timer on .set_timeout callback
* Fix iomap leak on error path
* Change restart registration error message to a warning
* Use devm_clk_get() to acquire the clock
---
drivers/watchdog/Kconfig | 10 ++
drivers/watchdog/Makefile| 1 +
drivers/watchdog/digicolor_wdt.c | 206 +++
3 files changed, 217 insertions(+)
create mode 100644 drivers/watchdog/digicolor_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 16f202350997..7d73d6c78cf6 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -515,6 +515,16 @@ config MEDIATEK_WATCHDOG
To compile this driver as a module, choose M here: the
module will be called mtk_wdt.
+config DIGICOLOR_WATCHDOG
+ tristate "Conexant Digicolor SoCs watchdog support"
+ depends on ARCH_DIGICOLOR
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for the watchdog timer
+ in Conexant Digicolor SoCs.
+ To compile this driver as a module, choose M here: the
+ module will be called digicolor_wdt.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 5c19294d1c30..0721f10e8d13 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_BCM_KONA_WDT) += bcm_kona_wdt.o
obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
obj-$(CONFIG_MESON_WATCHDOG) += meson_wdt.o
obj-$(CONFIG_MEDIATEK_WATCHDOG) += mtk_wdt.o
+obj-$(CONFIG_DIGICOLOR_WATCHDOG) += digicolor_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/digicolor_wdt.c b/drivers/watchdog/digicolor_wdt.c
new file mode 100644
index ..99981c54c1b9
--- /dev/null
+++ b/drivers/watchdog/digicolor_wdt.c
@@ -0,0 +1,206 @@
+/*
+ * Watchdog driver for Conexant Digicolor
+ *
+ * Copyright (C) 2015 Paradox Innovation Ltd.
+ *
+ * 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; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TIMER_A_CONTROL0
+#define TIMER_A_COUNT 4
+
+#define TIMER_A_ENABLE_COUNT BIT(0)
+#define TIMER_A_ENABLE_WATCHDOGBIT(1)
+
+struct dc_wdt {
+ void __iomem*base;
+ struct clk *clk;
+ struct notifier_block restart_handler;
+ spinlock_t lock;
+};
+
+static unsigned timeout;
+module_param(timeout, uint, 0);
+MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds");
+
+static void dc_wdt_set(struct dc_wdt *wdt, u32 ticks)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&wdt->lock, flags);
+
+ writel_relaxed(0, wdt->base + TIMER_A_CONTROL);
+ writel_relaxed(ticks, wdt->base + TIMER_A_COUNT);
+ writel_relaxed(TIMER_A_ENABLE_COUNT | TIMER_A_ENABLE_WATCHDOG,
+ wdt->base + TIMER_A_CONTROL);
+
+ spin_unlock_irqrestore(&wdt->lock, flags);
+}
+
+static int dc_restart_handler(struct notifier_block *this, unsigned long mode,
+ void *cmd)
+{
+ struct dc_wdt *wdt = container_of(this, struct dc_wdt, restart_handler);
+
+ dc_wdt_set(wdt, 1);
+ /* wait for reset to assert... */
+ mdelay(500);
+
+ return NOTIFY_DONE;
+}
+
+static int dc_wdt_start(struct watchdog_device *wdog)
+{
+ struct dc_wdt *wdt = watchdog_get_drvdata(wdog);
+
+ dc_wdt_set(wdt, wdog->timeout * clk_get_rate(wdt->clk));
+
+ return 0;
+}
+
+static int dc_wdt_stop(struct watchdog_device *wdog)
+{
+ struct dc_wdt *wdt = watchdog_get_drvdata(wdog);
+
+ writel_relaxed(0, wdt->base + TIMER_A_CONTROL);
+
+ return 0;
+}
+
+static int dc_w
[PATCH 1/2] phy: dt-binding: document Conexant Digicolor USB PHY
Add a device tree binding documentation to the USB PHY hardware block on the
Conexant CX92755 SoC. The CX92755 is one of the Digicolor SoCs series. Other
SoCs in that series may share the same hardware block.
Signed-off-by: Baruch Siach
---
.../devicetree/bindings/phy/digicolor-usb-phy.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/digicolor-usb-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/digicolor-usb-phy.txt
b/Documentation/devicetree/bindings/phy/digicolor-usb-phy.txt
new file mode 100644
index ..089f218c59c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/digicolor-usb-phy.txt
@@ -0,0 +1,15 @@
+Conexant Digicolor USB2 PHY
+
+Required properties:
+ - compatible: cnxt,cx92755-usbphy
+ - reg: offset and length of the PHY registers
+ - #phy-cells: must be 0
+Refer to phy-bindings.txt for the generic PHY binding properties
+
+Example:
+
+ usb_phy0: usb-phy@f0084000 {
+ compatible = "cnxt,cx92755-usbphy";
+ reg = <0xf0084000 0x100>;
+ #phy-cells = <0>;
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] phy: driver for Conexant Digicolor internal USB PHY
Add a driver for the USB PHY on the Conexant CX92755 SoC, from the Digicolor
series of SoCs. The PHY is connected to the on-chip chipidea usb2 host.
The hardware is somewhat similar to the phy-mxs-usb.c usb_phy, but it is
different enough to merit its own driver. Also, this driver uses the generic
phy infrastructure.
Cc: Marek Vasut
Cc: Richard Zhao
Signed-off-by: Baruch Siach
---
drivers/phy/Kconfig | 9 ++
drivers/phy/Makefile| 1 +
drivers/phy/phy-digicolor-usb.c | 209
3 files changed, 219 insertions(+)
create mode 100644 drivers/phy/phy-digicolor-usb.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2962de205ba7..9589056ef5c7 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -291,4 +291,13 @@ config PHY_QCOM_UFS
help
Support for UFS PHY on QCOM chipsets.
+config PHY_DIGICOLOR_USB
+ tristate "Conexant Digicolor USB2 PHY Driver"
+ depends on ARCH_DIGICOLOR
+ select GENERIC_PHY
+ select USB_PHY
+ help
+ Enable this to support the USB 2.0 PHY that is part of Conexant
+ Digicolor SoC series.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f080e1bb2a74..392cb60d0240 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
+obj-$(CONFIG_PHY_DIGICOLOR_USB)+= phy-digicolor-usb.o
diff --git a/drivers/phy/phy-digicolor-usb.c b/drivers/phy/phy-digicolor-usb.c
new file mode 100644
index ..a1d7503530a0
--- /dev/null
+++ b/drivers/phy/phy-digicolor-usb.c
@@ -0,0 +1,209 @@
+/*
+ * Conexant Digicolor Integrated USB PHY driver
+ *
+ * Copyright (C) 2014, 2015 Paradox Innovation Ltd.
+ *
+ * Author: Baruch Siach
+ *
+ * Based on phy-mxs-usb.c.
+ *
+ * Copyright 2012-2014 Freescale Semiconductor, Inc.
+ * Copyright (C) 2012 Marek Vasut
+ * on behalf of DENX Software Engineering GmbH
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME "digicolor_usb_phy"
+
+#define HW_USBPHY_PWD 0x00
+#define HW_USBPHY_TX 0x10
+#define HW_USBPHY_CTRL 0x30
+#define HW_USBPHY_CTRL_SET 0x34
+#define HW_USBPHY_CTRL_CLR 0x38
+
+#define HW_USBPHY_DEBUG0x50
+
+#define HW_USBPHY_IP 0x90
+#define HW_USBPHY_IP_SET 0x94
+#define HW_USBPHY_IP_CLR 0x98
+
+#define BM_USBPHY_CTRL_SFTRST BIT(31)
+#define BM_USBPHY_CTRL_CLKGATE BIT(30)
+#define BM_USBPHY_CTRL_ENHOSTDISCONDETECT BIT(1)
+
+#define BM_USBPHY_IP_EN_USB_CLKS BIT(2)
+#define BM_USBPHY_IP_PLL_LOCKEDBIT(1)
+#define BM_USBPHY_IP_PLL_POWER BIT(0)
+
+struct dc_usb_phy {
+ struct usb_phy phy;
+ struct device *dev;
+ void __iomem*regs;
+};
+
+static int digicolor_phy_init(struct phy *gphy)
+{
+ struct dc_usb_phy *phy = phy_get_drvdata(gphy);
+
+ /* Disable PLL */
+ writel(BM_USBPHY_IP_EN_USB_CLKS, phy->regs + HW_USBPHY_IP_CLR);
+ udelay(250);
+ writel(BM_USBPHY_IP_PLL_LOCKED, phy->regs + HW_USBPHY_IP_CLR);
+ udelay(250);
+ writel(BM_USBPHY_IP_PLL_POWER, phy->regs + HW_USBPHY_IP_CLR);
+ udelay(250);
+
+ /* Reset PHY */
+ writel(BM_USBPHY_CTRL_SFTRST, phy->regs + HW_USBPHY_CTRL_SET);
+ udelay(1000);
+ writel(BM_USBPHY_CTRL_SFTRST, phy->regs + HW_USBPHY_CTRL_CLR);
+ udelay(1000);
+
+ /* Enable PHY clock */
+ writel(BM_USBPHY_CTRL_CLKGATE, phy->regs + HW_USBPHY_CTRL_CLR);
+ udelay(250);
+
+ /* Enable PLL */
+ writel(BM_USBPHY_IP_PLL_POWER, phy->regs + HW_USBPHY_IP_SET);
+ udelay(250);
+ writel(BM_USBPHY_IP_PLL_LOCKED, phy->regs + HW_USBPHY_IP_SET);
+ udelay(250);
+ writel(BM_USBPHY_IP_EN_USB_CLKS, phy->regs + HW_USBPHY_IP_SET);
+ udelay(250);
+
+ /* Power PHY up */
+ writel(0, phy->regs + HW_USBPHY_PWD);
+ udelay(250);
+
+ /* Set resistors parameters (power up default values) */
+ writel(0x10060607, phy->regs + HW_USBPHY_TX);
+ writel(0x7f18, phy->regs + HW_USBPHY_DEBUG);
+
+ return 0;
+}
+
+static int digicolor_phy_shutdown(struct phy *gphy)
+{
+ struct dc_usb_phy *phy
Re: [U-Boot] serial atag tag in devicetree ?
On Thu, Mar 26, 2015 at 4:11 AM, Paul Kocialkowski wrote: > Le jeudi 26 mars 2015 à 09:53 +0100, Hans de Goede a écrit : >> Hi, >> >> On 25-03-15 23:35, Paul Kocialkowski wrote: >> > Le mardi 24 mars 2015 à 09:01 +0100, Hans de Goede a écrit : >> >> Hi, >> >> >> >> On 24-03-15 00:12, Rob Herring wrote: >> >>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede >> >>> wrote: >> Hi, >> >> >> On 22-03-15 22:01, Rob Herring wrote: >> >> >> >> >> >> >> > There is already "serial-number" (a string) which exists for >> > OpenFirmware. Also, "copyright" corresponds to vendor/manufacturer >> > string. Both of these are supported by lshw already. >> >> >> Ok, so if I understand you correctly then you're saying that we >> should set a "serial-number" string property at the dt root level >> and that this may contain pretty much anything, e.g. in the >> sunxi case the full 128 bit SID in hex. >> >>> >> >>> Right. >> >>> >> Is the use of the "serial-number" string property already documented >> somewhere? If not I'll submit a kernel patch to document it. >> >>> >> >>> Not that I'm aware of. It is something that predates our documentation >> >>> requirements. It could be in OpenFirmware specs. Documenting it in the >> >>> DT bindings does not hurt. >> >> >> >> Ok. >> >> >> And for older kernels we should not set any serial atag (u-boot >> always sets it, so this leaves it at 0) and old kernel users are >> out of luck wrt getting to the serial ? >> >>> >> >>> If there is sufficient reason to support this on old kernels you could. >> >> >> >> One problem with supporting this for older kernels is that if a non 0 >> >> serial gets shown in /proc/cpuinfo with older atag booted kernels, we >> >> should really show the same number in /proc/cpuinfo which means adding >> >> code to the kernel to get the devicetree "serial-number" string property >> >> and somehow put that into the 64 bits which we have in /proc/cpuinfo, >> >> but given that the "serial-number" string could be hex or decimal or >> >> what ever and > 64 bits that will likely require a platform specific >> >> solution. All doable, but the question then becomes is this worth the >> >> effort ? >> > >> > After investigating a bit more, I found out that the USB serial number >> > is expected to be a string of 32 bytes, so a 128 bit numeric serial >> > doesn't fit (it takes 32 bytes for the hex representation of 128 bits, >> > so there is no room left for the terminating null byte), hence it makes >> > sense to keep a 64 bit limitation for the serial number, if users are >> > going to rely on it as USB serial string. Moreover, it seems that >> > Android devices are mostly used 64 bit numbers for serial numbers/ >> > >> > I was initially going to suggest that we set it in stone that serial >> > must be 64 numeric bits (as it was in the ATAGs days) and that >> > bootloaders would pass it that way to the kernel through device tree >> > (with two 32 bits numeric integers), but Hans talked me out of it. >> > I just want to expose the situation (especially the USB and Android >> > thing) here to double-check that everyone still is convinced that a >> > string approach in device tree is best (which is fine with me). >> >> There are already existing users of the serial-number property in devicetree, >> and these already use a free-format string, so AFAICT we have no choice >> but to do the same as the existing users. >> >> But Rob is the expert here, so lets see what Rob has to say. >> >> > This way, users that still want to use the serial passed through device >> > tree as a USB serial number will have to use a string of 32 bits, >> > including the null terminating byte (which is what I'll suggest for >> > sunxi by using only 64 bits for the serial number). >> > >> > Also, I suggest that we show that serial-number string as-is in cpuinfo >> > as well >> >> We cannot do that because we must guarantee that the serial shown >> in cpu info is a 64 bits / 16 hex values (0 padded) number, anything >> else would break the kernel <-> userspace API and potentially break >> userspace apps. So we must do the devicetree -> serialnumber low/high >> -> /proc/cpinfo version to guarantee that this format does not change. >> >> And as discussed before if you want a non 0 serial in cpuinfo then >> the devicetree -> serialnumber low/high should be done in sunxi >> specific kernel code, as on sunxi we will know that the string in >> devicetree will be a hex value, but we've no such guarantee for >> other platforms, so we cannot simply have a generic function to >> populate erialnumber low/high from the devicetree serial-number >> string. >> >> > and instead make a string out of the serial ATAG in the kernel >> > prior to showing it in cpuinfo (as opposed to translating the string >> > coming from device tree to a numeric value that cpuinfo will end up >> > showing as a string at the end of the day). Thus, the s
Re: [PATCH 3/4] clk: hisi: add stub clk driver
On Thu, Mar 26, 2015 at 02:22:26PM +, Russell King - ARM Linux wrote:
> On Thu, Mar 26, 2015 at 07:13:38PM +0800, Leo Yan wrote:
> > +static unsigned long hisi_stub_clk_recalc_rate(struct clk_hw *hw,
> > + unsigned long parent_rate)
> > +{
> ...
> > + BUG_ON(!stub_clk->lock);
> ...
>
> > +static int hisi_stub_clk_set_rate(struct clk_hw *hw, unsigned long rate,
> > +unsigned long parent_rate)
> > +{
> ...
> > + BUG_ON(!stub_clk->lock);
> ...
>
> > +static long hisi_stub_clk_round_rate(struct clk_hw *hw, unsigned long rate,
> > + unsigned long *parent_rate)
> > +{
> ...
> > + BUG_ON(!stub_clk->lock);
> ...
>
> > +static struct clk_ops hisi_stub_clk_ops = {
> > + .recalc_rate= hisi_stub_clk_recalc_rate,
> > + .round_rate = hisi_stub_clk_round_rate,
> > + .set_rate = hisi_stub_clk_set_rate,
> > +};
> ...
> > +static struct clk *_register_stub_clk(struct device *dev, unsigned int id,
> > + const char *name, const char *parent_name, unsigned long flags,
> > + spinlock_t *lock)
> > +{
> > + struct hisi_stub_clk *stub_clk;
> > + struct clk *clk;
> > + struct clk_init_data init;
> > +
> > + stub_clk = kzalloc(sizeof(*stub_clk), GFP_KERNEL);
> > + if (!stub_clk) {
> > + pr_err("%s: fail to alloc stub clk!\n", __func__);
> > + return ERR_PTR(-ENOMEM);
> > + }
> > +
> > + init.name = name;
> > + init.ops = &hisi_stub_clk_ops;
> > + init.parent_names = parent_name ? &parent_name : NULL;
> > + init.num_parents = parent_name ? 1 : 0;
> > + init.flags = flags;
> > +
> > + stub_clk->hw.init = &init;
> > + stub_clk->id = id;
> > + stub_clk->lock = lock;
>
> Under what scenario is it safe to call _register_stub_clk() with a NULL
> lock argument?
>
> If lock is NULL, then every function callable via the ops structure
> will bug.
>
> Rather than doing a test in each method function, do it in
> _register_stub_clk() - this means we aren't waiting for a NULL pointer
> deref when one of these method functions gets called.
Will fix to check lock pointer in the function _register_stub_clk().
Thanks,
Leo Yan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] clk: hisi: add API for allocation clk data struct
hi Russell,
On Thu, Mar 26, 2015 at 02:18:34PM +, Russell King - ARM Linux wrote:
> On Thu, Mar 26, 2015 at 07:13:36PM +0800, Leo Yan wrote:
> > +struct hisi_clock_data __init *hisi_clk_init(struct device_node *np,
> > +int nr_clks)
> > +{
> > + struct hisi_clock_data *clk_data;
> > + void __iomem *base;
> > +
> > + if (np) {
> > + base = of_iomap(np, 0);
> > + if (!base) {
> > + pr_err("failed to map Hisilicon clock registers\n");
> > + return NULL;
> > + }
> > + printk("%s: base %p\n", __func__, base);
>
> Did you leave your debugging in?
Sorry, will remove it.
> > + } else {
> > + pr_err("failed to find Hisilicon clock node in DTS\n");
> > + return NULL;
> > + }
>
> I know you're mostly only moving this code, but it would be far better if
> it were written:
>
> if (!np) {
> pr_err("failed to find Hisilicon clock node in DTS\n");
> return NULL;
> }
>
> base = of_iomap(np, 0);
> if (!base) {
> pr_err("failed to map Hisilicon clock registers\n");
> return NULL;
> }
>
> Possibly do this first as a separate patch, and then move the code.
Will do this.
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DT: leds: Add uniqueness requirement for 'label' property.
On Thu, Mar 26, 2015 at 1:59 PM, Sakari Ailus wrote: > Hi Jacek, > > Jacek Anaszewski wrote: >> Label is used for naming LED class devices. Since ePAPR >> doesn't require uniqueness for label properties, it has to be >> explicitly required in the LEDs common bindings documentation. >> >> Signed-off-by: Jacek Anaszewski >> Acked-by: Kyungmin Park >> Cc: Bryan Wu >> Cc: Richard Purdie >> Cc: Sakari Ailus >> Cc: devicetree@vger.kernel.org > > Thanks for the patch! > > Acked-by: Sakari Ailus > Looks good to me, I will merge it. -Bryan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] spi/rockchip: Round up clock rate divisor to err on the safe side
On Thu, Mar 26, 2015 at 04:30:24PM -0700, Julius Werner wrote: > The Rockchip SPI driver currently calculates its clock rate divisor by > integer dividing the parent rate by the target rate, and then rounding > the result up to the next even number (since the divisor must be > even). Applied both, thanks. signature.asc Description: Digital signature
Re: [PATCH 2/2] spi/rockchip: Add device tree property to configure Rx Sample Delay
Julius, On Thu, Mar 26, 2015 at 4:30 PM, Julius Werner wrote: > We have found that we can sometimes see read failures on boards with > high-capacitance SPI lines. It seems that the controller samples the Rx > data line too early, and its register interface has an "Rx Sample Delay" > setting to fine-tune against this issue. > > This patch adds a new optional device tree entry that can configure this > delay in terms of nanoseconds. The kernel will calculate the > best-fitting amount of parent clock ticks to program the controller with > based on that. > > Signed-off-by: Julius Werner > --- > .../devicetree/bindings/spi/spi-rockchip.txt| 4 > drivers/spi/spi-rockchip.c | 21 > + > 2 files changed, 25 insertions(+) Reviewed-by: Doug Anderson -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] spi/rockchip: Round up clock rate divisor to err on the safe side
Julius, On Thu, Mar 26, 2015 at 4:30 PM, Julius Werner wrote: > The Rockchip SPI driver currently calculates its clock rate divisor by > integer dividing the parent rate by the target rate, and then rounding > the result up to the next even number (since the divisor must be > even). > > Clock rate divisors should always be rounded up, so that the resulting > frequency is lower or equal to the target. This is correctly done in the > second step here but not in the first, so we still have a risk of > exceeding the desired target frequency (e.g. setting spi-max-frequency > to 4000 with a parent clock of 9900 could lead to a divisor of > 9900 / 4000 == 2 (which is even) that then results in an > effective frequency of 9900 / 2 == 4950 (potentially exceeding > the flash chip's specifications). > > This patch changes the division to round up to fix this problem. > > Signed-off-by: Julius Werner > --- > drivers/spi/spi-rockchip.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Doug Anderson -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/5] power: max77843_charger: Add Max77843 charger device driver
On 03/26/2015 10:54 PM, Lee Jones wrote: > On Thu, 26 Mar 2015, Beomho Seo wrote: >> On 03/24/2015 05:38 PM, Krzysztof Kozlowski wrote: >>> 2015-03-24 9:01 GMT+01:00 Beomho Seo : On 03/10/2015 10:44 PM, Beomho Seo wrote: > On 03/09/2015 09:13 PM, Krzysztof Kozlowski wrote: >> On pon, 2015-03-09 at 20:46 +0900, Beomho Seo wrote: >>> On 03/09/2015 08:02 PM, Krzysztof Kozlowski wrote: 2015-03-09 1:35 GMT+01:00 Beomho Seo : > On 03/08/2015 05:13 AM, Sebastian Reichel wrote: >> On Mon, Mar 02, 2015 at 07:10:35PM +0900, Jaewon Kim wrote: >>> From: Beomho Seo >>> >>> This patch adds device driver of max77843 charger. This driver >>> provide >>> initialize each charging mode(e.g. fast charge, top-off mode and >>> constant >>> charging mode so on.). Additionally, control charging paramters to >>> use >>> i2c interface. >>> >>> Cc: Sebastian Reichel >>> Signed-off-by: Beomho Seo >> >> Reviewed-By: Sebastian Reichel >> >> I can't take it as is, since it depends on the private header file >> of PATCHv1. >> >> -- Sebastian >> > > This patch reviewed by Sebastian. > Could you Please merge that your git tree ? Hi, ... and again we are adding a new driver for very similar chipset to already supported. I looked at spec and the charger's registers are almost the same as for max77693. Their layout and addresses are the same. I see some minor differences, probably the most important would be different values current (fast-charge, top-off). But still 90% of registers are the same... Do we really have to add new driver? Best regards, Krzysztof >>> >>> Hi, >>> >>> Thank you for your comment. As you say, both chip set are similar. >>> But new driver need for support max77843. It is support different below >>> - Provide Battery presence information. >> >> Another set of power supply properties could be added for that chip. >> This way the get_property() function would be the same but actually the >> POWER_SUPPLY_PROP_PRESENT won't be called for max77693. >> >>> - Can OTG FET control. >> >> Where the OTG FET feature is it enabled in your driver? I couldn't find >> it. >> > > Sorry. This driver don't control OTG FET feature. > >>> - Bigger Fast charge current, Top Off current Threshold selection. >>> - Various and bigger OTG current limitation. >>> - Bigger primary charger termination voltage setting. >>> - Different maximum input current limit selection(Different step). >> >> Yes, I mentioned some of these differences (the Fast/top-off >> differences). These are differences in values so it does not require new >> driver. There is need to develop new driver just to support different >> current (3.0 A instead of 2.1 A) or voltage threshold. >> > > They are different charging current, OTG current limitation, top off > current, > charging limitation value. In case OTG current limitation different not > limitation value but using register bit(max77843 use[7:6] max77693 use[7] > bit only). Even if this driver not support all feature, some register > different with max77693(support value, use register bit). > > If this driver will combined with max77693 may even be beneficial for > new Maxim driver. But the present, this driver is related with > max77843 core driver and max77843-regulator. So I hope this driver > merge first. And then will extend two driver(max77843 charger and > max77693 charger). >>> >>> I still prefer merging common drivers into one instead of creating >>> some more of them. >>> However I understand your point and I am not entirely opposed against. >>> Especially that you invested quite a bit of time for developing this >>> and my feedback was quite late. To summarize I am fine with your >>> approach. >>> >>> Best regards, >>> Krzysztof >>> >> >> Dear Lee Jones, >> >> Could you please merge that your git tree ? > > Sorry, I'm lost. Why am I taking this though the MFD tree? What > patches are left? Where are they going? Am I taking any other > patches? > Max77843 charger driver is max77843 mfd core dependency. If you think this patch will suitable for battery tree(or other tree), I would like request for merge battery tree. Also, I will send again this patch and device tree binding document. Best regards, Beomho Seo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/4] mfd: lubbock_cplds: add lubbock IO board
On Thu, Mar 26, 2015 at 10:38:54PM +0100, Robert Jarzmik wrote: > Greg Kroah-Hartman writes: > > > On Fri, Feb 20, 2015 at 05:02:57PM +0100, Robert Jarzmik wrote: > >> If there is no solution, I'll fallback through arch/arm/plat-pxa, not very > >> nice, > >> but it has to land somewhere, I don't want lubbock to remain broken. > > > > drivers/platform/arm ? > Most certainly. > > I'll submit that to drivers/platform/arm/pxa, and maintain that pxa tree. As > for > drivers/platform/arm, do you want also maintainers to step up, or will you > take > the review/merge burden ? I have enough review/merge burden to do anything with ARM, sorry. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] spi/rockchip: Round up clock rate divisor to err on the safe side
The Rockchip SPI driver currently calculates its clock rate divisor by integer dividing the parent rate by the target rate, and then rounding the result up to the next even number (since the divisor must be even). Clock rate divisors should always be rounded up, so that the resulting frequency is lower or equal to the target. This is correctly done in the second step here but not in the first, so we still have a risk of exceeding the desired target frequency (e.g. setting spi-max-frequency to 4000 with a parent clock of 9900 could lead to a divisor of 9900 / 4000 == 2 (which is even) that then results in an effective frequency of 9900 / 2 == 4950 (potentially exceeding the flash chip's specifications). This patch changes the division to round up to fix this problem. Signed-off-by: Julius Werner --- drivers/spi/spi-rockchip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c index 1a777dc..5e4e52c 100644 --- a/drivers/spi/spi-rockchip.c +++ b/drivers/spi/spi-rockchip.c @@ -519,7 +519,7 @@ static void rockchip_spi_config(struct rockchip_spi *rs) } /* div doesn't support odd number */ - div = max_t(u32, rs->max_freq / rs->speed, 1); + div = DIV_ROUND_UP(rs->max_freq, rs->speed); div = (div + 1) & 0xfffe; writel_relaxed(cr0, rs->regs + ROCKCHIP_SPI_CTRLR0); -- 2.1.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] spi/rockchip: Add device tree property to configure Rx Sample Delay
We have found that we can sometimes see read failures on boards with
high-capacitance SPI lines. It seems that the controller samples the Rx
data line too early, and its register interface has an "Rx Sample Delay"
setting to fine-tune against this issue.
This patch adds a new optional device tree entry that can configure this
delay in terms of nanoseconds. The kernel will calculate the
best-fitting amount of parent clock ticks to program the controller with
based on that.
Signed-off-by: Julius Werner
---
.../devicetree/bindings/spi/spi-rockchip.txt| 4
drivers/spi/spi-rockchip.c | 21 +
2 files changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
index 467dec4..0c491bd 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
@@ -24,6 +24,9 @@ Optional Properties:
- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
Documentation/devicetree/bindings/dma/dma.txt
- dma-names: DMA request names should include "tx" and "rx" if present.
+- rx-sample-delay-ns: nanoseconds to delay after the SCLK edge before sampling
+ Rx data (may need to be fine tuned for high capacitance lines).
+ No delay (0) by default.
Example:
@@ -33,6 +36,7 @@ Example:
reg = <0xff11 0x1000>;
dmas = <&pdma1 11>, <&pdma1 12>;
dma-names = "tx", "rx";
+ rx-sample-delay-ns = <10>;
#address-cells = <1>;
#size-cells = <0>;
interrupts = ;
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 5e4e52c..f89cd5d 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -179,6 +179,7 @@ struct rockchip_spi {
u8 tmode;
u8 bpw;
u8 n_bytes;
+ u8 rsd_nsecs;
unsigned len;
u32 speed;
@@ -493,6 +494,7 @@ static void rockchip_spi_config(struct rockchip_spi *rs)
{
u32 div = 0;
u32 dmacr = 0;
+ int rsd = 0;
u32 cr0 = (CR0_BHT_8BIT << CR0_BHT_OFFSET)
| (CR0_SSD_ONE << CR0_SSD_OFFSET);
@@ -522,6 +524,20 @@ static void rockchip_spi_config(struct rockchip_spi *rs)
div = DIV_ROUND_UP(rs->max_freq, rs->speed);
div = (div + 1) & 0xfffe;
+ /* Rx sample delay is expressed in parent clock cycles (max 3) */
+ rsd = DIV_ROUND_CLOSEST(rs->rsd_nsecs * (rs->max_freq >> 8),
+ 10 >> 8);
+ if (!rsd && rs->rsd_nsecs) {
+ pr_warn_once("rockchip-spi: %u Hz are too slow to express %u ns
delay\n",
+rs->max_freq, rs->rsd_nsecs);
+ } else if (rsd > 3) {
+ rsd = 3;
+ pr_warn_once("rockchip-spi: %u Hz are too fast to express %u ns
delay, clamping at %u ns\n",
+rs->max_freq, rs->rsd_nsecs,
+rsd * 10U / rs->max_freq);
+ }
+ cr0 |= rsd << CR0_RSD_OFFSET;
+
writel_relaxed(cr0, rs->regs + ROCKCHIP_SPI_CTRLR0);
writel_relaxed(rs->len - 1, rs->regs + ROCKCHIP_SPI_CTRLR1);
@@ -614,6 +630,7 @@ static int rockchip_spi_probe(struct platform_device *pdev)
struct rockchip_spi *rs;
struct spi_master *master;
struct resource *mem;
+ u32 rsd_nsecs;
master = spi_alloc_master(&pdev->dev, sizeof(struct rockchip_spi));
if (!master)
@@ -665,6 +682,10 @@ static int rockchip_spi_probe(struct platform_device *pdev)
rs->dev = &pdev->dev;
rs->max_freq = clk_get_rate(rs->spiclk);
+ if (!of_property_read_u32(pdev->dev.of_node, "rx-sample-delay-ns",
+ &rsd_nsecs))
+ rs->rsd_nsecs = rsd_nsecs;
+
rs->fifo_len = get_fifo_len(rs);
if (!rs->fifo_len) {
dev_err(&pdev->dev, "Failed to get fifo length\n");
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alert
-- We have your donation reply for details -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 2/3] Phy: DT binding documentation for Broadcom Cygnus USB PHY driver
Hi Arun,
On Wed, Mar 25, 2015 at 05:04:57PM -0700, Arun Ramamurthy wrote:
>
>
> On 15-03-25 03:16 PM, Kishon Vijay Abraham I wrote:
> >Hi,
> >
> >On Saturday 21 March 2015 02:55 AM, Arun Ramamurthy wrote:
> >>Broadcom's Cygnus chip has a USB 2.0 host controller connected to
> >>three separate phys. One of the phs (port 2) is also connectd to
> >>a usb 2.0 device controller
> >>
> >>Reviewed-by: Ray Jui
> >>Reviewed-by: Scott Branden
> >>Signed-off-by: Arun Ramamurthy
> >>
> >>---
> >> .../bindings/phy/brcm,cygnus-usb-phy.txt | 65
> >> ++
> >> 1 file changed, 65 insertions(+)
> >> create mode 100644
> >> Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt
> >>
> >>diff --git a/Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt
> >>b/Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt
> >>new file mode 100644
> >>index 000..002bd59
> >>--- /dev/null
> >>+++ b/Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt
> >>@@ -0,0 +1,65 @@
> >>+BROADCOM CYGNUS USB PHY
> >>+
> >>+Required Properties:
> >>+ - compatible: brcm,cygnus-usb-phy
> >>+ - reg : usbphy_regs - Base address of phy registers
> >>+ usb2h_idm_regs - Base address of host idm registers
> >>+ usb2d_idm_regs - Base address of device idm registers
> >
> >where is #phy-cells documented?
> I dont follow, isnt phy-cells a standard binding, what documentation
> is required?
> >>+The node that uses the phy must provide one integers, 0 for device and 1
> >>for host
> >
"The node that uses phy must specify whether it should be configured as
host or device in the second cell of phy specification."
By the way, can we use not integers but symbolic constants for host and
device mode?
> >>+
> >>+NOTE: port 0 and port 1 are host only and port 2 can be configured for
> >>host or device.
> >>+
> >>+Example of phy :
> >>+ usbphy0: usbphy@0x0301c000 {
> >>+ compatible = "brcm,cygnus-usb-phy";
> >>+ reg = <0x0301c000 0x2000>,
> >>+ <0x18115000 0x1000>,
> >>+ <0x18111000 0x1000>;
> >>+ status = "okay";
> >>+
> >>+ #address-cells = <1>;
> >>+ #size-cells = <0>;
> >>+ usbphy0_0: usbphy0@0 {
> >>+ #phy-cells = <1>;
> >>+ reg = <0>;
> >>+ status = "okay";
> >>+ phy-supply = <&vbus_p0>;
> >>+ };
> >>+
> >>+ usbphy0_1: usbphy0@1 {
> >>+ #phy-cells = <1>;
> >>+ reg = <1>;
> >>+ status = "okay";
> >>+ };
> >>+
> >>+ usbphy0_2: usbphy0@2 {
> >>+ #phy-cells = <1>;
> >>+ reg = <2>;
> >>+ status = "okay";
> >>+ phy-supply = <&vbus_p2>;
> >>+ };
> >>+ };
> >>+
> >>+Example of node using the phy:
> >>+
> >>+ /* This nodes declares all three ports as host */
> >>+
> >>+ ehci0: usb@0x18048000 {
> >>+ compatible = "generic-ehci";
> >>+ reg = <0x18048000 0x100>;
> >>+ interrupts = ;
> >>+ phys = <&usbphy0_0 1 &usbphy0_1 1 &usbphy0_2 1>;
> >>+ phy-names = "usb","usb","usb";
> >
> >is it on purpose you use the same name for phy-names? it is wrong though.
> Kishon, I did use the same names on purpose. The phy-names are
> actually irrelevant because I used the new api I created
> devm_of_phy_get_by_index. I actually wasnt sure if should take out
> the phy-name field altogether or leave it as phy-names = "usb" for
> compatibility with other bindings.
There is no issue of compatibility as existing mappings would only use 1
phy and we'll pick it up when getting phy by index. I think we should
simply drop phy-names altogether as driver does not use this property
anymore.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] add support for Freescale's MMA8653FC 10 bit accelerometer
On Sat, Mar 21, 2015 at 12:26:04PM +0100, Martin Kepplinger wrote: > From: Martin Kepplinger > > The MMA8653FC is a low-power, three-axis, capacitive micromachined > accelerometer with 10 bits of resolution with flexible user-programmable > options. > > Embedded interrupt functions enable overall power savings, by relieving the > host processor from continuously polling data, for example using the poll() > system call. > > The device can be configured to generate wake-up interrupt signals from any > combination of the configurable embedded functions, enabling the MMA8653FC > to monitor events while remaining in a low-power mode during periods of > inactivity. > > This driver provides devicetree properties to program the device's behaviour > and a simple, tested and documented sysfs interface. The data sheet and more > information is available on Freescale's website. > > Signed-off-by: Martin Kepplinger > Signed-off-by: Christoph Muellner > --- > > Still, I was missing the drivers/staging Makefile addition. This applies and > builds automatically. You sent 4 different copies of a "v5" patch, which kind of defeats the whole purpose of a "v" number... All of them now deleted from my todo queue, get it together and send a correct one, properly numbered. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/15] serial: stm32-usart: Add STM32 USART Driver
2015-03-26 16:46 GMT+01:00 Russell King - ARM Linux :
> On Tue, Mar 24, 2015 at 02:23:38PM -0400, Peter Hurley wrote:
>> Hi Maxime,
>>
>> On 03/12/2015 05:55 PM, Maxime Coquelin wrote:
>> > +static unsigned int stm32_get_mctrl(struct uart_port *port)
>> > +{
>> > + /*
>> > +* This routine is used for geting signals of: DTR, DCD, DSR, RI,
>> > +* and CTS/RTS
>
> It's also worth noting that this comment is wrong. This is used to get
> the state of DCD, DSR, RI and CTS. DTR and RTS are *not* included
> because the core tracks their state.
OK, thanks for pointing this.
I will fix the comment in the v4.
>
> ...
>
>> > + stm32port->clk = devm_clk_get(&pdev->dev, NULL);
>> > +
>> > + if (WARN_ON(IS_ERR(stm32port->clk)))
>>
>> Do you really need a stack trace here? Could this be dev_err() instead?
>>
>> > + return -EINVAL;
>
> Also, propagate the error code.
Ok.
>
>> > +
>> > + /* ensure that clk rate is correct by enabling the clk */
>> > + clk_prepare_enable(stm32port->clk);
>
> And remember to check the return value of clk_prepare_enable().
I will.
Thanks for the review,
Maxime
>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/15] serial: stm32-usart: Add STM32 USART Driver
HI Peter
2015-03-24 19:23 GMT+01:00 Peter Hurley :
> Hi Maxime,
>
> On 03/12/2015 05:55 PM, Maxime Coquelin wrote:
>> From: Maxime Coquelin
>>
>> This drivers adds support to the STM32 USART controller, which is a
>> standard serial driver.
>
> Comments below.
Thanks for the review, please find my answsers below
>
>> Signed-off-by: Maxime Coquelin
>> ---
>> drivers/tty/serial/Kconfig | 17 +
>> drivers/tty/serial/Makefile | 1 +
>> drivers/tty/serial/stm32-usart.c | 695
>> +++
>> include/uapi/linux/serial_core.h | 3 +
>> 4 files changed, 716 insertions(+)
>> create mode 100644 drivers/tty/serial/stm32-usart.c
>>
...
>> +static unsigned int stm32_tx_empty(struct uart_port *port)
>> +{
>> + return readl_relaxed(port->membase + USART_SR) & USART_SR_TXE;
>> +}
>> +
>> +static void stm32_set_mctrl(struct uart_port *port, unsigned int mctrl)
>> +{
>> + /*
>> + * This routine is used for seting signals of: DTR, DCD, CTS/RTS
>> + * We use USART's hardware for CTS/RTS, so don't need any for that.
>
> If this means that you're enabling autoflow control, then you still need
> to respond to the state of TIOCM_RTS, so that both serial core and userspace
> can halt input flow.
>
> If the hardware doesn't support separate RTS enable/disable control,
> then you need to disable autoRTS when TIOCM_RTS is clear, and re-enable
> it when raised.
>
>
>> + * Some boards have DTR and DCD implemented using PIO pins,
>> + * code to do this should be hooked in here.
>> + */
>> +}
>> +
>> +static unsigned int stm32_get_mctrl(struct uart_port *port)
>> +{
>> + /*
>> + * This routine is used for geting signals of: DTR, DCD, DSR, RI,
>> + * and CTS/RTS
>> + */
>> + return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
>> +}
>> +
...
>> +
>> +static void stm32_set_termios(struct uart_port *port, struct ktermios
>> *termios,
>> + struct ktermios *old)
>> +{
>> + unsigned int baud;
>> + u32 usardiv, mantissa, fraction;
>> + tcflag_t cflag;
>> + u32 cr1, cr2, cr3;
>> + unsigned long flags;
>> +
>> + baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 16);
>> + cflag = termios->c_cflag;
>> +
>> + spin_lock_irqsave(&port->lock, flags);
>> +
>> + /* Stop serial port and reset value */
>> + writel_relaxed(0, port->membase + USART_CR1);
>> +
>> + cr1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_UE | USART_CR1_RXNEIE;
>> +
>> + if (cflag & CSTOPB)
>> + cr2 = USART_CR2_STOP_2B;
>> +
>> + if (cflag & PARENB) {
>> + cr1 |= USART_CR1_PCE;
>> + if ((cflag & CSIZE) == CS8)
>> + cr1 |= USART_CR1_M;
>> + }
>> +
>> + if (cflag & PARODD)
>> + cr1 |= USART_CR1_PS;
>> +
>> + if (cflag & CRTSCTS)
>> + cr3 = USART_CR3_RTSE | USART_CR3_CTSE;
>
> If this means autoflow control, then you need to define
> throttle()/unthrottle() methods, otherwise the serial core won't
> be able to throttle the remote when input buffers are about
> to overflow.
>
> And you should only enable the autoCTS and let the serial
> core enable autoRTS through set_mctrl(TIOCM_RTS).
>
> Just let me know if you need more info about how to do this.
Ok, let's see if I have well understood.
USART_CR3_RTSE should be set/cleared in set_mctrl(), depending on
TIOCM_RTS value.
The throttle callback should disable the rx interrupt, and the
unthrottle enable it.
For CTS, it should be enabled in set_termios() if CRTSCTS, as done here.
Am I right?
>
>> +
>> + usardiv = (port->uartclk * 25) / (baud * 4);
>> + mantissa = (usardiv / 100) << USART_BRR_DIV_M_SHIFT;
>> + fraction = DIV_ROUND_CLOSEST((usardiv % 100) * 16, 100);
>> + if (fraction & ~USART_BRR_DIV_F_MASK) {
>> + fraction = 0;
>> + mantissa += (1 << USART_BRR_DIV_M_SHIFT);
>> + }
>> +
>> + writel_relaxed(mantissa | fraction, port->membase + USART_BRR);
>> +
>> + uart_update_timeout(port, cflag, baud);
>> +
>> + port->read_status_mask = USART_SR_ORE;
>> + if (termios->c_iflag & INPCK)
>> + port->read_status_mask |= USART_SR_PE | USART_SR_FE;
>> + if (termios->c_iflag & (IGNBRK | BRKINT | PARMRK))
>> + port->read_status_mask |= USART_SR_LBD;
>> +
>> + /* Characters to ignore */
>> + port->ignore_status_mask = 0;
>> + if (termios->c_iflag & IGNPAR)
>> + port->ignore_status_mask = USART_SR_PE | USART_SR_FE;
>> + if (termios->c_iflag & IGNBRK) {
>> + port->ignore_status_mask |= USART_SR_LBD;
>> + /*
>> + * If we're ignoring parity and break indicators,
>> + * ignore overruns too (for real raw support).
>> + */
>> + if (termios->c_iflag & IGNPAR)
>> + port->ignore_status_mask |= USART_SR_ORE;
>> + }
>> +
>> + /*
>> + * Ignore all characters if CRE
Re: [PATCH v4 2/4] mfd: lubbock_cplds: add lubbock IO board
Greg Kroah-Hartman writes: > On Fri, Feb 20, 2015 at 05:02:57PM +0100, Robert Jarzmik wrote: >> If there is no solution, I'll fallback through arch/arm/plat-pxa, not very >> nice, >> but it has to land somewhere, I don't want lubbock to remain broken. > > drivers/platform/arm ? Most certainly. I'll submit that to drivers/platform/arm/pxa, and maintain that pxa tree. As for drivers/platform/arm, do you want also maintainers to step up, or will you take the review/merge burden ? Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DT: leds: Add uniqueness requirement for 'label' property.
Hi Jacek, Jacek Anaszewski wrote: > Label is used for naming LED class devices. Since ePAPR > doesn't require uniqueness for label properties, it has to be > explicitly required in the LEDs common bindings documentation. > > Signed-off-by: Jacek Anaszewski > Acked-by: Kyungmin Park > Cc: Bryan Wu > Cc: Richard Purdie > Cc: Sakari Ailus > Cc: devicetree@vger.kernel.org Thanks for the patch! Acked-by: Sakari Ailus -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/15] clocksource: Add ARM System timer driver
Hi Daniel,
Thanks for the review. Please find my answers below.
2015-03-26 10:50 GMT+01:00 Daniel Lezcano :
> On 03/12/2015 10:55 PM, Maxime Coquelin wrote:
>>
>> From: Maxime Coquelin
>>
>> This patch adds clocksource support for ARMv7-M's System timer,
>> also known as SysTick.
>>
>> Signed-off-by: Maxime Coquelin
>
>
> Hi Maxime,
>
> the driver looks good. Three comments below.
>
> -- Daniel
>
>
>> ---
>> drivers/clocksource/Kconfig | 7
>> drivers/clocksource/Makefile | 1 +
>> drivers/clocksource/armv7m_systick.c | 78
>>
>> 3 files changed, 86 insertions(+)
>> create mode 100644 drivers/clocksource/armv7m_systick.c
>>
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index 1c2506f..b82e58b 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -134,6 +134,13 @@ config CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
>> help
>> Use ARM global timer clock source as sched_clock
>>
>> +config ARMV7M_SYSTICK
>> + bool
>> + select CLKSRC_OF if OF
>> + select CLKSRC_MMIO
>> + help
>> + This options enables support for the ARMv7M system timer unit
>> +
>> config ATMEL_PIT
>> select CLKSRC_OF if OF
>> def_bool SOC_AT91SAM9 || SOC_SAMA5
>> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
>> index 752d5c7..1c9a643 100644
>> --- a/drivers/clocksource/Makefile
>> +++ b/drivers/clocksource/Makefile
>> @@ -44,6 +44,7 @@ obj-$(CONFIG_MTK_TIMER) += mtk_timer.o
>>
>> obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
>> obj-$(CONFIG_ARM_GLOBAL_TIMER)+= arm_global_timer.o
>> +obj-$(CONFIG_ARMV7M_SYSTICK) += armv7m_systick.o
>> obj-$(CONFIG_CLKSRC_METAG_GENERIC)+= metag_generic.o
>> obj-$(CONFIG_ARCH_HAS_TICK_BROADCAST) += dummy_timer.o
>> obj-$(CONFIG_ARCH_KEYSTONE) += timer-keystone.o
>> diff --git a/drivers/clocksource/armv7m_systick.c
>> b/drivers/clocksource/armv7m_systick.c
>> new file mode 100644
>> index 000..23d8249
>> --- /dev/null
>> +++ b/drivers/clocksource/armv7m_systick.c
>> @@ -0,0 +1,78 @@
>> +/*
>> + * Copyright (C) Maxime Coquelin 2015
>> + * Author: Maxime Coquelin
>> + * License terms: GNU General Public License (GPL), version 2
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define SYST_CSR 0x00
>> +#define SYST_RVR 0x04
>> +#define SYST_CVR 0x08
>> +#define SYST_CALIB 0x0c
>> +
>> +#define SYST_CSR_ENABLE BIT(0)
>> +
>> +#define SYSTICK_LOAD_RELOAD_MASK 0x00FF
>> +
>> +static void __init system_timer_of_register(struct device_node *np)
>> +{
>> + struct clk *clk;
>> + void __iomem *base;
>> + u32 rate = 0;
>> + int ret;
>> +
>> + base = of_iomap(np, 0);
>> + if (!base) {
>> + pr_warn("system-timer: invalid base address\n");
>> + return;
>> + }
>> +
>> + clk = of_clk_get(np, 0);
>> + if (!IS_ERR(clk)) {
>> + ret = clk_prepare_enable(clk);
>> + if (ret) {
>> + clk_put(clk);
>> + goto out_unmap;
>> + }
>> +
>> + rate = clk_get_rate(clk);
>> + }
>> +
>> + /* If no clock found, try to get clock-frequency property */
>> + if (!rate) {
>> + ret = of_property_read_u32(np, "clock-frequency", &rate);
>> + if (ret)
>> + goto out_unmap;
>
>
> Shouldn't be 'goto out_clk_disable' ?
No, because I assumed !rate means we failed to get the clock.
Actually, clk_get_rate could return 0, so relying on rate value is not safe.
I propose to get clock-frequency property if IS_ERR(clk).
Is it fine for you?
>
>> + }
>> +
>> + writel_relaxed(SYSTICK_LOAD_RELOAD_MASK, base + SYST_RVR);
>> + writel_relaxed(SYST_CSR_ENABLE, base + SYST_CSR);
>> +
>> + ret = clocksource_mmio_init(base + SYST_CVR, "arm_system_timer",
>> rate,
>> + 200, 24, clocksource_mmio_readl_down);
>> + if (ret) {
>> + pr_err("failed to init clocksource (%d)\n", ret);
>> + goto out_clk_disable;
>> + }
>> +
>> + pr_info("ARM System timer initialized as clocksource\n");
>> +
>> + return;
>> +
>> +out_clk_disable:
>> + if (!IS_ERR(clk))
>
>
> Why do you need this check ?
To handle the case were no clock was found, but a clk-frequency value
was provided.
>
> It isn't missing a clk_put ?
Right, thanks for spotting this.
I wonder if it makes sense to implement the error path.
If we fail to initialize the clocksource, the system will be unusable.
Maybe I should just perform a BUG_ON() in the error cases, as most of
the other clocksource drivers do.
What is your view?
Regards,
Maxime
>
>> + clk_disable_unprepare(
Re: [PATCH v3 0/4] clk: st: New always-on clock domain
On Thu, 26 Mar 2015, Geert Uytterhoeven wrote: > Hi Lee, > > On Thu, Mar 26, 2015 at 2:51 PM, Lee Jones wrote: > > On Wed, 25 Mar 2015, Geert Uytterhoeven wrote: > >> On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones wrote: > >> > On Fri, 06 Mar 2015, Mike Turquette wrote: > >> >> This approach looks fine to me. In practice I think it is restricted to > >> >> hardware blocks that don't exist in DT yet (e.g. no driver, in the case > >> >> of your interconnect) and that restriction is probably for the best. > >> > > >> > Agreed. > >> > >> I think this restriction should be documented in the DT binding more > >> clearly, > >> as adding a "clk-always-on" node prohibits you from handling the clock > >> correctly in > >> the future. > > > > Would you mind taking the time to explain what you think those > > limitations are? > > If you add a "clk-always-on" node, the clock will always on using that DT. > That will still be true later, when you get a better understanding of the > hardware, and might discover you're gonna need a driver for the currently > hidden core component that's driven by the clock, and may want to manage > that clock. So I have two points here. First point; I think you're looking at an older version of my set. The newer one can be found at [1] and no longer uses 'always-on' nodes. Instead the 'clk-always-on' property is applied to the provider. See the documentation patch [2] for more details. Second point; this binding is _not_ to be used as a hack because the hardware isn't understood. Genuine uses are for clocks that must not be turned off ever, else bad things will happen. If the hardware is not understood, use 'clk-disable-unused' on the kernel cmdline instead. > When that happens, you're gonna need a DT update to make use of the > newly introduced driver and the features it provides (e.g. better power > management). The whole point of this set is to manage clocks that can't be power managed. Using the 'clk-always-on' property labels the clock with a big-red-sign saying "DO NOT TURN ME OFF, OR RISK CATASTROPHIC FAILURE", not a "TODO: Fix-me when you understand me". > On the other hand, if you would describe the actual hardware topology in DT, > the device node for the future driver would already be there, and no DT update > is needed (assuming you can guess right w.r.t. its bindings; usually these are > transparent buses, for which bindings are fairly generic, cfr. e.g. > "simple-pm-bus"). In our case the devices these clocks control will never be added to Device Tree. Linux can't see them, they have no registers and they can't be controlled. Added a device driver for all such devices would be foolhardy. > Until you have (a need for) a real driver, you do need some platform code that > makes sure the clock is enabled. When a real driver is introduced, the > platform code has to be updated, but DT doesn't have to change. No, this binding is _not_ for that use-case. If your platform is incomplete you must use 'clk-disable-unused'. > (The same is true for devices where the current driver isn't aware of the > clock, and shouldn't be, but you still need to enable the clock until the > driver has Runtime PM support (E.g. ARM GIC on shmobile, cfr. > https://www.marc.info/?l=linux-pm&m=142670617929493&w=3 (good, now > we have a bidirectional link between these two threads :-) Using a > "clk-always-on" property there instead of adding a reference to the clock > in the existing GIC device node would be just lying.) If this clock should _genuinely_ be always-on, then use my new binding in the clock controller node and the Clk framework will not turn it off. > If we start seeing many users, perhaps we need a general framework where > the platform code can register a list of clocks that must be enabled > (properly, > i.e. using clk_prepare_enable())? But I don't think the list should be put > in DT: DT describes hardware, not behavior. I did this in the very first iteration of this set. The DT guys didn't like it, which is why I re-wrote it to look like [1]. > If you don't care about DT stability, and can afford always updating your DT > with your kernel, the above doesn't apply. I heard during the ELC hallways > chats this is actually the case for you? My ears burning eh? Do tell... I think you currently misunderstand the use-case for this set. I hope my points above will clarify the point somewhat. Once we write the bindings and the DT nodes in [1], I don't plan for them to be changed, thus our DT will stay stable in this regard. NB: Yes, we are quite fortunate by the fact that most of are bindings can be considered fairly transient, but that is irrelevant in this particular case. [1] https://lkml.org/lkml/2015/2/27/548 [2] https://lkml.org/lkml/2015/2/27/551 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscrib
Re: [PATCH V2 2/2] ARM: dts: am57xx-beagle-x15: Add thermal map to include fan and tmp102
* Eduardo Valentin [150324 08:17]: > On Mon, Mar 23, 2015 at 02:39:39PM -0500, Nishanth Menon wrote: > > BeagleBoard-X15 has capability for a fan and has an onboard TMP102 > > temperature sensor as well. This allows us to create a new thermal > > zone (called, un-imaginatively "board"), and allows us to use some > > active cooling as temperatures start edge upward in the system by > > creating a new alert temperature (emperically 50C) for cpu. > > > > NOTE: Fan is NOT mounted by default on the platform, in such a case, > > all we end up doing is switch on a regulator and leak very minimal > > current. > > > > Signed-off-by: Nishanth Menon > > Acked-by: Eduardo Valentin Applying both of these into omap-for-v4.1/fixes-not-urgent thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 4/4] DTS: ARM: OMAP3-N900: Add lis3lv02d support
* Sebastian Reichel [150321 13:20]:
> From: Sebastian Reichel
>
> This adds support for the N900's accelerometer to
> the Nokia N900 DTS file.
>
> Signed-off-by: Sebastian Reichel
This at least currently does not conflict with anything I have
queued, so I suggest you try to get Greg to take the whole set:
Acked-by: Tony Lindgren
> ---
> arch/arm/boot/dts/omap3-n900.dts | 52
>
> 1 file changed, 52 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-n900.dts
> b/arch/arm/boot/dts/omap3-n900.dts
> index 6040327..b02a717 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -602,6 +602,58 @@
> pinctrl-0 = <&i2c3_pins>;
>
> clock-frequency = <40>;
> +
> + lis302dl: lis3lv02d@1d {
> + compatible = "st,lis3lv02d";
> + reg = <0x1d>;
> +
> + Vdd-supply = <&vaux1>;
> + Vdd_IO-supply = <&vio>;
> +
> + interrupt-parent = <&gpio6>;
> + interrupts = <21 20>; /* 181 and 180 */
> +
> + /* click flags */
> + st,click-single-x;
> + st,click-single-y;
> + st,click-single-z;
> +
> + /* Limits are 0.5g * value */
> + st,click-threshold-x = <8>;
> + st,click-threshold-y = <8>;
> + st,click-threshold-z = <10>;
> +
> + /* Click must be longer than time limit */
> + st,click-time-limit = <9>;
> +
> + /* Kind of debounce filter */
> + st,click-latency = <50>;
> +
> + /* Interrupt line 2 for click detection */
> + st,irq2-click;
> +
> + st,wakeup-x-hi;
> + st,wakeup-y-hi;
> + st,wakeup-threshold = <(800/18)>; /* millig-value / 18 to get
> HW values */
> +
> + st,wakeup2-z-hi;
> + st,wakeup2-threshold = <(900/18)>; /* millig-value / 18 to get
> HW values */
> +
> + st,hipass1-disable;
> + st,hipass2-disable;
> +
> + st,axis-x = <1>;/* LIS3_DEV_X */
> + st,axis-y = <(-2)>; /* LIS3_INV_DEV_Y */
> + st,axis-z = <(-3)>; /* LIS3_INV_DEV_Z */
> +
> + st,min-limit-x = <(-32)>;
> + st,min-limit-y = <3>;
> + st,min-limit-z = <3>;
> +
> + st,max-limit-x = <(-3)>;
> + st,max-limit-y = <32>;
> + st,max-limit-z = <32>;
> + };
> };
>
> &mmc1 {
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] dt-bindings: brcm: rationalize Broadcom documentation naming
On Wed, Mar 25, 2015 at 1:41 AM, Scott Branden wrote: > Hi Rob, > > On 15-03-22 06:20 PM, Rob Herring wrote: >> >> On 03/20/2015 08:06 PM, Scott Branden wrote: >>> >>> This patchset attempts to standardize the naming of dt-bindings >>> documents based on the Broadcom vendor prefix of brcm. >>> >>> Although there are no guidelines currently present for how to name >>> the dt-bindings document the "vendor,binding.txt" style is in use by >>> some of the other vendors. >>> >>> Acked-by: Lee Jones >>> Acked-by: Florian Fainelli >>> Acked-by: Gregory Fong >>> Acked-by: Stephen Warren >>> Signed-off-by: Scott Branden >> >> >> Version history would be nice... > > Yes, I should have added a cover letter but didn't. The difference between > versions was minimal: a spelling correction in the commit message text and a > few additional binding files were found that were added between the > versions, along with the Ack's. > >> >> Who did you want to apply this? I can, but I'm worried about merge >> conflicts here. Hopefully, you're not also doing lots of changes to >> existing bindings. > > > Yes, it would be great for you to take care of applying this. There > shouldn't be any merge conflicts as none of these bindings are currently > being updated. I left a clock binding document out of this patchset at Ray > Jui is updating/renaming the documentation for that binding in a different > patch already. Okay, thanks. I've applied it. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: Explicitly include linux/types.h in of_graph.h
On Thu, Mar 26, 2015 at 11:47 AM, Mark Brown wrote: > In current -next of_graph.h fails to build due to it relying on > linux/types.h without explicitly including it: > > ../include/linux/of_graph.h:43:71: error: unknown type name 'u32' > > caused by bfe446e37c4e (of: Add of_graph_get_port_by_id function). Add > an explicit inclusion to fix this. > > Signed-off-by: Mark Brown Applied. Thanks. Rob > --- > include/linux/of_graph.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h > index 3c1c95a39e0c..7bc92e050608 100644 > --- a/include/linux/of_graph.h > +++ b/include/linux/of_graph.h > @@ -14,6 +14,8 @@ > #ifndef __LINUX_OF_GRAPH_H > #define __LINUX_OF_GRAPH_H > > +#include > + > /** > * struct of_endpoint - the OF graph endpoint data structure > * @port: identifier (value of reg property) of a port this endpoint belongs > to > -- > 2.1.4 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 4/4] crypto: Add Allwinner Security System crypto accelerator
Hi Corentin,
Here is a quick review, there surely are a lot of other things I didn't
spot.
On Mon, 16 Mar 2015 20:01:22 +0100
LABBE Corentin wrote:
> Add support for the Security System included in Allwinner SoC A20.
> The Security System is a hardware cryptographic accelerator that support:
> - MD5 and SHA1 hash algorithms
> - AES block cipher in CBC mode with 128/196/256bits keys.
> - DES and 3DES block cipher in CBC mode
>
> Signed-off-by: LABBE Corentin
> ---
[...]
> +static int sunxi_ss_cipher(struct ablkcipher_request *areq, u32 mode)
> +{
> + struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(areq);
> + struct sunxi_tfm_ctx *op = crypto_ablkcipher_ctx(tfm);
> + const char *cipher_type;
> + struct sunxi_ss_ctx *ss = op->ss;
> +
> + if (areq->nbytes == 0)
> + return 0;
> +
> + if (areq->info == NULL) {
> + dev_err(ss->dev, "ERROR: Empty IV\n");
> + return -EINVAL;
> + }
> +
> + if (areq->src == NULL || areq->dst == NULL) {
> + dev_err(ss->dev, "ERROR: Some SGs are NULL\n");
> + return -EINVAL;
> + }
> +
> + cipher_type = crypto_tfm_alg_name(crypto_ablkcipher_tfm(tfm));
> +
> + if (strcmp("cbc(aes)", cipher_type) == 0) {
> + mode |= SS_OP_AES | SS_CBC | SS_ENABLED | op->keymode;
> + return sunxi_ss_aes_poll(areq, mode);
> + }
> +
> + if (strcmp("cbc(des)", cipher_type) == 0) {
> + mode |= SS_OP_DES | SS_CBC | SS_ENABLED | op->keymode;
> + return sunxi_ss_des_poll(areq, mode);
> + }
> +
> + if (strcmp("cbc(des3_ede)", cipher_type) == 0) {
> + mode |= SS_OP_3DES | SS_CBC | SS_ENABLED | op->keymode;
> + return sunxi_ss_des_poll(areq, mode);
> + }
Hm, I'm not sure doing these string comparisons in the crypto operation
path is a good idea.
Moreover, you're doing 3 string comparisons, even though only one can
be valid at a time (using 'else if' would have been a bit better).
Anyway, IMHO this function should be split into 3 functions, and
referenced by your alg template definitions.
Something like:
int sunxi_ss_xxx_encrypt(struct ablkcipher_request *areq)
{
/* put your cipher specific intialization here */
return sunxi_ss_xxx_poll(areq, SS_ENCRYPTION);
}
int sunxi_ss_xxx_decrypt(struct ablkcipher_request *areq)
{
/* put your cipher specific intialization here */
return sunxi_ss_xxx_poll(areq, SS_DECRYPTION);
}
> +
> +int sunxi_ss_cipher_init(struct crypto_tfm *tfm)
> +{
> + const char *name = crypto_tfm_alg_name(tfm);
> + struct sunxi_tfm_ctx *op = crypto_tfm_ctx(tfm);
> + struct crypto_alg *alg = tfm->__crt_alg;
> + struct sunxi_ss_alg_template *algt;
> + struct sunxi_ss_ctx *ss;
> +
> + memset(op, 0, sizeof(struct sunxi_tfm_ctx));
> +
> + algt = container_of(alg, struct sunxi_ss_alg_template, alg.crypto);
> + ss = algt->ss;
> + op->ss = algt->ss;
> +
> + /* fallback is needed only for DES/3DES */
> + if (strcmp("cbc(des)", name) == 0 ||
> + strcmp("cbc(des3_ede)", name) == 0) {
> + op->fallback = crypto_alloc_ablkcipher(name, 0,
> + CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK);
> + if (IS_ERR(op->fallback)) {
> + dev_err(ss->dev, "ERROR: allocating fallback algo %s\n",
> + name);
> + return PTR_ERR(op->fallback);
> + }
> + }
Ditto: just create a specific init function for the des case:
int sunxi_ss_cbc_des_init(struct crypto_tfm *tfm)
{
sunxi_ss_cipher_init(tfm);
op->fallback = crypto_alloc_ablkcipher(name, 0,
CRYPTO_ALG_ASYNC |
CRYPTO_ALG_NEED_FALLBACK);
if (IS_ERR(op->fallback)) {
dev_err(ss->dev, "ERROR: allocating fallback algo %s\n",
name);
return PTR_ERR(op->fallback);
}
return 0;
}
[..]
> +/*
> + * Optimized function for the case where we have only one SG,
> + * so we can use kmap_atomic
> + */
> +static int sunxi_ss_aes_poll_atomic(struct ablkcipher_request *areq)
> +{
> + u32 spaces;
> + struct scatterlist *in_sg = areq->src;
> + struct scatterlist *out_sg = areq->dst;
> + void *src_addr;
> + void *dst_addr;
> + unsigned int ileft = areq->nbytes;
> + unsigned int oleft = areq->nbytes;
> + unsigned int todo;
> + u32 *src32;
> + u32 *dst32;
> + u32 rx_cnt = 32;
> + u32 tx_cnt = 0;
> + int i;
> + struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(areq);
> + struct sunxi_tfm_ctx *op = crypto_ablkcipher_ctx(tfm);
> + struct sunxi_ss_ctx *ss = op->ss;
> +
> + src_addr = kmap_atomic(sg_page(in_sg)) + in_sg->offset;
> + if (src_addr == NULL) {
> + dev_err(ss->dev, "kmap_atomic error for src SG\n");
> +
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi,
On Wed, Mar 25, 2015 at 05:44:42PM +0100, Dr. H. Nikolaus Schaller wrote:
> Am 25.03.2015 um 16:21 schrieb Sebastian Reichel :
> > On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote:
> >> Am 25.03.2015 um 02:45 schrieb Sebastian Reichel :
> >>> On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
> So you propose that the parent->child relationship is “control”? I.e.
> some
> channel which allows to address some bus client (through ) and
> control that devices.
>
> Makes sense. This is how i2c and spi clients are specified.
>
> > In the case of our GPS, it receives control over the serial connection
> > from
> > the UART,
>
> Ahem - does it?
>
> AFAIK the chip simply starts to emit NMEA records if powered on.
> There is no command going over the serial interface to address it
> or control it.
> >>>
> >>> Right, since GPS basically doesn't need any configuration/control.
> >>> That’s not true for other UART attached devices, though.
> >>
> >> Do you have an example? Usually an UART data stream is transparently
> >> presented to a /dev/tty - and user-space daemon can configure/control the
> >> attached device. In most cases it can mix payload data and control command
> >> by some AT command and escape sequences.
> >
> > Yes, but the configuration is minimal. Anyways as you said there
> > *is* some kind of control happening over the UART.
>
> Control is happening on a higher network stack level than UART. It
> control is done through AT commands.
Yes, obviously UART is only the physical layer. The same is true for
busses and does not really matter.
> > also receives control via a GPIO to the on/off pin, and also needs
> > a regulator to power the antenna.
> >
> > So should the parent be the uart, the on/off GPIO, or the regulator?
> >
> > I would much rather there wasn't a parent, and that each of these were
> > listed
> > as ad-hoc attribute assignments. But device-tree says there must be a
> > parent
> > (where possible), and the parent is the thing that is “primarily" in
> > control.
>
> Well, IMHO the “parent” could also be the root. Representing the
> whole board.
>
> Nevertheless, I doubt your rule that “ability to control” defines
> the parent>child relation (see below).
>
> >
> > I think the GPS is “primarily" a uart-attached device.
>
> But not in the same way as an I2C device.
>
> Especially the serial interface is not a bus and not used for
> signalling and power control. It is payload data (only).
> >>>
> >>> Actually many I2C devices are also powered on/off via a GPIO and
> >>> even use additional GPIOs for sending interrupts. Nevertheless they
> >>> are normally identified as an I2C device.
> >>
> >> Because I2C is a bus that can address multiple clients and gpio isn’t
> >> a bus and a point-to-point connection.
> >>
> >> But IMHO it is not because they (can) send payload data over i2c.
> >
> > From my POV it's not because I2C is a bus, but because the primary
> > function is happening via I2C (e.g. configuring sensor, gettings its
> > data). The GPIOs are only needed to compensate some I2C shortcomings
> > (missing irq feature in I2C) or reduce the complexity of the client
> > (power GPIO). The actual system interaction with the I2C chip is
> > going via I2C, though.
>
> Yes, but this is in my new understanding irrelevant for proper DT
> description.
And for my understanding it is. We are arguing in a circle...
> If you assume that parent>child relationship is about control (only).
> But if it
> is about data flow, there is a different concept in DT. For example the
> CSI/DSI
> (OMAP DSS) use the “port” concept.
> >>>
> >>> Yes, this is about data not going to the cpu / system memory.
> >>
> >> Really? The frame buffer data is in system memory and gets to the panel.
> >> Or a
> >> camera image ends up in system memory.
> >
> > Really? So the panel accesses the system memory? Check again. The
> > panel is simply connected via DSI/SDI/... and does not access the
> > system memory at all. The display controller OTH does. So let's have
> > a look at the DT structure (simplified):
> >
> > ocp -> dss -> { port = <&panel>; }
> > ... -> spi -> panel { port = <&dss>; }
> >
> > So the port models a device-to-device connection, which works
> > independent of the remaining system. No system memory is involved.
>
> Sorry, but I can’t exactly follow what you want to show.
>
> Yes, the port mechanism describes a device to device connection.
>
> But it does not describe system memory. Although it is the source of
> the video (i.e. the framebuffer).
>
> This shows that the DT does not necessarily describe data flow.
>
> So why do you want to describe data flow from tty to uart to some
> connected device?
It sh
Re: [RESEND PATCH 2/2] bus: ocp2scp: SYNC2 value should be changed to 0x6
* Kishon Vijay Abraham I [150317 04:25]: > As per the TRMs of AM572x, OMAP4430, OMAP4460, OMAP543x, the value of > SYNC2 must be set to 0x6 in order to ensure correct operation. > > So modified the SYNC2 value of OCP2SCP TIMING register to 0x6 in all the > platforms that use OCP2SCP driver except AM437x. Also introduced a new > compatible property since we don't want to modify the OCP2SCP TIMING > register for AM437x. OK thanks I'll apply both into omap-for-v4.1/fixes-not-urgent as it seems we've gotten away with it for quite a few years now, and I don't see any specific description of what these fix. If that's not the case, please let me know. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SAM5D3 Xplained MMC device tree updates
A small set to fix warnings from the kernel. Note, the atmel_defconfig will require CONFIG_REGULATOR_GPIO to be set. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: at91/dt: sama5d3 add mmc0 vmmcq entry
The SAM5D3 Xplained device tree is missing hte vqmmc node which is
tied to 3.3V on the board. Add this to avoid the kernel warning that
there is no vqmmc node.
atmel_mci f000.mmc: No vqmmc regulator found
Signed-off-by: Ben Dooks
--
CC: linux-arm-ker...@lists.infradead.org
CC: Andrew Victor
CC: Nicolas Ferre
CC: Jean-Christophe Plagniol-Villard
CC: Rob Herring
CC: Pawel Moll
CC: Mark Rutland
CC: Ian Campbell
CC: Kumar Gala
CC: Russell King
CC: linux-arm-ker...@lists.infradead.org
CC: devicetree@vger.kernel.org
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index 652c4dd..1eb150d 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -36,6 +36,7 @@
mmc0: mmc@f000 {
pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0
&pinctrl_mmc0_dat1_3 &pinctrl_mmc0_dat4_7 &pinctrl_mmc0_cd>;
status = "okay";
+ vqmmc-supply = <&vcc_3v3_reg>;
slot@0 {
reg = <0>;
bus-width = <8>;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: at91/dt: sama5d3 add gpio regulator for vmmc0
Add gpio regulator for vmmc0 and attach the vmmc for it to the mmc0
node on the SAM5D3 Xplained board. This will remove the following
warning from the kernel:
atmel_mci f000.mmc: No vmmc regulator found
Note, atmel_defconfig will need gpio regulator support enabled if this
is to be used properly.
Signed-off-by: Ben Dooks
--
CC: Andrew Victor
CC: Nicolas Ferre
CC: Jean-Christophe Plagniol-Villard
CC: Rob Herring
CC: Pawel Moll
CC: Mark Rutland
CC: Ian Campbell
CC: Kumar Gala
CC: Russell King
CC: linux-arm-ker...@lists.infradead.org
CC: devicetree@vger.kernel.org
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index 1eb150d..6b6ad5c 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -36,6 +36,7 @@
mmc0: mmc@f000 {
pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0
&pinctrl_mmc0_dat1_3 &pinctrl_mmc0_dat4_7 &pinctrl_mmc0_cd>;
status = "okay";
+ vmmc-supply = <&vcc_mmc0_reg>;
vqmmc-supply = <&vcc_3v3_reg>;
slot@0 {
reg = <0>;
@@ -285,6 +286,14 @@
};
};
+ vcc_mmc0_reg: regulator@1 {
+ compatible = "regualtor-gpio";
+ gpio = <&pioE 2 GPIO_ACTIVE_LOW>;
+ regulator-name = "mmc0-card-supply";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
gpio_keys {
compatible = "gpio-keys";
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/4] edac: Add APM X-Gene SoC EDAC driver
Hi Doug, Any comment with v6 of the APM EDAC driver? -Loc On Mon, Mar 16, 2015 at 11:30 PM, Loc Ho wrote: > This patch adds support for the APM X-Gene SoC EDAC driver for DT. > > v6: > * Rebase to 4.0.0-rc3 > * Add memory scrub stub function and enable ARM64 EDAC support patch > * Add bit definition defines for L2RTOS registers > * Remove un-necessary clearing of all L1/L2 software generated registers > * Remove wrong notification of LSU un-correctable error > * Change L2 reporting of un-correcable error to correctable error > * Change clearing of the L2C L2RTO registers > * Add support for L2 HW version 1 and version 2 or above > * Add support for L3 HW version 1 and version 2 or above > > v5: > * Rebase to 3.17.rc1 (next) > * Update binding documentation for additional SoC node binding resource > * Enable MCU correctable and uncorrectable interrupts if not enabled by > firmware > * Enable top level interrupt only after all MCU registered. Otherwise, > error interrupt will never get cleared by the corresponding MCU. > * Remove clearing of L1 and L2 errors during initialization time. Otherwise, > they will not be captured between firmware booting and error configuration. > * Add capture and clearing SoC register bus errors > * Add register bus resource to SoC DT node > > v4: > * Fix PMD l1/l2 error reading address due to wrong variable type > * Fix clearing of software generated and HW errors for l1/l2 > > v3: > * Update binding documentation for PMD DT node and exampples > * Add binding documentation for SoC DT node > * Change MC, PMD, and L3C driver error injection to use debugfs > * Add missing IRQ for MC correctable error (code and DT) > * Use true/false where appropriate instead 1/0 > * Add bit definition for L1 MMUESR register and fully decode this error > * Remove the un-necessary dev variable from xgene_edac_pmd_ctx structure > * Add check for disabled PMD (code and DT) > * Switch to edac_printk instead pr_err > * Some minor comments update > > v2: > * Add EDAC entry in MAINTAINERS for APM EDAC driver > * Remove the MC scrub patch > * Remove the word 'Caches' from Kconfig > * Change all MASK defines to use BIT(x) > * Update comment or remove them > * Wrap error injection code around CONFIG_EDAC_DEBUG > * Change function name xgene_edac_mc_hw_init to xgene_edac_mc_irq_ctl > * Change all function XXX_hw_init to XXX_hw_ctl > * Fix typo 'activie' > * Move calling function edac_mc_alloc after resource retrieval > * Check for NULL on platform_get_resource return if reference directly > * Add documentation for struct xgene_edac_pmd_ctx > * Move L1 and L2 check out of function xgene_edac_pmd_check to its own > functions > * Use for loop for configure each CPU of an PMD > * Replace /2 by >> 1 > * Remove unnecessary comment on edac_device_add_device failure > * Make mem_err_ip static const > * Unwind EDAC register correctly if failed > --- > Loc Ho (5): > arm64: Enable EDAC on ARM64 > MAINTAINERS: Add entry for APM X-Gene SoC EDAC driver > Documentation: Add documentation for the APM X-Gene SoC EDAC DTS > binding > edac: Add APM X-Gene SoC EDAC driver > arm64: Add APM X-Gene SoC EDAC DTS entries > > .../devicetree/bindings/edac/apm-xgene-edac.txt| 82 + > MAINTAINERS|8 + > arch/arm64/Kconfig |1 + > arch/arm64/boot/dts/apm/apm-storm.dtsi | 98 + > arch/arm64/include/asm/edac.h | 31 + > drivers/edac/Kconfig |9 +- > drivers/edac/Makefile |1 + > drivers/edac/xgene_edac.c | 2183 > > 8 files changed, 2412 insertions(+), 1 deletions(-) > create mode 100644 Documentation/devicetree/bindings/edac/apm-xgene-edac.txt > create mode 100644 arch/arm64/include/asm/edac.h > create mode 100644 drivers/edac/xgene_edac.c > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: at91/dt: sama5d3 fill in mmc1 and default disabled
The mmc1 channel is not populated on the SAM5D3 Xplained board, however
it is enabled and therefore the driver is attaching to it.
The node configuration for mmc1 is missing, so add an mmc1 node in the
device tree so add the basic node, set it to default it to disabled. Also
add the vmmc and also the necessary slot configuration if this node
where to be enabled to avoid the following warnings from the driver.
atmel_mci f800.mmc: No vmmc regulator found
atmel_mci f800.mmc: No vqmmc regulator found
Signed-off-by: Ben Dooks
--
CC: linux-arm-ker...@lists.infradead.org
CC: Andrew Victor
CC: Nicolas Ferre
CC: Jean-Christophe Plagniol-Villard
CC: Rob Herring
CC: Pawel Moll
CC: Mark Rutland
CC: Ian Campbell
CC: Kumar Gala
CC: Russell King
CC: linux-arm-ker...@lists.infradead.org
CC: devicetree@vger.kernel.org
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index fec1fca..652c4dd 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -43,6 +43,17 @@
};
};
+ mmc1: mmc@f800 {
+ vmmc-supply = <&vcc_3v3_reg>;
+ vqmmc-supply = <&vcc_3v3_reg>;
+ status = "disabled";
+ slot@0 {
+ reg = <0>;
+ bus-width = <4>;
+ cd-gpios = <&pioE 1 GPIO_ACTIVE_LOW>;
+ };
+ };
+
spi0: spi@f0004000 {
cs-gpios = <&pioD 13 0>, <0>, <0>, <&pioD 16 0>;
status = "okay";
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: Explicitly include linux/types.h in of_graph.h
Am Donnerstag, den 26.03.2015, 09:47 -0700 schrieb Mark Brown: > In current -next of_graph.h fails to build due to it relying on > linux/types.h without explicitly including it: > > ../include/linux/of_graph.h:43:71: error: unknown type name 'u32' > > caused by bfe446e37c4e (of: Add of_graph_get_port_by_id function). Add > an explicit inclusion to fix this. > > Signed-off-by: Mark Brown > --- > include/linux/of_graph.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h > index 3c1c95a39e0c..7bc92e050608 100644 > --- a/include/linux/of_graph.h > +++ b/include/linux/of_graph.h > @@ -14,6 +14,8 @@ > #ifndef __LINUX_OF_GRAPH_H > #define __LINUX_OF_GRAPH_H > > +#include > + > /** > * struct of_endpoint - the OF graph endpoint data structure > * @port: identifier (value of reg property) of a port this endpoint belongs > to Acked-by: Philipp Zabel Thanks! Philipp -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] clk: st: New always-on clock domain
Hi Lee,
On Thu, Mar 26, 2015 at 2:51 PM, Lee Jones wrote:
> On Wed, 25 Mar 2015, Geert Uytterhoeven wrote:
>> On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones wrote:
>> > On Fri, 06 Mar 2015, Mike Turquette wrote:
>> >> This approach looks fine to me. In practice I think it is restricted to
>> >> hardware blocks that don't exist in DT yet (e.g. no driver, in the case
>> >> of your interconnect) and that restriction is probably for the best.
>> >
>> > Agreed.
>>
>> I think this restriction should be documented in the DT binding more clearly,
>> as adding a "clk-always-on" node prohibits you from handling the clock
>> correctly in
>> the future.
>
> Would you mind taking the time to explain what you think those
> limitations are?
If you add a "clk-always-on" node, the clock will always on using that DT.
That will still be true later, when you get a better understanding of the
hardware, and might discover you're gonna need a driver for the currently
hidden core component that's driven by the clock, and may want to manage
that clock.
When that happens, you're gonna need a DT update to make use of the
newly introduced driver and the features it provides (e.g. better power
management).
On the other hand, if you would describe the actual hardware topology in DT,
the device node for the future driver would already be there, and no DT update
is needed (assuming you can guess right w.r.t. its bindings; usually these are
transparent buses, for which bindings are fairly generic, cfr. e.g.
"simple-pm-bus").
Until you have (a need for) a real driver, you do need some platform code that
makes sure the clock is enabled. When a real driver is introduced, the
platform code has to be updated, but DT doesn't have to change.
(The same is true for devices where the current driver isn't aware of the
clock, and shouldn't be, but you still need to enable the clock until the
driver has Runtime PM support (E.g. ARM GIC on shmobile, cfr.
https://www.marc.info/?l=linux-pm&m=142670617929493&w=3 (good, now
we have a bidirectional link between these two threads :-) Using a
"clk-always-on" property there instead of adding a reference to the clock
in the existing GIC device node would be just lying.)
If we start seeing many users, perhaps we need a general framework where
the platform code can register a list of clocks that must be enabled (properly,
i.e. using clk_prepare_enable())? But I don't think the list should be put
in DT: DT describes hardware, not behavior.
If you don't care about DT stability, and can afford always updating your DT
with your kernel, the above doesn't apply. I heard during the ELC hallways
chats this is actually the case for you?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: Explicitly include linux/types.h in of_graph.h
Hi Mark, Thank you for the patch. On Thursday 26 March 2015 09:47:55 Mark Brown wrote: > In current -next of_graph.h fails to build due to it relying on > linux/types.h without explicitly including it: > > ../include/linux/of_graph.h:43:71: error: unknown type name 'u32' > > caused by bfe446e37c4e (of: Add of_graph_get_port_by_id function). Add > an explicit inclusion to fix this. > > Signed-off-by: Mark Brown Acked-by: Laurent Pinchart > --- > include/linux/of_graph.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h > index 3c1c95a39e0c..7bc92e050608 100644 > --- a/include/linux/of_graph.h > +++ b/include/linux/of_graph.h > @@ -14,6 +14,8 @@ > #ifndef __LINUX_OF_GRAPH_H > #define __LINUX_OF_GRAPH_H > > +#include > + > /** > * struct of_endpoint - the OF graph endpoint data structure > * @port: identifier (value of reg property) of a port this endpoint > belongs to -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] pwm: samsung: Fix output race on disabling
From: Sjoerd Simons
When disabling the samsung PWM the output state remains at the level it
was in the end of a pwm cycle. In other words, calling pwm_disable when
at 100% duty will keep the output active, while at all other setting the
output will go/stay inactive. On top of that the samsung PWM settings are
double-buffered, which means the new settings only get applied at the
start of a new PWM cycle.
This results in a race if the PWM is at 100% duty and a driver calls:
pwm_config (pwm, 0, period);
pwm_disable (pwm);
In this case the PWMs output will unexpectedly stay active, unless a new
PWM cycle happened to start between the register writes in _config and
_disable. As far as i can tell this is a regression introduced by 3bdf878,
before that a call to pwm_config would call pwm_samsung_enable which,
while heavy-handed, made sure the expected settings were live.
To resolve this, while not re-introducing the issues 3bdf878 (flickering
as the PWM got reset while in a PWM cycle). Only force an update of the
settings when at 100% duty, which shouldn't have a noticeable effect on
the output but is enough to ensure the behaviour is as expected on
disable.
Signed-off-by: Sjoerd Simons
Signed-off-by: Anand Moon
---
drivers/pwm/pwm-samsung.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index 3e9b583..649f6c4 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -269,12 +269,31 @@ static void pwm_samsung_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
spin_unlock_irqrestore(&samsung_pwm_lock, flags);
}
+static void pwm_samsung_manual_update(struct samsung_pwm_chip *chip,
+ struct pwm_device *pwm)
+{
+ unsigned int tcon_chan = to_tcon_channel(pwm->hwpwm);
+ u32 tcon;
+ unsigned long flags;
+
+ spin_lock_irqsave(&samsung_pwm_lock, flags);
+
+ tcon = readl(chip->base + REG_TCON);
+ tcon |= TCON_MANUALUPDATE(tcon_chan);
+ writel(tcon, chip->base + REG_TCON);
+
+ tcon &= ~TCON_MANUALUPDATE(tcon_chan);
+ writel(tcon, chip->base + REG_TCON);
+
+ spin_unlock_irqrestore(&samsung_pwm_lock, flags);
+}
+
static int pwm_samsung_config(struct pwm_chip *chip, struct pwm_device *pwm,
int duty_ns, int period_ns)
{
struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
struct samsung_pwm_channel *chan = pwm_get_chip_data(pwm);
- u32 tin_ns = chan->tin_ns, tcnt, tcmp;
+ u32 tin_ns = chan->tin_ns, tcnt, tcmp, oldtcmp;
/*
* We currently avoid using 64bit arithmetic by using the
@@ -288,6 +307,7 @@ static int pwm_samsung_config(struct pwm_chip *chip, struct
pwm_device *pwm,
return 0;
tcnt = readl(our_chip->base + REG_TCNTB(pwm->hwpwm));
+ oldtcmp = readl(our_chip->base + REG_TCMPB(pwm->hwpwm));
/* We need tick count for calculation, not last tick. */
++tcnt;
@@ -335,6 +355,15 @@ static int pwm_samsung_config(struct pwm_chip *chip,
struct pwm_device *pwm,
writel(tcnt, our_chip->base + REG_TCNTB(pwm->hwpwm));
writel(tcmp, our_chip->base + REG_TCMPB(pwm->hwpwm));
+ /* In case the PWM is currently at 100% duty, force a manual update
+* to prevent the signal staying high in the pwm is disabled shortly
+* afer this update (before it autoreloaded the new values) .
+*/
+ if (oldtcmp == (u32) -1) {
+ dev_dbg(our_chip->chip.dev, "Forcing manual update");
+ pwm_samsung_manual_update(our_chip, pwm);
+ }
+
chan->period_ns = period_ns;
chan->tin_ns = tin_ns;
chan->duty_ns = duty_ns;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] of: Explicitly include linux/types.h in of_graph.h
In current -next of_graph.h fails to build due to it relying on linux/types.h without explicitly including it: ../include/linux/of_graph.h:43:71: error: unknown type name 'u32' caused by bfe446e37c4e (of: Add of_graph_get_port_by_id function). Add an explicit inclusion to fix this. Signed-off-by: Mark Brown --- include/linux/of_graph.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h index 3c1c95a39e0c..7bc92e050608 100644 --- a/include/linux/of_graph.h +++ b/include/linux/of_graph.h @@ -14,6 +14,8 @@ #ifndef __LINUX_OF_GRAPH_H #define __LINUX_OF_GRAPH_H +#include + /** * struct of_endpoint - the OF graph endpoint data structure * @port: identifier (value of reg property) of a port this endpoint belongs to -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] ARM: dts :exynos5422-odroidxu3 Add pwm-fan node to the Odroid-XU3 board.
Add pwm-fan node to the OdroidXU3 board.
Tested on OdroidXU3 board.
Signed-off-by: Anand Moon
---
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index a519c86..eaec006 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -278,6 +278,15 @@
rtc@101E {
status = "okay";
};
+
+ fan0: pwm-fan {
+ compatible = "pwm-fan";
+ pwms = <&pwm 0 20972 0>;
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
+ cooling-levels = <0 90 130 170 230>;
+ };
};
&hdmi {
@@ -369,3 +378,10 @@
shunt-resistor = <1>;
};
};
+
+&pwm {
+ pinctrl-0 = <&pwm0_out>;
+ pinctrl-names = "default";
+ samsung,pwm-outputs = <0>;
+ status = "okay";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] ARM: dts exynos5420 update the cooling cells for core cpu0
update the cooling level for cpu0 to avoid following message.
root@odroidxu3:~# dmesg | grep ther
[0.241511] /thermal-zones/cpu-thermal/cooling-maps/map0:
could not get #cooling-cells for /cpus/cpu@0
Signed-off-by: Anand Moon
---
arch/arm/boot/dts/exynos5420.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c0e98cf..6b49f3c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -61,6 +61,10 @@
reg = <0x0>;
clock-frequency = <18>;
cci-control-port = <&cci_control1>;
+
+ cooling-min-level = <10>;
+ cooling-max-level = <7>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu1: cpu@1 {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] ARM: dts: OdroidXU3: Enable TMU at Exynos5422 base.
This commit enables TMU IP block on the Exynos5422 OdroidXU3
device.
Tested on OdroidXU3 board.
Signed-off-by: Anand Moon
---
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index c8b3e3e..e1635b5 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -288,6 +288,31 @@
#cooling-cells = <2>;
cooling-levels = <0 90 130 170 230>;
};
+
+ tmu@1006 {
+ vtmu-supply = <&ldo10_reg>;
+ status = "okay";
+ };
+
+ tmu@10064000 {
+ vtmu-supply = <&ldo10_reg>;
+ status = "okay";
+ };
+
+ tmu@10068000 {
+ vtmu-supply = <&ldo10_reg>;
+ status = "okay";
+ };
+
+ tmu@1006c000 {
+ vtmu-supply = <&ldo10_reg>;
+ status = "okay";
+ };
+
+ tmu@100a {
+ vtmu-supply = <&ldo10_reg>;
+ status = "okay";
+ };
};
&hdmi {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
Below changes depend on following patch.
https://patchwork.kernel.org/patch/5944061/
Update the pwm_config with duty then update the pwm_disable
to poweroff the cpu fan.
Tested on OdroidXU3 board.
Signed-off-by: Anand Moon
---
drivers/hwmon/pwm-fan.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 7c83dc4..f25c841 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -44,26 +44,24 @@ static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned
long pwm)
int ret = 0;
mutex_lock(&ctx->lock);
+
if (ctx->pwm_value == pwm)
goto exit_set_pwm_err;
- if (pwm == 0) {
- pwm_disable(ctx->pwm);
- goto exit_set_pwm;
- }
-
duty = DIV_ROUND_UP(pwm * (ctx->pwm->period - 1), MAX_PWM);
ret = pwm_config(ctx->pwm, duty, ctx->pwm->period);
if (ret)
goto exit_set_pwm_err;
+ if (pwm == 0)
+ pwm_disable(ctx->pwm);
+
if (ctx->pwm_value == 0) {
ret = pwm_enable(ctx->pwm);
if (ret)
goto exit_set_pwm_err;
}
-exit_set_pwm:
ctx->pwm_value = pwm;
exit_set_pwm_err:
mutex_unlock(&ctx->lock);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
Move the registration of thermal sensors for tmu_cpu0 from exynos5420.dtsi
to exynos5-cpu-thermal.dtsi, to avoid duplicate registration of the sensors.
Tested on OdroidXU3 board.
Signed-off-by: Anand Moon
---
arch/arm/boot/dts/exynos5-cpu-thermal.dtsi | 58 ++
arch/arm/boot/dts/exynos5420.dtsi | 4 ---
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 1 +
3 files changed, 59 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
b/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
new file mode 100644
index 000..8fede70
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
@@ -0,0 +1,58 @@
+/*
+ * Device tree sources for Exynos5 thermal zone
+ *
+ * Copyright (c) 2014 Lukasz Majewski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+
+/ {
+ thermal-zones {
+ cpu0_thermal: cpu0-thermal {
+ thermal-sensors = <&tmu_cpu0>;
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ trips {
+ cpu_alert0: cpu-alert-0 {
+ temperature = <48000>; /* ms */
+ hysteresis = <3000>; /* ms */
+ type = "active";
+ };
+ cpu_alert1: cpu-alert-1 {
+ temperature = <53000>; /* ms */
+ hysteresis = <3000>; /* ms */
+ type = "active";
+ };
+ cpu_alert2: cpu-alert-2 {
+ temperature = <59000>; /* ms */
+ hysteresis = <3000>; /* ms */
+ type = "active";
+ };
+ cpu_crit0: cpu-crit-0 {
+ temperature = <75000>; /* ms */
+ hysteresis = <0>; /* ms */
+ type = "critical";
+ };
+ };
+ cooling-maps {
+ map0 {
+trip = <&cpu_alert0>;
+cooling-device = <&fan0 0 1>;
+ };
+ map1 {
+trip = <&cpu_alert1>;
+cooling-device = <&fan0 1 2>;
+ };
+ map2 {
+trip = <&cpu_alert2>;
+cooling-device = <&fan0 2 3>;
+ };
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 6b49f3c..eb0f16c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -827,10 +827,6 @@
};
thermal-zones {
- cpu0_thermal: cpu0-thermal {
- thermal-sensors = <&tmu_cpu0>;
- #include "exynos5420-trip-points.dtsi"
- };
cpu1_thermal: cpu1-thermal {
thermal-sensors = <&tmu_cpu1>;
#include "exynos5420-trip-points.dtsi"
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index eaec006..c8b3e3e 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -12,6 +12,7 @@
/dts-v1/;
#include "exynos5800.dtsi"
+#include "exynos5-cpu-thermal.dtsi"
/ {
model = "Hardkernel Odroid XU3";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Exynos5422 odroidxu3 pwm-fan control using thermal sensors
This work depeds upon work done by Lukasz Majewski and Sjoerd Simons regarding the pwm-fan. -Anand Moon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/9] eeprom: Add a simple EEPROM framework for eeprom providers
On 24/03/15 22:53, Mark Brown wrote:
On Tue, Mar 24, 2015 at 10:30:08PM +, Srinivas Kandagatla wrote:
+static ssize_t bin_attr_eeprom_write(struct file *filp, struct kobject *kobj,
+struct bin_attribute *attr,
+char *buf, loff_t offset, size_t count)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct eeprom_device *eeprom = to_eeprom(dev);
+ int rc;
+
+ if (offset > eeprom->size)
+ return -EINVAL;
+
+ if (offset + count > eeprom->size)
+ count = eeprom->size - offset;
+
+ rc = regmap_bulk_write(eeprom->regmap, offset,
+ buf, count/eeprom->stride);
Are you sure that this and the read interface should be using the bulk
interface and not the raw interface - do we want the byte swapping that
the bulk interface provides?
You are correct, byte swapping is not really needed in this cases.
It should read/write data as it is.
I will fix it in next version.
I'm also not entirely able to convince myself that the above error
checks and code line up with what I'd expect the userspace ABI to be, we
seem to be treating offset as both a byte offset into the data (which is
what I'd expect the userspace ABI to do) and a word based index into the
data (which is what the regmap API is doing). For example with 16 bit
words offset 2 will start at the 5th byte of data but if userspace seeks
to offset 5 it will get the 11th byte and onwards.
Thanks for spotting this, Yes, the offset from userspace should be
treated as byte oriented and the offset to regmap as word based index
into the data.
Yes, logic here needs a fix to handle data correctly.
The stride and the word size are separate, they will frequently line up
for memory mapped devices but typically won't for other devices. I
think you need more data mangling to handle this robustly.
Yes, I agree I will address this too in next version.
thanks,
srini
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/15] serial: stm32-usart: Add STM32 USART Driver
On Tue, Mar 24, 2015 at 02:23:38PM -0400, Peter Hurley wrote:
> Hi Maxime,
>
> On 03/12/2015 05:55 PM, Maxime Coquelin wrote:
> > +static unsigned int stm32_get_mctrl(struct uart_port *port)
> > +{
> > + /*
> > +* This routine is used for geting signals of: DTR, DCD, DSR, RI,
> > +* and CTS/RTS
It's also worth noting that this comment is wrong. This is used to get
the state of DCD, DSR, RI and CTS. DTR and RTS are *not* included
because the core tracks their state.
...
> > + stm32port->clk = devm_clk_get(&pdev->dev, NULL);
> > +
> > + if (WARN_ON(IS_ERR(stm32port->clk)))
>
> Do you really need a stack trace here? Could this be dev_err() instead?
>
> > + return -EINVAL;
Also, propagate the error code.
> > +
> > + /* ensure that clk rate is correct by enabling the clk */
> > + clk_prepare_enable(stm32port->clk);
And remember to check the return value of clk_prepare_enable().
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] dmaengine: Add driver for TI DMA crossbar on DRA7x
On Thu, Mar 26, 2015 at 02:31:30PM +0200, Peter Ujfalusi wrote:
> On 03/26/2015 12:56 PM, Vinod Koul wrote:
> >> +#define TI_XBAR_OUTPUTS 127
> >> +#define TI_XBAR_INPUTS256
> > Ideally this should be moved to DT. Will next revision of this chip always
> > support these output and inputs?
>
> They are coming from DT. I'm using these as fall back values in case we can
> not get this from DT and a warning will be printed in case if this unlikely
> event happens.
Oops missed, that. Looks fine then
>
> >> +
> >> +static DEFINE_IDR(map_idr);
> >> +
> >> +struct ti_dma_xbar_data {
> >> + struct dma_router dmarouter;
> >> + struct regmap *regmap;
> >> +
> >> + uint safe_val; /* Value to rest the crossbar lines */
> >> + uint xbar_requests; /* number of DMA requests connected to XBAR */
> >> + uint dma_requests; /* number of DMA requests forwarded to DMA */
> >> +
> >> + void __iomem *iomem;
> >> +};
> >> +
> >> +struct ti_dma_xbar_map {
> >> + int xbar_in;
> >> + int xbar_out;
> >> +};
> >> +
> >> +static void ti_dma_xbar_free(struct device *dev, void *route_data)
> >> +{
> >> + struct ti_dma_xbar_data *xbar = dev_get_drvdata(dev);
> >> + struct ti_dma_xbar_map *map = route_data;
> >> +
> >> + dev_dbg(dev, "Unmapping XBAR%d (was routed to %d)\n",
> >> + map->xbar_in, map->xbar_out);
> >> +
> >> + regmap_write(xbar->regmap, map->xbar_out * 2, 0);
> > just out of curiosity how much do you save using regmap :)
>
> good point, not much I guess. I had it implemented w/o regmap as well, but
> thought why not use regmap if it is available.
Yes but there is overhead involved in setting it up. I though you have some
latency issues. It is okay to have it :)
Cache is anyways fastest :)
> >> +static int ti_dma_xbar_probe(struct platform_device *pdev)
> >> +{
> >> + struct device_node *node = pdev->dev.of_node;
> >> + struct device_node *dma_node;
> >> + struct ti_dma_xbar_data *xbar;
> >> + struct resource *res;
> >> + void __iomem *iomem;
> >> + int i, ret;
> >> +
> >> + if (!node)
> >> + return -ENODEV;
> >> +
> >> + dma_node = of_parse_phandle(node, "dma-device", 0);
> >> + if (!dma_node) {
> >> + dev_err(&pdev->dev, "Can't get target DMA node\n");
> >> + return -ENODEV;
> >> + }
> >> +
> >> + xbar = devm_kzalloc(&pdev->dev, sizeof(*xbar), GFP_KERNEL);
> >> + if (!xbar)
> >> + return -ENOMEM;
> >> +
> >> + if (of_property_read_u32(dma_node, "dma-requests",
> >> + &xbar->dma_requests)) {
> >> + dev_info(&pdev->dev,
> >> + "Missing XBAR output information, using %u.\n",
> >> + TI_XBAR_OUTPUTS);
> >> + xbar->dma_requests = TI_XBAR_OUTPUTS;
> >> + }
> >> + of_node_put(dma_node);
> > _put here?
>
> The code takes the real dma controller's node and it should be put back after
> I have got the information I needed from it (number of DMA requests).
>
> >
> >> +int omap_dmaxbar_init(void)
> >> +{
> >> + return platform_driver_register(&ti_dma_xbar_driver);
> >> +}
> >> +arch_initcall(omap_dmaxbar_init);
> > why arch_initcall?
>
> It should be on the same init level as the real DMA controller. omap-dma at
> the moment, but in some platforms this can work with the edma as well.
> Since all device in the system (well most of them anyway) uses DMA it is
> better to not delay their probe with deferring because the crossbar driver is
> still not loaded
Deferring if resources not available is the right thing and helps you get rid
of init level ordering magic...
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] dmaengine: of_dma: Support for DMA routers
On Thu, Mar 26, 2015 at 02:11:38PM +0200, Peter Ujfalusi wrote: > On 03/26/2015 12:50 PM, Vinod Koul wrote: > > On Wed, Mar 11, 2015 at 03:23:24PM +0200, Peter Ujfalusi wrote: > >> DMA routers are transparent devices used to mux DMA requests from > >> peripherals to DMA controllers. They are used when the SoC integrates more > >> devices with DMA requests then their controller can handle. > >> DRA7x is one example of such SoC, where the sDMA can hanlde 128 DMA request > >> lines, but in SoC level it has 205 DMA requests. > >> > >> The of_dma_router will be registered as of_dma_controller with special > >> xlate function and additional parameters and the code will translate and > >> requests a DMA channel from the real DMA controller. > >> This way the router can be transparent for the system while remaining > >> generic > >> enough to be used in different environments. > >> > > Looks fine, was expecting a Documentation updates as well, but that can come > > as follow up patch too > > I have added the DT binding document since this series adds support for > routers for platforms booting with DT: > > Documentation/devicetree/bindings/dma/dma.txt | 28 I meant the update to Documnetation/dmanegine/ for routers :) -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: hummingboard: enable PCF8523 RTC support
On Tue, Mar 24, 2015 at 08:14:31PM +0800, Shawn Guo wrote: > On Mon, Mar 02, 2015 at 08:03:54PM +, Russell King wrote: > > Enable the commented out PCF8523 RTC support for Hummingboard pro > > base boards. > > > > Signed-off-by: Russell King > > --- > > For acks please. > > Russell, > > What do you mean by "For acks please"? Not for apply? I'm asking if I > should pick up the patches. I think you can - I don't have anything else outstanding at the moment for the DTS. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] dmaengine: Add driver for TI DMA crossbar on DRA7x
* Peter Ujfalusi [150326 05:32]:
> On 03/26/2015 12:56 PM, Vinod Koul wrote:
> >> +
> >> +static void ti_dma_xbar_free(struct device *dev, void *route_data)
> >> +{
> >> + struct ti_dma_xbar_data *xbar = dev_get_drvdata(dev);
> >> + struct ti_dma_xbar_map *map = route_data;
> >> +
> >> + dev_dbg(dev, "Unmapping XBAR%d (was routed to %d)\n",
> >> + map->xbar_in, map->xbar_out);
> >> +
> >> + regmap_write(xbar->regmap, map->xbar_out * 2, 0);
> > just out of curiosity how much do you save using regmap :)
>
> good point, not much I guess. I had it implemented w/o regmap as well, but
> thought why not use regmap if it is available.
Regmap is nice for slow devices and devices in a shared register
range like the omap syscon general area. For normal use, there's
quite a bit of overhead with regmap compared to just read/write :)
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] ARM: dts: sun4i: Add A10 SRAM and SRAM controller
The A10 has a few SRAM that can be mapped either to a device or to the CPU,
with the mapping being controlled by a SRAM controller.
Since most of the time these SRAM won't be accessible by the CPU,
we can't use the mmio-sram driver and compatible.
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/sun4i-a10.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 59fc7f7..595b77c 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -451,12 +451,46 @@
};
};
+ /*
+* Note we use the address where the mmio registers start, not where
+* the SRAM blocks start, this cannot be changed because that would be
+* a devicetree ABI change.
+*/
soc@01c0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ sram@ {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x 0x4000>;
+ allwinner,sram-name = "A1";
+ };
+
+ sram@4000 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x4000 0x4000>;
+ allwinner,sram-name = "A2";
+ };
+
+ sram@8000 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x8000 0x4000>;
+ allwinner,sram-name = "A3-A4";
+ };
+
+ sram@0001 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x0001 0x1000>;
+ allwinner,sram-name = "D";
+ };
+
+ sram-controller@01c0 {
+ compatible = "allwinner,sun4i-a10-sram-controller";
+ reg = <0x01c0 0x30>;
+ };
+
dma: dma-controller@01c02000 {
compatible = "allwinner,sun4i-a10-dma";
reg = <0x01c02000 0x1000>;
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] net: allwinner: emac: Claim our SRAM
From: Maxime Ripard
The SRAM the EMAC is using might not have been mapped accordingly by the
bootloader, preventing the EMAC to work properly.
Ask for that SRAM to be mapped at probe time to make sure that this never
happens.
Signed-off-by: Maxime Ripard
[hdego...@redhat.com: Make sure SUNXI_SRAM gets enabled in Kconfig]
Signed-off-by: Hans de Goede
---
drivers/net/ethernet/allwinner/sun4i-emac.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c
b/drivers/net/ethernet/allwinner/sun4i-emac.c
index f3470d9..9d0136b 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -29,6 +29,8 @@
#include
#include
+#include
+
#include "sun4i-emac.h"
#define DRV_NAME "sun4i-emac"
@@ -857,11 +859,15 @@ static int emac_probe(struct platform_device *pdev)
clk_prepare_enable(db->clk);
+ ret = sunxi_sram_claim(SUNXI_SRAM_EMAC, "emac");
+ if (ret)
+ dev_warn(&pdev->dev, "Couldn't map SRAM to device\n");
+
db->phy_node = of_parse_phandle(np, "phy", 0);
if (!db->phy_node) {
dev_err(&pdev->dev, "no associated PHY\n");
ret = -ENODEV;
- goto out;
+ goto out_release_sram;
}
/* Read MAC-address from DT */
@@ -893,7 +899,7 @@ static int emac_probe(struct platform_device *pdev)
if (ret) {
dev_err(&pdev->dev, "Registering netdev failed!\n");
ret = -ENODEV;
- goto out;
+ goto out_release_sram;
}
dev_info(&pdev->dev, "%s: at %p, IRQ %d MAC: %pM\n",
@@ -901,6 +907,8 @@ static int emac_probe(struct platform_device *pdev)
return 0;
+out_release_sram:
+ sunxi_sram_release(SUNXI_SRAM_EMAC);
out:
dev_err(db->dev, "not found (%d).\n", ret);
@@ -914,6 +922,7 @@ static int emac_remove(struct platform_device *pdev)
struct net_device *ndev = platform_get_drvdata(pdev);
unregister_netdev(ndev);
+ sunxi_sram_release(SUNXI_SRAM_EMAC);
free_netdev(ndev);
dev_dbg(&pdev->dev, "released and freed device\n");
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] ARM: sunxi: SRAM mapping support
Hi All, Here is v2 of my cleaned up version of Maxime's sunxi SRAM controller driver. Changes since v1: - Make the SUNXI_SRAM Kconfig option hidden, enabled by default if ARCH_SUNXI - Fix some typos in the comments in the dts file, both in the example in the devicetree-binding documentation, as well as in the actual dts files - Drop the bogus change to drivers/net/ethernet/stmicro/stmmac/Kconfig Since this is a prereq for my musb work, if there are no objections then I would like to see this go upstream soon. Since it only touches sunxi files (and one Makefile), it is probably best if this all goes upstream through Maxime. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] ARM: dts: sun5i: Add A13 and A10s SRAM and SRAM controller
The A13 / A10s has a few SRAM that can be mapped either to a device or to
the CPU, with the mapping being controlled by a SRAM controller.
Since most of the time these SRAM won't be accessible by the CPU,
we can't use the mmio-sram driver and compatible.
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/sun5i.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index c797d88..8c04f24 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -298,12 +298,46 @@
};
};
+ /*
+* Note we use the address where the mmio registers start, not where
+* the SRAM blocks start, this cannot be changed because that would be
+* a devicetree ABI change.
+*/
soc@01c0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ sram@ {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x 0x4000>;
+ allwinner,sram-name = "A1";
+ };
+
+ sram@4000 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x4000 0x4000>;
+ allwinner,sram-name = "A2";
+ };
+
+ sram@8000 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x8000 0x4000>;
+ allwinner,sram-name = "A3-A4";
+ };
+
+ sram@0001 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x0001 0x1000>;
+ allwinner,sram-name = "D";
+ };
+
+ sram-controller@01c0 {
+ compatible = "allwinner,sun4i-a10-sram-controller";
+ reg = <0x01c0 0x30>;
+ };
+
dma: dma-controller@01c02000 {
compatible = "allwinner,sun4i-a10-dma";
reg = <0x01c02000 0x1000>;
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] ARM: dts: sun7i: Add A20 SRAM and SRAM controller
From: Maxime Ripard
The A20 has a few SRAM that can be mapped either to a device or to the CPU,
with the mapping being controlled by a SRAM controller.
Since most of the time these SRAM won't be accessible by the CPU,
we can't use the mmio-sram driver and compatible.
Signed-off-by: Maxime Ripard
[hdego...@redhat.com: Do not change soc node name, change compatible to
sun4i-a10-sram-controller to match the driver change]
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/sun7i-a20.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 465a19f..e6f4a33 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -529,12 +529,46 @@
};
};
+ /*
+* Note we use the address where the mmio registers start, not where
+* the SRAM blocks start, this cannot be changed because that would be
+* a devicetree ABI change.
+*/
soc@01c0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ sram@ {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x 0x4000>;
+ allwinner,sram-name = "A1";
+ };
+
+ sram@4000 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x4000 0x4000>;
+ allwinner,sram-name = "A2";
+ };
+
+ sram@8000 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x8000 0x4000>;
+ allwinner,sram-name = "A3-A4";
+ };
+
+ sram@0001 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x0001 0x1000>;
+ allwinner,sram-name = "D";
+ };
+
+ sram-controller@01c0 {
+ compatible = "allwinner,sun4i-a10-sram-controller";
+ reg = <0x01c0 0x30>;
+ };
+
nmi_intc: interrupt-controller@01c00030 {
compatible = "allwinner,sun7i-a20-sc-nmi";
interrupt-controller;
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] drivers: soc: sunxi: Introduce SoC driver to map SRAMs
From: Maxime Ripard
The Allwinner SoCs have a handful of SRAM that can be either mapped to be
accessible by devices or the CPU.
That mapping is controlled by an SRAM controller, and that mapping might not be
set by the bootloader, for example if the device wasn't used at all, or if
we're using solutions like the U-Boot's Falcon Boot.
We could also imagine changing this at runtime for example to change the
mapping of these SRAMs to use them for suspend/resume or runtime memory rate
change, if that ever happens.
These use cases require some API in the kernel to control that mapping,
exported through a drivers/soc driver.
This driver also implement a debugfs file that shows the SRAM found in the
system, the current mapping and the SRAM that have been claimed by some drivers
in the kernel.
Signed-off-by: Maxime Ripard
[hdego...@redhat.com: Changed compat string to sun4i-a10-sram-controller, as
the sram controller is identical on sun4i, sun5i & sun7i, added devicetree
binding documentation, fixed some checkpatch warnings]
Signed-off-by: Hans de Goede
---
.../devicetree/bindings/soc/sunxi/sram.txt | 64 ++
drivers/soc/Kconfig| 1 +
drivers/soc/Makefile | 1 +
drivers/soc/sunxi/Kconfig | 11 +
drivers/soc/sunxi/Makefile | 1 +
drivers/soc/sunxi/sunxi_sram.c | 235 +
include/linux/soc/sunxi/sunxi_sram.h | 24 +++
7 files changed, 337 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/sunxi/sram.txt
create mode 100644 drivers/soc/sunxi/Kconfig
create mode 100644 drivers/soc/sunxi/Makefile
create mode 100644 drivers/soc/sunxi/sunxi_sram.c
create mode 100644 include/linux/soc/sunxi/sunxi_sram.h
diff --git a/Documentation/devicetree/bindings/soc/sunxi/sram.txt
b/Documentation/devicetree/bindings/soc/sunxi/sram.txt
new file mode 100644
index 000..bd3e53d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/sunxi/sram.txt
@@ -0,0 +1,64 @@
+Allwinnner sun4i / sun5i / sun7i SoC SRAM controllers
+-
+
+Required properties:
+- compatible : "allwinner,sun4i-a10-sram-controller"
+- reg : sram controller register offset + length
+
+SRAM nodes
+--
+
+Besides a node for the SRAM controller the devicetree must also contain a
+node for each SRAM block controlled by the controller.
+
+Required sram node properties:
+- compatible : "allwinner,sun4i-a10-sram"
+- allwinner,sram-name : should be one of
+ * "A1"
+ * "A2"
+ * "A3-A4"
+ * "D"
+
+Example
+---
+
+/*
+ * Note we use the address where the mmio registers start, not where
+ * the SRAM blocks start, this cannot be changed because that would be
+ * a devicetree ABI change.
+ */
+soc@01c0 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ sram@ {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x 0x4000>;
+ allwinner,sram-name = "A1";
+ };
+
+ sram@4000 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x4000 0x4000>;
+ allwinner,sram-name = "A2";
+ };
+
+ sram@8000 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x8000 0x4000>;
+ allwinner,sram-name = "A3-A4";
+ };
+
+ sram@0001 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x0001 0x1000>;
+ allwinner,sram-name = "D";
+ };
+
+ sram-controller@01c0 {
+ compatible = "allwinner,sun4i-a10-sram-controller";
+ reg = <0x01c0 0x30>;
+ };
+};
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 76d6bd4..5d0f55d 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,6 +1,7 @@
menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/sunxi/Kconfig"
source "drivers/soc/ti/Kconfig"
source "drivers/soc/versatile/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 063113d..170bba3 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_ARCH_QCOM)+= qcom/
+obj-$(CONFIG_ARCH_SUNXI) += sunxi/
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_SOC_TI) += ti/
obj-$(CONFIG_PLAT_VERSATILE) += versatile/
diff --git a/drivers/soc/sunxi/Kconfig b/drivers/soc/sunxi/Kconfig
new file mode 100644
index 000..e6de9fe
--- /dev/null
+++ b/drivers/soc/sunxi/Kconfig
@@ -0,0 +1,11 @@
+#
+# Allwinner sunXi SoC drivers
+#
+config SUNXI_SRAM
+ boolean
+ depends on ARCH_SUNXI
+ default y
+ help
+ Say y here to enable the SRAM controller support. This
+ device is responsible on map
Re: [PATCH 5/5] net: allwinner: emac: Claim our SRAM
Hi,
On 24-03-15 16:22, Maxime Ripard wrote:
On Fri, Mar 20, 2015 at 07:52:49PM +0100, Hans de Goede wrote:
From: Maxime Ripard
The SRAM the EMAC is using might not have been mapped accordingly by the
bootloader, preventing the EMAC to work properly.
Ask for that SRAM to be mapped at probe time to make sure that this never
happens.
Signed-off-by: Maxime Ripard
[hdego...@redhat.com: Make sure SUNXI_SRAM gets enabled in Kconfig]
Signed-off-by: Hans de Goede
---
drivers/net/ethernet/allwinner/sun4i-emac.c | 13 +++--
drivers/net/ethernet/stmicro/stmmac/Kconfig | 1 +
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c
b/drivers/net/ethernet/allwinner/sun4i-emac.c
index f3470d9..9d0136b 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -29,6 +29,8 @@
#include
#include
+#include
+
#include "sun4i-emac.h"
#define DRV_NAME "sun4i-emac"
@@ -857,11 +859,15 @@ static int emac_probe(struct platform_device *pdev)
clk_prepare_enable(db->clk);
+ ret = sunxi_sram_claim(SUNXI_SRAM_EMAC, "emac");
+ if (ret)
+ dev_warn(&pdev->dev, "Couldn't map SRAM to device\n");
+
db->phy_node = of_parse_phandle(np, "phy", 0);
if (!db->phy_node) {
dev_err(&pdev->dev, "no associated PHY\n");
ret = -ENODEV;
- goto out;
+ goto out_release_sram;
}
/* Read MAC-address from DT */
@@ -893,7 +899,7 @@ static int emac_probe(struct platform_device *pdev)
if (ret) {
dev_err(&pdev->dev, "Registering netdev failed!\n");
ret = -ENODEV;
- goto out;
+ goto out_release_sram;
}
dev_info(&pdev->dev, "%s: at %p, IRQ %d MAC: %pM\n",
@@ -901,6 +907,8 @@ static int emac_probe(struct platform_device *pdev)
return 0;
+out_release_sram:
+ sunxi_sram_release(SUNXI_SRAM_EMAC);
out:
dev_err(db->dev, "not found (%d).\n", ret);
@@ -914,6 +922,7 @@ static int emac_remove(struct platform_device *pdev)
struct net_device *ndev = platform_get_drvdata(pdev);
unregister_netdev(ndev);
+ sunxi_sram_release(SUNXI_SRAM_EMAC);
free_netdev(ndev);
dev_dbg(&pdev->dev, "released and freed device\n");
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig
b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 7d3af19..785ca22 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -16,6 +16,7 @@ if STMMAC_ETH
config STMMAC_PLATFORM
tristate "STMMAC Platform bus support"
depends on STMMAC_ETH
+ select SUNXI_SRAM if ARCH_SUNXI
default y
---help---
This selects the platform specific bus support for the stmmac driver.
Shouldn't that be in emac's Kconfig option instead?
Erm, yes my bad, or rather now that we've made SUNXI_SRAM a hidden option
defaulting
to y, it can simply be dropped. I've done that for v2 of the set which I'm
about to
send.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] ARM: dts: sun4i: Add A10 SRAM and SRAM controller
Hi,
On 24-03-15 16:20, Maxime Ripard wrote:
On Fri, Mar 20, 2015 at 07:52:46PM +0100, Hans de Goede wrote:
The A10 has a few SRAM that can be mapped either to a device or to the CPU,
with the mapping being controlled by a SRAM controller.
Since most of the time these SRAM won't be accessible by the CPU,
we can't use the mmio-sram driver and compatible.
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/sun4i-a10.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index b66ebb3..88f57b4 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -451,12 +451,46 @@
};
};
+ /*
+* Note we use the address were mmio registers start, not where the
^ where
Fixed in patches 2 to 4.
Regards,
Hans
+* SRAM blocks start, this cannot be changed because that would be
+* a devicetree ABI change.
+*/
soc@01c0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ sram@ {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x 0x4000>;
+ allwinner,sram-name = "A1";
+ };
+
+ sram@4000 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x4000 0x4000>;
+ allwinner,sram-name = "A2";
+ };
+
+ sram@8000 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x8000 0x4000>;
+ allwinner,sram-name = "A3-A4";
+ };
+
+ sram@0001 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x0001 0x1000>;
+ allwinner,sram-name = "D";
+ };
+
+ sram-controller@01c0 {
+ compatible = "allwinner,sun4i-a10-sram-controller";
+ reg = <0x01c0 0x30>;
+ };
+
dma: dma-controller@01c02000 {
compatible = "allwinner,sun4i-a10-dma";
reg = <0x01c02000 0x1000>;
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] drivers: soc: sunxi: Introduce SoC driver to map SRAMs
Hi,
On 24-03-15 16:19, Maxime Ripard wrote:
Hi,
On Fri, Mar 20, 2015 at 07:52:45PM +0100, Hans de Goede wrote:
From: Maxime Ripard
The Allwinner SoCs have a handful of SRAM that can be either mapped to be
accessible by devices or the CPU.
That mapping is controlled by an SRAM controller, and that mapping might not be
set by the bootloader, for example if the device wasn't used at all, or if
we're using solutions like the U-Boot's Falcon Boot.
We could also imagine changing this at runtime for example to change the
mapping of these SRAMs to use them for suspend/resume or runtime memory rate
change, if that ever happens.
These use cases require some API in the kernel to control that mapping,
exported through a drivers/soc driver.
This driver also implement a debugfs file that shows the SRAM found in the
system, the current mapping and the SRAM that have been claimed by some drivers
in the kernel.
Signed-off-by: Maxime Ripard
[hdego...@redhat.com: Changed compat string to sun4i-a10-sram-controller, as
the sram controller is identical on sun4i, sun5i & sun7i, added devicetree
binding documentation, fixed some checkpatch warnings]
Signed-off-by: Hans de Goede
---
.../devicetree/bindings/soc/sunxi/sram.txt | 64 ++
drivers/soc/Kconfig| 1 +
drivers/soc/Makefile | 1 +
drivers/soc/sunxi/Kconfig | 12 ++
drivers/soc/sunxi/Makefile | 1 +
drivers/soc/sunxi/sunxi_sram.c | 235 +
include/linux/soc/sunxi/sunxi_sram.h | 24 +++
7 files changed, 338 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/sunxi/sram.txt
create mode 100644 drivers/soc/sunxi/Kconfig
create mode 100644 drivers/soc/sunxi/Makefile
create mode 100644 drivers/soc/sunxi/sunxi_sram.c
create mode 100644 include/linux/soc/sunxi/sunxi_sram.h
diff --git a/Documentation/devicetree/bindings/soc/sunxi/sram.txt
b/Documentation/devicetree/bindings/soc/sunxi/sram.txt
new file mode 100644
index 000..6e1bc80
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/sunxi/sram.txt
@@ -0,0 +1,64 @@
+Allwinnner sun4i / sun5i / sun7i SoC SRAM controllers
+-
+
+Required properties:
+- compatible : "allwinner,sun4i-a10-sram-controller"
+- reg : sram controller register offset + length
+
+SRAM nodes
+--
+
+Besides a node for the SRAM controller the devicetree must also contain a
+node for each SRAM block controlled by the controller.
+
+Required sram node properties:
+- compatible : "allwinner,sun4i-a10-sram"
+- allwinner,sram-name : should be one of
+ * "A1"
+ * "A2"
+ * "A3-A4"
+ * "D"
+
+Example
+---
+
+/*
+ * Note we use the address were mmio register start, not where
^ where
+ * the SRAM blocks starts, this cannot be changed because doing
^ start
+ * doing so would be a devicetree ABI change.
One doing too many ? :)
Both fixed.
+ */
+soc@01c0 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ sram@ {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x 0x4000>;
+ allwinner,sram-name = "A1";
+ };
+
+ sram@4000 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x4000 0x4000>;
+ allwinner,sram-name = "A2";
+ };
+
+ sram@8000 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x8000 0x4000>;
+ allwinner,sram-name = "A3-A4";
+ };
+
+ sram@0001 {
+ compatible = "allwinner,sun4i-a10-sram";
+ reg = <0x0001 0x1000>;
+ allwinner,sram-name = "D";
+ };
+
+ sram-controller@01c0 {
+ compatible = "allwinner,sun4i-a10-sram-controller";
+ reg = <0x01c0 0x30>;
+ };
+};
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 76d6bd4..5d0f55d 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,6 +1,7 @@
menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/sunxi/Kconfig"
source "drivers/soc/ti/Kconfig"
source "drivers/soc/versatile/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 063113d..170bba3 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_ARCH_QCOM) += qcom/
+obj-$(CONFIG_ARCH_SUNXI) += sunxi/
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_SOC_TI) += ti/
obj-$(CONFIG_PLAT_VERSATILE) += versatile/
diff --git a/drivers/soc/sunxi/Kconfig b/drivers/soc/sunxi/Kconfig
new file mode 100644
index 000..212c634
--- /dev/null
+++ b/drivers/soc/sunxi/Kcon
Re: [PATCH 3/4] clk: hisi: add stub clk driver
On Thu, Mar 26, 2015 at 07:13:38PM +0800, Leo Yan wrote:
> +static unsigned long hisi_stub_clk_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
...
> + BUG_ON(!stub_clk->lock);
...
> +static int hisi_stub_clk_set_rate(struct clk_hw *hw, unsigned long rate,
> +unsigned long parent_rate)
> +{
...
> + BUG_ON(!stub_clk->lock);
...
> +static long hisi_stub_clk_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *parent_rate)
> +{
...
> + BUG_ON(!stub_clk->lock);
...
> +static struct clk_ops hisi_stub_clk_ops = {
> + .recalc_rate= hisi_stub_clk_recalc_rate,
> + .round_rate = hisi_stub_clk_round_rate,
> + .set_rate = hisi_stub_clk_set_rate,
> +};
...
> +static struct clk *_register_stub_clk(struct device *dev, unsigned int id,
> + const char *name, const char *parent_name, unsigned long flags,
> + spinlock_t *lock)
> +{
> + struct hisi_stub_clk *stub_clk;
> + struct clk *clk;
> + struct clk_init_data init;
> +
> + stub_clk = kzalloc(sizeof(*stub_clk), GFP_KERNEL);
> + if (!stub_clk) {
> + pr_err("%s: fail to alloc stub clk!\n", __func__);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + init.name = name;
> + init.ops = &hisi_stub_clk_ops;
> + init.parent_names = parent_name ? &parent_name : NULL;
> + init.num_parents = parent_name ? 1 : 0;
> + init.flags = flags;
> +
> + stub_clk->hw.init = &init;
> + stub_clk->id = id;
> + stub_clk->lock = lock;
Under what scenario is it safe to call _register_stub_clk() with a NULL
lock argument?
If lock is NULL, then every function callable via the ops structure
will bug.
Rather than doing a test in each method function, do it in
_register_stub_clk() - this means we aren't waiting for a NULL pointer
deref when one of these method functions gets called.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] clk: hisi: add API for allocation clk data struct
On Thu, Mar 26, 2015 at 07:13:36PM +0800, Leo Yan wrote:
> +struct hisi_clock_data __init *hisi_clk_init(struct device_node *np,
> + int nr_clks)
> +{
> + struct hisi_clock_data *clk_data;
> + void __iomem *base;
> +
> + if (np) {
> + base = of_iomap(np, 0);
> + if (!base) {
> + pr_err("failed to map Hisilicon clock registers\n");
> + return NULL;
> + }
> + printk("%s: base %p\n", __func__, base);
Did you leave your debugging in?
> + } else {
> + pr_err("failed to find Hisilicon clock node in DTS\n");
> + return NULL;
> + }
I know you're mostly only moving this code, but it would be far better if
it were written:
if (!np) {
pr_err("failed to find Hisilicon clock node in DTS\n");
return NULL;
}
base = of_iomap(np, 0);
if (!base) {
pr_err("failed to map Hisilicon clock registers\n");
return NULL;
}
Possibly do this first as a separate patch, and then move the code.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 02/11] DT: Add documentation for the mfd Maxim max77693
On Fri, 20 Mar 2015, Jacek Anaszewski wrote:
> This patch adds device tree binding documentation for
> the flash cell of the Maxim max77693 multifunctional device.
>
> Signed-off-by: Jacek Anaszewski
> Signed-off-by: Andrzej Hajda
> Acked-by: Kyungmin Park
> Cc: Lee Jones
> Cc: Chanwoo Choi
> Cc: Bryan Wu
> Cc: Richard Purdie
> ---
> Documentation/devicetree/bindings/mfd/max77693.txt | 61
>
> 1 file changed, 61 insertions(+)
Bryan and/or one of the DT folks really need to Ack this.
> diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt
> b/Documentation/devicetree/bindings/mfd/max77693.txt
> index 38e6440..15c546e 100644
> --- a/Documentation/devicetree/bindings/mfd/max77693.txt
> +++ b/Documentation/devicetree/bindings/mfd/max77693.txt
> @@ -76,7 +76,53 @@ Optional properties:
> Valid values: 430, 470, 480, 490
> Default: 430
>
> +- led : the LED submodule device node
> +
> +There are two LED outputs available - FLED1 and FLED2. Each of them can
> +control a separate LED or they can be connected together to double
> +the maximum current for a single connected LED. One LED is represented
> +by one child node.
> +
> +Required properties:
> +- compatible : Must be "maxim,max77693-led".
> +
> +Optional properties:
> +- maxim,trigger-type : Flash trigger type.
> + Possible trigger types:
> + LEDS_TRIG_TYPE_EDGE (0) - Rising edge of the signal triggers
> + the flash,
> + LEDS_TRIG_TYPE_LEVEL (1) - Strobe pulse length controls duration
> + of the flash.
> +- maxim,boost-mode :
> + In boost mode the device can produce up to 1.2A of total current
> + on both outputs. The maximum current on each output is reduced
> + to 625mA then. If not enabled explicitly, boost setting defaults to
> + LEDS_BOOST_FIXED in case both current sources are used.
> + Possible values:
> + LEDS_BOOST_OFF (0) - no boost,
> + LEDS_BOOST_ADAPTIVE (1) - adaptive mode,
> + LEDS_BOOST_FIXED (2) - fixed mode.
> +- maxim,boost-mvout : Output voltage of the boost module in millivolts.
> +- maxim,mvsys-min : Low input voltage level in millivolts. Flash is not fired
> + if chip estimates that system voltage could drop below this level due
> + to flash power consumption.
> +
> +Required properties of the LED child node:
> +- led-sources : see Documentation/devicetree/bindings/leds/common.txt;
> + device current output identifiers: 0 - FLED1, 1 - FLED2
> +
> +Optional properties of the LED child node:
> +- label : see Documentation/devicetree/bindings/leds/common.txt
> +- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
> + Range: 15625 - 25
> +- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
> + Range: 15625 - 100
> +- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
> + Range: 62500 - 100
> +
> Example:
> +#include
> +
> max77693@66 {
> compatible = "maxim,max77693";
> reg = <0x66>;
> @@ -117,5 +163,20 @@ Example:
> maxim,thermal-regulation-celsius = <75>;
> maxim,battery-overcurrent-microamp = <300>;
> maxim,charge-input-threshold-microvolt = <430>;
> +
> + led {
> + compatible = "maxim,max77693-led";
> + maxim,trigger-type = ;
> + maxim,boost-mode = ;
> + maxim,boost-mvout = <5000>;
> + maxim,mvsys-min = <2400>;
> +
> + camera_flash: flash-led {
> + label = "max77693-flash";
> + led-sources = <0>, <1>;
> + max-microamp = <50>;
> + flash-max-microamp = <125>;
> + flash-timeout-us = <100>;
> + };
> };
> };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] DT: leds: Add uniqueness requirement for 'label' property.
Label is used for naming LED class devices. Since ePAPR doesn't require uniqueness for label properties, it has to be explicitly required in the LEDs common bindings documentation. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Bryan Wu Cc: Richard Purdie Cc: Sakari Ailus Cc: devicetree@vger.kernel.org --- Documentation/devicetree/bindings/leds/common.txt |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index 34811c5..747c538 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -14,8 +14,10 @@ Optional properties for child nodes: - led-sources : List of device current outputs the LED is connected to. The outputs are identified by the numbers that must be defined in the LED device binding documentation. -- label : The label for this LED. If omitted, the label is - taken from the node name (excluding the unit address). +- label : The label for this LED. If omitted, the label is taken from the node + name (excluding the unit address). It has to uniquely identify + a device, i.e. no other LED class device can be assigned the same + label. - linux,default-trigger : This parameter, if present, is a string defining the trigger assigned to the LED. Current triggers are: -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/5] power: max77843_charger: Add Max77843 charger device driver
On Thu, 26 Mar 2015, Beomho Seo wrote: > On 03/24/2015 05:38 PM, Krzysztof Kozlowski wrote: > > 2015-03-24 9:01 GMT+01:00 Beomho Seo : > >> On 03/10/2015 10:44 PM, Beomho Seo wrote: > >>> On 03/09/2015 09:13 PM, Krzysztof Kozlowski wrote: > On pon, 2015-03-09 at 20:46 +0900, Beomho Seo wrote: > > On 03/09/2015 08:02 PM, Krzysztof Kozlowski wrote: > >> 2015-03-09 1:35 GMT+01:00 Beomho Seo : > >>> On 03/08/2015 05:13 AM, Sebastian Reichel wrote: > On Mon, Mar 02, 2015 at 07:10:35PM +0900, Jaewon Kim wrote: > > From: Beomho Seo > > > > This patch adds device driver of max77843 charger. This driver > > provide > > initialize each charging mode(e.g. fast charge, top-off mode and > > constant > > charging mode so on.). Additionally, control charging paramters to > > use > > i2c interface. > > > > Cc: Sebastian Reichel > > Signed-off-by: Beomho Seo > > Reviewed-By: Sebastian Reichel > > I can't take it as is, since it depends on the private header file > of PATCHv1. > > -- Sebastian > > >>> > >>> This patch reviewed by Sebastian. > >>> Could you Please merge that your git tree ? > >> > >> Hi, > >> > >> ... and again we are adding a new driver for very similar chipset to > >> already supported. I looked at spec and the charger's registers are > >> almost the same as for max77693. Their layout and addresses are the > >> same. I see some minor differences, probably the most important would > >> be different values current (fast-charge, top-off). But still 90% of > >> registers are the same... Do we really have to add new driver? > >> > >> Best regards, > >> Krzysztof > >> > > > > Hi, > > > > Thank you for your comment. As you say, both chip set are similar. > > But new driver need for support max77843. It is support different below > > - Provide Battery presence information. > > Another set of power supply properties could be added for that chip. > This way the get_property() function would be the same but actually the > POWER_SUPPLY_PROP_PRESENT won't be called for max77693. > > > - Can OTG FET control. > > Where the OTG FET feature is it enabled in your driver? I couldn't find > it. > > >>> > >>> Sorry. This driver don't control OTG FET feature. > >>> > > - Bigger Fast charge current, Top Off current Threshold selection. > > - Various and bigger OTG current limitation. > > - Bigger primary charger termination voltage setting. > > - Different maximum input current limit selection(Different step). > > Yes, I mentioned some of these differences (the Fast/top-off > differences). These are differences in values so it does not require new > driver. There is need to develop new driver just to support different > current (3.0 A instead of 2.1 A) or voltage threshold. > > >>> > >>> They are different charging current, OTG current limitation, top off > >>> current, > >>> charging limitation value. In case OTG current limitation different not > >>> limitation value but using register bit(max77843 use[7:6] max77693 use[7] > >>> bit only). Even if this driver not support all feature, some register > >>> different with max77693(support value, use register bit). > >>> > >>> If this driver will combined with max77693 may even be beneficial for > >>> new Maxim driver. But the present, this driver is related with > >>> max77843 core driver and max77843-regulator. So I hope this driver > >>> merge first. And then will extend two driver(max77843 charger and > >>> max77693 charger). > > > > I still prefer merging common drivers into one instead of creating > > some more of them. > > However I understand your point and I am not entirely opposed against. > > Especially that you invested quite a bit of time for developing this > > and my feedback was quite late. To summarize I am fine with your > > approach. > > > > Best regards, > > Krzysztof > > > > Dear Lee Jones, > > Could you please merge that your git tree ? Sorry, I'm lost. Why am I taking this though the MFD tree? What patches are left? Where are they going? Am I taking any other patches? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] clk: st: New always-on clock domain
On Wed, 25 Mar 2015, Geert Uytterhoeven wrote:
> Hi Lee,
>
> On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones wrote:
> > On Fri, 06 Mar 2015, Mike Turquette wrote:
> >> Quoting Lee Jones (2015-03-04 04:00:03)
> >> > Mike,
> >> >
> >> > Do you want me to resend this set with Robert's Reviewed-by applied,
> >> > or are you happy to apply it yourself?
> >>
> >> No need for the resend. I am hoping for a final review from a DT human.
> >>
> >> This approach looks fine to me. In practice I think it is restricted to
> >> hardware blocks that don't exist in DT yet (e.g. no driver, in the case
> >> of your interconnect) and that restriction is probably for the best.
> >
> > Agreed.
>
> I think this restriction should be documented in the DT binding more clearly,
> as adding a "clk-always-on" node prohibits you from handling the clock
> correctly in
> the future.
Would you mind taking the time to explain what you think those
limitations are?
> Still, for simple devices where you don't have a driver, but have
> "predictable"
> bindings (e.g. a bus like "simple-pm-bus"), I think it's better to add
> a device node
> for that simple device now, incl. a reference to the clock, and have a simple
> driver that binds to the device, or platform code that looks for a
> compatible node,
> and enables the clock. That way you don't have to make any chances to the DTS
> later, when you'll have a real driver.
>
> >> > > v2 => v3:
> >> > > - Ensure DT actually reflects h/w
> >> > > - i.e. Nodes should not contain a mishmash of different IP
> >> > > blocks, but should identify related h/w. In the current
> >> > > example we use interconnects
> >> > > - Change naming from clkdomain to clk-always-on
> >> > > - Place "do not abuse" warning in documentation
> >> > >
> >> > > v1 => v2:
> >> > > - Turned the ST specific driver into a generic one
> >> > >
> >> > > Hardware can have a bunch of clocks which must not be turned off.
> >> > > If drivers a) fail to obtain a reference to any of these or b) give
> >> > > up a previously obtained reference during suspend, the common clk
> >> > > framework will attempt to turn them off and the hardware will
> >> > > subsequently die. The only way to recover from this failure is to
> >> > > restart.
> >> > >
> >> > > To avoid either of these two scenarios from catastrophically
> >> > > disabling the running system we have implemented a clock domain
> >> > > where clocks are consumed and references are taken, thus preventing
> >> > > them from being shut down by the framework.
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/5] power: max77843_charger: Add Max77843 charger device driver
On 03/24/2015 05:38 PM, Krzysztof Kozlowski wrote: > 2015-03-24 9:01 GMT+01:00 Beomho Seo : >> On 03/10/2015 10:44 PM, Beomho Seo wrote: >>> On 03/09/2015 09:13 PM, Krzysztof Kozlowski wrote: On pon, 2015-03-09 at 20:46 +0900, Beomho Seo wrote: > On 03/09/2015 08:02 PM, Krzysztof Kozlowski wrote: >> 2015-03-09 1:35 GMT+01:00 Beomho Seo : >>> On 03/08/2015 05:13 AM, Sebastian Reichel wrote: On Mon, Mar 02, 2015 at 07:10:35PM +0900, Jaewon Kim wrote: > From: Beomho Seo > > This patch adds device driver of max77843 charger. This driver provide > initialize each charging mode(e.g. fast charge, top-off mode and > constant > charging mode so on.). Additionally, control charging paramters to use > i2c interface. > > Cc: Sebastian Reichel > Signed-off-by: Beomho Seo Reviewed-By: Sebastian Reichel I can't take it as is, since it depends on the private header file of PATCHv1. -- Sebastian >>> >>> This patch reviewed by Sebastian. >>> Could you Please merge that your git tree ? >> >> Hi, >> >> ... and again we are adding a new driver for very similar chipset to >> already supported. I looked at spec and the charger's registers are >> almost the same as for max77693. Their layout and addresses are the >> same. I see some minor differences, probably the most important would >> be different values current (fast-charge, top-off). But still 90% of >> registers are the same... Do we really have to add new driver? >> >> Best regards, >> Krzysztof >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-input" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > Hi, > > Thank you for your comment. As you say, both chip set are similar. > But new driver need for support max77843. It is support different below > - Provide Battery presence information. Another set of power supply properties could be added for that chip. This way the get_property() function would be the same but actually the POWER_SUPPLY_PROP_PRESENT won't be called for max77693. > - Can OTG FET control. Where the OTG FET feature is it enabled in your driver? I couldn't find it. >>> >>> Sorry. This driver don't control OTG FET feature. >>> > - Bigger Fast charge current, Top Off current Threshold selection. > - Various and bigger OTG current limitation. > - Bigger primary charger termination voltage setting. > - Different maximum input current limit selection(Different step). Yes, I mentioned some of these differences (the Fast/top-off differences). These are differences in values so it does not require new driver. There is need to develop new driver just to support different current (3.0 A instead of 2.1 A) or voltage threshold. >>> >>> They are different charging current, OTG current limitation, top off >>> current, >>> charging limitation value. In case OTG current limitation different not >>> limitation value but using register bit(max77843 use[7:6] max77693 use[7] >>> bit only). Even if this driver not support all feature, some register >>> different with max77693(support value, use register bit). >>> >>> If this driver will combined with max77693 may even be beneficial for >>> new Maxim driver. But the present, this driver is related with >>> max77843 core driver and max77843-regulator. So I hope this driver >>> merge first. And then will extend two driver(max77843 charger and max77693 >>> charger). > > I still prefer merging common drivers into one instead of creating > some more of them. > However I understand your point and I am not entirely opposed against. > Especially that you invested quite a bit of time for developing this > and my feedback was quite late. To summarize I am fine with your > approach. > > Best regards, > Krzysztof > Dear Lee Jones, Could you please merge that your git tree ? Best regards, Beomho Seo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/7] dmaengine: omap-dma: Use defines for dma channels and request count
On 03/26/2015 12:57 PM, Vinod Koul wrote: > On Wed, Mar 11, 2015 at 03:23:27PM +0200, Peter Ujfalusi wrote: >> Instead of magic numbers in the code, use define for number of logical DMA >> channels and DMA requests. >> >> Signed-off-by: Peter Ujfalusi >> --- >> drivers/dma/omap-dma.c | 7 +-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c >> index 7dd6dd121681..56c33e93dd24 100644 >> --- a/drivers/dma/omap-dma.c >> +++ b/drivers/dma/omap-dma.c >> @@ -22,6 +22,9 @@ >> >> #include "virt-dma.h" >> >> +#define OMAP_SDMA_REQUESTS 127 >> +#define OMAP_SDMA_CHANNELS 32 > Again why dont we put these things in DT ? They are in DT, the next patch will take the needed information from there and uses these values as fallback values in case they are missing for some reason. -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] dmaengine: Add driver for TI DMA crossbar on DRA7x
On 03/26/2015 12:56 PM, Vinod Koul wrote:
>> +#define TI_XBAR_OUTPUTS 127
>> +#define TI_XBAR_INPUTS 256
> Ideally this should be moved to DT. Will next revision of this chip always
> support these output and inputs?
They are coming from DT. I'm using these as fall back values in case we can
not get this from DT and a warning will be printed in case if this unlikely
event happens.
>> +
>> +static DEFINE_IDR(map_idr);
>> +
>> +struct ti_dma_xbar_data {
>> +struct dma_router dmarouter;
>> +struct regmap *regmap;
>> +
>> +uint safe_val; /* Value to rest the crossbar lines */
>> +uint xbar_requests; /* number of DMA requests connected to XBAR */
>> +uint dma_requests; /* number of DMA requests forwarded to DMA */
>> +
>> +void __iomem *iomem;
>> +};
>> +
>> +struct ti_dma_xbar_map {
>> +int xbar_in;
>> +int xbar_out;
>> +};
>> +
>> +static void ti_dma_xbar_free(struct device *dev, void *route_data)
>> +{
>> +struct ti_dma_xbar_data *xbar = dev_get_drvdata(dev);
>> +struct ti_dma_xbar_map *map = route_data;
>> +
>> +dev_dbg(dev, "Unmapping XBAR%d (was routed to %d)\n",
>> +map->xbar_in, map->xbar_out);
>> +
>> +regmap_write(xbar->regmap, map->xbar_out * 2, 0);
> just out of curiosity how much do you save using regmap :)
good point, not much I guess. I had it implemented w/o regmap as well, but
thought why not use regmap if it is available.
>> +static int ti_dma_xbar_probe(struct platform_device *pdev)
>> +{
>> +struct device_node *node = pdev->dev.of_node;
>> +struct device_node *dma_node;
>> +struct ti_dma_xbar_data *xbar;
>> +struct resource *res;
>> +void __iomem *iomem;
>> +int i, ret;
>> +
>> +if (!node)
>> +return -ENODEV;
>> +
>> +dma_node = of_parse_phandle(node, "dma-device", 0);
>> +if (!dma_node) {
>> +dev_err(&pdev->dev, "Can't get target DMA node\n");
>> +return -ENODEV;
>> +}
>> +
>> +xbar = devm_kzalloc(&pdev->dev, sizeof(*xbar), GFP_KERNEL);
>> +if (!xbar)
>> +return -ENOMEM;
>> +
>> +if (of_property_read_u32(dma_node, "dma-requests",
>> + &xbar->dma_requests)) {
>> +dev_info(&pdev->dev,
>> + "Missing XBAR output information, using %u.\n",
>> + TI_XBAR_OUTPUTS);
>> +xbar->dma_requests = TI_XBAR_OUTPUTS;
>> +}
>> +of_node_put(dma_node);
> _put here?
The code takes the real dma controller's node and it should be put back after
I have got the information I needed from it (number of DMA requests).
>
>> +int omap_dmaxbar_init(void)
>> +{
>> +return platform_driver_register(&ti_dma_xbar_driver);
>> +}
>> +arch_initcall(omap_dmaxbar_init);
> why arch_initcall?
It should be on the same init level as the real DMA controller. omap-dma at
the moment, but in some platforms this can work with the edma as well.
Since all device in the system (well most of them anyway) uses DMA it is
better to not delay their probe with deferring because the crossbar driver is
still not loaded
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] dmaengine: of_dma: Support for DMA routers
On 03/26/2015 12:50 PM, Vinod Koul wrote: > On Wed, Mar 11, 2015 at 03:23:24PM +0200, Peter Ujfalusi wrote: >> DMA routers are transparent devices used to mux DMA requests from >> peripherals to DMA controllers. They are used when the SoC integrates more >> devices with DMA requests then their controller can handle. >> DRA7x is one example of such SoC, where the sDMA can hanlde 128 DMA request >> lines, but in SoC level it has 205 DMA requests. >> >> The of_dma_router will be registered as of_dma_controller with special >> xlate function and additional parameters and the code will translate and >> requests a DMA channel from the real DMA controller. >> This way the router can be transparent for the system while remaining generic >> enough to be used in different environments. >> > Looks fine, was expecting a Documentation updates as well, but that can come > as follow up patch too I have added the DT binding document since this series adds support for routers for platforms booting with DT: Documentation/devicetree/bindings/dma/dma.txt | 28 -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/7] mailbox: arm_mhu: add driver for ARM MHU controller
On 26/03/15 11:49, Russell King - ARM Linux wrote: On Thu, Mar 26, 2015 at 11:43:21AM +, Sudeep Holla wrote: I tried using this driver and found that AMBA driver expects apb_clk without which probe fails. Though your example have it, it's not explicit from the binding. Also AMBA binding expects the primecell id in the binding. That's optional: Optional properties: - arm,primecell-periphid : Value to override the h/w value with It's only required when the hardware doesn't provide the correct value. Ah sorry my bad, I meant the compatible(somehow left this word at the end of earlier email - it should have been" .. AMBA binding expects the primecell id in the binding compatible") - compatible : should be a specific name for the peripheral and "arm,primecell". The specific name will match the ARM engineering name for the logic block in the form: "arm,pl???" So I wanted to make sure either we follow that here(unlikely as ARM is not publishing this as standard primecell yet) or specify that it's exception here. Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/7] mailbox: arm_mhu: add driver for ARM MHU controller
On Thu, Mar 26, 2015 at 11:43:21AM +, Sudeep Holla wrote: > I tried using this driver and found that AMBA driver expects apb_clk > without which probe fails. Though your example have it, it's not > explicit from the binding. Also AMBA binding expects the primecell id in > the binding. That's optional: Optional properties: - arm,primecell-periphid : Value to override the h/w value with It's only required when the hardware doesn't provide the correct value. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/7] mailbox: arm_mhu: add driver for ARM MHU controller
On 04/03/15 11:01, Vincent Yang wrote: From: Jassi Brar Add driver for the ARM Primecell Message-Handling-Unit(MHU) controller. Signed-off-by: Jassi Brar Signed-off-by: Andy Green Signed-off-by: Vincent Yang Signed-off-by: Tetsuya Nuriya --- .../devicetree/bindings/mailbox/arm-mhu.txt| 43 + drivers/mailbox/Kconfig| 9 + drivers/mailbox/Makefile | 2 + drivers/mailbox/arm_mhu.c | 195 + 4 files changed, 249 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/arm-mhu.txt create mode 100644 drivers/mailbox/arm_mhu.c diff --git a/Documentation/devicetree/bindings/mailbox/arm-mhu.txt b/Documentation/devicetree/bindings/mailbox/arm-mhu.txt new file mode 100644 index 000..4971f03 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/arm-mhu.txt @@ -0,0 +1,43 @@ +ARM MHU Mailbox Driver +== + +The ARM's Message-Handling-Unit (MHU) is a mailbox controller that has +3 independent channels/links to communicate with remote processor(s). + MHU links are hardwired on a platform. A link raises interrupt for any +received data. However, there is no specified way of knowing if the sent +data has been read by the remote. This driver assumes the sender polls +STAT register and the remote clears it after having read the data. +The last channel is specified to be a 'Secure' resource, hence can't be +used by Linux running NS. + +Mailbox Device Node: + + +Required properties: + +- compatible: Shall be "arm,mhu" & "arm,primecell" +- reg: Contains the mailbox register address range (base + address and length) +- #mbox-cells Shall be 1 - the index of the channel needed. +- interrupts: Contains the interrupt information corresponding to + each of the 3 links of MHU. + I tried using this driver and found that AMBA driver expects apb_clk without which probe fails. Though your example have it, it's not explicit from the binding. Also AMBA binding expects the primecell id in the binding. Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 7/8] drm/exynos: dsi: add support for MIC driver as a bridge
MIC must be initilized by MIPI DSI when it is being bound.
Signed-off-by: Hyungwon Hwang
---
Changes for v2:
- None
Changes for v3:
- None
.../devicetree/bindings/video/exynos_dsim.txt | 23 ++---
drivers/gpu/drm/exynos/exynos_drm_dsi.c| 24 ++
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
index 8b12bfe..9112b10 100644
--- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -31,10 +31,19 @@ Video interfaces:
Device node can contain video interface port nodes according to [2].
The following are properties specific to those nodes:
- port node:
-- reg: (required) can be 0 for input RGB/I80 port or 1 for DSI port;
+ port node inbound:
+- reg: (required) must be 0.
+ port node outbound:
+- reg: (required) must be 1.
- endpoint node of DSI port (reg = 1):
+ endpoint node connected from mic node (reg = 0):
+- remote-endpoint: specifies the endpoint in mic node. This node is
required
+ for Exynos5433 mipi dsi. So mic can access to panel node
+ thoughout this dsi node.
+ endpoint node connected to panel node (reg = 1):
+- remote-endpoint: specifies the endpoint in panel node. This node is
+ required in all kinds of exynos mipi dsi to represent
+ the connection between mipi dsi and panel.
- samsung,burst-clock-frequency: specifies DSI frequency in high-speed
burst
mode
- samsung,esc-clock-frequency: specifies DSI frequency in escape mode
@@ -73,7 +82,15 @@ Example:
#address-cells = <1>;
#size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ decon_to_mic: endpoint {
+ remote-endpoint = <&mic_to_decon>;
+ };
+ };
+
port@1 {
+ reg = <1>;
dsi_ep: endpoint {
reg = <0>;
samsung,burst-clock-frequency =
<5>;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index d1ecd0f..d382511 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -282,6 +283,7 @@ struct exynos_dsi {
struct list_head transfer_list;
struct exynos_dsi_driver_data *driver_data;
+ struct device_node *bridge_node;
};
#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1778,7 +1780,22 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
ret = exynos_dsi_of_read_u32(ep, "samsung,esc-clock-frequency",
&dsi->esc_clk_rate);
+ if (ret < 0)
+ goto end;
+
+ of_node_put(ep);
+
+ ep = of_graph_get_next_endpoint(node, NULL);
+ if (!ep) {
+ ret = -ENXIO;
+ goto end;
+ }
+ dsi->bridge_node = of_graph_get_remote_port_parent(ep);
+ if (!dsi->bridge_node) {
+ ret = -ENXIO;
+ goto end;
+ }
end:
of_node_put(ep);
@@ -1791,6 +1808,7 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
struct exynos_drm_display *display = dev_get_drvdata(dev);
struct exynos_dsi *dsi = display_to_dsi(display);
struct drm_device *drm_dev = data;
+ struct drm_bridge *bridge;
int ret;
ret = exynos_drm_create_enc_conn(drm_dev, display);
@@ -1800,6 +1818,12 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
return ret;
}
+ bridge = of_drm_find_bridge(dsi->bridge_node);
+ if (bridge) {
+ display->encoder->bridge = bridge;
+ drm_bridge_attach(drm_dev, bridge);
+ }
+
return mipi_dsi_host_register(&dsi->dsi_host);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/8] drm/exynos: dsi: add support for Exynos5433
This patch adds support for Exynos5433 mipi dsi.
Signed-off-by: Hyungwon Hwang
---
Changes for v2:
- change the author of "drm/exynos: dsi: add support for Exynos5433 SoC" to
Hyungwon Hwang by the previous author's will
Changes for v3:
- Separated from the patch "drm/exynos: dsi: add support for Exynos5433 SoC"
in version 2.
- use defines for more readable code
- fix typos
.../devicetree/bindings/video/exynos_dsim.txt | 1 +
drivers/gpu/drm/exynos/Kconfig | 2 +-
drivers/gpu/drm/exynos/exynos_drm_dsi.c| 69 +-
3 files changed, 68 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
index 39940ca..8b12bfe 100644
--- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -6,6 +6,7 @@ Required properties:
"samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
"samsung,exynos4415-mipi-dsi" /* for Exynos4415 SoC */
"samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs
*/
+ "samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
- reg: physical base address and length of the registers set for the device
- interrupts: should contain DSI interrupt
- clocks: list of clock specifiers, must contain an entry for each required
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index f78f3ef..e873502 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -47,7 +47,7 @@ config DRM_EXYNOS_DPI
config DRM_EXYNOS_DSI
bool "EXYNOS DRM MIPI-DSI driver support"
- depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS7_DECON)
+ depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS5433_DECON ||
DRM_EXYNOS7_DECON)
select DRM_MIPI_DSI
select DRM_PANEL
default n
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 2d9a249..d1ecd0f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -131,6 +131,7 @@
#define DSIM_INT_PLL_STABLE(1 << 31)
#define DSIM_INT_SW_RST_RELEASE(1 << 30)
#define DSIM_INT_SFR_FIFO_EMPTY(1 << 29)
+#define DSIM_INT_SFR_HDR_FIFO_EMPTY(1 << 28)
#define DSIM_INT_BTA (1 << 25)
#define DSIM_INT_FRAME_DONE(1 << 24)
#define DSIM_INT_RX_TIMEOUT(1 << 21)
@@ -179,6 +180,8 @@
/* DSIM_PHYCTRL */
#define DSIM_PHYCTRL_ULPS_EXIT(x) (((x) & 0x1ff) << 0)
+#define DSIM_PHYCTRL_B_DPHYCTL_VREG_LP (1 << 30)
+#define DSIM_PHYCTRL_B_DPHYCTL_SLEW_UP (1 << 14)
/* DSIM_PHYTIMING */
#define DSIM_PHYTIMING_LPX(x) ((x) << 8)
@@ -206,7 +209,9 @@
#define DSI_WRITE(dsi, reg, val) writel((val), REG((dsi), (reg)))
#define DSI_READ(dsi, reg) readl(REG((dsi), (reg)))
-static char *clk_names[2] = { "bus_clk", "sclk_mipi" };
+static char *clk_names[5] = { "bus_clk", "sclk_mipi",
+ "phyclk_mipidphy0_bitclkdiv8", "phyclk_mipidphy0_rxclkesc0",
+ "sclk_rgb_vclk_to_dsim0" };
enum exynos_dsi_transfer_type {
EXYNOS_DSI_TX,
@@ -335,6 +340,30 @@ static unsigned int regs[] = {
[DSIM_PHYTIMING2_REG] = 0x6c,
};
+static unsigned int exynos5433_regs[] = {
+ [DSIM_STATUS_REG] = 0x04,
+ [DSIM_SWRST_REG] = 0x0C,
+ [DSIM_CLKCTRL_REG] = 0x10,
+ [DSIM_TIMEOUT_REG] = 0x14,
+ [DSIM_CONFIG_REG] = 0x18,
+ [DSIM_ESCMODE_REG] = 0x1C,
+ [DSIM_MDRESOL_REG] = 0x20,
+ [DSIM_MVPORCH_REG] = 0x24,
+ [DSIM_MHPORCH_REG] = 0x28,
+ [DSIM_MSYNC_REG] = 0x2C,
+ [DSIM_INTSRC_REG] = 0x34,
+ [DSIM_INTMSK_REG] = 0x38,
+ [DSIM_PKTHDR_REG] = 0x3C,
+ [DSIM_PAYLOAD_REG] = 0x40,
+ [DSIM_RXFIFO_REG] = 0x44,
+ [DSIM_FIFOCTRL_REG] = 0x4C,
+ [DSIM_PLLCTRL_REG] = 0x94,
+ [DSIM_PHYCTRL_REG] = 0xA4,
+ [DSIM_PHYTIMING_REG] = 0xB4,
+ [DSIM_PHYTIMING1_REG] = 0xB8,
+ [DSIM_PHYTIMING2_REG] = 0xBC,
+};
+
enum values {
RESET_TYPE,
PLL_TIMER,
@@ -371,6 +400,24 @@ static unsigned int values[] = {
[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0b),
};
+static unsigned int exynos5433_values[] = {
+ [RESET_TYPE] = DSIM_FUNCRST,
+ [PLL_TIMER] = 22200,
+ [STOP_STATE_CNT] = 0xa,
+ [PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0x190),
+ [PHYCTRL_VREG_LP] = DSIM_PHYCTRL_B_DPHYCTL_VREG_LP,
+ [PHYCTRL_SLEW_UP] = DSIM_PHYCTRL_B_DPHYCTL_SLEW_UP,
+ [PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x07),
+ [PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0c),
+ [PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x09),
+ [PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x2d),
+ [PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0e),
+ [PHYTIMING_CLK_TRAIL] = D
[PATCH v3 8/8] drm/exynos: dsi: do not set TE GPIO direction by input
On some board, TE GPIO should be configured properly thoughout pinctrl driver
as an wakeup interrupt. So this gpio should be configurable in the board's DT,
not being requested as a input pin.
Signed-off-by: Hyungwon Hwang
---
Changes for v2:
- None
Changes for v3:
- None
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index d382511..230082a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1316,15 +1316,15 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi
*dsi)
goto out;
}
- ret = gpio_request_one(dsi->te_gpio, GPIOF_IN, "te_gpio");
+ ret = gpio_request(dsi->te_gpio, "te_gpio");
if (ret) {
dev_err(dsi->dev, "gpio request failed with %d\n", ret);
goto out;
}
te_gpio_irq = gpio_to_irq(dsi->te_gpio);
-
irq_set_status_flags(te_gpio_irq, IRQ_NOAUTOEN);
+
ret = request_threaded_irq(te_gpio_irq, exynos_dsi_te_irq_handler, NULL,
IRQF_TRIGGER_RISING, "TE", dsi);
if (ret) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/8] drm/exynos: dsi: rename pll_clk to sclk_clk
This patch renames pll_clk to sclk_clk. The clock referenced by pll_clk
is actually not the pll input clock for dsi. The pll input clock comes
from the board's oscillator directly.
Signed-off-by: Hyungwon Hwang
---
Changes for v3:
- Newly added
.../devicetree/bindings/video/exynos_dsim.txt | 6 ++---
drivers/gpu/drm/exynos/exynos_drm_dsi.c| 31 --
2 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
index 802aa7e..39940ca 100644
--- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -10,13 +10,13 @@ Required properties:
- interrupts: should contain DSI interrupt
- clocks: list of clock specifiers, must contain an entry for each required
entry in clock-names
- - clock-names: should include "bus_clk"and "pll_clk" entries
+ - clock-names: should include "bus_clk"and "sclk_mipi" entries
- phys: list of phy specifiers, must contain an entry for each required
entry in phy-names
- phy-names: should include "dsim" entry
- vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V)
- vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V)
- - samsung,pll-clock-frequency: specifies frequency of the "pll_clk" clock
+ - samsung,pll-clock-frequency: specifies frequency of the oscillator clock
- #address-cells, #size-cells: should be set respectively to <1> and <0>
according to DSI host bindings (see MIPI DSI bindings [1])
@@ -48,7 +48,7 @@ Example:
reg = <0x11C8 0x1>;
interrupts = <0 79 0>;
clocks = <&clock 286>, <&clock 143>;
- clock-names = "bus_clk", "pll_clk";
+ clock-names = "bus_clk", "sclk_mipi";
phys = <&mipi_phy 1>;
phy-names = "dsim";
vddcore-supply = <&vusb_reg>;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 05fe93d..4af18b2f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -277,7 +277,7 @@ struct exynos_dsi {
void __iomem *reg_base;
struct phy *phy;
- struct clk *pll_clk;
+ struct clk *sclk_clk;
struct clk *bus_clk;
struct regulator_bulk_data supplies[2];
int irq;
@@ -431,16 +431,7 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi
*dsi,
u16 m;
u32 reg;
- clk_set_rate(dsi->pll_clk, dsi->pll_clk_rate);
-
- fin = clk_get_rate(dsi->pll_clk);
- if (!fin) {
- dev_err(dsi->dev, "failed to get PLL clock frequency\n");
- return 0;
- }
-
- dev_dbg(dsi->dev, "PLL input frequency: %lu\n", fin);
-
+ fin = dsi->pll_clk_rate;
fout = exynos_dsi_pll_find_pms(dsi, fin, freq, &p, &m, &s);
if (!fout) {
dev_err(dsi->dev,
@@ -1308,10 +1299,10 @@ static int exynos_dsi_poweron(struct exynos_dsi *dsi)
goto err_bus_clk;
}
- ret = clk_prepare_enable(dsi->pll_clk);
+ ret = clk_prepare_enable(dsi->sclk_clk);
if (ret < 0) {
dev_err(dsi->dev, "cannot enable pll clock %d\n", ret);
- goto err_pll_clk;
+ goto err_sclk_clk;
}
ret = phy_power_on(dsi->phy);
@@ -1323,8 +1314,8 @@ static int exynos_dsi_poweron(struct exynos_dsi *dsi)
return 0;
err_phy:
- clk_disable_unprepare(dsi->pll_clk);
-err_pll_clk:
+ clk_disable_unprepare(dsi->sclk_clk);
+err_sclk_clk:
clk_disable_unprepare(dsi->bus_clk);
err_bus_clk:
regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
@@ -1350,7 +1341,7 @@ static void exynos_dsi_poweroff(struct exynos_dsi *dsi)
phy_power_off(dsi->phy);
- clk_disable_unprepare(dsi->pll_clk);
+ clk_disable_unprepare(dsi->sclk_clk);
clk_disable_unprepare(dsi->bus_clk);
ret = regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
@@ -1720,10 +1711,10 @@ static int exynos_dsi_probe(struct platform_device
*pdev)
return -EPROBE_DEFER;
}
- dsi->pll_clk = devm_clk_get(dev, "pll_clk");
- if (IS_ERR(dsi->pll_clk)) {
- dev_info(dev, "failed to get dsi pll input clock\n");
- ret = PTR_ERR(dsi->pll_clk);
+ dsi->sclk_clk = devm_clk_get(dev, "sclk_mipi");
+ if (IS_ERR(dsi->sclk_clk)) {
+ dev_info(dev, "failed to get dsi sclk clock\n");
+ ret = PTR_ERR(dsi->sclk_clk);
goto err_del_component;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/8] Add drivers for Exynos5433 display
This patchset is based on the git(branch name: exynos-drm-next) which is maintained by Inki Dae. https://kernel.googlesource.com/pub/scm/linux/kernel/git/... This patchset adds 2 new device drivers, decon and mic, and adds support for Exynos5433 mipi dsi. To enable display in a Exynos5433 board, decon(display controller), MIC(Mobile image compressor), mipi dsi, and panel have to be turned on. This patchset contains support for 3 drivers for SoC level devices. Changes for v2: - change config, file, and variable names of decon to represnt exynos5433 instead of exynos to distinguish them from exynos7 decon - change the initialization order of decon to make it initialized in order like FIMD or exynos7 decon - make mic driver to be registered by exynos drm driver instead as a module driver - change the description of mic driver in documentation - add module author at the top of the source file removing MODULE_OWNER, MODULE_DESCRIPTION, MODULE_LICENSE - change the author of "drm/exynos: dsi: add support for Exynos5433 SoC" to Hyungwon Hwang by the previous author's will Changes for v3: < Decon > - fail fast when the proper image format is not set - remove unnecessary checking code - add and modify the function to make DPMS work well < MIC > - move if statement out of function, so that the function is not called unnecessarily - Make it use syscon framework for controlling system register < DSI > - separate the previous one patch to three - renaming patch: rename pll clock to sclk clock - generalizing patch: generalize the way to getting address and values - Exynos5433 patch: adds support for Exynos5433 dsi - use defines for more readable code - fix typos Hyungwon Hwang (7): of: add helper for getting endpoint node of specific identifiers drm/exynos: mic: add MIC driver drm/exynos: dsi: rename pll_clk to sclk_clk drm/exynos: dsi: generalize register setting and clock control drm/exynos: dsi: add support for Exynos5433 drm/exynos: dsi: add support for MIC driver as a bridge drm/exynos: dsi: do not set TE GPIO direction by input Joonyoung Shim (1): drm/exynos: add Exynos5433 decon driver .../devicetree/bindings/video/exynos-mic.txt | 51 ++ .../devicetree/bindings/video/exynos5433-decon.txt | 65 ++ .../devicetree/bindings/video/exynos_dsim.txt | 30 +- drivers/gpu/drm/exynos/Kconfig | 14 +- drivers/gpu/drm/exynos/Makefile| 2 + drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 665 + drivers/gpu/drm/exynos/exynos_drm_drv.c| 6 + drivers/gpu/drm/exynos/exynos_drm_drv.h| 2 + drivers/gpu/drm/exynos/exynos_drm_dsi.c| 453 +- drivers/gpu/drm/exynos/exynos_drm_mic.c| 490 +++ drivers/of/base.c | 33 + include/linux/of_graph.h | 8 + include/video/exynos5433_decon.h | 163 + 13 files changed, 1832 insertions(+), 150 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/exynos-mic.txt create mode 100644 Documentation/devicetree/bindings/video/exynos5433-decon.txt create mode 100644 drivers/gpu/drm/exynos/exynos5433_drm_decon.c create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mic.c create mode 100644 include/video/exynos5433_decon.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/8] drm/exynos: mic: add MIC driver
MIC(Mobile image compressor) is newly added IP in Exynos5433. MIC
resides between decon and mipi dsim, and compresses frame data by 50%.
With dsi, not display port, to send frame data to the panel, the
bandwidth is not enough. That is why this compressor is introduced.
Signed-off-by: Hyungwon Hwang
---
Changes for v2:
- make mic driver to be registered by exynos drm driver instead as a module
driver
- change the description of mic driver in documentation
- add module author at the top of the source file removing MODULE_OWNER,
MODULE_DESCRIPTION, MODULE_LICENSE
Changes for v3:
- move if statement out of function, so that the function is not called
unnecessarily
- Make it use syscon framework for controlling system register
.../devicetree/bindings/video/exynos-mic.txt | 51 +++
drivers/gpu/drm/exynos/Kconfig | 6 +
drivers/gpu/drm/exynos/Makefile| 1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c| 3 +
drivers/gpu/drm/exynos/exynos_drm_drv.h| 1 +
drivers/gpu/drm/exynos/exynos_drm_mic.c| 490 +
6 files changed, 552 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/exynos-mic.txt
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mic.c
diff --git a/Documentation/devicetree/bindings/video/exynos-mic.txt
b/Documentation/devicetree/bindings/video/exynos-mic.txt
new file mode 100644
index 000..0fba2ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos-mic.txt
@@ -0,0 +1,51 @@
+Device-Tree bindings for Samsung Exynos SoC mobile image compressor (MIC)
+
+MIC (mobile image compressor) resides between decon and mipi dsi. Mipi dsi is
+not capable to transfer high resoltuion frame data as decon can send. MIC
+solves this problem by compressing the frame data by 1/2 before it is
+transferred through mipi dsi. The compressed frame data must be uncompressed in
+the panel PCB.
+
+Required properties:
+- compatible: value should be "samsung,exynos5433-mic".
+- reg: physical base address and length of the MIC registers set and system
+ register of mic.
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain "pclk_mic0", "sclk_rgb_vclk_to_mic0".
+- samsung,disp-syscon: the reference node for syscon for DISP block.
+- ports: contains a port which is connected to decon node and dsi node.
+address-cells and size-cells must 1 and 0, respectively.
+- port: contains an endpoint node which is connected to the endpoint in the
+ decon node or dsi node. The reg value must be 0 and 1 respectively.
+
+Example:
+SoC specific DT entry:
+mic: mic@1393 {
+ compatible = "samsung,exynos5433-mic";
+ reg = <0x1393 0x48>;
+ clocks = <&cmu_disp CLK_PCLK_MIC0>,
+ <&cmu_disp CLK_SCLK_RGB_VCLK_TO_MIC0>;
+ clock-names = "pclk_mic0", "sclk_rgb_vclk_to_mic0";
+ samsung,disp-syscon = <&syscon_disp>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mic_to_decon: endpoint {
+ remote-endpoint = <&decon_to_mic>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mic_to_dsi: endpoint {
+ remote-endpoint = <&dsi_to_mic>;
+ };
+ };
+ };
+};
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index d9dc408..f78f3ef 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -103,3 +103,9 @@ config DRM_EXYNOS_GSC
depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && !ARCH_MULTIPLATFORM
help
Choose this option if you want to use Exynos GSC for DRM.
+
+config DRM_EXYNOS_MIC
+ bool "Exynos DRM MIC"
+ depends on (DRM_EXYNOS && DRM_EXYNOS5433_DECON)
+ help
+ Choose this option if you want to use Exynos MIC for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index fbd084d..7de0b10 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -22,5 +22,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_IPP)+= exynos_drm_ipp.o
exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_MIC) += exynos_drm_mic.o
obj-$(CONFIG_DRM_EXYNOS) += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 4d6ad28..00cbaa2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.
[PATCH v3 5/8] drm/exynos: dsi: generalize register setting and clock control
This patch makes the driver use arrays for clocks, register address,
and values. By doing this, it becomes easier to add support for another
SoC.
Signed-off-by: Hyungwon Hwang
---
Changes for v3:
- Separated from the patch "drm/exynos: dsi: add support for Exynos5433 SoC"
in version 2.
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 347
1 file changed, 218 insertions(+), 129 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 4af18b2f..2d9a249 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -33,38 +33,6 @@
/* returns true iff both arguments logically differs */
#define NEQV(a, b) (!(a) ^ !(b))
-#define DSIM_STATUS_REG0x0 /* Status register */
-#define DSIM_SWRST_REG 0x4 /* Software reset register */
-#define DSIM_CLKCTRL_REG 0x8 /* Clock control register */
-#define DSIM_TIMEOUT_REG 0xc /* Time out register */
-#define DSIM_CONFIG_REG0x10/* Configuration register */
-#define DSIM_ESCMODE_REG 0x14/* Escape mode register */
-
-/* Main display image resolution register */
-#define DSIM_MDRESOL_REG 0x18
-#define DSIM_MVPORCH_REG 0x1c/* Main display Vporch register */
-#define DSIM_MHPORCH_REG 0x20/* Main display Hporch register */
-#define DSIM_MSYNC_REG 0x24/* Main display sync area register */
-
-/* Sub display image resolution register */
-#define DSIM_SDRESOL_REG 0x28
-#define DSIM_INTSRC_REG0x2c/* Interrupt source register */
-#define DSIM_INTMSK_REG0x30/* Interrupt mask register */
-#define DSIM_PKTHDR_REG0x34/* Packet Header FIFO register
*/
-#define DSIM_PAYLOAD_REG 0x38/* Payload FIFO register */
-#define DSIM_RXFIFO_REG0x3c/* Read FIFO register */
-#define DSIM_FIFOTHLD_REG 0x40/* FIFO threshold level register */
-#define DSIM_FIFOCTRL_REG 0x44/* FIFO status and control register */
-
-/* FIFO memory AC characteristic register */
-#define DSIM_PLLCTRL_REG 0x4c/* PLL control register */
-#define DSIM_PHYACCHR_REG 0x54/* D-PHY AC characteristic register */
-#define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic register1 */
-#define DSIM_PHYCTRL_REG 0x5c
-#define DSIM_PHYTIMING_REG 0x64
-#define DSIM_PHYTIMING1_REG0x68
-#define DSIM_PHYTIMING2_REG0x6c
-
/* DSIM_STATUS */
#define DSIM_STOP_STATE_DAT(x) (((x) & 0xf) << 0)
#define DSIM_STOP_STATE_CLK(1 << 8)
@@ -128,8 +96,8 @@
/* DSIM_MDRESOL */
#define DSIM_MAIN_STAND_BY (1 << 31)
-#define DSIM_MAIN_VRESOL(x)(((x) & 0x7ff) << 16)
-#define DSIM_MAIN_HRESOL(x)(((x) & 0X7ff) << 0)
+#define DSIM_MAIN_VRESOL(x, num_bits) (((x) & ((1 << (num_bits)) - 1)) << 16)
+#define DSIM_MAIN_HRESOL(x, num_bits) (((x) & ((1 << (num_bits)) - 1)) << 0)
/* DSIM_MVPORCH */
#define DSIM_CMD_ALLOW(x) ((x) << 28)
@@ -234,6 +202,12 @@
#define DSI_XFER_TIMEOUT_MS100
#define DSI_RX_FIFO_EMPTY 0x3082
+#define REG(dsi, reg) ((dsi)->reg_base + dsi->driver_data->regs[(reg)])
+#define DSI_WRITE(dsi, reg, val) writel((val), REG((dsi), (reg)))
+#define DSI_READ(dsi, reg) readl(REG((dsi), (reg)))
+
+static char *clk_names[2] = { "bus_clk", "sclk_mipi" };
+
enum exynos_dsi_transfer_type {
EXYNOS_DSI_TX,
EXYNOS_DSI_RX,
@@ -261,10 +235,15 @@ struct exynos_dsi_transfer {
#define DSIM_STATE_CMD_LPM BIT(2)
struct exynos_dsi_driver_data {
+ unsigned int *regs;
unsigned int plltmr_reg;
-
unsigned int has_freqband:1;
unsigned int has_clklane_stop:1;
+ unsigned int num_clks;
+ unsigned int max_freq;
+ unsigned int wait_for_reset;
+ unsigned int num_bits_resol;
+ unsigned int *values;
};
struct exynos_dsi {
@@ -277,8 +256,7 @@ struct exynos_dsi {
void __iomem *reg_base;
struct phy *phy;
- struct clk *sclk_clk;
- struct clk *bus_clk;
+ struct clk **clks;
struct regulator_bulk_data supplies[2];
int irq;
int te_gpio;
@@ -309,25 +287,133 @@ static inline struct exynos_dsi *display_to_dsi(struct
exynos_drm_display *d)
return container_of(d, struct exynos_dsi, display);
}
+enum regs {
+ DSIM_STATUS_REG,/* Status register */
+ DSIM_SWRST_REG, /* Software reset register */
+ DSIM_CLKCTRL_REG, /* Clock control register */
+ DSIM_TIMEOUT_REG, /* Time out register */
+ DSIM_CONFIG_REG,/* Configuration register */
+ DSIM_ESCMODE_REG, /* Escape mode register */
+ DSIM_MDRESOL_REG,
+ DSIM_MVPORCH_REG, /* Main display Vporch register */
+ DSIM_MHPORCH_REG, /* Main display Hporch regis
[PATCH v3 1/8] drm/exynos: add Exynos5433 decon driver
From: Joonyoung Shim
DECON(Display and Enhancement Controller) is new IP replacing FIMD in
Exynos5433. This patch adds Exynos5433 decon driver.
Signed-off-by: Joonyoung Shim
Signed-off-by: Hyungwon Hwang
---
Changes for v2:
- change file names and variable names of decon to represnt exynos5433 instead
of exynos to distinguish them from exynos7 decon
Changes for v3:
- fail fast when the proper image format is not set
- remove unnecessary checking code
- add and modify the function to make DPMS work well
.../devicetree/bindings/video/exynos5433-decon.txt | 65 ++
drivers/gpu/drm/exynos/Kconfig | 6 +
drivers/gpu/drm/exynos/Makefile| 1 +
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 665 +
drivers/gpu/drm/exynos/exynos_drm_drv.c| 3 +
drivers/gpu/drm/exynos/exynos_drm_drv.h| 1 +
include/video/exynos5433_decon.h | 163 +
7 files changed, 904 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/exynos5433-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos5433_drm_decon.c
create mode 100644 include/video/exynos5433_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt
b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
new file mode 100644
index 000..377afbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
@@ -0,0 +1,65 @@
+Device-Tree bindings for Samsung Exynos SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be "samsung,exynos5433-decon";
+- reg: physical base address and length of the DECON registers set.
+- interrupts: should contain a list of all DECON IP block interrupts in the
+ order: VSYNC, LCD_SYSTEM. The interrupt specifier format
+ depends on the interrupt controller used.
+- interrupt-names: should contain the interrupt names: "vsync", "lcd_sys"
+ in the same order as they were listed in the interrupts
+ property.
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain "aclk_decon", "aclk_smmu_decon0x",
+ "aclk_xiu_decon0x", "pclk_smmu_decon0x", clk_decon_vclk",
+ "sclk_decon_eclk"
+- ports: contains a port which is connected to mic node. address-cells and
+size-cells must 1 and 0, respectively.
+- port: contains an endpoint node which is connected to the endpoint in the mic
+ node. The reg value muset be 0.
+- i80-if-timings: specify whether the panel which is connected to decon uses
+ i80 lcd interface or mipi video interface. This node contains
+ no timing information as that of fimd does. Because there is
+ no register in decon to specify i80 interface timing value,
+ it is not needed, but make it remain to use same kind of node
+ in fimd and exynos7 decon.
+
+Example:
+SoC specific DT entry:
+decon: decon@1380 {
+ compatible = "samsung,exynos5433-decon";
+ reg = <0x1380 0x2104>;
+ clocks = <&cmu_disp CLK_ACLK_DECON>, <&cmu_disp CLK_ACLK_SMMU_DECON0X>,
+ <&cmu_disp CLK_ACLK_XIU_DECON0X>,
+ <&cmu_disp CLK_PCLK_SMMU_DECON0X>,
+ <&cmu_disp CLK_SCLK_DECON_VCLK>,
+ <&cmu_disp CLK_SCLK_DECON_ECLK>;
+ clock-names = "aclk_decon", "aclk_smmu_decon0x", "aclk_xiu_decon0x",
+ "pclk_smmu_decon0x", "sclk_decon_vclk", "sclk_decon_eclk";
+ interrupt-names = "vsync", "lcd_sys";
+ interrupts = <0 202 0>, <0 203 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ decon_to_mic: endpoint {
+ remote-endpoint = <&mic_to_decon>;
+ };
+ };
+ };
+};
+
+Board specific DT entry:
+&decon {
+ i80-if-timings {
+ };
+};
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index c8001c2..d9dc408 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -24,6 +24,12 @@ config DRM_EXYNOS_FIMD
help
Choose this option if you want to use Exynos FIMD for DRM.
+config DRM_EXYNOS5433_DECON
+ bool "Exynos5433 DRM DECON"
+ depends on DRM_EXYNOS
+ help
+ Choose this option if you want to use Exynos5433 DECON for DRM.
+
config DRM_EXYNOS7_DECON
bool "Exynos DRM DECON"
depends on DRM_EXYNOS
diff --git a/drivers/gp
[PATCH v3 2/8] of: add helper for getting endpoint node of specific identifiers
When there are multiple ports or multiple endpoints in a port, they have to be
distinguished by the value of reg property. It is common. The drivers can get
the specific endpoint in the specific port via this function. Now the drivers
have to implement this code in themselves or have to force the order of dt nodes
to get the right node.
Signed-off-by: Hyungwon Hwang
Acked-by: Rob Herring
---
Changes for v2:
- None
Changes for v3:
- None
drivers/of/base.c| 33 +
include/linux/of_graph.h | 8
2 files changed, 41 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index adb8764..ffc2235 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2165,6 +2165,39 @@ struct device_node *of_graph_get_next_endpoint(const
struct device_node *parent,
EXPORT_SYMBOL(of_graph_get_next_endpoint);
/**
+ * of_graph_get_endpoint_by_regs() - get endpoint node of specific identifiers
+ * @parent: pointer to the parent device node
+ * @port_reg: identifier (value of reg property) of the parent port node
+ * @reg: identifier (value of reg property) of the endpoint node
+ *
+ * Return: An 'endpoint' node pointer which is identified by reg and at the
same
+ * is the child of a port node identified by port_reg. reg and port_reg are
+ * ignored when they are -1.
+ */
+struct device_node *of_graph_get_endpoint_by_regs(
+ const struct device_node *parent, int port_reg, int reg)
+{
+ struct of_endpoint endpoint;
+ struct device_node *node, *prev_node = NULL;
+
+ while (1) {
+ node = of_graph_get_next_endpoint(parent, prev_node);
+ of_node_put(prev_node);
+ if (!node)
+ break;
+
+ of_graph_parse_endpoint(node, &endpoint);
+ if (((port_reg == -1) || (endpoint.port == port_reg)) &&
+ ((reg == -1) || (endpoint.id == reg)))
+ return node;
+
+ prev_node = node;
+ }
+
+ return NULL;
+}
+
+/**
* of_graph_get_remote_port_parent() - get remote port's parent node
* @node: pointer to a local endpoint device_node
*
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index befef42..e859eb7 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -31,6 +31,8 @@ int of_graph_parse_endpoint(const struct device_node *node,
struct of_endpoint *endpoint);
struct device_node *of_graph_get_next_endpoint(const struct device_node
*parent,
struct device_node *previous);
+struct device_node *of_graph_get_endpoint_by_regs(
+ const struct device_node *parent, int port_reg, int reg);
struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node);
struct device_node *of_graph_get_remote_port(const struct device_node *node);
@@ -49,6 +51,12 @@ static inline struct device_node *of_graph_get_next_endpoint(
return NULL;
}
+struct device_node *of_graph_get_endpoint_by_regs(
+ const struct device_node *parent, int port_reg, int reg)
+{
+ return NULL;
+}
+
static inline struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] dt-bindings: clk: hisilicon: Document stub clock driver
Document the new compatible for stub clock driver which is used for CPU
and DDR's dynamic frequency scaling.
Signed-off-by: Leo Yan
---
.../devicetree/bindings/clock/hisi,stub-clock.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/hisi,stub-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/hisi,stub-clock.txt
b/Documentation/devicetree/bindings/clock/hisi,stub-clock.txt
new file mode 100644
index 000..07ef5a11
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hisi,stub-clock.txt
@@ -0,0 +1,38 @@
+* Clock bindings for Hisilicon Stub Clock Driver
+
+The Hisilicon stub clock will directly send dynamic frequency scaling request
+to power controller, then the power controller will handle the request for
+cpu and ddr's frequency change.
+
+Required properties:
+- compatible: must be "hisilicon,hisi-clock-stub"
+- hisilicon,clk-stub-sram: phandle to the syscon managing the SoC internal
sram;
+ the driver need use the sram to pass parameters for frequency change.
+- hisilicon,clk-stub-mc: phandle to the syscon managing the multi-cores'
+ communication; need set related register to trigger the dynamic frequency
+ scaling.
+- #clock-cells: should be <1>
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in .
+
+Example:
+
+ sram: sram {
+ compatible = "hisilicon,sram", "syscon";
+ reg = <0x0 0xFFF8 0x0 0x12000>;
+ };
+
+ ipc_s: ipc_s {
+ compatible = "hisilicon,ipc-s", "syscon";
+ reg = <0x0 0xF751 0x0 0x1000>;
+ };
+
+ clock_stub: clock_stub {
+ compatible = "hisilicon,hisi-clock-stub";
+ hisilicon,clk-stub-sram = <&sram>;
+ hisilicon,clk-stub-mc = <&ipc_s>;
+ #clock-cells = <1>;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] clk: hisi: add API for allocation clk data struct
In the old clk init function, it will read the register base address
from dts and allocate the clk data structures. But for the some cases,
the clock driver don't need init the reg's base address, which will
directly access mmio region with syscon.
So for clock's initialization, this patch adds one more API which is
only for allocating clock data structure.
Signed-off-by: Leo Yan
---
drivers/clk/hisilicon/clk.c | 42 +++---
drivers/clk/hisilicon/clk.h | 2 ++
2 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/clk/hisilicon/clk.c b/drivers/clk/hisilicon/clk.c
index a078e84..1e4c5c6 100644
--- a/drivers/clk/hisilicon/clk.c
+++ b/drivers/clk/hisilicon/clk.c
@@ -38,30 +38,17 @@
static DEFINE_SPINLOCK(hisi_clk_lock);
-struct hisi_clock_data __init *hisi_clk_init(struct device_node *np,
-int nr_clks)
+struct hisi_clock_data __init *hisi_clk_alloc_data(struct device_node *np,
+ int nr_clks)
{
struct hisi_clock_data *clk_data;
struct clk **clk_table;
- void __iomem *base;
-
- if (np) {
- base = of_iomap(np, 0);
- if (!base) {
- pr_err("failed to map Hisilicon clock registers\n");
- goto err;
- }
- } else {
- pr_err("failed to find Hisilicon clock node in DTS\n");
- goto err;
- }
clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
if (!clk_data) {
pr_err("%s: could not allocate clock data\n", __func__);
goto err;
}
- clk_data->base = base;
clk_table = kzalloc(sizeof(struct clk *) * nr_clks, GFP_KERNEL);
if (!clk_table) {
@@ -72,12 +59,37 @@ struct hisi_clock_data __init *hisi_clk_init(struct
device_node *np,
clk_data->clk_data.clk_num = nr_clks;
of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data->clk_data);
return clk_data;
+
err_data:
kfree(clk_data);
err:
return NULL;
}
+struct hisi_clock_data __init *hisi_clk_init(struct device_node *np,
+int nr_clks)
+{
+ struct hisi_clock_data *clk_data;
+ void __iomem *base;
+
+ if (np) {
+ base = of_iomap(np, 0);
+ if (!base) {
+ pr_err("failed to map Hisilicon clock registers\n");
+ return NULL;
+ }
+ printk("%s: base %p\n", __func__, base);
+ } else {
+ pr_err("failed to find Hisilicon clock node in DTS\n");
+ return NULL;
+ }
+
+ clk_data = hisi_clk_alloc_data(np, nr_clks);
+ if (clk_data)
+ clk_data->base = base;
+ return clk_data;
+}
+
void __init hisi_clk_register_fixed_rate(struct hisi_fixed_rate_clock *clks,
int nums, struct hisi_clock_data *data)
{
diff --git a/drivers/clk/hisilicon/clk.h b/drivers/clk/hisilicon/clk.h
index 31083ff..624f608 100644
--- a/drivers/clk/hisilicon/clk.h
+++ b/drivers/clk/hisilicon/clk.h
@@ -96,6 +96,8 @@ struct clk *hisi_register_clkgate_sep(struct device *, const
char *,
u8, spinlock_t *);
struct hisi_clock_data __init *hisi_clk_init(struct device_node *, int);
+struct hisi_clock_data __init *hisi_clk_alloc_data(struct device_node *np,
+ int nr_clks);
void __init hisi_clk_register_fixed_rate(struct hisi_fixed_rate_clock *,
int, struct hisi_clock_data *);
void __init hisi_clk_register_fixed_factor(struct hisi_fixed_factor_clock *,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] clk: hisi: add stub clock register function
Add stub clock register function, so can easily enable stub clock for
platforms.
Signed-off-by: Leo Yan
---
drivers/clk/hisilicon/clk.c | 29 +
drivers/clk/hisilicon/clk.h | 12
2 files changed, 41 insertions(+)
diff --git a/drivers/clk/hisilicon/clk.c b/drivers/clk/hisilicon/clk.c
index 1e4c5c6..74ce813 100644
--- a/drivers/clk/hisilicon/clk.c
+++ b/drivers/clk/hisilicon/clk.c
@@ -244,3 +244,32 @@ void __init hisi_clk_register_gate_sep(struct
hisi_gate_clock *clks,
data->clk_data.clks[clks[i].id] = clk;
}
}
+
+void __init hisi_clk_register_stub(struct hisi_stub_clock *clks, int nums,
+ struct hisi_clock_data *data,
+ struct device_node *np)
+{
+ struct clk *clk;
+ int i;
+
+ for (i = 0; i < nums; i++) {
+ clk = hisi_register_stub_clk(np,
+clks[i].id,
+clks[i].name,
+clks[i].parent_name,
+clks[i].flags,
+&hisi_clk_lock);
+ if (IS_ERR(clk)) {
+ pr_err("%s: failed to register clock %s\n",
+ __func__, clks[i].name);
+ continue;
+ }
+
+ if (clks[i].alias)
+ clk_register_clkdev(clk, clks[i].name, NULL);
+
+ data->clk_data.clks[clks[i].id] = clk;
+ }
+
+ return;
+}
diff --git a/drivers/clk/hisilicon/clk.h b/drivers/clk/hisilicon/clk.h
index e99184a..89ce9ad 100644
--- a/drivers/clk/hisilicon/clk.h
+++ b/drivers/clk/hisilicon/clk.h
@@ -90,6 +90,14 @@ struct hisi_gate_clock {
const char *alias;
};
+struct hisi_stub_clock {
+ unsigned intid;
+ char*name;
+ const char *parent_name;
+ unsigned long flags;
+ const char *alias;
+};
+
struct clk *hisi_register_clkgate_sep(struct device *, const char *,
const char *, unsigned long,
void __iomem *, u8,
@@ -113,4 +121,8 @@ void __init hisi_clk_register_gate(struct hisi_gate_clock *,
int, struct hisi_clock_data *);
void __init hisi_clk_register_gate_sep(struct hisi_gate_clock *,
int, struct hisi_clock_data *);
+void __init hisi_clk_register_stub(struct hisi_stub_clock *clks, int nums,
+ struct hisi_clock_data *data,
+ struct device_node *np);
+
#endif /* __HISI_CLK_H */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] clk: hisi: add stub clk driver
On hisilicon platform, there have some clocks which can directly send
messages to power controller to change frequency; this includes cpu and
ddr's clocks.
For dynamic frequency scaling, firstly need write the frequency value
to sram region, and then write the communication register to trigger
power controller to run the state machine. These two part's addresses
are different and will be shared w/t other module; so use syscon APIs
to pass these two memory region and accessing related registers.
This init driver will support cpu frequency change firstly.
Signed-off-by: Leo Yan
---
drivers/clk/hisilicon/Makefile | 2 +-
drivers/clk/hisilicon/clk-stub.c| 284
drivers/clk/hisilicon/clk.h | 3 +
include/dt-bindings/clock/hisi,stub-clock.h | 26 +++
4 files changed, 314 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/hisilicon/clk-stub.c
create mode 100644 include/dt-bindings/clock/hisi,stub-clock.h
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
index 038c02f..fb26ac8 100644
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -2,7 +2,7 @@
# Hisilicon Clock specific Makefile
#
-obj-y += clk.o clkgate-separated.o
+obj-y += clk.o clkgate-separated.o clk-stub.o
obj-$(CONFIG_ARCH_HI3xxx) += clk-hi3620.o
obj-$(CONFIG_ARCH_HIP04) += clk-hip04.o
diff --git a/drivers/clk/hisilicon/clk-stub.c b/drivers/clk/hisilicon/clk-stub.c
new file mode 100644
index 000..897d6d3
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-stub.c
@@ -0,0 +1,284 @@
+/*
+ * Hisilicon stub clock driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ * Copyright (c) 2015 Linaro Limited.
+ *
+ * Author: Leo Yan
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* CPU dynamic frequency scaling */
+#define ACPU_DFS_FREQ_MAX (0x1724)
+#define ACPU_DFS_FLAG (0x1AF4)
+#define ACPU_DFS_FREQ_REQ (0x1AF8)
+#define ACPU_DFS_FREQ_LMT (0x1AFC)
+
+#define ACPU_DFS_LOCK_FLAG (0xAEAEAEAE)
+
+/* Multi-core communication */
+#define MC_CORE_ACPU 0x2
+#define MC_COM_CPU_RAW_INT_OFFSET(i) (0x400 + (i << 4))
+#define MC_COM_INT_ACPU_DFS15
+
+#define to_stub_clk(hw) container_of(hw, struct hisi_stub_clk, hw)
+
+struct hisi_stub_clk {
+ struct clk_hw hw;
+
+ /*
+* hi6220:
+* - 0: A53; 1: A53; 2: gpu; 3: ddr;
+*/
+ u32 id;
+ u32 rate;
+ spinlock_t *lock;
+};
+
+static int initialized_stub_clk = 0;
+static struct regmap *mc_map = NULL;
+static struct regmap *dfs_map = NULL;
+
+static unsigned int hisi_acpu_get_freq(void)
+{
+ unsigned int freq;
+
+ regmap_read(dfs_map, ACPU_DFS_FREQ_REQ, &freq);
+ return freq;
+}
+
+static int hisi_acpu_set_freq(unsigned int freq)
+{
+ /* set the frequency in sram */
+ regmap_write(dfs_map, ACPU_DFS_FREQ_REQ, freq);
+
+ /* send request to power controller */
+ regmap_write(mc_map, MC_COM_CPU_RAW_INT_OFFSET(MC_CORE_ACPU),
+(1 << MC_COM_INT_ACPU_DFS));
+ return 0;
+}
+
+static int hisi_acpu_round_freq(unsigned int freq)
+{
+ unsigned int limit_flag, limit_freq = UINT_MAX;
+ unsigned int max_freq;
+
+ /* check the constrainted frequency */
+ regmap_read(dfs_map, ACPU_DFS_FLAG, &limit_flag);
+ if (limit_flag == ACPU_DFS_LOCK_FLAG)
+ regmap_read(dfs_map, ACPU_DFS_FREQ_LMT, &limit_freq);
+
+ /* check the supported maximum frequency */
+ regmap_read(dfs_map, ACPU_DFS_FREQ_MAX, &max_freq);
+
+ /* calculate the real maximum frequency */
+ max_freq = min(max_freq, limit_freq);
+
+ if (WARN_ON(freq > max_freq))
+ freq = max_freq;
+
+ return freq;
+}
+
+static unsigned long hisi_stub_clk_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ u32 rate = 0;
+ struct hisi_stub_clk *stub_clk = to_stub_clk(hw);
+ unsigned long flags;
+
+ BUG_ON(!stub_clk->lock);
+
+ spin_lock_irqsave(stub_clk->lock, flags);
+
+ switch (stub_clk->id) {
+ case HISI_STUB_ACPU0:
+ rate = hisi_acpu_get_freq();
+
+ /* convert from KHz to Hz */
+ rate *= 1000;
+ break;
+
+ default:
+ pr_err("%s: un-supported clock id %d\n", __func__,
+ stub_clk->id);
+ break;
+ }
+
+ spin_unlock_irqrestore(stub_clk->lock, flags);
+ return rate;
+}
+
+static int hisi_stub_clk_set_rate(struct clk_hw *hw, unsigned long r
[PATCH 0/4] clk: hisilicon: support stub clock
This series adds support for hisilicon stub clock driver. On hi6220, the bootloader needs load the firmware image and set info for OPPs; after run into kernel, the stub clock driver is used to communicate w/t firmware for cpu dynamic frequency scaling. So finally s/w will simply write request in sram and send ipc to power controller. These patches have been tested on 96board hikey and will be used by cpufreq driver. Leo Yan (4): clk: hisi: add API for allocation clk data struct dt-bindings: clk: hisilicon: Document stub clock driver clk: hisi: add stub clk driver clk: hisi: add stub clock register function .../devicetree/bindings/clock/hisi,stub-clock.txt | 38 +++ drivers/clk/hisilicon/Makefile | 2 +- drivers/clk/hisilicon/clk-stub.c | 284 + drivers/clk/hisilicon/clk.c| 71 -- drivers/clk/hisilicon/clk.h| 17 ++ include/dt-bindings/clock/hisi,stub-clock.h| 26 ++ 6 files changed, 422 insertions(+), 16 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/hisi,stub-clock.txt create mode 100644 drivers/clk/hisilicon/clk-stub.c create mode 100644 include/dt-bindings/clock/hisi,stub-clock.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/7] dmaengine: omap-dma: Use defines for dma channels and request count
On Wed, Mar 11, 2015 at 03:23:27PM +0200, Peter Ujfalusi wrote:
> Instead of magic numbers in the code, use define for number of logical DMA
> channels and DMA requests.
>
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/dma/omap-dma.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> index 7dd6dd121681..56c33e93dd24 100644
> --- a/drivers/dma/omap-dma.c
> +++ b/drivers/dma/omap-dma.c
> @@ -22,6 +22,9 @@
>
> #include "virt-dma.h"
>
> +#define OMAP_SDMA_REQUESTS 127
> +#define OMAP_SDMA_CHANNELS 32
Again why dont we put these things in DT ?
--
~Vinod
> +
> struct omap_dmadev {
> struct dma_device ddev;
> spinlock_t lock;
> @@ -33,7 +36,7 @@ struct omap_dmadev {
> bool legacy;
> spinlock_t irq_lock;
> uint32_t irq_enable_mask;
> - struct omap_chan *lch_map[32];
> + struct omap_chan *lch_map[OMAP_SDMA_CHANNELS];
> };
>
> struct omap_chan {
> @@ -1115,7 +1118,7 @@ static int omap_dma_probe(struct platform_device *pdev)
>
> tasklet_init(&od->task, omap_dma_sched, (unsigned long)od);
>
> - for (i = 0; i < 127; i++) {
> + for (i = 0; i < OMAP_SDMA_REQUESTS; i++) {
> rc = omap_dma_chan_init(od, i);
> if (rc) {
> omap_dma_free(od);
> --
> 2.3.0
>
--
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] dmaengine: Add driver for TI DMA crossbar on DRA7x
On Wed, Mar 11, 2015 at 03:23:26PM +0200, Peter Ujfalusi wrote:
> The DRA7x has more peripherals with DMA requests than the sDMA can handle:
> 205 vs 127. All DMA requests are routed through the DMA crossbar, which can
> be configured to route selected incoming DMA requests to specific sDMA
> request.
>
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/dma/Kconfig | 4 +
> drivers/dma/Makefile | 1 +
> drivers/dma/ti-dma-crossbar.c | 190
> ++
> 3 files changed, 195 insertions(+)
> create mode 100644 drivers/dma/ti-dma-crossbar.c
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 074ffad334a7..519657a37ca1 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -247,6 +247,9 @@ config TI_EDMA
> Enable support for the TI EDMA controller. This DMA
> engine is found on TI DaVinci and AM33xx parts.
>
> +config TI_DMA_CROSSBAR
> + bool
> +
> config ARCH_HAS_ASYNC_TX_FIND_CHANNEL
> bool
>
> @@ -332,6 +335,7 @@ config DMA_OMAP
> depends on ARCH_OMAP
> select DMA_ENGINE
> select DMA_VIRTUAL_CHANNELS
> + select TI_DMA_CROSSBAR if SOC_DRA7XX
>
> config DMA_BCM2835
> tristate "BCM2835 DMA engine support"
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index bf4485800c60..6ec7af6a416c 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -39,6 +39,7 @@ obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o
> obj-$(CONFIG_DMA_SA11X0) += sa11x0-dma.o
> obj-$(CONFIG_MMP_TDMA) += mmp_tdma.o
> obj-$(CONFIG_DMA_OMAP) += omap-dma.o
> +obj-$(CONFIG_TI_DMA_CROSSBAR) += ti-dma-crossbar.o
> obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o
> obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o
> obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
> diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
> new file mode 100644
> index ..591307bd4370
> --- /dev/null
> +++ b/drivers/dma/ti-dma-crossbar.c
> @@ -0,0 +1,190 @@
> +/*
> + * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
> + * Author: Peter Ujfalusi
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define TI_XBAR_OUTPUTS 127
> +#define TI_XBAR_INPUTS 256
Ideally this should be moved to DT. Will next revision of this chip always
support these output and inputs?
> +
> +static DEFINE_IDR(map_idr);
> +
> +struct ti_dma_xbar_data {
> + struct dma_router dmarouter;
> + struct regmap *regmap;
> +
> + uint safe_val; /* Value to rest the crossbar lines */
> + uint xbar_requests; /* number of DMA requests connected to XBAR */
> + uint dma_requests; /* number of DMA requests forwarded to DMA */
> +
> + void __iomem *iomem;
> +};
> +
> +struct ti_dma_xbar_map {
> + int xbar_in;
> + int xbar_out;
> +};
> +
> +static void ti_dma_xbar_free(struct device *dev, void *route_data)
> +{
> + struct ti_dma_xbar_data *xbar = dev_get_drvdata(dev);
> + struct ti_dma_xbar_map *map = route_data;
> +
> + dev_dbg(dev, "Unmapping XBAR%d (was routed to %d)\n",
> + map->xbar_in, map->xbar_out);
> +
> + regmap_write(xbar->regmap, map->xbar_out * 2, 0);
just out of curiosity how much do you save using regmap :)
> +static int ti_dma_xbar_probe(struct platform_device *pdev)
> +{
> + struct device_node *node = pdev->dev.of_node;
> + struct device_node *dma_node;
> + struct ti_dma_xbar_data *xbar;
> + struct resource *res;
> + void __iomem *iomem;
> + int i, ret;
> +
> + if (!node)
> + return -ENODEV;
> +
> + dma_node = of_parse_phandle(node, "dma-device", 0);
> + if (!dma_node) {
> + dev_err(&pdev->dev, "Can't get target DMA node\n");
> + return -ENODEV;
> + }
> +
> + xbar = devm_kzalloc(&pdev->dev, sizeof(*xbar), GFP_KERNEL);
> + if (!xbar)
> + return -ENOMEM;
> +
> + if (of_property_read_u32(dma_node, "dma-requests",
> + &xbar->dma_requests)) {
> + dev_info(&pdev->dev,
> + "Missing XBAR output information, using %u.\n",
> + TI_XBAR_OUTPUTS);
> + xbar->dma_requests = TI_XBAR_OUTPUTS;
> + }
> + of_node_put(dma_node);
_put here?
> +int omap_dmaxbar_init(void)
> +{
> + return platform_driver_register(&ti_dma_xbar_driver);
> +}
> +arch_initcall(omap_dmaxbar_init);
why arch_initcall?
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] dmaengine: of_dma: Support for DMA routers
On Wed, Mar 11, 2015 at 03:23:24PM +0200, Peter Ujfalusi wrote:
> DMA routers are transparent devices used to mux DMA requests from
> peripherals to DMA controllers. They are used when the SoC integrates more
> devices with DMA requests then their controller can handle.
> DRA7x is one example of such SoC, where the sDMA can hanlde 128 DMA request
> lines, but in SoC level it has 205 DMA requests.
>
> The of_dma_router will be registered as of_dma_controller with special
> xlate function and additional parameters and the code will translate and
> requests a DMA channel from the real DMA controller.
> This way the router can be transparent for the system while remaining generic
> enough to be used in different environments.
>
Looks fine, was expecting a Documentation updates as well, but that can come
as follow up patch too
--
~Vinod
> Signed-off-by: Peter Ujfalusi
> ---
> Documentation/devicetree/bindings/dma/dma.txt | 28
> drivers/dma/dmaengine.c | 7 ++
> drivers/dma/of-dma.c | 92
> +++
> include/linux/dmaengine.h | 17 +
> include/linux/of_dma.h| 21 ++
> 5 files changed, 165 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/dma/dma.txt
> b/Documentation/devicetree/bindings/dma/dma.txt
> index 82104271e754..f728b978178e 100644
> --- a/Documentation/devicetree/bindings/dma/dma.txt
> +++ b/Documentation/devicetree/bindings/dma/dma.txt
> @@ -31,6 +31,34 @@ Example:
> dma-requests = <127>;
> };
>
> +* DMA router
> +
> +DMA routers are transparent IP blocks used to route DMA request lines from
> +devices to the DMA controller. Some SoCs (like TI DRA7x) have more
> peripherals
> +integrated with DMA requests than what the DMA controller can handle
> directly.
> +
> +Required property:
> +- dma-device:phandle of the DMA controller. The router is
> modifying
> + the DMA requests for this controller.
> +- #dma-cells:Must be at least 1. Used to provide DMA router
> specific
> + information. See DMA client binding below for more
> + details.
> +
> +Optional properties:
> +- dma-requests: Number of incoming request lines the router can handle.
> +- dma-device
> + - dma-requests: The router driver might need to look for this in order
> + to configure the routing.
> +
> +Example:
> + sdma_xbar: dma-router@4a002b78 {
> + compatible = "ti,dra7-dma-crossbar";
> + reg = <0x4a002b78 0xfc>;
> + #dma-cells = <1>;
> + dma-requests = <205>;
> + ti,dma-safe-map = <0>;
> + dma-device = <&sdma>;
> + };
>
> * DMA client
>
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 344b0ac6d985..1bb67dae5880 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -271,6 +271,13 @@ static void dma_chan_put(struct dma_chan *chan)
> /* This channel is not in use anymore, free it */
> if (!chan->client_count && chan->device->device_free_chan_resources)
> chan->device->device_free_chan_resources(chan);
> +
> + /* If the channel is used via a DMA request router, free the mapping */
> + if (chan->router && chan->router->route_free) {
> + chan->router->route_free(chan->router->dev, chan->route_data);
> + chan->router = NULL;
> + chan->route_data = NULL;
> + }
> }
>
> enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie)
> diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
> index ca31f1b45366..c86f8823da0d 100644
> --- a/drivers/dma/of-dma.c
> +++ b/drivers/dma/of-dma.c
> @@ -45,6 +45,53 @@ static struct of_dma *of_dma_find_controller(struct
> of_phandle_args *dma_spec)
> }
>
> /**
> + * of_dma_router_xlate - translation function for router devices
> + * @dma_spec:pointer to DMA specifier as found in the device tree
> + * @of_dma: pointer to DMA controller data (router information)
> + *
> + * The function creates new dma_spec to be passed to the router driver's
> + * of_dma_route_allocate() function to prepare a dma_spec which will be used
> + * to request channel from the real DMA controller.
> + */
> +static struct dma_chan *of_dma_router_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + struct dma_chan *chan;
> + struct of_dma *ofdma_target;
> + struct device_node *dma_target;
> + struct of_phandle_args dma_spec_target;
> + void*route_data;
> +
> + dma_target = of_parse_phandle(dma_spec->np, "dma-device", 0);
> + if (!dma_target) {
> + pr_err("%s: Can't get target DMA\n", __func__);
> + return NULL;
> + }
> +
> + /* translate the request
[PATCH 3/4] powerpc: support CPU hotplug for e500mc, e5500 and e6500
Implemented CPU hotplug on e500mc, e5500 and e6500, and support
multiple threads mode and 64-bits mode.
For e6500 with two threads, if one thread is online, it can
enable/disable the other thread in the same core. If two threads of
one core are offline, the core will enter the PH20 state (a low power
state). When the core is up again, Thread0 is up first, and it will be
bound with the present booting cpu. This way, all CPUs can hotplug
separately.
Signed-off-by: Chenhui Zhao
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/include/asm/fsl_pm.h | 4 +
arch/powerpc/include/asm/smp.h| 2 +
arch/powerpc/kernel/head_64.S | 20 +++--
arch/powerpc/kernel/smp.c | 5 ++
arch/powerpc/platforms/85xx/smp.c | 182 +-
arch/powerpc/sysdev/fsl_rcpm.c| 56
7 files changed, 220 insertions(+), 51 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 22b0940..9846c83 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -380,7 +380,7 @@ config SWIOTLB
config HOTPLUG_CPU
bool "Support for enabling/disabling CPUs"
depends on SMP && (PPC_PSERIES || \
- PPC_PMAC || PPC_POWERNV || (PPC_85xx && !PPC_E500MC))
+ PPC_PMAC || PPC_POWERNV || FSL_SOC_BOOKE)
---help---
Say Y here to be able to disable and re-enable individual
CPUs at runtime on SMP machines.
diff --git a/arch/powerpc/include/asm/fsl_pm.h
b/arch/powerpc/include/asm/fsl_pm.h
index bbe6089..579f495 100644
--- a/arch/powerpc/include/asm/fsl_pm.h
+++ b/arch/powerpc/include/asm/fsl_pm.h
@@ -34,6 +34,10 @@ struct fsl_pm_ops {
void (*cpu_enter_state)(int cpu, int state);
/* exit the CPU from the specified state */
void (*cpu_exit_state)(int cpu, int state);
+ /* cpu up */
+ void (*cpu_up)(int cpu);
+ /* cpu die */
+ void (*cpu_die)(int cpu);
/* place the platform in the sleep state */
int (*plat_enter_sleep)(void);
/* freeze the time base */
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index d607df5..1e500ed 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -67,6 +67,7 @@ void generic_cpu_die(unsigned int cpu);
void generic_set_cpu_dead(unsigned int cpu);
void generic_set_cpu_up(unsigned int cpu);
int generic_check_cpu_restart(unsigned int cpu);
+int generic_check_cpu_dead(unsigned int cpu);
#endif
#ifdef CONFIG_PPC64
@@ -198,6 +199,7 @@ extern void generic_secondary_thread_init(void);
extern unsigned long __secondary_hold_spinloop;
extern unsigned long __secondary_hold_acknowledge;
extern char __secondary_hold;
+extern unsigned int __cur_boot_cpu;
extern void __early_start(void);
#endif /* __ASSEMBLY__ */
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index d48125d..ac89050 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -181,6 +181,10 @@ exception_marker:
#endif
#ifdef CONFIG_PPC_BOOK3E
+ .globl __cur_boot_cpu
+__cur_boot_cpu:
+ .long 0x0
+ .align 3
_GLOBAL(fsl_secondary_thread_init)
/* Enable branch prediction */
lis r3,BUCSR_INIT@h
@@ -189,16 +193,14 @@ _GLOBAL(fsl_secondary_thread_init)
isync
/*
-* Fix PIR to match the linear numbering in the device tree.
-*
-* On e6500, the reset value of PIR uses the low three bits for
-* the thread within a core, and the upper bits for the core
-* number. There are two threads per core, so shift everything
-* but the low bit right by two bits so that the cpu numbering is
-* continuous.
+* The current thread has been in 64-bit mode,
+* see the value of TMRN_IMSR.
+* compute the address of __cur_boot_cpu
*/
- mfspr r3, SPRN_PIR
- rlwimi r3, r3, 30, 2, 30
+ bl 10f
+10:mflrr22
+ addir22,r22,(__cur_boot_cpu - 10b)
+ lwz r3,0(r22)
mtspr SPRN_PIR, r3
#endif
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index ec9ec20..2cca27a 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -454,6 +454,11 @@ int generic_check_cpu_restart(unsigned int cpu)
return per_cpu(cpu_state, cpu) == CPU_UP_PREPARE;
}
+int generic_check_cpu_dead(unsigned int cpu)
+{
+ return per_cpu(cpu_state, cpu) == CPU_DEAD;
+}
+
static bool secondaries_inhibited(void)
{
return kvm_hv_mode_active();
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index fba474f..f51441b 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -2,7 +2,7 @@
* Author: Andy Fleming
*Kumar Gala
*
- * Copyright 2006-2008, 2011-2012 Freescale Semiconductor Inc.
+ * Copyright 2006-2008, 2011-2012, 2015 Freescale Semiconductor Inc.
*
* This program i
[PATCH 2/4] powerpc/rcpm: add RCPM driver
There is a RCPM (Run Control/Power Management) in Freescale QorIQ
series processors. The device performs tasks associated with device
run control and power management.
The driver implements some features: mask/unmask irq, enter/exit low
power states, freeze time base, etc.
Signed-off-by: Chenhui Zhao
---
Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 23 ++
arch/powerpc/include/asm/fsl_guts.h| 105 ++
arch/powerpc/include/asm/fsl_pm.h | 49 +++
arch/powerpc/platforms/85xx/Kconfig| 1 +
arch/powerpc/sysdev/Kconfig| 5 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/fsl_rcpm.c | 353 +
7 files changed, 537 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/fsl/rcpm.txt
create mode 100644 arch/powerpc/include/asm/fsl_pm.h
create mode 100644 arch/powerpc/sysdev/fsl_rcpm.c
diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
new file mode 100644
index 000..8c21b6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -0,0 +1,23 @@
+* Run Control and Power Management
+
+The RCPM performs all device-level tasks associated with device run control
+and power management.
+
+Required properites:
+ - reg : Offset and length of the register set of RCPM block.
+ - compatible : Specifies the compatibility list for the RCPM. The type
+should be string, such as "fsl,qoriq-rcpm-1.0", "fsl,qoriq-rcpm-2.0".
+
+Example:
+The RCPM node for T4240:
+ rcpm: global-utilities@e2000 {
+ compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
+ reg = <0xe2000 0x1000>;
+ };
+
+The RCPM node for P4080:
+ rcpm: global-utilities@e2000 {
+ compatible = "fsl,qoriq-rcpm-1.0";
+ reg = <0xe2000 0x1000>;
+ #sleep-cells = <1>;
+ };
diff --git a/arch/powerpc/include/asm/fsl_guts.h
b/arch/powerpc/include/asm/fsl_guts.h
index 43b6bb1..96018ee 100644
--- a/arch/powerpc/include/asm/fsl_guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -188,5 +188,110 @@ static inline void guts_set_pmuxcr_dma(struct ccsr_guts
__iomem *guts,
#endif
+struct ccsr_rcpm_v1 {
+ u8 res[4];
+ __be32 cdozsr; /* 0x0004 Core Doze Status Register */
+ u8 res0008[4];
+ __be32 cdozcr; /* 0x000c Core Doze Control Register */
+ u8 res0010[4];
+ __be32 cnapsr; /* 0x0014 Core Nap Status Register */
+ u8 res0018[4];
+ __be32 cnapcr; /* 0x001c Core Nap Control Register */
+ u8 res0020[4];
+ __be32 cdozpsr;/* 0x0024 Core Doze Previous Status Register */
+ u8 res0028[4];
+ __be32 cnappsr;/* 0x002c Core Nap Previous Status Register */
+ u8 res0030[4];
+ __be32 cwaitsr;/* 0x0034 Core Wait Status Register */
+ u8 res0038[4];
+ __be32 cwdtdsr;/* 0x003c Core Watchdog Detect Status Register */
+ __be32 powmgtcsr; /* 0x0040 Power Management Control&Status Register
*/
+#define RCPM_POWMGTCSR_SLP 0x0002
+ u8 res0044[12];
+ __be32 ippdexpcr; /* 0x0050 IP Powerdown Exception Control Register */
+ u8 res0054[16];
+ __be32 cpmimr; /* 0x0064 Core PM IRQ Mask Register */
+ u8 res0068[4];
+ __be32 cpmcimr;/* 0x006c Core PM Critical IRQ Mask Register */
+ u8 res0070[4];
+ __be32 cpmmcmr;/* 0x0074 Core PM Machine Check Mask Register */
+ u8 res0078[4];
+ __be32 cpmnmimr; /* 0x007c Core PM NMI Mask Register */
+ u8 res0080[4];
+ __be32 ctbenr; /* 0x0084 Core Time Base Enable Register */
+ u8 res0088[4];
+ __be32 ctbckselr; /* 0x008c Core Time Base Clock Select Register */
+ u8 res0090[4];
+ __be32 ctbhltcr; /* 0x0094 Core Time Base Halt Control Register */
+ u8 res0098[4];
+ __be32 cmcpmaskcr; /* 0x00a4 Core Machine Check Mask Register */
+};
+
+struct ccsr_rcpm_v2 {
+ u8 res_00[12];
+ __be32 tph10sr0; /* Thread PH10 Status Register */
+ u8 res_10[12];
+ __be32 tph10setr0; /* Thread PH10 Set Control Register */
+ u8 res_20[12];
+ __be32 tph10clrr0; /* Thread PH10 Clear Control Register */
+ u8 res_30[12];
+ __be32 tph10psr0; /* Thread PH10 Previous Status Register */
+ u8 res_40[12];
+ __be32 twaitsr0; /* Thread Wait Status Register */
+ u8 res_50[96];
+ __be32 pcph15sr; /* Physical Core PH15 Status Register */
+ __be32 pcph15setr; /* Physical Core PH15 Set Control Register */
+ __be32 pcph15clrr; /* Physical Core PH15 Clear Control Register */
+ __be32 pcph15psr; /* Physical Core PH15
Re: [PATCH v2 4/6] drm/exynos: dsi: add support for Exynos5433 SoC
Dear Daniel,
On Wed, 18 Mar 2015 09:52:33 +
Daniel Stone wrote:
> Hi,
>
> On 18 March 2015 at 08:16, Hyungwon Hwang
> wrote:
> > +#define REG(dsi, reg) ((dsi)->reg_base +
> > dsi->driver_data->regs[(reg)])
>
> This seems like a good change in general, but please split it up: it
> makes bisection much easier if you have one patch which adds no
> functionality and should have exactly the same behaviour, and then
> another patch which introduces your changes.
>
Yes. That also looks good to me.
> > @@ -431,15 +579,11 @@ static unsigned long
> > exynos_dsi_set_pll(struct exynos_dsi *dsi, u16 m;
> > u32 reg;
> >
> > - clk_set_rate(dsi->pll_clk, dsi->pll_clk_rate);
> > -
> > - fin = clk_get_rate(dsi->pll_clk);
> > - if (!fin) {
> > - dev_err(dsi->dev, "failed to get PLL clock
> > frequency\n");
> > - return 0;
> > - }
> > -
> > - dev_dbg(dsi->dev, "PLL input frequency: %lu\n", fin);
> > + /*
> > +* The input PLL clock for MIPI DSI in Exynos5433 seems to
> > be fixed
> > +* by OSC CLK.
> > +*/
> > + fin = 24 * MHZ;
>
> Er, is this always true on other platforms as well? Shouldn't this be
> a part of the DeviceTree description?
>
> > @@ -509,7 +656,7 @@ static int exynos_dsi_enable_clock(struct
> > exynos_dsi *dsi) dev_dbg(dsi->dev, "hs_clk = %lu, byte_clk = %lu,
> > esc_clk = %lu\n", hs_clk, byte_clk, esc_clk);
> >
> > - reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
> > + reg = readl(REG(dsi, DSIM_CLKCTRL_REG));
>
> Instead of this readl(REG()) pattern you have everywhere, maybe it
> would be easier to introduce a dsi_read_reg(dsi, reg_enum_value)
> helper, and the same for write_reg.
>
Yes. That's resonable.
> > @@ -1720,18 +1873,16 @@ static int exynos_dsi_probe(struct
> > platform_device *pdev) return -EPROBE_DEFER;
> > }
> >
> > - dsi->pll_clk = devm_clk_get(dev, "pll_clk");
> > - if (IS_ERR(dsi->pll_clk)) {
> > - dev_info(dev, "failed to get dsi pll input
> > clock\n");
> > - ret = PTR_ERR(dsi->pll_clk);
> > - goto err_del_component;
> > - }
> > -
> > - dsi->bus_clk = devm_clk_get(dev, "bus_clk");
> > - if (IS_ERR(dsi->bus_clk)) {
> > - dev_info(dev, "failed to get dsi bus clock\n");
> > - ret = PTR_ERR(dsi->bus_clk);
> > - goto err_del_component;
> > + dsi->clks = devm_kzalloc(dev,
> > + sizeof(*dsi->clks) *
> > dsi->driver_data->num_clks,
> > + GFP_KERNEL);
> > + for (i = 0; i < dsi->driver_data->num_clks; i++) {
> > + dsi->clks[i] = devm_clk_get(dev, clk_names[i]);
> > + if (IS_ERR(dsi->clks[i])) {
> > + dev_info(dev, "failed to get dsi pll input
> > clock\n");
>
> This error message seems wrong; it should contain the name of the
> actual failing clock.
>
OK.
Best regards,
Hyungwon Hwang
> Cheers,
> Daniel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] powerpc/cache: add cache flush operation for various e500
Various e500 core have different cache architecture, so they
need different cache flush operations. Therefore, add a callback
function cpu_flush_caches to the struct cpu_spec. The cache flush
operation for the specific kind of e500 is selected at init time.
The callback function will flush all caches inside the current cpu.
Signed-off-by: Chenhui Zhao
---
arch/powerpc/include/asm/cacheflush.h | 2 -
arch/powerpc/include/asm/cputable.h | 11 +++
arch/powerpc/kernel/asm-offsets.c | 3 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 114 +-
arch/powerpc/kernel/cputable.c| 4 ++
arch/powerpc/kernel/head_fsl_booke.S | 74 ---
arch/powerpc/platforms/85xx/smp.c | 3 +-
7 files changed, 133 insertions(+), 78 deletions(-)
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index 30b35ff..729fde4 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -30,8 +30,6 @@ extern void flush_dcache_page(struct page *page);
#define flush_dcache_mmap_lock(mapping)do { } while (0)
#define flush_dcache_mmap_unlock(mapping) do { } while (0)
-extern void __flush_disable_L1(void);
-
extern void flush_icache_range(unsigned long, unsigned long);
extern void flush_icache_user_range(struct vm_area_struct *vma,
struct page *page, unsigned long addr,
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 5cf5a6d..c776efe4 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -43,6 +43,13 @@ extern int machine_check_e500(struct pt_regs *regs);
extern int machine_check_e200(struct pt_regs *regs);
extern int machine_check_47x(struct pt_regs *regs);
+#if defined(CONFIG_E500) || defined(CONFIG_PPC_E500MC)
+extern void __flush_caches_e500v2(void);
+extern void __flush_caches_e500mc(void);
+extern void __flush_caches_e5500(void);
+extern void __flush_caches_e6500(void);
+#endif
+
/* NOTE WELL: Update identify_cpu() if fields are added or removed! */
struct cpu_spec {
/* CPU is matched via (PVR & pvr_mask) == pvr_value */
@@ -59,6 +66,10 @@ struct cpu_spec {
unsigned inticache_bsize;
unsigned intdcache_bsize;
+#if defined(CONFIG_E500) || defined(CONFIG_PPC_E500MC)
+ /* flush caches inside the current cpu */
+ void (*cpu_flush_caches)(void);
+#endif
/* number of performance monitor counters */
unsigned intnum_pmcs;
enum powerpc_pmc_type pmc_type;
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index 4717859..9567930 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -372,6 +372,9 @@ int main(void)
DEFINE(CPU_SPEC_FEATURES, offsetof(struct cpu_spec, cpu_features));
DEFINE(CPU_SPEC_SETUP, offsetof(struct cpu_spec, cpu_setup));
DEFINE(CPU_SPEC_RESTORE, offsetof(struct cpu_spec, cpu_restore));
+#if defined(CONFIG_E500) || defined(CONFIG_PPC_E500MC)
+ DEFINE(CPU_FLUSH_CACHES, offsetof(struct cpu_spec, cpu_flush_caches));
+#endif
DEFINE(pbe_address, offsetof(struct pbe, address));
DEFINE(pbe_orig_address, offsetof(struct pbe, orig_address));
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index dddba3e..c8c251f 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -1,7 +1,7 @@
/*
* This file contains low level CPU setup functions.
* Kumar Gala
- * Copyright 2009 Freescale Semiconductor, Inc.
+ * Copyright 2009, 2015 Freescale Semiconductor, Inc.
*
* Based on cpu_setup_6xx code by
* Benjamin Herrenschmidt
@@ -13,11 +13,13 @@
*
*/
+#include
#include
#include
#include
#include
#include
+#include
_GLOBAL(__e500_icache_setup)
mfspr r0, SPRN_L1CSR1
@@ -233,3 +235,113 @@ _GLOBAL(__setup_cpu_e5500)
mtlrr5
blr
#endif
+
+/* flush L1 date cache, it can apply to e500v2, e500mc and e5500 */
+_GLOBAL(flush_dcache_L1)
+ mfmsr r10
+ wrteei 0
+
+ mfspr r3,SPRN_L1CFG0
+ rlwinm r5,r3,9,3 /* Extract cache block size */
+ twlgti r5,1/* Only 32 and 64 byte cache blocks
+* are currently defined.
+*/
+ li r4,32
+ subfic r6,r5,2 /* r6 = log2(1KiB / cache block size) -
+* log2(number of ways)
+*/
+ slw r5,r4,r5/* r5 = cache block size */
+
+ rlwinm r7,r3,0,0xff/* Extract number of KiB in the cache */
+ mulli r7,r7,13/* An 8-way cache will require 13
+* loads per set.
+*/
+
[PATCH 4/4] powerpc/85xx: support sleep feature on QorIQ SoCs with RCPM
In sleep mode, the clocks of e500 cores and unused IP blocks is
turned off. The IP blocks which are allowed to wake up the processor
are still running.
The sleep mode is equal to the Standby state in Linux. Use the
command to enter sleep mode:
echo standby > /sys/power/state
Signed-off-by: Chenhui Zhao
---
arch/powerpc/Kconfig | 3 +-
arch/powerpc/platforms/85xx/Kconfig| 5 +++
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/qoriq_pm.c | 59 ++
arch/powerpc/platforms/86xx/Kconfig| 1 +
5 files changed, 67 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/platforms/85xx/qoriq_pm.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9846c83..162eb53 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -233,7 +233,7 @@ config ARCH_HIBERNATION_POSSIBLE
config ARCH_SUSPEND_POSSIBLE
def_bool y
depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
- (PPC_85xx && !PPC_E500MC) || PPC_86xx || PPC_PSERIES \
+ FSL_SOC_BOOKE || PPC_86xx || PPC_PSERIES \
|| 44x || 40x
config PPC_DCR_NATIVE
@@ -747,7 +747,6 @@ config FSL_PCI
config FSL_PMC
bool
- default y
depends on SUSPEND && (PPC_85xx || PPC_86xx)
help
Freescale MPC85xx/MPC86xx power management controller support
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index ae1b8a2..b7c762e 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -9,6 +9,8 @@ menuconfig FSL_SOC_BOOKE
select SERIAL_8250_EXTENDED if SERIAL_8250
select SERIAL_8250_SHARE_IRQ if SERIAL_8250
select FSL_CORENET_RCPM if PPC_E500MC
+ select FSL_QORIQ_PM if SUSPEND && PPC_E500MC
+ select FSL_PMC if SUSPEND && !PPC_E500MC
default y
if FSL_SOC_BOOKE
@@ -289,3 +291,6 @@ endif # FSL_SOC_BOOKE
config TQM85xx
bool
+
+config FSL_QORIQ_PM
+ bool
diff --git a/arch/powerpc/platforms/85xx/Makefile
b/arch/powerpc/platforms/85xx/Makefile
index 1fe7fb9..65dfb60 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -2,6 +2,7 @@
# Makefile for the PowerPC 85xx linux kernel.
#
obj-$(CONFIG_SMP) += smp.o
+obj-$(CONFIG_FSL_QORIQ_PM) += qoriq_pm.o
obj-y += common.o
diff --git a/arch/powerpc/platforms/85xx/qoriq_pm.c
b/arch/powerpc/platforms/85xx/qoriq_pm.c
new file mode 100644
index 000..7594f08
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/qoriq_pm.c
@@ -0,0 +1,59 @@
+/*
+ * Support Power Management feature
+ *
+ * Copyright 2014-2015 Freescale Semiconductor Inc.
+ *
+ * Author: Chenhui Zhao
+ *
+ * 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; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+
+#include
+
+static int qoriq_suspend_enter(suspend_state_t state)
+{
+ int ret = 0;
+
+ switch (state) {
+ case PM_SUSPEND_STANDBY:
+ cur_cpu_spec->cpu_flush_caches();
+ ret = qoriq_pm_ops->plat_enter_sleep();
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
+static int qoriq_suspend_valid(suspend_state_t state)
+{
+ unsigned int pm_modes;
+
+ pm_modes = qoriq_pm_ops->get_pm_modes();
+
+ if ((state == PM_SUSPEND_STANDBY) && (pm_modes & FSL_PM_SLEEP))
+ return 1;
+
+ return 0;
+}
+
+static const struct platform_suspend_ops qoriq_suspend_ops = {
+ .valid = qoriq_suspend_valid,
+ .enter = qoriq_suspend_enter,
+};
+
+static int __init qoriq_suspend_init(void)
+{
+ suspend_set_ops(&qoriq_suspend_ops);
+
+ return 0;
+}
+arch_initcall(qoriq_suspend_init);
diff --git a/arch/powerpc/platforms/86xx/Kconfig
b/arch/powerpc/platforms/86xx/Kconfig
index 1afd1e4..09638e0 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -5,6 +5,7 @@ menuconfig PPC_86xx
select FSL_SOC
select ALTIVEC
select ARCH_WANT_OPTIONAL_GPIOLIB
+ select FSL_PMC if SUSPEND
help
The Freescale E600 SoCs have 74xx cores.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] NFC: nxp-nci: Add support for NXP-NCI NFC controllers
Hi Clément, On Mon, Mar 09, 2015 at 11:12:02AM +0100, clement.perroch...@effinnov.com wrote: > From: Clément Perrochaud > > This patch brings support for the NXP-NCI NFC controllers family. > > It has been successfully tested on the following SoC boards: > - BeagleBone > - BeagleBone Black > - Raspberry Pi B > - Raspberry Pi B+ > > The submission is broken into three patches: > - The first one adds firmware download support to NCI ; > - The second one adds the NXP-NCI driver's core ; > - The third one adds I2C support to the driver. All 3 patches applied to nfc-next, many thanks. Cheers, Samuel. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
