Hi Marco,
kernel test robot noticed the following build warnings:
[auto build test WARNING on c79b972eb88b077d2765e7790d0902b3dc94d55c]
url:
https://github.com/intel-lab-lkp/linux/commits/Marco-Pagani/drm-test-add-a-test-suite-for-GEM-objects-backed-by-shmem/20231120-230829
base
Hi David,
>
> On 18.11.23 07:32, Vivek Kasireddy wrote:
> > For drivers that would like to longterm-pin the pages associated
> > with a file, the pin_user_pages_fd() API provides an option to
> > not only pin the pages via FOLL_PIN but also to check and migrate
> > them if they reside in movable
the DMA buffer is released when still accessed by Mediatek display hardware,
this flow can lead to M4U reporting a translation fault warning
add dma buffer control flow in mediatek driver:
get dma buffer when drm plane disable
put dma buffer when overlay really disable
Fixes: 41016fe1028e ("drm:
> -Original Message-
> From: Ville Syrjälä
> Sent: Monday, November 20, 2023 7:57 PM
> To: Borah, Chaitanya Kumar
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH 2/4] drm/i915: Adjust LUT rounding rules
>
> On Mon, Nov 20, 2023 at
On Wed, Nov 15, 2023 at 11:33 AM Dmitry Baryshkov
wrote:
>
> On Wed, 15 Nov 2023 at 20:46, Dipam Turkar wrote:
> >
> > They are not outdated, my bad. I went through the locks' code and saw that
> > they have been updated. But they are probably not necessary here as most of
> > the drivers do
On 11/13/23 20:13, Abhinav Singh wrote:
This patch fixes a sparse warning with this message
"warning:dereference of noderef expression". In this context it means we
are dereferencing a __rcu tagged pointer directly.
We should not be directly dereferencing a rcu pointer. To get a normal
(non
Hello,
On Wed, Nov 01, 2023 at 06:20:17PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> The simple-framebuffer device tree bindings document the power-domains
> property, so make sure that simplefb supports it. This ensures that the
> power domains remain enabled as long as simplefb is
./drivers/gpu/drm/amd/display/dc/resource/dcn201/dcn201_resource.c:
dcn201/dcn201_hubbub.h is included more than once.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7583
Signed-off-by: Yang Li
---
From: Rob Clark
Replace the ww_mutex locking dance with the drm_exec helper.
v2: Error path fixes, move drm_exec_fini so we only call it once (and
only if we have drm_exec_init()
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/msm_gem.h
From: Rob Clark
In cases where the # is known ahead of time, it is silly to do the table
resize dance.
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
From: Rob Clark
Now that it only handles unlock duty, drop the superfluous arg and
rename it.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
From: Rob Clark
This was a small optimization for pre-soft-pin userspace. But mesa
switched to soft-pin nearly 5yrs ago. So lets drop the optimization
and simplify the code.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h| 2 --
drivers/gpu/drm/msm/msm_gem_submit.c | 44
From: Rob Clark
Untangle unpinning from unlock/unref loop. The unpin only happens in
error paths so it is easier to decouple from the normal unlock path.
Since we never have an intermediate state where a subset of buffers
are pinned (ie. we never bail out of the pin or unpin loops) we can
From: Rob Clark
We shouldn't be running the job in error cases. This also avoids having
to think too hard about where the objs get unpinned (and if necessary,
the resv takes over tracking that the obj is busy).. ie. error cases it
always happens synchronously, and normal cases it happens from
From: Rob Clark
The only point it is called is before pinning objects, so the "unpin"
part of the name is fiction. Just remove it and call submit_cleanup_bo()
directly.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_gem_submit.c | 10 ++
1 file
From: Rob Clark
Simplify the exec path (removing a legacy optimization) and convert to
drm_exec. One drm_exec patch to allow passing in the expected # of GEM
objects to avoid re-allocation.
I'd be a bit happier if I could avoid the extra objects table allocation
in drm_exec in the first place,
Hi Dave and Daniel,
Two fixups - fixing a potential error pointer dereference and wrong
error checking.
Ps. regarding the first patch, I had sent a GIT-PULL[1] but it seems
you missed.
[1]
https://lore.kernel.org/dri-devel/20231006040950.4397-1-inki@samsung.com/T/#u
Alex Deucher writes:
> Yes. Those changes went into 6.7 though, not 6.6 AFAIK. Maybe I'm
> misunderstanding what the original report was actually testing. If it
> was 6.7, then try reverting:
> 56e449603f0ac580700621a356d35d5716a62ce5
> b70438004a14f4d0f9890b3297cd66248728546c
I had been
Christian König writes:
> Well none of the commits mentioned can affect radeon in any way. Radeon
> simply doesn't use the scheduler.
>
> My suspicion is that the user is actually using amdgpu instead of
> radeon. The switch potentially occurred accidentally, for example by
> compiling amdgpu
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this
On Mon 2023-10-23 13:44:46, Miguel Ojeda wrote:
> On Mon, Oct 23, 2023 at 1:40 PM Jani Nikula
> wrote:
> >
> > One could also reasonably make the argument that controlling the
> > individual keyboard key backlights should be part of the input
> > subsystem. It's not a display per se. (Unless you
Hi!
> >> So... a bit of rationale. The keyboard does not really fit into the
> >> LED subsystem; LEDs are expected to be independent ("hdd led") and not
> >> a matrix of them.
> >
> > Makes sense.
> >
> >> We do see various strange displays these days -- they commonly have
> >> rounded corners
The mtk_dp driver registers a phy device which is handled by the
phy_mtk_dp driver and assumes that the phy probe will complete
synchronously, proceeding to make use of functionality exposed by that
driver right away. This assumption however is false when the phy driver
is built as a module,
Conor Dooley writes:
Hello Connor,
> On Thu, Nov 16, 2023 at 07:07:37PM +0100, Javier Martinez Canillas wrote:
>> This is used to specify the page start address offset of the display RAM.
>>
>> The value is used as offset when setting the page start address with the
>> SSD130X_SET_PAGE_RANGE
Hi,
On Sun, Nov 19, 2023 at 6:01 PM Cong Yang
wrote:
>
> The refresh reported by modetest is 60.46Hz, and the actual measurement
> is 60.01Hz, which is outside the expected tolerance. Adjust hporch and
> pixel clock to fix it. After repair, modetest and actual measurement were
> all 60.01Hz.
>
>
Hi,
On Sun, Nov 19, 2023 at 5:33 PM cong yang
wrote:
>
> Hi,
>
> On Sat, Nov 18, 2023 at 1:11 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, Nov 16, 2023 at 7:25 PM Cong Yang
> > wrote:
> > >
> > > The refresh reported by modetest is 60.46Hz, and the actual measurement
> > > is 60.01Hz,
https://bugzilla.kernel.org/show_bug.cgi?id=218168
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, Nov 20, 2023 at 11:24 AM Christian König
wrote:
>
> Am 20.11.23 um 17:08 schrieb Alex Deucher:
> > On Mon, Nov 20, 2023 at 10:57 AM Christian König
> > wrote:
> >> Am 19.11.23 um 07:47 schrieb Dave Airlie:
> On 12.11.23 01:46, Phillip Susi wrote:
> > I had been testing some
Hi Johan,
Am Donnerstag, 2. November 2023, 14:42:19 CET schrieb Johan Jonker:
> The Rk3066 hdmi output format is hard coded to RGB. Remove
> all useless code related to colorimetry and enc_out_format.
>
> Signed-off-by: Johan Jonker
I guess my first question is, is the hardcoding happening
On Wed, 25 Oct 2023 21:32:46 +, Jonas Karlman wrote:
> Add support for the 10-bit 4:2:2 and 4:4:4 formats NV20 and NV30.
>
> These formats can be tested using modetest [1]:
>
> modetest -P @:1920x1080@
>
> e.g. on a ROCK 3 Model A (rk3568):
>
> [...]
Applied, thanks!
[1/1]
On Thu, 2 Nov 2023 14:40:13 +0100, Johan Jonker wrote:
> Update the Rockchip rk3066_hdmi driver in a somewhat similar way
> to what is proposed for the inno_hdmi driver.
>
> Johan Jonker (4):
> drm/rockchip: rk3066_hdmi: Remove useless mode_fixup
> drm/rockchip: rk3066_hdmi: Switch encoder
Am 20.11.23 um 17:28 schrieb Thomas Zimmermann:
Hi
Am 20.11.23 um 17:22 schrieb Christian König:
Am 20.11.23 um 17:15 schrieb Felix Kuehling:
On 2023-11-20 11:02, Thomas Zimmermann wrote:
Hi Christian
Am 20.11.23 um 16:22 schrieb Christian König:
Am 20.11.23 um 16:18 schrieb Thomas
Hi
Am 20.11.23 um 17:22 schrieb Christian König:
Am 20.11.23 um 17:15 schrieb Felix Kuehling:
On 2023-11-20 11:02, Thomas Zimmermann wrote:
Hi Christian
Am 20.11.23 um 16:22 schrieb Christian König:
Am 20.11.23 um 16:18 schrieb Thomas Zimmermann:
Hi
Am 20.11.23 um 16:06 schrieb Felix
Hi
Am 20.11.23 um 17:15 schrieb Felix Kuehling:
On 2023-11-20 11:02, Thomas Zimmermann wrote:
Hi Christian
Am 20.11.23 um 16:22 schrieb Christian König:
Am 20.11.23 um 16:18 schrieb Thomas Zimmermann:
Hi
Am 20.11.23 um 16:06 schrieb Felix Kuehling:
On 2023-11-20 6:54, Thomas Zimmermann
Am 20.11.23 um 17:08 schrieb Alex Deucher:
On Mon, Nov 20, 2023 at 10:57 AM Christian König
wrote:
Am 19.11.23 um 07:47 schrieb Dave Airlie:
On 12.11.23 01:46, Phillip Susi wrote:
I had been testing some things on a post 6.6-rc5 kernel for a week or
two and then when I pulled to a post 6.6
Am 20.11.23 um 17:15 schrieb Felix Kuehling:
On 2023-11-20 11:02, Thomas Zimmermann wrote:
Hi Christian
Am 20.11.23 um 16:22 schrieb Christian König:
Am 20.11.23 um 16:18 schrieb Thomas Zimmermann:
Hi
Am 20.11.23 um 16:06 schrieb Felix Kuehling:
On 2023-11-20 6:54, Thomas Zimmermann
On 2023-11-20 11:02, Thomas Zimmermann wrote:
Hi Christian
Am 20.11.23 um 16:22 schrieb Christian König:
Am 20.11.23 um 16:18 schrieb Thomas Zimmermann:
Hi
Am 20.11.23 um 16:06 schrieb Felix Kuehling:
On 2023-11-20 6:54, Thomas Zimmermann wrote:
Hi
Am 17.11.23 um 22:44 schrieb Felix
On Thu, 26 Oct 2023 19:14:58 +, Jonas Karlman wrote:
> Use of DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888 on e.g. RK3288, RK3328
> and RK3399 result in wrong colors being displayed.
>
> The issue can be observed using modetest:
>
> modetest -s @:1920x1080-60@RG24
> modetest -s
On Mon, Nov 20, 2023 at 10:57 AM Christian König
wrote:
>
> Am 19.11.23 um 07:47 schrieb Dave Airlie:
> >> On 12.11.23 01:46, Phillip Susi wrote:
> >>> I had been testing some things on a post 6.6-rc5 kernel for a week or
> >>> two and then when I pulled to a post 6.6 release kernel, I found that
Hi Christian
Am 20.11.23 um 16:22 schrieb Christian König:
Am 20.11.23 um 16:18 schrieb Thomas Zimmermann:
Hi
Am 20.11.23 um 16:06 schrieb Felix Kuehling:
On 2023-11-20 6:54, Thomas Zimmermann wrote:
Hi
Am 17.11.23 um 22:44 schrieb Felix Kuehling:
This reverts commit
Am 19.11.23 um 07:47 schrieb Dave Airlie:
On 12.11.23 01:46, Phillip Susi wrote:
I had been testing some things on a post 6.6-rc5 kernel for a week or
two and then when I pulled to a post 6.6 release kernel, I found that
system suspend was broken. It seems that the radeon driver failed to
On Thu, Nov 16, 2023 at 07:07:37PM +0100, Javier Martinez Canillas wrote:
> This is used to specify the page start address offset of the display RAM.
>
> The value is used as offset when setting the page start address with the
> SSD130X_SET_PAGE_RANGE command, and the driver currently sets its
https://bugzilla.kernel.org/show_bug.cgi?id=218168
--- Comment #1 from hamza.mahf...@amd.com ---
+ amd-gfx
+ Felix
On 11/20/23 10:16, bugzilla-dae...@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=218168
>
> Bug ID: 218168
> Summary: amdgpu:
+ amd-gfx
+ Felix
On 11/20/23 10:16, bugzilla-dae...@kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=218168
Bug ID: 218168
Summary: amdgpu: kfd_topology.c warning: the frame size of 1408
bytes is larger than 1024 bytes
On Fri, 17 Nov 2023 14:25:30 -0600, Chris Morgan wrote:
> From: Chris Morgan
>
> Add support for the Powkiddy RK2023, which is extremely similar to
> existing Powkiddy RGB30 device.
>
> Changes since V3:
> - Corrected commit subject lines.
>
> [...]
Applied, thanks!
[4/6] dt-bindings: arm:
Am 20.11.23 um 16:18 schrieb Thomas Zimmermann:
Hi
Am 20.11.23 um 16:06 schrieb Felix Kuehling:
On 2023-11-20 6:54, Thomas Zimmermann wrote:
Hi
Am 17.11.23 um 22:44 schrieb Felix Kuehling:
This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
These helper functions are needed for
Hi
Am 20.11.23 um 16:06 schrieb Felix Kuehling:
On 2023-11-20 6:54, Thomas Zimmermann wrote:
Hi
Am 17.11.23 um 22:44 schrieb Felix Kuehling:
This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
These helper functions are needed for KFD to export and import DMABufs
the right way
https://bugzilla.kernel.org/show_bug.cgi?id=218168
Bug ID: 218168
Summary: amdgpu: kfd_topology.c warning: the frame size of 1408
bytes is larger than 1024 bytes
Product: Drivers
Version: 2.5
Hardware: All
On Mon, Nov 20, 2023 at 10:41:18PM +0800, Edward Adam Davis wrote:
> [Syz Log]
> divide error: [#1] PREEMPT SMP KASAN
> CPU: 0 PID: 5068 Comm: syz-executor357 Not tainted
> 6.6.0-syzkaller-16039-gac347a0655db #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>
Am 20.11.23 um 12:54 schrieb Thomas Zimmermann:
Hi
Am 17.11.23 um 22:44 schrieb Felix Kuehling:
This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
These helper functions are needed for KFD to export and import DMABufs
the right way without duplicating the tracking of DMABufs
On 2023-11-20 6:54, Thomas Zimmermann wrote:
Hi
Am 17.11.23 um 22:44 schrieb Felix Kuehling:
This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
These helper functions are needed for KFD to export and import DMABufs
the right way without duplicating the tracking of DMABufs
This patch introduces an initial KUnit test suite for GEM objects
backed by shmem buffers.
Suggested-by: Javier Martinez Canillas
Signed-off-by: Marco Pagani
v3:
- Explicitly cast pointers in the helpers
- Removed unused pointer to parent dev in struct fake_dev
- Test entries reordering in
[Syz Log]
divide error: [#1] PREEMPT SMP KASAN
CPU: 0 PID: 5068 Comm: syz-executor357 Not tainted
6.6.0-syzkaller-16039-gac347a0655db #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
10/09/2023
RIP: 0010:drm_mode_vrefresh drivers/gpu/drm/drm_modes.c:1303
On Thursday, 26 October 2023 21:14:58 CET Jonas Karlman wrote:
> Use of DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888 on e.g. RK3288, RK3328
> and RK3399 result in wrong colors being displayed.
>
> The issue can be observed using modetest:
>
> modetest -s @:1920x1080-60@RG24
> modetest -s
On Fri, Oct 13, 2023 at 04:13:58PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The current LUT rounding is generating weird results. Adjust
> it to follow the OpenGL int<->float conversion rules.
>
> Ville Syrjälä (4):
> drm: Fix color LUT rounding
^
I'd like to merge this via
On Mon, Nov 20, 2023 at 01:17:05PM +, Borah, Chaitanya Kumar wrote:
>
>
> > -Original Message-
> > From: Borah, Chaitanya Kumar
> > Sent: Monday, November 20, 2023 6:33 PM
> > To: Ville Syrjälä
> > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Jani
> > Nikula
On Mon, Nov 20, 2023 at 06:08:57AM +, Borah, Chaitanya Kumar wrote:
> Hello Ville,
>
> > -Original Message-
> > From: dri-devel On Behalf Of Ville
> > Syrjala
> > Sent: Friday, October 13, 2023 6:44 PM
> > To: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
>
Il 19/11/23 12:28, Heiner Kallweit ha scritto:
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove
Hi Fabio,
On 11/17/23 20:27, Fabio Estevam wrote:
Hi Quentin,
On Fri, Nov 17, 2023 at 3:31 PM Quentin Schulz wrote:
From: Quentin Schulz
This scary message may happen if the panel or bridge is not probed
before the LVDS controller is, resulting in some head scratching because
the LVDS
On Mon, 20 Nov 2023, Imre Deak wrote:
> On Mon, Nov 20, 2023 at 02:31:34PM +0200, Jani Nikula wrote:
>> On Thu, 16 Nov 2023, Imre Deak wrote:
>> > This is v2 of [1], with the following changes:
>> > - Store the pbn_div value in fixed point format.
>> > - Fix PBN calculation in patch 8.
>> > -
> -Original Message-
> From: Borah, Chaitanya Kumar
> Sent: Monday, November 20, 2023 6:33 PM
> To: Ville Syrjälä
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Jani
> Nikula
> Subject: RE: [Intel-gfx] [PATCH 1/4] drm: Fix color LUT rounding
>
> Hello Ville,
On Mon, Nov 20, 2023 at 02:31:34PM +0200, Jani Nikula wrote:
> On Thu, 16 Nov 2023, Imre Deak wrote:
> > This is v2 of [1], with the following changes:
> > - Store the pbn_div value in fixed point format.
> > - Fix PBN calculation in patch 8.
> > - Reuse intel_dp_max_data_rate(),
David Jagu (1):
meson: fix typo in libdrm_intel
Geert Uytterhoeven (18):
util: improve SMPTE color LUT accuracy
util: factor out and optimize C8 SMPTE color LUT
util: add support for DRM_FORMAT_C[124]
util: store number of colors for indexed formats
util: add
Hello Ville,
> -Original Message-
> From: dri-devel On Behalf Of Ville
> Syrjälä
> Sent: Tuesday, October 31, 2023 9:37 PM
> To: Jani Nikula
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/4] drm: Fix color LUT rounding
>
> On
Add kunit test cases for drm_dp_get_vc_payload_bw() with all the DP1.4
and UHBR link configurations.
v2:
- List test cases in decreasing rate,lane count order matching the
corresponding DP Standard tables. (Ville)
- Add references to the DP Standard tables.
v3:
- Sort the testcases properly.
On Thu, 16 Nov 2023, Imre Deak wrote:
> This is v2 of [1], with the following changes:
> - Store the pbn_div value in fixed point format.
> - Fix PBN calculation in patch 8.
> - Reuse intel_dp_max_data_rate(), intel_dp_effective_data_rate() in
> intel_link_compute_m_n() (Jani).
>
> [1]
From: Quentin Schulz
This scary message can misled the user into thinking something bad has
happened and needs to be fixed, however it could simply be part of a
normal boot process where EPROBE_DEFER is taken into account. Therefore,
let's use dev_err_probe so that this message doesn't get shown
From: Quentin Schulz
ret variable stores the return value of drm_of_find_panel_or_bridge
which can return error codes different from EPROBE_DEFER. Therefore,
let's just return that error code instead of forcing it to EPROBE_DEFER.
Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc
drm_of_find_panel_or_bridge may return a different error code than
EPROBE_DEFER so let's not overwrite it.
At the same time, let's demote the DRM_DEV_ERROR message to
dev_err_probe so that the scary message isn't shown (by default)
whenever EPROBE_DEFER is returned to not mislead users.
A643 (A635 speedbin 0xac) tops out at 812 MHz. Fill in the
opp-supported-hw appropriately.
Note that fuseval 0xac is referred to as speedbin 1 downstream, but
that was already in use upstream, so 2 was chosen instead.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 12
The SMMUs on sc7280 are cache-coherent. APPS_SMMU is marked as such,
mark the GPU one as well.
Fixes: 96c471970b7b ("arm64: dts: qcom: sc7280: Add gpu support")
Reviewed-by: Akhil P Oommen
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 1 +
1 file changed, 1
GPU_SMMU SID 1 is meant for Adreno LPAC (Low Priority Async Compute).
On platforms that support it (in firmware), it is necessary to
describe that link, or Adreno register access will hang the board.
The current settings are functionally identical, *but* due to what is
likely hardcoded security
Non-Chrome SC7280-family platforms ship a ZAP shader with the Adreno GPU.
Describe that and make sure it doesn't interfere with Chrome devices.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 2 ++
arch/arm64/boot/dts/qcom/sc7280.dtsi | 9
as it says on the can
drm/msm patches for Rob
arm64 patches for linux-arm-msm
for use with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25408
tested on QCM6490 (SC7280-IOT) Fairphone FP5
Signed-off-by: Konrad Dybcio
---
Changes in v2:
- Drop drm/msm patches (all applied)
- Make
[Dropped a few people from To that resulted in bounces before.]
On Thu, Nov 02, 2023 at 05:56:41PM +0100, Uwe Kleine-König wrote:
> Hello,
>
> this series converts all platform drivers below drivers/gpu/drm to use
> .remove_new(). It starts with a fix for a problem that potentially might
> crash
Hi
Am 17.11.23 um 22:44 schrieb Felix Kuehling:
This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
These helper functions are needed for KFD to export and import DMABufs
the right way without duplicating the tracking of DMABufs associated with
GEM objects while ensuring that move
On 11/20/23 14:19, Boris Brezillon wrote:
...
- dma_resv_lock(shmem->base.resv, NULL);
-
drm_WARN_ON(obj->dev, refcount_read(>vmap_use_count));
if (shmem->sgt) {
@@ -157,8 +171,6 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
Am 19.11.23 um 11:14 schrieb Heiner Kallweit:
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove
Am 19.11.23 um 11:14 schrieb Heiner Kallweit:
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove
On Sun, 19 Nov 2023, Edward Adam Davis wrote:
> [Syz Log]
> divide error: [#1] PREEMPT SMP KASAN
> CPU: 0 PID: 5068 Comm: syz-executor357 Not tainted
> 6.6.0-syzkaller-16039-gac347a0655db #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 10/09/2023
>
1 - 100 of 127 matches
Mail list logo
