Re: [linux-yocto][v5.10/standard/ti-sdk-5.10/ti-j72xx & v5.10/standard/preempt-rt/ti-sdk-5.10/ti-j72xx][PATCH] dwc: fix compile error

2024-03-13 Thread Bruce Ashfield 
merged.

Bruce

In message: [linux-yocto][v5.10/standard/ti-sdk-5.10/ti-j72xx & 
v5.10/standard/preempt-rt/ti-sdk-5.10/ti-j72xx][PATCH] dwc: fix compile error
on 13/03/2024 Li Wang wrote:

> ti-j72xx/kernel-source/drivers/pci/controller/dwc/pcie-designware-ep.c:598
> error: too few arguments to function 'dw_pcie_ep_map_addr'
> 
> Signed-off-by: Li Wang 
> ---
>  drivers/pci/controller/dwc/pcie-designware-ep.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c 
> b/drivers/pci/controller/dwc/pcie-designware-ep.c
> index b84e2ce3d714..fb53240150d2 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> @@ -595,7 +595,7 @@ int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 
> func_no,
>  
>   aligned_offset = msg_addr & (epc->mem->window.page_size - 1);
>   msg_addr = ALIGN_DOWN(msg_addr, epc->mem->window.page_size);
> - ret = dw_pcie_ep_map_addr(epc, func_no, ep->msi_mem_phys,  msg_addr,
> + ret = dw_pcie_ep_map_addr(epc, func_no, 0, ep->msi_mem_phys,  msg_addr,
> epc->mem->window.page_size);
>   if (ret)
>   return ret;
> -- 
> 2.25.1
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13686): 
https://lists.yoctoproject.org/g/linux-yocto/message/13686
Mute This Topic: https://lists.yoctoproject.org/mt/104907828/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][v5.15/standard/preempt-rt/sdkv5.15/xlnx-soc][PATCH] sound: xilinx: use hdmi-codec as dp audio codec

2024-03-13 Thread Bruce Ashfield 
In message: [linux-yocto][v5.15/standard/preempt-rt/sdkv5.15/xlnx-soc][PATCH] 
sound: xilinx: use hdmi-codec as dp audio codec
on 13/03/2024 quanyang.w...@windriver.com wrote:

> From: Quanyang Wang 
> 
> According to the description in the section "Audio Management" of
> Chapter 33 in "Zynq UltraScale+ Device Technical Reference Manual",
> A set/clr operation to TX_AUDIO_CONTROL register is needed when we
> start/stop audio play. It means that when we stop playing audio,
> TX_AUDIO_CONTROL register should be cleared. Now the dp codec driver
> xilinx-dp-codec.c can't access DP Tx registers and it has no control
> of DP Tx Audio registers. This results that even if we close the audio
> device after playing audio, Tx Audio is still working and it triggers
> numerous underflow interrupts (bit 17 in DP_INT_STATUS).
> 
> zcu102-zynqmp:~$ cat /proc/interrupts | grep display
>  52:1063792000   GICv2 151 Level   fd4a.display
> 
> zcu102-zynqmp:~$ top
> Mem: 158168K used, 3864792K free, 9992K shrd, 0K buff, 36500K cached
> CPU:  0.0% usr  1.0% sys  0.0% nic 98.9% idle  0.0% io  0.0% irq  0.0% sirq
> Load average: 0.03 0.03 0.01 1/122 391
>   PID  PPID USERSTAT   VSZ %VSZ CPU %CPU COMMAND
>   223 2 rootSW   0  0.0   0  0.9 [irq/52-fd4a]
>   352 1 rootS94148  2.3   0  0.0 /usr/sbin/tcf-agent -d -L- -l0
> 
> So we register a HDMI codec device and use callbacks in hdmi_codec_ops
> to set/clr TX_AUDIO_CONTROL.
> 
> Signed-off-by: Quanyang Wang 
> ---
> Hi Bruce,
> Would you please help merge this patch to the branches:
>   v5.15/standard/preempt-rt/sdkv5.15/xlnx-soc
>   v5.15/standard/sdkv5.15/xlnx-soc

merged.

Bruce

