vc4-kms-v3d overlay breaks bcm2835-i2s memory acquisition

[flatmax]

It appears that the i2s driver will not load when the vc4-kms-v3d overlay is loaded.
The reported reason appears to be because of a memory reservation conflict :
http://www.flatmax.org/phpbb/viewtopic.php?f=5&t=28
[ 9.831233] bcm2835-i2s 3f203000.i2s: can't request region for resource [mem 0x3f101098-0x3f10109f]
[ 9.840558] bcm2835-i2s: probe of 3f203000.i2s failed with error -16

Matt

[flatmax]

This is related to this issue :
#1420

Apparently due to clock frame work issues.

[pelwell]

Yes - it is the same issue. The I2S driver tries to directly manipulate the clock hardware, but the vc4-kms-v3d overlay enables the new clock driver which reserves the same I/O space as its domain. I don't think we'll be enabling the clock driver by default in the 4.4 tree, so in order to work with and without the vc4 overlay the I2S driver will need to support both access methods, presumably with a DT property to switch between the two modes. The obvious indication would be the absence of the second I/O region from the i2s node, which we can achieve by adding the shortened i2s "reg" property to the vc4-kms-v3d overlay.

[clivem]

I don't think we'll be enabling the clock driver by default in the 4.4 tree, so in order to work with and without the vc4 overlay the I2S driver will need to support both access methods, presumably with a DT property to switch between the two modes.

I can't help feeling that this is more goofy than just having accepted the complete dma/clock/i2s backport into the rpi-4.4.y tree to start with..... Oh well!

[pelwell]

Well, you know what they say about opinions.

@popcornmix I'm midway through a partial backport of this upstream commit. The options are:

1. Continue the backport, so that the clock driver support in the I2S driver is only used with the vc4-kms-v3d overlay.
2. Always use the clock driver.
3. Do nothing.

What are your thoughts?

[clivem]

Well, you know what they say about opinions.

That you are not interested in mine? ;)

No worries. I've been maintaining it out-of-tree for the audio guys that wanted to stick with 4.4.y for many months, so that's what I'll carry on doing.

[popcornmix]

@pelwell
Are you aware of any breakage by always using the clock driver?
No objection to always using it if it doesn't break anything.

The fourth option is to move to a newer kernel (4.8/4.9) where this isn't an issue.

[pelwell]

The only potential breakage I'm aware of is with the MIDI/DMX users who have been getting the kernel to use non-standard baudrates by lying about the UART clockrate. They will need an overlay to create a fixed-factor clock in order to achieve the same effect.

You have more exposure to feedback from Kodi's use of the 4.8 tree - how do you feel about either a full backport in 4.4 or switching up to 4.8?

[popcornmix]

Not aware of any problems with either clock driver or a move to 4.8 kernel.
All is stable in the kodi world.

I have a slight preference for 4.9 as the next stable kernel, due to the cleaner downstream patching, and it's rumoured to be LTS, but there's some argument to using 4.8 for rpi-update for a while as a stepping stone to 4.9 (may be a useful data point in regression testing).

[pelwell]

Do you have a preferred schedule for the update?

[popcornmix]

If it fixes this issue (avoiding the work of backporting) and we're not aware of any downsides then I don't mind doing this soon (e.g. this week). We've just had a stable bump to raspbian, so we have a while before the next stable release.

One thing I remember - vc4-kms-v3d / vc4-fkms-v3d is not working on 4.8 but is on 4.9.
I think it may just need some copy/pasting of DT nodes to make it work on 4.8, but we should either fix that or go straight to 4.9.

[clivem]

....avoiding the work of backporting....

FYI, the "work" was done back in August. #1592

[flatmax]

Interesting thing about all of this is that there is no need for clocking when the codec is master. For now another approach may be to work out how to segment the clock out of the i2s driver so that it can be used as is in those cases ... Matt

…

On 05/12/16 08:34, Clive Messer wrote: ....avoiding the work of backporting.... FYI, the "work" was done back in August. #1592 <#1592> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1746 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAq6B8lSVN8eh9Dq1MbAxZ9laK0rQ0-cks5rEzHggaJpZM4LDhw4>.

[pelwell]

The BRANCH=next kernel has been moved to 4.8 - see https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=167934 - having already been used succesfully by LibreELEC for a while. I doubt it will stay there for long before hitting the master branch.

[Ruffio]

@flatmax can this be closed? It looks like it has been resolved...

[flatmax]

Hey all, I am not sure of the state of this, are the two drivers working together nicely now with the current Raspbian Linux kernel ? thanks Matt

…

On 05/02/17 22:01, Rasmus Christiansen wrote: @flatmax <https://github.com/flatmax> can this be closed? It looks like it has been resolved... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1746 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAq6B_Mj8uJfLXWAr7_3nuZaaKhVKCOCks5rZav8gaJpZM4LDhw4>.