[4.18] corrupted tvservice -m mode list

[HiassofT]

With the current rpi-4.18.y kernel and latest rpi-update firmware (version 7e7f762267acd3e85aa3b72724f969b40fa4179c, Aug 8 2018 16:02:15) tvservice -m displays a corrupted list of modes. Several modes, resolutions and clocks show up as 0. This is especially bad as the preferred / current mode is missing.

eg when connected to a HP1755 (1280x1024, only DMT, no CEA modes)

on kernel 4.18

Group DMT has 12 modes:
           mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
           mode 5: 640x480 @ 72Hz 4:3, clock:31MHz progressive
           mode 6: 640x480 @ 75Hz 4:3, clock:31MHz progressive
           mode 9: 800x600 @ 60Hz 4:3, clock:40MHz progressive
           mode 10: 800x600 @ 72Hz 4:3, clock:50MHz progressive
           mode 11: 800x600 @ 75Hz 4:3, clock:49MHz progressive
           mode 16: 1024x768 @ 60Hz 4:3, clock:65MHz progressive
           mode 17: 1024x768 @ 70Hz 4:3, clock:75MHz progressive
           mode 18: 1024x768 @ 75Hz 4:3, clock:78MHz progressive
           mode 21: 1152x864 @ 75Hz 4:3, clock:0MHz progressive
           mode 0: 0x0 @ 0Hz unknown AR, clock:0MHz progressive
           mode 0: 0x0 @ 0Hz unknown AR, clock:0MHz progressive

on kernel 4.14 (current rpi-update kernel, same fw version as above) the output is fine

Group DMT has 12 modes:
           mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
           mode 5: 640x480 @ 72Hz 4:3, clock:31MHz progressive
           mode 6: 640x480 @ 75Hz 4:3, clock:31MHz progressive
           mode 9: 800x600 @ 60Hz 4:3, clock:40MHz progressive
           mode 10: 800x600 @ 72Hz 4:3, clock:50MHz progressive
           mode 11: 800x600 @ 75Hz 4:3, clock:49MHz progressive
           mode 16: 1024x768 @ 60Hz 4:3, clock:65MHz progressive
           mode 17: 1024x768 @ 70Hz 4:3, clock:75MHz progressive
           mode 18: 1024x768 @ 75Hz 4:3, clock:78MHz progressive
           mode 21: 1152x864 @ 75Hz 4:3, clock:108MHz progressive
  (prefer) mode 35: 1280x1024 @ 60Hz 5:4, clock:108MHz progressive
           mode 36: 1280x1024 @ 75Hz 5:4, clock:135MHz progressive

[mkreisl]

I can confirm this issue. Same crap here, issue started with 4.17 kernel.

This brakes Kodi (v18), because Kodi wants to set resolution mostly to 0x0, and of course, this never can work.

[pelwell]

@mkreisl 4.18 is still bleeding edge. Each new kernel version brings some breakage that we clean up as quickly as we can - I don't think the use of the word "crap" is justified. If it really did appear in 4.17, did you report it?

[mkreisl]

If it really did appear in 4.17, did you report it?

Believe me, it does. And no, I did not report it, because being unsure if this is Kodi Leia (this version is still in an early beta state) issue or kernel issue. But it seems to be a kernel issue

[maxnet]

Also seen it in 4.17
Reverting the following commit seems to fix it: 14dd37f

Seems device-tree passes 64 as cache-line-size.

[lategoodbye]

This patch was to avoid the introduction of the cache-line-size property for the driver.

There as a discussion about this: http://lists.infradead.org/pipermail/linux-rpi-kernel/2018-March/007786.html

So reverting the patch of @anholt isn't the right way to fix this.

[maxnet]

Because of the way partial cache lines are handled it is more important that the
two sides agree than that the value is correct. As a result, the firmware treats
the absence of a "cache_line_size" DT parameter (that sets the "cache-line-size"
property) in the DTB as an indication that the kernel driver pre-dates the ability
to switch, and uses the old fixed value of 32 as a fallback.

So the problem is that the (downstream?) device-tree files still have the cache_line_size parameter?

[lategoodbye]

Yes, this is my understanding. But i never test all variants.

[popcornmix]

@HiassofT I've reverted the identified commit on 4.18 as a temporary measure to avoid the vchiq regression.
It will be replaced when a better solution is identified.

[MilhouseVH]

This is looking good now - 4.14.62 and 4.18.0 (with this PR) now produces identical results.

