On Wed, 2023-09-06 at 17:15 -0700, Teres Alexis, Alan Previn wrote:
> Update the GSC-fw input/output HECI packet size to match
> updated internal fw specs.
alan:snip
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
> @@ -14,8 +14,8 @@
>
> +/* PXP-Packet sizes for MTL's GSCCS-HECI
[AMD Official Use Only - General]
> -Original Message-
> From: Imre Deak
> Sent: Friday, August 25, 2023 9:56 PM
> To: Lin, Wayne
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> ly...@redhat.com; jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> Wentland,
Hi Dave, Daniel,
Fixes for 6.6. Bigger than usual since this is ~3 weeks of fixes.
The following changes since commit 3698a75f5a98d0a6599e2878ab25d30a82dd836a:
Merge tag 'drm-intel-next-fixes-2023-08-24' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2023-08-25 12:55:55
Hi,
On 2023/9/6 17:40, Christian König wrote:
Am 06.09.23 um 11:08 schrieb suijingfeng:
Well, welcome to correct me if I'm wrong.
You seem to have some very basic misunderstandings here.
The term framebuffer describes some VRAM memory used for scanout.
This framebuffer is exposed to
Hi Rodrigo/Andi,
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Wednesday, September 6, 2023 7:38 PM
> To: Andi Shyti
> Cc: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Drop force_probe
On 2023/9/7 00:00, Alex Deucher wrote:
On Tue, Sep 5, 2023 at 1:25 PM suijingfeng wrote:
Hi,
On 2023/9/5 13:50, Christian König wrote:
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over
which one
is primary at
Add Cadence HDP-TX HDMI PHY driver for i.MX8MQ.
Cadence HDP-TX PHY could be put in either DP mode or
HDMI mode base on the configuration chosen.
HDMI PHY mode is configurated in the driver.
Signed-off-by: Sandor Yu
Tested-by: Alexander Stein
---
drivers/phy/freescale/Kconfig |
Add Cadence HDP-TX DisplayPort PHY driver for i.MX8MQ
Cadence HDP-TX PHY could be put in either DP mode or
HDMI mode base on the configuration chosen.
DisplayPort PHY mode is configurated in the driver.
Signed-off-by: Sandor Yu
---
drivers/phy/freescale/Kconfig | 9 +
Add bindings for Freescale iMX8MQ DP and HDMI PHY.
Signed-off-by: Sandor Yu
Reviewed-by: Rob Herring
---
.../bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml | 53 +++
1 file changed, 53 insertions(+)
create mode 100644
Add a new DRM DisplayPort and HDMI bridge driver for Candence MHDP8501
used in i.MX8MQ SOC. MHDP8501 could support HDMI or DisplayPort
standards according embedded Firmware running in the uCPU.
For iMX8MQ SOC, the DisplayPort/HDMI FW was loaded and activated by
SOC's ROM code. Bootload binary
Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge.
Signed-off-by: Sandor Yu
Reviewed-by: Krzysztof Kozlowski
---
v8->v9:
* Add Krzysztof's R-b tag
.../display/bridge/cdns,mhdp8501.yaml | 104 ++
1 file changed, 104 insertions(+)
create mode 100644
Allow HDMI PHYs to be configured through the generic
functions through a custom structure added to the generic union.
The parameters added here are based on HDMI PHY
implementation practices. The current set of parameters
should cover the potential users.
Signed-off-by: Sandor Yu
Reviewed-by:
MHDP8546 mailbox access functions will be share to other mhdp driver
and Cadence HDP-TX HDMI/DP PHY drivers.
Move those functions to head file include/drm/bridge/cdns-mhdp-mailbox.h
and convert them to macro functions.
Signed-off-by: Sandor Yu
---
.../drm/bridge/cadence/cdns-mhdp8546-core.c |
The patch set initial support Cadence MHDP8501(HDMI/DP) DRM bridge
drivers and Cadence HDP-TX PHY(HDMI/DP) drivers for Freescale i.MX8MQ.
The patch set compose of DRM bridge drivers and PHY drivers.
Both of them need the followed two patches to pass build.
drm: bridge: Cadence: convert mailbox
Debugging PXP issues can't even begin without understanding precedding
sequence of events. Add drm_dbg into the most important PXP events.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 2 ++
drivers/gpu/drm/i915/pxp/intel_pxp.c | 10 --
Update the max GSC-fw response time to match updated internal
fw specs. Because this response time is an SLA on the firmware,
not inclusive of i915->GuC->HW handoff latency, when submitting
requests to the GSC fw via intel_gsc_uc_heci_cmd_submit helpers,
start the count after the request hits the
On Meteorlake onwards, HW specs require that all user contexts that
run on render or compute engines and require PXP must enforce
run-alone bit in lrc. Add this enforcement for protected contexts.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 23 +++
1
For MTL, update the GSC-HECI packet size and the max firmware
response timeout to match internal fw specs. Enforce setting
run-alone bit in LRC for protected contexts.
Changes from prio revs:
v3: - Patch #1. Only start counting the request completion
timeout from after the request has
Update the GSC-fw input/output HECI packet size to match
updated internal fw specs.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
Hi Danilo,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 6bd3d8da51ca1ec97c724016466606aec7739b9f]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-gpuva_mgr-allow-building-as-module/20230907-054931
base:
Acked-by: Anitha Chrisanthus
> -Original Message-
> From: Jim Cromie
> Sent: Wednesday, September 6, 2023 12:02 PM
> To: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org; intel-
>
For MTL, update the GSC-HECI packet size and the max firmware
response timeout to match internal fw specs. Enforce setting
run-alone bit in LRC for protected contexts.
Changes from prio revs:
v3: - Patch #1. Only start counting the request completion
timeout from after the request has
On Fri, Sep 1, 2023 at 3:11 AM Mauro Carvalho Chehab wrote:
>
> Hi Rae,
>
> Em Thu, 13 Jul 2023 17:31:19 -0400
> Rae Moar escreveu:
>
> > On Wed, Jul 12, 2023 at 10:29 AM Mauro Carvalho Chehab
> > wrote:
> >
> > > As an example for the new documentation tool, add a documentation
> > > for
Quoting Dmitry Baryshkov (2023-09-05 10:43:51)
> For some of the platforms (e.g. SDM660, SDM630, MSM8996, etc.) it is
> possible to support this platform via the DPU driver (e.g. to provide
> support for DP, multirect, etc). Add a modparam to be able to switch
> between these two drivers.
>
> All
On Thu, 7 Sept 2023 at 01:17, Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2023-09-05 10:43:50)
> > diff --git a/drivers/gpu/drm/msm/msm_io_utils.c
> > b/drivers/gpu/drm/msm/msm_io_utils.c
> > index 59d2788c4510..9d0d76f3a319 100644
> > --- a/drivers/gpu/drm/msm/msm_io_utils.c
> > +++
On Thu, 7 Sept 2023 at 01:10, Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2023-09-05 10:43:49)
> > diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> > index 348c66b14683..fb6ee93b5abc 100644
> > --- a/drivers/gpu/drm/msm/msm_mdss.c
> > +++
Quoting Dmitry Baryshkov (2023-09-05 10:43:50)
> diff --git a/drivers/gpu/drm/msm/msm_io_utils.c
> b/drivers/gpu/drm/msm/msm_io_utils.c
> index 59d2788c4510..9d0d76f3a319 100644
> --- a/drivers/gpu/drm/msm/msm_io_utils.c
> +++ b/drivers/gpu/drm/msm/msm_io_utils.c
> @@ -50,6 +50,24 @@ struct clk
On Thu, 7 Sept 2023 at 00:54, Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2023-09-03 19:04:48)
> > The DPU_PINGPONG_TE bit is set for all PINGPONG blocks on DPU < 5.0.
> > Rather than checking for the flag, check for the presense of the
>
> s/presense/presence/
>
> > corresponding interrupt
Quoting Dmitry Baryshkov (2023-09-05 10:43:49)
> diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> index 348c66b14683..fb6ee93b5abc 100644
> --- a/drivers/gpu/drm/msm/msm_mdss.c
> +++ b/drivers/gpu/drm/msm/msm_mdss.c
> @@ -222,6 +222,36 @@ static void
Quoting Dmitry Baryshkov (2023-09-03 19:04:51)
> The DPU_INTF_TE bit is set for all INTF blocks on DPU >= 5.0, however
> only INTF_1 and INTF_2 actually support tearing control (both are
> INTF_DSI). Rather than trying to limit the DPU_INTF_TE feature bit to
> those two INTF instances, check for
Quoting Dmitry Baryshkov (2023-09-03 19:04:52)
> Replace the only user of the DPU_INTF_TE feature flag with the direct
> DPU version comparison.
>
> Reviewed-by: Marijn Suijten
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Quoting Dmitry Baryshkov (2023-09-03 19:04:53)
> The dpu_encoder_phys_cmd_te_rd_ptr_irq() function uses neither hw_intf
> nor hw_pp data, so we can drop the corresponding check.
>
> Reviewed-by: Marijn Suijten
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Quoting Dmitry Baryshkov (2023-09-03 19:04:54)
> As the INTF is fixed at the encoder creation time, we can move the
> check whether INTF supports tearchck to dpu_encoder_phys_cmd_init().
> This function can return an error if INTF doesn't have required feature.
> Performing this check in
Quoting Dmitry Baryshkov (2023-09-03 19:04:50)
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> index 8ec6505d9e78..dd67686f5403 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> +++
Quoting Dmitry Baryshkov (2023-09-03 19:04:49)
> The DPU_PINGPONG_TE flag became unused, we can drop it now.
>
> Reviewed-by: Marijn Suijten
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Quoting Dmitry Baryshkov (2023-09-03 19:04:48)
> The DPU_PINGPONG_TE bit is set for all PINGPONG blocks on DPU < 5.0.
> Rather than checking for the flag, check for the presense of the
s/presense/presence/
> corresponding interrupt line.
The patch checks for the major version though?
Quoting Dmitry Baryshkov (2023-09-03 19:04:47)
> Inline the _setup_pingpong_ops() function, it makes it easier to handle
> different conditions involving PINGPONG configuration.
>
> Reviewed-by: Marijn Suijten
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Make use of the DRM GPUVA managers GPU-VM common dma-resv, external GEM
object tracking, dma-resv locking, evicted GEM object tracking and
validation features.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 4 +-
drivers/gpu/drm/nouveau/nouveau_exec.c | 52
So far the DRM GPUVA manager offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and perform more complex mapping operations on the GPU VA
space.
However, there are more design patterns commonly used by drivers, which
Rename struct drm_gpuvm within struct nouveau_uvmm from 'umgr' to base.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_exec.c| 4 +--
drivers/gpu/drm/nouveau/nouveau_uvmm.c| 32 +++
This patch adds an abstraction layer between the drm_gpuva mappings of
a particular drm_gem_object and this GEM object itself. The abstraction
represents a combination of a drm_gem_object and drm_gpuvm. The
drm_gem_object holds a list of drm_gpuvm_bo structures (the structure
representing this
Provide a common dma-resv for GEM objects not being used outside of this
GPU-VM. This is used in a subsequent patch to generalize dma-resv,
external and evicted object handling and GEM validation.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_gpuva_mgr.c| 10 --
Rename struct drm_gpuva_manager to struct drm_gpuvm including
corresponding functions. This way the GPUVA manager's structures align
very well with the documentation of VM_BIND [1] and VM_BIND locking [2].
It also provides a better foundation for the naming of data structures
and functions
Currently, the DRM GPUVA manager does not have any core dependencies
preventing a module build.
Also, new features from subsequent patches require helpers (namely
drm_exec) which can be built as module.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/Kconfig | 7 +++
So far the DRM GPUVA manager offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and perform more complex mapping operations on the GPU VA
space.
However, there are more design patterns commonly used by drivers, which
On Thu, 2023-09-07 at 00:45 +0800, Juntong Deng wrote:
> There are 'enum drm_ioctl_flags' and 'bool drm_ioctl_flags(...)' with the
> same name, which is not a problem in C, but it can lead to
> 'WARNING: Duplicate C declaration' when generating documentation.
>
> According to the purpose of the
Hi Jim
On 9/6/2023 12:02 PM, Jim Cromie wrote:
By at least strong convention, a print-buffer's trailing newline says
"message complete, send it". The exception (no TNL, followed by a call
to pr_cont) proves the general rule.
Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG,
/* For Default case, driver will set the colorspace */
> @@ -522,7 +524,6 @@ enum drm_colorspace {
> DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED = 13,
> DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT = 14,
> DRM_MODE_COLORIMETRY_BT601_YCC = 15,
> - /* not a va
On 2023-08-25 10:18, Melissa Wen wrote:
> On 08/22, Pekka Paalanen wrote:
>> On Thu, 10 Aug 2023 15:02:47 -0100
>> Melissa Wen wrote:
>>
>>> Instead of relying on color block names to get the transfer function
>>> intention regarding encoding pixel's luminance, define supported
>>>
On Wed, Sep 6, 2023, at 10:35, Thomas Zimmermann wrote:
> Rename the fbdev mmap helper fb_pgprotect() to fb_pgprot_device().
> The helper sets VMA page-access flags for framebuffers in device I/O
> memory. The new name follows pgprot_device(), which does the same for
> arbitrary devices.
>
> Also
On 9/1/2023 09:32, Jeff Johnson wrote:
On 8/30/2023 11:20 PM, Evan Quan wrote:
To support the WBRF mechanism, Wifi adapters utilized in the system must
Since this is the first mention of WBRF in the core wireless code IMO
you should indicate what this is an acronym for and briefly describe
On 2023-08-10 12:02, Melissa Wen wrote:
> Hi all,
>
> Here is the next version of our work to enable AMD driver-specific color
> management properties [1][2]. This series is a collection of
> contributions from Joshua, Harry, and me to enhance the AMD KMS color
> pipeline for Steam Deck/SteamOS
On 2023-08-10 12:02, Melissa Wen wrote:
> On AMD HW, 3D LUT always assumes a preceding shaper 1D LUT used for
> delinearizing and/or normalizing the color space before applying a 3D
> LUT. Add pre-defined transfer function to enable delinearizing content
> with or without shaper LUT, where AMD
On 2023-08-10 12:02, Melissa Wen wrote:
> Add 3D LUT property for plane gamma correction using a 3D lookup table.
> Since a 3D LUT has a limited number of entries in each dimension we want
> to use them in an optimal fashion. This means using the 3D LUT in a
> colorspace that is optimized for
On Wed, 6 Sep 2023 11:51:59 +0800
Sui Jingfeng wrote:
> Hi,
>
>
> On 2023/9/5 22:52, Alex Williamson wrote:
> > On Tue, 5 Sep 2023 03:57:15 +0800
> > Sui Jingfeng wrote:
> >
> >> From: Sui Jingfeng
> >>
> >> On a machine with multiple GPUs, a Linux user has no control over which
> >> one
On 2023-08-10 12:02, Melissa Wen wrote:
> From: Harry Wentland
>
> The region and segment calculation was incapable of dealing
> with regions of more than 16 segments. We first fix this.
>
> Now that we can support regions up to 256 elements we can
> define a better segment distribution for
On Wed, Sep 6, 2023 at 11:56 AM Sarah Walker wrote:
> Add the device tree binding documentation for the IMG AXE GPU used in
> TI AM62 SoCs.
>
> Co-developed-by: Frank Binns
> Signed-off-by: Frank Binns
> Signed-off-by: Sarah Walker
> ---
> Changes since v5:
> - Update compatible string &
Incorrect CFLAGS- usage failed to add -DDYNAMIC_DEBUG_MODULE when needed,
which broke builds with:
CONFIG_DRM_USE_DYNAMIC_DEBUG=Y
CONFIG_DYNAMIC_DEBUG_CORE=Y
CONFIG_DYNAMIC_DEBUG=N
Also add subdir-ccflags so that all drivers pick up the addition.
Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg
By at least strong convention, a print-buffer's trailing newline says
"message complete, send it". The exception (no TNL, followed by a call
to pr_cont) proves the general rule.
Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG,
1288 drm_dbg. Clean up the remainders, in
By at least strong convention, a print-buffer's trailing newline says
"message complete, send it". The exception (no TNL, followed by a call
to pr_cont) proves the general rule.
Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG,
1288 drm_dbg. Clean up the remainders, in
By at least strong convention, a print-buffer's trailing newline says
"message complete, send it". The exception (no TNL, followed by a call
to pr_cont) proves the general rule.
Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG,
1288 drm_dbg. Clean up the remainders, in
By at least strong convention, a print-buffer's trailing newline says
"message complete, send it". The exception (no TNL, followed by a call
to pr_cont) proves the general rule.
Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG,
1288 drm_dbg. Clean up the remainders, in
By at least strong convention, a print-buffer's trailing newline says
"message complete, send it". The exception (no TNL, followed by a call
to pr_cont) proves the general rule.
Most DRM.debug calls already comport with this rule/convention:
207 DRM_DEV_DEBUG, 1288 drm_dbg. Clean up the
On 9/6/2023 02:17, Andi Shyti wrote:
Hi John,
static void guc_cancel_busyness_worker(struct intel_guc *guc)
{
- cancel_delayed_work_sync(>timestamp.work);
+ /*
+* When intel_gt_reset was called, task will hold a lock.
+* To cacel delayed work here, the
On 9/5/2023 23:50, Daniel Vetter wrote:
On Mon, Aug 28, 2023 at 04:01:38PM -0700, John Harrison wrote:
On 8/23/2023 10:37, John Harrison wrote:
On 8/23/2023 09:00, Daniel Vetter wrote:
On Tue, Aug 22, 2023 at 11:53:24AM -0700, John Harrison wrote:
On 8/11/2023 11:20, Zhanjun Dong wrote:
On 2023-08-10 12:03, Melissa Wen wrote:
> From: Joshua Ashton
>
> Signed-off-by: Joshua Ashton
> Signed-off-by: Melissa Wen
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 32 +--
> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 2 +-
> include/uapi/drm/drm_mode.h
On 2023-08-10 12:03, Melissa Wen wrote:
> Map the plane CTM driver-specific property to DC plane, instead of DC
> stream. The remaining steps to program DPP block are already implemented
> on DC shared-code.
>
> Signed-off-by: Melissa Wen
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
Hi Doug Anderson,
> Subject: Re: [PATCH v6 4/4] drm/bridge: panel: Drop CONFIG_OF conditional
> around *_of_get_bridge()
>
> Hi,
>
> On Thu, Aug 31, 2023 at 1:10 AM Biju Das
> wrote:
> >
> > Drop unnecessary CONFIG_OF conditional around devm_drm_of_get_bridge()
> > and
> > drmm_of_get_bridge()
Add a new driver for the Sitronix st7735s display controller
together with a 0.96" 80x160 color TFT display by Winstar.
The driver is very similar to the st7735r driver, but uses a
different pipe_enable sequence and also allows for an
optional regulator to be specified using devicetree.
Add a driver for Sitronix st7735s display controller, as well as a
Winstar wf0096atyaa3dnn0 0.96" 80x160 TFT panel.
The driver code is very similar to st7735r, but with adaptations for
the pipe_enable function. There is also optional support to specify
a power regulator for the display.
Add bindings for a driver for Sitronix st7735s display controller, as
well as for a Winstar wf0096atyaa3dnn0 0.96" 80x160 TFT panel.
Signed-off-by: Stefan x Nilsson
---
.../bindings/display/sitronix,st7735s.yaml | 81 ++
MAINTAINERS
There are 'enum drm_ioctl_flags' and 'bool drm_ioctl_flags(...)' with the
same name, which is not a problem in C, but it can lead to
'WARNING: Duplicate C declaration' when generating documentation.
According to the purpose of the function, rename 'drm_ioctl_flags(...)' to
On 2023-08-10 12:03, Melissa Wen wrote:
> Plane CTM for pre-blending color space conversion. Only enable
> driver-specific plane CTM property on drivers that support both pre- and
> post-blending gamut remap matrix, i.e., DCN3+ family. Otherwise it
> conflits with DRM CRTC CTM property.
>
>
Plugging in an Apple dongle without the HDMI cable attached prints out
an error message in the kernel logs when nothing is actually wrong.
no downstream ports connected
This is because the downstream port for the HDMI connector is not
connected, so the Apple dongle reports that as a zero sink
This function is basically a one-liner when you ignore the debug
logging. Just inline the function and drop the log to simplify the code.
Suggested-by: Dmitry Baryshkov
Cc: Vinod Polimera
Cc: Kuogee Hsieh
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_display.c | 10 +-
1
This is a follow-on to this series[1]. I can resend the whole pile if
desired.
[1] https://lore.kernel.org/r/20230829184735.2841739-1-swb...@chromium.org
Stephen Boyd (2):
drm/msm/dp: Inline dp_display_is_sink_count_zero()
drm/msm/dp: Remove error message when downstream port not connected
On 2023-08-28 04:20, Pekka Paalanen wrote:
> On Fri, 25 Aug 2023 13:37:08 -0100
> Melissa Wen wrote:
>
>> On 08/22, Pekka Paalanen wrote:
>>> On Thu, 10 Aug 2023 15:03:11 -0100
>>> Melissa Wen wrote:
>>>
dc->caps.color.mpc.gamut_remap says there is a post-blending color block
Hi Vinayak,
Thanks for you patch
On 06/09/2023 13:51, Vinayak Hegde wrote:
I encountered a warning during kernel documentation compilation
Usually we write the commit message in imperative mood, please check:
On Wed, Sep 6, 2023 at 10:42 AM Rodrigo Vivi wrote:
>
> On Mon, Sep 04, 2023 at 08:32:40AM +0200, Andi Shyti wrote:
> > Hi Jim,
> >
> > On Sun, Sep 03, 2023 at 12:46:00PM -0600, Jim Cromie wrote:
> > > By at least strong convention, a print-buffer's trailing newline says
> > > "message complete,
On Mon, Sep 04, 2023 at 11:39:55PM +0200, Danilo Krummrich wrote:
> On 8/31/23 21:17, Rodrigo Vivi wrote:
> > On Tue, Aug 29, 2023 at 12:30:04PM -0400, Rodrigo Vivi wrote:
> > > Nouveau has landed the GPU VA helpers, support and documentation
> > > already and Xe is already using the upstream GPU
On 2023-08-10 12:03, Melissa Wen wrote:
> From: Joshua Ashton
>
> Need to funnel the color caps through to these functions so it can check
> that the hardware is capable.
>
> v2:
> - remove redundant color caps assignment on plane degamma map (Harry)
> - pass color caps to degamma params
>
On Mon, Sep 04, 2023 at 11:32:30PM +0200, Danilo Krummrich wrote:
> Hi Rodrigo,
>
> On 8/31/23 21:10, Rodrigo Vivi wrote:
> > On Tue, Aug 29, 2023 at 12:30:03PM -0400, Rodrigo Vivi wrote:
> > > The consensus is for individual drivers VM_BIND uapis with
> > > the GPUVA helpers that are already
Hi Vinayak,
On Wed, 6 Sept 2023 at 22:21, Vinayak Hegde wrote:
>
> I encountered a warning during kernel documentation compilation
> due to a missing colon in the documentation for the
> 'num_fences' variable in the sync_file.h header file.
> This change adds the missing colon to align with the
I encountered a warning during kernel documentation compilation
due to a missing colon in the documentation for the
'num_fences' variable in the sync_file.h header file.
This change adds the missing colon to align with the documentation format.
Signed-off-by: Vinayak Hegde
---
On Mon, Sep 04, 2023 at 08:32:40AM +0200, Andi Shyti wrote:
> Hi Jim,
>
> On Sun, Sep 03, 2023 at 12:46:00PM -0600, Jim Cromie wrote:
> > By at least strong convention, a print-buffer's trailing newline says
> > "message complete, send it". The exception (no TNL, followed by a call
> > to
On Tue, Sep 5, 2023 at 1:25 PM suijingfeng wrote:
>
> Hi,
>
>
> On 2023/9/5 13:50, Christian König wrote:
> > Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
> >> From: Sui Jingfeng
> >>
> >> On a machine with multiple GPUs, a Linux user has no control over
> >> which one
> >> is primary at boot
Hi,
On Thu, Aug 31, 2023 at 1:10 AM Biju Das wrote:
>
> Drop unnecessary CONFIG_OF conditional around devm_drm_of_get_bridge() and
> drmm_of_get_bridge() as it is guarded with #if..#else blocks in
> drm_bridge.h.
>
> Signed-off-by: Biju Das
> ---
> v6:
> * New patch.
> ---
>
Hi,
On Thu, Aug 31, 2023 at 1:10 AM Biju Das wrote:
>
> Having conditional around the of_node pointers turns out to make driver
> code use ugly #ifdef and #if blocks. So drop the conditionals.
>
> Suggested-by: Douglas Anderson
> Signed-off-by: Biju Das
> Reviewed-by: Douglas Anderson
> ---
>
Hi,
On Thu, Aug 31, 2023 at 1:09 AM Biju Das wrote:
>
> The driver has an ID table, but it uses the wrong API for retrieving match
> data and that will lead to a crash, if it is instantiated by user space or
> using ID. From this, there is no user for the ID table and let's drop it
> from the
Hi,
On Thu, Aug 31, 2023 at 1:10 AM Biju Das wrote:
>
> This patch is based on commit c9e358dfc4a8 ("driver-core: remove
> conditionals around devicetree pointers").
>
> Having conditional around the of_node pointer of the drm_bridge
> structure turns out to make driver code use ugly #ifdef
Hi Julius,
On 9/4/23 21:02, Julius Zint wrote:
>
>
> On Mon, 4 Sep 2023, Thomas Weißschuh wrote:
>
>> +Cc Hans who ins involved with the backlight subsystem
>>
>> Hi Julius,
>>
>> today I stumbled upon a mail from Hans [0], which explains that the
>> backlight subsystem is not actually a good
Hi, Boris
On 9/6/23 16:54, Boris Brezillon wrote:
Hi Thomas,
On Wed, 6 Sep 2023 16:08:07 +0200
Thomas Hellström wrote:
Hi, Boris,
On 9/6/23 15:00, Boris Brezillon wrote:
On Wed, 6 Sep 2023 13:57:03 +0200
Thomas Hellström wrote:
Hi, Boris
On 9/6/23 13:09, Boris Brezillon wrote:
On
Hi Thomas,
On Wed, 6 Sep 2023 16:08:07 +0200
Thomas Hellström wrote:
> Hi, Boris,
>
> On 9/6/23 15:00, Boris Brezillon wrote:
> > On Wed, 6 Sep 2023 13:57:03 +0200
> > Thomas Hellström wrote:
> >
> >> Hi, Boris
> >>
> >> On 9/6/23 13:09, Boris Brezillon wrote:
> >>> On Wed, 6 Sep 2023
On 2023-08-29 04:51, Pekka Paalanen wrote:
> On Mon, 28 Aug 2023 12:56:04 -0100
> Melissa Wen wrote:
>
>> On 08/28, Pekka Paalanen wrote:
>>> On Mon, 28 Aug 2023 09:45:44 +0100
>>> Joshua Ashton wrote:
>>>
Degamma has always been on the plane on AMD. CRTC DEGAMMA_LUT has actually
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
---
arch/powerpc/include/asm/machdep.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index
Call __phys_mem_access_prot() from the fbdev mmap helper
fb_pgprot_device(). Allows to avoid the file argument of
NULL.
Signed-off-by: Thomas Zimmermann
---
arch/powerpc/include/asm/fb.h | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/fb.h
Rename the fbdev mmap helper fb_pgprotect() to fb_pgprot_device().
The helper sets VMA page-access flags for framebuffers in device I/O
memory. The new name follows pgprot_device(), which does the same for
arbitrary devices.
Also clean up the helper's parameters and return value. Instead of
the
Remove 'file' parameter from struct machdep_calls.phys_mem_access_prot
and its implementation in pci_phys_mem_access_prot(). The file is not
used on PowerPC. By removing it, a later patch can simplify fbdev's
mmap code, which uses phys_mem_access_prot() on PowerPC.
Signed-off-by: Thomas
Only PowerPC's fb_pgprotect() needs the file argument, although
the implementation does not use it. Pass NULL to the internal
helper in preparation of further updates. A later patch will remove
the file parameter from fb_pgprotect().
While at it, replace the shift operation with PHYS_PFN().
Clean up and rename fb_pgprotect() to work without struct file. Then
refactor the implemnetation for PowerPC. This change has been discussed
at [1] in the context of refactoring fbdev's mmap code.
The first two patches update fbdev and replace fbdev's fb_pgprotect()
with fb_pgprot_device() on all
1 - 100 of 225 matches
Mail list logo
