When list_for_each_entry() completes the iteration over the whole list
without breaking the loop, the iterator value will be a bogus pointer
computed based on the head element.
While it is safe to use the pointer to determine if it was computed
based on the head element with &pos->member == head,
While working at fixing powerpc headers, I ended up with the
following error.
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c:48:1: error:
conflicting types for 'prom_init'; have 'void *(struct nvkm_bios *, const char
*)'
make[5]: *** [scripts/Makefile.build:288:
drivers/gp
On 19.03.2022 00:39, Andi Shyti wrote:
> From: Tvrtko Ursulin
>
> On a multi-tile platform, each tile has its own registers + GGTT
> space, and BAR 0 is extended to cover all of them.
>
> Up to four GTs are supported in i915->gt[], with slot zero
> shadowing the existing i915->gt0 to enable s
On Mon, 14 Mar 2022 15:16:29 +0100
Uwe Kleine-König wrote:
> When a driver keeps a clock prepared (or enabled) during the whole
> lifetime of the driver, these helpers allow to simplify the drivers.
>
> Reviewed-by: Jonathan Cameron
> Reviewed-by: Alexandru Ardelean
> Signed-off-by: Uw
Alvin Šipraga writes:
> From: Alvin Šipraga
>
> The patches are sent against drm-misc-next. Thanks!
Whoops, I meant drm-misc-fixes, since these are fixes. :-)
Separate patches aimed at drm-misc-next incoming.
>
> Alvin Šipraga (2):
> drm: bridge: adv7511: fix CEC power down control register
From: Alvin Šipraga
The ADV7511 family of bridges supports two modes for CEC RX: legacy and
non-legacy mode. The only difference is whether the chip uses a single
CEC RX buffer, or uses all three available RX buffers. Currently the
adv7511 driver uses legacy mode.
While debugging a stall in CEC
From: Alvin Šipraga
The ADV7511_REG_CEC_CTRL = 0xE2 register is part of the main register
map - not the CEC register map. As such, we shouldn't apply an offset to
the register address. Doing so will cause us to address a bogus register
for chips with a CEC register map offset (e.g. ADV7533).
Fix
From: Alvin Šipraga
The patches are sent against drm-misc-next. Thanks!
Alvin Šipraga (2):
drm: bridge: adv7511: fix CEC power down control register offset
drm: bridge: adv7511: unregister cec i2c device after cec adapter
drivers/gpu/drm/bridge/adv7511/adv7511.h | 5 +
drivers/gpu/
From: Alvin Šipraga
cec_unregister_adapter() assumes that the underlying adapter ops are
callable. For example, if the CEC adapter currently has a valid physical
address, then the unregistration procedure will invalidate the physical
address by setting it to f.f.f.f. Whence the following kernel o
From: Alvin Šipraga
Like the ADV7533, the ADV7535 has an offset for the CEC register map,
and it is the same value (ADV7533_REG_CEC_OFFSET = 0x70).
Rather than testing for numerous chip types in the offset calculations
throughout the driver, just compute it during driver probe and put it in
the
From: Alvin Šipraga
We have an ADV7535 which is nominally supported by this driver. These
two patches fix up the driver to get CEC working too.
The first adds the basic support by correcting some register offsets.
The second addresses an issue we saw with CEC RX on the ADV7535. It
hasn't been t
On Fri, Mar 18, 2022 at 4:49 PM Guillaume Ranquet wrote:
>
> From: Jitao Shi
>
> Implement the DP HDP debounce described in DP 1.4a 3.3.
>
> Signed-off-by: Jitao Shi
> Signed-off-by: Guillaume Ranquet
Agree with Rex. The code is fine but I suggest including Rex's info in
the commit message for
r_ovl is NULL but dereferenced
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/omapdrm/omap_overlay.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_overlay.c
b/drivers/gpu/drm/omapdrm/omap_overlay.c
index 10730c9..d09aaf6 100644
--- a/drivers/gpu/drm/omapdrm/omap
From: Alvin Šipraga
The adv7511 driver is solely responsible for setting the physical
address of its CEC adapter. To do this, it must read the EDID. However,
EDID is only read when either the drm_bridge_funcs :: get_edid or
drm_connector_helper_funcs :: get_modes ops are called. Without loss of
g
Previous concern with using drm_clflush_sg was that we don't know what the
sg_table is pointing to, thus the usage of wbinvd_on_all_cpus to flush
everything at once to avoid paranoia.
To make i915 more architecture-neutral and be less paranoid, lets attempt to
use drm_clflush_sg to flush the pages
To align with the discussion in [1][2], this patch series drops all usage of
wbvind_on_all_cpus within i915 by either replacing the call with certain
drm clflush helpers, or reverting to a previous logic.
[1]. https://lists.freedesktop.org/archives/dri-devel/2021-November/330928.html
[2]. https://
As we are making i915 more architecture-neutral, lets revert this commit
to the previous logic [1] to avoid using wbinvd_on_all_cpus.
[1]. ac05a22cd07a ("drm/i915/gem: Almagamate clflushes on suspend")
Suggested-by: Lucas De Marchi
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gem/i915
This patch reverts i915_gem_freeze to previous logic [1] to avoid using
wbinvd_on_all_cpus.
[1]. https://patchwork.freedesktop.org/patch/415007/?series=86058&rev=2
Suggested-by: Lucas De Marchi
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 15 ++-
1 file
To avoid having to call wbinvd_on_all_cpus, revert i915_ggtt_resume and
i915_ggtt_resume_vm to previous logic [1].
[1]. 64b95df91f44 drm/i915: Assume exclusive access to objects inside resume
Suggested-by: Lucas De Marchi
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_ggtt.c |
On Xe-HP and later devices, we use dedicated compression control
state (CCS) stored in local memory for each surface, to support
the 3D and media compression formats.
The memory required for the CCS of the entire local memory is
1/256 of the local memory size. So before the kernel
boot, the requir
XY_FAST_COLOR_BLT cmd is faster than the older XY_COLOR_BLT. Hence for
clearing (Zero out) the pages of the newly allocated object, faster cmd
is used.
Signed-off-by: Ramalingam C
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 5 +++
drivers/gpu/drm/i915/gt/inte
At obj allocation size could be rounded up by min_page_size. So please
update the size as per the obj size allocated.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/selftest_migrate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c
b/dr
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.
XY_CTRL_SURF_COPY_BLT is a BLT cmd used for reading and writing the
ccs surface
Move the static calculations out of the loop.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 34 -
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
While clearing the Flat-CCS capable lmem object, we need to clear the CCS
meta data corresponding to the memory.
As part of live_migrate_clear add check for the ccs meta data clear for
the Flat-CCS capable lmem object.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c|
Add a parameter called "extra_pages" for ttm_tt_init, to indicate that
driver needs extra pages in ttm_tt.
v2:
Used imperative wording [Thomas and Christian]
Signed-off-by: Ramalingam C
cc: Christian Koenig
cc: Hellstrom Thomas
Reviewed-by: Thomas Hellstrom
Reviewed-by: Christian Konig
---
On Xe-HP and later devices, dedicated compression control state (CCS)
stored in local memory is used for each surface, to support the
3D and media compression formats.
The memory required for the CCS of the entire local memory is 1/256 of
the local memory size. So before the kernel boot, the requi
When we are swapping out the local memory obj on flat-ccs capable platform,
we need to capture the ccs data too along with main meory and we need to
restore it when we are swapping in the content.
When lmem object is swapped into a smem obj, smem obj will
have the extra pages required to hold the
On Fri, Mar 18, 2022 at 04:49:45PM +0900, Byungchul Park wrote:
>
> I guess it was becasue of the commit b1fca27d384e8("kernel debug:
> support resetting WARN*_ONCE"). Your script seems to reset WARN*_ONCE
> repeatedly.
I wasn't aware this was being done, but your guess was correct. The
WARN_ONC
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm/drm-next drm-tip/drm-tip next-20220318]
[cannot apply to v5.17-rc8]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
30 matches
Mail list logo
