Skip to content

Conversation

@yaochunhung
Copy link

Hi,
This PR is for basic support MT8195 platform on SOF.
MT8195 include Cadence HiFi-4 single core, currently we support 4 DAI interfaces, SOF_DL2/DL3/UL4/UL5(Downlink/Uplink paths) on MT8195 Audio Hardware(which we call AFE, the Abbreviation of Audio Front End). This PR includes basic skeleton hardware support on MT8195, Mediatek AFE DAIs for toplolgy, fw loader ops, and dai driver defintions.
Thanks!


/* DSP memories */
#define MBOX_OFFSET 0x800000 // DRAM
#define MBOX_SIZE 0x1000 // memory.h in sof fw
Copy link
Collaborator

Choose a reason for hiding this comment

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

Please do not use C++ style comments. Use /* */

Copy link
Author

Choose a reason for hiding this comment

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

ok. I will modify it. thanks

@dbaluta
Copy link
Collaborator

dbaluta commented Sep 16, 2021

@yaochunhung thanks. This PR is now much easier to review.

Few general comments:

  1. Please check the order of patches. Each patch individually should compile fine, to help with bisection. First patch should be
    ASoC: SOF: mediatek: Add mt8195 hardware support but maybe github shows the patches in a different order than you have in your tree.

  2. Check sparse warnings displayed by github:

https://github.com/thesofproject/linux/pull/3160/checks?check_run_id=3621871638

   CHECK   sound/soc/sof/mediatek/mt8195/mt8195.c
sound/soc/sof/mediatek/mt8195/mt8195.c:167:22: error: incorrect type in assignment (different address spaces)
sound/soc/sof/mediatek/mt8195/mt8195.c:167:22:    expected void [noderef] __iomem **va_dspsysreg
sound/soc/sof/mediatek/mt8195/mt8195.c:167:22:    got void [noderef] __iomem *
sound/soc/sof/mediatek/mt8195/mt8195.c:176:30: error: incorrect type in argument 1 (different address spaces)
sound/soc/sof/mediatek/mt8195/mt8195.c:176:30:    expected void const volatile [noderef] __iomem *addr
sound/soc/sof/mediatek/mt8195/mt8195.c:176:30:    got void [noderef] __iomem **va_dspsysreg
sound/soc/sof/mediatek/mt8195/mt8195.c:176:70: error: incorrect type in argument 2 (different address spaces)
sound/soc/sof/mediatek/mt8195/mt8195.c:176:70:    expected void volatile [noderef] __iomem *addr
sound/soc/sof/mediatek/mt8195/mt8195.c:176:70:    got void [noderef] __iomem **va_dspsysreg
sound/soc/sof/mediatek/mt8195/mt8195.c:178:30: error: incorrect type in argument 1 (different address spaces)
sound/soc/sof/mediatek/mt8195/mt8195.c:178:30:    expected void const volatile [noderef] __iomem *addr
sound/soc/sof/mediatek/mt8195/mt8195.c:178:30:    got void [noderef] __iomem **va_dspsysreg
sound/soc/sof/mediatek/mt8195/mt8195.c:178:69: error: incorrect type in argument 2 (different address spaces)
sound/soc/sof/mediatek/mt8195/mt8195.c:178:69:    expected void volatile [noderef] __iomem *addr
sound/soc/sof/mediatek/mt8195/mt8195.c:178:69:    got void [noderef] __iomem **va_dspsysreg
sound/soc/sof/mediatek/mt8195/mt8195.c:374:24: error: symbol 'sof_mt8195_ops' was not declared. Should it be static?

@yaochunhung yaochunhung force-pushed the mt8195-basic branch 2 times, most recently from ef81334 to 617aaae Compare September 17, 2021 03:17
@yaochunhung
Copy link
Author

@yaochunhung thanks. This PR is now much easier to review.

Few general comments:

  1. Please check the order of patches. Each patch individually should compile fine, to help with bisection. First patch should be
    ASoC: SOF: mediatek: Add mt8195 hardware support but maybe github shows the patches in a different order than you have in your tree.
  2. Check sparse warnings displayed by github:

https://github.com/thesofproject/linux/pull/3160/checks?check_run_id=3621871638

   CHECK   sound/soc/sof/mediatek/mt8195/mt8195.c
