* [PATCH v3 0/3] PCI: qcom: Add support to msm8996 pcie controller.
From: Srinivas Kandagatla @ 2016-11-04 12:59 UTC (permalink / raw)
To: svarbanov, Bjorn Helgaas, linux-pci
Cc: Rob Herring, Mark Rutland, devicetree, linux-kernel,
linux-arm-msm, Srinivas Kandagatla
This patchset adds support to msm8996 pcie controller. I tested this patch on
v4.9-rc2 along with phy driver patch [1] and
"PCI: designware: check for iATU unroll support after initializing host"
fix [2] on DB820c APQ8096 board on port B and port C using sata and
ethernet controller.
Changes since v2:
- Removed regulators that belong to phy, spotted by Stephen
- Removed clocks in to simple pm bus driver, spotted by Stephen
- renamed msm8996 ops to v2 ops as suggested by Stephen.
- cleanups as suggested by Stephen.
- Add runtime pm support to driver.
- Added pm clk support to simple pm bus driver.
Changes since v1:
- Fixed dt example as suggested by Rob
- added smmu bus clk dependency as smmu sits in between
system NOC and PCIe.
- Removed smmu configuration from bindings and driver as
the smmu Level2 translation on this SOC is controlled by
the secure world, and level 1 translation is disabled,
so there is one-to-one mapping of the address space.
Thanks,
srini
[1] https://patchwork.kernel.org/patch/9384711/
[2] https://patchwork.kernel.org/patch/9377557/
Srinivas Kandagatla (3):
bus: simple-pm: add support to pm clocks
PCI: qcom: add support to msm8996 PCIE controller
PCI: qcom: add runtime pm support to pcie_port
.../devicetree/bindings/pci/qcom,pcie.txt | 68 +++++++-
drivers/bus/simple-pm-bus.c | 13 +-
drivers/pci/host/pcie-qcom.c | 183 ++++++++++++++++++++-
3 files changed, 257 insertions(+), 7 deletions(-)
--
2.10.1
^ permalink raw reply
* Re: [PATCH] ARM: mvebu: Update comment for main PLL frequency
From: Gregory CLEMENT @ 2016-11-04 12:33 UTC (permalink / raw)
To: Chris Packham
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Rob Herring, Mark Rutland,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161025235242.31764-1-chris.packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
Hi Chris,
On mer., oct. 26 2016, Chris Packham <chris.packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org> wrote:
> The actual frequency was updated in commit ae142bd99765 ("ARM: mvebu:
> Fix the main PLL frequency on Armada 375, 38x and 39x SoCs") but the
> comment was not updated. Update it now.
>
> Signed-off-by: Chris Packham <chris.packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
Applied on mvebu/dt
Thanks,
Gregory
> ---
> arch/arm/boot/dts/armada-375.dtsi | 2 +-
> arch/arm/boot/dts/armada-38x.dtsi | 2 +-
> arch/arm/boot/dts/armada-39x.dtsi | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
> index cc952cf8ec30..45fa92f9cf5c 100644
> --- a/arch/arm/boot/dts/armada-375.dtsi
> +++ b/arch/arm/boot/dts/armada-375.dtsi
> @@ -65,7 +65,7 @@
> };
>
> clocks {
> - /* 2 GHz fixed main PLL */
> + /* 1 GHz fixed main PLL */
> mainpll: mainpll {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
> index 2d7668848c5a..7450e9fea45d 100644
> --- a/arch/arm/boot/dts/armada-38x.dtsi
> +++ b/arch/arm/boot/dts/armada-38x.dtsi
> @@ -661,7 +661,7 @@
> };
>
> clocks {
> - /* 2 GHz fixed main PLL */
> + /* 1 GHz fixed main PLL */
> mainpll: mainpll {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> diff --git a/arch/arm/boot/dts/armada-39x.dtsi b/arch/arm/boot/dts/armada-39x.dtsi
> index 34cba87f9200..de171baffcf6 100644
> --- a/arch/arm/boot/dts/armada-39x.dtsi
> +++ b/arch/arm/boot/dts/armada-39x.dtsi
> @@ -573,7 +573,7 @@
> };
>
> clocks {
> - /* 2 GHz fixed main PLL */
> + /* 1 GHz fixed main PLL */
> mainpll: mainpll {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> --
> 2.10.1
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards
From: Paul Burton @ 2016-11-04 12:30 UTC (permalink / raw)
To: Hans de Goede
Cc: Linus Torvalds, Andrew Morton, Rob Herring, Frank Rowand,
Thorsten Leemhuis, Greg Kroah-Hartman, Tejun Heo, devicetree,
linux-kernel
In-Reply-To: <20161104121135.4780-1-hdegoede@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2460 bytes --]
Hi Hans,
On Friday, 4 November 2016 13:11:34 GMT Hans de Goede wrote:
> Hi All,
>
> While booting 4.9-rc# for the first time on an Allwinner A33 tablet,
> I noticed that after u-boot the LCD display stayed black. It turns out
> that there was an issue which caused X to never get up, and all kernel
> (and other startup) messages prior to that only went to ttyS0 which
> consists of 2 tiny testpads on the PCB with this tablet.
>
> The same issue will also happen on any ARM boards which have a HDMI or
> composite video output and which use a stdout-path pointing to their
> serial console. I think this will e.g. also impact the Raspberry Pi,
> I know for certain that this will impact the 99 different Allwinnner
> boards currently supported by mainline u-boot + the mainline kernel.
>
> This is a behavior changes from previous kernels and I consider this
> a regression. Thus I propose to revert the commit in question, for more
> info here is a partial copy of the commit message of the proposed revert:
>
> The reverted commit changes existing behavior on which many ARM boards
> rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
> both a video output and a serial console. Depending on whether the user
> is using the device as a more regular computer; or as a headless device
> we need to have the console on either one or the other.
>
> Many users rely on the kernel behavior of the console being present on
> both outputs, before the reverted commit the console setup with no
> console= kernel arguments on an ARM board which sets stdout-path in dt
> would look like this:
>
> [root@localhost ~]# cat /proc/consoles
> ttyS0 -W- (EC p a) 4:64
> tty0 -WU (E p ) 4:1
>
> Where as after the reverted commit, it looks like this:
>
> [root@localhost ~]# cat /proc/consoles
> ttyS0 -W- (EC p a) 4:64
>
> This commit reverts commit 05fd007e4629 ("console: don't prefer first
> registered if DT specifies stdout-path") restoring the original behavior.
>
> Regards,
>
> Hans
Ugh... so the devices you're talking about rely upon set stdout-path in their
device tree but effectively rely upon us ignoring it?
If that's the case then I guess reverting is probably the best option, but it
does restore us to a position where we honor stdout-path for earlycon & then
essentially ignore it for the proper kernel console. That seems pretty bust to
me...
Thanks,
Paul
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] Revert "console: don't prefer first registered if DT specifies stdout-path"
From: Hans de Goede @ 2016-11-04 12:11 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton, Paul Burton, Rob Herring,
Frank Rowand, Thorsten Leemhuis
Cc: Greg Kroah-Hartman, Tejun Heo, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Hans de Goede
In-Reply-To: <20161104121135.4780-1-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
This reverts commit 05fd007e4629 ("console: don't prefer first registered
if DT specifies stdout-path").
The reverted commit changes existing behavior on which many ARM boards
rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
both a video output and a serial console. Depending on whether the user
is using the device as a more regular computer; or as a headless device
we need to have the console on either one or the other.
Many users rely on the kernel behavior of the console being present on
both outputs, before the reverted commit the console setup with no
console= kernel arguments on an ARM board which sets stdout-path in dt
would look like this:
[root@localhost ~]# cat /proc/consoles
ttyS0 -W- (EC p a) 4:64
tty0 -WU (E p ) 4:1
Where as after the reverted commit, it looks like this:
[root@localhost ~]# cat /proc/consoles
ttyS0 -W- (EC p a) 4:64
This commit reverts commit 05fd007e4629 ("console: don't prefer first
registered if DT specifies stdout-path") restoring the original behavior.
Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
drivers/of/base.c | 2 --
include/linux/console.h | 6 ------
kernel/printk/printk.c | 13 +------------
3 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d687e6d..a0bccb5 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2077,8 +2077,6 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64 align))
name = of_get_property(of_aliases, "stdout", NULL);
if (name)
of_stdout = of_find_node_opts_by_path(name, &of_stdout_options);
- if (of_stdout)
- console_set_by_of();
}
if (!of_aliases)
diff --git a/include/linux/console.h b/include/linux/console.h
index 3672809..d530c46 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -173,12 +173,6 @@ static inline void console_sysfs_notify(void)
#endif
extern bool console_suspend_enabled;
-#ifdef CONFIG_OF
-extern void console_set_by_of(void);
-#else
-static inline void console_set_by_of(void) {}
-#endif
-
/* Suspend and resume console messages over PM events */
extern void suspend_console(void);
extern void resume_console(void);
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index de08fc9..5028f4f 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -253,17 +253,6 @@ static int preferred_console = -1;
int console_set_on_cmdline;
EXPORT_SYMBOL(console_set_on_cmdline);
-#ifdef CONFIG_OF
-static bool of_specified_console;
-
-void console_set_by_of(void)
-{
- of_specified_console = true;
-}
-#else
-# define of_specified_console false
-#endif
-
/* Flag: console code may call schedule() */
static int console_may_schedule;
@@ -2657,7 +2646,7 @@ void register_console(struct console *newcon)
* didn't select a console we take the first one
* that registers here.
*/
- if (preferred_console < 0 && !of_specified_console) {
+ if (preferred_console < 0) {
if (newcon->index < 0)
newcon->index = 0;
if (newcon->setup == NULL ||
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards
From: Hans de Goede @ 2016-11-04 12:11 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton, Paul Burton, Rob Herring,
Frank Rowand, Thorsten Leemhuis
Cc: Greg Kroah-Hartman, Tejun Heo, devicetree, linux-kernel
Hi All,
While booting 4.9-rc# for the first time on an Allwinner A33 tablet,
I noticed that after u-boot the LCD display stayed black. It turns out
that there was an issue which caused X to never get up, and all kernel
(and other startup) messages prior to that only went to ttyS0 which
consists of 2 tiny testpads on the PCB with this tablet.
The same issue will also happen on any ARM boards which have a HDMI or
composite video output and which use a stdout-path pointing to their
serial console. I think this will e.g. also impact the Raspberry Pi,
I know for certain that this will impact the 99 different Allwinnner
boards currently supported by mainline u-boot + the mainline kernel.
This is a behavior changes from previous kernels and I consider this
a regression. Thus I propose to revert the commit in question, for more
info here is a partial copy of the commit message of the proposed revert:
The reverted commit changes existing behavior on which many ARM boards
rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
both a video output and a serial console. Depending on whether the user
is using the device as a more regular computer; or as a headless device
we need to have the console on either one or the other.
Many users rely on the kernel behavior of the console being present on
both outputs, before the reverted commit the console setup with no
console= kernel arguments on an ARM board which sets stdout-path in dt
would look like this:
[root@localhost ~]# cat /proc/consoles
ttyS0 -W- (EC p a) 4:64
tty0 -WU (E p ) 4:1
Where as after the reverted commit, it looks like this:
[root@localhost ~]# cat /proc/consoles
ttyS0 -W- (EC p a) 4:64
This commit reverts commit 05fd007e4629 ("console: don't prefer first
registered if DT specifies stdout-path") restoring the original behavior.
Regards,
Hans
^ permalink raw reply
* I need your urgent reply.
From: jify @ 2016-11-04 11:55 UTC (permalink / raw)
In-Reply-To: <1582635385.154572.1478260502422.ref@mail.yahoo.com>
Greetings my dear friend and how are you doing today? I am Mary Jify from Republic of Togo, am the only child of my late father, am 19years of age and right now am contacting you for the transfer of $11m.400 from the bank of Burkina to your own bank account in your country for my coming over for investment, Please reply me very urgent so that i can give you more details of the transfer and myself and will also send you my photo immediately i read from you.
I wait your reply
Best Regards
Mary.Jify.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] ARM: DTS: r8a7794: alt: Fix PFC names for DU
From: Sergei Shtylyov @ 2016-11-04 11:43 UTC (permalink / raw)
To: Jacopo Mondi, horms, magnus.damm, robh+dt, mark.rutland, linux
Cc: linux-renesas-soc, devicetree, linux-arm-kernel
In-Reply-To: <1478201686-25488-1-git-send-email-jacopo@jmondi.org>
Hello.
On 11/3/2016 10:34 PM, Jacopo Mondi wrote:
> Update the PFC pin groups and function names of DU interface for
> r8a7794 ALT board.
>
> The currently specified pin groups and function names prevented PFC and
> DU interfaces from being correctly configured:
>
> sh-pfc e6060000.pin-controller: function 'du' not supported
> sh-pfc e6060000.pin-controller: invalid function du in map table
> sh-pfc e6060000.pin-controller: function 'du' not supported
> sh-pfc e6060000.pin-controller: invalid function du in map table
> sh-pfc e6060000.pin-controller: function 'du' not supported
> sh-pfc e6060000.pin-controller: invalid function du in map table
> sh-pfc e6060000.pin-controller: function 'du' not supported
> sh-pfc e6060000.pin-controller: invalid function du in map table
> rcar-du: probe of feb00000.display failed with error -22
>
> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 0/10] mmc: Add support to Marvell Xenon SD Host Controller
From: Gregory CLEMENT @ 2016-11-04 11:20 UTC (permalink / raw)
To: Ulf Hansson
Cc: Adrian Hunter, linux-mmc-u79uwXL29TY76Z2rM5mHXA, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ziji Hu,
Jack(SH) Zhu, Jimmy Xu, Jisheng Zhang, Nadav Haklai, Ryan Gao,
Doug Jones, Shiwu Zhang, Victor Gu, Wei(SOCP) Liu, Wilson Ding,
Xueping Liu, Hilbert Zhang <zzh>
In-Reply-To: <cover.86006f271b60cf7c0b4c5a51762a9dacca4c4718.1477911954.git-series.gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi,
On lun., oct. 31 2016, Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hello,
>
> This the second version of the series adding support for the SDHCI
> Xenon controller. It can be currently found on the Armada 37xx and the
> Armada 7K/8K but will be also used in more Marvell SoC (and not only
> the mvebu ones actually).
>
> Some of the remarks had been taking into account since the first
> version, according to Ziji Hu, here are the following chcanges:
> "Changes in V2:
> rebase on v4.9-rc2.
> Re-write Xenon bindings. Ajust Xenon DT property naming.
> Add a new DT property to indicate eMMC card type, instead of using
> variable card_candidate.
> Clear quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 in Xenon platform data
> Add support to HS400 retuning."
>
> I think the main open point which remains is about issuing commands
> from the ->set_ios() callback (in patch 7).
> Ulf, could you comment about it?
A few comments:
- I forgot to add the v2 prefix on the series I hope it won't be too
annoying, if needed I can re-post the series with the correct title.
- I also forgot to add my Reviewed-by flag on the 7 first patches, I
will add them back on the v3.
- For the ones who want to get the series using git here is the place
you can get it here:
repository: git-9UaJU3cA/F/QT0dZR+AlfA@public.gmane.org:MISL-EBU-System-SW/mainline-public.git
branch: sdhci-xenon-v2
Thanks,
Gregory
>
> Thanks,
>
> Gregory
>
> Gregory CLEMENT (3):
> arm64: dts: marvell: add eMMC support for Armada 37xx
> arm64: dts: marvell: add sdhci support for Armada 7K/8K
> arm64: configs: enable SDHCI driver for Xenon
>
> Ziji Hu (7):
> mmc: sdhci: Export sdhci_set_ios() from sdhci.c
> mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c
> mmc: sdhci: Export sdhci_execute_tuning() in sdhci.c
> MAINTAINERS: add entry for Marvell Xenon MMC Host Controller drivers
> dt: bindings: Add bindings for Marvell Xenon SD Host Controller
> mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
> mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
>
> Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 161 +-
> MAINTAINERS | 7 +-
> arch/arm64/boot/dts/marvell/armada-3720-db.dts | 8 +-
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 11 +-
> arch/arm64/boot/dts/marvell/armada-7040-db.dts | 8 +-
> arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 9 +-
> arch/arm64/configs/defconfig | 1 +-
> drivers/mmc/host/Kconfig | 9 +-
> drivers/mmc/host/Makefile | 3 +-
> drivers/mmc/host/sdhci-xenon-phy.c | 1181 +++++++-
> drivers/mmc/host/sdhci-xenon-phy.h | 157 +-
> drivers/mmc/host/sdhci-xenon.c | 598 ++++-
> drivers/mmc/host/sdhci-xenon.h | 159 +-
> drivers/mmc/host/sdhci.c | 11 +-
> drivers/mmc/host/sdhci.h | 4 +-
> 15 files changed, 2323 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> create mode 100644 drivers/mmc/host/sdhci-xenon-phy.c
> create mode 100644 drivers/mmc/host/sdhci-xenon-phy.h
> create mode 100644 drivers/mmc/host/sdhci-xenon.c
> create mode 100644 drivers/mmc/host/sdhci-xenon.h
>
> base-commit: 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942
> --
> git-series 0.8.10
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 10/13] ARM: dts: exynos: replace to "max-frequecy" instead of "clock-freq-min-max"
From: Heiko Stuebner @ 2016-11-04 11:19 UTC (permalink / raw)
To: Jaehoon Chung
Cc: Krzysztof Kozlowski, linux-mmc, devicetree, linux-kernel,
linux-arm-kernel, linux-samsung-soc, linux-rockchip, ulf.hansson,
robh+dt, shawn.lin
In-Reply-To: <ecf4fac2-0ab7-d4c4-69e3-d498ee5b601c@samsung.com>
Hi Jaehoon,
Am Freitag, 4. November 2016, 19:21:30 CET schrieb Jaehoon Chung:
> On 11/04/2016 03:41 AM, Krzysztof Kozlowski wrote:
> > On Thu, Nov 03, 2016 at 03:21:32PM +0900, Jaehoon Chung wrote:
> >> In drivers/mmc/core/host.c, there is "max-frequency" property.
> >> It should be same behavior. So Use the "max-frequency" instead of
> >> "clock-freq-min-max".
> >>
> >> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> >> ---
> >>
> >> arch/arm/boot/dts/exynos3250-artik5-eval.dts | 2 +-
> >> arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +-
> >> arch/arm/boot/dts/exynos3250-monk.dts | 2 +-
> >> arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
> >> 4 files changed, 4 insertions(+), 4 deletions(-)
> >
> > This looks totally independent to rest of patches so it can be applied
> > separately without any functional impact (except lack of minimum
> > frequency). Is that correct?
>
> You're right. I will split the patches. And will resend.
> Thanks!
I think what Krzysztof was asking was just if he can simply pick up this patch
alone, as it does not require any of the previous changes.
Same is true for the Rockchip patches I guess, so we could just take them
individually into samsung/rockchip dts branches.
Heiko
^ permalink raw reply
* Re: [PATCH 6/6] ARM: dts: rockchip: add rockchip RK1108 Evaluation board
From: Heiko Stuebner @ 2016-11-04 11:17 UTC (permalink / raw)
To: Andy Yan
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <ce6e9d62-75e5-60bc-2775-507aa326e3a2-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Freitag, 4. November 2016, 18:54:35 CET schrieb Andy Yan:
> Hi Heiko:
>
> On 2016年11月04日 18:03, Heiko Stuebner wrote:
> > Am Donnerstag, 3. November 2016, 20:43:59 CET schrieb Andy Yan:
> >> RK1108EVB is designed by Rockchip for CVR field.
> >> This patch add basic support for it, which can boot with
> >> initramfs into shell.
> >>
> >> Signed-off-by: Andy Yan <andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> >
> > looks good, the only thing I can also change myself is moving the board in
> > the rockchip.txt to the block of Rockchip boards (i.e. sorting by
> > manufacturer and board name).
> >
> >
> > Heiko
>
> You mean it's better to put it between "Rockchip RK3368 evb" and
> "Rockchip PX5 Evaluation board"? if so, I will change it in next version.
yep, that is the location I also would've moved it to :-) .
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH v2 0/5] ARM64: Add Internal PHY support for Meson GXL
From: Neil Armstrong @ 2016-11-04 10:55 UTC (permalink / raw)
To: f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A, andrew-g2DYL2Zd6BY
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477932987-27871-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 10/31/2016 05:56 PM, Neil Armstrong wrote:
> The Amlogic Meson GXL SoCs have an internal RMII PHY that is muxed with the
> external RGMII pins.
>
> In order to support switching between the two PHYs links, extended registers
> size for mdio-mux-mmioreg must be added.
>
> Finally, the internal PHY is added in the GXL dtsi and support for each
> board is added in intermediate board family dtsi or final dts.
>
> This patchset depends on ARM64 dts patch at [1]
>
> Changes since original RFC patchset at : [2]
> - Remove meson8b experimental phy switching
> - Switch to mdio-mux-mmioreg with extennded size support
> - Add internal phy support for S905x and p231
> - Add external PHY support for p230
>
> [1] http://lkml.kernel.org/r/1477932286-27482-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
> [2] http://lkml.kernel.org/r/1477060838-14164-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
>
> Neil Armstrong (5):
> net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
> net: phy: Add Meson GXL Internal PHY driver
> ARM64: dts: meson-gxl: Add ethernet nodes with internal PHY
> ARM64: dts: meson-gxl-p23x: Enable ethernet
> ARM64: dts: meson-gxl-s905x: Enable internal ethernet PHY
>
> .../devicetree/bindings/net/mdio-mux-mmioreg.txt | 4 +-
> .../boot/dts/amlogic/meson-gxl-s905d-p230.dts | 16 +++++
> .../boot/dts/amlogic/meson-gxl-s905d-p231.dts | 6 ++
> .../boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi | 4 ++
> arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi | 6 ++
> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 45 ++++++++++++
> drivers/net/phy/Kconfig | 5 ++
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/mdio-mux-mmioreg.c | 60 ++++++++++++----
> drivers/net/phy/meson-gxl.c | 81 ++++++++++++++++++++++
> 10 files changed, 213 insertions(+), 15 deletions(-)
> create mode 100644 drivers/net/phy/meson-gxl.c
>
Hi Florian, Andrew, Sergei,
Thanks for reviews,
Since the meson-gxl dtsi has a lot of changes pending, the patches 3, 4 & 5 will be sent in a separate patchset,
and patches 1 & 2 will be send to netdev -next.
Neil
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/6] ARM: dts: rockchip: add rockchip RK1108 Evaluation board
From: Andy Yan @ 2016-11-04 10:54 UTC (permalink / raw)
To: Heiko Stuebner
Cc: mark.rutland, devicetree, linux, linux-kernel, linux-rockchip,
robh+dt, linux-arm-kernel
In-Reply-To: <3057904.hZPZRUIUZe@phil>
Hi Heiko:
On 2016年11月04日 18:03, Heiko Stuebner wrote:
> Am Donnerstag, 3. November 2016, 20:43:59 CET schrieb Andy Yan:
>> RK1108EVB is designed by Rockchip for CVR field.
>> This patch add basic support for it, which can boot with
>> initramfs into shell.
>>
>> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
> looks good, the only thing I can also change myself is moving the board in the
> rockchip.txt to the block of Rockchip boards (i.e. sorting by manufacturer and
> board name).
>
>
> Heiko
You mean it's better to put it between "Rockchip RK3368 evb" and
"Rockchip PX5 Evaluation board"? if so, I will change it in next version.
>> ---
>>
>> Documentation/devicetree/bindings/arm/rockchip.txt | 3 +
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/rk1108-evb.dts | 69
>> ++++++++++++++++++++++ 3 files changed, 73 insertions(+)
>> create mode 100644 arch/arm/boot/dts/rk1108-evb.dts
>>
>> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
>> b/Documentation/devicetree/bindings/arm/rockchip.txt index 10b92b5..8670181
>> 100644
>> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
>> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
>> @@ -1,5 +1,8 @@
>> Rockchip platforms device tree bindings
>> ---------------------------------------
>> +- Rockchip RK1108 Evaluation board
>> + Required root node properties:
>> + - compatible = "rockchip,rk1108-evb", "rockchip,rk1108";
>>
>> - Kylin RK3036 board:
>> Required root node properties:
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index e49476a..249dca9 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -635,6 +635,7 @@ dtb-$(CONFIG_ARCH_REALVIEW) += \
>> arm-realview-pba8.dtb \
>> arm-realview-pbx-a9.dtb
>> dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>> + rk1108-evb.dtb \
>> rk3036-evb.dtb \
>> rk3036-kylin.dtb \
>> rk3066a-bqcurie2.dtb \
>> diff --git a/arch/arm/boot/dts/rk1108-evb.dts
>> b/arch/arm/boot/dts/rk1108-evb.dts new file mode 100644
>> index 0000000..3956cff
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/rk1108-evb.dts
>> @@ -0,0 +1,69 @@
>> +/*
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + * a) This file is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This file is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + * b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "rk1108.dtsi"
>> +
>> +/ {
>> + model = "Rockchip RK1108 Evaluation board";
>> + compatible = "rockchip,rk1108-evb", "rockchip,rk1108";
>> +
>> + memory@60000000 {
>> + device_type = "memory";
>> + reg = <0x60000000 0x08000000>;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial2:1500000n8";
>> + };
>> +};
>> +
>> +&uart0 {
>> + status = "okay";
>> +};
>> +
>> +&uart1 {
>> + status = "okay";
>> +};
>> +
>> +&uart2 {
>> + status = "okay";
>> +};
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
>
>
^ permalink raw reply
* Re: [PATCH 10/13] ARM: dts: exynos: replace to "max-frequecy" instead of "clock-freq-min-max"
From: Jaehoon Chung @ 2016-11-04 10:21 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-rockchip, ulf.hansson, robh+dt, heiko,
shawn.lin
In-Reply-To: <20161103184112.GB11071@kozik-lap>
On 11/04/2016 03:41 AM, Krzysztof Kozlowski wrote:
> On Thu, Nov 03, 2016 at 03:21:32PM +0900, Jaehoon Chung wrote:
>> In drivers/mmc/core/host.c, there is "max-frequency" property.
>> It should be same behavior. So Use the "max-frequency" instead of
>> "clock-freq-min-max".
>>
>> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>> ---
>> arch/arm/boot/dts/exynos3250-artik5-eval.dts | 2 +-
>> arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +-
>> arch/arm/boot/dts/exynos3250-monk.dts | 2 +-
>> arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
>> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> This looks totally independent to rest of patches so it can be applied
> separately without any functional impact (except lack of minimum
> frequency). Is that correct?
You're right. I will split the patches. And will resend.
Thanks!
Best Regards,
Jaehoon Chung
>
> Best regards,
> Krzysztof
>
>
>
>
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: stm32f429: add LSI and LSE clocks
From: Gabriel Fernandez @ 2016-11-04 10:16 UTC (permalink / raw)
To: Alexandre Torgue, Rob Herring, Mark Rutland, Russell King,
Maxime Coquelin
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-F5mvAk5X5gdBDgjK7y7TUQ
In-Reply-To: <3974b516-d698-ab7f-efba-d768eccbd56f-qxv4g6HH51o@public.gmane.org>
Hi Alexandre,
On 11/04/2016 11:15 AM, Alexandre Torgue wrote:
> Gabriel,
>
> On 11/04/2016 09:52 AM, gabriel.fernandez-qxv4g6HH51o@public.gmane.org wrote:
>> From: Gabriel Fernandez <gabriel.fernandez-qxv4g6HH51o@public.gmane.org>
>>
>> This patch adds lsi / lse oscillators. These clocks can be use by
>> RTC clocks.
>> The clock drivers needs to disable the power domain write protection
>> using
>> syscon / regmap to enable these clocks.
>>
>
> Is it the same than you sent in last series ? If yes I will take it
> directly as review has already been done.
>
Yes
BR
Gabriel.
> regards
> Alex
>
>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez-qxv4g6HH51o@public.gmane.org>
>> ---
>> arch/arm/boot/dts/stm32f429.dtsi | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>> b/arch/arm/boot/dts/stm32f429.dtsi
>> index 336ee4f..2700449 100644
>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> @@ -56,6 +56,18 @@
>> compatible = "fixed-clock";
>> clock-frequency = <0>;
>> };
>> +
>> + clk-lse {
>> + #clock-cells = <0>;
>> + compatible = "fixed-clock";
>> + clock-frequency = <32768>;
>> + };
>> +
>> + clk-lsi {
>> + #clock-cells = <0>;
>> + compatible = "fixed-clock";
>> + clock-frequency = <32000>;
>> + };
>> };
>>
>> soc {
>> @@ -185,6 +197,11 @@
>> interrupts = <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>,
>> <23>, <40>, <41>, <42>, <62>, <76>;
>> };
>>
>> + pwrcfg: power-config@40007000 {
>> + compatible = "syscon";
>> + reg = <0x40007000 0x400>;
>> + };
>> +
>> pin-controller {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> @@ -340,6 +357,7 @@
>> compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
>> reg = <0x40023800 0x400>;
>> clocks = <&clk_hse>;
>> + st,syscfg = <&pwrcfg>;
>> };
>>
>> dma1: dma-controller@40026000 {
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: stm32f429: add LSI and LSE clocks
From: Alexandre Torgue @ 2016-11-04 10:15 UTC (permalink / raw)
To: gabriel.fernandez, Rob Herring, Mark Rutland, Russell King,
Maxime Coquelin
Cc: devicetree, linux-arm-kernel, linux-kernel, kernel
In-Reply-To: <1478249577-25999-2-git-send-email-gabriel.fernandez@st.com>
Gabriel,
On 11/04/2016 09:52 AM, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch adds lsi / lse oscillators. These clocks can be use by
> RTC clocks.
> The clock drivers needs to disable the power domain write protection using
> syscon / regmap to enable these clocks.
>
Is it the same than you sent in last series ? If yes I will take it
directly as review has already been done.
regards
Alex
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index 336ee4f..2700449 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -56,6 +56,18 @@
> compatible = "fixed-clock";
> clock-frequency = <0>;
> };
> +
> + clk-lse {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + };
> +
> + clk-lsi {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32000>;
> + };
> };
>
> soc {
> @@ -185,6 +197,11 @@
> interrupts = <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>, <23>, <40>, <41>, <42>, <62>, <76>;
> };
>
> + pwrcfg: power-config@40007000 {
> + compatible = "syscon";
> + reg = <0x40007000 0x400>;
> + };
> +
> pin-controller {
> #address-cells = <1>;
> #size-cells = <1>;
> @@ -340,6 +357,7 @@
> compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
> reg = <0x40023800 0x400>;
> clocks = <&clk_hse>;
> + st,syscfg = <&pwrcfg>;
> };
>
> dma1: dma-controller@40026000 {
>
^ permalink raw reply
* Re: [PATCH 6/6] ARM: dts: rockchip: add rockchip RK1108 Evaluation board
From: Heiko Stuebner @ 2016-11-04 10:03 UTC (permalink / raw)
To: Andy Yan
Cc: linux-rockchip, devicetree, robh+dt, mark.rutland, linux,
linux-arm-kernel, linux-kernel
In-Reply-To: <1478177039-12257-1-git-send-email-andy.yan@rock-chips.com>
Am Donnerstag, 3. November 2016, 20:43:59 CET schrieb Andy Yan:
> RK1108EVB is designed by Rockchip for CVR field.
> This patch add basic support for it, which can boot with
> initramfs into shell.
>
> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
looks good, the only thing I can also change myself is moving the board in the
rockchip.txt to the block of Rockchip boards (i.e. sorting by manufacturer and
board name).
Heiko
> ---
>
> Documentation/devicetree/bindings/arm/rockchip.txt | 3 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/rk1108-evb.dts | 69
> ++++++++++++++++++++++ 3 files changed, 73 insertions(+)
> create mode 100644 arch/arm/boot/dts/rk1108-evb.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> b/Documentation/devicetree/bindings/arm/rockchip.txt index 10b92b5..8670181
> 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -1,5 +1,8 @@
> Rockchip platforms device tree bindings
> ---------------------------------------
> +- Rockchip RK1108 Evaluation board
> + Required root node properties:
> + - compatible = "rockchip,rk1108-evb", "rockchip,rk1108";
>
> - Kylin RK3036 board:
> Required root node properties:
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index e49476a..249dca9 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -635,6 +635,7 @@ dtb-$(CONFIG_ARCH_REALVIEW) += \
> arm-realview-pba8.dtb \
> arm-realview-pbx-a9.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> + rk1108-evb.dtb \
> rk3036-evb.dtb \
> rk3036-kylin.dtb \
> rk3066a-bqcurie2.dtb \
> diff --git a/arch/arm/boot/dts/rk1108-evb.dts
> b/arch/arm/boot/dts/rk1108-evb.dts new file mode 100644
> index 0000000..3956cff
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk1108-evb.dts
> @@ -0,0 +1,69 @@
> +/*
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "rk1108.dtsi"
> +
> +/ {
> + model = "Rockchip RK1108 Evaluation board";
> + compatible = "rockchip,rk1108-evb", "rockchip,rk1108";
> +
> + memory@60000000 {
> + device_type = "memory";
> + reg = <0x60000000 0x08000000>;
> + };
> +
> + chosen {
> + stdout-path = "serial2:1500000n8";
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
^ permalink raw reply
* RE: [RFC 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20
From: Ramesh Shanmugasundaram @ 2016-11-04 9:23 UTC (permalink / raw)
To: Antti Palosaari, Laurent Pinchart
Cc: robh+dt@kernel.org, mark.rutland@arm.com, mchehab@kernel.org,
hverkuil@xs4all.nl, sakari.ailus@linux.intel.com, Chris Paterson,
geert@linux-m68k.org, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <9ec35a3a-02a7-8067-8f7c-23243de8456a@iki.fi>
Hi Antti,
Thanks for the response.
> Subject: Re: [RFC 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20
>
> Hello
>
> On 11/02/2016 10:58 PM, Laurent Pinchart wrote:
> > Hi Ramesh,
> >
> > On Wednesday 02 Nov 2016 09:00:00 Ramesh Shanmugasundaram wrote:
> >> Hi Laurent,
> >>
> >> Any further thoughts on the SDR format please (especially the comment
> >> below). I would appreciate your feedback.
> >>
> >>>> On Wednesday 12 Oct 2016 15:10:29 Ramesh Shanmugasundaram wrote:
> >>>>> This patch adds documentation for the three new SDR formats
> >>>>>
> >>>>> V4L2_SDR_FMT_SCU16BE
> >>>>> V4L2_SDR_FMT_SCU18BE
> >>>>> V4L2_SDR_FMT_SCU20BE
> >>
> >> [snip]
> >>
> >>>>> +
> >>>>> + - start + 0:
> >>>>> +
> >>>>> + - I'\ :sub:`0[D13:D6]`
> >>>>> +
> >>>>> + - I'\ :sub:`0[D5:D0]`
> >>>>> +
> >>>>> + - .. row 2
> >>>>> +
> >>>>> + - start + buffer_size/2:
> >>>>> +
> >>>>> + - Q'\ :sub:`0[D13:D6]`
> >>>>> +
> >>>>> + - Q'\ :sub:`0[D5:D0]`
> >>>>
> >>>> The format looks planar, does it use one V4L2 plane (as does NV12)
> >>>> or two V4L2 planes (as does NV12M) ? Same question for the other
> formats.
> >>>
> >>> Thank you for bringing up this topic. This is one of the key design
> >>> dilemma.
> >>>
> >>> The I & Q data for these three SDR formats comes from two different
> >>> DMA channels and hence two separate pointers -> we could say it is
> >>> v4l2 multi- planar. Right now, I am making it look like a single
> >>> plane by presenting the data in one single buffer ptr.
> >>>
> >>> For e.g. multi-planar SC16 format would look something like this
> >>>
> >>> <------------------------32bits---------------------->
> >>> <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0 + 0
> >>> <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0 + 4
> ...
> >>> <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1 + 0
> >>> <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1 + 4
> >>>
> >>> My concerns are
> >>>
> >>> 1) These formats are not a standard as the video "Image Formats".
> >>> These formats are possible when we use DRIF + MAX2175 combination.
> >>> If we interface with a different tuner vendor, the above format(s)
> >>> MAY/MAY NOT be re-usable. We do not know at this point. This is the
> >>> main open item for discussion in the cover letter.
> >
> > If the formats are really device-specific then they should be
> > documented accordingly and not made generic.
> >
> >>> 2) MPLANE support within V4L2 seems specific to video. Please
> >>> correct me if this is wrong interpretation.
> >>>
> >>> - struct v4l2_format contains v4l2_sdr_format and
> >>> v4l2_pix_format_mplane as members of union. Should I create a new
> >>> v4l2_sdr_format_mplane? If I have to use v4l2_pix_format_mplane most
> >>> of the video specific members would be unused (it would be similar
> >>> to using v4l2_pix_format itself instead of v4l2_sdr_format)?
> >
> > I have no answer to that question as I'm not familiar with SDR. Antti,
> > you've added v4l2_sdr_format to the API, what's your opinion ? Hans,
> > as you've acked the patch, your input would be appreciated as well.
>
> If I understood correctly this hardware provides I and Q samples via
> different channels and driver now combines those channels as a sequential
> IQ sample pairs.
The driver combines the two buffer ptrs and present as one single buffer. For a buffer of size 200
ptr + 0 : I I I I ... I
ptr + 100 : Q Q Q Q ... Q
>I have never seen any other than hw which provides IQ IQ
> IQ IQ ... IQ.
There are some modes where this h/w combo can also do IQ IQ IQ pattern. Those modes are not added in the RFC patchset.
> This is
> I I I I ... I
> Q Q Q Q ... Q
> I am not very familiar with planars, but it sounds like it is correct
> approach. So I think should be added rather than emulate packet sequential
> format.
My understanding of V4L2 MPLANE constructs is limited to a quick code read only. At this point MPLANE support seems specific to video. SDR is defined as separate format like v4l2_pix_format. Questions would be - should we define new SDR_MPLANE? or merge SDR format with pix format & reuse existing MPLANE with some SDR extensions (if possible)? These seem big design decisions. Any suggestions please?
For my use case, MPLANE support does not seem to add significant benefit except it may be syntactically correct. I am doing cyclic DMA with a small set of h/w buffers and copying each stage to one mmapped vmalloc vb2_buffer at two offsets. If we add MPLANE support, it can be two non-contiguous buffer pointers.
>
> >
> >>> - The above decision (accomodate SDR & MPLANE) needs to be
> >>> propagated across the framework. Is this the preferred approach?
> >>>
> >>> It goes back to point (1). As of today, the change set for this
> >>> combo
> >>> (DRIF+MAX2175) introduces new SDR formats only. Should it add
> >>> further
> >>> SDR+MPLANE support to the framework as well?
> >>>
> >>> I would appreciate your suggestions on this regard.
Thanks,
Ramesh
^ permalink raw reply
* Re: [PATCH 3/6] msm8994 clocks: global clock support for msm8994 SOC.
From: Bastian Köcher @ 2016-11-04 9:12 UTC (permalink / raw)
To: Jeremy McNicoll
Cc: Mark Rutland, Jeremy McNicoll, linux-arm-msm, linux-soc,
devicetree, robh, andy.gross, sboyd, arnd, bjorn.andersson,
michael.scott
In-Reply-To: <20161103234351.GA15102@mini-rhel.redhat.com>
On Donnerstag, 3. November 2016 16:43:52 CET Jeremy McNicoll wrote:
> On Thu, Nov 03, 2016 at 10:42:34PM +0000, Mark Rutland wrote:
> > On Tue, Oct 25, 2016 at 04:16:58AM -0700, Jeremy McNicoll wrote:
> > > +static const struct qcom_cc_desc gcc_msm8994_desc = {
> > > + .config = &gcc_msm8994_regmap_config,
> > > + .clks = gcc_msm8994_clocks,
> > > + .num_clks = ARRAY_SIZE(gcc_msm8994_clocks),
> > > + .resets = NULL,
> > > + .num_resets = 0,
> > > + .gdscs = NULL,
> > > + .num_gdscs = 0,
> > > +};
> > > +
> > > +static const struct of_device_id gcc_msm8994_match_table[] = {
> > > + { .compatible = "qcom,gcc-8994" },
> > > + { .compatible = "qcom,gcc-8994v2" },
> > > + {}
> > > +}
> > > +
> > > +MODULE_DEVICE_TABLE(of, gcc_msm8994_match_table);
> > > +
> > > +static int gcc_msm8994_probe(struct platform_device *pdev)
> > > +{
> > > + struct device *dev = &pdev->dev;
> > > + struct clk *clk;
> > > + const char *compat = NULL;
> > > + int compatlen = 0;
> > > + bool is_v2 = false;
> > > +
> > > + clk = devm_clk_register(dev, &xo.hw);
> > > + if (IS_ERR(clk))
> > > + return PTR_ERR(clk);
> > > +
> > > + compat = of_get_property(pdev->dev.of_node, "compatible", &compatlen);
> > > + if (!compat || (compatlen <= 0))
> > > + return -EINVAL;
> >
> > It is almost never correct to use of_get_property(). Please avoid it.
> >
>
> Hi Bastian,
>
> Mark is basically suggesting that instead of using of_get_property() you
> should be using something like of_device_compatible_match, or
> of_device_is_compatible. This should simplify the code a little bit
> too.
>
> Unless I am misunderstanding Mark's comment.
>
> -jeremy
We do not need that anymore, because that was required for the "v2" check.
Bastian
>
>
> > > +
> > > + is_v2 = !strcmp(compat, "qcom,gcc-8994v2");
> > > + if (is_v2)
> > > + msm_gcc_8994v2_fixup();
> >
> > Either put some data in the of_device_id tables, and use that to determine what
> > to do here, or use of_device_is_compatible() or of_match_node() to check the
> > string.
> >
> > Thanks,
> > Mark.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v2] ARM: DTS: r8a7794: alt: Fix PFC names for DU
From: Simon Horman @ 2016-11-04 9:02 UTC (permalink / raw)
To: Jacopo Mondi
Cc: magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478201686-25488-1-git-send-email-jacopo-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
Hi,
On Thu, Nov 03, 2016 at 08:34:46PM +0100, Jacopo Mondi wrote:
> Update the PFC pin groups and function names of DU interface for
> r8a7794 ALT board.
>
> The currently specified pin groups and function names prevented PFC and
> DU interfaces from being correctly configured:
>
> sh-pfc e6060000.pin-controller: function 'du' not supported
> sh-pfc e6060000.pin-controller: invalid function du in map table
> sh-pfc e6060000.pin-controller: function 'du' not supported
> sh-pfc e6060000.pin-controller: invalid function du in map table
> sh-pfc e6060000.pin-controller: function 'du' not supported
> sh-pfc e6060000.pin-controller: invalid function du in map table
> sh-pfc e6060000.pin-controller: function 'du' not supported
> sh-pfc e6060000.pin-controller: invalid function du in map table
> rcar-du: probe of feb00000.display failed with error -22
>
> Signed-off-by: Jacopo Mondi <jacopo-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
> ---
>
> v1->v2:
> - s/PCF/PFC/ in commit message according to Sergei Shtylyov's comment
>
> Patch applied against Simon Horman's renesas/master branch.
> The PCF pin groups and function renaming was introduced by commit 56ed4bb9 and
> DTS for ALT board has never been update accordingly.
> Tested displaying frames on VGA interface: the rcar-du driver loads correctly.
Thanks for noticing this.
There is no need to repost to update the subject, but for reference I would
prefer the prefix to be "ARM: dts: alt:". Assuming there are no other
changes I can fix that up when queuing up this change.
I am wondering if this should be queued up as a fix for v4.9 and in turn
v4.8-stable. Or if it should just be queued up for v4.10.
In the case of the former I'd advocate adding the following tag
(again no need to repost just to update this):
Fixes: 56ed4bb984ac ("pinctrl: sh-pfc: r8a7794: Add DU pin groups")
> arch/arm/boot/dts/r8a7794-alt.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
> index 8d1b35a..9d65fb3 100644
> --- a/arch/arm/boot/dts/r8a7794-alt.dts
> +++ b/arch/arm/boot/dts/r8a7794-alt.dts
> @@ -165,8 +165,8 @@
> pinctrl-names = "default";
>
> du_pins: du {
> - groups = "du1_rgb666", "du1_sync", "du1_disp", "du1_dotclkout0";
> - function = "du";
> + groups = "du1_rgb666", "du1_sync", "du1_disp", "du1_clk0_out";
> + function = "du1";
> };
>
> scif2_pins: scif2 {
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] ARM: dts: stm32f429: Add QSPI clock
From: gabriel.fernandez @ 2016-11-04 8:52 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue
Cc: devicetree, linux-arm-kernel, linux-kernel, kernel,
gabriel.fernandez
In-Reply-To: <1478249577-25999-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch adds the QSPI clock for stm32f469 discovery board.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
arch/arm/boot/dts/stm32f469-disco.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
index e911af8..c43a484 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -66,6 +66,10 @@
};
};
+&rcc {
+ compatible = "st,stm32f469-rcc", "st,stm32f42xx-rcc", "st,stm32-rcc";
+};
+
&clk_hse {
clock-frequency = <8000000>;
};
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: stm32f429: add LSI and LSE clocks
From: gabriel.fernandez @ 2016-11-04 8:52 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue
Cc: devicetree, linux-arm-kernel, linux-kernel, kernel,
gabriel.fernandez
In-Reply-To: <1478249577-25999-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch adds lsi / lse oscillators. These clocks can be use by
RTC clocks.
The clock drivers needs to disable the power domain write protection using
syscon / regmap to enable these clocks.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 336ee4f..2700449 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -56,6 +56,18 @@
compatible = "fixed-clock";
clock-frequency = <0>;
};
+
+ clk-lse {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ };
+
+ clk-lsi {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32000>;
+ };
};
soc {
@@ -185,6 +197,11 @@
interrupts = <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>, <23>, <40>, <41>, <42>, <62>, <76>;
};
+ pwrcfg: power-config@40007000 {
+ compatible = "syscon";
+ reg = <0x40007000 0x400>;
+ };
+
pin-controller {
#address-cells = <1>;
#size-cells = <1>;
@@ -340,6 +357,7 @@
compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
reg = <0x40023800 0x400>;
clocks = <&clk_hse>;
+ st,syscfg = <&pwrcfg>;
};
dma1: dma-controller@40026000 {
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] STM32F4 Enable RTC & QSPI clocks
From: gabriel.fernandez @ 2016-11-04 8:52 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue
Cc: devicetree, linux-arm-kernel, linux-kernel, kernel,
gabriel.fernandez
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch-set enables RTC & QSPI clocks.
Gabriel Fernandez (2):
ARM: dts: stm32f429: add LSI and LSE clocks
ARM: dts: stm32f429: Add QSPI clock
arch/arm/boot/dts/stm32f429.dtsi | 18 ++++++++++++++++++
arch/arm/boot/dts/stm32f469-disco.dts | 4 ++++
2 files changed, 22 insertions(+)
--
1.9.1
^ permalink raw reply
* Re: [PATCH v2 13/14] ARM: dts: sun6i: hummingbird: Enable internal audio codec
From: Chen-Yu Tsai @ 2016-11-04 8:12 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Rob Herring, Mark Rutland, Linux-ALSA,
linux-arm-kernel, linux-kernel, devicetree, linux-sunxi
In-Reply-To: <20161103084543.m4zvwhscpaa3y5ay@lukather>
On Thu, Nov 3, 2016 at 4:45 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Thu, Nov 03, 2016 at 03:55:55PM +0800, Chen-Yu Tsai wrote:
>> The Hummingbird A31 has headset and line in audio jacks and an onboard
>> mic routed to the pins for the SoC's internal codec. The line out pins
>> are routed to an onboard speaker amp, whose output is available on a
>> pin header.
>>
>> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>> ---
>> arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> index 9a74637f677f..48c041b75aab 100644
>> --- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> +++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> @@ -69,6 +69,19 @@
>> };
>> };
>>
>> +&codec {
>> + allwinner,audio-routing =
>> + "Headphone", "HP",
>> + "Speaker", "LINEOUT",
>> + "LINEIN", "Line In",
>> + "MIC1", "Mic",
>> + "MIC2", "Headset Mic",
>> + "Mic", "MBIAS",
>> + "Headset Mic", "HBIAS";
>> + allwinner,pa-gpios = <&pio 7 22 GPIO_ACTIVE_HIGH>; /* PH22 */
>> + status = "okay";
>> +};
>> +
>> &cpu0 {
>> cpu-supply = <®_dcdc3>;
>> };
>> @@ -152,6 +165,13 @@
>> };
>>
>> &pio {
>> + codec_pa_pin: codec_pa_pin@0 {
>> + allwinner,pins = "PH22";
>> + allwinner,function = "gpio_out";
>> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> + };
>> +
>
> This pin group isn't used anywhere. Because of the strict thing in
> pinctrl, I'd say it's better to not set it, but then, the pin group is
> useless.
I'll drop the pinmux setting then.
ChenYu
^ permalink raw reply
* Re: [PATCH 4/6] ARM: dts: add basic support for Rockchip RK1108 SOC
From: Heiko Stuebner @ 2016-11-04 8:07 UTC (permalink / raw)
To: Andy Yan
Cc: elaine.zhang-TNX95d0MmH7DzftRWevZcw,
mturquette-rdvid1DuHRBWk0Htik3J/w,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478176848-12132-1-git-send-email-andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Donnerstag, 3. November 2016, 20:40:48 CET schrieb Andy Yan:
> RK1108 is embedded with an ARM Cortex-A7 single core and a DSP core.
> It is designed for varies application scenario such as car DVR, sports
> DV, secure camera and UAV camera.
>
> This patch add basic support for it with DMAC / UART / CRU / pinctrl
> enabled.
>
> Signed-off-by: Andy Yan <andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
>
> arch/arm/boot/dts/rk1108.dtsi | 420
> ++++++++++++++++++++++++++++++++++++++ arch/arm/mach-rockchip/rockchip.c |
> 1 +
> 2 files changed, 421 insertions(+)
> create mode 100644 arch/arm/boot/dts/rk1108.dtsi
>
> diff --git a/arch/arm/boot/dts/rk1108.dtsi b/arch/arm/boot/dts/rk1108.dtsi
> new file mode 100644
> index 0000000..9dccfea
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk1108.dtsi
[...]
> + pinctrl: pinctrl {
> + compatible = "rockchip,rk1108-pinctrl";
> + rockchip,grf = <&grf>;
missing rockchip,pmu phandle for gpio0 iomuxes and also syscon declaration for
said pmugrf syscon in this file.
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/6] ARM: dts: add basic support for Rockchip RK1108 SOC
From: Heiko Stuebner @ 2016-11-04 8:00 UTC (permalink / raw)
To: Andy Yan
Cc: elaine.zhang-TNX95d0MmH7DzftRWevZcw,
mturquette-rdvid1DuHRBWk0Htik3J/w,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478176848-12132-1-git-send-email-andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Donnerstag, 3. November 2016, 20:40:48 CET schrieb Andy Yan:
> RK1108 is embedded with an ARM Cortex-A7 single core and a DSP core.
> It is designed for varies application scenario such as car DVR, sports
> DV, secure camera and UAV camera.
>
> This patch add basic support for it with DMAC / UART / CRU / pinctrl
> enabled.
>
> Signed-off-by: Andy Yan <andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
>
> arch/arm/boot/dts/rk1108.dtsi | 420
> ++++++++++++++++++++++++++++++++++++++ arch/arm/mach-rockchip/rockchip.c |
> 1 +
> 2 files changed, 421 insertions(+)
> create mode 100644 arch/arm/boot/dts/rk1108.dtsi
>
> diff --git a/arch/arm/boot/dts/rk1108.dtsi b/arch/arm/boot/dts/rk1108.dtsi
> new file mode 100644
> index 0000000..9dccfea
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk1108.dtsi
> @@ -0,0 +1,420 @@
> +/*
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/rk1108-cru.h>
> +#include <dt-bindings/pinctrl/rockchip.h>
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + compatible = "rockchip,rk1108";
> +
> + interrupt-parent = <&gic>;
> +
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + serial2 = &uart2;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@f00 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0xf00>;
> + };
> +
unnecessary empty line
> + };
> +
> + amba {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + pdma: pdma@102a0000 {
> + compatible = "arm,pl330", "arm,primecell";
> + reg = <0x102a0000 0x4000>;
> + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> + #dma-cells = <1>;
> + arm,pl330-broken-no-flushp;
> + clocks = <&cru ACLK_DMAC>;
> + clock-names = "apb_pclk";
> + };
> + };
> +
> + arm-pmu {
> + compatible = "arm,cortex-a7-pmu";
> + interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> +
> + timer {
> + compatible = "arm,armv7-timer";
> + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
CPU_MASK_SIMPLE(4)? You only have one core, not 4.
> + clock-frequency = <24000000>;
> + };
> +
> + xin24m: oscillator {
> + compatible = "fixed-clock";
> + clock-frequency = <24000000>;
> + clock-output-names = "xin24m";
> + #clock-cells = <0>;
> + };
> +
> + bus_intmem@10080000 {
> + compatible = "mmio-sram";
> + reg = <0x10080000 0x2000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x10080000 0x2000>;
> + };
> +
> + grf: syscon@10300000 {
> + compatible = "rockchip,rk1108-grf", "syscon";
> + reg = <0x10300000 0x1000>;
> + };
> +
> + emmc: dwmmc@30110000 {
> + compatible = "rockchip,rk1108-dw-mshc", "rockchip,rk3288-dw-mshc";
> + clock-freq-min-max = <400000 150000000>;
> + clocks = <&cru HCLK_EMMC>, <&cru SCLK_EMMC>,
> + <&cru SCLK_EMMC_DRV>, <&cru SCLK_EMMC_SAMPLE>;
> + clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> + fifo-depth = <0x100>;
> + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> + reg = <0x30110000 0x4000>;
> + status = "disabled";
> + };
> +
> + sdio: dwmmc@30120000 {
> + compatible = "rockchip,rk1108-dw-mshc", "rockchip,rk3288-dw-mshc";
> + clock-freq-min-max = <400000 150000000>;
> + clocks = <&cru HCLK_SDIO>, <&cru SCLK_SDIO>,
> + <&cru SCLK_SDIO_DRV>, <&cru SCLK_SDIO_SAMPLE>;
> + clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> + fifo-depth = <0x100>;
> + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> + reg = <0x30120000 0x4000>;
> + status = "disabled";
> + };
> +
> + sdmmc: dwmmc@30130000 {
ordering by register address please (uart2 before sdmmc etc; same for
everything else)
> + compatible = "rockchip,rk1108-dw-mshc", "rockchip,rk3288-dw-mshc";
> + clock-freq-min-max = <400000 100000000>;
> + clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>,
> + <&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
> + clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> + fifo-depth = <0x100>;
> + interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
> + reg = <0x30130000 0x4000>;
> + status = "disabled";
> + };
> +
> + uart2: serial@10210000 {
> + compatible = "rockchip,rk1108-uart", "snps,dw-apb-uart";
> + reg = <0x10210000 0x100>;
> + interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <24000000>;
> + clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
> + clock-names = "baudclk", "apb_pclk";
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart2m0_xfer>;
> + status = "disabled";
> + };
> +
> + uart1: serial@10220000 {
> + compatible = "rockchip,rk1108-uart", "snps,dw-apb-uart";
> + reg = <0x10220000 0x100>;
> + interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <24000000>;
> + clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
> + clock-names = "baudclk", "apb_pclk";
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart1_xfer>;
> + status = "disabled";
> + };
> +
> + uart0: serial@10230000 {
> + compatible = "rockchip,rk1108-uart", "snps,dw-apb-uart";
> + reg = <0x10230000 0x100>;
> + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <24000000>;
> + clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
> + clock-names = "baudclk", "apb_pclk";
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_xfer &uart0_cts &uart0_rts>;
> + status = "disabled";
> + };
> +
> + cru: clock-controller@20200000 {
> + compatible = "rockchip,rk1108-cru";
> + reg = <0x20200000 0x1000>;
> + rockchip,grf = <&grf>;
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> + gic: interrupt-controller@32010000 {
> + compatible = "arm,cortex-a15-gic";
compatible = "arm,gic-400"; ?
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + #address-cells = <0>;
> +
> + reg = <0x32011000 0x1000>,
> + <0x32012000 0x1000>;
please provide all 4 register areas and also the interrupt (
> + };
> +
[...]
> diff --git a/arch/arm/mach-rockchip/rockchip.c
> b/arch/arm/mach-rockchip/rockchip.c index a7ab9ec..e7fdf06 100644
> --- a/arch/arm/mach-rockchip/rockchip.c
> +++ b/arch/arm/mach-rockchip/rockchip.c
> @@ -76,6 +76,7 @@ static void __init rockchip_dt_init(void)
> }
>
> static const char * const rockchip_board_dt_compat[] = {
> + "rockchip,rk1108",
> "rockchip,rk2928",
> "rockchip,rk3066a",
> "rockchip,rk3066b",
please split this into a separate patch, as code and dts changes need to go
through different branches.
Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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