Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v5 02/17] drm/sun4i: sun6i_mipi_dsi: Add has_mod_clk quirk
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
  Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
	Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>

Mod clock is not mandatory for all Allwinner MIPI DSI
controllers, it is connected as CLK_DSI_SCLK for A31
and not available in A64.

So add has_mod_clk quirk and process the clk accordingly.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 39 ++++++++++++++++++--------
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |  5 ++++
 2 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index e3b34a345546..561de393ea23 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -10,6 +10,7 @@
 #include <linux/component.h>
 #include <linux/crc-ccitt.h>
 #include <linux/of_address.h>
+#include <linux/of_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/regmap.h>
 #include <linux/reset.h>
@@ -981,6 +982,8 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
 	dsi->host.ops = &sun6i_dsi_host_ops;
 	dsi->host.dev = dev;
 
+	dsi->variant = of_device_get_match_data(dev);
+
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	base = devm_ioremap_resource(dev, res);
 	if (IS_ERR(base)) {
@@ -1001,17 +1004,20 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
 		return PTR_ERR(dsi->reset);
 	}
 
-	dsi->mod_clk = devm_clk_get(dev, "mod");
-	if (IS_ERR(dsi->mod_clk)) {
-		dev_err(dev, "Couldn't get the DSI mod clock\n");
-		return PTR_ERR(dsi->mod_clk);
+	if (dsi->variant->has_mod_clk) {
+		dsi->mod_clk = devm_clk_get(dev, "mod");
+		if (IS_ERR(dsi->mod_clk)) {
+			dev_err(dev, "Couldn't get the DSI mod clock\n");
+			return PTR_ERR(dsi->mod_clk);
+		}
 	}
 
 	/*
 	 * In order to operate properly, that clock seems to be always
 	 * set to 297MHz.
 	 */
-	clk_set_rate_exclusive(dsi->mod_clk, 297000000);
+	if (dsi->variant->has_mod_clk)
+		clk_set_rate_exclusive(dsi->mod_clk, 297000000);
 
 	dphy_node = of_parse_phandle(dev->of_node, "phys", 0);
 	ret = sun6i_dphy_probe(dsi, dphy_node);
@@ -1043,7 +1049,8 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
 	pm_runtime_disable(dev);
 	sun6i_dphy_remove(dsi);
 err_unprotect_clk:
-	clk_rate_exclusive_put(dsi->mod_clk);
+	if (dsi->variant->has_mod_clk)
+		clk_rate_exclusive_put(dsi->mod_clk);
 	return ret;
 }
 
@@ -1056,7 +1063,8 @@ static int sun6i_dsi_remove(struct platform_device *pdev)
 	mipi_dsi_host_unregister(&dsi->host);
 	pm_runtime_disable(dev);
 	sun6i_dphy_remove(dsi);
-	clk_rate_exclusive_put(dsi->mod_clk);
+	if (dsi->variant->has_mod_clk)
+		clk_rate_exclusive_put(dsi->mod_clk);
 
 	return 0;
 }
@@ -1066,7 +1074,8 @@ static int __maybe_unused sun6i_dsi_runtime_resume(struct device *dev)
 	struct sun6i_dsi *dsi = dev_get_drvdata(dev);
 
 	reset_control_deassert(dsi->reset);
-	clk_prepare_enable(dsi->mod_clk);
+	if (dsi->variant->has_mod_clk)
+		clk_prepare_enable(dsi->mod_clk);
 
 	/*
 	 * Enable the DSI block.
@@ -1094,7 +1103,8 @@ static int __maybe_unused sun6i_dsi_runtime_suspend(struct device *dev)
 {
 	struct sun6i_dsi *dsi = dev_get_drvdata(dev);
 
-	clk_disable_unprepare(dsi->mod_clk);
+	if (dsi->variant->has_mod_clk)
+		clk_disable_unprepare(dsi->mod_clk);
 	reset_control_assert(dsi->reset);
 
 	return 0;
@@ -1106,9 +1116,16 @@ static const struct dev_pm_ops sun6i_dsi_pm_ops = {
 			   NULL)
 };
 
+static const struct sun6i_dsi_variant sun6i_a31_dsi = {
+	.has_mod_clk = true,
+};
+
 static const struct of_device_id sun6i_dsi_of_table[] = {
-	{ .compatible = "allwinner,sun6i-a31-mipi-dsi" },
-	{ }
+	{
+		.compatible = "allwinner,sun6i-a31-mipi-dsi",
+		.data = &sun6i_a31_dsi,
+	},
+	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, sun6i_dsi_of_table);
 
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
index dbbc5b3ecbda..597b62227019 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
@@ -20,6 +20,10 @@ struct sun6i_dphy {
 	struct reset_control	*reset;
 };
 
+struct sun6i_dsi_variant {
+	bool			has_mod_clk;
+};
+
 struct sun6i_dsi {
 	struct drm_connector	connector;
 	struct drm_encoder	encoder;
@@ -35,6 +39,7 @@ struct sun6i_dsi {
 	struct sun4i_drv	*drv;
 	struct mipi_dsi_device	*device;
 	struct drm_panel	*panel;
+	const struct sun6i_dsi_variant	*variant;
 };
 
 static inline struct sun6i_dsi *host_to_sun6i_dsi(struct mipi_dsi_host *host)
-- 
2.18.0.321.gffc6fa0e3


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v5 01/17] clk: sunxi-ng: Add check for minimal rate to NKM PLLs
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
  Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
	Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>

Some NKM PLLs doesn't work well when their output clock rate is set below
certain rate.

So, add support for minimal rate for relevant PLLs.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
---
 drivers/clk/sunxi-ng/ccu_nkm.c | 5 +++++
 drivers/clk/sunxi-ng/ccu_nkm.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
index 841840e35e61..096ff4f4839a 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.c
+++ b/drivers/clk/sunxi-ng/ccu_nkm.c
@@ -125,6 +125,11 @@ static unsigned long ccu_nkm_round_rate(struct ccu_mux_internal *mux,
 	if (nkm->common.features & CCU_FEATURE_FIXED_POSTDIV)
 		rate *= nkm->fixed_post_div;
 
+	if (rate < nkm->min_rate) {
+		rate = nkm->min_rate;
+		return rate;
+	}
+
 	ccu_nkm_find_best(*parent_rate, rate, &_nkm);
 
 	rate = *parent_rate * _nkm.n * _nkm.k / _nkm.m;
diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
index cc6efb70a102..ff5bd00f429f 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.h
+++ b/drivers/clk/sunxi-ng/ccu_nkm.h
@@ -35,6 +35,7 @@ struct ccu_nkm {
 	struct ccu_mux_internal	mux;
 
 	unsigned int		fixed_post_div;
+	unsigned int		min_rate;
 
 	struct ccu_common	common;
 };
-- 
2.18.0.321.gffc6fa0e3


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v5 03/17] drm/sun4i: sun6i_mipi_dsi: Add Allwinner A64 MIPI DSI support
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
  Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
	Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>

The MIPI DSI controller on Allwinner A64 is similar to
Allwinner A31 without support of DSI mod clock(CLK_DSI_SCLK)

So, alter has_mod_clk bool via driver data for respective
SoC's compatible.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 561de393ea23..50f535ae57e9 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -1120,11 +1120,18 @@ static const struct sun6i_dsi_variant sun6i_a31_dsi = {
 	.has_mod_clk = true,
 };
 
+static const struct sun6i_dsi_variant sun50i_a64_dsi = {
+};
+
 static const struct of_device_id sun6i_dsi_of_table[] = {
 	{
 		.compatible = "allwinner,sun6i-a31-mipi-dsi",
 		.data = &sun6i_a31_dsi,
 	},
+	{
+		.compatible = "allwinner,sun50i-a64-mipi-dsi",
+		.data = &sun50i_a64_dsi,
+	},
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, sun6i_dsi_of_table);
-- 
2.18.0.321.gffc6fa0e3


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v5 00/17] drm/sun4i: Allwinner A64 MIPI-DSI support
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
  Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
	Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel

This series fixed the issues related to work DSI on 2-lane panel
which is reported on previous version[1][2][3]

This supposed to be a clean series, where it support Allwinner A64 MIPI-DSI
support for 4-lane, 2-lane DSI panels.

This series fixed all previous series comments along with checkpatch
warnings/error.

Changes for v5:
- collect Rob, Acked-by
- droped "Fix VBP size calculation" patch
- updated vblk timing calculation.
- droped techstar, bananapi dsi panel drivers which may require
  bridge or other setup. it's under discussion.
Changes for v4:
- droppoed untested CCU_FEATURE_FIXED_POSTDIV check code in
  nkm min, max rate patches
- create two patches for "Add Allwinner A64 MIPI DSI support"
  one for has_mod_clk quirk and other one for A64 support
- use existing driver code construct for hblk computation
- dropped "Increase hfp packet overhead" patch [2], though BSP added
  this but we have no issues as of now.
  (no issues on panel side w/o this change)
- create separate function for vblk computation 
- enable vcc-dsi regulator in dsi_runtime_resume
- collect Rob, Acked-by
- update MAINTAINERS file for panel drivers
- cleanup commit messages
- fixed checkpatch warnings/errors

[3] https://patchwork.kernel.org/cover/10680247/
[2] https://patchwork.kernel.org/patch/10657541/
[1] https://patchwork.kernel.org/patch/10657619/

Note: the respetive dts consumer for dsi will send once the panel
driver finalized or in burst mode patch series.

Any inputs,
Jagan.

Jagan Teki (17):
  clk: sunxi-ng: Add check for minimal rate to NKM PLLs
  drm/sun4i: sun6i_mipi_dsi: Add has_mod_clk quirk
  drm/sun4i: sun6i_mipi_dsi: Add Allwinner A64 MIPI DSI support
  dt-bindings: sun6i-dsi: Add compatible for A64 MIPI DSI
  drm/sun4i: sun6i_mipi_dsi: Add DSI Generic short write 2 param
    transfer
  drm/sun4i: sun6i_mipi_dsi: Fix TCON DRQ set bits
  drm/sun4i: sun6i_mipi_dsi: Refactor vertical video start delay
  drm/sun4i: sun6i_mipi_dsi: Fix DSI hbp timing value
  drm/sun4i: sun6i_mipi_dsi: Fix DSI hblk timing calculation
  drm/sun4i: sun6i_mipi_dsi: Add DSI hblk packet overhead
  drm/sun4i: sun6i_mipi_dsi: Fix DSI hfp timing value
  drm/sun4i: sun6i_mipi_dsi: Set proper vblk timing calculation
  drm/sun4i: sun6i_mipi_dsi: Add support for VCC-DSI voltage regulator
  dt-bindings: sun6i-dsi: Add VCC-DSI supply property
  clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
  dt-bindings: sun6i-dsi: Add A64 DPHY compatible (w/ A31 fallback)
  arm64: dts: allwinner: a64: Add DSI pipeline

 .../bindings/display/sunxi/sun6i-dsi.txt      |   5 +
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi |  45 +++++++
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c         |   1 +
 drivers/clk/sunxi-ng/ccu_nkm.c                |   5 +
 drivers/clk/sunxi-ng/ccu_nkm.h                |   1 +
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c        | 118 ++++++++++++++----
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h        |   8 ++
 7 files changed, 159 insertions(+), 24 deletions(-)

-- 
2.18.0.321.gffc6fa0e3


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] ARM: mm: skip cleaning of idmap page tables on LPAE capable cores
From: Marc Zyngier @ 2018-12-10 16:13 UTC (permalink / raw)
  To: Russell King - ARM Linux, Ard Biesheuvel; +Cc: Will Deacon, linux-arm-kernel
In-Reply-To: <20181210154808.GF30658@n2100.armlinux.org.uk>

On 10/12/2018 15:48, Russell King - ARM Linux wrote:
> On Mon, Dec 10, 2018 at 04:28:55PM +0100, Ard Biesheuvel wrote:
>> Since only LPAE capable CPUs may execute under virtualization, and
>> considering that LPAE capable CPUs are guaranteed to have cache
>> coherent page table walkers (per the architecture), let's only
>> perform this cache maintenance on non-LPAE cores.
> 
> That statement doesn't stack up.  What about Cortex A15, which is a
> 32-bit core with LPAE support?  TI Keystone2 SoCs fall into this
> category.

As already documented in dcadda146f4fd25a732382747f306465d337cda6
("arm/kvm: excise redundant cache maintenance"):

<quote>
Per ARM DDI 0406C.c, section B1.7 ("The Virtualization Extensions"), the
virtualization extensions mandate the multiprocessing extensions.

Per ARM DDI 0406C.c, section B3.10.1 ("General TLB maintenance
requirements"), as described in the sub-section titled "TLB maintenance
operations and the memory order model", this maintenance is not required
in the presence of the multiprocessing extensions.
</quote>

Furthermore, as per B1.6 ("The Large Physical Address Extension") from
the same document:

<quote>
An implementation that includes the Large Physical Address Extension
must implement the Multiprocessing Extensions and therefore cannot
include the FCSE, see Use of the Fast Context Switch Extension on page
AppxI-2475.
</quote>

So on a core like Cortex A15 where we have both MP, VE and LPAE, we
should be able to assume a coherent page table walker.

Thanks,

	M.

> Sorry, but no, I don't think we can omit this cache flush on LPAE.


-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 11/12] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel
From: Jagan Teki @ 2018-12-10 16:12 UTC (permalink / raw)
  To: Thierry Reding, David Airlie
  Cc: Mark Rutland, devicetree, Jernej Skrabec, Maxime Ripard,
	linux-amarula, linux-sunxi, Maarten Lankhorst, linux-kernel,
	dri-devel, Vasily Khoruzhick, Chen-Yu Tsai, Rob Herring, TL Lim,
	Michael Trimarchi, Sean Paul, linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20181116163916.29621-12-jagan@amarulasolutions.com>

Hi Thierry and David,

On Fri, Nov 16, 2018 at 10:10 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
>
> Add panel driver for it.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>  MAINTAINERS                                   |   6 +
>  drivers/gpu/drm/panel/Kconfig                 |   9 +
>  drivers/gpu/drm/panel/Makefile                |   1 +
>  .../drm/panel/panel-feiyang-fy07024di26a30d.c | 286 ++++++++++++++++++
>  4 files changed, 302 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3dac08d0b3cb..40c8bfc974f4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4620,6 +4620,12 @@ T:       git git://anongit.freedesktop.org/drm/drm-misc
>  S:     Maintained
>  F:     drivers/gpu/drm/tve200/
>
> +DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS
> +M:     Jagan Teki <jagan@amarulasolutions.com>
> +S:     Maintained
> +F:     drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> +F:     Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
> +
>  DRM DRIVER FOR ILITEK ILI9225 PANELS
>  M:     David Lechner <david@lechnology.com>
>  S:     Maintained
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index d0d4e60f5153..bc70896fe43c 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -47,6 +47,15 @@ config DRM_PANEL_SIMPLE
>           that it can be automatically turned off when the panel goes into a
>           low power state.
>
> +config DRM_PANEL_FEIYANG_FY07024DI26A30D
> +       tristate "Feiyang FY07024DI26A30-D MIPI-DSI LCD panel"
> +       depends on OF
> +       depends on DRM_MIPI_DSI
> +       depends on BACKLIGHT_CLASS_DEVICE
> +       help
> +         Say Y if you want to enable support for panels based on the
> +         Feiyang FY07024DI26A30-D MIPI-DSI interface.
> +

Any comments on this?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v6 08/13] arm64: expose user PAC bit positions via ptrace
From: Catalin Marinas @ 2018-12-10 16:09 UTC (permalink / raw)
  To: Will Deacon
  Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Steve Capper,
	Marc Zyngier, Adam Wallis, Ard Biesheuvel, Richard Henderson,
	linux-kernel, Kristina Martsenko, Christoffer Dall,
	Cyrill Gorcunov, kvmarm, linux-arm-kernel, Ramana Radhakrishnan,
	Amit Kachhap, Dave P Martin, Suzuki K Poulose, Kees Cook
In-Reply-To: <20181210142944.GA13100@edgewater-inn.cambridge.arm.com>

On Mon, Dec 10, 2018 at 02:29:45PM +0000, Will Deacon wrote:
> On Mon, Dec 10, 2018 at 08:22:06AM -0600, Richard Henderson wrote:
> > On 12/10/18 6:03 AM, Catalin Marinas wrote:
> > >> However, it won't be too long before someone implements support for
> > >> ARMv8.2-LVA, at which point, without changes to mandatory pointer tagging, we
> > >> will only have 3 authentication bits: [54:52].  This seems useless and easily
> > >> brute-force-able.
[...]
> > Perhaps the opt-in should be at exec time, with ELF flags (or equivalent) on
> > the application.  Because, as you say, changing the shape of the PAC in the
> > middle of execution is in general not possible.
> 
> I think we'd still have a potential performance problem with that approach,
> since we'd end up having to context-switch TCR.T0SZ, which is permitted to
> be cached in a TLB and would therefore force us to introduce TLB
> invalidation when context-switching between tasks using 52-bit VAs and tasks
> using 48-bit VAs.
> 
> There's a chance we could get the architecture tightened here, but it's
> not something we've pushed for so far and it depends on what's already been
> built.

Just a quick summary of our internal discussion:

ARMv8.3 also comes with a new bit, TCR_EL1.TBIDx, which practically
disables TBI for code pointers. This bit allows us to use 11 bits for
code PtrAuth with 52-bit VA.

Now, the problem is that TBI for code pointers is user ABI, so we can't
simply disable it. We may be able to do this with memory tagging since
that's an opt-in feature (prctl) where the user is aware that the top
byte of a pointer is no longer ignored. However, that's probably for a
future discussion.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 00/12] arm64: Paravirtualized time support
From: Steven Price @ 2018-12-10 16:08 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Marc Zyngier, Catalin Marinas, Will Deacon, kvmarm,
	linux-arm-kernel
In-Reply-To: <20181210114047.tifwh6ilwzphsbqy@lakrids.cambridge.arm.com>

On 10/12/2018 11:40, Mark Rutland wrote:
> On Wed, Nov 28, 2018 at 02:45:15PM +0000, Steven Price wrote:
>> This series add support for paravirtualized time for Arm64 guests and
>> KVM hosts following the specification in Arm's document DEN 0057A:
>>
>> https://developer.arm.com/docs/den0057/a
>>
>> It implements support for Live Physical Time (LPT) which provides the
>> guest with a method to derive a stable counter of time during which the
>> guest is executing even when the guest is being migrated between hosts
>> with different physical counter frequencies.
>>
>> It also implements support for stolen time, allowing the guest to
>> identify time when it is forcibly not executing.
> 
> I know that stolen time reporting is important, and I think that we
> definitely want to pick up that part of the spec (once it is published
> in some non-draft form).
> 
> However, I am very concerned with the pv-freq part of LPT, and I'd like
> to avoid that if at all possible. I say that because:
> 
> * By design, it breaks architectural guarantees from the PoV of SW in
>   the guest.
> 
>   A VM may host multiple SW agents serially (e.g. when booting, or
>   across kexec), or concurrently (e.g. Linux w/ EFI runtime services),
>   and the host has no way to tell whether all software in the guest will
>   function correctly. Due to this, it's not possible to have a guest
>   opt-in to the architecturally-broken timekeeping.
> 
>   Existing guests will not work correctly once pv-freq is in use, and if
>   configured without pv-freq (or if the guest fails to discover pv-freq
>   for any reason), the administrator may encounter anything between
>   subtle breakage or fatally incorrect timekeeping.
> 
>   There's plenty of SW agents other than Linux which runs in a guest,
>   which would need to be updated to handle pv-freq, e.g. GRUB, *BSD,
>   iPXE.
> 
>   Given this, I think that this is going to lead to subtle breakage in
>   real-world scenarios. 

LPT only changes things on migration. Up until migration the
(architectural) clocks still behave perfectly normally. A guest which
opts in to LPT can derive a clock with a different frequency, but the
underlying clock doesn't change.

When migration happens it's a different story.

If the frequency of the new host matches the old host then again the
clocks behave 'normally': CNTVOFF is used to hide the change in offset
such that the guest at worst sees time pause during the actual migration.

But the whole point of LPT is to deal with the situation if the clock
frequency has changed. A guest (or SW agent) which doesn't know about PV
will experience one of two things:

* Without LPT: the clock frequency will suddenly change without warning,
but the virtual counter is monotonically increasing.

* With LPT: the clock frequency will suddenly change and the virtual
counter will jump (it won't be monotonically increasing).

So I agree the situation with LPT is worse (we lose the monotonicity),
but any guest/agent which didn't understand about the migration is in
trouble if it cares about time.

> * It is (necessarily) invasive to the low-level arch timer code. This is
>   unfortunate, and I strongly suspect this is going to be an area with
>   long-term subtle breakage.

I can't argue against that - I've tried to limit how invasive the code
changes are, but ultimately we're changing the interpretation of
low-level timers.

> * It's not clear to me how strongly people need this. My understanding
>   is that datacenters would run largely homogeneous platforms. I suspect
>   large datacenters which would use migration are in a position to
>   mandate a standard timer frequency from their OEMs or SiPs.
> 
>   I strongly believe that an architectural fix (e.g. in-hw scaling)
>   would be the better solution.

An architectural fix in hardware is clearly the best solution. The
question is whether we want to support the use-case with today's
hardware. While mandating a particular 'standard' timer frequency is a
good idea, there's currently no standard. Large datacenters might be
able to mandate that, and maybe there'll be sufficient consensus that
this doesn't matter. But I seem to have misplaced my crystal ball...

> I understand that LPT is supposed to account for time lost during the
> migration. Can we account for this without pv-freq? e.g. is it possible
> to account for this in the same way as stolen time?

LPT isn't really about accounting for the time lost (to some extent this
is already done by saving/restoring the "KVM_REG_ARM_TIMER_CNT"
register) but about ensuring that the guest can derive a monotonically
increasing counter which maintains a stable frequency when migrated.

I'm going to respin the series with the LPT parts split out to the end,
that way we can (hopefully) agree on the stolen time parts and can defer
the LPT part if necessary.

Thanks,

Steve

> Thanks,
> Mark.
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [linux-sunxi] Re: [PATCH v4 08/26] drm/sun4i: sun6i_mipi_dsi: Fix VBP size calculation
From: Jagan Teki @ 2018-12-10 16:07 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Mark Rutland, devicetree, Jernej Skrabec, David Airlie,
	Catalin Marinas, Michael Turquette, linux-sunxi, Will Deacon,
	linux-kernel, dri-devel, Vasily Khoruzhick, Stephen Boyd,
	Chen-Yu Tsai, Rob Herring, Michael Trimarchi, linux-amarula,
	linux-clk, linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20181207132136.oa4nzpczytzxhl2d@flea>

On Fri, Dec 7, 2018 at 6:51 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Tue, Nov 27, 2018 at 04:34:35PM +0530, Jagan Teki wrote:
> > On Tue, Nov 27, 2018 at 3:55 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Tue, Nov 20, 2018 at 09:55:42PM +0530, Jagan Teki wrote:
> > > > On Tue, Nov 20, 2018 at 9:27 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > >
> > > > > On Thu, Nov 15, 2018 at 11:19:53PM +0530, Jagan Teki wrote:
> > > > > > On Thu, Nov 15, 2018 at 3:26 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Tue, Nov 13, 2018 at 04:46:15PM +0530, Jagan Teki wrote:
> > > > > > > > The horizontal and vertical back porch calculation in BSP
> > > > > > > > code is simply following the Linux drm comment diagram, in
> > > > > > > > include/drm/drm_modes.h which is
> > > > > > > >
> > > > > > > > [hv]back porch = [hv]total - [hv]sync_end
> > > > > > > >
> > > > > > > > BSP code form BPI-M64-bsp is calculating vertical back porch as
> > > > > > > > (from linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c)
> > > > > > > >
> > > > > > > > timmings->ver_sync_time= panel_info->lcd_vspw;
> > > > > > > > timmings->ver_back_porch= panel_info->lcd_vbp-panel_info->lcd_vspw;
> > > > > > > >
> > > > > > > > vbp = panel->lcd_vbp;
> > > > > > > > vspw = panel->lcd_vspw;
> > > > > > > > dsi_dev[sel]->dsi_basic_size0.bits.vbp = vbp-vspw;
> > > > > > > > dsi_dev[sel]->dsi_basic_size0.bits.vbp = panel->lcd_vbp - panel->lcd_vspw;
> > > > > > > > =>  timmings->ver_back_porch + panel_info->lcd_vspw - panel_info->lcd_vspw
> > > > > > > > =>  timmings->ver_back_porch
> > > > > > > > =>  mode->vtotal - mode->end
> > > > > > > >
> > > > > > > > Which evatually same as mode->vtotal - mode->vsync_end so update the
> > > > > > > > same in SUN6I_DSI_BASIC_SIZE0_VBP
> > > > > > > >
> > > > > > > > On the information note, existing SUN6I_DSI_BASIC_SIZE0_VSA is proper
> > > > > > > > value.
> > > > > > > >
> > > > > > > > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > > > >
> > > > > > > I've tested your changes on my A33 board, and this commit will break
> > > > > > > it.
> > > > > > >
> > > > > > > It creates vblank timeouts, and visual artifacts at the bottom of the
> > > > > > > display.
> > > > > >
> > > > > > Strange, VBP is earlier gives front porch which is anyway wrong.
> > > > > >
> > > > > > >
> > > > > > > Later commits seem to fix the issue, but will create some blanking on
> > > > > > > the upper third of the display.
> > > > > > >
> > > > > > > Since the documentation is quite sparse, and a MIPI-DSI analyzer is
> > > > > > > way too expensive, I'd really like to have at least what each of these
> > > > > > > commits are actually fixing, and what symptoms each of these were
> > > > > > > causing, and not just "the BSP does it".
> > > > > >
> > > > > > W/o this 2-lane panel is breaking, same vblank timeout and visual
> > > > > > artifacts at the bottom of the panel. though the commits may reference
> > > > > > BSP, I have at-least tested on 3 different panels for us to prove its
> > > > > > working.
> > > > > >
> > > > > > > Having some datasheet for the panels you had working would help too.
> > > > > >
> > > > > > Unfortunately datasheet doesn't have any required information what we
> > > > > > actually looking for.
> > > > >
> > > > > Not even the timings? How did you get that information then?
> > > >
> > > > datasheet has timing values, but this changes need controller
> > > > information about VBP register that I don't have. But again existing
> > > > VBP is not back porch for real, it's front porch.
> > >
> > > Yet, this breaks the existing setup. So again:
> >
> > Was it with 4-lane or 2-lane panel? can you test it with 2-lane panel?
> > I can see the issue on 2-lane but the 4-lane working fine with this
> > patch even.
>
> It's a 4 lane display.

Thanks, look like my panel timings seems reverse b/w BP and FP. It
work irrespective of this change after proper update.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH RESEND v7 4/4] clk: meson: add one based divider support for sclk divider
From: Jianxin Pan @ 2018-12-10 16:04 UTC (permalink / raw)
  To: Jerome Brunet, Neil Armstrong
  Cc: Rob Herring, Hanjie Lin, Victor Wan, Jianxin Pan, Stephen Boyd,
	Kevin Hilman, Michael Turquette, Yixun Lan, linux-kernel,
	Boris Brezillon, Liang Yang, Jian Hu, Miquel Raynal, Carlo Caione,
	linux-amlogic, Martin Blumenstingl, linux-clk, linux-arm-kernel,
	Qiufang Dai
In-Reply-To: <1544457877-51301-1-git-send-email-jianxin.pan@amlogic.com>

When CLK_DIVIDER_ONE_BASED flag is set, the sclk divider will be:
one based divider (div = val), and zero value gates the clock

Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
---
 drivers/clk/meson/clkc-audio.h |  1 +
 drivers/clk/meson/sclk-div.c   | 28 ++++++++++++++++++----------
 2 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/clk/meson/clkc-audio.h b/drivers/clk/meson/clkc-audio.h
index 0a7c157..9bd6ced 100644
--- a/drivers/clk/meson/clkc-audio.h
+++ b/drivers/clk/meson/clkc-audio.h
@@ -20,6 +20,7 @@ struct meson_sclk_div_data {
 	struct parm hi;
 	unsigned int cached_div;
 	struct clk_duty cached_duty;
+	u8	flags;
 };
 
 extern const struct clk_ops meson_clk_triphase_ops;
diff --git a/drivers/clk/meson/sclk-div.c b/drivers/clk/meson/sclk-div.c
index bc64019..d98707b 100644
--- a/drivers/clk/meson/sclk-div.c
+++ b/drivers/clk/meson/sclk-div.c
@@ -24,22 +24,23 @@
 	return (struct meson_sclk_div_data *)clk->data;
 }
 
-static int sclk_div_maxval(struct meson_sclk_div_data *sclk)
-{
-	return (1 << sclk->div.width) - 1;
-}
-
 static int sclk_div_maxdiv(struct meson_sclk_div_data *sclk)
 {
-	return sclk_div_maxval(sclk) + 1;
+	if (sclk->flags & CLK_DIVIDER_ONE_BASED)
+		return clk_div_mask(sclk->div.width);
+	else
+		return clk_div_mask(sclk->div.width) + 1;
 }
 
 static int sclk_div_getdiv(struct clk_hw *hw, unsigned long rate,
 			   unsigned long prate, int maxdiv)
 {
 	int div = DIV_ROUND_CLOSEST_ULL((u64)prate, rate);
+	struct clk_regmap *clk = to_clk_regmap(hw);
+	struct meson_sclk_div_data *sclk = meson_sclk_div_data(clk);
+	int mindiv = (sclk->flags & CLK_DIVIDER_ONE_BASED) ? 1 : 2;
 
-	return clamp(div, 2, maxdiv);
+	return clamp(div, mindiv, maxdiv);
 }
 
 static int sclk_div_bestdiv(struct clk_hw *hw, unsigned long rate,
@@ -47,7 +48,7 @@ static int sclk_div_bestdiv(struct clk_hw *hw, unsigned long rate,
 			    struct meson_sclk_div_data *sclk)
 {
 	struct clk_hw *parent = clk_hw_get_parent(hw);
-	int bestdiv = 0, i;
+	int bestdiv = 0, i, mindiv;
 	unsigned long maxdiv, now, parent_now;
 	unsigned long best = 0, best_parent = 0;
 
@@ -64,8 +65,9 @@ static int sclk_div_bestdiv(struct clk_hw *hw, unsigned long rate,
 	 * unsigned long in rate * i below
 	 */
 	maxdiv = min(ULONG_MAX / rate, maxdiv);
