New updates to HDMI combo PHY voltage swing tables. Actually with this
update (bspec updated on 08/17/2021), the values are reverted back to be
same as icelake for HDMI combo PHY.
Bspec: 49291
Signed-off-by: Balasubramani Vivekanandan
---
.../drm/i915/display/intel_ddi_buf_trans.c| 22 +-
On Wed, May 25, 2022 at 5:02 AM Daniel Stone wrote:
> On Sat, 7 May 2022 at 14:18, Jason Ekstrand wrote:
> > This patch series actually contains two new ioctls. There is the export
> one
> > mentioned above as well as an RFC for an import ioctl which provides the
> other
> > half. The intentio
Removed trailing whitespace from end of line in amdgpu_device.c
Signed-off-by: Mitchell Augustin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_
On Wed, May 25, 2022 at 8:20 AM Daniel Vetter wrote:
> On Mon, May 09, 2022 at 07:54:19AM +0200, Christian König wrote:
> > Reviewed-by: Christian König for the series.
> >
> > I assume you have the userspace part ready as well? If yes let's push
> this
> > to drm-misc-next asap.
>
> Hopefully I
On Wed, May 25, 2022 at 06:53:16PM -0300, Fabio Estevam wrote:
> ADV7511_REG_CEC_RX_FRAME_HDR[] and ADV7511_REG_CEC_RX_FRAME_LEN[]
> are only used inside adv7511_cec.c.
>
> Move their definitions to this file to avoid the following build
> warnings when CONFIG_DRM_I2C_ADV7511_CEC is not selected:
On Wed, May 25, 2022 at 10:43 AM Daniel Vetter wrote:
> On Wed, May 25, 2022 at 10:35:47AM -0500, Jason Ekstrand wrote:
> > On Wed, May 25, 2022 at 8:20 AM Daniel Vetter wrote:
> >
> > > On Mon, May 09, 2022 at 07:54:19AM +0200, Christian König wrote:
> > > > Reviewed-by: Christian König for th
Fix spelling typo in comment.
Signed-off-by: pengfuyuan
---
include/video/radeon.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/video/radeon.h b/include/video/radeon.h
index 005eae19ec09..72f94ccfa725 100644
--- a/include/video/radeon.h
+++ b/include/video/radeon.h
On Wed, May 25, 2022 at 9:22 AM Tvrtko Ursulin
wrote:
>
>
> On 25/05/2022 14:41, Rob Clark wrote:
> > On Wed, May 25, 2022 at 2:46 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 24/05/2022 15:50, Rob Clark wrote:
> >>> On Tue, May 24, 2022 at 6:45 AM Tvrtko Ursulin
> >>> wrote:
>
>
> >
From: ChiYuan Huang
Add the property parsing for ocp level selection.
Reported-by: Lucas Tsai
Signed-off-by: ChiYuan Huang
---
drivers/video/backlight/rt4831-backlight.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/video/backlight/rt4831-backlight.c
b/drivers/vi
From: ChiYuan Huang
Add the new property for ocp level selection.
Signed-off-by: ChiYuan Huang
---
.../bindings/leds/backlight/richtek,rt4831-backlight.yaml | 8
include/dt-bindings/leds/rt4831-backlight.h | 5 +
2 files changed, 13 insertions(+)
dif
From: ChiYuan Huang
This patch series is to make ocp level selectable.
Some application design use small inductor. And it's easy to trigger the
over current protection. Due to the OCP limit, It make the brightness current
not match the configured value.
To meet the HW design, the ocp level have
On Wed, May 25, 2022 at 9:11 AM Tvrtko Ursulin
wrote:
>
>
> On 24/05/2022 15:57, Rob Clark wrote:
> > On Tue, May 24, 2022 at 6:45 AM Tvrtko Ursulin
> > wrote:
> >>
> >> On 23/05/2022 23:53, Rob Clark wrote:
> >>>
> >>> btw, one fun (but unrelated) issue I'm hitting with scheduler... I'm
> >>> tr
Hi Matthew,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on v5.18 next-20220525]
[cannot apply to drm-intel/for-linux-next drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
On Wed, 25 May 2022 10:57:46 -0400, Alyssa Rosenzweig wrote:
>
Reviewed-by: Rob Herring
On Wed, May 25, 2022 at 9:26 AM Daniel Vetter wrote:
>
> On Mon, May 23, 2022 at 05:59:02PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, May 20, 2022 at 5:01 PM Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Mon, May 16, 2022 at 3:28 AM Thomas Zimmermann
> > > wrote:
> > > >
> > > >
On Wed, May 25, 2022 at 03:20:06PM -0700, Andrew Morton wrote:
> On Wed, 25 May 2022 23:07:35 +0100 Jessica Clarke wrote:
>
> > This is i386, so an unsigned long is 32-bit, but i_blocks is a blkcnt_t
> > i.e. a u64, which makes the shift without a cast of the LHS fishy.
>
> Ah, of course, thanks
The pull request you sent on Wed, 25 May 2022 16:06:58 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2022-05-25
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2518f226c60d8e04d18ba4295500a5b0b8ac7659
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
Hi Matthew,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on v5.18 next-20220525]
[cannot apply to drm-intel/for-linux-next drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On 26/05/2022 00:02, Kuogee Hsieh wrote:
This patch add regulator_set_load() before enable regulator at
eDP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
---
drivers/phy/qualcomm/phy-qcom-edp.c | 12
1 file changed, 12
On Tue, May 24, 2022 at 04:59:06PM -0700, Matt Roper wrote:
PVC also has a hwconfig table. Actually the current expectation is that
all future platforms will have hwconfig, so let's just change the
condition to an IP version check so that we don't need to keep updating
this for each new platform
On Tue, May 24, 2022 at 11:07 PM Dave Airlie wrote:
>
> AMD has started some new GPU support [...]
Oh Christ. Which means another set of auto-generated monster headers. Lovely.
Linus
Hi Rob,
Thank you for the patch.
On Wed, May 25, 2022 at 03:56:26PM -0500, Rob Herring wrote:
> While 'ddc-i2c-bus' is a common property, it should be in a connector
> node rather than the HDMI bridge node as the I2C bus goes to a
> connector and not the HDMI block. Drop it from the example.
>
>
On Wed, 25 May 2022 23:07:35 +0100 Jessica Clarke wrote:
> This is i386, so an unsigned long is 32-bit, but i_blocks is a blkcnt_t
> i.e. a u64, which makes the shift without a cast of the LHS fishy.
Ah, of course, thanks. I remember 32 bits ;)
--- a/mm/shmem.c~mm-shmemc-suppress-shift-warning
Add linux-next
>> specific files for 20220525
>>
>> Error/Warning reports:
>>
>> ...
>>
>> Unverified Error/Warning (likely false positive, please contact us if
>> interested):
>
> Could be so.
>
>> mm/shmem.c:1948 shmem_g
On Wed, May 25, 2022 at 12:38:51PM +0200, Christian König wrote:
Am 25.05.22 um 11:35 schrieb Lionel Landwerlin:
On 25/05/2022 12:26, Lionel Landwerlin wrote:
On 25/05/2022 11:24, Christian König wrote:
Am 25.05.22 um 08:47 schrieb Lionel Landwerlin:
On 09/02/2022 20:26, Christian König wrote
ADV7511_REG_CEC_RX_FRAME_HDR[] and ADV7511_REG_CEC_RX_FRAME_LEN[]
are only used inside adv7511_cec.c.
Move their definitions to this file to avoid the following build
warnings when CONFIG_DRM_I2C_ADV7511_CEC is not selected:
drivers/gpu/drm/bridge/adv7511/adv7511.h:229:17: warning:
'ADV7511_REG_
On Thu, 26 May 2022 05:35:20 +0800 kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 8cb8311e95e3bb58bd84d6350365f14a718faa6d Add linux-next
> specific files for 20220525
>
> Err
On Wed, May 25, 2022 at 2:05 PM T.J. Mercier wrote:
>
> On Wed, May 25, 2022 at 7:38 AM Daniel Vetter wrote:
> >
> > On Tue, May 17, 2022 at 08:13:24AM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, May 16, 2022 at 05:08:05PM -0700, T.J. Mercier wrote:
> > > > On Mon, May 16, 2022 at 12:21 PM Chr
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 8cb8311e95e3bb58bd84d6350365f14a718faa6d Add linux-next specific
files for 20220525
Error/Warning reports:
https://lore.kernel.org/linux-mm/202204291924.vtgzmeri-...@intel.com
https
Applied. Thanks!
Alex
On Wed, May 25, 2022 at 4:38 PM Mitchell Augustin
wrote:
>
> Removed trailing whitespace from end of line in amdgpu_device.c
>
> Signed-off-by: Mitchell Augustin
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-
On Wed, May 25, 2022 at 7:38 AM Daniel Vetter wrote:
>
> On Tue, May 17, 2022 at 08:13:24AM +0200, Greg Kroah-Hartman wrote:
> > On Mon, May 16, 2022 at 05:08:05PM -0700, T.J. Mercier wrote:
> > > On Mon, May 16, 2022 at 12:21 PM Christian König
> > > wrote:
> > > >
> > > > Am 16.05.22 um 20:08 s
Vdda regulators are related to both eDP and DP phy so that it should be
managed at eDP and DP phy driver instead of controller. This patch removes
vdda regulators related functions out of eDP/DP controller.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
Revi
This patch add regulator_set_load() before enable regulator at
DP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Reviewed-by: Douglas Anderson
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 40 -
1 file changed, 31 insertions(+), 9 deletions(-)
This patch add regulator_set_load() before enable regulator at
eDP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Douglas Anderson
---
drivers/phy/qualcomm/phy-qcom-edp.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
b/drivers/phy/q
1) add regulator_set_load() to eDP phy
2) add regulator_set_load() to DP phy
3) remove vdda related function out of eDP/DP controller
Kuogee Hsieh (3):
phy: qcom-edp: add regulator_set_load to edp phy
phy: qcom-qmp: add regulator_set_load to dp phy
drm/msm/dp: delete vdda regulator related f
While 'ddc-i2c-bus' is a common property, it should be in a connector
node rather than the HDMI bridge node as the I2C bus goes to a
connector and not the HDMI block. Drop it from the example.
Signed-off-by: Rob Herring
---
.../devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml | 1 -
Hi,
On Wed, May 25, 2022 at 12:37 PM Kuogee Hsieh wrote:
>
> This patch add regulator_set_load() before enable regulator at
> DP phy driver.
>
> Signed-off-by: Kuogee Hsieh
> Reviewed-by: Stephen Boyd
> ---
> drivers/phy/qualcomm/phy-qcom-qmp.c | 41
> +
>
https://bugzilla.kernel.org/show_bug.cgi?id=213145
--- Comment #16 from Eric Wheeler (bugzilla-ker...@z.ewheeler.org) ---
FYI: 5.18 seems to be working! I guess the 5.13 driver from AMD needs to be
fixed, but thats on them...
--
You may reply to this email to add a comment.
You are receiving t
Hello Dominik,
I missed this email before and never answered. Sorry about that.
On 3/10/22 14:11, Dominik Kierner wrote:
> Hello Javier,
>
> I was working on a SSD130x driver as well, although with a different
> (drm_panel) approach and hit a bit of a roadblock.
My first attempt also was using
This patch add regulator_set_load() before enable regulator at
DP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 41 +
1 file changed, 32 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/qual
Vdda regulators are related to both eDP and DP phy so that it should be
managed at eDP and DP phy driver instead of controller. This patch removes
vdda regulators related functions out of eDP/DP controller.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
Revi
This patch add regulator_set_load() before enable regulator at
eDP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Douglas Anderson
---
drivers/phy/qualcomm/phy-qcom-edp.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
b/drivers/phy/q
1) add regulator_set_load() to eDP phy
2) add regulator_set_load() to DP phy
3) remove vdda related function out of eDP/DP controller
Kuogee Hsieh (3):
phy: qcom-edp: add regulator_set_load to edp phy
phy: qcom-qmp: add regulator_set_load to dp phy
drm/msm/dp: delete vdda regulator related f
Hi Jani, thanks for your review. I got all the user space
implementation ready to see it in context.
libdrm patch to wrap this functionality:
https://www.spinics.net/lists/dri-devel/msg347318.html
Chromium user space implementation making direct use of the new prop flag:
crrev.com/c/3655850
The f
On 5/24/2022 16:59, Matt Roper wrote:
PVC also has a hwconfig table. Actually the current expectation is that
all future platforms will have hwconfig, so let's just change the
condition to an IP version check so that we don't need to keep updating
this for each new platform that shows up.
Cc: J
Just for CI.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index 6c6f8cbd7321..119e53f5d9b1 100644
--- a/drivers/gpu/d
A non-recoverable context must be used if the user wants proper error
capture on discrete platforms. In the future the kernel may want to blit
the contents of some objects when later doing the capture stage.
Testcase: igt@gem_exec_capture@capture-recoverable-discrete
Signed-off-by: Matthew Auld
C
With the uAPI in place we should now have enough in place to ensure a
working system on small BAR configurations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G
Skip capturing any lmem pages that can't be copied using the CPU. This
in now only best effort on platforms that have small BAR.
Testcase: igt@gem-exec-capture@capture-invisible
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Da
If set, force the allocation to be placed in the mappable portion of
I915_MEMORY_CLASS_DEVICE. One big restriction here is that system memory
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the
object, that way we can always spill the object into system memory if we
can't
On small BAR configurations, when dealing with I915_MEMORY_CLASS_DEVICE
allocations, we assume that by default, all userspace allocations should
be placed in the non-CPU visible portion. Note that dumb buffers are
not included here, since these are not "GPU accelerated" and likely need
CPU access.
No longer used.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
---
drivers/gpu/drm/i915/intel_memory_region.c | 4 +---
drivers/gpu/drm/i915/intel_m
Userspace wants to know the size of CPU visible portion of device
local-memory, and on small BAR devices the probed_size is no longer
enough. In Vulkan, for example, it would like to know the size in bytes
for CPU visible VkMemoryHeap. We already track the io_size for each
region, so it's just case
Vulkan would like to have a rough measure of how much device memory can
in theory be allocated. Also add unallocated_cpu_visible_size to track
the visible portion, in case the device is using small BAR.
Testcase: igt@i915_query@query-regions-unallocated
Testcase: igt@i915_query@query-regions-sanit
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel
Test-with: 20220525183702.490989-1-matthew.a...@intel.com
--
2.34.3
Applied. Thanks!
Alex
On Wed, May 25, 2022 at 5:37 AM Jiapeng Chong
wrote:
>
> This symbol is not used outside of imu_v11_0.c, so marks it
> static.
>
> Fixes the following w1 warning:
>
> drivers/gpu/drm/amd/amdgpu/imu_v11_0.c:302:6: warning: no previous
> prototype for ‘program_imu_rlc_ram’ [
On Wed, May 25, 2022 at 05:03:13PM +0100, Tvrtko Ursulin wrote:
On 24/05/2022 18:51, Matt Roper wrote:
On Tue, May 24, 2022 at 10:43:39AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Catch and log any garbage in the register, including no tiles marked, or
multiple tiles marked.
Signed-
On Wed, May 25, 2022 at 05:03:13PM +0100, Tvrtko Ursulin wrote:
>
> On 24/05/2022 18:51, Matt Roper wrote:
> > On Tue, May 24, 2022 at 10:43:39AM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Catch and log any garbage in the register, including no tiles marked, or
> > > mul
Some comments on this from my side too, not sure how good they are when it
comes more to the hw side of things :-)
On Thu, Apr 14, 2022 at 10:50:18AM +0200, Maxime Ripard wrote:
> On Wed, Apr 13, 2022 at 05:19:00PM -0500, Samuel Holland wrote:
> > This series adds a DRM driver for the electrophore
Hi
Am 21.05.22 um 04:49 schrieb Benjamin Herrenschmidt:
On Thu, 2022-05-19 at 09:27 +0200, Thomas Zimmermann wrote:
to build without PCI to see what happens.
If you bring any of the "heuristic" and palette support code in, you
need PCI. I don't see any reason to take it out.
Those old Macs
On 5/18/22 03:44, Jani Nikula wrote:
On Tue, 17 May 2022, Hans de Goede wrote:
Hi All,
As mentioned in my RFC titled "drm/kms: control display brightness through
drm_connector properties":
https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/
The first step toward
On 25/05/2022 14:41, Rob Clark wrote:
On Wed, May 25, 2022 at 2:46 AM Tvrtko Ursulin
wrote:
On 24/05/2022 15:50, Rob Clark wrote:
On Tue, May 24, 2022 at 6:45 AM Tvrtko Ursulin
wrote:
On 23/05/2022 23:53, Rob Clark wrote:
On Mon, May 23, 2022 at 7:45 AM Tvrtko Ursulin
wrote:
Hi Ro
On 24/05/2022 15:57, Rob Clark wrote:
On Tue, May 24, 2022 at 6:45 AM Tvrtko Ursulin
wrote:
On 23/05/2022 23:53, Rob Clark wrote:
btw, one fun (but unrelated) issue I'm hitting with scheduler... I'm
trying to add an igt test to stress shrinker/eviction, similar to the
existing tests/i915/g
On 24/05/2022 18:51, Matt Roper wrote:
On Tue, May 24, 2022 at 10:43:39AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Catch and log any garbage in the register, including no tiles marked, or
multiple tiles marked.
Signed-off-by: Tvrtko Ursulin
Cc: Matt Roper
---
We caught garbage in
On Wed, May 25, 2022 at 10:35:47AM -0500, Jason Ekstrand wrote:
> On Wed, May 25, 2022 at 8:20 AM Daniel Vetter wrote:
>
> > On Mon, May 09, 2022 at 07:54:19AM +0200, Christian König wrote:
> > > Reviewed-by: Christian König for the series.
> > >
> > > I assume you have the userspace part ready
On Sat, May 21, 2022 at 04:13:42PM -0300, André Almeida wrote:
> Since commit ba420afab565 ("drm/vkms: Bugfix racing hrtimer vblank
> handle") the work is scheduled at vkms_vblank_simulate() and since
> commit 5ef8100a3919 ("drm/vkms: flush crc workers earlier in commit
> flow") the work is flushed
On Sun, May 22, 2022 at 01:41:04AM +0200, Niels Dossche wrote:
> Other callers of drmm_kzalloc already return -ENOMEM on allocation
> failure. Change EINVAL to ENOMEM for consistency.
>
> Signed-off-by: Niels Dossche
Thanks, applied to drm-misc-next.
-Daniel
> ---
>
> Note:
> I found this issu
Il 23/05/22 12:47, Guillaume Ranquet ha scritto:
From: Markus Schneider-Pargmann
This controller is present on several mediatek hardware. Currently
mt8195 and mt8395 have this controller without a functional difference,
so only one compatible field is added.
The controller can have two forms,
On Wed, May 18, 2022 at 10:54:46AM +0200, Christian König wrote:
> Use unrcu_pointer() instead of the manual cast.
>
> Signed-off-by: Christian König
TIL about unrcu_pointer, and also that entire code here freaks me out. But
at least this seems more with what other users of similar xchg and cmpx
ср, 25 мая 2022 г. в 18:14, Jernej Škrabec :
>
> Dne sreda, 25. maj 2022 ob 16:55:56 CEST je Roman Stratiienko napisal(a):
> > вт, 24 мая 2022 г. в 22:14, Jernej Škrabec :
> > >
> > > Dne torek, 24. maj 2022 ob 19:14:35 CEST je Roman Stratiienko napisal(a):
> > > > By the way, not related to this i
Dne sreda, 25. maj 2022 ob 16:55:56 CEST je Roman Stratiienko napisal(a):
> вт, 24 мая 2022 г. в 22:14, Jernej Škrabec :
> >
> > Dne torek, 24. maj 2022 ob 19:14:35 CEST je Roman Stratiienko napisal(a):
> > > By the way, not related to this issue:
> > >
> > > I cherry-picked
> > > https://patchwork
On Wed, May 18, 2022 at 01:12:33PM +0300, Jani Nikula wrote:
> On Wed, 18 May 2022, Hans de Goede wrote:
> > Hi,
> >
> > On 5/18/22 10:44, Jani Nikula wrote:
> >> On Tue, 17 May 2022, Hans de Goede wrote:
> >>> Hi All,
> >>>
> >>> As mentioned in my RFC titled "drm/kms: control display brightness
On Mon, May 16, 2022 at 04:56:13PM -0600, Jim Cromie wrote:
> DRM.debug API is 23 macros, issuing 10 exclusive categories of debug
> messages. By rough count, they are used 5140 times in the kernel.
> These all call drm_dbg or drm_devdbg, which call drm_debug_enabled(),
> which checks bits in glob
TTRX_3485 requires the infamous "dummy job" workaround. I have this
workaround implemented in a local branch, but I have not yet hit a case
that requires it so I cannot test whether the implementation is correct.
In the mean time, add the quirk bit so we can document which platforms
may need it in
The most important Valhall-specific quirks have been handled, so add the
Valhall compatible and probe.
v2: Use arm,mali-valhall-jm compatible.
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --gi
Add the features, issues, and GPU ID for Mali-G57, a first-generation
Valhall GPU. Other first- and second-generation Valhall GPUs should be
similar.
v2: Split out issue list for r0p0 from newer Natt GPUs, as TTRX_3485 was
fixed in r0p1. Unfortunately, MT8192 has a r0p0, so we do need to handle
TT
Add the HW_FEATURE_CLEAN_ONLY_SAFE bit based on kbase. When I actually
tried to port the logic from kbase, trivial jobs raised Data Invalid
Faults, so this may depend on other coherency details. It's still useful
to have the bit to record the feature bit when adding new models.
Signed-off-by: Alys
L2_MMU_CONFIG is an implementation-defined register. Different Mali GPUs
define slightly different MAX_READS and MAX_WRITES fields, which
throttle outstanding reads and writes when set to non-zero values. When
left as zero, reads and writes are not throttled.
Both kbase and panfrost always zero th
Add handling for the HW_ISSUE_TTRX_2968_TTRX_3162 quirk. Logic ported
from kbase. kbase lists this workaround as used on Mali-G57.
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_gpu.c| 3 +++
drivers/gpu/drm/panfrost/panfrost_issues.h | 3 ++
Some Valhall GPUs require resets when encountering bus faults due to
occlusion query writes. Add the issue bit for this and handle it.
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.c | 9 +++--
drivers/gpu/drm/panfrost/panfrost_issue
Logically, this function is free of side effects, so any pointers it
takes should be const. Needed to avoid a warning in the next patch.
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_issues.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
>From the kernel's perspective, (pre-CSF, "Job Manager") Valhall is more
or less compatible with Bifrost, although they differ to userspace. Add
a compatible for Valhall to the existing Bifrost bindings documentation.
As the first SoC with a Valhall GPU receiving mainline support, add a
specific c
Here is version 2 of the series adding support for job manager Valhall
(v9). CSF Valhall is not supported in this series. The core
issues/features are added for Mali-G57 "Natt" as the current target.
Natt is used in MT8192, which needs a few extra patches to follow
(currently blocked on MediaTek in
вт, 24 мая 2022 г. в 22:14, Jernej Škrabec :
>
> Dne torek, 24. maj 2022 ob 19:14:35 CEST je Roman Stratiienko napisal(a):
> > By the way, not related to this issue:
> >
> > I cherry-picked
> > https://patchwork.kernel.org/project/dri-devel/patch/20220424162633.12369-9-sam...@sholland.org/
> > and
On Tue, May 17, 2022 at 08:13:24AM +0200, Greg Kroah-Hartman wrote:
> On Mon, May 16, 2022 at 05:08:05PM -0700, T.J. Mercier wrote:
> > On Mon, May 16, 2022 at 12:21 PM Christian König
> > wrote:
> > >
> > > Am 16.05.22 um 20:08 schrieb T.J. Mercier:
> > > > On Mon, May 16, 2022 at 10:20 AM Christ
On Wed, May 25, 2022 at 04:22:48PM +0200, Christian König wrote:
> Am 25.05.22 um 16:15 schrieb Daniel Stone:
> > Hi,
> >
> > On Wed, 25 May 2022 at 15:07, Simon Ser wrote:
> > > On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter
> > > wrote:
> > > > > You can add that to the list of reasons
Am 25.05.22 um 16:15 schrieb Daniel Stone:
Hi,
On Wed, 25 May 2022 at 15:07, Simon Ser wrote:
On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter wrote:
You can add that to the list of reasons why compositors need to stop
using buffers with unsignaled fences. There's plenty of other reasons
Hi,
On Wed, 25 May 2022 at 15:07, Simon Ser wrote:
> On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter wrote:
> > > You can add that to the list of reasons why compositors need to stop
> > > using buffers with unsignaled fences. There's plenty of other reasons
> > > there already (the big one
On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter wrote:
> > > Ofc in reality you can still flood your compositor and they're not very
> > > robust, but with umf it's trivial to just hang your compositor forever and
> > > nothing happens.
> >
> > You can add that to the list of reasons why com
On Wed, May 25, 2022 at 03:28:41PM +0200, Michel Dänzer wrote:
> On 2022-05-25 15:05, Daniel Vetter wrote:
> > On Tue, May 17, 2022 at 12:28:17PM +0200, Christian König wrote:
> >> Am 09.05.22 um 16:10 schrieb Daniel Vetter:
> >>> On Mon, May 09, 2022 at 08:56:41AM +0200, Christian König wrote:
> >
On Wed, May 25, 2022 at 2:46 AM Tvrtko Ursulin
wrote:
>
>
> On 24/05/2022 15:50, Rob Clark wrote:
> > On Tue, May 24, 2022 at 6:45 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 23/05/2022 23:53, Rob Clark wrote:
> >>> On Mon, May 23, 2022 at 7:45 AM Tvrtko Ursulin
> >>> wrote:
>
>
> >
On Mon, 23 May 2022 at 15:55, Linus Walleij wrote:
>
> On Mon, May 23, 2022 at 2:46 PM Linus Walleij
> wrote:
> > On Fri, May 6, 2022 at 2:33 PM YueHaibing wrote:
> >
> > > While CONFIG_OF is n but COMPILE_TEST is y, we got this:
> > >
> > > WARNING: unmet direct dependencies detected for DRM_D
вт, 24 мая 2022 г. в 22:13, Jernej Škrabec :
>
> Don't top post, it's annoying and against rules.
>
> Dne torek, 24. maj 2022 ob 19:10:06 CEST je Roman Stratiienko napisal(a):
> > Please draft a test for the zpos issue you're mentioning.
> >
> > It's very easy to do with kmsxx using python wrapper.
On Mon, May 23, 2022 at 05:59:02PM -0700, Doug Anderson wrote:
> Hi,
>
> On Fri, May 20, 2022 at 5:01 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Mon, May 16, 2022 at 3:28 AM Thomas Zimmermann
> > wrote:
> > >
> > > Hi Douglas,
> > >
> > > I understand that you're trying to tell userspace th
On Mon, May 09, 2022 at 07:54:19AM +0200, Christian König wrote:
> Reviewed-by: Christian König for the series.
>
> I assume you have the userspace part ready as well? If yes let's push this
> to drm-misc-next asap.
Hopefully I'm not too late, but I think all my review has also been
addressed. O
On Fri, May 06, 2022 at 04:10:05PM +0200, Christian König wrote:
> The selftests, fix the error handling, remove unused functions and stop
> leaking memory in failed tests.
>
> v2: fix the memory leak correctly.
>
> Signed-off-by: Christian König
I'm still a bit lost on all this (maybe add an e
On Fri, May 06, 2022 at 04:10:07PM +0200, Christian König wrote:
> dma_fence_chain containers cleanup signaled fences automatically, so
> filter those out from arrays as well.
>
> v2: fix missing walk over the array
> v3: massively simplify the patch and actually update the description.
>
> Signe
Apologies I'm constantly behind on m-l discussions :-/
On Tue, May 17, 2022 at 12:28:17PM +0200, Christian König wrote:
> Am 09.05.22 um 16:10 schrieb Daniel Vetter:
> > On Mon, May 09, 2022 at 08:56:41AM +0200, Christian König wrote:
> > > Am 04.05.22 um 12:08 schrieb Daniel Vetter:
> > > > On Mo
Il 23/05/22 12:47, Guillaume Ranquet ha scritto:
This patch adds External DisplayPort support to the mt8195 eDP driver.
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dp.c | 104 +++---
1 file changed, 81 insertions(+), 23 deletions(-)
Your patch
1 - 100 of 131 matches
Mail list logo
