* Re: [PATCH 3/3] arm64: dts: qcom: Add initial support for Xiaomi Redmi Note 8T
From: Eli Riggs @ 2020-05-19 11:20 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, Rob Herring, linux-arm-msm, devicetree, linux-kernel,
~postmarketos/upstreaming
In-Reply-To: <20200519061114.GC2165@builder.lan>
On Mon, 18 May 2020 23:11:14 -0700
Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
> On Sun 17 May 04:54 PDT 2020, Eli Riggs wrote:
>
> > Adds initial device tree for Xiaomi Redmi Note 8T, codename
> > xiaomi-willow. It uses the sm6125 SoC. Currently only boots into
> > initrd shell over UART. Requires appended DTB with qcom,board-id =
> > <0x22 0x0> and qcom,msm-id = <0x18a 0x10000> to actually boot.
> >
>
> If I read this correctly you need to supply board-id and msm-id in
> order to be able to get this booting?
>
> Even though we don't like them, I would prefer if you just add them in
> the dts file, in this patch.
Yes, AFAICT the bootloader iterates over the appended DTBs and will
only boot if it finds one with those matching properties.
> > dtb-$(CONFIG_ARCH_QCOM) += sm8250-mtp.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-1000.dtb diff --git
> > a/arch/arm64/boot/dts/qcom/sm6125-xiaomi-willow.dts
> > b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-willow.dts new file mode
> > 100644 index 0000000000000..444b32ccb9d48 --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-willow.dts
> > @@ -0,0 +1,19 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
>
> Please make this GPL/BSD dual license.
>
> Apart from these few remarks your patches looks good, looking forward
> to see more of this platform!
>
> Regards,
> Bjorn
OK, thanks!
^ permalink raw reply
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Geert Uytterhoeven @ 2020-05-19 11:21 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Lukasz Stelmach, Dmitry Osipenko, Nicolas Pitre, Arnd Bergmann,
Eric Miao, Uwe Kleine-König, Masahiro Yamada, Ard Biesheuvel,
Marek Szyprowski, Chris Brandt, Linux ARM, Linux-Renesas,
Linux Kernel Mailing List, Bartlomiej Zolnierkiewicz,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Grant Likely
In-Reply-To: <20200519094637.GZ1551@shell.armlinux.org.uk>
Hi Russell,
CC devicetree
On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
> > On Tue, May 19, 2020 at 10:54 AM Lukasz Stelmach <l.stelmach@samsung.com> wrote:
> > > It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
> > > > Currently, the start address of physical memory is obtained by masking
> > > > the program counter with a fixed mask of 0xf8000000. This mask value
> > > > was chosen as a balance between the requirements of different platforms.
> > > > However, this does require that the start address of physical memory is
> > > > a multiple of 128 MiB, precluding booting Linux on platforms where this
> > > > requirement is not fulfilled.
> > > >
> > > > Fix this limitation by obtaining the start address from the DTB instead,
> > > > if available (either explicitly passed, or appended to the kernel).
> > > > Fall back to the traditional method when needed.
> > > >
> > > > This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> > > > on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> > > > i.e. not at a multiple of 128 MiB.
> > > >
> > > > Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> > > > Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> > > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > > Tested-by: Dmitry Osipenko <digetx@gmail.com>
> > > > ---
> > >
> > > [...]
> > >
> > > Apparently reading physical memory layout from DTB breaks crashdump
> > > kernels. A crashdump kernel is loaded into a region of memory, that is
> > > reserved in the original (i.e. to be crashed) kernel. The reserved
> > > region is large enough for the crashdump kernel to run completely inside
> > > it and don't modify anything outside it, just read and dump the remains
> > > of the crashed kernel. Using the information from DTB makes the
> > > decompressor place the kernel outside of the dedicated region.
> > >
> > > The log below shows that a zImage and DTB are loaded at 0x18eb8000 and
> > > 0x193f6000 (physical). The kernel is expected to run at 0x18008000, but
> > > it is decompressed to 0x00008000 (see r4 reported before jumping from
> > > within __enter_kernel). If I were to suggest something, there need to be
> > > one more bit of information passed in the DTB telling the decompressor
> > > to use the old masking technique to determain kernel address. It would
> > > be set in the DTB loaded along with the crashdump kernel.
> >
> > Shouldn't the DTB passed to the crashkernel describe which region of
> > memory is to be used instead?
>
> Definitely not. The crashkernel needs to know where the RAM in the
> machine is, so that it can create a coredump of the crashed kernel.
So the DTB should describe both ;-)
> > Describing "to use the old masking technique" sounds a bit hackish to me.
> > I guess it cannot just restrict the /memory node to the reserved region,
> > as the crashkernel needs to be able to dump the remains of the crashed
> > kernel, which lie outside this region.
>
> Correct.
>
> > However, something under /chosen should work.
>
> Yet another sticky plaster...
IMHO the old masking technique is the hacky solution covered by
plasters.
DT describes the hardware. In general, where to put the kernel is a
software policy, and thus doesn't belong in DT, except perhaps under
/chosen. But that would open another can of worms, as people usually
have no business in specifying where the kernel should be located.
In the crashkernel case, there is a clear separation between memory to
be used by the crashkernel, and memory to be solely inspected by the
crashkernel.
Devicetree Specification, Release v0.3, Section 3.4 "/memory node" says:
"The client program may access memory not covered by any memory
reservations (see section 5.3)"
(Section 5.3 "Memory Reservation Block" only talks about structures in
the FDT, not about DTS)
Hence according to the above, the crashkernel is rightfully allowed to
do whatever it wants with all memory under the /memory node.
However, there is also
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt.
This suggests the crashkernel should be passed a DTB that contains a
/reserved-memory node, describing which memory cannot be used freely.
Then the decompressor needs to take this into account when deciding
where the put the kernel.
Yes, the above requires changing code. But at least it provides a
path forward, getting rid of the fragile old masking technique.
Thanks for your comments!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Arnd Bergmann @ 2020-05-19 11:28 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King - ARM Linux admin, Lukasz Stelmach, Dmitry Osipenko,
Nicolas Pitre, Eric Miao, Uwe Kleine-König, Masahiro Yamada,
Ard Biesheuvel, Marek Szyprowski, Chris Brandt, Linux ARM,
Linux-Renesas, Linux Kernel Mailing List,
Bartlomiej Zolnierkiewicz,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Grant Likely
In-Reply-To: <CAMuHMdU5DG06G4H=+PH+OONMT_9oE==KS=wP+bLgY9xVCez6Ww@mail.gmail.com>
On Tue, May 19, 2020 at 1:21 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > > However, something under /chosen should work.
> >
> > Yet another sticky plaster...
>
> IMHO the old masking technique is the hacky solution covered by
> plasters.
>
> DT describes the hardware. In general, where to put the kernel is a
> software policy, and thus doesn't belong in DT, except perhaps under
> /chosen. But that would open another can of worms, as people usually
> have no business in specifying where the kernel should be located.
> In the crashkernel case, there is a clear separation between memory to
> be used by the crashkernel, and memory to be solely inspected by the
> crashkernel.
>
> Devicetree Specification, Release v0.3, Section 3.4 "/memory node" says:
>
> "The client program may access memory not covered by any memory
> reservations (see section 5.3)"
>
> (Section 5.3 "Memory Reservation Block" only talks about structures in
> the FDT, not about DTS)
>
> Hence according to the above, the crashkernel is rightfully allowed to
> do whatever it wants with all memory under the /memory node.
> However, there is also
> Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt.
> This suggests the crashkernel should be passed a DTB that contains a
> /reserved-memory node, describing which memory cannot be used freely.
> Then the decompressor needs to take this into account when deciding
> where the put the kernel.
>
> Yes, the above requires changing code. But at least it provides a
> path forward, getting rid of the fragile old masking technique.
There is an existing "linux,usable-memory-range" property documented
in Documentation/devicetree/bindings/chosen.txt, which as I understand
is exactly what you are looking for, except that it is currently only
documented for arm64.
Would extending this to arm work?
Arnd
^ permalink raw reply
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Russell King - ARM Linux admin @ 2020-05-19 11:43 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Lukasz Stelmach, Dmitry Osipenko, Nicolas Pitre, Arnd Bergmann,
Eric Miao, Uwe Kleine-König, Masahiro Yamada, Ard Biesheuvel,
Marek Szyprowski, Chris Brandt, Linux ARM, Linux-Renesas,
Linux Kernel Mailing List, Bartlomiej Zolnierkiewicz,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Grant Likely
In-Reply-To: <CAMuHMdU5DG06G4H=+PH+OONMT_9oE==KS=wP+bLgY9xVCez6Ww@mail.gmail.com>
On Tue, May 19, 2020 at 01:21:09PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
>
> CC devicetree
>
> On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> > On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
> > > On Tue, May 19, 2020 at 10:54 AM Lukasz Stelmach <l.stelmach@samsung.com> wrote:
> > > > It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
> > > > > Currently, the start address of physical memory is obtained by masking
> > > > > the program counter with a fixed mask of 0xf8000000. This mask value
> > > > > was chosen as a balance between the requirements of different platforms.
> > > > > However, this does require that the start address of physical memory is
> > > > > a multiple of 128 MiB, precluding booting Linux on platforms where this
> > > > > requirement is not fulfilled.
> > > > >
> > > > > Fix this limitation by obtaining the start address from the DTB instead,
> > > > > if available (either explicitly passed, or appended to the kernel).
> > > > > Fall back to the traditional method when needed.
> > > > >
> > > > > This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> > > > > on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> > > > > i.e. not at a multiple of 128 MiB.
> > > > >
> > > > > Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > > Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> > > > > Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> > > > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > > > Tested-by: Dmitry Osipenko <digetx@gmail.com>
> > > > > ---
> > > >
> > > > [...]
> > > >
> > > > Apparently reading physical memory layout from DTB breaks crashdump
> > > > kernels. A crashdump kernel is loaded into a region of memory, that is
> > > > reserved in the original (i.e. to be crashed) kernel. The reserved
> > > > region is large enough for the crashdump kernel to run completely inside
> > > > it and don't modify anything outside it, just read and dump the remains
> > > > of the crashed kernel. Using the information from DTB makes the
> > > > decompressor place the kernel outside of the dedicated region.
> > > >
> > > > The log below shows that a zImage and DTB are loaded at 0x18eb8000 and
> > > > 0x193f6000 (physical). The kernel is expected to run at 0x18008000, but
> > > > it is decompressed to 0x00008000 (see r4 reported before jumping from
> > > > within __enter_kernel). If I were to suggest something, there need to be
> > > > one more bit of information passed in the DTB telling the decompressor
> > > > to use the old masking technique to determain kernel address. It would
> > > > be set in the DTB loaded along with the crashdump kernel.
> > >
> > > Shouldn't the DTB passed to the crashkernel describe which region of
> > > memory is to be used instead?
> >
> > Definitely not. The crashkernel needs to know where the RAM in the
> > machine is, so that it can create a coredump of the crashed kernel.
>
> So the DTB should describe both ;-)
>
> > > Describing "to use the old masking technique" sounds a bit hackish to me.
> > > I guess it cannot just restrict the /memory node to the reserved region,
> > > as the crashkernel needs to be able to dump the remains of the crashed
> > > kernel, which lie outside this region.
> >
> > Correct.
> >
> > > However, something under /chosen should work.
> >
> > Yet another sticky plaster...
>
> IMHO the old masking technique is the hacky solution covered by
> plasters.
One line of code is not "covered by plasters". There are no plasters.
It's a solution that works for 99.99% of people, unlike your approach
that has had a stream of issues over the last four months, and has
required many reworks of the code to fix each one. That in itself
speaks volumes about the suitability of the approach.
> DT describes the hardware.
Right, so DT is correct.
> In general, where to put the kernel is a
> software policy, and thus doesn't belong in DT, except perhaps under
> /chosen. But that would open another can of worms, as people usually
> have no business in specifying where the kernel should be located.
> In the crashkernel case, there is a clear separation between memory to
> be used by the crashkernel, and memory to be solely inspected by the
> crashkernel.
>
> Devicetree Specification, Release v0.3, Section 3.4 "/memory node" says:
>
> "The client program may access memory not covered by any memory
> reservations (see section 5.3)"
>
> (Section 5.3 "Memory Reservation Block" only talks about structures in
> the FDT, not about DTS)
>
> Hence according to the above, the crashkernel is rightfully allowed to
> do whatever it wants with all memory under the /memory node.
> However, there is also
> Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt.
> This suggests the crashkernel should be passed a DTB that contains a
> /reserved-memory node, describing which memory cannot be used freely.
> Then the decompressor needs to take this into account when deciding
> where the put the kernel.
So you want to throw yet more complexity at this solution to try and
make it work...
> Yes, the above requires changing code. But at least it provides a
> path forward, getting rid of the fragile old masking technique.
It's hardly fragile when it's worked fine for the last 20+ years,
whereas your solution can't work without some regression being reported
within a couple of weeks of it being applied. Again, that speaks
volumes about which one is better than the other.
Continually patching this approach to workaround one issue after another
shows that it is _this_ solution that is the fragile implementation.
A fragile implementation is by definition one that keeps breaking.
That's yours. The masking approach hasn't "broken" for anyone, and
hasn't been the cause of one single regression anywhere. Yes, there
are some platforms that it doesn't work for (because they choose to
reserve the first chunk of RAM for something) but that is not a
regression.
So, I'm not going to apply the next revision of this patch for at least
one whole kernel cycle - that means scheduling it for 5.10-rc at the
earliest.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
^ permalink raw reply
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Lukasz Stelmach @ 2020-05-19 11:46 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King - ARM Linux admin, Dmitry Osipenko, Nicolas Pitre,
Arnd Bergmann, Eric Miao, Uwe Kleine-König, Masahiro Yamada,
Ard Biesheuvel, Marek Szyprowski, Chris Brandt, Linux ARM,
Linux-Renesas, Linux Kernel Mailing List,
Bartlomiej Zolnierkiewicz,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Grant Likely
In-Reply-To: <CAMuHMdU5DG06G4H=+PH+OONMT_9oE==KS=wP+bLgY9xVCez6Ww@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3210 bytes --]
It was <2020-05-19 wto 13:21>, when Geert Uytterhoeven wrote:
> Hi Russell,
>
> CC devicetree
>
> On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
>> On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
>>> On Tue, May 19, 2020 at 10:54 AM Lukasz Stelmach <l.stelmach@samsung.com> wrote:
>>>> It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
>>>>> Currently, the start address of physical memory is obtained by masking
>>>>> the program counter with a fixed mask of 0xf8000000. This mask value
>>>>> was chosen as a balance between the requirements of different platforms.
>>>>> However, this does require that the start address of physical memory is
>>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
>>>>> requirement is not fulfilled.
>>>>>
>>>>> Fix this limitation by obtaining the start address from the DTB instead,
>>>>> if available (either explicitly passed, or appended to the kernel).
>>>>> Fall back to the traditional method when needed.
>>>>>
>>>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
>>>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
>>>>> i.e. not at a multiple of 128 MiB.
>>>>>
>>>>> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
>>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
>>>>> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
>>>>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>> Tested-by: Dmitry Osipenko <digetx@gmail.com>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>> Apparently reading physical memory layout from DTB breaks crashdump
>>>> kernels. A crashdump kernel is loaded into a region of memory, that
>>>> is reserved in the original (i.e. to be crashed) kernel. The
>>>> reserved region is large enough for the crashdump kernel to run
>>>> completely inside it and don't modify anything outside it, just
>>>> read and dump the remains of the crashed kernel. Using the
>>>> information from DTB makes the decompressor place the kernel
>>>> outside of the dedicated region.
>>>>
>>>> The log below shows that a zImage and DTB are loaded at 0x18eb8000
>>>> and 0x193f6000 (physical). The kernel is expected to run at
>>>> 0x18008000, but it is decompressed to 0x00008000 (see r4 reported
>>>> before jumping from within __enter_kernel). If I were to suggest
>>>> something, there need to be one more bit of information passed in
>>>> the DTB telling the decompressor to use the old masking technique
>>>> to determain kernel address. It would be set in the DTB loaded
>>>> along with the crashdump kernel.
>>>
>>> Shouldn't the DTB passed to the crashkernel describe which region of
>>> memory is to be used instead?
>>
>> Definitely not. The crashkernel needs to know where the RAM in the
>> machine is, so that it can create a coredump of the crashed kernel.
>
> So the DTB should describe both ;-)
So we can do without the mem= cmdline option which is required
now. Sounds reasonable to me.
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply
* Re: [PATCH 04/10] dt-bindings: spi: Add bindings for spi-dw-mchp
From: Lars Povlsen @ 2020-05-19 11:47 UTC (permalink / raw)
To: Mark Brown
Cc: SoC Team, Rob Herring, Microchip Linux Driver Support, linux-spi,
devicetree, linux-kernel, linux-arm-kernel, Alexandre Belloni,
Serge Semin, Serge Semin, Andy Shevchenko, Wan Ahmad Zainie,
Lars Povlsen
In-Reply-To: <20200513145213.GJ4803@sirena.org.uk>
On 13/05/20 15:52, Mark Brown wrote:
> Date: Wed, 13 May 2020 15:52:13 +0100
> From: Mark Brown <broonie@kernel.org>
> To: Lars Povlsen <lars.povlsen@microchip.com>
> Cc: SoC Team <soc@kernel.org>, Rob Herring <robh+dt@kernel.org>, Microchip
> Linux Driver Support <UNGLinuxDriver@microchip.com>,
> linux-spi@vger.kernel.org, devicetree@vger.kernel.org,
> linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
> Alexandre Belloni <alexandre.belloni@bootlin.com>, Serge Semin
> <Sergey.Semin@baikalelectronics.ru>, Serge Semin
> <fancer.lancer@gmail.com>, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com>, Wan Ahmad Zainie
> <wan.ahmad.zainie.wan.mohamad@intel.com>
> Subject: Re: [PATCH 04/10] dt-bindings: spi: Add bindings for spi-dw-mchp
> User-Agent: Mutt/1.10.1 (2018-07-13)
>
> On Wed, May 13, 2020 at 04:00:25PM +0200, Lars Povlsen wrote:
> > This add DT bindings for the Microsemi/Microchip SPI controller used
> > in various SoC's. It describes the "mscc,ocelot-spi" and
> > "mscc,jaguar2-spi" bindings.
>
> > Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> > ---
> > .../bindings/spi/mscc,ocelot-spi.yaml | 60 +++++++++++++++++++
> > .../bindings/spi/snps,dw-apb-ssi.txt | 7 +--
>
> That's not what this change does. It is removing the existing binding
> for Ocelot and Jaguar2 from the free format binding documentation and
> adds some entirely separate YAML bindings for them. This conflicts with
> competing YAML conversions that both Serge Semin and Wan Ahmad Zainie
> (CCed) have in flight at the minute. It also doesn't strike me as a
> good idea to fork the bindings, what's the motivation for doing that?
The reason for doing this was due to the fact that I felt adding
Sparx5 support only cluttered the original driver even more.
And since I was adding a new driver, I needed to add bindings for it -
and (re)move the old ones.
I have become aware of Serge and Wan Ahmad's work, and will work out
something on top of that.
^ permalink raw reply
* Re: [PATCHv1] ARM: dts/imx6q-bx50v3: Set display interface clock parents
From: Sasha Levin @ 2020-05-19 11:49 UTC (permalink / raw)
To: Sasha Levin, Sebastian Reichel, Robert Beckett, Sebastian Reichel
Cc: Rob Herring, devicetree, stable, stable
In-Reply-To: <20200514170236.24814-1-sebastian.reichel@collabora.com>
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.6.13, v5.4.41, v4.19.123, v4.14.180, v4.9.223, v4.4.223.
v5.6.13: Build OK!
v5.4.41: Build OK!
v4.19.123: Build OK!
v4.14.180: Failed to apply! Possible dependencies:
e26dead44268 ("ARM: dts: imx6q-bx50v3: Add internal switch")
v4.9.223: Failed to apply! Possible dependencies:
1d0c7bb20c08 ("ARM: dts: imx: Correct B850v3 clock assignment")
e26dead44268 ("ARM: dts: imx6q-bx50v3: Add internal switch")
v4.4.223: Failed to apply! Possible dependencies:
15ef03b86247 ("ARM: dts: imx: b450/b650v3: Move ldb_di clk assignment")
1d0c7bb20c08 ("ARM: dts: imx: Correct B850v3 clock assignment")
2252792b4677 ("ARM: dts: imx: Add support for Advantech/GE B850v3")
226d16c80c61 ("ARM: dts: imx: Add support for Advantech/GE Bx50v3")
547da6bbcf08 ("ARM: dts: imx: Add support for Advantech/GE B450v3")
987e71877ae6 ("ARM: dts: imx: Add support for Advantech/GE B650v3")
b492b8744da9 ("ARM: dts: imx6q-b850v3: Update display clock source")
e26dead44268 ("ARM: dts: imx6q-bx50v3: Add internal switch")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: sc16is7xx: Add flag to activate IrDA mode
From: Maarten Brock @ 2020-05-19 12:01 UTC (permalink / raw)
To: Daniel Mack
Cc: Rob Herring, devicetree, linux-serial, gregkh, jslaby,
pascal.huerst, linux-serial-owner
In-Reply-To: <0494dbe1-81ad-493c-6eb0-a463a5604309@zonque.org>
On 2020-05-18 20:41, Daniel Mack wrote:
> On 5/18/20 8:08 PM, Rob Herring wrote:
>> On Fri, May 08, 2020 at 04:37:54PM +0200, Daniel Mack wrote:
>>> From: Pascal Huerst <pascal.huerst@gmail.com>
>>>
>>> This series of uart controllers is able to work in IrDA mode.
>>> This adds a flag to the device tree to enable that feature if needed.
>>>
>>> Signed-off-by: Pascal Huerst <pascal.huerst@gmail.com>
>>> ---
>>> Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
>>> b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
>>> index c1091a923a89..9317c320c82c 100644
>>> --- a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
>>> +++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
>>> @@ -21,6 +21,8 @@ Optional properties:
>>> the second cell is used to specify the GPIO polarity:
>>> 0 = active high,
>>> 1 = active low.
>>> +- linux,irda-mode-port-0: Use IrDA mode on port #0
>>> +- linux,irda-mode-port-1: Use IrDA mode on port #1 (for dual-port
>>> devices only)
>>>
>>> Example:
>>> sc16is750: sc16is750@51 {
>>> @@ -55,6 +57,8 @@ Optional properties:
>>> the second cell is used to specify the GPIO polarity:
>>> 0 = active high,
>>> 1 = active low.
>>> +- linux,irda-mode-port-0: Use IrDA mode on port #0
>>> +- linux,irda-mode-port-1: Use IrDA mode on port #1 (for dual-port
>>> devices only)
>>
>> How about an array of 1 or 2 entries instead?
I like this idea.
> Yes, that would be an alternative. We just weren't sure what type the
> elements of the array would have. Could you point to an existing
> example?
I think you need device_property_read_u8_array(). I can only find
device_property_read_u32_array() used in the serial drivers tree in
serial_core.c,
but that should be similar.
Maarten
^ permalink raw reply
* Re: [PATCH 05/10] spi: spi-dw-mmio: Spin off MSCC platforms into spi-dw-mchp
From: Lars Povlsen @ 2020-05-19 12:05 UTC (permalink / raw)
To: Mark Brown
Cc: SoC Team, Microchip Linux Driver Support, linux-spi, devicetree,
linux-kernel, linux-arm-kernel, Alexandre Belloni, Lars Povlsen
In-Reply-To: <20200513151811.GL4803@sirena.org.uk>
On 13/05/20 16:18, Mark Brown wrote:
> Date: Wed, 13 May 2020 16:18:11 +0100
> From: Mark Brown <broonie@kernel.org>
> To: Lars Povlsen <lars.povlsen@microchip.com>
> Cc: SoC Team <soc@kernel.org>, Microchip Linux Driver Support
> <UNGLinuxDriver@microchip.com>, linux-spi@vger.kernel.org,
> devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
> linux-arm-kernel@lists.infradead.org, Alexandre Belloni
> <alexandre.belloni@bootlin.com>
> Subject: Re: [PATCH 05/10] spi: spi-dw-mmio: Spin off MSCC platforms into
> spi-dw-mchp
> User-Agent: Mutt/1.10.1 (2018-07-13)
>
> On Wed, May 13, 2020 at 04:00:26PM +0200, Lars Povlsen wrote:
>
> > +config SPI_DW_MCHP
> > + tristate "Memory-mapped io interface driver using DW SPI core of MSCC SoCs"
> > + default y if ARCH_SPARX5
> > + default y if SOC_VCOREIII
>
> Why the default ys?
The SoC will typically boot from SPI... But its not a requirement per
se. I will remove it.
>
> > +++ b/drivers/spi/Makefile
> > @@ -37,6 +37,7 @@ obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o
> > obj-$(CONFIG_SPI_DLN2) += spi-dln2.o
> > obj-$(CONFIG_SPI_DESIGNWARE) += spi-dw.o
> > obj-$(CONFIG_SPI_DW_MMIO) += spi-dw-mmio.o
> > +obj-$(CONFIG_SPI_DW_MCHP) += spi-dw-mchp.o
> > obj-$(CONFIG_SPI_DW_PCI) += spi-dw-midpci.o
> > spi-dw-midpci-objs := spi-dw-pci.o spi-dw-mid.o
> > obj-$(CONFIG_SPI_EFM32) += spi-efm32.o
>
> Please keep the file alphabetically sorted.
>
Noted.
> > +++ b/drivers/spi/spi-dw-mchp.c
> > @@ -0,0 +1,232 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Memory-mapped interface driver for MSCC SoCs
> > + *
>
> Please make the entire comment a C++ one so things look more
> intentional.
Sure, I can do that. The presented form matches that of the other
spi-dw-* drivers, but I can see other using // blocks. Ack.
>
> > +#define MAX_CS 4
>
> This should be namespaced.
Ack.
>
> > + rx_sample_dly = 0;
> > + device_property_read_u32(&pdev->dev, "spi-rx-delay-us", &rx_sample_dly);
> > + dws->rx_sample_dly = DIV_ROUND_UP(rx_sample_dly,
> > + (dws->max_freq / 1000000));
>
> If this is a standard feature of the DesignWare IP why parse it here and
> not in the generic code?
This is a standard feature of the DesignWare IP, so good suggestion. I
will arrange with Serge.
Thank you for your comments!
---Lars
^ permalink raw reply
* Re: [PATCH 04/10] dt-bindings: spi: Add bindings for spi-dw-mchp
From: Lars Povlsen @ 2020-05-19 12:10 UTC (permalink / raw)
To: Mark Brown
Cc: SoC Team, Rob Herring, Microchip Linux Driver Support, linux-spi,
devicetree, linux-kernel, linux-arm-kernel, Alexandre Belloni,
Serge Semin, Serge Semin, Andy Shevchenko, Wan Ahmad Zainie,
Lars Povlsen
In-Reply-To: <20200519115829.GI4611@sirena.org.uk>
On 19/05/20 12:58, Mark Brown wrote:
> Date: Tue, 19 May 2020 12:58:29 +0100
> From: Mark Brown <broonie@kernel.org>
> To: Lars Povlsen <lars.povlsen@microchip.com>
> Cc: SoC Team <soc@kernel.org>, Rob Herring <robh+dt@kernel.org>, Microchip
> Linux Driver Support <UNGLinuxDriver@microchip.com>,
> linux-spi@vger.kernel.org, devicetree@vger.kernel.org,
> linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
> Alexandre Belloni <alexandre.belloni@bootlin.com>, Serge Semin
> <Sergey.Semin@baikalelectronics.ru>, Serge Semin
> <fancer.lancer@gmail.com>, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com>, Wan Ahmad Zainie
> <wan.ahmad.zainie.wan.mohamad@intel.com>
> Subject: Re: [PATCH 04/10] dt-bindings: spi: Add bindings for spi-dw-mchp
> User-Agent: Mutt/1.10.1 (2018-07-13)
>
> On Tue, May 19, 2020 at 01:47:39PM +0200, Lars Povlsen wrote:
> > On 13/05/20 15:52, Mark Brown wrote:
>
> > > On Wed, May 13, 2020 at 04:00:25PM +0200, Lars Povlsen wrote:
> > > > This add DT bindings for the Microsemi/Microchip SPI controller used
> > > > in various SoC's. It describes the "mscc,ocelot-spi" and
> > > > "mscc,jaguar2-spi" bindings.
>
> > > That's not what this change does. It is removing the existing binding
> > > for Ocelot and Jaguar2 from the free format binding documentation and
>
> > The reason for doing this was due to the fact that I felt adding
> > Sparx5 support only cluttered the original driver even more.
>
> That's not the issue I'm pointing out there. The issue is that your
> changelog claims that the change does one thing and the change itself
> does something substantially different.
Ok, got it. I'll reword the changelog to be more precise.
Thanks again,
---Lars
^ permalink raw reply
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Geert Uytterhoeven @ 2020-05-19 12:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King - ARM Linux admin, Lukasz Stelmach, Dmitry Osipenko,
Nicolas Pitre, Eric Miao, Uwe Kleine-König, Masahiro Yamada,
Ard Biesheuvel, Marek Szyprowski, Chris Brandt, Linux ARM,
Linux-Renesas, Linux Kernel Mailing List,
Bartlomiej Zolnierkiewicz,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Grant Likely
In-Reply-To: <CAK8P3a3H=7qx+Rz9sScTVCSMKWGwQ_ROnyoyK73A5yUd+_jbTw@mail.gmail.com>
Hi Arnd,
On Tue, May 19, 2020 at 1:28 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, May 19, 2020 at 1:21 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
>
> > >
> > > > However, something under /chosen should work.
> > >
> > > Yet another sticky plaster...
> >
> > IMHO the old masking technique is the hacky solution covered by
> > plasters.
> >
> > DT describes the hardware. In general, where to put the kernel is a
> > software policy, and thus doesn't belong in DT, except perhaps under
> > /chosen. But that would open another can of worms, as people usually
> > have no business in specifying where the kernel should be located.
> > In the crashkernel case, there is a clear separation between memory to
> > be used by the crashkernel, and memory to be solely inspected by the
> > crashkernel.
> >
> > Devicetree Specification, Release v0.3, Section 3.4 "/memory node" says:
> >
> > "The client program may access memory not covered by any memory
> > reservations (see section 5.3)"
> >
> > (Section 5.3 "Memory Reservation Block" only talks about structures in
> > the FDT, not about DTS)
> >
> > Hence according to the above, the crashkernel is rightfully allowed to
> > do whatever it wants with all memory under the /memory node.
> > However, there is also
> > Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt.
> > This suggests the crashkernel should be passed a DTB that contains a
> > /reserved-memory node, describing which memory cannot be used freely.
> > Then the decompressor needs to take this into account when deciding
> > where the put the kernel.
> >
> > Yes, the above requires changing code. But at least it provides a
> > path forward, getting rid of the fragile old masking technique.
>
> There is an existing "linux,usable-memory-range" property documented
> in Documentation/devicetree/bindings/chosen.txt, which as I understand
> is exactly what you are looking for, except that it is currently only
> documented for arm64.
Thank you, that looks appropriate!
It seems this is not really used by the early startup code.
Is that because the early startup code always runs in-place, and the
kernel image is not even copied?
> Would extending this to arm work?
Let's see.... Th arm early boot code seems to be more complex than the
arm64 code ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Lukasz Stelmach @ 2020-05-19 12:20 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Geert Uytterhoeven, Dmitry Osipenko, Nicolas Pitre, Arnd Bergmann,
Eric Miao, Uwe Kleine-König, Masahiro Yamada, Ard Biesheuvel,
Marek Szyprowski, Chris Brandt, Linux ARM, Linux-Renesas,
Linux Kernel Mailing List, Bartlomiej Zolnierkiewicz,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Grant Likely
In-Reply-To: <20200519114329.GB1551@shell.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 4479 bytes --]
It was <2020-05-19 wto 12:43>, when Russell King - ARM Linux admin wrote:
> On Tue, May 19, 2020 at 01:21:09PM +0200, Geert Uytterhoeven wrote:
>> On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
>> <linux@armlinux.org.uk> wrote:
>> > On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
>> > > On Tue, May 19, 2020 at 10:54 AM Lukasz Stelmach <l.stelmach@samsung.com> wrote:
>> > > > It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
>> > > > > Currently, the start address of physical memory is obtained by masking
>> > > > > the program counter with a fixed mask of 0xf8000000. This mask value
>> > > > > was chosen as a balance between the requirements of different platforms.
>> > > > > However, this does require that the start address of physical memory is
>> > > > > a multiple of 128 MiB, precluding booting Linux on platforms where this
>> > > > > requirement is not fulfilled.
>> > > > >
>> > > > > Fix this limitation by obtaining the start address from the DTB instead,
>> > > > > if available (either explicitly passed, or appended to the kernel).
>> > > > > Fall back to the traditional method when needed.
>> > > > >
>> > > > > This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
>> > > > > on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
>> > > > > i.e. not at a multiple of 128 MiB.
>> > > > >
>> > > > > Suggested-by: Nicolas Pitre <nico@fluxnic.net>
>> > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> > > > > Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
>> > > > > Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
>> > > > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> > > > > Tested-by: Dmitry Osipenko <digetx@gmail.com>
>> > > > > ---
>> > > >
>> > > > [...]
>> > > >
>> > > > Apparently reading physical memory layout from DTB breaks crashdump
>> > > > kernels. A crashdump kernel is loaded into a region of memory, that is
>> > > > reserved in the original (i.e. to be crashed) kernel. The reserved
>> > > > region is large enough for the crashdump kernel to run completely inside
>> > > > it and don't modify anything outside it, just read and dump the remains
>> > > > of the crashed kernel. Using the information from DTB makes the
>> > > > decompressor place the kernel outside of the dedicated region.
>> > > >
>> > > > The log below shows that a zImage and DTB are loaded at 0x18eb8000 and
>> > > > 0x193f6000 (physical). The kernel is expected to run at 0x18008000, but
>> > > > it is decompressed to 0x00008000 (see r4 reported before jumping from
>> > > > within __enter_kernel). If I were to suggest something, there need to be
>> > > > one more bit of information passed in the DTB telling the decompressor
>> > > > to use the old masking technique to determain kernel address. It would
>> > > > be set in the DTB loaded along with the crashdump kernel.
>> > >
>> > > Shouldn't the DTB passed to the crashkernel describe which region of
>> > > memory is to be used instead?
>> >
>> > Definitely not. The crashkernel needs to know where the RAM in the
>> > machine is, so that it can create a coredump of the crashed kernel.
>>
>> So the DTB should describe both ;-)
>>
>> > > Describing "to use the old masking technique" sounds a bit hackish to me.
>> > > I guess it cannot just restrict the /memory node to the reserved region,
>> > > as the crashkernel needs to be able to dump the remains of the crashed
>> > > kernel, which lie outside this region.
>> >
>> > Correct.
>> >
>> > > However, something under /chosen should work.
>> >
>> > Yet another sticky plaster...
>>
>> IMHO the old masking technique is the hacky solution covered by
>> plasters.
>
> One line of code is not "covered by plasters". There are no plasters.
> It's a solution that works for 99.99% of people, unlike your approach
> that has had a stream of issues over the last four months, and has
> required many reworks of the code to fix each one. That in itself
> speaks volumes about the suitability of the approach.
As I have been working with kexec code (patches soon) I would like to
defend the DT approach a bit. It allows to avoid zImage relocation when
a decompressed kernel is larger than ~128MiB. In such case zImage isn't
small either and moving it around takes some time.
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: at91: sama5d2_xplained: Add aliases for the dedicated I2C IPs
From: Alexandre Belloni @ 2020-05-19 12:27 UTC (permalink / raw)
To: Tudor.Ambarus
Cc: Nicolas.Ferre, Ludovic.Desroches, robh+dt, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20200518114802.253660-1-tudor.ambarus@microchip.com>
On 18/05/2020 11:49:21+0000, Tudor.Ambarus@microchip.com wrote:
> From: Tudor Ambarus <tudor.ambarus@microchip.com>
>
> The sama5d2 SoC has two dedicated I2C IPs that are enabled on
> sama5d2_xplained. Add alias for the i2c devices to not rely on
> probe order for the i2c device numbering.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> ---
> arch/arm/boot/dts/at91-sama5d2_xplained.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
Applied, thanks.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Russell King - ARM Linux admin @ 2020-05-19 12:27 UTC (permalink / raw)
To: Lukasz Stelmach
Cc: Geert Uytterhoeven, Dmitry Osipenko, Nicolas Pitre, Arnd Bergmann,
Eric Miao, Uwe Kleine-König, Masahiro Yamada, Ard Biesheuvel,
Marek Szyprowski, Chris Brandt, Linux ARM, Linux-Renesas,
Linux Kernel Mailing List, Bartlomiej Zolnierkiewicz,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Grant Likely
In-Reply-To: <dleftj5zcs5d6e.fsf%l.stelmach@samsung.com>
On Tue, May 19, 2020 at 02:20:25PM +0200, Lukasz Stelmach wrote:
> It was <2020-05-19 wto 12:43>, when Russell King - ARM Linux admin wrote:
> > On Tue, May 19, 2020 at 01:21:09PM +0200, Geert Uytterhoeven wrote:
> >> On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
> >> <linux@armlinux.org.uk> wrote:
> >> > On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
> >> > > On Tue, May 19, 2020 at 10:54 AM Lukasz Stelmach <l.stelmach@samsung.com> wrote:
> >> > > > It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
> >> > > > > Currently, the start address of physical memory is obtained by masking
> >> > > > > the program counter with a fixed mask of 0xf8000000. This mask value
> >> > > > > was chosen as a balance between the requirements of different platforms.
> >> > > > > However, this does require that the start address of physical memory is
> >> > > > > a multiple of 128 MiB, precluding booting Linux on platforms where this
> >> > > > > requirement is not fulfilled.
> >> > > > >
> >> > > > > Fix this limitation by obtaining the start address from the DTB instead,
> >> > > > > if available (either explicitly passed, or appended to the kernel).
> >> > > > > Fall back to the traditional method when needed.
> >> > > > >
> >> > > > > This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> >> > > > > on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> >> > > > > i.e. not at a multiple of 128 MiB.
> >> > > > >
> >> > > > > Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> >> > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> > > > > Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> >> > > > > Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> >> > > > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >> > > > > Tested-by: Dmitry Osipenko <digetx@gmail.com>
> >> > > > > ---
> >> > > >
> >> > > > [...]
> >> > > >
> >> > > > Apparently reading physical memory layout from DTB breaks crashdump
> >> > > > kernels. A crashdump kernel is loaded into a region of memory, that is
> >> > > > reserved in the original (i.e. to be crashed) kernel. The reserved
> >> > > > region is large enough for the crashdump kernel to run completely inside
> >> > > > it and don't modify anything outside it, just read and dump the remains
> >> > > > of the crashed kernel. Using the information from DTB makes the
> >> > > > decompressor place the kernel outside of the dedicated region.
> >> > > >
> >> > > > The log below shows that a zImage and DTB are loaded at 0x18eb8000 and
> >> > > > 0x193f6000 (physical). The kernel is expected to run at 0x18008000, but
> >> > > > it is decompressed to 0x00008000 (see r4 reported before jumping from
> >> > > > within __enter_kernel). If I were to suggest something, there need to be
> >> > > > one more bit of information passed in the DTB telling the decompressor
> >> > > > to use the old masking technique to determain kernel address. It would
> >> > > > be set in the DTB loaded along with the crashdump kernel.
> >> > >
> >> > > Shouldn't the DTB passed to the crashkernel describe which region of
> >> > > memory is to be used instead?
> >> >
> >> > Definitely not. The crashkernel needs to know where the RAM in the
> >> > machine is, so that it can create a coredump of the crashed kernel.
> >>
> >> So the DTB should describe both ;-)
> >>
> >> > > Describing "to use the old masking technique" sounds a bit hackish to me.
> >> > > I guess it cannot just restrict the /memory node to the reserved region,
> >> > > as the crashkernel needs to be able to dump the remains of the crashed
> >> > > kernel, which lie outside this region.
> >> >
> >> > Correct.
> >> >
> >> > > However, something under /chosen should work.
> >> >
> >> > Yet another sticky plaster...
> >>
> >> IMHO the old masking technique is the hacky solution covered by
> >> plasters.
> >
> > One line of code is not "covered by plasters". There are no plasters.
> > It's a solution that works for 99.99% of people, unlike your approach
> > that has had a stream of issues over the last four months, and has
> > required many reworks of the code to fix each one. That in itself
> > speaks volumes about the suitability of the approach.
>
> As I have been working with kexec code (patches soon) I would like to
> defend the DT approach a bit. It allows to avoid zImage relocation when
> a decompressed kernel is larger than ~128MiB. In such case zImage isn't
> small either and moving it around takes some time.
... which is something that has been supported for a very long time,
before the days of DT.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: memory: Add Baikal-T1 L2-cache Control Block binding
From: Serge Semin @ 2020-05-19 12:27 UTC (permalink / raw)
To: Thomas Bogendoerfer, Greg Kroah-Hartman, Arnd Bergmann,
Rob Herring
Cc: Serge Semin, Alexey Malahov, Paul Burton, Ralf Baechle,
Olof Johansson, Boris Brezillon, Paul Cercueil, Thomas Gleixner,
Masahiro Yamada, linux-mips, soc, devicetree, linux-kernel
In-Reply-To: <20200507230705.6468-2-Sergey.Semin@baikalelectronics.ru>
Rob,
Could you take a look at this patch?
Since you've accepted and merged in the patch:
https://lore.kernel.org/linux-devicetree/20200506174238.15385-4-Sergey.Semin@baikalelectronics.ru/
It's safe to perform the dt_binding_check of this one.
-Sergey
On Fri, May 08, 2020 at 02:07:03AM +0300, Serge Semin wrote:
> There is a single register provided by the SoC system controller,
> which can be used to tune the L2-cache RAM up. It only provides a way
> to change the L2-RAM access latencies. So aside from "be,bt1-l2-ctl"
> compatible string the device node can be optionally equipped with the
> properties of Tag/Data/WS latencies.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Paul Burton <paulburton@kernel.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Boris Brezillon <bbrezillon@kernel.org>
> Cc: Paul Cercueil <paul@crapouillou.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: linux-mips@vger.kernel.org
> Cc: soc@kernel.org
>
> ---
>
> Changelog v2:
> - Move driver to the memory subsystem.
> - Use dual GPL/BSD license.
> - Use single lined copyright header.
> - Move "allOf" restrictions to the root level of the properties.
> - Discard syscon compatible string and reg property.
> - The DT node is supposed to be a child of the Baikal-T1 system controller
> node.
> ---
> .../memory-controllers/baikal,bt1-l2-ctl.yaml | 59 +++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/memory-controllers/baikal,bt1-l2-ctl.yaml
>
> diff --git a/Documentation/devicetree/bindings/memory-controllers/baikal,bt1-l2-ctl.yaml b/Documentation/devicetree/bindings/memory-controllers/baikal,bt1-l2-ctl.yaml
> new file mode 100644
> index 000000000000..263f0cdab4e6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/baikal,bt1-l2-ctl.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/memory-controllers/baikal,bt1-l2-ctl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Baikal-T1 L2-cache Control Block
> +
> +maintainers:
> + - Serge Semin <fancer.lancer@gmail.com>
> +
> +description: |
> + By means of the System Controller Baikal-T1 SoC exposes a few settings to
> + tune the MIPS P5600 CM2 L2 cache performance up. In particular it's possible
> + to change the Tag, Data and Way-select RAM access latencies. Baikal-T1
> + L2-cache controller block is responsible for the tuning. Its DT node is
> + supposed to be a child of the system controller.
> +
> +properties:
> + compatible:
> + const: baikal,bt1-l2-ctl
> +
> + baikal,l2-ws-latency:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Cycles of latency for Way-select RAM accesses
> + default: 0
> + minimum: 0
> + maximum: 3
> +
> + baikal,l2-tag-latency:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Cycles of latency for Tag RAM accesses
> + default: 0
> + minimum: 0
> + maximum: 3
> +
> + baikal,l2-data-latency:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Cycles of latency for Data RAM accesses
> + default: 1
> + minimum: 0
> + maximum: 3
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> +
> +examples:
> + - |
> + l2_ctl {
> + compatible = "baikal,bt1-l2-ctl";
> +
> + baikal,l2-ws-latency = <0>;
> + baikal,l2-tag-latency = <0>;
> + baikal,l2-data-latency = <1>;
> + };
> +...
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sdm845-mtp: enable IPA
From: Alex Elder @ 2020-05-19 12:29 UTC (permalink / raw)
To: Bjorn Andersson
Cc: agross, evgreen, subashab, cpratapa, robh+dt, linux-arm-msm,
devicetree, open list
In-Reply-To: <20200518232402.GM2165@builder.lan>
On 5/18/20 6:24 PM, Bjorn Andersson wrote:
> modem-init tells the IPA driver that the modem will load the ipa_fws
> firmware, but the MTP is assumed to run "LA" firmware where it's the
> Linux-side's job to do this.
I didn't see this message until just now, but I remembered that
last night. I just build my version 2 and will send it shortly.
Sorry about that.
-Alex
^ permalink raw reply
* [PATCH v2] arm64: dts: qcom: sdm845-mtp: enable IPA
From: Alex Elder @ 2020-05-19 12:32 UTC (permalink / raw)
To: bjorn.andersson, agross
Cc: evgreen, subashab, cpratapa, robh+dt, linux-arm-msm, devicetree,
linux-kernel
Enable IPA on the SDM845 MTP.
Signed-off-by: Alex Elder <elder@linaro.org>
---
v2: This device uses the AP--not the modem--for early initialization.
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index 1372fe8601f5..91ede9296aff 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -448,6 +448,11 @@
clock-frequency = <400000>;
};
+&ipa {
+ status = "okay";
+ memory-region = <&ipa_fw_mem>;
+};
+
&mdss {
status = "okay";
};
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 1/4] dt-bindings: clk: Add Baikal-T1 CCU PLLs binding
From: Serge Semin @ 2020-05-19 12:33 UTC (permalink / raw)
To: Rob Herring
Cc: Serge Semin, Thomas Bogendoerfer, Stephen Boyd, Michael Turquette,
Alexey Malahov, Paul Burton, Ralf Baechle, Arnd Bergmann,
linux-mips, linux-clk, devicetree, linux-kernel
In-Reply-To: <20200514191318.GA10192@bogus>
On Thu, May 14, 2020 at 02:13:18PM -0500, Rob Herring wrote:
> On Thu, May 07, 2020 at 01:22:57AM +0300, Serge Semin wrote:
> > Baikal-T1 Clocks Control Unit is responsible for transformation of a
> > signal coming from an external oscillator into clocks of various
> > frequencies to propagate them then to the corresponding clocks
> > consumers (either individual IP-blocks or clock domains). In order
> > to create a set of high-frequency clocks the external signal is
> > firstly handled by the embedded into CCU PLLs. So the corresponding
> > dts-node is just a normal clock-provider node with standard set of
> > properties. Note as being part of the Baikal-T1 System Controller its
> > DT node is supposed to be a child the system controller node.
> >
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > Cc: Paul Burton <paulburton@kernel.org>
> > Cc: Ralf Baechle <ralf@linux-mips.org>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: linux-mips@vger.kernel.org
> >
> > ---
> >
[nip]
> > +examples:
> > + # Clock Control Unit PLL node:
> > + - |
> > + clock-controller-pll {
> > + compatible = "baikal,bt1-ccu-pll";
> > + #clock-cells = <1>;
> > +
> > + clocks = <&clk25m>;
> > + clock-names = "ref_clk";
>
> If there's a register range within the system controller for the pll,
> then add 'reg' even if Linux doesn't use it.
Rob, are you saying that the reg property should be mandatory or optional?
I've got a similar issue in several other patches you've already took a look.
In order to fix it there too could you please clarify this to me?
-Sergey
^ permalink raw reply
* [PATCH v3 0/4] iio: magnetometer: ak8975: Add gpio reset support
From: Jonathan Albrieux @ 2020-05-19 12:43 UTC (permalink / raw)
To: linux-kernel
Cc: ~postmarketos/upstreaming, Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner
v3:
- fix patch messages style
- align reset gpio comment to kernel doc reccomendation
- introduce changelog.
v2:
- rewording of reset gpio comment and patch messages to better clarify
reset gpio behaviour.
https://lore.kernel.org/linux-iio/20200518133645.19127-1-jonathan.albrieux@gmail.com/
v1:
- initial patch submission.
https://lore.kernel.org/linux-iio/20200519065749.4624-1-jonathan.albrieux@gmail.com/
Convert documentation from txt format to yaml. Add documentation about
reset-gpio.
Deassert reset on ak8975_power_on(), assert reset on ak8975_power_off().
Without reset's deassertion during ak8975_power_on(), driver's probe fails
on ak8975_who_i_am() while checking for device identity for AK09911 chip.
AK09911 has an active low reset gpio to handle register's reset.
AK09911 datasheed says that, if not used, reset pin should be connected
to VID. This patch emulates this situation.
Jonathan Albrieux (4):
dt-bindings: iio: magnetometer: ak8975: convert txt format to yaml
dt-bindings: iio: magnetometer: ak8975: add gpio reset support
iio: magnetometer: ak8975: Fix typo, uniform measurement unit style
iio: magnetometer: ak8975: Add gpio reset support
.../bindings/iio/magnetometer/ak8975.txt | 30 --------
.../bindings/iio/magnetometer/ak8975.yaml | 70 +++++++++++++++++++
drivers/iio/magnetometer/ak8975.c | 22 +++++-
3 files changed, 90 insertions(+), 32 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
--
2.17.1
^ permalink raw reply
* [PATCH v3 1/4] dt-bindings: iio: magnetometer: ak8975: convert txt format to yaml
From: Jonathan Albrieux @ 2020-05-19 12:43 UTC (permalink / raw)
To: linux-kernel
Cc: ~postmarketos/upstreaming, Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron, Rob Herring
In-Reply-To: <20200519124402.26076-1-jonathan.albrieux@gmail.com>
Converts documentation from txt format to yaml.
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
---
.../bindings/iio/magnetometer/ak8975.txt | 30 ---------
.../bindings/iio/magnetometer/ak8975.yaml | 66 +++++++++++++++++++
2 files changed, 66 insertions(+), 30 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
deleted file mode 100644
index aa67ceb0d4e0..000000000000
--- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* AsahiKASEI AK8975 magnetometer sensor
-
-Required properties:
-
- - compatible : should be "asahi-kasei,ak8975"
- - reg : the I2C address of the magnetometer
-
-Optional properties:
-
- - gpios : should be device tree identifier of the magnetometer DRDY pin
- - vdd-supply: an optional regulator that needs to be on to provide VDD
- - mount-matrix: an optional 3x3 mounting rotation matrix
-
-Example:
-
-ak8975@c {
- compatible = "asahi-kasei,ak8975";
- reg = <0x0c>;
- gpios = <&gpj0 7 0>;
- vdd-supply = <&ldo_3v3_gnss>;
- mount-matrix = "-0.984807753012208", /* x0 */
- "0", /* y0 */
- "-0.173648177666930", /* z0 */
- "0", /* x1 */
- "-1", /* y1 */
- "0", /* z1 */
- "-0.173648177666930", /* x2 */
- "0", /* y2 */
- "0.984807753012208"; /* z2 */
-};
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
new file mode 100644
index 000000000000..86e3efa693a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/ak8975.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AsahiKASEI AK8975 magnetometer sensor
+
+maintainers:
+ - can't find a mantainer, author is Laxman Dewangan <ldewangan@nvidia.com>
+
+properties:
+ compatible:
+ enum:
+ - "asahi-kasei,ak8975"
+ - "ak8975"
+ - "asahi-kasei,ak8963"
+ - "ak8963"
+ - "asahi-kasei,ak09911"
+ - "ak09911"
+ - "asahi-kasei,ak09912"
+ - "ak09912"
+
+ reg:
+ maxItems: 1
+ description: the I2C address of the magnetometer
+
+ gpios:
+ description: should be device tree identifier of the magnetometer DRDY pin
+
+ vdd-supply:
+ maxItems: 1
+ description: |
+ an optional regulator that needs to be on to provide VDD power to
+ the sensor.
+
+ mount-matrix:
+ description: an optional 3x3 mounting rotation matrix
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ i2c@78b7000 {
+ reg = <0x78b6000 0x600>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ak8975@c {
+ compatible = "asahi-kasei,ak8975";
+ reg = <0x0c>;
+ gpios = <&gpj0 7 0>;
+ vdd-supply = <&ldo_3v3_gnss>;
+ mount-matrix = "-0.984807753012208", /* x0 */
+ "0", /* y0 */
+ "-0.173648177666930", /* z0 */
+ "0", /* x1 */
+ "-1", /* y1 */
+ "0", /* z1 */
+ "-0.173648177666930", /* x2 */
+ "0", /* y2 */
+ "0.984807753012208"; /* z2 */
+ };
+ };
--
2.17.1
^ permalink raw reply related
* [PATCH v3 2/4] dt-bindings: iio: magnetometer: ak8975: add gpio reset support
From: Jonathan Albrieux @ 2020-05-19 12:43 UTC (permalink / raw)
To: linux-kernel
Cc: ~postmarketos/upstreaming, Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron, Rob Herring
In-Reply-To: <20200519124402.26076-1-jonathan.albrieux@gmail.com>
Add reset-gpio support.
Without reset's deassertion during ak8975_power_on(), driver's probe fails
on ak8975_who_i_am() while checking for device identity for AK09911 chip.
AK09911 has an active low reset gpio to handle register's reset.
AK09911 datasheed says that, if not used, reset pin should be connected
to VID. This patch emulates this situation.
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
---
.../devicetree/bindings/iio/magnetometer/ak8975.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
index 86e3efa693a8..a82c0ff5d098 100644
--- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
+++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
@@ -37,6 +37,9 @@ properties:
mount-matrix:
description: an optional 3x3 mounting rotation matrix
+ reset-gpio:
+ description: an optional pin needed for AK09911 to set the reset state
+
required:
- compatible
- reg
@@ -53,6 +56,7 @@ examples:
reg = <0x0c>;
gpios = <&gpj0 7 0>;
vdd-supply = <&ldo_3v3_gnss>;
+ reset-gpio = <&msmgpio 111 1>;
mount-matrix = "-0.984807753012208", /* x0 */
"0", /* y0 */
"-0.173648177666930", /* z0 */
--
2.17.1
^ permalink raw reply related
* [PATCH v3 4/4] iio: magnetometer: ak8975: Add gpio reset support
From: Jonathan Albrieux @ 2020-05-19 12:43 UTC (permalink / raw)
To: linux-kernel
Cc: ~postmarketos/upstreaming, Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron, Allison Randal
In-Reply-To: <20200519124402.26076-1-jonathan.albrieux@gmail.com>
According to AK09911 datasheet, if reset gpio is provided then
deassert reset on ak8975_power_on() and assert reset on ak8975_power_off().
Without reset's deassertion during ak8975_power_on(), driver's probe fails
on ak8975_who_i_am while() checking for device identity for AK09911 chip.
AK09911 has an active low reset gpio to handle register's reset.
AK09911 datasheed says that, if not used, reset pin should be connected
to VID. This patch emulates this situation.
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
---
drivers/iio/magnetometer/ak8975.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
index fd368455cd7b..a23422aad97d 100644
--- a/drivers/iio/magnetometer/ak8975.c
+++ b/drivers/iio/magnetometer/ak8975.c
@@ -358,6 +358,7 @@ struct ak8975_data {
u8 asa[3];
long raw_to_gauss[3];
struct gpio_desc *eoc_gpiod;
+ struct gpio_desc *reset_gpiod;
int eoc_irq;
wait_queue_head_t data_ready_queue;
unsigned long flags;
@@ -384,6 +385,9 @@ static int ak8975_power_on(const struct ak8975_data *data)
"Failed to enable specified Vid supply\n");
return ret;
}
+
+ gpiod_set_value_cansleep(data->reset_gpiod, 0);
+
/*
* According to the datasheet the power supply rise time is 200us
* and the minimum wait time before mode setting is 100us, in
@@ -396,6 +400,8 @@ static int ak8975_power_on(const struct ak8975_data *data)
/* Disable attached power regulator if any. */
static void ak8975_power_off(const struct ak8975_data *data)
{
+ gpiod_set_value_cansleep(data->reset_gpiod, 1);
+
regulator_disable(data->vid);
regulator_disable(data->vdd);
}
@@ -839,6 +845,7 @@ static int ak8975_probe(struct i2c_client *client,
struct ak8975_data *data;
struct iio_dev *indio_dev;
struct gpio_desc *eoc_gpiod;
+ struct gpio_desc *reset_gpiod;
const void *match;
unsigned int i;
int err;
@@ -856,6 +863,16 @@ static int ak8975_probe(struct i2c_client *client,
if (eoc_gpiod)
gpiod_set_consumer_name(eoc_gpiod, "ak_8975");
+ /*
+ * According to AK09911 datasheet, if reset GPIO is provided then
+ * deassert reset on ak8975_power_on() and assert reset on
+ * ak8975_power_off().
+ */
+ reset_gpiod = devm_gpiod_get_optional(&client->dev,
+ "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(reset_gpiod))
+ return PTR_ERR(reset_gpiod);
+
/* Register with IIO */
indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
if (indio_dev == NULL)
@@ -866,6 +883,7 @@ static int ak8975_probe(struct i2c_client *client,
data->client = client;
data->eoc_gpiod = eoc_gpiod;
+ data->reset_gpiod = reset_gpiod;
data->eoc_irq = 0;
err = iio_read_mount_matrix(&client->dev, "mount-matrix", &data->orientation);
--
2.17.1
^ permalink raw reply related
* [PATCH v3 3/4] iio: magnetometer: ak8975: Fix typo, uniform measurement unit style
From: Jonathan Albrieux @ 2020-05-19 12:43 UTC (permalink / raw)
To: linux-kernel
Cc: ~postmarketos/upstreaming, Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron
In-Reply-To: <20200519124402.26076-1-jonathan.albrieux@gmail.com>
Minor comment style edits.
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
---
drivers/iio/magnetometer/ak8975.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
index 3c881541ae72..fd368455cd7b 100644
--- a/drivers/iio/magnetometer/ak8975.c
+++ b/drivers/iio/magnetometer/ak8975.c
@@ -385,9 +385,9 @@ static int ak8975_power_on(const struct ak8975_data *data)
return ret;
}
/*
- * According to the datasheet the power supply rise time i 200us
+ * According to the datasheet the power supply rise time is 200us
* and the minimum wait time before mode setting is 100us, in
- * total 300 us. Add some margin and say minimum 500us here.
+ * total 300us. Add some margin and say minimum 500us here.
*/
usleep_range(500, 1000);
return 0;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] ASoC: fsi: Add missing properties to DT bindings
From: Mark Brown @ 2020-05-19 12:47 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Kuninori Morimoto, Liam Girdwood, Rob Herring, linux-renesas-soc,
devicetree, alsa-devel
In-Reply-To: <20200519075858.27869-1-geert+renesas@glider.be>
[-- Attachment #1: Type: text/plain, Size: 332 bytes --]
On Tue, May 19, 2020 at 09:58:58AM +0200, Geert Uytterhoeven wrote:
> make dtbs_check:
>
> arch/arm/boot/dts/r8a7740-armadillo800eva.dt.yaml: sound@fe1f0000: '#sound-dai-cells', 'clocks', 'power-domains' do not match any of the regexes: 'pinctrl-[0-9]+'
This doesn't apply against current code, please check and resend.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Lukasz Stelmach @ 2020-05-19 12:49 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Geert Uytterhoeven, Dmitry Osipenko, Nicolas Pitre, Arnd Bergmann,
Eric Miao, Uwe Kleine-König, Masahiro Yamada, Ard Biesheuvel,
Marek Szyprowski, Chris Brandt, Linux ARM, Linux-Renesas,
Linux Kernel Mailing List, Bartlomiej Zolnierkiewicz,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Grant Likely
In-Reply-To: <20200519122706.GC1551@shell.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 4262 bytes --]
It was <2020-05-19 wto 13:27>, when Russell King - ARM Linux admin wrote:
> On Tue, May 19, 2020 at 02:20:25PM +0200, Lukasz Stelmach wrote:
>> It was <2020-05-19 wto 12:43>, when Russell King - ARM Linux admin wrote:
>>> On Tue, May 19, 2020 at 01:21:09PM +0200, Geert Uytterhoeven wrote:
>>>> On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
>>>> <linux@armlinux.org.uk> wrote:
>>>>> On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
>>>>>> On Tue, May 19, 2020 at 10:54 AM Lukasz Stelmach <l.stelmach@samsung.com> wrote:
>>>>>>> It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
>>>>>>>> Currently, the start address of physical memory is obtained by masking
>>>>>>>> the program counter with a fixed mask of 0xf8000000. This mask value
>>>>>>>> was chosen as a balance between the requirements of different platforms.
>>>>>>>> However, this does require that the start address of physical memory is
>>>>>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
>>>>>>>> requirement is not fulfilled.
>>>>>>>>
>>>>>>>> Fix this limitation by obtaining the start address from the DTB instead,
>>>>>>>> if available (either explicitly passed, or appended to the kernel).
>>>>>>>> Fall back to the traditional method when needed.
[...]
>>>>>>> Apparently reading physical memory layout from DTB breaks crashdump
>>>>>>> kernels. A crashdump kernel is loaded into a region of memory, that is
>>>>>>> reserved in the original (i.e. to be crashed) kernel. The reserved
>>>>>>> region is large enough for the crashdump kernel to run completely inside
>>>>>>> it and don't modify anything outside it, just read and dump the remains
>>>>>>> of the crashed kernel. Using the information from DTB makes the
>>>>>>> decompressor place the kernel outside of the dedicated region.
>>>>>>>
>>>>>>> The log below shows that a zImage and DTB are loaded at 0x18eb8000 and
>>>>>>> 0x193f6000 (physical). The kernel is expected to run at 0x18008000, but
>>>>>>> it is decompressed to 0x00008000 (see r4 reported before jumping from
>>>>>>> within __enter_kernel). If I were to suggest something, there need to be
>>>>>>> one more bit of information passed in the DTB telling the decompressor
>>>>>>> to use the old masking technique to determain kernel address. It would
>>>>>>> be set in the DTB loaded along with the crashdump kernel.
[...]
>>>>>> Describing "to use the old masking technique" sounds a bit hackish to me.
>>>>>> I guess it cannot just restrict the /memory node to the reserved region,
>>>>>> as the crashkernel needs to be able to dump the remains of the crashed
>>>>>> kernel, which lie outside this region.
>>>>>
>>>>> Correct.
>>>>>
>>>>>> However, something under /chosen should work.
>>>>>
>>>>> Yet another sticky plaster...
>>>>
>>>> IMHO the old masking technique is the hacky solution covered by
>>>> plasters.
>>>
>>> One line of code is not "covered by plasters". There are no plasters.
>>> It's a solution that works for 99.99% of people, unlike your approach
>>> that has had a stream of issues over the last four months, and has
>>> required many reworks of the code to fix each one. That in itself
>>> speaks volumes about the suitability of the approach.
>>
>> As I have been working with kexec code (patches soon) I would like to
>> defend the DT approach a bit. It allows to avoid zImage relocation when
>> a decompressed kernel is larger than ~128MiB. In such case zImage isn't
>> small either and moving it around takes some time.
>
> ... which is something that has been supported for a very long time,
> before the days of DT.
How? If a decompressed kernel requires >128M and a bootloader would like
to put a zImage high enough to *avoid* copying it once again, then the
decompressor can't see any memory below the 128M window it starts in and
can't decompress the kernel there. If we do not care about copying
zImage, then, indeed, everything works fine as it is today. You are
most probably right 99% doesn't require 128M kernel, but the case is
IMHO obvious enough, that it should be adressed somehow.
Kind regards,
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ 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