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
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(+)
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
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
> >>>
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
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,
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.
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
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 ;)
---
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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 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
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
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:
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
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 +---
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
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:
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.
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.
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
> > >
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
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
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
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
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
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
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
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
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
ср, 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
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
> > >
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
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
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
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
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:
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
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 +++--
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
>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
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
вт, 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
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
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
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
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
вт, 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
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
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.
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
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.
>
>
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
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
Hi Linus Walleij
On 19/05/22 14:39, Linus Walleij wrote:
Nope. But add the rate limited error print please!
Will do.
Lots of magic numbers. You don't have a datasheet do you?
So you could #define some of the magic?
Unfortunately, I don't have a datasheet and the power on sequence is
taken
Il 23/05/22 12:47, Guillaume Ranquet ha scritto:
dpintf is the displayport interface hardware unit. This unit is similar
to dpi and can reuse most of the code.
This patch adds support for mt8195-dpintf to this dpi driver. Main
differences are:
- Some features/functional components are not
Hi,
On Mon, May 23, 2022 at 12:47:34PM +0200, Guillaume Ranquet wrote:
> From: Markus Schneider-Pargmann
>
> DPINTF is similar to DPI but does not have the exact same feature set
> or register layouts.
>
> DPINTF is the sink of the display pipeline that is connected to the
> DisplayPort
Il 23/05/22 12:47, Guillaume Ranquet ha scritto:
From: Markus Schneider-Pargmann
Similar to HDMI, DP uses audio infoframes as well which are structured
very similar to the HDMI ones.
This patch adds a helper function to pack the HDMI audio infoframe for
DP, called
Il 23/05/22 12:47, Guillaume Ranquet ha scritto:
This patch adds two helper functions that extract the frequency and word
length from a struct cea_sad.
For these helper functions new defines are added that help translate the
'freq' and 'byte2' fields into real numbers.
Signed-off-by: Markus
On 5/21/22 21:59, Tom Rix wrote:
> cppcheck reports
> [drivers/video/fbdev/xen-fbfront.c:226]: (style) Assignment of function
> parameter has no effect outside the function.
>
> The value parameter 'transp' is not used, so setting it can be removed.
>
> Signed-off-by: Tom Rix
applied to the
Il 23/05/22 12:47, Guillaume Ranquet ha scritto:
Signed-off-by: Guillaume Ranquet
---
include/drm/drm_edid.h | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 144c495b99c4..37c420423625 100644
---
1 - 100 of 126 matches
Mail list logo