+	mindiv = (sclk->flags & CLK_DIVIDER_ONE_BASED) ? 1 : 2;
 
-	for (i = 2; i <= maxdiv; i++) {
+	for (i = mindiv; i <= maxdiv; i++) {
 		/*
 		 * It's the most ideal case if the requested rate can be
 		 * divided from parent clock without needing to change
@@ -153,10 +155,14 @@ static int sclk_div_get_duty_cycle(struct clk_hw *hw,
 static void sclk_apply_divider(struct clk_regmap *clk,
 			       struct meson_sclk_div_data *sclk)
 {
+	unsigned int div;
+
 	if (MESON_PARM_APPLICABLE(&sclk->hi))
 		sclk_apply_ratio(clk, sclk);
 
-	meson_parm_write(clk->map, &sclk->div, sclk->cached_div - 1);
+	div = (sclk->flags & CLK_DIVIDER_ONE_BASED) ?
+		sclk->cached_div : (sclk->cached_div - 1);
+	meson_parm_write(clk->map, &sclk->div, div);
 }
 
 static int sclk_div_set_rate(struct clk_hw *hw, unsigned long rate,
@@ -223,6 +229,8 @@ static void sclk_div_init(struct clk_hw *hw)
 	/* if the divider is initially disabled, assume max */
 	if (!val)
 		sclk->cached_div = sclk_div_maxdiv(sclk);
+	else if (sclk->flags & CLK_DIVIDER_ONE_BASED)
+		sclk->cached_div = val;
 	else
 		sclk->cached_div = val + 1;
 
-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH RESEND v7 3/4] clk: meson: add sub MMC clock controller driver
From: Jianxin Pan @ 2018-12-10 16:04 UTC (permalink / raw)
  To: Jerome Brunet, Neil Armstrong
  Cc: Rob Herring, Hanjie Lin, Victor Wan, Jianxin Pan, Stephen Boyd,
	Kevin Hilman, Michael Turquette, Yixun Lan, linux-kernel,
	Boris Brezillon, Liang Yang, Jian Hu, Miquel Raynal, Carlo Caione,
	linux-amlogic, Martin Blumenstingl, linux-clk, linux-arm-kernel,
	Qiufang Dai
In-Reply-To: <1544457877-51301-1-git-send-email-jianxin.pan@amlogic.com>

From: Yixun Lan <yixun.lan@amlogic.com>

The patch will add a MMC clock controller driver which used by MMC or NAND,
It provide a mux and divider clock, and three phase clocks - core, tx, tx.

Two clocks are provided as the parent of MMC clock controller from
upper layer clock controller - eg "amlogic,axg-clkc" in AXG platform.

To specify which clock the MMC or NAND driver may consume,
the preprocessor macros in the dt-bindings/clock/amlogic,mmc-clkc.h header
can be used in the device tree sources.

Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
---
 drivers/clk/meson/Kconfig    |  10 ++
 drivers/clk/meson/Makefile   |   1 +
 drivers/clk/meson/mmc-clkc.c | 313 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 324 insertions(+)
 create mode 100644 drivers/clk/meson/mmc-clkc.c

diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index efaa70f..6bb0d44 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -15,6 +15,16 @@ config COMMON_CLK_MESON_AO
 	select COMMON_CLK_REGMAP_MESON
 	select RESET_CONTROLLER
 
+config COMMON_CLK_MMC_MESON
+	tristate "Meson MMC Sub Clock Controller Driver"
+	select MFD_SYSCON
+	select COMMON_CLK_AMLOGIC
+	select COMMON_CLK_AMLOGIC_AUDIO
+	help
+	  Support for the MMC sub clock controller on Amlogic Meson Platform,
+	  which include S905 (GXBB, GXL), A113D/X (AXG) devices.
+	  Say Y if you want this clock enabled.
+
 config COMMON_CLK_REGMAP_MESON
 	bool
 	select REGMAP
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 39ce566..31c16d5 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -9,4 +9,5 @@ obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
 obj-$(CONFIG_COMMON_CLK_GXBB)	 += gxbb.o gxbb-aoclk.o gxbb-aoclk-32k.o
 obj-$(CONFIG_COMMON_CLK_AXG)	 += axg.o axg-aoclk.o
 obj-$(CONFIG_COMMON_CLK_AXG_AUDIO)	+= axg-audio.o
+obj-$(CONFIG_COMMON_CLK_MMC_MESON) 	+= mmc-clkc.o
 obj-$(CONFIG_COMMON_CLK_REGMAP_MESON)	+= clk-regmap.o
diff --git a/drivers/clk/meson/mmc-clkc.c b/drivers/clk/meson/mmc-clkc.c
new file mode 100644
index 0000000..f5a79a4
--- /dev/null
+++ b/drivers/clk/meson/mmc-clkc.c
@@ -0,0 +1,313 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Amlogic Meson MMC Sub Clock Controller Driver
+ *
+ * Copyright (c) 2017 Baylibre SAS.
+ * Author: Jerome Brunet <jbrunet@baylibre.com>
+ *
+ * Copyright (c) 2018 Amlogic, inc.
+ * Author: Yixun Lan <yixun.lan@amlogic.com>
+ * Author: Jianxin Pan <jianxin.pan@amlogic.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/of_device.h>
+#include <linux/mfd/syscon.h>
+#include <linux/platform_device.h>
+#include <dt-bindings/clock/amlogic,mmc-clkc.h>
+
+#include "clkc.h"
+#include "clkc-audio.h"
+
+/* clock ID used by internal driver */
+#define CLKID_MMC_MUX			0
+
+#define   SD_EMMC_CLOCK		0
+#define   CLK_DELAY_STEP_PS		200
+
+#define MUX_CLK_NUM_PARENTS		2
+#define MMC_MAX_CLKS			5
+
+struct mmc_clkc_data {
+	struct meson_clk_phase_delay_data	tx;
+	struct meson_clk_phase_delay_data	rx;
+};
+
+static struct clk_regmap_mux_data mmc_clkc_mux_data = {
+	.offset		= SD_EMMC_CLOCK,
+	.mask		= 0x3,
+	.shift		= 6,
+};
+
+static const struct meson_sclk_div_data mmc_clkc_div_data = {
+	.div = {
+		.reg_off = SD_EMMC_CLOCK,
+		.shift   = (0),
+		.width   = (6),
+	},
+	.hi = {
+		.width   = 0,
+	},
+	.flags = CLK_DIVIDER_ONE_BASED,
+};
+
+static struct meson_clk_phase_data mmc_clkc_core_phase = {
+	.ph = {
+		.reg_off	= SD_EMMC_CLOCK,
+		.shift	= 8,
+		.width	= 2,
+	}
+};
+
+static const struct mmc_clkc_data mmc_clkc_gx_data = {
+	.tx = {
+		.phase = {
+			.reg_off	= SD_EMMC_CLOCK,
+			.shift	= 10,
+			.width	= 2,
+		},
+		.delay = {
+			.reg_off	= SD_EMMC_CLOCK,
+			.shift	= 16,
+			.width	= 4,
+		},
+		.delay_step_ps	= CLK_DELAY_STEP_PS,
+	},
+	.rx = {
+		.phase = {
+			.reg_off	= SD_EMMC_CLOCK,
+			.shift	= 12,
+			.width	= 2,
+		},
+		.delay = {
+			.reg_off	= SD_EMMC_CLOCK,
+			.shift	= 20,
+			.width	= 4,
+		},
+		.delay_step_ps	= CLK_DELAY_STEP_PS,
+	},
+};
+
+static const struct mmc_clkc_data mmc_clkc_axg_data = {
+	.tx = {
+		.phase = {
+			.reg_off	= SD_EMMC_CLOCK,
+			.shift	= 10,
+			.width	= 2,
+		},
+		.delay = {
+			.reg_off	= SD_EMMC_CLOCK,
+			.shift	= 16,
+			.width	= 6,
+		},
+		.delay_step_ps	= CLK_DELAY_STEP_PS,
+	},
+	.rx = {
+		.phase = {
+			.reg_off	= SD_EMMC_CLOCK,
+			.shift	= 12,
+			.width	= 2,
+		},
+		.delay = {
+			.reg_off	= SD_EMMC_CLOCK,
+			.shift	= 22,
+			.width	= 6,
+		},
+		.delay_step_ps	= CLK_DELAY_STEP_PS,
+	},
+};
+
+static const struct of_device_id mmc_clkc_match_table[] = {
+	{
+		.compatible	= "amlogic,gx-mmc-clkc",
+		.data		= &mmc_clkc_gx_data
+	},
+	{
+		.compatible	= "amlogic,axg-mmc-clkc",
+		.data		= &mmc_clkc_axg_data
+	},
+	{}
+};
+MODULE_DEVICE_TABLE(of, mmc_clkc_match_table);
+
+static struct clk_regmap *
+mmc_clkc_register_clk(struct device *dev, struct regmap *map,
+		      struct clk_init_data *init,
+		      const char *suffix, void *data)
+{
+	struct clk_regmap *clk;
+	char *name;
+	int ret;
+
+	clk = devm_kzalloc(dev, sizeof(*clk), GFP_KERNEL);
+	if (!clk)
+		return ERR_PTR(-ENOMEM);
+
+	name = kasprintf(GFP_KERNEL, "%s#%s", dev_name(dev), suffix);
+	if (!name)
+		return ERR_PTR(-ENOMEM);
+
+	init->name = name;
+
+	clk->map = map;
+	clk->data = data;
+	clk->hw.init = init;
+
+	ret = devm_clk_hw_register(dev, &clk->hw);
+	if (ret)
+		clk = ERR_PTR(ret);
+
+	kfree(name);
+	return clk;
+}
+
+static struct clk_regmap *mmc_clkc_register_mux(struct device *dev,
+						struct regmap *map)
+{
+	const char *parent_names[MUX_CLK_NUM_PARENTS];
+	struct clk_init_data init;
+	struct clk_regmap *mux;
+	struct clk *clk;
+	int i;
+
+	for (i = 0; i < MUX_CLK_NUM_PARENTS; i++) {
+		char name[8];
+
+		snprintf(name, sizeof(name), "clkin%d", i);
+		clk = devm_clk_get(dev, name);
+		if (IS_ERR(clk)) {
+			if (clk != ERR_PTR(-EPROBE_DEFER))
+				dev_err(dev, "Missing clock %s\n", name);
+			return ERR_PTR((long)clk);
+		}
+
+		parent_names[i] = __clk_get_name(clk);
+	}
+
+	init.ops = &clk_regmap_mux_ops;
+	init.flags = CLK_SET_RATE_PARENT;
+	init.parent_names = parent_names;
+	init.num_parents = MUX_CLK_NUM_PARENTS;
+
+	mux = mmc_clkc_register_clk(dev, map, &init, "mux", &mmc_clkc_mux_data);
+	if (IS_ERR(mux))
+		dev_err(dev, "Mux clock registration failed\n");
+
+	return mux;
+}
+
+static struct clk_regmap *
+mmc_clkc_register_clk_with_parent(struct device *dev, struct regmap *map,
+				  char *suffix, const struct clk_hw *hw,
+				  unsigned long flags,
+				  const struct clk_ops *ops, void *data)
+{
+	struct clk_init_data init;
+	struct clk_regmap *clk;
+	const char *parent_name = clk_hw_get_name(hw);
+
+	init.ops = ops;
+	init.flags = flags;
+	init.parent_names = &parent_name;
+	init.num_parents = 1;
+
+	clk = mmc_clkc_register_clk(dev, map, &init, suffix, data);
+	if (IS_ERR(clk))
+		dev_err(dev, "Core %s clock registration failed\n", suffix);
+
+	return clk;
+}
+
+static int mmc_clkc_probe(struct platform_device *pdev)
+{
+	struct clk_hw_onecell_data *onecell_data;
+	struct device *dev = &pdev->dev;
+	struct mmc_clkc_data *data;
+	struct regmap *map;
+	struct clk_regmap *clk, *core;
+	struct meson_sclk_div_data *div_data;
+
+	/*cast to drop the const in match->data*/
+	data = (struct mmc_clkc_data *)of_device_get_match_data(dev);
+	if (!data)
+		return -ENODEV;
+
+	map = syscon_node_to_regmap(dev->of_node);
+	if (IS_ERR(map)) {
+		dev_err(dev, "could not find mmc clock controller\n");
+		return PTR_ERR(map);
+	}
+
+	onecell_data = devm_kzalloc(dev, sizeof(*onecell_data) +
+				    sizeof(*onecell_data->hws) * MMC_MAX_CLKS,
+				    GFP_KERNEL);
+	if (!onecell_data)
+		return -ENOMEM;
+
+	clk = mmc_clkc_register_mux(dev, map);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+	onecell_data->hws[CLKID_MMC_MUX]		= &clk->hw,
+
+	div_data = devm_kzalloc(dev, sizeof(*div_data), GFP_KERNEL);
+	if (!div_data)
+		return -ENOMEM;
+	*div_data = mmc_clkc_div_data;
+
+	clk = mmc_clkc_register_clk_with_parent(dev, map, "div",
+						&clk->hw,
+						CLK_SET_RATE_PARENT,
+						&meson_sclk_div_ops,
+						div_data);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+	onecell_data->hws[CLKID_MMC_DIV]		= &clk->hw,
+
+	core = mmc_clkc_register_clk_with_parent(dev, map, "core",
+						 &clk->hw,
+						 CLK_SET_RATE_PARENT,
+						 &meson_clk_phase_ops,
+						 &mmc_clkc_core_phase);
+	if (IS_ERR(core))
+		return PTR_ERR(core);
+	onecell_data->hws[CLKID_MMC_PHASE_CORE]		= &core->hw,
+
+	clk = mmc_clkc_register_clk_with_parent(dev, map, "rx",
+						&core->hw,  0,
+						&meson_clk_phase_delay_ops,
+						&data->rx);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+	onecell_data->hws[CLKID_MMC_PHASE_RX]		= &clk->hw,
+
+	clk = mmc_clkc_register_clk_with_parent(dev, map, "tx",
+						&core->hw,  0,
+						&meson_clk_phase_delay_ops,
+						&data->tx);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+	onecell_data->hws[CLKID_MMC_PHASE_TX]		= &clk->hw,
+
+	onecell_data->num				= MMC_MAX_CLKS;
+
+	return devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
+					   onecell_data);
+}
+
+static struct platform_driver mmc_clkc_driver = {
+	.probe		= mmc_clkc_probe,
+	.driver		= {
+		.name	= "meson-mmc-clkc",
+		.of_match_table = of_match_ptr(mmc_clkc_match_table),
+	},
+};
+
+module_platform_driver(mmc_clkc_driver);
+
+MODULE_DESCRIPTION("Amlogic AXG MMC clock driver");
+MODULE_AUTHOR("Jianxin Pan <jianxin.pan@amlogic.com>");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH RESEND v7 2/4] clk: meson: add DT documentation for emmc clock controller
From: Jianxin Pan @ 2018-12-10 16:04 UTC (permalink / raw)
  To: Jerome Brunet, Neil Armstrong
  Cc: Rob Herring, Hanjie Lin, Victor Wan, Jianxin Pan, Stephen Boyd,
	Kevin Hilman, Michael Turquette, Yixun Lan, linux-kernel,
	Boris Brezillon, Liang Yang, Jian Hu, Miquel Raynal, Carlo Caione,
	linux-amlogic, Martin Blumenstingl, linux-clk, linux-arm-kernel,
	Qiufang Dai
