Re: [linux-yocto] v5.2.x - stable updates comprising v5.2.22

2019-11-10 Thread Quanyang Wang 

Hi Bruce,

On 11/11/19 11:36 AM, Bruce Ashfield wrote:

On Sun, Nov 10, 2019 at 12:05 AM Paul Gortmaker
 wrote:

Bruce, Yocto kernel folks:

Here is the first 5.2.x stable update "extension" primarily created for
the Yocto project, continuing from the last v5.2.21 EOL release from the
normal stable-kernel feed/stream.

As the 1st extension update, it is probably worthwhile to remind people
that the work here is stacked on top of the existing vanilla
linux-stable work and isn't Yocto specific in any way -- other than
filling a need for the Yocto project kernel needs.

Non Yocto users with a 5.2.x kernel are also encouraged to make use of
the work, just as the 4.8, 4.12 and 4.18 stable extension work done in
the past.  Content is chosen by monitoring non-EOL stable releases, CVEs
and similar, and is released in a fashion as close as possible to the
primary stable-kernel feed that people are used to.

More specifically, for this 5.2.22 release, it contains about 235 mainline
commits based on what was found in 5.3.6 and 5.3.7 stable content.

I've put this 5.2.22 queue through the usual testing; build testing on
x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis and
finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v5.2.22 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   
https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-5.2.y.git/?h=linux-5.2.y
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-5.2.y.git

for merge to standard/base in linux-yocto-5.2 and then out from there
into the other base and BSP branches.

This is merged, that being said .. there are a couple of things that
could use a second set of eyes.

1) I had a preempt-rt conflict in fs/libfs.c. It looks like
scan_positives() was introduced. The merge picked up a conflict, when
really it should have just been the introduction of that new function
and a drop of the old ones. But again, a 2nd set of eyes to see if I
read it right would be nice.

2) there was a conflict in v5.2/standard/xlnx-soc in
drivers/tty/serial/uartlite.c. There's a minor change in the driver
unregistration. I resolved he conflict, but there now might be two
unregister calls .. and I'm not sure how well that'll work. I copied
Quanyang, to have a look and see if I got it right.


The commit 7dba6bf5f7d8 ("serial: uartlite: fix exit path null pointer") 
should be


dropped because that the commit 4eed93c3703b ("serial-uartlite: Remove 
ULITE_NR_PORTS macro")


which is picked from SDK has moved "uart_unregister_driver" from 
ulite_exit to ulite_remove, and


there is no global variable "ulite_uart_driver" anymore.

Do I need to send a revert patch to revert it in v5.2/standard/xlnx-soc 
branch?


Thanks,

Quanyang



Cheers,

Bruce


For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-5.2.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 5.2.x release.

Paul.



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

--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH 2/3] drivers: soc: xilinx: fix compile warning by defining payload array length to 12

2019-11-04 Thread Quanyang Wang 

Hi Michal,

On 11/4/19 7:51 PM, Michal Simek wrote:

On 29. 10. 19 8:56, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

In include/linux/mailbox/zynqmp-ipi-message.h, it says that
the maximum length of data buffer is fixed to 12 bytes. So
define payload array length to 12 to fix compile warning as
below:

drivers/soc/xilinx/zynqmp_power.c:91:2: warning: ISO C90 forbids variable 
length array 'payload' [-Wvla]
91 |  u32 payload[msg->len];
   |  ^~~

Signed-off-by: Quanyang Wang 
---
  drivers/soc/xilinx/zynqmp_power.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/xilinx/zynqmp_power.c 
b/drivers/soc/xilinx/zynqmp_power.c
index 663010658b2a..0036d013aacd 100644
--- a/drivers/soc/xilinx/zynqmp_power.c
+++ b/drivers/soc/xilinx/zynqmp_power.c
@@ -88,7 +88,7 @@ static irqreturn_t zynqmp_pm_isr(int irq, void *data)
  static void ipi_receive_callback(struct mbox_client *cl, void *data)
  {
struct zynqmp_ipi_message *msg = (struct zynqmp_ipi_message *)data;
-   u32 payload[msg->len];
+   u32 payload[12];
int ret;
  
  	memcpy(payload, msg->data, sizeof(msg->len));



I don't think it is good idea to put magic numbers to the driver. That's
why create macro in correct header with proper name and use it.


OK, I will send a V2 patch.

Thanks,

Quanyang



M



--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 0/1][V2]patches for xilinx

2019-11-03 Thread Quanyang Wang 

Hi Bruce,

On 10/25/19 1:20 AM, Bruce Ashfield wrote:

On Thu, Oct 24, 2019 at 6:26 AM  wrote:

From: Quanyang Wang 

Hi all,

V1 ---> V2:

1. delete the patch "arch: arm64: dts: add overlay dts file" because it is 
improper
to add into kernel source.

2. modify the patch " i2c: cadence: do not clear bus_hold_flag in mrecv" by 
adding
a I2C_M_NOSTART flag check according to Shubhrajyoti's suggestion. And test it 
at
zcu102 board (read bus 0x8 device 0x65 (ucd10120) register 0xd6)as below:
Before applying this patch:
root@xilinx-zynq:~# i2cget -f -y 0x8 0x65 0xd6
0xff
After applying this patch:
root@xilinx-zynq:~# i2cget -f -y 0x8 0x65 0xd6
0x05


I'll wait for comments on this patch.


This patch has been reviewed. Would you please help merge it to 
v5.2/standard/xlnx-soc?


Thanks,

Quanyang



I just wanted to follow up to say that I *think* that I have all of
the reviewed and ack'd patches merged now .. but gmail is doing some
very strange things and hiding replies to some of the threads.

So if you see something that is reviewed/acked and is missing, send it
again with a clear "v2" (or whatever version it is) in the subject.

Bruce


Thanks,
Quanyang

Quanyang Wang (1):
   i2c: cadence: keep bus_hold_flag unless I2C_M_NOSTART is set

  drivers/i2c/busses/i2c-cadence.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

--
2.17.1




--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH 1/1] xilinx-zyqn: Move disable_nonboot_cpus() in front of local_irq_disable()

2019-10-24 Thread Quanyang Wang 

Hi Michal,

On 10/23/19 6:55 PM, Michal Simek wrote:

On 21. 10. 19 14:13, qwang2 wrote:

Hi Michal,

On 2019/10/21 下午6:45, Michal Simek wrote:

On 21. 10. 19 10:45, Quanyang Wang wrote:

Hi Michal,

On 10/21/19 4:16 PM, Michal Simek wrote:

On 21. 10. 19 7:50, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

When run kdump with enabling CONFIG_DEBUG_PREEMPT, there is a
calltrace
as below:

