* [PATCH v2] ARM: dts: AM571x-IDK Initial Support
From: Rob Herring @ 2016-11-23 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122041732.8385-1-lokeshvutla@ti.com>
On Tue, Nov 22, 2016 at 09:47:32AM +0530, Lokesh Vutla wrote:
> From: Schuyler Patton <spatton@ti.com>
>
> The AM571x-IDK board is a board based on TI's AM5718 SOC
> which has a single core 1.5GHz A15 processor. This board is a
> development platform for the Industrial market with:
> - 1GB of DDR3L
> - Dual 1Gbps Ethernet
> - HDMI,
> - PRU-ICSS
> - uSD
> - 16GB eMMC
> - CAN
> - RS-485
> - PCIe
> - USB3.0
> - Video Input Port
> - Industrial IO port and expansion connector
>
> The link to the data sheet and TRM can be found here:
>
> http://www.ti.com/product/AM5718
>
> Initial support is only for basic peripherals.
>
> Signed-off-by: Schuyler Patton <spatton@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> Cahnges since v1:
> - Dropped "ti,dra722", and "ti,dra72" from compatibles
> - Fixes few node names as suggested by Rob.
> Logs: http://pastebin.ubuntu.com/23515001/
>
> .../devicetree/bindings/arm/omap/omap.txt | 3 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/am571x-idk.dts | 81 ++++++++++++++++++++++
> 3 files changed, 85 insertions(+)
> create mode 100644 arch/arm/boot/dts/am571x-idk.dts
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] ARM: dts: imx6q-cm-fx6: enable S/PDIF support
From: Fabio Estevam @ 2016-11-23 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5da612fbab7a4064993790702550fa77@rwthex-s1-b.rwth-ad.de>
On Tue, Nov 22, 2016 at 10:07 PM, <christopher.spinrath@rwth-aachen.de> wrote:
> From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
>
> Enable the S/PDIF transceiver present on the cm-fx6 module.
>
> Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH v4 1/2] Documentation: dt: reset: Add TI SCI reset binding
From: Rob Herring @ 2016-11-23 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121213052.8684-2-afd@ti.com>
On Mon, Nov 21, 2016 at 03:30:51PM -0600, Andrew F. Davis wrote:
> Add TI SCI reset controller binding. This describes the DT binding
> details for a reset controller node providing reset management services
> to hardware blocks (reset consumers) using the Texas Instrument's System
> Control Interface (TI SCI) protocol to communicate to a system controller
> block present on the SoC.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> [s-anna at ti.com: revise the binding format]
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
> ---
> .../devicetree/bindings/reset/ti,sci-reset.txt | 66 ++++++++++++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/reset/k2g.h | 22 ++++++++
> 3 files changed, 90 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> create mode 100644 include/dt-bindings/reset/k2g.h
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/2] PCI: iproc: fix 32-bit build
From: Bjorn Helgaas @ 2016-11-23 22:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122141844.1655574-1-arnd@arndb.de>
On Tue, Nov 22, 2016 at 03:17:51PM +0100, Arnd Bergmann wrote:
> The newly added code to setup the inbound ranges causes a link error
> on 32-bit machines from a 32-bit division:
>
> drivers/pci/host/pcie-iproc.o: In function `iproc_pcie_setup_ib':
> pcie-iproc.c:(.text.iproc_pcie_setup_ib+0x14c): undefined reference to `__aeabi_uldivmod'
>
> As both sides of the division are always power-of-two numbers and
> we already rely on that, we can use a shift instead.
>
> Fixes: 87c240b19bba ("PCI: iproc: Add inbound DMA mapping support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I folded these fixes into the pci/host-iproc branch for v4.10, thanks!
For some reason, I don't see Ray's responses on the list. Maybe still
some email problem?
> ---
> drivers/pci/host/pcie-iproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> index d10e6aa32e0d..857ff5198317 100644
> --- a/drivers/pci/host/pcie-iproc.c
> +++ b/drivers/pci/host/pcie-iproc.c
> @@ -865,7 +865,7 @@ static int iproc_pcie_ib_write(struct iproc_pcie *pcie, int region_idx,
> * Now program the IMAP registers. Each IARR region may have one or
> * more IMAP windows.
> */
> - size /= nr_windows;
> + size >>= ilog2(nr_windows);
> for (window_idx = 0; window_idx < nr_windows; window_idx++) {
> val = readl(pcie->base + imap_offset);
> val |= lower_32_bits(axi_addr) | IMAP_VALID;
> --
> 2.9.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] Add support for the Nexbox A1 board based on the Amlogic S912 SoC.
From: Rob Herring @ 2016-11-23 22:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121162905.14285-3-narmstrong@baylibre.com>
On Mon, Nov 21, 2016 at 05:29:05PM +0100, Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/arm/amlogic.txt | 1 +
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 169 +++++++++++++++++++++
> 3 files changed, 171 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
A few nits below, otherwise:
Acked-by: Rob Herring <robh@kernel.org>
>
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
> index 1144214..6ef7c52 100644
> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> @@ -45,3 +45,4 @@ Board compatible values:
> - "amlogic,p231" (Meson gxl s905d)
> - "amlogic,q200" (Meson gxm s912)
> - "amlogic,q201" (Meson gxm s912)
> + - "nexbox,a1" (Meson gxm s912)
> diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
> index 7752a16..2fbb8e3 100644
> --- a/arch/arm64/boot/dts/amlogic/Makefile
> +++ b/arch/arm64/boot/dts/amlogic/Makefile
> @@ -10,6 +10,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p230.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p231.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q200.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q201.dtb
> +dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb
>
> always := $(dtb-y)
> subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> new file mode 100644
> index 0000000..d320727
> --- /dev/null
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> @@ -0,0 +1,169 @@
> +/*
> + * Copyright (c) 2016 BayLibre, SAS.
> + * Author: Neil Armstrong <narmstrong@baylibre.com>
> + *
> + * Copyright (c) 2016 Endless Computers, Inc.
> + * Author: Carlo Caione <carlo@endlessm.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "meson-gxm.dtsi"
> +
> +/ {
> + compatible = "nexbox,a1", "amlogic,s912", "amlogic,meson-gxm";
> + model = "NEXBOX A1";
> +
> + aliases {
> + serial0 = &uart_AO;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory at 0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x80000000>;
> + };
> +
> + vddio_boot: regulator-vddio_boot {
Don't use '_' in node names.
> + compatible = "regulator-fixed";
> + regulator-name = "VDDIO_BOOT";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + vddao_3v3: regulator-vddao_3v3 {
ditto
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + vcc_3v3: regulator-vcc_3v3 {
ditto
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + emmc_pwrseq: emmc-pwrseq {
> + compatible = "mmc-pwrseq-emmc";
> + reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
> + };
> +};
> +
> +/* This UART is brought out to the DB9 connector */
> +&uart_AO {
> + status = "okay";
> + pinctrl-0 = <&uart_ao_a_pins>;
> + pinctrl-names = "default";
> +};
> +
> +&ir {
> + status = "okay";
> + pinctrl-0 = <&remote_input_ao_pins>;
> + pinctrl-names = "default";
> +};
> +
> +/* SD card */
> +&sd_emmc_b {
> + status = "okay";
> + pinctrl-0 = <&sdcard_pins>;
> + pinctrl-names = "default";
> +
> + bus-width = <4>;
> + cap-sd-highspeed;
> + max-frequency = <100000000>;
> + disable-wp;
> +
> + cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> +
> + vmmc-supply = <&vddao_3v3>;
> + vqmmc-supply = <&vddio_boot>;
> +};
> +
> +/* eMMC */
> +&sd_emmc_c {
> + status = "okay";
> + pinctrl-0 = <&emmc_pins>;
> + pinctrl-names = "default";
> +
> + bus-width = <8>;
> + cap-sd-highspeed;
> + cap-mmc-highspeed;
> + max-frequency = <200000000>;
> + non-removable;
> + disable-wp;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> +
> + mmc-pwrseq = <&emmc_pwrseq>;
> + vmmc-supply = <&vcc_3v3>;
> + vqmmc-supply = <&vddio_boot>;
> +};
> +
> +ðmac {
> + status = "okay";
> +
> + pinctrl-0 = <ð_pins>;
> + pinctrl-names = "default";
> +
> + /* Select external PHY by default */
> + phy-handle = <&external_phy>;
> +
> + snps,reset-gpio = <&gpio GPIOZ_14 0>;
> + snps,reset-delays-us = <0 10000 1000000>;
> + snps,reset-active-low;
> +
> + /* External PHY is in RGMII */
> + phy-mode = "rgmii";
> +};
> +
> +&external_mdio {
> + external_phy: ethernet-phy at 0 {
> + compatible = "ethernet-phy-id001c.c916", "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + max-speed = <1000>;
> + };
> +};
> --
> 2.7.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: David Lechner @ 2016-11-23 22:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m2bmx5x1y2.fsf@baylibre.com>
On 11/23/2016 04:32 PM, Kevin Hilman wrote:
> David Lechner <david@lechnology.com> writes:
>
>> On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote:
>>> 2016-11-22 23:23 GMT+01:00 David Lechner <david@lechnology.com>:
>>>> On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
>>>>>
>>>>> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
>>>>> controller drivers to da850.dtsi.
>>>>>
>>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>>> ---
>>>>> v1 -> v2:
>>>>> - moved the priority controller node above the cfgchip node
>>>>> - renamed added nodes to better reflect their purpose
>>>>>
>>>>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>>>>> 1 file changed, 8 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>>>> index 1bb1f6d..412eec6 100644
>>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>>> @@ -210,6 +210,10 @@
>>>>> };
>>>>>
>>>>> };
>>>>> + prictrl: priority-controller at 14110 {
>>>>> + compatible = "ti,da850-mstpri";
>>>>> + reg = <0x14110 0x0c>;
>>>>
>>>>
>>>> I think we should add status = "disabled"; here and let boards opt in.
>>>>
>>>>> + };
>>>>> cfgchip: chip-controller at 1417c {
>>>>> compatible = "ti,da830-cfgchip", "syscon",
>>>>> "simple-mfd";
>>>>> reg = <0x1417c 0x14>;
>>>>> @@ -451,4 +455,8 @@
>>>>> 1 0 0x68000000 0x00008000>;
>>>>> status = "disabled";
>>>>> };
>>>>> + memctrl: memory-controller at b0000000 {
>>>>> + compatible = "ti,da850-ddr-controller";
>>>>> + reg = <0xb0000000 0xe8>;
>>>>
>>>>
>>>> same here. status = "disabled";
>>>>
>>>>> + };
>>>>> };
>>>>>
>>>
>>> Hi David,
>>>
>>> I did that initially[1][2] and it was rejected by Kevin[3] and Laurent[4].
>>>
>>> FYI this patch has already been queued by Sekhar.
>>
>> Thanks. I did not see those threads.
>>
>> FYI to maintainers, having these enabled by default causes error
>> messages in the kernel log for other boards that are not supported by
>> the drivers.
>
> Then the driver is too noisy and should be cleaned up.
>
>> Since there is only one board that is supported and soon
>> to be 2 that are not, I would rather have this disabled by default to
>> avoid the error messages.
>
> IMO, what exactly are the error messages? Sounds like the driver is
> being too verbose, and calling things errors that are not really errors.
It is just one line per driver.
dev_err(dev, "no master priorities defined for this board\n");
and
dev_err(dev, "no settings defined for this board\n");
Since "ti,da850-lcdk" is the only board supported in these drivers, all
other boards will see these error messages.
Also, these modules will be loaded and taking up memory on boards that
don't use them. This not really a big deal and they can be explicitly
disabled, so maybe it was not worth mentioning.
>
> Kevin
>
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: tomas.hlavacek at nic.cz @ 2016-11-23 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123145916.GL14947@lunn.ch>
Hi Andrew!
On Wed, Nov 23, 2016 at 3:59 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> >CZ11NIC12 is indicated on my board.
>>
>> :-( Well, this board version has wrongly matched length of some
>> differential pairs, IRQ from 88E1514 is connected differently, there
>> are slight differences in power supplies and (if I am not mistaken)
>> something changed in RTC support circuitry. It looks like a huge
>> mistake on our side.
>
> Hi Tomas
>
> Would these problems also explain why the Ethernet links to the switch
> don't work? Maybe the differential pairs?
I do not think so. The ethernet links to the switch are RGMII, not
differential pairs. Differential pair is used only for the eth2 to link
either SFP+ or 88E1514 (via a high-speed switch that selects one or
another). So the problems with differential pairs affect only WAN
interface.
>
>
>> It seems that libphy is probed before pca9538 and we end up with:
>> [ 4.217550] libphy: orion_mdio_bus: probed
>> [ 4.221777] irq: no irq domain found for
>> /soc/internal-regs/i2c at 11000/i2cmux at 70/i2c at 7/gpio at 71 !
>>
>> Any clue where to look in order to defer probing libphy or at least
>> orion_mdio_bus?
>
> I think there is a known phylib problem here. Somewhere in the call
> chain there is a void function, so the EPROBE_DEFFER gets
> discarded. But i could be remembering this wrongly.
Oh yes, I thought that and I tried to find exactly this type of problem
yesterday, but I didn't succeed. But I think that we agreed that we are
going to stick with PHY polling rather then experimenting with
unreliable IRQ over the GPIO expander, so we can leave this unresolved.
I will look into the I2C mux concerns, fix the remaining comments
regarding my version and test RTC more extensively - Uwe's board is
still not ticking, mine does, so we have to rule out that it is a
common problem.
Tomas
^ permalink raw reply
* [GIT PULL] Allwinner clock fixes for 4.9, take 2
From: Stephen Boyd @ 2016-11-23 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122145949.quvtzoupxbxbeql6@lukather>
On 11/22, Maxime Ripard wrote:
> Hi Mike, Stephen,
>
> Here are two new fixes for the 4.9 release.
>
> That should be my final PR for both the 4.9 fixes and 4.10
> developments.
>
> Thanks!
> Maxime
>
> The following changes since commit ac95330b96376550ae7a533d1396272d675adfa2:
>
> clk: sunxi: Fix M factor computation for APB1 (2016-11-04 08:49:46 +0100)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-clk-fixes-for-4.9-2
Ok. Pulled into a tag to send off tomorrow with another fix for
v4.9. Thanks.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 3/3] ARM: dts: da850: Add node for pullup/pulldown pinconf
From: Kevin Hilman @ 2016-11-23 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <06bc8517-8c33-85a1-9d5a-29042c7281db@lechnology.com>
David Lechner <david@lechnology.com> writes:
> On 11/23/2016 05:12 AM, Sekhar Nori wrote:
>> On Wednesday 23 November 2016 08:59 AM, David Lechner wrote:
>>> This SoC has a separate pin controller for configuring pullup/pulldown
>>> bias on groups of pins.
>>>
>>> Signed-off-by: David Lechner <david@lechnology.com>
>>> ---
>>> arch/arm/boot/dts/da850.dtsi | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>> index 8945815..1c0224c 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -210,6 +210,11 @@
>>> };
>>>
>>> };
>>> + pinconf: pin-controller at 22c00c {
>>> + compatible = "ti,da850-pupd";
>>> + reg = <0x22c00c 0x8>;
>>> + status = "disabled";
>>> + };
>>
>> Can you please place this below the i2c1 node. I am trying to keep the
>> nodes sorted by unit address. I know thats broken in many places today,
>> but lets add the new ones where they should eventually end up.
>
> I can do this, but it seems that the predominant sorting pattern here
> is to keep subsystems together (e.g. all i2c are together, all uart
> are together, etc.)
>
> Would a separate patch to sort everything by unit address to get this
> cleaned up be acceptable?
No thanks. That kind of thing is the needless churn that gets us flamed.
Kevin
^ permalink raw reply
* [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: Kevin Hilman @ 2016-11-23 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5e647eb0-2f8a-b46b-2048-7616bfb54ad7@lechnology.com>
David Lechner <david@lechnology.com> writes:
> On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote:
>> 2016-11-22 23:23 GMT+01:00 David Lechner <david@lechnology.com>:
>>> On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
>>>>
>>>> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
>>>> controller drivers to da850.dtsi.
>>>>
>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>> ---
>>>> v1 -> v2:
>>>> - moved the priority controller node above the cfgchip node
>>>> - renamed added nodes to better reflect their purpose
>>>>
>>>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>>>> 1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>>> index 1bb1f6d..412eec6 100644
>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>> @@ -210,6 +210,10 @@
>>>> };
>>>>
>>>> };
>>>> + prictrl: priority-controller at 14110 {
>>>> + compatible = "ti,da850-mstpri";
>>>> + reg = <0x14110 0x0c>;
>>>
>>>
>>> I think we should add status = "disabled"; here and let boards opt in.
>>>
>>>> + };
>>>> cfgchip: chip-controller at 1417c {
>>>> compatible = "ti,da830-cfgchip", "syscon",
>>>> "simple-mfd";
>>>> reg = <0x1417c 0x14>;
>>>> @@ -451,4 +455,8 @@
>>>> 1 0 0x68000000 0x00008000>;
>>>> status = "disabled";
>>>> };
>>>> + memctrl: memory-controller at b0000000 {
>>>> + compatible = "ti,da850-ddr-controller";
>>>> + reg = <0xb0000000 0xe8>;
>>>
>>>
>>> same here. status = "disabled";
>>>
>>>> + };
>>>> };
>>>>
>>
>> Hi David,
>>
>> I did that initially[1][2] and it was rejected by Kevin[3] and Laurent[4].
>>
>> FYI this patch has already been queued by Sekhar.
>
> Thanks. I did not see those threads.
>
> FYI to maintainers, having these enabled by default causes error
> messages in the kernel log for other boards that are not supported by
> the drivers.
Then the driver is too noisy and should be cleaned up.
> Since there is only one board that is supported and soon
> to be 2 that are not, I would rather have this disabled by default to
> avoid the error messages.
IMO, what exactly are the error messages? Sounds like the driver is
being too verbose, and calling things errors that are not really errors.
Kevin
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT changes for v4.10, round 2
From: Kevin Hilman @ 2016-11-23 22:23 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
Here's a final round of arm64 DT changes for Amlogic family SoCs.
Please pull.
Thanks,
Kevin
The following changes since commit ab5b24fdd2d551ea729e8e19e47811a646260331:
ARM64: dts: meson-gxbb-vega-s95: Add SD/SDIO/MMC and PWM nodes (2016-11-15 12:05:54 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-2
for you to fetch changes up to 3db317765fcd55808c782f38c0d3f1862a922c2a:
ARM64: dts: meson-gxl: Add support for Nexbox A95X (2016-11-23 07:57:35 -0800)
----------------------------------------------------------------
Amlogic 64-bit DT updates for v4.10, round 2
- new SoC support: S912/GXM series (8x A53)
- new boards: Nexbox A1 (S912), Nexbox A95X (S905X)
- resets for 2nd USB PHY
----------------------------------------------------------------
Martin Blumenstingl (1):
ARM64: dts: meson-gxbb: add the USB reset also to the second USB PHY
Neil Armstrong (3):
ARM64: dts: Add support for Meson GXM
ARM64: dts: meson-gxm: Add support for the Nexbox A1
ARM64: dts: meson-gxl: Add support for Nexbox A95X
Documentation/devicetree/bindings/arm/amlogic.txt | 8 +++
arch/arm64/boot/dts/amlogic/Makefile | 4 ++
arch/arm64/boot/dts/amlogic/{meson-gxl-s905d-p23x.dtsi => meson-gx-p23x-q20x.dtsi} | 4 +-
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 1 +
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 205 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 3 +-
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts | 3 +-
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 169 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 77 +++++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 58 ++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 114 +++++++++++++++++++++++++++++++++++++++
11 files changed, 643 insertions(+), 3 deletions(-)
rename arch/arm64/boot/dts/amlogic/{meson-gxl-s905d-p23x.dtsi => meson-gx-p23x-q20x.dtsi} (97%)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
^ permalink raw reply
* reboot fails on at91sam9g20 with kernel 4.x
From: Alexandre Belloni @ 2016-11-23 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2093786.uQmBVvCouf@ada>
Hi,
On 23/11/2016 at 17:13:05 +0100, Alexander Dahl wrote :
> The last message obviously comes from arch/arm/kernel/reboot.c and
> something fails. ;-)
>
> Searching the web I found someone having a similar problem here:
>
> https://groups.google.com/forum/#!topic/acmesystems/vC_66zmcatk
>
> Reboot works with 3.x kernels (if they run at all). I'll try a 4.1
> tomorrow, but I would be happy if someone could assist me in debugging
> this.
>
Since 3.18, the shdwc and reset controller have their own drivers that
may or may not be compiled in the kernel. Can you check you have
CONFIG_POWER_RESET_AT91_POWEROFF and CONFIG_POWER_RESET_AT91_RESET set
in your configuration? Also, you probably want to check the DT definition
of the shdwc and the rstc.
Regards,
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123211745.GF14217@n2100.armlinux.org.uk>
On Wed, Nov 23, 2016 at 09:17:45PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2016 at 08:59:17PM +0000, Jason Cooper wrote:
> > As requested on irc:
>
> Thanks.
>
> > 7f0: ea000002 b 800 <ath_cmn_process_fft+0xac>
> > 7f4: e7970102 ldr r0, [r7, r2, lsl #2]
> > 7f8: ebfffffe bl 0 <relay_buf_full>
> > 7fc: e0844000 add r4, r4, r0
> > 800: e300a000 movw sl, #0
> > 804: e28b2001 add r2, fp, #1
> > 808: e340a000 movt sl, #0
> > 80c: e3a01004 mov r1, #4
> > 810: e1a0000a mov r0, sl
> > 814: ebfffffe bl 0 <_find_next_bit_le>
> > 818: e5953000 ldr r3, [r5]
> > 81c: e1500003 cmp r0, r3
> > 820: e1a0b000 mov fp, r0
> > 824: e2802008 add r2, r0, #8
> > 828: bafffff1 blt 7f4 <ath_cmn_process_fft+0xa0>
>
> Okay, so i was 0, so running UP probably isn't going to help. r7 is
> also spec_priv->rfs_chan_spec_scan.
>
> So, I think the question is... how is this NULL - and has it always
> been NULL...
The problem appears to be that ath_cmn_process_fft() isn't called that
often. When it is, it crashes in ath_cmn_is_fft_buf_full() because
spec_priv->rfs_chan_spec_scan is NULL when ATH9K_DEBUGFS=n. :-(
I'm running with ATH9K_DEBUGFS=y now. If it goes a couple of days
without crashing, I'll gin up a patch.
thx,
Jason.
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Ard Biesheuvel @ 2016-11-23 21:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123211538.GH10776@rric.localdomain>
On 23 November 2016 at 21:15, Robert Richter <robert.richter@cavium.com> wrote:
> On 20.11.16 17:07:44, Ard Biesheuvel wrote:
>> On 17 November 2016 at 15:18, Robert Richter <robert.richter@cavium.com> wrote:
>
>> > The risk of breaking something with my patch is small and limited only
>> > to the mapping of efi reserved regions (which is the state of 4.4). If
>> > something breaks anyway it can easily be fixed by adding more checks
>> > to pfn_valid() as suggested above.
>> >
>>
>> As I noted before, it looks to me like setting CONFIG_HOLES_IN_ZONE is
>> the correct way to address this. However, doing that does uncover a
>> bug in move_freepages() where the VM_BUG_ON_PAGE() dereferences struct
>> page fields before the pfn_valid_within() check, so it seems those
>> need to be switched around.
>>
>> Robert, you mentioned that CONFIG_HOLES_IN_ZONE seems inappropriate
>> for sparsemem. Care to elaborate why?
>
> HOLES_IN_ZONE is of rare use in the kernel. I think it was introduced
> to save memory for the memmap and only some single systems enable it.
> There is no architecture that enables it entirely. For good reasons...
>
> It introduces additional checks. pfn_valid() is usually checked only
> once for the whole memmap. There are a number of checks enabled, just
> grep for pfn_valid_within. This will increase the number of
> pfn_valid() calls by a factor of MAX_ORDER_NR_PAGES, in my config this
> is 8k. So, this is not the direction to go.
>
That does sound like a potential issue. But does it cause any slowdown
in practice?
The reality is that CONFIG_HOLES_IN_ZONE perfectly describes the
situation, and so it is still my preferred option if the performance
hit is tolerable.
> My patch fixes a regression in the kernel that was introduced by the
> nomap implementation. Some systems can not boot anymore, beside of
> that the BUG_ON() may occur any time depending only on physical page
> access, we need to fix 4.9. Here is a reproducer:
>
> https://patchwork.kernel.org/patch/9407677/
>
> My patch also does not break memremap(). With my patch applied
> try_ram_remap() would return a linear addr for nomap regions. But this
> is only called if WB is explicitly requested, so it should not happen.
Why? MEMREMAP_WB is used often, among other things for mapping
firmware tables, which are marked as NOMAP, so in these cases, the
linear address is not mapped.
> If you think pfn_valid() is wrong here, I am happy to send a patch
> that fixes this by using page_is_ram(). In any case, the worst case
> that may happen is to behave the same as v4.4, we might fix then the
> wrong use of pfn_valid() where it is not correctly used to check for
> ram.
>
page_is_ram() uses string comparisons to look for regions called
'System RAM'. Is that something we can tolerate for each pfn_valid()
calll?
Perhaps the solution is to reimplement page_is_ram() for arm64 using
memblock_is_memory() instead, But that still means we need to modify
the generic memremap() code first to switch to it before changing the
arm64 implementation of pfn_valid
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Russell King - ARM Linux @ 2016-11-23 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123205917.GI2799@io.lakedaemon.net>
On Wed, Nov 23, 2016 at 08:59:17PM +0000, Jason Cooper wrote:
> As requested on irc:
Thanks.
> 7f0: ea000002 b 800 <ath_cmn_process_fft+0xac>
> 7f4: e7970102 ldr r0, [r7, r2, lsl #2]
> 7f8: ebfffffe bl 0 <relay_buf_full>
> 7fc: e0844000 add r4, r4, r0
> 800: e300a000 movw sl, #0
> 804: e28b2001 add r2, fp, #1
> 808: e340a000 movt sl, #0
> 80c: e3a01004 mov r1, #4
> 810: e1a0000a mov r0, sl
> 814: ebfffffe bl 0 <_find_next_bit_le>
> 818: e5953000 ldr r3, [r5]
> 81c: e1500003 cmp r0, r3
> 820: e1a0b000 mov fp, r0
> 824: e2802008 add r2, r0, #8
> 828: bafffff1 blt 7f4 <ath_cmn_process_fft+0xa0>
Okay, so i was 0, so running UP probably isn't going to help. r7 is
also spec_priv->rfs_chan_spec_scan.
So, I think the question is... how is this NULL - and has it always
been NULL...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Robert Richter @ 2016-11-23 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-2uGJGovqQL-gbB54u=fQ9L9YUbDdRo6u3oWqF6znn6Q@mail.gmail.com>
On 20.11.16 17:07:44, Ard Biesheuvel wrote:
> On 17 November 2016 at 15:18, Robert Richter <robert.richter@cavium.com> wrote:
> > The risk of breaking something with my patch is small and limited only
> > to the mapping of efi reserved regions (which is the state of 4.4). If
> > something breaks anyway it can easily be fixed by adding more checks
> > to pfn_valid() as suggested above.
> >
>
> As I noted before, it looks to me like setting CONFIG_HOLES_IN_ZONE is
> the correct way to address this. However, doing that does uncover a
> bug in move_freepages() where the VM_BUG_ON_PAGE() dereferences struct
> page fields before the pfn_valid_within() check, so it seems those
> need to be switched around.
>
> Robert, you mentioned that CONFIG_HOLES_IN_ZONE seems inappropriate
> for sparsemem. Care to elaborate why?
HOLES_IN_ZONE is of rare use in the kernel. I think it was introduced
to save memory for the memmap and only some single systems enable it.
There is no architecture that enables it entirely. For good reasons...
It introduces additional checks. pfn_valid() is usually checked only
once for the whole memmap. There are a number of checks enabled, just
grep for pfn_valid_within. This will increase the number of
pfn_valid() calls by a factor of MAX_ORDER_NR_PAGES, in my config this
is 8k. So, this is not the direction to go.
My patch fixes a regression in the kernel that was introduced by the
nomap implementation. Some systems can not boot anymore, beside of
that the BUG_ON() may occur any time depending only on physical page
access, we need to fix 4.9. Here is a reproducer:
https://patchwork.kernel.org/patch/9407677/
My patch also does not break memremap(). With my patch applied
try_ram_remap() would return a linear addr for nomap regions. But this
is only called if WB is explicitly requested, so it should not happen.
If you think pfn_valid() is wrong here, I am happy to send a patch
that fixes this by using page_is_ram(). In any case, the worst case
that may happen is to behave the same as v4.4, we might fix then the
wrong use of pfn_valid() where it is not correctly used to check for
ram.
-Robert
^ permalink raw reply
* [RFC PATCH v2 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2016-11-23 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e592169a-6287-7f3c-b4fd-23c4c79198b0@microchip.com>
On Wed, Nov 23, 2016 at 02:34:03PM +0100, Andrei Pistirica wrote:
> From what I understand, your suggestion is:
> (ns | frac) * ppb = (total_ns | total_frac)
> (total_ns | total_frac) / 10^9 = (adj_ns | adj_frac)
> This is correct iff total_ns/10^9 >= 1, but the problem is that there are
> missed fractions due to the following approximation:
> frac*ppb =~ (ns*ppb+frac*ppb*2^16)*2^16-10^9*2^16*flor(ns*ppb+frac*ppb*2^16,
> 10^9).
-ENOPARSE;
> An example which uses values from a real test:
> let ppb=4891, ns=12 and frac=3158
That is a very strange example for nominal frequency. The clock
period is 12.048187255859375 nanoseconds, and so the frequency is
83000037.99 Hz.
But hey, let's go with it...
> - using suggested algorithm, yields: adj_ns = 0 and adj_frac = 0
> - using in-place algorithm, yields: adj_ns = 0, adj_frac = 4
> You can check the calculus.
The test program, below, shows you what I meant. (Of course, you
should adjust this to fit the adjfine() method.)
Unfortunately, this device has a very coarse frequency resolution.
Using a nominal period of ns=12 as an example, the resolution is
2^-16 / 12 or 1.27 ppm. The 24 bit device is much better in this
repect.
The output using your example numbers is:
$ ./a.out 12 3158 4891
ns=12 frac=3158
ns=12 frac=3162
$ ./a.out 12 3158 -4891
ns=12 frac=3158
ns=12 frac=3154
See how you get a result of +/- 4 with just one division?
Thanks,
Richard
---
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
static void adjfreq(uint32_t ns, uint32_t frac, int32_t ppb)
{
uint64_t adj;
uint32_t diff, word;
int neg_adj = 0;
printf("ns=%u frac=%u\n", ns, frac);
if (ppb < 0) {
neg_adj = 1;
ppb = -ppb;
}
word = (ns << 16) + frac;
adj = word;
adj *= ppb;
adj += 500000000UL;
diff = adj / 1000000000UL;
word = neg_adj ? word - diff : word + diff;
printf("ns=%u frac=%u\n", word >> 16, word & 0xffff);
}
int main(int argc, char *argv[])
{
uint32_t ns, frac;
int32_t ppb;
if (argc != 4) {
puts("need ns, frac, and ppb");
return -1;
}
ns = atoi(argv[1]);
frac = atoi(argv[2]);
ppb = atoi(argv[3]);
adjfreq(ns, frac, ppb);
return 0;
}
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123195120.GE14217@n2100.armlinux.org.uk>
On Wed, Nov 23, 2016 at 07:51:20PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2016 at 07:15:39PM +0000, Jason Cooper wrote:
> > ------- oops from v4.8.6 #2 ------------------------------------------
> > [42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
> > [42059.311799] pgd = c0004000
> > [42059.314522] [00000020] *pgd=00000000
> > [42059.318162] Internal error: Oops: 17 [#1] SMP ARM
> > [42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
> > [42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
> > [42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
> > [42059.340613] task: c0b091c0 task.stack: c0b00000
> > [42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
> > [42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
> > [42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
> > [42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
> > [42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
> > [42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
> > [42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
>
> Well, the good news is that it's reproducable.
>
> It looks like it could be this:
>
> static int
> ath_cmn_is_fft_buf_full(struct ath_spec_scan_priv *spec_priv)
> {
> for_each_online_cpu(i)
> ret += relay_buf_full(rc->buf[i]);
>
> where i = 8 (r2) and rc->buf is r7. That's just a guess though, as
> there's precious little to go on with the Code: line - modern GCCs
> don't give us much with the Code: line anymore to figure out what's
> going on without the exact object files.
>
> e5933000 ldr r3, [r3]
> e1d330b4 ldrh r3, [r3, #4]
> e58d3030 str r3, [sp, #48] ; 0x30
> ea000002 b 1c <foo+0x1c>
> e7970102 ldr r0, [r7, r2, lsl #2]
>
As requested on irc:
-------------->8--------------------------------------------------------
drivers/net/wireless/ath/ath9k/common-spectral.o: file format elf32-littlearm
Disassembly of section .text:
...
00000754 <ath_cmn_process_fft>:
754: e92d4ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, lr}
758: e24dd0d4 sub sp, sp, #212 ; 0xd4
75c: e1a04002 mov r4, r2
760: e1a06001 mov r6, r1
764: e58d0024 str r0, [sp, #36] ; 0x24
768: e3a01000 mov r1, #0
76c: e58d2018 str r2, [sp, #24]
770: e28d0049 add r0, sp, #73 ; 0x49
774: e3a02087 mov r2, #135 ; 0x87
778: ebfffffe bl 0 <memset>
77c: e5d44007 ldrb r4, [r4, #7]
780: e20430fd and r3, r4, #253 ; 0xfd
784: e3530024 cmp r3, #36 ; 0x24
788: 13540005 cmpne r4, #5
78c: 13a04001 movne r4, #1
790: 03a04000 moveq r4, #0
794: 13a00000 movne r0, #0
798: 0a000001 beq 7a4 <ath_cmn_process_fft+0x50>
79c: e28dd0d4 add sp, sp, #212 ; 0xd4
7a0: e8bd8ff0 pop {r4, r5, r6, r7, r8, r9, sl, fp, pc}
7a4: e59d3018 ldr r3, [sp, #24]
7a8: e1d380b4 ldrh r8, [r3, #4]
7ac: e2489003 sub r9, r8, #3
7b0: e0863009 add r3, r6, r9
7b4: e5d30002 ldrb r0, [r3, #2]
7b8: e2000010 and r0, r0, #16
7bc: e21000ff ands r0, r0, #255 ; 0xff
7c0: 0afffff5 beq 79c <ath_cmn_process_fft+0x48>
7c4: e59d3024 ldr r3, [sp, #36] ; 0x24
7c8: e3005000 movw r5, #0
7cc: e3405000 movt r5, #0
7d0: e3e0b000 mvn fp, #0
7d4: e5932000 ldr r2, [r3]
7d8: e5937004 ldr r7, [r3, #4]
7dc: e5923438 ldr r3, [r2, #1080] ; 0x438
7e0: e58d2010 str r2, [sp, #16]
7e4: e5933000 ldr r3, [r3]
7e8: e1d330b4 ldrh r3, [r3, #4]
7ec: e58d3030 str r3, [sp, #48] ; 0x30
7f0: ea000002 b 800 <ath_cmn_process_fft+0xac>
7f4: e7970102 ldr r0, [r7, r2, lsl #2]
7f8: ebfffffe bl 0 <relay_buf_full>
7fc: e0844000 add r4, r4, r0
800: e300a000 movw sl, #0
804: e28b2001 add r2, fp, #1
808: e340a000 movt sl, #0
80c: e3a01004 mov r1, #4
810: e1a0000a mov r0, sl
814: ebfffffe bl 0 <_find_next_bit_le>
818: e5953000 ldr r3, [r5]
81c: e1500003 cmp r0, r3
820: e1a0b000 mov fp, r0
824: e2802008 add r2, r0, #8
828: bafffff1 blt 7f4 <ath_cmn_process_fft+0xa0>
82c: e59a0000 ldr r0, [sl]
830: e200000f and r0, r0, #15
834: ebfffffe bl 0 <__sw_hweight32>
838: e1540000 cmp r4, r0
83c: 0a000092 beq a8c <ath_cmn_process_fft+0x338>
840: e59d3010 ldr r3, [sp, #16]
844: e5932030 ldr r2, [r3, #48] ; 0x30
848: e5923018 ldr r3, [r2, #24]
84c: e3530001 cmp r3, #1
850: 0a000090 beq a98 <ath_cmn_process_fft+0x344>
854: 3a000119 bcc cc0 <ath_cmn_process_fft+0x56c>
858: e3530002 cmp r3, #2
85c: 1a000110 bne ca4 <ath_cmn_process_fft+0x550>
860: e3003000 movw r3, #0
864: e5921014 ldr r1, [r2, #20]
868: e1a00003 mov r0, r3
86c: e592301c ldr r3, [r2, #28]
870: e3002000 movw r2, #0
874: e3a0b087 mov fp, #135 ; 0x87
878: e1a0c002 mov ip, r2
87c: e1a02000 mov r2, r0
880: e3402000 movt r2, #0
884: e58d2034 str r2, [sp, #52] ; 0x34
888: e1a0200c mov r2, ip
88c: e3a0a08a mov sl, #138 ; 0x8a
890: e3402000 movt r2, #0
894: e58d2044 str r2, [sp, #68] ; 0x44
898: e1d120b4 ldrh r2, [r1, #4]
89c: e3a01080 mov r1, #128 ; 0x80
8a0: e58d1020 str r1, [sp, #32]
8a4: e1520003 cmp r2, r3
8a8: 33a03003 movcc r3, #3
8ac: 23a03002 movcs r3, #2
8b0: e58d3038 str r3, [sp, #56] ; 0x38
8b4: e2483002 sub r3, r8, #2
8b8: e58d3014 str r3, [sp, #20]
8bc: e3530000 cmp r3, #0
8c0: da000071 ble a8c <ath_cmn_process_fft+0x338>
8c4: e3a03000 mov r3, #0
8c8: e28aa002 add sl, sl, #2
8cc: e1a04003 mov r4, r3
8d0: e58d3028 str r3, [sp, #40] ; 0x28
8d4: e1a05004 mov r5, r4
8d8: e24b3001 sub r3, fp, #1
8dc: e1a07006 mov r7, r6
8e0: e58d302c str r3, [sp, #44] ; 0x2c
8e4: e58db01c str fp, [sp, #28]
8e8: e1a03009 mov r3, r9
8ec: e58d8010 str r8, [sp, #16]
8f0: e1a09004 mov r9, r4
8f4: ea00002c b 9ac <ath_cmn_process_fft+0x258>
8f8: e3520007 cmp r2, #7
8fc: e1a05003 mov r5, r3
900: e086b004 add fp, r6, r4
904: 8a00006f bhi ac8 <ath_cmn_process_fft+0x374>
908: e59d202c ldr r2, [sp, #44] ; 0x2c
90c: e1530002 cmp r3, r2
910: a3a09001 movge r9, #1
914: ba0000dd blt c90 <ath_cmn_process_fft+0x53c>
918: e59d101c ldr r1, [sp, #28]
91c: e2812002 add r2, r1, #2
920: e1520005 cmp r2, r5
924: ba000058 blt a8c <ath_cmn_process_fft+0x338>
928: e1510005 cmp r1, r5
92c: aa000092 bge b7c <ath_cmn_process_fft+0x428>
930: e5d7001f ldrb r0, [r7, #31]
934: e5d71020 ldrb r1, [r7, #32]
938: e1500001 cmp r0, r1
93c: 1a000052 bne a8c <ath_cmn_process_fft+0x338>
940: e58d3040 str r3, [sp, #64] ; 0x40
944: e1a01004 mov r1, r4
948: e59d3044 ldr r3, [sp, #68] ; 0x44
94c: e1a0000b mov r0, fp
950: e58d203c str r2, [sp, #60] ; 0x3c
954: e12fff33 blx r3
958: e3500000 cmp r0, #0
95c: e59d203c ldr r2, [sp, #60] ; 0x3c
960: e59d3040 ldr r3, [sp, #64] ; 0x40
964: 1a00008e bne ba4 <ath_cmn_process_fft+0x450>
968: e59d2010 ldr r2, [sp, #16]
96c: e152000a cmp r2, sl
970: da0000c9 ble c9c <ath_cmn_process_fft+0x548>
974: e59d9028 ldr r9, [sp, #40] ; 0x28
978: e2842001 add r2, r4, #1
97c: e0867002 add r7, r6, r2
980: e3590000 cmp r9, #0
984: 13a09000 movne r9, #0
988: 1a000003 bne 99c <ath_cmn_process_fft+0x248>
98c: e59d2020 ldr r2, [sp, #32]
990: e2425002 sub r5, r2, #2
994: e0844005 add r4, r4, r5
998: e2842001 add r2, r4, #1
99c: e1a04002 mov r4, r2
9a0: e59d2014 ldr r2, [sp, #20]
9a4: e1540002 cmp r4, r2
9a8: aa000037 bge a8c <ath_cmn_process_fft+0x338>
9ac: e59d2010 ldr r2, [sp, #16]
9b0: e152000a cmp r2, sl
9b4: e7d62004 ldrb r2, [r6, r4]
9b8: daffffce ble 8f8 <ath_cmn_process_fft+0x1a4>
9bc: e3520007 cmp r2, #7
9c0: e2855001 add r5, r5, #1
9c4: e086b004 add fp, r6, r4
9c8: 8a000002 bhi 9d8 <ath_cmn_process_fft+0x284>
9cc: e59d202c ldr r2, [sp, #44] ; 0x2c
9d0: e1550002 cmp r5, r2
9d4: aaffffcf bge 918 <ath_cmn_process_fft+0x1c4>
9d8: e3590000 cmp r9, #0
9dc: 0affffed beq 998 <ath_cmn_process_fft+0x244>
9e0: e59d201c ldr r2, [sp, #28]
9e4: e1520005 cmp r2, r5
9e8: 1affffe1 bne 974 <ath_cmn_process_fft+0x220>
9ec: ea00007e b bec <ath_cmn_process_fft+0x498>
9f0: e597e000 ldr lr, [r7]
9f4: e24b201f sub r2, fp, #31
9f8: e597c004 ldr ip, [r7, #4]
9fc: e2871021 add r1, r7, #33 ; 0x21
a00: e5973008 ldr r3, [r7, #8]
a04: e28d0068 add r0, sp, #104 ; 0x68
a08: e58de049 str lr, [sp, #73] ; 0x49
a0c: e58dc04d str ip, [sp, #77] ; 0x4d
a10: e597e010 ldr lr, [r7, #16]
a14: e597c014 ldr ip, [r7, #20]
a18: e58d3051 str r3, [sp, #81] ; 0x51
a1c: e597300c ldr r3, [r7, #12]
a20: e58de059 str lr, [sp, #89] ; 0x59
a24: e58dc05d str ip, [sp, #93] ; 0x5d
a28: e58d3055 str r3, [sp, #85] ; 0x55
a2c: e1d7c1bc ldrh ip, [r7, #28]
a30: e5973018 ldr r3, [r7, #24]
a34: e5d7e01f ldrb lr, [r7, #31]
a38: e1cdc6b5 strh ip, [sp, #101] ; 0x65
a3c: e58d3061 str r3, [sp, #97] ; 0x61
a40: e5cde067 strb lr, [sp, #103] ; 0x67
a44: ebfffffe bl 0 <memcpy>
a48: e59d3038 ldr r3, [sp, #56] ; 0x38
a4c: e59d1024 ldr r1, [sp, #36] ; 0x24
a50: e59d0018 ldr r0, [sp, #24]
a54: e58d300c str r3, [sp, #12]
a58: e59d3030 ldr r3, [sp, #48] ; 0x30
a5c: e58d3008 str r3, [sp, #8]
a60: e1cd2fd8 ldrd r2, [sp, #248] ; 0xf8
a64: e1cd20f0 strd r2, [sp]
a68: e28d2049 add r2, sp, #73 ; 0x49
a6c: e59d3034 ldr r3, [sp, #52] ; 0x34
a70: e12fff33 blx r3
a74: e3a01087 mov r1, #135 ; 0x87
a78: e28d0049 add r0, sp, #73 ; 0x49
a7c: ebfffffe bl 0 <__memzero>
a80: e59d1020 ldr r1, [sp, #32]
a84: e28d0049 add r0, sp, #73 ; 0x49
a88: ebfffffe bl 0 <add_device_randomness>
a8c: e3a00001 mov r0, #1
a90: e28dd0d4 add sp, sp, #212 ; 0xd4
a94: e8bd8ff0 pop {r4, r5, r6, r7, r8, r9, sl, fp, pc}
a98: e58d3038 str r3, [sp, #56] ; 0x38
a9c: e3003000 movw r3, #0
aa0: e3002000 movw r2, #0
aa4: e3403000 movt r3, #0
aa8: e3402000 movt r2, #0
aac: e58d3034 str r3, [sp, #52] ; 0x34
ab0: e3a0b03c mov fp, #60 ; 0x3c
ab4: e3a03038 mov r3, #56 ; 0x38
ab8: e58d2044 str r2, [sp, #68] ; 0x44
abc: e3a0a03f mov sl, #63 ; 0x3f
ac0: e58d3020 str r3, [sp, #32]
ac4: eaffff7a b 8b4 <ath_cmn_process_fft+0x160>
ac8: e59db01c ldr fp, [sp, #28]
acc: e153000b cmp r3, fp
ad0: 0a00005e beq c50 <ath_cmn_process_fft+0x4fc>
ad4: e06b5005 rsb r5, fp, r5
ad8: e2855001 add r5, r5, #1
adc: e3550003 cmp r5, #3
ae0: 979ff105 ldrls pc, [pc, r5, lsl #2]
ae4: eaffffd7 b a48 <ath_cmn_process_fft+0x2f4>
ae8: 00000b0c andeq r0, r0, ip, lsl #22
aec: 00000af8 strdeq r0, [r0], -r8
af0: 00000b20 andeq r0, r0, r0, lsr #22
af4: 000009f0 strdeq r0, [r0], -r0 ; <UNPREDICTABLE>
af8: e1a0200b mov r2, fp
afc: e1a01007 mov r1, r7
b00: e28d0049 add r0, sp, #73 ; 0x49
b04: ebfffffe bl 0 <memcpy>
b08: eaffffce b a48 <ath_cmn_process_fft+0x2f4>
b0c: e24b2001 sub r2, fp, #1
b10: e1a01007 mov r1, r7
b14: e28d004a add r0, sp, #74 ; 0x4a
b18: ebfffffe bl 0 <memcpy>
b1c: eaffffc9 b a48 <ath_cmn_process_fft+0x2f4>
b20: e597e000 ldr lr, [r7]
b24: e24b2020 sub r2, fp, #32
b28: e597c004 ldr ip, [r7, #4]
b2c: e2871021 add r1, r7, #33 ; 0x21
b30: e5973008 ldr r3, [r7, #8]
b34: e28d0069 add r0, sp, #105 ; 0x69
b38: e58de04a str lr, [sp, #74] ; 0x4a
b3c: e58dc04e str ip, [sp, #78] ; 0x4e
b40: e597e010 ldr lr, [r7, #16]
b44: e597c014 ldr ip, [r7, #20]
b48: e58d3052 str r3, [sp, #82] ; 0x52
b4c: e597300c ldr r3, [r7, #12]
b50: e58de05a str lr, [sp, #90] ; 0x5a
b54: e58dc05e str ip, [sp, #94] ; 0x5e
b58: e5d7e01f ldrb lr, [r7, #31]
b5c: e1d7c1bc ldrh ip, [r7, #28]
b60: e58d3056 str r3, [sp, #86] ; 0x56
b64: e5973018 ldr r3, [r7, #24]
b68: e1cdc6b6 strh ip, [sp, #102] ; 0x66
b6c: e5cde068 strb lr, [sp, #104] ; 0x68
b70: e58d3062 str r3, [sp, #98] ; 0x62
b74: ebfffffe bl 0 <memcpy>
b78: eaffffb2 b a48 <ath_cmn_process_fft+0x2f4>
b7c: e58d3040 str r3, [sp, #64] ; 0x40
b80: e1a01004 mov r1, r4
b84: e59d3044 ldr r3, [sp, #68] ; 0x44
b88: e1a0000b mov r0, fp
b8c: e58d203c str r2, [sp, #60] ; 0x3c
b90: e12fff33 blx r3
b94: e3500000 cmp r0, #0
b98: e59d203c ldr r2, [sp, #60] ; 0x3c
b9c: e59d3040 ldr r3, [sp, #64] ; 0x40
ba0: 0a00000e beq be0 <ath_cmn_process_fft+0x48c>
ba4: e5d7101f ldrb r1, [r7, #31]
ba8: e5d70020 ldrb r0, [r7, #32]
bac: e59dc01c ldr ip, [sp, #28]
bb0: e15c0005 cmp ip, r5
bb4: d1510000 cmple r1, r0
bb8: 03a01001 moveq r1, #1
bbc: 13a01000 movne r1, #0
bc0: e1520005 cmp r2, r5
bc4: d3a02000 movle r2, #0
bc8: c2012001 andgt r2, r1, #1
bcc: e3520000 cmp r2, #0
bd0: 0a00001a beq c40 <ath_cmn_process_fft+0x4ec>
bd4: e5db2001 ldrb r2, [fp, #1]
bd8: e3520007 cmp r2, #7
bdc: 9affff6d bls 998 <ath_cmn_process_fft+0x244>
be0: e59d201c ldr r2, [sp, #28]
be4: e1520005 cmp r2, r5
be8: 1affff5e bne 968 <ath_cmn_process_fft+0x214>
bec: e58d303c str r3, [sp, #60] ; 0x3c
bf0: e1a02007 mov r2, r7
bf4: e59d3038 ldr r3, [sp, #56] ; 0x38
bf8: e1cd8fd8 ldrd r8, [sp, #248] ; 0xf8
bfc: e59d1024 ldr r1, [sp, #36] ; 0x24
c00: e58d300c str r3, [sp, #12]
c04: e59d3030 ldr r3, [sp, #48] ; 0x30
c08: e1cd80f0 strd r8, [sp]
c0c: e59d0018 ldr r0, [sp, #24]
c10: e58d3008 str r3, [sp, #8]
c14: e59d3034 ldr r3, [sp, #52] ; 0x34
c18: e12fff33 blx r3
c1c: e58d0028 str r0, [sp, #40] ; 0x28
c20: e1a00007 mov r0, r7
c24: e59d1020 ldr r1, [sp, #32]
c28: ebfffffe bl 0 <add_device_randomness>
c2c: e59d3010 ldr r3, [sp, #16]
c30: e153000a cmp r3, sl
c34: e59d303c ldr r3, [sp, #60] ; 0x3c
c38: caffff4d bgt 974 <ath_cmn_process_fft+0x220>
c3c: eaffff92 b a8c <ath_cmn_process_fft+0x338>
c40: e59d202c ldr r2, [sp, #44] ; 0x2c
c44: e1520005 cmp r2, r5
c48: 1affffe4 bne be0 <ath_cmn_process_fft+0x48c>
c4c: eaffffe0 b bd4 <ath_cmn_process_fft+0x480>
c50: e59d3038 ldr r3, [sp, #56] ; 0x38
c54: e59d1024 ldr r1, [sp, #36] ; 0x24
c58: e59d0018 ldr r0, [sp, #24]
c5c: e58d300c str r3, [sp, #12]
c60: e59d3030 ldr r3, [sp, #48] ; 0x30
c64: e58d3008 str r3, [sp, #8]
c68: e1cd2fd8 ldrd r2, [sp, #248] ; 0xf8
c6c: e1cd20f0 strd r2, [sp]
c70: e1a02007 mov r2, r7
c74: e59d3034 ldr r3, [sp, #52] ; 0x34
c78: e12fff33 blx r3
c7c: e1a00007 mov r0, r7
c80: e59d1020 ldr r1, [sp, #32]
c84: ebfffffe bl 0 <add_device_randomness>
c88: e3a00001 mov r0, #1
c8c: eaffff7f b a90 <ath_cmn_process_fft+0x33c>
c90: e59d201c ldr r2, [sp, #28]
c94: e1530002 cmp r3, r2
c98: 0affffd3 beq bec <ath_cmn_process_fft+0x498>
c9c: e59db01c ldr fp, [sp, #28]
ca0: eaffff8b b ad4 <ath_cmn_process_fft+0x380>
ca4: e3000000 movw r0, #0
ca8: e300119a movw r1, #410 ; 0x19a
cac: e3400000 movt r0, #0
cb0: e3a03000 mov r3, #0
cb4: e58d3038 str r3, [sp, #56] ; 0x38
cb8: ebfffffe bl 0 <warn_slowpath_null>
cbc: eaffff76 b a9c <ath_cmn_process_fft+0x348>
cc0: e3a03000 mov r3, #0
cc4: e58d3038 str r3, [sp, #56] ; 0x38
cc8: eaffff73 b a9c <ath_cmn_process_fft+0x348>
^ permalink raw reply
* [Linaro-acpi] [PATCH] PCI: Add information about describing PCI in ACPI
From: Duc Dang @ 2016-11-23 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123123004.GA3642@red-moon>
On Wed, Nov 23, 2016 at 4:30 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On Wed, Nov 23, 2016 at 07:28:12AM +0000, Ard Biesheuvel wrote:
>> On 23 November 2016 at 01:06, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> > On Tue, Nov 22, 2016 at 10:09:50AM +0000, Ard Biesheuvel wrote:
>> >> On 17 November 2016 at 17:59, Bjorn Helgaas <bhelgaas@google.com> wrote:
>> >
>> >> > +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.
>> >>
>> >> Is that universally true? Or is it still possible to do the right
>> >> thing here on new ACPI architectures such as arm64?
>> >
>> > That's a very good question. I had thought that the ACPI spec had
>> > given up on Consumer/Producer completely, but I was wrong. In the 6.0
>> > spec, the Consumer/Producer bit is still documented in the Extended
>> > Address Space Descriptor (sec 6.4.3.5.4). It is documented as
>> > "ignored" in the QWord, DWord, and Word descriptors (sec 6.4.3.5.1,2,3).
>> >
>> > Linux looks at the producer_consumer bit in acpi_decode_space(), which
>> > I think is used for all these descriptors (QWord, DWord, Word, and
>> > Extended). This doesn't quite follow the spec -- we probably should
>> > ignore it except for Extended. In any event, acpi_decode_space() sets
>> > IORESOURCE_WINDOW for Producer descriptors, but we don't test
>> > IORESOURCE_WINDOW in the PCI host bridge code.
>> >
>> > x86 and ia64 supply their own pci_acpi_root_prepare_resources()
>> > functions that call acpi_pci_probe_root_resources(), which parses _CRS
>> > and looks at producer_consumer. Then they do a little arch-specific
>> > stuff on the result.
>> >
>> > On arm64 we use acpi_pci_probe_root_resources() directly, with no
>> > arch-specific stuff.
>> >
>> > On all three arches, we ignore the Consumer/Producer bit, so all the
>> > resources are treated as Producers, e.g., as bridge windows.
>> >
>> > I think we *could* implement an arm64 version of
>> > pci_acpi_root_prepare_resources() that would pay attention to the
>> > Consumer/Producer bit by checking IORESOURCE_WINDOW. To be spec
>> > compliant, we would have to use Extended descriptors for all bridge
>> > windows, even if they would fit in a DWord or QWord.
>> >
>> > Should we do that? I dunno. I'd like to hear your opinion(s).
>> >
>>
>> Yes, I think we should. If the spec allows for a way for a PNP0A03
>> device to describe all of its resources unambiguously, we should not
>> be relying on workarounds that were designed for another architecture
>> in another decade (for, presumably, another OS)
>
> That was the idea I floated at LPC16. We can override the
> acpi_pci_root_ops prepare_resources() function pointer with a function
> that checks IORESOURCE_WINDOW and filters resources accordingly (and
> specific quirk "drivers" may know how to intepret resources that aren't
> IORESOURCE_WINDOW - ie they can use it to describe the PCI ECAM config
> space quirk region in their _CRS).
>
> In a way that's something that makes sense anyway because given
> that we are starting from a clean slate on ARM64 considering resources
> that are not IORESOURCE_WINDOW as host bridge windows is just something
> we are inheriting from x86, it is not really ACPI specs compliant (is
> it ?).
>
>> Just for my understanding, we will need to use extended descriptors
>> for all consumed *and* produced regions, even though dword/qword are
>> implicitly produced-only, due to the fact that the bit is ignored?
>
> That's something that has to be clarified within the ASWG ie why the
> consumer bit is ignored for *some* descriptors and not for others.
>
> As things stand unfortunately the answer seems yes (I do not know
> why).
>
>> > It *would* be nice to have bridge registers in the bridge _CRS. That
>> > would eliminate the need for looking up the HISI0081/PNP0C02 devices
>> > to find the bridge registers. Avoiding that lookup is only a
>> > temporary advantage -- the next round of bridges are supposed to fully
>> > implement ECAM, and then we won't need to know where the registers
>> > are.
>> >
>> > Apart from the lookup, there's still some advantage in describing the
>> > registers in the PNP0A03 device instead of an unrelated PNP0C02
>> > device, because it makes /proc/iomem more accurate and potentially
>> > makes host bridge hotplug cleaner. We would have to enhance the host
>> > bridge driver to do the reservations currently done by pnp/system.c.
>> >
>> > There's some value in doing it the same way as on x86, even though
>> > that way is somewhat broken.
>> >
>> > Whatever we decide, I think it's very important to get it figured out
>> > ASAP because it affects the ECAM quirks that we're trying to merge in
>> > v4.10.
>> >
>>
>> I agree. What exactly is the impact for the quirks mechanism as proposed?
> The impact is that we could just use the PNP0A03 _CRS to report the PCI
> ECAM config space quirk region through a consumer resource keeping in
> mind what I say above (actually I think that's what was done on APM
> firmware initially, for the records).
Just to clarify: APM firmware initially has a _CSR region to declare
the controller register region. We don't know that we need to declare
the reserved space for ECAM until Bjorn pointed out recently (with the
usage of PNP0C02).
I really like this idea about declaring ECAM space and any additional
spaces required for ECAM quirk inside PNP0A03 _CRS. For the firmware
that already shipped, the quirk will need to add additional resources
(for ECAM and other needed regions) into the root-bus. If we decided
to go with this, do we still have time to make additional adjustment
for the current ECAM quirk and the foundation patches before
v4.10-rc1?
>
> Lorenzo
> _______________________________________________
> Linaro-acpi mailing list
> Linaro-acpi at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-acpi
Regards,
Duc Dang.
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123195120.GE14217@n2100.armlinux.org.uk>
Hi Russell,
On Wed, Nov 23, 2016 at 07:51:20PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2016 at 07:15:39PM +0000, Jason Cooper wrote:
> > ------- oops from v4.8.6 #2 ------------------------------------------
> > [42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
> > [42059.311799] pgd = c0004000
> > [42059.314522] [00000020] *pgd=00000000
> > [42059.318162] Internal error: Oops: 17 [#1] SMP ARM
> > [42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
> > [42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
> > [42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
> > [42059.340613] task: c0b091c0 task.stack: c0b00000
> > [42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
> > [42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
> > [42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
> > [42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
> > [42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
> > [42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
> > [42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
>
> Well, the good news is that it's reproducable.
>
> It looks like it could be this:
>
> static int
> ath_cmn_is_fft_buf_full(struct ath_spec_scan_priv *spec_priv)
> {
> for_each_online_cpu(i)
> ret += relay_buf_full(rc->buf[i]);
ahhh, my config has NR_CPUS=4, this SoC is uniprocessor. I'm going to
give it a go with SMP=no. This config is a lightly modified
mvebu_v7_defconfig. However, NR_CPUS isn't set in mvebu_v7_defconfig.
Only in multi_v7_defconfig.
I suspect ath9k uses different logic for setting up the relay buffer(s)
than for the code you referenced.
If SMP=no fails to fail ( :-P ) then we'll know where to start digging.
thx,
Jason.
^ permalink raw reply
* [PATCH 31/31] ARM: dts: r8a7794: Add device node for PRR
From: Simon Horman @ 2016-11-23 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479931686.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7794.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 364b4aa8d1c1..63dc7f29d216 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -1377,6 +1377,11 @@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7794-sysc";
reg = <0 0xe6180000 0 0x0200>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 30/31] ARM: dts: r8a7793: Add device node for PRR
From: Simon Horman @ 2016-11-23 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479931686.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7793.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 629d3d60d1cd..a377dda17724 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -1306,6 +1306,11 @@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7793-sysc";
reg = <0 0xe6180000 0 0x0200>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 29/31] ARM: dts: r8a7792: Add device node for PRR
From: Simon Horman @ 2016-11-23 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479931686.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7792.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index a75e0cd312c5..69789020cf39 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -120,6 +120,11 @@
IRQ_TYPE_LEVEL_LOW)>;
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7792-sysc";
reg = <0 0xe6180000 0 0x0200>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 28/31] ARM: dts: r8a7791: Add device node for PRR
From: Simon Horman @ 2016-11-23 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479931686.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7791.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 091d7fb6ee7d..4c50de2faef1 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1485,6 +1485,11 @@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7791-sysc";
reg = <0 0xe6180000 0 0x0200>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 27/31] ARM: dts: r8a7790: Add device node for PRR
From: Simon Horman @ 2016-11-23 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479931686.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7790.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index a946474be9cf..f554ef3c8096 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1471,6 +1471,11 @@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7790-sysc";
reg = <0 0xe6180000 0 0x0200>;
--
2.7.0.rc3.207.g0ac5344
^ 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