* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Sudeep Holla @ 2020-06-03 18:31 UTC (permalink / raw)
To: Jassi Brar
Cc: Devicetree List, Arnd Bergmann, Viresh Kumar,
Linux Kernel Mailing List, Bjorn Andersson, Rob Herring,
Sudeep Holla, Frank Rowand, linux-arm-kernel
In-Reply-To: <CABb+yY30nmbBUzYG62xGEbrr7107h_Edyq3jKPheZAQ0Cvr9Yg@mail.gmail.com>
On Mon, May 18, 2020 at 11:05:03PM -0500, Jassi Brar wrote:
> On Mon, May 18, 2020 at 10:40 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> >
> > On 18-05-20, 18:29, Bjorn Andersson wrote:
> > > On Thu 14 May 22:17 PDT 2020, Viresh Kumar wrote:
> > > > This stuff has been doing rounds on the mailing list since several years
> > > > now with no agreed conclusion by all the parties. And here is another
> > > > attempt to get some feedback from everyone involved to close this once
> > > > and for ever. Your comments will very much be appreciated.
> > > >
> > > > The ARM MHU is defined here in the TRM [1] for your reference, which
> > > > states following:
> > > >
> > > > "The MHU drives the signal using a 32-bit register, with all 32
> > > > bits logically ORed together. The MHU provides a set of
> > > > registers to enable software to set, clear, and check the status
> > > > of each of the bits of this register independently. The use of
> > > > 32 bits for each interrupt line enables software to provide more
> > > > information about the source of the interrupt. For example, each
> > > > bit of the register can be associated with a type of event that
> > > > can contribute to raising the interrupt."
> > > >
> > >
> > > Does this mean that there are 32 different signals and they are all ORed
> > > into the same interrupt line to trigger software action when something
> > > happens?
> > >
> > > Or does it mean that this register is used to pass multi-bit information
> > > and when any such information is passed an interrupt will be triggered?
> > > If so, what does that information mean? How is it tied into other Linux
> > > drivers/subsystems?
> >
> > I have started to believe the hardware is written badly at this point
> > :)
> >
> H/W is actually fine :) Its just that the driver is written to
> _also_ support a platform (my original) that doesn't have shmem and
> need to pass data via 32bit registers.
> Frankly, I am not against the doorbell mode, I am against implementing
> two modes in a driver. If it really helped (note the past tense) the
> SCMI, we could implement the driver only in doorbell mode but
> unfortunately SCMI would still be _broken_ for non-doorbell
> controllers.
Should be fine as the specification is designed to work with only shmem
for any data transfer and mailbox is just a signal mechanism. I won't
be too worried about that.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Jassi Brar @ 2020-06-03 18:32 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rob Herring, Arnd Bergmann, Devicetree List, Viresh Kumar,
Linux Kernel Mailing List, Bjorn Andersson, Frank Rowand,
linux-arm-kernel
In-Reply-To: <20200603180435.GB23722@bogus>
On Wed, Jun 3, 2020 at 1:04 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Fri, May 29, 2020 at 09:37:58AM +0530, Viresh Kumar wrote:
> > On 28-05-20, 13:20, Rob Herring wrote:
> > > Whether Linux
> > > requires serializing mailbox accesses is a separate issue. On that side,
> > > it seems silly to not allow driving the h/w in the most efficient way
> > > possible.
> >
> > That's exactly what we are trying to say. The hardware allows us to
> > write all 32 bits in parallel, without any hardware issues, why
> > shouldn't we do that ? The delay (which Sudeep will find out, he is
> > facing issues with hardware access because of lockdown right now)
>
> OK, I was able to access the setup today. I couldn't reach a point
> where I can do measurements as the system just became unusable with
> one physical channel instead of 2 virtual channels as in my patches.
>
> My test was simple. Switch to schedutil and read sensors periodically
> via sysfs.
>
> arm-scmi firmware:scmi: message for 1 is not expected!
>
This sounds like you are not serialising requests on a shared channel.
Can you please also share the patch?
Thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] engine: stm32-dma: call pm_runtime_put if pm_runtime_get_sync fails
From: Navid Emamdoost @ 2020-06-03 18:34 UTC (permalink / raw)
To: Dan Williams, Vinod Koul, Maxime Coquelin, Alexandre Torgue,
dmaengine, linux-stm32, linux-arm-kernel, linux-kernel
Cc: Navid Emamdoost, emamd001, kjlu, wu000273, smccaman
Calling pm_runtime_get_sync increments the counter even in case of
failure, causing incorrect ref count. Call pm_runtime_put if
pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
---
drivers/dma/stm32-dma.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index 0ddbaa4b4f0b..0aab86bd97fe 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -1169,8 +1169,10 @@ static int stm32_dma_alloc_chan_resources(struct dma_chan *c)
chan->config_init = false;
ret = pm_runtime_get_sync(dmadev->ddev.dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put(dmadev->ddev.dev);
return ret;
+ }
ret = stm32_dma_disable_chan(chan);
if (ret < 0)
@@ -1439,8 +1441,10 @@ static int stm32_dma_suspend(struct device *dev)
int id, ret, scr;
ret = pm_runtime_get_sync(dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_sync(dev);
return ret;
+ }
for (id = 0; id < STM32_DMA_MAX_CHANNELS; id++) {
scr = stm32_dma_read(dmadev, STM32_DMA_SCR(id));
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Jassi Brar @ 2020-06-03 18:42 UTC (permalink / raw)
To: Sudeep Holla
Cc: Devicetree List, Arnd Bergmann, Viresh Kumar,
Linux Kernel Mailing List, Bjorn Andersson, Rob Herring,
Frank Rowand, linux-arm-kernel
In-Reply-To: <20200603183120.GE23722@bogus>
On Wed, Jun 3, 2020 at 1:31 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> > >
> > H/W is actually fine :) Its just that the driver is written to
> > _also_ support a platform (my original) that doesn't have shmem and
> > need to pass data via 32bit registers.
> > Frankly, I am not against the doorbell mode, I am against implementing
> > two modes in a driver. If it really helped (note the past tense) the
> > SCMI, we could implement the driver only in doorbell mode but
> > unfortunately SCMI would still be _broken_ for non-doorbell
> > controllers.
>
> Should be fine as the specification is designed to work with only shmem
> for any data transfer and mailbox is just a signal mechanism. I won't
> be too worried about that.
>
Please clarify how it will work on, say again, rockchip platform with shmem.
thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Re: [RESEND PATCH v5 5/5] Documentation/vmcoreinfo: Add documentation for 'TCR_EL1.T1SZ'
From: Scott Branden @ 2020-06-03 18:47 UTC (permalink / raw)
To: Bhupesh Sharma, James Morse, linux-kernel
Cc: Mark Rutland, Ard Biesheuvel, linux-doc, Catalin Marinas, x86,
kexec, linuxppc-dev, Kazuhito Hagio, Dave Anderson, bhupesh.linux,
Will Deacon, linux-arm-kernel, Steve Capper
In-Reply-To: <b7d8d603-d9fe-3e18-c754-baf2015acd16@redhat.com>
Hi Bhupesh,
Would be great to get this patch series upstreamed?
On 2019-12-25 10:49 a.m., Bhupesh Sharma wrote:
> Hi James,
>
> On 12/12/2019 04:02 PM, James Morse wrote:
>> Hi Bhupesh,
>
> I am sorry this review mail skipped my attention due to holidays and
> focus on other urgent issues.
>
>> On 29/11/2019 19:59, Bhupesh Sharma wrote:
>>> Add documentation for TCR_EL1.T1SZ variable being added to
>>> vmcoreinfo.
>>>
>>> It indicates the size offset of the memory region addressed by
>>> TTBR1_EL1
>>
>>> and hence can be used for determining the vabits_actual value.
>>
>> used for determining random-internal-kernel-variable, that might not
>> exist tomorrow.
>>
>> Could you describe how this is useful/necessary if a debugger wants
>> to walk the page
>> tables from the core file? I think this is a better argument.
>>
>> Wouldn't the documentation be better as part of the patch that adds
>> the export?
>> (... unless these have to go via different trees? ..)
>
> Ok, will fix the same in v6 version.
>
>>> diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
>>> b/Documentation/admin-guide/kdump/vmcoreinfo.rst
>>> index 447b64314f56..f9349f9d3345 100644
>>> --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
>>> +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
>>> @@ -398,6 +398,12 @@ KERNELOFFSET
>>> The kernel randomization offset. Used to compute the page offset. If
>>> KASLR is disabled, this value is zero.
>>> +TCR_EL1.T1SZ
>>> +------------
>>> +
>>> +Indicates the size offset of the memory region addressed by TTBR1_EL1
>>
>>> +and hence can be used for determining the vabits_actual value.
>>
>> 'vabits_actual' may not exist when the next person comes to read this
>> documentation (its
>> going to rot really quickly).
>>
>> I think the first half of this text is enough to say what this is
>> for. You should include
>> words to the effect that its the hardware value that goes with
>> swapper_pg_dir. You may
>> want to point readers to the arm-arm for more details on what the
>> value means.
>
> Ok, got it. Fixed this in v6, which should be on its way shortly.
I can't seem to find v6?
>
> Thanks,
> Bhupesh
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 08/14] powerpc: add support for folded p4d page tables
From: Andrew Morton @ 2020-06-03 19:05 UTC (permalink / raw)
To: Mike Rapoport
Cc: Rich Felker, linux-ia64, Geert Uytterhoeven, linux-sh,
Benjamin Herrenschmidt, linux-mm, Paul Mackerras, linux-hexagon,
Will Deacon, kvmarm, Jonas Bonn, linux-arch, Brian Cain,
Marc Zyngier, Russell King, Ley Foon Tan, Mike Rapoport,
Catalin Marinas, Julien Thierry, uclinux-h8-devel, Fenghua Yu,
Arnd Bergmann, Suzuki K Poulose, kvm-ppc, Stefan Kristiansson,
openrisc, Stafford Horne, Guan Xuetao, linux-arm-kernel,
Christophe Leroy, Tony Luck, Yoshinori Sato, linux-kernel,
James Morse, Michael Ellerman, nios2-dev, linuxppc-dev
In-Reply-To: <20200414153455.21744-9-rppt@kernel.org>
On Tue, 14 Apr 2020 18:34:49 +0300 Mike Rapoport <rppt@kernel.org> wrote:
> Implement primitives necessary for the 4th level folding, add walks of p4d
> level where appropriate and replace 5level-fixup.h with pgtable-nop4d.h.
A bunch of new material just landed in linux-next/powerpc.
The timing is awkward! I trust this will be going into mainline during
this merge window? If not, please drop it and repull after -rc1.
arch/powerpc/mm/ptdump/ptdump.c:walk_pagetables() was a problem.
Here's what I ended up with - please check.
static void walk_pagetables(struct pg_state *st)
{
unsigned int i;
unsigned long addr = st->start_address & PGDIR_MASK;
pgd_t *pgd = pgd_offset_k(addr);
/*
* Traverse the linux pagetable structure and dump pages that are in
* the hash pagetable.
*/
for (i = pgd_index(addr); i < PTRS_PER_PGD; i++, pgd++, addr += PGDIR_SIZE) {
p4d_t *p4d = p4d_offset(pgd, 0);
if (pgd_none(*pgd) || pgd_is_leaf(*pgd))
note_page(st, addr, 1, p4d_val(*p4d), PGDIR_SIZE);
else if (is_hugepd(__hugepd(p4d_val(*p4d))))
walk_hugepd(st, (hugepd_t *)pgd, addr, PGDIR_SHIFT, 1);
else
/* pgd exists */
walk_pud(st, p4d, addr);
}
}
Mike's series "mm: consolidate definitions of page table accessors"
took quite a lot of damage as well. Patches which needed rework as a
result of this were:
powerpc-add-support-for-folded-p4d-page-tables-fix.patch
mm-introduce-include-linux-pgtableh.patch
mm-reorder-includes-after-introduction-of-linux-pgtableh.patch
mm-pgtable-add-shortcuts-for-accessing-kernel-pmd-and-pte.patch
mm-pgtable-add-shortcuts-for-accessing-kernel-pmd-and-pte-fix-2.patch
mm-consolidate-pte_index-and-pte_offset_-definitions.patch
mm-consolidate-pmd_index-and-pmd_offset-definitions.patch
mm-consolidate-pud_index-and-pud_offset-definitions.patch
mm-consolidate-pgd_index-and-pgd_offset_k-definitions.patch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dmaengine: stm32-mdma: call pm_runtime_put if pm_runtime_get_sync fails
From: Navid Emamdoost @ 2020-06-03 19:17 UTC (permalink / raw)
To: Markus Elfring
Cc: Maxime Coquelin, Alexandre Torgue, kernel-janitors, Kangjie Lu,
LKML, Vinod Koul, Navid Emamdoost, Qiushi Wu, Stephen McCamant,
dmaengine, Dan Williams, linux-stm32, linux-arm-kernel
In-Reply-To: <873bfb31-52d8-7c9b-5480-4a94dc945307@web.de>
On Wed, Jun 3, 2020 at 1:52 PM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> > Calling pm_runtime_get_sync increments the counter even in case of
> > failure, causing incorrect ref count. Call pm_runtime_put if
> > pm_runtime_get_sync fails.
>
> Is it appropriate to copy a sentence from the change description
> into the patch subject?
>
> How do you think about a wording variant like the following?
Please stop proposing rewording on my patches!
I will consider updating my patches only if a maintainer asks for it.
>
> The PM runtime reference counter is generally incremented by a call of
> the function “pm_runtime_get_sync”.
> Thus call the function “pm_runtime_put” also in two error cases
> to keep the reference counting consistent.
>
>
> Would you like to add the tag “Fixes” to the commit message?
>
> Regards,
> Markus
--
Navid.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 03/13] dt-bindings: PCI: Add bindings for more Brcmstb chips
From: Jim Quinlan @ 2020-06-03 19:20 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, open list, Rob Herring,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Jim Quinlan, Bjorn Helgaas,
moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE
In-Reply-To: <20200603192058.35296-1-james.quinlan@broadcom.com>
From: Jim Quinlan <jquinlan@broadcom.com>
- Add compatible strings for three more Broadcom STB chips: 7278, 7216,
7211 (STB version of RPi4).
- add new property 'brcm,scb-sizes'
- add new property 'resets'
- add new property 'reset-names' for 7216 only
- allow 'ranges' and 'dma-ranges' to have more than one item and update
the example to show this.
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
.../bindings/pci/brcm,stb-pcie.yaml | 58 ++++++++++++++++---
1 file changed, 51 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
index 8680a0f86c5a..4a012d77513f 100644
--- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
@@ -9,12 +9,15 @@ title: Brcmstb PCIe Host Controller Device Tree Bindings
maintainers:
- Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
-allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
-
properties:
compatible:
- const: brcm,bcm2711-pcie # The Raspberry Pi 4
+ items:
+ - enum:
+ - brcm,bcm2711-pcie # The Raspberry Pi 4
+ - brcm,bcm7211-pcie # Broadcom STB version of RPi4
+ - brcm,bcm7278-pcie # Broadcom 7278 Arm
+ - brcm,bcm7216-pcie # Broadcom 7216 Arm
+ - brcm,bcm7445-pcie # Broadcom 7445 Arm
reg:
maxItems: 1
@@ -34,10 +37,12 @@ properties:
- const: msi
ranges:
- maxItems: 1
+ minItems: 1
+ maxItems: 4
dma-ranges:
- maxItems: 1
+ minItems: 1
+ maxItems: 6
clocks:
maxItems: 1
@@ -58,8 +63,33 @@ properties:
aspm-no-l0s: true
+ resets:
+ description: for "brcm,bcm7216-pcie", must be a valid reset
+ phandle pointing to the RESCAL reset controller provider node.
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ reset-names:
+ items:
+ - const: rescal
+
+ brcm,scb-sizes:
+ description: u64 giving the 64bit PCIe memory
+ viewport size of a memory controller. There may be up to
+ three controllers, and each size must be a power of two
+ with a size greater or equal to the amount of memory the
+ controller supports. Note that each memory controller
+ may have two component regions -- base and extended -- so
+ this information cannot be deduced from the dma-ranges.
+
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint64-array
+ - items:
+ minItems: 1
+ maxItems: 3
+
required:
- reg
+ - ranges
- dma-ranges
- "#interrupt-cells"
- interrupts
@@ -68,6 +98,18 @@ required:
- interrupt-map
- msi-controller
+allOf:
+ - $ref: /schemas/pci/pci-bus.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm7216-pcie
+ then:
+ required:
+ - resets
+ - reset-names
+
unevaluatedProperties: false
examples:
@@ -93,7 +135,9 @@ examples:
msi-parent = <&pcie0>;
msi-controller;
ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>;
- dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>;
+ dma-ranges = <0x42000000 0x1 0x00000000 0x0 0x40000000 0x0 0x80000000>,
+ <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>;
brcm,enable-ssc;
+ brcm,scb-sizes = <0x0000000080000000 0x0000000080000000>;
};
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 00/13] PCI: brcmstb: enable PCIe for STB chips
From: Jim Quinlan @ 2020-06-03 19:20 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Ulf Hansson, Oliver Neukum, open list:SUPERH,
open list:REMOTE PROCESSOR REMOTEPROC SUBSYSTEM,
open list:DRM DRIVERS FOR ALLWINNER A10,
open list:LIBATA SUBSYSTEM Serial and Parallel ATA drivers,
Julien Grall, Srinivas Kandagatla, H. Peter Anvin,
open list:STAGING SUBSYSTEM, Rob Herring, Florian Fainelli,
Corey Minyard, Saravana Kannan, Rafael J. Wysocki,
open list:ACPI FOR ARM64 ACPI/arm64, Alan Stern,
open list:ALLWINNER A10 CSI DRIVER,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Joerg Roedel,
Arnd Bergmann, Suzuki K Poulose, Hans de Goede, Mark Brown,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Dan Williams, Andy Shevchenko, moderated list:ARM PORT,
Jens Axboe, Greg Kroah-Hartman, open list:USB SUBSYSTEM,
open list, open list:IOMMU DRIVERS, Stefano Stabellini,
Robin Murphy
v3:
Commit "device core: Introduce multiple dma pfn offsets"
Commit "arm: dma-mapping: Invoke dma offset func if needed"
-- The above two commits have been squashed. More importantly,
the code has been modified so that the functionality for
multiple pfn offsets subsumes the use of dev->dma_pfn_offset.
In fact, dma_pfn_offset is removed and supplanted by
dma_pfn_offset_map, which is a pointer to an array. The
more common case of a uniform offset is now handled as
a map with a single entry, while cases requiring multiple
pfn offsets use a map with multiple entries. Code paths
that used to do this:
dev->dma_pfn_offset = mydrivers_pfn_offset;
have been changed to do this:
attach_uniform_dma_pfn_offset(dev, pfn_offset);
Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
-- Add if/then clause for required props: resets, reset-names (RobH)
-- Change compatible list from const to enum (RobH)
-- Change list of u32-tuples to u64 (RobH)
Commit "of: Include a dev param in of_dma_get_range()"
-- modify of/unittests.c to add NULL param in of_dma_get_range() call.
Commit "device core: Add ability to handle multiple dma offsets"
-- align comment in device.h (AndyS).
-- s/cpu_beg/cpu_start/ and s/dma_beg/dma_start/ in struct
dma_pfn_offset_region (AndyS).
v2:
Commit: "device core: Add ability to handle multiple dma offsets"
o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
o dev->dma_pfn_map => dev->dma_pfn_offset_map
o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
o In device.h: s/const void */const struct dma_pfn_offset_region */
o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since
guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph)
o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now
dev->dma_pfn_offset_map is copied as well.
o Merged two of the DMA commits into one (Christoph).
Commit "arm: dma-mapping: Invoke dma offset func if needed":
o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET
Other commits' changes:
o Removed need for carrying of_id var in priv (Nicolas)
o Commit message rewordings (Bjorn)
o Commit log messages filled to 75 chars (Bjorn)
o devm_reset_control_get_shared())
=> devm_reset_control_get_optional_shared (Philipp)
o Add call to reset_control_assert() in PCIe remove routines (Philipp)
v1:
This patchset expands the usefulness of the Broadcom Settop Box PCIe
controller by building upon the PCIe driver used currently by the
Raspbery Pi. Other forms of this patchset were submitted by me years
ago and not accepted; the major sticking point was the code required
for the DMA remapping needed for the PCIe driver to work [1].
There have been many changes to the DMA and OF subsystems since that
time, making a cleaner and less intrusive patchset possible. This
patchset implements a generalization of "dev->dma_pfn_offset", except
that instead of a single scalar offset it provides for multiple
offsets via a function which depends upon the "dma-ranges" property of
the PCIe host controller. This is required for proper functionality
of the BrcmSTB PCIe controller and possibly some other devices.
[1] https://lore.kernel.org/linux-arm-kernel/1516058925-46522-5-git-send-email-jim2101024@gmail.com/
Jim Quinlan (13):
PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB
ata: ahci_brcm: Fix use of BCM7216 reset controller
dt-bindings: PCI: Add bindings for more Brcmstb chips
PCI: brcmstb: Add bcm7278 reigister info
PCI: brcmstb: Add suspend and resume pm_ops
PCI: brcmstb: Add bcm7278 PERST support
PCI: brcmstb: Add control of rescal reset
of: Include a dev param in of_dma_get_range()
device core: Introduce multiple dma pfn offsets
PCI: brcmstb: Set internal memory viewport sizes
PCI: brcmstb: Accommodate MSI for older chips
PCI: brcmstb: Set bus max burst size by chip type
PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match list
.../bindings/pci/brcm,stb-pcie.yaml | 58 ++-
arch/arm/include/asm/dma-mapping.h | 9 +-
arch/arm/mach-keystone/keystone.c | 9 +-
arch/sh/drivers/pci/pcie-sh7786.c | 3 +-
arch/sh/kernel/dma-coherent.c | 17 +-
arch/x86/pci/sta2x11-fixup.c | 7 +-
drivers/acpi/arm64/iort.c | 5 +-
drivers/ata/ahci_brcm.c | 14 +-
drivers/gpu/drm/sun4i/sun4i_backend.c | 7 +-
drivers/iommu/io-pgtable-arm.c | 2 +-
.../platform/sunxi/sun4i-csi/sun4i_csi.c | 5 +-
.../platform/sunxi/sun6i-csi/sun6i_csi.c | 5 +-
drivers/of/address.c | 97 ++++-
drivers/of/device.c | 10 +-
drivers/of/of_private.h | 8 +-
drivers/of/unittest.c | 2 +-
drivers/pci/controller/Kconfig | 3 +-
drivers/pci/controller/pcie-brcmstb.c | 408 +++++++++++++++---
drivers/remoteproc/remoteproc_core.c | 2 +-
.../staging/media/sunxi/cedrus/cedrus_hw.c | 7 +-
drivers/usb/core/message.c | 4 +-
drivers/usb/core/usb.c | 2 +-
include/linux/device.h | 4 +-
include/linux/dma-direct.h | 16 +-
include/linux/dma-mapping.h | 45 ++
kernel/dma/coherent.c | 11 +-
26 files changed, 631 insertions(+), 129 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 04/13] PCI: brcmstb: Add bcm7278 reigister info
From: Jim Quinlan @ 2020-06-03 19:20 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Rob Herring, Lorenzo Pieralisi, open list, Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Jim Quinlan, Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200603192058.35296-1-james.quinlan@broadcom.com>
From: Jim Quinlan <jquinlan@broadcom.com>
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 108 +++++++++++++++++++++++---
1 file changed, 96 insertions(+), 12 deletions(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 73020b4ff090..7c707e483181 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -120,9 +120,8 @@
#define PCIE_EXT_SLOT_SHIFT 15
#define PCIE_EXT_FUNC_SHIFT 12
-#define PCIE_RGR1_SW_INIT_1 0x9210
#define PCIE_RGR1_SW_INIT_1_PERST_MASK 0x1
-#define PCIE_RGR1_SW_INIT_1_INIT_MASK 0x2
+#define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0
/* PCIe parameters */
#define BRCM_NUM_PCIE_OUT_WINS 0x4
@@ -152,6 +151,76 @@
#define SSC_STATUS_SSC_MASK 0x400
#define SSC_STATUS_PLL_LOCK_MASK 0x800
+#define IDX_ADDR(pcie) \
+ (pcie->reg_offsets[EXT_CFG_INDEX])
+#define DATA_ADDR(pcie) \
+ (pcie->reg_offsets[EXT_CFG_DATA])
+#define PCIE_RGR1_SW_INIT_1(pcie) \
+ (pcie->reg_offsets[RGR1_SW_INIT_1])
+
+enum {
+ RGR1_SW_INIT_1,
+ EXT_CFG_INDEX,
+ EXT_CFG_DATA,
+};
+
+enum {
+ RGR1_SW_INIT_1_INIT_MASK,
+ RGR1_SW_INIT_1_INIT_SHIFT,
+};
+
+enum pcie_type {
+ GENERIC,
+ BCM7278,
+ BCM2711,
+};
+
+struct pcie_cfg_data {
+ const int *reg_field_info;
+ const int *offsets;
+ const enum pcie_type type;
+};
+
+static const int pcie_reg_field_info[] = {
+ [RGR1_SW_INIT_1_INIT_MASK] = 0x2,
+ [RGR1_SW_INIT_1_INIT_SHIFT] = 0x1,
+};
+
+static const int pcie_reg_field_info_bcm7278[] = {
+ [RGR1_SW_INIT_1_INIT_MASK] = 0x1,
+ [RGR1_SW_INIT_1_INIT_SHIFT] = 0x0,
+};
+
+static const int pcie_offsets[] = {
+ [RGR1_SW_INIT_1] = 0x9210,
+ [EXT_CFG_INDEX] = 0x9000,
+ [EXT_CFG_DATA] = 0x9004,
+};
+
+static const struct pcie_cfg_data generic_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offsets,
+ .type = GENERIC,
+};
+
+static const int pcie_offset_bcm7278[] = {
+ [RGR1_SW_INIT_1] = 0xc010,
+ [EXT_CFG_INDEX] = 0x9000,
+ [EXT_CFG_DATA] = 0x9004,
+};
+
+static const struct pcie_cfg_data bcm7278_cfg = {
+ .reg_field_info = pcie_reg_field_info_bcm7278,
+ .offsets = pcie_offset_bcm7278,
+ .type = BCM7278,
+};
+
+static const struct pcie_cfg_data bcm2711_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offsets,
+ .type = BCM2711,
+};
+
struct brcm_msi {
struct device *dev;
void __iomem *base;
@@ -176,6 +245,9 @@ struct brcm_pcie {
int gen;
u64 msi_target_addr;
struct brcm_msi *msi;
+ const int *reg_offsets;
+ const int *reg_field_info;
+ enum pcie_type type;
};
/*
@@ -602,20 +674,21 @@ static struct pci_ops brcm_pcie_ops = {
static inline void brcm_pcie_bridge_sw_init_set(struct brcm_pcie *pcie, u32 val)
{
- u32 tmp;
+ u32 tmp, mask = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_MASK];
+ u32 shift = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_SHIFT];
- tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1);
- u32p_replace_bits(&tmp, val, PCIE_RGR1_SW_INIT_1_INIT_MASK);
- writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1);
+ tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
+ tmp = (tmp & ~mask) | ((val << shift) & mask);
+ writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
}
static inline void brcm_pcie_perst_set(struct brcm_pcie *pcie, u32 val)
{
u32 tmp;
- tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1);
+ tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
u32p_replace_bits(&tmp, val, PCIE_RGR1_SW_INIT_1_PERST_MASK);
- writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1);
+ writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
}
static inline int brcm_pcie_get_rc_bar2_size_and_offset(struct brcm_pcie *pcie,
@@ -924,10 +997,16 @@ static int brcm_pcie_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id brcm_pcie_match[] = {
+ { .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
+ {},
+};
+
static int brcm_pcie_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node, *msi_np;
struct pci_host_bridge *bridge;
+ const struct pcie_cfg_data *data;
struct brcm_pcie *pcie;
struct pci_bus *child;
struct resource *res;
@@ -937,9 +1016,18 @@ static int brcm_pcie_probe(struct platform_device *pdev)
if (!bridge)
return -ENOMEM;
+ data = of_device_get_match_data(&pdev->dev);
+ if (!data) {
+ pr_err("failed to look up compatible string\n");
+ return -EINVAL;
+ }
+
pcie = pci_host_bridge_priv(bridge);
pcie->dev = &pdev->dev;
pcie->np = np;
+ pcie->reg_offsets = data->offsets;
+ pcie->reg_field_info = data->reg_field_info;
+ pcie->type = data->type;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pcie->base = devm_ioremap_resource(&pdev->dev, res);
@@ -1005,10 +1093,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
return ret;
}
-static const struct of_device_id brcm_pcie_match[] = {
- { .compatible = "brcm,bcm2711-pcie" },
- {},
-};
MODULE_DEVICE_TABLE(of, brcm_pcie_match);
static struct platform_driver brcm_pcie_driver = {
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 05/13] PCI: brcmstb: Add suspend and resume pm_ops
From: Jim Quinlan @ 2020-06-03 19:20 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Rob Herring, Lorenzo Pieralisi, open list, Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Jim Quinlan, Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200603192058.35296-1-james.quinlan@broadcom.com>
From: Jim Quinlan <jquinlan@broadcom.com>
Broadcom Set-top (BrcmSTB) boards typically support S2, S3, and S5 suspend
and resume. Now the PCIe driver may do so as well.
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 49 +++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 7c707e483181..f444751e247c 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -979,6 +979,49 @@ static void brcm_pcie_turn_off(struct brcm_pcie *pcie)
brcm_pcie_bridge_sw_init_set(pcie, 1);
}
+static int brcm_pcie_suspend(struct device *dev)
+{
+ struct brcm_pcie *pcie = dev_get_drvdata(dev);
+ int ret = 0;
+
+ brcm_pcie_turn_off(pcie);
+ clk_disable_unprepare(pcie->clk);
+
+ return ret;
+}
+
+static int brcm_pcie_resume(struct device *dev)
+{
+ struct brcm_pcie *pcie = dev_get_drvdata(dev);
+ void __iomem *base;
+ u32 tmp;
+ int ret;
+
+ base = pcie->base;
+ clk_prepare_enable(pcie->clk);
+
+ /* Take bridge out of reset so we can access the SERDES reg */
+ brcm_pcie_bridge_sw_init_set(pcie, 0);
+
+ /* SERDES_IDDQ = 0 */
+ tmp = readl(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
+ u32p_replace_bits(&tmp, 0,
+ PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
+ writel(tmp, base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
+
+ /* wait for serdes to be stable */
+ udelay(100);
+
+ ret = brcm_pcie_setup(pcie);
+ if (ret)
+ return ret;
+
+ if (pcie->msi)
+ brcm_msi_set_regs(pcie->msi);
+
+ return 0;
+}
+
static void __brcm_pcie_remove(struct brcm_pcie *pcie)
{
brcm_msi_remove(pcie);
@@ -1095,12 +1138,18 @@ static int brcm_pcie_probe(struct platform_device *pdev)
MODULE_DEVICE_TABLE(of, brcm_pcie_match);
+static const struct dev_pm_ops brcm_pcie_pm_ops = {
+ .suspend_noirq = brcm_pcie_suspend,
+ .resume_noirq = brcm_pcie_resume,
+};
+
static struct platform_driver brcm_pcie_driver = {
.probe = brcm_pcie_probe,
.remove = brcm_pcie_remove,
.driver = {
.name = "brcm-pcie",
.of_match_table = brcm_pcie_match,
+ .pm = &brcm_pcie_pm_ops,
},
};
module_platform_driver(brcm_pcie_driver);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 06/13] PCI: brcmstb: Add bcm7278 PERST support
From: Jim Quinlan @ 2020-06-03 19:20 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Rob Herring, Lorenzo Pieralisi, open list, Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Jim Quinlan, Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200603192058.35296-1-james.quinlan@broadcom.com>
From: Jim Quinlan <jquinlan@broadcom.com>
The PERST bit was moved to a different register in 7278-type STB chips. In
addition, the polarity of the bit was also changed; for other chips writing
a 1 specified assert; for 7278-type chips, writing a 0 specifies assert.
Signal-wise, PERST is an asserted-low signal.
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index f444751e247c..0bcae9eba048 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -81,6 +81,7 @@
#define PCIE_MISC_PCIE_CTRL 0x4064
#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_MASK 0x1
+#define PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_MASK 0x4
#define PCIE_MISC_PCIE_STATUS 0x4068
#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_MASK 0x80
@@ -686,9 +687,17 @@ static inline void brcm_pcie_perst_set(struct brcm_pcie *pcie, u32 val)
{
u32 tmp;
- tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
- u32p_replace_bits(&tmp, val, PCIE_RGR1_SW_INIT_1_PERST_MASK);
- writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
+ if (pcie->type == BCM7278) {
+ /* Perst bit has moved and assert value is 0 */
+ tmp = readl(pcie->base + PCIE_MISC_PCIE_CTRL);
+ u32p_replace_bits(&tmp,
+ !val, PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_MASK);
+ writel(tmp, pcie->base + PCIE_MISC_PCIE_CTRL);
+ } else {
+ tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
+ u32p_replace_bits(&tmp, val, PCIE_RGR1_SW_INIT_1_PERST_MASK);
+ writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
+ }
}
static inline int brcm_pcie_get_rc_bar2_size_and_offset(struct brcm_pcie *pcie,
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 07/13] PCI: brcmstb: Add control of rescal reset
From: Jim Quinlan @ 2020-06-03 19:20 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Rob Herring, Lorenzo Pieralisi, Jim Quinlan, open list,
Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Philipp Zabel, Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200603192058.35296-1-james.quinlan@broadcom.com>
From: Jim Quinlan <jquinlan@broadcom.com>
Some STB chips have a special purpose reset controller named RESCAL (reset
calibration). The PCIe HW can now control RESCAL to start and stop its
operation.
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 81 ++++++++++++++++++++++++++-
1 file changed, 80 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 0bcae9eba048..fa356bc149c3 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -23,6 +23,7 @@
#include <linux/of_platform.h>
#include <linux/pci.h>
#include <linux/printk.h>
+#include <linux/reset.h>
#include <linux/sizes.h>
#include <linux/slab.h>
#include <linux/string.h>
@@ -152,7 +153,17 @@
#define SSC_STATUS_SSC_MASK 0x400
#define SSC_STATUS_PLL_LOCK_MASK 0x800
-#define IDX_ADDR(pcie) \
+/* Rescal registers */
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL 0xc700
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS 0x3
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_DIG_RESET_MASK 0x4
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_DIG_RESET_SHIFT 0x2
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_RESET_MASK 0x2
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_RESET_SHIFT 0x1
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_MASK 0x1
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_SHIFT 0x0
+
+#define IDX_ADDR(pcie) \
(pcie->reg_offsets[EXT_CFG_INDEX])
#define DATA_ADDR(pcie) \
(pcie->reg_offsets[EXT_CFG_DATA])
@@ -249,6 +260,7 @@ struct brcm_pcie {
const int *reg_offsets;
const int *reg_field_info;
enum pcie_type type;
+ struct reset_control *rescal;
};
/*
@@ -964,6 +976,47 @@ static void brcm_pcie_enter_l23(struct brcm_pcie *pcie)
dev_err(pcie->dev, "failed to enter low-power link state\n");
}
+static int brcm_phy_cntl(struct brcm_pcie *pcie, const int start)
+{
+ static const u32 shifts[PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS] = {
+ PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_SHIFT,
+ PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_RESET_SHIFT,
+ PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_DIG_RESET_SHIFT,};
+ static const u32 masks[PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS] = {
+ PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_MASK,
+ PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_RESET_MASK,
+ PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_DIG_RESET_MASK,};
+ const int beg = start ? 0 : PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS - 1;
+ const int end = start ? PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS : -1;
+ u32 tmp, combined_mask = 0;
+ u32 val = !!start;
+ void __iomem *base = pcie->base;
+ int i;
+
+ for (i = beg; i != end; start ? i++ : i--) {
+ tmp = readl(base + PCIE_DVT_PMU_PCIE_PHY_CTRL);
+ tmp = (tmp & ~masks[i]) | ((val << shifts[i]) & masks[i]);
+ writel(tmp, base + PCIE_DVT_PMU_PCIE_PHY_CTRL);
+ usleep_range(50, 200);
+ combined_mask |= masks[i];
+ }
+
+ tmp = readl(base + PCIE_DVT_PMU_PCIE_PHY_CTRL);
+ val = start ? combined_mask : 0;
+
+ return (tmp & combined_mask) == val ? 0 : -EIO;
+}
+
+static inline int brcm_phy_start(struct brcm_pcie *pcie)
+{
+ return pcie->rescal ? brcm_phy_cntl(pcie, 1) : 0;
+}
+
+static inline int brcm_phy_stop(struct brcm_pcie *pcie)
+{
+ return pcie->rescal ? brcm_phy_cntl(pcie, 0) : 0;
+}
+
static void brcm_pcie_turn_off(struct brcm_pcie *pcie)
{
void __iomem *base = pcie->base;
@@ -994,6 +1047,9 @@ static int brcm_pcie_suspend(struct device *dev)
int ret = 0;
brcm_pcie_turn_off(pcie);
+ ret = brcm_phy_stop(pcie);
+ if (ret)
+ dev_err(pcie->dev, "failed to stop phy\n");
clk_disable_unprepare(pcie->clk);
return ret;
@@ -1009,6 +1065,12 @@ static int brcm_pcie_resume(struct device *dev)
base = pcie->base;
clk_prepare_enable(pcie->clk);
+ ret = brcm_phy_start(pcie);
+ if (ret) {
+ dev_err(pcie->dev, "failed to start phy\n");
+ return ret;
+ }
+
/* Take bridge out of reset so we can access the SERDES reg */
brcm_pcie_bridge_sw_init_set(pcie, 0);
@@ -1035,6 +1097,9 @@ static void __brcm_pcie_remove(struct brcm_pcie *pcie)
{
brcm_msi_remove(pcie);
brcm_pcie_turn_off(pcie);
+ if (brcm_phy_stop(pcie))
+ dev_err(pcie->dev, "failed to stop phy\n");
+ reset_control_assert(pcie->rescal);
clk_disable_unprepare(pcie->clk);
}
@@ -1105,6 +1170,20 @@ static int brcm_pcie_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "could not enable clock\n");
return ret;
}
+ pcie->rescal = devm_reset_control_get_optional_shared(&pdev->dev,
+ "rescal");
+ if (IS_ERR(pcie->rescal))
+ return PTR_ERR(pcie->rescal);
+
+ ret = reset_control_deassert(pcie->rescal);
+ if (ret)
+ dev_err(&pdev->dev, "failed to deassert 'rescal'\n");
+
+ ret = brcm_phy_start(pcie);
+ if (ret) {
+ dev_err(pcie->dev, "failed to start phy\n");
+ return ret;
+ }
ret = brcm_pcie_setup(pcie);
if (ret)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 10/13] PCI: brcmstb: Set internal memory viewport sizes
From: Jim Quinlan @ 2020-06-03 19:20 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Rob Herring, Lorenzo Pieralisi, open list, Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200603192058.35296-1-james.quinlan@broadcom.com>
BrcmSTB PCIe controllers are intimately connected to the memory
controller(s) on the SOC. There is a "viewport" for each memory controller
that allows inbound accesses to CPU memory. Each viewport's size must be
set to a power of two, and that size must be equal to or larger than the
amount of memory each controller supports.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 67 ++++++++++++++++++++-------
1 file changed, 49 insertions(+), 18 deletions(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index fa356bc149c3..338e9ed44230 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -55,6 +55,8 @@
#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x300000
#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_128 0x0
#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf8000000
+#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK 0x07c00000
+#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK 0x0000001f
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO 0x400c
#define PCIE_MEM_WIN0_LO(win) \
@@ -152,6 +154,7 @@
#define SSC_STATUS_OFFSET 0x1
#define SSC_STATUS_SSC_MASK 0x400
#define SSC_STATUS_PLL_LOCK_MASK 0x800
+#define PCIE_BRCM_MAX_MEMC 3
/* Rescal registers */
#define PCIE_DVT_PMU_PCIE_PHY_CTRL 0xc700
@@ -261,6 +264,8 @@ struct brcm_pcie {
const int *reg_field_info;
enum pcie_type type;
struct reset_control *rescal;
+ int num_memc;
+ u64 memc_size[PCIE_BRCM_MAX_MEMC];
};
/*
@@ -717,22 +722,40 @@ static inline int brcm_pcie_get_rc_bar2_size_and_offset(struct brcm_pcie *pcie,
u64 *rc_bar2_offset)
{
struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
- struct device *dev = pcie->dev;
struct resource_entry *entry;
+ struct device *dev = pcie->dev;
+ u64 lowest_pcie_addr = ~(u64)0;
+ int ret, i = 0;
+ u64 size = 0;
- entry = resource_list_first_type(&bridge->dma_ranges, IORESOURCE_MEM);
- if (!entry)
- return -ENODEV;
+ resource_list_for_each_entry(entry, &bridge->dma_ranges) {
+ u64 pcie_beg = entry->res->start - entry->offset;
+ size += entry->res->end - entry->res->start + 1;
+ if (pcie_beg < lowest_pcie_addr)
+ lowest_pcie_addr = pcie_beg;
+ }
- /*
- * The controller expects the inbound window offset to be calculated as
- * the difference between PCIe's address space and CPU's. The offset
- * provided by the firmware is calculated the opposite way, so we
- * negate it.
- */
- *rc_bar2_offset = -entry->offset;
- *rc_bar2_size = 1ULL << fls64(entry->res->end - entry->res->start);
+ ret = of_property_read_variable_u64_array(
+ pcie->np, "brcm,scb-sizes", pcie->memc_size, 1,
+ PCIE_BRCM_MAX_MEMC);
+
+ if (ret <= 0) {
+ /* Make an educated guess */
+ pcie->num_memc = 1;
+ pcie->memc_size[0] = 1 << fls64(size - 1);
+ } else {
+ pcie->num_memc = ret;
+ }
+
+ /* Each memc is viewed through a "port" that is a power of 2 */
+ for (i = 0, size = 0; i < pcie->num_memc; i++)
+ size += pcie->memc_size[i];
+
+ /* System memory starts at this address in PCIe-space */
+ *rc_bar2_offset = lowest_pcie_addr;
+ /* The sum of all memc views must also be a power of 2 */
+ *rc_bar2_size = 1ULL << fls64(size - 1);
/*
* We validate the inbound memory view even though we should trust
@@ -784,12 +807,11 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
void __iomem *base = pcie->base;
struct device *dev = pcie->dev;
struct resource_entry *entry;
- unsigned int scb_size_val;
bool ssc_good = false;
struct resource *res;
int num_out_wins = 0;
u16 nlw, cls, lnksta;
- int i, ret;
+ int i, ret, memc;
u32 tmp, aspm_support;
/* Reset the bridge */
@@ -825,11 +847,20 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
writel(upper_32_bits(rc_bar2_offset),
base + PCIE_MISC_RC_BAR2_CONFIG_HI);
- scb_size_val = rc_bar2_size ?
- ilog2(rc_bar2_size) - 15 : 0xf; /* 0xf is 1GB */
tmp = readl(base + PCIE_MISC_MISC_CTRL);
- u32p_replace_bits(&tmp, scb_size_val,
- PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK);
+ for (memc = 0; memc < pcie->num_memc; memc++) {
+ u32 scb_size_val = ilog2(pcie->memc_size[memc]) - 15;
+
+ if (memc == 0)
+ u32p_replace_bits(&tmp, scb_size_val,
+ PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK);
+ else if (memc == 1)
+ u32p_replace_bits(&tmp, scb_size_val,
+ PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK);
+ else if (memc == 2)
+ u32p_replace_bits(&tmp, scb_size_val,
+ PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK);
+ }
writel(tmp, base + PCIE_MISC_MISC_CTRL);
/*
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 11/13] PCI: brcmstb: Accommodate MSI for older chips
From: Jim Quinlan @ 2020-06-03 19:20 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Rob Herring, Lorenzo Pieralisi, open list, Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Jim Quinlan, Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200603192058.35296-1-james.quinlan@broadcom.com>
From: Jim Quinlan <jquinlan@broadcom.com>
Older BrcmSTB chips do not have a separate register for MSI interrupts; the
MSIs are in a register that also contains unrelated interrupts. In
addition, the interrupts lie in bits [31..24] for these legacy chips. This
commit provides common code for both legacy and non-legacy MSI interrupt
registers.
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 72 +++++++++++++++++++--------
1 file changed, 52 insertions(+), 20 deletions(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 338e9ed44230..9930419e3ac2 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -80,7 +80,8 @@
#define PCIE_MISC_MSI_BAR_CONFIG_HI 0x4048
#define PCIE_MISC_MSI_DATA_CONFIG 0x404c
-#define PCIE_MISC_MSI_DATA_CONFIG_VAL 0xffe06540
+#define PCIE_MISC_MSI_DATA_CONFIG_VAL_32 0xffe06540
+#define PCIE_MISC_MSI_DATA_CONFIG_VAL_8 0xfff86540
#define PCIE_MISC_PCIE_CTRL 0x4064
#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_MASK 0x1
@@ -92,6 +93,9 @@
#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_MASK 0x10
#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK 0x40
+#define PCIE_MISC_REVISION 0x406c
+#define BRCM_PCIE_HW_REV_33 0x0303
+
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT 0x4070
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_MASK 0xfff00000
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_MASK 0xfff0
@@ -112,10 +116,14 @@
#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK 0x2
#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x08000000
-#define PCIE_MSI_INTR2_STATUS 0x4500
-#define PCIE_MSI_INTR2_CLR 0x4508
-#define PCIE_MSI_INTR2_MASK_SET 0x4510
-#define PCIE_MSI_INTR2_MASK_CLR 0x4514
+
+#define PCIE_INTR2_CPU_BASE 0x4300
+#define PCIE_MSI_INTR2_BASE 0x4500
+/* Offsets from PCIE_INTR2_CPU_BASE and PCIE_MSI_INTR2_BASE */
+#define MSI_INT_STATUS 0x0
+#define MSI_INT_CLR 0x8
+#define MSI_INT_MASK_SET 0x10
+#define MSI_INT_MASK_CLR 0x14
#define PCIE_EXT_CFG_DATA 0x8000
@@ -130,6 +138,8 @@
/* PCIe parameters */
#define BRCM_NUM_PCIE_OUT_WINS 0x4
#define BRCM_INT_PCI_MSI_NR 32
+#define BRCM_INT_PCI_MSI_LEGACY_NR 8
+#define BRCM_INT_PCI_MSI_SHIFT 0
/* MSI target adresses */
#define BRCM_MSI_TARGET_ADDR_LT_4GB 0x0fffffffcULL
@@ -247,6 +257,12 @@ struct brcm_msi {
int irq;
/* used indicates which MSI interrupts have been alloc'd */
unsigned long used;
+ bool legacy;
+ /* Some chips have MSIs in bits [31..24] of a shared register. */
+ int legacy_shift;
+ int nr; /* No. of MSI available, depends on chip */
+ /* This is the base pointer for interrupt status/set/clr regs */
+ void __iomem *intr_base;
};
/* Internal PCIe Host Controller Information.*/
@@ -266,6 +282,7 @@ struct brcm_pcie {
struct reset_control *rescal;
int num_memc;
u64 memc_size[PCIE_BRCM_MAX_MEMC];
+ u32 hw_rev;
};
/*
@@ -456,8 +473,10 @@ static void brcm_pcie_msi_isr(struct irq_desc *desc)
msi = irq_desc_get_handler_data(desc);
dev = msi->dev;
- status = readl(msi->base + PCIE_MSI_INTR2_STATUS);
- for_each_set_bit(bit, &status, BRCM_INT_PCI_MSI_NR) {
+ status = readl(msi->intr_base + MSI_INT_STATUS);
+ status >>= msi->legacy_shift;
+
+ for_each_set_bit(bit, &status, msi->nr) {
virq = irq_find_mapping(msi->inner_domain, bit);
if (virq)
generic_handle_irq(virq);
@@ -474,7 +493,7 @@ static void brcm_msi_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
msg->address_lo = lower_32_bits(msi->target_addr);
msg->address_hi = upper_32_bits(msi->target_addr);
- msg->data = (0xffff & PCIE_MISC_MSI_DATA_CONFIG_VAL) | data->hwirq;
+ msg->data = (0xffff & PCIE_MISC_MSI_DATA_CONFIG_VAL_32) | data->hwirq;
}
static int brcm_msi_set_affinity(struct irq_data *irq_data,
@@ -486,8 +505,9 @@ static int brcm_msi_set_affinity(struct irq_data *irq_data,
static void brcm_msi_ack_irq(struct irq_data *data)
{
struct brcm_msi *msi = irq_data_get_irq_chip_data(data);
+ const int shift_amt = data->hwirq + msi->legacy_shift;
- writel(1 << data->hwirq, msi->base + PCIE_MSI_INTR2_CLR);
+ writel(1 << shift_amt, msi->intr_base + MSI_INT_CLR);
}
@@ -503,7 +523,7 @@ static int brcm_msi_alloc(struct brcm_msi *msi)
int hwirq;
mutex_lock(&msi->lock);
- hwirq = bitmap_find_free_region(&msi->used, BRCM_INT_PCI_MSI_NR, 0);
+ hwirq = bitmap_find_free_region(&msi->used, msi->nr, 0);
mutex_unlock(&msi->lock);
return hwirq;
@@ -552,7 +572,7 @@ static int brcm_allocate_domains(struct brcm_msi *msi)
struct fwnode_handle *fwnode = of_node_to_fwnode(msi->np);
struct device *dev = msi->dev;
- msi->inner_domain = irq_domain_add_linear(NULL, BRCM_INT_PCI_MSI_NR,
+ msi->inner_domain = irq_domain_add_linear(NULL, msi->nr,
&msi_domain_ops, msi);
if (!msi->inner_domain) {
dev_err(dev, "failed to create IRQ domain\n");
@@ -590,7 +610,10 @@ static void brcm_msi_remove(struct brcm_pcie *pcie)
static void brcm_msi_set_regs(struct brcm_msi *msi)
{
- writel(0xffffffff, msi->base + PCIE_MSI_INTR2_MASK_CLR);
+ u32 val = __GENMASK(31, msi->legacy_shift);
+
+ writel(val, msi->intr_base + MSI_INT_MASK_CLR);
+ writel(val, msi->intr_base + MSI_INT_CLR);
/*
* The 0 bit of PCIE_MISC_MSI_BAR_CONFIG_LO is repurposed to MSI
@@ -601,8 +624,10 @@ static void brcm_msi_set_regs(struct brcm_msi *msi)
writel(upper_32_bits(msi->target_addr),
msi->base + PCIE_MISC_MSI_BAR_CONFIG_HI);
- writel(PCIE_MISC_MSI_DATA_CONFIG_VAL,
- msi->base + PCIE_MISC_MSI_DATA_CONFIG);
+ val = msi->legacy ? PCIE_MISC_MSI_DATA_CONFIG_VAL_8 :
+ PCIE_MISC_MSI_DATA_CONFIG_VAL_32;
+
+ writel(val, msi->base + PCIE_MISC_MSI_DATA_CONFIG);
}
static int brcm_pcie_enable_msi(struct brcm_pcie *pcie)
@@ -627,6 +652,17 @@ static int brcm_pcie_enable_msi(struct brcm_pcie *pcie)
msi->np = pcie->np;
msi->target_addr = pcie->msi_target_addr;
msi->irq = irq;
+ msi->legacy = pcie->hw_rev < BRCM_PCIE_HW_REV_33;
+
+ if (msi->legacy) {
+ msi->intr_base = msi->base + PCIE_INTR2_CPU_BASE;
+ msi->nr = BRCM_INT_PCI_MSI_LEGACY_NR;
+ msi->legacy_shift = 24;
+ } else {
+ msi->intr_base = msi->base + PCIE_MSI_INTR2_BASE;
+ msi->nr = BRCM_INT_PCI_MSI_NR;
+ msi->legacy_shift = 0;
+ }
ret = brcm_allocate_domains(msi);
if (ret)
@@ -885,12 +921,6 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
tmp &= ~PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_MASK;
writel(tmp, base + PCIE_MISC_RC_BAR3_CONFIG_LO);
- /* Mask all interrupts since we are not handling any yet */
- writel(0xffffffff, pcie->base + PCIE_MSI_INTR2_MASK_SET);
-
- /* clear any interrupts we find on boot */
- writel(0xffffffff, pcie->base + PCIE_MSI_INTR2_CLR);
-
if (pcie->gen)
brcm_pcie_set_gen(pcie, pcie->gen);
@@ -1220,6 +1250,8 @@ static int brcm_pcie_probe(struct platform_device *pdev)
if (ret)
goto fail;
+ pcie->hw_rev = readl(pcie->base + PCIE_MISC_REVISION);
+
msi_np = of_parse_phandle(pcie->np, "msi-parent", 0);
if (pci_msi_enabled() && msi_np == pcie->np) {
ret = brcm_pcie_enable_msi(pcie);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 13/13] PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match list
From: Jim Quinlan @ 2020-06-03 19:20 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Rob Herring, Lorenzo Pieralisi, open list, Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200603192058.35296-1-james.quinlan@broadcom.com>
Now that the support is in place with previous commits, we add several
chips that use the BrcmSTB driver.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 131cf0a51398..22dbecb5403c 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -1189,6 +1189,10 @@ static int brcm_pcie_remove(struct platform_device *pdev)
static const struct of_device_id brcm_pcie_match[] = {
{ .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
+ { .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
+ { .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
+ { .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
+ { .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
{},
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 12/13] PCI: brcmstb: Set bus max burst size by chip type
From: Jim Quinlan @ 2020-06-03 19:20 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Rob Herring, Lorenzo Pieralisi, open list, Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Jim Quinlan, Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200603192058.35296-1-james.quinlan@broadcom.com>
From: Jim Quinlan <jquinlan@broadcom.com>
The proper value of the parameter SCB_MAX_BURST_SIZE varies per chip. The
2711 family requires 128B whereas other devices can employ 512. The
assignment is complicated by the fact that the values for this two-bit
field have different meanings;
Value Type_Generic Type_7278
00 Reserved 128B
01 128B 256B
10 256B 512B
11 512B Reserved
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 9930419e3ac2..131cf0a51398 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -53,7 +53,7 @@
#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK 0x1000
#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK 0x2000
#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x300000
-#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_128 0x0
+
#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf8000000
#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK 0x07c00000
#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK 0x0000001f
@@ -848,7 +848,7 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
int num_out_wins = 0;
u16 nlw, cls, lnksta;
int i, ret, memc;
- u32 tmp, aspm_support;
+ u32 tmp, burst, aspm_support;
/* Reset the bridge */
brcm_pcie_bridge_sw_init_set(pcie, 1);
@@ -864,10 +864,22 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
/* Wait for SerDes to be stable */
usleep_range(100, 200);
+ /*
+ * SCB_MAX_BURST_SIZE is a two bit field. For GENERIC chips it
+ * is encoded as 0=128, 1=256, 2=512, 3=Rsvd, for BCM7278 it
+ * is encoded as 0=Rsvd, 1=128, 2=256, 3=512.
+ */
+ if (pcie->type == BCM2711)
+ burst = 0x0; /* 128B */
+ else if (pcie->type == BCM7278)
+ burst = 0x3; /* 512 bytes */
+ else
+ burst = 0x2; /* 512 bytes */
+
/* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
u32p_replace_bits(&tmp, 1, PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK);
u32p_replace_bits(&tmp, 1, PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK);
- u32p_replace_bits(&tmp, PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_128,
+ u32p_replace_bits(&tmp, burst,
PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK);
writel(tmp, base + PCIE_MISC_MISC_CTRL);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] dmaengine: stm32-dmamux: fix pm_runtime_get_sync fialure cases
From: Navid Emamdoost @ 2020-06-03 19:36 UTC (permalink / raw)
To: Vinod Koul, Dan Williams, Maxime Coquelin, Alexandre Torgue,
dmaengine, linux-stm32, linux-arm-kernel, linux-kernel
Cc: Navid Emamdoost, emamd001, kjlu, wu000273, smccaman
Calling pm_runtime_get_sync increments the counter even in case of
failure, causing incorrect ref count. Call pm_runtime_put_sync if
pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
---
drivers/dma/stm32-dmamux.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/stm32-dmamux.c b/drivers/dma/stm32-dmamux.c
index 12f7637e13a1..ab250d7eed29 100644
--- a/drivers/dma/stm32-dmamux.c
+++ b/drivers/dma/stm32-dmamux.c
@@ -140,6 +140,7 @@ static void *stm32_dmamux_route_allocate(struct of_phandle_args *dma_spec,
ret = pm_runtime_get_sync(&pdev->dev);
if (ret < 0) {
spin_unlock_irqrestore(&dmamux->lock, flags);
+ pm_runtime_put_sync(&pdev->dev);
goto error;
}
spin_unlock_irqrestore(&dmamux->lock, flags);
@@ -340,8 +341,10 @@ static int stm32_dmamux_suspend(struct device *dev)
int i, ret;
ret = pm_runtime_get_sync(dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_sync(dev);
return ret;
+ }
for (i = 0; i < stm32_dmamux->dma_requests; i++)
stm32_dmamux->ccr[i] = stm32_dmamux_read(stm32_dmamux->iomem,
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCHv2 0/7] Support inhibiting input devices
From: Hans de Goede @ 2020-06-03 19:37 UTC (permalink / raw)
To: Andrzej Pietrasiewicz, Dmitry Torokhov
Cc: Nick Dyer, linux-iio, Benjamin Tissoires, platform-driver-x86,
ibm-acpi-devel, Laxman Dewangan, Peter Meerwald-Stadler, kernel,
Fabio Estevam, linux-samsung-soc, Krzysztof Kozlowski,
Jonathan Hunter, linux-acpi, Kukjin Kim, NXP Linux Team,
linux-input, Len Brown, Peter Hutterer, Michael Hennerich,
Sascha Hauer, Sylvain Lemieux, Henrique de Moraes Holschuh,
Vladimir Zapolskiy, Lars-Peter Clausen, linux-tegra,
linux-arm-kernel, Barry Song, Ferruh Yigit, patches,
Rafael J . Wysocki, Thierry Reding, Sangwon Jee,
Pengutronix Kernel Team, Hartmut Knaack, Shawn Guo,
Jonathan Cameron
In-Reply-To: <025361f4-5b1b-6669-ffa0-a6e8ad43940c@collabora.com>
Hi,
On 6/3/20 7:54 PM, Andrzej Pietrasiewicz wrote:
> W dniu 03.06.2020 o 19:38, Hans de Goede pisze:
>> Hi,
>>
>> On 6/3/20 3:07 PM, Andrzej Pietrasiewicz wrote:
>>> Hi Hans, hi Dmitry,
>>
>> <snip>
>>
>>> I'm taking one step back and looking at the ->open() and ->close()
>>> driver callbacks. They are called from input_open_device() and
>>> input_close_device(), respectively:
>>>
>>> input_open_device():
>>> "This function should be called by input handlers when they
>>> want to start receive events from given input device."
>>>
>>> ->open() callback:
>>> "this method is called when the very first user calls
>>> input_open_device(). The driver must prepare the device to start
>>> generating events (start polling thread, request an IRQ, submit
>>> URB, etc.)"
>>>
>>> input_close_device():
>>> "This function should be called by input handlers when they
>>> want to stop receive events from given input device."
>>>
>>> ->close() callback:
>>> "this method is called when the very last user calls
>>> input_close_device()"
>>>
>>> It seems to me that the callback names do not reflect their
>>> purpose: their meaning is not to "open" or to "close" but to
>>> give drivers a chance to control when they start or stop
>>> providing events to the input core.
>>>
>>> What would you say about changing the callbacks' names?
>>> I'd envsion: ->provide_events() instead of ->open() and
>>> ->stop_events() instead of ->close(). Of course drivers can
>>> exploit the fact of knowing that nobody wants any events
>>> from them and do whatever they consider appropriate, for
>>> example go into a low power mode - but the latter is beyond
>>> the scope of the input subsystem and is driver-specific.
>>
>> I don't have much of an opinion on changing the names,
>> to me open/close have always means start/stop receiving
>> events. This follows the everything is a file philosophy,
>> e.g. you can also not really "open" a serial port,
>> yet opening /dev/ttyS0 will activate the receive IRQ
>> of the UART, etc. So maybe we just need to make the
>> docs clearer rather then do the rename? Doing the
>> rename is certainly going to cause a lot of churn.
>
> Right, I can see now that the suggestion to change names is
> too far fetched. (I feel that release() would be better
> than close(), though). But it exposes the message I wanted to
> pass.
>
>>
>> Anyways as said, I don't have much of an opinion,
>> so I'll leave commenting (more) on this to Dmitry.
>>
>>> With such a naming change in mind let's consider inhibiting.
>>> We want to be able to control when to disregard events from
>>> a given device. It makes sense to do it at device level, otherwise
>>> such an operation would have to be invoked in all associated
>>> handlers (those that have an open handle associating them with
>>> the device in question). But of course we can do better than
>>> merely ignoring the events received: we can tell the drivers
>>> that we don't want any events from them, and later, at uninhibit
>>> time, tell them to start providing the events again. Conceptually,
>>> the two operations (provide or don't provide envents) are exactly
>>> the same thing we want to be happening at input_open_device() and
>>> input_close_device() time. To me, changing the names of
>>> ->open() and ->close() exposes this fact very well.
>>>
>>> Consequently, ->inhibit() and ->uninhibit() won't be needed,
>>> and drivers which already implement ->provide_events() (formerly
>>> ->open()) and ->stop_events() (formerly ->close()) will receive
>>> full inhibit/uninhibit support for free (subject to how well they
>>> implement ->provide_events()/->stop_events()). Unless we can come
>>> up with what the drivers might be doing on top of ->stop_events()
>>> and ->provide_events() when inhibiting/uninhibiting, but it seems
>>> to me we can't. Can we?
>>
>> Right. I'm happy that you've come to see that both on open/close
>> and on inhibit/uninhibit we want to "start receiving events" and
>> "stop receiving events", so that we only need one set of callbacks.
>>
>
> Yeah, that's my conclusion - at least on a conceptual level.
>
> That said, what I can imagine is an existing driver (e.g. elan_i2c)
> which does not implement neither open() nor close(), but does have
> suspend() and resume(). Then it is maybe a bit easier to add inhibit()
> and uninhibit() /they would be similar to suspend and resume/ instead
> of open() and close(): If only open() and close() are possible, then
> the probe function needs to be extended to "close" the device before it
> gets registered, because from the moment it is registered it might be
> opened right away.
The probe only needs to "close" it if for some reason it
starts directly sending events in most cases the driver
must actively do something to get it to send events.
So in most cases this should be pretty straight forward,
as for having to do some init / power-on during probe
and then power-off at the end of the probe. Yes sometimes
something like that might be necessary.
Looking at your suggested elan_i2c changes I think they
look fine. I have the feeling that with some refactoring
they can be made a bit cleaner (I did not look a the
changes in too much detail) but overall I think they
look ok.
Note you may also want to look at using the runtime
suspend framework for this, doing a pm_runtime_get_sync()
in open() and then letting (runtime) suspend do the power
off if you set a reasonable timeout for autosuspend after
the last user is gone then that will also avoid an
unnecessary suspend / resume cycle between probe()
exiting and the first open() call and this avoids the
need to do a poweroff() at the end of probe(), the
runtime-pm framework will autosuspend the device after
the timeout expires.
Regards,
Hans
> And the device must be available earlier during the
> course of probe to query some parameters through i2c:
>
> +static int elan_reactivate(struct elan_tp_data *data)
> +{
> + struct device *dev = &data->client->dev;
> + int ret;
> +
> + ret = elan_enable_power(data);
> + if (ret)
> + dev_err(dev, "failed to restore power: %d\n", ret);
> +
> + ret = elan_initialize(data);
> + if (ret)
> + dev_err(dev, "failed to re-initialize touchpad: %d\n", ret);
> +
> + return ret;
> +}
> +
> +static int elan_open(struct input_dev *input)
> +{
> + struct elan_tp_data *data = input_get_drvdata(input);
> + struct i2c_client *client = data->client;
> + int ret;
> +
> + dev_dbg(&client->dev, "uninhibiting\n");
> +
> + ret = mutex_lock_interruptible(&data->sysfs_mutex);
> + if (ret)
> + return ret;
> +
> + ret = elan_reactivate(data);
> + if (ret == 0)
> + enable_irq(client->irq);
> +
> + mutex_unlock(&data->sysfs_mutex);
> +
> + return ret;
> +}
> +
> +static int elan_inhibit(struct input_dev *input)
> +{
> + struct elan_tp_data *data = input_get_drvdata(input);
> + struct i2c_client *client = data->client;
> + int ret;
> +
> + dev_dbg(&client->dev, "closing\n");
> +
> + /*
> + * We are taking the mutex to make sure sysfs operations are
> + * complete before we attempt to bring the device into low[er]
> + * power mode.
> + */
> + ret = mutex_lock_interruptible(&data->sysfs_mutex);
> + if (ret)
> + return ret;
> +
> + disable_irq(client->irq);
> +
> + ret = elan_disable_power(data);
> + if (ret)
> + enable_irq(client->irq);
> +
> + mutex_unlock(&data->sysfs_mutex);
> +
> + return ret;
> +}
> +
> +static void elan_close(struct input_dev *input)
> +{
> + elan_inhibit(input);
> +}
> +
> static int elan_query_device_info(struct elan_tp_data *data)
> {
> int error;
> u16 ic_type;
>
> error = data->ops->get_version(data->client, false, &data->fw_version);
> if (error)
> return error;
>
> error = data->ops->get_checksum(data->client, false,
> &data->fw_checksum);
> if (error)
> return error;
>
> error = data->ops->get_version(data->client, true, &data->iap_version);
> if (error)
> return error;
> @@ -1071,34 +1141,36 @@ static int elan_setup_trackpoint_input_device(struct elan_tp_data *data)
>
> static int elan_setup_input_device(struct elan_tp_data *data)
> {
> struct device *dev = &data->client->dev;
> struct input_dev *input;
> unsigned int max_width = max(data->width_x, data->width_y);
> unsigned int min_width = min(data->width_x, data->width_y);
> int error;
>
> input = devm_input_allocate_device(dev);
> if (!input)
> return -ENOMEM;
>
> input->name = "Elan Touchpad";
> input->id.bustype = BUS_I2C;
> input->id.vendor = ELAN_VENDOR_ID;
> input->id.product = data->product_id;
> + input->open = elan_open;
> + input->close = elan_close;
> input_set_drvdata(input, data);
>
> error = input_mt_init_slots(input, ETP_MAX_FINGERS,
> INPUT_MT_POINTER | INPUT_MT_DROP_UNUSED);
> if (error) {
> dev_err(dev, "failed to initialize MT slots: %d\n", error);
> return error;
> }
>
> __set_bit(EV_ABS, input->evbit);
> __set_bit(INPUT_PROP_POINTER, input->propbit);
> if (data->clickpad) {
> __set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
> } else {
> __set_bit(BTN_RIGHT, input->keybit);
> if (data->middle_button)
> __set_bit(BTN_MIDDLE, input->keybit);
> @@ -1253,34 +1325,40 @@ static int elan_probe(struct i2c_client *client,
> if (!irqflags)
> irqflags = IRQF_TRIGGER_FALLING;
>
> error = devm_request_threaded_irq(dev, client->irq, NULL, elan_isr,
> irqflags | IRQF_ONESHOT,
> client->name, data);
> if (error) {
> dev_err(dev, "cannot register irq=%d\n", client->irq);
> return error;
> }
>
> error = devm_device_add_groups(dev, elan_sysfs_groups);
> if (error) {
> dev_err(dev, "failed to create sysfs attributes: %d\n", error);
> return error;
> }
>
> + error = elan_inhibit(data->input);
> + if (error) {
> + dev_err(dev, "failed to inhibit input device before registering: %d\n", error);
> + return error;
> + }
> +
> error = input_register_device(data->input);
> if (error) {
> dev_err(dev, "failed to register input device: %d\n", error);
> return error;
> }
>
> if (data->tp_input) {
> error = input_register_device(data->tp_input);
> if (error) {
> dev_err(&client->dev,
> "failed to register TrackPoint input device: %d\n",
> error);
> return error;
> }
> }
>
> /*
> @@ -1294,72 +1372,71 @@ static int elan_probe(struct i2c_client *client,
> }
>
> static int __maybe_unused elan_suspend(struct device *dev)
> {
> struct i2c_client *client = to_i2c_client(dev);
> struct elan_tp_data *data = i2c_get_clientdata(client);
> int ret;
>
> /*
> * We are taking the mutex to make sure sysfs operations are
> * complete before we attempt to bring the device into low[er]
> * power mode.
> */
> ret = mutex_lock_interruptible(&data->sysfs_mutex);
> if (ret)
> return ret;
>
> - disable_irq(client->irq);
> + mutex_lock(&data->input->mutex);
> + if (input_device_enabled(data->input)) {
> + disable_irq(client->irq);
>
> - if (device_may_wakeup(dev)) {
> - ret = elan_sleep(data);
> - /* Enable wake from IRQ */
> - data->irq_wake = (enable_irq_wake(client->irq) == 0);
> - } else {
> - ret = elan_disable_power(data);
> + if (device_may_wakeup(dev)) {
> + ret = elan_sleep(data);
> + /* Enable wake from IRQ */
> + data->irq_wake = (enable_irq_wake(client->irq) == 0);
> + } else {
> + ret = elan_disable_power(data);
> + }
> }
> + mutex_unlock(&data->input->mutex);
>
> mutex_unlock(&data->sysfs_mutex);
> return ret;
> }
>
> static int __maybe_unused elan_resume(struct device *dev)
> {
> struct i2c_client *client = to_i2c_client(dev);
> struct elan_tp_data *data = i2c_get_clientdata(client);
> - int error;
> + int ret = 0;
>
> - if (device_may_wakeup(dev) && data->irq_wake) {
> - disable_irq_wake(client->irq);
> - data->irq_wake = false;
> - }
> + mutex_lock(&data->input->mutex);
> + if (input_device_enabled(data->input)) {
> + if (data->irq_wake) {
> + disable_irq_wake(client->irq);
> + data->irq_wake = false;
> + }
>
> - error = elan_enable_power(data);
> - if (error) {
> - dev_err(dev, "power up when resuming failed: %d\n", error);
> - goto err;
> + ret = elan_reactivate(data);
> + enable_irq(data->client->irq);
> }
> + mutex_unlock(&data->input->mutex);
>
> - error = elan_initialize(data);
> - if (error)
> - dev_err(dev, "initialize when resuming failed: %d\n", error);
> -
> -err:
> - enable_irq(data->client->irq);
> - return error;
> + return ret;
> }
>
> Regards,
>
> Andrzej
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] dmaengine: stm32-dma: call pm_runtime_put if pm_runtime_get_sync fails
From: Markus Elfring @ 2020-06-03 19:40 UTC (permalink / raw)
To: Navid Emamdoost, dmaengine, linux-arm-kernel, linux-stm32
Cc: Maxime Coquelin, Alexandre Torgue, kernel-janitors, Kangjie Lu,
LKML, Vinod Koul, Navid Emamdoost, Qiushi Wu, Stephen McCamant,
Dan Williams
In-Reply-To: <CAEkB2ET_gfNUAuoZHxiGWZX7d3CQaJYJJqS2Fspif5mFq4-xfA@mail.gmail.com>
>> How do you think about a wording variant like the following?
> Please stop proposing rewording on my patches!
I am trying to remind you on open issues according to patch review concerns.
> I will consider updating my patches only if a maintainer asks for it.
* I hope that more contributors would like to improve the software quality
also for commit messages.
* Would the adjusted patch prefix need a different version indication?
Regards,
Markus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: Bhupesh Sharma @ 2020-06-03 19:47 UTC (permalink / raw)
To: John Donnelly
Cc: Devicetree List, Arnd Bergmann, Baoquan He,
Linux Doc Mailing List, chenzhou, Catalin Marinas, RuiRui Yang,
Prabhakar Kushwaha, kexec mailing list, Linux Kernel Mailing List,
Rob Herring, Simon Horman, James Morse, linux-arm-kernel,
guohanjun, Thomas Gleixner, Prabhakar Kushwaha, Will Deacon,
Ingo Molnar, nsaenzjulienne
In-Reply-To: <8E0D45DC-12BF-437D-A342-03E974D9C6D4@oracle.com>
Hi All,
On Wed, Jun 3, 2020 at 9:03 PM John Donnelly <john.p.donnelly@oracle.com> wrote:
>
>
>
> > On Jun 3, 2020, at 8:20 AM, chenzhou <chenzhou10@huawei.com> wrote:
> >
> > Hi,
> >
> >
> > On 2020/6/3 19:47, Prabhakar Kushwaha wrote:
> >> Hi Chen,
> >>
> >> On Tue, Jun 2, 2020 at 8:12 PM John Donnelly <john.p.donnelly@oracle.com> wrote:
> >>>
> >>>
> >>>> On Jun 2, 2020, at 12:38 AM, Prabhakar Kushwaha <prabhakar.pkin@gmail.com> wrote:
> >>>>
> >>>> On Tue, Jun 2, 2020 at 3:29 AM John Donnelly <john.p.donnelly@oracle.com> wrote:
> >>>>> Hi . See below !
> >>>>>
> >>>>>> On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
> >>>>>>
> >>>>>> Hi John,
> >>>>>>
> >>>>>> On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <John.P.donnelly@oracle.com> wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>>
> >>>>>>> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
> >>>>>>>> Hi Chen,
> >>>>>>>>
> >>>>>>>> On Thu, May 21, 2020 at 3:05 PM Chen Zhou <chenzhou10@huawei.com> wrote:
> >>>>>>>>> This patch series enable reserving crashkernel above 4G in arm64.
> >>>>>>>>>
> >>>>>>>>> There are following issues in arm64 kdump:
> >>>>>>>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
> >>>>>>>>> when there is no enough low memory.
> >>>>>>>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
> >>>>>>>>> in this case, if swiotlb or DMA buffers are required, crash dump kernel
> >>>>>>>>> will boot failure because there is no low memory available for allocation.
> >>>>>>>>>
> >>>>>>>> We are getting "warn_alloc" [1] warning during boot of kdump kernel
> >>>>>>>> with bootargs as [2] of primary kernel.
> >>>>>>>> This error observed on ThunderX2 ARM64 platform.
> >>>>>>>>
> >>>>>>>> It is observed with latest upstream tag (v5.7-rc3) with this patch set
> >>>>>>>> and https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
> >>>>>>>> Also **without** this patch-set
> >>>>>>>> "https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$"
> >>>>>>>>
> >>>>>>>> This issue comes whenever crashkernel memory is reserved after 0xc000_0000.
> >>>>>>>> More details discussed earlier in
> >>>>>>>> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$ without any
> >>>>>>>> solution
> >>>>>>>>
> >>>>>>>> This patch-set is expected to solve similar kind of issue.
> >>>>>>>> i.e. low memory is only targeted for DMA, swiotlb; So above mentioned
> >>>>>>>> observation should be considered/fixed. .
> >>>>>>>>
> >>>>>>>> --pk
> >>>>>>>>
> >>>>>>>> [1]
> >>>>>>>> [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
> >>>>>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> >>>>>>>> [ 30.367696] NET: Registered protocol family 16
> >>>>>>>> [ 30.369973] swapper/0: page allocation failure: order:6,
> >>>>>>>> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
> >>>>>>>> [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc3+ #121
> >>>>>>>> [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
> >>>>>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> >>>>>>>> [ 30.369984] Call trace:
> >>>>>>>> [ 30.369989] dump_backtrace+0x0/0x1f8
> >>>>>>>> [ 30.369991] show_stack+0x20/0x30
> >>>>>>>> [ 30.369997] dump_stack+0xc0/0x10c
> >>>>>>>> [ 30.370001] warn_alloc+0x10c/0x178
> >>>>>>>> [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0xb50
> >>>>>>>> [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
> >>>>>>>> [ 30.370008] alloc_page_interleave+0x24/0x98
> >>>>>>>> [ 30.370011] alloc_pages_current+0xe4/0x108
> >>>>>>>> [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
> >>>>>>>> [ 30.370020] do_one_initcall+0x54/0x228
> >>>>>>>> [ 30.370027] kernel_init_freeable+0x228/0x2cc
> >>>>>>>> [ 30.370031] kernel_init+0x1c/0x110
> >>>>>>>> [ 30.370034] ret_from_fork+0x10/0x18
> >>>>>>>> [ 30.370036] Mem-Info:
> >>>>>>>> [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
> >>>>>>>> [ 30.370064] active_file:0 inactive_file:0 isolated_file:0
> >>>>>>>> [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
> >>>>>>>> [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
> >>>>>>>> [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
> >>>>>>>> [ 30.370064] free:1537719 free_pcp:219 free_cma:0
> >>>>>>>> [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
> >>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> >>>>>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> >>>>>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> >>>>>>>> unstable:0kB all_unreclaimable? no
> >>>>>>>> [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
> >>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> >>>>>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> >>>>>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> >>>>>>>> unstable:0kB all_unreclaimable? no
> >>>>>>>> [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
> >>>>>>>> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> >>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> >>>>>>>> present:128kB managed:0kB mlocked:0kB kernel_stack:0kB pagetables:0kB
> >>>>>>>> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> >>>>>>>> [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
> >>>>>>>> [ 30.370090] Node 0 DMA32 free:256000kB min:408kB low:664kB
> >>>>>>>> high:920kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> >>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> >>>>>>>> present:269700kB managed:256000kB mlocked:0kB kernel_stack:0kB
> >>>>>>>> pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> >>>>>>>> [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
> >>>>>>>> [ 30.370100] Node 0 Normal free:5894876kB min:9552kB low:15504kB
> >>>>>>>> high:21456kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> >>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> >>>>>>>> present:8388608kB managed:5953112kB mlocked:0kB kernel_stack:21672kB
> >>>>>>>> pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB free_cma:0kB
> >>>>>>>> [ 30.370104] lowmem_reserve[]: 0 0 0 0
> >>>>>>>> [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> >>>>>>>> 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> >>>>>>>> [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> >>>>>>>> 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) = 256000kB
> >>>>>>>> [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB (UE) 3*32kB
> >>>>>>>> (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME) 3*1024kB (ME)
> >>>>>>>> 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
> >>>>>>>> [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
> >>>>>>>> hugepages_surp=0 hugepages_size=1048576kB
> >>>>>>>> [ 30.370130] 0 total pagecache pages
> >>>>>>>> [ 30.370132] 0 pages in swap cache
> >>>>>>>> [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
> >>>>>>>> [ 30.370135] Free swap = 0kB
> >>>>>>>> [ 30.370136] Total swap = 0kB
> >>>>>>>> [ 30.370137] 2164609 pages RAM
> >>>>>>>> [ 30.370139] 0 pages HighMem/MovableOnly
> >>>>>>>> [ 30.370140] 612331 pages reserved
> >>>>>>>> [ 30.370141] 0 pages hwpoisoned
> >>>>>>>> [ 30.370143] DMA: failed to allocate 256 KiB pool for atomic
> >>>>>>>> coherent allocation
> >>>>>>>
> >>>>>>> During my testing I saw the same error and Chen's solution corrected it .
> >>>>>> Which combination you are using on your side? I am using Prabhakar's
> >>>>>> suggested environment and can reproduce the issue
> >>>>>> with or without Chen's crashkernel support above 4G patchset.
> >>>>>>
> >>>>>> I am also using a ThunderX2 platform with latest makedumpfile code and
> >>>>>> kexec-tools (with the suggested patch
> >>>>>> <https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!J6lUig58-Gw6TKZnEEYzEeSU36T-1SqlB1kImU00xtX_lss5Tx-JbUmLE9TJC3foXBLg$ >).
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Bhupesh
> >>>>>
> >>>>> I did this activity 5 months ago and I have moved on to other activities. My DMA failures were related to PCI devices that could not be enumerated because low-DMA space was not available when crashkernel was moved above 4G; I don’t recall the exact platform.
> >>>>>
> >>>>>
> >>>>>
> >>>>> For this failure ,
> >>>>>
> >>>>>>>> DMA: failed to allocate 256 KiB pool for atomic
> >>>>>>>> coherent allocation
> >>>>>
> >>>>> Is due to :
> >>>>>
> >>>>>
> >>>>> 3618082c
> >>>>> ("arm64 use both ZONE_DMA and ZONE_DMA32")
> >>>>>
> >>>>> With the introduction of ZONE_DMA to support the Raspberry DMA
> >>>>> region below 1G, the crashkernel is placed in the upper 4G
> >>>>> ZONE_DMA_32 region. Since the crashkernel does not have access
> >>>>> to the ZONE_DMA region, it prints out call trace during bootup.
> >>>>>
> >>>>> It is due to having this CONFIG item ON :
> >>>>>
> >>>>>
> >>>>> CONFIG_ZONE_DMA=y
> >>>>>
> >>>>> Turning off ZONE_DMA fixes a issue and Raspberry PI 4 will
> >>>>> use the device tree to specify memory below 1G.
> >>>>>
> >>>>>
> >>>> Disabling ZONE_DMA is temporary solution. We may need proper solution
> >>>
> >>> Perhaps the Raspberry platform configuration dependencies need separated from “server class” Arm equipment ? Or auto-configured on boot ? Consult an expert ;-)
> >>>
> >>>
> >>>
> >>>>> I would like to see Chen’s feature added , perhaps as EXPERIMENTAL, so we can get some configuration testing done on it. It corrects having a DMA zone in low memory while crash-kernel is above 4GB. This has been going on for a year now.
> >>>> I will also like this patch to be added in Linux as early as possible.
> >>>>
> >>>> Issue mentioned by me happens with or without this patch.
> >>>>
> >>>> This patch-set can consider fixing because it uses low memory for DMA
> >>>> & swiotlb only.
> >>>> We can consider restricting crashkernel within the required range like below
> >>>>
> >>>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> >>>> index 7f9e5a6dc48c..bd67b90d35bd 100644
> >>>> --- a/kernel/crash_core.c
> >>>> +++ b/kernel/crash_core.c
> >>>> @@ -354,7 +354,7 @@ int __init reserve_crashkernel_low(void)
> >>>> return 0;
> >>>> }
> >>>>
> >>>> - low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
> >>>> + low_base = memblock_find_in_range(0,0xc0000000, low_size, CRASH_ALIGN);
> >>>> if (!low_base) {
> >>>> pr_err("Cannot reserve %ldMB crashkernel low memory,
> >>>> please try smaller size.\n",
> >>>> (unsigned long)(low_size >> 20));
> >>>>
> >>>>
> >>> I suspect 0xc0000000 would need to be a CONFIG item and not hard-coded.
> >>>
> >> if you consider this as valid change, can you please incorporate as
> >> part of your patch-set.
> >
> > After commit 1a8e1cef7 ("arm64: use both ZONE_DMA and ZONE_DMA32")，the 0-4G memory is splited
> > to DMA [mem 0x0000000000000000-0x000000003fffffff] and DMA32 [mem 0x0000000040000000-0x00000000ffffffff] on arm64.
> >
> > From the above discussion, on your platform, the low crashkernel fall in DMA32 region, but your environment needs to access DMA
> > region, so there is the call trace.
> >
> > I have a question, why do you choose 0xc0000000 here?
> >
> > Besides, this is common code, we also need to consider about x86.
> >
>
> + nsaenzjulienne@suse.de
>
> Exactly . This is why it needs to be a CONFIG option for Raspberry .., or device tree option.
>
>
> We could revert 1a8e1cef7 since it broke Arm kdump too.
Well, unfortunately the patch for commit 1a8e1cef7603 ("arm64: use
both ZONE_DMA and ZONE_DMA32") was not Cc'ed to the kexec mailing
list, thus we couldn't get many eyes on it for a thorough review from
kexec/kdump p-o-v.
Also we historically never had distinction in common arch code on the
basis of the intended end use-case: embedded, server or automotive, so
I am not sure introducing a Raspberry specific CONFIG option would be
a good idea.
So, rather than reverting the patch, we can look at addressing the
same properly this time - especially from a kdump p-o-v.
This issue has been reported by some Red Hat arm64 partners with
upstream kernel also and as we have noticed in the past as well,
hardcoding the placement of the crashkernel base address (unless the
base address is specified by a crashkernel=X@Y like bootargs) is also
not a portable suggestion.
I am working on a possible fix and will have more updates on the same
in a day-or-two.
Thanks,
Bhupesh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 13/13] PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match list
From: Florian Fainelli @ 2020-06-03 20:02 UTC (permalink / raw)
To: Jim Quinlan, linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list
Cc: Rob Herring, Lorenzo Pieralisi, open list,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200603192058.35296-14-james.quinlan@broadcom.com>
On 6/3/2020 12:20 PM, Jim Quinlan wrote:
> Now that the support is in place with previous commits, we add several
> chips that use the BrcmSTB driver.
>
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 12/13] PCI: brcmstb: Set bus max burst size by chip type
From: Florian Fainelli @ 2020-06-03 20:06 UTC (permalink / raw)
To: Jim Quinlan, linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list
Cc: Rob Herring, Lorenzo Pieralisi, open list, Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200603192058.35296-13-james.quinlan@broadcom.com>
On 6/3/2020 12:20 PM, Jim Quinlan wrote:
> From: Jim Quinlan <jquinlan@broadcom.com>
>
> The proper value of the parameter SCB_MAX_BURST_SIZE varies per chip. The
> 2711 family requires 128B whereas other devices can employ 512. The
> assignment is complicated by the fact that the values for this two-bit
> field have different meanings;
>
> Value Type_Generic Type_7278
It looks like Type_Generic and Type_7278 should be swapped in this
description. Other than that:
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>
> 00 Reserved 128B
> 01 128B 256B
> 10 256B 512B
> 11 512B Reserved
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 105/105] ARM: dts: bcm2711: Enable the display pipeline
From: Stefan Wahren @ 2020-06-03 20:11 UTC (permalink / raw)
To: Maxime Ripard, Nicolas Saenz Julienne, Eric Anholt
Cc: Tim Gover, Dave Stevenson, linux-kernel, dri-devel,
bcm-kernel-feedback-list, linux-rpi-kernel, Phil Elwell,
linux-arm-kernel
In-Reply-To: <587d6e4a529a8d807a5c0bae583dd432d77064d6.1590594512.git-series.maxime@cerno.tech>
Hi Maxime,
Am 27.05.20 um 17:49 schrieb Maxime Ripard:
> Now that all the drivers have been adjusted for it, let's bring in the
> necessary device tree changes.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 46 +++++++++++-
> arch/arm/boot/dts/bcm2711.dtsi | 115 ++++++++++++++++++++++++++-
> 2 files changed, 160 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> index 222d7825e1ab..c4a650ea4e21 100644
> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> @@ -231,3 +231,49 @@
> &vchiq {
> interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
> };
> +
> +&vc4 {
> + status = "okay";
> +};
> +
> +&pixelvalve0 {
> + status = "okay";
> +};
> +
> +&pixelvalve1 {
> + status = "okay";
> +};
> +
> +&pixelvalve2 {
> + status = "okay";
> +};
> +
> +&pixelvalve4 {
> + status = "okay";
> +};
> +
> +&vec {
> + status = "disabled";
> +};
> +
> +&hdmi0 {
> + clocks = <&firmware_clocks 13>, <&dvp 0>;
> + status = "okay";
> +};
> +
> +&ddc0 {
> + status = "okay";
> +};
> +
> +&hdmi1 {
> + clocks = <&firmware_clocks 13>, <&dvp 1>;
> + status = "okay";
> +};
> +
> +&ddc1 {
> + status = "okay";
> +};
> +
> +&hvs {
> + clocks = <&firmware_clocks 4>;
> +};
it would be nice to have these references in alphabetical order.
Regards
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 05/13] PCI: brcmstb: Add suspend and resume pm_ops
From: Bjorn Helgaas @ 2020-06-03 20:24 UTC (permalink / raw)
To: Jim Quinlan
Cc: moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Rob Herring, Lorenzo Pieralisi, linux-pci, open list,
Florian Fainelli, bcm-kernel-feedback-list,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Bjorn Helgaas, Christoph Hellwig, Nicolas Saenz Julienne
In-Reply-To: <20200603192058.35296-6-james.quinlan@broadcom.com>
On Wed, Jun 03, 2020 at 03:20:37PM -0400, Jim Quinlan wrote:
> From: Jim Quinlan <jquinlan@broadcom.com>
>
> Broadcom Set-top (BrcmSTB) boards typically support S2, S3, and S5 suspend
> and resume. Now the PCIe driver may do so as well.
>
> Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> ---
> drivers/pci/controller/pcie-brcmstb.c | 49 +++++++++++++++++++++++++++
> 1 file changed, 49 insertions(+)
>
> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> index 7c707e483181..f444751e247c 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -979,6 +979,49 @@ static void brcm_pcie_turn_off(struct brcm_pcie *pcie)
> brcm_pcie_bridge_sw_init_set(pcie, 1);
> }
>
> +static int brcm_pcie_suspend(struct device *dev)
> +{
> + struct brcm_pcie *pcie = dev_get_drvdata(dev);
> + int ret = 0;
> +
> + brcm_pcie_turn_off(pcie);
> + clk_disable_unprepare(pcie->clk);
> +
> + return ret;
No need for "ret".
> +}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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