sound/soc/sof/mediatek/mt8195/mt8195.c:167:22: error: incorrect type in assignment (different address spaces)
sound/soc/sof/mediatek/mt8195/mt8195.c:167:22:    expected void [noderef] __iomem **va_dspsysreg
sound/soc/sof/mediatek/mt8195/mt8195.c:167:22:    got void [noderef] __iomem *
sound/soc/sof/mediatek/mt8195/mt8195.c:176:30: error: incorrect type in argument 1 (different address spaces)
sound/soc/sof/mediatek/mt8195/mt8195.c:176:30:    expected void const volatile [noderef] __iomem *addr
sound/soc/sof/mediatek/mt8195/mt8195.c:176:30:    got void [noderef] __iomem **va_dspsysreg
sound/soc/sof/mediatek/mt8195/mt8195.c:176:70: error: incorrect type in argument 2 (different address spaces)
sound/soc/sof/mediatek/mt8195/mt8195.c:176:70:    expected void volatile [noderef] __iomem *addr
sound/soc/sof/mediatek/mt8195/mt8195.c:176:70:    got void [noderef] __iomem **va_dspsysreg
sound/soc/sof/mediatek/mt8195/mt8195.c:178:30: error: incorrect type in argument 1 (different address spaces)
sound/soc/sof/mediatek/mt8195/mt8195.c:178:30:    expected void const volatile [noderef] __iomem *addr
sound/soc/sof/mediatek/mt8195/mt8195.c:178:30:    got void [noderef] __iomem **va_dspsysreg
sound/soc/sof/mediatek/mt8195/mt8195.c:178:69: error: incorrect type in argument 2 (different address spaces)
sound/soc/sof/mediatek/mt8195/mt8195.c:178:69:    expected void volatile [noderef] __iomem *addr
sound/soc/sof/mediatek/mt8195/mt8195.c:178:69:    got void [noderef] __iomem **va_dspsysreg
sound/soc/sof/mediatek/mt8195/mt8195.c:374:24: error: symbol 'sof_mt8195_ops' was not declared. Should it be static?

@dbaluta Thanks. I reorder the patches but there is still sparse warning shown as below, The symbol 'sof_mt8195_ops' will be used in mediatek/mediatek-ops.h and cannot be set as static. Do you have any suggestion to fix it? Thanks.
CHECK sound/soc/sof/mediatek/mt8195/mt8195.c
sound/soc/sof/mediatek/mt8195/mt8195.c:371:24: error: symbol 'sof_mt8195_ops' was not declared. Should it be static?
make[5]: *** [scripts/Makefile.build:278: sound/soc/sof/mediatek/mt8195/mt8195.o] Error 1
make[5]: *** Deleting file 'sound/soc/sof/mediatek/mt8195/mt8195.o'

Copy link
Collaborator

@lyakh lyakh left a comment

Choose a reason for hiding this comment

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

nothing critical, all should be easy to address, but maybe good to do so at least for some of the comments before merging

}

adsp->pa_sram = (phys_addr_t)res->start;
adsp->srammsize = (u32)resource_size(res);
Copy link
Collaborator

Choose a reason for hiding this comment

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

why does .srammsize have two "m"s in it?

Copy link
Author

Choose a reason for hiding this comment

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

It is typo and I will modify it. thanks

struct adsp_chip_info *adsp = data;
int i, ret;

res = &resource;
Copy link
Collaborator

Choose a reason for hiding this comment

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

optional / cosmetic: you reuse res for different resources below. Maybe it would be better to just use &resource for the part, where that's what's needed to avoid confusion

Copy link
Author

Choose a reason for hiding this comment

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

OK. I will use struct resource res for of_address_to_resource and struct resource *mmio for platform_get_resource to avoid confusion. thanks.

adsp->dram_offset = offset;
offset >>= DRAM_REMAP_SHIFT;
dev_dbg(dev, "adsp->pa_dram %llx, offset 0x%x\n", adsp->pa_dram, offset);
WARN_ON(offset < 0);
Copy link
Collaborator

Choose a reason for hiding this comment

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

first of all, it would be better to check for this apparent error immediately after calculating offset or maybe even before that by chacking adsp->pa_dram < DRAM_PHYS_BASE_FROM_DSP_VIEW perhaps where it's obtained from res->start. Secondly what does a WARN_ON() bring? Is this a valid value? If not, perhaps it shouldn't be used.

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for suggestion but I think WARN_ON could be removed since offset can be negative value for mt8195 hardware design. thanks