In-Reply-To: <1544457877-51301-1-git-send-email-jianxin.pan@amlogic.com>

From: Yixun Lan <yixun.lan@amlogic.com>

Document the MMC sub clock controller driver, the potential consumer
of this driver is MMC or NAND. Also add four clock bindings IDs which
provided by this driver.

Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
---
 .../devicetree/bindings/clock/amlogic,mmc-clkc.txt | 39 ++++++++++++++++++++++
 include/dt-bindings/clock/amlogic,mmc-clkc.h       | 17 ++++++++++
 2 files changed, 56 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
 create mode 100644 include/dt-bindings/clock/amlogic,mmc-clkc.h

diff --git a/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt b/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
new file mode 100644
index 0000000..0f518e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
@@ -0,0 +1,39 @@
+* Amlogic MMC Sub Clock Controller Driver
+
+The Amlogic MMC clock controller generates and supplies clock to support
+MMC and NAND controller
+
+Required Properties:
+
+- compatible: should be:
+		"amlogic,gx-mmc-clkc"
+		"amlogic,axg-mmc-clkc"
+
+- #clock-cells: should be 1.
+- clocks: phandles to clocks corresponding to the clock-names property
+- clock-names: list of parent clock names
+	- "clkin0", "clkin1"
+
+- reg: address of emmc sub clock register
+
+Example: Clock controller node:
+
+sd_mmc_c_clkc: clock-controller@7000 {
+	compatible = "amlogic,axg-mmc-clkc", "syscon";
+	reg = <0x0 0x7000 0x0 0x4>;
+	#clock-cells = <1>;
+
+	clock-names = "clkin0", "clkin1";
+	clocks = <&clkc CLKID_SD_MMC_C_CLK0>,
+		 <&clkc CLKID_FCLK_DIV2>;
+};
+
+sd_emmc_b_clkc: clock-controller@5000 {
+	compatible = "amlogic,axg-mmc-clkc", "syscon";
+	reg = <0x0 0x5000 0x0 0x4>;
+
+	#clock-cells = <1>;
+	clock-names = "clkin0", "clkin1";
+	clocks = <&clkc CLKID_SD_EMMC_B_CLK0>,
+		 <&clkc CLKID_FCLK_DIV2>;
+};
diff --git a/include/dt-bindings/clock/amlogic,mmc-clkc.h b/include/dt-bindings/clock/amlogic,mmc-clkc.h
new file mode 100644
index 0000000..162b949
--- /dev/null
+++ b/include/dt-bindings/clock/amlogic,mmc-clkc.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
+/*
+ * Meson MMC sub clock tree IDs
+ *
+ * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
+ * Author: Yixun Lan <yixun.lan@amlogic.com>
+ */
+
+#ifndef __MMC_CLKC_H
+#define __MMC_CLKC_H
+
+#define CLKID_MMC_DIV				1
+#define CLKID_MMC_PHASE_CORE			2
+#define CLKID_MMC_PHASE_TX			3
+#define CLKID_MMC_PHASE_RX			4
+
+#endif
-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH RESEND v7 1/4] clk: meson: add emmc sub clock phase delay driver
From: Jianxin Pan @ 2018-12-10 16:04 UTC (permalink / raw)
  To: Jerome Brunet, Neil Armstrong
  Cc: Rob Herring, Hanjie Lin, Victor Wan, Jianxin Pan, devicetree,
	Stephen Boyd, Kevin Hilman, Michael Turquette, Yixun Lan,
	linux-kernel, Boris Brezillon, Liang Yang, Jian Hu, Miquel Raynal,
	Carlo Caione, linux-amlogic, Martin Blumenstingl, linux-clk,
	linux-arm-kernel, Qiufang Dai
In-Reply-To: <1544457877-51301-1-git-send-email-jianxin.pan@amlogic.com>

From: Yixun Lan <yixun.lan@amlogic.com>

Export the emmc sub clock phase delay ops which will be used
by the emmc sub clock driver itself.

Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
---
 drivers/clk/meson/Makefile          |  2 +-
 drivers/clk/meson/clk-phase-delay.c | 64 +++++++++++++++++++++++++++++++++++++
 drivers/clk/meson/clkc.h            | 13 ++++++++
 3 files changed, 78 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/meson/clk-phase-delay.c

diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 72ec8c4..39ce566 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -2,7 +2,7 @@
 # Makefile for Meson specific clk
 #
 
-obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-pll.o clk-mpll.o clk-phase.o
+obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-pll.o clk-mpll.o clk-phase.o clk-phase-delay.o
 obj-$(CONFIG_COMMON_CLK_AMLOGIC_AUDIO)	+= clk-triphase.o sclk-div.o
 obj-$(CONFIG_COMMON_CLK_MESON_AO) += meson-aoclk.o
 obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
diff --git a/drivers/clk/meson/clk-phase-delay.c b/drivers/clk/meson/clk-phase-delay.c
new file mode 100644
index 0000000..84e7b63
--- /dev/null
+++ b/drivers/clk/meson/clk-phase-delay.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Amlogic Meson MMC Sub Clock Controller Driver
+ *
+ * Copyright (c) 2017 Baylibre SAS.
+ * Author: Jerome Brunet <jbrunet@baylibre.com>
+ *
+ * Copyright (c) 2018 Amlogic, inc.
+ * Author: Yixun Lan <yixun.lan@amlogic.com>
+ * Author: Jianxin Pan <jianxin.pan@amlogic.com>
+ */
+
+#include <linux/clk-provider.h>
+#include "clkc.h"
+
+static int meson_clk_phase_delay_get_phase(struct clk_hw *hw)
+{
+	struct clk_regmap *clk = to_clk_regmap(hw);
+	struct meson_clk_phase_delay_data *ph;
+	unsigned long period_ps, p, d;
+	int degrees;
+
+	ph = meson_clk_get_phase_delay_data(clk);
+	p = meson_parm_read(clk->map, &ph->phase);
+	degrees = p * 360 / (1 << (ph->phase.width));
+
+	period_ps = DIV_ROUND_UP(NSEC_PER_SEC * 1000,
+				 clk_hw_get_rate(hw));
+
+	d = meson_parm_read(clk->map, &ph->delay);
+	degrees += d * ph->delay_step_ps * 360 / period_ps;
+	degrees %= 360;
+
+	return degrees;
+}
+
+static int meson_clk_phase_delay_set_phase(struct clk_hw *hw, int degrees)
+{
+	struct clk_regmap *clk = to_clk_regmap(hw);
+	struct meson_clk_phase_delay_data *ph;
+	unsigned long period_ps, d = 0, r;
+
+	ph = meson_clk_get_phase_delay_data(clk);
+	period_ps = DIV_ROUND_UP(NSEC_PER_SEC * 1000, clk_hw_get_rate(hw));
+
+	/*
+	 * First compute the phase index (p), the remainder (r) is the
+	 * part we'll try to acheive using the delays (d).
+	 */
+	r = do_div(degrees, 360 / 1 << (ph->phase.width));
+	d = DIV_ROUND_CLOSEST(r * period_ps,
+			      360 * ph->delay_step_ps);
+	d = min(d, PMASK(ph->delay.width));
+
+	meson_parm_write(clk->map, &ph->phase, degrees);
+	meson_parm_write(clk->map, &ph->delay, d);
+	return 0;
+}
+
+const struct clk_ops meson_clk_phase_delay_ops = {
+	.get_phase = meson_clk_phase_delay_get_phase,
+	.set_phase = meson_clk_phase_delay_set_phase,
+};
+EXPORT_SYMBOL_GPL(meson_clk_phase_delay_ops);
diff --git a/drivers/clk/meson/clkc.h b/drivers/clk/meson/clkc.h
index 6b96d55..30470c6 100644
--- a/drivers/clk/meson/clkc.h
+++ b/drivers/clk/meson/clkc.h
@@ -105,6 +105,18 @@ struct clk_regmap _name = {						\
 	},								\
 };
 
