qrbx2210 updates #70
qrbx2210 updates #70
Conversation
Signed-off-by: Alexey Klimov <[email protected]>
Signed-off-by: Alexey Klimov <[email protected]>
| status-display-gpu: 6.6 | ||
| status-display-hdmi: N/A | ||
| status-display-hdmiaudio: N/A | ||
| status-display-hdmi: 6.6 |
There was a problem hiding this comment.
No, the platform doesn't support HDMI.
There was a problem hiding this comment.
Ok, got it.
In such case I don't have a way to reflect that sm6115/qrb4210 supports HDMI sound output.
There was a problem hiding this comment.
Well, those chips do not have HDMI sound support. They have I2S output and then the board converts that to HDMI out. If necessary feel free to add new entry for I2S.
There was a problem hiding this comment.
Well, separate entry for i2s will be misleading as well.
One thing just pure i2s pins and playback support via them and another thing is playback via i2s pins routed to hdmi bridge. These can be the same pins (rb1, rb2) or separate pins (rb3 and rb5 iirc).
There was a problem hiding this comment.
rb1/2/3/5 are boards. This spreadsheet talks about SoC features. Corresponding SoC feature is to send audio over I2S bus. That is the feature that is listed as status-audio-i2s.
On a particular board I2S can be routed to I2S codec, I2S pins, HDMI bridge or something else. However all these popssible cases are of no concern to this page.
There was a problem hiding this comment.
I am not sure that what you described is particularly correct and it still looks misleading.
The platform (SoC, LPASS part of it) could support a feature to send i2s somewhere in general (and maybe receive/capture it as well) and in our cases here this would be supported by audio DSP, hence, in my understanding, this also described by "ADSP (Elite)" entry (let's focus on non-audioreach platforms for this discussion). There are different, not sure which word to use, i2s ports or controllers there, some of them could be even multi-channel i2s ports. (A)
Are we there yet? Can we send i2s already? No.
There is also an LPASS pin controller which could or might have specific pins that need to be configured in a certain way. For simple i2s one needs 3 or 4 pins to actually be able to send i2s data somewhere (or receive). There could be different number of such i2s groups or sets of pins related to specific i2s controllers from the audio DSP side.
So, let's say LPASS pinctrl pins 0,1,2 can be used for sending i2s data from first i2s "controller" from audio DSP, and pins 17,18,19 can be used by "third" or tertiary i2s "controller" on audio DSP. (B)
And this is platform or SoC features.
If I understand this incorrectly or this is all wrong, then let's chat.
Now, the platform doesn't really care where these i2s pins are routed: to HDMI bridge or to whatever or just simple exported via some connector and this will be specific to a specific board (RB1, 2, 3, 3gen2, et cetera).
What status-audio-i2s does describe exactly in such case? Ability to
send audio over I2S bus.
? Over which path+direction from (A) and (B) described above? All of them or just at least one i2s "controller" + its i2s pins? I highly doubt that these are all tested, supported and/'or described. Not that all of them are practically needed.
So when I was talking about
One thing just pure i2s pins and playback support via them and another thing is playback via i2s pins routed to hdmi bridge. These can be the same pins (rb1, rb2) or separate pins (rb3 and rb5 iirc).
I was referring to a specific "controller" or port on the audio DSP side and a specific set of pins for i2s transfer on the LPASS pin controller. And in my understanding these are SoC/platform features.
Hence we might need ideally:
status-audio-i2s-<specific_reference_to_i2s_controller_and_pins>
For example:
status-audio-i2s-primary(there might be no users of that path)status-audio-i2s-secondary(can be used for HDMI audio on some boards)status-audio-i2s-tertiary(can be used for HDMI audio on some boards and for LS connectors on others)
...
What single status-audio-i2s entry might describe? Single any "path"? All of them? Without such level of details I'd say it would be misleading. But do we need such level of details? It might be unmaintainable.
There was a problem hiding this comment.
The idea was 'any path', because adding another one is usually easy. Feel free to add any additional data (like which paths or which controllers are actually supported) to status-audio-i2s-comment:
There was a problem hiding this comment.
Wouldn't say it is easy in generic case.
Issues I saw already for different platforms:
-- random i2s path/adsp controller suddenly doesn't work (but others work just fine);
-- strange delays after enabling corresponding clocks (might be ignored for some usecases);
-- difficult to find configuration of pins for specific set of pins;
-- difficult to test or no way to test specific "path".
Feel free to add any additional data (like which paths or which controllers are actually supported) to status-audio-i2s-comment:
Ok, let's do that then.
There was a problem hiding this comment.
Well, that was an expectation :-D
Feel free to propose any kind of changes to the _soc.yaml if you think it will be beneficiable.
| status-audio-dmic: N/A | ||
| status-audio-adspelite: WIP | ||
| status-audio-analogcodec: WIP | ||
| status-audio-dmic: WIP |
There was a problem hiding this comment.
Are those supported by the SoC or by the pmic?
There was a problem hiding this comment.
Ah, my bad. I guess I need to update pmic pm4125 then for that.
|
@trashsee any updates? Gracious ping |
Let me update this. And I already regret touching this HDMI/i2s thingy. |
3 participants
Updates to reflect current state of RB2 and RB1 boards. Mostly audio-related updates.