#include "../../ops.h"
#include "../../sof-audio.h"

static struct adsp_chip_info *adsp_info;
Copy link
Collaborator

Choose a reason for hiding this comment

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

is this global variable really needed? I don't see any other platforms doing this.

Copy link
Author

Choose a reason for hiding this comment

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

ok. I will remove this global variable and use priv->adsp to replace it. thanks.

goto err_adsp_sram_power_off;
}
adsp_info->va_dram = sdev->bar[SOF_FW_BLK_TYPE_SRAM];
mailbox_type = SOF_FW_BLK_TYPE_SRAM;
Copy link
Collaborator

Choose a reason for hiding this comment

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

not really needed, you can use SOF_FW_BLK_TYPE_SRAM directly in assignments below

Copy link
Author

Choose a reason for hiding this comment

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

ok. I will remove it. thanks

#define DSP_RESERVED_1 (0x03F4)

/* dsp wdt */
#define DSP_WDT_MODE (0x0400)
Copy link
Collaborator

Choose a reason for hiding this comment

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

parentheses around individual constants aren't needed

Copy link
Author

Choose a reason for hiding this comment

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

ok. I will modify it. thanks

(SIZE_SHARED_DRAM_DL + SIZE_SHARED_DRAM_UL)

#define SRAM_PHYS_BASE_FROM_DSP_VIEW (0x40000000) /* MT8195 DSP view */
#define DRAM_PHYS_BASE_FROM_DSP_VIEW (0x60000000) /* MT8195 DSP view */
Copy link
Collaborator

Choose a reason for hiding this comment

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

ditto: parentheses unneeded

Copy link
Author

Choose a reason for hiding this comment

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

ok. I will modify them. thanks

};
#endif
#if IS_ENABLED(CONFIG_SND_SOC_SOF_MT8195)
static struct sof_dev_desc sof_of_mt8195_desc = {
Copy link
Collaborator

Choose a reason for hiding this comment

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

const

Copy link
Author

Choose a reason for hiding this comment

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

ok. I will add it. thanks

}

