Hi,
On 09.02.2024 16:39, Jeffrey Hugo wrote:
> On 2/7/2024 3:24 AM, Jacek Lawrynowicz wrote:
>> Issue IP reset before shutdown in order to
>> complete all upstream requests to the SOC.
>> Without this DevTLB is complaining about
>> incomplete transactions and NPU cannot resume from
>> suspend.
>>
Applied to drm-misc-fixes
On 06.02.2024 16:19, Jacek Lawrynowicz wrote:
> Issue IP reset before shutdown in order to
> complete all upstream requests to the SOC.
> Without this DevTLB is complaining about
> incomplete transactions and NPU cannot resume from
> suspend.
> This problem is only happen
On 11/02/2024 10:51, Tony Lindgren wrote:
> From: Michael Walle
>
> For a normal operation, the stby GPIO is not needed.
>
> The reset pin is required because once the PPI (PHY protocol interface)
> is started, it can only be stopped by asserting the reset pin.
>
> Signed-off-by: Michael Walle
On 11/02/2024 10:51, Tony Lindgren wrote:
> The device uses a clock lane, and 1 to 4 DSI data lanes. Let's add the
> data-lanes property starting at 1 similar to what the other bridge
> bindings are doing.
>
> Let's also drop the data-lanes properties in the example for the DSI host
> controller t
On 11/02/2024 10:51, Tony Lindgren wrote:
> The tc358765 is similar to tc358775. The tc358765 just an earlier version
> of the hardware, and it's pin and register compatible with tc358775 for
> most part.
>
> From the binding point of view the only difference is that the tc358765
> does not have s
* Krzysztof Kozlowski [240212 08:06]:
> On 11/02/2024 10:51, Tony Lindgren wrote:
> > The tc358765 is similar to tc358775. The tc358765 just an earlier version
> > of the hardware, and it's pin and register compatible with tc358775 for
> > most part.
> >
> > From the binding point of view the onl
Hi Matthew,
Can I push this test case along with the bug fix patch.
Thanks,
Arun.
On 2/8/2024 8:06 PM, Matthew Auld wrote:
Sanity check DRM_BUDDY_CONTIGUOUS_ALLOCATION.
References: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Signed-off-by: Matthew Auld
Cc: Arunpravin Paneer Selvam
applied to drm-misc-next
On Tue, Jan 30, 2024 at 9:07 AM Qiang Yu wrote:
>
> Serial is Reviewed-by: QIang Yu
>
> On Wed, Jan 24, 2024 at 11:00 AM Erico Nunes wrote:
> >
> > v1 reference:
> > https://patchwork.kernel.org/project/dri-devel/cover/20240117031212.1104034-1-nunes.er...@gmail.com/
> >
On Fri, 9 Feb 2024 14:29:30 -0300
Arthur Grillo wrote:
> On 09/02/24 05:32, Pekka Paalanen wrote:
> > On Thu, 8 Feb 2024 16:38:31 -0300
> > Arthur Grillo wrote:
> >
> >> On 08/02/24 06:50, Pekka Paalanen wrote:
> >>> On Wed, 07 Feb 2024 17:17:15 -0300
> >>> Arthur Grillo wrote:
> >>>
On Fri, 9 Feb 2024 17:53:07 +0100
Xaver Hugl wrote:
> Signed-off-by: Xaver Hugl
> ---
> drivers/gpu/drm/drm_connector.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b0516505f7ae..01e13984629b 100644
Set the firmware framebuffer's parent device, which usually is the
graphics hardware's physical device. Integrates the framebuffer in
the Linux device hierarchy and lets Linux handle dependencies among
devices. For example, the graphics hardware won't be suspended while
the firmware device is still
If the firmware framebuffer has been reloacted, the sysfb code
fixes the screen_info state before it creates the framebuffer's
platform device. Efifb will automatically receive a screen_info
with updated values. Hence remove the tracking from efifb.
Signed-off-by: Thomas Zimmermann
Reviewed-by: J
Test if the firmware framebuffer's parent PCI device, if any, has
been enabled. If not, the firmware framebuffer is most likely not
working. Hence, do not create a device for the firmware framebuffer
on disabled PCI devices.
So far, efifb tracked the status of the PCI parent device internally
and
On ARM PCI systems, the PCI hierarchy might be reconfigured during
boot and the firmware framebuffer might move as a result of that.
The values in screen_info will then be invalid.
Work around this problem by tracking the framebuffer's initial
location before it get relocated; then fix the screen_
There will be no EFI framebuffer device for disabled parent devices
and thus we never probe efifb in that case. Hence remove the tracking
code from efifb.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/efifb.c | 5 +
1 file changed, 1 insertio
The EFI device has the correct parent device set. This allows Linux
to handle the power management internally. Hence, remove the manual
PM management for the parent device from efifb.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/efifb.c | 16 +++
The plain values as stored in struct screen_info need to be decoded
before being used. Add helpers that decode the type of video output
and the framebuffer I/O aperture.
Old or non-x86 systems may not set the type of video directly, but
only indicate the presence by storing 0x01 in orig_video_isVG
Add screen_info_get_pci_dev() to find the PCI device of an instance
of screen_info. Does nothing on systems without PCI bus.
v3:
* search PCI device with pci_get_base_class() (Sui)
v2:
* remove ret from screen_info_pci_dev() (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by:
Detect the firmware framebuffer's parent device from the global
screen_info state and set up the framebuffer's device accordingly.
Remove the equivalent functionality from efifb. Other drivers for
firmware framebuffers, such as simpledrm or vesafb, now add these
new features.
Patches 1 and 2 provi
On Fri, 9 Feb 2024 17:53:07 +0100
Xaver Hugl wrote:
> Signed-off-by: Xaver Hugl
> ---
> drivers/gpu/drm/drm_connector.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b0516505f7ae..01e13984629b 100644
On 12/02/2024 08:23, Arunpravin Paneer Selvam wrote:
Hi Matthew,
Can I push this test case along with the bug fix patch.
Sure. Please go ahead.
Thanks,
Arun.
On 2/8/2024 8:06 PM, Matthew Auld wrote:
Sanity check DRM_BUDDY_CONTIGUOUS_ALLOCATION.
References: https://gitlab.freedesktop.org/
On Mon, 12 Feb 2024, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/tests/drm_mm_test.c: In function 'drm_test_mm_debug':
> drivers/gpu/drm/tests/drm_mm_test.c:191:32: error: implicit dec
There is a spelling mistake in a drm_dbg_dp message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 03bbdf865d26..320f17fce9a6
On 12/02/2024 10:16, Colin Ian King wrote:
There is a spelling mistake in a drm_dbg_dp message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/ms
On Fri, Feb 09, 2024 at 09:30:46PM +0100, Sebastian Wick wrote:
> On Fri, Feb 02, 2024 at 04:49:04PM +0100, Maxime Ripard wrote:
> > Hi Sebastian,
> >
> > On Mon, Jan 15, 2024 at 03:33:08PM +0100, Sebastian Wick wrote:
> > > > /**
> > > > * DOC: HDMI connector properties
> > > > *
> > > > + *
On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote:
> On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote:
> > On Fri, Feb 02, 2024 at 06:37:52PM +0200, Ville Syrjälä wrote:
> > > On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard wrote:
> > > > On Fri, Feb 02, 2024 at 05
On Sat, 10 Feb 2024, Abhinav Kumar wrote:
> From: Paloma Arellano
>
> YUV420 format is supported only in the VSC SDP packet and not through
> MSA. Hence add an API which indicates the sink support which can be used
> by the rest of the DP programming.
>
> changes in v3:
> - fix the commit t
https://bugzilla.kernel.org/show_bug.cgi?id=218483
Bug ID: 218483
Summary: Blank screen on Cezanne/Barcelo APU with
amdgpu.seamless=1
Product: Drivers
Version: 2.5
Hardware: AMD
OS: Linux
Status:
https://bugzilla.kernel.org/show_bug.cgi?id=218483
Luya Tshimbalanga (l...@fedoraproject.org) changed:
What|Removed |Added
Kernel Version||6.7.4
--
Yo
Remove unnecessary dependencies in the include statements of the
header file . Several files throughout the kernel include
the fbdev header, so reducing dependencies positively affects other
subsystems as well. Also fix up nouveau, which needs backlight.h in
one of its source files.
Thomas Zimmerm
Resolved the proxy include via , which does not require the
backlight header.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index
Add forward declarations for struct i2c_adapter and struct module, and
sort the list alphabetically.
Signed-off-by: Thomas Zimmermann
---
include/linux/fb.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 42155898374b1..8f
Forward declare struct notifier_block and remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
include/linux/fb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index f269ba5202809..90f348f14a490 100644
--- a/include/linu
Forward declare struct inode and remove the include statement.
Signed-off-by: Thomas Zimmermann
---
include/linux/fb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 7380d959c5d53..f269ba5202809 100644
--- a/include/linux/fb.h
++
Forward declare struct page and remove the include statement.
Signed-off-by: Thomas Zimmermann
---
include/linux/fb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 90f348f14a490..42155898374b1 100644
--- a/include/linux/fb.h
+++
Include mutex.h, printk.h and types.h, remove several unnecessary
include statements, and sort the list alphabetically.
Signed-off-by: Thomas Zimmermann
---
include/linux/fb.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
inde
Forward declare struct backlight_device and remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
include/linux/fb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 2ce2f5c2fca9a..7380d959c5d53 100644
--- a/include/li
On 08/02/2024 11:43, Lee Jones wrote:
> On Fri, 02 Feb 2024 05:47:33 +0530, Dharma Balasubiramani wrote:
>> Convert the atmel,hlcdc binding to DT schema format.
>>
>> Align clocks and clock-names properties to clearly indicate that the LCD
>> controller expects lvds_pll_clk when interfaced with the
On Mon, 12 Feb 2024, Thomas Zimmermann wrote:
> Remove unnecessary dependencies in the include statements of the
> header file . Several files throughout the kernel include
> the fbdev header, so reducing dependencies positively affects other
> subsystems as well. Also fix up nouveau, which needs
Hello,
syzbot found the following issue on:
HEAD commit:445a555e0623 Add linux-next specific files for 20240209
git tree: linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=175fa6ec18
kernel config: https://syzkaller.appspot.com/x/.config?x=85aa3388229f9ea9
dashbo
Document the Adreno 750 GMU found on the SM8650 platform.
Signed-off-by: Neil Armstrong
---
Documentation/devicetree/bindings/display/msm/gmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml
b/Documentation/devicetree/bindings/displ
Document the GPU SMMU found on the SM8650 platform.
Signed-off-by: Neil Armstrong
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
b/Documentation/devicetree
Add support for the A750 GPU found on the SM8650 platform
Unlike the the very close A740 GPU on the SM8550 SoC, the A750 GPU
doesn't have an HWCFG block but a separate register set.
The missing registers are added in the a6xx.xml.h file that would
require a subsequent sync and the non-existent hw
Unlike the the very close A740 GPU on the SM8550 SoC, the A750 GPU
doesn't have an HWCFG block but a separate register set.
The missing registers are added in the a6xx.xml.h file that would
require a subsequent sync and the non-existent hwcfg is handled
in a6xx_set_hwcg().
The A750 GPU info are a
Add GPU nodes for the SM8650 platform.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 169 +++
1 file changed, 169 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi
b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index c455ca4e6475
Add path of the GPU firmware for the SM8650-QRD board
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
index 8515498553bf..7151f
The indicated commit below added a device argument to the
function, but there was a call in the xe driver that was
not properly changed.
Fixes: 5e0c04c8c40b ("drm/print: make drm_err_printer() device specific by
using drm_err()")
Cc: Jani Nikula
Cc: Luca Coelho
Cc: Maxime Ripard
Signed-off-by:
On 12.02.2024 11:37, Neil Armstrong wrote:
> Document the Adreno 750 GMU found on the SM8650 platform.
>
> Signed-off-by: Neil Armstrong
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 12.02.2024 11:37, Neil Armstrong wrote:
> Add support for the A750 GPU found on the SM8650 platform
>
> Unlike the the very close A740 GPU on the SM8550 SoC, the A750 GPU
> doesn't have an HWCFG block but a separate register set.
>
> The missing registers are added in the a6xx.xml.h file that
Hello,
syzbot found the following issue on:
HEAD commit:a5b6244cf87c Merge tag 'block-6.8-2024-02-10' of git://git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15e9ad5018
kernel config: https://syzkaller.appspot.com/x/.config?x=53985487b59d9442
das
On 12.02.2024 11:37, Neil Armstrong wrote:
> Add GPU nodes for the SM8650 platform.
>
> Signed-off-by: Neil Armstrong
> ---
> arch/arm64/boot/dts/qcom/sm8650.dtsi | 169
> +++
> 1 file changed, 169 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8650.d
On 12.02.2024 11:37, Neil Armstrong wrote:
> Add path of the GPU firmware for the SM8650-QRD board
>
> Signed-off-by: Neil Armstrong
> ---
Reviewed-by: Konrad Dybcio
Konrad
On Mon, Feb 12, 2024 at 11:38:33AM +0100, Thomas Hellström wrote:
> The indicated commit below added a device argument to the
> function, but there was a call in the xe driver that was
> not properly changed.
>
> Fixes: 5e0c04c8c40b ("drm/print: make drm_err_printer() device specific by
> using d
On Mon, 12 Feb 2024, Thomas Hellström wrote:
> The indicated commit below added a device argument to the
> function, but there was a call in the xe driver that was
> not properly changed.
Aww, crap. Looks like my drm-misc-next configs don't have xe enabled.
Reviewed-by: Jani Nikula
> Fixes: 5e
On Sat, Feb 10, 2024 at 05:16:17PM +0100, Duje Mihanović wrote:
> The struct containing the KTD2801 timing can be made static as it's not
> referenced outside the KTD2801 driver. Do this to prevent sparse
> complaints.
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbui
From: Arnd Bergmann
The new backlight driver unconditionally selects LEDS_EXPRESSWIRE, which
is in a different subsystem that may be disabled here:
WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=y]
Selected by [y]:
- BACKLIGHT_KT
From: Arnd Bergmann
The conversion to kvcalloc() mixed up the object size and count
arguments, causing a warning:
drivers/gpu/drm/nouveau/nouveau_svm.c: In function
'nouveau_svm_fault_buffer_ctor':
drivers/gpu/drm/nouveau/nouveau_svm.c:1010:40: error: 'kvcalloc' sizes
specified with 'sizeof' i
On Sun Feb 11, 2024 at 10:51 AM CET, Tony Lindgren wrote:
> The hs_rate and lp_rate may be used by the dsi host for timing
> calculations. The tc358775 has a maximum bit rate of 1 Gbps/lane,
> tc358765 has maximurate of 800 Mbps per lane.
>
> Signed-off-by: Tony Lindgren
Reviewed-by: Michael Walle
On Sat, 10 Feb 2024, Mario Limonciello wrote:
> On 2/9/2024 12:57, Daniel Vetter wrote:
>> On Fri, Feb 09, 2024 at 09:34:13AM -0600, Mario Limonciello wrote:
>>> On 2/9/2024 05:07, Daniel Vetter wrote:
On Thu, Feb 08, 2024 at 11:57:11AM +0200, Jani Nikula wrote:
> On Wed, 07 Feb 2024, Mar
On 12/02/2024 09:17, Tony Lindgren wrote:
> * Krzysztof Kozlowski [240212 08:06]:
>> On 11/02/2024 10:51, Tony Lindgren wrote:
>>> The tc358765 is similar to tc358775. The tc358765 just an earlier version
>>> of the hardware, and it's pin and register compatible with tc358775 for
>>> most part.
>>
On 22/01/2024 16:30, Boris Brezillon wrote:
> Tiler heap growing requires some kernel driver involvement: when the
> tiler runs out of heap memory, it will raise an exception which is
> either directly handled by the firmware if some free heap chunks are
> available in the heap context, or passed b
On 08/02/2024 18:13, Erick Archer wrote:
The "struct i915_syncmap" uses a dynamically sized set of trailing
elements. It can use an "u32" array or a "struct i915_syncmap *"
array.
So, use the preferred way in the kernel declaring flexible arrays [1].
Because there are two possibilities for the
syzbot has bisected this issue to:
commit ea40d7857d5250e5400f38c69ef9e17321e9c4a2
Author: Daniel Vetter
Date: Fri Oct 9 23:21:56 2020 +
drm/vkms: fbdev emulation support
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14426df418
start commit: 445a555e0623 Add linux
On Mon, Jan 22, 2024 at 05:30:36PM +0100, Boris Brezillon wrote:
> Anything relating to GEM object management is placed here. Nothing
> particularly interesting here, given the implementation is based on
> drm_gem_shmem_object, which is doing most of the work.
>
> v4:
> - Force kernel BOs to be GP
On Mon, Feb 12, 2024 at 12:18:12PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The new backlight driver unconditionally selects LEDS_EXPRESSWIRE, which
> is in a different subsystem that may be disabled here:
>
> WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
> Depend
On Mon, 12 Feb 2024, Jani Nikula wrote:
> On Mon, 12 Feb 2024, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the drm-misc tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/gpu/drm/tests/drm_mm_test.c: In function 'drm_test_mm_debug':
>> drivers/gpu/d
drmm_connector_init is the preferred function to initialize a
drm_connector structure. Let's add a bunch of unit tests for it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 170 -
1 file changed, 169 insertions(+), 1 deletion(-)
diff -
We're going to need a full-blown, functional, KMS device to test more
components of the atomic modesetting infrastructure.
Let's add a new helper to create a dumb, mocked, primary plane. By
default, it will create a linear XRGB plane, using the default
helpers.
Signed-off-by: Maxime Ripard
-
The mock device we were creating was missing any of the driver-wide
helpers. That was fine before since we weren't testing the atomic state
path, but we're going to start, so let's use the default
implementations.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 3 +++
Hi,
Here's a series that creates some extra infrastructure specifically
targeted at HDMI controllers.
The idea behind this series came from a recent discussion on IRC during
which we discussed infoframes generation of i915 vs everything else.
Infoframes generation code still requires some decent
We're going to need a full-blown, functional, KMS device to test more
components of the atomic modesetting infrastructure.
Let's add a new helper to create a dumb, mocked, CRTC. By default it
will create a CRTC relying only on the default helpers, but drivers are
free to deviate from that.
Signed
We have a few functions declared in our kunit helpers header, some of
them dereferencing the struct drm_driver.
However, we don't include the drm_drv.h header file defining that
structure, leading to compilation errors if we don't include both
headers.
Fixes: d98780310719 ("drm/tests: helpers: Al
The next features we will need to share across drivers will need to
store some parameters for drivers to use, such as the selected output
format.
Let's create a new connector sub-state dedicated to HDMI controllers,
that will eventually store everything we need.
Reviewed-by: Dave Stevenson
Signe
We just introduced a new initialization function for our connectors, so
let's build a kunit test suite for it as well.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 123 +
1 file changed, 123 insertions(+)
A lot of the various HDMI drivers duplicate some logic that depends on
the HDMI spec itself and not really a particular hardware
implementation.
Output BPC or format selection, infoframe generation are good examples
of such areas.
This creates a lot of boilerplate, with a lot of variations, which
This had a bunch of kunit tests to make sure our code to handle the
Broadcast RGB property behaves properly.
This requires bringing a bit of infrastructure to create mock HDMI
connectors, with custom EDIDs.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/Make
The i915 driver has a property to force the RGB range of an HDMI output.
The vc4 driver then implemented the same property with the same
semantics. KWin has support for it, and a PR for mutter is also there to
support it.
Both drivers implementing the same property with the same semantics,
plus th
HDMI controller drivers will need to figure out the RGB range they need
to configure based on a mode and property values. Let's expose that in
the HDMI connector state so drivers can just use that value.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c
The previous commit added the infrastructure to the connector state to
track what RGB Quantization should be used in a given state for an HDMI
connector.
Let's add some kunit tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests
Now that we're tracking the output bpc count in the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 203 +
drivers/gpu/drm/tests/drm_co
We'll add automatic selection of the output BPC in a following patch,
but let's add it to the HDMI connector state already.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 1 +
drivers/gpu/drm/drm_atomic_state_helper.c
Just like BPC, we'll add support for automatic selection of the output
format for HDMI connectors.
Let's add the needed defaults and fields for now.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 2 +
drivers/gpu/drm/drm_atomi
Now that we track the HDMI output format as part of the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 32 +++
drivers/gpu/drm/tests/drm_connector_tes
A lot of HDMI drivers have some variation of the formula to calculate
the TMDS character rate from a mode, but few of them actually take all
parameters into account.
Let's create a helper to provide that rate taking all parameters into
account.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime R
Most HDMI drivers have some code to calculate the TMDS character rate,
usually to adjust an internal clock to match what the mode requires.
Since the TMDS character rates mostly depends on the resolution, whether
we need to repeat pixels or not, the bpc count and the format, we can
now derive it f
The previous patch added an helper to compute the TMDS character rate on
an HDMI connector. Let's add a few tests to make sure it works as
expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 323 +
1 fil
Google Chameleon v3 is a testing device capable of emulating multiple
DisplayPort monitors, used for testing purposes. It is based on an Arria
10 SoCFPGA. This patchset adds V4L2 drivers for two IP blocks used in
the device's FPGA: the Chameleon v3 framebuffer, and the Intel DisplayPort
RX IP. T
Add v4l2 driver for the Google Chameleon v3 framebuffer device.
Signed-off-by: Paweł Anikiel
---
drivers/media/platform/Kconfig| 1 +
drivers/media/platform/Makefile | 1 +
drivers/media/platform/google/Kconfig | 3 +
drivers/media/platform/google/Make
Move structures describing MST sideband messages into a separate header
so that non-DRM code can use them.
Signed-off-by: Paweł Anikiel
---
include/drm/display/drm_dp_mst.h| 238
include/drm/display/drm_dp_mst_helper.h | 232 +--
2 files chang
Currently, .query_dv_timings() is defined as a video callback without
a pad argument. This is a problem if the subdevice can have different
dv timings for each pad (e.g. a DisplayPort receiver with multiple
virtual channels).
To solve this, add a pad variant of this callback which includes
the pad
The CRC functions found in drivers/gpu/drm/display/drm_dp_mst_topology.c
may be useful for other non-DRM code that deals with DisplayPort, e.g.
v4l2 drivers for DP receivers. Move these functions to /lib.
Signed-off-by: Paweł Anikiel
---
drivers/gpu/drm/display/Kconfig | 1 +
driv
The previous patch stores in the connector state the expected TMDS
character rate matching the configuration of the HDMI connector. Let's
add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_tes
The Chameleon v3 uses the framebuffer IP core to take the video signal
from different sources and directly write frames into memory.
Signed-off-by: Paweł Anikiel
---
.../bindings/media/google,chv3-fb.yaml| 77 +++
1 file changed, 77 insertions(+)
create mode 100644 Docum
Each of these registers contains a single value, but not the entire
8 bits:
DP_PAYLOAD_ALLOCATE_SET - Bit 7 Reserved
DP_PAYLOAD_ALLOCATE_START_TIME_SLOT - Bits 7:6 Reserved
DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT - Bits 7:6 Reserved
Add definitions to properly mask off values read from these register
The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP
Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video
capture and Multi-Stream Transport. The user guide can be found here:
https://www.intel.com/programmable/technical-pdfs/683273.pdf
Signed-off-by: Paweł Aniki
The previous patch adds a new hook for HDMI connectors to filter out
configurations based on the TMDS character rate. Let's add some tests to
make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 65
Most of the HDMI controllers have an upper TMDS character rate limit
they can't exceed. On "embedded"-grade display controllers, it will
typically be lower than what high-grade monitors can provide these days,
so drivers will filter the TMDS character rate based on the controller
capabilities.
To
Add driver for the Intel DisplayPort RX FPGA IP
Signed-off-by: Paweł Anikiel
---
drivers/media/platform/intel/Kconfig | 12 +
drivers/media/platform/intel/Makefile |1 +
drivers/media/platform/intel/intel-dprx.c | 2171 +
3 files changed, 2184 insertions(+)
cr
Add device nodes for the video system present on the Chameleon v3.
It consists of six framebuffers and two Intel Displayport receivers.
Signed-off-by: Paweł Anikiel
---
.../socfpga/socfpga_arria10_chameleonv3.dts | 130 ++
1 file changed, 130 insertions(+)
diff --git a/arch/ar
Infoframes in KMS is usually handled by a bunch of low-level helpers
that require quite some boilerplate for drivers. This leads to
discrepancies with how drivers generate them, and which are actually
sent.
Now that we have everything needed to generate them in the HDMI
connector state, we can gen
1 - 100 of 248 matches
Mail list logo
