Create rotation property according to the hardware capability.
Fixes: 84d805753983 ("drm/mediatek: Support reflect-y plane rotation")
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 1 +
drivers/gpu/drm/mediatek/mtk_
This commit is based on 20231024130048.14749-1-shawn.s...@mediatek.com.
This bug is found when running IGT tests.
For CRTCs that doesn't support rotation should still return
DRM_MODE_ROTATE_0, otherwise the test will fail to restart.
Returns the hardware capabilities accordingly.
Changes in v3:
-
Hi
Am 18.11.23 um 16:06 schrieb Sui Jingfeng:
Hi,
On 2023/11/16 17:59, Thomas Zimmermann wrote:
Detecting the ast device's chipset type and configuration mode
involves several registers, DT properties and possibly POSTing
parts of the chip. It is preferable to do this before initializing
the
> -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
> Subject: [PATCH 4/4] drm/i915: Fix glk+ degamma LUT conversions
>
> From: Ville Syrjälä
>
> The curr
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
> Subject: [PATCH 2/4] drm/i915: Adjust LUT rounding rules
>
> From: Ville Syrjälä
>
> d
tree: git://anongit.freedesktop.org/drm-intel for-linux-next-gt
head: 3c7a5eb700661e8905ab4e50c2d09c6568125280
commit: e4ae85e364fc652ea15d85b0f3a6da304c9b5ce7 [1/6] drm/i915: Add ability
for tracking buffer objects per client
config: i386-buildonly-randconfig-006-20231120
(https://download.0
On Sun, 2023-11-19 at 11:56 +0100, Javier Martinez Canillas wrote:
> Hello,
>
> This series is to fix an issue that surfaced after damage clipping was
> enabled for the virtio-gpu by commit 01f05940a9a7 ("drm/virtio: Enable
> fb damage clips property for the primary plane").
>
> After that change,
From: Dave Airlie
The fence code uses the total number of channel ids to allocate a
bunch of memory for fencing. This is probably not the best way to
do this, but it's hard to fix right now.
The GSP code realises it can fit 8 channels into a USERD
page, so it claims it can support 256 channels m
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.
Modetest refresh = Pixel CLK/ htotal* vtotal, but measurement frame
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, which is outside the expected tolerance.
>
> Presumably you've swapped the numbe
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
between commits:
a58555359a9f ("drm/amd/display: Fix DSC not Enabled on Direct MST Sink")
c29085d29562 ("drm/amd/display: Enable DSC Flag in MST Mode Valid
On Sun, 19 Nov 2023 at 13: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
On 11/19/23 21:51, Heiner Kallweit wrote:
On 19.11.2023 21:48, Heiner Kallweit wrote:
On 19.11.2023 21:28, Helge Deller wrote:
On 11/19/23 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
On 19.11.2023 21:48, Heiner Kallweit wrote:
> On 19.11.2023 21:28, Helge Deller wrote:
>> On 11/19/23 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 de
On 19.11.2023 21:28, Helge Deller wrote:
> On 11/19/23 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 shou
On 11/19/23 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 this c
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 description,
ones which match both the datasheet and
Hi Christian,
On Sun, Nov 19, 2023 at 5:28 PM Christian Zigotzky
wrote:
> On 16 November 2023 at 03:44 pm, Gerd Hoffmann wrote:
> > On Thu, Nov 16, 2023 at 02:16:54PM +0100, Geert Uytterhoeven wrote:
> >> When using virtgpu on a big-endian machine, e.g. powerpc QEMU:
> >>
> >> virtio-pci 000
On 16 November 2023 at 03:44 pm, Gerd Hoffmann wrote:
On Thu, Nov 16, 2023 at 02:16:54PM +0100, Geert Uytterhoeven wrote:
When using virtgpu on a big-endian machine, e.g. powerpc QEMU:
virtio-pci :00:02.0: [drm] *ERROR* fbdev: Failed to setup generic
emulation (ret=-2)
or m68k/virt:
On 11/19/23 20:48, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 19.11.23 14:24, Bagas Sanjaya wrote:
>> Hi Dave,
>>
>> AFAIK commit c07bf1636f0005 ("MAINTAINERS: Update the GPU Scheduler email")
>> doesn't seem to do with this regression as it doesn't change any amdgpu code
>> that may
On 19.11.23 14:24, Bagas Sanjaya wrote:
> On Sun, Nov 19, 2023 at 04:47:01PM +1000, Dave Airlie wrote:
>>> 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 Sun, Nov 19, 2023 at 04:47:01PM +1000, Dave Airlie wrote:
> >
> > 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 se
Respected maintainers,
Looking at the code and the call trace reported by Syzbot, I understood
that the issue lies in the drm_gem.c file in
drm_gem_object_handle_put_unlocked(obj);. As per my understanding, I
believe that a warning is given out when the DRM GEM object handle gets
destroyed along
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
The "Damage Tracking Properties" section in the documentation doesn't have
info about the two type of damage handling: frame damage vs buffer damage.
Add it to the section and mention that helpers only support frame damage,
and how drivers handling buffer damage can indicate that the damage clips
Currently, only damage tracking for frame damage is supported. If a driver
needs to do buffer damage (e.g: the framebuffer attached to plane's state
has changed since the last page-flip), the damage helpers just fallback to
a full plane update.
Add en entry in the TODO about implementing buffer ag
The driver does per-buffer uploads and needs to force a full plane update
if the plane's attached framebuffer has change since the last page-flip.
Suggested-by: Sima Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
---
(no changes since v2)
Changes in v2:
- Set st
The driver does per-buffer uploads and needs to force a full plane update
if the plane's attached framebuffer has change since the last page-flip.
Fixes: 01f05940a9a7 ("drm/virtio: Enable fb damage clips property for the
primary plane")
Cc: # v6.4+
Reported-by: nerdopolis
Closes: https://bugzil
It allows drivers to set a struct drm_plane_state .ignore_damage_clips in
their plane's .atomic_check callback, as an indication to damage helpers
such as drm_atomic_helper_damage_iter_init() that the damage clips should
be ignored.
To be used by drivers that do per-buffer (e.g: virtio-gpu) upload
Hello,
This series is to fix an issue that surfaced after damage clipping was
enabled for the virtio-gpu by commit 01f05940a9a7 ("drm/virtio: Enable
fb damage clips property for the primary plane").
After that change, flickering artifacts was reported to be present with
both weston and wlroots wa
Hi,
At FOSDEM on Sunday the 4th of February, there will the 15th Graphics
DevRoom.
URL: https://fosdem.org/2024/
The talk topics of the graphics devroom encompass:
* graphics drivers: display, 2d engines, 3d engines, at bootloader,
kernel and userspace levels.
* media drivers: camera/capture
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
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 series
71 matches
Mail list logo