/* mt8195 ops */
struct snd_sof_dsp_ops sof_mt8195_ops = {
Copy link
Collaborator

Choose a reason for hiding this comment

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

const

Copy link
Author

Choose a reason for hiding this comment

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

ok. I will add it. thanks

@yaochunhung
Copy link
Author

yaochunhung commented Sep 23, 2021

@dbaluta There are conflicts in dai.h and topology.c. It seems caused by AMD's patch. Could you please help advice how to resolve it? Should I fetch the latest codes and create another PR? I tried to resolve conflicts but I don't have permission to commit merge after resolving conflicts. thanks.

@dbaluta
Copy link
Collaborator

dbaluta commented Sep 23, 2021

@dbaluta There are conflicts in dai.h and topology.c. It seems caused by AMD's patch. Could you please help advice how to resolve it? Should I fetch the latest codes and create another PR? I tried to resolve conflicts but I don't have permission to commit merge after resolving conflicts. thanks.

You don't need to create another Pull Request. Just do something like this on your branch that this PR was created from:

$ git fetch origin
$ git rebase origin/topic/sof-dev
# resolve conflicts
$ git push -f -u <your_github_remote>

That should be it.

@yaochunhung
Copy link
Author

@dbaluta I will try it.Thanks

dbaluta
dbaluta previously approved these changes Sep 23, 2021
Copy link
Member

@plbossart plbossart left a comment

Choose a reason for hiding this comment

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

minor nit-picks below, the main issue is really that we need the ability to compile this code with GitHub actions so that we can see any compilation-level issues on this PR and any changes to the SOF tree. Thanks!

@yaochunhung yaochunhung dismissed stale reviews from kv2019i and ranj063 via c7433a7 September 30, 2021 09:33
@yaochunhung yaochunhung force-pushed the mt8195-basic branch 2 times, most recently from c7433a7 to 3dc11be Compare September 30, 2021 09:57
@yaochunhung
Copy link
Author

@ujfalusi yes, IPC will be next PR. I also modify the PR by your comments. Please help to check if there is still anything I need to modify. thanks.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Just forward declare the sdev struct in the header, no need to include anything else:

struct snd_sof_dev;

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think you should have

void hifixdsp_boot_sequence(struct snd_sof_dev *sdev, u32 boot_addr)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Here you want to have

void hifixdsp_shutdown(struct snd_sof_dev *sdev)

I would probably prefix these functions with sof_

Copy link
Collaborator

Choose a reason for hiding this comment

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

Is it a good idea to do devm_ioremap() every time this function is called?

Copy link
Author

Choose a reason for hiding this comment

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

I will replace it with ioremap and iounmap. thanks.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I might have used different name instead of val, on perhaps is better?

Copy link
Author

Choose a reason for hiding this comment

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

ok. I will modify it. thanks

Copy link
Collaborator

Choose a reason for hiding this comment

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

Why void *data and not directly struct mtk_adsp_chip_info *adsp?

If you need, just forward declare it in the header.

Copy link
Author

Choose a reason for hiding this comment

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

ok. I will modify it.thanks.

Copy link
Collaborator

Choose a reason for hiding this comment

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

This is not much of a help if it happens, it might be better to
dev_err(dev, "ioremap failed for shared DRAM\n");

Copy link
Author

Choose a reason for hiding this comment

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

ok I will modify it. thanks

Copy link
Collaborator

Choose a reason for hiding this comment

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

Is there real information comes out from the [ADSP] prefix, you will have the device name in prints.

Copy link
Author

Choose a reason for hiding this comment

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

ok. I will remove it. thanks

@yaochunhung yaochunhung force-pushed the mt8195-basic branch 2 times, most recently from 86e7df1 to d5d22d8 Compare September 30, 2021 14:47
Copy link
Collaborator

@ujfalusi ujfalusi left a comment

Choose a reason for hiding this comment

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

@yaochunhung, thanks for the quick updates, it really looks fine, if you could align the numbers in the header I can approve it right away.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you align the numbers, there is one tab line jump here.

Copy link
Author

Choose a reason for hiding this comment

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

ok. I will align them. thanks!

Copy link
Author

@yaochunhung yaochunhung left a comment

Choose a reason for hiding this comment

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

@ujfalusi Thanks for comments. I update the patch. Please help to check it. thanks.

Copy link
Author

Choose a reason for hiding this comment

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

ok. I will align them. thanks!

Copy link
Collaborator

@ujfalusi ujfalusi left a comment

Choose a reason for hiding this comment

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

@yaochunhung, one comment needs to be moved up one line.

This patch initialize to support SOF on Mediatek mt8195 platform.
MT8195 has four Cortex A78 cores paired with four Cortex A55 cores.
It also has Cadence HiFi-4 DSP single core. There are shared DRAM and
mailbox interrupt between AP and DSP to use for IPC communication.

Signed-off-by: YC Hung <yc.hung@mediatek.com>
Add the definition for Mediatek audio front end(AFE) tokens,include
AFE sampling rate, channels, and format.

Signed-off-by: YC Hung <yc.hung@mediatek.com>
Add new sof dai and config to pass topology file configuration
to SOF firmware running on Mediatek platform DSP core.
Add mediatek audio front end(AFE) to the list of supported sof_dais

Signed-off-by: YC Hung <yc.hung@mediatek.com>
Add mt8195-loader module with ops callback to load and run firmware
on mt8195 platform.

Signed-off-by: YC Hung <yc.hung@mediatek.com>
Add SOF device and DT descriptor for Mediatek mt8195 platform.

Signed-off-by: YC Hung <yc.hung@mediatek.com>
Add dsp ops callback to register AFE DL2/DL3/UL4/UL5 sof dai's with ALSA

Signed-off-by: YC Hung <yc.hung@mediatek.com>
Copy link
Author

@yaochunhung yaochunhung left a comment

Choose a reason for hiding this comment

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

@ujfalusi I will modify it. thanks.

Copy link
Collaborator

@ujfalusi ujfalusi left a comment

Choose a reason for hiding this comment

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

@yaochunhung, thank you for the prompt updates!

The PR looks fine from my side.

@yaochunhung
Copy link
Author

@ujfalusi thanks for your comments and approval. :)

@plbossart
Copy link
Member

@dbaluta @lyakh @bardliao last call for reviews!

Copy link
Collaborator

@dbaluta dbaluta left a comment

Choose a reason for hiding this comment

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

LGTM, sorry for the late answer I had a day off on Friday.

@dbaluta dbaluta merged commit 786e304 into thesofproject:topic/sof-dev Oct 4, 2021
@yaochunhung
Copy link
Author

@dbaluta Thanks a lot for your suggestion and comments.

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.

9 participants