> Thanks,
> Quanyang
> ---
>  drivers/gpu/drm/xlnx/zynqmp_dp.c  | 55 +++
>  sound/soc/xilinx/Kconfig  |  1 +
>  sound/soc/xilinx/xilinx-dp-card.c | 14 ++--
>  3 files changed, 59 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c 
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 308404f122957..c9badbfe5b566 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "zynqmp_disp.h"
>  #include "zynqmp_dp.h"
> @@ -329,6 +330,7 @@ struct zynqmp_dp {
>   void __iomem *iomem;
>   struct reset_control *reset;
>   int irq;
> + struct platform_device *audio_pdev;
>  
>   struct zynqmp_dp_config config;
>   struct drm_dp_aux aux;
> @@ -375,6 +377,53 @@ static void zynqmp_dp_set(void __iomem *base, int 
> offset, u32 set)
>   zynqmp_dp_write(base, offset, zynqmp_dp_read(base, offset) | set);
>  }
>  
> +static int zynqmp_dp_audio_hw_params(struct device *dev,  void *data,
> +struct hdmi_codec_daifmt *daifmt,
> +struct hdmi_codec_params *params)
> +{
> + return 0;
> +}
> +
> +static int zynqmp_dp_audio_startup(struct device *dev, void *data)
> +{
> + struct zynqmp_dp *dp = data;
> +
> + if (zynqmp_disp_aud_enabled(dp->dpsub->disp))
> + zynqmp_dp_write(dp->iomem, ZYNQMP_DP_TX_AUDIO_CONTROL, 1);
> +
> + return 0;
> +}
> +
> +static void zynqmp_dp_audio_shutdown(struct device *dev, void *data)
> +{
> + struct zynqmp_dp *dp = data;
> +
> + if (zynqmp_disp_aud_enabled(dp->dpsub->disp))
> + zynqmp_dp_write(dp->iomem, ZYNQMP_DP_TX_AUDIO_CONTROL, 0);
> +}
> +
> +static const struct hdmi_codec_ops audio_codec_ops = {
> + .hw_params = zynqmp_dp_audio_hw_params,
> + .audio_shutdown = zynqmp_dp_audio_shutdown,
> + .audio_startup = zynqmp_dp_audio_startup,
> +};
> +
> +static int zynqmp_dp_audio_init(struct zynqmp_dp *dp,
> +struct device *dev)
> +{
> + struct hdmi_codec_pdata codec_data = {
> + .ops = _codec_ops,
> + .spdif = 1,
> + .data = dp,
> + };
> +
> + dp->audio_pdev = platform_device_register_data(
> +  dev, HDMI_CODEC_DRV_NAME, PLATFORM_DEVID_NONE,
> +  _data, sizeof(codec_data));
> +
> + return PTR_ERR_OR_ZERO(dp->audio_pdev);
> +}
> +
>  /* 
> -
>   * PHY Handling
>   */
> @@ -1950,6 +1999,12 @@ int zynqmp_dp_probe(struct platform_device *pdev)
>   goto error;
>   }
>  
> + ret = zynqmp_dp_audio_init(dp, dp->dev);
> + if (ret < 0) {
> + dev_err(dp->dev, "failed to initialize DP audio codec\n");
> + goto error;
> + }
> +
>   irq = platform_get_irq(pdev, 0);
>   if (irq < 0) {
>   ret = irq;
> diff --git a/sound/soc/xilinx/Kconfig b/sound/soc/xilinx/Kconfig
> index ade55b32a8cc6..787b92a406a23 100644
> --- a/sound/soc/xilinx/Kconfig
> +++ b/sound/soc/xilinx/Kconfig
> @@ -3,6 +3,7 @@ config SND_SOC_XILINX_DP
>   tristate "Audio support for the the Xilinx

[linux-yocto][v5.10/standard/ti-sdk-5.10/ti-j72xx & v5.10/standard/preempt-rt/ti-sdk-5.10/ti-j72xx][PATCH] dwc: fix compile error

2024-03-13 Thread Li Wang via lists.yoctoproject.org 
ti-j72xx/kernel-source/drivers/pci/controller/dwc/pcie-designware-ep.c:598
error: too few arguments to function 'dw_pcie_ep_map_addr'

Signed-off-by: Li Wang 
---
 drivers/pci/controller/dwc/pcie-designware-ep.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c 
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index b84e2ce3d714..fb53240150d2 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -595,7 +595,7 @@ int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 
func_no,
 
aligned_offset = msg_addr & (epc->mem->window.page_size - 1);
msg_addr = ALIGN_DOWN(msg_addr, epc->mem->window.page_size);
-   ret = dw_pcie_ep_map_addr(epc, func_no, ep->msi_mem_phys,  msg_addr,
+   ret = dw_pcie_ep_map_addr(epc, func_no, 0, ep->msi_mem_phys,  msg_addr,
  epc->mem->window.page_size);
if (ret)
return ret;
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13684): 
https://lists.yoctoproject.org/g/linux-yocto/message/13684
Mute This Topic: https://lists.yoctoproject.org/mt/104907828/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][v5.15/standard/base][PATCH] locking/rwsem: Disable preemption while trying for rwsem lock

2024-03-13 Thread Bruce Ashfield 
On Wed, Mar 13, 2024 at 2:07 AM Wang, Li  wrote:
>
>
> On 3/13/2024 10:55, Bruce Ashfield wrote:
> > In message: [linux-yocto][v5.15/standard/base][PATCH] locking/rwsem: 
> > Disable preemption while trying for rwsem lock
> > on 10/03/2024 Li Wang via lists.yoctoproject.org wrote:
> >
> >> From: Gokul krishna Krishnakumar 
> >>
> >> commit 48dfb5d2560d36fb16c7d430c229d1604ea7d185 upstream
> >>
> >> Make the region inside the rwsem_write_trylock non preemptible.
> >>
> >> We observe RT task is hogging CPU when trying to acquire rwsem lock
> >> which was acquired by a kworker task but before the rwsem owner was set.
> >>
> >> Here is the scenario:
> >> 1. CFS task (affined to a particular CPU) takes rwsem lock.
> >>
> >> 2. CFS task gets preempted by a RT task before setting owner.
> >>
> >> 3. RT task (FIFO) is trying to acquire the lock, but spinning until
> >> RT throttling happens for the lock as the lock was taken by CFS task.
> >>
> >> This patch attempts to fix the above issue by disabling preemption
> >> until owner is set for the lock. While at it also fix the issues
> >> at the places where rwsem_{set,clear}_owner() are called.
> >>
> >> This also adds lockdep annotation of preemption disable in
> >> rwsem_{set,clear}_owner() on Peter Z. suggestion.
> > Any thoughts on why this hasn't been picked up by -stable ?
>
> submitter want the patch into linux stable 5.10, but miss the receiver
> mail of stable.
>
> we will wait the reply from the maintainer of stable:
>
> https://lore.kernel.org/all/b92644e5-529b-4403-aba7-d316262cc...@redhat.com/
>

Perfect!

I'll do the merge now as well, since any conflicts will be easy to
handle. I just
wanted to be sure that we let -stable know (we've done our best, whether it
makes -stable or not :)

Bruce

> Thanks,
> LiWang.
>
> >
> > Bruce
> >
> >> Signed-off-by: Gokul krishna Krishnakumar 
> >> Signed-off-by: Mukesh Ojha 
> >> Signed-off-by: Peter Zijlstra (Intel) 
> >> Reviewed-by: Waiman Long 
> >> Link: 
> >> https://lore.kernel.org/r/1662661467-24203-1-git-send-email-quic_mo...@quicinc.com
> >> Signed-off-by: Beniamin Sandu 
> >> Signed-off-by: Li Wang 
> >> ---
> >>   kernel/locking/rwsem.c | 14 --
> >>   1 file changed, 12 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c
> >> index f0287a16b4ec..4a38d32b89fa 100644
> >> --- a/kernel/locking/rwsem.c
> >> +++ b/kernel/locking/rwsem.c
> >> @@ -133,14 +133,19 @@
> >>* the owner value concurrently without lock. Read from owner, however,
> >>* may not need READ_ONCE() as long as the pointer value is only used
> >>* for comparison and isn't being dereferenced.
> >> + *
> >> + * Both rwsem_{set,clear}_owner() functions should be in the same
> >> + * preempt disable section as the atomic op that changes sem->count.
> >>*/
> >>   static inline void rwsem_set_owner(struct rw_semaphore *sem)
> >>   {
> >> +lockdep_assert_preemption_disabled();
> >>  atomic_long_set(>owner, (long)current);
> >>   }
> >>
> >>   static inline void rwsem_clear_owner(struct rw_semaphore *sem)
> >>   {
> >> +lockdep_assert_preemption_disabled();
> >>  atomic_long_set(>owner, 0);
> >>   }
> >>
> >> @@ -251,13 +256,16 @@ static inline bool rwsem_read_trylock(struct 
> >> rw_semaphore *sem, long *cntp)
> >>   static inline bool rwsem_write_trylock(struct rw_semaphore *sem)
> >>   {
> >>  long tmp = RWSEM_UNLOCKED_VALUE;
> >> +bool ret = false;
> >>
> >> +preempt_disable();
> >>  if (atomic_long_try_cmpxchg_acquire(>count, , 
> >> RWSEM_WRITER_LOCKED)) {
> >>  rwsem_set_owner(sem);
> >> -return true;
> >> +ret = true;
> >>  }
> >>
> >> -return false;
> >> +preempt_enable();
> >> +return ret;
> >>   }
> >>
> >>   /*
> >> @@ -1341,8 +1349,10 @@ static inline void __up_write(struct rw_semaphore 
> >> *sem)
> >>  DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) &&
> >>  !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE), sem);
> >>
> >> +preempt_disable();
> >>  rwsem_clear_owner(sem);
> >>  tmp = atomic_long_fetch_add_release(-RWSEM_WRITER_LOCKED, 
> >> >count);
> >> +preempt_enable();
> >>  if (unlikely(tmp & RWSEM_FLAG_WAITERS))
> >>  rwsem_wake(sem);
> >>   }
> >> --
> >> 2.25.1
> >>
> >> 
> >>



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13683): 
https://lists.yoctoproject.org/g/linux-yocto/message/13683
Mute This Topic: https://lists.yoctoproject.org/mt/104857955/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][v5.10/standard/base && v5.10/standard/preempt-rt/base][PATCH 1/2] blk-mq: Introduce the BLK_MQ_F_NO_SCHED_BY_DEFAULT flag

2024-03-13 Thread Bruce Ashfield 
On Wed, Mar 13, 2024 at 2:25 AM Wentao Zhang  wrote:
>
> 832a4d4cdb3f612d5079aadcc67a44f18fa7b5b7 in 5.10 did the patch back from 
> 2112f5c1330a671fa852051d85cb9eadc05d7eb7 in upstream.
>
> 2112f5c1330a671fa852051d85cb9eadc05d7eb7 add BLK_MQ_F_NO_SCHED_BY_DEFAULT to 
> tag_set.flags in loop device in the upstream, but
>
> 832a4d4cdb3f612d5079aadcc67a44f18fa7b5b7 add  BLK_MQ_F_NO_SCHED   
>to tag_set.flags in loop device in the 5.10.
>
> this backport cause elv_support_iosched return false, then loop device get no 
> scheduler. As shown in the following record:
>
> root@intel-x86-64:~# cat /sys/block/sda/queue/scheduler
> [mq-deadline] kyber bfq none
> root@intel-x86-64:~# cat /sys/block/loop2/queue/scheduler
> [none]
>
> To solve this problem, we can backport the patch from upstream correctly, or 
> revert 832a4d4cdb3f612d5079aadcc67a44f18fa7b5b7.
>
> The loop device gets schedulers after applying the patch I submitted.
> I did the test in intel-x86-64 with linux-yocto, qemux86-64 with linux-yocto 
> and qemux86-64 with linux-yocto-rt.
> The test steps includes boot and "cat /sys/block/loop*/queue/scheduler".

Thanks! This is exactly the information I was looking for.

I agree that fixing this is better than the revert, since future
-stable patches may
need the functionality as a building block.

Bruce

>
> On 2024-03-13 10:59, Bruce Ashfield wrote:
>
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and 
> know the content is safe.
>
> Since this is requested for the common branches and
> hence all BSPs (This is the right place for a patch
> like this) ... can you provide some extra context
> about how they were identified (and tested).
>
> Similar to my earlier comment, these in theory should
> be nominated for -stable.
>
> Bruce
>
> In message: [linux-yocto][v5.10/standard/base && 
> v5.10/standard/preempt-rt/base][PATCH  1/2]  blk-mq: Introduce the 
> BLK_MQ_F_NO_SCHED_BY_DEFAULT flag
> on 12/03/2024 Wentao Zhang wrote:
>
> From: Bart Van Assche 
>
> commit 90b7198001f23ea37d3b46dc631bdaa2357a20b1 upstream.
>
> elevator_get_default() uses the following algorithm to select an I/O
> scheduler from inside add_disk():
> - In case of a single hardware queue or if sharing hardware queues across
>   multiple request queues (BLK_MQ_F_TAG_HCTX_SHARED), use mq-deadline.
> - Otherwise, use 'none'.
>
> This is a good choice for most but not for all block drivers. Make it
> possible to override the selection of mq-deadline with a new flag,
> namely BLK_MQ_F_NO_SCHED_BY_DEFAULT.
>
> Cc: Christoph Hellwig 
> Cc: Ming Lei 
> Cc: Tetsuo Handa 
> Cc: Martijn Coenen 
> Cc: Jaegeuk Kim 
> Signed-off-by: Bart Van Assche 
> Link: https://lore.kernel.org/r/20210805174200.3250718-2-bvanass...@acm.org
> Signed-off-by: Jens Axboe 
> Signed-off-by: Wentao Zhang 
> ---
>  block/elevator.c   | 3 +++
>  include/linux/blk-mq.h | 6 ++
>  2 files changed, 9 insertions(+)
>
> diff --git a/block/elevator.c b/block/elevator.c
> index 2f962662c32a..f762b2af1d2a 100644
> --- a/block/elevator.c
> +++ b/block/elevator.c
> @@ -622,6 +622,9 @@ static inline bool elv_support_iosched(struct 
> request_queue *q)
>   */
>  static struct elevator_type *elevator_get_default(struct request_queue *q)
>  {
> + if (q->tag_set && q->tag_set->flags & BLK_MQ_F_NO_SCHED_BY_DEFAULT)
> + return NULL;
> +
>   if (q->nr_hw_queues != 1)
>   return NULL;
>
> diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
> index f8ea27423d1d..39526279fbd3 100644
> --- a/include/linux/blk-mq.h
> +++ b/include/linux/blk-mq.h
> @@ -398,7 +398,13 @@ enum {
>   BLK_MQ_F_STACKING   = 1 << 2,
>   BLK_MQ_F_TAG_HCTX_SHARED = 1 << 3,
>   BLK_MQ_F_BLOCKING   = 1 << 5,
> + /* Do not allow an I/O scheduler to be configured. */
>   BLK_MQ_F_NO_SCHED   = 1 << 6,
> + /*
> +  * Select 'none' during queue registration in case of a single hwq
> +  * or shared hwqs instead of 'mq-deadline'.
> +  */
> + BLK_MQ_F_NO_SCHED_BY_DEFAULT= 1 << 7,
>   BLK_MQ_F_ALLOC_POLICY_START_BIT = 8,
>   BLK_MQ_F_ALLOC_POLICY_BITS = 1,
>
> --
> 2.31.1
>
> --
> 
> ☮ Wentao Zhang
> ☮ Wind River Linux
> 



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13682): 
https://lists.yoctoproject.org/g/linux-yocto/message/13682
Mute This Topic: https://lists.yoctoproject.org/mt/104880299/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] Creating ARM64 ISO images

2024-03-13 Thread Nicolas Wirth via lists.yoctoproject.org 
Hey Johnnie, I hope you're doing well !

Did you ever figure this one out ?

Best,
Nicolas

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13681): 
https://lists.yoctoproject.org/g/linux-yocto/message/13681
Mute This Topic: https://lists.yoctoproject.org/mt/94484706/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][v5.15/standard/preempt-rt/sdkv5.15/xlnx-soc][PATCH] sound: xilinx: use hdmi-codec as dp audio codec

2024-03-13 Thread quanyang.wang via lists.yoctoproject.org 
From: Quanyang Wang 

According to the description in the section "Audio Management" of
Chapter 33 in "Zynq UltraScale+ Device Technical Reference Manual",
A set/clr operation to TX_AUDIO_CONTROL register is needed when we
start/stop audio play. It means that when we stop playing audio,
TX_AUDIO_CONTROL register should be cleared. Now the dp codec driver
xilinx-dp-codec.c can't access DP Tx registers and it has no control
of DP Tx Audio registers. This results that even if we close the audio
device after playing audio, Tx Audio is still working and it triggers
numerous underflow interrupts (bit 17 in DP_INT_STATUS).

zcu102-zynqmp:~$ cat /proc/interrupts | grep display
 52:1063792000   GICv2 151 Level   fd4a.display

zcu102-zynqmp:~$ top
Mem: 158168K used, 3864792K free, 9992K shrd, 0K buff, 36500K cached
CPU:  0.0% usr  1.0% sys  0.0% nic 98.9% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 0.03 0.03 0.01 1/122 391
  PID  PPID USERSTAT   VSZ %VSZ CPU %CPU COMMAND
  223 2 rootSW   0  0.0   0  0.9 [irq/52-fd4a]
  352 1 rootS94148  2.3   0  0.0 /usr/sbin/tcf-agent -d -L- -l0

So we register a HDMI codec device and use callbacks in hdmi_codec_ops
to set/clr TX_AUDIO_CONTROL.

Signed-off-by: Quanyang Wang 
---
Hi Bruce,
Would you please help merge this patch to the branches:
v5.15/standard/preempt-rt/sdkv5.15/xlnx-soc
v5.15/standard/sdkv5.15/xlnx-soc
Thanks,
Quanyang
---
 drivers/gpu/drm/xlnx/zynqmp_dp.c  | 55 +++
 sound/soc/xilinx/Kconfig  |  1 +
 sound/soc/xilinx/xilinx-dp-card.c | 14 ++--
 3 files changed, 59 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index 308404f122957..c9badbfe5b566 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "zynqmp_disp.h"
 #include "zynqmp_dp.h"
@@ -329,6 +330,7 @@ struct zynqmp_dp {
void __iomem *iomem;
struct reset_control *reset;
int irq;
+   struct platform_device *audio_pdev;
 
struct zynqmp_dp_config config;
struct drm_dp_aux aux;
@@ -375,6 +377,53 @@ static void zynqmp_dp_set(void __iomem *base, int offset, 
u32 set)
zynqmp_dp_write(base, offset, zynqmp_dp_read(base, offset) | set);
 }
 
+static int zynqmp_dp_audio_hw_params(struct device *dev,  void *data,
+  struct hdmi_codec_daifmt *daifmt,
+  struct hdmi_codec_params *params)
+{
+   return 0;
+}
+
+static int zynqmp_dp_audio_startup(struct device *dev, void *data)
+{
+   struct zynqmp_dp *dp = data;
+
+   if (zynqmp_disp_aud_enabled(dp->dpsub->disp))
+   zynqmp_dp_write(dp->iomem, ZYNQMP_DP_TX_AUDIO_CONTROL, 1);
+
+   return 0;
+}
+
+static void zynqmp_dp_audio_shutdown(struct device *dev, void *data)
+{
+   struct zynqmp_dp *dp = data;
+
+   if (zynqmp_disp_aud_enabled(dp->dpsub->disp))
+   zynqmp_dp_write(dp->iomem, ZYNQMP_DP_TX_AUDIO_CONTROL, 0);
+}
+
+static const struct hdmi_codec_ops audio_codec_ops = {
+   .hw_params = zynqmp_dp_audio_hw_params,
+   .audio_shutdown = zynqmp_dp_audio_shutdown,
+   .audio_startup = zynqmp_dp_audio_startup,
+};
+
+static int zynqmp_dp_audio_init(struct zynqmp_dp *dp,
+  struct device *dev)
+{
+   struct hdmi_codec_pdata codec_data = {
+   .ops = _codec_ops,
+   .spdif = 1,
+   .data = dp,
+   };
+
+   dp->audio_pdev = platform_device_register_data(
+dev, HDMI_CODEC_DRV_NAME, PLATFORM_DEVID_NONE,
+_data, sizeof(codec_data));
+
+   return PTR_ERR_OR_ZERO(dp->audio_pdev);
+}
+
 /* 
-
  * PHY Handling
  */
@@ -1950,6 +1999,12 @@ int zynqmp_dp_probe(struct platform_device *pdev)
goto error;
}
 
