The timeout arg of usb_bulk_msg() is ms already and it has convert it
to jiffies by msecs_to_jiffies() in usb_start_wait_urb(). So fix the usage
by remove the redundant msecs_to_jiffies() in the macros.
Fixes: 77b8cabf3d52 ("drm/gm12u320: Move driver to drm/tiny")
Signed-off-by: Jinjie Ruan
---
Hi Jinjie,
On 9/3/23 10:55, Jinjie Ruan wrote:
> The timeout arg of usb_bulk_msg() is ms already and it has convert it
> to jiffies by msecs_to_jiffies() in usb_start_wait_urb(). So fix the usage
> by remove the redundant msecs_to_jiffies() in the macros.
>
> Fixes: 77b8cabf3d52 ("drm/gm12u320: M
Hi Alexandra
Quoting Alexandra Diupina (2023-09-03 14:37:09)
> rcar_du_group_get() never returns a negative
> error code (always returns 0), so change
> the comment about returned value
If so, then perhaps this may as well become a void return and remove the
return 0.
That could then clean up so
On Fri, Sep 01, 2023 at 04:41:12PM -0700, Douglas Anderson wrote:
> Based on grepping through the source code this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown
> time. Among other things, this means that if a panel is in use that it
> won't be cleanly pow
Make drm/gem API function names consistent by having locked function
use the _locked postfix in the name, while the unlocked variants don't
use the _unlocked postfix. Rename drm_gem_v/unmap() function names to
make them consistent with the rest of the API functions.
Reviewed-by: Boris Brezillon
S
Freeing drm-shmem GEM right after creating it using
drm_gem_shmem_prime_import_sg_table() frees SGT of the imported dma-buf
and then dma-buf frees this SGT second time.
The v3d_prime_import_sg_table() is example of a error code path where
dma-buf's SGT is freed by drm-shmem and then it's freed sec
Use separate flag for tracking page count bumped by shmem->sgt to avoid
imbalanced page counter during of drm_gem_shmem_free() time. It's fragile
to assume that populated shmem->pages at a freeing time means that the
count was bumped by drm_gem_shmem_get_pages_sgt(), using a flag removes
the ambigu
Add _locked postfix to drm_gem functions that have unlocked counterpart
functions to make GEM functions naming more consistent and intuitive in
regards to the locking requirements.
Reviewed-by: Boris Brezillon
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm
Prepare virtio_gpu_object_create() to addition of memory shrinker support
by replacing open-coded drm_gem_shmem_free() with drm_gem_object_put() that
decrements GEM refcount to 0, which becomes important for drm-shmem because
it will start to use GEM's refcount during the shmem's BO freeing time in
Make all drm-shmem exported symbols GPL to make them consistent with
the rest of drm-shmem symbols.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.
Use atomic refcount_t helper for pages_use_count to optimize pin/unpin
functions by skipping reservation locking while GEM's pin refcount > 1.
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 35 +++--
drivers/gpu/drm
Add separate pages_pin_count for tracking of whether drm-shmem pages are
moveable or not. With the addition of memory shrinker support to drm-shmem,
the pages_use_count will no longer determine whether pages are hard-pinned
in memory, but whether pages exist and are soft-pinned (and could be swappe
The drm_gem_shmem_free() doesn't put GEM's kref to zero, which becomes
important with addition of the shrinker support to drm-shmem that will
use kref=0 in order to prevent taking lock during special GEM-freeing
time in order to avoid spurious lockdep warning about locking ordering
vs fs_reclaim co
This series:
1. Adds common drm-shmem memory shrinker
2. Enables shrinker for VirtIO-GPU driver
3. Switches Panfrost driver to the common shrinker
4. Fixes bugs and improves drm-shmem code
Mesa: https://gitlab.freedesktop.org/digetx/mesa/-/commits/virgl-madvise
IGT:
https://gitlab.freed
Add locked and remove unlocked postfixes from drm-shmem function names,
making names consistent with the drm/gem core code.
Reviewed-by: Boris Brezillon
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 64 +--
driv
Everything that uses the mapped buffer should be agnostic to is_iomem.
The only reason for the is_iomem test is that we're setting shmem->vaddr
to the returned map->vaddr. Now that the shmem->vaddr code is gone, remove
the obsoleted is_iomem test to clean up the code.
Suggested-by: Thomas Zimmerma
Use refcount_t helper for vmap_use_count to make refcounting consistent
with pages_use_count and pages_pin_count that use refcount_t. This will
allow to optimize unlocked vmappings by skipping reservation locking if
refcnt > 1 and also makes vmapping to benefit from the refcount_t's
overflow checks
Add lockless drm_gem_shmem_get_pages() helper that skips taking reservation
lock if pages_use_count is non-zero, leveraging from atomicity of the
refcount_t. Make drm_gem_shmem_mmap() to utilize the new helper.
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm
Prepare for addition of memory shrinker support by attaching shmem pages
to host dynamically on first use. The attachment vq command wasn't fenced
and there was no vq kick made in the BO creation code path, hence the
the attachment already was happening dynamically, but implicitly. Making
attachmen
Replace Panfrost's custom memory shrinker with a common drm-shmem
memory shrinker.
Tested-by: Steven Price # Firefly-RK3288
Reviewed-by: Steven Price
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/panfrost/Makefile | 1 -
drivers/gpu/drm/panfrost/panfrost_device.h| 4 -
Introduce common drm-shmem shrinker for DRM drivers.
To start using drm-shmem shrinker drivers should do the following:
1. Implement evict() callback of GEM object where driver should check
whether object is purgeable or evictable using drm-shmem helpers and
perform the shrinking action
2.
Support generic drm-shmem memory shrinker and add new madvise IOCTL to
the VirtIO-GPU driver. BO cache manager of Mesa driver will mark BOs as
"don't need" using the new IOCTL to let shrinker purge the marked BOs on
OOM, the shrinker will also evict unpurgeable shmem BOs from memory if
guest suppor
The vmapped pages shall be pinned in memory and previously get/put_pages()
were implicitly hard-pinning/unpinning the pages. This will no longer be
the case with addition of memory shrinker because pages_use_count > 0 won't
determine anymore whether pages are hard-pinned (they will be soft-pinned),
Prepare to addition of memory shrinker support by pinning display
framebuffer BO pages in memory while they are in use by display on host.
Shrinker is free to relocate framebuffer BO pages if it doesn't know that
pages are in use, thus pin the pages to disallow shrinker to move them.
Acked-by: Ger
Export drm_gem_shmem_get_pages_sgt_locked() that will be used by virtio-gpu
shrinker during GEM swap-in operation done under the held reservation lock.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ++-
include/drm/drm_gem_shmem_helper.h | 1 +
2 files changed
On 22/08/2023 20:42, Jessica Zhang wrote:
DPU supports a data-bus widen mode for DSI INTF.
Enable this mode for all supported chipsets if widebus is enabled for DSI.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 7 +--
drivers/gpu/drm/msm/disp/d
On 22/08/2023 20:42, Jessica Zhang wrote:
DSI 6G v2.5.x+ supports a data-bus widen mode that allows DSI to send
48 bits of compressed data instead of 24.
Enable this mode whenever DSC is enabled for supported chipsets.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi.c | 2
On 29.08.23 16:35, Jagan Teki wrote:
On Sun, Aug 27, 2023 at 12:03 AM Mimoja wrote:
I appreciate you taking the time to respond!
On 26.08.23 17:18, Marek Vasut wrote:
On 8/26/23 11:55, Mimoja wrote:
"The .prepare() function is typically called before the display
controller
starts to transm
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 remainde
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 maintaine
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 maintaine
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 maintaine
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 maintaine
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 maintaine
Incorrect CFLAGS- usage failed to add -DDYNAMIC_DEBUG_MODULE,
which broke builds with:
CONFIG_DRM_USE_DYNAMIC_DEBUG=Y
CONFIG_DYNAMIC_DEBUG_CORE=Y, but CONFIG_DYNAMIC_DEBUG=N
Also add subdir-ccflags so that all drivers pick up the addition.
Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in dyndb
On 2023-08-22 10:42:07, Jessica Zhang wrote:
> DSI 6G v2.5.x+ supports a data-bus widen mode that allows DSI to send
> 48 bits of compressed data instead of 24.
>
> Enable this mode whenever DSC is enabled for supported chipsets.
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/dsi/
On Tue, 22 Aug 2023 at 17:17, Laurent Pinchart
wrote:
>
> Hi Dmitry,
>
> Thank you for the patches.
>
> On Thu, Aug 17, 2023 at 05:55:13PM +0300, Dmitry Baryshkov wrote:
> > Supporting DP/USB-C can result in a chain of several transparent
> > bridges (PHY, redrivers, mux, etc). This results in dri
* Guenter Roeck :
> Hi,
>
> On Sat, Aug 12, 2023 at 05:48:52PM +0200, Helge Deller wrote:
> > On the parisc architecture, lockdep reports for all static objects which
> > are in the __initdata section (e.g. "setup_done" in devtmpfs,
> > "kthreadd_done" in init/main.c) this warning:
> >
> > IN
From: Bjorn Andersson
In some implementations, such as the Qualcomm platforms, the display
driver has no way to query the current HPD state and as such it's
impossible to distinguish between disconnect and attention events.
Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD
sta
Note, numbering for this series starts from v5, since there were several
revisions for this patchset under a different series title ([1]).
USB altmodes code would send OOB notifications to the drm_connector
specified in the device tree. However as the MSM DP driver uses
drm_bridge_connector, there
Implement the oob_hotplug_event() callback. Translate it to the HPD
notification sent to the HPD bridge in the chain.
Reviewed-by: Janne Grunau
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 31 +++---
1 file changed, 28 insertions(+), 3 deletio
In some cases the bridge drivers would like to receive hotplug events
even in the case new status is equal to the old status. In the DP case
this is used to deliver "attention" messages to the DP host. Stop
filtering the events in the drm_bridge_connector_hpd_cb() and let
drivers decide whether the
During the discussion regarding DisplayPort wrapped in the USB-C
connectors (via the USB-C altmode) it was pointed out that currently
there is no good way to let userspace know if the DRM connector in
question is the 'native' DP connector or if it is the USB-C connector.
An attempt to use DRM_MODE
Userspace needs to identify whether the DisplayPort connector is a
native one or it is wrapped into the USB-C port. Moreover the userspace
might need to point user to the exact location of this Type-C port on
the laptop case.
Existing USB-C altmode implementations (i915, amdgpu) have used the
DRM_
Remove ifdef CONFIG_OF around the drm_bridge::of_node field. This follow
the correponding change to struct device we had since 2.6.39. Having
conditional around the of_node pointers turns out to make driver code
use ugly #ifdef blocks. Drop the conditionals and remove the #ifdef
blocks from the aff
During discussions regarding USB-C vs native DisplayPort it was pointed
out that other implementations (i915, AMD) are using
DRM_MODE_CONNECTOR_DisplayPort for both native and USB-C-wrapped DP
output. Follow this example and make the pmic_glink_altmode driver also
report DipslayPort connector rathe
We need a way to generate and return the Type-C port device names. For
example, it is going to be used by the DRM to provide PATH property for
DisplayPort connectors.
Signed-off-by: Dmitry Baryshkov
---
drivers/usb/typec/class.c | 14 ++
include/linux/usb/typec.h | 2 ++
2 files cha
We need a way to generate and return the Type-C port device names. For
example, it is going to be used by the DRM to provide PATH property for
DisplayPort connectors.
Signed-off-by: Dmitry Baryshkov
---
drivers/usb/typec/tcpm/tcpm.c | 14 ++
include/linux/usb/tcpm.h | 2 ++
2 f
In order to simplify source code and to reduce the amount of ifdefs in
the C files, extract the DRM bridge functionality to the separate file.
Suggested-by: Heikki Krogerus
Suggested-by: Bryan O'Donoghue
Signed-off-by: Dmitry Baryshkov
---
drivers/usb/typec/tcpm/qcom/Makefile | 4 ++
Setup the of_node and fwnode fields for the DRM connector device,
making respective links to appear in /sys.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_sysfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 06662
The kdev->fwnode pointer is never set in drm_sysfs_connector_add(), so
dev_fwnode() checks never succeed, making the respective commit NOP.
And if drm_sysfs_connector_add() is modified to set kdev->fwnode, it
breaks drivers already using components (as it was pointed at [1]),
resulting in a deadlo
Set the bridge's path property to point out that this connector is
wrapped into the Type-C port.
We can not really identify the exact Type-C port because it is
registered separately, by another driver, which is not mandatory and the
corresponding device is not even present on some of platforms, li
In order to properly identify connectors (in particular, DisplayPort
connectors wrapped into USB-C) allow bridge drivers to specify the value
to be used for connector's PATH property.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 12
include/drm/drm_br
Implement proper error path in the qcom_pmic_typec_probe(). This makes
sure that we properly disable hardware blocks and do not leak memory.
Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver")
Signed-off-by: Dmitry Baryshkov
---
drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c
In order to notify the userspace about the DRM connector's USB-C port,
export the corresponding port's name as the bridge's path field.
Signed-off-by: Dmitry Baryshkov
---
drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c | 11 +++
drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_drm.c | 4 +
If the created connector type supports subconnector type property,
create and attach corresponding it. The default subtype value is 0,
which maps to the DRM_MODE_SUBCONNECTOR_Unknown type.
Signed-off-by: Dmitry Baryshkov
---
This is a leftover of my previous attempt to implement USB-C DisplayPor
On 09/08/2023 01:19, Kuogee Hsieh wrote:
DP PHY re-initialization done using dp_ctrl_reinitialize_mainlink() will
cause PLL unlocked initially and then PLL gets locked at the end of
initialization. PLL_UNLOCKED interrupt will fire during this time if the
interrupt mask is enabled.
However current
Read the downstream port info and set the subconnector type accordingly.
Signed-off-by: Dmitry Baryshkov
---
Dependencies: https://patchwork.freedesktop.org/series/123221/
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 -
drivers/gpu/drm/msm/dp/dp_panel.c | 5 +
drivers/gpu/drm/msm
On 29/08/2023 21:47, Stephen Boyd wrote:
This function duplicates the common function drm_dp_read_dpcd_caps().
The array of DPCD registers filled in is one size larger than the
function takes, but from what I can tell that extra byte was never used.
Resize the array and use the common function to
On 29/08/2023 21:47, Stephen Boyd wrote:
Use the common function drm_dp_read_sink_count() instead of open-coding
it. This shrinks the kernel text a tiny bit.
Cc: Vinod Polimera
Cc: Kuogee Hsieh
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_panel.c | 19 +++
1 fi
On 29/08/2023 21:47, Stephen Boyd wrote:
We read the downstream port count and capability info but never use it
anywhere. Remove 'ds_port_cnt' and 'ds_cap_info' and any associated code
from this driver. Fold the check for 'dfp_present' into a call to
drm_dp_is_branch() at the one place it is used
On 29/08/2023 21:47, Stephen Boyd wrote:
The member 'aux_cfg_update_done' is always false. This is dead code that
never runs. Remove it.
Cc: Vinod Polimera
Cc: Kuogee Hsieh
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_panel.c | 15 ---
1 file changed, 15 deletions(
On 29/08/2023 21:47, Stephen Boyd wrote:
These are open-coded versions of common functions. Replace them with the
common code to improve readability.
Cc: Vinod Polimera
Cc: Kuogee Hsieh
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_panel.c | 4 ++--
1 file changed, 2 insertions
On 29/08/2023 21:47, Stephen Boyd wrote:
The function dp_link_parse_sink_count() is really just
drm_dp_read_sink_count(). It debug prints out the bit for content
protection (DP_SINK_CP_READY), but that is not useful beyond debug
because 'link->dp_link.sink_count' is overwritten to only contain th
On 29/08/2023 21:47, Stephen Boyd wrote:
This function is simply drm_dp_is_branch() so use that instead of
open-coding it.
Cc: Vinod Polimera
Cc: Kuogee Hsieh
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
On 29/08/2023 21:47, Stephen Boyd wrote:
This driver open-codes a few of the DPCD register reads when it can be
simplified by using the helpers instead. This series reworks the MSM DP
driver to use the DPCD helpers and removes some dead code along the way.
There's the potential for even more code
On 9/3/23 14:11, Helge Deller wrote:
* Guenter Roeck :
Hi,
On Sat, Aug 12, 2023 at 05:48:52PM +0200, Helge Deller wrote:
On the parisc architecture, lockdep reports for all static objects which
are in the __initdata section (e.g. "setup_done" in devtmpfs,
"kthreadd_done" in init/main.c) this w
On Tue, Aug 22, 2023 at 03:41:18PM +, Deucher, Alexander wrote:
[Public]
-Original Message-
From: Sasha Levin
Sent: Tuesday, August 22, 2023 7:36 AM
To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
Cc: Deucher, Alexander ; Kuehling, Felix
; Koenig, Christian ;
Mike Lothian
2023년 8월 29일 (화) 오전 7:38, Adam Ford 님이 작성:
>
> On Mon, Aug 28, 2023 at 10:59 AM Michael Tretter
> wrote:
> >
> > From: Marco Felsch
> >
> > Since the MIPI configuration can be changed on demand it is very useful
> > to print more MIPI settings during the MIPI device attach step.
> >
> > Signed-of
Each of connectors and CRTCs used by the DRM device provides debugfs
directory, which is used by several standard debugfs files and can
further be extended by the driver. Add such generic debugfs directories
for encoder.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_debugfs.c | 25 +++
Now as we have standard per-encoder debugfs directory, move DPU encoder
status file to that directory.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 45 +++--
1 file changed, 6 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/msm/di
Each of connectors and CRTCs used by the DRM device provides debugfs
directory, which is used by several standard debugfs files and can
further be extended by the driver. Add such generic debugfs directories
for encoder. As a showcase for this dir, migrate `bridge_chains' debugfs
file (which contai
Instead of having a single file with all bridge chains, list bridges
under a corresponding per-encoder debugfs directory.
Example of the listing:
$ cat /sys/kernel/debug/dri/0/encoder-0/bridges
bridge[0]: dsi_mgr_bridge_funcs
type: [0] Unknown
ops: [0]
bridge[1]: lt9611uxc_bridge_
The DPU_PINGPONG_TE flag became unused, we can drop it now.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --gi
rop two feature flags, DPU_INTF_TE and DPU_PINGPONG_TE, in favour of
performing the MDSS revision checks instead.
Changes since v2:
- Added guarding checks for hw_intf and hw_pp in debug print (Marijn)
- Removed extra empty lines (Marijn)
Changes since v1:
- Added missing patch
- Reworked commit
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
corresponding interrupt line.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 6 --
drivers
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 dpu_encoder_phys_cmd_tearcheck_config() is less
useful, as this f
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
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 39 ---
1 file changed, 17 insertions(+)
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 the major && INTF type.
Reviewed-by: Marijn Suijten
Sig
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
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 5 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 1 -
drivers/gpu/d
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
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 8
1 file changed, 8 deletions(-)
diff
Inline the _setup_intf_ops() function, it makes it easier to handle
different conditions involving INTF configuration.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 48 ++---
1 file changed, 22 insertions(+), 26 del
The timeout arg of usb_bulk_msg() is ms already, which has been converted
to jiffies by msecs_to_jiffies() in usb_start_wait_urb(). So fix the usage
by removing the redundant msecs_to_jiffies() in the macros.
And as Hans suggested, also remove msecs_to_jiffies() for the IDLE_TIMEOUT
macro to make
On Thu, Aug 24, 2023 at 11:05:04AM +0300, Imre Deak wrote:
> For fractional bpp values passed to the function in a .4 fixed point
> format, the fractional part is currently ignored due to scaling bpp too
> early. Fix this by scaling the overhead factor instead and to avoid an
> overflow multiplying
From: Ville Syrjälä
The cursor hardware only does sync updates, and thus the hardware
will be scanning out from the old fb until the next start of vblank.
So in order to make the legacy cursor fastpath actually safe we
should not unpin the old fb until we're sure the hardware has
ceased accessing
From: Ville Syrjälä
Silently cancelling vblank works is a bit rude, especially
if said works do any resource management (eg. free memory).
WARN if we ever hit this.
TODO: Maybe drm_crtc_vblank_off() should wait for any
pending work to reach its target vblank before actually
doing anything drasti
2023년 8월 29일 (화) 오전 12:59, Michael Tretter 님이 작성:
>
> The PLL reference clock may change at runtime. Thus, reading the clock
> rate during probe is not sufficient to correctly configure the PLL for
> the expected hs clock.
>
> Read the actual rate of the reference clock before calculating the PLL
2023년 8월 29일 (화) 오전 12:59, Michael Tretter 님이 작성:
>
> The PLL requires a clock between 2 MHz and 30 MHz after the pre-divider.
> The reference clock for the PLL may change due to changes to it's parent
> clock. Thus, the frequency may be out of range or unsuited for
> generating the high speed cloc
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 pr_cont) proves the general rule.
>
> Most DRM.debug calls already comport wit
On Sat, Sep 2, 2023 at 11:13 AM 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
Hi Alexandra,
On Sun, Sep 3, 2023 at 7:10 PM Alexandra Diupina wrote:
> rcar_du_group_get() never returns a negative
> error code (always returns 0), so change
> the comment about returned value
>
> Fixes: cb2025d2509f ("drm/rcar-du: Introduce CRTCs groups")
> Signed-off-by: Alexandra Diupina
T
[Public]
Thank you Lyude and Alex!
Regards,
Wayne
> -Original Message-
> From: Alex Deucher
> Sent: Saturday, September 2, 2023 3:38 AM
> To: Lyude Paul
> Cc: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org; jani.nik...@intel.com; imre.d...@intel.com;
> Wen
92 matches
Mail list logo
