Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 3/4 v7] drm/bridge: Add timing support to dumb VGA DAC
From: Archit Taneja @ 2018-01-12  9:25 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180112074854.9560-3-linus.walleij@linaro.org>



On 01/12/2018 01:18 PM, Linus Walleij wrote:
> This extends the dumb VGA DAC bridge to handle the THS8134A
> and THS8134B VGA DACs in addition to those already handled.
> 
> We assign the proper timing data to the pointer inside the
> bridge struct so display controllers that need to align their
> timings to the bridge can pick it up and work from there.

queued to drm-misc-next.

Thanks,
Archit

> 
> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v5->v6:
> - Use DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE to indicate
>    the sampling edge of the clock signal.
> - Skip intermediate variable for timings.
> - Leave timings as NULL for really dumb VGA DACs.
> - Collect Laurent's Review tag.
> ChangeLog v4->v5:
> - Rewrite the support using the new concept of defining
>    fine-granular sampling (setup+hold) timing definitions
>    stored in the bridge timings struct.
> ChangeLog v3->v4:
> - Actually have the code syntactically correct and compiling :(
>    (Kconfig mistake.)
>    (...)
>    AS      usr/initramfs_data.o
>    AR      usr/built-in.o
>    CC      drivers/gpu/drm/bridge/dumb-vga-dac.o
>    AR      drivers/gpu/drm/bridge/built-in.o
>    AR      drivers/gpu/drm/built-in.o
>    AR      drivers/gpu/built-in.o
>    AR      drivers/built-in.o
>    (...)
> ChangeLog v2->v3:
> - Move const specifier.
> - Cut one line of code assigning bus flags.
> - Preserve the "ti,ths8135" compatible for elder device trees.
> ChangeLog v1->v2:
> - Alphabetize includes
> - Use a u32 with the bus polarity flags and just encode the
>    polarity using the DRM define directly.
> - Rename vendor_data to vendor_info.
> - Simplify assignment of the flag as it is just a simple
>    u32 now.
> - Probe all TI variants on the "ti,ths813x" wildcard for now,
>    we only need to know that the device is in this family to
>    set the clock edge flag right.
> ---
>   drivers/gpu/drm/bridge/dumb-vga-dac.c | 59 +++++++++++++++++++++++++++++++++--
>   1 file changed, 56 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> index de5e7dee7ad6..498d5948d1a8 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -11,6 +11,7 @@
>    */
>   
>   #include <linux/module.h>
> +#include <linux/of_device.h>
>   #include <linux/of_graph.h>
>   #include <linux/regulator/consumer.h>
>   
> @@ -204,6 +205,7 @@ static int dumb_vga_probe(struct platform_device *pdev)
>   
>   	vga->bridge.funcs = &dumb_vga_bridge_funcs;
>   	vga->bridge.of_node = pdev->dev.of_node;
> +	vga->bridge.timings = of_device_get_match_data(&pdev->dev);
>   
>   	drm_bridge_add(&vga->bridge);
>   
> @@ -222,10 +224,61 @@ static int dumb_vga_remove(struct platform_device *pdev)
>   	return 0;
>   }
>   
> +/*
> + * We assume the ADV7123 DAC is the "default" for historical reasons
> + * Information taken from the ADV7123 datasheet, revision D.
> + * NOTE: the ADV7123EP seems to have other timings and need a new timings
> + * set if used.
> + */
> +static const struct drm_bridge_timings default_dac_timings = {
> +	/* Timing specifications, datasheet page 7 */
> +	.sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
> +	.setup_time_ps = 500,
> +	.hold_time_ps = 1500,
> +};
> +
> +/*
> + * Information taken from the THS8134, THS8134A, THS8134B datasheet named
> + * "SLVS205D", dated May 1990, revised March 2000.
> + */
> +static const struct drm_bridge_timings ti_ths8134_dac_timings = {
> +	/* From timing diagram, datasheet page 9 */
> +	.sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
> +	/* From datasheet, page 12 */
> +	.setup_time_ps = 3000,
> +	/* I guess this means latched input */
> +	.hold_time_ps = 0,
> +};
> +
> +/*
> + * Information taken from the THS8135 datasheet named "SLAS343B", dated
> + * May 2001, revised April 2013.
> + */
> +static const struct drm_bridge_timings ti_ths8135_dac_timings = {
> +	/* From timing diagram, datasheet page 14 */
> +	.sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
> +	/* From datasheet, page 16 */
> +	.setup_time_ps = 2000,
> +	.hold_time_ps = 500,
> +};
> +
>   static const struct of_device_id dumb_vga_match[] = {
> -	{ .compatible = "dumb-vga-dac" },
> -	{ .compatible = "adi,adv7123" },
> -	{ .compatible = "ti,ths8135" },
> +	{
> +		.compatible = "dumb-vga-dac",
> +		.data = NULL,
> +	},
> +	{
> +		.compatible = "adi,adv7123",
> +		.data = &default_dac_timings,
> +	},
> +	{
> +		.compatible = "ti,ths8135",
> +		.data = &ti_ths8135_dac_timings,
> +	},
> +	{
> +		.compatible = "ti,ths8134",
> +		.data = &ti_ths8134_dac_timings,
> +	},
>   	{},
>   };
>   MODULE_DEVICE_TABLE(of, dumb_vga_match);
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply

* [PATCH 4/4 v7] drm/pl111: Support handling bridge timings
From: Archit Taneja @ 2018-01-12  9:25 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180112074854.9560-4-linus.walleij@linaro.org>



On 01/12/2018 01:18 PM, Linus Walleij wrote:
> If the bridge has a too strict setup time for the incoming
> signals, we may not be fast enough and then we need to
> compensate by outputting the signal on the inverse clock
> edge so it is for sure stable when the bridge samples it.
> 
> Since bridges in difference to panels does not expose their
> connectors, make the connector optional in the display
> setup code.
> 

Since Eric has already Ack'ed it, queued to drm-misc-next so that
the commits stay together.

Thanks,
Archit

> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Reviewed-by: Eric Anholt <eric@anholt.net>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v6->v7:
> - Collect Eric's ACK.
> ChangeLog v5->v6:
> - Collect Laurent's ACK.
> ChangeLog v4->v5:
> - Use the new bridge timings setup method.
> ---
>   drivers/gpu/drm/pl111/Kconfig         |  1 +
>   drivers/gpu/drm/pl111/pl111_display.c | 35 +++++++++++++++++++++++++++++++----
>   drivers/gpu/drm/pl111/pl111_drv.c     | 20 +++++++++++---------
>   3 files changed, 43 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
> index e5e2abd66491..82cb3e60ddc8 100644
> --- a/drivers/gpu/drm/pl111/Kconfig
> +++ b/drivers/gpu/drm/pl111/Kconfig
> @@ -8,6 +8,7 @@ config DRM_PL111
>   	select DRM_GEM_CMA_HELPER
>   	select DRM_BRIDGE
>   	select DRM_PANEL_BRIDGE
> +	select DRM_DUMB_VGA_DAC
>   	select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
>   	help
>   	  Choose this option for DRM support for the PL111 CLCD controller.
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
> index 06c4bf756b69..7fe4040aea46 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
> @@ -94,6 +94,7 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
>   	const struct drm_display_mode *mode = &cstate->mode;
>   	struct drm_framebuffer *fb = plane->state->fb;
>   	struct drm_connector *connector = priv->connector;
> +	struct drm_bridge *bridge = priv->bridge;
>   	u32 cntl;
>   	u32 ppl, hsw, hfp, hbp;
>   	u32 lpp, vsw, vfp, vbp;
> @@ -143,11 +144,37 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
>   	if (mode->flags & DRM_MODE_FLAG_NVSYNC)
>   		tim2 |= TIM2_IVS;
>   
> -	if (connector->display_info.bus_flags & DRM_BUS_FLAG_DE_LOW)
> -		tim2 |= TIM2_IOE;
> +	if (connector) {
> +		if (connector->display_info.bus_flags & DRM_BUS_FLAG_DE_LOW)
> +			tim2 |= TIM2_IOE;
>   
> -	if (connector->display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
> -		tim2 |= TIM2_IPC;
> +		if (connector->display_info.bus_flags &
> +		    DRM_BUS_FLAG_PIXDATA_NEGEDGE)
> +			tim2 |= TIM2_IPC;
> +	}
> +
> +	if (bridge) {
> +		const struct drm_bridge_timings *btimings = bridge->timings;
> +
> +		/*
> +		 * Here is when things get really fun. Sometimes the bridge
> +		 * timings are such that the signal out from PL11x is not
> +		 * stable before the receiving bridge (such as a dumb VGA DAC
> +		 * or similar) samples it. If that happens, we compensate by
> +		 * the only method we have: output the data on the opposite
> +		 * edge of the clock so it is for sure stable when it gets
> +		 * sampled.
> +		 *
> +		 * The PL111 manual does not contain proper timining diagrams
> +		 * or data for these details, but we know from experiments
> +		 * that the setup time is more than 3000 picoseconds (3 ns).
> +		 * If we have a bridge that requires the signal to be stable
> +		 * earlier than 3000 ps before the clock pulse, we have to
> +		 * output the data on the opposite edge to avoid flicker.
> +		 */
> +		if (btimings && btimings->setup_time_ps >= 3000)
> +			tim2 ^= TIM2_IPC;
> +	}
>   
>   	tim2 |= cpl << 16;
>   	writel(tim2, priv->regs + CLCD_TIM2);
> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c
> index 201d57d5cb54..101a9c7db6ff 100644
> --- a/drivers/gpu/drm/pl111/pl111_drv.c
> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
> @@ -107,11 +107,17 @@ static int pl111_modeset_init(struct drm_device *dev)
>   			ret = PTR_ERR(bridge);
>   			goto out_config;
>   		}
> -		/*
> -		 * TODO: when we are using a different bridge than a panel
> -		 * (such as a dumb VGA connector) we need to devise a different
> -		 * method to get the connector out of the bridge.
> -		 */
> +	} else if (bridge) {
> +		dev_info(dev->dev, "Using non-panel bridge\n");
> +	} else {
> +		dev_err(dev->dev, "No bridge, exiting\n");
> +		return -ENODEV;
> +	}
> +
> +	priv->bridge = bridge;
> +	if (panel) {
> +		priv->panel = panel;
> +		priv->connector = panel->connector;
>   	}
>   
>   	ret = pl111_display_init(dev);
> @@ -125,10 +131,6 @@ static int pl111_modeset_init(struct drm_device *dev)
>   	if (ret)
>   		return ret;
>   
> -	priv->bridge = bridge;
> -	priv->panel = panel;
> -	priv->connector = panel->connector;
> -
>   	ret = drm_vblank_init(dev, 1);
>   	if (ret != 0) {
>   		dev_err(dev->dev, "Failed to init vblank\n");
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply

* [PATCH -next] IIO: ADC: fix return value check in stm32_dfsdm_adc_probe()
From: Arnaud Pouliquen @ 2018-01-12  9:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <6AADFAC011213A4C87B956458587ADB40132A0E3@dggemi507-mbx.china.huawei.com>



On 01/12/2018 02:37 AM, weiyongjun (A) wrote:
>>
>> On Thu, Jan 11, 2018 at 11:12:41AM +0000, Wei Yongjun wrote:
>>> In case of error, the function devm_iio_device_alloc() returns NULL
>>> pointer not ERR_PTR(). The IS_ERR() test in the return value check
>>> should be replaced with NULL test.
>>>
>>> Fixes: e2e6771c6462 ("IIO: ADC: add STM32 DFSDM sigma delta ADC
>> support")
>>> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
>>> ---
>>>  drivers/iio/adc/stm32-dfsdm-adc.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-
>> dfsdm-adc.c
>>> index e628d04..5e87140 100644
>>> --- a/drivers/iio/adc/stm32-dfsdm-adc.c
>>> +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
>>> @@ -1100,9 +1100,9 @@ static int stm32_dfsdm_adc_probe(struct
>> platform_device *pdev)
>>>  	dev_data = (const struct stm32_dfsdm_dev_data *)of_id->data;
>>>
>>>  	iio = devm_iio_device_alloc(dev, sizeof(*adc));
>>> -	if (IS_ERR(iio)) {
>>> +	if (!iio) {
>>>  		dev_err(dev, "%s: Failed to allocate IIO\n", __func__);
>>> -		return PTR_ERR(iio);
>>> +		return -ENOMEM;
>>>  	}
>>>
>>>  	adc = iio_priv(iio);
>>         ^^^^^^^^^^^^^^^^^^
>> This one doesn't return an error pointer either.  The check causes a
>> static check warning for me.  (It can't actually fail, though so maybe
>> it will return an error pointer in the future?)
> 
> It seems that we can simply remove the check since 'adc' can never
> be an invalid address here.

Agree, i'm preparing patches for all issue you highlight,

Thanks for all your remarks
Arnaud
> 
> Regards,
> Yongjun Wei
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply

* [PATCH v5 03/44] clk: davinci: Add platform information for TI DA830 PLL
From: Sekhar Nori @ 2018-01-12  9:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1515377863-20358-4-git-send-email-david@lechnology.com>

On Monday 08 January 2018 07:47 AM, David Lechner wrote:
> This adds platform-specific declarations for the PLL clocks on TI DA830/
> OMAP-L137/AM17XX SoCs.
> 
> Signed-off-by: David Lechner <david@lechnology.com>

Reviewed-by: Sekhar Nori <nsekhar@ti.com>

Thanks,
Sekhar

^ permalink raw reply

* [PATCH] arm64: dts: marvell: armada-80x0: Fix pinctrl compatible string
From: Gregory CLEMENT @ 2018-01-12 10:00 UTC (permalink / raw)
  To: linux-arm-kernel

When replacing the cpm by cp0 and cps by cp1 [1] not only the label and
the alias were replaced but also the compatible string which was wrong.

Due to this the pinctrl driver was no more probed.

This patch fix it by reverting this change for the pinctrl compatible
string on Armada 8K.

[1]: "arm64: dts: marvell: replace cpm by cp0, cps by cp1"

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 arch/arm64/boot/dts/marvell/armada-80x0.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-80x0.dtsi b/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
index 0d36b0fa7153..e9c84a1d3c4d 100644
--- a/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
@@ -108,13 +108,13 @@
 
 &cp0_syscon0 {
 	cp0_pinctrl: pinctrl {
-		compatible = "marvell,armada-8k-cp0-pinctrl";
+		compatible = "marvell,armada-8k-cpm-pinctrl";
 	};
 };
 
 &cp1_syscon0 {
 	cp1_pinctrl: pinctrl {
-		compatible = "marvell,armada-8k-cp1-pinctrl";
+		compatible = "marvell,armada-8k-cps-pinctrl";
 
 		nand_pins: nand-pins {
 			marvell,pins =
-- 
2.15.1

^ permalink raw reply related

* [PATCH] arm64: dts: marvell: armada-80x0: Fix pinctrl compatible string
From: Thomas Petazzoni @ 2018-01-12 10:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180112100002.3967-1-gregory.clement@free-electrons.com>

Hello,

On Fri, 12 Jan 2018 11:00:02 +0100, Gregory CLEMENT wrote:
> When replacing the cpm by cp0 and cps by cp1 [1] not only the label and
> the alias were replaced but also the compatible string which was wrong.
> 
> Due to this the pinctrl driver was no more probed.
> 
> This patch fix it by reverting this change for the pinctrl compatible
> string on Armada 8K.
> 
> [1]: "arm64: dts: marvell: replace cpm by cp0, cps by cp1"

It is normally recommended to give the commit ID, i.e:

In commit 01b451ed3bd2 ("arm64: dts: marvell: replace cpm by cp0, cps
by cp1"), ...

> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Thanks for fixing this mistake!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [PATCH 0/3] Reset USB3 controller before initializing Type-C PHY on rk3399
From: William Wu @ 2018-01-12 10:08 UTC (permalink / raw)
  To: linux-arm-kernel

This series adds USB3 OTG controller reset for rk3399 Type-C PHY, and use the
reset to hold the whole USB3 OTG controller in reset state to keep the PIPE
power state in P2 before initializing Type-C PHY, it's useful to avoid waiting
for PHY PMA and PIPE ready timeout.

William Wu (3):
  dt-bindings: phy: phy-rockchip-typec: add usb3 otg reset
  arm64: dts: rockchip: add USB3 OTG reset for Type-C PHY on rk3399
  phy: rockchip-typec: reset USB3 controller before initializing PHY

 .../devicetree/bindings/phy/phy-rockchip-typec.txt | 12 +++++++-----
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           | 10 ++++++----
 drivers/phy/rockchip/phy-rockchip-typec.c          | 22 ++++++++++++++++++++--
 3 files changed, 33 insertions(+), 11 deletions(-)

-- 
2.0.0

^ permalink raw reply

* [PATCH 1/3] dt-bindings: phy: phy-rockchip-typec: add usb3 otg reset
From: William Wu @ 2018-01-12 10:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1515751704-13213-1-git-send-email-william.wu@rock-chips.com>

This patch adds USB3 OTG reset property for rk3399 Type-C PHY
to hold the USB3 controller in reset state.

Signed-off-by: William Wu <william.wu@rock-chips.com>
---
 Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
index 6ea867e..db2902e 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
@@ -13,7 +13,7 @@ Required properties:
  - assigned-clock-rates : the phy core clk frequency, shall be: 50000000
  - resets : a list of phandle + reset specifier pairs
  - reset-names : string reset name, must be:
-		 "uphy", "uphy-pipe", "uphy-tcphy"
+		 "uphy", "uphy-pipe", "uphy-tcphy", "usb3-otg"
  - extcon : extcon specifier for the Power Delivery
 
 Note, there are 2 type-c phys for RK3399, and they are almost identical, except
@@ -56,8 +56,9 @@ Example:
 		assigned-clock-rates = <50000000>;
 		resets = <&cru SRST_UPHY0>,
 			 <&cru SRST_UPHY0_PIPE_L00>,
-			 <&cru SRST_P_UPHY0_TCPHY>;
-		reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+			 <&cru SRST_P_UPHY0_TCPHY>,
+			 <&cru SRST_A_USB3_OTG0>;
+		reset-names = "uphy", "uphy-pipe", "uphy-tcphy", "usb3-otg";
 		rockchip,typec-conn-dir = <0xe580 0 16>;
 		rockchip,usb3tousb2-en = <0xe580 3 19>;
 		rockchip,external-psm = <0xe588 14 30>;
@@ -84,8 +85,9 @@ Example:
 		assigned-clock-rates = <50000000>;
 		resets = <&cru SRST_UPHY1>,
 			 <&cru SRST_UPHY1_PIPE_L00>,
-			 <&cru SRST_P_UPHY1_TCPHY>;
-		reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+			 <&cru SRST_P_UPHY1_TCPHY>,
+			 <&cru SRST_A_USB3_OTG1>;
+		reset-names = "uphy", "uphy-pipe", "uphy-tcphy", "usb3-otg";
 		rockchip,typec-conn-dir = <0xe58c 0 16>;
 		rockchip,usb3tousb2-en = <0xe58c 3 19>;
 		rockchip,external-psm = <0xe594 14 30>;
-- 
2.0.0

^ permalink raw reply related

* [PATCH 2/3] arm64: dts: rockchip: add USB3 OTG reset for Type-C PHY on rk3399
From: William Wu @ 2018-01-12 10:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1515751704-13213-1-git-send-email-william.wu@rock-chips.com>

Add USB3 OTG reset for Type-C PHY. It can be used to hold the USB3
OTG controller in reset state before initializing the Type-C PHY.

Signed-off-by: William Wu <william.wu@rock-chips.com>
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index d340b58a..4e89d00 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1377,8 +1377,9 @@
 		power-domains = <&power RK3399_PD_TCPD0>;
 		resets = <&cru SRST_UPHY0>,
 			 <&cru SRST_UPHY0_PIPE_L00>,
-			 <&cru SRST_P_UPHY0_TCPHY>;
-		reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+			 <&cru SRST_P_UPHY0_TCPHY>,
+			 <&cru SRST_A_USB3_OTG0>;
+		reset-names = "uphy", "uphy-pipe", "uphy-tcphy", "usb3-otg";
 		rockchip,grf = <&grf>;
 		rockchip,typec-conn-dir = <0xe580 0 16>;
 		rockchip,usb3tousb2-en = <0xe580 3 19>;
@@ -1406,8 +1407,9 @@
 		power-domains = <&power RK3399_PD_TCPD1>;
 		resets = <&cru SRST_UPHY1>,
 			 <&cru SRST_UPHY1_PIPE_L00>,
-			 <&cru SRST_P_UPHY1_TCPHY>;
-		reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+			 <&cru SRST_P_UPHY1_TCPHY>,
+			 <&cru SRST_A_USB3_OTG1>;
+		reset-names = "uphy", "uphy-pipe", "uphy-tcphy", "usb3-otg";
 		rockchip,grf = <&grf>;
 		rockchip,typec-conn-dir = <0xe58c 0 16>;
 		rockchip,usb3tousb2-en = <0xe58c 3 19>;
-- 
2.0.0

^ permalink raw reply related

* [PATCH 3/3] phy: rockchip-typec: reset USB3 controller before initializing PHY
From: William Wu @ 2018-01-12 10:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1515751704-13213-1-git-send-email-william.wu@rock-chips.com>

According to the RK3399 TRM, for Type-C USB start-up sequence,
we need to hold the whole USB 3.0 OTG controller in reset state
to keep the PIPE power state in P2 while initializing PHY. This
is because when initialize the Type-C PHY for USB3, we need to
configure the PHY and PMA for the selected mode of operation,
and wait for the PMA and PIPE ready, if the USB3 OTG controller
isn't in P2 state, it may cause waiting timeout.

Without this patch, waiting for the PMA and PIPE ready timeout
issue easily happens when we shutdown the Logic on RK3399 and
do the suspend/resume stress test.

Signed-off-by: William Wu <william.wu@rock-chips.com>
---
 drivers/phy/rockchip/phy-rockchip-typec.c | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c b/drivers/phy/rockchip/phy-rockchip-typec.c
index ee85fa0..68a5840 100644
--- a/drivers/phy/rockchip/phy-rockchip-typec.c
+++ b/drivers/phy/rockchip/phy-rockchip-typec.c
@@ -372,6 +372,7 @@ struct rockchip_typec_phy {
 	struct reset_control *uphy_rst;
 	struct reset_control *pipe_rst;
 	struct reset_control *tcphy_rst;
+	struct reset_control *otg_rst;
 	struct rockchip_usb3phy_port_cfg port_cfgs;
 	/* mutex to protect access to individual PHYs */
 	struct mutex lock;
@@ -841,10 +842,16 @@ static int rockchip_usb3_phy_power_on(struct phy *phy)
 	if (tcphy->mode == new_mode)
 		goto unlock_ret;
 
+	ret = reset_control_assert(tcphy->otg_rst);
+	if (ret < 0) {
+		dev_err(tcphy->dev, "failed to assert otg reset: %d\n", ret);
+		goto unlock_ret;
+	}
+
 	if (tcphy->mode == MODE_DISCONNECT) {
 		ret = tcphy_phy_init(tcphy, new_mode);
 		if (ret)
-			goto unlock_ret;
+			goto unlock_deassert;
 	}
 
 	/* wait TCPHY for pipe ready */
@@ -852,7 +859,7 @@ static int rockchip_usb3_phy_power_on(struct phy *phy)
 		regmap_read(tcphy->grf_regs, reg->offset, &val);
 		if (!(val & BIT(reg->enable_bit))) {
 			tcphy->mode |= new_mode & (MODE_DFP_USB | MODE_UFP_USB);
-			goto unlock_ret;
+			goto unlock_deassert;
 		}
 		usleep_range(10, 20);
 	}
@@ -862,6 +869,11 @@ static int rockchip_usb3_phy_power_on(struct phy *phy)
 
 	ret = -ETIMEDOUT;
 
+unlock_deassert:
+	ret = reset_control_deassert(tcphy->otg_rst);
+	if (ret < 0)
+		dev_err(tcphy->dev, "failed to deassert otg reset: %d\n", ret);
+
 unlock_ret:
 	mutex_unlock(&tcphy->lock);
 	return ret;
@@ -1066,6 +1078,12 @@ static int tcphy_parse_dt(struct rockchip_typec_phy *tcphy,
 		return PTR_ERR(tcphy->tcphy_rst);
 	}
 
+	tcphy->otg_rst = devm_reset_control_get(dev, "usb3-otg");
+	if (IS_ERR(tcphy->otg_rst)) {
+		dev_err(dev, "no otg_rst reset control found\n");
+		return PTR_ERR(tcphy->otg_rst);
+	}
+
 	return 0;
 }
 
-- 
2.0.0

^ permalink raw reply related

* [PATCH] arm64: dts: marvell: armada-80x0: Fix pinctrl compatible string
From: Gregory CLEMENT @ 2018-01-12 10:10 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180112110612.223da2d9@windsurf.lan>

Hi Thomas,
 
 On ven., janv. 12 2018, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> Hello,
>
> On Fri, 12 Jan 2018 11:00:02 +0100, Gregory CLEMENT wrote:
>> When replacing the cpm by cp0 and cps by cp1 [1] not only the label and
>> the alias were replaced but also the compatible string which was wrong.
>> 
>> Due to this the pinctrl driver was no more probed.
>> 
>> This patch fix it by reverting this change for the pinctrl compatible
>> string on Armada 8K.
>> 
>> [1]: "arm64: dts: marvell: replace cpm by cp0, cps by cp1"
>
> It is normally recommended to give the commit ID, i.e:
>
> In commit 01b451ed3bd2 ("arm64: dts: marvell: replace cpm by cp0, cps
> by cp1"), ...

But this commit in not yet in Linus tree, the ID you point is in
linux-next, so once this patch will be merged the commit ID would become
meaningless.

Gregory
>
>> 
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> Thanks for fixing this mistake!
>
> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply

* [PATCH v3] rcutorture: Add basic ARM64 support to run scripts
From: lianglihao at huawei.com @ 2018-01-12 10:11 UTC (permalink / raw)
  To: linux-arm-kernel

From: Lihao Liang <lianglihao@huawei.com>

This commit adds support of the qemu command qemu-system-aarch64
to rcutorture.

Signed-off-by: Lihao Liang <lianglihao@huawei.com>
---

Comparing to the previous version, this patch lifts the limitation of
maximum 8 CPUs of option "-M virt" by adding "gic-version=host" to it.
This allows qemu to use the maximum CPU number supported by the actual
hardware.

This commit is against RCU's git branch rcu/dev

commit 505b61b2ec1d ("EXP: rcu: Add debugging info to other assertion")


 tools/testing/selftests/rcutorture/bin/functions.sh | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh b/tools/testing/selftests/rcutorture/bin/functions.sh
index 07a1377..65f6655 100644
--- a/tools/testing/selftests/rcutorture/bin/functions.sh
+++ b/tools/testing/selftests/rcutorture/bin/functions.sh
@@ -136,6 +136,9 @@ identify_boot_image () {
 		qemu-system-x86_64|qemu-system-i386)
 			echo arch/x86/boot/bzImage
 			;;
+		qemu-system-aarch64)
+			echo arch/arm64/boot/Image
+			;;
 		*)
 			echo vmlinux
 			;;
@@ -158,6 +161,9 @@ identify_qemu () {
 	elif echo $u | grep -q "Intel 80386"
 	then
 		echo qemu-system-i386
+	elif echo $u | grep -q aarch64
+	then
+		echo qemu-system-aarch64
 	elif uname -a | grep -q ppc64
 	then
 		echo qemu-system-ppc64
@@ -176,16 +182,20 @@ identify_qemu () {
 # Output arguments for the qemu "-append" string based on CPU type
 # and the TORTURE_QEMU_INTERACTIVE environment variable.
 identify_qemu_append () {
+	local console=ttyS0
 	case "$1" in
 	qemu-system-x86_64|qemu-system-i386)
 		echo noapic selinux=0 initcall_debug debug
 		;;
+	qemu-system-aarch64)
+		console=ttyAMA0
+		;;
 	esac
 	if test -n "$TORTURE_QEMU_INTERACTIVE"
 	then
 		echo root=/dev/sda
 	else
-		echo console=ttyS0
+		echo console=$console
 	fi
 }
 
@@ -197,6 +207,9 @@ identify_qemu_args () {
 	case "$1" in
 	qemu-system-x86_64|qemu-system-i386)
 		;;
+	qemu-system-aarch64)
+		echo -machine virt,gic-version=host -cpu host
+		;;
 	qemu-system-ppc64)
 		echo -enable-kvm -M pseries -nodefaults
 		echo -device spapr-vscsi
@@ -254,7 +267,7 @@ specify_qemu_cpus () {
 		echo $2
 	else
 		case "$1" in
-		qemu-system-x86_64|qemu-system-i386)
+		qemu-system-x86_64|qemu-system-i386|qemu-system-aarch64)
 			echo $2 -smp $3
 			;;
 		qemu-system-ppc64)
-- 
2.7.4

^ permalink raw reply related

* [PATCH] phy: work around 'phys' references to usb-nop-xceiv devices
From: Arnd Bergmann @ 2018-01-12 10:12 UTC (permalink / raw)
  To: linux-arm-kernel

Stefan Wahren reports a problem with a warning fix that was merged
for v4.15: we had lots of device nodes with a 'phys' property pointing
to a device node that is not compliant with the binding documented in
Documentation/devicetree/bindings/phy/phy-bindings.txt

This generally works because USB HCD drivers that support both the generic
phy subsystem and the older usb-phy subsystem ignore most errors from
phy_get() and related calls and then use the usb-phy driver instead.

However, it turns out that making the usb-nop-xceiv device compatible with
the generic-phy binding changes the phy_get() return code from -EINVAL to
-EPROBE_DEFER, and the dwc2 usb controller driver for bcm2835 now returns
-EPROBE_DEFER from its probe function rather than ignoring the failure,
breaking all USB support on raspberry-pi when CONFIG_GENERIC_PHY is
enabled. The same code is used in the dwc3 driver and the usb_add_hcd()
function, so a reasonable assumption would be that many other platforms
are affected as well.

I have reviewed all the related patches and concluded that "usb-nop-xceiv"
is the only USB phy that is affected by the change, and since it is by far
the most commonly referenced phy, all the other USB phy drivers appear
to be used in ways that are are either safe in DT (they don't use the
'phys' property), or in the driver (they already ignore -EPROBE_DEFER
from generic-phy when usb-phy is available).

To work around the problem, this adds a special case to _of_phy_get()
so we ignore any PHY node that is compatible with "usb-nop-xceiv",
as we know that this can never load no matter how much we defer. In the
future, we might implement a generic-phy driver for "usb-nop-xceiv"
and then remove this workaround.

Since we generally want older kernels to also want to work with the
fixed devicetree files, it would be good to backport the patch into
stable kernels as well (3.13+ are possibly affected), even though they
don't contain any of the patches that may have caused regressions.

Fixes: 014d6da6cb25 ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells
Fixes: c5bbf358b790 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv
Fixes: 44e5dced2ef6 arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
Fixes: f568f6f554b8 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv
Fixes: d745d5f277bf ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv
Fixes: 915fbe59cbf2 ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv
Link: https://marc.info/?l=linux-usb&m=151518314314753&w=2
Link: https://patchwork.kernel.org/patch/10158145/
Cc: stable at vger.kernel.org
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Eric Anholt <eric@anholt.net>
Tested-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Hans tested the earlier version of this patch, I'd like one more
confirmation from Hans or Stefan (or anyone else) that this version
addresses the regression as well before this gets merged.

Greg, can you pick this up into usb-linus for v4.15 once the fix
has been confirmed, or should I merge it through arm-soc?
---
 drivers/phy/phy-core.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index b4964b067aec..8f6e8e28996d 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -410,6 +410,10 @@ static struct phy *_of_phy_get(struct device_node *np, int index)
 	if (ret)
 		return ERR_PTR(-ENODEV);
 
+	/* This phy type handled by the usb-phy subsystem for now */
+	if (of_device_is_compatible(args.np, "usb-nop-xceiv"))
+		return ERR_PTR(-ENODEV);
+
 	mutex_lock(&phy_provider_mutex);
 	phy_provider = of_phy_provider_lookup(args.np);
 	if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
-- 
2.9.0

^ permalink raw reply related

* [PATCH v2 3/7] PCI: aardvark: set host and device to the same MAX payload size
From: Thomas Petazzoni @ 2018-01-12 10:14 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180109221436.GE31640@bhelgaas-glaptop.roam.corp.google.com>

Hello,

On Tue, 9 Jan 2018 16:14:36 -0600, Bjorn Helgaas wrote:

> > I'm trying to get back (finally) to this topic. Unfortunately, your
> > branch has been rebased, and this commit no longer exists. Do you have
> > an updated pointer about what you suggest to use for systems that don't
> > have Root Ports ?  
> 
> Sorry, about that; here's the upstream commit, FWIW:
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ee8bdfb6568d

Thanks. I don't see how this commit can fix our problem though, see below.

> If the OS sees no Root Port (I haven't seen the full lspci or kernel
> enumeration log, so I don't know what the topology actually is), I
> assume you probably have some Endpoints that have valid Link
> Capabilities, Control, and Status registers.  Those refer to the
> downstream end of the Link, and the Root Port would normally have
> corresponding registers that refer to the upstream end.
> 
> The lack of the Root Port means we can't do any management of those
> top-level Links, so no ASPM, no MPS, no link width/speed management,
> etc.
> 
> I see that advk_pcie_probe() calls pcie_bus_configure_settings() like
> all other drivers, and ideally we would try to make that work just
> like it does on other platforms.  The code is:
> 
>   pci_scan_root_bus_bridge(bridge);
>   bus = bridge->bus;
>   list_for_each_entry(child, &bus->children, node)
>     pcie_bus_configure_settings(child);
> 
> This MPS setting is all strictly in the PCIe domain (it's not in the
> Aardvark domain and shouldn't have any Aardvark dependencies), so I
> would expect the core code to just work, modulo some possible
> confusion if it expects to find a Root Port but doesn't.
> 
> Can you collect "lspci -vv" output and details about what currently
> goes wrong?  Then we'd have something more concrete to talk about.

With an E1000E PCIe NIC connected, the entire lspci -vvv output is:

# lspci -vv
00:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)
	Subsystem: Intel Corporation PRO/1000 PT Server Adapter
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 40
	Region 0: Memory at e8000000 (32-bit, non-prefetchable) [size=128K]
	Region 1: Memory at e8020000 (32-bit, non-prefetchable) [size=128K]
	Region 2: I/O ports at 1000 [disabled] [size=32]
	Expansion ROM@e8040000 [disabled] [size=128K]
	Capabilities: [c8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 000000001d1f6f68  Data: 0028
	Capabilities: [e0] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 256 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <4us
			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		AERCap:	First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn-
			MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
		HeaderLog: 00000000 00000000 00000000 00000000
	Capabilities: [140 v1] Device Serial Number 00-1b-21-ff-ff-c1-c4-fe
	Kernel driver in use: e1000e

I.e, there is no Root Port. Therefore, I don't see how the kernel
can know what is the maximum allowed payload size of the PCIe
controller, nor how to adjust the payload size to use. Same for the L0s
configuration.

This is why we need those changes, one to update the PCIe controller
MPS according to the Maximum Payload Size acceptable by the endpoint,
and one to disable L0s entirely to avoid issues with non-L0s compliant
devices.

Does that make more sense ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [PATCH v1 01/16] virtio: Validate queue pfn for 32bit transports
From: Peter Maydell @ 2018-01-12 10:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <2aacb81b-0efb-87b9-f70c-a61e66dd0331@arm.com>

On 10 January 2018 at 11:25, Jean-Philippe Brucker
<jean-philippe.brucker@arm.com> wrote:
> Hi Peter,
>
> On 10/01/18 11:19, Peter Maydell wrote:
>> Are there uses that make it worthwhile to get virtio-1
>> support added to virtio-mmio, rather than just getting
>> people to move over to virtio-pci instead ?
>
> virtio-iommu uses virtio-mmio transport. It makes little sense to have an
> IOMMU presented as a PCI endpoint.

Having an entire transport just for the IOMMU doesn't make
a great deal of sense either though :-) If we didn't already
have virtio-mmio kicking around would we really have designed
it that way?

thanks
-- PMM

^ permalink raw reply

* [PATCH v2] rcutorture: Add basic ARM64 support to run scripts
From: Lihao Liang @ 2018-01-12 10:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171218233155.GZ7829@linux.vnet.ibm.com>

Hi Paul,

On 2017/12/19 7:31, Paul E. McKenney wrote:
> On Tue, Dec 12, 2017 at 05:19:25PM +0800, lianglihao at huawei.com wrote:
>> From: Lihao Liang <lianglihao@huawei.com>
>>
>> This commit adds support of the qemu command qemu-system-aarch64
>> to rcutorture.
>>
>> Signed-off-by: Lihao Liang <lianglihao@huawei.com>
> 
> Queued for further review and testing, thank you!
> 
> (This one has been on my list for quite some time.)
> 
> 							Thanx, Paul
> 
>> ---
>> This commit is against RCU's git tree rcu/dev branch
>>
>> commit 505b61b2ec1d ("EXP: rcu: Add debugging info to other assertion")
>>
>> Note that the max CPUs supported by qemu machine 'virt' is 8 so the value of
>> CONFIG_NR_CPUS in some test configuration files needs to be adjusted.
>>
>>  tools/testing/selftests/rcutorture/bin/functions.sh | 17 +++++++++++++++--
>>  1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh b/tools/testing/selftests/rcutorture/bin/functions.sh
>> index 07a1377..0541d10 100644
>> --- a/tools/testing/selftests/rcutorture/bin/functions.sh
>> +++ b/tools/testing/selftests/rcutorture/bin/functions.sh
>> @@ -136,6 +136,9 @@ identify_boot_image () {
>>  		qemu-system-x86_64|qemu-system-i386)
>>  			echo arch/x86/boot/bzImage
>>  			;;
>> +		qemu-system-aarch64)
>> +			echo arch/arm64/boot/Image
>> +			;;
>>  		*)
>>  			echo vmlinux
>>  			;;
>> @@ -158,6 +161,9 @@ identify_qemu () {
>>  	elif echo $u | grep -q "Intel 80386"
>>  	then
>>  		echo qemu-system-i386
>> +	elif echo $u | grep -q aarch64
>> +	then
>> +		echo qemu-system-aarch64
>>  	elif uname -a | grep -q ppc64
>>  	then
>>  		echo qemu-system-ppc64
>> @@ -176,16 +182,20 @@ identify_qemu () {
>>  # Output arguments for the qemu "-append" string based on CPU type
>>  # and the TORTURE_QEMU_INTERACTIVE environment variable.
>>  identify_qemu_append () {
>> +	local console=ttyS0
>>  	case "$1" in
>>  	qemu-system-x86_64|qemu-system-i386)
>>  		echo noapic selinux=0 initcall_debug debug
>>  		;;
>> +	qemu-system-aarch64)
>> +		console=ttyAMA0
>> +		;;
>>  	esac
>>  	if test -n "$TORTURE_QEMU_INTERACTIVE"
>>  	then
>>  		echo root=/dev/sda
>>  	else
>> -		echo console=ttyS0
>> +		echo console=$console
>>  	fi
>>  }
>>
>> @@ -197,6 +207,9 @@ identify_qemu_args () {
>>  	case "$1" in
>>  	qemu-system-x86_64|qemu-system-i386)
>>  		;;
>> +	qemu-system-aarch64)
>> +		echo -M virt -cpu host