BUG: using smp_processor_id() in preemptible [] code: sh/303
caller is machine_crash_shutdown+0x2c/0xe8
CPU: 0 PID: 303 Comm: sh Kdump: loaded Not tainted
5.2.20-yocto-standard #1
Hardware name: Xilinx Zynq Platform
[<80112ff4>] (unwind_backtrace) from [<8010ca4c>]
(show_stack+0x18/0x1c)
[<8010ca4c>] (show_stack) from [<809b000c>] (dump_stack+0x70/0x8c)
[<809b000c>] (dump_stack) from [<80549a14>]
(debug_smp_processor_id+0xd4/0x118)
[<80549a14>] (debug_smp_processor_id) from [<80111428>]
(machine_crash_shutdown+0x2c/0xe8)
[<80111428>] (machine_crash_shutdown) from [<801afe24>]
(__crash_kexec+0x70/0xd0)
[<801afe24>] (__crash_kexec) from [<801259b4>] (panic+0x110/0x324)
[<801259b4>] (panic) from [<805f7018>] (sysrq_handle_crash+0x18/0x1c)
[<805f7018>] (sysrq_handle_crash) from [<805f7584>]
(__handle_sysrq+0x9c/0x14c)
[<805f7584>] (__handle_sysrq) from [<805f79e8>]
(write_sysrq_trigger+0x5c/0x6c)
[<805f79e8>] (write_sysrq_trigger) from [<8031e850>]
(proc_reg_write+0x78/0x8c)
[<8031e850>] (proc_reg_write) from [<802b1b28>] (vfs_write+0xc0/0x154)
[<802b1b28>] (vfs_write) from [<802b2a64>] (ksys_write+0x6c/0xd4)
[<802b2a64>] (ksys_write) from [<80101000>]
(ret_fast_syscall+0x0/0x54)
Exception stack(0xba157fa8 to 0xba157ff0)
7fa0: 0002 005ab930 0001 005ab930 0002 
7fc0: 0002 005ab930 76fa2290 0004 76f3d124 76f3cc8c 

7fe0: 0004 7edec940 76edbfff 76e67d16

This is because that the function disable_nonboot_cpus is called in
order to make sure that the crash kernel runs in the boot CPU(cpu0).
And it will enable local irq by calling as below:

disable_nonboot_cpus
    -> freeze_secondary_cpus
     -> _cpu_down
  -> percpu_down_write
   -> rcu_sync_enter
    -> spin_unlock_irq(>rss_lock)
     -> local_irq_enable()

Then the functions including smp_processor_id() behind
disable_nonboot_cpus
will run at the irq-enabled context, and this will trigger the
calltrace.

So move disable_nonboot_cpus() in front of local_irq_disable() to
avoid
it since disable_nonboot_cpus() not need run at an atomic context.

Signed-off-by: Quanyang Wang 
---
    arch/arm/kernel/machine_kexec.c | 3 ++-
    1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/machine_kexec.c
b/arch/arm/kernel/machine_kexec.c
index 654f2b1f9ac0..83d2025a4ab1 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -145,9 +145,10 @@ static void machine_kexec_mask_interrupts(void)
      void machine_crash_shutdown(struct pt_regs *regs)
    {
-    local_irq_disable();
    disable_nonboot_cpus();
    +    local_irq_disable();
+
    crash_smp_send_stop();
      crash_save_cpu(regs, smp_processor_id());


ok. Can you please check before this if your usecases work without
disable_nonboot_cpus(). This patch was done pretty long time ago where
there was an issue with kexec. Long time ago I was talking to arm-soc
maintainers about this and they told me that mainline code should work
fine without any need to call disable_nonboot_cpus().
It means if kexec is working fine we can revert origin patch and use
what mainline is using.

It seems that the issue is still there. When crash at cpu1 and crash
kernel runs at cpu1,

it will hang, the log is as below:

root@xilinx-zynq:~# sh 1.sh
syscall kexec_file_load not available.
sysrq: Trigger a crash
Kernel panic - not syncing: sysrq triggered crash
CPU: 1 PID: 308 Comm: sh Kdump: loaded Not tainted
5.2.20-yocto-standard #4
Hardware name: Xilinx Zynq Platform
[<80112eb0>] (unwind_backtrace) from [<8010cc04>] (show_stack+0x18/0x1c)
[<8010cc04>] (show_stack) from [<8094f8f4>] (dump_stack+0x70/0x8c)
[<8094f8f4>] (dump_stack) from [<801256f4>] (panic+0xf8/0x320)
[<801256f4>] (panic) from [<805dbeb0>] (sysrq_handle_crash+0x18/0x1c)
[<805dbeb0>] (sysrq_handle_crash) from [<805dc3b8>]
(__handle_sysrq+0x9c/0x148)
[<805dc3b8>] (__handle_sysrq) from [<805dc804>]
(write_sysrq_trigger+0x5c/0x6c)
[<805dc804>] (write_sysrq_trigger) from [<8031b040>]
(proc_reg_write+0x78/0x8c)
[<8031b040>] (proc_reg_write) from [<802aeec4>] (vfs_write+0xc0/0x154)
[<802aeec4>] (vfs_write) from [<802afd18>] (ksys_write+0x64/0xc8)
[<802afd18>] (ksys_write) from [<80101000>] (ret_fast_syscall+0x0/0x54)
Exception stack(0xb905bfa8 to 0xb905bff0)

Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 1/2] i2c: cadence: do not clear bus_hold_flag in mrecv

2019-10-23 Thread Quanyang Wang 

Hi Shubhrajyoti,

On 10/23/19 5:17 PM, Shubhrajyoti Datta wrote:

Hi ,


-Original Message-
From: Quanyang Wang 
Sent: Wednesday, October 23, 2019 2:24 PM
To: Michal Simek ; Bruce ;
Shubhrajyoti Datta 
Cc: linux-yocto@yoctoproject.org; git 
Subject: Re: [linux-yocto][kernel v5.2/standard/xlnx-soc][PATCH 1/2] i2c:
cadence: do not clear bus_hold_flag in mrecv

Hi,

On 10/14/19 2:07 PM, Michal Simek wrote:

On 13. 10. 19 15:33, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

When using i2c_smbus_read_byte_data to read one byte from a slave
device, because of the commit d358def70688
("i2c: cadence: Fix the hold bit setting"), the transaction becomes:

S Addr Wr [A] Comm [A] P S Addr Rd [A] [Data] NA P
 ^
  CR_HOLD bit as 0

This will result that the read operation fails and will read "0xff"
from the slave device. In the SMBus protocol stipulates that it must
follow that command with a repeated START condition as below:

S Addr Wr [A] Comm [A] Sr Addr Rd [A] [Data] NA P

So keep CR_HOLD bit to be 1 to make sure that the read operation
begins with a Sr (repeated START) but not a STOP followed by START.

Signed-off-by: Quanyang Wang 
---
   drivers/i2c/busses/i2c-cadence.c | 2 --
   1 file changed, 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-cadence.c
b/drivers/i2c/busses/i2c-cadence.c
index 6b011931e090..d9493914be15 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -626,8 +626,6 @@ static void cdns_i2c_mrecv(struct cdns_i2c *id)
 */
if ((id->recv_count > CDNS_I2C_FIFO_DEPTH)  || id->bus_hold_flag)
ctrl_reg |= CDNS_I2C_CR_HOLD;
-   else
-   ctrl_reg = ctrl_reg & ~CDNS_I2C_CR_HOLD;

