Hi,
> + dri-devel mailing list that looks more appropriated.
> + Hans and Lyude who were recently working to standardize some of the
> backlight stuff.
Thank you for these contacts. I'll try there if I need.
> I don't believe you want to use the i915 API, but move the common functions
> to the
Hi, Kevin,
在 2022/9/9 18:22, Kevin Tian 写道:
The idea is to let vfio core manage the vfio_device life cycle instead
of duplicating the logic cross drivers. This is also a preparatory
step for adding struct device into vfio_device.
New pair of helpers together with a kref in vfio_device:
- vfi
> Yes, lines 0-23 is the entire blanking area. And the "back porch" in this
> context is everything from the start of the sync pulse to the start of active
> video. It's not just the equalizing pulses.
I meant "from the end of the sync pulse", obviously. Sorry about the slipup.
Hi Maxime,
W dniu 9.09.2022 o 15:54, Maxime Ripard pisze:
> Hi,
>
> On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote:
> [...]
>> I think you're confusing the "post-equalizing pulses" with the "vertical back
>> porch" a little bit. The "vertical back porch" includes both the
>>
W dniu 9.09.2022 o 11:46, Maxime Ripard pisze:
> On Wed, Sep 07, 2022 at 09:52:09PM +0200, Mateusz Kwiatkowski wrote:
>> W dniu 7.09.2022 o 14:10, Maxime Ripard pisze:
>>> Hi,
>>>
>>> On Fri, Sep 02, 2022 at 12:00:33AM +0200, Mateusz Kwiatkowski wrote:
W dniu 29.08.2022 o 15:11, Maxime Ripard
Hi Maxime,
W dniu 9.09.2022 o 16:00, Maxime Ripard pisze:
> On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote:
>> The "canonical" modelines (at least for vc4's VEC, see the notes below):
>>
>> - (vfp==4, vsync==6, vbp==39) for 576i
>> - (vfp==7, vsync==6, vbp==32) for 480i
>> - (
Hi Maíra,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on next-20220909]
[cannot apply to linus/master v6.0-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch
As made mention of in commit 9f0ac028410f ("drm/print: rename drm_debug
to __drm_debug to discourage use"), we shouldn't explicitly refer to
__drm_debug in this context. So, use drm_debug_enabled() instead.
Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
Signed-off-by: Hamza Mahfooz
---
dr
With the introduction of KUnit, IGT is no longer the only option to run
the DRM unit tests, as the tests can be run through kunit-tool or on
real hardware with CONFIG_KUNIT.
Therefore, remove the "igt_" prefix from the tests and replace it with
the "drm_test_" prefix, making the tests' names indep
The igt_check_drm_framebuffer_create is based on a loop that executes
tests for all createbuffer_tests test cases. This could be better
represented by parameterized tests, provided by KUnit.
So, convert the igt_check_drm_framebuffer_create into parameterized tests.
Signed-off-by: Maíra Canal
Rev
From: Rob Clark
[ Upstream commit 174974d8463b77c2b4065e98513adb204e64de7d ]
If the previous thing cat'ing $debugfs/rd left the FIFO full, then
subsequent open could deadlock in rd_write() (because open is blocked,
not giving a chance for read() to consume any data in the FIFO). Also
it is gene
From: Rob Clark
[ Upstream commit 174974d8463b77c2b4065e98513adb204e64de7d ]
If the previous thing cat'ing $debugfs/rd left the FIFO full, then
subsequent open could deadlock in rd_write() (because open is blocked,
not giving a chance for read() to consume any data in the FIFO). Also
it is gene
From: Rob Clark
[ Upstream commit 174974d8463b77c2b4065e98513adb204e64de7d ]
If the previous thing cat'ing $debugfs/rd left the FIFO full, then
subsequent open could deadlock in rd_write() (because open is blocked,
not giving a chance for read() to consume any data in the FIFO). Also
it is gene
From: Rob Clark
[ Upstream commit 174974d8463b77c2b4065e98513adb204e64de7d ]
If the previous thing cat'ing $debugfs/rd left the FIFO full, then
subsequent open could deadlock in rd_write() (because open is blocked,
not giving a chance for read() to consume any data in the FIFO). Also
it is gene
From: Chengming Gui
[ Upstream commit 39c84b8e929dbd4f63be7e04bf1a2bcd92b44177 ]
Restrict the ucode loading check to avoid frontdoor loading error.
Signed-off-by: Chengming Gui
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/
From: Rob Clark
[ Upstream commit 174974d8463b77c2b4065e98513adb204e64de7d ]
If the previous thing cat'ing $debugfs/rd left the FIFO full, then
subsequent open could deadlock in rd_write() (because open is blocked,
not giving a chance for read() to consume any data in the FIFO). Also
it is gene
From: Chengming Gui
[ Upstream commit 39c84b8e929dbd4f63be7e04bf1a2bcd92b44177 ]
Restrict the ucode loading check to avoid frontdoor loading error.
Signed-off-by: Chengming Gui
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/
From: Rob Clark
[ Upstream commit 174974d8463b77c2b4065e98513adb204e64de7d ]
If the previous thing cat'ing $debugfs/rd left the FIFO full, then
subsequent open could deadlock in rd_write() (because open is blocked,
not giving a chance for read() to consume any data in the FIFO). Also
it is gene
From: Chengming Gui
[ Upstream commit 39c84b8e929dbd4f63be7e04bf1a2bcd92b44177 ]
Restrict the ucode loading check to avoid frontdoor loading error.
Signed-off-by: Chengming Gui
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/
From: Evan Quan
[ Upstream commit b023053592646b1da9477b0b598f2cdd5d3f89d8 ]
For those SMU13.0.7 unsecure SKUs, the vbios carried pptable is ready to go.
Use that one instead of hardcoded softpptable.
Signed-off-by: Evan Quan
Reviewed-by: Kenneth Feng
Signed-off-by: Alex Deucher
Signed-off-b
From: Guchun Chen
[ Upstream commit c8fea9273fd1be308668496badfcbd55183e0dd3 ]
Below driver load error will be printed, not friendly to end user.
amdgpu: ATOM BIOS: 113-D603GLXE-077
[drm] FRU: Failed to get size field
[drm:amdgpu_fru_get_product_info [amdgpu]] *ERROR* Failed to read FRU
Manufa
From: Rob Clark
[ Upstream commit 174974d8463b77c2b4065e98513adb204e64de7d ]
If the previous thing cat'ing $debugfs/rd left the FIFO full, then
subsequent open could deadlock in rd_write() (because open is blocked,
not giving a chance for read() to consume any data in the FIFO). Also
it is gene
Refactor backlight support so that the gma_backlight_enable() /
gma_backlight_disable() / gma_backlight_set() functions used by
the Opregion handle will also work if no backlight_device gets
registered.
This is a preparation patch for not registering the gma500's own backlight
device when acpi_vid
On machines without an Intel video opregion the acpi_video driver
immediately probes the ACPI video bus and used to also immediately
register acpi_video# backlight devices when supported.
Once the drm/kms driver then loaded later and possibly registered
a native backlight device then the drivers/a
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
Change the type for the registered backlight class device from platform
to raw/native.
The poulsbo/cedarview/oaktrail backlight support is using native GPU
backlight control and as such the type should be raw (aka native) as
is done by all the other native GPU backlight driver code.
Note this wil
Hi All,
Here is a patch-series changing gma500's backlight handling to match
the changes done to the other major x86 GPU drivers in the just landed
backlight detection refactor patch series:
https://lore.kernel.org/dri-devel/261afe3d-7790-e945-adf6-a2c96c9b1...@redhat.com/
The main goal is here i
Hi Patrik,
On 9/9/22 10:45, Hans de Goede wrote:
> Hi,
>
> On 9/9/22 09:34, Patrik Jakobsson wrote:
>> On Thu, Sep 8, 2022 at 3:39 PM Hans de Goede
>> wrote:
>>>
>>> Hi,
>>>
>>> On 9/8/22 15:26, Patrik Jakobsson wrote:
On Poulsbo I can see
interrupts not getting handled during suspe
On 09/08, Harshit Mogalapalli wrote:
> Smatch warns:
>
> drivers/gpu/drm/vkms/vkms_plane.c:110 vkms_plane_atomic_update() warn:
> variable dereferenced before check 'fb' (see line 108)
>
> Fix the warning by moving the dereference after the NULL check.
>
> Fixes: 8ba1648567e2 ("drm: vkms: Refac
On 09/09, Igor Matheus Andrade Torrente wrote:
> Hi Mellisa,
>
> Thanks for the patch fixing my mistakes.
>
> On 9/9/22 08:41, Melissa Wen wrote:
> > Replace vkms_formats macros for fixed-point operations with functions
> > from drm/drm_fixed.h to do the same job and fix 32-bit compilation
> > er
Replace vkms_formats macro for fixed-point operations with functions
from drm/drm_fixed.h to do the same job and fix 32-bit compilation
errors.
v2:
- don't cast results to s32 (Igor)
- add missing drm_fixp2int conversion (Igor)
Fixes: a19c2ac9858 ("drm: vkms: Add support to the RGB565 format")
Te
Hi
Am 09.09.22 um 16:43 schrieb Saurabh Sengar:
hyperv_setup_vram tries to remove conflicting framebuffer based on
'screen_info'. As observed in past due to some bug or wrong setting
in grub, the 'screen_info' fields may not be set for Gen1, and in such
cases drm_aperture_remove_conflicting_fram
Hi
Am 09.09.22 um 17:09 schrieb Saurabh Sengar:
Due to a full ring buffer, the driver may be unable to send updates to
the Hyper-V host. But outputing the error message can make the problem
worse because console output is also typically written to the frame
buffer.
Rate limiting the error messa
Den 07.09.2022 18.44, skrev Noralf Trønnes:
>
>
> Den 07.09.2022 12.36, skrev Stefan Wahren:
>> Hi Maxime,
>>
>> Am 05.09.22 um 16:57 schrieb Maxime Ripard:
>>> On Fri, Sep 02, 2022 at 01:28:16PM +0200, Noralf Trønnes wrote:
Den 01.09.2022 21.35, skrev Noralf Trønnes:
>
> I h
From: Saurabh Sengar Sent: Friday, September 9,
2022 8:10 AM
>
> Due to a full ring buffer, the driver may be unable to send updates to
> the Hyper-V host. But outputing the error message can make the problem
> worse because console output is also typically written to the frame
> buffer.
> Rate
From: Saurabh Sengar Sent: Friday, September 9,
2022 7:44 AM
>
> hyperv_setup_vram tries to remove conflicting framebuffer based on
> 'screen_info'. As observed in past due to some bug or wrong setting
> in grub, the 'screen_info' fields may not be set for Gen1, and in such
> cases drm_aperture_
Hi Lucas
Am Fr., 9. Sept. 2022 um 11:30 Uhr schrieb Lucas Stach :
>
> The tile status modifiers can be combined with all of the usual
> color buffer modifiers. When they are present an additional plane
> is added to the surfaces to share the tile status buffer. The
> TS modifiers describe the inte
On Sat, 10 Sept 2022 at 11:45, Krzysztof Kozlowski
wrote:
>
> On 10/09/2022 00:23, Rob Herring wrote:
>
> This should be ref to dsi-controller-main.yaml... or based on previous
> Rob's feedback you dropped it everywhere in children?
> >>>
> >>> I don't think I said. I thought about
https://bugzilla.kernel.org/show_bug.cgi?id=205089
Allard (allardprui...@outlook.com) changed:
What|Removed |Added
CC||allardprui...@outlook
On 10/09/2022 00:23, Rob Herring wrote:
This should be ref to dsi-controller-main.yaml... or based on previous
Rob's feedback you dropped it everywhere in children?
>>>
>>> I don't think I said. I thought about it some, as yes, we normally have
>>> done as you suggested. The downside
40 matches
Mail list logo
