* [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 5/6] ARM: dts: keystone-k2g-ice: 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
In-Reply-To: <20171123075154.3938-1-vigneshr@ti.com>
Add DT nodes for QSPI, on board LEDS, MMC, I2C, PCA IO expander,
gpio-decoder and regulators on K2G ICE board.
Thanks to Franklin S Cooper Jr <fcooper@ti.com> for initial work on few
peripherals.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
arch/arm/boot/dts/keystone-k2g-ice.dts | 336 +++++++++++++++++++++++++++++++++
1 file changed, 336 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g-ice.dts b/arch/arm/boot/dts/keystone-k2g-ice.dts
index 78692745e0af..1736eb53ad83 100644
--- a/arch/arm/boot/dts/keystone-k2g-ice.dts
+++ b/arch/arm/boot/dts/keystone-k2g-ice.dts
@@ -30,6 +30,191 @@
status = "okay";
};
};
+
+ vmain: fixedregulator-vmain {
+ compatible = "regulator-fixed";
+ regulator-name = "vmain_fixed";
+ regulator-min-microvolt = <24000000>;
+ regulator-max-microvolt = <24000000>;
+ regulator-always-on;
+ };
+
+ v5_0: fixedregulator-v5_0 {
+ /* TPS54531 */
+ compatible = "regulator-fixed";
+ regulator-name = "v5_0_fixed";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vmain>;
+ regulator-always-on;
+ };
+
+ vdd_3v3: fixedregulator-vdd_3v3 {
+ /* TLV62084 */
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_3v3_fixed";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&v5_0>;
+ regulator-always-on;
+ };
+
+ vdd_1v8: fixedregulator-vdd_1v8 {
+ /* TLV62084 */
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_1v8_fixed";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&v5_0>;
+ regulator-always-on;
+ };
+
+ vdds_ddr: fixedregulator-vdds_ddr {
+ /* TLV62080 */
+ compatible = "regulator-fixed";
+ regulator-name = "vdds_ddr_fixed";
+ regulator-min-microvolt = <1350000>;
+ regulator-max-microvolt = <1350000>;
+ vin-supply = <&v5_0>;
+ regulator-always-on;
+ };
+
+ vref_ddr: fixedregulator-vref_ddr {
+ /* LP2996A */
+ compatible = "regulator-fixed";
+ regulator-name = "vref_ddr_fixed";
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <675000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-always-on;
+ };
+
+ vtt_ddr: fixedregulator-vtt_ddr {
+ /* LP2996A */
+ compatible = "regulator-fixed";
+ regulator-name = "vtt_ddr_fixed";
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <675000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-always-on;
+ };
+
+ vdd_0v9: fixedregulator-vdd_0v9 {
+ /* TPS62180 */
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_0v9_fixed";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ vin-supply = <&v5_0>;
+ regulator-always-on;
+ };
+
+ vddb: fixedregulator-vddb {
+ /* TPS22945 */
+ compatible = "regulator-fixed";
+ regulator-name = "vddb_fixed";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&gpio1 53 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ gpio-decoder {
+ compatible = "gpio-decoder";
+ gpios = <&pca9536 3 GPIO_ACTIVE_HIGH>,
+ <&pca9536 2 GPIO_ACTIVE_HIGH>,
+ <&pca9536 1 GPIO_ACTIVE_HIGH>,
+ <&pca9536 0 GPIO_ACTIVE_HIGH>;
+ linux,axis = <0>; /* ABS_X */
+ decoder-max-value = <9>;
+ };
+
+ leds1 {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&user_leds>;
+
+ led0 {
+ label = "status0:red:cpu0";
+ gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ linux,default-trigger = "cpu0";
+ };
+
+ led1 {
+ label = "status0:green:usr";
+ gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led2 {
+ label = "status0:yellow:usr";
+ gpios = <&gpio0 13 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led3 {
+ label = "status1:red:mmc0";
+ gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ linux,default-trigger = "mmc0";
+ };
+
+ led4 {
+ label = "status1:green:usr";
+ gpios = <&gpio0 15 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led5 {
+ label = "status1:yellow:usr";
+ gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led6 {
+ label = "status2:red:usr";
+ gpios = <&gpio0 44 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led7 {
+ label = "status2:green:usr";
+ gpios = <&gpio0 43 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led8 {
+ label = "status2:yellow:usr";
+ gpios = <&gpio0 42 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led9 {
+ label = "status3:red:usr";
+ gpios = <&gpio0 41 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led10 {
+ label = "status3:green:usr";
+ gpios = <&gpio0 101 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led11 {
+ label = "status3:yellow:usr";
+ gpios = <&gpio0 102 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led12 {
+ label = "status4:green:heartbeat";
+ gpios = <&gpio0 19 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
};
&k2g_pinctrl {
@@ -39,6 +224,64 @@
K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN | MUX_MODE0) /* uart0_txd.uart0_txd */
>;
};
+
+ 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 */
+ >;
+ };
+
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x10FC) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0) /* mmc1_dat3.mmc1_dat3 */
+ K2G_CORE_IOPAD(0x1100) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0) /* mmc1_dat2.mmc1_dat2 */
+ K2G_CORE_IOPAD(0x1104) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0) /* mmc1_dat1.mmc1_dat1 */
+ K2G_CORE_IOPAD(0x1108) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0) /* mmc1_dat0.mmc1_dat0 */
+ K2G_CORE_IOPAD(0x110C) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0) /* mmc1_clk.mmc1_clk */
+ K2G_CORE_IOPAD(0x1110) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0) /* mmc1_cmd.mmc1_cmd */
+ K2G_CORE_IOPAD(0x1114) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3) /* mmc1_sdcd.gpio0_69 */
+ K2G_CORE_IOPAD(0x1118) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0) /* mmc1_sdwp.mmc1_sdwp */
+ K2G_CORE_IOPAD(0x111C) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0) /* mmc1_pow.mmc1_pow */
+ >;
+ };
+
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x137c) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0) /* i2c0_scl.i2c0_scl */
+ K2G_CORE_IOPAD(0x1380) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0) /* i2c0_sda.i2c0_sda */
+ >;
+ };
+
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x1384) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0) /* i2c1_scl.i2c1_scl */
+ K2G_CORE_IOPAD(0x1388) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0) /* i2c1_sda.i2c1_sda */
+ >;
+ };
+
+ user_leds: pinmux_user_leds {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x102c) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3) /* gpmc_ad11.gpio0_11 */
+ K2G_CORE_IOPAD(0x1030) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3) /* gpmc_ad12.gpio0_12 */
+ K2G_CORE_IOPAD(0x1034) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3) /* gpmc_ad13.gpio0_13 */
+ K2G_CORE_IOPAD(0x1038) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3) /* gpmc_ad14.gpio0_14 */
+ K2G_CORE_IOPAD(0x103c) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3) /* gpmc_ad15.gpio0_15 */
+ K2G_CORE_IOPAD(0x1040) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3) /* gpmc_clk.gpio0_16 */
+ K2G_CORE_IOPAD(0x104c) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3) /* gpmc_wen.gpio0_19 */
+ K2G_CORE_IOPAD(0x10b0) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3) /* dss_data9.gpio0_44 */
+ K2G_CORE_IOPAD(0x10ac) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3) /* dss_data10.gpio0_43 */
+ K2G_CORE_IOPAD(0x10a8) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3) /* dss_data11.gpio0_42 */
+ K2G_CORE_IOPAD(0x10a4) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3) /* dss_data12.gpio0_41 */
+ K2G_CORE_IOPAD(0x11b8) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3) /* spi2_scsn0.gpio0_101 */
+ K2G_CORE_IOPAD(0x11bc) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3) /* spi2_scsn1.gpio0_102 */
+ >;
+ };
};
&uart0 {
@@ -51,3 +294,96 @@
memory-region = <&dsp_common_memory>;
status = "okay";
};
+
+&qspi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&qspi_pins>;
+ cdns,rclk-en;
+ status = "okay";
+
+ flash0: m25p80@0 {
+ compatible = "s25fl256s1", "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";
+ 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.u-boot-spl-os";
+ reg = <0x009c0000 0x0040000>;
+ };
+ partition@6 {
+ label = "QSPI.file-system";
+ reg = <0x00a00000 0x1600000>;
+ };
+ };
+};
+
+&gpio0 {
+ status = "okay";
+};
+
+&gpio1 {
+ status = "okay";
+};
+
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <&vdd_3v3>;
+ cd-gpios = <&gpio0 69 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "okay";
+
+ eeprom@50 {
+ compatible = "atmel,24c256";
+ reg = <0x50>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+ status = "okay";
+ clock-frequency = <400000>;
+
+ pca9536: gpio@41 {
+ compatible = "ti,pca9536";
+ reg = <0x41>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ vcc-supply = <&vdd_3v3>;
+ };
+};
--
2.15.0
^ permalink raw reply related
* [PATCH 6/6] ARM: configs: keystone_defconfig: Enable few peripheral drivers
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>
Enable drivers for QSPI, LEDS, gpio-decoder that are present on 66AK2G EVM
and 66AK2G ICE boards.
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
arch/arm/configs/keystone_defconfig | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig
index f710c192b33a..2536c231eea1 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -228,3 +228,10 @@ CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_ANSI_CPRNG=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
+CONFIG_SPI_CADENCE_QUADSPI=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_EVDEV=m
+CONFIG_INPUT_GPIO_DECODER=m
+CONFIG_GPIO_PCA953X=m
+CONFIG_LEDS_TRIGGER_ACTIVITY=y
+CONFIG_LEDS_TRIGGER_CPU=y
--
2.15.0
^ permalink raw reply related
* Re: [PATCH 3/5] media: i2c: Add TDA1997x HDMI receiver driver
From: Hans Verkuil @ 2017-11-23 8:08 UTC (permalink / raw)
To: Tim Harvey
Cc: devicetree@vger.kernel.org, alsa-devel,
linux-kernel@vger.kernel.org, Hans Verkuil, Mauro Carvalho Chehab,
Philipp Zabel, Steve Longerbeam, Shawn Guo, linux-media
In-Reply-To: <CAJ+vNU0q4Ab-1sFsyQv3JRMd54ntMU3=Er6yCNiY=tLCN1N5VQ@mail.gmail.com>
On 11/23/2017 05:27 AM, Tim Harvey wrote:
> On Mon, Nov 20, 2017 at 7:39 AM, Hans Verkuil <hverkuil@xs4all.nl> 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.
Output for RGB is always full range. The reason is simply that the V4L2 API
has no way of selecting the quantization range it wants to receive. I made
a patch for that a few years back, but there really is no demand for it (yet).
Userspace expects full range RGB and limited range YUV.
>
> 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?
You can choose yourself whether you convert to YUV 601 or 709. I would
recommend to use 601 for SDTV resolutions (i.e. width/height <= 720x576)
and 709 for HDTV.
I made a little program that calculates the values for RGB lim/full to
YUV 601/709:
-------------------------------------
#include <stdlib.h>
#include <stdio.h>
#define COEFF(v, r) ((v) * (r) * 16.0)
static const double bt601[3][3] = {
{ COEFF(0.299, 219), COEFF(0.587, 219), COEFF(0.114, 219) },
{ COEFF(-0.1687, 224), COEFF(-0.3313, 224), COEFF(0.5, 224) },
{ COEFF(0.5, 224), COEFF(-0.4187, 224), COEFF(-0.0813, 224) },
};
static const double rec709[3][3] = {
{ COEFF(0.2126, 219), COEFF(0.7152, 219), COEFF(0.0722, 219) },
{ COEFF(-0.1146, 224), COEFF(-0.3854, 224), COEFF(0.5, 224) },
{ COEFF(0.5, 224), COEFF(-0.4542, 224), COEFF(-0.0458, 224) },
};
int main(int argc, char **argv)
{
int i, j;
int mapi[] = { 0, 2, 1 };
int mapj[] = { 1, 0, 2 };
printf("rgb full -> 601\n");
printf(" 0, 0, 0,\n");
for (i = 0; i < 3; i++) {
for (j = 0; j < 3; j++) {
printf("%5d, ", (int)(0.5 + bt601[mapi[i]][mapj[j]]));
}
printf("\n");
}
printf(" 256, 2048, 2048,\n\n");
printf("rgb lim -> 601\n");
printf(" -256, -256, -256,\n");
for (i = 0; i < 3; i++) {
for (j = 0; j < 3; j++) {
printf("%5d, ", (int)(0.5 + 255.0 / 219.0 * bt601[mapi[i]][mapj[j]]));
}
printf("\n");
}
printf(" 256, 2048, 2048,\n\n");
printf("rgb full -> 709\n");
printf(" 0, 0, 0,\n");
for (i = 0; i < 3; i++) {
for (j = 0; j < 3; j++) {
printf("%5d, ", (int)(0.5 + rec709[mapi[i]][mapj[j]]));
}
printf("\n");
}
printf(" 256, 2048, 2048,\n\n");
printf("rgb lim -> 709\n");
printf(" -256, -256, -256,\n");
for (i = 0; i < 3; i++) {
for (j = 0; j < 3; j++) {
printf("%5d, ", (int)(0.5 + 255.0 / 219.0 * rec709[mapi[i]][mapj[j]]));
}
printf("\n");
}
printf(" 256, 2048, 2048,\n\n");
return 0;
}
-------------------------------------
This should give you the needed matrices. It's up to you whether to keep the
existing matrices for 601 or replace them with these. Probably best to keep
them.
>
> 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;
Huh? You're mixing V4L2_DV_RGB_* defines with HDMI_QUANTIZATION_RANGE_*
defines.
You probably mean to check the control value here.
> 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
>
Regards,
Hans
^ permalink raw reply
* Re: [PATCH 2/5] media: dt-bindings: Add bindings for TDA1997X
From: Sakari Ailus @ 2017-11-23 8:25 UTC (permalink / raw)
To: Tim Harvey
Cc: devicetree@vger.kernel.org, alsa-devel, Rob Herring,
linux-kernel@vger.kernel.org, Hans Verkuil, Mauro Carvalho Chehab,
Philipp Zabel, Steve Longerbeam, Shawn Guo, linux-media
In-Reply-To: <CAJ+vNU1FEp5aU6aXXOuGr3ifcngfP0Pj0rnBBxDh_mVtQyvLAQ@mail.gmail.com>
On Wed, Nov 22, 2017 at 08:37:04PM -0800, Tim Harvey wrote:
> 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.
I think it'd be clearer if you just add "The port node shall contain one
endpoint child node".
>
> >> +
> >> +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.
The parallel bus. If you mean that, then you could just say that. "Source
endpoint" is a bit vague, or requires knowing V4L2.
--
Sakari Ailus
e-mail: sakari.ailus@iki.fi
^ permalink raw reply
* Re: [v4,2/3] drivers: hwmon: Add W83773G driver
From: Guenter Roeck @ 2017-11-23 9:01 UTC (permalink / raw)
To: Joel Stanley
Cc: Lei YU, Mark Rutland, Jean Delvare, Jonathan Corbet, Jiri Kosina,
devicetree, Linux Kernel Mailing List,
linux-hwmon-u79uwXL29TY76Z2rM5mHXA, Andrew Jeffery
In-Reply-To: <CACPK8Xc5zmHCmDikYFPA+GdVCydHwgiLMY0X1RTyOmzS+m9W7A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/22/2017 10:32 PM, Joel Stanley wrote:
> On Sun, Nov 19, 2017 at 2:45 AM, Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>
>> Applied to hwmon-next.
>
> Where does hwmon-next live? I was looking on kernel.org and I can't
> seem to find it.
>
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
branch hwmon-next, but I('ll only push it after the commit window closes.
Guenter
--
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] arm64: dts: renesas: r8a7795: Move nodes which have no reg property out of bus
From: Geert Uytterhoeven @ 2017-11-23 9:27 UTC (permalink / raw)
To: Simon Horman
Cc: Linux-Renesas, linux-arm-kernel@lists.infradead.org, Magnus Damm,
Arnd Bergmann, Rob Herring, Geert Uytterhoeven,
devicetree@vger.kernel.org
In-Reply-To: <20171120110125.12267-1-horms+renesas@verge.net.au>
Hi Simon,
On Mon, Nov 20, 2017 at 12:01 PM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
> The nodes that have been moved do not have any register properties and thus
> shouldn't be placed on the bus.
>
> This problem is flagged by the compiler as follows:
> $ make
> ...
> DTC arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb
> arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
[...]
Thanks for your patch!
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -126,6 +126,86 @@
The node above is called "cpus".
> };
> };
>
> + pmu_a57 {
> + };
> +
> + pmu_a53 {
> + };
> +
> + timer {
> + };
> +
> + thermal-zones {
> + };
> +
> extal_clk: extal {
> compatible = "fixed-clock";
> #clock-cells = <0>;
Any sorting rules (alphabetically?) for nodes at the root level?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: media: rcar_vin: Reverse SoC part number list
From: Geert Uytterhoeven @ 2017-11-23 9:28 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Mauro Carvalho Chehab, Mark Rutland, Rob Herring,
Niklas Söderlund, Linux Media Mailing List, Linux-Renesas,
devicetree@vger.kernel.org, Simon Horman, Chris Paterson,
Biju Das
In-Reply-To: <1510856571-30281-2-git-send-email-fabrizio.castro@bp.renesas.com>
On Thu, Nov 16, 2017 at 7:22 PM, Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> Change the sorting of the part numbers from descending to ascending to
> match with other documentation.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 0/7] R-Car D3 (r8a77995) CAN support
From: Simon Horman @ 2017-11-23 9:43 UTC (permalink / raw)
To: Ulrich Hecht
Cc: Linux-Renesas, linux-can, devicetree@vger.kernel.org,
Wolfram Sang, Geert Uytterhoeven, Magnus Damm, Chris Paterson,
Ramesh Shanmugasundaram
In-Reply-To: <CAO3366xk+Spa=z6bFW9TfqPk_8wUEd5scMK35JbXwpxZ2z7L2w@mail.gmail.com>
On Thu, Nov 23, 2017 at 08:43:18AM +0100, Ulrich Hecht wrote:
> On Wed, Nov 22, 2017 at 7:10 PM, Simon Horman <horms@verge.net.au> 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.
Thanks. I have applied them for v4.16.
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a7795: Move nodes which have no reg property out of bus
From: Simon Horman @ 2017-11-23 9:46 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux-Renesas, linux-arm-kernel@lists.infradead.org, Magnus Damm,
Arnd Bergmann, Rob Herring, Geert Uytterhoeven,
devicetree@vger.kernel.org
In-Reply-To: <CAMuHMdXqPqhiCZFseBGFDEh9R+_kFcrmjWWgCSudtnHkuXoFgw@mail.gmail.com>
On Thu, Nov 23, 2017 at 10:27:55AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Mon, Nov 20, 2017 at 12:01 PM, Simon Horman
> <horms+renesas@verge.net.au> wrote:
> > Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
> > The nodes that have been moved do not have any register properties and thus
> > shouldn't be placed on the bus.
> >
> > This problem is flagged by the compiler as follows:
> > $ make
> > ...
> > DTC arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb
> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
>
> [...]
>
> Thanks for your patch!
>
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > @@ -126,6 +126,86 @@
>
> The node above is called "cpus".
>
> > };
> > };
> >
> > + pmu_a57 {
>
> > + };
> > +
> > + pmu_a53 {
>
> > + };
> > +
> > + timer {
>
> > + };
> > +
> > + thermal-zones {
>
> > + };
> > +
> > extal_clk: extal {
> > compatible = "fixed-clock";
> > #clock-cells = <0>;
>
> Any sorting rules (alphabetically?) for nodes at the root level?
Now would be a good time to decide on an alternate on an order as
I plan to submit similar patches for several other SoCs.
I took used order they were already present (with other nodes) in the
cpu node. They appear to be sorted alphabetically. Should I keep that
sort order relative to existing nodes present in the root node?
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a7795: Move nodes which have no reg property out of bus
From: Geert Uytterhoeven @ 2017-11-23 9:49 UTC (permalink / raw)
To: Simon Horman
Cc: Linux-Renesas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Magnus Damm, Arnd Bergmann, Rob Herring, Geert Uytterhoeven,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20171123094657.r2wjbmvrn24ohrn6-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
Hi Simon,
On Thu, Nov 23, 2017 at 10:46 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> On Thu, Nov 23, 2017 at 10:27:55AM +0100, Geert Uytterhoeven wrote:
>> On Mon, Nov 20, 2017 at 12:01 PM, Simon Horman
>> <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
>> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> > @@ -126,6 +126,86 @@
>>
>> The node above is called "cpus".
>>
>> > };
>> > };
>> >
>> > + pmu_a57 {
>>
>> > + };
>> > +
>> > + pmu_a53 {
>>
>> > + };
>> > +
>> > + timer {
>>
>> > + };
>> > +
>> > + thermal-zones {
>>
>> > + };
>> > +
>> > extal_clk: extal {
>> > compatible = "fixed-clock";
>> > #clock-cells = <0>;
>>
>> Any sorting rules (alphabetically?) for nodes at the root level?
>
> Now would be a good time to decide on an alternate on an order as
> I plan to submit similar patches for several other SoCs.
>
> I took used order they were already present (with other nodes) in the
> cpu node. They appear to be sorted alphabetically. Should I keep that
> sort order relative to existing nodes present in the root node?
I think you should.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 4/8] drivers/fsi: sbefifo: Add in-kernel API
From: kbuild test robot @ 2017-11-23 9:50 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
bradleyb-r5pk2Da7Bxt8sGd51Jp2sdBPR1lH4CV8,
cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
joel-U3u1mxZcP9KHXe+LvDLADg,
eajames-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8, Edward A. James
In-Reply-To: <1511207217-14075-5-git-send-email-eajames-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]
Hi Edward,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR 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/Eddie-James/drivers-fsi-Add-SBEFIFO-and-OCC-client-drivers/20171123-041813
config: um-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=um
All errors (new ones prefixed by >>):
arch/um/drivers/vde.o: In function `vde_open_real':
(.text+0x951): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
(.text+0x79c): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
(.text+0xab5): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
arch/um/drivers/pcap.o: In function `pcap_nametoaddr':
(.text+0xdef5): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
arch/um/drivers/pcap.o: In function `pcap_nametonetaddr':
(.text+0xdf95): warning: Using 'getnetbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
arch/um/drivers/pcap.o: In function `pcap_nametoproto':
(.text+0xe1b5): warning: Using 'getprotobyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
arch/um/drivers/pcap.o: In function `pcap_nametoport':
(.text+0xdfe7): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
drivers/auxdisplay/img-ascii-lcd.o: In function `img_ascii_lcd_probe':
img-ascii-lcd.c:(.text+0x771): undefined reference to `devm_ioremap_resource'
drivers/fsi/fsi-sbefifo.o: In function `sbefifo_probe':
>> fsi-sbefifo.c:(.text+0x2666): undefined reference to `of_platform_device_create'
collect2: error: ld returned 1 exit status
---
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: 19833 bytes --]
^ permalink raw reply
* [PATCH v2 1/4] Documentation : can : flexcan : Add big-endian property to device tree
From: Pankaj Bansal @ 2017-11-23 9:55 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-can-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: V.Sethi-3arQi8VN3Tc, poonam.aggrwal-3arQi8VN3Tc, Pankaj Bansal
The FlexCAN controller can be modelled as little or big endian depending
on SOC design. This device tree property identifies the controller
endianness and the driver reads/writes controller registers based on
that.
This is optional property. i.e. if this property is not present in
device tree node then controller is assumed to be little endian. if this
property is present then controller is assumed to be big endian.
Signed-off-by: Pankaj Bansal <pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
Reviewed-by: Poonam Aggrwal <poonam.aggrwal-3arQi8VN3Tc@public.gmane.org>
---
Changes in v2:
- No change.
- Added one more patch in series.
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index 56d6cc3..bb081ba 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -18,6 +18,8 @@ Optional properties:
- xceiver-supply: Regulator that powers the CAN transceiver
+- big-endian: This means the registers of FlexCAN controller are big endian
+
Example:
can@1c000 {
--
2.7.4
--
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 v2 2/4] powerpc: dts: P1010: Add endianness property to flexcan node
From: Pankaj Bansal @ 2017-11-23 9:55 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-can-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: V.Sethi-3arQi8VN3Tc, poonam.aggrwal-3arQi8VN3Tc, Pankaj Bansal
In-Reply-To: <1511430935-29783-1-git-send-email-pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
The flexcan driver assumed that flexcan controller is big endian for
powerpc architecture and little endian for other architectures.
But this is not universally true. flexcan controller can be little or
big endian on any architecture.
Therefore the flexcan driver has been modified to check for "big-endian"
device tree property for controllers that are big endian.
consequently add the property to freescale P1010 SOC device tree.
Signed-off-by: Pankaj Bansal <pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
Reviewed-by: Poonam Aggrwal <poonam.aggrwal-3arQi8VN3Tc@public.gmane.org>
---
Changes in v2:
- No change.
- Added one more patch in series.
arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
index af12ead..1b4aafc 100644
--- a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
@@ -137,12 +137,14 @@
compatible = "fsl,p1010-flexcan";
reg = <0x1c000 0x1000>;
interrupts = <48 0x2 0 0>;
+ big-endian;
};
can1: can@1d000 {
compatible = "fsl,p1010-flexcan";
reg = <0x1d000 0x1000>;
interrupts = <61 0x2 0 0>;
+ big-endian;
};
L2: l2-cache-controller@20000 {
--
2.7.4
--
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 v2 3/4] arm/dts: Add nodes for flexcan devices present on LS1021A-Rev2 SoC
From: Pankaj Bansal @ 2017-11-23 9:55 UTC (permalink / raw)
To: wg, mkl, linux-can, robh+dt, mark.rutland, devicetree
Cc: V.Sethi, poonam.aggrwal, Pankaj Bansal, Bhupesh Sharma,
Sakar Arora
In-Reply-To: <1511430935-29783-1-git-send-email-pankaj.bansal@nxp.com>
This patch adds the device nodes for flexcan controller(s) present on
LS1021A-Rev2 SoC.
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
Signed-off-by: Sakar Arora <Sakar.Arora@freescale.com>
Reviewed-by: Zhengxiong Jin <Jason.Jin@freescale.com>
Reviewed-by: Poonam Aggrwal <poonam.aggrwal@nxp.com>
---
Changes in v2:
- No change.
- Added one more patch in series.
arch/arm/boot/dts/ls1021a-qds.dts | 16 +++++++++++++
arch/arm/boot/dts/ls1021a-twr.dts | 16 +++++++++++++
arch/arm/boot/dts/ls1021a.dtsi | 36 +++++++++++++++++++++++++++++
3 files changed, 68 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a-qds.dts b/arch/arm/boot/dts/ls1021a-qds.dts
index 9408753..4f211e3 100644
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -331,3 +331,19 @@
&uart1 {
status = "okay";
};
+
+&can0 {
+ status = "okay";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&can2 {
+ status = "disabled";
+};
+
+&can3 {
+ status = "disabled";
+};
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts b/arch/arm/boot/dts/ls1021a-twr.dts
index a8b148a..7202d9c 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -243,3 +243,19 @@
&uart1 {
status = "okay";
};
+
+&can0 {
+ status = "okay";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&can2 {
+ status = "disabled";
+};
+
+&can3 {
+ status = "disabled";
+};
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 9319e1f..7789031 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -730,5 +730,41 @@
<0000 0 0 3 &gic GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
<0000 0 0 4 &gic GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ can0: can@2a70000 {
+ compatible = "fsl,ls1021ar2-flexcan";
+ reg = <0x0 0x2a70000 0x0 0x1000>;
+ interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clockgen 4 1>, <&clockgen 4 1>;
+ clock-names = "ipg", "per";
+ big-endian;
+ };
+
+ can1: can@2a80000 {
+ compatible = "fsl,ls1021ar2-flexcan";
+ reg = <0x0 0x2a80000 0x0 0x1000>;
+ interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clockgen 4 1>, <&clockgen 4 1>;
+ clock-names = "ipg", "per";
+ big-endian;
+ };
+
+ can2: can@2a90000 {
+ compatible = "fsl,ls1021ar2-flexcan";
+ reg = <0x0 0x2a90000 0x0 0x1000>;
+ interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clockgen 4 1>, <&clockgen 4 1>;
+ clock-names = "ipg", "per";
+ big-endian;
+ };
+
+ can3: can@2aa0000 {
+ compatible = "fsl,ls1021ar2-flexcan";
+ reg = <0x0 0x2aa0000 0x0 0x1000>;
+ interrupts = <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clockgen 4 1>, <&clockgen 4 1>;
+ clock-names = "ipg", "per";
+ big-endian;
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/4] arm: dts: Remove p1010-flexcan compatible from imx series dts
From: Pankaj Bansal @ 2017-11-23 9:55 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-can-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: V.Sethi-3arQi8VN3Tc, poonam.aggrwal-3arQi8VN3Tc, Pankaj Bansal
In-Reply-To: <1511430935-29783-1-git-send-email-pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
The flexcan driver has been modified to check for big-endian dts
property for be read/write to flexcan registers/mb.
An exception to this rule is powerpc P1010RDB, which is always
big-endian, even if big-endian is not present in dts. This is
checked using p1010-flexcan compatible in dts.
Therefore, remove p1010-flexcan compatible from imx series dts,
as their flexcan core is little endian.
Signed-off-by: Pankaj Bansal <pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
---
Changes in v2:
- Add this patch in series.
arch/arm/boot/dts/imx25.dtsi | 4 ++--
arch/arm/boot/dts/imx28.dtsi | 4 ++--
arch/arm/boot/dts/imx35.dtsi | 4 ++--
arch/arm/boot/dts/imx53.dtsi | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 09ce8b8..fcaff1c 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -122,7 +122,7 @@
};
can1: can@43f88000 {
- compatible = "fsl,imx25-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx25-flexcan";
reg = <0x43f88000 0x4000>;
interrupts = <43>;
clocks = <&clks 75>, <&clks 75>;
@@ -131,7 +131,7 @@
};
can2: can@43f8c000 {
- compatible = "fsl,imx25-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx25-flexcan";
reg = <0x43f8c000 0x4000>;
interrupts = <44>;
clocks = <&clks 76>, <&clks 76>;
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 2f4ebe0..e52e05c 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -1038,7 +1038,7 @@
};
can0: can@80032000 {
- compatible = "fsl,imx28-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx28-flexcan";
reg = <0x80032000 0x2000>;
interrupts = <8>;
clocks = <&clks 58>, <&clks 58>;
@@ -1047,7 +1047,7 @@
};
can1: can@80034000 {
- compatible = "fsl,imx28-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx28-flexcan";
reg = <0x80034000 0x2000>;
interrupts = <9>;
clocks = <&clks 59>, <&clks 59>;
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index 6d5e6a6..1f0e220 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -303,7 +303,7 @@
};
can1: can@53fe4000 {
- compatible = "fsl,imx35-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx35-flexcan";
reg = <0x53fe4000 0x1000>;
clocks = <&clks 33>, <&clks 33>;
clock-names = "ipg", "per";
@@ -312,7 +312,7 @@
};
can2: can@53fe8000 {
- compatible = "fsl,imx35-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx35-flexcan";
reg = <0x53fe8000 0x1000>;
clocks = <&clks 34>, <&clks 34>;
clock-names = "ipg", "per";
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 8bf0d89..85573cf 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -545,7 +545,7 @@
};
can1: can@53fc8000 {
- compatible = "fsl,imx53-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx53-flexcan";
reg = <0x53fc8000 0x4000>;
interrupts = <82>;
clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>,
@@ -555,7 +555,7 @@
};
can2: can@53fcc000 {
- compatible = "fsl,imx53-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx53-flexcan";
reg = <0x53fcc000 0x4000>;
interrupts = <83>;
clocks = <&clks IMX5_CLK_CAN2_IPG_GATE>,
--
2.7.4
--
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
* Re: [PATCH v2 1/4] Documentation : can : flexcan : Add big-endian property to device tree
From: Marc Kleine-Budde @ 2017-11-23 10:02 UTC (permalink / raw)
To: Pankaj Bansal, wg-5Yr1BZd7O62+XT7JhA+gdA,
linux-can-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: V.Sethi-3arQi8VN3Tc, poonam.aggrwal-3arQi8VN3Tc
In-Reply-To: <1511430935-29783-1-git-send-email-pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1283 bytes --]
On 11/23/2017 10:55 AM, Pankaj Bansal wrote:
> The FlexCAN controller can be modelled as little or big endian depending
> on SOC design. This device tree property identifies the controller
> endianness and the driver reads/writes controller registers based on
> that.
>
> This is optional property. i.e. if this property is not present in
> device tree node then controller is assumed to be little endian. if this
> property is present then controller is assumed to be big endian.
>
> Signed-off-by: Pankaj Bansal <pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
> Reviewed-by: Poonam Aggrwal <poonam.aggrwal-3arQi8VN3Tc@public.gmane.org>
Please document the default behaviour in the bindings if the big-endian
property is missing.
This and the other series have to be applied in the correct order,
otherwise you break bisectability when removing the "fsl,p1010-flexcan"
from the mx{25,35,53} devicetree before adding the compatible to the
driver. Maybe merge these two series?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v7 11/13] slimbus: qcom: Add Qualcomm Slimbus controller driver
From: Charles Keepax @ 2017-11-23 10:07 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-12-srinivas.kandagatla@linaro.org>
On Wed, Nov 15, 2017 at 02:10:41PM +0000, srinivas.kandagatla@linaro.org wrote:
> From: Sagar Dharia <sdharia@codeaurora.org>
>
> This controller driver programs manager, interface, and framer
> devices for Qualcomm's slimbus HW block.
> Manager component currently implements logical address setting,
> and messaging interface.
> Interface device reports bus synchronization information, and framer
> device clocks the bus from the time it's woken up, until clock-pause
> is executed by the manager device.
>
> Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> +
> +static irqreturn_t qcom_slim_handle_rx_irq(struct qcom_slim_ctrl *ctrl,
> + u32 stat)
> +{
> + u32 *rx_buf, pkt[10];
> + bool q_rx = false;
> + u8 la, *buf, mc, mt, len, *b = (u8 *)&pkt[0];
> + u16 ele;
> +
This function feels pretty funky, we basically have rx_buf, pkt,
b and buf all of which basically point to the same thing. Can we
simplify it a little?
> + pkt[0] = readl_relaxed(ctrl->base + MGR_RX_MSG);
> + mt = SLIM_HEADER_GET_MT(b[0]);
> + len = SLIM_HEADER_GET_RL(b[0]);
> + mc = SLIM_HEADER_GET_MC(b[1]);
> +
> + /*
> + * this message cannot be handled by ISR, so
> + * let work-queue handle it
> + */
> + if (mt == SLIM_MSG_MT_CORE &&
> + mc == SLIM_MSG_MC_REPORT_PRESENT)
> + rx_buf = (u32 *)slim_alloc_rxbuf(ctrl);
> + else
> + rx_buf = pkt;
> +
> + if (rx_buf == NULL) {
> + dev_err(ctrl->dev, "dropping RX:0x%x due to RX full\n",
> + pkt[0]);
> + goto rx_ret_irq;
> + }
> +
> + rx_buf[0] = pkt[0];
This is the only time that rx_buf is used without being cast to a
u8* would there be any milage in combining b and buf, and getting
rid of rx_buf?
> + __ioread32_copy(rx_buf + 1, ctrl->base + MGR_RX_MSG + 4,
> + DIV_ROUND_UP(len, 4));
> +
> + switch (mc) {
> +
> + case SLIM_MSG_MC_REPORT_PRESENT:
> + q_rx = true;
> + break;
> + case SLIM_MSG_MC_REPLY_INFORMATION:
> + case SLIM_MSG_MC_REPLY_VALUE:
> + slim_msg_response(&ctrl->ctrl, (u8 *)(rx_buf + 1),
> + (u8)(*rx_buf >> 24), (len - 4));
> + break;
> + case SLIM_MSG_MC_REPORT_INFORMATION:
> + buf = (u8 *)rx_buf;
> + la = buf[2];
> + ele = (u16)buf[4] << 4;
> +
> + ele |= ((buf[3] & 0xf0) >> 4);
> + /*
> + * report information is most likely loss of
> + * sync or collision detected in data slots
> + */
> + dev_info(ctrl->dev, "LA:%d report inf ele:0x%x\n",
> + la, ele);
> + break;
> + default:
> + dev_err(ctrl->dev, "unsupported MC,%x MT:%x\n",
> + mc, mt);
> + break;
> + }
> +rx_ret_irq:
> + writel(MGR_INT_RX_MSG_RCVD, ctrl->base +
> + MGR_INT_CLR);
> + if (q_rx)
> + queue_work(ctrl->rxwq, &ctrl->wd);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int qcom_xfer_msg(struct slim_controller *sctrl,
> + struct slim_msg_txn *txn)
> +{
> + struct qcom_slim_ctrl *ctrl = dev_get_drvdata(sctrl->dev);
> + DECLARE_COMPLETION_ONSTACK(done);
> + void *pbuf = slim_alloc_txbuf(ctrl, txn, &done);
> + unsigned long ms = txn->rl + HZ;
> + u8 *puc;
> + int ret = 0, timeout, retries = QCOM_BUF_ALLOC_RETRIES;
> + u8 la = txn->la;
> + u32 *head;
> + /* HW expects length field to be excluded */
> + txn->rl--;
> +
> + /* spin till buffer is made available */
> + if (!pbuf) {
> + while (retries--) {
> + usleep_range(10000, 15000);
> + pbuf = slim_alloc_txbuf(ctrl, txn, &done);
> + if (pbuf)
> + break;
> + }
> + }
> +
> + if (!retries && !pbuf)
> + return -ENOMEM;
> +
> + puc = (u8 *)pbuf;
> + head = (u32 *)pbuf;
> +
> + if (txn->dt == SLIM_MSG_DEST_LOGICALADDR)
> + *head = SLIM_MSG_ASM_FIRST_WORD(txn->rl, txn->mt, txn->mc, 0,
> + la);
> + else
> + *head = SLIM_MSG_ASM_FIRST_WORD(txn->rl, txn->mt, txn->mc, 1,
> + la);
> +
> + if (txn->dt == SLIM_MSG_DEST_LOGICALADDR)
> + puc += 3;
> + else
> + puc += 2;
Combine these two if statements, makes it much clearer the actions
are related.
> +
> + if (txn->mt == SLIM_MSG_MT_CORE && slim_tid_txn(txn->mt, txn->mc))
slim_tid_txn checks for SLIM_MSG_MT_CORE so the check here should
be redundant.
> + *(puc++) = txn->tid;
> +
> + if ((txn->mt == SLIM_MSG_MT_CORE) &&
> + ((txn->mc >= SLIM_MSG_MC_REQUEST_INFORMATION &&
> + txn->mc <= SLIM_MSG_MC_REPORT_INFORMATION) ||
> + (txn->mc >= SLIM_MSG_MC_REQUEST_VALUE &&
> + txn->mc <= SLIM_MSG_MC_CHANGE_VALUE))) {
> + *(puc++) = (txn->ec & 0xFF);
> + *(puc++) = (txn->ec >> 8) & 0xFF;
> + }
As you already have slim_tid_txn, would it be worth adding
something like slim_ec_txn? To state if an element code is
required, feels like other controls will probably want to do a
similar thing and would make the code a little more readable
here.
> +
> + if (txn->msg && txn->msg->wbuf)
> + memcpy(puc, txn->msg->wbuf, txn->msg->num_bytes);
> +
> + qcom_slim_queue_tx(ctrl, head, txn->rl, MGR_TX_MSG);
> + timeout = wait_for_completion_timeout(&done, msecs_to_jiffies(ms));
> +
> + if (!timeout) {
> + dev_err(ctrl->dev, "TX timed out:MC:0x%x,mt:0x%x", txn->mc,
> + txn->mt);
> + ret = -ETIMEDOUT;
> + }
> +
> + return ret;
> +
> +}
> +
> +static void qcom_slim_rxwq(struct work_struct *work)
> +{
> + u8 buf[SLIM_MSGQ_BUF_LEN];
> + u8 mc, mt, len;
> + int i, ret;
> + struct qcom_slim_ctrl *ctrl = container_of(work, struct qcom_slim_ctrl,
> + wd);
> +
> + while ((slim_get_current_rxbuf(ctrl, buf)) != -ENODATA) {
> + len = SLIM_HEADER_GET_RL(buf[0]);
> + mt = SLIM_HEADER_GET_MT(buf[0]);
> + mc = SLIM_HEADER_GET_MC(buf[1]);
> + if (mt == SLIM_MSG_MT_CORE &&
> + mc == SLIM_MSG_MC_REPORT_PRESENT) {
> + u8 laddr;
> + struct slim_eaddr ea;
> + u8 e_addr[6];
> +
> + for (i = 0; i < 6; i++)
> + e_addr[i] = buf[7-i];
> +
> + ea.manf_id = (u16)(e_addr[5] << 8) | e_addr[4];
> + ea.prod_code = (u16)(e_addr[3] << 8) | e_addr[2];
> + ea.dev_index = e_addr[1];
> + ea.instance = e_addr[0];
If we are just bitshifting this out of the bytes does it really
make it much more clear to reverse the byte order first? Feels
like you might as well shift it out of buf directly.
Also we didn't bother to reverse the bytes for the element code
above, so feels more consistent.
> + ret = slim_device_report_present(&ctrl->ctrl,
> + &ea, &laddr);
> + if (ret < 0)
> + dev_err(ctrl->dev, "assign laddr failed:%d\n",
> + ret);
> + } else {
> + dev_err(ctrl->dev, "unexpected message:mc:%x, mt:%x\n",
> + mc, mt);
> + }
> + }
> +}
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH v7 12/13] slimbus: qcom: Add runtime-pm support using clock-pause
From: Charles Keepax @ 2017-11-23 10:17 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-13-srinivas.kandagatla@linaro.org>
On Wed, Nov 15, 2017 at 02:10:42PM +0000, srinivas.kandagatla@linaro.org wrote:
> From: Sagar Dharia <sdharia@codeaurora.org>
>
> Slimbus HW mandates that clock-pause sequence has to be executed
> before disabling relevant interface and core clocks.
> Runtime-PM's autosuspend feature is used here to enter/exit low
> power mode for Qualcomm's Slimbus controller. Autosuspend feature
> enables driver to avoid changing power-modes too frequently since
> entering clock-pause is an expensive sequence
>
> Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int qcom_slim_suspend(struct device *dev)
> +{
> + int ret = 0;
> +
> + if (!pm_runtime_enabled(dev) ||
> + (!pm_runtime_suspended(dev))) {
> + dev_dbg(dev, "system suspend");
> + ret = qcom_slim_runtime_suspend(dev);
> + }
> +
> + /*
> + * If the clock pause failed due to active channels, there is
> + * a possibility that some audio stream is active during suspend.
> + * (e.g. modem usecase during suspend)
> + * We dont want to return suspend failure in that case so that
> + * display and relevant components can still go to suspend.
> + * If there is some other error, then it should prevent
> + * system level suspend
> + */
> + if (ret == -EISCONN)
> + ret = 0;
Who actually returns the EISCONN for this to catch? Or will that
be added to slim_ctrl_clk_pause once support for the audio
channels is added?
Thanks,
Charles
> +
> + return ret;
> +}
^ permalink raw reply
* Re: [RFCv2 PATCH 01/36] iommu: Keep track of processes and PASIDs
From: Bob Liu @ 2017-11-23 10:33 UTC (permalink / raw)
To: Jean-Philippe Brucker,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Cc: Mark Rutland,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
Catalin Marinas, Will Deacon,
okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
rfranz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org,
lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org, Sudeep Holla
In-Reply-To: <42f815ee-2a9a-ac49-2392-5c03c1d4c809-5wv7dgnIgG8@public.gmane.org>
On 2017/11/22 21:04, Jean-Philippe Brucker wrote:
> On 22/11/17 03:15, Bob Liu wrote:
>> Hey Jean,
>>
>> On 2017/10/6 21:31, Jean-Philippe Brucker wrote:
>>> IOMMU drivers need a way to bind Linux processes to devices. This is used
>>> for Shared Virtual Memory (SVM), where devices support paging. In that
>>> mode, DMA can directly target virtual addresses of a process.
>>>
>>> Introduce boilerplate code for allocating process structures and binding
>>> them to devices. Four operations are added to IOMMU drivers:
>>>
>>> * process_alloc, process_free: to create an iommu_process structure and
>>> perform architecture-specific operations required to grab the process
>>> (for instance on ARM SMMU, pin down the CPU ASID). There is a single
>>> iommu_process structure per Linux process.
>>>
>>
>> I'm a bit confused here.
>> The original meaning of iommu_domain is a virtual addrspace defined by a set of io page table.
>> (fix me if I misunderstood).
>
> iommu_domain can also be seen as a logical partition of devices that share
> the same address spaces (the concept comes from AMD and Intel IOMMU
> domains, I believe). Without PASIDs it was a single address space, with
> PASIDs it can have multiple address spaces.
>
>> Then what's the meaning of iommu_domain and iommu_process after introducing iommu_process?
>> Could you consider document these concepts?
>
> iommu_process is used to keep track of Linux process address spaces. I'll
> rename it to io_mm in next version, to make it clear that it doesn't
> represent a Linux task but an mm_struct instead. However the
> implementation stays pretty much identical. A domain can be associated to
> multiple io_mm, and an io_mm can be associated to multiple domains.
>
> In the IOMMU architectures I know, PASID is implemented like this. You
> have the device tables (stream tables on SMMU), pointing to PASID tables
> (context descriptor tables on SMMU). In the following diagram,
>
> .->+--------+
> / 0 | |------ io_pgtable
> / +--------+
> / 1 | |------ io_mm->mm X
> +--------+ / +--------+
> 0 | A |-' 2 | |-.
> +--------+ +--------+ \
> 1 | | 3 | | \
> +--------+ +--------+ -- io_mm->mm Y
> 2 | B |--. PASID tables /
> +--------+ \ |
> 3 | B |----+--->+--------+ |
> +--------+ / 0 | |- | -- io_pgtable
> 4 | B |--' +--------+ |
> +--------+ 1 | | |
> Device tables +--------+ |
> 2 | |--'
> +--------+
> 3 | |------ io_mm->priv io_pgtable
> +--------+
> PASID tables
>
> * Device 0 (e.g. PCI 0000:00:00.0) is in domain A.
> * Devices 2, 3 and 4 are in domain B.
> * Domain A has the top set of PASID tables.
> * Domain B has the bottom set of PASID tables.
>
> * Domain A is bound to process address space X.
> -> Device 0 can access X with PASID 1.
> * Both domains A and B are bound to process address space Y.
> -> Devices 0, 2, 3 and 4 can access Y with PASID 2
>
> * PASID 0 is special on Arm SMMU (with S1DSS=0b10). It will always be
> reserved for classic DMA map/unmap. Even for hypothetical devices that
> don't support non-pasid transactions, I'd like to keep this convention.
> It should be quite useful for device drivers to have PASID 0 available
> with DMA map/unmap.
>
> * When introducing "private" PASID address spaces (that many are asking
> for), which are backed by a set of io-pgtable and map/unmap ops, I
> suppose they would reuse the io_mm structure. In this example PASID 3 is
> associated to a private address space and not backed by an mm. Since the
> PASID space is global, PASID 3 won't be available for any other domain.
>
> Does this clarify the current design, or is it just more confusing?
>
It's very helpful, thank you very much!
Regards,
Liubo
^ permalink raw reply
* Re: [PATCH 1/2] usb: xhci: add relaxed timing quirk bit
From: Mathias Nyman @ 2017-11-23 10:59 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: <3c44d4d0-e10c-bacc-8e7f-df04bed5dc21-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 23.11.2017 01:32, Adam Wallis wrote:
> 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?
>
I think current 40us is still reasonable, it's about ~3 times per
usb microframe (125us) .8000 interrupts per second just covers the microframe rate,
which is the shortest interval a interrupt transfer can require service.
1ms interrupt interval is too long. In the worst case ~8 microframes could pass
before the driver is aware of a error it needs to take care of.
USB 3.1 devices can transfer 6 burst of 16 max sized packets (6 x 16 x 2014) bytes
per microframe.
closer to 125us could probably work as well, but unless we are fixing some issue or
getting some other bigger benefit out of it I don't think it's worth changing it
just to see if it breaks stuff.
Thanks
-Mathias
--
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 v2 1/4] Documentation : can : flexcan : Add big-endian property to device tree
From: Pankaj Bansal @ 2017-11-23 12:08 UTC (permalink / raw)
To: Marc Kleine-Budde, wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org,
linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Varun Sethi, Poonam Aggrwal
In-Reply-To: <f859951e-072f-499b-5e86-1aaeb789a549-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2276 bytes --]
HI Marc,
> -----Original Message-----
> From: Marc Kleine-Budde [mailto:mkl@pengutronix.de]
> Sent: Thursday, November 23, 2017 3:32 PM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>; wg@grandegger.com; linux-
> can@vger.kernel.org; robh+dt@kernel.org; mark.rutland@arm.com;
> devicetree@vger.kernel.org
> Cc: Varun Sethi <V.Sethi@nxp.com>; Poonam Aggrwal
> <poonam.aggrwal@nxp.com>
> Subject: Re: [PATCH v2 1/4] Documentation : can : flexcan : Add big-endian
> property to device tree
>
> On 11/23/2017 10:55 AM, Pankaj Bansal wrote:
> > The FlexCAN controller can be modelled as little or big endian
> > depending on SOC design. This device tree property identifies the
> > controller endianness and the driver reads/writes controller registers
> > based on that.
> >
> > This is optional property. i.e. if this property is not present in
> > device tree node then controller is assumed to be little endian. if
> > this property is present then controller is assumed to be big endian.
> >
> > Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> > Reviewed-by: Poonam Aggrwal <poonam.aggrwal@nxp.com>
>
> Please document the default behaviour in the bindings if the big-endian
> property is missing.
Ok.
>
> This and the other series have to be applied in the correct order, otherwise
> you break bisectability when removing the "fsl,p1010-flexcan"
> from the mx{25,35,53} devicetree before adding the compatible to the driver.
> Maybe merge these two series?
>
Can we merge these 2 series ? one set of changes are in net/can directory which is managed in can-next branch.
Other set of changes are in device tree which is managed in dt-next branch.
I thought both these branches are independently updated and then all these branches
are merged in linux-next.
Please correct me if I am wrong.
> Marc
>
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Industrial Linux Solutions | Phone: +49-231-2826-924 |
> Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i
^ permalink raw reply
* Re: [PATCH v2 1/4] Documentation : can : flexcan : Add big-endian property to device tree
From: Marc Kleine-Budde @ 2017-11-23 12:30 UTC (permalink / raw)
To: Pankaj Bansal, wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org,
linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Varun Sethi, Poonam Aggrwal
In-Reply-To: <AM0PR0402MB3940CFEA5C70EE517E553CDBF1210-mYCQpYF9suc3mfjNbz3WnI3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 986 bytes --]
On 11/23/2017 01:08 PM, Pankaj Bansal wrote:
>> This and the other series have to be applied in the correct order, otherwise
>> you break bisectability when removing the "fsl,p1010-flexcan"
>> from the mx{25,35,53} devicetree before adding the compatible to the driver.
>> Maybe merge these two series?
>>
>
> Can we merge these 2 series ? one set of changes are in net/can
> directory which is managed in can-next branch. Other set of changes
> are in device tree which is managed in dt-next branch. I thought both
> these branches are independently updated and then all these branches
> are merged in linux-next.
They are independently managed, but the changes are not independent.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 0/5] Add basic support for emtrion emCON-MX6 modules
From: Jan Tuerk @ 2017-11-23 12:55 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Russell King, Shawn Guo, Sascha Hauer, Fabio Estevam, Jan Tuerk,
Andreas Färber, Kevin Hilman, Maxime Ripard,
Greg Kroah-Hartman, SZ Lin, Alexandre Belloni, devicetree,
linux-kernel, dri-devel, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 653 bytes --]
The following patch-series adds support for emtrion's emCON-MX6 modules
with all their dependencies. The focus is based on the emtion standard
developer-kit configuration. It includes a new vendor-prefix,
an new simple-panel type, a small modification of the imx6dl.dtsi,
as well as modifications of the common imx_v6_v8_defconfig.
And finally the board devicetrees themselves.
emtrion GmbH
Kreativpark - Alter Schlachthof 45
76131 Karlsruhe
GERMANY
http://www.emtrion.de
_______________________________________
Amtsgericht Mannheim
HRB 110 300
Geschäftsführer: Dieter Baur, Ramona Maurer
_______________________________________
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6
From: Jan Tuerk @ 2017-11-23 12:55 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Russell King, Shawn Guo, Sascha Hauer, Fabio Estevam, Jan Tuerk,
Andreas Färber, Kevin Hilman, Maxime Ripard,
Alexandre Belloni, Greg Kroah-Hartman, SZ Lin, devicetree,
linux-kernel, dri-devel, linux-arm-kernel
In-Reply-To: <20171123125600.41562-1-jan.tuerk@emtrion.com>
[-- Attachment #1: Type: text/plain, Size: 2811 bytes --]
The Emerging Display Technology ETM0700G0BDH6 is exactly
the same display as the ETM0700G0DH6, exept the pixelclock
polarity. Therefore re-use the ETM0700G0DH6 modes. It is
used by default on emtrion Avari based development kits.
Signed-off-by: Jan Tuerk <jan.tuerk@emtrion.com>
---
.../bindings/display/panel/edt,etm0700g0bdh6.txt | 9 +++++++++
drivers/gpu/drm/panel/panel-simple.c | 15 +++++++++++++++
2 files changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
diff --git a/Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt b/Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
new file mode 100644
index 000000000000..099e30bfa17f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
@@ -0,0 +1,9 @@
+Emerging Display Technology Corp. ETM0700G0BDH6 7.0" WVGA TFT LCD panel
+
+Required properties:
+ compatible: "edt,etm0700g0bdh6"
+
+This panel is exactly the same as ETM0700G0DH6 except the pixelclock polarity.
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index b7c4709f7b34..42442034b53e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -886,6 +886,18 @@ static const struct panel_desc edt_etm0700g0dh6 = {
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
};
+static const struct panel_desc edt_etm0700g0bdh6 = {
+ .modes = &edt_etm0700g0dh6_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
+};
+
static const struct drm_display_mode foxlink_fl500wvr00_a0t_mode = {
.clock = 32260,
.hdisplay = 800,
@@ -2029,6 +2041,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "edt,etm0700g0dh6",
.data = &edt_etm0700g0dh6,
}, {
+ .compatible = "edt,etm0700g0bdh6",
+ .data = &edt_etm0700g0bdh6,
+ }, {
.compatible = "foxlink,fl500wvr00-a0t",
.data = &foxlink_fl500wvr00_a0t,
}, {
--
2.11.0
emtrion GmbH
Kreativpark - Alter Schlachthof 45
76131 Karlsruhe
GERMANY
http://www.emtrion.de
_______________________________________
Amtsgericht Mannheim
HRB 110 300
Geschäftsführer: Dieter Baur, Ramona Maurer
_______________________________________
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox