Skip to content

Conversation

@popcornmix
Copy link
Collaborator

Signed-off-by: Dom Cobley [email protected]

@popcornmix
Copy link
Collaborator Author

Marking as WIP until I work out what else is needed.

With this, we do generate a valid vendor infoframe with 3d parameters.
And Kodi will make the 3D signal on my TV come on.

However the display image is garbled.
Need to work out if this is a clocking type issue or framebuffer geometry issue.

connector,
mode);
if (ret < 0) {
DRM_ERROR("couldn't fill HDMI infoframe (%d)\n", ret);
Copy link
Contributor

Choose a reason for hiding this comment

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

https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_edid.c#L5809

Note that there's is a need to send HDMI vendor infoframes only when using a
4k or stereoscopic 3D mode. So when giving any other mode as input this
function will return -EINVAL, error that can be safely ignored.

Logging an error is therefore a bad move.

DRM_ERROR("couldn't fill HDMI infoframe (%d)\n", ret);
return;
}
ret = hdmi_vendor_infoframe_check(&frame.vendor.hdmi);
Copy link
Contributor

Choose a reason for hiding this comment

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

Seeing as we've only just generated this, is there a possibility that it is wrong? It seems to vary between drivers whether they check this or not.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I was looking at intel_hdmi which does do this (for this infoframe and others).
Happy to skip it if it's believed redundant at this point.

I also noticed we aren't adding drm_hdmi_infoframe_set_hdr_metadata which we may want in future
(although I suspect Maxime may be adding this in 10-bit colour work.).

Copy link
Contributor

Choose a reason for hiding this comment

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

i915 is a pretty good reference :-)
Even so, I think it's impossible.
Looking at hdmi_vendor_infoframe_check_only - https://elixir.bootlin.com/linux/latest/source/drivers/video/hdmi.c#L515,
type, version, and oui will have been set by hdmi_vendor_infoframe_init
frame->length has been set to hdmi_vendor_infoframe_length(frame)
That only leaves frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID.
frame->vic is set by drm_mode_hdmi_vic which includes if (mode->flags & DRM_MODE_FLAG_3D_MASK) return 0;, so that should ensure it is 0 in any 3D mode.

HDR patches are in progress, but yes that is the right patchset to be adding the infoframe. There's no point in sending it if you don't support HDR.

Phil Elwell and others added 28 commits November 17, 2020 11:43
The irq_fence and done_fence are given a reference that is never
released. The necessary dma_fence_put()s seem to have been
deleted in error in an earlier commit.

Fixes: 0b73676 ("drm/v3d: Clock V3D down when not in use.")

Signed-off-by: Phil Elwell <[email protected]>
Following the same pattern as bcm2835-camera and bcm2835-audio,
register the vcsm-cma driver as a platform driver

Signed-off-by: Dave Stevenson <[email protected]>
Following the same pattern as bcm2835-camera and bcm2835-audio,
register the V4L2 codec driver as a platform driver

Signed-off-by: Dave Stevenson <[email protected]>
As of 5.4, the kernel logs errors for absent IRQs unless requested
with platform_get_irq_optional.

Signed-off-by: Phil Elwell <[email protected]>
Add device tree entries and code to allow the specification of
the lighting modes for the LED's on the ethernet connector.

Signed-off-by: James Hughes <[email protected]>
This should return default behaviour back to that of previous
releases.
… interface

Setting the v3d clock to low value allows firmware to handle dvfs in case
where v3d hardware is not being actively used (e.g. console use).

Signed-off-by: popcornmix <[email protected]>
For performance/power it is beneficial to adjust gpu clocks with arm clock.
This is how the downstream cpufreq driver works

Signed-off-by: popcornmix <[email protected]>
This is controlled by firmware, see clk-raspberrypi.c

Signed-off-by: popcornmix <[email protected]>
Both coherent_dma_mask and dma_mask act as constraints on allocations
and bounce buffer usage, so be sure to set dma_mask to the appropriate
value otherwise the effective mask could be incorrect.

Signed-off-by: Phil Elwell <[email protected]>
The VCHIQ driver now loads the audio, camera, codec, and vc-sm
drivers as platform drivers. However they were not being given
the correct DMA configuration.

Call of_dma_configure with the parent (VCHIQ) parameters to be
inherited by the child.

Signed-off-by: Dave Stevenson <[email protected]>
…devices

vchiq on Pi4 is no longer under the soc node, therefore it
doesn't get the dma-ranges for the VPU.

Switch to using the configuration of the old dma controller as
that will set the dma-ranges correctly.

Signed-off-by: Dave Stevenson <[email protected]>
Make the BCM2711 a different machine, but keep it in board_bcm2835.

Signed-off-by: Stefan Wahren <[email protected]>
The IMA (Integrity Measurement Architecture) looks for a TPM (Trusted
Platform Module) having been registered when it initialises; otherwise
it assumes there is no TPM. It has been observed on BCM2835 that IMA
is initialised before TPM, and that initialising the BCM2835 clock
driver before the firmware driver has the effect of reversing this
order.

Change the firmware driver to initialise at core_initcall, delaying the
BCM2835 clock driver to postcore_initcall.

See: raspberrypi#3291
     raspberrypi#3297

Signed-off-by: Luke Hinds <[email protected]>
Co-authored-by: Phil Elwell <[email protected]>
vchiq kernel clients are now instantiated as platform drivers rather
than using DT, but the children of the vchiq interface may still
benefit from access to DT properties. Give them the option of a
a sub-node of the vchiq parent for configuration and to allow
them to be disabled.

Signed-off-by: Phil Elwell <[email protected]>
A failure in gpiochip_irqchip_add leads to a leak of a gpiochip. Fix
the leak with the use of devm_gpiochip_add_data.

Fixes: 85ae9e5 ("pinctrl: bcm2835: switch to GPIOLIB_IRQCHIP")
Signed-off-by: Phil Elwell <[email protected]>
pinctrl-bcm2835 is a combined pinctrl/gpio driver. Currently the gpio
side is registered first, but this breaks gpio hogs (which are
configured during gpiochip_add_data). Part of the hog initialisation
is a call to pinctrl_gpio_request, and since the pinctrl driver hasn't
yet been registered this results in an -EPROBE_DEFER from which it can
never recover.

Change the initialisation sequence to register the pinctrl driver
first.

See: https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=260600

Signed-off-by: Phil Elwell <[email protected]>
The downstream .dts files only request two GPIO IRQs. Truncate the
array of parent IRQs when irq_of_parse_and_map returns 0.

Signed-off-by: Phil Elwell <[email protected]>
The definition of compat_ptr is now common for most platforms, but
requires the inclusion of <linux/compat.h>.

Signed-off-by: Phil Elwell <[email protected]>
The definition of compat_ptr is now common for most platforms, but
requires the inclusion of <linux/compat.h>.

Signed-off-by: Phil Elwell <[email protected]>
When symbols from overlays are added to the live tree their paths must
be rebased. The translated symbol is normally the result of joining
the fragment-relative path (with a leading "/") to the target path
(either copied directly from the "target-path" property or resolved
from the phandle). This translation fails when the target is the root
node (a common case for Raspberry Pi overlays) because the resulting
path starts with a double slash. For example, if target-path is "/" and
the fragment adds a node called "newnode", the label associated with
that node will be assigned the path "//newnode", which can't be found
in the tree.

Fix the failure case by explicitly replacing a target path of "/" with
an empty string.

Fixes: d1651b0 ("of: overlay: add overlay symbols to live device tree")

Signed-off-by: Phil Elwell <[email protected]>
The DT bindings description of the Brcmstb PCIe device is described.  This
node can be used by almost all Broadcom settop box chips, using
ARM, ARM64, or MIPS CPU architectures.

Signed-off-by: Jim Quinlan <[email protected]>
This is adjustment to commit
d368cea "kbuild: Allow .dtbo overlays to be built piecemeal"

prepare3 target has gone from mainline tree in branch 5.4.y

Signed-off-by: Nataliya Korovkina <[email protected]>
Possible fixed upstream by 'net: bcmgenet: keep MAC in reset until PHY is up'

Signed-off-by: popcornmix <[email protected]>
Adds a format that is 3 10bit YUV 4:2:0 samples packed into
a 32bit work (with 2 spare bits).

Supported on Broadcom BCM2711 chips.

Signed-off-by: Dave Stevenson <[email protected]>
Taken from https://patchwork.linuxtv.org/patch/60728/
Changes (mainly documentation) have been requested.

HEVC has a scaling matrix concept. Add support for it.

Signed-off-by: Jernej Skrabec <[email protected]>
From https://patchwork.linuxtv.org/patch/60725/
Changes requested, but mainly docs.

If HEVC frame consists of multiple slices, segment address has to be
known in order to properly decode it.

Add segment address field to slice parameters.

Signed-off-by: Jernej Skrabec <[email protected]>
popcornmix and others added 9 commits November 17, 2020 11:47
[1] replaced a single reset function with a pointer to one of two
implementations, but also removed the call asserting the reset
at the start of brcm_pcie_setup. Doing so breaks Raspberry Pis with
VL805 XHCI controllers lacking dedicated SPI EEPROMs, which have been
used for USB booting but then need to be reset so that the kernel
can reconfigure them. The lack of a reset causes the firmware's loading
of the EEPROM image to RAM to fail, breaking USB for the kernel.

See: https://www.raspberrypi.org/forums/viewtopic.php?p=1758157#p1758157

Fixes: 04356ac ("PCI: brcmstb: Add bcm7278 PERST# support")

[1] 04356ac ("PCI: brcmstb: Add bcm7278 PERST# support")

Signed-off-by: Phil Elwell <[email protected]>
Using a hdmi analyser the bytes in packet ram
registers beyond the length were visible in the
infoframes and it flagged the checksum as invalid.

Zeroing unused words of packet RAM avoids this

Signed-off-by: Dom Cobley <[email protected]>
Not all systems have the interrupt line wired up, so switch to
polling the touchscreen off a timer if no interrupt line is
configured.

Signed-off-by: Dave Stevenson <[email protected]>
This touchscreen controller is used by the 7" DSI panel, and
this overlay configures it for when it is NOT being polled by
the firmware.

Signed-off-by: Dave Stevenson <[email protected]>
…elay.

We now have the hardware I2C controller pinmuxed to the drive the
display I2C, but this controller does not support clock stretching.
The Atmel micro-controller in the panel requires clock stretching
to allow it to prepare any data to be read.

Split the rpi_touchscreen_i2c_read into two independent transactions with
a delay between them for the Atmel to prepare the data.

Signed-off-by: Dave Stevenson <[email protected]>
In switching to the hardware I2C controller there is an issue
where we seem to not get back the correct state from the Pi
touchscreen.
Insert a delay before polling to avoid this condition.

Signed-off-by: Dave Stevenson <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
@popcornmix
Copy link
Collaborator Author

I think I'm happy with the half-SBS and half-TAB modes doing the right thing (they trigger the right 3d mode on TV and poking kodi I can get a framebuffer that matches).

I've added an enable 3d flag to modetest. It will switch to the half-SBS/half-TAB modes and display a testcard (not in 3d).
It doesn't like the FP mode and gets an ENOSPC when choosing it. Tracked it to here:

[ 1340.665441] [drm:drm_ioctl [drm]] comm="modetest" pid=1823, dev=0xe201, auth=1, DRM_IOCTL_MODE_SETCRTC
[ 1340.665957] [drm:drm_mode_setcrtc [drm]] [CRTC:72:crtc-3]
[ 1340.666664] [drm:drm_framebuffer_check_src_coords [drm]] Invalid source coordinates 1920.000000x2205.000000+0.000000+0.000000 (fb 1920x1080)
[ 1340.666744] [drm:drm_mode_object_put.part.0 [drm]] OBJ ID: 222 (2)
[ 1340.667139] [drm:drm_ioctl [drm]] comm="modetest", pid=1823, ret=-28

I like the 1920x2205 (that's a FP framebuffer with 45 lines of padding between left and right). Not sure why the dimensions are not matching. Possibly an issue in modetest? But it can otherwise switch resolutions....

@6by9
Copy link
Contributor

6by9 commented Nov 17, 2020

The source rectangle being requested is bigger than the frame buffer, or effectively off into non-framebuffer memory.
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_framebuffer.c#L76

@popcornmix
Copy link
Collaborator Author

Yes, but why?
modetest -3 is reporting:

  #20 1920x1080 24.00 1920 2558 2602 2750 1080 1084 1089 1125 74250 flags: phsync, pvsync; 3d: fp; type: driver

I'm just passing:

modetest -3 -d -s 32:#20

so I'd assume modetest is just requesting the dimensions it has been given by drm.
The same procedure with the non-3d or half-SBS/half-TAB behaves sensibly.

@6by9
Copy link
Contributor

6by9 commented Nov 17, 2020

Presumably the half modes result in a framebuffer that is still 1920x1080 overall. It's asking for the wrong part of the image for each eye, but that's not going to be a failure as such.

Note that both i915 and nouveau double the clock for frame packing mode.
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/display/intel_hdmi.c#L2239
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/nouveau/nouveau_connector.c#L1074
It may just be modetest not reporting it, but I'm assuming we need to do likewise. Ah, except that's only for mode validation of clock rate though, so shouldn't cause failures.

https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_modes.c#L861 appears to be where the stereo config gets expanded up vertically.
I'd suspect that the drm framebuffer emulation doesn't note the 3d packing flag, so has only created a single image sized FB, and it complains when it then tries to display it.

@popcornmix popcornmix force-pushed the rpi-5.10.y branch 2 times, most recently from a99052d to 37c3abe Compare December 7, 2020 17:13
@popcornmix popcornmix force-pushed the rpi-5.10.y branch 2 times, most recently from 8cb2e66 to 967d45b Compare December 18, 2020 18:55
@popcornmix popcornmix force-pushed the rpi-5.10.y branch 2 times, most recently from b1f4757 to 31fbc18 Compare December 27, 2020 13:53
@popcornmix popcornmix force-pushed the rpi-5.10.y branch 2 times, most recently from 3403b48 to ab9e2a6 Compare January 11, 2021 14:55
@popcornmix popcornmix force-pushed the rpi-5.10.y branch 2 times, most recently from 839c811 to 17cf96b Compare January 21, 2021 15:14
@popcornmix popcornmix force-pushed the rpi-5.10.y branch 2 times, most recently from 9007908 to c5f51df Compare January 27, 2021 19:14
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.