* Re: [PATCH v8 08/24] ASoC: qdsp6: q6core: Add q6core driver
From: Banajit Goswami @ 2018-05-15 7:44 UTC (permalink / raw)
To: Srinivas Kandagatla, andy.gross, broonie, linux-arm-msm,
alsa-devel, robh+dt
Cc: mark.rutland, devicetree, rohkumar, gregkh, plai, tiwai,
lgirdwood, david.brown, linux-arm-kernel, spatakok, linux-kernel
In-Reply-To: <20180509125635.5653-9-srinivas.kandagatla@linaro.org>
On 5/9/2018 5:56 AM, Srinivas Kandagatla wrote:
> This patch adds support to core apr service, which is used to query
> status of other static and dynamic services on the dsp.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-and-tested-by: Rohit kumar <rohitkr@codeaurora.org>
> ---
> sound/soc/qcom/Kconfig | 4 +
> sound/soc/qcom/qdsp6/Makefile | 1 +
> sound/soc/qcom/qdsp6/q6core.c | 380 ++++++++++++++++++++++++++++++++++++++++++
> sound/soc/qcom/qdsp6/q6core.h | 15 ++
> 4 files changed, 400 insertions(+)
> create mode 100644 sound/soc/qcom/qdsp6/q6core.c
> create mode 100644 sound/soc/qcom/qdsp6/q6core.h
Acked-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v6] gpio: dwapb: Add support for 1 interrupt per port A GPIO
From: Simon Horman @ 2018-05-15 7:42 UTC (permalink / raw)
To: Phil Edworthy
Cc: Andy Shevchenko, Hoan Tran, Linus Walleij, Mark Rutland,
Rob Herring, Lee Jones, Michel Pollet, linux-gpio, devicetree,
linux-renesas-soc, linux-kernel
In-Reply-To: <1526027497-32556-1-git-send-email-phil.edworthy@renesas.com>
On Fri, May 11, 2018 at 09:31:37AM +0100, Phil Edworthy wrote:
> The DesignWare GPIO IP can be configured for either 1 interrupt or 1
> per GPIO in port A, but the driver currently only supports 1 interrupt.
> See the DesignWare DW_apb_gpio Databook description of the
> 'GPIO_INTR_IO' parameter.
>
> This change allows the driver to work with up to 32 interrupts, it will
> get as many interrupts as specified in the DT 'interrupts' property.
> It doesn't do anything clever with the different interrupts, it just calls
> the same handler used for single interrupt hardware.
>
> Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
> One point to mention is that I have made it possible for users to have
> unconnected interrupts by specifying holes in the list of interrupts. This is
> done by supporting the interrupts-extended DT prop.
> However, I have no use for this and had to hack some test case for this.
> Perhaps the driver should support 1 interrupt or all GPIOa as interrupts?
>
> v6:
> - Treat DT and ACPI the same as much as possible. Note that we can't use
> platform_get_irq() to get the DT interrupts as they are in the port
> sub-node and hence do not have an associated platform device.
> v5:
> - Rolled ACPI companion code provided by Hoan Tran into this patch.
> v4:
> - Use of_irq_get() instead of of_irq_parse_one()+irq_create_of_mapping()
> v3:
> - Rolled mfd: intel_quark_i2c_gpio fix into this patch to avoid bisect problems
> v2:
> - Replaced interrupt-mask DT prop with support for the interrupts-extended
> prop. This means replacing the call to irq_of_parse_and_map() with calls
> to of_irq_parse_one() and irq_create_of_mapping().
> ---
> .../devicetree/bindings/gpio/snps-dwapb-gpio.txt | 9 +++-
> drivers/gpio/gpio-dwapb.c | 49 +++++++++++++++-------
> drivers/mfd/intel_quark_i2c_gpio.c | 3 +-
> include/linux/platform_data/gpio-dwapb.h | 3 +-
> 4 files changed, 45 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
> index 4a75da7..3c1118b 100644
> --- a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
> @@ -26,8 +26,13 @@ controller.
> the second encodes the triger flags encoded as described in
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> - interrupt-parent : The parent interrupt controller.
> -- interrupts : The interrupt to the parent controller raised when GPIOs
> - generate the interrupts.
> +- interrupts : The interrupts to the parent controller raised when GPIOs
> + generate the interrupts. If the controller provides one combined interrupt
> + for all GPIOs, specify a single interrupt. If the controller provides one
> + interrupt for each GPIO, provide a list of interrupts that correspond to each
> + of the GPIO pins. When specifying multiple interrupts, if any are unconnected,
> + use the interrupts-extended property to specify the interrupts and set the
> + interrupt controller handle for unused interrupts to 0.
> - snps,nr-gpios : The number of pins in the port, a single cell.
> - resets : Reset line for the controller.
An enhanced example might be helpful.
That not withstanding:
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: imx6/7: Remove unit-address from anatop regulators
From: Shawn Guo @ 2018-05-15 7:40 UTC (permalink / raw)
To: Fabio Estevam; +Cc: Fabio Estevam, devicetree, robh+dt, linux-arm-kernel
In-Reply-To: <1526304714-23821-1-git-send-email-festevam@gmail.com>
On Mon, May 14, 2018 at 10:31:54AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Remove unit-address and reg property from anatop regulators to fix
> the following DTC warnings with W=1:
>
> arch/arm/boot/dts/imx6dl-apf6dev.dtb: Warning (unique_unit_address): /soc/aips-bus@2000000/anatop@20c8000/regulator-vddcore@20c8140: duplicate unit-address (also used in node /soc/aips-bus@2000000/anatop@20c8000/regulator-vddpu@20c8140)
> arch/arm/boot/dts/imx6dl-apf6dev.dtb: Warning (unique_unit_address): /soc/aips-bus@2000000/anatop@20c8000/regulator-vddcore@20c8140: duplicate unit-address (also used in node /soc/aips-bus@2000000/anatop@20c8000/regulator-vddsoc@20c8140)
> arch/arm/boot/dts/imx6dl-apf6dev.dtb: Warning (unique_unit_address): /soc/aips-bus@2000000/anatop@20c8000/regulator-vddpu@20c8140: duplicate unit-address (also used in node /soc/aips-bus@2000000/anatop@20c8000/regulator-vddsoc@20c8140)
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Changes since v1:
> - Send it is a standalone patch instead of a patch series.
>
> arch/arm/boot/dts/imx6qdl.dtsi | 20 ++++++--------------
> arch/arm/boot/dts/imx6sl.dtsi | 20 ++++++--------------
> arch/arm/boot/dts/imx6sx.dtsi | 20 ++++++--------------
> arch/arm/boot/dts/imx6ul.dtsi | 11 +++--------
I'm a bit confused. It looks that the change is just to revert commit
685e1321ba74 ("ARM: dts: imx6: Add unit address and reg for the anatop
nodes"). But what about the simple_bus_reg warning the commit was
fixing?
Shawn
> arch/arm/boot/dts/imx7s.dtsi | 8 ++------
> 5 files changed, 23 insertions(+), 56 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index 69648e2..22942dd 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -692,11 +692,8 @@
> interrupts = <0 49 IRQ_TYPE_LEVEL_HIGH>,
> <0 54 IRQ_TYPE_LEVEL_HIGH>,
> <0 127 IRQ_TYPE_LEVEL_HIGH>;
> - #address-cells = <1>;
> - #size-cells = <0>;
>
> - regulator-1p1@20c8110 {
> - reg = <0x20c8110>;
> + regulator-1p1 {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vdd1p1";
> regulator-min-microvolt = <1000000>;
> @@ -711,8 +708,7 @@
> anatop-enable-bit = <0>;
> };
>
> - regulator-3p0@20c8120 {
> - reg = <0x20c8120>;
> + regulator-3p0 {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vdd3p0";
> regulator-min-microvolt = <2800000>;
> @@ -727,8 +723,7 @@
> anatop-enable-bit = <0>;
> };
>
> - regulator-2p5@20c8130 {
> - reg = <0x20c8130>;
> + regulator-2p5 {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vdd2p5";
> regulator-min-microvolt = <2250000>;
> @@ -743,8 +738,7 @@
> anatop-enable-bit = <0>;
> };
>
> - reg_arm: regulator-vddcore@20c8140 {
> - reg = <0x20c8140>;
> + reg_arm: regulator-vddcore {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vddarm";
> regulator-min-microvolt = <725000>;
> @@ -761,8 +755,7 @@
> anatop-max-voltage = <1450000>;
> };
>
> - reg_pu: regulator-vddpu@20c8140 {
> - reg = <0x20c8140>;
> + reg_pu: regulator-vddpu {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vddpu";
> regulator-min-microvolt = <725000>;
> @@ -779,8 +772,7 @@
> anatop-max-voltage = <1450000>;
> };
>
> - reg_soc: regulator-vddsoc@20c8140 {
> - reg = <0x20c8140>;
> + reg_soc: regulator-vddsoc {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vddsoc";
> regulator-min-microvolt = <725000>;
> diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
> index 2002db2..8c838ba 100644
> --- a/arch/arm/boot/dts/imx6sl.dtsi
> +++ b/arch/arm/boot/dts/imx6sl.dtsi
> @@ -524,11 +524,8 @@
> interrupts = <0 49 IRQ_TYPE_LEVEL_HIGH>,
> <0 54 IRQ_TYPE_LEVEL_HIGH>,
> <0 127 IRQ_TYPE_LEVEL_HIGH>;
> - #address-cells = <1>;
> - #size-cells = <0>;
>
> - regulator-1p1@20c8110 {
> - reg = <0x20c8110>;
> + regulator-1p1 {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vdd1p1";
> regulator-min-microvolt = <800000>;
> @@ -543,8 +540,7 @@
> anatop-enable-bit = <0>;
> };
>
> - regulator-3p0@20c8120 {
> - reg = <0x20c8120>;
> + regulator-3p0 {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vdd3p0";
> regulator-min-microvolt = <2800000>;
> @@ -559,8 +555,7 @@
> anatop-enable-bit = <0>;
> };
>
> - regulator-2p5@20c8130 {
> - reg = <0x20c8130>;
> + regulator-2p5 {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vdd2p5";
> regulator-min-microvolt = <2100000>;
> @@ -575,8 +570,7 @@
> anatop-enable-bit = <0>;
> };
>
> - reg_arm: regulator-vddcore@20c8140 {
> - reg = <0x20c8140>;
> + reg_arm: regulator-vddcore {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vddarm";
> regulator-min-microvolt = <725000>;
> @@ -593,8 +587,7 @@
> anatop-max-voltage = <1450000>;
> };
>
> - reg_pu: regulator-vddpu@20c8140 {
> - reg = <0x20c8140>;
> + reg_pu: regulator-vddpu {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vddpu";
> regulator-min-microvolt = <725000>;
> @@ -611,8 +604,7 @@
> anatop-max-voltage = <1450000>;
> };
>
> - reg_soc: regulator-vddsoc@20c8140 {
> - reg = <0x20c8140>;
> + reg_soc: regulator-vddsoc {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vddsoc";
> regulator-min-microvolt = <725000>;
> diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
> index 7e463d2..4a97513 100644
> --- a/arch/arm/boot/dts/imx6sx.dtsi
> +++ b/arch/arm/boot/dts/imx6sx.dtsi
> @@ -591,11 +591,8 @@
> interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
> - #address-cells = <1>;
> - #size-cells = <0>;
>
> - regulator-1p1@20c8110 {
> - reg = <0x20c8110>;
> + regulator-1p1 {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vdd1p1";
> regulator-min-microvolt = <800000>;
> @@ -610,8 +607,7 @@
> anatop-enable-bit = <0>;
> };
>
> - regulator-3p0@20c8120 {
> - reg = <0x20c8120>;
> + regulator-3p0 {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vdd3p0";
> regulator-min-microvolt = <2800000>;
> @@ -626,8 +622,7 @@
> anatop-enable-bit = <0>;
> };
>
> - regulator-2p5@20c8130 {
> - reg = <0x20c8130>;
> + regulator-2p5 {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vdd2p5";
> regulator-min-microvolt = <2100000>;
> @@ -642,8 +637,7 @@
> anatop-enable-bit = <0>;
> };
>
> - reg_arm: regulator-vddcore@20c8140 {
> - reg = <0x20c8140>;
> + reg_arm: regulator-vddcore {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vddarm";
> regulator-min-microvolt = <725000>;
> @@ -660,8 +654,7 @@
> anatop-max-voltage = <1450000>;
> };
>
> - reg_pcie: regulator-vddpcie@20c8140 {
> - reg = <0x20c8140>;
> + reg_pcie: regulator-vddpcie {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vddpcie";
> regulator-min-microvolt = <725000>;
> @@ -677,8 +670,7 @@
> anatop-max-voltage = <1450000>;
> };
>
> - reg_soc: regulator-vddsoc@20c8140 {
> - reg = <0x20c8140>;
> + reg_soc: regulator-vddsoc {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vddsoc";
> regulator-min-microvolt = <725000>;
> diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
> index 2b854d1..1818b6c 100644
> --- a/arch/arm/boot/dts/imx6ul.dtsi
> +++ b/arch/arm/boot/dts/imx6ul.dtsi
> @@ -551,11 +551,8 @@
> interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
> - #address-cells = <1>;
> - #size-cells = <0>;
>
> - reg_3p0: regulator-3p0@20c8110 {
> - reg = <0x20c8110>;
> + reg_3p0: regulator-3p0 {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vdd3p0";
> regulator-min-microvolt = <2625000>;
> @@ -569,8 +566,7 @@
> anatop-enable-bit = <0>;
> };
>
> - reg_arm: regulator-vddcore@20c8140 {
> - reg = <0x20c8140>;
> + reg_arm: regulator-vddcore {
> compatible = "fsl,anatop-regulator";
> regulator-name = "cpu";
> regulator-min-microvolt = <725000>;
> @@ -587,8 +583,7 @@
> anatop-max-voltage = <1450000>;
> };
>
> - reg_soc: regulator-vddsoc@20c8140 {
> - reg = <0x20c8140>;
> + reg_soc: regulator-vddsoc {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vddsoc";
> regulator-min-microvolt = <725000>;
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index b416d2b..99f92ec 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -557,11 +557,8 @@
> reg = <0x30360000 0x10000>;
> interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
> - #address-cells = <1>;
> - #size-cells = <0>;
>
> - reg_1p0d: regulator-vdd1p0d@30360210 {
> - reg = <0x30360210>;
> + reg_1p0d: regulator-vdd1p0d {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vdd1p0d";
> regulator-min-microvolt = <800000>;
> @@ -575,8 +572,7 @@
> anatop-enable-bit = <0>;
> };
>
> - reg_1p2: regulator-vdd1p2@30360220 {
> - reg = <0x30360220>;
> + reg_1p2: regulator-vdd1p2 {
> compatible = "fsl,anatop-regulator";
> regulator-name = "vdd1p2";
> regulator-min-microvolt = <1100000>;
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v2 2/2] drm/bridge: sii902x: add optional power supplies
From: Laurent Pinchart @ 2018-05-15 7:36 UTC (permalink / raw)
To: Philippe CORNU
Cc: Mark Rutland, devicetree@vger.kernel.org, Alexandre TORGUE,
David Airlie, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, Yannick FERTRE, Rob Herring
In-Reply-To: <8ed2cfcd-df26-fa9c-c45d-7bf4020f0faa@st.com>
Hi Philippe,
On Monday, 14 May 2018 21:58:48 EEST Philippe CORNU wrote:
> On 05/14/2018 12:33 PM, Andrzej Hajda wrote:
> > On 14.05.2018 11:38, Philippe CORNU wrote:
> >> On 04/25/2018 09:53 AM, Philippe Cornu wrote:
> >>> Add the optional power supplies using the description found in
> >>> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
> >>>
> >>> The sii902x input IOs are not "io safe" so it is important to
> >>> enable/disable voltage regulators during probe/remove phases to
> >>> avoid damages.
> >
> > What exactly does it mean? Ie I understand that the chip has some
> > limitations, but why enabling/disabling regulators in probe/remove
> > should solve it?
>
> thank you for your comment.
>
> And sorry for the "bad" explanation in the 2nd paragraph about the fact
> that inputs are not "io safe". I added this 2nd paragraph in v2
> following a good comment from Laurent on adding the management of the
> regulators outside the probe/remove for a better power consumption
> management (enable/disable regulators only when the ic is used for
> displaying something for instance...). But after a deeper analysis, I
> realized that the only way to improve the power consumption is to
> implement & test the sii902x various sleep modes, that is out-of-scope
> of this small patch and also out-of-scope of my test board I use on
> which the sii902x bridge ic power consumption is very low compare to the
> rest of the system...
>
> I will remove this "explanation" in v3 as it creates confusion.
I'd rather keep it and expand it explain why enabling/disabling regulators at
probe/remove solves the problem. Your patch otherwise looks OK (although if
you submit a v3 anyway you could also rename err_disable_regulator to
err_disable_regulators).
> >>> Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
> >>> ---
> >>>
> >>> drivers/gpu/drm/bridge/sii902x.c | 38 ++++++++++++++++++++++++++++++----
> >>> 1 file changed, 34 insertions(+), 4 deletions(-)
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/2] USB: dwc3: get extcon device by OF graph bindings
From: Krzysztof Kozlowski @ 2018-05-15 7:31 UTC (permalink / raw)
To: Felipe Balbi
Cc: Andrzej Hajda, open list:DESIGNWARE USB3 DRD IP DRIVER,
Bartlomiej Zolnierkiewicz, Marek Szyprowski,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Inki Dae, Rob Herring, Mark Rutland,
Chanwoo Choi, Laurent Pinchart, linux-kernel,
linux-samsung-soc@vger.kernel.org
In-Reply-To: <878t8l9y6j.fsf@linux.intel.com>
On Tue, May 15, 2018 at 9:26 AM, Felipe Balbi <balbi@kernel.org> wrote:
> Andrzej Hajda <a.hajda@samsung.com> writes:
>
>> extcon device is used to detect host/device connection. Since extcon
>> OF property is deprecated, alternative method should be added.
>> This method uses OF graph bindings to locate extcon.
>>
>> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
>> ---
>> Hi all,
>>
>> This patch implements alternative method to get extcon from DWC3.
>> The code works but is hacky, as DWC3 must traverse different DT nodes
>> to get extcon, in case of TM2 it is USB-PHY and MUIC, but other
>> platforms can have different paths.
>> I would be glad if it can be merged as is for now, but additional work
>> must be done to make it generic.
>> I guess on DT binding side it is OK. So the problem should be addressed
>> in the code.
>> My rough idea is to implement kind of extcon aliases/forwarder mechanism,
>> ie. USB-PHY will expect on its output remote port extcon, and it should register
>> extcon-forwarder pointing to this extcon. This way DWC3 can look for the extcon
>> on its PHY phandle, and it will receive via forwarding mechanism extcon
>> exposed by MUIC.
>> As I said this is rough idea for discussion, other propositions are welcome.
>>
>> Regards
>> Andrzej
>
> I need someone from devicetree to review and ack patch2 before I can
> apply them. Either way, this doesn't apply:
The DTS patch will go through arm-soc tree, I'll take it. The DTS
patches are independent from drivers and shall not usually go through
regular trees.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] USB: dwc3: get extcon device by OF graph bindings
From: Felipe Balbi @ 2018-05-15 7:26 UTC (permalink / raw)
To: open list:DESIGNWARE USB3 DRD IP DRIVER
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Inki Dae, Rob Herring, Mark Rutland,
Krzysztof Kozlowski, Chanwoo Choi, Laurent Pinchart, linux-kernel,
linux-samsung-soc
In-Reply-To: <20180131155718.5237-2-a.hajda@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]
Andrzej Hajda <a.hajda@samsung.com> writes:
> extcon device is used to detect host/device connection. Since extcon
> OF property is deprecated, alternative method should be added.
> This method uses OF graph bindings to locate extcon.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> ---
> Hi all,
>
> This patch implements alternative method to get extcon from DWC3.
> The code works but is hacky, as DWC3 must traverse different DT nodes
> to get extcon, in case of TM2 it is USB-PHY and MUIC, but other
> platforms can have different paths.
> I would be glad if it can be merged as is for now, but additional work
> must be done to make it generic.
> I guess on DT binding side it is OK. So the problem should be addressed
> in the code.
> My rough idea is to implement kind of extcon aliases/forwarder mechanism,
> ie. USB-PHY will expect on its output remote port extcon, and it should register
> extcon-forwarder pointing to this extcon. This way DWC3 can look for the extcon
> on its PHY phandle, and it will receive via forwarding mechanism extcon
> exposed by MUIC.
> As I said this is rough idea for discussion, other propositions are welcome.
>
> Regards
> Andrzej
I need someone from devicetree to review and ack patch2 before I can
apply them. Either way, this doesn't apply:
checking file drivers/usb/dwc3/drd.c
Hunk #1 FAILED at 8.
Hunk #2 FAILED at 38.
2 out of 2 hunks FAILED
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH/RFT v3 1/3] thermal: rcar_thermal: add r8a77995 support
From: Simon Horman @ 2018-05-15 7:26 UTC (permalink / raw)
To: Yoshihiro Kaneko
Cc: Eduardo Valentin, Rob Herring, Zhang Rui, devicetree, linux-pm,
linux-renesas-soc
In-Reply-To: <CAH1o70JNjsgeb5CHPZs3UunGR6jg6_C3d+EZjWs_B0389Z2Y-A@mail.gmail.com>
On Mon, May 14, 2018 at 06:11:59AM +0900, Yoshihiro Kaneko wrote:
> Hi Simon-san,
>
> 2018年5月10日(木) 3:11 Simon Horman <horms@verge.net.au>:
>
> > On Tue, Apr 03, 2018 at 09:43:03PM +0900, Yoshihiro Kaneko wrote:
> > > Add support for R-Car D3 (r8a77995) thermal sensor.
> > >
> > > Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
> > > ---
> > > drivers/thermal/rcar_thermal.c | 154
> > ++++++++++++++++++++++++++++++++---------
> > > 1 file changed, 122 insertions(+), 32 deletions(-)
> > >
> > > diff --git a/drivers/thermal/rcar_thermal.c
> > b/drivers/thermal/rcar_thermal.c
> > > index 73e5fee..5ec47a9 100644
> > > --- a/drivers/thermal/rcar_thermal.c
> > > +++ b/drivers/thermal/rcar_thermal.c
> > > @@ -58,10 +58,43 @@ struct rcar_thermal_common {
> > > spinlock_t lock;
> > > };
> > >
> > > +struct rcar_thermal_chip {
> > > + unsigned int use_of_thermal : 1;
> > > + unsigned int has_filonoff : 1;
> > > + unsigned int irq_per_ch : 1;
> > > + unsigned int needs_suspend_resume : 1;
> > > + unsigned int nirqs;
> > > +};
> > > +
> > > +static const struct rcar_thermal_chip rcar_thermal = {
> > > + .use_of_thermal = 0,
> > > + .has_filonoff = 1,
> > > + .irq_per_ch = 0,
> > > + .needs_suspend_resume = 0,
> > > + .nirqs = 1,
> > > +};
> > > +
> > > +static const struct rcar_thermal_chip rcar_gen2_thermal = {
> > > + .use_of_thermal = 1,
> > > + .has_filonoff = 1,
> > > + .irq_per_ch = 0,
> > > + .needs_suspend_resume = 0,
> > > + .nirqs = 1,
> > > +};
> > > +
> > > +static const struct rcar_thermal_chip rcar_gen3_thermal = {
> > > + .use_of_thermal = 1,
> > > + .has_filonoff = 0,
> > > + .irq_per_ch = 1,
> > > + .needs_suspend_resume = 1,
> > > + .nirqs = 2,
> > > +};
> >
> > The binding and dts patches in this series describe 3 interrupts
> > for R-Car D3. But the above specifies two. Am I missing something obvious?
>
>
> R-Car D3 has 3 interrupts, but this driver uses only 2 interrupts to detect
> a temperature change, rise or fall.
Thanks, that makes perfect sense.
Perhaps a comment above ".nirqs = 2" would make it more obvious to the casual
observer?
^ permalink raw reply
* Re: [PATCH] usb: gadget: composite: fill bcdUSB as 0x0320 for SuperSpeed or higher speeds
From: Felipe Balbi @ 2018-05-15 7:22 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Greg Kroah-Hartman, Matthias Brugger, linux-usb, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <1525913200.32173.3.camel@mhfsdcap03>
[-- Attachment #1: Type: text/plain, Size: 723 bytes --]
Hi,
Chunfeng Yun <chunfeng.yun@mediatek.com> writes:
> On Wed, 2018-05-09 at 14:33 +0300, Felipe Balbi wrote:
>> Hi,
>>
>> Chunfeng Yun <chunfeng.yun@mediatek.com> writes:
>> > The USB3CV version 2.1.80 (March 26, 2018) requires all devices
>> > ( gen1, gen2, single lane, dual lane) to return the value of 0x0320
>> > in the bcdUSB field
>>
>> this sounds really odd. What happens when I get a USB 3.1 compliant
>> device off-the-shelf and run it through USB3CV? will it fail now?
> Yes, it will fail, the last version requires it 0x0310
>>
>> Care to share a screenshot or the raw html of the test result?
> A screenshot is attached
really odd. But I'll apply the patch.
thanks
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: document Renesas V3HSK board bindings
From: Simon Horman @ 2018-05-15 7:18 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sergei Shtylyov, Rob Herring, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Magnus Damm, Mark Rutland
In-Reply-To: <CAMuHMdV6HtW7L4HVbi=RSC-nmb4SDuNaY3-iVH0YYERBg3tToA@mail.gmail.com>
On Mon, May 14, 2018 at 10:28:34PM +0200, Geert Uytterhoeven wrote:
> On Thu, May 10, 2018 at 8:09 PM, Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com> wrote:
> > Document the V3H Starter Kit device tree bindings, listing it as
> > a supported board.
> >
> > This allows to use checkpatch.pl to validate .dts files referring to
> > the V3HSK board.
> >
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied.
^ permalink raw reply
* Re: [PATCH] media: dt-bindings: media: rcar_vin: add support for r8a77965
From: Simon Horman @ 2018-05-15 7:16 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Rob Herring, devicetree, linux-media, linux-renesas-soc
In-Reply-To: <20180513185818.15359-1-niklas.soderlund+renesas@ragnatech.se>
On Sun, May 13, 2018 at 08:58:18PM +0200, Niklas Söderlund wrote:
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH 4/4] misc: pci_endpoint_test: Add DesignWare EP entry
From: Gustavo Pimentel @ 2018-05-15 7:13 UTC (permalink / raw)
To: bhelgaas, lorenzo.pieralisi, Joao.Pinto, jingoohan1, kishon,
robh+dt, mark.rutland
Cc: linux-pci, linux-kernel, devicetree, Gustavo Pimentel
In-Reply-To: <cover.1526368368.git.gustavo.pimentel@synopsys.com>
Add the DesignWare EP device ID entry to pci_endpoint_test driver table.
Allow the device to be recognize and handle by the pci_endpoint_test
driver.
Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
---
drivers/misc/pci_endpoint_test.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index fe8897e..58a88ba 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -634,6 +634,7 @@ static void pci_endpoint_test_remove(struct pci_dev *pdev)
static const struct pci_device_id pci_endpoint_test_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x) },
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA72x) },
+ { PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS, 0xedda) },
{ }
};
MODULE_DEVICE_TABLE(pci, pci_endpoint_test_tbl);
--
2.7.4
^ permalink raw reply related
* [PATCH 3/4] bindings: PCI: designware: Add support for EP in DesignWare driver
From: Gustavo Pimentel @ 2018-05-15 7:13 UTC (permalink / raw)
To: bhelgaas, lorenzo.pieralisi, Joao.Pinto, jingoohan1, kishon,
robh+dt, mark.rutland
Cc: linux-pci, linux-kernel, devicetree, Gustavo Pimentel
In-Reply-To: <cover.1526368368.git.gustavo.pimentel@synopsys.com>
Add device tree binding documentation for the EP in PCIe DesignWare driver.
Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/pci/designware-pcie.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index 7f9804d..c124f9b 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -3,6 +3,7 @@
Required properties:
- compatible:
"snps,dw-pcie" for RC mode;
+ "snps,dw-pcie-ep" for EP mode;
- reg: Should contain the configuration address space.
- reg-names: Must be "config" for the PCIe configuration space.
(The old way of getting the configuration address space from "ranges"
@@ -56,3 +57,14 @@ Example configuration:
#interrupt-cells = <1>;
num-lanes = <1>;
};
+or
+ pcie: pcie@dfc00000 {
+ compatible = "snps,dw-pcie-ep";
+ reg = <0xdfc00000 0x0001000>, /* IP registers 1 */
+ <0xdfc01000 0x0001000>, /* IP registers 2 */
+ <0xd0000000 0x2000000>; /* Configuration space */
+ reg-names = "dbi", "dbi2", "addr_space";
+ num-ib-windows = <6>;
+ num-ob-windows = <2>;
+ num-lanes = <1>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] PCI: dwc: Add support for EP mode
From: Gustavo Pimentel @ 2018-05-15 7:13 UTC (permalink / raw)
To: bhelgaas, lorenzo.pieralisi, Joao.Pinto, jingoohan1, kishon,
robh+dt, mark.rutland
Cc: linux-pci, linux-kernel, devicetree, Gustavo Pimentel
In-Reply-To: <cover.1526368368.git.gustavo.pimentel@synopsys.com>
The PCIe controller dual mode is capable of operating in RC mode as well
as EP mode by configuration option. Till now only RC mode was supported,
with this patch is add EP support to the DesignWare driver.
Add new property on pci_epc structure which allow to configure
pci_epf_test driver accordingly to the controller specific requirements.
Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
---
drivers/pci/dwc/Kconfig | 41 +++++--
drivers/pci/dwc/pcie-designware-ep.c | 3 +
drivers/pci/dwc/pcie-designware-plat.c | 149 ++++++++++++++++++++++++--
drivers/pci/endpoint/functions/pci-epf-test.c | 7 ++
include/linux/pci-epc.h | 8 ++
5 files changed, 187 insertions(+), 21 deletions(-)
diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
index 2f3f5c5..62f7cdf 100644
--- a/drivers/pci/dwc/Kconfig
+++ b/drivers/pci/dwc/Kconfig
@@ -7,8 +7,7 @@ config PCIE_DW
config PCIE_DW_HOST
bool
- depends on PCI
- depends on PCI_MSI_IRQ_DOMAIN
+ depends on PCI && PCI_MSI_IRQ_DOMAIN
select PCIE_DW
config PCIE_DW_EP
@@ -51,17 +50,37 @@ config PCI_DRA7XX_EP
This uses the DesignWare core.
config PCIE_DW_PLAT
- bool "Platform bus based DesignWare PCIe Controller"
- depends on PCI
- depends on PCI_MSI_IRQ_DOMAIN
- select PCIE_DW_HOST
- ---help---
- This selects the DesignWare PCIe controller support. Select this if
- you have a PCIe controller on Platform bus.
+ bool
- If you have a controller with this interface, say Y or M here.
+config PCIE_DW_PLAT_HOST
+ bool "Platform bus based DesignWare PCIe Controller - Host mode"
+ depends on PCI && PCI_MSI_IRQ_DOMAIN
+ select PCIE_DW_HOST
+ select PCIE_DW_PLAT
+ default y
+ help
+ Enables support for the PCIe controller in the Designware IP to
+ work in host mode. There are two instances of PCIe controller in
+ Designware IP.
+ This controller can work either as EP or RC. In order to enable
+ host-specific features PCIE_DW_PLAT_HOST must be selected and in
+ order to enable device-specific features PCI_DW_PLAT_EP must be
+ selected.
- If unsure, say N.
+config PCIE_DW_PLAT_EP
+ bool "Platform bus based DesignWare PCIe Controller - Endpoint mode"
+ depends on PCI && PCI_MSI_IRQ_DOMAIN
+ depends on PCI_ENDPOINT
+ select PCIE_DW_EP
+ select PCIE_DW_PLAT
+ help
+ Enables support for the PCIe controller in the Designware IP to
+ work in endpoint mode. There are two instances of PCIe controller
+ in Designware IP.
+ This controller can work either as EP or RC. In order to enable
+ host-specific features PCIE_DW_PLAT_HOST must be selected and in
+ order to enable device-specific features PCI_DW_PLAT_EP must be
+ selected.
config PCI_EXYNOS
bool "Samsung Exynos PCIe controller"
diff --git a/drivers/pci/dwc/pcie-designware-ep.c b/drivers/pci/dwc/pcie-designware-ep.c
index f07678b..04e19b8 100644
--- a/drivers/pci/dwc/pcie-designware-ep.c
+++ b/drivers/pci/dwc/pcie-designware-ep.c
@@ -411,6 +411,9 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
return -ENOMEM;
}
+ epc->features = EPC_FEATURE_NO_LINKUP_NOTIFIER;
+ EPC_FEATURE_SET_BAR(epc->features, BAR_0);
+
ep->epc = epc;
epc_set_drvdata(epc, ep);
dw_pcie_setup(pci);
diff --git a/drivers/pci/dwc/pcie-designware-plat.c b/drivers/pci/dwc/pcie-designware-plat.c
index 5416aa8..efc315c 100644
--- a/drivers/pci/dwc/pcie-designware-plat.c
+++ b/drivers/pci/dwc/pcie-designware-plat.c
@@ -12,19 +12,29 @@
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/init.h>
+#include <linux/of_device.h>
#include <linux/of_gpio.h>
#include <linux/pci.h>
#include <linux/platform_device.h>
#include <linux/resource.h>
#include <linux/signal.h>
#include <linux/types.h>
+#include <linux/regmap.h>
#include "pcie-designware.h"
struct dw_plat_pcie {
- struct dw_pcie *pci;
+ struct dw_pcie *pci;
+ struct regmap *regmap;
+ enum dw_pcie_device_mode mode;
};
+struct dw_plat_pcie_of_data {
+ enum dw_pcie_device_mode mode;
+};
+
+static const struct of_device_id dw_plat_pcie_of_match[];
+
static int dw_plat_pcie_host_init(struct pcie_port *pp)
{
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
@@ -42,9 +52,53 @@ static const struct dw_pcie_host_ops dw_plat_pcie_host_ops = {
.host_init = dw_plat_pcie_host_init,
};
-static int dw_plat_add_pcie_port(struct pcie_port *pp,
+static int dw_plat_pcie_establish_link(struct dw_pcie *pci)
+{
+ return 0;
+}
+
+static const struct dw_pcie_ops dw_pcie_ops = {
+ .start_link = dw_plat_pcie_establish_link,
+};
+
+static void dw_plat_pcie_ep_init(struct dw_pcie_ep *ep)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ enum pci_barno bar;
+
+ for (bar = BAR_0; bar <= BAR_5; bar++)
+ dw_pcie_ep_reset_bar(pci, bar);
+}
+
+static int dw_plat_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
+ enum pci_epc_irq_type type,
+ u8 interrupt_num)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+
+ switch (type) {
+ case PCI_EPC_IRQ_LEGACY:
+ dev_err(pci->dev, "EP cannot trigger legacy IRQs\n");
+ return -EINVAL;
+ case PCI_EPC_IRQ_MSI:
+ return dw_pcie_ep_raise_msi_irq(ep, func_no, interrupt_num);
+ default:
+ dev_err(pci->dev, "UNKNOWN IRQ type\n");
+ }
+
+ return 0;
+}
+
+static struct dw_pcie_ep_ops pcie_ep_ops = {
+ .ep_init = dw_plat_pcie_ep_init,
+ .raise_irq = dw_plat_pcie_ep_raise_irq,
+};
+
+static int dw_plat_add_pcie_port(struct dw_plat_pcie *dw_plat_pcie,
struct platform_device *pdev)
{
+ struct dw_pcie *pci = dw_plat_pcie->pci;
+ struct pcie_port *pp = &pci->pp;
struct device *dev = &pdev->dev;
int ret;
@@ -63,15 +117,44 @@ static int dw_plat_add_pcie_port(struct pcie_port *pp,
ret = dw_pcie_host_init(pp);
if (ret) {
- dev_err(dev, "failed to initialize host\n");
+ dev_err(dev, "Failed to initialize host\n");
return ret;
}
return 0;
}
-static const struct dw_pcie_ops dw_pcie_ops = {
-};
+static int dw_plat_add_pcie_ep(struct dw_plat_pcie *dw_plat_pcie,
+ struct platform_device *pdev)
+{
+ int ret;
+ struct dw_pcie_ep *ep;
+ struct resource *res;
+ struct device *dev = &pdev->dev;
+ struct dw_pcie *pci = dw_plat_pcie->pci;
+
+ ep = &pci->ep;
+ ep->ops = &pcie_ep_ops;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi2");
+ pci->dbi_base2 = devm_ioremap_resource(dev, res);
+ if (IS_ERR(pci->dbi_base2))
+ return PTR_ERR(pci->dbi_base2);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space");
+ if (!res)
+ return -EINVAL;
+
+ ep->phys_base = res->start;
+ ep->addr_size = resource_size(res);
+
+ ret = dw_pcie_ep_init(ep);
+ if (ret) {
+ dev_err(dev, "Failed to initialize endpoint\n");
+ return ret;
+ }
+ return 0;
+}
static int dw_plat_pcie_probe(struct platform_device *pdev)
{
@@ -80,6 +163,16 @@ static int dw_plat_pcie_probe(struct platform_device *pdev)
struct dw_pcie *pci;
struct resource *res; /* Resource from DT */
int ret;
+ const struct of_device_id *match;
+ const struct dw_plat_pcie_of_data *data;
+ enum dw_pcie_device_mode mode;
+
+ match = of_match_device(dw_plat_pcie_of_match, dev);
+ if (!match)
+ return -EINVAL;
+
+ data = (struct dw_plat_pcie_of_data *)match->data;
+ mode = (enum dw_pcie_device_mode)data->mode;
dw_plat_pcie = devm_kzalloc(dev, sizeof(*dw_plat_pcie), GFP_KERNEL);
if (!dw_plat_pcie)
@@ -93,23 +186,59 @@ static int dw_plat_pcie_probe(struct platform_device *pdev)
pci->ops = &dw_pcie_ops;
dw_plat_pcie->pci = pci;
+ dw_plat_pcie->mode = mode;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
+ if (!res)
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pci->dbi_base = devm_ioremap_resource(dev, res);
if (IS_ERR(pci->dbi_base))
return PTR_ERR(pci->dbi_base);
platform_set_drvdata(pdev, dw_plat_pcie);
- ret = dw_plat_add_pcie_port(&pci->pp, pdev);
- if (ret < 0)
- return ret;
+ switch (dw_plat_pcie->mode) {
+ case DW_PCIE_RC_TYPE:
+ if (!IS_ENABLED(CONFIG_PCIE_DW_PLAT_HOST))
+ return -ENODEV;
+
+ ret = dw_plat_add_pcie_port(dw_plat_pcie, pdev);
+ if (ret < 0)
+ return ret;
+ break;
+ case DW_PCIE_EP_TYPE:
+ if (!IS_ENABLED(CONFIG_PCIE_DW_PLAT_EP))
+ return -ENODEV;
+
+ ret = dw_plat_add_pcie_ep(dw_plat_pcie, pdev);
+ if (ret < 0)
+ return ret;
+ break;
+ default:
+ dev_err(dev, "INVALID device type %d\n", dw_plat_pcie->mode);
+ }
return 0;
}
+static const struct dw_plat_pcie_of_data dw_plat_pcie_rc_of_data = {
+ .mode = DW_PCIE_RC_TYPE,
+};
+
+static const struct dw_plat_pcie_of_data dw_plat_pcie_ep_of_data = {
+ .mode = DW_PCIE_EP_TYPE,
+};
+
static const struct of_device_id dw_plat_pcie_of_match[] = {
- { .compatible = "snps,dw-pcie", },
+ {
+ .compatible = "snps,dw-pcie",
+ .data = &dw_plat_pcie_rc_of_data,
+ },
+ {
+ .compatible = "snps,dw-pcie-ep",
+ .data = &dw_plat_pcie_ep_of_data,
+ },
{},
};
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index 7cef851..bee401d 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -435,6 +435,13 @@ static int pci_epf_test_bind(struct pci_epf *epf)
if (WARN_ON_ONCE(!epc))
return -EINVAL;
+ if (epc->features & EPC_FEATURE_NO_LINKUP_NOTIFIER)
+ epf_test->linkup_notifier = false;
+ else
+ epf_test->linkup_notifier = true;
+
+ epf_test->test_reg_bar = EPC_FEATURE_GET_BAR(epc->features);
+
ret = pci_epc_write_header(epc, epf->func_no, header);
if (ret) {
dev_err(dev, "configuration header write failed\n");
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index af657ca..243eaa5 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -90,8 +90,16 @@ struct pci_epc {
struct config_group *group;
/* spinlock to protect against concurrent access of EP controller */
spinlock_t lock;
+ unsigned int features;
};
+#define EPC_FEATURE_NO_LINKUP_NOTIFIER BIT(0)
+#define EPC_FEATURE_BAR_MASK (BIT(1) | BIT(2) | BIT(3))
+#define EPC_FEATURE_SET_BAR(features, bar) \
+ (features |= (EPC_FEATURE_BAR_MASK & (bar << 1)))
+#define EPC_FEATURE_GET_BAR(features) \
+ ((features & EPC_FEATURE_BAR_MASK) >> 1)
+
#define to_pci_epc(device) container_of((device), struct pci_epc, dev)
#define pci_epc_create(dev, ops) \
--
2.7.4
^ permalink raw reply related
* [PATCH 1/4] bindings: PCI: designware: Example update
From: Gustavo Pimentel @ 2018-05-15 7:13 UTC (permalink / raw)
To: bhelgaas, lorenzo.pieralisi, Joao.Pinto, jingoohan1, kishon,
robh+dt, mark.rutland
Cc: linux-pci, linux-kernel, devicetree, Gustavo Pimentel
In-Reply-To: <cover.1526368368.git.gustavo.pimentel@synopsys.com>
Replace "ctrlreg" reg-name by "dbi" to be coherent with similar drivers,
however it still be compatible with any previous DT that uses the old
reg-name.
Replace the PCIe base address example by a real PCIe base address in use.
Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/pci/designware-pcie.txt | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index 1da7ade..7f9804d 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -1,7 +1,8 @@
* Synopsys DesignWare PCIe interface
Required properties:
-- compatible: should contain "snps,dw-pcie" to identify the core.
+- compatible:
+ "snps,dw-pcie" for RC mode;
- reg: Should contain the configuration address space.
- reg-names: Must be "config" for the PCIe configuration space.
(The old way of getting the configuration address space from "ranges"
@@ -41,11 +42,11 @@ EP mode:
Example configuration:
- pcie: pcie@dffff000 {
+ pcie: pcie@dfc00000 {
compatible = "snps,dw-pcie";
- reg = <0xdffff000 0x1000>, /* Controller registers */
- <0xd0000000 0x2000>; /* PCI config space */
- reg-names = "ctrlreg", "config";
+ reg = <0xdfc00000 0x0001000>, /* IP registers */
+ <0xd0000000 0x0002000>; /* Configuration space */
+ reg-names = "dbi", "config";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -54,5 +55,4 @@ Example configuration:
interrupts = <25>, <24>;
#interrupt-cells = <1>;
num-lanes = <1>;
- num-viewport = <3>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH 0/4] Add DesignWare EP support
From: Gustavo Pimentel @ 2018-05-15 7:13 UTC (permalink / raw)
To: bhelgaas, lorenzo.pieralisi, Joao.Pinto, jingoohan1, kishon,
robh+dt, mark.rutland
Cc: linux-pci, linux-kernel, devicetree, Gustavo Pimentel
The PCIe controller dual mode is capable of operating in RC mode as well
as EP mode by configuration option. Till now only RC mode was supported,
with this patch is add EP support to the DesignWare driver.
Gustavo Pimentel (4):
bindings: PCI: designware: Example update
PCI: dwc: Add support for EP mode
bindings: PCI: designware: Add support for EP in DesignWare driver
misc: pci_endpoint_test: Add DesignWare EP entry
.../devicetree/bindings/pci/designware-pcie.txt | 24 +++-
drivers/misc/pci_endpoint_test.c | 1 +
drivers/pci/dwc/Kconfig | 41 ++++--
drivers/pci/dwc/pcie-designware-ep.c | 3 +
drivers/pci/dwc/pcie-designware-plat.c | 149 +++++++++++++++++++--
drivers/pci/endpoint/functions/pci-epf-test.c | 7 +
include/linux/pci-epc.h | 8 ++
7 files changed, 206 insertions(+), 27 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6qdl-phytec-pfla02: Use IRQ_TYPE specifier
From: Shawn Guo @ 2018-05-15 7:12 UTC (permalink / raw)
To: Hernán Gonzalez
Cc: s.hauer, kernel, fabio.estevam, robh+dt, mark.rutland,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <1526254115-3999-1-git-send-email-hernan@vanguardiasur.com.ar>
On Sun, May 13, 2018 at 08:28:35PM -0300, Hernán Gonzalez wrote:
> Replace magic number with the proper IRQ_TYPE specifier to improve DT
> readability.
>
> Signed-off-by: Hernán Gonzalez <hernan@vanguardiasur.com.ar>
> ---
> arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
> index c58f344..1b79ee7 100644
> --- a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
> @@ -115,7 +115,7 @@
> compatible = "dlg,da9063";
> reg = <0x58>;
> interrupt-parent = <&gpio2>;
> - interrupts = <9 0x8>; /* active-low GPIO2_9 */
> + interrupts = <9 IRQ_TYPE_LOW_LEVEL>; /* active-low GPIO2_9 */
It should be IRQ_TYPE_LEVEL_LOW. I fixed it up and applied the patch.
Shawn
>
> regulators {
> vddcore_reg: bcore1 {
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx53-voipac-dmm-668: Use IRQ_TYPE specifier
From: Shawn Guo @ 2018-05-15 7:11 UTC (permalink / raw)
To: Hernán Gonzalez
Cc: s.hauer, kernel, fabio.estevam, robh+dt, mark.rutland,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <1526254051-3929-1-git-send-email-hernan@vanguardiasur.com.ar>
On Sun, May 13, 2018 at 08:27:31PM -0300, Hernán Gonzalez wrote:
> Replace magic number with the proper IRQ_TYPE specifier to improve DT
> readability.
>
> Signed-off-by: Hernán Gonzalez <hernan@vanguardiasur.com.ar>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx53-qsb: Use IRQ_TYPE specifier
From: Shawn Guo @ 2018-05-15 7:10 UTC (permalink / raw)
To: Hernán Gonzalez
Cc: s.hauer, kernel, fabio.estevam, robh+dt, mark.rutland,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <1526253988-3848-1-git-send-email-hernan@vanguardiasur.com.ar>
On Sun, May 13, 2018 at 08:26:28PM -0300, Hernán Gonzalez wrote:
> Replace magic number with the proper IRQ_TYPE specifier to improve DT
> readability.
>
> Signed-off-by: Hernán Gonzalez <hernan@vanguardiasur.com.ar>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] media: i2c: mt9t112: Add device tree support
From: jacopo mondi @ 2018-05-15 7:10 UTC (permalink / raw)
To: Sakari Ailus
Cc: Jacopo Mondi, hans.verkuil, mchehab, robh+dt, linux-media,
devicetree, linux-kernel
In-Reply-To: <20180514215004.5oy6jr7f32jpfhx2@valkosipuli.retiisi.org.uk>
[-- Attachment #1: Type: text/plain, Size: 6333 bytes --]
Hi Sakari,
On Tue, May 15, 2018 at 12:50:04AM +0300, Sakari Ailus wrote:
> Hi Jacopo,
>
> On Mon, May 14, 2018 at 04:30:44PM +0200, jacopo mondi wrote:
> > Hi Sakari,
> >
> > On Mon, May 07, 2018 at 12:32:19PM +0300, Sakari Ailus wrote:
> > > Hi Jacopo,
> > >
> > > On Wed, Apr 25, 2018 at 01:00:14PM +0200, Jacopo Mondi wrote:
> >
> > [snip]
> >
> > > > static int mt9t112_probe(struct i2c_client *client,
> > > > const struct i2c_device_id *did)
> > > > {
> > > > struct mt9t112_priv *priv;
> > > > int ret;
> > > >
> > > > - if (!client->dev.platform_data) {
> > > > + if (!client->dev.of_node && !client->dev.platform_data) {
> > > > dev_err(&client->dev, "mt9t112: missing platform data!\n");
> > > > return -EINVAL;
> > > > }
> > > > @@ -1081,23 +1118,39 @@ static int mt9t112_probe(struct i2c_client *client,
> > > > if (!priv)
> > > > return -ENOMEM;
> > > >
> > > > - priv->info = client->dev.platform_data;
> > > > priv->init_done = false;
> > > > -
> > > > - v4l2_i2c_subdev_init(&priv->subdev, client, &mt9t112_subdev_ops);
> > > > -
> > > > - priv->clk = devm_clk_get(&client->dev, "extclk");
> > > > - if (PTR_ERR(priv->clk) == -ENOENT) {
> > > > + priv->dev = &client->dev;
> > > > +
> > > > + if (client->dev.platform_data) {
> > > > + priv->info = client->dev.platform_data;
> > > > +
> > > > + priv->clk = devm_clk_get(&client->dev, "extclk");
> > >
> > > extclk needs to be documented in DT binding documentation.
> > >
> > > > + if (PTR_ERR(priv->clk) == -ENOENT) {
> > > > + priv->clk = NULL;
> > > > + } else if (IS_ERR(priv->clk)) {
> > > > + dev_err(&client->dev,
> > > > + "Unable to get clock \"extclk\"\n");
> > > > + return PTR_ERR(priv->clk);
> > > > + }
> > > > + } else {
> > > > + /*
> > > > + * External clock frequencies != 24MHz are only supported
> > > > + * for non-OF systems.
> > > > + */
> > >
> > > Shouldn't you actually set the frequency? Or perhaps even better to check
> > > it, and use assigned-clocks and assigned-clock-rates properties?
> > >
> >
> > I might be confused, but my intention was to use an external clock
> > reference, with a configurable frequency only in the platform data use
> > case. As you can see in this 'else' branch, in OF case, the priv->clk
> > field is null, and all the PLL and clock computations are performed
> > assuming a 24MHz input clock.
> >
> > In my opinion, as the driver when running on OF systems does not
> > get any reference to 'extclk' clock, it should not be documented in
> > bindings. Do you agree?
>
> Uh, isn't the clock generally controlled by the driver on OF-based systems?
> You could assign the frequency in DT though, and not in the driver, but
> that should be documented in binding documentation.
>
> The register configuration the driver does not appear to be dependent on
> the clock frequency, which suggests that it is only applicable to a
> particular frequency --- 24 MHz?
Correct.
That's what the comment above here states...
/*
* External clock frequencies != 24MHz are only supported
* for non-OF systems.
*/
That's how it works: the driver expects to receive the PLL dividers
from platform data. It's ugly, I agree, but that's how it was. I do
not have time atm to poke around with PLL configuration, and I'm not
even sure I have the right documentation, so I made a 'default PLL
configuration' for 24MHz clock, copied from the platform data supplied
to the driver by the only user in mainline. In general, I would like
to have the driver calculate the PLL dividers based on the input clock
frequency, that should be supplied from DT. As this is not possible,
at the moment I made the driver only provide a PLL configuration for
24MHz, and that's the only clock the driver accepts.
+ priv->info = &mt9t112_default_pdata_24MHz;
Would you prefer I take a reference to an external clock, check it's
frequency and refuse it if != 24MHz?
By the way, I'm trying to run this driver with a camera module
connected to an ARM platform and so far I have not been able to
capture any image. The Ecovec I have (thanks Hans) has a camera module but the
cable is bad, so I can't test it on the platform the driver has
originally been developed on, but I assume on SH Ecovec it works properly.
Any confirmation from someone who has that board would be appreciate
though.
Thanks
j
>
> >
> > Thanks
> > j
> >
> > > > priv->clk = NULL;
> > > > - } else if (IS_ERR(priv->clk)) {
> > > > - dev_err(&client->dev, "Unable to get clock \"extclk\"\n");
> > > > - return PTR_ERR(priv->clk);
> > > > + priv->info = &mt9t112_default_pdata_24MHz;
> > > > +
> > > > + ret = mt9t112_parse_dt(priv);
> > > > + if (ret)
> > > > + return ret;
> > > > }
> > > >
> > > > - priv->standby_gpio = devm_gpiod_get_optional(&client->dev, "standby",
> > > > + v4l2_i2c_subdev_init(&priv->subdev, client, &mt9t112_subdev_ops);
> > > > +
> > > > + priv->standby_gpio = devm_gpiod_get_optional(&client->dev, "powerdown",
> > > > GPIOD_OUT_HIGH);
> > > > if (IS_ERR(priv->standby_gpio)) {
> > > > - dev_err(&client->dev, "Unable to get gpio \"standby\"\n");
> > > > + dev_err(&client->dev, "Unable to get gpio \"powerdown\"\n");
> > > > return PTR_ERR(priv->standby_gpio);
> > > > }
> > > >
> > > > @@ -1124,9 +1177,19 @@ static const struct i2c_device_id mt9t112_id[] = {
> > > > };
> > > > MODULE_DEVICE_TABLE(i2c, mt9t112_id);
> > > >
> > > > +#if IS_ENABLED(CONFIG_OF)
> > > > +static const struct of_device_id mt9t112_of_match[] = {
> > > > + { .compatible = "micron,mt9t111", },
> > > > + { .compatible = "micron,mt9t112", },
> > > > + { /* sentinel */ },
> > > > +};
> > > > +MODULE_DEVICE_TABLE(of, mt9t112_of_match);
> > > > +#endif
> > > > +
> > > > static struct i2c_driver mt9t112_i2c_driver = {
> > > > .driver = {
> > > > .name = "mt9t112",
> > > > + .of_match_table = of_match_ptr(mt9t112_of_match),
> > >
> > > No need to use of_match_ptr().
> > >
> > > > },
> > > > .probe = mt9t112_probe,
> > > > .remove = mt9t112_remove,
> > >
> > > --
> > > Sakari Ailus
> > > e-mail: sakari.ailus@iki.fi
>
>
>
> --
> Sakari Ailus
> e-mail: sakari.ailus@iki.fi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: vf-colibri-eval-v3.dtsi: Use IRQ_TYPE specifier
From: Shawn Guo @ 2018-05-15 7:10 UTC (permalink / raw)
To: Hernán Gonzalez
Cc: s.hauer, kernel, stefan, robh+dt, mark.rutland, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <1526253894-3709-1-git-send-email-hernan@vanguardiasur.com.ar>
On Sun, May 13, 2018 at 08:24:54PM -0300, Hernán Gonzalez wrote:
> GPIO_ACTIVE_LOW was being used to specify an interrupt, use
> IRQ_TYPE_EDGE_RISING instead. This improves DT readability.
>
> Signed-off-by: Hernán Gonzalez <hernan@vanguardiasur.com.ar>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/3] arm64: dts: Draak: Enable HDMI input and VIN4
From: Simon Horman @ 2018-05-15 7:09 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jacopo Mondi, Niklas Söderlund, Laurent Pinchart,
Magnus Damm, Rob Herring, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Linux Kernel Mailing List
In-Reply-To: <CAMuHMdXdDZdbrpLTogyR=djwtQYMf1dgAA_z+8HaFZBG6R+e6g@mail.gmail.com>
On Mon, May 14, 2018 at 10:33:44PM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Fri, May 11, 2018 at 11:59 AM, Jacopo Mondi
> <jacopo+renesas@jmondi.org> wrote:
> > this series enables HDMI input and VIN4 on R-Car D3 Draak board.
> >
> > The Draak board has an HDMI input connected to an HDMI decoder that feeds
> > the VIN capture interface through its parallel video interface.
> >
> > The series requires the just sent:
> > [PATCH 0/5] rcar-vin: Add support for digital input on Gen3
> >
> > and enables image capture operations on D3 Draak board.
> >
> > The series has been developed on top of media-master tree but applies cleanly
> > on top of latest renesas-driver.
> >
> > Geert: would you like a topic branch for this series to be included in
> > renesas-drivers?
>
> It seems patch 2 has been applied by Simon already, but there is some
> discussion pending on patch 3?
Yes, that is correct.
Also, for extra fun, I moved the nodes when applying patch 2.
> > Patches for testing are available at:
> > git://jmondi.org/linux d3/media-master/driver
> > git://jmondi.org/linux d3/media-master/dts
> > git://jmondi.org/linux d3/media-master/test
> > git://jmondi.org/vin-tests d3
> >
> > Thanks
> > j
> >
> > Jacopo Mondi (3):
> > dt-bindings: media: rcar-vin: Add R8A77995 support
> > arm64: dts: renesas: r8a77995: Add VIN4
> > arm64: dts: renesas: draak: Describe HDMI input
> >
> > .../devicetree/bindings/media/rcar_vin.txt | 1 +
> > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 68 ++++++++++++++++++++++
> > arch/arm64/boot/dts/renesas/r8a77995.dtsi | 11 ++++
> > 3 files changed, 80 insertions(+)
>
> 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 2/3] arm64: dts: renesas: r8a77995: Add VIN4
From: Simon Horman @ 2018-05-15 7:06 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Niklas Söderlund, Jacopo Mondi, geert, magnus.damm, robh+dt,
linux-renesas-soc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <3456643.qNU80MrgjU@avalon>
On Mon, May 14, 2018 at 05:36:41AM +0300, Laurent Pinchart wrote:
> Hello,
>
> On Friday, 11 May 2018 16:45:16 EEST Simon Horman wrote:
> > On Fri, May 11, 2018 at 01:25:23PM +0200, Niklas Söderlund wrote:
> > > Hi Jacopo,
> > >
> > > Thanks for your work.
> > >
> > > On 2018-05-11 12:00:01 +0200, Jacopo Mondi wrote:
> > > > Describe VIN4 interface for R-Car D3 R8A77995 SoC.
> > > >
> > > > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > >
> > > Acked-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> > >
> > >> ---
> > >>
> > >> arch/arm64/boot/dts/renesas/r8a77995.dtsi | 11 +++++++++++
> > >> 1 file changed, 11 insertions(+)
> > >>
> > >> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > >> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index 82aed7e..bdf7017
> > >> 100644
> > >> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > >> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > >> @@ -783,6 +783,17 @@
> > >> };
> > >> };
> > >> };
> > >> +
> > >> + vin4: video@e6ef4000 {
> > >> + compatible = "renesas,vin-r8a77995";
> > >> + reg = <0 0xe6ef4000 0 0x1000>;
> > >> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> > >> + clocks = <&cpg CPG_MOD 807>;
> > >> + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
> > >> + resets = <&cpg 807>;
> > >> + renesas,id = <4>;
> > >> + status = "disabled";
> > >> + };
> > >> };
> >
> > Thanks, I have moved the new node to preserve sorting of nodes by bus
> > address and applied the result. It is as follows:
> >
> > From: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > Subject: [PATCH] arm64: dts: renesas: r8a77995: Add VIN4
> >
> > Describe VIN4 interface for R-Car D3 R8A77995 SoC.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > Acked-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> > [simon: sorted node by bus address]
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Thanks, tag added.
^ permalink raw reply
* Re: [PATCH] thermal: qcom: tsens: Allow number of sensors to come from DT
From: Amit Kucheria @ 2018-05-15 6:57 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Rajendra Nayak, Linux PM list, devicetree, LKML, linux-arm-msm
In-Reply-To: <20180507235339.8836-1-bjorn.andersson@linaro.org>
On Tue, May 8, 2018 at 2:53 AM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> For platforms that has multiple copies of the TSENS hardware block it's
> necessary to be able to specify the number of sensors per block in DeviceTree.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Just one comment below, otherwise,
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
> ---
> .../devicetree/bindings/thermal/qcom-tsens.txt | 1 +
> drivers/thermal/qcom/tsens.c | 12 +++++++++---
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> index 292ed89d900b..06195e8f35e2 100644
> --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> @@ -8,6 +8,7 @@ Required properties:
>
> - reg: Address range of the thermal registers
> - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
> +- #qcom,sensors: Number of sensors in tsens block
> - Refer to Documentation/devicetree/bindings/nvmem/nvmem.txt to know how to specify
> nvmem cells
>
> diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
> index 3f9fe6aa51cc..20f3b87d7667 100644
> --- a/drivers/thermal/qcom/tsens.c
> +++ b/drivers/thermal/qcom/tsens.c
> @@ -116,6 +116,7 @@ static int tsens_probe(struct platform_device *pdev)
> struct tsens_device *tmdev;
> const struct tsens_data *data;
> const struct of_device_id *id;
> + u32 num_sensors;
>
> if (pdev->dev.of_node)
> dev = &pdev->dev;
> @@ -130,18 +131,23 @@ static int tsens_probe(struct platform_device *pdev)
> else
> data = &data_8960;
>
> - if (data->num_sensors <= 0) {
> + num_sensors = data->num_sensors;
> +
Probably worth adding a comment that we're overriding the num_sensors
from DT if available here.
> + if (np)
> + of_property_read_u32(np, "#qcom,sensors", &num_sensors);
> +
> + if (num_sensors <= 0) {
> dev_err(dev, "invalid number of sensors\n");
> return -EINVAL;
> }
>
> tmdev = devm_kzalloc(dev, sizeof(*tmdev) +
> - data->num_sensors * sizeof(*s), GFP_KERNEL);
> + num_sensors * sizeof(*s), GFP_KERNEL);
> if (!tmdev)
> return -ENOMEM;
>
> tmdev->dev = dev;
> - tmdev->num_sensors = data->num_sensors;
> + tmdev->num_sensors = num_sensors;
> tmdev->ops = data->ops;
> for (i = 0; i < tmdev->num_sensors; i++) {
> if (data->hw_ids)
> --
> 2.17.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd
From: Richard Genoud @ 2018-05-15 6:28 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Radu Pirea, devicetree, open list:SERIAL DRIVERS,
Linux Kernel Mailing List, linux-arm Mailing List, linux-spi,
Mark Rutland, Rob Herring, Lee Jones, Greg Kroah-Hartman,
Jiri Slaby, alexandre.belloni, Nicolas Ferre, Mark Brown
In-Reply-To: <CAHp75Vdcd0MmqCMGkFXcvKLrzcHtxBDcB8U1qTzysaH9By4Y8A@mail.gmail.com>
On 14/05/2018 18:56, Andy Shevchenko wrote:
> On Mon, May 14, 2018 at 1:57 PM, Richard Genoud
> <richard.genoud@gmail.com> wrote:
>> On 11/05/2018 12:38, Radu Pirea wrote:
>>> This patch modifies the place where resources and device tree properties
>>> are searched.
>
>> I think it may be simpler with something like:
>
>> + int size = mfd_pdev->resource[0].end - mfd_pdev->resource[0].start + 1;
>
> Isn't resource_size() macro for this very purpose?
Indeed.
+ int size = resource_size(mfd_pdev->resource);
would be even simpler !
>
>>> + int size = to_platform_device(pdev->dev.parent)->resource[0].end -
>>> + to_platform_device(pdev->dev.parent)->resource[0].start + 1;
>>>
>> ditto
>
> Ditto.
>
Thanks !
Richard.
^ permalink raw reply
* [PATCH] ARM: dts: berlin2q: add "cache-unified" to l2 node
From: Jisheng Zhang @ 2018-05-15 6:05 UTC (permalink / raw)
To: Sebastian Hesselbarth, Rob Herring, Mark Rutland
Cc: linux-arm-kernel, devicetree, linux-kernel
Without this property, we get this boot warning:
"L2C: device tree omits to specify unified cache"
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
arch/arm/boot/dts/berlin2q.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index e23c49ae3ec2..7cba798152b9 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -149,6 +149,7 @@
l2: l2-cache-controller@ac0000 {
compatible = "arm,pl310-cache";
reg = <0xac0000 0x1000>;
+ cache-unified;
cache-level = <2>;
arm,data-latency = <2 2 2>;
arm,tag-latency = <2 2 2>;
--
2.17.0
^ 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