* [PATCH 00/12] i.MX media devices and connections
From: Steve Longerbeam @ 2016-12-08 0:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Philipp, Sascha, Shawn, et al,
I've been working for the past few months on a media driver for i.MX.
In addition to the media entities for the IPU-external units involved
with video capture (video mux and MIPI CSI-2 receiver), I've created
media entities for the IPU CSI, SMFC, and IC subunits. The IC entities
carry out scaling, CSC, horizontal/vertical flip, and rotation. In
addition, the IC-PRPVF entity carries out motion compensated
de-interlace.
The following series adds the OF device nodes and graphs that define
all the possible hardware connections supported by the i.MX involved
in video capture and image conversion.
Here are some of the pipelines defined by the OF graphs:
CSI -> IC-PRPENC
CSI -> IC-PRPVF
CSI -> IC-PRPVF -> IC-PP
CSI -> SMFC
CSI -> SMFC -> IC-PRPVF
CSI -> SMFC -> IC-PP
CSI -> SMFC -> IC-PRPVF -> IC-PP
You will notice that three IC-PP nodes are defined (ipu1_ic_pp0,
ipu1_ic_pp1, ipu1_ic_pp2, and same for ipu2). The reason for that
is that the IC-PP media entity uses the new ipu-image-conversion
API, which allows for multiple conversion contexts to be created.
Each IC-PP entity thus creates its own conversion context, and there
can be any number of IC-PP entities instantiated as needed by the OF
graph.
Camera sensor nodes are also added for the SabreAuto, SabreSD, and
SabreLite reference platforms.
The media driver is now in fairly good shape. It parses the OF graphs
to create the media pads and links. All the pipelines defined by the
OF graphs have been tested and are working. My media driver work is
at:
git at github.com:slongerbeam/mediatree.git, branch imx-media-staging-md-v2.
For an overview of the pipelines supported and usage notes for the
reference boards, you can refer to Documentation/media/v4l-drivers/imx.rst.
I realize there is collision here with the recent patch series posted by
Philipp, particularly around the video multiplexer and mipi csi-2 receiver
subdevs and OF graphs, as well as v4l2 capture drivers.
Philipp Zabel (1):
ARM: dts: imx6qdl: add video capture devices and connections
Steve Longerbeam (11):
ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node
ARM: dts: imx6qdl: rename ipu client nodes
ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
ARM: dts: imx6-sabreauto: create i2cmux for i2c3
ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b
ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
gpu: ipu-v3: Add ipu_unit_type enumeration
gpu: ipu-v3: lookup ipu client nodes by name
gpu: ipu-v3: Add smfc and ic client devices
arch/arm/boot/dts/imx6dl-sabrelite.dts | 5 +
arch/arm/boot/dts/imx6dl-sabresd.dts | 5 +
arch/arm/boot/dts/imx6dl.dtsi | 190 ++++++++++++
arch/arm/boot/dts/imx6q-sabrelite.dts | 6 +
arch/arm/boot/dts/imx6q-sabresd.dts | 5 +
arch/arm/boot/dts/imx6q.dtsi | 497 ++++++++++++++++++++++++++++++-
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 148 +++++++--
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 122 +++++++-
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 114 ++++++-
arch/arm/boot/dts/imx6qdl.dtsi | 385 +++++++++++++++++++++++-
drivers/gpu/ipu-v3/ipu-common.c | 142 ++++++++-
include/video/imx-ipu-v3.h | 21 ++
12 files changed, 1593 insertions(+), 47 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH] ARM: dts: imx7d: fix LCDIF clock assignment
From: Shawn Guo @ 2016-12-08 0:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207205314.GA20203@localhost>
On Wed, Dec 07, 2016 at 12:53:14PM -0800, Olof Johansson wrote:
> Applied, with the fixes line. In the future, please email arm at kernel.org too,
> it's easier to make sure we don't miss it that way.
Noted. Thanks, Olof.
Shawn
^ permalink raw reply
* [PATCH v3 2/2] clk: uniphier: add cpufreq data for LD11, LD20 SoCs
From: Stephen Boyd @ 2016-12-08 0:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481074353-31535-2-git-send-email-yamada.masahiro@socionext.com>
On 12/07, Masahiro Yamada wrote:
> Add more data to 64bit SoCs for the cpufreq support.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 1/2] clk: uniphier: add CPU-gear change (cpufreq) support
From: Stephen Boyd @ 2016-12-08 0:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481074353-31535-1-git-send-email-yamada.masahiro@socionext.com>
On 12/07, Masahiro Yamada wrote:
> Core support code for CPU frequency changes, which will be used by
> the generic cpufreq driver.
>
> The register view is different from the generic clk-mux; it has
> a separate status register, and an update bit to load the register
> setting.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] drm: hdlcd: Work properly in big-endian mode
From: Ilia Mirkin @ 2016-12-08 0:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <548dc9d9-4d21-7f93-cc92-5bc3234f1b8f@arm.com>
On Wed, Dec 7, 2016 at 11:42 AM, Robin Murphy <robin.murphy@arm.com> wrote:
> By comparison, the same use-cases (fbcon and fb-test) under the same
> big-endian kernel do *not* show the same problem with nouveau driving a
> PCIe 7600GT card, which led me to believe it was HDLCD-specific.
Just to randomly insert info here... NV11+ cards have a "big endian"
mode, where you can do 32-bit mmio from a big-endian cpu, and the card
will auto-swap those. There are similar additional bits that make
operating and accelerating off a big-endian CPU tolerable. Some care
has gone into the kernel to make sure that all that stuff works. (One
of those bits is that data gets byteswapped on upload to VRAM by
virtue of being uploaded by sticking data into a pushbuf, as I
recall.)
-ilia
^ permalink raw reply
* [PATCH v2.1 1/4] ARM: dts: davinci: da850: VPIF: add node and muxing
From: Kevin Hilman @ 2016-12-08 0:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207193137.27947-2-khilman@baylibre.com>
Add VPIF node an pins to da850 and enable on boards. VPIF has two input
channels described using the standard DT ports and enpoints.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
v2 -> v2.1: moved ports from SoC .dtsi to board .dts files.
arch/arm/boot/dts/da850-evm.dts | 20 ++++++++++++++++++++
arch/arm/boot/dts/da850-lcdk.dts | 13 +++++++++++++
arch/arm/boot/dts/da850.dtsi | 27 ++++++++++++++++++++++++++-
3 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 41de15fe15a2..cea36ee6fd07 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -289,3 +289,23 @@
};
};
};
+
+&vpif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&vpif_capture_pins>;
+ status = "okay";
+
+ /* VPIF capture port */
+ port {
+ vpif_ch0: endpoint at 0 {
+ reg = <0>;
+ bus-width = <8>;
+ };
+
+ vpif_ch1: endpoint at 1 {
+ reg = <1>;
+ bus-width = <8>;
+ data-shift = <8>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21fed6c..5fc21528e0ba 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -219,3 +219,16 @@
};
};
};
+
+&vpif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&vpif_capture_pins>;
+ status = "okay";
+
+ /* VPIF capture port */
+ port {
+ vpif_ch0: endpoint {
+ bus-width = <8>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b91c680..5f0b40510b2b 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -186,7 +186,18 @@
0xc 0x88888888 0xffffffff
>;
};
-
+ vpif_capture_pins: vpif_capture_pins {
+ pinctrl-single,bits = <
+ /* VP_DIN[2..7], VP_CLKIN1, VP_CLKIN0 */
+ 0x38 0x11111111 0xffffffff
+ /* VP_DIN[10..15,0..1] */
+ 0x3c 0x11111111 0xffffffff
+ /* VP_DIN[8..9] */
+ 0x40 0x00000011 0x000000ff
+ /* VP_CLKIN3, VP_CLKIN2 */
+ 0x4c 0x00010100 0x000f0f00
+ >;
+ };
};
edma0: edma at 0 {
compatible = "ti,edma3-tpcc";
@@ -399,7 +410,21 @@
<&edma0 0 1>;
dma-names = "tx", "rx";
};
+
+ vpif: video at 217000 {
+ compatible = "ti,da850-vpif";
+ reg = <0x217000 0x1000>;
+ interrupts = <92>;
+ status = "disabled";
+
+ /* VPIF capture port */
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
};
+
aemif: aemif at 68000000 {
compatible = "ti,da850-aemif";
#address-cells = <2>;
--
2.9.3
^ permalink raw reply related
* linux-next: manual merge of the sunxi tree with the arm-soc tree
From: Stephen Rothwell @ 2016-12-08 0:13 UTC (permalink / raw)
To: linux-arm-kernel
Hi Maxime,
Today's linux-next merge of the sunxi tree got a conflict in:
arch/arm/boot/dts/sun8i-h3.dtsi
between commit:
4367c1d84655 ("dts: sun8i-h3: correct UART3 pin definitions")
from the arm-soc tree and commits:
acac77949d26 ("ARM: sunxi: Remove useless allwinner,drive property")
3872abae96ef ("ARM: sunxi: Remove useless allwinner,pull property")
264969c22623 ("ARM: sunxi: Convert pinctrl nodes to generic bindings")
from the sunxi tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/boot/dts/sun8i-h3.dtsi
index 6c14a6f72820,fca66bf2dec5..000000000000
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@@ -425,10 -406,8 +406,8 @@@
};
uart3_pins: uart3 {
- allwinner,pins = "PA13", "PA14";
- allwinner,function = "uart3";
- allwinner,drive = <SUN4I_PINCTRL_10_MA>;
- allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
- pins = "PG13", "PG14";
++ pins = "PA13", "PA14";
+ function = "uart3";
};
};
^ permalink raw reply
* [PATCH 3/3] clk: keystone: Add sci-clk driver support
From: Stephen Boyd @ 2016-12-08 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477053961-27128-4-git-send-email-t-kristo@ti.com>
On 10/21, Tero Kristo wrote:
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 6a8ac04..dce08a7 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -169,6 +169,15 @@ config COMMON_CLK_NXP
> ---help---
> Support for clock providers on NXP platforms.
>
> +config TI_SCI_CLK
> + tristate "TI System Control Interface clock drivers"
> + depends on (TI_SCI_PROTOCOL && COMMON_CLK_KEYSTONE) || COMPILE_TEST
Given that we depend on COMMON_CLK_KEYSTONE (just for the
Makefile dependency?) this should be moved to right below the
COMMON_CLK_KEYSTONE config. And we should consider making a
Kconfig file in drivers/clk/keystone/ to hold both those configs
instead of having them at the toplevel.
> + default TI_SCI_PROTOCOL
> + ---help---
> + This adds the clock driver support over TI System Control Interface.
> + If you wish to use clock resources from the PMMC firmware, say Y.
> + Otherwise, say N.
> +
> config COMMON_CLK_PALMAS
> tristate "Clock driver for TI Palmas devices"
> depends on MFD_PALMAS
> diff --git a/drivers/clk/keystone/Makefile b/drivers/clk/keystone/Makefile
> index 0477cf6..0e7993d 100644
> --- a/drivers/clk/keystone/Makefile
> +++ b/drivers/clk/keystone/Makefile
> @@ -1 +1,2 @@
> obj-y += pll.o gate.o
> +obj-$(CONFIG_TI_SCI_CLK) += sci-clk.o
> diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c
> new file mode 100644
> index 0000000..f6af5bd
> --- /dev/null
> +++ b/drivers/clk/keystone/sci-clk.c
> @@ -0,0 +1,589 @@
[...]
> +
> +/**
> + * sci_clk_recalc_rate - Get clock rate for a TI SCI clock
> + * @hw: clock to get rate for
> + * @parent_rate: parent rate provided by common clock framework, not used
> + *
> + * Gets the current clock rate of a TI SCI clock. Returns the current
> + * clock rate, or zero in failure.
> + */
> +static unsigned long sci_clk_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct sci_clk *clk = to_sci_clk(hw);
> + u64 freq;
> + int ret;
> +
> + ret = clk->provider->ops->get_freq(clk->provider->sci, clk->dev_id,
> + clk->clk_id, &freq);
> + if (ret) {
> + dev_err(clk->provider->dev,
> + "recalc-rate failed for dev=%d, clk=%d, ret=%d\n",
> + clk->dev_id, clk->clk_id, ret);
> + return 0;
> + }
> +
> + return (u32)freq;
Do we need the cast? sizeof(u32) doesn't always equal
sizeof(unsigned long).
> +
> +/**
> + * _sci_clk_get - Gets a handle for an SCI clock
> + * @provider: Handle to SCI clock provider
> + * @dev_id: device ID for the clock to register
> + * @clk_id: clock ID for the clock to register
> + *
> + * Gets a handle to an existing TI SCI hw clock, or builds a new clock
> + * entry and registers it with the common clock framework. Called from
> + * the common clock framework, when a corresponding of_clk_get call is
> + * executed, or recursively from itself when parsing parent clocks.
> + * Returns a pointer to the hw clock struct, or ERR_PTR value in failure.
> + */
> +static struct clk_hw *_sci_clk_build(struct sci_clk_provider *provider,
> + u16 dev_id, u8 clk_id)
> +{
> + struct clk_init_data init = { NULL };
> + struct sci_clk *sci_clk = NULL;
> + char *name = NULL;
> + char **parent_names = NULL;
> + int i;
> + int ret;
> +
> + sci_clk = devm_kzalloc(provider->dev, sizeof(*sci_clk), GFP_KERNEL);
> + if (!sci_clk)
> + return ERR_PTR(-ENOMEM);
> +
> + sci_clk->dev_id = dev_id;
> + sci_clk->clk_id = clk_id;
> + sci_clk->provider = provider;
> +
> + ret = provider->ops->get_num_parents(provider->sci, dev_id,
> + clk_id,
> + &init.num_parents);
> + if (ret)
> + goto err;
> +
> + name = kasprintf(GFP_KERNEL, "%s:%d:%d", dev_name(provider->dev),
> + sci_clk->dev_id, sci_clk->clk_id);
> +
> + init.name = name;
> +
> + if (init.num_parents < 2)
> + init.num_parents = 0;
This deserves a comment. Why is num_parents == 1 the same as
num_parents == 0?
> +
> + if (init.num_parents) {
> + parent_names = devm_kcalloc(provider->dev, init.num_parents,
> + sizeof(char *), GFP_KERNEL);
> +
> + if (!parent_names) {
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + for (i = 0; i < init.num_parents; i++) {
> + char *parent_name;
> +
> + parent_name = kasprintf(GFP_KERNEL, "%s:%d:%d",
> + dev_name(provider->dev),
> + sci_clk->dev_id,
> + sci_clk->clk_id + 1 + i);
> + if (!parent_name) {
> + ret = -ENOMEM;
> + goto err;
> + }
> + parent_names[i] = parent_name;
> + }
> + init.parent_names = (const char * const *)parent_names;
Does that really need a cast?
> + }
> +
> + init.ops = &sci_clk_ops;
> + sci_clk->hw.init = &init;
> +
> + ret = devm_clk_hw_register(provider->dev, &sci_clk->hw);
> + if (ret) {
> + dev_err(provider->dev, "failed clk register with %d\n", ret);
> + goto err;
> + }
> + kfree(name);
> +
> + return &sci_clk->hw;
> +
> +err:
> + if (parent_names) {
> + for (i = 0; i < init.num_parents; i++)
> + devm_kfree(provider->dev, parent_names[i]);
> +
> + devm_kfree(provider->dev, parent_names);
Shouldn't we be freeing the parent names all the time? It should
be deep copied in the framework.
> + }
> +
> + devm_kfree(provider->dev, sci_clk);
> +
> + kfree(name);
> +
> + return ERR_PTR(ret);
> +}
[..]
> +
> +static int ti_sci_init_clocks(struct sci_clk_provider *p)
> +{
> + struct sci_clk_data *data = p->clocks;
> + struct clk_hw *hw;
> + int i;
> +
> + while (data->num_clks) {
> + data->clocks = devm_kcalloc(p->dev, data->num_clks,
> + sizeof(struct sci_clk),
> + GFP_KERNEL);
> + if (!data->clocks)
> + return -ENOMEM;
> +
> + for (i = 0; i < data->num_clks; i++) {
> + hw = _sci_clk_build(p, data->dev, i);
> + if (!IS_ERR(hw)) {
> + data->clocks[i] = hw;
> + continue;
> + }
> +
> + /* Skip any holes in the clock lists */
> + if (PTR_ERR(hw) == -ENODEV)
Does this happen? I don't see where _sci_clk_build() returns
-ENODEV.
> + continue;
> +
> + return PTR_ERR(hw);
> + }
> + data++;
> + }
> +
> + return 0;
> +}
> +
> +
> +/**
> + * ti_sci_clk_probe - Probe function for the TI SCI clock driver
> + * @pdev: platform device pointer to be probed
> + *
> + * Probes the TI SCI clock device. Allocates a new clock provider
> + * and registers this to the common clock framework. Also applies
> + * any required flags to the identified clocks via clock lists
> + * supplied from DT. Returns 0 for success, negative error value
> + * for failure.
> + */
> +static int ti_sci_clk_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + struct sci_clk_provider *provider;
> + const struct ti_sci_handle *handle;
> + struct sci_clk_data *data;
> + int ret;
> +
> + data = (struct sci_clk_data *)
> + of_match_node(ti_sci_clk_of_match, np)->data;
Just use of_device_get_match_data() instead.
> +
> + handle = devm_ti_sci_get_handle(dev);
> + if (IS_ERR(handle))
> + return PTR_ERR(handle);
> +
> + provider = devm_kzalloc(dev, sizeof(*provider), GFP_KERNEL);
> + if (!provider)
> + return -ENOMEM;
> +
> + provider->clocks = data;
> +
> + provider->sci = handle;
> + provider->ops = &handle->ops.clk_ops;
> + provider->dev = dev;
> +
> + ti_sci_init_clocks(provider);
And if this fails?
> +
> + ret = of_clk_add_hw_provider(np, sci_clk_get, provider);
> + if (ret)
> + return ret;
> +
> + return 0;
Just "return of_clk_add_hw_provider()" please.
> +}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] PM / Domains: Fix compatible for domain idle state
From: Rafael J. Wysocki @ 2016-12-08 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1616414.c1s7NxTqJS@aspire.rjw.lan>
On Thursday, December 01, 2016 10:21:59 PM Rafael J. Wysocki wrote:
> On Tuesday, November 29, 2016 09:47:03 AM Ulf Hansson wrote:
> > On 10 November 2016 at 20:58, Rob Herring <robh@kernel.org> wrote:
> > > On Mon, Nov 07, 2016 at 12:14:28PM +0100, Ulf Hansson wrote:
> > >> On 3 November 2016 at 22:54, Lina Iyer <lina.iyer@linaro.org> wrote:
> > >> > Re-using idle state definition provided by arm,idle-state for domain
> > >> > idle states creates a lot of confusion and limits further evolution of
> > >> > the domain idle definition. To keep things clear and simple, define a
> > >> > idle states for domain using a new compatible "domain-idle-state".
> > >> >
> > >> > Fix existing PM domains code to look for the newly defined compatible.
> > >> >
> > >> > Cc: <devicetree@vger.kernel.org>
> > >> > Cc: Rob Herring <robh@kernel.org>
> > >> > Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> > >> > ---
> > >> > .../bindings/power/domain-idle-state.txt | 33 ++++++++++++++++++++++
> > >> > .../devicetree/bindings/power/power_domain.txt | 8 +++---
> > >> > drivers/base/power/domain.c | 2 +-
> > >> > 3 files changed, 38 insertions(+), 5 deletions(-)
> > >> > create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt
> > >> >
> > >> > diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.txt b/Documentation/devicetree/bindings/power/domain-idle-state.txt
> > >> > new file mode 100644
> > >> > index 0000000..eefc7ed
> > >> > --- /dev/null
> > >> > +++ b/Documentation/devicetree/bindings/power/domain-idle-state.txt
> > >> > @@ -0,0 +1,33 @@
> > >> > +PM Domain Idle State Node:
> > >> > +
> > >> > +A domain idle state node represents the state parameters that will be used to
> > >> > +select the state when there are no active components in the domain.
> > >> > +
> > >> > +The state node has the following parameters -
> > >> > +
> > >> > +- compatible:
> > >> > + Usage: Required
> > >> > + Value type: <string>
> > >> > + Definition: Must be "domain-idle-state".
> > >> > +
> > >> > +- entry-latency-us
> > >> > + Usage: Required
> > >> > + Value type: <prop-encoded-array>
> > >> > + Definition: u32 value representing worst case latency in
> > >> > + microseconds required to enter the idle state.
> > >> > + The exit-latency-us duration may be guaranteed
> > >> > + only after entry-latency-us has passed.
> > >>
> > >> As we anyway are going to change this, why not use an u64 and have the
> > >> value in ns instead of us?
> > >
> > > I can't imagine that you would need more resolution or range. For times
> > > less than 1us, s/w and register access times are going to dominate the
> > > time.
> > >
> > > Unless there is a real need, I'd keep alignment with the existing
> > > binding.
> >
> > Rob, are you fine with this? I thought it would be great to get this
> > in for 4.10 rc1.
>
> Rob, any objections here?
Well, no objections, so applied.
Thanks,
Rafael
^ permalink raw reply
* [PATCH] drm: hdlcd: Work properly in big-endian mode
From: Daniel Vetter @ 2016-12-07 23:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <36dcbbc5-607a-1773-17e4-af2a9810a06e@arm.com>
On Wed, Dec 07, 2016 at 04:50:31PM +0000, Robin Murphy wrote:
> On 07/12/16 16:42, Robin Murphy wrote:
> > On 07/12/16 15:57, Daniel Vetter wrote:
> >> On Wed, Dec 07, 2016 at 03:31:40PM +0000, Robin Murphy wrote:
> >>> Under a big-endian kernel, colours on the framebuffer all come out a
> >>> delightful shade of wrong, since we fail to take the reversed byte
> >>> order into account. Fortunately, the HDLCD has a control bit to make it
> >>> automatically byteswap big-endian data; let's use it as appropriate.
> >>>
> >>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >>
> >> fourcc codes (and the drm fourcc codes) are supposed to be little-endian.
> >> All of them. So either we fix up the drivers and userspace to set that
> >> flag correctly (which would mean hdlcd should expose twice as many
> >> formats, each one with the little and big endian mode).
> >
> > AFAICS, SIMPLEFB_FORMATS *is* supposed to be explicitly little-endian
> > modes. I see that DRM_FORMAT_BIG_ENDIAN exists, but nothing in-tree ever
> > sets it :/
> >
> > My vague (and probably wrong) assumption was that the HDLCD is still
> > expecting little-endian data, but the the CPU is writing framebuffer
> > data as host-endian words, hence what the HDLCD thinks is xRGB is
> > actually RGBx under a big-endian kernel - It's certainly consistent
> > between kernel (fbcon) and userspace (fb-test[1]): white is yellow, blue
> > is black, green is red and red is green. I don't know how to test
> > "proper" DRM (I've failed to get X to work with the Arch Linux ARM
> > distro I have on there at the moment).
> >
> > Once again I'm somewhat out of my depth here - I just found a thing that
> > seemed appropriate and visibly resolved the immediate problem :)
> > By comparison, the same use-cases (fbcon and fb-test) under the same
> > big-endian kernel do *not* show the same problem with nouveau driving a
> > PCIe 7600GT card, which led me to believe it was HDLCD-specific.
>
> Off the back of that, upon closer inspection, nv_crtc_commit() would
> appear to already be doing very much the equivalent thing to what I'm
> doing in this patch, so now I have no idea whether this is right or
> everything's wrong.
Congrats for finding a really big can of worms. Unfortunately I can't
really help you with figuring out what's the right choice here :(
Trying to fix up everything is probably going to be lots of work, but
assuming that everything is broken for big endian is probably correct.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH] USB: OHCI: nxp: fix code warnings
From: csmanjuvijay at gmail.com @ 2016-12-07 23:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Manjunath Goudar <csmanjuvijay@gmail.com>
This patch will fix the checkpatch.pl following warnings:
WARNING: Missing a blank line after declarations
WARNING: braces {} are not necessary for single statement blocks
Signed-off-by: Manjunath Goudar <csmanjuvijay@gmail.com>
Cc: Vladimir Zapolskiy <vz@mleia.com>
Cc: Sylvain Lemieux <slemieux.tyco@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-usb at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
---
drivers/usb/host/ohci-nxp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-nxp.c b/drivers/usb/host/ohci-nxp.c
index 1843f04..6df8e2e 100644
--- a/drivers/usb/host/ohci-nxp.c
+++ b/drivers/usb/host/ohci-nxp.c
@@ -125,6 +125,7 @@ static inline void isp1301_vbus_off(void)
static void ohci_nxp_start_hc(void)
{
unsigned long tmp = __raw_readl(USB_OTG_STAT_CONTROL) | HOST_EN;
+
__raw_writel(tmp, USB_OTG_STAT_CONTROL);
isp1301_vbus_on();
}
@@ -132,6 +133,7 @@ static void ohci_nxp_start_hc(void)
static void ohci_nxp_stop_hc(void)
{
unsigned long tmp;
+
isp1301_vbus_off();
tmp = __raw_readl(USB_OTG_STAT_CONTROL) & ~HOST_EN;
__raw_writel(tmp, USB_OTG_STAT_CONTROL);
@@ -153,9 +155,8 @@ static int ohci_hcd_nxp_probe(struct platform_device *pdev)
}
isp1301_i2c_client = isp1301_get_client(isp1301_node);
- if (!isp1301_i2c_client) {
+ if (!isp1301_i2c_client)
return -EPROBE_DEFER;
- }
ret = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (ret)
--
2.7.4
^ permalink raw reply related
* [PATCH 08/16] drivers/fsi: Add crc4 helpers
From: Jeremy Kerr @ 2016-12-07 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207090219.GA14742@kroah.com>
Hi Greg,
> Why not just create lib/crc4.c with these functions, like the other crc
> functions in the kernel?
Two (bad) reasons:
- The crc4 implementation here is pretty specific to the FSI
usage (only supporting 4-bit-sized chunks), to keep the math & lookup
table simple
- I'm lazy
So yes, we should spend the effort now to make this generic enough for
a lib/crc4.c. Would we want to support different values for the
polynomial?
Chris: do you want me to to that, or will you?
Cheers,
Jeremy
^ permalink raw reply
* [PATCH 05/16] drivers/fsi: Add fake master driver
From: Jeremy Kerr @ 2016-12-07 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207120905.GD7054@leverpostej>
Hi Mark & Chris,
> On Tue, Dec 06, 2016 at 06:14:26PM -0600, Chris Bostic wrote:
>> From: Jeremy Kerr <jk@ozlabs.org>
>>
>> For debugging, add a fake master driver, that only supports reads,
>> returning a fixed set of data.
>
>> +config FSI_MASTER_FAKE
>> + tristate "Fake FSI master"
>> + depends on FSI
>> + ---help---
>> + This option enables a fake FSI master driver for debugging.
>> +endif
>
>> +static const struct of_device_id fsi_master_fake_match[] = {
>> + { .compatible = "ibm,fsi-master-fake" },
>> + { },
>> +};
>
> NAK.
>
> DT should be treated as an ABI, and should describe the HW explicitly.
> This makes no sense. This is also missing a binding document.
>
> Have your module take a module parameter allowing you to bind it to
> arbitrary devices, or do something like what PCI does where you can
> bind/unbind arbitrary drivers to devices using sysfs.
This driver is purely for testing the FSI engine scan code; we could
probably just drop this patch since I suspect that it's no longer useful
(now that we have an actual master driver).
If we do want to keep it though, I'd say we remove the device tree
dependency; all this is doing at the moment is triggering the ->probe,
and there are better ways to do that.
Cheers,
Jeremy
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: zx: Fix gic GICR property
From: Arnd Bergmann @ 2016-12-07 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMh5=R18+wfM5WjUPnQ2a7UFi35t11cRDyTwCYHxpySnMg@mail.gmail.com>
On Wednesday, December 7, 2016 2:12:23 PM CET Olof Johansson wrote:
> > I checked the other branches now and found two other commits missing
> > in next/fixes-non-critical:
> >
> >
> > arm64: tegra: Add missing Smaug revision
> > arm64: tegra: Add VDD_GPU regulator to Jetson TX1
> >
> > Both sent by Thierry Reding last Friday. I can add them back on top
> > or you pick them up again if you are already busy doing merges.
> >
> > For the first patch, I had amended the changelog text, this is the
> > version I had.
>
> I'm done touching the tree for today so you can rebase and push your
> versions if you want -- probably easiest all around.
>
Done.
Arnd
^ permalink raw reply
* [PATCH v2 1/4] ARM: dts: davinci: da850: VPIF: add node and muxing
From: Kevin Hilman @ 2016-12-07 23:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37047453.6bLpOkkjm4@avalon>
Laurent Pinchart <laurent.pinchart@ideasonboard.com> writes:
> Hi Kevin,
>
> Thank you for the patch.
>
> On Wednesday 07 Dec 2016 11:31:34 Kevin Hilman wrote:
>> Add VPIF node an pins to da850 and enable on boards. VPIF has two input
>> channels described using the standard DT ports and enpoints.
>>
>> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>> ---
>> arch/arm/boot/dts/da850-evm.dts | 6 ++++++
>> arch/arm/boot/dts/da850-lcdk.dts | 6 ++++++
>> arch/arm/boot/dts/da850.dtsi | 38 +++++++++++++++++++++++++++++++++++-
>> 3 files changed, 49 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/da850-evm.dts
>> b/arch/arm/boot/dts/da850-evm.dts index 41de15fe15a2..212b50d4f84b 100644
>> --- a/arch/arm/boot/dts/da850-evm.dts
>> +++ b/arch/arm/boot/dts/da850-evm.dts
>> @@ -289,3 +289,9 @@
>> };
>> };
>> };
>> +
>> +&vpif {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&vpif_capture_pins>;
>> + status = "okay";
>> +};
>> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
>> b/arch/arm/boot/dts/da850-lcdk.dts index 7b8ab21fed6c..67f846f5bb35 100644
>> --- a/arch/arm/boot/dts/da850-lcdk.dts
>> +++ b/arch/arm/boot/dts/da850-lcdk.dts
>> @@ -219,3 +219,9 @@
>> };
>> };
>> };
>> +
>> +&vpif {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&vpif_capture_pins>;
>> + status = "okay";
>> +};
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index f79e1b91c680..dd2a13ed106e 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -186,7 +186,18 @@
>> 0xc 0x88888888 0xffffffff
>>
>> >;
>>
>> };
>> -
>> + vpif_capture_pins: vpif_capture_pins {
>> + pinctrl-single,bits = <
>> + /* VP_DIN[2..7], VP_CLKIN1, VP_CLKIN0
> */
>> + 0x38 0x11111111 0xffffffff
>> + /* VP_DIN[10..15,0..1] */
>> + 0x3c 0x11111111 0xffffffff
>> + /* VP_DIN[8..9] */
>> + 0x40 0x00000011 0x000000ff
>> + /* VP_CLKIN3, VP_CLKIN2 */
>> + 0x4c 0x00010100 0x000f0f00
>> + >;
>> + };
>> };
>> edma0: edma at 0 {
>> compatible = "ti,edma3-tpcc";
>> @@ -399,7 +410,32 @@
>> <&edma0 0 1>;
>> dma-names = "tx", "rx";
>> };
>> +
>> + vpif: video at 217000 {
>> + compatible = "ti,da850-vpif";
>> + reg = <0x217000 0x1000>;
>> + interrupts = <92>;
>> + status = "disabled";
>> +
>> + /* VPIF capture: input channels */
>> + port {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + vpif_ch0: endpoint at 0 {
>> + reg = <0>;
>> + bus-width = <8>;
>> + };
>> +
>> + vpif_ch1: endpoint at 1 {
>> + reg = <1>;
>> + bus-width = <8>;
>> + data-shift = <8>;
>> + };
>
> Given that the VPIF can also accept a single 16-bit input, I'd move the
> endpoints to board files.
>
Yes, good point. Will move them.
Kevin
^ permalink raw reply
* [PATCH v2] ARM: dts: lpc32xx: add pwm-cells to base dts file
From: Vladimir Zapolskiy @ 2016-12-07 22:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481139047-13166-1-git-send-email-slemieux.tyco@gmail.com>
Hi Sylvain,
On 12/07/2016 09:30 PM, Sylvain Lemieux wrote:
> From: Sylvain Lemieux <slemieux@tycoint.com>
>
> There is no need to define the "pwm-cells" in the board
> specific dts file; move the entry to the base dts file.
>
> Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
> ---
thank you for the change,
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH] clk: uniphier: Fix build with gcc-4.4.
From: Arnd Bergmann @ 2016-12-07 22:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206231642.GA4388@codeaurora.org>
On Tuesday, December 6, 2016 3:16:42 PM CET Stephen Boyd wrote:
> On 12/03, Masahiro Yamada wrote:
> > 2016-12-03 9:37 GMT+09:00 Vinson Lee <vlee@freedesktop.org>:
> > > gcc-4.4 has issues with anonymous unions in initializers.
> > >
> > > CC drivers/clk/uniphier/clk-uniphier-sys.o
> > > drivers/clk/uniphier/clk-uniphier-sys.c:45: error: unknown field ?factor? specified in initializer
> > >
> I'll go drop all three patches and wreck Andrew's merge of this
> patch to -mm.
While the specific bug is resolved now, I'm curious about the
motivation for the first fix: Vinson, are you actually using
a seven year old compiler to build modern kernels in order
to run them on real systems, or is this for the purpose of
build testing only?
It would be good to know if there are actual requirements
for using compilers this old (or even older, as according
to the README file, we theoretically support building even
with gcc-3.2 from 2002), in case we ever want to officially
raise the minimum required versions.
I see that gcc-4.3 builds an ARM defconfig kernel 17% faster than
gcc-7.0, which may be nice for build testing, but it also produces
thousands of false-positive warnings, which makes it rather
useless for actually finding bugs in build testing.
Arnd
^ permalink raw reply
* [PATCH v2 3/3] USB: OHCI: nxp: remove useless extern declaration
From: csmanjuvijay at gmail.com @ 2016-12-07 22:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481150056-3623-1-git-send-email-csmanjuvijay@gmail.com>
From: Manjunath Goudar <csmanjuvijay@gmail.com>
Remove usb_disabled() extern declaration as it is already declared
as extern in include/linux/usb.h.
Signed-off-by: Manjunath Goudar <csmanjuvijay@gmail.com>
Cc: Vladimir Zapolskiy <vz@mleia.com>
Cc: Sylvain Lemieux <slemieux.tyco@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-usb at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
---
changelog V1->V2:
patch discrition is update with proper message.
drivers/usb/host/ohci-nxp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/host/ohci-nxp.c b/drivers/usb/host/ohci-nxp.c
index b7d4756..1843f04 100644
--- a/drivers/usb/host/ohci-nxp.c
+++ b/drivers/usb/host/ohci-nxp.c
@@ -56,8 +56,6 @@ static struct hc_driver __read_mostly ohci_nxp_hc_driver;
static struct i2c_client *isp1301_i2c_client;
-extern int usb_disabled(void);
-
static struct clk *usb_host_clk;
static void isp1301_configure_lpc32xx(void)
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 00/23] arm: defconfigs: use kconfig fragments
From: Olof Johansson @ 2016-12-07 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9c0ed8c5-406a-9304-48b5-6f11f3940271@redhat.com>
On Wed, Dec 7, 2016 at 1:56 PM, Laura Abbott <labbott@redhat.com> wrote:
> On 12/07/2016 01:35 PM, Arnd Bergmann wrote:
>> On Wednesday, December 7, 2016 1:14:02 PM CET Olof Johansson wrote:
>>>>
>>>> - A "debug" fragment would be nice, to turn on common options that
>>>> add a lot of useful runtime checks at the expense of performance
>>>> or code size.
>>>
>>> Hmm, some of these might work but several useful debug options (in
>>> particular DEBUG_LL for early errors) are per-system/platform.
>>
>> I was thinking mostly of architecture-independent options, i.e.
>> the stuff that is in lib/Kconfig.debug but isn't too expensive
>> to be run in a regular test environment. Enabling those
>> for a build/boot automation environment would be particularly
>> useful as you'd catch more bugs that get introduced through
>> a random patch.
>>
>>>> - A "distro" fragment that turns on all loadable modules that are
>>>> enabled by common distributions (e.g. two or more of
>>>> debian/fedora/opensuse/gentoo), to let you build a drop-in
>>>> replacement kernel for a shipping distro. This would also allow
>>>> the distros to strip their own config files and just specify
>>>> whatever differs from the others.
>>>
>>> Keeping this in sync with the distro kernel could be a bit awkward
>>> (and possibly churny).
>>
>> It would certainly need buy-in from distro maintainers. I've discussed
>> this with Laura Abbott in the past, and she was interested in
>> principle.
>>
>> Arnd
>>
>
> Yes, I've gotten the request from multiple people now about having
> some Fedora config in mainline. I agree that churn and keeping in
> sync would be a concern. For a first pass, I was going to propose
> a minimal set of options that are unlikely to need to churn. Once
> those are agreed on, everything else could become a separate .config.
> My plan was to send a patch out around -rc2/-rc3 each cycle to sync
> up.
That sounds reasonable to me -- we could add it as
fedora_<something>_defconfig. Ideally just one per distro (for their
multi-platform target), if possible. Makes sense to get coverage of
this on builders, etc, as well.
-Olof
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: zx: Fix gic GICR property
From: Olof Johansson @ 2016-12-07 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5275588.dlJdb2OzJi@wuerfel>
Hi,
On Wed, Dec 7, 2016 at 1:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, December 7, 2016 12:34:12 PM CET Olof Johansson wrote:
>>
>> So, it seems that Arnd didn't apply the old patch to fixes-non-critical, or
>> at least didn't push out after doing it. So, I've done that now, as well as
>> applied the fixup you have above.
>>
>
> My mistake, I forgot to push it out.
No worries.
> I checked the other branches now and found two other commits missing
> in next/fixes-non-critical:
>
>
> arm64: tegra: Add missing Smaug revision
> arm64: tegra: Add VDD_GPU regulator to Jetson TX1
>
> Both sent by Thierry Reding last Friday. I can add them back on top
> or you pick them up again if you are already busy doing merges.
>
> For the first patch, I had amended the changelog text, this is the
> version I had.
I'm done touching the tree for today so you can rebase and push your
versions if you want -- probably easiest all around.
-Olof
^ permalink raw reply
* IMX6S MRII does not work
From: Andy Ng @ 2016-12-07 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAVaN8z0tKSFBtuOLe_cYboY_R=jeNggZ4Sv+bEVq-ErHq9PTg@mail.gmail.com>
I have hacked the file clk-imx6q.c and it works.
/*Set enet_ref clock to 125M to supply for RGMII tx_clk */
/*clk_set_rate(clk[IMX6QDL_CLK_ENET_REF], 125000000); */
clk_set_rate(clk[IMX6QDL_CLK_ENET_REF], 50000000);
On Wed, Dec 7, 2016 at 9:39 PM, Andy Ng <andreas2025@gmail.com> wrote:
> Just an update...
>
> I have put a scope on ENET_REF_CLK to check what comes out from the
> PAD_GPIO16. The uboot shows 50MHz, and when in the kernel it goes
> 125MHz. And for sure that doesn't do
>
> On Wed, Dec 7, 2016 at 12:44 AM, Andy Ng <andreas2025@gmail.com> wrote:
>> Hello,
>>
>> I have quite recent kernel linux-4.1.20 from Freescale's git repo.
>>
>>
>> I am using MRII and a fec setup that uses clock that goes to the phy too.
>>
>>
>> My dtsi has:
>>
>> pinctrl_enet: enetgrp {
>> fsl,pins = <
>> MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
>> MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
>> MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
>> MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
>> MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
>> MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
>> MX6QDL_PAD_ENET_RX_ER__ENET_RX_ER 0x1b0b0
>> MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
>> MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
>> MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8
>>
>> >;
>> };
>>
>>
>> the fec entry:
>>
>> &fec {
>> pinctrl-names = "default";
>> pinctrl-0 = <&pinctrl_enet>;
>> phy-mode = "rmii";
>> phy-reset-duration = <2>;
>> phy-reset-gpios = <&gpio2 9 GPIO_ACTIVE_LOW>;
>> status = "okay";
>> };
>>
>>
>> The kernel comes up and detects the phy (MDIO works), but it seems fec
>> is not doing much:
>>
>> INIT: Entering runlevel: 5
>> Configuring network interfaces... RMII Detected
>> fec 2188000.ethernet eth0: Freescale FEC PHY driver [SMSC
>> LAN8710/LAN8720] (mii_bus:phy_addr=2188000.ethernet:00, irq=-1)
>> IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>> udhcpc (v1.24.1) started
>> Sending discover...
>> Sending discover...
>> Sending discover...
>> No lease, forking to background
>> done.
>>
>> I have checked the code, and I've found very few boards that use
>> rmii, and from those, most of them are using external clock for the
>> phy.
>>
>> I have the impression that GPIO_16_ENET_REF_CLK with SION bit ON may
>> not have been tested, as there is no imx6 ref board that uses
>> that mode.
>>
>> Did anyone else have seen the same issue?
>> Any thoughts will be very much appreciated.
>>
>> Thank you
>> Andy
^ permalink raw reply
* [RFC PATCH 00/23] arm: defconfigs: use kconfig fragments
From: Laura Abbott @ 2016-12-07 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2155947.mOKhpZPiAn@wuerfel>
On 12/07/2016 01:35 PM, Arnd Bergmann wrote:
> On Wednesday, December 7, 2016 1:14:02 PM CET Olof Johansson wrote:
>>>
>>> - A "debug" fragment would be nice, to turn on common options that
>>> add a lot of useful runtime checks at the expense of performance
>>> or code size.
>>
>> Hmm, some of these might work but several useful debug options (in
>> particular DEBUG_LL for early errors) are per-system/platform.
>
> I was thinking mostly of architecture-independent options, i.e.
> the stuff that is in lib/Kconfig.debug but isn't too expensive
> to be run in a regular test environment. Enabling those
> for a build/boot automation environment would be particularly
> useful as you'd catch more bugs that get introduced through
> a random patch.
>
>>> - A "distro" fragment that turns on all loadable modules that are
>>> enabled by common distributions (e.g. two or more of
>>> debian/fedora/opensuse/gentoo), to let you build a drop-in
>>> replacement kernel for a shipping distro. This would also allow
>>> the distros to strip their own config files and just specify
>>> whatever differs from the others.
>>
>> Keeping this in sync with the distro kernel could be a bit awkward
>> (and possibly churny).
>
> It would certainly need buy-in from distro maintainers. I've discussed
> this with Laura Abbott in the past, and she was interested in
> principle.
>
> Arnd
>
Yes, I've gotten the request from multiple people now about having
some Fedora config in mainline. I agree that churn and keeping in
sync would be a concern. For a first pass, I was going to propose
a minimal set of options that are unlikely to need to churn. Once
those are agreed on, everything else could become a separate .config.
My plan was to send a patch out around -rc2/-rc3 each cycle to sync
up.
Thanks,
Laura
^ permalink raw reply
* [PATCH V6 10/10] arm/arm64: KVM: add guest SEA support
From: Tyler Baicar @ 2016-12-07 21:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481147303-7979-1-git-send-email-tbaicar@codeaurora.org>
Currently external aborts are unsupported by the guest abort
handling. Add handling for SEAs so that the host kernel reports
SEAs which occur in the guest kernel.
Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
---
arch/arm/include/asm/kvm_arm.h | 1 +
arch/arm/include/asm/system_misc.h | 5 +++++
arch/arm/kvm/mmu.c | 18 ++++++++++++++++--
arch/arm64/include/asm/kvm_arm.h | 1 +
arch/arm64/include/asm/system_misc.h | 2 ++
arch/arm64/mm/fault.c | 13 +++++++++++++
6 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h
index e22089f..33a77509 100644
--- a/arch/arm/include/asm/kvm_arm.h
+++ b/arch/arm/include/asm/kvm_arm.h
@@ -187,6 +187,7 @@
#define FSC_FAULT (0x04)
#define FSC_ACCESS (0x08)
#define FSC_PERM (0x0c)
+#define FSC_EXTABT (0x10)
/* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
#define HPFAR_MASK (~0xf)
diff --git a/arch/arm/include/asm/system_misc.h b/arch/arm/include/asm/system_misc.h
index a3d61ad..ea45d94 100644
--- a/arch/arm/include/asm/system_misc.h
+++ b/arch/arm/include/asm/system_misc.h
@@ -24,4 +24,9 @@ extern unsigned int user_debug;
#endif /* !__ASSEMBLY__ */
+static inline int handle_guest_sea(unsigned long addr, unsigned int esr)
+{
+ return -1;
+}
+
#endif /* __ASM_ARM_SYSTEM_MISC_H */
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index e9a5c0e..1152966 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -29,6 +29,7 @@
#include <asm/kvm_asm.h>
#include <asm/kvm_emulate.h>
#include <asm/virt.h>
+#include <asm/system_misc.h>
#include "trace.h"
@@ -1441,8 +1442,21 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
/* Check the stage-2 fault is trans. fault or write fault */
fault_status = kvm_vcpu_trap_get_fault_type(vcpu);
- if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
- fault_status != FSC_ACCESS) {
+
+ /* The host kernel will handle the synchronous external abort. There
+ * is no need to pass the error into the guest.
+ */
+ if (fault_status == FSC_EXTABT) {
+ if(handle_guest_sea((unsigned long)fault_ipa,
+ kvm_vcpu_get_hsr(vcpu))) {
+ kvm_err("Failed to handle guest SEA, FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
+ kvm_vcpu_trap_get_class(vcpu),
+ (unsigned long)kvm_vcpu_trap_get_fault(vcpu),
+ (unsigned long)kvm_vcpu_get_hsr(vcpu));
+ return -EFAULT;
+ }
+ } else if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
+ fault_status != FSC_ACCESS) {
kvm_err("Unsupported FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
kvm_vcpu_trap_get_class(vcpu),
(unsigned long)kvm_vcpu_trap_get_fault(vcpu),
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 4b5c977..be0efb6 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -201,6 +201,7 @@
#define FSC_FAULT ESR_ELx_FSC_FAULT
#define FSC_ACCESS ESR_ELx_FSC_ACCESS
#define FSC_PERM ESR_ELx_FSC_PERM
+#define FSC_EXTABT ESR_ELx_FSC_EXTABT
/* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
#define HPFAR_MASK (~UL(0xf))
diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
index 9040e1d..3a142a5 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -77,4 +77,6 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
int register_synchronous_ext_abort_notifier(struct notifier_block *nb);
void unregister_synchronous_ext_abort_notifier(struct notifier_block *nb);
+int handle_guest_sea(unsigned long addr, unsigned int esr);
+
#endif /* __ASM_SYSTEM_MISC_H */
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index fcc49f1..691399e 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -597,6 +597,19 @@ static const char *fault_name(unsigned int esr)
}
/*
+ * Handle Synchronous External Aborts that occur in a guest kernel.
+ */
+int handle_guest_sea(unsigned long addr, unsigned int esr)
+{
+ atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
+
+ pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
+ fault_name(esr), esr, addr);
+
+ return 0;
+}
+
+/*
* Dispatch a data abort to the relevant handler.
*/
asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH V6 09/10] trace, ras: add ARM processor error trace event
From: Tyler Baicar @ 2016-12-07 21:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481147303-7979-1-git-send-email-tbaicar@codeaurora.org>
Currently there are trace events for the various RAS
errors with the exception of ARM processor type errors.
Add a new trace event for such errors so that the user
will know when they occur. These trace events are
consistent with the ARM processor error section type
defined in UEFI 2.6 spec section N.2.4.4.
Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
---
drivers/acpi/apei/ghes.c | 9 +++++++-
drivers/firmware/efi/cper.c | 1 +
drivers/ras/ras.c | 1 +
include/ras/ras_event.h | 55 +++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index f2217da..49e6c25 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -517,7 +517,14 @@ static void ghes_do_proc(struct ghes *ghes,
}
#endif
- else {
+ else if (!uuid_le_cmp(sec_type, CPER_SEC_PROC_ARM)) {
+ struct cper_sec_proc_arm *arm_err;
+ struct cper_arm_err_info *err_info;
+
+ arm_err = acpi_hest_generic_data_payload(gdata);
+ err_info = (void *)(arm_err +1);
+ trace_arm_event(arm_err, err_info);
+ } else {
void *unknown_err = acpi_hest_generic_data_payload(gdata);
trace_unknown_sec_event(&sec_type,
fru_id, fru_text, sec_sev,
diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index 6cfcaa2..3cc0104 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -35,6 +35,7 @@
#include <linux/printk.h>
#include <linux/bcd.h>
#include <acpi/ghes.h>
+#include <ras/ras_event.h>
#define INDENT_SP " "
diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c
index fb2500b..8ba5a94 100644
--- a/drivers/ras/ras.c
+++ b/drivers/ras/ras.c
@@ -28,3 +28,4 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(extlog_mem_event);
#endif
EXPORT_TRACEPOINT_SYMBOL_GPL(mc_event);
EXPORT_TRACEPOINT_SYMBOL_GPL(unknown_sec_event);
+EXPORT_TRACEPOINT_SYMBOL_GPL(arm_event);
diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index 5861b6f..860a5f1 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -162,6 +162,61 @@ TRACE_EVENT(mc_event,
);
/*
+ * ARM Processor Events Report
+ *
+ * This event is generated when hardware detects an ARM processor error
+ * has occurred. UEFI 2.6 spec section N.2.4.4.
+ */
+TRACE_EVENT(arm_event,
+
+ TP_PROTO(const struct cper_sec_proc_arm *proc,
+ struct cper_arm_err_info *err_info),
+
+ TP_ARGS(proc, err_info),
+
+ TP_STRUCT__entry(
+ __field(u64, mpidr)
+ __field(u64, midr)
+ __field(u64, info)
+ __field(u64, virt_fault_addr)
+ __field(u64, phys_fault_addr)
+ __field(u32, running_state)
+ __field(u32, psci_state)
+ __field(u16, err_count)
+ __field(u8, affinity)
+ __field(u8, version)
+ __field(u8, type)
+ __field(u8, flags)
+ ),
+
+ TP_fast_assign(
+ __entry->affinity = proc->affinity_level;
+ __entry->mpidr = proc->mpidr;
+ __entry->midr = proc->midr;
+ __entry->running_state = proc->running_state;
+ __entry->psci_state = proc->psci_state;
+ __entry->version = err_info->version;
+ __entry->type = err_info->type;
+ __entry->err_count = err_info->multiple_error;
+ __entry->flags = err_info->flags;
+ __entry->info = err_info->error_info;
+ __entry->virt_fault_addr = err_info->virt_fault_addr;
+ __entry->phys_fault_addr = err_info->physical_fault_addr;
+ ),
+
+ TP_printk("affinity level: %d; MPIDR: %016llx; MIDR: %016llx; "
+ "running state: %d; PSCI state: %d; version: %d; type: %d; "
+ "error count: 0x%04x; flags: 0x%02x; info: %016llx; "
+ "virtual fault address: %016llx; "
+ "physical fault address: %016llx",
+ __entry->affinity, __entry->mpidr, __entry->midr,
+ __entry->running_state, __entry->psci_state, __entry->version,
+ __entry->type, __entry->err_count, __entry->flags,
+ __entry->info, __entry->virt_fault_addr,
+ __entry->phys_fault_addr)
+);
+
+/*
* Unknown Section Report
*
* This event is generated when hardware detected a hardware
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH V6 08/10] ras: acpi / apei: generate trace event for unrecognized CPER section
From: Tyler Baicar @ 2016-12-07 21:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481147303-7979-1-git-send-email-tbaicar@codeaurora.org>
UEFI spec allows for non-standard section in Common Platform Error
Record. This is defined in section N.2.3 of UEFI version 2.5.
Currently if the CPER section's type (UUID) does not match with
any section type that the kernel knows how to parse, trace event
is not generated for such section. And thus user is not able to know
happening of such hardware error, including error record of
non-standard section.
This commit generates a trace event which contains raw error data
for unrecognized CPER section.
Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
---
drivers/acpi/apei/ghes.c | 22 ++++++++++++++++++++--
drivers/ras/ras.c | 1 +
include/ras/ras_event.h | 45 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 895dec7..f2217da 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -44,11 +44,13 @@
#include <linux/pci.h>
#include <linux/aer.h>
#include <linux/nmi.h>
+#include <linux/uuid.h>
#include <acpi/actbl1.h>
#include <acpi/ghes.h>
#include <acpi/apei.h>
#include <asm/tlbflush.h>
+#include <ras/ras_event.h>
#ifdef CONFIG_HAVE_ACPI_APEI_SEA
#include <asm/system_misc.h>
@@ -457,11 +459,21 @@ static void ghes_do_proc(struct ghes *ghes,
{
int sev, sec_sev;
struct acpi_hest_generic_data *gdata;
+ uuid_le sec_type;
+ uuid_le *fru_id = &NULL_UUID_LE;
+ char *fru_text = "";
sev = ghes_severity(estatus->error_severity);
apei_estatus_for_each_section(estatus, gdata) {
sec_sev = ghes_severity(gdata->error_severity);
- if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
+ sec_type = *(uuid_le *)gdata->section_type;
+
+ if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID)
+ fru_id = (uuid_le *)gdata->fru_id;
+ if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT)
+ fru_text = gdata->fru_text;
+
+ if (!uuid_le_cmp(sec_type,
CPER_SEC_PLATFORM_MEM)) {
struct cper_sec_mem_err *mem_err;
@@ -472,7 +484,7 @@ static void ghes_do_proc(struct ghes *ghes,
ghes_handle_memory_failure(gdata, sev);
}
#ifdef CONFIG_ACPI_APEI_PCIEAER
- else if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
+ else if (!uuid_le_cmp(sec_type,
CPER_SEC_PCIE)) {
struct cper_sec_pcie *pcie_err;
@@ -505,6 +517,12 @@ static void ghes_do_proc(struct ghes *ghes,
}
#endif
+ else {
+ void *unknown_err = acpi_hest_generic_data_payload(gdata);
+ trace_unknown_sec_event(&sec_type,
+ fru_id, fru_text, sec_sev,
+ unknown_err, gdata->error_data_length);
+ }
}
}
diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c
index b67dd36..fb2500b 100644
--- a/drivers/ras/ras.c
+++ b/drivers/ras/ras.c
@@ -27,3 +27,4 @@ subsys_initcall(ras_init);
EXPORT_TRACEPOINT_SYMBOL_GPL(extlog_mem_event);
#endif
EXPORT_TRACEPOINT_SYMBOL_GPL(mc_event);
+EXPORT_TRACEPOINT_SYMBOL_GPL(unknown_sec_event);
diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index 1791a12..5861b6f 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -162,6 +162,51 @@ TRACE_EVENT(mc_event,
);
/*
+ * Unknown Section Report
+ *
+ * This event is generated when hardware detected a hardware
+ * error event, which may be of non-standard section as defined
+ * in UEFI spec appendix "Common Platform Error Record", or may
+ * be of sections for which TRACE_EVENT is not defined.
+ *
+ */
+TRACE_EVENT(unknown_sec_event,
+
+ TP_PROTO(const uuid_le *sec_type,
+ const uuid_le *fru_id,
+ const char *fru_text,
+ const u8 sev,
+ const u8 *err,
+ const u32 len),
+
+ TP_ARGS(sec_type, fru_id, fru_text, sev, err, len),
+
+ TP_STRUCT__entry(
+ __array(char, sec_type, 16)
+ __array(char, fru_id, 16)
+ __string(fru_text, fru_text)
+ __field(u8, sev)
+ __field(u32, len)
+ __dynamic_array(u8, buf, len)
+ ),
+
+ TP_fast_assign(
+ memcpy(__entry->sec_type, sec_type, sizeof(uuid_le));
+ memcpy(__entry->fru_id, fru_id, sizeof(uuid_le));
+ __assign_str(fru_text, fru_text);
+ __entry->sev = sev;
+ __entry->len = len;
+ memcpy(__get_dynamic_array(buf), err, len);
+ ),
+
+ TP_printk("severity: %d; sec type:%pU; FRU: %pU %s; data len:%d; raw data:%s",
+ __entry->sev, __entry->sec_type,
+ __entry->fru_id, __get_str(fru_text),
+ __entry->len,
+ __print_hex(__get_dynamic_array(buf), __entry->len))
+);
+
+/*
* PCIe AER Trace event
*
* These events are generated when hardware detects a corrected or
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox