Every caller has a readily available vfio_device pointer, use that instead
of passing in a generic struct device. The struct vfio_device already
contains the group we need so this avoids complexity, extra refcountings,
and a confusing lifecycle model.
Reviewed-by: Christoph Hellwig
Signed-off-by:
RZ/G2L LCD controller composed of Frame compression Processor(FCPVD),
Video signal processor (VSPD) and Display unit(DU). The output of LCDC is
connected to Display parallel interface and MIPI link video interface.
This patch series aims to add basic display support on RZ/G2L SMARC EVK
platform. T
The RZ/G2L LCD controller is composed of Frame Compression Processor
(FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
The DU module supports the following hardware features
− Display Parallel Interface (DPI) and MIPI LINK Video Interface
− Display timing master
− Generates video timi
Fix typo rcar_du_vsp.h->rcar_du_vsp.c
Signed-off-by: Biju Das
---
v3:
* New patch
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 8eb9b2b097ae..9c4d
Number of RPF's VSP is different on R-Car and RZ/G2L
R-Car Gen3 -> 5 RPFs
R-Car Gen2 -> 4 RPFs
RZ/G2L -> 2 RPFs
Add num_rpf to struct rcar_du_device_info to support later
SoC without any code changes.
Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
---
v2->v3:
* Added Rb tag from Laur
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
It has DPI/DSI interfaces and supports a maximum resolution of 1080p
along with 2 RPFs to support blending of two picture layers and
raster operations (ROPs).
The DU part i
Hi Eugeniu,
On Thu, Apr 21, 2022 at 06:12:59PM +0200, Eugeniu Rosca wrote:
> Dear Uli,
> Dear Laurent,
> Dear Renesas community,
>
> On Mo, Mai 30, 2016 at 06:00:13 +0200, Ulrich Hecht wrote:
> > This patch changes to VSPD hardware recommended value.
> > Purpose is highest pixel clock without und
Hi Doug,
>On Thu, Apr 21, 2022 at 7:37 AM Sankeerth Billakanti
> wrote:
>>
>> The panel-edp enables the eDP panel power during probe, get_modes and
>> pre-enable. The eDP connect and disconnect interrupts for the eDP/DP
>> controller are directly dependent on panel power. As eDP display can
>> be
Hi everyone,
After implementing a similar change in the VC4 driver [1], as suggested
by Laurent in the ToDo list [2], I noticed that a similar pattern is
used in the Exynos, Rockchip, STI and sun4i drivers.
This patchset replaces drm_detect_hdmi_monitor() with is_hdmi in the
mentioned drivers.
B
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi.
This driver calls drm_detect_hdmi_monitor() to receive the same
information and stores its own cached value, which is less efficient.
Avoid calling drm_detect_hdmi_monitor() and use drm_displa
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi.
This driver calls drm_detect_hdmi_monitor() to receive the same
information and stores its own cached value, which is less efficient.
Avoid calling drm_detect_hdmi_monitor() and use drm_displa
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi.
This driver calls drm_detect_hdmi_monitor() to receive the same
information and stores its own cached value, which is less efficient.
Avoid calling drm_detect_hdmi_monitor() and use drm_displa
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi.
This driver calls drm_detect_hdmi_monitor() to receive the same
information and stores its own cached value, which is less efficient.
Avoid calling drm_detect_hdmi_monitor() and use drm_displa
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi.
This driver calls drm_detect_hdmi_monitor() to receive the same
information and stores its own cached value, which is less efficient.
Avoid calling drm_detect_hdmi_monitor() and use drm_displa
Hi,
On Thu, Apr 21, 2022 at 9:39 AM Sankeerth Billakanti (QUIC)
wrote:
>
> Hi Doug,
>
> >On Thu, Apr 21, 2022 at 7:37 AM Sankeerth Billakanti
> > wrote:
> >>
> >> The panel-edp enables the eDP panel power during probe, get_modes and
> >> pre-enable. The eDP connect and disconnect interrupts for t
Hi folks:
Here is the PR of gvt-next. Thanks so much for the patience.
Mostly it includes the patch bundle of GVT-g re-factor patches for adapting the
GVT-g with the
new MDEV interfaces:
- Separating the MMIO table from GVT-g. (Zhi)
- GVT-g re-factor. (Christoph)
- GVT-g mdev API cleanup. (Jaso
On Thu, Apr 21, 2022 at 8:22 AM Javier Martinez Canillas
wrote:
>
> On 4/21/22 14:54, Patrik Jakobsson wrote:
> > On Thu, Apr 21, 2022 at 2:47 PM Javier Martinez Canillas
> > wrote:
>
> [snip]
>
> > diff --git a/drivers/gpu/drm/gma500/Kconfig
> > b/drivers/gpu/drm/gma500/Kconfig
> >
On Thu, Apr 21, 2022 at 8:20 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 21.04.22 um 14:54 schrieb Patrik Jakobsson:
> > On Thu, Apr 21, 2022 at 2:47 PM Javier Martinez Canillas
> > wrote:
> >>
> >> Hello Patrik,
> >>
> >> On 4/21/22 14:39, Patrik Jakobsson wrote:
> >>> On Thu, Apr 21, 2022 at 1:49
Add a format helper that converts RGB888 to XRGB. Use this
function in drm_fb_blit_toio(). Fixes simpledrm output for this
combination of formats.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c | 46 +
1 file changed, 46 insertions(+)
di
(resending with dri-devel in cc)
Support conversion from RGB565 and RGB888 to XRGB. This enables
simpledrm to work with framebuffers of such formats.
UEFI and/or Grub will usually set 32-bit output in XRGB format.
The issue can be reproduced by enabling simpledrm and requesting a
console
Add a format helper that converts RGB565 to XRGB. Use this
function in drm_fb_blit_toio(). Fixes simpledrm output for this
combination of formats.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c | 46 +
1 file changed, 46 insertions(+)
di
Not all possible format conversions are supported yet. Print a
warning on unsupported combinations.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_he
On Thu, Apr 21, 2022 at 05:32:32PM +, Wang, Zhi A wrote:
> Hi folks:
>
> Here is the PR of gvt-next. Thanks so much for the patience.
>
> Mostly it includes the patch bundle of GVT-g re-factor patches for adapting
> the GVT-g with the
> new MDEV interfaces:
>
> - Separating the MMIO table f
Hi
Am 21.04.22 um 19:39 schrieb James Hilliard:
On Thu, Apr 21, 2022 at 8:22 AM Javier Martinez Canillas
wrote:
On 4/21/22 14:54, Patrik Jakobsson wrote:
On Thu, Apr 21, 2022 at 2:47 PM Javier Martinez Canillas
wrote:
[snip]
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/
Hi
Am 21.04.22 um 20:22 schrieb Thomas Zimmermann:
Hi
Am 21.04.22 um 19:39 schrieb James Hilliard:
On Thu, Apr 21, 2022 at 8:22 AM Javier Martinez Canillas
wrote:
On 4/21/22 14:54, Patrik Jakobsson wrote:
On Thu, Apr 21, 2022 at 2:47 PM Javier Martinez Canillas
wrote:
[snip]
diff --git
On Thu, Apr 21, 2022 at 1:23 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 21.04.22 um 20:22 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 21.04.22 um 19:39 schrieb James Hilliard:
> >> On Thu, Apr 21, 2022 at 8:22 AM Javier Martinez Canillas
> >> wrote:
> >>>
> >>> On 4/21/22 14:54, Patrik Jakobsson
This series refactors i915's stolen memory region to use ttm.
v2: handle disabled stolen similar to legacy version.
relying on ttm to fail allocs works fine, but is dmesg noisy and causes
testing
dmesg warning regressions.
v3: rebase to latest drm-tip.
fix v2 code
stolen/kernel buffers should not be mmapable by userland.
do not provide callbacks to facilitate this for these buffers.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 32 +
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/driver
ttm managed buffers start off with system resource definitions and ttm_tt
tracking structures allocated (though unpopulated).
currently this prevents clearing of buffers on first move to desired
placements.
The desired behaviour is to clear user allocated buffers and any kernel
buffers that specif
Stolen regions are not page backed or considered iomem.
Prevent flags indicating such.
This correctly prevents stolen buffers from attempting to directly map
them.
See i915_gem_object_has_struct_page() and i915_gem_object_has_iomem()
usage for where it would break otherwise.
Signed-off-by: Robert
prepare for ttm based stolen region by using ttm range manager
as the resource manager for stolen region.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 6 ++--
drivers/gpu/drm/i915/intel_region_ttm.c | 31 +++-
2 files changed, 27 insertio
add callbacks for alloc and free.
this allows region creators to allocate any extra storage they may
require.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_memory_region.c | 16 +---
drivers/gpu/drm/i915/intel_memory_region.h | 2 ++
2 files changed, 15 insertions(+),
refactor stolen memory region to use ttm.
this necessitates using ttm resources to track reserved stolen regions
instead of drm_mm_nodes.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/display/intel_fbc.c | 78 +--
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 -
drivers/gpu/
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
On Thu, Apr 21, 2022 at 7:48 PM James Hilliard
wrote:
>
> On Thu, Apr 21, 2022 at 8:20 AM Thomas Zimmermann wrote:
> >
> > Hi
> >
> > Am 21.04.22 um 14:54 schrieb Patrik Jakobsson:
> > > On Thu, Apr 21, 2022 at 2:47 PM Javier Martinez Canillas
> > > wrote:
> > >>
> > >> Hello Patrik,
> > >>
> >
On 04/21, Harry Wentland wrote:
>
>
> On 2022-04-21 10:37, Melissa Wen wrote:
> > Hi all,
> >
> > I'm examining how DRM color management properties (degamma, ctm, gamma)
> > are applied to AMD display drivers. As far I could understand thanks
> > Nicholas documentation on amdgpu_dm/amdgpu_dm_col
Will be adding some additional control options to DRRS that will
require to have the DRRS downclock mode stored in the crtc_state.
So to optimize memory usage a bit here using it to replace has_drrs
as we can check if the drrs_downclock_mode pointer is different than
null to have the same behavior
Intel hardware supports change between modes with different refresh
rates without any glitches or visual artifacts, that feature is called
seamless DRRS.
So far i915 driver was automatically changing between preferred panel
mode and lower refresh rate mode based on idleness but ChromeOS
compositor
As described in previous commit "drm: Add infrastructure to allow
seamless mode switches" here doing the i915 implementation.
The main steps are:
- drm_atomic_helper_check_modeset() will call
atomic_seamless_mode_switch_check()/intel_drrs_seamless_mode_switch_check()
if conditions match
- intel_dr
Hello,
On Wed, Apr 20, 2022 at 11:52:19PM +, T.J. Mercier wrote:
> From: Hridya Valsaraju
>
> This patch adds a proposal for a new GPU cgroup controller for
> accounting/limiting GPU and GPU-related memory allocations.
> The proposed controller is based on the DRM cgroup controller[1] and
>
Check if 'aspace' is set before using it as it will stay null without
IOMMU, such as on msm8974.
Fixes: bc2112583a0b ("drm/msm/gpu: Track global faults per address-space")
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 5 -
drivers/gpu/drm/msm/msm_gpu.c | 3
As promised here [1], this is a follow up change to separate out
wb_idx and intf_idx for better clarity in dpu_encoder.
This also helps to easily handle boards which do not have a physical
display but can still be validated using writeback interface.
In addition, this also takes care of adding wb
Convert all the usages of intf_idx to wb_idx in
dpu_encoder_phys_wb.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/
Add wb_idx to existing DRM prints in dpu_encoder and also
print the intf_mode so that its clear that for any INTF_CMD/VID
there will be a valid intf_idx and any INTF_WB_* there will be a
valid wb_idx.
Update the debugfs to add the same information. Here is a sample
output with this change:
root:/
Using intf_idx even for writeback interfaces is confusing
because intf_idx is of type enum dpu_intf but the index used
for writeback is of type enum dpu_wb.
In addition, this makes it easier to separately check the
availability of the two as its possible that there are boards
which don't have any
Change the DRM traces to include both the intf_mode
and wb_idx similar to the DRM prints in the previous change.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 13 -
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 26 ++
2 files c
On Thu, 2022-04-21 at 12:17 +0200, Christian König wrote:
> ⚠ External Email
>
> Am 20.04.22 um 21:28 schrieb Zack Rusin:
> > [SNIP]
> > > To figure out what it is could you try the following code
> > > fragment:
> > >
> > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
> > > b/drivers/
On 4/11/22 02:47, Marek Vasut wrote:
All users of this function require width-mm/height-mm DT property to be
present per their DT bindings, make width-mm/height-mm check mandatory.
It is generally a good idea to specify panel dimensions, so userspace
can configure e.g. scaling accordingly.
I wi
On 21/04/2022 23:48, Abhinav Kumar wrote:
Using intf_idx even for writeback interfaces is confusing
because intf_idx is of type enum dpu_intf but the index used
for writeback is of type enum dpu_wb.
In addition, this makes it easier to separately check the
availability of the two as its possible
On 21/04/2022 23:48, Abhinav Kumar wrote:
Add wb_idx to existing DRM prints in dpu_encoder and also
print the intf_mode so that its clear that for any INTF_CMD/VID
there will be a valid intf_idx and any INTF_WB_* there will be a
valid wb_idx.
Update the debugfs to add the same information. Here
On 21/04/2022 23:48, Abhinav Kumar wrote:
Change the DRM traces to include both the intf_mode
and wb_idx similar to the DRM prints in the previous change.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 13 -
drive
Hi Dmitry
Thanks for the review.
One question below.
On 4/21/2022 3:40 PM, Dmitry Baryshkov wrote:
On 21/04/2022 23:48, Abhinav Kumar wrote:
Using intf_idx even for writeback interfaces is confusing
because intf_idx is of type enum dpu_intf but the index used
for writeback is of type enum dpu
This is just quick look up. I basically check some style issues and did
some basic static analyzing.
I have run
- cppcheck (which found couple mistakes)
- flawfinder (did not found anything to my eyes)
- codespell (did find couple typo)
You can run these yourself also or check below.
Couple
Dear Uli,
Dear Laurent,
Dear Renesas community,
On Mo, Mai 30, 2016 at 06:00:13 +0200, Ulrich Hecht wrote:
> This patch changes to VSPD hardware recommended value.
> Purpose is highest pixel clock without underruns.
> In the default R-Car Linux BSP config this value is
> wrong and therefore there
On Fri, 22 Apr 2022 at 02:07, Abhinav Kumar wrote:
>
> Hi Dmitry
>
> Thanks for the review.
>
> One question below.
>
> On 4/21/2022 3:40 PM, Dmitry Baryshkov wrote:
> > On 21/04/2022 23:48, Abhinav Kumar wrote:
> >> Using intf_idx even for writeback interfaces is confusing
> >> because intf_idx i
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> All callers have a struct vfio_device trivially available, pass it in
> directly and avoid calling the expensive vfio_group_get_from_dev().
>
> To support the unconverted kvmgt mdev driver add
> mdev_legacy_get_vfio_device() whic
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> Every caller has a readily available vfio_device pointer, use that instead
> of passing in a generic struct device. The struct vfio_device already
> contains the group we need so this avoids complexity, extra refcountings,
> and
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> Every caller has a readily available vfio_device pointer, use that instead
> of passing in a generic struct device. The struct vfio_device already
> contains the group we need so this avoids complexity, extra refcountings,
> and
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> Use the existing vfio_device versions of vfio_(un)pin_pages(). There is no
> reason to use a group interface here, kvmgt has easy access to a
> vfio_device.
>
> Delete kvmgt_vdev::vfio_group since these calls were the last users
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> Now that callers have been updated to use the vfio_device APIs the driver
> facing group interface is no longer used, delete it:
>
> - vfio_group_get_external_user_from_dev()
> - vfio_group_pin_pages()
> - vfio_group_unpin_pages
On 4/21/2022 5:22 PM, Dmitry Baryshkov wrote:
On Fri, 22 Apr 2022 at 02:07, Abhinav Kumar wrote:
Hi Dmitry
Thanks for the review.
One question below.
On 4/21/2022 3:40 PM, Dmitry Baryshkov wrote:
On 21/04/2022 23:48, Abhinav Kumar wrote:
Using intf_idx even for writeback interfaces is
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> 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
Hi Linus,
Extra quiet after Easter, only have minor i915 and msm pulls. However
I haven't seen a PR from our misc tree in a little while, I've cc'ed
all the suspects. Once that unblocks I expect a bit larger bunch of
patches to arrive.
Otherwise as I said, one msm revert and two i915 fixes.
Rega
The pull request you sent on Fri, 22 Apr 2022 12:56:18 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-04-22
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d569e86915b7f2f9795588591c8d5ea0b66481cb
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
On 4/21/2022 8:22 PM, Yang Yingliang wrote:
It will cause null-ptr-deref if platform_get_resource_byname() returns NULL,
we need check the return value.
Fixes: c6a57a50ad56 ("drm/msm/hdmi: add hdmi hdcp support (V3)")
Signed-off-by: Yang Yingliang
Reviewed-by: Abhinav Kumar
---
drivers/
https://bugzilla.kernel.org/show_bug.cgi?id=214991
Jian-Hong Pan (j...@endlessos.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Res
On 19-04-22, 15:37, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The legacy interface for omap-dma is only used on OMAP1, and the
> same is true for the non-DT case. Make both of these conditional on
> CONFIG_ARCH_OMAP1 being set to simplify the dependency.
Acked-By: Vinod Koul
--
~Vinod
After alloc fail, we do not need to kfree.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index ec709997c9c7..5fb3e69c04c4 100644
--- a/dri
101 - 168 of 168 matches
Mail list logo
