* [PATCH] kirkwood: fix spelling mistake
From: Andrew Lunn @ 2016-11-17 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <trinity-6911950b-e19a-4b44-aeed-adaccbc33164-1479414587776@3capp-gmx-bs50>
On Thu, Nov 17, 2016 at 09:29:47PM +0100, p.wassi at gmx.at wrote:
> From: Paul Wassi <p.wassi@gmx.at>
Hi Paul
You should also send the patch to the Marvell MVEBU
maintainers. Otherwise it can fall through the cracks.
Andrew
^ permalink raw reply
* [PATCH] kirkwood: fix spelling mistake
From: Andrew Lunn @ 2016-11-17 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <trinity-6911950b-e19a-4b44-aeed-adaccbc33164-1479414587776@3capp-gmx-bs50>
On Thu, Nov 17, 2016 at 09:29:47PM +0100, p.wassi at gmx.at wrote:
> From: Paul Wassi <p.wassi@gmx.at>
>
> Fix a spelling mistake in arch/arm/boot/dts/kirkwood-topkick.dts
>
> Signed-off-by: Paul Wassi <p.wassi@gmx.at>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Thanks
Andrew
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Explicitly enable pull-ups for MMC pins
From: klaus.goger at theobroma-systems.com @ 2016-11-17 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117093438.17988-1-wens@csie.org>
On 2016-11-17 10:34, Chen-Yu Tsai wrote:
> Given that MMC starts in open-drain mode and the pull-ups are required,
> it's best to enable it for all the pin settings.
It's even more complicated than that with MMC. It starts in open-drain
mode for
CMD during initialization but changes to push-pull afterwards. The card
has
internal pull-ups to prevent bus floating during setup and will disable
them
after switching to 4bit mode (or 8bit for eMMC when available).
But even after switching to push-pull drivers there are states the bus
would
float and pull ups have to ensure a high level on the bus.
See JESD84-A441 chapter 7.15 ff as reference.
The difference between the P-bit and Z-bit is that a P-bit is actively
driven
to HIGH by the card respectively host output driver, while Z-bit is
driven to
(respectively kept) HIGH by the pull-up resistors Rcmd respectively
Rdat.
Enabling the pull ups on the CPU would be the right choice considering
that
most boards will not have external pull-ups. Even if they would have
one,
adding the internal in parallel would work in almost all cases and the
increase in power consumption would be negligible.
Cheers,
Klaus
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Explicitly enable pull-ups for MMC pins
From: Maxime Ripard @ 2016-11-17 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117093438.17988-1-wens@csie.org>
On Thu, Nov 17, 2016 at 05:34:38PM +0800, Chen-Yu Tsai wrote:
> In the past, all the MMC pins had
>
> allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>
> which was actually a no-op. We were relying on U-boot to set the bias
> pull up for us. These properties were removed as part of the fix up to
> actually support no bias on the pins. During the transition some boards
> experienced regular MMC time-outs during normal operation, while others
> completely failed to initialize the SD card.
>
> Given that MMC starts in open-drain mode and the pull-ups are required,
> it's best to enable it for all the pin settings.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161117/a5739611/attachment.sig>
^ permalink raw reply
* [PATCH fpga 8/9] fpga socfpga: Use the scatterlist interface
From: atull @ 2016-11-17 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1611171350590.4425@atull-VirtualBox2>
On Thu, 17 Nov 2016, atull wrote:
> On Wed, 16 Nov 2016, Jason Gunthorpe wrote:
>
> > On Wed, Nov 16, 2016 at 09:45:23AM -0600, atull wrote:
> > > > What is the point of this if write_init gets a copy of the buffer -
> > > > what is that supposed to be?
> > >
> > > Sometimes write_init needs to look at the header of the image.
> > > You can see that in the socfpga-a10.c (on linux-next/master)
> >
> > I know what it is for, I'm asking what should it be if we are calling
> > write_init multiple times.
> >
> > It feels like the driver needs to indicate the header length it wants
> > to inspect and the core core needs to make that much of the bitstream
> > available to write_init() before calling write().
> >
> > Is that what you were thinking?
>
> That would make sense. socfpga-a10.c requires a certain amount
> of header in write_init, but the current API didn't have a way
> for socfgpa-a10.c to specify that to fpga-mgr.c core. Should
> probably happen during registration. If you have an idea about
> that, that's good, otherwise we'll get back to that separately.
>
> >
> > > at this stuff, this is coming at a busy time). My point there
> > > was that there was code that needed to go into the core so that
> > > the ICE40 and the cyclone spi driver that are on the mailing
> > > list won't have to have the same workaround that you were
> > > adding to the socfpga.c driver.
> >
> > Sure, that is easy for write() - not clear on write_init sematics?
> > I will send a revised series.
> >
> > I'd also like to close on the zynq bitfile verification patch, did you
> > have any comments on that?
>
> I think Joshua had some comments. Besides that, I'm ok with that
> patch.
>
> Alan
I didn't have any other specific issues with on the other
zynq patches.
For the sg patches, I don't have anything more to say
that I haven't already said.
I want to keep open the possibility of streaming an FPGA image
in. In this case the FPGA image is not complete in memory
and write() will be called multiple times. One case is where
maybe hopefully the firmware layer can be extended to not
allocate a large buffer (scattered or contiguous) and can
stream in the image.
If you have a nice way to move the workarounds that you had
to add to socfpga.c into the core so they don't replicated
in socfpga-a10.c, ICE40, cyclone5 spi and other new drivers
that aren't using sg natively, that would be good.
I think I've already said all this before so please figure
that into he your v2 when you rebase onto linux-next.
Alan
>
> >
> > Jason
> >
>
^ permalink raw reply
* [PATCH] kirkwood: fix spelling mistake
From: p.wassi at gmx.at @ 2016-11-17 20:29 UTC (permalink / raw)
To: linux-arm-kernel
From: Paul Wassi <p.wassi@gmx.at>
Fix a spelling mistake in arch/arm/boot/dts/kirkwood-topkick.dts
Signed-off-by: Paul Wassi <p.wassi@gmx.at>
---
The manufacturer's name is Univer*s*al Scientific Industrial...
Compare with footer of page here:
http://www.usish.com/english/products_topkick1281p2.php
arch/arm/boot/dts/kirkwood-topkick.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -rupN a/arch/arm/boot/dts/kirkwood-topkick.dts b/arch/arm/boot/dts/kirkwood-topkick.dts
--- a/arch/arm/boot/dts/kirkwood-topkick.dts
+++ b/arch/arm/boot/dts/kirkwood-topkick.dts
@@ -4,7 +4,7 @@
#include "kirkwood-6282.dtsi"
/ {
- model = "Univeral Scientific Industrial Co. Topkick-1281P2";
+ model = "Universal Scientific Industrial Co. Topkick-1281P2";
compatible = "usi,topkick-1281P2", "usi,topkick", "marvell,kirkwood-88f6282", "marvell,kirkwood";
memory {
^ permalink raw reply
* [PATCH v4 2/2] ARM: dts: sun6i: hummingbird-a31: Enable display output through VGA bridge
From: Maxime Ripard @ 2016-11-17 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116154232.872-3-wens@csie.org>
On Wed, Nov 16, 2016 at 11:42:32PM +0800, Chen-Yu Tsai wrote:
> The Hummingbird A31 board has a VGA DAC which converts RGB output
> from the LCD interface to VGA analog signals.
>
> Add nodes for the VGA DAC, its power supply, and enable this part
> of the display pipeline.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161117/14fb64a4/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Maxime Ripard @ 2016-11-17 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116131508.12541-1-hdegoede@redhat.com>
On Wed, Nov 16, 2016 at 02:15:08PM +0100, Hans de Goede wrote:
> Just like on sun8i all sun5i tablets use the same interrupt and power
> gpios for their touchscreens. I've checked all known a13 fex files and
> only the UTOO P66 uses a different gpio for the interrupt.
>
> Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
> fills in the necessary gpios to avoid duplication in the tablet dts files,
> just like we do in sun8i-reference-design-tablet.dtsi.
>
> This will make future patches adding touchscreen nodes to a13 tablets
> simpler.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161117/173b0eaf/attachment.sig>
^ permalink raw reply
* [PATCH fpga 8/9] fpga socfpga: Use the scatterlist interface
From: atull @ 2016-11-17 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116202329.GD19593@obsidianresearch.com>
On Wed, 16 Nov 2016, Jason Gunthorpe wrote:
> On Wed, Nov 16, 2016 at 09:45:23AM -0600, atull wrote:
> > > What is the point of this if write_init gets a copy of the buffer -
> > > what is that supposed to be?
> >
> > Sometimes write_init needs to look at the header of the image.
> > You can see that in the socfpga-a10.c (on linux-next/master)
>
> I know what it is for, I'm asking what should it be if we are calling
> write_init multiple times.
>
> It feels like the driver needs to indicate the header length it wants
> to inspect and the core core needs to make that much of the bitstream
> available to write_init() before calling write().
>
> Is that what you were thinking?
That would make sense. socfpga-a10.c requires a certain amount
of header in write_init, but the current API didn't have a way
for socfgpa-a10.c to specify that to fpga-mgr.c core. Should
probably happen during registration. If you have an idea about
that, that's good, otherwise we'll get back to that separately.
>
> > at this stuff, this is coming at a busy time). My point there
> > was that there was code that needed to go into the core so that
> > the ICE40 and the cyclone spi driver that are on the mailing
> > list won't have to have the same workaround that you were
> > adding to the socfpga.c driver.
>
> Sure, that is easy for write() - not clear on write_init sematics?
> I will send a revised series.
>
> I'd also like to close on the zynq bitfile verification patch, did you
> have any comments on that?
I think Joshua had some comments. Besides that, I'm ok with that
patch.
Alan
>
> Jason
>
^ permalink raw reply
* [PATCH] drm/sun4i: tcon: Initialize regmap after enabling bus clocks
From: Maxime Ripard @ 2016-11-17 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116093732.12828-2-wens@csie.org>
On Wed, Nov 16, 2016 at 05:37:32PM +0800, Chen-Yu Tsai wrote:
> If we attempt to read/write the TCON registers before the bus clock
> is enabled, those accesses get ignored.
>
> In practice this almost never occurs because U-boot had already enabled
> the bus clock as part of its firmware provided framebuffer (simplefb).
>
> Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>
> I was looking around the DRM driver and noticed this sequence was off.
>
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index c6afb2448655..8c2db65ea229 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -506,16 +506,16 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
> return ret;
> }
>
> - ret = sun4i_tcon_init_regmap(dev, tcon);
> + ret = sun4i_tcon_init_clocks(dev, tcon);
> if (ret) {
> - dev_err(dev, "Couldn't init our TCON regmap\n");
> + dev_err(dev, "Couldn't init our TCON clocks\n");
> goto err_assert_reset;
> }
>
> - ret = sun4i_tcon_init_clocks(dev, tcon);
> + ret = sun4i_tcon_init_regmap(dev, tcon);
> if (ret) {
> - dev_err(dev, "Couldn't init our TCON clocks\n");
> - goto err_assert_reset;
> + dev_err(dev, "Couldn't init our TCON regmap\n");
> + goto err_free_clocks;
> }
That won't work either. sun4i_tcon_init_clocks requires the regmap to
be enabled before it calls sun4i_dclk_create.
Maybe we should just move that call outside of sun4i_tcon_init_clocks
and put it directly into the bind then.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161117/ac4950fb/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: qcom: Add apq8064 CoreSight components
From: Mathieu Poirier @ 2016-11-17 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117153609.11705-1-georgi.djakov@linaro.org>
On Thu, Nov 17, 2016 at 05:36:09PM +0200, Georgi Djakov wrote:
> From: "Ivan T. Ivanov" <ivan.ivanov@linaro.org>
>
> Add initial set of CoreSight components found on Qualcomm's
> 8064 chipset.
>
> Signed-off-by: Ivan T. Ivanov <ivan.ivanov@linaro.org>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
> arch/arm/boot/dts/qcom-apq8064-coresight.dtsi | 196 ++++++++++++++++++++++++++
> arch/arm/boot/dts/qcom-apq8064.dtsi | 11 +-
> 2 files changed, 203 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm/boot/dts/qcom-apq8064-coresight.dtsi
>
> diff --git a/arch/arm/boot/dts/qcom-apq8064-coresight.dtsi b/arch/arm/boot/dts/qcom-apq8064-coresight.dtsi
> new file mode 100644
> index 000000000000..9395fddb1bf0
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-apq8064-coresight.dtsi
> @@ -0,0 +1,196 @@
> +/*
> + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +&soc {
> +
> + etb at 1a01000 {
> + compatible = "coresight-etb10", "arm,primecell";
> + reg = <0x1a01000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etb_in: endpoint {
> + slave-mode;
> + remote-endpoint = <&replicator_out0>;
> + };
> + };
> + };
> +
> + tpiu at 1a03000 {
> + compatible = "arm,coresight-tpiu", "arm,primecell";
> + reg = <0x1a03000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + port {
> + tpiu_in: endpoint {
> + slave-mode;
> + remote-endpoint = <&replicator_out1>;
> + };
> + };
> + };
> +
> + replicator {
> + compatible = "arm,coresight-replicator";
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + replicator_out0: endpoint {
> + remote-endpoint = <&etb_in>;
> + };
> + };
> + port at 1 {
> + reg = <1>;
> + replicator_out1: endpoint {
> + remote-endpoint = <&tpiu_in>;
> + };
> + };
> + port at 2 {
> + reg = <0>;
> + replicator_in: endpoint {
> + slave-mode;
> + remote-endpoint = <&funnel_out>;
> + };
> + };
> + };
> + };
> +
> + funnel at 1a04000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0x1a04000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /*
> + * Not described input ports:
> + * 2 - connected to STM component
> + * 3 - not-connected
> + * 6 - not-connected
> + * 7 - not-connected
> + */
> + port at 0 {
> + reg = <0>;
> + funnel_in0: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm0_out>;
> + };
> + };
> + port at 1 {
> + reg = <1>;
> + funnel_in1: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm1_out>;
> + };
> + };
> + port at 4 {
> + reg = <4>;
> + funnel_in4: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm2_out>;
> + };
> + };
> + port at 5 {
> + reg = <5>;
> + funnel_in5: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm3_out>;
> + };
> + };
> + port at 8 {
> + reg = <0>;
> + funnel_out: endpoint {
> + remote-endpoint = <&replicator_in>;
> + };
> + };
> + };
> + };
> +
> + etm at 1a1c000 {
> + compatible = "arm,coresight-etm3x", "arm,primecell";
> + reg = <0x1a1c000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&CPU0>;
> +
> + port {
> + etm0_out: endpoint {
> + remote-endpoint = <&funnel_in0>;
> + };
> + };
> + };
> +
> + etm at 1a1d000 {
> + compatible = "arm,coresight-etm3x", "arm,primecell";
> + reg = <0x1a1d000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&CPU1>;
> +
> + port {
> + etm1_out: endpoint {
> + remote-endpoint = <&funnel_in1>;
> + };
> + };
> + };
> +
> + etm at 1a1e000 {
> + compatible = "arm,coresight-etm3x", "arm,primecell";
> + reg = <0x1a1e000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&CPU2>;
> +
> + port {
> + etm2_out: endpoint {
> + remote-endpoint = <&funnel_in4>;
> + };
> + };
> + };
> +
> + etm at 1a1f000 {
> + compatible = "arm,coresight-etm3x", "arm,primecell";
> + reg = <0x1a1f000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&CPU3>;
> +
> + port {
> + etm3_out: endpoint {
> + remote-endpoint = <&funnel_in5>;
> + };
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index 268bd470c865..18469c632e2f 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -4,6 +4,7 @@
> #include <dt-bindings/clock/qcom,gcc-msm8960.h>
> #include <dt-bindings/reset/qcom,gcc-msm8960.h>
> #include <dt-bindings/clock/qcom,mmcc-msm8960.h>
> +#include <dt-bindings/clock/qcom,rpmcc.h>
> #include <dt-bindings/soc/qcom,gsbi.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> @@ -27,7 +28,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> - cpu at 0 {
> + CPU0: cpu at 0 {
> compatible = "qcom,krait";
> enable-method = "qcom,kpss-acc-v1";
> device_type = "cpu";
> @@ -38,7 +39,7 @@
> cpu-idle-states = <&CPU_SPC>;
> };
>
> - cpu at 1 {
> + CPU1: cpu at 1 {
> compatible = "qcom,krait";
> enable-method = "qcom,kpss-acc-v1";
> device_type = "cpu";
> @@ -49,7 +50,7 @@
> cpu-idle-states = <&CPU_SPC>;
> };
>
> - cpu at 2 {
> + CPU2: cpu at 2 {
> compatible = "qcom,krait";
> enable-method = "qcom,kpss-acc-v1";
> device_type = "cpu";
> @@ -60,7 +61,7 @@
> cpu-idle-states = <&CPU_SPC>;
> };
>
> - cpu at 3 {
> + CPU3: cpu at 3 {
> compatible = "qcom,krait";
> enable-method = "qcom,kpss-acc-v1";
> device_type = "cpu";
> @@ -1418,4 +1419,6 @@
> };
> };
> };
> +
> +#include "qcom-apq8064-coresight.dtsi"
> #include "qcom-apq8064-pins.dtsi"
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
^ permalink raw reply
* [PATCH] drm/sun4i: Only count TCON endpoints as valid outputs
From: Maxime Ripard @ 2016-11-17 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116093732.12828-1-wens@csie.org>
On Wed, Nov 16, 2016 at 05:37:31PM +0800, Chen-Yu Tsai wrote:
> The sun4i DRM driver counts the number of endpoints it found and
> registers the whole DRM pipeline if any endpoints are found.
>
> However, if the TCON and its child endpoints (LCD panels, TV encoder,
> HDMI encoder, MIPI DSI encoder, etc.) aren't found, that means we
> don't have any usable CRTCs, and the display pipeline is incomplete
> and useless.
If some node set as available is not probed, then yes, it does, but
I'm not really sure how it's a problem. Quite the opposite actually.
> The whole DRM display pipeline should only be registered and enabled
> if there are proper outputs available.
Unless I've misunderstood what you're saying, we could have the
writeback for example that would just need the display engine.
> The debug message "Queued %d outputs on pipeline %d\n" is also telling.
>
> This patch makes the driver only count enabled TCON endpoints. If
> none are found, the DRM pipeline is not used. This avoids screwing
> up the simple framebuffer provided by the bootloader in cases where
> we aren't able to support the display with the DRM subsystem, due
> to lack of panel or bridge drivers, or just lack of progress.
The framebuffer is removed only at bind time, which means that all the
drivers have probed already. Lack of progress isn't an issue here,
since the node simply won't be there, and we wouldn't have it in the
component lists. And lack of drivers shouldn't be an issue either,
since in order for bind to be called, all the drivers would have
gone through their probe.
So I'm not really sure what it fixes.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161117/9e378540/attachment.sig>
^ permalink raw reply
* [PATCH v4] arm64: dts: qcom: Add msm8916 CoreSight components
From: Mathieu Poirier @ 2016-11-17 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117153522.11630-1-georgi.djakov@linaro.org>
On Thu, Nov 17, 2016 at 05:35:22PM +0200, Georgi Djakov wrote:
> From: "Ivan T. Ivanov" <ivan.ivanov@linaro.org>
>
> Add initial set of CoreSight components found on Qualcomm's 8x16 chipset.
Hello Georgi,
Could you add a better desccription for the SoC? To me "8x16" doesn't
say much.
With that change:
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> Signed-off-by: Ivan T. Ivanov <ivan.ivanov@linaro.org>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
>
> This patch was on hold for some time, as it has a dependency on RPM clocks,
> which is now merged into clk-next.
>
> Changes since v3: (https://lkml.org/lkml/2015/5/11/134)
> * Include msm8916-coresight.dtsi into msm8916.dtsi
>
> Changes since v2: (https://lkml.org/lkml/2015/4/29/242)
> * Added "1x" to "qcom,coresight-replicator" compatible string, to match what
> devicetree bindings documentations says.
>
>
> arch/arm64/boot/dts/qcom/msm8916-coresight.dtsi | 254 ++++++++++++++++++++++++
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +
> 2 files changed, 256 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/msm8916-coresight.dtsi
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-coresight.dtsi b/arch/arm64/boot/dts/qcom/msm8916-coresight.dtsi
> new file mode 100644
> index 000000000000..900f1f484a0a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8916-coresight.dtsi
> @@ -0,0 +1,254 @@
> +/*
> + * Copyright (c) 2013 - 2015, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +&soc {
> +
> + tpiu at 820000 {
> + compatible = "arm,coresight-tpiu", "arm,primecell";
> + reg = <0x820000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + port {
> + tpiu_in: endpoint {
> + slave-mode;
> + remote-endpoint = <&replicator_out1>;
> + };
> + };
> + };
> +
> + funnel at 821000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0x821000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /*
> + * Not described input ports:
> + * 0 - connected to Resource and Power Manger CPU ETM
> + * 1 - not-connected
> + * 2 - connected to Modem CPU ETM
> + * 3 - not-connected
> + * 5 - not-connected
> + * 6 - connected trought funnel to Wireless CPU ETM
> + * 7 - connected to STM component
> + */
> + port at 4 {
> + reg = <4>;
> + funnel0_in4: endpoint {
> + slave-mode;
> + remote-endpoint = <&funnel1_out>;
> + };
> + };
> + port at 8 {
> + reg = <0>;
> + funnel0_out: endpoint {
> + remote-endpoint = <&etf_in>;
> + };
> + };
> + };
> + };
> +
> + replicator at 824000 {
> + compatible = "qcom,coresight-replicator1x", "arm,primecell";
> + reg = <0x824000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + replicator_out0: endpoint {
> + remote-endpoint = <&etr_in>;
> + };
> + };
> + port at 1 {
> + reg = <1>;
> + replicator_out1: endpoint {
> + remote-endpoint = <&tpiu_in>;
> + };
> + };
> + port at 2 {
> + reg = <0>;
> + replicator_in: endpoint {
> + slave-mode;
> + remote-endpoint = <&etf_out>;
> + };
> + };
> + };
> + };
> +
> + etf at 825000 {
> + compatible = "arm,coresight-tmc", "arm,primecell";
> + reg = <0x825000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + etf_out: endpoint {
> + slave-mode;
> + remote-endpoint = <&funnel0_out>;
> + };
> + };
> + port at 1 {
> + reg = <0>;
> + etf_in: endpoint {
> + remote-endpoint = <&replicator_in>;
> + };
> + };
> + };
> + };
> +
> + etr at 826000 {
> + compatible = "arm,coresight-tmc", "arm,primecell";
> + reg = <0x826000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + port {
> + etr_in: endpoint {
> + slave-mode;
> + remote-endpoint = <&replicator_out0>;
> + };
> + };
> + };
> +
> + funnel at 841000 { /* APSS funnel only 4 inputs are used */
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0x841000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + funnel1_in0: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm0_out>;
> + };
> + };
> + port at 1 {
> + reg = <1>;
> + funnel1_in1: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm1_out>;
> + };
> + };
> + port at 2 {
> + reg = <2>;
> + funnel1_in2: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm2_out>;
> + };
> + };
> + port at 3 {
> + reg = <3>;
> + funnel1_in3: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm3_out>;
> + };
> + };
> + port at 4 {
> + reg = <0>;
> + funnel1_out: endpoint {
> + remote-endpoint = <&funnel0_in4>;
> + };
> + };
> + };
> + };
> +
> + etm at 85c000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0x85c000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + cpu = <&CPU0>;
> +
> + port {
> + etm0_out: endpoint {
> + remote-endpoint = <&funnel1_in0>;
> + };
> + };
> + };
> +
> + etm at 85d000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0x85d000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + cpu = <&CPU1>;
> +
> + port {
> + etm1_out: endpoint {
> + remote-endpoint = <&funnel1_in1>;
> + };
> + };
> + };
> +
> + etm at 85e000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0x85e000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + cpu = <&CPU2>;
> +
> + port {
> + etm2_out: endpoint {
> + remote-endpoint = <&funnel1_in2>;
> + };
> + };
> + };
> +
> + etm at 85f000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0x85f000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + cpu = <&CPU3>;
> +
> + port {
> + etm3_out: endpoint {
> + remote-endpoint = <&funnel1_in3>;
> + };
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 4221b7d2c0ce..bfaeb9364190 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -14,6 +14,7 @@
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/clock/qcom,gcc-msm8916.h>
> #include <dt-bindings/reset/qcom,gcc-msm8916.h>
> +#include <dt-bindings/clock/qcom,rpmcc.h>
>
> / {
> model = "Qualcomm Technologies, Inc. MSM8916";
> @@ -993,4 +994,5 @@
> };
> };
>
> +#include "msm8916-coresight.dtsi"
> #include "msm8916-pins.dtsi"
^ permalink raw reply
* [PATCH 1/2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Hans de Goede @ 2016-11-17 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117183520.vpyw72mchynpqx7d@lukather>
Hi,
On 17-11-16 19:35, Maxime Ripard wrote:
> Hi Hans,
>
> On Tue, Nov 15, 2016 at 11:12:35AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 14-11-16 21:08, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Sun, Nov 13, 2016 at 08:22:02PM +0100, Hans de Goede wrote:
>>>> Just like on sun8i all sun5i tablets use the same interrupt and power
>>>> gpios for their touchscreens. I've checked all known a13 fex files and
>>>> only the UTOO P66 uses a different gpio for the interrupt.
>>>>
>>>> Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
>>>> fills in the necessary gpios to avoid duplication in the tablet dts files,
>>>> just like we do in sun8i-reference-design-tablet.dtsi.
>>>>
>>>> This will make future patches adding touchscreen nodes to a13 tablets
>>>> simpler.
>>>>
>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>> ---
>>>> arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 38 ++++++++--------------
>>>> .../boot/dts/sun5i-reference-design-tablet.dtsi | 25 ++++++++++++++
>>>> 2 files changed, 39 insertions(+), 24 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
>>>> index a8b0bcc..3d7ff10 100644
>>>> --- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
>>>> +++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
>>>> @@ -83,22 +83,6 @@
>>>> allwinner,pins = "PG3";
>>>> };
>>>>
>>>> -&i2c1 {
>>>> - icn8318: touchscreen at 40 {
>>>> - compatible = "chipone,icn8318";
>>>> - reg = <0x40>;
>>>> - interrupt-parent = <&pio>;
>>>> - interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
>>>> - pinctrl-names = "default";
>>>> - pinctrl-0 = <&ts_wake_pin_p66>;
>>>> - wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
>>>> - touchscreen-size-x = <800>;
>>>> - touchscreen-size-y = <480>;
>>>> - touchscreen-inverted-x;
>>>> - touchscreen-swapped-x-y;
>>>> - };
>>>> -};
>>>> -
>>>> &mmc2 {
>>>> pinctrl-names = "default";
>>>> pinctrl-0 = <&mmc2_pins_a>;
>>>> @@ -121,20 +105,26 @@
>>>> allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>>> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>>>> };
>>>> -
>>>> - ts_wake_pin_p66: ts_wake_pin at 0 {
>>>> - allwinner,pins = "PB3";
>>>> - allwinner,function = "gpio_out";
>>>> - allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>>> - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>>> - };
>>>> -
>>>> };
>>>>
>>>> ®_usb0_vbus {
>>>> gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
>>>> };
>>>>
>>>> +&touchscreen {
>>>> + compatible = "chipone,icn8318";
>>>> + reg = <0x40>;
>>>> + /* The P66 uses a different EINT then the reference design */
>>>> + interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
>>>> + /* The icn8318 binding expects wake-gpios instead of power-gpios */
>>>> + wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
>>>> + touchscreen-size-x = <800>;
>>>> + touchscreen-size-y = <480>;
>>>> + touchscreen-inverted-x;
>>>> + touchscreen-swapped-x-y;
>>>> + status = "okay";
>>>> +};
>>>> +
>>>> &uart1 {
>>>> /* The P66 uses the uart pins as gpios */
>>>> status = "disabled";
>>>> diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
>>>> index 20cc940..7af488a 100644
>>>> --- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
>>>> +++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
>>>> @@ -41,6 +41,7 @@
>>>> */
>>>> #include "sunxi-reference-design-tablet.dtsi"
>>>>
>>>> +#include <dt-bindings/interrupt-controller/irq.h>
>>>> #include <dt-bindings/pwm/pwm.h>
>>>>
>>>> / {
>>>> @@ -84,6 +85,23 @@
>>>> };
>>>>
>>>> &i2c1 {
>>>> + /*
>>>> + * The gsl1680 is rated at 400KHz and it will not work reliable at
>>>> + * 100KHz, this has been confirmed on multiple different q8 tablets.
>>>> + * All other devices on this bus are also rated for 400KHz.
>>>> + */
>>>> + clock-frequency = <400000>;
>>>> +
>>>> + touchscreen: touchscreen {
>>>> + interrupt-parent = <&pio>;
>>>> + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&ts_power_pin>;
>>>> + power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
>>>> + /* Tablet dts must provide reg and compatible */
>>>> + status = "disabled";
>>>> + };
>>>> +
>>>> pcf8563: rtc at 51 {
>>>> compatible = "nxp,pcf8563";
>>>> reg = <0x51>;
>>>> @@ -125,6 +143,13 @@
>>>> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>>>> };
>>>>
>>>> + ts_power_pin: ts_power_pin {
>>>> + allwinner,pins = "PB3";
>>>> + allwinner,function = "gpio_out";
>>>> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>>> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>>> + };
>>>> +
>>>
>>> For the next release, we'll switch to the generic pin mux properties
>>> ("pins" and "function"), and we actually implemented the fact that the
>>> drive and pull properties are optional, so you can drop them both.
>>>
>>> You'll need next + http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/467123.html
>>
>> Ok, before I send a v2 first a question about this, for the touchscreen
>> case I actually need:
>>
>> allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>
>> Because otherwise when the touchscreen controller is powered by a separate
>> regulator and that regulator is off, then it may draw just enough current
>> from its enable pin to be sort-of listening to the i2c bus and mess up
>> that bus.
>>
>> So is this the default, or do we get the power-on default when not
>> specifying these? If it is the power-on default then we do need to
>> specify these, because AFAICT the power-on drive strength typically
>> is 20 mA.
>
> Leaving them out will keep whatever state has been programmed. Putting
> them in the DT will force them to whatever value has been set.
Thanks for the answer, in the mean time I've send a v2 which leaves
them in using the new names (which according to your answer seems to
be the right thing to do).
Regards,
Hans
^ permalink raw reply
* [PATCH 15/20] ARM/hw_breakpoint: Convert to hotplug state machine
From: Sebastian Andrzej Siewior @ 2016-11-17 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117183541.8588-1-bigeasy@linutronix.de>
Install the callbacks via the state machine and let the core invoke
the callbacks on the already online CPUs.
smp_call_function_single() has been removed because the function is already
invoked on the target CPU.
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/arm/kernel/hw_breakpoint.c | 44 ++++++++++++++++++-----------------------
1 file changed, 19 insertions(+), 25 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index b8df45883cf7..51cff5a8feff 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -925,9 +925,9 @@ static bool core_has_os_save_restore(void)
}
}
-static void reset_ctrl_regs(void *unused)
+static void reset_ctrl_regs(unsigned int cpu)
{
- int i, raw_num_brps, err = 0, cpu = smp_processor_id();
+ int i, raw_num_brps, err = 0;
u32 val;
/*
@@ -1020,25 +1020,20 @@ static void reset_ctrl_regs(void *unused)
cpumask_or(&debug_err_mask, &debug_err_mask, cpumask_of(cpu));
}
-static int dbg_reset_notify(struct notifier_block *self,
- unsigned long action, void *cpu)
+static int dbg_reset_online(unsigned int cpu)
{
- if ((action & ~CPU_TASKS_FROZEN) == CPU_ONLINE)
- smp_call_function_single((int)cpu, reset_ctrl_regs, NULL, 1);
-
- return NOTIFY_OK;
+ local_irq_disable();
+ reset_ctrl_regs(cpu);
+ local_irq_enable();
+ return 0;
}
-static struct notifier_block dbg_reset_nb = {
- .notifier_call = dbg_reset_notify,
-};
-
#ifdef CONFIG_CPU_PM
static int dbg_cpu_pm_notify(struct notifier_block *self, unsigned long action,
void *v)
{
if (action == CPU_PM_EXIT)
- reset_ctrl_regs(NULL);
+ reset_ctrl_regs(smp_processor_id());
return NOTIFY_OK;
}
@@ -1059,6 +1054,8 @@ static inline void pm_init(void)
static int __init arch_hw_breakpoint_init(void)
{
+ int ret;
+
debug_arch = get_debug_arch();
if (!debug_arch_supported()) {
@@ -1072,8 +1069,6 @@ static int __init arch_hw_breakpoint_init(void)
core_num_brps = get_num_brps();
core_num_wrps = get_num_wrps();
- cpu_notifier_register_begin();
-
/*
* We need to tread carefully here because DBGSWENABLE may be
* driven low on this core and there isn't an architected way to
@@ -1082,15 +1077,18 @@ static int __init arch_hw_breakpoint_init(void)
register_undef_hook(&debug_reg_hook);
/*
- * Reset the breakpoint resources. We assume that a halting
- * debugger will leave the world in a nice state for us.
+ * Register CPU notifier which resets the breakpoint resources. We
+ * assume that a halting debugger will leave the world in a nice state
+ * for us.
*/
- on_each_cpu(reset_ctrl_regs, NULL, 1);
+ ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "arm/hw_breakpoint:online",
+ dbg_reset_online, NULL);
unregister_undef_hook(&debug_reg_hook);
- if (!cpumask_empty(&debug_err_mask)) {
+ if (WARN_ON(ret < 0) || !cpumask_empty(&debug_err_mask)) {
core_num_brps = 0;
core_num_wrps = 0;
- cpu_notifier_register_done();
+ if (ret > 0)
+ cpuhp_remove_state_nocalls(ret);
return 0;
}
@@ -1109,11 +1107,7 @@ static int __init arch_hw_breakpoint_init(void)
hook_ifault_code(FAULT_CODE_DEBUG, hw_breakpoint_pending, SIGTRAP,
TRAP_HWBKPT, "breakpoint debug exception");
- /* Register hotplug and PM notifiers. */
- __register_cpu_notifier(&dbg_reset_nb);
-
- cpu_notifier_register_done();
-
+ /* Register PM notifiers. */
pm_init();
return 0;
}
--
2.10.2
^ permalink raw reply related
* [PATCH 14/20] arm/bL_switcher: Convert to hotplug state machine
From: Sebastian Andrzej Siewior @ 2016-11-17 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117183541.8588-1-bigeasy@linutronix.de>
Install the callbacks via the state machine.
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
arch/arm/common/bL_switcher.c | 34 ++++++++++++++++++++--------------
include/linux/cpuhotplug.h | 1 +
2 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
index 37dc0fe1093f..46730017b3c5 100644
--- a/arch/arm/common/bL_switcher.c
+++ b/arch/arm/common/bL_switcher.c
@@ -757,19 +757,18 @@ EXPORT_SYMBOL_GPL(bL_switcher_put_enabled);
* while the switcher is active.
* We're just not ready to deal with that given the trickery involved.
*/
-static int bL_switcher_hotplug_callback(struct notifier_block *nfb,
- unsigned long action, void *hcpu)
+static int bL_switcher_cpu_pre(unsigned int cpu)
{
- if (bL_switcher_active) {
- int pairing = bL_switcher_cpu_pairing[(unsigned long)hcpu];
- switch (action & 0xf) {
- case CPU_UP_PREPARE:
- case CPU_DOWN_PREPARE:
- if (pairing == -1)
- return NOTIFY_BAD;
- }
- }
- return NOTIFY_DONE;
+ int pairing;
+
+ if (!bL_switcher_active)
+ return 0;
+
+ pairing = bL_switcher_cpu_pairing[cpu];
+
+ if (pairing == -1)
+ return -EINVAL;
+ return 0;
}
static bool no_bL_switcher;
@@ -782,8 +781,15 @@ static int __init bL_switcher_init(void)
if (!mcpm_is_available())
return -ENODEV;
- cpu_notifier(bL_switcher_hotplug_callback, 0);
-
+ cpuhp_setup_state_nocalls(CPUHP_ARM_BL_PREPARE, "arm/bl:prepare",
+ bL_switcher_cpu_pre, NULL);
+ ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "arm/bl:predown",
+ NULL, bL_switcher_cpu_pre);
+ if (ret < 0) {
+ cpuhp_remove_state_nocalls(CPUHP_ARM_BL_PREPARE);
+ pr_err("bL_switcher: Failed to allocate a hotplug state\n");
+ return ret;
+ }
if (!no_bL_switcher) {
ret = bL_switcher_enable();
if (ret)
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 69abf2c09f6c..4b99b79c16e5 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -64,6 +64,7 @@ enum cpuhp_state {
CPUHP_X86_CPUID_PREPARE,
CPUHP_X86_MSR_PREPARE,
CPUHP_NET_IUCV_PREPARE,
+ CPUHP_ARM_BL_PREPARE,
CPUHP_TIMERS_DEAD,
CPUHP_NOTF_ERR_INJ_PREPARE,
CPUHP_MIPS_SOC_PREPARE,
--
2.10.2
^ permalink raw reply related
* [PATCH 07/20] pci/xgene-msi: Convert to hotplug state machine
From: Sebastian Andrzej Siewior @ 2016-11-17 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117183541.8588-1-bigeasy@linutronix.de>
Install the callbacks via the state machine and let the core invoke
the callbacks on the already online CPUs.
Cc: Duc Dang <dhdang@apm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/pci/host/pci-xgene-msi.c | 69 +++++++++++-----------------------------
include/linux/cpuhotplug.h | 1 +
2 files changed, 20 insertions(+), 50 deletions(-)
diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
index a6456b578269..1f38d0836751 100644
--- a/drivers/pci/host/pci-xgene-msi.c
+++ b/drivers/pci/host/pci-xgene-msi.c
@@ -360,16 +360,16 @@ static void xgene_msi_isr(struct irq_desc *desc)
chained_irq_exit(chip, desc);
}
+static enum cpuhp_state pci_xgene_online;
+
static int xgene_msi_remove(struct platform_device *pdev)
{
- int virq, i;
struct xgene_msi *msi = platform_get_drvdata(pdev);
- for (i = 0; i < NR_HW_IRQS; i++) {
- virq = msi->msi_groups[i].gic_irq;
- if (virq != 0)
- irq_set_chained_handler_and_data(virq, NULL, NULL);
- }
+ if (pci_xgene_online)
+ cpuhp_remove_state(pci_xgene_online);
+ cpuhp_remove_state(CPUHP_PCI_XGENE_DEAD);
+
kfree(msi->msi_groups);
kfree(msi->bitmap);
@@ -427,7 +427,7 @@ static int xgene_msi_hwirq_alloc(unsigned int cpu)
return 0;
}
-static void xgene_msi_hwirq_free(unsigned int cpu)
+static int xgene_msi_hwirq_free(unsigned int cpu)
{
struct xgene_msi *msi = &xgene_msi_ctrl;
struct xgene_msi_group *msi_group;
@@ -441,33 +441,9 @@ static void xgene_msi_hwirq_free(unsigned int cpu)
irq_set_chained_handler_and_data(msi_group->gic_irq, NULL,
NULL);
}
+ return 0;
}
-static int xgene_msi_cpu_callback(struct notifier_block *nfb,
- unsigned long action, void *hcpu)
-{
- unsigned cpu = (unsigned long)hcpu;
-
- switch (action) {
- case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
- xgene_msi_hwirq_alloc(cpu);
- break;
- case CPU_DEAD:
- case CPU_DEAD_FROZEN:
- xgene_msi_hwirq_free(cpu);
- break;
- default:
- break;
- }
-
- return NOTIFY_OK;
-}
-
-static struct notifier_block xgene_msi_cpu_notifier = {
- .notifier_call = xgene_msi_cpu_callback,
-};
-
static const struct of_device_id xgene_msi_match_table[] = {
{.compatible = "apm,xgene1-msi"},
{},
@@ -478,7 +454,6 @@ static int xgene_msi_probe(struct platform_device *pdev)
struct resource *res;
int rc, irq_index;
struct xgene_msi *xgene_msi;
- unsigned int cpu;
int virt_msir;
u32 msi_val, msi_idx;
@@ -540,28 +515,22 @@ static int xgene_msi_probe(struct platform_device *pdev)
}
}
- cpu_notifier_register_begin();
-
- for_each_online_cpu(cpu)
- if (xgene_msi_hwirq_alloc(cpu)) {
- dev_err(&pdev->dev, "failed to register MSI handlers\n");
- cpu_notifier_register_done();
- goto error;
- }
-
- rc = __register_hotcpu_notifier(&xgene_msi_cpu_notifier);
- if (rc) {
- dev_err(&pdev->dev, "failed to add CPU MSI notifier\n");
- cpu_notifier_register_done();
- goto error;
- }
-
- cpu_notifier_register_done();
+ rc = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "pci/xgene:online",
+ xgene_msi_hwirq_alloc, NULL);
+ if (rc)
+ goto err_cpuhp;
+ pci_xgene_online = rc;
+ rc = cpuhp_setup_state(CPUHP_PCI_XGENE_DEAD, "pci/xgene:dead", NULL,
+ xgene_msi_hwirq_free);
+ if (rc)
+ goto err_cpuhp;
dev_info(&pdev->dev, "APM X-Gene PCIe MSI driver loaded\n");
return 0;
+err_cpuhp:
+ dev_err(&pdev->dev, "failed to add CPU MSI notifier\n");
error:
xgene_msi_remove(pdev);
return rc;
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 6506dce8343a..fd5598b8353a 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -38,6 +38,7 @@ enum cpuhp_state {
CPUHP_RADIX_DEAD,
CPUHP_PAGE_ALLOC_DEAD,
CPUHP_NET_DEV_DEAD,
+ CPUHP_PCI_XGENE_DEAD,
CPUHP_WORKQUEUE_PREP,
CPUHP_POWER_NUMA_PREPARE,
CPUHP_HRTIMERS_PREPARE,
--
2.10.2
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Maxime Ripard @ 2016-11-17 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0c3a9e9c-d310-c6c3-ae10-1ae9e520963e@redhat.com>
Hi Hans,
On Tue, Nov 15, 2016 at 11:12:35AM +0100, Hans de Goede wrote:
> Hi,
>
> On 14-11-16 21:08, Maxime Ripard wrote:
> > Hi,
> >
> > On Sun, Nov 13, 2016 at 08:22:02PM +0100, Hans de Goede wrote:
> > > Just like on sun8i all sun5i tablets use the same interrupt and power
> > > gpios for their touchscreens. I've checked all known a13 fex files and
> > > only the UTOO P66 uses a different gpio for the interrupt.
> > >
> > > Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
> > > fills in the necessary gpios to avoid duplication in the tablet dts files,
> > > just like we do in sun8i-reference-design-tablet.dtsi.
> > >
> > > This will make future patches adding touchscreen nodes to a13 tablets
> > > simpler.
> > >
> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > > ---
> > > arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 38 ++++++++--------------
> > > .../boot/dts/sun5i-reference-design-tablet.dtsi | 25 ++++++++++++++
> > > 2 files changed, 39 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> > > index a8b0bcc..3d7ff10 100644
> > > --- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> > > +++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> > > @@ -83,22 +83,6 @@
> > > allwinner,pins = "PG3";
> > > };
> > >
> > > -&i2c1 {
> > > - icn8318: touchscreen at 40 {
> > > - compatible = "chipone,icn8318";
> > > - reg = <0x40>;
> > > - interrupt-parent = <&pio>;
> > > - interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> > > - pinctrl-names = "default";
> > > - pinctrl-0 = <&ts_wake_pin_p66>;
> > > - wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> > > - touchscreen-size-x = <800>;
> > > - touchscreen-size-y = <480>;
> > > - touchscreen-inverted-x;
> > > - touchscreen-swapped-x-y;
> > > - };
> > > -};
> > > -
> > > &mmc2 {
> > > pinctrl-names = "default";
> > > pinctrl-0 = <&mmc2_pins_a>;
> > > @@ -121,20 +105,26 @@
> > > allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> > > allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> > > };
> > > -
> > > - ts_wake_pin_p66: ts_wake_pin at 0 {
> > > - allwinner,pins = "PB3";
> > > - allwinner,function = "gpio_out";
> > > - allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> > > - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> > > - };
> > > -
> > > };
> > >
> > > ®_usb0_vbus {
> > > gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
> > > };
> > >
> > > +&touchscreen {
> > > + compatible = "chipone,icn8318";
> > > + reg = <0x40>;
> > > + /* The P66 uses a different EINT then the reference design */
> > > + interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> > > + /* The icn8318 binding expects wake-gpios instead of power-gpios */
> > > + wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> > > + touchscreen-size-x = <800>;
> > > + touchscreen-size-y = <480>;
> > > + touchscreen-inverted-x;
> > > + touchscreen-swapped-x-y;
> > > + status = "okay";
> > > +};
> > > +
> > > &uart1 {
> > > /* The P66 uses the uart pins as gpios */
> > > status = "disabled";
> > > diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> > > index 20cc940..7af488a 100644
> > > --- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> > > +++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> > > @@ -41,6 +41,7 @@
> > > */
> > > #include "sunxi-reference-design-tablet.dtsi"
> > >
> > > +#include <dt-bindings/interrupt-controller/irq.h>
> > > #include <dt-bindings/pwm/pwm.h>
> > >
> > > / {
> > > @@ -84,6 +85,23 @@
> > > };
> > >
> > > &i2c1 {
> > > + /*
> > > + * The gsl1680 is rated at 400KHz and it will not work reliable at
> > > + * 100KHz, this has been confirmed on multiple different q8 tablets.
> > > + * All other devices on this bus are also rated for 400KHz.
> > > + */
> > > + clock-frequency = <400000>;
> > > +
> > > + touchscreen: touchscreen {
> > > + interrupt-parent = <&pio>;
> > > + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&ts_power_pin>;
> > > + power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> > > + /* Tablet dts must provide reg and compatible */
> > > + status = "disabled";
> > > + };
> > > +
> > > pcf8563: rtc at 51 {
> > > compatible = "nxp,pcf8563";
> > > reg = <0x51>;
> > > @@ -125,6 +143,13 @@
> > > allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> > > };
> > >
> > > + ts_power_pin: ts_power_pin {
> > > + allwinner,pins = "PB3";
> > > + allwinner,function = "gpio_out";
> > > + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> > > + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> > > + };
> > > +
> >
> > For the next release, we'll switch to the generic pin mux properties
> > ("pins" and "function"), and we actually implemented the fact that the
> > drive and pull properties are optional, so you can drop them both.
> >
> > You'll need next + http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/467123.html
>
> Ok, before I send a v2 first a question about this, for the touchscreen
> case I actually need:
>
> allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>
> Because otherwise when the touchscreen controller is powered by a separate
> regulator and that regulator is off, then it may draw just enough current
> from its enable pin to be sort-of listening to the i2c bus and mess up
> that bus.
>
> So is this the default, or do we get the power-on default when not
> specifying these? If it is the power-on default then we do need to
> specify these, because AFAICT the power-on drive strength typically
> is 20 mA.
Leaving them out will keep whatever state has been programmed. Putting
them in the DT will force them to whatever value has been set.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161117/a4f82915/attachment.sig>
^ permalink raw reply
* [PATCH fpga 4/9] fpga zynq: Check for errors after completing DMA
From: Jason Gunthorpe @ 2016-11-17 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAtXAHeGJjQ22d=OP6cEt8Ssg1bhAEVQ5_GWFFd26xp-j8EUFg@mail.gmail.com>
On Wed, Nov 16, 2016 at 10:10:35PM -0800, Moritz Fischer wrote:
> > /* FPGA programmed */
> > #define IXR_PCFG_DONE_MASK BIT(2)
> > -#define IXR_ERROR_FLAGS_MASK 0x00F0F860
> > +#define IXR_ERROR_FLAGS_MASK 0x00F0C860
>
> True. Ouch.
Yeah, this only works at all by accident..
> > -static void zynq_fpga_mask_irqs(struct zynq_fpga_priv *priv)
> > +static inline void zynq_fpga_set_irq_mask(struct zynq_fpga_priv *priv,
> > + u32 enable)
> > {
> > - u32 intr_mask;
> > -
> > - intr_mask = zynq_fpga_read(priv, INT_MASK_OFFSET);
> > - zynq_fpga_write(priv, INT_MASK_OFFSET,
> > - intr_mask | IXR_DMA_DONE_MASK | IXR_ERROR_FLAGS_MASK);
> > -}
> > + zynq_fpga_write(priv, INT_MASK_OFFSET, ~enable);
>
> Not a fan of this ~enable here. Function name indicates you're doing
> the opposite
Lets call it zynq_fpga_set_irq then
The ~ is best placed here because it is after the compiler has coerced
the argument into u32 so the ~ will always do the right
thing
I've been reading the IXR_*_MASK as indicating it is a bit pattern for
the INT_MASK register not as actually meaning literal masking.
> > +out_clk:
> > clk_disable(priv->clk);
> > -
>
> Personally found it more readable with newline.
sure
Jason
^ permalink raw reply
* System/uncore PMUs and unit aggregation
From: Will Deacon @ 2016-11-17 18:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
We currently have support for three arm64 system PMUs in flight:
[Cavium ThunderX] http://lkml.kernel.org/r/cover.1477741719.git.jglauber at cavium.com
[Hisilicon Hip0x] http://lkml.kernel.org/r/1478151727-20250-1-git-send-email-anurup.m at huawei.com
[Qualcomm L2] http://lkml.kernel.org/r/1477687813-11412-1-git-send-email-nleeder at codeaurora.org
Each of which have to deal with multiple underlying hardware units in one
way or another. Mark and I recently expressed a desire to expose these
units to userspace as individual PMU instances, since this can allow:
* Fine-grained control of events from userspace, when you want to see
individual numbers as opposed to a summed total
* Potentially ease migration to new SoC revisions, where the units
are laid out slightly differently
* Easier handling of cases where the units aren't quite identical
however, this received pushback from all of the patch authors, so there's
clearly a problem with this approach. I'm hoping we can try to resolve
this here.
Speaking to Mark earlier today, we came up with the following rough rules
for drivers that present multiple hardware units as a single PMU:
1. If the units share some part of the programming interface (e.g. control
registers or interrupts), then they must be handled by the same PMU.
Otherwise, they should be treated independently as separate PMU
instances.
2. If the units are handled by the same PMU, then care must be taken to
handle event groups correctly. That is, if the units cannot be started
and stopped atomically, cross-unit groups must be rejected by the
driver. Furthermore, any cross-unit scheduling constraints must be
honoured so that all the units targetted by a group can schedule the
group concurrently.
3. Summing the counters across units is only permitted if the units
can all be started and stopped atomically. Otherwise, the counters
should be exposed individually. It's up to the driver author to
decide what makes sense to sum.
4. Unit topology can optionally be described in sysfs (we should pick
some standard directory naming here), and then events targetting
specific units can have the unit identifier extracted from the topology
encoded in some configN fields.
The million dollar question is: how does that fit in with the drivers I
mentioned at the top? Is this overly restrictive, or have we missed stuff?
We certainly want to allow flexibility in the way in which the drivers
talk to the hardware, but given that these decisions directly affect the
user ABI, some consistent ground rules are required.
For Cavium ThunderX, it's not clear whether or not the individual units
could be expressed as separate PMUs, or whether they're caught by one of
the rules above. The Qualcomm L2 looks like it's doing the right thing
and we can't quite work out what the Hisilicon Hip0x topology looks like,
since the interaction with djtag is confusing.
If the driver authors (on To:) could shed some light on this, then that
would be much appreciated!
Thanks,
Will
^ permalink raw reply
* [PATCH v4 1/5] arm64: perf: Basic uncore counter support for Cavium ThunderX SOC
From: Will Deacon @ 2016-11-17 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111103029.GD16907@hardcore>
On Fri, Nov 11, 2016 at 11:30:29AM +0100, Jan Glauber wrote:
> On Tue, Nov 08, 2016 at 11:50:10PM +0000, Will Deacon wrote:
> > On Sat, Oct 29, 2016 at 01:55:29PM +0200, Jan Glauber wrote:
> > > +/* node attribute depending on number of NUMA nodes */
> > > +static ssize_t node_show(struct device *dev, struct device_attribute *attr,
> > > + char *page)
> > > +{
> > > + if (NODES_SHIFT)
> > > + return sprintf(page, "config:16-%d\n", 16 + NODES_SHIFT - 1);
> >
> > If NODES_SHIFT is 1, you'll end up with "config:16-16", which might confuse
> > userspace.
>
> So should I use "config:16" in that case? Is it OK to use this also for
> NODES_SHIFT=0 ?
If you only need one bit, then "config:16" is the right thing to do.
Will
^ permalink raw reply
* [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
From: James Morse @ 2016-11-17 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117111917.GA22855@arm.com>
Hi Will, Akashi,
On 17/11/16 11:19, Will Deacon wrote:
> It looks much better, thanks! Just one question below.
>
> On Thu, Nov 17, 2016 at 02:34:24PM +0900, AKASHI Takahiro wrote:
>> diff --git a/mm/memblock.c b/mm/memblock.c
>> index 7608bc3..fea1688 100644
>> --- a/mm/memblock.c
>> +++ b/mm/memblock.c
>> @@ -1514,11 +1514,37 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
>> (phys_addr_t)ULLONG_MAX);
>> }
>>
>> +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
>> +{
>> + int start_rgn, end_rgn;
>> + int i, ret;
>> +
>> + if (!size)
>> + return;
>> +
>> + ret = memblock_isolate_range(&memblock.memory, base, size,
>> + &start_rgn, &end_rgn);
>> + if (ret)
>> + return;
>> +
>> + /* remove all the MAP regions */
>> + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
>> + if (!memblock_is_nomap(&memblock.memory.regions[i]))
>> + memblock_remove_region(&memblock.memory, i);
>
> In the case that we have only one, giant memblock that covers base all
> of base + size, can't we end up with start_rgn = end_rgn = 0? In which
Can this happen? If we only have one memblock that exactly spans
base:(base+size), memblock_isolate_range() will hit the '@rgn is fully
contained, record it' code and set start_rgn=0,end_rgn=1. (rbase==base,
rend==end). We only go round the loop once.
If we only have one memblock that is bigger than base:(base+size) we end up with
three regions, start_rgn=1,end_rgn=2. The trickery here is the '@rgn intersects
from above' code decreases the loop counter so we process the same entry twice,
hitting '@rgn is fully contained, record it' the second time round... so we go
round the loop four times.
I can't see how we hit the:
> if (rbase >= end)
> break;
> if (rend <= base)
> continue;
code in either case...
Thanks,
James
> case, we'd end up accidentally removing the map regions here.
>
> The existing code:
>
>> - /* remove all the MAP regions above the limit */
>> - for (i = end_rgn - 1; i >= start_rgn; i--) {
>> - if (!memblock_is_nomap(&type->regions[i]))
>> - memblock_remove_region(type, i);
>> - }
>
> seems to handle this.
^ permalink raw reply
* [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Anand Moon @ 2016-11-17 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479378055.17538.57.camel@baylibre.com>
Hi Jerone,
On 17 November 2016 at 15:50, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Wed, 2016-11-16 at 22:36 +0530, Anand Moon wrote:
>> Hi Jerome.
>>
>> On 15 November 2016 at 19:59, Jerome Brunet <jbrunet@baylibre.com>
>> wrote:
>> >
>> > On some platforms, energy efficient ethernet with rtl8211 devices
>> > is
>> > causing issue, like throughput drop or broken link.
>> >
>> > This was reported on the OdroidC2 (DWMAC + RTL8211F). While the
>> > issue root
>> > cause is not fully understood yet, disabling EEE advertisement
>> > prevent auto
>> > negotiation from enabling EEE.
>> >
>> > This patch provides options to disable 1000T and 100TX EEE
>> > advertisement
>> > individually for the realtek phys supporting this feature.
>> >
>> > Reported-by: Martin Blumenstingl <martin.blumenstingl@googlemail.co
>> > m>
>> > Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>> > Cc: Alexandre TORGUE <alexandre.torgue@st.com>
>> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
>> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> > Tested-by: Andre Roth <neolynx@gmail.com>
>> > ---
>> > drivers/net/phy/realtek.c | 65
>> > ++++++++++++++++++++++++++++++++++++++++++++++-
>> > 1 file changed, 64 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
>> > index aadd6e9f54ad..77235fd5faaf 100644
>> > --- a/drivers/net/phy/realtek.c
>> > +++ b/drivers/net/phy/realtek.c
>> > @@ -15,6 +15,12 @@
>> > */
>> > #include <linux/phy.h>
>> > #include <linux/module.h>
>> > +#include <linux/of.h>
>> > +
>> > +struct rtl8211x_phy_priv {
>> > + bool eee_1000t_disable;
>> > + bool eee_100tx_disable;
>> > +};
>> >
>> > #define RTL821x_PHYSR 0x11
>> > #define RTL821x_PHYSR_DUPLEX 0x2000
>> > @@ -93,12 +99,44 @@ static int rtl8211f_config_intr(struct
>> > phy_device *phydev)
>> > return err;
>> > }
>> >
>> > +static void rtl8211x_clear_eee_adv(struct phy_device *phydev)
>> > +{
>> > + struct rtl8211x_phy_priv *priv = phydev->priv;
>> > + u16 val;
>> > +
>> > + if (priv->eee_1000t_disable || priv->eee_100tx_disable) {
>> > + val = phy_read_mmd_indirect(phydev,
>> > MDIO_AN_EEE_ADV,
>> > + MDIO_MMD_AN);
>> > +
>> > + if (priv->eee_1000t_disable)
>> > + val &= ~MDIO_AN_EEE_ADV_1000T;
>> > + if (priv->eee_100tx_disable)
>> > + val &= ~MDIO_AN_EEE_ADV_100TX;
>> > +
>> > + phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV,
>> > + MDIO_MMD_AN, val);
>> > + }
>> > +}
>> > +
>> > +static int rtl8211x_config_init(struct phy_device *phydev)
>> > +{
>> > + int ret;
>> > +
>> > + ret = genphy_config_init(phydev);
>> > + if (ret < 0)
>> > + return ret;
>> > +
>> > + rtl8211x_clear_eee_adv(phydev);
>> > +
>> > + return 0;
>> > +}
>> > +
>> > static int rtl8211f_config_init(struct phy_device *phydev)
>> > {
>> > int ret;
>> > u16 reg;
>> >
>> > - ret = genphy_config_init(phydev);
>> > + ret = rtl8211x_config_init(phydev);
>> > if (ret < 0)
>> > return ret;
>> >
>> > @@ -115,6 +153,26 @@ static int rtl8211f_config_init(struct
>> > phy_device *phydev)
>> > return 0;
>> > }
>> >
>> > +static int rtl8211x_phy_probe(struct phy_device *phydev)
>> > +{
>> > + struct device *dev = &phydev->mdio.dev;
>> > + struct device_node *of_node = dev->of_node;
>> > + struct rtl8211x_phy_priv *priv;
>> > +
>> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>> > + if (!priv)
>> > + return -ENOMEM;
>> > +
>> > + priv->eee_1000t_disable =
>> > + of_property_read_bool(of_node, "realtek,disable-
>> > eee-1000t");
>> > + priv->eee_100tx_disable =
>> > + of_property_read_bool(of_node, "realtek,disable-
>> > eee-100tx");
>> > +
>> > + phydev->priv = priv;
>> > +
>> > + return 0;
>> > +}
>> > +
>> > static struct phy_driver realtek_drvs[] = {
>> > {
>> > .phy_id = 0x00008201,
>> > @@ -140,7 +198,9 @@ static struct phy_driver realtek_drvs[] = {
>> > .phy_id_mask = 0x001fffff,
>> > .features = PHY_GBIT_FEATURES,
>> > .flags = PHY_HAS_INTERRUPT,
>> > + .probe = &rtl8211x_phy_probe,
>> > .config_aneg = genphy_config_aneg,
>> > + .config_init = &rtl8211x_config_init,
>> > .read_status = genphy_read_status,
>> > .ack_interrupt = rtl821x_ack_interrupt,
>> > .config_intr = rtl8211e_config_intr,
>> > @@ -152,7 +212,9 @@ static struct phy_driver realtek_drvs[] = {
>> > .phy_id_mask = 0x001fffff,
>> > .features = PHY_GBIT_FEATURES,
>> > .flags = PHY_HAS_INTERRUPT,
>> > + .probe = &rtl8211x_phy_probe,
>> > .config_aneg = &genphy_config_aneg,
>> > + .config_init = &rtl8211x_config_init,
>> > .read_status = &genphy_read_status,
>> > .ack_interrupt = &rtl821x_ack_interrupt,
>> > .config_intr = &rtl8211e_config_intr,
>> > @@ -164,6 +226,7 @@ static struct phy_driver realtek_drvs[] = {
>> > .phy_id_mask = 0x001fffff,
>> > .features = PHY_GBIT_FEATURES,
>> > .flags = PHY_HAS_INTERRUPT,
>> > + .probe = &rtl8211x_phy_probe,
>> > .config_aneg = &genphy_config_aneg,
>> > .config_init = &rtl8211f_config_init,
>> > .read_status = &genphy_read_status,
>> > --
>> > 2.7.4
>> >
>>
>> How about adding callback functionality for .soft_reset to handle
>> BMCR
>> where we update the Auto-Negotiation for the phy,
>> as per the datasheet of the rtl8211f.
>
> I'm not sure I understand how this would help with our issue (and EEE).
> Am I missing something or is it something unrelated that you would like
> to see happening on this driver ?
>
[snip]
I was just tying other phy module to understand the feature.
But in order to improve the throughput I tried to integrate blow u-boot commit.
commit 3d6af748ebd831524cb22a29433e9092af469ec7
Author: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Date: Thu Mar 12 18:54:59 2015 +0800
net/phy: Add support for realtek RTL8211F
RTL8211F has different registers from RTL8211E.
This patch adds support for RTL8211F PHY which
can be found on Freescale's T1023 RDB board.
And added the similar functionality to .config_aneg = &rtl8211f_config_aneg,
And I seem to have better results in through put with periodic drop
but it recovers.
-----
odroid at odroid64:~$ iperf3 -c 10.0.0.102 -p 2006 -i 1 -t 100 -V
iperf 3.0.11
Linux odroid64 4.9.0-rc5-xc2ml #18 SMP PREEMPT Thu Nov 17 22:56:00 IST
2016 aarch64 aarch64 aarch64 GNU/Linux
Time: Thu, 17 Nov 2016 17:35:25 GMT
Connecting to host 10.0.0.102, port 2006
Cookie: odroid64.1479404125.404729.3b45146e7
TCP MSS: 1448 (default)
[ 4] local 10.0.0.105 port 40238 connected to 10.0.0.102 port 2006
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting
0 seconds, 100 second test
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 114 MBytes 952 Mbits/sec 0 368 KBytes
[ 4] 1.00-2.00 sec 112 MBytes 937 Mbits/sec 0 368 KBytes
[ 4] 2.00-3.00 sec 111 MBytes 935 Mbits/sec 0 368 KBytes
[ 4] 3.00-4.00 sec 112 MBytes 936 Mbits/sec 0 368 KBytes
[ 4] 4.00-5.00 sec 112 MBytes 939 Mbits/sec 0 368 KBytes
[ 4] 5.00-6.00 sec 112 MBytes 936 Mbits/sec 0 368 KBytes
[ 4] 6.00-7.00 sec 111 MBytes 933 Mbits/sec 0 368 KBytes
[ 4] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 0 368 KBytes
[ 4] 8.00-9.00 sec 111 MBytes 935 Mbits/sec 0 368 KBytes
[ 4] 9.00-10.00 sec 111 MBytes 932 Mbits/sec 0 368 KBytes
[ 4] 10.00-11.00 sec 112 MBytes 937 Mbits/sec 0 368 KBytes
[ 4] 11.00-12.00 sec 111 MBytes 935 Mbits/sec 0 368 KBytes
[ 4] 12.00-13.00 sec 112 MBytes 938 Mbits/sec 0 368 KBytes
[ 4] 13.00-14.00 sec 112 MBytes 940 Mbits/sec 0 368 KBytes
[ 4] 14.00-15.00 sec 111 MBytes 934 Mbits/sec 0 368 KBytes
[ 4] 15.00-16.00 sec 111 MBytes 935 Mbits/sec 0 368 KBytes
[ 4] 16.00-17.00 sec 112 MBytes 939 Mbits/sec 0 368 KBytes
[ 4] 17.00-18.00 sec 112 MBytes 936 Mbits/sec 0 368 KBytes
[ 4] 18.00-19.00 sec 111 MBytes 934 Mbits/sec 0 368 KBytes
[ 4] 19.00-20.00 sec 112 MBytes 940 Mbits/sec 0 368 KBytes
[ 4] 20.00-21.00 sec 111 MBytes 933 Mbits/sec 0 368 KBytes
[ 4] 21.00-22.00 sec 112 MBytes 941 Mbits/sec 0 368 KBytes
[ 4] 22.00-23.00 sec 111 MBytes 931 Mbits/sec 0 368 KBytes
[ 4] 23.00-24.00 sec 112 MBytes 938 Mbits/sec 0 368 KBytes
[ 4] 24.00-25.00 sec 112 MBytes 938 Mbits/sec 0 368 KBytes
[ 4] 25.00-26.00 sec 111 MBytes 934 Mbits/sec 0 368 KBytes
[ 4] 26.00-27.00 sec 112 MBytes 940 Mbits/sec 0 368 KBytes
[ 4] 27.00-28.00 sec 112 MBytes 936 Mbits/sec 0 368 KBytes
[ 4] 28.00-29.00 sec 111 MBytes 934 Mbits/sec 0 368 KBytes
[ 4] 29.00-30.00 sec 112 MBytes 937 Mbits/sec 0 368 KBytes
[ 4] 30.00-31.00 sec 111 MBytes 934 Mbits/sec 0 368 KBytes
[ 4] 31.00-32.00 sec 112 MBytes 942 Mbits/sec 0 368 KBytes
[ 4] 32.00-33.00 sec 111 MBytes 933 Mbits/sec 0 368 KBytes
[ 4] 33.00-34.00 sec 111 MBytes 935 Mbits/sec 0 368 KBytes
[ 4] 34.00-35.00 sec 112 MBytes 941 Mbits/sec 0 368 KBytes
[ 4] 35.00-36.00 sec 107 MBytes 896 Mbits/sec 0 368 KBytes
[ 4] 36.00-37.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes
[ 4] 37.00-38.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 4] 38.00-39.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 39.00-40.00 sec 38.0 MBytes 319 Mbits/sec 1 385 KBytes
[ 4] 40.00-41.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 41.00-42.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 42.00-43.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 43.00-44.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 44.00-45.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 45.00-46.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 46.00-47.00 sec 111 MBytes 931 Mbits/sec 0 385 KBytes
[ 4] 47.00-48.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 48.00-49.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 49.00-50.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 50.00-51.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 51.00-52.00 sec 111 MBytes 934 Mbits/sec 0 385 KBytes
[ 4] 52.00-53.00 sec 112 MBytes 941 Mbits/sec 0 385 KBytes
[ 4] 53.00-54.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 54.00-55.00 sec 111 MBytes 930 Mbits/sec 0 385 KBytes
[ 4] 55.00-56.00 sec 112 MBytes 941 Mbits/sec 0 385 KBytes
[ 4] 56.00-57.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 57.00-58.00 sec 111 MBytes 933 Mbits/sec 0 385 KBytes
[ 4] 58.00-59.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 59.00-60.00 sec 112 MBytes 940 Mbits/sec 0 385 KBytes
[ 4] 60.00-61.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 61.00-62.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 62.00-63.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 63.00-64.00 sec 112 MBytes 938 Mbits/sec 0 385 KBytes
[ 4] 64.00-65.00 sec 111 MBytes 932 Mbits/sec 0 385 KBytes
[ 4] 65.00-66.00 sec 112 MBytes 940 Mbits/sec 0 385 KBytes
[ 4] 66.00-67.00 sec 112 MBytes 938 Mbits/sec 0 385 KBytes
[ 4] 67.00-68.00 sec 111 MBytes 934 Mbits/sec 0 385 KBytes
[ 4] 68.00-69.00 sec 111 MBytes 933 Mbits/sec 0 385 KBytes
[ 4] 69.00-70.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 70.00-71.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 71.00-72.00 sec 112 MBytes 941 Mbits/sec 0 385 KBytes
[ 4] 72.00-73.00 sec 111 MBytes 933 Mbits/sec 0 385 KBytes
[ 4] 73.00-74.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 74.00-75.00 sec 111 MBytes 934 Mbits/sec 0 385 KBytes
[ 4] 75.00-76.00 sec 111 MBytes 934 Mbits/sec 0 385 KBytes
[ 4] 76.00-77.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 77.00-78.00 sec 112 MBytes 938 Mbits/sec 0 385 KBytes
[ 4] 78.00-79.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 79.00-80.00 sec 111 MBytes 934 Mbits/sec 0 385 KBytes
[ 4] 80.00-81.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 81.00-82.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 82.00-83.00 sec 111 MBytes 934 Mbits/sec 0 385 KBytes
[ 4] 83.00-84.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 84.00-85.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 85.00-86.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 86.00-87.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 87.00-88.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 88.00-89.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 89.00-90.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 90.00-91.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 91.00-92.00 sec 111 MBytes 934 Mbits/sec 0 385 KBytes
[ 4] 92.00-93.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 93.00-94.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 94.00-95.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 95.00-96.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 96.00-97.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 97.00-98.00 sec 113 MBytes 945 Mbits/sec 0 559 KBytes
[ 4] 98.00-99.00 sec 112 MBytes 937 Mbits/sec 0 559 KBytes
[ 4] 99.00-100.00 sec 111 MBytes 928 Mbits/sec 0 559 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-100.00 sec 10.5 GBytes 902 Mbits/sec 4 sender
[ 4] 0.00-100.00 sec 10.5 GBytes 902 Mbits/sec receiver
CPU Utilization: local/sender 5.6% (0.2%u/5.4%s), remote/receiver
17.1% (1.2%u/15.9%s)
Can your confirm this at your end.
Once confirm I will try to send this as a fix for this issue.
-Best Regards
Anand Moon
^ permalink raw reply
* [PATCH fpga 5/9] fpga zynq: Remove priv->dev
From: Moritz Fischer @ 2016-11-17 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1611140913280.3739@atull-VirtualBox>
Hi Jason,
On Mon, Nov 14, 2016 at 09:13:49AM -0600, atull wrote:
> On Wed, 9 Nov 2016, Jason Gunthorpe wrote:
>
> Hi Jason,
>
> Acked-by: Alan Tull <atull@opensource.altera.com>
>
> Alan
>
> > socfpga uses mgr->dev for debug prints, there should be consistency
> > here, so standardize on that. The only other use was for dma
> > which can be replaced with mgr->dev.parent.
> >
> > Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
For the priv->dev removal part.
Acked-by: Moritz Fischer <moritz.fischer@ettus.com>
> > ---
> > drivers/fpga/zynq-fpga.c | 22 ++++++++++------------
> > 1 file changed, 10 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
> > index 3ffc5fcc3072..ac2deae92dbd 100644
> > --- a/drivers/fpga/zynq-fpga.c
> > +++ b/drivers/fpga/zynq-fpga.c
> > @@ -118,7 +118,6 @@
> > #define FPGA_RST_NONE_MASK 0x0
> >
> > struct zynq_fpga_priv {
> > - struct device *dev;
> > int irq;
> > struct clk *clk;
> >
> > @@ -188,7 +187,7 @@ static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> > * least the sync word and something else to do anything.
> > */
> > if (count <= 4 || (count % 4) != 0) {
> > - dev_err(priv->dev,
> > + dev_err(&mgr->dev,
> > "Invalid bitstream size, must be multiples of 4 bytes\n");
> > return -EINVAL;
> > }
> > @@ -200,7 +199,7 @@ static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> > /* don't globally reset PL if we're doing partial reconfig */
> > if (!(flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> > if (!zynq_fpga_has_sync(buf, count)) {
> > - dev_err(priv->dev,
> > + dev_err(&mgr->dev,
> > "Invalid bitstream, could not find a sync word. Bitstream must be a byte swaped .bin file\n");
> > err = -EINVAL;
> > goto out_err;
> > @@ -233,7 +232,7 @@ static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> > INIT_POLL_DELAY,
> > INIT_POLL_TIMEOUT);
> > if (err) {
> > - dev_err(priv->dev, "Timeout waiting for PCFG_INIT\n");
> > + dev_err(&mgr->dev, "Timeout waiting for PCFG_INIT\n");
> > goto out_err;
> > }
> >
> > @@ -247,7 +246,7 @@ static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> > INIT_POLL_DELAY,
> > INIT_POLL_TIMEOUT);
> > if (err) {
> > - dev_err(priv->dev, "Timeout waiting for !PCFG_INIT\n");
> > + dev_err(&mgr->dev, "Timeout waiting for !PCFG_INIT\n");
> > goto out_err;
> > }
> >
> > @@ -261,7 +260,7 @@ static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> > INIT_POLL_DELAY,
> > INIT_POLL_TIMEOUT);
> > if (err) {
> > - dev_err(priv->dev, "Timeout waiting for PCFG_INIT\n");
> > + dev_err(&mgr->dev, "Timeout waiting for PCFG_INIT\n");
> > goto out_err;
> > }
> > }
> > @@ -278,7 +277,7 @@ static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> > /* check that we have room in the command queue */
> > status = zynq_fpga_read(priv, STATUS_OFFSET);
> > if (status & STATUS_DMA_Q_F) {
> > - dev_err(priv->dev, "DMA command queue full\n");
> > + dev_err(&mgr->dev, "DMA command queue full\n");
> > err = -EBUSY;
> > goto out_err;
> > }
> > @@ -309,7 +308,8 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr,
> >
> > priv = mgr->priv;
> >
> > - kbuf = dma_alloc_coherent(priv->dev, count, &dma_addr, GFP_KERNEL);
> > + kbuf =
> > + dma_alloc_coherent(mgr->dev.parent, count, &dma_addr, GFP_KERNEL);
> > if (!kbuf)
> > return -ENOMEM;
> >
> > @@ -356,7 +356,7 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr,
> > goto out_clk;
> >
> > out_report:
> > - dev_err(priv->dev,
> > + dev_err(&mgr->dev,
> > "%s: INT_STS:0x%x CTRL:0x%x LOCK:0x%x INT_MASK:0x%x STATUS:0x%x MCTRL:0x%x\n",
> > why,
> > intr_status,
> > @@ -368,7 +368,7 @@ out_report:
> > out_clk:
> > clk_disable(priv->clk);
> > out_free:
> > - dma_free_coherent(priv->dev, count, kbuf, dma_addr);
> > + dma_free_coherent(mgr->dev.parent, count, kbuf, dma_addr);
> > return err;
> > }
> >
> > @@ -445,8 +445,6 @@ static int zynq_fpga_probe(struct platform_device *pdev)
> > if (!priv)
> > return -ENOMEM;
> >
> > - priv->dev = dev;
> > -
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > priv->io_base = devm_ioremap_resource(dev, res);
> > if (IS_ERR(priv->io_base))
> > --
> > 2.1.4
> >
> >
Thanks,
Moritz
^ permalink raw reply
* [PATCH] PCI: Add information about describing PCI in ACPI
From: Bjorn Helgaas @ 2016-11-17 17:59 UTC (permalink / raw)
To: linux-arm-kernel
Add a writeup about how PCI host bridges should be described in ACPI
using PNP0A03/PNP0A08 devices, PNP0C02 devices, and the MCFG table.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
Documentation/PCI/00-INDEX | 2 +
Documentation/PCI/acpi-info.txt | 136 +++++++++++++++++++++++++++++++++++++++
2 files changed, 138 insertions(+)
create mode 100644 Documentation/PCI/acpi-info.txt
diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index 147231f..0780280 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -1,5 +1,7 @@
00-INDEX
- this file
+acpi-info.txt
+ - info on how PCI host bridges are represented in ACPI
MSI-HOWTO.txt
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
PCIEBUS-HOWTO.txt
diff --git a/Documentation/PCI/acpi-info.txt b/Documentation/PCI/acpi-info.txt
new file mode 100644
index 0000000..ccbcfda
--- /dev/null
+++ b/Documentation/PCI/acpi-info.txt
@@ -0,0 +1,136 @@
+ ACPI considerations for PCI host bridges
+
+The basic requirement is that the ACPI namespace should describe
+*everything* that consumes address space unless there's another
+standard way for the OS to find it [1, 2]. ?For example, windows that
+are forwarded to PCI by a PCI host bridge should be described via ACPI
+devices, since the OS can't locate the host bridge by itself. ?PCI
+devices *below* the host bridge do not need to be described via ACPI,
+because the resources they consume are inside the host bridge windows,
+and the OS can discover them via the standard PCI enumeration
+mechanism (using config accesses to read and size the BARs).
+
+This ACPI resource description is done via _CRS methods of devices in
+the ACPI namespace [2]. ? _CRS methods are like generalized PCI BARs:
+the OS can read _CRS and figure out what resource is being consumed
+even if it doesn't have a driver for the device [3]. ?That's important
+because it means an old OS can work correctly even on a system with
+new devices unknown to the OS. ?The new devices won't do anything, but
+the OS can at least make sure no resources conflict with them.
+
+Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for
+reserving address space! The static tables are for things the OS
+needs to know early in boot, before it can parse the ACPI namespace.
+If a new table is defined, an old OS needs to operate correctly even
+though it ignores the table. _CRS allows that because it is generic
+and understood by the old OS; a static table does not.
+
+If the OS is expected to manage an ACPI device, that device will have
+a specific _HID/_CID that tells the OS what driver to bind to it, and
+the _CRS tells the OS and the driver where the device's registers are.
+
+PNP0C02 "motherboard" devices are basically a catch-all. ?There's no
+programming model for them other than "don't use these resources for
+anything else." ?So any address space that is (1) not claimed by some
+other ACPI device and (2) should not be assigned by the OS to
+something else, should be claimed by a PNP0C02 _CRS method.
+
+PCI host bridges are PNP0A03 or PNP0A08 devices. ?Their _CRS should
+describe all the address space they consume. ?In principle, this would
+be all the windows they forward down to the PCI bus, as well as the
+bridge registers themselves. ?The bridge registers include things like
+secondary/subordinate bus registers that determine the bus range below
+the bridge, window registers that describe the apertures, etc. ?These
+are all device-specific, non-architected things, so the only way a
+PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which
+contain the device-specific details. ?These bridge registers also
+include ECAM space, since it is consumed by the bridge.
+
+ACPI defined a Producer/Consumer bit that was intended to distinguish
+the bridge apertures from the bridge registers [4, 5]. ?However,
+BIOSes didn't use that bit correctly, and the result is that OSes have
+to assume that everything in a PCI host bridge _CRS is a window. ?That
+leaves no way to describe the bridge registers in the PNP0A03/PNP0A08
+device itself.
+
+The workaround is to describe the bridge registers (including ECAM
+space) in PNP0C02 catch-all devices [6]. ?With the exception of ECAM,
+the bridge register space is device-specific anyway, so the generic
+PNP0A03/PNP0A08 driver (pci_root.c) has no need to know about it. ?For
+ECAM, pci_root.c learns about the space from either MCFG or the _CBA
+method.
+
+Note that the PCIe spec actually does require ECAM unless there's a
+standard firmware interface for config access, e.g., the ia64 SAL
+interface [7]. One reason is that we want a generic host bridge
+driver (pci_root.c), and a generic driver requires a generic way to
+access config space.
+
+
+[1] ACPI 6.0, sec 6.1:
+ For any device that is on a non-enumerable type of bus (for
+ example, an ISA bus), OSPM enumerates the devices' identifier(s)
+ and the ACPI system firmware must supply an _HID object ... for
+ each device to enable OSPM to do that.
+
+[2] ACPI 6.0, sec 3.7:
+ The OS enumerates motherboard devices simply by reading through
+ the ACPI Namespace looking for devices with hardware IDs.
+
+ Each device enumerated by ACPI includes ACPI-defined objects in
+ the ACPI Namespace that report the hardware resources the device
+ could occupy [_PRS], an object that reports the resources that are
+ currently used by the device [_CRS], and objects for configuring
+ those resources [_SRS]. The information is used by the Plug and
+ Play OS (OSPM) to configure the devices.
+
+[3] ACPI 6.0, sec 6.2:
+ OSPM uses device configuration objects to configure hardware
+ resources for devices enumerated via ACPI. Device configuration
+ objects provide information about current and possible resource
+ requirements, the relationship between shared resources, and
+ methods for configuring hardware resources.
+
+ When OSPM enumerates a device, it calls _PRS to determine the
+ resource requirements of the device. It may also call _CRS to
+ find the current resource settings for the device. Using this
+ information, the Plug and Play system determines what resources
+ the device should consume and sets those resources by calling the
+ device?s _SRS control method.
+
+ In ACPI, devices can consume resources (for example, legacy
+ keyboards), provide resources (for example, a proprietary PCI
+ bridge), or do both. Unless otherwise specified, resources for a
+ device are assumed to be taken from the nearest matching resource
+ above the device in the device hierarchy.
+
+[4] ACPI 6.0, sec 6.4.3.5.4:
+ Extended Address Space Descriptor
+ General Flags: Bit [0] Consumer/Producer:
+ 1?This device consumes this resource
+ 0?This device produces and consumes this resource
+
+[5] ACPI 6.0, sec 19.6.43:
+ ResourceUsage specifies whether the Memory range is consumed by
+ this device (ResourceConsumer) or passed on to child devices
+ (ResourceProducer). If nothing is specified, then
+ ResourceConsumer is assumed.
+
+[6] PCI Firmware 3.0, sec 4.1.2:
+ If the operating system does not natively comprehend reserving the
+ MMCFG region, the MMCFG region must be reserved by firmware. The
+ address range reported in the MCFG table or by _CBA method (see
+ Section 4.1.3) must be reserved by declaring a motherboard
+ resource. For most systems, the motherboard resource would appear
+ at the root of the ACPI namespace (under \_SB) in a node with a
+ _HID of EISAID (PNP0C02), and the resources in this case should
+ not be claimed in the root PCI bus?s _CRS. The resources can
+ optionally be returned in Int15 E820 or EFIGetMemoryMap as
+ reserved memory but must always be reported through ACPI as a
+ motherboard resource.
+
+[7] PCI Express 3.0, sec 7.2.2:
+ For systems that are PC-compatible, or that do not implement a
+ processor-architecture-specific firmware interface standard that
+ allows access to the Configuration Space, the ECAM is required as
+ defined in this section.
^ 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