Hi Daniele,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Daniele-Ceraolo-Spurio/drm-i915-HuC-loading-for-DG2/20220819-070704
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config:
Hi Linus,
Regular weekly fixes. The nouveau patch just enables modesetting on
GA103 hw which is like other ampere cards that are already supported.
amdgpu has 2 weeks of fixes, as Alex was away, so a bit larger than
usual, otherwise some i915 and misc other fixes.
Dave.
drm-fixes-2022-08-19:
On 8/18/22 20:38, Mauro Carvalho Chehab wrote:
> 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:
>
在 2022/8/18 6:31, Felix Kuehling 写道:
Am 2022-07-15 um 04:07 schrieb ZhiJie.zhang:
memleak will happend that reload module due to ignore kfree when
release topology
Signed-off-by: ZhiJie.zhang
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 1 +
1 file changed, 1 insertion(+)
diff
Hi Laurent,
> 2022/08/19 11:08、Laurent Pinchart のメール:
>
> Hello Hayama-san,
>
> Thank you for the patch.
>
> On Wed, Aug 10, 2022 at 05:37:10PM +0900, Takanari Hayama wrote:
>> R-Car DU driver implicitly supports DRM_MODE_BLEND_COVERAGE only.
>> This adds a support for DRM_MODE_BLEND_PREMULTI.
Mauro, would you be fine with this patch going through the DRM tree for
v6.1 ? I don't foresee any risk of conflict with other changes to the
VSP driver scheduled for the next kernel version. If that's fine with
you, could you give an Acked-by ? Otherwise I can send you a pull
request to create an
Hello Hayama-san,
Thank you for the patch.
On Wed, Aug 10, 2022 at 05:37:11PM +0900, Takanari Hayama wrote:
> DRM_MODE_BLEND_PIXEL_NONE ignores an alpha channel.
>
> Rcar-du driver supports only 3 formats with an alpha channel
> (DRM_FORMAT_ARGB1555, DRM_FORMAT_ARGB and
Hello Hayama-san,
Thank you for the patch.
On Wed, Aug 10, 2022 at 05:37:10PM +0900, Takanari Hayama wrote:
> R-Car DU driver implicitly supports DRM_MODE_BLEND_COVERAGE only.
> This adds a support for DRM_MODE_BLEND_PREMULTI. As a consequence,
> DRM_MODE_BLEND_PREMULTI becomes the default. If
Hi Laurent,
> 2022/08/19 11:01、Laurent Pinchart のメール:
>
> Hi Hayama-san,
>
> Thank you for the patch.
>
> On Wed, Aug 10, 2022 at 05:37:09PM +0900, Takanari Hayama wrote:
>> To support DRM blend mode in R-Car DU driver, we must be able to pass
>> a plane with the premultiplied alpha. Adding a
Hi Hayama-san,
Thank you for the patch.
On Wed, Aug 10, 2022 at 05:37:09PM +0900, Takanari Hayama wrote:
> To support DRM blend mode in R-Car DU driver, we must be able to pass
> a plane with the premultiplied alpha. Adding a new property to
> vsp1_du_atomic_config allows the R-Car DU driver to
dml_wrapper* files were removed in commit 724449e30433
("drm/amd/display: Remove unused code"), as they are not used anywhere.
However, the header file wasn't removed, so remove the header as well.
Signed-off-by: Magali Lemes
---
.../gpu/drm/amd/display/dc/inc/dml_wrapper.h | 34
Hi Tomi,
Thank you for the patch.
On Wed, Aug 17, 2022 at 04:28:03PM +0300, Tomi Valkeinen wrote:
> 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
Hi Tomi,
Thank you for the patch.
On Wed, Aug 17, 2022 at 04:28:02PM +0300, Tomi Valkeinen wrote:
> From: Tomi Valkeinen
>
> The rcar DU driver on r8a779a0 has a bug causing some specific colors
> getting converted to transparent colors, which then (usually) show as
> black pixels on the
Hi Tomi,
Thank you for the patch.
On Wed, Aug 17, 2022 at 04:28:01PM +0300, Tomi Valkeinen wrote:
> From: Tomi Valkeinen
>
> rcar_du_regs.h is not needed by rcar_du_drv.c so drop the include.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
>
In vc4_hdmi_encoder_{pre,post}_crtc_enable() commit cd00ed5187bf
("drm/vc4: hdmi: Protect device resources after removal") missed to
unlock the mutex before returning due to drm_dev_enter() indicating the
device being unplugged.
Fixes: cd00ed5187bf ("drm/vc4: hdmi: Protect device resources after
(Hardware) resources which are bound to the driver and device lifecycle
must not be accessed after the device and driver are unbound.
However, the DRM device isn't freed as long as the last user closed it,
hence userspace can still call into the driver.
Therefore protect the critical sections
Hi,
I've found a few potential issues left after the hotplug rework.
In vc4_hdmi.c we're missing two mutex_unlock() calls when the device is
unplugged.
vc4_crtc and vc4_plane seem to miss some drm_dev_enter()/drm_dev_exit() calls
to protect against resource access after the device/driver is
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+strace: https://syzkaller.appspot.com/x/log.txt?x=1331f44708
kernel config: https://syzkaller.appspot.com/x/.config?x=924833c12349a8c0
On 8/19/22 07:13, Laurent Pinchart wrote:
CAUTION: Email originated externally, do not click links or open attachments
unless you recognize the sender and know the content is safe.
On Thu, Aug 18, 2022 at 02:33:42PM +0800, Hsia-Jun Li wrote:
On 8/18/22 14:06, Tomasz Figa wrote:
On Tue,
From: Madhumitha Tolakanahalli Pradeep
In Display version 14, Transcoder Chicken Registers are moved from DPRZ to DRPOS
to reduce register signal crossings for Unit Interface Optimization.
This patch modifies the CHICKEN_TRANS macro to add a DISPLAY_VER check for
calculating the correct
Display version 14 platforms have different credits values compared to ADL-P.
Update the credits based on pipe usage.
v2: Simplify DBOX BW Credit definition(MattR)
Bspec: 49213
Cc: Jose Roberto de Souza
Cc: Matt Roper
Original Author: Caz Yokoyama
Signed-off-by: José Roberto de Souza
From: José Roberto de Souza
Display version 14 also supports MBUS joining just like ADL-P
and also it does not need MBUS initialization, so extending ADL-P
code paths to display version 14 and higher.
Bspec: 49213
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
Signed-off-by:
From: Imre Deak
Add support for display power wells on MTL. The differences from XE_LPD:
- The AUX HW block is moved to the PICA block, where the registers are on
an always-on power well and the functionality needs to be powered on/off
via the AUX_CH_CTL register: [1], [2]
- The DDI IO power
Meteorlake uses a similar DBUF calculations as ADL-P.
Reuse the call flow for meteorlake.
Bspec: 49255
Original Author: Caz Yokoyama
Reviewed-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
From: Imre Deak
On MTL TypeC ports the AUX_CH_CTL and AUX_CH_DATA addresses have
changed wrt. previous platforms, adjust the code accordingly.
Signed-off-by: Imre Deak
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_dp_aux.c | 45 -
Since Xe LPD+, Memory latency data are in LATENCY_LPX_LPY registers
instead of GT driver mailbox.
v2: Use the extracted wm latency adjustment function(Matt)
Bspec: 64608
Cc: Matt Roper
Original Author: Caz Yokoyama
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/i915_reg.h | 7
Like ADL_P, Meteorlake has different memory characteristics from
past platforms. Update the values used by our memory bandwidth
calculations accordingly.
Bspec: 64631
Reviewed-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
Signed-off-by: José Roberto de Souza
---
No need to update mask value/restrict because
"Pcode only wants to use GV bandwidth value, not the mask value."
for Display version greater than 14.
Bspec: 646365
Cc: Matt Roper
Original Author: Caz Yokoyama
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_pm.c | 18
From: Clint Taylor
MTL has a fixed rawclk of 38400Khz. Register does not need to be
reprogrammed.
Bspec: 49304
Reviewed-by: Matt Roper
Signed-off-by: Clint Taylor
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 7 +++
1 file changed, 7 insertions(+)
Watermark latency is adjusted in cases when latency is 0us for level
greater than 1, the subsequent levels are disabled. Extract this logic
into its own function.
Suggested-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_pm.c | 88
From: Matt Roper
Previously only dgfx platforms had a 4MB MMIO range, but starting with
MTL we now use the larger range for all platforms.
Bspec: 63834, 63830
Signed-off-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_uncore.c | 11 ++-
1 file
From: Matt Roper
The part of the media and blitter engine contexts that we care about for
setting up an initial state are the same on MTL as they were on DG2
(and PVC), so we need to update the driver conditions to re-use the DG2
context table.
For render/compute engines, the part of the
From: José Roberto de Souza
The GMD step field do not properly match the current stepping convention
that we use(STEP_A0, STEP_A1, STEP_B0...).
One platform could have { arch = 12, rel = 70, step = 1 } and the
actual stepping is STEP_B0 but without the translation of the step
field would mean
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 IP block (graphics, media, display) will have their own
architecture major.minor versions and stepping ID's which should be
From: Matt Roper
Unlike the Xe_HP platforms, MTL only has a single CCS engine; the
quad-based engine masking logic does not apply to this platform (or
presumably any future platforms that only have 0 or 1 CCS).
Signed-off-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
Add tables to map the GMBUS pin pairs to GPIO registers and port to DDC.
>From spec we have registers GPIO_CTL[1-5] mapped to native display phys and
GPIO_CTL[9-14] are mapped to TC ports.
BSpec: 49306
Original Author: Brian J Lovin
Signed-off-by: Radhakrishna Sripada
---
Add support for Meteorpoint(MTP) PCH used with Meteorlake.
Cc: Matt Roper
Reviewed-by: Anusha Srivatsa
Signed-off-by: Clint Taylor
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_pch.c | 9 -
drivers/gpu/drm/i915/intel_pch.h | 4
2 files changed, 12
The PCI Id's and platform definition are posted earlier.
This series adds handful of early enablement patches including
support for display power wells, VBT and AUX Channel mapping,
PCH and gmbus support, dbus, mbus, sagv and memory bandwidth support.
This series also add the support for a new
On 8/19/22 07:16, Laurent Pinchart wrote:
CAUTION: Email originated externally, do not click links or open attachments
unless you recognize the sender and know the content is safe.
Hi Hsia-Jun,
Thank you for the patch.
On Tue, Aug 09, 2022 at 12:27:49AM +0800, Hsia-Jun Li wrote:
From:
On 8/19/22 07:08, Laurent Pinchart wrote:
CAUTION: Email originated externally, do not click links or open attachments
unless you recognize the sender and know the content is safe.
Hi Hsia-Jun,
On Tue, Aug 09, 2022 at 12:27:48AM +0800, Hsia-Jun Li wrote:
From: "Hsia-Jun(Randy) Li"
Hi Hsia-Jun,
Thank you for the patch.
On Tue, Aug 09, 2022 at 12:27:49AM +0800, Hsia-Jun Li wrote:
> From: "Hsia-Jun(Randy) Li"
>
> Memory Traffic Reduction(MTR) is a module in Synaptics
> VideoSmart platform could process lossless compression image
> and cache the tile memory line.
>
> Those
On Thu, Aug 18, 2022 at 02:33:42PM +0800, Hsia-Jun Li wrote:
> On 8/18/22 14:06, Tomasz Figa wrote:
> > On Tue, Aug 9, 2022 at 1:28 AM Hsia-Jun Li wrote:
> >>
> >> From: "Hsia-Jun(Randy) Li"
> >>
> >> The most of detail has been written in the drm.
This patch still needs a description of the
Hi Doug
On 8/17/2022 1:48 PM, Doug Anderson wrote:
Hi,
On Wed, Jul 20, 2022 at 3:42 PM Doug Anderson wrote:
Hi,
On Wed, Jul 20, 2022 at 1:46 PM Rob Clark wrote:
On Fri, Jul 8, 2022 at 8:25 AM Doug Anderson wrote:
Hi,
On Wed, Jul 6, 2022 at 12:14 PM Stephen Boyd wrote:
Set the
Hi Hsia-Jun,
On Tue, Aug 09, 2022 at 12:27:48AM +0800, Hsia-Jun Li wrote:
> From: "Hsia-Jun(Randy) Li"
>
> Those pixel formats are used in Synaptics's VideoSmart series SoCs,
> likes VS640, VS680. I just disclose the pixel formats used in the video
> codecs and display pipeline this time.
Given that HuC load is delayed on DG2, this patch adds support for a fence
that can be used to wait for load completion. No waiters are added in this
patch (they're coming up in the next one), to keep the focus of the
patch on the tracking logic.
The full HuC loading flow on boot DG2 is as
Both are required for HuC loading.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/Kconfig.debug | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index e7fd3e76f8a2..a6576ffbc4dc 100644
---
From: Tomas Winkler
Add support for loading HuC via a pxp stream command.
Signed-off-by: Tomas Winkler
Signed-off-by: Vitaly Lubart
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Reviewed-by: Alan Previn
---
drivers/gpu/drm/i915/Makefile | 3 +-
The current HuC status getparam return values are a bit confusing in
regards to what happens in some scenarios. In particular, most of the
error cases cause the ioctl to return an error, but a couple of them,
INIT_FAIL and LOAD_FAIL, are not explicitly handled and neither is
their expected return
The GSC will perform both the load and teh authentication, so we just
need to check the auth bit after the GSC has replied.
Since we require the PXP module to load the HuC, the earliest we can
trigger the load is during the pxp_bind operation.
Note that GSC-loaded HuC survives GT reset, so we
From: Vitaly Lubart
Command to be sent via the stream interface are written to a local
memory page, whose address is then provided to the GSC.
The interface supports providing a full sg with multiple pages for both
input and output messages, but since for now we only aim to support short
and
The fw name is different and we need to record the fact that the blob is
gsc-loaded, so add a new macro to help.
Note: A-step DG2 G10 does not support HuC loading via GSC and would
require a separate firmware to be loaded the legacy way, but that's
not a production stepping so we're not going to
Wait on the fence to be signalled to avoid the submissions finding HuC
not yet loaded.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tony Ye
Reviewed-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 6 ++
drivers/gpu/drm/i915/i915_request.c| 24
2
From: Tomas Winkler
With on-boards graphics card, both i915 and MEI
are in the same device hierarchy with the same parent,
while for discrete gfx card the MEI is its child device.
Adjust the match function for that scenario
by matching MEI parent device with i915.
V2:
1. More detailed commit
From: Tomas Winkler
GSC command is and extended header containing a scatter gather
list and without a data buffer. Using MEI_CL_IO_SGL flag,
the caller send the GSC command as a data and the function internally
moves it to the extended header.
Signed-off-by: Tomas Winkler
Signed-off-by:
The mei_pxp module is required to send the command to load authenticate
the HuC to the GSC even if pxp is not in use for protected content
management.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Reviewed-by: Alan Previn
---
drivers/gpu/drm/i915/Makefile| 10 +++---
This is a squash of the GSC support for XeHP SDV and DG2 series, which
is being reviewed separately at:
https://patchwork.freedesktop.org/series/106638/
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_gsc.c | 118 +---
On DG2, HuC loading is performed by the GSC, via a PXP command. The load
operation itself is relatively simple (just send a message to the GSC
with the physical address of the HuC in LMEM), but there are timing
changes that requires special attention. In particular, to send a PXP
command we need
Hi Wolfram,
Thank you for the patch.
On Thu, Aug 18, 2022 at 11:00:07PM +0200, Wolfram Sang wrote:
> Follow the advice of the below link and prefer 'strscpy' in this
> subsystem. Conversion is 1:1 because the return value is not used.
> Generated by a coccinelle script.
>
> Link:
>
On Fri, Aug 05, 2022 at 06:04:08PM +0800, Nancy.Lin wrote:
[..]
> Hello Matthias,
>
> This series is about mmsys configuration of external display path.
>
> It is in version *25*, and it is reviewed by many reviewers, like CK
> and Angelo.
> The reset.h is also reviewed by Krzysztof.
>
> This
Hi Nancy,
On Mon, Jul 11, 2022 at 03:52:42PM +0800, Nancy.Lin wrote:
[..]
> static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
> .clk_driver = "clk-mt2701-mm",
> .routes = mmsys_default_routing_table,
> @@ -86,6 +88,7 @@ static const struct mtk_mmsys_driver_data
Hello everyone!
The X.org board is soliciting proposals to host XDC in 2023. Since
XDC 2022 is being held in North America this year, XDC 2023 is expected
to be in Europe. However, the board is open to other locations,
especially if there's an interesting co-location with another
conference.
If
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wolfram Sang
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wolfram Sang
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wolfram Sang
On Thu, 2022-08-18 at 13:42 -0700, Vinay Belgaumkar wrote:
> These tests were specifically designed for host Turbo. Skip
> them when SLPC is enabled as they fail frequently. We will look
> to keep adding to SLPC test coverage with these scenarios.
>
> Bug:
These tests were specifically designed for host Turbo. Skip
them when SLPC is enabled as they fail frequently. We will look
to keep adding to SLPC test coverage with these scenarios.
Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/3963
Bug:
Hi Nancy,
On Thu, Aug 04, 2022 at 03:28:21PM +0800, Nancy.Lin wrote:
> Add vdosys1 ETHDR definition.
>
> Signed-off-by: Nancy.Lin
> Reviewed-by: Chun-Kuang Hu
> Reviewed-by: AngeloGioacchino Del Regno
>
Some line-wrapping happened to your patch when sending, so it's corrupted and
won't
On Wed, Aug 17, 2022 at 8:10 AM Maxime Ripard wrote:
>
> Hi,
>
> On Tue, Aug 16, 2022 at 05:34:51PM +0100, Sudip Mukherjee (Codethink) wrote:
> > Not sure if it has been reported but the mainline kernel shows a drm warning
> > on RPI4B.
> >
> > [ 14.821276] WARNING: CPU: 3 PID: 187 at
> >
We can do a few more things to improve our chance at a successful gpu
recovery, especially during a hangcheck timeout:
1. Halt CP and GMU core
2. Do RBBM GBIF HALT sequence
3. Do a soft reset of GPU core
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
When prepare-slumber hfi fails, we should follow a6xx_gmu_force_off()
sequence.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
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 driver.
This feature requires support from the platform's gpucc driver.
We already enable gpu power from msm_gpu_submit(), so avoid a duplicate
pm_runtime_get/put from msm_job_run().
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/msm_ringbuffer.c | 4
1 file changed, 4 deletions(-)
diff --git
Instead of separate refcount for each submit, take single rpm refcount
on behalf of all the submits. This makes it easier to drop the rpm
refcount during recovery in an upcoming patch.
Signed-off-by: Akhil P Oommen
---
(no changes since v3)
Changes in v3:
- New patch
There are some hardware logic under CX domain. For a successful
recovery, we should ensure cx headswitch collapses to ensure all the
stale states are cleard out. This is especially true to for a6xx family
where we can GMU co-processor.
Currently, cx doesn't collapse due to a devlink between gpu
In the scenario where there is one a single submit which is hung, gpu is
power collapsed when it is retired. Because of this, by the time we call
reover(), gpu state would be already clear. Fix this by correctly
managing the pm runtime votes.
Signed-off-by: Akhil P Oommen
---
(no changes since
Recently, I debugged a few device crashes which occured during recovery
after a hangcheck timeout. It looks like there are a few things we can
do to improve our chance at a successful gpu recovery.
First one is to ensure that CX GDSC collapses which clears the internal
states in gpu's CX
Add support for Reset using GPUCC driver for GPU. This helps to ensure
that GPU state is reset by making sure that CX head switch is collapsed.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git
Allow a consumer driver to poll for cx gdsc collapse through Reset
framework.
Signed-off-by: Akhil P Oommen
---
Changes in v3:
- Convert 'struct qcom_reset_ops cx_gdsc_reset' to 'static const' (Krzysztof)
Changes in v2:
- Minor update to use the updated custom reset ops implementation
Allow soc specific clk drivers to specify a custom reset operation. We
will use this in an upcoming patch to allow gpucc driver to specify a
differet reset operation for cx_gdsc.
Signed-off-by: Akhil P Oommen
---
Changes in v3:
- Use pointer to const for "struct qcom_reset_ops" in
Add a reset op compatible function to poll for gdsc collapse.
Signed-off-by: Akhil P Oommen
---
(no changes since v2)
Changes in v2:
- Minor update to function prototype
drivers/clk/qcom/gdsc.c | 23 +++
drivers/clk/qcom/gdsc.h | 7 +++
2 files changed, 26
Add necessary definitions in gpucc bindings to ensure gpu cx gdsc collapse
through 'reset' framework for SC7280.
Signed-off-by: Akhil P Oommen
Acked-by: Krzysztof Kozlowski
---
(no changes since v1)
include/dt-bindings/clock/qcom,gpucc-sc7280.h | 3 +++
1 file changed, 3 insertions(+)
diff
Some clients like adreno gpu driver would like to ensure that its gdsc
is collapsed at hardware during a gpu reset sequence. This is because it
has a votable gdsc which could be ON due to a vote from another subsystem
like tz, hyp etc or due to an internal hardware signal. To allow
this, gpucc
On 8/18/22 1:42 PM, Hans de Goede wrote:
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
On 8/18/22 1:42 PM, Hans de Goede wrote:
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
On 8/18/22 1:42 PM, Hans de Goede wrote:
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
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 +
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
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
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 #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
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
---
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.
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_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
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
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
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
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,
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"))
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
---
1 - 100 of 191 matches
Mail list logo