+struct meson_clk_phase_delay_data {
+	struct parm			phase;
+	struct parm			delay;
+	unsigned int			delay_step_ps;
+};
+
+static inline struct meson_clk_phase_delay_data *
+meson_clk_get_phase_delay_data(struct clk_regmap *clk)
+{
+	return clk->data;
+}
+
 /* clk_ops */
 extern const struct clk_ops meson_clk_pll_ro_ops;
 extern const struct clk_ops meson_clk_pll_ops;
@@ -112,5 +124,6 @@ struct clk_regmap _name = {						\
 extern const struct clk_ops meson_clk_mpll_ro_ops;
 extern const struct clk_ops meson_clk_mpll_ops;
 extern const struct clk_ops meson_clk_phase_ops;
+extern const struct clk_ops meson_clk_phase_delay_ops;
 
 #endif /* __CLKC_H */
-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH RESEND v7 0/4] clk: meson: add a sub EMMC clock controller support
From: Jianxin Pan @ 2018-12-10 16:04 UTC (permalink / raw)
  To: Jerome Brunet, Neil Armstrong
  Cc: Rob Herring, Hanjie Lin, Victor Wan, Jianxin Pan, devicetree,
	Stephen Boyd, Kevin Hilman, Michael Turquette, Yixun Lan,
	linux-kernel, Boris Brezillon, Liang Yang, Jian Hu, Miquel Raynal,
	Carlo Caione, linux-amlogic, Martin Blumenstingl, linux-clk,
	linux-arm-kernel, Qiufang Dai

This driver will add a MMC clock controller driver support.
The original idea about adding a clock controller is during the
discussion in the NAND driver mainline effort[1].

This driver is tested in the S400 board (AXG platform) with NAND driver.

Changes since v6 [7]:
 - add one based support for sclk divier
 - alloc sclk in probe for multiple instance
 - fix coding styles

Changes since v5 [6]:
 - remove divider ops with .init and use sclk_div instead
 - drop CLK_DIVIDER_ROUND_CLOSEST in mux and div
 - drop the useless type cast 

Changes since v4 [5]:
 - use struct parm in phase delay driver
 - remove 0 delay releted part in phase delay driver
 - don't rebuild the parent name once again
 - add divider ops with .init

Changes since v3 [4]:
 - separate clk-phase-delay driver
 - replace clk_get_rate() with clk_hw_get_rate()
 - collect Rob's R-Y
 - drop 'meson-' prefix from compatible string

 Changes since v2 [3]:
 - squash dt-binding clock-id patch
 - update license
 - fix alignment
 - construct a clk register helper() function

Changes since v1 [2]:
 - implement phase clock
 - update compatible name
 - adjust file name
 - divider probe() into small functions, and re-use them

[1] https://lkml.kernel.org/r/20180628090034.0637a062@xps13
[2] https://lkml.kernel.org/r/20180703145716.31860-1-yixun.lan@amlogic.com
[3] https://lkml.kernel.org/r/20180710163658.6175-1-yixun.lan@amlogic.com
[4] https://lkml.kernel.org/r/20180712211244.11428-1-yixun.lan@amlogic.com
[5] https://lkml.kernel.org/r/20180809070724.11935-4-yixun.lan@amlogic.com
[6] https://lkml.kernel.org/r/1539839245-13793-1-git-send-email-jianxin.pan@amlogic.com
[7] https://lkml.kernel.org/r/1541089855-19356-1-git-send-email-jianxin.pan@amlogic.com
Yixun Lan (3):
  clk: meson: add emmc sub clock phase delay driver
  clk: meson: add DT documentation for emmc clock controller
  clk: meson: add sub MMC clock controller driver
  clk: meson: add one based divider support for sclk divider

 .../devicetree/bindings/clock/amlogic,mmc-clkc.txt |  39 +++
 drivers/clk/meson/Kconfig                          |  10 +
 drivers/clk/meson/Makefile                         |   3 +-
 drivers/clk/meson/clk-phase-delay.c                |  64 +++++
 drivers/clk/meson/clkc-audio.h                     |   1 +
 drivers/clk/meson/clkc.h                           |  13 +
 drivers/clk/meson/mmc-clkc.c                       | 313 +++++++++++++++++++++
 drivers/clk/meson/sclk-div.c                       |  28 +-
 include/dt-bindings/clock/amlogic,mmc-clkc.h       |  17 ++
 9 files changed, 477 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
 create mode 100644 drivers/clk/meson/clk-phase-delay.c
 create mode 100644 drivers/clk/meson/mmc-clkc.c
 create mode 100644 include/dt-bindings/clock/amlogic,mmc-clkc.h

-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH V5 5/7] arm64: mm: Prevent mismatched 52-bit VA support
From: Steve Capper @ 2018-12-10 16:04 UTC (permalink / raw)
  To: Will Deacon
  Cc: ard.biesheuvel@linaro.org, Catalin Marinas, Suzuki Poulose,
	linux-mm@kvack.org, jcm@redhat.com, nd,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181210133640.GA31425@edgewater-inn.cambridge.arm.com>

On Mon, Dec 10, 2018 at 01:36:40PM +0000, Will Deacon wrote:
> On Fri, Dec 07, 2018 at 05:28:58PM +0000, Suzuki K Poulose wrote:
> > 
> > 
> > On 07/12/2018 15:26, Will Deacon wrote:
> > > On Fri, Dec 07, 2018 at 10:47:57AM +0000, Suzuki K Poulose wrote:
> > > > On 12/06/2018 10:50 PM, Steve Capper wrote:
> > > > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > > > > index f60081be9a1b..58fcc1edd852 100644
> > > > > --- a/arch/arm64/kernel/head.S
> > > > > +++ b/arch/arm64/kernel/head.S
> > > > > @@ -707,6 +707,7 @@ secondary_startup:
> > > > >    	/*
> > > > >    	 * Common entry point for secondary CPUs.
> > > > >    	 */
> > > > > +	bl	__cpu_secondary_check52bitva
> > > > >    	bl	__cpu_setup			// initialise processor
> > > > >    	adrp	x1, swapper_pg_dir
> > > > >    	bl	__enable_mmu
> > > > > @@ -785,6 +786,31 @@ ENTRY(__enable_mmu)
> > > > >    	ret
> > > > >    ENDPROC(__enable_mmu)
> > > > > +ENTRY(__cpu_secondary_check52bitva)
> > > > > +#ifdef CONFIG_ARM64_52BIT_VA
> > > > > +	ldr_l	x0, vabits_user
> > > > > +	cmp	x0, #52
> > > > > +	b.ne	2f > +
> > > > > +	mrs_s	x0, SYS_ID_AA64MMFR2_EL1
> > > > > +	and	x0, x0, #(0xf << ID_AA64MMFR2_LVA_SHIFT)
> > > > > +	cbnz	x0, 2f
> > > > > +
> > > > > +	adr_l	x0, va52mismatch
> > > > > +	mov	w1, #1
> > > > > +	strb	w1, [x0]
> > > > > +	dmb	sy
> > > > > +	dc	ivac, x0	// Invalidate potentially stale cache line
> > > > 
> > > > You may have to clear this variable before a CPU is brought up to avoid
> > > > raising a false error message when another secondary CPU doesn't boot
> > > > for some other reason (say granule support) after a CPU failed with lack
> > > > of 52bitva. It is really a crazy corner case.
> > > 
> > > Can't we just follow the example set by the EL2 setup in the way that is
> > > uses __boot_cpu_mode? In that case, we only need one variable and you can
> > > detect a problem by comparing the two halves.
> > 
> > The only difference here is, the support is bolted at boot CPU time and hence
> > we need to verify each and every CPU, unlike the __boot_cpu_mode where we
> > check for mismatch after the SMP CPUs are brought up. If we decide to make
> > the choice later, something like that could work. The only caveat is the 52bit
> > kernel VA will have to do something like the above.
> 
> So looking at this a bit more, I think we're better off repurposing the
> upper bits of the early boot status word to contain a reason code, rather
> than introducing new variables for every possible mismatch.
> 
> Does the untested diff below look remotely sane to you?
> 
> Will
> 

Thanks Will,
This looks good to me, I will test now and fold this into a patch.

Cheers,
-- 
Steve

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 01/34] kbuild: Add support for DT binding schema checks
From: Rob Herring @ 2018-12-10 15:55 UTC (permalink / raw)
  To: Masahiro Yamada
  Cc: Mark Rutland, devicetree, Kumar Gala, ARM-SoC Maintainers,
	Sean Hudson, Jonathan Corbet, Frank Rowand,
	Linux Doc Mailing List, linux-kernel@vger.kernel.org,
	Linux Kbuild mailing list, Michal Marek, Grant Likely,
	linuxppc-dev,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAK7LNARgyL+Pq+SCkUUKnMny4nDw1L4zEevdzqbyGGAoE+BXUA@mail.gmail.com>

On Fri, Dec 7, 2018 at 10:47 PM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> Hi Rob,
>
>
> On Tue, Dec 4, 2018 at 6:32 AM Rob Herring <robh@kernel.org> wrote:
> >
> > This adds the build infrastructure for checking DT binding schema
> > documents and validating dts files using the binding schema.
> >
> > Check DT binding schema documents:
> > make dt_binding_check
> >
> > Build dts files and check using DT binding schema:
> > make dtbs_check
> >
> > Optionally, DT_SCHEMA_FILES can passed in with a schema file(s) to use
> > for validation. This makes it easier to find and fix errors generated by
> > a specific schema.
> >
> > Currently, the validation targets are separate from a normal build to
> > avoid a hard dependency on the external DT schema project and because
> > there are lots of warnings generated.
> >
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> > Cc: Michal Marek <michal.lkml@markovi.net>
> > Cc: linux-doc@vger.kernel.org
> > Cc: devicetree@vger.kernel.org
> > Cc: linux-kbuild@vger.kernel.org
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> >  .gitignore                                   |  1 +
> >  Documentation/Makefile                       |  2 +-
> >  Documentation/devicetree/bindings/.gitignore |  1 +
> >  Documentation/devicetree/bindings/Makefile   | 33 ++++++++++++++++++++
> >  Makefile                                     | 11 +++++--
> >  scripts/Makefile.lib                         | 24 ++++++++++++--
> >  6 files changed, 67 insertions(+), 5 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/.gitignore
> >  create mode 100644 Documentation/devicetree/bindings/Makefile
> >
> > diff --git a/.gitignore b/.gitignore
> > index 97ba6b79834c..a20ac26aa2f5 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -15,6 +15,7 @@
> >  *.bin
> >  *.bz2
> >  *.c.[012]*.*
> > +*.dt.yaml
> >  *.dtb
> >  *.dtb.S
> >  *.dwo
> > diff --git a/Documentation/Makefile b/Documentation/Makefile
> > index 2ca77ad0f238..9786957c6a35 100644
> > --- a/Documentation/Makefile
> > +++ b/Documentation/Makefile
> > @@ -2,7 +2,7 @@
> >  # Makefile for Sphinx documentation
> >  #
> >
> > -subdir-y :=
> > +subdir-y := devicetree/bindings/
> >
> >  # You can set these variables from the command line.
> >  SPHINXBUILD   = sphinx-build
> > diff --git a/Documentation/devicetree/bindings/.gitignore b/Documentation/devicetree/bindings/.gitignore
> > new file mode 100644
> > index 000000000000..d9194c02dd08
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/.gitignore
> > @@ -0,0 +1 @@
> > +*.example.dts
> > diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile
> > new file mode 100644
> > index 000000000000..ee0110dd8131
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/Makefile
> > @@ -0,0 +1,33 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +DT_DOC_CHECKER ?= dt-doc-validate
> > +DT_EXTRACT_EX ?= dt-extract-example
> > +DT_MK_SCHEMA ?= dt-mk-schema
> > +DT_MK_SCHEMA_FLAGS := $(if $(DT_SCHEMA_FILES), -u)
> > +
> > +quiet_cmd_chk_binding = CHKDT   $<
> > +      cmd_chk_binding = (set -e; \
> > +                         $(DT_DOC_CHECKER) $< ; \
> > +                         mkdir -p $(dir $@) ; \
> > +                         $(DT_EXTRACT_EX) $< > $@ )
> > +
> > +$(obj)/%.example.dts: $(src)/%.yaml FORCE
> > +       $(call if_changed,chk_binding)
> > +
> > +DT_TMP_SCHEMA := .schema.yaml.tmp
> > +extra-y += $(DT_TMP_SCHEMA)
> > +
> > +quiet_cmd_mk_schema = SCHEMA  $@
> > +      cmd_mk_schema = mkdir -p $(obj); \
> > +                      rm -f $@; \
> > +                      $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $<
>
>
> I think '$<' is wrong.
>
> '$<' is replaced with the first prerequisite.

