On Thu, Dec 09, 2021 at 09:15:24PM +0530, Ramalingam C wrote:
> From: Stanislav Lisovskiy
>
> Tile4 in bspec format is 4K tile organized into
> 64B subtiles with same basic shape as for legacy TileY
> which will be supported by Display13.
>
> v2: - Moved Tile4 associating struct for modifier/dis
On Thu, Dec 09, 2021 at 09:15:24PM +0530, Ramalingam C wrote:
> From: Stanislav Lisovskiy
>
> Tile4 in bspec format is 4K tile organized into
> 64B subtiles with same basic shape as for legacy TileY
> which will be supported by Display13.
>
> v2: - Moved Tile4 associating struct for modifier/dis
Hi,
> > The drivers are asic and platform specific. E.g., the driver for
> > vangogh is different from renoir is different from skylake, etc. The
> > display programming interfaces are asic specific.
>
> Cool, that makes sense! But if you (or anybody here) know some of these
> GOP drivers, e.
Am 09.12.21 um 19:28 schrieb Felix Kuehling:
Am 2021-12-09 um 10:30 a.m. schrieb Christian König:
That still won't work.
But I think we could do this change for the amdgpu mmap callback only.
If graphics user mode has problems with it, we could even make this
specific to KFD BOs in the amdgpu_
From: John Harrison
If the GuC has failed to load for any reason and then the user pokes
the debugfs GuC log interface, a BUG and/or null pointer deref can
occur. Don't let that happen.
Signed-off-by: John Harrison
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log_debu
From: John Harrison
Fix a potential null pointer dereference, improve debug crash reports,
improve code separation, improve GuC log read speed.
Signed-off-by: John Harrison
John Harrison (4):
drm/i915/uc: Allow platforms to have GuC but not HuC
drm/i915/guc: Speed up GuC log dumps
drm/
From: John Harrison
Lots of testing is done with the DEBUG_GEM config option enabled but
not the DEBUG_GUC option. That means we only get teeny-tiny GuC logs
which are not hugely useful. Enabling full DEBUG_GUC also spews lots
of other detailed output that is not generally desired. However,
bigge
From: John Harrison
Add support for telling the debugfs interface the size of the GuC log
dump in advance. Without that, the underlying framework keeps calling
the 'show' function with larger and larger buffer allocations until it
fits. That means reading the log from graphics memory many times -
From: John Harrison
It is possible for platforms to require GuC but not HuC firmware.
Also, the firmware versions for GuC and HuC advance independently. So
split the macros up to allow the lists to be maintained separately.
Signed-off-by: John Harrison
Reviewed-by: Lucas De Marchi
Reviewed-by:
Hi Linus,
Regular fixes, pretty small overall, couple of core fixes, two i915
and two amdgpu, hopefully it stays this quiet.
Regards,
Dave.
drm-fixes-2021-12-10:
drm fixes for 5.16-rc5
ttm:
- fix ttm_bo_swapout
syncobj:
- fix fence find bug with signalled fences
i915:
- fix error pointer dere
Hi Matt,
> > GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> > eventually want to get rid of the i915->ggtt one.
> > Use to_gt() for all i915->ggtt accesses to help with the future
> > refactoring.
>
> I think we can also convert the two references in i915_drm_suspend()
On Friday, 10 December 2021 3:54:31 AM AEDT Sierra Guiza, Alejandro (Alex)
wrote:
>
> On 12/9/2021 10:29 AM, Felix Kuehling wrote:
> > Am 2021-12-09 um 5:53 a.m. schrieb Alistair Popple:
> >> On Thursday, 9 December 2021 5:55:26 AM AEDT Sierra Guiza, Alejandro
> >> (Alex) wrote:
> >>> On 12/8/20
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Andi Shyti
---
Hi,
the inline of i915_dev_to_pxp() was accidentally removed in v6.
Thanks Matt.
Andi
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 4 +++-
1 file
On Fri, Dec 10, 2021 at 02:21:53AM +0200, Andi Shyti wrote:
> Hi Matt,
>
> > > -static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
> > > +static struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
> >
> > Was dropping the inline here intentional? It doesn't seem l
Hi Matt,
> > -static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
> > +static struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
>
> Was dropping the inline here intentional? It doesn't seem like there's
> any reason to drop it, and if it was intentional the white
On Thu, Dec 09, 2021 at 03:25:12PM +0200, Andi Shyti wrote:
> In preparation of the multitile support, highlight the root GT by
> calling it gt0 inside the drm i915 private data.
>
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Lucas De Marchi
> Cc: Rodrigo Vivi
>
On 10/12/2021 01:27, Abhinav Kumar wrote:
On 12/9/2021 2:18 PM, Abhinav Kumar wrote:
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
We are preparing to change DPU plane implementation. Move SSPP debugfs
code from dpu_plane.c to dpu_hw_sspp.c, where it belongs.
Signed-off-by: Dmitry Baryshko
On Thu, Dec 09, 2021 at 03:25:11PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Use to_gt() for all i915->ggtt accesses to help with the future
> refactoring.
I
On Thu, Dec 09, 2021 at 03:25:10PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> Use to_gt() helper consistently throughout the codebase.
> Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
>
> Signed-off-by: Michał Winiarski
> Signed-off-by: Andi Shyti
Reviewed-by: Matt
On Thu, Dec 09, 2021 at 03:25:09PM +0200, Andi Shyti wrote:
> Use to_gt() helper consistently throughout the codebase.
> Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
>
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 6 --
> 1 file changed, 4 i
Reviewed-by: Steve Cho
On Wed, Dec 1, 2021 at 7:46 PM Yunfei Dong wrote:
>
> Adds decoder dt-bindings for mt8192.
basic question: what is dt-bindings?
Is this yaml file supposed to be used for some settings?
>
> Signed-off-by: Yunfei Dong
> ---
> .../media/mediatek,vcodec-subdev-decoder.yam
On Thu, Dec 09, 2021 at 03:25:08PM +0200, Andi Shyti wrote:
> Use to_gt() helper consistently throughout the codebase.
> Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
>
> Signed-off-by: Andi Shyti
> Cc: Michał Winiarski
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/se
On Thu, Dec 09, 2021 at 03:25:07PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> Use to_gt() helper consistently throughout the codebase.
> Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
>
> Signed-off-by: Michał Winiarski
> Signed-off-by: Andi Shyti
Reviewed-by: Matt
On Thu, Dec 09, 2021 at 03:25:06PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> Use to_gt() helper consistently throughout the codebase.
> Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
>
> Signed-off-by: Michał Winiarski
> Signed-off-by: Andi Shyti
Reviewed-by: Matt
On Wed, Dec 1, 2021 at 7:46 PM Yunfei Dong wrote:
>
> Add work queue to process core hardware information.
> First, get lat_buf from message queue, then call core
> hardware of each codec(H264/VP9/AV1) to decode, finally
> puts lat_buf back to the message.
>
> Signed-off-by: Yunfei Dong
> ---
>
On Thu, Dec 09, 2021 at 05:20:45PM -0500, Harry Wentland wrote:
>
>
> On 2021-12-09 01:23, Kees Cook wrote:
> > On Wed, Dec 08, 2021 at 01:19:28PM +0200, Jani Nikula wrote:
> >> On Fri, 03 Dec 2021, Kees Cook wrote:
> >>> The link_status array was not large enough to read the Adjust Request
> >>
On Thu, Dec 09, 2021 at 03:25:05PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> Use to_gt() helper consistently throughout the codebase.
> Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
>
> Signed-off-by: Michał Winiarski
> Signed-off-by: Andi Shyti
Reviewed-by: Matt
Few comments and questions.
On Wed, Dec 1, 2021 at 7:46 PM Yunfei Dong wrote:
>
> There are more than two hardwares for decoder: LAT0, LAT1 and CORE. In order
> to
> manage these hardwares, register each hardware as independent platform device
> for the larbs are different.
basic question: what
On Thu, Dec 09, 2021 at 03:25:04PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> Use to_gt() helper consistently throughout the codebase.
> Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
>
> Signed-off-by: Michał Winiarski
> Signed-off-by: Andi Shyti
Reviewed-by: Matt
On Thu, Dec 09, 2021 at 03:25:03PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> To allow further refactoring and abstract away the fact that GT is
> stored inside i915 private.
> No functional changes.
>
> Signed-off-by: Michał Winiarski
> Signed-off-by: Andi Shyti
Reviewed-by: Matt
On 12/9/2021 2:18 PM, Abhinav Kumar wrote:
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
We are preparing to change DPU plane implementation. Move SSPP debugfs
code from dpu_plane.c to dpu_hw_sspp.c, where it belongs.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu
Hi all, I have a question about the possibility of reusing a framebuffer
after a regular (or panic) kexec - my case is with amdgpu (APU, aka, not
a separate GPU hardware), but I guess the question is kinda generic
hence I've looped most of the lists / people I think does make sense
(apologies for d
In line 1138 (#1), amdgpu_get_xgmi_hive() increases the kobject reference
counter of the hive it returned. The hive returned by
amdgpu_get_xgmi_hive()should be released with the help of
amdgpu_put_xgmi_hive() to balance its kobject reference counter properly.
Forgetting the amdgpu_put_xgmi_hive() o
On 09/12/2021 14:31, Alex Deucher wrote:
> [...]
> Once the driver takes over, none of the pre-driver state is retained.
> You'll need to load the driver in the new kernel to initialize the
> displays. Note the efifb doesn't actually have the ability to program
> any hardware, it just takes over
Thanks again Alex! Some comments inlined below:
On 09/12/2021 15:06, Alex Deucher wrote:
> Not really in a generic way. It's asic and platform specific. In
> addition most modern displays require link training to bring up the
> display, so you can't just save and restore registers.
Oh sure, I u
Ping. I see that a v4 has been sent out without these comments being addressed.
-Nanley
On Tue, Dec 7, 2021 at 6:51 PM Nanley Chery wrote:
>
> Hi Ramalingam,
>
> On Wed, Oct 27, 2021 at 5:22 PM Ramalingam C wrote:
> >
> > From: Matt Roper
> >
> > DG2 unifies render compression and media compre
syzbot has found a reproducer for the following issue on:
HEAD commit:2a987e65025e Merge tag 'perf-tools-fixes-for-v5.16-2021-12..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12f8fdc5b0
kernel config: https://syzkaller.appspot.com/x/.config?x=7d5e878
On 2021-12-09 01:23, Kees Cook wrote:
> On Wed, Dec 08, 2021 at 01:19:28PM +0200, Jani Nikula wrote:
>> On Fri, 03 Dec 2021, Kees Cook wrote:
>>> The link_status array was not large enough to read the Adjust Request
>>> Post Cursor2 register. Adjust the size to include it. Found with a
>>> -War
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
We are preparing to change DPU plane implementation. Move SSPP debugfs
code from dpu_plane.c to dpu_hw_sspp.c, where it belongs.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 67 +
drivers/gp
By default, GT (and GuC) run at RPn. Requesting for RP0
before firmware load can speed up DMA and HuC auth as well.
In addition to writing to 0xA008, we also need to enable
swreq in 0xA024 so that Punit will pay heed to our request.
SLPC will restore the frequency back to RPn after initialization,
'bufs' is an array embedded in an structure (struct drm_device_dma) which
is kzalloc just a few lines above.
So there is no need to explicitly memset each element on the array. It is
already cleared.
Remove the useless memset.
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/drm_dma.c | 5
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
Squash dpu_debugfs_setup_regset32() into dpu_debugfs_create_regset32().
it makes little sense to have separate function to just setup the
structure.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1
Panel is 800x1280, but mounted on a laptop form factor, sideways.
Signed-off-by: Anisse Astier
Reviewed-by: Hans de Goede
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/dr
The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
used for the embedded display. Add support for using it via by adding
the EDID to the list of available modes on the connector, and use it for
eDP when available.
If a panel's EDID is broken, there may be an override EDID set in
This patch series is for making the GPD Win Max display usable with
Linux.
The GPD Win Max is a small laptop, and its eDP panel does not send an
EDID over DPCD; the EDID is instead available in the intel opregion, in
mailbox #5 [1]
The second patch is just to fix the orientation of the panel.
Ch
On Thu, Dec 02, 2021 at 07:39:45PM +0100, H. Nikolaus Schaller wrote:
> [..]
> This series adds HDMI support for JZ4780 and CI20 board
>
>
>
> H. Nikolaus Schaller (3):
> drm/ingenic: prepare ingenic drm for later addition of JZ4780
> MIPS: defconfig: CI20: configure for DRM_DW_HDMI_JZ4780
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and limited code scalability.
This patch divides the driver life cycle of operation into four states,
resume (including
Add checking aux read/write status at both dp_link_parse_sink_count()
and dp_link_parse_sink_status_filed() to avoid long timeout delay if
dp aux read/write failed at timeout due to cable unplugged. Also make
sure dp controller had been initialized before start dpcd read and write.
Changes in V4:
Hi
On Thu, Dec 9, 2021 at 9:24 PM Lucas Stach wrote:
>
> Am Donnerstag, dem 09.12.2021 um 18:09 +0100 schrieb Michael Nazzareno
> Trimarchi:
> > Hi Tim
> >
> > On Thu, Dec 9, 2021 at 5:40 PM Tim Harvey wrote:
> > >
> > > On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi
> > > wrote:
>
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
DRM code handles removing all debugfs recursively. Drop CRTC-specific
code to perform that.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 15 ---
drivers/gpu/drm/msm/di
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
DRM code handles removing all debugfs recursively. Drop plane-specific
code to perform that.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 28 ---
1 file chang
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
Proper support for the 'default_scaling' debugfs file was removed during
DPU driver pre-merge cleanup. Remove leftover file.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 5 -
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
Change \t to \n in the print format to stop putting all SSPP status in a
single line. Splitting it to one SSPP per line is much more readable.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_k
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
Make safe_status debugfs fs file actually return safe status rather than
danger status data.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
The disable_danger debugfs file is not related to a single plane.
Instead it is used by all registered planes. Move it from plane subtree
to the global subtree next to danger_status and safe_status files,
so that the new file supplements them.
the
> Thanks for this. It's really good to see this.
>
> Reviewed-by: Harry Wentland
Hearfully seconded, let's get this rolling :)
Reviewed-by: Yann Dirson
>
> Harry
>
> On 2021-12-09 09:20, Rodrigo Siqueira wrote:
> > Display Core (DC) is one of the components under amdgpu, and it has
> > mu
Am Donnerstag, dem 09.12.2021 um 18:09 +0100 schrieb Michael Nazzareno
Trimarchi:
> Hi Tim
>
> On Thu, Dec 9, 2021 at 5:40 PM Tim Harvey wrote:
> >
> > On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi
> > wrote:
> > >
> > > Hi Tim
> > >
> > > On Tue, Oct 5, 2021 at 11:43 PM Tim Har
On 12/9/2021 11:57 AM, Matthew Brost wrote:
On Thu, Dec 09, 2021 at 11:26:09AM -0800, Daniele Ceraolo Spurio wrote:
On 12/9/2021 10:51 AM, Matthew Brost wrote:
A full GT can race with the last context put resulting in the context
forgot to mention earlier but you're missing "reset" here
On Thu, Dec 09, 2021 at 11:26:09AM -0800, Daniele Ceraolo Spurio wrote:
>
>
> On 12/9/2021 10:51 AM, Matthew Brost wrote:
> > A full GT can race with the last context put resulting in the context
> > ref count being zero but the destroyed bit not yet being set. Remove
> > GEM_BUG_ON in scrub_guc_
On 12/9/2021 10:51 AM, Matthew Brost wrote:
A full GT can race with the last context put resulting in the context
ref count being zero but the destroyed bit not yet being set. Remove
GEM_BUG_ON in scrub_guc_desc_for_outstanding_g2h that asserts the
destroyed bit must be set in ref count is zer
From: Rob Clark
I am seeing some crash logs which imply that we are trying to use
crashdumper hw to read back GPU state when the GPU isn't initialized.
This doesn't go well (for example, GPU could be in 32b address mode
and ignoring the upper bits of buffer that it is trying to dump state
to).
I
On Thu, Dec 9, 2021 at 1:18 PM Guilherme G. Piccoli wrote:
>
> Thanks again Alex! Some comments inlined below:
>
> On 09/12/2021 15:06, Alex Deucher wrote:
> > Not really in a generic way. It's asic and platform specific. In
> > addition most modern displays require link training to bring up the
On 12/9/2021 10:48 AM, Matthew Brost wrote:
s/ce/cn/ when grabbing guc_state.lock before calling
clr_context_registered.
Fixes: 0f7976506de61 ("drm/i915/guc: Rework and simplify locking")
Signed-off-by: Matthew Brost
Cc:
Reviewed-by: Daniele Ceraolo Spurio
I'm assuming we didn't see any
Hi Dave and Daniel,
Here goes drm-intel-fixes-2021-12-09:
A fix to a error pointer dereference in gem_execbuffer and
a fix for GT initialization when GuC/HuC are used on ICL.
Thanks,
Rodrigo.
The following changes since commit 0fcfb00b28c0b7884635dacf38e46d60bf3d4eb1:
Linux 5.16-rc4 (2021-12
A full GT can race with the last context put resulting in the context
ref count being zero but the destroyed bit not yet being set. Remove
GEM_BUG_ON in scrub_guc_desc_for_outstanding_g2h that asserts the
destroyed bit must be set in ref count is zero.
Signed-off-by: Matthew Brost
---
drivers/gp
s/ce/cn/ when grabbing guc_state.lock before calling
clr_context_registered.
Fixes: 0f7976506de61 ("drm/i915/guc: Rework and simplify locking")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Am 2021-12-09 um 10:30 a.m. schrieb Christian König:
> That still won't work.
>
> But I think we could do this change for the amdgpu mmap callback only.
If graphics user mode has problems with it, we could even make this
specific to KFD BOs in the amdgpu_gem_object_mmap callback.
Regards,
Felix
Hi Dave
On Thu, Dec 9, 2021 at 6:58 PM Dave Stevenson
wrote:
>
> Hi Michael
>
> On Thu, 9 Dec 2021 at 16:58, Michael Nazzareno Trimarchi
> wrote:
> >
> > Hi all
> >
> > On Sat, Oct 16, 2021 at 4:58 PM Michael Trimarchi
> > wrote:
> > >
> > > All the panel driver check the fact that their prepar
On Thu, Dec 9, 2021 at 1:00 PM Guilherme G. Piccoli wrote:
>
> On 09/12/2021 14:31, Alex Deucher wrote:
> > [...]
> > Once the driver takes over, none of the pre-driver state is retained.
> > You'll need to load the driver in the new kernel to initialize the
> > displays. Note the efifb doesn't a
Hi Michael
On Thu, 9 Dec 2021 at 16:58, Michael Nazzareno Trimarchi
wrote:
>
> Hi all
>
> On Sat, Oct 16, 2021 at 4:58 PM Michael Trimarchi
> wrote:
> >
> > All the panel driver check the fact that their prepare/unprepare
> > call was already called. It's not an ideal solution but fix
> > for no
On Thu, Dec 9, 2021 at 9:09 AM Michael Nazzareno Trimarchi
wrote:
>
> Hi Tim
>
> On Thu, Dec 9, 2021 at 5:40 PM Tim Harvey wrote:
> >
> > On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi
> > wrote:
> > >
> > > Hi Tim
> > >
> > > On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey wrote:
> > >
On 08/12/2021 08:22, Thomas Hellström wrote:
When updating the error capture code and introducing vma snapshots,
we introduced code to hold the vma in memory while capturing it,
calling i915_active_acquire_if_busy(). Now that function isn't relevant
for perma-pinned vmas and caused important vmas
On Wed, Dec 8, 2021 at 7:16 PM Chun-Kuang Hu wrote:
>
> Hi Mark:
>
> Mark Yacoub 於 2021年10月28日 週四 上午12:28寫道：
> >
> > From: Mark Yacoub
> >
> > At the reset hook, call __drm_atomic_helper_plane_reset which is
> > called at the initialization of the plane and sets the default value of
> > rotation
Hi Rob and Laurent,
On Wed, Dec 8, 2021 at 11:56 AM Jagan Teki wrote:
>
> On Wed, Dec 8, 2021 at 2:20 AM Rob Herring wrote:
> >
> > On Mon, Dec 6, 2021 at 11:49 PM Jagan Teki
> > wrote:
> > >
> > > Add of_get_non_port_child() helper that can be used to lookup
> > > non port child nodes.
> > >
On Thu, Dec 9, 2021 at 12:04 PM Guilherme G. Piccoli
wrote:
>
> Hi all, I have a question about the possibility of reusing a framebuffer
> after a regular (or panic) kexec - my case is with amdgpu (APU, aka, not
> a separate GPU hardware), but I guess the question is kinda generic
> hence I've loo
On 09/12/2021 14:13, Thomas Hellström wrote:
When we recently converted the capture code to use vma snapshots,
we forgot to free the struct i915_capture_list list items after use.
Fix that by bringing back a kfree.
Fixes: ff20afc4cee7 ("drm/i915: Update error capture code to avoid using the cur
Hi Jani,
thanks for looking at it.
> > - intel_gt_init_early(&dev_priv->gt, dev_priv);
> > + __intel_gt_init_early(&dev_priv->gt, dev_priv);
>
> Why double underscores here? It looks like it's supposed to be internal
> to intel_gt, not to be called by anyone else.
I forgot to write two line
On 12/9/2021 06:41, Robert Beckett wrote:
On 09/12/2021 00:24, John Harrison wrote:
On 12/8/2021 09:58, Robert Beckett wrote:
On 07/12/2021 23:15, John Harrison wrote:
On 12/7/2021 09:53, Adrian Larumbe wrote:
Beginning with DG2, all successive devices will require GuC FW to be
present and lo
On Thu, 09 Dec 2021, Andi Shyti wrote:
> From: Michał Winiarski
>
> We now support a per-gt uncore, yet we're not able to infer which GT
> we're operating upon. Let's store a backpointer for now.
>
> Signed-off-by: Michał Winiarski
> Signed-off-by: Matt Roper
> Reviewed-by: Andi Shyti
> Signe
Hi Tim
On Thu, Dec 9, 2021 at 5:40 PM Tim Harvey wrote:
>
> On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi
> wrote:
> >
> > Hi Tim
> >
> > On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey wrote:
> > >
> > > On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki
> > > wrote:
> > > >
> > > > Hi Sam
Hi Dmitry,
(CC'ing Tomi)
On Thu, Dec 09, 2021 at 07:53:43PM +0300, Dmitry Baryshkov wrote:
> On Fri, 26 Nov 2021 at 14:56, Dave Stevenson wrote:
> > On Fri, 26 Nov 2021 at 00:32, Dmitry Baryshkov wrote:
> > >
> > > During the pre_enable time the previous bridge (e.g. DSI host) might be
> > > not
Il 02/10/21 00:33, Dmitry Baryshkov ha scritto:
On 11/09/2021 19:39, AngeloGioacchino Del Regno wrote:
In function dpu_encoder_phys_cmd_wait_for_commit_done we are always
checking if the relative CTL is started by waiting for an interrupt
to fire: it is fine to do that, but then sometimes we cal
Documents the Flat-CCS feature and kernel handling required along with
modifiers used.
Signed-off-by: Ramalingam C
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
---
drivers/gpu/drm/i915/gt/intel_
On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi
wrote:
>
> Hi Tim
>
> On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey wrote:
> >
> > On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki
> > wrote:
> > >
> > > Hi Sam,
> > >
> > > On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg wrote:
> > > >
> > >
09.12.2021 18:05, Akhil R пишет:
> Add support for SMBus Alert and SMBus block read functions to
> i2c-tegra driver
>
> Akhil R (2):
> dt-bindings: i2c: tegra: Add SMBus feature properties
> i2c: tegra: Add SMBus block read and SMBus alert functions
>
> .../devicetree/bindings/i2c/nvidia,teg
From: Ayaz A Siddiqui
Xe-HP and latest devices support Flat CCS which reserved a portion of
the device memory to store compression metadata, during the clearing of
device memory buffer object we also need to clear the associated
CCS buffer.
Flat CCS memory can not be directly accessed by S/W.
Ad
Use i2c_timings struct and corresponding methods to get bus clock frequency
Signed-off-by: Akhil R
Suggested-by: Andy Shevchenko
Reviewed-by: Andy Shevchenko
---
drivers/i2c/busses/i2c-tegra.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
v1->v2: Added temp var f
Am 2021-12-09 um 5:53 a.m. schrieb Alistair Popple:
> On Thursday, 9 December 2021 5:55:26 AM AEDT Sierra Guiza, Alejandro (Alex)
> wrote:
>> On 12/8/2021 11:30 AM, Felix Kuehling wrote:
>>> Am 2021-12-08 um 11:58 a.m. schrieb Felix Kuehling:
Am 2021-12-08 um 6:31 a.m. schrieb Alistair Popple
Hi Jagan,
On Thu, Dec 09, 2021 at 12:34:49PM +0530, Jagan Teki wrote:
> On Thu, Nov 18, 2021 at 2:50 PM Alexander Stein wrote:
> >
> > VCC needs to be enabled before releasing the enable GPIO.
> >
> > Signed-off-by: Alexander Stein
> > ---
> > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 19 +
On 2021-12-08 at 19:46:09 +0530, Ramalingam C wrote:
> Preparational patches for 64k page support.
Thanks for the review. Merged these patches.
Ram.
>
> Matthew Auld (3):
> drm/i915/xehpsdv: set min page-size to 64K
> drm/i915/gtt/xehpsdv: move scratch page to system memory
> drm/i915: enf
[AMD Official Use Only]
Hi Matthew,
Ping on this?
Regards,
Arun
-Original Message-
From: amd-gfx On Behalf Of Arunpravin
Sent: Wednesday, December 1, 2021 10:10 PM
To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org;
amd-...@lists.freedesktop.org
Cc: dan...@ffwll.ch; P
[Public]
Hi Matthew,
Ping?
Regards,
Arun
-Original Message-
From: Paneer Selvam, Arunpravin
Sent: Wednesday, December 1, 2021 10:10 PM
To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org;
amd-...@lists.freedesktop.org
Cc: matthew.a...@intel.com; dan...@ffwll.ch; Koeni
09.12.2021 18:33, Andy Shevchenko пишет:
> On Thu, Dec 9, 2021 at 5:30 PM Dmitry Osipenko wrote:
>> 09.12.2021 18:05, Akhil R пишет:
>>> +static int tegra_i2c_setup_smbalert(struct tegra_i2c_dev *i2c_dev)
>>> +{
>>> + struct tegra_i2c_smbalert *smbalert = &i2c_dev->smbalert;
>>> + struct g
From: Matthew Auld
XEHPSDV optimises 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no longer sup
From: Michel Dänzer
Move code using the Pipe struct to a new helper function.
Works around[0] this warning (resulting in failure to build a RHEL debug
kernel with Werror enabled):
../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c: In
function ‘dml31_ModeSupportAndSyst
From: Matt Roper
DG2 unifies render compression and media compression into a single
format for the first time. The programming and buffer layout is
supposed to match compression on older gen12 platforms, but the actual
compression algorithm is different from any previous platform; as such,
we ne
From: Chris Wilson
As we setup the memory regions for the device, give each a quick test to
verify that we can read and write to the full iomem range. This ensures
that our physical addressing for the device's memory is correct, and
some reassurance that the memory is functional.
v2: wrapper for
On Thu, Dec 9, 2021 at 5:05 PM Akhil R wrote:
>
> Tegra I2C can use a gpio as an smbus-alert. Document the usage of
> the same.
...
> +optional properties:
Optional
> +- smbalert-gpio: Must contain an entry for the gpio to be used as smbus
> alert.
-gpios (the suffix in plural form, the sing
> -Original Message-
> From: Lisovskiy, Stanislav
> Sent: Thursday, December 9, 2021 5:47 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Lisovskiy, Stanislav
> ; Saarinen, Jani ; C,
> Ramalingam ; ville.syrj...@linux.intel.com; Deak,
> Imre ; Chery, Nanl
From: Anshuman Gupta
DG2 onwards discrete gfx has support for new flat CCS mapping,
which brings in display feature in to avoid Aux walk for compressed
surface. This support build on top of Flat CCS support added in XEHPSDV.
FLAT CCS surface base address should be 64k aligned,
Compressed displaya
1 - 100 of 212 matches
Mail list logo
