On Thu, Sep 22, 2022 at 02:39:16PM -0700, Niranjana Vishwanathapura wrote:
> The function parameter 'exclude' in funciton
> i915_sw_fence_await_reservation() is not used.
> Remove it.
>
> Reviewed-by: Tvrtko Ursulin
> Signed-off-by: Niranjana Vishwanathapura
pushed to drm-intel-next.
Thanks
On Thu, Sep 22, 2022 at 12:51:27PM -0700, Nathan Chancellor wrote:
> [...]
> To make everything work properly, adjust certain functions to match the
> type of the ->show() and ->store() members in 'struct kobj_attribute'.
> Add a macro to generate functions for that can be called via both
>
On Fri, Sep 23, 2022 at 09:40:20AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
vma_lookup is tied to segment of the object instead of section
Can be, but not only that. It would be more accurate to say it is
based of gtt views.
Yah, but new code is
On Thu, Sep 22, 2022 at 12:54:09PM +0300, Jani Nikula wrote:
On Wed, 21 Sep 2022, Niranjana Vishwanathapura
wrote:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h
new file mode 100644
index ..725febfd6a53
On Fri, 23 Sep 2022 12:56:42 -0700, Badal Nilawar wrote:
>
> From: Ashutosh Dixit
>
> Expose power1_max_interval, that is the tau corresponding to PL1.
I think let's change the above sentence to: "Expose power1_max_interval,
that is the tau corresponding to PL1, as a custom hwmon attribute".
On Fri, 23 Sep 2022 12:56:40 -0700, Badal Nilawar wrote:
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.h
> b/drivers/gpu/drm/i915/i915_hwmon.h
> index 7ca9cf2c34c9..4e5b6c149f3a 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.h
> +++ b/drivers/gpu/drm/i915/i915_hwmon.h
> @@ -17,4 +17,5 @@
On Fri, 23 Sep 2022 12:56:37 -0700, Badal Nilawar wrote:
>
Hi Badal,
Let me add this comment on the latest version so we don't forget about it:
> +void i915_hwmon_register(struct drm_i915_private *i915)
> +{
> + struct device *dev = i915->drm.dev;
> + struct i915_hwmon *hwmon;
> +
On Wed, 21 Sep 2022 05:44:35 -0700, Andi Shyti wrote:
>
> > +void i915_hwmon_register(struct drm_i915_private *i915)
> > +{
> > + struct device *dev = i915->drm.dev;
> > + struct i915_hwmon *hwmon;
> > + struct device *hwmon_dev;
> > + struct hwm_drvdata *ddat;
> > +
> > + /* hwmon is
In the probe path, dev_err() can be replaced with dev_err_probe()
which will check if error code is -EPROBE_DEFER and prints the
error name. It also sets the defer probe reason which can be
checked later through debugfs.
Signed-off-by: Yuan Can
---
drivers/gpu/drm/panel/panel-edp.c | 13
In the probe path, dev_err() can be replaced with dev_err_probe()
which will check if error code is -EPROBE_DEFER and prints the
error name. It also sets the defer probe reason which can be
checked later through debugfs.
Signed-off-by: Yuan Can
---
drivers/gpu/drm/panel/panel-simple.c | 9
In the probe path, dev_err() can be replaced with dev_err_probe()
which will check if error code is -EPROBE_DEFER and prints the
error name. It also sets the defer probe reason which can be
checked later through debugfs.
Signed-off-by: Yuan Can
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c |
In the probe path, dev_err() can be replaced with dev_err_probe()
which will check if error code is -EPROBE_DEFER and prints the
error name. It also sets the defer probe reason which can be
checked later through debugfs.
Signed-off-by: Yuan Can
---
drivers/gpu/drm/panel/panel-lvds.c | 9
In the probe path, dev_err() can be replaced with dev_err_probe()
which will check if error code is -EPROBE_DEFER and prints the
error name. It also sets the defer probe reason which can be
checked later through debugfs.
Signed-off-by: Yuan Can
---
.../gpu/drm/panel/panel-leadtek-ltk500hd1829.c
In the probe path, dev_err() can be replaced with dev_err_probe()
which will check if error code is -EPROBE_DEFER and prints the
error name. It also sets the defer probe reason which can be
checked later through debugfs.
Signed-off-by: Yuan Can
---
In the probe path, dev_err() can be replaced with dev_err_probe()
which will check if error code is -EPROBE_DEFER and prints the
error name. It also sets the defer probe reason which can be
checked later through debugfs.
Signed-off-by: Yuan Can
---
drivers/gpu/drm/panel/panel-samsung-s6d16d0.c
In the probe path, dev_err() can be replaced with dev_err_probe()
which will check if error code is -EPROBE_DEFER and prints the
error name. It also sets the defer probe reason which can be
checked later through debugfs.
Signed-off-by: Yuan Can
---
.../gpu/drm/panel/panel-leadtek-ltk050h3146w.c
In the probe path, dev_err() can be replaced with dev_err_probe()
which will check if error code is -EPROBE_DEFER and prints the
error name. It also sets the defer probe reason which can be
checked later through debugfs.
Signed-off-by: Yuan Can
---
drivers/gpu/drm/panel/panel-raydium-rm68200.c
In the probe path, dev_err() can be replaced with dev_err_probe()
which will check if error code is -EPROBE_DEFER and prints the
error name. It also sets the defer probe reason which can be
checked later through debugfs.
Signed-off-by: Yuan Can
---
drivers/gpu/drm/panel/panel-boe-himax8279d.c |
This series simplify the error handling in probe function by
switching from dev_err() to dev_err_probe().
Yuan Can (10):
drm/panel: himax8279d: Use dev_err_probe() to simplify code
drm/panel: panel-edp: Use dev_err_probe() to simplify code
drm/panel: elida-kd35t133: Use dev_err_probe() to
On Fri, Sep 23, 2022 at 03:48:51PM -0700, Lucas De Marchi wrote:
> On Thu, Sep 15, 2022 at 06:46:48PM -0700, Radhakrishna Sripada wrote:
> > From: Matt Roper
> >
> > The part of the media and blitter engine contexts that we care about for
> > setting up an initial state are the same on MTL as
On Thu, Sep 15, 2022 at 06:46:48PM -0700, Radhakrishna Sripada wrote:
From: Matt Roper
The part of the media and blitter engine contexts that we care about for
setting up an initial state are the same on MTL as they were on DG2
(and PVC), so we need to update the driver conditions to re-use
From: Rob Clark
The introduction of 025d27239a2f exposes a problem with f371bcc0c2ac, in
that we need to keep the object pinned in the time the submit is queued
up in the gpu scheduler. Otherwise the shrinker will see it as a thing
that can be evicted if we wait for it to be signaled. But if
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: aaa11ce2ffc84166d11c4d2ac88c3fcf75425fbd Add linux-next specific
files for 20220923
Error/Warning reports:
https://lore.kernel.org/linux-doc/202209231933.vcyettul-...@intel.com
https
On Fri, 2022-09-23 at 14:34 -0700, Han Jingoo wrote:
> On Wed, Sep 21, 2022 Andy Shevchenko wrote:
> >
> > On Wed, Sep 21, 2022 at 4:48 AM ChiaEn Wu wrote:
> > > On Sun, Sep 18, 2022 at 3:22 AM Han Jingoo wrote:
> > > > On Mon, Aug 29, 2022 ChiaEn Wu wrote:
> >
> > > > > +#define
Hi Dave, Daniel,
A few more new things for 6.1. Mostly bug fixes, the new feature here
is gang submission support for mesh shaders in Mesa:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18367
The following changes since commit dacd2d2d9d800b7ab2ee2734578112532cba8105:
On Wed, Sep 21, 2022 Andy Shevchenko wrote:
>
> On Wed, Sep 21, 2022 at 4:48 AM ChiaEn Wu wrote:
> > On Sun, Sep 18, 2022 at 3:22 AM Han Jingoo wrote:
> > > On Mon, Aug 29, 2022 ChiaEn Wu wrote:
>
> > > > +#define MT6370_ITORCH_MIN_uA 25000
> > > > +#define MT6370_ITORCH_STEP_uA
On Thu, Sep 22, 2022 wrote:
>
> From: ye xingchen
>
> Replace the open-code with sysfs_emit() to simplify the code.
>
> Signed-off-by: ye xingchen
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/video/backlight/lp8788_bl.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Thu, Sep 22, 2022 wrote:
>
> From: ye xingchen
>
> Replace the open-code with sysfs_emit() to simplify the code.
>
> Signed-off-by: ye xingchen
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/video/backlight/lm3533_bl.c | 10 +-
> 1 file changed, 5 insertions(+), 5
When a display is unplugged from a MST hub, the connector will be
destroyed in dm_dp_mst_connector_destroy(). The connector's HDCP
properties, like HDCP state will be lost. So, save the connector's HDCP
properties into hdcp_work in amdgpu_dm_atomic_commit_tail(). Also, if
the same display is
Currently we aren't considering the mode_changed property of struct
drm_crtc_state, which can mean that we might not update the display when
it is otherwise necessary, and cause a crash. So, consider mode_changed
in is_content_protection_different().
Signed-off-by: Hamza Mahfooz
---
For MST topology with 1 physical link and multiple connectors (e.g. a
one-to-many MST hub), if userspace enables HDCP simultaneously on all
connected outputs, the commit tail iteratively calls
hdcp_update_display() for each display (connector). However, the HDCP
workqueue data structure for each
With skbuff's post-allocation use of ksize() rearranged to use
kmalloc_size_round() prior to allocation, the compiler can correctly
reason about the size of these allocations. The prior mismatch had caused
buffer overflow mitigations to erroneously fire under CONFIG_UBSAN_BOUNDS,
requiring a
With all "silently resizing" callers of ksize() refactored, remove the
logic in ksize() that would allow it to be used to effectively change
the size of an allocation (bypassing __alloc_size hints, etc). Users
wanting this feature need to either use kmalloc_size_roundup() before an
allocation, or
On 22/09/2022 15:28, Krzysztof Kozlowski wrote:
On 22/09/2022 13:46, Dmitry Baryshkov wrote:
- ranges: true
+maxItems: 2
interconnects:
-items:
- - description: Interconnect path from mdp0 port to the data bus
- - description: Interconnect path from mdp1 port to the
Round up allocations with kmalloc_size_roundup() so that mempool's use
of ksize() is always accurate and no special handling of the memory is
needed by KASAN, UBSAN_BOUNDS, nor FORTIFY_SOURCE.
Cc: Andrew Morton
Cc: linux...@kvack.org
Signed-off-by: Kees Cook
---
mm/mempool.c | 2 +-
1 file
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
Cc: Sumit Semwal
Cc:
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
This will allow for kernels
Round up allocations with kmalloc_size_roundup() so that openvswitch's
use of ksize() is always accurate and no special handling of the memory
is needed by KASAN, UBSAN_BOUNDS, nor FORTIFY_SOURCE.
Cc: Pravin B Shelar
Cc: "David S. Miller"
Cc: Eric Dumazet
Cc: Jakub Kicinski
Cc: Paolo Abeni
All callers of APIs that allowed a 0-sized frag_size appear to be
passing actual size information already, so this use of ksize() can
be removed. However, just in case there is something still depending
on this behavior, issue a WARN and fall back to as before to ksize()
which means we'll also
In the effort to help the compiler reason about buffer sizes, the
__alloc_size attribute was added to allocators. This improves the scope
of the compiler's ability to apply CONFIG_UBSAN_BOUNDS and (in the near
future) CONFIG_FORTIFY_SOURCE. For most allocations, this works well,
as the vast
Round up allocations with kmalloc_size_roundup() so that the verifier's
use of ksize() is always accurate and no special handling of the memory
is needed by KASAN, UBSAN_BOUNDS, nor FORTIFY_SOURCE. Pass the new size
information back up to callers so they can use the space immediately,
so array
In preparation for no longer unpoisoning in ksize(), remove the behavioral
self-tests for ksize().
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
Cc: Andrey Konovalov
Cc: Dmitry Vyukov
Cc: Vincenzo Frascino
Cc: Andrew Morton
Cc: kasan-...@googlegroups.com
Cc: linux...@kvack.org
Signed-off-by:
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
Cc: "David S. Miller"
Cc:
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
Cc: Chris Mason
Cc: Josef
Hi,
The main details on this series are in patch #2's commit log. It's long,
so I won't repeat it again here for the v2. As before, I've tried to
trim the CC list.
v2:
- _keep_ ksize(), but remove instrumentation (makes patch series smaller)
- reorganized skbuff logic to avoid yet more
In preparation for removing the "silently change allocation size"
users of ksize(), explicitly round up all q_vector allocations so that
allocations can be correctly compared to ksize().
Additionally fix potential use-after-free in the case of new allocation
failure: only free memory if the
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
Cc:
Round up allocations with kmalloc_size_roundup() so that devres's use
of ksize() is always accurate and no special handling of the memory is
needed by KASAN, UBSAN_BOUNDS, nor FORTIFY_SOURCE.
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Signed-off-by: Kees Cook
---
drivers/base/devres.c | 3
The __malloc attribute should not be applied to "realloc" functions, as
the returned pointer may alias the storage of the prior pointer. Instead
of splitting __malloc from __alloc_size, which would be a huge amount of
churn, just create __realloc_size for the few cases where it is needed.
From: Dale B Stimson
Extend hwmon power/energy for XEHPSDV especially per gt level energy
usage.
v2: Update to latest HWMON spec (Ashutosh)
v3: Fix review comments (Ashutosh)
v4: Fix review comments (Anshuman)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Dale B Stimson
Signed-off-by: Badal
From: Dale B Stimson
Use i915 HWMON to display device level energy input.
v2: Updated the date and kernel version in feature description
v3:
- Cleaned up hwm_energy function and removed unused function
i915_hwmon_energy_status_get (Ashutosh)
v4: KernelVersion: 6.2, Date: February 2023 in
From: Ashutosh Dixit
Expose power1_max_interval, that is the tau corresponding to PL1. Some bit
manipulation is needed because of the format of PKG_PWR_LIM_1_TIME in
GT0_PACKAGE_RAPL_LIMIT register (1.x * power(2,y)).
v2: Update date and kernel version in Documentation (Badal)
v3: Cleaned up
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
From: Ashutosh Dixit
Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).
v2: Add curr1_crit functionality (Ashutosh)
v3: Use HWMON_CHANNEL_INFO to define power1_crit,
From: Riana Tauro
Use i915 HWMON subsystem to display current input voltage.
v2:
- Updated date and kernel version in feature description
- Fixed review comments (Ashutosh)
v3: Use macro HWMON_CHANNEL_INFO to define hwmon channel (Guenter)
v4:
- Fixed review comments (Ashutosh)
- Use
From: Dale B Stimson
The i915 HWMON module will be used to expose voltage, power and energy
values for dGfx. Here we set up i915 hwmon infrastructure including i915
hwmon registration, basic data structures and functions.
v2:
- Create HWMON infra patch (Ashutosh)
- Fixed review comments
This series adds the HWMON support for DGFX
Test-with: 20220919144408.251981-1-riana.ta...@intel.com
v2:
- Reorganized series. Created first patch as infrastructure patch
followed by feature patches. (Ashutosh)
- Fixed review comments (Jani)
- Fixed review comments (Ashutosh)
v3:
-
On Fri, Sep 23, 2022 at 09:17:25AM +0800, Feng Tang wrote:
> On Thu, Sep 22, 2022 at 07:12:21PM +0800, Hyeonggon Yoo wrote:
> > On Wed, Sep 21, 2022 at 08:10:02PM -0700, Kees Cook wrote:
> > > [...]
> > > Introduce kmalloc_size_roundup(), to serve this function so we can start
> > > replacing the
https://bugzilla.kernel.org/show_bug.cgi?id=216516
--- Comment #9 from Mario Limonciello (AMD) (mario.limoncie...@amd.com) ---
You're missing CONFIG_AMD_PMC.
/var/log/messages:2022-09-23T20:19:35.187256+02:00 myhost kernel: [
85.619055][ T3150] amdgpu :05:00.0: amdgpu: Power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=216516
--- Comment #8 from kolAflash (kolafl...@kolahilft.de) ---
Created attachment 301855
--> https://bugzilla.kernel.org/attachment.cgi?id=301855=edit
kernel log for s2idle: v6.0-rc6 and v6.0-rc6 with 7123d39dc reverted
@Mario
Sadly I've to
On Thu, Sep 15, 2022 at 06:46:47PM -0700, Radhakrishna Sripada wrote:
From: José Roberto de Souza
Expand the current stepping convention to accommodate the GMD
stepping info. Typically GMD step maps to letter stepping
by "A + step %4" and number to "A + step /4" i.e, GMD step
0 maps to
On Thu, Sep 15, 2022 at 06:46:46PM -0700, Radhakrishna Sripada wrote:
From: Matt Roper
Going forward, the hardware teams no longer consider new platforms to
have a "generation" in the way we've defined it for past platforms.
Instead, each IP block (graphics, media, display) will have their own
From: Rob Clark
In some cases crosvm needs a way to query the cache flags to communicate
them to the guest kernel for guest userspace mapping.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 10 ++
include/uapi/drm/msm_drm.h| 1 +
2 files changed, 11 insertions(+)
Ping
Andrey
On 2022-09-22 12:15, Andrey Grodzovsky wrote:
On 2022-09-22 11:03, Luben Tuikov wrote:
The title of this patch has "v3", but "v4" in the title prefix.
If you're using "-v" to git-format-patch, please remove the "v3" from
the title.
Inlined:
On 2022-09-21 14:28, Andrey
The pull request you sent on Fri, 23 Sep 2022 16:08:19 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-09-23-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/22565ae784134282e03912023456151a61db479c
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, Sep 23, 2022 at 03:29:34PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Kernel is trying to eliminate callers of flush_scheduled_work so lets
> try to accommodate.
>
> We currently call it from intel_modeset_driver_remove_noirq on the driver
> remove path but the comment next
On Mon, Aug 29, 2022 at 11:54 PM Kevin Hilman wrote:
>
> Hi Oded (and sorry I misspelled your name last time),
>
> Oded Gabbay writes:
>
> > On Tue, Aug 23, 2022 at 9:24 PM Kevin Hilman wrote:
> >>
> >> Hi Obed,
> >>
> >> Oded Gabbay writes:
> >>
> >> [...]
> >>
> >> > I want to update that
https://bugzilla.kernel.org/show_bug.cgi?id=216516
--- Comment #7 from The Linux kernel's regression tracker (Thorsten Leemhuis)
(regressi...@leemhuis.info) ---
(In reply to Mario Limonciello (AMD) from comment #6)
>
> Thorsten - this is not a regression,
don't worry, I already had feared
https://bugzilla.kernel.org/show_bug.cgi?id=216516
--- Comment #6 from Mario Limonciello (AMD) (mario.limoncie...@amd.com) ---
> Tested s2idle with the openSUSE-15.4 stock kernel v5.14 and it consumed
> MASSIVELY more power than S3.
TONS and TONS of fixes have landed for s2idle since then.
https://bugzilla.kernel.org/show_bug.cgi?id=216516
--- Comment #5 from kolAflash (kolafl...@kolahilft.de) ---
Created attachment 301854
--> https://bugzilla.kernel.org/attachment.cgi?id=301854=edit
kernel log: v6.0-rc6 and v6.0-rc6 with 7123d39dc reverted
@Mario
(In reply to Mario
On 9/23/2022 3:53 AM, Tvrtko Ursulin wrote:
On 22/09/2022 23:11, Daniele Ceraolo Spurio wrote:
On MTL the primary GT doesn't have any media capabilities, so no video
engines and no HuC. We must therefore skip the HuC fetch and load on
that specific case. Given that other multi-GT platforms
On 9/23/2022 2:24 AM, Jani Nikula wrote:
On Thu, 22 Sep 2022, Daniele Ceraolo Spurio
wrote:
From: Aravind Iddamsetty
With MTL standalone media architecture the wopcm layout has changed with
separate partitioning in WOPCM for GCD/GT GuC and SA Media GuC. The size
of WOPCM is 4MB with
On Fri, 2022-09-23 at 15:48 +0200, Ulf Hansson wrote:
> On Fri, 23 Sept 2022 at 14:47, Liu Ying wrote:
> >
> > After a device transitions to sleep state through it's system
> > suspend
> > callback pm_runtime_force_suspend(), the device's driver may still
> > try
> > to do runtime PM for the
devm_ioremap_resource() prints error message in itself. Remove the
dev_err call to avoid redundant error message.
Signed-off-by: Shang XiaoJing
---
drivers/video/fbdev/imxfb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
index
devm_ioremap_resource() prints error message in itself. Remove the
dev_err call to avoid redundant error message.
Signed-off-by: Shang XiaoJing
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 4 +---
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 4 +---
drivers/gpu/drm/mediatek/mtk_mdp_rdma.c |
On 23.09.2022 10:45, Nirmoy Das wrote:
Print the error code returned by __i915_ttm_migrate()
for better debuggability.
v2: Fix kernel test robot warning.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6889
Acked-by: Matthew Auld
Signed-off-by: Nirmoy Das ---
Print the error code returned by __i915_ttm_migrate()
for better debuggability.
v2: Fix kernel test robot warning.
v3: Fix dim checkpatch warning.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6889
Acked-by: Matthew Auld
Signed-off-by: Nirmoy Das
---
Hi,
On Thu, Sep 22, 2022 at 10:51 PM Sean Hong
wrote:
>
> Add support for the AUO - B116XAK01.6 (HW: 1A) panel.
>
> Signed-off-by: Sean Hong
> ---
> drivers/gpu/drm/panel/panel-edp.c | 1 +
> 1 file changed, 1 insertion(+)
As with previous trivial patches that just add an entry to this
Am 23.09.22 um 16:17 schrieb Daniel Gomez:
Commit [1] removes DC_FP_* wrappers from dml. However, this generates
the BUG [2] on the amdgpu driver. Restore DC_FP_* wrappers in dml/calcs
but only for the functions dcn_bw_update_from_pplib and
dcn_bw_notify_pplib_of_wm_ranges.
That's a really bad
Hi,
On Thu, Sep 22, 2022 at 10:46 PM Sean Hong
wrote:
>
> Add support for the BOE - NT116WHM-N21 (HW: V8.2) panel.
>
> Signed-off-by: Sean Hong
> ---
> drivers/gpu/drm/panel/panel-edp.c | 1 +
> 1 file changed, 1 insertion(+)
As with previous trivial patches that just add an entry to this
Hi,
On Fri, Sep 23, 2022 at 1:50 AM Sean Hong
wrote:
>
> Add support for the BOE - NT116WHM-N21 (HW: V8.1) panel.
>
> Signed-off-by: Sean Hong
> ---
> drivers/gpu/drm/panel/panel-edp.c | 1 +
> 1 file changed, 1 insertion(+)
As with previous trivial patches that just add an entry to this
Hi,
On Thu, Sep 22, 2022 at 10:37 PM Sean Hong
wrote:
>
> Add support for the INX - N116BCN-EA1 (HW: C4) panel.
>
> Signed-off-by: Sean Hong
> ---
> drivers/gpu/drm/panel/panel-edp.c | 1 +
> 1 file changed, 1 insertion(+)
As with previous trivial patches that just add an entry to this
From: Tvrtko Ursulin
Kernel is trying to eliminate callers of flush_scheduled_work so lets
try to accommodate.
We currently call it from intel_modeset_driver_remove_noirq on the driver
remove path but the comment next to it does not tell me what exact work it
wants to flush.
I can spot three
Hi,
On Mon, Sep 12, 2022 at 11:48 AM Brian Norris wrote:
>
> On Thu, Aug 25, 2022 at 11:06 AM Brian Norris
> wrote:
> > On Thu, Aug 25, 2022 at 10:37 AM Doug Anderson
> > wrote:
> > > Given that this is _not_ an area that I'm an expert in nor is it an
> > > area where the consequences are
Commit [1] removes DC_FP_* wrappers from dml. However, this generates
the BUG [2] on the amdgpu driver. Restore DC_FP_* wrappers in dml/calcs
but only for the functions dcn_bw_update_from_pplib and
dcn_bw_notify_pplib_of_wm_ranges.
[1] 9696679bf7ac40a8fb6a488a75bd66d4414cd3c3 drm/amd/display:
On Fri, 23 Sept 2022 at 14:47, Liu Ying wrote:
>
> After a device transitions to sleep state through it's system suspend
> callback pm_runtime_force_suspend(), the device's driver may still try
> to do runtime PM for the device(runtime suspend first and then runtime
> resume) although runtime PM
Using the newest pm_runtime_resume_and_get is more appropriate
for simplifing code here.
Signed-off-by: Zhang Qilong
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 6 ++
drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++
drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++
After a device transitions to sleep state through it's system suspend
callback pm_runtime_force_suspend(), the device's driver may still try
to do runtime PM for the device(runtime suspend first and then runtime
resume) although runtime PM is disabled by that callback. The runtime
PM operations
>-Original Message-
>From: Thomas Zimmermann
>Sent: Friday, September 23, 2022 3:53 AM
>To: Ruhl, Michael J ; javi...@redhat.com;
>airl...@linux.ie; dan...@ffwll.ch
>Cc: dri-devel@lists.freedesktop.org
>Subject: Re: [PATCH 2/5] drm/simpledrm: Use
>drm_atomic_get_new_plane_state()
>
>Hi
>
https://bugzilla.kernel.org/show_bug.cgi?id=216516
--- Comment #4 from Mario Limonciello (AMD) (mario.limoncie...@amd.com) ---
> This "stays awake" behaviour is probably a bug on it's own.
> (I may may open another bug report when this one is solved)
This is actually the root of the problem I
Hi
Am 23.09.22 um 12:58 schrieb Javier Martinez Canillas:
On 9/23/22 12:43, Thomas Zimmermann wrote:
Hi
Am 23.09.22 um 10:06 schrieb Javier Martinez Canillas:
On 9/22/22 15:09, Thomas Zimmermann wrote:
Synchronize CPU access to GEM BOs with other drivers when updating the
screen buffer.
On Thu, 22 Sep 2022, Maxime Ripard wrote:
> drm_connector_pick_cmdline_mode() is in charge of finding a proper
> drm_display_mode from the definition we got in the video= command line
> argument.
>
> Let's add some unit tests to make sure we're not getting any regressions
> there.
>
>
On 23/09/2022 03:39, liangxu...@mediatek.com wrote:
> From: liangxu xu
>
> Add dt-binding documentation of dp for MediaTek MT8188 SoC.
>
> Signed-off-by: liangxu xu
> ---
Where is the DTS? Where are driver changes?
Best regards,
Krzysztof
On 23/09/2022 03:42, liangxu...@mediatek.com wrote:
> From: liangxu xu
>
> Add dt-binding documentation of dpi for MediaTek MT8188 SoC.
>
> Signed-off-by: liangxu xu
Where is the DTS? Where are driver changes?
Best regards,
Krzysztof
On Fri, Sep 23, 2022 at 12:30:09PM +0200, Thomas Zimmermann wrote:
> Am 23.09.22 um 11:26 schrieb Javier Martinez Canillas:
> > On 9/23/22 11:15, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 22.09.22 um 16:25 schrieb Maxime Ripard:
> > > > drm_connector_pick_cmdline_mode() is in charge of
On 9/23/22 12:30, Thomas Zimmermann wrote:
[...]
+
+#ifdef CONFIG_DRM_KUNIT_TEST
+#include "tests/drm_client_modeset_test.c"
+#endif
>>>
>>> I strongly dislike this style of including source files in each other.
>>> It's a recipe for all kind of build errors. Can you do
On 23/09/2022 11:32, Das, Nirmoy wrote:
Reviewed-by: Nirmoy Das
Thanks!
Pushed now. Should land with 6.2.
Regards,
Tvrtko
On 6/30/2022 2:57 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
There are ongoing efforts to remove usages of flush_scheduled_work() from
drivers in order to
On 9/23/22 12:43, Thomas Zimmermann wrote:
> Hi
>
> Am 23.09.22 um 10:06 schrieb Javier Martinez Canillas:
>> On 9/22/22 15:09, Thomas Zimmermann wrote:
>>> Synchronize CPU access to GEM BOs with other drivers when updating the
>>> screen buffer. Imported buffers might otherwise contain stale
On 22/09/2022 23:11, Daniele Ceraolo Spurio wrote:
On MTL the primary GT doesn't have any media capabilities, so no video
engines and no HuC. We must therefore skip the HuC fetch and load on
that specific case. Given that other multi-GT platforms might have HuC
on the primary GT, we can't just
Hi
Am 23.09.22 um 10:06 schrieb Javier Martinez Canillas:
On 9/22/22 15:09, Thomas Zimmermann wrote:
Synchronize CPU access to GEM BOs with other drivers when updating the
screen buffer. Imported buffers might otherwise contain stale data.
Can you please elaborate what the problem is? The
1 - 100 of 184 matches
Mail list logo
