* [PATCH v4 1/2] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
From: Yong Deng @ 2017-12-22 9:41 UTC (permalink / raw)
To: linux-arm-kernel
Add binding documentation for Allwinner V3s CSI.
Signed-off-by: Yong Deng <yong.deng@magewell.com>
---
.../devicetree/bindings/media/sun6i-csi.txt | 51 ++++++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt b/Documentation/devicetree/bindings/media/sun6i-csi.txt
new file mode 100644
index 0000000..b5bfe3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -0,0 +1,51 @@
+Allwinner V3s Camera Sensor Interface
+------------------------------
+
+Required properties:
+ - compatible: value must be "allwinner,sun8i-v3s-csi"
+ - reg: base address and size of the memory-mapped region.
+ - interrupts: interrupt associated to this IP
+ - clocks: phandles to the clocks feeding the CSI
+ * bus: the CSI interface clock
+ * mod: the CSI module clock
+ * ram: the CSI DRAM clock
+ - clock-names: the clock names mentioned above
+ - resets: phandles to the reset line driving the CSI
+
+- ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ Currently, the driver only support the parallel interface. So, a single port
+ node with one endpoint and parallel bus is supported.
+
+Example:
+
+ csi1: csi at 1cb4000 {
+ compatible = "allwinner,sun8i-v3s-csi";
+ reg = <0x01cb4000 0x1000>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CSI>,
+ <&ccu CLK_CSI1_SCLK>,
+ <&ccu CLK_DRAM_CSI>;
+ clock-names = "bus", "mod", "ram";
+ resets = <&ccu RST_BUS_CSI>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Parallel bus endpoint */
+ csi1_ep: endpoint {
+ remote-endpoint = <&adv7611_ep>;
+ bus-width = <16>;
+ data-shift = <0>;
+
+ /* If hsync-active/vsync-active are missing,
+ embedded BT.656 sync is used */
+ hsync-active = <0>; /* Active low */
+ vsync-active = <0>; /* Active low */
+ data-active = <1>; /* Active high */
+ pclk-sample = <1>; /* Rising */
+ };
+ };
+ };
+
--
1.8.3.1
^ permalink raw reply related
* [PATCH] ARM: OMAP2+: hwmod_core: enable optional clocks before main clock
From: Keerthy @ 2017-12-22 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513934763-23966-1-git-send-email-t-kristo@ti.com>
On Friday 22 December 2017 02:56 PM, Tero Kristo wrote:
> The optional clocks must be enabled before the main clock after the
> transition to clkctrl controlled clocks is done. Otherwise the module
> we attempt to enable might be stuck in transition.
>
> Reported-by: Keerthy <j-keerthy@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
Tested the patch on both DRA7-EVM and DRA72-EVM. I no longer see the issue:
Tested-by: Keerthy <j-keerthy@ti.com>
> ---
> Hi Tony,
>
> This patch fixes a regression seen in linux-next, where certain peripherals
> fail to enable after the clkctrl changes are in. The case seen has been
> with mcasp3, where it fails to transition to enabled during the audio
> driver probe. Not sure where you want to pick this up, maybe as early
> rc fixes if its too late to push this to linux-next?
>
> arch/arm/mach-omap2/omap_hwmod.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 7324048..340d05c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -976,6 +976,9 @@ static int _enable_clocks(struct omap_hwmod *oh)
>
> pr_debug("omap_hwmod: %s: enabling clocks\n", oh->name);
>
> + if (oh->flags & HWMOD_OPT_CLKS_NEEDED)
> + _enable_optional_clocks(oh);
> +
> if (oh->_clk)
> clk_enable(oh->_clk);
>
> @@ -984,9 +987,6 @@ static int _enable_clocks(struct omap_hwmod *oh)
> clk_enable(os->_clk);
> }
>
> - if (oh->flags & HWMOD_OPT_CLKS_NEEDED)
> - _enable_optional_clocks(oh);
> -
> /* The opt clocks are controlled by the device driver. */
>
> return 0;
>
^ permalink raw reply
* [PATCH] arm64: dts: hisilicon: Add hi3660 cpu capacity-dmips-mhz information
From: Wei Xu @ 2017-12-22 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513174866-6678-1-git-send-email-valentin.schneider@arm.com>
Hi Valentin,
On 2017/12/13 14:21, Valentin Schneider wrote:
> The following dt entries are added:
> cpus [0-3] (Cortex A53):
> - capacity-dmips-mhz = <592>;
>
> cpus [4-7] (Cortex A73):
> - capacity-dmips-mhz = <1024>;
>
> Those values were obtained by running dhrystone 2.1 on a
> HiKey960 with the following procedure:
> - Offline all CPUs but CPU0 (A53)
> - Set CPU0 frequency to maximum
> - Run Dhrystone 2.1 for 20 seconds
>
> - Offline all CPUs but CPU4 (A73)
> - set CPU4 frequency to maximum
> - Run Dhrystone 2.1 for 20 seconds
>
> The results are as follows:
> A53: 129633887 loops
> A73: 287034147 loops
>
> By scaling those values so that the A73s use 1024, we end up with 462
> for the A53s. However, they have different maximum frequencies:
> 1.844GHz for A53s and 2.362GHz for A73s. Thus, we can scale the A53
> value to truly represent dmips per MHz, and we end up with 592.
>
> The impact of this change can be verified on HiKey960:
>
> $ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
> 1844000
> 1844000
> 1844000
> 1844000
> 2362000
> 2362000
> 2362000
> 2362000
>
> $ cat /sys/devices/system/cpu/cpu*/cpu_capacity
> 462
> 462
> 462
> 462
> 1024
> 1024
> 1024
> 1024
>
> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
> ---
Applied into hisilicon dt tree.
Thanks!
Best Regards,
Wei
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index ab0b95b..04a8d28 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -61,6 +61,7 @@
> enable-method = "psci";
> next-level-cache = <&A53_L2>;
> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_0>;
> + capacity-dmips-mhz = <592>;
> };
>
> cpu1: cpu at 1 {
> @@ -70,6 +71,7 @@
> enable-method = "psci";
> next-level-cache = <&A53_L2>;
> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_0>;
> + capacity-dmips-mhz = <592>;
> };
>
> cpu2: cpu at 2 {
> @@ -79,6 +81,7 @@
> enable-method = "psci";
> next-level-cache = <&A53_L2>;
> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_0>;
> + capacity-dmips-mhz = <592>;
> };
>
> cpu3: cpu at 3 {
> @@ -88,6 +91,7 @@
> enable-method = "psci";
> next-level-cache = <&A53_L2>;
> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_0>;
> + capacity-dmips-mhz = <592>;
> };
>
> cpu4: cpu at 100 {
> @@ -101,6 +105,7 @@
> &CPU_SLEEP
> &CLUSTER_SLEEP_1
> >;
> + capacity-dmips-mhz = <1024>;
> };
>
> cpu5: cpu at 101 {
> @@ -114,6 +119,7 @@
> &CPU_SLEEP
> &CLUSTER_SLEEP_1
> >;
> + capacity-dmips-mhz = <1024>;
> };
>
> cpu6: cpu at 102 {
> @@ -127,6 +133,7 @@
> &CPU_SLEEP
> &CLUSTER_SLEEP_1
> >;
> + capacity-dmips-mhz = <1024>;
> };
>
> cpu7: cpu at 103 {
> @@ -140,6 +147,7 @@
> &CPU_SLEEP
> &CLUSTER_SLEEP_1
> >;
> + capacity-dmips-mhz = <1024>;
> };
>
> idle-states {
> --
> 2.7.4
>
>
> .
>
^ permalink raw reply
* [PATCH v2] arm64: dts: Hi3660: Fix up psci state id
From: Wei Xu @ 2017-12-22 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513069954-22827-1-git-send-email-leo.yan@linaro.org>
Hi Leo,
On 2017/12/12 9:12, Leo Yan wrote:
> Thanks a lot for Vincent Guittot careful work to find bug for 'CPU_NAP'
> idle state. From ftrace log we can observe CA73 CPUs can be easily
> waken up from 'CPU_NAP' state but the 'waken up' CPUs doesn't handle
> anything and sleep again; so there have tons of trace events for CA73
> CPUs entering and exiting idle state.
>
> On Hi3660 CA73 has retention state 'CPU_NAP' for CPU idle, this state we
> set its psci parameter as '0x0000001' and from this parameter it can
> calculate state id is 1. Unfortunately ARM trusted firmware (ARM-TF)
> takes 1 as a invalid value for state id, so the CPU cannot enter idle
> state and directly bail out to kernel.
>
> We want to create good practice for psci parameters platform definition,
> so review the psci specification. The spec "ARM Power State Coordination
> Interface - Platform Design Document (ARM DEN 0022D)" recommends state
> ID in chapter "6.5 Recommended StateID Encoding". The recommended power
> state IDs can be presented by below listed values; and it divides into
> three fields, every field can use 4 bits to present power states
> corresponding to core level, cluster level and system level:
> 0: Run
> 1: Standby
> 2: Retention
> 3: Powerdown
>
> This commit changes psci parameter to compliance with the suggested
> state ID in the doc. Except we change 'CPU_NAP' state psci parameter
> to '0x0000002', this commit also changes 'CPU_SLEEP' and 'CLUSTER_SLEEP'
> state parameters to '0x0010003' and '0x1010033' respectively.
>
> Credits to Daniel, Sudeep and Soby for suggestion and consolidation.
>
> Cc: Vincent Guittot <vincent.guittot@linaro.org>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Soby Mathew <Soby.Mathew@arm.com>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
Applied into hisilicon dt tree.
Thanks!
Best Regards,
Wei
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index ab0b95b..99d5a46 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -147,7 +147,7 @@
>
> CPU_NAP: cpu-nap {
> compatible = "arm,idle-state";
> - arm,psci-suspend-param = <0x0000001>;
> + arm,psci-suspend-param = <0x0000002>;
> entry-latency-us = <7>;
> exit-latency-us = <2>;
> min-residency-us = <15>;
> @@ -156,7 +156,7 @@
> CPU_SLEEP: cpu-sleep {
> compatible = "arm,idle-state";
> local-timer-stop;
> - arm,psci-suspend-param = <0x0010000>;
> + arm,psci-suspend-param = <0x0010003>;
> entry-latency-us = <40>;
> exit-latency-us = <70>;
> min-residency-us = <3000>;
> @@ -165,7 +165,7 @@
> CLUSTER_SLEEP_0: cluster-sleep-0 {
> compatible = "arm,idle-state";
> local-timer-stop;
> - arm,psci-suspend-param = <0x1010000>;
> + arm,psci-suspend-param = <0x1010033>;
> entry-latency-us = <500>;
> exit-latency-us = <5000>;
> min-residency-us = <20000>;
> @@ -174,7 +174,7 @@
> CLUSTER_SLEEP_1: cluster-sleep-1 {
> compatible = "arm,idle-state";
> local-timer-stop;
> - arm,psci-suspend-param = <0x1010000>;
> + arm,psci-suspend-param = <0x1010033>;
> entry-latency-us = <1000>;
> exit-latency-us = <5000>;
> min-residency-us = <20000>;
>
^ permalink raw reply
* [PATCH v2] arm64: dts: hi3660: improve pmu description
From: Wei Xu @ 2017-12-22 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1510226303-20950-1-git-send-email-xuyiping@hisilicon.com>
Hi Xu YiPing,
On 2017/11/9 11:18, Xu YiPing wrote:
> cortex-a73 pmu driver is supported now. hi3660 is 4*a73 + 4*a53, so it
> should use "cortex-a73-pmu" and "cortex-a53-pmu" instead of "armpmu-v3",
> then we can use the a73 and a53 events in perf tool directly.
>
> Signed-off-by: Xu YiPing <xuyiping@hisilicon.com>
Applied into hisilicon dt tree.
Thanks!
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 22 +++++++++++++---------
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index 13ae69f..f4882d3 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -203,21 +203,25 @@
> IRQ_TYPE_LEVEL_HIGH)>;
> };
>
> - pmu {
> - compatible = "arm,armv8-pmuv3";
> + a53-pmu {
> + compatible = "arm,cortex-a53-pmu";
> interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> + <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-affinity = <&cpu0>,
> <&cpu1>,
> <&cpu2>,
> - <&cpu3>,
> - <&cpu4>,
> + <&cpu3>;
> + };
> +
> + a73-pmu {
> + compatible = "arm,cortex-a73-pmu";
> + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&cpu4>,
> <&cpu5>,
> <&cpu6>,
> <&cpu7>;
>
^ permalink raw reply
* [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests
From: Corentin Labbe @ 2017-12-22 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222090603.GB32542@gondor.apana.org.au>
On Fri, Dec 22, 2017 at 08:06:03PM +1100, Herbert Xu wrote:
> On Fri, Dec 22, 2017 at 09:41:48AM +0100, Corentin Labbe wrote:
> >
> > It's you that was suggesting using crypto_async_request:
> > https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1474434.html
> > "The only wart with this scheme is that the drivers end up seeing
> > struct crypto_async_request and will need to convert that to the
> > respective request types but I couldn't really find a better way."
> >
> > So I wait for any suggestion.
>
> The core engine code obviously will use the base type but it should
> not be exposed to the driver authors. IOW all exposed API should
> take the final types such as aead_request before casting it.
>
For driver->engine calls(crypto_finalize_request/crypto_transfer_request_to_engine) it's easy.
But I do not see how to do it for crypto_engine_op appart re-introducing the big if/then/else that
you didnt want.
Or do you agree to set the request parameter for crypto_engine_op(prepare_request/unprepare_request/do_one_request) to void * ?
Regards
^ permalink raw reply
* [PATCH] arm64: dts: hi3798cv200: add SD card support
From: Wei Xu @ 2017-12-22 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1508036687-13926-1-git-send-email-shawnguo@kernel.org>
Hi Shawn,
On 2017/10/15 4:04, Shawn Guo wrote:
> From: Shawn Guo <shawn.guo@linaro.org>
>
> It adds device mmc at 9820000 which is used as SD card on poplar board.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Applied into hisilicon dt tree.
Thanks!
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts | 6 ++++++
> arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 12 ++++++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
> index b9142871d6fe..e6fd9f296497 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
> @@ -146,6 +146,12 @@
> status = "okay";
> };
>
> +&sd0 {
> + bus-width = <4>;
> + cap-sd-highspeed;
> + status = "okay";
> +};
> +
> &spi0 {
> status = "okay";
> label = "LS-SPI0";
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
> index 75865f8a862a..962bd79139e4 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
> @@ -192,6 +192,18 @@
> status = "disabled";
> };
>
> + sd0: mmc at 9820000 {
> + compatible = "snps,dw-mshc";
> + reg = <0x9820000 0x10000>;
> + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&crg HISTB_SDIO0_CIU_CLK>,
> + <&crg HISTB_SDIO0_BIU_CLK>;
> + clock-names = "ciu", "biu";
> + resets = <&crg 0x9c 4>;
> + reset-names = "reset";
> + status = "disabled";
> + };
> +
> emmc: mmc at 9830000 {
> compatible = "snps,dw-mshc";
> reg = <0x9830000 0x10000>;
>
^ permalink raw reply
* [PATCH v6 11/11] thermal: armada: Give meaningful names to the thermal zones
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222093226.23456-1-miquel.raynal@free-electrons.com>
After registration to the thermal core, sysfs will make one entry
per instance of the driver in /sys/class/thermal_zoneX and
/sys/class/hwmon/hwmonX, X being the index of the instance, all of them
having the type/name "armada_thermal".
Until now there was only one thermal zone per SoC but SoCs like Armada
A7K and Armada A8K have respectively two and three thermal zones (one
per AP and one per CP) and this number is subject to grow in the future.
Use dev_name() instead of the "armada_thermal" string to get a
meaningful name and be able to identify the thermal zones from
userspace.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index ea958e651312..454137f78eb3 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -406,8 +406,8 @@ static int armada_thermal_probe(struct platform_device *pdev)
priv->data->init_sensor(pdev, priv);
- thermal = thermal_zone_device_register("armada_thermal", 0, 0,
- priv, &ops, NULL, 0, 0);
+ thermal = thermal_zone_device_register(dev_name(&pdev->dev), 0, 0, priv,
+ &ops, NULL, 0, 0);
if (IS_ERR(thermal)) {
dev_err(&pdev->dev,
"Failed to register thermal zone device\n");
--
2.11.0
^ permalink raw reply related
* [PATCH v6 10/11] thermal: armada: Wait sensors validity before exiting the init callback
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222093226.23456-1-miquel.raynal@free-electrons.com>
The thermal core will check for sensors validity right after the
initialization callback has returned. As the initialization routine make
a reset, the sensors are not ready immediately and the core spawns an
error in the dmesg. Avoid this annoying situation by polling on the
validity bit before exiting from these routines. This also avoid the use
of blind sleeps.
Suggested-by: David Sniatkiwicz <davidsn@marvell.com>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index a3feaef7db20..ea958e651312 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -23,6 +23,7 @@
#include <linux/platform_device.h>
#include <linux/of_device.h>
#include <linux/thermal.h>
+#include <linux/iopoll.h>
/* Thermal Manager Control and Status Register */
#define PMU_TDC0_SW_RST_MASK (0x1 << 1)
@@ -59,6 +60,9 @@
#define CONTROL1_EXT_TSEN_SW_RESET BIT(7)
#define CONTROL1_EXT_TSEN_HW_RESETn BIT(8)
+#define STATUS_POLL_PERIOD_US 1000
+#define STATUS_POLL_TIMEOUT_US 100000
+
struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
@@ -155,6 +159,16 @@ static void armada375_init_sensor(struct platform_device *pdev,
msleep(50);
}
+static void armada_wait_sensor_validity(struct armada_thermal_priv *priv)
+{
+ u32 reg;
+
+ readl_relaxed_poll_timeout(priv->status, reg,
+ reg & priv->data->is_valid_bit,
+ STATUS_POLL_PERIOD_US,
+ STATUS_POLL_TIMEOUT_US);
+}
+
static void armada380_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
@@ -164,7 +178,6 @@ static void armada380_init_sensor(struct platform_device *pdev,
reg |= CONTROL1_EXT_TSEN_HW_RESETn;
reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
writel(reg, priv->control1);
- msleep(10);
/* Set Tsen Tc Trim to correct default value (errata #132698) */
if (priv->control0) {
@@ -172,8 +185,10 @@ static void armada380_init_sensor(struct platform_device *pdev,
reg &= ~CONTROL0_TSEN_TC_TRIM_MASK;
reg |= CONTROL0_TSEN_TC_TRIM_VAL;
writel(reg, priv->control0);
- msleep(10);
}
+
+ /* Wait the sensors to be valid or the core will warn the user */
+ armada_wait_sensor_validity(priv);
}
static void armada_ap806_init_sensor(struct platform_device *pdev,
@@ -185,7 +200,9 @@ static void armada_ap806_init_sensor(struct platform_device *pdev,
reg &= ~CONTROL0_TSEN_RESET;
reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
writel(reg, priv->control0);
- msleep(10);
+
+ /* Wait the sensors to be valid or the core will warn the user */
+ armada_wait_sensor_validity(priv);
}
static bool armada_is_valid(struct armada_thermal_priv *priv)
--
2.11.0
^ permalink raw reply related
* [PATCH v6 09/11] thermal: armada: Change sensors trim default value
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222093226.23456-1-miquel.raynal@free-electrons.com>
Errata #132698 highlights an error in the default value of Tc trim.
Set this parameter to b'011.
Suggested-by: David Sniatkiwicz <davidsn@marvell.com>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 537f6fdc9059..a3feaef7db20 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -46,6 +46,10 @@
#define CONTROL0_OFFSET 0x0
#define CONTROL1_OFFSET 0x4
+/* Errata fields */
+#define CONTROL0_TSEN_TC_TRIM_MASK 0x7
+#define CONTROL0_TSEN_TC_TRIM_VAL 0x3
+
/* TSEN refers to the temperature sensors within the AP */
#define CONTROL0_TSEN_START BIT(0)
#define CONTROL0_TSEN_RESET BIT(1)
@@ -161,6 +165,15 @@ static void armada380_init_sensor(struct platform_device *pdev,
reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
writel(reg, priv->control1);
msleep(10);
+
+ /* Set Tsen Tc Trim to correct default value (errata #132698) */
+ if (priv->control0) {
+ reg = readl_relaxed(priv->control0);
+ reg &= ~CONTROL0_TSEN_TC_TRIM_MASK;
+ reg |= CONTROL0_TSEN_TC_TRIM_VAL;
+ writel(reg, priv->control0);
+ msleep(10);
+ }
}
static void armada_ap806_init_sensor(struct platform_device *pdev,
--
2.11.0
^ permalink raw reply related
* [PATCH v6 08/11] thermal: armada: Update Kconfig and module description
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222093226.23456-1-miquel.raynal@free-electrons.com>
Update Armada thermal driver Kconfig entry as well as the driver's
MODULE_DESCRIPTION content, now that 64-bit SoCs are also supported,
eg. Armada 7K and Armada 8K.
Use the generic term "Marvell EBU Armada SoCs" instead of listing all
the supported SoCs everywhere (excepted in the Kconfig description,
where it is useful to have a list).
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/Kconfig | 4 ++--
drivers/thermal/armada_thermal.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 315ae2926e20..b6adc54b96f1 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -301,13 +301,13 @@ config DB8500_THERMAL
thermal zone if trip points reached.
config ARMADA_THERMAL
- tristate "Armada 370/XP thermal management"
+ tristate "Marvell EBU Armada SoCs thermal management"
depends on ARCH_MVEBU || COMPILE_TEST
depends on HAS_IOMEM
depends on OF
help
Enable this option if you want to have support for thermal management
- controller present in Armada 370 and Armada XP SoC.
+ controller present in Marvell EBU Armada SoCs (370,375,XP,38x,7K,8K).
config DA9062_THERMAL
tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 93f7c0eb5141..537f6fdc9059 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -1,5 +1,5 @@
/*
- * Marvell Armada 370/XP thermal sensor driver
+ * Marvell EBU Armada SoCs thermal sensor driver
*
* Copyright (C) 2013 Marvell
*
@@ -411,5 +411,5 @@ static struct platform_driver armada_thermal_driver = {
module_platform_driver(armada_thermal_driver);
MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia@free-electrons.com>");
-MODULE_DESCRIPTION("Armada 370/XP thermal driver");
+MODULE_DESCRIPTION("Marvell EBU Armada SoCs thermal driver");
MODULE_LICENSE("GPL v2");
--
2.11.0
^ permalink raw reply related
* [PATCH v6 07/11] thermal: armada: Add support for Armada CP110
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222093226.23456-1-miquel.raynal@free-electrons.com>
From: Baruch Siach <baruch@tkos.co.il>
The CP110 component is integrated in the Armada 8k and 7k lines of
processors.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[<miquel.raynal@free-electrons.com>: renamed the register pointers as
well as some definitions related to the new register names and
simplified the init sequence for Armada 380]
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 33 ++++++++++++++++++++++++++-------
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 28ff2d0412ac..93f7c0eb5141 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -37,7 +37,6 @@
#define A375_UNIT_CONTROL_MASK 0x7
#define A375_READOUT_INVERT BIT(15)
#define A375_HW_RESETn BIT(8)
-#define A380_HW_RESET BIT(8)
/* Legacy bindings */
#define LEGACY_CONTROL_MEM_LEN 0x4
@@ -52,6 +51,10 @@
#define CONTROL0_TSEN_RESET BIT(1)
#define CONTROL0_TSEN_ENABLE BIT(2)
+/* EXT_TSEN refers to the external temperature sensors, out of the AP */
+#define CONTROL1_EXT_TSEN_SW_RESET BIT(7)
+#define CONTROL1_EXT_TSEN_HW_RESETn BIT(8)
+
struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
@@ -153,12 +156,11 @@ static void armada380_init_sensor(struct platform_device *pdev,
{
u32 reg = readl_relaxed(priv->control1);
- /* Reset hardware once */
- if (!(reg & A380_HW_RESET)) {
- reg |= A380_HW_RESET;
- writel(reg, priv->control1);
- msleep(10);
- }
+ /* Disable the HW/SW reset */
+ reg |= CONTROL1_EXT_TSEN_HW_RESETn;
+ reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
+ writel(reg, priv->control1);
+ msleep(10);
}
static void armada_ap806_init_sensor(struct platform_device *pdev,
@@ -281,6 +283,19 @@ static const struct armada_thermal_data armada_ap806_data = {
.needs_control0 = true,
};
+static const struct armada_thermal_data armada_cp110_data = {
+ .is_valid = armada_is_valid,
+ .init_sensor = armada380_init_sensor,
+ .is_valid_bit = BIT(10),
+ .temp_shift = 0,
+ .temp_mask = 0x3ff,
+ .coef_b = 1172499100ULL,
+ .coef_m = 2000096ULL,
+ .coef_div = 4201,
+ .inverted = true,
+ .needs_control0 = true,
+};
+
static const struct of_device_id armada_thermal_id_table[] = {
{
.compatible = "marvell,armadaxp-thermal",
@@ -303,6 +318,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
.data = &armada_ap806_data,
},
{
+ .compatible = "marvell,armada-cp110-thermal",
+ .data = &armada_cp110_data,
+ },
+ {
/* sentinel */
},
};
--
2.11.0
^ permalink raw reply related
* [PATCH v6 06/11] thermal: armada: Add support for Armada AP806
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222093226.23456-1-miquel.raynal@free-electrons.com>
From: Baruch Siach <baruch@tkos.co.il>
The AP806 component is integrated in the Armada 8K and 7K lines of
processors.
The thermal sensor sample field on the status register is a signed
value. Extend armada_get_temp() and the driver structure to handle
signed values.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[<miquel.raynal@free-electrons.com>: Changes when applying over the
previous patches, including the register names changes, also switched
the coefficients values to s64 instead of unsigned long to deal with
negative values and used do_div instead of the traditionnal '/']
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 78 +++++++++++++++++++++++++++++++---------
1 file changed, 62 insertions(+), 16 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index ceebabf45c53..28ff2d0412ac 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -47,6 +47,11 @@
#define CONTROL0_OFFSET 0x0
#define CONTROL1_OFFSET 0x4
+/* TSEN refers to the temperature sensors within the AP */
+#define CONTROL0_TSEN_START BIT(0)
+#define CONTROL0_TSEN_RESET BIT(1)
+#define CONTROL0_TSEN_ENABLE BIT(2)
+
struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
@@ -66,10 +71,11 @@ struct armada_thermal_data {
bool (*is_valid)(struct armada_thermal_priv *);
/* Formula coeficients: temp = (b - m * reg) / div */
- unsigned long coef_b;
- unsigned long coef_m;
- unsigned long coef_div;
+ s64 coef_b;
+ s64 coef_m;
+ u32 coef_div;
bool inverted;
+ bool signed_sample;
/* Register shift and mask to access the sensor temperature */
unsigned int temp_shift;
@@ -155,6 +161,18 @@ static void armada380_init_sensor(struct platform_device *pdev,
}
}
+static void armada_ap806_init_sensor(struct platform_device *pdev,
+ struct armada_thermal_priv *priv)
+{
+ u32 reg;
+
+ reg = readl_relaxed(priv->control0);
+ reg &= ~CONTROL0_TSEN_RESET;
+ reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
+ writel(reg, priv->control0);
+ msleep(10);
+}
+
static bool armada_is_valid(struct armada_thermal_priv *priv)
{
u32 reg = readl_relaxed(priv->status);
@@ -163,11 +181,12 @@ static bool armada_is_valid(struct armada_thermal_priv *priv)
}
static int armada_get_temp(struct thermal_zone_device *thermal,
- int *temp)
+ int *temperature)
{
struct armada_thermal_priv *priv = thermal->devdata;
- unsigned long reg;
- unsigned long m, b, div;
+ u32 reg, div;
+ s64 sample, b, m;
+ u64 tmp;
/* Valid check */
if (priv->data->is_valid && !priv->data->is_valid(priv)) {
@@ -178,6 +197,11 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
reg = readl_relaxed(priv->status);
reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
+ if (priv->data->signed_sample)
+ /* The most significant bit is the sign bit */
+ sample = sign_extend32(reg, fls(priv->data->temp_mask) - 1);
+ else
+ sample = reg;
/* Get formula coeficients */
b = priv->data->coef_b;
@@ -185,9 +209,13 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
div = priv->data->coef_div;
if (priv->data->inverted)
- *temp = ((m * reg) - b) / div;
+ tmp = (m * sample) - b;
else
- *temp = (b - (m * reg)) / div;
+ tmp = b - (m * sample);
+
+ do_div(tmp, div);
+ *temperature = (int)tmp;
+
return 0;
}
@@ -199,8 +227,8 @@ static const struct armada_thermal_data armadaxp_data = {
.init_sensor = armadaxp_init_sensor,
.temp_shift = 10,
.temp_mask = 0x1ff,
- .coef_b = 3153000000UL,
- .coef_m = 10000000UL,
+ .coef_b = 3153000000ULL,
+ .coef_m = 10000000ULL,
.coef_div = 13825,
};
@@ -210,8 +238,8 @@ static const struct armada_thermal_data armada370_data = {
.is_valid_bit = BIT(9),
.temp_shift = 10,
.temp_mask = 0x1ff,
- .coef_b = 3153000000UL,
- .coef_m = 10000000UL,
+ .coef_b = 3153000000ULL,
+ .coef_m = 10000000ULL,
.coef_div = 13825,
};
@@ -221,8 +249,8 @@ static const struct armada_thermal_data armada375_data = {
.is_valid_bit = BIT(10),
.temp_shift = 0,
.temp_mask = 0x1ff,
- .coef_b = 3171900000UL,
- .coef_m = 10000000UL,
+ .coef_b = 3171900000ULL,
+ .coef_m = 10000000ULL,
.coef_div = 13616,
.needs_control0 = true,
};
@@ -233,12 +261,26 @@ static const struct armada_thermal_data armada380_data = {
.is_valid_bit = BIT(10),
.temp_shift = 0,
.temp_mask = 0x3ff,
- .coef_b = 1172499100UL,
- .coef_m = 2000096UL,
+ .coef_b = 1172499100ULL,
+ .coef_m = 2000096ULL,
.coef_div = 4201,
.inverted = true,
};
+static const struct armada_thermal_data armada_ap806_data = {
+ .is_valid = armada_is_valid,
+ .init_sensor = armada_ap806_init_sensor,
+ .is_valid_bit = BIT(16),
+ .temp_shift = 0,
+ .temp_mask = 0x3ff,
+ .coef_b = -150000LL,
+ .coef_m = 423ULL,
+ .coef_div = 1,
+ .inverted = true,
+ .signed_sample = true,
+ .needs_control0 = true,
+};
+
static const struct of_device_id armada_thermal_id_table[] = {
{
.compatible = "marvell,armadaxp-thermal",
@@ -257,6 +299,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
.data = &armada380_data,
},
{
+ .compatible = "marvell,armada-ap806-thermal",
+ .data = &armada_ap806_data,
+ },
+ {
/* sentinel */
},
};
--
2.11.0
^ permalink raw reply related
* [PATCH v6 05/11] thermal: armada: Use real status register name
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222093226.23456-1-miquel.raynal@free-electrons.com>
Three 32-bit registers are used to drive the thermal IP: control0,
control1 and status. The two control registers share the same name both
in the documentation and in the code, while the latter is referred as
"sensor" in the code. Rename this pointer to be called "status" in order
to be aligned with the documentation.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index d58376eba6d9..ceebabf45c53 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -51,7 +51,7 @@ struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
struct armada_thermal_priv {
- void __iomem *sensor;
+ void __iomem *status;
void __iomem *control0;
void __iomem *control1;
struct armada_thermal_data *data;
@@ -99,9 +99,9 @@ static void armadaxp_init_sensor(struct platform_device *pdev,
writel(reg, priv->control1);
/* Enable the sensor */
- reg = readl_relaxed(priv->sensor);
+ reg = readl_relaxed(priv->status);
reg &= ~PMU_TM_DISABLE_MASK;
- writel(reg, priv->sensor);
+ writel(reg, priv->status);
}
static void armada370_init_sensor(struct platform_device *pdev,
@@ -157,7 +157,7 @@ static void armada380_init_sensor(struct platform_device *pdev,
static bool armada_is_valid(struct armada_thermal_priv *priv)
{
- u32 reg = readl_relaxed(priv->sensor);
+ u32 reg = readl_relaxed(priv->status);
return reg & priv->data->is_valid_bit;
}
@@ -176,7 +176,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
return -EIO;
}
- reg = readl_relaxed(priv->sensor);
+ reg = readl_relaxed(priv->status);
reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
/* Get formula coeficients */
@@ -279,9 +279,9 @@ static int armada_thermal_probe(struct platform_device *pdev)
return -ENOMEM;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->sensor = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(priv->sensor))
- return PTR_ERR(priv->sensor);
+ priv->status = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(priv->status))
+ return PTR_ERR(priv->status);
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
control = devm_ioremap_resource(&pdev->dev, res);
--
2.11.0
^ permalink raw reply related
* [PATCH v6 04/11] thermal: armada: Clarify control registers accesses
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222093226.23456-1-miquel.raynal@free-electrons.com>
Bindings were incomplete for a long time by only exposing one of the two
available control registers. To ease the migration to the full bindings
(already in use for the Armada 375 SoC), rename the pointers for
clarification. This way, it will only be needed to add another pointer
to access the other control register when the time comes.
This avoids dangerous situations where the offset 0 of the control
area can be either one register or the other depending on the bindings
used. After this change, device trees of other SoCs could be migrated to
the "full" bindings if they may benefit from features from the
unaccessible register, without any change in the driver.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 76 ++++++++++++++++++++++++++++------------
1 file changed, 54 insertions(+), 22 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index f350d7efd35a..d58376eba6d9 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -39,12 +39,21 @@
#define A375_HW_RESETn BIT(8)
#define A380_HW_RESET BIT(8)
+/* Legacy bindings */
+#define LEGACY_CONTROL_MEM_LEN 0x4
+
+/* Current bindings with the 2 control registers under the same memory area */
+#define LEGACY_CONTROL1_OFFSET 0x0
+#define CONTROL0_OFFSET 0x0
+#define CONTROL1_OFFSET 0x4
+
struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
struct armada_thermal_priv {
void __iomem *sensor;
- void __iomem *control;
+ void __iomem *control0;
+ void __iomem *control1;
struct armada_thermal_data *data;
};
@@ -66,27 +75,28 @@ struct armada_thermal_data {
unsigned int temp_shift;
unsigned int temp_mask;
u32 is_valid_bit;
+ bool needs_control0;
};
static void armadaxp_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
- unsigned long reg;
+ u32 reg;
- reg = readl_relaxed(priv->control);
+ reg = readl_relaxed(priv->control1);
reg |= PMU_TDC0_OTF_CAL_MASK;
- writel(reg, priv->control);
+ writel(reg, priv->control1);
/* Reference calibration value */
reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
- writel(reg, priv->control);
+ writel(reg, priv->control1);
/* Reset the sensor */
- reg = readl_relaxed(priv->control);
- writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
+ reg = readl_relaxed(priv->control1);
+ writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
- writel(reg, priv->control);
+ writel(reg, priv->control1);
/* Enable the sensor */
reg = readl_relaxed(priv->sensor);
@@ -97,19 +107,19 @@ static void armadaxp_init_sensor(struct platform_device *pdev,
static void armada370_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
- unsigned long reg;
+ u32 reg;
- reg = readl_relaxed(priv->control);
+ reg = readl_relaxed(priv->control1);
reg |= PMU_TDC0_OTF_CAL_MASK;
- writel(reg, priv->control);
+ writel(reg, priv->control1);
/* Reference calibration value */
reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
- writel(reg, priv->control);
+ writel(reg, priv->control1);
reg &= ~PMU_TDC0_START_CAL_MASK;
- writel(reg, priv->control);
+ writel(reg, priv->control1);
msleep(10);
}
@@ -117,30 +127,30 @@ static void armada370_init_sensor(struct platform_device *pdev,
static void armada375_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
- unsigned long reg;
+ u32 reg;
- reg = readl(priv->control + 4);
+ reg = readl(priv->control1);
reg &= ~(A375_UNIT_CONTROL_MASK << A375_UNIT_CONTROL_SHIFT);
reg &= ~A375_READOUT_INVERT;
reg &= ~A375_HW_RESETn;
- writel(reg, priv->control + 4);
+ writel(reg, priv->control1);
msleep(20);
reg |= A375_HW_RESETn;
- writel(reg, priv->control + 4);
+ writel(reg, priv->control1);
msleep(50);
}
static void armada380_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
- unsigned long reg = readl_relaxed(priv->control);
+ u32 reg = readl_relaxed(priv->control1);
/* Reset hardware once */
if (!(reg & A380_HW_RESET)) {
reg |= A380_HW_RESET;
- writel(reg, priv->control);
+ writel(reg, priv->control1);
msleep(10);
}
}
@@ -214,6 +224,7 @@ static const struct armada_thermal_data armada375_data = {
.coef_b = 3171900000UL,
.coef_m = 10000000UL,
.coef_div = 13616,
+ .needs_control0 = true,
};
static const struct armada_thermal_data armada380_data = {
@@ -253,6 +264,7 @@ MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
static int armada_thermal_probe(struct platform_device *pdev)
{
+ void __iomem *control = NULL;
struct thermal_zone_device *thermal;
const struct of_device_id *match;
struct armada_thermal_priv *priv;
@@ -272,11 +284,31 @@ static int armada_thermal_probe(struct platform_device *pdev)
return PTR_ERR(priv->sensor);
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- priv->control = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(priv->control))
- return PTR_ERR(priv->control);
+ control = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(control))
+ return PTR_ERR(control);
priv->data = (struct armada_thermal_data *)match->data;
+
+ /*
+ * Legacy DT bindings only described "control1" register (also referred
+ * as "control MSB" on old documentation). New bindings cover
+ * "control0/control LSB" and "control1/control MSB" registers within
+ * the same resource, which is then of size 8 instead of 4.
+ */
+ if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
+ /* ->control0 unavailable in this configuration */
+ if (priv->data->needs_control0) {
+ dev_err(&pdev->dev, "No access to control0 register\n");
+ return -EINVAL;
+ }
+
+ priv->control1 = control + LEGACY_CONTROL1_OFFSET;
+ } else {
+ priv->control0 = control + CONTROL0_OFFSET;
+ priv->control1 = control + CONTROL1_OFFSET;
+ }
+
priv->data->init_sensor(pdev, priv);
thermal = thermal_zone_device_register("armada_thermal", 0, 0,
--
2.11.0
^ permalink raw reply related
* [PATCH v4 0/2] Initial Allwinner V3s CSI Support
From: Yong Deng @ 2017-12-22 9:32 UTC (permalink / raw)
To: linux-arm-kernel
This patchset add initial support for Allwinner V3s CSI.
Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datasheet but by testing and guess.
This patchset implement a v4l2 framework driver and add a binding
documentation for it.
Currently, the driver only support the parallel interface. And has been
tested with a BT1120 signal which generating from FPGA. The following
fetures are not support with this patchset:
- ISP
- MIPI-CSI2
- Master clock for camera sensor
- Power regulator for the front end IC
Thanks for Ond?ej Jirman's help.
Changes in v4:
* Deal with the CSI 'INNER QUEUE'.
CSI will lookup the next dma buffer for next frame before the
the current frame done IRQ triggered. This is not documented
but reported by Ond?ej Jirman.
The BSP code has workaround for this too. It skip to mark the
first buffer as frame done for VB2 and pass the second buffer
to CSI in the first frame done ISR call. Then in second frame
done ISR call, it mark the first buffer as frame done for VB2
and pass the third buffer to CSI. And so on. The bad thing is
that the first buffer will be written twice and the first frame
is dropped even the queued buffer is sufficient.
So, I make some improvement here. Pass the next buffer to CSI
just follow starting the CSI. In this case, the first frame
will be stored in first buffer, second frame in second buffer.
This mothed is used to avoid dropping the first frame, it
would also drop frame when lacking of queued buffer.
* Fix: using a wrong mbus_code when getting the supported formats
* Change all fourcc to pixformat
* Change some function names
Changes in v3:
* Get rid of struct sun6i_csi_ops
* Move sun6i-csi to new directory drivers/media/platform/sunxi
* Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
* Use generic fwnode endpoints parser
* Only support a single subdev to make things simple
* Many complaintion fix
Changes in v2:
* Change sunxi-csi to sun6i-csi
* Rebase to media_tree master branch
Following is the 'v4l2-compliance -s -f' output, I have test this
with both interlaced and progressive signal:
# ./v4l2-compliance -s -f
v4l2-compliance SHA : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
Driver Info:
Driver name : sun6i-video
Card type : sun6i-csi
Bus info : platform:csi
Driver version: 4.15.0
Capabilities : 0x84200001
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04200001
Video Capture
Streaming
Extended Pix Format
Compliance test for device /dev/video0 (not using libv4l2):
Required ioctls:
test VIDIOC_QUERYCAP: OK
Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Test input 0:
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK
Test input 0:
Streaming ioctls:
test read/write: OK (Not Supported)
test MMAP: OK
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device
Stream using all formats:
test MMAP for Format HM12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format NV12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format NV21, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format YU12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format YV12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format NV16, Frame Size 1280x720:
Stride 2560, Field None: OK
test MMAP for Format NV61, Frame Size 1280x720:
Stride 2560, Field None: OK
test MMAP for Format 422P, Frame Size 1280x720:
Stride 2560, Field None: OK
Total: 54, Succeeded: 54, Failed: 0, Warnings: 0
Yong Deng (2):
dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
media: V3s: Add support for Allwinner CSI.
.../devicetree/bindings/media/sun6i-csi.txt | 51 ++
MAINTAINERS | 8 +
drivers/media/platform/Kconfig | 1 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/sunxi/sun6i-csi/Kconfig | 9 +
drivers/media/platform/sunxi/sun6i-csi/Makefile | 3 +
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 878 +++++++++++++++++++++
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 147 ++++
.../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 203 +++++
.../media/platform/sunxi/sun6i-csi/sun6i_video.c | 752 ++++++++++++++++++
.../media/platform/sunxi/sun6i-csi/sun6i_video.h | 60 ++
11 files changed, 2114 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
--
1.8.3.1
^ permalink raw reply
* [PATCH v6 03/11] thermal: armada: Simplify the check of the validity bit
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222093226.23456-1-miquel.raynal@free-electrons.com>
All Armada SoCs use one bit to declare if the sensor values are valid.
This bit moves across the versions of the IP.
The method until then was to do both a shift and compare with an useless
flag of "0x1". It is clearer and quicker to directly save the value that
must be ANDed instead of the bit position and do a single bitwise AND
operation.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 6c4af2622d4f..f350d7efd35a 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -24,8 +24,6 @@
#include <linux/of_device.h>
#include <linux/thermal.h>
-#define THERMAL_VALID_MASK 0x1
-
/* Thermal Manager Control and Status Register */
#define PMU_TDC0_SW_RST_MASK (0x1 << 1)
#define PMU_TM_DISABLE_OFFS 0
@@ -67,7 +65,7 @@ struct armada_thermal_data {
/* Register shift and mask to access the sensor temperature */
unsigned int temp_shift;
unsigned int temp_mask;
- unsigned int is_valid_shift;
+ u32 is_valid_bit;
};
static void armadaxp_init_sensor(struct platform_device *pdev,
@@ -149,9 +147,9 @@ static void armada380_init_sensor(struct platform_device *pdev,
static bool armada_is_valid(struct armada_thermal_priv *priv)
{
- unsigned long reg = readl_relaxed(priv->sensor);
+ u32 reg = readl_relaxed(priv->sensor);
- return (reg >> priv->data->is_valid_shift) & THERMAL_VALID_MASK;
+ return reg & priv->data->is_valid_bit;
}
static int armada_get_temp(struct thermal_zone_device *thermal,
@@ -199,7 +197,7 @@ static const struct armada_thermal_data armadaxp_data = {
static const struct armada_thermal_data armada370_data = {
.is_valid = armada_is_valid,
.init_sensor = armada370_init_sensor,
- .is_valid_shift = 9,
+ .is_valid_bit = BIT(9),
.temp_shift = 10,
.temp_mask = 0x1ff,
.coef_b = 3153000000UL,
@@ -210,7 +208,7 @@ static const struct armada_thermal_data armada370_data = {
static const struct armada_thermal_data armada375_data = {
.is_valid = armada_is_valid,
.init_sensor = armada375_init_sensor,
- .is_valid_shift = 10,
+ .is_valid_bit = BIT(10),
.temp_shift = 0,
.temp_mask = 0x1ff,
.coef_b = 3171900000UL,
@@ -221,7 +219,7 @@ static const struct armada_thermal_data armada375_data = {
static const struct armada_thermal_data armada380_data = {
.is_valid = armada_is_valid,
.init_sensor = armada380_init_sensor,
- .is_valid_shift = 10,
+ .is_valid_bit = BIT(10),
.temp_shift = 0,
.temp_mask = 0x3ff,
.coef_b = 1172499100UL,
--
2.11.0
^ permalink raw reply related
* [PATCH v6 02/11] thermal: armada: Use msleep for long delays
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222093226.23456-1-miquel.raynal@free-electrons.com>
From: Baruch Siach <baruch@tkos.co.il>
Use msleep for long (> 10ms) delays, instead of the busy waiting mdelay.
All delays are called from the probe routine, where scheduling is
allowed.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 706d74798cbe..6c4af2622d4f 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -113,7 +113,7 @@ static void armada370_init_sensor(struct platform_device *pdev,
reg &= ~PMU_TDC0_START_CAL_MASK;
writel(reg, priv->control);
- mdelay(10);
+ msleep(10);
}
static void armada375_init_sensor(struct platform_device *pdev,
@@ -127,11 +127,11 @@ static void armada375_init_sensor(struct platform_device *pdev,
reg &= ~A375_HW_RESETn;
writel(reg, priv->control + 4);
- mdelay(20);
+ msleep(20);
reg |= A375_HW_RESETn;
writel(reg, priv->control + 4);
- mdelay(50);
+ msleep(50);
}
static void armada380_init_sensor(struct platform_device *pdev,
@@ -143,7 +143,7 @@ static void armada380_init_sensor(struct platform_device *pdev,
if (!(reg & A380_HW_RESET)) {
reg |= A380_HW_RESET;
writel(reg, priv->control);
- mdelay(10);
+ msleep(10);
}
}
--
2.11.0
^ permalink raw reply related
* [PATCH v6 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222093226.23456-1-miquel.raynal@free-electrons.com>
From: Baruch Siach <baruch@tkos.co.il>
Add compatible strings for AP806 and CP110 that are part of the Armada
8k/7k line of SoCs.
Add a note on the differences in the size of the control area in
different bindings. This is an existing difference between the Armada
375 binding and the other boards already supported. The new AP806 and
CP110 bindings are similar to the existing Armada 375 in this regard.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[<miquel.raynal@free-electrons.com>: reword, additional details]
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
.../devicetree/bindings/thermal/armada-thermal.txt | 37 +++++++++++++++-------
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
index 24aacf8948c5..e0d013a2e66d 100644
--- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
@@ -2,22 +2,35 @@
Required properties:
-- compatible: Should be set to one of the following:
- marvell,armada370-thermal
- marvell,armada375-thermal
- marvell,armada380-thermal
- marvell,armadaxp-thermal
+- compatible: Should be set to one of the following:
+ * marvell,armada370-thermal
+ * marvell,armada375-thermal
+ * marvell,armada380-thermal
+ * marvell,armadaxp-thermal
+ * marvell,armada-ap806-thermal
+ * marvell,armada-cp110-thermal
-- reg: Device's register space.
- Two entries are expected, see the examples below.
- The first one is required for the sensor register;
- the second one is required for the control register
- to be used for sensor initialization (a.k.a. calibration).
+- reg: Device's register space.
+ Two entries are expected, see the examples below. The first one points
+ to the status register (4B). The second one points to the control
+ registers (8B).
+ Note: The compatibles marvell,armada370-thermal,
+ marvell,armada380-thermal, and marvell,armadaxp-thermal must point to
+ "control MSB/control 1", with size of 4 (deprecated binding), or point
+ to "control LSB/control 0" with size of 8 (current binding). All other
+ compatibles must point to "control LSB/control 0" with size of 8.
-Example:
+Examples:
+ /* Legacy bindings */
thermal at d0018300 {
compatible = "marvell,armada370-thermal";
- reg = <0xd0018300 0x4
+ reg = <0xd0018300 0x4
0xd0018304 0x4>;
};
+
+ ap_thermal: thermal at 6f8084 {
+ compatible = "marvell,armada-ap806-thermal";
+ reg = <0x6f808C 0x4>,
+ <0x6f8084 0x8>;
+ };
--
2.11.0
^ permalink raw reply related
* [PATCH v6 00/11] Armada thermal: improvements and A7K/A8K SoCs support
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This series takes over Baruch's series by integrating his patches about
supporting thermal on Armada 7K and 8K SoCs within a larger series with
several improvements on the armada_thermal.c driver.
For now, Armada 380 and CP110 compatibles share the same initialization
routine but this will probably change in the near future when adding
support for overheat interrupts.
DT bindings documentation is updated to match existing code.
Armada AP806 and CP110 DT are also updated with thermal nodes and have
already been accepted (thus absent in this series).
Thank you,
Miqu?l
Changes since v5:
- Added Grogory's Tested-by tags for 64-bit platforms in patches:
"thermal: armada: Add support for Armada AP806"
"thermal: armada: Add support for Armada CP110"
- Fixed a compilation issue with 32-bit toolchains introduced in patch:
"thermal: armada: Add support for Armada AP806"
Baruch Siach (4):
dt-bindings: thermal: Describe Armada AP806 and CP110
thermal: armada: Use msleep for long delays
thermal: armada: Add support for Armada AP806
thermal: armada: Add support for Armada CP110
Miquel Raynal (7):
thermal: armada: Simplify the check of the validity bit
thermal: armada: Clarify control registers accesses
thermal: armada: Use real status register name
thermal: armada: Update Kconfig and module description
thermal: armada: Change sensors trim default value
thermal: armada: Wait sensors validity before exiting the init
callback
thermal: armada: Give meaningful names to the thermal zones
.../devicetree/bindings/thermal/armada-thermal.txt | 37 ++-
drivers/thermal/Kconfig | 4 +-
drivers/thermal/armada_thermal.c | 257 +++++++++++++++------
3 files changed, 218 insertions(+), 80 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH] ARM: OMAP2+: hwmod_core: enable optional clocks before main clock
From: Tero Kristo @ 2017-12-22 9:26 UTC (permalink / raw)
To: linux-arm-kernel
The optional clocks must be enabled before the main clock after the
transition to clkctrl controlled clocks is done. Otherwise the module
we attempt to enable might be stuck in transition.
Reported-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
Hi Tony,
This patch fixes a regression seen in linux-next, where certain peripherals
fail to enable after the clkctrl changes are in. The case seen has been
with mcasp3, where it fails to transition to enabled during the audio
driver probe. Not sure where you want to pick this up, maybe as early
rc fixes if its too late to push this to linux-next?
arch/arm/mach-omap2/omap_hwmod.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7324048..340d05c 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -976,6 +976,9 @@ static int _enable_clocks(struct omap_hwmod *oh)
pr_debug("omap_hwmod: %s: enabling clocks\n", oh->name);
+ if (oh->flags & HWMOD_OPT_CLKS_NEEDED)
+ _enable_optional_clocks(oh);
+
if (oh->_clk)
clk_enable(oh->_clk);
@@ -984,9 +987,6 @@ static int _enable_clocks(struct omap_hwmod *oh)
clk_enable(os->_clk);
}
- if (oh->flags & HWMOD_OPT_CLKS_NEEDED)
- _enable_optional_clocks(oh);
-
/* The opt clocks are controlled by the device driver. */
return 0;
--
1.9.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related
* [PATCH] ARM: dts: exynos: fix RTC interrupt for exynos5410
From: Krzysztof Kozlowski @ 2017-12-22 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221213020.3080361-1-arnd@arndb.de>
On Thu, Dec 21, 2017 at 10:30 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> According to the comment added to exynos_dt_pmu_match[] in commit
> 8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to stacked domains"),
> the RTC is not able to wake up the system through the PMU on Exynos5410,
> unlike Exynos5420.
>
> However, when the RTC DT node got added, it was a straight copy of
> the Exynos5420 node, which now causes a warning from dtc.
>
> This removes the incorrect interrupt-parent, which should get the
> interrupt working and avoid the warning.
>
> Fixes: e1e146b1b062 ("ARM: dts: exynos: Add RTC and I2C to Exynos5410")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/boot/dts/exynos5410.dtsi | 1 -
> 1 file changed, 1 deletion(-)
In my pull request thread [1] you mentioned that PMU should not be
interrupt controller for Exynos5410. Yes, I think you are right.
Regardless whether Exynos5410 really supports Suspend to RAM or not,
now it is not configured as IRQ controller so the RTC's should go
straight to GIC. I think your fix is correct and I should drop my
patch.
I do not have Exynos5410 anymore (Odroid XU was left at Samsung
Poland) so I cannot test it. Maybe guys in Poland can test it? Marek?
Sylwester? Bartlomiej?
BTW,
It annoys me so much that it is so difficult to get Samsung boards. I
was writing to Samsung many times - to HQ, Open Source Group, LSI,
Artik and nothing. They do not have any boards... or they do not want
to share. This is how Samsung's support for Open Source really looks
like.
>From the three boards I have, two of them I bought myself by my own
money, one was donated to me by Markus Reichl (Odroid U3, thanks!).
When I was working in Samsung Poland they provided me with boards
(thanks guys!) but only for the time of work there and I am not
Samsung employee anymore.
So except this board from Markus, all infrastructure I have was built
by my own money. Eh, it is not that expensive, one board costs like
50-70 USD with shipment, but come on! Seriously, damn big company,
with damn big marketing budget and plenty of people and they cannot
provide their own boards to open-source... It really pisses me off
sometimes...
Back to the topic - thanks for the patch!
Best regards,
Krzysztof
[1] https://www.spinics.net/lists/arm-kernel/msg624966.html
>
> diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
> index 06713ec86f0d..d2174727df9a 100644
> --- a/arch/arm/boot/dts/exynos5410.dtsi
> +++ b/arch/arm/boot/dts/exynos5410.dtsi
> @@ -333,7 +333,6 @@
> &rtc {
> clocks = <&clock CLK_RTC>;
> clock-names = "rtc";
> - interrupt-parent = <&pmu_system_controller>;
> status = "disabled";
> };
>
> --
> 2.9.0
>
^ permalink raw reply
* [PATCH v5 06/11] thermal: armada: Add support for Armada AP806
From: Miquel RAYNAL @ 2017-12-22 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zi6dg0e1.fsf@free-electrons.com>
Hello Gregory,
On Wed, 20 Dec 2017 11:27:18 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> Hi Miquel,
>
> On mar., d?c. 19 2017, Miquel Raynal
> <miquel.raynal@free-electrons.com> wrote:
>
> > From: Baruch Siach <baruch@tkos.co.il>
> >
> > The AP806 component is integrated in the Armada 8K and 7K lines of
> > processors.
> >
> > The thermal sensor sample field on the status register is a signed
> > value. Extend armada_get_temp() and the driver structure to handle
> > signed values.
> >
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > [<miquel.raynal@free-electrons.com>: Changes when applying over the
> > previous patches, including the register names changes, also
> > switched the coefficients values to s64 instead of unsigned long to
> > deal with negative values and used do_div instead of the
> > traditionnal '/'] Signed-off-by: Miquel Raynal
> > <miquel.raynal@free-electrons.com> Reviewed-by: Gregory CLEMENT
> > <gregory.clement@free-electrons.com> ---
> > drivers/thermal/armada_thermal.c | 74
> > ++++++++++++++++++++++++++++++++-------- 1 file changed, 59
> > insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/thermal/armada_thermal.c
> > b/drivers/thermal/armada_thermal.c index ceebabf45c53..c7dcac39cbf9
> > 100644 --- a/drivers/thermal/armada_thermal.c
> > +++ b/drivers/thermal/armada_thermal.c
> > @@ -47,6 +47,11 @@
> > #define CONTROL0_OFFSET 0x0
> > #define CONTROL1_OFFSET 0x4
> >
> > +/* TSEN refers to the temperature sensors within the AP */
> > +#define CONTROL0_TSEN_START BIT(0)
> > +#define CONTROL0_TSEN_RESET BIT(1)
> > +#define CONTROL0_TSEN_ENABLE BIT(2)
> > +
> > struct armada_thermal_data;
> >
> > /* Marvell EBU Thermal Sensor Dev Structure */
> > @@ -66,10 +71,11 @@ struct armada_thermal_data {
> > bool (*is_valid)(struct armada_thermal_priv *);
> >
> > /* Formula coeficients: temp = (b - m * reg) / div */
> > - unsigned long coef_b;
> > - unsigned long coef_m;
> > - unsigned long coef_div;
> > + s64 coef_b;
> > + s64 coef_m;
> > + u32 coef_div;
> > bool inverted;
> > + bool signed_sample;
> >
> > /* Register shift and mask to access the sensor
> > temperature */ unsigned int temp_shift;
> > @@ -155,6 +161,18 @@ static void armada380_init_sensor(struct
> > platform_device *pdev, }
> > }
> >
> > +static void armada_ap806_init_sensor(struct platform_device *pdev,
> > + struct armada_thermal_priv
> > *priv) +{
> > + u32 reg;
> > +
> > + reg = readl_relaxed(priv->control0);
> > + reg &= ~CONTROL0_TSEN_RESET;
> > + reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
> > + writel(reg, priv->control0);
> > + msleep(10);
> > +}
> > +
> > static bool armada_is_valid(struct armada_thermal_priv *priv)
> > {
> > u32 reg = readl_relaxed(priv->status);
> > @@ -166,8 +184,8 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, int *temp)
> > {
> > struct armada_thermal_priv *priv = thermal->devdata;
> > - unsigned long reg;
> > - unsigned long m, b, div;
> > + u32 reg, div;
> > + s64 sample, b, m;
> >
> > /* Valid check */
> > if (priv->data->is_valid && !priv->data->is_valid(priv)) {
> > @@ -178,6 +196,11 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal,
> > reg = readl_relaxed(priv->status);
> > reg = (reg >> priv->data->temp_shift) &
> > priv->data->temp_mask;
> > + if (priv->data->signed_sample)
> > + /* The most significant bit is the sign bit */
> > + sample = sign_extend32(reg,
> > fls(priv->data->temp_mask) - 1);
> > + else
> > + sample = reg;
> >
> > /* Get formula coeficients */
> > b = priv->data->coef_b;
> > @@ -185,9 +208,12 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, div = priv->data->coef_div;
> >
> > if (priv->data->inverted)
> > - *temp = ((m * reg) - b) / div;
> > + *temp = (m * sample) - b;
> > else
> > - *temp = (b - (m * reg)) / div;
> > + *temp = b - (m * sample);
> > +
> > + do_div(*temp, div);
>
> I wanted to test in on ARMv7 and this line failed to compile:
> In file included from arch/arm/include/asm/div64.h:127:0,
> from include/linux/kernel.h:173,
> from include/linux/list.h:9,
> from include/linux/kobject.h:20,
> from include/linux/device.h:17,
> from drivers/thermal/armada_thermal.c:16:
> drivers/thermal/armada_thermal.c: In function ?armada_get_temp?:
> include/asm-generic/div64.h:208:28: warning: comparison of distinct
> pointer types lacks a cast (void)(((typeof((n)) *)0) == ((uint64_t
> *)0)); \ ^
> drivers/thermal/armada_thermal.c:247:2: note: in expansion of macro
> ?do_div? do_div(*temp, div);
> ^~~~~~
> In file included from include/linux/ioport.h:13:0,
> from include/linux/device.h:16,
> from drivers/thermal/armada_thermal.c:16:
> include/asm-generic/div64.h:221:25: warning: right shift count >=
> width of type [-Wshift-count-overflow] } else if (likely(((n) >> 32)
> == 0)) { \ ^
> include/linux/compiler.h:175:40: note: in definition of macro ?likely?
> # define likely(x) __builtin_expect(!!(x), 1)
> ^
> drivers/thermal/armada_thermal.c:247:2: note: in expansion of macro
> ?do_div? do_div(*temp, div);
> ^~~~~~
> In file included from arch/arm/include/asm/div64.h:127:0,
> from include/linux/kernel.h:173,
> from include/linux/list.h:9,
> from include/linux/kobject.h:20,
> from include/linux/device.h:17,
> from drivers/thermal/armada_thermal.c:16:
> include/asm-generic/div64.h:225:22: error: passing argument 1 of
> ?__div64_32? from incompatible pointer type
> [-Werror=incompatible-pointer-types] __rem = __div64_32(&(n),
> __base); \ ^ drivers/thermal/armada_thermal.c:247:2: note: in
> expansion of macro ?do_div? do_div(*temp, div);
> ^~~~~~
> In file included from include/linux/kernel.h:173:0,
> from include/linux/list.h:9,
> from include/linux/kobject.h:20,
> from include/linux/device.h:17,
> from drivers/thermal/armada_thermal.c:16:
> arch/arm/include/asm/div64.h:33:24: note: expected ?uint64_t * {aka
> long long unsigned int *}? but argument is of type ?int *? static
> inline uint32_t __div64_32(uint64_t *n, uint32_t base)
>
Indeed, I also have this compilation error with a 32-bit toolchain but
not with the 64-bit one. Anyway I fixed it and tested on a 32-bit
platform also.
Thanks for reporting it.
Miqu?l
^ permalink raw reply
* [GIT PULL] Gemini DTS updates for v4.16, take 2
From: Linus Walleij @ 2017-12-22 9:08 UTC (permalink / raw)
To: linux-arm-kernel
I realized I forgot two DTS patches and the panel
driver for enabling video on DIR-685 was merged, so here is
a second pull request on top of the Gemini DTS pull request
from yesterday.
Please pull it in on top of the other Gemini DTS patches!
Yours,
Linus Walleij
The following changes since commit dd5c0561db755845f0fd372c9bdb3099dce1a1c8:
ARM: dts: Add basic devicetree for D-Link DNS-313 (2017-12-16 20:32:22 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
tags/gemini-dts-update-2
for you to fetch changes up to ea6f23f59331f11494ef966429a0f8672b5d4109:
ARM: dts: Add TVE/TVC and ILI9322 panel to DIR-685 (2017-12-22 09:57:05 +0100)
----------------------------------------------------------------
A second set of Gemini DTS updates for v4.16:
- Use Open Drain flags properly for emulated I2C
- Add the PCI bus to WBD111 and WBD222
- Enable the TVE and panel on DIR-685; the panel driver and
bindings have been merged into the DRI subsystem.
----------------------------------------------------------------
Linus Walleij (3):
ARM: dts: Flags D-Link DIR-685 I2C bus gpios
ARM: dts: Add PCI to WBD111 and WBD222
ARM: dts: Add TVE/TVC and ILI9322 panel to DIR-685
arch/arm/boot/dts/gemini-dlink-dir-685.dts | 67 ++++++++++++++++++++++++++++--
arch/arm/boot/dts/gemini-wbd111.dts | 22 ++++++++++
arch/arm/boot/dts/gemini-wbd222.dts | 22 ++++++++++
3 files changed, 108 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests
From: Herbert Xu @ 2017-12-22 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222084148.GA3024@Red>
On Fri, Dec 22, 2017 at 09:41:48AM +0100, Corentin Labbe wrote:
>
> It's you that was suggesting using crypto_async_request:
> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1474434.html
> "The only wart with this scheme is that the drivers end up seeing
> struct crypto_async_request and will need to convert that to the
> respective request types but I couldn't really find a better way."
>
> So I wait for any suggestion.
The core engine code obviously will use the base type but it should
not be exposed to the driver authors. IOW all exposed API should
take the final types such as aead_request before casting it.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox