* Re: [PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399
From: Caesar Wang @ 2016-11-14 15:05 UTC (permalink / raw)
To: Shawn Lin
Cc: Caesar Wang, Heiko Stuebner, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Catalin Marinas,
Elaine Zhang, Will Deacon, Douglas Anderson,
tfiga-F7+t8E8rja9g9hUCZPvPmw,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
eddie.cai-TNX95d0MmH7DzftRWevZcw, David Wu, Jianqun Xu,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ziyuan Xu
In-Reply-To: <bce1a5eb-fbb3-9ed9-46b9-72a95eefed3e-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On 2016年11月12日 12:22, Shawn Lin wrote:
> On 2016/11/9 21:21, Caesar Wang wrote:
>> From: Ziyuan Xu <xzy.xu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>>
>> Control power domain for eMMC via genpd to reduce power consumption.
>>
>> Signed-off-by: Elaine Zhang <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>> Signed-off-by: Ziyuan Xu <xzy.xu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>> Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> It was verified on my rk3399 evb with kernel4.4, so
> free feel to add my tag,
>
> Tested-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
Thanks the tests.
> BTW, it seems my reply is bounced form Yakir's address, so please
> remove him from CC list if he changed his mail address.
Right, Yakir's (ykk-TNX95d0MmH7DzftRWevZcw@public.gmane.org) address had left this world.;-)
But the patman tool is auto sending with the Cc people.
-
Caesar
>
>> ---
>>
>> Changes in v2:
>> - Reviewed-on: https://chromium-review.googlesource.com/376558
>> - Verified on ChromeOS kernel4.4
>>
>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> index cbb7f8b..b401176 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> @@ -269,6 +269,7 @@
>> #clock-cells = <0>;
>> phys = <&emmc_phy>;
>> phy-names = "phy_arasan";
>> + power-domains = <&power RK3399_PD_EMMC>;
>> status = "disabled";
>> };
>>
>> @@ -690,6 +691,11 @@
>> status = "disabled";
>> };
>>
>> + qos_emmc: qos@ffa58000 {
>> + compatible = "syscon";
>> + reg = <0x0 0xffa58000 0x0 0x20>;
>> + };
>> +
>> qos_gmac: qos@ffa5c000 {
>> compatible = "syscon";
>> reg = <0x0 0xffa5c000 0x0 0x20>;
>> @@ -823,6 +829,11 @@
>> };
>>
>> /* These power domains are grouped by VD_LOGIC */
>> + pd_emmc@RK3399_PD_EMMC {
>> + reg = <RK3399_PD_EMMC>;
>> + clocks = <&cru ACLK_EMMC>;
>> + pm_qos = <&qos_emmc>;
>> + };
>> pd_gmac@RK3399_PD_GMAC {
>> reg = <RK3399_PD_GMAC>;
>> clocks = <&cru ACLK_GMAC>;
>>
>
>
--
caesar wang | software engineer | wxt-TNX95d0MmH73oGB3hsPCZA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v5 3/3] clocksource: Add clockevent support to NPS400 driver
From: Noam Camus @ 2016-11-14 15:17 UTC (permalink / raw)
To: Daniel Lezcano
Cc: robh+dt@kernel.org, mark.rutland@arm.com, tglx@linutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20161114143454.GE2016@mai>
> From: Daniel Lezcano [mailto:daniel.lezcano@linaro.org]
> Sent: Monday, November 14, 2016 4:35 PM
>The function nps_clkevent_timer_event_setup() writes into the NPS_REG_TIMER0_CTRL register but there is no critical section there. What prevents another HW thread to write this register at the same time ?
Correct, during my last email to you I noticed that fact and already started fixing it.
>I do believe we have a framework to access shared registers, otherwise a simple spinlock would be simpler and perhaps faster than disabling the entire hardware scheduling for the system, no ?
When you are saying "we have a framework" do you mean to some generic framework in the kernel?
Anyway to my understanding I cannot guarantee this atomics during my routines without preventing HW from changing the HW thread this core executes.
As SW I am not aware to such HW scheduling, It is much same as with interrupts that we disable them when we reach code that might be shared by the interrupt handler.
>Regarding the comment I did above, it is possible the critical section is reduced and moved into the shutdown function. Thus, the boolean wouldn't be needed anymore, well that is conditional to the above comment. Discard the comment for the moment, until the hw sched vs spinlock vs NPS_REG_TIMER0_CTRL is sorted out.
OK, I will discard that in the meantime.
...
>> >> + .set_state_shutdown = nps_clkevent_timer_shutdown,
>>
>> >Doesn't set_state_shutdown and set_state_oneshot_stopped need to remove the HW thread from the TSI ?
>> You are correct, I will fix that.
>And tick_resume. Perhaps, that is the reason why NO_HZ hangs.
What NO_HZ hang are you referring to in this case?
How calling nps_clkevent_rm_thread() explain such hang?
Anyway I agree, and will add nps_clkevent_rm_thread() to tick_resume.
Appreciating your effort and will gladly provide any more information needed about our SoC.
-Noam
^ permalink raw reply
* Re: [PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399
From: Heiko Stuebner @ 2016-11-14 15:26 UTC (permalink / raw)
To: Caesar Wang
Cc: Mark Rutland, devicetree, Elaine Zhang, Catalin Marinas,
Brian Norris, Ziyuan Xu, Will Deacon, Douglas Anderson,
Rob Herring, tfiga, open list:ARM/Rockchip SoC..., eddie.cai,
linux-arm-kernel, David Wu, Jianqun Xu, linux-kernel
In-Reply-To: <5829D1C7.9020105@rock-chips.com>
Am Montag, 14. November 2016, 23:01:27 CET schrieb Caesar Wang:
> On 2016年11月14日 22:45, Heiko Stuebner wrote:
> > Am Mittwoch, 9. November 2016, 21:21:53 CET schrieb Caesar Wang:
> >> From: Ziyuan Xu <xzy.xu@rock-chips.com>
> >>
> >> Control power domain for eMMC via genpd to reduce power consumption.
> >>
> >> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> >> Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
> >> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> >
> > Authorship / Signed-off mismatch. From above suggest Ziyuan is the author
> > while first Signed-off-by indicates Elaine as author. Please clarify.
>
> I believe the Elaine is the first author. Sorry for this kind of
> question to brother you again. :(
no problem :-) and thanks for the very fast reply.
Applied to my dts64 branch.
Thanks
Heiko
^ permalink raw reply
* [PATCH] arm64: dts: juno: fix cluster sleep state entry latency on all SoC versions
From: Sudeep Holla @ 2016-11-14 15:26 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Jon Medhurst (Tixy), devicetree, Lorenzo Pieralisi, Liviu Dudau,
Sudeep Holla
The core and the cluster sleep state entry latencies can't be same as
cluster sleep involves more work compared to core level e.g. shared
cache maintenance.
Experiments have shown on an average about 100us more latency for the
cluster sleep state compared to the core level sleep. This patch fixes
the entry latency for the cluster sleep state.
Fixes: 28e10a8f3a03 ("arm64: dts: juno: Add idle-states to device tree")
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: "Jon Medhurst (Tixy)" <tixy@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/boot/dts/arm/juno-r1.dts | 2 +-
arch/arm64/boot/dts/arm/juno-r2.dts | 2 +-
arch/arm64/boot/dts/arm/juno.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
Hi,
This was found recently when I found that core sleep was chosen when
entering suspend-to-idle state on Juno. Since the wakeup(entry+exit)
latency matched for the both states, cpu sleep state was chosen to enter
in suspend-to-idle.
Regards,
Sudeep
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
index 3be8a3ef671c..eec37feee8fc 100644
--- a/arch/arm64/boot/dts/arm/juno-r1.dts
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -76,7 +76,7 @@
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x1010000>;
local-timer-stop;
- entry-latency-us = <300>;
+ entry-latency-us = <400>;
exit-latency-us = <1200>;
min-residency-us = <2500>;
};
diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts b/arch/arm64/boot/dts/arm/juno-r2.dts
index 614fc9227943..28f40ec44090 100644
--- a/arch/arm64/boot/dts/arm/juno-r2.dts
+++ b/arch/arm64/boot/dts/arm/juno-r2.dts
@@ -76,7 +76,7 @@
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x1010000>;
local-timer-stop;
- entry-latency-us = <300>;
+ entry-latency-us = <400>;
exit-latency-us = <1200>;
min-residency-us = <2500>;
};
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index 6b4135e9cfe5..ac5ceb73f45f 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -76,7 +76,7 @@
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x1010000>;
local-timer-stop;
- entry-latency-us = <300>;
+ entry-latency-us = <400>;
exit-latency-us = <1200>;
min-residency-us = <2500>;
};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 2/9] arm64: dts: rockchip: add pd_sd power node for rk3399
From: Heiko Stuebner @ 2016-11-14 15:27 UTC (permalink / raw)
To: Caesar Wang
Cc: eddie.cai-TNX95d0MmH7DzftRWevZcw, tfiga-F7+t8E8rja9g9hUCZPvPmw,
zhangqing, Douglas Anderson, David Wu, Jianqun Xu, Yakir Yang,
Brian Norris, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Will Deacon,
Mark Rutland, Catalin Marinas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478697721-2323-3-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Mittwoch, 9. November 2016, 21:21:54 CET schrieb Caesar Wang:
> From: zhangqing <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> 1.add pd node for RK3399 Soc
> 2.create power domain tree
> 3.add qos node for domain
> 4.add the pd_sd consumers node
>
> Signed-off-by: Elaine Zhang <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Applied to my dts64 branch after some tweaks to patch subject and commit
message.
Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] Add Documentation for Media Device, Video Device, and Synopsys DW MIPI CSI-2 Host
From: Ramiro Oliveira @ 2016-11-14 15:31 UTC (permalink / raw)
To: Laurent Pinchart, Ramiro Oliveira
Cc: robh+dt, mark.rutland, mchehab, devicetree, linux-kernel,
linux-media, davem, gregkh, geert+renesas, akpm, linux, hverkuil,
laurent.pinchart+renesas, arnd, sudipm.mukherjee, tiffany.lin,
minghsiu.tsai, jean-christophe.trotin, andrew-ct.chen,
simon.horman, songjun.wu, bparrot, CARLOS.PALMINHA
In-Reply-To: <9132828.vOiOHSy7z0@avalon>
Hi Laurent,
Thanks for the feedback.
On 11/14/2016 2:49 PM, Laurent Pinchart wrote:
> Hi Ramiro,
>
> Thank you for the patch.
>
> On Monday 14 Nov 2016 14:20:22 Ramiro Oliveira wrote:
>> Add documentation for Media and Video Device, as well as the DW MIPI CSI-2
>> Host.
>>
>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>> ---
>> .../devicetree/bindings/media/snps,dw-mipi-csi.txt | 27 +++++++++++++++++++
>> .../devicetree/bindings/media/snps,plat-ipk.txt | 9 ++++++++
>> .../bindings/media/snps,video-device.txt | 12 ++++++++++
>> 3 files changed, 48 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt create mode
>> 100644 Documentation/devicetree/bindings/media/snps,plat-ipk.txt create
>> mode 100644 Documentation/devicetree/bindings/media/snps,video-device.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
>> b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt new file
>> mode 100644
>> index 0000000..bec7441
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
>> @@ -0,0 +1,27 @@
>> +Synopsys DesignWare CSI-2 Host controller
>> +
>> +Description
>> +-----------
>> +
>> +This HW block is used to receive image coming from an MIPI CSI-2 compatible
>> +camera.
>
> And what does it do after receiving the stream ? A more detailed description
> would be useful. Is there any public documentation for this IP core ?
>
I can add a more detailed description. Also, here is a link to the
documentation, but I'm afraid you might have to register yourself to access it.
CSI-2 Host
https://www.synopsys.com/dw/doc.php/ds/c/dwc_csi2_controller.pdf
CSI-2 Host IPK
https://www.synopsys.com/dw/doc.php/ds/o/ip_prototyping_kit_mipi_csi2_host_arc.pdf
>> +Required properties:
>> +- compatible: shall be "snps,dw-mipi-csi"
>> +- reg : physical base address and size of the device memory
> mapped
>> + registers;
>> +- interrupts : CSI-2 Host interrupt
>> +- data-lanes : Number of lanes to be used
>
> Is that fixed at synthesis time or configurable at runtime ?
>
The max number is fixed at synthesis time, but you can configure it for lower
values. I added this option here because, although configurable, it's usually a
fixed value.
>> +- output-type : Core output to be used (IPI-> 0 or IDI->1 or BOTH->2)
>
> What are IPI and IDI ?
>
IPI is Image Pixel Interface and IDI Image Data Interface, these are the two
types of data output support by our CSI-2 Host controller
>> +- phys, phy-names: List of one PHY specifier and identifier string (as
>> defined
>> + in Documentation/devicetree/bindings/phy/phy-bindings.txt).
>
> A PHY for what ?
>
Our controller needs a PHY, in this case a MIPI DPHY, to interact with a CSI-2
receiver (usually a sensor).
>> +Optional properties(if in IPI mode):
>> +- ipi-mode : Mode to be used when in IPI(Camera -> 0 or Automatic -> 1)
>> +- ipi-color-mode: Color depth to be used in IPI (48 bits -> 0 or 16 bits ->
>> 1)
>> +- ipi-auto-flush: Data auto-flush (1 -> Yes or 0 -> No)
>> +- virtual-channel: Virtual channel where data is present when in IPI
>
> We need more details than that, this is impossible to review, sorry.
>
Sure, I'll add more details to the descripton
>> +The per-board settings:
>> + - port sub-node describing a single endpoint connected to the dw-mipi-csi
>> + as described in video-interfaces.txt[1].
>
> An example would be nice.
>
I'll add an example of how we're using it.
>> diff --git a/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
>> b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt new file mode
>> 100644
>> index 0000000..2d51541
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
>> @@ -0,0 +1,9 @@
>> +Synopsys DesignWare CSI-2 Host IPK Media Device
>> +
>> +This Media Device at the moment is not totally functional, however it is a
>> base
>> +for the future.
>
> Then let's add it later :-) We don't want to design incomplete transient DT
> bindings.
>
I'm afraid I wasn't completely clear. This setup is fully functional. Actually
this sentence made sense in the past, but no longer does now.
>> +Required properties:
>> +
>> +- compatible: Must be "snps,plat-ipk".
>> +
>> diff --git a/Documentation/devicetree/bindings/media/snps,video-device.txt
>> b/Documentation/devicetree/bindings/media/snps,video-device.txt new file
>> mode 100644
>> index 0000000..d467092
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/snps,video-device.txt
>> @@ -0,0 +1,12 @@
>> +Synopsys DesignWare CSI-2 Host video device
>> +
>> +This driver handles all the video handling part of this platform.
>
> This is a DT binding documentation, drivers are irrelevant. You should
> describe the hardware only.
>
> More information is needed, based on this document I can't tell what the
> "CSI-2 host video device" is.
>
You're right, I'll add a more detailed description.
>> +Required properties:
>> +
>> +- compatible: Must be "snps,video-device".
>> +
>> +- dmas, dma-names: List of one DMA specifier and identifier string (as
>> defined
>> + in Documentation/devicetree/bindings/dma/dma.txt) per port. Each port
>> + requires a DMA channel with the identifier string set to "port" followed
>> by
>> + the port index.
>
Thanks once again,
Ramiro Oliveira
^ permalink raw reply
* Re: [PATCH v2] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Nicolas Ferre @ 2016-11-14 15:36 UTC (permalink / raw)
To: Wenyou Yang, Alexandre Belloni, Russell King, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
Cc: linux-kernel, Wenyou Yang, devicetree, linux-arm-kernel
In-Reply-To: <1478055958-8463-1-git-send-email-wenyou.yang@atmel.com>
Le 02/11/2016 à 04:05, Wenyou Yang a écrit :
> The sama5d36ek CMP board is the variant of sama5d3xek board.
> It is equipped with the low-power DDR2 SDRAM, PMIC ACT8865 and
> some power rail. Its main purpose is used to measure the power
> consumption.
> The difference of the sama5d36ek CMP dts from sama5d36ek dts
> is listed as below.
> 1. The USB host nodes are removed, that is, the USB host is disabled.
> 2. The gpio_keys node is added to wake up from the sleep.
> 3. The LCD isn't supported due to the pins for LCD are conflicted
> with gpio_keys.
> 4. The adc0 node support the pinctrl sleep state to fix the over
> consumption on VDDANA.
>
> As said in errata, "When the USB host ports are used in high speed
> mode (EHCI), it is not possible to suspend the ports if no device is
> attached on each port. This leads to increased power consumption even
> if the system is in a low power mode." That is why the the USB host
> is disabled.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
>
> Changes in v2:
> - Add the pinctrl sleep state for adc0 node to fix the over
> consumption on VDDANA.
> - Improve the commit log.
>
> arch/arm/boot/dts/sama5d36ek_cmp.dts | 51 +++++++
> arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 166 +++++++++++++++++++++
> arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 265 ++++++++++++++++++++++++++++++++++
> 3 files changed, 482 insertions(+)
> create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
> create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
>
> diff --git a/arch/arm/boot/dts/sama5d36ek_cmp.dts b/arch/arm/boot/dts/sama5d36ek_cmp.dts
> new file mode 100644
> index 0000000..fd6bcd6
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d36ek_cmp.dts
> @@ -0,0 +1,51 @@
> +/*
> + * sama5d36ek_cmp.dts - Device Tree file for SAMA5D36-EK CMP board
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * Licensed under GPLv2 or later.
No, in fact we now use a dual license scheme for DT files. Please have a
look at the recent board that we posted to take the header from them.
> + */
> +/dts-v1/;
> +#include "sama5d36.dtsi"
> +#include "sama5d3xmb_cmp.dtsi"
> +
> +/ {
> + model = "Atmel SAMA5D36-EK";
> + compatible = "atmel,sama5d36ek", "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
I don't think the model name nor the compatible string reflect the
nature of this new "CMP" board.
> +
> + ahb {
> + apb {
> + spi0: spi@f0004000 {
> + status = "okay";
> + };
> +
> + ssc0: ssc@f0008000 {
> + status = "okay";
> + };
> +
> + can0: can@f000c000 {
> + status = "okay";
> + };
> +
> + i2c0: i2c@f0014000 {
> + status = "okay";
> + };
> +
> + i2c1: i2c@f0018000 {
> + status = "okay";
> + };
> +
> + macb0: ethernet@f0028000 {
> + status = "okay";
> + };
> +
> + macb1: ethernet@f802c000 {
> + status = "okay";
> + };
> + };
> + };
> +
> + sound {
> + status = "okay";
> + };
> +};
> diff --git a/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> new file mode 100644
> index 0000000..77638c3
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> @@ -0,0 +1,166 @@
> +/*
> + * sama5d3xcm_cmp.dtsi - Device Tree Include file for SAMA5D36 CMP CPU Module
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * Licensed under GPLv2 or later.
Ditto.
> + */
> +
> +/ {
> + compatible = "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
Ditto.
> +
> + chosen {
> + bootargs = "rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs";
Remove bootargs.
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + reg = <0x20000000 0x20000000>;
> + };
> +
> + clocks {
> + slow_xtal {
> + clock-frequency = <32768>;
> + };
> +
> + main_xtal {
> + clock-frequency = <12000000>;
> + };
> + };
> +
> + ahb {
> + apb {
> + spi0: spi@f0004000 {
> + cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
> + };
> +
> + macb0: ethernet@f0028000 {
> + phy-mode = "rgmii";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet-phy@1 {
> + reg = <0x1>;
> + interrupt-parent = <&pioB>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + txen-skew-ps = <800>;
> + txc-skew-ps = <3000>;
> + rxdv-skew-ps = <400>;
> + rxc-skew-ps = <3000>;
> + rxd0-skew-ps = <400>;
> + rxd1-skew-ps = <400>;
> + rxd2-skew-ps = <400>;
> + rxd3-skew-ps = <400>;
> + };
> +
> + ethernet-phy@7 {
> + reg = <0x7>;
> + interrupt-parent = <&pioB>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + txen-skew-ps = <800>;
> + txc-skew-ps = <3000>;
> + rxdv-skew-ps = <400>;
> + rxc-skew-ps = <3000>;
> + rxd0-skew-ps = <400>;
> + rxd1-skew-ps = <400>;
> + rxd2-skew-ps = <400>;
> + rxd3-skew-ps = <400>;
> + };
> + };
> +
> + i2c1: i2c@f0018000 {
> + pmic: act8865@5b {
> + compatible = "active-semi,act8865";
> + reg = <0x5b>;
> + status = "disabled";
> +
> + regulators {
> + vcc_1v8_reg: DCDC_REG1 {
> + regulator-name = "VCC_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + vcc_1v2_reg: DCDC_REG2 {
> + regulator-name = "VCC_1V2";
> + regulator-min-microvolt = <1100000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-always-on;
> + };
> +
> + vcc_3v3_reg: DCDC_REG3 {
> + regulator-name = "VCC_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vddana_reg: LDO_REG1 {
> + regulator-name = "VDDANA";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vddfuse_reg: LDO_REG2 {
> + regulator-name = "FUSE_2V5";
> + regulator-min-microvolt = <2500000>;
> + regulator-max-microvolt = <2500000>;
> + };
> + };
> + };
> + };
> + };
> +
> + nand0: nand@60000000 {
> + nand-bus-width = <8>;
> + nand-ecc-mode = "hw";
> + atmel,has-pmecc;
> + atmel,pmecc-cap = <4>;
> + atmel,pmecc-sector-size = <512>;
> + nand-on-flash-bbt;
> + status = "okay";
> +
> + at91bootstrap@0 {
> + label = "at91bootstrap";
> + reg = <0x0 0x40000>;
> + };
> +
> + bootloader@40000 {
> + label = "bootloader";
> + reg = <0x40000 0x80000>;
> + };
> +
> + bootloaderenv@c0000 {
> + label = "bootloader env";
> + reg = <0xc0000 0xc0000>;
> + };
> +
> + dtb@180000 {
> + label = "device tree";
> + reg = <0x180000 0x80000>;
> + };
> +
> + kernel@200000 {
> + label = "kernel";
> + reg = <0x200000 0x600000>;
> + };
> +
> + rootfs@800000 {
> + label = "rootfs";
> + reg = <0x800000 0x0f800000>;
> + };
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + d2 {
> + label = "d2";
> + gpios = <&pioE 25 GPIO_ACTIVE_LOW>; /* PE25, conflicts with A25, RXD2 */
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
> new file mode 100644
> index 0000000..62c6230
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
> @@ -0,0 +1,265 @@
> +/*
> + * sama5d3xmb_cmp.dts - Device Tree file for SAMA5D3x CMP mother board
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * Licensed under GPLv2 or later.
Ditto.
> + */
> +#include "sama5d3xcm_cmp.dtsi"
> +
> +/ {
> + compatible = "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
Ditto.
> +
> + ahb {
> + apb {
> + mmc0: mmc@f0000000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
> + status = "okay";
> + slot@0 {
> + reg = <0>;
> + bus-width = <4>;
> + cd-gpios = <&pioD 17 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + spi0: spi@f0004000 {
> + dmas = <0>, <0>; /* Do not use DMA for spi0 */
> +
> + m25p80@0 {
> + compatible = "atmel,at25df321a";
> + spi-max-frequency = <50000000>;
> + reg = <0>;
> + };
> + };
> +
> + ssc0: ssc@f0008000 {
> + atmel,clk-from-rk-pin;
> + };
> +
> + /*
> + * i2c0 conflicts with ISI:
> + * disable it to allow the use of ISI
> + * can not enable audio when i2c0 disabled
> + */
> + i2c0: i2c@f0014000 {
> + wm8904: wm8904@1a {
> + compatible = "wlf,wm8904";
> + reg = <0x1a>;
> + clocks = <&pck0>;
> + clock-names = "mclk";
> + };
> + };
> +
> + i2c1: i2c@f0018000 {
> + ov2640: camera@0x30 {
> + compatible = "ovti,ov2640";
> + reg = <0x30>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pck1_as_isi_mck &pinctrl_sensor_power &pinctrl_sensor_reset>;
> + resetb-gpios = <&pioE 24 GPIO_ACTIVE_LOW>;
> + pwdn-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
> + /* use pck1 for the master clock of ov2640 */
> + clocks = <&pck1>;
> + clock-names = "xvclk";
> + assigned-clocks = <&pck1>;
> + assigned-clock-rates = <25000000>;
> +
> + port {
> + ov2640_0: endpoint {
> + remote-endpoint = <&isi_0>;
> + bus-width = <8>;
> + };
> + };
> + };
> + };
> +
> + usart1: serial@f0020000 {
> + dmas = <0>, <0>; /* Do not use DMA for usart1 */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
> + status = "okay";
> + };
> +
> + isi: isi@f0034000 {
> + port {
> + isi_0: endpoint {
> + remote-endpoint = <&ov2640_0>;
> + bus-width = <8>;
> + vsync-active = <1>;
> + hsync-active = <1>;
> + };
> + };
> + };
> +
> + mmc1: mmc@f8000000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3 &pinctrl_mmc1_cd>;
> + status = "okay";
> + slot@0 {
> + reg = <0>;
> + bus-width = <4>;
> + cd-gpios = <&pioD 18 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + adc0: adc@f8018000 {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <
> + &pinctrl_adc0_adtrg
> + &pinctrl_adc0_ad0
> + &pinctrl_adc0_ad1
> + &pinctrl_adc0_ad2
> + &pinctrl_adc0_ad3
> + &pinctrl_adc0_ad4
> + >;
> + pinctrl-1 = <
> + &pinctrl_adc0_adtrg_sleep
> + &pinctrl_adc0_ad0_sleep
> + &pinctrl_adc0_ad1_sleep
> + &pinctrl_adc0_ad2_sleep
> + &pinctrl_adc0_ad3_sleep
> + &pinctrl_adc0_ad4_sleep
> + >;
> + status = "okay";
> + };
> +
> + macb1: ethernet@f802c000 {
> + phy-mode = "rmii";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy0: ethernet-phy@1 {
> + /*interrupt-parent = <&pioE>;*/
> + /*interrupts = <30 IRQ_TYPE_EDGE_FALLING>;*/
> + reg = <1>;
> + };
> + };
> +
> + pinctrl@fffff200 {
> + adc0 {
> + pinctrl_adc0_adtrg_sleep: adc0_adtrg_1 {
> + atmel,pins =
> + <AT91_PIOD 19 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD19 GPIO output 0 */
> + };
> + pinctrl_adc0_ad0_sleep: adc0_ad0_1 {
> + atmel,pins =
> + <AT91_PIOD 20 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD20 GPIO output 0 */
> + };
> + pinctrl_adc0_ad1_sleep: adc0_ad1_1 {
> + atmel,pins =
> + <AT91_PIOD 21 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD21 GPIO output 0 */
> + };
> + pinctrl_adc0_ad2_sleep: adc0_ad2_1 {
> + atmel,pins =
> + <AT91_PIOD 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD22 GPIO output 0 */
> + };
> + pinctrl_adc0_ad3_sleep: adc0_ad3_1 {
> + atmel,pins =
> + <AT91_PIOD 23 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD23 GPIO output 0 */
> + };
> + pinctrl_adc0_ad4_sleep: adc0_ad4_1 {
> + atmel,pins =
> + <AT91_PIOD 24 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD24 GPIO output 0 */
Please remove all these comments. The binding is good enough to
understand easily.
> + };
> + };
> +
> + board {
> + pinctrl_gpio_keys: gpio_keys {
> + atmel,pins =
> + <AT91_PIOE 27 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
> + };
> +
> + pinctrl_mmc0_cd: mmc0_cd {
> + atmel,pins =
> + <AT91_PIOD 17 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD17 GPIO with pullup deglitch */
> + };
> +
> + pinctrl_mmc1_cd: mmc1_cd {
> + atmel,pins =
> + <AT91_PIOD 18 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD18 GPIO with pullup deglitch */
> + };
> +
> + pinctrl_pck0_as_audio_mck: pck0_as_audio_mck {
> + atmel,pins =
> + <AT91_PIOD 30 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD30 periph B */
> + };
> +
> + pinctrl_pck1_as_isi_mck: pck1_as_isi_mck-0 {
> + atmel,pins =
> + <AT91_PIOD 31 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD31 periph B ISI_MCK */
> + };
> +
> + pinctrl_sensor_reset: sensor_reset-0 {
> + atmel,pins =
> + <AT91_PIOE 24 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE24 gpio */
> + };
> +
> + pinctrl_sensor_power: sensor_power-0 {
> + atmel,pins =
> + <AT91_PIOE 29 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE29 gpio */
> + };
> +
> + pinctrl_usba_vbus: usba_vbus {
> + atmel,pins =
> + <AT91_PIOD 29 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PD29 GPIO with deglitch */
Here again, all comments are not or great use: remove them.
> + };
> + };
> + };
> +
> + dbgu: serial@ffffee00 {
> + dmas = <0>, <0>; /* Do not use DMA for dbgu */
> + status = "okay";
> + };
> +
> + watchdog@fffffe40 {
> + status = "okay";
> + };
> + };
> +
> + usb0: gadget@00500000 {
> + atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usba_vbus>;
> + status = "okay";
> + };
> + };
> +
> + sound {
> + compatible = "atmel,asoc-wm8904";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pck0_as_audio_mck>;
> +
> + atmel,model = "wm8904 @ SAMA5D3EK";
> + atmel,audio-routing =
> + "Headphone Jack", "HPOUTL",
> + "Headphone Jack", "HPOUTR",
> + "IN2L", "Line In Jack",
> + "IN2R", "Line In Jack",
> + "Mic", "MICBIAS",
> + "IN1L", "Mic";
> +
> + atmel,ssc-controller = <&ssc0>;
> + atmel,audio-codec = <&wm8904>;
> +
> + status = "disabled";
> + };
> +
> + /* Conflict with LCD pins */
> + gpio_keys {
> + compatible = "gpio-keys";
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_keys>;
> +
> + pb_user1 {
> + label = "pb_user1";
> + gpios = <&pioE 27 GPIO_ACTIVE_HIGH>;
> + linux,code = <0x100>;
> + gpio-key,wakeup;
> + };
> + };
> +};
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH v5 3/3] clocksource: Add clockevent support to NPS400 driver
From: Daniel Lezcano @ 2016-11-14 15:41 UTC (permalink / raw)
To: Noam Camus
Cc: robh+dt@kernel.org, mark.rutland@arm.com, tglx@linutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <DB6PR0501MB25183EEEC116B9E97CC01BCFAABC0@DB6PR0501MB2518.eurprd05.prod.outlook.com>
On Mon, Nov 14, 2016 at 03:17:48PM +0000, Noam Camus wrote:
> > From: Daniel Lezcano [mailto:daniel.lezcano@linaro.org]
> > Sent: Monday, November 14, 2016 4:35 PM
>
>
> >The function nps_clkevent_timer_event_setup() writes into the
> >NPS_REG_TIMER0_CTRL register but there is no critical section there. What
> >prevents another HW thread to write this register at the same time ?
> Correct, during my last email to you I noticed that fact and already started
> fixing it.
>
> >I do believe we have a framework to access shared registers, otherwise a
> >simple spinlock would be simpler and perhaps faster than disabling the
> >entire hardware scheduling for the system, no ?
> When you are saying "we have a framework" do you mean to some generic
> framework in the kernel?
Yes, IIRC it is regmap but I'm not sure.
> Anyway to my understanding I cannot guarantee this
> atomics during my routines without preventing HW from changing the HW thread
> this core executes. As SW I am not aware to such HW scheduling, It is much
> same as with interrupts that we disable them when we reach code that might be
> shared by the interrupt handler.
I think there is something I am missing with this HW scheduling thing. Why are
these hw_schd_save/hw_schd_restore functions needed to be called from the
timer driver ? Regarding the explanation, the HW scheduling can happen everywhere
at any time, not only in the timer code but this one is the only one which need
the hw_schd_save/hw_schd_restore calls, why ?
Why,
spin_lock(&lock);
write_aux_reg(...)
spin_unlock(&lock);
can't work ?
IIUC, there can be more than 16 cpus/threads, so calling hw_schd_save /
hw_schd_restore will disable the HW scheduling for the entire system while one
cpu is processing something with these couple of registers, no ?
> >Regarding the comment I did above, it is possible the critical section is
> >reduced and moved into the shutdown function. Thus, the boolean wouldn't be
> >needed anymore, well that is conditional to the above comment. Discard the
> >comment for the moment, until the hw sched vs spinlock vs
> >NPS_REG_TIMER0_CTRL is sorted out.
> OK, I will discard that in the meantime.
>
> ...
> >> >> + .set_state_shutdown =
> >> >> nps_clkevent_timer_shutdown,
> >>
> >> >Doesn't set_state_shutdown and set_state_oneshot_stopped need to remove
> >> >the HW thread from the TSI ?
> >> You are correct, I will fix that.
>
> >And tick_resume. Perhaps, that is the reason why NO_HZ hangs.
> What NO_HZ hang are you referring to in this case? How calling
> nps_clkevent_rm_thread() explain such hang? Anyway I agree, and will add
> nps_clkevent_rm_thread() to tick_resume.
Actually I meant NOHZ_FULL.
> Appreciating your effort and will gladly provide any more information needed
> about our SoC. -Noam
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH v2] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Sudeep Holla @ 2016-11-14 15:41 UTC (permalink / raw)
To: Wenyou Yang
Cc: Mark Rutland, devicetree, Russell King, Wenyou Yang, Pawel Moll,
Ian Campbell, Sudeep Holla, Nicolas Ferre, linux-kernel,
Rob Herring, Alexandre Belloni, Kumar Gala, linux-arm-kernel
In-Reply-To: <1478055958-8463-1-git-send-email-wenyou.yang@atmel.com>
On 02/11/16 03:05, Wenyou Yang wrote:
> The sama5d36ek CMP board is the variant of sama5d3xek board.
> It is equipped with the low-power DDR2 SDRAM, PMIC ACT8865 and
> some power rail. Its main purpose is used to measure the power
> consumption.
> The difference of the sama5d36ek CMP dts from sama5d36ek dts
> is listed as below.
> 1. The USB host nodes are removed, that is, the USB host is disabled.
> 2. The gpio_keys node is added to wake up from the sleep.
> 3. The LCD isn't supported due to the pins for LCD are conflicted
> with gpio_keys.
> 4. The adc0 node support the pinctrl sleep state to fix the over
> consumption on VDDANA.
>
> As said in errata, "When the USB host ports are used in high speed
> mode (EHCI), it is not possible to suspend the ports if no device is
> attached on each port. This leads to increased power consumption even
> if the system is in a low power mode." That is why the the USB host
> is disabled.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
>
> Changes in v2:
> - Add the pinctrl sleep state for adc0 node to fix the over
> consumption on VDDANA.
> - Improve the commit log.
>
> arch/arm/boot/dts/sama5d36ek_cmp.dts | 51 +++++++
> arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 166 +++++++++++++++++++++
> arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 265 ++++++++++++++++++++++++++++++++++
> 3 files changed, 482 insertions(+)
> create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
> create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
>
[...]
> + /* Conflict with LCD pins */
> + gpio_keys {
> + compatible = "gpio-keys";
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_keys>;
> +
> + pb_user1 {
> + label = "pb_user1";
> + gpios = <&pioE 27 GPIO_ACTIVE_HIGH>;
> + linux,code = <0x100>;
> + gpio-key,wakeup;
Please replace this with "wakeup-source", I will post patches to fix the
new comers in the mainline. It was cleaned last year.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH -next] ARM: dts: omap5: replace gpio-key,wakeup with wakeup-source property
From: Sudeep Holla @ 2016-11-14 15:44 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sudeep Holla, devicetree-u79uwXL29TY76Z2rM5mHXA,
Benoît Cousson, Tony Lindgren
Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
check for/support the legacy "gpio-key,wakeup" boolean property to
enable gpio buttons as wakeup source, "wakeup-source" is the new
standard binding.
This patch replaces the legacy "gpio-key,wakeup" with the unified
"wakeup-source" property in order to avoid any further copy-paste
duplication.
Cc: "Benoît Cousson" <bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
---
arch/arm/boot/dts/omap5-uevm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi,
Inspite of getting rid of most of the legacy property almost a year ago,
addition of new platforms have brought this back and over time it's
now found again in few places. Just get rid of them *again*
Regards,
Sudeep
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 2fcdc516da45..a8c72611fbe3 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -41,7 +41,7 @@
label = "BTN1";
linux,code = <169>;
gpios = <&gpio3 19 GPIO_ACTIVE_LOW>; /* gpio3_83 */
- gpio-key,wakeup;
+ wakeup-source;
autorepeat;
debounce_interval = <50>;
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
From: Sudeep Holla @ 2016-11-14 15:44 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sudeep Holla, devicetree-u79uwXL29TY76Z2rM5mHXA, Nicolas Ferre,
Alexandre Belloni, Jean-Christophe Plagniol-Villard
Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
check for/support the legacy "gpio-key,wakeup" boolean property to
enable gpio buttons as wakeup source, "wakeup-source" is the new
standard binding.
This patch replaces the legacy "gpio-key,wakeup" with the unified
"wakeup-source" property in order to avoid any further copy-paste
duplication.
Cc: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Jean-Christophe Plagniol-Villard <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
---
arch/arm/boot/dts/at91sam9260ek.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Hi,
Inspite of getting rid of most of the legacy property almost a year ago,
addition of new platforms have brought this back and over time it's
now found again in few places. Just get rid of them *again*
Regards,
Sudeep
diff --git a/arch/arm/boot/dts/at91sam9260ek.dts b/arch/arm/boot/dts/at91sam9260ek.dts
index 2c87f58448e7..b2578feceb08 100644
--- a/arch/arm/boot/dts/at91sam9260ek.dts
+++ b/arch/arm/boot/dts/at91sam9260ek.dts
@@ -174,14 +174,14 @@
label = "Button 3";
gpios = <&pioA 30 GPIO_ACTIVE_LOW>;
linux,code = <0x103>;
- gpio-key,wakeup;
+ wakeup-source;
};
btn4 {
label = "Button 4";
gpios = <&pioA 31 GPIO_ACTIVE_LOW>;
linux,code = <0x104>;
- gpio-key,wakeup;
+ wakeup-source;
};
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] ARM: dts: imx6q: replace gpio-key,wakeup with wakeup-source for Utilite Pro
From: Sudeep Holla @ 2016-11-14 15:44 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sudeep Holla, devicetree-u79uwXL29TY76Z2rM5mHXA, Shawn Guo,
Sascha Hauer, Fabio Estevam
Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
check for/support the legacy "gpio-key,wakeup" boolean property to
enable gpio buttons as wakeup source, "wakeup-source" is the new
standard binding.
This patch replaces the legacy "gpio-key,wakeup" with the unified
"wakeup-source" property in order to avoid any further copy-paste
duplication.
Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
---
arch/arm/boot/dts/imx6q-utilite-pro.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi,
Inspite of getting rid of most of the legacy property almost a year ago,
addition of new platforms have brought this back and over time it's
now found again in few places. Just get rid of them *again*
Regards,
Sudeep
diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
index 61990630a748..104bbe710927 100644
--- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
+++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
@@ -68,7 +68,7 @@
label = "Power Button";
gpios = <&gpio1 29 GPIO_ACTIVE_LOW>;
linux,code = <KEY_POWER>;
- gpio-key,wakeup;
+ wakeup-source;
};
};
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] ARM: dts: sun8i: replace enable-sdio-wakeup with wakeup-source for BananaPi M1+
From: Sudeep Holla @ 2016-11-14 15:44 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sudeep Holla, devicetree-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai,
Maxime Ripard
Though the mmc core driver will continue to support the legacy
"enable-sdio-wakeup" property to enable SDIO as the wakeup source,
"wakeup-source" is the new standard binding.
This patch replaces the legacy "enable-sdio-wakeup" with the unified
"wakeup-source" property in order to avoid any further copy-paste
duplication.
Cc: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Cc: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi,
Inspite of getting rid of most of the legacy property almost a year ago,
addition of new platforms have brought this back and over time it's
now found again in few places. Just get rid of them *again*
Regards,
Sudeep
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
index ba5bca0fe997..1df47aa0a07b 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
@@ -167,7 +167,7 @@
mmc-pwrseq = <&mmc3_pwrseq>;
bus-width = <4>;
non-removable;
- enable-sdio-wakeup;
+ wakeup-source;
status = "okay";
brcmf: bcrmf@1 {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v7 11/14] mmc: sdhci-msm: Add HS400 platform support
From: Ulf Hansson @ 2016-11-14 15:44 UTC (permalink / raw)
To: kbuild test robot
Cc: Ritesh Harjani, kbuild-all@01.org, linux-mmc, Adrian Hunter,
Shawn Lin, Stephen Boyd, Andy Gross, devicetree@vger.kernel.org,
linux-clk, david.brown, linux-arm-msm@vger.kernel.org,
Georgi Djakov, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Asutosh Das, kdorfman@codeaurora.org, David Griego
In-Reply-To: <201611142112.EdLY7cAN%fengguang.wu@intel.com>
Hi,
On 14 November 2016 at 14:53, kbuild test robot <lkp@intel.com> wrote:
> Hi Venkat,
>
> [auto build test ERROR on ulf.hansson-mmc/next]
> [also build test ERROR on v4.9-rc5]
> [cannot apply to next-20161114]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
Here we go...
>
> url: https://github.com/0day-ci/linux/commits/Ritesh-Harjani/mmc-sdhci-msm-Add-clk-rates-DDR-HS400-support/20161114-142815
> base: https://git.linaro.org/people/ulf.hansson/mmc next
This above is the old tree, here's the new:
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
Could you please update the path in the build system?
[...]
Kind regards
Ulf Hansson
^ permalink raw reply
* Re: [PATCH] ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
From: Nicolas Ferre @ 2016-11-14 15:45 UTC (permalink / raw)
To: Sudeep Holla, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Alexandre Belloni,
Jean-Christophe Plagniol-Villard
In-Reply-To: <1479138250-17780-2-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
Le 14/11/2016 à 16:44, Sudeep Holla a écrit :
> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
> check for/support the legacy "gpio-key,wakeup" boolean property to
> enable gpio buttons as wakeup source, "wakeup-source" is the new
> standard binding.
>
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
Acked-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
> Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
> ---
> arch/arm/boot/dts/at91sam9260ek.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Hi,
>
> Inspite of getting rid of most of the legacy property almost a year ago,
> addition of new platforms have brought this back and over time it's
> now found again in few places. Just get rid of them *again*
>
> Regards,
> Sudeep
Sorry for this Sudeep and thanks for the patch.
Best regards,
> diff --git a/arch/arm/boot/dts/at91sam9260ek.dts b/arch/arm/boot/dts/at91sam9260ek.dts
> index 2c87f58448e7..b2578feceb08 100644
> --- a/arch/arm/boot/dts/at91sam9260ek.dts
> +++ b/arch/arm/boot/dts/at91sam9260ek.dts
> @@ -174,14 +174,14 @@
> label = "Button 3";
> gpios = <&pioA 30 GPIO_ACTIVE_LOW>;
> linux,code = <0x103>;
> - gpio-key,wakeup;
> + wakeup-source;
> };
>
> btn4 {
> label = "Button 4";
> gpios = <&pioA 31 GPIO_ACTIVE_LOW>;
> linux,code = <0x104>;
> - gpio-key,wakeup;
> + wakeup-source;
> };
> };
>
> --
> 2.7.4
>
>
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6q: replace gpio-key,wakeup with wakeup-source for Utilite Pro
From: Fabio Estevam @ 2016-11-14 15:47 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Shawn Guo,
Sascha Hauer, Fabio Estevam
In-Reply-To: <1479138250-17780-3-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
On Mon, Nov 14, 2016 at 1:44 PM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org> wrote:
> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
> check for/support the legacy "gpio-key,wakeup" boolean property to
> enable gpio buttons as wakeup source, "wakeup-source" is the new
> standard binding.
>
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] regulator: pwm: DT: Add ramp delay for exponential voltage transition
From: Rob Herring @ 2016-11-14 15:48 UTC (permalink / raw)
To: Laxman Dewangan
Cc: broonie, mark.rutland, linux-kernel, devicetree, Douglas Anderson,
Aleksandr Frid
In-Reply-To: <1478281075-3498-1-git-send-email-ldewangan@nvidia.com>
On Fri, Nov 04, 2016 at 11:07:54PM +0530, Laxman Dewangan wrote:
> Some PWM regulator has the exponential transition in voltage change as
> opposite to fixed slew-rate linear transition on other regulators.
> For such PWM regulators, add the property for providing the delay
> from DT node.
>
> Add DT binding details of the new property
> "pwm-regulator-voltage-ramp-time-us" added for providing voltage
> transition delay.
>
> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
> CC: Douglas Anderson <dianders@chromium.org>
> CC: Aleksandr Frid <afrid@nvidia.com>
>
> ---
> This patch is continuation of discussion on patch
> regulator: pwm: Fix regulator ramp delay for continuous mode
> https://patchwork.kernel.org/patch/9216857/
> where is it discussed to have separate property for PWM which has
> exponential voltage transition.
> ---
> Documentation/devicetree/bindings/regulator/pwm-regulator.txt | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
> index 3aeba9f..a163f42 100644
> --- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
> @@ -54,6 +54,16 @@ Optional properties:
> --------------------
> - enable-gpios: GPIO to use to enable/disable the regulator
>
> +- pwm-regulator-voltage-ramp-time-us: Integer, voltage ramp time in
This is a really long name. Drop the 'pwm-regulator-' part as it is
redundant. The fact that it is PWM reg specific is captured as it is
documented that way.
Rob
^ permalink raw reply
* Re: [PATCH] ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
From: Sudeep Holla @ 2016-11-14 15:51 UTC (permalink / raw)
To: Nicolas Ferre
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sudeep Holla,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alexandre Belloni,
Jean-Christophe Plagniol-Villard
In-Reply-To: <55e95acc-d30f-432e-90d6-f96bad69ac3d-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
On 14/11/16 15:45, Nicolas Ferre wrote:
> Le 14/11/2016 à 16:44, Sudeep Holla a écrit :
>> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
>> check for/support the legacy "gpio-key,wakeup" boolean property to
>> enable gpio buttons as wakeup source, "wakeup-source" is the new
>> standard binding.
>>
>> This patch replaces the legacy "gpio-key,wakeup" with the unified
>> "wakeup-source" property in order to avoid any further copy-paste
>> duplication.
>>
>> Cc: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
>
> Acked-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
>
>> Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> Cc: Jean-Christophe Plagniol-Villard <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
>> ---
>> arch/arm/boot/dts/at91sam9260ek.dts | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Hi,
>>
>> Inspite of getting rid of most of the legacy property almost a year ago,
>> addition of new platforms have brought this back and over time it's
>> now found again in few places. Just get rid of them *again*
>>
>> Regards,
>> Sudeep
>
> Sorry for this Sudeep and thanks for the patch.
>
No problem, in fact you reminded me to post them :)
--
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/2] Documentation: dt: reset: Add TI SCI reset binding
From: Rob Herring @ 2016-11-14 15:52 UTC (permalink / raw)
To: Andrew F. Davis
Cc: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Philipp Zabel,
Mark Rutland, Suman Anna,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161104174240.9688-2-afd-l0cyMroinI0@public.gmane.org>
On Fri, Nov 04, 2016 at 12:42:39PM -0500, Andrew F. Davis wrote:
> Add TI SCI reset controller binding. This describes the DT binding
> details for a reset controller node providing reset management services
> to hardware blocks (reset consumers) using the Texas Instrument's System
> Control Interface (TI SCI) protocol to communicate to a system controller
> block present on the SoC.
>
> Signed-off-by: Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>
> [s-anna-l0cyMroinI0@public.gmane.org: revise the binding format]
> Signed-off-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
> ---
> .../devicetree/bindings/reset/ti,sci-reset.txt | 65 ++++++++++++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/reset/k2g.h | 22 ++++++++
> 3 files changed, 89 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> create mode 100644 include/dt-bindings/reset/k2g.h
>
> diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> new file mode 100644
> index 0000000..cb00679
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> @@ -0,0 +1,65 @@
> +Texas Instruments System Control Interface (TI-SCI) Reset Controller
> +=====================================================================
> +
> +Some TI SoCs contain a system controller (like the Power Management Micro
> +Controller (PMMC) on Keystone K2G SoC) that are responsible for controlling
> +the state of the various hardware modules present on the SoC. Communication
> +between the host processor running an OS and the system controller happens
> +through a protocol called TI System Control Interface (TI-SCI protocol).
> +For TI SCI details, please refer to the document,
> +Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +TI-SCI Reset Controller Node
> +============================
> +This reset controller node uses the TI SCI protocol to perform the reset
> +management of various hardware modules present on the SoC.
Needs to say must be a child of the SCI node somewhere in here.
> +
> +Required properties:
> +--------------------
> + - compatible : Should be "ti,sci-reset"
> + - #reset-cells : Should be 2. Please see the reset consumer node below for
> + usage details.
> +
> +TI-SCI Reset Consumer Nodes
> +===========================
> +Each of the reset consumer nodes should have the following properties,
> +in addition to their own properties.
> +
> +Required properties:
> +--------------------
> + - resets : A phandle and reset specifier pair, one pair for each reset
> + signal that affects the device, or that the device manages.
> + The phandle should point to the TI-SCI reset controller node,
> + and the reset specifier should have 2 cell-values. The first
> + cell should contain the device ID, the values of which are
> + specified in the <dt-bindings/genpd/<soc>.h> include file.
> + The second cell should contain the reset mask value used by
> + system controller, the values of which are specified in the
> + include file <dt-bindings/reset/<soc>.h>, where <soc> is the
> + name of the SoC involved, for example 'k2g'.
> +
> +Please also refer to Documentation/devicetree/bindings/reset/reset.txt for
> +common reset controller usage by consumers.
> +
> +Example:
> +--------
> +The following example demonstrates both a TI-SCI reset controller node and a
> +consumer (a DSP device) on the K2G SoC.
> +
> +#include <dt-bindings/genpd/k2g.h>
> +#include <dt-bindings/reset/k2g.h>
> +
> +pmmc: pmmc {
> + compatible = "ti,k2g-sci";
> +
> + k2g_reset: k2g_reset {
...: reset-controller {
> + compatible = "ti,sci-reset";
> + #reset-cells = <2>;
> + };
> +};
> +
> +dsp0: dsp0 {
> + ...
> + resets = <&k2g_reset K2G_DEV_CGEM0 K2G_DEV_CGEM0_DSP0_RESET>;
> + ...
> +};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [RFC 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20
From: Ramesh Shanmugasundaram @ 2016-11-14 15:53 UTC (permalink / raw)
To: Hans Verkuil, Laurent Pinchart
Cc: Antti Palosaari, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
Chris Paterson, geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <fb15b6f3-6c5c-0922-8655-aabd4799d158-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
Hello Laurent, Antti, Hans,
> Subject: Re: [RFC 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20
>
> On 11/11/2016 02:57 PM, Laurent Pinchart wrote:
> > Hi Hans,
> >
> > On Friday 11 Nov 2016 14:53:58 Hans Verkuil wrote:
> >> On 11/10/2016 09:08 AM, Laurent Pinchart wrote:
> >>> Antti, Hans, ping ? Please see below.
> >>>
> >>> On Friday 04 Nov 2016 09:23:29 Ramesh Shanmugasundaram wrote:
> >>>>> On 11/02/2016 10:58 PM, Laurent Pinchart wrote:
> >>>>>> On Wednesday 02 Nov 2016 09:00:00 Ramesh Shanmugasundaram wrote:
> >>>>>>>>> On Wednesday 12 Oct 2016 15:10:29 Ramesh Shanmugasundaram wrote:
> >>>>>>>>>> This patch adds documentation for the three new SDR formats
> >>>>>>>>>>
> >>>>>>>>>> V4L2_SDR_FMT_SCU16BE
> >>>>>>>>>> V4L2_SDR_FMT_SCU18BE
> >>>>>>>>>> V4L2_SDR_FMT_SCU20BE
> >>>>>>>
> >>>>>>> [snip]
> >>>>>>>
> >>>>>>>>>> +
> >>>>>>>>>> + - start + 0:
> >>>>>>>>>> +
> >>>>>>>>>> + - I'\ :sub:`0[D13:D6]`
> >>>>>>>>>> +
> >>>>>>>>>> + - I'\ :sub:`0[D5:D0]`
> >>>>>>>>>> +
> >>>>>>>>>> + - .. row 2
> >>>>>>>>>> +
> >>>>>>>>>> + - start + buffer_size/2:
> >>>>>>>>>> +
> >>>>>>>>>> + - Q'\ :sub:`0[D13:D6]`
> >>>>>>>>>> +
> >>>>>>>>>> + - Q'\ :sub:`0[D5:D0]`
> >>>>>>>>>
> >>>>>>>>> The format looks planar, does it use one V4L2 plane (as does
> >>>>>>>>> NV12) or two V4L2 planes (as does NV12M) ? Same question for
> >>>>>>>>> the other formats.
> >>>>>>>>
> >>>>>>>> Thank you for bringing up this topic. This is one of the key
> >>>>>>>> design dilemma.
> >>>>>>>>
> >>>>>>>> The I & Q data for these three SDR formats comes from two
> >>>>>>>> different DMA channels and hence two separate pointers -> we
> >>>>>>>> could say it is
> >>>>>>>> v4l2 multi- planar. Right now, I am making it look like a
> >>>>>>>> single plane by presenting the data in one single buffer ptr.
> >>>>>>>>
> >>>>>>>> For e.g. multi-planar SC16 format would look something like
> >>>>>>>> this
> >>>>>>>>
> >>>>>>>> <------------------------32bits---------------------->
> >>>>>>>> <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0
> >>>>>>>> + 0
> >>>>>>>> <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0
> >>>>>>>> + 4 ...
> >>>>>>>> <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1
> >>>>>>>> + 0
> >>>>>>>> <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1
> >>>>>>>> + 4
> >>>>>>>>
> >>>>>>>> My concerns are
> >>>>>>>>
> >>>>>>>> 1) These formats are not a standard as the video "Image Formats".
> >>>>>>>> These formats are possible when we use DRIF + MAX2175
> combination.
> >>>>>>>> If we interface with a different tuner vendor, the above
> >>>>>>>> format(s) MAY/MAY NOT be re-usable. We do not know at this
> >>>>>>>> point. This is the main open item for discussion in the cover
> letter.
> >>>>>>
> >>>>>> If the formats are really device-specific then they should be
> >>>>>> documented accordingly and not made generic.
> >>>>>>
> >>>>>>>> 2) MPLANE support within V4L2 seems specific to video. Please
> >>>>>>>> correct me if this is wrong interpretation.
> >>>>>>>>
> >>>>>>>> - struct v4l2_format contains v4l2_sdr_format and
> >>>>>>>> v4l2_pix_format_mplane as members of union. Should I create a
> >>>>>>>> new v4l2_sdr_format_mplane? If I have to use
> >>>>>>>> v4l2_pix_format_mplane most of the video specific members would
> >>>>>>>> be unused (it would be similar to using v4l2_pix_format itself
> instead of v4l2_sdr_format)?
> >>>>>>
> >>>>>> I have no answer to that question as I'm not familiar with SDR.
> >>>>>> Antti, you've added v4l2_sdr_format to the API, what's your
> >>>>>> opinion ? Hans, as you've acked the patch, your input would be
> appreciated as well.
> >>>>>
> >>>>> If I understood correctly this hardware provides I and Q samples
> >>>>> via different channels and driver now combines those channels as a
> >>>>> sequential IQ sample pairs.
> >>>>
> >>>> The driver combines the two buffer ptrs and present as one single
> buffer.
> >>>> For a buffer of size 200
> >>>>
> >>>> ptr + 0 : I I I I ... I
> >>>> ptr + 100 : Q Q Q Q ... Q
> >>>>
> >>>>> I have never seen any other than hw which provides IQ IQ IQ IQ ...
> IQ.
> >>>>
> >>>> There are some modes where this h/w combo can also do IQ IQ IQ
> pattern.
> >>>> Those modes are not added in the RFC patchset.
> >>>>
> >>>>> This is
> >>>>> I I I I ... I
> >>>>> Q Q Q Q ... Q
> >>>>> I am not very familiar with planars, but it sounds like it is
> >>>>> correct approach. So I think should be added rather than emulate
> >>>>> packet sequential format.
> >>>>
> >>>> My understanding of V4L2 MPLANE constructs is limited to a quick
> >>>> code read only. At this point MPLANE support seems specific to
> >>>> video. SDR is defined as separate format like v4l2_pix_format.
> >>>> Questions would be - should we define new SDR_MPLANE? or merge SDR
> >>>> format with pix format & reuse existing MPLANE with some SDR
> >>>> extensions (if possible)? These seem big design decisions. Any
> >>>> suggestions please?
> >>>>
> >>>> For my use case, MPLANE support does not seem to add significant
> >>>> benefit except it may be syntactically correct. I am doing cyclic
> >>>> DMA with a small set of h/w buffers and copying each stage to one
> >>>> mmapped vmalloc vb2_buffer at two offsets. If we add MPLANE
> >>>> support, it can be two non-contiguous buffer pointers.
> >>>>
> >>>>>>>> - The above decision (accomodate SDR & MPLANE) needs to be
> >>>>>>>> propagated across the framework. Is this the preferred approach?
> >>>>>>>>
> >>>>>>>> It goes back to point (1). As of today, the change set for this
> >>>>>>>> combo (DRIF+MAX2175) introduces new SDR formats only. Should it
> >>>>>>>> add further SDR+MPLANE support to the framework as well?
> >>>>>>>>
> >>>>>>>> I would appreciate your suggestions on this regard.
> >>
> >> Some terminology first:
> >>
> >> Planar formats separate the data into different memory areas: in this
> >> case one part is all I and one part is all Q. This as opposed to
> >> interleaved formats (IQIQIQIQ....).
> >>
> >> As long as both planes fit in the same buffer all is fine. Since that
> >> is the case here there is no need to introduce a new MPLANE API.
> >>
> >> The MPLANE API was added for video to handle cases where the two
> >> planes had to be in two different non-contiguous buffers.
> >
> > Not only that, it can also be used for cases where storing the two
> > planes in separate buffers can be beneficial, even if a single
> > contiguous buffer could work.
> >
> >> So instead of passing one buffer pointer, you need to pass two or
> >> more buffer pointers.
> >>
> >> In hindsight we should have called it the MBUFFER API.
> >
> > The name was badly chosen, yes.
> >
> >> Oh well...
> >>
> >> Anyway, since there is no problem here apparently to keep both planes
> >> in one buffer there is also no need to introduce a SDR_MPLANE.
> >
> > The question here is whether there could be a benefit in separating I
> > and Q data in two buffers compared to storing them in the same buffer.
> >
>
> The MPLANE API is very messy and introducing something like SDR_MPLANE is
> not something I would promote. If we want that, then we should first make
> a new v4l2_buffer struct that simplifies MPLANE handling (we discussed
> that before).
Thank you for the comments and closure on this topic.
Thanks,
Ramesh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/2] regulator: fixed: dt: Allow an optional over current pin
From: Rob Herring @ 2016-11-14 15:54 UTC (permalink / raw)
To: Axel Haslam
Cc: broonie, girdwood, khilman, nsekhar, david, linux-kernel,
devicetree
In-Reply-To: <20161104213536.28496-2-ahaslam@baylibre.com>
On Fri, Nov 04, 2016 at 10:35:35PM +0100, Axel Haslam wrote:
> Add support for an optional over current input pin which
> can be used to send an over current event to the regulator
> consumer.
>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
> Documentation/devicetree/bindings/regulator/fixed-regulator.txt | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* RE: [PATCH 2/5] media: i2c: max2175: Add MAX2175 support
From: Ramesh Shanmugasundaram @ 2016-11-14 15:54 UTC (permalink / raw)
To: Hans Verkuil, robh+dt@kernel.org, mark.rutland@arm.com,
mchehab@kernel.org, sakari.ailus@linux.intel.com, crope@iki.fi
Cc: Chris Paterson, laurent.pinchart@ideasonboard.com,
geert+renesas@glider.be, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <46394837-c3f0-8487-750b-95dae7bcf859@xs4all.nl>
Hi Hans,
Thank you for the review comments.
> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
> > This patch adds driver support for MAX2175 chip. This is Maxim
> > Integrated's RF to Bits tuner front end chip designed for
> > software-defined radio solutions. This driver exposes the tuner as a
> > sub-device instance with standard and custom controls to configure the
> device.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > <ramesh.shanmugasundaram@bp.renesas.com>
> > ---
> > .../devicetree/bindings/media/i2c/max2175.txt | 61 +
> > drivers/media/i2c/Kconfig | 4 +
> > drivers/media/i2c/Makefile | 2 +
> > drivers/media/i2c/max2175/Kconfig | 8 +
> > drivers/media/i2c/max2175/Makefile | 4 +
> > drivers/media/i2c/max2175/max2175.c | 1558
> ++++++++++++++++++++
> > drivers/media/i2c/max2175/max2175.h | 108 ++
> > 7 files changed, 1745 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/media/i2c/max2175.txt
> > create mode 100644 drivers/media/i2c/max2175/Kconfig create mode
> > 100644 drivers/media/i2c/max2175/Makefile
> > create mode 100644 drivers/media/i2c/max2175/max2175.c
> > create mode 100644 drivers/media/i2c/max2175/max2175.h
> >
>
> <snip>
>
> > diff --git a/drivers/media/i2c/max2175/max2175.c
> > b/drivers/media/i2c/max2175/max2175.c
> > new file mode 100644
> > index 0000000..ec45b52
> > --- /dev/null
> > +++ b/drivers/media/i2c/max2175/max2175.c
> > @@ -0,0 +1,1558 @@
>
> <snip>
>
> > +/* Read/Write bit(s) on top of regmap */ static int
> > +max2175_read(struct max2175 *ctx, u8 idx, u8 *val) {
> > + u32 regval;
> > + int ret = regmap_read(ctx->regmap, idx, ®val);
> > +
> > + if (ret)
> > + v4l2_err(ctx->client, "read ret(%d): idx 0x%02x\n", ret, idx);
> > +
> > + *val = regval;
>
> Does regmap_read initialize regval even if it returns an error? If not,
> then I would initialize regval to 0 to prevent *val being uninitialized.
Agreed.
>
> > + return ret;
> > +}
> > +
> > +static int max2175_write(struct max2175 *ctx, u8 idx, u8 val) {
> > + int ret = regmap_write(ctx->regmap, idx, val);
> > +
> > + if (ret)
> > + v4l2_err(ctx->client, "write ret(%d): idx 0x%02x val
> 0x%02x\n",
> > + ret, idx, val);
> > + return ret;
> > +}
> > +
> > +static u8 max2175_read_bits(struct max2175 *ctx, u8 idx, u8 msb, u8
> > +lsb) {
> > + u8 val;
> > +
> > + if (max2175_read(ctx, idx, &val))
> > + return 0;
> > +
> > + return max2175_get_bitval(val, msb, lsb); }
> > +
> > +static bool max2175_read_bit(struct max2175 *ctx, u8 idx, u8 bit) {
> > + return !!max2175_read_bits(ctx, idx, bit, bit); }
> > +
> > +static int max2175_write_bits(struct max2175 *ctx, u8 idx,
> > + u8 msb, u8 lsb, u8 newval)
> > +{
> > + int ret = regmap_update_bits(ctx->regmap, idx, GENMASK(msb, lsb),
> > + newval << lsb);
> > +
> > + if (ret)
> > + v4l2_err(ctx->client, "wbits ret(%d): idx 0x%02x\n", ret,
> idx);
> > +
> > + return ret;
> > +}
> > +
> > +static int max2175_write_bit(struct max2175 *ctx, u8 idx, u8 bit, u8
> > +newval) {
> > + return max2175_write_bits(ctx, idx, bit, bit, newval); }
> > +
> > +/* Checks expected pattern every msec until timeout */ static int
> > +max2175_poll_timeout(struct max2175 *ctx, u8 idx, u8 msb, u8 lsb,
> > + u8 exp_bitval, u32 timeout_ms)
> > +{
> > + unsigned int val;
> > +
> > + return regmap_read_poll_timeout(ctx->regmap, idx, val,
> > + (max2175_get_bitval(val, msb, lsb) == exp_bitval),
> > + 1000, timeout_ms * 1000);
> > +}
> > +
> > +static int max2175_poll_csm_ready(struct max2175 *ctx) {
> > + int ret;
> > +
> > + ret = max2175_poll_timeout(ctx, 69, 1, 1, 0, 50);
> > + if (ret)
> > + v4l2_err(ctx->client, "csm not ready\n");
> > +
> > + return ret;
> > +}
> > +
> > +#define MAX2175_IS_BAND_AM(ctx) \
> > + (max2175_read_bits(ctx, 5, 1, 0) == MAX2175_BAND_AM)
> > +
> > +#define MAX2175_IS_BAND_VHF(ctx) \
> > + (max2175_read_bits(ctx, 5, 1, 0) == MAX2175_BAND_VHF)
> > +
> > +#define MAX2175_IS_FM_MODE(ctx) \
> > + (max2175_read_bits(ctx, 12, 5, 4) == 0)
> > +
> > +#define MAX2175_IS_FMHD_MODE(ctx) \
> > + (max2175_read_bits(ctx, 12, 5, 4) == 1)
> > +
> > +#define MAX2175_IS_DAB_MODE(ctx) \
> > + (max2175_read_bits(ctx, 12, 5, 4) == 2)
> > +
> > +static int max2175_band_from_freq(u32 freq) {
> > + if (freq >= 144000 && freq <= 26100000)
> > + return MAX2175_BAND_AM;
> > + else if (freq >= 65000000 && freq <= 108000000)
> > + return MAX2175_BAND_FM;
> > + else
>
> No need for these 'else' keywords.
Agreed.
>
> > + return MAX2175_BAND_VHF;
> > +}
> > +
> > +static int max2175_update_i2s_mode(struct max2175 *ctx, u32 rx_mode,
> > + u32 i2s_mode)
> > +{
> > + max2175_write_bits(ctx, 29, 2, 0, i2s_mode);
> > +
> > + /* Based on I2S mode value I2S_WORD_CNT values change */
> > + switch (i2s_mode) {
> > + case MAX2175_I2S_MODE3:
> > + max2175_write_bits(ctx, 30, 6, 0, 1);
> > + break;
> > + case MAX2175_I2S_MODE2:
> > + case MAX2175_I2S_MODE4:
> > + max2175_write_bits(ctx, 30, 6, 0, 0);
> > + break;
> > + case MAX2175_I2S_MODE0:
> > + max2175_write_bits(ctx, 30, 6, 0,
> > + ctx->rx_modes[rx_mode].i2s_word_size);
> > + break;
> > + }
> > + mxm_dbg(ctx, "update_i2s_mode %u, rx_mode %u\n", i2s_mode, rx_mode);
> > + return 0;
> > +}
[snip]
> > +
> > +static int max2175_enum_freq_bands(struct v4l2_subdev *sd,
> > + struct v4l2_frequency_band *band) {
> > + struct max2175 *ctx = max2175_from_sd(sd);
> > +
> > + if (band->tuner == 0 && band->index == 0)
> > + *band = *ctx->bands_rf;
> > + else
> > + return -EINVAL;
>
> This is a bit ugly. I would invert the condition and return -EINVAL.
> Then assign *band and return 0.
Agreed.
>
> > +
> > + return 0;
> > +}
> > +
> > +static int max2175_g_tuner(struct v4l2_subdev *sd, struct v4l2_tuner
> > +*vt) {
> > + struct max2175 *ctx = max2175_from_sd(sd);
> > +
> > + if (vt->index > 0)
> > + return -EINVAL;
> > +
> > + strlcpy(vt->name, "RF", sizeof(vt->name));
> > + vt->type = V4L2_TUNER_RF;
> > + vt->capability = V4L2_TUNER_CAP_1HZ | V4L2_TUNER_CAP_FREQ_BANDS;
> > + vt->rangelow = ctx->bands_rf->rangelow;
> > + vt->rangehigh = ctx->bands_rf->rangehigh;
> > + return 0;
> > +}
> > +
> > +static int max2175_s_tuner(struct v4l2_subdev *sd, const struct
> > +v4l2_tuner *vt) {
> > + /* Check tuner index is valid */
> > + if (vt->index > 0)
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > +static const struct v4l2_subdev_tuner_ops max2175_tuner_ops = {
> > + .s_frequency = max2175_s_frequency,
> > + .g_frequency = max2175_g_frequency,
> > + .enum_freq_bands = max2175_enum_freq_bands,
> > + .g_tuner = max2175_g_tuner,
> > + .s_tuner = max2175_s_tuner,
> > +};
> > +
> > +static const struct v4l2_subdev_ops max2175_ops = {
> > + .tuner = &max2175_tuner_ops,
> > +};
> > +
> > +static const struct v4l2_ctrl_ops max2175_ctrl_ops = {
> > + .s_ctrl = max2175_s_ctrl,
> > + .g_volatile_ctrl = max2175_g_volatile_ctrl, };
> > +
> > +static const struct v4l2_ctrl_config max2175_i2s_en = {
> > + .ops = &max2175_ctrl_ops,
> > + .id = V4L2_CID_MAX2175_I2S_ENABLE,
> > + .name = "I2S Enable",
> > + .type = V4L2_CTRL_TYPE_BOOLEAN,
> > + .min = 0,
> > + .max = 1,
> > + .step = 1,
> > + .def = 1,
> > +};
> > +
> > +static const char * const max2175_ctrl_i2s_modes[] = {
> > + [MAX2175_I2S_MODE0] = "i2s mode 0",
> > + [MAX2175_I2S_MODE1] = "i2s mode 1 (skipped)",
> > + [MAX2175_I2S_MODE2] = "i2s mode 2",
> > + [MAX2175_I2S_MODE3] = "i2s mode 3",
> > + [MAX2175_I2S_MODE4] = "i2s mode 4",
> > +};
> > +
> > +static const struct v4l2_ctrl_config max2175_i2s_mode = {
> > + .ops = &max2175_ctrl_ops,
> > + .id = V4L2_CID_MAX2175_I2S_MODE,
> > + .name = "I2S MODE value",
> > + .type = V4L2_CTRL_TYPE_MENU,
> > + .max = ARRAY_SIZE(max2175_ctrl_i2s_modes) - 1,
> > + .def = 0,
> > + .menu_skip_mask = 0x02,
> > + .qmenu = max2175_ctrl_i2s_modes,
> > +};
>
> Is this something that is changed dynamically? It looks more like a device
> tree thing (it's not clear what it does, so obviously I can't be sure).
Yes. It can be changed dynamically.
>
> > +
> > +static const struct v4l2_ctrl_config max2175_hsls = {
> > + .ops = &max2175_ctrl_ops,
> > + .id = V4L2_CID_MAX2175_HSLS,
> > + .name = "HSLS above/below desired",
> > + .type = V4L2_CTRL_TYPE_INTEGER,
> > + .min = 0,
> > + .max = 1,
> > + .step = 1,
> > + .def = 1,
> > +};
> > +
> > +static const char * const max2175_ctrl_eu_rx_modes[] = {
> > + [MAX2175_EU_FM_1_2] = "EU FM 1.2",
> > + [MAX2175_DAB_1_2] = "DAB 1.2",
> > +};
> > +
> > +static const char * const max2175_ctrl_na_rx_modes[] = {
> > + [MAX2175_NA_FM_1_0] = "NA FM 1.0",
> > + [MAX2175_NA_FM_2_0] = "NA FM 2.0",
> > +};
> > +
> > +static const struct v4l2_ctrl_config max2175_eu_rx_mode = {
> > + .ops = &max2175_ctrl_ops,
> > + .id = V4L2_CID_MAX2175_RX_MODE,
> > + .name = "RX MODE",
> > + .type = V4L2_CTRL_TYPE_MENU,
> > + .max = ARRAY_SIZE(max2175_ctrl_eu_rx_modes) - 1,
> > + .def = 0,
> > + .qmenu = max2175_ctrl_eu_rx_modes,
> > +};
> > +
> > +static const struct v4l2_ctrl_config max2175_na_rx_mode = {
> > + .ops = &max2175_ctrl_ops,
> > + .id = V4L2_CID_MAX2175_RX_MODE,
> > + .name = "RX MODE",
> > + .type = V4L2_CTRL_TYPE_MENU,
> > + .max = ARRAY_SIZE(max2175_ctrl_na_rx_modes) - 1,
> > + .def = 0,
> > + .qmenu = max2175_ctrl_na_rx_modes,
> > +};
>
> Please document all these controls better. This is part of the public API,
> so you need to give more information what this means exactly.
Thanks. Now, I have added a one-liner and a bit descriptive explanation at Documentation/media/v4l-drivers dir as you & Laurent concluded.
Thanks,
Ramesh
^ permalink raw reply
* Re: [PATCH v2 02/11] soc: renesas: rcar-sysc: add R8A7745 support
From: Rob Herring @ 2016-11-14 15:54 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: horms, linux-renesas-soc, mark.rutland, devicetree
In-Reply-To: <1834171.PEVAvqbuLx@wasted.cogentembedded.com>
On Sat, Nov 05, 2016 at 12:46:13AM +0300, Sergei Shtylyov wrote:
> Add support for RZ/G1E (R8A7745) SoC power areas to the R-Car SYSC driver.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> ---
> Changes in version 2:
> - added Geert's tag.
>
> Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt | 1
Acked-by: Rob Herring <robh@kernel.org>
> drivers/soc/renesas/Makefile | 1
> drivers/soc/renesas/r8a7745-sysc.c | 32 ++++++++++
> drivers/soc/renesas/rcar-sysc.c | 3
> drivers/soc/renesas/rcar-sysc.h | 1
> 5 files changed, 38 insertions(+)
^ permalink raw reply
* Re: [PATCH v2 03/11] ARM: shmobile: r8a7745: basic SoC support
From: Rob Herring @ 2016-11-14 15:55 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: horms-/R6kz+dDXgpPR4JQBCEnsQ,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w, linux-lFZ/pmaqli7XmaaqVzeoHQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1611958.qRQu5pdJd3-gHKXc3Y1Z8zGSmamagVegGFoWSdPRAKMAL8bYrjMMd8@public.gmane.org>
On Sat, Nov 05, 2016 at 12:49:55AM +0300, Sergei Shtylyov wrote:
> Add minimal support for the RZ/G1E (R8A7745) SoC.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
>
> ---
> Changes in version 2:
> - added Geert's tag;
> - refreshed the patch.
>
> Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
> arch/arm/mach-shmobile/Kconfig | 4 ++++
> arch/arm/mach-shmobile/setup-rcar-gen2.c | 1 +
> 3 files changed, 7 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 09/11] ARM: shmobile: document SK-RZG1E board
From: Rob Herring @ 2016-11-14 15:56 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: horms, linux-renesas-soc, mark.rutland, devicetree
In-Reply-To: <4775558.KSi1d1GNCP@wasted.cogentembedded.com>
On Sat, Nov 05, 2016 at 01:02:25AM +0300, Sergei Shtylyov wrote:
> Document the SK-RZG1E device tree bindings, listing it as a supported board.
>
> This allows to use checkpatch.pl to validate .dts files referring to the
> SK-RZG1E board.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> ---
> Changes in version 2:
> - fixed the subject;
> - added Geert's tag.
>
> Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ 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