On 19/11/2023 12:28, Heiner Kallweit wrote:
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 17/11/2023 20:44, Chris Morgan wrote:
From: Chris Morgan
The driver shutdown is duplicate as it calls drm_unprepare and
drm_disable which are called anyway when associated drivers are
shutdown/removed.
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 17
On 19/11/2023 20:50, Marek Vasut wrote:
On 11/17/23 09:40, Maxime Ripard wrote:
On Thu, Nov 16, 2023 at 10:15:31PM +0100, Marek Vasut wrote:
On 10/9/23 10:58, Neil Armstrong wrote:
On 09/10/2023 00:33, Marek Vasut wrote:
Add missing .bus_flags = DRM_BUS_FLAG_DE_HIGH to this panel
Hi,
On 17.11.2023 18:43, Jeffrey Hugo wrote:
> From: Carl Vanderlip
>
> 'in_reset' holds the state of the device. As part of bringup, the device
> needs to be queried to check if it's in a valid state. Add a new state
> that indicates that the device is coming up, but not ready for users
> yet.
On Thu, Nov 16, 2023 at 01:05:52PM -0800, Abhinav Kumar wrote:
>
>
> On 11/1/2023 12:23 PM, Abhinav Kumar wrote:
> >
> >
> > On 10/13/2023 1:25 AM, Dan Carpenter wrote:
> > > This NULL check was required when it was added, but we shuffled the code
> > > around and now it's not.? The
On 11/6/2023 11:26 AM, Yong Wu (吴勇) wrote:
> On Wed, 2023-11-01 at 11:20 +0530, Jaskaran Singh wrote:
>>
>> External email : Please do not click links or open attachments until
>> you have verified the sender or the content.
>> On 10/20/2023 3:20 PM, Yong Wu (吴勇) wrote:
>>> On Thu,
On 17/11/2023 18:14, Sui Jingfeng wrote:
Hi,
On 2023/11/17 17:03, Dmitry Baryshkov wrote:
On Fri, 17 Nov 2023 at 06:24, Sui Jingfeng wrote:
Hi,
On 2023/11/16 23:23, Dmitry Baryshkov wrote:
Then you will need some way (fwnode?) to
discover the bridge chain. And at the last point you will
Hi Linus,
On Wednesday, November 15, 2023 6:00 AM, Linus Walleij
wrote:
> On Mon, Aug 7, 2023 at 8:06 AM Liu Ying wrote:
>
> > Add the device link when panel bridge is attached and delete the link
> > when panel bridge is detached. The drm device is the consumer while
> > the panel device is
On 11/10/23 13:16, Boris Brezillon wrote:
> On Mon, 30 Oct 2023 02:01:50 +0300
> Dmitry Osipenko wrote:
>
>> Prepare drm_gem_shmem_free() to addition of memory shrinker support
>> to drm-shmem by adding and using variant of put_pages() that doesn't
>> touch reservation lock. Reservation
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 zone or CMA block. This API
Polling firmware HPD GPIO status, set HPD irq detect window to 2ms
after firmware HPD GPIO initial done
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 51 ---
drivers/gpu/drm/bridge/analogix/anx7625.h | 4 ++
2 files changed, 40 insertions(+), 15
This reverts commit 330140d7319fcc4ec68bd924ea212e476bf12275
200ms delay will cause panel display image later than backlight
turn on, revert this patch.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 3 ---
1 file changed, 3 deletions(-)
diff --git
Am 17.11.23 um 19:50 schrieb T.J. Mercier:
On Thu, Nov 16, 2023 at 11:14 AM Kees Cook wrote:
strlcpy() reads the entire source buffer first. This read may exceed
the destination size limit. This is both inefficient and can lead
to linear read overflows if a source string is not
On Mon, 13 Nov 2023, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> There is no need to return anything in the version which was merged and
> also the implementation of the !CONFIG_PROC_FS wasn't returning anything,
> causing a build failure there.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes:
Hi Tvrtko,
On Mon, Nov 13, 2023 at 08:54:57AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> __rcu annotation is needed to avoid the sparse warnings such as:
>
> .../i915_drm_client.c:92:9: sparse: sparse: incompatible types in
> comparison expression (different address spaces):
>
Hi,
On Fri, 17 Nov 2023 13:44:00 -0600, Chris Morgan wrote:
> From: Chris Morgan
>
> Fix a few bugs and clean up no longer needed code on the Elida KD35T133
> DSI panel, as used in devices such as the Odroid Go Advance and the
> Anbernic RG351M.
>
> Changes since V1:
> - Split removal of
On Fri, 17 Nov 2023 at 19:36, Sui Jingfeng wrote:
>
> Hi,
>
>
> On 2023/11/17 17:03, Dmitry Baryshkov wrote:
> > On Fri, 17 Nov 2023 at 06:24, Sui Jingfeng wrote:
> >> Hi,
> >>
> >> On 2023/11/16 23:23, Dmitry Baryshkov wrote:
> >> Then you will need some way (fwnode?) to
> >> discover
On Mon, 13 Nov 2023, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> __rcu annotation is needed to avoid the sparse warnings such as:
>
> .../i915_drm_client.c:92:9: sparse: sparse: incompatible types in
> comparison expression (different address spaces):
> .../i915_drm_client.c:92:9:
Hi Tvrtko,
On Mon, Nov 13, 2023 at 08:54:56AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> There is no need to return anything in the version which was merged and
> also the implementation of the !CONFIG_PROC_FS wasn't returning anything,
> causing a build failure there.
>
>
On Tue, 2023-11-14 at 17:42 +0100, Danilo Krummrich wrote:
> *** CAUTION: This email originates from a source not known to Imagination
> Technologies. Think before you click a link or open an attachment ***
>
> On 10/31/23 16:12, Sarah Walker wrote:
> > From: Donald Robson
> >
> > Determining
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
>
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
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 Fri, Nov 17, 2023 at 10:41:34AM +0100, Maxime Ripard wrote:
> Hi,
>
> Here's the first drm-misc-next PR for what will become 6.8.
>
> There's one missing SoB on the commit 0da611a87021 ("dma-buf: add
> dma_fence_timestamp helper") from the committer. They provided their SoB
> on the ML here
Hi
Am 20.11.23 um 09:52 schrieb Hans Verkuil:
Hi Thomas,
On 15/11/2023 11:19, Thomas Zimmermann wrote:
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. This explictily sets
the read/write, draw and mmap callbacks to the correct
On 17/11/2023 20:44, Chris Morgan wrote:
From: Chris Morgan
Drop the prepare/unprepare logic, as this is now tracked elsewhere
since this commit [1].
[1] commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in
drm_panel")
Signed-off-by: Chris Morgan
---
Hi,
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.
>
> [...]
Thanks, Applied to
Hi Thomas,
On 15/11/2023 11:19, Thomas Zimmermann wrote:
> Initialize the instance of struct fb_ops with fbdev initializer
> macros for framebuffers in I/O address space. This explictily sets
> the read/write, draw and mmap callbacks to the correct default
> implementation.
>
> Fbdev drivers
Hi Sui,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.7-rc2 next-20231120]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
On Mon, 20 Nov 2023 14:02:29 +0300
Dmitry Osipenko wrote:
> On 11/10/23 13:16, Boris Brezillon wrote:
> > On Mon, 30 Oct 2023 02:01:50 +0300
> > Dmitry Osipenko wrote:
> >
> >> Prepare drm_gem_shmem_free() to addition of memory shrinker support
> >> to drm-shmem by adding and using variant
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
[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
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(),
> -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, 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.
>> > -
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 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]
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.
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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 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
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
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
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
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
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
>
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 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
[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
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
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 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
>
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 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 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
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
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
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:
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 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
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]
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 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!
> >> 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
./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
---
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 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
https://bugzilla.kernel.org/show_bug.cgi?id=218168
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
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
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
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
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
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
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
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,
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
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
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.
>
>
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
1 - 100 of 127 matches
Mail list logo
