* Re: [PATCH] dt-bindings: pinctrl: uniphier: add UniPhier pinctrl binding
From: Rob Herring @ 2017-11-30 20:24 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Greg Kroah-Hartman, Linus Walleij, Randy Dunlap,
Linux Kernel Mailing List, Mauro Carvalho Chehab, David S. Miller,
linux-arm-kernel
In-Reply-To: <CAK7LNAQYBe=x8sOBTrz8zE+5JEhOu+3eQKd8fbSAxi9Zuy18jQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Nov 28, 2017 at 9:44 PM, Masahiro Yamada
<yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org> wrote:
> Hi Rob,
>
>
> 2017-11-29 0:27 GMT+09:00 Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>> On Tue, Nov 28, 2017 at 04:49:45PM +0900, Masahiro Yamada wrote:
>>> The driver has been in the tree for a while, but its binding document
>>> is missing. Hence, here it is.
>>>
>>> Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
>>> ---
>>>
>>> .../pinctrl/socionext,uniphier-pinctrl.txt | 27 ++++++++++++++++++++++
>>> MAINTAINERS | 1 +
>>> 2 files changed, 28 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.txt
>>> new file mode 100644
>>> index 0000000..8173b12
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.txt
>>> @@ -0,0 +1,27 @@
>>> +UniPhier SoCs pin controller
>>> +
>>> +Required properties:
>>> +- compatible: should be one of the following:
>>> + "socionext,uniphier-ld4-pinctrl" - for LD4 SoC
>>> + "socionext,uniphier-pro4-pinctrl" - for Pro4 SoC
>>> + "socionext,uniphier-sld8-pinctrl" - for sLD8 SoC
>>> + "socionext,uniphier-pro5-pinctrl" - for Pro5 SoC
>>> + "socionext,uniphier-pxs2-pinctrl" - for PXs2 SoC
>>> + "socionext,uniphier-ld6b-pinctrl" - for LD6b SoC
>>> + "socionext,uniphier-ld11-pinctrl" - for LD11 SoC
>>> + "socionext,uniphier-ld20-pinctrl" - for LD20 SoC
>>> + "socionext,uniphier-pxs3-pinctrl" - for PXs3 SoC
>>> +
>>> +Note:
>>> +The UniPhier pinctrl should be a subnode of a "syscon" compatible node.
>>> +
>>> +Example:
>>> + soc-glue@5f800000 {
>>> + compatible = "socionext,uniphier-pro4-soc-glue",
>>> + "simple-mfd", "syscon";
>>> + reg = <0x5f800000 0x2000>;
>>> +
>>> + pinctrl: pinctrl {
>>> + compatible = "socionext,uniphier-pro4-pinctrl";
>>
>> There's not a contiguous register range that can be put here?
>
>
> Right.
>
> I saw SATA PHY registers are inserted among the pinctrl registers.
Okay,
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Hardware engineers often make crazy design.
If there's 2 ways to do things, they will find a 3rd way.
Rob
--
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
* [PATCH 8/8] PCIe: imx6: imx7d: add support for phy refclk source
From: tyler @ 2017-11-30 20:14 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel
Cc: robh+dt, mark.rutland, linux-arm-kernel, devicetree, linux-kernel,
Tyler Baker, Ilya Ledvich
In-Reply-To: <20171130201434.14122-1-tyler@opensourcefoundries.com>
From: Tyler Baker <tyler@opensourcefoundries.com>
In the i.MX7D the PCIe PHY can use either externel oscillator or
internal PLL as a reference clock source.
Add support for the PHY Reference Clock source including
device tree property phy-ref-clk.
External oscillator is used as a default reference clock source.
Signed-off-by: Tyler Baker <tyler@opensourcefoundries.com>
Signed-off-by: Ilya Ledvich <ilya@compulab.co.il>
---
drivers/pci/dwc/pci-imx6.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
index b734835..e935db4 100644
--- a/drivers/pci/dwc/pci-imx6.c
+++ b/drivers/pci/dwc/pci-imx6.c
@@ -45,6 +45,7 @@ enum imx6_pcie_variants {
struct imx6_pcie {
struct dw_pcie *pci;
int reset_gpio;
+ u32 phy_refclk;
bool gpio_active_high;
struct clk *pcie_bus;
struct clk *pcie_phy;
@@ -474,7 +475,7 @@ static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
switch (imx6_pcie->variant) {
case IMX7D:
regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
- IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
+ BIT(5), imx6_pcie->phy_refclk ? BIT(5) : 0);
break;
case IMX6SX:
regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
@@ -733,6 +734,11 @@ static int imx6_pcie_probe(struct platform_device *pdev)
if (IS_ERR(pci->dbi_base))
return PTR_ERR(pci->dbi_base);
+ /* Fetch PHY Reference Clock */
+ if (of_property_read_u32(node, "phy-ref-clk", &imx6_pcie->phy_refclk))
+ imx6_pcie->phy_refclk = 0;
+ pr_info("%s: phy_refclk = %d\n", __func__, imx6_pcie->phy_refclk);
+
/* Fetch GPIOs */
imx6_pcie->reset_gpio = of_get_named_gpio(node, "reset-gpio", 0);
imx6_pcie->gpio_active_high = of_property_read_bool(node,
--
2.9.3
^ permalink raw reply related
* [PATCH 7/8] ARM: dts: imx7s: add usb hsic phy domain
From: tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf @ 2017-11-30 20:14 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A, fabio.estevam-3arQi8VN3Tc,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Tyler Baker
In-Reply-To: <20171130201434.14122-1-tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
From: Tyler Baker <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
The GPCv2 driver should control the MIPI, PCIe,
and USB HSIC PHY regulators. Add the USB HSIC
power domain to the GPC node.
Signed-off-by: Tyler Baker <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
---
arch/arm/boot/dts/imx7s.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 151ab34..9626a3e 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -602,6 +602,12 @@
reg = <IMX7_POWER_DOMAIN_PCIE_PHY>;
power-supply = <®_1p0d>;
};
+ pgc_usb_hsic_phy: pgc-usb-hsic-phy-domain {
+ #power-domain-cells = <0>;
+
+ reg = <IMX7_POWER_DOMAIN_USB_HSIC_PHY>;
+ power-supply = <®_1p2>;
+ };
};
};
};
--
2.9.3
--
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 6/8] ARM: dts: imx7d-sbc-iot: enable PCIe peripheral
From: tyler @ 2017-11-30 20:14 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel
Cc: robh+dt, mark.rutland, linux-arm-kernel, devicetree, linux-kernel,
Tyler Baker
In-Reply-To: <20171130201434.14122-1-tyler@opensourcefoundries.com>
From: Tyler Baker <tyler@opensourcefoundries.com>
Add a PCIe device tree node to enable PCIe support.
Signed-off-by: Tyler Baker <tyler@opensourcefoundries.com>
---
arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts b/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
index 50dfdd3..7b21366 100644
--- a/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
@@ -127,6 +127,12 @@
>;
};
+ pinctrl_pcie: pciegrp {
+ fsl,pins = <
+ MX7D_PAD_EPDC_BDR1__GPIO2_IO29 0x34 /* PCIe RST */
+ >;
+ };
+
pinctrl_uart2: uart2grp {
fsl,pins = <
MX7D_PAD_LCD_ENABLE__UART2_DCE_TX 0x79 /* P7-12 */
@@ -201,6 +207,14 @@
};
};
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie>;
+ reset-gpio = <&gpio2 29 GPIO_ACTIVE_LOW>;
+ phy-ref-clk = <1>;
+ status = "okay";
+};
+
&uart2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart2>;
--
2.9.3
^ permalink raw reply related
* [PATCH 5/8] ARM: dts: imx7s: add node and supplies for vdd1p2
From: tyler @ 2017-11-30 20:14 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel
Cc: robh+dt, mark.rutland, linux-arm-kernel, devicetree, linux-kernel,
Tyler Baker
In-Reply-To: <20171130201434.14122-1-tyler@opensourcefoundries.com>
From: Tyler Baker <tyler@opensourcefoundries.com>
Add the regulator nodes and supplies for vdd1p2. This regulator is
used to power the GPC and USB HSIC PHY.
Signed-off-by: Tyler Baker <tyler@opensourcefoundries.com>
---
arch/arm/boot/dts/imx7s.dtsi | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 7b85659..151ab34 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -522,6 +522,20 @@
anatop-max-voltage = <1200000>;
anatop-enable-bit = <0>;
};
+
+ reg_1p2: regulator-vdd1p2@220 {
+ compatible = "fsl,anatop-regulator";
+ regulator-name = "vdd1p2";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ anatop-reg-offset = <0x220>;
+ anatop-vol-bit-shift = <8>;
+ anatop-vol-bit-width = <5>;
+ anatop-min-bit-val = <8>;
+ anatop-min-voltage = <1100000>;
+ anatop-max-voltage = <1300000>;
+ anatop-enable-bit = <0>;
+ };
};
snvs: snvs@30370000 {
@@ -578,7 +592,7 @@
#interrupt-cells = <3>;
interrupt-parent = <&intc>;
#power-domain-cells = <1>;
-
+ vcc-supply = <®_1p2>;
pgc {
#address-cells = <1>;
#size-cells = <0>;
@@ -961,6 +975,7 @@
compatible = "usb-nop-xceiv";
clocks = <&clks IMX7D_USB_HSIC_ROOT_CLK>;
clock-names = "main_clk";
+ vcc-supply = <®_1p2>;
};
usdhc1: usdhc@30b40000 {
--
2.9.3
^ permalink raw reply related
* [PATCH 4/8] ARM: dts: imx7s: add dma support
From: tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf @ 2017-11-30 20:14 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A, fabio.estevam-3arQi8VN3Tc,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Tyler Baker
In-Reply-To: <20171130201434.14122-1-tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
From: Tyler Baker <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
Enable dma on all SPI and UART interfaces.
Signed-off-by: Tyler Baker <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
---
arch/arm/boot/dts/imx7s.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 82ad26e..7b85659 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -700,6 +700,8 @@
clocks = <&clks IMX7D_ECSPI1_ROOT_CLK>,
<&clks IMX7D_ECSPI1_ROOT_CLK>;
clock-names = "ipg", "per";
+ dmas = <&sdma 0 7 1>, <&sdma 1 7 2>;
+ dma-names = "rx", "tx";
status = "disabled";
};
@@ -712,6 +714,8 @@
clocks = <&clks IMX7D_ECSPI2_ROOT_CLK>,
<&clks IMX7D_ECSPI2_ROOT_CLK>;
clock-names = "ipg", "per";
+ dmas = <&sdma 2 7 1>, <&sdma 3 7 2>;
+ dma-names = "rx", "tx";
status = "disabled";
};
@@ -724,6 +728,8 @@
clocks = <&clks IMX7D_ECSPI3_ROOT_CLK>,
<&clks IMX7D_ECSPI3_ROOT_CLK>;
clock-names = "ipg", "per";
+ dmas = <&sdma 4 7 1>, <&sdma 5 7 2>;
+ dma-names = "rx", "tx";
status = "disabled";
};
--
2.9.3
--
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 3/8] ARM: dts: imx7d-cl-som: add nodes for usbh, and usbotg2
From: tyler @ 2017-11-30 20:14 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel
Cc: robh+dt, mark.rutland, linux-arm-kernel, devicetree, linux-kernel,
Tyler Baker
In-Reply-To: <20171130201434.14122-1-tyler@opensourcefoundries.com>
From: Tyler Baker <tyler@opensourcefoundries.com>
Add device tree nodes for the USB hub, and USB OTG. i2c2 on this
platform supports low state retention power state so lets use it.
Signed-off-by: Tyler Baker <tyler@opensourcefoundries.com>
---
arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 36 +++++++++++++++++++++++++--------
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index ae45af1..a9f690b 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -30,6 +30,16 @@
gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+ reg_usbh_nreset: regulator@4 {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_host_nreset";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&pca9555 6 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ };
};
&cpu0 {
@@ -199,6 +209,16 @@
status = "okay";
};
+&usbotg2 {
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usbh {
+ vbus-supply = <®_usbh_nreset>;
+ status = "okay";
+};
+
&usdhc3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc3>;
@@ -247,13 +267,6 @@
>;
};
- pinctrl_i2c2: i2c2grp {
- fsl,pins = <
- MX7D_PAD_I2C2_SDA__I2C2_SDA 0x4000007f
- MX7D_PAD_I2C2_SCL__I2C2_SCL 0x4000007f
- >;
- };
-
pinctrl_uart1: uart1grp {
fsl,pins = <
MX7D_PAD_UART1_TX_DATA__UART1_DCE_TX 0x79
@@ -284,4 +297,11 @@
MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG PWREN */
>;
};
-};
\ No newline at end of file
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX7D_PAD_LPSR_GPIO1_IO07__I2C2_SDA 0x4000000f
+ MX7D_PAD_LPSR_GPIO1_IO06__I2C2_SCL 0x4000000f
+ >;
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 2/8] ARM: dts: imx7: build imx7d-sbc-iot-imx7 dtb
From: tyler @ 2017-11-30 20:14 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel
Cc: robh+dt, mark.rutland, linux-arm-kernel, devicetree, linux-kernel,
Tyler Baker
In-Reply-To: <20171130201434.14122-1-tyler@opensourcefoundries.com>
From: Tyler Baker <tyler@opensourcefoundries.com>
Build the imx7d-sbc-iot-imx7 device tree blob.
Signed-off-by: Tyler Baker <tyler@opensourcefoundries.com>
---
arch/arm/boot/dts/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9..0334137 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -515,6 +515,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
imx7d-nitrogen7.dtb \
imx7d-pico.dtb \
imx7d-sbc-imx7.dtb \
+ imx7d-sbc-iot-imx7.dtb \
imx7d-sdb.dtb \
imx7d-sdb-sht11.dtb \
imx7s-colibri-eval-v3.dtb \
--
2.9.3
^ permalink raw reply related
* [PATCH 1/8] ARM: dts: imx7d-sbc-iot: add initial iot gateway dts
From: tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf @ 2017-11-30 20:14 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A, fabio.estevam-3arQi8VN3Tc,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Tyler Baker, Ilya Ledvich
In-Reply-To: <20171130201434.14122-1-tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
From: Tyler Baker <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
The Compulab IoT Gateway is based on an NXP i.MX7D, dual core
Cortex-A7 clocking at 1GHz. It supports up to 2GB of DDR3,
and 32GB of eMMC flash. Onboard, there are two gigabit
ethernet controllers, 4 x USB2, RS485, and CAN.
This platform is based on the imx7d-cl-som-imx7 module but
includes a baseboard with additional peripherals
which is what this device tree is meant to describe.
This work has been derrived from the Compulab Linux sources
based on v4.1.
Signed-off-by: Tyler Baker <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
Signed-off-by: Ilya Ledvich <ilya-UTxiZqZC01RS1MOuV/RT9w@public.gmane.org>
---
arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts | 238 +++++++++++++++++++++++++++++++
1 file changed, 238 insertions(+)
create mode 100644 arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
diff --git a/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts b/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
new file mode 100644
index 0000000..50dfdd3
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
@@ -0,0 +1,238 @@
+/*
+ * Support for CompuLab SBC-IOT-iMX7 Single Board Computer
+ *
+ * Copyright (C) 2017 CompuLab Ltd. - http://www.compulab.co.il/
+ * Author: Ilya Ledvich <ilya-UTxiZqZC01RS1MOuV/RT9w@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "imx7d-cl-som-imx7.dts"
+
+/ {
+ model = "CompuLab SBC-IOT-iMX7";
+ compatible = "compulab,sbc-iot-imx7", "compulab,cl-som-imx7", "fsl,imx7d";
+
+ aliases {
+ lcdif = &lcdif;
+ };
+};
+
+&ecspi3 {
+ fsl,spi-num-chipselects = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs>;
+ cs-gpios = <&gpio4 11 0>;
+ status = "okay";
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+};
+
+&i2c4 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ status = "okay";
+
+ eeprom_iot@54 {
+ compatible = "atmel,24c08";
+ reg = <0x54>;
+ pagesize = <16>;
+ };
+
+ dvicape@39 {
+ compatible = "sil164_simple";
+ reg = <0x39>;
+ };
+};
+
+&iomuxc {
+ pinctrl_xpen: xpengrp {
+ fsl,pins = <
+ MX7D_PAD_LCD_DATA13__GPIO3_IO18 0x34 /* P7-4 - gpio82 */
+ MX7D_PAD_LCD_DATA12__GPIO3_IO17 0x34 /* P7-5 - gpio81 */
+ >;
+ };
+
+ pinctrl_ecspi3: ecspi3grp {
+ fsl,pins = <
+ MX7D_PAD_I2C1_SDA__ECSPI3_MOSI 0xf /* P7-8 */
+ MX7D_PAD_I2C1_SCL__ECSPI3_MISO 0xf /* P7-7 */
+ MX7D_PAD_I2C2_SCL__ECSPI3_SCLK 0xf /* P7-6 */
+ >;
+ };
+
+ pinctrl_ecspi3_cs: ecspi3_cs_grp {
+ fsl,pins = <
+ MX7D_PAD_I2C2_SDA__GPIO4_IO11 0x34 /* P7-9 */
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO09__I2C3_SDA 0x4000000f /* P7-3 */
+ MX7D_PAD_GPIO1_IO08__I2C3_SCL 0x4000000f /* P7-2 */
+ >;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO11__I2C4_SDA 0x4000000f
+ MX7D_PAD_GPIO1_IO10__I2C4_SCL 0x4000000f
+ >;
+ };
+
+ pinctrl_lcdif_dat: lcdifdatgrp {
+ fsl,pins = <
+ MX7D_PAD_LCD_DATA00__LCD_DATA0 0x79
+ MX7D_PAD_LCD_DATA01__LCD_DATA1 0x79
+ MX7D_PAD_LCD_DATA02__LCD_DATA2 0x79
+ MX7D_PAD_LCD_DATA03__LCD_DATA3 0x79
+ MX7D_PAD_EPDC_DATA04__LCD_DATA4 0x79
+ MX7D_PAD_EPDC_DATA05__LCD_DATA5 0x79
+ MX7D_PAD_EPDC_DATA06__LCD_DATA6 0x79
+ MX7D_PAD_EPDC_DATA07__LCD_DATA7 0x79
+ MX7D_PAD_EPDC_DATA08__LCD_DATA8 0x79
+ MX7D_PAD_EPDC_DATA09__LCD_DATA9 0x79
+ MX7D_PAD_EPDC_DATA10__LCD_DATA10 0x79
+ MX7D_PAD_EPDC_DATA11__LCD_DATA11 0x79
+ MX7D_PAD_EPDC_DATA12__LCD_DATA12 0x79
+ MX7D_PAD_EPDC_DATA13__LCD_DATA13 0x79
+ MX7D_PAD_EPDC_DATA14__LCD_DATA14 0x79
+ MX7D_PAD_EPDC_DATA15__LCD_DATA15 0x79
+ MX7D_PAD_LCD_DATA16__LCD_DATA16 0x79
+ MX7D_PAD_LCD_DATA17__LCD_DATA17 0x79
+ MX7D_PAD_LCD_DATA18__LCD_DATA18 0x79
+ MX7D_PAD_LCD_DATA19__LCD_DATA19 0x79
+ MX7D_PAD_LCD_DATA20__LCD_DATA20 0x79
+ MX7D_PAD_LCD_DATA21__LCD_DATA21 0x79
+ MX7D_PAD_LCD_DATA22__LCD_DATA22 0x79
+ MX7D_PAD_LCD_DATA23__LCD_DATA23 0x79
+ >;
+ };
+
+ pinctrl_lcdif_ctrl: lcdifctrlgrp {
+ fsl,pins = <
+ MX7D_PAD_EPDC_DATA00__LCD_CLK 0x79
+ MX7D_PAD_EPDC_DATA01__LCD_ENABLE 0x79
+ MX7D_PAD_EPDC_DATA02__LCD_VSYNC 0x79
+ MX7D_PAD_EPDC_DATA03__LCD_HSYNC 0x79
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX7D_PAD_LCD_ENABLE__UART2_DCE_TX 0x79 /* P7-12 */
+ MX7D_PAD_LCD_CLK__UART2_DCE_RX 0x79 /* P7-13 */
+ MX7D_PAD_LCD_VSYNC__UART2_DCE_CTS 0x79 /* P7-11 */
+ MX7D_PAD_LCD_HSYNC__UART2_DCE_RTS 0x79 /* P7-10 */
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ MX7D_PAD_I2C4_SDA__UART5_DCE_TX 0x79 /* RS232-TX */
+ MX7D_PAD_I2C4_SCL__UART5_DCE_RX 0x79 /* RS232-RX */
+ MX7D_PAD_I2C3_SDA__UART5_DCE_RTS 0x79 /* RS232-RTS */
+ MX7D_PAD_I2C3_SCL__UART5_DCE_CTS 0x79 /* RS232-CTS */
+ >;
+ };
+
+ pinctrl_uart7: uart7grp {
+ fsl,pins = <
+ MX7D_PAD_ECSPI2_MOSI__UART7_DCE_TX 0x79 /* R485-TX */
+ MX7D_PAD_ECSPI2_SCLK__UART7_DCE_RX 0x79 /* R485-RX */
+ MX7D_PAD_ECSPI2_SS0__UART7_DCE_CTS 0x79 /* R485-CTS */
+ MX7D_PAD_ECSPI2_MISO__UART7_DCE_RTS 0x79 /* R485-TTS */
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX7D_PAD_SD1_CMD__SD1_CMD 0x59
+ MX7D_PAD_SD1_CLK__SD1_CLK 0x19
+ MX7D_PAD_SD1_DATA0__SD1_DATA0 0x59
+ MX7D_PAD_SD1_DATA1__SD1_DATA1 0x59
+ MX7D_PAD_SD1_DATA2__SD1_DATA2 0x59
+ MX7D_PAD_SD1_DATA3__SD1_DATA3 0x59
+ MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x59 /* CD */
+ >;
+ };
+};
+
+&lcdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif_dat
+ &pinctrl_lcdif_ctrl>;
+ display = <&display0>;
+ status = "okay";
+
+ display0: display {
+ bits-per-pixel = <24>;
+ bus-width = <24>;
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: dvi {
+ /* 1024x768p60 */
+ clock-frequency = <65000000>;
+ hactive = <1024>;
+ hfront-porch = <40>;
+ hback-porch = <220>;
+ hsync-len = <60>;
+ vactive = <768>;
+ vfront-porch = <7>;
+ vback-porch = <21>;
+ vsync-len = <10>;
+
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <0>;
+ };
+ };
+ };
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ assigned-clocks = <&clks IMX7D_UART2_ROOT_SRC>;
+ assigned-clock-parents = <&clks IMX7D_OSC_24M_CLK>;
+ fsl,uart-has-rtscts;
+ status = "okay";
+};
+
+&uart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart5>;
+ assigned-clocks = <&clks IMX7D_UART5_ROOT_SRC>;
+ assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
+ fsl,uart-has-rtscts;
+ status = "okay";
+};
+
+&uart7 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart7>;
+ assigned-clocks = <&clks IMX7D_UART7_ROOT_SRC>;
+ assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
+ fsl,uart-has-rtscts;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+ wp-gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
+ enable-sdio-wakeup;
+ status = "okay";
+};
--
2.9.3
--
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 0/8] ARM: dts: introduce Compulab IoT Gateway
From: tyler @ 2017-11-30 20:14 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel
Cc: robh+dt, mark.rutland, linux-arm-kernel, devicetree, linux-kernel,
Tyler Baker
From: Tyler Baker <tyler@opensourcefoundries.com>
The Compulab IoT Gateway is based on an NXP i.MX7D, dual core
Cortex-A7 clocking at 1GHz. It supports up to 2GB of DDR3,
and 32GB of eMMC flash. Onboard, there are two gigabit
ethernet controllers, 4 x USB2, RS485, and CAN.
It uses the same SoM as the cl-som-imx7, but includes a baseboard
with additional I/O.
Compulab has provided patches for this platform based on v4.1.
I've used these patches as reference to get things working on tip.
The entire series is based on v4.15-rc1.
Tyler Baker (8):
ARM: dts: imx7d-sbc-iot: add initial iot gateway dts
ARM: dts: imx7: build imx7d-sbc-iot-imx7 dtb
ARM: dts: imx7d-cl-som: add nodes for usbh, and usbotg2
ARM: dts: imx7s: add dma support
ARM: dts: imx7s: add node and supplies for vdd1p2
ARM: dts: imx7d-sbc-iot: enable PCIe peripheral
ARM: dts: imx7s: add usb hsic phy domain
PCIe: imx6: imx7d: add support for phy refclk source
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 36 ++++-
arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts | 252 +++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx7s.dtsi | 29 +++-
drivers/pci/dwc/pci-imx6.c | 8 +-
5 files changed, 316 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
--
2.9.3
^ permalink raw reply
* Re: [PATCH 0/5] PCI: Add support to the Cadence PCIe controller
From: Cyrille Pitchen @ 2017-11-30 20:05 UTC (permalink / raw)
To: Lorenzo Pieralisi, Kishon Vijay Abraham I
Cc: bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-pci-u79uwXL29TY76Z2rM5mHXA,
adouglas-vna1KIf7WgpBDgjK7y7TUQ, stelford-vna1KIf7WgpBDgjK7y7TUQ,
dgary-vna1KIf7WgpBDgjK7y7TUQ, kgopi-vna1KIf7WgpBDgjK7y7TUQ,
eandrews-vna1KIf7WgpBDgjK7y7TUQ,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
sureshp-vna1KIf7WgpBDgjK7y7TUQ, nsekhar-l0cyMroinI0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <a02af401-2eb8-dc34-6f3c-092f04ec2636-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Le 30/11/2017 à 19:45, Cyrille Pitchen a écrit :
> Hi all,
>
> Le 30/11/2017 à 19:18, Lorenzo Pieralisi a écrit :
>> On Thu, Nov 30, 2017 at 12:43:20PM +0530, Kishon Vijay Abraham I wrote:
>>
>> [...]
>>
>>>>> For linux-next, I applied this series on top of Kishon's patch
>>>>> ("PCI: endpoint: Use EPC's device in dma_alloc_coherent/dma_free_coherent")
>>>>> otherwise dma_alloc_coherent() fails when called by pci_epf_alloc_space().
>>>>>
>>>>> Also, I patched drivers/Makefile rather than drivers/pci/Makefile to make
>>>>> the drivers/pci/cadence/pcie-cadence-ep.o linked after
>>>
>>> The reason to patch drivers/Makefile should be because pcie-cadence-ep has to
>>> be compiled even when CONFIG_PCI is not enabled. CONFIG_PCI enables host
>>> specific features and ENDPOINT shouldn't depend on CONFIG_PCI.
>>>>> drivers/pci/endpoint/*.o objects, otherwise the built-in pci-cadence-ep
>>>>> driver would be probed before the PCI endpoint framework would have been
>>>>> initialized, which results in a kernel crash.
>>>>
>>>> Nice :( - isn't there a way to improve this (ie probe deferral or
>>>> registering the EPF bus earlier) ?
>>>>
>>>>> I guess this is the reason why the "pci/dwc" line was also put in
>>>>> drivers/Makefile, right after the "pci/endpoint" line.
>>>>
>>>> Or probably the other way around - see commit 5e8cb4033807
>>>>
>>>> @Kishon, thoughts ?
>>>
>>> Lorenzo, ordering Makefile is one way to initialize EP core before
>>
>> Makefile ordering is fragile, I do not like relying on it.
>>
>>> other drivers. the other way is to have PCI EP core have a different
>>> initcall level.. subsys_initcall??
>>
>> Yes, registering the bus at eg postcore_initcall() as PCI does should do
>> (if that's the problem this is solving) but still, the code must not
>> crash if the ordering is not correct, we have to fix this regardless.
>>
>> I would appreciate if Cyrille can debug the cause of the kernel crash
>> so that we can fix it in the longer term.
>>
>
> I had the crash kernel few weeks ago hence I have to test again to confirm
> but if I remember correctly it was a NULL pointer dereferencing crash:
>
> cdns_pcie_ep_probe()
> |
> +--> devm_pci_epc_create()
> |
> +--> __devm_pci_ep_create()
> |
> +--> __pci_epc_create()
> |
> +--> pci_ep_cfs_add_epc_group()
> |
> | /*
> | * Here controllers_group is still NULL because
> | * pci_ep_cfs_init() has not been called yet.
> | */
> +--> configfs_register_group(controllers_group, ...)
> |
> +--> link_group()
> /* Dereferencing NULL pointer */
>
> Best regards,
>
> Cyrille
>
I know it's far from perfect but what do you think or something like that:
---8<---------------------------------------------------------------------------
diff --git a/drivers/Makefile b/drivers/Makefile
index 27bdd98784d9..9757199b9a65 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -16,11 +16,7 @@ obj-$(CONFIG_PINCTRL) += pinctrl/
obj-$(CONFIG_GPIOLIB) += gpio/
obj-y += pwm/
-obj-$(CONFIG_PCI) += pci/
-obj-$(CONFIG_PCI_ENDPOINT) += pci/endpoint/
-obj-$(CONFIG_PCI_CADENCE) += pci/cadence/
-# PCI dwc controller drivers
-obj-y += pci/dwc/
+obj-y += pci/
obj-$(CONFIG_PARISC) += parisc/
obj-$(CONFIG_RAPIDIO) += rapidio/
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 3d5e047f0a32..4e57fe4499ce 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -3,6 +3,7 @@
# Makefile for the PCI bus specific drivers.
#
+ifdef CONFIG_PCI
obj-y += access.o bus.o probe.o host-bridge.o remove.o pci.o \
pci-driver.o search.o pci-sysfs.o rom.o setup-res.o \
irq.o vpd.o setup-bus.o vc.o mmap.o setup-irq.o
@@ -54,3 +55,9 @@ ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
# PCI host controller drivers
obj-y += host/
obj-y += switch/
+endif
+
+obj-$(CONFIG_PCI_ENDPOINT) += endpoint/
+obj-$(CONFIG_PCI_CADENCE) += cadence/
+# PCI dwc controller drivers
+obj-y += dwc/
---8<---------------------------------------------------------------------------
I admit it doesn't solve the ordering issue but at least it cleans some mess
in drivers/Makefile.
I agree with Lorenzo, we should avoid as much as we could to rely on the
link order.
However I faced another issue: code from pcie-cadence.c is used by both
pcie-cadence-host.c and pcie-cadence-ep.c so I had to find a way to compile
this shared file if at least one of the host and EPC driver was selected.
That's why I put source files in the cadence sub-directory and used the
single cadence/Makefile to regroup all the compilation rules, instead of
splitting them between pci/Makefile and pci/endpoint/Makefile and having to
add pcie-cadence.o in both Makefiles.
>> Thanks,
>> Lorenzo
>>
>
>
--
Cyrille Pitchen, Free Electrons
Embedded Linux and Kernel engineering
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 related
* Re: [PATCH V2 5/9] PCI: Export pci_flags
From: Manikanta Maddireddy @ 2017-11-30 19:38 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi
Cc: thierry.reding, jonathanh, robh+dt, frowand.list, bhelgaas, rjw,
tglx, vidyas, kthota, linux-tegra, devicetree, linux-pci,
linux-pm
In-Reply-To: <20171130184224.GA19640@bhelgaas-glaptop.roam.corp.google.com>
On 01-Dec-17 12:12 AM, Bjorn Helgaas wrote:
> On Thu, Nov 30, 2017 at 10:24:37AM +0000, Lorenzo Pieralisi wrote:
>> On Wed, Nov 29, 2017 at 11:01:33AM -0600, Bjorn Helgaas wrote:
>>> [+cc Lorenzo]
>>>
>>> On Sun, Nov 26, 2017 at 01:02:09AM +0530, Manikanta Maddireddy wrote:
>>>> pci_flags variable is used in inline functions in 'pci.h', Tegra PCIe
>>>> driver use one of these functions pci_add_flags() and includes 'pci.h'.
>>>> Export pci_flags to allow Tegra PCIe host controller driver to be
>>>> compiled as loadable kernel module.
>>>
>>> Here's the usage in tegra_pcie_probe():
>>>
>>> pci_add_flags(PCI_REASSIGN_ALL_RSRC | PCI_REASSIGN_ALL_BUS);
>>>
>>> We've probably had this discussion before, but I don't know why Tegra
>>> needs PCI_REASSIGN_ALL_RSRC and PCI_REASSIGN_ALL_BUS.
>>>
>>> I would prefer to drop this usage of pci_add_flags() if possible. It
>>> seems to be just an arm/powerpc thing and I'm not convinced it's
>>> really necessary.
>>
>> It is hard to say if it is really necessary (because it depends
>> on firmware configuration - ie pci_scan_bridge()), that's the
>> problem.
>>
>> I suspect it can trigger regressions if we do not set it (since
>> it affects what pcibios_assign_all_busses() returns on eg arm/arm64).
>>
>> There are two things we can do:
>>
>> 1) Set it unconditionally in arch code (in a hook to be defined)
>> 2) We remove it on a per-host bridge basis and ask for testing
>>
>> I agree this may have trickled from host bridge to host bridge through
>> copy'n'paste and it is not based on any firmware assumtpion but I can't
>> say if it is really needed.
>
> My basic position is that if resources are not assigned correctly, the
> PCI core should automatically try to assign them, regardless of
> whether PCI_REASSIGN_ALL_RSRC or PCI_REASSIGN_ALL_BUS is set. If that
> doesn't work, I think there's something wrongin the PCI core and we
> should fix that.
>
> This might be an opportunity to try removing the use of
> pci_add_flags() and see what breaks.
>
> Bjorn
>
As per the Tegra TRM primary, secondary and subordinate default
bus numbers are 0 and it is expecting SW to program these numbers.
I believe this is the reason for adding PCI_REASSIGN_ALL_RSRC and
PCI_REASSIGN_ALL_BUS flags.
Looking at the function pci_scan_bridge_extend(), if secondary and
subordinate bus numbers are 0 it is assigning bus numbers even if
these flags are not set.
In the basic testing with one endpoint PCIe link up is working
fine without these flags, however I would like test with PCIe switch
and multiple endpoints connected to Tegra.
Manikanta
^ permalink raw reply
* Re: [PATCH v8 07/13] slimbus: Add support for 'clock-pause' feature
From: Philippe Ombredanne @ 2017-11-30 19:25 UTC (permalink / raw)
To: Srini Kandagatla
Cc: Greg Kroah-Hartman, Mark, ALSA, Sagar Dharia, bp, poeschel,
treding, andreas.noever, alan, mathieu.poirier, daniel, jkosina,
sharon.dvir1, Joe Perches, David S. Miller, james.hogan,
michael.opdenacker, Rob Herring, pawel.moll, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
linux-arm-msm, Vinod Koul, Arnd Bergmann <arn>
In-Reply-To: <20171130174200.6684-8-srinivas.kandagatla@linaro.org>
On Thu, Nov 30, 2017 at 6:41 PM, <srinivas.kandagatla@linaro.org> wrote:
[]
> diff --git a/drivers/slimbus/sched.c b/drivers/slimbus/sched.c
> new file mode 100644
> index 000000000000..74300f1a6898
> --- /dev/null
> +++ b/drivers/slimbus/sched.c
> @@ -0,0 +1,128 @@
> +/* Copyright (c) 2011-2016, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
Could it make sense to use the new SPDX ids here? e.g.
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2011-2016, The Linux Foundation
This neat and cleaner, is it?
See tglx doc posted as patches and Linus comments for a rationale on
the comment styles.
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.
From: Doug Anderson @ 2017-11-30 19:06 UTC (permalink / raw)
To: Enric Balletbo Serra
Cc: Daniel Thompson, Enric Balletbo i Serra, Jingoo Han,
Richard Purdie, Jacek Anaszewski, Pavel Machek, Rob Herring,
Brian Norris, Guenter Roeck, Lee Jones, Alexandru Stan,
linux-leds, devicetree@vger.kernel.org, LKML
In-Reply-To: <CAFqH_50qgvntzwvZ_n3qhpw+BA2SpYqiJgsxfCMt1piNWzgDmA@mail.gmail.com>
Hi
On Thu, Nov 30, 2017 at 10:34 AM, Enric Balletbo Serra
<eballetbo@gmail.com> wrote:
> Hi,
>
> 2017-11-30 12:27 GMT+01:00 Daniel Thompson <daniel.thompson@linaro.org>:
>>
>>
>> On 30/11/17 00:44, Doug Anderson wrote:
>>>
>>> Hi,
>>>
>>> On Thu, Nov 16, 2017 at 6:11 AM, Enric Balletbo i Serra
>>> <enric.balletbo@collabora.com> wrote:
>>>>
>>>> When you want to change the brightness using a PWM signal, one thing you
>>>> need to consider is how human perceive the brightness. Human perceive the
>>>> brightness change non-linearly, we have better sensitivity at low
>>>> luminance than high luminance, so to achieve perceived linear dimming,
>>>> the
>>>> brightness must be matches to the way our eyes behave. The CIE 1931
>>>> lightness formula is what actually describes how we perceive light.
>>>>
>>>> This patch adds support to compute the brightness levels based on a
>>>> static
>>>> table filled with the numbers provided by the CIE 1931 algorithm, for now
>>>> it only supports PWM resolutions up to 65535 (16 bits) with 1024 steps.
>>>> Lower PWM resolutions are implemented using the same curve but with less
>>>> steps, e.g. For a PWM resolution of 256 (8 bits) we have 37 steps.
>>>
>>>
>>> Your patch assumes that the input to your formula (luminance, I think)
>>> scales linearly with PWM duty cycle. I don't personally know this,
>>> but has anyone confirmed it's common in reality, or at least is a
>>> close enough approximation of reality?
>>
>>
>> Isn't this the loop we went round for v1?
>>
>> We do know that its not linear, however the graphs from a couple of example
>> devices didn't look too scary and nobody has proposed a better formula.
>>
>> At this point the linear interpolation code in patch 1 allows people with
>> especially alinear devices to express suitable brightness curves.
>>
>> However we also know that many DT authors choose not to create good
>> brightness tables for their devices... and we'd rather they used allowed the
>> kernel to choose a model than to use no model at all.
>>
>>
>> Daniel.
>>
>>
>>
>> Enric: BTW sorry I haven't replied so far. That's mostly because
>> these looked more "real" and that I should pay them close
>> attention (which requires time I haven't had spare to
>> consume yet).
>>
>
> No problem. It also took me some time to send v2 because of was busy
> with other things :)
>
>>
>>
>>>> The calculation of the duty cycle using the CIE 1931 algorithm is enabled
>>>> by
>>>> default when you do not define the 'brightness-levels' propriety in your
>>>> device tree.
>>>
>>>
>>> One note is that you probably still want at least a "min" duty cycle.
>>> I seem to remember some PWM backlights don't work well when the duty
>>> cycle is too low and it would still be nice to be able to use your
>>> table.
>>>
>
> Right, iirc that is needed on some veyron devices, and this is another
> reason why the first patch needs to support to be able to describe
> corrected gamma curves and not only linear-interpolation between 2
> points. I'd say that:
>
> 1. For low and high resolution PWMs, if you know nothing about PWM
> backlight, patch 2 can provide to the user a default table that should
> work.
> 2. If you need something more specific you should use the old way
> (aka, use brightness levels table)
> 2.1 If you have a high resolution PWM you might be interested on
> enable interpolation.
The thing I was thinking was that it might be very common to have a
min PWM duty cycle. It would be a shame if patch set #2 was almost a
perfect fit but you were forced to specify a table in the device tree
(to get your output to be linear w/ respect to human perception) just
because you had a minimum duty cycle.
>>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>>>> ---
>>>> drivers/video/backlight/pwm_bl.c | 160
>>>> +++++++++++++++++++++++++++++++++++----
>>>> include/linux/pwm_backlight.h | 1 +
>>>> 2 files changed, 147 insertions(+), 14 deletions(-)
>>>
>>>
>>> Something I'd like to see in a patch somewhere in this series is a way
>>> to expose the backlight "units" to userspace. As far as I know right
>>> now the backlight exposed to userspace is "unitless", but it would be
>>> nice for userspace to query that the backlight is now linear to human
>>> perception. For old code, it could always expose the unit as
>>> "unknown".
>>>
>>>
>>>> diff --git a/drivers/video/backlight/pwm_bl.c
>>>> b/drivers/video/backlight/pwm_bl.c
>>>> index 59b1bfb..ea96358 100644
>>>> --- a/drivers/video/backlight/pwm_bl.c
>>>> +++ b/drivers/video/backlight/pwm_bl.c
>>>> @@ -26,6 +26,112 @@
>>>>
>>>> #define NSTEPS 256
>>>>
>>>> +/*
>>>> + * CIE lightness to PWM conversion table. The CIE 1931 lightness formula
>>>> is what
>>>> + * actually describes how we perceive light:
>>>> + *
>>>> + * Y = (L* / 902.3) if L* ≤ 0.08856
>>>> + * Y = ((L* + 16) / 116)^3 if L* > 0.08856
>>>> + *
>>>> + * Where Y is the luminance (output) between 0.0 and 1.0, and L* is the
>>>> + * lightness (input) between 0 and 100.
>>>
>>>
>>> Just because I'm stupid and not 100% sure, I think:
>>>
>
> Just because I'm also stupid and I'm still learning :) I'll try to
> clarify a bit more that ...
>
>
>>> luminance = the amount of light coming out of the screen
>>> lightness = how bright a human perceives the screen to be
>>>
>>> Is that right? If so could you add it to the comments? So "output"
>>> here is the output to the PWM and "input" is the input from userspace
>>> (and thus should be expressed in terms of human perception).
>>>
>
> Yes, I think that how you describe luminance and lightness is right,
> and sounds good improve the doc.
>
> To be clear the correction table for PWM values can be calculated with
> this code.
>
> OUTPUT_SIZE = 65535 # Output integer size
> INPUT_SIZE = 2047
>
> def cie1931(L):
> L = L*100.0
> if L <= 8:
> return (L/902.3)
> else:
> return ((L+16.0)/116.0)**3
>
> x = range(0,int(INPUT_SIZE+1))
> y = [int(round(cie1931(float(L)/INPUT_SIZE)*(OUTPUT_SIZE))) for L in x]
Personally I'd love to see that little bit of code in the commit
message to help explain where the table came from, though I'm known
for putting PhD theses in my commit messages... ;)
>>>> + 0, 7, 14, 21, 28, 35, 43, 50, 57, 64, 71, 78, 85, 92, 99, 106,
>>>> 114, 121,
>>>
>>>
>>> Seems like you could save space (and nicely use the previous patch) by
>>> using the linear interpolation code from the previous patch, since
>>>
>>> 0 + 7 = 7
>>> + 7 = 14
>>> + 7 = 21
>>> + 7 = 28
>>> + 7 = 35
>>>
>>> ...and it would likely be OK to keep going and be slight off, so:
>>>
>>> + 7 = 42
>>> + 7 = 49
>>> + 7 = 56
>>> + 7 = 63
>>> + 7 = 70
>>> ...
>>> ...
>>>
>>> In other words it seems like you're just providing a default table...
>>>
>
> Yes, I think that's the Daniel idea ;)
>
>>> -Doug
>>>
>>
>
> Best regards,
> - Enric
^ permalink raw reply
* Re: [PATCH 04/10] ARM: tegra: EXPORT tegra_cpuidle_pcie_irqs_in_use()
From: Manikanta Maddireddy @ 2017-11-30 18:46 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: thierry.reding, jonathanh, robh+dt, frowand.list, bhelgaas, rjw,
tglx, vidyas, kthota, linux-tegra, devicetree, linux-pci,
linux-pm
In-Reply-To: <20171130124149.GB12096@red-moon>
On 30-Nov-17 6:11 PM, Lorenzo Pieralisi wrote:
> On Fri, Nov 24, 2017 at 09:23:14PM +0530, Manikanta Maddireddy wrote:
>> EXPORT tegra_cpuidle_pcie_irqs_in_use() to allow Tegra PCIe driver to be
>> compiled as loadable kernel module.
>>
>> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
>> ---
>> arch/arm/mach-tegra/cpuidle.c | 1 +
>> 1 file changed, 1 insertion(+)
>
> You should find a way to remove this call and the corresponding
> drivers->arch dependency, not to export it by spreading it even
> further.
>
> Lorenzo
>
I will drop this patch from the series and will explore the possibilities of
removing the arch dependency. I will address it in next series of patches
>> diff --git a/arch/arm/mach-tegra/cpuidle.c b/arch/arm/mach-tegra/cpuidle.c
>> index 316563141add..7d7e6d3ce32d 100644
>> --- a/arch/arm/mach-tegra/cpuidle.c
>> +++ b/arch/arm/mach-tegra/cpuidle.c
>> @@ -57,3 +57,4 @@ void tegra_cpuidle_pcie_irqs_in_use(void)
>> break;
>> }
>> }
>> +EXPORT_SYMBOL(tegra_cpuidle_pcie_irqs_in_use);
>> --
>> 2.1.4
>>
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: dts: at91: disable the nxp,se97b SMBUS timeout on the TSE-850
From: Peter Rosin @ 2017-11-30 18:46 UTC (permalink / raw)
To: Alexandre Belloni, Guenter Roeck
Cc: linux-kernel, Rob Herring, Mark Rutland, Nicolas Ferre,
Russell King, Jean Delvare, Ludovic Desroches, devicetree,
linux-arm-kernel, linux-hwmon
In-Reply-To: <20171130172606.GZ21126@piout.net>
On 2017-11-30 18:26, Alexandre Belloni wrote:
> On 30/11/2017 at 09:16:38 -0800, Guenter Roeck wrote:
>> On Wed, Nov 29, 2017 at 09:56:29PM +0100, Alexandre Belloni wrote:
>>> On 29/11/2017 at 12:53:11 -0800, Guenter Roeck wrote:
>>>> On Mon, Nov 27, 2017 at 05:31:01PM +0100, Peter Rosin wrote:
>>>>> The I2C adapter driver is sometimes slow, causing the SCL line to
>>>>> be stuck low for more than the stipulated SMBUS timeout of 25-35 ms.
>>>>> This causes the client device to give up which in turn causes silent
>>>>> corruption of data. So, disable the SMBUS timeout in the client device.
>>>>>
>>>>> Signed-off-by: Peter Rosin <peda@axentia.se>
>>>>
>>>> Acked-by: Guenter Roeck <linux@roeck-us.net>
>>>>
>>>> I assume this will be sent upstream through an arm tree.
>>>>
>>>
>>> Yes, I'm applying it right now.
>>>
>> Are you going to apply the patch for 4.15, or queue it up for 4.16 ?
>> I have been arguing with myself if this is a feature or a bug fix.
>> So far I queued the driver change up for 4.16, but I am open to
>> applying it to 4.15. Any thoughts ?
>>
>
> I was wondering that myself. I'm open to have it as a fix in 4.15. Or
> maybe Peter can send the series to stable if he needs it in 4.14.
>
> Peter, what do you think/want?
TL;DR Either way is fine.
I think it's a bugfix; it fixes real problems where the application
misbehave due to faulty content when reading from an eeprom. I'm
expecting to make a new release for the hw in question RSN and these
are the only local patches. So, it would be nice if they made it to
4.14.x before my release happens. However, it's not like it's difficult
to rebase the patches should that backport not happen or take too long.
The badness started to happen much more frequently due to some timing
difference affecting the i2c bus driver, but in theory it's a problem
that has been there from the start. I have just not noticed it before...
Cheers,
Peter
^ permalink raw reply
* Re: [PATCH 0/5] PCI: Add support to the Cadence PCIe controller
From: Cyrille Pitchen @ 2017-11-30 18:45 UTC (permalink / raw)
To: Lorenzo Pieralisi, Kishon Vijay Abraham I
Cc: bhelgaas, linux-pci, adouglas, stelford, dgary, kgopi, eandrews,
thomas.petazzoni, sureshp, nsekhar, linux-kernel, robh,
devicetree
In-Reply-To: <20171130181819.GD12096@red-moon>
Hi all,
Le 30/11/2017 à 19:18, Lorenzo Pieralisi a écrit :
> On Thu, Nov 30, 2017 at 12:43:20PM +0530, Kishon Vijay Abraham I wrote:
>
> [...]
>
>>>> For linux-next, I applied this series on top of Kishon's patch
>>>> ("PCI: endpoint: Use EPC's device in dma_alloc_coherent/dma_free_coherent")
>>>> otherwise dma_alloc_coherent() fails when called by pci_epf_alloc_space().
>>>>
>>>> Also, I patched drivers/Makefile rather than drivers/pci/Makefile to make
>>>> the drivers/pci/cadence/pcie-cadence-ep.o linked after
>>
>> The reason to patch drivers/Makefile should be because pcie-cadence-ep has to
>> be compiled even when CONFIG_PCI is not enabled. CONFIG_PCI enables host
>> specific features and ENDPOINT shouldn't depend on CONFIG_PCI.
>>>> drivers/pci/endpoint/*.o objects, otherwise the built-in pci-cadence-ep
>>>> driver would be probed before the PCI endpoint framework would have been
>>>> initialized, which results in a kernel crash.
>>>
>>> Nice :( - isn't there a way to improve this (ie probe deferral or
>>> registering the EPF bus earlier) ?
>>>
>>>> I guess this is the reason why the "pci/dwc" line was also put in
>>>> drivers/Makefile, right after the "pci/endpoint" line.
>>>
>>> Or probably the other way around - see commit 5e8cb4033807
>>>
>>> @Kishon, thoughts ?
>>
>> Lorenzo, ordering Makefile is one way to initialize EP core before
>
> Makefile ordering is fragile, I do not like relying on it.
>
>> other drivers. the other way is to have PCI EP core have a different
>> initcall level.. subsys_initcall??
>
> Yes, registering the bus at eg postcore_initcall() as PCI does should do
> (if that's the problem this is solving) but still, the code must not
> crash if the ordering is not correct, we have to fix this regardless.
>
> I would appreciate if Cyrille can debug the cause of the kernel crash
> so that we can fix it in the longer term.
>
I had the crash kernel few weeks ago hence I have to test again to confirm
but if I remember correctly it was a NULL pointer dereferencing crash:
cdns_pcie_ep_probe()
|
+--> devm_pci_epc_create()
|
+--> __devm_pci_ep_create()
|
+--> __pci_epc_create()
|
+--> pci_ep_cfs_add_epc_group()
|
| /*
| * Here controllers_group is still NULL because
| * pci_ep_cfs_init() has not been called yet.
| */
+--> configfs_register_group(controllers_group, ...)
|
+--> link_group()
/* Dereferencing NULL pointer */
Best regards,
Cyrille
> Thanks,
> Lorenzo
>
--
Cyrille Pitchen, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH V2 8/9] PCI: tegra: Broadcast PME_turn_Off message before link goes to L2
From: Manikanta Maddireddy @ 2017-11-30 18:43 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: thierry.reding, jonathanh, robh+dt, frowand.list, bhelgaas, rjw,
tglx, vidyas, kthota, linux-tegra, devicetree, linux-pci,
linux-pm
In-Reply-To: <20171129165147.GB6469@bhelgaas-glaptop.roam.corp.google.com>
On 29-Nov-17 10:21 PM, Bjorn Helgaas wrote:
> On Sun, Nov 26, 2017 at 01:02:12AM +0530, Manikanta Maddireddy wrote:
>> Per PCIe r3.0, sec 5.3.3.2.1, PCIe root port shoould broadcast PME_turn_Off
>> message before PCIe link goes to L2. PME_turn_Off broadcast mechanism is
>> implemented in AFI module. Each Tegra PCIe root port has its own
>> PME_turn_Off and PME_TO_Ack bitmap in AFI_PME register, program this
>> register to broadcast PME_turn_Off message.
>
> s/PME_turn_Off/PME_Turn_Off/ above to match spec.
>
> I thought PME_TO_Ack was also mis-capitalized, but it's not. Guess
> that "TO" stands for "Turn Off".
>
>> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
>> ---
>> V2:
>> * no change in this patch
>>
>> drivers/pci/host/pci-tegra.c | 76 ++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 76 insertions(+)
>>
>> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
>> index bbc2807bcd4a..b380958a3deb 100644
>> --- a/drivers/pci/host/pci-tegra.c
>> +++ b/drivers/pci/host/pci-tegra.c
>> @@ -155,6 +155,8 @@
>> #define AFI_INTR_EN_FPCI_TIMEOUT (1 << 7)
>> #define AFI_INTR_EN_PRSNT_SENSE (1 << 8)
>>
>> +#define AFI_PCIE_PME 0xf0
>> +
>> #define AFI_PCIE_CONFIG 0x0f8
>> #define AFI_PCIE_CONFIG_PCIE_DISABLE(x) (1 << ((x) + 1))
>> #define AFI_PCIE_CONFIG_PCIE_DISABLE_ALL 0xe
>> @@ -315,6 +317,7 @@
>> #define PADS_REFCLK_CFG_DRVI_SHIFT 12 /* 15:12 */
>>
>> #define LINK_RETRAIN_TIMEOUT 100000
>> +#define PME_ACK_TIMEOUT 10000
>>
>> struct tegra_msi {
>> struct msi_controller chip;
>> @@ -1503,6 +1506,76 @@ static int tegra_pcie_put_resources(struct tegra_pcie *pcie)
>> return 0;
>> }
>>
>> +static inline u32 get_pme_turnoff_bitmap(struct tegra_pcie_port *port)
>> +{
>> + struct device *dev = port->pcie->dev;
>> + struct device_node *np = dev->of_node;
>> + int ret = 0;
>
> Unnecessary initialization. In fact, the variable is unnecessary; you
> can just return the value directly as soon as you know it.
>
I can get rid of this function with Mikko's suggestion to use soc data
>> +
>> + switch (port->index) {
>> + case 0:
>> + ret = 0;
>> + case 1:
>> + ret = 8;
>> + case 2:
>> + if (of_device_is_compatible(np, "nvidia,tegra30-pcie"))
>> + ret = 16;
>> + else
>> + ret = 12;
>> + }
>> + return ret;
>> +}
>> +
>> +static inline u32 get_pme_ack_bitmap(struct tegra_pcie_port *port)
>> +{
>> + struct device *dev = port->pcie->dev;
>> + struct device_node *np = dev->of_node;
>> + int ret = 0;
>
> Similar.
>
Similar
>> +
>> + switch (port->index) {
>> + case 0:
>> + ret = 5;
>> + case 1:
>> + ret = 10;
>> + case 2:
>> + if (of_device_is_compatible(np, "nvidia,tegra30-pcie"))
>> + ret = 18;
>> + else
>> + ret = 14;
>> + }
>> + return ret;
>> +}
>> +
>> +static void tegra_pcie_pme_turnoff(struct tegra_pcie_port *port)
>> +{
>> + struct tegra_pcie *pcie = port->pcie;
>> + ktime_t deadline;
>> + unsigned int data;
>> +
>> + data = afi_readl(pcie, AFI_PCIE_PME);
>> + data |= (0x1 << get_pme_turnoff_bitmap(port));
>> + afi_writel(pcie, data, AFI_PCIE_PME);
>> +
>> + deadline = ktime_add_us(ktime_get(), PME_ACK_TIMEOUT);
>> + do {
>> + data = afi_readl(pcie, AFI_PCIE_PME);
>> + data &= (0x1 << get_pme_ack_bitmap(port));
>> + udelay(1);
>> + if (ktime_after(ktime_get(), deadline))
>> + break;
>> + } while (!data);
>> +
>> + if (data)
>> + dev_err(pcie->dev, "PME Ack is not receieved on port: %d\n",
>
> s/receieved/received/
>
>> + port->index);
>> +
>> + usleep_range(10000, 11000);
>> +
>> + data = afi_readl(pcie, AFI_PCIE_PME);
>> + data &= ~(0x1 << get_pme_turnoff_bitmap(port));
>> + afi_writel(pcie, data, AFI_PCIE_PME);
>> +}
>> +
>> static int tegra_msi_alloc(struct tegra_msi *chip)
>> {
>> int msi;
>> @@ -2828,6 +2901,7 @@ static int tegra_pcie_remove(struct platform_device *pdev)
>> {
>> struct tegra_pcie *pcie = platform_get_drvdata(pdev);
>> struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
>> + struct tegra_pcie_port *port, *tmp;
>>
>> if (IS_ENABLED(CONFIG_DEBUG_FS))
>> tegra_pcie_debugfs_exit(pcie);
>> @@ -2835,6 +2909,8 @@ static int tegra_pcie_remove(struct platform_device *pdev)
>> pci_remove_root_bus(host->bus);
>> if (IS_ENABLED(CONFIG_PCI_MSI))
>> tegra_pcie_disable_msi(pcie);
>> + list_for_each_entry_safe(port, tmp, &pcie->ports, list)
>> + tegra_pcie_pme_turnoff(port);
>> tegra_pcie_disable_ports(pcie);
>> tegra_pcie_free_resources(pcie);
>> tegra_pcie_disable_controller(pcie);
>> --
>> 2.1.4
>>
^ permalink raw reply
* Re: [PATCH V2 5/9] PCI: Export pci_flags
From: Bjorn Helgaas @ 2017-11-30 18:42 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Manikanta Maddireddy, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, rjw-LthD3rsA81gm4RdzfppkhA,
tglx-hfZtesqFncYOwBW4kG4KsQ, vidyas-DDmLM1+adcrQT0dZR+AlfA,
kthota-DDmLM1+adcrQT0dZR+AlfA, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171130102436.GB10349@red-moon>
On Thu, Nov 30, 2017 at 10:24:37AM +0000, Lorenzo Pieralisi wrote:
> On Wed, Nov 29, 2017 at 11:01:33AM -0600, Bjorn Helgaas wrote:
> > [+cc Lorenzo]
> >
> > On Sun, Nov 26, 2017 at 01:02:09AM +0530, Manikanta Maddireddy wrote:
> > > pci_flags variable is used in inline functions in 'pci.h', Tegra PCIe
> > > driver use one of these functions pci_add_flags() and includes 'pci.h'.
> > > Export pci_flags to allow Tegra PCIe host controller driver to be
> > > compiled as loadable kernel module.
> >
> > Here's the usage in tegra_pcie_probe():
> >
> > pci_add_flags(PCI_REASSIGN_ALL_RSRC | PCI_REASSIGN_ALL_BUS);
> >
> > We've probably had this discussion before, but I don't know why Tegra
> > needs PCI_REASSIGN_ALL_RSRC and PCI_REASSIGN_ALL_BUS.
> >
> > I would prefer to drop this usage of pci_add_flags() if possible. It
> > seems to be just an arm/powerpc thing and I'm not convinced it's
> > really necessary.
>
> It is hard to say if it is really necessary (because it depends
> on firmware configuration - ie pci_scan_bridge()), that's the
> problem.
>
> I suspect it can trigger regressions if we do not set it (since
> it affects what pcibios_assign_all_busses() returns on eg arm/arm64).
>
> There are two things we can do:
>
> 1) Set it unconditionally in arch code (in a hook to be defined)
> 2) We remove it on a per-host bridge basis and ask for testing
>
> I agree this may have trickled from host bridge to host bridge through
> copy'n'paste and it is not based on any firmware assumtpion but I can't
> say if it is really needed.
My basic position is that if resources are not assigned correctly, the
PCI core should automatically try to assign them, regardless of
whether PCI_REASSIGN_ALL_RSRC or PCI_REASSIGN_ALL_BUS is set. If that
doesn't work, I think there's something wrongin the PCI core and we
should fix that.
This might be an opportunity to try removing the use of
pci_add_flags() and see what breaks.
Bjorn
^ permalink raw reply
* [PATCH RFC 2/2] arm64: allwinner: a64: Add Brava Keller initial support
From: Jagan Teki @ 2017-11-30 18:42 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Icenowy Zheng, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Michael Trimarchi,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Janoff,
Stuart Westerman, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Jagan Teki
In-Reply-To: <1512067334-12761-1-git-send-email-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Brava Keller is A64 based IoT device, which support
- Allwinner A64 Cortex-A53
- AXP803 PMIC
- 1GB DDR3 RAM
- 8GB eMMC
- Mali-400MP2 GPU
- AP6330 Wifi/BLE
- Camera OV5640
- USB Host and OTG
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
Note: Need to test it on hardware
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../boot/dts/allwinner/sun50i-a64-brava-keller.dts | 244 +++++++++++++++++++++
2 files changed, 245 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index f505227..af80ca0 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-brava-keller.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
new file mode 100644
index 0000000..f5303a3
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
@@ -0,0 +1,244 @@
+/*
+ * Copyright (C) 2017 Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ model = "Brava Keller";
+ compatible = "brava,brava-keller", "allwinner,sun50i-a64";
+
+ aliases {
+ serial2 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ reset-gpios = <&pio 0 2 GPIO_ACTIVE_LOW>; /* WL-PMU-EN: PL2 */
+ post-power-on-delay-ms = <200>;
+ };
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <®_dcdc1>;
+ vqmmc-supply = <®_dldo4>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+
+ brcmf: wifi@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&r_pio>;
+ interrupts = <0 7 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
+ interrupt-names = "host-wake";
+ };
+};
+
+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins>;
+ vmmc-supply = <®_dcdc1>;
+ bus-width = <8>;
+ non-removable;
+ cap-mmc-hw-reset;
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&r_rsb {
+ status = "okay";
+
+ axp803: pmic@3a3 {
+ compatible = "x-powers,axp803";
+ reg = <0x3a3>;
+ interrupt-parent = <&r_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
+#include "axp803.dtsi"
+
+®_aldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "avdd-csi";
+};
+
+®_aldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc-pl";
+};
+
+®_aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "vcc-pll-avcc";
+};
+
+®_dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-3v3";
+};
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1040000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+®_dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-name = "vcc-dram";
+};
+
+®_dcdc6 {
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "vdd-sys";
+};
+
+®_dldo1 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-hdmi-dsi-sensor";
+};
+
+®_dldo2 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-mipi";
+};
+
+®_dldo3 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-name = "vcc-gen";
+};
+
+®_dldo4 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-wifi-io";
+};
+
+®_eldo1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "cpvdd";
+};
+
+®_fldo1 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vcc-1v2-hsic";
+};
+
+/*
+ * The A64 chip cannot work without this regulator off, although
+ * it seems to be only driving the AR100 core.
+ * Maybe we don't still know well about CPUs domain.
+ */
+®_fldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "vdd-cpus";
+};
+
+®_rtc_ldo {
+ regulator-name = "vcc-rtc";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+ status = "okay";
+};
+
+&usbphy {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 1/2] dt-bindings: Add vendor prefix for Brava Home
From: Jagan Teki @ 2017-11-30 18:42 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Icenowy Zheng, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Michael Trimarchi,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Janoff,
Stuart Westerman, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Jagan Teki
Added 'brava' as a vendor prefix for Brava Home, Inc.
which is consumer electronics and IoT company.
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 9bce76f..6004c3f 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -54,6 +54,7 @@ bhf Beckhoff Automation GmbH & Co. KG
boe BOE Technology Group Co., Ltd.
bosch Bosch Sensortec GmbH
boundary Boundary Devices Inc.
+brava Brava Home, Inc.
brcm Broadcom Corporation
buffalo Buffalo, Inc.
calxeda Calxeda
--
2.7.4
^ permalink raw reply related
* Re: [PATCH V2 7/9] PCI: tegra: Add loadable kernel module support
From: Manikanta Maddireddy @ 2017-11-30 18:39 UTC (permalink / raw)
To: Mikko Perttunen
Cc: thierry.reding, jonathanh, robh+dt, frowand.list, bhelgaas, rjw,
tglx, vidyas, kthota, linux-tegra, devicetree, linux-pci,
linux-pm
In-Reply-To: <e49cb27d-6803-2ca5-6ee6-2bb862968451@kapsi.fi>
On 29-Nov-17 5:31 PM, Mikko Perttunen wrote:
> On 25.11.2017 21:32, Manikanta Maddireddy wrote:
>> Implement remove callback function for Tegra PCIe driver to add
>> loadable kernel module support. Change PCI_TEGRA config to tristate to
>> allow pci-tegra driver to be build as a module.
>>
>> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
>> ---
>> V2:
>> * no change in this patch
>>
>> drivers/pci/host/Kconfig | 2 +-
>> drivers/pci/host/pci-tegra.c | 31 ++++++++++++++++++++++++++++++-
>> 2 files changed, 31 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index 38d12980db0f..6fd2a5937804 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -34,7 +34,7 @@ config PCI_FTPCI100
>> default ARCH_GEMINI
>>
>> config PCI_TEGRA
>> - bool "NVIDIA Tegra PCIe controller"
>> + tristate "NVIDIA Tegra PCIe controller"
>> depends on ARCH_TEGRA
>> help
>> Say Y here if you want support for the PCIe host controller found
>> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
>> index 7f7b8c9c1e84..bbc2807bcd4a 100644
>> --- a/drivers/pci/host/pci-tegra.c
>> +++ b/drivers/pci/host/pci-tegra.c
>> @@ -35,6 +35,7 @@
>> #include <linux/irqdomain.h>
>> #include <linux/kernel.h>
>> #include <linux/init.h>
>> +#include <linux/module.h>
>> #include <linux/msi.h>
>> #include <linux/of_address.h>
>> #include <linux/of_pci.h>
>> @@ -2720,6 +2721,12 @@ static int tegra_pcie_debugfs_init(struct tegra_pcie *pcie)
>> return -ENOMEM;
>> }
>>
>> +static void tegra_pcie_debugfs_exit(struct tegra_pcie *pcie)
>> +{
>> + debugfs_remove_recursive(pcie->debugfs);
>> + pcie->debugfs = NULL;
>> +}
>> +
>
> I think it's unnecessary to have a helper function for this - just inline it in the remove function.
This helper function can be used in tegra_pcie_debugfs_init(), I will publish a new patch calling this
helper function in both tegra_pcie_debugfs_exit and remove.
>
>> static int tegra_pcie_probe(struct platform_device *pdev)
>> {
>> struct device *dev = &pdev->dev;
>> @@ -2734,6 +2741,7 @@ static int tegra_pcie_probe(struct platform_device *pdev)
>> return -ENOMEM;
>>
>> pcie = pci_host_bridge_priv(host);
>> + platform_set_drvdata(pdev, pcie);
>>
>> pcie->soc = of_device_get_match_data(dev);
>> INIT_LIST_HEAD(&pcie->buses);
>> @@ -2816,6 +2824,25 @@ static int tegra_pcie_probe(struct platform_device *pdev)
>> return err;
>> }
>>
>> +static int tegra_pcie_remove(struct platform_device *pdev)
>> +{
>> + struct tegra_pcie *pcie = platform_get_drvdata(pdev);
>> + struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
>> +
>> + if (IS_ENABLED(CONFIG_DEBUG_FS))
>> + tegra_pcie_debugfs_exit(pcie);
>> + pci_stop_root_bus(host->bus);
>> + pci_remove_root_bus(host->bus);
>> + if (IS_ENABLED(CONFIG_PCI_MSI))
>> + tegra_pcie_disable_msi(pcie);
>> + tegra_pcie_disable_ports(pcie);
>> + tegra_pcie_free_resources(pcie);
>> + tegra_pcie_disable_controller(pcie);
>> + tegra_pcie_put_resources(pcie);
>> +
>> + return 0;
>> +}
>> +
>> static struct platform_driver tegra_pcie_driver = {
>> .driver = {
>> .name = "tegra-pcie",
>> @@ -2823,5 +2850,7 @@ static struct platform_driver tegra_pcie_driver = {
>> .suppress_bind_attrs = true,
>> },
>> .probe = tegra_pcie_probe,
>> + .remove = tegra_pcie_remove,
>> };
>> -builtin_platform_driver(tegra_pcie_driver);
>> +module_platform_driver(tegra_pcie_driver);
>> +MODULE_LICENSE("GPL");
>>
^ permalink raw reply
* Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.
From: Enric Balletbo Serra @ 2017-11-30 18:34 UTC (permalink / raw)
To: Daniel Thompson
Cc: Doug Anderson, Enric Balletbo i Serra, Jingoo Han, Richard Purdie,
Jacek Anaszewski, Pavel Machek, Rob Herring, Brian Norris,
Guenter Roeck, Lee Jones, Alexandru Stan,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, LKML
In-Reply-To: <c6450f50-5c12-dc52-4340-b068c0b38c54-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi,
2017-11-30 12:27 GMT+01:00 Daniel Thompson <daniel.thompson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
>
>
> On 30/11/17 00:44, Doug Anderson wrote:
>>
>> Hi,
>>
>> On Thu, Nov 16, 2017 at 6:11 AM, Enric Balletbo i Serra
>> <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> wrote:
>>>
>>> When you want to change the brightness using a PWM signal, one thing you
>>> need to consider is how human perceive the brightness. Human perceive the
>>> brightness change non-linearly, we have better sensitivity at low
>>> luminance than high luminance, so to achieve perceived linear dimming,
>>> the
>>> brightness must be matches to the way our eyes behave. The CIE 1931
>>> lightness formula is what actually describes how we perceive light.
>>>
>>> This patch adds support to compute the brightness levels based on a
>>> static
>>> table filled with the numbers provided by the CIE 1931 algorithm, for now
>>> it only supports PWM resolutions up to 65535 (16 bits) with 1024 steps.
>>> Lower PWM resolutions are implemented using the same curve but with less
>>> steps, e.g. For a PWM resolution of 256 (8 bits) we have 37 steps.
>>
>>
>> Your patch assumes that the input to your formula (luminance, I think)
>> scales linearly with PWM duty cycle. I don't personally know this,
>> but has anyone confirmed it's common in reality, or at least is a
>> close enough approximation of reality?
>
>
> Isn't this the loop we went round for v1?
>
> We do know that its not linear, however the graphs from a couple of example
> devices didn't look too scary and nobody has proposed a better formula.
>
> At this point the linear interpolation code in patch 1 allows people with
> especially alinear devices to express suitable brightness curves.
>
> However we also know that many DT authors choose not to create good
> brightness tables for their devices... and we'd rather they used allowed the
> kernel to choose a model than to use no model at all.
>
>
> Daniel.
>
>
>
> Enric: BTW sorry I haven't replied so far. That's mostly because
> these looked more "real" and that I should pay them close
> attention (which requires time I haven't had spare to
> consume yet).
>
No problem. It also took me some time to send v2 because of was busy
with other things :)
>
>
>>> The calculation of the duty cycle using the CIE 1931 algorithm is enabled
>>> by
>>> default when you do not define the 'brightness-levels' propriety in your
>>> device tree.
>>
>>
>> One note is that you probably still want at least a "min" duty cycle.
>> I seem to remember some PWM backlights don't work well when the duty
>> cycle is too low and it would still be nice to be able to use your
>> table.
>>
Right, iirc that is needed on some veyron devices, and this is another
reason why the first patch needs to support to be able to describe
corrected gamma curves and not only linear-interpolation between 2
points. I'd say that:
1. For low and high resolution PWMs, if you know nothing about PWM
backlight, patch 2 can provide to the user a default table that should
work.
2. If you need something more specific you should use the old way
(aka, use brightness levels table)
2.1 If you have a high resolution PWM you might be interested on
enable interpolation.
>>
>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>>> ---
>>> drivers/video/backlight/pwm_bl.c | 160
>>> +++++++++++++++++++++++++++++++++++----
>>> include/linux/pwm_backlight.h | 1 +
>>> 2 files changed, 147 insertions(+), 14 deletions(-)
>>
>>
>> Something I'd like to see in a patch somewhere in this series is a way
>> to expose the backlight "units" to userspace. As far as I know right
>> now the backlight exposed to userspace is "unitless", but it would be
>> nice for userspace to query that the backlight is now linear to human
>> perception. For old code, it could always expose the unit as
>> "unknown".
>>
>>
>>> diff --git a/drivers/video/backlight/pwm_bl.c
>>> b/drivers/video/backlight/pwm_bl.c
>>> index 59b1bfb..ea96358 100644
>>> --- a/drivers/video/backlight/pwm_bl.c
>>> +++ b/drivers/video/backlight/pwm_bl.c
>>> @@ -26,6 +26,112 @@
>>>
>>> #define NSTEPS 256
>>>
>>> +/*
>>> + * CIE lightness to PWM conversion table. The CIE 1931 lightness formula
>>> is what
>>> + * actually describes how we perceive light:
>>> + *
>>> + * Y = (L* / 902.3) if L* ≤ 0.08856
>>> + * Y = ((L* + 16) / 116)^3 if L* > 0.08856
>>> + *
>>> + * Where Y is the luminance (output) between 0.0 and 1.0, and L* is the
>>> + * lightness (input) between 0 and 100.
>>
>>
>> Just because I'm stupid and not 100% sure, I think:
>>
Just because I'm also stupid and I'm still learning :) I'll try to
clarify a bit more that ...
>> luminance = the amount of light coming out of the screen
>> lightness = how bright a human perceives the screen to be
>>
>> Is that right? If so could you add it to the comments? So "output"
>> here is the output to the PWM and "input" is the input from userspace
>> (and thus should be expressed in terms of human perception).
>>
Yes, I think that how you describe luminance and lightness is right,
and sounds good improve the doc.
To be clear the correction table for PWM values can be calculated with
this code.
OUTPUT_SIZE = 65535 # Output integer size
INPUT_SIZE = 2047
def cie1931(L):
L = L*100.0
if L <= 8:
return (L/902.3)
else:
return ((L+16.0)/116.0)**3
x = range(0,int(INPUT_SIZE+1))
y = [int(round(cie1931(float(L)/INPUT_SIZE)*(OUTPUT_SIZE))) for L in x]
>>
>>> + 0, 7, 14, 21, 28, 35, 43, 50, 57, 64, 71, 78, 85, 92, 99, 106,
>>> 114, 121,
>>
>>
>> Seems like you could save space (and nicely use the previous patch) by
>> using the linear interpolation code from the previous patch, since
>>
>> 0 + 7 = 7
>> + 7 = 14
>> + 7 = 21
>> + 7 = 28
>> + 7 = 35
>>
>> ...and it would likely be OK to keep going and be slight off, so:
>>
>> + 7 = 42
>> + 7 = 49
>> + 7 = 56
>> + 7 = 63
>> + 7 = 70
>> ...
>> ...
>>
>> In other words it seems like you're just providing a default table...
>>
Yes, I think that's the Daniel idea ;)
>> -Doug
>>
>
Best regards,
- Enric
--
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/5] PCI: Add support to the Cadence PCIe controller
From: Lorenzo Pieralisi @ 2017-11-30 18:18 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Cyrille Pitchen, bhelgaas, linux-pci, adouglas, stelford, dgary,
kgopi, eandrews, thomas.petazzoni, sureshp, nsekhar, linux-kernel,
robh, devicetree
In-Reply-To: <8c6c50fc-47a9-7b93-d826-1dba9c4d09c2@ti.com>
On Thu, Nov 30, 2017 at 12:43:20PM +0530, Kishon Vijay Abraham I wrote:
[...]
> >> For linux-next, I applied this series on top of Kishon's patch
> >> ("PCI: endpoint: Use EPC's device in dma_alloc_coherent/dma_free_coherent")
> >> otherwise dma_alloc_coherent() fails when called by pci_epf_alloc_space().
> >>
> >> Also, I patched drivers/Makefile rather than drivers/pci/Makefile to make
> >> the drivers/pci/cadence/pcie-cadence-ep.o linked after
>
> The reason to patch drivers/Makefile should be because pcie-cadence-ep has to
> be compiled even when CONFIG_PCI is not enabled. CONFIG_PCI enables host
> specific features and ENDPOINT shouldn't depend on CONFIG_PCI.
> >> drivers/pci/endpoint/*.o objects, otherwise the built-in pci-cadence-ep
> >> driver would be probed before the PCI endpoint framework would have been
> >> initialized, which results in a kernel crash.
> >
> > Nice :( - isn't there a way to improve this (ie probe deferral or
> > registering the EPF bus earlier) ?
> >
> >> I guess this is the reason why the "pci/dwc" line was also put in
> >> drivers/Makefile, right after the "pci/endpoint" line.
> >
> > Or probably the other way around - see commit 5e8cb4033807
> >
> > @Kishon, thoughts ?
>
> Lorenzo, ordering Makefile is one way to initialize EP core before
Makefile ordering is fragile, I do not like relying on it.
> other drivers. the other way is to have PCI EP core have a different
> initcall level.. subsys_initcall??
Yes, registering the bus at eg postcore_initcall() as PCI does should do
(if that's the problem this is solving) but still, the code must not
crash if the ordering is not correct, we have to fix this regardless.
I would appreciate if Cyrille can debug the cause of the kernel crash
so that we can fix it in the longer term.
Thanks,
Lorenzo
^ permalink raw reply
* Re: [PATCH 2/3] net: socionext: Add Synquacer NetSec driver
From: David Miller @ 2017-11-30 18:14 UTC (permalink / raw)
To: ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A
Cc: dan.j.williams-ral2JQCrhuEAvxtiuMwx3w, will.deacon-5wv7dgnIgG8,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
arnd.bergmann-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <CAKv+Gu9qpLWTjjCZBvyn87HoNNY+U5++2UeHxF8jXYQPDd3U1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Date: Thu, 30 Nov 2017 18:08:34 +0000
> But the whole point of memremap() is obtaining a virtual mapping
> that does not require accessors, but can be used like ordinary
> memory.
That's unfortunately not what it's doing.
It's relying on the fact that some architectures (I guess x86
and arm) do happen to give a virutal address from ioremap_wt()
even though it's return type is annotated __iomem.
Thanks in advance for changing your driver to use ioremap() and
accessors for now.
--
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
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