| Message ID | 20240807105813.3844985-1-neal.frager@amd.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [v1,1/5] board/xilinx/patches/linux: add linux 6.6.40 hash | expand |
Hello Neal, On Wed, 7 Aug 2024 11:58:09 +0100 Neal Frager via buildroot <buildroot@buildroot.org> wrote: > Add the hash for the Linux 6.6.40 release for Xilinx products. > > The release tag was missing a patch, so it is being added here for users that > bump to Linux 6.6.40. The patch has already been committed to the linux-xlnx > repo. > > Upstream: https://github.com/Xilinx/linux-xlnx/commit/5365c13a86998da06d845c918f849b30b8735538 > > Signed-off-by: Neal Frager <neal.frager@amd.com> I'm not sure I'm a big fan of the approach of doing this addition in PATCH 1/5, and then changing the defconfigs one after the other. I see two problems: - In PATCH 1/5, you're adding a kernel patch, but do you realize that with only PATCH 1/5 applied, your kernel patch will be applied to the existing defconfigs, that use the xlnx_rebase_v6.6_LTS_2024.1 kernel ? It turns out you're lucky, as the patch applies fine on xlnx_rebase_v6.6_LTS_2024.1, but in the general case that would not work. - After applying all patches, you still have the hash of xlnx_rebase_v6.6_LTS_2024.1.tar.gz, but I don't know if it's still used by some other defconfigs. So I see several approaches here: - Don't use a shared board/xilinx/patches/ folder, and use one per board, like is done in board/freescale/. This allows to update defconfigs independently from each other. - Update all defconfigs that use board/xilinx/patches/ in one single commit. Best regards, Thomas
Hi Thomas, > Add the hash for the Linux 6.6.40 release for Xilinx products. > > The release tag was missing a patch, so it is being added here for users that > bump to Linux 6.6.40. The patch has already been committed to the linux-xlnx > repo. > > Upstream: https://github.com/Xilinx/linux-xlnx/commit/5365c13a86998da06d845c918f849b30b8735538 > > Signed-off-by: Neal Frager <neal.frager@amd.com> > I'm not sure I'm a big fan of the approach of doing this addition in > PATCH 1/5, and then changing the defconfigs one after the other. I see > two problems: > - In PATCH 1/5, you're adding a kernel patch, but do you realize that > with only PATCH 1/5 applied, your kernel patch will be applied to the > existing defconfigs, that use the xlnx_rebase_v6.6_LTS_2024.1 kernel ? > It turns out you're lucky, as the patch applies fine on > xlnx_rebase_v6.6_LTS_2024.1, but in the general case that would not > work. Yes, I was aware of this, and verified that it would be ok before submitting the patch set like this. However, I see your point and I will re-submit. > - After applying all patches, you still have the hash of > xlnx_rebase_v6.6_LTS_2024.1.tar.gz, but I don't know if it's still > used by some other defconfigs. > So I see several approaches here: > - Don't use a shared board/xilinx/patches/ folder, and use one per > board, like is done in board/freescale/. This allows to update > defconfigs independently from each other. > - Update all defconfigs that use board/xilinx/patches/ in one single > commit. From my view, it is best to keep the shared hash files since there are now 12 xilinx defconfigs using this and soon to be 13. Since it only requires a single line change in the defconfig files, I will squash this into a single patch that updates all 12 defconfigs to Linux 6.6.40. Best regards, Neal Frager AMD
On Wed, 7 Aug 2024 14:26:24 +0000 "Frager, Neal" <neal.frager@amd.com> wrote: > From my view, it is best to keep the shared hash files since there are now 12 > xilinx defconfigs using this and soon to be 13. > > Since it only requires a single line change in the defconfig files, I will > squash this into a single patch that updates all 12 defconfigs to Linux 6.6.40. But are you able to test that those 12 (soon 13) defconfigs all build and boot fine when doing such updates to all defconfigs at the same time? Thomas
Hi Thomas, > From my view, it is best to keep the shared hash files since there are now 12 > xilinx defconfigs using this and soon to be 13. > > Since it only requires a single line change in the defconfig files, I will > squash this into a single patch that updates all 12 defconfigs to Linux 6.6.40. > But are you able to test that those 12 (soon 13) defconfigs all build > and boot fine when doing such updates to all defconfigs at the same time? I have 10 of the 12 boards (11 of 13 when the versal_vek280 is added). I do not actually have a zynq_microzed or a zynq_zed board, but these are mature enough that I believe testing on the zynq_zc702 and zynq_zc706 should be sufficient for covering these boards. So far, I have tested the 6.6.40 release on the zynq_zc702 and zynq_zc706 boards, which is why I only submitted the zynq defconfigs so far. Now that I will squash all of them into one patch, I will go through zynqmp and versal testing as well. I will create the squashed patch, and then go through the build and run process on all the boards. Once complete, I will submit the patch. It will probably take me a couple days. Please note that outside of my testing, our software team has already tested this 6.6.40 release on all of the boards, so I am really just doing a sanity check. Please let me know if you have any further questions. Best regards, Neal Frager AMD
Hi Thomas, > From my view, it is best to keep the shared hash files since there are now 12 > xilinx defconfigs using this and soon to be 13. > > Since it only requires a single line change in the defconfig files, I will > squash this into a single patch that updates all 12 defconfigs to Linux 6.6.40. > But are you able to test that those 12 (soon 13) defconfigs all build > and boot fine when doing such updates to all defconfigs at the same time? > I have 10 of the 12 boards (11 of 13 when the versal_vek280 is added). > I do not actually have a zynq_microzed or a zynq_zed board, but these are > mature enough that I believe testing on the zynq_zc702 and zynq_zc706 should > be sufficient for covering these boards. > So far, I have tested the 6.6.40 release on the zynq_zc702 and zynq_zc706 > boards, which is why I only submitted the zynq defconfigs so far. Now that I > will squash all of them into one patch, I will go through zynqmp and versal > testing as well. > I will create the squashed patch, and then go through the build and run > process on all the boards. Once complete, I will submit the patch. It will > probably take me a couple days. > Please note that outside of my testing, our software team has already tested > this 6.6.40 release on all of the boards, so I am really just doing a sanity > check. > Please let me know if you have any further questions. Also, in supporting Linux LTS, we plan to do release tags 10 tags at a time in addition to the .1 and .2 releases we do each year. So 6.6.40 then 6.6.50 then 6.6.60, etc. We will only be doing it for the latest LTS. Meaning just Linux 6.6 this year, and Linux 6.(12 or 13?) next year. We are also upstreaming our software as quickly as possible, but since we have a large number of patches not yet mainline, this is our short term solution for supporting Linux LTS until we can promote customers using the mainline Linux kernel. Best regards, Neal Frager AMD
Hi Thomas, > From my view, it is best to keep the shared hash files since there are now 12 > xilinx defconfigs using this and soon to be 13. > > Since it only requires a single line change in the defconfig files, I will > squash this into a single patch that updates all 12 defconfigs to Linux 6.6.40. > But are you able to test that those 12 (soon 13) defconfigs all build > and boot fine when doing such updates to all defconfigs at the same time? We have a better solution now. I got our team to re-do the release tag for Linux 6.6.40, so that all the needed patches are included now. https://github.com/Xilinx/linux-xlnx/commits/xlnx_rebase_v6.6_LTS_merge_6.6.40/ Now we no longer need to add the patch to the buildroot source tree. Best regards, Neal Frager AMD
On Thu, 8 Aug 2024 09:10:45 +0000 "Frager, Neal" <neal.frager@amd.com> wrote: > We have a better solution now. I got our team to re-do the release tag for > Linux 6.6.40, so that all the needed patches are included now. Re-do a tag that has been published, arg. You want to break build systems like Buildroot? :-/ Thomas
Hi Thomas, > We have a better solution now. I got our team to re-do the release tag for > Linux 6.6.40, so that all the needed patches are included now. > Re-do a tag that has been published, arg. You want to break build > systems like Buildroot? :-/ The tag was only published yesterday at my request. As far as I know, no one was using this tag yet, so changing it should not have broken anything. In any case, now that we use hashes for everything, we should be protected from tag changes. If a tag gets changed, the hash check will fail. But in general, I fully agree with you that changing a published tag is bad practice. I only requested it this time, so we could avoid needing to add a patch in buildroot which should not have been necessary. Best regards, Neal Frager AMD
diff --git a/board/xilinx/patches/linux/0001-dmaengine-xilinx-dpdma-removed-extra.patch b/board/xilinx/patches/linux/0001-dmaengine-xilinx-dpdma-removed-extra.patch new file mode 100644 index 0000000000..f5008f7dc3 --- /dev/null +++ b/board/xilinx/patches/linux/0001-dmaengine-xilinx-dpdma-removed-extra.patch @@ -0,0 +1,54 @@ +From 5365c13a86998da06d845c918f849b30b8735538 Mon Sep 17 00:00:00 2001 +From: Rohit Visavalia <rohit.visavalia@amd.com> +Date: Tue, 30 Jul 2024 23:53:29 -0700 +Subject: [PATCH] dmaengine: xilinx: dpdma: removed extra vchan lock + +There were redundant spinlock for virtual dma channel +Removal of this fixes crash at xilinx_dpdma_chan_queue_transfer + +[ 2876.675266] Call trace: +[ 2876.677701] xilinx_dpdma_chan_queue_transfer+0x4c/0x200 +[ 2876.683004] __handle_irq_event_percpu+0x58/0x170 +[ 2876.687698] handle_irq_event+0x64/0x11c +[ 2876.691606] handle_fasteoi_irq+0xc0/0x220 +[ 2876.695693] __handle_domain_irq+0x7c/0xe0 +[ 2876.699775] gic_handle_irq+0x78/0xa0 +[ 2876.703428] el1_irq+0xc4/0x180 +[ 2876.706563] arch_cpu_idle+0x18/0x30 +[ 2876.710131] default_idle_call+0x24/0x74 +[ 2876.714045] do_idle+0x238/0x2ac +[ 2876.717265] cpu_startup_entry+0x28/0x60 +[ 2876.721171] rest_init+0xbc/0xcc +[ 2876.724384] arch_call_rest_init+0x10/0x1c +[ 2876.728463] start_kernel+0x4ec/0x524 +[ 2876.732113] Code: d2802008 d2802447 f2fbd5a8 a9400823 (f9000462) +[ 2876.738200] ---[ end trace 1c82d54670104ec1 ]--- +[ 2876.742804] Kernel panic - not syncing: Oops: Fatal exception in interrupt +[ 2876.749662] SMP: stopping secondary CPUs +[ 2876.753571] Kernel Offset: disabled +[ 2876.757049] CPU features: 0x0040002,20002004 +[ 2876.761301] Memory Limit: none +[ 2876.764343] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- + +Signed-off-by: Rohit Visavalia <rohit.visavalia@amd.com> +Signed-off-by: Neal Frager <neal.frager@amd.com> +Upstream: https://github.com/Xilinx/linux-xlnx/commit/5365c13a86998da06d845c918f849b30b8735538 +--- + drivers/dma/xilinx/xilinx_dpdma.c | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/drivers/dma/xilinx/xilinx_dpdma.c b/drivers/dma/xilinx/xilinx_dpdma.c +index ca9374ebaf3f..db4a5c2dd226 100644 +--- a/drivers/dma/xilinx/xilinx_dpdma.c ++++ b/drivers/dma/xilinx/xilinx_dpdma.c +@@ -1182,7 +1182,6 @@ static void xilinx_dpdma_chan_vsync_irq(struct xilinx_dpdma_chan *chan) + chan->desc.active = pending; + chan->desc.pending = NULL; + +- spin_lock(&chan->vchan.lock); + xilinx_dpdma_chan_queue_transfer(chan); + spin_unlock(&chan->vchan.lock); + +-- +2.25.1 + diff --git a/board/xilinx/patches/linux/linux.hash b/board/xilinx/patches/linux/linux.hash index d85f773478..e34e86757b 100644 --- a/board/xilinx/patches/linux/linux.hash +++ b/board/xilinx/patches/linux/linux.hash @@ -1,2 +1,3 @@ # Locally calculated sha256 ea85988e66b9a2e19ccd76d0f5f5e657988a873fed292160917712f45605a805 xlnx_rebase_v6.6_LTS_2024.1.tar.gz +sha256 c46fbcb45b2c7da919663119eeab2581bb36b6238ae809a71e19013291d9054c xlnx_rebase_v6.6_LTS_merge_6.6.40.tar.gz
Add the hash for the Linux 6.6.40 release for Xilinx products. The release tag was missing a patch, so it is being added here for users that bump to Linux 6.6.40. The patch has already been committed to the linux-xlnx repo. Upstream: https://github.com/Xilinx/linux-xlnx/commit/5365c13a86998da06d845c918f849b30b8735538 Signed-off-by: Neal Frager <neal.frager@amd.com> --- ...dmaengine-xilinx-dpdma-removed-extra.patch | 54 +++++++++++++++++++ board/xilinx/patches/linux/linux.hash | 1 + 2 files changed, 55 insertions(+) create mode 100644 board/xilinx/patches/linux/0001-dmaengine-xilinx-dpdma-removed-extra.patch