* [PATCH 2/4] ARM: dts: exynos: specify snps, dwmac in compatible string for gmac
From: Niklas Cassel @ 2016-11-23 14:24 UTC (permalink / raw)
To: linux-arm-kernel
From: Niklas Cassel <niklas.cassel@axis.com>
devicetree binding for stmmac states:
- compatible: Should be "snps,dwmac-<ip_version>", "snps,dwmac"
For backwards compatibility: "st,spear600-gmac" is also supported.
No functional change intended.
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
---
arch/arm/boot/dts/exynos5440.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 97c9f0e38526..2a2e570bbee6 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -197,7 +197,7 @@
};
gmac: ethernet at 00230000 {
- compatible = "snps,dwmac-3.70a";
+ compatible = "snps,dwmac-3.70a", "snps,dwmac";
reg = <0x00230000 0x8000>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 31 4>;
--
2.1.4
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: sunxi: enable SDIO Wi-Fi on Orange Pi Zero
From: Chen-Yu Tsai @ 2016-11-23 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123075950.fjtplylunwale6j4@lukather>
On Wed, Nov 23, 2016 at 3:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Tue, Nov 22, 2016 at 12:24:21AM +0800, Icenowy Zheng wrote:
>> There's a Allwinner's XR819 SDIO Wi-Fi module soldered on the board of
>> Orange Pi Zero, which used a dedicated regulator to power.
>>
>> Add the device tree node of the regulator, the enable gpio (with
>> mmc-pwrseq) and the sdio controller.
>>
>> There's a out-of-tree driver tested to work with this device tree.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ---
>> New patch in the patchset, since a out-of-tree working xradio driver is done.
>>
>> If there is any problem in this patch, it can be omitted.
>
> No particular problem with this one, however it can and should be
> merged with the previous one.
>
> Minor comments below though.
>
>>
>> arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 42 ++++++++++++++++++++++++
>> 1 file changed, 42 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> index b428e47..39cac26 100644
>> --- a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> @@ -79,6 +79,24 @@
>> gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
>> };
>> };
>> +
>> + reg_vcc_wifi: reg_vcc_wifi {
>> + compatible = "regulator-fixed";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&vcc_wifi_pin_opi0>;
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-name = "vcc-wifi";
>> + enable-active-high;
>> + gpio = <&pio 0 20 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-simple";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&wifi_pwrseq_pin_opi0>;
>> + reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>;
>> + };
>> };
>>
>> &ehci1 {
>> @@ -95,6 +113,20 @@
>> status = "okay";
>> };
>>
>> +&mmc1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc1_pins_a>;
>> + vmmc-supply = <®_vcc_wifi>;
>> + mmc-pwrseq = <&wifi_pwrseq>;
>> + bus-width = <4>;
>> + non-removable;
>> + status = "okay";
>> +};
>> +
>> +&mmc1_pins_a {
>> + allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>
> This should be bias-pull-up.
IIRC I already added this for _all_ existing mmc pinmux settings?
>
>> +};
>> +
>> &ohci1 {
>> status = "okay";
>> };
>> @@ -104,6 +136,11 @@
>> pins = "PA17";
>> function = "gpio_out";
>> };
>> +
>> + vcc_wifi_pin_opi0: vcc_wifi_pin at 0 {
>> + allwinner,pins = "PA20";
>
> This should be pins
>
>> + allwinner,function = "gpio_out";
>
> This should be function
>
>> + };
>> };
>>
>> &r_pio {
>> @@ -111,6 +148,11 @@
>> pins = "PL10";
>> function = "gpio_out";
>> };
>> +
>> + wifi_pwrseq_pin_opi0: wifi_pwrseq_pin at 0 {
>> + allwinner,pins = "PL7";
>> + allwinner,function = "gpio_out";
>
> And same thing here.
Might we do away with the pinmux for gpio pins tradition?
Recent patches I've sent all omit them.
ChenYu
^ permalink raw reply
* [PATCH 3/3] ARM: dts: sunxi: enable SDIO Wi-Fi on Orange Pi Zero
From: Hans de Goede @ 2016-11-23 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64taF9x9MDYW+KUEEUUoSx0bF68QNc7uZXQoNrsozMGtg@mail.gmail.com>
Hi,
On 23-11-16 15:25, Chen-Yu Tsai wrote:
> On Wed, Nov 23, 2016 at 3:59 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>> Hi,
>>
>> On Tue, Nov 22, 2016 at 12:24:21AM +0800, Icenowy Zheng wrote:
>>> There's a Allwinner's XR819 SDIO Wi-Fi module soldered on the board of
>>> Orange Pi Zero, which used a dedicated regulator to power.
>>>
>>> Add the device tree node of the regulator, the enable gpio (with
>>> mmc-pwrseq) and the sdio controller.
>>>
>>> There's a out-of-tree driver tested to work with this device tree.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>> ---
>>> New patch in the patchset, since a out-of-tree working xradio driver is done.
>>>
>>> If there is any problem in this patch, it can be omitted.
>>
>> No particular problem with this one, however it can and should be
>> merged with the previous one.
>>
>> Minor comments below though.
>>
>>>
>>> arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 42 ++++++++++++++++++++++++
>>> 1 file changed, 42 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>>> index b428e47..39cac26 100644
>>> --- a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>>> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>>> @@ -79,6 +79,24 @@
>>> gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
>>> };
>>> };
>>> +
>>> + reg_vcc_wifi: reg_vcc_wifi {
>>> + compatible = "regulator-fixed";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&vcc_wifi_pin_opi0>;
>>> + regulator-min-microvolt = <3300000>;
>>> + regulator-max-microvolt = <3300000>;
>>> + regulator-name = "vcc-wifi";
>>> + enable-active-high;
>>> + gpio = <&pio 0 20 GPIO_ACTIVE_HIGH>;
>>> + };
>>> +
>>> + wifi_pwrseq: wifi_pwrseq {
>>> + compatible = "mmc-pwrseq-simple";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&wifi_pwrseq_pin_opi0>;
>>> + reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>;
>>> + };
>>> };
>>>
>>> &ehci1 {
>>> @@ -95,6 +113,20 @@
>>> status = "okay";
>>> };
>>>
>>> +&mmc1 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mmc1_pins_a>;
>>> + vmmc-supply = <®_vcc_wifi>;
>>> + mmc-pwrseq = <&wifi_pwrseq>;
>>> + bus-width = <4>;
>>> + non-removable;
>>> + status = "okay";
>>> +};
>>> +
>>> +&mmc1_pins_a {
>>> + allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>>
>> This should be bias-pull-up.
>
> IIRC I already added this for _all_ existing mmc pinmux settings?
>
>>
>>> +};
>>> +
>>> &ohci1 {
>>> status = "okay";
>>> };
>>> @@ -104,6 +136,11 @@
>>> pins = "PA17";
>>> function = "gpio_out";
>>> };
>>> +
>>> + vcc_wifi_pin_opi0: vcc_wifi_pin at 0 {
>>> + allwinner,pins = "PA20";
>>
>> This should be pins
>>
>>> + allwinner,function = "gpio_out";
>>
>> This should be function
>>
>>> + };
>>> };
>>>
>>> &r_pio {
>>> @@ -111,6 +148,11 @@
>>> pins = "PL10";
>>> function = "gpio_out";
>>> };
>>> +
>>> + wifi_pwrseq_pin_opi0: wifi_pwrseq_pin at 0 {
>>> + allwinner,pins = "PL7";
>>> + allwinner,function = "gpio_out";
>>
>> And same thing here.
>
> Might we do away with the pinmux for gpio pins tradition?
> Recent patches I've sent all omit them.
I'm in favor of doing away with them, except there were
we need to configure bias / strength.
Regards,
Hans
^ permalink raw reply
* [PATCH 0/3] arm64: dts: r8a7796: Add CAN/CAN FD support
From: Simon Horman @ 2016-11-23 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f358442c-8373-328c-1270-709498c133f5@pengutronix.de>
On Wed, Nov 23, 2016 at 02:18:13PM +0100, Marc Kleine-Budde wrote:
> On 11/23/2016 01:14 PM, Chris Paterson wrote:
> > This patch series adds CAN and CAN FD support to the r8a7796.
> >
> > Based on renesas-devel-20161122-v4.9-rc6.
> >
> > Chris Paterson (3):
> > arm64: dts: r8a7796: Add CAN external clock support
> > arm64: dts: r8a7796: Add CAN support
> > arm64: dts: r8a7796: Add CAN FD support
> >
> > .../devicetree/bindings/net/can/rcar_can.txt | 12 +++--
> > .../devicetree/bindings/net/can/rcar_canfd.txt | 12 +++--
> > arch/arm64/boot/dts/renesas/r8a7796.dtsi | 61 ++++++++++++++++++++++
> > 3 files changed, 75 insertions(+), 10 deletions(-)
>
> For all three:
>
> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
>
> Who takes this series?
I would like to see these patches split up so that the
.../devicetree/bindings/ portions can go through you whole
the arch/arm64/boot/dts/renesas/ portions go thorugh my renesas tree.
Regarding the arch/arm64/boot/dts/renesas/ portion, I would like
some consideration given to what effect enabling memory above 4Gb
(64bit addressing) would have.
^ permalink raw reply
* [PATCH 0/3] arm64: dts: r8a7796: Add CAN/CAN FD support
From: Marc Kleine-Budde @ 2016-11-23 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123142938.GF9057@verge.net.au>
On 11/23/2016 03:29 PM, Simon Horman wrote:
> On Wed, Nov 23, 2016 at 02:18:13PM +0100, Marc Kleine-Budde wrote:
>> On 11/23/2016 01:14 PM, Chris Paterson wrote:
>>> This patch series adds CAN and CAN FD support to the r8a7796.
>>>
>>> Based on renesas-devel-20161122-v4.9-rc6.
>>>
>>> Chris Paterson (3):
>>> arm64: dts: r8a7796: Add CAN external clock support
>>> arm64: dts: r8a7796: Add CAN support
>>> arm64: dts: r8a7796: Add CAN FD support
>>>
>>> .../devicetree/bindings/net/can/rcar_can.txt | 12 +++--
>>> .../devicetree/bindings/net/can/rcar_canfd.txt | 12 +++--
>>> arch/arm64/boot/dts/renesas/r8a7796.dtsi | 61 ++++++++++++++++++++++
>>> 3 files changed, 75 insertions(+), 10 deletions(-)
>>
>> For all three:
>>
>> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
>>
>> Who takes this series?
>
> I would like to see these patches split up so that the
> .../devicetree/bindings/ portions can go through you whole
> the arch/arm64/boot/dts/renesas/ portions go thorugh my renesas tree.
Ok
> Regarding the arch/arm64/boot/dts/renesas/ portion, I would like
> some consideration given to what effect enabling memory above 4Gb
> (64bit addressing) would have.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161123/803507ec/attachment.sig>
^ permalink raw reply
* [PATCH] arm: perf: use builtin_platform_driver
From: Geliang Tang @ 2016-11-23 14:39 UTC (permalink / raw)
To: linux-arm-kernel
Use builtin_platform_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
arch/arm/kernel/perf_event_v6.c | 6 +-----
arch/arm/kernel/perf_event_v7.c | 6 +-----
arch/arm/kernel/perf_event_xscale.c | 6 +-----
3 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
index 09413e7..96b7a47 100644
--- a/arch/arm/kernel/perf_event_v6.c
+++ b/arch/arm/kernel/perf_event_v6.c
@@ -581,9 +581,5 @@ static struct platform_driver armv6_pmu_driver = {
.probe = armv6_pmu_device_probe,
};
-static int __init register_armv6_pmu_driver(void)
-{
- return platform_driver_register(&armv6_pmu_driver);
-}
-device_initcall(register_armv6_pmu_driver);
+builtin_platform_driver(armv6_pmu_driver);
#endif /* CONFIG_CPU_V6 || CONFIG_CPU_V6K */
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index b942349..ab6522b 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -2034,9 +2034,5 @@ static struct platform_driver armv7_pmu_driver = {
.probe = armv7_pmu_device_probe,
};
-static int __init register_armv7_pmu_driver(void)
-{
- return platform_driver_register(&armv7_pmu_driver);
-}
-device_initcall(register_armv7_pmu_driver);
+builtin_platform_driver(armv7_pmu_driver);
#endif /* CONFIG_CPU_V7 */
diff --git a/arch/arm/kernel/perf_event_xscale.c b/arch/arm/kernel/perf_event_xscale.c
index aa0499e..0e51f5e 100644
--- a/arch/arm/kernel/perf_event_xscale.c
+++ b/arch/arm/kernel/perf_event_xscale.c
@@ -767,9 +767,5 @@ static struct platform_driver xscale_pmu_driver = {
.probe = xscale_pmu_device_probe,
};
-static int __init register_xscale_pmu_driver(void)
-{
- return platform_driver_register(&xscale_pmu_driver);
-}
-device_initcall(register_xscale_pmu_driver);
+builtin_platform_driver(xscale_pmu_driver);
#endif /* CONFIG_CPU_XSCALE */
--
2.9.3
^ permalink raw reply related
* [PATCH] arm64: defconfig: Do not lower CONFIG_LOG_BUF_SHIFT
From: Catalin Marinas @ 2016-11-23 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479908176-13625-1-git-send-email-geert+renesas@glider.be>
On Wed, Nov 23, 2016 at 02:36:16PM +0100, Geert Uytterhoeven wrote:
> The default value of 17 for CONFIG_LOG_BUF_SHIFT is much more suitable
> than 14. The latter easily leads to lost kernel messages on systems with
> only one CPU core.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> arch/arm64/configs/defconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 0e41290f6cbb4101..f284568373adf917 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -11,7 +11,6 @@ CONFIG_TASK_XACCT=y
> CONFIG_TASK_IO_ACCOUNTING=y
> CONFIG_IKCONFIG=y
> CONFIG_IKCONFIG_PROC=y
> -CONFIG_LOG_BUF_SHIFT=14
> CONFIG_MEMCG=y
> CONFIG_MEMCG_SWAP=y
> CONFIG_BLK_CGROUP=y
The defconfig updates usually go via arm-soc. The patch looks fine to
me:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Andrew Lunn @ 2016-11-23 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479851991.26813.2@smtp.gmail.com>
> >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?
> 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.
Andrew
^ permalink raw reply
* [PATCH] soc/fsl/qe: use builtin_platform_driver
From: Geliang Tang @ 2016-11-23 15:04 UTC (permalink / raw)
To: linux-arm-kernel
Use builtin_platform_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
drivers/soc/fsl/qe/qe.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 2707a82..ade168f 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -717,9 +717,5 @@ static struct platform_driver qe_driver = {
.resume = qe_resume,
};
-static int __init qe_drv_init(void)
-{
- return platform_driver_register(&qe_driver);
-}
-device_initcall(qe_drv_init);
+builtin_platform_driver(qe_driver);
#endif /* defined(CONFIG_SUSPEND) && defined(CONFIG_PPC_85xx) */
--
2.9.3
^ permalink raw reply related
* [PATCH] PCI: Add information about describing PCI in ACPI
From: Bjorn Helgaas @ 2016-11-23 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-TW__+eZFS2p=1ZLN7fBs7pqQ+SitbEX46Z4JiS64egA@mail.gmail.com>
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)
>
> 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?
>From an ACPI spec point of view, I would say QWord/DWord/Word
descriptors are implicitly *consumer*-only because ResourceConsumer
is the default and they don't have a bit to indicate otherwise.
The current code assumes all PNP0A03 resources are producers. If we
implement an arm64 pci_acpi_root_prepare_resources() that pays
attention to the Consumer/Producer bit, we would have to:
- Reserve all producer regions in the iomem/ioport trees. This is
already done via pci_acpi_root_add_resources(), but we might need
a new check to handle consumers differently.
- Reserve all consumer regions. This corresponds to what
pnp/system.c does for PNP0C02 devices. This is similar to the
producer regions, but I think the consumer ones should be marked
IORESOURCE_BUSY.
- Use every producer (IORESOURCE_WINDOW) as a host bridge window.
I think it's a bug that acpi_decode_space() looks at producer_consumer
for QWord/DWord/Word descriptors, but I think QWord/DWord/Word
descriptors for consumed regions should be safe, as long as they don't
set the Consumer/Producer bit.
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-11-23 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2359248.XjnRfPbj1B@wuerfel>
Hi Arnd
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 23 November 2016 14:16
> To: Gabriele Paoloni
> Cc: linux-arm-kernel at lists.infradead.org; mark.rutland at arm.com;
> benh at kernel.crashing.org; catalin.marinas at arm.com; liviu.dudau at arm.com;
> Linuxarm; lorenzo.pieralisi at arm.com; xuwei (O); Jason Gunthorpe; linux-
> serial at vger.kernel.org; linux-pci at vger.kernel.org;
> devicetree at vger.kernel.org; minyard at acm.org; will.deacon at arm.com; John
> Garry; zourongrong at gmail.com; robh+dt at kernel.org; bhelgaas at go og
> le.com; kantyzc at 163.com; zhichang.yuan02 at gmail.com; T homas Petazzoni;
> linux-kernel at vger.kernel.org; Yuanzhichang; olof at lixom.net
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Friday, November 18, 2016 5:03:11 PM CET Gabriele Paoloni wrote:
> > > On Friday, November 18, 2016 4:18:07 PM CET Gabriele Paoloni wrote:
> > > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > > > On Friday, November 18, 2016 12:53:08 PM CET Gabriele Paoloni
> > > wrote:
> > > > > For the ISA/LPC spaces there are only 4k of addresses, they
> > > > > the bus addresses always overlap, but we can trivially
> > > > > figure out the bus address from Linux I/O port number
> > > > > by subtracting the start of the range.
> > > >
> > > > Are you saying that our LPC controller should specify a
> > > > range property to map bus addresses into a cpu address range?
> > >
> > > No. There is not CPU address associated with it, because it's
> > > not memory mapped.
> > >
> > > Instead, we need to associate a bus address with a logical
> > > Linux port number, both in of_address_to_resource and
> > > in inb()/outb().
> >
> > I think this is effectively what we are doing so far with patch 2/3.
> > The problem with this patch is that we are carving out a "forbidden"
> > IO tokens range that goes from 0 to PCIBIOS_MIN_IO.
> >
> > I think that the proper solution would be to have the LPC driver to
> > set the carveout threshold used in pci_register_io_range(),
> > pci_pio_to_address(), pci_address_to_pio(), but this would impose
> > a probe dependency on the LPC itself that should be probed before
> > the PCI controller (or before any other devices calling these
> > functions...)
>
> Why do you think the order matters? My point was that we should
> be able to register any region of logical port numbers for any
> bus here.
Maybe I have not followed well so let's roll back to your previous
comment...
"we need to associate a bus address with a logical Linux port number,
both in of_address_to_resource and in inb()/outb()"
Actually of_address_to_resource() returns the port number to used
in inb/outb(); inb() and outb() add the port number to PCI_IOBASE
to rd/wr to the right virtual address.
Our LPC cannot operate on the virtual address and it operates on
a bus address range that for LPC is also equal to the cpu address
range and goes from 0 to 0x1000.
Now as I understand it is risky and not appropriate to reserve
the logical port numbers from 0 to 0x1000 or to whatever other
upper bound because existing systems may rely on these port numbers
retrieved by __of_address_to_resource().
In this scenario I think the best thing to do would be
in the probe function of the LPC driver:
1) call pci_register_io_range() passing [0, 0x1000] (that is the
range for LPC)
2) retrieve the logical port numbers associated to the LPC range
by calling pci_address_to_pio() for 0 and 0x1000 and assign
them to extio_ops_node->start and extio_ops_node->end
3) implement the LPC accessors to operate on the logical ports
associated to the LPC range (in practice in the accessors
implementation we will call pci_pio_to_address to retrieve
the cpu address to operate on)
What do you think?
Thanks
Gab
>
>
> > > > > > To be honest with you I would keep things simple for this
> > > > > > LPC and introduce more complex reworks later if more devices
> > > > > > need to be introduced.
> > > > > >
> > > > > > What if we stick on a single domain now where we introduce a
> > > > > > reserved threshold for the IO space (say INDIRECT_MAX_IO).
> > > > >
> > > > > I said having a single domain is fine, but I still don't
> > > > > like the idea of reserving low port numbers for this hack,
> > > > > it would mean that the numbers change for everyone else.
> > > >
> > > > I don't get this much...I/O tokens that are passed to the I/O
> > > > accessors are not fixed anyway and they vary depending on the
> order
> > > > of adding ranges to io_range_list...so I don't see a big issue
> > > > with this...
> > >
> > > On machines with a legacy devices behind the PCI bridge,
> > > there may still be a reason to have the low I/O port range
> > > reserved for the primary bus, e.g. to get a VGA text console
> > > to work.
> > >
> > > On powerpc, this is called the "primary" PCI host, i.e. the
> > > only one that is allowed to have an ISA bridge.
> >
> > Yes but
> > 1) isn't the PCI controller range property that defines how IO bus
> address
> > map into physical CPU addresses?
>
> Correct, but the DT knows nothing about logical port numbers in Linux.
>
> > 2) How can you guarantee that the cpu range associated with this
> > IO bus range is the first to be registered in
> pci_register_io_range()?
> > ( i.e. are you saying that they are just relying on the fact that
> it is the
> > only IO range in the system and by chance the IO tokens and
> corresponding
> > bus addresses are the same? )
>
> To clarify: the special properties of having the first 0x1000 logical
> port numbers go to a particular physical bus are very obscure. I think
> it's more important to not change the behavior for existing systems
> that might rely on it than for new systems that have no such legacy.
>
> The ipmi and uart drivers in particular will get the port numbers
> filled
> in their platform device from the DT bus scanning, so they don't care
> at all about having the same numeric value for port numbers on the bus
> and logical numbers, but other drivers might rely on particular ports
> to be mapped on a specific PCI host, especially when those drivers
> are used only on systems that don't have more than one PCI domain.
>
> Arnd
^ permalink raw reply
* [PATCH 2/4] ARM: dts: davinci: da850: add VPIF
From: Kevin Hilman @ 2016-11-23 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d4e696d1-f9b2-665c-c44f-c661856c5098@ti.com>
Sekhar Nori <nsekhar@ti.com> writes:
> On Wednesday 23 November 2016 11:13 AM, Kevin Hilman wrote:
>> David Lechner <david@lechnology.com> writes:
>>
>>> On 11/22/2016 01:45 PM, Kevin Hilman wrote:
>>>> Add VPIF and VPIF capture nodes to da850. VPIF capture has two input
>>>> channels describe using the standard DT ports and enpoints.
>>>>
>>>> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>>>> ---
>>>> arch/arm/boot/dts/da850.dtsi | 28 ++++++++++++++++++++++++++++
>>>> 1 file changed, 28 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>>> index 6205917b4f59..e05e2bb834e8 100644
>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>> @@ -453,7 +453,35 @@
>>>> interrupts = <52>;
>>>> status = "disabled";
>>>> };
>>>> +
>>>> + vpif: video at 0x00217000 {
>>>
>>> Should be @217000
>>>
>>>> + compatible = "ti,da850-vpif";
>>>> + reg = <0x00217000 0x1000>;
>>>
>>> Could omit leading 0's to be consistent with existing entries.
>>>
>>> reg = <0x217000 0x1000>;
>>
>> Ugh, yeah. I hate that convention, but better to be consistent, I guess.
>>
>>>> + status = "disabled";
>>>> + };
>>>> +
>>>> + vpif_capture: video-capture at 0x00217000 {
>>>
>>> Again, @217000. But it seems odd to have two device nodes with the
>>> same address. Is enabling these mutually exclusive?
>>
>> They're not mutually exclusive because the vpif is the one that actually
>> maps the register range (since it's shared between vpif_display and
>> vpif_capture) so I guess I should just drop the reg property from the
>> vpif_capture node.
>
> Reading the documentation, VPIF is presented as a single device, with
> two channels dedicated to display and two for capture. Most of the
> channel registers are independent, but there are are some like interrupt
> enable which are common for all channels. So I believe we cannot use
> simple-mfd. But I believe VPIF display and capture should be subdevices
> of a single VPIF device.
OK, I can give it a try that way.
> It should look something like this, I think:
>
> vpif: video at 217000 {
> compatible = "ti,da850-vpif";
> reg = <0x217000 0x1000>;
> interrupts = <92>;
> status = "disabled";
>
> vpif_capture: video-capture {
> compatible = "ti,da850-vpif-capture"
> port {
> vpif_ch0: endpoint at 0 {
> reg = <0>;
> bus-width = <8>;
> };
>
> vpif_ch1: endpoint at 1 {
> reg = <1>;
> bus-width = <8>;
> data-shift = <8>;
> };
> };
> };
>
> vpif_display: video-display {
> compatible = "ti,da850-vpif-display"
> port {
> vpif_ch2: endpoint at 2 {
> reg = <2>;
> bus-width = <8>;
> data-shift = <16>;
> };
>
> vpif_ch3: endpoint at 3 {
> reg = <3>;
> bus-width = <8>;
> data-shift = <24>;
> };
> };
> };
> };
> The interrupt too, seems to be common interrupt for both display and
> capture. So, it should not be under the capture node.
Possibly. That will require reworking of the way the driver works
today, since the vpif driver doesn't request interrupts, but the capture
and display drivers both register interrupts, one per channel. I'll
have a closer look.
> BTW, I am sure
> what exactly data-shift is used for. It does not seem to be used in the
> driver patches too. I just extrapolated the values based on the pattern
> I saw.
For video out, the way I read the spec, and based on the schematics,
there appears to be a separate 16-bit parallel bus, so the data-shift on
the video-display endpoints should probably be zero and 16 like for
catpure. Anyways, I'll get to that when I get to the display part.
Kevin
^ permalink raw reply
* [PATCH] ARM: dts: am335x-baltos: use phy-phandle declarations
From: Tony Lindgren @ 2016-11-23 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479894757-32736-1-git-send-email-yegorslists@googlemail.com>
* yegorslists at googlemail.com <yegorslists@googlemail.com> [161123 01:53]:
> From: Yegor Yefremov <yegorslists@googlemail.com>
Description missing? Something like "do so and so because of" :)
Regards
Tony
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Afzal Mohammed @ 2016-11-23 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <583478FB.4020008@arm.com>
Hi,
On Tue, Nov 22, 2016 at 04:57:31PM +0000, Vladimir Murzin wrote:
> I used defconfigs
Which defconfig was used ?
multi_v7_defconfig, MMU & SMP disabled - thus spake the compiler,
kernel/built-in.o: In function `kimage_free_entry':
memremap.c:(.text+0x4dafc): undefined reference to
`arch_phys_to_idmap_offset'
memremap.c:(.text+0x4db04): undefined reference to
`arch_phys_to_idmap_offset'
kernel/built-in.o: In function `kimage_alloc_page':
memremap.c:(.text+0x4dbc0): undefined reference to
`arch_phys_to_idmap_offset'
memremap.c:(.text+0x4dbc8): undefined reference to
`arch_phys_to_idmap_offset'
memremap.c:(.text+0x4dc1c): undefined reference to
`arch_phys_to_idmap_offset'
kernel/built-in.o:memremap.c:(.text+0x4dc30): more undefined
references to `arch_phys_to_idmap_offset' follow
multi_v7_defconfig & MMU disabled, stderr was more verbose and was
unhappy with Kconfig dependencies,
warning: (SOC_IMX31 && SOC_IMX35 && SOC_VF610 && REALVIEW_DT) selects
SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL &&
MMU)
warning: (SOC_IMX31 && SOC_IMX35 && SOC_VF610 && REALVIEW_DT) selects
SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL &&
MMU)
Ulterior motive here is to try !MMU on Cortex A
Regards
afzal
^ permalink raw reply
* [PATCH v2] ARM: dts: am335x-baltos: use phy-phandle declarations
From: yegorslists at googlemail.com @ 2016-11-23 15:49 UTC (permalink / raw)
To: linux-arm-kernel
From: Yegor Yefremov <yegorslists@googlemail.com>
phy-phandle is now a preferred method to reference a PHY device.
Especially in regards to cpsw it enables PHY specific settings like
max-speed etc. being specified in DTS.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
Changes:
v2: add patch description (Tony Lindgren)
arch/arm/boot/dts/am335x-baltos-ir2110.dts | 10 ++++++++--
arch/arm/boot/dts/am335x-baltos-ir3220.dts | 2 +-
arch/arm/boot/dts/am335x-baltos-ir5221.dts | 2 +-
arch/arm/boot/dts/am335x-baltos.dtsi | 5 ++++-
4 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-baltos-ir2110.dts b/arch/arm/boot/dts/am335x-baltos-ir2110.dts
index a9a9730..501c752 100644
--- a/arch/arm/boot/dts/am335x-baltos-ir2110.dts
+++ b/arch/arm/boot/dts/am335x-baltos-ir2110.dts
@@ -54,16 +54,22 @@
dr_mode = "host";
};
+&davinci_mdio {
+ phy0: ethernet-phy at 0 {
+ reg = <1>;
+ };
+};
+
&cpsw_emac0 {
- phy_id = <&davinci_mdio>, <1>;
phy-mode = "rmii";
dual_emac_res_vlan = <1>;
+ phy-handle = <&phy0>;
};
&cpsw_emac1 {
- phy_id = <&davinci_mdio>, <7>;
phy-mode = "rgmii-txid";
dual_emac_res_vlan = <2>;
+ phy-handle = <&phy1>;
};
&phy_sel {
diff --git a/arch/arm/boot/dts/am335x-baltos-ir3220.dts b/arch/arm/boot/dts/am335x-baltos-ir3220.dts
index fe002a1..19f53b8 100644
--- a/arch/arm/boot/dts/am335x-baltos-ir3220.dts
+++ b/arch/arm/boot/dts/am335x-baltos-ir3220.dts
@@ -109,9 +109,9 @@
};
&cpsw_emac1 {
- phy_id = <&davinci_mdio>, <7>;
phy-mode = "rgmii-txid";
dual_emac_res_vlan = <2>;
+ phy-handle = <&phy1>;
};
&phy_sel {
diff --git a/arch/arm/boot/dts/am335x-baltos-ir5221.dts b/arch/arm/boot/dts/am335x-baltos-ir5221.dts
index f599350..2b9d7f4 100644
--- a/arch/arm/boot/dts/am335x-baltos-ir5221.dts
+++ b/arch/arm/boot/dts/am335x-baltos-ir5221.dts
@@ -127,9 +127,9 @@
};
&cpsw_emac1 {
- phy_id = <&davinci_mdio>, <7>;
phy-mode = "rgmii-txid";
dual_emac_res_vlan = <2>;
+ phy-handle = <&phy1>;
};
&phy_sel {
diff --git a/arch/arm/boot/dts/am335x-baltos.dtsi b/arch/arm/boot/dts/am335x-baltos.dtsi
index 09b9541..efb5eae 100644
--- a/arch/arm/boot/dts/am335x-baltos.dtsi
+++ b/arch/arm/boot/dts/am335x-baltos.dtsi
@@ -364,11 +364,14 @@
};
&davinci_mdio {
+ status = "okay";
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
- status = "okay";
+ phy1: ethernet-phy at 1 {
+ reg = <7>;
+ };
};
&mmc1 {
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 03/11] ARM: omap: do not select HIGHMEM explicitly
From: Tony Lindgren @ 2016-11-23 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122095136.GU1041@n2100.armlinux.org.uk>
* Russell King - ARM Linux <linux@armlinux.org.uk> [161122 01:51]:
> On Tue, Nov 22, 2016 at 09:26:00AM +0000, Vladimir Murzin wrote:
> > Explicit selection of HIGHMEM breaks NOMMU builds. It seems that
> > HIGHMEM is user selectable option, so probably it would be better to
> > let user to make a decision on this options or, at least, move it to
> > defconfig.
>
> That's kind of the point of ARCH_OMAP2PLUS_TYPICAL - it's a user
> option to let the user select a range of options for typical OMAP2+
> configurations, so that the user doesn't have to dig around looking
> for multiple options, some of which are hard requirements for OMAP
> to be functional. OMAP is a particularly difficult case because the
> hardware tends to be very complex.
>
> However, HIGHMEM should never be a requirement to boot, so this looks
> sane.
Yeah we can add that to the defconfig:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Tony Lindgren @ 2016-11-23 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <583478FB.4020008@arm.com>
* Vladimir Murzin <vladimir.murzin@arm.com> [161122 08:57]:
> On 22/11/16 10:17, Arnd Bergmann wrote:
> > Another question is what architecture levels and what platforms
> > we want to support without MMU. The only ARMv4/v5 platform we
> > still have that can actually use NOMMU cores is Integrator
> > with its ARM7TDMI, ARM920T and ARM966E core tiles (and possibly
> > others I couldn't immediately find). Do we actually care about
> > them any more now that all the NOMMU world is ARMv7-M? Are
> > there any benefits in running an ARM920T or ARM926E core
> > with MMU disabled, and does this work with your patches?
> >
>
> I don't have such hardware, so I can't acctually test it - it is why "there is
> no guaranty" :( OTOH, if sombody has these platforms these pathces is a good
> start to try NOMMU.
I believe the reason to run them without MMU might be still
valid if we ever get mainline Linux kernel working on some
3G/LTE modems for latency reasons. Not that I know of any
use cases, but if we have it working we might as well keep
it working.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 1/2] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-23 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCAbUK-6uLc_ceJ5d-oD4N_HGz9rbtCvivTp1N8OOVBNBg@mail.gmail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> On Tue, Nov 22, 2016 at 11:00 AM, Neil Armstrong
> <narmstrong@baylibre.com> wrote:
>> Following the Amlogic Linux kernel, it seem the only differences
>> between the GXL and GXM SoCs are the CPU Clusters.
>>
>> This commit renames the gxl-s905d-p23x DTSI in a common file for
>> S905D p23x and S912 q20x boards.
>>
>> Then adds a meson-gxm dtsi and reproduce the P23x to Q20x boards
>> dts files since the S905D and S912 SoCs shares the same pinout
>> and the P23x and Q20x boards are identical.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>
> I have tested this successfully on a Mecool BB2 (similar to the Q200
> reference board).
Thanks for testing (and reporting),
Kevin
^ permalink raw reply
* [PATCH net-next 1/4] net: mvneta: Convert to be 64 bits compatible
From: Marcin Wojtas @ 2016-11-23 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mvgqmjiy.fsf@free-electrons.com>
Hi Gregory,
2016-11-23 14:07 GMT+01:00 Gregory CLEMENT <gregory.clement@free-electrons.com>:
> Hi Jisheng, Arnd,
>
>
> Thanks for your feedback.
>
>
> On mer., nov. 23 2016, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Wednesday, November 23, 2016 5:53:41 PM CET Jisheng Zhang wrote:
>>> On Tue, 22 Nov 2016 22:04:12 +0100 Arnd Bergmann wrote:
>>>
>>> > On Tuesday, November 22, 2016 5:48:41 PM CET Gregory CLEMENT wrote:
>>> > > +#ifdef CONFIG_64BIT
>>> > > + void *data_tmp;
>>> > > +
>>> > > + /* In Neta HW only 32 bits data is supported, so in order to
>>> > > + * obtain whole 64 bits address from RX descriptor, we store
>>> > > + * the upper 32 bits when allocating buffer, and put it back
>>> > > + * when using buffer cookie for accessing packet in memory.
>>> > > + * Frags should be allocated from single 'memory' region,
>>> > > + * hence common upper address half should be sufficient.
>>> > > + */
>>> > > + data_tmp = mvneta_frag_alloc(pp->frag_size);
>>> > > + if (data_tmp) {
>>> > > + pp->data_high = (u64)upper_32_bits((u64)data_tmp) << 32;
>>> > > + mvneta_frag_free(pp->frag_size, data_tmp);
>>> > > + }
>>> > >
>>> >
>>> > How does this work when the region spans a n*4GB address boundary?
>>>
>>> indeed. We also make use of this driver on 64bit platforms. We use
>>> different solution to make the driver 64bit safe.
>>>
>>> solA: make use of the reserved field in the mvneta_rx_desc, such
>>> as reserved2 etc. Yes, the field is marked as "for future use, PnC", but
>>> now it's not used at all. This is one possible solution however.
>>
>> Right, this sounds like the most straightforward choice.
>
> The PnC (which stands for Parsing and Classification) is not used yet
> indeed but this field will be needed when we will enable it. It is
> something we want to do but it is not planned in a near future. However
> from the datasheets I have it seems only present on the Armada XP. It is
> not mentioned on datasheets for the Armada 38x or the Armada 3700.
>
It is not mentioned in A38x spec, but this SoC has exactly the same
PnC as Armada XP (they differ only with used SRAM details). I wouldn't
be surprised if it was supported on A3700 as well.
> That would mean it was safe to use on of this field in 64-bits mode on
> the Armada 3700.
>
> So I am going to take this approach.
>
I think for now it's safe and is much easier than handling extra
software ring for virtual addresses.
Best regards,
Marcin
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Vladimir Murzin @ 2016-11-23 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123154829.GA2489@afzalpc>
On 23/11/16 15:48, Afzal Mohammed wrote:
> Hi,
>
> On Tue, Nov 22, 2016 at 04:57:31PM +0000, Vladimir Murzin wrote:
>
>> I used defconfigs
>
> Which defconfig was used ?
>
I had a script to traverse config directory, but seems that I messed
things up.
Now I'm running allmodconfig per Arnd suggestion.
> multi_v7_defconfig, MMU & SMP disabled - thus spake the compiler,
>
> kernel/built-in.o: In function `kimage_free_entry':
> memremap.c:(.text+0x4dafc): undefined reference to
> `arch_phys_to_idmap_offset'
> memremap.c:(.text+0x4db04): undefined reference to
> `arch_phys_to_idmap_offset'
> kernel/built-in.o: In function `kimage_alloc_page':
> memremap.c:(.text+0x4dbc0): undefined reference to
> `arch_phys_to_idmap_offset'
> memremap.c:(.text+0x4dbc8): undefined reference to
> `arch_phys_to_idmap_offset'
> memremap.c:(.text+0x4dc1c): undefined reference to
> `arch_phys_to_idmap_offset'
> kernel/built-in.o:memremap.c:(.text+0x4dc30): more undefined
> references to `arch_phys_to_idmap_offset' follow
I think this one is fixed by
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 8e7496c..c3349b9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2019,7 +2019,7 @@ config XIP_PHYS_ADDR
config KEXEC
bool "Kexec system call (EXPERIMENTAL)"
depends on (!SMP || PM_SLEEP_SMP)
- depends on !CPU_V7M
+ depends on MMU
select KEXEC_CORE
help
kexec is a system call that implements the ability to shutdown your
but there are others I'm working on.
>
> multi_v7_defconfig & MMU disabled, stderr was more verbose and was
> unhappy with Kconfig dependencies,
>
> warning: (SOC_IMX31 && SOC_IMX35 && SOC_VF610 && REALVIEW_DT) selects
> SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL &&
> MMU)
> warning: (SOC_IMX31 && SOC_IMX35 && SOC_VF610 && REALVIEW_DT) selects
> SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL &&
> MMU)
These we fixed in 9001214 ("ARM: imx: no need to select SMP_ON_UP explicitly")
>
> Ulterior motive here is to try !MMU on Cortex A
>
Thanks for trying it. Just a gentle remainder not to forget to set DRAM_BASE
and DRAM_SIZE ;)
> Regards
> afzal
>
^ permalink raw reply related
* [RFC PATCH 03/11] ARM: omap: do not select HIGHMEM explicitly
From: Vladimir Murzin @ 2016-11-23 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123154957.GD4082@atomide.com>
On 23/11/16 15:49, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [161122 01:51]:
>> On Tue, Nov 22, 2016 at 09:26:00AM +0000, Vladimir Murzin wrote:
>>> Explicit selection of HIGHMEM breaks NOMMU builds. It seems that
>>> HIGHMEM is user selectable option, so probably it would be better to
>>> let user to make a decision on this options or, at least, move it to
>>> defconfig.
>>
>> That's kind of the point of ARCH_OMAP2PLUS_TYPICAL - it's a user
>> option to let the user select a range of options for typical OMAP2+
>> configurations, so that the user doesn't have to dig around looking
>> for multiple options, some of which are hard requirements for OMAP
>> to be functional. OMAP is a particularly difficult case because the
>> hardware tends to be very complex.
>>
>> However, HIGHMEM should never be a requirement to boot, so this looks
>> sane.
>
> Yeah we can add that to the defconfig:
>
> Acked-by: Tony Lindgren <tony@atomide.com>
>
Thanks!
Vladimir
^ permalink raw reply
* [PATCH v2] ARM: dts: am335x-baltos: use phy-phandle declarations
From: Tony Lindgren @ 2016-11-23 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479916166-6633-1-git-send-email-yegorslists@googlemail.com>
* yegorslists at googlemail.com <yegorslists@googlemail.com> [161123 07:49]:
> From: Yegor Yefremov <yegorslists@googlemail.com>
>
> phy-phandle is now a preferred method to reference a PHY device.
> Especially in regards to cpsw it enables PHY specific settings like
> max-speed etc. being specified in DTS.
Applying into omap-for-v4.10/dt thanks.
Tony
^ permalink raw reply
* reboot fails on at91sam9g20 with kernel 4.x
From: Alexander Dahl @ 2016-11-23 16:13 UTC (permalink / raw)
To: linux-arm-kernel
Hei hei,
while upgrading a at91sam9g20 based board to a recent kernel I stumbled
over a problem I can not solve by myself. We have a board which is more
or less a stripped down version of the at91sam9g20ek. The kernels I was
trying lately with a custom DT were 3.14.79, 3.18.44 (didn't work),
4.4.32, 4.8.6 and 4.9-rc6+. The rootfs is built with
OSELAS.Toolchain-2014.12.2, ptxdist 2016.11.0, gcc 4.9.2, glibc 2.20,
busybox v1.24.2 and it's on a UBIFS on NAND flash.
The following happens if I try to reboot a 4.x kernel from console:
The system is going down NOW!
Sent SIGTERM to all processes
macb fffc4000.ethernet eth0: link down
Requesting system reboot
reboot: Restarting system
Reboot failed -- System halted
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.
Greets
Alex
^ permalink raw reply
* [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: David Lechner @ 2016-11-23 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJVqog0Fno_DO0NQKmVNvzu5d=3GOLk145wBmB-V70BLeg@mail.gmail.com>
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. 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.
>
> Best regards,
> Bartosz Golaszewski
>
> [1] https://www.spinics.net/lists/arm-kernel/msg539638.html
> [2] http://www.spinics.net/lists/devicetree/msg148575.html
> [3] http://www.spinics.net/lists/devicetree/msg148667.html
> [4] http://www.spinics.net/lists/devicetree/msg148655.html
>
^ permalink raw reply
* [PATCH 0/2] minor GXL and GXM improvements
From: Martin Blumenstingl @ 2016-11-23 16:20 UTC (permalink / raw)
To: linux-arm-kernel
This series adds SCPI support to GXL and GXM SoCs by moving the nodes
to meson-gx.dtsi. Additionally this updates the compatible string to
match the recent changes, see [0]
Now that we have SCPI support for GXM we can also use it to configure
the CPU cores using the SCPI DVFS clocks.
[0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001632.html
Martin Blumenstingl (2):
ARM64: dts: meson-gx: move the SCPI and SRAM nodes to meson-gx
ARM64: dts: meson-gxm: add SCPI configuration for GXM
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 45 +++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 57 -----------------------------
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 9 +++++
3 files changed, 54 insertions(+), 57 deletions(-)
--
2.10.2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox