* [PATCH v2] ARM: mvebu: Select corediv clk for all mvebu v7 SoC
From: Gregory CLEMENT @ 2016-09-19 15:48 UTC (permalink / raw)
To: linux-arm-kernel
Since the commit bd3677ff31a3 ("clk: mvebu: Remove corediv clock from
Armada XP"), the corediv clk is no more selected for Armada XP, however
this clock is used for Armada XP using the compatible
armada-370-corediv-clock.
While since commit 1594d568c6e3 ("clk: mvebu: Move corediv config to
mvebu config") Armada 38x and Armada 375 got corediv support again, not
only Armada XP was missed but also Armada 39x.
Actually all the SoC selecting MVEBU_V7 config need this clock:
git grep "\-corediv-clock" arch/arm/boot/dts
arch/arm/boot/dts/armada-370-xp.dtsi: compatible = "marvell,armada-370-corediv-clock";
arch/arm/boot/dts/armada-375.dtsi: compatible = "marvell,armada-375-corediv-clock";
arch/arm/boot/dts/armada-38x.dtsi: compatible = "marvell,armada-380-corediv-clock";
arch/arm/boot/dts/armada-39x.dtsi: compatible = "marvell,armada-390-corediv-clock"
This commit now fixes this behavior by letting MVEBU_V7 select
MVEBU_CLK_COREDIV.
Fixes: bd3677ff31a3 ("clk: mvebu: Remove corediv clock from Armada XP")
Cc: stable at vger.kernel.org
Reported-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
Changelog:
v1 -> v2
- Improve commit log as suggested by Uwe
arch/arm/mach-mvebu/Kconfig | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index f9b6bd306cfe..541647f57192 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -23,6 +23,7 @@ config MACH_MVEBU_V7
select CACHE_L2X0
select ARM_CPU_SUSPEND
select MACH_MVEBU_ANY
+ select MVEBU_CLK_COREDIV
config MACH_ARMADA_370
bool "Marvell Armada 370 boards"
@@ -32,7 +33,6 @@ config MACH_ARMADA_370
select CPU_PJ4B
select MACH_MVEBU_V7
select PINCTRL_ARMADA_370
- select MVEBU_CLK_COREDIV
help
Say 'Y' here if you want your kernel to support boards based
on the Marvell Armada 370 SoC with device tree.
@@ -50,7 +50,6 @@ config MACH_ARMADA_375
select HAVE_SMP
select MACH_MVEBU_V7
select PINCTRL_ARMADA_375
- select MVEBU_CLK_COREDIV
help
Say 'Y' here if you want your kernel to support boards based
on the Marvell Armada 375 SoC with device tree.
@@ -68,7 +67,6 @@ config MACH_ARMADA_38X
select HAVE_SMP
select MACH_MVEBU_V7
select PINCTRL_ARMADA_38X
- select MVEBU_CLK_COREDIV
help
Say 'Y' here if you want your kernel to support boards based
on the Marvell Armada 380/385 SoC with device tree.
--
2.9.3
^ permalink raw reply related
* [PATCH v3 4/8] scpi: Add support for Legacy match table for Amlogic GXBB SoC
From: Sudeep Holla @ 2016-09-19 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473262477-18045-5-git-send-email-narmstrong@baylibre.com>
On 07/09/16 16:34, Neil Armstrong wrote:
> Add new DT match table to setup the is_legacy boolean value across
> the scpi functions.
> Add the Amlogic GXBB SoC compatible for platform and as legacy match entry.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/firmware/arm_scpi.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
> index 6a16100..60a76e63 100644
> --- a/drivers/firmware/arm_scpi.c
> +++ b/drivers/firmware/arm_scpi.c
> @@ -979,6 +979,11 @@ static int scpi_alloc_xfer_list(struct device *dev, struct scpi_chan *ch)
> return 0;
> }
>
> +static const struct of_device_id legacy_scpi_of_match[] = {
> + {.compatible = "amlogic,meson-gxbb-scpi"},
> + {},
> +};
This needs to be documented.
> +
> static int scpi_probe(struct platform_device *pdev)
> {
> int count, idx, ret;
> @@ -991,6 +996,9 @@ static int scpi_probe(struct platform_device *pdev)
> if (!scpi_info)
> return -ENOMEM;
>
> + if (of_match_device(legacy_scpi_of_match, &pdev->dev))
> + scpi_info->is_legacy = true;
> +
> count = of_count_phandle_with_args(np, "mboxes", "#mbox-cells");
> if (count < 0) {
> dev_err(dev, "no mboxes property in '%s'\n", np->full_name);
> @@ -1097,6 +1105,7 @@ err:
>
> static const struct of_device_id scpi_of_match[] = {
> {.compatible = "arm,scpi"},
> + {.compatible = "amlogic,meson-gxbb-scpi"},
I also prefer adding "arm,legacy-scpi". So far AMLogic has followed the
legacy specification except the capabilities. You could use
"amlogic,meson-gxbb-scpi" for that and "arm,legacy-scpi" for the probe
part or we can add the use of "amlogic,meson-gxbb-scpi" later but just
document it now.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2] ARM: mvebu: Select corediv clk for all mvebu v7 SoC
From: Uwe Kleine-König @ 2016-09-19 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919154824.22919-1-gregory.clement@free-electrons.com>
On Mon, Sep 19, 2016 at 05:48:24PM +0200, Gregory CLEMENT wrote:
> Since the commit bd3677ff31a3 ("clk: mvebu: Remove corediv clock from
> Armada XP"), the corediv clk is no more selected for Armada XP, however
> this clock is used for Armada XP using the compatible
> armada-370-corediv-clock.
>
> While since commit 1594d568c6e3 ("clk: mvebu: Move corediv config to
> mvebu config") Armada 38x and Armada 375 got corediv support again, not
> only Armada XP was missed but also Armada 39x.
>
> Actually all the SoC selecting MVEBU_V7 config need this clock:
> git grep "\-corediv-clock" arch/arm/boot/dts
> arch/arm/boot/dts/armada-370-xp.dtsi: compatible = "marvell,armada-370-corediv-clock";
> arch/arm/boot/dts/armada-375.dtsi: compatible = "marvell,armada-375-corediv-clock";
> arch/arm/boot/dts/armada-38x.dtsi: compatible = "marvell,armada-380-corediv-clock";
> arch/arm/boot/dts/armada-39x.dtsi: compatible = "marvell,armada-390-corediv-clock"
>
> This commit now fixes this behavior by letting MVEBU_V7 select
> MVEBU_CLK_COREDIV.
>
> Fixes: bd3677ff31a3 ("clk: mvebu: Remove corediv clock from Armada XP")
> Cc: stable at vger.kernel.org
> Reported-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v3 4/8] scpi: Add support for Legacy match table for Amlogic GXBB SoC
From: Sudeep Holla @ 2016-09-19 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6698b7b9-6ffc-d120-be9c-851ea0be2bf2@arm.com>
On 19/09/16 16:50, Sudeep Holla wrote:
>
>
> On 07/09/16 16:34, Neil Armstrong wrote:
>> Add new DT match table to setup the is_legacy boolean value across
>> the scpi functions.
>> Add the Amlogic GXBB SoC compatible for platform and as legacy match
>> entry.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> drivers/firmware/arm_scpi.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
>> index 6a16100..60a76e63 100644
>> --- a/drivers/firmware/arm_scpi.c
>> +++ b/drivers/firmware/arm_scpi.c
>> @@ -979,6 +979,11 @@ static int scpi_alloc_xfer_list(struct device
>> *dev, struct scpi_chan *ch)
>> return 0;
>> }
>>
>> +static const struct of_device_id legacy_scpi_of_match[] = {
>> + {.compatible = "amlogic,meson-gxbb-scpi"},
>> + {},
>> +};
>
> This needs to be documented.
>
Ignore that I see you have done that in the later patch.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] ASoC: samsung: make audio interface/controller explicitly
From: Randy Li @ 2016-09-19 15:51 UTC (permalink / raw)
To: linux-arm-kernel
It is simple sound card time, we could assign different codec
to a interface without making a specific driver for it. The SPDIF
and I2S interface for Samsung would be possible used by simple-sound-card,
but not sure about the PCM.
Signed-off-by: Randy Li <ayaka@soulik.info>
---
sound/soc/samsung/Kconfig | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 7b722b0..210ce38 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -1,3 +1,7 @@
+menu "SoC Audio for Samsung CPUs"
+
+comment "Common SoC Audio options for Samsung CPUs:"
+
config SND_SOC_SAMSUNG
tristate "ASoC support for Samsung"
depends on (PLAT_SAMSUNG || ARCH_EXYNOS)
@@ -18,18 +22,22 @@ config SND_S3C2412_SOC_I2S
select SND_S3C_I2SV2_SOC
config SND_SAMSUNG_PCM
- tristate
+ tristate "Samsung PCM interface support"
+ depends on SND_SOC_SAMSUNG
config SND_SAMSUNG_AC97
tristate
select SND_SOC_AC97_BUS
+ depends on SND_SOC_SAMSUNG
config SND_SAMSUNG_SPDIF
- tristate
+ tristate "Samsung SPDIF transmitter support"
+ depends on SND_SOC_SAMSUNG
select SND_SOC_SPDIF
config SND_SAMSUNG_I2S
- tristate
+ tristate "Samsung I2S interface support"
+ depends on I2C && SND_SOC_SAMSUNG
config SND_SOC_SAMSUNG_NEO1973_WM8753
tristate "Audio support for Openmoko Neo1973 Smartphones (GTA02)"
@@ -229,3 +237,5 @@ config SND_SOC_ARNDALE_RT5631_ALC5631
depends on SND_SOC_SAMSUNG && I2C
select SND_SAMSUNG_I2S
select SND_SOC_RT5631
+
+endmenu
--
2.7.4
^ permalink raw reply related
* [GIT PULL] Amlogic driver updates for v4.9, 2nd round
From: Arnd Bergmann @ 2016-09-19 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hoa3ql2y7.fsf@baylibre.com>
On Wednesday, September 14, 2016 12:02:40 PM CEST Kevin Hilman wrote:
> Amlogic driver updates for v4.9, 2nd round
> - media: update IR support for newer SoCs
> - firmware: add secure monitor driver
> - net: new stmmac glue driver
> - usb: udd DWC2 support for meson-gxbb
> - clocks: expose more clock IDs for use by DT
> - DT binding updates
>
Pulled into next/late. I think in a case like this, separate
branches would have been a bit nicer, as this branch mixes some things
that are not really related.
> ----------------------------------------------------------------
> Alexander M?ller (6):
> clk: meson: Rename meson8b-clkc.c to reflect gxbb naming convention
> meson: clk: Move register definitions to meson8b.h
> meson: clk: Rename register names according to Amlogic datasheet
> clk: meson: Copy meson8b CLKID defines to private header file
> gxbb: clk: Adjust MESON_GATE macro to be shared with meson8b
> meson: clk: Add support for clock gates
I also note that some of the subject lines are inconsistent regarding
the "clk: meson:" vs "gxbb: clk:" part.
Arnd
^ permalink raw reply
* [GIT PULL 1/3] ARM: soc: exynos: Drivers for v4.9
From: Krzysztof Kozlowski @ 2016-09-19 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2663426.T8oUku18qe@wuerfel>
On Mon, Sep 19, 2016 at 05:02:40PM +0200, Arnd Bergmann wrote:
> On Sunday, September 18, 2016 6:39:46 PM CEST Krzysztof Kozlowski wrote:
> > Samsung drivers/soc update for v4.9:
> > 1. Allow compile testing of exynos-mct clocksource driver on ARM64.
> > 2. Document Exynos5433 PMU compatible (already used by clkout driver and more
> > will be coming soon).
>
> Pulled into next/drivers, thanks
>
> Just for my understanding: why do we need the exynos-mct driver on ARM64
> but not the delay-timer portion of it?
I think we want all of it but Doug's optimization 3252a646aa2c
("clocksource: exynos_mct: Only use 32-bits where possible") is not
ARM64 friendly. One way of dealing with it would be to prepare two
versions of exynos4_read_current_timer(). One reading only lower 32-bit
value for ARMv7 and second (slow) reading lower and upper for ARMv8.
>
> Is there an advantage in using MCT over the architected timer on these
> chips? If so, should we also have a way to use it as the delay timer?
No, there is no real advantage... except that the SoC has some
interesting "characteristics"... The timers are tightly coupled. Very
tightly. I spent a lot of time and failed to boot my ARMv8 board without
some MCT magic.
Best regards,
Krzysztof
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT updates for v4.9, round 2 (for next/late)
From: Arnd Bergmann @ 2016-09-19 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7h37l0kbv9.fsf@baylibre.com>
On Thursday, September 15, 2016 3:59:54 PM CEST Kevin Hilman wrote:
> Here is round 2 of the 64-bit DT changes for v4.9.
>
> Based on my drivers pull (round 2), this is targetted at next/late also
> since the DT patches here are using clock IDs that come from my 2nd
> drivers pull (which itself has merged an immtable branch from the clock
> tree.)
>
Pulled into next/late, thanks!
Arnd
^ permalink raw reply
* [PATCH v26 0/7] arm64: add kdump support
From: James Morse @ 2016-09-19 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_UvFnPtFHggaO6Z_ePuArdchEK1qYWPkkwpcgLus3Epw@mail.gmail.com>
On 16/09/16 21:17, Ard Biesheuvel wrote:
> On 16 September 2016 at 17:04, James Morse <james.morse@arm.com> wrote:
>> Mark, Ard, how does/will reserved-memory work on an APCI only system?
>
> It works by accident, at the moment. We used to ignore both
> /memreserve/s and the /reserved-memory node, but due to some unrelated
> refactoring, we ended up honouring the reserved-memory node when
> booting via UEFI
Okay, so kdump probably shouldn't rely on this behaviour...
For an acpi-only system, we could get reserve_crashkernel() to copy the uefi
memory map into the reserved region, changing the region types for existing
kernel memory to EfiReservedMemoryType (for example) and fixing up the reserved
region boundaries.
This second memory map could then be added alongside the real one in the
DT/chosen, and used in preference the second time we go through uefi_init() in
the crash kernel.
kexec-tools would still need to keep the '/reserved-memory' node for non-uefi
systems.
Doing this doesn't depend on userspace, and means the uefi memory map is still
the one and only true source of memory layout information. If fixing it like
this is valid I don't think it should block kdump.
... I will think about this some more before trying to put it together.
Thanks,
James
^ permalink raw reply
* [PATCH v26 0/7] arm64: add kdump support
From: Ard Biesheuvel @ 2016-09-19 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E00CDC.70403@arm.com>
On 19 September 2016 at 17:05, James Morse <james.morse@arm.com> wrote:
> On 16/09/16 21:17, Ard Biesheuvel wrote:
>> On 16 September 2016 at 17:04, James Morse <james.morse@arm.com> wrote:
>>> Mark, Ard, how does/will reserved-memory work on an APCI only system?
>>
>> It works by accident, at the moment. We used to ignore both
>> /memreserve/s and the /reserved-memory node, but due to some unrelated
>> refactoring, we ended up honouring the reserved-memory node when
>> booting via UEFI
>
> Okay, so kdump probably shouldn't rely on this behaviour...
>
No, but I would still like to keep /reserved-memory node support for
dynamic ranges, since they are guaranteed not to contain anything
'magic' left behind by the firmware. So if we keep /that/, keeping
static allocation support (with validation, as I proposed in the
series I quoted) is only a small step.
--
Ard.
> For an acpi-only system, we could get reserve_crashkernel() to copy the uefi
> memory map into the reserved region, changing the region types for existing
> kernel memory to EfiReservedMemoryType (for example) and fixing up the reserved
> region boundaries.
>
> This second memory map could then be added alongside the real one in the
> DT/chosen, and used in preference the second time we go through uefi_init() in
> the crash kernel.
>
> kexec-tools would still need to keep the '/reserved-memory' node for non-uefi
> systems.
>
> Doing this doesn't depend on userspace, and means the uefi memory map is still
> the one and only true source of memory layout information. If fixing it like
> this is valid I don't think it should block kdump.
>
> ... I will think about this some more before trying to put it together.
>
>
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.
From: Eric Anholt @ 2016-09-19 16:13 UTC (permalink / raw)
To: linux-arm-kernel
The RPi firmware exposes all of the board's GPIO lines through
property calls. Linux chooses to control most lines directly through
the pinctrl driver, but for the FXL6408 GPIO expander on the Pi3, we
need to access them through the firmware.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
.../bindings/gpio/gpio-raspberrypi-firmware.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt b/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
new file mode 100644
index 000000000000..2b635c23a6f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
@@ -0,0 +1,22 @@
+Raspberry Pi power domain driver
+
+Required properties:
+
+- compatible: Should be "raspberrypi,firmware-gpio"
+- gpio-controller: Marks the device node as a gpio controller
+- #gpio-cells: Should be <2> for GPIO number and flags
+- ngpios: Number of GPIO lines to control. See gpio.txt
+- firmware: Reference to the RPi firmware device node
+- raspberrypi,firmware-gpio-offset:
+ Number the firmware uses for the first GPIO line
+ controlled by this driver
+
+Example:
+fxl6408: firmware-gpio-128 {
+ compatible = "raspberrypi,firmware-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ firmware = <&firmware>;
+ ngpios = <8>;
+ raspberrypi,firmware-gpio-offset = <128>;
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] gpio: Add a driver for the Raspberry Pi's firmware GPIO calls.
From: Eric Anholt @ 2016-09-19 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919161314.25858-1-eric@anholt.net>
This driver will be used for accessing the FXL6408 GPIO exander on the
Pi3. We can't drive it directly from Linux because the firmware is
continuously polling one of the expander's lines to do its
undervoltage detection.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
drivers/gpio/Kconfig | 8 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-raspberrypi.c | 159 +++++++++++++++++++++++++++++
include/soc/bcm2835/raspberrypi-firmware.h | 2 +
4 files changed, 170 insertions(+)
create mode 100644 drivers/gpio/gpio-raspberrypi.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index fcbd8e318474..60cf38bb3a44 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -136,6 +136,14 @@ config GPIO_BCM_KONA
help
Turn on GPIO support for Broadcom "Kona" chips.
+config GPIO_RASPBERRYPI
+ tristate "Raspberry Pi firmware-based GPIO access"
+ depends on OF_GPIO && RASPBERRYPI_FIRMWARE && (ARCH_BCM2835 || COMPILE_TEST)
+ help
+ Turns on support for using the Raspberry Pi firmware to
+ control GPIO pins. Used for access to the FXL6408 GPIO
+ expander on the Pi 3.
+
config GPIO_BRCMSTB
tristate "BRCMSTB GPIO support"
default y if (ARCH_BRCMSTB || BMIPS_GENERIC)
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index b3e039c3ae8d..fa10cf4030ad 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_GPIO_ATH79) += gpio-ath79.o
obj-$(CONFIG_GPIO_ASPEED) += gpio-aspeed.o
obj-$(CONFIG_GPIO_AXP209) += gpio-axp209.o
obj-$(CONFIG_GPIO_BCM_KONA) += gpio-bcm-kona.o
+obj-$(CONFIG_GPIO_RASPBERRYPI) += gpio-raspberrypi.o
obj-$(CONFIG_GPIO_BRCMSTB) += gpio-brcmstb.o
obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
obj-$(CONFIG_GPIO_CLPS711X) += gpio-clps711x.o
diff --git a/drivers/gpio/gpio-raspberrypi.c b/drivers/gpio/gpio-raspberrypi.c
new file mode 100644
index 000000000000..233c211f45ba
--- /dev/null
+++ b/drivers/gpio/gpio-raspberrypi.c
@@ -0,0 +1,159 @@
+/*
+ * Copyright ? 2016 Broadcom
+ *
+ * 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 driver supports using the Raspberry Pi's firmware interface to
+ * access its GPIO lines. This lets us interact with the GPIO lines
+ * on the Raspberry Pi 3's FXL6408 expander, which we otherwise have
+ * no way to access (since the firmware is polling the chip
+ * continuously).
+ */
+
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <soc/bcm2835/raspberrypi-firmware.h>
+
+struct rpi_gpio {
+ struct device *dev;
+ struct gpio_chip gc;
+ struct rpi_firmware *firmware;
+
+ /* Offset of our pins in the GET_GPIO_STATE/SET_GPIO_STATE calls. */
+ unsigned offset;
+};
+
+static int rpi_gpio_dir_in(struct gpio_chip *gc, unsigned off)
+{
+ /* We don't have direction control. */
+ return -EINVAL;
+}
+
+static int rpi_gpio_dir_out(struct gpio_chip *gc, unsigned off, int val)
+{
+ /* We don't have direction control. */
+ return -EINVAL;
+}
+
+static void rpi_gpio_set(struct gpio_chip *gc, unsigned off, int val)
+{
+ struct rpi_gpio *rpi = container_of(gc, struct rpi_gpio, gc);
+ u32 packet[2] = { rpi->offset + off, val };
+ int ret;
+
+ ret = rpi_firmware_property(rpi->firmware,
+ RPI_FIRMWARE_SET_GPIO_STATE,
+ &packet, sizeof(packet));
+ if (ret)
+ dev_err(rpi->dev, "Error setting GPIO %d state: %d\n", off, ret);
+}
+
+static int rpi_gpio_get(struct gpio_chip *gc, unsigned off)
+{
+ struct rpi_gpio *rpi = container_of(gc, struct rpi_gpio, gc);
+ u32 packet[2] = { rpi->offset + off, 0 };
+ int ret;
+
+ ret = rpi_firmware_property(rpi->firmware,
+ RPI_FIRMWARE_GET_GPIO_STATE,
+ &packet, sizeof(packet));
+ if (ret) {
+ dev_err(rpi->dev, "Error getting GPIO state: %d\n", ret);
+ return ret;
+ } else if (packet[0]) {
+ dev_err(rpi->dev, "Firmware error getting GPIO state: %d\n",
+ packet[0]);
+ return -EINVAL;
+ } else {
+ return packet[1];
+ }
+}
+
+static int rpi_gpio_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct device_node *fw_node;
+ struct rpi_gpio *rpi;
+ u32 ngpio;
+ int ret;
+
+ rpi = devm_kzalloc(dev, sizeof *rpi, GFP_KERNEL);
+ if (!rpi)
+ return -ENOMEM;
+ rpi->dev = dev;
+
+ fw_node = of_parse_phandle(np, "firmware", 0);
+ if (!fw_node) {
+ dev_err(dev, "Missing firmware node\n");
+ return -ENOENT;
+ }
+
+ rpi->firmware = rpi_firmware_get(fw_node);
+ if (!rpi->firmware)
+ return -EPROBE_DEFER;
+
+ if (of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpio)) {
+ dev_err(dev, "Missing ngpios");
+ return -ENOENT;
+ }
+ if (of_property_read_u32(pdev->dev.of_node,
+ "raspberrypi,firmware-gpio-offset",
+ &rpi->offset)) {
+ dev_err(dev, "Missing raspberrypi,firmware-gpio-offset");
+ return -ENOENT;
+ }
+
+ rpi->gc.label = np->full_name;
+ rpi->gc.owner = THIS_MODULE;
+ rpi->gc.of_node = np;
+ rpi->gc.ngpio = ngpio;
+ rpi->gc.direction_input = rpi_gpio_dir_in;
+ rpi->gc.direction_output = rpi_gpio_dir_out;
+ rpi->gc.get = rpi_gpio_get;
+ rpi->gc.set = rpi_gpio_set;
+ rpi->gc.can_sleep = true;
+
+ ret = gpiochip_add(&rpi->gc);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, rpi);
+
+ return 0;
+}
+
+static int rpi_gpio_remove(struct platform_device *pdev)
+{
+ struct rpi_gpio *rpi = platform_get_drvdata(pdev);
+
+ gpiochip_remove(&rpi->gc);
+
+ return 0;
+}
+
+static const struct of_device_id __maybe_unused rpi_gpio_ids[] = {
+ { .compatible = "raspberrypi,firmware-gpio" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, rpi_gpio_ids);
+
+static struct platform_driver rpi_gpio_driver = {
+ .driver = {
+ .name = "gpio-raspberrypi-firmware",
+ .of_match_table = of_match_ptr(rpi_gpio_ids),
+ },
+ .probe = rpi_gpio_probe,
+ .remove = rpi_gpio_remove,
+};
+module_platform_driver(rpi_gpio_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Eric Anholt <eric@anholt.net>");
+MODULE_DESCRIPTION("Raspberry Pi firmware GPIO driver");
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index 3fb357193f09..671ccd00aea2 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -73,11 +73,13 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_GET_DISPMANX_RESOURCE_MEM_HANDLE = 0x00030014,
RPI_FIRMWARE_GET_EDID_BLOCK = 0x00030020,
RPI_FIRMWARE_GET_DOMAIN_STATE = 0x00030030,
+ RPI_FIRMWARE_GET_GPIO_STATE = 0x00030041,
RPI_FIRMWARE_SET_CLOCK_STATE = 0x00038001,
RPI_FIRMWARE_SET_CLOCK_RATE = 0x00038002,
RPI_FIRMWARE_SET_VOLTAGE = 0x00038003,
RPI_FIRMWARE_SET_TURBO = 0x00038009,
RPI_FIRMWARE_SET_DOMAIN_STATE = 0x00038030,
+ RPI_FIRMWARE_SET_GPIO_STATE = 0x00038041,
/* Dispmanx TAGS */
RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
--
2.9.3
^ permalink raw reply related
* [PATCH 3/3] arm64: Add the Raspberry Pi firmware's interface to the FXL6408.
From: Eric Anholt @ 2016-09-19 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919161314.25858-1-eric@anholt.net>
This gets us hotplug detection of HDMI, so that graphics now works at
boot. Tested with watching the output of xrandr while plugging and
unplugging the HDMI cable.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
index 7841b724e340..2460b47737e9 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
+++ b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
@@ -23,8 +23,25 @@
linux,default-trigger = "default-on";
};
};
+
+ soc {
+ fxl6408: firmware-gpio-128 {
+ compatible = "raspberrypi,firmware-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ firmware = <&firmware>;
+ ngpios = <8>;
+ gpio-line-names = "BT_ON", "WL_ON", "", "LAN_RUN", "HPD_N", "CAM_GPIO0", "CAM_GPIO1", "PWR_LOW_N";
+
+ raspberrypi,firmware-gpio-offset = <128>;
+ };
+ };
};
&uart1 {
status = "okay";
};
+
+&hdmi {
+ hpd-gpios = <&fxl6408 4 GPIO_ACTIVE_HIGH>;
+};
--
2.9.3
^ permalink raw reply related
* [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization
From: Heiko Stuebner @ 2016-09-19 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=VawAOWBF_PoXqSj3oiVgfF8SnCBp56p8F==XsaVLmMcg@mail.gmail.com>
Am Montag, 19. September 2016, 08:15:30 CEST schrieb Doug Anderson:
> Hi,
>
> On Mon, Sep 19, 2016 at 1:44 AM, Andy Yan <andy.yan@rock-chips.com> wrote:
> > The current rk3066a based boards(Rayeager, Bqcurie2, Marsboard) use
> > pwm modulate vdd_logic voltage, but the pwm is default disabled and
> > the pwm pin acts as a gpio before pwm regulator probed, so the pwm
> > regulator driver will get a zero dutycycle at probe time, so change
> > the initial dutycycle to zero to match pwm_regulator_init_state check.
> >
> > Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
> >
> > ---
> >
> > arch/arm/boot/dts/rk3066a-bqcurie2.dts | 2 +-
> > arch/arm/boot/dts/rk3066a-marsboard.dts | 2 +-
> > arch/arm/boot/dts/rk3066a-rayeager.dts | 2 +-
> > 3 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
> > b/arch/arm/boot/dts/rk3066a-bqcurie2.dts index bc674ee..618450d 100644
> > --- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
> > +++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
> > @@ -61,7 +61,7 @@
> >
> > regulator-min-microvolt = <1200000>;
> > regulator-max-microvolt = <1200000>;
> > regulator-always-on;
> >
> > - voltage-table = <1000000 100>,
> > + voltage-table = <1000000 0>,
>
> In my opinion this isn't quite the right answer. I think that you
> should add a new property describing the voltage in the case that the
> pin is an input and you should fill that property in, like:
>
> voltage-when-input = <1000000>;
I'd think this would be more of a pwm issue, not something the pwm-regulator
should need to care about.
Ideally the pwm driver should be able to return some state information even if
disabled? I.e. deriving a duty-cycle value from its pin state similar to what
Doug described below (it's either 0% or 100%)
But right now I have a hard time understanding how the pwm could return any
duty-cycle information for an input gpio to the pwm-regulator, as I assume the
pwm-driver has to probe (and thus set pinctrl to the pwm function) before the
pwm-regulator is able to get the pwm handle?
> Once you have this property you should ideally be able to read whether
> the pin is currently configured as an input or as a special function
> at bootup. Note that I don't actually know if this is possible with
> the current pinctrl API, but it does seem like the ideal way to do it
> since it means you'll work even if the BIOS changes (AKA: if the BIOS
> leaves the pin as an input you can keep the voltage the same and if
> the BIOS leaves the pin as PWM you can keep the voltage the same).
>
> It's also possible that you could just add a property that says "init
> to a certain value at bootup no matter what the BIOS left it as". As
> long as that voltage is the maximum (and you'll lower it later) this
> ought to be safe and you shouldn't risk temporarily undervolting
> things.
>
>
> Note that, if you haven't already done so, you almost certainly want
> to make sure your pinctrl species an "init" state in addition to a
> "default" state. See <https://patchwork.kernel.org/patch/7454311/>.
>
> -Doug
^ permalink raw reply
* [PATCH] ASoC: samsung: make audio interface/controller explicitly
From: Krzysztof Kozlowski @ 2016-09-19 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474300318-26767-1-git-send-email-ayaka@soulik.info>
On Mon, Sep 19, 2016 at 11:51:58PM +0800, Randy Li wrote:
> It is simple sound card time, we could assign different codec
> to a interface without making a specific driver for it. The SPDIF
> and I2S interface for Samsung would be possible used by simple-sound-card,
> but not sure about the PCM.
>
> Signed-off-by: Randy Li <ayaka@soulik.info>
> ---
> sound/soc/samsung/Kconfig | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
> index 7b722b0..210ce38 100644
> --- a/sound/soc/samsung/Kconfig
> +++ b/sound/soc/samsung/Kconfig
> @@ -1,3 +1,7 @@
> +menu "SoC Audio for Samsung CPUs"
This adds a new empty layer. One have to choose this menu and then
SND_SOC_SAMSUNG to access specific options. Instead of new menu, the
SND_SOC_SAMSUNG should be menuconfig. The existing "depends on" and the
one you added below won't be needed then, I think. Just have to be sure
that nothing selects particular drivers without selecting
SND_SOC_SAMSUNG first.
Best regards,
Krzysztof
> +
> +comment "Common SoC Audio options for Samsung CPUs:"
> +
> config SND_SOC_SAMSUNG
> tristate "ASoC support for Samsung"
> depends on (PLAT_SAMSUNG || ARCH_EXYNOS)
> @@ -18,18 +22,22 @@ config SND_S3C2412_SOC_I2S
> select SND_S3C_I2SV2_SOC
>
> config SND_SAMSUNG_PCM
> - tristate
> + tristate "Samsung PCM interface support"
> + depends on SND_SOC_SAMSUNG
>
> config SND_SAMSUNG_AC97
> tristate
> select SND_SOC_AC97_BUS
> + depends on SND_SOC_SAMSUNG
>
> config SND_SAMSUNG_SPDIF
> - tristate
> + tristate "Samsung SPDIF transmitter support"
> + depends on SND_SOC_SAMSUNG
> select SND_SOC_SPDIF
>
> config SND_SAMSUNG_I2S
> - tristate
> + tristate "Samsung I2S interface support"
> + depends on I2C && SND_SOC_SAMSUNG
>
> config SND_SOC_SAMSUNG_NEO1973_WM8753
> tristate "Audio support for Openmoko Neo1973 Smartphones (GTA02)"
> @@ -229,3 +237,5 @@ config SND_SOC_ARNDALE_RT5631_ALC5631
> depends on SND_SOC_SAMSUNG && I2C
> select SND_SAMSUNG_I2S
> select SND_SOC_RT5631
> +
> +endmenu
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization
From: Doug Anderson @ 2016-09-19 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2318029.f7g774Bk76@phil>
Hi,
On Mon, Sep 19, 2016 at 9:15 AM, Heiko Stuebner <heiko@sntech.de> wrote:
> Am Montag, 19. September 2016, 08:15:30 CEST schrieb Doug Anderson:
>> Hi,
>>
>> On Mon, Sep 19, 2016 at 1:44 AM, Andy Yan <andy.yan@rock-chips.com> wrote:
>> > The current rk3066a based boards(Rayeager, Bqcurie2, Marsboard) use
>> > pwm modulate vdd_logic voltage, but the pwm is default disabled and
>> > the pwm pin acts as a gpio before pwm regulator probed, so the pwm
>> > regulator driver will get a zero dutycycle at probe time, so change
>> > the initial dutycycle to zero to match pwm_regulator_init_state check.
>> >
>> > Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
>> >
>> > ---
>> >
>> > arch/arm/boot/dts/rk3066a-bqcurie2.dts | 2 +-
>> > arch/arm/boot/dts/rk3066a-marsboard.dts | 2 +-
>> > arch/arm/boot/dts/rk3066a-rayeager.dts | 2 +-
>> > 3 files changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
>> > b/arch/arm/boot/dts/rk3066a-bqcurie2.dts index bc674ee..618450d 100644
>> > --- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
>> > +++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
>> > @@ -61,7 +61,7 @@
>> >
>> > regulator-min-microvolt = <1200000>;
>> > regulator-max-microvolt = <1200000>;
>> > regulator-always-on;
>> >
>> > - voltage-table = <1000000 100>,
>> > + voltage-table = <1000000 0>,
>>
>> In my opinion this isn't quite the right answer. I think that you
>> should add a new property describing the voltage in the case that the
>> pin is an input and you should fill that property in, like:
>>
>> voltage-when-input = <1000000>;
>
> I'd think this would be more of a pwm issue, not something the pwm-regulator
> should need to care about.
>
> Ideally the pwm driver should be able to return some state information even if
> disabled? I.e. deriving a duty-cycle value from its pin state similar to what
> Doug described below (it's either 0% or 100%)
>
> But right now I have a hard time understanding how the pwm could return any
> duty-cycle information for an input gpio to the pwm-regulator, as I assume the
> pwm-driver has to probe (and thus set pinctrl to the pwm function) before the
> pwm-regulator is able to get the pwm handle?
Hrm, right. The PWM ought to own the pinctrl, not the regulator.
Hrm. Then I guess this gets more complicated.
One thing to point out, though, is that an EE I talked to said that
the "voltage when input" is actually a well defined property and is
unrelated to the min/max voltage. AKA: it's not guaranteed to be
equal to the 50% duty cycle. ...so adding a property to the PWM
regulator that includes this value is something very sane. The
"voltage when input" is defined by the pile of resistors and
capacitors that are used to actually make the PWM control the
regulator.
The "voltage when input" is super important because this is the
voltage that's used at bootup (when all pins are configured as inputs,
possible with a pull applied) and that's used during suspend time when
the PWM stops.
-Doug
^ permalink raw reply
* [PATCH v2 3/6] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Kevin Hilman @ 2016-09-19 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DCC3CF.9090409@ti.com>
Kishon Vijay Abraham I <kishon@ti.com> writes:
> Hi Kevin,
>
> On Wednesday 14 September 2016 09:36 PM, Kevin Hilman wrote:
>> Kishon,
>>
>> Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
>>
>>> This is a new driver for the USB PHY found in Meson8b and GXBB SoCs.
>>>
>>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>>> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
>>> Tested-by: Kevin Hilman <khilman@baylibre.com>
>>
>> Will you be picking this up for v4.9?
>
> It's already late for 4.9. Generally send pull request to Greg around -rc6.
> This can go only in 4.10.
That's fine.
Does that mean you have it queued someplace? I don't see it in any of
your branches.
Kevin
^ permalink raw reply
* [PATCH 1/3] i2c: bcm2835: Fix hang for writing messages larger than 16 bytes
From: Eric Anholt @ 2016-09-19 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474298777-5858-1-git-send-email-noralf@tronnes.org>
Noralf Tr?nnes <noralf@tronnes.org> writes:
> Writing messages larger than the FIFO size results in a hang, rendering
> the machine unusable. This is because the RXD status flag is set on the
> first interrupt which results in bcm2835_drain_rxfifo() stealing bytes
> from the buffer. The controller continues to trigger interrupts waiting
> for the missing bytes, but bcm2835_fill_txfifo() has none to give.
> In this situation wait_for_completion_timeout() apparently is unable to
> stop the madness.
>
> The BCM2835 ARM Peripherals datasheet has this to say about the flags:
> TXD: is set when the FIFO has space for at least one byte of data.
> RXD: is set when the FIFO contains at least one byte of data.
> TXW: is set during a write transfer and the FIFO is less than full.
> RXR: is set during a read transfer and the FIFO is or more full.
>
> Implementing the logic from the downstream i2c-bcm2708 driver solved
> the hang problem.
>
> Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
Patches 1, 3 are:
Reviewed-by: Eric Anholt <eric@anholt.net>
For patch 2 I followed some of it, but couldn't quite say it's a review.
I trust your testing, and that the path has had a lot more testing in
the downstream tree, so it's:
Acked-by: Eric Anholt <eric@anholt.net>
Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/20ab542b/attachment.sig>
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Mark Rutland @ 2016-09-19 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474260085.15220.17.camel@buserror.net>
On Sun, Sep 18, 2016 at 11:41:25PM -0500, Scott Wood wrote:
> On Mon, 2016-09-12 at 12:36 +0100, Mark Rutland wrote:
> > On Fri, Sep 09, 2016 at 08:03:31PM -0500, Scott Wood wrote:
> > > +static __always_inline void arch_timer_cval_write_cp15(int access, u64
> > > val)
> > > +{
> > > + if (access == ARCH_TIMER_PHYS_ACCESS)
> > > + asm volatile("msr cntp_cval_el0, %0" : : "r" (val));
> > > + else if (access == ARCH_TIMER_VIRT_ACCESS)
> > > + asm volatile("msr cntv_cval_el0, %0" : : "r" (val));
> > > +
> > > + isb();
> > > +}
> > Please add ARCH_TIMER_REG_CVAL to enum arch_timer_reg, and move these
> > accesses into arch_timer_reg_write_cp15().
>
> Adding ARCH_TIMER_REG_CVAL to the enum means we get warnings from bunch of
> switch statements that don't actually need a CVAL implementation -- or else we
> have to add untested CVAL accessors for arm32 and mmio. ?The arm32 part would
> add another dependency on getting an ack from RMK, that can't be postponed as
> easily as the archdata/vdso patch.
That's annoying. Never mind, then.
> Since this is specific to an erratum rather than general cval support, I can
> move the accesses into fsl_a008585_set_next_event (and convert to
> write_sysreg).
Ok. I think that's preferable given we have no other users.
> > > +static void fsl_a008585_set_sne(struct clock_event_device *clk)
> > > +{
> > > +#ifdef CONFIG_FSL_ERRATUM_A008585
> > > + if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
> > > + return;
> > > +
> > > + if (arch_timer_uses_ppi == VIRT_PPI)
> > > + clk->set_next_event = fsl_a008585_set_next_event_virt;
> > > + else
> > > + clk->set_next_event = fsl_a008585_set_next_event_phys;
> > > +#endif
> > > +}
> > > +
> > I'm not keen on the magic hook to reset the function pointers, and the
> > additional phys/virt stubs seem pointless. Instead, can we fold this
> > into the existing set_next_event? e.g. have that do:
> >
> > if (needs_fsl_a008585_workaround() {
> > fsl_a008585_set_next_event(access, evt, clk);
> > return;
> > }
>
> OK. ?I had been trying to avoid messing with the standard set_next_event, but
> it doesn't matter as much now that static branches are being used. ?In that
> case we can avoid duplicating the ctrl code, and only replace the tval write.
Reconsidering my suggestion, I realise this will also affect the MMIO
timers, so that doesn't work.
So for the moment, I guess we have to keep fsl_a008585_set_next_event().
Thanks,
Mark.
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Mark Rutland @ 2016-09-19 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474259505.15220.8.camel@buserror.net>
On Sun, Sep 18, 2016 at 11:31:45PM -0500, Scott Wood wrote:
> On Mon, 2016-09-12 at 14:07 +0100, Marc Zyngier wrote:
> > On 12/09/16 13:59, Mark Rutland wrote:
> > >
> > > On Mon, Sep 12, 2016 at 01:30:28PM +0100, Mark Rutland wrote:
> > > >
> > > > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> > > > >
> > > > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > > > > >
> > > > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > > > > some cleanup [1,2] that just landed in the arm64 for-next/core
> > > > > > branch.
> > > > > >
> > > > > > Could you please rebase atop of that?
> > > > > Well, we should figure out what tree this is going through first.
> > > > > There
> > > > > are a mixture of arm, arm64, driver and dts changes here and not all
> > > > > of it is carrying the appropriate acks for me to queue it.
> > > > Given that mix, I had assumed that this would all go through the arm64
> > > > tree -- I see that Rob has already acked the binding, and I'm happy to
> > > > give my ack for the driver once that's in shape.
> > > Now I see that I'd missed the arch/arm changes in patch 4, which lack a
> > > relevant ack.
> > >
> > > Given that, I don't know what to suggest.
> > I wouldn't mind delaying patch 4 until it gets acked by RMK, as it
> > doesn't impact the functionality.
>
> Mark asked me to move that patch before the workaround patch, to avoid ever
> having to add more code that messes with the name. ?Should I keep the order as
> is then?
Yes; at this stage I think we have to.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] coresight: tmc: Cleanup operation mode handling
From: Suzuki K Poulose @ 2016-09-19 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkxWSQFgBYHi6dosjut78uohCtX8Wv3Kw=eHk0L_7jmFVw@mail.gmail.com>
On 16/09/16 18:07, Mathieu Poirier wrote:
> On 14 September 2016 at 07:53, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>> The mode of operation of the TMC tracked in drvdata->mode is defined
>> as a local_t type. This is always checked and modified under the
>> drvdata->spinlock and hence we don't need local_t for it and the
>> unnecessary synchronisation instructions that comes with it. This
>> change makes the code a bit more cleaner.
>>
>> Also fixes the order in which we update the drvdata->mode to
>> CS_MODE_DISABLED. i.e, in tmc_disable_etX_sink we change the
>> mode to CS_MODE_DISABLED before invoking tmc_disable_etX_hw()
>> which in turn depends on the mode to decide whether to dump the
>> trace to a buffer.
>
> Thank you for the patch - just a few comments below.
>
>> @@ -194,17 +192,17 @@ static int tmc_enable_etf_sink_perf(struct coresight_device *csdev, u32 mode)
>> goto out;
>> }
>>
>> - val = local_xchg(&drvdata->mode, mode);
>> /*
>> * In Perf mode there can be only one writer per sink. There
>> * is also no need to continue if the ETB/ETR is already operated
>> * from sysFS.
>> */
>> - if (val != CS_MODE_DISABLED) {
>> + if (drvdata->mode != CS_MODE_DISABLED) {
>> ret = -EINVAL;
>> goto out;
>> }
>>
>> + drvdata->mode = mode;
>
> Given the way tmc_enable_etf_sink_perf() is called in
> tmc_enable_etf_sink(), I think it is time to get rid of the 'mode'
> parameter - it doesn't do anything nowadays. Same thing for
> tmc_enable_etf_sink_sysfs() and ETR.
Sure, makes sense. I will clean it up.
>> @@ -279,8 +277,8 @@ static void tmc_disable_etf_link(struct coresight_device *csdev,
>> return;
>> }
>>
>> + drvdata->mode = CS_MODE_DISABLED;
>> tmc_etf_disable_hw(drvdata);
>> - local_set(&drvdata->mode, CS_MODE_DISABLED);
>
> I think setting the mode should come after tmc_etf_disable_hw(), as it
> was before.
You're right, I will change it.
Thanks for the review. Will send the updated series soon.
Cheers
Suzuki
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Scott Wood @ 2016-09-19 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919165258.GA30584@leverpostej>
On Mon, 2016-09-19 at 17:52 +0100, Mark Rutland wrote:
> > > >
> > > > +static void fsl_a008585_set_sne(struct clock_event_device *clk)
> > > > +{
> > > > +#ifdef CONFIG_FSL_ERRATUM_A008585
> > > > + if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
> > > > + return;
> > > > +
> > > > + if (arch_timer_uses_ppi == VIRT_PPI)
> > > > + clk->set_next_event =
> > > > fsl_a008585_set_next_event_virt;
> > > > + else
> > > > + clk->set_next_event =
> > > > fsl_a008585_set_next_event_phys;
> > > > +#endif
> > > > +}
> > > > +
> > > I'm not keen on the magic hook to reset the function pointers, and the
> > > additional phys/virt stubs seem pointless. Instead, can we fold this
> > > into the existing set_next_event? e.g. have that do:
> > >
> > > if (needs_fsl_a008585_workaround() {
> > > fsl_a008585_set_next_event(access, evt, clk);
> > > return;
> > > }
> > OK. ?I had been trying to avoid messing with the standard set_next_event,
> > but
> > it doesn't matter as much now that static branches are being used. ?In
> > that
> > case we can avoid duplicating the ctrl code, and only replace the tval
> > write.
> Reconsidering my suggestion, I realise this will also affect the MMIO
> timers, so that doesn't work.
>
> So for the moment, I guess we have to keep fsl_a008585_set_next_event().
What is the problem with MMIO timers? ?needs_fsl_a008585_workaround() should
always be false for them.
-Scott
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Mark Rutland @ 2016-09-19 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474304489.4283.6.camel@buserror.net>
On Mon, Sep 19, 2016 at 12:01:29PM -0500, Scott Wood wrote:
> On Mon, 2016-09-19 at 17:52 +0100, Mark Rutland wrote:
> > > > >
> > > > > +static void fsl_a008585_set_sne(struct clock_event_device *clk)
> > > > > +{
> > > > > +#ifdef CONFIG_FSL_ERRATUM_A008585
> > > > > + if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
> > > > > + return;
> > > > > +
> > > > > + if (arch_timer_uses_ppi == VIRT_PPI)
> > > > > + clk->set_next_event =
> > > > > fsl_a008585_set_next_event_virt;
> > > > > + else
> > > > > + clk->set_next_event =
> > > > > fsl_a008585_set_next_event_phys;
> > > > > +#endif
> > > > > +}
> > > > > +
> > > > I'm not keen on the magic hook to reset the function pointers, and the
> > > > additional phys/virt stubs seem pointless. Instead, can we fold this
> > > > into the existing set_next_event? e.g. have that do:
> > > >
> > > > if (needs_fsl_a008585_workaround() {
> > > > fsl_a008585_set_next_event(access, evt, clk);
> > > > return;
> > > > }
> > > OK. ?I had been trying to avoid messing with the standard set_next_event,
> > > but
> > > it doesn't matter as much now that static branches are being used. ?In
> > > that
> > > case we can avoid duplicating the ctrl code, and only replace the tval
> > > write.
> > Reconsidering my suggestion, I realise this will also affect the MMIO
> > timers, so that doesn't work.
> >
> > So for the moment, I guess we have to keep fsl_a008585_set_next_event().
>
> What is the problem with MMIO timers? ?needs_fsl_a008585_workaround() should
> always be false for them.
As suggested, needs_fsl_a008585_workaround() takes no parameter, and
set_next_event is called for both cp15/sysreg and MMIO timers. So it
would either be true for all, or false for all.
If it's true for all, we'd end up calling fsl_a008585_set_next_event()
for the MMIO timers too.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] coresight: tmc: Cleanup operation mode handling
From: Suzuki K Poulose @ 2016-09-19 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b693447b-e89c-d4ea-bc57-6c447d688055@arm.com>
On 19/09/16 17:59, Suzuki K Poulose wrote:
> On 16/09/16 18:07, Mathieu Poirier wrote:
>> On 14 September 2016 at 07:53, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> Cheers
> Suzuki
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
Bah, sorry about that. You are fine. This email is intended for the public list discussions.
Suzuki
^ permalink raw reply
* [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization
From: Boris Brezillon @ 2016-09-19 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=UOXcUZyXRj++GkKksyFedGt59vQz8958nhhF9UM7rOuw@mail.gmail.com>
On Mon, 19 Sep 2016 09:38:34 -0700
Doug Anderson <dianders@chromium.org> wrote:
> Hi,
>
> On Mon, Sep 19, 2016 at 9:15 AM, Heiko Stuebner <heiko@sntech.de> wrote:
> > Am Montag, 19. September 2016, 08:15:30 CEST schrieb Doug Anderson:
> >> Hi,
> >>
> >> On Mon, Sep 19, 2016 at 1:44 AM, Andy Yan <andy.yan@rock-chips.com> wrote:
> >> > The current rk3066a based boards(Rayeager, Bqcurie2, Marsboard) use
> >> > pwm modulate vdd_logic voltage, but the pwm is default disabled and
> >> > the pwm pin acts as a gpio before pwm regulator probed, so the pwm
> >> > regulator driver will get a zero dutycycle at probe time, so change
> >> > the initial dutycycle to zero to match pwm_regulator_init_state check.
> >> >
> >> > Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
> >> >
> >> > ---
> >> >
> >> > arch/arm/boot/dts/rk3066a-bqcurie2.dts | 2 +-
> >> > arch/arm/boot/dts/rk3066a-marsboard.dts | 2 +-
> >> > arch/arm/boot/dts/rk3066a-rayeager.dts | 2 +-
> >> > 3 files changed, 3 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
> >> > b/arch/arm/boot/dts/rk3066a-bqcurie2.dts index bc674ee..618450d 100644
> >> > --- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
> >> > +++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
> >> > @@ -61,7 +61,7 @@
> >> >
> >> > regulator-min-microvolt = <1200000>;
> >> > regulator-max-microvolt = <1200000>;
> >> > regulator-always-on;
> >> >
> >> > - voltage-table = <1000000 100>,
> >> > + voltage-table = <1000000 0>,
> >>
> >> In my opinion this isn't quite the right answer. I think that you
> >> should add a new property describing the voltage in the case that the
> >> pin is an input and you should fill that property in, like:
> >>
> >> voltage-when-input = <1000000>;
> >
> > I'd think this would be more of a pwm issue, not something the pwm-regulator
> > should need to care about.
> >
> > Ideally the pwm driver should be able to return some state information even if
> > disabled? I.e. deriving a duty-cycle value from its pin state similar to what
> > Doug described below (it's either 0% or 100%)
> >
> > But right now I have a hard time understanding how the pwm could return any
> > duty-cycle information for an input gpio to the pwm-regulator, as I assume the
> > pwm-driver has to probe (and thus set pinctrl to the pwm function) before the
> > pwm-regulator is able to get the pwm handle?
>
> Hrm, right. The PWM ought to own the pinctrl, not the regulator.
> Hrm. Then I guess this gets more complicated.
>
> One thing to point out, though, is that an EE I talked to said that
> the "voltage when input" is actually a well defined property and is
> unrelated to the min/max voltage. AKA: it's not guaranteed to be
> equal to the 50% duty cycle. ...so adding a property to the PWM
> regulator that includes this value is something very sane. The
> "voltage when input" is defined by the pile of resistors and
> capacitors that are used to actually make the PWM control the
> regulator.
>
> The "voltage when input" is super important because this is the
> voltage that's used at bootup (when all pins are configured as inputs,
> possible with a pull applied) and that's used during suspend time when
> the PWM stops.
Correct me if I'm wrong, but the main problem here is that, when we try
to detect the initial regulator state, we ran into a "missing entry in
the duty-cycle <-> voltage table" error, which then triggers an -EINVAL
error preventing the PWM regulator probe to succeed.
Of course, adding an entry for the 0% dutycle case would solve the
issue, but I wonder if we should not allow "unknown value" at probe
time, and let the regulator user set the voltage output when it claims
it.
Another option would be to fake a valid value in this case (choose the
closest entry in the voltage table?).
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox