* [PATCH 1/3] ARM: dts: rockchip: Enable build of rk3066 MK808 dts
From: Heiko Stuebner @ 2016-10-06 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <84d4bc0b733cb9776f03ad54bb946fd1c4be4049.1475764778.git.paweljarosz3691@gmail.com>
Hi Pawe?,
Am Donnerstag, 6. Oktober 2016, 18:22:40 CEST schrieb =?UTF-8?q?
Pawe=C5=82=20Jarosz?=:
> MK808 is rockchip rk3066 based board made by Rickomagic. It has two usb
> ports, sdmmc, wifi and uart onboard.
>
> Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..f19cc1d 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -639,6 +639,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> rk3036-kylin.dtb \
> rk3066a-bqcurie2.dtb \
> rk3066a-marsboard.dtb \
> + rk3066a-mk808.dtb \
> rk3066a-rayeager.dtb \
> rk3188-radxarock.dtb \
> rk3228-evb.dtb \
This patch breaks bisectability, as it adds a dtb to the makefile that you only
add in patch3 which makes builds fail. Please fold your patches 1 and 3 into
one patch and also add and entry to Documentation/devicetree/bindings/arm/
rockchip.txt for the board.
Heiko
^ permalink raw reply
* PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
From: Michael Niewöhner @ 2016-10-06 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFp+6iGx-jf+xrdHF=0J3FK9dDBg54zESYNVo8bz2Qz6G4gEZg@mail.gmail.com>
Hi Vivek,
On Di, 2016-10-04 at 17:32 +0530, Vivek Gautam wrote:
> Hi Michael,
>
>
> On Tue, Oct 4, 2016 at 4:28 PM, Michael Niew?hner <linux@mniewoehner.de> wrote:
>
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > [1.] One line summary of the problem:
> > > > > > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
> > > > > > >
> > > > > > > [2.] Full description of the problem/report:
> > > > > > > No usb 3.0 devices are being detected when attached while USB 2.0
> > > > > > > devices work on the same port.
> > > > > > > USB 3.0 works after applying patches [9.1] and [9.2], but seems
> > > > > > > to be
> > > > > > > buggy. The usb hub is redetected every time an usb device is
> > > > > > > attached.
>
> [snip]
>
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > [9.] Other notes, patches, fixes, workarounds:
> > > > > > > > [9.1] https://lkml.org/lkml/2014/4/28/234
> > > > > > > > [9.2] https://lkml.org/lkml/2015/2/2/259
> > >
> > > These patches are required to get USB super-speed working on Exynos5420/5800.
> > > But they did not make to upstream. There was resistance on adding new
> > > phy_calibrate()
> > > callback.
> > >
> > > Without these patches the Exynos5420/5800 will enumerate all
> > > super-speed capable devices
> > > as high-speed devices.
> > > Last time we checked with exynos542x smdk boards and peach-* boards,
> > > we could get the
> > > Super - speed devices working. I have not tested odroid anytime so
> > > don't have much idea about the
> > > its intricacies.
> > > I guess Anand was able to use these patches to get his kernel working in past.
> >
> >
> > The patches don't work anymore with 4.8-rc* / 4.8. They worked - but very
> > unstable - with 4.7.
> >
> > One more problem appeared since one of the 4.8-RCs: reboot hangs when the dwc3
> > module is loaded. If I unload it before reboot / shutdown everything is fine.
> >
> >
> > >
> > >
> > > When you have a downstream on-board usb hub, ideally it should be able
> > > to detect the devices
> > > and not reset everytime you connect a new device (like you mentioned earlier).
> > > There can be two possible reasons why the hub keeps getting reset ever
> > > after applying the above
> > > mentioned patches:
> > > 1) the clock rates are not proper.
> > > 2) the regulator load setting is not enough to drive the hub.
> > >
> > > Anand, can you please point Michael to an older kernel with which you
> > > could test usb on odroid successfully ?
> > > You can compare the clocks with an older version and see if there'a
> > > any difference.
> > >
> > > Any possibility of any other framework (such as, bus-freq) trimming
> > > down the clock - rates ?
> >
> >
> > ################################
> > # v4.7.5
> > ################################
> >
> > $ cat /sys/kernel/debug/clk/clk_summary | grep usb
> > ?sclk_usbh20_scan_clk?????????????????????0????????????0???480000000??????????0
> > ?sclk_usbh20??????????????????????????????0????????????0????48000
> > 000??????????0
> > ????mout_usbd300??????????????????????????1????????????1????24000000??????????0
> > ???????dout_usbd300???????????????????????0????????????0????24000000??????????0
> > ??????????sclk_usbd300
> > ?????????????????0????????????0????24000000??????????0
> > ???????dout_usbphy300?????????????????????1????????????1????24000000??????????0
> > ??????????sclk_usbphy300??????????????????4????????????4????24000
> > 000??????????0
> > ????mout_usbd301??????????????????????????1????????????1????24000000??????????0
> > ???????dout_usbd301???????????????????????0????????????0????24000000??????????0
> > ??????????sclk_usbd301
> > ?????????????????0????????????0????24000000??????????0
> > ???????dout_usbphy301?????????????????????1????????????1????24000000??????????0
> > ??????????sclk_usbphy301??????????????????3????????????3????24000
> > 000??????????0
> > ?????????????????????????usbd301???????????1????????????1???100000000
> > ?????????????????????????usbd300???????????1????????????1???100000000
> >
> > usbh20???????????3????????????3???100000000??????????0
>
> >
> >
> > ################################
> > # v4.8.0
> > ################################
> >
> > $ cat /sys/kernel/debug/clk/clk_summary | grep usb
> > ?sclk_usbh20_scan_clk?????????????????????0????????????0???480000000??????????0
> > ?sclk_usbh20??????????????????????????????0????????????0????48000000
> > ????????0
> > ????mout_usbd300??????????????????????????1????????????1????24000000??????????0
> > ???????dout_usbd300???????????????????????0????????????0????24000000??????????0
> > ??????????sclk_usbd300
> > ????????????0????????????0????24000000??????????0
> > ???????dout_usbphy300?????????????????????1????????????1????24000000??????????0
> > ??????????sclk_usbphy300??????????????????4????????????4????24000000
> > ????????0
> > ????mout_usbd301??????????????????????????1????????????1????24000000??????????0
> > ???????dout_usbd301???????????????????????0????????????0????24000000??????????0
> > ??????????sclk_usbd301
> > ????????????0????????????0????24000000??????????0
> > ???????dout_usbphy301?????????????????????1????????????1????24000000??????????0
> > ??????????sclk_usbphy301??????????????????3????????????3????24000000
> > ????????0
> > ?????????????????????????usbd301???????????1????????????1???100000000
>
> This clock should have been 200MHz.
>
> >
> > ?????????????????????????usbd300???????????1????????????1???100000000
> > ?????????????????????????usbh2
> > 0???????????3????????????3???100000000??????????0
> >
> > $ cat /sys/kernel/debug/usb/devices
> > <<system hangs>>
> >
>
> The clocks are same across working/non-working.
> Is it possible to bisect the commit that's causing hang for 4.8x ?
[c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor init and exit paths
This patch causes both the hang on reboot and the lsusb hang.
>
> Adding few of the folks from Samsung who can test dwc3 usb on smdk/peach boards.
> +Alim, Pankaj
>
> Hi Alim, Pankaj,
> can you please give a try with 4.8 kernel on peach/smdk542x board and
> see if dwc3 usb works or not.
> You may need to the patches mentioned in [9.1] and [9.2] mentioned above.
>
>
> [snip]
>
>
> Thanks
> Vivek
>
Best regards
Michael
^ permalink raw reply
* [PATCH 3/3] ARM: dts: rockchip: Add rk3066 MK808 board devicetree description file
From: =?UTF-8?q?Pawe=C5=82=20Jarosz?= @ 2016-10-06 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1475764778.git.paweljarosz3691@gmail.com>
MK808 is a tv stick which has rockchip rk3066 CPU inside, two usb ports
- host and otg, micro sd card slot and onboard wifi RK901.
Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
---
arch/arm/boot/dts/rk3066a-mk808.dts | 184 ++++++++++++++++++++++++++++++++++++
1 file changed, 184 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts
diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts b/arch/arm/boot/dts/rk3066a-mk808.dts
new file mode 100644
index 0000000..2878562
--- /dev/null
+++ b/arch/arm/boot/dts/rk3066a-mk808.dts
@@ -0,0 +1,184 @@
+/*
+ * Copyright (c) 2016 Pawe? Jarosz <paweljarosz3691@gmail.com>
+ *
+ * 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 "rk3066a.dtsi"
+
+/ {
+ model = "Rikomagic MK808";
+ compatible = "rikomagic,mk808", "rockchip,rk3066a";
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ };
+
+ memory at 60000000 {
+ device_type = "memory";
+ reg = <0x60000000 0x40000000>;
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ blue {
+ label = "mk808:blue:power";
+ gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ linux,default-trigger = "default-on";
+ };
+ };
+
+ mmc_pwrseq: mmc-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_pwr>;
+ reset-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_pwr>;
+ reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>;
+ };
+
+ vcc_io: vcc-io {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_io";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ vcc_host: usb-host-regulator {
+ compatible = "regulator-fixed";
+ gpio = <&gpio0 6 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <&host_drv>;
+ pinctrl-names = "default";
+ regulator-always-on;
+ regulator-name = "host-pwr";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ startup-delay-us = <100000>;
+ vin-supply = <&vcc_io>;
+ };
+
+ vcc_otg: usb-otg-regulator {
+ compatible = "regulator-fixed";
+ gpio = <&gpio0 5 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <&otg_drv>;
+ pinctrl-names = "default";
+ regulator-always-on;
+ regulator-name = "vcc_otg";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ startup-delay-us = <100000>;
+ vin-supply = <&vcc_io>;
+ };
+};
+
+&mmc0 {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ mmc-pwrseq = <&mmc_pwrseq>;
+ num-slots = <1>;
+ status = "okay";
+ vmmc-supply = <&vcc_io>;
+};
+
+&mmc1 {
+ bus-width = <4>;
+ disable-wp;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ non-removable;
+ num-slots = <1>;
+ status = "okay";
+ vmmc-supply = <&vcc_io>;
+};
+
+&pinctrl {
+ usb-host {
+ host_drv: host-drv {
+ rockchip,pins = <RK_GPIO0 6 RK_FUNC_GPIO &pcfg_pull_default>;
+ };
+ };
+
+ usb-otg {
+ otg_drv: otg-drv {
+ rockchip,pins = <RK_GPIO0 5 RK_FUNC_GPIO &pcfg_pull_default>;
+ };
+ };
+
+ sdmmc {
+ sdmmc_pwr: sdmmc-pwr {
+ rockchip,pins = <RK_GPIO3 7 RK_FUNC_GPIO &pcfg_pull_default>;
+ };
+ };
+
+ sdio {
+ wifi_pwr: wifi-pwr {
+ rockchip,pins = <RK_GPIO3 24 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&usb_host {
+ status = "okay";
+};
+
+&usb_otg {
+ status = "okay";
+};
+
+&usbphy {
+ status = "okay";
+};
+
+&wdt {
+ status = "okay";
+};
+
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] devicetree: Add vendor prefix for Rikomagic
From: =?UTF-8?q?Pawe=C5=82=20Jarosz?= @ 2016-10-06 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1475764778.git.paweljarosz3691@gmail.com>
Add Rikomagic to vendor-prefixes.txt
Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 69caf14..3edfa08 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -224,6 +224,7 @@ realtek Realtek Semiconductor Corp.
renesas Renesas Electronics Corporation
richtek Richtek Technology Corporation
ricoh Ricoh Co. Ltd.
+rikomagic Rikomagic
rockchip Fuzhou Rockchip Electronics Co., Ltd
samsung Samsung Semiconductor
sandisk Sandisk Corporation
--
2.7.4
^ permalink raw reply related
* [linux-sunxi] [PATCH 9/9] [DO NOT MERGE] ARM: dts: sun6i: Enable 7" LCD panel on Sinlinx SinA31s
From: Icenowy Zheng @ 2016-10-06 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-10-wens@csie.org>
07.10.2016, 00:06, "Chen-Yu Tsai" <wens@csie.org>:
> Sinlinx SinA31s comes with an optional 7" 1024x600 LCD panel with
> capacitive touch panel that bolts on to the board.
>
> Enable the display using a panel with close timings. This patch is more
> of a proof of concept. The LCD panel has no markings whatsoever, and
> the timings are not exactly the same, and as a result the display produces
> glitch lines sometimes.
As you say, you can use the panel of SinA33...
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> ?arch/arm/boot/dts/sun6i-a31s-sina31s.dts | 30 ++++++++++++++++++++++++++++++
> ?1 file changed, 30 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
> index 6ead2f5c847a..2d5cf8c9a12f 100644
> --- a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
> +++ b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
> @@ -63,6 +63,23 @@
> ?????????????????????????gpios = <&pio 7 13 GPIO_ACTIVE_HIGH>; /* PH13 */
> ?????????????????};
> ?????????};
> +
> + panel: panel {
> + compatible = "avic,tm070ddh03", "simple-panel";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + panel_input: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&tcon0_out_lcd>;
> + };
> + };
> + };
> ?};
>
> ?&ehci0 {
> @@ -148,6 +165,19 @@
> ?????????regulator-name = "vcc-gmac-phy";
> ?};
>
> +&tcon0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd0_rgb888_pins>;
> + status = "okay";
> +};
> +
> +&tcon0_out {
> + tcon0_out_lcd: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&panel_input>;
> + };
> +};
> +
> ?&usbphy {
> ?????????status = "okay";
> ?};
> --
> 2.9.3
>
> --
> 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 at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH 1/3] ARM: dts: rockchip: Enable build of rk3066 MK808 dts
From: =?UTF-8?q?Pawe=C5=82=20Jarosz?= @ 2016-10-06 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1475764778.git.paweljarosz3691@gmail.com>
MK808 is rockchip rk3066 based board made by Rickomagic. It has two usb
ports, sdmmc, wifi and uart onboard.
Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
---
arch/arm/boot/dts/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..f19cc1d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -639,6 +639,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3036-kylin.dtb \
rk3066a-bqcurie2.dtb \
rk3066a-marsboard.dtb \
+ rk3066a-mk808.dtb \
rk3066a-rayeager.dtb \
rk3188-radxarock.dtb \
rk3228-evb.dtb \
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] Add MK808 RK3066 device
From: =?UTF-8?q?Pawe=C5=82=20Jarosz?= @ 2016-10-06 16:22 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for Rikomagic MK808 v1 device with RK901 wifi.
It is hdmi stick with two usb ports(host and otg), sdmmc, wifi and uart
onboard.
It is RK3066 based.
Pawe? Jarosz (3):
ARM: dts: rockchip: Enable build of rk3066 MK808 dts
devicetree: Add vendor prefix for Rikomagic
ARM: dts: rockchip: Add rk3066 MK808 board devicetree description file
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk3066a-mk808.dts | 184 +++++++++++++++++++++
3 files changed, 186 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts
--
2.7.4
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Robert Richter @ 2016-10-06 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-oYzSn_eeqaX3QVFeQjBGkaX-Wh7+oPcQFcXv7J6GOFQ@mail.gmail.com>
Ard,
thank you for your answer and you explanation.
On 06.10.16 11:00:33, Ard Biesheuvel wrote:
> On 6 October 2016 at 10:52, Robert Richter <rrichter@cavium.com> wrote:
> > There is a memory setup problem on ThunderX systems with certain
> > memory configurations. The symptom is
> >
> > kernel BUG at mm/page_alloc.c:1848!
> >
> > This happens for some configs with 64k page size enabled. The bug
> > triggers for page zones with some pages in the zone not assigned to
> > this particular zone. In my case some pages that are marked as nomap
> > were not reassigned to the new zone of node 1, so those are still
> > assigned to node 0.
> >
> > The reason for the mis-configuration is a change in pfn_valid() which
> > reports pages marked nomap as invalid:
> >
> > 68709f45385a arm64: only consider memblocks with NOMAP cleared for linear mapping
> >
>
> These pages are owned by the firmware, which may map it with
> attributes that conflict with the attributes we use for the linear
> mapping. This means they should not be covered by the linear mapping.
>
> > This causes pages marked as nomap being no long reassigned to the new
> > zone in memmap_init_zone() by calling __init_single_pfn().
> >
>
> This sounds like the root cause of your issue. Could we not fix that instead?
Yes, this is proposal b) from my last mail that would work too: I
implemented an arm64 private early_pfn_valid() function that uses
memblock_is_memory() to setup all pages of a zone. Though, I think
this is the wrong way and thus I prefer this patch instead. I see
serveral reasons for this:
Inconsistent use of struct *page, it is initialized but never used
again.
Other archs only do a basic range check in pfn_valid(), the default
implementation just returns if the whole section is valid. As I
understand the code, if the mem range is not aligned to the section,
then there will be pfn's in the section that don't have physical mem
attached. The page is then just initialized, it's not marked reserved
nor the refcount is non-zero. It is then simply not used. This is how
no-map pages should be handled too.
I think pfn_valid() is just a quick check if the pfn's struct *page
can be used. There is a good description for this in include/linux/
mmzone.h. So there can be memory holes that have a valid pfn.
If the no-map memory needs special handling, then additional checks
need to be added to the particular code (as in ioremap.c). It's imo
wrong to (mis-)use pfn_valid for that.
Variant b) involves generic mm code to fix it for arm64, this patch is
an arm64 change only. This makes it harder to get a fix for it.
(Though maybe only a problem of patch logistics.)
>
> > Fixing this by restoring the old behavior of pfn_valid() to use
> > memblock_is_memory().
>
> This is incorrect imo. In general, pfn_valid() means ordinary memory
> covered by the linear mapping and the struct page array. Returning
> reserved ranges that the kernel should not even touch only to please
> the NUMA code seems like an inappropriate way to deal with this issue.
As said above, it is not marked as reserved, it is treated like
non-existing memory.
This has been observed for non-numa kernels too and can happen for
each zone that is only partly initialized.
I think the patch addresses your concerns. I can't see there the
kernel uses memory marked as nomap in a wrong way.
Thanks,
-Robert
>
> > Also changing users of pfn_valid() in arm64 code
> > to use memblock_is_map_memory() where necessary. This only affects
> > code in ioremap.c. The code in mmu.c still can use the new version of
> > pfn_valid().
> >
> > Should be marked stable v4.5..
> >
> > Signed-off-by: Robert Richter <rrichter@cavium.com>
> > ---
> > arch/arm64/mm/init.c | 2 +-
> > arch/arm64/mm/ioremap.c | 5 +++--
> > 2 files changed, 4 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH v3] Adding missing features of Coresight PTM components
From: Mathieu Poirier @ 2016-10-06 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <04170bc7-a947-ae75-cb14-7989a6cb4870@centralesupelec.fr>
On 6 October 2016 at 09:57, Muhammad Abdul WAHAB
<muhammadabdul.wahab@centralesupelec.fr> wrote:
> Hi,
>
>> Where is ETMCR_RETURN_STACK_EN defined? Did you send me code that
>> doesn't compile?
>
> I changed the naming in the .h file before submitting it and I forgot to
> change it in .c file. I am sorry. It is defined in coresight-etm.h.
> Here is the correct patch.
Then send me a proper V4 patch.
>From hereon I suggest you compile your code before sending patches to
the mailing list - other people won't be as lenient as I am.
> ---
> drivers/hwtracing/coresight/coresight-etm.h | 5 +++++
> drivers/hwtracing/coresight/coresight-etm3x-sysfs.c | 10 ++++++++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm.h
> b/drivers/hwtracing/coresight/coresight-etm.h
> index 4a18ee4..ad063d7 100644
> --- a/drivers/hwtracing/coresight/coresight-etm.h
> +++ b/drivers/hwtracing/coresight/coresight-etm.h
> @@ -89,11 +89,13 @@
> /* ETMCR - 0x00 */
> #define ETMCR_PWD_DWN BIT(0)
> #define ETMCR_STALL_MODE BIT(7)
> +#define ETMCR_BRANCH_BROADCAST BIT(8)
> #define ETMCR_ETM_PRG BIT(10)
> #define ETMCR_ETM_EN BIT(11)
> #define ETMCR_CYC_ACC BIT(12)
> #define ETMCR_CTXID_SIZE (BIT(14)|BIT(15))
> #define ETMCR_TIMESTAMP_EN BIT(28)
> +#define ETMCR_RETURN_STACK BIT(29)
> /* ETMCCR - 0x04 */
> #define ETMCCR_FIFOFULL BIT(23)
> /* ETMPDCR - 0x310 */
> @@ -110,8 +112,11 @@
> #define ETM_MODE_STALL BIT(2)
> #define ETM_MODE_TIMESTAMP BIT(3)
> #define ETM_MODE_CTXID BIT(4)
> +#define ETM_MODE_BBROAD BIT(5)
> +#define ETM_MODE_RET_STACK BIT(6)
> #define ETM_MODE_ALL (ETM_MODE_EXCLUDE | ETM_MODE_CYCACC | \
> ETM_MODE_STALL | ETM_MODE_TIMESTAMP | \
> + ETM_MODE_BBROAD | ETM_MODE_RET_STACK | \
> ETM_MODE_CTXID | ETM_MODE_EXCL_KERN | \
> ETM_MODE_EXCL_USER)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> index 5ea0909..a76009a 100644
> --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> @@ -164,6 +164,16 @@ static ssize_t mode_store(struct device *dev,
> else
> config->ctrl &= ~ETMCR_CTXID_SIZE;
>
> + if (config->mode & ETM_MODE_BBROAD)
> + config->ctrl |= ETMCR_BRANCH_BROADCAST;
> + else
> + config->ctrl &= ~ETMCR_BRANCH_BROADCAST;
> +
> + if (config->mode & ETM_MODE_RET_STACK)
> + config->ctrl |= ETMCR_RETURN_STACK;
> + else
> + config->ctrl &= ~ETMCR_RETURN_STACK;
> +
> if (config->mode & (ETM_MODE_EXCL_KERN | ETM_MODE_EXCL_USER))
> etm_config_trace_mode(config);
>
> --
> 1.9.1
^ permalink raw reply
* [PATCH 06/14] ASoC: Add sun8i digital audio codec
From: Icenowy Zheng @ 2016-10-06 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004161549.GO5228@lukather>
05.10.2016, 00:20, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> Hi,
>
>> ?+static const struct of_device_id sun8i_codec_of_match[] = {
>> ?+ { .compatible = "allwinner,sun8i-a33-codec" },
>> ?+ { .compatible = "allwinner,sun8i-a23-codec" },
>
> I thought that the A23 and A33 had different codecs? In that case, it
> wouldn't be a good assumption to make
Yes.
>
>> ?+ {}
>> ?+};
>> ?+MODULE_DEVICE_TABLE(of, sun8i_codec_of_match);
>> ?+
>> ?+static struct platform_driver sun8i_codec_driver = {
>> ?+ .driver = {
>> ?+ .name = "sun8i-codec",
>> ?+ .owner = THIS_MODULE,
>> ?+ .of_match_table = sun8i_codec_of_match,
>> ?+ },
>> ?+ .probe = sun8i_codec_probe,
>> ?+ .remove = sun8i_codec_remove,
>> ?+};
>> ?+module_platform_driver(sun8i_codec_driver);
>> ?+
>> ?+MODULE_DESCRIPTION("Allwinner A33 (sun8i) codec driver");
>> ?+MODULE_AUTHOR("huanxin<huanxin@reuuimllatech.com>");
>
> Those obfuscated email adresses are not really helpful :)
This kind of email addresses are kept in many places in mainline kernel.
e.g. drivers/mmc/host/sunxi-mmc.c have 'Aaron Maoye <leafy.myeh@reuuimllatech.com>'
>
> Thanks,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
> ,
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 9/9] [DO NOT MERGE] ARM: dts: sun6i: Enable 7" LCD panel on Sinlinx SinA31s
From: Chen-Yu Tsai @ 2016-10-06 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-1-wens@csie.org>
Sinlinx SinA31s comes with an optional 7" 1024x600 LCD panel with
capacitive touch panel that bolts on to the board.
Enable the display using a panel with close timings. This patch is more
of a proof of concept. The LCD panel has no markings whatsoever, and
the timings are not exactly the same, and as a result the display produces
glitch lines sometimes.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun6i-a31s-sina31s.dts | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
index 6ead2f5c847a..2d5cf8c9a12f 100644
--- a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
@@ -63,6 +63,23 @@
gpios = <&pio 7 13 GPIO_ACTIVE_HIGH>; /* PH13 */
};
};
+
+ panel: panel {
+ compatible = "avic,tm070ddh03", "simple-panel";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel_input: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_lcd>;
+ };
+ };
+ };
};
&ehci0 {
@@ -148,6 +165,19 @@
regulator-name = "vcc-gmac-phy";
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd0_rgb888_pins>;
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_lcd: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };
+};
+
&usbphy {
status = "okay";
};
--
2.9.3
^ permalink raw reply related
* [PATCH 8/9] ARM: dts: sun6i: Add A31 LCD0 RGB888 pins
From: Chen-Yu Tsai @ 2016-10-06 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-1-wens@csie.org>
The LCD0 controller on the A31 can do RGB output up to 8 bits per
channel. Add the pins for RGB888 output.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 4d2c7786b92a..2e8bf93dcfb2 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -540,6 +540,19 @@
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
+ lcd0_rgb888_pins: lcd0_rgb888 {
+ allwinner,pins = "PD0", "PD1", "PD2", "PD3",
+ "PD4", "PD5", "PD6", "PD7",
+ "PD8", "PD9", "PD10", "PD11",
+ "PD12", "PD13", "PD14", "PD15",
+ "PD16", "PD17", "PD18", "PD19",
+ "PD20", "PD21", "PD22", "PD23",
+ "PD24", "PD25", "PD26", "PD27";
+ allwinner,function = "lcd0";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
mmc0_pins_a: mmc0 at 0 {
allwinner,pins = "PF0", "PF1", "PF2",
"PF3", "PF4", "PF5";
--
2.9.3
^ permalink raw reply related
* [PATCH 7/9] ARM: dts: sun6i: Add device nodes for first display pipeline
From: Chen-Yu Tsai @ 2016-10-06 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-1-wens@csie.org>
The A31 has 2 parallel display pipelines, which can be intermixed.
However the driver currently only supports one of them.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 152 ++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/sun6i-a31s.dtsi | 8 ++
2 files changed, 160 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index c1b891e75f18..4d2c7786b92a 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -231,6 +231,11 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun6i-a31-display-engine";
+ allwinner,pipelines = <&fe0>;
+ };
+
soc at 01c00000 {
compatible = "simple-bus";
#address-cells = <1>;
@@ -246,6 +251,44 @@
#dma-cells = <1>;
};
+ tcon0: lcd-controller at 01c0c000 {
+ compatible = "allwinner,sun6i-a31-tcon";
+ reg = <0x01c0c000 0x1000>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&ccu RST_AHB1_LCD0>;
+ reset-names = "lcd";
+ clocks = <&ccu CLK_AHB1_LCD0>,
+ <&ccu CLK_LCD0_CH0>,
+ <&ccu CLK_LCD0_CH1>;
+ clock-names = "ahb",
+ "tcon-ch0",
+ "tcon-ch1";
+ clock-output-names = "tcon0-pixel-clock";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon0_in_drc0: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&drc0_out_tcon0>;
+ };
+ };
+
+ tcon0_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+
mmc0: mmc at 01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
@@ -799,6 +842,115 @@
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
+ fe0: display-frontend at 01e00000 {
+ compatible = "allwinner,sun6i-a31-display-frontend";
+ reg = <0x01e00000 0x20000>;
+ interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_AHB1_FE0>, <&ccu CLK_FE0>,
+ <&ccu CLK_DRAM_FE0>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&ccu RST_AHB1_FE0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fe0_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ fe0_out_be0: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&be0_in_fe0>;
+ };
+ };
+ };
+ };
+
+ be0: display-backend at 01e60000 {
+ compatible = "allwinner,sun6i-a31-display-backend";
+ reg = <0x01e60000 0x10000>;
+ interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_AHB1_BE0>, <&ccu CLK_BE0>,
+ <&ccu CLK_DRAM_BE0>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&ccu RST_AHB1_BE0>;
+
+ assigned-clocks = <&ccu CLK_BE0>;
+ assigned-clock-rates = <300000000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ be0_in: port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ be0_in_fe0: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&fe0_out_be0>;
+ };
+ };
+
+ be0_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ be0_out_drc0: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&drc0_in_be0>;
+ };
+ };
+ };
+ };
+
+ drc0: drc at 01e70000 {
+ compatible = "allwinner,sun6i-a31-drc";
+ reg = <0x01e70000 0x10000>;
+ interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_AHB1_DRC0>, <&ccu CLK_IEP_DRC0>,
+ <&ccu CLK_DRAM_DRC0>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&ccu RST_AHB1_DRC0>;
+
+ assigned-clocks = <&ccu CLK_IEP_DRC0>;
+ assigned-clock-rates = <300000000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ drc0_in: port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ drc0_in_be0: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&be0_out_drc0>;
+ };
+ };
+
+ drc0_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ drc0_out_tcon0: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_in_drc0>;
+ };
+ };
+ };
+ };
+
rtc: rtc at 01f00000 {
compatible = "allwinner,sun6i-a31-rtc";
reg = <0x01f00000 0x54>;
diff --git a/arch/arm/boot/dts/sun6i-a31s.dtsi b/arch/arm/boot/dts/sun6i-a31s.dtsi
index c17a32771b98..97e2c51d0aea 100644
--- a/arch/arm/boot/dts/sun6i-a31s.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31s.dtsi
@@ -48,6 +48,14 @@
#include "sun6i-a31.dtsi"
+&de {
+ compatible = "allwinner,sun6i-a31s-display-engine";
+};
+
&pio {
compatible = "allwinner,sun6i-a31s-pinctrl";
};
+
+&tcon0 {
+ compatible = "allwinner,sun6i-a31s-tcon";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 6/9] ARM: dts: sun6i: Sort pinmux setting nodes
From: Chen-Yu Tsai @ 2016-10-06 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-1-wens@csie.org>
The pinmux setting nodes for the A31 were added out of alphabetical
order. Sort them.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 82 ++++++++++++++++++++--------------------
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index ce1960453a0b..c1b891e75f18 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -434,13 +434,48 @@
#interrupt-cells = <3>;
#gpio-cells = <3>;
- uart0_pins_a: uart0 at 0 {
- allwinner,pins = "PH20", "PH21";
- allwinner,function = "uart0";
+ gmac_pins_gmii_a: gmac_gmii at 0 {
+ allwinner,pins = "PA0", "PA1", "PA2", "PA3",
+ "PA4", "PA5", "PA6", "PA7",
+ "PA8", "PA9", "PA10", "PA11",
+ "PA12", "PA13", "PA14", "PA15",
+ "PA16", "PA17", "PA18", "PA19",
+ "PA20", "PA21", "PA22", "PA23",
+ "PA24", "PA25", "PA26", "PA27";
+ allwinner,function = "gmac";
+ /*
+ * data lines in GMII mode run at 125MHz and
+ * might need a higher signal drive strength
+ */
+ allwinner,drive = <SUN4I_PINCTRL_30_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
+ gmac_pins_mii_a: gmac_mii at 0 {
+ allwinner,pins = "PA0", "PA1", "PA2", "PA3",
+ "PA8", "PA9", "PA11",
+ "PA12", "PA13", "PA14", "PA19",
+ "PA20", "PA21", "PA22", "PA23",
+ "PA24", "PA26", "PA27";
+ allwinner,function = "gmac";
allwinner,drive = <SUN4I_PINCTRL_10_MA>;
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
+ gmac_pins_rgmii_a: gmac_rgmii at 0 {
+ allwinner,pins = "PA0", "PA1", "PA2", "PA3",
+ "PA9", "PA10", "PA11",
+ "PA12", "PA13", "PA14", "PA19",
+ "PA20", "PA25", "PA26", "PA27";
+ allwinner,function = "gmac";
+ /*
+ * data lines in RGMII mode use DDR mode
+ * and need a higher signal drive strength
+ */
+ allwinner,drive = <SUN4I_PINCTRL_40_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
i2c0_pins_a: i2c0 at 0 {
allwinner,pins = "PH14", "PH15";
allwinner,function = "i2c0";
@@ -506,47 +541,12 @@
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
- gmac_pins_mii_a: gmac_mii at 0 {
- allwinner,pins = "PA0", "PA1", "PA2", "PA3",
- "PA8", "PA9", "PA11",
- "PA12", "PA13", "PA14", "PA19",
- "PA20", "PA21", "PA22", "PA23",
- "PA24", "PA26", "PA27";
- allwinner,function = "gmac";
+ uart0_pins_a: uart0 at 0 {
+ allwinner,pins = "PH20", "PH21";
+ allwinner,function = "uart0";
allwinner,drive = <SUN4I_PINCTRL_10_MA>;
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
-
- gmac_pins_gmii_a: gmac_gmii at 0 {
- allwinner,pins = "PA0", "PA1", "PA2", "PA3",
- "PA4", "PA5", "PA6", "PA7",
- "PA8", "PA9", "PA10", "PA11",
- "PA12", "PA13", "PA14", "PA15",
- "PA16", "PA17", "PA18", "PA19",
- "PA20", "PA21", "PA22", "PA23",
- "PA24", "PA25", "PA26", "PA27";
- allwinner,function = "gmac";
- /*
- * data lines in GMII mode run at 125MHz and
- * might need a higher signal drive strength
- */
- allwinner,drive = <SUN4I_PINCTRL_30_MA>;
- allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
- };
-
- gmac_pins_rgmii_a: gmac_rgmii at 0 {
- allwinner,pins = "PA0", "PA1", "PA2", "PA3",
- "PA9", "PA10", "PA11",
- "PA12", "PA13", "PA14", "PA19",
- "PA20", "PA25", "PA26", "PA27";
- allwinner,function = "gmac";
- /*
- * data lines in RGMII mode use DDR mode
- * and need a higher signal drive strength
- */
- allwinner,drive = <SUN4I_PINCTRL_40_MA>;
- allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
- };
};
timer at 01c20c00 {
--
2.9.3
^ permalink raw reply related
* [PATCH 5/9] drm/sun4i: Add compatible strings for A31/A31s display pipelines
From: Chen-Yu Tsai @ 2016-10-06 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-1-wens@csie.org>
The A31's display pipeline has 2 frontends, 2 backends, and 2 TCONs. It
also has new display enhancement blocks, such as the DRC (Dynamic Range
Controller), the DEU (Display Enhancement Unit), and the CMU (Color
Management Unit). It supports HDMI, MIPI DSI, and 2 LCD/LVDS channels.
The A31s display pipeline is almost the same, just without MIPI DSI.
Only the TCON seems to be different, due to the missing mux for MIPI
DSI.
Add compatible strings for both of them.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 ++++
drivers/gpu/drm/sun4i/sun4i_backend.c | 1 +
drivers/gpu/drm/sun4i/sun4i_drv.c | 3 +++
3 files changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 15fdca8909f2..b82c00449468 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -91,6 +91,7 @@ system.
Required properties:
- compatible: value must be one of:
* allwinner,sun5i-a13-display-backend
+ * allwinner,sun6i-a31-display-backend
* allwinner,sun8i-a33-display-backend
- reg: base address and size of the memory-mapped region.
- clocks: phandles to the clocks feeding the frontend and backend
@@ -121,6 +122,7 @@ deinterlacing and color space conversion.
Required properties:
- compatible: value must be one of:
* allwinner,sun5i-a13-display-frontend
+ * allwinner,sun6i-a31-display-frontend
* allwinner,sun8i-a33-display-frontend
- reg: base address and size of the memory-mapped region.
- interrupts: interrupt associated to this IP
@@ -146,6 +148,8 @@ extra node.
Required properties:
- compatible: value must be one of:
* allwinner,sun5i-a13-display-engine
+ * allwinner,sun6i-a31-display-engine
+ * allwinner,sun6i-a31s-display-engine
* allwinner,sun8i-a33-display-engine
- allwinner,pipelines: list of phandle to the display engine
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 32c0584e3c35..6e6c59a661b6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -408,6 +408,7 @@ static int sun4i_backend_remove(struct platform_device *pdev)
static const struct of_device_id sun4i_backend_of_table[] = {
{ .compatible = "allwinner,sun5i-a13-display-backend" },
+ { .compatible = "allwinner,sun6i-a31-display-backend" },
{ .compatible = "allwinner,sun8i-a33-display-backend" },
{ }
};
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 35af3728c4ee..480a709cc324 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -200,6 +200,7 @@ static const struct component_master_ops sun4i_drv_master_ops = {
static bool sun4i_drv_node_is_frontend(struct device_node *node)
{
return of_device_is_compatible(node, "allwinner,sun5i-a13-display-frontend") ||
+ of_device_is_compatible(node, "allwinner,sun6i-a31-display-frontend") ||
of_device_is_compatible(node, "allwinner,sun8i-a33-display-frontend");
}
@@ -323,6 +324,8 @@ static int sun4i_drv_remove(struct platform_device *pdev)
static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun5i-a13-display-engine" },
+ { .compatible = "allwinner,sun6i-a31-display-engine" },
+ { .compatible = "allwinner,sun6i-a31s-display-engine" },
{ .compatible = "allwinner,sun8i-a33-display-engine" },
{ }
};
--
2.9.3
^ permalink raw reply related
* [PATCH 4/9] drm/sun4i: Add compatible string for A31/A31s TCON (timing controller)
From: Chen-Yu Tsai @ 2016-10-06 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-1-wens@csie.org>
The A31 TCON has mux controls for how TCON outputs are routed to the
HDMI and MIPI DSI blocks.
Since the A31s does not have MIPI DSI, it only has a mux for the HDMI
controller input.
This patch only adds support for the compatible strings. Actual support
for the mux controls should be added with HDMI and MIPI DSI support.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
.../devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 +++-
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
drivers/gpu/drm/sun4i/sun4i_tcon.c | 17 +++++++++++++++++
drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 ++
4 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 5368961cd727..15fdca8909f2 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -28,6 +28,8 @@ The TCON acts as a timing controller for RGB, LVDS and TV interfaces.
Required properties:
- compatible: value must be either:
* allwinner,sun5i-a13-tcon
+ * allwinner,sun6i-a31-tcon
+ * allwinner,sun6i-a31s-tcon
* allwinner,sun8i-a33-tcon
- reg: base address and size of memory-mapped region
- interrupts: interrupt associated to this IP
@@ -50,7 +52,7 @@ Required properties:
second the block connected to the TCON channel 1 (usually the TV
encoder)
-On the A13, there is one more clock required:
+On SoCs other than the A33, there is one more clock required:
- 'tcon-ch1': The clock driving the TCON channel 1
DRC
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index c4d03c1b6db8..35af3728c4ee 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -206,6 +206,8 @@ static bool sun4i_drv_node_is_frontend(struct device_node *node)
static bool sun4i_drv_node_is_tcon(struct device_node *node)
{
return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon") ||
+ of_device_is_compatible(node, "allwinner,sun6i-a31-tcon") ||
+ of_device_is_compatible(node, "allwinner,sun6i-a31s-tcon") ||
of_device_is_compatible(node, "allwinner,sun8i-a33-tcon");
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 5a5407193753..745708f85ab6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -590,6 +590,21 @@ const struct sun4i_tcon_quirks sun5i_a13_quirks = {
.has_dma_src = true,
};
+const struct sun4i_tcon_quirks sun6i_a31_quirks = {
+ .max_clock = 200000,
+ .has_channel_1 = true,
+ .has_dma_src = true,
+ .has_hdmi_mux = true,
+ .has_dsi_mux = true,
+};
+
+const struct sun4i_tcon_quirks sun6i_a31s_quirks = {
+ .max_clock = 200000,
+ .has_channel_1 = true,
+ .has_dma_src = true,
+ .has_hdmi_mux = true,
+};
+
const struct sun4i_tcon_quirks sun8i_a33_quirks = {
.max_clock = 200000,
/* nothing is supported */
@@ -597,6 +612,8 @@ const struct sun4i_tcon_quirks sun8i_a33_quirks = {
static const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun5i-a13-tcon", .data = &sun5i_a13_quirks },
+ { .compatible = "allwinner,sun6i-a31-tcon", .data = &sun6i_a31_quirks },
+ { .compatible = "allwinner,sun6i-a31s-tcon", .data = &sun6i_a31s_quirks },
{ .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks },
{ }
};
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index 972ca2b7c8c2..deebb97e9c3f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -148,6 +148,8 @@ struct sun4i_tcon_quirks {
bool has_channel_1; /* a33 does not have channel 1 */
bool has_bypass_src; /* has separate input bypassing CEU */
bool has_dma_src; /* has DMA input */
+ bool has_hdmi_mux; /* HDMI source selector */
+ bool has_dsi_mux; /* MIPI DSI source selector */
};
struct sun4i_tcon {
--
2.9.3
^ permalink raw reply related
* [PATCH 3/9] drm/sun4i: Put dotclock range into tcon quirks and check against them
From: Chen-Yu Tsai @ 2016-10-06 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-1-wens@csie.org>
In commit bb43d40d7c83 ("drm/sun4i: rgb: Validate the clock rate") the
driver was rounding the requested clock rate and then checking the
result against the original requested rate.
This does not work well for a number of reasons:
- The pixel clock does not have enough resolution to be able to
provide all sub-MHz clock rates. This makes it filter out most modes
found in simple-panel.
- When first introduced, the main limiting factors were the video PLL
clock range (27 ~ 381 MHz) and the lowest divider (6). On sun6i and
later, the valid PLL clock range is extended to 30 ~ 600 MHz. The
PLL's multiplier and divider can make it go much higher out of range,
but the clock driver currently has no checks for it.
Since the limits are well known, we can hard code the range into the
tcon driver, and check against them. And we really only care about the
upper limit, which affects the highest resolutions we can support.
Fixes: bb43d40d7c83 ("drm/sun4i: rgb: Validate the clock rate")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 8 +-------
drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 ++
drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 +
3 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 8b520d9f5bd9..edbb42ead1f1 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -60,8 +60,6 @@ static int sun4i_rgb_mode_valid(struct drm_connector *connector,
struct sun4i_tcon *tcon = drv->tcon;
u32 hsync = mode->hsync_end - mode->hsync_start;
u32 vsync = mode->vsync_end - mode->vsync_start;
- unsigned long rate = mode->clock * 1000;
- long rounded_rate;
DRM_DEBUG_DRIVER("Validating modes...\n");
@@ -93,11 +91,7 @@ static int sun4i_rgb_mode_valid(struct drm_connector *connector,
DRM_DEBUG_DRIVER("Vertical parameters OK\n");
- rounded_rate = clk_round_rate(tcon->dclk, rate);
- if (rounded_rate < rate)
- return MODE_CLOCK_LOW;
-
- if (rounded_rate > rate)
+ if (mode->clock > tcon->quirks->max_clock)
return MODE_CLOCK_HIGH;
DRM_DEBUG_DRIVER("Clock rate OK\n");
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c6c1c7ce94a1..5a5407193753 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -583,6 +583,7 @@ static int sun4i_tcon_remove(struct platform_device *pdev)
}
const struct sun4i_tcon_quirks sun5i_a13_quirks = {
+ .max_clock = 63500,
.is_sun5i = true,
.has_channel_1 = true,
.has_bypass_src = true,
@@ -590,6 +591,7 @@ const struct sun4i_tcon_quirks sun5i_a13_quirks = {
};
const struct sun4i_tcon_quirks sun8i_a33_quirks = {
+ .max_clock = 200000,
/* nothing is supported */
};
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index 96c4f15c6922..972ca2b7c8c2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -143,6 +143,7 @@
#define SUN4I_TCON_MAX_CHANNELS 2
struct sun4i_tcon_quirks {
+ int max_clock; /* Highest possible dotclock in kHz */
bool is_sun5i; /* sun5i has undocumented mux */
bool has_channel_1; /* a33 does not have channel 1 */
bool has_bypass_src; /* has separate input bypassing CEU */
--
2.9.3
^ permalink raw reply related
* [PATCH 2/9] drm/sun4i: tcon: Move SoC specific quirks to a DT matched data structure
From: Chen-Yu Tsai @ 2016-10-06 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-1-wens@csie.org>
We already have some differences between the 2 supported SoCs.
More will be added as we support other SoCs. To avoid bloating
the probe function with even more conditionals, move the quirks
to a separate data structure that's tied to the compatible string.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 35 ++++++++++++++++++++---------------
drivers/gpu/drm/sun4i/sun4i_tcon.h | 13 +++++++++----
2 files changed, 29 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index cadacb517f95..c6c1c7ce94a1 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -20,6 +20,7 @@
#include <linux/component.h>
#include <linux/ioport.h>
#include <linux/of_address.h>
+#include <linux/of_device.h>
#include <linux/of_graph.h>
#include <linux/of_irq.h>
#include <linux/regmap.h>
@@ -62,7 +63,7 @@ void sun4i_tcon_channel_disable(struct sun4i_tcon *tcon, int channel)
return;
}
- WARN_ON(!tcon->has_channel_1);
+ WARN_ON(!tcon->quirks->has_channel_1);
regmap_update_bits(tcon->regs, SUN4I_TCON1_CTL_REG,
SUN4I_TCON1_CTL_TCON_ENABLE, 0);
clk_disable_unprepare(tcon->sclk1);
@@ -80,7 +81,7 @@ void sun4i_tcon_channel_enable(struct sun4i_tcon *tcon, int channel)
return;
}
- WARN_ON(!tcon->has_channel_1);
+ WARN_ON(!tcon->quirks->has_channel_1);
regmap_update_bits(tcon->regs, SUN4I_TCON1_CTL_REG,
SUN4I_TCON1_CTL_TCON_ENABLE,
SUN4I_TCON1_CTL_TCON_ENABLE);
@@ -202,7 +203,7 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
u8 clk_delay;
u32 val;
- WARN_ON(!tcon->has_channel_1);
+ WARN_ON(!tcon->quirks->has_channel_1);
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 1);
@@ -266,7 +267,7 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
/*
* FIXME: Undocumented bits
*/
- if (tcon->has_mux)
+ if (tcon->quirks->is_sun5i)
regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
}
EXPORT_SYMBOL(sun4i_tcon1_mode_set);
@@ -327,7 +328,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
return PTR_ERR(tcon->sclk0);
}
- if (tcon->has_channel_1) {
+ if (tcon->quirks->has_channel_1) {
tcon->sclk1 = devm_clk_get(dev, "tcon-ch1");
if (IS_ERR(tcon->sclk1)) {
dev_err(dev, "Couldn't get the TCON channel 1 clock\n");
@@ -487,14 +488,7 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
drv->tcon = tcon;
tcon->drm = drm;
tcon->dev = dev;
-
- if (of_device_is_compatible(dev->of_node, "allwinner,sun5i-a13-tcon")) {
- tcon->has_mux = true;
- tcon->has_channel_1 = true;
- } else {
- tcon->has_mux = false;
- tcon->has_channel_1 = false;
- }
+ tcon->quirks = of_device_get_match_data(dev);
tcon->lcd_rst = devm_reset_control_get(dev, "lcd");
if (IS_ERR(tcon->lcd_rst)) {
@@ -588,9 +582,20 @@ static int sun4i_tcon_remove(struct platform_device *pdev)
return 0;
}
+const struct sun4i_tcon_quirks sun5i_a13_quirks = {
+ .is_sun5i = true,
+ .has_channel_1 = true,
+ .has_bypass_src = true,
+ .has_dma_src = true,
+};
+
+const struct sun4i_tcon_quirks sun8i_a33_quirks = {
+ /* nothing is supported */
+};
+
static const struct of_device_id sun4i_tcon_of_table[] = {
- { .compatible = "allwinner,sun5i-a13-tcon" },
- { .compatible = "allwinner,sun8i-a33-tcon" },
+ { .compatible = "allwinner,sun5i-a13-tcon", .data = &sun5i_a13_quirks },
+ { .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks },
{ }
};
MODULE_DEVICE_TABLE(of, sun4i_tcon_of_table);
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index 12bd48925f4d..96c4f15c6922 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -142,6 +142,13 @@
#define SUN4I_TCON_MAX_CHANNELS 2
+struct sun4i_tcon_quirks {
+ bool is_sun5i; /* sun5i has undocumented mux */
+ bool has_channel_1; /* a33 does not have channel 1 */
+ bool has_bypass_src; /* has separate input bypassing CEU */
+ bool has_dma_src; /* has DMA input */
+};
+
struct sun4i_tcon {
struct device *dev;
struct drm_device *drm;
@@ -160,12 +167,10 @@ struct sun4i_tcon {
/* Reset control */
struct reset_control *lcd_rst;
- /* Platform adjustments */
- bool has_mux;
-
struct drm_panel *panel;
- bool has_channel_1;
+ /* Platform adjustments */
+ const struct sun4i_tcon_quirks *quirks;
};
struct drm_bridge *sun4i_tcon_find_bridge(struct device_node *node);
--
2.9.3
^ permalink raw reply related
* [PATCH 1/9] drm/sun4i: sun6i-drc: Support DRC on A31 and A31s
From: Chen-Yu Tsai @ 2016-10-06 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-1-wens@csie.org>
The A31 and A31s also have the DRC as part of the display pipeline.
As we know virtually nothing about them, just add compatible strings
for both SoCs to the stub driver.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++
drivers/gpu/drm/sun4i/sun6i_drc.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index b95696d748c7..5368961cd727 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -64,6 +64,8 @@ adaptive backlight control.
Required properties:
- compatible: value must be one of:
+ * allwinner,sun6i-a31-drc
+ * allwinner,sun6i-a31s-drc
* allwinner,sun8i-a33-drc
- reg: base address and size of the memory-mapped region.
- interrupts: interrupt associated to this IP
diff --git a/drivers/gpu/drm/sun4i/sun6i_drc.c b/drivers/gpu/drm/sun4i/sun6i_drc.c
index bf6d846d8132..6ef707c5a719 100644
--- a/drivers/gpu/drm/sun4i/sun6i_drc.c
+++ b/drivers/gpu/drm/sun4i/sun6i_drc.c
@@ -98,6 +98,8 @@ static int sun6i_drc_remove(struct platform_device *pdev)
}
static const struct of_device_id sun6i_drc_of_table[] = {
+ { .compatible = "allwinner,sun6i-a31-drc" },
+ { .compatible = "allwinner,sun6i-a31s-drc" },
{ .compatible = "allwinner,sun8i-a33-drc" },
{ }
};
--
2.9.3
^ permalink raw reply related
* [PATCH 0/9] drm/sun4i: Support first display pipeline on sun6i
From: Chen-Yu Tsai @ 2016-10-06 16:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
This series adds support for the first display pipeline found on the
A31 and A31s SoCs, with output through the RGB LCD interface.
This has been tested on the Sinlinx SinA31s development board, with
its included 7" LCD panel (see last patch), and the Merrii Hummingbird
A31 development board, with its RGB-VGA bridge using Maxime's dumb VGA
bridge patches. The Hummingbird A31 patches will be sent once Maxime's
patches are merged.
The last patch is only included for completeness. The LCD panel is
not exactly supported, and Maxime's previous attempt to add it was
postponed pending discussion.
Regards
ChenYu
Chen-Yu Tsai (9):
drm/sun4i: sun6i-drc: Support DRC on A31 and A31s
drm/sun4i: tcon: Move SoC specific quirks to a DT matched data
structure
drm/sun4i: Put dotclock range into tcon quirks and check against them
drm/sun4i: Add compatible string for A31/A31s TCON (timing controller)
drm/sun4i: Add compatible strings for A31/A31s display pipelines
ARM: dts: sun6i: Sort pinmux setting nodes
ARM: dts: sun6i: Add device nodes for first display pipeline
ARM: dts: sun6i: Add A31 LCD0 RGB888 pins
[DO NOT MERGE] ARM: dts: sun6i: Enable 7" LCD panel on Sinlinx SinA31s
.../bindings/display/sunxi/sun4i-drm.txt | 10 +-
arch/arm/boot/dts/sun6i-a31.dtsi | 247 +++++++++++++++++----
arch/arm/boot/dts/sun6i-a31s-sina31s.dts | 30 +++
arch/arm/boot/dts/sun6i-a31s.dtsi | 8 +
drivers/gpu/drm/sun4i/sun4i_backend.c | 1 +
drivers/gpu/drm/sun4i/sun4i_drv.c | 5 +
drivers/gpu/drm/sun4i/sun4i_rgb.c | 8 +-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 54 +++--
drivers/gpu/drm/sun4i/sun4i_tcon.h | 16 +-
drivers/gpu/drm/sun4i/sun6i_drc.c | 2 +
10 files changed, 313 insertions(+), 68 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH] indentation fix (extra space removed)
From: Mathieu Poirier @ 2016-10-06 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0b897b22-fc32-c97e-b678-1c0040782a62@centralesupelec.fr>
On 5 October 2016 at 05:41, Muhammad Abdul WAHAB
<muhammadabdul.wahab@centralesupelec.fr> wrote:
> An extra space is removed.
>
> Signed-off-by: Muhammad Abdul Wahab <muhammadabdul.wahab@centralesupelec.fr>
> ---
> drivers/hwtracing/coresight/coresight-etm3x-sysfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> index e9b0719..5ea0909 100644
> --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> @@ -146,7 +146,7 @@ static ssize_t mode_store(struct device *dev,
> goto err_unlock;
> }
> config->ctrl |= ETMCR_STALL_MODE;
> - } else
> + } else
> config->ctrl &= ~ETMCR_STALL_MODE;
>
> if (config->mode & ETM_MODE_TIMESTAMP) {
Applied, but prepended "coresight: etm3x:" to the original title.
Thanks,
Mathieu
> --
> 1.9.1
^ permalink raw reply
* [PATCH v3] Adding missing features of Coresight PTM components
From: Muhammad Abdul WAHAB @ 2016-10-06 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkyPTtiGsfKg13ZY2pgCC3rh+MfirMwTrLG1=TZ5gUJqzA@mail.gmail.com>
Hi,
> Where is ETMCR_RETURN_STACK_EN defined? Did you send me code that
> doesn't compile?
I changed the naming in the .h file before submitting it and I forgot to
change it in .c file. I am sorry. It is defined in coresight-etm.h.
Here is the correct patch.
---
drivers/hwtracing/coresight/coresight-etm.h | 5 +++++
drivers/hwtracing/coresight/coresight-etm3x-sysfs.c | 10 ++++++++++
2 files changed, 15 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-etm.h
b/drivers/hwtracing/coresight/coresight-etm.h
index 4a18ee4..ad063d7 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -89,11 +89,13 @@
/* ETMCR - 0x00 */
#define ETMCR_PWD_DWN BIT(0)
#define ETMCR_STALL_MODE BIT(7)
+#define ETMCR_BRANCH_BROADCAST BIT(8)
#define ETMCR_ETM_PRG BIT(10)
#define ETMCR_ETM_EN BIT(11)
#define ETMCR_CYC_ACC BIT(12)
#define ETMCR_CTXID_SIZE (BIT(14)|BIT(15))
#define ETMCR_TIMESTAMP_EN BIT(28)
+#define ETMCR_RETURN_STACK BIT(29)
/* ETMCCR - 0x04 */
#define ETMCCR_FIFOFULL BIT(23)
/* ETMPDCR - 0x310 */
@@ -110,8 +112,11 @@
#define ETM_MODE_STALL BIT(2)
#define ETM_MODE_TIMESTAMP BIT(3)
#define ETM_MODE_CTXID BIT(4)
+#define ETM_MODE_BBROAD BIT(5)
+#define ETM_MODE_RET_STACK BIT(6)
#define ETM_MODE_ALL (ETM_MODE_EXCLUDE | ETM_MODE_CYCACC | \
ETM_MODE_STALL | ETM_MODE_TIMESTAMP | \
+ ETM_MODE_BBROAD | ETM_MODE_RET_STACK | \
ETM_MODE_CTXID | ETM_MODE_EXCL_KERN | \
ETM_MODE_EXCL_USER)
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
index 5ea0909..a76009a 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
@@ -164,6 +164,16 @@ static ssize_t mode_store(struct device *dev,
else
config->ctrl &= ~ETMCR_CTXID_SIZE;
+ if (config->mode & ETM_MODE_BBROAD)
+ config->ctrl |= ETMCR_BRANCH_BROADCAST;
+ else
+ config->ctrl &= ~ETMCR_BRANCH_BROADCAST;
+
+ if (config->mode & ETM_MODE_RET_STACK)
+ config->ctrl |= ETMCR_RETURN_STACK;
+ else
+ config->ctrl &= ~ETMCR_RETURN_STACK;
+
if (config->mode & (ETM_MODE_EXCL_KERN | ETM_MODE_EXCL_USER))
etm_config_trace_mode(config);
--
1.9.1
^ permalink raw reply related
* [PATCH 6/8] PM / Domains: Abstract genpd locking
From: Lina Iyer @ 2016-10-06 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFrzPbr_njosTxO9y0V3KKG0stfhA3XejmQk_3RJMr3=Tg@mail.gmail.com>
On Thu, Oct 06 2016 at 04:56 -0600, Ulf Hansson wrote:
>On 5 October 2016 at 22:31, Lina Iyer <lina.iyer@linaro.org> wrote:
>> Abstract genpd lock/unlock calls, in preparation for domain specific
>> locks added in the following patches.
>>
>> Cc: Kevin Hilman <khilman@kernel.org>
>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> ---
>> drivers/base/power/domain.c | 121 +++++++++++++++++++++++++++++---------------
>> include/linux/pm_domain.h | 5 +-
>> 2 files changed, 85 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index 52fcdb2..82e6a33 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -39,6 +39,46 @@
>> static LIST_HEAD(gpd_list);
>> static DEFINE_MUTEX(gpd_list_lock);
>>
>> +struct genpd_lock_fns {
>
>May I suggest you to rename the struct to "genpd_lock_ops"?
>
>I think "*_ops" is in general what we use in the kernel for callbacks
>and functions pointers like these.
>
OK.
Thanks,
Lina
>> + void (*lock)(struct generic_pm_domain *genpd);
>> + void (*lock_nested)(struct generic_pm_domain *genpd, int depth);
>> + int (*lock_interruptible)(struct generic_pm_domain *genpd);
>> + void (*unlock)(struct generic_pm_domain *genpd);
>> +};
>> +
>
>[...]
>
>Otherwise this looks good to me!
>
>Kind regards
>Uffe
^ permalink raw reply
* [PATCH 5/8] dt/bindings: Update binding for PM domain idle states
From: Lina Iyer @ 2016-10-06 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUKbJ1Mt3viEkbCDmZGHQjGi_E=bxEBSHOB1MMY+qfSYQ@mail.gmail.com>
On Thu, Oct 06 2016 at 02:09 -0600, Geert Uytterhoeven wrote:
>On Thu, Oct 6, 2016 at 10:06 AM, Geert Uytterhoeven
><geert@linux-m68k.org> wrote:
>> On Wed, Oct 5, 2016 at 10:31 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
>>> Update DT bindings to describe idle states of PM domains.
>>>
>>> This patch is based on the original patch by Marc Titinger.
>>>
>>> Cc: <devicetree@vger.kernel.org>
>>> Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>>> Acked-by: Rob Herring <robh@kernel.org>
>>> ---
>>> .../devicetree/bindings/power/power_domain.txt | 36 ++++++++++++++++++++++
>>> 1 file changed, 36 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
>>> index 025b5e7..a043315 100644
>>> --- a/Documentation/devicetree/bindings/power/power_domain.txt
>>> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
>>> @@ -29,6 +29,10 @@ Optional properties:
>>> specified by this binding. More details about power domain specifier are
>>> available in the next section.
>>>
>>> +- domain-idle-states : A phandle of an idle-state that shall be soaked into a
>>> + generic domain power state. The idle state definitions are
>>> + compatible with arm,idle-state specified in [1].
>>> +
>>> Example:
>>>
>>> power: power-controller at 12340000 {
>>> @@ -59,6 +63,36 @@ The nodes above define two power controllers: 'parent' and 'child'.
>>> Domains created by the 'child' power controller are subdomains of '0' power
>>> domain provided by the 'parent' power controller.
>>>
>>> +Example 3:
>>> + parent: power-controller at 12340000 {
>>
>> With W=1, this is gonna trigger:
>>
>> Warning (unit_address_vs_reg): Node foo has a unit name, but no reg property
>>
>> Yes, there are pre-existing users in this file.
>
>Scrap this... switching desktops causes loss of position...
>
>>> + compatible = "foo,power-controller";
>>> + reg = <0x12340000 0x1000>;
>>> + #power-domain-cells = <1>;
>>> + domain-idle-states = <&DOMAIN_RET, &DOMAIN_PWR_DN>;
>>> + };
>
>+ DOMAIN_RET: state at 0 {
>+ compatible = "arm,idle-state";
>+ entry-latency-us = <1000>;
>+ exit-latency-us = <2000>;
>+ min-residency-us = <10000>;
>
>This one is gonna trigger
>
>Warning (unit_address_vs_reg): Node foo has a unit name, but no reg property
>
>+ };
>
Its just an example, Will fix the example.
>Gr{oetje,eeting}s,
>
> Geert
>
>--
>Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
>In personal conversations with technical people, I call myself a hacker. But
>when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* [PATCH 4/8] PM / Domains: Add fwnode provider to genpd states
From: Lina Iyer @ 2016-10-06 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFrsLjchkbkqg4O=RfKamO+EgOhZtzw1-_3e5QphLON0XQ@mail.gmail.com>
On Thu, Oct 06 2016 at 06:01 -0600, Ulf Hansson wrote:
>On 5 October 2016 at 22:31, Lina Iyer <lina.iyer@linaro.org> wrote:
>> Save the fwnode for the genpd state in the state node. PM Domain clients
>> may use the fwnode to read in the rest of the properties for the domain
>> state.
>
>What is the "rest"? I assume you mean the non PM domain generic parts,
>but perhaps you could elaborate a bit on that?
>
>>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> ---
>> drivers/base/power/domain.c | 1 +
>> include/linux/pm_domain.h | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index 368a5b8..52fcdb2 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -1937,6 +1937,7 @@ static int read_genpd_state(struct genpd_power_state *genpd_state,
>> latency = entry_latency + exit_latency;
>> genpd_state->power_on_latency_ns = 1000 * latency;
>> genpd_state->power_off_latency_ns = 1000 * entry_latency;
>> + genpd_state->provider = &state_node->fwnode;
>>
>> return 0;
>> }
>> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
>> index 4c9152d..eacfa71 100644
>> --- a/include/linux/pm_domain.h
>> +++ b/include/linux/pm_domain.h
>> @@ -39,6 +39,7 @@ struct genpd_power_state {
>> s64 power_off_latency_ns;
>> s64 power_on_latency_ns;
>> s64 residency_ns;
>> + struct fwnode_handle *provider;
>
>I don't think this is a provider, but just a fwnode_handle to a
>domain-idle-state. Therefore, I would suggest you to rename it to
>"fwnode" instead.
>
OK.
>> };
>>
>> struct generic_pm_domain {
>> --
>> 2.7.4
>>
>
>Kind regards
>Uffe
^ 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