* [PATCH v4 5/5] mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
From: Andrew Jeffery @ 2016-12-20 7:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220071535.27542-1-andrew@aj.id.au>
The Aspeed SoC Display Controller is presented as a syscon device to
arbitrate access by display and pinmux drivers. Video pinmux
configuration on fifth generation SoCs depends on bits in both the
System Control Unit and the Display Controller.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/mfd/aspeed-gfx.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
diff --git a/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
new file mode 100644
index 000000000000..aea5370efd97
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
@@ -0,0 +1,17 @@
+* Device tree bindings for Aspeed SoC Display Controller (GFX)
+
+The Aspeed SoC Display Controller primarily does as its name suggests, but also
+participates in pinmux requests on the g5 SoCs. It is therefore considered a
+syscon device.
+
+Required properties:
+- compatible: "aspeed,ast2500-gfx", "syscon"
+- reg: contains offset/length value of the GFX memory
+ region.
+
+Example:
+
+gfx: display at 1e6e6000 {
+ compatible = "aspeed,ast2500-gfx", "syscon";
+ reg = <0x1e6e6000 0x1000>;
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v4 4/5] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
From: Andrew Jeffery @ 2016-12-20 7:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220071535.27542-1-andrew@aj.id.au>
The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
on bits in both the System Control Unit and the LPC Host Controller.
The Aspeed LPC Host Controller is described as a child node of the
LPC host-range syscon device for arbitration of access by the host
controller and pinmux drivers.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
---
Linus: I've retained your r-b tag I don't think the addition of the ast2400
compatible string will fuss you. Please let me know if you feel this is
inappropriate.
.../devicetree/bindings/mfd/aspeed-lpc.txt | 26 ++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
index a97131aba446..514d82ced95b 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
+++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
@@ -109,3 +109,29 @@ lpc: lpc at 1e789000 {
};
};
+Host Node Children
+==================
+
+LPC Host Controller
+-------------------
+
+The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour
+between the host and the baseboard management controller. The registers exist
+in the "host" portion of the Aspeed LPC controller, which must be the parent of
+the LPC host controller node.
+
+Required properties:
+
+- compatible: One of:
+ "aspeed,ast2400-lhc";
+ "aspeed,ast2500-lhc";
+
+- reg: contains offset/length values of the LHC memory regions. In the
+ AST2400 and AST2500 there are two regions.
+
+Example:
+
+lhc: lhc at 20 {
+ compatible = "aspeed,ast2500-lhc";
+ reg = <0x20 0x24 0x48 0x8>;
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v4 3/5] mfd: dt: Add Aspeed Low Pin Count Controller bindings
From: Andrew Jeffery @ 2016-12-20 7:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220071535.27542-1-andrew@aj.id.au>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/mfd/aspeed-lpc.txt | 111 +++++++++++++++++++++
1 file changed, 111 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
new file mode 100644
index 000000000000..a97131aba446
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
@@ -0,0 +1,111 @@
+======================================================================
+Device tree bindings for the Aspeed Low Pin Count (LPC) Bus Controller
+======================================================================
+
+The LPC bus is a means to bridge a host CPU to a number of low-bandwidth
+peripheral devices, replacing the use of the ISA bus in the age of PCI[0]. The
+primary use case of the Aspeed LPC controller is as a slave on the bus
+(typically in a Baseboard Management Controller SoC), but under certain
+conditions it can also take the role of bus master.
+
+The LPC controller is represented as a multi-function device to account for the
+mix of functionality it provides. The principle split is between the register
+layout at the start of the I/O space which is, to quote the Aspeed datasheet,
+"basically compatible with the [LPC registers from the] popular BMC controller
+H8S/2168[1]", and everything else, where everything else is an eclectic
+collection of functions with a esoteric register layout. "Everything else",
+here labeled the "host" portion of the controller, includes, but is not limited
+to:
+
+* An IPMI Block Transfer[2] Controller
+
+* An LPC Host Controller: Manages LPC functions such as host vs slave mode, the
+ physical properties of some LPC pins, configuration of serial IRQs, and
+ APB-to-LPC bridging amonst other functions.
+
+* An LPC Host Interface Controller: Manages functions exposed to the host such
+ as LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART
+ management and bus snoop configuration.
+
+* A set of SuperIO[3] scratch registers: Enables implementation of e.g. custom
+ hardware management protocols for handover between the host and baseboard
+ management controller.
+
+Additionally the state of the LPC controller influences the pinmux
+configuration, therefore the host portion of the controller is exposed as a
+syscon as a means to arbitrate access.
+
+[0] http://www.intel.com/design/chipsets/industry/25128901.pdf
+[1] https://www.renesas.com/en-sg/doc/products/mpumcu/001/rej09b0078_h8s2168.pdf?key=7c88837454702128622bee53acbda8f4
+[2] http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf
+[3] https://en.wikipedia.org/wiki/Super_I/O
+
+Required properties
+===================
+
+- compatible: One of:
+ "aspeed,ast2400-lpc", "simple-mfd"
+ "aspeed,ast2500-lpc", "simple-mfd"
+
+- reg: contains the physical address and length values of the Aspeed
+ LPC memory region.
+
+- #address-cells: <1>
+- #size-cells: <1>
+- ranges: Maps 0 to the physical address and length of the LPC memory
+ region
+
+Required LPC Child nodes
+========================
+
+BMC Node
+--------
+
+- compatible: One of:
+ "aspeed,ast2400-lpc-bmc"
+ "aspeed,ast2500-lpc-bmc"
+
+- reg: contains the physical address and length values of the
+ H8S/2168-compatible LPC controller memory region
+
+Host Node
+---------
+
+- compatible: One of:
+ "aspeed,ast2400-lpc-host", "simple-mfd", "syscon"
+ "aspeed,ast2500-lpc-host", "simple-mfd", "syscon"
+
+- reg: contains the address and length values of the host-related
+ register space for the Aspeed LPC controller
+
+- #address-cells: <1>
+- #size-cells: <1>
+- ranges: Maps 0 to the address and length of the host-related LPC memory
+ region
+
+Example:
+
+lpc: lpc at 1e789000 {
+ compatible = "aspeed,ast2500-lpc", "simple-mfd";
+ reg = <0x1e789000 0x1000>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x1e789000 0x1000>;
+
+ lpc_bmc: lpc-bmc at 0 {
+ compatible = "aspeed,ast2500-lpc-bmc";
+ reg = <0x0 0x80>;
+ };
+
+ lpc_host: lpc-host at 80 {
+ compatible = "aspeed,ast2500-lpc-host", "simple-mfd", "syscon";
+ reg = <0x80 0x1e0>;
+ reg-io-width = <4>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x80 0x1e0>;
+ };
+};
+
--
2.9.3
^ permalink raw reply related
* [PATCH v4 2/5] mfd: dt: ranges, #address-cells and #size-cells as optional properties
From: Andrew Jeffery @ 2016-12-20 7:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220071535.27542-1-andrew@aj.id.au>
Whilst describing a device and not a bus, simple-mfd is modelled on
simple-bus where child nodes are iterated and registered as platform
devices. Some complex devices, e.g. the Aspeed LPC controller, can
benefit from address space mapping such that child nodes can use the
regs property to describe their resource offsets within the
multi-function device.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/mfd/mfd.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
index f1fceeda12f1..bcb6abb9d413 100644
--- a/Documentation/devicetree/bindings/mfd/mfd.txt
+++ b/Documentation/devicetree/bindings/mfd/mfd.txt
@@ -25,6 +25,16 @@ Optional properties:
be used. In the latter case the child devices will be determined by the
operating system.
+- ranges: Describes the address mapping relationship to the parent. Should set
+ the child's base address to 0, the physical address within parent's address
+ space, and the length of the address map.
+
+- #address-cells: Specifies the number of cells used to represent physical base
+ addresses. Must be present if ranges is used.
+
+- #size-cells: Specifies the number of cells used to represent the size of an
+ address. Must be present if ranges is used.
+
Example:
foo at 1000 {
--
2.9.3
^ permalink raw reply related
* [PATCH v4 1/5] mfd: dt: Fix "indicates" typo in mfd bindings document
From: Andrew Jeffery @ 2016-12-20 7:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220071535.27542-1-andrew@aj.id.au>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/mfd/mfd.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
index af9d6931a1a2..f1fceeda12f1 100644
--- a/Documentation/devicetree/bindings/mfd/mfd.txt
+++ b/Documentation/devicetree/bindings/mfd/mfd.txt
@@ -19,7 +19,7 @@ Optional properties:
- compatible : "simple-mfd" - this signifies that the operating system should
consider all subnodes of the MFD device as separate devices akin to how
- "simple-bus" inidicates when to see subnodes as children for a simple
+ "simple-bus" indicates when to see subnodes as children for a simple
memory-mapped bus. For more complex devices, when the nexus driver has to
probe registers to figure out what child devices exist etc, this should not
be used. In the latter case the child devices will be determined by the
--
2.9.3
^ permalink raw reply related
* [PATCH v4 0/5] mfd: dt: Add bindings for the Aspeed MFDs
From: Andrew Jeffery @ 2016-12-20 7:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Lee,
Here's v4 of the Aspeed LPC MFD devicetree bindings series. v3 can be found at:
https://lkml.org/lkml/2016/12/5/835
Changes since v3:
* Based on Arnd's argument[1], drop the addition of the mfd/syscon bindings
directory as well as the the last patch in v3, which moved a number of
existing bindings. Eventually the Aspeed display controller will have a
device-specific driver so it doesn't belong there either.
* Add a compatible string for the AST2400 in the LPC Host Controller bindings
as requested by Joel and slightly tweak the reg description for Rob.
[1] https://lkml.org/lkml/2016/12/13/202
Andrew Jeffery (5):
mfd: dt: Fix "indicates" typo in mfd bindings document
mfd: dt: ranges, #address-cells and #size-cells as optional properties
mfd: dt: Add Aspeed Low Pin Count Controller bindings
mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
.../devicetree/bindings/mfd/aspeed-gfx.txt | 17 +++
.../devicetree/bindings/mfd/aspeed-lpc.txt | 137 +++++++++++++++++++++
Documentation/devicetree/bindings/mfd/mfd.txt | 12 +-
3 files changed, 165 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
--
2.9.3
^ permalink raw reply
* [PATCH] drm/mediatek: Support UYVY and YUYV format for overlay
From: YT Shen @ 2016-12-20 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481692473-18755-1-git-send-email-bibby.hsieh@mediatek.com>
Hi Bibby,
On Wed, 2016-12-14 at 13:14 +0800, Bibby Hsieh wrote:
> MT8173 overlay can support UYVY and YUYV format,
> we add the format in DRM driver.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++++++
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 ++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 019b7ca..0a340f3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -44,6 +44,8 @@
> #define OVL_CON_CLRFMT_RGB888 (1 << 12)
> #define OVL_CON_CLRFMT_RGBA8888 (2 << 12)
> #define OVL_CON_CLRFMT_ARGB8888 (3 << 12)
> +#define OVL_CON_CLRFMT_UYVY (4 << 12)
> +#define OVL_CON_CLRFMT_YUYV (5 << 12)
> #define OVL_CON_AEN BIT(8)
> #define OVL_CON_ALPHA 0xff
>
> @@ -161,6 +163,10 @@ static unsigned int ovl_fmt_convert(unsigned int fmt)
> case DRM_FORMAT_XBGR8888:
> case DRM_FORMAT_ABGR8888:
> return OVL_CON_CLRFMT_RGBA8888 | OVL_CON_BYTE_SWAP;
> + case DRM_FORMAT_YUYV:
> + return OVL_CON_CLRFMT_YUYV;
> + case DRM_FORMAT_UYVY:
> + return OVL_CON_CLRFMT_UYVY;
> }
> }
Your patch looks good, but I am not sure about some details.
AFAIK, there is a color matrix here to describe how to transform from
BT.601 / BT.709 / other color space to RGB color space. You can use the
default value if you don't care how colors are represented. Or you can
specify the matrix in this patch.
Regards,
yt.shen
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index c461a23..b94c6ee 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -28,6 +28,8 @@
> DRM_FORMAT_XRGB8888,
> DRM_FORMAT_ARGB8888,
> DRM_FORMAT_RGB565,
> + DRM_FORMAT_YUYV,
> + DRM_FORMAT_UYVY,
> };
>
> static void mtk_plane_reset(struct drm_plane *plane)
^ permalink raw reply
* [PATCH] arm64/dts/ls2080a-rdb: remove disable status of pca9547
From: Meng Yi @ 2016-12-20 6:03 UTC (permalink / raw)
To: linux-arm-kernel
pca9547 won't probed since its status property is disabled.
while there are devices connected to it, we need remove status
property to let ds3232 and adt7461 probed correctly.
Signed-off-by: Meng Yi <meng.yi@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
index 265e0a8..2ff46ca 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
@@ -102,7 +102,6 @@
reg = <0x75>;
#address-cells = <1>;
#size-cells = <0>;
- status = "disabled";
i2c at 1 {
#address-cells = <1>;
#size-cells = <0>;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH] ARM: dts: sun8i: add a delay after reset xr819 on Orange Pi Zero
From: Icenowy Zheng @ 2016-12-20 5:58 UTC (permalink / raw)
To: linux-arm-kernel
XR819 seems to need a delay after its reset line to be deasserted,
otherwise it may not respond MMC commands correctly, and fail to
initialize.
Add a 200ms delay in the mmc-pwrseq.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
index d18807f73060..b7ca916d871d 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -92,6 +92,7 @@
wifi_pwrseq: wifi_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>;
+ post-power-on-delay-ms = <200>;
};
};
--
2.11.0
^ permalink raw reply related
* [RFC] Question about freeing of resource in 'atlas7_pinmux_probe()', in file 'drivers/pinctrl/sirf/pinctrl-atlas7.c'
From: Christophe JAILLET @ 2016-12-20 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7123e174-cc22-4a76-337c-661ee87994df@mentor.com>
Le 19/12/2016 ? 14:54, Vladimir Zapolskiy a ?crit :
> Functionally it looks good, I have two comments though.
> 1) you don't need to revert 151b8c5ba1eb, the commit is a proper fix
> per se but incomplete, please add your change on top of it,
>
> 2) minimizing the lines of code by removing duplicates is always good,
> so here a better and complete fix will be like the following one:
>
Hi,
thanks for the feedback and comments.
Patch submitted.
CJ
^ permalink raw reply
* [PATCH 2/2] pinctrl: sirf: atlas7: Improve code layout
From: Christophe JAILLET @ 2016-12-20 5:41 UTC (permalink / raw)
To: linux-arm-kernel
Add some tab in order to improve indentation.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/pinctrl/sirf/pinctrl-atlas7.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/sirf/pinctrl-atlas7.c b/drivers/pinctrl/sirf/pinctrl-atlas7.c
index f714f67c4b64..76df538fa814 100644
--- a/drivers/pinctrl/sirf/pinctrl-atlas7.c
+++ b/drivers/pinctrl/sirf/pinctrl-atlas7.c
@@ -5444,7 +5444,7 @@ static int atlas7_pinmux_probe(struct platform_device *pdev)
pmx->regs[idx] = of_iomap(np, idx);
if (!pmx->regs[idx]) {
dev_err(&pdev->dev,
- "can't map ioc bank#%d registers\n", idx);
+ "can't map ioc bank#%d registers\n", idx);
ret = -ENOMEM;
goto unmap_io;
}
@@ -6057,8 +6057,8 @@ static int atlas7_gpio_probe(struct platform_device *pdev)
ret = gpiochip_add_data(chip, a7gc);
if (ret) {
dev_err(&pdev->dev,
- "%s: error in probe function with status %d\n",
- np->name, ret);
+ "%s: error in probe function with status %d\n",
+ np->name, ret);
goto failed;
}
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] pinctrl: sirf: atlas7: Add missing 'of_node_put()'
From: Christophe JAILLET @ 2016-12-20 5:40 UTC (permalink / raw)
To: linux-arm-kernel
Reference to 'sys2pci_np' should be dropped in all cases here, not only in
error handling path.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/pinctrl/sirf/pinctrl-atlas7.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/sirf/pinctrl-atlas7.c b/drivers/pinctrl/sirf/pinctrl-atlas7.c
index 7f3041697813..f714f67c4b64 100644
--- a/drivers/pinctrl/sirf/pinctrl-atlas7.c
+++ b/drivers/pinctrl/sirf/pinctrl-atlas7.c
@@ -5420,14 +5420,15 @@ static int atlas7_pinmux_probe(struct platform_device *pdev)
sys2pci_np = of_find_node_by_name(NULL, "sys2pci");
if (!sys2pci_np)
return -EINVAL;
+
ret = of_address_to_resource(sys2pci_np, 0, &res);
+ of_node_put(sys2pci_np);
if (ret)
return ret;
+
pmx->sys2pci_base = devm_ioremap_resource(&pdev->dev, &res);
- if (IS_ERR(pmx->sys2pci_base)) {
- of_node_put(sys2pci_np);
+ if (IS_ERR(pmx->sys2pci_base))
return -ENOMEM;
- }
pmx->dev = &pdev->dev;
--
2.9.3
^ permalink raw reply related
* [PATCH v4 0/2] FPGA: TS-7300 FPGA manager
From: Alan Tull @ 2016-12-20 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c964999f-0988-dc41-5e5e-c0ff9c2455b1@gmail.com>
On Mon, 19 Dec 2016, Florian Fainelli wrote:
> On 12/18/2016 12:21 PM, Florian Fainelli wrote:
> > Hi all,
> >
> > This patch series adds support for loading bitstreams into the Altera Cyclone II
> > connected to an EP9302 on a TS-7300 board.
> >
> > Changes in v4:
> >
> > - fixed ops->write not to do the final configuration release
> > - reordered patches
> >
> > Changes in v3:
> >
> > - fix write_init and write_complete signatures
> >
> > Changes in v2:
> >
> > - rebased against fpga/for-next
> > - added defines for configuration bits and delays
> > - added error mesage if ioremap() fails
> > - detailed how the configuration through CPLD is done
>
> Alan, Moritz, thanks for providing Acked-by, I was under the impression
> these patches would be taken by you through the FPGA tree,
Hi Florain,
That's right, I'll handle it. The FPGA tree goes in through Greg.
We're in the merge window where stuff Greg already has is going to
Linus so it's too late to get this into 4.10. I'll be doing a pull
after that.
Alan
> since Hartley
> acked the EP93xx part and since that was the tree used as a baseline.
>
> Let me know how you want to proceed, since EP93xx is not as active as
> other ARM SoCs, there may not be a specific tree where to stage these
> patches (unless you take them).
>
> Thanks!
> --
> Florian
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 2/2] mfd: mc13xxx: Pass the IRQF_TRIGGER_HIGH flag.
From: Alexander Shiyan @ 2016-12-20 5:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482182934-18559-3-git-send-email-lilja.magnus@gmail.com>
>???????, 20 ??????? 2016, 0:28 +03:00 ?? Magnus Lilja <lilja.magnus@gmail.com>:
>
>All supported mc13xxx devices have active high interrupt outputs. Make sure
>to configure the interrupt as active high by passing the IRQF_TRIGGER_HIGH
>flag. This is required at least on the i.MX31 PDK board.
>
>Signed-off-by: Magnus Lilja < lilja.magnus@gmail.com >
>---
>
>?drivers/mfd/mc13xxx-core.c | 2 +-
>?1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
>index d7f54e4..4cbe6b7 100644
>--- a/drivers/mfd/mc13xxx-core.c
>+++ b/drivers/mfd/mc13xxx-core.c
>@@ -440,7 +440,7 @@ int mc13xxx_common_init(struct device *dev)
>?mc13xxx->irq_chip.irqs = mc13xxx->irqs;
>?mc13xxx->irq_chip.num_irqs = ARRAY_SIZE(mc13xxx->irqs);
>?
>-ret = regmap_add_irq_chip(mc13xxx->regmap, mc13xxx->irq, IRQF_ONESHOT,
>+ret = regmap_add_irq_chip(mc13xxx->regmap, mc13xxx->irq, IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
>? 0, &mc13xxx->irq_chip, &mc13xxx->irq_data);
>?if (ret)
>?return ret;
IRQ line can be passed through inverter to IC.
On my opinion the best way to handle all possible situations is parse
devicetree IRQ flags and pass to the driver.
---
^ permalink raw reply
* [RFC v4 00/16] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Bharat Bhushan @ 2016-12-20 4:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481661034-3088-1-git-send-email-eric.auger@redhat.com>
Hi Eric,
Tested this series on NXP ARMv8 platform.
Thanks
-Bharat
> -----Original Message-----
> From: Eric Auger [mailto:eric.auger at redhat.com]
> Sent: Wednesday, December 14, 2016 2:00 AM
> To: eric.auger at redhat.com; eric.auger.pro at gmail.com;
> christoffer.dall at linaro.org; marc.zyngier at arm.com;
> robin.murphy at arm.com; alex.williamson at redhat.com;
> will.deacon at arm.com; joro at 8bytes.org; tglx at linutronix.de;
> jason at lakedaemon.net; linux-arm-kernel at lists.infradead.org
> Cc: kvm at vger.kernel.org; drjones at redhat.com; linux-
> kernel at vger.kernel.org; pranav.sawargaonkar at gmail.com;
> iommu at lists.linux-foundation.org; punit.agrawal at arm.com; Diana Madalina
> Craciun <diana.craciun@nxp.com>; gpkulkarni at gmail.com;
> shankerd at codeaurora.org; Bharat Bhushan <bharat.bhushan@nxp.com>
> Subject: [RFC v4 00/16] KVM PCIe/MSI passthrough on ARM/ARM64 and
> IOVA reserved regions
>
> Following LPC discussions, we now report reserved regions through iommu-
> group sysfs reserved_regions attribute file.
>
> Reserved regions are populated through the IOMMU get_resv_region
> callback (former get_dm_regions), now implemented by amd-iommu, intel-
> iommu and arm-smmu:
> - the amd-iommu reports device direct mapped regions.
> - the intel-iommu reports the [0xfee00000 - 0xfeefffff] MSI window
> as an IOMMU_RESV_NOMAP reserved region.
> - the arm-smmu reports the MSI window (arbitrarily located at
> 0x8000000 and 1MB large).
>
> Unsafe interrupt assignment is tested by enumerating all MSI irq domains
> and checking they support MSI remapping. This check is done in case we
> detect the iommu translates MSI (an IOMMU_RESV_MSI window exists).
> Otherwise the IRQ remapping capability is checked at IOMMU level.
> Obviously this is a defensive IRQ safety assessment.
> Assuming there are several MSI controllers in the system and at least one
> does not implement IRQ remapping, the assignment will be considered as
> unsafe (even if this controller is not acessible from the assigned devices).
>
> The series integrates a not officially posted patch from Robin:
> "iommu/dma: Allow MSI-only cookies".
>
> Best Regards
>
> Eric
>
> Git: complete series available at
> https://github.com/eauger/linux/tree/v4.9-reserved-v4
>
> History:
>
> RFCv3 -> RFCv4:
> - arm-smmu driver does not register PCI host bridge windows as
> reserved regions anymore
> - Implement reserved region get/put callbacks also in arm-smmuv3
> - take the iommu_group lock on iommu_get_group_resv_regions
> - add a type field in iommu_resv_region instead of using prot
> - init the region list_head in iommu_alloc_resv_region, also
> add type parameter
> - iommu_insert_resv_region manage overlaps and sort reserved
> windows
> - address IRQ safety assessment by enumerating all the MSI irq
> domains and checking the MSI_REMAP flag
> - update Documentation/ABI/testing/sysfs-kernel-iommu_groups
> - Did not add T-b since the code has significantly changed
>
> RFCv2 -> RFCv3:
> - switch to an iommu-group sysfs API
> - use new dummy allocator provided by Robin
> - dummy allocator initialized by vfio-iommu-type1 after enumerating
> the reserved regions
> - at the moment ARM MSI base address/size is left unchanged compared
> to v2
> - we currently report reserved regions and not usable IOVA regions as
> requested by Alex
>
> RFC v1 -> v2:
> - fix intel_add_reserved_regions
> - add mutex lock/unlock in vfio_iommu_type1
>
>
> Eric Auger (16):
> iommu/dma: Allow MSI-only cookies
> iommu: Rename iommu_dm_regions into iommu_resv_regions
> iommu: Add a new type field in iommu_resv_region
> iommu: iommu_alloc_resv_region
> iommu: Only map direct mapped regions
> iommu: iommu_get_group_resv_regions
> iommu: Implement reserved_regions iommu-group sysfs file
> iommu/vt-d: Implement reserved region get/put callbacks
> iommu/arm-smmu: Implement reserved region get/put callbacks
> iommu/arm-smmu-v3: Implement reserved region get/put callbacks
> irqdomain: Add IRQ_DOMAIN_FLAG_MSI_REMAP value
> irqdomain: irq_domain_check_msi_remap
> irqchip/gicv3-its: Sets IRQ_DOMAIN_FLAG_MSI_REMAP
> vfio/type1: Allow transparent MSI IOVA allocation
> vfio/type1: Check MSI remapping at irq domain level
> iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP anymore
>
> .../ABI/testing/sysfs-kernel-iommu_groups | 9 ++
> drivers/iommu/amd_iommu.c | 21 +--
> drivers/iommu/arm-smmu-v3.c | 30 +++-
> drivers/iommu/arm-smmu.c | 30 +++-
> drivers/iommu/dma-iommu.c | 116 +++++++++++++---
> drivers/iommu/intel-iommu.c | 50 +++++--
> drivers/iommu/iommu.c | 152 +++++++++++++++++++--
> drivers/irqchip/irq-gic-v3-its.c | 1 +
> drivers/vfio/vfio_iommu_type1.c | 37 ++++-
> include/linux/dma-iommu.h | 7 +
> include/linux/iommu.h | 46 +++++--
> include/linux/irqdomain.h | 8 ++
> kernel/irq/irqdomain.c | 24 ++++
> 13 files changed, 455 insertions(+), 76 deletions(-)
>
> --
> 1.9.1
^ permalink raw reply
* [PATCH v10 0/8] power: add power sequence library
From: Peter Chen @ 2016-12-20 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161219191504.GA18988@kozik-lap>
On Mon, Dec 19, 2016 at 09:15:04PM +0200, Krzysztof Kozlowski wrote:
> On Mon, Nov 14, 2016 at 09:35:51AM +0800, Peter Chen wrote:
> > Hi all,
> >
> > This is a follow-up for my last power sequence framework patch set [1].
> > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > power sequence instances will be added at postcore_initcall, the match
> > criteria is compatible string first, if the compatible string is not
> > matched between dts and library, it will try to use generic power sequence.
> >
> > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence instance is needed, for more power sequences
> > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
> >
> > In future, if there are special power sequence requirements, the special
> > power sequence library can be created.
> >
> > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > two hot-plug devices to simulate this use case, the related binding
> > change is updated at patch [1/6], The udoo board changes were tested
> > using my last power sequence patch set.[3]
> >
> > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > need to power on itself before it can be found by ULPI bus.
> >
> > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
> >
> > Changes for v10:
> > - Improve the kernel-doc for power sequence core, including exported APIs and
> > main structure. [Patch 2/8]
> > - Change Kconfig, and let the user choose power sequence. [Patch 2/8]
> > - Delete EXPORT_SYMBOL and change related APIs as local, these APIs do not
> > be intended to export currently. [Patch 2/8]
> > - Selete POWER_SEQUENCE at USB core's Kconfig. [Patch 4/8]
>
> Hi Peter,
>
> It is great that you continued the work on this.
>
> I saw (in some previous mails) your repo mentioned:
> https://git.kernel.org/cgit/linux/kernel/git/peter.chen/usb.git/
> Does it contain the recent version of this patchset?
>
> I want to build on top of it fixes for usb3503 on Odroid U3 board.
Krzysztof, I put v10 patch set at branch: pwrseq-lib.
It seems there are no more comments I will send my v11 patch set
after new year holiday.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH v4 0/2] FPGA: TS-7300 FPGA manager
From: Florian Fainelli @ 2016-12-20 4:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161218202158.10582-1-f.fainelli@gmail.com>
On 12/18/2016 12:21 PM, Florian Fainelli wrote:
> Hi all,
>
> This patch series adds support for loading bitstreams into the Altera Cyclone II
> connected to an EP9302 on a TS-7300 board.
>
> Changes in v4:
>
> - fixed ops->write not to do the final configuration release
> - reordered patches
>
> Changes in v3:
>
> - fix write_init and write_complete signatures
>
> Changes in v2:
>
> - rebased against fpga/for-next
> - added defines for configuration bits and delays
> - added error mesage if ioremap() fails
> - detailed how the configuration through CPLD is done
Alan, Moritz, thanks for providing Acked-by, I was under the impression
these patches would be taken by you through the FPGA tree, since Hartley
acked the EP93xx part and since that was the tree used as a baseline.
Let me know how you want to proceed, since EP93xx is not as active as
other ARM SoCs, there may not be a specific tree where to stage these
patches (unless you take them).
Thanks!
--
Florian
^ permalink raw reply
* [PATCH] tty: hvc_dcc: Add basic early_con support
From: Nishanth Menon @ 2016-12-20 0:23 UTC (permalink / raw)
To: linux-arm-kernel
In some cases, earlycon can help catch errors with kernel boot prior to
standard console is available.
Example bootargs: console=hvc0 earlycon=hvcdcc
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Based on: v4.9 tag
Also applies on: next-20161219
Tested on Simulation environment (which did not have serial console option)
drivers/tty/hvc/hvc_dcc.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/tty/hvc/hvc_dcc.c b/drivers/tty/hvc/hvc_dcc.c
index 82f240fb98f0..1ec06e550656 100644
--- a/drivers/tty/hvc/hvc_dcc.c
+++ b/drivers/tty/hvc/hvc_dcc.c
@@ -10,7 +10,9 @@
* GNU General Public License for more details.
*/
+#include <linux/console.h>
#include <linux/init.h>
+#include <linux/serial_core.h>
#include <asm/dcc.h>
#include <asm/processor.h>
@@ -94,3 +96,45 @@ static int __init hvc_dcc_init(void)
return PTR_ERR_OR_ZERO(p);
}
device_initcall(hvc_dcc_init);
+
+static int hvc_dcc_earlyputc(int c)
+{
+ unsigned long count = 0xFFFFFFFF;
+ static bool dead_dcc_earlycon;
+
+ if (dead_dcc_earlycon)
+ return -EBUSY;
+
+ while (count--) {
+ if (!(__dcc_getstatus() & DCC_STATUS_TX))
+ break;
+ }
+ if (!count) {
+ dead_dcc_earlycon = true;
+ return -EBUSY;
+ }
+ __dcc_putchar(c);
+ return 0;
+}
+
+static void hvc_dcc_earlywrite(struct console *con, const char *s,
+ unsigned int n)
+{
+ int r;
+
+ while (n--) {
+ r = hvc_dcc_earlyputc(*s);
+ if (r)
+ break;
+ s++;
+ }
+}
+
+static int
+__init early_hvc_dcc_setup(struct earlycon_device *device, const char *opt)
+{
+ device->con->write = hvc_dcc_earlywrite;
+ return 0;
+}
+
+EARLYCON_DECLARE(hvcdcc, early_hvc_dcc_setup);
--
2.11.0.65.geff96d7
^ permalink raw reply related
* [PATCH] crypto: testmgr: Use linear alias for test input
From: Laura Abbott @ 2016-12-19 23:37 UTC (permalink / raw)
To: linux-arm-kernel
Christopher Covington reported a crash on aarch64 on recent Fedora
kernels:
kernel BUG at ./include/linux/scatterlist.h:140!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 752 Comm: cryptomgr_test Not tainted 4.9.0-11815-ge93b1cc #162
Hardware name: linux,dummy-virt (DT)
task: ffff80007c650080 task.stack: ffff800008910000
PC is at sg_init_one+0xa0/0xb8
LR is at sg_init_one+0x24/0xb8
...
[<ffff000008398db8>] sg_init_one+0xa0/0xb8
[<ffff000008350a44>] test_acomp+0x10c/0x438
[<ffff000008350e20>] alg_test_comp+0xb0/0x118
[<ffff00000834f28c>] alg_test+0x17c/0x2f0
[<ffff00000834c6a4>] cryptomgr_test+0x44/0x50
[<ffff0000080dac70>] kthread+0xf8/0x128
[<ffff000008082ec0>] ret_from_fork+0x10/0x50
The test vectors used for input are part of the kernel image. These
inputs are passed as a buffer to sg_init_one which eventually blows up
with BUG_ON(!virt_addr_valid(buf)). On arm64, virt_addr_valid returns
false for the kernel image since virt_to_page will not return the
correct page. The kernel image is also aliased to the linear map so get
the linear alias and pass that to the scatterlist instead.
Reported-by: Christopher Covington <cov@codeaurora.org>
Fixes: d7db7a882deb ("crypto: acomp - update testmgr with support for acomp")
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
x86 supports virt_addr_valid working on kernel image addresses but arm64 is
more strict. This is the direction things have been moving with my
CONFIG_DEBUG_VIRTUAL series for arm64 which is tightening the definition of
__pa/__pa_symbol.
---
crypto/testmgr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index f616ad7..f5bac10 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1464,7 +1464,7 @@ static int test_acomp(struct crypto_acomp *tfm, struct comp_testvec *ctemplate,
memset(output, 0, dlen);
init_completion(&result.completion);
- sg_init_one(&src, ctemplate[i].input, ilen);
+ sg_init_one(&src, __va(__pa_symbol(ctemplate[i].input)), ilen);
sg_init_one(&dst, output, dlen);
req = acomp_request_alloc(tfm);
@@ -1513,7 +1513,7 @@ static int test_acomp(struct crypto_acomp *tfm, struct comp_testvec *ctemplate,
memset(output, 0, dlen);
init_completion(&result.completion);
- sg_init_one(&src, dtemplate[i].input, ilen);
+ sg_init_one(&src, __va(__pa_symbol(dtemplate[i].input)), ilen);
sg_init_one(&dst, output, dlen);
req = acomp_request_alloc(tfm);
--
2.7.4
^ permalink raw reply related
* [PATCHv2 2/8] dt-bindings: document the STM32 RTC bindings
From: Rob Herring @ 2016-12-19 23:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481878257-29163-3-git-send-email-amelie.delaunay@st.com>
On Fri, Dec 16, 2016 at 09:50:51AM +0100, Amelie Delaunay wrote:
> This patch adds documentation of device tree bindings for the STM32 RTC.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
> .../devicetree/bindings/rtc/st,stm32-rtc.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/3 v2] iio: adc: add device tree bindings for Qualcomm PM8xxx ADCs
From: Rob Herring @ 2016-12-19 22:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481842089-13999-1-git-send-email-linus.walleij@linaro.org>
On Thu, Dec 15, 2016 at 11:48:09PM +0100, Linus Walleij wrote:
> This adds the device tree bindings for the Qualcomm PM8xxx
> ADCs. This is based on the existing DT bindings for the
> SPMI ADC so there are hopefully no controversial features.
>
> Cc: devicetree at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-arm-msm at vger.kernel.org
> Cc: Ivan T. Ivanov <iivanov.xz@gmail.com>
> Cc: Andy Gross <andy.gross@linaro.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Spelling fixes
> ---
> .../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 160 +++++++++++++++++++++
> 1 file changed, 160 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> new file mode 100644
> index 000000000000..3c6bca5b4edf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> @@ -0,0 +1,160 @@
> +Qualcomm's PM8xxx voltage XOADC
> +
> +The Qualcomm PM8xxx PMICs contain a HK/XO ADC (Housekeeping/Crystal
> +oscillator ADC) encompassing PM8018, PM8038, PM8058, PM8917 and PM8921.
> +
> +Required properties:
> +
> +- compatible: should be one of:
> + "qcom,pm8018-adc"
> + "qcom,pm8038-adc"
> + "qcom,pm8058-adc"
> + "qcom,pm8917-adc"
> + "qcom,pm8921-adc"
> +
> +- reg: should contain the ADC base address in the PMIC, typically
> + 0x197.
> +
> +The following required properties are standard for IO channels, see
> +iio-bindings.txt for more details:
> +
> +- #address-cells: should be set to <1>
> +
> +- #size-cells: should be set to <0>
> +
> +- #io-channel-cells: should be set to <1>
> +
> +- interrupts: should refer to the parent PMIC interrupt controller
> + and reference the proper ADC interrupt.
> +
> +Required subnodes:
> +
> +The ADC channels are configured as subnodes of the ADC. Since some of
> +them are used for calibrating the ADC, these nodes are compulsory:
> +
> +ref_625mv {
ref at c
> + reg = <0x0c>;
> +};
> +
> +ref_1250mv {
> + reg = <0x0d>;
> +};
> +
> +ref_muxoff {
> + reg = <0x0f>;
> +};
> +
> +These three nodes are used for absolute and ratiometric calibration
> +and only need to have these reg values: they are by hardware definition
> +1:1 ratio converters that sample 625, 1250 and 0 milliV and create
> +an interpolation calibration for all other ADCs.
> +
> +Optional subnodes: any channels other than channel 0x0c, 0x0d and
> +0x0f are optional.
> +
> +Required channel node properties:
> +
> +- reg: should contain the hardware channel number in the range
> + 0 .. 0x0f (4 bits). The hardware only supports 16 channels.
> +
> +Optional channel node properties:
> +
> +- qcom,decimation:
> + Value type: <u32>
> + Definition: This parameter is used to decrease the ADC sampling rate.
> + Quicker measurements can be made by reducing the decimation ratio.
> + Valid values are 512, 1024, 2048, 4096.
> + If the property is not found, a default value of 512 will be used.
> +
> +- qcom,ratiometric:
> + Value type: <empty>
> + Definition: Channel calibration type. If this property is specified
> + VADC will use the VDD reference (1.8V) and GND for channel
> + calibration. If the property is not found, the channel will be
> + calibrated with the 0.625V and 1.25V reference channels, also
> + known as an absolute calibration.
> +
> +- qcom,ratiometric-ref:
> + Value type: <u32>
> + Definition: The reference voltage pair when using ratiometric
> + calibration:
> + 0 = XO_IN/XOADC_GND
> + 1 = PMIC_IN/XOADC_GND
> + 2 = PMIC_IN/BMS_CSP
> + 3 (invalid)
> + 4 = XOADC_GND/XOADC_GND
> + 5 = XOADC_VREF/XOADC_GND
> +
> +Example:
> +
> +xoadc: xoadc at 197 {
> + compatible = "qcom,pm8058-adc";
> + reg = <0x197>;
> + interrupt-parent = <&pm8058>;
> + interrupts = <76 1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #io-channel-cells = <1>;
> +
> + vcoin {
> + reg = <0x00>;
If you have a reg property, then you should have a unit address on all
of these.
These should really all be something like adc-channel at ... Not sure if we
have a standard node name for ADC channels. Or don't put any of this in
DT.
> + };
> + vbat {
> + reg = <0x01>;
> + };
> + dcin {
> + reg = <0x02>;
> + };
> + ichg {
> + reg = <0x03>;
> + };
> + vph_pwr {
> + reg = <0x04>;
> + };
> + mpp5 {
> + reg = <0x05>;
> + };
> + mpp6 {
> + reg = <0x06>;
> + };
> + mpp7 {
> + reg = <0x07>;
> + };
> + mpp8 {
> + reg = <0x08>;
> + };
> + mpp9 {
> + reg = <0x09>;
> + };
> + usb_vbus {
> + reg = <0x0a>;
> + };
> + die_temp {
> + reg = <0x0b>;
> + };
> + ref_625mv {
> + reg = <0x0c>;
> + };
> + ref_1250mv {
> + reg = <0x0d>;
> + };
> + ref_325mv {
> + reg = <0x0e>;
> + };
> + ref_muxoff {
> + reg = <0x0f>;
> + };
> +};
^ permalink raw reply
* [PATCH] staging: vc04_services: Fix bracing on single statement blocks
From: Eric Anholt @ 2016-12-19 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161218054822.GA16024@mainline.lan>
Aaron Moore <aaron@atamisk.net> writes:
> Fix coding style issue caught by checkpatch.pl relating to braces on
> single statement blocks. This issue was corrected in 3 locations.
>
> Signed-off-by: Aaron Moore <aaron@atamisk.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161219/f7d2dc40/attachment.sig>
^ permalink raw reply
* [PATCHv6] support for AD5820 camera auto-focus coil
From: Pavel Machek @ 2016-12-19 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215065022.GC16630@valkosipuli.retiisi.org.uk>
Hi!
> Hi Pali and Tony,
> On Wed, Dec 14, 2016 at 07:08:19AM -0800, Tony Lindgren wrote:
> > * Pali Roh?r <pali.rohar@gmail.com> [161214 05:38]:
> > > On Monday 08 August 2016 23:41:32 Pavel Machek wrote:
> > > > On Mon 2016-08-08 11:09:56, Sakari Ailus wrote:
> > > > > On Fri, Aug 05, 2016 at 12:26:11PM +0200, Pavel Machek wrote:
> > > > > > This adds support for AD5820 autofocus coil, found for example in
> > > > > > Nokia N900 smartphone.
> > > > >
> > > > > Thanks, Pavel!
> > > > >
> > > > > Let's use V4L2_CID_FOCUS_ABSOLUTE, as is in the patch. If we get
> > > > > something better in the future, we'll switch to that then.
> > > > >
> > > > > I've applied this to ad5820 branch in my tree.
> > > >
> > > > Thanks. If I understands things correctly, both DTS patch and this
> > > > patch are waiting in your tree, so we should be good to go for 4.9
> > > > (unless some unexpected problems surface)?
> > > >
> > > > Best regards,
> > > > Pavel
> > >
> > > Was DTS patch merged into 4.9? At least I do not see updated that dts
> > > file omap3-n900.dts in linus tree...
> >
> > If it's not in current mainline or next, it's off my radar so sounds
> > like I've somehow missed it and needs resending..
>
> Where's this patch? I remember seeing the driver patch and the DT
> documentation but no actual DT source patch for the N900.
The patch was not yet submitted. Autofocus coil is not too useful
withou camera support, and we don't yet have support for v4l subdevs
for omap3. I have it in the camera tree, but there are still pieces to
be done before this is useful.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161219/39969b35/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: Document the hi3660 clock bindings
From: Rob Herring @ 2016-12-19 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481781493-6188-2-git-send-email-zhangfei.gao@linaro.org>
On Thu, Dec 15, 2016 at 01:58:12PM +0800, Zhangfei Gao wrote:
> Add DT bindings documentation for hi3660 SoC clock.
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> ---
> .../devicetree/bindings/clock/hi3660-clock.txt | 42 ++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/hi3660-clock.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/hi3660-clock.txt b/Documentation/devicetree/bindings/clock/hi3660-clock.txt
> new file mode 100644
> index 0000000..7296fd7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/hi3660-clock.txt
> @@ -0,0 +1,42 @@
> +* Hisilicon Hi3660 Clock Controller
> +
> +The Hi3660 clock controller generates and supplies clock to various
> +controllers within the Hi3660 SoC.
> +
> +Required Properties:
> +
> +- compatible: the compatible should be one of the following strings to
> + indicate the clock controller functionality.
> +
> + - "hisilicon,hi3660-crgctrl"
> + - "hisilicon,hi3660-pctrl"
> + - "hisilicon,hi3660-pmuctrl"
> + - "hisilicon,hi3660-sctrl"
> + - "hisilicon,hi3660-iomcu"
> +
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +
> +- #clock-cells: should be 1.
> +
> +Each clock is assigned an identifier and client nodes use this identifier
> +to specify the clock which they consume.
> +
> +All these identifier could be found in <dt-bindings/clock/hi3660-clock.h>.
> +
> +Examples:
> + crg_ctrl: crg_ctrl at fff35000 {
clock-controller at ...
> + compatible = "hisilicon,hi3660-crgctrl", "syscon";
> + reg = <0x0 0xfff35000 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + uart0: uart at fdf02000 {
serial at ...
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x0 0xfdf02000 0x0 0x1000>;
> + interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&crg_ctrl HI3660_CLK_MUX_UART0>,
> + <&crg_ctrl HI3660_PCLK>;
> + clock-names = "uartclk", "apb_pclk";
> + status = "disabled";
> + };
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH pci/host-iproc] PCI: iproc: Allow more than slot 0 on PAXC
From: Andy Gospodarek @ 2016-12-19 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fdd96c8d-93ae-81e8-57e7-457a5d7f21a6@broadcom.com>
On Mon, Dec 19, 2016 at 02:01:59PM -0800, Ray Jui wrote:
>
>
> On 12/19/2016 1:30 PM, Andy Gospodarek wrote:
> > On Mon, Dec 19, 2016 at 10:54:15AM -0800, Ray Jui wrote:
> >>
> >>
> >> On 12/8/2016 1:30 PM, Andy Gospodarek wrote:
> >>> The iproc host driver limits the number of slots that are available on
> >>> PAXC devices. Enforcing this limit prevents VFs from being created
> >>> beyond the first port. After this change it is possible to create VFs
> >>> associated with all four devices.
> >>>
> >>> The first four devices below are the PFs and the next four are the newly
> >>> created VFs:
> >>>
> >>> 0008:01:00.0 Ethernet controller: Broadcom Limited Device 16cd
> >>> 0008:01:00.1 Ethernet controller: Broadcom Limited Device 16cd
> >>> 0008:01:00.2 Ethernet controller: Broadcom Limited Device 16cd
> >>> 0008:01:00.3 Ethernet controller: Broadcom Limited Device 16cd
> >>> 0008:01:00.4 Ethernet controller: Broadcom Limited BCM57304 NetXtreme-C Ethernet Virtual Function
> >>> 0008:01:01.0 Ethernet controller: Broadcom Limited BCM57304 NetXtreme-C Ethernet Virtual Function
> >>> 0008:01:01.4 Ethernet controller: Broadcom Limited BCM57304 NetXtreme-C Ethernet Virtual Function
> >>> 0008:01:02.0 Ethernet controller: Broadcom Limited BCM57304 NetXtreme-C Ethernet Virtual Function
> >>>
> >>> Based on the git history around 923c6bb1f641 ("PCI: iproc: Allow multiple
> >>> devices except on PAXC") and 943ebae781f5 ("PCI: iproc: Add PAXC interface
> >>> support") I expect there may be an unmentioned or unknown-to-me reason why this
> >>> code exists. I certainly cannot create and use VFs without some kind of change
> >>> around this space, so I would like to see the current limitation simply removed.
> >>>
> >>> Fixes: 923c6bb1f641 ("PCI: iproc: Allow multiple devices except on PAXC")
> >>
> >>> Signed-off-by: Andy Gospodarek <gospo@broadcom.com>
> >>> ---
> >>> drivers/pci/host/pcie-iproc.c | 8 --------
> >>> 1 file changed, 8 deletions(-)
> >>>
> >>> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> >>> index 3ebc025..9311826 100644
> >>> --- a/drivers/pci/host/pcie-iproc.c
> >>> +++ b/drivers/pci/host/pcie-iproc.c
> >>> @@ -477,14 +477,6 @@ static void __iomem *iproc_pcie_map_cfg_bus(struct pci_bus *bus,
> >>> return (pcie->base + offset);
> >>> }
> >>>
> >>> - /*
> >>> - * PAXC is connected to an internally emulated EP within the SoC. It
> >>> - * allows only one device.
> >>> - */
> >>> - if (pcie->ep_is_internal)
> >>> - if (slot > 0)
> >>> - return NULL;
> >>> -
> >>> /* EP device access */
> >>> val = (busno << CFG_ADDR_BUS_NUM_SHIFT) |
> >>> (slot << CFG_ADDR_DEV_NUM_SHIFT) |
> >>>
> >>
> >> With this change, standard v4.9 kernel would crash on a NS2 SVK with the
> >> log shown below. This is inline with my previous observation and
> >> therefore slot number has been limited to only zero for the PAXC
> >> interface. Does it require more than just this change in order for the
> >> kernel to boot to complete?
> >>
> >> [ 2.190515] OF: PCI: host bridge /pcie at 60c00000 ranges:
> >> [ 2.196400] OF: PCI: MEM 0x60000000..0x60bfffff -> 0x00000000
> >> [ 2.203135] iproc-pcie 60c00000.pcie: PCI host bridge to bus 0008:00
> >> [ 2.210289] pci_bus 0008:00: root bus resource [bus 00-01]
> >> [ 2.216349] pci_bus 0008:00: root bus resource [mem
> >> 0x60000000-0x60bfffff] (bus address [0x00000000-0x00bfffff])
> >> [ 2.227769] iproc-pcie 60c00000.pcie: not using iProc MSI
> >> [ 2.234050] pci 0008:00:00.0: bridge configuration invalid ([bus
> >> 00-00]), reconfiguring
> >> [ 2.244285] Bad mode in Error handler detected on CPU1, code
> >> 0xbf000002 -- SError
> >> [ 2.252661] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.9.0+ #24
> >> [ 2.259430] Hardware name: Broadcom NS2 SVK (DT)
> >> [ 2.264550] task: ffff8000fb488000 task.stack: ffff8000fb490000
> >> [ 2.271161] PC is at pci_generic_config_read32+0x74/0xa0
> >> [ 2.277043] LR is at pci_generic_config_read32+0x28/0xa0
> >> [ 2.283005] pc : [<ffff00000839d984>] lr : [<ffff00000839d938>]
> >> pstate: 200000c5
> >> [ 2.291225] sp : ffff8000fb4937f0
> >> [ 2.294937] x29: ffff8000fb4937f0 x28: ffff8000fadb9000
> >> [ 2.300884] x27: ffff8000faf27098 x26: 0000000000000000
> >> [ 2.306803] x25: 0000000000000000 x24: ffff8000fadb9400
> >> [ 2.312757] x23: 0000000000000040 x22: ffff0000089c55d8
> >> [ 2.318730] x21: 0000000000000010 x20: ffff8000fb49391c
> >> [ 2.324666] x19: 0000000000000000 x18: 000000000000077f
> >> [ 2.330594] x17: ffffffffffffffff x16: ffff000008a49fff
> >> [ 2.336539] x15: ffff000008a49fff x14: 0000000000000000
> >> [ 2.342502] x13: 0000000000000007 x12: 0000000000000018
> >> [ 2.348456] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
> >> [ 2.354392] x9 : 0000000000000000 x8 : ffff8000fa80e680
> >> [ 2.360355] x7 : 000000000000ffff x6 : ffff8000faf0ca98
> >> [ 2.366300] x5 : 0000000000000002 x4 : ffff8000fb49389c
> >> [ 2.372290] x3 : 0000000000000004 x2 : 0000000000100001
> >> [ 2.378209] x1 : ffff000008a49000 x0 : 0000000000000000
> >> [ 2.384145]
> >> [ 2.385807] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
> >> [ 2.392351] Modules linked in:
> >> [ 2.395770] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.9.0+ #24
> >> [ 2.402529] Hardware name: Broadcom NS2 SVK (DT)
> >> [ 2.407693] task: ffff8000fb488000 task.stack: ffff8000fb490000
> >> [ 2.414301] PC is at pci_generic_config_read32+0x74/0xa0
> >> [ 2.420299] LR is at pci_generic_config_read32+0x28/0xa0
> >> [ 2.426279] pc : [<ffff00000839d984>] lr : [<ffff00000839d938>]
> >> pstate: 200000c5
> >> [ 2.434552] sp : ffff8000fb4937f0
> >> [ 2.438246] x29: ffff8000fb4937f0 x28: ffff8000fadb9000
> >> [ 2.444209] x27: ffff8000faf27098 x26: 0000000000000000
> >> [ 2.450137] x25: 0000000000000000 x24: ffff8000fadb9400
> >> [ 2.456091] x23: 0000000000000040 x22: ffff0000089c55d8
> >> [ 2.462037] x21: 0000000000000010 x20: ffff8000fb49391c
> >> [ 2.467947] x19: 0000000000000000 x18: 000000000000077f
> >> [ 2.473945] x17: ffffffffffffffff x16: ffff000008a49fff
> >> [ 2.479881] x15: ffff000008a49fff x14: 0000000000000000
> >> [ 2.485826] x13: 0000000000000007 x12: 0000000000000018
> >> [ 2.491798] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
> >> [ 2.497752] x9 : 0000000000000000 x8 : ffff8000fa80e680
> >> [ 2.503689] x7 : 000000000000ffff x6 : ffff8000faf0ca98
> >> [ 2.509643] x5 : 0000000000000002 x4 : ffff8000fb49389c
> >> [ 2.515561] x3 : 0000000000000004 x2 : 0000000000100001
> >> [ 2.521453] x1 : ffff000008a49000 x0 : 0000000000000000
> >> [ 2.527388]
> >> [ 2.529058] Process swapper/0 (pid: 1, stack limit = 0xffff8000fb490020)
> >> [ 2.536607] Stack: (0xffff8000fb4937f0 to 0xffff8000fb494000)
> >> [ 2.543044] 37e0: ffff8000fb493820
> >> ffff0000083b65cc
> >> [ 2.551830] 3800: ffff8000fadb9400 ffff00000867606c 0000000000000004
> >> ffff8000fb49389c
> >> [ 2.560481] 3820: ffff8000fb493840 ffff00000839dcc8 ffff8000fadb9400
> >> ffff00000839dce0
> >> [ 2.569158] 3840: ffff8000fb4938a0 ffff00000839fcb8 0000000000000000
> >> ffff8000fb49391c
> >> [ 2.577915] 3860: 000000000000ea60 0000000000000001 0000000000000010
> >> 0000000000000000
> >> [ 2.586718] 3880: ffff8000faef9000 0000000000000000 ffff8000fb4938b0
> >> 00000000083a94d8
> >> [ 2.595548] 38a0: ffff8000fb4938e0 ffff0000083a1380 0000000000000000
> >> ffff8000fadb9400
> >> [ 2.604359] 38c0: 0000000000000010 0000000000000001 ffff0000087fb000
> >> ffff8000fadb9528
> >> [ 2.613180] 38e0: ffff8000fb493920 ffff0000083a1444 ffff8000fadb9400
> >> ffff8000fadb9400
> >> [ 2.621938] 3900: 0000000000000010 0000000000000004 ffff8000fb493960
> >> fffffffffb493960
> >> [ 2.630767] 3920: ffff8000fb493960 ffff0000083a237c 0000000000000018
> >> ffff8000fadb9400
> >> [ 2.639543] 3940: 0000000000000001 0000000000000000 ffff8000fadb9000
> >> 0000000000000007
> >> [ 2.648355] 3960: ffff8000fb4939b0 ffff0000083a20d8 ffff8000faf27000
> >> ffff8000fadb9400
> >> [ 2.657166] 3980: 0000000000000001 0000000000000000 0000000000000000
> >> 0000000000000001
> >> [ 2.665960] 39a0: 0000000000000000 0000000000000018 ffff8000fb493a30
> >> ffff0000083a23d8
> >> [ 2.674789] 39c0: ffff8000faf27000 ffff8000fadb9000 ffff8000fadb9028
> >> 0000000000000000
> >> [ 2.683547] 39e0: ffff0000087fb000 ffff8000fadb9128 0000000000000001
> >> ffff0000088c0460
> >> [ 2.692341] 3a00: ffff0000089a4000 ffff0000088f8b60 ffff8000fb49396c
> >> 0000000000000000
> >> [ 2.701117] 3a20: 0000000000000000 00ff010000000000 ffff8000fb493a80
> >> ffff0000083b731c
> >> [ 2.709910] 3a40: ffff8000faf0e218 ffff8000fffe7748 ffff8000fb63f410
> >> ffff8000fadb9000
> >> [ 2.718695] 3a60: ffff0000086e9000 ffff8000fffe1e00 ffff0000088f8bc0
> >> 6c6071652c6c3175
> >> [ 2.727489] 3a80: ffff8000fb493bc0 ffff0000083b8774 0000000000000000
> >> ffff8000faf0e218
> >> [ 2.736291] 3aa0: ffff8000fb63f410 ffff8000fb493c10 ffff8000fffe1e00
> >> ffff8000fb63f400
> >> [ 2.745058] 3ac0: ffff0000088f8bc0 ffff0000088c0460 ffff0000089a4000
> >> ffff0000088f8b60
> >> [ 2.753816] 3ae0: ffff8000fb493b20 ffff00000858b7b0 ffff8000fb493c08
> >> ffff000008855f08
> >> [ 2.762583] 3b00: ffff0000089b6000 ffff8000fb493c10 ffff8000fffe1e00
> >> 0000000060000000
> >> [ 2.771376] 3b20: ffff8000fb493bc0 ffff0000083b8744 0000000000000000
> >> ffff8000faf0e218
> >> [ 2.780125] 3b40: ffff8000fb63f410 ffff8000fb493c10 ffff8000fffe1e00
> >> ffff8000fb63f400
> >> [ 2.788937] 3b60: ffff8000fffe1e00 0000000000000000 ffff0000004d454d
> >> 0000000200000007
> >> [ 2.797731] 3b80: ffff7dfffe8009dc ffff7dfffe8009dc 0000000200000007
> >> ffff000000000083
> >> [ 2.806533] 3ba0: 0000000000000000 0000000060000000 0000000000c00000
> >> 0000000000000200
> >> [ 2.815372] 3bc0: ffff8000fb493c60 ffff000008414ef8 ffff000008962258
> >> ffff8000fb63f410
> >> [ 2.824121] 3be0: 0000000000000000 ffff000008962280 0000000000000000
> >> ffff0000089a4000
> >> [ 2.832950] 3c00: ffff8000fb493c40 ffffffffffffffff ffff8000fb493c10
> >> ffff8000fb493c10
> >> [ 2.841717] 3c20: 0000000060c00000 0000000060c00fff ffff8000fffe1ea8
> >> 0000000000000200
> >> [ 2.850529] 3c40: 0000000000000000 0000000000000000 0000000000000000
> >> 0000000000000000
> >> [ 2.859358] 3c60: ffff8000fb493c80 ffff000008413688 ffff8000fb63f410
> >> ffff0000089c8000
> >> [ 2.868161] 3c80: ffff8000fb493cc0 ffff0000084137c0 ffff8000fb63f410
> >> ffff000008962280
> >> [ 2.876919] 3ca0: ffff8000fb63f470 ffff00000896cd30 ffff00000896c000
> >> ffff00000841190c
> >> [ 2.885677] 3cc0: ffff8000fb493cf0 ffff000008411900 0000000000000000
> >> ffff000008962280
> >> [ 2.894497] 3ce0: ffff000008413720 ffff8000fb493d40 ffff8000fb493d30
> >> ffff000008413124
> >> [ 2.903308] 3d00: ffff000008962280 ffff8000faf0e100 0000000000000000
> >> ffff00000867606c
> >> [ 2.912058] 3d20: ffff8000fb43eca8 ffff8000fb625b68 ffff8000fb493d40
> >> ffff000008412d84
> >> [ 2.920815] 3d40: ffff8000fb493d80 ffff000008413eb4 ffff000008962280
> >> ffff0000088e1438
> >> [ 2.929591] 3d60: 0000000000000000 ffff0000088f8b30 ffff0000088aba00
> >> ffff0000089c5000
> >> [ 2.938358] 3d80: ffff8000fb493db0 ffff000008414eb8 ffff8000fb490000
> >> ffff0000088e1438
> >> [ 2.947134] 3da0: 0000000000000000 0000000000000000 ffff8000fb493dc0
> >> ffff0000088e1450
> >> [ 2.955936] 3dc0: ffff8000fb493dd0 ffff000008083144 ffff8000fb493e40
> >> ffff0000088c0c98
> >> [ 2.964658] 3de0: ffff000008907240 0000000000000006 00000000000000e7
> >> ffff0000088f8b30
> >> [ 2.973506] 3e00: ffff8000fb493e00 ffff0000087f42c8 ffff8000fb493e20
> >> ffff0000087f3ae8
> >> [ 2.982326] 3e20: 0000000600000006 0000000000000000 0000000000000000
> >> ffff0000088aba00
> >> [ 2.991129] 3e40: ffff8000fb493ea0 ffff000008678154 ffff000008678144
> >> 0000000000000000
> >> [ 2.999922] 3e60: 0000000000000000 0000000000000000 0000000000000000
> >> 0000000000000000
> >> [ 3.008671] 3e80: 0000000000000000 0000000000000000 0000000000000000
> >> 0000000000000000
> >> [ 3.017500] 3ea0: 0000000000000000 ffff000008082e80 ffff000008678144
> >> 0000000000000000
> >> [ 3.026294] 3ec0: 0000000000000000 0000000000000000 0000000000000000
> >> 0000000000000000
> >> [ 3.035043] 3ee0: 0000000000000000 0000000000000000 0000000000000000
> >> 0000000000000000
> >> [ 3.043818] 3f00: 0000000000000000 0000000000000000 0000000000000000
> >> 0000000000000000
> >> [ 3.052639] 3f20: 0000000000000000 0000000000000000 0000000000000000
> >> 0000000000000000
> >> [ 3.061432] 3f40: 0000000000000000 0000000000000000 0000000000000000
> >> 0000000000000000
> >> [ 3.070207] 3f60: 0000000000000000 0000000000000000 0000000000000000
> >> 0000000000000000
> >> [ 3.079036] 3f80: 0000000000000000 0000000000000000 0000000000000000
> >> 0000000000000000
> >> [ 3.087820] 3fa0: 0000000000000000 0000000000000000 0000000000000000
> >> 0000000000000000
> >> [ 3.096623] 3fc0: 0000000000000000 0000000000000005 0000000000000000
> >> 0000000000000000
> >> [ 3.105398] 3fe0: 0000000000000000 0000000000000000 000000017b493ff0
> >> 000000017b493ff8
> >> [ 3.114173] Call trace:
> >> [ 3.116920] [<ffff00000839d984>] pci_generic_config_read32+0x74/0xa0
> >> [ 3.124039] [<ffff0000083b65cc>] iproc_pcie_config_read32+0x2c/0xe0
> >> [ 3.131041] [<ffff00000839dcc8>] pci_bus_read_config_dword+0x80/0xb0
> >> [ 3.138143] [<ffff00000839fcb8>] pci_bus_read_dev_vendor_id+0x30/0x104
> >> [ 3.145459] [<ffff0000083a1380>] pci_scan_single_device+0x50/0xc4
> >> [ 3.152345] [<ffff0000083a1444>] pci_scan_slot+0x50/0xf0
> >> [ 3.158334] [<ffff0000083a237c>] pci_scan_child_bus+0x50/0x164
> >> [ 3.164798] [<ffff0000083a20d8>] pci_scan_bridge+0x2c0/0x514
> >> [ 3.171154] [<ffff0000083a23d8>] pci_scan_child_bus+0xac/0x164
> >> [ 3.177690] [<ffff0000083b731c>] iproc_pcie_setup+0x71c/0xc78
> >> [ 3.184172] [<ffff0000083b8774>] iproc_pcie_pltfm_probe+0x170/0x260
> >> [ 3.191176] [<ffff000008414ef8>] platform_drv_probe+0x38/0x7c
> >> [ 3.197640] [<ffff000008413688>] really_probe+0x1b0/0x248
> >> [ 3.203701] [<ffff0000084137c0>] __driver_attach+0xa0/0xb0
> >> [ 3.209878] [<ffff000008411900>] bus_for_each_dev+0x58/0x98
> >> [ 3.216110] [<ffff000008413124>] driver_attach+0x20/0x28
> >> [ 3.222063] [<ffff000008412d84>] bus_add_driver+0x1c8/0x22c
> >> [ 3.228285] [<ffff000008413eb4>] driver_register+0x68/0x108
> >> [ 3.234517] [<ffff000008414eb8>] __platform_driver_register+0x4c/0x54
> >> [ 3.241772] [<ffff0000088e1450>] iproc_pcie_pltfm_driver_init+0x18/0x20
> >> [ 3.249224] [<ffff000008083144>] do_one_initcall+0x38/0x128
> >> [ 3.255466] [<ffff0000088c0c98>] kernel_init_freeable+0x14c/0x1ec
> >> [ 3.262344] [<ffff000008678154>] kernel_init+0x10/0xfc
> >> [ 3.268118] [<ffff000008082e80>] ret_from_fork+0x10/0x50
> >> [ 3.274108] Code: 52800000 f9400bf3 a8c37bfd d65f03c0 (b9000080)
> >> [ 3.280984] ---[ end trace d90bb74924ac9e8e ]---
> >> [ 3.286202] note: swapper/0[1] exited with preempt_count 1
> >> [ 3.292340] Kernel panic - not syncing: Attempted to kill init!
> >> exitcode=0x0000000b
> >> [ 3.292340]
> >>
> >
> > I originally tested this patch with the following DT change to enable
> > that PCI slot on the host-iproc branch (uname reports it as 4.9.0-rc1+).
> > I also just tested it again to be sure and I do not see the same crash
> > you see. I'll test Linus' tree and see if I can reproduce what you are
> > seeing. We can also share configs offline if needed.
> >
>
> Does this require a certain version of Chimp firmware to run on Nitro
> for it to work properly?
It _may_. I've been testing with 0.0.7.0 -- which version are you using?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox