On Mon, Dec 07, 2020 at 11:20:56AM +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Gasket.
>
> Signed-off-by: Liu Ying
> ---
> Note that this depends on the 'two cell binding' clock patch set which has
> already landed in Shawn's i.MX clk/imx git branch.
On Mon, Dec 07, 2020 at 11:20:57AM +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Channel.
>
> Signed-off-by: Liu Ying
> ---
> Note that this depends on the 'two cell binding' clock patch set which has
> already landed in Shawn's i.MX clk/imx git branch
Hi Randy,
> >>
> >> Yes, RETURNS: will work. It just looks like any kernel-doc section name,
> >> such as Context: or Note:.
> >> However, the documented format for return info is "Return:".
> >> (see Documentation/doc-guide/kernel-doc.rst)
> >
> > Thanks for the note. I asked for RETURNS: because
On 11:32-20201204, Boris Brezillon wrote:
> On Tue, 1 Dec 2020 17:48:27 +0530
> Nikhil Devshatwar wrote:
>
> > input_bus_flags are specified in drm_bridge_timings (legacy) as well
> > as drm_bridge_state->input_bus_cfg.flags
> >
> > The flags from the timings will be deprecated. Bridges are supp
On 11:42-20201204, Boris Brezillon wrote:
> On Tue, 1 Dec 2020 17:48:27 +0530
> Nikhil Devshatwar wrote:
>
> > input_bus_flags are specified in drm_bridge_timings (legacy) as well
> > as drm_bridge_state->input_bus_cfg.flags
> >
> > The flags from the timings will be deprecated. Bridges are supp
Hi James,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master drm/drm-next
v5.10-rc7 next-20201207]
[If your patch is
https://bugzilla.kernel.org/show_bug.cgi?id=210467
--- Comment #7 from Alexey (intervio...@gmail.com) ---
Problem in firmware. I downgrade linux-firmware package, pp_dpm_mclk now "0:
400Mhz" at start.
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
Am 07.12.20 um 17:00 schrieb Andrey Grodzovsky:
On 12/7/20 6:13 AM, Christian König wrote:
Am 04.12.20 um 16:10 schrieb Andrey Grodzovsky:
On 12/4/20 3:13 AM, Christian König wrote:
Thinking more about that I came to the conclusion that the whole
approach here isn't correct.
See even when
On 12/7/20 1:04 PM, Christian König wrote:
Am 07.12.20 um 17:00 schrieb Andrey Grodzovsky:
On 12/7/20 6:13 AM, Christian König wrote:
Am 04.12.20 um 16:10 schrieb Andrey Grodzovsky:
On 12/4/20 3:13 AM, Christian König wrote:
Thinking more about that I came to the conclusion that the whole a
Am 07.12.20 um 20:09 schrieb Andrey Grodzovsky:
On 12/7/20 1:04 PM, Christian König wrote:
Am 07.12.20 um 17:00 schrieb Andrey Grodzovsky:
On 12/7/20 6:13 AM, Christian König wrote:
Am 04.12.20 um 16:10 schrieb Andrey Grodzovsky:
On 12/4/20 3:13 AM, Christian König wrote:
Thinking more abo
https://bugzilla.kernel.org/show_bug.cgi?id=210467
--- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) ---
Can you narrow down which specific firmware? Also what what versions did you
try?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
On Mon, Dec 7, 2020 at 5:33 PM Christian König
wrote:
>
> Based on an idea from Dave, but cleaned up a bit.
>
> We had multiple fields for essentially the same thing.
>
> Now bo->size is the original size of the BO in arbitrary
> units, usually bytes.
>
> bo->mem.num_pages is the size in number of
Am 07.12.20 um 20:33 schrieb Daniel Vetter:
On Mon, Dec 7, 2020 at 5:33 PM Christian König
wrote:
Based on an idea from Dave, but cleaned up a bit.
We had multiple fields for essentially the same thing.
Now bo->size is the original size of the BO in arbitrary
units, usually bytes.
bo->mem.nu
On 12/7/20 2:19 PM, Christian König wrote:
Am 07.12.20 um 20:09 schrieb Andrey Grodzovsky:
On 12/7/20 1:04 PM, Christian König wrote:
Am 07.12.20 um 17:00 schrieb Andrey Grodzovsky:
On 12/7/20 6:13 AM, Christian König wrote:
Am 04.12.20 um 16:10 schrieb Andrey Grodzovsky:
On 12/4/20 3:13
On 07/12/2020 17:31, Ville Syrjälä wrote:
> On Sat, Dec 05, 2020 at 12:35:25AM +0200, Laurent Pinchart wrote:
>> Hi Tomi,
>>
>> Thank you for the patch.
>>
>> On Thu, Dec 03, 2020 at 01:48:44PM +0200, Tomi Valkeinen wrote:
>>> We currently have drm_atomic_helper_legacy_gamma_set() helper which can
On 2020-12-04 3:16 a.m., Christian König wrote:
> Am 04.12.20 um 04:17 schrieb Luben Tuikov:
>> The drm_sched_job_done() callback now moves done
>> jobs from the pending list to a "done" list.
>>
>> In drm_sched_job_timeout, make use of the status
>> returned by a GPU driver job timeout handler to
On Mon, 2020-12-07 at 15:28 -0400, Jason Gunthorpe wrote:
> On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote:
> > Just as a side note. I was looking at tpm_tis_probe_irq_single()
> > and that function is leaking the interrupt request if any of the
> > checks afterwards fails, except
https://bugzilla.kernel.org/show_bug.cgi?id=210467
--- Comment #9 from Alexey (intervio...@gmail.com) ---
Created attachment 294027
--> https://bugzilla.kernel.org/attachment.cgi?id=294027&action=edit
modinfo amdgpu (workly)
(In reply to Alex Deucher from comment #8)
> Can you narrow down which
https://bugzilla.kernel.org/show_bug.cgi?id=210467
--- Comment #10 from Alexey (intervio...@gmail.com) ---
Created attachment 294029
--> https://bugzilla.kernel.org/attachment.cgi?id=294029&action=edit
modules info (workly)
--
You are receiving this mail because:
You are watching the assignee
On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on
> arm64, merging it into DRM_AMD_DC means that the top-level symbol
> is now x86-only as well.
>
> Compilation fails on arm64 with clang-12 with
>
> dri
Am 07.12.20 um 21:47 schrieb Alex Deucher:
On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann wrote:
From: Arnd Bergmann
As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on
arm64, merging it into DRM_AMD_DC means that the top-level symbol
is now x86-only as well.
Compilation fails on
On Wed, 18 Nov 2020 16:21:18 +0800, Chunfeng Yun wrote:
> Convert phy-mtk-xsphy.txt to YAML schema mediatek,xsphy.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v3:
> 1. remove type for property with standard unit suffix suggested by Rob
> 2. remove '|' for descritpion
> 3. fix yamllint warni
On Wed, 18 Nov 2020 16:21:19 +0800, Chunfeng Yun wrote:
> Convert phy-mtk-tphy.txt to YAML schema mediatek,tphy.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v3:
> 1. fix dt_binding_check error in example after add mtu3.yaml
> Changes suggested by Rob:
> 2. fix wrong indentation
> 3. remov
On Wed, Nov 18, 2020 at 04:21:22PM +0800, Chunfeng Yun wrote:
> Convert MIPI DSI PHY binding to YAML schema mediatek,dsi-phy.yaml
>
> Cc: Chun-Kuang Hu
> Signed-off-by: Chunfeng Yun
> ---
> v3: new patch
> ---
> .../display/mediatek/mediatek,dsi.txt | 18 +---
> .../bindings/phy/mediate
On Wed, Nov 18, 2020 at 04:21:24PM +0800, Chunfeng Yun wrote:
> Convert mediatek,mtk-xhci.txt to YAML schema mediatek,mtk-xhci.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v3:
> 1. fix yamllint warning
> 2. remove pinctrl* properties supported by default suggested by Rob
> 3. drop unused la
On Wed, Nov 18, 2020 at 04:21:25PM +0800, Chunfeng Yun wrote:
> Convert mediatek,mtu3.txt to YAML schema mediatek,mtu3.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v3:
> 1. fix yamllint warning
> 2. remove pinctrl* properties
> 3. remove unnecessary '|'
> 4. drop unused labels in example
Hi Tian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.10-rc7 next-20201207]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as doc
On Wed, Nov 18, 2020 at 09:29:52AM +0100, Guido Günther wrote:
> Add prefix for Shenzhen Yashi Changhua Intelligent Technology Co., Ltd.
>
> Signed-off-by: Guido Günther
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herrin
On Wed, 18 Nov 2020 09:29:53 +0100, Guido Günther wrote:
> This panel from Shenzhen Yashi Changhua Intelligent Technology Co
> uses the same driver IC but a different LCD.
>
> Signed-off-by: Guido Günther
> Reviewed-by: Linus Walleij
> ---
> .../devicetree/bindings/display/panel/mantix,mlaf057w
Hi Dave,
This time around:
* Shutdown hook for GPU (to ensure GPU is idle before iommu goes away)
* GPU cooling device support
* DSI 7nm and 10nm phy/pll updates
* Additional sm8150/sm8250 DPU support (merge_3d and DSPP color
processing)
* Various DP fixes
* A whole bunch of W=1 fixes fr
On 2020-12-04 3:13 a.m., Christian König wrote:
> Thinking more about that I came to the conclusion that the whole
> approach here isn't correct.
>
> See even when the job has been completed or canceled we still want to
> restart the timer.
>
> The reason for this is that the timer is then not
>-Original Message-
>From: dri-devel On Behalf Of
>Daniel Vetter
>Sent: Friday, December 4, 2020 3:03 PM
>To: DRI Development
>Cc: Daniel Vetter ; Vetter, Daniel
>
>Subject: [PATCH] dma-buf: Fix kerneldoc formatting
>
>I wanted to look up something and noticed the hyperlink doesn't work.
On Mon, Dec 7, 2020 at 9:50 PM Christian König wrote:
> Am 07.12.20 um 21:47 schrieb Alex Deucher:
> > On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann wrote:
> >> From: Arnd Bergmann
> >>
> >> As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on
> >> arm64, merging it into DRM_AMD_DC me
Implement the new driver method 'reg_user_mr_dmabuf'. Utilize the core
functions to import dma-buf based memory region and update the mappings.
Add code to handle dma-buf related page fault.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koe
Dma-buf is a standard cross-driver buffer sharing mechanism that can be
used to support peer-to-peer access from RDMA devices.
Device memory exported via dma-buf is associated with a file descriptor.
This is passed to the user space as a property associated with the
buffer allocation. When the buf
Dma-buf based memory region requires one extra parameter and is processed
quite differently. Adding a separate method allows clean separation from
regular memory regions.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel
This is the thirteenth version of the patch set. Changelog:
v13:
* Rebase to the latest linux-rdma 'for-next' branch (5.10.0-rc6+)
* Check for device on-demand paging capability at the entry point of
the new verbs command to avoid calling device's reg_user_mr_dmabuf()
method when CONFIG_INFINI
Implement a new uverbs ioctl method for memory registration with file
descriptor as an extra parameter.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/core/uverbs_std_types_mr.c | 117 ++
On Mon, Dec 7, 2020 at 11:08 PM 'Nick Desaulniers' via Clang Built
Linux wrote:
>
> On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann wrote:
> >
> > Right, looking at my latest randconfig logs, I see the same problem on x86
> > builds with clang as well, though I'm not entirely sure which other
> > c
On Mon, 23 Nov 2020 11:46:52 +0800, Hsin-Yi Wang wrote:
> anx7625 requires 3 power supply regulators.
>
> Signed-off-by: Hsin-Yi Wang
> ---
> Change:
> v2: remove maxItems for supplies
> ---
> .../bindings/display/bridge/analogix,anx7625.yaml | 15 +++
> 1 file changed, 15 insertions
On Mon, 07 Dec 2020 12:48:30 +0800, Zhen Lei wrote:
> Eliminate the following yamllint warnings:
> ./Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> :52:9: [warning] wrong indentation: expected 6 but found 8 (indentation)
>
> ./Documentation/devicetree/bindings/display/bri
https://bugzilla.kernel.org/show_bug.cgi?id=210543
Bug ID: 210543
Summary: amdgpu Kernel
panic：__ttm_dma_free_page.isra.0+0xac/0xe8 [ttm]
Product: Drivers
Version: 2.5
Kernel Version: 4.19
Hardware: ARM
Geert,
On Mon, Dec 07, 2020 at 09:15:11AM +0100, Geert Uytterhoeven wrote:
> On Fri, Dec 4, 2020 at 11:02 PM Laurent Pinchart wrote:
> > On D3 and E3 platforms, the LVDS encoder includes a PLL that can
> > generate a clock for the corresponding CRTC, used even when the CRTC
> > output to a non-LVD
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/vga/vga_switcheroo.c
between commit:
99efde6c9bb7 ("PCI/PM: Rename pci_wakeup_bus() to pci_resume_bus()")
from the pci tree and commit:
9572e6693cd7 ("vga_switcheroo: simplify the return expression of
vga_s
Hi Bjorn,
On Mon, Dec 07, 2020 at 10:44:46PM -0600, Bjorn Andersson wrote:
> Some bridge chips, such as the TI SN65DSI86 DSI/eDP bridge, provides
> means of generating a PWM signal for backlight control of the attached
> panel. The provided PWM chip is typically controlled by the
> pwm-backlight dr
On Mon, Dec 07, 2020 at 02:15:50PM -0800, Jianxin Xiong wrote:
> Dma-buf is a standard cross-driver buffer sharing mechanism that can be
> used to support peer-to-peer access from RDMA devices.
>
> Device memory exported via dma-buf is associated with a file descriptor.
> This is passed to the user
On Mon, Dec 07, 2020 at 02:15:52PM -0800, Jianxin Xiong wrote:
> Implement a new uverbs ioctl method for memory registration with file
> descriptor as an extra parameter.
>
> Signed-off-by: Jianxin Xiong
> Reviewed-by: Sean Hefty
> Acked-by: Michael J. Ruhl
> Acked-by: Christian Koenig
> Acked-
> -Original Message-
> From: Leon Romanovsky
> Sent: Monday, December 07, 2020 11:06 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Jason Gunthorpe ;
> Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
> Subject: Re: [PATCH
On Mon, Dec 07, 2020 at 02:15:51PM -0800, Jianxin Xiong wrote:
> Dma-buf based memory region requires one extra parameter and is processed
> quite differently. Adding a separate method allows clean separation from
> regular memory regions.
>
> Signed-off-by: Jianxin Xiong
> Reviewed-by: Sean Hefty
Am 07.12.20 um 16:57 schrieb Maxime Ripard:
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++---
Am 07.12.20 um 16:57 schrieb Maxime Ripard:
Reported-by: Thomas Zimmermann
Fixes: 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within limits")
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 +++
1 file changed, 3 insertions
Am 07.12.20 um 16:57 schrieb Maxime Ripard:
The pixel rate is for now quite simple to compute, but with more features
(30 and 36 bits output, YUV output, etc.) will depend on a bunch of
connectors properties.
Let's store the rate we have to run the pixel clock at in our custom
connector state,
This patch series attempts to add support for a DP-HDMI2.1 Protocol
Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata
E5 to DisplayPort_v2.0:
https://vesa.org/join-vesamemberships/member-downloads/?action=stamp&fileid=42299
The details are mentioned in:
VESA DP-to-HDMI PCON Speci
From: Swati Sharma
The HDMI2.1 extends HFVSDB (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.
This patch adds the new HFVSDB fields
From: Swati Sharma
This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.
v2: Fixed minor bugs, and removed extra wrapper function (Uma Shan
This patch parses HFVSDB fields for DSC1.2 capabilities of an
HDMI2.1 sink. These fields are required by a source to understand the
DSC capability of the sink, to set appropriate PPS parameters,
before transmitting compressed data stream.
v2: Addressed following issues as suggested by Uma Shankar:
This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.
v2: Fixed typos and addressed other review comments from Uma Shankar.
-changed the commit message for better clarity (Uma Shankar)
-removed unnecessary argume
From: Swati Sharma
There are specific DPCDs defined for detecting link failures between
the PCON and HDMI sink and check the link status. In case of link
failure, PCON will communicate the same using an IRQ_HPD to source.
HDMI sink would have indicated the same to PCON using SCDC interrupt
mechan
This patch adds registers for getting DSC encoder capability for
a HDMI2.1 PCon. It also addes helper functions to configure
DSC between the PCON and HDMI2.1 sink.
v2: Corrected offset for DSC encoder bpc and minor changes.
Also added helper functions for getting pcon dsc encoder capabilities
as s
DP Specification for DP2.0 to HDMI2.1 Pcon specifies support for conversion
of colorspace from RGB to YCbCr.
https://groups.vesa.org/wg/DP/document/previewpdf/15651
This patch adds the relavant registers and helper functions to
get the capability and set the color conversion bits for rgb->ycbcr
co
HDMI2.1 PCON advertises Max FRL bandwidth supported by the PCON and
by the sink.
This patch captures these in dfp cap structure in intel_dp and uses
these to prune connector modes that cannot be supported by the PCON
and sink FRL bandwidth.
v2: Addressed review comments from Uma Shankar:
-tweaked
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
v2: As suggested by Uma Shankar:
-renamed couple of variables for better clar
From: Swati Sharma
In this patch enables support for detecting link failures between
PCON and HDMI sink in i915 driver. HDMI link loss indication to
upstream DP source is indicated via IRQ_HPD. This is followed by
reading of HDMI link configuration status (HDMI_TX_LINK_ACTIVE_STATUS).
If the PCON
This patch calls functions to check FRL training requirements
for an HDMI2.1 sink, when connected through PCON.
The call is made before the DP link training. In case FRL is not
required or failure during FRL training, the TMDS mode is selected
for the pcon.
v2: moved check_frl_training() just afte
This patch adds support to read and store the DSC capabilities of the
HDMI2.1 PCon encoder. It also adds a new field to store these caps,
The caps are read during dfp update and can later be used to get the
PPS parameters for PCON-HDMI2.1 sink pair. Which inturn will be used
to take a call to overr
Am 07.12.20 um 02:04 schrieb Tian Tao:
switch to using devm_add_action_or_reset() instead of devm_add_action.
Signed-off-by: Tian Tao
I'm surprised that devm_drm_dev_init() didn't already use
devm_add_action_or_reset(). But it doesn't look special, so
Acked-by: Thomas Zimmermann
---
The DP-HDMI2.1 PCON spec provides way for a source to set PPS
parameters: slice height, slice width and bits_per_pixel, based on
the HDMI2.1 sink capabilities. The DSC encoder of the PCON will
respect these parameters, while preparing the 128 byte PPS.
This patch adds helper functions to calculate
When a source supporting DSC1.1 is connected to DSC1.2 HDMI2.1 sink
via DP HDMI2.1 PCON, the PCON can be configured to decode the
DSC1.1 compressed stream and encode to DSC1.2. It then sends the
DSC1.2 compressed stream to the HDMI2.1 sink.
This patch configures the PCON for DSC1.1 to DSC1.2 encod
If PCON has capability to convert RGB->YUV colorspace and also
to 444->420 downsampling then for any YUV420 only mode, we can
let the PCON do all the conversion.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c
This patch enables PCON configuration for color space conversion for
TGL+ platfrom. This will help in supporting 8k@60 YUV420 modes common
in HDMI 8k panels, through a capable PCON.
Also allow 8k@60 YUV420 modes, only if PCON claims to support the
color space conversion.
Signed-off-by: Ankit Nauti
ping for a review of the i915 patches
Am 01.12.20 um 11:35 schrieb Thomas Zimmermann:
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
v2:
* move gt/ and gvt/ changes into separate patches
Signed-off-by: Thomas Zimmermann
Cc: Ja
101 - 171 of 171 matches
Mail list logo
