* [linux-sunxi] [PATCH 1/3] ARM: sunxi: add support for H2+ SoC
From: Hans de Goede @ 2016-11-13 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111164654.15273-1-icenowy@aosc.xyz>
Hi,
On 11-11-16 17:46, Icenowy Zheng wrote:
> Allwinner H2+ is a quad-core Cortex-A7 SoC.
>
> It is very like H3, that they share the same SoC ID (0x1680), and H3
> memory maps as well as drivers works well on the SoC.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
I agree that given that the chip-id is 1680 for both
this does seem to be the same die as the H3, and given
that we do not have any datasheets, I agree that just
treating the H2+ as a H3 is best for now, we can always
change h2.dtsi to actually differentiate things later.
This entire series LGTM and is:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
> ---
> Documentation/arm/sunxi/README | 4 ++++
> Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
> arch/arm/mach-sunxi/sunxi.c | 1 +
> 3 files changed, 6 insertions(+)
>
> diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
> index cd02433..1fe4d99c 100644
> --- a/Documentation/arm/sunxi/README
> +++ b/Documentation/arm/sunxi/README
> @@ -63,6 +63,10 @@ SunXi family
> + User Manual
> http://dl.linux-sunxi.org/A33/A33%20user%20manual%20release%201.1.pdf
>
> + - Allwinner H2+ (sun8i)
> + + No document available now, but is known to be working properly with
> + H3 drivers and memory map.
> +
> - Allwinner H3 (sun8i)
> + Datasheet
> http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
> index 3975d0a..0c0f277 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -13,5 +13,6 @@ using one of the following compatible strings:
> allwinner,sun8i-a33
> allwinner,sun8i-a83t
> allwinner,sun8i-h3
> + allwinner,sun8i-h2plus
> allwinner,sun9i-a80
> nextthing,gr8
> diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> index 2e2bde2..3647ad7 100644
> --- a/arch/arm/mach-sunxi/sunxi.c
> +++ b/arch/arm/mach-sunxi/sunxi.c
> @@ -63,6 +63,7 @@ static const char * const sun8i_board_dt_compat[] = {
> "allwinner,sun8i-a23",
> "allwinner,sun8i-a33",
> "allwinner,sun8i-a83t",
> + "allwinner,sun8i-h2plus",
> "allwinner,sun8i-h3",
> NULL,
> };
>
^ permalink raw reply
* [PATCH] input: bma150: Only claim to support the bma180 if the separate iio bma180 driver is not build
From: Hans de Goede @ 2016-11-13 18:34 UTC (permalink / raw)
To: linux-arm-kernel
commit ef3714fdbc8d ("Input: bma150 - extend chip detection for bma180"),
adds bma180 chip-ids to the input bma150 driver, assuming that they are
100% compatible, but the bma180 is not compatible with the bma150 at all,
it has 14 bits resolution instead of 10, and it has quite different
control registers too.
Treating the bma180 as a bma150 wrt its data registers will just result
in throwing away the lowest 4 bits, which is not too bad. But the ctrl
registers are a different story. Things happen to just work but supporting
that certainly does not make treating the bma180 the same as the bma150
right.
Since some setups depend on the evdev interface the bma150 driver offers
on top of the bma180, we cannot simply remove the bma180 ids.
So this commit only removes the bma180 id when the bma180 iio driver,
which does treat the bma180 properly, is enabled.
Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/input/misc/bma150.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c
index b0d4453..9fa1c9a 100644
--- a/drivers/input/misc/bma150.c
+++ b/drivers/input/misc/bma150.c
@@ -539,7 +539,11 @@ static int bma150_probe(struct i2c_client *client,
}
chip_id = i2c_smbus_read_byte_data(client, BMA150_CHIP_ID_REG);
- if (chip_id != BMA150_CHIP_ID && chip_id != BMA180_CHIP_ID) {
+ if (chip_id != BMA150_CHIP_ID
+#ifndef CONFIG_BMA180
+ && chip_id != BMA180_CHIP_ID
+#endif
+ ) {
dev_err(&client->dev, "BMA150 chip id error: %d\n", chip_id);
return -EINVAL;
}
@@ -643,7 +647,9 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL);
static const struct i2c_device_id bma150_id[] = {
{ "bma150", 0 },
+#ifndef CONFIG_BMA180
{ "bma180", 0 },
+#endif
{ "smb380", 0 },
{ "bma023", 0 },
{ }
--
2.9.3
^ permalink raw reply related
* [PATCH 2/2] ARM: bcm2835: Add names for the Raspberry Pi Zero GPIO lines
From: Stefan Wahren @ 2016-11-13 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479060729-25769-1-git-send-email-stefan.wahren@i2se.com>
This adds the GPIO names for the Raspberry Pi Zero. Since there are no
schematics for the RPi Zero use the same as the Model A+.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
arch/arm/boot/dts/bcm2835-rpi-a-plus-gpio.dtsi | 75 +++++++++++++++++++++++
arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 76 +-----------------------
arch/arm/boot/dts/bcm2835-rpi-zero.dts | 11 +---
3 files changed, 77 insertions(+), 85 deletions(-)
create mode 100644 arch/arm/boot/dts/bcm2835-rpi-a-plus-gpio.dtsi
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus-gpio.dtsi b/arch/arm/boot/dts/bcm2835-rpi-a-plus-gpio.dtsi
new file mode 100644
index 0000000..741d64d
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus-gpio.dtsi
@@ -0,0 +1,75 @@
+&gpio {
+ /*
+ * This is based on the unreleased schematic for the Model A+.
+ *
+ * Legend:
+ * "NC" = not connected (no rail from the SoC)
+ * "FOO" = GPIO line named "FOO" on the schematic
+ * "FOO_N" = GPIO line named "FOO" on schematic, active low
+ */
+ gpio-line-names = "SDA0",
+ "SCL0",
+ "SDA1",
+ "SCL1",
+ "GPIO_GCLK",
+ "GPIO5",
+ "GPIO6",
+ "SPI_CE1_N",
+ "SPI_CE0_N",
+ "SPI_MISO",
+ "SPI_MOSI",
+ "SPI_SCLK",
+ "GPIO12",
+ "GPIO13",
+ /* Serial port */
+ "TXD0",
+ "RXD0",
+ "GPIO16",
+ "GPIO17",
+ "GPIO18",
+ "GPIO19",
+ "GPIO20",
+ "GPIO21",
+ "GPIO22",
+ "GPIO23",
+ "GPIO24",
+ "GPIO25",
+ "GPIO26",
+ "GPIO27",
+ "SDA0",
+ "SCL0",
+ "NC", /* GPIO30 */
+ "NC", /* GPIO31 */
+ "CAM_GPIO1", /* GPIO32 */
+ "NC", /* GPIO33 */
+ "NC", /* GPIO34 */
+ "PWR_LOW_N", /* GPIO35 */
+ "NC", /* GPIO36 */
+ "NC", /* GPIO37 */
+ "USB_LIMIT", /* GPIO38 */
+ "NC", /* GPIO39 */
+ "PWM0_OUT", /* GPIO40 */
+ "CAM_GPIO0", /* GPIO41 */
+ "NC", /* GPIO42 */
+ "NC", /* GPIO43 */
+ "NC", /* GPIO44 */
+ "PWM1_OUT", /* GPIO45 */
+ "HDMI_HPD_N",
+ "STATUS_LED",
+ /* Used by SD Card */
+ "SD_CLK_R",
+ "SD_CMD_R",
+ "SD_DATA0_R",
+ "SD_DATA1_R",
+ "SD_DATA2_R",
+ "SD_DATA3_R";
+
+ pinctrl-0 = <&gpioout &alt0 &i2s_alt0>;
+
+ /* I2S interface */
+ i2s_alt0: i2s_alt0 {
+ brcm,pins = <18 19 20 21>;
+ brcm,function = <BCM2835_FSEL_ALT0>;
+ };
+};
+
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
index d070454..9b665da 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
@@ -2,6 +2,7 @@
#include "bcm2835.dtsi"
#include "bcm2835-rpi.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"
+#include "bcm2835-rpi-a-plus-gpio.dtsi"
/ {
compatible = "raspberrypi,model-a-plus", "brcm,bcm2835";
@@ -21,81 +22,6 @@
};
};
-&gpio {
- /*
- * This is based on the unreleased schematic for the Model A+.
- *
- * Legend:
- * "NC" = not connected (no rail from the SoC)
- * "FOO" = GPIO line named "FOO" on the schematic
- * "FOO_N" = GPIO line named "FOO" on schematic, active low
- */
- gpio-line-names = "SDA0",
- "SCL0",
- "SDA1",
- "SCL1",
- "GPIO_GCLK",
- "GPIO5",
- "GPIO6",
- "SPI_CE1_N",
- "SPI_CE0_N",
- "SPI_MISO",
- "SPI_MOSI",
- "SPI_SCLK",
- "GPIO12",
- "GPIO13",
- /* Serial port */
- "TXD0",
- "RXD0",
- "GPIO16",
- "GPIO17",
- "GPIO18",
- "GPIO19",
- "GPIO20",
- "GPIO21",
- "GPIO22",
- "GPIO23",
- "GPIO24",
- "GPIO25",
- "GPIO26",
- "GPIO27",
- "SDA0",
- "SCL0",
- "NC", /* GPIO30 */
- "NC", /* GPIO31 */
- "CAM_GPIO1", /* GPIO32 */
- "NC", /* GPIO33 */
- "NC", /* GPIO34 */
- "PWR_LOW_N", /* GPIO35 */
- "NC", /* GPIO36 */
- "NC", /* GPIO37 */
- "USB_LIMIT", /* GPIO38 */
- "NC", /* GPIO39 */
- "PWM0_OUT", /* GPIO40 */
- "CAM_GPIO0", /* GPIO41 */
- "NC", /* GPIO42 */
- "NC", /* GPIO43 */
- "NC", /* GPIO44 */
- "PWM1_OUT", /* GPIO45 */
- "HDMI_HPD_N",
- "STATUS_LED",
- /* Used by SD Card */
- "SD_CLK_R",
- "SD_CMD_R",
- "SD_DATA0_R",
- "SD_DATA1_R",
- "SD_DATA2_R",
- "SD_DATA3_R";
-
- pinctrl-0 = <&gpioout &alt0 &i2s_alt0>;
-
- /* I2S interface */
- i2s_alt0: i2s_alt0 {
- brcm,pins = <18 19 20 21>;
- brcm,function = <BCM2835_FSEL_ALT0>;
- };
-};
-
&hdmi {
hpd-gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero.dts b/arch/arm/boot/dts/bcm2835-rpi-zero.dts
index 7c1c180..0154ae0 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-zero.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-zero.dts
@@ -13,6 +13,7 @@
#include "bcm2835.dtsi"
#include "bcm2835-rpi.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"
+#include "bcm2835-rpi-a-plus-gpio.dtsi"
/ {
compatible = "raspberrypi,model-zero", "brcm,bcm2835";
@@ -25,16 +26,6 @@
};
};
-&gpio {
- pinctrl-0 = <&gpioout &alt0 &i2s_alt0>;
-
- /* I2S interface */
- i2s_alt0: i2s_alt0 {
- brcm,pins = <18 19 20 21>;
- brcm,function = <BCM2835_FSEL_ALT0>;
- };
-};
-
&hdmi {
hpd-gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] ARM: bcm2835: Fix names for the Raspberry Pi GPIO lines
From: Stefan Wahren @ 2016-11-13 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479060729-25769-1-git-send-email-stefan.wahren@i2se.com>
There are some differences between the schematics and the official firmware
DTS [1]. So based on these additional information the following has been
changed:
* use consistent "CAM_GPIO1" for camera LED
* use consistent "CAM_GPIO0" for camera shutdown
* add "USB_LIMIT" for USB current limit (0=600mA, 1=1200mA)
[1] - https://github.com/raspberrypi/documentation/blob/master/configuration/images/dt-blob.dts
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 4 ++--
arch/arm/boot/dts/bcm2835-rpi-a.dts | 4 ++--
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 2 +-
arch/arm/boot/dts/bcm2835-rpi-b.dts | 4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
index 5a22c79..d070454 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
@@ -63,13 +63,13 @@
"SCL0",
"NC", /* GPIO30 */
"NC", /* GPIO31 */
- "NC", /* GPIO32 */
+ "CAM_GPIO1", /* GPIO32 */
"NC", /* GPIO33 */
"NC", /* GPIO34 */
"PWR_LOW_N", /* GPIO35 */
"NC", /* GPIO36 */
"NC", /* GPIO37 */
- "NC", /* GPIO38 */
+ "USB_LIMIT", /* GPIO38 */
"NC", /* GPIO39 */
"PWM0_OUT", /* GPIO40 */
"CAM_GPIO0", /* GPIO41 */
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a.dts b/arch/arm/boot/dts/bcm2835-rpi-a.dts
index 54f98c5..46d078e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a.dts
@@ -29,7 +29,7 @@
"SDA1",
"SCL1",
"GPIO_GCLK",
- "CAM_CLK",
+ "CAM_GPIO1",
"LAN_RUN",
"SPI_CE1_N",
"SPI_CE0_N",
@@ -52,7 +52,7 @@
"GPIO24",
"GPIO25",
"NC", /* GPIO26 */
- "CAM_GPIO",
+ "CAM_GPIO0",
/* Binary number representing build/revision */
"CONFIG0",
"CONFIG1",
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index b67587e..432088e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -71,7 +71,7 @@
"PWR_LOW_N", /* GPIO35 */
"NC", /* GPIO36 */
"NC", /* GPIO37 */
- "NC", /* GPIO38 */
+ "USB_LIMIT", /* GPIO38 */
"NC", /* GPIO39 */
"PWM0_OUT", /* GPIO40 */
"CAM_GPIO0", /* GPIO41 */
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index 71f50e1..4d56fe3 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -30,7 +30,7 @@
"SDA1",
"SCL1",
"GPIO_GCLK",
- "CAM_CLK",
+ "CAM_GPIO1",
"LAN_RUN",
"SPI_CE1_N",
"SPI_CE0_N",
@@ -53,7 +53,7 @@
"GPIO24",
"GPIO25",
"NC", /* GPIO26 */
- "CAM_GPIO",
+ "CAM_GPIO0",
/* Binary number representing build/revision */
"CONFIG0",
"CONFIG1",
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/2] ARM: bcm2835: Fix names for the Raspberry Pi GPIO lines
From: Stefan Wahren @ 2016-11-13 18:12 UTC (permalink / raw)
To: linux-arm-kernel
This patch series should fix and extend the patch V4 "ARM: bcm2835: Add names
for the Raspberry Pi GPIO lines" from Linus Walleij and Eric Anholt.
Stefan Wahren (2):
ARM: bcm2835: Fix names for the Raspberry Pi GPIO lines
ARM: bcm2835: Add names for the Raspberry Pi Zero GPIO lines
arch/arm/boot/dts/bcm2835-rpi-a-plus-gpio.dtsi | 75 +++++++++++++++++++++++
arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 76 +-----------------------
arch/arm/boot/dts/bcm2835-rpi-a.dts | 4 +-
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 2 +-
arch/arm/boot/dts/bcm2835-rpi-b.dts | 4 +-
arch/arm/boot/dts/bcm2835-rpi-zero.dts | 11 +---
6 files changed, 82 insertions(+), 90 deletions(-)
create mode 100644 arch/arm/boot/dts/bcm2835-rpi-a-plus-gpio.dtsi
--
1.7.9.5
^ permalink raw reply
* [PATCH v3] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512
From: Andy Polyakov @ 2016-11-13 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_Y-ik0L9mh4z-g3fHKjPt780_znCQNU-jAwXifLgAo4A@mail.gmail.com>
> (+ Andy)
>
> ...
>>
>> Looking at the generated code, I see references to __ARMEB__ and
> __ILP32__.
>> The former is probably a bug,
Oh! You mean that it should be __AARCH64EB__/__AARCH64EL__! Apparently I
simply went on assuming that it would be __ARMEB__/__ARMEL__ even in
64-bit case. As Ard mentioned, there is a number of modules that can be
compiled for either 32- or 64-bit case, and supposedly that's where this
blunder stems from. Will fix... As for it being actually tested. No, I
don't have big-endian AArch64 setup, and big-endian segments in AArch64
are based on experience with endian neutrality elsewhere. I.e. it's
based on observations what it takes to achieve the neutrality elsewhere,
e.g. ARM, MIPS, PPC, and then exercising equivalent approach even here.
Modulo fact that I apparently got macros wrong :-(
>> whilst the second is not required.
Note that references to __ILP32__ are also inside #ifndef
__KERNEL__/#endif, i.e. they won't be even evaluated when compiled for
kernel. Or in other words it's shared code artefact just like #if[n]def
__KERNEL__ itself. You either disregard it or remove altogether, but
then code becomes specific and not shared :-)
>> There are
>> also some commented out instructions, which is weird.
Commented instructions denote those that are moved into next round in
order to improve instruction scheduling on either of processors. In
other words it means that you should spot it further below [in generated
code]. Yes, it's weird, but it helps me to remember which instructions
are moved. On side note it's not uncommon that instruction scheduling is
result of compromise. In general I attempt to schedule instruction for
near-optimal performance on *multiple* processors, but sometimes you
have to make compromises. One is mentioned in commentary section for
this very module, the Apple A7 vs. Cortex-A53 thing. Well, it's not like
the commented instruction you're observing is the only result of the
compromise, it's merely an example of how said compromises can manifest
themselves, as somewhat weird irregularities in the code, possibly with
commented instructions.
^ permalink raw reply
* [PATCH] drm/sun4i: constify component_ops structures
From: Daniel Vetter @ 2016-11-13 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478971198-3659-1-git-send-email-Julia.Lawall@lip6.fr>
On Sat, Nov 12, 2016 at 6:19 PM, Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> These component_ops structures are only used as the second argument to
> component_add and component_del, which are declared as const, so the
> structures can be declared as const as well.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
>
> static struct component_ops i at p = { ... };
>
> @ok1@
> identifier r.i;
> expression e1;
> position p;
> @@
>
> component_add(e1,&i at p)
>
> @ok2@
> identifier r.i;
> expression e1;
> position p;
> @@
>
> component_del(e1, &i at p)
>
> @bad@
> position p != {r.p,ok1.p,ok2.p};
> identifier r.i;
> struct component_ops e;
> @@
>
> e at i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
>
> static
> +const
> struct component_ops i = { ... };
> // </smpl>
>
> The result of the size command before the change is (arm):
>
> text data bss dec hex filename
> 5266 236 8 5510 1586 sun4i_backend.o
> 6393 236 8 6637 19ed sun4i_tcon.o
> 3700 368 8 4076 fec sun4i_tv.o
> 1668 108 0 1776 6f0 sun6i_drc.o
>
> and after the change:
>
> text data bss dec hex filename
> 5274 228 8 5510 1586 sun4i_backend.o
> 6401 228 8 6637 19ed sun4i_tcon.o
> 3708 360 8 4076 fec sun4i_tv.o
> 1676 100 0 1776 6f0 sun6i_drc.o
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied to drm-misc, thanks.
-Daniel
>
> ---
> drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_tv.c | 2 +-
> drivers/gpu/drm/sun4i/sun6i_drc.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index 7eb2a96..2e08f96 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -409,7 +409,7 @@ static void sun4i_backend_unbind(struct device *dev, struct device *master,
> reset_control_assert(backend->reset);
> }
>
> -static struct component_ops sun4i_backend_ops = {
> +static const struct component_ops sun4i_backend_ops = {
> .bind = sun4i_backend_bind,
> .unbind = sun4i_backend_unbind,
> };
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index c6afb24..ea2906f 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -545,7 +545,7 @@ static void sun4i_tcon_unbind(struct device *dev, struct device *master,
> sun4i_tcon_free_clocks(tcon);
> }
>
> -static struct component_ops sun4i_tcon_ops = {
> +static const struct component_ops sun4i_tcon_ops = {
> .bind = sun4i_tcon_bind,
> .unbind = sun4i_tcon_unbind,
> };
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
> index 1dd3d9e..d430b331 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -667,7 +667,7 @@ static void sun4i_tv_unbind(struct device *dev, struct device *master,
> clk_disable_unprepare(tv->clk);
> }
>
> -static struct component_ops sun4i_tv_ops = {
> +static const struct component_ops sun4i_tv_ops = {
> .bind = sun4i_tv_bind,
> .unbind = sun4i_tv_unbind,
> };
> diff --git a/drivers/gpu/drm/sun4i/sun6i_drc.c b/drivers/gpu/drm/sun4i/sun6i_drc.c
> index 6ef707c..09bba85 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_drc.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_drc.c
> @@ -80,7 +80,7 @@ static void sun6i_drc_unbind(struct device *dev, struct device *master,
> reset_control_assert(drc->reset);
> }
>
> -static struct component_ops sun6i_drc_ops = {
> +static const struct component_ops sun6i_drc_ops = {
> .bind = sun6i_drc_bind,
> .unbind = sun6i_drc_unbind,
> };
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 9/10] ARM: sun5i: Convert to CCU
From: Chen-Yu Tsai @ 2016-11-13 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4046893c1810045bac3eeb1ea3a35c5771d250e0.1478625788.git-series.maxime.ripard@free-electrons.com>
On Wed, Nov 9, 2016 at 1:23 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Now that we have drivers for all of them, convert all the SoCs that share
> the sun5i DTSI to the new CCU driver.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> arch/arm/boot/dts/sun5i-a10s.dtsi | 94 +-------
> arch/arm/boot/dts/sun5i-a13.dtsi | 140 +-----------
> arch/arm/boot/dts/sun5i-r8.dtsi | 10 +-
> arch/arm/boot/dts/sun5i.dtsi | 368 ++++---------------------------
> 4 files changed, 90 insertions(+), 522 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
> index 7aa8c7aa0153..1d26ae7267dc 100644
> --- a/arch/arm/boot/dts/sun5i-a10s.dtsi
> +++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
> @@ -61,99 +61,33 @@
> #size-cells = <1>;
> ranges;
>
> - framebuffer at 0 {
> - compatible = "allwinner,simple-framebuffer",
> - "simple-framebuffer";
> - allwinner,pipeline = "de_be0-lcd0-hdmi";
> - clocks = <&pll3>, <&pll5 1>, <&ahb_gates 36>,
> - <&ahb_gates 43>, <&ahb_gates 44>;
> - status = "disabled";
> - };
> -
> framebuffer at 1 {
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> - allwinner,pipeline = "de_be0-lcd0";
> - clocks = <&pll3>, <&pll5 1>, <&ahb_gates 36>,
> - <&ahb_gates 44>;
> + allwinner,pipeline = "de_be0-lcd0-tve0";
> + clocks = <&ccu CLK_AHB_TVE>, <&ccu CLK_AHB_LCD>,
> + <&ccu CLK_AHB_DE_BE>, <&ccu CLK_DE_BE>,
> + <&ccu CLK_TCON_CH1>, <&ccu CLK_DRAM_DE_BE>;
> status = "disabled";
> };
>
> framebuffer at 2 {
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> - allwinner,pipeline = "de_be0-lcd0-tve0";
> - clocks = <&pll3>, <&pll5 1>, <&ahb_gates 34>,
> - <&ahb_gates 36>, <&ahb_gates 44>;
> + allwinner,pipeline = "de_be0-lcd0-hdmi";
> + clocks = <&ccu CLK_AHB_LCD>, <&ccu CLK_AHB_HDMI>,
> + <&ccu CLK_AHB_DE_BE>, <&ccu CLK_DRAM_DE_BE>,
> + <&ccu CLK_DE_BE>, <&ccu CLK_HDMI>;
You might want to mention you moved the framebuffer nodes around.
Or maybe do it in a separate patch.
> status = "disabled";
> };
> };
>
> - clocks {
> - ahb_gates: clk at 01c20060 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a10s-ahb-gates-clk";
> - reg = <0x01c20060 0x8>;
> - clocks = <&ahb>;
> - clock-indices = <0>, <1>,
> - <2>, <5>, <6>,
> - <7>, <8>, <9>,
> - <10>, <13>,
> - <14>, <17>, <18>,
> - <20>, <21>, <22>,
> - <26>, <28>, <32>,
> - <34>, <36>, <40>,
> - <43>, <44>,
> - <46>, <51>,
> - <52>;
> - clock-output-names = "ahb_usbotg", "ahb_ehci",
> - "ahb_ohci", "ahb_ss", "ahb_dma",
> - "ahb_bist", "ahb_mmc0", "ahb_mmc1",
> - "ahb_mmc2", "ahb_nand",
> - "ahb_sdram", "ahb_emac", "ahb_ts",
> - "ahb_spi0", "ahb_spi1", "ahb_spi2",
> - "ahb_gps", "ahb_stimer", "ahb_ve",
> - "ahb_tve", "ahb_lcd", "ahb_csi",
> - "ahb_hdmi", "ahb_de_be",
> - "ahb_de_fe", "ahb_iep",
> - "ahb_mali400";
> - };
> -
> - apb0_gates: clk at 01c20068 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a10s-apb0-gates-clk";
> - reg = <0x01c20068 0x4>;
> - clocks = <&apb0>;
> - clock-indices = <0>, <3>,
> - <5>, <6>,
> - <10>;
> - clock-output-names = "apb0_codec", "apb0_iis",
> - "apb0_pio", "apb0_ir",
> - "apb0_keypad";
> - };
> -
> - apb1_gates: clk at 01c2006c {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a10s-apb1-gates-clk";
> - reg = <0x01c2006c 0x4>;
> - clocks = <&apb1>;
> - clock-indices = <0>, <1>,
> - <2>, <16>,
> - <17>, <18>,
> - <19>;
> - clock-output-names = "apb1_i2c0", "apb1_i2c1",
> - "apb1_i2c2", "apb1_uart0",
> - "apb1_uart1", "apb1_uart2",
> - "apb1_uart3";
> - };
> - };
> -
> soc at 01c00000 {
> emac: ethernet at 01c0b000 {
> compatible = "allwinner,sun4i-a10-emac";
> reg = <0x01c0b000 0x1000>;
> interrupts = <55>;
> - clocks = <&ahb_gates 17>;
> + clocks = <&ccu CLK_AHB_EMAC>;
> allwinner,sram = <&emac_sram 1>;
> status = "disabled";
> };
> @@ -169,7 +103,7 @@
> pwm: pwm at 01c20e00 {
> compatible = "allwinner,sun5i-a10s-pwm";
> reg = <0x01c20e00 0xc>;
> - clocks = <&osc24M>;
> + clocks = <&ccu CLK_HOSC>;
> #pwm-cells = <3>;
> status = "disabled";
> };
> @@ -180,7 +114,7 @@
> interrupts = <1>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 16>;
> + clocks = <&ccu CLK_APB1_UART0>;
> status = "disabled";
> };
>
> @@ -190,12 +124,16 @@
> interrupts = <3>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 18>;
> + clocks = <&ccu CLK_APB1_UART2>;
> status = "disabled";
> };
> };
> };
>
> +&ccu {
> + compatible = "allwinner,sun5i-a10s-ccu";
> +};
> +
> &pio {
> compatible = "allwinner,sun5i-a10s-pinctrl";
>
> diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
> index a17ba0243db3..0330304f1d42 100644
> --- a/arch/arm/boot/dts/sun5i-a13.dtsi
> +++ b/arch/arm/boot/dts/sun5i-a13.dtsi
> @@ -61,8 +61,8 @@
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> allwinner,pipeline = "de_be0-lcd0";
> - clocks = <&ahb_gates 36>, <&ahb_gates 44>, <&de_be_clk>,
> - <&tcon_ch0_clk>, <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_LCD>, <&ccu CLK_AHB_DE_BE>, <&ccu CLK_DE_BE>,
> + <&ccu CLK_TCON_CH0>, <&ccu CLK_DRAM_DE_BE>;
> status = "disabled";
> };
> };
> @@ -99,114 +99,6 @@
> };
> };
>
> - clocks {
> - ahb_gates: clk at 01c20060 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a13-ahb-gates-clk";
> - reg = <0x01c20060 0x8>;
> - clocks = <&ahb>;
> - clock-indices = <0>, <1>,
> - <2>, <5>, <6>,
> - <7>, <8>, <9>,
> - <10>, <13>,
> - <14>, <20>,
> - <21>, <22>,
> - <28>, <32>, <34>,
> - <36>, <40>, <44>,
> - <46>, <51>,
> - <52>;
> - clock-output-names = "ahb_usbotg", "ahb_ehci",
> - "ahb_ohci", "ahb_ss", "ahb_dma",
> - "ahb_bist", "ahb_mmc0", "ahb_mmc1",
> - "ahb_mmc2", "ahb_nand",
> - "ahb_sdram", "ahb_spi0",
> - "ahb_spi1", "ahb_spi2",
> - "ahb_stimer", "ahb_ve", "ahb_tve",
> - "ahb_lcd", "ahb_csi", "ahb_de_be",
> - "ahb_de_fe", "ahb_iep",
> - "ahb_mali400";
> - };
> -
> - apb0_gates: clk at 01c20068 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a13-apb0-gates-clk";
> - reg = <0x01c20068 0x4>;
> - clocks = <&apb0>;
> - clock-indices = <0>, <5>,
> - <6>;
> - clock-output-names = "apb0_codec", "apb0_pio",
> - "apb0_ir";
> - };
> -
> - apb1_gates: clk at 01c2006c {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a13-apb1-gates-clk";
> - reg = <0x01c2006c 0x4>;
> - clocks = <&apb1>;
> - clock-indices = <0>, <1>,
> - <2>, <17>,
> - <19>;
> - clock-output-names = "apb1_i2c0", "apb1_i2c1",
> - "apb1_i2c2", "apb1_uart1",
> - "apb1_uart3";
> - };
> -
> - dram_gates: clk at 01c20100 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a13-dram-gates-clk",
> - "allwinner,sun4i-a10-gates-clk";
> - reg = <0x01c20100 0x4>;
> - clocks = <&pll5 0>;
> - clock-indices = <0>,
> - <1>,
> - <25>,
> - <26>,
> - <29>,
> - <31>;
> - clock-output-names = "dram_ve",
> - "dram_csi",
> - "dram_de_fe",
> - "dram_de_be",
> - "dram_ace",
> - "dram_iep";
> - };
> -
> - de_be_clk: clk at 01c20104 {
> - #clock-cells = <0>;
> - #reset-cells = <0>;
> - compatible = "allwinner,sun4i-a10-display-clk";
> - reg = <0x01c20104 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> - clock-output-names = "de-be";
> - };
> -
> - de_fe_clk: clk at 01c2010c {
> - #clock-cells = <0>;
> - #reset-cells = <0>;
> - compatible = "allwinner,sun4i-a10-display-clk";
> - reg = <0x01c2010c 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> - clock-output-names = "de-fe";
> - };
> -
> - tcon_ch0_clk: clk at 01c20118 {
> - #clock-cells = <0>;
> - #reset-cells = <1>;
> - compatible = "allwinner,sun4i-a10-tcon-ch0-clk";
> - reg = <0x01c20118 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> - clock-output-names = "tcon-ch0-sclk";
> - };
> -
> - tcon_ch1_clk: clk at 01c2012c {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-tcon-ch1-clk";
> - reg = <0x01c2012c 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> - clock-output-names = "tcon-ch1-sclk";
> - };
> - };
> -
> display-engine {
> compatible = "allwinner,sun5i-a13-display-engine";
> allwinner,pipelines = <&fe0>;
> @@ -217,11 +109,11 @@
> compatible = "allwinner,sun5i-a13-tcon";
> reg = <0x01c0c000 0x1000>;
> interrupts = <44>;
> - resets = <&tcon_ch0_clk 1>;
> + resets = <&ccu RST_LCD>;
> reset-names = "lcd";
> - clocks = <&ahb_gates 36>,
> - <&tcon_ch0_clk>,
> - <&tcon_ch1_clk>;
> + clocks = <&ccu CLK_AHB_LCD>,
> + <&ccu CLK_TCON_CH0>,
> + <&ccu CLK_TCON_CH1>;
Just curious, is CLK_TCON_CH1_SCLK ever used?
> clock-names = "ahb",
> "tcon-ch0",
> "tcon-ch1";
> @@ -254,7 +146,7 @@
> pwm: pwm at 01c20e00 {
> compatible = "allwinner,sun5i-a13-pwm";
> reg = <0x01c20e00 0xc>;
> - clocks = <&osc24M>;
> + clocks = <&ccu CLK_HOSC>;
> #pwm-cells = <3>;
> status = "disabled";
> };
> @@ -263,11 +155,11 @@
> compatible = "allwinner,sun5i-a13-display-frontend";
> reg = <0x01e00000 0x20000>;
> interrupts = <47>;
> - clocks = <&ahb_gates 46>, <&de_fe_clk>,
> - <&dram_gates 25>;
> + clocks = <&ccu CLK_DE_FE>, <&ccu CLK_DE_FE>,
> + <&ccu CLK_DRAM_DE_FE>;
> clock-names = "ahb", "mod",
> "ram";
> - resets = <&de_fe_clk>;
> + resets = <&ccu RST_DE_FE>;
> status = "disabled";
>
> ports {
> @@ -290,14 +182,14 @@
> be0: display-backend at 01e60000 {
> compatible = "allwinner,sun5i-a13-display-backend";
> reg = <0x01e60000 0x10000>;
> - clocks = <&ahb_gates 44>, <&de_be_clk>,
> - <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_DE_BE>, <&ccu CLK_DE_BE>,
> + <&ccu CLK_DRAM_DE_BE>;
> clock-names = "ahb", "mod",
> "ram";
> - resets = <&de_be_clk>;
> + resets = <&ccu RST_DE_BE>;
> status = "disabled";
>
> - assigned-clocks = <&de_be_clk>;
> + assigned-clocks = <&ccu CLK_DE_BE>;
> assigned-clock-rates = <300000000>;
>
> ports {
> @@ -330,6 +222,10 @@
> };
> };
>
> +&ccu {
> + compatible = "allwinner,sun5i-a13-ccu";
> +};
> +
> &cpu0 {
> clock-latency = <244144>; /* 8 32k periods */
> operating-points = <
> diff --git a/arch/arm/boot/dts/sun5i-r8.dtsi b/arch/arm/boot/dts/sun5i-r8.dtsi
> index 8b058f53b7dc..4c1141396c99 100644
> --- a/arch/arm/boot/dts/sun5i-r8.dtsi
> +++ b/arch/arm/boot/dts/sun5i-r8.dtsi
> @@ -51,9 +51,9 @@
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> allwinner,pipeline = "de_be0-lcd0-tve0";
> - clocks = <&ahb_gates 34>, <&ahb_gates 36>,
> - <&ahb_gates 44>, <&de_be_clk>,
> - <&tcon_ch1_clk>, <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_TVE>, <&ccu CLK_AHB_LCD>,
> + <&ccu CLK_AHB_DE_BE>, <&ccu CLK_DE_BE>,
> + <&ccu CLK_TCON_CH1>, <&ccu CLK_DRAM_DE_BE>;
> status = "disabled";
> };
> };
> @@ -62,8 +62,8 @@
> tve0: tv-encoder at 01c0a000 {
> compatible = "allwinner,sun4i-a10-tv-encoder";
> reg = <0x01c0a000 0x1000>;
> - clocks = <&ahb_gates 34>;
> - resets = <&tcon_ch0_clk 0>;
> + clocks = <&ccu CLK_AHB_TVE>;
> + resets = <&ccu RST_TVE>;
> status = "disabled";
>
> port {
> diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
> index b4ccee8cfb02..2dbc7623ec04 100644
> --- a/arch/arm/boot/dts/sun5i.dtsi
> +++ b/arch/arm/boot/dts/sun5i.dtsi
> @@ -44,13 +44,29 @@
>
> #include "skeleton.dtsi"
>
> -#include <dt-bindings/clock/sun4i-a10-pll2.h>
> +#include <dt-bindings/clock/sun5i-ccu.h>
> #include <dt-bindings/dma/sun4i-a10.h>
> #include <dt-bindings/pinctrl/sun4i-a10.h>
> +#include <dt-bindings/reset/sun5i-ccu.h>
>
> / {
> interrupt-parent = <&intc>;
>
> + chosen {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + framebuffer at 0 {
> + compatible = "allwinner,simple-framebuffer",
> + "simple-framebuffer";
> + allwinner,pipeline = "de_be0-lcd0";
> + clocks = <&ccu CLK_AHB_LCD>, <&ccu CLK_AHB_DE_BE>, <&ccu CLK_DE_BE>,
> + <&ccu CLK_TCON_CH0>, <&ccu CLK_DRAM_DE_BE>;
> + status = "disabled";
> + };
> + };
> +
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -59,7 +75,7 @@
> device_type = "cpu";
> compatible = "arm,cortex-a8";
> reg = <0x0>;
> - clocks = <&cpu>;
> + clocks = <&ccu CLK_CPU>;
> };
> };
>
> @@ -68,291 +84,19 @@
> #size-cells = <1>;
> ranges;
>
> - /*
> - * This is a dummy clock, to be used as placeholder on
> - * other mux clocks when a specific parent clock is not
> - * yet implemented. It should be dropped when the driver
> - * is complete.
> - */
> - dummy: dummy {
> - #clock-cells = <0>;
> - compatible = "fixed-clock";
> - clock-frequency = <0>;
> - };
> -
> osc24M: clk at 01c20050 {
> #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-osc-clk";
> - reg = <0x01c20050 0x4>;
> + compatible = "fixed-clock";
> clock-frequency = <24000000>;
> clock-output-names = "osc24M";
> };
>
> - osc3M: osc3M_clk {
> - compatible = "fixed-factor-clock";
> - #clock-cells = <0>;
> - clock-div = <8>;
> - clock-mult = <1>;
> - clocks = <&osc24M>;
> - clock-output-names = "osc3M";
> - };
> -
> osc32k: clk at 0 {
> #clock-cells = <0>;
> compatible = "fixed-clock";
> clock-frequency = <32768>;
> clock-output-names = "osc32k";
> };
> -
> - pll1: clk at 01c20000 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll1-clk";
> - reg = <0x01c20000 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll1";
> - };
> -
> - pll2: clk at 01c20008 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a13-pll2-clk";
> - reg = <0x01c20008 0x8>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll2-1x", "pll2-2x",
> - "pll2-4x", "pll2-8x";
> - };
> -
> - pll3: clk at 01c20010 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll3-clk";
> - reg = <0x01c20010 0x4>;
> - clocks = <&osc3M>;
> - clock-output-names = "pll3";
> - };
> -
> - pll3x2: pll3x2_clk {
> - compatible = "allwinner,sun4i-a10-pll3-2x-clk", "fixed-factor-clock";
> - #clock-cells = <0>;
> - clock-div = <1>;
> - clock-mult = <2>;
> - clocks = <&pll3>;
> - clock-output-names = "pll3-2x";
> - };
> -
> - pll4: clk at 01c20018 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll1-clk";
> - reg = <0x01c20018 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll4";
> - };
> -
> - pll5: clk at 01c20020 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-pll5-clk";
> - reg = <0x01c20020 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll5_ddr", "pll5_other";
> - };
> -
> - pll6: clk at 01c20028 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-pll6-clk";
> - reg = <0x01c20028 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll6_sata", "pll6_other", "pll6";
> - };
> -
> - pll7: clk at 01c20030 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll3-clk";
> - reg = <0x01c20030 0x4>;
> - clocks = <&osc3M>;
> - clock-output-names = "pll7";
> - };
> -
> - pll7x2: pll7x2_clk {
> - compatible = "fixed-factor-clock";
> - #clock-cells = <0>;
> - clock-div = <1>;
> - clock-mult = <2>;
> - clocks = <&pll7>;
> - clock-output-names = "pll7-2x";
> - };
> -
> - /* dummy is 200M */
> - cpu: cpu at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-cpu-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&osc32k>, <&osc24M>, <&pll1>, <&dummy>;
> - clock-output-names = "cpu";
> - };
> -
> - axi: axi at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-axi-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&cpu>;
> - clock-output-names = "axi";
> - };
> -
> - ahb: ahb at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun5i-a13-ahb-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&axi>, <&cpu>, <&pll6 1>;
> - clock-output-names = "ahb";
> - /*
> - * Use PLL6 as parent, instead of CPU/AXI
> - * which has rate changes due to cpufreq
> - */
> - assigned-clocks = <&ahb>;
> - assigned-clock-parents = <&pll6 1>;
> - };
> -
> - apb0: apb0 at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-apb0-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&ahb>;
> - clock-output-names = "apb0";
> - };
> -
> - apb1: clk at 01c20058 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-apb1-clk";
> - reg = <0x01c20058 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&osc32k>;
> - clock-output-names = "apb1";
> - };
> -
> - axi_gates: clk at 01c2005c {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-axi-gates-clk";
> - reg = <0x01c2005c 0x4>;
> - clocks = <&axi>;
> - clock-indices = <0>;
> - clock-output-names = "axi_dram";
> - };
> -
> - nand_clk: clk at 01c20080 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c20080 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "nand";
> - };
> -
> - ms_clk: clk at 01c20084 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c20084 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ms";
> - };
> -
> - mmc0_clk: clk at 01c20088 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-mmc-clk";
> - reg = <0x01c20088 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mmc0",
> - "mmc0_output",
> - "mmc0_sample";
> - };
> -
> - mmc1_clk: clk at 01c2008c {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-mmc-clk";
> - reg = <0x01c2008c 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mmc1",
> - "mmc1_output",
> - "mmc1_sample";
> - };
> -
> - mmc2_clk: clk at 01c20090 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-mmc-clk";
> - reg = <0x01c20090 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mmc2",
> - "mmc2_output",
> - "mmc2_sample";
> - };
> -
> - ts_clk: clk at 01c20098 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c20098 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ts";
> - };
> -
> - ss_clk: clk at 01c2009c {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c2009c 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ss";
> - };
> -
> - spi0_clk: clk at 01c200a0 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200a0 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "spi0";
> - };
> -
> - spi1_clk: clk at 01c200a4 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200a4 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "spi1";
> - };
> -
> - spi2_clk: clk at 01c200a8 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200a8 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "spi2";
> - };
> -
> - ir0_clk: clk at 01c200b0 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200b0 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ir0";
> - };
> -
> - usb_clk: clk at 01c200cc {
> - #clock-cells = <1>;
> - #reset-cells = <1>;
> - compatible = "allwinner,sun5i-a13-usb-clk";
> - reg = <0x01c200cc 0x4>;
> - clocks = <&pll6 1>;
> - clock-output-names = "usb_ohci0", "usb_phy";
> - };
> -
> - codec_clk: clk at 01c20140 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-codec-clk";
> - reg = <0x01c20140 0x4>;
> - clocks = <&pll2 SUN4I_A10_PLL2_1X>;
> - clock-output-names = "codec";
> - };
> -
> - mbus_clk: clk at 01c2015c {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun5i-a13-mbus-clk";
> - reg = <0x01c2015c 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mbus";
> - };
> };
>
> soc at 01c00000 {
> @@ -395,7 +139,7 @@
> compatible = "allwinner,sun4i-a10-dma";
> reg = <0x01c02000 0x1000>;
> interrupts = <27>;
> - clocks = <&ahb_gates 6>;
> + clocks = <&ccu CLK_AHB_DMA>;
> #dma-cells = <2>;
> };
>
> @@ -403,7 +147,7 @@
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c05000 0x1000>;
> interrupts = <10>;
> - clocks = <&ahb_gates 20>, <&spi0_clk>;
> + clocks = <&ccu CLK_AHB_SPI0>, <&ccu CLK_SPI0>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 27>,
> <&dma SUN4I_DMA_DEDICATED 26>;
> @@ -417,7 +161,7 @@
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c06000 0x1000>;
> interrupts = <11>;
> - clocks = <&ahb_gates 21>, <&spi1_clk>;
> + clocks = <&ccu CLK_AHB_SPI1>, <&ccu CLK_SPI1>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 9>,
> <&dma SUN4I_DMA_DEDICATED 8>;
> @@ -430,14 +174,8 @@
> mmc0: mmc at 01c0f000 {
> compatible = "allwinner,sun5i-a13-mmc";
> reg = <0x01c0f000 0x1000>;
> - clocks = <&ahb_gates 8>,
> - <&mmc0_clk 0>,
> - <&mmc0_clk 1>,
> - <&mmc0_clk 2>;
> - clock-names = "ahb",
> - "mmc",
> - "output",
> - "sample";
> + clocks = <&ccu CLK_AHB_MMC0>, <&ccu CLK_MMC0>;
> + clock-names = "ahb", "mmc";
> interrupts = <32>;
> status = "disabled";
> #address-cells = <1>;
> @@ -447,14 +185,8 @@
> mmc1: mmc at 01c10000 {
> compatible = "allwinner,sun5i-a13-mmc";
> reg = <0x01c10000 0x1000>;
> - clocks = <&ahb_gates 9>,
> - <&mmc1_clk 0>,
> - <&mmc1_clk 1>,
> - <&mmc1_clk 2>;
> - clock-names = "ahb",
> - "mmc",
> - "output",
> - "sample";
> + clocks = <&ccu CLK_AHB_MMC1>, <&ccu CLK_MMC1>;
> + clock-names = "ahb", "mmc";
> interrupts = <33>;
> status = "disabled";
> #address-cells = <1>;
> @@ -464,14 +196,8 @@
> mmc2: mmc at 01c11000 {
> compatible = "allwinner,sun5i-a13-mmc";
> reg = <0x01c11000 0x1000>;
> - clocks = <&ahb_gates 10>,
> - <&mmc2_clk 0>,
> - <&mmc2_clk 1>,
> - <&mmc2_clk 2>;
> - clock-names = "ahb",
> - "mmc",
> - "output",
> - "sample";
> + clocks = <&ccu CLK_AHB_MMC2>, <&ccu CLK_MMC2>;
> + clock-names = "ahb", "mmc";
> interrupts = <34>;
> status = "disabled";
> #address-cells = <1>;
> @@ -481,7 +207,7 @@
> usb_otg: usb at 01c13000 {
> compatible = "allwinner,sun4i-a10-musb";
> reg = <0x01c13000 0x0400>;
> - clocks = <&ahb_gates 0>;
> + clocks = <&ccu CLK_AHB_OTG>;
> interrupts = <38>;
> interrupt-names = "mc";
> phys = <&usbphy 0>;
> @@ -496,9 +222,9 @@
> compatible = "allwinner,sun5i-a13-usb-phy";
> reg = <0x01c13400 0x10 0x01c14800 0x4>;
> reg-names = "phy_ctrl", "pmu1";
> - clocks = <&usb_clk 8>;
> + clocks = <&ccu CLK_USB_PHY0>;
> clock-names = "usb_phy";
> - resets = <&usb_clk 0>, <&usb_clk 1>;
> + resets = <&ccu RST_USB_PHY0>, <&ccu RST_USB_PHY1>;
> reset-names = "usb0_reset", "usb1_reset";
> status = "disabled";
> };
> @@ -507,7 +233,7 @@
> compatible = "allwinner,sun5i-a13-ehci", "generic-ehci";
> reg = <0x01c14000 0x100>;
> interrupts = <39>;
> - clocks = <&ahb_gates 1>;
> + clocks = <&ccu CLK_AHB_EHCI>;
> phys = <&usbphy 1>;
> phy-names = "usb";
> status = "disabled";
> @@ -517,7 +243,7 @@
> compatible = "allwinner,sun5i-a13-ohci", "generic-ohci";
> reg = <0x01c14400 0x100>;
> interrupts = <40>;
> - clocks = <&usb_clk 6>, <&ahb_gates 2>;
> + clocks = <&ccu CLK_USB_OHCI>, <&ccu CLK_AHB_OHCI>;
> phys = <&usbphy 1>;
> phy-names = "usb";
> status = "disabled";
> @@ -527,7 +253,7 @@
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c17000 0x1000>;
> interrupts = <12>;
> - clocks = <&ahb_gates 22>, <&spi2_clk>;
> + clocks = <&ccu CLK_AHB_SPI2>, <&ccu CLK_SPI2>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 29>,
> <&dma SUN4I_DMA_DEDICATED 28>;
> @@ -537,6 +263,14 @@
> #size-cells = <0>;
> };
>
> + ccu: clock at 01c20000 {
> + reg = <0x01c20000 0x400>;
> + clocks = <&osc24M>, <&osc32k>;
> + clock-names = "hosc", "losc";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> intc: interrupt-controller at 01c20400 {
> compatible = "allwinner,sun4i-a10-ic";
> reg = <0x01c20400 0x400>;
> @@ -547,7 +281,7 @@
> pio: pinctrl at 01c20800 {
> reg = <0x01c20800 0x400>;
> interrupts = <28>;
> - clocks = <&apb0_gates 5>;
> + clocks = <&ccu CLK_APB0_PIO>;
> gpio-controller;
> interrupt-controller;
> #interrupt-cells = <3>;
> @@ -641,7 +375,7 @@
> compatible = "allwinner,sun4i-a10-timer";
> reg = <0x01c20c00 0x90>;
> interrupts = <22>;
> - clocks = <&osc24M>;
> + clocks = <&ccu CLK_HOSC>;
> };
>
> wdt: watchdog at 01c20c90 {
> @@ -661,7 +395,7 @@
> compatible = "allwinner,sun4i-a10-codec";
> reg = <0x01c22c00 0x40>;
> interrupts = <30>;
> - clocks = <&apb0_gates 0>, <&codec_clk>;
> + clocks = <&ccu CLK_APB0_CODEC>, <&ccu CLK_CODEC>;
> clock-names = "apb", "codec";
> dmas = <&dma SUN4I_DMA_NORMAL 19>,
> <&dma SUN4I_DMA_NORMAL 19>;
> @@ -687,7 +421,7 @@
> interrupts = <2>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 17>;
> + clocks = <&ccu CLK_APB1_UART1>;
> status = "disabled";
> };
>
> @@ -697,7 +431,7 @@
> interrupts = <4>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 19>;
> + clocks = <&ccu CLK_APB1_UART3>;
> status = "disabled";
> };
>
> @@ -705,7 +439,7 @@
> compatible = "allwinner,sun4i-a10-i2c";
> reg = <0x01c2ac00 0x400>;
> interrupts = <7>;
> - clocks = <&apb1_gates 0>;
> + clocks = <&ccu CLK_APB1_I2C0>;
> status = "disabled";
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -715,7 +449,7 @@
> compatible = "allwinner,sun4i-a10-i2c";
> reg = <0x01c2b000 0x400>;
> interrupts = <8>;
> - clocks = <&apb1_gates 1>;
> + clocks = <&ccu CLK_APB1_I2C1>;
> status = "disabled";
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -725,7 +459,7 @@
> compatible = "allwinner,sun4i-a10-i2c";
> reg = <0x01c2b400 0x400>;
> interrupts = <9>;
> - clocks = <&apb1_gates 2>;
> + clocks = <&ccu CLK_APB1_I2C2>;
> status = "disabled";
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -735,7 +469,7 @@
> compatible = "allwinner,sun5i-a13-hstimer";
> reg = <0x01c60000 0x1000>;
> interrupts = <82>, <83>;
> - clocks = <&ahb_gates 28>;
> + clocks = <&ccu CLK_AHB_HSTIMER>;
> };
> };
> };
The rest looks good.
ChenYu
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-13 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b5ae20d7-8394-7ad5-1830-13173e9105c4@gmail.com>
Hi,
On 13-11-16 12:44, Jacek Anaszewski wrote:
> Hi,
>
> On 11/12/2016 10:14 PM, Hans de Goede wrote:
<snip>
>>>> So I would like to propose creating a new read-write
>>>> user_brightness file.
>>>>
>>>> The write behavior would be 100% identical to the brightness
>>>> file (in code terms it will call the same store function).
>>>>
>>>> The the read behavior otoh will be different: it will shows
>>>> the last brightness as set by the user, this would show the
>>>> read behavior we really want of brightness: show the real
>>>> brightness when not blinking / triggers are active and show
>>>> the brightness used when on when blinking / triggers are active.
>>>>
>>>> We could then add poll support on this new user_brightness
>>>> file, thus avoiding the problem with the extra cpu-load on
>>>> notifications on blinking / triggers.
>>>
>>> I agree that user_brightness allows to solve the issues you raised
>>> about inconsistent write and read brightness' semantics
>>> (which is not that painful IMHO).
>>>
>>> Reporting non-user brightness changes on user_brightness file
>>> doesn't sound reasonable though.
>>
>> The changes I'm interested in are user brightness changes they
>> are just not done through sysfs, but through a hardwired hotkey,
>> they are however very much done by the user.
>
> Ah, so this file name would be misleading especially taking into account
> the context in which "user" is used in kernel, which predominantly
> means "userspace", e.g. copy_to_user(), copy_from_user().
>
>>> Also, how would we read the
>>> brightness set by the firmware? We'd have to read brightness
>>> file, so still two files would have to be opened which is
>>> a second drawback of this approach.
>>
>> No, look carefully at the definition of the read behavior
>> I plan to put in the ABI doc:
>
> OK, "user" was what confused me. So in this case changes made
> by the firmware even if in a result of user activity
> (pressing hardware key) obviously cannot be treated similarly
> to the changes made from the userspace context.
In the end both result on the brightness of the device
changing, so any userspace process interested in monitoring
the brightness will want to know about both type of changes.
> Unless you're able to give references to the kernel code which
> contradict my judgement.
AFAIK the audio code will signal volume changes done by
hardwired buttons the same way as audio changes done
by userspace calling into the kernel. This also makes
sense because in the end, what is interesting for a
mixer app, is that the volume changed, and what the
new volume is.
>> "Reading this file will return the actual led brightness
>> when not blinking and no triggers are active; reading this
>> file will return the brightness used when the led is on
>> when blinking or triggers are active."
>
> This is unnecessarily entangled. Blinking means timer trigger
> is active.
Ok.
>> So for e.g. the backlit keyboard case reading this single
>> file will return the actual brightness of the backlight,
>> since this does not involve blinking or triggers.
>>
>> Basically the idea is that the user_brightness file
>> will have the semantics which IMHO the brightness file
>> itself should have had from the beginning, but which
>> we can't change now due to ABI reasons.
>
> And in fact introducing user_brightness file would indeed
> fix that shortcoming. However without providing notifications
> of hw brightness changes on it.
See above, I believe such a file should report any
changes in brightness, except those caused by triggers,
so it would report hw brightness changes.
Anyways if you're not interested in fixing the
shortcomings of the current read behavior on the
brightness file (I'm fine with that, I can live
with the shortcomings) I suggest that we simply go
with v2 of my poll() patch.
>>> Having no difference in this area between the two approaches
>>> I'm still in favour of the read-only file for notifying
>>> brightness changes procured by hardware.
>>
>> That brings back the needing 2 fds problem; and does
>> not solve userspace not being able to reliably read
>> the led on brightness when blinking or using triggers.
>>
>> And this also has the issue that one is doing poll() on
>> one fd to detect changes on another fd,
>
> It is not necessarily true. We can treat the polling on
> hw_brightness_change file as a means to detect brightness
> changes procured by hardware and we can read that brightness
> by executing read on this same fd. It could return -ENODATA
> if no such an event has occurred so far.
That would still require 2 fds as userspace also wants to
be able to set the keyboard backlight, but allowing read()
on the hw_brightness_change file at least fixes the weirdness
where userspace gets woken from poll() without being able to
read. So if you insist on going the hw_brightness_change file
route, then I can live with that (and upower will simply
need to open 2 fds, that is doable).
But, BUT, I would greatly prefer to just go for v4 of my
patch, which fixes the only real problem we've seen with
my patch as original merged without adding a new, somewhat
convoluted sysfs attribute.
Regards,
Hans
^ permalink raw reply
* [PATCH] ARM: dts: imx6sx-udoo: Add board specific compatible strings
From: Fabio Estevam @ 2016-11-13 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478021892-18344-1-git-send-email-fabio.estevam@nxp.com>
Hi Shawn,
On Tue, Nov 1, 2016 at 3:38 PM, Fabio Estevam <fabio.estevam@nxp.com> wrote:
> Add a compatible entry for the specific board versions.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts | 2 +-
> arch/arm/boot/dts/imx6sx-udoo-neo-extended.dts | 2 +-
> arch/arm/boot/dts/imx6sx-udoo-neo-full.dts | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts b/arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts
> index 0b88878..0c1fc1a 100644
> --- a/arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts
> +++ b/arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts
> @@ -46,7 +46,7 @@
>
> / {
> model = "UDOO Neo Basic";
> - compatible = "fsl,imx6sx";
> + compatible = "udoo,neobasic", "fsl,imx6sx";
Just to let you know that Rob has alreasy applied the patch that add
udoo in vendor-prefixes.txt:
https://git.kernel.org/cgit/linux/kernel/git/robh/linux.git/commit/?h=for-next&id=61bdc6a118e402543a724808c651bb7ca2751bd9
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Jacek Anaszewski @ 2016-11-13 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cb0aa3ce-ee48-66b8-510c-bd70917afec9@redhat.com>
Hi,
On 11/12/2016 10:14 PM, Hans de Goede wrote:
> Hi,
>
> On 12-11-16 20:14, Jacek Anaszewski wrote:
>
> <snip>
>
>>>>> Why a dedicated file? Are we going to mirror brightness here
>>>>> wrt r/w (show/store) behavior ? If not userspace now needs
>>>>> 2 open fds which is not really nice. If we are and we are
>>>>> not going to use poll for something else on brightness itself
>>>>> then why not just poll directly on brightness ?
>>>>
>>>> My main concern is that reporting only hw brightness changes
>>>> wouldn't be consistent with general brightness file purpose.
>>>> One could expect that brightness changes made by triggers
>>>> should be also reported.
>>>
>>> Ok, I agree that not notifying poll() while an actual
>>> read() would result in a different value is not really good
>>> semantics.
>>>
>>> I don't like to call it hw_brightness_change though, as
>>> mentioned before I believe that if we were to start with
>>> a clean slate we would make the brightness file's read/write
>>> behavior more a mirror of itself.
>>>
>>> So I would like to propose creating a new read-write
>>> user_brightness file.
>>>
>>> The write behavior would be 100% identical to the brightness
>>> file (in code terms it will call the same store function).
>>>
>>> The the read behavior otoh will be different: it will shows
>>> the last brightness as set by the user, this would show the
>>> read behavior we really want of brightness: show the real
>>> brightness when not blinking / triggers are active and show
>>> the brightness used when on when blinking / triggers are active.
>>>
>>> We could then add poll support on this new user_brightness
>>> file, thus avoiding the problem with the extra cpu-load on
>>> notifications on blinking / triggers.
>>
>> I agree that user_brightness allows to solve the issues you raised
>> about inconsistent write and read brightness' semantics
>> (which is not that painful IMHO).
>>
>> Reporting non-user brightness changes on user_brightness file
>> doesn't sound reasonable though.
>
> The changes I'm interested in are user brightness changes they
> are just not done through sysfs, but through a hardwired hotkey,
> they are however very much done by the user.
Ah, so this file name would be misleading especially taking into account
the context in which "user" is used in kernel, which predominantly
means "userspace", e.g. copy_to_user(), copy_from_user().
>> Also, how would we read the
>> brightness set by the firmware? We'd have to read brightness
>> file, so still two files would have to be opened which is
>> a second drawback of this approach.
>
> No, look carefully at the definition of the read behavior
> I plan to put in the ABI doc:
OK, "user" was what confused me. So in this case changes made
by the firmware even if in a result of user activity
(pressing hardware key) obviously cannot be treated similarly
to the changes made from the userspace context.
Unless you're able to give references to the kernel code which
contradict my judgement.
>
> "Reading this file will return the actual led brightness
> when not blinking and no triggers are active; reading this
> file will return the brightness used when the led is on
> when blinking or triggers are active."
This is unnecessarily entangled. Blinking means timer trigger
is active.
> So for e.g. the backlit keyboard case reading this single
> file will return the actual brightness of the backlight,
> since this does not involve blinking or triggers.
>
> Basically the idea is that the user_brightness file
> will have the semantics which IMHO the brightness file
> itself should have had from the beginning, but which
> we can't change now due to ABI reasons.
And in fact introducing user_brightness file would indeed
fix that shortcoming. However without providing notifications
of hw brightness changes on it.
>> Having no difference in this area between the two approaches
>> I'm still in favour of the read-only file for notifying
>> brightness changes procured by hardware.
>
> That brings back the needing 2 fds problem; and does
> not solve userspace not being able to reliably read
> the led on brightness when blinking or using triggers.
>
> And this also has the issue that one is doing poll() on
> one fd to detect changes on another fd,
It is not necessarily true. We can treat the polling on
hw_brightness_change file as a means to detect brightness
changes procured by hardware and we can read that brightness
by executing read on this same fd. It could return -ENODATA
if no such an event has occurred so far.
> which is completely
> unheard of in any kernel API, so I still vote NACK for the
> entire idea of having a different file purely for notifying
> changes. The way unix defines poll to work means that the
> poll() and read() must be on the same fd, anything else
> does not make sense.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH v3 2/2] arm64: Wire up iommu_dma_{map, unmap}_resource()
From: Catalin Marinas @ 2016-11-13 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <706f6bc883775206d661f38d9c1cbaa4cc4d04b7.1478887214.git.robin.murphy@arm.com>
On Fri, Nov 11, 2016 at 06:27:35PM +0000, Robin Murphy wrote:
> With no coherency to worry about, just plug'em straight in.
>
> CC: Catalin Marinas <catalin.marinas@arm.com>
> CC: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> arch/arm64/mm/dma-mapping.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 3f74d0d98de6..5cd0a383b14b 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -796,6 +796,8 @@ static struct dma_map_ops iommu_dma_ops = {
> .sync_single_for_device = __iommu_sync_single_for_device,
> .sync_sg_for_cpu = __iommu_sync_sg_for_cpu,
> .sync_sg_for_device = __iommu_sync_sg_for_device,
> + .map_resource = iommu_dma_map_resource,
> + .unmap_resource = iommu_dma_unmap_resource,
> .dma_supported = iommu_dma_supported,
> .mapping_error = iommu_dma_mapping_error,
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
I guess these two patches would go in via the iommu tree.
--
Catalin
^ permalink raw reply
* [PATCH v3 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Catalin Marinas @ 2016-11-13 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7d54803d32968be46a1a525d7160feb13af72f00.1478887214.git.robin.murphy@arm.com>
On Fri, Nov 11, 2016 at 06:27:34PM +0000, Robin Murphy wrote:
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c5ab8667e6f2..8b745260b3bc 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -432,13 +432,12 @@ int iommu_dma_mmap(struct page **pages, size_t size, struct vm_area_struct *vma)
> return ret;
> }
>
> -dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
> - unsigned long offset, size_t size, int prot)
> +dma_addr_t __iommu_dma_map(struct device *dev, phys_addr_t phys,
> + size_t size, int prot)
This should be static.
--
Catalin
^ permalink raw reply
* Applied "ASoC: mioa701_wm9713: add missing white space in dev_err message" to the asoc tree
From: Mark Brown @ 2016-11-13 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112163025.4801-1-colin.king@canonical.com>
The patch
ASoC: mioa701_wm9713: add missing white space in dev_err message
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 28ab49bf9bd9185d8221392a5195bb6c989ed7c7 Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king@canonical.com>
Date: Sat, 12 Nov 2016 16:30:25 +0000
Subject: [PATCH] ASoC: mioa701_wm9713: add missing white space in dev_err
message
There is a missing whitespace in the dev_err message between
"will" and "lead". Add the whitespace.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/pxa/mioa701_wm9713.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/pxa/mioa701_wm9713.c b/sound/soc/pxa/mioa701_wm9713.c
index d1661fa6ee08..0fe0abec8fc4 100644
--- a/sound/soc/pxa/mioa701_wm9713.c
+++ b/sound/soc/pxa/mioa701_wm9713.c
@@ -187,7 +187,7 @@ static int mioa701_wm9713_probe(struct platform_device *pdev)
mioa701.dev = &pdev->dev;
rc = devm_snd_soc_register_card(&pdev->dev, &mioa701);
if (!rc)
- dev_warn(&pdev->dev, "Be warned that incorrect mixers/muxes setup will"
+ dev_warn(&pdev->dev, "Be warned that incorrect mixers/muxes setup will "
"lead to overheating and possible destruction of your device."
" Do not use without a good knowledge of mio's board design!\n");
return rc;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 1/6] Documentation: dt-bindings: Document STM32 ADC DT bindings
From: Jonathan Cameron @ 2016-11-13 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478794738-28933-2-git-send-email-fabrice.gasnier@st.com>
On 10/11/16 16:18, Fabrice Gasnier wrote:
> This patch adds documentation of device tree bindings for the STM32 ADC.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> .../devicetree/bindings/iio/adc/st,stm32-adc.txt | 85 ++++++++++++++++++++++
> 1 file changed, 85 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> new file mode 100644
> index 0000000..8b20c23
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> @@ -0,0 +1,85 @@
> +STMicroelectronics STM32 ADC device driver
> +
> +STM32 ADC is a successive approximation analog-to-digital converter.
> +It has several multiplexed input channels. Conversions can be performed
> +in single, continuous, scan or discontinuous mode. Result of the ADC is
> +stored in a left-aligned or right-aligned 32-bit data register.
> +Conversions can be launched in software or using hardware triggers.
> +
> +The analog watchdog feature allows the application to detect if the input
> +voltage goes beyond the user-defined, higher or lower thresholds.
> +
> +Each STM32 ADC block can have up to 3 ADC instances.
> +
> +Each instance supports two contexts to manage conversions, each one has its
> +own configurable sequence and trigger:
> +- regular conversion can be done in sequence, running in background
> +- injected conversions have higher priority, and so have the ability to
> + interrupt regular conversion sequence (either triggered in SW or HW).
> + Regular sequence is resumed, in case it has been interrupted.
> +
> +Contents of a stm32 adc root node:
> +-----------------------------------
> +Required properties:
> +- compatible: Should be "st,stm32f4-adc-core".
> +- reg: Offset and length of the ADC block register set.
> +- interrupts: Must contain the interrupt for ADC block.
> +- clocks: Clock for the analog circuitry (common to all ADCs).
> +- clock-names: Must be "adc".
> +- interrupt-controller: Identifies the controller node as interrupt-parent
> +- vref-supply: Phandle to the vref input analog reference voltage.
> +- #interrupt-cells = <1>;
> +- #address-cells = <1>;
> +- #size-cells = <0>;
> +
> +Optional properties:
> +- A pinctrl state named "default" for each ADC channel may be defined to set
> + inX ADC pins in mode of operation for analog input on external pin.
> +
> +Contents of a stm32 adc child node:
> +-----------------------------------
> +An ADC block node should contain at least one subnode, representing an
> +ADC instance available on the machine.
> +
> +Required properties:
> +- compatible: Should be "st,stm32f4-adc".
> +- reg: Offset of ADC instance in ADC block (e.g. may be 0x0, 0x100, 0x200).
> +- st,adc-channels: List of single-ended channels muxed for this ADC.
> + It can have up to 16 channels, numbered from 0 to 15 (resp. for in0..in15).
> +- interrupt-parent: Phandle to the parent interrupt controller.
> +- interrupts: IRQ Line for the ADC (e.g. may be 0 for adc at 0, 1 for adc at 100 or
> + 2 for adc at 200).
> +- #io-channel-cells = <1>: See the IIO bindings section "IIO consumers" in
> + Documentation/devicetree/bindings/iio/iio-bindings.txt
> +
> +Optional properties:
> +- clocks: Input clock private to this ADC instance.
I'm a little surprised this is optional. Perhaps some text here explaining why?
> +
> +Example:
> + adc: adc at 40012000 {
> + compatible = "st,stm32f4-adc-core";
> + reg = <0x40012000 0x400>;
> + interrupts = <18>;
> + clocks = <&rcc 0 168>;
> + clock-names = "adc";
> + vref-supply = <®_vref>;
> + interrupt-controller;
> + pinctrl-names = "default";
> + pinctrl-0 = <&adc3_in8_pin>;
> +
> + #interrupt-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + adc at 0 {
> + compatible = "st,stm32f4-adc";
> + #io-channel-cells = <1>;
> + reg = <0x0>;
> + clocks = <&rcc 0 168>;
> + interrupt-parent = <&adc>;
> + interrupts = <0>;
> + st,adc-channels = <8>;
> + };
> + ...
> + other adc child nodes follow...
> + };
>
^ permalink raw reply
* [PATCH 0/2] mmc: allow mmc_alloc_host() and tmio_mmc_host_alloc()
From: Greg Kroah-Hartman @ 2016-11-13 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNAThxsE3QW4EdPUyxmxbnt_PPjeogi8Fox5AHkddsuu-Sg@mail.gmail.com>
On Fri, Nov 11, 2016 at 12:19:05PM +0900, Masahiro Yamada wrote:
> 2016-11-10 22:35 GMT+09:00 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> > On Thu, Nov 10, 2016 at 10:24:21PM +0900, Masahiro Yamada wrote:
> >>
> >> sdhci_alloc_host() returns an error pointer when it fails.
> >> but mmc_alloc_host() cannot.
> >>
> >> This series allow to propagate a proper error code
> >> when host-allocation fails.
> >
> > Why? What can we really do about the error except give up? Why does
> > having a explicit error value make any difference to the caller, they
> > can't do anything different, right?
>
>
> The error code is shown in the console, like
>
> probe of 5a000000.sdhc failed with error -12
>
>
> The proper error code will give a clue why the driver failed to probe.
Can't the mmc core show the reason once, and not require each and every
individual driver to show/say the same thing? All a driver needs to
know is if it worked or didn't work. Every time it didn't work, it
needs to unwind stuff and then recover properly.
The drivers do not do different things based on what type of error
happened, as they don't care at all.
So I strongly suggest leaving it simple, as it is today, as this makes
drivers simpler, they don't have to duplicate the same type of error
reporting all over the place, and it's easy to audit for.
It also makes it so that large patchsets that touch every driver like
this are not needed at all.
> > I suggest just leaving it as-is, it's simple, and you don't have to mess
> > with PTR_ERR() anywhere.
>
>
> Why?
>
> Most of driver just give up probing for any error,
> but we still do ERR_PTR()/PTR_ERR() here and there.
> I think this patch is the same pattern.
I think we need to get rid of more of the ERR_PTR() stuff, as again,
it's useless. All we need to know is an error happened, that's it.
> If a function returns NULL on failure, we need to think about
> "what is the most common failure case".
>
> Currently, MMC drivers assume -ENOMEM is the best
> fit for mmc_alloc_host(), but the assumption is fragile.
>
> Already, mmc_alloc_host() calls a function
> that returns not only -ENOMEM, but also -ENOSPC.
>
> In the future, some other failure cases might be
> added to mmc_alloc_host().
>
> Once we decide the API returns an error pointer,
> drivers just propagate the return value from the API.
> This is much more stable implementation.
Again, no, it makes more work for the different drivers, duplicates code
all over the place, and really doesn't help any user, or developer, out
at all.
Just have the mmc core properly log what went wrong, and all should be
fine.
Again, keep it simple, that's the best policy for the kernel, and
really, most software :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH devicetree/next] ARM: BCM5301X: Add DT for TP-LINK Archer C9 V1
From: Rafał Miłecki @ 2016-11-13 10:12 UTC (permalink / raw)
To: linux-arm-kernel
From: Rafa? Mi?ecki <rafal@milecki.pl>
It's BCM4709A0 based device with 16 MiB flash, 128 MiB of RAM and two
PCIe based on-PCB BCM4360 chipsets.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts | 114 ++++++++++++++++++++++
2 files changed, 115 insertions(+)
create mode 100644 arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 837703a..7a52a9f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -87,6 +87,7 @@ dtb-$(CONFIG_ARCH_BCM_5301X) += \
bcm4709-buffalo-wxr-1900dhp.dtb \
bcm4709-netgear-r7000.dtb \
bcm4709-netgear-r8000.dtb \
+ bcm4709-tplink-archer-c9-v1.dtb \
bcm47094-dlink-dir-885l.dtb \
bcm47094-luxul-xwr-3100.dtb \
bcm47094-netgear-r8500.dtb \
diff --git a/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts b/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
new file mode 100644
index 0000000..9a92c24
--- /dev/null
+++ b/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
@@ -0,0 +1,114 @@
+/*
+ * Copyright (C) 2016 Rafa? Mi?ecki <rafal@milecki.pl>
+ *
+ * Licensed under the ISC license.
+ */
+
+/dts-v1/;
+
+#include "bcm4709.dtsi"
+
+/ {
+ compatible = "tplink,archer-c9-v1", "brcm,bcm4709", "brcm,bcm4708";
+ model = "TP-LINK Archer C9 V1";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlycon";
+ };
+
+ memory {
+ reg = <0x00000000 0x08000000>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ lan {
+ label = "bcm53xx:blue:lan";
+ gpios = <&chipcommon 1 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-off";
+ };
+
+ wps {
+ label = "bcm53xx:blue:wps";
+ gpios = <&chipcommon 2 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-off";
+ };
+
+ 2ghz {
+ label = "bcm53xx:blue:2ghz";
+ gpios = <&chipcommon 4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-off";
+ };
+
+ 5ghz {
+ label = "bcm53xx:blue:5ghz";
+ gpios = <&chipcommon 5 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-off";
+ };
+
+ usb3 {
+ label = "bcm53xx:blue:usb3";
+ gpios = <&chipcommon 6 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-off";
+ };
+
+ usb2 {
+ label = "bcm53xx:blue:usb2";
+ gpios = <&chipcommon 7 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-off";
+ };
+
+ wan-blue {
+ label = "bcm53xx:blue:wan";
+ gpios = <&chipcommon 14 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-off";
+ };
+
+ wan-amber {
+ label = "bcm53xx:amber:wan";
+ gpios = <&chipcommon 15 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-off";
+ };
+
+ power {
+ label = "bcm53xx:blue:power";
+ gpios = <&chipcommon 18 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "default-on";
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wps {
+ label = "WPS";
+ linux,code = <KEY_WPS_BUTTON>;
+ gpios = <&chipcommon 0 GPIO_ACTIVE_LOW>;
+ };
+
+ restart {
+ label = "Reset";
+ linux,code = <KEY_RESTART>;
+ gpios = <&chipcommon 3 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&usb2 {
+ vcc-gpio = <&chipcommon 13 GPIO_ACTIVE_HIGH>;
+};
+
+&usb3 {
+ vcc-gpio = <&chipcommon 12 GPIO_ACTIVE_HIGH>;
+};
+
+&spi_nor {
+ status = "okay";
+};
--
2.10.1
^ permalink raw reply related
* [PATCH 7/10] clk: sunxi-ng: Add A13 CCU driver
From: Chen-Yu Tsai @ 2016-11-13 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1fe10e9ca64dce0a06a2d83693cbaf6ee3a76bde.1478625788.git-series.maxime.ripard@free-electrons.com>
On Wed, Nov 9, 2016 at 1:23 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/clk/sunxi-ng/Kconfig | 10 +-
> drivers/clk/sunxi-ng/Makefile | 1 +-
> drivers/clk/sunxi-ng/ccu-sun5i-a13.c | 681 ++++++++++++++++++++++++++++-
> 3 files changed, 692 insertions(+), 0 deletions(-)
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun5i-a13.c
I'm not sure what to make of this one. Presumably this is the same as the A10s,
with some bits (TS, HDMI, I2S, GPS) removed. BTW you kept the GPS reset control
in this one.
Hans and others have said and IIRC proven that the sun5i is the same die, with
some exposing more peripherals than others. Wouldn't it make sense to use the
same CCU driver for all of them? It's not like Allwinner actually disabled the
clock control or hardware block.
If you don't like it, perhaps you can share the same set of definitions, but
have separate lists of what clocks are registered, for each SoC variant. That
would at least cut down on code size and the effort to maintain 3 copies of
almost the exact same thing.
I guess the same applies to the GR8 CCU driver patch. And the comments from
the previous (A10s CCU driver) patch applies to both.
Let me know what you think.
Regards
ChenYu
^ permalink raw reply
* Three different LED brightnesses (was Re: PM regression with LED changes in next-20161109)
From: Hans de Goede @ 2016-11-13 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113091054.GA17790@amd>
Hi,
On 13-11-16 10:10, Pavel Machek wrote:
> On Sat 2016-11-12 09:03:42, Hans de Goede wrote:
>> Hi,
>>
>> On 11-11-16 23:12, Pavel Machek wrote:
>>> Hi!
>>>
>>> Reason #1:
>>>
>>>>>> Hmm. So userland can read the LED state, and it can get _some_ value
>>>>>> back, but it can not know if it is current state or not.
>>
>> That is not correct, the current behavior for eading the brightness
>> atrribute is to always return the current state.
>
> No. (Because some hardware can't get back current state of
> hardware-controlled leds, and because of blinking).
>
>>>> Why a dedicated file? Are we going to mirror brightness here
>>>> wrt r/w (show/store) behavior ? If not userspace now needs
>>>> 2 open fds which is not really nice. If we are and we are
>>>> not going to use poll for something else on brightness itself
>>>> then why not just poll directly on brightness ?
>>>
>>> Reason #1 is above.
>>
>> See my reply above.
>>
>>> Reason #2 is "if userspace sees brightness file, it can not know if
>>> the notifications on change actually work or not".
>>
>> If it needs to know that it can simply check the kernel version.
>
> No. Because in case of hardware blinking we can't provide poll()
> functionality.
We have already decided that we do not want to wakeup poll()
on blinking because it causes to many wakeups, and there is
no use-case for waking poll for blinking (or for triggers).
> Plus, saying "simply check the kernel version" simply means you should
> not be submitting patches to kernel... at all. (Hint... it also does
> not work.)
Lets keep things civil please.
>>> Reason #3 is that you broke Tony's system. Polling does not make sense
>>> when trigger such as "CPU in use" is active.
>>
>> Have you seen v4 of my patch? It fixes this while keeping the
>> polling on the brightness attribute itself, it basically goes
>> back (more or less) to v1 of my patch which did not have this
>> problem. I never wanted notification of trigger / blinking
>> changes because I already feared Tony's problem would happen.
>
> Have you seen v67123 of my latest facebook post? It explains why you
> are completely wrong.
Lets keep things civil please.
>>> Reason #4 is that there are really two brightnesses:
>>>
>>> 1) maximum brightness trigger is going to use
>>>
>>> 2) current brightness
>>>
>>> Currently writing to "brightness" file changes 1), but reading returns
>>> 2) when available.
>>
>> Right and Jacek has already said that we cannot change the
>> reading behavior on the brightness file because of ABI concerns.
>
> Until there's user that actually reads that, ABI can be fixed. Given
> that it basically returns random value,
Jacek has pretty much nacked fixing this because of ABI concerns,
so I see no use in further discussing changing the read behavior
of the existing brightness sysfs attribute.
>>> So, feel free to propose better interface. One that solves #1..#4
>>> above.
>>
>> Proposal 1:
>>
>> v4 of my patch, see the list. It solves all but #4, which
>> is out of scope for my patch, feel free to submit a patch to
>> solve #4 (with a new sysfs attr).
>
> NAK on that. (And it does not solve #1 and #2 at least.)
>
>> Proposal 2:
>>
>> Add a new "user_brightness" file, which shows the last brightness
>> as set by the user, this would show the read behavior we really
>> want of brightness: show the real brightness when not blinking /
>> triggers are active, show the brightness used when on when
>> blinking / triggers are active.
>
> No, that's just adding more mess on the system.
>
> Here's better proposal:
>
> brightness (write): what we do today. (Mess, but too late to change it)
> (read): -Esomething or what we do today (if someone
> acutally uses it)
As said Jacek has already nacked any changes to read behavior.
> (poll): -Esomething
Making poll() on sysfs attributes return -Esomething is not possible,
the internal sysfs API does not allow this.
> current_brightness (write): -Esomething, or maybe change brightness
> for triggers that can work with that
> (read, poll): if the current trigger can get current
> state of led, do it, otherwise -Esomething...
> or maybe file should be simply hidden from sysfs.
So write is -EINVAL and read is the same as what brightness currently does,
so I see no use in introducing this new file.
Also this reintroduces all the issues of v2 of my poll() patch since the
CPU load problem is not actually in waking up userspace, it is in
even checking if there are any userspace waiters. TLDR we simply cannot
have poll behavior where we need to try and wakeup userspace on
every blink / every time a trigger triggers.
> trigger_max_brightness (read,write): change the maximum brightness for
> a trigger.
> (poll): -Esomething
The write behavior here is the same as what brightness currently does
and the read behavior is that of what I suggested for user_brightness,
minus that you've not definied the read behavior for when no trigger /
blinking is active.
In itself I would be fine with this file to work around the read
behavior of trigger_max_brightness, but you've not solved the
polling problem.
We've 2 sorts of brightness really:
1) transient brightness, aka current brightness, when blinking or
triggers are used this will switch many times a second
between off and some on level.
2) non-transient brightness, for non blinking leds this is the
actual brightness, for blinking leds this is the brightness
level used when the led is on.
Now we want to have a sysfs attribute reflecting 2, so that
userspace can poll on that, both for my use-case as well as so
that userspace process a can detect changes made by writing to
the brightness file by process b.
So maybe we need to simply call the new attribute
non_transient_brightness instead of user_brightness?
> If you have hardware changing the brightness behind kernel's back,
> that should be modelled as a trigger. Userspace should know
> there's hardware changing it autonomously ... there should be
> "hardware-keylight-brightness" trigger, probably impossible to change
> (depends on hardware behaviour).
>
> On thinkpad, for example, for many LEDs kernel can select either
> "hardware drives the LED", but then current_brightness is unavailable,
> or "kernel drives the LED", but then hardware does not touch the led
> at all.
Whether or not the hardware changing the brightness behind kernel's
should be modeled as a trigger is really outside of the scope of
this discussion, as it is not related to the issues with the
brightness atrribute / polling on the brightness attribute.
Regards,
Hans
^ permalink raw reply
* [PATCH 6/10] clk: sunxi-ng: Add A10s CCU driver
From: Chen-Yu Tsai @ 2016-11-13 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2110deed00d33bdb557efebe8f988976fbf5a440.1478625788.git-series.maxime.ripard@free-electrons.com>
On Wed, Nov 9, 2016 at 1:23 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/clk/sunxi-ng/Kconfig | 10 +-
> drivers/clk/sunxi-ng/Makefile | 1 +-
> drivers/clk/sunxi-ng/ccu-sun5i-a10s.c | 755 +++++++++++++++++++++++++++-
> drivers/clk/sunxi-ng/ccu-sun5i.h | 129 +++++-
> 4 files changed, 895 insertions(+), 0 deletions(-)
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun5i-a10s.c
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun5i.h
>
> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
> index 8454c6e3dd65..e2becd36a1f9 100644
> --- a/drivers/clk/sunxi-ng/Kconfig
> +++ b/drivers/clk/sunxi-ng/Kconfig
> @@ -64,6 +64,16 @@ config SUN50I_A64_CCU
> select SUNXI_CCU_PHASE
> default ARM64 && ARCH_SUNXI
>
> +config SUN5I_A10S_CCU
> + bool "Support for the Allwinner A10s CCM"
> + select SUNXI_CCU_DIV
> + select SUNXI_CCU_NK
> + select SUNXI_CCU_NKM
> + select SUNXI_CCU_NM
> + select SUNXI_CCU_MP
> + select SUNXI_CCU_PHASE
> + default MACH_SUN5I
> +
> config SUN6I_A31_CCU
> bool "Support for the Allwinner A31/A31s CCU"
> select SUNXI_CCU_DIV
> diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
> index 24fbc6e5deb8..79e9a166dc83 100644
> --- a/drivers/clk/sunxi-ng/Makefile
> +++ b/drivers/clk/sunxi-ng/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_SUNXI_CCU_MP) += ccu_mp.o
>
> # SoC support
> obj-$(CONFIG_SUN50I_A64_CCU) += ccu-sun50i-a64.o
> +obj-$(CONFIG_SUN5I_A10S_CCU) += ccu-sun5i-a10s.o
> obj-$(CONFIG_SUN6I_A31_CCU) += ccu-sun6i-a31.o
> obj-$(CONFIG_SUN8I_A23_CCU) += ccu-sun8i-a23.o
> obj-$(CONFIG_SUN8I_A33_CCU) += ccu-sun8i-a33.o
> diff --git a/drivers/clk/sunxi-ng/ccu-sun5i-a10s.c b/drivers/clk/sunxi-ng/ccu-sun5i-a10s.c
> new file mode 100644
> index 000000000000..94d9a5cbf60b
> --- /dev/null
> +++ b/drivers/clk/sunxi-ng/ccu-sun5i-a10s.c
> @@ -0,0 +1,755 @@
> +/*
> + * Copyright (c) 2016 Maxime Ripard. All rights reserved.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program 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.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/of_address.h>
> +
> +#include "ccu_common.h"
> +#include "ccu_reset.h"
> +
> +#include "ccu_div.h"
> +#include "ccu_gate.h"
> +#include "ccu_mp.h"
> +#include "ccu_mult.h"
> +#include "ccu_nk.h"
> +#include "ccu_nkm.h"
> +#include "ccu_nkmp.h"
> +#include "ccu_nm.h"
> +#include "ccu_phase.h"
> +
> +#include "ccu-sun5i.h"
> +
> +static struct ccu_nkmp pll_core_clk = {
> + .enable = BIT(31),
> + .n = _SUNXI_CCU_MULT_OFFSET(8, 5, 0),
> + .k = _SUNXI_CCU_MULT(4, 2),
> + .m = _SUNXI_CCU_DIV(0, 2),
> + .p = _SUNXI_CCU_DIV(16, 2),
> + .common = {
> + .reg = 0x000,
> + .hw.init = CLK_HW_INIT("pll-core",
> + "hosc",
> + &ccu_nkmp_ops,
> + 0),
> + },
> +};
> +
> +/*
> + * The Audio PLL is supposed to have 4 outputs: 3 fixed factors from
> + * the base (2x, 4x and 8x), and one variable divider (the one true
> + * pll audio).
> + *
> + * We don't have any need for the variable divider for now, so we just
> + * hardcode it to match with the clock names
> + */
> +#define SUN5I_PLL_AUDIO_REG 0x008
> +
> +static struct ccu_nm pll_audio_base_clk = {
> + .enable = BIT(31),
> + .n = _SUNXI_CCU_MULT_OFFSET(8, 7, 0),
> + .m = _SUNXI_CCU_DIV_OFFSET(0, 5, 0),
Nit: a note explaining that the datasheet is wrong would be nice.
> + .common = {
> + .reg = 0x008,
> + .hw.init = CLK_HW_INIT("pll-audio-base",
> + "hosc",
> + &ccu_nm_ops,
> + 0),
> + },
> +};
> +
> +static struct ccu_mult pll_video0_clk = {
> + .enable = BIT(31),
> + .mult = _SUNXI_CCU_MULT_OFFSET_MIN_MAX(0, 7, 0, 9, 127),
> + .frac = _SUNXI_CCU_FRAC(BIT(15), BIT(14),
> + 270000000, 297000000),
> + .common = {
> + .reg = 0x010,
> + .features = CCU_FEATURE_FRACTIONAL,
> + .hw.init = CLK_HW_INIT("pll-video0",
> + "osc3M",
> + &ccu_mult_ops,
> + 0),
> + },
> +};
> +
> +static struct ccu_nkmp pll_ve_clk = {
> + .enable = BIT(31),
> + .n = _SUNXI_CCU_MULT_OFFSET(8, 5, 0),
> + .k = _SUNXI_CCU_MULT(4, 2),
> + .m = _SUNXI_CCU_DIV(0, 2),
> + .p = _SUNXI_CCU_DIV(16, 2),
Any chance we'll support the bypass switch on this one?
> + .common = {
> + .reg = 0x018,
> + .hw.init = CLK_HW_INIT("pll-ve",
> + "hosc",
> + &ccu_nkmp_ops,
> + 0),
> + },
> +};
> +
> +static struct ccu_nk pll_ddr_base_clk = {
> + .enable = BIT(31),
> + .n = _SUNXI_CCU_MULT_OFFSET(8, 5, 0),
> + .k = _SUNXI_CCU_MULT(4, 2),
> + .common = {
> + .reg = 0x020,
> + .hw.init = CLK_HW_INIT("pll-ddr-base",
> + "hosc",
> + &ccu_nk_ops,
> + 0),
> + },
> +};
> +
> +static SUNXI_CCU_M(pll_ddr_clk, "pll-ddr", "pll-ddr-base", 0x020, 0, 2, 0);
Maybe we should set CLK_IS_CRITICAL on this one as well... in case the
bootloader uses pll-periph for mbus, and none of the dram gates are enabled.
> +
> +static struct ccu_div pll_ddr_other_clk = {
> + .div = _SUNXI_CCU_DIV_FLAGS(16, 2, CLK_DIVIDER_POWER_OF_TWO),
> +
> + .common = {
> + .reg = 0x020,
> + .hw.init = CLK_HW_INIT("pll-ddr-other", "pll-ddr-base",
> + &ccu_div_ops,
> + 0),
> + },
> +};
> +
> +static struct ccu_nk pll_periph_clk = {
> + .enable = BIT(31),
> + .n = _SUNXI_CCU_MULT_OFFSET(8, 5, 0),
> + .k = _SUNXI_CCU_MULT(4, 2),
> + .fixed_post_div = 2,
> + .common = {
> + .reg = 0x028,
> + .features = CCU_FEATURE_FIXED_POSTDIV,
> + .hw.init = CLK_HW_INIT("pll-periph",
> + "hosc",
> + &ccu_nk_ops,
> + 0),
> + },
> +};
> +
> +static struct ccu_mult pll_video1_clk = {
> + .enable = BIT(31),
> + .mult = _SUNXI_CCU_MULT_OFFSET_MIN_MAX(0, 7, 0, 9, 127),
> + .frac = _SUNXI_CCU_FRAC(BIT(15), BIT(14),
> + 270000000, 297000000),
> + .common = {
> + .reg = 0x030,
> + .features = CCU_FEATURE_FRACTIONAL,
> + .hw.init = CLK_HW_INIT("pll-video1",
> + "osc3M",
> + &ccu_mult_ops,
> + 0),
> + },
> +};
> +
> +static SUNXI_CCU_GATE(hosc_clk, "hosc", "osc24M", 0x050, BIT(0), 0);
Why the extra "hosc" clock here? You should probably just internalize "osc24M".
> +
> +#define SUN5I_AHB_REG 0x054
> +static const char * const cpu_parents[] = { "osc32k", "hosc",
> + "pll-core" , "pll-periph" };
> +static const struct ccu_mux_fixed_prediv cpu_predivs[] = {
> + { .index = 3, .div = 3, },
> +};
> +static struct ccu_mux cpu_clk = {
> + .mux = {
> + .shift = 16,
> + .width = 2,
> + .fixed_predivs = cpu_predivs,
> + .n_predivs = ARRAY_SIZE(cpu_predivs),
> + },
> + .common = {
> + .reg = 0x054,
> + .features = CCU_FEATURE_FIXED_PREDIV,
> + .hw.init = CLK_HW_INIT_PARENTS("cpu",
> + cpu_parents,
> + &ccu_mux_ops,
> + CLK_IS_CRITICAL),
> + }
> +};
> +
> +static SUNXI_CCU_M(axi_clk, "axi", "cpu", 0x054, 0, 2, 0);
> +
> +static const char * const ahb_parents[] = { "axi" , "cpu", "pll-periph" };
> +static struct ccu_div ahb_clk = {
> + .div = _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
> + .mux = _SUNXI_CCU_MUX(6, 2),
There's a fixed /2 pre-divider on pll-periph.
> +
> + .common = {
> + .reg = 0x054,
> + .hw.init = CLK_HW_INIT_PARENTS("ahb",
> + ahb_parents,
> + &ccu_div_ops,
> + 0),
> + },
> +};
> +
> +static struct clk_div_table apb0_div_table[] = {
> + { .val = 0, .div = 2 },
> + { .val = 1, .div = 2 },
> + { .val = 2, .div = 4 },
> + { .val = 3, .div = 8 },
> + { /* Sentinel */ },
> +};
> +static SUNXI_CCU_DIV_TABLE(apb0_clk, "apb0", "ahb",
> + 0x054, 8, 2, apb0_div_table, 0);
> +
> +static const char * const apb1_parents[] = { "hosc", "pll-periph", "osc32k" };
> +static SUNXI_CCU_MP_WITH_MUX(apb1_clk, "apb1", apb1_parents, 0x058,
> + 0, 5, /* M */
> + 16, 2, /* P */
> + 24, 2, /* mux */
> + 0);
> +
> +static SUNXI_CCU_GATE(axi_dram_clk, "axi-dram", "axi",
> + 0x05c, BIT(0), 0);
> +
> +static SUNXI_CCU_GATE(ahb_otg_clk, "ahb-otg", "ahb",
> + 0x060, BIT(0), 0);
> +static SUNXI_CCU_GATE(ahb_ehci_clk, "ahb-ehci", "ahb",
> + 0x060, BIT(1), 0);
> +static SUNXI_CCU_GATE(ahb_ohci_clk, "ahb-ohci", "ahb",
> + 0x060, BIT(2), 0);
> +static SUNXI_CCU_GATE(ahb_ss_clk, "ahb-ss", "ahb",
> + 0x060, BIT(5), 0);
> +static SUNXI_CCU_GATE(ahb_dma_clk, "ahb-dma", "ahb",
> + 0x060, BIT(6), 0);
> +static SUNXI_CCU_GATE(ahb_bist_clk, "ahb-bist", "ahb",
> + 0x060, BIT(6), 0);
> +static SUNXI_CCU_GATE(ahb_mmc0_clk, "ahb-mmc0", "ahb",
> + 0x060, BIT(8), 0);
> +static SUNXI_CCU_GATE(ahb_mmc1_clk, "ahb-mmc1", "ahb",
> + 0x060, BIT(9), 0);
> +static SUNXI_CCU_GATE(ahb_mmc2_clk, "ahb-mmc2", "ahb",
> + 0x060, BIT(10), 0);
> +static SUNXI_CCU_GATE(ahb_nand_clk, "ahb-nand", "ahb",
> + 0x060, BIT(13), 0);
> +static SUNXI_CCU_GATE(ahb_sdram_clk, "ahb-sdram", "ahb",
> + 0x060, BIT(14), CLK_IS_CRITICAL);
> +static SUNXI_CCU_GATE(ahb_emac_clk, "ahb-emac", "ahb",
> + 0x060, BIT(17), 0);
> +static SUNXI_CCU_GATE(ahb_ts_clk, "ahb-ts", "ahb",
> + 0x060, BIT(18), 0);
> +static SUNXI_CCU_GATE(ahb_spi0_clk, "ahb-spi0", "ahb",
> + 0x060, BIT(20), 0);
> +static SUNXI_CCU_GATE(ahb_spi1_clk, "ahb-spi1", "ahb",
> + 0x060, BIT(21), 0);
> +static SUNXI_CCU_GATE(ahb_spi2_clk, "ahb-spi2", "ahb",
> + 0x060, BIT(22), 0);
> +static SUNXI_CCU_GATE(ahb_gps_clk, "ahb-gps", "ahb",
> + 0x060, BIT(26), 0);
> +static SUNXI_CCU_GATE(ahb_hstimer_clk, "ahb-hstimer", "ahb",
> + 0x060, BIT(28), 0);
> +
> +static SUNXI_CCU_GATE(ahb_ve_clk, "ahb-ve", "ahb",
> + 0x064, BIT(0), 0);
> +static SUNXI_CCU_GATE(ahb_tve_clk, "ahb-tve", "ahb",
> + 0x064, BIT(2), 0);
> +static SUNXI_CCU_GATE(ahb_lcd_clk, "ahb-lcd", "ahb",
> + 0x064, BIT(4), 0);
> +static SUNXI_CCU_GATE(ahb_csi_clk, "ahb-csi", "ahb",
> + 0x064, BIT(8), 0);
> +static SUNXI_CCU_GATE(ahb_hdmi_clk, "ahb-hdmi", "ahb",
> + 0x064, BIT(11), 0);
> +static SUNXI_CCU_GATE(ahb_de_be_clk, "ahb-de-be", "ahb",
> + 0x064, BIT(12), 0);
> +static SUNXI_CCU_GATE(ahb_de_fe_clk, "ahb-de-fe", "ahb",
> + 0x064, BIT(14), 0);
> +static SUNXI_CCU_GATE(ahb_iep_clk, "ahb-iep", "ahb",
> + 0x064, BIT(19), 0);
> +static SUNXI_CCU_GATE(ahb_gpu_clk, "ahb-gpu", "ahb",
> + 0x064, BIT(20), 0);
> +
> +static SUNXI_CCU_GATE(apb0_codec_clk, "apb0-codec", "apb0",
> + 0x068, BIT(0), 0);
> +static SUNXI_CCU_GATE(apb0_i2s_clk, "apb0-i2s", "apb0",
> + 0x068, BIT(3), 0);
> +static SUNXI_CCU_GATE(apb0_pio_clk, "apb0-pio", "apb0",
> + 0x068, BIT(5), 0);
> +static SUNXI_CCU_GATE(apb0_ir_clk, "apb0-ir", "apb0",
> + 0x068, BIT(6), 0);
> +static SUNXI_CCU_GATE(apb0_keypad_clk, "apb0-keypad", "apb0",
> + 0x068, BIT(10), 0);
> +
> +static SUNXI_CCU_GATE(apb1_i2c0_clk, "apb1-i2c0", "apb1",
> + 0x06c, BIT(0), 0);
> +static SUNXI_CCU_GATE(apb1_i2c1_clk, "apb1-i2c1", "apb1",
> + 0x06c, BIT(1), 0);
> +static SUNXI_CCU_GATE(apb1_i2c2_clk, "apb1-i2c2", "apb1",
> + 0x06c, BIT(2), 0);
> +static SUNXI_CCU_GATE(apb1_uart0_clk, "apb1-uart0", "apb1",
> + 0x06c, BIT(16), 0);
> +static SUNXI_CCU_GATE(apb1_uart1_clk, "apb1-uart1", "apb1",
> + 0x06c, BIT(17), 0);
> +static SUNXI_CCU_GATE(apb1_uart2_clk, "apb1-uart2", "apb1",
> + 0x06c, BIT(18), 0);
> +static SUNXI_CCU_GATE(apb1_uart3_clk, "apb1-uart3", "apb1",
> + 0x06c, BIT(19), 0);
> +
> +static const char * const mod0_default_parents[] = { "hosc", "pll-periph",
> + "pll-ddr-other" };
> +static SUNXI_CCU_MP_WITH_MUX_GATE(nand_clk, "nand", mod0_default_parents, 0x080,
> + 0, 4, /* M */
> + 16, 2, /* P */
> + 24, 2, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static SUNXI_CCU_MP_WITH_MUX_GATE(mmc0_clk, "mmc0", mod0_default_parents, 0x088,
> + 0, 4, /* M */
> + 16, 2, /* P */
> + 24, 2, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static SUNXI_CCU_MP_WITH_MUX_GATE(mmc1_clk, "mmc1", mod0_default_parents, 0x08c,
> + 0, 4, /* M */
> + 16, 2, /* P */
> + 24, 2, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static SUNXI_CCU_MP_WITH_MUX_GATE(mmc2_clk, "mmc2", mod0_default_parents, 0x090,
> + 0, 4, /* M */
> + 16, 2, /* P */
> + 24, 2, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static SUNXI_CCU_MP_WITH_MUX_GATE(ts_clk, "ts", mod0_default_parents, 0x098,
> + 0, 4, /* M */
> + 16, 2, /* P */
> + 24, 2, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static SUNXI_CCU_MP_WITH_MUX_GATE(ss_clk, "ss", mod0_default_parents, 0x09c,
> + 0, 4, /* M */
> + 16, 2, /* P */
> + 24, 2, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static SUNXI_CCU_MP_WITH_MUX_GATE(spi0_clk, "spi0", mod0_default_parents, 0x0a0,
> + 0, 4, /* M */
> + 16, 2, /* P */
> + 24, 2, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static SUNXI_CCU_MP_WITH_MUX_GATE(spi1_clk, "spi1", mod0_default_parents, 0x0a4,
> + 0, 4, /* M */
> + 16, 2, /* P */
> + 24, 2, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static SUNXI_CCU_MP_WITH_MUX_GATE(spi2_clk, "spi2", mod0_default_parents, 0x0a8,
> + 0, 4, /* M */
> + 16, 2, /* P */
> + 24, 2, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static SUNXI_CCU_MP_WITH_MUX_GATE(ir_clk, "ir", mod0_default_parents, 0x0b0,
> + 0, 4, /* M */
> + 16, 2, /* P */
> + 24, 2, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static const char * const i2s_parents[] = { "pll-audio-8x", "pll-audio-4x",
> + "pll-audio-2x", "pll-audio" };
> +static SUNXI_CCU_MUX_WITH_GATE(i2s_clk, "i2s", i2s_parents,
> + 0x0b8, 16, 2, BIT(31), 0);
CLK_SET_RATE_PARENT please.
> +
> +static const char * const keypad_parents[] = { "hosc", "losc"};
> +static const u8 keypad_table[] = { 0, 2 };
> +static struct ccu_mp keypad_clk = {
> + .enable = BIT(31),
> + .m = _SUNXI_CCU_DIV(8, 5),
> + .p = _SUNXI_CCU_DIV(20, 2),
> + .mux = _SUNXI_CCU_MUX_TABLE(24, 2, keypad_table),
> +
> + .common = {
> + .reg = 0x0c4,
> + .hw.init = CLK_HW_INIT_PARENTS("keypad",
> + keypad_parents,
> + &ccu_mp_ops,
> + 0),
> + },
> +};
> +
> +static SUNXI_CCU_GATE(usb_ohci_clk, "usb-ohci", "pll-periph",
> + 0x0cc, BIT(6), 0);
> +static SUNXI_CCU_GATE(usb_phy0_clk, "usb-phy0", "pll-periph",
> + 0x0cc, BIT(8), 0);
> +static SUNXI_CCU_GATE(usb_phy1_clk, "usb-phy1", "pll-periph",
> + 0x0cc, BIT(9), 0);
> +
> +static const char * const gps_parents[] = { "hosc", "pll-periph",
> + "pll-video1", "pll-ve" };
> +static SUNXI_CCU_M_WITH_MUX_GATE(gps_clk, "gps", gps_parents,
> + 0x0d0, 0, 3, 24, 2, BIT(31), 0);
> +
> +static SUNXI_CCU_GATE(dram_ve_clk, "dram-ve", "pll-ddr",
> + 0x100, BIT(0), 0);
> +static SUNXI_CCU_GATE(dram_csi_clk, "dram-csi", "pll-ddr",
> + 0x100, BIT(1), 0);
> +static SUNXI_CCU_GATE(dram_ts_clk, "dram-ts", "pll-ddr",
> + 0x100, BIT(3), 0);
> +static SUNXI_CCU_GATE(dram_tve_clk, "dram-tve", "pll-ddr",
> + 0x100, BIT(5), 0);
> +static SUNXI_CCU_GATE(dram_de_fe_clk, "dram-de-fe", "pll-ddr",
> + 0x100, BIT(25), 0);
> +static SUNXI_CCU_GATE(dram_de_be_clk, "dram-de-be", "pll-ddr",
> + 0x100, BIT(26), 0);
> +static SUNXI_CCU_GATE(dram_ace_clk, "dram-ace", "pll-ddr",
> + 0x100, BIT(29), 0);
> +static SUNXI_CCU_GATE(dram_iep_clk, "dram-iep", "pll-ddr",
> + 0x100, BIT(31), 0);
> +
> +static const char * const de_parents[] = { "pll-video0", "pll-video1",
> + "pll-ddr-other" };
> +static SUNXI_CCU_M_WITH_MUX_GATE(de_be_clk, "de-be", de_parents,
> + 0x104, 0, 4, 24, 2, BIT(31), 0);
> +
> +static SUNXI_CCU_M_WITH_MUX_GATE(de_fe_clk, "de-fe", de_parents,
> + 0x10c, 0, 4, 24, 2, BIT(31), 0);
> +
> +static const char * const tcon_parents[] = { "pll-video0", "pll-video1",
> + "pll-video0-2x", "pll-video1-2x" };
> +static SUNXI_CCU_MUX_WITH_GATE(tcon_ch0_clk, "tcon-ch0-sclk", tcon_parents,
> + 0x118, 24, 2, BIT(31), 0);
CLK_SET_RATE_PARENT?
> +
> +static SUNXI_CCU_M_WITH_MUX_GATE(tcon_ch1_sclk2_clk, "tcon-ch1-sclk2",
> + tcon_parents,
> + 0x12c, 0, 4, 24, 2, BIT(31), 0);
CLK_SET_RATE_PARENT?
> +
> +static SUNXI_CCU_M_WITH_GATE(tcon_ch1_sclk1_clk, "tcon-ch1-sclk1", "tcon-ch1-sclk2",
> + 0x12c, 11, 1, BIT(15), 0);
CLK_SET_RATE_PARENT?
> +
> +static const char * const csi_parents[] = { "hosc", "pll-video0", "pll-video1",
> + "pll-video0-2x", "pll-video1-2x" };
> +static const u8 csi_table[] = { 0, 1, 2, 5, 6 };
> +static SUNXI_CCU_M_WITH_MUX_TABLE_GATE(csi_clk, "csi",
> + csi_parents, csi_table,
> + 0x134, 0, 5, 24, 2, BIT(31), 0);
Do you know if CSI needs to change the module clock?
> +
> +static SUNXI_CCU_GATE(ve_clk, "ve", "pll-ve",
> + 0x13c, BIT(31), 0);
CLK_SET_RATE_PARENT?
> +
> +static SUNXI_CCU_GATE(codec_clk, "codec", "pll-audio",
> + 0x140, BIT(31), 0);
CLK_SET_RATE_PARENT?
> +
> +static SUNXI_CCU_GATE(avs_clk, "avs", "hosc",
> + 0x144, BIT(31), 0);
> +
> +static const char * const hdmi_parents[] = { "pll-video0", "pll-video0-2x" };
> +static const u8 hdmi_table[] = { 0, 2 };
> +static SUNXI_CCU_M_WITH_MUX_TABLE_GATE(hdmi_clk, "hdmi",
> + hdmi_parents, hdmi_table,
> + 0x150, 0, 4, 24, 2, BIT(31), 0);
CLK_SET_RATE_PARENT?
> +
> +static const char * const gpu_parents[] = { "pll-video0", "pll-ve",
> + "pll-ddr-other", "pll-video1",
> + "pll-video1-2x" };
> +static SUNXI_CCU_M_WITH_MUX_GATE(gpu_clk, "gpu", gpu_parents,
> + 0x154, 0, 4, 24, 3, BIT(31), 0);
> +
> +static const char * const mbus_parents[] = { "hosc", "pll-periph", "pll-ddr" };
> +static SUNXI_CCU_MP_WITH_MUX_GATE(mbus_clk, "mbus", mbus_parents,
> + 0x15c, 0, 4, 16, 2, 24, 2, BIT(31), CLK_IS_CRITICAL);
> +
> +static SUNXI_CCU_GATE(iep_clk, "iep", "de-be",
> + 0x160, BIT(31), 0);
> +
> +static struct ccu_common *sun5i_a10s_ccu_clks[] = {
> + &hosc_clk.common,
> + &pll_core_clk.common,
> + &pll_audio_base_clk.common,
> + &pll_video0_clk.common,
> + &pll_ve_clk.common,
> + &pll_ddr_base_clk.common,
> + &pll_ddr_clk.common,
> + &pll_ddr_other_clk.common,
> + &pll_periph_clk.common,
> + &pll_video1_clk.common,
> + &cpu_clk.common,
> + &axi_clk.common,
> + &ahb_clk.common,
> + &apb0_clk.common,
> + &apb1_clk.common,
> + &axi_dram_clk.common,
> + &ahb_otg_clk.common,
> + &ahb_ehci_clk.common,
> + &ahb_ohci_clk.common,
> + &ahb_ss_clk.common,
> + &ahb_dma_clk.common,
> + &ahb_bist_clk.common,
> + &ahb_mmc0_clk.common,
> + &ahb_mmc1_clk.common,
> + &ahb_mmc2_clk.common,
> + &ahb_nand_clk.common,
> + &ahb_sdram_clk.common,
> + &ahb_emac_clk.common,
> + &ahb_ts_clk.common,
> + &ahb_spi0_clk.common,
> + &ahb_spi1_clk.common,
> + &ahb_spi2_clk.common,
> + &ahb_gps_clk.common,
> + &ahb_hstimer_clk.common,
> + &ahb_ve_clk.common,
> + &ahb_tve_clk.common,
> + &ahb_lcd_clk.common,
> + &ahb_csi_clk.common,
> + &ahb_hdmi_clk.common,
> + &ahb_de_be_clk.common,
> + &ahb_de_fe_clk.common,
> + &ahb_iep_clk.common,
> + &ahb_gpu_clk.common,
> + &apb0_codec_clk.common,
> + &apb0_i2s_clk.common,
> + &apb0_pio_clk.common,
> + &apb0_ir_clk.common,
> + &apb0_keypad_clk.common,
> + &apb1_i2c0_clk.common,
> + &apb1_i2c1_clk.common,
> + &apb1_i2c2_clk.common,
> + &apb1_uart0_clk.common,
> + &apb1_uart1_clk.common,
> + &apb1_uart2_clk.common,
> + &apb1_uart3_clk.common,
> + &nand_clk.common,
> + &mmc0_clk.common,
> + &mmc1_clk.common,
> + &mmc2_clk.common,
> + &ts_clk.common,
> + &ss_clk.common,
> + &spi0_clk.common,
> + &spi1_clk.common,
> + &spi2_clk.common,
> + &ir_clk.common,
> + &i2s_clk.common,
> + &keypad_clk.common,
> + &usb_ohci_clk.common,
> + &usb_phy0_clk.common,
> + &usb_phy1_clk.common,
> + &gps_clk.common,
> + &dram_ve_clk.common,
> + &dram_csi_clk.common,
> + &dram_ts_clk.common,
> + &dram_tve_clk.common,
> + &dram_de_fe_clk.common,
> + &dram_de_be_clk.common,
> + &dram_ace_clk.common,
> + &dram_iep_clk.common,
> + &de_be_clk.common,
> + &de_fe_clk.common,
> + &tcon_ch0_clk.common,
> + &tcon_ch1_sclk2_clk.common,
> + &tcon_ch1_sclk1_clk.common,
> + &csi_clk.common,
> + &ve_clk.common,
> + &codec_clk.common,
> + &avs_clk.common,
> + &hdmi_clk.common,
> + &gpu_clk.common,
> + &mbus_clk.common,
> + &iep_clk.common,
> +};
> +
> +static CLK_FIXED_FACTOR(osc3M_clk, "osc3M", "hosc", 8, 1, 0);
> +/* We hardcode the divider to 4 for now */
> +static CLK_FIXED_FACTOR(pll_audio_clk, "pll-audio",
> + "pll-audio-base", 4, 1, CLK_SET_RATE_PARENT);
> +static CLK_FIXED_FACTOR(pll_audio_2x_clk, "pll-audio-2x",
> + "pll-audio-base", 2, 1, CLK_SET_RATE_PARENT);
> +static CLK_FIXED_FACTOR(pll_audio_4x_clk, "pll-audio-4x",
> + "pll-audio-base", 1, 1, CLK_SET_RATE_PARENT);
> +static CLK_FIXED_FACTOR(pll_audio_8x_clk, "pll-audio-8x",
> + "pll-audio-base", 1, 2, CLK_SET_RATE_PARENT);
> +static CLK_FIXED_FACTOR(pll_video0_2x_clk, "pll-video0-2x",
> + "pll-video0", 1, 2, CLK_SET_RATE_PARENT);
> +static CLK_FIXED_FACTOR(pll_video1_2x_clk, "pll-video1-2x",
> + "pll-video1", 1, 2, CLK_SET_RATE_PARENT);
> +
> +static struct clk_hw_onecell_data sun5i_a10s_hw_clks = {
> + .hws = {
> + [CLK_HOSC] = &hosc_clk.common.hw,
> + [CLK_OSC3M] = &osc3M_clk.hw,
> + [CLK_PLL_CORE] = &pll_core_clk.common.hw,
> + [CLK_PLL_AUDIO_BASE] = &pll_audio_base_clk.common.hw,
> + [CLK_PLL_AUDIO] = &pll_audio_clk.hw,
> + [CLK_PLL_AUDIO_2X] = &pll_audio_2x_clk.hw,
> + [CLK_PLL_AUDIO_4X] = &pll_audio_4x_clk.hw,
> + [CLK_PLL_AUDIO_8X] = &pll_audio_8x_clk.hw,
> + [CLK_PLL_VIDEO0] = &pll_video0_clk.common.hw,
> + [CLK_PLL_VIDEO0_2X] = &pll_video0_2x_clk.hw,
> + [CLK_PLL_VE] = &pll_ve_clk.common.hw,
> + [CLK_PLL_DDR_BASE] = &pll_ddr_base_clk.common.hw,
> + [CLK_PLL_DDR] = &pll_ddr_clk.common.hw,
> + [CLK_PLL_DDR_OTHER] = &pll_ddr_other_clk.common.hw,
> + [CLK_PLL_PERIPH] = &pll_periph_clk.common.hw,
> + [CLK_PLL_VIDEO1] = &pll_video1_clk.common.hw,
> + [CLK_PLL_VIDEO1_2X] = &pll_video1_2x_clk.hw,
> + [CLK_CPU] = &cpu_clk.common.hw,
> + [CLK_AXI] = &axi_clk.common.hw,
> + [CLK_AHB] = &ahb_clk.common.hw,
> + [CLK_APB0] = &apb0_clk.common.hw,
> + [CLK_APB1] = &apb1_clk.common.hw,
> + [CLK_DRAM_AXI] = &axi_dram_clk.common.hw,
> + [CLK_AHB_OTG] = &ahb_otg_clk.common.hw,
> + [CLK_AHB_EHCI] = &ahb_ehci_clk.common.hw,
> + [CLK_AHB_OHCI] = &ahb_ohci_clk.common.hw,
> + [CLK_AHB_SS] = &ahb_ss_clk.common.hw,
> + [CLK_AHB_DMA] = &ahb_dma_clk.common.hw,
> + [CLK_AHB_BIST] = &ahb_bist_clk.common.hw,
> + [CLK_AHB_MMC0] = &ahb_mmc0_clk.common.hw,
> + [CLK_AHB_MMC1] = &ahb_mmc1_clk.common.hw,
> + [CLK_AHB_MMC2] = &ahb_mmc2_clk.common.hw,
> + [CLK_AHB_NAND] = &ahb_nand_clk.common.hw,
> + [CLK_AHB_SDRAM] = &ahb_sdram_clk.common.hw,
> + [CLK_AHB_EMAC] = &ahb_emac_clk.common.hw,
> + [CLK_AHB_TS] = &ahb_ts_clk.common.hw,
> + [CLK_AHB_SPI0] = &ahb_spi0_clk.common.hw,
> + [CLK_AHB_SPI1] = &ahb_spi1_clk.common.hw,
> + [CLK_AHB_SPI2] = &ahb_spi2_clk.common.hw,
> + [CLK_AHB_GPS] = &ahb_gps_clk.common.hw,
> + [CLK_AHB_HSTIMER] = &ahb_hstimer_clk.common.hw,
> + [CLK_AHB_VE] = &ahb_ve_clk.common.hw,
> + [CLK_AHB_TVE] = &ahb_tve_clk.common.hw,
> + [CLK_AHB_LCD] = &ahb_lcd_clk.common.hw,
> + [CLK_AHB_CSI] = &ahb_csi_clk.common.hw,
> + [CLK_AHB_HDMI] = &ahb_hdmi_clk.common.hw,
> + [CLK_AHB_DE_BE] = &ahb_de_be_clk.common.hw,
> + [CLK_AHB_DE_FE] = &ahb_de_fe_clk.common.hw,
> + [CLK_AHB_IEP] = &ahb_iep_clk.common.hw,
> + [CLK_AHB_GPU] = &ahb_gpu_clk.common.hw,
> + [CLK_APB0_CODEC] = &apb0_codec_clk.common.hw,
> + [CLK_APB0_I2S] = &apb0_i2s_clk.common.hw,
> + [CLK_APB0_PIO] = &apb0_pio_clk.common.hw,
> + [CLK_APB0_IR] = &apb0_ir_clk.common.hw,
> + [CLK_APB0_KEYPAD] = &apb0_keypad_clk.common.hw,
> + [CLK_APB1_I2C0] = &apb1_i2c0_clk.common.hw,
> + [CLK_APB1_I2C1] = &apb1_i2c1_clk.common.hw,
> + [CLK_APB1_I2C2] = &apb1_i2c2_clk.common.hw,
> + [CLK_APB1_UART0] = &apb1_uart0_clk.common.hw,
> + [CLK_APB1_UART1] = &apb1_uart1_clk.common.hw,
> + [CLK_APB1_UART2] = &apb1_uart2_clk.common.hw,
> + [CLK_APB1_UART3] = &apb1_uart3_clk.common.hw,
> + [CLK_NAND] = &nand_clk.common.hw,
> + [CLK_MMC0] = &mmc0_clk.common.hw,
> + [CLK_MMC1] = &mmc1_clk.common.hw,
> + [CLK_MMC2] = &mmc2_clk.common.hw,
> + [CLK_TS] = &ts_clk.common.hw,
> + [CLK_SS] = &ss_clk.common.hw,
> + [CLK_SPI0] = &spi0_clk.common.hw,
> + [CLK_SPI1] = &spi1_clk.common.hw,
> + [CLK_SPI2] = &spi2_clk.common.hw,
> + [CLK_IR] = &ir_clk.common.hw,
> + [CLK_I2S] = &i2s_clk.common.hw,
> + [CLK_KEYPAD] = &keypad_clk.common.hw,
> + [CLK_USB_OHCI] = &usb_ohci_clk.common.hw,
> + [CLK_USB_PHY0] = &usb_phy0_clk.common.hw,
> + [CLK_USB_PHY1] = &usb_phy1_clk.common.hw,
> + [CLK_GPS] = &gps_clk.common.hw,
> + [CLK_DRAM_VE] = &dram_ve_clk.common.hw,
> + [CLK_DRAM_CSI] = &dram_csi_clk.common.hw,
> + [CLK_DRAM_TS] = &dram_ts_clk.common.hw,
> + [CLK_DRAM_TVE] = &dram_tve_clk.common.hw,
> + [CLK_DRAM_DE_FE] = &dram_de_fe_clk.common.hw,
> + [CLK_DRAM_DE_BE] = &dram_de_be_clk.common.hw,
> + [CLK_DRAM_ACE] = &dram_ace_clk.common.hw,
> + [CLK_DRAM_IEP] = &dram_iep_clk.common.hw,
> + [CLK_DE_BE] = &de_be_clk.common.hw,
> + [CLK_DE_FE] = &de_fe_clk.common.hw,
> + [CLK_TCON_CH0] = &tcon_ch0_clk.common.hw,
> + [CLK_TCON_CH1_SCLK] = &tcon_ch1_sclk2_clk.common.hw,
> + [CLK_TCON_CH1] = &tcon_ch1_sclk1_clk.common.hw,
> + [CLK_CSI] = &csi_clk.common.hw,
> + [CLK_VE] = &ve_clk.common.hw,
> + [CLK_CODEC] = &codec_clk.common.hw,
> + [CLK_AVS] = &avs_clk.common.hw,
> + [CLK_HDMI] = &hdmi_clk.common.hw,
> + [CLK_GPU] = &gpu_clk.common.hw,
> + [CLK_MBUS] = &mbus_clk.common.hw,
> + [CLK_IEP] = &iep_clk.common.hw,
> + },
> + .num = CLK_NUMBER,
> +};
> +
> +static struct ccu_reset_map sun5i_a10s_ccu_resets[] = {
> + [RST_USB_PHY0] = { 0x0cc, BIT(0) },
> + [RST_USB_PHY1] = { 0x0cc, BIT(1) },
> +
> + [RST_GPS] = { 0x0d0, BIT(30) },
> +
> + [RST_DE_BE] = { 0x104, BIT(30) },
> +
> + [RST_DE_FE] = { 0x10c, BIT(30) },
> +
> + [RST_TVE] = { 0x118, BIT(29) },
> + [RST_LCD] = { 0x118, BIT(30) },
> +
> + [RST_CSI] = { 0x134, BIT(30) },
> +
> + [RST_VE] = { 0x13c, BIT(0) },
> +
> + [RST_GPU] = { 0x154, BIT(30) },
> +
> + [RST_IEP] = { 0x160, BIT(30) },
> +};
> +
> +static const struct sunxi_ccu_desc sun5i_a10s_ccu_desc = {
> + .ccu_clks = sun5i_a10s_ccu_clks,
> + .num_ccu_clks = ARRAY_SIZE(sun5i_a10s_ccu_clks),
> +
> + .hw_clks = &sun5i_a10s_hw_clks,
> +
> + .resets = sun5i_a10s_ccu_resets,
> + .num_resets = ARRAY_SIZE(sun5i_a10s_ccu_resets),
> +};
> +
> +static void __init sun5i_a10s_ccu_setup(struct device_node *node)
> +{
> + void __iomem *reg;
> + u32 val;
> +
> + reg = of_io_request_and_map(node, 0, of_node_full_name(node));
> + if (IS_ERR(reg)) {
> + pr_err("%s: Could not map the clock registers\n",
> + of_node_full_name(node));
> + return;
> + }
> +
> + /* Force the PLL-Audio-1x divider to 4 */
> + val = readl(reg + SUN5I_PLL_AUDIO_REG);
> + val &= ~GENMASK(19, 16);
> + writel(val | (3 << 16), reg + SUN5I_PLL_AUDIO_REG);
> +
> + /*
> + * Use the peripheral PLL as the AHB parent, instead of CPU /
> + * AXI which have rate changes due to cpufreq.
> + *
> + * This is especially a big deal for the HS timer whose parent
> + * clock is AHB.
> + */
> + val = readl(reg + SUN5I_AHB_REG);
> + val &= ~GENMASK(7, 6);
> + writel(val | (2 << 6), reg + SUN5I_AHB_REG);
> +
> + sunxi_ccu_probe(node, reg, &sun5i_a10s_ccu_desc);
> +}
> +CLK_OF_DECLARE(sun5i_a10s_ccu, "allwinner,sun5i-a10s-ccu",
> + sun5i_a10s_ccu_setup);
> diff --git a/drivers/clk/sunxi-ng/ccu-sun5i.h b/drivers/clk/sunxi-ng/ccu-sun5i.h
> new file mode 100644
> index 000000000000..43f2ce3e9e6e
> --- /dev/null
> +++ b/drivers/clk/sunxi-ng/ccu-sun5i.h
> @@ -0,0 +1,129 @@
> +/*
> + * Copyright 2016 Maxime Ripard
> + *
> + * Maxime Ripard <maxime.ripard@free-electrons.com>
> + *
> + * This program 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 program 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.
> + */
> +
> +#ifndef _CCU_SUN5I_H_
> +#define _CCU_SUN5I_H_
> +
> +#include <dt-bindings/clock/sun5i-ccu.h>
> +#include <dt-bindings/reset/sun5i-ccu.h>
> +
> +#define CLK_HOSC 1
> +#define CLK_OSC3M 2
> +#define CLK_PLL_CORE 3
> +#define CLK_PLL_AUDIO_BASE 4
> +#define CLK_PLL_AUDIO 5
> +#define CLK_PLL_AUDIO_2X 6
> +#define CLK_PLL_AUDIO_4X 7
> +#define CLK_PLL_AUDIO_8X 8
> +#define CLK_PLL_VIDEO0 9
> +#define CLK_PLL_VIDEO0_2X 10
> +#define CLK_PLL_VE 11
> +#define CLK_PLL_DDR_BASE 12
> +#define CLK_PLL_DDR 13
> +#define CLK_PLL_DDR_OTHER 14
> +#define CLK_PLL_PERIPH 15
> +#define CLK_PLL_VIDEO1 16
> +#define CLK_PLL_VIDEO1_2X 17
> +#define CLK_OSC24M 18
> +#define CLK_CPU 19
> +#define CLK_AXI 20
> +#define CLK_AHB 21
> +#define CLK_APB0 22
> +#define CLK_APB1 23
> +#define CLK_DRAM_AXI 24
> +#define CLK_AHB_OTG 25
> +#define CLK_AHB_EHCI 26
> +#define CLK_AHB_OHCI 27
> +#define CLK_AHB_SS 28
> +#define CLK_AHB_DMA 29
> +#define CLK_AHB_BIST 30
> +#define CLK_AHB_MMC0 31
> +#define CLK_AHB_MMC1 32
> +#define CLK_AHB_MMC2 33
> +#define CLK_AHB_NAND 34
> +#define CLK_AHB_SDRAM 35
> +#define CLK_AHB_EMAC 36
> +#define CLK_AHB_TS 37
> +#define CLK_AHB_SPI0 38
> +#define CLK_AHB_SPI1 39
> +#define CLK_AHB_SPI2 40
> +#define CLK_AHB_GPS 41
> +#define CLK_AHB_HSTIMER 42
> +#define CLK_AHB_VE 43
> +#define CLK_AHB_TVE 44
> +#define CLK_AHB_LCD 45
> +#define CLK_AHB_CSI 46
> +#define CLK_AHB_HDMI 47
> +#define CLK_AHB_DE_BE 48
> +#define CLK_AHB_DE_FE 49
> +#define CLK_AHB_IEP 50
> +#define CLK_AHB_GPU 51
> +#define CLK_APB0_CODEC 52
> +#define CLK_APB0_SPDIF 53
> +#define CLK_APB0_I2S 54
> +#define CLK_APB0_PIO 55
> +#define CLK_APB0_IR 56
> +#define CLK_APB0_KEYPAD 57
> +#define CLK_APB1_I2C0 58
> +#define CLK_APB1_I2C1 59
> +#define CLK_APB1_I2C2 60
> +#define CLK_APB1_UART0 61
> +#define CLK_APB1_UART1 62
> +#define CLK_APB1_UART2 63
> +#define CLK_APB1_UART3 64
> +#define CLK_NAND 65
> +#define CLK_MMC0 66
> +#define CLK_MMC1 67
> +#define CLK_MMC2 68
> +#define CLK_TS 69
> +#define CLK_SS 70
> +#define CLK_CE 71
> +#define CLK_SPI0 72
> +#define CLK_SPI1 73
> +#define CLK_SPI2 74
> +#define CLK_IR 75
> +#define CLK_I2S 76
> +#define CLK_SPDIF 77
> +#define CLK_KEYPAD 78
> +#define CLK_USB_OHCI 79
> +#define CLK_USB_PHY0 80
> +#define CLK_USB_PHY1 81
> +#define CLK_GPS 82
> +#define CLK_DRAM_VE 83
> +#define CLK_DRAM_CSI 84
> +#define CLK_DRAM_TS 85
> +#define CLK_DRAM_TVE 86
> +#define CLK_DRAM_DE_FE 87
> +#define CLK_DRAM_DE_BE 88
> +#define CLK_DRAM_ACE 89
> +#define CLK_DRAM_IEP 90
> +#define CLK_DE_BE 91
> +#define CLK_DE_FE 92
> +#define CLK_TCON_CH0 93
> +#define CLK_TCON_CH1_SCLK 94
> +#define CLK_TCON_CH1 95
> +#define CLK_CSI 96
> +#define CLK_VE 97
> +#define CLK_CODEC 98
> +#define CLK_AVS 99
> +#define CLK_HDMI 100
> +#define CLK_GPU 101
> +#define CLK_MBUS 102
> +#define CLK_IEP 103
> +
> +#define CLK_NUMBER (CLK_IEP + 1)
> +
> +#endif /* _CCU_SUN5I_H_ */
Didn't you already list all the clocks in the device tree bindings header
patch 5?
Regards
ChenYu
^ permalink raw reply
* Applied "ASoC: mioa701_wm9713: add missing white space in dev_err message" to the regulator tree
From: Mark Brown @ 2016-11-13 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112163025.4801-1-colin.king@canonical.com>
The patch
ASoC: mioa701_wm9713: add missing white space in dev_err message
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 28cbed38973cd458e4cdba1df9a240ce739da841 Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king@canonical.com>
Date: Sat, 12 Nov 2016 16:30:25 +0000
Subject: [PATCH] ASoC: mioa701_wm9713: add missing white space in dev_err
message
There is a missing whitespace in the dev_err message between
"will" and "lead". Add the whitespace.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/pxa/mioa701_wm9713.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/pxa/mioa701_wm9713.c b/sound/soc/pxa/mioa701_wm9713.c
index d1661fa6ee08..0fe0abec8fc4 100644
--- a/sound/soc/pxa/mioa701_wm9713.c
+++ b/sound/soc/pxa/mioa701_wm9713.c
@@ -187,7 +187,7 @@ static int mioa701_wm9713_probe(struct platform_device *pdev)
mioa701.dev = &pdev->dev;
rc = devm_snd_soc_register_card(&pdev->dev, &mioa701);
if (!rc)
- dev_warn(&pdev->dev, "Be warned that incorrect mixers/muxes setup will"
+ dev_warn(&pdev->dev, "Be warned that incorrect mixers/muxes setup will "
"lead to overheating and possible destruction of your device."
" Do not use without a good knowledge of mio's board design!\n");
return rc;
--
2.10.2
^ permalink raw reply related
* Three different LED brightnesses (was Re: PM regression with LED changes in next-20161109)
From: Pavel Machek @ 2016-11-13 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3ca04742-6376-5a88-8d10-5b88fcd8f5e5@redhat.com>
On Sat 2016-11-12 09:03:42, Hans de Goede wrote:
> Hi,
>
> On 11-11-16 23:12, Pavel Machek wrote:
> >Hi!
> >
> >Reason #1:
> >
> >>>>Hmm. So userland can read the LED state, and it can get _some_ value
> >>>>back, but it can not know if it is current state or not.
>
> That is not correct, the current behavior for eading the brightness
> atrribute is to always return the current state.
No. (Because some hardware can't get back current state of
hardware-controlled leds, and because of blinking).
> >>Why a dedicated file? Are we going to mirror brightness here
> >>wrt r/w (show/store) behavior ? If not userspace now needs
> >>2 open fds which is not really nice. If we are and we are
> >>not going to use poll for something else on brightness itself
> >>then why not just poll directly on brightness ?
> >
> >Reason #1 is above.
>
> See my reply above.
>
> >Reason #2 is "if userspace sees brightness file, it can not know if
> >the notifications on change actually work or not".
>
> If it needs to know that it can simply check the kernel version.
No. Because in case of hardware blinking we can't provide poll()
functionality.
Plus, saying "simply check the kernel version" simply means you should
not be submitting patches to kernel... at all. (Hint... it also does
not work.)
> >Reason #3 is that you broke Tony's system. Polling does not make sense
> >when trigger such as "CPU in use" is active.
>
> Have you seen v4 of my patch? It fixes this while keeping the
> polling on the brightness attribute itself, it basically goes
> back (more or less) to v1 of my patch which did not have this
> problem. I never wanted notification of trigger / blinking
> changes because I already feared Tony's problem would happen.
Have you seen v67123 of my latest facebook post? It explains why you
are completely wrong.
> >Reason #4 is that there are really two brightnesses:
> >
> >1) maximum brightness trigger is going to use
> >
> >2) current brightness
> >
> >Currently writing to "brightness" file changes 1), but reading returns
> >2) when available.
>
> Right and Jacek has already said that we cannot change the
> reading behavior on the brightness file because of ABI concerns.
Until there's user that actually reads that, ABI can be fixed. Given
that it basically returns random value,
> >So, feel free to propose better interface. One that solves #1..#4
> >above.
>
> Proposal 1:
>
> v4 of my patch, see the list. It solves all but #4, which
> is out of scope for my patch, feel free to submit a patch to
> solve #4 (with a new sysfs attr).
NAK on that. (And it does not solve #1 and #2 at least.)
> Proposal 2:
>
> Add a new "user_brightness" file, which shows the last brightness
> as set by the user, this would show the read behavior we really
> want of brightness: show the real brightness when not blinking /
> triggers are active, show the brightness used when on when
> blinking / triggers are active.
No, that's just adding more mess on the system.
Here's better proposal:
brightness (write): what we do today. (Mess, but too late to change it)
(read): -Esomething or what we do today (if someone
acutally uses it)
(poll): -Esomething
current_brightness (write): -Esomething, or maybe change brightness
for triggers that can work with that
(read, poll): if the current trigger can get current
state of led, do it, otherwise -Esomething...
or maybe file should be simply hidden from sysfs.
trigger_max_brightness (read,write): change the maximum brightness for
a trigger.
(poll): -Esomething
If you have hardware changing the brightness behind kernel's back,
that should be modelled as a trigger. Userspace should know
there's hardware changing it autonomously ... there should be
"hardware-keylight-brightness" trigger, probably impossible to change
(depends on hardware behaviour).
On thinkpad, for example, for many LEDs kernel can select either
"hardware drives the LED", but then current_brightness is unavailable,
or "kernel drives the LED", but then hardware does not touch the led
at all.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161113/0eefaee1/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/2] ARM: dts: rockchip: add the sdmmc pinctrl for rk1108
From: 陈豪 @ 2016-11-13 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479024799-29198-1-git-send-email-jacob-chen@iotwrt.com>
2016-11-13 16:13 GMT+08:00 Jacob Chen <jacob-chen@iotwrt.com>:
> From: Jacob Chen <jacob2.chen@rock-chips.com>
>
> Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
> ---
> arch/arm/boot/dts/rk1108.dtsi | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk1108.dtsi b/arch/arm/boot/dts/rk1108.dtsi
> index 9dccfea..6a06ad7 100644
> --- a/arch/arm/boot/dts/rk1108.dtsi
> +++ b/arch/arm/boot/dts/rk1108.dtsi
> @@ -321,6 +321,31 @@
> input-enable;
> };
>
> + sdmmc {
> + sdmmc_clk: sdmmc-clk {
> + rockchip,pins = <3 RK_PC4 RK_FUNC_1 &pcfg_pull_none_drv_4ma>;
> + };
> +
> + sdmmc_cmd: sdmmc-cmd {
> + rockchip,pins = <3 RK_PC5 RK_FUNC_1 &pcfg_pull_up_drv_4ma>;
> + };
> +
> + sdmmc_cd: sdmmc-cd {
> + rockchip,pins = <0 RK_PA1 RK_FUNC_1 &pcfg_pull_up_drv_4ma>;
> + };
> +
> + sdmmc_bus1: sdmmc-bus1 {
> + rockchip,pins = <3 RK_PC3 RK_FUNC_1 &pcfg_pull_up_drv_4ma>;
> + };
> +
> + sdmmc_bus4: sdmmc-bus4 {
> + rockchip,pins = <3 RK_PC3 RK_FUNC_1 &pcfg_pull_up_drv_4ma>,
> + <3 RK_PC2 RK_FUNC_1 &pcfg_pull_up_drv_4ma>,
> + <3 RK_PC1 RK_FUNC_1 &pcfg_pull_up_drv_4ma>,
> + <3 RK_PC0 RK_FUNC_1 &pcfg_pull_up_drv_4ma>;
> + };
> + };
> +
> i2c1 {
> i2c1_xfer: i2c1-xfer {
> rockchip,pins = <2 RK_PD3 RK_FUNC_1 &pcfg_pull_up>,
> --
> 2.7.4
>
Those patches are based on andy's patch set "Add basic support for
support for Rockchip RK1108 SOC ", assuming he will include
drive-strength functionality in pinctrl.
^ permalink raw reply
* [PATCH 2/2] ARM: dts: rockchip: enable sdmmc for rk1108-evb
From: Jacob Chen @ 2016-11-13 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479024799-29198-1-git-send-email-jacob-chen@iotwrt.com>
From: Jacob Chen <jacob2.chen@rock-chips.com>
This patch add sdmmc support for rk1108-evb, now I can load the rootfs
from sdmmc.
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
---
arch/arm/boot/dts/rk1108-evb.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/rk1108-evb.dts b/arch/arm/boot/dts/rk1108-evb.dts
index 3956cff..cea26e5 100644
--- a/arch/arm/boot/dts/rk1108-evb.dts
+++ b/arch/arm/boot/dts/rk1108-evb.dts
@@ -56,6 +56,18 @@
};
};
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ card-detect-delay = <200>;
+ disable-wp;
+ num-slots = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_clk>, <&sdmmc_cmd>, <&sdmmc_cd>, <&sdmmc_bus4>;
+ status = "okay";
+};
+
&uart0 {
status = "okay";
};
@@ -67,3 +79,12 @@
&uart2 {
status = "okay";
};
+
+&pinctrl {
+
+ sdmmc {
+ sdmmc_pwr: sdmmc-pwr {
+ rockchip,pins = <3 RK_PB7 RK_FUNC_GPIO &pcfg_pull_up_drv_4ma>;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: rockchip: add the sdmmc pinctrl for rk1108
From: Jacob Chen @ 2016-11-13 8:13 UTC (permalink / raw)
To: linux-arm-kernel
From: Jacob Chen <jacob2.chen@rock-chips.com>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
---
arch/arm/boot/dts/rk1108.dtsi | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/rk1108.dtsi b/arch/arm/boot/dts/rk1108.dtsi
index 9dccfea..6a06ad7 100644
--- a/arch/arm/boot/dts/rk1108.dtsi
+++ b/arch/arm/boot/dts/rk1108.dtsi
@@ -321,6 +321,31 @@
input-enable;
};
+ sdmmc {
+ sdmmc_clk: sdmmc-clk {
+ rockchip,pins = <3 RK_PC4 RK_FUNC_1 &pcfg_pull_none_drv_4ma>;
+ };
+
+ sdmmc_cmd: sdmmc-cmd {
+ rockchip,pins = <3 RK_PC5 RK_FUNC_1 &pcfg_pull_up_drv_4ma>;
+ };
+
+ sdmmc_cd: sdmmc-cd {
+ rockchip,pins = <0 RK_PA1 RK_FUNC_1 &pcfg_pull_up_drv_4ma>;
+ };
+
+ sdmmc_bus1: sdmmc-bus1 {
+ rockchip,pins = <3 RK_PC3 RK_FUNC_1 &pcfg_pull_up_drv_4ma>;
+ };
+
+ sdmmc_bus4: sdmmc-bus4 {
+ rockchip,pins = <3 RK_PC3 RK_FUNC_1 &pcfg_pull_up_drv_4ma>,
+ <3 RK_PC2 RK_FUNC_1 &pcfg_pull_up_drv_4ma>,
+ <3 RK_PC1 RK_FUNC_1 &pcfg_pull_up_drv_4ma>,
+ <3 RK_PC0 RK_FUNC_1 &pcfg_pull_up_drv_4ma>;
+ };
+ };
+
i2c1 {
i2c1_xfer: i2c1-xfer {
rockchip,pins = <2 RK_PD3 RK_FUNC_1 &pcfg_pull_up>,
--
2.7.4
^ permalink raw reply related
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