* Re: [PATCH V6 16/21] soc/tegra: pmc: Add pmc wake support for tegra210
From: Dmitry Osipenko @ 2019-07-23 3:43 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland
Cc: pdeschrijver, pgaikwad, sboyd, linux-clk, linux-gpio, jckuo,
josephl, talho, linux-tegra, linux-kernel, mperttunen, spatra,
robh+dt, devicetree
In-Reply-To: <97096b6c-f2f5-b82a-b172-802f4a06d1af@nvidia.com>
23.07.2019 6:31, Sowjanya Komatineni пишет:
>
> On 7/22/19 8:25 PM, Dmitry Osipenko wrote:
>> 23.07.2019 6:09, Sowjanya Komatineni пишет:
>>> On 7/22/19 8:03 PM, Dmitry Osipenko wrote:
>>>> 23.07.2019 4:52, Sowjanya Komatineni пишет:
>>>>> On 7/22/19 6:41 PM, Dmitry Osipenko wrote:
>>>>>> 23.07.2019 4:08, Dmitry Osipenko пишет:
>>>>>>> 23.07.2019 3:58, Dmitry Osipenko пишет:
>>>>>>>> 21.07.2019 22:40, Sowjanya Komatineni пишет:
>>>>>>>>> This patch implements PMC wakeup sequence for Tegra210 and defines
>>>>>>>>> common used RTC alarm wake event.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>>>>>>>> ---
>>>>>>>>> drivers/soc/tegra/pmc.c | 111
>>>>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>>> 1 file changed, 111 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
>>>>>>>>> index 91c84d0e66ae..c556f38874e1 100644
>>>>>>>>> --- a/drivers/soc/tegra/pmc.c
>>>>>>>>> +++ b/drivers/soc/tegra/pmc.c
>>>>>>>>> @@ -57,6 +57,12 @@
>>>>>>>>> #define PMC_CNTRL_SYSCLK_OE BIT(11) /* system clock
>>>>>>>>> enable */
>>>>>>>>> #define PMC_CNTRL_SYSCLK_POLARITY BIT(10) /* sys clk
>>>>>>>>> polarity */
>>>>>>>>> #define PMC_CNTRL_MAIN_RST BIT(4)
>>>>>>>>> +#define PMC_CNTRL_LATCH_WAKEUPS BIT(5)
>>>>>>> Please follow the TRM's bits naming.
>>>>>>>
>>>>>>> PMC_CNTRL_LATCHWAKE_EN
>>>>>>>
>>>>>>>>> +#define PMC_WAKE_MASK 0x0c
>>>>>>>>> +#define PMC_WAKE_LEVEL 0x10
>>>>>>>>> +#define PMC_WAKE_STATUS 0x14
>>>>>>>>> +#define PMC_SW_WAKE_STATUS 0x18
>>>>>>>>> #define DPD_SAMPLE 0x020
>>>>>>>>> #define DPD_SAMPLE_ENABLE BIT(0)
>>>>>>>>> @@ -87,6 +93,11 @@
>>>>>>>>> #define PMC_SCRATCH41 0x140
>>>>>>>>> +#define PMC_WAKE2_MASK 0x160
>>>>>>>>> +#define PMC_WAKE2_LEVEL 0x164
>>>>>>>>> +#define PMC_WAKE2_STATUS 0x168
>>>>>>>>> +#define PMC_SW_WAKE2_STATUS 0x16c
>>>>>>>>> +
>>>>>>>>> #define PMC_SENSOR_CTRL 0x1b0
>>>>>>>>> #define PMC_SENSOR_CTRL_SCRATCH_WRITE BIT(2)
>>>>>>>>> #define PMC_SENSOR_CTRL_ENABLE_RST BIT(1)
>>>>>>>>> @@ -1922,6 +1933,55 @@ static const struct irq_domain_ops
>>>>>>>>> tegra_pmc_irq_domain_ops = {
>>>>>>>>> .alloc = tegra_pmc_irq_alloc,
>>>>>>>>> };
>>>>>>>>> +static int tegra210_pmc_irq_set_wake(struct irq_data *data,
>>>>>>>>> unsigned int on)
>>>>>>>>> +{
>>>>>>>>> + struct tegra_pmc *pmc = irq_data_get_irq_chip_data(data);
>>>>>>>>> + unsigned int offset, bit;
>>>>>>>>> + u32 value;
>>>>>>>>> +
>>>>>>>>> + if (data->hwirq == ULONG_MAX)
>>>>>>>>> + return 0;
>>>>>>>>> +
>>>>>>>>> + offset = data->hwirq / 32;
>>>>>>>>> + bit = data->hwirq % 32;
>>>>>>>>> +
>>>>>>>>> + /*
>>>>>>>>> + * Latch wakeups to SW_WAKE_STATUS register to capture events
>>>>>>>>> + * that would not make it into wakeup event register during
>>>>>>>>> LP0 exit.
>>>>>>>>> + */
>>>>>>>>> + value = tegra_pmc_readl(pmc, PMC_CNTRL);
>>>>>>>>> + value |= PMC_CNTRL_LATCH_WAKEUPS;
>>>>>>>>> + tegra_pmc_writel(pmc, value, PMC_CNTRL);
>>>>>>>>> + udelay(120);
>>>>>>>> Why it takes so much time to latch the values? Shouldn't some
>>>>>>>> status-bit
>>>>>>>> be polled for the completion of latching?
>>>>>>>>
>>>>>>>> Is this register-write really getting buffered in the PMC?
>>>>>>>>
>>>>>>>>> + value &= ~PMC_CNTRL_LATCH_WAKEUPS;
>>>>>>>>> + tegra_pmc_writel(pmc, value, PMC_CNTRL);
>>>>>>>>> + udelay(120);
>>>>>>>> 120 usecs to remove latching, really?
>>>>>>>>
>>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_SW_WAKE_STATUS);
>>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_SW_WAKE2_STATUS);
>>>>>>>>> +
>>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_WAKE_STATUS);
>>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_WAKE2_STATUS);
>>>>>>>>> +
>>>>>>>>> + /* enable PMC wake */
>>>>>>>>> + if (data->hwirq >= 32)
>>>>>>>>> + offset = PMC_WAKE2_MASK;
>>>>>>>>> + else
>>>>>>>>> + offset = PMC_WAKE_MASK;
>>>>>>>>> +
>>>>>>>>> + value = tegra_pmc_readl(pmc, offset);
>>>>>>>>> +
>>>>>>>>> + if (on)
>>>>>>>>> + value |= 1 << bit;
>>>>>>>>> + else
>>>>>>>>> + value &= ~(1 << bit);
>>>>>>>>> +
>>>>>>>>> + tegra_pmc_writel(pmc, value, offset);
>>>>>>>> Why the latching is done *before* writing into the WAKE registers?
>>>>>>>> What
>>>>>>>> it is latching then?
>>>>>>> I'm looking at the TRM doc and it says that latching should be done
>>>>>>> *after* writing to the WAKE_MASK / LEVEL registers.
>>>>>>>
>>>>>>> Secondly it says that it's enough to do:
>>>>>>>
>>>>>>> value = tegra_pmc_readl(pmc, PMC_CNTRL);
>>>>>>> value |= PMC_CNTRL_LATCH_WAKEUPS;
>>>>>>> tegra_pmc_writel(pmc, value, PMC_CNTRL);
>>>>>>>
>>>>>>> in order to latch. There is no need for the delay and to remove the
>>>>>>> "LATCHWAKE_EN" bit, it should be a oneshot action.
>>>>>> Although, no. TRM says "stops latching on transition from 1
>>>>>> to 0 (sequence - set to 1,set to 0)", so it's not a oneshot action.
>>>>>>
>>>>>> Have you tested this code at all? I'm wondering how it happens to
>>>>>> work
>>>>>> without a proper latching.
>>>>> Yes, ofcourse its tested and this sequence to do transition is
>>>>> recommendation from Tegra designer.
>>>>> Will check if TRM doesn't have update properly or will re-confirm
>>>>> internally on delay time...
>>>>>
>>>>> On any of the wake event PMC wakeup happens and WAKE_STATUS register
>>>>> will have bits set for all events that triggered wake.
>>>>> After wakeup PMC doesn't update SW_WAKE_STATUS register as per PMC
>>>>> design.
>>>>> SW latch register added in design helps to provide a way to capture
>>>>> those events that happen right during wakeup time and didnt make it to
>>>>> SW_WAKE_STATUS register.
>>>>> So before next suspend entry, latching all prior wake events into SW
>>>>> WAKE_STATUS and then clearing them.
>>>> I'm now wondering whether the latching cold be turned ON permanently
>>>> during of the PMC's probe, for simplicity.
>>> latching should be done on suspend-resume cycle as wake events gets
>>> generates on every suspend-resume cycle.
>> You're saying that PMC "doesn't update SW_WAKE_STATUS" after wake-up,
>> then I don't quite understand what's the point of disabling the latching
>> at all.
> When latch wake enable is set, events are latched and during 1 to 0
> transition latching is disabled.
>
> This is to avoid sw_wake_status and wake_status showing diff events.
Okay.
> Currently driver is not relying on SW_WAKE_STATUS but its good to latch
> and clear so even at some point for some reason when SW_WAKE_STATUS is
> used, this wlil not cause mismatch with wake_status.
Then the latching need to be enabled on suspend and disabled early on
resume to get a proper WAKE status.
[snip]
^ permalink raw reply
* Re: [PATCH 17/18] arm64: dts: broadcom: Add reference to RPi 4 B
From: Matthias Brugger @ 2019-07-23 7:20 UTC (permalink / raw)
To: Stefan Wahren, Eric Anholt, Mark Rutland, Michael Turquette,
Ray Jui, Scott Branden, Florian Fainelli, Adrian Hunter,
Rob Herring, Stephen Boyd, Linus Walleij, Ulf Hansson,
Nicolas Saenz Julienne
Cc: bcm-kernel-feedback-list@broadcom.com,
linux-arm-kernel@lists.infradead.org,
linux-rpi-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
linux-mmc@vger.kernel.org
In-Reply-To: <1563815257-2648-5-git-send-email-wahrenst@gmx.net>
On 22/07/2019 19:07, Stefan Wahren wrote:
> This adds a reference to the dts of the Raspberry Pi 4 B,
> so we don't need to maintain the content in arm64.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
AFAIK arm64 doesn't boot without the DMA RFC patch series from Nicolas. So maybe
we should wait until this is fixed before adding a for now broken device.
Regards,
Matthias
> ---
> arch/arm64/boot/dts/broadcom/Makefile | 3 ++-
> arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dts | 2 ++
> 2 files changed, 4 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dts
>
> diff --git a/arch/arm64/boot/dts/broadcom/Makefile b/arch/arm64/boot/dts/broadcom/Makefile
> index d1d31cc..cb7de8d 100644
> --- a/arch/arm64/boot/dts/broadcom/Makefile
> +++ b/arch/arm64/boot/dts/broadcom/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> -dtb-$(CONFIG_ARCH_BCM2835) += bcm2837-rpi-3-a-plus.dtb \
> +dtb-$(CONFIG_ARCH_BCM2835) += bcm2711-rpi-4-b.dtb \
> + bcm2837-rpi-3-a-plus.dtb \
> bcm2837-rpi-3-b.dtb \
> bcm2837-rpi-3-b-plus.dtb \
> bcm2837-rpi-cm3-io3.dtb
> diff --git a/arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dts b/arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dts
> new file mode 100644
> index 0000000..d24c536
> --- /dev/null
> +++ b/arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dts
> @@ -0,0 +1,2 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include "arm/bcm2711-rpi-4-b.dts"
> --
> 2.7.4
>
>
^ permalink raw reply
* [PATCH] gpio: Use dev_get_drvdata
From: Chuhong Yuan @ 2019-07-23 8:29 UTC (permalink / raw)
Cc: Andy Shevchenko, Linus Walleij, Bartosz Golaszewski, linux-gpio,
linux-kernel, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/gpio/gpio-pch.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c
index 1d99293096f2..3f3d9a94b709 100644
--- a/drivers/gpio/gpio-pch.c
+++ b/drivers/gpio/gpio-pch.c
@@ -409,8 +409,7 @@ static int pch_gpio_probe(struct pci_dev *pdev,
static int __maybe_unused pch_gpio_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct pch_gpio *chip = pci_get_drvdata(pdev);
+ struct pch_gpio *chip = dev_get_drvdata(dev);
unsigned long flags;
spin_lock_irqsave(&chip->spinlock, flags);
@@ -422,8 +421,7 @@ static int __maybe_unused pch_gpio_suspend(struct device *dev)
static int __maybe_unused pch_gpio_resume(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct pch_gpio *chip = pci_get_drvdata(pdev);
+ struct pch_gpio *chip = dev_get_drvdata(dev);
unsigned long flags;
spin_lock_irqsave(&chip->spinlock, flags);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] gpio: Use dev_get_drvdata
From: Bartosz Golaszewski @ 2019-07-23 8:34 UTC (permalink / raw)
To: Chuhong Yuan; +Cc: Andy Shevchenko, Linus Walleij, linux-gpio, LKML
In-Reply-To: <20190723082933.21134-1-hslester96@gmail.com>
wt., 23 lip 2019 o 10:29 Chuhong Yuan <hslester96@gmail.com> napisał(a):
>
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> ---
> drivers/gpio/gpio-pch.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c
> index 1d99293096f2..3f3d9a94b709 100644
> --- a/drivers/gpio/gpio-pch.c
> +++ b/drivers/gpio/gpio-pch.c
> @@ -409,8 +409,7 @@ static int pch_gpio_probe(struct pci_dev *pdev,
>
> static int __maybe_unused pch_gpio_suspend(struct device *dev)
> {
> - struct pci_dev *pdev = to_pci_dev(dev);
> - struct pch_gpio *chip = pci_get_drvdata(pdev);
> + struct pch_gpio *chip = dev_get_drvdata(dev);
> unsigned long flags;
>
> spin_lock_irqsave(&chip->spinlock, flags);
> @@ -422,8 +421,7 @@ static int __maybe_unused pch_gpio_suspend(struct device *dev)
>
> static int __maybe_unused pch_gpio_resume(struct device *dev)
> {
> - struct pci_dev *pdev = to_pci_dev(dev);
> - struct pch_gpio *chip = pci_get_drvdata(pdev);
> + struct pch_gpio *chip = dev_get_drvdata(dev);
> unsigned long flags;
>
> spin_lock_irqsave(&chip->spinlock, flags);
> --
> 2.20.1
>
The subject line should start with gpio: pch: ...
Bart
^ permalink raw reply
* [PATCH v2] gpio: pch: Use dev_get_drvdata
From: Chuhong Yuan @ 2019-07-23 8:39 UTC (permalink / raw)
Cc: Andy Shevchenko, Linus Walleij, Bartosz Golaszewski, linux-gpio,
linux-kernel, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
Changes in v2:
- Change the subject line to gpio: pch: ...
drivers/gpio/gpio-pch.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c
index 1d99293096f2..3f3d9a94b709 100644
--- a/drivers/gpio/gpio-pch.c
+++ b/drivers/gpio/gpio-pch.c
@@ -409,8 +409,7 @@ static int pch_gpio_probe(struct pci_dev *pdev,
static int __maybe_unused pch_gpio_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct pch_gpio *chip = pci_get_drvdata(pdev);
+ struct pch_gpio *chip = dev_get_drvdata(dev);
unsigned long flags;
spin_lock_irqsave(&chip->spinlock, flags);
@@ -422,8 +421,7 @@ static int __maybe_unused pch_gpio_suspend(struct device *dev)
static int __maybe_unused pch_gpio_resume(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct pch_gpio *chip = pci_get_drvdata(pdev);
+ struct pch_gpio *chip = dev_get_drvdata(dev);
unsigned long flags;
spin_lock_irqsave(&chip->spinlock, flags);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 00/18] ARM: Add minimal Raspberry Pi 4 support
From: Christoph Hellwig @ 2019-07-23 9:34 UTC (permalink / raw)
To: Stefan Wahren
Cc: Nicolas Saenz Julienne, Eric Anholt, Florian Fainelli, Ray Jui,
Scott Branden, Matthias Brugger, Rob Herring, Mark Rutland,
Linus Walleij, Michael Turquette, Stephen Boyd, Ulf Hansson,
Adrian Hunter, bcm-kernel-feedback-list, linux-arm-kernel,
linux-rpi-kernel, linux-gpio, linux-mmc, Christoph Hellwig
In-Reply-To: <bc650090-db86-ccac-01dc-23f08ad7b19b@gmx.net>
On Mon, Jul 22, 2019 at 08:10:17PM +0200, Stefan Wahren wrote:
> i rebased this series also and got this only on the RPi 4.
>
> After reverting the following:
>
> 79a986721de dma-mapping: remove dma_max_pfn
> 7559d612dff0 mmc: core: let the dma map ops handle bouncing
>
> This crash disappear, but wifi seems to be still broken.
>
> Would be nice, if you can investigate further.
That means dma addressing on this system doesn't just work for some
memory, and the mmc bounce buffering was papering over that just for
mmc. Do you have highmem on this system?
You might want to try this series, which has been submitted upstream:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/arm-swiotlb
^ permalink raw reply
* Re: [PATCH v2] gpio: pch: Use dev_get_drvdata
From: Bartosz Golaszewski @ 2019-07-23 9:49 UTC (permalink / raw)
To: Chuhong Yuan; +Cc: Andy Shevchenko, Linus Walleij, linux-gpio, LKML
In-Reply-To: <20190723083923.21392-1-hslester96@gmail.com>
wt., 23 lip 2019 o 10:39 Chuhong Yuan <hslester96@gmail.com> napisał(a):
>
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> ---
> Changes in v2:
> - Change the subject line to gpio: pch: ...
>
> drivers/gpio/gpio-pch.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c
> index 1d99293096f2..3f3d9a94b709 100644
> --- a/drivers/gpio/gpio-pch.c
> +++ b/drivers/gpio/gpio-pch.c
> @@ -409,8 +409,7 @@ static int pch_gpio_probe(struct pci_dev *pdev,
>
> static int __maybe_unused pch_gpio_suspend(struct device *dev)
> {
> - struct pci_dev *pdev = to_pci_dev(dev);
> - struct pch_gpio *chip = pci_get_drvdata(pdev);
> + struct pch_gpio *chip = dev_get_drvdata(dev);
> unsigned long flags;
>
> spin_lock_irqsave(&chip->spinlock, flags);
> @@ -422,8 +421,7 @@ static int __maybe_unused pch_gpio_suspend(struct device *dev)
>
> static int __maybe_unused pch_gpio_resume(struct device *dev)
> {
> - struct pci_dev *pdev = to_pci_dev(dev);
> - struct pch_gpio *chip = pci_get_drvdata(pdev);
> + struct pch_gpio *chip = dev_get_drvdata(dev);
> unsigned long flags;
>
> spin_lock_irqsave(&chip->spinlock, flags);
> --
> 2.20.1
>
Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
^ permalink raw reply
* Re: [PATCH 00/18] ARM: Add minimal Raspberry Pi 4 support
From: Nicolas Saenz Julienne @ 2019-07-23 13:32 UTC (permalink / raw)
To: Christoph Hellwig, Stefan Wahren
Cc: Eric Anholt, Florian Fainelli, Ray Jui, Scott Branden,
Matthias Brugger, Rob Herring, Mark Rutland, Linus Walleij,
Michael Turquette, Stephen Boyd, Ulf Hansson, Adrian Hunter,
bcm-kernel-feedback-list, linux-arm-kernel, linux-rpi-kernel,
linux-gpio, linux-mmc
In-Reply-To: <20190723093442.GA27239@lst.de>
[-- Attachment #1: Type: text/plain, Size: 3896 bytes --]
On Tue, 2019-07-23 at 11:34 +0200, Christoph Hellwig wrote:
> On Mon, Jul 22, 2019 at 08:10:17PM +0200, Stefan Wahren wrote:
> > i rebased this series also and got this only on the RPi 4.
> >
> > After reverting the following:
> >
> > 79a986721de dma-mapping: remove dma_max_pfn
> > 7559d612dff0 mmc: core: let the dma map ops handle bouncing
> >
> > This crash disappear, but wifi seems to be still broken.
> >
> > Would be nice, if you can investigate further.
>
> That means dma addressing on this system doesn't just work for some
> memory, and the mmc bounce buffering was papering over that just for
> mmc. Do you have highmem on this system?
>
> You might want to try this series, which has been submitted upstream:
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/arm-swiotlb
Hi Christoph,
I tried your series on top of Stefan's, it has no effect. I guess it's no
surprise as with mult_v7_defconfig, you get SWIOTLB=n & LPAE=n.
FYI DMA addressing constraints for RPi4 are the following: devices can only
access the first GB of ram even though the board might have up to 4GB of ram.
The DMA addresses are aliased with a 0xc0000000 offset. So 0x00000000 phys is
aliased to 0xc0000000 in DMA. This is the same as for an RFC you commented last
week trying to fix similar issues for arm64.
You state in "arm: use swiotlb for bounce buffer on LPAE configs" that "The DMA
API requires that 32-bit DMA masks are always supported". If I understand it
correctly this device breaks that assumption. Which implies we need a bounce
buffer system in place for any straming DMA user.
It seems we're unable to use dma-direct/swiotlb, so I enabled arm's dmabounce
on all devices hooked into RPi's limited interconnect, which fixes this issue.
Any thoughts on this?
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 5e5f1fabc3d4..3db8deed83a6 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -168,6 +168,7 @@ config ARCH_BCM2835
select PINCTRL
select PINCTRL_BCM2835
select MFD_CORE
+ select DMABOUNCE
help
This enables support for the Broadcom BCM2835 and BCM2836 SoCs.
This SoC is used in the Raspberry Pi and Roku 2 devices.
diff --git a/arch/arm/mach-bcm/board_bcm2835.c b/arch/arm/mach-bcm/board_bcm2835.c
index c09cf25596af..be788849c4bb 100644
--- a/arch/arm/mach-bcm/board_bcm2835.c
+++ b/arch/arm/mach-bcm/board_bcm2835.c
@@ -3,6 +3,8 @@
* Copyright (C) 2010 Broadcom
*/
+#include <linux/device.h>
+#include <linux/dma-mapping.h>
#include <linux/init.h>
#include <linux/irqchip.h>
#include <linux/of_address.h>
@@ -24,8 +26,37 @@ static const char * const bcm2835_compat[] = {
NULL
};
+static int bcm2835_needs_bounce(struct device *dev, dma_addr_t dma_addr, size_t size)
+{
+ /*
+ * The accepted dma addresses are [0xc0000000, 0xffffffff] which map to
+ * ram's [0x00000000, 0x3fffffff].
+ */
+ return dma_addr < 3ULL * SZ_1G;
+}
+
+/*
+ * Setup DMA mask to 1GB on devices hanging from soc interconnect
+ */
+static int bcm2835_platform_notify(struct device *dev)
+{
+ if (dev->parent && !strcmp("soc", dev_name(dev->parent))) {
+ dev->dma_mask = &dev->coherent_dma_mask;
+ dev->coherent_dma_mask = DMA_BIT_MASK(30); /* 1GB */
+ dmabounce_register_dev(dev, 2048, 4096, bcm2835_needs_bounce);
+ }
+
+ return 0;
+}
+
+void __init bcm2835_init_early(void)
+{
+ platform_notify = bcm2835_platform_notify;
+}
+
DT_MACHINE_START(BCM2835, "BCM2835")
.dma_zone_size = SZ_1G,
.dt_compat = bcm2835_compat,
.smp = smp_ops(bcm2836_smp_ops),
+ .init_early = bcm2835_init_early,
MACHINE_END
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* Re: [PATCH V6 16/21] soc/tegra: pmc: Add pmc wake support for tegra210
From: Dmitry Osipenko @ 2019-07-23 14:27 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland
Cc: pdeschrijver, pgaikwad, sboyd, linux-clk, linux-gpio, jckuo,
josephl, talho, linux-tegra, linux-kernel, mperttunen, spatra,
robh+dt, devicetree
In-Reply-To: <a58de350-f6ce-9308-1ae0-885e732b575d@gmail.com>
23.07.2019 6:43, Dmitry Osipenko пишет:
> 23.07.2019 6:31, Sowjanya Komatineni пишет:
>>
>> On 7/22/19 8:25 PM, Dmitry Osipenko wrote:
>>> 23.07.2019 6:09, Sowjanya Komatineni пишет:
>>>> On 7/22/19 8:03 PM, Dmitry Osipenko wrote:
>>>>> 23.07.2019 4:52, Sowjanya Komatineni пишет:
>>>>>> On 7/22/19 6:41 PM, Dmitry Osipenko wrote:
>>>>>>> 23.07.2019 4:08, Dmitry Osipenko пишет:
>>>>>>>> 23.07.2019 3:58, Dmitry Osipenko пишет:
>>>>>>>>> 21.07.2019 22:40, Sowjanya Komatineni пишет:
>>>>>>>>>> This patch implements PMC wakeup sequence for Tegra210 and defines
>>>>>>>>>> common used RTC alarm wake event.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>>>>>>>>> ---
>>>>>>>>>> drivers/soc/tegra/pmc.c | 111
>>>>>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>>>> 1 file changed, 111 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
>>>>>>>>>> index 91c84d0e66ae..c556f38874e1 100644
>>>>>>>>>> --- a/drivers/soc/tegra/pmc.c
>>>>>>>>>> +++ b/drivers/soc/tegra/pmc.c
>>>>>>>>>> @@ -57,6 +57,12 @@
>>>>>>>>>> #define PMC_CNTRL_SYSCLK_OE BIT(11) /* system clock
>>>>>>>>>> enable */
>>>>>>>>>> #define PMC_CNTRL_SYSCLK_POLARITY BIT(10) /* sys clk
>>>>>>>>>> polarity */
>>>>>>>>>> #define PMC_CNTRL_MAIN_RST BIT(4)
>>>>>>>>>> +#define PMC_CNTRL_LATCH_WAKEUPS BIT(5)
>>>>>>>> Please follow the TRM's bits naming.
>>>>>>>>
>>>>>>>> PMC_CNTRL_LATCHWAKE_EN
>>>>>>>>
>>>>>>>>>> +#define PMC_WAKE_MASK 0x0c
>>>>>>>>>> +#define PMC_WAKE_LEVEL 0x10
>>>>>>>>>> +#define PMC_WAKE_STATUS 0x14
>>>>>>>>>> +#define PMC_SW_WAKE_STATUS 0x18
>>>>>>>>>> #define DPD_SAMPLE 0x020
>>>>>>>>>> #define DPD_SAMPLE_ENABLE BIT(0)
>>>>>>>>>> @@ -87,6 +93,11 @@
>>>>>>>>>> #define PMC_SCRATCH41 0x140
>>>>>>>>>> +#define PMC_WAKE2_MASK 0x160
>>>>>>>>>> +#define PMC_WAKE2_LEVEL 0x164
>>>>>>>>>> +#define PMC_WAKE2_STATUS 0x168
>>>>>>>>>> +#define PMC_SW_WAKE2_STATUS 0x16c
>>>>>>>>>> +
>>>>>>>>>> #define PMC_SENSOR_CTRL 0x1b0
>>>>>>>>>> #define PMC_SENSOR_CTRL_SCRATCH_WRITE BIT(2)
>>>>>>>>>> #define PMC_SENSOR_CTRL_ENABLE_RST BIT(1)
>>>>>>>>>> @@ -1922,6 +1933,55 @@ static const struct irq_domain_ops
>>>>>>>>>> tegra_pmc_irq_domain_ops = {
>>>>>>>>>> .alloc = tegra_pmc_irq_alloc,
>>>>>>>>>> };
>>>>>>>>>> +static int tegra210_pmc_irq_set_wake(struct irq_data *data,
>>>>>>>>>> unsigned int on)
>>>>>>>>>> +{
>>>>>>>>>> + struct tegra_pmc *pmc = irq_data_get_irq_chip_data(data);
>>>>>>>>>> + unsigned int offset, bit;
>>>>>>>>>> + u32 value;
>>>>>>>>>> +
>>>>>>>>>> + if (data->hwirq == ULONG_MAX)
>>>>>>>>>> + return 0;
>>>>>>>>>> +
>>>>>>>>>> + offset = data->hwirq / 32;
>>>>>>>>>> + bit = data->hwirq % 32;
>>>>>>>>>> +
>>>>>>>>>> + /*
>>>>>>>>>> + * Latch wakeups to SW_WAKE_STATUS register to capture events
>>>>>>>>>> + * that would not make it into wakeup event register during
>>>>>>>>>> LP0 exit.
>>>>>>>>>> + */
>>>>>>>>>> + value = tegra_pmc_readl(pmc, PMC_CNTRL);
>>>>>>>>>> + value |= PMC_CNTRL_LATCH_WAKEUPS;
>>>>>>>>>> + tegra_pmc_writel(pmc, value, PMC_CNTRL);
>>>>>>>>>> + udelay(120);
>>>>>>>>> Why it takes so much time to latch the values? Shouldn't some
>>>>>>>>> status-bit
>>>>>>>>> be polled for the completion of latching?
>>>>>>>>>
>>>>>>>>> Is this register-write really getting buffered in the PMC?
>>>>>>>>>
>>>>>>>>>> + value &= ~PMC_CNTRL_LATCH_WAKEUPS;
>>>>>>>>>> + tegra_pmc_writel(pmc, value, PMC_CNTRL);
>>>>>>>>>> + udelay(120);
>>>>>>>>> 120 usecs to remove latching, really?
>>>>>>>>>
>>>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_SW_WAKE_STATUS);
>>>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_SW_WAKE2_STATUS);
>>>>>>>>>> +
>>>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_WAKE_STATUS);
>>>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_WAKE2_STATUS);
>>>>>>>>>> +
>>>>>>>>>> + /* enable PMC wake */
>>>>>>>>>> + if (data->hwirq >= 32)
>>>>>>>>>> + offset = PMC_WAKE2_MASK;
>>>>>>>>>> + else
>>>>>>>>>> + offset = PMC_WAKE_MASK;
>>>>>>>>>> +
>>>>>>>>>> + value = tegra_pmc_readl(pmc, offset);
>>>>>>>>>> +
>>>>>>>>>> + if (on)
>>>>>>>>>> + value |= 1 << bit;
>>>>>>>>>> + else
>>>>>>>>>> + value &= ~(1 << bit);
>>>>>>>>>> +
>>>>>>>>>> + tegra_pmc_writel(pmc, value, offset);
>>>>>>>>> Why the latching is done *before* writing into the WAKE registers?
>>>>>>>>> What
>>>>>>>>> it is latching then?
>>>>>>>> I'm looking at the TRM doc and it says that latching should be done
>>>>>>>> *after* writing to the WAKE_MASK / LEVEL registers.
>>>>>>>>
>>>>>>>> Secondly it says that it's enough to do:
>>>>>>>>
>>>>>>>> value = tegra_pmc_readl(pmc, PMC_CNTRL);
>>>>>>>> value |= PMC_CNTRL_LATCH_WAKEUPS;
>>>>>>>> tegra_pmc_writel(pmc, value, PMC_CNTRL);
>>>>>>>>
>>>>>>>> in order to latch. There is no need for the delay and to remove the
>>>>>>>> "LATCHWAKE_EN" bit, it should be a oneshot action.
>>>>>>> Although, no. TRM says "stops latching on transition from 1
>>>>>>> to 0 (sequence - set to 1,set to 0)", so it's not a oneshot action.
>>>>>>>
>>>>>>> Have you tested this code at all? I'm wondering how it happens to
>>>>>>> work
>>>>>>> without a proper latching.
>>>>>> Yes, ofcourse its tested and this sequence to do transition is
>>>>>> recommendation from Tegra designer.
>>>>>> Will check if TRM doesn't have update properly or will re-confirm
>>>>>> internally on delay time...
>>>>>>
>>>>>> On any of the wake event PMC wakeup happens and WAKE_STATUS register
>>>>>> will have bits set for all events that triggered wake.
>>>>>> After wakeup PMC doesn't update SW_WAKE_STATUS register as per PMC
>>>>>> design.
>>>>>> SW latch register added in design helps to provide a way to capture
>>>>>> those events that happen right during wakeup time and didnt make it to
>>>>>> SW_WAKE_STATUS register.
>>>>>> So before next suspend entry, latching all prior wake events into SW
>>>>>> WAKE_STATUS and then clearing them.
>>>>> I'm now wondering whether the latching cold be turned ON permanently
>>>>> during of the PMC's probe, for simplicity.
>>>> latching should be done on suspend-resume cycle as wake events gets
>>>> generates on every suspend-resume cycle.
>>> You're saying that PMC "doesn't update SW_WAKE_STATUS" after wake-up,
>>> then I don't quite understand what's the point of disabling the latching
>>> at all.
>> When latch wake enable is set, events are latched and during 1 to 0
>> transition latching is disabled.
>>
>> This is to avoid sw_wake_status and wake_status showing diff events.
>
> Okay.
>
>> Currently driver is not relying on SW_WAKE_STATUS but its good to latch
>> and clear so even at some point for some reason when SW_WAKE_STATUS is
>> used, this wlil not cause mismatch with wake_status.
>
> Then the latching need to be enabled on suspend and disabled early on
> resume to get a proper WAKE status.
Actually, it will be better to simply not implement the latching until
it will become really needed. In general you shouldn't add into the
patchset anything that is unused.
^ permalink raw reply
* Re: [PATCH 00/18] ARM: Add minimal Raspberry Pi 4 support
From: Christoph Hellwig @ 2019-07-23 14:33 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Christoph Hellwig, Stefan Wahren, Eric Anholt, Florian Fainelli,
Ray Jui, Scott Branden, Matthias Brugger, Rob Herring,
Mark Rutland, Linus Walleij, Michael Turquette, Stephen Boyd,
Ulf Hansson, Adrian Hunter, bcm-kernel-feedback-list,
linux-arm-kernel, linux-rpi-kernel, linux-gpio, linux-mmc
In-Reply-To: <04c5eaa03f3a124dbbce6186e11e19acc4539cc8.camel@suse.de>
On Tue, Jul 23, 2019 at 03:32:11PM +0200, Nicolas Saenz Julienne wrote:
> You state in "arm: use swiotlb for bounce buffer on LPAE configs" that "The DMA
> API requires that 32-bit DMA masks are always supported". If I understand it
> correctly this device breaks that assumption. Which implies we need a bounce
> buffer system in place for any straming DMA user.
Yes, you do.
> It seems we're unable to use dma-direct/swiotlb, so I enabled arm's dmabounce
> on all devices hooked into RPi's limited interconnect, which fixes this issue.
> Any thoughts on this?
There is no reason swiotlb could not handle the case, but at least for
now dmabounce seems like the better option given that it is well
integrated into the arm code.
Your patch looks good to me.
^ permalink raw reply
* Re: [PATCH] gpio: Use dev_get_drvdata
From: Andy Shevchenko @ 2019-07-23 15:39 UTC (permalink / raw)
To: Bartosz Golaszewski; +Cc: Chuhong Yuan, Linus Walleij, linux-gpio, LKML
In-Reply-To: <CAMpxmJUCPCyC-n9V+o5veMTm-yui8H2vdn1ceqZN=VG+yosLOw@mail.gmail.com>
On Tue, Jul 23, 2019 at 10:34:28AM +0200, Bartosz Golaszewski wrote:
> wt., 23 lip 2019 o 10:29 Chuhong Yuan <hslester96@gmail.com> napisał(a):
> >
> > Instead of using to_pci_dev + pci_get_drvdata,
> > use dev_get_drvdata to make code simpler.
> >
> > Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> > ---
> > drivers/gpio/gpio-pch.c | 6 ++----
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c
> > index 1d99293096f2..3f3d9a94b709 100644
> > --- a/drivers/gpio/gpio-pch.c
> > +++ b/drivers/gpio/gpio-pch.c
> > @@ -409,8 +409,7 @@ static int pch_gpio_probe(struct pci_dev *pdev,
> >
> > static int __maybe_unused pch_gpio_suspend(struct device *dev)
> > {
> > - struct pci_dev *pdev = to_pci_dev(dev);
> > - struct pch_gpio *chip = pci_get_drvdata(pdev);
> > + struct pch_gpio *chip = dev_get_drvdata(dev);
> > unsigned long flags;
> >
> > spin_lock_irqsave(&chip->spinlock, flags);
> > @@ -422,8 +421,7 @@ static int __maybe_unused pch_gpio_suspend(struct device *dev)
> >
> > static int __maybe_unused pch_gpio_resume(struct device *dev)
> > {
> > - struct pci_dev *pdev = to_pci_dev(dev);
> > - struct pch_gpio *chip = pci_get_drvdata(pdev);
> > + struct pch_gpio *chip = dev_get_drvdata(dev);
> > unsigned long flags;
> >
> > spin_lock_irqsave(&chip->spinlock, flags);
> > --
> > 2.20.1
> >
>
> The subject line should start with gpio: pch: ...
I can change it when apply to gpio-intel tree.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 1/4] pinctrl: baytrail: Use devm_platform_ioremap_resource()
From: Andy Shevchenko @ 2019-07-23 15:51 UTC (permalink / raw)
To: Mika Westerberg; +Cc: linux-gpio, Linus Walleij
In-Reply-To: <20190703163630.GY2640@lahna.fi.intel.com>
On Wed, Jul 03, 2019 at 07:36:30PM +0300, Mika Westerberg wrote:
> On Wed, Jul 03, 2019 at 05:56:12PM +0300, Andy Shevchenko wrote:
> > Use the new helper that wraps the calls to platform_get_resource()
> > and devm_ioremap_resource() together.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> For the whole series,
>
> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Pushed to my review and testing queue, thanks!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1] pinctrl: intel: Drop double check for data in intel_pinctrl_probe_by_uid()
From: Andy Shevchenko @ 2019-07-23 15:51 UTC (permalink / raw)
To: Mika Westerberg; +Cc: linux-gpio, Linus Walleij
In-Reply-To: <20190704131321.GK2640@lahna.fi.intel.com>
On Thu, Jul 04, 2019 at 04:13:21PM +0300, Mika Westerberg wrote:
> On Thu, Jul 04, 2019 at 04:02:39PM +0300, Andy Shevchenko wrote:
> > There is no need to duplicate the check which is done in the common
> > intel_pinctrl_probe().
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Pushed to my review and testing queue, thanks!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v1] pinctrl: intel: Use NSEC_PER_USEC for debounce calculus
From: Andy Shevchenko @ 2019-07-23 15:54 UTC (permalink / raw)
To: Linus Walleij, linux-gpio, Mika Westerberg; +Cc: Andy Shevchenko
Replace hard coded constants with self-explanatory names, i.e.
use NSEC_PER_USEC for debounce calculus.
While here, add a unit suffix to debounce period constant.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/pinctrl/intel/pinctrl-intel.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c
index 3a7876efd4a6..99c5bca789eb 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -8,12 +8,13 @@
*/
#include <linux/acpi.h>
-#include <linux/module.h>
#include <linux/interrupt.h>
#include <linux/gpio/driver.h>
#include <linux/log2.h>
+#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/property.h>
+#include <linux/time.h>
#include <linux/pinctrl/pinctrl.h>
#include <linux/pinctrl/pinmux.h>
@@ -71,7 +72,7 @@
#define PADCFG2_DEBOUNCE_SHIFT 1
#define PADCFG2_DEBOUNCE_MASK GENMASK(4, 1)
-#define DEBOUNCE_PERIOD 31250 /* ns */
+#define DEBOUNCE_PERIOD_NS 31250
struct intel_pad_context {
u32 padcfg0;
@@ -566,7 +567,7 @@ static int intel_config_get(struct pinctrl_dev *pctldev, unsigned int pin,
return -EINVAL;
v = (v & PADCFG2_DEBOUNCE_MASK) >> PADCFG2_DEBOUNCE_SHIFT;
- arg = BIT(v) * DEBOUNCE_PERIOD / 1000;
+ arg = BIT(v) * DEBOUNCE_PERIOD_NS / NSEC_PER_USEC;
break;
}
@@ -683,7 +684,7 @@ static int intel_config_set_debounce(struct intel_pinctrl *pctrl,
if (debounce) {
unsigned long v;
- v = order_base_2(debounce * 1000 / DEBOUNCE_PERIOD);
+ v = order_base_2(debounce * NSEC_PER_USEC / DEBOUNCE_PERIOD_NS);
if (v < 3 || v > 15) {
ret = -EINVAL;
goto exit_unlock;
--
2.20.1
^ permalink raw reply related
* [PATCH v1] pinctrl: intel: Simplify offset validation in intel_get_padcfg()
From: Andy Shevchenko @ 2019-07-23 15:55 UTC (permalink / raw)
To: Linus Walleij, linux-gpio, Mika Westerberg; +Cc: Andy Shevchenko
There is more generic and simpler validation just against the nregs.
Using it allows to drop customization from the intel_get_padcfg().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/pinctrl/intel/pinctrl-intel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c
index 99c5bca789eb..1e8018edde4d 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -166,7 +166,7 @@ static void __iomem *intel_get_padcfg(struct intel_pinctrl *pctrl,
padno = pin_to_padno(community, pin);
nregs = (community->features & PINCTRL_FEATURE_DEBOUNCE) ? 4 : 2;
- if (reg == PADCFG2 && !(community->features & PINCTRL_FEATURE_DEBOUNCE))
+ if (reg >= nregs * 4)
return NULL;
return community->pad_regs + reg + padno * nregs * 4;
--
2.20.1
^ permalink raw reply related
* [PATCH v1 2/8] pinctrl: cannonlake: Provide Interrupt Status register offset
From: Andy Shevchenko @ 2019-07-23 15:56 UTC (permalink / raw)
To: Linus Walleij, linux-gpio, Mika Westerberg; +Cc: Andy Shevchenko
In-Reply-To: <20190723155633.65232-1-andriy.shevchenko@linux.intel.com>
Since some of the GPIO controllers use different Interrupt Status offset,
it make sense to provide it explicitly in the driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/pinctrl/intel/pinctrl-cannonlake.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/intel/pinctrl-cannonlake.c b/drivers/pinctrl/intel/pinctrl-cannonlake.c
index 08024b065033..f51b27bbf9f1 100644
--- a/drivers/pinctrl/intel/pinctrl-cannonlake.c
+++ b/drivers/pinctrl/intel/pinctrl-cannonlake.c
@@ -19,6 +19,7 @@
#define CNL_PADCFGLOCK 0x080
#define CNL_LP_HOSTSW_OWN 0x0b0
#define CNL_H_HOSTSW_OWN 0x0c0
+#define CNL_GPI_IS 0x100
#define CNL_GPI_IE 0x120
#define CNL_GPP(r, s, e, g) \
@@ -37,6 +38,7 @@
.padown_offset = CNL_PAD_OWN, \
.padcfglock_offset = CNL_PADCFGLOCK, \
.hostown_offset = (o), \
+ .is_offset = CNL_GPI_IS, \
.ie_offset = CNL_GPI_IE, \
.pin_base = (s), \
.npins = ((e) - (s) + 1), \
--
2.20.1
^ permalink raw reply related
* [PATCH v1 1/8] pinctrl: broxton: Provide Interrupt Status register offset
From: Andy Shevchenko @ 2019-07-23 15:56 UTC (permalink / raw)
To: Linus Walleij, linux-gpio, Mika Westerberg; +Cc: Andy Shevchenko
Since some of the GPIO controllers use different Interrupt Status offset,
it make sense to provide it explicitly in the driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/pinctrl/intel/pinctrl-broxton.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/intel/pinctrl-broxton.c b/drivers/pinctrl/intel/pinctrl-broxton.c
index e2d4505d6747..2be7e414f803 100644
--- a/drivers/pinctrl/intel/pinctrl-broxton.c
+++ b/drivers/pinctrl/intel/pinctrl-broxton.c
@@ -15,8 +15,9 @@
#include "pinctrl-intel.h"
#define BXT_PAD_OWN 0x020
-#define BXT_HOSTSW_OWN 0x080
#define BXT_PADCFGLOCK 0x060
+#define BXT_HOSTSW_OWN 0x080
+#define BXT_GPI_IS 0x100
#define BXT_GPI_IE 0x110
#define BXT_COMMUNITY(s, e) \
@@ -24,6 +25,7 @@
.padown_offset = BXT_PAD_OWN, \
.padcfglock_offset = BXT_PADCFGLOCK, \
.hostown_offset = BXT_HOSTSW_OWN, \
+ .is_offset = BXT_GPI_IS, \
.ie_offset = BXT_GPI_IE, \
.gpp_size = 32, \
.pin_base = (s), \
--
2.20.1
^ permalink raw reply related
* [PATCH v1 5/8] pinctrl: sunrisepoint: Provide Interrupt Status register offset
From: Andy Shevchenko @ 2019-07-23 15:56 UTC (permalink / raw)
To: Linus Walleij, linux-gpio, Mika Westerberg; +Cc: Andy Shevchenko
In-Reply-To: <20190723155633.65232-1-andriy.shevchenko@linux.intel.com>
Since some of the GPIO controllers use different Interrupt Status offset,
it make sense to provide it explicitly in the driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/pinctrl/intel/pinctrl-sunrisepoint.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/intel/pinctrl-sunrisepoint.c b/drivers/pinctrl/intel/pinctrl-sunrisepoint.c
index ccafeea4939c..44d7f50bbc82 100644
--- a/drivers/pinctrl/intel/pinctrl-sunrisepoint.c
+++ b/drivers/pinctrl/intel/pinctrl-sunrisepoint.c
@@ -18,6 +18,7 @@
#define SPT_PAD_OWN 0x020
#define SPT_PADCFGLOCK 0x0a0
#define SPT_HOSTSW_OWN 0x0d0
+#define SPT_GPI_IS 0x100
#define SPT_GPI_IE 0x120
#define SPT_COMMUNITY(b, s, e) \
@@ -26,6 +27,7 @@
.padown_offset = SPT_PAD_OWN, \
.padcfglock_offset = SPT_PADCFGLOCK, \
.hostown_offset = SPT_HOSTSW_OWN, \
+ .is_offset = SPT_GPI_IS, \
.ie_offset = SPT_GPI_IE, \
.gpp_size = 24, \
.gpp_num_padown_regs = 4, \
--
2.20.1
^ permalink raw reply related
* [PATCH v1 4/8] pinctrl: icelake: Provide Interrupt Status register offset
From: Andy Shevchenko @ 2019-07-23 15:56 UTC (permalink / raw)
To: Linus Walleij, linux-gpio, Mika Westerberg; +Cc: Andy Shevchenko
In-Reply-To: <20190723155633.65232-1-andriy.shevchenko@linux.intel.com>
Since some of the GPIO controllers use different Interrupt Status offset,
it make sense to provide it explicitly in the driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/pinctrl/intel/pinctrl-icelake.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/intel/pinctrl-icelake.c b/drivers/pinctrl/intel/pinctrl-icelake.c
index 5f2f5c61ad41..6489e9bbb61f 100644
--- a/drivers/pinctrl/intel/pinctrl-icelake.c
+++ b/drivers/pinctrl/intel/pinctrl-icelake.c
@@ -18,6 +18,7 @@
#define ICL_PAD_OWN 0x020
#define ICL_PADCFGLOCK 0x080
#define ICL_HOSTSW_OWN 0x0b0
+#define ICL_GPI_IS 0x100
#define ICL_GPI_IE 0x110
#define ICL_GPP(r, s, e, g) \
@@ -36,6 +37,7 @@
.padown_offset = ICL_PAD_OWN, \
.padcfglock_offset = ICL_PADCFGLOCK, \
.hostown_offset = ICL_HOSTSW_OWN, \
+ .is_offset = ICL_GPI_IS, \
.ie_offset = ICL_GPI_IE, \
.pin_base = (s), \
.npins = ((e) - (s) + 1), \
--
2.20.1
^ permalink raw reply related
* [PATCH v1 3/8] pinctrl: geminilake: Provide Interrupt Status register offset
From: Andy Shevchenko @ 2019-07-23 15:56 UTC (permalink / raw)
To: Linus Walleij, linux-gpio, Mika Westerberg; +Cc: Andy Shevchenko
In-Reply-To: <20190723155633.65232-1-andriy.shevchenko@linux.intel.com>
Since some of the GPIO controllers use different Interrupt Status offset,
it make sense to provide it explicitly in the driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/pinctrl/intel/pinctrl-geminilake.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/intel/pinctrl-geminilake.c b/drivers/pinctrl/intel/pinctrl-geminilake.c
index b49a484754b9..de96aa9794a2 100644
--- a/drivers/pinctrl/intel/pinctrl-geminilake.c
+++ b/drivers/pinctrl/intel/pinctrl-geminilake.c
@@ -17,6 +17,7 @@
#define GLK_PAD_OWN 0x020
#define GLK_PADCFGLOCK 0x080
#define GLK_HOSTSW_OWN 0x0b0
+#define GLK_GPI_IS 0x100
#define GLK_GPI_IE 0x110
#define GLK_COMMUNITY(s, e) \
@@ -24,6 +25,7 @@
.padown_offset = GLK_PAD_OWN, \
.padcfglock_offset = GLK_PADCFGLOCK, \
.hostown_offset = GLK_HOSTSW_OWN, \
+ .is_offset = GLK_GPI_IS, \
.ie_offset = GLK_GPI_IE, \
.gpp_size = 32, \
.pin_base = (s), \
--
2.20.1
^ permalink raw reply related
* [PATCH v1 7/8] pinctrl: lewisburg: Provide Interrupt Status register offset
From: Andy Shevchenko @ 2019-07-23 15:56 UTC (permalink / raw)
To: Linus Walleij, linux-gpio, Mika Westerberg; +Cc: Andy Shevchenko
In-Reply-To: <20190723155633.65232-1-andriy.shevchenko@linux.intel.com>
Since some of the GPIO controllers use different Interrupt Status offset,
it make sense to provide it explicitly in the driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/pinctrl/intel/pinctrl-lewisburg.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/intel/pinctrl-lewisburg.c b/drivers/pinctrl/intel/pinctrl-lewisburg.c
index 03b04c7ae9e8..2e06fb1464ab 100644
--- a/drivers/pinctrl/intel/pinctrl-lewisburg.c
+++ b/drivers/pinctrl/intel/pinctrl-lewisburg.c
@@ -17,6 +17,7 @@
#define LBG_PAD_OWN 0x020
#define LBG_PADCFGLOCK 0x060
#define LBG_HOSTSW_OWN 0x080
+#define LBG_GPI_IS 0x100
#define LBG_GPI_IE 0x110
#define LBG_COMMUNITY(b, s, e) \
@@ -25,6 +26,7 @@
.padown_offset = LBG_PAD_OWN, \
.padcfglock_offset = LBG_PADCFGLOCK, \
.hostown_offset = LBG_HOSTSW_OWN, \
+ .is_offset = LBG_GPI_IS, \
.ie_offset = LBG_GPI_IE, \
.gpp_size = 24, \
.pin_base = (s), \
--
2.20.1
^ permalink raw reply related
* [PATCH v1 6/8] pinctrl: denverton: Provide Interrupt Status register offset
From: Andy Shevchenko @ 2019-07-23 15:56 UTC (permalink / raw)
To: Linus Walleij, linux-gpio, Mika Westerberg; +Cc: Andy Shevchenko
In-Reply-To: <20190723155633.65232-1-andriy.shevchenko@linux.intel.com>
Since some of the GPIO controllers use different Interrupt Status offset,
it make sense to provide it explicitly in the driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/pinctrl/intel/pinctrl-denverton.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/intel/pinctrl-denverton.c b/drivers/pinctrl/intel/pinctrl-denverton.c
index 3a4932b557b4..fde83cd4aac5 100644
--- a/drivers/pinctrl/intel/pinctrl-denverton.c
+++ b/drivers/pinctrl/intel/pinctrl-denverton.c
@@ -15,8 +15,9 @@
#include "pinctrl-intel.h"
#define DNV_PAD_OWN 0x020
-#define DNV_HOSTSW_OWN 0x0C0
#define DNV_PADCFGLOCK 0x090
+#define DNV_HOSTSW_OWN 0x0C0
+#define DNV_GPI_IS 0x100
#define DNV_GPI_IE 0x120
#define DNV_GPP(n, s, e) \
@@ -32,6 +33,7 @@
.padown_offset = DNV_PAD_OWN, \
.padcfglock_offset = DNV_PADCFGLOCK, \
.hostown_offset = DNV_HOSTSW_OWN, \
+ .is_offset = DNV_GPI_IS, \
.ie_offset = DNV_GPI_IE, \
.pin_base = (s), \
.npins = ((e) - (s) + 1), \
--
2.20.1
^ permalink raw reply related
* [PATCH v1 8/8] pinctrl: intel: Remove default Interrupt Status offset
From: Andy Shevchenko @ 2019-07-23 15:56 UTC (permalink / raw)
To: Linus Walleij, linux-gpio, Mika Westerberg; +Cc: Andy Shevchenko
In-Reply-To: <20190723155633.65232-1-andriy.shevchenko@linux.intel.com>
Since some of the GPIO controllers use different Interrupt Status offset,
it make sense to provide it explicitly in the drivers.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/pinctrl/intel/pinctrl-intel.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c
index 1e8018edde4d..3a945997b8eb 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -30,7 +30,6 @@
#define REVID_MASK GENMASK(31, 16)
#define PADBAR 0x00c
-#define GPI_IS 0x100
#define PADOWN_BITS 4
#define PADOWN_SHIFT(p) ((p) % 8 * PADOWN_BITS)
@@ -1343,9 +1342,6 @@ static int intel_pinctrl_probe(struct platform_device *pdev,
community->regs = regs;
community->pad_regs = regs + padbar;
- if (!community->is_offset)
- community->is_offset = GPI_IS;
-
ret = intel_pinctrl_add_padgroups(pctrl, community);
if (ret)
return ret;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2] gpio: pch: Use dev_get_drvdata
From: Andy Shevchenko @ 2019-07-23 15:59 UTC (permalink / raw)
To: Bartosz Golaszewski; +Cc: Chuhong Yuan, Linus Walleij, linux-gpio, LKML
In-Reply-To: <CAMpxmJXkg8wiLOj9rQs+aNx+_oqb_tUWeELmrWQd7GXi-qAueA@mail.gmail.com>
On Tue, Jul 23, 2019 at 11:49:46AM +0200, Bartosz Golaszewski wrote:
> wt., 23 lip 2019 o 10:39 Chuhong Yuan <hslester96@gmail.com> napisał(a):
> >
> > Instead of using to_pci_dev + pci_get_drvdata,
> > use dev_get_drvdata to make code simpler.
> >
> > Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> > ---
> > Changes in v2:
> > - Change the subject line to gpio: pch: ...
> >
> > drivers/gpio/gpio-pch.c | 6 ++----
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c
> > index 1d99293096f2..3f3d9a94b709 100644
> > --- a/drivers/gpio/gpio-pch.c
> > +++ b/drivers/gpio/gpio-pch.c
> > @@ -409,8 +409,7 @@ static int pch_gpio_probe(struct pci_dev *pdev,
> >
> > static int __maybe_unused pch_gpio_suspend(struct device *dev)
> > {
> > - struct pci_dev *pdev = to_pci_dev(dev);
> > - struct pch_gpio *chip = pci_get_drvdata(pdev);
> > + struct pch_gpio *chip = dev_get_drvdata(dev);
> > unsigned long flags;
> >
> > spin_lock_irqsave(&chip->spinlock, flags);
> > @@ -422,8 +421,7 @@ static int __maybe_unused pch_gpio_suspend(struct device *dev)
> >
> > static int __maybe_unused pch_gpio_resume(struct device *dev)
> > {
> > - struct pci_dev *pdev = to_pci_dev(dev);
> > - struct pch_gpio *chip = pci_get_drvdata(pdev);
> > + struct pch_gpio *chip = dev_get_drvdata(dev);
> > unsigned long flags;
> >
> > spin_lock_irqsave(&chip->spinlock, flags);
> > --
> > 2.20.1
> >
>
> Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Pushed to my review and testing queue, thanks!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 00/18] ARM: Add minimal Raspberry Pi 4 support
From: Stefan Wahren @ 2019-07-23 16:26 UTC (permalink / raw)
To: Nicolas Saenz Julienne, Christoph Hellwig
Cc: Eric Anholt, Florian Fainelli, Ray Jui, Scott Branden,
Matthias Brugger, Rob Herring, Mark Rutland, Linus Walleij,
Michael Turquette, Stephen Boyd, Ulf Hansson, Adrian Hunter,
bcm-kernel-feedback-list, linux-arm-kernel, linux-rpi-kernel,
linux-gpio, linux-mmc
In-Reply-To: <04c5eaa03f3a124dbbce6186e11e19acc4539cc8.camel@suse.de>
Hi Nicolas,
thanks for your work, but i'm a little bit sceptical about these
changes. So here some thoughts.
Am 23.07.19 um 15:32 schrieb Nicolas Saenz Julienne:
> On Tue, 2019-07-23 at 11:34 +0200, Christoph Hellwig wrote:
>> On Mon, Jul 22, 2019 at 08:10:17PM +0200, Stefan Wahren wrote:
>>> i rebased this series also and got this only on the RPi 4.
>>>
>>> After reverting the following:
>>>
>>> 79a986721de dma-mapping: remove dma_max_pfn
>>> 7559d612dff0 mmc: core: let the dma map ops handle bouncing
>>>
>>> This crash disappear, but wifi seems to be still broken.
>>>
>>> Would be nice, if you can investigate further.
>> That means dma addressing on this system doesn't just work for some
>> memory, and the mmc bounce buffering was papering over that just for
>> mmc. Do you have highmem on this system?
>>
>> You might want to try this series, which has been submitted upstream:
>>
>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/arm-swiotlb
> Hi Christoph,
> I tried your series on top of Stefan's, it has no effect. I guess it's no
> surprise as with mult_v7_defconfig, you get SWIOTLB=n & LPAE=n.
>
> FYI DMA addressing constraints for RPi4 are the following: devices can only
> access the first GB of ram even though the board might have up to 4GB of ram.
> The DMA addresses are aliased with a 0xc0000000 offset. So 0x00000000 phys is
> aliased to 0xc0000000 in DMA. This is the same as for an RFC you commented last
> week trying to fix similar issues for arm64.
>
> You state in "arm: use swiotlb for bounce buffer on LPAE configs" that "The DMA
> API requires that 32-bit DMA masks are always supported". If I understand it
> correctly this device breaks that assumption. Which implies we need a bounce
> buffer system in place for any straming DMA user.
>
> It seems we're unable to use dma-direct/swiotlb, so I enabled arm's dmabounce
> on all devices hooked into RPi's limited interconnect, which fixes this issue.
Does it fix the wifi issue too?
> Any thoughts on this?
>
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index 5e5f1fabc3d4..3db8deed83a6 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -168,6 +168,7 @@ config ARCH_BCM2835
> select PINCTRL
> select PINCTRL_BCM2835
> select MFD_CORE
> + select DMABOUNCE
> help
> This enables support for the Broadcom BCM2835 and BCM2836 SoCs.
> This SoC is used in the Raspberry Pi and Roku 2 devices.
> diff --git a/arch/arm/mach-bcm/board_bcm2835.c b/arch/arm/mach-bcm/board_bcm2835.c
> index c09cf25596af..be788849c4bb 100644
> --- a/arch/arm/mach-bcm/board_bcm2835.c
> +++ b/arch/arm/mach-bcm/board_bcm2835.c
> @@ -3,6 +3,8 @@
> * Copyright (C) 2010 Broadcom
> */
>
> +#include <linux/device.h>
> +#include <linux/dma-mapping.h>
> #include <linux/init.h>
> #include <linux/irqchip.h>
> #include <linux/of_address.h>
> @@ -24,8 +26,37 @@ static const char * const bcm2835_compat[] = {
> NULL
> };
>
> +static int bcm2835_needs_bounce(struct device *dev, dma_addr_t dma_addr, size_t size)
> +{
> + /*
> + * The accepted dma addresses are [0xc0000000, 0xffffffff] which map to
> + * ram's [0x00000000, 0x3fffffff].
> + */
> + return dma_addr < 3ULL * SZ_1G;
> +}
> +
> +/*
> + * Setup DMA mask to 1GB on devices hanging from soc interconnect
> + */
> +static int bcm2835_platform_notify(struct device *dev)
> +{
> + if (dev->parent && !strcmp("soc", dev_name(dev->parent))) {
> + dev->dma_mask = &dev->coherent_dma_mask;
> + dev->coherent_dma_mask = DMA_BIT_MASK(30); /* 1GB */
Shouldn't this come from the device tree?
> + dmabounce_register_dev(dev, 2048, 4096, bcm2835_needs_bounce);
> + }
> +
> + return 0;
> +}
> +
> +void __init bcm2835_init_early(void)
> +{
> + platform_notify = bcm2835_platform_notify;
> +}
> +
> DT_MACHINE_START(BCM2835, "BCM2835")
> .dma_zone_size = SZ_1G,
> .dt_compat = bcm2835_compat,
> .smp = smp_ops(bcm2836_smp_ops),
> + .init_early = bcm2835_init_early,
The sum of all these changes make me think, that we should start a new
board for BCM2711 instead of extending BCM2835.
Best regards
Stefan Wahren
> MACHINE_END
>
> Regards,
> Nicolas
>
^ 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