Re: [RFC PATCH v5 01/11] ASoC: fsl_asrc: define functions for memory to memory usage
Hi On Mon, Oct 2, 2023 at 11:08 PM Mark Brown wrote: > > On Thu, Sep 28, 2023 at 05:00:09PM +0800, Shengjiu Wang wrote: > > > m2m_start_part_one: first part of the start steps > > m2m_start_part_two: second part of the start steps > > m2m_stop_part_one: first part of stop steps > > m2m_stop_part_two: second part of stop steps, optional > > The part_one/two naming isn't amazing here. Looking at the rest of the > code it looks like this is a prepare/trigger type distinction where the > first part is configuring things prior to DMA setup and the second part > is actually starting the transfer. Perhaps _config()/_start() instead? Ok, I will use m2m_prepare/m2m_unprepare to replace m2m_start_part_one/m2m_stop_part_one, and use m2m_start/m2m_stop to replace m2m_start_part_two/m2m_stop_part_two. Best regards Wang shengjiu
Re: [PATCH v2] arch: Reserve map_shadow_stack() syscall number for all architectures
On 10/6/2023 1:29 PM, Arnd Bergmann wrote: > On Fri, Oct 6, 2023, at 22:01, Edgecombe, Rick P wrote: >> Hi Arnd, >> >> It doesn't look like anyone is pouncing on the syscall number in linux- >> next currently. It might be nice to have this patch go through linux- >> next since it touches so many architectures. And it sounds like x86 >> folk are ok with this, so if you could pick it up for 6.7 that would be >> great. Thanks! > > Ok, I picked it up now, should be in linux-next starting next week. > Great, thanks Arnd and Rick! Sohil
Re: [PATCH v2] arch: Reserve map_shadow_stack() syscall number for all architectures
On Fri, Oct 6, 2023, at 22:01, Edgecombe, Rick P wrote: > On Tue, 2023-10-03 at 10:18 -0700, Sohil Mehta wrote: >> > If you like, I can pick this up for 6.7 through the asm-generic >> > tree. If you think this should be part of 6.6, I would suggest >> > to merge it through the tree that originally contained the >> > syscall code. >> > >> >> Dave, Ingo, would you prefer to take this patch through 6.6 or defer >> it >> until 6.7? >> >> It's not necessarily a fix but it does help finish up the shstk >> syscall >> added with 6.6. Also, it might help reduce some merge conflicts later >> if >> newer syscalls are being added during the 6.7 window. > > Hi Arnd, > > It doesn't look like anyone is pouncing on the syscall number in linux- > next currently. It might be nice to have this patch go through linux- > next since it touches so many architectures. And it sounds like x86 > folk are ok with this, so if you could pick it up for 6.7 that would be > great. Thanks! Ok, I picked it up now, should be in linux-next starting next week. Arnd
Re: [PATCH v2] arch: Reserve map_shadow_stack() syscall number for all architectures
On Tue, 2023-10-03 at 10:18 -0700, Sohil Mehta wrote: > > If you like, I can pick this up for 6.7 through the asm-generic > > tree. If you think this should be part of 6.6, I would suggest > > to merge it through the tree that originally contained the > > syscall code. > > > > Dave, Ingo, would you prefer to take this patch through 6.6 or defer > it > until 6.7? > > It's not necessarily a fix but it does help finish up the shstk > syscall > added with 6.6. Also, it might help reduce some merge conflicts later > if > newer syscalls are being added during the 6.7 window. Hi Arnd, It doesn't look like anyone is pouncing on the syscall number in linux- next currently. It might be nice to have this patch go through linux- next since it touches so many architectures. And it sounds like x86 folk are ok with this, so if you could pick it up for 6.7 that would be great. Thanks!
Re: [net-next PATCH v2 4/4] netdev: use napi_schedule bool instead of napi_schedule_prep/__napi_schedule
On Thu, Oct 05, 2023 at 06:16:26PM +0200, Eric Dumazet wrote:
> On Tue, Oct 3, 2023 at 8:36 PM Christian Marangi wrote:
> >
> > Replace if condition of napi_schedule_prep/__napi_schedule and use bool
> > from napi_schedule directly where possible.
> >
> > Signed-off-by: Christian Marangi
> > ---
> > drivers/net/ethernet/atheros/atlx/atl1.c | 4 +---
> > drivers/net/ethernet/toshiba/tc35815.c | 4 +---
> > drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 4 +---
> > 3 files changed, 3 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c
> > b/drivers/net/ethernet/atheros/atlx/atl1.c
> > index 02aa6fd8ebc2..a9014d7932db 100644
> > --- a/drivers/net/ethernet/atheros/atlx/atl1.c
> > +++ b/drivers/net/ethernet/atheros/atlx/atl1.c
> > @@ -2446,7 +2446,7 @@ static int atl1_rings_clean(struct napi_struct *napi,
> > int budget)
> >
> > static inline int atl1_sched_rings_clean(struct atl1_adapter* adapter)
> > {
> > - if (!napi_schedule_prep(&adapter->napi))
> > + if (!napi_schedule(&adapter->napi))
> > /* It is possible in case even the RX/TX ints are disabled
> > via IMR
> > * register the ISR bits are set anyway (but do not produce
> > IRQ).
> > * To handle such situation the napi functions used to
> > check is
> > @@ -2454,8 +2454,6 @@ static inline int atl1_sched_rings_clean(struct
> > atl1_adapter* adapter)
> > */
> > return 0;
> >
> > - __napi_schedule(&adapter->napi);
> > -
> > /*
> > * Disable RX/TX ints via IMR register if it is
> > * allowed. NAPI handler must reenable them in same
> > diff --git a/drivers/net/ethernet/toshiba/tc35815.c
> > b/drivers/net/ethernet/toshiba/tc35815.c
> > index 14cf6ecf6d0d..a8b8a0e13f9a 100644
> > --- a/drivers/net/ethernet/toshiba/tc35815.c
> > +++ b/drivers/net/ethernet/toshiba/tc35815.c
> > @@ -1436,9 +1436,7 @@ static irqreturn_t tc35815_interrupt(int irq, void
> > *dev_id)
> > if (!(dmactl & DMA_IntMask)) {
> > /* disable interrupts */
> > tc_writel(dmactl | DMA_IntMask, &tr->DMA_Ctl);
> > - if (napi_schedule_prep(&lp->napi))
> > - __napi_schedule(&lp->napi);
> > - else {
> > + if (!napi_schedule(&lp->napi)) {
> > printk(KERN_ERR "%s: interrupt taken in poll\n",
> >dev->name);
> > BUG();
>
> Hmmm... could you also remove this BUG() ? I think this code path can be taken
> if some applications are using busy polling.
>
> Or simply rewrite this with the traditional
>
> if (napi_schedule_prep(&lp->napi)) {
>/* disable interrupts */
>tc_writel(dmactl | DMA_IntMask, &tr->DMA_Ctl);
> __napi_schedule(&lp->napi);
> }
>
>
Mhhh is it safe to do so? I mean it seems very wrong to print a warning
and BUG() instead of disabling the interrupt only if napi can be
scheduled... Maybe is very old code? The more I see this the more I see
problem... (randomly disabling the interrupt and then make the kernel
die)
>
> > diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> > b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> > index 23b5a0adcbd6..146bc7bd14fb 100644
> > --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> > +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> > @@ -1660,9 +1660,7 @@ irqreturn_t iwl_pcie_irq_rx_msix_handler(int irq,
> > void *dev_id)
> > IWL_DEBUG_ISR(trans, "[%d] Got interrupt\n", entry->entry);
> >
> > local_bh_disable();
> > - if (napi_schedule_prep(&rxq->napi))
> > - __napi_schedule(&rxq->napi);
> > - else
> > + if (!napi_schedule(&rxq->napi))
> > iwl_pcie_clear_irq(trans, entry->entry);
>
> Same remark here about twisted logic.
>
Ehhh here we need to be careful... We can do the usual prep/__schedule
with the DMA disable in between...
>From the comments of iwl_pcie_clear_irq.
/*
* Before sending the interrupt the HW disables it to prevent
* a nested interrupt. This is done by writing 1 to the corresponding
* bit in the mask register. After handling the interrupt, it should be
* re-enabled by clearing this bit. This register is defined as
* write 1 clear (W1C) register, meaning that it's being clear
* by writing 1 to the bit.
*/
So the device disable the interrupt after being fired and the bit needs
to set again for the interrupt to be reenabled. So the function
correctly reenable the irq if a napi can't be scheduled... Think there
isn't another way to handle this.
> > local_bh_enable();
> >
> > --
> > 2.40.1
> >
--
Ansuel
Re: [net-next PATCH v2 3/4] netdev: replace napi_reschedule with napi_schedule
On Thu, Oct 05, 2023 at 06:41:03PM +0200, Eric Dumazet wrote:
> On Thu, Oct 5, 2023 at 6:32 PM Jakub Kicinski wrote:
> >
> > On Thu, 5 Oct 2023 18:11:56 +0200 Eric Dumazet wrote:
> > > OK, but I suspect some users of napi_reschedule() might not be
> > > race-free...
> >
> > What's the race you're thinking of?
>
> This sort of thing... the race is in fl_starving() though...
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c
> b/drivers/net/ethernet/chelsio/cxgb4/sge.c
> index 98dd78551d89..b5ff2e1a9975 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
> @@ -4261,7 +4261,7 @@ static void sge_rx_timer_cb(struct timer_list *t)
>
> if (fl_starving(adap, fl)) {
> rxq = container_of(fl, struct sge_eth_rxq,
> fl);
> - if (napi_reschedule(&rxq->rspq.napi))
> + if (napi_schedule(&rxq->rspq.napi))
> fl->starving++;
> else
> set_bit(id, s->starving_fl);
Ehhh problem is that this is a simple rename so if any race is present,
it's already there and not caused by this rename :(
Don't know maybe this is out of scope and should be investigated with a
bug report?
Maybe this should be changed to prep/__schedule to prevent any kind of
race? But doing so doesn't prevent any kind of ""starving""?
--
Ansuel
Re: [Bisected] [commit 2ad56efa80db] [Hotplug] WARNING while performing hotplug operation on 6.6-rc3-next
Greetings, Thanks Jason. The fix provided by you works. It is not giving WARNING's but i am seeing below logs. Would you please confirm on the logs. https://lore.kernel.org/all/0-v1-2b52423411b9+164fc-iommu_ppc_defdomain_...@nvidia.com/ [ 152.342125] pci 0013:60:00.0: No hypervisor support for SR-IOV on this device, IOV BARs disabled. [ 152.344896] pci 0013:60:00.0: PME# supported from D0 D3hot D3cold [ 152.348936] pci 0013:60:00.0: Adding to iommu group 0 [ 152.349944] pci 0013:60:00.1: No hypervisor support for SR-IOV on this device, IOV BARs disabled. [ 152.352701] pci 0013:60:00.1: PME# supported from D0 D3hot D3cold [ 152.356520] pci 0013:60:00.1: Adding to iommu group 0 [ 152.356527] iommu_tce: it_map is not empty [ 152.357501] pci 0013:60:00.2: No hypervisor support for SR-IOV on this device, IOV BARs disabled. [ 152.360247] pci 0013:60:00.2: PME# supported from D0 D3hot D3cold [ 152.364070] pci 0013:60:00.2: Adding to iommu group 0 [ 152.364075] *iommu_tce: it_map is not empty* [ 152.365043] pci 0013:60:00.3: No hypervisor support for SR-IOV on this device, IOV BARs disabled. [ 152.367790] pci 0013:60:00.3: PME# supported from D0 D3hot D3cold [ 152.371635] pci 0013:60:00.3: Adding to iommu group 0 [ 152.371641] iommu_tce: it_map is not empty [ 152.371720] pci 0013:60:00.0: of_irq_parse_pci: no interrupt-map found, INTx interrupts not available [ 152.408351] tg3 0013:60:00.0: iommu: 64-bit OK but direct DMA is limited by 820 [ 152.408376] tg3 0013:60:00.0: iommu: 64-bit OK but direct DMA is limited by 820 *[ 152.408404] tg3 0013:60:00.0: DMA engine test failed, aborting** **[ 152.408557] tg3: probe of 0013:60:00.0 failed with error -12* [ 152.408583] pci 0013:60:00.1: Adding to iommu group 0 [ 152.408589] iommu_tce: it_map is not empty [ 152.408656] pci 0013:60:00.1: of_irq_parse_pci: no interrupt-map found, INTx interrupts not available [ 152.448321] tg3 0013:60:00.1: iommu: 64-bit OK but direct DMA is limited by 820 [ 152.448339] tg3 0013:60:00.1: iommu: 64-bit OK but direct DMA is limited by 820 [ 152.448360] tg3 0013:60:00.1: DMA engine test failed, aborting [ 152.448497] tg3: probe of 0013:60:00.1 failed with error -12 [ 152.448519] pci 0013:60:00.2: Adding to iommu group 0 [ 152.448525] iommu_tce: it_map is not empty [ 152.448586] pci 0013:60:00.2: of_irq_parse_pci: no interrupt-map found, INTx interrupts not available [ 152.488323] tg3 0013:60:00.2: iommu: 64-bit OK but direct DMA is limited by 820 [ 152.488340] tg3 0013:60:00.2: iommu: 64-bit OK but direct DMA is limited by 820 [ 152.488362] tg3 0013:60:00.2: DMA engine test failed, aborting [ 152.488495] tg3: probe of 0013:60:00.2 failed with error -12 [ 152.488516] pci 0013:60:00.3: Adding to iommu group 0 [ 152.488523] iommu_tce: it_map is not empty [ 152.488581] pci 0013:60:00.3: of_irq_parse_pci: no interrupt-map found, INTx interrupts not available [ 152.528342] tg3 0013:60:00.3: iommu: 64-bit OK but direct DMA is limited by 820 [ 152.528359] tg3 0013:60:00.3: iommu: 64-bit OK but direct DMA is limited by 820 [ 152.528381] tg3 0013:60:00.3: DMA engine test failed, aborting [ 152.528515] tg3: probe of 0013:60:00.3 failed with error -12 On 10/6/23 17:06, Jason Gunthorpe wrote: On Fri, Oct 06, 2023 at 01:20:17PM +0530, Tasmiya Nalatwad wrote: Greetings, [linux-next] [6.6.0-rc3-next-20230929] WARNING: CPU: 5 PID: 185612 at drivers/iommu/iommu.c:3049 iommu_setup_default_domain+0x410/0x680 --- Traces --- [ 6296.425934] WARNING: CPU: 5 PID: 185612 at drivers/iommu/iommu.c:3049 iommu_setup_default_domain+0x410/0x680 Does this fix it too? I think it should? https://lore.kernel.org/r/0-v1-2b52423411b9+164fc-iommu_ppc_defdomain_...@nvidia.com Jason -- Regards, Tasmiya Nalatwad IBM Linux Technology Center
Re: [PATCH v6 4/9] mm: thp: Introduce anon_orders and anon_always_mask sysfs files
Andrew Morton writes:
> On Fri, 29 Sep 2023 12:44:15 +0100 Ryan Roberts wrote:
>
>> In preparation for adding support for anonymous large folios that are
>> smaller than the PMD-size, introduce 2 new sysfs files that will be used
>> to control the new behaviours via the transparent_hugepage interface.
>> For now, the kernel still only supports PMD-order anonymous THP, so when
>> reading back anon_orders, it will reflect that. Therefore there are no
>> behavioural changes intended here.
>
> powerpc strikes again. ARCH=powerpc allmodconfig:
>
>
> In file included from ./include/linux/bits.h:6,
> from ./include/linux/ratelimit_types.h:5,
> from ./include/linux/printk.h:9,
> from ./include/asm-generic/bug.h:22,
> from ./arch/powerpc/include/asm/bug.h:116,
> from ./include/linux/bug.h:5,
> from ./include/linux/mmdebug.h:5,
> from ./include/linux/mm.h:6,
> from mm/huge_memory.c:8:
> ./include/vdso/bits.h:7:33: error: initializer element is not constant
> 7 | #define BIT(nr) (UL(1) << (nr))
> | ^
> mm/huge_memory.c:77:47: note: in expansion of macro 'BIT'
>77 | unsigned int huge_anon_orders __read_mostly = BIT(PMD_ORDER);
> | ^~~
>
> We keep tripping over this. I wish there was a way to fix it.
I can't think of any solution, other than ripping the code out.
To catch it earlier we'd need a generic compile-time test that all values
derived from the page table geometry are only used in places that don't
require a constant. I can't think of a way to write a test for that.
Or submitters could compile-test for powerpc - one can dream :D
> Style whine: an all-caps identifier is supposed to be a constant,
> dammit.
>
> #define PTE_INDEX_SIZE __pte_index_size
>
> Nope.
I agree it's ugly. It was done that way because PTE_INDEX_SIZE used to
be constant, and still is for 32-bit PPC and 64-bit Book3E PPC.
We could rename PTE_INDEX_SIZE itself, but we'd still have eg.
PTE_TABLE_SIZE which is used in generic code, and which would be
sometimes constant and sometimes not for different powerpc subarches.
> I did this:
>
> ---
> a/mm/huge_memory.c~mm-thp-introduce-anon_orders-and-anon_always_mask-sysfs-files-fix
> +++ a/mm/huge_memory.c
> @@ -74,7 +74,7 @@ static unsigned long deferred_split_scan
> static atomic_t huge_zero_refcount;
> struct page *huge_zero_page __read_mostly;
> unsigned long huge_zero_pfn __read_mostly = ~0UL;
> -unsigned int huge_anon_orders __read_mostly = BIT(PMD_ORDER);
> +unsigned int huge_anon_orders __read_mostly;
> static unsigned int huge_anon_always_mask __read_mostly;
>
> /**
> @@ -528,6 +528,9 @@ static int __init hugepage_init_sysfs(st
> {
> int err;
>
> + /* powerpc's PMD_ORDER isn't a compile-time constant */
> + huge_anon_orders = BIT(PMD_ORDER);
> +
> *hugepage_kobj = kobject_create_and_add("transparent_hugepage",
> mm_kobj);
> if (unlikely(!*hugepage_kobj)) {
> pr_err("failed to create transparent hugepage kobject\n");
> _
>
>
> I assume this is set up early enough.
Yes it should be.
> I don't know why powerpc's PTE_INDEX_SIZE is variable.
To allow a single vmlinux to boot using either the Hashed Page Table
MMU, or Radix Tree MMU, which have different page table geometry.
That's a pretty crucial feature for distros, so that they can build a
single kernel to boot on Power8/9/10.
cheers
Re: [PATCH v2 00/15] sysctl: Remove sentinel elements from drivers
Joel Granados writes: > On Mon, Oct 02, 2023 at 12:27:18PM +, Christophe Leroy wrote: >> Le 02/10/2023 à 10:55, Joel Granados via B4 Relay a écrit : >> > From: Joel Granados >> > > <--- snip ---> >> > - The "yesall" config saves 2432 bytes [4] >> > - The "tiny" config saves 64 bytes [5] >> > * memory usage: >> > In this case there were no bytes saved because I do not have any >> > of the drivers in the patch. To measure it comment the printk in >> > `new_dir` and uncomment the if conditional in `new_links` [3]. >> > >> > --- >> > Changes in v2: >> > - Left the dangling comma in the ctl_table arrays. >> > - Link to v1: >> > https://lore.kernel.org/r/20230928-jag-sysctl_remove_empty_elem_drivers-v1-0-e59120fca...@samsung.com >> > >> > Comments/feedback greatly appreciated >> >> Same problem on powerpc CI tests, all boot target failed, most of them >> with similar OOPS, see >> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20231002-jag-sysctl_remove_empty_elem_drivers-v2-15-02dd0d46f...@samsung.com/ > I found the culprit!. Here you are rebasing on top of v6.5.0-rc6 "INFO: > Looking for kernel version: 6.5.0-rc6-gbf2ac4d7d596". The error makes > sense becuase in that version we have not introduced the stopping > criteria based on the ctl_table array size, so the loop continues > looking for an empty sentinel past valid memory (and does not find it). > The ctl_table check catches it but then fails to do a proper error > because we have already tried to access invalid memory. The solution > here is to make sure to rebase in on top of the latest rc in v6.6. Thanks for tracking it down. This is my fault, previously Russell would update the branch that the CI uses as its base. Now that he has left I need to do that myself, but had forgotten. Sorry for the noise. cheers
Re: linux-next: Tree for Sep 20 (ppc32: ADB_CUDA Kconfig warning)
Hi Michael,
On 9/21/23 21:51, Randy Dunlap wrote:
>
>
> On 9/21/23 17:10, Michael Ellerman wrote:
>> Randy Dunlap writes:
>>> On 9/19/23 20:37, Stephen Rothwell wrote:
Hi all,
Changes since 20230919:
The mm tree lost its boot warning.
The drm-misc tree gained a conflict against Linus' tree.
Non-merge commits (relative to Linus' tree): 6006
3996 files changed, 459968 insertions(+), 111742 deletions(-)
>>>
>>> 4 out of 10 randconfigs have this warning:
>>>
>>> WARNING: unmet direct dependencies detected for ADB_CUDA
>>> Depends on [n]: MACINTOSH_DRIVERS [=n] && (ADB [=n] || PPC_PMAC [=y]) &&
>>> !PPC_PMAC64 [=n]
>>> Selected by [y]:
>>> - PPC_PMAC [=y] && PPC_BOOK3S [=y] && CPU_BIG_ENDIAN [=y] && POWER_RESET
>>> [=y] && PPC32 [=y]
>>>
>>> WARNING: unmet direct dependencies detected for ADB_CUDA
>>> Depends on [n]: MACINTOSH_DRIVERS [=n] && (ADB [=n] || PPC_PMAC [=y]) &&
>>> !PPC_PMAC64 [=n]
>>> Selected by [y]:
>>> - PPC_PMAC [=y] && PPC_BOOK3S [=y] && CPU_BIG_ENDIAN [=y] && POWER_RESET
>>> [=y] && PPC32 [=y]
>>>
>>> WARNING: unmet direct dependencies detected for ADB_CUDA
>>> Depends on [n]: MACINTOSH_DRIVERS [=n] && (ADB [=n] || PPC_PMAC [=y]) &&
>>> !PPC_PMAC64 [=n]
>>> Selected by [y]:
>>> - PPC_PMAC [=y] && PPC_BOOK3S [=y] && CPU_BIG_ENDIAN [=y] && POWER_RESET
>>> [=y] && PPC32 [=y]
>>
>> Crud. Caused by:
>>
>> a3ef2fef198c ("powerpc/32: Add dependencies of POWER_RESET for pmac32")
>>
>> I was suspicious of that select, I should have been *more* suspicious :)
>>
>> I think this is a fix. The PPC32 isn't needed because ADB depends on
>> (PPC_PMAC && PPC32).
>
> Yes, that fixes the problem. Thanks.
>
> Tested-by: Randy Dunlap
> Acked-by: Randy Dunlap
>
Will you be merging this fix?
Thanks.
>>
>> diff --git a/arch/powerpc/platforms/powermac/Kconfig
>> b/arch/powerpc/platforms/powermac/Kconfig
>> index 8bdae0caf21e..84f101ec53a9 100644
>> --- a/arch/powerpc/platforms/powermac/Kconfig
>> +++ b/arch/powerpc/platforms/powermac/Kconfig
>> @@ -2,7 +2,7 @@
>> config PPC_PMAC
>> bool "Apple PowerMac based machines"
>> depends on PPC_BOOK3S && CPU_BIG_ENDIAN
>> - select ADB_CUDA if POWER_RESET && PPC32
>> + select ADB_CUDA if POWER_RESET && ADB
>> select MPIC
>> select FORCE_PCI
>> select PPC_INDIRECT_PCI if PPC32
>>
>> cheers
>
--
~Randy
RE: [EXT] Re: Re: [PATCH v2 1/2] ASoC: dt-bindings: fsl_rpmsg: List DAPM endpoints ignoring system suspend
> > > This is a fairly standard DSP playback case as far as I can see so > > > it should work with DAPM without needing this obviously use case > > > specific stuff peering into the Linux implementation. Generally > > > this is done by tagging endpoint widgets and DAIs as ignore_suspend, > > > DAPM will then figure out the rest of the widgets in the path. > > > Yes, indeed I meant to let driver get DAPM endpoints from the > "fsl,lpa-widgets" > > property and then set these endpoints as ignore_suspend if the sound > > card is running in this use case. Do you think the description for the > > use case can be simplified since it's a common use case? > > This is a card problem - the driver for rpmsg shouldn't need to worry about > it. > Any bindings extensions should be at the card level rather than in a specific > driver, we could probably use something in the generic properties that they're > all using. Instead of "fsl,lpa-widgets", I would like to add a common property "ignore-suspend-widgets" in sound-card-common.yaml file. So not only rpmsg sound cards but also other sound cards which have such feature can use this property to define wanted widgets ignoring suspend. What do you think about that? Regards, Chancel Liu
Re: [PATCH v5 1/5] powerpc/code-patching: introduce patch_instructions()
Le 06/10/2023 à 18:22, Hari Bathini a écrit :
> Hi Christophe,
>
>
> On 29/09/23 2:09 pm, Christophe Leroy wrote:
>>
>>
>> Le 28/09/2023 à 21:48, Hari Bathini a écrit :
>>> patch_instruction() entails setting up pte, patching the instruction,
>>> clearing the pte and flushing the tlb. If multiple instructions need
>>> to be patched, every instruction would have to go through the above
>>> drill unnecessarily. Instead, introduce function patch_instructions()
>>> that sets up the pte, clears the pte and flushes the tlb only once per
>>> page range of instructions to be patched. This adds a slight overhead
>>> to patch_instruction() call while improving the patching time for
>>> scenarios where more than one instruction needs to be patched.
>>
>> On my powerpc8xx, this patch leads to an increase of about 8% of the
>> time needed to activate ftrace function tracer.
>
> Interesting! My observation on ppc64le was somewhat different.
> With single cpu, average ticks were almost similar with and without
> the patch (~1580). I saw a performance degradation of less than
> 0.6% without vs with this patch to activate function tracer.
>
> Ticks to activate function tracer in 15 attempts without
> this patch (avg: 108734089):
> 106619626
> 111712292
> 111030404
> 111021344
> 111313530
> 106253773
> 107156175
> 106887038
> 107215379
> 108646636
> 108040287
> 108311770
> 107842343
> 106894310
> 112066423
>
> Ticks to activate function tracer in 15 attempts with
> this patch (avg: 109328578):
> 109378357
> 108794095
> 108595381
> 107622142
> 110689418
> 107287276
> 107132093
> 112540481
> 111311830
> 112608265
> 102883923
> 112054554
> 111762570
> 109874309
> 107393979
>
> I used the below patch for the experiment:
I do the measurement at a higher level:
diff --git a/arch/powerpc/kernel/trace/ftrace.c
b/arch/powerpc/kernel/trace/ftrace.c
index 82010629cf88..3eea5b963bfa 100644
--- a/arch/powerpc/kernel/trace/ftrace.c
+++ b/arch/powerpc/kernel/trace/ftrace.c
@@ -167,7 +167,9 @@ void ftrace_replace_code(int enable)
struct ftrace_rec_iter *iter;
struct dyn_ftrace *rec;
int ret = 0, update;
+ long t0;
+ t0 = mftb();
for_ftrace_rec_iter(iter) {
rec = ftrace_rec_iter_record(iter);
ip = rec->ip;
@@ -206,6 +208,8 @@ void ftrace_replace_code(int enable)
if (ret)
goto out;
}
+ t0 = mftb() - t0;
+ pr_err("%s: %ld\n", __func__, t0);
out:
if (ret)
Without your patch I get:
# echo function > /sys/kernel/debug/tracing/current_tracer
[ 59.871176] ftrace-powerpc: ftrace_replace_code: 708099
# echo nop > /sys/kernel/debug/tracing/current_tracer
[ 62.645293] ftrace-powerpc: ftrace_replace_code: 606449
[ 64.141428] ftrace-powerpc: ftrace_replace_code: 710117
[ 65.185562] ftrace-powerpc: ftrace_replace_code: 615069
[ 66.311363] ftrace-powerpc: ftrace_replace_code: 706974
[ 67.272770] ftrace-powerpc: ftrace_replace_code: 604744
[ 68.311403] ftrace-powerpc: ftrace_replace_code: 707498
[ 69.245960] ftrace-powerpc: ftrace_replace_code: 607089
[ 72.661438] ftrace-powerpc: ftrace_replace_code: 710228
[ 74.127413] ftrace-powerpc: ftrace_replace_code: 604846
[ 75.301460] ftrace-powerpc: ftrace_replace_code: 707982
[ 76.289665] ftrace-powerpc: ftrace_replace_code: 600860
[ 77.431054] ftrace-powerpc: ftrace_replace_code: 706672
[ 78.418618] ftrace-powerpc: ftrace_replace_code: 600879
[ 79.641558] ftrace-powerpc: ftrace_replace_code: 711074
[ 80.636932] ftrace-powerpc: ftrace_replace_code: 605791
[ 81.751581] ftrace-powerpc: ftrace_replace_code: 709184
[ 82.802525] ftrace-powerpc: ftrace_replace_code: 603046
[ 84.701412] ftrace-powerpc: ftrace_replace_code: 709887
[ 85.792599] ftrace-powerpc: ftrace_replace_code: 604801
With patch_instructions() patch applied I get:
[ 150.677364] ftrace-powerpc: ftrace_replace_code: 753321
[ 154.201196] ftrace-powerpc: ftrace_replace_code: 657561
[ 157.027344] ftrace-powerpc: ftrace_replace_code: 753435
[ 158.692425] ftrace-powerpc: ftrace_replace_code: 652702
[ 162.137339] ftrace-powerpc: ftrace_replace_code: 753394
[ 163.207269] ftrace-powerpc: ftrace_replace_code: 650320
[ 165.387861] ftrace-powerpc: ftrace_replace_code: 756018
[ 166.458877] ftrace-powerpc: ftrace_replace_code: 650477
[ 167.617375] ftrace-powerpc: ftrace_replace_code: 753326
[ 168.596360] ftrace-powerpc: ftrace_replace_code: 647984
[ 169.737676] ftrace-powerpc: ftrace_replace_code: 756137
[ 170.743584] ftrace-powerpc: ftrace_replace_code: 652650
[ 171.907454] ftrace-powerpc: ftrace_replace_code: 754017
[ 172.943305] ftrace-powerpc: ftrace_replace_code: 650853
[ 174.187347] ftrace-powerpc: ftrace_replace_code: 753476
[ 175.811981] ftrace-powerpc: ftrace_replace_code: 650908
[ 177.007400] ftrace-powerpc: ftrace_replace_code: 753408
[ 177.993642] ftrace-powerpc: ftrace_replace_code: 651607
[ 179.157650] ftrace-powerpc: ftrace_replace_