+   ret = zynqmp_dp_audio_init(dp, dp->dev);
+   if (ret < 0) {
+   dev_err(dp->dev, "failed to initialize DP audio codec\n");
+   goto error;
+   }
+
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
ret = irq;
diff --git a/sound/soc/xilinx/Kconfig b/sound/soc/xilinx/Kconfig
index ade55b32a8cc6..787b92a406a23 100644
--- a/sound/soc/xilinx/Kconfig
+++ b/sound/soc/xilinx/Kconfig
@@ -3,6 +3,7 @@ config SND_SOC_XILINX_DP
tristate "Audio support for the the Xilinx DisplayPort"
select SND_DMAENGINE_PCM
select SND_SOC_GENERIC_DMAENGINE_PCM
+   select SND_SOC_HDMI_CODEC
help
  Audio support the for Xilinx DisplayPort.
 
diff --git a/sound/soc/xilinx/xilinx-dp-card.c 
b/sound/soc/xilinx/xilinx-dp-card.c
index 396a87d56394f..ec0682f2a7a6c 100644
--- a/sound/soc/xilinx/xilinx-dp-card.c
+++

Re: [linux-yocto][v5.10/standard/base && v5.10/standard/preempt-rt/base][PATCH 1/2] blk-mq: Introduce the BLK_MQ_F_NO_SCHED_BY_DEFAULT flag

