On 19/01/2023 01:38, Jessica Zhang wrote:
Add a !drm_atomic_crtc_needs_modeset() check to
_dpu_crtc_setup_cp_blocks() so that CTM is reapplied if the LM/DSPP
blocks were reallocated during modeset or after a suspend/resume.
Changes in V2:
- Fixed commit message
Changes in V3:
- Added mention
Konstantin?
On Thu, 15 Sep 2022, Jani Nikula wrote:
> Hey all, I'd be interested in having the pr-tracker-bot [1] set up for
> the drm subsystem, following the dri-devel mailing list [2] and
> notifying when the pull requests have been merged to either the drm-next
> or drm-fixes branches of
Enable SDP error detection configuration, this will set CRC16 in
128b/132b link layer.
For Display version 13 a hardware bit31 in register VIDEO_DIP_CTL is
added to enable/disable SDP CRC applicable for DP2.0 only, but the
default value of this bit will enable CRC16 in 128b/132b hence
skipping
*** BLURB HERE ***
Arun R Murthy (2):
drm: Add SDP Error Detection Configuration Register
i915/display/dp: SDP CRC16 for 128b132b link layer
.../gpu/drm/i915/display/intel_dp_link_training.c| 12
include/drm/display/drm_dp.h | 3 +++
2 files
DP2.0 E11 defines a new register to facilitate SDP error detection by a
128B/132B capable DPRX device.
v2: Update the macro name to reflect the DP spec(Harry)
Signed-off-by: Arun R Murthy
Reviewed-by: Harry Wentland
---
include/drm/display/drm_dp.h | 3 +++
1 file changed, 3 insertions(+)
I no longer have access to the HiKey boards, so while I'm happy to
review code, I wanted to add Sumit and Yongqin to the reviewers list
so they would get CC'ed on future changes and would be able to have
a chance to validate and provide Tested-by: tags
Cc: Xinliang Liu
Cc: Tian Tao
Cc: Yongqin
On Thu, Jan 19, 2023 at 11:01 AM Sean Anderson wrote:
>
> Make various small changes to allow compile-testing on other arches.
> This is helpful to allow testing changes to 32-bit arm drivers in the
> same build.
>
> The primary changes is to use macros for 64-bit divisions and shifts,
> but we
Enable SDP error detection configuration, this will set CRC16 in
128b/132b link layer.
For Display version 13 a hardware bit31 in register VIDEO_DIP_CTL is
added to enable/disable SDP CRC applicable for DP2.0 only, but the
default value of this bit will enable CRC16 in 128b/132b hence
skipping
DP2.0 E11 defines a new register to facilitate SDP error detection by a
128B/132B capable DPRX device.
v2: Update the macro name to reflect the DP spec(Harry)
Signed-off-by: Arun R Murthy
Reviewed-by: Harry Wentland
---
include/drm/display/drm_dp.h | 3 +++
1 file changed, 3 insertions(+)
On Fri, 20 Jan 2023 at 00:54, Abhinav Kumar wrote:
>
>
>
> On 1/17/2023 5:04 PM, Dmitry Baryshkov wrote:
> > To simplify adding new platforms and to make settings more obvious,
> > rewrite the UBWC setup to use the data structure to pass platform config
> > rather than just calling the functions
Hi Tomi,
Thank you for taking a look at the patches!
On 17-Jan-23 18:08, Tomi Valkeinen wrote:
On 09/01/2023 18:21, Aradhya Bhatia wrote:
Hi Angelo,
Thanks for taking a look at the patches!
On 03-Jan-23 17:21, AngeloGioacchino Del Regno wrote:
Il 03/01/23 07:46, Aradhya Bhatia ha scritto:
This patch adds support to iterate over compressed output bpp as per the
fractional step, supported by DP sink.
v2:
-Avoid ending up with compressed bpp, same as pipe bpp. (Stan)
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 47 +++--
1 file
Add helper to get the DSC bits_per_pixel precision for the DP sink.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/display/drm_dp_helper.c | 27 +
include/drm/display/drm_dp_helper.h | 1 +
2 files changed, 28 insertions(+)
diff --git
From: Vandita Kulkarni
Consider the fractional bpp while reading the qp values.
Signed-off-by: Vandita Kulkarni
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_qp_tables.c | 3 ---
drivers/gpu/drm/i915/display/intel_vdsc.c | 12 +---
2 files changed, 9
From: Swati Sharma
DSC_Sink_BPP_Precision entry is added to i915_dsc_fec_support_show
to depict sink's precision.
Also, new debugfs entry is created to enforce fractional bpp.
If Force_DSC_Fractional_BPP_en is set then while iterating over
output bpp with fractional step size we will continue if
From: Swati Sharma
If force_dsc_fractional_bpp_en is set through debugfs allow DSC iff
compressed bpp is fractional. Continue if we computed compressed bpp is
computed as integer.
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_dp.c | 6 ++
1 file changed, 6
DP DSC Receiver Capabilities are exposed via DPCD 60h-6Fh.
Fix the DSC RECEIVER CAP SIZE accordingly.
Fixes: ffddc4363c28 ("drm/dp: Add DP DSC DPCD receiver capability size define
and missing SHIFT")
Cc: Anusha Srivatsa
Cc: Manasi Navare
Cc: # v5.0+
Reported-by: kernel test robot
MTL+ supports fractional compressed bits_per_pixel, with precision of
1/16. This compressed bpp is stored in U6.4 format.
Accommodate this precision while computing m_n values.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +-
MTL+ supports fractional compressed bits_per_pixel, with precision of
1/16. This compressed bpp is stored in U6.4 format.
Accommodate the precision during calculation of transfer unit data
for hblank_early calculation.
v2:
-Fixed tu_data calculation while dealing with U6.4 format. (Stan)
Currently the required dsc output bpp is set to be the largest
compressed bpp supported for max, lane, rate, and bpp.
The helper intel_dp_dsc_get_output_bpp gets the maximum supported
compressed bpp taking into account link configuration, input bpp,
bigjoiner considerations etc.
Similarly, the
Currently, we take the max lane, rate and pipe bpp, to get the maximum
compressed bpp possible. We then set the output bpp to this value.
This patch provides support to have max bpp, min rate and min lanes,
that can support the min compressed bpp.
v2:
-Avoid ending up with compressed bpp, same as
Add a check to use force DSC bpc only if it, along with the
corresponding bpp are within allowed limits.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
DSC parameter bits_per_pixel is stored in U6.4 format.
The 4 bits represent the fractional part of the bpp.
Currently we use compressed_bpp member of dsc structure to store
only the integral part of the bits_per_pixel.
To store the full bits_per_pixel along with the fractional part,
compressed_bpp
To make way for fractional bpp support, avoid left shifting the
output_bpp by 4 in helper intel_dp_dsc_get_output_bpp.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 10 +++---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
2 files changed, 4
For DSC the min BPC is 8 for ICL+ and so the min pipe_bpp is 24.
Check this condition for cases only where pipe_bpp is to be computed.
For MST case the pipe_bpp is already computed (hardcoded to be 24),
and this check is not required.
Signed-off-by: Ankit Nautiyal
---
DSC compressed bpp and slice counts are already getting printed at the
end of dsc compute config. Remove extra logs.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
For MST the bpc is hardcoded to 8, and pipe bpp to 24.
So avoid forcing DSC bpc for MST case.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 11 +--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 8
2 files changed, 13 insertions(+), 6
This patch series adds support for DSC fractional compressed bpp
for MTL+. The series starts with some fixes, followed by patches that
lay groundwork to iterate over valid compressed bpps to select the
'best' compressed bpp with optimal link configuration (taken from
upstream series:
On 2023-01-19 11:56, Krylov Michael wrote:
> On Thu, 15 Dec 2022 07:07:33 -0500
> Luben Tuikov wrote:
>
>> On 2022-12-15 06:53, Robin Murphy wrote:
>>> On 2022-12-15 11:40, Luben Tuikov wrote:
On 2022-12-15 06:27, Christian König wrote:
> Am 15.12.22 um 11:19 schrieb Luben Tuikov:
On Thu, Jan 19, 2023 at 11:25:51PM +0100, Danilo Krummrich wrote:
> On 1/19/23 22:47, Matthew Brost wrote:
> > On Thu, Jan 19, 2023 at 06:46:30PM +0100, Danilo Krummrich wrote:
> > >
> > >
> > > On 1/19/23 17:38, Matthew Brost wrote:
> > > > On Thu, Jan 19, 2023 at 04:36:43PM +0100, Danilo
: 0b45ac1170ea6416bc1d36798414c04870cd356d
patch link:
https://lore.kernel.org/r/20230118061256.2689-12-dakr%40redhat.com
patch subject: [PATCH drm-next 11/14] drm/nouveau: nvkm/vmm: implement raw ops
to manage uvmm
config: arc-randconfig-s051-20230119
(https://download.01.org/0day-ci/archive/20230120/202301201115
On Thu, Jan 19, 2023 at 07:07:59PM -0800, Boqun Feng wrote:
> On Thu, Jan 19, 2023 at 06:23:49PM -0800, Boqun Feng wrote:
> > On Fri, Jan 20, 2023 at 10:51:45AM +0900, Byungchul Park wrote:
> > > Boqun wrote:
> > > > On Thu, Jan 19, 2023 at 01:33:58PM +, Matthew Wilcox wrote:
> > > > > On Thu,
On Thu, Jan 19, 2023 at 06:23:49PM -0800, Boqun Feng wrote:
> On Fri, Jan 20, 2023 at 10:51:45AM +0900, Byungchul Park wrote:
> > Boqun wrote:
> > > On Thu, Jan 19, 2023 at 01:33:58PM +, Matthew Wilcox wrote:
> > > > On Thu, Jan 19, 2023 at 03:23:08PM +0900, Byungchul Park wrote:
> > > > >
Hi Linus,
Just a pretty regular week for this stage of things, amdgpu and i915,
along with some msm and misc others.
Dave.
drm-fixes-2023-01-20:
drm fixes for 6.2-rc5
fb-helper:
- switcheroo fix
msm:
- kexec shutdown fix
- fix potential double free
i915:
- Reject display plane with height ==
On 2023.01.19 17:05:56 -0500, Rodrigo Vivi wrote:
>
> It still doesn't apply in drm-intel-next.
> Could you please take it through your branch?
>
sure, I'll pick it.
signature.asc
Description: PGP signature
On Fri, Jan 20, 2023 at 10:51:45AM +0900, Byungchul Park wrote:
> Boqun wrote:
> > On Thu, Jan 19, 2023 at 01:33:58PM +, Matthew Wilcox wrote:
> > > On Thu, Jan 19, 2023 at 03:23:08PM +0900, Byungchul Park wrote:
> > > > Boqun wrote:
> > > > > *Looks like the DEPT dependency graph doesn't
On 1/18/2023 10:49 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown reasons that normally come down to a missing
w/a), it is useful to get as much information out of the system as
possible. Given
On 1/18/2023 10:49 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not reproducible.
However, it is
Boqun wrote:
> On Thu, Jan 19, 2023 at 01:33:58PM +, Matthew Wilcox wrote:
> > On Thu, Jan 19, 2023 at 03:23:08PM +0900, Byungchul Park wrote:
> > > Boqun wrote:
> > > > *Looks like the DEPT dependency graph doesn't handle the
> > > > fair/unfair readers as lockdep current does. Which bring
On 1/18/2023 10:49 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The debugfs dump of requests was confused about what state requires
the execlist lock versus the GuC lock. There was also a bunch of
duplicated messy code between it and the error capture code.
So refactor the hung
On 1/18/2023 10:49 PM, john.c.harri...@intel.com wrote:
From: John Harrison
When GuC support was added to error capture, the locking around the
request object was broken. Fix it up.
The context based search manages the spinlocking around the search
internally. So it needs to grab the
Hi all,
Today's linux-next merge of the accel tree got conflicts in:
drivers/Makefile
drivers/accel/Kconfig
drivers/accel/Makefile
between commit:
35b137630f08 ("accel/ivpu: Introduce a new DRM driver for Intel VPU")
from the drm-misc tree and commit:
45886b6fa0f1 ("habanalabs:
Thanks for reviewing Daniele - will fix these on re-rev.
And you're right - we dont need a variable "gsccs" (so HAS_ENGINE should work
fine).
On Wed, 2023-01-18 at 09:51 -0800, Ceraolo Spurio, Daniele wrote:
>
>
Alan: [snip]
Hi,
On Wed, Jan 18, 2023 at 2:34 PM Stephen Boyd wrote:
>
> Quoting Doug Anderson (2023-01-18 10:29:59)
> > Hi,
> >
> > On Tue, Dec 27, 2022 at 6:16 PM Kuogee Hsieh
> > wrote:
> > > +
> > > if (isr & DP_INTR_AUX_ERROR) {
> > > aux->aux_error_num = DP_AUX_ERR_PHY;
> > >
From: Wayne Lin
[why & how]
The term (i.e. port & mst_port) that we used to use in amdgpu is a bit
confusing. Rename them to mst_output_port & mst_root respectively.
Signed-off-by: Wayne Lin
Signed-off-by: Harry Wentland
Acked-by: Harry Wentland
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
From: Wayne Lin
[why & how]
We still need to refer to port while removing payload at commit_tail.
we should keep the kref till then to release.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Signed-off-by: Wayne Lin
Signed-off-by: Harry Wentland
Fixes: 4d07b0bc4034
From: Wayne Lin
[why & how]
adjust the coding in dm_helpers_dp_mst_send_payload_allocation()
for reading easily.
Signed-off-by: Wayne Lin
Signed-off-by: Harry Wentland
Acked-by: Harry Wentland
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +-
1 file changed, 5
From: Wayne Lin
[Why & How]
Now the vc_start_slot is controlled at drm side. When we
service a long HPD, we still need to run
dm_helpers_dp_mst_write_payload_allocation_table() to update
drm mst_mgr's relevant variable. Otherwise, on the next plug-in,
payload will get assigned with a wrong start
From: Wayne Lin
[Why]
amdgpu expects to update payload table for one stream one time
by calling dm_helpers_dp_mst_write_payload_allocation_table().
Currently, it get modified to try to update HW payload table
at once by referring mst_state.
[How]
This is just a quick workaround. Should find way
From: Wayne Lin
[why & how]
__drm_dbg() parameter set format is wrong and not aligned with the
format under CONFIG_DRM_USE_DYNAMIC_DEBUG is on. Fix it.
Signed-off-by: Wayne Lin
Signed-off-by: Harry Wentland
Acked-by: Harry Wentland
---
include/drm/drm_print.h | 2 +-
1 file changed, 1
From: Lyude Paul
Looks like I made a pretty big mistake here without noticing: it seems when
I moved the assignments of mst_state->pbn_div I completely missed the fact
that the reason for us calling drm_dp_mst_update_slots() earlier was to
account for the fact that we need to call this function
MST has been broken on amdgpu after a refactor in drm_dp_mst
code that was aligning drm_dp_mst more closely with the atomic
model.
The gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
This series fixes it.
It can be found at
On 1/19/23 22:47, Matthew Brost wrote:
On Thu, Jan 19, 2023 at 06:46:30PM +0100, Danilo Krummrich wrote:
On 1/19/23 17:38, Matthew Brost wrote:
On Thu, Jan 19, 2023 at 04:36:43PM +0100, Danilo Krummrich wrote:
On 1/19/23 05:58, Matthew Brost wrote:
On Thu, Jan 19, 2023 at 04:44:23AM +0100,
From: Rob Clark
In the error path, exynos_drm_gem_mmap() was dropping an obj reference
that it doesn't own.
Fixes: 832316c704fe ("drm/exynos: use drm generic mmap interface")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 +---
1 file changed, 1
From: Rob Clark
In the error path, rockchip_drm_gem_object_mmap() is dropping an obj
reference that it doesn't own.
Fixes: 41315b793e13 ("drm/rockchip: use drm_gem_mmap helpers")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 3 ---
1 file changed, 3 deletions(-)
From: Rob Clark
In the error path, mtk_drm_gem_object_mmap() is dropping an obj
reference that it doesn't own.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 2 --
1 file changed, 2
From: Chris Morgan
The Anbernic RG353V-V2 is a 5 inch panel used in a new revision of the
Anbernic RG353V handheld gaming device. Add support for it.
Unfortunately it appears this controller is not able to support 120hz
or 100hz mode like the first revision panel.
Signed-off-by: Chris Morgan
From: Chris Morgan
The Anbernic RG353V-V2 panel is a 5 inch 640x480 MIPI-DSI LCD panel.
It's based on the ST7703 LCD controller just like rocktech,jh057n00900.
It's used in a 2nd revision of the Anbernic RG353V handheld gaming
device. Like the first revision of the RG353V the control chip is
From: Chris Morgan
Add the NewVision NV3051D panel as found on the second revision of the
RG353V. The underlying LCD panel itself is unknown (ST7703 is the
controller IC).
Chris Morgan (2):
dt-bindings: panel: Add compatible for Anbernic RG353V-V2 panel
drm/panel: st7703: Add support for
Thanks for reviewing the patch. I will fix the code according to your
recommendation.
I assume we could probably go with -ENOLINK as the error (instead of -ENOMEM).
However, i'll wait for Alexander to respond on whether he needs drm_WARN_ON and
your question on RPM.
...alan
On Thu, 2023-01-19
On 1/17/2023 5:04 PM, Dmitry Baryshkov wrote:
To simplify adding new platforms and to make settings more obvious,
rewrite the UBWC setup to use the data structure to pass platform config
rather than just calling the functions direcly.
Signed-off-by: Dmitry Baryshkov
I was reviewing this
If our interrupt handler gets called and we don't really handle the
interrupt then we should return IRQ_NONE. The current interrupt
handler didn't do this, so let's fix it.
NOTE: for some of the cases it's clear that we should return IRQ_NONE
and some cases it's clear that we should return
The DP AUX interrupt handling was a bit of a mess.
* There were two functions (one for "native" transfers and one for
"i2c" transfers) that were quite similar. It was hard to say how
many of the differences between the two functions were on purpose
and how many of them were just an accident
From: Rob Clark
Once we create the handle, the handle owns the reference. Currently
nothing was doing anything with the shmem ptr after the handle was
created, but let's change drm_gem_shmem_create_with_handle() to not
return the pointer, so-as to not encourage problematic use of this
function
From: Rob Clark
It appears that the dependency on the DMA helpers was only for
drm_gem_dma_vm_ops.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/mediatek/Kconfig | 1 -
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 7 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git
Thanks for reviewing - responses below.
On Thu, 2023-01-19 at 14:35 -0500, Vivi, Rodrigo wrote:
> On Thu, Jan 12, 2023 at 05:18:49PM -0800, Alan Previn wrote:
> > A driver bug was recently discovered where the security firmware was
> > receiving internal HW signals indicating that session key
On Thu, Jan 19, 2023 at 01:12:22PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from drivers/gpu/drm/drm_fb_helper.c:33:
> drivers/gpu/drm/drm_fb_helper.c: In function
On Thu, Jan 19, 2023 at 09:06:54AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 18.01.23 um 20:21 schrieb Rodrigo Vivi:
> > On Thu, Jan 12, 2023 at 09:11:55PM +0100, Thomas Zimmermann wrote:
> > > Set the framebuffer info for drivers that support VGA switcheroo. Only
> > > affects the amdgpu and
On Thu, Jan 19, 2023 at 09:26:20AM +0800, Zhenyu Wang wrote:
> On 2023.01.18 11:44:55 -0500, Rodrigo Vivi wrote:
> > On Wed, Jan 18, 2023 at 10:18:11AM +0530, Deepak R Varma wrote:
> > > On Tue, Jan 17, 2023 at 02:29:37PM -0500, Rodrigo Vivi wrote:
> > > > On Mon, Jan 16, 2023 at 01:44:46PM +0800,
Thanks Rodrigo for the ack.
On Thu, 2023-01-19 at 14:28 -0500, Vivi, Rodrigo wrote:
> On Thu, Jan 12, 2023 at 05:18:48PM -0800, Alan Previn wrote:
> > A gap was recently discovered where if an application did not
> > invalidate all of the stream keys (intentionally or not), and the
> > driver did
On 1/18/23 1:00 PM, Jason Gunthorpe wrote:
> These contexts are sleepable, so use the proper annotation. The GFP_ATOMIC
> was added mechanically in the prior patches.
>
> Reviewed-by: Niklas Schnelle
> Signed-off-by: Jason Gunthorpe
> ---
> arch/s390/pci/pci_dma.c| 2 +-
>
On 1/18/23 1:00 PM, Jason Gunthorpe wrote:
> dma_alloc_cpu_table() and dma_alloc_page_table() are eventually called by
> iommufd through s390_iommu_map_pages() and it should not be forced to
> atomic. Thread the gfp parameter through the call chain starting from
> s390_iommu_map_pages().
>
>
Hi Rob,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.2-rc4 next-20230119]
[If your
On Thu, Jan 19, 2023 at 06:46:30PM +0100, Danilo Krummrich wrote:
>
>
> On 1/19/23 17:38, Matthew Brost wrote:
> > On Thu, Jan 19, 2023 at 04:36:43PM +0100, Danilo Krummrich wrote:
> > > On 1/19/23 05:58, Matthew Brost wrote:
> > > > On Thu, Jan 19, 2023 at 04:44:23AM +0100, Danilo Krummrich
On Fri, 06 Jan 2023, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates this from future changes.
>
>
On Fri, 06 Jan 2023, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates this from future changes.
>
>
On Fri, 06 Jan 2023, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates this from future changes.
>
>
Forwarded offline. Let's hold off R-B or merging until I verify that hw spec
update is finalized to be exactly as what this patch is (probably a minor
delay).
On Thu, 2023-01-19 at 14:57 -0500, Vivi, Rodrigo wrote:
> On Thu, Jan 19, 2023 at 11:49:55AM -0800, Alan Previn wrote:
> > The
From: Rob Clark
In the error path, drm_gem_dma_mmap() is dropping an obj reference that
it doesn't own.
Fixes: f5ca8eb6f9bd ("drm/cma-helper: Implement mmap as GEM CMA object
functions")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem_dma_helper.c | 2 --
1 file changed, 2 deletions(-)
Hi Dave, Daniel,
Fixes for 6.2.
The following changes since commit e695bc7e542358978434c8489a5a164d2bbefae8:
Merge tag 'drm-msm-fixes-2023-01-12' of
https://gitlab.freedesktop.org/drm/msm into drm-fixes (2023-01-13 13:01:22
+1000)
are available in the Git repository at:
On Thu, Jan 19, 2023 at 11:49:55AM -0800, Alan Previn wrote:
> The Driver-FLR flow may inadvertently exit early before the full
> completion of the re-init of the internal HW state if we only poll
> GU_DEBUG Bit31 (polling for it to toggle from 0 -> 1). Instead
> we need a two-step completion
Hi Dave and Daniel,
Couple patches targeting stable, couple DG2 w/a,
and a selftest fix.
There was a drm-tip conflict but very trivial where
keeping the new mtl function as in drm-intel-gt-next is
the right resolution.
Here goes drm-intel-fixes-2023-01-19:
- Reject display plane with height ==
The Driver-FLR flow may inadvertently exit early before the full
completion of the re-init of the internal HW state if we only poll
GU_DEBUG Bit31 (polling for it to toggle from 0 -> 1). Instead
we need a two-step completion wait-for-completion flow that also
involves GU_CNTL. See the patch and
On Thu, Jan 19, 2023 at 11:10:21AM -0800, Ceraolo Spurio, Daniele wrote:
>
>
> On 1/12/2023 5:18 PM, Alan Previn wrote:
> > During suspend flow, i915 currently achors' on the pm_suspend_prepare
> > callback as the location where we quiesce the entire GPU and perform
> > all necessary cleanup in
On Thu, Jan 12, 2023 at 05:18:49PM -0800, Alan Previn wrote:
> A driver bug was recently discovered where the security firmware was
> receiving internal HW signals indicating that session key expirations
> had occurred. Architecturally, the firmware was expecting a response
> from the GuC to
On Thu, Jan 12, 2023 at 05:18:48PM -0800, Alan Previn wrote:
> A gap was recently discovered where if an application did not
> invalidate all of the stream keys (intentionally or not), and the
> driver did a full PXP global teardown on the GT subsystem, we
> find that future session creation would
On Thu, Jan 19, 2023 at 01:33:58PM +, Matthew Wilcox wrote:
> On Thu, Jan 19, 2023 at 03:23:08PM +0900, Byungchul Park wrote:
> > Boqun wrote:
> > > * Looks like the DEPT dependency graph doesn't handle the
> > > fair/unfair readers as lockdep current does. Which bring the
> > > next
On Thu, Jan 12, 2023 at 05:18:46PM -0800, Alan Previn wrote:
> From: Alexander Usyskin
>
> Add device link with i915 as consumer and mei_pxp as supplier
> to ensure proper ordering of power flows.
>
> V2: condition on absence of heci_pxp to filter out DG
>
> Signed-off-by: Alexander Usyskin
>
On 1/12/2023 5:18 PM, Alan Previn wrote:
During suspend flow, i915 currently achors' on the pm_suspend_prepare
callback as the location where we quiesce the entire GPU and perform
all necessary cleanup in order to go into suspend. PXP is also called
during this time to perform the arbitration
Every user of this function either uses component_compare_of or
something equivalent. Most of them immediately put the device node as
well. Convert these users to component_match_add_of and remove
drm_of_component_match_add.
Signed-off-by: Sean Anderson
Acked-by: Jyri Sarha
Tested-by: Jyri
There is a common case where component_patch_add_release is called with
component_release_of/component_compare_of and a device node. Add a
helper.
Signed-off-by: Sean Anderson
---
(no changes since v2)
Changes in v2:
- Split off conversion from helper addition
include/linux/component.h | 9
Convert users of component_match_add_release with component_release_of
and component_compare_of to component_match_add_of.
Signed-off-by: Sean Anderson
Acked-by: Mark Brown
---
Changes in v3:
- Rebase onto drm/drm-next
Changes in v2:
- Split off from helper addition
This series adds a new function component_match_add_of to simplify the
common case of calling component_match_add_release with
component_release_of and component_compare_of. There is already
drm_of_component_match_add, which allows for a custom compare function.
However, all existing users just
Make various small changes to allow compile-testing on other arches.
This is helpful to allow testing changes to 32-bit arm drivers in the
same build.
The primary changes is to use macros for 64-bit divisions and shifts,
but we also need some other fixes to deal with larger constants and
Hi Jianhua,
I love your patch! Perhaps something to improve:
[auto build test WARNING on lee-backlight/for-backlight-next]
[also build test WARNING on lee-backlight/for-backlight-fixes
lee-leds/for-leds-next pavel-leds/for-next linus/master v6.2-rc4 next-20230119]
[If your patch is applied
>-Original Message-
>From: Dmitry Baryshkov
>Sent: Wednesday, January 18, 2023 9:06 AM
>To: Kalyan Thota ; Kalyan Thota (QUIC)
>; dri-devel@lists.freedesktop.org; linux-arm-
>m...@vger.kernel.org; freedr...@lists.freedesktop.org;
>devicet...@vger.kernel.org; Abhinav Kumar (QUIC)
>; Doug
Hi Inki Dae,
On Thu, Jan 12, 2023 at 7:56 AM 대인기/Tizen Platform Lab(SR)/삼성전자
wrote:
>
> Hi Jagan Teki,
>
> Sorry for late.
>
> > -Original Message-
> > From: Jagan Teki
> > Sent: Saturday, January 7, 2023 2:56 AM
> > To: Marek Szyprowski ; Inki Dae
> > ; Seung-Woo Kim ; Kyungmin
> >
From: Rob Clark
Once we create the handle, the handle owns the reference. Currently
nothing was doing anything with the shmem ptr after the handle was
created, but let's change drm_gem_shmem_create_with_handle() to not
return the pointer, so-as to not encourage problematic use of this
function
On Wed, Jan 18, 2023 at 04:58:26AM +0200, Dmitry Baryshkov wrote:
> On 08/12/2022 00:00, Bjorn Andersson wrote:
> > From: Bjorn Andersson
> >
> > Define the display clock controllers, the MDSS instances, the DP phys
> > and connect these together.
> >
> > Signed-off-by: Bjorn Andersson
> >
Hi Fabio,
On Thu, Jan 19, 2023 at 10:57 PM Fabio Estevam wrote:
>
> Hi Jagan,
>
> On Thu, Jan 5, 2023 at 7:24 AM Jagan Teki wrote:
>
> > Does anyone have any other comments on this? I would like to send v11
> > with a few nits on v10. Please let me know.
>
> What is blocking this series to be
1 - 100 of 244 matches
Mail list logo
