* Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support
From: Matthias Brugger @ 2019-09-13 7:15 UTC (permalink / raw)
To: Stefan Wahren, Matthias Brugger, catalin.marinas, marc.zyngier,
robh+dt, linux-mm, linux-arm-kernel, linux-riscv, hch,
Nicolas Saenz Julienne
Cc: f.fainelli, robin.murphy, linux-kernel, linux-rpi-kernel, phill,
will, m.szyprowski
In-Reply-To: <2c3e1ef3-0dba-9f79-52e2-314b6b500e14@gmx.net>
On 12/09/2019 21:32, Stefan Wahren wrote:
>
> Am 12.09.19 um 19:18 schrieb Matthias Brugger:
>>
>> On 10/09/2019 11:27, Matthias Brugger wrote:
>>>
>>> On 09/09/2019 21:33, Stefan Wahren wrote:
>>>> Hi Nicolas,
>>>>
>>>> Am 09.09.19 um 11:58 schrieb Nicolas Saenz Julienne:
>>>>> 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:
>>>>> v4: https://lkml.org/lkml/2019/9/6/352
>>>>> v3: https://lkml.org/lkml/2019/9/2/589
>>>>> 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.
>>>>>
>>>> i like to test this series on Raspberry Pi 4 and i have some questions
>>>> to get arm64 running:
>>>>
>>>> Do you use U-Boot? Which tree?
>>> If you want to use U-Boot, try v2019.10-rc4, it should have everything you need
>>> to boot your kernel.
>>>
>> Ok, here is a thing. In the linux kernel we now use bcm2711 as SoC name, but the
>> RPi4 devicetree provided by the FW uses mostly bcm2838.
>
> Do you mean the DTB provided at runtime?
>
Yes.
> You mean the merged U-Boot changes, doesn't work with my Raspberry Pi
> series?
>
Unfortunately that is exactly the state right now.
>> U-Boot in its default
>> config uses the devicetree provided by the FW, mostly because this way you don't
>> have to do anything to find out how many RAM you really have. Secondly because
>> this will allow us, in the near future, to have one U-boot binary for both RPi3
>> and RPi4 (and as a side effect one binary for RPi1 and RPi2).
>>
>> Anyway, I found at least, that the following compatibles need to be added:
>>
>> "brcm,bcm2838-cprman"
>> "brcm,bcm2838-gpio"
>>
>> Without at least the cprman driver update, you won't see anything.
>>
>> "brcm,bcm2838-rng200" is also a candidate.
>>
>> I also suppose we will need to add "brcm,bcm2838" to
>> arch/arm/mach-bcm/bcm2711.c, but I haven't verified this.
> How about changing this in the downstream kernel? Which is much easier.
>>
>> Regards,
>> Matthias
>>
>>> Regards,
>>> Matthias
>>>
>>>> Are there any config.txt tweaks necessary?
>>>>
>>>>
>>> _______________________________________________
>>> 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
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 05/13] clk: bcm2835: Add BCM2711_CLOCK_EMMC2 support
From: Matthias Brugger @ 2019-09-13 7:13 UTC (permalink / raw)
To: Stefan Wahren, Eric Anholt, Florian Fainelli, Ray Jui,
Scott Branden, Wolfram Sang, Rob Herring, Mark Rutland,
Michael Turquette, Stephen Boyd
Cc: devicetree, bcm-kernel-feedback-list, linux-i2c, linux-clk,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <097c31de-4b11-92a8-af22-c34d6317359c@gmx.net>
On 13/09/2019 03:20, Stefan Wahren wrote:
> Am 12.09.19 um 20:52 schrieb Eric Anholt:
>> Matthias Brugger <matthias.bgg@gmail.com> writes:
>>
>>> On 13/08/2019 18:20, Stefan Wahren wrote:
>>>> The new BCM2711 supports an additional clock for the emmc2 block.
>>>> So add a new compatible and register this clock only for BCM2711.
>>>>
>>>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
>>>> Reviewed-by: Matthias Brugger <mbrugger@suse.com>
>>>> Acked-by: Eric Anholt <eric@anholt.net>
>>>> ---
>>>> drivers/clk/bcm/clk-bcm2835.c | 20 +++++++++++++++++++-
>>>> 1 file changed, 19 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
>>>> index 21cd952..fdf672a 100644
>>>> --- a/drivers/clk/bcm/clk-bcm2835.c
>>>> +++ b/drivers/clk/bcm/clk-bcm2835.c
>>>> @@ -114,6 +114,8 @@
>>>> #define CM_AVEODIV 0x1bc
>>>> #define CM_EMMCCTL 0x1c0
>>>> #define CM_EMMCDIV 0x1c4
>>>> +#define CM_EMMC2CTL 0x1d0
>>>> +#define CM_EMMC2DIV 0x1d4
>>>>
>>>> /* General bits for the CM_*CTL regs */
>>>> # define CM_ENABLE BIT(4)
>>>> @@ -290,7 +292,8 @@
>>>> #define BCM2835_MAX_FB_RATE 1750000000u
>>>>
>>>> #define SOC_BCM2835 BIT(0)
>>>> -#define SOC_ALL (SOC_BCM2835)
>>>> +#define SOC_BCM2711 BIT(1)
>>>> +#define SOC_ALL (SOC_BCM2835 | SOC_BCM2711)
>>>>
>>>> /*
>>>> * Names of clocks used within the driver that need to be replaced
>>>> @@ -2003,6 +2006,16 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
>>>> .frac_bits = 8,
>>>> .tcnt_mux = 39),
>>>>
>>>> + /* EMMC2 clock (only available for BCM2711) */
>>>> + [BCM2711_CLOCK_EMMC2] = REGISTER_PER_CLK(
>>>> + SOC_BCM2711,
>>>> + .name = "emmc2",
>>>> + .ctl_reg = CM_EMMC2CTL,
>>>> + .div_reg = CM_EMMC2DIV,
>>>> + .int_bits = 4,
>>>> + .frac_bits = 8,
>>>> + .tcnt_mux = 42),
>>>> +
>>>> /* General purpose (GPIO) clocks */
>>>> [BCM2835_CLOCK_GP0] = REGISTER_PER_CLK(
>>>> SOC_ALL,
>>>> @@ -2238,8 +2251,13 @@ static const struct cprman_plat_data cprman_bcm2835_plat_data = {
>>>> .soc = SOC_BCM2835,
>>>> };
>>>>
>>>> +static const struct cprman_plat_data cprman_bcm2711_plat_data = {
>>>> + .soc = SOC_BCM2711,
>>>> +};
>>>> +
>>>> static const struct of_device_id bcm2835_clk_of_match[] = {
>>>> { .compatible = "brcm,bcm2835-cprman", .data = &cprman_bcm2835_plat_data },
>>>> + { .compatible = "brcm,bcm2711-cprman", .data = &cprman_bcm2711_plat_data },
>>> Because the RPi4 FW uses bcm2838-cprman as compatible, we will need to add this
>>> here as well.
>> Upstream has not committed to backwards compat with Pi's firmware. That
>> makes the ABI requirement we get held to for upstream's DT absurd, but
>> that's the state of things.
>
> We also learned from past, that's not possible to keep things downstream
> compatible. As soon as a binding is not accepted, this wont work
> anymore. A lot of the downstream stuff is hacky.
>
> For example yesterday, i learned that the thermal node is broken
> (register is part of ring oscillator block). So do we really want to be
> compatible with a hack? I would say: No
>
There is always the possibility to fix this in the FW, which in many cases will
be trivial.
_______________________________________________
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] mm/pgtable/debug: Fix test validating architecture page table helpers
From: Christophe Leroy @ 2019-09-13 7:11 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Heiko Carstens, Michal Hocko, Dave Hansen, Paul Mackerras,
sparclinux, Thomas Gleixner, linux-s390, Jason Gunthorpe, x86,
Russell King - ARM Linux, Matthew Wilcox, Steven Price,
Tetsuo Handa, Gerald Schaefer, linux-snps-arc, Kees Cook,
Mark Brown, Kirill A . Shutemov, Dan Williams, Vlastimil Babka,
linux-arm-kernel, Sri Krishna chowdary, Masahiro Yamada,
Greg Kroah-Hartman, Ard Biesheuvel, linux-mips, Ralf Baechle,
linux-kernel, Paul Burton, Mike Rapoport, Vineet Gupta,
Martin Schwidefsky, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <e2b42446-7f91-83f1-ac12-08dff75c4d35@c-s.fr>
Le 13/09/2019 à 09:03, Christophe Leroy a écrit :
>
>
> Le 13/09/2019 à 08:58, Anshuman Khandual a écrit :
>> On 09/13/2019 11:53 AM, Christophe Leroy wrote:
>>> Fix build failure on powerpc.
>>>
>>> Fix preemption imbalance.
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>> ---
>>> mm/arch_pgtable_test.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
>>> index 8b4a92756ad8..f2b3c9ec35fa 100644
>>> --- a/mm/arch_pgtable_test.c
>>> +++ b/mm/arch_pgtable_test.c
>>> @@ -24,6 +24,7 @@
>>> #include <linux/swap.h>
>>> #include <linux/swapops.h>
>>> #include <linux/sched/mm.h>
>>> +#include <linux/highmem.h>
>>
>> This is okay.
>>
>>> #include <asm/pgalloc.h>
>>> #include <asm/pgtable.h>
>>> @@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void)
>>> p4d_clear_tests(p4dp);
>>> pgd_clear_tests(mm, pgdp);
>>> + pte_unmap(ptep);
>>> +
>>
>> Now the preemption imbalance via pte_alloc_map() path i.e
>>
>> pte_alloc_map() -> pte_offset_map() -> kmap_atomic()
>>
>> Is not this very much powerpc 32 specific or this will be applicable
>> for all platform which uses kmap_XXX() to map high memory ?
>>
>
> See
> https://elixir.bootlin.com/linux/v5.3-rc8/source/include/linux/highmem.h#L91
>
>
> I think it applies at least to all arches using the generic implementation.
>
> Applies also to arm:
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/mm/highmem.c#L52
>
> Applies also to mips:
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/mips/mm/highmem.c#L47
>
> Same on sparc:
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/sparc/mm/highmem.c#L52
>
>
> Same on x86:
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/mm/highmem_32.c#L34
>
>
> I have not checked others, but I guess it is like that for all.
>
Seems like I answered too quickly. All kmap_atomic() do
preempt_disable(), but not all pte_alloc_map() call kmap_atomic().
However, for instance ARM does:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/include/asm/pgtable.h#L200
And X86 as well:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/include/asm/pgtable_32.h#L51
Microblaze also:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/microblaze/include/asm/pgtable.h#L495
Christophe
_______________________________________________
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] mm/pgtable/debug: Fix test validating architecture page table helpers
From: Christophe Leroy @ 2019-09-13 7:03 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Heiko Carstens, Michal Hocko, Dave Hansen, Paul Mackerras,
sparclinux, Dan Williams, linux-s390, Jason Gunthorpe, x86,
Russell King - ARM Linux, Matthew Wilcox, Steven Price,
Tetsuo Handa, Vlastimil Babka, linux-snps-arc, Kees Cook,
Mark Brown, Kirill A . Shutemov, Thomas Gleixner, Gerald Schaefer,
linux-arm-kernel, Sri Krishna chowdary, Masahiro Yamada,
Greg Kroah-Hartman, Ard Biesheuvel, linux-mips, Ralf Baechle,
linux-kernel, Paul Burton, Mike Rapoport, Vineet Gupta,
Martin Schwidefsky, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <527dd29d-45fa-4d83-1899-6cbf268dd749@arm.com>
Le 13/09/2019 à 08:58, Anshuman Khandual a écrit :
> On 09/13/2019 11:53 AM, Christophe Leroy wrote:
>> Fix build failure on powerpc.
>>
>> Fix preemption imbalance.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>> ---
>> mm/arch_pgtable_test.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
>> index 8b4a92756ad8..f2b3c9ec35fa 100644
>> --- a/mm/arch_pgtable_test.c
>> +++ b/mm/arch_pgtable_test.c
>> @@ -24,6 +24,7 @@
>> #include <linux/swap.h>
>> #include <linux/swapops.h>
>> #include <linux/sched/mm.h>
>> +#include <linux/highmem.h>
>
> This is okay.
>
>> #include <asm/pgalloc.h>
>> #include <asm/pgtable.h>
>>
>> @@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void)
>> p4d_clear_tests(p4dp);
>> pgd_clear_tests(mm, pgdp);
>>
>> + pte_unmap(ptep);
>> +
>
> Now the preemption imbalance via pte_alloc_map() path i.e
>
> pte_alloc_map() -> pte_offset_map() -> kmap_atomic()
>
> Is not this very much powerpc 32 specific or this will be applicable
> for all platform which uses kmap_XXX() to map high memory ?
>
See
https://elixir.bootlin.com/linux/v5.3-rc8/source/include/linux/highmem.h#L91
I think it applies at least to all arches using the generic implementation.
Applies also to arm:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/mm/highmem.c#L52
Applies also to mips:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/mips/mm/highmem.c#L47
Same on sparc:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/sparc/mm/highmem.c#L52
Same on x86:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/mm/highmem_32.c#L34
I have not checked others, but I guess it is like that for all.
Christophe
_______________________________________________
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] mm/pgtable/debug: Fix test validating architecture page table helpers
From: Anshuman Khandual @ 2019-09-13 6:58 UTC (permalink / raw)
To: Christophe Leroy, linux-mm
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Heiko Carstens, Michal Hocko, Dave Hansen, Paul Mackerras,
sparclinux, Dan Williams, linux-s390, Jason Gunthorpe, x86,
Russell King - ARM Linux, Matthew Wilcox, Steven Price,
Tetsuo Handa, Vlastimil Babka, linux-snps-arc, Kees Cook,
Mark Brown, Kirill A . Shutemov, Thomas Gleixner, Gerald Schaefer,
linux-arm-kernel, Sri Krishna chowdary, Masahiro Yamada,
Greg Kroah-Hartman, Ard Biesheuvel, linux-mips, Ralf Baechle,
linux-kernel, Paul Burton, Mike Rapoport, Vineet Gupta,
Martin Schwidefsky, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1892b37d1fd9a4ed39e76c4b999b6556077201c0.1568355752.git.christophe.leroy@c-s.fr>
On 09/13/2019 11:53 AM, Christophe Leroy wrote:
> Fix build failure on powerpc.
>
> Fix preemption imbalance.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> mm/arch_pgtable_test.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
> index 8b4a92756ad8..f2b3c9ec35fa 100644
> --- a/mm/arch_pgtable_test.c
> +++ b/mm/arch_pgtable_test.c
> @@ -24,6 +24,7 @@
> #include <linux/swap.h>
> #include <linux/swapops.h>
> #include <linux/sched/mm.h>
> +#include <linux/highmem.h>
This is okay.
> #include <asm/pgalloc.h>
> #include <asm/pgtable.h>
>
> @@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void)
> p4d_clear_tests(p4dp);
> pgd_clear_tests(mm, pgdp);
>
> + pte_unmap(ptep);
> +
Now the preemption imbalance via pte_alloc_map() path i.e
pte_alloc_map() -> pte_offset_map() -> kmap_atomic()
Is not this very much powerpc 32 specific or this will be applicable
for all platform which uses kmap_XXX() to map high memory ?
_______________________________________________
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] drm: bridge/dw_hdmi: add audio sample channel status setting
From: Jonas Karlman @ 2019-09-13 6:37 UTC (permalink / raw)
To: Cheng-yi Chiang, Neil Armstrong
Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
Doug Anderson, kuninori.morimoto.gx@renesas.com, David Airlie,
dri-devel@lists.freedesktop.org, cain.cai@rock-chips.com,
Andrzej Hajda, Laurent Pinchart, Yakir Yang, sam@ravnborg.org,
Jerome Brunet, Xing Zheng, linux-rockchip@lists.infradead.org,
Dylan Reid, tzungbi@chromium.org, Jeffy Chen, 蔡枫,
linux-arm-kernel@lists.infradead.org, Jernej Škrabec,
linux-kernel, Daniel Vetter, Enric Balletbo i Serra,
kuankuan.y@gmail.com
In-Reply-To: <CAFv8NwJGa0HXsnv2MvJhknpr9PxUL3jH2HZLSLiSD5s_nHiQhQ@mail.gmail.com>
On 2019-09-11 19:02, Cheng-yi Chiang wrote:
> On Thu, Sep 12, 2019 at 12:54 AM Jernej Škrabec <jernej.skrabec@siol.net> wrote:
>> Dne sreda, 11. september 2019 ob 18:23:59 CEST je Neil Armstrong napisal(a):
>>> On 11/09/2019 10:26, Cheng-Yi Chiang wrote:
>>>> From: Yakir Yang <ykk@rock-chips.com>
>>>>
>>>> When transmitting IEC60985 linear PCM audio, we configure the
>>>> Aduio Sample Channel Status information in the IEC60958 frame.
>>>> The status bit is already available in iec.status of hdmi_codec_params.
>>>>
>>>> This fix the issue that audio does not come out on some monitors
>>>> (e.g. LG 22CV241)
>>>>
>>>> Note that these registers are only for interfaces:
>>>> I2S audio interface, General Purpose Audio (GPA), or AHB audio DMA
>>>> (AHBAUDDMA).
>>>> For S/PDIF interface this information comes from the stream.
>>>>
>>>> Currently this function dw_hdmi_set_channel_status is only called
>>>> from dw-hdmi-i2s-audio in I2S setup.
>>>>
>>>> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
>>>> Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
>>>> ---
>>>>
>>>> Change from v2 to v3:
>>>> 1. Reuse what is already set in iec.status in hw_param.
>>>> 2. Remove all useless definition of registers and values.
>>>> 3. Note that the original sampling frequency is not written to
>>>>
>>>> the channel status as we reuse create_iec958_consumer in pcm_iec958.c.
>>>> Without that it can still play audio fine.
>>>>
>>>> .../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 1 +
>>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 20 +++++++++++++++++++
>>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
>>>> include/drm/bridge/dw_hdmi.h | 1 +
>>>> 4 files changed, 24 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
>>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index
>>>> 34d8e837555f..20f4f92dd866 100644
>>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
>>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
>>>> @@ -102,6 +102,7 @@ static int dw_hdmi_i2s_hw_params(struct device *dev,
>>>> void *data,>
>>>> }
>>>>
>>>> dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
>>>>
>>>> + dw_hdmi_set_channel_status(hdmi, hparms->iec.status);
>>>>
>>>> dw_hdmi_set_channel_count(hdmi, hparms->channels);
>>>> dw_hdmi_set_channel_allocation(hdmi, hparms-
>>> cea.channel_allocation);
>>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
>>>> bd65d0479683..aa7efd4da1c8 100644
>>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>> @@ -582,6 +582,26 @@ static unsigned int hdmi_compute_n(unsigned int freq,
>>>> unsigned long pixel_clk)>
>>>> return n;
>>>>
>>>> }
>>>>
>>>> +/*
>>>> + * When transmitting IEC60958 linear PCM audio, these registers allow to
>>>> + * configure the channel status information of all the channel status
>>>> + * bits in the IEC60958 frame. For the moment this configuration is only
>>>> + * used when the I2S audio interface, General Purpose Audio (GPA),
>>>> + * or AHB audio DMA (AHBAUDDMA) interface is active
>>>> + * (for S/PDIF interface this information comes from the stream).
>>>> + */
>>>> +void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi,
>>>> + u8 *channel_status)
>>>> +{
>>>> + /*
>>>> + * Set channel status register for frequency and word length.
>>>> + * Use default values for other registers.
>>>> + */
>>>> + hdmi_writeb(hdmi, channel_status[3], HDMI_FC_AUDSCHNLS7);
>>>> + hdmi_writeb(hdmi, channel_status[4], HDMI_FC_AUDSCHNLS8);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(dw_hdmi_set_channel_status);
>>>> +
>>>>
>>>> static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
>>>>
>>>> unsigned long pixel_clk, unsigned int sample_rate)
>>>>
>>>> {
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
>>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h index
>>>> 6988f12d89d9..fcff5059db24 100644
>>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
>>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
>>>> @@ -158,6 +158,8 @@
>>>>
>>>> #define HDMI_FC_SPDDEVICEINF 0x1062
>>>> #define HDMI_FC_AUDSCONF 0x1063
>>>> #define HDMI_FC_AUDSSTAT 0x1064
>>>>
>>>> +#define HDMI_FC_AUDSCHNLS7 0x106e
>>>> +#define HDMI_FC_AUDSCHNLS8 0x106f
>>>>
>>>> #define HDMI_FC_DATACH0FILL 0x1070
>>>> #define HDMI_FC_DATACH1FILL 0x1071
>>>> #define HDMI_FC_DATACH2FILL 0x1072
>>>>
>>>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
>>>> index cf528c289857..4b3e863c4f8a 100644
>>>> --- a/include/drm/bridge/dw_hdmi.h
>>>> +++ b/include/drm/bridge/dw_hdmi.h
>>>> @@ -156,6 +156,7 @@ void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool
>>>> hpd, bool rx_sense);>
>>>> void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);
>>>> void dw_hdmi_set_channel_count(struct dw_hdmi *hdmi, unsigned int cnt);
>>>>
>>>> +void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi, u8
>>>> *channel_status);
>>>>
>>>> void dw_hdmi_set_channel_allocation(struct dw_hdmi *hdmi, unsigned int
>>>> ca);
>>>> void dw_hdmi_audio_enable(struct dw_hdmi *hdmi);
>>>> void dw_hdmi_audio_disable(struct dw_hdmi *hdmi);
>>> Looks fine for me:
>>> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
>>>
>>> Jonas ? Jernej ? Russell ?
>> Patch itself is fine, I'm just wondering if more information should be copied
>> from status array to registers. But I think they are not 1:1 mapping so some
>> more work would be needed. Anyway, patch is:
> Hi Jernej,
> Yes you are right. I was thinking about the same thing.
> But there are also some fields in the IEC60958 spec not mapped to the
> registers on dw-hdmi.
> So I ended up just writing the two registers in the original ykk's
> patch, and ignoring "original sampling frequency" like pcm_iec958.
> It turns out that audio plays fine on my LG monitor. So I suggest we
> can keep this patch as simple as it is, and add more register setting
> if we find issue.
> Thanks!
In my old multi-channel lpcm patch [1] I only wrote sample rate to FC_AUDSCHNLS7.
This is much cleaner and simpler, and setting FC_AUDSCHNLS8 does not cause any
problems when I tested on ASUS Tinker Board S (RK3288).
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
[1] https://github.com/Kwiboo/linux-rockchip/commit/4af9ebc567ccf0a0851fa260097021c27aebbb6b
Regards,
Jonas
>
>>
>> Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
>>
>> Best regards,
>> Jernej
>>
>>> If it's ok for you I'll apply it.
>>>
>>> Neil
>>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 0/2] mm/debug: Add tests for architecture exported page table helpers
From: Christophe Leroy @ 2019-09-13 6:32 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Heiko Carstens, Michal Hocko, Dave Hansen, Paul Mackerras,
sparclinux, Thomas Gleixner, linux-s390, Jason Gunthorpe,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Tetsuo Handa, Gerald Schaefer, linux-snps-arc,
Kees Cook, Masahiro Yamada, Mark Brown, Kirill A . Shutemov,
Dan Williams, Vlastimil Babka, linux-arm-kernel,
Sri Krishna chowdary, Ard Biesheuvel, Greg Kroah-Hartman,
linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Vineet Gupta, Martin Schwidefsky, Andrew Morton,
linuxppc-dev, David S. Miller, Mike Kravetz
In-Reply-To: <1b467d7a-0324-eb2c-876a-f04a99b9c596@arm.com>
Le 13/09/2019 à 08:24, Anshuman Khandual a écrit :
>
>
> On 09/12/2019 08:12 PM, Christophe Leroy wrote:
>> Hi,
>>
>> I didn't get patch 1 of this series, and it is not on linuxppc-dev patchwork either. Can you resend ?
>
> Its there on linux-mm patchwork and copied on linux-kernel@vger.kernel.org
> as well. The CC list for the first patch was different than the second one.
>
> https://patchwork.kernel.org/patch/11142317/
>
> Let me know if you can not find it either on MM or LKML list.
>
I finaly found it on linux-mm archive, thanks. See my other mails and my
fixing patch.
Christophe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers
From: Christophe Leroy @ 2019-09-13 6:30 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Heiko Carstens, Michal Hocko, Dave Hansen, Paul Mackerras,
sparclinux, Dan Williams, linux-s390, Jason Gunthorpe, x86,
Russell King - ARM Linux, Matthew Wilcox, Steven Price,
Tetsuo Handa, Vlastimil Babka, linux-snps-arc, Kees Cook,
Mark Brown, Kirill A . Shutemov, Thomas Gleixner, Gerald Schaefer,
linux-arm-kernel, Sri Krishna chowdary, Masahiro Yamada,
Greg Kroah-Hartman, Ard Biesheuvel, linux-mips, Ralf Baechle,
linux-kernel, Paul Burton, Mike Rapoport, Vineet Gupta,
Martin Schwidefsky, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <600a7c62-eea9-e26f-f7cf-f2103b7c228c@c-s.fr>
Le 12/09/2019 à 17:52, Christophe Leroy a écrit :
>
>
> Le 12/09/2019 à 17:36, Christophe Leroy a écrit :
>>
>>
>> Le 12/09/2019 à 17:00, Christophe Leroy a écrit :
>>>
>>>
>>> On 09/12/2019 06:02 AM, Anshuman Khandual wrote:
>>>> This adds a test module which will validate architecture page table
>>>> helpers
>>>> and accessors regarding compliance with generic MM semantics
>>>> expectations.
>>>> This will help various architectures in validating changes to the
>>>> existing
>>>> page table helpers or addition of new ones.
>>>>
>>>> Test page table and memory pages creating it's entries at various
>>>> level are
>>>> all allocated from system memory with required alignments. If memory
>>>> pages
>>>> with required size and alignment could not be allocated, then all
>>>> depending
>>>> individual tests are skipped.
>>>
>>> Build failure on powerpc book3s/32. This is because asm/highmem.h is
>>> missing. It can't be included from asm/book3s/32/pgtable.h because it
>>> creates circular dependency. So it has to be included from
>>> mm/arch_pgtable_test.c
>>
>> In fact it is <linux/highmem.h> that needs to be added, adding
>> <asm/highmem.h> directly provokes build failure at link time.
>>
>
> I get the following failure,
>
> [ 0.704685] ------------[ cut here ]------------
> [ 0.709239] initcall arch_pgtable_tests_init+0x0/0x228 returned with
> preemption imbalance
preempt_disable() is called from kmap_atomic() which is called from
pte_alloc_map() via pte_offset_map().
pte_unmap() has to be called to release the mapped pte and re-enable
preemtion.
Christophe
> [ 0.717539] WARNING: CPU: 0 PID: 1 at init/main.c:952
> do_one_initcall+0x18c/0x1d4
> [ 0.724922] CPU: 0 PID: 1 Comm: swapper Not tainted
> 5.3.0-rc7-s3k-dev-00880-g28fd02a838e5-dirty #2307
> [ 0.734070] NIP: c070e674 LR: c070e674 CTR: c001292c
> [ 0.739084] REGS: df4a5dd0 TRAP: 0700 Not tainted
> (5.3.0-rc7-s3k-dev-00880-g28fd02a838e5-dirty)
> [ 0.747975] MSR: 00029032 <EE,ME,IR,DR,RI> CR: 28000222 XER: 00000000
> [ 0.754628]
> [ 0.754628] GPR00: c070e674 df4a5e88 df4a0000 0000004e 0000000a
> 00000000 000000ca 38207265
> [ 0.754628] GPR08: 00001032 00000800 00000000 00000000 22000422
> 00000000 c0004a7c 00000000
> [ 0.754628] GPR16: 00000000 00000000 00000000 00000000 00000000
> c0810000 c0800000 c0816f30
> [ 0.754628] GPR24: c070dc20 c074702c 00000006 0000009c 00000000
> c0724494 c074e140 00000000
> [ 0.789339] NIP [c070e674] do_one_initcall+0x18c/0x1d4
> [ 0.794435] LR [c070e674] do_one_initcall+0x18c/0x1d4
> [ 0.799437] Call Trace:
> [ 0.801867] [df4a5e88] [c070e674] do_one_initcall+0x18c/0x1d4
> (unreliable)
> [ 0.808694] [df4a5ee8] [c070e8c0] kernel_init_freeable+0x204/0x2dc
> [ 0.814830] [df4a5f28] [c0004a94] kernel_init+0x18/0x110
> [ 0.820107] [df4a5f38] [c00122ac] ret_from_kernel_thread+0x14/0x1c
> [ 0.826220] Instruction dump:
> [ 0.829161] 4beb1069 7d2000a6 61298000 7d200124 89210008 2f890000
> 41be0048 3c60c06a
> [ 0.836849] 38a10008 7fa4eb78 3863cacc 4b915115 <0fe00000> 4800002c
> 81220070 712a0004
> [ 0.844723] ---[ end trace 969d686308d40b33 ]---
>
> Then starting init fails:
>
> [ 3.894074] Run /init as init process
> [ 3.898403] Failed to execute /init (error -14)
> [ 3.903009] Run /sbin/init as init process
> [ 3.907172] Run /etc/init as init process
> [ 3.911251] Run /bin/init as init process
> [ 3.915513] Run /bin/sh as init process
> [ 3.919471] Starting init: /bin/sh exists but couldn't execute it
> (error -14)
> [ 3.926732] Kernel panic - not syncing: No working init found. Try
> passing init= option to kernel. See Linux
> Documentation/admin-guide/init.rst for guidance.
> [ 3.940864] CPU: 0 PID: 1 Comm: init Tainted: G W
> 5.3.0-rc7-s3k-dev-00880-g28fd02a838e5-dirty #2307
> [ 3.951165] Call Trace:
> [ 3.953617] [df4a5ec8] [c002392c] panic+0x12c/0x320 (unreliable)
> [ 3.959621] [df4a5f28] [c0004b8c] rootfs_mount+0x0/0x2c
> [ 3.964849] [df4a5f38] [c00122ac] ret_from_kernel_thread+0x14/0x1c
>
>
> Christophe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 0/2] mm/debug: Add tests for architecture exported page table helpers
From: Anshuman Khandual @ 2019-09-13 6:24 UTC (permalink / raw)
To: Christophe Leroy, linux-mm
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Heiko Carstens, Michal Hocko, Dave Hansen, Paul Mackerras,
sparclinux, Thomas Gleixner, linux-s390, Jason Gunthorpe,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Tetsuo Handa, Gerald Schaefer, linux-snps-arc,
Kees Cook, Masahiro Yamada, Mark Brown, Kirill A . Shutemov,
Dan Williams, Vlastimil Babka, linux-arm-kernel,
Sri Krishna chowdary, Ard Biesheuvel, Greg Kroah-Hartman,
linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Vineet Gupta, Martin Schwidefsky, Andrew Morton,
linuxppc-dev, David S. Miller, Mike Kravetz
In-Reply-To: <527edfce-c986-de4c-e286-34a70f6a2790@c-s.fr>
On 09/12/2019 08:12 PM, Christophe Leroy wrote:
> Hi,
>
> I didn't get patch 1 of this series, and it is not on linuxppc-dev patchwork either. Can you resend ?
Its there on linux-mm patchwork and copied on linux-kernel@vger.kernel.org
as well. The CC list for the first patch was different than the second one.
https://patchwork.kernel.org/patch/11142317/
Let me know if you can not find it either on MM or LKML list.
- Anshuman
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] mm/pgtable/debug: Fix test validating architecture page table helpers
From: Christophe Leroy @ 2019-09-13 6:23 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Heiko Carstens, Michal Hocko, Dave Hansen, Paul Mackerras,
sparclinux, Dan Williams, linux-s390, Jason Gunthorpe, x86,
Russell King - ARM Linux, Matthew Wilcox, Steven Price,
Tetsuo Handa, Vlastimil Babka, linux-snps-arc, Kees Cook,
Mark Brown, Kirill A . Shutemov, Thomas Gleixner, Gerald Schaefer,
linux-arm-kernel, Sri Krishna chowdary, Masahiro Yamada,
Greg Kroah-Hartman, Ard Biesheuvel, linux-mips, Ralf Baechle,
linux-kernel, Paul Burton, Mike Rapoport, Vineet Gupta,
Martin Schwidefsky, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <ab0ca38b-1e4f-b636-f8b4-007a15903984@c-s.fr>
Fix build failure on powerpc.
Fix preemption imbalance.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
mm/arch_pgtable_test.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
index 8b4a92756ad8..f2b3c9ec35fa 100644
--- a/mm/arch_pgtable_test.c
+++ b/mm/arch_pgtable_test.c
@@ -24,6 +24,7 @@
#include <linux/swap.h>
#include <linux/swapops.h>
#include <linux/sched/mm.h>
+#include <linux/highmem.h>
#include <asm/pgalloc.h>
#include <asm/pgtable.h>
@@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void)
p4d_clear_tests(p4dp);
pgd_clear_tests(mm, pgdp);
+ pte_unmap(ptep);
+
pmd_populate_tests(mm, pmdp, saved_ptep);
pud_populate_tests(mm, pudp, saved_pmdp);
p4d_populate_tests(mm, p4dp, saved_pudp);
--
2.13.3
_______________________________________________
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 V7 3/3] arm64/mm: Enable memory hot remove
From: Anshuman Khandual @ 2019-09-13 5:58 UTC (permalink / raw)
To: Catalin Marinas
Cc: mark.rutland, mhocko, david, linux-mm, arunks, cpandya, ira.weiny,
will, steven.price, valentin.schneider, suzuki.poulose,
Robin.Murphy, broonie, cai, ard.biesheuvel, dan.j.williams,
linux-arm-kernel, osalvador, steve.capper, logang, linux-kernel,
akpm, mgorman
In-Reply-To: <20190912201517.GB1068@C02TF0J2HF1T.local>
On 09/13/2019 01:45 AM, Catalin Marinas wrote:
> Hi Anshuman,
>
> Thanks for the details on the need for removing the page tables and
> vmemmap backing. Some comments on the code below.
>
> On Tue, Sep 03, 2019 at 03:15:58PM +0530, Anshuman Khandual wrote:
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -60,6 +60,14 @@ static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss __maybe_unused;
>>
>> static DEFINE_SPINLOCK(swapper_pgdir_lock);
>>
>> +/*
>> + * This represents if vmalloc and vmemmap address range overlap with
>> + * each other on an intermediate level kernel page table entry which
>> + * in turn helps in deciding whether empty kernel page table pages
>> + * if any can be freed during memory hotplug operation.
>> + */
>> +static bool vmalloc_vmemmap_overlap;
>
> I'd say just move the static find_vmalloc_vmemmap_overlap() function
> here, the compiler should be sufficiently smart enough to figure out
> that it's just a build-time constant.
Sure, will do.
>
>> @@ -770,6 +1022,28 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
>> void vmemmap_free(unsigned long start, unsigned long end,
>> struct vmem_altmap *altmap)
>> {
>> +#ifdef CONFIG_MEMORY_HOTPLUG
>> + /*
>> + * FIXME: We should have called remove_pagetable(start, end, true).
>> + * vmemmap and vmalloc virtual range might share intermediate kernel
>> + * page table entries. Removing vmemmap range page table pages here
>> + * can potentially conflict with a concurrent vmalloc() allocation.
>> + *
>> + * This is primarily because vmalloc() does not take init_mm ptl for
>> + * the entire page table walk and it's modification. Instead it just
>> + * takes the lock while allocating and installing page table pages
>> + * via [p4d|pud|pmd|pte]_alloc(). A concurrently vanishing page table
>> + * entry via memory hot remove can cause vmalloc() kernel page table
>> + * walk pointers to be invalid on the fly which can cause corruption
>> + * or worst, a crash.
>> + *
>> + * So free_empty_tables() gets called where vmalloc and vmemmap range
>> + * do not overlap at any intermediate level kernel page table entry.
>> + */
>> + unmap_hotplug_range(start, end, true);
>> + if (!vmalloc_vmemmap_overlap)
>> + free_empty_tables(start, end);
>> +#endif
>> }
>
> So, I see the risk with overlapping and I guess for some kernel
> configurations (PAGE_SIZE == 64K) we may not be able to avoid it. If we
Did not see 64K config options to have overlap, do you suspect they might ?
After the 52 bit KVA series has been merged, following configurations have
the vmalloc-vmemmap range overlap problem.
- 4K page size with 48 bit VA space
- 16K page size with 48 bit VA space
> can, that's great, otherwise could we rewrite the above functions to
> handle floor and ceiling similar to free_pgd_range()? (I wonder how this
> function works if you called it on init_mm and kernel address range). By
Hmm, never tried that. Are you wondering if this can be used directly ?
There are two distinct elements which make it very specific to user page
tables, mmu_gather based TLB tracking and mm->pgtable_bytes accounting
with mm_dec_nr_pxx().
> having the vmemmap start/end information it avoids freeing partially
> filled page table pages.
Did you mean page table pages which can partially overlap with vmalloc ?
The problem (race) is not because of the inability to deal with partially
filled table. We can handle that correctly as explained below [1]. The
problem is with inadequate kernel page table locking during vmalloc()
which might be accessing intermediate kernel page table pointers which is
being freed with free_empty_tables() concurrently. Hence we cannot free
any page table page which can ever have entries from vmalloc() range.
Though not completely sure, whether I really understood the suggestion above
with respect to the floor-ceiling mechanism as in free_pgd_range(). Are you
suggesting that we should only attempt to free up those vmemmap range page
table pages which *definitely* could never overlap with vmalloc by working
on a modified (i.e cut down with floor-ceiling while avoiding vmalloc range
at each level) vmemmap range instead ? This can be one restrictive version of
the function free_empty_tables() called in case there is an overlap. So we
will maintain two versions for free_empty_tables(). Please correct me if any
the above assumptions or understanding is wrong.
But yes, with this we should be able to free up some possible empty page
table pages which were being left out in the current proposal when overlap
happens.
[1] Skipping partially filled page tables
All free_pXX_table() functions take care in avoiding freeing partially filled
page table pages whether they represent or ever represented linear or vmemmap
or vmalloc mapping in init_mm. They go over each individual entry in a given
page table making sure that each of them checks as pXX_none() before freeing
the entire page table page.
Though walking is restricted by the address range in question.
free_empty_tables(start, end)
free_empty_pud_table(pgdp, addr, next);
free_empty_pmd_table(pudp, addr, next);
free_empty_pte_table(pmdp, addr, next);
Page table pages being examined here on the way while freeing might contain
entries which once represented address beyond vmemmap range in removal. But
thats a good thing IMHO. It can accommodate vmemmap tear down from a previous
hot remove for an adjacent range which might not have been freed last time.
pudp = pud_offset(pgdp, 0UL);
pmdp = pmd_offset(pudp, 0UL);
ptep = pte_offset_kernel(pmdp, 0UL);
pxx_none() makes sure that in such cases freeing of the page table page is
skipped. But yes, even though it is more thorough, it might attempt to free
page table pages which might contains entries not belonging to the range
being removed.
>
> Another question: could we do the page table and the actual vmemmap
> pages freeing in a single pass (sorry if this has been discussed
> before)?
We could and some initial versions (till V5) of the series had that in fact.
Initially Mark Rutland had suggested to do this in two passes. Some extracts
from the previous discussion.
https://lkml.org/lkml/2019/5/30/1159
-----------------------
Looking at this some more, I don't think this is quite right, and tI
think that structure of the free_*() and remove_*() functions makes this
unnecessarily hard to follow. We should aim for this to be obviously
correct.
The x86 code is the best template to follow here. As mentioned
previously, I'm fairly certain it's not entirely correct (e.g. due to
missing TLB maintenance), and we've already diverged a fair amount in
fixing up obvious issues, so we shouldn't aim to mirror it.
I think that the structure of unmap_region() is closer to what we want
here -- do one pass to unmap leaf entries (and freeing the associated
memory if unmapping the vmemmap), then do a second pass cleaning up any
empty tables.
----------------------
Apart from the fact that two passes over the page table is cleaner and gives
us more granular and modular infrastructure to use for later purposes, it is
also a necessity in dealing with vmalloc-vmemmap overlap. free_empty_tables()
which is the second pass, can be skipped cleanly when overlap is detected.
>
>> @@ -1048,10 +1322,18 @@ int p4d_free_pud_page(p4d_t *p4d, unsigned long addr)
>> }
>>
>> #ifdef CONFIG_MEMORY_HOTPLUG
>> +static void __remove_pgd_mapping(pgd_t *pgdir, unsigned long start, u64 size)
>> +{
>> + unsigned long end = start + size;
>> +
>> + WARN_ON(pgdir != init_mm.pgd);
>> + remove_pagetable(start, end, false);
>> +}
>
> I think the point I've made previously still stands: you only call
> remove_pagetable() with sparse_vmap == false in this patch. Just remove
> the extra argument and call unmap_hotplug_range() with sparse_vmap ==
> false directly in remove_pagetable().
Sure, will do. The original function signature was left unchanged in the hope
that at a later point in time it can be called with "sparse_vmap == true" as
mentioned by the comment in vmemmap_free(). Will change the comment as well.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in handle_vmptrld
From: Greg Kroah-Hartman @ 2019-09-13 4:46 UTC (permalink / raw)
To: Paolo Bonzini
Cc: mark.rutland, x86, wanpengli, kvm, narmstrong, catalin.marinas,
will.deacon, hpa, khilman, joro, rkrcmar, mingo, Dmitry Vyukov,
syzbot, devicetree, syzkaller-bugs, robh+dt, bp, linux-amlogic,
tglx, linux-arm-kernel, jmattson, USB list, linux-kernel,
sean.j.christopherson, carlo, Vitaly Kuznetsov
In-Reply-To: <5218e70e-8a80-7c5f-277b-01d9ab70692a@redhat.com>
On Thu, Sep 12, 2019 at 06:49:26PM +0200, Paolo Bonzini wrote:
> [tl;dr: there could be a /dev/usb bug only affecting KASAN
> configurations, jump to the end to skip the analysis and get to the bug
> details]
>
> On 12/09/19 15:54, Vitaly Kuznetsov wrote:
> > Hm, the bisection seems bogus but the stack points us to the following
> > piece of code:
> >
> > 4776) if (kvm_vcpu_map(vcpu, gpa_to_gfn(vmptr), &map)) {
> > <skip>
> > 4783) return nested_vmx_failValid(vcpu,
> > 4784) VMXERR_VMPTRLD_INCORRECT_VMCS_REVISION_ID);
> > 4785) }
> > 4786)
> > 4787) new_vmcs12 = map.hva;
> > 4788)
> > *4789) if (new_vmcs12->hdr.revision_id != VMCS12_REVISION ||
> > 4790) (new_vmcs12->hdr.shadow_vmcs &&
> > 4791) !nested_cpu_has_vmx_shadow_vmcs(vcpu))) {
> >
> > the reported problem seems to be on VMCS12 region access but it's part
> > of guest memory and we successfuly managed to map it. We're definitely
> > within 1-page range. Maybe KASAN is just wrong here?
>
> Here is the relevant part of the syzkaller repro:
>
> syz_kvm_setup_cpu$x86(r1, 0xffffffffffffffff,
> &(0x7f0000000000/0x18000)=nil, 0x0, 0x133, 0x0, 0x0, 0xff7d)
> r3 = syz_open_dev$usb(&(0x7f0000000080)='/dev/bus/usb/00#/00#\x00',
> 0x40000fffffd, 0x200800000000042)
> mmap$IORING_OFF_SQES(&(0x7f0000007000/0x2000)=nil, 0x2000, 0x4, 0x13,
> r3, 0x10000000)
> syz_kvm_setup_cpu$x86(0xffffffffffffffff, r2,
> &(0x7f0000000000/0x18000)=nil, 0x0, 0xfefd, 0x40, 0x0, 0xfffffffffffffdd4)
> ioctl$KVM_RUN(r2, 0xae80, 0x0)
>
> The mmap$IORING_OFF_SQES is just a normal mmap from a device, which
> replaces the previous mapping for guest memory and in particular
> 0x7f0000007000 which is the VMCS (from the C reproducer: "#define
> ADDR_VAR_VMCS 0x7000").
>
> The previous mapping is freed with do_munmap and then repopulated in
> usbdev_mmap with remap_pfn_range. In KVM this means that kvm_vcpu_map
> goes through hva_to_pfn_remapped, which correctly calls get_page via
> kvm_get_pfn. (Note that although drivers/usb/core/devio.c's usbdev_mmap
> sets VM_IO *after* calling remap_pfn_range, remap_pfn_range itself
> helpfully sets it before calling remap_p4d_range. And anyway KVM is
> looking at vma->vm_flags under mmap_sem, which is held during mmap).
>
> So, KVM should be doing the right thing. Now, the error is:
>
> > Read of size 4 at addr ffff888091e10000 by task syz-executor758/10006
> > The buggy address belongs to the object at ffff888091e109c0
> > The buggy address is located 2496 bytes to the left of
> > 8192-byte region [ffff888091e109c0, ffff888091e129c0)
>
> And given the use of remap_pfn_range in devusb_mmap, the simplest
> explanation could be that USB expects kmalloc-8k to return 8k-aligned
> values, but this is not true anymore with KASAN. CCing Dmitry, Greg and
> linux-usb.
USB drivers expect kmalloc to return DMA-able memory. I don't know
about specific alignment issues, that should only an issue for the host
controller being used here, which you do not say in the above list.
We have had some reports that usbdev_mmap() does not do the "correct
thing" for all host controllers, but a lot of the DMA work that is in
linux-next for 5.4-rc1 should have helped resolve those issues. What
tree are you seeing these bug reports happening from?
thanks,
greg k-h
_______________________________________________
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] clk: imx: lpcg: write twice when writing lpcg regs
From: Shawn Guo @ 2019-09-13 3:42 UTC (permalink / raw)
To: Anson Huang
Cc: Aisheng Dong, Peng Fan, Dong Aisheng, Stephen Boyd,
mturquette@baylibre.com, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org, Abel Vesa, dl-linux-imx,
kernel@pengutronix.de, festevam@gmail.com, s.hauer@pengutronix.de,
linux-arm-kernel@lists.infradead.org, Jacky Bai
In-Reply-To: <DB3PR0402MB3916906683B58843B459ABE1F5B60@DB3PR0402MB3916.eurprd04.prod.outlook.com>
On Tue, Sep 10, 2019 at 02:47:59AM +0000, Anson Huang wrote:
>
>
> > On Sat, Sep 7, 2019 at 9:47 PM Stephen Boyd <sboyd@kernel.org> wrote:
> > >
> > > Quoting Peng Fan (2019-08-27 01:17:50)
> > > > From: Peng Fan <peng.fan@nxp.com>
> > > >
> > > > There is hardware issue that:
> > > > The output clock the LPCG cell will not turn back on as expected,
> > > > even though a read of the IPG registers in the LPCG indicates that
> > > > the clock should be enabled.
> > > >
> > > > The software workaround is to write twice to enable the LPCG clock
> > > > output.
> > > >
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > >
> > > Does this need a Fixes tag?
> >
> > Not sure as it's not code logic issue but a hardware bug.
> > And 4.19 LTS still have not this driver support.
>
> Looks like there is an errata for this issue, and Ranjani just sent a patch for review internally,
Having errata number in both commit log and code comment is generally
helpful.
Shawn
_______________________________________________
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 01/12] ARM: dts: imx7d: cl-som-imx7 imx7d-sbc-imx7: move USB
From: Shawn Guo @ 2019-09-13 3:31 UTC (permalink / raw)
To: André Draszik
Cc: Mark Rutland, devicetree, linux-arm-kernel, Sascha Hauer,
linux-kernel, Rob Herring, Igor Grinberg, Pengutronix Kernel Team,
Fabio Estevam, Ilya Ledvich, NXP Linux Team
In-Reply-To: <20190826153800.35400-1-git@andred.net>
On Mon, Aug 26, 2019 at 04:37:49PM +0100, André Draszik wrote:
> Whether and which USB port is enabled and how they
> are powered is a function of the carrier board, not
> of the SoM. Different carrier boards can have different
> ports enabled / wired up, and power them differently;
> so this should really move into the respective DTS.
>
> Do so and update the USB power supply to reflect
> the actual situation on the sbc-imx7 carrier board.
>
> Signed-off-by: André Draszik <git@andred.net>
> Cc: Ilya Ledvich <ilya@compulab.co.il>
> Cc: Igor Grinberg <grinberg@compulab.co.il>
Ilya, Igor, can you have a look at the series?
Shawn
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: NXP Linux Team <linux-imx@nxp.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 24 ------------------------
> arch/arm/boot/dts/imx7d-sbc-imx7.dts | 13 +++++++++++++
> 2 files changed, 13 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
> index 62d5e9a4a781..6f7e85cf0c28 100644
> --- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
> +++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
> @@ -22,15 +22,6 @@
> device_type = "memory";
> reg = <0x80000000 0x10000000>; /* 256 MB - minimal configuration */
> };
> -
> - reg_usb_otg1_vbus: regulator-vbus {
> - compatible = "regulator-fixed";
> - regulator-name = "usb_otg1_vbus";
> - regulator-min-microvolt = <5000000>;
> - regulator-max-microvolt = <5000000>;
> - gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
> - enable-active-high;
> - };
> };
>
> &cpu0 {
> @@ -193,13 +184,6 @@
> status = "okay";
> };
>
> -&usbotg1 {
> - pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_usbotg1>;
> - vbus-supply = <®_usb_otg1_vbus>;
> - status = "okay";
> -};
> -
> &usdhc3 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usdhc3>;
> @@ -278,11 +262,3 @@
> >;
> };
> };
> -
> -&iomuxc_lpsr {
> - pinctrl_usbotg1: usbotg1grp {
> - fsl,pins = <
> - MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG PWREN */
> - >;
> - };
> -};
> diff --git a/arch/arm/boot/dts/imx7d-sbc-imx7.dts b/arch/arm/boot/dts/imx7d-sbc-imx7.dts
> index f8a868552707..aab646903de3 100644
> --- a/arch/arm/boot/dts/imx7d-sbc-imx7.dts
> +++ b/arch/arm/boot/dts/imx7d-sbc-imx7.dts
> @@ -15,6 +15,14 @@
> / {
> model = "CompuLab SBC-iMX7";
> compatible = "compulab,sbc-imx7", "compulab,cl-som-imx7", "fsl,imx7d";
> +
> + reg_usb_vbus: regulator-usb-vbus {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + };
> };
>
> &usdhc1 {
> @@ -26,6 +34,11 @@
> status = "okay";
> };
>
> +&&usbotg1 {
> + vbus-supply = <®_usb_vbus>;
> + status = "okay";
> +};
> +
> &iomuxc {
> pinctrl_usdhc1: usdhc1grp {
> fsl,pins = <
> --
> 2.23.0.rc1
>
_______________________________________________
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] bus: imx-weim: remove __init from 2 functions
From: Shawn Guo @ 2019-09-13 3:28 UTC (permalink / raw)
To: Ilie Halip
Cc: clang-built-linux, Sascha Hauer, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <CAHFW8PTS6DQCmJKOC0PK=4A6zjOZm6Krhr6MTqB1c8kZ8++hNw@mail.gmail.com>
On Wed, Sep 11, 2019 at 10:40:19AM +0300, Ilie Halip wrote:
> Hi Shawn,
>
> I think you can disregard this patch; the issue was already fixed by
> Arnd[1] a couple of days after I sent it.
Ah, okay. Thanks for the note. Dropped.
Shawn
_______________________________________________
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/5] input: keyboard: imx_sc: Add i.MX system controller key support
From: Dmitry Torokhov @ 2019-09-12 20:22 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, ulf.hansson, ping.bai, catalin.marinas, peng.fan,
stefan, bjorn.andersson, leonard.crestez, will, festevam,
yuehaibing, marcin.juszkiewicz, jagan, linux-input, ronald,
Linux-imx, devicetree, arnd, s.hauer, mripard, m.felsch, robh+dt,
tglx, andriy.shevchenko, daniel.baluta, linux-arm-kernel,
aisheng.dong, fugang.duan, gregkh, linux-kernel, dinguyen, kernel,
olof, shawnguo
In-Reply-To: <1567546600-21566-2-git-send-email-Anson.Huang@nxp.com>
Hi Anson,
On Tue, Sep 03, 2019 at 05:36:37PM -0400, Anson Huang wrote:
> i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
> inside, the system controller is in charge of controlling power,
> clock and scu key etc..
>
> Adds i.MX system controller key driver support, Linux kernel has
> to communicate with system controller via MU (message unit) IPC
> to get scu key's status.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V2:
> - use private platform data instead of global data;
> - use "key" instead of "pwrkey";
> - fix some data format.
> ---
> drivers/input/keyboard/Kconfig | 7 ++
> drivers/input/keyboard/Makefile | 1 +
> drivers/input/keyboard/imx_sc_key.c | 178 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 186 insertions(+)
> create mode 100644 drivers/input/keyboard/imx_sc_key.c
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index 2e6d288..607acf2 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -469,6 +469,13 @@ config KEYBOARD_IMX
> To compile this driver as a module, choose M here: the
> module will be called imx_keypad.
>
> +config KEYBOARD_IMX_SC_KEY
> + tristate "IMX SCU Key Driver"
> + depends on IMX_SCU
> + help
> + This is the system controller key driver for NXP i.MX SoCs with
> + system controller inside.
> +
> config KEYBOARD_NEWTON
> tristate "Newton keyboard"
> select SERIO
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index 9510325..f5b1752 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -29,6 +29,7 @@ obj-$(CONFIG_KEYBOARD_HIL) += hil_kbd.o
> obj-$(CONFIG_KEYBOARD_HIL_OLD) += hilkbd.o
> obj-$(CONFIG_KEYBOARD_IPAQ_MICRO) += ipaq-micro-keys.o
> obj-$(CONFIG_KEYBOARD_IMX) += imx_keypad.o
> +obj-$(CONFIG_KEYBOARD_IMX_SC_KEY) += imx_sc_key.o
> obj-$(CONFIG_KEYBOARD_HP6XX) += jornada680_kbd.o
> obj-$(CONFIG_KEYBOARD_HP7XX) += jornada720_kbd.o
> obj-$(CONFIG_KEYBOARD_LKKBD) += lkkbd.o
> diff --git a/drivers/input/keyboard/imx_sc_key.c b/drivers/input/keyboard/imx_sc_key.c
> new file mode 100644
> index 0000000..e69479b
> --- /dev/null
> +++ b/drivers/input/keyboard/imx_sc_key.c
> @@ -0,0 +1,178 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2019 NXP.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/firmware/imx/sci.h>
> +#include <linux/init.h>
> +#include <linux/input.h>
> +#include <linux/interrupt.h>
> +#include <linux/jiffies.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +
> +#define DEBOUNCE_TIME 100
> +#define REPEAT_INTERVAL 60
> +
> +#define SC_IRQ_BUTTON 1
> +#define SC_IRQ_GROUP_WAKE 3
> +#define IMX_SC_MISC_FUNC_GET_BUTTON_STATUS 18
> +
> +struct imx_key_drv_data {
> + int keycode;
> + bool keystate; /* 1: pressed, 0: release */
> + bool delay_check;
> + struct delayed_work check_work;
> + struct input_dev *input;
> + struct imx_sc_ipc *key_ipc_handle;
> + struct notifier_block key_notifier;
> +};
> +
> +struct imx_sc_msg_key {
> + struct imx_sc_rpc_msg hdr;
> + u8 state;
> +};
> +
> +static int imx_sc_key_notify(struct notifier_block *nb,
> + unsigned long event, void *group)
> +{
> + struct imx_key_drv_data *priv =
> + container_of(nb,
> + struct imx_key_drv_data,
> + key_notifier);
> +
> + if ((event & SC_IRQ_BUTTON) && (*(u8 *)group == SC_IRQ_GROUP_WAKE)
> + && !priv->delay_check) {
> + priv->delay_check = 1;
> + schedule_delayed_work(&priv->check_work,
> + msecs_to_jiffies(REPEAT_INTERVAL));
> + }
> +
> + return 0;
> +}
> +
> +static void imx_sc_check_for_events(struct work_struct *work)
> +{
> + struct imx_key_drv_data *priv =
> + container_of(work,
> + struct imx_key_drv_data,
> + check_work.work);
> + struct input_dev *input = priv->input;
> + struct imx_sc_msg_key msg;
> + struct imx_sc_rpc_msg *hdr = &msg.hdr;
> + bool state;
> + int ret;
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_MISC;
> + hdr->func = IMX_SC_MISC_FUNC_GET_BUTTON_STATUS;
> + hdr->size = 1;
> +
> + ret = imx_scu_call_rpc(priv->key_ipc_handle, &msg, true);
> + if (ret) {
> + dev_err(&input->dev, "read imx sc key failed, ret %d\n", ret);
> + return;
> + }
> +
> + state = (bool)msg.state;
> +
> + if (!state && !priv->keystate)
> + state = true;
> +
> + if (state ^ priv->keystate) {
> + pm_wakeup_event(input->dev.parent, 0);
> + priv->keystate = state;
> + input_event(input, EV_KEY, priv->keycode, state);
> + input_sync(input);
> + if (!state)
> + priv->delay_check = 0;
> + pm_relax(priv->input->dev.parent);
> + }
> +
> + if (state)
> + schedule_delayed_work(&priv->check_work,
> + msecs_to_jiffies(DEBOUNCE_TIME));
Hmm, I am not quite sure follow the code. Judging by the name, you are
trying to handle debounce, but if I understand this correctly you
already sent out the press event for now.
Could you please explain what you are trying to do here.
> +}
> +
> +static int imx_sc_key_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + static struct imx_key_drv_data *priv;
> + struct input_dev *input;
> + int ret;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + ret = imx_scu_get_handle(&priv->key_ipc_handle);
> + if (ret)
> + return ret;
> +
> + if (of_property_read_u32(np, "linux,keycode", &priv->keycode)) {
> + dev_err(&pdev->dev, "missing KEY_POWER in DT\n");
> + return -EINVAL;
> + }
> +
> + INIT_DELAYED_WORK(&priv->check_work, imx_sc_check_for_events);
> +
> + input = devm_input_allocate_device(&pdev->dev);
> + if (!input) {
> + dev_err(&pdev->dev, "failed to allocate the input device\n");
> + return -ENOMEM;
> + }
> +
> + input->name = pdev->name;
> + input->phys = "imx-sc-key/input0";
> + input->id.bustype = BUS_HOST;
> +
> + input_set_capability(input, EV_KEY, priv->keycode);
> +
> + ret = input_register_device(input);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to register input device\n");
> + return ret;
> + }
> +
> + priv->input = input;
> + platform_set_drvdata(pdev, priv);
> +
> + ret = imx_scu_irq_group_enable(SC_IRQ_GROUP_WAKE, SC_IRQ_BUTTON, true);
> + if (ret) {
> + dev_warn(&pdev->dev, "enable scu group irq failed\n");
> + return ret;
> + }
> +
> + priv->key_notifier.notifier_call = imx_sc_key_notify;
> + ret = imx_scu_irq_register_notifier(&priv->key_notifier);
> + if (ret) {
> + imx_scu_irq_group_enable(SC_IRQ_GROUP_WAKE, SC_IRQ_BUTTON, false);
> + dev_warn(&pdev->dev, "register scu notifier failed\n");
> + }
> +
> + return ret;
> +}
> +
> +static const struct of_device_id imx_sc_key_ids[] = {
> + { .compatible = "fsl,imx-sc-key" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, imx_sc_key_ids);
> +
> +static struct platform_driver imx_sc_key_driver = {
> + .driver = {
> + .name = "imx-sc-key",
> + .of_match_table = imx_sc_key_ids,
> + },
> + .probe = imx_sc_key_probe,
You need a remove() handler to disable the itq group, remove the
notifier, cancel the delayed work, etc.
> +};
> +module_platform_driver(imx_sc_key_driver);
> +
> +MODULE_AUTHOR("Anson Huang <Anson.Huang@nxp.com>");
> +MODULE_DESCRIPTION("i.MX System Controller Key Driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
>
Thanks.
--
Dmitry
_______________________________________________
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] input: keyboard: snvs_pwrkey: Send key events for i.MX6 S, DL and Q
From: Dmitry Torokhov @ 2019-09-12 20:13 UTC (permalink / raw)
To: Robin van der Gracht
Cc: Adam Ford, Marco Felsch, linux-kernel @ vger . kernel . org,
Pengutronix Kernel Team, linux-input @ vger . kernel . org,
RobinGong, Shawn Guo, linux-arm-kernel @ lists . infradead . org
In-Reply-To: <20190904062329.97520-1-robin@protonic.nl>
Hi Robin,
On Wed, Sep 04, 2019 at 06:23:29AM +0000, Robin van der Gracht wrote:
> The first generation i.MX6 processors does not send an interrupt when the
> power key is pressed. It sends a power down request interrupt if the key is
> released before a hard shutdown (5 second press). This should allow
> software to bring down the SoC safely.
>
> For this driver to work as a regular power key with the older SoCs, we need
> to send a keypress AND release when we get the power down request irq.
>
> Signed-off-by: Robin van der Gracht <robin@protonic.nl>
> ---
>
> Changes v2 -> v3:
> - Drop alt compatible string for identifying first revision snvs hardware,
> read minor revision from register instead.
> - Drop imx6qdl.dtsi modification and device-tree binding documentation.
> - Add an additional input_sync() to create 2 seperate input reports for press
> and release.
>
> drivers/input/keyboard/Kconfig | 2 +-
> drivers/input/keyboard/snvs_pwrkey.c | 28 ++++++++++++++++++++++++++--
> 2 files changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index 7c4f19dab34f..937e58da5ce1 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -436,7 +436,7 @@ config KEYBOARD_SNVS_PWRKEY
> depends on OF
> help
> This is the snvs powerkey driver for the Freescale i.MX application
> - processors that are newer than i.MX6 SX.
> + processors.
>
> To compile this driver as a module, choose M here; the
> module will be called snvs_pwrkey.
> diff --git a/drivers/input/keyboard/snvs_pwrkey.c b/drivers/input/keyboard/snvs_pwrkey.c
> index 5342d8d45f81..828580eee0d2 100644
> --- a/drivers/input/keyboard/snvs_pwrkey.c
> +++ b/drivers/input/keyboard/snvs_pwrkey.c
> @@ -19,6 +19,7 @@
> #include <linux/mfd/syscon.h>
> #include <linux/regmap.h>
>
> +#define SNVS_HPVIDR1_REG 0xF8
> #define SNVS_LPSR_REG 0x4C /* LP Status Register */
> #define SNVS_LPCR_REG 0x38 /* LP Control Register */
> #define SNVS_HPSR_REG 0x14
> @@ -37,6 +38,7 @@ struct pwrkey_drv_data {
> int wakeup;
> struct timer_list check_timer;
> struct input_dev *input;
> + u8 minor_rev;
> };
>
> static void imx_imx_snvs_check_for_events(struct timer_list *t)
> @@ -45,6 +47,20 @@ static void imx_imx_snvs_check_for_events(struct timer_list *t)
> struct input_dev *input = pdata->input;
> u32 state;
>
> + if (pdata->minor_rev == 0) {
> + /*
> + * The first generation i.MX6 SoCs only sends an interrupt on
> + * button release. To mimic power-key usage, we'll prepend a
> + * press event.
> + */
> + input_report_key(input, pdata->keycode, 1);
> + input_sync(input);
> + input_report_key(input, pdata->keycode, 0);
> + input_sync(input);
> + pm_relax(input->dev.parent);
> + return;
> + }
> +
> regmap_read(pdata->snvs, SNVS_HPSR_REG, &state);
> state = state & SNVS_HPSR_BTN ? 1 : 0;
>
> @@ -67,13 +83,17 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int irq, void *dev_id)
> {
> struct platform_device *pdev = dev_id;
> struct pwrkey_drv_data *pdata = platform_get_drvdata(pdev);
> + unsigned long expire = jiffies;
> u32 lp_status;
>
> pm_wakeup_event(pdata->input->dev.parent, 0);
>
> regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
> - if (lp_status & SNVS_LPSR_SPO)
> - mod_timer(&pdata->check_timer, jiffies + msecs_to_jiffies(DEBOUNCE_TIME));
> + if (lp_status & SNVS_LPSR_SPO) {
> + if (pdata->minor_rev > 0)
> + expire = jiffies + msecs_to_jiffies(DEBOUNCE_TIME);
> + mod_timer(&pdata->check_timer, expire);
Why do we even need to fire the timer in case of the first generation
hardware? Just send press and release events directly from the ISR.
Thanks.
--
Dmitry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 05/13] clk: bcm2835: Add BCM2711_CLOCK_EMMC2 support
From: Stefan Wahren @ 2019-09-13 1:20 UTC (permalink / raw)
To: Eric Anholt, Matthias Brugger, Florian Fainelli, Ray Jui,
Scott Branden, Wolfram Sang, Rob Herring, Mark Rutland,
Michael Turquette, Stephen Boyd
Cc: devicetree, bcm-kernel-feedback-list, linux-i2c, linux-clk,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <87o8zp1h4u.fsf@anholt.net>
Am 12.09.19 um 20:52 schrieb Eric Anholt:
> Matthias Brugger <matthias.bgg@gmail.com> writes:
>
>> On 13/08/2019 18:20, Stefan Wahren wrote:
>>> The new BCM2711 supports an additional clock for the emmc2 block.
>>> So add a new compatible and register this clock only for BCM2711.
>>>
>>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
>>> Reviewed-by: Matthias Brugger <mbrugger@suse.com>
>>> Acked-by: Eric Anholt <eric@anholt.net>
>>> ---
>>> drivers/clk/bcm/clk-bcm2835.c | 20 +++++++++++++++++++-
>>> 1 file changed, 19 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
>>> index 21cd952..fdf672a 100644
>>> --- a/drivers/clk/bcm/clk-bcm2835.c
>>> +++ b/drivers/clk/bcm/clk-bcm2835.c
>>> @@ -114,6 +114,8 @@
>>> #define CM_AVEODIV 0x1bc
>>> #define CM_EMMCCTL 0x1c0
>>> #define CM_EMMCDIV 0x1c4
>>> +#define CM_EMMC2CTL 0x1d0
>>> +#define CM_EMMC2DIV 0x1d4
>>>
>>> /* General bits for the CM_*CTL regs */
>>> # define CM_ENABLE BIT(4)
>>> @@ -290,7 +292,8 @@
>>> #define BCM2835_MAX_FB_RATE 1750000000u
>>>
>>> #define SOC_BCM2835 BIT(0)
>>> -#define SOC_ALL (SOC_BCM2835)
>>> +#define SOC_BCM2711 BIT(1)
>>> +#define SOC_ALL (SOC_BCM2835 | SOC_BCM2711)
>>>
>>> /*
>>> * Names of clocks used within the driver that need to be replaced
>>> @@ -2003,6 +2006,16 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
>>> .frac_bits = 8,
>>> .tcnt_mux = 39),
>>>
>>> + /* EMMC2 clock (only available for BCM2711) */
>>> + [BCM2711_CLOCK_EMMC2] = REGISTER_PER_CLK(
>>> + SOC_BCM2711,
>>> + .name = "emmc2",
>>> + .ctl_reg = CM_EMMC2CTL,
>>> + .div_reg = CM_EMMC2DIV,
>>> + .int_bits = 4,
>>> + .frac_bits = 8,
>>> + .tcnt_mux = 42),
>>> +
>>> /* General purpose (GPIO) clocks */
>>> [BCM2835_CLOCK_GP0] = REGISTER_PER_CLK(
>>> SOC_ALL,
>>> @@ -2238,8 +2251,13 @@ static const struct cprman_plat_data cprman_bcm2835_plat_data = {
>>> .soc = SOC_BCM2835,
>>> };
>>>
>>> +static const struct cprman_plat_data cprman_bcm2711_plat_data = {
>>> + .soc = SOC_BCM2711,
>>> +};
>>> +
>>> static const struct of_device_id bcm2835_clk_of_match[] = {
>>> { .compatible = "brcm,bcm2835-cprman", .data = &cprman_bcm2835_plat_data },
>>> + { .compatible = "brcm,bcm2711-cprman", .data = &cprman_bcm2711_plat_data },
>> Because the RPi4 FW uses bcm2838-cprman as compatible, we will need to add this
>> here as well.
> Upstream has not committed to backwards compat with Pi's firmware. That
> makes the ABI requirement we get held to for upstream's DT absurd, but
> that's the state of things.
We also learned from past, that's not possible to keep things downstream
compatible. As soon as a binding is not accepted, this wont work
anymore. A lot of the downstream stuff is hacky.
For example yesterday, i learned that the thermal node is broken
(register is part of ring oscillator block). So do we really want to be
compatible with a hack? I would say: No
_______________________________________________
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/3] OMAP3: PM: Set/clear T2 bit for Smartreflex on TWL
From: Tony Lindgren @ 2019-09-12 21:09 UTC (permalink / raw)
To: Adam Ford
Cc: Nishanth Menon, Kevin Hilman, H. Nikolaus Schaller, Shweta Gulati,
André Roth, Thara Gopinath, Linux-OMAP, arm-soc
In-Reply-To: <CAHCN7x+Vd+ECoa4fmUfoX47znag+NxKSzRt3iouQCZ2CQ2T--A@mail.gmail.com>
* Adam Ford <aford173@gmail.com> [190912 19:00]:
> On Wed, Jul 31, 2019 at 8:29 PM André Roth <neolynx@gmail.com> wrote:
> >
> > From: Thara Gopinath <thara@ti.com>
> >
> > Voltage control on TWL can be done using VMODE/I2C1/I2C_SR.
> > Since almost all platforms use I2C_SR on omap3, omap3_twl_init by
> > default expects that OMAP's I2C_SR is plugged in to TWL's I2C
> > and calls omap3_twl_set_sr_bit. On platforms where I2C_SR is not connected,
> > the board files are expected to call omap3_twl_set_sr_bit(false) to
> > ensure that I2C_SR path is not set for voltage control and prevent
> > the default behavior of omap3_twl_init.
> >
> > Signed-off-by: Nishanth Menon <nm@ti.com>
> > Signed-off-by: Thara Gopinath <thara@ti.com>
> > Signed-off-by: Shweta Gulati <shweta.gulati@ti.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Signed-off-by: Kevin Hilman <khilman@ti.com>
>
> Tony,
>
> Is there a status update on this series? It's been several months,
> and I haven't seen any feedback on it, nor does it appear to be in any
> of your branches that I can see.
Well it was tagged RFC.. Does something need updating
with it?
At least the first two patches looked OK to me.
Regards,
Tony
_______________________________________________
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 3/6] ARM: dts: sunxi: h3/h5: Add MBUS controller node
From: Jernej Škrabec @ 2019-09-12 20:46 UTC (permalink / raw)
To: Maxime Ripard
Cc: mark.rutland, devicetree, linux-sunxi, linux-kernel, hverkuil,
wens, robh+dt, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20190912203427.ajbmtm5djctpkz6p@localhost.localdomain>
Dne četrtek, 12. september 2019 ob 22:34:27 CEST je Maxime Ripard napisal(a):
> On Thu, Sep 12, 2019 at 10:28:37PM +0200, Jernej Škrabec wrote:
> > Dne četrtek, 12. september 2019 ob 22:20:57 CEST je Maxime Ripard
napisal(a):
> > > Hi,
> > >
> > > On Thu, Sep 12, 2019 at 07:51:29PM +0200, Jernej Skrabec wrote:
> > > > Both, H3 and H5, contain MBUS, which is the bus used by DMA devices to
> > > > access system memory.
> > > >
> > > > MBUS controller is responsible for arbitration between channels based
> > > > on set priority and can do some other things as well, like report
> > > > bandwidth used. It also maps RAM region to different address than CPU.
> > > >
> > > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > > > ---
> > > >
> > > > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 9 +++++++++
> > > > 1 file changed, 9 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > > b/arch/arm/boot/dts/sunxi-h3-h5.dtsi index eba190b3f9de..ef1d03812636
> > > > 100644
> > > > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > > @@ -109,6 +109,7 @@
> > > >
> > > > compatible = "simple-bus";
> > > > #address-cells = <1>;
> > > > #size-cells = <1>;
> > > >
> > > > + dma-ranges;
> > > >
> > > > ranges;
> > > >
> > > > display_clocks: clock@1000000 {
> > > >
> > > > @@ -538,6 +539,14 @@
> > > >
> > > > };
> > > >
> > > > };
> > > >
> > > > + mbus: dram-controller@1c62000 {
> > > > + compatible = "allwinner,sun8i-h3-mbus";
> > > > + reg = <0x01c62000 0x1000>;
> > > > + clocks = <&ccu 113>;
> > > > + dma-ranges = <0x00000000 0x40000000
> >
> > 0xc0000000>;
> >
> > > > + #interconnect-cells = <1>;
> > > > + };
> > > > +
> > >
> > > If that's easy enough to access, can you also add the references in
> > > the devices that are already there? (CSI and DE comes to my mind, but
> > > there might be others).
> >
> > Strangely, DE2 doesn't use this offset. That was tested on OrangePi
> > Plus2E,
> > which has 2 GiB of RAM and subtracting this offset causes corrupted image.
>
> Ok, weird. But if it was tested then fine by me :)
>
> > But I can add this properties to CSI too. However, wouldn't that need CSI
> > DT binding expansion with those properties? othetwise DT check will fail.
> Oh right, we definitely need to update the binding indeed. The code
> should be able to cope with both cases already.
I guess it's better to handle that with another patch series then? Changing
CSI bindings doesn't fit here.
Best regards,
Jernej
_______________________________________________
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 5/6] media: sun4i: Add H3 deinterlace driver
From: Jernej Škrabec @ 2019-09-12 20:43 UTC (permalink / raw)
To: Maxime Ripard
Cc: mark.rutland, devicetree, linux-sunxi, linux-kernel, hverkuil,
wens, robh+dt, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20190912202647.wfcjur7yxhlelvd6@localhost.localdomain>
Dne četrtek, 12. september 2019 ob 22:26:47 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Thu, Sep 12, 2019 at 07:51:31PM +0200, Jernej Skrabec wrote:
> > + dev->regmap = devm_regmap_init_mmio(dev->dev, dev->base,
> > +
&deinterlace_regmap_config);
> > + if (IS_ERR(dev->regmap)) {
> > + dev_err(dev->dev, "Couldn't create deinterlace
regmap\n");
> > +
> > + return PTR_ERR(dev->regmap);
> > + }
> > +
> > + ret = clk_prepare_enable(dev->bus_clk);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to enable bus clock\n");
> > +
> > + return ret;
> > + }
>
> Do you need to keep the bus clock enabled all the time? Usually, for
> the SoCs that have a reset line, you only need it to read / write to
> the registers, not to have the controller actually running.
>
> If you don't, then regmap_init_mmio_clk will take care of that for
> you.
I'll test that.
>
> > + clk_set_rate(dev->mod_clk, 300000000);
> > +
> > + ret = clk_prepare_enable(dev->mod_clk);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to enable mod clock\n");
> > +
> > + goto err_bus_clk;
> > + }
> > +
> > + ret = clk_prepare_enable(dev->ram_clk);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to enable ram clock\n");
> > +
> > + goto err_mod_clk;
> > + }
> > +
> > + ret = reset_control_reset(dev->rstc);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to apply reset\n");
> > +
> > + goto err_ram_clk;
> > + }
>
> This could be moved to a runtime_pm hook, with get_sync called in the
> open. That way you won't leave the device powered on if it's unused.
Ok.
>
> > +struct deinterlace_dev {
> > + struct v4l2_device v4l2_dev;
> > + struct video_device vfd;
> > + struct device *dev;
> > + struct v4l2_m2m_dev *m2m_dev;
> > +
> > + /* Device file mutex */
> > + struct mutex dev_mutex;
> > +
> > + void __iomem *base;
> > + struct regmap *regmap;
>
> Do you need to store the base address in that structure if you're
> using the regmap?
Probably not. I'll remove it in v2.
Best regards,
Jernej
>
> Maxime
_______________________________________________
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 3/9] dt-bindings: crypto: Add DT bindings documentation for sun8i-ce Crypto Engine
From: Chen-Yu Tsai @ 2019-09-12 20:37 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Herbert Xu, Russell King, linux-kernel,
linux-sunxi, Rob Herring, Corentin Labbe, linux-crypto,
David Miller, linux-arm-kernel
In-Reply-To: <20190912203301.is4ubixhk64dl5t7@localhost.localdomain>
On Thu, Sep 12, 2019 at 9:33 PM Maxime Ripard <mripard@kernel.org> wrote:
>
> On Thu, Sep 12, 2019 at 09:26:27PM +0100, Chen-Yu Tsai wrote:
> > > >
> > > > clock-names:
> > > > items:
> > > > - const: ahb
> > > > - const: mod
> > > > - const: mbus
> > >
> > > And here as well
> > >
> > > Something I missed earlier though was that we've tried to unify as
> > > much as possible the ahb / apb / axi clocks around the bus name, it
> > > would be great if you could do it.
> >
> > I think we also want to standardize "mbus" as "dram"?
>
> Do we? The only user so far seems to be sun9i-de, while mbus has more
> users. I don't really care though, both mbus and dram are pretty
> generic to me. What makes you prefer dram over mbus?
Argh... it's actually "ram" we use the most. Both "dram" and "mbus"
have only one instance each.
ChenYu
_______________________________________________
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 3/6] ARM: dts: sunxi: h3/h5: Add MBUS controller node
From: Maxime Ripard @ 2019-09-12 20:34 UTC (permalink / raw)
To: Jernej Škrabec
Cc: mark.rutland, devicetree, linux-sunxi, linux-kernel, hverkuil,
wens, robh+dt, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <1679881.yZ8pMUtPNZ@jernej-laptop>
On Thu, Sep 12, 2019 at 10:28:37PM +0200, Jernej Škrabec wrote:
> Dne četrtek, 12. september 2019 ob 22:20:57 CEST je Maxime Ripard napisal(a):
> > Hi,
> >
> > On Thu, Sep 12, 2019 at 07:51:29PM +0200, Jernej Skrabec wrote:
> > > Both, H3 and H5, contain MBUS, which is the bus used by DMA devices to
> > > access system memory.
> > >
> > > MBUS controller is responsible for arbitration between channels based
> > > on set priority and can do some other things as well, like report
> > > bandwidth used. It also maps RAM region to different address than CPU.
> > >
> > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > > ---
> > >
> > > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 9 +++++++++
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > b/arch/arm/boot/dts/sunxi-h3-h5.dtsi index eba190b3f9de..ef1d03812636
> > > 100644
> > > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > @@ -109,6 +109,7 @@
> > >
> > > compatible = "simple-bus";
> > > #address-cells = <1>;
> > > #size-cells = <1>;
> > >
> > > + dma-ranges;
> > >
> > > ranges;
> > >
> > > display_clocks: clock@1000000 {
> > >
> > > @@ -538,6 +539,14 @@
> > >
> > > };
> > >
> > > };
> > >
> > > + mbus: dram-controller@1c62000 {
> > > + compatible = "allwinner,sun8i-h3-mbus";
> > > + reg = <0x01c62000 0x1000>;
> > > + clocks = <&ccu 113>;
> > > + dma-ranges = <0x00000000 0x40000000
> 0xc0000000>;
> > > + #interconnect-cells = <1>;
> > > + };
> > > +
> >
> > If that's easy enough to access, can you also add the references in
> > the devices that are already there? (CSI and DE comes to my mind, but
> > there might be others).
>
> Strangely, DE2 doesn't use this offset. That was tested on OrangePi Plus2E,
> which has 2 GiB of RAM and subtracting this offset causes corrupted image.
Ok, weird. But if it was tested then fine by me :)
> But I can add this properties to CSI too. However, wouldn't that need CSI DT
> binding expansion with those properties? othetwise DT check will fail.
Oh right, we definitely need to update the binding indeed. The code
should be able to cope with both cases already.
Maxime
_______________________________________________
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 3/9] dt-bindings: crypto: Add DT bindings documentation for sun8i-ce Crypto Engine
From: Maxime Ripard @ 2019-09-12 20:33 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Rutland, devicetree, Herbert Xu, Russell King, linux-kernel,
linux-sunxi, Rob Herring, Corentin Labbe, linux-crypto,
David Miller, linux-arm-kernel
In-Reply-To: <CAGb2v678WGQm5PNy8GhOTpz+fYeLP3k0dnR0F00yyZpSRcA4yA@mail.gmail.com>
On Thu, Sep 12, 2019 at 09:26:27PM +0100, Chen-Yu Tsai wrote:
> > >
> > > clock-names:
> > > items:
> > > - const: ahb
> > > - const: mod
> > > - const: mbus
> >
> > And here as well
> >
> > Something I missed earlier though was that we've tried to unify as
> > much as possible the ahb / apb / axi clocks around the bus name, it
> > would be great if you could do it.
>
> I think we also want to standardize "mbus" as "dram"?
Do we? The only user so far seems to be sun9i-de, while mbus has more
users. I don't really care though, both mbus and dram are pretty
generic to me. What makes you prefer dram over mbus?
Maxime
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: imx6: Extend support for Phytec phycore i.MX6ULL SoM
From: Parthiban Nallathambi @ 2019-09-12 20:29 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
linux-imx
Cc: devicetree, Parthiban Nallathambi, linux-kernel, linux-arm-kernel
Extend Phycore i.MX6UL SoM for i.MX6ULL with on board eMMC. Phycore
i.MX6ULL is deployed with same carrier board Segin as the pins are
compatible with UL version.
Signed-off-by: Parthiban Nallathambi <pn@denx.de>
---
arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi | 26 +++++++++++++++++--
.../dts/imx6ul-phytec-phyboard-segin-full.dts | 5 ++++
arch/arm/boot/dts/imx6ull-phytec-pcl063.dtsi | 24 +++++++++++++++++
3 files changed, 53 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/imx6ull-phytec-pcl063.dtsi
diff --git a/arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi b/arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi
index fc2997449b49..822a178ce438 100644
--- a/arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi
+++ b/arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi
@@ -7,7 +7,6 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/pwm/pwm.h>
-#include "imx6ul.dtsi"
/ {
model = "Phytec phyCORE i.MX6 UltraLite";
@@ -65,7 +64,7 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gpmi_nand>;
nand-on-flash-bbt;
- status = "okay";
+ status = "disabled";
};
&i2c1 {
@@ -90,6 +89,15 @@
status = "okay";
};
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ bus-width = <8>;
+ no-1-8-v;
+ non-removable;
+ status = "disabled";
+};
+
&iomuxc {
pinctrl_enet1: enet1grp {
fsl,pins = <
@@ -145,4 +153,18 @@
>;
};
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x170f9
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x100f9
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x170f9
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x170f9
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x170f9
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x170f9
+ MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x170f9
+ MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x170f9
+ MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x170f9
+ MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x170f9
+ >;
+ };
};
diff --git a/arch/arm/boot/dts/imx6ul-phytec-phyboard-segin-full.dts b/arch/arm/boot/dts/imx6ul-phytec-phyboard-segin-full.dts
index b6a1407a9d44..76f2447f2657 100644
--- a/arch/arm/boot/dts/imx6ul-phytec-phyboard-segin-full.dts
+++ b/arch/arm/boot/dts/imx6ul-phytec-phyboard-segin-full.dts
@@ -5,6 +5,7 @@
*/
/dts-v1/;
+#include "imx6ul.dtsi"
#include "imx6ul-phytec-pcl063.dtsi"
#include "imx6ul-phytec-phyboard-segin.dtsi"
#include "imx6ul-phytec-peb-eval-01.dtsi"
@@ -37,6 +38,10 @@
status = "okay";
};
+&gpmi {
+ status = "okay";
+};
+
&i2c_rtc {
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6ull-phytec-pcl063.dtsi b/arch/arm/boot/dts/imx6ull-phytec-pcl063.dtsi
new file mode 100644
index 000000000000..3f749d9f09a5
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-phytec-pcl063.dtsi
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 PHYTEC Messtechnik GmbH
+ * Author: Stefan Riedmueller <s.riedmueller@phytec.de>
+ */
+
+#include "imx6ul-phytec-pcl063.dtsi"
+
+/ {
+ model = "PHYTEC phyCORE-i.MX 6ULL";
+ compatible = "phytec,imx6ull-pcl063", "fsl,imx6ull";
+};
+
+&iomuxc {
+ /delete-node/ gpioledssomgrp;
+};
+
+&iomuxc_snvs {
+ pinctrl_gpioleds_som: gpioledssomgrp {
+ fsl,pins = <
+ MX6ULL_PAD_SNVS_TAMPER4__GPIO5_IO04 0x0b0b0
+ >;
+ };
+};
--
2.21.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
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