Instead of working around the missing bulk register read/write in
regmap_config using regmap_bus callbacks, switch to new regmap_config
read/write callbacks.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Mark Brown
Cc: Maxime Ripard
Cc: Robert Foss
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Currently the regmap_config structure only allows the user to implement
single element register read/write using .reg_read/.reg_write callbacks.
The regmap_bus already implements bulk counterparts of both, and is being
misused as a workaround for the missing bulk read/write callbacks in
Drop two unused register macros, ICN6211_MAX_REGISTER and MIPI_ATE_STATUS_1,
neither of which is used and where the later should be specified using macro
MIPI_ATE_STATUS(1) instead. Drop the _(n) underscore and keep only the (n)
part of register macros. No functional change.
Signed-off-by: Marek
Currently, dpu_hw_lm_collect_misr returns EINVAL if CRC is disabled.
This causes a lot of spam in the DRM debug logs as it's called for every
vblank.
Instead of returning EINVAL when CRC is disabled in
dpu_hw_lm_collect_misr, let's return ENODATA and add an extra ENODATA check
before the debug
Hi Jessica
Please add reported by for dmitry and suggested-by for Rob.
Thanks
Abhinav
On 4/29/2022 5:39 PM, Jessica Zhang wrote:
Currently, dpu_hw_lm_collect_misr returns EINVAL if CRC is disabled.
This causes a lot of spam in the DRM debug logs as it's called for every
vblank.
Instead of
Currently, dpu_hw_lm_collect_misr returns EINVAL if CRC is disabled.
This causes a lot of spam in the DRM debug logs as it's called for every
vblank.
Instead of returning EINVAL when CRC is disabled in
dpu_hw_lm_collect_misr, let's return ENODATA and add an extra ENODATA check
before the debug
Cool! Tested this on three different laptops, and it seems to work great on
all of them. so, this series is:
Tested-by: Lyude Paul
Would review, but I basically have the same comments as jani
On Tue, 2022-04-26 at 15:30 +0300, Jouni Högander wrote:
> This patch set splits out static hdr
On 4/29/22 14:46, Arnd Bergmann wrote:
On Fri, Apr 29, 2022 at 10:23 PM Guenter Roeck wrote:
On 4/29/22 10:48, Guenter Roeck wrote:
I tried the pxa-multiplatform-5.18 branch. Its failures match
those in v5.18-rc1.
Uuh, wait, the build wasn't complete. There are still some
failures. I'll
On Sat, 2022-04-30 at 00:56 +0200, Karol Herbst wrote:
> On Fri, Apr 29, 2022 at 9:54 PM Lyude Paul wrote:
> >
> > There's plenty of ways to fudge the GPU when developing on nouveau by
> > mistake, some of which can result in nouveau seriously spamming dmesg with
> > fault errors. This can be
On Fri, Apr 29, 2022 at 9:54 PM Lyude Paul wrote:
>
> There's plenty of ways to fudge the GPU when developing on nouveau by
> mistake, some of which can result in nouveau seriously spamming dmesg with
> fault errors. This can be somewhat annoying, as it can quickly overrun the
> message buffer
On Fri, Apr 29, 2022 at 10:59 AM Jagan Teki wrote:
> commit <3d7039e1e649> ("drm: bridge: mcde_dsi: Switch to
> devm_drm_of_get_bridge")
> switched to devm_drm_of_get_bridge for looking up if child node has panel
> or bridge.
>
> However commit ("Revert "drm: of: Lookup if child node
> has
On Fri, Apr 29, 2022 at 10:59 AM Jagan Teki wrote:
> commit <3730bc6147b0> ("drm: bridge: mcde_dsi: Drop explicit bridge
> remove") has removed downstream bridge as it's prior commit <3d7039e1e649>
> ("drm: bridge: mcde_dsi: Switch to devm_drm_of_get_bridge") added
> devm_drm_of_get_bridge for
On Fri, Apr 29, 2022 at 10:56 AM Jagan Teki wrote:
> From: Jagan Teki
>
> commit <3d7039e1e649> ("drm: bridge: mcde_dsi: Switch to
> devm_drm_of_get_bridge")
> switched to devm_drm_of_get_bridge for looking up if child node has panel
> or bridge.
>
> However commit ("Revert "drm: of: Lookup
On Fri, 29 Apr 2022 14:31:49 -0300
Jason Gunthorpe wrote:
> On Thu, Apr 21, 2022 at 01:28:31PM -0300, Jason Gunthorpe wrote:
> > Prior series have transformed other parts of VFIO from working on struct
> > device or struct vfio_group into working directly on struct
> > vfio_device. Based on that
On Fri, Apr 29, 2022 at 2:53 PM Dmitry Baryshkov
wrote:
>
> For the past several releases I have been assisting Rob by writing,
> collecting, testing and integrating patches for non-GPU and non-core
> parts of MSM DRM driver, while Rob is more interested in improving the
> GPU-related part. Let's
For the past several releases I have been assisting Rob by writing,
collecting, testing and integrating patches for non-GPU and non-core
parts of MSM DRM driver, while Rob is more interested in improving the
GPU-related part. Let's note this in the MAINTAINERS file.
While we are at it, per Rob's
On Fri, Apr 29, 2022 at 10:23 PM Guenter Roeck wrote:
> On 4/29/22 10:48, Guenter Roeck wrote:
> >
> > I tried the pxa-multiplatform-5.18 branch. Its failures match
> > those in v5.18-rc1.
> >
>
> Uuh, wait, the build wasn't complete. There are still some
> failures. I'll report later.
Sorry
I did some light testing with our anvil (Vulkan) and iris (OpenGL)
Mesa drivers after applying these patches on top of drm-tip tagged
intel/CI_DRM_11574. All the unit tests that I tried passed. I also ran
the gl_manhattan31 benchmark which used the compute engine for iris
compute shader ops.
The LCDIF controller as present in i.MX28/i.MX6SX/i.MX8M Mini/Nano has
CRC_STAT register, which contains CRC32 of the frame as it was clocked
out of the DPI interface of the LCDIF. This is most likely meant as a
functional safety feature.
Unfortunately, there is zero documentation on how the
On 4/29/22 16:08, Stefan Agner wrote:
On 2022-04-11 22:35, Marek Vasut wrote:
The LCDIF controller as present in i.MX28/i.MX6SX/i.MX8M Mini/Nano has
CRC_STAT register, which contains CRC32 of the frame as it was clocked
out of the DPI interface of the LCDIF. This is most likely meant as a
Implement DSI-to-e(DP) mode, which is a mix of currently supported
DSI-to-DPI and DPI-to-(e)DP modes. The input side is configured as
either DSI or DPI, the DP AUX channel is registered for both input
side options, and the DSI host is attached for both DPI and (e)DP
output side options.
One
Factor out register programming to configure the chip video RX side for
reception of video data from DSI or DPI. This is particularly useful in
the (e)DP output mode, where the video data can be received from either
DPI or DSI. While only the former is supported in (e)DP output mode so
far, this
Per toshiba,tc358767.yaml DT binding document, port@2 the output (e)DP
port is optional. In case this port is not described in DT, the bridge
driver operates in DPI-to-DP mode. Make sure the driver treats this as
a valid mode of operation instead of reporting invalid mode.
Fixes: 71f7d9c03118
Certain DSI bridge chips like TC358767/TC358867/TC9595 expect the DSI D0
data lane to be in LP-11 state when released from reset. Currently the
STM32MP157 DSI host wrapper glue logic keeps D0 data lane in LP-00 state
until DSI init happens, which confuses the TC358767 into entering some
sort of
On Thu, 21 Apr 2022 13:28:38 -0300
Jason Gunthorpe wrote:
> When the open_device() op is called the container_users is incremented and
> held incremented until close_device(). Thus, so long as drivers call
> functions within their open_device()/close_device() region they do not
> need to worry
On 4/29/22 10:48, Guenter Roeck wrote:
On 4/28/22 06:44, Arnd Bergmann wrote:
On Sun, Apr 24, 2022 at 8:48 PM Arnd Bergmann wrote:
On Sun, Apr 24, 2022 at 5:28 PM Guenter Roeck wrote:
On 4/24/22 01:52, Arnd Bergmann wrote:
On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck wrote:
into the
On Fri, Apr 29, 2022 at 09:55:37AM +0800, Rex-BC Chen wrote:
> On Thu, 2022-04-28 at 15:33 -0500, Rob Herring wrote:
> > On Thu, 28 Apr 2022 21:37:50 +0800, Rex-BC Chen wrote:
> > > From: Xinlei Lee
> > >
> > > Convert mediatek,dsi.txt to mediatek,dsi.yaml format
> > >
> > > Signed-off-by:
Reviewed-by: Lyude Paul
Also consider this as permission to push this to drm-misc-next
On Fri, 2022-04-29 at 15:42 +0200, Christian König wrote:
> Instead of manually adjusting the plane state.
>
> Signed-off-by: Christian König
> Cc: Karol Herbst
> Cc: Lyude Paul
> Cc: Ben Skeggs
> Cc:
DEFINE_DRM_GEM_FOPS() references drm functions from other headers. For
example drm_open() is defined in drm_file.h and drm_ioctl() is defined
in drm_ioctl.h. Since drm_gem.h doesn't include these headers, it
relies on an implicit include from the .c file to have included these
required headers
There's plenty of ways to fudge the GPU when developing on nouveau by
mistake, some of which can result in nouveau seriously spamming dmesg with
fault errors. This can be somewhat annoying, as it can quickly overrun the
message buffer (or your terminal emulator's buffer) and get rid of actually
Reviewed-by: Lyude Paul
Will push to drm-misc-next in a bit
(Kind of impressed that a bot managed to catch this, considering the route
from here to the code capable of returning < 0 or 0 was definitely not
obvious)
On Fri, 2022-04-29 at 09:03 +, cgel@gmail.com wrote:
> From: Minghao
I've been contributing to v3d through improvements, reviews, testing,
debugging, etc. So, I'm adding myself as a co-maintainer of the V3D
driver.
Signed-off-by: Melissa Wen
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
On 4/19/22 16:37, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most of the interface functions in plat/dma.c are only used from the
> USB driver, which is practically OMAP1 specific, except for compile
> testing.
>
> The omap_get_plat_info(), omap_request_dma() and omap_free_dma()
>
On 4/19/22 16:37, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> No part of plat-omap/dma.c is called on omap2 any more, so
> anything omap2 specific in here can simply be removed.
Reviewed-by: Peter Ujfalusi
> Signed-off-by: Arnd Bergmann
> ---
> arch/arm/plat-omap/dma.c | 217
On 4/19/22 16:37, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most of the plat-omap/dma.c code is specific to the USB
> driver.
The reason is simple: the omap_udc is the only driver which has not been
ported to DMAengine.
I had a patch if I recall to convert it, but I don't have a way to
While the labels may mislead the casual reader, the tail of the function
etnaviv_ioctl_gem_submit is always executed, as a lot of the structures
set up in this function need to be cleaned up regardless of whether the
submit succeeded or failed.
An exception is the newly added
The functionality of drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() is provided automatically by the
drm_kms_poll helpers. Stop calling these functions manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 2 --
1 file changed, 2 deletions(-)
Now as all drivers stopped calling drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() it is safe to remove them complelely.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 25 -
include/drm/drm_bridge_connector.h |
Use drm_connector's helpers enable_hpd and disable_hpd to enable and
disable HPD automatically by the means of drm_kms_helper_poll_*
functions. As the drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() functions are now unused, replace
them with stubs to ease driver
Intruct two drm_connector_helper_funcs: enable_hpd() and disable_hpd().
They are called by drm_kms_helper_poll_enable() and
drm_kms_helper_poll_disable() (and thus drm_kms_helper_poll_init() and
drm_kms_helper_poll_fini()) respectively.
This allows drivers to rely on drm_kms_helper_poll for
The functionality of drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() is provided automatically by the
drm_kms_poll helpers. Stop calling these functions manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/imx/dcss/dcss-dev.c | 4
The functionality of drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() is provided automatically by the
drm_kms_poll helpers. Stop calling these functions manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/omapdrm/omap_drv.c | 41 --
Merge drm_kms_helper_poll_disable() and drm_kms_helper_poll_fini() code
into a common helper function.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_probe_helper.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git
>From all the drivers using drm_bridge_connector only iMX/dcss and OMAP
DRM driver do a proper work of calling
drm_bridge_connector_en/disable_hpd() in right places. Rather than
teaching each and every driver how to properly handle
drm_bridge_connector's HPD, make that automatic.
Add two
Reviewed-by: Alan Previn
On Tue, 2022-04-26 at 17:26 -0700, Daniele Ceraolo Spurio wrote:
> HuC loading via GSC is performed via a PXP command sent through the mei
> modules, so we need both MEI_GSC and MEI_PXP to be available. Given that
> the GSC will do both the transfer and the
minor nit: not sure if its worth mentioning in commit msg that "loaded_via_gsc"
is zero-init-ed as fw_def macros we havent added fw_defs for gsc-loaded-huc-bins
which explains why "loaded_via_gsc" not getting set anywhere in this series.
Reviewed-by: Alan Previn
On Tue, 2022-04-26 at 17:26
On 4/28/22 06:44, Arnd Bergmann wrote:
On Sun, Apr 24, 2022 at 8:48 PM Arnd Bergmann wrote:
On Sun, Apr 24, 2022 at 5:28 PM Guenter Roeck wrote:
On 4/24/22 01:52, Arnd Bergmann wrote:
On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck wrote:
into the defconfig file, otherwise the multiplatform
From: Chris Wilson
When testing whether we can get the GPU to leak information about
non-privileged state, we first need to ensure that the output buffer is
set to a known value as the HW may opt to skip the write into memory for
a non-privileged read of a sensitive register. We chose
From: Chris Wilson
Ensure that we always signal the semaphore when timing out, so that if it
happens to be stuck waiting for the semaphore we will quickly recover
without having to wait for a reset.
Reported-by: CQ Tang
Signed-off-by: Chris Wilson
Cc: CQ Tang
cc: Joonas Lahtinen
From: Chris Wilson
In order to keep the context image parser simple, we assume that all
commands follow a similar format. A few, especially not MI commands on
the render engines, have fixed lengths not encoded in a length field.
This caused us to incorrectly skip over 3D state commands, and
From: Chris Wilson
Even though the initial protocontext we load onto HW has the register
cleared, by the time we save it into the default image, BB_OFFSET has
had the enable bit set. Reclear BB_OFFSET for each new context.
Testcase: igt/i915_selftests/gt_lrc
v2:
Extend it for gen8.
Few bug fixes for lrc selftest.
v3:
Extending the first patch for gen8
Chris Wilson (4):
drm/i915/gt: Explicitly clear BB_OFFSET for new contexts
drm/i915/selftests: Check for incomplete LRI from the context image
drm/i915/selftest: Always cancel semaphore on error
drm/i915/selftest:
For the past several releases I have been assisting Rob by writing,
collecting, testing and integrating patches for non-GPU and non-core
parts of MSM DRM driver, while Rob is more interested in improving the
GPU-related part. Let's note this in the MAINTAINERS file.
Signed-off-by: Dmitry
On Thu, Apr 21, 2022 at 01:28:31PM -0300, Jason Gunthorpe wrote:
> Prior series have transformed other parts of VFIO from working on struct
> device or struct vfio_group into working directly on struct
> vfio_device. Based on that work we now have vfio_device's readily
> available in all the
On 4/29/22 19:20, Fabio Estevam wrote:
From: Fabio Estevam
Add Startek KD070WVFPA043-C069A 7" TFT LCD panel compatible string.
Signed-off-by: Fabio Estevam
Acked-by: Sam Ravnborg
---
Changes since v2:
- None
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file
On 4/29/22 19:20, Fabio Estevam wrote:
From: Heiko Schocher
Add Startek KD070WVFPA043-C069A 7" TFT LCD panel support.
Signed-off-by: Heiko Schocher
[fabio: passed .flags and .bus_flags]
Signed-off-by: Fabio Estevam
Acked-by: Sam Ravnborg
Reviewed-by: Marek Vasut
From: Fabio Estevam
Add Startek KD070WVFPA043-C069A 7" TFT LCD panel compatible string.
Signed-off-by: Fabio Estevam
Acked-by: Sam Ravnborg
---
Changes since v2:
- None
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Heiko Schocher
Add Startek KD070WVFPA043-C069A 7" TFT LCD panel support.
Signed-off-by: Heiko Schocher
[fabio: passed .flags and .bus_flags]
Signed-off-by: Fabio Estevam
Acked-by: Sam Ravnborg
---
Changes since v2:
- Pass the full flags and bus_flags.
Now it's easy to see it's redundant, it's a problematic design where the
fence 'get' part is happening outside the job->dependencies array logic
but the fence 'put' part is happening inside, leads to confusions such
as adding this 'put'
in the first place. I will look into improving this if
Hi,
On Thu, Apr 28, 2022 at 10:51 PM wrote:
>
> From: Minghao Chi
>
> Simplify the return expression.
>
> Reported-by: Zeal Robot
> Signed-off-by: Minghao Chi
> ---
> drivers/gpu/drm/bridge/parade-ps8640.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
Reviewed-by: Douglas
Reviewed-by: Alex Deucher
On Fri, Apr 29, 2022 at 12:08 PM Richard Gong wrote:
>
> Active State Power Management (ASPM) feature is enabled since kernel 5.14.
> There are some AMD Volcanic Islands (VI) GFX cards, such as the WX3200 and
> RX640, that do not work with ASPM-enabled Intel Alder Lake
Active State Power Management (ASPM) feature is enabled since kernel 5.14.
There are some AMD Volcanic Islands (VI) GFX cards, such as the WX3200 and
RX640, that do not work with ASPM-enabled Intel Alder Lake based systems.
Using these GFX cards as video/display output, Intel Alder Lake based
Hi Maxime,
On Fri, Apr 29, 2022 at 05:46:45PM +0200, Maxime Ripard wrote:
> On Fri, Apr 29, 2022 at 01:17:26AM +0300, Laurent Pinchart wrote:
> > On Thu, Apr 28, 2022 at 02:09:42PM +0530, Jagan Teki wrote:
> > > On Wed, Apr 27, 2022 at 8:04 PM Maxime Ripard wrote:
> > > > On Tue, Apr 26, 2022 at
On Fri, Apr 29, 2022 at 11:23:51AM +0100, Mauro Carvalho Chehab wrote:
Em Fri, 29 Apr 2022 12:10:07 +0200
Greg KH escreveu:
On Fri, Apr 29, 2022 at 10:15:03AM +0100, Mauro Carvalho Chehab wrote:
> HI Greg,
>
> Em Fri, 29 Apr 2022 10:30:33 +0200
> Greg KH escreveu:
>
> > On Fri, Apr 29, 2022
On Fri, Apr 29, 2022 at 01:17:26AM +0300, Laurent Pinchart wrote:
> Hi Jagan,
>
> On Thu, Apr 28, 2022 at 02:09:42PM +0530, Jagan Teki wrote:
> > On Wed, Apr 27, 2022 at 8:04 PM Maxime Ripard wrote:
> > > On Tue, Apr 26, 2022 at 01:40:31PM +0530, Jagan Teki wrote:
> > > > On Tue, Apr 26, 2022 at
Applied. Thanks!
On Fri, Apr 29, 2022 at 9:04 AM pengfuyuan wrote:
>
> Fix spelling typo in comments.
>
> Signed-off-by: pengfuyuan
> ---
> drivers/gpu/drm/radeon/atombios.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios.h
Applied. Thanks!
On Fri, Apr 29, 2022 at 1:50 AM wrote:
>
> From: Minghao Chi
>
> Simplify the return expression.
>
> Reported-by: Zeal Robot
> Signed-off-by: Minghao Chi
> ---
> drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff
Applied. Thanks!
On Fri, Apr 29, 2022 at 1:48 AM wrote:
>
> From: Minghao Chi
>
> Simplify the return expression.
>
> Reported-by: Zeal Robot
> Signed-off-by: Minghao Chi
> ---
> drivers/gpu/drm/amd/amdgpu/iceland_ih.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff
Hi Dave, Daniel,
More stuff for 5.19.
The following changes since commit e15c9d06e9ad70df41285ca41d535de6215e0b21:
drm/amd/amdgpu: Update PF2VF header (2022-04-21 16:00:14 -0400)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
On Thu, 28 Apr 2022 15:26:23 +0300, Dan Carpenter wrote:
> The "dsi->bus_clk" pointer cannot be an error pointer at this point.
> The check is confusing and unnecessary. Delete it.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Fri, 29 Apr 2022 05:49:45 +, cgel@gmail.com wrote:
> From: Minghao Chi
>
> Simplify the return expression.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Fri, 29 Apr 2022 09:02:08 +, cgel@gmail.com wrote:
> From: Minghao Chi
>
> Simplify the return expression.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
> -Original Message-
> From: Intel-gfx On Behalf Of
> Bhanuprakash Modem
> Sent: Monday, April 11, 2022 3:21 PM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org; jani.nik...@linux.intel.com;
> ville.syrj...@linux.intel.com;
> +static int output_bpc_show(struct seq_file *m, void *data) {
Can we have a meaningful name instead of 'm' ?
Upon changing this parameter name, you can have my
Reviewed-By: Arun R Murthy
Thanks and Regards,
Arun R Murthy
On 2022-04-11 22:35, Marek Vasut wrote:
> The LCDIF controller as present in i.MX28/i.MX6SX/i.MX8M Mini/Nano has
> CRC_STAT register, which contains CRC32 of the frame as it was clocked
> out of the DPI interface of the LCDIF. This is most likely meant as a
> functional safety feature.
>
>
From: Tvrtko Ursulin
Use lockdep_assert_not_held to simplify and correct the code. Otherwise
false positive are hit if lock state is uknown like after a previous
taint.
Signed-off-by: Tvrtko Ursulin
Reported-by: Ville Syrjälä
Reviewed-by: Ville Syrjälä
---
It's not pretty but it fired again
Am Montag, dem 11.04.2022 um 22:35 +0200 schrieb Marek Vasut:
> The LCDIF controller as present in i.MX28/i.MX6SX/i.MX8M Mini/Nano has
> CRC_STAT register, which contains CRC32 of the frame as it was clocked
> out of the DPI interface of the LCDIF. This is most likely meant as a
> functional
On Mon, 25 Apr 2022 at 16:22, Ramalingam C wrote:
>
> From: Chris Wilson
>
> Userspace may leave predication enabled upon return from the batch
> buffer, which has the consequent of preventing all operation from the
> ring from being executed, including all the synchronisation, coherency
>
We could need to wait for the pin to complete here.
Signed-off-by: Christian König
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_display.c | 8 +++-
1 file changed, 7 insertions(+), 1
Instead of manually adjusting the plane state.
Signed-off-by: Christian König
Cc: Karol Herbst
Cc: Lyude Paul
Cc: Ben Skeggs
Cc: Maxime Ripard
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
This gives us the standard atomic implicit and explicit fencing rules.
Signed-off-by: Christian König
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Roman Li
Cc: Qingqing Zhuo
Cc: Jude Shih
Cc: Wayne Lin
Cc: Rodrigo Siqueira
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23
drm_gem_plane_helper_prepare_fb() was using
drm_atomic_set_fence_for_plane() which ignores all implicit fences when an
explicit fence is already set. That's rather unfortunate when the fb still
has a kernel fence we need to wait for to avoid presenting garbage on the
screen.
So instead update the
https://bugzilla.kernel.org/show_bug.cgi?id=201991
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
On Mon, 25 Apr 2022 at 16:22, Ramalingam C wrote:
>
> From: Chris Wilson
>
> When predication is enabled all commands baring a few (such as MI_BB_END)
> are nop'ed. If we accidentally enable predication while poisoning the
> context, not only is the rest of the poisoning skipped (thus disabling
On Wed, 27 Apr 2022 21:44:34 -0300
Igor Torrente wrote:
> On 4/27/22 04:43, Pekka Paalanen wrote:
> > On Tue, 26 Apr 2022 22:22:22 -0300
> > Igor Torrente wrote:
> >
> >> On April 26, 2022 10:03:09 PM GMT-03:00, Igor Torrente
> >> wrote:
> >>>
> >>>
> >>> On 4/25/22 22:54, Igor Torrente
Hi,
On Fri, 2022-04-22 at 19:24 +0200, Guido Günther wrote:
> Hi,
> On Tue, Apr 19, 2022 at 09:08:48AM +0800, Liu Ying wrote:
> > The Northwest Logic MIPI DSI host controller embedded in i.MX8qxp
> > works with a Mixel MIPI DPHY + LVDS PHY combo to support either
> > a MIPI DSI display or a LVDS
On Mon, 25 Apr 2022 at 16:22, Ramalingam C wrote:
>
> From: Akeem G Abodunrin
>
> When bit 19 of MI_LOAD_REGISTER_IMM instruction opcode is set on tgl+
> devices, HW does not care about certain register address offsets, but
> instead check the following for valid address ranges on specific
On Tue, 26 Apr 2022, Jani Nikula wrote:
> Fix the below drm/edid kernel-doc warnings:
>
> drivers/gpu/drm/drm_edid.c:1589: warning: Function parameter or member
> '_edid' not described in 'drm_edid_header_is_valid'
> drivers/gpu/drm/drm_edid.c:1589: warning: Excess function parameter
>
On 4/29/22 12:20, Thomas Zimmermann wrote:
> Hi Javier
[snip]
>>
>>> We can do this with DRIVER_FIRMWARE. Alternatively, I'd suggest to we
>>> could also used the existing final parameter of
>>> drm_fbdev_generic_setup() to pass a flag that designates a firmware device.
>>>
>>
>> By existing
Am 29.04.22 um 03:13 schrieb Stephen Rothwell:
Hi all,
On Wed, 13 Apr 2022 10:10:14 +1000 Stephen Rothwell
wrote:
On Wed, 6 Apr 2022 10:34:05 +1000 Stephen Rothwell
wrote:
Today's linux-next merge of the amdgpu tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
between
On Thu, 28 Apr 2022, "Wang, Zhi A" wrote:
> Hi folks:
>
> Here is the pull of gvt-next which fixes the compilation error and warnings
> for the the GVT-g refactor patches:
>
> - Fix a compiling warning of non-static function only having one caller.
> - Fix a potential NULL pointer reference in
On Fri, Apr 29, 2022 at 11:23:51AM +0100, Mauro Carvalho Chehab wrote:
> Em Fri, 29 Apr 2022 12:10:07 +0200
> Greg KH escreveu:
>
> > On Fri, Apr 29, 2022 at 10:15:03AM +0100, Mauro Carvalho Chehab wrote:
> > > HI Greg,
> > >
> > > Em Fri, 29 Apr 2022 10:30:33 +0200
> > > Greg KH escreveu:
> >
On 29/04/2022 12:01, cgel@gmail.com wrote:
From: Minghao Chi
Simplify the return expression.
Reported-by: Zeal Robot
Signed-off-by: Minghao Chi
---
drivers/gpu/drm/omapdrm/dss/hdmi_pll.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git
Em Fri, 29 Apr 2022 12:10:07 +0200
Greg KH escreveu:
> On Fri, Apr 29, 2022 at 10:15:03AM +0100, Mauro Carvalho Chehab wrote:
> > HI Greg,
> >
> > Em Fri, 29 Apr 2022 10:30:33 +0200
> > Greg KH escreveu:
> >
> > > On Fri, Apr 29, 2022 at 09:07:57AM +0100, Mauro Carvalho Chehab wrote:
> >
Hi Javier
Am 29.04.22 um 11:23 schrieb Javier Martinez Canillas:
Hello Thomas,
On 4/29/22 11:14, Thomas Zimmermann wrote:
Hi
Am 29.04.22 um 10:42 schrieb Javier Martinez Canillas:
The DRIVER_FIRMWARE flag denotes that a DRM driver uses a framebuffer
that was initialized and provided by the
On Fri, Apr 29, 2022 at 10:15:03AM +0100, Mauro Carvalho Chehab wrote:
> HI Greg,
>
> Em Fri, 29 Apr 2022 10:30:33 +0200
> Greg KH escreveu:
>
> > On Fri, Apr 29, 2022 at 09:07:57AM +0100, Mauro Carvalho Chehab wrote:
> > > Hi Daniel,
> > >
> > > Em Fri, 29 Apr 2022 09:54:10 +0200
> > > Daniel
Rename various instances of pagelist to pagereflist. The list now
stores pageref structures, so the new name is more appropriate.
In their write-back helpers, several fbdev drivers refer to the
pageref list in struct fb_deferred_io instead of using the one
supplied as argument to the function.
Refactor the page-write handler for deferred I/O. Drivers use the
function to let fbdev track written pages of mmap'ed framebuffer
memory.
v3:
* keep locking within track-pages function for readability (Sam)
v2:
* don't export the helper until we have an external caller
Store the per-page state for fbdev's deferred I/O in struct
fb_deferred_io_pageref. Maintain a list of pagerefs for the pages
that have to be written back to video memory. Update all affected
drivers.
As with pages before, fbdev acquires a pageref when an mmaped page
of the framebuffer is being
Use pageref->offset instead of page->index for deferred-I/O writeback
where appropriate. Distinguishes between file-mapping offset and video-
memory offset. While at it, also remove unnecessary references to
struct page.
Fbdev's deferred-I/O code uses the two related page->index and
1 - 100 of 152 matches
Mail list logo
