Hi Liu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on shawnguo/for-next]
[also build test WARNING on robh/for-next soc/for-next clk/clk-next
linus/master v5.10-rc6 next-20201201]
[cannot apply to xlnx/master]
[If your patch is applied to the wrong git tree,
Hi
Am 03.12.20 um 04:09 schrieb Tian Tao:
updated to use drmm_vram_helper_init()
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
As a good follow-up patch, I would suggest to get rig of the entire file
hibmc_ttm.c. drmm_vram_helper_init() can be called directly from
hibmc_load().
Unfortunately this isn't a crash, but rather a warning that things are
timing out. By the time you get this, the display is most likely hung.
Was there anything before this, e.g. an error state dump perhaps?
What GPU are you using, what displays, and how are they connected?
What kind of
https://bugzilla.kernel.org/show_bug.cgi?id=201139
Michal Turecki (ture...@gmail.com) changed:
What|Removed |Added
CC||ture...@gmail.com
cc'ing Ben + nouveau
On Thu, 3 Dec 2020 at 14:59, bob wrote:
>
> Hello. I have a crash dump for:
>
> $ uname -a
> Linux freedom 5.10.0-rc6 #1 SMP Sun Nov 29 17:26:13 MST 2020 x86_64
> x86_64 x86_64 GNU/Linux
>
> Occasionally when this dumps it likes to lock up the computer, but I
> caught it
On Wed, Dec 2, 2020 at 3:45 AM Christian König wrote:
>
> Am 02.12.20 um 09:27 schrieb Mauro Carvalho Chehab:
> > The function name at kernel-doc markup doesn't match the name
> > of the function:
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1534: warning: expecting
> > prototype for
Hi Dave, Daniel,
Fixes for 5.10.
The following changes since commit b65054597872ce3aefbc6a666385eabdf9e288da:
Linux 5.10-rc6 (2020-11-29 15:50:50 -0800)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.10-2020-12-02
for you to fetch
> On Dec 2, 2020, at 11:03, Daniel Vetter wrote:
>
> On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin wrote:
>>
>>
>>
>>> On Dec 2, 2020, at 09:27, Thomas Zimmermann wrote:
>>>
>>> Hi
>>>
>>> Am 02.12.20 um 09:01 schrieb Thomas Zimmermann:
Hi
Am 30.11.20 um 21:59 schrieb Zack Rusin:
Thanks Dan.
> -Original Message-
> From: Dan Carpenter
> Sent: Sunday, November 29, 2020 11:48 PM
> To: Chrisanthus, Anitha
> Cc: Dea, Edmund J ; David Airlie ;
> Daniel Vetter ; Sam Ravnborg ; dri-
> de...@lists.freedesktop.org; kernel-janit...@vger.kernel.org
> Subject: Re: [PATCH v2]
On Wed, Dec 02, 2020 at 04:36:24PM -0800, Rodrigo Vivi wrote:
> Hi Dave and Daniel,
>
> Fixes for GPU hang, null dereference, suspend-resume, power consumption, and
> use-after-free.
>
> The commit 6db58901c2aa ("drm/i915/display: return earlier from
> intel_modeset_init() without display")
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #70 from mirh (m...@protonmail.ch) ---
So.. I was also testing this on my Sapphire R9 290 Tri-X OC. And it seems to
work pretty good.
I noticed an oddity though. The first time I tried it, when I switched to
manual fan control,
Hi Dave and Daniel,
Fixes for GPU hang, null dereference, suspend-resume, power consumption, and
use-after-free.
The commit 6db58901c2aa ("drm/i915/display: return earlier from
intel_modeset_init() without display") was not actually a crucial fix, but it
allowed a clean pick of the
nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code
back to the caller. On failures, ttm_bo_init() invokes the provided
destructor which should de-initialize and free the memory.
Thus, when nouveau_bo_init() returns an error the gem object has already
been released and the
rx_callback is a standard mailbox callback mechanism and could
cover the function of proprietary cmdq_task_cb, so it is better
to use the standard one instead of the proprietary one. But
register rx_callback should before mbox_request_channel(),
so remove cmdq_pkt_flush() and let client driver
On Wed, Dec 2, 2020 at 8:48 PM James Park wrote:
>
> I can avoid modifying drm.h by doing this to drm_fourcc.h:
>
> #ifdef _WIN32
> #include
> typedef uint64_t __u64;
> #else
> #include "drm.h"
> #endif
>
> And this to amdgpu_drm.h:
>
> #ifdef _WIN32
> #include
> typedef int32_t __s32;
>
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #69 from fawz (f...@negentropy.io) ---
Well, I'll have a read! And thanks anyways, I'll run this going forward, post
if there are issues and am looking forward to seeing this in mainline at some
point :)
--
You are receiving this
Define a new sub-class of 'MR' that uses dma-buf object for the memory
region. Define a new class 'DmaBuf' as a wrapper for dma-buf allocation
mechanism implemented in C.
Update the cmake function for cython modules to allow building modules
with mixed cython and c source files.
Signed-off-by:
To commit 2eef437c4669 ("RDMA/uverbs: Add uverbs command for dma-buf based
MR registration").
Signed-off-by: Jianxin Xiong
---
kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 ++
kernel-headers/rdma/ib_user_verbs.h | 14 --
2 files changed, 14 insertions(+), 14
Define a set of unit tests similar to regular MR tests and a set of
tests for send/recv and rdma traffic using dma-buf MRs. Add a utility
function to generate access flags for dma-buf based MRs because the
set of supported flags is smaller.
Signed-off-by: Jianxin Xiong
---
tests/args_parser.py
The filter definition is wrong and causes get_access_flags() always
returning empty list. As the result the MR tests using this function
are effectively skipped (but report success).
Signed-off-by: Jianxin Xiong
---
tests/utils.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Implement the new provider method for registering dma-buf based memory
regions.
Signed-off-by: Jianxin Xiong
---
providers/mlx5/mlx5.c | 2 ++
providers/mlx5/mlx5.h | 3 +++
providers/mlx5/verbs.c | 22 ++
3 files changed, 27 insertions(+)
diff --git
This is the fourth version of the patch series. Change log:
v4:
* Rework the cmake funciton rdma_cython_module to support both single
source (.pyx) and multiple source (.pyx + [.c]*) scenarios instead
of using two separate functions
* Rename 'dri_*' to 'drm_*' for the dmabuf allocation
Add new API function and new provider method for registering dma-buf
based memory region. Update the man page and bump the API version.
Signed-off-by: Jianxin Xiong
---
debian/libibverbs1.symbols | 2 ++
libibverbs/CMakeLists.txt| 2 +-
libibverbs/cmd_mr.c | 38
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #68 from Alex Deucher (alexdeuc...@gmail.com) ---
It's pretty similar to other the code for other smu7 chips (tonga, polaris,
etc.). Note that this change is not relevant to newer smu7 chips (rx480,
tonga, etc.).
--
You are
/git/tmlind/linux-omap.git
for-next
config: riscv-randconfig-r016-20201202 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
2671fccf0381769276ca8246ec0499adcb9b0355)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #67 from fawz (f...@negentropy.io) ---
> I guess we need to fan control parameters. How about this patch?
After some quick testing, your latest patch seems to work great! And new code,
ie. something not just taken from the other
On 12/2/20 1:20 PM, Greg KH wrote:
On Wed, Dec 02, 2020 at 01:02:06PM -0500, Andrey Grodzovsky wrote:
On 12/2/20 12:34 PM, Greg KH wrote:
On Wed, Dec 02, 2020 at 10:48:01AM -0500, Andrey Grodzovsky wrote:
On 11/11/20 10:34 AM, Greg KH wrote:
On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey
On Wed, Dec 02, 2020 at 01:02:06PM -0500, Andrey Grodzovsky wrote:
>
> On 12/2/20 12:34 PM, Greg KH wrote:
> > On Wed, Dec 02, 2020 at 10:48:01AM -0500, Andrey Grodzovsky wrote:
> > > On 11/11/20 10:34 AM, Greg KH wrote:
> > > > On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:
>
On 2020-12-02 1:46 p.m., Daniel Vetter wrote:
On Wed, Dec 2, 2020 at 12:43 PM Michel Dänzer wrote:
On 2020-12-01 11:01 a.m., James Park wrote:
This will allow Mesa to port code to Windows more easily.
As discussed in
On 12/2/20 12:34 PM, Greg KH wrote:
On Wed, Dec 02, 2020 at 10:48:01AM -0500, Andrey Grodzovsky wrote:
On 11/11/20 10:34 AM, Greg KH wrote:
On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:
On 11/10/20 12:59 PM, Greg KH wrote:
On Tue, Nov 10, 2020 at 12:54:21PM -0500,
On Wed, Dec 2, 2020 at 8:55 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 01.12.20 um 12:20 schrieb Mikulas Patocka:
> >
> >
> > On Tue, 1 Dec 2020, Thomas Zimmermann wrote:
> >
> >> Hi
> >>
> >> Am 30.11.20 um 19:39 schrieb Mikulas Patocka:
> >>>
> >>>
> >>> On Mon, 30 Nov 2020, Daniel Vetter wrote:
On Wed, Dec 02, 2020 at 10:48:01AM -0500, Andrey Grodzovsky wrote:
>
> On 11/11/20 10:34 AM, Greg KH wrote:
> > On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:
> > > On 11/10/20 12:59 PM, Greg KH wrote:
> > > > On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:
-a016-20201202 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
2671fccf0381769276ca8246ec0499adcb9b0355)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod
On Wed, Dec 02, 2020 at 08:53:51PM +0530, Akhil P Oommen wrote:
> On 11/30/2020 10:32 PM, Jordan Crouse wrote:
> >On Fri, Nov 27, 2020 at 06:19:44PM +0530, Akhil P Oommen wrote:
> >>So far a530v2 gpu has support for detecting its supported opps
> >>based on a fuse value called speed-bin. This
https://bugzilla.kernel.org/show_bug.cgi?id=201539
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
Attachment #293903|0 |1
is
/20201201-071109
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
09162bc32c880a791c6c0668ce0745cf7958f576
config: riscv-randconfig-r024-20201202 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin wrote:
>
>
>
> > On Dec 2, 2020, at 09:27, Thomas Zimmermann wrote:
> >
> > Hi
> >
> > Am 02.12.20 um 09:01 schrieb Thomas Zimmermann:
> >> Hi
> >> Am 30.11.20 um 21:59 schrieb Zack Rusin:
> >>>
> >>>
> On Nov 24, 2020, at 06:38, Thomas Zimmermann
Hi,
On Tue 03 Nov 20, 10:46, Maxime Ripard wrote:
> On Mon, Nov 02, 2020 at 04:53:07PM +0100, Paul Kocialkowski wrote:
> > Introduces a driver for the LogiCVC display controller, a programmable
> > logic controller optimized for use in Xilinx Zynq-7000 SoCs and other
> > Xilinx FPGAs. The
On 30/11/2020 16:10, Daniel Vetter wrote:
> The thing is, the legacy helpers should be able to pull off what userspace
> needs to do when it's using atomic anyway. Hard-coding information in the
> kernel means we have a gap here. Hence imo legacy helpers doing the right
> thing in all reasonable
On 11/11/20 10:34 AM, Greg KH wrote:
On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:
On 11/10/20 12:59 PM, Greg KH wrote:
On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:
Hi, back to this after a long context switch for some higher priority stuff.
So
Hi Sam,
On Wed 04 Nov 20, 22:22, Sam Ravnborg wrote:
> Hi Paul.
>
> A few comments in the following. I did not find time to read all of the
> driver.
Thanks for taking a look at the driver!
>
> Sam
>
> On Mon, Nov 02, 2020 at 04:53:07PM +0100, Paul Kocialkowski wrote:
> > Introduces a
> On Dec 2, 2020, at 09:27, Thomas Zimmermann wrote:
>
> Hi
>
> Am 02.12.20 um 09:01 schrieb Thomas Zimmermann:
>> Hi
>> Am 30.11.20 um 21:59 schrieb Zack Rusin:
>>>
>>>
On Nov 24, 2020, at 06:38, Thomas Zimmermann wrote:
Using struct drm_device.pdev is deprecated. Convert
<< Resending since Jordan wasn't in the CC list >>
On 11/30/2020 10:32 PM, Jordan Crouse wrote:
On Fri, Nov 27, 2020 at 06:19:44PM +0530, Akhil P Oommen wrote:
So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support
On 11/30/2020 10:32 PM, Jordan Crouse wrote:
On Fri, Nov 27, 2020 at 06:19:44PM +0530, Akhil P Oommen wrote:
So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support generic across gpu families. This is in preparation
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
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
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
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
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
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
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:
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
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
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
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
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
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=42299
The details are mentioned in DP to HDMI2.1 PCON Enum/Config
Hi
Am 02.12.20 um 15:02 schrieb Alex Deucher:
On Wed, Dec 2, 2020 at 3:53 AM Thomas Zimmermann wrote:
Hi
Am 02.12.20 um 09:43 schrieb Christian König:
Am 02.12.20 um 08:59 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 11:40 schrieb Christian König:
Reviewed-by: Christian König on patch
Hi
Am 02.12.20 um 09:01 schrieb Thomas Zimmermann:
Hi
Am 30.11.20 um 21:59 schrieb Zack Rusin:
On Nov 24, 2020, at 06:38, Thomas Zimmermann
wrote:
Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas
Thanks Uma for the comments.
Please find my responses inline:
On 11/26/2020 2:15 AM, Shankar, Uma wrote:
-Original Message-
From: Nautiyal, Ankit K
Sent: Sunday, November 1, 2020 3:37 PM
To: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
Hi Uma,
Thanks for the comments and spotting the errors. I agree to most of the
comments and will address them in the next version.
Please find my responses inline:
On 11/26/2020 1:58 AM, Shankar, Uma wrote:
-Original Message-
From: Nautiyal, Ankit K
Sent: Sunday, November 1,
On Wed, Dec 2, 2020 at 3:53 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 02.12.20 um 09:43 schrieb Christian König:
> > Am 02.12.20 um 08:59 schrieb Thomas Zimmermann:
> >> Hi
> >>
> >> Am 01.12.20 um 11:40 schrieb Christian König:
> >>> Reviewed-by: Christian König on patch #1
> >>> and #15.
> >>>
On Wed, Dec 2, 2020 at 12:43 PM Michel Dänzer wrote:
>
> On 2020-12-01 11:01 a.m., James Park wrote:
> > This will allow Mesa to port code to Windows more easily.
>
> As discussed in
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162#note_712779
> , including drm.h makes no sense
On Wed, Dec 2, 2020 at 12:52 PM Tomi Valkeinen wrote:
>
> On 30/11/2020 16:10, Daniel Vetter wrote:
>
> > The thing is, the legacy helpers should be able to pull off what userspace
> > needs to do when it's using atomic anyway. Hard-coding information in the
> > kernel means we have a gap here.
Hi Peiyong,
On Mon, Nov 30, 2020 at 02:33:59PM -0800, Peiyong Lin wrote:
> On Tue, Nov 17, 2020 at 1:31 PM Peiyong Lin wrote:
> >
> > On Thu, Oct 22, 2020 at 10:34 AM Peiyong Lin wrote:
> > >
> > > Historically there is no common trace event for GPU frequency, in
> > > downstream Android each
On Wed, 02 Dec 2020 13:14:06 +0100,
Michael Ellerman wrote:
>
> Uwe Kleine-König writes:
> > Hello Michael,
> >
> > On Sat, Nov 28, 2020 at 09:48:30AM +0100, Takashi Iwai wrote:
> >> On Thu, 26 Nov 2020 17:59:50 +0100,
> >> Uwe Kleine-König wrote:
> >> >
> >> > The driver core ignores the
On 2020-12-01 11:01 a.m., James Park wrote:
This will allow Mesa to port code to Windows more easily.
As discussed in
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162#note_712779
, including drm.h makes no sense when building for Windows.
--
Earthling Michel Dänzer
On Mon, Nov 30, 2020 at 06:16:21PM -0800, Gurchetan Singh wrote:
> virtio_gpu typically uses the prefix virtio_gpu, but there are
> a few places where the virtio prefix is used. Modify this for
> consistency.
>
> v3: add r-b tags
>
> Signed-off-by: Gurchetan Singh
> Reviewed-by: Anthoine
Am 02.12.20 um 10:26 schrieb Tian Tao:
Add new api devm_drm_irq_install() to register interrupts,
no need to call drm_irq_uninstall() when the drm module is removed.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_irq.c | 32
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #65 from fawz (f...@negentropy.io) ---
Unfortunately, your patch leads to a stuck boot. There's some minor
"corruption" visible on the bottom of the screen while still booting up,
and then it gets stuck.
I don't think I mentioned
Am 02.12.20 um 09:47 schrieb Tian Tao:
Use the devm_drm_dev_alloc provided by the drm framework to alloc
a structure hibmc_drm_private.
Signed-off-by: Tian Tao
This looks good now. Thanks for sticking to it.
Acked-by: Thomas Zimmermann
---
Hi
Am 02.12.20 um 09:47 schrieb Tian Tao:
Add new api devm_drm_irq_install() to register interrupts,
no need to call drm_irq_uninstall() when the drm module is removed.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/drm_irq.c | 35 +++
include/drm/drm_irq.h
Hi
Am 02.12.20 um 09:43 schrieb Christian König:
Am 02.12.20 um 08:59 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 11:40 schrieb Christian König:
Reviewed-by: Christian König on patch #1
and #15.
Acked-by: Christian König on patch #2 and
#16.
Could you add these patches to the AMD
Can you add a Signed-off-by line to your commit message? This means
you agree to the Developer Certificate of Origin [1].
[1]: https://developercertificate.org/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Am 02.12.20 um 09:27 schrieb Mauro Carvalho Chehab:
The function name at kernel-doc markup doesn't match the name
of the function:
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1534: warning: expecting
prototype for amdgpu_debugfs_print_bo_info(). Prototype was for
amdgpu_bo_print_info()
Am 02.12.20 um 08:59 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 11:40 schrieb Christian König:
Reviewed-by: Christian König on patch #1
and #15.
Acked-by: Christian König on patch #2 and
#16.
Could you add these patches to the AMD tree?
Alex is usually the one who picks such stuff
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #64 from fawz (f...@negentropy.io) ---
Of course, that makes sense! Should've realized that there must be
correspondig logic for non-vega12/20 hardware.
If this patch works, are you going to submit it or should I? Afterall,
you
On Wed, 2 Dec 2020 08:55:52 +0100
Thomas Zimmermann wrote:
> Hi
>
> Am 01.12.20 um 12:20 schrieb Mikulas Patocka:
> >
> >
> > On Tue, 1 Dec 2020, Thomas Zimmermann wrote:
> >
...
> >> And why can links not run as DRM master mode? If it renders to the
> >> terminal,
> >> it should act
The function name at kernel-doc markup doesn't match the name
of the function:
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1534: warning: expecting
prototype for amdgpu_debugfs_print_bo_info(). Prototype was for
amdgpu_bo_print_info() instead
Fix it.
Signed-off-by: Mauro Carvalho
After applying this patch over next-20201201:
https://lore.kernel.org/linux-doc/cover.1606823973.git.mchehab+hua...@kernel.org/T/#m0072adc6eb1af595a31fcc3b019cb81ab28c7b9f
There are a couple of new warnings that the kernel-doc prototype
doesn't match the documented function.
This series
在 2020/12/1 21:44, Thomas Zimmermann 写道:
Hi
Am 01.12.20 um 14:05 schrieb tiantao (H):
在 2020/12/1 20:36, Thomas Zimmermann 写道:
Hi
Am 01.12.20 um 13:26 schrieb tiantao (H):
在 2020/12/1 20:17, Thomas Zimmermann 写道:
Hi
Am 01.12.20 um 12:55 schrieb Tian Tao:
Assign local variable to
patch #1 is code refactorings to use devm_drm_irq_install.
patch #2 add the new api to install irq, patch #3 is hibmc driver uses
the newly added api to register interrupts.
Changes since v1:
Splits the original patch #1 into two patches,rewrite
to_hibmc_drm_private() function in patch #2.Fix the
01.12.2020 17:34, Mark Brown пишет:
> On Tue, Dec 01, 2020 at 05:17:20PM +0300, Dmitry Osipenko wrote:
>> 01.12.2020 16:57, Mark Brown пишет:
>
>>> [1/1] regulator: Allow skipping disabled regulators in
>>> regulator_check_consumers()
>>> (no commit info)
>
>> Could you please hold on
On Tuesday 01 Dec 2020 at 12:19:18 (+), Lukasz Luba wrote:
>
>
> On 12/1/20 10:36 AM, Ionela Voinescu wrote:
> > Hi,
> >
> > Sorry for the delay and for the noise on this older version. I first
> > want to understand the code better.
> >
> > On Thursday 22 Oct 2020 at 11:55:28 (+0100),
The PM reference count is not expected to be incremented on
return in functions vop_enable and vop_enable.
However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here.
Replace it with
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: Maxime Ripard
---
The PM reference count is not expected to be incremented on
return in functions v3d_get_param_ioctl and v3d_job_init.
However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here.
Replace it with
On Tue, Dec 01, 2020 at 12:56:12PM +0100, Sam Ravnborg wrote:
> Hi Oleksij
>
> On Tue, Dec 01, 2020 at 10:27:37AM +0100, Oleksij Rempel wrote:
> > This display is already supported by the panel-simple driver, so add it
> > to the bindings documentation.
> >
> > This patch is needed to fix
Hi,
patches chained to this message contains changes I've found useful when
testing whether 2d rendering works well with the etnaviv driver on my
platform. Perhaps they're useful enough for merging upstream.
Thanks
Lubo
___
dri-devel mailing list
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, and compute it in atomic_check.
The PM reference count is not expected to be incremented on
return in these tegra functions.
However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here.
Replace it with pm_runtime_resume_and_get to keep
The BCM2711 supports higher bpc count than just 8, so let's support it in
our driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 71 -
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9
3 files
Hi Rob,
Rob Herring 于2020年12月1日周二 上午4:31写道：
> On Mon, Nov 30, 2020 at 7:29 AM Kevin Tang wrote:
> >
> > From: Kevin Tang
> >
> > Adds MIPI DSI Master and MIPI DSI-PHY (D-PHY)
> > support for Unisoc's display subsystem.
> >
> > Cc: Orson Zhai
> > Cc: Chunyan Zhang
> > Signed-off-by: Kevin
On Mon, Nov 30, 2020 at 05:53:39PM +, Xiong, Jianxin wrote:
> > From: Jason Gunthorpe
> > Sent: Monday, November 30, 2020 8:08 AM
> > To: Xiong, Jianxin
> > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug
> > Ledford ; Leon Romanovsky
> > ; Sumit Semwal ; Christian
Hi,
Static analysis on linux-next with Coverity had detected a minor issue
in the following commit:
commit 2a74e8682a39d00e04ca278459ae7d7ecbdfb394
Author: Sam Ravnborg
Date: Sat Nov 28 23:40:55 2020 +0100
video: fbdev: sis: Fix set but not used warnings in init.c
The analysis is as
在 2020/12/1 18:35, Thomas Zimmermann 写道:
Using struct drm_device.pdev is deprecated. Convert hibmc to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Xinliang Liu
Cc: Tian Tao
Cc: John Stultz
Cc: Xinwei Kong
Cc: Chen Feng
---
01.12.2020 16:57, Mark Brown пишет:
> On Thu, 5 Nov 2020 02:43:57 +0300, Dmitry Osipenko wrote:
>> Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces
>> power consumption and heating of the Tegra chips. Tegra SoC has multiple
>> hardware units which belong to a core power
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
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
drivers/gpu/drm/vc4/vc4_drv.h | 10 +-
Use devm_drm_irq_install to register interrupts so that
drm_irq_uninstall is not called when hibmc is removed.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git
1 - 100 of 143 matches
Mail list logo