2024-03-13 Thread Wentao Zhang via lists.yoctoproject.org 
832a4d4cdb3f612d5079aadcc67a44f18fa7b5b7 
 
in 5.10 did the patch back from 2112f5c1330a671fa852051d85cb9eadc05d7eb7 
 
in upstream.


2112f5c1330a671fa852051d85cb9eadc05d7eb7 
 
add BLK_MQ_F_NO_SCHED_BY_DEFAULT to tag_set.flags in loop device in the 
upstream, but


832a4d4cdb3f612d5079aadcc67a44f18fa7b5b7 
 
add  BLK_MQ_F_NO_SCHED  to tag_set.flags in loop 
device in the 5.10.


this backport cause elv_support_iosched return false, then loop device 
get no scheduler. As shown in the following record:


   root@intel-x86-64:~# cat /sys/block/sda/queue/scheduler
   [mq-deadline] kyber bfq none
   root@intel-x86-64:~# cat /sys/block/loop2/queue/scheduler
   [none]

To solve this problem, we can backport the patch from upstream 
correctly, or revert 832a4d4cdb3f612d5079aadcc67a44f18fa7b5b7 
.


The loop device gets schedulers after applying the patch I submitted.
I did the test in intel-x86-64 with linux-yocto, qemux86-64 
with linux-yocto and qemux86-64 with linux-yocto-rt.

