> 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
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
---
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
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
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
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
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
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
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
---
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
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
---
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
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
---
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
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
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
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
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
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
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
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
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:
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
> >
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")
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
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
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
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.
>
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
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
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|
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
This is a note to let you know that I've just added the patch titled
drm/amd/display: fix memory leak when using debugfs_lookup()
to the 5.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch
This is a note to let you know that I've just added the patch titled
drm/amd/display: fix memory leak when using debugfs_lookup()
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch
40 matches
Mail list logo