Indeed.

> You can easily check what is happening here.
>
> $ cat   Documentation/devicetree/bindings/..schema.yaml.tmp.cmd
> cmd_Documentation/devicetree/bindings/.schema.yaml.tmp := mkdir -p
> Documentation/devicetree/bindings; rm -f
> Documentation/devicetree/bindings/.schema.yaml.tmp; dt-mk-schema  -o
> Documentation/devicetree/bindings/.schema.yaml.tmp
> Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml
>
>
> So, the dt-validater will check only binding from ti,davinci.yaml,
> which is almost useless.
>
>
>
> If I understand it correctly,
> .schema.yaml.tmp should contain all binding yaml.
>
>
> I fixed it up like follows:
>
> diff --git a/Documentation/devicetree/bindings/Makefile
> b/Documentation/devicetree/bindings/Makefile
> index ee0110d..267458f 100644
> --- a/Documentation/devicetree/bindings/Makefile
> +++ b/Documentation/devicetree/bindings/Makefile
> @@ -19,7 +19,7 @@ extra-y += $(DT_TMP_SCHEMA)
>  quiet_cmd_mk_schema = SCHEMA  $@
>        cmd_mk_schema = mkdir -p $(obj); \
>                        rm -f $@; \
> -                      $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $<
> +                      $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@
> $(filter-out FORCE, $^)

Thanks, I incorporated this fix.

>
>  DT_DOCS = $(shell cd $(srctree)/$(src) && find * -name '*.yaml')
>  DT_SCHEMA_FILES ?= $(addprefix $(src)/,$(DT_DOCS))
>
>
>
> Then, I see another error.

I fixed this with this change:

@@ -27,7 +27,7 @@ DT_SCHEMA_FILES ?= $(addprefix $(src)/,$(DT_DOCS))
 extra-y += $(patsubst $(src)/%.yaml,%.example.dts, $(DT_SCHEMA_FILES))
 extra-y += $(patsubst $(src)/%.yaml,%.example.dtb, $(DT_SCHEMA_FILES))

-$(obj)/$(DT_TMP_SCHEMA): $(addprefix $(obj)/,$(patsubst
$(src)/%.yaml,%.example.dtb, $(DT_SCHEMA_FILES)))
+$(obj)/$(DT_TMP_SCHEMA): | $(addprefix $(obj)/,$(patsubst
$(src)/%.yaml,%.example.dtb, $(DT_SCHEMA_FILES)))

 $(obj)/$(DT_TMP_SCHEMA): $(addprefix $(srctree)/, $(DT_SCHEMA_FILES)) FORCE
        $(call if_changed,mk_schema)

>
>
>   SCHEMA  Documentation/devicetree/bindings/.schema.yaml.tmp
> Traceback (most recent call last):
>   File "/home/masahiro/ref/yaml-bindings/tools/dt-mk-schema", line 32,
> in <module>
>     schemas = dtschema.process_schemas(args.schemas, core_schema=(not
> args.useronly))
>   File "/usr/local/lib/python3.5/dist-packages/dtschema-0.0.1-py3.5.egg/dtschema/lib.py",
> line 359, in process_schemas
>     sch = process_schema(os.path.abspath(filename))
>   File "/usr/local/lib/python3.5/dist-packages/dtschema-0.0.1-py3.5.egg/dtschema/lib.py",
> line 314, in process_schema
>     schema = load_schema(filename)
>   File "/usr/local/lib/python3.5/dist-packages/dtschema-0.0.1-py3.5.egg/dtschema/lib.py",
> line 80, in load_schema
>     return yaml.load(f.read())
>   File "/usr/lib/python3.5/codecs.py", line 321, in decode
>     (result, consumed) = self._buffer_decode(data, self.errors, final)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd0 in position
> 0: invalid continuation byte
> Documentation/devicetree/bindings/Makefile:33: recipe for target
> 'Documentation/devicetree/bindings/.schema.yaml.tmp' failed
> make[1]: *** [Documentation/devicetree/bindings/.schema.yaml.tmp] Error 1
> Makefile:1278: recipe for target 'dt_binding_check' failed
> make: *** [dt_binding_check] Error 2
>
>
>
>
>
>
>
> BTW, I cannot build *.dt.yaml
>
>
>
>   DTC     arch/arm/boot/dts/alpine-db.dt.yaml
> FATAL ERROR: Unknown output format "yaml"
> scripts/Makefile.lib:313: recipe for target
> 'arch/arm/boot/dts/alpine-db.dt.yaml' failed
> make[1]: *** [arch/arm/boot/dts/alpine-db.dt.yaml] Error 1
> make[1]: *** Deleting file 'arch/arm/boot/dts/alpine-db.dt.yaml'
> Makefile:1262: recipe for target 'dtbs_check' failed
>
>
>
>
> I use linux-next.
>
>
> script/dtc/dtc does not understand '-O yaml'
>
>
> I also tried the upstream DTC project with no success.
>
>
> Where can I get dtc with yaml support?

You need libyaml and its headers. I'll try to make this a better error
message. For now, libyaml is optional so we don't break everyone just
building dtbs.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: ufs_qcom_dump_dbg_regs makes the kernel panic
From: Robin Murphy @ 2018-12-10 15:54 UTC (permalink / raw)
  To: Marc Gonzalez, Jeffrey Hugo, Vivek Gautam, Bjorn Andersson,
	Andy Gross, David Brown
  Cc: MSM, Linux ARM
In-Reply-To: <2aaa187e-c612-097c-cbb1-fdb46753eb8b@free.fr>

On 10/12/2018 14:57, Marc Gonzalez wrote:
[...]
> [   14.135960] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: core_clk disabled
> [   14.140789] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: bus_aggr_clk disabled
> [   14.148604] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: iface_clk disabled
> [   14.156687] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: core_clk_unipro disabled
> [   14.164398] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: core_clk_ice disabled
> [   14.172866] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: ref_clk disabled
> [   14.180878] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: tx_lane0_sync_clk disabled
> [   14.188272] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: rx_lane0_sync_clk disabled
> [   14.196958] ufshcd-qcom 1da4000.ufshc: __ufshcd_setup_clocks: clk: rx_lane1_sync_clk disabled
> /*** System hangs here ***/

Looks like it's time to rule out the obvious and crank up the 
clock/power domain debugging to see if turning off all this stuff 
inadvertently also turns off something else important (and/or the 
primary CPU gets wedged trying to read some now-unclocked register).

Robin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] ARM: mm: skip cleaning of idmap page tables on LPAE capable cores
From: Russell King - ARM Linux @ 2018-12-10 15:48 UTC (permalink / raw)
  To: Ard Biesheuvel; +Cc: Marc Zyngier, Will Deacon, linux-arm-kernel
In-Reply-To: <20181210152855.3634-1-ard.biesheuvel@linaro.org>

On Mon, Dec 10, 2018 at 04:28:55PM +0100, Ard Biesheuvel wrote:
> Since only LPAE capable CPUs may execute under virtualization, and
> considering that LPAE capable CPUs are guaranteed to have cache
> coherent page table walkers (per the architecture), let's only
> perform this cache maintenance on non-LPAE cores.

That statement doesn't stack up.  What about Cortex A15, which is a
32-bit core with LPAE support?  TI Keystone2 SoCs fall into this
category.

Sorry, but no, I don't think we can omit this cache flush on LPAE.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RESEND PATCH v2] clocksource/arm_arch_timer: fix a lockdep warning
From: Qian Cai @ 2018-12-10 15:47 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: mark.rutland, marc.zyngier, daniel.lezcano, linux-kernel, mingo,
	longman, akpm, tglx, linux-arm-kernel
In-Reply-To: <20181210140703.GM5289@hirez.programming.kicks-ass.net>


On 12/10/18 9:07 AM, Peter Zijlstra wrote:
> On Mon, Dec 10, 2018 at 08:52:28AM -0500, Qian Cai wrote:
>> Booting this Huawei TaiShan 2280 arm64 server generated this lockdep
>> warning.
>>
>> [    0.000000]  lockdep_assert_cpus_held+0x50/0x60
>> [    0.000000]  static_key_enable_cpuslocked+0x30/0xe8
>> [    0.000000]  arch_timer_check_ool_workaround+0x128/0x2d0
>> [    0.000000]  arch_timer_acpi_init+0x274/0x6ac
>> [    0.000000]  acpi_table_parse+0x1ac/0x218
>> [    0.000000]  __acpi_probe_device_table+0x164/0x1ec
>> [    0.000000]  timer_probe+0x1bc/0x254
>> [    0.000000]  time_init+0x44/0x98
>> [    0.000000]  start_kernel+0x4ec/0x7d4
> 
> It seems to me we want something like:

Tested-by: Qian Cai <cai@lca.pw>

> 
> ---
>  kernel/cpu.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 91d5c38eb7e5..e1ee8caf28b5 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -313,6 +313,8 @@ void cpus_write_unlock(void)
>  
>  void lockdep_assert_cpus_held(void)
>  {
> +	if (system_state < SYSTEM_RUNNING)
> +		return;
>  	percpu_rwsem_assert_held(&cpu_hotplug_lock);
>  }
>  
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 06/12] KVM: arm64: Support Live Physical Time reporting
From: Steven Price @ 2018-12-10 15:45 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Marc Zyngier, Catalin Marinas, Will Deacon, kvmarm,
	linux-arm-kernel
In-Reply-To: <20181210105632.hjdnszkcqwiqbyub@lakrids.cambridge.arm.com>

On 10/12/2018 10:56, Mark Rutland wrote:
> On Wed, Nov 28, 2018 at 02:45:21PM +0000, Steven Price wrote:
>> Provide a method for a guest to derive a paravirtualized counter/timer
>> which isn't dependent on the host's counter frequency. This allows a
>> guest to be migrated onto a new host which doesn't have the same
>> frequency without the virtual counter being disturbed.
> 
> I have a number of concerns about paravirtualizing the timer frequency,
> but I'll bring that up in reply to the cover letter.
> 
> I have some orthogonal comments below.
> 
>> The host provides a shared page which contains coefficients that can be
>> used to map the real counter from the host (the Arm "virtual counter")
>> to a paravirtualized view of time. On migration the new host updates the
>> coefficients to ensure that the guests view of time (after using the
>> coefficients) doesn't change and that the derived counter progresses at
>> the same real frequency.
> 
> Can we please avoid using the term 'page' here?
> 
> There is a data structure in shared memory, but it is not page-sized,
> and referring to it as a page here and elsewhere is confusing. The spec
> never uses the term 'page'
> 
> Could we please say something like:
> 
>   The host provides a datastrucutre in shared memory which ...
> 
> ... to avoid the implication this is page sized/aligned etc.
> 
> [...]

Sure, I'll update to avoid referring to it as a page. Although note that
when mapping it into the guest we can obviously only map in page sized
granules, so in practise the LPT structure is contained within a entire
page given to the guest...

>> +	struct kvm_arch_pvtime {
>> +		void *pv_page;
>> +
>> +		gpa_t lpt_page;
>> +		u32 lpt_fpv;
>> +	} pvtime;
> 
> To remove the page terminology, perhaps something like:
> 
> 	struct kvm_arch_pvtime {
>  		struct lpt	*lpt;
>  		gpa_t		lpt_gpa;
>  		u32		lpt_fpv;
>  	};
> 
> [...]
> 
>> diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
>> index 8bf259dae9f6..fd3a2caabeb2 100644
>> --- a/include/linux/kvm_types.h
>> +++ b/include/linux/kvm_types.h
>> @@ -49,6 +49,8 @@ typedef unsigned long  gva_t;
>>  typedef u64            gpa_t;
>>  typedef u64            gfn_t;
>>  
>> +#define GPA_INVALID    -1
> 
> To avoid any fun with signed/unsigned comparison, can we please make
> this:
> 
> #define GPA_INVALID	((gpa_t)-1)
> 
> ... or:
> 
> #define GPA_INVALID     (~(gpa_t)0)
> 
> [...]

I'll go with the latter as I think that's clearer.