The test steps includes boot and "cat /sys/block/loop*/queue/scheduler".

On 2024-03-13 10:59, Bruce Ashfield wrote:

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

Since this is requested for the common branches and
hence all BSPs (This is the right place for a patch
like this) ... can you provide some extra context
about how they were identified (and tested).

Similar to my earlier comment, these in theory should
be nominated for -stable.

Bruce

In message: [linux-yocto][v5.10/standard/base && 
v5.10/standard/preempt-rt/base][PATCH  1/2]  blk-mq: Introduce the 
BLK_MQ_F_NO_SCHED_BY_DEFAULT flag
on 12/03/2024 Wentao Zhang wrote:


From: Bart Van Assche

commit 90b7198001f23ea37d3b46dc631bdaa2357a20b1 upstream.

elevator_get_default() uses the following algorithm to select an I/O
scheduler from inside add_disk():
- In case of a single hardware queue or if sharing hardware queues across
   multiple request queues (BLK_MQ_F_TAG_HCTX_SHARED), use mq-deadline.
- Otherwise, use 'none'.

This is a good choice for most but not for all block drivers. Make it
possible to override the selection of mq-deadline with a new flag,
namely BLK_MQ_F_NO_SCHED_BY_DEFAULT.

Cc: Christoph Hellwig
Cc: Ming Lei
Cc: Tetsuo Handa
Cc: Martijn Coenen
Cc: Jaegeuk Kim
Signed-off-by: Bart Van Assche
Link:https://lore.kernel.org/r/20210805174200.3250718-2-bvanass...@acm.org
Signed-off-by: Jens Axboe
Signed-off-by: Wentao Zhang
---
  block/elevator.c   | 3 +++
  include/linux/blk-mq.h | 6 ++
  2 files changed, 9 insertions(+)

