Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DO NOT MERGE] I.MX8 MU support #40

Open
wants to merge 1 commit into
base: sof-v4.2
Choose a base branch
from

Conversation

dianacretu
Copy link

Add implementation for MU write in order to communicate with the host.

Add implementation for MU write in order to
communicate with the host.

Signed-off-by: Diana Cretu <dianacretu2806@gmail.com>

log_write(adsp->log, space, addr, val, size,
info->region[addr >> 2]);

/* set value via SHM */
/* Interrupt arrived, check src */
info->region[addr >> 2] = val;
Copy link

Choose a reason for hiding this comment

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

I think it is OK to leave the initial comment here ' set value via SHM' because we are actually setting the value of register via SHM. Then move the comment with 'Interrupt arrived' just above the switch.

Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

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

Good to merge once @dbaluta approves

@dbaluta
Copy link

dbaluta commented May 7, 2020

Will keep this open for few days. I need to do some tests and more thinking, because MU (Messaging Unit) it is an interesting piece of hardware from emulation pow.

It has two sides: A and B one for Host and for DSP. The thing is that writing a register from A (lets say Generic Interrupt Request) has the effect of enabling a bit from side B (Generic Interrupt Pending).

I'm not sure we emulated this correctly. I need to think about it.

@lgirdwood
Copy link
Member

We have the same with the SHIM doorbell on BYT. We set the Bit on A and it's immediately visible on B (via SHM). However B is unaware of the change until we send the IRQ message.

@dbaluta
Copy link

dbaluta commented May 7, 2020

Yes, this is what we want. @dianacretu can you have a look on BYT implementation?

On qemu MU_A and MU_B sides are not in a continuous memory area.

So, when SOF writes on MU_A the write handler gets a reference to MU_A area but we couldn't figure out how to get a reference to MU_B also.

/* SHIM IO from ADSP */
static void mu_write(void *opaque, hwaddr addr,
        uint64_t val, unsigned size)
{
    struct adsp_io_info *info = opaque;
    struct adsp_dev *adsp = info->adsp;
    struct adsp_reg_space *space = info->space;
    struct qemu_io_msg_irq irq;
    uint64_t aux;

Here info->region[] points to MU_A but we would also want to have a reference to a similar object for MU_B.

@crazoes
Copy link

crazoes commented Jul 6, 2020

@dianacretu I am trying to make sof boot with fuzzer in imx8...in my investigation I noticed that the merged code doesn't write anything to parent yet which led me to your PR, seems like we introduce some writing to parent queue in this PR. Can you tell us what's left?
I can continue working on this if you can't.

@dianacretu
Copy link
Author

@dianacretu I am trying to make sof boot with fuzzer in imx8...in my investigation I noticed that the merged code doesn't write anything to parent yet which led me to your PR, seems like we introduce some writing to parent queue in this PR. Can you tell us what's left?
I can continue working on this if you can't.

The problem with this PR is that the interrupts are not activated, so the interrupt handler from SOF does not receive any interrupts. More exactly, we need an equivalent to "adsp_set_lvl1_irq" function from the byt implementation. This function is used in byt-shim.c file when qemu received a message (which can be a message sent by the fuzzer), so we need to do the same for imx8.

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.

4 participants