4.14.62 (#0815):

rpi22:~ # tvservice -m CEA
Group CEA has 11 modes:
           mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
           mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
           mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
           mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
           mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced
  (prefer) mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
           mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
           mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
           mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive
           mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced
           mode 31: 1920x1080 @ 50Hz 16:9, clock:148MHz progressive
rpi22:~ # tvservice -m DMT
Group DMT has 6 modes:
           mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
           mode 9: 800x600 @ 60Hz 4:3, clock:40MHz progressive
           mode 16: 1024x768 @ 60Hz 4:3, clock:65MHz progressive
           mode 32: 1280x960 @ 60Hz 4:3, clock:108MHz progressive
           mode 35: 1280x1024 @ 60Hz 5:4, clock:108MHz progressive
           mode 58: 1680x1050 @ 60Hz 16:10, clock:146MHz progressive

4.18.0 (without this PR) (#0814b):

rpi22:~ # tvservice -m CEA
Group CEA has 11 modes:
           mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
           mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
           mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
           mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
           mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced
  (prefer) mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
           mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
           mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
           mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive
           mode 20: 1920x1080 @ 50Hz 16:9, clock:0MHz interlaced
           mode 0: 0x0 @ 0Hz unknown AR, clock:0MHz progressive
rpi22:~ # tvservice -m DMT
Group DMT has 6 modes:
           mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
           mode 9: 800x600 @ 60Hz 4:3, clock:40MHz progressive
           mode 16: 1024x768 @ 60Hz 4:3, clock:65MHz progressive
           mode 32: 0x0 @ 0Hz 4:3, clock:0MHz progressive
           mode 0: 0x0 @ 0Hz unknown AR, clock:0MHz progressive
           mode 0: 0x0 @ 0Hz unknown AR, clock:0MHz progressive

4.18.0 (with this PR) (#0815b):

rpi22:~ # tvservice -m CEA
Group CEA has 11 modes:
           mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
           mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
           mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
           mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
           mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced
  (prefer) mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
           mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
           mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
           mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive
           mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced
           mode 31: 1920x1080 @ 50Hz 16:9, clock:148MHz progressive
rpi22:~ # tvservice -m DMT
Group DMT has 6 modes:
           mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
           mode 9: 800x600 @ 60Hz 4:3, clock:40MHz progressive
           mode 16: 1024x768 @ 60Hz 4:3, clock:65MHz progressive
           mode 32: 1280x960 @ 60Hz 4:3, clock:108MHz progressive
           mode 35: 1280x1024 @ 60Hz 5:4, clock:108MHz progressive
           mode 58: 1680x1050 @ 60Hz 16:10, clock:146MHz progressive

[HiassofT]

thanks, current 4.18 tree seems to be fine. fingers crossed you find a solution for the root cause!

[pelwell]

The root cause is just that using the wrong cache line size causes incorrect behaviour.

The correct way to fix this in the absence of a property (or in general) is for the firmware to trust the kernel driver to use the correct value. The old method of the driver using a fixed value of 32 predates the BCM2836 so is sufficiently old that it can be ignored.

Unfortunately this change would probably break builds with old kernels worse than it is now, so the firmware needs a way of detecting that the kernel has been updated. Fortunately the VCHIQ DT properties are currently wrong - the reg declaration has a size specified in words (0xf) instead of bytes (0x3c). By fixing the DT in the same patch set as choosing the cache line size based on the architecture (v6 -> 32, v7&v8 -> 64) we would allow the firmware to do the right thing.

[pelwell]

See PR #2666.

[HiassofT]

thanks, already started a 4.18 build :)

[mkreisl]

This issue is back again in kernel 4.20 and 5.0 😞
staging/vc04_services: Derive g_cache_line_size commit is missing in 4.20.y and 5.0.y source tree, however the code

g_cache_line_size = ((read_cpuid_id() & 0x7f000) == 0x7b000) ? 32 : 64;

has been replaced by

g_cache_line_size = drvdata->cache_line_size;

and this seems to be wrong, because drvdata->cache_line_size has value 32 instead of required 64 for a Pi2/3/3+

Do I miss a new kernel CONFIG_ setting?

A revert to the previous code makes it work again

[lategoodbye]

The change is correct, but i assume the devicetree files still uses the old compatible brcm,bcm2835-vchiq instread of brcm,bcm2836-vchiq:
https://www.spinics.net/lists/arm-kernel/msg676786.html

[pelwell]

The required patch is now in rpi-4.20.y and rpi-5.0.y.

[mkreisl]

The required patch is now in rpi-4.20.y and rpi-5.0.y.

Thanks. This patch solves issue again 😄