* [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
* [PATCH 00/27] drm/rockchip: MIPI fixes & improvements
From: John Keeping @ 2016-09-19 17:17 UTC (permalink / raw)
To: linux-arm-kernel
This is a bit of a mixed selection of patches to all areas of the
Rockchip dw-mipi-dsi driver, which I've been using for a while.
The first few patches fix the driver's use of the atomic API by removing
hardware manipulation from the mode_set hook:
drm/rockchip: dw-mipi-dsi: use mode from display state
drm/rockchip: dw-mipi-dsi: pass new mode into MIPI mode set
drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for
MIPI
drm/rockchip: dw-mipi-dsi: rename commit hook to enable
The following several patches fix various aspects of DSI host transfers
in order to improve support for displays that need to be set up via DSI
commands:
drm/rockchip: dw-mipi-dsi: fix command header writes
drm/rockchip: dw-mipi-dsi: fix generic packet status check
drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf
drm/rockchip: dw-mipi-dsi: include bad value in error message
drm/rockchip: dw-mipi-dsi: respect message flags
drm/rockchip: dw-mipi-dsi: only request HS clock when required
drm/rockchip: dw-mipi-dsi: don't assume buffer is aligned
drm/rockchip: dw-mipi-dsi: prepare panel after phy init
drm/rockchip: dw-mipi-dsi: allow commands in panel_disable
Then a bunch of patches to improve the PHY PLL and other clock setup:
drm/rockchip: dw-mipi-dsi: fix escape clock rate
drm/rockchip: dw-mipi-dsi: ensure PHY is reset
drm/rockchip: dw-mipi-dsi: configure bias and bandgap before enable
drm/rockchip: dw-mipi-dsi: don't enable PHY PLL until it's configured
drm/rockchip: dw-mipi-dsi: properly configure PHY timing
drm/rockchip: dw-mipi-dsi: improve PLL configuration
A couple of patches make the VOP and MIPI host consistent when panels do
not set explicit hsync/vsync polarities:
drm/rockchip: dw-mipi-dsi: use positive check for N{H,V}SYNC
drm/rockchip: vop: test for P{H,V}SYNC
The following patch fixes fbcon by making sure that the output
resolution is known before it loads:
drm/rockchip: dw-mipi-dsi: defer probe if panel is not loaded
Then a patch that should be self-explanatory:
drm/rockchip: dw-mipi-dsi: support non-burst modes
And the final two patches were useful in development but aren't really
needed once everything's working:
drm/rockchip: dw-mipi-dsi: add reset control
drm/rockchip: dw-mipi-dsi: support read commands
John Keeping (26):
drm/rockchip: dw-mipi-dsi: use mode from display state
drm/rockchip: dw-mipi-dsi: pass new mode into MIPI mode set
drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for
MIPI
drm/rockchip: dw-mipi-dsi: rename commit hook to enable
drm/rockchip: dw-mipi-dsi: fix command header writes
drm/rockchip: dw-mipi-dsi: fix generic packet status check
drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf
drm/rockchip: dw-mipi-dsi: include bad value in error message
drm/rockchip: dw-mipi-dsi: respect message flags
drm/rockchip: dw-mipi-dsi: only request HS clock when required
drm/rockchip: dw-mipi-dsi: don't assume buffer is aligned
drm/rockchip: dw-mipi-dsi: prepare panel after phy init
drm/rockchip: dw-mipi-dsi: allow commands in panel_disable
drm/rockchip: dw-mipi-dsi: fix escape clock rate
drm/rockchip: dw-mipi-dsi: ensure PHY is reset
drm/rockchip: dw-mipi-dsi: configure bias and bandgap before enable
drm/rockchip: dw-mipi-dsi: don't enable PHY PLL until it's configured
drm/rockchip: dw-mipi-dsi: properly configure PHY timing
drm/rockchip: dw-mipi-dsi: improve PLL configuration
drm/rockchip: dw-mipi-dsi: use specific poll helper
drm/rockchip: dw-mipi-dsi: use positive check for N{H,V}SYNC
drm/rockchip: vop: test for P{H,V}SYNC
drm/rockchip: dw-mipi-dsi: defer probe if panel is not loaded
drm/rockchip: dw-mipi-dsi: support non-burst modes
drm/rockchip: dw-mipi-dsi: add reset control
drm/rockchip: dw-mipi-dsi: support read commands
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 325 ++++++++++++++++++++--------
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 +-
2 files changed, 234 insertions(+), 95 deletions(-)
--
2.10.0.278.g4f427b1.dirty
^ permalink raw reply
* [PATCH 01/26] drm/rockchip: dw-mipi-dsi: use mode from display state
From: John Keeping @ 2016-09-19 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919171747.28512-1-john@metanate.com>
There is no need to keep a pointer to the mode around since we know it
will be present in the connector state.
Signed-off-by: John Keeping <john@metanate.com>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 31 ++++++++++++++++---------------
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index ca22e5ee89ca..a87037556f5c 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -286,7 +286,6 @@ struct dw_mipi_dsi {
u32 format;
u16 input_div;
u16 feedback_div;
- struct drm_display_mode *mode;
const struct dw_mipi_dsi_plat_data *pdata;
};
@@ -332,9 +331,10 @@ static int max_mbps_to_testdin(unsigned int max_mbps)
*/
static void dw_mipi_dsi_wait_for_two_frames(struct dw_mipi_dsi *dsi)
{
+ struct drm_display_mode *mode = &dsi->connector.state->crtc->state->adjusted_mode;
int refresh, two_frames;
- refresh = drm_mode_vrefresh(dsi->mode);
+ refresh = drm_mode_vrefresh(mode);
two_frames = DIV_ROUND_UP(MSEC_PER_SEC, refresh) * 2;
msleep(two_frames);
}
@@ -461,6 +461,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)
{
+ struct drm_display_mode *mode = &dsi->connector.state->crtc->state->adjusted_mode;
unsigned int i, pre;
unsigned long mpclk, pllref, tmp;
unsigned int m = 1, n = 1, target_mbps = 1000;
@@ -474,7 +475,7 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)
return bpp;
}
- mpclk = DIV_ROUND_UP(dsi->mode->clock, MSEC_PER_SEC);
+ mpclk = DIV_ROUND_UP(mode->clock, MSEC_PER_SEC);
if (mpclk) {
/* take 1 / 0.9, since mbps must big than bandwidth of RGB */
tmp = mpclk * (bpp / dsi->lanes) * 10 / 9;
@@ -689,9 +690,9 @@ static void dw_mipi_dsi_init(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS);
}
-static void dw_mipi_dsi_dpi_config(struct dw_mipi_dsi *dsi,
- struct drm_display_mode *mode)
+static void dw_mipi_dsi_dpi_config(struct dw_mipi_dsi *dsi)
{
+ struct drm_display_mode *mode = &dsi->connector.state->crtc->state->adjusted_mode;
u32 val = 0, color = 0;
switch (dsi->format) {
@@ -726,9 +727,10 @@ static void dw_mipi_dsi_packet_handler_config(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_PCKHDL_CFG, EN_CRC_RX | EN_ECC_RX | EN_BTA);
}
-static void dw_mipi_dsi_video_packet_config(struct dw_mipi_dsi *dsi,
- struct drm_display_mode *mode)
+static void dw_mipi_dsi_video_packet_config(struct dw_mipi_dsi *dsi)
{
+ struct drm_display_mode *mode = &dsi->connector.state->crtc->state->adjusted_mode;
+
dsi_write(dsi, DSI_VID_PKT_SIZE, VID_PKT_SIZE(mode->hdisplay));
}
@@ -744,12 +746,13 @@ static void dw_mipi_dsi_command_mode_config(struct dw_mipi_dsi *dsi)
static u32 dw_mipi_dsi_get_hcomponent_lbcc(struct dw_mipi_dsi *dsi,
u32 hcomponent)
{
+ struct drm_display_mode *mode = &dsi->connector.state->crtc->state->adjusted_mode;
u32 frac, lbcc;
lbcc = hcomponent * dsi->lane_mbps * MSEC_PER_SEC / 8;
- frac = lbcc % dsi->mode->clock;
- lbcc = lbcc / dsi->mode->clock;
+ frac = lbcc % mode->clock;
+ lbcc = lbcc / mode->clock;
if (frac)
lbcc++;
@@ -759,7 +762,7 @@ static u32 dw_mipi_dsi_get_hcomponent_lbcc(struct dw_mipi_dsi *dsi,
static void dw_mipi_dsi_line_timer_config(struct dw_mipi_dsi *dsi)
{
u32 htotal, hsa, hbp, lbcc;
- struct drm_display_mode *mode = dsi->mode;
+ struct drm_display_mode *mode = &dsi->connector.state->crtc->state->adjusted_mode;
htotal = mode->htotal;
hsa = mode->hsync_end - mode->hsync_start;
@@ -778,7 +781,7 @@ static void dw_mipi_dsi_line_timer_config(struct dw_mipi_dsi *dsi)
static void dw_mipi_dsi_vertical_timing_config(struct dw_mipi_dsi *dsi)
{
u32 vactive, vsa, vfp, vbp;
- struct drm_display_mode *mode = dsi->mode;
+ struct drm_display_mode *mode = &dsi->connector.state->crtc->state->adjusted_mode;
vactive = mode->vdisplay;
vsa = mode->vsync_end - mode->vsync_start;
@@ -821,8 +824,6 @@ static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder *encoder,
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
int ret;
- dsi->mode = adjusted_mode;
-
ret = dw_mipi_dsi_get_lane_bps(dsi);
if (ret < 0)
return;
@@ -833,10 +834,10 @@ static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder *encoder,
}
dw_mipi_dsi_init(dsi);
- dw_mipi_dsi_dpi_config(dsi, mode);
+ dw_mipi_dsi_dpi_config(dsi);
dw_mipi_dsi_packet_handler_config(dsi);
dw_mipi_dsi_video_mode_config(dsi);
- dw_mipi_dsi_video_packet_config(dsi, mode);
+ dw_mipi_dsi_video_packet_config(dsi);
dw_mipi_dsi_command_mode_config(dsi);
dw_mipi_dsi_line_timer_config(dsi);
dw_mipi_dsi_vertical_timing_config(dsi);
--
2.10.0.278.g4f427b1.dirty
^ permalink raw reply related
* [PATCH 02/26] drm/rockchip: dw-mipi-dsi: pass new mode into MIPI mode set
From: John Keeping @ 2016-09-19 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919171747.28512-1-john@metanate.com>
In the atomic world the new connector state is not set when mode_set is
called and we should use the adjusted_mode parameter.
Signed-off-by: John Keeping <john@metanate.com>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index a87037556f5c..fa90bb615fd0 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -459,9 +459,9 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
return ret;
}
-static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)
+static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi,
+ struct drm_display_mode *mode)
{
- struct drm_display_mode *mode = &dsi->connector.state->crtc->state->adjusted_mode;
unsigned int i, pre;
unsigned long mpclk, pllref, tmp;
unsigned int m = 1, n = 1, target_mbps = 1000;
@@ -824,7 +824,7 @@ static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder *encoder,
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
int ret;
- ret = dw_mipi_dsi_get_lane_bps(dsi);
+ ret = dw_mipi_dsi_get_lane_bps(dsi, adjusted_mode);
if (ret < 0)
return;
--
2.10.0.278.g4f427b1.dirty
^ permalink raw reply related
* [PATCH 03/26] drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for MIPI
From: John Keeping @ 2016-09-19 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919171747.28512-1-john@metanate.com>
With atomic modesetting the hardware will be powered off when the
mode_set function is called. We should configure the hardware in the
commit function (or even the enable function, but switching from commit
to enable is left for a future patch).
Signed-off-by: John Keeping <john@metanate.com>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 40 +++++++++++++---------------------
1 file changed, 15 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index fa90bb615fd0..5925a185ed76 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -822,32 +822,8 @@ static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
{
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
- int ret;
-
- ret = dw_mipi_dsi_get_lane_bps(dsi, adjusted_mode);
- if (ret < 0)
- return;
-
- if (clk_prepare_enable(dsi->pclk)) {
- dev_err(dsi->dev, "%s: Failed to enable pclk\n", __func__);
- return;
- }
- dw_mipi_dsi_init(dsi);
- dw_mipi_dsi_dpi_config(dsi);
- dw_mipi_dsi_packet_handler_config(dsi);
- dw_mipi_dsi_video_mode_config(dsi);
- dw_mipi_dsi_video_packet_config(dsi);
- dw_mipi_dsi_command_mode_config(dsi);
- dw_mipi_dsi_line_timer_config(dsi);
- dw_mipi_dsi_vertical_timing_config(dsi);
- dw_mipi_dsi_dphy_timing_config(dsi);
- dw_mipi_dsi_dphy_interface_config(dsi);
- dw_mipi_dsi_clear_err(dsi);
- if (drm_panel_prepare(dsi->panel))
- dev_err(dsi->dev, "failed to prepare panel\n");
-
- clk_disable_unprepare(dsi->pclk);
+ dw_mipi_dsi_get_lane_bps(dsi, adjusted_mode);
}
static void dw_mipi_dsi_encoder_disable(struct drm_encoder *encoder)
@@ -887,6 +863,20 @@ static void dw_mipi_dsi_encoder_commit(struct drm_encoder *encoder)
return;
}
+ dw_mipi_dsi_init(dsi);
+ dw_mipi_dsi_dpi_config(dsi);
+ dw_mipi_dsi_packet_handler_config(dsi);
+ dw_mipi_dsi_video_mode_config(dsi);
+ dw_mipi_dsi_video_packet_config(dsi);
+ dw_mipi_dsi_command_mode_config(dsi);
+ dw_mipi_dsi_line_timer_config(dsi);
+ dw_mipi_dsi_vertical_timing_config(dsi);
+ dw_mipi_dsi_dphy_timing_config(dsi);
+ dw_mipi_dsi_dphy_interface_config(dsi);
+ dw_mipi_dsi_clear_err(dsi);
+ if (drm_panel_prepare(dsi->panel))
+ dev_err(dsi->dev, "failed to prepare panel\n");
+
dw_mipi_dsi_phy_init(dsi);
dw_mipi_dsi_wait_for_two_frames(dsi);
--
2.10.0.278.g4f427b1.dirty
^ permalink raw reply related
* [PATCH 04/26] drm/rockchip: dw-mipi-dsi: rename commit hook to enable
From: John Keeping @ 2016-09-19 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919171747.28512-1-john@metanate.com>
Rockchip DRM is fully atomic and commit is deprecated for atomic
drivers. No changed are needed beyond renaming the function.
Signed-off-by: John Keeping <john@metanate.com>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 5925a185ed76..fac2429b9d6d 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -852,7 +852,7 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder *encoder)
clk_disable_unprepare(dsi->pclk);
}
-static void dw_mipi_dsi_encoder_commit(struct drm_encoder *encoder)
+static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)
{
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
@@ -924,7 +924,7 @@ dw_mipi_dsi_encoder_atomic_check(struct drm_encoder *encoder,
static struct drm_encoder_helper_funcs
dw_mipi_dsi_encoder_helper_funcs = {
- .commit = dw_mipi_dsi_encoder_commit,
+ .enable = dw_mipi_dsi_encoder_enable,
.mode_set = dw_mipi_dsi_encoder_mode_set,
.disable = dw_mipi_dsi_encoder_disable,
.atomic_check = dw_mipi_dsi_encoder_atomic_check,
--
2.10.0.278.g4f427b1.dirty
^ permalink raw reply related
* [PATCH 05/26] drm/rockchip: dw-mipi-dsi: fix command header writes
From: John Keeping @ 2016-09-19 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919171747.28512-1-john@metanate.com>
In a couple of places here we use "val" for the value that is about to
be written to a register but then reuse the same variable for the value
of a status register before we get around to writing it. Rename the
value to be written to so that we write the value we intend to and not
what we have just read from the status register.
Signed-off-by: John Keeping <john@metanate.com>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index fac2429b9d6d..03915bf9c97d 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -543,9 +543,10 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host *host,
return 0;
}
-static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 val)
+static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val)
{
int ret;
+ u32 val;
ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,
val, !(val & GEN_CMD_FULL), 1000,
@@ -555,7 +556,7 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 val)
return ret;
}
- dsi_write(dsi, DSI_GEN_HDR, val);
+ dsi_write(dsi, DSI_GEN_HDR, hdr_val);
ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,
val, val & (GEN_CMD_EMPTY | GEN_PLD_W_EMPTY),
@@ -588,8 +589,9 @@ static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
{
const u32 *tx_buf = msg->tx_buf;
int len = msg->tx_len, pld_data_bytes = sizeof(*tx_buf), ret;
- u32 val = GEN_HDATA(msg->tx_len) | GEN_HTYPE(msg->type);
+ u32 hdr_val = GEN_HDATA(msg->tx_len) | GEN_HTYPE(msg->type);
u32 remainder = 0;
+ u32 val;
if (msg->tx_len < 3) {
dev_err(dsi->dev, "wrong tx buf length %zu for long write\n",
@@ -618,7 +620,7 @@ static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
}
}
- return dw_mipi_dsi_gen_pkt_hdr_write(dsi, val);
+ return dw_mipi_dsi_gen_pkt_hdr_write(dsi, hdr_val);
}
static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
--
2.10.0.278.g4f427b1.dirty
^ permalink raw reply related
* [PATCH 06/26] drm/rockchip: dw-mipi-dsi: fix generic packet status check
From: John Keeping @ 2016-09-19 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919171747.28512-1-john@metanate.com>
We want to check that both the GEN_CMD_EMPTY and GEN_PLD_W_EMPTY bits
are set so we can't just check "val & mask" because that will be true if
either bit is set.
Signed-off-by: John Keeping <john@metanate.com>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 03915bf9c97d..f2bed2a0f907 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -546,7 +546,7 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host *host,
static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val)
{
int ret;
- u32 val;
+ u32 val, mask;
ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,
val, !(val & GEN_CMD_FULL), 1000,
@@ -558,8 +558,9 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val)
dsi_write(dsi, DSI_GEN_HDR, hdr_val);
+ mask = GEN_CMD_EMPTY | GEN_PLD_W_EMPTY;
ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,
- val, val & (GEN_CMD_EMPTY | GEN_PLD_W_EMPTY),
+ val, (val & mask) == mask,
1000, CMD_PKT_STATUS_TIMEOUT_US);
if (ret < 0) {
dev_err(dsi->dev, "failed to write command FIFO\n");
--
2.10.0.278.g4f427b1.dirty
^ permalink raw reply related
* [PATCH 07/26] drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf
From: John Keeping @ 2016-09-19 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919171747.28512-1-john@metanate.com>
As a side-effect of this, encode the endianness explicitly rather than
casting a u16.
Signed-off-by: John Keeping <john@metanate.com>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index f2bed2a0f907..38186df8476e 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -573,8 +573,13 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val)
static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
const struct mipi_dsi_msg *msg)
{
- const u16 *tx_buf = msg->tx_buf;
- u32 val = GEN_HDATA(*tx_buf) | GEN_HTYPE(msg->type);
+ const u8 *tx_buf = msg->tx_buf;
+ u32 val = GEN_HTYPE(msg->type);
+
+ if (msg->tx_len > 0)
+ val |= GEN_HDATA(tx_buf[0]);
+ if (msg->tx_len > 1)
+ val |= GEN_HDATA(tx_buf[1] << 8);
if (msg->tx_len > 2) {
dev_err(dsi->dev, "too long tx buf length %zu for short write\n",
--
2.10.0.278.g4f427b1.dirty
^ permalink raw reply related
* [PATCH 08/26] drm/rockchip: dw-mipi-dsi: include bad value in error message
From: John Keeping @ 2016-09-19 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919171747.28512-1-john@metanate.com>
As an aid to debugging.
Signed-off-by: John Keeping <john@metanate.com>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 38186df8476e..a25db02e1c19 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -645,7 +645,8 @@ static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
ret = dw_mipi_dsi_dcs_long_write(dsi, msg);
break;
default:
- dev_err(dsi->dev, "unsupported message type\n");
+ dev_err(dsi->dev, "unsupported message type 0x%02x\n",
+ msg->type);
ret = -EINVAL;
}
--
2.10.0.278.g4f427b1.dirty
^ 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