On Mon, Feb 12, 2024 at 11:10:15AM +0200, Pekka Paalanen 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
On 12/02/2024 16:49, Ville Syrjälä wrote:
> On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote:
>> 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
On 2/10/2024 23:50, Mario Limonciello wrote:
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops. Drivers that prefer to
fetch this EDID can set a bit on the drm_connector to indicate that
the DRM EDID helpers should try to fetch it and
The driver sets struct fb_info.bl_dev to the correct backlight
device. Thus rely on the backlight core code to match backlight
and framebuffer devices, and remove the extra check_fb function
from struct backlight_ops.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/sh_mobile_lcdcfb.c |
The driver sets struct fb_info.bl_dev to the correct backlight
device. Thus rely on the backlight core code to match backlight
and framebuffer devices, and remove the extra check_fb function
from struct backlight_ops.
Signed-off-by: Thomas Zimmermann
Cc: Robin van der Gracht
---
Replace check_fb with controls_device in struct backlight_ops. The
new callback interface takes a Linux device instead of a framebuffer.
Resolves one of the dependencies of backlight.h on fb.h.
The few drivers that had custom implementations of check_fb can easily
use the framebuffer's Linux
The driver sets struct fb_info.bl_dev to the correct backlight
device. Thus rely on the backlight core code to match backlight
and framebuffer devices, and remove the extra check_fb function
from struct backlight_ops.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/ssd1307fb.c | 7
For drivers that support backlight, LCD and fbdev devices, fbdev has
to be initialized last. See documentation for struct fbinfo.bl_dev.
The backlight name's index number comes from register_framebuffer(),
which now happens after initializing the backlight device. So like
in all other backlight
Backlight drivers implement struct backlight_ops.check_fb, which
uses struct fb_info in its interface. Replace the callback with one
the does not use fb_info.
In DRM, we have several drivers that implement backlight support. By
including these drivers depend on .
At the same time, fbdev is
The internal check_fb callback from struct pwm_bl_data is never
implemented. thus the driver's implementation of check_fb always
returns true, which is the backlight core's default if no
implementation has been set. So remove the code from the driver.
Signed-off-by: Thomas Zimmermann
Cc: "Uwe
The driver's implementation of check_fb always returns true, which
is the default if no implementation has been set. So remove the code
from the driver.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/aat2870_bl.c | 7 ---
1 file changed, 7 deletions(-)
diff --git
The driver sets struct fb_info.bl_dev to the correct backlight
device. Thus rely on the backlight core code to match backlight
and framebuffer devices, and remove the extra check_fb function
from struct backlight_ops.
Signed-off-by: Thomas Zimmermann
Cc: "Bruno Prémont"
---
For drivers that support backlight, LCD and fbdev devices, fbdev has
to be initialized last. See documentation for struct fbinfo.bl_dev.
Signed-off-by: Thomas Zimmermann
Cc: "Bruno Prémont"
---
drivers/hid/hid-picolcd_core.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Framebuffer drivers for devices with dedicated backlight are supposed
to set struct fb_info.bl_dev to the backlight's respective device. Use
the value to match backlight and framebuffer in the backlight core code.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/backlight.c | 9
On Mon, Feb 12, 2024 at 3:35 PM Rob Herring wrote:
>
>
> On Mon, 12 Feb 2024 13:13:22 +, Paweł Anikiel wrote:
> > 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
On Mon, Feb 12, 2024 at 3:35 PM Rob Herring wrote:
>
>
> On Mon, 12 Feb 2024 13:13:21 +, Paweł Anikiel wrote:
> > 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
> >
On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote:
> 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
On Mon, Feb 12, 2024 at 05:25:43PM +0200, Jani Nikula wrote:
> On Fri, 02 Feb 2024, Ville Syrjälä wrote:
> > On Fri, Feb 02, 2024 at 04:05:32PM +0200, Jani Nikula wrote:
> >> Currently we've split MST capability detection in two places,
> >> intel_dp_can_mst() and intel_dp_configure_mst(). They
On Mon, Feb 12, 2024 at 05:30:40PM +0200, Jani Nikula wrote:
> On Fri, 02 Feb 2024, Ville Syrjälä wrote:
> > On Fri, Feb 02, 2024 at 04:05:34PM +0200, Jani Nikula wrote:
> >> If the sink supports 128b/132b and single-stream sideband messaging,
> >> enable MST mode.
> >>
> >> With this, the
On Mon, 22 Jan 2024 19:06:55 +0100, Uwe Kleine-König wrote:
> this is v2 of this patch set.
>
> Changes since (implicit) v1, sent with Message-Id:
> cover.1705348269.git.u.kleine-koe...@pengutronix.de:
>
> - Rebase to v6.8-rc1
> - Fix a build failure on sh
> - Added the tags received in
On Fri, 02 Feb 2024, Ville Syrjälä wrote:
> On Fri, Feb 02, 2024 at 04:05:34PM +0200, Jani Nikula wrote:
>> If the sink supports 128b/132b and single-stream sideband messaging,
>> enable MST mode.
>>
>> With this, the topology manager will still write DP_MSTM_CTRL, which
>> should be ignored by
On Fri, 02 Feb 2024, Ville Syrjälä wrote:
> On Fri, Feb 02, 2024 at 04:05:32PM +0200, Jani Nikula wrote:
>> Currently we've split MST capability detection in two places,
>> intel_dp_can_mst() and intel_dp_configure_mst(). They check essentially
>> the same things.
>>
>> Move bulk of the work,
On 2/12/24 12:22, Arnd Bergmann wrote:
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:
On Tue, Jan 30 2024 at 11:58, Byungchul Park wrote:
> On Fri, Jan 26, 2024 at 06:30:02PM +0100, Thomas Gleixner wrote:
>> On Wed, Jan 24 2024 at 20:59, Byungchul Park wrote:
>>
>> Why is lockdep in the subsystem prefix here? You are changing the CPU
>> hotplug (not hotplus) code, right?
>>
>> >
On 12/02/2024 11:46, Konrad Dybcio wrote:
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
On Mon, 12 Feb 2024 13:13:22 +, Paweł Anikiel wrote:
> 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:
>
>
On Mon, 12 Feb 2024 13:13:21 +, Paweł Anikiel wrote:
> 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
On Monday, February 12, 2024 1:44:28 PM CET Daniel Thompson wrote:
> 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:
On Sat, Feb 10, 2024 at 10:49:50PM -0800, Randy Dunlap wrote:
>
>
> On 2/8/24 07:20, Kousik Sanagavarapu wrote:
> > On Thu, Jan 25, 2024 at 12:05:56AM +0530, Kousik Sanagavarapu wrote:
> >> The comments explaining the function "drm_dp_mst_atom_check_mgr()" had
> >> uneven indentation which made
On 12/02/2024 11:50, Konrad Dybcio wrote:
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
On Mon, Feb 12, 2024 at 12:30:12PM +0100, Krzysztof Kozlowski wrote:
> 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
Hi,
On 12/02/2024 14:32, Dmitry Baryshkov wrote:
On Mon, 12 Feb 2024 at 12:37, Neil Armstrong wrote:
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
On Mon, 12 Feb 2024 at 12:37, Neil Armstrong wrote:
>
> 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
On 2024-02-11 at 16:42:43 +0100, Frank Oltmanns wrote:
> On 2024-02-08 at 20:05:08 +0100, Maxime Ripard wrote:
>> [[PGP Signed Part:Undecided]]
>> Hi Frank,
>>
>> On Mon, Feb 05, 2024 at 04:22:28PM +0100, Frank Oltmanns wrote:
>>> This panel is used in the pinephone that runs on a Allwinner
On Tue, 06 Feb 2024, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (i386 defconfig)
> failed like this:
>
> In function 'i915_ttm_placement_from_obj',
> inlined from 'i915_ttm_get_pages' at
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c:847:2:
>
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 80 ++
1 file changed, 51 insertions(+), 29 deletions(-)
We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 38 +-
1 file changed, 14 insertions(+), 24 deletions(-)
diff
atomic_check and mode_valid do not check for the same things which can
lead to surprising result if the userspace commits a mode that didn't go
through mode_valid. Let's merge the two implementations into a function
called by both.
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
container_of_const() allows to preserve the pointer constness and is
thus more flexible than inline functions.
Let's switch all our instances of container_of() to container_of_const().
Reviewed-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 16
The sun4i_hdmi driver still uses the non-atomic variants of the encoder
hooks, so let's convert to their atomic equivalents.
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
The new HDMI connector infrastructure allows us to remove a lot of
boilerplate, so let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 638 +
drivers/gpu/drm/vc4/vc4_hdmi.h | 44 +--
Now that we have all the infrastructure needed, we can add some code
that will, for a given connector state and mode, compute the best output
format and bpc.
The algorithm is equivalent to the one already found in i915 and vc4.
Signed-off-by: Maxime Ripard
---
Now that we have a plane create helper for kunit mocked drivers, let's
convert to it in vc4.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 34 +++---
1 file changed, 8 insertions(+), 26 deletions(-)
diff --git
The vc4_dummy_plane structure is an exact equivalent to vc4_plane, so we
don't need it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_mock.c | 6 ++
drivers/gpu/drm/vc4/tests/vc4_mock.h | 9 ++---
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 14
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 123 ---
1 file changed, 42 insertions(+), 81 deletions(-)
The previous patch added the generation of the infoframes matching an
HDMI connector state. Let's add a few tests to make sure it works as
expected.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 219 +
1 file changed, 219 insertions(+)
There has been some discussions recently about the infoframes sent by
drivers and if they were properly generated.
In parallel, there's been some interest in creating an infoframe-decode
tool similar to edid-decode.
Both would be much easier if we were to expose the infoframes programmed
in the
The previous patch added the bpc and format an HDMI connector needs to
be set up with for a given connector state.
Let's add a few tests to make sure it works as expected.
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 504 +
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
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
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(+)
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
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
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ł
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
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
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 +
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
---
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
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
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.
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 +
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
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
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
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 +++
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 +
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
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 +
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
---
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
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
---
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
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,
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(+)
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
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:
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.
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
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
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
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
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':
>>
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
>
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
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
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
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
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 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,
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
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'
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]:
-
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:
>
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:
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
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 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
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
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
101 - 200 of 248 matches
Mail list logo
