Mailbox power channel missing responses

[swarren]

When writing to the power channel in the VC mailbox, you typically get a response back which indicates the current (new) power state. However, this response is not sent under either of two conditions:

1. If the message sent ARM->VC is simply 0, there is no response. The only way to turn everything off and still get a response back is by setting some invalid bit in the message sent ARM->VC, since the VC always responds if you set some invalid bit.

This means you need a bit of a hack/kludge in the ARM-side driver if you do want to turn everything off for some reason.

2. If the new requested state is identical to the previously current state.

This makes hand-off between multiple ARM-side firmware difficult. Suppose the first thing to run on the ARM is U-Boot rather than the kernel, and the kernel is loaded over the (USB) network. This requires turning on USB power. Without explicit code, U-Boot would leave the USB power on. When the kernel starts, it assumes that nothing is turned on. When the power driver starts, it will try to turn on USB (since at least in the current older reference kernels, USB is listed as always-on). The power driver will actually send a message to the VC in this case, since it thinks the desired power state is different to the current power state. However, they are in fact identical, so I believe no response will be sent, which would cause the kernel power driver to hang or timeout. To solve this, U-Boot might be coded to power everything back off before starting the kernel, but that requires a workaround for (1).

If the VC would always respond to every power message (including 0), that would simplify the ARM-side logic a lot.

[popcornmix]

Can you check #47

[nomis]

I can't find the reference to the issue related to this, but in the Linux driver I send a message with just the MSB set to get the current state (which happens to turn everything off). There's also a hack in the latest kernel to send 0x0 on startup to do the same thing.

[swarren]

popcornmix, #47 looks very interesting, but I'd argue that this particular issue could be considered a bug in the existing power mailbox channel, rather than needing a new mailbox API.

lp0, yes, I did wonder about doing something like that to work around the issue, but unless it's documented as a legitimate usage of the mailbox API, I'm slightly hesitant to do that, since I have no idea what setting that MSB might mean to the VC. If BCM says it'll be fine though, it seems a reasonable enough workaround.

[popcornmix]

The API is working as designed, and changing this would break firmware/kernel compatibilty.
I'll make sure the desired API is supported in #47.

Sending bit 30 (not MSB) set is supported and will return current state.

[swarren]

I don't believe that fixing this would actually cause any compatibility issues.

All current drivers take explicit action to avoid sending a message requesting the same state as the current state, so that they don't hang up waiting for a response that won't come. As such, the scenario whose behavior would change isn't happening, so the change in behaviour wouldn't be noticed.

But that said, it setting bit 30 is a supported workaround to guarantee a response, that's fine too.

[nomis]

If the existing driver sent a device off message followed by a device on message, it could immediately read the response to the device off message by mistake.

[swarren]

I can't really see any problem here.

• Old FW, old kernel: No change.
• New FW, old kernel: FW supports new usage, but the kernel doesn't change so only sends commands and waits for responses it would have got anyway (i.e. as described above, avoids the problematic cases that'd change in the new FW, or it couldn't work with the old FW), so no change.
• New FW, new kernel: Works as expected.
• Old FW, new kernel: Admittedly doesn't work. But, if it's mandatory to support all new kernels on old FW, then we can't implement any new FW feature (e.g. issue Add new property/value mailbox channel #47) since any new kernel that uses the new FW feature would not work on an old FW.

[nomis]

Old kernel, new FW:

• Send power off
• Recv status (ignored, but stored by the driver)
• Send power on
• Read old status (as it was stored already)
• Recv new status

The mbox code in my branch will clear unread messages but there could still be an issue if you turn the power on for a device immediately after turning it off.

[swarren]

That seems like a bug; any time a message is sent, the driver should wait for the response. Otherwise even in normal operation irrespective of any FW change, you're going to get out-of-sync.