The qemu option "-M virt" only supports maximum 8 CPUs. We can lift this limitation by adding "gic-version=host" to it, which allows qemu to use the maximum CPU number supported by the actual hardware.

I have sent you a new version in a separate email.

Best,
Lihao.

>> +		;;
>>  	qemu-system-ppc64)
>>  		echo -enable-kvm -M pseries -nodefaults
>>  		echo -device spapr-vscsi
>> @@ -254,7 +267,7 @@ specify_qemu_cpus () {
>>  		echo $2
>>  	else
>>  		case "$1" in
>> -		qemu-system-x86_64|qemu-system-i386)
>> +		qemu-system-x86_64|qemu-system-i386|qemu-system-aarch64)
>>  			echo $2 -smp $3
>>  			;;
>>  		qemu-system-ppc64)
>> -- 
>> 2.7.4
>>
> 
> 
> .
> 

^ permalink raw reply

* [PATCH v3 0/2] i2c: mv64xxx: Fix clock resource for Armada 7K/8K
From: Gregory CLEMENT @ 2018-01-12 10:39 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

This short series fixes the way the clocks are used for the mv64xxx
controller embedded in the Marvell Armada 7K/8K SoCs. On these SoCs a
second one is needed in order to clock the registers. It was not
noticed until now because we relied on the bootloader and also because
the clock driver was wrong.

Thanks to this fix, it would be possible to fix the clock driver
without introducing a regression.

The first patch is just a small cleanup found when I wrote the main
patch.

Thanks,

Gregory

Changelog:
v1 -> v2:

 - Really add the binding documentation in the second patch, noticed
   by Thomas Petazzoni.

v2 -> v3

 - Fix typo in binding documentation reported by Thomas	Petazzoni
 - Use correct name for the axi clock, reported by Thomas Petazzoni

Gregory CLEMENT (2):
  i2c: mv64xxx: Remove useless test before clk_disable_unprepare
  i2c: mv64xxx: Fix clock resource by adding an optional bus clock

 .../devicetree/bindings/i2c/i2c-mv64xxx.txt          | 20 ++++++++++++++++++++
 drivers/i2c/busses/i2c-mv64xxx.c                     | 20 +++++++++++++-------
 2 files changed, 33 insertions(+), 7 deletions(-)

-- 
2.15.1

^ permalink raw reply

* [PATCH v3 1/2] i2c: mv64xxx: Remove useless test before clk_disable_unprepare
From: Gregory CLEMENT @ 2018-01-12 10:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180112103956.4875-1-gregory.clement@free-electrons.com>

The 2 functions called from clk_disable_unprepare() already check that
the clock pointer is valid: no need to test it before calling it.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 drivers/i2c/busses/i2c-mv64xxx.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index a832c45276a4..f69066266faa 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -950,9 +950,7 @@ mv64xxx_i2c_probe(struct platform_device *pd)
 exit_reset:
 	reset_control_assert(drv_data->rstc);
 exit_clk:
-	/* Not all platforms have a clk */
-	if (!IS_ERR(drv_data->clk))
-		clk_disable_unprepare(drv_data->clk);
+	clk_disable_unprepare(drv_data->clk);
 
 	return rc;
 }
@@ -965,9 +963,7 @@ mv64xxx_i2c_remove(struct platform_device *dev)
 	i2c_del_adapter(&drv_data->adapter);
 	free_irq(drv_data->irq, drv_data);
 	reset_control_assert(drv_data->rstc);
-	/* Not all platforms have a clk */
-	if (!IS_ERR(drv_data->clk))
-		clk_disable_unprepare(drv_data->clk);
+	clk_disable_unprepare(drv_data->clk);
 
 	return 0;
 }
-- 
2.15.1

^ permalink raw reply related

* [PATCH v3 2/2] i2c: mv64xxx: Fix clock resource by adding an optional bus clock
From: Gregory CLEMENT @ 2018-01-12 10:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180112103956.4875-1-gregory.clement@free-electrons.com>

On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock
is optional because not all the SoCs need them but at least for Armada
7K/8K it is actually mandatory.

The binding documentation is updating accordingly.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 .../devicetree/bindings/i2c/i2c-mv64xxx.txt          | 20 ++++++++++++++++++++
 drivers/i2c/busses/i2c-mv64xxx.c                     | 12 +++++++++++-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
