Hello Thomas,
On 3/30/22 12:32, Thomas Zimmermann wrote:
> Hi
>
[snip]
>>>
>>> -obj-$(CONFIG_DRM_DP_HELPER) += drm_dp_helper.o
>>> +obj-$(CONFIG_DRM_DISPLAY_HELPER) += drm_display_helper.o
>>
>> The drm_dp_helper.ko module has some parameters and this change will break
>> existing kernel cmd
I'm going to take a look, but need to figure out how to find the broken
merge
Christian.
Am 31.03.22 um 00:33 schrieb Dixit, Ashutosh:
Is anyone looking into fixing this:
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c: In function
‘amdgpu_gtt_mgr_recover’:
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_
Am 30.03.22 um 20:24 schrieb Pavel Skripkin:
Hi Christian,
On 3/30/22 10:09, Christian König wrote:
That problem is already fixed with patch 21d139d73f77 dma-buf/sync-file:
fix logic error in new fence merge code.
Am 30.03.22 um 00:14 schrieb Pavel Skripkin:
syzbot reported GPF in dma_fenc
On 29-03-22, 10:52, Rob Herring wrote:
> On Tue, Mar 29, 2022 at 12:01:52PM +0530, Vinod Koul wrote:
> > On 28-03-22, 13:21, Rob Herring wrote:
> > > On Mon, Mar 28, 2022 at 12:18 PM Krzysztof Kozlowski
> > > wrote:
> > > >
> > > > On 28/03/2022 19:16, Vinod Koul wrote:
> > > > > On 28-03-22, 19:4
Hi Dmitry,
> On Wed, 30 Mar 2022 at 19:04, Sankeerth Billakanti
> wrote:
> >
> > The panel-edp driver modes needs to be validated differently from DP
> > because the link capabilities are not available for EDP by that time.
> >
> > Signed-off-by: Sankeerth Billakanti
>
> This should not be nece
Hi Dmitry,
> On Wed, 30 Mar 2022 at 19:03, Sankeerth Billakanti
> wrote:
> >
> > The interrupt register will still reflect the connect and disconnect
> > interrupt status without generating an actual HW interrupt.
> > The controller driver should not handle those masked interrupts.
> >
> > Signed
Hi,
On Wed, Mar 30, 2022 at 4:19 PM Dmitry Baryshkov
wrote:
> > + bridge->ops =
> > + DRM_BRIDGE_OP_DETECT |
> > + DRM_BRIDGE_OP_HPD |
> > + DRM_BRIDGE_OP_MODES;
>
> I think OP_MODES should be used for eDP, shouldn't it?
No.
Hi Paul,
> -Original Message-
> From: Paul Menzel
> Sent: Thursday, March 31, 2022 12:47 AM
> To: Liu, Chuansheng
> Cc: tzimmerm...@suse.de; linux-fb...@vger.kernel.org; del...@gmx.de; dri-
> de...@lists.freedesktop.org
> Subject: Re: [PATCH] fbdev: defio: fix the pagelist corruption
>
Rather than relying on the implicit behavior of intel_uncore_*()
functions, let's always use the intel_gt_mcr_*() functions to operate on
multicast/replicated registers.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 4 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 4
XEHPSDV_TILE0_ADDR_RANGE is a GT register and requires multicast
handling. Move the definition to the proper header.
Fixes: b8ca8fef58d4 ("drm/i915/stolen: don't treat small BAR as an error")
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 1 +
drivers/gpu/drm/i915/gt
Historically we've selected and programmed a single MCR group/instance
ID at driver startup that will steer register accesses for GSLICE/DSS
ranges to a non-terminated instance. Any reads of these register ranges
that don't need a specific unicast access won't bother explicitly
resteering because
Rather than treating multicast registers as 'i915_reg_t' let's define
them as a completely new type. This will allow the compiler to help us
make sure we're using multicast-aware functions to operate on multicast
registers.
This plan does break down a bit in places where we're just maintaining
he
Let's be more explicit about which of our workarounds are updating MCR
registers.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 346 +++-
1 file changed, 198 insertions(+), 148 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b
Handling of multicast/replicated registers is spread across intel_gt.c
and intel_uncore.c today. As multicast handling and the related
steering logic gets more complicated with the addition of new platforms
and new rules it makes sense to centralize it all in one place.
For now the existing funct
Rather than using the same _MMIO() macro to define MCR registers as
singleton registers, let's use a new MCR_REG() macro to make it clear
that these registers are special and should be handled accordingly. For
now MCR_REG() will still generate an i915_reg_t with the given offset,
but we'll change
Starting in Xe_HP, several registers our driver works with have been
converted from singleton registers into replicated registers with
multicast behavior. Although the registers are still located at the
same MMIO offsets as on previous platforms, let's duplicate the register
definitions in prepara
Let's replace the assortment of intel_gt_* and intel_uncore_* functions
that operate on MCR registers with a cleaner set of interfaces:
* intel_gt_mcr_read -- unicast read from specific instance
* intel_gt_mcr_read_any[_fw] -- unicast read from any non-terminated
instance
* intel_gt_mcr_
When this register was moved to intel_gt_regs.h it wasn't dropped from
i915_reg.h; do so now.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_reg.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index efb81cb4c7c0..
MCR registers can be placed on the GuC's save/restore list, but at the
moment they are always handled in a multicast manner (i.e., the GuC
reads one instance to save the value and then does a multicast write to
restore that single value to all instances). In the future the GuC will
probably give u
Gen8 was the first time our hardware had multicast registers (or at
least the first time the multicast nature was exposed and MMIO accesses
could be steered). There are some registers that transitioned from
singleton behavior to multicast during the gen7 -> gen8 transition;
let's duplicate the reg
The fault registers are multicast registers, replicated per-mslice
starting on Xe_HP. When checking for faults, we should check each
mslice's instance of the register rather than just one of the instances.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 44 ++
We have a few registers that have existed for several hardware
generations, but are only used by the driver on Xe_HP and beyond. In
cases where the Xe_HP version of the register is now replicated and uses
multicast behavior, but earlier generations were singleton, let's change
the register prefix
Let's drop a few register definitions that are unused anywhere in the
driver today. Since the referenced offsets are part of what is now
considered a multicast register region, the current definitions would
not be correct for use on any future platform.
Signed-off-by: Matt Roper
---
drivers/gpu
Multicast/replicated (MCR) registers on Intel hardware are a purely
GT-specific concept. Rather than leaving MCR register handling spread
across several places throughout the driver (intel_uncore.c, intel_gt.c,
etc.) with confusing combinations of handler functions living in
different namespaces,
On 30/03/2022 19:02, Sankeerth Billakanti wrote:
This patch adds support for generic eDP sink through aux_bus. The eDP/DP
controller driver should support aux transactions originating from the
panel-edp driver and hence should be initialized and ready.
The panel bridge supporting the panel shoul
Hi,
On Wed, 30 Mar 2022 at 20:47, Daniel Vetter wrote:
> On Thu, Mar 31, 2022 at 12:14:31AM +0530, Jagan Teki wrote:
> > Does it mean the userspace knows when to disconnect and connect the
> > LVDS or HDMI? What if display-switch ISR will disconnect LVDS and
> > connect HDMI when HPD is On and co
>From [1], I realized two other calls to dcn30 code are associated with
FPU operations and are not protected by DC_FP_* macros:
* dcn30_populate_dml_writeback_from_context()
* dcn30_set_mcif_arb_params()
So, since FPU-associated code is not fully isolated in dcn30, and
dcn3.1.x reuses them, let's
Is anyone looking into fixing this:
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c: In function
‘amdgpu_gtt_mgr_recover’:
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:200:31: error: ‘struct
ttm_range_mgr_node’ has no member named ‘tbo’
amdgpu_ttm_recover_gart(node->tbo);
Since the last commit, the max_pclk_khz became constant, it's set to
DP_MAX_PIXEL_CLK_KHZ and never changed afterwards. Remove it completely
and use DP_MAX_PIXEL_CLK_KHZ directly.
Reviewed-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_
Since dp_panel_get_modes() handling for dp_mode was removed,
dp_display_get_modes also doesn't change the passed dp_mode, drop the
unused dp_mode variable being allocated unused and then freed.
Reviewed-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/
Make dp_connector_mode_valid() return precise MODE_CLOCK_HIGH rather
than generic MODE_BAD in case the mode clock is higher than
DP_MAX_PIXEL_CLK_KHZ (675 MHz).
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Since the commit ab205927592b ("drm/msm/dp: remove mode hard-coding in
case of DP CTS") the function dp_panel_get_modes() doesn't use (or fill)
the dp_mode argument. Drop it completely.
Reviewed-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/
As noted by Ville Syrjälä [1] the dp_connector_get_modes() has weird
on-stack interim copy of the mode. When reviewing the mentioned patch I
noticed that the rest of the code in dp_connector_get_modes() is weird,
unused since September of 2020 and can be removed. This series removes
dead weird code
On Wed, 30 Mar 2022 at 19:03, Sankeerth Billakanti
wrote:
>
> The interrupt register will still reflect the connect and disconnect
> interrupt status without generating an actual HW interrupt.
> The controller driver should not handle those masked interrupts.
>
> Signed-off-by: Sankeerth Billakant
On Wed, 30 Mar 2022 at 19:04, Sankeerth Billakanti
wrote:
>
> The panel-edp driver modes needs to be validated differently from DP
> because the link capabilities are not available for EDP by that time.
>
> Signed-off-by: Sankeerth Billakanti
This should not be necessary after
https://patchwork.
Hi Matthew,
I sent this patch by accident. Please ignore it.
Regards,
Alex Sierra
> -Original Message-
> From: Matthew Wilcox
> Sent: Wednesday, March 30, 2022 4:29 PM
> To: Sierra Guiza, Alejandro (Alex)
> Cc: j...@nvidia.com; da...@redhat.com; Kuehling, Felix
> ; linux...@kvack.org; r
Newer platforms have DSS that aren't necessarily available for both
geometry and compute, two queries will need to exist. This introduces
the first, when passing a valid engine class and engine instance in the
flags returns a topology describing geometry.
v2: fix white space errors
v3: change flag
On Wed, Mar 30, 2022 at 04:24:20PM -0500, Alex Sierra wrote:
> From: Philip Yang
>
> SVMAPISupported property added to HSA_CAPABILITY, the value match
> HSA_CAPABILITY defined in Thunk spec:
>
> SVMAPISupported: it will not be supported on older kernels that don't
> have HMM or on systems with G
Please ignore this patch.
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Sierra
> Sent: Wednesday, March 30, 2022 4:24 PM
> To: j...@nvidia.com
> Cc: rcampb...@nvidia.com; wi...@infradead.org; da...@redhat.com;
> Kuehling, Felix ; apop...@nvidia.com; amd-
> g...@lists.freedeskto
The objective is to test device migration mechanism in pages marked
as COW, for private and coherent device type. In case of writing to
COW private page(s), a page fault will migrate pages back to system
memory first. Then, these pages will be duplicated. In case of COW
device coherent type, pages
Test device pages with get_user_pages and get_user_pages_fast.
The motivation is to test device coherent type pages in the gup and
gup fast paths, after vm_normal_pages was split into LRU and non-LRU
handled.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
---
tools/testing/selftests/vm/hmm
With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
device-managed anonymous pages that are not LRU pages. Although they
behave like normal pages for purposes of mapping in CPU page, and for
COW. They do not support LRU lists, NUMA migration or THP. The
difference between new vm_normal_l
With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
device-managed anonymous pages that are not LRU pages. Although they
behave like normal pages for purposes of mapping in CPU page, and for
COW. They do not support LRU lists, NUMA migration or THP. The
difference between new vm_normal_l
From: Philip Yang
SVMAPISupported property added to HSA_CAPABILITY, the value match
HSA_CAPABILITY defined in Thunk spec:
SVMAPISupported: it will not be supported on older kernels that don't
have HMM or on systems with GFXv8 or older GPUs without support for
48-bit virtual addresses.
CoherentH
Add bindings for Lontium LT9211 Single/Dual-Link DSI/LVDS or Single DPI to
Single-link/Dual-Link DSI/LVDS or Single DPI bridge. This chip is highly
capable at converting formats, but sadly it is also highly undocumented.
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime
Add driver for Lontium LT9211 Single/Dual-Link DSI/LVDS or Single DPI to
Single-link/Dual-Link DSI/LVDS or Single DPI bridge. This chip is highly
capable at converting formats, but sadly it is also highly undocumented.
This driver is written without any documentation from Lontium and based
only on
Hi,
On Wed, Mar 30, 2022 at 9:04 AM Matthias Kaehlcke wrote:
>
> Two digits are swapped in the AUO B133UAN01 panel id (0x8495 instead
> of 0x8594). This went initially unnoticed because the panel is still
> detected, though it is set up with a conservative default timing. Fix
> the digit swap.
>
On Wed, 30 Mar 2022, Jani Nikula wrote:
> On Wed, 30 Mar 2022, Ville Syrjälä wrote:
>> This one points to extension blocks too so using
>> struct edid doesn't seem entirely appropriate.
>
> So I've gone back and forth with this. I think I want to get rid of u8*
> no matter what, because it alway
From: Rob Clark
With userspace allocated iova (next patch), we can have a race condition
where userspace observes the fence completion and deletes the vma before
retire_submit() gets around to unpinning the vma. To handle this, add a
fenced unpin which drops the refcount but tracks the fence, an
From: Rob Clark
The motivation at this point is mainly native userspace mesa driver in a
VM guest. The one remaining synchronous "hotpath" is buffer allocation,
because guest needs to wait to know the bo's iova before it can start
emitting cmdstream/state that references the new bo. By allocati
From: Rob Clark
Combines duplicate vma lookup in the get_and_pin path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 50 ++-
1 file changed, 26 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_ge
From: Rob Clark
This way we only lookup vma once per object per submit, for both the
submit and retire path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c| 60 +---
drivers/gpu/drm/msm/msm_gem.h| 9 +++--
drivers/gpu/drm/msm/msm_gem_submit.
From: Rob Clark
Get rid of all the unnecessary conversion between address/size and page
offsets. It just confuses things.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
drivers/gpu/drm/msm/msm_gem.c | 5 ++---
drivers/gpu/dr
From: Rob Clark
There was only a single user, which could just as easily stash the iova
when pinning.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_fb.c | 16 ++--
drivers/gpu/drm/msm/msm_gem.c | 16
drivers/gpu/drm/msm/msm_ge
From: Rob Clark
Prep for a following patch, where it gets a bit more complicated.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 2 +-
drivers/gpu/drm/msm/msm_gem.h | 1 +
drivers/gpu/drm/msm/msm_gem_vma.c | 9 +++--
3 files changed, 9 insertions(+), 3 deletions(-)
d
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_vma.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c
b/drivers/gpu/drm/msm/msm_gem_vma.c
index f914ddbaea89..64906594fc65 100644
--- a/drivers/gpu/drm/msm/
From: Rob Clark
The ring seqno counter duplicates the fence-context last_fence counter.
They end up getting incremented in lock-step, on the same scheduler
thread, but the split just makes things less obvious.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
drivers
From: Rob Clark
These belong more cleanly in the gem header.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.h | 23 ---
drivers/gpu/drm/msm/msm_gem.h | 22 ++
2 files changed, 22 insertions(+), 23 deletions(-)
di
From: Rob Clark
The first six paches are various cleanups and simplifications. The
next two get rid of redundant vma lookups in the submit and retire
paths. Following that, fenced vma lets us indicate a fence value
following which the vma is no longer used, which is needed because
otherwise use
On 30/03/22 2:42 pm, Christian König wrote:
> Am 30.03.22 um 11:20 schrieb Arunpravin Paneer Selvam:
>>
>> On 30/03/22 2:37 pm, Christian König wrote:
>>> Am 30.03.22 um 11:04 schrieb Arunpravin Paneer Selvam:
Round up the size value to the min_page_size and trim the last block to
the
This looks very similar to existing perf_pmu tests with the slight
change that the busyness is now captured from the fdinfo.
lgtm,
Reviewed-by: Umesh Nerlige Ramappa
Umesh
On Tue, Feb 22, 2022 at 01:55:56PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Mostly inherited from the perf_pm
On Wed, Mar 30, 2022 at 09:35:17PM +0200, Piotr Oniszczuk wrote:
>
>
> > Wiadomość napisana przez Sascha Hauer w dniu
> > 30.03.2022, o godz. 21:20:
> >
> >> So i tried following combinations
> >>
> >> -boot
> >> -modetest -s 69@67:1920x1080 -> ok
> >> -modetest -P 43@67:1920x1080@NV12 -> gre
On Wed, Mar 30, 2022 at 08:53:11AM -0700, John Harrison wrote:
> Sorry, only just seen this patch.
>
> Please do not do this!
>
> The entire lrc_desc_pool entity is being dropped as part of the update to
> GuC v70. That's why there was a recent patch set to significantly
> re-organise how/where i
On Tue, Feb 22, 2022 at 01:55:55PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Tests and intel_gpu_top will share common code for parsing this file.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_fdinfo.c | 183 +++
lib/igt_drm_fdinfo.h | 48 ++
On Thu, Mar 31, 2022 at 12:14:31AM +0530, Jagan Teki wrote:
> On Wed, Mar 30, 2022 at 3:27 PM Daniel Vetter wrote:
> >
> > On Wed, Mar 30, 2022 at 10:52:54AM +0200, Maxime Ripard wrote:
> > > On Tue, Mar 29, 2022 at 11:38:32PM +0530, Jagan Teki wrote:
> > > > Hi all,
> > > >
> > > > I have impleme
From: Chris Morgan
Add the option to set the byteswap order in the devicetree. For the
official HDMI DIP for the NTC CHIP the byteswap order needs to be
RGB, however the driver sets it as BGR. With this patch the driver
will remain at BGR unless manually specified via devicetree.
Signed-off-by:
From: Chris Morgan
Update dt-binding documentation to add support for setting byteswap of
chrontel ch7033.
New property name of chrontel,byteswap added to set the byteswap order.
This property is optional.
Signed-off-by: Chris Morgan
---
.../bindings/display/bridge/chrontel,ch7033.yaml
From: Chris Morgan
This series adds the ability to set the byteswap order in the chrontel
ch7033 driver via an optional devicetree node. This is necessary
because the HDMI DIP of the NTC CHIP requires a byteswap order that
differs from the default value of the driver.
Signed-off-by: Chris Morgan
> Wiadomość napisana przez Sascha Hauer w dniu
> 30.03.2022, o godz. 21:20:
>
>> So i tried following combinations
>>
>> -boot
>> -modetest -s 69@67:1920x1080 -> ok
>> -modetest -P 43@67:1920x1080@NV12 -> green screen
>
> I have no idea what is going on here. There same commands work for me
On Wed, Mar 30, 2022 at 04:52:22PM +0200, Piotr Oniszczuk wrote:
>
>
> > Wiadomość napisana przez Sascha Hauer w dniu
> > 30.03.2022, o godz. 12:20:
> >
> > Does it change anything if you do a "modetest -s 69@67:1920x1080" before
> > starting the app? Or if you run "modetest -P 43@67:1920x1080
From: Chen-Yu Tsai
Hi everyone,
This series adds support for SH1106 to the ssd130x OLED display
driver.
The SINO WEALTH SH1106 is an OLED display driver that is somewhat
compatible with the SSD1306. It supports a slightly wider display,
at 132 instead of 128 pixels. The basic commands are the s
From: Chen-Yu Tsai
Add a vendor prefix entry for SINO WEALTH Eletronics Ltd.
(http://www.sinowealth.com).
Signed-off-by: Chen-Yu Tsai
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefix
From: Chen-Yu Tsai
The SINO WEALTH SH1106 is an OLED display driver that is somewhat
compatible with the SSD1306. It supports a slightly wider display,
at 132 instead of 128 pixels. The basic commands are the same, but
the SH1106 doesn't support the horizontal or vertical address modes.
Add a co
From: Chen-Yu Tsai
The SINO WEALTH SH1106 is an OLED display driver that is somewhat
compatible with the SSD1306. It supports a slightly wider display,
at 132 instead of 128 pixels. The basic commands are the same, but
the SH1106 doesn't support the horizontal or vertical address modes.
Add supp
From: Chen-Yu Tsai
On the SINO WEALTH SH1106, which is mostly compatible with the SSD1306,
only the basic page addressing mode is supported. This addressing mode
is not as easy to use compared to the currently supported horizontal
addressing mode, as the page address has to be set prior to writin
On Wed, Mar 30, 2022 at 3:27 PM Daniel Vetter wrote:
>
> On Wed, Mar 30, 2022 at 10:52:54AM +0200, Maxime Ripard wrote:
> > On Tue, Mar 29, 2022 at 11:38:32PM +0530, Jagan Teki wrote:
> > > Hi all,
> > >
> > > I have implemented runtime display switching in the MIPI switch design
> > > where LVDS
Hi Christian,
On 3/30/22 10:09, Christian König wrote:
That problem is already fixed with patch 21d139d73f77 dma-buf/sync-file:
fix logic error in new fence merge code.
Am 30.03.22 um 00:14 schrieb Pavel Skripkin:
syzbot reported GPF in dma_fence_array_first(), which is caused by
dereferencing
When building with CONFIG_PM=y and CONFIG_PM_SLEEP=n (such as ARCH=riscv
allmodconfig), the following warnings/errors occur:
drivers/gpu/drm/msm/adreno/adreno_device.c:679:12: error:
'adreno_system_resume' defined but not used [-Werror=unused-function]
679 | static int adreno_system_resume(
On Wed, 30 Mar 2022, Felix Kuehling wrote:
>
> Am 2022-03-30 um 03:51 schrieb Lee Jones:
> > This ensures userspace cannot prematurely clean-up the client before
> > it is fully initialised which has been proven to cause issues in the
> > past.
> >
> > Cc: Felix Kuehling
> > Cc: Alex Deucher
>
On Wed, Mar 30, 2022 at 4:32 AM Dmitry Baryshkov
wrote:
>
> On Wed, 30 Mar 2022 at 02:00, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > Prep for a following patch. While we are at it, convert a few remaining
> > WARN_ON()s to GEM_WARN_ON().
>
> Well... GEM_WARN_ON doesn't really look like a
On Wed, Mar 30, 2022 at 08:04:26PM +0300, Jani Nikula wrote:
> The invalid EDID block filtering uses the number of valid EDID
> extensions instead of all EDID extensions for looping the extensions in
> the copy. This is fine, by coincidence, if all the invalid blocks are at
> the end of the EDID. H
On Wed, 30 Mar 2022, Ville Syrjälä wrote:
> I'd fix this up front so we don't end having to backport the whole
> thing if/when some security scan gizmo stumbles on this.
Sent separately [1]. I'll rebase this series on top once that gets
merged, but the conflict is trivial so I think the first rou
The invalid EDID block filtering uses the number of valid EDID
extensions instead of all EDID extensions for looping the extensions in
the copy. This is fine, by coincidence, if all the invalid blocks are at
the end of the EDID. However, it's completely broken if there are
invalid extensions in the
On Wed, Mar 30, 2022 at 07:28:56PM +0300, Jani Nikula wrote:
> On Wed, 30 Mar 2022, Ville Syrjälä wrote:
> > On Wed, Mar 30, 2022 at 06:16:17PM +0300, Jani Nikula wrote:
> >> On Wed, 30 Mar 2022, Ville Syrjälä wrote:
> >> > On Tue, Mar 29, 2022 at 09:42:08PM +0300, Jani Nikula wrote:
> >> >> Mixi
[Cc: -jay...@intworks.biz as it bounces]
Dear Chuansheng,
Am 29.03.22 um 01:58 schrieb Liu, Chuansheng:
-Original Message-
From: Paul Menzel
Sent: Monday, March 28, 2022 2:15 PM
Am 28.03.22 um 02:58 schrieb Liu, Chuansheng:
-Original Message-
Sent: Saturday, March 26,
Am 2022-03-30 um 03:51 schrieb Lee Jones:
This ensures userspace cannot prematurely clean-up the client before
it is fully initialised which has been proven to cause issues in the
past.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel
On Wed, 30 Mar 2022, Ville Syrjälä wrote:
> On Wed, Mar 30, 2022 at 06:16:17PM +0300, Jani Nikula wrote:
>> On Wed, 30 Mar 2022, Ville Syrjälä wrote:
>> > On Tue, Mar 29, 2022 at 09:42:08PM +0300, Jani Nikula wrote:
>> >> Mixing u8 * and struct edid * is confusing, switch to the latter.
>> >>
>>
Two digits are swapped in the AUO B133UAN01 panel id (0x8495 instead
of 0x8594). This went initially unnoticed because the panel is still
detected, though it is set up with a conservative default timing. Fix
the digit swap.
Fixes: ec57376fba5a ("drm/panel-edp: Add AUO B133UAN01")
Signed-off-by: Ma
The panel-edp driver modes needs to be validated differently from DP
because the link capabilities are not available for EDP by that time.
Signed-off-by: Sankeerth Billakanti
---
drivers/gpu/drm/msm/dp/dp_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/
Some eDP sinks or platform boards will not support hpd.
This patch adds support for those cases.
Signed-off-by: Sankeerth Billakanti
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b
Remove the unnecessary delay in executing the EV_HPD_INIT_SETUP event.
Signed-off-by: Sankeerth Billakanti
---
drivers/gpu/drm/msm/dp/dp_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index
The aux_bus support with the dp_display driver will enable the dp
resources during msm_dp_modeset_init. The host_init has to return early
if the core is already initialized to prevent putting an additional vote
for the dp controller resources.
Signed-off-by: Sankeerth Billakanti
---
drivers/gpu/
The interrupt register will still reflect the connect and disconnect
interrupt status without generating an actual HW interrupt.
The controller driver should not handle those masked interrupts.
Signed-off-by: Sankeerth Billakanti
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 5 +++--
1 file changed,
The panel-edp enables the eDP panel power during probe, get_modes
and enable. The eDP connect and disconnect interrupts for the eDP/DP
controller are directly dependent on panel power. As eDP display can be
assumed as always connected, the controller driver can skip the eDP
connect and disconnect i
The source device should ensure the sink is ready before proceeding to
read the sink capability or performing any aux transactions. The sink
will indicate its readiness by asserting the HPD line. The controller
driver needs to wait for the hpd line to be asserted by the sink before
performing any a
This patch adds support for generic eDP sink through aux_bus. The eDP/DP
controller driver should support aux transactions originating from the
panel-edp driver and hence should be initialized and ready.
The panel bridge supporting the panel should be ready before the bridge
connector is initializ
This series adds support for generic eDP panel over aux_bus.
These changes are dependent on the following series in order:
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=620127&state=*
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=616587&state=*
https://patchwork
Sorry, only just seen this patch.
Please do not do this!
The entire lrc_desc_pool entity is being dropped as part of the update
to GuC v70. That's why there was a recent patch set to significantly
re-organise how/where it is used. That patch set explicitly said - this
is all in preparation fo
On Wed, Mar 30, 2022 at 06:16:17PM +0300, Jani Nikula wrote:
> On Wed, 30 Mar 2022, Ville Syrjälä wrote:
> > On Tue, Mar 29, 2022 at 09:42:08PM +0300, Jani Nikula wrote:
> >> Mixing u8 * and struct edid * is confusing, switch to the latter.
> >>
> >> Cc: Ville Syrjälä
> >> Signed-off-by: Jani Ni
On Wed, 30 Mar 2022, Ville Syrjälä wrote:
> On Tue, Mar 29, 2022 at 09:42:08PM +0300, Jani Nikula wrote:
>> Mixing u8 * and struct edid * is confusing, switch to the latter.
>>
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_edid.c | 31 +++-
1 - 100 of 174 matches
Mail list logo