>> +static void update_vtimer_cval(struct kvm *kvm, u32 previous_rate)
>> +{
>> +	u32 current_rate = arch_timer_get_rate();
>> +	u64 current_time = kvm_phys_timer_read();
>> +	int i;
>> +	struct kvm_vcpu *vcpu;
>> +	u64 rel_cval;
>> +
>> +	/* Early out if there's nothing to do */
>> +	if (likely(previous_rate == current_rate))
>> +		return;
> 
> Given this only happens on migration, I don't think we need to care
> about likely/unlikely here, and can drop that from the condition.

Fair enough

> [...]
> 
>> +int kvm_arm_update_lpt_sequence(struct kvm *kvm)
>> +{
>> +	struct pvclock_vm_time_info *pvclock;
>> +	u64 lpt_ipa = kvm->arch.pvtime.lpt_page;
>> +	u64 native_freq, pv_freq, scale_mult, div_by_pv_freq_mult;
>> +	u64 shift = 0;
>> +	u64 sequence_number = 0;
>> +
>> +	if (lpt_ipa == GPA_INVALID)
>> +		return -EINVAL;
>> +
>> +	/* Page address must be 64 byte aligned */
>> +	if (lpt_ipa & 63)
>> +		return -EINVAL;
> 
> Please use IS_ALIGNED(), e.g.
> 
> 	if (!IS_ALIGNED(lpt_ipa, 64))
> 		return -EINVAL;

Yes, much clearer - no need for the comment :)

Thanks,

Steve

> Thanks,
> Mark.
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v6 2/3] iommu/io-pgtable-arm-v7s: Request DMA32 memory, and improve debugging
From: Will Deacon @ 2018-12-10 15:35 UTC (permalink / raw)
  To: Nicolas Boichat
  Cc: Michal Hocko, Levin Alexander, linux-mm, Christoph Lameter,
	Huaisheng Ye, Joerg Roedel, Matthew Wilcox, hch, linux-arm-kernel,
	David Rientjes, yingjoe.chen, Vlastimil Babka, Tomasz Figa,
	Mike Rapoport, hsinyi, Matthias Brugger, Joonsoo Kim, Yong Wu,
	Robin Murphy, linux-kernel, stable, Pekka Enberg, iommu,
	Andrew Morton, Mel Gorman
In-Reply-To: <20181210011504.122604-3-drinkcat@chromium.org>

On Mon, Dec 10, 2018 at 09:15:03AM +0800, Nicolas Boichat wrote:
> IOMMUs using ARMv7 short-descriptor format require page tables
> (level 1 and 2) to be allocated within the first 4GB of RAM, even
> on 64-bit systems.
> 
> For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32
> is defined (e.g. on arm64 platforms).
> 
> For level 2 pages, allocate a slab cache in SLAB_CACHE_DMA32. Note
> that we do not explicitly pass GFP_DMA[32] to kmem_cache_zalloc,
> as this is not strictly necessary, and would cause a warning
> in mm/sl*b.c, as we did not update GFP_SLAB_BUG_MASK.
> 
> Also, print an error when the physical address does not fit in
> 32-bit, to make debugging easier in the future.
> 
> Cc: stable@vger.kernel.org
> Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> ---

Acked-by: Will Deacon <will.deacon@arm.com>

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v5 0/7] spi: add support for octal mode
From: Mark Brown @ 2018-12-10 15:29 UTC (permalink / raw)
  To: Yogesh Narayan Gaur
  Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Vignesh R,
	marek.vasut@gmail.com, linux-kernel@vger.kernel.org,
	linux-spi@vger.kernel.org, Boris Brezillon,
	frieder.schrempf@exceet.de, linux-mtd@lists.infradead.org,
	computersforpeace@gmail.com, shawnguo@kernel.org, robh@kernel.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB572641541BB83E587541BBD099A50@VI1PR04MB5726.eurprd04.prod.outlook.com>


[-- Attachment #1.1: Type: text/plain, Size: 1276 bytes --]

On Mon, Dec 10, 2018 at 04:13:28AM +0000, Yogesh Narayan Gaur wrote:
> Hi Mark,

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> Patch has been resend [1], this patch is depends on the series of patch[2] and this series has been applied by Boris already.

> [1] https://patchwork.ozlabs.org/patch/1010253/

This appears to be an MTD patch?  The subject is "mtd: m25p80: add
support of octal mode I/O transfer".  MTD patches normally go via the
MTD tree which is maintained by a group of people including Boris but
not me.

Please include human readable descriptions of things like commits and
issues being discussed in e-mail in your mails, this makes them much
easier for humans to read especially when they have no internet access.
I do frequently catch up on my mail on flights or while otherwise
travelling so this is even more pressing for me than just being about
making things a bit easier to read.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] arm64: Add memory hotplug support
From: Robin Murphy @ 2018-12-10 15:29 UTC (permalink / raw)
  To: will.deacon, catalin.marinas
  Cc: anshuman.khandual, cyrilc, linux-kernel, james.morse,
	jonathan.cameron, linux-arm-kernel

Wire up the basic support for hot-adding memory. Since memory hotplug
is fairly tightly coupled to sparsemem, we tweak pfn_valid() to also
cross-check the presence of a section in the manner of the generic
implementation, before falling back to memblock to check for no-map
regions within a present section as before. By having arch_add_memory(()
create the linear mapping first, this then makes everything work in the
way that __add_section() expects.

We expect hotplug to be ACPI-driven, so the swapper_pg_dir updates
should be safe from races by virtue of the global device hotplug lock.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---

Looks like I'm not going to have the whole pte_devmap story figured out
in time to land any ZONE_DEVICE support this cycle, but since this patch
also stands alone as a complete feature (and has ended up remarkably
simple and self-contained), I hope we might consider getting it merged
on its own merit.

Robin.

 arch/arm64/Kconfig   |  3 +++
 arch/arm64/mm/init.c |  8 ++++++++
 arch/arm64/mm/mmu.c  | 12 ++++++++++++
 arch/arm64/mm/numa.c | 10 ++++++++++
 4 files changed, 33 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6d2b25f51bb3..7b855ae45747 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -261,6 +261,9 @@ config ZONE_DMA32
 config HAVE_GENERIC_GUP
 	def_bool y
 
+config ARCH_ENABLE_MEMORY_HOTPLUG
+	def_bool y
+
 config SMP
 	def_bool y
 
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 2983e0fc1786..82e0b08f2e31 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -291,6 +291,14 @@ int pfn_valid(unsigned long pfn)
 
 	if ((addr >> PAGE_SHIFT) != pfn)
 		return 0;
+
+#ifdef CONFIG_SPARSEMEM
+	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
+		return 0;
+
+	if (!valid_section(__nr_to_section(pfn_to_section_nr(pfn))))
+		return 0;
+#endif
 	return memblock_is_map_memory(addr);
 }
 EXPORT_SYMBOL(pfn_valid);
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index e1b2d58a311a..22379a74d289 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1044,3 +1044,15 @@ int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
 	pmd_free(NULL, table);
 	return 1;
 }
+
+#ifdef CONFIG_MEMORY_HOTPLUG
+int arch_add_memory(int nid, u64 start, u64 size, struct vmem_altmap *altmap,
+		    bool want_memblock)
+{
+	__create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
+			     size, PAGE_KERNEL, pgd_pgtable_alloc, 0);
+
+	return __add_pages(nid, start >> PAGE_SHIFT, size >> PAGE_SHIFT,
+			   altmap, want_memblock);
+}
+#endif
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 27a31efd9e8e..ae34e3a1cef1 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -466,3 +466,13 @@ void __init arm64_numa_init(void)
 
 	numa_init(dummy_numa_init);
 }
+
+/*
+ * We hope that we will be hotplugging memory on nodes we already know about,
+ * such that acpi_get_node() succeeds and we never fall back to this...
+ */
+int memory_add_physaddr_to_nid(u64 addr)
+{
+	pr_warn("Unknown node for memory at 0x%llx, assuming node 0\n", addr);
+	return 0;
+}
-- 
2.19.1.dirty


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH] ARM: mm: skip cleaning of idmap page tables on LPAE capable cores
From: Ard Biesheuvel @ 2018-12-10 15:28 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: Marc Zyngier, Will Deacon, Russell King, Ard Biesheuvel

Currently, init_static_idmap() installs some page table entries to
cover the identity mapped part of the kernel image (which is only
about 160 bytes in size in a multi_v7_defconfig Thumb2 build), and
calls flush_cache_louis() to ensure that the updates are visible
to the page table walker on the same core.

When running under virtualization, flush_cache_louis() may take more
than 10 seconds to complete:

[    0.108192] Setting up static identity map for 0x40300000 - 0x403000a0
[   13.078127] rcu: Hierarchical SRCU implementation.

This is due to the fact that set/way ops are not virtualizable, and so
KVM may trap each one, resulting in a substantial delay.

Since only LPAE capable CPUs may execute under virtualization, and
considering that LPAE capable CPUs are guaranteed to have cache
coherent page table walkers (per the architecture), let's only
perform this cache maintenance on non-LPAE cores.

Cc: Russell King <linux@armlinux.org.uk>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm/mm/idmap.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index 1d1edd064199..a033f6134a64 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -6,6 +6,7 @@
 
 #include <asm/cputype.h>
 #include <asm/idmap.h>
+#include <asm/hwcap.h>
 #include <asm/pgalloc.h>
 #include <asm/pgtable.h>
 #include <asm/sections.h>
@@ -110,7 +111,8 @@ static int __init init_static_idmap(void)
 			     __idmap_text_end, 0);
 
 	/* Flush L1 for the hardware to see this page table content */
-	flush_cache_louis();
+	if (!(elf_hwcap & HWCAP_LPAE))
+		flush_cache_louis();
 
 	return 0;
 }
-- 
2.19.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: TK1: DRM, Nouveau and VIC
From: Marcel Ziswiler @ 2018-12-10 15:20 UTC (permalink / raw)
  To: bskeggs@redhat.com, thierry.reding@gmail.com
  Cc: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	mperttunen@nvidia.com, linux-tegra@vger.kernel.org,
	jonathanh@nvidia.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181210110056.GL15154@ulmo>

Hi Thierry