index 5c30026921ae..3d76bb19492f 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
@@ -25,6 +25,15 @@ default frequency is 100kHz
                      whenever you're using the "allwinner,sun6i-a31-i2c"
                      compatible.
 
+ - clocks:	   : pointers to the reference clocks for this device, the
+		     first one is the one used for the clock on the i2c bus,
+		     the second one is the clock used for the functional part
+		     of the controller
+
+ - clock-names	   : names of used clocks, mandatory if the second clock is
+		     used, the name must be "core", and "axi" (the latter is
+		     only for Armada 7K/8K).
+
 Examples:
 
 	i2c at 11000 {
@@ -42,3 +51,14 @@ For the Armada XP:
 		interrupts = <29>;
 		clock-frequency = <100000>;
 	};
+
+For the Armada 7040:
+
+	i2c at 701000 {
+		compatible = "marvell,mv78230-i2c";
+		reg = <0x701000 0x20>;
+		interrupts = <29>;
+		clock-frequency = <100000>;
+		clock-names = "core", "axi";
+		clocks = <&core_clock>, <&axi_clock>;
+	};
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index f69066266faa..cce37d8ecf41 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -135,6 +135,7 @@ struct mv64xxx_i2c_data {
 	u32			freq_m;
 	u32			freq_n;
 	struct clk              *clk;
+	struct clk              *axi_clk;
 	wait_queue_head_t	waitq;
 	spinlock_t		lock;
 	struct i2c_msg		*msg;
@@ -894,13 +895,20 @@ mv64xxx_i2c_probe(struct platform_device *pd)
 	init_waitqueue_head(&drv_data->waitq);
 	spin_lock_init(&drv_data->lock);
 
-	/* Not all platforms have a clk */
+	/* Not all platforms have clocks */
 	drv_data->clk = devm_clk_get(&pd->dev, NULL);
 	if (IS_ERR(drv_data->clk) && PTR_ERR(drv_data->clk) == -EPROBE_DEFER)
 		return -EPROBE_DEFER;
 	if (!IS_ERR(drv_data->clk))
 		clk_prepare_enable(drv_data->clk);
 
+	drv_data->axi_clk = devm_clk_get(&pd->dev, "axi");
+	if (IS_ERR(drv_data->axi_clk) &&
+	    PTR_ERR(drv_data->axi_clk) == -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+	if (!IS_ERR(drv_data->axi_clk))
+		clk_prepare_enable(drv_data->axi_clk);
+
 	drv_data->irq = platform_get_irq(pd, 0);
 
 	if (pdata) {
@@ -950,6 +958,7 @@ mv64xxx_i2c_probe(struct platform_device *pd)
 exit_reset:
 	reset_control_assert(drv_data->rstc);
 exit_clk:
+	clk_disable_unprepare(drv_data->axi_clk);
 	clk_disable_unprepare(drv_data->clk);
 
 	return rc;
@@ -963,6 +972,7 @@ mv64xxx_i2c_remove(struct platform_device *dev)
 	i2c_del_adapter(&drv_data->adapter);
 	free_irq(drv_data->irq, drv_data);
 	reset_control_assert(drv_data->rstc);
+	clk_disable_unprepare(drv_data->axi_clk);
 	clk_disable_unprepare(drv_data->clk);
 
 	return 0;
-- 
2.15.1

^ permalink raw reply related

* [PATCH] spi: orion: Fix clock resource by adding an optional bus clock
From: Gregory CLEMENT @ 2018-01-12 10:42 UTC (permalink / raw)
  To: linux-arm-kernel

On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock
is optional because not all the SoCs need them but at least for Armada
7K/8K it is actually mandatory.

The binding documentation is updating accordingly as well as mentioning
the mandatory clock which was also missing.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 Documentation/devicetree/bindings/spi/spi-orion.txt |  9 +++++++++
 drivers/spi/spi-orion.c                             | 14 ++++++++++++++
 2 files changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-orion.txt b/Documentation/devicetree/bindings/spi/spi-orion.txt
index df8ec31f2f07..8434a65fc12a 100644
--- a/Documentation/devicetree/bindings/spi/spi-orion.txt
+++ b/Documentation/devicetree/bindings/spi/spi-orion.txt
@@ -18,8 +18,17 @@ Required properties:
 	The eight register sets following the control registers refer to
 	chip-select lines 0 through 7 respectively.
 - cell-index : Which of multiple SPI controllers is this.
+- clocks : pointers to the reference clocks for this device, the first
+	   one is the one used for the clock on the spi bus, the
+	   second one is optional and is the clock used for the
+	   functional part of the controller
+
 Optional properties:
 - interrupts : Is currently not used.
+- clock-names : names of used clocks, mandatory if the second clock is
+		used, the name must be "core", and "axi" (the latter
+		is only for Armada 7K/8K).
+
 
 Example:
        spi at 10600 {
diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
index 8974bb340b3a..482a0cf3b7aa 100644
--- a/drivers/spi/spi-orion.c
+++ b/drivers/spi/spi-orion.c
@@ -94,6 +94,7 @@ struct orion_spi {
 	struct spi_master	*master;
 	void __iomem		*base;
 	struct clk              *clk;
+	struct clk              *axi_clk;
 	const struct orion_spi_dev *devdata;
 
 	struct orion_direct_acc	direct_access[ORION_NUM_CHIPSELECTS];
@@ -634,6 +635,14 @@ static int orion_spi_probe(struct platform_device *pdev)
 	if (status)
 		goto out;
 
+	/* The following clock is only used by some SoCs */
+	spi->axi_clk = devm_clk_get(&pdev->dev, "axi");
+	if (IS_ERR(spi->axi_clk) &&
+	    PTR_ERR(spi->axi_clk) == -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+	if (!IS_ERR(spi->axi_clk))
+		clk_prepare_enable(spi->axi_clk);
+
 	tclk_hz = clk_get_rate(spi->clk);
 
 	/*
@@ -725,6 +734,7 @@ static int orion_spi_probe(struct platform_device *pdev)
 out_rel_pm:
 	pm_runtime_disable(&pdev->dev);
 out_rel_clk:
+	clk_disable_unprepare(spi->axi_clk);
 	clk_disable_unprepare(spi->clk);
 out:
 	spi_master_put(master);
@@ -738,6 +748,7 @@ static int orion_spi_remove(struct platform_device *pdev)
 	struct orion_spi *spi = spi_master_get_devdata(master);
 
 	pm_runtime_get_sync(&pdev->dev);
+	clk_disable_unprepare(spi->axi_clk);
 	clk_disable_unprepare(spi->clk);
 
 	spi_unregister_master(master);
@@ -754,6 +765,7 @@ static int orion_spi_runtime_suspend(struct device *dev)
 	struct spi_master *master = dev_get_drvdata(dev);
 	struct orion_spi *spi = spi_master_get_devdata(master);
 
+	clk_disable_unprepare(spi->axi_clk);
 	clk_disable_unprepare(spi->clk);
 	return 0;
 }
@@ -763,6 +775,8 @@ static int orion_spi_runtime_resume(struct device *dev)
 	struct spi_master *master = dev_get_drvdata(dev);
 	struct orion_spi *spi = spi_master_get_devdata(master);
 
+	if (!IS_ERR(spi->axi_clk))
+		clk_prepare_enable(spi->axi_clk);
 	return clk_prepare_enable(spi->clk);
 }
 #endif
-- 
2.15.1

^ permalink raw reply related

* [PATCH v3] arm64: fix unwind_frame() for filtered out fn for function graph tracing
From: Jerome Marchand @ 2018-01-12 10:48 UTC (permalink / raw)
  To: linux-arm-kernel

From: Pratyush Anand <panand@redhat.com>

Change since v2:
- Set frame.graph = current->curr_ret_stack in profile_pc
- Check that frame->graph != -1 in unwind_frame

do_task_stat() calls get_wchan(), which further does unwind_frame().
unwind_frame() restores frame->pc to original value in case function
graph tracer has modified a return address (LR) in a stack frame to hook
a function return. However, if function graph tracer has hit a filtered
function, then we can't unwind it as ftrace_push_return_trace() has
biased the index(frame->graph) with a 'huge negative'
offset(-FTRACE_NOTRACE_DEPTH).

Moreover, arm64 stack walker defines index(frame->graph) as unsigned
int, which can not compare a -ve number.

Similar problem we can have with calling of walk_stackframe() from
save_stack_trace_tsk() or dump_backtrace().

This patch fixes unwind_frame() to test the index for -ve value and
restore index accordingly before we can restore frame->pc.

Reproducer:

cd /sys/kernel/debug/tracing/
echo schedule > set_graph_notrace
echo 1 > options/display-graph
echo wakeup > current_tracer
ps -ef | grep -i agent

Above commands result in:
Unable to handle kernel paging request at virtual address ffff801bd3d1e000
pgd = ffff8003cbe97c00
[ffff801bd3d1e000] *pgd=0000000000000000, *pud=0000000000000000
Internal error: Oops: 96000006 [#1] SMP
[...]
CPU: 5 PID: 11696 Comm: ps Not tainted 4.11.0+ #33
[...]
task: ffff8003c21ba000 task.stack: ffff8003cc6c0000
PC is at unwind_frame+0x12c/0x180
LR is at get_wchan+0xd4/0x134
pc : [<ffff00000808892c>] lr : [<ffff0000080860b8>] pstate: 60000145
sp : ffff8003cc6c3ab0
x29: ffff8003cc6c3ab0 x28: 0000000000000001
x27: 0000000000000026 x26: 0000000000000026
x25: 00000000000012d8 x24: 0000000000000000
x23: ffff8003c1c04000 x22: ffff000008c83000
x21: ffff8003c1c00000 x20: 000000000000000f
x19: ffff8003c1bc0000 x18: 0000fffffc593690
x17: 0000000000000000 x16: 0000000000000001
x15: 0000b855670e2b60 x14: 0003e97f22cf1d0f
x13: 0000000000000001 x12: 0000000000000000
x11: 00000000e8f4883e x10: 0000000154f47ec8
x9 : 0000000070f367c0 x8 : 0000000000000000
x7 : 00008003f7290000 x6 : 0000000000000018
x5 : 0000000000000000 x4 : ffff8003c1c03cb0
x3 : ffff8003c1c03ca0 x2 : 00000017ffe80000
x1 : ffff8003cc6c3af8 x0 : ffff8003d3e9e000

Process ps (pid: 11696, stack limit = 0xffff8003cc6c0000)
Stack: (0xffff8003cc6c3ab0 to 0xffff8003cc6c4000)
[...]
[<ffff00000808892c>] unwind_frame+0x12c/0x180
[<ffff000008305008>] do_task_stat+0x864/0x870
[<ffff000008305c44>] proc_tgid_stat+0x3c/0x48
[<ffff0000082fde0c>] proc_single_show+0x5c/0xb8
[<ffff0000082b27e0>] seq_read+0x160/0x414
[<ffff000008289e6c>] __vfs_read+0x58/0x164
[<ffff00000828b164>] vfs_read+0x88/0x144
[<ffff00000828c2e8>] SyS_read+0x60/0xc0
[<ffff0000080834a0>] __sys_trace_return+0x0/0x4

fixes: 20380bb390a4 (arm64: ftrace: fix a stack tracer's output under function graph tracer)
Signed-off-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
---
 arch/arm64/include/asm/stacktrace.h | 2 +-
 arch/arm64/kernel/stacktrace.c      | 4 ++++
 arch/arm64/kernel/time.c            | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/stacktrace.h b/arch/arm64/include/asm/stacktrace.h
index 6ad30776e984..99390755c0c4 100644
--- a/arch/arm64/include/asm/stacktrace.h
+++ b/arch/arm64/include/asm/stacktrace.h
@@ -27,7 +27,7 @@ struct stackframe {
 	unsigned long fp;
 	unsigned long pc;
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
-	unsigned int graph;
+	int graph;
 #endif
 };
 
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 76809ccd309c..5a528c58ef68 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -59,6 +59,10 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 	if (tsk->ret_stack &&
 			(frame->pc == (unsigned long)return_to_handler)) {
+		WARN_ON(frame->graph == -1);
+		if (frame->graph < -1)
+			frame->graph += FTRACE_NOTRACE_DEPTH;
+
 		/*
 		 * This is a case where function graph tracer has
 		 * modified a return address (LR) in a stack frame
diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index a4391280fba9..f258636273c9 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -52,7 +52,7 @@ unsigned long profile_pc(struct pt_regs *regs)
 	frame.fp = regs->regs[29];
 	frame.pc = regs->pc;
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
-	frame.graph = -1; /* no task info */
+	frame.graph = current->curr_ret_stack;
 #endif
 	do {
 		int ret = unwind_frame(NULL, &frame);
-- 
2.13.6

^ permalink raw reply related

* [PATCH v3 2/2] i2c: mv64xxx: Fix clock resource by adding an optional bus clock
From: Maxime Ripard @ 2018-01-12 10:54 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180112103956.4875-3-gregory.clement@free-electrons.com>

Hi,

On Fri, Jan 12, 2018 at 11:39:56AM +0100, Gregory CLEMENT wrote:
> On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock
> is optional because not all the SoCs need them but at least for Armada
> 7K/8K it is actually mandatory.
> 
> The binding documentation is updating accordingly.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
>  .../devicetree/bindings/i2c/i2c-mv64xxx.txt          | 20 ++++++++++++++++++++
>  drivers/i2c/busses/i2c-mv64xxx.c                     | 12 +++++++++++-
>  2 files changed, 31 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> index 5c30026921ae..3d76bb19492f 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> @@ -25,6 +25,15 @@ default frequency is 100kHz
>                       whenever you're using the "allwinner,sun6i-a31-i2c"
>                       compatible.
>  
> + - clocks:	   : pointers to the reference clocks for this device, the
> +		     first one is the one used for the clock on the i2c bus,
> +		     the second one is the clock used for the functional part
> +		     of the controller

This documentation is confusing, as usually the functional clock is
the clock driving the bus, as opposed to the interface clock clocking
the bus interface.

> + - clock-names	   : names of used clocks, mandatory if the second clock is
> +		     used, the name must be "core", and "axi" (the latter is
> +		     only for Armada 7K/8K).
> +

Are you sure the i2c controller is on the AXI bus? It seems more
likely to be on an APB bus.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180112/4f2142f6/attachment.sig>

^ permalink raw reply

* [PATCH v1 01/16] virtio: Validate queue pfn for 32bit transports
From: Jean-Philippe Brucker @ 2018-01-12 11:01 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAFEAcA9KMWkTOd4w-QD8fsFs4UQJaNC4PMwPtHVS54ZLhHT72A@mail.gmail.com>

On 12/01/18 10:21, Peter Maydell wrote:
> On 10 January 2018 at 11:25, Jean-Philippe Brucker
> <jean-philippe.brucker@arm.com> wrote:
>> Hi Peter,
>>
>> On 10/01/18 11:19, Peter Maydell wrote:
>>> Are there uses that make it worthwhile to get virtio-1
>>> support added to virtio-mmio, rather than just getting
>>> people to move over to virtio-pci instead ?
>>
>> virtio-iommu uses virtio-mmio transport. It makes little sense to have an
>> IOMMU presented as a PCI endpoint.
> 
> Having an entire transport just for the IOMMU doesn't make
> a great deal of sense either though :-) If we didn't already
> have virtio-mmio kicking around would we really have designed
> it that way?
Possibly. It certainly was on the table during early investigations. It
does beat the alternative, having to redesign firmware interfaces and
rewrite core driver code to cater for unrealistic device topologies.

Thanks,
Jean

^ permalink raw reply

* [PATCH v3 2/2] i2c: mv64xxx: Fix clock resource by adding an optional bus clock
From: Gregory CLEMENT @ 2018-01-12 11:15 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180112105434.juefp2apuber3zti@flea.lan>

Hi Maxime,
 
 On ven., janv. 12 2018, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:

> Hi,
>
> On Fri, Jan 12, 2018 at 11:39:56AM +0100, Gregory CLEMENT wrote:
>> On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock
>> is optional because not all the SoCs need them but at least for Armada
>> 7K/8K it is actually mandatory.
>> 
>> The binding documentation is updating accordingly.
>> 
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>>  .../devicetree/bindings/i2c/i2c-mv64xxx.txt          | 20 ++++++++++++++++++++
>>  drivers/i2c/busses/i2c-mv64xxx.c                     | 12 +++++++++++-
>>  2 files changed, 31 insertions(+), 1 deletion(-)
>> 
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
>> index 5c30026921ae..3d76bb19492f 100644
>> --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
>> @@ -25,6 +25,15 @@ default frequency is 100kHz
>>                       whenever you're using the "allwinner,sun6i-a31-i2c"
>>                       compatible.
>>  
>> + - clocks:	   : pointers to the reference clocks for this device, the
>> +		     first one is the one used for the clock on the i2c bus,
>> +		     the second one is the clock used for the functional part
>> +		     of the controller
>
> This documentation is confusing, as usually the functional clock is
> the clock driving the bus, as opposed to the interface clock clocking
> the bus interface.

I don't find it less confusing, for my point of view the interface of a
bus is the lines interfacing the bus with the devices on this bus. But I
don't mind modifying it, as I clearly state that the first clock is the
one used to generate the clock of the i2c bus, so we can change the
name.

>
>> + - clock-names	   : names of used clocks, mandatory if the second clock is
>> +		     used, the name must be "core", and "axi" (the latter is
>> +		     only for Armada 7K/8K).
>> +
>
> Are you sure the i2c controller is on the AXI bus? It seems more
> likely to be on an APB bus.

No I am not sure :)
Actually I don't have this information, so lets call it "reg" for
register clock.

Gregory

>
> Maxime
>
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply

* [PATCH] soc: brcmstb: Only register SoC device on STB platforms
From: Sudeep Holla @ 2018-01-12 11:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180109145409.11612-1-thierry.reding@gmail.com>



On 09/01/18 14:54, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> After moving the SoC device initialization to an early initcall in
> commit f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall"),
> the Broadcom STB SoC device is registered on all platforms if support
> for the device is enabled in the kernel configuration.
> 
> This causes an additional SoC device to appear on platforms that already
> register a native one. In case of Tegra the STB SoC device is registered
> as soc0 (with totally meaningless content in the sysfs attributes) and
> causes various scripts and programs to fail because they don't know how
> to parse that data.
> 
> To fix this, duplicate the check from brcmstb_soc_device_early_init()
> that already prevents the code from doing anything nonsensical on non-
> STB platforms.
> 
> Fixes: f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall")
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  drivers/soc/bcm/brcmstb/common.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/soc/bcm/brcmstb/common.c b/drivers/soc/bcm/brcmstb/common.c
> index 781ada62d0a3..4fe1cb73b39a 100644
> --- a/drivers/soc/bcm/brcmstb/common.c
> +++ b/drivers/soc/bcm/brcmstb/common.c
> @@ -89,8 +89,13 @@ early_initcall(brcmstb_soc_device_early_init);
>  static int __init brcmstb_soc_device_init(void)
>  {
>  	struct soc_device_attribute *soc_dev_attr;
> +	struct device_node *sun_top_ctrl;
>  	struct soc_device *soc_dev;
>  
> +	sun_top_ctrl = of_find_matching_node(NULL, sun_top_ctrl_match);
> +	if (!sun_top_ctrl)
> +		return -ENODEV;
> +

missing of_node_put(sun_top_ctrl) ? or am I missing to see that elsewhere ?

-- 
Regards,
Sudeep

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox