This series introduces the enabling patches for new memory compression
feature Flat CCS and 64k page support for i915 local memory, along with
documentation on the uAPI impact. Included the details of the feature and
the implications on the uAPI below. Which is also added into
Documentation/gpu/rfc
Thanks for this. It's really good to see this.
Reviewed-by: Harry Wentland
Harry
On 2021-12-09 09:20, Rodrigo Siqueira wrote:
> Display Core (DC) is one of the components under amdgpu, and it has
> multiple features directly related to the KMS API. Unfortunately, we
> don't have enough document
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 gpio_desc *alert_gpiod;
> + struct i2c_client *ara;
> +
> + alert_gpiod = devm_gpiod_get(i2c_dev->dev,
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.
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/display to
the beginning(Imre Deak)
- Removed unneeded case I915_FORM
On Wed, Dec 08, 2021 at 06:16:10AM +0100, jim.cro...@gmail.com wrote:
> are you planning to dust this patchset off and resubmit it ?
>
> Ive been playing with it and learning ftrace (decade+ late),
> I found your boot-line example very helpful as 1st steps
> (still havent even tried the filtering)
Hi Dave,
On Fri, 26 Nov 2021 at 14:56, Dave Stevenson
wrote:
>
> Hi Dmitry
>
> 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 initialized yet. Move the regulator enablement and bridge init to
> > te
From: Matthew Auld
If this is LMEM then we get a 32 entry PT, with each PTE pointing to
some 64K block of memory, otherwise it's just the usual 512 entry PT.
This very much assumes the caller knows what they are doing.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
Reviewed
From: Abdiel Janulgue
A portion of device memory is reserved for Flat CCS so usable
device memory will be reduced by size of Flat CCS. Size of
Flat CCS is specified in “XEHPSDV_FLAT_CCS_BASE_ADDR”.
So to get effective device memory we need to subtract
total device memory by Flat CCS memory size.
From: Matthew Auld
On some platforms we have alignment restrictions when accessing LMEM
from the GTT. In the next patch few patches we need to be able to modify
the page-tables directly via the GTT itself.
Suggested-by: Ramalingam C
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalin
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/2021 11:30 AM, Felix Kuehling wrote:
Am 2021-12-08 um 11:58 a.m. schrieb Felix Kuehling:
Am 2021-12-08
From: Mika Kahola
DG2 clear color render compression uses Tile4 layout. Therefore, we need
to define a new format modifier for uAPI to support clear color rendering.
Signed-off-by: Mika Kahola
cc: Anshuman Gupta
Signed-off-by: Juha-Pekka Heikkilä
Signed-off-by: Ramalingam C
---
drivers/gpu/
> -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
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
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
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: 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
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
[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
[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
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
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 +
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
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
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
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:
> > > >
> > >
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_
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
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
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
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
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
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 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
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
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 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
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 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:
> > >
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 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 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
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
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
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
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
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
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
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 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
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 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
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
> 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
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
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:
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:
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:
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:
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
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:
>
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:
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
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
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
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
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
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
'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
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,
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
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
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
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
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
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
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
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
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
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 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
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: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
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 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 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 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: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
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: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
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: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 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: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
>
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 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
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
101 - 200 of 212 matches
Mail list logo
