* [PATCH 4/6] ARM: dts: keystone-k2g-evm: Add QSPI DT node.
From: Vignesh R @ 2017-11-23 7:51 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: devicetree, Rob Herring, linux-kernel, linux-arm-kernel,
Vignesh R
In-Reply-To: <20171123075154.3938-1-vigneshr@ti.com>
66AK2G EVM has a s25fl512s flash connected to QSPI. Add DT nodes for the
same.
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
arch/arm/boot/dts/keystone-k2g-evm.dts | 59 ++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 03b3e7c5dc8e..8d100217e38f 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -103,6 +103,18 @@
K2G_CORE_IOPAD(0x11b4) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* spi1_mosi.spi1_mosi */
>;
};
+
+ qspi_pins: pinmux_qspi_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x1204) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_clk.qspi_clk */
+ K2G_CORE_IOPAD(0x1208) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_rclk.qspi_rclk */
+ K2G_CORE_IOPAD(0x120c) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d0.qspi_d0 */
+ K2G_CORE_IOPAD(0x1210) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d1.qspi_d1 */
+ K2G_CORE_IOPAD(0x1214) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d2.qspi_d2 */
+ K2G_CORE_IOPAD(0x1218) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d3.qspi_d3 */
+ K2G_CORE_IOPAD(0x121c) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_csn0.qspi_csn0 */
+ >;
+ };
};
&uart0 {
@@ -204,3 +216,50 @@
};
};
};
+
+&qspi {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&qspi_pins>;
+ cdns,rclk-en;
+
+ flash0: m25p80@0 {
+ compatible = "s25fl512s", "jedec,spi-nor";
+ reg = <0>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <4>;
+ spi-max-frequency = <96000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cdns,read-delay = <5>;
+ cdns,tshsl-ns = <500>;
+ cdns,tsd2d-ns = <500>;
+ cdns,tchsh-ns = <119>;
+ cdns,tslch-ns = <119>;
+
+ partition@0 {
+ label = "QSPI.u-boot-spl-os";
+ reg = <0x00000000 0x00100000>;
+ };
+ partition@1 {
+ label = "QSPI.u-boot-env";
+ reg = <0x00100000 0x00040000>;
+ };
+ partition@2 {
+ label = "QSPI.skern";
+ reg = <0x00140000 0x0040000>;
+ };
+ partition@3 {
+ label = "QSPI.pmmc-firmware";
+ reg = <0x00180000 0x0040000>;
+ };
+ partition@4 {
+ label = "QSPI.kernel";
+ reg = <0x001C0000 0x0800000>;
+ };
+ partition@5 {
+ label = "QSPI.file-system";
+ reg = <0x009C0000 0x3640000>;
+ };
+ };
+};
--
2.15.0
^ permalink raw reply related
* [PATCH 3/6] ARM: dts: keystone-k2g: Move ti,non-removable property to board dts
From: Vignesh R @ 2017-11-23 7:51 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Rob Herring, linux-arm-kernel, devicetree, linux-kernel,
Vignesh R
In-Reply-To: <20171123075154.3938-1-vigneshr@ti.com>
On 66AK2G EVM mmc1 is connected to emmc whereas 66AK2G ICE baord has SD
card slot connected to mmc1. Therefore move emmc specific
ti,non-removable property from SoC file to EVM's dts file.
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
arch/arm/boot/dts/keystone-k2g-evm.dts | 1 +
arch/arm/boot/dts/keystone-k2g.dtsi | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 298a50555e46..03b3e7c5dc8e 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -127,6 +127,7 @@
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins>;
vmmc-supply = <&vcc3v3_dcin_reg>; /* VCC3V3_EMMC is connected to VCC3V3_DCIN */
+ ti,non-removable;
status = "okay";
};
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
index 01d29320b04c..ef82c0a6e607 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -372,7 +372,6 @@
dma-names = "tx", "rx";
bus-width = <8>;
ti,needs-special-reset;
- ti,non-removable;
max-frequency = <96000000>;
power-domains = <&k2g_pds 0xc>;
clocks = <&k2g_clks 0xc 1>, <&k2g_clks 0xc 2>;
--
2.15.0
^ permalink raw reply related
* [PATCH 2/6] ARM: dts: keystone-k2g-evm: Fix botched up merge
From: Vignesh R @ 2017-11-23 7:51 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Vignesh R
In-Reply-To: <20171123075154.3938-1-vigneshr-l0cyMroinI0@public.gmane.org>
spi1 and ecap0 pinmuxes ended up under root node instead of k2g_pinctrl
node. Fix this by moving them under k2g_pinctrl node.
Signed-off-by: Vignesh R <vigneshr-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/keystone-k2g-evm.dts | 30 ++++++++++++++----------------
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 656af194a518..298a50555e46 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -45,22 +45,6 @@
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
-
- ecap0_pins: ecap0_pins {
- pinctrl-single,pins = <
- K2G_CORE_IOPAD(0x1374) (BUFFER_CLASS_B | MUX_MODE4) /* pr1_mdio_data.ecap0_in_apwm0_out */
- >;
- };
-
- spi1_pins: pinmux_spi1_pins {
- pinctrl-single,pins = <
- K2G_CORE_IOPAD(0x11a4) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* spi1_scs0.spi1_scs0 */
- K2G_CORE_IOPAD(0x11ac) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* spi1_clk.spi1_clk */
- K2G_CORE_IOPAD(0x11b0) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* spi1_miso.spi1_miso */
- K2G_CORE_IOPAD(0x11b4) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* spi1_mosi.spi1_mosi */
- >;
- };
-
};
&k2g_pinctrl {
@@ -105,6 +89,20 @@
>;
};
+ ecap0_pins: ecap0_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x1374) (BUFFER_CLASS_B | MUX_MODE4) /* pr1_mdio_data.ecap0_in_apwm0_out */
+ >;
+ };
+
+ spi1_pins: pinmux_spi1_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x11a4) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* spi1_scs0.spi1_scs0 */
+ K2G_CORE_IOPAD(0x11ac) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* spi1_clk.spi1_clk */
+ K2G_CORE_IOPAD(0x11b0) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* spi1_miso.spi1_miso */
+ K2G_CORE_IOPAD(0x11b4) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* spi1_mosi.spi1_mosi */
+ >;
+ };
};
&uart0 {
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/6] ARM: dts: keystone-k2g: Add QSPI DT entry
From: Vignesh R @ 2017-11-23 7:51 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Rob Herring, linux-arm-kernel, devicetree, linux-kernel,
Vignesh R
In-Reply-To: <20171123075154.3938-1-vigneshr@ti.com>
Add DT node for Cadence QSPI IP present in 66AK2G SoC.
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
arch/arm/boot/dts/keystone-k2g.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
index 8f313ff406b9..01d29320b04c 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -377,6 +377,20 @@
power-domains = <&k2g_pds 0xc>;
clocks = <&k2g_clks 0xc 1>, <&k2g_clks 0xc 2>;
clock-names = "fck", "mmchsdb_fck";
+ };
+
+ qspi: qspi@2940000 {
+ compatible = "ti,k2g-qspi", "cdns,qspi-nor";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x02940000 0x1000>,
+ <0x24000000 0x4000000>;
+ interrupts = <GIC_SPI 198 IRQ_TYPE_EDGE_RISING>;
+ cdns,fifo-depth = <256>;
+ cdns,fifo-width = <4>;
+ cdns,trigger-address = <0x24000000>;
+ clocks = <&k2g_clks 0x43 0x0>;
+ power-domains = <&k2g_pds 0x43>;
status = "disabled";
};
--
2.15.0
^ permalink raw reply related
* [PATCH 0/6] 66AK2G: Add DT nodes for few peripherals
From: Vignesh R @ 2017-11-23 7:51 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Rob Herring, linux-arm-kernel, devicetree, linux-kernel,
Vignesh R
This patch series adds DT nodes for bunch of peripherials on 66AK2G EVM and
66AK2G ICE boards.
Tested on 66AK2G EVM and ICE boards
Vignesh R (6):
ARM: dts: keystone-k2g: Add QSPI DT entry
ARM: dts: keystone-k2g-evm: Fix botched up merge
ARM: dts: keystone-k2g: Move ti,non-removable property to board dts
ARM: dts: keystone-k2g-evm: Add QSPI DT node.
ARM: dts: keystone-k2g-ice: Add DT nodes for few peripherals
ARM: configs: keystone_defconfig: Enable few peripheral drivers
arch/arm/boot/dts/keystone-k2g-evm.dts | 90 +++++++--
arch/arm/boot/dts/keystone-k2g-ice.dts | 336 +++++++++++++++++++++++++++++++++
arch/arm/boot/dts/keystone-k2g.dtsi | 15 +-
arch/arm/configs/keystone_defconfig | 7 +
4 files changed, 431 insertions(+), 17 deletions(-)
--
2.15.0
^ permalink raw reply
* Re: [PATCH v7 08/13] regmap: add SLIMbus support
From: Charles Keepax @ 2017-11-23 7:49 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: mark.rutland, alsa-devel, michael.opdenacker, poeschel,
andreas.noever, arnd, vinod.koul, treding, devicetree,
james.hogan, pawel.moll, linux-arm-msm, sharon.dvir1, robh+dt,
sdharia, alan, bp, mathieu.poirier, gregkh, linux-kernel, broonie,
daniel, jkosina, joe, davem
In-Reply-To: <20171115141043.29202-9-srinivas.kandagatla@linaro.org>
On Wed, Nov 15, 2017 at 02:10:38PM +0000, srinivas.kandagatla@linaro.org wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>
> This patch adds support to read/write slimbus value elements.
> Currently it only supports byte read/write. Adding this support in
> regmap would give codec drivers more flexibility when there are more
> than 2 control interfaces like slimbus, i2c.
>
> Without this patch each codec driver has to directly call slimbus value
> element apis, and this could would get messy once we want to add i2c
> interface to it.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> +
> +static int regmap_slimbus_byte_reg_read(void *context, unsigned int reg,
> + unsigned int *val)
> +{
> + struct slim_device *sdev = context;
> + int v;
> +
> + if (!sdev)
> + return 0;
Is there a specific reason we are checking the context here? The
other regmap buses don't both and whilst I don't mind checking
shouldn't we return an error if we don't have a context rather
than pretending to succeed?
> +
> + v = slim_readb(sdev, reg);
> +
> + if (v < 0)
> + return v;
> +
> + *val = v;
> +
> + return 0;
> +}
> +
> +static int regmap_slimbus_byte_reg_write(void *context, unsigned int reg,
> + unsigned int val)
> +{
> + struct slim_device *sdev = context;
> +
> + if (!sdev)
> + return 0;
ditto.
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH 0/7] R-Car D3 (r8a77995) CAN support
From: Ulrich Hecht @ 2017-11-23 7:43 UTC (permalink / raw)
To: Simon Horman
Cc: Linux-Renesas, linux-can-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Wolfram Sang,
Geert Uytterhoeven, Magnus Damm, Chris Paterson,
Ramesh Shanmugasundaram
In-Reply-To: <20171122181045.5pstmikwp43idts5-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
On Wed, Nov 22, 2017 at 7:10 PM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> On Fri, Nov 17, 2017 at 11:41:22AM +0100, Ulrich Hecht wrote:
>> Hi!
>>
>> Here's CAN and CAN FD support for the R-Car D3. This is a by-the-datasheet
>> implementation, with the datasheet missing some bits, namely the pin map.
>> I filled in the gaps with frog DNA^W^W^Wby deducing the information from
>> pin numbers already in the PFC driver, so careful scrutiny is advised.
>>
>> CU
>> Uli
>>
>>
>> Ulrich Hecht (7):
>> pinctrl: sh-pfc: r8a77995: Add CAN support
>> pinctrl: sh-pfc: r8a77995: Add CAN FD support
>> arm64: dts: r8a77995: Add CAN external clock support
>> arm64: dts: r8a77995: Add CAN support
>> arm64: dts: r8a77995: Add CAN FD support
>> can: rcar_can: document r8a77995 (R-Car D3) compatibility strings
>> can: rcar_canfd: document r8a77995 (R-Car D3) compatibility strings
>
> Hi Ulrich,
>
> is it safe, from a regression point of view, to apply the dts patches
> to a tree that does not have the other patches present?
I believe it is.
CU
Uli
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 02/13] dt-bindings: Add SLIMbus bindings
From: Charles Keepax @ 2017-11-23 7:41 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland, alsa-devel, michael.opdenacker, poeschel,
srinivas.kandagatla, andreas.noever, arnd, vinod.koul, treding,
devicetree, james.hogan, pawel.moll, linux-arm-msm, sharon.dvir1,
broonie, sdharia, alan, bp, mathieu.poirier, gregkh, linux-kernel,
daniel, jkosina, joe, davem
In-Reply-To: <20171116051500.qlzgxglom2s3dhkt@rob-hp-laptop>
On Wed, Nov 15, 2017 at 11:15:00PM -0600, Rob Herring wrote:
> On Wed, Nov 15, 2017 at 02:10:32PM +0000, srinivas.kandagatla@linaro.org wrote:
> > From: Sagar Dharia <sdharia@codeaurora.org>
> >
> > SLIMbus (Serial Low Power Interchip Media Bus) is a specification
> > developed by MIPI (Mobile Industry Processor Interface) alliance.
> > SLIMbus is a 2-wire implementation, which is used to communicate with
> > peripheral components like audio-codec.
> >
> > This patch adds device tree bindings for the slimbus.
> >
> > Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
> > Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> > ---
> > Documentation/devicetree/bindings/slimbus/bus.txt | 50 +++++++++++++++++++++++
> > 1 file changed, 50 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/slimbus/bus.txt
>
> Reviewed-by: Rob Herring <robh@kernel.org>
I still have some reservations about the putting the MID and PID
in the compatible sting, are we sure this is what we want to do?
As has been discussed previous the discoverability of SLIMbus
is really theoretical since you really always need to bind a
driver to power on the device, since power is not part of the bus
itself.
Many devices (ours included) will support SLIMbus and other
interfaces, this means we will need a different compatible
string between SLIMbus and I2C/SPI, which feels a little
icky. Additionally it does make the compatible strings really
unreadable and which is a little annoying when looking at device
trees as you can't easily see what things are.
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH v7 07/13] slimbus: Add support for 'clock-pause' feature
From: Charles Keepax @ 2017-11-23 7:28 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: mark.rutland, alsa-devel, michael.opdenacker, poeschel,
andreas.noever, arnd, vinod.koul, treding, devicetree,
james.hogan, pawel.moll, linux-arm-msm, sharon.dvir1, robh+dt,
sdharia, alan, bp, mathieu.poirier, gregkh, linux-kernel, broonie,
daniel, jkosina, joe, davem
In-Reply-To: <20171115141043.29202-8-srinivas.kandagatla@linaro.org>
On Wed, Nov 15, 2017 at 02:10:37PM +0000, srinivas.kandagatla@linaro.org wrote:
> From: Sagar Dharia <sdharia@codeaurora.org>
>
> Per slimbus specification, a reconfiguration sequence known as
> 'clock pause' needs to be broadcast over the bus while entering low-
> power mode. Clock-pause is initiated by the controller driver.
> To exit clock-pause, controller typically wakes up the framer device.
> Since wakeup precedure is controller-specific, framework calls it via
> controller's function pointer to invoke it.
>
> Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> +/**
> + * struct slim_sched: Framework uses this structure internally for scheduling.
Missing kernel doc for clkgear here.
> + * @clk_state: Controller's clock state from enum slim_clk_state
> + * @pause_comp: Signals completion of clock pause sequence. This is useful when
> + * client tries to call slimbus transaction when controller is entering
> + * clock pause.
> + * @m_reconf: This mutex is held until current reconfiguration (data channel
> + * scheduling, message bandwidth reservation) is done. Message APIs can
> + * use the bus concurrently when this mutex is held since elemental access
> + * messages can be sent on the bus when reconfiguration is in progress.
> + */
> +struct slim_sched {
> + int clkgear;
> + enum slim_clk_state clk_state;
> + struct completion pause_comp;
> + struct mutex m_reconf;
> +};
Thanks,
Charles
^ permalink raw reply
* Re: [v4,2/3] drivers: hwmon: Add W83773G driver
From: Joel Stanley @ 2017-11-23 6:32 UTC (permalink / raw)
To: Guenter Roeck
Cc: Lei YU, Mark Rutland, Jean Delvare, Jonathan Corbet, Jiri Kosina,
devicetree, Linux Kernel Mailing List, linux-hwmon,
Andrew Jeffery
In-Reply-To: <20171118161533.GA2810@roeck-us.net>
On Sun, Nov 19, 2017 at 2:45 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Mon, Nov 13, 2017 at 11:27:33AM +0800, Lei YU wrote:
>> Nuvoton W83773G is a hardware monitor IC providing one local
>> temperature and two remote temperature sensors.
>>
>> Signed-off-by: Lei YU <mine260309@gmail.com>
>
> Applied to hwmon-next.
Where does hwmon-next live? I was looking on kernel.org and I can't
seem to find it.
Cheers,
Joel
^ permalink raw reply
* [PATCH] arm64: dts: Hi3660: Fix state id for 'CPU_NAP' state
From: Leo Yan @ 2017-11-23 5:40 UTC (permalink / raw)
To: Wei Xu, Mark Rutland, linux-arm-kernel, linux-kernel, Rob Herring,
devicetree
Cc: Leo Yan, Vincent Guittot, Daniel Lezcano
Thanks a lot for Vincent Guittot careful work to find bug for 'CPU_NAP'
idle state. From ftrace log we can observe CA73 CPUs can be easily waken
up from 'CPU_NAP' state but the 'waken up' CPUs doesn't handle anything
and sleep again; so there have tons of trace events for CA73 CPUs
entering and exiting idle state.
On Hi3660 CA73 has retention state 'CPU_NAP' for CPU idle, this state we
set its psci parameter as '0x0000001' and from this parameter it can
calculate state id is 1. Unfortunately ARM trusted firmware (ARM-TF)
takes 1 as a invalid value for state id, so the CPU cannot enter idle
state and directly bail out to kernel.
This commit changes psci parameter to '0x00000000' for state id = 0;
this id is accepted by ARM trusted firmware and finally CPU can stay
properly in 'CPU_NAP' state.
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index ab0b95b..5666d29 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -147,7 +147,7 @@
CPU_NAP: cpu-nap {
compatible = "arm,idle-state";
- arm,psci-suspend-param = <0x0000001>;
+ arm,psci-suspend-param = <0x0000000>;
entry-latency-us = <7>;
exit-latency-us = <2>;
min-residency-us = <15>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 3/5] media: i2c: Add TDA1997x HDMI receiver driver
From: Tim Harvey @ 2017-11-23 4:49 UTC (permalink / raw)
To: Hans Verkuil
Cc: linux-media, Rob Herring, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Shawn Guo,
Steve Longerbeam, Philipp Zabel, Mauro Carvalho Chehab,
Hans Verkuil
In-Reply-To: <20171116043059.azaqjfbjeo4rlaon@rob-hp-laptop>
On Wed, Nov 15, 2017 at 8:30 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Nov 15, 2017 at 10:31:14AM -0800, Tim Harvey wrote:
>> On Wed, Nov 15, 2017 at 7:52 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> > On Thu, Nov 09, 2017 at 10:45:34AM -0800, Tim Harvey wrote:
>> >> Add support for the TDA1997x HDMI receivers.
>> >>
>> >> Cc: Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
>> >> Signed-off-by: Tim Harvey <tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org>
>> >> ---
>> >> v3:
>> >> - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros
>> >> - fixed missing break
>> >> - use only hdmi_infoframe_log for infoframe logging
>> >> - simplify tda1997x_s_stream error handling
>> >> - add delayed work proc to handle hotplug enable/disable
>> >> - fix set_edid (disable HPD before writing, enable after)
>> >> - remove enabling edid by default
>> >> - initialize timings
>> >> - take quant range into account in colorspace conversion
>> >> - remove vendor/product tracking (we provide this in log_status via infoframes)
>> >> - add v4l_controls
>> >> - add more detail to log_status
>> >> - calculate vhref generator timings
>> >> - timing detection fixes (rounding errors, hswidth errors)
>> >> - rename configure_input/configure_conv functions
>> >>
>> >> v2:
>> >> - implement dv timings enum/cap
>> >> - remove deprecated g_mbus_config op
>> >> - fix dv_query_timings
>> >> - add EDID get/set handling
>> >> - remove max-pixel-rate support
>> >> - add audio codec DAI support
>> >> - change audio bindings
>> >> ---
>> >> drivers/media/i2c/Kconfig | 9 +
>> >> drivers/media/i2c/Makefile | 1 +
>> >> drivers/media/i2c/tda1997x.c | 3485 ++++++++++++++++++++++++++++++++++
>> >> include/dt-bindings/media/tda1997x.h | 78 +
>> >
>> > This belongs with the binding documentation patch.
>> >
>>
>> Rob,
>>
>> Thanks - missed that. I will move it for v4.
>>
>> Regarding your previous comment to the v2 series:
>> > The rest of the binding looks fine, but I have some reservations about
>> > this. I think this should be common probably. There's been a few
>> > bindings for display recently that deal with the interface format. Maybe
>> > some vendor property is needed here to map a standard interface format
>> > back to pin configuration.
>>
>> I take it this is not an 'Ack' for the bindings?
>>
>> Which did you feel should be made common? I admit I was surprised
>> there wasn't a common binding for audio bus format (i2s|spdif) but if
>> you were referring to the video data that would probably be much more
>> complicated.
>
> The video data. Either you have to try to come up with some way to map
> color components to signals/pins (and even cycles) or you just enumerate
> the formats and keep adding to them when new ones appear. There's h/w
> that allows the former, but in the end you have to interoperate, so
> enumerating the formats is probably enough.
>
>> I was hoping one of the media/driver maintainers would respond to your
>> comment with thoughts as I'm not familiar with a very wide variety of
>> receivers.
>
> I am hoping, too.
>
> Rob
Hans,
Do you have any comment here regarding Rob's hope that there could be
some generic properties created for video port bindings? Anyone else
you know of who should chime in here?
The TDA1997x allows mapping its internal video output bus to its
physical pin in a fairly flexible way. I don't know how unique this is
to other chips.
Regards,
Tim
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/5] media: dt-bindings: Add bindings for TDA1997X
From: Tim Harvey @ 2017-11-23 4:37 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-media, alsa-devel, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Shawn Guo, Steve Longerbeam,
Philipp Zabel, Hans Verkuil, Mauro Carvalho Chehab, Rob Herring
In-Reply-To: <20171122073606.56ldk3bzg23dkkfm@valkosipuli.retiisi.org.uk>
On Tue, Nov 21, 2017 at 11:36 PM, Sakari Ailus <sakari.ailus@iki.fi> wrote:
> Hi Tim,
>
> On Thu, Nov 09, 2017 at 10:45:33AM -0800, Tim Harvey wrote:
>> Cc: Rob Herring <robh@kernel.org>
>> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
>> ---
>> v3:
>> - fix typo
>>
>> v2:
>> - add vendor prefix and remove _ from vidout-portcfg
>> - remove _ from labels
>> - remove max-pixel-rate property
>> - describe and provide example for single output port
>> - update to new audio port bindings
>> ---
>> .../devicetree/bindings/media/i2c/tda1997x.txt | 179 +++++++++++++++++++++
>> 1 file changed, 179 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
>> new file mode 100644
>> index 0000000..dd37f14
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
>> @@ -0,0 +1,179 @@
>> +Device-Tree bindings for the NXP TDA1997x HDMI receiver
>> +
>> +The TDA19971/73 are HDMI video receivers.
>> +
>> +The TDA19971 Video port output pins can be used as follows:
>> + - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
>> + - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
>> + - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
>> + - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
>> + - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
>> + - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
>> + - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
>> + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
>> +
>> +The TDA19973 Video port output pins can be used as follows:
>> + - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
>> + - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
>> + - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
>> + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
>> +
>> +The Video port output pins are mapped via 4-bit 'pin groups' allowing
>> +for a variety of connection possibilities including swapping pin order within
>> +pin groups. The video_portcfg device-tree property consists of register mapping
>> +pairs which map a chip-specific VP output register to a 4-bit pin group. If
>> +the pin group needs to be bit-swapped you can use the *_S pin-group defines.
>> +
>> +Required Properties:
>> + - compatible :
>> + - "nxp,tda19971" for the TDA19971
>> + - "nxp,tda19973" for the TDA19973
>> + - reg : I2C slave address
>> + - interrupts : The interrupt number
>> + - DOVDD-supply : Digital I/O supply
>> + - DVDD-supply : Digital Core supply
>> + - AVDD-supply : Analog supply
>> + - nxp,vidout-portcfg : array of pairs mapping VP output pins to pin groups.
>> +
>> +Optional Properties:
>> + - nxp,audout-format : DAI bus format: "i2s" or "spdif".
>> + - nxp,audout-width : width of audio output data bus (1-4).
>> + - nxp,audout-layout : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
>> + - nxp,audout-mclk-fs : Multiplication factor between stream rate and codec
>> + mclk.
>> +
>> +The device node must contain one 'port' child node for its digital output
>> +video port, in accordance with the video interface bindings defined in
>> +Documentation/devicetree/bindings/media/video-interfaces.txt.
>
> Could you add that this port has one endpoint node as well? (Unless you
> support multiple, that is.)
Sure... will clarify as:
The device node must contain one endpoint 'port' child node for its
digital output
video port, in accordance with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
>> +
>> +Optional Endpoint Properties:
>> + The following three properties are defined in video-interfaces.txt and
>> + are valid for source endpoints only:
>
> Transmitters? Don't you have an endpoint only in the port representing the
> transmitter?
I'm not usre what you mean.
The TDA1997x is an HDMI receiver meaning it receives HDMI and decodes
it to a parallel video bus. HDMI transmitters are the opposite.
Regards,
Tim
^ permalink raw reply
* Re: [PATCH 3/5] media: i2c: Add TDA1997x HDMI receiver driver
From: Tim Harvey @ 2017-11-23 4:27 UTC (permalink / raw)
To: Hans Verkuil
Cc: linux-media, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Shawn Guo,
Steve Longerbeam, Philipp Zabel, Hans Verkuil,
Mauro Carvalho Chehab
In-Reply-To: <4048cb21-c65c-6282-a1d7-81ad9a0d7cfa-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
On Mon, Nov 20, 2017 at 7:39 AM, Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> wrote:
> Hi Tim,
>
> Some more review comments:
>
> On 11/09/2017 07:45 PM, Tim Harvey wrote:
>> Add support for the TDA1997x HDMI receivers.
<snip>
>> + */
>> +struct color_matrix_coefs {
>> + const char *name;
>> + /* Input offsets */
>> + s16 offint1;
>> + s16 offint2;
>> + s16 offint3;
>> + /* Coeficients */
>> + s16 p11coef;
>> + s16 p12coef;
>> + s16 p13coef;
>> + s16 p21coef;
>> + s16 p22coef;
>> + s16 p23coef;
>> + s16 p31coef;
>> + s16 p32coef;
>> + s16 p33coef;
>> + /* Output offsets */
>> + s16 offout1;
>> + s16 offout2;
>> + s16 offout3;
>> +};
>> +
>> +enum {
>> + ITU709_RGBLIMITED,
>> + ITU709_RGBFULL,
>> + ITU601_RGBLIMITED,
>> + ITU601_RGBFULL,
>> + RGBLIMITED_RGBFULL,
>> + RGBLIMITED_ITU601,
>> + RGBFULL_ITU601,
>
> This can't be right.
>ITU709_RGBLIMITED
> You have these conversions:
>
> ITU709_RGBFULL
> ITU601_RGBFULL
> RGBLIMITED_RGBFULL
> RGBLIMITED_ITU601
> RGBFULL_ITU601
> RGBLIMITED_ITU709
> RGBFULL_ITU709
>
> I.e. on the HDMI receiver side you can receive RGB full/limited or ITU601/709.
> On the output side you have RGB full or ITU601/709.
>
> So something like ITU709_RGBLIMITED makes no sense.
>
I misunderstood the V4L2_CID_DV_RX_RGB_RANGE thinking that it allowed
you to configure the output range. If output to the SoC is only ever
full quant range for RGB then I can drop the
ITU709_RGBLIMITED/ITU601_RGBLIMITED conversions.
However, If the output is YUV how do I know if I need to convert to
ITU709 or ITU601 and what are my conversion matrices for
RGBLIMITED_ITU709/RGBFULL_ITU709?
Sorry for all the questions, the colorspace/colorimetry options
confuse the heck out of me.
>> +};
>> +
<snip>
>> +
>> +/* parse an infoframe and do some sanity checks on it */
>> +static unsigned int
>> +tda1997x_parse_infoframe(struct tda1997x_state *state, u16 addr)
>> +{
>> + struct v4l2_subdev *sd = &state->sd;
>> + union hdmi_infoframe frame;
>> + u8 buffer[40];
>> + u8 reg;
>> + int len, err;
>> +
>> + /* read data */
>> + len = io_readn(sd, addr, sizeof(buffer), buffer);
>> + err = hdmi_infoframe_unpack(&frame, buffer);
>> + if (err) {
>> + v4l_err(state->client,
>> + "failed parsing %d byte infoframe: 0x%04x/0x%02x\n",
>> + len, addr, buffer[0]);
>> + return err;
>> + }
>> + hdmi_infoframe_log(KERN_INFO, &state->client->dev, &frame);
>> + switch (frame.any.type) {
>> + /* Audio InfoFrame: see HDMI spec 8.2.2 */
>> + case HDMI_INFOFRAME_TYPE_AUDIO:
>> + /* sample rate */
>> + switch (frame.audio.sample_frequency) {
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_32000:
>> + state->audio_samplerate = 32000;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_44100:
>> + state->audio_samplerate = 44100;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_48000:
>> + state->audio_samplerate = 48000;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_88200:
>> + state->audio_samplerate = 88200;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_96000:
>> + state->audio_samplerate = 96000;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_176400:
>> + state->audio_samplerate = 176400;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_192000:
>> + state->audio_samplerate = 192000;
>> + break;
>> + default:
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM:
>> + break;
>> + }
>> +
>> + /* sample size */
>> + switch (frame.audio.sample_size) {
>> + case HDMI_AUDIO_SAMPLE_SIZE_16:
>> + state->audio_samplesize = 16;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_SIZE_20:
>> + state->audio_samplesize = 20;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_SIZE_24:
>> + state->audio_samplesize = 24;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_SIZE_STREAM:
>> + default:
>> + break;
>> + }
>> +
>> + /* Channel Count */
>> + state->audio_channels = frame.audio.channels;
>> + if (frame.audio.channel_allocation &&
>> + frame.audio.channel_allocation != state->audio_ch_alloc) {
>> + /* use the channel assignment from the infoframe */
>> + state->audio_ch_alloc = frame.audio.channel_allocation;
>> + tda1997x_configure_audout(sd, state->audio_ch_alloc);
>> + /* reset the audio FIFO */
>> + tda1997x_hdmi_info_reset(sd, RESET_AUDIO, false);
>> + }
>> + break;
>> +
>> + /* Auxiliary Video information (AVI) InfoFrame: see HDMI spec 8.2.1 */
>> + case HDMI_INFOFRAME_TYPE_AVI:
>> + state->colorspace = frame.avi.colorspace;
>> + state->colorimetry = frame.avi.colorimetry;
>> + state->range = frame.avi.quantization_range;
>
> This should be ignored if it is overridden by the RGB Quantization Range
> control, or am I missing something?
>
Ok. Sounds like I should only use the range from the infoframe if
range == V4L2_DV_RGB_RANGE_AUTO:
/* Quantization Range */
if (state->range == V4L2_DV_RGB_RANGE_AUTO)
state->range = frame.avi.quantization_range;
if (state->range == HDMI_QUANTIZATION_RANGE_DEFAULT) {
if (frame.avi.video_code <= 1)
state->range = HDMI_QUANTIZATION_RANGE_FULL;
else
state->range = HDMI_QUANTIZATION_RANGE_LIMITED;
}
>> + state->content = frame.avi.content_type;
>> + /*
>> + * If colorimetry not specified, conversion depends on res type:
>> + * - SDTV: ITU601 for SD (480/576/240/288 line resolution)
>> + * - HDTV: ITU709 for HD (720/1080 line resolution)
>> + * - PC: sRGB
>> + * see HDMI specification section 6.7
>> + */
>> + if ((state->colorspace == HDMI_COLORSPACE_YUV422 ||
>> + state->colorspace == HDMI_COLORSPACE_YUV444) &&
>> + (state->colorimetry == HDMI_COLORIMETRY_EXTENDED ||
>> + state->colorimetry == HDMI_COLORIMETRY_NONE)) {
>> + switch (state->timings.bt.height) {
>> + case 480:
>> + case 576:
>> + case 240:
>> + case 288:
>> + state->colorimetry = HDMI_COLORIMETRY_ITU_601;
>> + break;
>> + case 720:
>> + case 1080:
>> + state->colorimetry = HDMI_COLORIMETRY_ITU_709;
>> + break;
>> + default:
>> + state->colorimetry = HDMI_COLORIMETRY_NONE;
>> + break;
>> + }
>> + }
>> + /* if range not specified */
>> + if (state->range == HDMI_QUANTIZATION_RANGE_DEFAULT) {
>> + if (frame.avi.video_code == 0)
>
> This should be:
>
> if (frame.avi.video_code <= 1)
>
> VIC code 1 (VGA) is also full range. It's an exception to the rule.
ok
Thanks,
Tim
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V5 10/12] clk: sprd: add clocks support for SC9860
From: kbuild test robot @ 2017-11-23 2:34 UTC (permalink / raw)
To: Chunyan Zhang
Cc: kbuild-all-JC7UmRfGjtg, Stephen Boyd, Michael Turquette,
Rob Herring, Mark Rutland, Catalin Marinas, Will Deacon,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
Mark Brown, Xiaolong Zhang, Ben Li, Orson Zhai, Chunyan Zhang
In-Reply-To: <20171120060137.27380-11-chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3275 bytes --]
Hi Chunyan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on clk/clk-next]
[also build test WARNING on v4.14 next-20171122]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Chunyan-Zhang/add-clock-driver-for-Spreadtrum-platforms/20171123-072852
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All warnings (new ones prefixed by >>):
>> drivers/clk/sprd/sc9860-clk.c:128:18: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
static const u64 const itable1[4] = {3, 780000000, 988000000, 1196000000};
^~~~~
drivers/clk/sprd/sc9860-clk.c:133:35: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
static const struct clk_bit_field const f_mpll0[PLL_FACT_MAX] = {
^~~~~
drivers/clk/sprd/sc9860-clk.c:150:35: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
static const struct clk_bit_field const f_mpll1[PLL_FACT_MAX] = {
^~~~~
drivers/clk/sprd/sc9860-clk.c:166:35: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
static const struct clk_bit_field const f_dpll[PLL_FACT_MAX] = {
^~~~~
drivers/clk/sprd/sc9860-clk.c:185:35: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
static const struct clk_bit_field const f_rpll[PLL_FACT_MAX] = {
^~~~~
drivers/clk/sprd/sc9860-clk.c:204:35: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
static const struct clk_bit_field const f_twpll[PLL_FACT_MAX] = {
^~~~~
drivers/clk/sprd/sc9860-clk.c:220:35: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
static const struct clk_bit_field const f_ltepll[PLL_FACT_MAX] = {
^~~~~
drivers/clk/sprd/sc9860-clk.c:240:35: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
static const struct clk_bit_field const f_gpll[PLL_FACT_MAX] = {
^~~~~
drivers/clk/sprd/sc9860-clk.c:257:35: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
static const struct clk_bit_field const f_cppll[PLL_FACT_MAX] = {
^~~~~
vim +/const +128 drivers/clk/sprd/sc9860-clk.c
126
127 /* GPLL/LPLL/DPLL/RPLL/CPLL */
> 128 static const u64 const itable1[4] = {3, 780000000, 988000000, 1196000000};
129
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 36946 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.
From: Yong @ 2017-11-23 1:14 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Greg Kroah-Hartman, David S. Miller, Hans Verkuil, Arnd Bergmann,
Hugues Fruchet, Yannick Fertre, Philipp Zabel, Benoit Parrot,
Benjamin Gaignard, Jean-Christophe Trotin,
Ramesh Shanmugasundaram, Minghsiu Tsai, Krzysztof Kozlowski,
Robert Jarzmik, linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-sun
In-Reply-To: <20171122094526.nqxfy2e5jzxw7nl4-ZC1Zs529Oq4@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3389 bytes --]
Hi,
On Wed, 22 Nov 2017 10:45:26 +0100
Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi,
>
> On Wed, Nov 22, 2017 at 09:33:06AM +0800, Yong wrote:
> > > On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote:
> > > > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > > > and CSI1 is used for parallel interface. This is not documented in
> > > > datasheet but by testing and guess.
> > > >
> > > > This patch implement a v4l2 framework driver for it.
> > > >
> > > > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > > > ISP's support are not included in this patch.
> > > >
> > > > Signed-off-by: Yong Deng <yong.deng-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
> > >
> > > Thanks again for this driver.
> > >
> > > It seems like at least this iteration is behaving in a weird way with
> > > DMA transfers for at least YU12 and NV12 (and I would assume YV12).
> > >
> > > Starting a transfer of multiple frames in either of these formats,
> > > using either ffmpeg (ffmpeg -f v4l2 -video_size 640x480 -framerate 30
> > > -i /dev/video0 output.mkv) or yavta (yavta -c80 -p -F --skip 0 -f NV12
> > > -s 640x480 $(media-c tl -e 'sun6i-csi')) will end up in a panic.
> > >
> > > The panic seems to be generated with random data going into parts of
> > > the kernel memory, the pattern being in my case something like
> > > 0x8287868a which is very odd (always around 0x88)
> > >
> > > It turns out that when you cover the sensor, the values change to
> > > around 0x28, so it really seems like it's pixels that have been copied
> > > there.
> > >
> > > I've looked quickly at the DMA setup, and it seems reasonable to
> > > me. Do you have the same issue on your side? Have you been able to
> > > test those formats using your hardware?
> >
> > I had tested the following formats with BT1120 input:
> > V4L2_PIX_FMT_NV12 -> NV12
> > V4L2_PIX_FMT_NV21 -> NV21
> > V4L2_PIX_FMT_NV16 -> NV16
> > V4L2_PIX_FMT_NV61 -> NV61
> > V4L2_PIX_FMT_YUV420 -> YU12
> > V4L2_PIX_FMT_YVU420 -> YV12
> > V4L2_PIX_FMT_YUV422P -> 422P
> > And they all work fine.
>
> Ok, that's good to know.
>
> > > Given that they all are planar formats and YUYV and the likes work
> > > just fine, maybe we can leave them aside for now?
> >
> > V4L2_PIX_FMT_YUV422P and V4L2_PIX_FMT_YUYV is OK, and V4L2_PIX_FMT_NV12
> > is bad? It's really weird.
> >
> > What's your input bus code format, type and width?
>
> The sensor is an ov5640, so the MBUS code for the bus is
> MEDIA_BUS_FMT_YUYV8_2X8.
Did you test on V3s?
I haven't tested it with MEDIA_BUS_FMT_YUYV8_2X8.
The Allwinner CSI's DMA is definitely weird. Ondřej Jirman thought
that CSI has an internal queue (Ondřej's commit has explained in detail).
I think CSI just pick up the buffer address before the frame done
interrupt triggered.
The patch in attachment can deal with this. You can see if it is
useful to solve your problem.
Thanks,
Yong
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: sun6i_csi_fix_writing_to_incorrect_buffer.patch --]
[-- Type: application/octet-stream, Size: 10429 bytes --]
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index 3f4de09..80bc40b 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -566,7 +566,7 @@ int sun6i_csi_update_config(struct sun6i_csi *csi,
return 0;
}
-int sun6i_csi_update_buf_addr(struct sun6i_csi *csi, dma_addr_t addr)
+void sun6i_csi_update_buf_addr(struct sun6i_csi *csi, dma_addr_t addr)
{
struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
/* transform physical address to bus address */
@@ -580,11 +580,9 @@ int sun6i_csi_update_buf_addr(struct sun6i_csi *csi, dma_addr_t addr)
if (sdev->planar_offset[2] != -1)
regmap_write(sdev->regmap, CSI_CH_F2_BUFA_REG,
(bus_addr + sdev->planar_offset[2]) >> 2);
-
- return 0;
}
-int sun6i_csi_set_stream(struct sun6i_csi *csi, bool enable)
+void sun6i_csi_set_stream(struct sun6i_csi *csi, bool enable)
{
struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
struct regmap *regmap = sdev->regmap;
@@ -592,7 +590,7 @@ int sun6i_csi_set_stream(struct sun6i_csi *csi, bool enable)
if (!enable) {
regmap_update_bits(regmap, CSI_CAP_REG, CSI_CAP_CH0_VCAP_ON, 0);
regmap_write(regmap, CSI_CH_INT_EN_REG, 0);
- return 0;
+ return;
}
regmap_write(regmap, CSI_CH_INT_STA_REG, 0xFF);
@@ -606,8 +604,6 @@ int sun6i_csi_set_stream(struct sun6i_csi *csi, bool enable)
regmap_update_bits(regmap, CSI_CAP_REG, CSI_CAP_CH0_VCAP_ON,
CSI_CAP_CH0_VCAP_ON);
-
- return 0;
}
/* -----------------------------------------------------------------------------
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
index 12508ff..9bc758b 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
@@ -92,14 +92,14 @@ int sun6i_csi_update_config(struct sun6i_csi *csi,
* @csi: pointer to the csi
* @addr: frame buffer's physical address
*/
-int sun6i_csi_update_buf_addr(struct sun6i_csi *csi, dma_addr_t addr);
+void sun6i_csi_update_buf_addr(struct sun6i_csi *csi, dma_addr_t addr);
/**
* sun6i_csi_set_stream() - start/stop csi streaming
* @csi: pointer to the csi
* @enable: start/stop
*/
-int sun6i_csi_set_stream(struct sun6i_csi *csi, bool enable);
+void sun6i_csi_set_stream(struct sun6i_csi *csi, bool enable);
static inline int v4l2_pixformat_get_bpp(unsigned int pixformat)
{
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c b/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
index 0cebcbd..0819b71 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
@@ -29,6 +29,7 @@ struct sun6i_csi_buffer {
struct list_head list;
dma_addr_t dma_addr;
+ bool queued_to_csi;
};
static struct sun6i_csi_format *
@@ -135,6 +136,7 @@ static int sun6i_video_start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct sun6i_video *video = vb2_get_drv_priv(vq);
struct sun6i_csi_buffer *buf;
+ struct sun6i_csi_buffer *next_buf;
struct sun6i_csi_config config;
unsigned long flags;
int ret;
@@ -143,11 +145,7 @@ static int sun6i_video_start_streaming(struct vb2_queue *vq, unsigned int count)
ret = media_pipeline_start(&video->vdev.entity, &video->vdev.pipe);
if (ret < 0)
- goto err_start_pipeline;
-
- ret = sun6i_pipeline_set_stream(video, true);
- if (ret < 0)
- goto err_start_stream;
+ goto clear_dma_queue;
config.pixelformat = video->fmt.fmt.pix.pixelformat;
config.code = video->current_fmt->mbus_code;
@@ -157,31 +155,50 @@ static int sun6i_video_start_streaming(struct vb2_queue *vq, unsigned int count)
ret = sun6i_csi_update_config(video->csi, &config);
if (ret < 0)
- goto err_update_config;
+ goto stop_media_pipeline;
spin_lock_irqsave(&video->dma_queue_lock, flags);
- video->cur_frm = list_first_entry(&video->dma_queue,
- struct sun6i_csi_buffer, list);
- list_del(&video->cur_frm->list);
- spin_unlock_irqrestore(&video->dma_queue_lock, flags);
- ret = sun6i_csi_update_buf_addr(video->csi, video->cur_frm->dma_addr);
- if (ret < 0)
- goto err_update_addr;
+ buf = list_first_entry(&video->dma_queue,
+ struct sun6i_csi_buffer, list);
+ buf->queued_to_csi = true;
+ sun6i_csi_update_buf_addr(video->csi, buf->dma_addr);
+
+ sun6i_csi_set_stream(video->csi, true);
+
+ /* CSI will lookup the next dma buffer for next frame before the
+ * the current frame done IRQ triggered. This is not documented
+ * but reported by Ondřej Jirman.
+ * The BSP code has workaround for this too. It skip to mark the
+ * first buffer as frame done for VB2 and pass the second buffer
+ * to CSI in the first frame done ISR call. Then in second frame
+ * done ISR call, it mark the first buffer as frame done for VB2
+ * and pass the third buffer to CSI. And so on. The bad thing is
+ * that the first buffer will be written twice and the first frame
+ * is dropped even the queued buffer is sufficient.
+ * So, I make some improvement here. Pass the next buffer to CSI
+ * just follow starting the CSI. In this case, the first frame
+ * will be stored in first buffer, second frame in second buffer.
+ * This mothed is used to avoid dropping the first frame, it
+ * would also drop frame when lack of queued buffer.
+ */
+ next_buf = list_next_entry(buf, list);
+ next_buf->queued_to_csi = true;
+ sun6i_csi_update_buf_addr(video->csi, next_buf->dma_addr);
- ret = sun6i_csi_set_stream(video->csi, true);
+ spin_unlock_irqrestore(&video->dma_queue_lock, flags);
+
+ ret = sun6i_pipeline_set_stream(video, true);
if (ret < 0)
- goto err_csi_stream;
+ goto stop_csi_stream;
return 0;
-err_csi_stream:
-err_update_addr:
-err_update_config:
- sun6i_pipeline_set_stream(video, false);
-err_start_stream:
+stop_csi_stream:
+ sun6i_csi_set_stream(video->csi, false);
+stop_media_pipeline:
media_pipeline_stop(&video->vdev.entity);
-err_start_pipeline:
+clear_dma_queue:
spin_lock_irqsave(&video->dma_queue_lock, flags);
list_for_each_entry(buf, &video->dma_queue, list)
vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_QUEUED);
@@ -205,11 +222,6 @@ static void sun6i_video_stop_streaming(struct vb2_queue *vq)
/* Release all active buffers */
spin_lock_irqsave(&video->dma_queue_lock, flags);
- if (unlikely(video->cur_frm)) {
- vb2_buffer_done(&video->cur_frm->vb.vb2_buf,
- VB2_BUF_STATE_ERROR);
- video->cur_frm = NULL;
- }
list_for_each_entry(buf, &video->dma_queue, list)
vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_ERROR);
INIT_LIST_HEAD(&video->dma_queue);
@@ -225,39 +237,58 @@ static void sun6i_video_buffer_queue(struct vb2_buffer *vb)
unsigned long flags;
spin_lock_irqsave(&video->dma_queue_lock, flags);
- if (!video->cur_frm && list_empty(&video->dma_queue) &&
- vb2_is_streaming(vb->vb2_queue)) {
- video->cur_frm = buf;
- sun6i_csi_update_buf_addr(video->csi, video->cur_frm->dma_addr);
- sun6i_csi_set_stream(video->csi, 1);
- } else
- list_add_tail(&buf->list, &video->dma_queue);
+ buf->queued_to_csi = false;
+ list_add_tail(&buf->list, &video->dma_queue);
spin_unlock_irqrestore(&video->dma_queue_lock, flags);
}
void sun6i_video_frame_done(struct sun6i_video *video)
{
+ struct sun6i_csi_buffer *buf;
+ struct sun6i_csi_buffer *next_buf;
+ struct vb2_v4l2_buffer *vbuf ;
+
spin_lock(&video->dma_queue_lock);
- if (video->cur_frm) {
- struct vb2_v4l2_buffer *vbuf = &video->cur_frm->vb;
- struct vb2_buffer *vb = &vbuf->vb2_buf;
+ video->sequence++;
+
+ buf = list_first_entry(&video->dma_queue,
+ struct sun6i_csi_buffer, list);
+ if (list_is_last(&buf->list, &video->dma_queue)) {
+ dev_dbg(video->csi->dev, "Frame droped!\n");
+ goto unlock;
+ }
- vb->timestamp = ktime_get_ns();
- vbuf->sequence = video->sequence++;
- vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
- video->cur_frm = NULL;
+ next_buf = list_next_entry(buf, list);
+ /* If a new buffer (#next_buf) had not been queued to CSI, the old
+ * buffer (#buf) is still holding by CSI for storing the next
+ * frame. So, we queue a new buffer (#next_buf) to CSI then wait
+ * for next ISR call.
+ */
+ if (!next_buf->queued_to_csi) {
+ next_buf->queued_to_csi = true;
+ sun6i_csi_update_buf_addr(video->csi, next_buf->dma_addr);
+ dev_dbg(video->csi->dev, "Frame droped!\n");
+ goto unlock;
}
- if (!list_empty(&video->dma_queue)
- && vb2_is_streaming(&video->vb2_vidq)) {
- video->cur_frm = list_first_entry(&video->dma_queue,
- struct sun6i_csi_buffer, list);
- list_del(&video->cur_frm->list);
- sun6i_csi_update_buf_addr(video->csi, video->cur_frm->dma_addr);
- } else
- sun6i_csi_set_stream(video->csi, 0);
+ list_del(&buf->list);
+ vbuf = &buf->vb;
+ vbuf->vb2_buf.timestamp = ktime_get_ns();
+ vbuf->sequence = video->sequence;
+ vb2_buffer_done(&vbuf->vb2_buf, VB2_BUF_STATE_DONE);
+ if (list_is_last(&next_buf->list, &video->dma_queue))
+ goto unlock;
+
+ /* Prepare buffer for next frame but one. */
+ next_buf = list_next_entry(next_buf, list);
+ if (!list_is_last(&next_buf->list, &video->dma_queue)) {
+ next_buf->queued_to_csi = true;
+ sun6i_csi_update_buf_addr(video->csi, next_buf->dma_addr);
+ }
+
+unlock:
spin_unlock(&video->dma_queue_lock);
}
@@ -664,7 +695,6 @@ int sun6i_video_init(struct sun6i_video *video, struct sun6i_csi *csi,
INIT_LIST_HEAD(&video->dma_queue);
spin_lock_init(&video->dma_queue_lock);
- video->cur_frm = NULL;
video->sequence = 0;
video->num_formats = 0;
@@ -677,7 +707,7 @@ int sun6i_video_init(struct sun6i_video *video, struct sun6i_csi *csi,
vidq->mem_ops = &vb2_dma_contig_memops;
vidq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
vidq->lock = &video->lock;
- vidq->min_buffers_needed = 1;
+ vidq->min_buffers_needed = 2;
vidq->dev = csi->dev;
ret = vb2_queue_init(vidq);
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h b/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
index 14eac6e..b5a3d34 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
@@ -43,7 +43,6 @@ struct sun6i_video {
spinlock_t dma_queue_lock;
struct list_head dma_queue;
- struct sun6i_csi_buffer *cur_frm;
unsigned int sequence;
struct sun6i_csi_format *formats;
^ permalink raw reply related
* Re: [PATCH 1/2] usb: xhci: add relaxed timing quirk bit
From: Adam Wallis @ 2017-11-22 23:32 UTC (permalink / raw)
To: Mathias Nyman, Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Greg Kroah-Hartman, Mathias Nyman, Linux USB List,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Rutland,
Timur Tabi, Chunfeng Yun
In-Reply-To: <ee0ca959-1812-a4e4-346f-d57a1fdade13-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 11/22/2017 10:24 AM, Mathias Nyman wrote:
[..]
>
> We know have at least two hosts/platforms that need custom interrupt moderation
> values
>
> How about adding a u32 device property for xhci with the interrupt moderation
> interval in
> nanoseconds? And also add a u32 imod_interval variable to struct xhci_hcd?
>
> imod_interval can be set to the current default 40000ns (160*250ns) and
> overwritten if
> device_property_read_u32() returns something else.
>
Isn't the 160 value quite aggressive anyway? Section 5.5.2.2 of the xHCI spec
says that maximum observable interrupt rate should never exceed 8000
interrupts/second. I believe the IMOD value in the most aggressive case would
then be 500 by this statement [ 1 / (250e-9 * 500) = 8000 irqs/second ]
Perhaps I am misreading the spec or just doing the math wrong? With the default
value of 160, we are interrupting 25,000 irq/second...which is over 3 times the
maximum stated value (again, assuming I did the math right)
Anyway, my preference would be to set the IMOD default val to 4000 (~1ms) per
the recommended value in Table 49 of the spec and allow platforms to adjust as
necessary from that point.
Thoughts on this?
> XHCI_MTK_HOST could then use whatever preferred device propery interval value,
> and we can get rid of using XHCI_MTK_HOST quirk flag when setting up the IMODI
>
> -Mathias
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Adam
--
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [v5 RESEND 14/17] ASoC: madera: Add common support for Cirrus Logic Madera codecs
From: kbuild test robot @ 2017-11-22 23:13 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: kbuild-all, lee.jones, broonie, linus.walleij, gnurou, robh+dt,
tglx, jason, alsa-devel, patches, linux-gpio, devicetree,
linux-kernel, Richard Fitzgerald, Charles Keepax, Nariman Poushin,
Nikesh Oswal, Piotr Stankiewicz, Ajit Pandey
In-Reply-To: <d2a67476-5cc7-4052-a9cf-8b511e48dd1d@EX17.ad.cirrus.com>
[-- Attachment #1: Type: text/plain, Size: 8182 bytes --]
Hi Richard,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on next-20171122]
[cannot apply to ljones-mfd/for-mfd-next asoc/for-next v4.14]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Richard-Fitzgerald/Add-support-for-Cirrus-Logic-CS47L35-L85-L90-L91-codecs/20171123-054144
config: blackfin-allyesconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin
All warnings (new ones prefixed by >>):
drivers/mfd/madera-i2c.c: In function 'madera_i2c_probe':
>> drivers/mfd/madera-i2c.c:34:2: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if (i2c->dev.of_node)
^~
drivers/mfd/madera-i2c.c:36:3: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
if (of_id)
^~
>> drivers/mfd/madera-i2c.c:37:31: warning: 'of_id' may be used uninitialized in this function [-Wmaybe-uninitialized]
type = (unsigned long)of_id->data;
~~~~~^~~~~~
--
drivers/mfd/madera-spi.c: In function 'madera_spi_probe':
>> drivers/mfd/madera-spi.c:34:2: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if (spi->dev.of_node)
^~
drivers/mfd/madera-spi.c:36:3: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
if (of_id)
^~
>> drivers/mfd/madera-spi.c:37:31: warning: 'of_id' may be used uninitialized in this function [-Wmaybe-uninitialized]
type = (unsigned long)of_id->data;
~~~~~^~~~~~
vim +/if +34 drivers/mfd/madera-i2c.c
6d2961b1 Richard Fitzgerald 2017-11-20 22
6d2961b1 Richard Fitzgerald 2017-11-20 23 static int madera_i2c_probe(struct i2c_client *i2c,
6d2961b1 Richard Fitzgerald 2017-11-20 24 const struct i2c_device_id *id)
6d2961b1 Richard Fitzgerald 2017-11-20 25 {
6d2961b1 Richard Fitzgerald 2017-11-20 26 struct madera *madera;
6d2961b1 Richard Fitzgerald 2017-11-20 27 const struct regmap_config *regmap_16bit_config = NULL;
6d2961b1 Richard Fitzgerald 2017-11-20 28 const struct regmap_config *regmap_32bit_config = NULL;
6d2961b1 Richard Fitzgerald 2017-11-20 29 const struct of_device_id *of_id;
6d2961b1 Richard Fitzgerald 2017-11-20 30 unsigned long type = 0;
6d2961b1 Richard Fitzgerald 2017-11-20 31 const char *name;
6d2961b1 Richard Fitzgerald 2017-11-20 32 int ret;
6d2961b1 Richard Fitzgerald 2017-11-20 33
6d2961b1 Richard Fitzgerald 2017-11-20 @34 if (i2c->dev.of_node)
6d2961b1 Richard Fitzgerald 2017-11-20 35 of_id = of_match_device(madera_of_match, &i2c->dev);
6d2961b1 Richard Fitzgerald 2017-11-20 36 if (of_id)
6d2961b1 Richard Fitzgerald 2017-11-20 @37 type = (unsigned long)of_id->data;
6d2961b1 Richard Fitzgerald 2017-11-20 38 else
6d2961b1 Richard Fitzgerald 2017-11-20 39 type = id->driver_data;
6d2961b1 Richard Fitzgerald 2017-11-20 40
6d2961b1 Richard Fitzgerald 2017-11-20 41 switch (type) {
6d2961b1 Richard Fitzgerald 2017-11-20 42 case CS47L35:
6d2961b1 Richard Fitzgerald 2017-11-20 43 if (IS_ENABLED(CONFIG_MFD_CS47L35)) {
6d2961b1 Richard Fitzgerald 2017-11-20 44 regmap_16bit_config = &cs47l35_16bit_i2c_regmap;
6d2961b1 Richard Fitzgerald 2017-11-20 45 regmap_32bit_config = &cs47l35_32bit_i2c_regmap;
6d2961b1 Richard Fitzgerald 2017-11-20 46 }
6d2961b1 Richard Fitzgerald 2017-11-20 47 break;
6d2961b1 Richard Fitzgerald 2017-11-20 48 case CS47L85:
6d2961b1 Richard Fitzgerald 2017-11-20 49 case WM1840:
6d2961b1 Richard Fitzgerald 2017-11-20 50 if (IS_ENABLED(CONFIG_MFD_CS47L85)) {
6d2961b1 Richard Fitzgerald 2017-11-20 51 regmap_16bit_config = &cs47l85_16bit_i2c_regmap;
6d2961b1 Richard Fitzgerald 2017-11-20 52 regmap_32bit_config = &cs47l85_32bit_i2c_regmap;
6d2961b1 Richard Fitzgerald 2017-11-20 53 }
6d2961b1 Richard Fitzgerald 2017-11-20 54 break;
6d2961b1 Richard Fitzgerald 2017-11-20 55 case CS47L90:
6d2961b1 Richard Fitzgerald 2017-11-20 56 case CS47L91:
6d2961b1 Richard Fitzgerald 2017-11-20 57 if (IS_ENABLED(CONFIG_MFD_CS47L90)) {
6d2961b1 Richard Fitzgerald 2017-11-20 58 regmap_16bit_config = &cs47l90_16bit_i2c_regmap;
6d2961b1 Richard Fitzgerald 2017-11-20 59 regmap_32bit_config = &cs47l90_32bit_i2c_regmap;
6d2961b1 Richard Fitzgerald 2017-11-20 60 }
6d2961b1 Richard Fitzgerald 2017-11-20 61 break;
6d2961b1 Richard Fitzgerald 2017-11-20 62 default:
6d2961b1 Richard Fitzgerald 2017-11-20 63 dev_err(&i2c->dev,
6d2961b1 Richard Fitzgerald 2017-11-20 64 "Unknown Madera I2C device type %ld\n", type);
6d2961b1 Richard Fitzgerald 2017-11-20 65 return -EINVAL;
6d2961b1 Richard Fitzgerald 2017-11-20 66 }
6d2961b1 Richard Fitzgerald 2017-11-20 67
6d2961b1 Richard Fitzgerald 2017-11-20 68 name = madera_name_from_type(type);
6d2961b1 Richard Fitzgerald 2017-11-20 69
6d2961b1 Richard Fitzgerald 2017-11-20 70 if (!regmap_16bit_config) {
6d2961b1 Richard Fitzgerald 2017-11-20 71 dev_err(&i2c->dev,
6d2961b1 Richard Fitzgerald 2017-11-20 72 "Kernel does not include support for %s\n", name);
6d2961b1 Richard Fitzgerald 2017-11-20 73 return -EINVAL;
6d2961b1 Richard Fitzgerald 2017-11-20 74 }
6d2961b1 Richard Fitzgerald 2017-11-20 75
6d2961b1 Richard Fitzgerald 2017-11-20 76 madera = devm_kzalloc(&i2c->dev, sizeof(*madera), GFP_KERNEL);
6d2961b1 Richard Fitzgerald 2017-11-20 77 if (!madera)
6d2961b1 Richard Fitzgerald 2017-11-20 78 return -ENOMEM;
6d2961b1 Richard Fitzgerald 2017-11-20 79
6d2961b1 Richard Fitzgerald 2017-11-20 80
6d2961b1 Richard Fitzgerald 2017-11-20 81 madera->regmap = devm_regmap_init_i2c(i2c, regmap_16bit_config);
6d2961b1 Richard Fitzgerald 2017-11-20 82 if (IS_ERR(madera->regmap)) {
6d2961b1 Richard Fitzgerald 2017-11-20 83 ret = PTR_ERR(madera->regmap);
6d2961b1 Richard Fitzgerald 2017-11-20 84 dev_err(&i2c->dev,
6d2961b1 Richard Fitzgerald 2017-11-20 85 "Failed to allocate 16-bit register map: %d\n", ret);
6d2961b1 Richard Fitzgerald 2017-11-20 86 return ret;
6d2961b1 Richard Fitzgerald 2017-11-20 87 }
6d2961b1 Richard Fitzgerald 2017-11-20 88
6d2961b1 Richard Fitzgerald 2017-11-20 89 madera->regmap_32bit = devm_regmap_init_i2c(i2c, regmap_32bit_config);
6d2961b1 Richard Fitzgerald 2017-11-20 90 if (IS_ERR(madera->regmap_32bit)) {
6d2961b1 Richard Fitzgerald 2017-11-20 91 ret = PTR_ERR(madera->regmap_32bit);
6d2961b1 Richard Fitzgerald 2017-11-20 92 dev_err(&i2c->dev,
6d2961b1 Richard Fitzgerald 2017-11-20 93 "Failed to allocate 32-bit register map: %d\n", ret);
6d2961b1 Richard Fitzgerald 2017-11-20 94 return ret;
6d2961b1 Richard Fitzgerald 2017-11-20 95 }
6d2961b1 Richard Fitzgerald 2017-11-20 96
6d2961b1 Richard Fitzgerald 2017-11-20 97 madera->type = type;
6d2961b1 Richard Fitzgerald 2017-11-20 98 madera->type_name = name;
6d2961b1 Richard Fitzgerald 2017-11-20 99 madera->dev = &i2c->dev;
6d2961b1 Richard Fitzgerald 2017-11-20 100 madera->irq = i2c->irq;
6d2961b1 Richard Fitzgerald 2017-11-20 101
6d2961b1 Richard Fitzgerald 2017-11-20 102 return madera_dev_init(madera);
6d2961b1 Richard Fitzgerald 2017-11-20 103 }
6d2961b1 Richard Fitzgerald 2017-11-20 104
:::::: The code at line 34 was first introduced by commit
:::::: 6d2961b15454236732cb14352de43abcda1c807f mfd: madera: Add common support for Cirrus Logic Madera codecs
:::::: TO: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 47082 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/3] DT: leds: Add Qualcomm Light Pulse Generator binding
From: Jacek Anaszewski @ 2017-11-22 20:42 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Richard Purdie, Pavel Machek, Rob Herring, Mark Rutland,
linux-kernel, linux-leds, linux-arm-msm, devicetree, Fenglin Wu
In-Reply-To: <20171120214550.GA28761@minitux>
On 11/20/2017 10:45 PM, Bjorn Andersson wrote:
> On Mon 20 Nov 12:35 PST 2017, Jacek Anaszewski wrote:
>
>> On 11/20/2017 08:58 PM, Bjorn Andersson wrote:
>>> On Sun 19 Nov 13:35 PST 2017, Jacek Anaszewski wrote:
>>>
>>>> Hi Bjorn,
>>>>
>>>> Thanks for the update.
>>>>
>>>> On 11/15/2017 08:13 AM, Bjorn Andersson wrote:
>>>>> This adds the binding document describing the three hardware blocks
>>>>> related to the Light Pulse Generator found in a wide range of Qualcomm
>>>>> PMICs.
>>>>>
>>>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>>>> ---
>>>>>
>>>>> Changes since v2:
>>>>> - Squashed all things into one node
>>>>> - Removed quirks from the binding, compatible implies number of channels, their
>>>>> configuration etc.
>>>>> - Binding describes LEDs connected as child nodes
>>>>> - Support describing multi-channel LEDs
>>>>> - Change style of the binding document, to match other LED bindings
>>>>>
>>>>> Changes since v1:
>>>>> - Dropped custom pattern properties
>>>>> - Renamed cell-index to qcom,lpg-channel to clarify its purpose
>>>>>
>>>>> .../devicetree/bindings/leds/leds-qcom-lpg.txt | 66 ++++++++++++++++++++++
>>>>> 1 file changed, 66 insertions(+)
>>>>> create mode 100644 Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
>>>>> new file mode 100644
>>>>> index 000000000000..9cee6f9f543c
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
>>>>> @@ -0,0 +1,66 @@
>>>>> +Binding for Qualcomm Light Pulse Generator
>>>>> +
>>>>> +The Qualcomm Light Pulse Generator consists of three different hardware blocks;
>>>>> +a ramp generator with lookup table, the light pulse generator and a three
>>>>> +channel current sink. These blocks are found in a wide range of Qualcomm PMICs.
>>>>> +
>>>>> +Required properties:
>>>>> +- compatible: one of:
>>>>> + "qcom,pm8916-pwm",
>>>>> + "qcom,pm8941-lpg",
>>>>> + "qcom,pm8994-lpg",
>>>>> + "qcom,pmi8994-lpg",
>>>>> + "qcom,pmi8998-lpg",
>>>>> +
>>>>> +Optional properties:
>>>>> +- qcom,power-source: power-source used to drive the output, as defined in the
>>>>> + datasheet. Should be specified if the TRILED block is
>>>>> + present
>>>>
>>>> Range of possible values is missing here.
>>>>
>>>
>>> There seems to be a 4-way mux in all variants, but the wiring is
>>> different in the different products. E.g. in pm8941 1 represents VPH_PWR
>>> while in pmi8994 this is pulled from a dedicated pin named VIN_RGB.
>>>
>>> Would you like me to list the 4 options for each compatible?
>>
>> Could you please explain why user would prefer one power source
>> over the other? Is it that they have different max current limit?
>>
>
> The mux in pm8941 is connected to ground (0V), vph_pwr (3.6V), internal
> 5V and min(5V, charger). In pmi8994 it's ground, vdd_rgb (a dedicated
> pin) and 4.2V. PMI8998 is a slight variation of PMI8994 and I expect
> there to be more variants.
>
> So it's different voltage level and, potentially, current limit.
I'd replace this property with led-max-microamp
(see Documentation/devicetree/bindings/leds/common.txt) and let
the driver to decide which power source to choose, basing on that limit.
> [..]
>> One more question regarding TRILED - in your design it will be
>> exposed as a single LED class device with one brightness file,
>> right? Does it mean that all three LEDs will be applied the
>> same brightness after writing it to the sysfs file?
>>
>
> Correct, each LED described in DT will become one LED and can have more
> than one (any number of) physical channel associated. The current
> implementation applies the same brightness (and pattern) to all channels
> associated with a LED.
The rgb DT node name would be a bit misleading in this case, since
RGB usually implies the possibility of having different intensity
of each color.
> The open question is still how to pass a color from user space, the
> brightness_set and pattern_set would need to be modified to map a list
> of brightnesses to the individual channels or to adapt the brightness by
> some color-modifier(?).
Pavel made and attempt of reworking Heiner Kallweit's HSV approach
few months ago [0]. You can take a look and share your opinion
or even continue this effort.
> I've tested the driver on single-LEDs and on RGB-leds and it supports
> both, the latter with pulse pattern synchronized over the 3 channels.
> So I'm hoping that we can move forward with merging the driver with this
> limitation and then discuss the RGB interface in LED-class separately.
Agreed.
[0] https://lkml.org/lkml/2017/8/30/423
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH 1/2] usb: xhci: add relaxed timing quirk bit
From: Adam Wallis @ 2017-11-22 19:56 UTC (permalink / raw)
To: Mathias Nyman, Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Greg Kroah-Hartman, Mathias Nyman, Linux USB List,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Rutland,
Timur Tabi, Chunfeng Yun
In-Reply-To: <ee0ca959-1812-a4e4-346f-d57a1fdade13-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 11/22/2017 10:24 AM, Mathias Nyman wrote:
> On 22.11.2017 02:07, Adam Wallis wrote:
>> On 11/21/2017 3:06 PM, Rob Herring wrote:
>>
>> [..]
>>
>>>> I like where you are going with this. Are you saying that I could read for a
>>>> device property read from firmware (for DTB or ACPI) like DWC3 does for
>>>> "snps,hird-threshold"?
>>>
>>> Is that for the same thing? If so, drop the vendor prefix and use
>>> that. Otherwise, a separate property should really be something that
>>> is per board rather than per SoC.
>>
>> I don't think that's exactly the same property, but it's the same idea I would
>> prefer to go with. That way, an integer can be passed in via the firmware tables.
>>
>>>
>>>> If you mean this, where do you recommend I store the
>>>> desired IRQ_CONTROL value - in struct xhci_hcd ?
>>>
>>> No idea.
>>>
>>>> Or by "compatible" strings, did you mean storing hard-coded values in the
>>>> of_device_id usb_xhci_of_match[] array? This would still be hard-coding
>>>> (which I
>>>> would like to avoid) and also would not work for the ACPI case.
>>>
>>> ACPI has match tables too?
>>>
>>
>> Yes, you can use DSD in a way that is similar to OF properties
>>
>>> It would only be hardcoded per compatible which should be per SoC. Do
>>> you need per board/device tuning? If so, use a property.
>>>
>>
>> The reason why I think it should dynamic via firmware tables is that
>>
>> * It's much less invasive for vendors to update their DT tables if they need to
>> adjust on a per device/controller/family/etc basis then to adjust a properties
>> table in xhci-plat
>> * This would lead to less polluting in xhci-plat code
>>
>>> Rob
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>> I will provide an updated proposed patch sometime this week. I also hope to get
>> some feedback from Mathias to see what he prefers.
>
> We know have at least two hosts/platforms that need custom interrupt moderation
> values
>
> How about adding a u32 device property for xhci with the interrupt moderation
> interval in
> nanoseconds? And also add a u32 imod_interval variable to struct xhci_hcd?
>
> imod_interval can be set to the current default 40000ns (160*250ns) and
> overwritten if
> device_property_read_u32() returns something else.
>
> XHCI_MTK_HOST could then use whatever preferred device propery interval value,
> and we can get rid of using XHCI_MTK_HOST quirk flag when setting up the IMODI
>
> -Mathias
>
This sounds excellent Mathias. Let me put together a patch along these lines.
Thanks for the feedback!
Adam
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/7] R-Car D3 (r8a77995) CAN support
From: Simon Horman @ 2017-11-22 18:10 UTC (permalink / raw)
To: Ulrich Hecht
Cc: linux-renesas-soc, linux-can, devicetree, wsa, geert, magnus.damm,
chris.paterson2, ramesh.shanmugasundaram
In-Reply-To: <1510915289-15059-1-git-send-email-ulrich.hecht+renesas@gmail.com>
On Fri, Nov 17, 2017 at 11:41:22AM +0100, Ulrich Hecht wrote:
> Hi!
>
> Here's CAN and CAN FD support for the R-Car D3. This is a by-the-datasheet
> implementation, with the datasheet missing some bits, namely the pin map.
> I filled in the gaps with frog DNA^W^W^Wby deducing the information from
> pin numbers already in the PFC driver, so careful scrutiny is advised.
>
> CU
> Uli
>
>
> Ulrich Hecht (7):
> pinctrl: sh-pfc: r8a77995: Add CAN support
> pinctrl: sh-pfc: r8a77995: Add CAN FD support
> arm64: dts: r8a77995: Add CAN external clock support
> arm64: dts: r8a77995: Add CAN support
> arm64: dts: r8a77995: Add CAN FD support
> can: rcar_can: document r8a77995 (R-Car D3) compatibility strings
> can: rcar_canfd: document r8a77995 (R-Car D3) compatibility strings
Hi Ulrich,
is it safe, from a regression point of view, to apply the dts patches
to a tree that does not have the other patches present?
^ permalink raw reply
* Re: [patches] Re: [PATCH] dt-bindings: Add an enable method to RISC-V
From: Palmer Dabbelt @ 2017-11-22 17:11 UTC (permalink / raw)
To: mark.rutland-5wv7dgnIgG8
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
patches-q3qR2WxjNRFS9aJRtSZj7A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171121110451.qm5cy5s4audfvwu5-agMKViyK24J5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
On Tue, 21 Nov 2017 03:04:52 PST (-0800), mark.rutland-5wv7dgnIgG8@public.gmane.org wrote:
> Hi Palmer,
>
> On Mon, Nov 20, 2017 at 11:50:22AM -0800, Palmer Dabbelt wrote:
>> RISC-V doesn't currently specify a mechanism for enabling or disabling
>> CPUs. Instead, we assume that all CPUs are enabled on boot, and if
>> someone wants to save power we instead put a CPU to sleep via a WFI
>> loop.
>>
>> This patch adds "enable-method" to the RISC-V CPU binding, which
>> currently only has the value "none". This allows us to change the
>> enable method in the future.
>
> I think you might want to be a bit more explicit about what this means,
> and this could do with a better name, as "none" sounds like the CPU is
> unusable, rather than it having been placed within the kernel already by
> the FW/bootloader (which IIUC is what happens currently).
It was proposed to make "enable-method" optional, and have the lack of an
enable method signify the current scheme. The current scheme is that the
bootloader starts every hart at the kernel's entry point.
Calling this "always-enabled" was also suggested, which seems fine to me.
> As previosuly commented, I also really think you'll want to define a
> simple boot protocol (like PPC spin-table) whereby the kernel can bring
> each CPU into the kernel independently. That will save you a lot of pain
> in future with things like kexec, suspend/resume, etc.
>
> For arm64 we had a spin-table clone (implemented in our boot-wrapper
> firmware) that allowed us to bring CPUs into the kernel explicitly.
> However, we made the mistake of allowing CPUs to share a mailbox, and we
> couldn't tell how many CPUs were stuck in the kernel at any point in
> time (rendering kexec, suspend, etc impossible).
This is actually why I'm kind of pushing back on this: because we don't know
how we're actually going to handle this, I don't want to go build an interface
to the firmware that might be broken. Essentially what we're doing now is just
keeping the spin table entirely within Linux, so we can change this interface
whenever we want. The start of our kernel looks like
_start(char *dtb_pointer, long hartid)
if (atomic_increment_return(hart_lottery) == 0)
start_kernel()
else
while (READ_ONCE(__cpu_up_has_turned_on_hart[hartid]) == 0)
wait_for_interrupt()
smp_callin()
If I understand correctly, this is essentially what the spin tables are doing
in arm64. Our mechanism is a bit different because we can expose a much more
complicated interface here, but since the interface can change (it's a
kernel-internal interface, not a firmware->kernel interface) that's the natural
thing to do.
While I haven't actually gone through and looked at any of this (and I admit I
have only a vague idea of how it works), I think this should work fine for
kexec, CPU hotplug, and suspend. kexec is easy: the fresh kernel's image will
boot exactly like a regular one, as all the harts can just jump to the entry
point at the same time. Since "hart_lottery" is initialized to 0 by the ELF
there isn't anything special required to make it work.
Actually turning off harts will require us to add an interface that does so,
which will probably happen via an SBI call. We haven't actually designed the
interface yet, but I'm assuming it'll just reset the hart. In general, we like
to make any interface that sleeps also work as a NOP, so for now let's just
pretend that this interface does nothing and go straight to_start. This should
map pretty well, our __cpu_down could just be the mirror of __cpu_up
__cpu_down(int hartid)
__cpu_up_has_turned_on_hart[hartid] = false;
atomic_decrement(hart_lottery);
__sbi_suspend_hart();
jump _start
That should cover hotplug, and then suspend is just a matter of hotplugging out
the last CPU. I assume that lots of our stuff will blow up when we start
removing harts at runtime, but that'll all happen regardless of how we wake
them up. There's also a bit of a race here (bringing up a hart while the last
one is suspending), and that counter overflows, but those seem solvable.
Does that sound sane? If not, I'd be happy to go and design a spin table
firmware interface. We just like to avoid inventing external interfaces until
we really know what we're doing :).
> Thanks,
> Mark.
>
>> CC: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> Signed-off-by: Palmer Dabbelt <palmer-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/riscv/cpus.txt | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.txt b/Documentation/devicetree/bindings/riscv/cpus.txt
>> index adf7b7af5dc3..dd9e1ae197e2 100644
>> --- a/Documentation/devicetree/bindings/riscv/cpus.txt
>> +++ b/Documentation/devicetree/bindings/riscv/cpus.txt
>> @@ -82,6 +82,11 @@ described below.
>> Value type: <string>
>> Definition: Contains the RISC-V ISA string of this hart. These
>> ISA strings are defined by the RISC-V ISA manual.
>> + - cpu-enable-method:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: Must be one of
>> + "none": This CPU's state cannot be changed.
>>
>> Example: SiFive Freedom U540G Development Kit
>> ---------------------------------------------
>> @@ -105,6 +110,7 @@ Linux is allowed to run on.
>> reg = <0>;
>> riscv,isa = "rv64imac";
>> status = "disabled";
>> + enable-method = "none";
>> L10: interrupt-controller {
>> #interrupt-cells = <1>;
>> compatible = "riscv,cpu-intc";
>> @@ -130,6 +136,7 @@ Linux is allowed to run on.
>> reg = <1>;
>> riscv,isa = "rv64imafdc";
>> status = "okay";
>> + enable-method = "none";
>> tlb-split;
>> L13: interrupt-controller {
>> #interrupt-cells = <1>;
>> --
>> 2.13.6
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/6] arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
From: Gregory CLEMENT @ 2017-11-22 16:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Lunn, Rob Herring, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, arm@kernel.org,
Jason Cooper, Sebastian Hesselbarth
In-Reply-To: <CAK8P3a1x7mnpvfgsnwVJdX4OFwJZn0GpTE9ATfoLuQPB5ev=gg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Arnd,
On mar., nov. 21 2017, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Tue, Nov 21, 2017 at 9:09 PM, Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:
>> On Tue, Nov 21, 2017 at 12:29:48PM -0600, Rob Herring wrote:
>>> On Thu, Nov 9, 2017 at 4:26 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>> > "usb-nop-xceiv" is using the phy binding, but is missing #phy-cells
>>> > property. This is probably because the binding was the precursor to the phy
>>> > binding.
>>> >
>>> > Fixes the following warning in Marvell dts files:
>>> >
>>> > Warning (phys_property): Missing property '#phy-cells' in node ...
>>> >
>>> > Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> > Cc: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
>>> > Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
>>> > Cc: Gregory Clement <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>>> > Cc: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> > ---
>>> > Please apply to Marvell tree.
>>>
>>> Ping.
>>>
>>> Arnd, can you apply if you'd like the warnings fixed and Marvell
>>> maintainers don't respond.
>>
>> Hi Rob
>>
>> Patches submitted a week before the merge window opens are generally
>> deferred to the next cycle. I expect that once -rc1 is out, Gregory
>> will pick up this patch.
>
> These are real bugfixes, I want them in 4.15, since we now get a
> loud warning for them. I'd rather not shut up that warning because
> it's not a false-positive.
As pointed by Andrew, I planned to take them once the 4.15-rc1 would be
released. It was not obvious for me that it was real fixes. Actually I
would have expected to have first the dts fixed in a release and then
the warning enabled.
I am fine if you take this patch, especially if it is merged in
4.15-rc1.
So for this patch:
Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Thanks,
Gregory
>
> Arnd
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver
From: Dave Stevenson @ 2017-11-22 16:39 UTC (permalink / raw)
To: Eric Anholt
Cc: Rob Herring, Stefan Wahren, Mauro Carvalho Chehab,
linux-media@vger.kernel.org, Sakari Ailus, Hans Verkuil,
moderated list:BROADCOM BCM2835 ARM ARCHITECTURE,
devicetree@vger.kernel.org
In-Reply-To: <87bmjvcpyv.fsf@anholt.net>
On 21 November 2017 at 20:54, Eric Anholt <eric@anholt.net> wrote:
> Rob Herring <robh@kernel.org> writes:
>
>> On Tue, Nov 21, 2017 at 1:26 PM, Eric Anholt <eric@anholt.net> wrote:
>>> Dave Stevenson <dave.stevenson@raspberrypi.org> writes:
>>>
>>>> Hi Rob
>>>>
>>>> On 27 September 2017 at 22:51, Rob Herring <robh@kernel.org> wrote:
>>>>> On Fri, Sep 22, 2017 at 05:07:22PM +0100, Dave Stevenson wrote:
>>>>>> Hi Stefan
>>>>>>
>>>>>> On 22 September 2017 at 07:45, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>>>>>> > Hi Dave,
>>>>>> >
>>>>>> >> Dave Stevenson <dave.stevenson@raspberrypi.org> hat am 20. September 2017 um 18:07 geschrieben:
>>>>>> >>
>>>>>> >>
>>>>>> >> Document the DT bindings for the CSI2/CCP2 receiver peripheral
>>>>>> >> (known as Unicam) on BCM283x SoCs.
>>>>>> >>
>>>>>> >> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
>>>>>> >> ---
>>>>>> >>
>>>>>> >> Changes since v2
>>>>>> >> - Removed all references to Linux drivers.
>>>>>> >> - Reworded section about disabling the firmware driver.
>>>>>> >> - Renamed clock from "lp_clock" to "lp" in description and example.
>>>>>> >> - Referred to video-interfaces.txt and stated requirements on remote-endpoint
>>>>>> >> and data-lanes.
>>>>>> >> - Corrected typo in example from csi to csi1.
>>>>>> >> - Removed unnecessary #address-cells and #size-cells in example.
>>>>>> >> - Removed setting of status from the example.
>>>>>> >>
>>>>>> >> .../devicetree/bindings/media/bcm2835-unicam.txt | 85 ++++++++++++++++++++++
>>>>>> >> 1 file changed, 85 insertions(+)
>>>>>> >> create mode 100644 Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>>>>>> >>
>>>>>> >> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>>>>>> >> new file mode 100644
>>>>>> >> index 0000000..7714fb3
>>>>>> >> --- /dev/null
>>>>>> >> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>>>>>> >> @@ -0,0 +1,85 @@
>>>>>> >> +Broadcom BCM283x Camera Interface (Unicam)
>>>>>> >> +------------------------------------------
>>>>>> >> +
>>>>>> >> +The Unicam block on BCM283x SoCs is the receiver for either
>>>>>> >> +CSI-2 or CCP2 data from image sensors or similar devices.
>>>>>> >> +
>>>>>> >> +The main platform using this SoC is the Raspberry Pi family of boards.
>>>>>> >> +On the Pi the VideoCore firmware can also control this hardware block,
>>>>>> >> +and driving it from two different processors will cause issues.
>>>>>> >> +To avoid this, the firmware checks the device tree configuration
>>>>>> >> +during boot. If it finds device tree nodes called csi0 or csi1 then
>>>>>> >> +it will stop the firmware accessing the block, and it can then
>>>>>> >> +safely be used via the device tree binding.
>>>>>> >> +
>>>>>> >> +Required properties:
>>>>>> >> +===================
>>>>>> >> +- compatible : must be "brcm,bcm2835-unicam".
>>>>>> >> +- reg : physical base address and length of the register sets for the
>>>>>> >> + device.
>>>>>> >> +- interrupts : should contain the IRQ line for this Unicam instance.
>>>>>> >> +- clocks : list of clock specifiers, corresponding to entries in
>>>>>> >> + clock-names property.
>>>>>> >> +- clock-names : must contain an "lp" entry, matching entries in the
>>>>>> >> + clocks property.
>>>>>> >> +
>>>>>> >> +Unicam supports a single port node. It should contain one 'port' child node
>>>>>> >> +with child 'endpoint' node. Please refer to the bindings defined in
>>>>>> >> +Documentation/devicetree/bindings/media/video-interfaces.txt.
>>>>>> >> +
>>>>>> >> +Within the endpoint node the "remote-endpoint" and "data-lanes" properties
>>>>>> >> +are mandatory.
>>>>>> >> +Data lane reordering is not supported so the data lanes must be in order,
>>>>>> >> +starting at 1. The number of data lanes should represent the number of
>>>>>> >> +usable lanes for the hardware block. That may be limited by either the SoC or
>>>>>> >> +how the platform presents the interface, and the lower value must be used.
>>>>>> >> +
>>>>>> >> +Lane reordering is not supported on the clock lane either, so the optional
>>>>>> >> +property "clock-lane" will implicitly be <0>.
>>>>>> >> +Similarly lane inversion is not supported, therefore "lane-polarities" will
>>>>>> >> +implicitly be <0 0 0 0 0>.
>>>>>> >> +Neither of these values will be checked.
>>>>>> >> +
>>>>>> >> +Example:
>>>>>> >> + csi1: csi1@7e801000 {
>>>>>> >> + compatible = "brcm,bcm2835-unicam";
>>>>>> >> + reg = <0x7e801000 0x800>,
>>>>>> >> + <0x7e802004 0x4>;
>>>>>> >
>>>>>> > sorry, i didn't noticed this before. I'm afraid this is using a small range of the CMI. Are there possible other users of this range? Does it make sense to handle this by a separate clock driver?
>>>>>>
>>>>>> CMI (Clock Manager Image) consists of a total of 4 registers.
>>>>>> 0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and
>>>>>> inversion of the clock and data lanes (2 data lanes available on
>>>>>> CAM0).
>>>>>> 0x7e802004 is CMI_CAM1, with only bits 0-9 used for gating and
>>>>>> inversion of the clock and data lanes (4 data lanes available on
>>>>>> CAM1).
>>>>>> 0x7e802008 is CMI_CAMTEST which I have no documentation or drivers for.
>>>>>> 0x7e802010 is CMI_USBCTL. Only bit 6 is documented and is a reset. The
>>>>>> default value is the required value. Nothing touches it that I can
>>>>>> find.
>>>>>>
>>>>>> The range listed only covers the one register associated with that
>>>>>> Unicam instance, so no other users. The other two aren't touched.
>>>>>> Do 16 active register bits solely for camera clock gating really
>>>>>> warrant a full clock driver?
>>>>>
>>>>> You should describe all the registers in DT, not just what the driver
>>>>> (currently) uses.
>>>>
>>>> I'm not clear what you're asking for here.
>>>>
>>>> This binding is for the Unicam block, not for CMI (Clock Manager
>>>> Imaging). In order for a Unicam instance to work, it needs to enable
>>>> the relevant clock gating via 1 CMI register, and it will only ever be
>>>> one register.
>>>
>>> Rob, the CMI just a small bit of glue required by the crossing of a
>>> power domain in a unicam instance, and the two unicam instances in this
>>> HW have their CMI regs next to each other. It's not really a separate
>>> block, and I think describing the unicam's CMI reg in the unicam binding
>>> is appropriate.
>>>
>>> What would you need from Dave to ack this binding?
>>
>> Sorry, had started to reply on this and got distracted.
>>
>> I guess since there seems to be only 1 other bit that could possibly
>> be used (CMI_USBCTL) it is fine like this. However, my concern would
>> be if the CMI registers are integrated in a different way in some
>> future chip that has the same unicam instances. Or just if the
>> register bits are rearranged. Those are not an uncommon occurrence.
>> You would have to provide access to those registers in some other way.
>> It can be dealt with, but then you have to support both cases in the
>> driver. If you all are fine with that, then:
>
> The bigisland chips match bcm2835. For capri the lane enables are
> shifted down by two and the clock is up at bit 20. That would be
> trivial to handle based on the compatible string, except that we can't
> talk to capri's hardware from ARM anyway :(
Thank you both.
The Java and Hawaii chips also have the same Unicam block, but appear
to be missing CMI totally based on the BCM Android kernel source.
They aren't chips I have any interest in, but as Eric says it can be
supported easily via the compatible string, or by making the resource
optional. The latter is easy to do, so I'll add that to v4 of the
patch set.
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH 1/2] usb: xhci: add relaxed timing quirk bit
From: Mathias Nyman @ 2017-11-22 15:24 UTC (permalink / raw)
To: Adam Wallis, Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Greg Kroah-Hartman, Mathias Nyman, Linux USB List,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Rutland,
Timur Tabi, Chunfeng Yun
In-Reply-To: <32f8dc7e-9fde-5e45-1570-a9ec372579fa-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 22.11.2017 02:07, Adam Wallis wrote:
> On 11/21/2017 3:06 PM, Rob Herring wrote:
>
> [..]
>
>>> I like where you are going with this. Are you saying that I could read for a
>>> device property read from firmware (for DTB or ACPI) like DWC3 does for
>>> "snps,hird-threshold"?
>>
>> Is that for the same thing? If so, drop the vendor prefix and use
>> that. Otherwise, a separate property should really be something that
>> is per board rather than per SoC.
>
> I don't think that's exactly the same property, but it's the same idea I would
> prefer to go with. That way, an integer can be passed in via the firmware tables.
>
>>
>>> If you mean this, where do you recommend I store the
>>> desired IRQ_CONTROL value - in struct xhci_hcd ?
>>
>> No idea.
>>
>>> Or by "compatible" strings, did you mean storing hard-coded values in the
>>> of_device_id usb_xhci_of_match[] array? This would still be hard-coding (which I
>>> would like to avoid) and also would not work for the ACPI case.
>>
>> ACPI has match tables too?
>>
>
> Yes, you can use DSD in a way that is similar to OF properties
>
>> It would only be hardcoded per compatible which should be per SoC. Do
>> you need per board/device tuning? If so, use a property.
>>
>
> The reason why I think it should dynamic via firmware tables is that
>
> * It's much less invasive for vendors to update their DT tables if they need to
> adjust on a per device/controller/family/etc basis then to adjust a properties
> table in xhci-plat
> * This would lead to less polluting in xhci-plat code
>
>> Rob
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> I will provide an updated proposed patch sometime this week. I also hope to get
> some feedback from Mathias to see what he prefers.
We know have at least two hosts/platforms that need custom interrupt moderation values
How about adding a u32 device property for xhci with the interrupt moderation interval in
nanoseconds? And also add a u32 imod_interval variable to struct xhci_hcd?
imod_interval can be set to the current default 40000ns (160*250ns) and overwritten if
device_property_read_u32() returns something else.
XHCI_MTK_HOST could then use whatever preferred device propery interval value,
and we can get rid of using XHCI_MTK_HOST quirk flag when setting up the IMODI
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox