Skip to content

Conversation

@pamolloy
Copy link
Collaborator

@pamolloy pamolloy commented Nov 4, 2025

This base series is a refactored version of the current adsp-main-6.12 branch. The minimal diff with adsp-main-6.12 is below. Note this is getting merged into a new branch, adsp-6.12.0-y.

I will then apply a set of fixup commits in an attempt to pass CI/CD. Only the fixup commits need to be reviewed.

Once merged adsp-main-6.12 can be replaced. And then this series can be manually rebased on top of adsp-main-6.12.38-y, which contains Artur's series that is being mainlined.

diff --git a/arch/arm/configs/sc594-som-ezkit_defconfig b/arch/arm/configs/sc594-som-ezkit_defconfig
index 95ee136225b73..137f1163bf94a 100644
--- a/arch/arm/configs/sc594-som-ezkit_defconfig
+++ b/arch/arm/configs/sc594-som-ezkit_defconfig
@@ -1,4 +1,4 @@
-CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION="-yocto-standard"
 CONFIG_SYSVIPC=y
 CONFIG_USELIB=y
 CONFIG_GENERIC_IRQ_DEBUGFS=y
diff --git a/arch/arm/mach-sc5xx/Kconfig b/arch/arm/mach-sc5xx/Kconfig
index ca7fc607d2b97..d982ed8496f69 100644
--- a/arch/arm/mach-sc5xx/Kconfig
+++ b/arch/arm/mach-sc5xx/Kconfig
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)-or-later
 menuconfig ARCH_SC5XX
-       bool "SC5xx SoCs (Cortex-A5-based)" 
+       bool "SC5xx SoCs (Cortex-A5-based)"
        depends on ARCH_MULTI_V7
        select ARM_GIC
        select PINCTRL
@@ -46,7 +46,7 @@ config ARCH_SC58X
        select COMMON_CLK_ADI_SC58X
        help
                This enables support for 32-bit Cortex-A5-based ADI ADSP SC-58X
-               SoCs, like the SC589. 
+               SoCs, like the SC589.
 
 config MACH_SC589_MINI
        bool "ADI sc589-mini board"

Signed-off-by: Philip Molloy <[email protected]>
@pamolloy pamolloy requested review from a team, gastmaier and nunojsa November 4, 2025 13:11
UtsavAgarwalADI and others added 8 commits November 4, 2025 14:25
Only supports the ADZS-SC589-MINI

Signed-off-by: Utsav Agarwal <[email protected]>
Signed-off-by: Utsav Agarwal <[email protected]>
Signed-off-by: Arturs Artamonovs <[email protected]>
Co-developed-by: Nathan Barrett-Morrison <[email protected]>
Signed-off-by: Nathan Barrett-Morrison <[email protected]>
Co-developed-by: Greg Malysa <[email protected]>
Signed-off-by: Greg Malysa <[email protected]>
Signed-off-by: Utsav Agarwal <[email protected]>
Signed-off-by: Arturs Artamonovs <[email protected]>
@pamolloy pamolloy force-pushed the staging/philip/adsp-6.12.0-clean-up branch from baabcea to 48807cd Compare November 5, 2025 14:00
@pamolloy pamolloy marked this pull request as ready for review November 5, 2025 14:03
@pamolloy
Copy link
Collaborator Author

pamolloy commented Nov 5, 2025

There is still a lot to clean-up, but it isn't possible to fix everything in one go. I'll also fix some more when I rebase these on top of adsp-6.12.38-y that includes Artur's mainline series. @analogdevicesinc/linux-for-adsp please take a look through. There are a lot of fixup commits, but they should be very straight forward.

@CalebEthridgeADI
Copy link

The plan is to keep adsp-main-6.12 around until you finish the fixup patch series with future PRs? I ask because the meta layer is pinned to a specific commit SHA for each release, so it will need to be updated if the SHA changes. I would suggest we keep both branches until everything is finished, especially since the current pinned commit for the 5.0.0 release will definitely need to be fixed up :)

@pamolloy
Copy link
Collaborator Author

The plan is to keep adsp-main-6.12 around until you finish the fixup patch series with future PRs? I ask because the meta layer is pinned to a specific commit SHA for each release, so it will need to be updated if the SHA changes. I would suggest we keep both branches until everything is finished, especially since the current pinned commit for the 5.0.0 release will definitely need to be fixed up :)

Yup, adsp-main-6.12 is not going anywhere 👍

Copy link
Collaborator

@nunojsa nunojsa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly looks good!

Regarding all the cast comments, I'm ok if you say you prefer to group all of those changes for a latter round

struct ldr_hdr *block_hdr = NULL;
struct ldr_hdr *next_hdr = NULL;
uint8_t *virbuf = (uint8_t *) rproc_data->mem_virt;
u8 *virbuf = (u8 *) rproc_data->mem_virt;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if the cast is even needed. If mem_virt is void *, then it should be implicit already

// Poll until Core is in reset
while (!(adi_rcu_readl(rcu, ADI_RCU_REG_CRSTAT) & (1 << coreid)));
while (!(adi_rcu_readl(rcu, ADI_RCU_REG_CRSTAT) & (1 << coreid)))
;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm? Is this just personal preference or did we get any tool complaining about it? If I'm not mistaken, I'm actually used to see the style we are changing.


/** @brief Subdevice id to which the buffer should be attached */
int32_t subdev_id;
s32 subdev_id;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this, often one just uses plain int. I guess it will depend on the maintainer we're dealing with

return ret;
}
sport->tx_dma_icap_buf_id = (uint32_t)ret;
sport->tx_dma_icap_buf_id = (u32)ret;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same thing (since we're changing it already better to just drop it). Same for all other casts I'm seeing. I'm not 100% sure about all of them but gut feeling that we should be able to drop most (if not all) of them

static u64 notrace read_sched_gptimer(void)
{
return (u64) get_gptimer_count(gptimer_controller.cs->timer);
return (u64)get_gptimer_count(gptimer_controller.cs->timer);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likely the cast is not needed

@pamolloy
Copy link
Collaborator Author

Mostly looks good!

Regarding all the cast comments, I'm ok if you say you prefer to group all of those changes for a latter round

Yah, I'd leave the cast clean-up to another round. The other comments were already fixed, but likely the result of rebasing or squashing fixups, which created weird diffs, but are correct in the end.

Copy link
Collaborator

@nunojsa nunojsa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given @pamolloy feedback, LGTM!

But we should have more eyes on this one!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants