* [PATCH v3 00/19] ARM: dts: aspeed: updates and new machines
From: Joel Stanley @ 2017-12-20 3:23 UTC (permalink / raw)
To: linux-arm-kernel
This series of device tree patches for the ASPEED BMC machines
moves all systems to use the soon to be merged clk driver, and
updates machines to use all of the drivers we have upstream.
v3: Address review from Rob and Cedric
- Move aspeed-gpio.h usage out into the patches where use of the GPIO
is added
- Clarify that the aspeed-clock.h patch will be merged as part of
the device tree tree. This is to ensure we don't depend on the clk
tree for building.
- Fix duplicate flash controller nodes in Romulus
v2: Address review from Arnd
- Remove NUM_CLKS from dt header
- Send VUART patch as a fix, drop it from this series
- Add reasoning for breaking old kernel in the 'proper clock
references' patch
In addition it adds three new OpenBMC systems that have been developed
in the OpenBMC kernel tree over the past year: two Power9 OpenPower
systems, and a port by Google to a Quanta x86 server.
I have boot tested these on Romulus and Palmetto, as well as boot tested
all device trees in Qemu.
Please review the boards you are familiar with. I will merge these in to
the ASPEED ARM SoC tree for inclusion in 4.16.
Andrew Jeffery (1):
ARM: dts: aspeed: Add LPC and child devices
Joel Stanley (16):
dt-bindings: clock: Add ASPEED constants
dt-bindings: gpio: Add ASPEED constants
ARM: dts: aspeed: Add proper clock references
ARM: dts: aspeed: Add MAC clocks
ARM: dts: aspeed: Add watchdog clocks
ARM: dts: aspeed: Add flash controller clocks
ARM: dts: aspeed: Add clock phandle to GPIO
ARM: dts: aspeed: Add PWM and tachometer node
ARM: dts: aspeed: Add LPC Snoop device
ARM: dts: aspeed: Remove skeleton.dtsi
ARM: dts: aspeed: Update license headers
ARM: dts: Add OpenBMC flash layout
ARM: dts: aspeed: Sort ASPEED entries in makefile
ARM: dts: aspeed: Add Witherspoon BMC machine
ARM: dts: aspeed-romulus: Update Romulus system
ARM: dts: aspeed-plametto: Add flash layout
Rick Altherr (1):
ARM: dts: aspeed: Add Qanta Q71L BMC machine
Xo Wang (1):
ARM: dts: aspeed: Add Ingrasys Zaius BMC machine
arch/arm/boot/dts/Makefile | 8 +-
arch/arm/boot/dts/aspeed-ast2500-evb.dts | 2 +-
arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 3 +-
arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 157 ++++++-
arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts | 548 +++++++++++++++++++++++
arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 426 ++++++++++++++++++
arch/arm/boot/dts/aspeed-bmc-quanta-q71l.dts | 458 +++++++++++++++++++
arch/arm/boot/dts/aspeed-g4.dtsi | 163 ++++---
arch/arm/boot/dts/aspeed-g5.dtsi | 154 ++++---
arch/arm/boot/dts/openbmc-flash-layout.dtsi | 32 ++
include/dt-bindings/clock/aspeed-clock.h | 52 +++
include/dt-bindings/gpio/aspeed-gpio.h | 49 ++
12 files changed, 1905 insertions(+), 147 deletions(-)
create mode 100644 arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
create mode 100644 arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
create mode 100644 arch/arm/boot/dts/aspeed-bmc-quanta-q71l.dts
create mode 100644 arch/arm/boot/dts/openbmc-flash-layout.dtsi
create mode 100644 include/dt-bindings/clock/aspeed-clock.h
create mode 100644 include/dt-bindings/gpio/aspeed-gpio.h
--
2.15.1
^ permalink raw reply
* [PATCH v2 18/19] ARM: dts: aspeed-romulus: Update Romulus system
From: Joel Stanley @ 2017-12-20 3:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b8e80861-88c4-da87-a201-ca2eefaa5a94@kaod.org>
On Mon, Dec 18, 2017 at 8:02 PM, C?dric Le Goater <clg@kaod.org> wrote:
>> +};
>> +
>> +&fmc {
>> + status = "okay";
>> +
>> + flash at 0 {
>> + status = "okay";
>> + label = "pnor";
>> + m25p,fast-read;
>> +#include "openbmc-flash-layout.dtsi"
>> + };
>> +};
>> +
>> +&spi1 {
>> + status = "okay";
>> +
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_spi1_default>;
>> +
>> + flash at 0 {
>> + status = "okay";
>> + label = "pnor";
>> + m25p,fast-read;
>> };
>> };
>
>
> hmm, the fmc and spi1 bindings were already added in commit 1142aea9ff9d.
>
>
>> @@ -38,6 +101,7 @@
>> status = "okay";
>> m25p,fast-read;
>> label = "bmc";
>> +#include "openbmc-flash-layout.dtsi"
>
>
> This looks like an extra "fmc" node ?
You're right. It still built and booted too. Good catch.
Cheers,
Joel
^ permalink raw reply
* [PATCH v2 03/19] ARM: dts: aspeed: Add LPC and child devices
From: Joel Stanley @ 2017-12-20 3:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f08188a0-a6dd-a445-340c-eee1ca335865@kaod.org>
j
On Mon, Dec 18, 2017 at 7:55 PM, C?dric Le Goater <clg@kaod.org> wrote:
> On 12/15/2017 07:24 AM, Joel Stanley wrote:
>> From: Andrew Jeffery <andrew@aj.id.au>
>>
>> Ensure the ordering is correct and add all of the children in the SoC
>> device trees for the ast2400 and ast2500.
>>
>> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>> ---
>> arch/arm/boot/dts/aspeed-g4.dtsi | 35 +++++++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/aspeed-g5.dtsi | 27 +++++++++++++++++----------
>> 2 files changed, 52 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
>> index 100d092e6c07..a3bc5da7d42c 100644
>> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
>> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
>> @@ -226,6 +226,41 @@
>> status = "disabled";
>> };
>>
>> + lpc: lpc at 1e789000 {
>> + compatible = "aspeed,ast2400-lpc", "simple-mfd";
>> + reg = <0x1e789000 0x1000>;
>> +
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x1e789000 0x1000>;
>> +
>> + lpc_bmc: lpc-bmc at 0 {
>> + compatible = "aspeed,ast2400-lpc-bmc";
>> + reg = <0x0 0x80>;
>> + };
>> +
>> + lpc_host: lpc-host at 80 {
>> + compatible = "aspeed,ast2400-lpc-host", "simple-mfd", "syscon";
>> + reg = <0x80 0x1e0>;
>> + reg-io-width = <4>;
>> +
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x80 0x1e0>;
>> +
>> + lpc_ctrl: lpc-ctrl at 0 {
>> + compatible = "aspeed,ast2400-lpc-ctrl";
>> + reg = <0x0 0x80>;
>> + status = "disabled";
>> + };
>> +
>> + lhc: lhc at 20 {
>> + compatible = "aspeed,ast2500-lhc";
>
> aspeed,ast2400-lhc
>
> The layout of the registers are the same but there a couple of differences
> in the bit definitions between the two SoCs.
>
> a part from that :
>
> Reviewed-by: C?dric Le Goater <clg@kaod.org>
Good catch. Fixed in v3.
Cheers,
Joel
^ permalink raw reply
* [PATCH v2 10/19] ARM: dts: aspeed: Add LPC Snoop device
From: Joel Stanley @ 2017-12-20 3:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c5ef27de-34c1-f5e9-e4ae-e2709b004677@kaod.org>
On Mon, Dec 18, 2017 at 7:46 PM, C?dric Le Goater <clg@kaod.org> wrote:
> On 12/15/2017 07:24 AM, Joel Stanley wrote:
>> LPC snoop hardware on the ASPEED BMC, used for monitoring
>> host I/O port activity.
>>
>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>> ---
>> arch/arm/boot/dts/aspeed-g4.dtsi | 7 +++++++
>> arch/arm/boot/dts/aspeed-g5.dtsi | 6 ++++++
>> 2 files changed, 13 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
>> index f6fee40c04c0..b3580f37f507 100644
>> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
>> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
>> @@ -236,6 +236,13 @@
>> status = "disabled";
>> };
>>
>> + lpc_snoop: lpc-snoop at 0 {
>> + compatible = "aspeed,ast2500-lpc-snoop";
>
> it should be :
>
> aspeed,ast2400-lpc-snoop
>
> a part from that :
>
> Reviewed-by: C?dric Le Goater <clg@kaod.org>
Fixed in v3.
Cheers,
Joel
^ permalink raw reply
* [PATCH] PCI: Mediatek: clear irq status after irq dispathed to avoid reentry
From: Ryder Lee @ 2017-12-20 3:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513738334-26213-1-git-send-email-honghui.zhang@mediatek.com>
On Wed, 2017-12-20 at 10:52 +0800, honghui.zhang at mediatek.com wrote:
> From: Honghui Zhang <honghui.zhang@mediatek.com>
>
> There maybe a same irq reentry scenario after irq received in current
> irq handle flow:
> EP device PCIe host driver EP driver
> 1. issue an irq
> 2. received irq
> 3. clear irq status
> 4. dispatch irq
> 5. clear irq source
> The irq status was not successfully cleared at step 2 since the irq
> source was not cleared yet. So the PCIe host driver may receive the
> same irq after step 5. Then there's an irq reentry occurred.
> Even worse, if the reentry irq was not an irq that EP driver expected,
> it may not handle the irq. Then we may run into the dead loop from
> step 2 to step 4.
> Clear the irq status after irq have been dispatched to avoid the irq
> reentry.
>
> Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
> ---
> drivers/pci/host/pcie-mediatek.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> index db93efd..3248771 100644
> --- a/drivers/pci/host/pcie-mediatek.c
> +++ b/drivers/pci/host/pcie-mediatek.c
> @@ -605,11 +605,11 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
>
> while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
> for_each_set_bit_from(bit, &status, PCI_NUM_INTX + INTX_SHIFT) {
> - /* Clear the INTx */
> - writel(1 << bit, port->base + PCIE_INT_STATUS);
> virq = irq_find_mapping(port->irq_domain,
> bit - INTX_SHIFT);
> generic_handle_irq(virq);
> + /* Clear the INTx */
> + writel(1 << bit, port->base + PCIE_INT_STATUS);
> }
> }
>
> @@ -619,10 +619,10 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
>
> while ((imsi_status = readl(port->base + PCIE_IMSI_STATUS))) {
> for_each_set_bit(bit, &imsi_status, MTK_MSI_IRQS_NUM) {
> - /* Clear the MSI */
> - writel(1 << bit, port->base + PCIE_IMSI_STATUS);
> virq = irq_find_mapping(port->msi_domain, bit);
> generic_handle_irq(virq);
> + /* Clear the MSI */
> + writel(1 << bit, port->base + PCIE_IMSI_STATUS);
> }
> }
> /* Clear MSI interrupt status */
Acked-by: Ryder Lee <ryder.lee@mediatek.com>
Thanks.
^ permalink raw reply
* [PATCH v2] arm64: dts: ls1088a: Add USB support
From: Shawn Guo @ 2017-12-20 2:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <VI1PR04MB1262C44016CE4ECB8902E7E7E9330@VI1PR04MB1262.eurprd04.prod.outlook.com>
On Thu, Dec 07, 2017 at 07:33:28AM +0000, Yinbo Zhu wrote:
> Hi shawn guo,
>
> If my patch has no other issue,
> Can you help me push it to upstream.
Are you talking about v4 patch? First of all, I cannot find v4 in
my mailbox. That said, it seems you did not send the patch to me.
Secondly, by checking the patch on patchwork, the usb nodes in
fsl-ls1088a-rdb.dts do not sorted alphabetically in label name.
Shawn
^ permalink raw reply
* [PATCH] PCI: Mediatek: clear irq status after irq dispathed to avoid reentry
From: honghui.zhang at mediatek.com @ 2017-12-20 2:52 UTC (permalink / raw)
To: linux-arm-kernel
From: Honghui Zhang <honghui.zhang@mediatek.com>
There maybe a same irq reentry scenario after irq received in current
irq handle flow:
EP device PCIe host driver EP driver
1. issue an irq
2. received irq
3. clear irq status
4. dispatch irq
5. clear irq source
The irq status was not successfully cleared at step 2 since the irq
source was not cleared yet. So the PCIe host driver may receive the
same irq after step 5. Then there's an irq reentry occurred.
Even worse, if the reentry irq was not an irq that EP driver expected,
it may not handle the irq. Then we may run into the dead loop from
step 2 to step 4.
Clear the irq status after irq have been dispatched to avoid the irq
reentry.
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
---
drivers/pci/host/pcie-mediatek.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index db93efd..3248771 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -605,11 +605,11 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
for_each_set_bit_from(bit, &status, PCI_NUM_INTX + INTX_SHIFT) {
- /* Clear the INTx */
- writel(1 << bit, port->base + PCIE_INT_STATUS);
virq = irq_find_mapping(port->irq_domain,
bit - INTX_SHIFT);
generic_handle_irq(virq);
+ /* Clear the INTx */
+ writel(1 << bit, port->base + PCIE_INT_STATUS);
}
}
@@ -619,10 +619,10 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
while ((imsi_status = readl(port->base + PCIE_IMSI_STATUS))) {
for_each_set_bit(bit, &imsi_status, MTK_MSI_IRQS_NUM) {
- /* Clear the MSI */
- writel(1 << bit, port->base + PCIE_IMSI_STATUS);
virq = irq_find_mapping(port->msi_domain, bit);
generic_handle_irq(virq);
+ /* Clear the MSI */
+ writel(1 << bit, port->base + PCIE_IMSI_STATUS);
}
}
/* Clear MSI interrupt status */
--
2.6.4
^ permalink raw reply related
* [v7, 3/3] ARM: dts: imx6qdl.dtsi/imx6ul.dtsi: add "fsl, imx6q-snvs-lpgpr" node
From: Shawn Guo @ 2017-12-20 2:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cfd53377-437a-98d3-1a0e-1123495a35ee@maciej.szmigiero.name>
On Mon, Dec 11, 2017 at 11:31:52PM +0100, Maciej S. Szmigiero wrote:
> On 20.06.2017 09:09, Oleksij Rempel wrote:
> > This node is for Low Power General Purpose Register which can
> > be used as Non-Volatile Storage.
> >
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> > ---
> > arch/arm/boot/dts/imx6qdl.dtsi | 4 ++++
> > arch/arm/boot/dts/imx6ul.dtsi | 4 ++++
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> > index e426faa9c243..94e992558238 100644
> (..)
>
> FYI: It looks to me that while the driver itself from this series was
> picked up and eventually reached Linus' tree this DT change was
> forgotten, since I can't find in any tree (or am I not looking at the
> right place?).
Thanks for reminding. I just updated the subject as below and applied
the patch.
ARM: dts: imx6: add snvs-lpgpr node
Shawn
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Stephen Boyd @ 2017-12-20 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <735d4316-9b18-2903-aabd-46ead1db5233@codeaurora.org>
On 12/19, Timur Tabi wrote:
> On 12/18/2017 08:39 PM, Stephen Boyd wrote:
> >+ if (gpios && gpios[j] != i)
> >+ continue;
> ...
> > + j++;
>
> Doesn't this assume that the available GPIOs are listed in numerical
> order in the ACPI table? If so, then this patch won't work because
> that order is not guaranteed.
>
Yes, I added a comment in the patch about that assumption. It's
simple enough to sort the array in place with sort() though.
I was looking at the gpiochip_add_pin_ranges() code to try and
understand how to only expose pins that are supported as gpios
into gpiolib, and then I looked at the history of these patches
and wrote some code around pin ranges, got super confused and
started thinking about adding gpiochips for each range (ugh),
talked to Bjorn, and now I'm writing this mail. The approach of
multiple ranges or chips looks like a dead-end that you've
already gone down so let's not do that.
The thing that I don't like about this patch is that we're
modifying npins to indicate what gpios are available or not and
then having a huge diff in this patch to do the 's/i/gpio/'.
Ideally, everything would flow directly from the request callback
and the SoC specific pinctrl driver would just tell the core code
what all pins exist in hardware even if they're locked away and
in use by something non-linux. That way, we don't have to rejig
things in the SoC specific driver when the system configuration
changes. I'm hoping we can do the valid mask part generically in
the core pinctrl-msm.c file once so that things aren't spread
around the SoC specific drivers and we solve ACPI and DT at the
same time.
We will want irq lines to be unallocated for things that aren't
GPIOs, I'm not sure about ACPI and if it cares here, and we have
a one to one mapping between irqs, GPIOs, and pinctrl pins with
this hardware. Furthermore, we have the irq_valid_mask support in
place already, so it seems that we can at least use the mask to
be the one place where we indicate which pins are allowed to be
used. And it seems like the simplest solution is to set the irq
valid mask to be the GPIOs from the device property and then test
that bitmask in the pinmux_ops structure's request callback so we
cover both gpio (via the gpiochip_generic_request() ->
pinmux_request_gpio() -> pin_request() path) and pinctrl (via the
pin_request() path). Debugfs will need to test the mask too, but
that should be simple. I believe you don't care about pin muxing,
but it would make things work in both cases and will help if we
want to limit access on platforms that use pin muxing.
Let's resolve this by the end of this week. If this plan works we
can have the revert patch for get_direction() and the
pinctrl-msm.c patch to update the valid mask on gpiochip
registration.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v4 1/3] dt-bindings: mailbox: Introduce Hi3660 controller binding
From: Leo Yan @ 2017-12-20 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219233038.mjkqakshn7ud7ise@rob-hp-laptop>
On Tue, Dec 19, 2017 at 05:30:38PM -0600, Rob Herring wrote:
> On Tue, Dec 19, 2017 at 07:15:43PM +0800, Kaihua Zhong wrote:
> > From: Leo Yan <leo.yan@linaro.org>
> >
> > Introduce a binding for the Hi3660 mailbox controller, the mailbox is
> > used within application processor (AP), communication processor (CP),
> > HIFI and MCU, etc.
> >
> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > ---
> > .../bindings/mailbox/hisilicon,hi3660-mailbox.txt | 51 ++++++++++++++++++++++
> > 1 file changed, 51 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi3660-mailbox.txt
>
> Please add acks when posting new versions.
Thanks, Rob.
This is my bad :) and will add acks in later version.
Thanks,
Leo Yan
^ permalink raw reply
* [PATCH v2] IPI performance benchmark
From: Andrew Morton @ 2017-12-19 23:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219085010.4081-1-ynorov@caviumnetworks.com>
On Tue, 19 Dec 2017 11:50:10 +0300 Yury Norov <ynorov@caviumnetworks.com> wrote:
> This benchmark sends many IPIs in different modes and measures
> time for IPI delivery (first column), and total time, ie including
> time to acknowledge the receive by sender (second column).
>
> The scenarios are:
> Dry-run: do everything except actually sending IPI. Useful
> to estimate system overhead.
> Self-IPI: Send IPI to self CPU.
> Normal IPI: Send IPI to some other CPU.
> Broadcast IPI: Send broadcast IPI to all online CPUs.
> Broadcast lock: Send broadcast IPI to all online CPUs and force them
> acquire/release spinlock.
>
> The raw output looks like this:
> [ 155.363374] Dry-run: 0, 2999696 ns
> [ 155.429162] Self-IPI: 30385328, 65589392 ns
> [ 156.060821] Normal IPI: 566914128, 631453008 ns
> [ 158.384427] Broadcast IPI: 0, 2323368720 ns
> [ 160.831850] Broadcast lock: 0, 2447000544 ns
>
> For virtualized guests, sending and reveiving IPIs causes guest exit.
> I used this test to measure performance impact on KVM subsystem of
> Christoffer Dall's series "Optimize KVM/ARM for VHE systems" [1].
>
> Test machine is ThunderX2, 112 online CPUs. Below the results normalized
> to host dry-run time, broadcast lock results omitted. Smaller - better.
>
> Host, v4.14:
> Dry-run: 0 1
> Self-IPI: 9 18
> Normal IPI: 81 110
> Broadcast IPI: 0 2106
>
> Guest, v4.14:
> Dry-run: 0 1
> Self-IPI: 10 18
> Normal IPI: 305 525
> Broadcast IPI: 0 9729
>
> Guest, v4.14 + [1]:
> Dry-run: 0 1
> Self-IPI: 9 18
> Normal IPI: 176 343
> Broadcast IPI: 0 9885
>
That looks handy. Peter and Ingo might be interested.
I wonder if it should be in kernel/. Perhaps it's better to accumulate
these things in lib/test_*.c, rather than cluttering up other top-level
directories.
> +static ktime_t __init send_ipi(int flags)
> +{
> + ktime_t time = 0;
> + DEFINE_SPINLOCK(lock);
I have some vague historical memory that an on-stack spinlock can cause
problems, perhaps with debugging code. Can't remember, maybe I dreamed it.
^ permalink raw reply
* [PATCH v4 1/3] dt-bindings: mailbox: Introduce Hi3660 controller binding
From: Rob Herring @ 2017-12-19 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513682145-19892-2-git-send-email-zhongkaihua@huawei.com>
On Tue, Dec 19, 2017 at 07:15:43PM +0800, Kaihua Zhong wrote:
> From: Leo Yan <leo.yan@linaro.org>
>
> Introduce a binding for the Hi3660 mailbox controller, the mailbox is
> used within application processor (AP), communication processor (CP),
> HIFI and MCU, etc.
>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
> .../bindings/mailbox/hisilicon,hi3660-mailbox.txt | 51 ++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi3660-mailbox.txt
Please add acks when posting new versions.
^ permalink raw reply
* [PATCH 1/9] ARM: enable secure platform-only erratas
From: Russell King - ARM Linux @ 2017-12-19 23:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bdff72b9-8ebd-a426-b27b-fe055d45cfb1@gmail.com>
On Thu, Oct 05, 2017 at 09:16:12PM +0300, Dmitry Osipenko wrote:
> On 20.07.2017 03:29, Micha? Miros?aw wrote:
> > Allow secure-only erratas to be used in multiarch kernel.
> >
> > Signed-off-by: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
> > ---
> > arch/arm/Kconfig | 20 ++++++++++++++------
> > 1 file changed, 14 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index a208bfe367b5..a1eff866550b 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -696,6 +696,14 @@ config ARCH_MULTI_CPU_AUTO
> >
> > endmenu
> >
> > +config ARCH_ASSUME_SECURE_PLATFORM
> > + bool "Enable ERRATAs using secure-only registers"
> > + default !ARCH_MULTIPLATFORM
>
> I think default should always be "Yes" and this option shouldn't affect
> multiplatform kernels. So a multiplatform kernel wouldn't be an option
> for your device.
No, that changes the current behaviour.
Current behaviour is for the secure-only errata to be disabled when the
multi-platform option is enabled, because multi-platform kernels have to
be able to run in the non-secure world. Defaulting this option to "yes"
means that these errata become visible.
I have to wonder why you need this though - your patches seem to be
targetting a platform that runs in non-secure world, and enabling these
errata would make the kernel non-bootable on your platform.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 7/9] ARM: tegra: enable cache via TF
From: Russell King - ARM Linux @ 2017-12-19 23:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6a164b2270a3e996c083e94bf5b1e27028c1135e.1500510157.git.mirq-linux@rere.qmqm.pl>
On Thu, Jul 20, 2017 at 02:29:25AM +0200, Micha? Miros?aw wrote:
> diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
> index 805f306fa6f7..aae7f5961563 100644
> --- a/arch/arm/mach-tegra/reset-handler.S
> +++ b/arch/arm/mach-tegra/reset-handler.S
> @@ -78,8 +78,20 @@ ENTRY(tegra_resume)
> orr r1, r1, #1
> str r1, [r0]
> #endif
> +#ifdef CONFIG_TRUSTED_FOUNDATIONS
> + adr r3, __tegra_smc_stack
> + stmia r3, {r4-r12, sp, lr}
>
> -#ifdef CONFIG_CACHE_L2X0
> + mov r0, #3 // local wake
> + mov r3, #0
> + mov r4, #0
> + dsb
> + .arch_extension sec
> + smc #0
> +
> + adr r3, __tegra_smc_stack
> + ldmia r3, {r4-r12, sp, pc}
You don't want to jump to the 'lr' value previously stacked here. I
also wonder whether you need all this stacking, or whether you're
just doing it because you don't know whether its necessary. From
what I can see, the only register that this code cares about is r8,
although it would be wise to place a comment in the code if the smc
call corrupts the other registers.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 1/3] dt-bindings: chosen: Add clocksource and clockevent selection
From: Rob Herring @ 2017-12-19 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8fe1dce0-3fd2-d740-8456-bf3b734e571a@ti.com>
On Fri, Dec 15, 2017 at 7:57 PM, Grygorii Strashko
<grygorii.strashko@ti.com> wrote:
>
>
> On 12/13/2017 12:53 PM, Alexandre Belloni wrote:
>> The clocksource and clockevent timer are probed early in the boot process.
>> At that time it is difficult for linux to know whether a particular timer
>> can be used as the clocksource or the clockevent or by another driver,
>> especially when they are all identical or have similar features.
>>
>> Until now, multiple strategies have been used to solve that:
>> - use Kconfig option as MXC_USE_EPIT or ATMEL_TCB_CLKSRC_BLOCK
>> - use a kernel parameter as the "clocksource" early_param in mach-omap2
>> - registering the first seen timer as a clockevent and the second one as
>> a clocksource as in rk_timer_init or dw_apb_timer_init
>>
>> Add a linux,clocksource and a linux,clockevent node in chosen with a timer
>> property pointing to the timer to use. Other properties, like the targeted
>> precision may be added later.
>>
>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>> ---
>> Documentation/devicetree/bindings/chosen.txt | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
>> index e3b13ea7d2ae..c7ee3ecb5276 100644
>> --- a/Documentation/devicetree/bindings/chosen.txt
>> +++ b/Documentation/devicetree/bindings/chosen.txt
>> @@ -120,3 +120,23 @@ e.g.
>> While this property does not represent a real hardware, the address
>> and the size are expressed in #address-cells and #size-cells,
>> respectively, of the root node.
>> +
>> +linux,clocksource and linux,clockevent
>> +--------------------------------------
>> +
>> +Those nodes have a timer property. This property is a phandle to the timer to be
>> +chosen as the clocksource or clockevent. This is only useful when the platform
>> +has multiple identical timers and it is not possible to let linux make the
>> +correct choice.
>> +
>> +/ {
>> + chosen {
>> + linux,clocksource {
>> + timer = <&timer0>;
>> + };
>> +
>> + linux,clockevent {
>> + timer = <&timer1>;
>> + };
>> + };
>> +};
>>
>
> It'd be nice if smth. like this will actually happen, as on some OMAP
> platforms can be up to 3-4 alternatives for each clocksource/clockevent and
> different combination need to be selected depending on SoC and platform
> (and sometime - use case) which is pain in multi-platform environment now.
Can we have some concrete examples with why the current selection
logic is broken.
For use-cases, if a board maker can't make that decision, then I think
those should be kernel command-line options (if boot time) or sysfs
controlled.
> But more important note from my side is clocksource and clockevent selections seems
> not enough :( There are also sched clock (sched_clock_register()) and delay_timer
> (register_current_timer_delay() at least on ARM).
> Both above can't be unregistered (at least last time I've checked).
Sounds like an OS problem...
Rob
^ permalink raw reply
* [PATCH 6/9] ARM: init: update secondary_data register documentation
From: Russell King - ARM Linux @ 2017-12-19 23:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a6e5e735ebae32a433e501188a86082efc8b0b52.1500510157.git.mirq-linux@rere.qmqm.pl>
On Thu, Jul 20, 2017 at 02:29:25AM +0200, Micha? Miros?aw wrote:
> Fix secondary_data pointer register and document other
> occurrences in SMP boot code.
>
> Signed-off-by: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
It's probably worth referecing commit 34d926266500 ("[ARM] Fix SMP booting")
since we have it in our history for this.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Marcin Wojtas @ 2017-12-19 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219204614.GA24156@lunn.ch>
Hi Andrew,
2017-12-19 21:46 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
>> Of course! v2 will not have such problem, I've been waiting however
>> for the feedback about the ACPI representation. Anyway, I'm strongly
>> leaning towards using _ADR/_CID objects in PHY's nodes for ACPI, so
>> maybe I'll just issue the v2 in order to push the discussion a bit
>> forward.
>
> Hi Marcin
>
> I know ~0 about ACPI. But what seems to be missing for me is
> documentation. You are defining a ABI here, which all future MDIO
> busses, PHYs, and to some extent Ethernet switches need to follow. So
> i would expect this to be documented somewhere.
As the code derives straight from of_mdio.c, there is absolutely no
deviation from Documentation/devicetree/bindings/net/mdio.txt.
>
> How does documentation work in the ACPI world?
>
ACPI has its own specification, the newest one is 6.2
http://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf
It is pretty likely, that if we establish a generic solution for the
MDIO bus, a short section about it may probably require adding to
above - for now I see none.
Best regards,
Marcin
^ permalink raw reply
* [PATCH v3 4/5] ARM: davinci: convert to common clock framework
From: David Lechner @ 2017-12-19 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b8025b62-c7c0-29f8-388d-d84816adf688@ti.com>
On 12/19/2017 07:47 AM, Sekhar Nori wrote:
> Hi David,
>
> On Saturday 09 December 2017 07:45 AM, David Lechner wrote:
>> This converts the clocks in mach-davinci to the common clock framework.
>>
>> Most of the patch just involves renaming struct clk to struct davinci_clk.
>> There is also a struct clk_hw added to provide the bridge between the
>> existing clock implementation and the common clock framework.
>>
>> The clk_get_parent and clk_set_parent callbacks are dropped because all
>> clocks currently (effectivly) have a single parent, in which case the
>> common clock framework does not want you to implement these functions
>> yourself.
>>
>> clk_unregister() is dropped because it is not used anywhere in
>> mach-davinci.
>>
>> EXPORT_SYMBOL() is removed from functions not used outside of mach-davinci.
>>
>> Fixed checkpatch.pl warning about bare use of unsigned in dump_clock().
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>
> The cleanups leading upto this patch look fine, but I am not sure about
> this patch itself. Ideally, we should have moved to drivers/clk also.
> And shared code with keystone too since the PSC and PLL implementations
> of the two architectures are quite similar.
>
> I could think of this as an intermediate step while we get there, but I
> am afraid of the churn that would cause. For example, if we reuse
> keystone driver, we will be using clk_psc and we can get rid of the
> davinci_clk that this patch introduces.
>
> So unless there is big roadblock to moving to drivers/clk, we should
> probably do that in one shot.
>
Yes, this is intended as an intermediate step. My thinking was that it
would be better to do one thing at a time, so if something breaks, it
will be easier to find the problem than if we try to do everything at
once. But, you are right, there will be quite a few extra intermediate
steps required, for example, I have realized that in order to use the
davinci_clk concurrently with other clocks in the common clock
framework, at least the parent pointer and children linked list will
have to be removed, introducing another intermediate step.
While avoiding the davinci_clk step would be ideal, there is quite a bit
that needs to be done first before this will be possible. And the
downside I see to doing it this way is that no one will be able to test
any of the preparatory patches because they depend on the common clock
framework. We won't even be able to compile them until all the pieces
are in place and we can enable the common clock kernel configuration option.
Here is a list of some of the issues I know about so far preventing me
from doing everything at once at this point in time:
* Reentrancy of clk_enable() on non-SMP systems is broken in the common
clock framework [1][2], but this reentrancy is needed for the DA8xx USB
PHY PLL clock [3].
* drivers/remoteproc/da8xx_remoteproc.c calls
davinci_clk_reset_{assert,deassert}() in arch/arm/mach-davinci/clock.c.
This needs to be moved to the PSC driver in drivers/clk. The reset
framework in drivers/reset looks ideal for handling this, but it is
currently device tree only and it looks like we need it to work on
non-device tree boards. So, our options are: to move this hack to the
PSC driver in drivers/clk/ *or* to update the reset framework to work
with non-device tree boards *or* convert all of the mach-davinci boards
to device tree only.
* The device tree bindings for "ti,keystone,psc-clock" are not the best
and I am really not keen on reusing them. What makes sense to me would
be to define a device tree node that represents the entire PSC IP block
with child nodes for each clock output. Something like this:
power-controller at 2350000 {
compatible = "ti,davinci-psc";
reg = <0x2350000 0xb00>;
...
clkhyperlink0: clkhyperlink0 {
#clock-cells = <0>;
clock-output-names = "hyperlink-0";
clocks = <&chipclk12>;
power-domain = <5>;
module-domain = <12>;
};
...
};
But the keystone bindings assign the entire PSC register space to each
clock individually (twice). And the really ugly part is that the module
domain and the power domain numbers of each PSC "clock" is embedded in
the register address. So, if you have reg = <0x02350030 0xb00>,
<0x02350014 0x400>; what this really means is that the clock driver will
iomap 0x02350000 (notice the 00 instead of the 30 and 14 at the end of
each register and that the base 0x02350000 is essentially listed twice
with two different sizes) and it means that this particular clock has a
module domain of 12 (0x30 / 4 = 12, 4 comes from the fact these are
32-bit registers) and a power domain of 5 (0x14 / 4 = 5). You can find
the numbers 12 and 5 easily in the SRM, but the numbers used in the
device tree bindings are pretty meaningless. Furthermore, the driver
itself stores the base address in a global variable which won't work for
DA8XX since it has two PSCs instead of one. So, for this case, I'm
really tempted to just write a new driver with better device tree
bindings rather than trying to fix up the keystone driver to make it
compatible with davinci and better device tree bindings while still
maintaining backwards compatibility with wacky device tree bindings.
* The keystone PLL driver and device tree bindings are in better shape,
but they cannot be used as-is with davinci family processors since the
registers are laid out differently. I have a work-in-progress patch for
this that I started quite a while back [4][5].
* All of the keystone clock drivers are currently device tree only, so
they will need to be modified *or* as mentioned above all mach-davinci
boards could be converted to device tree only.
[1]: https://patchwork.kernel.org/patch/10108437/
[2]: https://patchwork.kernel.org/patch/10115483/
[3]: https://patchwork.kernel.org/patch/9449741/
[4]:
https://github.com/dlech/ev3dev-kernel/commit/5e7bf2070aa03283b605d7b86864758d24f83aa8
[5]:
https://github.com/dlech/ev3dev-kernel/commit/1e34686ff57a673c8655eaedacec4d65d48f93b3
---
Also, a bit more background on my motivation here. Really, all I want is
to be able to use the "pwm-clock" device tree bindings to supply a clock
to a Bluetooth chip. But the driver for it requires the common clock
framework.
This is just a spare time project for me, which is why I have just done
the bare minimum to get CONFIG_COMMON_CLK enabled rather than trying to
fix all of the hard problems to do thing the "right way". As you have
seen above, there is still quite a bit of work remaining to be done,
especially when doing this just for fun. It is probably just wishful
thinking, but I kind of hoped that if I was able to get things this far,
maybe some other interested parties might be able to help with one of
the various pieces.
One way or another, I suppose I will get my Bluetooth clock eventually. :-)
^ permalink raw reply
* [PATCH 3/9] arm: cache-l2x0: share l2x0_base
From: Russell King - ARM Linux @ 2017-12-19 23:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171005164831.GG5235@leverpostej>
On Thu, Oct 05, 2017 at 05:48:32PM +0100, Mark Rutland wrote:
> On Thu, Jul 20, 2017 at 02:29:23AM +0200, Micha? Miros?aw wrote:
> > Share l2x0_base between cache-l2x0 and pmu drivers. They are duplicates.
>
> This is not quite true, and this change introduces bugs.
>
> The l2x0 pmu driver only sets its copy of the base for an l2x0 variant
> it recognises:
>
> > -void __init l2x0_pmu_register(void __iomem *base, u32 part)
> > +void __init l2x0_pmu_register(u32 part)
> > {
> > /*
> > * Determine whether we support the PMU, and choose the name for sysfs.
> > @@ -503,8 +502,7 @@ void __init l2x0_pmu_register(void __iomem *base, u32 part)
> > * supported by this driver.
> > *
> > * We must defer registering the PMU until the perf subsystem is up and
> > - * running, so just stash the name and base, and leave that to another
> > - * initcall.
> > + * running, so just stash the name, and leave that to another initcall.
> > */
> > switch (part & L2X0_CACHE_ID_PART_MASK) {
> > case L2X0_CACHE_ID_PART_L220:
> > @@ -516,8 +514,6 @@ void __init l2x0_pmu_register(void __iomem *base, u32 part)
> > default:
> > return;
> > }
> > -
> > - l2x0_base = base;
>
> ... note that we may return *before* setting l2x0_base.
>
> This (deliberately) prevents us from erroneously registering a PMU for
> l2x0 variants for which we don't know how to drive any IMPLEMENTATION
> DEFINED PMU functionality.
>
> This cahnge breaks that, and will result in l2x0_pmu_init() trying to
> register a PMU with a NULL name.
>
> So NAK to this change.
Also I don't want the virtual base address of the L2 cache exposed to
the world, that's an invitation for people to do what they did years
ago, and throw code left right and centre into the tree that accesses
the L2 cache directly from all sorts of places - the result was very
much a mess that took a big patch series to sort out.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-19 22:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219023935.GA17456@codeaurora.org>
On 12/18/2017 08:39 PM, Stephen Boyd wrote:
> + if (gpios && gpios[j] != i)
> + continue;
...
> + j++;
Doesn't this assume that the available GPIOs are listed in numerical
order in the ACPI table? If so, then this patch won't work because that
order is not guaranteed.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 3/3] ARM: dts: am335x-boneblue: enable can
From: Robert Nelson @ 2017-12-19 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219223242.21386-1-robertcnelson@gmail.com>
BeagleBone Blue: can: enable the dedicated can connector.
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
CC: Jason Kridner <jkridner@beagleboard.org>
CC: Drew Fustini <drew@beagleboard.org>
CC: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/am335x-boneblue.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblue.dts b/arch/arm/boot/dts/am335x-boneblue.dts
index ad988e8b8427..3f2480d05a3b 100644
--- a/arch/arm/boot/dts/am335x-boneblue.dts
+++ b/arch/arm/boot/dts/am335x-boneblue.dts
@@ -252,6 +252,15 @@
AM33XX_IOPAD(0x930, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (L18) gmii1_rxclk.gpio3[10] - LS_BUF_EN */
>;
};
+
+ /* DCAN */
+ dcan1_pins: pinmux_dcan1_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x96c, PIN_INPUT | MUX_MODE2) /* (E17) uart0_rtsn.dcan1_rx */
+ AM33XX_IOPAD(0x968, PIN_OUTPUT | MUX_MODE2) /* (E18) uart0_ctsn.dcan1_tx */
+ AM33XX_IOPAD(0x940, PIN_OUTPUT | MUX_MODE7) /* (M16) gmii1_rxd0.gpio2[21] */
+ >;
+ };
};
&uart0 {
@@ -510,6 +519,12 @@
clock-names = "ext-clk", "int-clk";
};
+&dcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dcan1_pins>;
+ status = "okay";
+};
+
&gpio3 {
ls_buf_en {
gpio-hog;
--
2.15.1
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: am335x-boneblue: enable usarts
From: Robert Nelson @ 2017-12-19 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219223242.21386-1-robertcnelson@gmail.com>
BeagleBone Blue: usarts: enable all the dedicated usart connectors.
DSM2/uart4: on the Blue, this is a recieve only interface.
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
CC: Jason Kridner <jkridner@beagleboard.org>
CC: Drew Fustini <drew@beagleboard.org>
CC: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/am335x-boneblue.dts | 60 +++++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblue.dts b/arch/arm/boot/dts/am335x-boneblue.dts
index c5820919e709..ad988e8b8427 100644
--- a/arch/arm/boot/dts/am335x-boneblue.dts
+++ b/arch/arm/boot/dts/am335x-boneblue.dts
@@ -159,6 +159,7 @@
>;
};
+ /* UT0 */
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x970, PIN_INPUT_PULLUP | MUX_MODE0) /* (E15) uart0_rxd.uart0_rxd */
@@ -166,6 +167,37 @@
>;
};
+ /* UT1 */
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x980, PIN_INPUT_PULLUP | MUX_MODE0) /* (D16) uart1_rxd.uart1_rxd */
+ AM33XX_IOPAD(0x984, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* (D15) uart1_txd.uart1_txd */
+ >;
+ };
+
+ /* GPS */
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x950, PIN_INPUT_PULLUP | MUX_MODE1) /* (A17) spi0_sclk.uart2_rxd */
+ AM33XX_IOPAD(0x954, PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* (B17) spi0_d0.uart2_txd */
+ >;
+ };
+
+ /* DSM2 */
+ uart4_pins: pinmux_uart4_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x870, PIN_INPUT_PULLUP | MUX_MODE6) /* (T17) gpmc_wait0.uart4_rxd */
+ >;
+ };
+
+ /* UT5 */
+ uart5_pins: pinmux_uart5_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x8C4, PIN_INPUT_PULLUP | MUX_MODE4) /* (U2) lcd_data9.uart5_rxd */
+ AM33XX_IOPAD(0x8C0, PIN_OUTPUT_PULLDOWN | MUX_MODE4) /* (U1) lcd_data8.uart5_txd */
+ >;
+ };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x960, PIN_INPUT | MUX_MODE7) /* (C15) spi0_cs1.gpio0[6] */
@@ -229,6 +261,34 @@
status = "okay";
};
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart4_pins>;
+
+ status = "okay";
+};
+
+&uart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart5_pins>;
+
+ status = "okay";
+};
+
&usb {
status = "okay";
};
--
2.15.1
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: am335x-boneblue: fix wl1835 IRQ pin
From: Robert Nelson @ 2017-12-19 22:32 UTC (permalink / raw)
To: linux-arm-kernel
Use the correct IRQ gpio pin on the BeagleBone Blue to allow the
wl1835 wireless module to actually work.
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
CC: Jason Kridner <jkridner@beagleboard.org>
CC: Drew Fustini <drew@beagleboard.org>
CC: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/am335x-boneblue.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-boneblue.dts b/arch/arm/boot/dts/am335x-boneblue.dts
index d5be9fc4f416..c5820919e709 100644
--- a/arch/arm/boot/dts/am335x-boneblue.dts
+++ b/arch/arm/boot/dts/am335x-boneblue.dts
@@ -216,7 +216,7 @@
wl18xx_pins: pinmux_wl18xx_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x92c, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* (K18) gmii1_txclk.gpio3[9] - WL_EN */
- AM33XX_IOPAD(0x944, PIN_INPUT_PULLDOWN | MUX_MODE7) /* (H18) rmii1_refclk.gpio0[29] - WL_IRQ */
+ AM33XX_IOPAD(0x924, PIN_INPUT_PULLDOWN | MUX_MODE7) /* (K16) gmii1_txd1.gpio0[21] - WL_IRQ */
AM33XX_IOPAD(0x930, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (L18) gmii1_rxclk.gpio3[10] - LS_BUF_EN */
>;
};
@@ -414,7 +414,7 @@
compatible = "ti,wl1835";
reg = <2>;
interrupt-parent = <&gpio0>;
- interrupts = <29 IRQ_TYPE_EDGE_RISING>;
+ interrupts = <21 IRQ_TYPE_EDGE_RISING>;
};
};
--
2.15.1
^ permalink raw reply related
* [PATCH v6 3/3] clk: at91: pmc: Support backup for programmable clocks
From: Alexandre Belloni @ 2017-12-19 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211165535.5126-4-romain.izard.pro@gmail.com>
On 11/12/2017 at 17:55:35 +0100, Romain Izard wrote:
> When an AT91 programmable clock is declared in the device tree, register
> it into the Power Management Controller driver. On entering suspend mode,
> the driver saves and restores the Programmable Clock registers to support
> the backup mode for these clocks.
>
> Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
> Changes in v2:
> * register PCKs on clock startup
>
> Changes in v3:
> * improve comments on hanling 0 in pmc_register_id and pmc_register_pck
> * declare local variables earlier for checkpatch
>
> Changes in v6:
> * Use the correct author email address
>
> drivers/clk/at91/clk-programmable.c | 2 ++
> drivers/clk/at91/pmc.c | 35 +++++++++++++++++++++++++++++++++++
> drivers/clk/at91/pmc.h | 2 ++
> 3 files changed, 39 insertions(+)
>
> diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
> index 85a449cf61e3..0e6aab1252fc 100644
> --- a/drivers/clk/at91/clk-programmable.c
> +++ b/drivers/clk/at91/clk-programmable.c
> @@ -204,6 +204,8 @@ at91_clk_register_programmable(struct regmap *regmap,
> if (ret) {
> kfree(prog);
> hw = ERR_PTR(ret);
> + } else {
> + pmc_register_pck(id);
> }
>
> return hw;
> diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
> index 07dc2861ad3f..1fa27f4ea538 100644
> --- a/drivers/clk/at91/pmc.c
> +++ b/drivers/clk/at91/pmc.c
> @@ -22,6 +22,7 @@
> #include "pmc.h"
>
> #define PMC_MAX_IDS 128
> +#define PMC_MAX_PCKS 8
>
> int of_at91_get_clk_range(struct device_node *np, const char *propname,
> struct clk_range *range)
> @@ -50,6 +51,7 @@ EXPORT_SYMBOL_GPL(of_at91_get_clk_range);
> static struct regmap *pmcreg;
>
> static u8 registered_ids[PMC_MAX_IDS];
> +static u8 registered_pcks[PMC_MAX_PCKS];
>
> static struct
> {
> @@ -66,8 +68,13 @@ static struct
> u32 pcr[PMC_MAX_IDS];
> u32 audio_pll0;
> u32 audio_pll1;
> + u32 pckr[PMC_MAX_PCKS];
> } pmc_cache;
>
> +/*
> + * As Peripheral ID 0 is invalid on AT91 chips, the identifier is stored
> + * without alteration in the table, and 0 is for unused clocks.
> + */
> void pmc_register_id(u8 id)
> {
> int i;
> @@ -82,9 +89,28 @@ void pmc_register_id(u8 id)
> }
> }
>
> +/*
> + * As Programmable Clock 0 is valid on AT91 chips, there is an offset
> + * of 1 between the stored value and the real clock ID.
> + */
> +void pmc_register_pck(u8 pck)
> +{
> + int i;
> +
> + for (i = 0; i < PMC_MAX_PCKS; i++) {
> + if (registered_pcks[i] == 0) {
> + registered_pcks[i] = pck + 1;
> + break;
> + }
> + if (registered_pcks[i] == (pck + 1))
> + break;
> + }
> +}
> +
> static int pmc_suspend(void)
> {
> int i;
> + u8 num;
>
> regmap_read(pmcreg, AT91_PMC_SCSR, &pmc_cache.scsr);
> regmap_read(pmcreg, AT91_PMC_PCSR, &pmc_cache.pcsr0);
> @@ -103,6 +129,10 @@ static int pmc_suspend(void)
> regmap_read(pmcreg, AT91_PMC_PCR,
> &pmc_cache.pcr[registered_ids[i]]);
> }
> + for (i = 0; registered_pcks[i]; i++) {
> + num = registered_pcks[i] - 1;
> + regmap_read(pmcreg, AT91_PMC_PCKR(num), &pmc_cache.pckr[num]);
> + }
>
> return 0;
> }
> @@ -119,6 +149,7 @@ static bool pmc_ready(unsigned int mask)
> static void pmc_resume(void)
> {
> int i;
> + u8 num;
> u32 tmp;
> u32 mask = AT91_PMC_MCKRDY | AT91_PMC_LOCKA;
>
> @@ -143,6 +174,10 @@ static void pmc_resume(void)
> pmc_cache.pcr[registered_ids[i]] |
> AT91_PMC_PCR_CMD);
> }
> + for (i = 0; registered_pcks[i]; i++) {
> + num = registered_pcks[i] - 1;
> + regmap_write(pmcreg, AT91_PMC_PCKR(num), pmc_cache.pckr[num]);
> + }
>
> if (pmc_cache.uckr & AT91_PMC_UPLLEN)
> mask |= AT91_PMC_LOCKU;
> diff --git a/drivers/clk/at91/pmc.h b/drivers/clk/at91/pmc.h
> index 858e8ef7e8db..d22b1fa9ecdc 100644
> --- a/drivers/clk/at91/pmc.h
> +++ b/drivers/clk/at91/pmc.h
> @@ -31,8 +31,10 @@ int of_at91_get_clk_range(struct device_node *np, const char *propname,
>
> #ifdef CONFIG_PM
> void pmc_register_id(u8 id);
> +void pmc_register_pck(u8 pck);
> #else
> static inline void pmc_register_id(u8 id) {}
> +static inline void pmc_register_pck(u8 pck) {}
> #endif
>
> #endif /* __PMC_H_ */
> --
> 2.14.1
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v6 2/3] clk: at91: pmc: Save SCSR during suspend
From: Alexandre Belloni @ 2017-12-19 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211165535.5126-3-romain.izard.pro@gmail.com>
On 11/12/2017 at 17:55:34 +0100, Romain Izard wrote:
> The contents of the System Clock Status Register (SCSR) needs to be
> restored into the System Clock Enable Register (SCER).
>
> As the bootloader will restore some clocks by itself, the issue can be
> missed as only the USB controller, the LCD controller, the Image Sensor
> controller and the programmable clocks will be impacted.
>
> Fix the obvious typo in the suspend/resume code, as the IMR register
> does not need to be saved twice.
>
> Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
> drivers/clk/at91/pmc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
> index 5c2b26de303e..07dc2861ad3f 100644
> --- a/drivers/clk/at91/pmc.c
> +++ b/drivers/clk/at91/pmc.c
> @@ -86,7 +86,7 @@ static int pmc_suspend(void)
> {
> int i;
>
> - regmap_read(pmcreg, AT91_PMC_IMR, &pmc_cache.scsr);
> + regmap_read(pmcreg, AT91_PMC_SCSR, &pmc_cache.scsr);
> regmap_read(pmcreg, AT91_PMC_PCSR, &pmc_cache.pcsr0);
> regmap_read(pmcreg, AT91_CKGR_UCKR, &pmc_cache.uckr);
> regmap_read(pmcreg, AT91_CKGR_MOR, &pmc_cache.mor);
> @@ -129,7 +129,7 @@ static void pmc_resume(void)
> if (pmc_cache.pllar != tmp)
> pr_warn("PLLAR was not configured properly by the firmware\n");
>
> - regmap_write(pmcreg, AT91_PMC_IMR, pmc_cache.scsr);
> + regmap_write(pmcreg, AT91_PMC_SCER, pmc_cache.scsr);
> regmap_write(pmcreg, AT91_PMC_PCER, pmc_cache.pcsr0);
> regmap_write(pmcreg, AT91_CKGR_UCKR, pmc_cache.uckr);
> regmap_write(pmcreg, AT91_CKGR_MOR, pmc_cache.mor);
> --
> 2.14.1
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ 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