* [PATCH v3 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Michel Pollet @ 2018-05-24 10:30 UTC (permalink / raw)
To: linux-renesas-soc, Simon Horman
Cc: phil.edworthy, Michel Pollet, Michel Pollet, Rob Herring,
Mark Rutland, Magnus Damm, Russell King, Chen-Yu Tsai,
Greg Kroah-Hartman, Kevin Hilman, Stefan Wahren, Rajendra Nayak,
Andreas Färber, Juri Lelli, Florian Fainelli, Frank Rowand,
Carlo Caione, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1527157834-7747-1-git-send-email-michel.pollet@bp.renesas.com>
The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time, it
requires a special enable method to get it started.
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
---
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/smp-r9a06g032.c | 85 ++++++++++++++++++++++++++++++++++
2 files changed, 86 insertions(+)
create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 1939f52..d7fc98f 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0) += smp-sh73a0.o headsmp-scu.o platsmp-scu.o
smp-$(CONFIG_ARCH_R8A7779) += smp-r8a7779.o headsmp-scu.o platsmp-scu.o
smp-$(CONFIG_ARCH_R8A7790) += smp-r8a7790.o
smp-$(CONFIG_ARCH_R8A7791) += smp-r8a7791.o
+smp-$(CONFIG_ARCH_R9A06G032) += smp-r9a06g032.o
smp-$(CONFIG_ARCH_EMEV2) += smp-emev2.o headsmp-scu.o platsmp-scu.o
# PM objects
diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c b/arch/arm/mach-shmobile/smp-r9a06g032.c
new file mode 100644
index 0000000..a536e89
--- /dev/null
+++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RZ/N1D Second CA7 enabler.
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
+ * Derived from action,s500-smp
+ */
+
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/smp.h>
+#include <asm/cacheflush.h>
+#include <asm/smp_plat.h>
+#include <asm/smp_scu.h>
+
+/*
+ * The second CPU is parked in ROM at boot time. It requires waking it after
+ * writing an address into the BOOTADDR register of sysctrl.
+ *
+ * So the default value of the "cpu-release-addr" corresponds to BOOTADDR...
+ *
+ * *However* the BOOTADDR register is not available when the kernel
+ * starts in NONSEC mode.
+ *
+ * So for NONSEC mode, the bootloader re-parks the second CPU into a pen
+ * in SRAM, and changes the "cpu-release-addr" of linux's DT to a SRAM address,
+ * which is not restricted.
+ */
+
+static void __iomem *cpu_bootaddr;
+
+static DEFINE_SPINLOCK(cpu_lock);
+
+static int rzn1_smp_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+ if (!cpu_bootaddr)
+ return -ENODEV;
+
+ spin_lock(&cpu_lock);
+
+ writel(__pa_symbol(secondary_startup), cpu_bootaddr);
+ arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+
+ spin_unlock(&cpu_lock);
+
+ return 0;
+}
+
+static void __init rzn1_smp_prepare_cpus(unsigned int max_cpus)
+{
+ struct device_node *dn;
+ int ret;
+ u32 bootaddr;
+
+ dn = of_get_cpu_node(1, NULL);
+ if (!dn) {
+ pr_err("CPU#1: missing device tree node\n");
+ return;
+ }
+ /*
+ * Determine the address from which the CPU is polling.
+ * The bootloader *does* change this property
+ */
+ ret = of_property_read_u32(dn, "cpu-release-addr", &bootaddr);
+ of_node_put(dn);
+ if (ret) {
+ pr_err("CPU#1: invalid cpu-release-addr property\n");
+ return;
+ }
+ pr_info("CPU#1: cpu-release-addr %08x\n", (u32)bootaddr);
+
+ cpu_bootaddr = ioremap(bootaddr, sizeof(bootaddr));
+ if (!cpu_bootaddr)
+ pr_err("CPU#1: cpu-release-addr map failed\n");
+}
+
+static const struct smp_operations rzn1_smp_ops __initconst = {
+ .smp_prepare_cpus = rzn1_smp_prepare_cpus,
+ .smp_boot_secondary = rzn1_smp_boot_secondary,
+};
+CPU_METHOD_OF_DECLARE(rzn1_smp, "renesas,r9a06g032-smp", &rzn1_smp_ops);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/3] dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method.
From: Michel Pollet @ 2018-05-24 10:30 UTC (permalink / raw)
To: linux-renesas-soc, Simon Horman
Cc: phil.edworthy, Michel Pollet, Michel Pollet, Rob Herring,
Mark Rutland, Magnus Damm, Russell King, Douglas Anderson,
Greg Kroah-Hartman, Chen-Yu Tsai, Florian Fainelli, Stefan Wahren,
Andreas Färber, Frank Rowand, Juri Lelli, Carlo Caione,
Rajendra Nayak, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1527157834-7747-1-git-send-email-michel.pollet@bp.renesas.com>
Add a special enable method for second CA7 of the R9A06G032
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 29e1dc5..b395d107 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -219,6 +219,7 @@ described below.
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
"renesas,apmu"
+ "renesas,r9a06g032-smp"
"rockchip,rk3036-smp"
"rockchip,rk3066-smp"
"ste,dbx500-smp"
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/3] Renesas R9A06G032 SMP enabler
From: Michel Pollet @ 2018-05-24 10:30 UTC (permalink / raw)
To: linux-renesas-soc, Simon Horman
Cc: phil.edworthy, Michel Pollet, Michel Pollet, Rob Herring,
Mark Rutland, Magnus Damm, Russell King, Carlo Caione,
Stefan Wahren, Martin Blumenstingl, Maxime Ripard,
Andreas Färber, Rajendra Nayak, Florian Fainelli, Juri Lelli,
Frank Rowand, devicetree, linux-kernel, linux-arm-kernel
*WARNING -- this requires the base R9A06G032 support patches
already posted
This patch series is for enabling the second CA7 of the R9A06G032.
It's based on a spin_table method, and it reuses the same binding
property as that driver.
v3:
+ Removed mentions of rz/?n1d?
+ Rebased on base patch v7
v2:
+ Added suggestions from Florian Fainelli
+ Use __pa_symbol()
+ Simplified logic in prepare_cpu()
+ Reordered the patches
+ Rebased on RZN1 Base patch v5
Michel Pollet (3):
dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method.
arm: shmobile: Add the R9A06G032 SMP enabler driver
ARM: dts: Renesas R9A06G032 SMP enable method
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/boot/dts/r9a06g032.dtsi | 2 +
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/smp-r9a06g032.c | 85 ++++++++++++++++++++++++++
4 files changed, 89 insertions(+)
create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
--
2.7.4
^ permalink raw reply
* Re: [PATCH RFC 00/24] Lima DRM driver
From: Christian König @ 2018-05-24 9:53 UTC (permalink / raw)
To: Daniel Vetter
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Qiang Yu, Erico Nunes
In-Reply-To: <CAKMK7uFHpX12RKJewZmSBnTgpcAvr9OpLgyYL__RGQW7vqkJYQ@mail.gmail.com>
Am 24.05.2018 um 09:25 schrieb Daniel Vetter:
> [SNIP]
>>> Does virtio drm driver need to move buffers around? amdgpu also
>>> has no vram when APU.
> Afaiui APUs have a range of stolen memory which looks and acts and is
> managed like discrete vram. Including moving buffers around.
BTW: We are actually working on getting rid of that. E.g. the only thing
modern APUs need this stolen VRAM for are page tables, and it's just a
matter of my time to fix this.
>>>> From your description you don't have such a requirement, and
>>>> then doing what etnaviv has done would be a lot simpler. Everything
>>>> that's not related to buffer movement handling is also available
>>>> outside of ttm already.
>>> Yeah, I could do like etnaviv, but it's not simpler than using ttm
>>> directly especially want some optimization (like ttm page pool,
>>> ttm_eu_reserve_buffers, ttm_bo_mmap). If I have/want to implement
>>> them, why not just use TTM directly with all those helper functions.
>>
>> Well TTM has some design flaws (e.g. heavily layered design etc...), but it
>> also offers some rather nice functionality.
> Yeah, but I still think that for non-discrete drivers just moving a
> bunch of more of the neat ttm functionality into helpers where
> everyone can use them (instead of the binary ttm y/n decision) would
> be much better. E.g. the allocator pool definitely sounds like
> something gem helpers should be able to do, same for reserving a pile
> of buffers or default mmap implementations. A lot of that also exists
> already, thanks to lots of efforts from Noralf Tronnes and others.
>
> I think ideally the long-term goal would be to modularize ttm concepts
> as much as possible, so that drivers can flexibly pick&choose the bits
> they need. We're slowly getting there (but definitely not yet there if
> you need to manage discrete vram I think).
Yes, completely agree. It's just that nobody had time for that.
Especially the different memory pools should be cleaned up and moved
into a common DRM functionality or even into the DMA or directly the MM
subsystem.
E.g. an interface like: I'm device X and need memory which is
cached/uncached/wc please allocate something for me.
Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers"
From: Christian König @ 2018-05-24 9:41 UTC (permalink / raw)
To: Qiang Yu
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Erico Nunes
In-Reply-To: <CAKGbVbttv2zJBaif2EVvqVFQo-xPM+x9hD6X5Lon-bNCNny01A@mail.gmail.com>
Am 24.05.2018 um 11:24 schrieb Qiang Yu:
> On Thu, May 24, 2018 at 2:46 PM, Christian König
> <christian.koenig@amd.com> wrote:
> [SNIP]
>> Because of this we have a separate tracking in amdgpu so that we not only
>> know who is using which BO, who is using which VM.
> amdgpu's VM implementation seems too complicated for this simple mali GPU,
> but I may investigate it more to see if I can make it better.
Yeah, completely agree.
The VM handling in amdgpu is really complicated because we had to tune
it for multiple use cases. E.g. partial resident textures, delayed
updates etc etc....
But you should at least be able to take the lessons learned we had with
that VM code and not make the same mistakes again.
>> We intentionally removed the preclose callback to prevent certain use cases,
>> bringing it back to allow your use case looks rather fishy to me.
> Seems other drivers do either the deffer or wait way to adopt the drop
> of preclose. I can do the same as you suggested, but just not understand why
> we make our life harder. Can I know what's the case you want to prevent?
I think what matters most for your case is the issue is that drivers
should handle closing a BO because userspace said so in the same way it
handles closing a BO because of a process termination, but see below.
>> BTW: What exactly is the issue with using the postclose callback?
> The issue is, when Ctrl+C to terminate an application, if no wait or deffer
> unmap, buffer just gets unmapped before task is done, so kernel driver
> gets MMU fault and HW reset to recover the GPU.
Yeah, that sounds like exactly one of the reasons we had the callback in
the first place and worked on to removing it.
See the intention is to have reliable handling, e.g. use the same code
path for closing a BO because of an IOCTL and closing a BO because of
process termination.
In other words what happens when userspace closes a BO while the GPU is
still using it? Would you then run into a GPU reset as well?
I mean it's your driver stack, so I'm not against it as long as you can
live with it. But it's exactly the thing we wanted to avoid here.
Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v11 1/2] cpufreq: Add Kryo CPU scaling driver
From: Sudeep Holla @ 2018-05-24 9:37 UTC (permalink / raw)
To: Viresh Kumar
Cc: Ilia Lin, vireshk, nm, sboyd, robh, mark.rutland, rjw, linux-pm,
devicetree, linux-kernel, Sudeep Holla
In-Reply-To: <20180524043443.adivshl2un53n6hm@vireshk-i7>
On Thu, May 24, 2018 at 10:04:43AM +0530, Viresh Kumar wrote:
> On 23-05-18, 14:25, Sudeep Holla wrote:
> > On 23/05/18 13:38, Ilia Lin wrote:
> > > +config ARM_QCOM_CPUFREQ_KRYO
> > > + bool "Qualcomm Kryo based CPUFreq"
> > > + depends on QCOM_QFPROM
> > > + depends on QCOM_SMEM
> > > + select PM_OPP
> > > + help
> > > + This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
> > > +
> > > + If in doubt, say N.
> > > +
> >
> > Sorry but just noticed now, any reason why this can't be module. I can't
> > imagine any.
>
> Actually I asked him to do that as cpufreq-dt itself can be compiled
> in as module and this driver wasn't doing much and isn't big enough
> (size wise) as well.
>
Initially I guessed that to be the reason, but not prevents this to be a
module. But you are right, the gain is not much as this driver is quite
small on it's own.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH net-next v3 0/7] Add support for QCA8334 switch
From: Michal Vokáč @ 2018-05-24 9:34 UTC (permalink / raw)
To: Florian Fainelli, andrew
Cc: netdev, linux-kernel, devicetree, vivien.didelot, mark.rutland,
robh+dt, davem, michal.vokac
In-Reply-To: <29ea7cdd-5690-e39a-a2ef-4f48fbcb7659@gmail.com>
On 23.5.2018 17:39, Florian Fainelli wrote:
>
>
> On 05/22/2018 11:20 PM, Michal Vokáč wrote:
>> This series basically adds support for a QCA8334 ethernet switch to the
>> qca8k driver. It is a four-port variant of the already supported seven
>> port QCA8337. Register map is the same for the whole familly and all chips
>> have the same device ID.
>>
>> Major part of this series enhances the CPU port setting. Currently the CPU
>> port is not set to any sensible defaults compatible with the xGMII
>> interface. This series forces the CPU port to its maximum bandwidth and
>> also allows to adjust the new defaults using fixed-link device tree
>> sub-node.
>>
>> Alongside these changes I fixed two checkpatch warnings regarding SPDX and
>> redundant parentheses.
>
> Looks great, thanks Michal! Do you have any features or things you are
> working on that would be added later to the driver?
Thank you too Florian. And also big thank to you Andrew. You helped me
a lot to debug the RGMII issue. I have been stuck at that for more than
a month and would not resolve it without your help.
As I have done this in a process of upgrading our BSP to a more recent
kernel, and hopefully mainline, I now need to move on to other parts of
the board. So unfortunately no, I do not have any other enhancements
planned to this driver for now. But as we are probably one of the few
with access to the NDA covered Qualcomm documentation I see a great
opportunity to work on that later. I am afraid "later" means something
like next year in this case as I am basically the only kernel developer
in our company and not yet very experienced.
Thank you all for your time,
Michal
^ permalink raw reply
* Re: [PATCH v7 2/4] ARM: dts: tegra: Fix unit_address_vs_reg DTC warnings for /memory
From: Stefan Agner @ 2018-05-24 9:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Mark Rutland, Thierry Reding, Jonathan Hunter,
devicetree, linux-tegra, linux-kernel, Marcel Ziswiler,
Lucas Stach
In-Reply-To: <1527144833-24285-2-git-send-email-krzk@kernel.org>
On 24.05.2018 08:53, Krzysztof Kozlowski wrote:
> Add a generic /memory node in each Tegra DTSI (with empty reg property,
> to be overidden by each DTS) and set proper unit address for /memory
> nodes to fix the DTC warnings:
>
> arch/arm/boot/dts/tegra20-harmony.dtb: Warning (unit_address_vs_reg):
> /memory: node has a reg or ranges property, but no unit name
>
> The DTB after the change is the same as before except adding
> unit-address to /memory node.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
Looks good to me! Thanks!
Reviewed-by: Stefan Agner <stefan@agner.ch>
--
Stefan
> ---
>
> Changes since v6:
> 1. Fix unit addresses for tegra124 and minor nits (suggested by Stefan).
>
> Changes since v5:
> 1. Split with skeleton.dtsi removal (suggested by Stefan).
>
> Changes since v4:
> 1. None
> ---
> arch/arm/boot/dts/tegra114-dalmore.dts | 2 +-
> arch/arm/boot/dts/tegra114-roth.dts | 2 +-
> arch/arm/boot/dts/tegra114-tn7.dts | 2 +-
> arch/arm/boot/dts/tegra114.dtsi | 3 ++-
> arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi | 2 +-
> arch/arm/boot/dts/tegra124-apalis.dtsi | 2 +-
> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 2 +-
> arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
> arch/arm/boot/dts/tegra124-venice2.dts | 2 +-
> arch/arm/boot/dts/tegra124.dtsi | 3 ++-
> arch/arm/boot/dts/tegra20-colibri-512.dtsi | 2 +-
> arch/arm/boot/dts/tegra20-harmony.dts | 2 +-
> arch/arm/boot/dts/tegra20-paz00.dts | 2 +-
> arch/arm/boot/dts/tegra20-seaboard.dts | 2 +-
> arch/arm/boot/dts/tegra20-tamonten.dtsi | 2 +-
> arch/arm/boot/dts/tegra20-trimslice.dts | 2 +-
> arch/arm/boot/dts/tegra20-ventana.dts | 2 +-
> arch/arm/boot/dts/tegra20.dtsi | 3 ++-
> arch/arm/boot/dts/tegra30-apalis.dtsi | 4 ++--
> arch/arm/boot/dts/tegra30-beaver.dts | 2 +-
> arch/arm/boot/dts/tegra30-cardhu.dtsi | 2 +-
> arch/arm/boot/dts/tegra30-colibri.dtsi | 2 +-
> arch/arm/boot/dts/tegra30.dtsi | 3 ++-
> 23 files changed, 28 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
> b/arch/arm/boot/dts/tegra114-dalmore.dts
> index eafff16765b4..1788556b4977 100644
> --- a/arch/arm/boot/dts/tegra114-dalmore.dts
> +++ b/arch/arm/boot/dts/tegra114-dalmore.dts
> @@ -23,7 +23,7 @@
> stdout-path = "serial0:115200n8";
> };
>
> - memory {
> + memory@80000000 {
> reg = <0x80000000 0x40000000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra114-roth.dts
> b/arch/arm/boot/dts/tegra114-roth.dts
> index 7ed7370ee67a..3d3835591cd2 100644
> --- a/arch/arm/boot/dts/tegra114-roth.dts
> +++ b/arch/arm/boot/dts/tegra114-roth.dts
> @@ -28,7 +28,7 @@
> };
> };
>
> - memory {
> + memory@80000000 {
> /* memory >= 0x79600000 is reserved for firmware usage */
> reg = <0x80000000 0x79600000>;
> };
> diff --git a/arch/arm/boot/dts/tegra114-tn7.dts
> b/arch/arm/boot/dts/tegra114-tn7.dts
> index 7fc4a8b31e45..bfdd1bf61816 100644
> --- a/arch/arm/boot/dts/tegra114-tn7.dts
> +++ b/arch/arm/boot/dts/tegra114-tn7.dts
> @@ -28,7 +28,7 @@
> };
> };
>
> - memory {
> + memory@80000000 {
> /* memory >= 0x37e00000 is reserved for firmware usage */
> reg = <0x80000000 0x37e00000>;
> };
> diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
> index 27ef515e5640..85488a150701 100644
> --- a/arch/arm/boot/dts/tegra114.dtsi
> +++ b/arch/arm/boot/dts/tegra114.dtsi
> @@ -11,8 +11,9 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - memory {
> + memory@80000000 {
> device_type = "memory";
> + reg = <0x80000000 0x0>;
> };
>
> host1x@50000000 {
> diff --git a/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
> b/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
> index bb67edb016c5..acb5b379e896 100644
> --- a/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
> +++ b/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
> @@ -15,7 +15,7 @@
> compatible = "toradex,apalis-tk1-v1.2", "toradex,apalis-tk1",
> "nvidia,tegra124";
>
> - memory {
> + memory@80000000 {
> reg = <0x0 0x80000000 0x0 0x80000000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi
> b/arch/arm/boot/dts/tegra124-apalis.dtsi
> index 65a2161b9b8e..08518e424448 100644
> --- a/arch/arm/boot/dts/tegra124-apalis.dtsi
> +++ b/arch/arm/boot/dts/tegra124-apalis.dtsi
> @@ -50,7 +50,7 @@
> model = "Toradex Apalis TK1";
> compatible = "toradex,apalis-tk1", "nvidia,tegra124";
>
> - memory {
> + memory@80000000 {
> reg = <0x0 0x80000000 0x0 0x80000000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
> b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
> index 6dbcf84dafbc..9151b3ebb839 100644
> --- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
> +++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
> @@ -24,7 +24,7 @@
> stdout-path = "serial0:115200n8";
> };
>
> - memory {
> + memory@80000000 {
> reg = <0x0 0x80000000 0x0 0x80000000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra124-nyan.dtsi
> b/arch/arm/boot/dts/tegra124-nyan.dtsi
> index 3609367037a6..d5f11d6d987e 100644
> --- a/arch/arm/boot/dts/tegra124-nyan.dtsi
> +++ b/arch/arm/boot/dts/tegra124-nyan.dtsi
> @@ -13,7 +13,7 @@
> stdout-path = "serial0:115200n8";
> };
>
> - memory {
> + memory@80000000 {
> reg = <0x0 0x80000000 0x0 0x80000000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts
> b/arch/arm/boot/dts/tegra124-venice2.dts
> index 89bcc178994d..82d139648ef1 100644
> --- a/arch/arm/boot/dts/tegra124-venice2.dts
> +++ b/arch/arm/boot/dts/tegra124-venice2.dts
> @@ -18,7 +18,7 @@
> stdout-path = "serial0:115200n8";
> };
>
> - memory {
> + memory@80000000 {
> reg = <0x0 0x80000000 0x0 0x80000000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
> index 951feea784af..183c5acafb22 100644
> --- a/arch/arm/boot/dts/tegra124.dtsi
> +++ b/arch/arm/boot/dts/tegra124.dtsi
> @@ -13,8 +13,9 @@
> #address-cells = <2>;
> #size-cells = <2>;
>
> - memory {
> + memory@80000000 {
> device_type = "memory";
> + reg = <0x0 0x80000000 0x0 0x0>;
> };
>
> pcie@1003000 {
> diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> index 5c202b3e3bb1..5623ff8d128c 100644
> --- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> +++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> @@ -10,7 +10,7 @@
> rtc1 = "/rtc@7000e000";
> };
>
> - memory {
> + memory@0 {
> reg = <0x00000000 0x20000000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra20-harmony.dts
> b/arch/arm/boot/dts/tegra20-harmony.dts
> index 628a55a9318b..1d96d92b72a7 100644
> --- a/arch/arm/boot/dts/tegra20-harmony.dts
> +++ b/arch/arm/boot/dts/tegra20-harmony.dts
> @@ -18,7 +18,7 @@
> stdout-path = "serial0:115200n8";
> };
>
> - memory {
> + memory@0 {
> reg = <0x00000000 0x40000000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
> b/arch/arm/boot/dts/tegra20-paz00.dts
> index 30436969adc0..ef245291924f 100644
> --- a/arch/arm/boot/dts/tegra20-paz00.dts
> +++ b/arch/arm/boot/dts/tegra20-paz00.dts
> @@ -19,7 +19,7 @@
> stdout-path = "serial0:115200n8";
> };
>
> - memory {
> + memory@0 {
> reg = <0x00000000 0x20000000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts
> b/arch/arm/boot/dts/tegra20-seaboard.dts
> index 284aae351ff2..f91441683aad 100644
> --- a/arch/arm/boot/dts/tegra20-seaboard.dts
> +++ b/arch/arm/boot/dts/tegra20-seaboard.dts
> @@ -18,7 +18,7 @@
> stdout-path = "serial0:115200n8";
> };
>
> - memory {
> + memory@0 {
> reg = <0x00000000 0x40000000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi
> b/arch/arm/boot/dts/tegra20-tamonten.dtsi
> index 872046d48709..20137fc578b1 100644
> --- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
> +++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
> @@ -15,7 +15,7 @@
> stdout-path = "serial0:115200n8";
> };
>
> - memory {
> + memory@0 {
> reg = <0x00000000 0x20000000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts
> b/arch/arm/boot/dts/tegra20-trimslice.dts
> index d55c6b240a30..9eb26dc15f6b 100644
> --- a/arch/arm/boot/dts/tegra20-trimslice.dts
> +++ b/arch/arm/boot/dts/tegra20-trimslice.dts
> @@ -18,7 +18,7 @@
> stdout-path = "serial0:115200n8";
> };
>
> - memory {
> + memory@0 {
> reg = <0x00000000 0x40000000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra20-ventana.dts
> b/arch/arm/boot/dts/tegra20-ventana.dts
> index ee3fbf941e79..f44551e2d9d0 100644
> --- a/arch/arm/boot/dts/tegra20-ventana.dts
> +++ b/arch/arm/boot/dts/tegra20-ventana.dts
> @@ -18,7 +18,7 @@
> stdout-path = "serial0:115200n8";
> };
>
> - memory {
> + memory@0 {
> reg = <0x00000000 0x40000000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
> index 88dd1afb5877..55581c0e5105 100644
> --- a/arch/arm/boot/dts/tegra20.dtsi
> +++ b/arch/arm/boot/dts/tegra20.dtsi
> @@ -13,8 +13,9 @@
> chosen { };
> aliases { };
>
> - memory {
> + memory@0 {
> device_type = "memory";
> + reg = <0 0>;
> };
>
> iram@40000000 {
> diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi
> b/arch/arm/boot/dts/tegra30-apalis.dtsi
> index 6f29cbad6e8a..9465fc592b7b 100644
> --- a/arch/arm/boot/dts/tegra30-apalis.dtsi
> +++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
> @@ -10,8 +10,8 @@
> model = "Toradex Apalis T30";
> compatible = "toradex,apalis_t30", "nvidia,tegra30";
>
> - memory {
> - reg = <0 0>;
> + memory@80000000 {
> + reg = <0x80000000 0x40000000>;
> };
>
> pcie@3000 {
> diff --git a/arch/arm/boot/dts/tegra30-beaver.dts
> b/arch/arm/boot/dts/tegra30-beaver.dts
> index ae52a5039506..1434d50438f9 100644
> --- a/arch/arm/boot/dts/tegra30-beaver.dts
> +++ b/arch/arm/boot/dts/tegra30-beaver.dts
> @@ -17,7 +17,7 @@
> stdout-path = "serial0:115200n8";
> };
>
> - memory {
> + memory@80000000 {
> reg = <0x80000000 0x7ff00000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi
> b/arch/arm/boot/dts/tegra30-cardhu.dtsi
> index 92a9740c533f..33b73dca16a3 100644
> --- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
> +++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
> @@ -40,7 +40,7 @@
> stdout-path = "serial0:115200n8";
> };
>
> - memory {
> + memory@80000000 {
> reg = <0x80000000 0x40000000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra30-colibri.dtsi
> b/arch/arm/boot/dts/tegra30-colibri.dtsi
> index c44d8c40c410..9bf3327665d3 100644
> --- a/arch/arm/boot/dts/tegra30-colibri.dtsi
> +++ b/arch/arm/boot/dts/tegra30-colibri.dtsi
> @@ -10,7 +10,7 @@
> model = "Toradex Colibri T30";
> compatible = "toradex,colibri_t30", "nvidia,tegra30";
>
> - memory {
> + memory@80000000 {
> reg = <0x80000000 0x40000000>;
> };
>
> diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
> index 19237c08c166..bc42f791d791 100644
> --- a/arch/arm/boot/dts/tegra30.dtsi
> +++ b/arch/arm/boot/dts/tegra30.dtsi
> @@ -14,8 +14,9 @@
> chosen { };
> aliases { };
>
> - memory {
> + memory@80000000 {
> device_type = "memory";
> + reg = <0x80000000 0x0>;
> };
>
> pcie@3000 {
^ permalink raw reply
* Re: [PATCH v7 4/4] ARM: dts: tegra: Work safely with 256 MB Colibri-T20 modules
From: Stefan Agner @ 2018-05-24 9:29 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Mark Rutland, Thierry Reding, Jonathan Hunter,
devicetree, linux-tegra, linux-kernel, Marcel Ziswiler,
Lucas Stach
In-Reply-To: <1527144833-24285-4-git-send-email-krzk@kernel.org>
On 24.05.2018 08:53, Krzysztof Kozlowski wrote:
> Colibri-T20 can come in 256 MB RAM (with 512 MB NAND) or 512 MB RAM
> (with 1024 MB NAND) flavors. Both of them will use the same DTSI
> expecting the bootloader to do the fixup of /memory node. However in
> case it does not happen, let's stay on safe side by limiting the memory
> to 256 MB for both versions of Colibri-T20.
>
> Rename to remove the unnecessary memory size from the device tree file
> name. While at it, also follow the typical Toradex SoC, module, carrier
> board hierarchy.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
That looks good!
Reviewed-by: Stefan Agner <stefan@agner.ch>
Also works fine with full memory available on a 512MiB Colibri T20 using
downstream U-Boot 2016.11.
Tested-by: Stefan Agner <stefan@agner.ch>
--
Stefan
>
> ---
>
> RFT:
> Not tested on 512 MB module as I have only the 256 MB one.
>
> Changes since v6:
> 1. Only adjust commit msg.
>
> Changes since v5:
> 1. Add "colibri" suffix to iris DTS (suggested by Stefan).
>
> Changes since v4:
> 1. Drop the 512 suffix from file names (suggested by Stefan).
>
> Changes since v3:
> 1. Reduce the memory in existing DTSI instead of creating a new one
> (suggested by Marcel).
>
> Changes since v2:
> 1. Do not add new compatible but use everywhere existing
> "toradex,colibri_t20-512" (suggested by Rob).
>
> Changes since v1:
> 1. Fix memory size in tegra20-colibri-256.dtsi (was working fine because
> my bootloader uses mem= argument).
> ---
> arch/arm/boot/dts/Makefile | 2 +-
> .../boot/dts/{tegra20-iris-512.dts => tegra20-colibri-iris.dts} | 4 ++--
> .../boot/dts/{tegra20-colibri-512.dtsi => tegra20-colibri.dtsi} | 9 +++++++--
> 3 files changed, 10 insertions(+), 5 deletions(-)
> rename arch/arm/boot/dts/{tegra20-iris-512.dts =>
> tegra20-colibri-iris.dts} (95%)
> rename arch/arm/boot/dts/{tegra20-colibri-512.dtsi =>
> tegra20-colibri.dtsi} (98%)
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ec2024ea8b1e..1c8bb55c0948 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1030,7 +1030,7 @@ dtb-$(CONFIG_ARCH_TANGO) += \
> tango4-vantage-1172.dtb
> dtb-$(CONFIG_ARCH_TEGRA_2x_SOC) += \
> tegra20-harmony.dtb \
> - tegra20-iris-512.dtb \
> + tegra20-colibri-iris.dtb \
> tegra20-medcom-wide.dtb \
> tegra20-paz00.dtb \
> tegra20-plutux.dtb \
> diff --git a/arch/arm/boot/dts/tegra20-iris-512.dts
> b/arch/arm/boot/dts/tegra20-colibri-iris.dts
> similarity index 95%
> rename from arch/arm/boot/dts/tegra20-iris-512.dts
> rename to arch/arm/boot/dts/tegra20-colibri-iris.dts
> index 40126388946d..57f16c0e9917 100644
> --- a/arch/arm/boot/dts/tegra20-iris-512.dts
> +++ b/arch/arm/boot/dts/tegra20-colibri-iris.dts
> @@ -1,10 +1,10 @@
> // SPDX-License-Identifier: GPL-2.0
> /dts-v1/;
>
> -#include "tegra20-colibri-512.dtsi"
> +#include "tegra20-colibri.dtsi"
>
> / {
> - model = "Toradex Colibri T20 512MB on Iris";
> + model = "Toradex Colibri T20 256/512 MB on Iris";
> compatible = "toradex,iris", "toradex,colibri_t20-512", "nvidia,tegra20";
>
> aliases {
> diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> b/arch/arm/boot/dts/tegra20-colibri.dtsi
> similarity index 98%
> rename from arch/arm/boot/dts/tegra20-colibri-512.dtsi
> rename to arch/arm/boot/dts/tegra20-colibri.dtsi
> index 5623ff8d128c..dc06b23183e1 100644
> --- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> +++ b/arch/arm/boot/dts/tegra20-colibri.dtsi
> @@ -2,7 +2,7 @@
> #include "tegra20.dtsi"
>
> / {
> - model = "Toradex Colibri T20 512MB";
> + model = "Toradex Colibri T20 256/512 MB";
> compatible = "toradex,colibri_t20-512", "nvidia,tegra20";
>
> aliases {
> @@ -11,7 +11,12 @@
> };
>
> memory@0 {
> - reg = <0x00000000 0x20000000>;
> + /*
> + * Set memory to 256 MB to be safe as this could be used on
> + * 256 or 512 MB module. It is expected from bootloader
> + * to fix this up for 512 MB version.
> + */
> + reg = <0x00000000 0x10000000>;
> };
>
> host1x@50000000 {
^ permalink raw reply
* [PATCH v7 5/5] clk: renesas: Renesas R9A06G032 clock driver
From: Michel Pollet @ 2018-05-24 9:28 UTC (permalink / raw)
To: linux-renesas-soc, Simon Horman
Cc: phil.edworthy, Michel Pollet, Michel Pollet, Michael Turquette,
Stephen Boyd, Rob Herring, Mark Rutland, Geert Uytterhoeven,
linux-clk, devicetree, linux-kernel
In-Reply-To: <1527154169-32380-1-git-send-email-michel.pollet@bp.renesas.com>
This provides a clock driver for the Renesas R09A06G032.
This uses a structure derived from both the RCAR gen2 driver as well as
the renesas-cpg-mssr driver.
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
---
drivers/clk/renesas/Kconfig | 6 +
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r9a06g032-clocks.c | 812 +++++++++++++++++++++++++++++++++
3 files changed, 819 insertions(+)
create mode 100644 drivers/clk/renesas/r9a06g032-clocks.c
diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
index f9ba71311..9022bbe 100644
--- a/drivers/clk/renesas/Kconfig
+++ b/drivers/clk/renesas/Kconfig
@@ -21,6 +21,7 @@ config CLK_RENESAS
select CLK_R8A77980 if ARCH_R8A77980
select CLK_R8A77990 if ARCH_R8A77990
select CLK_R8A77995 if ARCH_R8A77995
+ select CLK_R9A06G032 if ARCH_R9A06G032
select CLK_SH73A0 if ARCH_SH73A0
if CLK_RENESAS
@@ -125,6 +126,11 @@ config CLK_R8A77995
bool "R-Car D3 clock support" if COMPILE_TEST
select CLK_RCAR_GEN3_CPG
+config CLK_R9A06G032
+ bool "Renesas R9A06G032 clock driver"
+ help
+ This is a driver for R9A06G032 clocks
+
config CLK_SH73A0
bool "SH-Mobile AG5 clock support" if COMPILE_TEST
select CLK_RENESAS_CPG_MSTP
diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile
index fe5bac9..e4aa3d6 100644
--- a/drivers/clk/renesas/Makefile
+++ b/drivers/clk/renesas/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_CLK_R8A77970) += r8a77970-cpg-mssr.o
obj-$(CONFIG_CLK_R8A77980) += r8a77980-cpg-mssr.o
obj-$(CONFIG_CLK_R8A77990) += r8a77990-cpg-mssr.o
obj-$(CONFIG_CLK_R8A77995) += r8a77995-cpg-mssr.o
+obj-$(CONFIG_CLK_R9A06G032) += r9a06g032-clocks.o
obj-$(CONFIG_CLK_SH73A0) += clk-sh73a0.o
# Family
diff --git a/drivers/clk/renesas/r9a06g032-clocks.c b/drivers/clk/renesas/r9a06g032-clocks.c
new file mode 100644
index 0000000..ad61cda
--- /dev/null
+++ b/drivers/clk/renesas/r9a06g032-clocks.c
@@ -0,0 +1,812 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * R9A09G032 clock driver
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/math64.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <dt-bindings/clock/r9a06g032-sysctrl.h>
+
+struct r9a06g032_gate {
+ uint16_t gate, reset, ready, midle,
+ scon, mirack, mistat;
+};
+
+/* This is used to describe a clock for instantiation */
+struct r9a06g032_clkdesc {
+ const char *name;
+ uint32_t type: 3;
+ uint32_t index: 8;
+ uint32_t source : 8; /* source index + 1 (0 == none) */
+ /* these are used to populate the bitsel struct */
+ union {
+ struct r9a06g032_gate gate;
+ /* for dividers */
+ struct {
+ unsigned int div_min : 10, div_max : 10, reg: 10;
+ uint16_t div_table[4];
+ };
+ /* For fixed-factor ones */
+ uint16_t div;
+ unsigned int factor;
+ unsigned int frequency;
+ /* for dual gate */
+ struct {
+ uint16_t group : 1, index: 3;
+ uint16_t sel, g1, r1, g2, r2;
+ } dual;
+ };
+} __packed;
+
+#define I_GATE(_clk, _rst, _rdy, _midle, _scon, _mirack, _mistat) \
+ { .gate = _clk, .reset = _rst, \
+ .ready = _rdy, .midle = _midle, \
+ .scon = _scon, .mirack = _mirack, .mistat = _mistat }
+#define D_GATE(_idx, _n, _src, ...) \
+ { .type = K_GATE, .index = R9A06G032_##_idx, \
+ .source = 1 + R9A06G032_##_src, .name = _n, \
+ .gate = I_GATE(__VA_ARGS__), }
+#define D_FC(_idx, _n, _freq) \
+ { .type = K_FC, .index = R9A06G032_##_idx, .name = _n, .frequency = _freq, }
+#define D_FFC(_idx, _n, _src, _div) \
+ { .type = K_FFC, .index = R9A06G032_##_idx, \
+ .source = 1 + R9A06G032_##_src, .name = _n, \
+ .div = _div, }
+#define D_DIV(_idx, _n, _src, _reg, _min, _max, ...) \
+ { .type = K_DIV, .index = R9A06G032_##_idx, \
+ .source = 1 + R9A06G032_##_src, .name = _n, \
+ .reg = _reg, .div_min = _min, .div_max = _max, \
+ .div_table = { __VA_ARGS__ } }
+#define D_UGATE(_idx, _n, _src, _g, _gi, _g1, _r1, _g2, _r2) \
+ { .type = K_DUALGATE, .index = R9A06G032_##_idx, \
+ .source = 1 + R9A06G032_##_src, .name = _n, \
+ .dual = { .group = _g, .index = _gi, \
+ .g1 = _g1, .r1 = _r1, .g2 = _g2, .r2 = _r2 }, }
+
+enum { K_GATE = 0, K_FFC, K_FC, K_DIV, K_BITSEL, K_DUALGATE };
+
+static const struct r9a06g032_clkdesc r9a06g032_clocks[] __initconst = {
+ D_FC(CLKOUT, "clkout", 1000000000),
+ D_FC(CLK_PLL_USB, "clk_pll_usb", 48000000),
+ D_FFC(CLKOUT_D10, "clkout_d10", CLKOUT, 10),
+ D_FFC(CLKOUT_D16, "clkout_d16", CLKOUT, 16),
+ D_FFC(CLKOUT_D160, "clkout_d160", CLKOUT, 160),
+ D_DIV(CLKOUT_D1OR2, "clkout_d1or2", CLKOUT, 0, 1, 2),
+ D_FFC(CLKOUT_D20, "clkout_d20", CLKOUT, 20),
+ D_FFC(CLKOUT_D40, "clkout_d40", CLKOUT, 40),
+ D_FFC(CLKOUT_D5, "clkout_d5", CLKOUT, 5),
+ D_FFC(CLKOUT_D8, "clkout_d8", CLKOUT, 8),
+ D_DIV(DIV_ADC, "div_adc", CLKOUT, 77, 50, 250),
+ D_DIV(DIV_I2C, "div_i2c", CLKOUT, 78, 12, 16),
+ D_DIV(DIV_NAND, "div_nand", CLKOUT, 82, 12, 32),
+ D_DIV(DIV_P1_PG, "div_p1_pg", CLKOUT, 68, 12, 200),
+ D_DIV(DIV_P2_PG, "div_p2_pg", CLKOUT, 62, 12, 128),
+ D_DIV(DIV_P3_PG, "div_p3_pg", CLKOUT, 64, 8, 128),
+ D_DIV(DIV_P4_PG, "div_p4_pg", CLKOUT, 66, 8, 128),
+ D_DIV(DIV_P5_PG, "div_p5_pg", CLKOUT, 71, 10, 40),
+ D_DIV(DIV_P6_PG, "div_p6_pg", CLKOUT, 18, 12, 64),
+ D_DIV(DIV_QSPI0, "div_qspi0", CLKOUT, 73, 3, 7),
+ D_DIV(DIV_QSPI1, "div_qspi1", CLKOUT, 25, 3, 7),
+ D_DIV(DIV_REF_SYNC, "div_ref_sync", CLKOUT, 56, 2, 16, 2, 4, 8, 16),
+ D_DIV(DIV_SDIO0, "div_sdio0", CLKOUT, 74, 20, 128),
+ D_DIV(DIV_SDIO1, "div_sdio1", CLKOUT, 75, 20, 128),
+ D_DIV(DIV_SWITCH, "div_switch", CLKOUT, 37, 5, 40),
+ D_DIV(DIV_UART, "div_uart", CLKOUT, 79, 12, 128),
+ D_GATE(CLK_25_PG4, "clk_25_pg4", CLKOUT_D40, 0x749, 0x74a, 0x74b, 0, 0xae3, 0, 0),
+ D_GATE(CLK_25_PG5, "clk_25_pg5", CLKOUT_D40, 0x74c, 0x74d, 0x74e, 0, 0xae4, 0, 0),
+ D_GATE(CLK_25_PG6, "clk_25_pg6", CLKOUT_D40, 0x74f, 0x750, 0x751, 0, 0xae5, 0, 0),
+ D_GATE(CLK_25_PG7, "clk_25_pg7", CLKOUT_D40, 0x752, 0x753, 0x754, 0, 0xae6, 0, 0),
+ D_GATE(CLK_25_PG8, "clk_25_pg8", CLKOUT_D40, 0x755, 0x756, 0x757, 0, 0xae7, 0, 0),
+ D_GATE(CLK_ADC, "clk_adc", DIV_ADC, 0x1ea, 0x1eb, 0, 0, 0, 0, 0),
+ D_GATE(CLK_ECAT100, "clk_ecat100", CLKOUT_D10, 0x405, 0, 0, 0, 0, 0, 0),
+ D_GATE(CLK_HSR100, "clk_hsr100", CLKOUT_D10, 0x483, 0, 0, 0, 0, 0, 0),
+ D_GATE(CLK_I2C0, "clk_i2c0", DIV_I2C, 0x1e6, 0x1e7, 0, 0, 0, 0, 0),
+ D_GATE(CLK_I2C1, "clk_i2c1", DIV_I2C, 0x1e8, 0x1e9, 0, 0, 0, 0, 0),
+ D_GATE(CLK_MII_REF, "clk_mii_ref", CLKOUT_D40, 0x342, 0, 0, 0, 0, 0, 0),
+ D_GATE(CLK_NAND, "clk_nand", DIV_NAND, 0x284, 0x285, 0, 0, 0, 0, 0),
+ D_GATE(CLK_NOUSBP2_PG6, "clk_nousbp2_pg6", DIV_P2_PG, 0x774, 0x775, 0, 0, 0, 0, 0),
+ D_GATE(CLK_P1_PG2, "clk_p1_pg2", DIV_P1_PG, 0x862, 0x863, 0, 0, 0, 0, 0),
+ D_GATE(CLK_P1_PG3, "clk_p1_pg3", DIV_P1_PG, 0x864, 0x865, 0, 0, 0, 0, 0),
+ D_GATE(CLK_P1_PG4, "clk_p1_pg4", DIV_P1_PG, 0x866, 0x867, 0, 0, 0, 0, 0),
+ D_GATE(CLK_P4_PG3, "clk_p4_pg3", DIV_P4_PG, 0x824, 0x825, 0, 0, 0, 0, 0),
+ D_GATE(CLK_P4_PG4, "clk_p4_pg4", DIV_P4_PG, 0x826, 0x827, 0, 0, 0, 0, 0),
+ D_GATE(CLK_P6_PG1, "clk_p6_pg1", DIV_P6_PG, 0x8a0, 0x8a1, 0x8a2, 0, 0xb60, 0, 0),
+ D_GATE(CLK_P6_PG2, "clk_p6_pg2", DIV_P6_PG, 0x8a3, 0x8a4, 0x8a5, 0, 0xb61, 0, 0),
+ D_GATE(CLK_P6_PG3, "clk_p6_pg3", DIV_P6_PG, 0x8a6, 0x8a7, 0x8a8, 0, 0xb62, 0, 0),
+ D_GATE(CLK_P6_PG4, "clk_p6_pg4", DIV_P6_PG, 0x8a9, 0x8aa, 0x8ab, 0, 0xb63, 0, 0),
+ D_GATE(CLK_QSPI0, "clk_qspi0", DIV_QSPI0, 0x2a4, 0x2a5, 0, 0, 0, 0, 0),
+ D_GATE(CLK_QSPI1, "clk_qspi1", DIV_QSPI1, 0x484, 0x485, 0, 0, 0, 0, 0),
+ D_GATE(CLK_RGMII_REF, "clk_rgmii_ref", CLKOUT_D8, 0x340, 0, 0, 0, 0, 0, 0),
+ D_GATE(CLK_RMII_REF, "clk_rmii_ref", CLKOUT_D20, 0x341, 0, 0, 0, 0, 0, 0),
+ D_GATE(CLK_SDIO0, "clk_sdio0", DIV_SDIO0, 0x64, 0, 0, 0, 0, 0, 0),
+ D_GATE(CLK_SDIO1, "clk_sdio1", DIV_SDIO1, 0x644, 0, 0, 0, 0, 0, 0),
+ D_GATE(CLK_SERCOS100, "clk_sercos100", CLKOUT_D10, 0x425, 0, 0, 0, 0, 0, 0),
+ D_GATE(CLK_SLCD, "clk_slcd", DIV_P1_PG, 0x860, 0x861, 0, 0, 0, 0, 0),
+ D_GATE(CLK_SPI0, "clk_spi0", DIV_P3_PG, 0x7e0, 0x7e1, 0, 0, 0, 0, 0),
+ D_GATE(CLK_SPI1, "clk_spi1", DIV_P3_PG, 0x7e2, 0x7e3, 0, 0, 0, 0, 0),
+ D_GATE(CLK_SPI2, "clk_spi2", DIV_P3_PG, 0x7e4, 0x7e5, 0, 0, 0, 0, 0),
+ D_GATE(CLK_SPI3, "clk_spi3", DIV_P3_PG, 0x7e6, 0x7e7, 0, 0, 0, 0, 0),
+ D_GATE(CLK_SPI4, "clk_spi4", DIV_P4_PG, 0x820, 0x821, 0, 0, 0, 0, 0),
+ D_GATE(CLK_SPI5, "clk_spi5", DIV_P4_PG, 0x822, 0x823, 0, 0, 0, 0, 0),
+ D_GATE(CLK_SWITCH, "clk_switch", DIV_SWITCH, 0x982, 0x983, 0, 0, 0, 0, 0),
+ D_DIV(DIV_MOTOR, "div_motor", CLKOUT_D5, 84, 2, 8),
+ D_GATE(HCLK_ECAT125, "hclk_ecat125", CLKOUT_D8, 0x400, 0x401, 0, 0x402, 0, 0x440, 0x441),
+ D_GATE(HCLK_PINCONFIG, "hclk_pinconfig", CLKOUT_D40, 0x740, 0x741, 0x742, 0, 0xae0, 0, 0),
+ D_GATE(HCLK_SERCOS, "hclk_sercos", CLKOUT_D10, 0x420, 0x422, 0, 0x421, 0, 0x460, 0x461),
+ D_GATE(HCLK_SGPIO2, "hclk_sgpio2", DIV_P5_PG, 0x8c3, 0x8c4, 0x8c5, 0, 0xb41, 0, 0),
+ D_GATE(HCLK_SGPIO3, "hclk_sgpio3", DIV_P5_PG, 0x8c6, 0x8c7, 0x8c8, 0, 0xb42, 0, 0),
+ D_GATE(HCLK_SGPIO4, "hclk_sgpio4", DIV_P5_PG, 0x8c9, 0x8ca, 0x8cb, 0, 0xb43, 0, 0),
+ D_GATE(HCLK_TIMER0, "hclk_timer0", CLKOUT_D40, 0x743, 0x744, 0x745, 0, 0xae1, 0, 0),
+ D_GATE(HCLK_TIMER1, "hclk_timer1", CLKOUT_D40, 0x746, 0x747, 0x748, 0, 0xae2, 0, 0),
+ D_GATE(HCLK_USBF, "hclk_usbf", CLKOUT_D8, 0xe3, 0, 0, 0xe4, 0, 0x102, 0x103),
+ D_GATE(HCLK_USBH, "hclk_usbh", CLKOUT_D8, 0xe0, 0xe1, 0, 0xe2, 0, 0x100, 0x101),
+ D_GATE(HCLK_USBPM, "hclk_usbpm", CLKOUT_D8, 0xe5, 0, 0, 0, 0, 0, 0),
+ D_GATE(CLK_48_PG_F, "clk_48_pg_f", CLK_48, 0x78c, 0x78d, 0, 0x78e, 0, 0xb04, 0xb05),
+ D_GATE(CLK_48_PG4, "clk_48_pg4", CLK_48, 0x789, 0x78a, 0x78b, 0, 0xb03, 0, 0),
+ D_FFC(CLK_DDRPHY_PLLCLK_D4, "clk_ddrphy_pllclk_d4", CLK_DDRPHY_PLLCLK, 4),
+ D_FFC(CLK_ECAT100_D4, "clk_ecat100_d4", CLK_ECAT100, 4),
+ D_FFC(CLK_HSR100_D2, "clk_hsr100_d2", CLK_HSR100, 2),
+ D_FFC(CLK_REF_SYNC_D4, "clk_ref_sync_d4", CLK_REF_SYNC, 4),
+ D_FFC(CLK_REF_SYNC_D8, "clk_ref_sync_d8", CLK_REF_SYNC, 8),
+ D_FFC(CLK_SERCOS100_D2, "clk_sercos100_d2", CLK_SERCOS100, 2),
+ D_DIV(DIV_CA7, "div_ca7", CLK_REF_SYNC, 57, 1, 4, 1, 2, 4),
+ D_GATE(HCLK_CAN0, "hclk_can0", CLK_48, 0x783, 0x784, 0x785, 0, 0xb01, 0, 0),
+ D_GATE(HCLK_CAN1, "hclk_can1", CLK_48, 0x786, 0x787, 0x788, 0, 0xb02, 0, 0),
+ D_GATE(HCLK_DELTASIGMA, "hclk_deltasigma", DIV_MOTOR, 0x1ef, 0x1f0, 0x1f1, 0, 0, 0, 0),
+ D_GATE(HCLK_PWMPTO, "hclk_pwmpto", DIV_MOTOR, 0x1ec, 0x1ed, 0x1ee, 0, 0, 0, 0),
+ D_GATE(HCLK_RSV, "hclk_rsv", CLK_48, 0x780, 0x781, 0x782, 0, 0xb00, 0, 0),
+ D_GATE(HCLK_SGPIO0, "hclk_sgpio0", DIV_MOTOR, 0x1e0, 0x1e1, 0x1e2, 0, 0, 0, 0),
+ D_GATE(HCLK_SGPIO1, "hclk_sgpio1", DIV_MOTOR, 0x1e3, 0x1e4, 0x1e5, 0, 0, 0, 0),
+ D_DIV(RTOS_MDC, "rtos_mdc", CLK_REF_SYNC, 100, 80, 640, 80, 160, 320, 640),
+ D_GATE(CLK_CM3, "clk_cm3", CLK_REF_SYNC_D4, 0xba0, 0xba1, 0, 0xba2, 0, 0xbc0, 0xbc1),
+ D_GATE(CLK_DDRC, "clk_ddrc", CLK_DDRPHY_PLLCLK_D4, 0x323, 0x324, 0, 0, 0, 0, 0),
+ D_GATE(CLK_ECAT25, "clk_ecat25", CLK_ECAT100_D4, 0x403, 0x404, 0, 0, 0, 0, 0),
+ D_GATE(CLK_HSR50, "clk_hsr50", CLK_HSR100_D2, 0x484, 0x485, 0, 0, 0, 0, 0),
+ D_GATE(CLK_HW_RTOS, "clk_hw_rtos", CLK_REF_SYNC_D4, 0xc60, 0xc61, 0, 0, 0, 0, 0),
+ D_GATE(CLK_SERCOS50, "clk_sercos50", CLK_SERCOS100_D2, 0x424, 0x423, 0, 0, 0, 0, 0),
+ D_GATE(HCLK_ADC, "hclk_adc", CLK_REF_SYNC_D8, 0x1af, 0x1b0, 0x1b1, 0, 0, 0, 0),
+ D_GATE(HCLK_CM3, "hclk_cm3", CLK_REF_SYNC_D4, 0xc20, 0xc21, 0xc22, 0, 0, 0, 0),
+ D_GATE(HCLK_CRYPTO_EIP150, "hclk_crypto_eip150", CLK_REF_SYNC_D4, 0x123, 0x124, 0x125, 0, 0x142, 0, 0),
+ D_GATE(HCLK_CRYPTO_EIP93, "hclk_crypto_eip93", CLK_REF_SYNC_D4, 0x120, 0x121, 0, 0x122, 0, 0x140, 0x141),
+ D_GATE(HCLK_DDRC, "hclk_ddrc", CLK_REF_SYNC_D4, 0x320, 0x322, 0, 0x321, 0, 0x3a0, 0x3a1),
+ D_GATE(HCLK_DMA0, "hclk_dma0", CLK_REF_SYNC_D4, 0x260, 0x261, 0x262, 0x263, 0x2c0, 0x2c1, 0x2c2),
+ D_GATE(HCLK_DMA1, "hclk_dma1", CLK_REF_SYNC_D4, 0x264, 0x265, 0x266, 0x267, 0x2c3, 0x2c4, 0x2c5),
+ D_GATE(HCLK_GMAC0, "hclk_gmac0", CLK_REF_SYNC_D4, 0x360, 0x361, 0x362, 0x363, 0x3c0, 0x3c1, 0x3c2),
+ D_GATE(HCLK_GMAC1, "hclk_gmac1", CLK_REF_SYNC_D4, 0x380, 0x381, 0x382, 0x383, 0x3e0, 0x3e1, 0x3e2),
+ D_GATE(HCLK_GPIO0, "hclk_gpio0", CLK_REF_SYNC_D4, 0x212, 0x213, 0x214, 0, 0, 0, 0),
+ D_GATE(HCLK_GPIO1, "hclk_gpio1", CLK_REF_SYNC_D4, 0x215, 0x216, 0x217, 0, 0, 0, 0),
+ D_GATE(HCLK_GPIO2, "hclk_gpio2", CLK_REF_SYNC_D4, 0x229, 0x22a, 0x22b, 0, 0, 0, 0),
+ D_GATE(HCLK_HSR, "hclk_hsr", CLK_HSR100_D2, 0x480, 0x482, 0, 0x481, 0, 0x4c0, 0x4c1),
+ D_GATE(HCLK_I2C0, "hclk_i2c0", CLK_REF_SYNC_D8, 0x1a9, 0x1aa, 0x1ab, 0, 0, 0, 0),
+ D_GATE(HCLK_I2C1, "hclk_i2c1", CLK_REF_SYNC_D8, 0x1ac, 0x1ad, 0x1ae, 0, 0, 0, 0),
+ D_GATE(HCLK_LCD, "hclk_lcd", CLK_REF_SYNC_D4, 0x7a0, 0x7a1, 0x7a2, 0, 0xb20, 0, 0),
+ D_GATE(HCLK_MSEBI_M, "hclk_msebi_m", CLK_REF_SYNC_D4, 0x164, 0x165, 0x166, 0, 0x183, 0, 0),
+ D_GATE(HCLK_MSEBI_S, "hclk_msebi_s", CLK_REF_SYNC_D4, 0x160, 0x161, 0x162, 0x163, 0x180, 0x181, 0x182),
+ D_GATE(HCLK_NAND, "hclk_nand", CLK_REF_SYNC_D4, 0x280, 0x281, 0x282, 0x283, 0x2e0, 0x2e1, 0x2e2),
+ D_GATE(HCLK_PG_I, "hclk_pg_i", CLK_REF_SYNC_D4, 0x7ac, 0x7ad, 0, 0x7ae, 0, 0xb24, 0xb25),
+ D_GATE(HCLK_PG19, "hclk_pg19", CLK_REF_SYNC_D4, 0x22c, 0x22d, 0x22e, 0, 0, 0, 0),
+ D_GATE(HCLK_PG20, "hclk_pg20", CLK_REF_SYNC_D4, 0x22f, 0x230, 0x231, 0, 0, 0, 0),
+ D_GATE(HCLK_PG3, "hclk_pg3", CLK_REF_SYNC_D4, 0x7a6, 0x7a7, 0x7a8, 0, 0xb22, 0, 0),
+ D_GATE(HCLK_PG4, "hclk_pg4", CLK_REF_SYNC_D4, 0x7a9, 0x7aa, 0x7ab, 0, 0xb23, 0, 0),
+ D_GATE(HCLK_QSPI0, "hclk_qspi0", CLK_REF_SYNC_D4, 0x2a0, 0x2a1, 0x2a2, 0x2a3, 0x300, 0x301, 0x302),
+ D_GATE(HCLK_QSPI1, "hclk_qspi1", CLK_REF_SYNC_D4, 0x480, 0x481, 0x482, 0x483, 0x4c0, 0x4c1, 0x4c2),
+ D_GATE(HCLK_ROM, "hclk_rom", CLK_REF_SYNC_D4, 0xaa0, 0xaa1, 0xaa2, 0, 0xb80, 0, 0),
+ D_GATE(HCLK_RTC, "hclk_rtc", CLK_REF_SYNC_D8, 0xa00, 0, 0, 0, 0, 0, 0),
+ D_GATE(HCLK_SDIO0, "hclk_sdio0", CLK_REF_SYNC_D4, 0x60, 0x61, 0x62, 0x63, 0x80, 0x81, 0x82),
+ D_GATE(HCLK_SDIO1, "hclk_sdio1", CLK_REF_SYNC_D4, 0x640, 0x641, 0x642, 0x643, 0x660, 0x661, 0x662),
+ D_GATE(HCLK_SEMAP, "hclk_semap", CLK_REF_SYNC_D4, 0x7a3, 0x7a4, 0x7a5, 0, 0xb21, 0, 0),
+ D_GATE(HCLK_SPI0, "hclk_spi0", CLK_REF_SYNC_D4, 0x200, 0x201, 0x202, 0, 0, 0, 0),
+ D_GATE(HCLK_SPI1, "hclk_spi1", CLK_REF_SYNC_D4, 0x203, 0x204, 0x205, 0, 0, 0, 0),
+ D_GATE(HCLK_SPI2, "hclk_spi2", CLK_REF_SYNC_D4, 0x206, 0x207, 0x208, 0, 0, 0, 0),
+ D_GATE(HCLK_SPI3, "hclk_spi3", CLK_REF_SYNC_D4, 0x209, 0x20a, 0x20b, 0, 0, 0, 0),
+ D_GATE(HCLK_SPI4, "hclk_spi4", CLK_REF_SYNC_D4, 0x20c, 0x20d, 0x20e, 0, 0, 0, 0),
+ D_GATE(HCLK_SPI5, "hclk_spi5", CLK_REF_SYNC_D4, 0x20f, 0x210, 0x211, 0, 0, 0, 0),
+ D_GATE(HCLK_SWITCH, "hclk_switch", CLK_REF_SYNC_D4, 0x980, 0, 0x981, 0, 0, 0, 0),
+ D_GATE(HCLK_SWITCH_RG, "hclk_switch_rg", CLK_REF_SYNC_D4, 0xc40, 0xc41, 0xc42, 0, 0, 0, 0),
+ D_GATE(HCLK_UART0, "hclk_uart0", CLK_REF_SYNC_D8, 0x1a0, 0x1a1, 0x1a2, 0, 0, 0, 0),
+ D_GATE(HCLK_UART1, "hclk_uart1", CLK_REF_SYNC_D8, 0x1a3, 0x1a4, 0x1a5, 0, 0, 0, 0),
+ D_GATE(HCLK_UART2, "hclk_uart2", CLK_REF_SYNC_D8, 0x1a6, 0x1a7, 0x1a8, 0, 0, 0, 0),
+ D_GATE(HCLK_UART3, "hclk_uart3", CLK_REF_SYNC_D4, 0x218, 0x219, 0x21a, 0, 0, 0, 0),
+ D_GATE(HCLK_UART4, "hclk_uart4", CLK_REF_SYNC_D4, 0x21b, 0x21c, 0x21d, 0, 0, 0, 0),
+ D_GATE(HCLK_UART5, "hclk_uart5", CLK_REF_SYNC_D4, 0x220, 0x221, 0x222, 0, 0, 0, 0),
+ D_GATE(HCLK_UART6, "hclk_uart6", CLK_REF_SYNC_D4, 0x223, 0x224, 0x225, 0, 0, 0, 0),
+ D_GATE(HCLK_UART7, "hclk_uart7", CLK_REF_SYNC_D4, 0x226, 0x227, 0x228, 0, 0, 0, 0),
+ /*
+ * These are not hardware clocks, but are needed to handle the special
+ * case where we have a 'selector bit' that doesn't just change the
+ * parent for a clock, but also the gate it's suposed to use.
+ */
+ {
+ .index = R9A06G032_UART_GROUP_012,
+ .name = "uart_group_012",
+ .type = K_BITSEL,
+ .source = 1 + R9A06G032_DIV_UART,
+ /* R9A06G032_SYSCTRL_REG_PWRCTRL_PG1_PR2 */
+ .dual.sel = ((0xec / 4) << 5) | 24,
+ .dual.group = 0,
+ },
+ {
+ .index = R9A06G032_UART_GROUP_34567,
+ .name = "uart_group_34567",
+ .type = K_BITSEL,
+ .source = 1 + R9A06G032_DIV_P2_PG,
+ /* R9A06G032_SYSCTRL_REG_PWRCTRL_PG0_0 */
+ .dual.sel = ((0x34 / 4) << 5) | 30,
+ .dual.group = 1,
+ },
+ D_UGATE(CLK_UART0, "clk_uart0", UART_GROUP_012, 0, 0, 0x1b2, 0x1b3, 0x1b4, 0x1b5),
+ D_UGATE(CLK_UART1, "clk_uart1", UART_GROUP_012, 0, 1, 0x1b6, 0x1b7, 0x1b8, 0x1b9),
+ D_UGATE(CLK_UART2, "clk_uart2", UART_GROUP_012, 0, 2, 0x1ba, 0x1bb, 0x1bc, 0x1bd),
+ D_UGATE(CLK_UART3, "clk_uart3", UART_GROUP_34567, 1, 0, 0x760, 0x761, 0x762, 0x763),
+ D_UGATE(CLK_UART4, "clk_uart4", UART_GROUP_34567, 1, 1, 0x764, 0x765, 0x766, 0x767),
+ D_UGATE(CLK_UART5, "clk_uart5", UART_GROUP_34567, 1, 2, 0x768, 0x769, 0x76a, 0x76b),
+ D_UGATE(CLK_UART6, "clk_uart6", UART_GROUP_34567, 1, 3, 0x76c, 0x76d, 0x76e, 0x76f),
+ D_UGATE(CLK_UART7, "clk_uart7", UART_GROUP_34567, 1, 4, 0x770, 0x771, 0x772, 0x773),
+};
+
+struct r9a06g032_priv {
+ struct clk_onecell_data data;
+ spinlock_t lock;
+ void __iomem *reg;
+};
+
+/* register/bit pairs are encoded as an uint16_t */
+static void clk_rdesc_set(
+ struct r9a06g032_priv *clocks,
+ uint16_t one, unsigned int on)
+{
+ u32 __iomem *reg = ((u32 __iomem *)clocks->reg) + (one >> 5);
+ u32 val = clk_readl(reg);
+
+ val = (val & ~(1U << (one & 0x1f))) | ((!!on) << (one & 0x1f));
+ clk_writel(val, reg);
+}
+
+static int clk_rdesc_get(
+ struct r9a06g032_priv *clocks,
+ uint16_t one)
+{
+ u32 __iomem *reg = ((u32 __iomem *)clocks->reg) + (one >> 5);
+ u32 val = clk_readl(reg);
+
+ return !!(val & (1U << (one & 0x1f)));
+}
+
+/*
+ * This implements the R9A09G032 clock gate 'driver'. We cannot use the system's
+ * clock gate framework as the gates on the R9A09G032 have a special enabling
+ * sequence, therefore we use this little proxy.
+ */
+struct r9a06g032_clk_gate {
+ struct clk_hw hw;
+ struct r9a06g032_priv *clocks;
+ u16 index;
+ unsigned read_only : 1;
+
+ struct r9a06g032_gate gate;
+};
+
+#define to_r9a06g032_gate(_hw) container_of(_hw, struct r9a06g032_clk_gate, hw)
+
+static void r9a06g032_clk_gate_set(
+ struct r9a06g032_priv *clocks,
+ struct r9a06g032_gate *g, int on)
+{
+ unsigned long flags;
+
+ WARN_ON(!g->gate);
+
+ spin_lock_irqsave(&clocks->lock, flags);
+ clk_rdesc_set(clocks, g->gate, on);
+ /* De-assert reset */
+ if (g->reset)
+ clk_rdesc_set(clocks, g->reset, 1);
+ spin_unlock_irqrestore(&clocks->lock, flags);
+
+ /* Hardware manual recommends 5us delay after enabling clock & reset */
+ udelay(5);
+
+ /* If the peripheral is memory mapped (i.e. an AXI slave), there is an
+ * associated SLVRDY bit in the System Controller that needs to be set
+ * so that the FlexWAY bus fabric passes on the read/write requests.
+ */
+ if (g->ready || g->midle) {
+ spin_lock_irqsave(&clocks->lock, flags);
+ if (g->ready)
+ clk_rdesc_set(clocks, g->ready, on);
+ /* Clear 'Master Idle Request' bit */
+ if (g->midle)
+ clk_rdesc_set(clocks, g->midle, !on);
+ spin_unlock_irqrestore(&clocks->lock, flags);
+ }
+ /* Note: We don't wait for FlexWAY Socket Connection signal */
+}
+
+static int r9a06g032_clk_gate_enable(struct clk_hw *hw)
+{
+ struct r9a06g032_clk_gate *g = to_r9a06g032_gate(hw);
+
+ r9a06g032_clk_gate_set(g->clocks, &g->gate, 1);
+ return 0;
+}
+
+static void r9a06g032_clk_gate_disable(struct clk_hw *hw)
+{
+ struct r9a06g032_clk_gate *g = to_r9a06g032_gate(hw);
+
+ if (!g->read_only)
+ r9a06g032_clk_gate_set(g->clocks, &g->gate, 0);
+ else
+ pr_debug("%s %s: disallowed\n", __func__,
+ __clk_get_name(hw->clk));
+}
+
+static int r9a06g032_clk_gate_is_enabled(struct clk_hw *hw)
+{
+ struct r9a06g032_clk_gate *g = to_r9a06g032_gate(hw);
+
+ return clk_rdesc_get(g->clocks, g->gate.gate);
+}
+
+static const struct clk_ops r9a06g032_clk_gate_ops = {
+ .enable = r9a06g032_clk_gate_enable,
+ .disable = r9a06g032_clk_gate_disable,
+ .is_enabled = r9a06g032_clk_gate_is_enabled,
+};
+
+static struct clk *r9a06g032_register_gate(
+ struct r9a06g032_priv *clocks,
+ const char *parent_name,
+ const struct r9a06g032_clkdesc *desc)
+{
+ struct clk *clk;
+ struct r9a06g032_clk_gate *g;
+ struct clk_init_data init;
+
+ g = kzalloc(sizeof(struct r9a06g032_clk_gate), GFP_KERNEL);
+ if (!g)
+ return NULL;
+
+ init.name = desc->name;
+ init.ops = &r9a06g032_clk_gate_ops;
+ init.flags = CLK_IS_BASIC | CLK_SET_RATE_PARENT;
+ init.parent_names = parent_name ? &parent_name : NULL;
+ init.num_parents = parent_name ? 1 : 0;
+
+ g->clocks = clocks;
+ g->index = desc->index;
+ g->gate = desc->gate;
+ g->hw.init = &init;
+ g->read_only = 0;
+
+ clk = clk_register(NULL, &g->hw);
+ if (IS_ERR(clk)) {
+ kfree(g);
+ return NULL;
+ }
+ /*
+ * important here, some clocks are already in use by the CM3, we
+ * have to assume they are not Linux's to play with and try to disable
+ * at the end of the boot!
+ * Therefore we increase the clock usage count by arbitrarily enabling
+ * the clock, allowing it to stay untouched at the end of the boot.
+ */
+ g->read_only = r9a06g032_clk_gate_is_enabled(&g->hw);
+ if (g->read_only)
+ pr_debug("%s was enabled, making read-only\n", desc->name);
+ return clk;
+}
+
+struct r9a06g032_clk_div {
+ struct clk_hw hw;
+ struct r9a06g032_priv *clocks;
+ u16 index;
+ u16 reg;
+ u16 min, max;
+ uint8_t table_size;
+ u16 table[8]; /* we know there are no more than 8 */
+};
+
+#define to_r9a06g032_divider(_hw) \
+ container_of(_hw, struct r9a06g032_clk_div, hw)
+
+static unsigned long r9a06g032_divider_recalc_rate(
+ struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct r9a06g032_clk_div *clk = to_r9a06g032_divider(hw);
+ u32 *reg = ((u32 *)clk->clocks->reg) + clk->reg;
+ long div = clk_readl(reg);
+
+ if (div < clk->min)
+ div = clk->min;
+ else if (div > clk->max)
+ div = clk->max;
+ return DIV_ROUND_UP(parent_rate, div);
+}
+
+/*
+ * Attempts to find a value that is in range of min,max,
+ * and if a table of set dividers was specified for this
+ * register, try to find the fixed divider that is the closest
+ * to the target frequency
+ */
+static long r9a06g032_divider_clamp_div(
+ struct r9a06g032_clk_div *clk,
+ unsigned long rate, unsigned long prate)
+{
+ /* + 1 to cope with rates that have the remainder dropped */
+ long div = DIV_ROUND_UP(prate, rate + 1);
+ int i;
+
+ if (div <= clk->min)
+ return clk->min;
+ if (div >= clk->max)
+ return clk->max;
+
+ for (i = 0; clk->table_size && i < clk->table_size - 1; i++) {
+ if (div >= clk->table[i] && div <= clk->table[i+1]) {
+ unsigned long m = rate -
+ DIV_ROUND_UP(prate, clk->table[i]);
+ unsigned long p =
+ DIV_ROUND_UP(prate, clk->table[i + 1]) -
+ rate;
+ /*
+ * select the divider that generates
+ * the value closest to the ideal frequency
+ */
+ div = p >= m ? clk->table[i] : clk->table[i + 1];
+ return div;
+ }
+ }
+ return div;
+}
+
+static long r9a06g032_divider_round_rate(
+ struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ struct r9a06g032_clk_div *clk = to_r9a06g032_divider(hw);
+ long div = DIV_ROUND_UP(*prate, rate);
+
+ pr_devel("%s %pC %ld (prate %ld) (wanted div %ld)\n", __func__,
+ hw->clk, rate, *prate, div);
+ pr_devel(" min %d (%ld) max %d (%ld)\n",
+ clk->min, DIV_ROUND_UP(*prate, clk->min),
+ clk->max, DIV_ROUND_UP(*prate, clk->max));
+
+ div = r9a06g032_divider_clamp_div(clk, rate, *prate);
+ /*
+ * this is a hack. Currently the serial driver asks for a clock rate
+ * that is 16 times the baud rate -- and that is wildly outside the
+ * range of the UART divider, somehow there is no provision for that
+ * case of 'let the divider as is if outside range'.
+ * The serial driver *shouldn't* play with these clocks anyway, there's
+ * several uarts attached to this divider, and changing this impacts
+ * everyone.
+ */
+ if (clk->index == R9A06G032_DIV_UART) {
+ pr_devel("%s div uart hack!\n", __func__);
+ return clk_get_rate(hw->clk);
+ }
+ pr_devel("%s %pC %ld / %ld = %ld\n", __func__, hw->clk,
+ *prate, div, DIV_ROUND_UP(*prate, div));
+ return DIV_ROUND_UP(*prate, div);
+}
+
+static int r9a06g032_divider_set_rate(
+ struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct r9a06g032_clk_div *clk = to_r9a06g032_divider(hw);
+ /* + 1 to cope with rates that have the remainder dropped */
+ u32 div = DIV_ROUND_UP(parent_rate, rate + 1);
+ u32 *reg = ((u32 *)clk->clocks->reg) + clk->reg;
+
+ pr_devel("%s %pC rate %ld parent %ld div %d\n", __func__, hw->clk,
+ rate, parent_rate, div);
+
+ /*
+ * Need to write the bit 31 with the divider value to
+ * latch it. Technically we should wait until it has been
+ * cleared too.
+ * TODO: Find whether this callback is sleepable, in case
+ * the hardware /does/ require some sort of spinloop here.
+ */
+ clk_writel(div | (1U << 31), reg);
+
+ return 0;
+}
+
+static const struct clk_ops r9a06g032_clk_div_ops = {
+ .recalc_rate = r9a06g032_divider_recalc_rate,
+ .round_rate = r9a06g032_divider_round_rate,
+ .set_rate = r9a06g032_divider_set_rate,
+};
+
+static struct clk *r9a06g032_register_divider(
+ struct r9a06g032_priv *clocks,
+ const char *parent_name,
+ const struct r9a06g032_clkdesc *desc)
+{
+ struct r9a06g032_clk_div *div;
+ struct clk *clk;
+ struct clk_init_data init;
+ int i;
+
+ div = kzalloc(sizeof(struct r9a06g032_clk_div), GFP_KERNEL);
+ if (!div)
+ return NULL;
+
+ init.name = desc->name;
+ init.ops = &r9a06g032_clk_div_ops;
+ init.flags = CLK_IS_BASIC | CLK_SET_RATE_PARENT;
+ init.parent_names = parent_name ? &parent_name : NULL;
+ init.num_parents = parent_name ? 1 : 0;
+
+ div->clocks = clocks;
+ div->index = desc->index;
+ div->reg = desc->reg;
+ div->hw.init = &init;
+ div->min = desc->div_min;
+ div->max = desc->div_max;
+ /* populate (optional) divider table fixed values */
+ for (i = 0; i < ARRAY_SIZE(div->table) &&
+ i < ARRAY_SIZE(desc->div_table) &&
+ desc->div_table[i]; i++) {
+ div->table[div->table_size++] = desc->div_table[i];
+ }
+
+ clk = clk_register(NULL, &div->hw);
+ if (IS_ERR(clk)) {
+ kfree(div);
+ return NULL;
+ }
+ return clk;
+}
+
+/*
+ * This clock provider handles the case of the R9A06G032 where you have
+ * peripherals that have two potential clock source and two gates, one for
+ * each of the clock source - the used clock source (for all sub clocks)
+ * is selected by a single bit.
+ * That single bit affects all sub-clocks, and therefore needs to change the
+ * active gate (and turn the others off) and force a recalculation of the rates.
+ *
+ * This implements two clock providers, one 'bitselect' that
+ * handles the switch between both parents, and another 'dualgate'
+ * that knows which gate to poke at, depending on the parent's bit position.
+ */
+struct r9a06g032_clk_bitsel {
+ struct clk_hw hw;
+ struct r9a06g032_priv *clocks;
+ u16 index;
+ u16 selector; /* selector register + bit */
+};
+
+#define to_clk_bitselect(_hw) \
+ container_of(_hw, struct r9a06g032_clk_bitsel, hw)
+
+static u8 r9a06g032_clk_mux_get_parent(struct clk_hw *hw)
+{
+ struct r9a06g032_clk_bitsel *set = to_clk_bitselect(hw);
+
+ return clk_rdesc_get(set->clocks, set->selector);
+}
+
+static int r9a06g032_clk_mux_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct r9a06g032_clk_bitsel *set = to_clk_bitselect(hw);
+
+ /* a single bit in the register selects one of two parent clocks */
+ clk_rdesc_set(set->clocks, set->selector, !!index);
+
+ return 0;
+}
+
+static const struct clk_ops clk_bitselect_ops = {
+ .get_parent = r9a06g032_clk_mux_get_parent,
+ .set_parent = r9a06g032_clk_mux_set_parent,
+};
+
+static struct clk *r9a06g032_register_bitsel(
+ struct r9a06g032_priv *clocks,
+ const char *parent_name,
+ const struct r9a06g032_clkdesc *desc)
+{
+ struct clk *clk;
+ struct r9a06g032_clk_bitsel *g;
+ struct clk_init_data init;
+ const char *names[2];
+
+ /* allocate the gate */
+ g = kzalloc(sizeof(struct r9a06g032_clk_bitsel), GFP_KERNEL);
+ if (!g)
+ return NULL;
+
+ names[0] = parent_name;
+ names[1] = "clk_pll_usb";
+
+ init.name = desc->name;
+ init.ops = &clk_bitselect_ops;
+ init.flags = CLK_IS_BASIC | CLK_SET_RATE_PARENT;
+ init.parent_names = names;
+ init.num_parents = 2;
+
+ g->clocks = clocks;
+ g->index = desc->index;
+ g->selector = desc->dual.sel;
+ g->hw.init = &init;
+
+ clk = clk_register(NULL, &g->hw);
+ if (IS_ERR(clk)) {
+ kfree(g);
+ return NULL;
+ }
+ return clk;
+}
+
+struct r9a06g032_clk_dualgate {
+ struct clk_hw hw;
+ struct r9a06g032_priv *clocks;
+ u16 index;
+ u16 selector; /* selector register + bit */
+ struct r9a06g032_gate gate[2];
+};
+#define to_clk_dualgate(_hw) \
+ container_of(_hw, struct r9a06g032_clk_dualgate, hw)
+
+static int r9a06g032_clk_dualgate_setenable(
+ struct r9a06g032_clk_dualgate *g, int enable)
+{
+ uint8_t sel_bit = clk_rdesc_get(g->clocks, g->selector);
+
+ /* we always turn off the 'other' gate, regardless */
+ r9a06g032_clk_gate_set(g->clocks, &g->gate[!sel_bit], 0);
+ r9a06g032_clk_gate_set(g->clocks, &g->gate[sel_bit], enable);
+
+ return 0;
+}
+
+static int r9a06g032_clk_dualgate_enable(struct clk_hw *hw)
+{
+ struct r9a06g032_clk_dualgate *gate = to_clk_dualgate(hw);
+
+ r9a06g032_clk_dualgate_setenable(gate, 1);
+
+ return 0;
+}
+
+static void r9a06g032_clk_dualgate_disable(struct clk_hw *hw)
+{
+ struct r9a06g032_clk_dualgate *gate = to_clk_dualgate(hw);
+
+ r9a06g032_clk_dualgate_setenable(gate, 0);
+}
+
+static int r9a06g032_clk_dualgate_is_enabled(struct clk_hw *hw)
+{
+ struct r9a06g032_clk_dualgate *g = to_clk_dualgate(hw);
+ uint8_t sel_bit = clk_rdesc_get(g->clocks, g->selector);
+
+ return clk_rdesc_get(g->clocks, g->gate[sel_bit].gate);
+}
+
+static const struct clk_ops r9a06g032_clk_dualgate_ops = {
+ .enable = r9a06g032_clk_dualgate_enable,
+ .disable = r9a06g032_clk_dualgate_disable,
+ .is_enabled = r9a06g032_clk_dualgate_is_enabled,
+};
+
+static struct clk *r9a06g032_register_dualgate(
+ struct r9a06g032_priv *clocks,
+ const char *parent_name,
+ const struct r9a06g032_clkdesc *desc,
+ uint16_t sel)
+{
+ struct r9a06g032_clk_dualgate *g;
+ struct clk *clk;
+ struct clk_init_data init;
+
+ /* allocate the gate */
+ g = kzalloc(sizeof(struct r9a06g032_clk_dualgate), GFP_KERNEL);
+ if (!g)
+ return NULL;
+ g->clocks = clocks;
+ g->index = desc->index;
+ g->selector = sel;
+ g->gate[0].gate = desc->dual.g1;
+ g->gate[0].reset = desc->dual.r1;
+ g->gate[1].gate = desc->dual.g2;
+ g->gate[1].reset = desc->dual.r2;
+
+ init.name = desc->name;
+ init.ops = &r9a06g032_clk_dualgate_ops;
+ init.flags = CLK_IS_BASIC | CLK_SET_RATE_PARENT;
+ init.parent_names = &parent_name;
+ init.num_parents = 1;
+
+ g->hw.init = &init;
+
+ clk = clk_register(NULL, &g->hw);
+ if (IS_ERR(clk)) {
+ kfree(g);
+ return NULL;
+ }
+ return clk;
+}
+
+static void __init r9a06g032_clocks_init(struct device_node *np)
+{
+ struct r9a06g032_priv *clocks;
+ struct clk **clks;
+ unsigned int i;
+ uint16_t uart_group_sel[2];
+
+ clocks = kzalloc(sizeof(*clocks), GFP_KERNEL);
+ clks = kzalloc(R9A06G032_CLOCK_COUNT * sizeof(struct clk *),
+ GFP_KERNEL);
+ if (clocks == NULL || clks == NULL) {
+ /* We're leaking memory on purpose, there's no point in cleaning
+ * up as the system won't boot anyway.
+ */
+ return;
+ }
+ spin_lock_init(&clocks->lock);
+
+ clocks->data.clks = clks;
+ clocks->data.clk_num = R9A06G032_CLOCK_COUNT;
+
+ clocks->reg = of_iomap(np, 0);
+ if (WARN_ON(clocks->reg == NULL))
+ return;
+ for (i = 0; i < ARRAY_SIZE(r9a06g032_clocks); ++i) {
+ const struct r9a06g032_clkdesc *d = &r9a06g032_clocks[i];
+ const char *parent_name = d->source ?
+ __clk_get_name(clocks->data.clks[d->source - 1]) : NULL;
+ struct clk *clk = NULL;
+
+ switch (d->type) {
+ case K_FC:
+ clk = clk_register_fixed_rate(NULL, d->name,
+ parent_name, 0, d->frequency);
+ break;
+ case K_FFC:
+ clk = clk_register_fixed_factor(NULL, d->name,
+ parent_name, 0, 1, d->div);
+ break;
+ case K_GATE:
+ clk = r9a06g032_register_gate(clocks, parent_name, d);
+ break;
+ case K_DIV:
+ clk = r9a06g032_register_divider(clocks,
+ parent_name, d);
+ break;
+ case K_BITSEL:
+ /* keep that selector register around */
+ uart_group_sel[d->dual.group] = d->dual.sel;
+ clk = r9a06g032_register_bitsel(clocks, parent_name, d);
+ break;
+ case K_DUALGATE:
+ clk = r9a06g032_register_dualgate(clocks, parent_name,
+ d, uart_group_sel[d->dual.group]);
+ break;
+ }
+ clocks->data.clks[d->index] = clk;
+ }
+ of_clk_add_provider(np, of_clk_src_onecell_get, &clocks->data);
+}
+CLK_OF_DECLARE(r9a06g032_clks, "renesas,r9a06g032-sysctrl",
+ r9a06g032_clocks_init);
--
2.7.4
^ permalink raw reply related
* [PATCH v7 4/5] ARM: dts: Renesas RZN1D-DB Board base file
From: Michel Pollet @ 2018-05-24 9:28 UTC (permalink / raw)
To: linux-renesas-soc, Simon Horman
Cc: phil.edworthy, Michel Pollet, Michel Pollet, Michael Turquette,
Stephen Boyd, Rob Herring, Mark Rutland, Geert Uytterhoeven,
linux-clk, devicetree, linux-kernel
In-Reply-To: <1527154169-32380-1-git-send-email-michel.pollet@bp.renesas.com>
This adds a base device tree file for the RZN1-DB board, with only the
basic support allowing the system to boot to a prompt. Only one UART is
used, with only a single CPU running.
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts | 29 +++++++++++++++++++++++++++++
2 files changed, 30 insertions(+)
create mode 100644 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f4753b0..6157897 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -814,6 +814,7 @@ dtb-$(CONFIG_ARCH_RENESAS) += \
r8a7793-gose.dtb \
r8a7794-alt.dtb \
r8a7794-silk.dtb \
+ r9a06g032-rzn1d400-db.dtb \
sh73a0-kzm9g.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rv1108-evb.dtb \
diff --git a/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
new file mode 100644
index 0000000..292af58
--- /dev/null
+++ b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the RZN1D-DB Board
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ */
+
+/dts-v1/;
+
+#include "r9a06g032.dtsi"
+
+/ {
+ model = "RZN1D-DB Board";
+ compatible = "renesas,rzn1d400-db",
+ "renesas,r9a06g032";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ aliases {
+ serial0 = &uart0;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v7 3/5] ARM: dts: Renesas R9A06G032 base device tree file
From: Michel Pollet @ 2018-05-24 9:28 UTC (permalink / raw)
To: linux-renesas-soc, Simon Horman
Cc: phil.edworthy, Michel Pollet, Michel Pollet, Michael Turquette,
Stephen Boyd, Rob Herring, Mark Rutland, Geert Uytterhoeven,
linux-clk, devicetree, linux-kernel
In-Reply-To: <1527154169-32380-1-git-send-email-michel.pollet@bp.renesas.com>
This adds the Renesas R9A06G032 bare bone support.
This currently only handles generic parts (gic, architected timer)
and a UART.
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
---
arch/arm/boot/dts/r9a06g032.dtsi | 86 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 86 insertions(+)
create mode 100644 arch/arm/boot/dts/r9a06g032.dtsi
diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
new file mode 100644
index 0000000..9534f1b
--- /dev/null
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Base Device Tree Source for the Renesas RZ/N1D (R9A06G032)
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/r9a06g032-sysctrl.h>
+
+/ {
+ compatible = "renesas,r9a06g032";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0>;
+ clocks = <&sysctrl R9A06G032_DIV_CA7>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <1>;
+ clocks = <&sysctrl R9A06G032_DIV_CA7>;
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&gic>;
+ ranges;
+
+ sysctrl: sysctrl@4000c000 {
+ compatible = "renesas,r9a06g032-sysctrl";
+ reg = <0x4000c000 0x1000>;
+ status = "okay";
+ #clock-cells = <1>;
+ };
+
+ uart0: serial@40060000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x40060000 0x400>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&sysctrl R9A06G032_CLK_UART0>;
+ clock-names = "baudclk";
+ status = "disabled";
+ };
+
+ gic: gic@44101000 {
+ compatible = "arm,cortex-a7-gic", "arm,gic-400";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x44101000 0x1000>, /* Distributer */
+ <0x44102000 0x2000>, /* CPU interface */
+ <0x44104000 0x2000>, /* Virt interface control */
+ <0x44106000 0x2000>; /* Virt CPU interface */
+ interrupts =
+ <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
+ };
+ };
+
+ timer {
+ compatible = "arm,cortex-a7-timer",
+ "arm,armv7-timer";
+ interrupt-parent = <&gic>;
+ arm,cpu-registers-not-fw-configured;
+ always-on;
+ interrupts =
+ <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v7 2/5] dt-bindings: clock: renesas,r9a06g032-sysctrl: documentation
From: Michel Pollet @ 2018-05-24 9:28 UTC (permalink / raw)
To: linux-renesas-soc, Simon Horman
Cc: phil.edworthy, Michel Pollet, Michel Pollet, Michael Turquette,
Stephen Boyd, Rob Herring, Mark Rutland, Geert Uytterhoeven,
linux-clk, devicetree, linux-kernel
In-Reply-To: <1527154169-32380-1-git-send-email-michel.pollet@bp.renesas.com>
The Renesas R9A06G032 SYSCTRL node description.
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
---
.../bindings/clock/renesas,r9a06g032-sysctrl.txt | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt
diff --git a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt
new file mode 100644
index 0000000..63eb66cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt
@@ -0,0 +1,32 @@
+* Renesas R9A06G032 SYSCTRL
+
+Required Properties:
+
+ - compatible: Must be:
+ - "renesas,r9a06g032-sysctrl"
+ - reg: Base address and length of the SYSCTRL IO block.
+ - #clock-cells: Must be 1
+
+Examples
+--------
+
+ - SYSCTRL node:
+
+ sysctrl: sysctrl@4000c000 {
+ compatible = "renesas,r9a06g032-sysctrl";
+ reg = <0x4000c000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ - Other nodes can use the clocks provided by SYSCTRL as in:
+
+ #include <dt-bindings/clock/r9a06g032-sysctrl.h>
+ uart0: serial@40060000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x40060000 0x400>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&sysctrl R9A06G032_CLK_UART0>;
+ clock-names = "baudclk";
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v7 1/5] dt-bindings: Add the r9a06g032-sysctrl.h file
From: Michel Pollet @ 2018-05-24 9:28 UTC (permalink / raw)
To: linux-renesas-soc, Simon Horman
Cc: phil.edworthy, Michel Pollet, Michel Pollet, Michael Turquette,
Stephen Boyd, Rob Herring, Mark Rutland, Geert Uytterhoeven,
linux-clk, devicetree, linux-kernel
In-Reply-To: <1527154169-32380-1-git-send-email-michel.pollet@bp.renesas.com>
This adds the constants necessary to use the renesas,r9a06g032-sysctrl node.
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
include/dt-bindings/clock/r9a06g032-sysctrl.h | 187 ++++++++++++++++++++++++++
1 file changed, 187 insertions(+)
create mode 100644 include/dt-bindings/clock/r9a06g032-sysctrl.h
diff --git a/include/dt-bindings/clock/r9a06g032-sysctrl.h b/include/dt-bindings/clock/r9a06g032-sysctrl.h
new file mode 100644
index 0000000..e3fe69e
--- /dev/null
+++ b/include/dt-bindings/clock/r9a06g032-sysctrl.h
@@ -0,0 +1,187 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * R9A06G032 sysctrl IDs
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
+ * Derived from zx-reboot.c
+ */
+
+#ifndef __DT_BINDINGS_R9A06G032_SYSCTRL_H__
+#define __DT_BINDINGS_R9A06G032_SYSCTRL_H__
+
+#define R9A06G032_CLKOUT 0
+#define R9A06G032_CLK_PLL_USB 1
+#define R9A06G032_CLK_48 1 /* AKA CLK_PLL_USB */
+#define R9A06G032_CLKOUT_D10 2
+#define R9A06G032_CLKOUT_D16 3
+#define R9A06G032_MSEBIS_CLK 3 /* AKA CLKOUT_D16 */
+#define R9A06G032_MSEBIM_CLK 3 /* AKA CLKOUT_D16 */
+#define R9A06G032_CLKOUT_D160 4
+#define R9A06G032_CLKOUT_D1OR2 5
+#define R9A06G032_CLK_DDRPHY_PLLCLK 5 /* AKA CLKOUT_D1OR2 */
+#define R9A06G032_CLKOUT_D20 6
+#define R9A06G032_CLK50 6 /* AKA CLKOUT_D20 */
+#define R9A06G032_CLKOUT_D40 7
+#define R9A06G032_CLK25 7 /* AKA CLKOUT_D40 */
+#define R9A06G032_CLKOUT_D5 8
+#define R9A06G032_CLKOUT_D8 9
+#define R9A06G032_CLK125 9 /* AKA CLKOUT_D8 */
+#define R9A06G032_DIV_ADC 10
+#define R9A06G032_DIV_I2C 11
+#define R9A06G032_DIV_NAND 12
+#define R9A06G032_DIV_P1_PG 13
+#define R9A06G032_DIV_P2_PG 14
+#define R9A06G032_DIV_P3_PG 15
+#define R9A06G032_DIV_P4_PG 16
+#define R9A06G032_DIV_P5_PG 17
+#define R9A06G032_CLK_P5_PG1 17 /* AKA DIV_P5_PG */
+#define R9A06G032_DIV_P6_PG 18
+#define R9A06G032_DIV_QSPI0 19
+#define R9A06G032_DIV_QSPI1 20
+#define R9A06G032_DIV_REF_SYNC 21
+#define R9A06G032_CLK_REF_SYNC 21 /* AKA DIV_REF_SYNC */
+#define R9A06G032_DIV_SDIO0 22
+#define R9A06G032_DIV_SDIO1 23
+#define R9A06G032_DIV_SWITCH 24
+#define R9A06G032_DIV_UART 25
+#define R9A06G032_CLK_25_PG4 26
+#define R9A06G032_CLK_25_PG5 27
+#define R9A06G032_CLK_25_PG6 28
+#define R9A06G032_CLK_25_PG7 29
+#define R9A06G032_CLK_25_PG8 30
+#define R9A06G032_CLK_ADC 31
+#define R9A06G032_CLK_ECAT100 32
+#define R9A06G032_CLK_HSR100 33
+#define R9A06G032_CLK_I2C0 34
+#define R9A06G032_CLK_I2C1 35
+#define R9A06G032_CLK_MII_REF 36
+#define R9A06G032_CLK_NAND 37
+#define R9A06G032_CLK_NOUSBP2_PG6 38
+#define R9A06G032_CLK_P1_PG2 39
+#define R9A06G032_CLK_P1_PG3 40
+#define R9A06G032_CLK_P1_PG4 41
+#define R9A06G032_CLK_P4_PG3 42
+#define R9A06G032_CLK_P4_PG4 43
+#define R9A06G032_CLK_P6_PG1 44
+#define R9A06G032_CLK_P6_PG2 45
+#define R9A06G032_CLK_P6_PG3 46
+#define R9A06G032_CLK_P6_PG4 47
+#define R9A06G032_CLK_PCI_USB 48
+#define R9A06G032_CLK_QSPI0 49
+#define R9A06G032_CLK_QSPI1 50
+#define R9A06G032_CLK_RGMII_REF 51
+#define R9A06G032_CLK_RMII_REF 52
+#define R9A06G032_CLK_SDIO0 53
+#define R9A06G032_CLK_SDIO1 54
+#define R9A06G032_CLK_SERCOS100 55
+#define R9A06G032_CLK_SLCD 56
+#define R9A06G032_CLK_SPI0 57
+#define R9A06G032_CLK_SPI1 58
+#define R9A06G032_CLK_SPI2 59
+#define R9A06G032_CLK_SPI3 60
+#define R9A06G032_CLK_SPI4 61
+#define R9A06G032_CLK_SPI5 62
+#define R9A06G032_CLK_SWITCH 63
+#define R9A06G032_DIV_MOTOR 64
+#define R9A06G032_HCLK_ECAT125 65
+#define R9A06G032_HCLK_PINCONFIG 66
+#define R9A06G032_HCLK_SERCOS 67
+#define R9A06G032_HCLK_SGPIO2 68
+#define R9A06G032_HCLK_SGPIO3 69
+#define R9A06G032_HCLK_SGPIO4 70
+#define R9A06G032_HCLK_TIMER0 71
+#define R9A06G032_HCLK_TIMER1 72
+#define R9A06G032_HCLK_USBF 73
+#define R9A06G032_HCLK_USBH 74
+#define R9A06G032_HCLK_USBPM 75
+#define R9A06G032_CLK_48_PG_F 76
+#define R9A06G032_CLK_48_PG4 77
+#define R9A06G032_CLK_DDRPHY_PLLCLK_D4 78
+#define R9A06G032_CLK_ECAT100_D4 79
+#define R9A06G032_CLK_HSR100_D2 80
+#define R9A06G032_CLK_REF_SYNC_D4 81
+#define R9A06G032_CLK_DDRPHY_PCLK 81 /* AKA CLK_REF_SYNC_D4 */
+#define R9A06G032_CLK_FW 81 /* AKA CLK_REF_SYNC_D4 */
+#define R9A06G032_CLK_CRYPTO 81 /* AKA CLK_REF_SYNC_D4 */
+#define R9A06G032_CLK_REF_SYNC_D8 82
+#define R9A06G032_CLK_SERCOS100_D2 83
+#define R9A06G032_DIV_CA7 84
+#define R9A06G032_CLK_A7MP 84 /* AKA DIV_CA7 */
+#define R9A06G032_HCLK_CAN0 85
+#define R9A06G032_HCLK_CAN1 86
+#define R9A06G032_HCLK_DELTASIGMA 87
+#define R9A06G032_HCLK_PWMPTO 88
+#define R9A06G032_HCLK_RSV 89
+#define R9A06G032_HCLK_SGPIO0 90
+#define R9A06G032_HCLK_SGPIO1 91
+#define R9A06G032_RTOS_MDC 92
+#define R9A06G032_CLK_CM3 93
+#define R9A06G032_CLK_DDRC 94
+#define R9A06G032_CLK_ECAT25 95
+#define R9A06G032_CLK_HSR50 96
+#define R9A06G032_CLK_HW_RTOS 97
+#define R9A06G032_CLK_SERCOS50 98
+#define R9A06G032_HCLK_ADC 99
+#define R9A06G032_HCLK_CM3 100
+#define R9A06G032_HCLK_CRYPTO_EIP150 101
+#define R9A06G032_HCLK_CRYPTO_EIP93 102
+#define R9A06G032_HCLK_DDRC 103
+#define R9A06G032_HCLK_DMA0 104
+#define R9A06G032_HCLK_DMA1 105
+#define R9A06G032_HCLK_GMAC0 106
+#define R9A06G032_HCLK_GMAC1 107
+#define R9A06G032_HCLK_GPIO0 108
+#define R9A06G032_HCLK_GPIO1 109
+#define R9A06G032_HCLK_GPIO2 110
+#define R9A06G032_HCLK_HSR 111
+#define R9A06G032_HCLK_I2C0 112
+#define R9A06G032_HCLK_I2C1 113
+#define R9A06G032_HCLK_LCD 114
+#define R9A06G032_HCLK_MSEBI_M 115
+#define R9A06G032_HCLK_MSEBI_S 116
+#define R9A06G032_HCLK_NAND 117
+#define R9A06G032_HCLK_PG_I 118
+#define R9A06G032_HCLK_PG19 119
+#define R9A06G032_HCLK_PG20 120
+#define R9A06G032_HCLK_PG3 121
+#define R9A06G032_HCLK_PG4 122
+#define R9A06G032_HCLK_QSPI0 123
+#define R9A06G032_HCLK_QSPI1 124
+#define R9A06G032_HCLK_ROM 125
+#define R9A06G032_HCLK_RTC 126
+#define R9A06G032_HCLK_SDIO0 127
+#define R9A06G032_HCLK_SDIO1 128
+#define R9A06G032_HCLK_SEMAP 129
+#define R9A06G032_HCLK_SPI0 130
+#define R9A06G032_HCLK_SPI1 131
+#define R9A06G032_HCLK_SPI2 132
+#define R9A06G032_HCLK_SPI3 133
+#define R9A06G032_HCLK_SPI4 134
+#define R9A06G032_HCLK_SPI5 135
+#define R9A06G032_HCLK_SWITCH 136
+#define R9A06G032_HCLK_SWITCH_RG 137
+#define R9A06G032_HCLK_UART0 138
+#define R9A06G032_HCLK_UART1 139
+#define R9A06G032_HCLK_UART2 140
+#define R9A06G032_HCLK_UART3 141
+#define R9A06G032_HCLK_UART4 142
+#define R9A06G032_HCLK_UART5 143
+#define R9A06G032_HCLK_UART6 144
+#define R9A06G032_HCLK_UART7 145
+#define R9A06G032_CLK_UART0 146
+#define R9A06G032_CLK_UART1 147
+#define R9A06G032_CLK_UART2 148
+#define R9A06G032_CLK_UART3 149
+#define R9A06G032_CLK_UART4 150
+#define R9A06G032_CLK_UART5 151
+#define R9A06G032_CLK_UART6 152
+#define R9A06G032_CLK_UART7 153
+
+#define R9A06G032_UART_GROUP_012 154
+#define R9A06G032_UART_GROUP_34567 155
+
+#define R9A06G032_CLOCK_COUNT (R9A06G032_UART_GROUP_34567 + 1)
+
+#endif /* __DT_BINDINGS_R9A06G032_SYSCTRL_H__ */
--
2.7.4
^ permalink raw reply related
* [PATCH v7 0/5] arm: Base support for Renesas RZN1D-DB Board
From: Michel Pollet @ 2018-05-24 9:28 UTC (permalink / raw)
To: linux-renesas-soc, Simon Horman
Cc: phil.edworthy, Michel Pollet, Michel Pollet, Michael Turquette,
Stephen Boyd, Rob Herring, Mark Rutland, Geert Uytterhoeven,
linux-clk, devicetree, linux-kernel
This series adds the plain basic support for booting a bare
kernel on the RZ/N1D-DB Board. It's been trimmed to the strict
minimum as a 'base', further patches that could add the
rest of the support.
Note on the clock driver: Current usage of the clocks on Linux
involves Linux 'claiming' all of them, disabling the one it doesn't
need and so on.
On *this* architecture it can't be done, there is at least one other
OS running on the CM3 core that claims it's own clock; Linux can claim
some others but definitely not start disabling stuff it isn't supposed to.
Thanks for the comments on the previous versions!
v7:
+ Removed mention of 'rz[/]n1' from everywhere.
+ Removed unwanted documentation.
+ Renamed clock node back to sysctrl.
+ Renamed rzn1-clocks.h to r9a06g032-sysctrl.h to match
+ Made the clock driver claim the sysctrl node.
+ Fixed a couple of 'sparse' warning in the clock driver.
v6:
+ Fix for suggestion by Geert Uytterhoeven
+ Removed "renesas,rzn1" from the board bindings
+ Removed patches already merged.
+ Removed reboot driver
+ Added a whole clock infrastructure.
+ Rebased on next-20180517
v5:
+ Given the problems I have with getting in some structure around the
sysctrl block, I've removed the MFD, I've now attached the reboot
driver on it's own pair of registers.
+ Rebased on next-20180417
v4:
+ Fixes for suggestions by Simon Horman
+ Fixes for suggestions by Jacopo Mondi
+ Fixes for suggestions by Geert Uytterhoeven
+ Renamed the r9a06g0xx.dtsi file, given up on trying to get a family
common file in, so dropped potential RZ/N1S support and now only
focus on RZ/N1D for this patchset.
+ Added 'always-on' to the architected timer node, because it is.
+ Added ARCH_R9A06G032, to match others patterns like RCAR
+ Sorted the .dts files, added empty lines as required.
+ Fixed patch prefixes to match git-log for bindings&dts
+ Merged board .dts & Makefile changes together
+ Rebased on next-20180410
v3:
+ Fixes for suggestions by Geert Uytterhoeven
+ Removed SoC Specific renesas,r9a06g032-xxx, as it's not needed for now.
+ Kept renesas,rzn1 as a family/generic for this family.
+ Fixed a couple of the commit messages.
+ Added Geert's Reviewed-By where appropriate.
v2:
+ Fixes for suggestions by Simon Horman
+ Fixes for suggestions by Rob Herring
+ Fixes for suggestions by Geert Uytterhoeven
+ Removed the mach file
+ Added a MFD base for the sysctrl block
+ Added a regmap based sub driver for the reboot handler
+ Renamed the files to match shmobile conventions
+ Adapted the compatible= strings to reflect 'family' vs 'part'
distinction.
+ Removed the sysctrl.h file entirelly.
+ Fixed every warnings from the DTC compiler on W=12 mode.
+ Split the device-tree patches from the code.
Michel Pollet (5):
dt-bindings: Add the r9a06g032-sysctrl.h file
dt-bindings: clock: renesas,r9a06g032-sysctrl: documentation
ARM: dts: Renesas R9A06G032 base device tree file
ARM: dts: Renesas RZN1D-DB Board base file
clk: renesas: Renesas R9A06G032 clock driver
.../bindings/clock/renesas,r9a06g032-sysctrl.txt | 32 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts | 29 +
arch/arm/boot/dts/r9a06g032.dtsi | 86 +++
drivers/clk/renesas/Kconfig | 6 +
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r9a06g032-clocks.c | 812 +++++++++++++++++++++
include/dt-bindings/clock/r9a06g032-sysctrl.h | 187 +++++
8 files changed, 1154 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt
create mode 100644 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
create mode 100644 arch/arm/boot/dts/r9a06g032.dtsi
create mode 100644 drivers/clk/renesas/r9a06g032-clocks.c
create mode 100644 include/dt-bindings/clock/r9a06g032-sysctrl.h
--
2.7.4
^ permalink raw reply
* Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers"
From: Qiang Yu @ 2018-05-24 9:24 UTC (permalink / raw)
To: Christian König
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Erico Nunes
In-Reply-To: <75f682e9-5b31-ad82-441f-b2c250edc0a0@amd.com>
On Thu, May 24, 2018 at 2:46 PM, Christian König
<christian.koenig@amd.com> wrote:
> Am 24.05.2018 um 03:38 schrieb Qiang Yu:
>
> [SNIP]
>
> Adding fence is done already, and I did wait it before unmap. But then
> I see when
> the buffer is shared between processes, the "perfect wait" is just
> wait the fence
> from this process's task, so it's better to also distinguish fences.
> If so, I just think
> why we don't just wait tasks from this process in the preclose before
> unmap/free
> buffer in the drm_release()?
>
> Well it depends on your VM management. When userspace expects that the VM
> space the BO used is reusable immediately than the TTM callback won't work.
>
> On the other hand you can just grab the list of fences on a BO and filter
> out the ones from your current process and wait for those. See
> amdgpu_sync_resv() as an example how to do that.
>
> In current lima implementation, user space driver is responsible not
> unmap/free
> buffer before task is complete. And VM map/unmap is not differed.
>
>
> Well it's up to you how to design userspace, but in the past doing it like
> that turned out to be a rather bad design decision.
>
> Keep in mind that the kernel driver must guarantee that a shaders can never
> access freed up memory.
>
> Otherwise taking over the system from an unprivileged processes becomes just
> a typing exercise when you manage to access freed memory which is now used
> for a page table.
Right, I know this has to be avoided.
>
> Because of this we have a separate tracking in amdgpu so that we not only
> know who is using which BO, who is using which VM.
amdgpu's VM implementation seems too complicated for this simple mali GPU,
but I may investigate it more to see if I can make it better.
>
> This works simple and fine except the case that user press Ctrl+C to
> terminate
> the application which will force to close drm fd.
>
>
> I'm not sure if that actually works as fine as you think.
>
> For an example of what we had to add to prevent security breaches, take a
> look at amdgpu_gem_object_close().
>
> I'd more prefer to wait buffer fence before vm unmap and filter like
> amdgpu_sync_resv() compared to implement refcount in kernel task.
> But these two ways are all not as simple as preclose.
>
>
> Well, I would rather say you should either delay VM unmap operations until
> all users of the VM are done with their work using the ttm_bo_destroy
> callback.
>
> Or you block in the gem_close_object callback until all tasks using the BO
> are done with it.
>
> So I still don't understand why you don't want to get preclose back even
> have to introduce other complicated mechanism to cover the case free/unmap
> buffer before this process's task is done?
>
>
> We intentionally removed the preclose callback to prevent certain use cases,
> bringing it back to allow your use case looks rather fishy to me.
Seems other drivers do either the deffer or wait way to adopt the drop
of preclose. I can do the same as you suggested, but just not understand why
we make our life harder. Can I know what's the case you want to prevent?
>
> BTW: What exactly is the issue with using the postclose callback?
The issue is, when Ctrl+C to terminate an application, if no wait or deffer
unmap, buffer just gets unmapped before task is done, so kernel driver
gets MMU fault and HW reset to recover the GPU.
Regards,
Qiang
>
> Regards,
> Christian.
>
>
> Regards,
> Qiang
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: OMAP serial runtime PM and autosuspend (was: Re: [PATCH 4/7] dt-bindings: gnss: add u-blox binding))
From: Johan Hovold @ 2018-05-24 9:17 UTC (permalink / raw)
To: Tony Lindgren
Cc: Johan Hovold, Sebastian Reichel, H. Nikolaus Schaller,
Andreas Kemnade, Mark Rutland, Arnd Bergmann, Pavel Machek,
linux-kernel@vger.kernel.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Rob Herring, linux-serial, linux-omap,
linux-pm
In-Reply-To: <20180521154832.GY98604@atomide.com>
On Mon, May 21, 2018 at 08:48:32AM -0700, Tony Lindgren wrote:
> * Johan Hovold <johan@kernel.org> [180521 13:50]:
> > On Thu, May 17, 2018 at 10:10:38AM -0700, Tony Lindgren wrote:
> > > * Johan Hovold <johan@kernel.org> [180517 10:12]:
> > > Well in that case we should just stick with -1 value for the
> > > autosuspend. And just do pm_runtime_put_sync_suspend() after
> > > probe and on close.
> >
> > That won't work either as a negative autosuspend delay prevents runtime
> > suspend completely (by grabbing an extra RPM reference).
>
> Well so negative autosuspend delay is working as documented then :)
Yes, indeed. All too well. ;)
> > > > I fail to see how we can implement this using the current toolbox. What
> > > > you're after here is really a mechanism for selecting between two
> > > > different runtime PM schemes at runtime:
> > > >
> > > > 1. normal serial RPM, where the controller is active while the
> > > > port is open (this should be the safe default)
> > >
> > > Agreed. And that is the case already.
> >
> > Yes, but it's not really the case today as since omap-serial (and
> > 8250-omap) sets a negative autosuspend at probe and hence does not
> > runtime-suspend when the port is closed. So that's the long-standing bug
> > which needs fixing.
>
> Yes the bug for closed ports needs to be fixed for sure.
I did some forensic on this and it seems this problem has "always" been
there. Specifically, closed ports have never been runtime suspended
unless a non-negative autosuspend delay has been set by user space since
fcdca75728ac ("ARM: OMAP2+: UART: Add runtime pm support for omap-serial
driver") which was merged seven years ago.
So while it would certainly be nice to save some more power by default,
this would really be a new feature rather than a bug or regression fix
(which reduces the urgency for this issue somewhat too).
> > > > 2. aggressive serial RPM, where the controller is allowed to
> > > > suspend while the port is open even though this may result in
> > > > lost characters when waking up on incoming data
> > >
> > > In this case it seems that the only thing needed is to just
> > > configure the autosuspend delay for the parent port. The use of
> > > -1 has been around since the start of runtime PM AFAIK, so maybe
> > > we should just document it. I guess we could also introduce
> > > pm_runtime_block_autoidle_unless_configured() :)
> >
> > The implications of a negative autosuspend delay are already documented
> > (in Documentation/power/runtime_pm.txt); it's just the omap drivers that
> > gets it wrong when trying to do things which aren't currently supported
> > (and never have been).
> >
> > So I still think we need a new mechanism for this.
>
> Well if you have some better mechanism in mind let's try it out. Short of
> sprinkling pm_runtime_force_suspend/resume calls all over, I'm out of ideas
> right now.
Yeah, that would be too much of a hack and likely wouldn't work either
(and we really should do away with those _force calls altogether).
I've been thinking a bit too much about this already, but it may be
possible to use the pm QoS framework for this. A resume latency can be
set through sysfs where "n/a" is defined to mean "no latency accepted"
(i.e. controller remains always-on while port is open) and "0" means
"any latency accepted" (i.e. omap aggressive serial RPM is allowed).
Now, implementing this may get a little tricky as we want to be able to
change this setting on the fly (consider consoles) and we need to figure
out the interaction with serdev (user space should probably not be
allowed to request a resume latency for ports used by serdev).
I'd be happy to dig into this some more, but not in my spare time I'm
afraid.
> > > > For normal ttys, we need a user-space interface for selecting between
> > > > the two, and for serdev we may want a way to select the RPM scheme from
> > > > within the kernel.
> > > >
> > > > Note that with my serdev controller runtime PM patch, serdev core could
> > > > always opt for aggressive PM (as by default serdev core holds an RPM
> > > > reference for the controller while the port is open).
> > >
> > > So if your serdev controller was to set the parent autosuspend
> > > delay on open() and set it back on close() this should work?
> >
> > Is it really the job of a serdev driver to set the autosuspend delay of
> > a parent controller? Isn't this somethings which depends on the
> > characteristics of the controller (possibly configurable by user space)
> > such as the cost of runtime suspending and resuming?
>
> Only in some cases will the serdev driver know it's safe to configure
> the parent controller. Configuring the parent controller from userspace
> works just fine as we've seen for years now.
Yes, user space may override the default settings provided by the serial
driver, but a serdev driver, in contrast, knows nothing about the
underlying serial hardware.
> > The patch I posted works with what we have today; if a parent serial
> > controller driver uses aggressive runtime PM by default or after having
> > been configured through sysfs to do so.
>
> Yeah let's stick with configuring the parent controller from userspace
> for now at least.
Yep, status quo works for the time being (since this isn't a
regression).
> > What I'm getting at here is that the delay should be set by the serial
> > driver implementing aggressive runtime PM. Then all we need is a
> > mechanism to determine whether an extra RPM reference should be taken at
> > tty open or not (configurable by user space, defaulting to yes).
>
> OK yeah some additional on/off switch seems to be missing here.
As mentioned above, PM QoS resume latency may possibly be used, and
otherwise me may able to define a new (generic) QoS flag for this.
> > Specifically, the serial drivers themselves would always use
> > autosuspend and not have to deal with supporting the two RPM schemes
> > (normal vs aggressive runtime PM).
>
> OK. So if I understand your idea right, we could have autosuspend timeout
> set to 3000ms in the 8250_omap.c but still default to RPM blocked?
> Then user can enable aggressive PM via /sys as desired, right?
Not RPM blocked; the ports must always be able to suspend when the port
is closed. But user space should be able to enable the aggressive
(active) runtime PM via sysfs independently of the autosuspend delay,
yes.
Thanks,
Johan
^ permalink raw reply
* Re: [PATCH v12 0/2] Kryo CPU scaling driver
From: Viresh Kumar @ 2018-05-24 9:02 UTC (permalink / raw)
To: Ilia Lin
Cc: vireshk, nm, sboyd, robh, mark.rutland, rjw, linux-pm, devicetree,
linux-kernel
In-Reply-To: <1527152242-31281-1-git-send-email-ilialin@codeaurora.org>
On 24-05-18, 11:57, Ilia Lin wrote:
> [v12]
> * Addressed comments from Sudeep and Viresh about the single init
>
> [v11]
> * Addressed comment from Russel about device_node reference
> * Addressed comment from Sudeep about the late_initcall
> * Transformed init into probe to take care of deferals
>
> [v10]
> * Split the series into domains
> * Addressed comments from Viresh and Sudeep about logical CPU numbering.
>
> The qcom-cpufreq-kryo driver is aimed to support different SOC versions.
> The driver reads eFuse information and chooses the required OPP subset
> by passing the OPP supported-hw parameter.
>
> The series depends on the series from Viresh:
> https://patchwork.kernel.org/patch/10418139/
>
> The previous spin was here:
> https://patchwork.kernel.org/patch/10421143/
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v12 2/2] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu
From: Ilia Lin @ 2018-05-24 8:57 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh, mark.rutland, rjw
Cc: linux-pm, devicetree, linux-kernel, ilialin
In-Reply-To: <1527152242-31281-1-git-send-email-ilialin@codeaurora.org>
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
This change adds documentation for the DT bindings.
The "operating-points-v2-kryo-cpu" DT extends the "operating-points-v2"
with following parameters:
- nvmem-cells (NVMEM area containig the speedbin information)
- opp-supported-hw: A single 32 bit bitmap value,
representing compatible HW:
0: MSM8996 V3, speedbin 0
1: MSM8996 V3, speedbin 1
2: MSM8996 V3, speedbin 2
3: unused
4: MSM8996 SG, speedbin 0
5: MSM8996 SG, speedbin 1
6: MSM8996 SG, speedbin 2
7-31: unused
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
.../devicetree/bindings/opp/kryo-cpufreq.txt | 680 +++++++++++++++++++++
1 file changed, 680 insertions(+)
create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
diff --git a/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt b/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
new file mode 100644
index 0000000..c2127b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
@@ -0,0 +1,680 @@
+Qualcomm Technologies, Inc. KRYO CPUFreq and OPP bindings
+===================================
+
+In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996
+that have KRYO processors, the CPU ferequencies subset and voltage value
+of each OPP varies based on the silicon variant in use.
+Qualcomm Technologies, Inc. Process Voltage Scaling Tables
+defines the voltage and frequency value based on the msm-id in SMEM
+and speedbin blown in the efuse combination.
+The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+to provide the OPP framework with required information (existing HW bitmap).
+This is used to determine the voltage and frequency value for each OPP of
+operating-points-v2 table when it is parsed by the OPP framework.
+
+Required properties:
+--------------------
+In 'cpus' nodes:
+- operating-points-v2: Phandle to the operating-points-v2 table to use.
+
+In 'operating-points-v2' table:
+- compatible: Should be
+ - 'operating-points-v2-kryo-cpu' for apq8096 and msm8996.
+- nvmem-cells: A phandle pointing to a nvmem-cells node representing the
+ efuse registers that has information about the
+ speedbin that is used to select the right frequency/voltage
+ value pair.
+ Please refer the for nvmem-cells
+ bindings Documentation/devicetree/bindings/nvmem/nvmem.txt
+ and also examples below.
+
+In every OPP node:
+- opp-supported-hw: A single 32 bit bitmap value, representing compatible HW.
+ Bitmap:
+ 0: MSM8996 V3, speedbin 0
+ 1: MSM8996 V3, speedbin 1
+ 2: MSM8996 V3, speedbin 2
+ 3: unused
+ 4: MSM8996 SG, speedbin 0
+ 5: MSM8996 SG, speedbin 1
+ 6: MSM8996 SG, speedbin 2
+ 7-31: unused
+
+Example 1:
+---------
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ clocks = <&kryocc 0>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster0_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_0>;
+ L2_0: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ };
+ };
+
+ CPU1: cpu@1 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ clocks = <&kryocc 0>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster0_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_0>;
+ };
+
+ CPU2: cpu@100 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ clocks = <&kryocc 1>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster1_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_1>;
+ L2_1: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ };
+ };
+
+ CPU3: cpu@101 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x101>;
+ enable-method = "psci";
+ clocks = <&kryocc 1>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster1_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_1>;
+ };
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&CPU0>;
+ };
+
+ core1 {
+ cpu = <&CPU1>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&CPU2>;
+ };
+
+ core1 {
+ cpu = <&CPU3>;
+ };
+ };
+ };
+ };
+
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2-kryo-cpu";
+ nvmem-cells = <&speedbin_efuse>;
+ opp-shared;
+
+ opp-307200000 {
+ opp-hz = /bits/ 64 <307200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-422400000 {
+ opp-hz = /bits/ 64 <422400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-460800000 {
+ opp-hz = /bits/ 64 <460800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-537600000 {
+ opp-hz = /bits/ 64 <537600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-556800000 {
+ opp-hz = /bits/ 64 <556800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-652800000 {
+ opp-hz = /bits/ 64 <652800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-691200000 {
+ opp-hz = /bits/ 64 <691200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-729600000 {
+ opp-hz = /bits/ 64 <729600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-768000000 {
+ opp-hz = /bits/ 64 <768000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-844800000 {
+ opp-hz = /bits/ 64 <844800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-902400000 {
+ opp-hz = /bits/ 64 <902400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-960000000 {
+ opp-hz = /bits/ 64 <960000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-979200000 {
+ opp-hz = /bits/ 64 <979200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1036800000 {
+ opp-hz = /bits/ 64 <1036800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1056000000 {
+ opp-hz = /bits/ 64 <1056000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1113600000 {
+ opp-hz = /bits/ 64 <1113600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1132800000 {
+ opp-hz = /bits/ 64 <1132800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1190400000 {
+ opp-hz = /bits/ 64 <1190400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1209600000 {
+ opp-hz = /bits/ 64 <1209600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1228800000 {
+ opp-hz = /bits/ 64 <1228800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1286400000 {
+ opp-hz = /bits/ 64 <1286400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1324800000 {
+ opp-hz = /bits/ 64 <1324800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x5>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1363200000 {
+ opp-hz = /bits/ 64 <1363200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x72>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1401600000 {
+ opp-hz = /bits/ 64 <1401600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x5>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1440000000 {
+ opp-hz = /bits/ 64 <1440000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1478400000 {
+ opp-hz = /bits/ 64 <1478400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1497600000 {
+ opp-hz = /bits/ 64 <1497600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x4>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1516800000 {
+ opp-hz = /bits/ 64 <1516800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1593600000 {
+ opp-hz = /bits/ 64 <1593600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x71>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1996800000 {
+ opp-hz = /bits/ 64 <1996800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x20>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2188800000 {
+ opp-hz = /bits/ 64 <2188800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ };
+
+ cluster1_opp: opp_table1 {
+ compatible = "operating-points-v2-kryo-cpu";
+ nvmem-cells = <&speedbin_efuse>;
+ opp-shared;
+
+ opp-307200000 {
+ opp-hz = /bits/ 64 <307200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-403200000 {
+ opp-hz = /bits/ 64 <403200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-460800000 {
+ opp-hz = /bits/ 64 <460800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-537600000 {
+ opp-hz = /bits/ 64 <537600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-556800000 {
+ opp-hz = /bits/ 64 <556800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-652800000 {
+ opp-hz = /bits/ 64 <652800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-691200000 {
+ opp-hz = /bits/ 64 <691200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-729600000 {
+ opp-hz = /bits/ 64 <729600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-748800000 {
+ opp-hz = /bits/ 64 <748800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-806400000 {
+ opp-hz = /bits/ 64 <806400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-825600000 {
+ opp-hz = /bits/ 64 <825600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-883200000 {
+ opp-hz = /bits/ 64 <883200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-902400000 {
+ opp-hz = /bits/ 64 <902400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-940800000 {
+ opp-hz = /bits/ 64 <940800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-979200000 {
+ opp-hz = /bits/ 64 <979200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1036800000 {
+ opp-hz = /bits/ 64 <1036800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1056000000 {
+ opp-hz = /bits/ 64 <1056000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1113600000 {
+ opp-hz = /bits/ 64 <1113600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1132800000 {
+ opp-hz = /bits/ 64 <1132800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1190400000 {
+ opp-hz = /bits/ 64 <1190400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1209600000 {
+ opp-hz = /bits/ 64 <1209600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1248000000 {
+ opp-hz = /bits/ 64 <1248000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1286400000 {
+ opp-hz = /bits/ 64 <1286400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1324800000 {
+ opp-hz = /bits/ 64 <1324800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1363200000 {
+ opp-hz = /bits/ 64 <1363200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1401600000 {
+ opp-hz = /bits/ 64 <1401600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1440000000 {
+ opp-hz = /bits/ 64 <1440000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1478400000 {
+ opp-hz = /bits/ 64 <1478400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1516800000 {
+ opp-hz = /bits/ 64 <1516800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1555200000 {
+ opp-hz = /bits/ 64 <1555200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1593600000 {
+ opp-hz = /bits/ 64 <1593600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1632000000 {
+ opp-hz = /bits/ 64 <1632000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1670400000 {
+ opp-hz = /bits/ 64 <1670400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1708800000 {
+ opp-hz = /bits/ 64 <1708800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1747200000 {
+ opp-hz = /bits/ 64 <1747200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1785600000 {
+ opp-hz = /bits/ 64 <1785600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1804800000 {
+ opp-hz = /bits/ 64 <1804800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x6>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1824000000 {
+ opp-hz = /bits/ 64 <1824000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x71>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1900800000 {
+ opp-hz = /bits/ 64 <1900800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x74>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1920000000 {
+ opp-hz = /bits/ 64 <1920000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1977600000 {
+ opp-hz = /bits/ 64 <1977600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x30>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1996800000 {
+ opp-hz = /bits/ 64 <1996800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2054400000 {
+ opp-hz = /bits/ 64 <2054400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x30>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2073600000 {
+ opp-hz = /bits/ 64 <2073600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2150400000 {
+ opp-hz = /bits/ 64 <2150400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x31>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2246400000 {
+ opp-hz = /bits/ 64 <2246400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2342400000 {
+ opp-hz = /bits/ 64 <2342400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ };
+
+....
+
+reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+....
+ smem_mem: smem-mem@86000000 {
+ reg = <0x0 0x86000000 0x0 0x200000>;
+ no-map;
+ };
+....
+};
+
+smem {
+ compatible = "qcom,smem";
+ memory-region = <&smem_mem>;
+ hwlocks = <&tcsr_mutex 3>;
+};
+
+soc {
+....
+ qfprom: qfprom@74000 {
+ compatible = "qcom,qfprom";
+ reg = <0x00074000 0x8ff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ....
+ speedbin_efuse: speedbin@133 {
+ reg = <0x133 0x1>;
+ bits = <5 3>;
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v12 1/2] cpufreq: Add Kryo CPU scaling driver
From: Ilia Lin @ 2018-05-24 8:57 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh, mark.rutland, rjw
Cc: linux-pm, devicetree, linux-kernel, ilialin
In-Reply-To: <1527152242-31281-1-git-send-email-ilialin@codeaurora.org>
In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
the CPU frequency subset and voltage value of each OPP varies
based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
defines the voltage and frequency value based on the msm-id in SMEM
and speedbin blown in the efuse combination.
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
---
drivers/cpufreq/Kconfig.arm | 10 ++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 194 +++++++++++++++++++++++++++++++++++
4 files changed, 208 insertions(+)
create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index de55c7d..0bfd40e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -124,6 +124,16 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
+config ARM_QCOM_CPUFREQ_KRYO
+ bool "Qualcomm Kryo based CPUFreq"
+ depends on QCOM_QFPROM
+ depends on QCOM_SMEM
+ select PM_OPP
+ help
+ This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
+
+ If in doubt, say N.
+
config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d24ade..fb4a2ec 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.o
obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3b585e4..77d6ab8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -118,6 +118,9 @@
{ .compatible = "nvidia,tegra124", },
+ { .compatible = "qcom,apq8096", },
+ { .compatible = "qcom,msm8996", },
+
{ .compatible = "st,stih407", },
{ .compatible = "st,stih410", },
diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c b/drivers/cpufreq/qcom-cpufreq-kryo.c
new file mode 100644
index 0000000..9fe379c
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
@@ -0,0 +1,194 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+/*
+ * In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
+ * the CPU frequency subset and voltage value of each OPP varies
+ * based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
+ * defines the voltage and frequency value based on the msm-id in SMEM
+ * and speedbin blown in the efuse combination.
+ * The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+ * to provide the OPP framework with required information.
+ * This is used to determine the voltage and frequency value for each OPP of
+ * operating-points-v2 table when it is parsed by the OPP framework.
+ */
+
+#include <linux/cpu.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+#include <linux/soc/qcom/smem.h>
+
+#define MSM_ID_SMEM 137
+
+enum _msm_id {
+ MSM8996V3 = 0xF6ul,
+ APQ8096V3 = 0x123ul,
+ MSM8996SG = 0x131ul,
+ APQ8096SG = 0x138ul,
+};
+
+enum _msm8996_version {
+ MSM8996_V3,
+ MSM8996_SG,
+ NUM_OF_MSM8996_VERSIONS,
+};
+
+static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void)
+{
+ size_t len;
+ u32 *msm_id;
+ enum _msm8996_version version;
+
+ msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len);
+ /* The first 4 bytes are format, next to them is the actual msm-id */
+ msm_id++;
+
+ switch ((enum _msm_id)*msm_id) {
+ case MSM8996V3:
+ case APQ8096V3:
+ version = MSM8996_V3;
+ break;
+ case MSM8996SG:
+ case APQ8096SG:
+ version = MSM8996_SG;
+ break;
+ default:
+ version = NUM_OF_MSM8996_VERSIONS;
+ }
+
+ return version;
+}
+
+static int qcom_cpufreq_kryo_probe(struct platform_device *pdev)
+{
+ struct opp_table *opp_tables[NR_CPUS] = {0};
+ struct platform_device *cpufreq_dt_pdev;
+ enum _msm8996_version msm8996_version;
+ struct nvmem_cell *speedbin_nvmem;
+ struct device_node *np;
+ struct device *cpu_dev;
+ unsigned cpu;
+ u8 *speedbin;
+ u32 versions;
+ size_t len;
+ int ret;
+
+ cpu_dev = get_cpu_device(0);
+ if (NULL == cpu_dev)
+ return -ENODEV;
+
+ msm8996_version = qcom_cpufreq_kryo_get_msm_id();
+ if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
+ dev_err(cpu_dev, "Not Snapdragon 820/821!");
+ return -ENODEV;
+ }
+
+ np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
+ if (IS_ERR(np))
+ return PTR_ERR(np);
+
+ if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
+ of_node_put(np);
+ return -ENOENT;
+ }
+
+ speedbin_nvmem = of_nvmem_cell_get(np, NULL);
+ of_node_put(np);
+ if (IS_ERR(speedbin_nvmem)) {
+ dev_err(cpu_dev, "Could not get nvmem cell: %ld\n",
+ PTR_ERR(speedbin_nvmem));
+ return PTR_ERR(speedbin_nvmem);
+ }
+
+ speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ nvmem_cell_put(speedbin_nvmem);
+
+ switch (msm8996_version) {
+ case MSM8996_V3:
+ versions = 1 << (unsigned int)(*speedbin);
+ break;
+ case MSM8996_SG:
+ versions = 1 << ((unsigned int)(*speedbin) + 4);
+ break;
+ default:
+ BUG();
+ break;
+ }
+
+ for_each_possible_cpu(cpu) {
+ cpu_dev = get_cpu_device(cpu);
+ if (NULL == cpu_dev) {
+ ret = -ENODEV;
+ goto free_opp;
+ }
+
+ opp_tables[cpu] = dev_pm_opp_set_supported_hw(cpu_dev,
+ &versions, 1);
+ if (IS_ERR(opp_tables[cpu])) {
+ ret = PTR_ERR(opp_tables[cpu]);
+ dev_err(cpu_dev, "Failed to set supported hardware\n");
+ goto free_opp;
+ }
+ }
+
+ cpufreq_dt_pdev = platform_device_register_simple("cpufreq-dt", -1,
+ NULL, 0);
+ if (!IS_ERR(cpufreq_dt_pdev))
+ return 0;
+
+ ret = PTR_ERR(cpufreq_dt_pdev);
+ dev_err(cpu_dev, "Failed to register platform device\n");
+
+free_opp:
+ for_each_possible_cpu(cpu) {
+ if (IS_ERR_OR_NULL(opp_tables[cpu]))
+ break;
+ dev_pm_opp_put_supported_hw(opp_tables[cpu]);
+ }
+
+ return ret;
+}
+
+static struct platform_driver qcom_cpufreq_kryo_driver = {
+ .probe = qcom_cpufreq_kryo_probe,
+ .driver = {
+ .name = "qcom-cpufreq-kryo",
+ },
+};
+
+/*
+ * Since the driver depends on smem and nvmem drivers, which may
+ * return EPROBE_DEFER, all the real activity is done in the probe,
+ * which may be defered as well. The init here is only registering
+ * the driver and the platform device.
+ */
+static int __init qcom_cpufreq_kryo_init(void)
+{
+ int ret;
+
+ ret = platform_driver_register(&qcom_cpufreq_kryo_driver);
+ if (unlikely(ret < 0))
+ return ret;
+
+ ret = PTR_ERR_OR_ZERO(platform_device_register_simple(
+ "qcom-cpufreq-kryo", -1, NULL, 0));
+ if (unlikely(ret < 0)) {
+ platform_driver_unregister(&qcom_cpufreq_kryo_driver);
+ return ret;
+ }
+
+ return 0;
+}
+module_init(qcom_cpufreq_kryo_init);
+
+MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH v12 0/2] Kryo CPU scaling driver
From: Ilia Lin @ 2018-05-24 8:57 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh, mark.rutland, rjw
Cc: linux-pm, devicetree, linux-kernel, ilialin
[v12]
* Addressed comments from Sudeep and Viresh about the single init
[v11]
* Addressed comment from Russel about device_node reference
* Addressed comment from Sudeep about the late_initcall
* Transformed init into probe to take care of deferals
[v10]
* Split the series into domains
* Addressed comments from Viresh and Sudeep about logical CPU numbering.
The qcom-cpufreq-kryo driver is aimed to support different SOC versions.
The driver reads eFuse information and chooses the required OPP subset
by passing the OPP supported-hw parameter.
The series depends on the series from Viresh:
https://patchwork.kernel.org/patch/10418139/
The previous spin was here:
https://patchwork.kernel.org/patch/10421143/
Ilia Lin (2):
cpufreq: Add Kryo CPU scaling driver
dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu
.../devicetree/bindings/opp/kryo-cpufreq.txt | 680 +++++++++++++++++++++
drivers/cpufreq/Kconfig.arm | 10 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 194 ++++++
5 files changed, 888 insertions(+)
create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
--
1.9.1
^ permalink raw reply
* Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver
From: Boris Brezillon @ 2018-05-24 8:56 UTC (permalink / raw)
To: Stefan Agner
Cc: dwmw2, computersforpeace, marek.vasut, robh+dt, mark.rutland,
thierry.reding, mturquette, sboyd, dev, miquel.raynal, richard,
marcel, krzk, digetx, benjamin.lindqvist, jonathanh, pdeschrijver,
pgaikwad, mirza.krak, linux-mtd, linux-tegra, devicetree,
linux-kernel, linux-clk
In-Reply-To: <2d8107f0e6568512d691e9ea25a1e4e5@agner.ch>
On Thu, 24 May 2018 10:46:27 +0200
Stefan Agner <stefan@agner.ch> wrote:
> Hi Boris,
>
> Thanks for the initial review! One small question below:
>
> On 23.05.2018 16:18, Boris Brezillon wrote:
> > Hi Stefan,
> >
> > On Tue, 22 May 2018 14:07:06 +0200
> > Stefan Agner <stefan@agner.ch> wrote:
> >> +
> >> +struct tegra_nand {
> >> + void __iomem *regs;
> >> + struct clk *clk;
> >> + struct gpio_desc *wp_gpio;
> >> +
> >> + struct nand_chip chip;
> >> + struct device *dev;
> >> +
> >> + struct completion command_complete;
> >> + struct completion dma_complete;
> >> + bool last_read_error;
> >> +
> >> + dma_addr_t data_dma;
> >> + void *data_buf;
> >> + dma_addr_t oob_dma;
> >> + void *oob_buf;
> >> +
> >> + int cur_chip;
> >> +};
> >
> > This struct should be split in 2 structures: one representing the NAND
> > controller and one representing the NAND chip:
> >
> > struct tegra_nand_controller {
> > struct nand_hw_control base;
> > void __iomem *regs;
> > struct clk *clk;
> > struct device *dev;
> > struct completion command_complete;
> > struct completion dma_complete;
> > bool last_read_error;
> > int cur_chip;
> > };
> >
> > struct tegra_nand {
> > struct nand_chip base;
> > dma_addr_t data_dma;
> > void *data_buf;
> > dma_addr_t oob_dma;
> > void *oob_buf;
> > };
>
> Is there a particular reason why you would leave DMA buffers in the chip
> structure? It seems that is more a controller thing...
The size of those buffers is likely to be device dependent, so if you
have several NANDs connected to the controller, you'll either have to
have one buffer at the controller level which is max(all-chip-buf-size)
or a buffer per device.
Also, do you really need these buffers? The core already provide some
which are suitable for DMA (chip->oob_poi and chip->data_buf).
>
> If I move them, then struct tegra_nand would be basically empty. Can I
> just use struct nand_chip and have no driver specific chip abstraction?
Sure.
^ permalink raw reply
* Re: [PATCH v3] arm64: allwinner: a64: Add Amarula A64-Relic initial support
From: Maxime Ripard @ 2018-05-24 8:54 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, Michael Trimarchi, Icenowy Zheng, devicetree,
linux-arm-kernel, linux-kernel, linux-sunxi
In-Reply-To: <CAMty3ZC-N-6WzYg+kYd2+V3wbQdQmvU706Nog_Urd_EUaWnQjQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]
On Wed, May 23, 2018 at 03:57:05PM +0530, Jagan Teki wrote:
> On Wed, May 23, 2018 at 1:48 PM, Maxime Ripard
> <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > On Wed, May 23, 2018 at 11:44:56AM +0530, Jagan Teki wrote:
> >> On Tue, May 22, 2018 at 8:00 PM, Maxime Ripard
> >> <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> >> > On Tue, May 22, 2018 at 06:52:28PM +0530, Jagan Teki wrote:
> >> >> Amarula A64-Relic is Allwinner A64 based IoT device, which support
> >> >> - Allwinner A64 Cortex-A53
> >> >> - Mali-400MP2 GPU
> >> >> - AXP803 PMIC
> >> >> - 1GB DDR3 RAM
> >> >> - 8GB eMMC
> >> >> - AP6330 Wifi/BLE
> >> >> - MIPI-DSI
> >> >> - CSI: OV5640 sensor
> >> >> - USB OTG
> >> >
> >> > You claim that this is doing OTG...
> >> >
> >> > [..]
> >> >
> >> >> +&usb_otg {
> >> >> + dr_mode = "peripheral";
> >> >> + status = "okay";
> >> >> +};
> >> >
> >> > ... and yet you're setting it as peripheral...
> >>
> >> Though it claims OTG, board doesn't have any USB ports to operate(not
> >> even Mini-AB) the only way to use the board as peripheral to transfer
> >> images from host.
> >
> > I'm not sure what you mean here. If there's no USB connector, why do
> > you even enable it?
>
> I'm saying there is no host port on board. Board has connector
> header[1] comes with few pins includes USB D+, D-, ID, VBUS, GROUND,
> UART0 TX, RX etc. we have to connect wires to these pins to make
> pluggable USB to host pc. and here USB pins used for transferring data
> from host pc to target board like in peripheral mode.
I'm still unsure how it's relevant. If the wire is plugged on your
board's header, is there anything that prevents using it as a host
assuming you have a proper connector on the other end of your wire?
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 06/15] drm/sun4i: tcon: Add support for tcon-top
From: Maxime Ripard @ 2018-05-24 8:50 UTC (permalink / raw)
To: Jernej Škrabec
Cc: wens-jdAy2FN1RRM, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <218132669.UY7RKz0VPx@jernej-laptop>
[-- Attachment #1: Type: text/plain, Size: 6037 bytes --]
On Mon, May 21, 2018 at 07:27:46PM +0200, Jernej Škrabec wrote:
> Hi,
>
> Dne ponedeljek, 21. maj 2018 ob 10:07:59 CEST je Maxime Ripard napisal(a):
> > On Sat, May 19, 2018 at 08:31:18PM +0200, Jernej Skrabec wrote:
> > > If SoC has TCON TOP unit, it has to be configured from TCON, since it
> > > has all information needed. Additionally, if it is TCON TV, it must also
> > > enable bus gate inside TCON TOP unit.
> >
> > Why?
>
> I'll explain my design decision below.
>
> >
> > > Add support for such TCONs.
> > >
> > > Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> > > ---
> > >
> > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 28 ++++++++++++++++++++++++++++
> > > drivers/gpu/drm/sun4i/sun4i_tcon.h | 8 ++++++++
> > > 2 files changed, 36 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..e0c562ce1c22
> > > 100644
> > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device *dev,
> > >
> > > dev_err(dev, "Couldn't get the TCON bus clock\n");
> > > return PTR_ERR(tcon->clk);
> > >
> > > }
> > >
> > > +
> > > + if (tcon->quirks->needs_tcon_top && tcon->quirks->has_channel_1) {
> > > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> > > + if (IS_ERR(tcon->top_clk)) {
> > > + dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
> > > + return PTR_ERR(tcon->top_clk);
> > > + }
> > > + clk_prepare_enable(tcon->top_clk);
> > > + }
> > > +
> > >
> > > clk_prepare_enable(tcon->clk);
> > >
> > > if (tcon->quirks->has_channel_0) {
> > >
> > > @@ -712,6 +722,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
> > >
> > > static void sun4i_tcon_free_clocks(struct sun4i_tcon *tcon)
> > > {
> > >
> > > clk_disable_unprepare(tcon->clk);
> > >
> > > + clk_disable_unprepare(tcon->top_clk);
> > >
> > > }
> > >
> > > static int sun4i_tcon_init_irq(struct device *dev,
> > >
> > > @@ -980,6 +991,23 @@ static int sun4i_tcon_bind(struct device *dev, struct
> > > device *master,>
> > > tcon->id = engine->id;
> > > tcon->quirks = of_device_get_match_data(dev);
> > >
> > > + if (tcon->quirks->needs_tcon_top) {
> > > + struct device_node *np;
> > > +
> > > + np = of_parse_phandle(dev->of_node, "allwinner,tcon-top", 0);
> > > + if (np) {
> > > + struct platform_device *pdev;
> > > +
> > > + pdev = of_find_device_by_node(np);
> > > + if (pdev)
> > > + tcon->tcon_top = platform_get_drvdata(pdev);
> > > + of_node_put(np);
> > > +
> > > + if (!tcon->tcon_top)
> > > + return -EPROBE_DEFER;
> > > + }
> > > + }
> > > +
> >
> > I might have missed it, but I've not seen the bindings additions for
> > that property. This shouldn't really be done that way anyway, instead
> > of using a direct phandle, you should be using the of-graph, with the
> > TCON-top sitting where it belongs in the flow of data.
>
> Just to answer to the first question, it did describe it in "[PATCH 07/15] dt-
> bindings: display: sun4i-drm: Add R40 HDMI pipeline".
>
> As why I designed it that way - HW representation could be described that way
> (ASCII art makes sense when fixed width font is used to view it):
>
> / LCD0/LVDS0
> / TCON-LCD0
> | \ MIPI DSI
> mixer0 |
> \ / TCON-LCD1 - LCD1/LVDS1
> TCON-TOP
> / \ TCON-TV0 - TVE0/RGB
> mixer1 | \
> | TCON-TOP - HDMI
> | /
> \ TCON-TV1 - TVE1/RGB
>
> This is a bit simplified, since there is also TVE-TOP, which is responsible
> for sharing 4 DACs between both TVE encoders. You can have two TV outs (PAL/
> NTSC) or TVE0 as TV out and TVE1 as RGB or vice versa. It even seems that you
> can arbitrarly choose which DAC is responsible for which signal, so there is a
> ton of possible end combinations, but I'm not 100% sure.
>
> Even though I wrote TCON-TOP twice, this is same unit in HW. R40 manual
> suggest more possibilities, although some of them seem wrong, like RGB feeding
> from LCD TCON. That is confirmed to be wrong when checking BSP code.
>
> Additionally, TCON-TOP comes in the middle of TVE0 and LCD0, TVE1 and LCD1 for
> pin muxing, although I'm not sure why is that needed at all, since according
> to R40 datasheet, TVE0 and TVE1 pins are dedicated and not on PORT D and PORT
> H, respectively, as TCON-TOP documentation suggest. However, HSYNC and PSYNC
> lines might be shared between TVE (when it works in RGB mode) and LCD. But
> that is just my guess since I'm not really familiar with RGB and LCD
> interfaces.
>
> I'm really not sure what would be the best representation in OF-graph. Can you
> suggest one?
Rob might disagree on this one, but I don't see anything wrong with
having loops in the graph. If the TCON-TOP can be both the input and
output of the TCONs, then so be it, and have it described that way in
the graph.
The code is already able to filter out nodes that have already been
added to the list of devices we need to wait for in the component
framework, so that should work as well.
And we'd need to describe TVE-TOP as well, even though we don't have a
driver for it yet. That will simplify the backward compatibility later
on.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Linus Walleij @ 2018-05-24 8:47 UTC (permalink / raw)
To: Heiko Stübner
Cc: Mark Rutland, Rob Herring, Wayne Chou,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org,
open list:ARM/Rockchip SoC..., Levin Du,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <2044895.BqI5yRtle6@diego>
On Thu, May 24, 2018 at 10:35 AM, Heiko Stübner <heiko@sntech.de> wrote:
> Am Donnerstag, 24. Mai 2018, 10:28:44 CEST schrieb Linus Walleij:
>> On Wed, May 23, 2018 at 5:12 PM, Heiko Stübner <heiko@sntech.de> wrote:
>> > So the gpio controller should definitly also be a subnode.
>> >
>> > The gpio in question is called "mute", so I'd think the gpio-syscon driver
>> > should just define a "rockchip,rk3328-gpio-mute" compatible and contain
>> > all the register voodoo in the driver itself and not define it in the dt.
>> >
>> > So it should probably look like
>> >
>> > grf: syscon at ff100000 {
>> >
>> > compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
>> >
>> > [all the other syscon sub-devices]
>> >
>> > gpio_mute: gpio-mute {
>> >
>> > compatible = "rockchip,rk3328-gpio-mute";
>> > gpio-controller;
>> > #gpio-cells = <2>;
>> >
>> > };
>>
>> I'm sceptic.
>>
>> That doesn't sound like "general purpose input output" at all.
>>
>> It sounds like special purpose, for a mute button.
>>
>> Does it use IRQ? I would recommend implementing
>> drivers/input/keyboard/syscon-keys.c in the same vein
>> as drivers/leds/leds-syscon.c so you can avoid indirection
>> through GPIO for no good reason at all.
>
> To quote Levin from the other mail:
> --------
> The "mute" pin is a output only GPIO, which is already supported by
> setting flags in the gpio-syscon
> driver. And yes, this pin has a defined function, but can also be used
> for general purpose operation.
> --------
>
> So to summarize, the documentation calls it "mute", but it is usable as
> a general pin, which is the reason Levin is working on it - because on his
> board this pin is used to switch between two voltages (aka a gpio-regulator)
> for the sdmmc controller [3.3V + 1.8V].
OK then, I was wrong! :)
Go ahead with this, sorry for the fuzz.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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