cdns_i2c_writereg(ctrl_reg, CDNS_I2C_CR_OFFSET);



Shubhrajyoti: Can you please comment?

Any comment?

I am not finding code segment in the tree
I am checking

https://gitenterprise.xilinx.com/Linux/linux-xlnx/blob/master/drivers/i2c/busses/i2c-cadence.c

maybe you can try moving to the latest code.


And when SDK kernel applies with this patch "i2c: cadence: Fix the hold 
bit setting",


using i2c_smbus_read_byte_data to access ucd90120 
(drivers/hwmon/pmbus/ucd9000.c) in the board zc706 can reproduce this error.


Thanks,

Quanyang


M
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 1/2] i2c: cadence: do not clear bus_hold_flag in mrecv

2019-10-23 Thread Quanyang Wang 

Hi,

On 10/14/19 2:07 PM, Michal Simek wrote:

On 13. 10. 19 15:33, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

When using i2c_smbus_read_byte_data to read one byte from a
slave device, because of the commit d358def70688
("i2c: cadence: Fix the hold bit setting"), the transaction becomes:

S Addr Wr [A] Comm [A] P S Addr Rd [A] [Data] NA P
^
 CR_HOLD bit as 0

This will result that the read operation fails and will read "0xff" from
the slave device. In the SMBus protocol stipulates that it must follow that
command with a repeated START condition as below:

S Addr Wr [A] Comm [A] Sr Addr Rd [A] [Data] NA P

So keep CR_HOLD bit to be 1 to make sure that the read operation begins
with a Sr (repeated START) but not a STOP followed by START.

Signed-off-by: Quanyang Wang 
---
  drivers/i2c/busses/i2c-cadence.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index 6b011931e090..d9493914be15 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -626,8 +626,6 @@ static void cdns_i2c_mrecv(struct cdns_i2c *id)
 */
if ((id->recv_count > CDNS_I2C_FIFO_DEPTH)  || id->bus_hold_flag)
ctrl_reg |= CDNS_I2C_CR_HOLD;
-   else
-   ctrl_reg = ctrl_reg & ~CDNS_I2C_CR_HOLD;
  
  	cdns_i2c_writereg(ctrl_reg, CDNS_I2C_CR_OFFSET);
  


Shubhrajyoti: Can you please comment?

Any comment?


M

--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH 1/1] dma: xilinx: dpdma: alloc xilinx_dpdma_tx_desc using GFP_ATOMIC

2019-10-22 Thread Quanyang Wang 


On 10/18/19 10:42 PM, Radhey Shyam Pandey wrote:

-Original Message-
From: Hyun Kwon 
Sent: Thursday, October 17, 2019 11:01 PM
To: Quanyang Wang 
Cc: Hyun Kwon ; Michal Simek ;
Bruce ; linux-yocto@yoctoproject.org; Radhey
Shyam Pandey 
Subject: Re: [linux-yocto][PATCH 1/1] dma: xilinx: dpdma: alloc
xilinx_dpdma_tx_desc using GFP_ATOMIC

Hi Quanyang,

+ Radhey

On Wed, 2019-10-16 at 20:11:39 -0700, Quanyang Wang wrote:

On 10/17/19 1:01 AM, Hyun Kwon wrote:

Hi Quanyang,

Thanks for the patch.

On Tue, 2019-10-15 at 22:49:41 -0700, Michal Simek wrote:

+Hyun,

On 15. 10. 19 16:56, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

The function xilinx_dpdma_chan_alloc_tx_desc can be called
from atomic context, hence use GFP_ATOMIC instead of GFP_KERNEL,
or else it will cause the calltrace as below:

BUG: sleeping function called from invalid context at mm/slab.h:418
in_atomic(): 1, irqs_disabled(): 128, pid: 416, name: alsa-sink-(null

Preemption disabled at:

[] snd_pcm_stream_lock_irq+0x40/0x50
CPU: 2 PID: 416 Comm: alsa-sink-(null Tainted: G O 5.2.17-yocto-

standard #1

Hardware name: ZynqMP ZCU102 Rev1.0 (DT) Call trace:
dump_backtrace+0x0/0x138
show_stack+0x24/0x30
dump_stack+0x94/0xbc
___might_sleep+0x14c/0x178
__might_sleep+0x58/0x90
kmem_cache_alloc_trace+0x1a4/0x300
xilinx_dpdma_chan_alloc_tx_desc.isra.0+0x24/0x40
xilinx_dpdma_prep_dma_cyclic+0xc0/0x208
snd_dmaengine_pcm_trigger+0xf8/0x198
soc_pcm_trigger+0xb4/0x128
snd_pcm_do_start+0x48/0x58
snd_pcm_action_single+0x4c/0xa0
snd_pcm_action+0x78/0x90
snd_pcm_action_lock_irq+0x3c/0x60
snd_pcm_common_ioctl+0x4ac/0x10c8
snd_pcm_ioctl+0x48/0x68
do_vfs_ioctl+0x6d4/0x968
ksys_ioctl+0x84/0xb8
__arm64_sys_ioctl+0x28/0x38
el0_svc_common.constprop.0+0x74/0x180
el0_svc_handler+0x70/0x90
el0_svc+0x8/0xc

Signed-off-by: Quanyang Wang 

Maybe the 'nonatomic' can be set to true in xilinx_dp_dai_links? But I

don't

know much about the flag, ex what's required, and I don't see any

problem with

this change. So,

   Reviewed-by: Hyun Kwon 

Hi Hyun,

Thank you for looking this patch over.

I test and the "nonatomic" can also eliminate the calltrace.  But I
don't know if there is any

problem with alsa driver running in a nonatomic context.

Me neither, so maybe changing gfp flag seems safer in that aspect. :-)


And do you think it's better using GFP_NOWAIT instead of GFP_ATOMIC ?
This can save some atomic memory.

In my limited view, GFP_ATOMIC seems better as the allocation is relatively
small but related to IO, rather than relying only on page reclaim. I see both
are quite commonly used for dma descriptor allocation, so it doesn't seem
like
one is clearly better than the other. But I may be wrong. Radhey may have
better answer.

_NOWAIT is like _ATOMIC except that no wait will not fall back to emergency
pools. http://lkml.iu.edu/hypermail/linux/kernel/0911.1/02316.html
IMO if allocation is in critical path and small then GFP_ATOMIC can be used
else switching to _NOWAIT might be preferred.


Hi Radhey,

Thank you for your suggestion.

Since xilinx_dpdma_tx_desc is small, it seems that GFP_ATOMIC is better.

Thanks,

Quanyang




Thanks,
-hyun

--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH 1/1] xilinx-zyqn: Move disable_nonboot_cpus() in front of local_irq_disable()

2019-10-21 Thread Quanyang Wang 



On 10/21/19 8:05 PM, Bruce Ashfield wrote:

On Mon, Oct 21, 2019 at 6:45 AM Michal Simek  wrote:

On 21. 10. 19 10:45, Quanyang Wang wrote:

Hi Michal,

On 10/21/19 4:16 PM, Michal Simek wrote:

On 21. 10. 19 7:50, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

When run kdump with enabling CONFIG_DEBUG_PREEMPT, there is a calltrace
as below:

BUG: using smp_processor_id() in preemptible [] code: sh/303
caller is machine_crash_shutdown+0x2c/0xe8
CPU: 0 PID: 303 Comm: sh Kdump: loaded Not tainted
5.2.20-yocto-standard #1
Hardware name: Xilinx Zynq Platform
[<80112ff4>] (unwind_backtrace) from [<8010ca4c>] (show_stack+0x18/0x1c)
[<8010ca4c>] (show_stack) from [<809b000c>] (dump_stack+0x70/0x8c)
[<809b000c>] (dump_stack) from [<80549a14>]
(debug_smp_processor_id+0xd4/0x118)
[<80549a14>] (debug_smp_processor_id) from [<80111428>]
(machine_crash_shutdown+0x2c/0xe8)
[<80111428>] (machine_crash_shutdown) from [<801afe24>]
(__crash_kexec+0x70/0xd0)
[<801afe24>] (__crash_kexec) from [<801259b4>] (panic+0x110/0x324)
[<801259b4>] (panic) from [<805f7018>] (sysrq_handle_crash+0x18/0x1c)
[<805f7018>] (sysrq_handle_crash) from [<805f7584>]
(__handle_sysrq+0x9c/0x14c)
[<805f7584>] (__handle_sysrq) from [<805f79e8>]
(write_sysrq_trigger+0x5c/0x6c)
[<805f79e8>] (write_sysrq_trigger) from [<8031e850>]
(proc_reg_write+0x78/0x8c)
[<8031e850>] (proc_reg_write) from [<802b1b28>] (vfs_write+0xc0/0x154)
[<802b1b28>] (vfs_write) from [<802b2a64>] (ksys_write+0x6c/0xd4)
[<802b2a64>] (ksys_write) from [<80101000>] (ret_fast_syscall+0x0/0x54)
Exception stack(0xba157fa8 to 0xba157ff0)
7fa0: 0002 005ab930 0001 005ab930 0002 
7fc0: 0002 005ab930 76fa2290 0004 76f3d124 76f3cc8c 

7fe0: 0004 7edec940 76edbfff 76e67d16

This is because that the function disable_nonboot_cpus is called in
order to make sure that the crash kernel runs in the boot CPU(cpu0).
And it will enable local irq by calling as below:

disable_nonboot_cpus
   -> freeze_secondary_cpus
-> _cpu_down
 -> percpu_down_write
  -> rcu_sync_enter
   -> spin_unlock_irq(>rss_lock)
-> local_irq_enable()

Then the functions including smp_processor_id() behind
disable_nonboot_cpus
will run at the irq-enabled context, and this will trigger the
calltrace.

So move disable_nonboot_cpus() in front of local_irq_disable() to avoid
it since disable_nonboot_cpus() not need run at an atomic context.

Signed-off-by: Quanyang Wang 
---
   arch/arm/kernel/machine_kexec.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/machine_kexec.c
b/arch/arm/kernel/machine_kexec.c
index 654f2b1f9ac0..83d2025a4ab1 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -145,9 +145,10 @@ static void machine_kexec_mask_interrupts(void)
 void machine_crash_shutdown(struct pt_regs *regs)
   {
-local_irq_disable();
   disable_nonboot_cpus();
   +local_irq_disable();
+
   crash_smp_send_stop();
 crash_save_cpu(regs, smp_processor_id());


ok. Can you please check before this if your usecases work without
disable_nonboot_cpus(). This patch was done pretty long time ago where
there was an issue with kexec. Long time ago I was talking to arm-soc
maintainers about this and they told me that mainline code should work
fine without any need to call disable_nonboot_cpus().
It means if kexec is working fine we can revert origin patch and use
what mainline is using.

It seems that the issue is still there. When crash at cpu1 and crash
kernel runs at cpu1,

it will hang, the log is as below:

root@xilinx-zynq:~# sh 1.sh
syscall kexec_file_load not available.
sysrq: Trigger a crash
Kernel panic - not syncing: sysrq triggered crash
CPU: 1 PID: 308 Comm: sh Kdump: loaded Not tainted 5.2.20-yocto-standard #4
Hardware name: Xilinx Zynq Platform
[<80112eb0>] (unwind_backtrace) from [<8010cc04>] (show_stack+0x18/0x1c)
[<8010cc04>] (show_stack) from [<8094f8f4>] (dump_stack+0x70/0x8c)
[<8094f8f4>] (dump_stack) from [<801256f4>] (panic+0xf8/0x320)
[<801256f4>] (panic) from [<805dbeb0>] (sysrq_handle_crash+0x18/0x1c)
[<805dbeb0>] (sysrq_handle_crash) from [<805dc3b8>]
(__handle_sysrq+0x9c/0x148)
[<805dc3b8>] (__handle_sysrq) from [<805dc804>]
(write_sysrq_trigger+0x5c/0x6c)
[<805dc804>] (write_sysrq_trigger) from [<8031b040>]
(proc_reg_write+0x78/0x8c)
[<8031b040>] (proc_reg_write) from [<802aeec4>] (vfs_write+0xc0/0x154)
[<802aeec4>] (vfs_write) from [<802afd18>] (ksys_write+0x64/0xc8)
[<802afd18>] (ksys_write) from [<80101000>] (ret_fast_syscall+0x0/0x54)
Exception stack(0xb905bfa8 to 0xb905bff0)
bfa0:   0002 0059afa0 0001 0059a

Re: [linux-yocto] [PATCH 1/1] xilinx-zyqn: Move disable_nonboot_cpus() in front of local_irq_disable()

2019-10-21 Thread Quanyang Wang 

Hi Michal,

On 10/21/19 4:16 PM, Michal Simek wrote:

On 21. 10. 19 7:50, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

When run kdump with enabling CONFIG_DEBUG_PREEMPT, there is a calltrace
as below:

BUG: using smp_processor_id() in preemptible [] code: sh/303
caller is machine_crash_shutdown+0x2c/0xe8
CPU: 0 PID: 303 Comm: sh Kdump: loaded Not tainted 5.2.20-yocto-standard #1
Hardware name: Xilinx Zynq Platform
[<80112ff4>] (unwind_backtrace) from [<8010ca4c>] (show_stack+0x18/0x1c)
[<8010ca4c>] (show_stack) from [<809b000c>] (dump_stack+0x70/0x8c)
[<809b000c>] (dump_stack) from [<80549a14>] (debug_smp_processor_id+0xd4/0x118)
[<80549a14>] (debug_smp_processor_id) from [<80111428>] 
(machine_crash_shutdown+0x2c/0xe8)
[<80111428>] (machine_crash_shutdown) from [<801afe24>] 
(__crash_kexec+0x70/0xd0)
[<801afe24>] (__crash_kexec) from [<801259b4>] (panic+0x110/0x324)
[<801259b4>] (panic) from [<805f7018>] (sysrq_handle_crash+0x18/0x1c)
[<805f7018>] (sysrq_handle_crash) from [<805f7584>] (__handle_sysrq+0x9c/0x14c)
[<805f7584>] (__handle_sysrq) from [<805f79e8>] (write_sysrq_trigger+0x5c/0x6c)
[<805f79e8>] (write_sysrq_trigger) from [<8031e850>] (proc_reg_write+0x78/0x8c)
[<8031e850>] (proc_reg_write) from [<802b1b28>] (vfs_write+0xc0/0x154)
[<802b1b28>] (vfs_write) from [<802b2a64>] (ksys_write+0x6c/0xd4)
[<802b2a64>] (ksys_write) from [<80101000>] (ret_fast_syscall+0x0/0x54)
Exception stack(0xba157fa8 to 0xba157ff0)
7fa0: 0002 005ab930 0001 005ab930 0002 
7fc0: 0002 005ab930 76fa2290 0004 76f3d124 76f3cc8c  
7fe0: 0004 7edec940 76edbfff 76e67d16

This is because that the function disable_nonboot_cpus is called in
order to make sure that the crash kernel runs in the boot CPU(cpu0).
And it will enable local irq by calling as below:

disable_nonboot_cpus
  -> freeze_secondary_cpus
   -> _cpu_down
-> percpu_down_write
 -> rcu_sync_enter
  -> spin_unlock_irq(>rss_lock)
   -> local_irq_enable()

Then the functions including smp_processor_id() behind disable_nonboot_cpus
will run at the irq-enabled context, and this will trigger the calltrace.

So move disable_nonboot_cpus() in front of local_irq_disable() to avoid
it since disable_nonboot_cpus() not need run at an atomic context.

Signed-off-by: Quanyang Wang 
---
  arch/arm/kernel/machine_kexec.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index 654f2b1f9ac0..83d2025a4ab1 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -145,9 +145,10 @@ static void machine_kexec_mask_interrupts(void)
  
  void machine_crash_shutdown(struct pt_regs *regs)

  {
-   local_irq_disable();
disable_nonboot_cpus();
  
+	local_irq_disable();

+
crash_smp_send_stop();
  
  	crash_save_cpu(regs, smp_processor_id());



ok. Can you please check before this if your usecases work without
disable_nonboot_cpus(). This patch was done pretty long time ago where
there was an issue with kexec. Long time ago I was talking to arm-soc
maintainers about this and they told me that mainline code should work
fine without any need to call disable_nonboot_cpus().
It means if kexec is working fine we can revert origin patch and use
what mainline is using.


It seems that the issue is still there. When crash at cpu1 and crash 
kernel runs at cpu1,


it will hang, the log is as below:

root@xilinx-zynq:~# sh 1.sh
syscall kexec_file_load not available.
sysrq: Trigger a crash
Kernel panic - not syncing: sysrq triggered crash
CPU: 1 PID: 308 Comm: sh Kdump: loaded Not tainted 5.2.20-yocto-standard #4
Hardware name: Xilinx Zynq Platform
[<80112eb0>] (unwind_backtrace) from [<8010cc04>] (show_stack+0x18/0x1c)
[<8010cc04>] (show_stack) from [<8094f8f4>] (dump_stack+0x70/0x8c)
[<8094f8f4>] (dump_stack) from [<801256f4>] (panic+0xf8/0x320)
[<801256f4>] (panic) from [<805dbeb0>] (sysrq_handle_crash+0x18/0x1c)
[<805dbeb0>] (sysrq_handle_crash) from [<805dc3b8>] 
(__handle_sysrq+0x9c/0x148)
[<805dc3b8>] (__handle_sysrq) from [<805dc804>] 
(write_sysrq_trigger+0x5c/0x6c)
[<805dc804>] (write_sysrq_trigger) from [<8031b040>] 
(proc_reg_write+0x78/0x8c)

[<8031b040>] (proc_reg_write) from [<802aeec4>] (vfs_write+0xc0/0x154)
[<802aeec4>] (vfs_write) from [<802afd18>] (ksys_write+0x64/0xc8)
[<802afd18>] (ksys_write) from [<80101000>] (ret_fast_syscall+0x0/0x54)
Exception stack(0xb905bfa8 to 0xb905bff0)
bfa0:   0002 0059afa0 0001 0059afa0 0002 

bfc0: 0002 0059afa0 76f8e290 0004 76f29124 76f28c8c  


bfe0: 0004 7eb858c0 76ec7fff 76e

Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add kernel options for ZynqMP PL Programming

2019-10-18 Thread Quanyang Wang 



On 10/18/19 2:16 PM, Michal Simek wrote:

On 17. 10. 19 16:58, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

Add kernel options for zynqmp FPGA programming.

Signed-off-by: Quanyang Wang 
---
  bsp/xilinx-zynqmp/xilinx-zynqmp.cfg | 4 
  1 file changed, 4 insertions(+)

diff --git a/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg 
b/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg
index fe8ae24d..b87c2892 100644
--- a/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg
+++ b/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg
@@ -234,3 +234,7 @@ CONFIG_RESET_CONTROLLER=y
  
  CONFIG_PMBUS=y

  CONFIG_SENSORS_MAX20751=y
+
+CONFIG_OF_OVERLAY=y
+CONFIG_OF_CONFIGFS=y
+CONFIG_FPGA_MGR_DEBUG_FS=y


Just keep in your mind that configfs is out of mainline and it should be
used carefully.


Hi Michal,

OK. Thanks for your reminding.

Quanyang


M

--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH 1/1] clk: zynqmp: fix memory leak in zynqmp_register_clocks

2019-10-18 Thread Quanyang Wang 

Hi MIchal,

The steps are:

(1)

I use kernel source https://github.com/Xilinx/linux-xlnx.git 
xlnx_rebase_v4.19.


(2)

Enable kernel option:

Kernel hacking  ---> Memory Debugging  --->

[*] Kernel memory leak detector

(9000) Maximum kmemleak early log entries.

(3)

When the board boots, run the command as below:

echo scan > /sys/kernel/debug/kmemleak

Then cat /sys/kernel/debug/kmemleak.


I attached the log as zcu102.log. Using mainline and linux-yocto with 
enabling kmemleak can also reproduce the memory leak.


Thanks,

Quanyang

On 10/18/19 2:33 PM, Michal Simek wrote:

Hi,

On 16. 10. 19 15:02, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

This is detected by kmemleak running on zcu102 board:

unreferenced object 0xffc877e48180 (size 128):
comm "swapper/0", pid 1, jiffies 4294892909 (age 315.436s)
hex dump (first 32 bytes):
64 70 5f 76 69 64 65 6f 5f 72 65 66 5f 64 69 76 dp_video_ref_div
31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1...
backtrace:
[<c9be883b>] __kmalloc_track_caller+0x200/0x380
[<f02c3809>] kvasprintf+0x7c/0x100
[<e51dde4d>] kasprintf+0x60/0x80
[<92298b05>] zynqmp_register_clocks+0x29c/0x398
[<faaff182>] zynqmp_clock_probe+0x3cc/0x4c0
[<5f5986f0>] platform_drv_probe+0x58/0xa8
[<d5810136>] really_probe+0xd8/0x2a8
[<f5b671be>] driver_probe_device+0x5c/0x100
[<38f91fcf>] __device_attach_driver+0x98/0xb8
[<8a3f2ac2>] bus_for_each_drv+0x74/0xd8
[<1cb2783d>] __device_attach+0xe0/0x140
[<c268031b>] device_initial_probe+0x24/0x30
[<6998de4b>] bus_probe_device+0x9c/0xa8
[<647ae6ff>] device_add+0x3c0/0x610
[<71c14bb8>] of_device_add+0x40/0x50
[<4bb5d132>] of_platform_device_create_pdata+0xbc/0x138

This is because that when num_nodes is larger than 1, clk_out is
allocated using kasprintf for these nodes but only the last node's
clk_out is freed.

Signed-off-by: Quanyang Wang 
---
  drivers/clk/zynqmp/clkc.c | 16 ++--
  1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/zynqmp/clkc.c b/drivers/clk/zynqmp/clkc.c
index 64355fd07f6b..536f68c98e97 100644
--- a/drivers/clk/zynqmp/clkc.c
+++ b/drivers/clk/zynqmp/clkc.c
@@ -563,7 +563,7 @@ static struct clk_hw *zynqmp_register_clk_topology(int 
clk_id, char *clk_name,
  {
int j;
u32 num_nodes, clk_dev_id;
-   char *clk_out = NULL;
+   char *clk_out[MAX_NODES];
struct clock_topology *nodes;
struct clk_hw *hw = NULL;
  
@@ -577,16 +577,16 @@ static struct clk_hw *zynqmp_register_clk_topology(int clk_id, char *clk_name,

 * Intermediate clock names are postfixed with type of clock.
 */
if (j != (num_nodes - 1)) {
-   clk_out = kasprintf(GFP_KERNEL, "%s%s", clk_name,
+   clk_out[j] = kasprintf(GFP_KERNEL, "%s%s", clk_name,
clk_type_postfix[nodes[j].type]);
} else {
-   clk_out = kasprintf(GFP_KERNEL, "%s", clk_name);
+   clk_out[j] = kasprintf(GFP_KERNEL, "%s", clk_name);
}
  
  		if (!clk_topology[nodes[j].type])

continue;
  
-		hw = (*clk_topology[nodes[j].type])(clk_out, clk_dev_id,

+   hw = (*clk_topology[nodes[j].type])(clk_out[j], clk_dev_id,
parent_names,
num_parents,
[j]);
@@ -595,9 +595,12 @@ static struct clk_hw *zynqmp_register_clk_topology(int 
clk_id, char *clk_name,
 __func__,  clk_dev_id, clk_name,
 PTR_ERR(hw));
  
-		parent_names[0] = clk_out;

+   parent_names[0] = clk_out[j];
}
-   kfree(clk_out);
+
+   for (j = 0; j < num_nodes; j++)
+   kfree(clk_out[j]);
+
return hw;
  }
  


I have tried to replicated but didn't see this issue. Can you please
send me full boot log with steps you have done?

Thanks,
Michal
[0.00] Booting Linux on physical CPU 0x00 [0x410fd034]
[0.00] Linux version 4.19.0-00085-gf0be99aa3709 (wrsadmin@pek-qwang2-d1) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ec9
[0.00] Machine model: ZynqMP ZCU102 Rev1.0
[0.00] earlycon: cdns0 at MMIO 0xff00 (options '')
[0.00] bootconsole [cdns0] enabled
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 256 MiB at 0x6fc0
[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv1.1 detected

Re: [linux-yocto] [PATCH 1/1] dma: xilinx: dpdma: alloc xilinx_dpdma_tx_desc using GFP_ATOMIC

2019-10-16 Thread Quanyang Wang 


On 10/17/19 1:01 AM, Hyun Kwon wrote:

Hi Quanyang,

Thanks for the patch.

On Tue, 2019-10-15 at 22:49:41 -0700, Michal Simek wrote:

+Hyun,

On 15. 10. 19 16:56, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

The function xilinx_dpdma_chan_alloc_tx_desc can be called
from atomic context, hence use GFP_ATOMIC instead of GFP_KERNEL,
or else it will cause the calltrace as below:

BUG: sleeping function called from invalid context at mm/slab.h:418
in_atomic(): 1, irqs_disabled(): 128, pid: 416, name: alsa-sink-(null 
Preemption disabled at:
[] snd_pcm_stream_lock_irq+0x40/0x50
CPU: 2 PID: 416 Comm: alsa-sink-(null Tainted: G O 5.2.17-yocto-standard #1
Hardware name: ZynqMP ZCU102 Rev1.0 (DT) Call trace:
dump_backtrace+0x0/0x138
show_stack+0x24/0x30
dump_stack+0x94/0xbc
___might_sleep+0x14c/0x178
__might_sleep+0x58/0x90
kmem_cache_alloc_trace+0x1a4/0x300
xilinx_dpdma_chan_alloc_tx_desc.isra.0+0x24/0x40
xilinx_dpdma_prep_dma_cyclic+0xc0/0x208
snd_dmaengine_pcm_trigger+0xf8/0x198
soc_pcm_trigger+0xb4/0x128
snd_pcm_do_start+0x48/0x58
snd_pcm_action_single+0x4c/0xa0
snd_pcm_action+0x78/0x90
snd_pcm_action_lock_irq+0x3c/0x60
snd_pcm_common_ioctl+0x4ac/0x10c8
snd_pcm_ioctl+0x48/0x68
do_vfs_ioctl+0x6d4/0x968
ksys_ioctl+0x84/0xb8
__arm64_sys_ioctl+0x28/0x38
el0_svc_common.constprop.0+0x74/0x180
el0_svc_handler+0x70/0x90
el0_svc+0x8/0xc

Signed-off-by: Quanyang Wang 

Maybe the 'nonatomic' can be set to true in xilinx_dp_dai_links? But I don't
know much about the flag, ex what's required, and I don't see any problem with
this change. So,

  Reviewed-by: Hyun Kwon 


Hi Hyun,

Thank you for looking this patch over.

I test and the "nonatomic" can also eliminate the calltrace.  But I 
don't know if there is any


problem with alsa driver running in a nonatomic context.

And do you think it's better using GFP_NOWAIT instead of GFP_ATOMIC ? 
This can save some atomic memory.


Hope to get your advice.

Thanks,

Quanyang




Thanks,
-hyun


---
  drivers/dma/xilinx/xilinx_dpdma.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/xilinx/xilinx_dpdma.c 
b/drivers/dma/xilinx/xilinx_dpdma.c
index 1ea509e00742..89ade893f51c 100644
--- a/drivers/dma/xilinx/xilinx_dpdma.c
+++ b/drivers/dma/xilinx/xilinx_dpdma.c
@@ -797,7 +797,7 @@ xilinx_dpdma_chan_alloc_tx_desc(struct xilinx_dpdma_chan 
*chan)
  {
struct xilinx_dpdma_tx_desc *tx_desc;
  
-	tx_desc = kzalloc(sizeof(*tx_desc), GFP_KERNEL);

+   tx_desc = kzalloc(sizeof(*tx_desc), GFP_ATOMIC);
if (!tx_desc)
return NULL;
  


Hyun: Can you please review this?

Thanks,
Michal

--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 2/2] arch: arm64: dts: add overlay dts file

2019-10-15 Thread Quanyang Wang 



On 10/15/19 11:27 PM, Bruce Ashfield wrote:

On Mon, Oct 14, 2019 at 6:19 AM Quanyang Wang
 wrote:


On 10/14/19 6:00 PM, Michal Simek wrote:

On 14. 10. 19 11:34, Quanyang Wang wrote:

On 10/14/19 3:58 PM, Michal Simek wrote:

On 14. 10. 19 9:55, Quanyang Wang wrote:

On 10/14/19 2:05 PM, Michal Simek wrote:

On 13. 10. 19 15:33, quanyang.w...@windriver.com wrote:

From: MengLi 

Add overlay dts file for updating FPGA bitstream file on
zynqmp platform.

Signed-off-by: Meng Li 
Signed-off-by: Quanyang Wang 
---
arch/arm64/boot/dts/xilinx/Makefile|  1 +
.../dts/xilinx/zynqmp-zcu102-fpga-update.dts   | 18
++
2 files changed, 19 insertions(+)
create mode 100644
arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts

diff --git a/arch/arm64/boot/dts/xilinx/Makefile
b/arch/arm64/boot/dts/xilinx/Makefile
index bec4746fe721..d56c449988d0 100644
--- a/arch/arm64/boot/dts/xilinx/Makefile
+++ b/arch/arm64/boot/dts/xilinx/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu100-revC.dtb
dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-revA.dtb
dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-revB.dtb
dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-rev1.0.dtb
+dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-fpga-update.dtb
dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu104-revA.dtb
dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu104-revC.dtb
dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu106-revA.dtb
diff --git
a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts
b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts
new file mode 100644
index ..f1e1506b6210
--- /dev/null
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts
@@ -0,0 +1,18 @@
+// overlay dts file.
+/dts-v1/;
+/plugin/;
+
+/ {
+fragment@0 {
+target-path = "/fpga-full";
+#address-cells = <1>;
+#size-cells = <1>;
+
+__overlay__ {
+#address-cells = <2>;
+#size-cells = <2>;
+
+firmware-name = "system.bit.bin";
+};
+};
+};


I understand what you want to do but not sure why you think that
this is
the best way how to do it.

Hi Michal,

This patch is based on the url:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841847/Solution+ZynqMP+PL+Programming#x-Programming+the+PL+through+Linux


"FPGA programming using Device Tree Overlay (DTO)".

We will describe how to programming FPGA by using 2 methods in README
for our customer:

one is FPGA programming using sysfs attributes
<https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841847/Solution+ZynqMP+PL+Programming#SolutionZynqMPPLProgramming-FPGAprogrammingusingsysfsattributes>


And the other is FPGA programming using Device Tree Overlay (DTO)
<https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841847/Solution+ZynqMP+PL+Programming#SolutionZynqMPPLProgramming-FPGAprogrammingusingDeviceTreeOverlay(DTO)>


This patch is used for the second method.

Is there any better way to do it?


It is not about that using fragments is incorrect. It is about reasons
to include this dts file to Linux source code. Because this fragment is
just doing programming without anything else. It means it is coupled
with also description what it is in DT which is missing here.
It means this is just part A (with system.bit.bin generic name - which
is not fully accurate) and part B is missing.
In part B there should be what you are including with clock/reset and IP
part.
That's why my question remains if make even sense to merge part A
without any details about part B.

Hi Michal,

The target for this patch is to just simply test the FPGA programming
function. So it changes nothing.

It seems to be improper to add such a dts file to kernel source.

I will transform the dts file to a text description in README or make it
to be a more detailed and integral dts file in a V2 patch.

ok. let's see where you want to add this readme. If this targets
"Documentation" folder then not a problem at all.

Hi Michal,

Sorry for making you confuse. The README which I said about is not in
kernel source but in WRLinux project.

I mean that maybe I can just describe how to test FPGA programming in
some place of our own Product Document

Just confirming that I'll drop this patch from my pending queue, since
either this is going to be in documentation or somewhere else in the
dts.


Hi Bruce,

Yes, please drop this patch.

Thanks,

Quanyang



Cheers,

Bruce


instead of adding a dts file to kernel source since it's just a simple
testcase.

Thanks,

Quanyang


M




--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 2/2] arch: arm64: dts: add overlay dts file

2019-10-14 Thread Quanyang Wang 


On 10/14/19 6:00 PM, Michal Simek wrote:

On 14. 10. 19 11:34, Quanyang Wang wrote:

On 10/14/19 3:58 PM, Michal Simek wrote:

On 14. 10. 19 9:55, Quanyang Wang wrote:

On 10/14/19 2:05 PM, Michal Simek wrote:

On 13. 10. 19 15:33, quanyang.w...@windriver.com wrote:

From: MengLi 

Add overlay dts file for updating FPGA bitstream file on
zynqmp platform.

Signed-off-by: Meng Li 
Signed-off-by: Quanyang Wang 
---
   arch/arm64/boot/dts/xilinx/Makefile    |  1 +
   .../dts/xilinx/zynqmp-zcu102-fpga-update.dts   | 18
++
   2 files changed, 19 insertions(+)
   create mode 100644
arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts

diff --git a/arch/arm64/boot/dts/xilinx/Makefile
b/arch/arm64/boot/dts/xilinx/Makefile
index bec4746fe721..d56c449988d0 100644
--- a/arch/arm64/boot/dts/xilinx/Makefile
+++ b/arch/arm64/boot/dts/xilinx/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu100-revC.dtb
   dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-revA.dtb
   dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-revB.dtb
   dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-rev1.0.dtb
+dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-fpga-update.dtb
   dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu104-revA.dtb
   dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu104-revC.dtb
   dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu106-revA.dtb
diff --git
a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts
b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts
new file mode 100644
index ..f1e1506b6210
--- /dev/null
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts
@@ -0,0 +1,18 @@
+// overlay dts file.
+/dts-v1/;
+/plugin/;
+
+/ {
+    fragment@0 {
+    target-path = "/fpga-full";
+    #address-cells = <1>;
+    #size-cells = <1>;
+
+    __overlay__ {
+    #address-cells = <2>;
+    #size-cells = <2>;
+
+    firmware-name = "system.bit.bin";
+    };
+    };
+};


I understand what you want to do but not sure why you think that
this is
the best way how to do it.

Hi Michal,

This patch is based on the url:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841847/Solution+ZynqMP+PL+Programming#x-Programming+the+PL+through+Linux


"FPGA programming using Device Tree Overlay (DTO)".

We will describe how to programming FPGA by using 2 methods in README
for our customer:

one is FPGA programming using sysfs attributes
<https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841847/Solution+ZynqMP+PL+Programming#SolutionZynqMPPLProgramming-FPGAprogrammingusingsysfsattributes>


And the other is FPGA programming using Device Tree Overlay (DTO)
<https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841847/Solution+ZynqMP+PL+Programming#SolutionZynqMPPLProgramming-FPGAprogrammingusingDeviceTreeOverlay(DTO)>


This patch is used for the second method.

Is there any better way to do it?


It is not about that using fragments is incorrect. It is about reasons
to include this dts file to Linux source code. Because this fragment is
just doing programming without anything else. It means it is coupled
with also description what it is in DT which is missing here.
It means this is just part A (with system.bit.bin generic name - which
is not fully accurate) and part B is missing.
In part B there should be what you are including with clock/reset and IP
part.
That's why my question remains if make even sense to merge part A
without any details about part B.

Hi Michal,

The target for this patch is to just simply test the FPGA programming
function. So it changes nothing.

It seems to be improper to add such a dts file to kernel source.

I will transform the dts file to a text description in README or make it
to be a more detailed and integral dts file in a V2 patch.

ok. let's see where you want to add this readme. If this targets
"Documentation" folder then not a problem at all.


Hi Michal,

Sorry for making you confuse. The README which I said about is not in 
kernel source but in WRLinux project.


I mean that maybe I can just describe how to test FPGA programming in 
some place of our own Product Document


instead of adding a dts file to kernel source since it's just a simple 
testcase.


Thanks,

Quanyang



M

--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 2/2] arch: arm64: dts: add overlay dts file

2019-10-14 Thread Quanyang Wang 



On 10/14/19 3:58 PM, Michal Simek wrote:

On 14. 10. 19 9:55, Quanyang Wang wrote:

On 10/14/19 2:05 PM, Michal Simek wrote:

On 13. 10. 19 15:33, quanyang.w...@windriver.com wrote:

From: MengLi 

Add overlay dts file for updating FPGA bitstream file on
zynqmp platform.

Signed-off-by: Meng Li 
Signed-off-by: Quanyang Wang 
---
  arch/arm64/boot/dts/xilinx/Makefile|  1 +
  .../dts/xilinx/zynqmp-zcu102-fpga-update.dts   | 18 ++
  2 files changed, 19 insertions(+)
  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts

diff --git a/arch/arm64/boot/dts/xilinx/Makefile 
b/arch/arm64/boot/dts/xilinx/Makefile
index bec4746fe721..d56c449988d0 100644
--- a/arch/arm64/boot/dts/xilinx/Makefile
+++ b/arch/arm64/boot/dts/xilinx/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu100-revC.dtb
  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-revA.dtb
  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-revB.dtb
  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-rev1.0.dtb
+dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-fpga-update.dtb
  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu104-revA.dtb
  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu104-revC.dtb
  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu106-revA.dtb
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts 
b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts
new file mode 100644
index ..f1e1506b6210
--- /dev/null
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts
@@ -0,0 +1,18 @@
+// overlay dts file.
+/dts-v1/;
+/plugin/;
+
+/ {
+   fragment@0 {
+   target-path = "/fpga-full";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   __overlay__ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   firmware-name = "system.bit.bin";
+   };
+   };
+};


I understand what you want to do but not sure why you think that this is
the best way how to do it.

Hi Michal,

This patch is based on the url:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841847/Solution+ZynqMP+PL+Programming#x-Programming+the+PL+through+Linux

"FPGA programming using Device Tree Overlay (DTO)".

We will describe how to programming FPGA by using 2 methods in README
for our customer:

one is FPGA programming using sysfs attributes
<https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841847/Solution+ZynqMP+PL+Programming#SolutionZynqMPPLProgramming-FPGAprogrammingusingsysfsattributes>

And the other is FPGA programming using Device Tree Overlay (DTO)
<https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841847/Solution+ZynqMP+PL+Programming#SolutionZynqMPPLProgramming-FPGAprogrammingusingDeviceTreeOverlay(DTO)>

This patch is used for the second method.

Is there any better way to do it?


It is not about that using fragments is incorrect. It is about reasons
to include this dts file to Linux source code. Because this fragment is
just doing programming without anything else. It means it is coupled
with also description what it is in DT which is missing here.
It means this is just part A (with system.bit.bin generic name - which
is not fully accurate) and part B is missing.
In part B there should be what you are including with clock/reset and IP
part.
That's why my question remains if make even sense to merge part A
without any details about part B.


Hi Michal,

The target for this patch is to just simply test the FPGA programming 
function. So it changes nothing.


It seems to be improper to add such a dts file to kernel source.

I will transform the dts file to a text description in README or make it 
to be a more detailed and integral dts file in a V2 patch.


Thanks,

Quanyang



Thanks,
Michal




--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 2/2] arch: arm64: dts: add overlay dts file

2019-10-14 Thread Quanyang Wang 


On 10/14/19 2:05 PM, Michal Simek wrote:

On 13. 10. 19 15:33, quanyang.w...@windriver.com wrote:

From: MengLi 

Add overlay dts file for updating FPGA bitstream file on
zynqmp platform.

Signed-off-by: Meng Li 
Signed-off-by: Quanyang Wang 
---
  arch/arm64/boot/dts/xilinx/Makefile|  1 +
  .../dts/xilinx/zynqmp-zcu102-fpga-update.dts   | 18 ++
  2 files changed, 19 insertions(+)
  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts

diff --git a/arch/arm64/boot/dts/xilinx/Makefile 
b/arch/arm64/boot/dts/xilinx/Makefile
index bec4746fe721..d56c449988d0 100644
--- a/arch/arm64/boot/dts/xilinx/Makefile
+++ b/arch/arm64/boot/dts/xilinx/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu100-revC.dtb
  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-revA.dtb
  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-revB.dtb
  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-rev1.0.dtb
+dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-fpga-update.dtb
  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu104-revA.dtb
  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu104-revC.dtb
  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu106-revA.dtb
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts 
b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts
new file mode 100644
index ..f1e1506b6210
--- /dev/null
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts
@@ -0,0 +1,18 @@
+// overlay dts file.
+/dts-v1/;
+/plugin/;
+
+/ {
+   fragment@0 {
+   target-path = "/fpga-full";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   __overlay__ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   firmware-name = "system.bit.bin";
+   };
+   };
+};


I understand what you want to do but not sure why you think that this is
the best way how to do it.


Hi Michal,

This patch is based on the url:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841847/Solution+ZynqMP+PL+Programming#x-Programming+the+PL+through+Linux

"FPGA programming using Device Tree Overlay (DTO)".

We will describe how to programming FPGA by using 2 methods in README 
for our customer:


one is FPGA programming using sysfs attributes 
<https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841847/Solution+ZynqMP+PL+Programming#SolutionZynqMPPLProgramming-FPGAprogrammingusingsysfsattributes>


And the other is FPGA programming using Device Tree Overlay (DTO) 
<https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841847/Solution+ZynqMP+PL+Programming#SolutionZynqMPPLProgramming-FPGAprogrammingusingDeviceTreeOverlay(DTO)>


This patch is used for the second method.

Is there any better way to do it?

Thanks,

Quanyang




Thanks,
Michal

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto