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
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
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
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
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
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
---
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
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
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 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
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
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
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
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 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
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:
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
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
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
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,
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:
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 ++---
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
> -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: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-
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
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
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
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
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
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
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, 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
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 ++
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
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
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
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
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
>-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 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
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 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
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
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 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
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: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, 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, 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
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 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
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
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
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
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 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 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
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 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
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.
___
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
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 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
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.
_
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
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
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
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 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
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, 07 Dec 2020 11:20:55 +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qxp/qm Display Processing Unit.
>
> 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. Otherwise, i
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 pages in the
resource domain of bo->mem.mem_type.
Signed-off-by: Chr
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 the job has been completed or canceled we still w
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
> > be used to handle legacy gamma-set ioctl.
>
From: Colin Ian King
Currently there is a null pointer check for hdmi_phy that implies it
may be null, however a dev_err messages dereferences this potential null
pointer. Avoid a null pointer dereference by only emitting the dev_err
message if hdmi_phy is non-null. It is a moot point if the er
Am 07.12.20 um 14:39 schrieb Maxime Ripard:
The PHY initialisation parameters are not based on the pixel clock but
the TMDS clock rate which can be the pixel clock in the standard case,
but could be adjusted based on some parameters like the bits per color.
Since the TMDS clock rate is stored
Am 07.12.20 um 14:39 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
This becomes relevant in patch 5, I guess? If so
Acked-by: Thomas Zimmermann
---
Hi
Am 07.12.20 um 14:39 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 stat
Am 07.12.20 um 14:39 schrieb Maxime Ripard:
When run with a higher bpc than 8, the clock of the HDMI controller needs
to be adjusted. Let's create a connector state that will be used at
atomic_check and atomic_enable to compute and store the clock rate
associated to the state.
Signed-off-by: M
Am 07.12.20 um 14:39 schrieb Maxime Ripard:
drm_atomic_helper_connector_reset uses kmalloc which, from an API
standpoint, can fail, and thus setting connector->state to NULL.
However, our reset hook then calls drm_atomic_helper_connector_tv_reset
that will access connector->state without checki
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
Coverity reported:
Useless call (USELESS_CALL) side_effect_free: Calling
SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex) is only useful for its
return value, which is ignored.
And this is correct - so drop the call.
Signed-off-by: Sam Ra
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
The controlfb driver has a number of dummy defines for IO operations.
They were introduced in commit a07a63b0e24d
("video: fbdev: controlfb: add COMPILE_TEST support").
The write variants did not use their value parameter in the
dummy versions, result
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
screen_pitch was asssigned a value which was never used.
Drop it to fix the warning
Signed-off-by: Sam Ravnborg
Cc: Peter Jones
Cc: linux-fb...@vger.kernel.org
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/efifb.c | 3 +--
1 file chang
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
The variable "x" was set but never used.
Drop the redundant assignments.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/gbefb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff
Hi,
On 05/12/2020 20:15, Sam Ravnborg wrote:
> Hi Neil,
>
>> +
>> +static int khadas_ts050_panel_probe(struct mipi_dsi_device *dsi)
>> +{
>> +struct khadas_ts050_panel *khadas_ts050;
>> +int err;
>> +
>> +dsi->lanes = 4;
>> +dsi->format = MIPI_DSI_FMT_RGB888;
>> +dsi->mode_fla
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
The goldfish_fb_acpi_match table is only used with ACPI enabled.
Ifdef it out unless it is needed.
This is a similar fix to what other acpi drivers do.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Acked-by: Thomas Zimmermann
---
drivers/video
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
Include own header to fix "function not declared" warnings.
Signed-off-by: Sam Ravnborg
Cc: Tony Prisk
Cc: linux-arm-ker...@lists.infradead.org
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/wmt_ge_rops.c | 1 +
1 file changed, 1 insert
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
Add missing parameter and drop parameter that is not present
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Bartlomiej Zolnierkiewicz
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/mmp/hw/mmp_spi.c | 2 +-
1 file c
On Fri, Dec 04, 2020 at 02:12:21PM +0100, Enrico Weigelt, metux IT consult
wrote:
VIRTIO itself has no dependencies and therefore can easily be just
select'ed, instead of depending on it. The current depends on causes
any others trying to select VIRTIO to fail like this:
drivers/gpu/drm/Kconf
On Fri, 27 Nov 2020, Matthew Auld wrote:
> From: CQ Tang
>
> Add "REGION_STOLEN" device info to dg1, create stolen memory
> region from upper portion of local device memory, starting
> from DSMBASE.
>
> The memory region is marked with "is_devmem=true".
>
> Cc: Joonas Lahtinen
> Cc: Matthew Auld
On Mon, 07 Dec 2020 10:53:49 +
Simon Ser wrote:
> On Monday, December 7th, 2020 at 11:49 AM, James Park
> wrote:
>
> > That would work, but that's kind of an annoying requirement. I would
> > prefer the header to be self-sufficient.
>
> I don't want to make it more confusing than before
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 the job has been completed or canceled we still want to
restart the timer.
The reason for t
On Monday, December 7th, 2020 at 11:49 AM, James Park
wrote:
> That would work, but that's kind of an annoying requirement. I would
> prefer the header to be self-sufficient.
I don't want to make it more confusing than before, but here Pekka (I
think) suggests to replace this:
diff --git a/inc
On Monday, December 7th, 2020 at 11:44 AM, Pekka Paalanen
wrote:
> But then, the code in the header should be literally
>
> #ifndef DRM_FOURCC_STANDALONE
> #include "drm.h"
> #endif
>
> without an #else branch.
As long as there is a #include "drm_basic_types.h" right before
(drm_fourcc.h needs
On Mon, 7 Dec 2020 12:35:14 +0200
Pekka Paalanen wrote:
> On Mon, 7 Dec 2020 01:08:58 -0800
> James Park wrote:
>
> > I'm not completely sure what you're saying, but doesn't drm_base_types.h
> > (now drm_basic_types.h) make things robust to header order? The patch is in
> > another email. You c
Some GPUs support different max frequencies depending on the platform.
To identify the correct variant, we should check the gpu speedbin
fuse value. Add support for this speedbin detection to a6xx family
along with the required fuse details for a618 gpu.
Signed-off-by: Akhil P Oommen
---
Changes
Add support for gpu fuse to help identify the supported opps.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 6678
On Mon, 7 Dec 2020 01:08:58 -0800
James Park wrote:
> I'm not completely sure what you're saying, but doesn't drm_base_types.h
> (now drm_basic_types.h) make things robust to header order? The patch is in
> another email. You can also see it here:
> https://github.com/jpark37/linux/commit/0cc8ae7
On Monday, December 7th, 2020 at 11:05 AM, James Park
wrote:
> The original code blocks in drm.h look identical to me. I see:
>
> #include
> #include
> typedef unsigned int drm_handle_t;
Hmm. Actually you're completely right, it turns out it's necessary to
duplicate the branches like this to
1 - 100 of 171 matches
Mail list logo
