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
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
https://bugzilla.kernel.org/show_bug.cgi?id=214991
Jian-Hong Pan (j...@endlessos.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Res
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/
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
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
> 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
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
>
> 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
> 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
>
> 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
>
> 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
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
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
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
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
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
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:
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 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 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/
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
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
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:/
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/
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
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
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
>
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
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
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
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
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,
> > >>
> >
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
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/
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(+),
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
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/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
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
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
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
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/
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
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
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
(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 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
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
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
> >
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
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
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 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
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 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
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
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
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
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
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
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:
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.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.h | 1
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() which will return the vfio_device pointer
vfio_mdev.c puts in the drv_data.
Acke
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 about the container_users.
These functions can all only be called bet
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()
- vfio_group_iommu_domain()
Reviewed-by: Christoph Hellwig
Signed-off-by: J
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
Acked-by: Eric
The next patch wants the vfio_device instead. There is no reason to store
a pointer here since we can container_of back to the vfio_device.
Reviewed-by: Eric Farman
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_cp.c | 47 -
drivers/s390/cio/vfio_c
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 drivers.
Update the rest of the driver facing API to use vfio_device as an inp
Hi,
On Thu, Apr 21, 2022 at 9:00 AM Sankeerth Billakanti (QUIC)
wrote:
>
> >> + }
> >> +
> >> + /*
> >> +* External bridges are mandatory for eDP interfaces: one has to
> >> +* provide at least an eDP panel (which gets wrapped into panel-
> >bridge).
> >> +*
>
Hi Doug,
>On Thu, Apr 21, 2022 at 7:37 AM Sankeerth Billakanti
> wrote:
>>
>> @@ -1530,6 +1532,61 @@ void msm_dp_debugfs_init(struct msm_dp
>*dp_display, struct drm_minor *minor)
>> }
>> }
>>
>> +static int dp_display_get_next_bridge(struct msm_dp *dp) {
>> + int rc;
>> + stru
On Tue, Apr 19, 2022 at 6:37 PM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> This revisits a series I sent a few years ago:
>
> https://lore.kernel.org/lkml/20191018154052.1276506-1-a...@arndb.de/
>
> All the other ARMv5 conversions are under way now, with
> OMAP1 being the only one still not
Hi,
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
> assumed as a
Hi,
On Thu, Apr 21, 2022 at 7:37 AM Sankeerth Billakanti
wrote:
>
> @@ -1530,6 +1532,61 @@ void msm_dp_debugfs_init(struct msm_dp *dp_display,
> struct drm_minor *minor)
> }
> }
>
> +static int dp_display_get_next_bridge(struct msm_dp *dp)
> +{
> + int rc;
> + struct dp_disp
On Thu, Apr 21, 2022 at 3:34 PM Aaro Koskinen wrote:
>
> Hi,
>
> On Wed, Apr 20, 2022 at 10:00:13PM +0200, Arnd Bergmann wrote:
> > On Wed, Apr 20, 2022 at 7:08 PM Aaro Koskinen wrote:
> > > On Tue, Apr 19, 2022 at 03:36:42PM +0200, Arnd Bergmann wrote:
> > > > From: Arnd Bergmann
> > > >
> > >
Smatch reports this issue
cdn-dp-core.c:51:20: warning: symbol 'rk3399_cdn_dp' was not declared. Should
it be static?
rk3399_cdn_dp is only used in cdn-dp-core.c so change
its storge-class specifier to static.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +-
1 file cha
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_color, DC drivers have
per-plane color correction features:
* - Input gamma LUT (de-normalized)
* - In
The eDP controller does not have a reliable way keep panel
powered on to read the sink capabilities. So, the controller
driver cannot validate if a mode can be supported by the
source. We will rely on the panel driver to populate only
the supported modes for now.
Signed-off-by: Sankeerth Billakant
The source device should ensure the sink is ready before proceeding to
read the sink capability or perform any aux transactions. The sink
will indicate its readiness by asserting the HPD line. The controller
driver needs to wait for the hpd line to be asserted by the sink before
it performs any aux
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
assumed as always connected, the controller driver can skip the eDP
connect and disconne
This patch adds support for generic eDP sink through aux_bus. The eDP/DP
controller driver should support aux transactions originating from the
panel-edp driver and hence should be initialized and ready.
The panel bridge supporting the panel should be ready before the bridge
connector is initializ
This series adds support for generic eDP panel over aux_bus.
These changes are dependent on the following patches:
https://patchwork.kernel.org/project/linux-arm-msm/patch/20220211224006.1797846-5-dmitry.barysh...@linaro.org/
https://patchwork.kernel.org/project/linux-arm-msm/patch/20220211224006.
On Fri, 1 Apr 2022 05:48:08 +0530, Joel Selvaraj wrote:
> Add support for backlight. This panel supports backlight control
> through the QCOM WLED driver in Xiaomi Poco F1 device.
>
>
Applied, thanks!
[3/3] arm64: dts: qcom: sdm845-xiaomi-beryllium: enable qcom wled backlight and
link to panel
Applied. Thanks!
Alex
On Thu, Apr 21, 2022 at 5:03 AM Miaoqian Lin wrote:
>
> When dcn20_clk_src_construct() fails, we need to release clk_src.
>
> Fixes: 6f4e6361c3ff ("drm/amd/display: Add Renoir resource (v2)")
> Signed-off-by: Miaoqian Lin
> ---
> drivers/gpu/drm/amd/display/dc/dcn21/dcn2
Smatch reports this issue
qxl_kms.c:36:5: warning: symbol 'qxl_log_level' was not declared. Should it be
static?
qxl_log_level is defined qxl_kms.c but unused, so remove.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/qxl/qxl_kms.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/d
Applied. Thanks!
Alex
On Thu, Apr 21, 2022 at 6:29 AM Haowen Bai wrote:
>
> aux_rep only memset but no use at all, so we drop it.
>
> Signed-off-by: Haowen Bai
> ---
> drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/di
On 4/21/22 1:14 PM, Jason Gunthorpe wrote:
> On Thu, Apr 21, 2022 at 09:41:30AM +0300, Joonas Lahtinen wrote:
>> + Tvrtko
>>
>> Quoting Christoph Hellwig (2022-04-21 08:47:38)
>>> On Thu, Apr 21, 2022 at 04:57:34AM +, Wang, Zhi A wrote:
Is it possible that I can send two different pull bas
On 2022-04-21 at 18:57:59 +0530, Hellstrom, Thomas wrote:
> On Thu, 2022-04-21 at 17:08 +0530, Ramalingam C wrote:
> > While locating the start of ccs scatterlist in smem scatterlist, that
> > has
> > to be the size of lmem obj size + corresponding ccs data size. Report
> > bug
> > if scatterlist t
On Thu, 2022-04-21 at 17:08 +0530, Ramalingam C wrote:
> Object created with list of memory classes as placement preferences,
> can
> be backed with any memory class of the list as per kernel's migration
> policy for the memory contrain situation. Userspace won't be notified
> of
> the memory resid
On Thu, 2022-04-21 at 17:08 +0530, Ramalingam C wrote:
> Capture the eviction details for Flat-CCS capable lmem only objects
> and
> lmem objects with smem residency. This also captures the impact of
> eviction on object's memory residency and Flat-CCS compression
> state.
>
> Signed-off-by: Rama
Hi,
On Wed, Apr 20, 2022 at 10:00:13PM +0200, Arnd Bergmann wrote:
> On Wed, Apr 20, 2022 at 7:08 PM Aaro Koskinen wrote:
> > On Tue, Apr 19, 2022 at 03:36:42PM +0200, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > This is the full series for converting OMAP1 to multiplatform, rebase
Smatch reports this issue
gv100.c:46:1: warning: symbol 'gv100_gsp' was not declared. Should it be static?
gv100_gsp is only used in gv100.c so change its
storage-class specifier to static.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/gv100.c | 2 +-
1 file changed, 1 inse
On Thu, 2022-04-21 at 17:08 +0530, Ramalingam C wrote:
> While locating the start of ccs scatterlist in smem scatterlist, that
> has
> to be the size of lmem obj size + corresponding ccs data size. Report
> bug
> if scatterlist terminate before that length.
>
> Signed-off-by: Ramalingam C
> ---
>
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
> index 0cff20265f97..a422fa84d53b 100644
> --- a/drivers/gpu/drm/gma500/Kconfig
1 - 100 of 168 matches
Mail list logo