On Mon, 2018-12-10 at 12:00 +0100, Thierry Reding wrote:
> On Mon, Dec 10, 2018 at 11:21:47AM +0100, Thierry Reding wrote:
> > On Sat, Dec 08, 2018 at 02:54:45PM +0000, Marcel Ziswiler wrote:
> > > Hi Thierry et al.
> > > 
> > > I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on
> > > Tegra124") graphics on Apalis TK1 is broken. During boot it fails
> > > loading the vic firmware:
> > > 
> > > [    1.595824] tegra-vic 54340000.vic: Direct firmware load for
> > > nvidia/tegra124/vic03_ucode.bin failed with error -2
> > > [    1.606140] tegra-vic: probe of 54340000.vic failed with error
> > > -2
> > > 
> > > Subsequently Tegra HDMI seems to fail completely:
> > > 
> > > [    2.379860] tegra-hdmi 54280000.hdmi: failed to get PLL
> > > regulator
> > > 
> > > And finally, Nouveau even crashes:
> > > 
> > > [    8.241115] nouveau 57000000.gpu: Linked as a consumer to
> > > regulator.31
> > > [    8.247889] nouveau 57000000.gpu: NVIDIA GK20A (0ea000a1)
> > > [    8.253396] nouveau 57000000.gpu: imem: using IOMMU
> > > [    8.270210] Unable to handle kernel NULL pointer dereference
> > > at
> > > virtual address 0000006c
> > > [    8.278340] pgd = (ptrval)
> > > [    8.281250] [0000006c] *pgd=00000000
> > > [    8.284944] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> > > [    8.290260] Modules linked in: nouveau(+) ttm
> > > [    8.294625] CPU: 2 PID: 203 Comm: systemd-udevd Not tainted
> > > 4.20.0-
> > > rc5-next-20181207-00008-g85b0f8e25f86-dirty #110
> > > [    8.305055] Hardware name: NVIDIA Tegra SoC (Flattened Device
> > > Tree)
> > > [    8.311331] PC is at drm_plane_register_all+0x18/0x50
> > > [    8.316373] LR is at drm_modeset_register_all+0xc/0x70
> > > [    8.321513] pc : [<c056200c>]    lr : [<c0564cc8>]    psr:
> > > a0060013
> > > [    8.327768] sp : ed527c70  ip : ecc43ec0  fp : 00000000
> > > [    8.332993] r10: 00000016  r9 : ecc43e80  r8 : 00000000
> > > [    8.338209] r7 : bf182c80  r6 : 00000000  r5 : ed61b24c  r4 :
> > > fffffffc
> > > [    8.344735] r3 : 0002f000  r2 : ffffffff  r1 : 2e124000  r0 :
> > > ed61b000
> > > [    8.351260] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA
> > > ARM  Segment none
> > > [    8.358383] Control: 10c5387d  Table: ad64c06a  DAC: 00000051
> > > [    8.364127] Process systemd-udevd (pid: 203, stack limit =
> > > 0x(ptrval))
> > > [    8.370654] Stack: (0xed527c70 to 0xed528000)
> > > [    8.375004] 7c60:                                     ed61b000
> > > ed61b000 00000000 c0564cc8
> > > [    8.383177] 7c80: ed61b000 00000000 00000000 c054b5b8 00000001
> > > 00000001 ffffffff ffffffff
> > > [    8.391355] 7ca0: ed527cc0 c0f08c48 ed61b000 00000000 00000000
> > > 00000000 bf180c5c bf0dc900
> > > [    8.399531] 7cc0: eda29208 5dfe844b 00000000 ee9f2a10 00000000
> > > bf180c5c 00000000 c05a9328
> > > [    8.407695] 7ce0: c1006828 ee9f2a10 c100682c 00000000 00000000
> > > c05a744c ee9f2a10 bf180c5c
> > > [    8.415871] 7d00: ee9f2a44 c05a77a8 00000000 c0f08c48 bf182980
> > > c05a769c eefd14d0 c05a77a8
> > > [    8.424048] 7d20: 00000000 ee9f2a10 bf180c5c ee9f2a44 c05a77a8
> > > 00000000 c0f08c48 bf182980
> > > [    8.432226] 7d40: 00000000 c05a7884 ee9ebfb4 c0f08c48 bf180c5c
> > > c05a5790 00000000 ee88135c
> > > [    8.440405] 7d60: ee9ebfb4 5dfe844b c0f71168 bf180c5c ee379e80
> > > c0f71168 00000000 c05a692c
> > > [    8.448570] 7d80: bf15dc00 bf180ac8 ffffe000 bf180c5c bf180ac8
> > > ffffe000 bf1aa000 c05a84a0
> > > [    8.456746] 7da0: bf182b80 bf180ac8 ffffe000 bf1aa170 c0fbd220
> > > c0f08c48 ffffe000 c0102ed0
> > > [    8.464924] 7dc0: ed53f4c0 006000c0 c01b3d98 0000000c 60000113
> > > bf182980 00000040 c02592d0
> > > [    8.473102] 7de0: eda60200 2e124000 ee800000 006000c0 006000c0
> > > c01b3d98 0000000c c025a8cc
> > > [    8.481281] 7e00: c024ce54 a0000113 bf182980 5dfe844b bf182980
> > > 00000002 ed53f4c0 00000002
> > > [    8.489459] 7e20: eceba000 c01b3dd4 c0f08c48 bf182980 00000000
> > > ed527f40 00000002 eceb9fc0
> > > [    8.497625] 7e40: 00000002 c01b61a4 bf18298c 00007fff bf182980
> > > c01b2f88 00000000 c01b279c
> > > [    8.505800] 7e60: bf1829c8 bf182a80 bf182b6c bf182ab0 c0b03ab0
> > > c0d58964 c0ca726c c0ca7278
> > > [    8.513978] 7e80: c0ca72d0 c0f08c48 00000000 c02654a0 00000000
> > > 00000000 ffffe000 bf000000
> > > [    8.522157] 7ea0: 00000000 00000000 00000000 00000000 00000000
> > > 00000000 6e72656b 00006c65
> > > [    8.530336] 7ec0: 00000000 00000000 00000000 00000000 00000000
> > > 00000000 00000000 00000000
> > > [    8.538502] 7ee0: 00000000 00000000 00000000 00000000 00000000
> > > 5dfe844b 7fffffff c0f08c48
> > > [    8.546677] 7f00: 00000000 0000000f b6f761cc c0101204 ed526000
> > > 0000017b 004a3270 c01b66a4
> > > [    8.554855] 7f20: 7fffffff 00000000 00000003 00000001 004a3270
> > > f0ced000 06e8994c 00000000
> > > [    8.563032] 7f40: f0e37f3a f0e50a40 f0ced000 06e8994c f7b75f9c
> > > f7b75d34 f63e62dc 0016b000
> > > [    8.571209] 7f60: 0017f6f0 00000000 00000000 00000000 00050a48
> > > 0000003b 0000003c 00000023
> > > [    8.579388] 7f80: 00000000 00000014 00000000 5dfe844b 00000000
> > > 004c0ec0 00000000 00000001
> > > [    8.587554] 7fa0: 0000017b c0101000 004c0ec0 00000000 0000000f
> > > b6f761cc 00000000 00020000
> > > [    8.595730] 7fc0: 004c0ec0 00000000 00000001 0000017b 0048e114
> > > 00000000 00000000 004a3270
> > > [    8.603908] 7fe0: bea8f990 bea8f980 b6f71269 b6e9f6c0 400d0010
> > > 0000000f 00000000 00000000
> > > [    8.612096] [<c056200c>] (drm_plane_register_all) from
> > > [<c0564cc8>]
> > > (drm_modeset_register_all+0xc/0x70)  
> > > [    8.621499] [<c0564cc8>] (drm_modeset_register_all) from
> > > [<c054b5b8>] (drm_dev_register+0x168/0x1c4)
> > > [    8.630855] [<c054b5b8>] (drm_dev_register) from [<bf0dc900>]
> > > (nouveau_platform_probe+0x6c/0x88 [nouveau])
> > > [    8.640739] [<bf0dc900>] (nouveau_platform_probe [nouveau])
> > > from
> > > [<c05a9328>] (platform_drv_probe+0x48/0x98)
> > > [    8.650574] [<c05a9328>] (platform_drv_probe) from
> > > [<c05a744c>]
> > > (really_probe+0x1e0/0x2cc)
> > > [    8.658827] [<c05a744c>] (really_probe) from [<c05a769c>]
> > > (driver_probe_device+0x60/0x16c)
> > > [    8.667096] [<c05a769c>] (driver_probe_device) from
> > > [<c05a7884>]
> > > (__driver_attach+0xdc/0xe0)
> > > [    8.675543] [<c05a7884>] (__driver_attach) from [<c05a5790>]
> > > (bus_for_each_dev+0x74/0xb4)
> > > [    8.683729] [<c05a5790>] (bus_for_each_dev) from [<c05a692c>]
> > > (bus_add_driver+0x1c0/0x204)
> > > [    8.692004] [<c05a692c>] (bus_add_driver) from [<c05a84a0>]
> > > (driver_register+0x74/0x108)
> > > [    8.700324] [<c05a84a0>] (driver_register) from [<bf1aa170>]
> > > (nouveau_drm_init+0x170/0x1000 [nouveau])   
> > > [    8.709857] [<bf1aa170>] (nouveau_drm_init [nouveau]) from
> > > [<c0102ed0>] (do_one_initcall+0x54/0x284)
> > > [    8.718980] [<c0102ed0>] (do_one_initcall) from [<c01b3dd4>]
> > > (do_init_module+0x64/0x214)
> > > [    8.727079] [<c01b3dd4>] (do_init_module) from [<c01b61a4>]
> > > (load_module+0x21b8/0x246c)
> > > [    8.735094] [<c01b61a4>] (load_module) from [<c01b66a4>]
> > > (sys_finit_module+0xc4/0xdc)
> > > [    8.742937] [<c01b66a4>] (sys_finit_module) from [<c0101000>]
> > > (ret_fast_syscall+0x0/0x54)
> > > [    8.751114] Exception stack(0xed527fa8 to 0xed527ff0)
> > > [    8.756157] 7fa0:                   004c0ec0 00000000 0000000f
> > > b6f761cc 00000000 00020000
> > > [    8.764333] 7fc0: 004c0ec0 00000000 00000001 0000017b 0048e114
> > > 00000000 00000000 004a3270
> > > [    8.772510] 7fe0: bea8f990 bea8f980 b6f71269 b6e9f6c0
> > > [    8.777556] Code: e5b5424c e1550004 0a00000c e2444004
> > > (e5943070)
> > > [    8.784011] ---[ end trace ad8c21587c118655 ]---
> > > 
> > > Of course my root file system does include resp. vic firmware:
> > > 
> > > 7ef01d2e3f507c91ca79584e89edcc64  /lib/firmware/nvidia/tegra124/v
> > > ic03_u
> > > code.bin
> > > 
> > > If I bake that one into the kernel binary, Nouveau still crashes
> > > like
> > > above albeit VIC loading and Tegra DRM now at least showing
> > > something
> > > on HDMI.
> > 
> > Yeah, this is a fairly common pitfall. The general rule of thumb is
> > that
> > the firmware has to live on the same medium as the module. So if
> > you've
> > built Tegra DRM as a loadable kernel module and installed it in the
> > root
> > filesystem, then that's where your firmware file also needs to be.
> > If
> > the driver is built-in (or a loadable module installed in the
> > initial
> > ramdisk), then the firmware needs to be in the initial ramdisk (or
> > built
> > into the kernel image itself). That's somewhat annoying, but it is
> > what
> > it is. At least it's logical.
> > 
> > > Just reverting above mentioned commit still leaves Nouveau
> > > crashing.
> > > 
> > > This has been observed using latest next-20181207.
> > > 
> > > Does anybody know what exactly is going on and how exactly one
> > > may get
> > > graphics working again as before?
> > 
> > So this is something that should be fixed by this:
> > 
> > 	https://patchwork.freedesktop.org/patch/260547/
> > 
> > And there's another patch that fixes a subsequent crash when you
> > actually start to use the GPU:
> > 
> > 	https://patchwork.freedesktop.org/patch/263588/
> > 
> > It'd be great if you could apply both and verify that they fix the
> > crash
> > for you. If so, can you provide a Tested-by? Both were Cc'ed to
> > linux-tegra, so you should have a copy to reply to. If not, let me
> > know
> > and I can bounce it.
> > 
> > Ben, can you pick up the two patches above? They're kind of high-
> > priority because they fix issues that crept into v4.20-rc1, so
> > should
> > ideally be fixed before v4.20 final.
> 
> Actually, it looks as if only the last patch is needed, since it
> superseeds the first. The second one calls drm_mode_config_init() via
> nouveau_display_create() and nouveau_drm_device_init(), making the
> first patch obsolete.
> 
> There's more confirmation here:
> 
> 	
> https://lists.freedesktop.org/archives/nouveau/2018-December/031636.html
> 
> So Ben, correction, please only apply:
> 
> 	https://patchwork.freedesktop.org/patch/263587/

Yes, that fixes it and I sent my tested-by. Thanks!

> Preferably in time for v4.20 final.

BTW: During testing I was also brave enough to try rmmodding nouveau
which unfortunately also seems to fail:

root@apalis-tk1-mainline:~# rmmod nouveau
[ 3044.432527] [TTM] Finalizing pool allocator
[ 3044.440007] [TTM] Zone  kernel: Used memory at exit: 0 kiB
[ 3044.445631] [TTM] Zone highmem: Used memory at exit: 0 kiB
[ 3044.452841] Unable to handle kernel NULL pointer dereference at
virtual address 0000038a
[ 3044.461167] pgd = 537c0ac4
[ 3044.463891] [0000038a] *pgd=fb95b835
[ 3044.467487] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 3044.472901] Modules linked in: nouveau(-) btusb btrtl btbcm btintel
tegra_drm xhci_tegra host1x iova ttm
[ 3044.482415] CPU: 3 PID: 616 Comm: rmmod Not tainted 4.20.0-rc6-next-
20181210-00001-gd70a977fd0d5-dirty #115
[ 3044.492176] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[ 3044.498455] PC is at pci_disable_device+0x8/0xd4
[ 3044.503165] LR is at nouveau_drm_device_remove+0x50/0x7c [nouveau]
[ 3044.509350] pc : [<c048d05c>]    lr : [<bf254820>]    psr: 60000113
[ 3044.515638] sp : ee3abedc  ip : ed625000  fp : 00000001
[ 3044.520879] r10: 00000081  r9 : ee3aa000  r8 : ee9eb834
[ 3044.526107] r7 : ed624000  r6 : 00000000  r5 : c0f08c48  r4 :
00000000
[ 3044.532649] r3 : 5dfe844b  r2 : 5dfe844b  r1 : 2e135000  r0 :
00000000
[ 3044.539181] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA
ARM  Segment none
[ 3044.546333] Control: 10c5387d  Table: acbc006a  DAC: 00000051
[ 3044.552098] Process rmmod (pid: 616, stack limit = 0xfc4e79a2)
[ 3044.557934] Stack: (0xee3abedc to 0xee3ac000)
[ 3044.562304]
bec0:                                                                ed
62d400
[ 3044.570503] bee0: c0f08c48 bf254820 eda76808 5dfe844b ee9f1c8c
ee9f1c10 ee9f1c10 bf2f9c5c
[ 3044.578701] bf00: ee9eb800 bf255914 ee9f1c10 c056aba8 ee9f1c10
ee9f1c44 bf2f9c5c c05693bc
[ 3044.587298] bf20: ee9f1c10 bf2f9c5c 0001f10c 00000800 c0101204
c05694cc bf2f9c5c bf2fb980
[ 3044.596316] bf40: 0001f10c c056829c c0f08c48 c01b3c34 76756f6e
00756165 00000000 00000000
[ 3044.605356] bf60: c0f08c48 ec415000 00000002 5dfe844b 00000001
c0141c10 ec415000 ec415000
[ 3044.614431] bf80: ed67c100 5dfe844b 00000000 5dfe844b 00000000
00000002 bebb5ba8 00000000
[ 3044.623529] bfa0: 00000081 c0101000 00000002 bebb5ba8 0001f10c
00000800 0000000a 00000000
[ 3044.632631] bfc0: 00000002 bebb5ba8 00000000 00000081 bebb5e9b
0001f0d0 bebb5d8c 00000001
[ 3044.641739] bfe0: b6e74730 bebb5b64 00012bdf b6e7473c 600d0010
0001f10c 00000000 00000000
[ 3044.650884] [<c048d05c>] (pci_disable_device) from [<ee9f1c8c>]
(0xee9f1c8c)
[ 3044.658410] Code: eafffff0 ebf25973 e92d4030 e1a04000 (e5d0338a) 
[ 3044.665141] ---[ end trace 810af3dad648a902 ]---
Segmentation fault

Looks like with pci_disable_device() it may take a rather strange
path...

> Thanks,
> Thierry

Cheers

Marcel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ 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