diff --git a/block/elevator.c b/block/elevator.c
index 2f962662c32a..f762b2af1d2a 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -622,6 +622,9 @@ static inline bool elv_support_iosched(struct request_queue 
*q)
   */
  static struct elevator_type *elevator_get_default(struct request_queue *q)
  {
+ if (q->tag_set && q->tag_set->flags & BLK_MQ_F_NO_SCHED_BY_DEFAULT)
+ return NULL;
+
   if (q->nr_hw_queues != 1)
   return NULL;

diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index f8ea27423d1d..39526279fbd3 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -398,7 +398,13 @@ enum {
   BLK_MQ_F_STACKING   = 1 << 2,
   BLK_MQ_F_TAG_HCTX_SHARED = 1 << 3,
   BLK_MQ_F_BLOCKING   = 1 << 5,
+ /* Do not allow an I/O scheduler to be configured. */
   BLK_MQ_F_NO_SCHED   = 1 << 6,
+ /*
+  * Select 'none' during queue registration in case of a single hwq
+  * or shared hwqs instead of 'mq-deadline'.
+  */
+ BLK_MQ_F_NO_SCHED_BY_DEFAULT= 1 << 7,
   BLK_MQ_F_ALLOC_POLICY_START_BIT = 8,
   BLK_MQ_F_ALLOC_POLICY_BITS = 1,

--
2.31.1


--

☮ Wentao Zhang
☮ Wind River Linux


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13679): 
https://lists.yoctoproject.org/g/linux-yocto/message/13679
Mute This Topic: https://lists.yoctoproject.org/mt/104880299/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][v5.15/standard/base][PATCH] locking/rwsem: Disable preemption while trying for rwsem lock

2024-03-13 Thread Li Wang via lists.yoctoproject.org 


On 3/13/2024 10:55, Bruce Ashfield wrote:

In message: [linux-yocto][v5.15/standard/base][PATCH] locking/rwsem: Disable 
preemption while trying for rwsem lock
on 10/03/2024 Li Wang via lists.yoctoproject.org wrote:


From: Gokul krishna Krishnakumar 

commit 48dfb5d2560d36fb16c7d430c229d1604ea7d185 upstream

Make the region inside the rwsem_write_trylock non preemptible.

We observe RT task is hogging CPU when trying to acquire rwsem lock
which was acquired by a kworker task but before the rwsem owner was set.

Here is the scenario:
1. CFS task (affined to a particular CPU) takes rwsem lock.

2. CFS task gets preempted by a RT task before setting owner.

3. RT task (FIFO) is trying to acquire the lock, but spinning until
RT throttling happens for the lock as the lock was taken by CFS task.

This patch attempts to fix the above issue by disabling preemption
until owner is set for the lock. While at it also fix the issues
at the places where rwsem_{set,clear}_owner() are called.

This also adds lockdep annotation of preemption disable in
rwsem_{set,clear}_owner() on Peter Z. suggestion.

Any thoughts on why this hasn't been picked up by -stable ?


submitter want the patch into linux stable 5.10, but miss the receiver 
mail of stable.


we will wait the reply from the maintainer of stable:

https://lore.kernel.org/all/b92644e5-529b-4403-aba7-d316262cc...@redhat.com/

Thanks,
LiWang.



Bruce


Signed-off-by: Gokul krishna Krishnakumar 
Signed-off-by: Mukesh Ojha 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Waiman Long 
Link: 
https://lore.kernel.org/r/1662661467-24203-1-git-send-email-quic_mo...@quicinc.com
Signed-off-by: Beniamin Sandu 
Signed-off-by: Li Wang 
---
  kernel/locking/rwsem.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c
index f0287a16b4ec..4a38d32b89fa 100644
--- a/kernel/locking/rwsem.c
+++ b/kernel/locking/rwsem.c
@@ -133,14 +133,19 @@
   * the owner value concurrently without lock. Read from owner, however,
   * may not need READ_ONCE() as long as the pointer value is only used
   * for comparison and isn't being dereferenced.
+ *
+ * Both rwsem_{set,clear}_owner() functions should be in the same
+ * preempt disable section as the atomic op that changes sem->count.
   */
  static inline void rwsem_set_owner(struct rw_semaphore *sem)
  {
+   lockdep_assert_preemption_disabled();
atomic_long_set(>owner, (long)current);
  }
  
  static inline void rwsem_clear_owner(struct rw_semaphore *sem)

  {
+   lockdep_assert_preemption_disabled();
atomic_long_set(>owner, 0);
  }
  
@@ -251,13 +256,16 @@ static inline bool rwsem_read_trylock(struct rw_semaphore *sem, long *cntp)

  static inline bool rwsem_write_trylock(struct rw_semaphore *sem)
  {
long tmp = RWSEM_UNLOCKED_VALUE;
+   bool ret = false;
  
+	preempt_disable();

if (atomic_long_try_cmpxchg_acquire(>count, , 
RWSEM_WRITER_LOCKED)) {
rwsem_set_owner(sem);
-   return true;
+   ret = true;
}
  
-	return false;

+   preempt_enable();
+   return ret;
  }
  
  /*

@@ -1341,8 +1349,10 @@ static inline void __up_write(struct rw_semaphore *sem)
DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) &&
!rwsem_test_oflags(sem, RWSEM_NONSPINNABLE), sem);
  
+	preempt_disable();

rwsem_clear_owner(sem);
tmp = atomic_long_fetch_add_release(-RWSEM_WRITER_LOCKED, >count);
+   preempt_enable();
if (unlikely(tmp & RWSEM_FLAG_WAITERS))
rwsem_wake(sem);
  }
--
2.25.1




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13678): 
https://lists.yoctoproject.org/g/linux-yocto/message/13678
Mute This Topic: https://lists.yoctoproject.org/mt/104857955/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-