Hi Andy Et al.,
On Mon, Aug 22, 2022 at 05:20:15PM +0200, Sascha Hauer wrote:
> This series adds support for 4k@30 to the rockchip HDMI controller. This
> has been tested on a rk3568 rock3a board. It should be possible to add
> 4k@60 support the same way, but it doesn't work for me, so let's add
>
On Wed, Aug 24, 2022 at 07:43:03AM +0200, Michael Riesch wrote:
> Hi Sascha,
>
> Can you Cc: linux-rockchip list to get more feedback?
Yes, will do that next time.
>
> On 8/22/22 17:20, Sascha Hauer wrote:
> > This series adds support for 4k@30 to the rockchip HDMI controller. This
> > has been
Delete the redundant word 'to'.
Signed-off-by: wangjianli
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index d49de4905efa..23e773222019 100644
--
Delete the redundant word 'the'.
Delete the redundant word 'for'.
Delete the redundant word 'really'.
Signed-off-by: Jilin Yuan
---
drivers/gpu/drm/gma500/cdv_intel_dp.c | 2 +-
drivers/gpu/drm/gma500/oaktrail_crtc.c | 2 +-
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 2 +-
3 files changed, 3 i
On 8/23/2022 10:07 PM, Rob Clark wrote:
From: Rob Clark
Using map_pages/unmap_pages cuts down on the # of pgtable walks needed
in the process of finding where to insert/remove an entry. The end
result is ~5-10x faster than mapping a single page at a time.
v2: Rename iommu_pgsize(), drop obsol
Delete the redundant word 'for'.
Delete the redundant word 'the'.
Delete the redundant word 'into'.
Signed-off-by: Jilin Yuan
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/i915_request.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.h | 2 +-
3 files changed,
Hi Rob,
On 8/23/2022 12:17 AM, Rob Clark wrote:
From: Rob Clark
Using map_pages/unmap_pages cuts down on the # of pgtable walks needed
in the process of finding where to insert/remove an entry. The end
result is ~5-10x faster than mapping a single page at a time.
Signed-off-by: Rob Clark
--
Delete the redundant word 'power'.
Delete the redundant word 'in'.
Delete the redundant word 'for'.
Signed-off-by: Jilin Yuan
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/
Delete the redundant word 'one'.
Signed-off-by: Jilin Yuan
---
drivers/gpu/drm/msm/msm_gem.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index c75d3b879a53..e300c70e8904 100644
--- a/drivers/gpu/drm/msm/msm_ge
Delete the redundant word 'the'.
Signed-off-by: wangjianli
---
drivers/gpu/drm/vboxvideo/vboxvideo.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vboxvideo/vboxvideo.h
b/drivers/gpu/drm/vboxvideo/vboxvideo.h
index a5de40fe1a76..f60d82504da0 100644
--- a/d
Delete the redundant word 'the'.
Signed-off-by: wangjianli
---
drivers/gpu/drm/i915/display/intel_crt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
b/drivers/gpu/drm/i915/display/intel_crt.c
index 6a3893c8ff22..fead011c87b5 10064
Delete the redundant word 'next'.
Signed-off-by: Jilin Yuan
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 471fd6c8135f..4f9edca66632 100644
Delete the redundant word 'the'.
Signed-off-by: Jilin Yuan
---
drivers/gpu/drm/drm_ioctl.c| 2 +-
drivers/gpu/drm/drm_mipi_dsi.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 51fcf1298023..8faad23dc1d8
Delete the redundant word 'the'.
Signed-off-by: wangjianli
---
drivers/gpu/drm/i915/i915_irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 73cebc6aa650..783a6ca41a61 100644
--- a/drivers/gpu/drm/i915
Delete the redundant word 'is'.
Signed-off-by: Jilin Yuan
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index bce47647d891..59ca7d70a652 100644
--
Delete the redundant word 'in'.
Delete the redundant word 'on'.
Signed-off-by: Jilin Yuan
---
drivers/gpu/drm/drm_edid.c| 2 +-
drivers/gpu/drm/drm_framebuffer.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid
Delete the redundant word 'the'.
Signed-off-by: wangjianli
---
drivers/gpu/drm/gma500/cdv_intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
index 9ee99a7d4fbe..a286861ffa3f 100644
--- a/dr
Delete the redundant word 'the'.
Delete the redundant word 'this'.
Signed-off-by: Jilin Yuan
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 4 ++--
drivers/gpu/drm/drm_prime.c| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_pa
Delete the redundant word 'the'.
Signed-off-by: Jilin Yuan
---
drivers/gpu/drm/display/drm_dp_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index e7c22c2ca90c..c258cbd6857b 1006
On 22/08/2022 17:34, Tomi Valkeinen wrote:
+struct drm_atomic_state;
+struct drm_bridge;
+
+#if IS_ENABLED(CONFIG_DRM_RCAR_MIPI_DSI)
+void rcar_mipi_dsi_pclk_enable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+void rcar_mipi_dsi_pclk_disable(struct
Hi Nicolas, all
Nicolas, please see below in the thread for your concerns regarding video
decoding and hdmi receivers with secure memory.
But i can also propose to setup calls to discuss about that. We are almost done
with a proposal to add support of Linaro secure dmabuff heaps in V4L2. Today
Sorry for the necro-bump, I hadnt seen this go by
My main concern with this proposal is the phasing out of
/sys/class/backlight/.
Currently on the user(user, not userland) level its easier for me to just
modify
the file and be done with it. xbacklight doesnt tell me when its failed,
brightnessctl
Delete the redundant word 'the'.
Signed-off-by: wangjianli
---
drivers/gpu/drm/drm_rect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index 0460e874896e..8873922d6dee 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/dr
Hi Jilin,
On Tue, Aug 16, 2022 at 3:08 PM Jilin Yuan wrote:
> Delete the redundant word 'set'.
>
> Signed-off-by: Jilin Yuan
Thanks for your patch, which is now commit 253cabc01468d6b5 ("fbdev:
ssd1307fb: Fix repeated words in comments") in fbdev/for-next
> --- a/drivers/video/fbdev/ssd1307fb
Hi,
On Thu, Jul 14, 2022 at 12:31:42PM +0200, Lucas Stach wrote:
> The same logic is already used in two different places and now
> it will also be needed outside of the compilation unit, so split
> it into a separate function.
>
> Cc: sta...@vger.kernel.org # 5.19
> Signed-off-by: Lucas Stach
>
Hi,
On Thu, Jul 14, 2022 at 12:31:43PM +0200, Lucas Stach wrote:
> When a idle BO, which is held open by another process, gets freed by
> userspace and subsequently referenced again by e.g. importing it again,
> userspace may assign a different softpin VA than the last time around.
> As the kernel
This approach will not break existing user-space AFAIK.
Acked-by: Simon Ser
On Wed, 24 Aug 2022 at 01:59, Abhinav Kumar wrote:
>
>
>
> On 8/23/2022 3:41 PM, Dmitry Baryshkov wrote:
> > On Wed, 24 Aug 2022 at 01:07, Abhinav Kumar
> > wrote:
> >> On 8/22/2022 11:33 AM, Dmitry Baryshkov wrote:
> >>> On 22/08/2022 20:32, Abhinav Kumar wrote:
>
>
> On 8/22/202
'config_max_height' should be used for 'max_height'.
Signed-off-by: Jammy Huang
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv
On 2022-08-22 22:09, Andrey Grodzovsky wrote:
> Poblem: Given many entities competing for same rq on
> same scheduler an uncceptabliy long wait time for some
> jobs waiting stuck in rq before being picked up are
> observed (seen using GPUVis).
> The issue is due to Round Robin policy used by sched
On Wed, 24 Aug 2022 at 04:25, Abhinav Kumar wrote:
>
>
>
> On 6/20/2022 2:30 PM, Dmitry Baryshkov wrote:
> > The rest of the code expects that master's device drvdata is the
> > struct msm_drm_private instance. Do not override the mdp5's drvdata.
> >
> > Fixes: 6874f48bb8b0 ("drm/msm: make mdp5/dp
This patch series fixes integer overflow or integer truncation issues in
page lookups, ttm place configuration and scatterlist creation, etc.
We need to check that we avoid integer overflows when looking up a page,
and so fix all the instances where we have mistakenly used a plain integer
instead o
It adds exact_type and exactly_pgoff_t macro to catch type mis-match while
compiling. The existing typecheck() macro outputs build warnings, but the
newly added exact_type() macro uses the BUILD_BUG_ON() macro to generate
a build break when the types are different and can be used to detect
explicit
There is an impedance mismatch between the first/last valid page
frame number of ttm place in unsigned and our memory/page accounting in
unsigned long.
As the object size is under the control of userspace, we have to be prudent
and catch the conversion errors.
To catch the implicit truncation as we
From: Chris Wilson
We need to check that we avoid integer overflows when looking up a page,
and so fix all the instances where we have mistakenly used a plain
integer instead of a more suitable long. Be pedantic and add integer
typechecking to the lookup so that we can be sure that we are safe.
A
From: Chris Wilson
There is an impedance mismatch between the scatterlist API using unsigned
int and our memory/page accounting in unsigned long. That is we may try
to create a scatterlist for a large object that overflows returning a
small table into which we try to fit very many pages. As the o
From: Chris Wilson
Having addressed the issues surrounding incorrect types for local
variables and potential integer truncation in using the scatterlist API,
we have closed all the loop holes we had previously identified with
dangerously large object creation. As such, we can eliminate the warnin
The ttm_bo_init_reserved() functions returns -ENOSPC if the size is too big
to add vma. The direct function that returns -ENOSPC is
drm_mm_insert_node_in_range().
To handle the same error as other code returning -E2BIG when the size is
too large, it converts return value to -E2BIG.
Signed-off-by:
The __shmem_file_setup() function returns -EINVAL if size is greater than
MAX_LFS_FILESIZE. To handle the same error as other code that returns
-E2BIG when the size is too large, it add a code that returns -E2BIG when
the size is larger than the size that can be handled.
v4: If BITS_PER_LONG is 32
It moves overflows_type utility macro into overflow header from i915_utils
header. The overflows_type can be used to catch the truncaion (overflow)
between different data types. And it adds check_assign() macro which
performs an assigning source value into destination ptr along with an
overflow che
Hi Geert,
Thanks for the feedback.
> Subject: Re: [PATCH v5 04/10] drm: rcar-du: Add rcar_du_lib_fb_create()
>
> Hi Biju,
>
> On Wed, Jul 27, 2022 at 6:08 PM Biju Das
> wrote:
> > Move the common code from rcar_du_fb_create->rcar_du_lib_fb_create,
> > so that rzg2l_du_fb_create() can reuse the
NACK on this one. Let's get this reverted or fixed to eliminate
new module parameters.
What prevents us just from using the maximum sizes? Or alternatively
we could check the already existing drm.debug variable or anything else
but addding 3 new module parameters.
For future reference, please do
On 8/23/22 9:35 PM, Andrzej Hajda wrote:
On 23.08.2022 12:17, Gwan-gyeong Mun wrote:
It moves overflows_type utility macro into overflow header from
i915_utils
header. The overflows_type can be used to catch the truncaion (overflow)
between different data types. And it adds check_assign() ma
On 24.08.2022 10:45, Gwan-gyeong Mun wrote:
It moves overflows_type utility macro into overflow header from i915_utils
header. The overflows_type can be used to catch the truncaion (overflow)
between different data types. And it adds check_assign() macro which
performs an assigning source valu
On Fri, 19 Aug 2022, Matt Roper wrote:
> On Thu, Aug 18, 2022 at 04:41:42PM -0700, Radhakrishna Sripada wrote:
>> From: Matt Roper
>>
>> Going forward, the hardware teams no longer consider new platforms to
>> have a "generation" in the way we've defined it for past platforms.
>> Instead, each I
Add _unlocked postfix to the dma-buf API function names in a preparation
to move all non-dynamic dma-buf users over to the dynamic locking
specification. This patch only renames API functions, preparing drivers
to the common locking convention. Later on, we will make the "unlocked"
functions to tak
Hello,
This series moves all drivers to a dynamic dma-buf locking specification.
>From now on all dma-buf importers are made responsible for holding
dma-buf's reservation lock around all operations performed over dma-bufs
in accordance to the locking specification. This allows us to utilize
reserv
The new common dma-buf locking convention will require buffer importers
to hold the reservation lock around mapping operations. Make DRM GEM core
to take the lock around the vmapping operations and update DRM drivers to
use the locked functions for the case where DRM core now holds the lock.
This p
All drivers that use dma-bufs have been moved to the updated locking
specification and now dma-buf reservation is guaranteed to be locked
by importers during the mapping operations. There is no need to take
the internal dma-buf lock anymore. Remove locking from the videobuf2
memory allocators.
Ack
Move dma_buf_mmap_unlocked() function to the dynamic locking specification
by taking the reservation lock. Neither of the today's drivers take the
reservation lock within the mmap() callback, hence it's safe to enforce
the locking.
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 8
Add documentation for the dynamic locking convention. The documentation
tells dma-buf API users when they should take the reservation lock and
when not.
Signed-off-by: Dmitry Osipenko
---
Documentation/driver-api/dma-buf.rst | 6 +++
drivers/dma-buf/dma-buf.c| 63 +++
Move dma-buf attachment API functions to the dynamic locking specification.
The strict locking convention prevents deadlock situations for dma-buf
importers and exporters.
Previously, the "unlocked" versions of the attachment API functions
weren't taking the reservation lock and this patch makes t
The internal dma-buf lock isn't needed anymore because the updated
locking specification claims that dma-buf reservation must be locked
by importers, and thus, the internal data is already protected by the
reservation lock. Remove the obsoleted internal lock.
Signed-off-by: Dmitry Osipenko
---
d
Add locked variant of dma_buf_vmap/vunmap() that will be utilized by
DRM drivers once vmap/unmap functions will be moved to the new locking
convention.
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 42 +++
include/linux/dma-buf.h | 2 ++
2
Move dma_buf_vmap/vunmap_unlocked() functions to the dynamic locking
specification by taking the reservation lock. All the affected drivers
were prepared to this change by a previous drm/gem patch.
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 8
drivers/gpu/drm/drm_p
Nice!
Acked-by: Hans Verkuil
Regards,
Hans
On 24/08/2022 12:22, Dmitry Osipenko wrote:
> All drivers that use dma-bufs have been moved to the updated locking
> specification and now dma-buf reservation is guaranteed to be locked
> by importers during the mapping operations. There is no
Hi Daniel,
On 8/17/22 22:18, Daniel Dadap wrote:
> On 8/17/22 10:05 AM, Hans de Goede wrote:
>>> One further potential difficulty that I anticipate is that not all dynamic
>>> mux systems use the EC backlight driver (or a similar, GPU-agnostic
>>> driver), and rather have whichever GPU happen
On Tue, Aug 23, 2022 at 11:48:01PM +0200, Andrzej Hajda wrote:
>
>
> On 22.08.2022 19:27, Imre Deak wrote:
> > On Fri, Jul 22, 2022 at 02:51:42PM +0200, Andrzej Hajda wrote:
> > > HPD events during driver removal can be generated by hardware and
> > > software frameworks - drm_dp_mst, the former
Hi,
2022년 8월 23일 (화) 오후 10:37, Robin Murphy 님이 작성:
>
> On 2022-08-23 13:21, Jilin Yuan wrote:
> > Delete the redundant word 'next'.
>
> From the context, I'm not sure it is redundant - as far as I can tell
> this comment seems to be describing a sequence of 3 commands, where
> "current" is the
On 24/08/2022 04:44, Nancy.Lin wrote:
Hi Matthias,
Thanks for your comment.
On Tue, 2022-08-23 at 14:08 +0200, Matthias Brugger wrote:
On 23/08/2022 13:30, Nancy.Lin wrote:
Hi Matthias,
Thanks for the review.
On Tue, 2022-08-23 at 12:20 +0200, Matthias Brugger wrote:
On 19/08/2022 08:
The print function dev_err() is redundant because platform_get_irq()
already prints an error.
./drivers/video/fbdev/omap/omapfb_main.c:1653:2-9: line 1653 is redundant
because platform_get_irq() already prints an error.
./drivers/video/fbdev/omap/omapfb_main.c:1646:2-9: line 1646 is redundant
be
Hi Dave & Daniel,
Here goes the first drm-intel-gt-next PR towards 6.1. Quite a small one.
As primary things, there's the parallel support of GuC v69 and v70
which already went in via -fixes, improvements to the TLB invalidation
performance regressions, further DG2 enabling and improved debugging
On Tue, Aug 23, 2022 at 08:15:48PM +0300, Jani Nikula wrote:
> On Fri, 19 Aug 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > EDID 1.4 introduced some extra flags in the range
> > descriptor to support min/max h/vfreq >= 255. Consult them
> > to correctly parse the vfreq limits.
> >
>
ATM on x86 laptops where we want userspace to use the acpi_video backlight
device we often 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, but
registering 2
Hi All,
As mentioned in my RFC titled "drm/kms: control display brightness through
drm_connector properties":
https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/
The first step towards this is to deal with some existing technical debt
in backlight handling on x86/AC
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
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
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
Move the list_del removing an acpi_video_bus from video_bus_head
on teardown to before the teardown is done, to avoid code iterating
over the video_bus_head list seeing acpi_video_bus objects on there
which are (partly) torn down already.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
Typically the acpi_video driver will initialize before radeon, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
radeon would register its own radeon_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there b
All x86/ACPI kms drivers which register native/BACKLIGHT_RAW type
backlight devices call acpi_video_backlight_use_native() now. This sets
__acpi_video_get_backlight_type()'s internal static native_available flag.
This makes the backlight_device_get_by_type(BACKLIGHT_RAW) check
unnecessary.
Relyin
On x86/ACPI boards the acpi_video driver will usually initialize before
the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native backlight
device after which the drivers/acpi/video_detect.c code unregisters
the acpi_video
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.
When this WMI interface is present and indicates th
On machins without an i915 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/acpi/vide
When acpi_video_register() has not run yet the video_bus_head will be
empty, so there is no need to check the register_count flag first.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
dif
Typically the acpi_video driver will initialize before amdgpu, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
amdgpu would register its own amdgpu_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there b
Remove the code to unregister acpi_video backlight devices when
a native backlight device gets registered later.
Now that the acpi_video backlight device registration is a separate step
which runs later, after the drm/kms driver is done setting up its own
native backlight device, it is no longer n
Move the WMI interface definitions to a header, so that the definitions
can be shared with drivers/acpi/video_detect.c .
Changes in v2:
- Add missing Nvidia copyright header
- Move WMI_BRIGHTNESS_GUID to nvidia-wmi-ec-backlight.h as well
Suggested-by: Daniel Dadap
Signed-off-by: Hans de Goede
-
Refactor acpi_video_get_backlight_type() so that the heuristics /
detection steps are stricly in order of descending precedence.
Also move the comments describing the steps to when the various steps are
actually done, to avoid the comments getting out of sync with the code.
Acked-by: Rafael J. Wy
Typically the acpi_video driver will initialize before nouveau, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
nouveau would register its own nv_backlight device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid the
On Apple laptops with an Apple GMUX using this for brightness control,
should take precedence of any other brightness control methods.
Add apple-gmux detection to acpi_video_get_backlight_type() using
the already existing apple_gmux_present() helper function.
This will allow removig the (ab)use o
Now that acpi_video_get_backlight_type() has apple-gmux detection (using
apple_gmux_present()), it is no longer necessary for the apple-gmux code
to manually remove possibly conflicting drivers.
So remove the handling for this from the apple-gmux driver.
Signed-off-by: Hans de Goede
---
drivers
Remove the asus-wmi quirk_entry.wmi_backlight_native quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_native) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_native callback.
acpi_video_set_dmi_backlight_type() is troub
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight, acpi_v
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Move all the acpi_backlight=[vendor|native]
Move the backlight DMI quirks to acpi/video_detect.c, so that
the driver no longer needs to call acpi_video_set_dmi_backlight_type().
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_t
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
Add an acpi_video_get_backlight_type() == acpi_backlight_nvidia_wmi_ec
check. This will make nvidia-wmi-ec-backlight properly honor the user
selecting a different backlight driver through the acpi_backlight=...
kernel commandline option.
Since the auto-detect code check for nvidia-wmi-ec-backlight
acpi_backlight=native is the default for the "Samsung X360", but as
the comment explains the quirk was still necessary because even
briefly registering the acpi_video0 backlight; and then unregistering
it once the native driver showed up, was leading to issues.
After the "ACPI: video: Make backlig
acpi_video_set_dmi_backlight_type() is troublesome because it may end
up getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight, acpi_v
Add an entry summarizing the discussion about dealing with brightness
control on devices with more then 1 internal panel.
The original discussion can be found here:
https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdego...@redhat.com/
Signed-off-by: Hans de Goede
---
Documentation/gpu/t
Remove the asus-wmi quirk_entry.wmi_backlight_power quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_vendor callback.
acpi_video_set_dmi_backlight_type() is troubl
acpi_backlight=native is the default for these, but as the comment
explains the quirk was still necessary because even briefly registering
the acpi_video0 backlight; and then unregistering it once the native
driver showed up, was leading to issues.
After the "ACPI: video: Make backlight class devi
The video_detect_dmi_table[] uses an unusual indentation for
before the ".name = ..." named struct initializers.
Instead of being indented with an extra tab compared to
the previous line's '{' these are indented to with only
a single space to allow for long DMI_MATCH() lines without
wrapping.
But
Changes to v3:
- Fix LVDS function renames wrt. export symbol.
- Fix missing static inline
- Use rcar_mipi_dsi_write for VCLKSET writes
Tomi
Tomi Valkeinen (5):
drm: rcar-du: lvds: Rename pclk enable/disable functions
drm: rcar-du: dsi: Properly stop video mode TX
drm: rcar-du: dsi: Improv
From: Tomi Valkeinen
The driver does not explicitly stop the video mode transmission when
disabling the output. While this doesn't seem to be causing any issues,
lets follow the steps described in the documentation and add a
rcar_mipi_dsi_stop_video() which stop the video mode transmission. This
From: Tomi Valkeinen
rcar_mipi_dsi_startup() writes correct values to VCLKSET, but as it uses
or-operation to add the new values to the current value in the register,
it should first make sure the fields are cleared.
Do this by using rcar_mipi_dsi_write() to write the VCLKSET register
with a var
From: Tomi Valkeinen
Improve the DSI shutdown procedure by clearing various bits that were
set while enabling the DSI output. There has been no clear issues caused
by these, but it's safer to ensure that the features are disabled at the
start of the next DSI enable.
Signed-off-by: Tomi Valkeinen
From: Tomi Valkeinen
The DU driver uses the rcar_lvds_clk_enable() and
rcar_lvds_clk_disable() functions enable or disable the pixel clock
generated by the LVDS encoder, as it requires that clock for proper DU
operation. Rename the functions by replacing "clk" with "pclk" to make
it clearer that
From: Tomi Valkeinen
The rcar crtc depends on the clock provided from the rcar DSI bridge.
When the DSI bridge is disabled, the clock is stopped, which causes the
crtc disable to timeout.
Also, while I have no issue with the enable, the documentation suggests
to enable the DSI before the crtc so
1 - 100 of 304 matches
Mail list logo
