* Re: [PATCH v4 2/9] dt-bindings: i2c: add bindings for i2c analog and digital filter
From: Alexandre Belloni @ 2019-09-02 14:22 UTC (permalink / raw)
To: Eugen.Hristev
Cc: mark.rutland, devicetree, wsa, linux-kernel, pierre-yves.mordret,
Ludovic.Desroches, robh+dt, linux-i2c, peda, linux-arm-kernel
In-Reply-To: <b6528812-65d3-6561-38e7-c0545af900d8@microchip.com>
Eugen,
On 02/09/2019 14:15:14+0000, Eugen.Hristev@microchip.com wrote:
> On 02.09.2019 13:49, Peter Rosin wrote:
>
> > On 2019-09-02 12:12, Eugen.Hristev@microchip.com wrote:
> >> From: Eugen Hristev <eugen.hristev@microchip.com>
> >>
> >> Some i2c controllers have a built-in digital or analog filter.
> >> This is specifically required depending on the hardware PCB/board.
> >> Some controllers also allow specifying the maximum width of the
> >> spikes that can be filtered. The width length can be specified in nanoseconds.
> >>
> >> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> >> ---
> >> Documentation/devicetree/bindings/i2c/i2c.txt | 11 +++++++++++
> >> 1 file changed, 11 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
> >> index 44efafd..8dbff67 100644
> >> --- a/Documentation/devicetree/bindings/i2c/i2c.txt
> >> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt
> >> @@ -55,6 +55,17 @@ wants to support one of the below features, it should adapt the bindings below.
> >> Number of nanoseconds the SDA signal takes to fall; t(f) in the I2C
> >> specification.
> >>
> >> +- i2c-analog-filter
> >> + Enable analog filter for i2c lines.
> >> +
> >> +- i2c-digital-filter
> >> + Enable digital filter for i2c lines.
> >> +
> >> +- i2c-filter-width-ns
> >> + Width of spikes which can be filtered by either digital or analog
> >> + filters (i2c-analog-filtr or i2c-digital-filtr). This width is specified
> >
> > filtr -> filter (two instances)
> >
> > What if you want/need to have different bandwidth for the digital and analog
> > filters? After all, this is a generic binding...
>
> For our needs, this is enough: the purpose of the filters is to avoid
> noise on the lines, the noise is as big as it is for the digital and for
> the analog filters, since we use an absolute measurement for them. So I
> do not know how useful it would be to make a difference.
>
You are adding generic properties so they have to be generic and not
tied to your particular use case.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
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 v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Rob Herring @ 2019-09-02 14:20 UTC (permalink / raw)
To: Peng Fan
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com,
jassisinghbrar@gmail.com, linux-kernel@vger.kernel.org,
dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <5d6d1b86.1c69fb81.f86b5.3988@mx.google.com>
On Mon, Sep 2, 2019 at 2:39 PM Rob Herring <robh@kernel.org> wrote:
>
> On Wed, Aug 28, 2019 at 03:02:58AM +0000, Peng Fan wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
> > actions in software layers running in the EL2 or EL3 exception levels.
> > The term "ARM" here relates to the SMC instruction as part of the ARM
> > instruction set, not as a standard endorsed by ARM Ltd.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > .../devicetree/bindings/mailbox/arm-smc.yaml | 125 +++++++++++++++++++++
> > 1 file changed, 125 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > new file mode 100644
> > index 000000000000..f8eb28d5e307
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > @@ -0,0 +1,125 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: ARM SMC Mailbox Interface
> > +
> > +maintainers:
> > + - Peng Fan <peng.fan@nxp.com>
> > +
> > +description: |
> > + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
> > + call) instruction to trigger a mailbox-connected activity in firmware,
> > + executing on the very same core as the caller. By nature this operation
> > + is synchronous and this mailbox provides no way for asynchronous messages
> > + to be delivered the other way round, from firmware to the OS, but
> > + asynchronous notification could also be supported. However the value of
> > + r0/w0/x0 the firmware returns after the smc call is delivered as a received
> > + message to the mailbox framework, so a synchronous communication can be
> > + established, for a asynchronous notification, no value will be returned.
> > + The exact meaning of both the action the mailbox triggers as well as the
> > + return value is defined by their users and is not subject to this binding.
> > +
> > + One use case of this mailbox is the SCMI interface, which uses shared memory
> > + to transfer commands and parameters, and a mailbox to trigger a function
> > + call. This allows SoCs without a separate management processor (or when
> > + such a processor is not available or used) to use this standardized
> > + interface anyway.
> > +
> > + This binding describes no hardware, but establishes a firmware interface.
> > + Upon receiving an SMC using one of the described SMC function identifiers,
> > + the firmware is expected to trigger some mailbox connected functionality.
> > + The communication follows the ARM SMC calling convention.
> > + Firmware expects an SMC function identifier in r0 or w0. The supported
> > + identifiers are passed from consumers, or listed in the the arm,func-ids
> > + properties as described below. The firmware can return one value in
> > + the first SMC result register, it is expected to be an error value,
> > + which shall be propagated to the mailbox client.
> > +
> > + Any core which supports the SMC or HVC instruction can be used, as long as
> > + a firmware component running in EL3 or EL2 is handling these calls.
> > +
> > +properties:
> > + compatible:
> > + const: arm,smc-mbox
> > +
> > + "#mbox-cells":
> > + const: 1
> > +
> > + arm,num-chans:
> > + description: The number of channels supported.
> > + items:
> > + minimum: 1
> > + maximum: 4096 # Should be enough?
> > +
> > + method:
> > + - enum:
>
> Did you build this with 'make dt_binding_check' as this should be a
> warning. This should not be a list entry (i.e. drop the '-').
>
> > + - smc
> > + - hvc
> > +
> > + transports:
>
> arm,transports
>
> > + - enum:
> > + - mem
> > + - reg
> > +
> > + arm,func-ids:
> > + description: |
> > + An array of 32-bit values specifying the function IDs used by each
> > + mailbox channel. Those function IDs follow the ARM SMC calling
> > + convention standard [1].
> > +
> > + There is one identifier per channel and the number of supported
> > + channels is determined by the length of this array.
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
Also, this doesn't work. You need:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
> > + minItems: 0
> > + maxItems: 4096 # Should be enough?
_______________________________________________
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 03/26] m68k, microblaze: remove ioremap_fullcache
From: Michal Simek @ 2019-09-02 14:16 UTC (permalink / raw)
To: Christoph Hellwig, Arnd Bergmann, Guo Ren, Greentime Hu,
Vincent Chen, Guan Xuetao, x86
Cc: linux-arch, linux-s390, linux-ia64, linux-parisc, linux-sh,
linux-hexagon, linux-xtensa, linux-mips, linux-kernel, linux-m68k,
openrisc, linux-mtd, linux-alpha, sparclinux, nios2-dev,
linux-riscv, linux-snps-arc, linux-arm-kernel
In-Reply-To: <20190817073253.27819-4-hch@lst.de>
[-- Attachment #1.1.1: Type: text/plain, Size: 1977 bytes --]
On 17. 08. 19 9:32, Christoph Hellwig wrote:
> No callers of this function.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/m68k/include/asm/kmap.h | 7 -------
> arch/microblaze/include/asm/io.h | 1 -
> 2 files changed, 8 deletions(-)
>
> diff --git a/arch/m68k/include/asm/kmap.h b/arch/m68k/include/asm/kmap.h
> index aac7f045f7f0..03d904fe6087 100644
> --- a/arch/m68k/include/asm/kmap.h
> +++ b/arch/m68k/include/asm/kmap.h
> @@ -43,13 +43,6 @@ static inline void __iomem *ioremap_wt(unsigned long physaddr,
> return __ioremap(physaddr, size, IOMAP_WRITETHROUGH);
> }
>
> -#define ioremap_fullcache ioremap_fullcache
> -static inline void __iomem *ioremap_fullcache(unsigned long physaddr,
> - unsigned long size)
> -{
> - return __ioremap(physaddr, size, IOMAP_FULL_CACHING);
> -}
> -
> #define memset_io memset_io
> static inline void memset_io(volatile void __iomem *addr, unsigned char val,
> int count)
> diff --git a/arch/microblaze/include/asm/io.h b/arch/microblaze/include/asm/io.h
> index c7968139486f..86c95b2a1ce1 100644
> --- a/arch/microblaze/include/asm/io.h
> +++ b/arch/microblaze/include/asm/io.h
> @@ -40,7 +40,6 @@ extern void iounmap(volatile void __iomem *addr);
>
> extern void __iomem *ioremap(phys_addr_t address, unsigned long size);
> #define ioremap_nocache(addr, size) ioremap((addr), (size))
> -#define ioremap_fullcache(addr, size) ioremap((addr), (size))
> #define ioremap_wc(addr, size) ioremap((addr), (size))
> #define ioremap_wt(addr, size) ioremap((addr), (size))
>
>
Acked-by: Michal Simek <monstr@monstr.eu> (for Microblaze)
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 v5] perf machine: arm/arm64: Improve completeness for kernel address space
From: Leo Yan @ 2019-09-02 14:15 UTC (permalink / raw)
To: Adrian Hunter
Cc: Song Liu, Mathieu Poirier, Daniel Borkmann, Suzuki Poulouse,
Alexander Shishkin, netdev, coresight, Alexei Starovoitov,
Arnaldo Carvalho de Melo, linux-kernel, clang-built-linux,
Peter Zijlstra, Yonghong Song, Namhyung Kim, bpf, Jiri Olsa,
Martin KaFai Lau, linux-arm-kernel
In-Reply-To: <20190826125105.GA3288@leoy-ThinkPad-X240s>
Hi Adrian,
On Mon, Aug 26, 2019 at 08:51:05PM +0800, Leo Yan wrote:
> Hi Adrian,
>
> On Fri, Aug 16, 2019 at 04:00:02PM +0300, Adrian Hunter wrote:
> > On 16/08/19 4:45 AM, Leo Yan wrote:
> > > Hi Adrian,
> > >
> > > On Thu, Aug 15, 2019 at 02:45:57PM +0300, Adrian Hunter wrote:
> > >
> > > [...]
> > >
> > >>>> How come you cannot use kallsyms to get the information?
> > >>>
> > >>> Thanks for pointing out this. Sorry I skipped your comment "I don't
> > >>> know how you intend to calculate ARM_PRE_START_SIZE" when you reviewed
> > >>> the patch v3, I should use that chance to elaborate the detailed idea
> > >>> and so can get more feedback/guidance before procceed.
> > >>>
> > >>> Actually, I have considered to use kallsyms when worked on the previous
> > >>> patch set.
> > >>>
> > >>> As mentioned in patch set v4's cover letter, I tried to implement
> > >>> machine__create_extra_kernel_maps() for arm/arm64, the purpose is to
> > >>> parse kallsyms so can find more kernel maps and thus also can fixup
> > >>> the kernel start address. But I found the 'perf script' tool directly
> > >>> calls machine__get_kernel_start() instead of running into the flow for
> > >>> machine__create_extra_kernel_maps();
> > >>
> > >> Doesn't it just need to loop through each kernel map to find the lowest
> > >> start address?
> > >
> > > Based on your suggestion, I worked out below change and verified it
> > > can work well on arm64 for fixing up start address; please let me know
> > > if the change works for you?
> >
> > How does that work if take a perf.data file to a machine with a different
> > architecture?
>
> Sorry I delayed so long to respond to your question; I didn't have
> confidence to give out very reasonale answer and this is the main reason
> for delaying.
Could you take chance to review my below replying? I'd like to get
your confirmation before I send out offical patch.
Thanks,
Leo Yan
>
> For your question for taking a perf.data file to a machine with a
> different architecture, we can firstly use command 'perf buildid-list'
> to print out the buildid for kallsyms, based on the dumped buildid we
> can find out the location for the saved kallsyms file; then we can use
> option '--kallsyms' to specify the offline kallsyms file and use the
> offline kallsyms to fixup kernel start address. The detailed commands
> are listed as below:
>
> root@debian:~# perf buildid-list
> 7b36dfca8317ef74974ebd7ee5ec0a8b35c97640 [kernel.kallsyms]
> 56b84aa88a1bcfe222a97a53698b92723a3977ca /usr/lib/systemd/systemd
> 0956b952e9cd673d48ff2cfeb1a9dbd0c853e686 /usr/lib/aarch64-linux-gnu/libm-2.28.so
> [...]
>
> root@debian:~# perf script --kallsyms ~/.debug/\[kernel.kallsyms\]/7b36dfca8317ef74974ebd7ee5ec0a8b35c97640/kallsyms
>
> The amended patch is as below, please review and always welcome
> any suggestions or comments!
>
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index 5734460fc89e..593f05cc453f 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -2672,9 +2672,26 @@ int machine__nr_cpus_avail(struct machine *machine)
> return machine ? perf_env__nr_cpus_avail(machine->env) : 0;
> }
>
> +static int machine__fixup_kernel_start(void *arg,
> + const char *name __maybe_unused,
> + char type,
> + u64 start)
> +{
> + struct machine *machine = arg;
> +
> + type = toupper(type);
> +
> + /* Fixup for text, weak, data and bss sections. */
> + if (type == 'T' || type == 'W' || type == 'D' || type == 'B')
> + machine->kernel_start = min(machine->kernel_start, start);
> +
> + return 0;
> +}
> +
> int machine__get_kernel_start(struct machine *machine)
> {
> struct map *map = machine__kernel_map(machine);
> + char filename[PATH_MAX];
> int err = 0;
>
> /*
> @@ -2696,6 +2713,22 @@ int machine__get_kernel_start(struct machine *machine)
> if (!err && !machine__is(machine, "x86_64"))
> machine->kernel_start = map->start;
> }
> +
> + if (symbol_conf.kallsyms_name != NULL) {
> + strncpy(filename, symbol_conf.kallsyms_name, PATH_MAX);
> + } else {
> + machine__get_kallsyms_filename(machine, filename, PATH_MAX);
> +
> + if (symbol__restricted_filename(filename, "/proc/kallsyms"))
> + goto out;
> + }
> +
> + if (kallsyms__parse(filename, machine, machine__fixup_kernel_start))
> + pr_warning("Fail to fixup kernel start address. skipping...\n");
> +
> +out:
> return err;
> }
>
>
> Thanks,
> Leo Yan
_______________________________________________
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 2/9] dt-bindings: i2c: add bindings for i2c analog and digital filter
From: Eugen.Hristev @ 2019-09-02 14:15 UTC (permalink / raw)
To: peda, wsa, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, pierre-yves.mordret,
alexandre.belloni, robh+dt
In-Reply-To: <9a9c209c-2fb8-0a4c-4e0a-b04fefda3360@axentia.se>
On 02.09.2019 13:49, Peter Rosin wrote:
> On 2019-09-02 12:12, Eugen.Hristev@microchip.com wrote:
>> From: Eugen Hristev <eugen.hristev@microchip.com>
>>
>> Some i2c controllers have a built-in digital or analog filter.
>> This is specifically required depending on the hardware PCB/board.
>> Some controllers also allow specifying the maximum width of the
>> spikes that can be filtered. The width length can be specified in nanoseconds.
>>
>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
>> ---
>> Documentation/devicetree/bindings/i2c/i2c.txt | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
>> index 44efafd..8dbff67 100644
>> --- a/Documentation/devicetree/bindings/i2c/i2c.txt
>> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt
>> @@ -55,6 +55,17 @@ wants to support one of the below features, it should adapt the bindings below.
>> Number of nanoseconds the SDA signal takes to fall; t(f) in the I2C
>> specification.
>>
>> +- i2c-analog-filter
>> + Enable analog filter for i2c lines.
>> +
>> +- i2c-digital-filter
>> + Enable digital filter for i2c lines.
>> +
>> +- i2c-filter-width-ns
>> + Width of spikes which can be filtered by either digital or analog
>> + filters (i2c-analog-filtr or i2c-digital-filtr). This width is specified
>
> filtr -> filter (two instances)
>
> What if you want/need to have different bandwidth for the digital and analog
> filters? After all, this is a generic binding...
Hi Peter,
For our needs, this is enough: the purpose of the filters is to avoid
noise on the lines, the noise is as big as it is for the digital and for
the analog filters, since we use an absolute measurement for them. So I
do not know how useful it would be to make a difference.
Wolfram, what do you think ?
Eugen
>
> Cheers,
> Peter
>
>> + in nanoseconds.
>> +
>> - interrupts
>> interrupts used by the device.
>>
>>
>
> _______________________________________________
> 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 1/9] dt-bindings: i2c: at91: add new compatible
From: Eugen.Hristev @ 2019-09-02 14:12 UTC (permalink / raw)
To: peda, wsa, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, pierre-yves.mordret,
alexandre.belloni, robh+dt
In-Reply-To: <47d618da-263f-199c-3cc6-35e8f8c6015d@axentia.se>
On 02.09.2019 13:44, Peter Rosin wrote:
>
> On 2019-09-02 12:11, Eugen.Hristev@microchip.com wrote:
>> From: Eugen Hristev <eugen.hristev@microchip.com>
>>
>> Add compatible for new Microchip SoC, sam9x60
>>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
>> ---
>> Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
>> index b7cec17..2210f43 100644
>> --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
>> @@ -3,7 +3,8 @@ I2C for Atmel platforms
>> Required properties :
>> - compatible : Must be "atmel,at91rm9200-i2c", "atmel,at91sam9261-i2c",
>> "atmel,at91sam9260-i2c", "atmel,at91sam9g20-i2c", "atmel,at91sam9g10-i2c",
>> - "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c" or "atmel,sama5d2-i2c"
>> + "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c", "atmel,sama5d2-i2c" or
>> + "microchip,sam9x60-i2c"
>
> IIUC, this list should ideally be reformatted with one compatible per line.
>
> Side note; unfortunate naming with SAM9x60, when there is a preexisting 9260
> fitting the "wildcard" (AFAICT, it's not a wildcard in this case, but it sure
> looks like one).
>
Yes, this is a separate SoC. It is named SAM9X60 and not related to old
9260
Reformatting the list would be useful perhaps in a different cosmetic
patch ?
> Cheers,
> Peter
>
>> - reg: physical base address of the controller and length of memory mapped
>> region.
>> - interrupts: interrupt number to the cpu.
>>
>
> _______________________________________________
> 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
* [PATCH v3 3/4] arm64: use both ZONE_DMA and ZONE_DMA32
From: Nicolas Saenz Julienne @ 2019-09-02 14:10 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, robh+dt,
linux-arm-kernel, linux-mm, linux-riscv, Will Deacon
Cc: f.fainelli, linux-kernel, mbrugger, linux-rpi-kernel, phill,
robin.murphy, nsaenzjulienne, m.szyprowski
In-Reply-To: <20190902141043.27210-1-nsaenzjulienne@suse.de>
So far all arm64 devices have supported 32 bit DMA masks for their
peripherals. This is not true anymore for the Raspberry Pi 4 as most of
it's peripherals can only address the first GB of memory on a total of
up to 4 GB.
This goes against ZONE_DMA32's intent, as it's expected for ZONE_DMA32
to be addressable with a 32 bit mask. So it was decided to re-introduce
ZONE_DMA in arm64.
ZONE_DMA will contain the lower 1G of memory, which is currently the
memory area addressable by any peripheral on an arm64 device.
ZONE_DMA32 will contain the rest of the 32 bit addressable memory.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes in v3:
- Used fixed size ZONE_DMA
- Fix check befor swiotlb_init()
Changes in v2:
- Update comment to reflect new zones split
- ZONE_DMA will never be left empty
arch/arm64/Kconfig | 4 +++
arch/arm64/include/asm/page.h | 2 ++
arch/arm64/mm/init.c | 51 ++++++++++++++++++++++++++++-------
3 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3adcec05b1f6..a9fd71d3bc8e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -266,6 +266,10 @@ config GENERIC_CSUM
config GENERIC_CALIBRATE_DELAY
def_bool y
+config ZONE_DMA
+ bool "Support DMA zone" if EXPERT
+ default y
+
config ZONE_DMA32
bool "Support DMA32 zone" if EXPERT
default y
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index d39ddb258a04..7b8c98830101 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -38,4 +38,6 @@ extern int pfn_valid(unsigned long);
#include <asm-generic/getorder.h>
+#define ARCH_ZONE_DMA_BITS 30
+
#endif
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 8956c22634dd..f02a4945aeac 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -50,6 +50,13 @@
s64 memstart_addr __ro_after_init = -1;
EXPORT_SYMBOL(memstart_addr);
+/*
+ * We create both ZONE_DMA and ZONE_DMA32. ZONE_DMA covers the first 1G of
+ * memory as some devices, namely the Raspberry Pi 4, have peripherals with
+ * this limited view of the memory. ZONE_DMA32 will cover the rest of the 32
+ * bit addressable memory area.
+ */
+phys_addr_t arm64_dma_phys_limit __ro_after_init;
phys_addr_t arm64_dma32_phys_limit __ro_after_init;
#ifdef CONFIG_KEXEC_CORE
@@ -164,9 +171,9 @@ static void __init reserve_elfcorehdr(void)
}
#endif /* CONFIG_CRASH_DUMP */
/*
- * Return the maximum physical address for ZONE_DMA32 (DMA_BIT_MASK(32)). It
- * currently assumes that for memory starting above 4G, 32-bit devices will
- * use a DMA offset.
+ * Return the maximum physical address for ZONE_DMA32 (DMA_BIT_MASK(32)) and
+ * ZONE_DMA (DMA_BIT_MASK(30)) respectively. It currently assumes that for
+ * memory starting above 4G, 32-bit devices will use a DMA offset.
*/
static phys_addr_t __init max_zone_dma32_phys(void)
{
@@ -174,12 +181,23 @@ static phys_addr_t __init max_zone_dma32_phys(void)
return min(offset + (1ULL << 32), memblock_end_of_DRAM());
}
+static phys_addr_t __init max_zone_dma_phys(void)
+{
+ phys_addr_t offset = memblock_start_of_DRAM() & GENMASK_ULL(63, 32);
+
+ return min(offset + (1ULL << ARCH_ZONE_DMA_BITS),
+ memblock_end_of_DRAM());
+}
+
#ifdef CONFIG_NUMA
static void __init zone_sizes_init(unsigned long min, unsigned long max)
{
unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
+#ifdef CONFIG_ZONE_DMA
+ max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
+#endif
#ifdef CONFIG_ZONE_DMA32
max_zone_pfns[ZONE_DMA32] = PFN_DOWN(arm64_dma32_phys_limit);
#endif
@@ -195,13 +213,17 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
struct memblock_region *reg;
unsigned long zone_size[MAX_NR_ZONES], zhole_size[MAX_NR_ZONES];
unsigned long max_dma32 = min;
+ unsigned long max_dma = min;
memset(zone_size, 0, sizeof(zone_size));
- /* 4GB maximum for 32-bit only capable devices */
+#ifdef CONFIG_ZONE_DMA
+ max_dma = PFN_DOWN(arm64_dma_phys_limit);
+ zone_size[ZONE_DMA] = max_dma - min;
+#endif
#ifdef CONFIG_ZONE_DMA32
max_dma32 = PFN_DOWN(arm64_dma32_phys_limit);
- zone_size[ZONE_DMA32] = max_dma32 - min;
+ zone_size[ZONE_DMA32] = max_dma32 - max_dma;
#endif
zone_size[ZONE_NORMAL] = max - max_dma32;
@@ -213,11 +235,17 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
if (start >= max)
continue;
-
+#ifdef CONFIG_ZONE_DMA
+ if (start < max_dma) {
+ unsigned long dma_end = min_not_zero(end, max_dma);
+ zhole_size[ZONE_DMA] -= dma_end - start;
+ }
+#endif
#ifdef CONFIG_ZONE_DMA32
if (start < max_dma32) {
- unsigned long dma_end = min(end, max_dma32);
- zhole_size[ZONE_DMA32] -= dma_end - start;
+ unsigned long dma32_end = min(end, max_dma32);
+ unsigned long dma32_start = max(start, max_dma);
+ zhole_size[ZONE_DMA32] -= dma32_end - dma32_start;
}
#endif
if (end > max_dma32) {
@@ -405,7 +433,9 @@ void __init arm64_memblock_init(void)
early_init_fdt_scan_reserved_mem();
- /* 4GB maximum for 32-bit only capable devices */
+ if (IS_ENABLED(CONFIG_ZONE_DMA))
+ arm64_dma_phys_limit = max_zone_dma_phys();
+
if (IS_ENABLED(CONFIG_ZONE_DMA32))
arm64_dma32_phys_limit = max_zone_dma32_phys();
else
@@ -417,7 +447,7 @@ void __init arm64_memblock_init(void)
high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
- dma_contiguous_reserve(arm64_dma32_phys_limit);
+ dma_contiguous_reserve(arm64_dma_phys_limit ? : arm64_dma32_phys_limit);
}
void __init bootmem_init(void)
@@ -521,6 +551,7 @@ static void __init free_unused_memmap(void)
void __init mem_init(void)
{
if (swiotlb_force == SWIOTLB_FORCE ||
+ max_pfn > (arm64_dma_phys_limit >> PAGE_SHIFT) ||
max_pfn > (arm64_dma32_phys_limit >> PAGE_SHIFT))
swiotlb_init(1);
else
--
2.23.0
_______________________________________________
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 4/4] mm: refresh ZONE_DMA and ZONE_DMA32 comments in 'enum zone_type'
From: Nicolas Saenz Julienne @ 2019-09-02 14:10 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, robh+dt,
linux-arm-kernel, linux-mm, linux-riscv, Paul Walmsley,
Palmer Dabbelt, Albert Ou
Cc: f.fainelli, will, linux-kernel, mbrugger, linux-rpi-kernel, phill,
robin.murphy, nsaenzjulienne, m.szyprowski
In-Reply-To: <20190902141043.27210-1-nsaenzjulienne@suse.de>
These zones usage has evolved with time and the comments were outdated.
This joins both ZONE_DMA and ZONE_DMA32 explanation and gives up to date
examples on how they are used on different architectures.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
Changes in v3:
- Update comment to match changes in arm64
Changes in v2:
- Try another approach merging both ZONE_DMA comments into one
- Address Christoph's comments
- If this approach doesn't get much traction I'll just drop the patch
from the series as it's not really essential
include/linux/mmzone.h | 45 ++++++++++++++++++++++++------------------
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 3f38c30d2f13..bf1b916c9ecb 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -357,33 +357,40 @@ struct per_cpu_nodestat {
#endif /* !__GENERATING_BOUNDS.H */
enum zone_type {
-#ifdef CONFIG_ZONE_DMA
/*
- * ZONE_DMA is used when there are devices that are not able
- * to do DMA to all of addressable memory (ZONE_NORMAL). Then we
- * carve out the portion of memory that is needed for these devices.
- * The range is arch specific.
+ * ZONE_DMA and ZONE_DMA32 are used when there are peripherals not able
+ * to DMA to all of the addressable memory (ZONE_NORMAL).
+ * On architectures where this area covers the whole 32 bit address
+ * space ZONE_DMA32 is used. ZONE_DMA is left for the ones with smaller
+ * DMA addressing constraints. This distinction is important as a 32bit
+ * DMA mask is assumed when ZONE_DMA32 is defined. Some 64-bit
+ * platforms may need both zones as they support peripherals with
+ * different DMA addressing limitations.
+ *
+ * Some examples:
+ *
+ * - i386 and x86_64 have a fixed 16M ZONE_DMA and ZONE_DMA32 for the
+ * rest of the lower 4G.
+ *
+ * - arm only uses ZONE_DMA, the size, up to 4G, may vary depending on
+ * the specific device.
+ *
+ * - arm64 has a fixed 1G ZONE_DMA and ZONE_DMA32 for the rest of the
+ * lower 4G.
*
- * Some examples
+ * - powerpc only uses ZONE_DMA, the size, up to 2G, may vary
+ * depending on the specific device.
*
- * Architecture Limit
- * ---------------------------
- * parisc, ia64, sparc <4G
- * s390, powerpc <2G
- * arm Various
- * alpha Unlimited or 0-16MB.
+ * - s390 uses ZONE_DMA fixed to the lower 2G.
*
- * i386, x86_64 and multiple other arches
- * <16M.
+ * - ia64 and riscv only use ZONE_DMA32.
+ *
+ * - parisc uses neither.
*/
+#ifdef CONFIG_ZONE_DMA
ZONE_DMA,
#endif
#ifdef CONFIG_ZONE_DMA32
- /*
- * x86_64 needs two ZONE_DMAs because it supports devices that are
- * only able to do DMA to the lower 16M but also 32 bit devices that
- * can only do DMA areas below 4G.
- */
ZONE_DMA32,
#endif
/*
--
2.23.0
_______________________________________________
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 0/4] Raspberry Pi 4 DMA addressing support
From: Nicolas Saenz Julienne @ 2019-09-02 14:10 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, robh+dt,
linux-arm-kernel, linux-mm, linux-riscv
Cc: f.fainelli, will, linux-kernel, mbrugger, linux-rpi-kernel, phill,
robin.murphy, nsaenzjulienne, m.szyprowski
Hi all,
this series attempts to address some issues we found while bringing up
the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow
up of these discussions:
v2: https://lkml.org/lkml/2019/8/20/767
v1: https://lkml.org/lkml/2019/7/31/922
RFC: https://lkml.org/lkml/2019/7/17/476
The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can
only address the first GB: their DMA address range is
0xc0000000-0xfc000000 which is aliased to the first GB of physical
memory 0x00000000-0x3c000000. Note that only some peripherals have these
limitations: the PCIe, V3D, GENET, and 40-bit DMA channels have a wider
view of the address space by virtue of being hooked up trough a second
interconnect.
Part of this is solved on arm32 by setting up the machine specific
'.dma_zone_size = SZ_1G', which takes care of reserving the coherent
memory area at the right spot. That said no buffer bouncing (needed for
dma streaming) is available at the moment, but that's a story for
another series.
Unfortunately there is no such thing as 'dma_zone_size' in arm64. Only
ZONE_DMA32 is created which is interpreted by dma-direct and the arm64
arch code as if all peripherals where be able to address the first 4GB
of memory.
In the light of this, the series implements the following changes:
- Create both DMA zones in arm64, ZONE_DMA will contain the first 1G
area and ZONE_DMA32 the rest of the 32 bit addressable memory. So far
the RPi4 is the only arm64 device with such DMA addressing limitations
so this hardcoded solution was deemed preferable.
- Properly set ARCH_ZONE_DMA_BITS.
- Reserve the CMA area in a place suitable for all peripherals.
This series has been tested on multiple devices both by checking the
zones setup matches the expectations and by double-checking physical
addresses on pages allocated on the three relevant areas GFP_DMA,
GFP_DMA32, GFP_KERNEL:
- On an RPi4 with variations on the ram memory size. But also forcing
the situation where all three memory zones are nonempty by setting a 3G
ZONE_DMA32 ceiling on a 4G setup. Both with and without NUMA support.
- On a Synquacer box[1] with 32G of memory.
- On an ACPI based Huawei TaiShan server[2] with 256G of memory.
- On a QEMU virtual machine running arm64's OpenSUSE Tumbleweed.
That's all.
Regards,
Nicolas
[1] https://www.96boards.org/product/developerbox/
[2] https://e.huawei.com/en/products/cloud-computing-dc/servers/taishan-server/taishan-2280-v2
---
Changes in v3:
- Fixed ZONE_DMA's size to 1G
- Update mmzone.h's comment to match changes in arm64
- Remove all dma-direct patches
Changes in v2:
- Update comment to reflect new zones split
- ZONE_DMA will never be left empty
- Try another approach merging both ZONE_DMA comments into one
- Address Christoph's comments
- If this approach doesn't get much traction I'll just drop the patch
from the series as it's not really essential
Nicolas Saenz Julienne (4):
arm64: mm: use arm64_dma_phys_limit instead of calling
max_zone_dma_phys()
arm64: rename variables used to calculate ZONE_DMA32's size
arm64: use both ZONE_DMA and ZONE_DMA32
mm: refresh ZONE_DMA and ZONE_DMA32 comments in 'enum zone_type'
arch/arm64/Kconfig | 4 ++
arch/arm64/include/asm/page.h | 2 +
arch/arm64/mm/init.c | 71 +++++++++++++++++++++++++----------
include/linux/mmzone.h | 45 ++++++++++++----------
4 files changed, 83 insertions(+), 39 deletions(-)
--
2.23.0
_______________________________________________
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 2/4] arm64: rename variables used to calculate ZONE_DMA32's size
From: Nicolas Saenz Julienne @ 2019-09-02 14:10 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, robh+dt,
linux-arm-kernel, linux-mm, linux-riscv, linux-kernel
Cc: f.fainelli, will, mbrugger, linux-rpi-kernel, phill, robin.murphy,
nsaenzjulienne, m.szyprowski
In-Reply-To: <20190902141043.27210-1-nsaenzjulienne@suse.de>
Let the name indicate that they are used to calculate ZONE_DMA32's size
as opposed to ZONE_DMA.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes in v3: None
Changes in v2: None
arch/arm64/mm/init.c | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 6112d6c90fa8..8956c22634dd 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -50,7 +50,7 @@
s64 memstart_addr __ro_after_init = -1;
EXPORT_SYMBOL(memstart_addr);
-phys_addr_t arm64_dma_phys_limit __ro_after_init;
+phys_addr_t arm64_dma32_phys_limit __ro_after_init;
#ifdef CONFIG_KEXEC_CORE
/*
@@ -168,7 +168,7 @@ static void __init reserve_elfcorehdr(void)
* currently assumes that for memory starting above 4G, 32-bit devices will
* use a DMA offset.
*/
-static phys_addr_t __init max_zone_dma_phys(void)
+static phys_addr_t __init max_zone_dma32_phys(void)
{
phys_addr_t offset = memblock_start_of_DRAM() & GENMASK_ULL(63, 32);
return min(offset + (1ULL << 32), memblock_end_of_DRAM());
@@ -181,7 +181,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
#ifdef CONFIG_ZONE_DMA32
- max_zone_pfns[ZONE_DMA32] = PFN_DOWN(arm64_dma_phys_limit);
+ max_zone_pfns[ZONE_DMA32] = PFN_DOWN(arm64_dma32_phys_limit);
#endif
max_zone_pfns[ZONE_NORMAL] = max;
@@ -194,16 +194,16 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
{
struct memblock_region *reg;
unsigned long zone_size[MAX_NR_ZONES], zhole_size[MAX_NR_ZONES];
- unsigned long max_dma = min;
+ unsigned long max_dma32 = min;
memset(zone_size, 0, sizeof(zone_size));
/* 4GB maximum for 32-bit only capable devices */
#ifdef CONFIG_ZONE_DMA32
- max_dma = PFN_DOWN(arm64_dma_phys_limit);
- zone_size[ZONE_DMA32] = max_dma - min;
+ max_dma32 = PFN_DOWN(arm64_dma32_phys_limit);
+ zone_size[ZONE_DMA32] = max_dma32 - min;
#endif
- zone_size[ZONE_NORMAL] = max - max_dma;
+ zone_size[ZONE_NORMAL] = max - max_dma32;
memcpy(zhole_size, zone_size, sizeof(zhole_size));
@@ -215,14 +215,14 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
continue;
#ifdef CONFIG_ZONE_DMA32
- if (start < max_dma) {
- unsigned long dma_end = min(end, max_dma);
+ if (start < max_dma32) {
+ unsigned long dma_end = min(end, max_dma32);
zhole_size[ZONE_DMA32] -= dma_end - start;
}
#endif
- if (end > max_dma) {
+ if (end > max_dma32) {
unsigned long normal_end = min(end, max);
- unsigned long normal_start = max(start, max_dma);
+ unsigned long normal_start = max(start, max_dma32);
zhole_size[ZONE_NORMAL] -= normal_end - normal_start;
}
}
@@ -407,9 +407,9 @@ void __init arm64_memblock_init(void)
/* 4GB maximum for 32-bit only capable devices */
if (IS_ENABLED(CONFIG_ZONE_DMA32))
- arm64_dma_phys_limit = max_zone_dma_phys();
+ arm64_dma32_phys_limit = max_zone_dma32_phys();
else
- arm64_dma_phys_limit = PHYS_MASK + 1;
+ arm64_dma32_phys_limit = PHYS_MASK + 1;
reserve_crashkernel();
@@ -417,7 +417,7 @@ void __init arm64_memblock_init(void)
high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
- dma_contiguous_reserve(arm64_dma_phys_limit);
+ dma_contiguous_reserve(arm64_dma32_phys_limit);
}
void __init bootmem_init(void)
@@ -521,7 +521,7 @@ static void __init free_unused_memmap(void)
void __init mem_init(void)
{
if (swiotlb_force == SWIOTLB_FORCE ||
- max_pfn > (arm64_dma_phys_limit >> PAGE_SHIFT))
+ max_pfn > (arm64_dma32_phys_limit >> PAGE_SHIFT))
swiotlb_init(1);
else
swiotlb_force = SWIOTLB_NO_FORCE;
--
2.23.0
_______________________________________________
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 1/4] arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys()
From: Nicolas Saenz Julienne @ 2019-09-02 14:10 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, robh+dt,
linux-arm-kernel, linux-mm, linux-riscv, linux-kernel
Cc: f.fainelli, will, mbrugger, linux-rpi-kernel, phill, robin.murphy,
nsaenzjulienne, m.szyprowski
In-Reply-To: <20190902141043.27210-1-nsaenzjulienne@suse.de>
By the time we call zones_sizes_init() arm64_dma_phys_limit already
contains the result of max_zone_dma_phys(). We use the variable instead
of calling the function directly to save some precious cpu time.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes in v3: None
Changes in v2: None
arch/arm64/mm/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3c795278def..6112d6c90fa8 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -181,7 +181,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
#ifdef CONFIG_ZONE_DMA32
- max_zone_pfns[ZONE_DMA32] = PFN_DOWN(max_zone_dma_phys());
+ max_zone_pfns[ZONE_DMA32] = PFN_DOWN(arm64_dma_phys_limit);
#endif
max_zone_pfns[ZONE_NORMAL] = max;
--
2.23.0
_______________________________________________
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: [PATCH 00/10] arm64: dts: allwinner: h5: Enable CPU DVFS (cpufreq)
From: Ondřej Jirman @ 2019-09-02 14:03 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: devicetree, Sergey Matyukevich, Maxime Ripard, Andre Przywara,
linux-kernel, Emmanuel Vadot, linux-sunxi, Jagan Teki,
Hauke Mehrtens, linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20190130084203.25053-1-wens@csie.org>
Hi,
On Wed, Jan 30, 2019 at 04:41:53PM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
>
> This series enables DVFS for the CPU cores (aka cpufreq) on the
> Allwinner H5 SoC. The OPP table was taken from Armbian, with minor
> tweaks to the maximum voltage to account for slightly increased voltage
> on some of the boards.
>
> This has been tested on the Bananapi M2+ v1.2 and Libre Computer
> ALL-H3-CC H5 ver.. I do not have the remaining boards so I've CC-ed
> people who did the original submission or have modified the board
> specifically later on.
>
> Patch 1 fixes the voltages specified for the GPIO-controlled regulator
> on the Bananapi M2+ v1.2. The voltages are slightly higher than what
> was originally written.
>
> Patch 2 adds a fixed regulator for the CPU on the original Bananapi M2+.
> This is for the retail version, not the engineering samples that had an
> even higher voltage setting.
>
> Patch 3 hooks up the CPU regulator supply for H5 boards that already
> define the regulator, but were missing the property to tie it to the
> CPUs.
>
> Patch 4 ~ 8 adds the CPU regulator for boards that don't have it
> defined. This is based on each vendor's schematics. I need people
> to test each of these specifically and the whole series.
>
> Patch 9 ties the CPU clock to the CPU cores.
>
> Patch 10 adds the OPP table, based on the one from Armbian.
>
> Please have a look and please help test this.
Looks like this patch series got forgotten. Or is it waiting for some
user testing?
regards,
o.
>
> Regards
> ChenYu
>
>
> Chen-Yu Tsai (10):
> ARM: dts: sunxi: bananapi-m2-plus-v1.2: Fix CPU supply voltages
> ARM: dts: bananapi-m2-plus: Add CPU supply regulator
> arm64: dts: allwinner: h5: Hook up cpu regulator supplies
> arm64: dts: allwinner: h5: nanopi-neo2: Add CPU regulator supply
> arm64: dts: allwinner: h5: orange-pi-zero-plus: Add CPU regulator
> supply
> arm64: dts: allwinner: h5: orange-pi-zero-plus2: Add CPU regulator
> supply
> arm64: dts: allwinner: h5: orange-pi-pc2: Add CPU regulator supply
> arm64: dts: allwinner: h5: orange-pi-prime: Add CPU regulator supply
> arm64: dts: allwinner: h5: Add clock to CPU cores
> arm64: dts: allwinner: h5: Add CPU Operating Performance Points table
>
> .../boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi | 30 +++-----
> arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi | 14 ++++
> .../sun50i-h5-emlid-neutis-n5-devboard.dts | 4 +
> .../allwinner/sun50i-h5-nanopi-neo-plus2.dts | 4 +
> .../dts/allwinner/sun50i-h5-nanopi-neo2.dts | 20 +++++
> .../dts/allwinner/sun50i-h5-orangepi-pc2.dts | 28 +++++++
> .../allwinner/sun50i-h5-orangepi-prime.dts | 28 +++++++
> .../sun50i-h5-orangepi-zero-plus.dts | 20 +++++
> .../sun50i-h5-orangepi-zero-plus2.dts | 20 +++++
> arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 75 +++++++++++++++++++
> 10 files changed, 224 insertions(+), 19 deletions(-)
>
> --
> 2.20.1
>
>
> _______________________________________________
> 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: microblaze HAVE_MEMBLOCK_NODE_MAP dependency (was Re: [PATCH v2 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA)
From: Michal Simek @ 2019-09-02 13:51 UTC (permalink / raw)
To: Mike Rapoport, Michal Hocko
Cc: Catalin Marinas, Will Deacon, open list:MEMORY MANAGEMENT,
Paul Mackerras, H . Peter Anvin, sparclinux@vger.kernel.org,
Alexander Duyck, Will Deacon, linux-s390@vger.kernel.org,
Michael Ellerman, x86@kernel.org, willy@infradead.org,
Christian Borntraeger, Ingo Molnar, Vlastimil Babka,
Benjamin Herrenschmidt, Open Source Submission, Pavel Tatashin,
Vasily Gorbik, Heiko Carstens, Borislav Petkov, Thomas Gleixner,
Hoan Tran OS, Oscar Salvador,
linux-arm-kernel@lists.infradead.org, Randy Dunlap,
linux-kernel@vger.kernel.org, Andrew Morton,
linuxppc-dev@lists.ozlabs.org, David S . Miller
In-Reply-To: <20190731171510.GB24998@rapoport-lnx>
[-- Attachment #1.1.1: Type: text/plain, Size: 4592 bytes --]
On 31. 07. 19 19:15, Mike Rapoport wrote:
> On Wed, Jul 31, 2019 at 04:41:14PM +0200, Michal Hocko wrote:
>> On Wed 31-07-19 17:21:29, Mike Rapoport wrote:
>>> On Wed, Jul 31, 2019 at 03:00:37PM +0200, Michal Hocko wrote:
>>>>
>>>> I am sorry, but I still do not follow. Who is consuming that node id
>>>> information when NUMA=n. In other words why cannot we simply do
>>>
>>> We can, I think nobody cared to change it.
>>
>> It would be great if somebody with the actual HW could try it out.
>> I can throw a patch but I do not even have a cross compiler in my
>> toolbox.
>
> Well, it compiles :)
>
>>>> diff --git a/arch/microblaze/mm/init.c b/arch/microblaze/mm/init.c
>>>> index a015a951c8b7..3a47e8db8d1c 100644
>>>> --- a/arch/microblaze/mm/init.c
>>>> +++ b/arch/microblaze/mm/init.c
>>>> @@ -175,14 +175,9 @@ void __init setup_memory(void)
>>>>
>>>> start_pfn = memblock_region_memory_base_pfn(reg);
>>>> end_pfn = memblock_region_memory_end_pfn(reg);
>>>> - memblock_set_node(start_pfn << PAGE_SHIFT,
>>>> - (end_pfn - start_pfn) << PAGE_SHIFT,
>>>> - &memblock.memory, 0);
>>>> + memory_present(0, start_pfn << PAGE_SHIFT, end_pfn << PAGE_SHIFT);
>>>
>>> memory_present() expects pfns, the shift is not needed.
>>
>> Right.
Sorry for slow response on this. In general regarding this topic.
Microblaze is soft core CPU (now there are hardcore versions too but not
running Linux). I believe there could be Numa system with
microblaze/microblazes (SMP is not supported in mainline).
This code was added in 2011 which is pretty hard to remember why it was
done in this way.
It compiles but not working on HW. Please take a look at log below.
Thanks,
Michal
[ 0.000000] Linux version 5.3.0-rc6-00007-g54b01939182f-dirty
(monstr@monstr-desktop3) (gcc version 8.2.0 (crosstool-NG 1.20.0)) #101
Mon Sep 2 15:44:05 CEST 2019
[ 0.000000] setup_memory: max_mapnr: 0x40000
[ 0.000000] setup_memory: min_low_pfn: 0x80000
[ 0.000000] setup_memory: max_low_pfn: 0xb0000
[ 0.000000] setup_memory: max_pfn: 0xc0000
[ 0.000000] start pfn 0x80000
[ 0.000000] end pfn 0xc0000
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000080000000-0x00000000afffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x00000000b0000000-0x00000000bfffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 1: [mem 0x0000000080000000-0x00000000bfffffff]
[ 0.000000] Could not find start_pfn for node 0
[ 0.000000] Initmem setup node 0 [mem
0x0000000000000000-0x0000000000000000]
[ 0.000000] earlycon: ns16550a0 at MMIO 0x44a01000 (options '115200n8')
[ 0.000000] printk: bootconsole [ns16550a0] enabled
[ 0.000000] setup_cpuinfo: initialising
[ 0.000000] setup_cpuinfo: Using full CPU PVR support
[ 0.000000] wt_msr_noirq
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists, mobility grouping off. Total pages: 0
[ 0.000000] Kernel command line: earlycon
[ 0.000000] Dentry cache hash table entries: -2147483648 (order: -13,
0 bytes, linear)
[ 0.000000] Inode-cache hash table entries: -2147483648 (order: -13,
0 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Oops: kernel access of bad area, sig: 11
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
5.3.0-rc6-00007-g54b01939182f-dirty #101
[ 0.000000] Registers dump: mode=805B9EA8
[ 0.000000] r1=000065A0, r2=C05B7AE6, r3=00000000, r4=00000000
[ 0.000000] r5=00080000, r6=00080B50, r7=00000000, r8=00000004
[ 0.000000] r9=00000000, r10=0000001F, r11=00000000, r12=00006666
[ 0.000000] r13=4119DCC0, r14=00000000, r15=C05EFF8C, r16=00000000
[ 0.000000] r17=C0604408, r18=FFFC0000, r19=C05B9F6C, r20=BFFEC168
[ 0.000000] r21=BFFEC168, r22=EFFF9AC0, r23=00000001, r24=C0606874
[ 0.000000] r25=BFE6B74C, r26=80000000, r27=00000000, r28=90000040
[ 0.000000] r29=01000000, r30=00000380, r31=C05C02F0, rPC=C0604408
[ 0.000000] msr=000046A0, ear=00000004, esr=00000D12, fsr=FFFFFFFF
[ 0.000000] Oops: kernel access of bad area, sig: 11
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 2/3] dt-bindings: sound: Add Xilinx logicPD-I2S FPGA IP bindings
From: Miquel Raynal @ 2019-09-02 13:51 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, alsa-devel, Takashi Iwai, Liam Girdwood,
Mark Brown, alexandre, Thomas Petazzoni, Jaroslav Kysela,
Michal Simek, linux-arm-kernel
In-Reply-To: <20190902044231.GA17348@bogus>
Hi Rob,
Thanks for the review, one question below.
Rob Herring <robh@kernel.org> wrote on Mon, 02 Sep 2019 14:39:09 +0100:
> On Fri, Aug 30, 2019 at 11:06:06PM +0200, Miquel Raynal wrote:
> > Document the logicPD I2S FPGA block bindings in yaml.
> >
> > Syntax verified with dt-doc-validate.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> > .../bindings/sound/xlnx,logicpd-i2s.yaml | 57 +++++++++++++++++++
> > 1 file changed, 57 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/sound/xlnx,logicpd-i2s.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/sound/xlnx,logicpd-i2s.yaml b/Documentation/devicetree/bindings/sound/xlnx,logicpd-i2s.yaml
> > new file mode 100644
> > index 000000000000..cbff641af199
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/sound/xlnx,logicpd-i2s.yaml
> > @@ -0,0 +1,57 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/sound/xlnx,logicpd-i2s.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Device-Tree bindings for Xilinx logicPD I2S FPGA block
> > +
> > +maintainers:
> > + - Miquel Raynal <miquel.raynal@bootlin.com>
> > +
> > +description: |
> > + The IP supports I2S playback/capture audio. It acts as a slave and
> > + clocks should come from the codec. It only supports two channels and
> > + S16_LE format.
> > +
> > +properties:
> > + compatible:
> > + items:
> > + - const: xlnx,logicpd-i2s
> > +
> > + reg:
> > + maxItems: 1
> > + description:
> > + Base address and size of the IP core instance.
> > +
> > + interrupts:
> > + minItems: 1
> > + maxItems: 2
> > + items:
> > + - description: tx interrupt
> > + - description: rx interrupt
> > + description:
> > + Either the Tx interruption or the Rx interruption or both.
>
> The schema says either tx or both. Doesn't really matter here as it's
> just numbers.
I see , I'll drop the 'items' entry.
>
> > +
> > + interrupt-names:
> > + minItems: 1
> > + maxItems: 2
> > + items:
> > + - const: tx
> > + - const: rx
>
> But here it does matter.
>
> The easiest way to express this is:
>
> oneOf:
> - items:
> - enum: [ tx, rx ]
> - items:
> - const: tx
> - const: rx
>
Does this enforce an order? (I don't know if it matters, though, but in
the bellow example I put the Rx interrupt first).
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - interrupts-controller
> > +
> > +examples:
> > + - |
> > + logii2s_dai: logii2s-dai@43c10000 {
> > + reg = <0x43c10000 0x1000>;
> > + compatible = "xlnx,logicpd-i2s-dai";
> > + interrupt-parent = <&intc>;
> > + interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>, <0 30 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-names = "rx", "tx";
> > + };
> > --
> > 2.20.1
> >
>
Thanks,
Miquèl
_______________________________________________
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 1/7] iommu/arm-smmu: add Nvidia SMMUv2 implementation
From: Robin Murphy @ 2019-09-02 13:39 UTC (permalink / raw)
To: Krishna Reddy
Cc: Timo Alho, Thierry Reding, Mikko Perttunen,
linux-kernel@vger.kernel.org, joro@8bytes.org,
will.deacon@arm.com, iommu@lists.linux-foundation.org,
Pritesh Raithatha, Thomas Zeng (SW-TEGRA), Sachin Nikam,
linux-tegra@vger.kernel.org, Yu-Huan Hsu, Juha Tukkinen,
Alexander Van Brunt, linux-arm-kernel@lists.infradead.org
In-Reply-To: <BYAPR12MB2710D045303BE89A7D3FF2C1B3BD0@BYAPR12MB2710.namprd12.prod.outlook.com>
On 30/08/2019 19:16, Krishna Reddy wrote:
>>> +ARM_SMMU_MATCH_DATA(nvidia_smmuv2, ARM_SMMU_V2, NVIDIA_SMMUV2);
>
>> From the previous discussions, I got the impression that other than the 'novel' way they're integrated, the actual SMMU implementations were unmodified Arm MMU-500s. Is that the case, or have I misread something?
>
> The ARM MMU-500 implementation is unmodified. It is the way the are integrated and used together(for interleaved accesses) is different from regular ARM MMU-500.
> I have added it to get the model number and to be able differentiate the SMMU implementation in arm-smmu-impl.c.
In that case, I would rather keep smmu->model representing the MMU-500
microarchitecture - since you'll still want to pick up errata
workarounds etc. for that - and detect the Tegra integration via an
explicit of_device_is_compatible() check in arm_smmu_impl_init(). For
comparison, under ACPI we'd probably have to detect integration details
by looking at table headers, separately from the IORT "Model" field, so
I'd prefer if the DT vs. ACPI handling didn't diverge more than necessary.
Of course, that immediately opens the question of how best to combine
arm_mmu500_impl with nsmmu_impl, but hey, one step at a time :)
Robin.
_______________________________________________
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 v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Rob Herring @ 2019-09-02 13:39 UTC (permalink / raw)
To: Peng Fan
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com,
jassisinghbrar@gmail.com, linux-kernel@vger.kernel.org,
dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1567004515-3567-2-git-send-email-peng.fan@nxp.com>
On Wed, Aug 28, 2019 at 03:02:58AM +0000, Peng Fan wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
> actions in software layers running in the EL2 or EL3 exception levels.
> The term "ARM" here relates to the SMC instruction as part of the ARM
> instruction set, not as a standard endorsed by ARM Ltd.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> .../devicetree/bindings/mailbox/arm-smc.yaml | 125 +++++++++++++++++++++
> 1 file changed, 125 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
>
> diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> new file mode 100644
> index 000000000000..f8eb28d5e307
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> @@ -0,0 +1,125 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ARM SMC Mailbox Interface
> +
> +maintainers:
> + - Peng Fan <peng.fan@nxp.com>
> +
> +description: |
> + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
> + call) instruction to trigger a mailbox-connected activity in firmware,
> + executing on the very same core as the caller. By nature this operation
> + is synchronous and this mailbox provides no way for asynchronous messages
> + to be delivered the other way round, from firmware to the OS, but
> + asynchronous notification could also be supported. However the value of
> + r0/w0/x0 the firmware returns after the smc call is delivered as a received
> + message to the mailbox framework, so a synchronous communication can be
> + established, for a asynchronous notification, no value will be returned.
> + The exact meaning of both the action the mailbox triggers as well as the
> + return value is defined by their users and is not subject to this binding.
> +
> + One use case of this mailbox is the SCMI interface, which uses shared memory
> + to transfer commands and parameters, and a mailbox to trigger a function
> + call. This allows SoCs without a separate management processor (or when
> + such a processor is not available or used) to use this standardized
> + interface anyway.
> +
> + This binding describes no hardware, but establishes a firmware interface.
> + Upon receiving an SMC using one of the described SMC function identifiers,
> + the firmware is expected to trigger some mailbox connected functionality.
> + The communication follows the ARM SMC calling convention.
> + Firmware expects an SMC function identifier in r0 or w0. The supported
> + identifiers are passed from consumers, or listed in the the arm,func-ids
> + properties as described below. The firmware can return one value in
> + the first SMC result register, it is expected to be an error value,
> + which shall be propagated to the mailbox client.
> +
> + Any core which supports the SMC or HVC instruction can be used, as long as
> + a firmware component running in EL3 or EL2 is handling these calls.
> +
> +properties:
> + compatible:
> + const: arm,smc-mbox
> +
> + "#mbox-cells":
> + const: 1
> +
> + arm,num-chans:
> + description: The number of channels supported.
> + items:
> + minimum: 1
> + maximum: 4096 # Should be enough?
> +
> + method:
> + - enum:
Did you build this with 'make dt_binding_check' as this should be a
warning. This should not be a list entry (i.e. drop the '-').
> + - smc
> + - hvc
> +
> + transports:
arm,transports
> + - enum:
> + - mem
> + - reg
> +
> + arm,func-ids:
> + description: |
> + An array of 32-bit values specifying the function IDs used by each
> + mailbox channel. Those function IDs follow the ARM SMC calling
> + convention standard [1].
> +
> + There is one identifier per channel and the number of supported
> + channels is determined by the length of this array.
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 0
> + maxItems: 4096 # Should be enough?
> +
> +required:
> + - compatible
> + - "#mbox-cells"
> + - arm,num-chans
> + - transports
> + - method
> +
> +examples:
> + - |
> + sram@910000 {
> + compatible = "mmio-sram";
> + reg = <0x0 0x93f000 0x0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x0 0x93f000 0x1000>;
> +
> + cpu_scp_lpri: scp-shmem@0 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x0 0x200>;
> + };
> +
> + cpu_scp_hpri: scp-shmem@200 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x200 0x200>;
> + };
> + };
> +
> + firmware {
> + smc_mbox: mailbox {
> + #mbox-cells = <1>;
> + compatible = "arm,smc-mbox";
> + method = "smc";
> + arm,num-chans = <0x2>;
> + transports = "mem";
> + /* Optional */
> + arm,func-ids = <0xc20000fe>, <0xc20000ff>;
> + };
> +
> + scmi {
> + compatible = "arm,scmi";
> + mboxes = <&smc_mbox 0>, <&smc_mbox 1>;
> + mbox-names = "tx", "rx";
> + shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>;
> + };
> + };
> +
> +...
> --
> 2.16.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv3 01/10] dt-bindings: omap: add new binding for PRM instances
From: Rob Herring @ 2019-09-02 13:39 UTC (permalink / raw)
To: Tero Kristo
Cc: devicetree, tony, p.zabel, ssantosh, linux-omap, linux-arm-kernel
In-Reply-To: <20190830121816.30034-2-t-kristo@ti.com>
On Fri, Aug 30, 2019 at 03:18:07PM +0300, Tero Kristo wrote:
> Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
> of these will act as a power domain controller and potentially as a reset
> provider.
>
Converting this to schema would be nice.
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> .../devicetree/bindings/arm/omap/prm-inst.txt | 31 +++++++++++++++++++
bindings/reset/
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> new file mode 100644
> index 000000000000..7c7527c37734
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> @@ -0,0 +1,31 @@
> +OMAP PRM instance bindings
> +
> +Power and Reset Manager is an IP block on OMAP family of devices which
> +handle the power domains and their current state, and provide reset
> +handling for the domains and/or separate IP blocks under the power domain
> +hierarchy.
> +
> +Required properties:
> +- compatible: Must be one of:
> + "ti,am3-prm-inst"
> + "ti,am4-prm-inst"
> + "ti,omap4-prm-inst"
> + "ti,omap5-prm-inst"
> + "ti,dra7-prm-inst"
'-inst' seems a bit redundant.
> +- reg: Contains PRM instance register address range
> + (base address and length)
> +
> +Optional properties:
> +- #reset-cells: Should be 1 if the PRM instance in question supports resets.
> +- clocks: Associated clocks for the reset signals if any. Certain reset
> + signals can't be toggled properly without functional clock
> + being active for them.
> +
> +Example:
> +
> +prm_dsp2: prm@1b00 {
reset-controller@...
> + compatible = "ti,dra7-prm-inst";
> + reg = <0x1b00 0x40>;
> + #reset-cells = <1>;
> + clocks = <&dsp2_clkctrl DRA7_DSP2_MMU0_DSP2_CLKCTRL 0>;
> +};
> --
> 2.17.1
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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 1/5] dt-bindings: fsl: scu: add scu power key binding
From: Rob Herring @ 2019-09-02 13:39 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, ulf.hansson, ping.bai, catalin.marinas, peng.fan,
stefan, bjorn.andersson, leonard.crestez, will, dinguyen,
festevam, marcin.juszkiewicz, jagan, linux-input, ronald,
Linux-imx, devicetree, arnd, s.hauer, mripard, m.felsch, tglx,
andriy.shevchenko, daniel.baluta, linux-arm-kernel, aisheng.dong,
fugang.duan, gregkh, dmitry.torokhov, linux-kernel, hsweeten,
kernel, olof, shawnguo
In-Reply-To: <1567198429-27886-1-git-send-email-Anson.Huang@nxp.com>
On Fri, Aug 30, 2019 at 04:53:45PM -0400, Anson Huang wrote:
> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
> system controller, the system controller is in charge of system
> power, clock and power key event etc. management, Linux kernel
> has to communicate with system controller via MU (message unit)
> IPC to get power key event, add binding doc for i.MX system
> controller power key driver.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> index c149fad..001d0b7 100644
> --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> @@ -157,6 +157,17 @@ Required properties:
> Optional properties:
> - timeout-sec: contains the watchdog timeout in seconds.
>
> +Power key bindings based on SCU Message Protocol
> +------------------------------------------------------------
> +
> +Required properties:
> +- compatible: should be:
> + "fsl,imx8qxp-sc-pwrkey"
> + followed by "fsl,imx-sc-pwrkey";
> +- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt
> +Optional Properties:
> +- wakeup-source: See Documentation/devicetree/bindings/power/wakeup-source.txt
> +
> Example (imx8qxp):
> -------------
> aliases {
> @@ -220,6 +231,13 @@ firmware {
> compatible = "fsl,imx8qxp-sc-rtc";
> };
>
> + scu_pwrkey: scu-pwrkey {
> + compatible = "fsl,imx8qxp-sc-pwrkey", "fsl,imx-sc-pwrkey";
> + linux,keycode = <KEY_POWER>;
> + wakeup-source;
wakeup-source implies an interrupt property.
> + status = "disabled";
Don't should status in examples.
> + };
> +
> watchdog {
> compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
> timeout-sec = <60>;
> --
> 2.7.4
>
_______________________________________________
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] PCI: Remove unused includes and superfluous struct declaration
From: Rob Herring @ 2019-09-02 13:39 UTC (permalink / raw)
To: Krzysztof Wilczynski
Cc: devicetree, Lorenzo Pieralisi, Jingoo Han, Joerg Roedel,
linux-pci, linux-kernel, iommu, Bjorn Helgaas, Thomas Petazzoni,
Gustavo Pimentel, Frank Rowand, linux-arm-kernel
In-Reply-To: <20190901112506.8469-1-kw@linux.com>
On Sun, 1 Sep 2019 13:25:06 +0200, Krzysztof Wilczynski wrote:
> Remove <linux/pci.h> and <linux/msi.h> from being included
> directly as part of the include/linux/of_pci.h, and remove
> superfluous declaration of struct of_phandle_args.
>
> Move users of include <linux/of_pci.h> to include <linux/pci.h>
> and <linux/msi.h> directly rather than rely on both being
> included transitively through <linux/of_pci.h>.
>
> Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
> ---
> drivers/iommu/of_iommu.c | 2 ++
> drivers/pci/controller/dwc/pcie-designware-host.c | 1 +
> drivers/pci/controller/pci-aardvark.c | 1 +
> drivers/pci/pci.c | 1 +
> drivers/pci/probe.c | 1 +
> include/linux/of_pci.h | 4 +---
> 6 files changed, 7 insertions(+), 3 deletions(-)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 02/16] dt-bindings: arm: Convert Marvell MMP board/soc bindings to json-schema
From: Rob Herring @ 2019-09-02 13:39 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Mark Rutland, devicetree, Jason Cooper, Stephen Boyd,
linux-kernel, Michael Turquette, Russell King,
Kishon Vijay Abraham I, Lubomir Rintel, Cc : Rob Herring,
To : Olof Johansson, Thomas Gleixner, linux-clk, linux-arm-kernel
In-Reply-To: <20190830220743.439670-3-lkundrak@v3.sk>
On Sat, 31 Aug 2019 00:07:29 +0200, Lubomir Rintel wrote:
> Convert Marvell MMP SoC bindings to DT schema format using json-schema.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>
> ---
> Changes since v2:
> - Add mrvl,pxa910
> - s/MMP2 Brownstone Board/MMP2 based boards/
>
> Changes since v1:
> - Added this patch
>
> .../devicetree/bindings/arm/mrvl/mrvl.txt | 14 --------
> .../devicetree/bindings/arm/mrvl/mrvl.yaml | 32 +++++++++++++++++++
> 2 files changed, 32 insertions(+), 14 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> create mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 2/3] dt-bindings: sound: Add Xilinx logicPD-I2S FPGA IP bindings
From: Rob Herring @ 2019-09-02 13:39 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland, devicetree, alsa-devel, Takashi Iwai, Liam Girdwood,
Mark Brown, alexandre, Thomas Petazzoni, Jaroslav Kysela,
Michal Simek, linux-arm-kernel
In-Reply-To: <20190830210607.22644-2-miquel.raynal@bootlin.com>
On Fri, Aug 30, 2019 at 11:06:06PM +0200, Miquel Raynal wrote:
> Document the logicPD I2S FPGA block bindings in yaml.
>
> Syntax verified with dt-doc-validate.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> .../bindings/sound/xlnx,logicpd-i2s.yaml | 57 +++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/xlnx,logicpd-i2s.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/xlnx,logicpd-i2s.yaml b/Documentation/devicetree/bindings/sound/xlnx,logicpd-i2s.yaml
> new file mode 100644
> index 000000000000..cbff641af199
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/xlnx,logicpd-i2s.yaml
> @@ -0,0 +1,57 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/xlnx,logicpd-i2s.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Device-Tree bindings for Xilinx logicPD I2S FPGA block
> +
> +maintainers:
> + - Miquel Raynal <miquel.raynal@bootlin.com>
> +
> +description: |
> + The IP supports I2S playback/capture audio. It acts as a slave and
> + clocks should come from the codec. It only supports two channels and
> + S16_LE format.
> +
> +properties:
> + compatible:
> + items:
> + - const: xlnx,logicpd-i2s
> +
> + reg:
> + maxItems: 1
> + description:
> + Base address and size of the IP core instance.
> +
> + interrupts:
> + minItems: 1
> + maxItems: 2
> + items:
> + - description: tx interrupt
> + - description: rx interrupt
> + description:
> + Either the Tx interruption or the Rx interruption or both.
The schema says either tx or both. Doesn't really matter here as it's
just numbers.
> +
> + interrupt-names:
> + minItems: 1
> + maxItems: 2
> + items:
> + - const: tx
> + - const: rx
But here it does matter.
The easiest way to express this is:
oneOf:
- items:
- enum: [ tx, rx ]
- items:
- const: tx
- const: rx
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupts-controller
> +
> +examples:
> + - |
> + logii2s_dai: logii2s-dai@43c10000 {
> + reg = <0x43c10000 0x1000>;
> + compatible = "xlnx,logicpd-i2s-dai";
> + interrupt-parent = <&intc>;
> + interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>, <0 30 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "rx", "tx";
> + };
> --
> 2.20.1
>
_______________________________________________
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 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller
From: Rob Herring @ 2019-09-02 13:39 UTC (permalink / raw)
To: Guido Günther
Cc: devicetree, Jernej Skrabec, Daniel Vetter, Sam Ravnborg,
Neil Armstrong, To : David Airlie, Lee Jones, Sascha Hauer,
Jonas Karlman, linux-kernel, dri-devel, Andrzej Hajda,
Arnd Bergmann, NXP Linux Team, Pengutronix Kernel Team,
Robert Chiras, Fabio Estevam, Guido Günther,
linux-arm-kernel, Laurent Pinchart
In-Reply-To: <64ec3f9375d9684f432dba48af63e3a5de8875f5.1567169464.git.agx@sigxcpu.org>
On Fri, 30 Aug 2019 14:58:21 +0200, =?UTF-8?q?Guido=20G=C3=BCnther?= wrote:
> The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> Tested-by: Robert Chiras <robert.chiras@nxp.com>
> ---
> .../bindings/display/bridge/nwl-dsi.yaml | 176 ++++++++++++++++++
> 1 file changed, 176 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 2/7] dt-bindings: usb: mtk-xhci: support USB wakeup for MT8183
From: Rob Herring @ 2019-09-02 13:39 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland, devicetree, Mathias Nyman, Greg Kroah-Hartman,
linux-usb, linux-kernel, Matthias Brugger, Rob Herring,
linux-mediatek, Chunfeng Yun, linux-arm-kernel
In-Reply-To: <1567150854-30033-3-git-send-email-chunfeng.yun@mediatek.com>
On Fri, 30 Aug 2019 15:40:49 +0800, Chunfeng Yun wrote:
> Support USB wakeup by ip-sleep mode for MT8183
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> v2~v3: no changes
> ---
> Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 v7 1/6] dt-bindings: usb: musb: Add support for MediaTek musb controller
From: Rob Herring @ 2019-09-02 13:39 UTC (permalink / raw)
To: min.guo
Cc: Mark Rutland, hdegoede, devicetree, tony, Greg Kroah-Hartman,
linux-usb, linux-kernel, chunfeng.yun, Alan Stern, Min Guo,
Matthias Brugger, linux-mediatek, Bin Liu, linux-arm-kernel
In-Reply-To: <20190830082026.30401-2-min.guo@mediatek.com>
On Fri, 30 Aug 2019 16:20:21 +0800, <min.guo@mediatek.com> wrote:
> From: Min Guo <min.guo@mediatek.com>
>
> This adds support for MediaTek musb controller in
> host, peripheral and otg mode.
>
> Signed-off-by: Min Guo <min.guo@mediatek.com>
> ---
> changes in v7:
> 1. Modify compatible as
> - compatible : should be one of:
> "mediatek,mt2701-musb"
> ...
> followed by "mediatek,mtk-musb"
> 2. Change usb connector child node compatible as "gpio-usb-b-connector"
>
> changes in v6:
> 1. Modify usb connector child node
>
> changes in v5:
> suggested by Rob:
> 1. Modify compatible as
> - compatible : should be one of:
> "mediatek,mt-2701"
> ...
> followed by "mediatek,mtk-musb"
> 2. Add usb connector child node
>
> changes in v4:
> suggested by Sergei:
> 1. String alignment
>
> changes in v3:
> 1. no changes
>
> changes in v2:
> suggested by Bin:
> 1. Modify DRC to DRD
> suggested by Rob:
> 2. Drop the "<soc-model>-musb" in compatible
> 3. Remove phy-names
> 4. Add space after comma in clock-names
> ---
> .../devicetree/bindings/usb/mediatek,musb.txt | 55 ++++++++++++++++++++++
> 1 file changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 1/7] dt-bindings: usb: mtu3: support USB wakeup for MT8183
From: Rob Herring @ 2019-09-02 13:39 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland, devicetree, Mathias Nyman, Greg Kroah-Hartman,
linux-usb, linux-kernel, Matthias Brugger, Rob Herring,
linux-mediatek, Chunfeng Yun, linux-arm-kernel
In-Reply-To: <1567150854-30033-2-git-send-email-chunfeng.yun@mediatek.com>
On Fri, 30 Aug 2019 15:40:48 +0800, Chunfeng Yun wrote:
> Support USB wakeup by ip-sleep mode for MT8183
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> v2~v3: no changes
> ---
> Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
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