* [arm64:devel/mte-v4 25/28] arch/arm64/kernel/cpufeature.c:137:5: warning: no previous prototype for 'mte_ftr_filter'
From: kernel test robot @ 2020-06-03 13:31 UTC (permalink / raw)
To: Vincenzo, Frascino,; +Cc: Catalin Marinas, kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 4302 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git devel/mte-v4
head: 628f92bb11400cab1adb95c32c05cb1c3c384248
commit: bcf807ed1e622f8311b05e34816df6c41aed54c0 [25/28] arm64: mte: Kconfig entry
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout bcf807ed1e622f8311b05e34816df6c41aed54c0
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> arch/arm64/kernel/cpufeature.c:137:5: warning: no previous prototype for 'mte_ftr_filter' [-Wmissing-prototypes]
137 | s64 mte_ftr_filter(const struct arm64_ftr_bits *ftrp, s64 val)
| ^~~~~~~~~~~~~~
vim +/mte_ftr_filter +137 arch/arm64/kernel/cpufeature.c
4225028da943ad3 Catalin Marinas 2020-05-15 136
22fba7c9a015db8 Catalin Marinas 2020-04-08 @137 s64 mte_ftr_filter(const struct arm64_ftr_bits *ftrp, s64 val)
22fba7c9a015db8 Catalin Marinas 2020-04-08 138 {
22fba7c9a015db8 Catalin Marinas 2020-04-08 139 struct device_node *np;
22fba7c9a015db8 Catalin Marinas 2020-04-08 140 static bool memory_checked = false;
22fba7c9a015db8 Catalin Marinas 2020-04-08 141 static bool mte_capable = true;
22fba7c9a015db8 Catalin Marinas 2020-04-08 142
4225028da943ad3 Catalin Marinas 2020-05-15 143 if (mte_disable)
4225028da943ad3 Catalin Marinas 2020-05-15 144 return ID_AA64PFR1_MTE_NI;
4225028da943ad3 Catalin Marinas 2020-05-15 145
22fba7c9a015db8 Catalin Marinas 2020-04-08 146 /* EL0-only MTE is not supported by Linux, don't expose it */
22fba7c9a015db8 Catalin Marinas 2020-04-08 147 if (val < ID_AA64PFR1_MTE)
22fba7c9a015db8 Catalin Marinas 2020-04-08 148 return ID_AA64PFR1_MTE_NI;
22fba7c9a015db8 Catalin Marinas 2020-04-08 149
22fba7c9a015db8 Catalin Marinas 2020-04-08 150 if (memory_checked)
22fba7c9a015db8 Catalin Marinas 2020-04-08 151 return mte_capable ? val : ID_AA64PFR1_MTE_NI;
22fba7c9a015db8 Catalin Marinas 2020-04-08 152
22fba7c9a015db8 Catalin Marinas 2020-04-08 153 if (!acpi_disabled) {
22fba7c9a015db8 Catalin Marinas 2020-04-08 154 pr_warn("MTE not supported on ACPI systems\n");
22fba7c9a015db8 Catalin Marinas 2020-04-08 155 return ID_AA64PFR1_MTE_NI;
22fba7c9a015db8 Catalin Marinas 2020-04-08 156 }
22fba7c9a015db8 Catalin Marinas 2020-04-08 157
22fba7c9a015db8 Catalin Marinas 2020-04-08 158 /* check the DT "memory" nodes for MTE support */
22fba7c9a015db8 Catalin Marinas 2020-04-08 159 for_each_node_by_type(np, "memory") {
22fba7c9a015db8 Catalin Marinas 2020-04-08 160 memory_checked = true;
22fba7c9a015db8 Catalin Marinas 2020-04-08 161 mte_capable &= of_property_read_bool(np, "arm,armv8.5-memtag");
22fba7c9a015db8 Catalin Marinas 2020-04-08 162 }
22fba7c9a015db8 Catalin Marinas 2020-04-08 163
22fba7c9a015db8 Catalin Marinas 2020-04-08 164 if (!memory_checked || !mte_capable) {
22fba7c9a015db8 Catalin Marinas 2020-04-08 165 pr_warn("System memory is not MTE-capable\n");
22fba7c9a015db8 Catalin Marinas 2020-04-08 166 memory_checked = true;
22fba7c9a015db8 Catalin Marinas 2020-04-08 167 mte_capable = false;
22fba7c9a015db8 Catalin Marinas 2020-04-08 168 return ID_AA64PFR1_MTE_NI;
22fba7c9a015db8 Catalin Marinas 2020-04-08 169 }
22fba7c9a015db8 Catalin Marinas 2020-04-08 170
22fba7c9a015db8 Catalin Marinas 2020-04-08 171 return val;
22fba7c9a015db8 Catalin Marinas 2020-04-08 172 }
22fba7c9a015db8 Catalin Marinas 2020-04-08 173 #endif
22fba7c9a015db8 Catalin Marinas 2020-04-08 174
:::::: The code at line 137 was first introduced by commit
:::::: 22fba7c9a015db8fbbb8004e8f82b10767d98de5 arm64: mte: Check the DT memory nodes for MTE support
:::::: TO: Catalin Marinas <catalin.marinas@arm.com>
:::::: CC: Catalin Marinas <catalin.marinas@arm.com>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 71821 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: fix rk3399-puma gmac reset gpio
From: Heiko Stuebner @ 2020-06-03 13:28 UTC (permalink / raw)
To: linux-rockchip
Cc: Heiko Stuebner, klaus.goger, linux-arm-kernel, christoph.muellner
From: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
The puma gmac node currently uses opposite active-values for the
gmac phy reset pin. The gpio-declaration uses active-high while the
separate snps,reset-active-low property marks the pin as active low.
While on the kernel side this works ok, other DT users may get
confused - as seen with uboot right now.
So bring this in line and make both properties match, similar to the
other Rockchip board.
Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
---
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
index 07694b196fdb..531520e771e7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
@@ -157,7 +157,7 @@ &gmac {
phy-mode = "rgmii";
pinctrl-names = "default";
pinctrl-0 = <&rgmii_pins>;
- snps,reset-gpio = <&gpio3 RK_PC0 GPIO_ACTIVE_HIGH>;
+ snps,reset-gpio = <&gpio3 RK_PC0 GPIO_ACTIVE_LOW>;
snps,reset-active-low;
snps,reset-delays-us = <0 10000 50000>;
tx_delay = <0x10>;
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] coresight: tmc: Add shutdown callback for TMC ETR/ETF
From: Mike Leach @ 2020-06-03 13:22 UTC (permalink / raw)
To: Sai Prakash Ranjan
Cc: Mathieu Poirier, Suzuki K Poulose, linux-arm-msm, Coresight ML,
Linux Kernel Mailing List, Stephen Boyd, robin.murphy,
linux-arm-kernel
In-Reply-To: <4a09cd2e054836d85f2e024ca4435e91@codeaurora.org>
Hi Sai,
On Wed, 3 Jun 2020 at 13:14, Sai Prakash Ranjan
<saiprakash.ranjan@codeaurora.org> wrote:
>
> Hi Mike,
>
> On 2020-06-03 16:57, Mike Leach wrote:
> > Hi,
> >
> > On Wed, 3 Jun 2020 at 11:24, Sai Prakash Ranjan
> > <saiprakash.ranjan@codeaurora.org> wrote:
> >>
> >> Hi Mike,
> >>
> >> Thanks again for looking at this.
> >>
> >> On 2020-06-03 03:42, Mike Leach wrote:
> >> [...]
> >>
> >> >>
> >> >> SMMU/IOMMU won't be able to do much here as it is the client's
> >> >> responsiblity to
> >> >> properly shutdown and SMMU device link just makes sure that
> >> >> SMMU(supplier) shutdown is
> >> >> called only after its consumers shutdown callbacks are called.
> >> >
> >> > I think this use case can be handled slightly differently than the
> >> > general requirements for modular CoreSight drivers.
> >> >
> >> > What is needed here is a way of stopping the underlying ETR hardware
> >> > from issuing data to the SMMU, until the entire device has been shut
> >> > down, in a way that does not remove the driver, breaking existing
> >> > references and causing a system crash.
> >> >
> >> > We could introduce a new mode to the ETR driver - e.g.
> >> > CS_MODE_SHUTDOWN.
> >> >
> >> > At the end of the block tmc_shutdown(struct amba_device *adev), set
> >> > drvdata->mode to CS_MODE_SHUTDOWN & remove the coresight_unregister().
> >> > This new mode can be used to prevent the underlying hardware from
> >> > being able to restart until the device is re-powered.
> >> >
> >> > This mode can be detected in the code that enables / disables the ETR
> >> > and handled appropriately (updates to tmc_enable_etr_sink and
> >> > tmc_disable_etr_sink).
> >> > This mode will persist until the device is re-started - but because we
> >> > are on the device shutdown path this is not an issue.
> >> >
> >> > This should leave the CoreSight infrastructure stable until the
> >> > drivers are shut down normally as part of the device power down
> >> > process.
> >> >
> >>
> >> Sounds good to me, but if the coresight_unregister() is the trouble
> >> point
> >> causing these crashes, then can't we just remove that from
> >> tmc_shutdown()
> >> callback? This would be like maintaining the same behaviour as now
> >> where
> >> on reboot/shutdown we basically don't do anything except for disabling
> >> ETR.
> >
> > No - the new mode prevents race conditions where the thread shutting
> > down the SMMU does the ETR shutdown, but then another thread happens
> > to be trying to start trace and restarts the ETR.
> > It also prevents the condition Mathieu discussed where a thread might
> > be attempting to shutdown trace - this could try to disable the
> > hardware again re-releasing resources/ re-flushing and waiting for
> > stop.
> >
>
> I do not think there will a race between SMMU shutdown and ETR shutdown.
> Driver core takes care of calling SMMU shutdown after its consumer
> shutdown callbacks via device link, otherwise there would already be
> bugs in all other client drivers.
>
I am not saying there could be a race between tmc_shutdowm and
Smmu_shutdown - there may be a case if the coresight_disable_path
sequence is running and gets to the point of disabling the ETR after
the SMMU callback has disabled it.
Mike
> Thanks,
> Sai
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member
> of Code Aurora Forum, hosted by The Linux Foundation
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: chenzhou @ 2020-06-03 13:20 UTC (permalink / raw)
To: Prabhakar Kushwaha, John Donnelly
Cc: Devicetree List, Arnd Bergmann, Baoquan He,
Linux Doc Mailing List, Catalin Marinas, Bhupesh Sharma,
RuiRui Yang, kexec mailing list, Linux Kernel Mailing List,
Rob Herring, Simon Horman, James Morse, guohanjun,
Thomas Gleixner, Prabhakar Kushwaha, Will Deacon, Ingo Molnar,
linux-arm-kernel
In-Reply-To: <CAJ2QiJJhUCnobrMHui5=6zLzgy3KsoPxrqiH_oYT8Jhb5MkmbA@mail.gmail.com>
Hi,
On 2020/6/3 19:47, Prabhakar Kushwaha wrote:
> Hi Chen,
>
> On Tue, Jun 2, 2020 at 8:12 PM John Donnelly <john.p.donnelly@oracle.com> wrote:
>>
>>
>>> On Jun 2, 2020, at 12:38 AM, Prabhakar Kushwaha <prabhakar.pkin@gmail.com> wrote:
>>>
>>> On Tue, Jun 2, 2020 at 3:29 AM John Donnelly <john.p.donnelly@oracle.com> wrote:
>>>> Hi . See below !
>>>>
>>>>> On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>>>>>
>>>>> Hi John,
>>>>>
>>>>> On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <John.P.donnelly@oracle.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
>>>>>>> Hi Chen,
>>>>>>>
>>>>>>> On Thu, May 21, 2020 at 3:05 PM Chen Zhou <chenzhou10@huawei.com> wrote:
>>>>>>>> This patch series enable reserving crashkernel above 4G in arm64.
>>>>>>>>
>>>>>>>> There are following issues in arm64 kdump:
>>>>>>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>>>>>>>> when there is no enough low memory.
>>>>>>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>>>>>>>> in this case, if swiotlb or DMA buffers are required, crash dump kernel
>>>>>>>> will boot failure because there is no low memory available for allocation.
>>>>>>>>
>>>>>>> We are getting "warn_alloc" [1] warning during boot of kdump kernel
>>>>>>> with bootargs as [2] of primary kernel.
>>>>>>> This error observed on ThunderX2 ARM64 platform.
>>>>>>>
>>>>>>> It is observed with latest upstream tag (v5.7-rc3) with this patch set
>>>>>>> and https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
>>>>>>> Also **without** this patch-set
>>>>>>> "https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$"
>>>>>>>
>>>>>>> This issue comes whenever crashkernel memory is reserved after 0xc000_0000.
>>>>>>> More details discussed earlier in
>>>>>>> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$ without any
>>>>>>> solution
>>>>>>>
>>>>>>> This patch-set is expected to solve similar kind of issue.
>>>>>>> i.e. low memory is only targeted for DMA, swiotlb; So above mentioned
>>>>>>> observation should be considered/fixed. .
>>>>>>>
>>>>>>> --pk
>>>>>>>
>>>>>>> [1]
>>>>>>> [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
>>>>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>>>>>> [ 30.367696] NET: Registered protocol family 16
>>>>>>> [ 30.369973] swapper/0: page allocation failure: order:6,
>>>>>>> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
>>>>>>> [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc3+ #121
>>>>>>> [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
>>>>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>>>>>> [ 30.369984] Call trace:
>>>>>>> [ 30.369989] dump_backtrace+0x0/0x1f8
>>>>>>> [ 30.369991] show_stack+0x20/0x30
>>>>>>> [ 30.369997] dump_stack+0xc0/0x10c
>>>>>>> [ 30.370001] warn_alloc+0x10c/0x178
>>>>>>> [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0xb50
>>>>>>> [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
>>>>>>> [ 30.370008] alloc_page_interleave+0x24/0x98
>>>>>>> [ 30.370011] alloc_pages_current+0xe4/0x108
>>>>>>> [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
>>>>>>> [ 30.370020] do_one_initcall+0x54/0x228
>>>>>>> [ 30.370027] kernel_init_freeable+0x228/0x2cc
>>>>>>> [ 30.370031] kernel_init+0x1c/0x110
>>>>>>> [ 30.370034] ret_from_fork+0x10/0x18
>>>>>>> [ 30.370036] Mem-Info:
>>>>>>> [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
>>>>>>> [ 30.370064] active_file:0 inactive_file:0 isolated_file:0
>>>>>>> [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
>>>>>>> [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
>>>>>>> [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
>>>>>>> [ 30.370064] free:1537719 free_pcp:219 free_cma:0
>>>>>>> [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
>>>>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
>>>>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
>>>>>>> unstable:0kB all_unreclaimable? no
>>>>>>> [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
>>>>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
>>>>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
>>>>>>> unstable:0kB all_unreclaimable? no
>>>>>>> [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
>>>>>>> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>>>>>>> present:128kB managed:0kB mlocked:0kB kernel_stack:0kB pagetables:0kB
>>>>>>> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>>>>>>> [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
>>>>>>> [ 30.370090] Node 0 DMA32 free:256000kB min:408kB low:664kB
>>>>>>> high:920kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>>>>>>> present:269700kB managed:256000kB mlocked:0kB kernel_stack:0kB
>>>>>>> pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>>>>>>> [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
>>>>>>> [ 30.370100] Node 0 Normal free:5894876kB min:9552kB low:15504kB
>>>>>>> high:21456kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>>>>>>> present:8388608kB managed:5953112kB mlocked:0kB kernel_stack:21672kB
>>>>>>> pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB free_cma:0kB
>>>>>>> [ 30.370104] lowmem_reserve[]: 0 0 0 0
>>>>>>> [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
>>>>>>> 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
>>>>>>> [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
>>>>>>> 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) = 256000kB
>>>>>>> [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB (UE) 3*32kB
>>>>>>> (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME) 3*1024kB (ME)
>>>>>>> 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
>>>>>>> [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
>>>>>>> hugepages_surp=0 hugepages_size=1048576kB
>>>>>>> [ 30.370130] 0 total pagecache pages
>>>>>>> [ 30.370132] 0 pages in swap cache
>>>>>>> [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
>>>>>>> [ 30.370135] Free swap = 0kB
>>>>>>> [ 30.370136] Total swap = 0kB
>>>>>>> [ 30.370137] 2164609 pages RAM
>>>>>>> [ 30.370139] 0 pages HighMem/MovableOnly
>>>>>>> [ 30.370140] 612331 pages reserved
>>>>>>> [ 30.370141] 0 pages hwpoisoned
>>>>>>> [ 30.370143] DMA: failed to allocate 256 KiB pool for atomic
>>>>>>> coherent allocation
>>>>>>
>>>>>> During my testing I saw the same error and Chen's solution corrected it .
>>>>> Which combination you are using on your side? I am using Prabhakar's
>>>>> suggested environment and can reproduce the issue
>>>>> with or without Chen's crashkernel support above 4G patchset.
>>>>>
>>>>> I am also using a ThunderX2 platform with latest makedumpfile code and
>>>>> kexec-tools (with the suggested patch
>>>>> <https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!J6lUig58-Gw6TKZnEEYzEeSU36T-1SqlB1kImU00xtX_lss5Tx-JbUmLE9TJC3foXBLg$ >).
>>>>>
>>>>> Thanks,
>>>>> Bhupesh
>>>>
>>>> I did this activity 5 months ago and I have moved on to other activities. My DMA failures were related to PCI devices that could not be enumerated because low-DMA space was not available when crashkernel was moved above 4G; I don’t recall the exact platform.
>>>>
>>>>
>>>>
>>>> For this failure ,
>>>>
>>>>>>> DMA: failed to allocate 256 KiB pool for atomic
>>>>>>> coherent allocation
>>>>
>>>> Is due to :
>>>>
>>>>
>>>> 3618082c
>>>> ("arm64 use both ZONE_DMA and ZONE_DMA32")
>>>>
>>>> With the introduction of ZONE_DMA to support the Raspberry DMA
>>>> region below 1G, the crashkernel is placed in the upper 4G
>>>> ZONE_DMA_32 region. Since the crashkernel does not have access
>>>> to the ZONE_DMA region, it prints out call trace during bootup.
>>>>
>>>> It is due to having this CONFIG item ON :
>>>>
>>>>
>>>> CONFIG_ZONE_DMA=y
>>>>
>>>> Turning off ZONE_DMA fixes a issue and Raspberry PI 4 will
>>>> use the device tree to specify memory below 1G.
>>>>
>>>>
>>> Disabling ZONE_DMA is temporary solution. We may need proper solution
>>
>> Perhaps the Raspberry platform configuration dependencies need separated from “server class” Arm equipment ? Or auto-configured on boot ? Consult an expert ;-)
>>
>>
>>
>>>> I would like to see Chen’s feature added , perhaps as EXPERIMENTAL, so we can get some configuration testing done on it. It corrects having a DMA zone in low memory while crash-kernel is above 4GB. This has been going on for a year now.
>>> I will also like this patch to be added in Linux as early as possible.
>>>
>>> Issue mentioned by me happens with or without this patch.
>>>
>>> This patch-set can consider fixing because it uses low memory for DMA
>>> & swiotlb only.
>>> We can consider restricting crashkernel within the required range like below
>>>
>>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
>>> index 7f9e5a6dc48c..bd67b90d35bd 100644
>>> --- a/kernel/crash_core.c
>>> +++ b/kernel/crash_core.c
>>> @@ -354,7 +354,7 @@ int __init reserve_crashkernel_low(void)
>>> return 0;
>>> }
>>>
>>> - low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
>>> + low_base = memblock_find_in_range(0,0xc0000000, low_size, CRASH_ALIGN);
>>> if (!low_base) {
>>> pr_err("Cannot reserve %ldMB crashkernel low memory,
>>> please try smaller size.\n",
>>> (unsigned long)(low_size >> 20));
>>>
>>>
>> I suspect 0xc0000000 would need to be a CONFIG item and not hard-coded.
>>
> if you consider this as valid change, can you please incorporate as
> part of your patch-set.
After commit 1a8e1cef7 ("arm64: use both ZONE_DMA and ZONE_DMA32")，the 0-4G memory is splited
to DMA [mem 0x0000000000000000-0x000000003fffffff] and DMA32 [mem 0x0000000040000000-0x00000000ffffffff] on arm64.
From the above discussion, on your platform, the low crashkernel fall in DMA32 region, but your environment needs to access DMA
region, so there is the call trace.
I have a question, why do you choose 0xc0000000 here?
Besides, this is common code, we also need to consider about x86.
Thanks,
Chen Zhou
>
> --pk.
>
> .
>
_______________________________________________
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 032/105] drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable
From: Maxime Ripard @ 2020-06-03 13:14 UTC (permalink / raw)
To: Stefan Wahren
Cc: Tim Gover, Dave Stevenson, LKML, DRI Development, Eric Anholt,
bcm-kernel-feedback-list, linux-arm-kernel, Phil Elwell,
Nicolas Saenz Julienne, linux-rpi-kernel
In-Reply-To: <f0098c06-f892-cc1e-eb75-be48e40f705c@i2se.com>
[-- Attachment #1.1: Type: text/plain, Size: 2826 bytes --]
Hi Stefan,
On Tue, Jun 02, 2020 at 10:03:13PM +0200, Stefan Wahren wrote:
> Am 02.06.20 um 21:31 schrieb Eric Anholt:
> > On Tue, Jun 2, 2020 at 8:02 AM Dave Stevenson
> > <dave.stevenson@raspberrypi.com> wrote:
> >> Hi Maxime and Eric
> >>
> >> On Tue, 2 Jun 2020 at 15:12, Maxime Ripard <maxime@cerno.tech> wrote:
> >>> Hi Eric
> >>>
> >>> On Wed, May 27, 2020 at 09:54:44AM -0700, Eric Anholt wrote:
> >>>> On Wed, May 27, 2020 at 8:50 AM Maxime Ripard <maxime@cerno.tech> wrote:
> >>>>> The VIDEN bit in the pixelvalve currently being used to enable or disable
> >>>>> the pixelvalve seems to not be enough in some situations, which whill end
> >>>>> up with the pixelvalve stalling.
> >>>>>
> >>>>> In such a case, even re-enabling VIDEN doesn't bring it back and we need to
> >>>>> clear the FIFO. This can only be done if the pixelvalve is disabled though.
> >>>>>
> >>>>> In order to overcome this, we can configure the pixelvalve during
> >>>>> mode_set_no_fb, but only enable it in atomic_enable and flush the FIFO
> >>>>> there, and in atomic_disable disable the pixelvalve again.
> >>>> What displays has this been tested with? Getting this sequencing
> >>>> right is so painful, and things like DSI are tricky to get to light
> >>>> up.
> >>> That FIFO is between the HVS and the HDMI PVs, so this was obviously
> >>> tested against that. Dave also tested the DSI output IIRC, so we should
> >>> be covered here.
> >> DSI wasn't working on the first patch set that Maxime sent - I haven't
> >> tested this one as yet but will do so.
> >> DPI was working early on to both an Adafruit 800x480 DPI panel, and
> >> via a VGA666 as VGA.
> >> HDMI is obviously working.
> >> VEC is being ignored now. The clock structure is more restricted than
> >> earlier chips, so to get the required clocks for the VEC without using
> >> fractional divides it compromises the clock that other parts of the
> >> system can run at (IIRC including the ARM). That's why the VEC has to
> >> be explicitly enabled for the firmware to enable it as the only
> >> output. It's annoying, but that's just a restriction of the chip.
> > I'm more concerned with "make sure we don't regress pre-pi4 with this
> > series" than "pi4 displays all work from the beginning"
>
> unfortuntely i can confirm this. With this patch series (using Maxime's
> git repo with multi_v7_defconfig) my Raspberry Pi 3 B hangs up while
> starting X (screen stays black, heartbeat stops, no more output at the
> debug UART). AFAIR v2 didn't had this issue.
Did it happen with a DSI display or something else?
I've been trying to setup the DSI display on an RPi3 today, but noticed
that it looks like there's a regression in next that prevents the HDMI
driver to load entirely (without my patches).
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3] usb: host: xhci-mtk: avoid runtime suspend when removing hcd
From: Macpaul Lin @ 2020-06-03 13:09 UTC (permalink / raw)
To: Chunfeng Yun, Mathias Nyman, Greg Kroah-Hartman, Matthias Brugger,
stable
Cc: Mediatek WSD Upstream, linux-usb, linux-kernel, linux-mediatek,
Macpaul Lin, Macpaul Lin, linux-arm-kernel
In-Reply-To: <ebd32a2b-c4ba-8891-b13e-f6c641a94276@linux.intel.com>
When runtime suspend was enabled, runtime suspend might happened
when xhci is removing hcd. This might cause kernel panic when hcd
has been freed but runtime pm suspend related handle need to
reference it.
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
Reviewed-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
Changes for v3:
- Replace better sequence for disabling the pm_runtime suspend.
drivers/usb/host/xhci-mtk.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index bfbdb3c..641d24e 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -587,6 +587,9 @@ static int xhci_mtk_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct usb_hcd *shared_hcd = xhci->shared_hcd;
+ pm_runtime_put_noidle(&dev->dev);
+ pm_runtime_disable(&dev->dev);
+
usb_remove_hcd(shared_hcd);
xhci->shared_hcd = NULL;
device_init_wakeup(&dev->dev, false);
@@ -597,8 +600,6 @@ static int xhci_mtk_remove(struct platform_device *dev)
xhci_mtk_sch_exit(mtk);
xhci_mtk_clks_disable(mtk);
xhci_mtk_ldos_disable(mtk);
- pm_runtime_put_sync(&dev->dev);
- pm_runtime_disable(&dev->dev);
return 0;
}
--
1.7.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCHv2 0/7] Support inhibiting input devices
From: Andrzej Pietrasiewicz @ 2020-06-03 13:07 UTC (permalink / raw)
To: Hans de Goede, Dmitry Torokhov
Cc: Nick Dyer, linux-iio, Benjamin Tissoires, platform-driver-x86,
ibm-acpi-devel, Laxman Dewangan, Peter Meerwald-Stadler, kernel,
Fabio Estevam, linux-samsung-soc, Krzysztof Kozlowski,
Jonathan Hunter, linux-acpi, Kukjin Kim, NXP Linux Team,
linux-input, Len Brown, Peter Hutterer, Michael Hennerich,
Sascha Hauer, Sylvain Lemieux, Henrique de Moraes Holschuh,
Vladimir Zapolskiy, Lars-Peter Clausen, linux-tegra,
linux-arm-kernel, Barry Song, Ferruh Yigit, patches,
Rafael J . Wysocki, Thierry Reding, Sangwon Jee,
Pengutronix Kernel Team, Hartmut Knaack, Shawn Guo,
Jonathan Cameron
In-Reply-To: <8f97d2e1-497a-495d-bc82-f46dbeba440c@redhat.com>
Hi Hans, hi Dmitry,
W dniu 02.06.2020 o 22:19, Hans de Goede pisze:
> Hi,
>
> On 6/2/20 8:50 PM, Andrzej Pietrasiewicz wrote:
>> Hi Dmitry,
>>
>> W dniu 02.06.2020 o 19:52, Dmitry Torokhov pisze:
>>> Hi Andrzej,
>>>
>>> On Tue, Jun 02, 2020 at 06:56:40PM +0200, Andrzej Pietrasiewicz wrote:
>>>> Hi Dmitry,
>>>>
>>>> W dniu 27.05.2020 o 08:34, Dmitry Torokhov pisze:
>>>>> That said, I think the way we should handle inhibit/uninhibit, is that
>>>>> if we have the callback defined, then we call it, and only call open and
>>>>> close if uninhibit or inhibit are _not_ defined.
>>>>>
>>>>
>>>> If I understand you correctly you suggest to call either inhibit,
>>>> if provided or close, if inhibit is not provided, but not both,
>>>> that is, if both are provided then on the inhibit path only
>>>> inhibit is called. And, consequently, you suggest to call either
>>>> uninhibit or open, but not both. The rest of my mail makes this
>>>> assumption, so kindly confirm if I understand you correctly.
>>>
>>> Yes, that is correct. If a driver wants really fine-grained control, it
>>> will provide inhibit (or both inhibit and close), otherwise it will rely
>>> on close in place of inhibit.
>>>
>>>>
>>>> In my opinion this idea will not work.
>>>>
>>>> The first question is should we be able to inhibit a device
>>>> which is not opened? In my opinion we should, in order to be
>>>> able to inhibit a device in anticipation without needing to
>>>> open it first.
>>>
>>> I agree.
>>>
>>>>
>>>> Then what does opening (with input_open_device()) an inhibited
>>>> device mean? Should it succeed or should it fail?
>>>
>>> It should succeed.
>>>
>>>> If it is not
>>>> the first opening then effectively it boils down to increasing
>>>> device's and handle's counters, so we can allow it to succeed.
>>>> If, however, the device is being opened for the first time,
>>>> the ->open() method wants to be called, but that somehow
>>>> contradicts the device's inhibited state. So a logical thing
>>>> to do is to either fail input_open_device() or postpone ->open()
>>>> invocation to the moment of uninhibiting - and the latter is
>>>> what the patches in this series currently do.
>>>>
>>>> Failing input_open_device() because of the inhibited state is
>>>> not the right thing to do. Let me explain. Suppose that a device
>>>> is already inhibited and then a new matching handler appears
>>>> in the system. Most handlers (apm-power.c, evbug.c, input-leds.c,
>>>> mac_hid.c, sysrq.c, vt/keyboard.c and rfkill/input.c) don't create
>>>> any character devices (only evdev.c, joydev.c and mousedev.c do),
>>>> so for them it makes no sense to delay calling input_open_device()
>>>> and it is called in handler's ->connect(). If input_open_device()
>>>> now fails, we have lost the only chance for this ->connect() to
>>>> succeed.
>>>>
>>>> Summarizing, IMO the uninhibit path should be calling both
>>>> ->open() and ->uninhibit() (if provided), and conversely, the inhibit
>>>> path should be calling both ->inhibit() and ->close() (if provided).
>>>
>>> So what you are trying to say is that you see inhibit as something that
>>> is done in addition to what happens in close. But what exactly do you
>>> want to do in inhibit, in addition to what close is doing?
>>
>> See below (*).
>>
>>>
>>> In my view, if we want to have a dedicated inhibit callback, then it
>>> will do everything that close does, they both are aware of each other
>>> and can sort out the state transitions between them. For drivers that do
>>> not have dedicated inhibit/uninhibit, we can use open and close
>>> handlers, and have input core sort out when each should be called. That
>>> means that we should not call dev->open() in input_open_device() when
>>> device is inhibited (and same for dev->close() in input_close_device).
>>> And when uninhibiting, we should not call dev->open() when there are no
>>> users for the device, and no dev->close() when inhibiting with no users.
>>>
>>> Do you see any problems with this approach?
>>
>> My concern is that if e.g. both ->open() and ->uninhibit() are provided,
>> then in certain circumstances ->open() won't be called:
>>
>> 1. users == 0
>> 2. inhibit happens
>> 3. input_open_device() happens, ->open() not called
>> 4. uninhibit happens
>> 5. as part of uninhibit ->uninhibit() is only called, but ->open() is not.
>>
>> They way I understand your answer is that we implicitly impose requirements
>> on drivers which choose to implement e.g. both ->open() and ->uninhibit():
>> in such a case ->uninhibit() should be doing exactly the same things as
>> ->open() does. Which leads to a conclusion that in practice no drivers
>> should choose to implement both, otherwise they must be aware that
>> ->uninhibit() can be sometimes called instead of ->open(). Then ->open()
>> becomes synonymous with ->uninhibit(), and ->close() with ->inhibit().
>> Or, maybe, then ->inhibit() can be a superset of ->close() and
>> ->uninhibit() a superset of ->open().
>>
>> If such an approach is ok with you, it is ok with me, too.
>>
>> (*)
>> Calling both ->inhibit() and ->close() (if they are provided) allows
>> drivers to go fancy and fail inhibiting (which is impossible using
>> only ->close() as it does not return a value, but ->inhibit() by design
>> does). Then ->uninhibit() is mostly for symmetry.
>
> All the complications discussed above are exactly why I still
> believe that there should be only open and close.
>
> If error propagation on inhibit is considered as something
> really important to have then we can make the input driver close
> callback return an error (*), note I'm talking about the
> driver close callback here, not the system call.
>
> If the close callback is called for actually closing the fd
> referring to the input node, then the new error return code
> can be ignored, as we already do for errors on close atm
> since the driver close callback returns void.
>
> I still have not seen a very convincing argument for having
> separate inhibit and close callbacks and as the messy discussion
> above shows, having 2 such very similar yet subtly different
> calls seems like a bad idea...
>
> Regards,
>
> Hans
>
>
> *) This will require a flag day where "return 0" is added
> to all current close handlers
>
I'm taking one step back and looking at the ->open() and ->close()
driver callbacks. They are called from input_open_device() and
input_close_device(), respectively:
input_open_device():
"This function should be called by input handlers when they
want to start receive events from given input device."
->open() callback:
"this method is called when the very first user calls
input_open_device(). The driver must prepare the device to start
generating events (start polling thread, request an IRQ, submit
URB, etc.)"
input_close_device():
"This function should be called by input handlers when they
want to stop receive events from given input device."
->close() callback:
"this method is called when the very last user calls
input_close_device()"
It seems to me that the callback names do not reflect their
purpose: their meaning is not to "open" or to "close" but to
give drivers a chance to control when they start or stop
providing events to the input core.
What would you say about changing the callbacks' names?
I'd envsion: ->provide_events() instead of ->open() and
->stop_events() instead of ->close(). Of course drivers can
exploit the fact of knowing that nobody wants any events
from them and do whatever they consider appropriate, for
example go into a low power mode - but the latter is beyond
the scope of the input subsystem and is driver-specific.
With such a naming change in mind let's consider inhibiting.
We want to be able to control when to disregard events from
a given device. It makes sense to do it at device level, otherwise
such an operation would have to be invoked in all associated
handlers (those that have an open handle associating them with
the device in question). But of course we can do better than
merely ignoring the events received: we can tell the drivers
that we don't want any events from them, and later, at uninhibit
time, tell them to start providing the events again. Conceptually,
the two operations (provide or don't provide envents) are exactly
the same thing we want to be happening at input_open_device() and
input_close_device() time. To me, changing the names of
->open() and ->close() exposes this fact very well.
Consequently, ->inhibit() and ->uninhibit() won't be needed,
and drivers which already implement ->provide_events() (formerly
->open()) and ->stop_events() (formerly ->close()) will receive
full inhibit/uninhibit support for free (subject to how well they
implement ->provide_events()/->stop_events()). Unless we can come
up with what the drivers might be doing on top of ->stop_events()
and ->provide_events() when inhibiting/uninhibiting, but it seems
to me we can't. Can we?
Optionally ->close() (only the callback, not input_close_device())
can be made return a value, just as Hans suggests. The value
can be ignored in input_close_device() but used in input_inhibit().
No strong opinion here, though. (btw it seems to me that
input_inhibit() should be renamed to input_inhibit_device()).
Regards,
Andrzej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 9/9] mtd: rawnand: Move the user input parsing bits to the ECC framework
From: Boris Brezillon @ 2020-06-03 13:05 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su, Richard Weinberger,
linux-mtd, Thomas Petazzoni, Mason Yang, linux-arm-kernel
In-Reply-To: <20200603145833.3f80ef6d@xps13>
On Wed, 3 Jun 2020 14:58:33 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Boris Brezillon <boris.brezillon@collabora.com> wrote on Tue, 2 Jun
> 2020 18:21:57 +0200:
>
> > On Tue, 2 Jun 2020 16:31:24 +0200
> > Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > > +void nand_ecc_read_user_conf(struct nand_device *nand)
> >
> > This function is not introduced in this patch, but I'm commenting here.
> > Looks like it only operates on an OF node, so how about naming it
> > of_get_nand_ecc_config().
>
> of_get_nand_ecc_user_config()? I'd like to mention "user" because
> "config" is way too vague given the number of possible configuration
> sources.
Works for me.
_______________________________________________
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] usb: host: xhci-mtk: avoid runtime suspend when removing hcd
From: Macpaul Lin @ 2020-06-03 13:01 UTC (permalink / raw)
To: Mathias Nyman
Cc: Mathias Nyman, Mediatek WSD Upstream, Greg Kroah-Hartman,
linux-usb, linux-kernel, Matthias Brugger, linux-mediatek,
Chunfeng Yun, Macpaul Lin, linux-arm-kernel
In-Reply-To: <ebd32a2b-c4ba-8891-b13e-f6c641a94276@linux.intel.com>
On Wed, 2020-06-03 at 14:47 +0300, Mathias Nyman wrote:
> On 29.5.2020 7.29, Macpaul Lin wrote:
> > When runtime suspend was enabled, runtime suspend might happened
> > when xhci is removing hcd. This might cause kernel panic when hcd
> > has been freed but runtime pm suspend related handle need to
> > reference it.
> >
> > Change-Id: I70a5dc8006207caeecbac6955ce8e5345dcc70e6
> > Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> > ---
> > drivers/usb/host/xhci-mtk.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> > index bfbdb3c..641d24e 100644
> > --- a/drivers/usb/host/xhci-mtk.c
> > +++ b/drivers/usb/host/xhci-mtk.c
> > @@ -587,6 +587,9 @@ static int xhci_mtk_remove(struct platform_device *dev)
> > struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> > struct usb_hcd *shared_hcd = xhci->shared_hcd;
> >
> > + pm_runtime_put_sync(&dev->dev);
>
> Might runtime suspend here.
> It's a lot better than before, no panic as hcd isn't released, but a bit unnecessary.
>
> how about this sequence instead:
> pm_runtime_disable()
> pm_runtime_put_noidle()
>
> > + pm_runtime_disable(&dev->dev);
> > +
>
> -Mathias
Thanks for your suggestion!
Will it better to put no idle before disable?
pm_runtime_put_noidle()
pm_runtime_disable()
I've found pm_runtime_put_noidle is called in pm_runtime_disable() when
there is a pending request.
I will send patch v3 as noidle() called earlier than disable(). Please
help to comment it if disable() should go before.
Thanks!
Macpaul Lin
_______________________________________________
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 v9 9/9] mtd: rawnand: Move the user input parsing bits to the ECC framework
From: Miquel Raynal @ 2020-06-03 12:58 UTC (permalink / raw)
To: Boris Brezillon
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su, Richard Weinberger,
linux-mtd, Thomas Petazzoni, Mason Yang, linux-arm-kernel
In-Reply-To: <20200602182157.26716f89@collabora.com>
Boris Brezillon <boris.brezillon@collabora.com> wrote on Tue, 2 Jun
2020 18:21:57 +0200:
> On Tue, 2 Jun 2020 16:31:24 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > +void nand_ecc_read_user_conf(struct nand_device *nand)
>
> This function is not introduced in this patch, but I'm commenting here.
> Looks like it only operates on an OF node, so how about naming it
> of_get_nand_ecc_config().
of_get_nand_ecc_user_config()? I'd like to mention "user" because
"config" is way too vague given the number of possible configuration
sources.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RESEND v7 4/6] mfd: stm32: enable regmap fast_io for stm32-lptimer
From: Benjamin Gaignard @ 2020-06-03 12:54 UTC (permalink / raw)
To: fabrice.gasnier, lee.jones, robh+dt, mcoquelin.stm32,
alexandre.torgue, linux, daniel.lezcano, tglx
Cc: Benjamin Gaignard, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20200603125439.23275-1-benjamin.gaignard@st.com>
Because stm32-lptimer need to write in registers in interrupt context
enable regmap fast_io to use a spin_lock to protect registers access
rather than a mutex.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/stm32-lptimer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/stm32-lptimer.c b/drivers/mfd/stm32-lptimer.c
index a00f99f36559..746e51a17cc8 100644
--- a/drivers/mfd/stm32-lptimer.c
+++ b/drivers/mfd/stm32-lptimer.c
@@ -17,6 +17,7 @@ static const struct regmap_config stm32_lptimer_regmap_cfg = {
.val_bits = 32,
.reg_stride = sizeof(u32),
.max_register = STM32_LPTIM_MAX_REGISTER,
+ .fast_io = true,
};
static int stm32_lptimer_detect_encoder(struct stm32_lptimer *ddata)
--
2.15.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
* [RESEND v7 6/6] ARM: mach-stm32: select low power timer for STM32MP157
From: Benjamin Gaignard @ 2020-06-03 12:54 UTC (permalink / raw)
To: fabrice.gasnier, lee.jones, robh+dt, mcoquelin.stm32,
alexandre.torgue, linux, daniel.lezcano, tglx
Cc: Benjamin Gaignard, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20200603125439.23275-1-benjamin.gaignard@st.com>
Make MACH_STM32MP157 select CLKSRC_STM32_LP to get a broadcast timer.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
arch/arm/mach-stm32/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-stm32/Kconfig b/arch/arm/mach-stm32/Kconfig
index 57699bd8f107..d78f55b7b1d0 100644
--- a/arch/arm/mach-stm32/Kconfig
+++ b/arch/arm/mach-stm32/Kconfig
@@ -46,6 +46,7 @@ if ARCH_MULTI_V7
config MACH_STM32MP157
bool "STMicroelectronics STM32MP157"
select ARM_ERRATA_814220
+ select CLKSRC_STM32_LP
default y
endif # ARMv7-A
--
2.15.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
* [RESEND v7 5/6] clocksource: Add Low Power STM32 timers driver
From: Benjamin Gaignard @ 2020-06-03 12:54 UTC (permalink / raw)
To: fabrice.gasnier, lee.jones, robh+dt, mcoquelin.stm32,
alexandre.torgue, linux, daniel.lezcano, tglx
Cc: devicetree, linux-kernel, Pascal Paillet, Benjamin Gaignard,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200603125439.23275-1-benjamin.gaignard@st.com>
From: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Implement clock event driver using low power STM32 timers.
Low power timer counters running even when CPUs are stopped.
It could be used as clock event broadcaster to wake up CPUs but not like
a clocksource because each it rise an interrupt the counter restart from 0.
Low power timers have a 16 bits counter and a prescaler which allow to
divide the clock per power of 2 to up 128 to target a 32KHz rate.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Pascal Paillet <p.paillet@st.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
drivers/clocksource/Kconfig | 4 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-stm32-lp.c | 221 +++++++++++++++++++++++++++++++++++
3 files changed, 226 insertions(+)
create mode 100644 drivers/clocksource/timer-stm32-lp.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index f2142e6bbea3..22b8d8f1eb40 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -292,6 +292,10 @@ config CLKSRC_STM32
select CLKSRC_MMIO
select TIMER_OF
+config CLKSRC_STM32_LP
+ bool "Low power clocksource for STM32 SoCs"
+ depends on MFD_STM32_LPTIMER || COMPILE_TEST
+
config CLKSRC_MPS2
bool "Clocksource for MPS2 SoCs" if COMPILE_TEST
depends on GENERIC_SCHED_CLOCK
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 641ba5383ab5..69f744135cb5 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_BCM_KONA_TIMER) += bcm_kona_timer.o
obj-$(CONFIG_CADENCE_TTC_TIMER) += timer-cadence-ttc.o
obj-$(CONFIG_CLKSRC_EFM32) += timer-efm32.o
obj-$(CONFIG_CLKSRC_STM32) += timer-stm32.o
+obj-$(CONFIG_CLKSRC_STM32_LP) += timer-stm32-lp.o
obj-$(CONFIG_CLKSRC_EXYNOS_MCT) += exynos_mct.o
obj-$(CONFIG_CLKSRC_LPC32XX) += timer-lpc32xx.o
obj-$(CONFIG_CLKSRC_MPS2) += mps2-timer.o
diff --git a/drivers/clocksource/timer-stm32-lp.c b/drivers/clocksource/timer-stm32-lp.c
new file mode 100644
index 000000000000..0f06b8a337aa
--- /dev/null
+++ b/drivers/clocksource/timer-stm32-lp.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) STMicroelectronics 2019 - All Rights Reserved
+ * Authors: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ * Pascal Paillet <p.paillet@st.com> for STMicroelectronics.
+ */
+
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/mfd/stm32-lptimer.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+#include <linux/pm_wakeirq.h>
+
+#define CFGR_PSC_OFFSET 9
+#define STM32_LP_RATING 1000
+#define STM32_TARGET_CLKRATE (32000 * HZ)
+#define STM32_LP_MAX_PSC 7
+
+struct stm32_lp_private {
+ struct regmap *reg;
+ struct clock_event_device clkevt;
+ unsigned long period;
+ struct device *dev;
+};
+
+static struct stm32_lp_private*
+to_priv(struct clock_event_device *clkevt)
+{
+ return container_of(clkevt, struct stm32_lp_private, clkevt);
+}
+
+static int stm32_clkevent_lp_shutdown(struct clock_event_device *clkevt)
+{
+ struct stm32_lp_private *priv = to_priv(clkevt);
+
+ regmap_write(priv->reg, STM32_LPTIM_CR, 0);
+ regmap_write(priv->reg, STM32_LPTIM_IER, 0);
+ /* clear pending flags */
+ regmap_write(priv->reg, STM32_LPTIM_ICR, STM32_LPTIM_ARRMCF);
+
+ return 0;
+}
+
+static int stm32_clkevent_lp_set_timer(unsigned long evt,
+ struct clock_event_device *clkevt,
+ int is_periodic)
+{
+ struct stm32_lp_private *priv = to_priv(clkevt);
+
+ /* disable LPTIMER to be able to write into IER register*/
+ regmap_write(priv->reg, STM32_LPTIM_CR, 0);
+ /* enable ARR interrupt */
+ regmap_write(priv->reg, STM32_LPTIM_IER, STM32_LPTIM_ARRMIE);
+ /* enable LPTIMER to be able to write into ARR register */
+ regmap_write(priv->reg, STM32_LPTIM_CR, STM32_LPTIM_ENABLE);
+ /* set next event counter */
+ regmap_write(priv->reg, STM32_LPTIM_ARR, evt);
+
+ /* start counter */
+ if (is_periodic)
+ regmap_write(priv->reg, STM32_LPTIM_CR,
+ STM32_LPTIM_CNTSTRT | STM32_LPTIM_ENABLE);
+ else
+ regmap_write(priv->reg, STM32_LPTIM_CR,
+ STM32_LPTIM_SNGSTRT | STM32_LPTIM_ENABLE);
+
+ return 0;
+}
+
+static int stm32_clkevent_lp_set_next_event(unsigned long evt,
+ struct clock_event_device *clkevt)
+{
+ return stm32_clkevent_lp_set_timer(evt, clkevt,
+ clockevent_state_periodic(clkevt));
+}
+
+static int stm32_clkevent_lp_set_periodic(struct clock_event_device *clkevt)
+{
+ struct stm32_lp_private *priv = to_priv(clkevt);
+
+ return stm32_clkevent_lp_set_timer(priv->period, clkevt, true);
+}
+
+static int stm32_clkevent_lp_set_oneshot(struct clock_event_device *clkevt)
+{
+ struct stm32_lp_private *priv = to_priv(clkevt);
+
+ return stm32_clkevent_lp_set_timer(priv->period, clkevt, false);
+}
+
+static irqreturn_t stm32_clkevent_lp_irq_handler(int irq, void *dev_id)
+{
+ struct clock_event_device *clkevt = (struct clock_event_device *)dev_id;
+ struct stm32_lp_private *priv = to_priv(clkevt);
+
+ regmap_write(priv->reg, STM32_LPTIM_ICR, STM32_LPTIM_ARRMCF);
+
+ if (clkevt->event_handler)
+ clkevt->event_handler(clkevt);
+
+ return IRQ_HANDLED;
+}
+
+static void stm32_clkevent_lp_set_prescaler(struct stm32_lp_private *priv,
+ unsigned long *rate)
+{
+ int i;
+
+ for (i = 0; i <= STM32_LP_MAX_PSC; i++) {
+ if (DIV_ROUND_CLOSEST(*rate, 1 << i) < STM32_TARGET_CLKRATE)
+ break;
+ }
+
+ regmap_write(priv->reg, STM32_LPTIM_CFGR, i << CFGR_PSC_OFFSET);
+
+ /* Adjust rate and period given the prescaler value */
+ *rate = DIV_ROUND_CLOSEST(*rate, (1 << i));
+ priv->period = DIV_ROUND_UP(*rate, HZ);
+}
+
+static void stm32_clkevent_lp_init(struct stm32_lp_private *priv,
+ struct device_node *np, unsigned long rate)
+{
+ priv->clkevt.name = np->full_name;
+ priv->clkevt.cpumask = cpu_possible_mask;
+ priv->clkevt.features = CLOCK_EVT_FEAT_PERIODIC |
+ CLOCK_EVT_FEAT_ONESHOT;
+ priv->clkevt.set_state_shutdown = stm32_clkevent_lp_shutdown;
+ priv->clkevt.set_state_periodic = stm32_clkevent_lp_set_periodic;
+ priv->clkevt.set_state_oneshot = stm32_clkevent_lp_set_oneshot;
+ priv->clkevt.set_next_event = stm32_clkevent_lp_set_next_event;
+ priv->clkevt.rating = STM32_LP_RATING;
+
+ clockevents_config_and_register(&priv->clkevt, rate, 0x1,
+ STM32_LPTIM_MAX_ARR);
+}
+
+static int stm32_clkevent_lp_probe(struct platform_device *pdev)
+{
+ struct stm32_lptimer *ddata = dev_get_drvdata(pdev->dev.parent);
+ struct stm32_lp_private *priv;
+ unsigned long rate;
+ int ret, irq;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->reg = ddata->regmap;
+ ret = clk_prepare_enable(ddata->clk);
+ if (ret)
+ return -EINVAL;
+
+ rate = clk_get_rate(ddata->clk);
+ if (!rate) {
+ ret = -EINVAL;
+ goto out_clk_disable;
+ }
+
+ irq = platform_get_irq(to_platform_device(pdev->dev.parent), 0);
+ if (irq <= 0) {
+ ret = irq;
+ goto out_clk_disable;
+ }
+
+ if (of_property_read_bool(pdev->dev.parent->of_node, "wakeup-source")) {
+ ret = device_init_wakeup(&pdev->dev, true);
+ if (ret)
+ goto out_clk_disable;
+
+ ret = dev_pm_set_wake_irq(&pdev->dev, irq);
+ if (ret)
+ goto out_clk_disable;
+ }
+
+ ret = devm_request_irq(&pdev->dev, irq, stm32_clkevent_lp_irq_handler,
+ IRQF_TIMER, pdev->name, &priv->clkevt);
+ if (ret)
+ goto out_clk_disable;
+
+ stm32_clkevent_lp_set_prescaler(priv, &rate);
+
+ stm32_clkevent_lp_init(priv, pdev->dev.parent->of_node, rate);
+
+ priv->dev = &pdev->dev;
+
+ return 0;
+
+out_clk_disable:
+ clk_disable_unprepare(ddata->clk);
+ return ret;
+}
+
+static int stm32_clkevent_lp_remove(struct platform_device *pdev)
+{
+ return -EBUSY; /* cannot unregister clockevent */
+}
+
+static const struct of_device_id stm32_clkevent_lp_of_match[] = {
+ { .compatible = "st,stm32-lptimer-timer", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, stm32_clkevent_lp_of_match);
+
+static struct platform_driver stm32_clkevent_lp_driver = {
+ .probe = stm32_clkevent_lp_probe,
+ .remove = stm32_clkevent_lp_remove,
+ .driver = {
+ .name = "stm32-lptimer-timer",
+ .of_match_table = of_match_ptr(stm32_clkevent_lp_of_match),
+ },
+};
+module_platform_driver(stm32_clkevent_lp_driver);
+
+MODULE_ALIAS("platform:stm32-lptimer-timer");
+MODULE_DESCRIPTION("STMicroelectronics STM32 clockevent low power driver");
+MODULE_LICENSE("GPL v2");
--
2.15.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
* [RESEND v7 1/6] dt-bindings: mfd: Document STM32 low power timer bindings
From: Benjamin Gaignard @ 2020-06-03 12:54 UTC (permalink / raw)
To: fabrice.gasnier, lee.jones, robh+dt, mcoquelin.stm32,
alexandre.torgue, linux, daniel.lezcano, tglx
Cc: Benjamin Gaignard, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20200603125439.23275-1-benjamin.gaignard@st.com>
Add a subnode to STM low power timer bindings to support timer driver
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml
index ddf190cb800b..2a99b2296d2b 100644
--- a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml
@@ -33,6 +33,9 @@ properties:
items:
- const: mux
+ interrupts:
+ maxItems: 1
+
"#address-cells":
const: 1
@@ -106,11 +109,13 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/clock/stm32mp1-clks.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
timer@40002400 {
compatible = "st,stm32-lptimer";
reg = <0x40002400 0x400>;
clocks = <&timer_clk>;
clock-names = "mux";
+ interrupts-extended = <&exti 47 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
--
2.15.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
* [RESEND v7 2/6] ARM: dts: stm32: Add timer subnodes on stm32mp15 SoCs
From: Benjamin Gaignard @ 2020-06-03 12:54 UTC (permalink / raw)
To: fabrice.gasnier, lee.jones, robh+dt, mcoquelin.stm32,
alexandre.torgue, linux, daniel.lezcano, tglx
Cc: Benjamin Gaignard, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20200603125439.23275-1-benjamin.gaignard@st.com>
Add timer subnode and interrupts to low power timer nodes for
all stm32mp15x SoCs.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
arch/arm/boot/dts/stm32mp151.dtsi | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp151.dtsi b/arch/arm/boot/dts/stm32mp151.dtsi
index 3ea05ba48215..5e881e8d0f58 100644
--- a/arch/arm/boot/dts/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/stm32mp151.dtsi
@@ -359,6 +359,8 @@
reg = <0x40009000 0x400>;
clocks = <&rcc LPTIM1_K>;
clock-names = "mux";
+ interrupts-extended = <&exti 47 IRQ_TYPE_LEVEL_HIGH>;
+ wakeup-source;
status = "disabled";
pwm {
@@ -377,6 +379,11 @@
compatible = "st,stm32-lptimer-counter";
status = "disabled";
};
+
+ timer {
+ compatible = "st,stm32-lptimer-timer";
+ status = "disabled";
+ };
};
spi2: spi@4000b000 {
@@ -1144,6 +1151,8 @@
reg = <0x50021000 0x400>;
clocks = <&rcc LPTIM2_K>;
clock-names = "mux";
+ interrupts-extended = <&exti 48 IRQ_TYPE_LEVEL_HIGH>;
+ wakeup-source;
status = "disabled";
pwm {
@@ -1162,6 +1171,11 @@
compatible = "st,stm32-lptimer-counter";
status = "disabled";
};
+
+ timer {
+ compatible = "st,stm32-lptimer-timer";
+ status = "disabled";
+ };
};
lptimer3: timer@50022000 {
@@ -1171,6 +1185,8 @@
reg = <0x50022000 0x400>;
clocks = <&rcc LPTIM3_K>;
clock-names = "mux";
+ interrupts-extended = <&exti 50 IRQ_TYPE_LEVEL_HIGH>;
+ wakeup-source;
status = "disabled";
pwm {
@@ -1184,6 +1200,11 @@
reg = <2>;
status = "disabled";
};
+
+ timer {
+ compatible = "st,stm32-lptimer-timer";
+ status = "disabled";
+ };
};
lptimer4: timer@50023000 {
@@ -1191,6 +1212,8 @@
reg = <0x50023000 0x400>;
clocks = <&rcc LPTIM4_K>;
clock-names = "mux";
+ interrupts-extended = <&exti 52 IRQ_TYPE_LEVEL_HIGH>;
+ wakeup-source;
status = "disabled";
pwm {
@@ -1198,6 +1221,11 @@
#pwm-cells = <3>;
status = "disabled";
};
+
+ timer {
+ compatible = "st,stm32-lptimer-timer";
+ status = "disabled";
+ };
};
lptimer5: timer@50024000 {
@@ -1205,6 +1233,8 @@
reg = <0x50024000 0x400>;
clocks = <&rcc LPTIM5_K>;
clock-names = "mux";
+ interrupts-extended = <&exti 53 IRQ_TYPE_LEVEL_HIGH>;
+ wakeup-source;
status = "disabled";
pwm {
@@ -1212,6 +1242,11 @@
#pwm-cells = <3>;
status = "disabled";
};
+
+ timer {
+ compatible = "st,stm32-lptimer-timer";
+ status = "disabled";
+ };
};
vrefbuf: vrefbuf@50025000 {
--
2.15.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
* [RESEND v7 0/6] clockevent: add low power STM32 timer
From: Benjamin Gaignard @ 2020-06-03 12:54 UTC (permalink / raw)
To: fabrice.gasnier, lee.jones, robh+dt, mcoquelin.stm32,
alexandre.torgue, linux, daniel.lezcano, tglx
Cc: Benjamin Gaignard, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel
This series add low power timer as boadcast clockevent device.
Low power timer could runs even when CPUs are in idle mode and
could wakeup them.
Lee has acked the MFD part.
Clocksource driver still need to be reviewed by maintainers.
Add missing part of the bindings to describe interrupt.
version 7 resend:
- with Daniel ack for driver patch
- with Rob review for bindings patch
version 7:
- rebased on top of v5.7-rc2
version 6:
- simplify binding, DT and code to use only one interrupt
version 5:
- document interrupts and interrupt-names bindings
- use a different wake up interrupt
- add device-tree patch
- make STM32MP157 select low power timer configuration flag
- enable fast_io in regmap configuration
version 4:
- move defines in mfd/stm32-lptimer.h
- change compatible and subnode names
- document wakeup-source property
- reword commit message
- make driver Kconfig depends of MFD_STM32_LPTIMER
- remove useless include
- remove rate and clk fields from the private structure
- to add comments about the registers sequence in stm32_clkevent_lp_set_timer
- rework probe function and use devm_request_irq()
- do not allow module to be removed
version 3:
- fix timer set sequence
- don't forget to free irq on remove function
- use devm_kzalloc to simplify errors handling in probe function
version 2:
- stm32 clkevent driver is now a child of the stm32 lp timer node
- add a probe function and adpat the driver to use regmap provide
by it parent
- stop using timer_of helpers
Benjamin Gaignard (6):
dt-bindings: mfd: Document STM32 low power timer bindings
ARM: dts: stm32: Add timer subnodes on stm32mp15 SoCs
mfd: stm32: Add defines to be used for clkevent purpose
mfd: stm32: enable regmap fast_io for stm32-lptimer
clocksource: Add Low Power STM32 timers driver
ARM: mach-stm32: select low power timer for STM32MP157
.../devicetree/bindings/mfd/st,stm32-lptimer.yaml | 5 +
arch/arm/boot/dts/stm32mp151.dtsi | 35 ++++
arch/arm/mach-stm32/Kconfig | 1 +
drivers/clocksource/Kconfig | 4 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-stm32-lp.c | 221 +++++++++++++++++++++
drivers/mfd/stm32-lptimer.c | 1 +
include/linux/mfd/stm32-lptimer.h | 5 +
8 files changed, 273 insertions(+)
create mode 100644 drivers/clocksource/timer-stm32-lp.c
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RESEND v7 3/6] mfd: stm32: Add defines to be used for clkevent purpose
From: Benjamin Gaignard @ 2020-06-03 12:54 UTC (permalink / raw)
To: fabrice.gasnier, lee.jones, robh+dt, mcoquelin.stm32,
alexandre.torgue, linux, daniel.lezcano, tglx
Cc: Benjamin Gaignard, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20200603125439.23275-1-benjamin.gaignard@st.com>
Add defines to be able to enable/clear irq and configure one shot mode.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
include/linux/mfd/stm32-lptimer.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/mfd/stm32-lptimer.h b/include/linux/mfd/stm32-lptimer.h
index 605f62264825..90b20550c1c8 100644
--- a/include/linux/mfd/stm32-lptimer.h
+++ b/include/linux/mfd/stm32-lptimer.h
@@ -27,10 +27,15 @@
#define STM32_LPTIM_CMPOK BIT(3)
/* STM32_LPTIM_ICR - bit fields */
+#define STM32_LPTIM_ARRMCF BIT(1)
#define STM32_LPTIM_CMPOKCF_ARROKCF GENMASK(4, 3)
+/* STM32_LPTIM_IER - bit flieds */
+#define STM32_LPTIM_ARRMIE BIT(1)
+
/* STM32_LPTIM_CR - bit fields */
#define STM32_LPTIM_CNTSTRT BIT(2)
+#define STM32_LPTIM_SNGSTRT BIT(1)
#define STM32_LPTIM_ENABLE BIT(0)
/* STM32_LPTIM_CFGR - bit fields */
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] sound: usb: pcm: fix incorrect power state when playing sound after PM_AUTO suspend
From: Macpaul Lin @ 2020-06-03 12:39 UTC (permalink / raw)
To: Takashi Iwai
Cc: alsa-devel, Szabolcs Szőke, Mediatek WSD Upstream,
Greg Kroah-Hartman, linux-usb, Takashi Iwai, stable, linux-kernel,
Hui Wang, Alexander Tsoy, linux-mediatek, Matthias Brugger,
Johan Hovold, Jaroslav Kysela, Macpaul Lin, linux-arm-kernel
In-Reply-To: <s5h367cfsga.wl-tiwai@suse.de>
On Wed, 2020-06-03 at 10:45 +0200, Takashi Iwai wrote:
> On Wed, 03 Jun 2020 08:54:51 +0200,
> Takashi Iwai wrote:
> >
> > On Wed, 03 Jun 2020 08:28:09 +0200,
> > Takashi Iwai wrote:
> > >
> > > And, the most suspicious case is the last one,
> > > chip->num_suspended-intf. It means that the device has multiple
> > > USB interfaces and they went to suspend, while the resume isn't
> > > performed for the all suspended interfaces in return.
> >
> > If this is the cause, a patch like below might help.
> > It gets/puts the all assigned interfaced instead of only the primary
> > one.
>
> ... and considering of the problem again, rather the patch below might
> be the right answer. Now the driver tries to remember at which state
> it entered into the system-suspend. Upon resume, in return, when the
> state reaches back to that point, set the card state to D0.
>
> The previous patch can be applied on the top, too, and it might be
> worth to apply both.
>
> Let me know if any of those actually helps.
>
>
> Takashi
Thanks for your response so quickly.
I've just test this patch since it looks like enough for the issue.
This patch worked since the flag system_suspend will be set at the same
time when power state has been changed. I have 2 interface with the head
set. But actually the problem happened when primary one is suspended.
So I didn't test the earlier patch "suspend all interface instead of
only the primary one."
Will you resend this patch officially later? I think this solution is
required to send to stable, too. It's better to have it for other stable
kernel versions include android's.
> ---
> diff --git a/sound/usb/card.c b/sound/usb/card.c
> --- a/sound/usb/card.c
> +++ b/sound/usb/card.c
> @@ -843,9 +843,6 @@ static int usb_audio_suspend(struct usb_interface *intf, pm_message_t message)
> if (chip == (void *)-1L)
> return 0;
>
> - chip->autosuspended = !!PMSG_IS_AUTO(message);
> - if (!chip->autosuspended)
> - snd_power_change_state(chip->card, SNDRV_CTL_POWER_D3hot);
> if (!chip->num_suspended_intf++) {
> list_for_each_entry(as, &chip->pcm_list, list) {
> snd_usb_pcm_suspend(as);
> @@ -858,6 +855,11 @@ static int usb_audio_suspend(struct usb_interface *intf, pm_message_t message)
> snd_usb_mixer_suspend(mixer);
> }
>
> + if (!PMSG_IS_AUTO(message) && !chip->system_suspend) {
> + snd_power_change_state(chip->card, SNDRV_CTL_POWER_D3hot);
> + chip->system_suspend = chip->num_suspended_intf;
> + }
> +
> return 0;
> }
>
> @@ -871,10 +873,10 @@ static int __usb_audio_resume(struct usb_interface *intf, bool reset_resume)
>
> if (chip == (void *)-1L)
> return 0;
> - if (--chip->num_suspended_intf)
> - return 0;
>
> atomic_inc(&chip->active); /* avoid autopm */
> + if (chip->num_suspended_intf > 1)
> + goto out;
>
> list_for_each_entry(as, &chip->pcm_list, list) {
> err = snd_usb_pcm_resume(as);
> @@ -896,9 +898,12 @@ static int __usb_audio_resume(struct usb_interface *intf, bool reset_resume)
> snd_usbmidi_resume(p);
> }
>
> - if (!chip->autosuspended)
> + out:
> + if (chip->num_suspended_intf == chip->system_suspend) {
> snd_power_change_state(chip->card, SNDRV_CTL_POWER_D0);
> - chip->autosuspended = 0;
> + chip->system_suspend = 0;
> + }
> + chip->num_suspended_intf--;
>
> err_out:
> atomic_dec(&chip->active); /* allow autopm after this point */
> diff --git a/sound/usb/usbaudio.h b/sound/usb/usbaudio.h
> index 1c892c7f14d7..e0ebfb25fbd5 100644
> --- a/sound/usb/usbaudio.h
> +++ b/sound/usb/usbaudio.h
> @@ -26,7 +26,7 @@ struct snd_usb_audio {
> struct usb_interface *pm_intf;
> u32 usb_id;
> struct mutex mutex;
> - unsigned int autosuspended:1;
> + unsigned int system_suspend;
> atomic_t active;
> atomic_t shutdown;
> atomic_t usage_count;
>
> _______________________________________________
Thank you very much!
Best regards,
Macpaul Lin
_______________________________________________
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] sound: usb: pcm: fix incorrect power state when playing sound after PM_AUTO suspend
From: Takashi Iwai @ 2020-06-03 12:47 UTC (permalink / raw)
To: Macpaul Lin
Cc: alsa-devel, Szabolcs Szőke, Mediatek WSD Upstream,
Greg Kroah-Hartman, linux-usb, Takashi Iwai, stable, linux-kernel,
Hui Wang, Alexander Tsoy, linux-mediatek, Matthias Brugger,
Johan Hovold, Jaroslav Kysela, Macpaul Lin, linux-arm-kernel
In-Reply-To: <1591187964.23525.61.camel@mtkswgap22>
On Wed, 03 Jun 2020 14:39:24 +0200,
Macpaul Lin wrote:
>
> On Wed, 2020-06-03 at 10:45 +0200, Takashi Iwai wrote:
> > On Wed, 03 Jun 2020 08:54:51 +0200,
> > Takashi Iwai wrote:
> > >
> > > On Wed, 03 Jun 2020 08:28:09 +0200,
> > > Takashi Iwai wrote:
> > > >
> > > > And, the most suspicious case is the last one,
> > > > chip->num_suspended-intf. It means that the device has multiple
> > > > USB interfaces and they went to suspend, while the resume isn't
> > > > performed for the all suspended interfaces in return.
> > >
> > > If this is the cause, a patch like below might help.
> > > It gets/puts the all assigned interfaced instead of only the primary
> > > one.
> >
> > ... and considering of the problem again, rather the patch below might
> > be the right answer. Now the driver tries to remember at which state
> > it entered into the system-suspend. Upon resume, in return, when the
> > state reaches back to that point, set the card state to D0.
> >
> > The previous patch can be applied on the top, too, and it might be
> > worth to apply both.
> >
> > Let me know if any of those actually helps.
> >
> >
> > Takashi
>
> Thanks for your response so quickly.
> I've just test this patch since it looks like enough for the issue.
Good to hear!
> This patch worked since the flag system_suspend will be set at the same
> time when power state has been changed. I have 2 interface with the head
> set. But actually the problem happened when primary one is suspended.
Currently the autosuspend is set only to the primary interface; IOW,
the other interfaces will never get autosuspend, and the another
suspend-all-intf patch should improve that situation. But it won't
fix your actual bug, obviously :)
> So I didn't test the earlier patch "suspend all interface instead of
> only the primary one."
Could you try it one on top of the last patch? At least I'd like to
see whether it causes any regression.
> Will you resend this patch officially later? I think this solution is
> required to send to stable, too. It's better to have it for other stable
> kernel versions include android's.
Yes, that's a general bug and worth to be merged quickly.
I'm going to submit a proper patch soon later.
thanks,
Takashi
>
> > ---
> > diff --git a/sound/usb/card.c b/sound/usb/card.c
> > --- a/sound/usb/card.c
> > +++ b/sound/usb/card.c
> > @@ -843,9 +843,6 @@ static int usb_audio_suspend(struct usb_interface *intf, pm_message_t message)
> > if (chip == (void *)-1L)
> > return 0;
> >
> > - chip->autosuspended = !!PMSG_IS_AUTO(message);
> > - if (!chip->autosuspended)
> > - snd_power_change_state(chip->card, SNDRV_CTL_POWER_D3hot);
> > if (!chip->num_suspended_intf++) {
> > list_for_each_entry(as, &chip->pcm_list, list) {
> > snd_usb_pcm_suspend(as);
> > @@ -858,6 +855,11 @@ static int usb_audio_suspend(struct usb_interface *intf, pm_message_t message)
> > snd_usb_mixer_suspend(mixer);
> > }
> >
> > + if (!PMSG_IS_AUTO(message) && !chip->system_suspend) {
> > + snd_power_change_state(chip->card, SNDRV_CTL_POWER_D3hot);
> > + chip->system_suspend = chip->num_suspended_intf;
> > + }
> > +
> > return 0;
> > }
> >
> > @@ -871,10 +873,10 @@ static int __usb_audio_resume(struct usb_interface *intf, bool reset_resume)
> >
> > if (chip == (void *)-1L)
> > return 0;
> > - if (--chip->num_suspended_intf)
> > - return 0;
> >
> > atomic_inc(&chip->active); /* avoid autopm */
> > + if (chip->num_suspended_intf > 1)
> > + goto out;
> >
> > list_for_each_entry(as, &chip->pcm_list, list) {
> > err = snd_usb_pcm_resume(as);
> > @@ -896,9 +898,12 @@ static int __usb_audio_resume(struct usb_interface *intf, bool reset_resume)
> > snd_usbmidi_resume(p);
> > }
> >
> > - if (!chip->autosuspended)
> > + out:
> > + if (chip->num_suspended_intf == chip->system_suspend) {
> > snd_power_change_state(chip->card, SNDRV_CTL_POWER_D0);
> > - chip->autosuspended = 0;
> > + chip->system_suspend = 0;
> > + }
> > + chip->num_suspended_intf--;
> >
> > err_out:
> > atomic_dec(&chip->active); /* allow autopm after this point */
> > diff --git a/sound/usb/usbaudio.h b/sound/usb/usbaudio.h
> > index 1c892c7f14d7..e0ebfb25fbd5 100644
> > --- a/sound/usb/usbaudio.h
> > +++ b/sound/usb/usbaudio.h
> > @@ -26,7 +26,7 @@ struct snd_usb_audio {
> > struct usb_interface *pm_intf;
> > u32 usb_id;
> > struct mutex mutex;
> > - unsigned int autosuspended:1;
> > + unsigned int system_suspend;
> > atomic_t active;
> > atomic_t shutdown;
> > atomic_t usage_count;
> >
> > _______________________________________________
>
> Thank you very much!
>
> Best regards,
> Macpaul Lin
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 3/3] ARM: dts: stm32: Set DCMI frequency requirement for stm32mp15x
From: Benjamin Gaignard @ 2020-06-03 12:45 UTC (permalink / raw)
To: hugues.fruchet, mchehab, mcoquelin.stm32, alexandre.torgue
Cc: Benjamin Gaignard, rjw, linux-kernel, linux-stm32,
valentin.schneider, linux-arm-kernel, linux-media
In-Reply-To: <20200603124559.22652-1-benjamin.gaignard@st.com>
Make sure that CPUs will at least run at 650Mhz when streaming
sensor frames.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
arch/arm/boot/dts/stm32mp151.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/stm32mp151.dtsi b/arch/arm/boot/dts/stm32mp151.dtsi
index 3ea05ba48215..f6d7bf4f8231 100644
--- a/arch/arm/boot/dts/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/stm32mp151.dtsi
@@ -1091,6 +1091,7 @@
clock-names = "mclk";
dmas = <&dmamux1 75 0x400 0x0d>;
dma-names = "tx";
+ st,stm32-dcmi-min-frequency = <650000>;
status = "disabled";
};
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/3] DCMI set minimum cpufreq requirement
From: Benjamin Gaignard @ 2020-06-03 12:45 UTC (permalink / raw)
To: hugues.fruchet, mchehab, mcoquelin.stm32, alexandre.torgue
Cc: Benjamin Gaignard, rjw, linux-kernel, linux-stm32,
valentin.schneider, linux-arm-kernel, linux-media
This series allow to STM32 camera interface (DCMI) to require a minimum
frequency to the CPUs before start streaming frames from the sensor.
The minimum frequency requirement is provided in the devide-tree node.
Setting a minimum frequency for the CPUs is needed to ensure a quick handling
of the interrupts between two sensor frames and avoid dropping half of them.
Benjamin Gaignard (3):
dt-bindings: media: stm32-dcmi: Add DCMI min frequency property
media: stm32-dcmi: Set minimum cpufreq requirement
ARM: dts: stm32: Set DCMI frequency requirement for stm32mp15x
.../devicetree/bindings/media/st,stm32-dcmi.yaml | 8 ++
arch/arm/boot/dts/stm32mp151.dtsi | 1 +
drivers/media/platform/stm32/stm32-dcmi.c | 90 ++++++++++++++++++++--
3 files changed, 91 insertions(+), 8 deletions(-)
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/3] media: stm32-dcmi: Set minimum cpufreq requirement
From: Benjamin Gaignard @ 2020-06-03 12:45 UTC (permalink / raw)
To: hugues.fruchet, mchehab, mcoquelin.stm32, alexandre.torgue
Cc: Benjamin Gaignard, rjw, linux-kernel, linux-stm32,
valentin.schneider, linux-arm-kernel, linux-media
In-Reply-To: <20200603124559.22652-1-benjamin.gaignard@st.com>
Before start streaming set cpufreq minimum frequency requirement.
The cpufreq governor will adapt the frequencies and we will have
no latency for handling interrupts.
The frequency requirement is retrieved from the device-tree node.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
drivers/media/platform/stm32/stm32-dcmi.c | 90 ++++++++++++++++++++++++++++---
1 file changed, 82 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index b8931490b83b..1b9f24986694 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -13,10 +13,12 @@
#include <linux/clk.h>
#include <linux/completion.h>
+#include <linux/cpufreq.h>
#include <linux/delay.h>
#include <linux/dmaengine.h>
#include <linux/init.h>
#include <linux/interrupt.h>
+#include <linux/irq.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
@@ -99,6 +101,9 @@ enum state {
#define OVERRUN_ERROR_THRESHOLD 3
+static DEFINE_PER_CPU(struct cpufreq_policy *, policy);
+static DEFINE_PER_CPU(struct freq_qos_request, qos_req);
+
struct dcmi_graph_entity {
struct v4l2_async_subdev asd;
@@ -133,6 +138,7 @@ struct stm32_dcmi {
struct resource *res;
struct reset_control *rstc;
int sequence;
+ int irq;
struct list_head buffers;
struct dcmi_buf *active;
@@ -173,6 +179,8 @@ struct stm32_dcmi {
struct media_device mdev;
struct media_pad vid_cap_pad;
struct media_pipeline pipeline;
+
+ u32 min_frequency;
};
static inline struct stm32_dcmi *notifier_to_dcmi(struct v4l2_async_notifier *n)
@@ -722,6 +730,62 @@ static void dcmi_pipeline_stop(struct stm32_dcmi *dcmi)
dcmi_pipeline_s_stream(dcmi, 0);
}
+static void dcmi_get_min_frequency(struct stm32_dcmi *dcmi)
+{
+ struct device_node *np = dcmi->mdev.dev->of_node;
+
+ dcmi->min_frequency = FREQ_QOS_MIN_DEFAULT_VALUE;
+
+ of_property_read_u32(np, "st,stm32-dcmi-min-frequency",
+ &dcmi->min_frequency);
+}
+
+static void dcmi_get_cpu_policy(struct stm32_dcmi *dcmi)
+{
+ struct cpufreq_policy *p;
+ int cpu;
+
+ for_each_cpu(cpu, irq_get_affinity_mask(dcmi->irq)) {
+ p = cpufreq_cpu_get(cpu);
+ if (!p)
+ continue;
+
+ freq_qos_add_request(&p->constraints, &per_cpu(qos_req, cpu),
+ FREQ_QOS_MIN, FREQ_QOS_MIN_DEFAULT_VALUE);
+
+ per_cpu(policy, cpu) = p;
+ }
+}
+
+static void dcmi_put_cpu_policy(struct stm32_dcmi *dcmi)
+{
+ struct cpufreq_policy *p;
+ int cpu;
+
+ for_each_cpu(cpu, irq_get_affinity_mask(dcmi->irq)) {
+ p = per_cpu(policy, cpu);
+ if (!p)
+ continue;
+
+ freq_qos_remove_request(&per_cpu(qos_req, cpu));
+ cpufreq_cpu_put(p);
+ }
+}
+
+static void dcmi_set_min_frequency(struct stm32_dcmi *dcmi, u64 freq)
+{
+ struct cpufreq_policy *p;
+ int cpu;
+
+ for_each_cpu(cpu, irq_get_affinity_mask(dcmi->irq)) {
+ p = per_cpu(policy, cpu);
+ if (!p)
+ continue;
+
+ freq_qos_update_request(&per_cpu(qos_req, cpu), freq);
+ }
+}
+
static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct stm32_dcmi *dcmi = vb2_get_drv_priv(vq);
@@ -736,11 +800,13 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
goto err_release_buffers;
}
+ dcmi_set_min_frequency(dcmi, dcmi->min_frequency);
+
ret = media_pipeline_start(&dcmi->vdev->entity, &dcmi->pipeline);
if (ret < 0) {
dev_err(dcmi->dev, "%s: Failed to start streaming, media pipeline start error (%d)\n",
__func__, ret);
- goto err_pm_put;
+ goto err_drop_qos;
}
ret = dcmi_pipeline_start(dcmi);
@@ -835,7 +901,8 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
err_media_pipeline_stop:
media_pipeline_stop(&dcmi->vdev->entity);
-err_pm_put:
+err_drop_qos:
+ dcmi_set_min_frequency(dcmi, FREQ_QOS_MIN_DEFAULT_VALUE);
pm_runtime_put(dcmi->dev);
err_release_buffers:
@@ -863,6 +930,8 @@ static void dcmi_stop_streaming(struct vb2_queue *vq)
media_pipeline_stop(&dcmi->vdev->entity);
+ dcmi_set_min_frequency(dcmi, FREQ_QOS_MIN_DEFAULT_VALUE);
+
spin_lock_irq(&dcmi->irqlock);
/* Disable interruptions */
@@ -1838,7 +1907,6 @@ static int dcmi_probe(struct platform_device *pdev)
struct vb2_queue *q;
struct dma_chan *chan;
struct clk *mclk;
- int irq;
int ret = 0;
match = of_match_device(of_match_ptr(stm32_dcmi_of_match), &pdev->dev);
@@ -1879,9 +1947,9 @@ static int dcmi_probe(struct platform_device *pdev)
dcmi->bus.bus_width = ep.bus.parallel.bus_width;
dcmi->bus.data_shift = ep.bus.parallel.data_shift;
- irq = platform_get_irq(pdev, 0);
- if (irq <= 0)
- return irq ? irq : -ENXIO;
+ dcmi->irq = platform_get_irq(pdev, 0);
+ if (dcmi->irq <= 0)
+ return dcmi->irq ? dcmi->irq : -ENXIO;
dcmi->res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!dcmi->res) {
@@ -1895,11 +1963,12 @@ static int dcmi_probe(struct platform_device *pdev)
return PTR_ERR(dcmi->regs);
}
- ret = devm_request_threaded_irq(&pdev->dev, irq, dcmi_irq_callback,
+ ret = devm_request_threaded_irq(&pdev->dev, dcmi->irq,
+ dcmi_irq_callback,
dcmi_irq_thread, IRQF_ONESHOT,
dev_name(&pdev->dev), dcmi);
if (ret) {
- dev_err(&pdev->dev, "Unable to request irq %d\n", irq);
+ dev_err(&pdev->dev, "Unable to request irq %d\n", dcmi->irq);
return ret;
}
@@ -2022,6 +2091,9 @@ static int dcmi_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "Probe done\n");
+ dcmi_get_min_frequency(dcmi);
+ dcmi_get_cpu_policy(dcmi);
+
platform_set_drvdata(pdev, dcmi);
pm_runtime_enable(&pdev->dev);
@@ -2049,6 +2121,8 @@ static int dcmi_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
+ dcmi_put_cpu_policy(dcmi);
+
v4l2_async_notifier_unregister(&dcmi->notifier);
v4l2_async_notifier_cleanup(&dcmi->notifier);
media_entity_cleanup(&dcmi->vdev->entity);
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: media: stm32-dcmi: Add DCMI min frequency property
From: Benjamin Gaignard @ 2020-06-03 12:45 UTC (permalink / raw)
To: hugues.fruchet, mchehab, mcoquelin.stm32, alexandre.torgue
Cc: Benjamin Gaignard, rjw, linux-kernel, linux-stm32,
valentin.schneider, linux-arm-kernel, linux-media
In-Reply-To: <20200603124559.22652-1-benjamin.gaignard@st.com>
Document st,stm32-dcmi-min-frequency property which is used to
request CPUs minimum frequency when streaming frames.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
index 3fe778cb5cc3..05ca85a2411a 100644
--- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
@@ -44,6 +44,13 @@ properties:
bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
+ st,stm32-dcmi-min-frequency:
+ description: DCMI minimum CPUs frequency requirement (in KHz).
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - minimum: 0
+ - default: 0
+
required:
- compatible
- reg
@@ -71,6 +78,7 @@ examples:
clock-names = "mclk";
dmas = <&dmamux1 75 0x400 0x0d>;
dma-names = "tx";
+ st,stm32-dcmi-min-frequency = <650000>;
port {
dcmi_0: endpoint {
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq
From: Marc Zyngier @ 2020-06-03 12:44 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Herrenschmidt, Benjamin, jason, Machulsky, Zorik, linux-kernel,
Saidi, Ali, Zilberman, Zeev, Woodhouse, David, linux-arm-kernel
In-Reply-To: <87y2p5fatl.fsf@nanos.tec.linutronix.de>
On 2020-06-02 21:54, Thomas Gleixner wrote:
> "Herrenschmidt, Benjamin" <benh@amazon.com> writes:
>> On Sun, 2020-05-31 at 12:09 +0100, Marc Zyngier wrote:
>>> > The semantic of activate/deactivate (which maps to started/shutdown
>>> > in the IRQ code) is that the HW resources for a given interrupt are
>>> > only committed when the interrupt is activated. Trying to perform
>>> > actions involving the HW on an interrupt that isn't active cannot be
>>> > guaranteed to take effect.
>>> >
>>> > I'd rather address it in the core code, by preventing set_affinity (and
>>> > potentially others) to take place when the interrupt is not in the
>>> > STARTED state. Userspace would get an error, which is perfectly
>>> > legitimate, and which it already has to deal with it for plenty of
>>> > other
>>> > reasons.
>>
>> So I finally found time to dig a bit in there :) Code has changed a
>> bit
>> since last I looked. But I have memories of the startup code messing
>> around with the affinity, and here it is. In irq_startup() :
>>
>>
>> switch (__irq_startup_managed(desc, aff, force)) {
>> case IRQ_STARTUP_NORMAL:
>> ret = __irq_startup(desc);
>> irq_setup_affinity(desc);
>> break;
>> case IRQ_STARTUP_MANAGED:
>> irq_do_set_affinity(d, aff, false);
>> ret = __irq_startup(desc);
Grump. Nice catch. In hindsight, this is obvious, as managed interrupts
may have been allocated to target CPUs that have been hot-plugged off.
>> break;
>> case IRQ_STARTUP_ABORT:
>> irqd_set_managed_shutdown(d);
>> return 0;
>>
>> So we have two cases here. Normal and managed.
>>
>> In the managed case, we set the affinity before startup. I feel like
>> your
>> patch might break that or am I missing something ?
>
> It will break stuff because the affinity is not stored in case that the
> interrupt is not started.
>
> I think we can fix this in the core code but that needs more thought.
> __irq_can_set_affinity() is definitely the wrong place.
Indeed. I completely missed the above. Back to square one.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
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] efi/libstub: refactor Makefile to not use lib-y syntax
From: Ard Biesheuvel @ 2020-06-03 12:42 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-efi, Kees Cook, Catalin Marinas, Linux Kernel Mailing List,
Atish Patra, Arvind Sankar, Will Deacon, Ingo Molnar, Linux ARM
In-Reply-To: <CAK7LNAQ_YMfjucip8eFBod1TBMUqGgnYebBeP22dZ4J7ZsFXeg@mail.gmail.com>
On Wed, 3 Jun 2020 at 13:23, Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Wed, Jun 3, 2020 at 6:16 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Wed, 3 Jun 2020 at 11:15, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > >
> > > On Wed, Jun 3, 2020 at 6:02 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > >
> > > > On Wed, 3 Jun 2020 at 10:59, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > > > >
> > > > > On Wed, Jun 3, 2020 at 5:45 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > > >
> > > > > > On Wed, 3 Jun 2020 at 10:36, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > > > > > >
> > > > > > > On Wed, Jun 3, 2020 at 3:45 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > > > > >
> > > > > > > > On Wed, 3 Jun 2020 at 07:34, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > > > > > > > >
> > > > > > > > > Documentation/kbuild/makefiles.rst says:
> > > > > > > > >
> > > > > > > > > Use of lib-y is normally restricted to `lib/` and `arch/*/lib`.
> > > > > > > > >
> > > > > > > > > I want to disallow lib-y outside of them.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Why?
> > > > > > >
> > > > > > >
> > > > > > > Because I plan to remove lib-y entirely at some point.
> > > > > > >
> > > > > > > lib-y is not so useful to shrink the image size because:
> > > > > > >
> > > > > > > - An object in lib.a can be omitted only when no symbol
> > > > > > > in that object is referenced. This rarely happens.
> > > > > > >
> > > > > > > - lib-y objects are often exported by nature
> > > > > > > because lib-y is a collection of utility functions.
> > > > > > > Even if no in-tree user, we always need to keep them
> > > > > > > because EXPORT_SYMBOL() is the interface to modules.
> > > > > > >
> > > > > > >
> > > > > > > When I worked on commit 7273ad2b08f8ac9563579d16a3cf528857b26f49,
> > > > > > > I made some research.
> > > > > > >
> > > > > > > The benefit of lib-y is just 362 byte for x86_64_defconfig.
> > > > > > > ( Before: 26578002, After: 26578364)
> > > > > > >
> > > > > > > My hope is lib-y will be replaced by dead-code elimination or
> > > > > > > ultimately by LTO.
> > > > > > >
> > > > > > > drivers/firmware/efi/libstub/Makefile
> > > > > > > is the only Makefile that breaks the rule:
> > > > > > > "Use of lib-y is normally restricted to `lib/` and `arch/*/lib`"
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > > Add a custom rule to build lib.a, which is linked to the decompressor
> > > > > > > > > for ARCH=x86, ARCH=arm.
> > > > > > > > >
> > > > > > > > > For ARCH=arm64, use obj-y to link objects to vmlinux in the ordinary
> > > > > > > > > way.
> > > > > > > > >
> > > > > > > >
> > > > > > > > The code works perfectly fine as is, and I don't see what is
> > > > > > > > fundamentally wrong with using static libraries outside of lib/ and
> > > > > > > > arch/*/lib.
> > > > > > >
> > > > > > > The intended usage of lib-y is to hook lib.a
> > > > > > > to scripts/vmlinux.sh via KBUILD_VMLINUX_LIBS.
> > > > > > >
> > > > > > > This Makefile is just what you found to work.
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Also, I would like this code to still be incorporated as a static
> > > > > > > > library into arm64 as well, so that only pieces that are actually
> > > > > > > > needed are incorporated into the final image.
> > > > > > >
> > > > > > > No.
> > > > > > > It is not working like that because you set
> > > > > > > lib.a to core-y.
> > > > > > >
> > > > > > > All objects in core-y are always linked to vmlinux.
> > > > > > >
> > > > > >
> > > > > > The lib.a file is passed to the linker as a static library, so it will
> > > > > > only grab what it needs.
> > > > > >
> > > > > > For instance, if you build arm64 from mainline today, the
> > > > > > efi_relocate_kernel will not be in the final image, even though it is
> > > > > > built as part of libstub
> > > > >
> > > > >
> > > > > I built today's mainline kernel
> > > > > (d6f9469a03d832dcd17041ed67774ffb5f3e73b3).
> > > > >
> > > > >
> > > > > I see it in vmlinux.
> > > > >
> > > > >
> > > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
> > > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24
> > > > > ...
> > > > > $ aarch64-linux-gnu-nm -n vmlinux | grep efi_relocate_kernel
> > > > > ffff8000114afb90 t __efistub_efi_relocate_kernel
> > > > >
> > > >
> > > > That is strange. I tested this before, and it worked.
> > > >
> > > > Did anything change recently in the way the linker is invoked?
> > >
> > >
> > > Nothing recently.
> > >
> > > This is obvious result because
> > > drivers/firmware/efi/libstub/lib.a
> > > is passed after ----whole-archive flag.
> > >
> > >
> > > I guess the following commit is it,
> > > but it is already 3 years ago.
> > >
> >
> > Right.
> >
> > So that means there is no point at all in using static libraries, no?
> > Or does --whole-archive still allow duplicate definitions like static
> > libraries do usually?
>
>
> --whole-archive literally links the whole of the archive.
> If there are duplicate definitions, the linking fails
> due to multiple definition.
> So, --whole-archive is similar to linking .o files
> in this regard.
>
>
> There is a point for arm and x86 because
> the decompressor link does not use --whole-archive.
>
> As for arm64, there is no point,
> but you can pass lib.a after --no-whole-archive
> by the following patch.
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 650e1185c190..48a6afa774fc 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -145,7 +145,7 @@ export TEXT_OFFSET
>
> core-y += arch/arm64/
> libs-y := arch/arm64/lib/ $(libs-y)
> -core-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
> +libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
>
> # Default target when executing plain make
> boot := arch/arm64/boot
>
>
>
> Then, _efistub_efi_low_alloc_above
> and __efistub_efi_relocate_kernel will be dropped.
>
>
> If you like the static library
> do you want me to send v2?
>
Yes please
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox