On 17/08/2022 17:57, Akhil P Oommen wrote:
Thank you for your patch. There is something to discuss/improve.
>
> return regmap_update_bits(rst->regmap, map->reg, mask, 0);
> diff --git a/drivers/clk/qcom/reset.h b/drivers/clk/qcom/reset.h
> index 2a08b5e..d4213b4 100644
> --- a/drivers/clk
On 17/08/2022 17:57, Akhil P Oommen wrote:
> Allow a consumer driver to poll for cx gdsc collapse through Reset
> framework.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> Changes in v2:
> - Minor update to use the updated custom reset ops implementation
>
> drivers/clk/qcom/gpucc-sc7280.c | 10 +
Hi Nicolas, all,
The short reply:
- For DRM, gstreamer, ffmeg, ... we don't use anymore NXP VPU proprietary
API
- We need secure dma-buf heaps to replace secure ion heaps
The more detailed reply to address concerns below in the thread:
- NXP doesn't design VPU, but rely on
Hi Akhil,
On Wed, Aug 17, 2022 at 08:44:18PM +0530, Akhil P Oommen wrote:
> Because there could be transient votes from other drivers/tz/hyp which
> may keep the cx gdsc enabled, we should poll until cx gdsc collapses.
> We can use the reset framework to poll for cx gdsc collapse from gpucc
> clk
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 common code.
>
> Signed-off-by: Biju Das
> ---
> v5:
> * New patch
Thanks for your patch!
> --- a/drivers/gpu/drm/rcar-du
Am 18.08.22 um 02:30 schrieb Bas Nieuwenhuizen:
On Thu, Aug 18, 2022 at 12:04 AM Felix Kuehling wrote:
Am 2022-08-12 um 21:27 schrieb Bas Nieuwenhuizen:
This way callsites can choose between READ/BOOKKEEP reservations.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amd
Am 18.08.22 um 00:20 schrieb Dmitry Osipenko:
On 8/15/22 16:08, Christian König wrote:
TTM owns the pages it uses for backing buffer objects with system
memory. Because of this it is absolutely illegal to mess around with
the reference count of those pages.
So make sure that nobody ever tries t
Am 18.08.22 um 01:13 schrieb Dmitry Osipenko:
On 8/18/22 01:57, Dmitry Osipenko wrote:
On 8/15/22 18:54, Dmitry Osipenko wrote:
On 8/15/22 17:57, Dmitry Osipenko wrote:
On 8/15/22 16:53, Christian König wrote:
Am 15.08.22 um 15:45 schrieb Dmitry Osipenko:
[SNIP]
Well that comment sounds lik
Hello,
syzbot found the following issue on:
HEAD commit:7ebfc85e2cd7 Merge tag 'net-6.0-rc1' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=143d292d08
kernel config: https://syzkaller.appspot.com/x/.config?x=924833c12349a8c0
das
Hi,
On 17.08.22 г. 7:52 ч., Yongqin Liu wrote:
Hi, Ivaylo
On Mon, 15 Aug 2022 at 14:23, Ivaylo Dimitrov
wrote:
Hi Liu,
On 14.08.22 г. 17:27 ч., Yongqin Liu wrote:
Hi, IvayIo
Thanks very much for the reply!
On Sat, 13 Aug 2022 at 14:58, Ivaylo Dimitrov
wrote:
Hi Liu,
On 12.08.22 г. 7:
On Wed, 17 Aug 2022, Doug Anderson wrote:
> Hi,
>
> On Sun, Aug 14, 2022 at 11:46 PM Maxime Ripard wrote:
>>
>> On Fri, Jul 29, 2022 at 12:57:40PM -0700, Doug Anderson wrote:
>> > Hi,
>> >
>> > On Fri, Jul 29, 2022 at 9:41 AM Maxime Ripard wrote:
>> > > You raise some good points, but most of th
On Thu, Aug 18, 2022 at 3:09 AM Randy Dunlap wrote:
>
>
>
> On 8/17/22 19:01, Alex Deucher wrote:
> > On Wed, Aug 17, 2022 at 6:03 PM Sudip Mukherjee (Codethink)
> > wrote:
> >>
> >> Hi All,
> >>
> >> Not sure if it has been reported, build of next-20220817 fails with the
> >> error:
> >>
> >> ER
This patch adds ast specific codes for DRM prime feature, this is to
allow for offloading of rending in one direction and outputs in other.
v1->v2:
- Fix the comment.
Signed-off-by: oushixiong
---
drivers/gpu/drm/ast/ast_drv.c | 22 ++
drivers/gpu/drm/ast/ast_mode.c | 125 ++
Am 17.08.22 um 18:11 schrieb Jason Gunthorpe:
dma-buf has become a way to safely acquire a handle to non-struct page
memory that can still have lifetime controlled by the exporter. Notably
RDMA can now import dma-buf FDs and build them into MRs which allows for
PCI P2P operations. Extend this to
Am 17.08.22 um 15:44 schrieb Rob Clark:
On Wed, Aug 17, 2022 at 2:57 AM Christian König
wrote:
[SNIP]
The resulting cache attrs from combination of S1 and S2 translation
can differ. So ideally we setup the S2 pgtables in guest aligned with
host userspace mappings
Well exactly that is not very
Hi Mark,
On 8/15/22 18:44, Mark Brown wrote:
On Fri, 12 Aug 2022 13:08:17 +0300, Matti Vaittinen wrote:
Devm helpers for regulator get and enable
First patch in the series is actually just a simple documentation fix
which could be taken in as it is now.
A few* drivers seem to use pattern demo
On Thu, Aug 18, 2022 at 02:33:53PM +0300, Matti Vaittinen wrote:
> On 8/15/22 18:44, Mark Brown wrote:
> > [2/7] regulator: Add devm helpers for get and enable
> >(no commit info)
> I was planning to send out the v3 (where IIO patches are no longer squashed
> into one). I didn't spot the
On Wed, Aug 17, 2022 at 01:11:38PM -0300, Jason Gunthorpe wrote:
> dma-buf has become a way to safely acquire a handle to non-struct page
> memory that can still have lifetime controlled by the exporter. Notably
> RDMA can now import dma-buf FDs and build them into MRs which allows for
> PCI P2P op
On Tue, Aug 16, 2022 at 11:06:18AM +0300, Jani Nikula wrote:
> On Tue, 16 Aug 2022, Kai-Heng Feng wrote:
> > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> > dGFX so external monitors are routed to dGFX, and more monitors can be
> > supported as result.
> >
> > To switc
Hi!
On Wed, Aug 17, 2022 at 04:01:48PM +0200, Geert Uytterhoeven wrote:
> > > > > Vertically, it's simpler, as the number of lines is discrete.
> > > > > You do have to take into account interlace and doublescan, and
> > > > > progressive modes with 262/312 lines.
> > > >
> > > > So we only have t
1. Corrected the definition of AST_DP501_PNP_CONNECTED.
2. Created the Base address for DP501 MCU.
Signed-off-by: KuoHsiang Chou
---
drivers/gpu/drm/ast/ast_dp501.c | 10 --
drivers/gpu/drm/ast/ast_drv.h | 2 +-
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gp
Hi Maxime,
On Thu, Aug 18, 2022 at 2:39 PM Maxime Ripard wrote:
> On Wed, Aug 17, 2022 at 04:01:48PM +0200, Geert Uytterhoeven wrote:
> > > I've looked around and it looks like the entire blanking area is
> > > supposed to be 40 pixels in interlaced, but I couldn't find anywhere how
> >
> > 625 l
Am 18.08.22 um 14:03 schrieb Jason Gunthorpe:
On Thu, Aug 18, 2022 at 01:07:16PM +0200, Christian König wrote:
Am 17.08.22 um 18:11 schrieb Jason Gunthorpe:
dma-buf has become a way to safely acquire a handle to non-struct page
memory that can still have lifetime controlled by the exporter.
Add binding for the Emerging Display Technology ETML1010G0DKA panel.
It's a 10.1" WXGA (1280 x 800) LVDS panel with backlight and capacitive
touch.
Signed-off-by: Dominik Haller
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --gi
On Thu, Aug 18, 2022 at 02:58:10PM +0200, Christian König wrote:
> > > The only thing I'm not 100% convinced of is dma_buf_try_get(), I've seen
> > > this incorrectly used so many times that I can't count them any more.
> > >
> > > Would that be somehow avoidable? Or could you at least explain th
Hi Bas,
I've just pushed the branch drm-exec to my fdo repository:
https://gitlab.freedesktop.org/ckoenig/linux-drm.git
This branch contains all the gang submit patches as well as the latest
drm-exec stuff. VCN3/4 video decoding has some issues on it, but that
probably shouldn't bother your
The file amdgpu_dm_plane.c missed the header amdgpu_dm_plane.h, which
resulted on the following warning:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1046:5:
warning: no previous prototype for 'fill_dc_scaling_info'
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/
Am 18.08.22 um 15:16 schrieb Jason Gunthorpe:
On Thu, Aug 18, 2022 at 02:58:10PM +0200, Christian König wrote:
The only thing I'm not 100% convinced of is dma_buf_try_get(), I've seen
this incorrectly used so many times that I can't count them any more.
Would that be somehow avoidable? Or coul
Hi Jon,
This series is against 6.0-rc1, so it should apply fine on the top of your tree.
After applying one fix sent to ACPI:
https://lore.kernel.org/linux-acpi/20220818055156.7456-1-sakari.ai...@linux.intel.com/T/#u
make htmldocs (with Sphinx 2.4.4) produces a very clean result:
:
War
Address this warning:
Documentation/leds/leds-qcom-lpg.rst: WARNING: o documento não está
incluído em nenhum toctree
Signed-off-by: Mauro Carvalho Chehab
---
See [PATCH 00/13] at:
https://lore.kernel.org/all/cover.1660829433.git.mche...@kernel.org/
Documentation/leds/index.rst
On Thu, Aug 18, 2022 at 02:57:55PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Thu, Aug 18, 2022 at 2:39 PM Maxime Ripard wrote:
> > On Wed, Aug 17, 2022 at 04:01:48PM +0200, Geert Uytterhoeven wrote:
> > > > I've looked around and it looks like the entire blanking area is
> > > > suppos
On 8/17/22 18:12, Michał Winiarski wrote:
Expecting to observe a specific value, when the function responsible for
setting the value has failed will lead to extra noise in test output.
Use assert when the situation calls for it.
Also - very small tidying up around the changed areas (whitespace
On 8/17/22 18:12, Michał Winiarski wrote:
Negative tests can be expressed as a single parameterized test case,
which highlights that we're following the same test logic (passing
invalid cmdline and expecting drm_mode_parse_command_line_for_connector
to fail), which improves readability.
In
On Thu, Aug 18, 2022 at 4:21 AM Christian König
wrote:
>
> Am 17.08.22 um 15:44 schrieb Rob Clark:
> > On Wed, Aug 17, 2022 at 2:57 AM Christian König
> > wrote:
> >> [SNIP]
> >>
> >> The resulting cache attrs from combination of S1 and S2 translation
> >> can differ. So ideally we setup the S2
Passed through PCI device sometimes misbehave on Gen1 VMs when Hyper-V
DRM driver is also loaded. Looking at IOMEM assignment, we can see e.g.
$ cat /proc/iomem
...
f800-fffb : PCI Bus :00
f800-fbff : :00:08.0
f800-f8001fff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
.
There are already two places in kernel with PCI_VENDOR_ID_MICROSOFT/
PCI_DEVICE_ID_HYPERV_VIDEO and there's a need to use these from core
Vmbus code. Move the defines to a common header.
No functional change.
Signed-off-by: Vitaly Kuznetsov
---
drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 3 ---
d
vmbus_reserve_fb() tries reserving framebuffer region iff
screen_info.lfb_base is set. Gen2 VMs seem to have it set by EFI fb
but on Gen1 VM it is observed to be zero. In fact, we do not need to
rely on some other video driver setting it correctly as Gen1 VMs have
a dedicated PCI device to look at.
Passed through PCI device sometimes misbehave on Gen1 VMs when Hyper-V
DRM driver is also loaded. Looking at IOMEM assignment, we can see e.g.
$ cat /proc/iomem
...
f800-fffb : PCI Bus :00
f800-fbff : :00:08.0
f800-f8001fff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
.
On Tue, Aug 16, 2022 at 11:56:17AM +0200, Neil Armstrong wrote:
> From: Neil Armstrong
>
> My professional e-mail will change and the BayLibre one will
> bounce after mid-september of 2022.
>
> This updates the MAINTAINERS file, the YAML bindings and adds an
> entry in the .mailmap file.
>
> Si
Am 18.08.22 um 16:25 schrieb Rob Clark:
On Thu, Aug 18, 2022 at 4:21 AM Christian König
wrote:
Am 17.08.22 um 15:44 schrieb Rob Clark:
On Wed, Aug 17, 2022 at 2:57 AM Christian König
wrote:
[SNIP]
The resulting cache attrs from combination of S1 and S2 translation
can differ. So ideally we
On Wed, Aug 17, 2022 at 04:04:24PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard wrote:
> > On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote:
> > > On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard wrote:
> > > > On Wed, Aug 17, 202
Den 18.08.2022 01.23, skrev Noralf Trønnes:
>
>
> Den 17.08.2022 15.11, skrev Noralf Trønnes:
>>
>>
>> Den 17.08.2022 13.46, skrev Maxime Ripard:
>>> On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrote:
Den 16.08.2022 11.49, skrev Maxime Ripard:
> On Tue, Aug 16, 2022 at 11
On Thu, Aug 18, 2022 at 7:54 AM Christian König
wrote:
>
> Am 18.08.22 um 16:25 schrieb Rob Clark:
> > On Thu, Aug 18, 2022 at 4:21 AM Christian König
> > wrote:
> >> Am 17.08.22 um 15:44 schrieb Rob Clark:
> >>> On Wed, Aug 17, 2022 at 2:57 AM Christian König
> >>> wrote:
> [SNIP]
>
>
Hi,
On Wed, Aug 17, 2022 at 8:22 PM Hsin-Yi Wang wrote:
>
> On Thu, Aug 18, 2022 at 11:19 AM Rock Chiu
> wrote:
> >
> > How does T4/T5 impact the real case? We talked previously the T4/T5
> > shouldn't cause user impact.
> > Do we have testing data from ODM?
> >
> Please leave comments below th
On 8/18/22 03:43, Sudip Mukherjee wrote:
> On Thu, Aug 18, 2022 at 3:09 AM Randy Dunlap wrote:
>>
>>
>>
>> On 8/17/22 19:01, Alex Deucher wrote:
>>> On Wed, Aug 17, 2022 at 6:03 PM Sudip Mukherjee (Codethink)
>>> wrote:
Hi All,
Not sure if it has been reported, build of nex
On Wed, Aug 17, 2022 at 03:11:56PM +0200, Noralf Trønnes wrote:
> Den 17.08.2022 13.46, skrev Maxime Ripard:
> > On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrote:
> >> Den 16.08.2022 11.49, skrev Maxime Ripard:
> >>> On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote:
> >>
Hi Maxime,
On Thu, Aug 18, 2022 at 4:54 PM Maxime Ripard wrote:
> On Wed, Aug 17, 2022 at 04:04:24PM +0200, Geert Uytterhoeven wrote:
> > On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard wrote:
> > > On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, Aug 17, 2022 at
On Thu, Aug 18, 2022 at 05:01:38PM +0200, Noralf Trønnes wrote:
>
>
> Den 18.08.2022 01.23, skrev Noralf Trønnes:
> >
> >
> > Den 17.08.2022 15.11, skrev Noralf Trønnes:
> >>
> >>
> >> Den 17.08.2022 13.46, skrev Maxime Ripard:
> >>> On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrot
Hi Maxime,
On Thu, Aug 18, 2022 at 3:42 PM Maxime Ripard wrote:
> On Thu, Aug 18, 2022 at 02:57:55PM +0200, Geert Uytterhoeven wrote:
> > On Thu, Aug 18, 2022 at 2:39 PM Maxime Ripard wrote:
> > > On Wed, Aug 17, 2022 at 04:01:48PM +0200, Geert Uytterhoeven wrote:
> > > > > I've looked around an
On Thu, Aug 18, 2022 at 05:20:42PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Thu, Aug 18, 2022 at 4:54 PM Maxime Ripard wrote:
> > On Wed, Aug 17, 2022 at 04:04:24PM +0200, Geert Uytterhoeven wrote:
> > > On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard wrote:
> > > > On Wed, Aug 17, 202
On Mon, Aug 15, 2022 at 09:52:59AM -0700, Florian Fainelli wrote:
> On 8/15/22 07:12, Maxime Ripard wrote:
> > On Wed, Aug 10, 2022 at 10:33:48PM +0200, Stefan Wahren wrote:
> > > Hi Florian,
> > >
> > > Am 09.08.22 um 21:02 schrieb Florian Fainelli:
> > > > On 8/4/22 16:11, Florian Fainelli wrote
On Thu, Aug 18, 2022 at 05:34:30PM +0200, Geert Uytterhoeven wrote:
> On Thu, Aug 18, 2022 at 3:42 PM Maxime Ripard wrote:
> > On Thu, Aug 18, 2022 at 02:57:55PM +0200, Geert Uytterhoeven wrote:
> > > On Thu, Aug 18, 2022 at 2:39 PM Maxime Ripard wrote:
> > > > On Wed, Aug 17, 2022 at 04:01:48PM
https://bugzilla.kernel.org/show_bug.cgi?id=212649
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
Hi Maxime,
On Thu, Aug 18, 2022 at 5:46 PM Maxime Ripard wrote:
> On Thu, Aug 18, 2022 at 05:34:30PM +0200, Geert Uytterhoeven wrote:
> > On Thu, Aug 18, 2022 at 3:42 PM Maxime Ripard wrote:
> > > I started adding more sanity checks to my code, and I just realised I
> > > don't seem to be able t
Hi Arnd,
Doubling back around to this now since I think this is the only thing
breaking x86_64 allmodconfig with clang 11 through 15.
On Fri, Aug 05, 2022 at 09:32:13PM +0200, Arnd Bergmann wrote:
> On Fri, Aug 5, 2022 at 8:02 PM Nathan Chancellor wrote:
> > On Fri, Aug 05, 2022 at 06:16:45PM +0
Hi Stephen
On 8/15/2022 10:08 AM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-08-11 08:20:01)
On 8/10/2022 6:00 PM, Abhinav Kumar wrote:
Even then, you do have a valid point. DRM framework should not have
caused the disable path to happen without an enable.
I went through the stack menti
On Thu, Aug 18, 2022 at 11:15:39AM -0300, Maíra Canal wrote:
>
>
> On 8/17/22 18:12, Michał Winiarski wrote:
> > Negative tests can be expressed as a single parameterized test case,
> > which highlights that we're following the same test logic (passing
> > invalid cmdline and expecting drm_mode_p
Addresses the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3596:6:
error: stack frame size (2092) exceeds limit (2048) in
'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml30_ModeSupportAndSystemConfigurationFull(str
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 5b6a4bf680d61b1dd26629840f848d0df8983c62 Add linux-next specific
files for 20220818
Error/Warning: (recently discovered and may have been fixed)
drivers/base/regmap/regmap-mmio.c:231:17: error
On Thu, Aug 18, 2022 at 02:45:17PM +0200, Dominik Haller wrote:
> Add binding for the Emerging Display Technology ETML1010G0DKA panel.
> It's a 10.1" WXGA (1280 x 800) LVDS panel with backlight and capacitive
> touch.
>
> Signed-off-by: Dominik Haller
> ---
> .../devicetree/bindings/display/pane
https://bugzilla.kernel.org/show_bug.cgi?id=216376
Bug ID: 216376
Summary: AMDGPU: display output disables and quickly reenables
when switching AVR into/from standby doing HDMI
passthrough
Product: Drivers
Version
fbcon_do_set_font() calls vc_resize() when font size is changed.
However, if if vc_resize() failed, current implementation doesn't
revert changes for font size, and this causes inconsistent state.
syzbot reported unable to handle page fault due to this issue [1].
syzbot's repro uses fault injectio
https://bugzilla.kernel.org/show_bug.cgi?id=216376
--- Comment #1 from Jure Repinc (jlp.b...@gmail.com) ---
Created attachment 301601
--> https://bugzilla.kernel.org/attachment.cgi?id=301601&action=edit
Xorg.0.log
--
You may reply to this email to add a comment.
You are receiving this mail be
https://bugzilla.kernel.org/show_bug.cgi?id=216376
--- Comment #2 from Jure Repinc (jlp.b...@gmail.com) ---
Created attachment 301602
--> https://bugzilla.kernel.org/attachment.cgi?id=301602&action=edit
lspci
--
You may reply to this email to add a comment.
You are receiving this mail because
https://bugzilla.kernel.org/show_bug.cgi?id=216376
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
On 2022-08-18 12:48, Hamza Mahfooz wrote:
Addresses the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3596:6:
error: stack frame size (2092) exceeds limit (2048) in
'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 this check from the asus-wmi backlight handling:
/* Some Asus desktop boards export an acpi-video backlight interface,
stop this from showing up */
chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
if (chassis_type && !strcmp(chassis_type, "3"))
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
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.
Move all the acpi_backlight=[vendor|native]
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
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
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=216376
--- Comment #4 from Jure Repinc (jlp.b...@gmail.com) ---
If I got it right, the hotplug events are all posted via udev? If so, is it
correct to use "udevadm monitor --environment --udev" to see these events
posted to userspace? Or is there somethi
On Thu, Aug 18, 2022 at 4:10 PM Randy Dunlap wrote:
>
>
>
> On 8/18/22 03:43, Sudip Mukherjee wrote:
> > On Thu, Aug 18, 2022 at 3:09 AM Randy Dunlap wrote:
> >>
> >>
> >>
> >> On 8/17/22 19:01, Alex Deucher wrote:
> >>> On Wed, Aug 17, 2022 at 6:03 PM Sudip Mukherjee (Codethink)
> >>> wrote:
>
https://bugzilla.kernel.org/show_bug.cgi?id=216376
--- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) ---
Yes, those are the events. The desktop environment listens for them and
reacts.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching
Hi--
On 8/18/22 12:15, Sudip Mukherjee wrote:
> On Thu, Aug 18, 2022 at 4:10 PM Randy Dunlap wrote:
>>
>>
>>
>> On 8/18/22 03:43, Sudip Mukherjee wrote:
>>> On Thu, Aug 18, 2022 at 3:09 AM Randy Dunlap wrote:
On 8/17/22 19:01, Alex Deucher wrote:
> On Wed, Aug 17, 2022 at
On 8/18/22 1:42 PM, Hans de Goede wrote:
Move the WMI interface definitions to a header, so that the definitions
can be shared with drivers/acpi/video_detect.c .
Suggested-by: Daniel Dadap
Signed-off-by: Hans de Goede
---
MAINTAINERS | 1 +
.../platform/
1 - 100 of 190 matches
Mail list logo
