On 09/02/2022 20:26, Christian König wrote:
It is illegal to add a dma_fence_chain as timeline point. Flatten out
the fences into a dma_fence_array instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 61 ---
1 file changed, 56 insertion
On Wednesday, May 25th, 2022 at 00:03, Alex Deucher
wrote:
> > Why would anyone want to run at 8bpc when they have a panel with
> > higher color depth? So I think someone is going to be doing that
> > modeset eventually anyway.
>
> We used to do something similar, but then got piles of bug repor
https://bugzilla.kernel.org/show_bug.cgi?id=213145
--- Comment #15 from Eric Wheeler (bugzilla-ker...@z.ewheeler.org) ---
I found this bug because our card was hanging the entire system, it didn't even
ping and we had to get dmesg output from netconsole. While it would be (more)
acceptable for th
https://bugzilla.kernel.org/show_bug.cgi?id=213145
--- Comment #14 from Eric Wheeler (bugzilla-ker...@z.ewheeler.org) ---
Interesting, that makes sense. Does the kernel have a framework for notifying
window managers that the graphics driver reset? If not then that seems like
that would be the ne
On Tue, May 24, 2022 at 7:57 AM Rob Clark wrote:
>
> On Tue, May 24, 2022 at 6:45 AM Tvrtko Ursulin
> wrote:
> >
> > On 23/05/2022 23:53, Rob Clark wrote:
> > >
> > > btw, one fun (but unrelated) issue I'm hitting with scheduler... I'm
> > > trying to add an igt test to stress shrinker/eviction,
On Sun, 2022-05-22 at 21:35 +0200, Thomas Zimmermann wrote:
> > Interesting. Did you find some formats that were not supported ?
>
> We still don't support XRGB1555. If the native buffer uses this format,
> we'd have no conversion helper. In this case, we rely on userspace/fbcon
> to use the nat
https://bugzilla.kernel.org/show_bug.cgi?id=213145
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugzilla.kernel.org/show_bug.cgi?id=213145
Eric Wheeler (bugzilla-ker...@z.ewheeler.org) changed:
What|Removed |Added
CC||bugzilla-k
Hi,
On Fri, May 20, 2022 at 2:27 PM Kuogee Hsieh wrote:
>
> @@ -101,11 +101,6 @@ struct dp_reg_entry {
> int disable_load;
> };
>
> -struct dp_regulator_cfg {
> - int num;
> - struct dp_reg_entry regs[DP_DEV_REGULATOR_MAX];
You forgot to delete the #define of DP_DEV_REGULATO
Hi,
On Fri, May 20, 2022 at 2:28 PM Kuogee Hsieh wrote:
>
> This patch add regulator_set_load() before enable regulator at
> eDP phy driver.
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/phy/qualcomm/phy-qcom-edp.c | 12
> 1 file changed, 12 insertions(+)
Reviewed-by: Douglas An
Hi,
On Fri, May 20, 2022 at 2:27 PM Kuogee Hsieh wrote:
>
> This patch add regulator_set_load() before enable regulator at
> DP phy driver.
>
> Signed-off-by: Kuogee Hsieh
> Reviewed-by: Stephen Boyd
> ---
> drivers/phy/qualcomm/phy-qcom-qmp.c | 25 -
> 1 file changed,
PVC also has a hwconfig table. Actually the current expectation is that
all future platforms will have hwconfig, so let's just change the
condition to an IP version check so that we don't need to keep updating
this for each new platform that shows up.
Cc: John Harrison
Cc: Radhakrishna Sripada
On Tue, May 24, 2022 at 11:43 AM Ville Syrjälä
wrote:
>
> On Tue, May 24, 2022 at 11:36:22AM +0200, Hans de Goede wrote:
> > Hi,
> >
> > On 5/23/22 13:54, Sebastian Wick wrote:
> > > On Mon, May 23, 2022 at 10:23 AM Pekka Paalanen
> > > wrote:
> > >>
> > >> On Fri, 20 May 2022 17:20:50 +0200
> >
On 2022-05-24 02:43:01, Dmitry Baryshkov wrote:
> Hi,
>
> On Tue, 24 May 2022 at 00:38, Marijn Suijten
> wrote:
> >
> > As stated in [1] I promised to tackle and send this series.
> >
> > parent_hw pointers are easier to manage and cheaper to use than
> > repeatedly formatting the parent name and
On 2022-05-24 01:44:49, Dmitry Baryshkov wrote:
> On Tue, 24 May 2022 at 01:44, Dmitry Baryshkov
> wrote:
> >
> > On Tue, 24 May 2022 at 00:38, Marijn Suijten
> > wrote:
> > >
> > > parent_hw pointers are easier to manage and cheaper to use than
> > > repeatedly formatting the parent name and sub
This is already static, in our local branch, from this commit:
commit 6852e61a0917a2
Author: Evan Quan
Date: Thu May 19 17:28:12 2022 +0800
drm/amdgpu: suppress some compile warnings
Suppress two compile warnings about "no previous prototype".
Reported-by: kernel test rob
Hi,
On Mon, May 23, 2022 at 7:46 PM gaochao wrote:
>
> From: Gao Chao
>
> If CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20=y && CONFIG_DRM_DISPLAY_HELPER=m,
> bulding fails:
>
> drivers/gpu/drm/panel/panel-samsung-atna33xc20.o: In function
> `atana33xc20_probe':
> panel-samsung-atna33xc20.c:(.text+0x744)
Dne torek, 24. maj 2022 ob 19:14:35 CEST je Roman Stratiienko napisal(a):
> By the way, not related to this issue:
>
> I cherry-picked
> https://patchwork.kernel.org/project/dri-devel/patch/20220424162633.12369-9-sam...@sholland.org/
> and got a blank FB console on OPI3.
> Can you check it please?
Don't top post, it's annoying and against rules.
Dne torek, 24. maj 2022 ob 19:10:06 CEST je Roman Stratiienko napisal(a):
> Please draft a test for the zpos issue you're mentioning.
>
> It's very easy to do with kmsxx using python wrapper.
>
> Or explain steps to reproduce here, I will write it
Dne nedelja, 22. maj 2022 ob 12:48:27 CEST je benly...@gmail.com napisal(a):
> Hi Jernej!
>
> > Which SDK? All SDKs that I have or found on internet don't mention YUV nor
RGB
> > scanline limit. That doesn't mean there is none, I'm just unable to verify
> > your claim. Did you test this by yourse
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 cases such as migrate_fault and migrate_multiple, were modified to
explicit migrate from device to sys memory without the need of page
faults, when using device coherent type.
Snapshot test case updated to read memory device type first and based
on that, get the proper returned results migrat
From: Alistair Popple
migrate_vma_setup() checks that a valid vma is passed so that the page
tables can be walked to find the pfns associated with a given address
range. However in some cases the pfns are already known, such as when
migrating device coherent pages during pin_user_pages() meaning
The intention is to test hmm device coherent type under different get
user pages paths. Also, test gup with FOLL_LONGTERM flag set in
device coherent pages. These pages should get migrated back to system
memory.
Signed-off-by: Alex Sierra
Reviewed-by: Alistair Popple
---
tools/testing/selftests
Device Coherent type uses device memory that is coherently accesible by
the CPU. This could be shown as SP (special purpose) memory range
at the BIOS-e820 memory enumeration. If no SP memory is supported in
system, this could be faked by setting CONFIG_EFI_FAKE_MEMMAP.
Currently, test_hmm only sup
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.
We also introduced a FOLL_LRU flag th
In order to configure device coherent in test_hmm, two module parameters
should be passed, which correspond to the SP start address of each
device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed,
private device type is configured.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Add two more parameters to set spm_addr_dev0 & spm_addr_dev1
addresses. These two parameters configure the start SP
addresses for each device in test_hmm driver.
Consequently, this configures zone device type as coherent.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Reviewed-by: Alistair
new ioctl cmd added to query zone device type. This will be
used once the test_hmm adds zone device coherent type.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Reviewed-by: Alistair Poppple
Signed-off-by: Christoph Hellwig
---
lib/test_hmm.c | 23 +--
lib/test_
This case is used to migrate pages from device memory, back to system
memory. Device coherent type memory is cache coherent from device and CPU
point of view.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Reviewed-by: Alistair Poppple
Signed-off-by: Christoph Hellwig
---
include/linux/m
From: Alistair Popple
Currently any attempts to pin a device coherent page will fail. This is
because device coherent pages need to be managed by a device driver, and
pinning them would prevent a driver from migrating them off the device.
However this is no reason to fail pinning of these pages.
When CPU is connected throug XGMI, it has coherent
access to VRAM resource. In this case that resource
is taken from a table in the device gmc aperture base.
This resource is used along with the device type, which could
be DEVICE_PRIVATE or DEVICE_COHERENT to create the device
page map region.
Also
Device memory that is cache coherent from device and CPU point of view.
This is used on platforms that have an advanced system bus (like CAPI
or CXL). Any page of a process can be migrated to such memory. However,
no one should be allowed to pin such memory so that it can always be
evicted.
Signed
This is our MEMORY_DEVICE_COHERENT patch series rebased and updated
for current 5.18.0
Changes since the last version:
- Fixed problems with migration during long-term pinning in
get_user_pages
- Open coded vm_normal_lru_pages as suggested in previous code review
- Update hmm_gup_test with more ge
Dne torek, 24. maj 2022 ob 19:07:27 CEST je Samuel Holland napisal(a):
> On 5/23/22 8:14 AM, Icenowy Zheng wrote:
> > 在 2022-05-22星期日的 10:36 +0200,Jernej Škrabec写道:
> >> Hi!
> >>
> >> Dne sobota, 21. maj 2022 ob 15:34:43 CEST je Genfu Pan napisal(a):
> >>> Accrording the SDK from Allwinner, the sca
On 5/23/2022 7:02 AM, Alistair Popple wrote:
Technically I think this patch should be earlier in the series. As I
understand it patch 1 allows DEVICE_COHERENT pages to be inserted in the
page tables and therefore makes it possible for page table walkers to
see non-LRU pages.
Patch will reorde
On Tue, May 10, 2022 at 11:02:28PM -0700, Matt Roper wrote:
> From: Daniele Ceraolo Spurio
>
> Disable HuC loading since it is not used on these platforms.
>
> Cc: Stuart Summers
Reviewed-by: Matt Atwood
> Signed-off-by: Daniele Ceraolo Spurio
> Signed-off-by: Matt Roper
> ---
> drivers/gpu
On Tue, May 10, 2022 at 11:02:27PM -0700, Matt Roper wrote:
> Intialize ADS system info to reflect the availablity of new BCS engines
>
> Original-author: CQ Tang
> Cc: Stuart Summers
> Cc: John Harrison
Reviewed-by: Matt Atwood
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/uc/i
On Tue, May 10, 2022 at 11:02:26PM -0700, Matt Roper wrote:
> From: Stuart Summers
>
> Although we already strip 3D-specific flags from PIPE_CONTROL
> instructions when submitting to a compute engine, there are some
> additional flags that need to be removed when the platform as a whole
> lacks a
On Tue, May 10, 2022 at 11:02:25PM -0700, Matt Roper wrote:
> Add PVC's forcewake ranges.
>
> v2:
> - Drop replicated comment completely; move general cleanup of the
>documentation to a separate patch.
>
> Bspec: 67609
> Cc: Daniele Ceraolo Spurio
> Cc: Stuart Summers
Reviewed-by: Matt Atw
The supported EOTFs are defined in eotf_supported in drm_edid
but userspace has no way of knowing what is and isn't supported
when creating an HDR_OUTPUT_METADATA and will only know
something is wrong when the atomic commit fails.
Since it is expected that userspace reads the EDID to understand
wh
On Tue, May 24, 2022 at 10:43:39AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Catch and log any garbage in the register, including no tiles marked, or
> multiple tiles marked.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Matt Roper
> ---
> We caught garbage in DG1_MSTR_TILE_INTR with D
On Tue, May 10, 2022 at 11:02:24PM -0700, Matt Roper wrote:
> Let's reorganize some of the forcewake/shadow handling in intel_uncore.c
> and consolidate the cargo-cult comments on each table into more general
> comments that apply to all tables.
>
> We'll probably move forcewake handling to its ow
On 5/24/2022 3:35 AM, Vinod Koul wrote:
Commit 58dca9810749 ("drm/msm/disp/dpu1: Add support for DSC in
encoder") added dsc_common_mode variable which was set to zero but then
again programmed, so drop the supoerflous init.
Both in the subject line and here, typo
supoerflous ---> superfluous
By the way, not related to this issue:
I cherry-picked
https://patchwork.kernel.org/project/dri-devel/patch/20220424162633.12369-9-sam...@sholland.org/
and got a blank FB console on OPI3.
Can you check it please?
Regards,
Roman
вт, 24 мая 2022 г. в 20:10, Roman Stratiienko :
>
> Please draft a
Please draft a test for the zpos issue you're mentioning.
It's very easy to do with kmsxx using python wrapper.
Or explain steps to reproduce here, I will write it by myself.
Thanks.
Regards
Roman
вт, 24 мая 2022 г. в 19:21, Jernej Škrabec :
>
> Dne torek, 24. maj 2022 ob 17:31:13 CEST je Roman
On 5/23/22 8:14 AM, Icenowy Zheng wrote:
> 在 2022-05-22星期日的 10:36 +0200,Jernej Škrabec写道:
>> Hi!
>>
>> Dne sobota, 21. maj 2022 ob 15:34:43 CEST je Genfu Pan napisal(a):
>>> Accrording the SDK from Allwinner, the scanline value of yuv and
>>> rgb for
>>> V3s are both 1024.
>>
>> s/scanline value/sc
Dne torek, 24. maj 2022 ob 17:31:13 CEST je Roman Stratiienko napisal(a):
> NAK for this. Further testing showed such an approach is not reliable
> due to .atomic_update() callback called only in case planes have some
> changes.
Additionally, I think it would be better to fix underlaying zpos issu
On 5/24/22 02:26, Stephen Rothwell wrote:
> Hi all,
>
> Note: please do not add any v5.20 material to your linux-next included
> branches until after v5.19-rc1 has been related.
>
> Changes since 20220523:
>
on i386:
drivers/gpu/drm/i915/display/intel_backlight.o: in function
`intel_backlig
On Tue, May 24, 2022 at 11:36:22AM +0200, Hans de Goede wrote:
> Hi,
>
> On 5/23/22 13:54, Sebastian Wick wrote:
> > On Mon, May 23, 2022 at 10:23 AM Pekka Paalanen wrote:
> >>
> >> On Fri, 20 May 2022 17:20:50 +0200
> >> Hans de Goede wrote:
> >>
> >>> I got pointed to this thread by Jonas Ådah
NAK for this. Further testing showed such an approach is not reliable
due to .atomic_update() callback called only in case planes have some
changes.
вт, 24 мая 2022 г. в 16:52, Roman Stratiienko :
>
> Corruption happens when plane zpos is updated
>
> Example scenario:
>
> Initial frame blender sta
Acked-by: Alyssa Rosenzweig
On Tue, May 24, 2022 at 6:45 AM Tvrtko Ursulin
wrote:
>
> On 23/05/2022 23:53, Rob Clark wrote:
> >
> > btw, one fun (but unrelated) issue I'm hitting with scheduler... I'm
> > trying to add an igt test to stress shrinker/eviction, similar to the
> > existing tests/i915/gem_shrink.c. But we hit a
On Tue, May 24, 2022 at 6:45 AM Tvrtko Ursulin
wrote:
>
>
> On 23/05/2022 23:53, Rob Clark wrote:
> > On Mon, May 23, 2022 at 7:45 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> Hi Rob,
> >>
> >> On 28/07/2021 02:06, Rob Clark wrote:
> >>> From: Rob Clark
> >>>
> >>> The drm/scheduler provides addi
Hi Dave & Daniel -
Some i915 fixes for v5.19 merge window.
drm-intel-next-fixes-2022-05-24:
drm/i915 fixes for v5.19 merge window:
- Build, sparse, UB, and CFI fixes
- Variable scope fix
- Audio pipe logging fix
- ICL+ DSI NULL dereference fix
BR,
Jani.
The following changes since commit f834
Corruption happens when plane zpos is updated
Example scenario:
Initial frame blender state:
PLANE_ZPOS = {0, 1, 2, 3}
BLD_ROUTE = {0, 1, 2, 0}
BLD_EN = {1, 1, 1, 0}
New frame commit (Only ZPOS has been changed):
PLANE_ZPOS = {0->2, 1->0, 2->1, 3}
Expected results after pl
On 23/05/2022 23:53, Rob Clark wrote:
On Mon, May 23, 2022 at 7:45 AM Tvrtko Ursulin
wrote:
Hi Rob,
On 28/07/2021 02:06, Rob Clark wrote:
From: Rob Clark
The drm/scheduler provides additional prioritization on top of that
provided by however many number of ringbuffers (each with their o
On Tue, 24 May 2022, Andrzej Hajda wrote:
> On 24.05.2022 12:39, Jani Nikula wrote:
>> Add drm_edid based block count and data access helper functions that
>> take the EDID allocated size into account.
>>
>> At the moment, the allocated size should always match the EDID size
>> indicated by the e
On 24.05.2022 12:39, Jani Nikula wrote:
Add drm_edid based block count and data access helper functions that
take the EDID allocated size into account.
At the moment, the allocated size should always match the EDID size
indicated by the extension count, but this will change in the future.
Signe
>-Original Message-
>From: dri-devel On Behalf Of
>Vinod Koul
>Sent: Tuesday, May 24, 2022 6:36 AM
>To: Dmitry Baryshkov
>Cc: Liu, Yujie ; linux-arm-...@vger.kernel.org; Abhinav
>Kumar ; dri-devel@lists.freedesktop.org; Bjorn
>Andersson ; Vinod Koul ;
>freedr...@lists.freedesktop.org
>
On Tue, 24 May 2022 at 13:35, Vinod Koul wrote:
>
> Commit 58dca9810749 ("drm/msm/disp/dpu1: Add support for DSC in
> encoder") added dsc_common_mode variable which was set to zero but then
> again programmed, so drop the supoerflous init.
>
> Fixes: 58dca9810749 ("drm/msm/disp/dpu1: Add support f
On Sat, 21 May 2022, Julia Lawall wrote:
> Spelling mistakes (triple letters) in comments.
> Detected with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
Thanks, pushed to drm-intel-next.
BR,
Jani.
>
> ---
> drivers/gpu/drm/i915/display/intel_color.c |2 +-
> drivers/gp
We need to stop duplicating EDID validation and parsing all over the
subsystem in various broken ways.
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
Documentation/gpu/todo.rst | 25 +
1 file changed, 25 insertions(+)
diff --git a/Documentation/gpu/t
Take the HF-EEODB extension count override into account.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ba0c880dc133..6b1284b895eb 100644
--- a/drivers/gpu/
HDMI 2.1 section 10.3.6 defines an HDMI Forum EDID Extension Override
Data Block, which may contain a different extension count than the base
block claims. Add support for reading more EDID data if available. The
extra blocks aren't parsed yet, though.
Signed-off-by: Jani Nikula
---
drivers/gpu/
Rewrite edid_filter_invalid_blocks() to filter invalid blocks
in-place. The main motivation is to not rely on passed in information on
invalid block count or the allocation size, which will be helpful in
follow-up work on HF-EEODB.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 43 +
Convert all the connectors that use cached connector edid and
detect_edid to drm_edid.
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_connector.c| 4 +-
.../drm/i915/display/intel_display_types.h| 4 +-
drivers/gpu/drm/i915/display/intel_dp.c | 72 ++---
Unfortunately, there are still plenty of interfaces around that require
a struct edid pointer, and it's impossible to change them all at
once. Add an accessor to the raw EDID data to help the transition.
While there are no such cases now, be defensive against raw EDID
extension count indicating bi
Add a hook for custom .get_edid() when .get_modes() is not set.
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_probe_helper.c | 11 +--
include/drm/drm_modeset_helper_vtables.h | 21 ++---
2 files changed, 27 insertions(+), 5
Add default action when .get_modes() not set. This also defines what a
.get_modes() hook should do.
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_probe_helper.c | 14 +-
include/drm/drm_modeset_helper_vtables.h | 4
2 files change
Abstract the .get_modes() connector helper call, including the
override/firmware EDID fallback, to make it easier to extend it.
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_probe_helper.c | 29 +++--
1 file changed, 19 insertions
Add a new function drm_edid_connector_update() to replace the
combination of calls drm_connector_update_edid_property() and
drm_add_edid_modes(). Usually they are called in the drivers in this
order, however the former needs information from the latter.
This is all in drm_edid.c simply to keep str
Add new functions drm_edid_read(), drm_edid_read_ddc(), and
drm_edid_read_custom() to replace drm_get_edid() and drm_do_get_edid()
for reading the EDID. The transition is expected to happen over a fairly
long time.
Note that the new drm_edid_read*() functions do not do any of the
connector updates
We'll want to return the allocated buffer size in the future. Keep track
of it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index
Add drm_edid based block count and data access helper functions that
take the EDID allocated size into account.
At the moment, the allocated size should always match the EDID size
indicated by the extension count, but this will change in the future.
Signed-off-by: Jani Nikula
---
drivers/gpu/dr
Hey all, I'm adding a bunch of people to the cover letter, sorry for the
noise.
I've been putting a lot of effort lately into cleaning up our EDID
parsing. It's been long overdue. Here, we finally leverage all that prep
work to implement the HDMI Forum HF-EEODB extension. In short, HF-EEODB
lets a
On 23.05.2022 09:51, Balasubramani Vivekanandan wrote:
ADL-N being a subplatform of ADL-P, it lacks support for hwconfig
table. Explicit check added to skip ADL-N.
Signed-off-by: Balasubramani Vivekanandan
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/gt/uc/intel_g
Commit 58dca9810749 ("drm/msm/disp/dpu1: Add support for DSC in
encoder") added dsc_common_mode variable which was set to zero but then
again programmed, so drop the supoerflous init.
Fixes: 58dca9810749 ("drm/msm/disp/dpu1: Add support for DSC in encoder")
Reported-by: kernel test robot
Signed-o
On 20/05/2022 01:52, Zanoni, Paulo R wrote:
On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote:
VM_BIND design document with description of intended use cases.
v2: Add more documentation and format as per review comments
from Daniel.
Signed-off-by: Niranjana Vishwanathapur
From: Tvrtko Ursulin
Catch and log any garbage in the register, including no tiles marked, or
multiple tiles marked.
Signed-off-by: Tvrtko Ursulin
Cc: Matt Roper
---
We caught garbage in DG1_MSTR_TILE_INTR with DG2 (actual value 0xF9D2C008)
during glmark and more badness. So I thought lets log
Hi,
On 5/23/22 13:54, Sebastian Wick wrote:
> On Mon, May 23, 2022 at 10:23 AM Pekka Paalanen wrote:
>>
>> On Fri, 20 May 2022 17:20:50 +0200
>> Hans de Goede wrote:
>>
>>> I got pointed to this thread by Jonas Ådahl while asking some questions
>>> the "max bpc" property related to:
>>>
>>> http
On 20/05/2022 21:42, Matt Roper wrote:
On Fri, May 20, 2022 at 10:15:32AM +0100, Tvrtko Ursulin wrote:
On 17/05/2022 04:20, Matt Roper wrote:
Slice/subslice/EU information should be obtained via the topology
queries provided by the I915_QUERY interface; let's turn off support for
the old GET
Fix the following W=1 kernel warnings:
drivers/gpu/drm/i915/gvt/handlers.c:3066: warning: expecting prototype
for intel_t_default_mmio_write(). Prototype was for
intel_vgpu_default_mmio_write() instead.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/i915/gvt/handlers
Fix the following W=1 kernel warnings:
drivers/gpu/drm/i915/gvt/mmio_context.c:560: warning: expecting
prototype for intel_gvt_switch_render_mmio(). Prototype was for
intel_gvt_switch_mmio() instead.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/i915/gvt/mmio_contex
Eliminate the follow clang warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:544:33: warning: variable
‘mode’ set but not used [-Wunused-but-set-variable].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 --
1 file changed, 2 deletio
This symbol is not used outside of amdgpu_discovery.c, so marks it static.
Fixes the following w1 warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1364:5: warning: no
previous prototype for ‘amdgpu_discovery_get_mall_info’
[-Wmissing-prototypes].
Reported-by: Abaci Robot
Signed-off-by: Ji
From: Tvrtko Ursulin
Mention the compute engine which was recently added to the driver and also
clarify that userspace should be written in a forward compatible way.
Signed-off-by: Tvrtko Ursulin
---
Documentation/gpu/i915.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --
Am Dienstag, 24. Mai 2022, 09:29:43 CEST schrieb Marek Vasut:
> On 5/24/22 09:09, Alexander Stein wrote:
> > Hi Marek,
>
> Hi,
>
> > Am Donnerstag, 19. Mai 2022, 13:48:49 CEST schrieb Marek Vasut:
> >> Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is
> >> completely different
On 21/05/2022 00:04, Matt Roper wrote:
This series reworks i915's internal handling of slice/subslice/EU (SSEU)
data to represent platforms like Xe_HP in a more natural manner and to
prepare for future platforms where the masks will need to grow in size.
One key idea of this series is that alth
On 5/24/22 09:09, Alexander Stein wrote:
Hi Marek,
Hi,
Am Donnerstag, 19. Mai 2022, 13:48:49 CEST schrieb Marek Vasut:
Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is
completely different from the LCDIFv3 found in i.MX23 in that it has
a completely scrambled register lay
Hi,
On 5/24/22 01:25, Daniel Dadap wrote:
> On 5/20/22 16:41, Daniel Dadap wrote:
>>
>> On 5/17/22 10:23, Hans de Goede wrote:
>>> On x86/ACPI boards the acpi_video driver will usually initializing before
>>> the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
>>> to show up
Hi Marek,
Am Donnerstag, 19. Mai 2022, 13:48:49 CEST schrieb Marek Vasut:
> Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is
> completely different from the LCDIFv3 found in i.MX23 in that it has
> a completely scrambled register layout compared to all previous LCDIF
> variants
92 matches
Mail list logo