Hi Linus,
Regular weekly pull, all seems pretty normal, i915 and amdgpu mostly.
There is one small new uAPI addition for nouveau but getting it in now
avoids a bunch of userspace dances, and it's for a userspace that
hasn't yet released, so should have no side effects.
Dave.
Hi Dave and Daniel,
Just one fixup to a potential error pointer dereference.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit 8a749fd1a8720d4619c91c8b6e7528c0a355c0aa:
Linux 6.6-rc4 (2023-10-01 14:15:13 -0700)
are available in
2023년 9월 19일 (화) 오후 7:40, Uwe Kleine-König
님이 작성:
>
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a
Thanks for testing. :)
Acked-by : Inki Dae
2023년 9월 22일 (금) 오후 3:00, Marek Szyprowski 님이 작성:
>
>
> On 21.09.2023 21:26, Douglas Anderson wrote:
> > Based on grepping through the source code this driver appears to be
> > missing a call to drm_atomic_helper_shutdown() at system shutdown time
> >
Hi all,
Today's linux-next merge of the drm-msm-lumag tree got a conflict in:
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
between commit:
8f5d3daad715 ("drm/msm/dpu: Annotate struct dpu_hw_intr with __counted_by")
from the drm-misc tree and commits:
eb7af0e86349 ("drm/msm/dpu:
From: Daniele Ceraolo Spurio
The GuC handles the WA, the KMD just needs to set the flag to enable
it on the appropriate platforms.
Signed-off-by: John Harrison
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 6 ++
On 9/14/2023 3:28 PM, john.c.harri...@intel.com wrote:
From: Daniele Ceraolo Spurio
The GuC handles the WA, the KMD just needs to set the flag to enable
it on the appropriate platforms.
Signed-off-by: John Harrison
Signed-off-by: Daniele Ceraolo Spurio
---
On Wed, Aug 30, 2023 at 07:15:28PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> The PCI code and ID assignment specification defined four types of
> display controllers for the display base class(03h), and the devices
> with 0x00h sub-class code are VGA devices. VGA devices with
On Thu, Sep 7, 2023 at 8:05 PM Dmitry Baryshkov
wrote:
>
> The drm_atomic_print_new_state() already prints private object state via
> drm_atomic_private_obj_print_state(). Add private object state dumping
> to __drm_state_dump(), so that it is also included into drm_state_dump()
> output and into
On 06/09/2023 21:12, Stephen Boyd wrote:
Plugging in an Apple dongle without the HDMI cable attached prints out
an error message in the kernel logs when nothing is actually wrong.
no downstream ports connected
This is because the downstream port for the HDMI connector is not
connected, so
On 06/09/2023 21:12, Stephen Boyd wrote:
This function is basically a one-liner when you ignore the debug
logging. Just inline the function and drop the log to simplify the code.
Suggested-by: Dmitry Baryshkov
Cc: Vinod Polimera
Cc: Kuogee Hsieh
Signed-off-by: Stephen Boyd
---
On Thu, Oct 05, 2023 at 04:57:14PM -0500, Bjorn Helgaas wrote:
> In subject: "drm/virtio" to match previous history.
>
> On Wed, Aug 30, 2023 at 07:15:31PM +0800, Sui Jingfeng wrote:
> > From: Sui Jingfeng
> >
> > Should be no functional change, just for cleanup purpose.
> >
> > Cc: David
The frame event callback is always set to dpu_crtc_frame_event_cb() (or
to NULL) and the data is always either the CRTC itself or NULL
(correpondingly). Thus drop the event callback registration, call the
dpu_crtc_frame_event_cb() directly and gate on the dpu_enc->crtc
assigned using
In subject: "drm/virtio" to match previous history.
On Wed, Aug 30, 2023 at 07:15:31PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> Should be no functional change, just for cleanup purpose.
>
> Cc: David Airlie
> Cc: Gerd Hoffmann
> Cc: Gurchetan Singh
> Cc: Chia-I Wu
> Cc: Daniel
Applied. Thanks!
Alex
On Thu, Oct 5, 2023 at 10:32 AM Christian König
wrote:
>
> Am 04.10.23 um 01:29 schrieb Kees Cook:
> > Prepare for the coming implementation by GCC and Clang of the __counted_by
> > attribute. Flexible array members annotated with __counted_by can have
> > their accesses
The field `id' is not used for subblocks. The handling code usually
knows, which sub-block it is now looking at. Drop the field completely.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 76 +--
After folding QSEED3LITE and QSEED4 feature bits into QSEED3 several
VIG feature masks became equal. Drop these duplicates.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h| 2 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 8
In preparation to deduplicating SSPP subblocks, drop the (unused)
`smart_dma_priority' field from struct dpu_sspp_sub_blks. If it is
needed later (e.g. for SmartDMA v1), it should be added to the SSPP
declarations themselves.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
As the subblock info is now mostly gone, inline and drop the macro
DPU_HW_SUBBLK_INFO.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 40 ++-
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git
Three different features, DPU_SSPP_SCALER_QSEED3, QSEED3LITE and QSEED4
are all related to different versions of the same HW scaling block.
Corresponding driver parts use scaler_blk.version to identify the
correct way to program the hardware. In order to simplify the driver
codepath, merge these
In order to check whether the SSPP block has scaler and CSC subblocks
the funcion dpu_plane_atomic_check_pipe() uses macros which enumerate
all possible scaler and CSC features. Replace those checks with the
scaler and CSC subblock length checks in order to be able to drop those
two macros.
As we have dropped the variadic parts of SSPP sub-blocks declarations,
deduplicate them now, reducing memory cruft.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 16 +--
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 16 +--
From: Marijn Suijten
The SSPP scaler subblk is responsible for reporting its version (via the
.id field, feature bits on the parent SSPP block, and since recently
also from reading a register to supersede a read-but-unset version field
in the catalog), leaving this global qseed_type field
From: Marijn Suijten
This pointer callback is never used and should be removed.
Signed-off-by: Marijn Suijten
Reviewed-by: Dmitry Baryshkov
[DB: dropped the helpers completely, which are unused now]
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
The handling code also usually knows, which sub-block it is now looking
at. Drop unused 'id' field and arguments and merge some of sub-block
declarations.
While we are at it, also fix all VIG subblocks to contain correct scaler
block version and drop the becoming unused QSEED-related feature
The function _dpu_hw_sspp_setup_scaler3() passes and
dpu_hw_setup_scaler3() uses scaler_blk.version to determine in which way
the scaler (QSEED3) block should be programmed. However up to now we
were not setting this field. Set it now, splitting the vig_sblk data
which has different version
Given a reference to "guc", the guc_to_i915() returns the
pointer to "i915" private data.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt.h| 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c| 2
The drm_atomic_helper_check_wb_encoder_state() function doesn't use
encoder for anything other than getting the drm_device instance. The
function's description talks about checking the writeback connector
state, not the encoder state. Moreover, there is no such thing as an
encoder state, encoders
Hi,
On Thu, Oct 5, 2023 at 5:57 AM Daniel Vetter wrote:
> So imo the trouble with this is that we suddenly start to make
> realtime/cpu usage guarantees in the atomic ioctl. That's a _huge_ uapi
> change, because even limited to the case of !ALLOW_MODESET we do best
> effort guarantees at best.
On 05/10/2023 20:49, Duje Mihanović wrote:
> Add driver for the Kinetic KTD2801 backlight driver.
>
> Signed-off-by: Duje Mihanović
> ---
> MAINTAINERS | 6 ++
> drivers/video/backlight/Kconfig | 7 ++
> drivers/video/backlight/Makefile
On 05/10/2023 20:49, Duje Mihanović wrote:
> Add the dt binding for the Kinetic KTD2801 backlight driver.
>
> Signed-off-by: Duje Mihanović
> ---
> .../bindings/leds/backlight/kinetic,ktd2801.yaml | 46
> ++
> 1 file changed, 46 insertions(+)
Reviewed-by: Krzysztof
Add driver for the Kinetic KTD2801 backlight driver.
Signed-off-by: Duje Mihanović
---
MAINTAINERS | 6 ++
drivers/video/backlight/Kconfig | 7 ++
drivers/video/backlight/Makefile| 1 +
drivers/video/backlight/ktd2801-backlight.c |
Hello,
This small series adds a driver for the Kinetic KTD2801 backlight IC.
The driver has been tested on the samsung,coreprimevelte for which
support is still out-of-tree.
Signed-off-by: Duje Mihanović
---
Duje Mihanović (2):
dt-bindings: backlight: add Kinetic KTD2801 binding
On 10/5/23 21:10, Doug Anderson wrote:
Hi,
On Tue, Sep 26, 2023 at 7:01 AM Doug Anderson wrote:
Hi,
On Tue, Sep 26, 2023 at 1:06 AM AngeloGioacchino Del Regno
wrote:
Il 26/09/23 00:00, Douglas Anderson ha scritto:
In commit 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of
Add the dt binding for the Kinetic KTD2801 backlight driver.
Signed-off-by: Duje Mihanović
---
.../bindings/leds/backlight/kinetic,ktd2801.yaml | 46 ++
1 file changed, 46 insertions(+)
diff --git
a/Documentation/devicetree/bindings/leds/backlight/kinetic,ktd2801.yaml
On 2023-10-05 13:20, Arvind Yadav wrote:
Here, Adding db_size in byte to find the doorbell's
absolute offset for both 32-bit and 64-bit doorbell sizes.
So that doorbell offset will be aligned based on the doorbell
size.
v2:
- Addressed the review comment from Felix.
v3:
- Adding doorbell_size
This seems like a very good solution to the problem :)
Reviewed-by: Lyude Paul
On Thu, 2023-10-05 at 13:16 +, Simon Ser wrote:
> The driver might pull connectors which weren't submitted by
> user-space into the atomic state. For instance,
> intel_dp_mst_atomic_master_trans_check() pulls in
On Thu, Oct 5, 2023 at 11:11 AM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Sep 26, 2023 at 7:01 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Sep 26, 2023 at 1:06 AM AngeloGioacchino Del Regno
> > wrote:
> > >
> > > Il 26/09/23 00:00, Douglas Anderson ha scritto:
> > > > In commit
Hi,
On Tue, Sep 26, 2023 at 7:01 AM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Sep 26, 2023 at 1:06 AM AngeloGioacchino Del Regno
> wrote:
> >
> > Il 26/09/23 00:00, Douglas Anderson ha scritto:
> > > In commit 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of
> > > panel-simple") I moved a
On 10/3/23 14:09, Boris Brezillon wrote:
> Unmap tends to refer to a VM related operation (removing a mapping in
> the CPU or GPU VM), so it's confusing too IMHO. What we do here is
> return pages to the shmem file logic, so they can be reclaimed.
>
> Given the drm_gem function doing that is
Here, Adding db_size in byte to find the doorbell's
absolute offset for both 32-bit and 64-bit doorbell sizes.
So that doorbell offset will be aligned based on the doorbell
size.
v2:
- Addressed the review comment from Felix.
v3:
- Adding doorbell_size as parameter to get db absolute offset.
v4:
On older chips, the absolute doorbell offset within
the doorbell page is based on the queue ID.
KFD is using queue ID and doorbell size to get an
absolute doorbell offset in userspace.
Here, adding db_size in byte to find the doorbell's
absolute offset for both 32-bit and 64-bit doorbell sizes.
Quoting Doug Anderson (2023-10-02 17:31:41)
> Hi,
>
> On Mon, Oct 2, 2023 at 4:54 PM Stephen Boyd wrote:
> >
> > The kernel produces a warning splat and the DSI device fails to register
> > in this driver if the i2c driver probes, populates child auxiliary
> > devices, and then somewhere in
From: Joshua Ashton
Create drm_color_ctm_3x4 to support 3x4-dimension plane CTM matrix and
convert DRM CTM to DC CSC float matrix.
v3:
- rename ctm2 to ctm_3x4 (Harry)
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 28
From: Joshua Ashton
When commiting planes, we copy color mgmt resources to the stream state.
Do the same for shaper and 3D LUTs.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
Plane CTM for pre-blending color space conversion. Only enable
driver-specific plane CTM property on drivers that support both pre- and
post-blending gamut remap matrix, i.e., DCN3+ family. Otherwise it
conflits with DRM CRTC CTM property.
Reviewed-by: Harry Wentland
Signed-off-by: Melissa Wen
Map the plane CTM driver-specific property to DC plane, instead of DC
stream. The remaining steps to program DPP block are already implemented
on DC shared-code.
v3:
- fix comment about plane and CRTC CTMs priorities (Harry)
Reviewed-by: Harry Wentland
Signed-off-by: Melissa Wen
---
From: Joshua Ashton
Unlike degamma, blend gamma doesn't support hardcoded curve
(predefined/ROM), but we can use AMD color module to fill blend gamma
parameters when we have non-linear plane gamma TF without plane gamma
LUT. The regular degamma path doesn't hit this.
Reviewed-by: Harry Wentland
From: Joshua Ashton
Map plane blend properties to DPP blend gamma. Plane blend is a
post-3D LUT curve that linearizes color space for blending. It may be
defined by a user-blob LUT and/or predefined transfer function. As
hardcoded curve (ROM) is not supported on blend gamma, we use AMD color
From: Joshua Ashton
Need to funnel the color caps through to these functions so it can check
that the hardware is capable.
v2:
- remove redundant color caps assignment on plane degamma map (Harry)
- pass color caps to degamma params
v3:
- remove unused color_caps parameter from
Wire up DC 3D LUT to DM plane color management (pre-blending). On AMD
display HW, 3D LUT comes after a shaper curve and we always have to
program a shaper curve to delinearize or normalize the color space
before applying a 3D LUT (since we have a reduced number of LUT
entries).
In this version,
Enable usage of predefined transfer func in addition to shaper 1D LUT.
That means we can save some complexity by just setting a predefined
curve, instead of programming a custom curve when preparing color space
for applying 3D LUT.
Reviewed-by: Harry Wentland
Signed-off-by: Melissa Wen
---
DC only has pre-blending degamma caps (plane/DPP) that is currently in
use for CRTC/post-blending degamma, so that we don't have HW caps to
perform plane and CRTC degamma at the same time. Reject atomic updates
when serspace sets both plane and CRTC degamma properties.
Reviewed-by: Harry Wentland
From: Joshua Ashton
With `dc_fixpt_from_s3132()` translation, we can just use it to set
hdr_mult.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
From: Joshua Ashton
Detach value translation from CTM to reuse it for programming HDR
multiplier property.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 8 +---
Map DC shaper LUT to DM plane color management. Shaper LUT can be used
to delinearize and/or normalize the color space for computational
efficiency and achiving specific visual styles. If a plane degamma is
apply to linearize the color space, a custom shaper 1D LUT can be used
just before applying
From: Joshua Ashton
Set DC plane with user degamma LUT or predefined TF from driver-specific
plane color properties. If plane and CRTC degamma are set in the same
time, plane degamma has priority. That means, we only set CRTC degamma
if we don't have plane degamma LUT or TF to configure. We
Add AMD pre-defined transfer function property to default DRM CRTC gamma
to convert to wire encoding with or without a user gamma LUT. There is
no post-blending regamma ROM for pre-defined TF. When setting Gamma TF
(!= Identity) and LUT at the same time, the color module will combine
the
The next patch adds pre-blending degamma to AMD color mgmt pipeline, but
pre-blending degamma caps (DPP) is currently in use to provide DRM CRTC
atomic degamma or implict degamma on legacy gamma. Detach degamma usage
regarging CRTC color properties to manage plane and CRTC color
correction
From: Joshua Ashton
We should reset a plane state if at least one of the color management
properties differs from old and new state.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
From: Joshua Ashton
Otherwise this is just initialized to 0. This needs to actually have a
value so that compute_curve can work for PQ EOTF.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
From: Joshua Ashton
Add predefined transfer function programming. There is no post-blending
out gamma ROM for hardcoded curves, but we can use AMD color modules to
program LUT parameters from pre-defined coefficients and an empty
regamma LUT (or bump up LUT parameters with pre-defined TF
We will wire up MPC 3D LUT to DM CRTC color pipeline in the next patch,
but so far, only for atomic interface. By checking
set_output_transfer_func in DC drivers with MPC 3D LUT support, we can
verify that regamma is only programmed when 3D LUT programming fails. As
a groundwork to introduce 3D
Describe some expected behavior of the AMD DM color mgmt programming.
Reviewed-by: Harry Wentland
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git
Brief documentation about pre-defined transfer function usage on AMD
display driver and standardized EOTFs and inverse EOTFs.
v3:
- Document BT709 OETF (Pekka)
- Fix description of sRGB and pure power funcs (Pekka)
v4:
- Add description of linear and non-linear forms (Harry)
Co-developed-by:
On AMD HW, 3D LUT always assumes a preceding shaper 1D LUT used for
delinearizing and/or normalizing the color space before applying a 3D
LUT. Add pre-defined transfer function to enable delinearizing content
with or without shaper LUT, where AMD color module calculates the
resulted shaper curve.
From: Joshua Ashton
Blend 1D LUT or a pre-defined transfer function (TF) can be set to
linearize content before blending, so that it's positioned just before
blending planes in the AMD color mgmt pipeline, and after 3D LUT
(non-linear space). Shaper and Blend LUTs are 1D LUTs that sandwich 3D
From: Joshua Ashton
Multiplier to 'gain' the plane. When PQ is decoded using the fixed func
transfer function to the internal FP16 fb, 1.0 -> 80 nits (on AMD at
least) When sRGB is decoded, 1.0 -> 1.0. Therefore, 1.0 multiplier = 80
nits for SDR content. So if you want, 203 nits for SDR
Instead of relying on color block names to get the transfer function
intention regarding encoding pixel's luminance, define supported
Electro-Optical Transfer Functions (EOTFs) and inverse EOTFs, that
includes pure gamma or standardized transfer functions.
v3:
- squash linear and unity TFs to
Add 3D LUT property for plane color transformations using a 3D lookup
table. 3D LUT allows for highly accurate and complex color
transformations and is suitable to adjust the balance between color
channels. It's also more complex to manage and require more
computational resources.
Since a 3D LUT
From: Joshua Ashton
Allow userspace to tell the kernel driver the input space and,
therefore, uses correct predefined transfer function (TF) to go from
encoded values to linear values.
v2:
- rename TF enum prefix from DRM_ to AMDGPU_ (Harry)
- remove HLG TF
Reviewed-by: Harry Wentland
We will add color mgmt properties to DRM planes in the next patches and
we want to track when one of this properties change to define atomic
commit behaviors. Using a similar approach from CRTC color props, we set
a color_mgmt_changed boolean whenever a plane color prop changes.
Reviewed-by:
Place it in drm_property where drm_property_replace_blob and
drm_property_lookup_blob live. Then we can use the DRM helper for
driver-specific KMS properties too.
Reviewed-by: Harry Wentland
Reviewed-by: Liviu Dudau
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/arm/malidp_crtc.c | 2 +-
Hook up driver-specific atomic operations for managing AMD color
properties. Create AMD driver-specific color management properties
and attach them according to HW capabilities defined by `struct
dc_color_caps`.
First add plane degamma LUT properties that means user-blob and its
size. We will add
DRM_OBJECT_MAX_PROPERTY limits the number of properties to be attached
and we are increasing that value all time we add a new property (generic
or driver-specific).
In this series, we are adding 13 new KMS driver-specific properties for
AMD color manage:
- CRTC Gamma enumerated Transfer Function
Hello,
Just another iteration for AMD driver-specific color properties.
Basically, addressing comments from the previous version.
Recap: this series extends the current KMS color management API with AMD
driver-specific properties to enhance the color management support on
AMD Steam Deck. The key
On Thu, Oct 5, 2023 at 4:04 AM Wayne Lin wrote:
>
> [Why]
> Unplug mst hub will cause warning. That's because
> dm_helpers_construct_old_payload() is changed to be called after
> payload removement from dc link.
>
> In dm_helpers_construct_old_payload(), We refer to the vcpi in
> payload
On Thu, Oct 05, 2023 at 11:42:38AM +0200, Christian König wrote:
> Am 02.10.23 um 20:22 schrieb Kees Cook:
> > On Mon, Oct 02, 2023 at 08:11:41PM +0200, Christian König wrote:
> > > Am 02.10.23 um 20:08 schrieb Kees Cook:
> > > > On Mon, Oct 02, 2023 at 08:01:57PM +0200, Christian König wrote:
> >
Hi,
On Tue, 03 Oct 2023 11:33:53 -0500, Chris Morgan wrote:
> From: Chris Morgan
>
> Add support for the Anbernic RG351V panel. This panel is mostly
> identical to the one used in the 353 series, except it has a different
> panel ID when queried (0x4000 for the 351V, 0x3052 for the 353 panel)
>
Thomas Zimmermann writes:
> Hi
>
[...]
>>
>> I'm confused, the copy helper is the same than init. What's the point of
>> this function ? Why not just call drm_format_conv_state_init() from the
>> __drm_gem_duplicate_shadow_plane_state() function in the next patch ?
>
> I guess that deserves a
On Thu, Oct 05, 2023 at 12:13:01AM -0400, Luben Tuikov wrote:
> On 2023-10-04 23:33, Matthew Brost wrote:
> > On Tue, Sep 26, 2023 at 11:32:10PM -0400, Luben Tuikov wrote:
> >> Hi,
> >>
> >> On 2023-09-19 01:01, Matthew Brost wrote:
> >>> In XE, the new Intel GPU driver, a choice has made to have
On 05/10/2023 15:12, Adrián Larumbe wrote:
> Fix issues revealed by `make htmldocs` after adding Panfrost DRM
> documentation file.
>
> Signed-off-by: Adrián Larumbe
> Fixes: d124dac2089c ("drm/panfrost: Add fdinfo support GPU load metrics")
> Reported-by: kernel test robot
> Closes:
>
Hi
Am 05.10.23 um 15:18 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Hello Thomas,
Hold temporary memory for format conversion in an instance of struct
drm_format_conv_state. Update internal helpers of DRM's format-conversion
code accordingly. Drivers will later be able to
On Tue, 03 Oct 2023, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_drv.h
>
> between commits:
>
> c9517783060a ("drm/i915/dg2: Drop Wa_16011777198")
> 5a213086a025 ("drm/i915: Eliminate
On Wed, 04 Oct 2023, Ville Syrjälä wrote:
> On Wed, Oct 04, 2023 at 07:21:49PM +0300, Jani Nikula wrote:
>> Prefer struct drm_edid where possible. With limited users for the
>> drm_dp_downstream_*() helpers, this is fairly straightforward.
>>
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville
Am 04.10.23 um 01:29 schrieb Kees Cook:
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for
array indexing) and
Hi Dave and Daniel,
Here goes drm-intel-fixes-2023-10-05:
- Fix for OpenGL CTS regression on Compute Shaders (Nirmoy)
- Fix for default engines initialization (Mathias)
- Fix TLB invalidation for Multi-GT devices (Chris)
Thanks,
Rodrigo.
The following changes since commit
Fix issues revealed by `make htmldocs` after adding Panfrost DRM
documentation file.
Signed-off-by: Adrián Larumbe
Fixes: d124dac2089c ("drm/panfrost: Add fdinfo support GPU load metrics")
Reported-by: kernel test robot
Closes:
If the shared memory object is larger than the DRM object that it backs,
we can overrun the page array. Limit the number of pages we install
from each folio to prevent this.
Signed-off-by: Matthew Wilcox (Oracle)
Reported-by: Oleksandr Natalenko
Tested-by: Oleksandr Natalenko
Link:
Thomas Zimmermann writes:
Hello Thomas,
> Preallocate the format-conversion state's storage in the plane's
> atomic_check function if a format conversion is necessary. Allows
> the update to fail if no memory is available. Avoids the same
> allocation within atomic_update, which may not fail.
>
Thomas Zimmermann writes:
> Preallocate the format-conversion state's storage in the plane's
> atomic_check function if a format conversion is necessary. Allows
> the update to fail if no memory is available. Avoids the same
> allocation within atomic_update, which may not fail.
>
>
wt., 26 wrz 2023 o 16:01 Radosław Biernacki napisał(a):
>
> On Fri, Sep 22, 2023 at 8:34 AM Lukasz Majczak wrote:
> >
> > As drm_dp_get_mst_branch_device_by_guid() is called from
> > drm_dp_get_mst_branch_device_by_guid(), mstb parameter has to be checked,
> > otherwise NULL dereference may
On čtvrtek 5. října 2023 15:05:27 CEST Matthew Wilcox wrote:
> On Thu, Oct 05, 2023 at 02:30:55PM +0200, Oleksandr Natalenko wrote:
> > No-no, sorry for possible confusion. Let me explain again:
> >
> > 1. we had an issue with i915, which was introduced by 0b62af28f249, and
> > later was fixed
On 10/5/23 12:44, Christian König wrote:
Am 05.10.23 um 10:36 schrieb Thomas Hellström:
On Wed, 2023-10-04 at 14:44 +0200, Christian König wrote:
Am 04.10.23 um 09:17 schrieb Thomas Hellström:
On Wed, 2023-10-04 at 03:52 +, Zeng, Oak wrote:
Hi Christian,
As a follow up to this
Thomas Zimmermann writes:
> Pass an instance of struct drm_format_conv_state to DRM's format
> conversion helpers. Update all callers.
>
> Most drivers can use the format-conversion state from their shadow-
> plane state. The shadow plane's destroy function releases the
> allocated buffer.
Thomas Zimmermann writes:
> Store an instance of struct drm_format_conv_state in the shadow-plane
> state struct drm_shadow_plane_state. Many drivers with shadow planes
> use DRM's format helpers to copy or convert the framebuffer data to
> backing storage in the scanout buffer. The shadow plane
Thomas Zimmermann writes:
Hello Thomas,
> Hold temporary memory for format conversion in an instance of struct
> drm_format_conv_state. Update internal helpers of DRM's format-conversion
> code accordingly. Drivers will later be able to maintain this cache by
> themselves.
>
> Besides caching,
The driver might pull connectors which weren't submitted by
user-space into the atomic state. For instance,
intel_dp_mst_atomic_master_trans_check() pulls in connectors
sharing the same DP-MST stream. However, if the connector is
unregistered, this later fails with:
[ 559.425658] i915
On Thu, Oct 05, 2023 at 02:30:55PM +0200, Oleksandr Natalenko wrote:
> No-no, sorry for possible confusion. Let me explain again:
>
> 1. we had an issue with i915, which was introduced by 0b62af28f249, and later
> was fixed by 863a8eb3f270
> 2. now I've discovered another issue, which looks very
Javier Martinez Canillas writes:
> Thomas Zimmermann writes:
>
> Hello Thomas,
>
[...]
>>
>> You have a atomic_disable in that plane, so you're taking the branch at
>> [2] for disabling the plane. No atomic_update then. If the plane has
>> been enabled, you should take the branch at [3].
1 - 100 of 153 matches
Mail list logo
