Am 05.02.21 um 03:23 schrieb Kalesh Singh:
If a FD refers to a DMA buffer add the DMA buffer inode number to
/proc//fdinfo/ and /proc//task//fdindo/.
The dmabuf inode number allows userspace to uniquely identify the buffer
and avoids a dependency on /proc//fd/* when accounting per-process
DMA
On Thu, Feb 04, 2021 at 11:30:50AM -0500, Tong Zhang wrote:
> if qxl_device_init() fail, drm device will not be registered,
> in this case, do not run qxl_drm_release()
How do you trigger this?
take care,
Gerd
___
dri-devel mailing list
On Tue, 2 Feb 2021 at 09:03, Lyude Paul wrote:
>
> On Wed, 2020-09-23 at 12:13 +1000, Sam McNally wrote:
> > From: Hans Verkuil
> >
> > These are required for the CEC MST support.
> >
> > Signed-off-by: Hans Verkuil
> > Signed-off-by: Sam McNally
> > ---
> >
> > (no changes since v1)
> >
> >
On Thu, Feb 04, 2021 at 03:58:33PM +0100, Christian König wrote:
> ?
>
> What's the background here?
>
> Christian.
>
> Am 04.02.21 um 15:57 schrieb Gerd Hoffmann:
> > kobject: '(null)' ((ptrval)): is not initialized, yet kobject_put()
> > is being called.
> > WARNING: CPU: 0 PID: 209
On Thu, 4 Feb 2021 at 21:42, Hans Verkuil wrote:
>
> On 23/09/2020 04:13, Sam McNally wrote:
> > With DP v2.0 errata E5, CEC tunneling can be supported through an MST
> > topology.
> >
> > There are some minor differences for CEC tunneling through an MST
> > topology compared to CEC tunneling to
On 2/5/2021 4:26 AM, Rob Clark wrote:
From: Rob Clark
In moving code around, we ended up using the same pointer to
copy_from_user() the relocs tables as we used for the cmd table
entry, which is clearly not right. This went unnoticed because
modern mesa on non-ancent kernels does not actually
On Thu, 4 Feb 2021 at 21:19, Hans Verkuil wrote:
>
> On 01/02/2021 23:13, Ville Syrjälä wrote:
> > On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> >> From: Hans Verkuil
> >>
> >> For adapters behind an MST hub use the correct AUX channel.
> >>
> >> Signed-off-by: Hans Verkuil
>
https://bugzilla.kernel.org/show_bug.cgi?id=210849
--- Comment #10 from JerryD (jvdeli...@charter.net) ---
This bug has basically disabled two different machines I have that use AMD
graphics cards. One, a work station running Fedora 33 will lose the display if
I do not log on right away after a
On Thu, Feb 4, 2021 at 6:52 PM Dave Airlie wrote:
>
> On Thu, 4 Feb 2021 at 14:57, Alex Deucher wrote:
> >
> > Hi Dave, Daniel,
> >
> > More fixes for 5.12. Same PR from last week with the issue Felix reported
> > fixed and a few more additional fixes on top.
> >
> > The following changes since
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> It turns out that reasoning for lowering max. supported frequency is
> wrong. Scrambling works just fine. Several now fixed bugs prevented
> proper functioning, even with rates lower than 340 MHz. Issues were just
> more pronounced with
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> cpce value for 594 MHz is set differently in BSP driver. Fix that.
>
> Fixes: c71c9b2fee17 ("drm/sun4i: Add support for Synopsys HDMI PHY")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> As expected, HDMI controller clock should always match pixel clock. In
> the past, changing HDMI controller rate would seemingly worsen
> situation. However, that was the result of other bugs which are now
> fixed.
>
> Fix that by removing
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> CLK_SET_RATE_PARENT flag is checked on parent clock instead of current
> one. Fix that.
>
> Fixes: 3f790433c3cb ("clk: sunxi-ng: Adjust MP clock parent rate when
> allowed")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> Channel 1 has polarity bits for vsync and hsync signals but driver never
> sets them. It turns out that with pre-HDMI2 controllers seemingly there
> is no issue if polarity is not set. However, with HDMI2 controllers
> (H6) there often
Hi all,
After merging the amdgpu tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Caused by commit
13a75af50484 ("drm/amd/display: Fix unused variable warning")
interacting with commit
4c3a3292730c ("drm/amd/display: fix unused variable warning")
from the drm tree.
Hi Linus,
Fixes for rc7, bit bigger than I'd like at this stage, but most of the
i915 stuff and some amdgpu is destined for staging and I'd rather not
hold it up, the i915 changes also pulled in a few precusor code
movement patches to make things cleaner, but nothing seems that
horrible, and I've
The default list was old and in particular lacking all common 16:9
resolutions, as well as some newer 16:10 ones.
This makes them selectable in resolution change lists, which can be
quite useful (for instance in case auto-fit isn't enabled).
Signed-off-by: Roland Scheidegger
Reviewed-by: Martin
Compilation of pyverbs/dmabuf_alloc.c depends on a few DRM headers
that are installed by either the kernel-header or the libdrm package.
The installation is optional and the location is not unique.
Check the presence of the headers at both the standard locations and
any location defined by custom
Commit 6b0a3238289f ("verbs: Support dma-buf based memory region") caused
a build failure when building for 32b systems with gcc:
$ mkdir build && cd build && CFLAGS="-m32" cmake -GNinja .. \
-DIOCTL_MODE=both -DNO_PYVERBS=1 -DENABLE_WERROR=1 && ninja
...
../libibverbs/cmd_mr.c: In function
Rename the parameter 'unit' to 'gpu'. Expand GTT to the full name in the
comments.
Signed-off-by: Jianxin Xiong
Reviewed-by: John Hubbard
---
pyverbs/dmabuf.pyx | 12
pyverbs/dmabuf_alloc.c | 12
pyverbs/dmabuf_alloc.h | 2 +-
pyverbs/mr.pyx | 6 ++--
This is the second version of the patch series. Change log:
v2:
* Use pgk_check_modules() to check libdrm configuration instead of calling
pkg-config directly
* Put all the DRM header checking logic in CMakeLists.txt
* Use a seperate source file for dma-buf allocation stubs
* Remove the
On 2021-02-03 15:15, Konrad Dybcio wrote:
The maximum mdp clock rate on msm8974v2 is 320MHz. Fix it.
Signed-off-by: Konrad Dybcio
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Thu, 4 Feb 2021 at 14:57, Alex Deucher wrote:
>
> Hi Dave, Daniel,
>
> More fixes for 5.12. Same PR from last week with the issue Felix reported
> fixed and a few more additional fixes on top.
>
> The following changes since commit a6b8720c2f85143561c3453e1cf928a2f8586ac0:
>
> Merge tag
On 2/4/21 11:29 PM, Laurent Pinchart wrote:
Hi Jagan,
Thank you for the patch.
On Wed, Feb 03, 2021 at 12:42:56PM +0530, Jagan Teki wrote:
SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from
Texas Instruments.
SN65DSI83, SN65DSI85 are variants of the same family of bridge
On 2/4/21 10:50 AM, Jianxin Xiong wrote:
Rename the parameter 'unit' to 'gpu'. Expand GTT to the full name in the
comments.
Signed-off-by: Jianxin Xiong
---
pyverbs/dmabuf.pyx | 12
pyverbs/dmabuf_alloc.c | 12
pyverbs/dmabuf_alloc.h | 2 +-
pyverbs/mr.pyx |
From: Rob Clark
In moving code around, we ended up using the same pointer to
copy_from_user() the relocs tables as we used for the cmd table
entry, which is clearly not right. This went unnoticed because
modern mesa on non-ancent kernels does not actually use relocs.
But this broke ancient mesa
Hi Jagan,
Thank you for the patch.
On Wed, Feb 03, 2021 at 12:42:56PM +0530, Jagan Teki wrote:
> SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from
> Texas Instruments.
>
> SN65DSI83, SN65DSI85 are variants of the same family of bridge
> controllers.
>
> Right now the bridge
On Thu, Feb 4, 2021 at 8:59 PM Andrzej Hajda wrote:
>
>
> W dniu 04.02.2021 o 13:34, Nicolas Boichat pisze:
> > On Thu, Feb 4, 2021 at 8:07 PM Robert Foss wrote:
> >> Hi Xin,
> >>
> >> Thanks for the patch.
> >>
> >> On Thu, 28 Jan 2021 at 12:17, Xin Ji wrote:
> >>> Enable DSI EOTP feature for
> -Original Message-
> From: Jason Gunthorpe
> Sent: Thursday, February 04, 2021 1:12 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
> ; Edward Srouji ;
On 2/4/21 10:10 PM, Doug Anderson wrote:
Hi,
Hi,
[...]
+ regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
Do you need to list REG_RC_RESET as volatile? Specifically you need
to make sure it's not cached...
Isn't volatile table exactly for this purpose -- to make sure the reg is
not
[+cc Oliver, Pali, Krzysztof]
s/also/Also/ in subject
On Thu, Feb 04, 2021 at 05:58:30PM +0100, Daniel Vetter wrote:
> We are already doing this for all the regular sysfs files on PCI
> devices, but not yet on the legacy io files on the PCI buses. Thus far
> now problem, but in the next patch I
On Thursday, February 4th, 2021 at 10:15 PM, James Park
wrote:
> No, I haven't pushed anything with DRM_BASIC_TYPES_DEFINED yet. I was
> just illustrating since DRM_BASIC_TYPES_H would not be a great
> choice for a name in this case.
This approach looks fine to me too. I'd R-b it.
Thanks for
On Wed, Feb 3, 2021 at 2:51 PM Michael Nazzareno Trimarchi
wrote:
>
> Hi
>
> On Wed, Feb 3, 2021 at 8:13 AM Jagan Teki wrote:
> >
> > SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from
> > Texas Instruments.
> >
> > SN65DSI83, SN65DSI85 are variants of the same family of bridge
> >
On Thu, Feb 4, 2021 at 1:07 PM Emil Velikov wrote:
>
> On Thu, 4 Feb 2021 at 18:17, James Park wrote:
> >
> > On Thu, Feb 4, 2021 at 9:37 AM James Park
> > wrote:
> > >
> > > On Thu, Feb 4, 2021 at 3:37 AM Emil Velikov
> > > wrote:
> > > >
> > > > Currently, the drm_fourcc.h header depends
On Thu, Feb 04, 2021 at 10:50:51AM -0800, Jianxin Xiong wrote:
> Compilation of pyverbs/dmabuf_alloc.c depends on a few DRM headers
> that are installed by either the kernel-header or the libdrm package.
> The installation is optional and the location is not unique.
>
> The standard locations
Hi,
On Thu, Feb 4, 2021 at 10:41 AM Marek Vasut wrote:
>
> >> +static const struct regmap_range sn65dsi83_volatile_ranges[] = {
> >> + regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_LVDS_PLL),
> >
> > Why is REG_RC_LVDS_PLL volatile?
>
> See register 0xa bit 7, PLL_EN_STAT .
Wow, I looked at it
On Thu, 4 Feb 2021 at 18:17, James Park wrote:
>
> On Thu, Feb 4, 2021 at 9:37 AM James Park wrote:
> >
> > On Thu, Feb 4, 2021 at 3:37 AM Emil Velikov
> > wrote:
> > >
> > > Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
> > > At the same time drm.h pulls a lot of
On Thu, Feb 04, 2021 at 09:19:57PM +0100, Daniel Vetter wrote:
> On Thu, Feb 4, 2021 at 9:09 PM Jason Gunthorpe wrote:
> >
> > On Thu, Feb 04, 2021 at 08:59:59PM +0100, Daniel Vetter wrote:
> >
> > > So I think just checking for VM_PFNMAP after the vma is set up should
> > > be enough to
> On Feb 4, 2021, at 2:06 PM, Thomas Zimmermann wrote:
>
> Hi Tong
>
>> I have posted an updated patch.
>> The new patch use the following logic
>> +if (!qdev->ddev.mode_config.funcs)
>> + return;
>
> This is again just papering over the issue. Better don't call
> qxl_drm_release()
On Thu, Feb 4, 2021 at 9:09 PM Jason Gunthorpe wrote:
>
> On Thu, Feb 04, 2021 at 08:59:59PM +0100, Daniel Vetter wrote:
>
> > So I think just checking for VM_PFNMAP after the vma is set up should
> > be enough to guarantee we'll only have pte_special ptes in there,
> > ever. But I'm not sure,
On Thu, Feb 04, 2021 at 08:59:59PM +0100, Daniel Vetter wrote:
> So I think just checking for VM_PFNMAP after the vma is set up should
> be enough to guarantee we'll only have pte_special ptes in there,
> ever. But I'm not sure, this stuff all isn't really documented much
> and the code is
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit
Several drivers use GEM buffer objects as shadow buffers for the actual
framebuffer memory. Right now, drivers do these vmap operations in their
commit tail, which is actually not allowed by the locking rules for
the dma-buf reservation lock. The involved BO has to be vmapped in the
plane's
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit
Several SHMEM-based drivers use the BO as shadow buffer for the real
framebuffer memory. Damage handling requires a vmap of the BO memory.
But vmap/vunmap can acquire the dma-buf reservation lock, which is not
allowed in commit tails.
This patchset introduces a set of helpers that implement
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit
Just like regular plane-state helpers, drivers can use these new
callbacks to create and destroy private plane state.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_simple_kms_helper.c | 40 +++--
include/drm/drm_simple_kms_helper.h | 28 +
2
On Thu, Feb 4, 2021 at 7:38 PM Jason Gunthorpe wrote:
>
> On Thu, Feb 04, 2021 at 06:16:27PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 4, 2021 at 5:13 PM Jason Gunthorpe wrote:
> > > On Wed, Feb 03, 2021 at 10:19:48PM +0100, Daniel Vetter wrote:
> > > > tldr; DMA buffers aren't normal memory,
On Thu, Feb 04, 2021 at 11:49:23AM +, Robin Murphy wrote:
> On 2021-02-04 07:29, Christoph Hellwig wrote:
> > On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
> > > This patch converts several swiotlb related variables to arrays, in
> > > order to maintain stat/status for
Hi Thomas,
The original problem was qxl_device_init() can fail,
when it fails there is no need to call
qxl_modeset_fini(qdev);
qxl_device_fini(qdev);
But those two functions are otherwise called in the qxl_drm_release() -
I have posted an updated patch.
The new patch use the
On Thu, Feb 4, 2021 at 10:09 AM Chema Casanova wrote:
>
> On 3/9/20 18:48, Yukimasa Sugizaki wrote:
> > From: Yukimasa Sugizaki
> >
> > The default timeout is 500 ms which is too short for some workloads
> > including Piglit. Adding this parameter will help users to run heavier
> > tasks.
> >
>
if qxl_device_init() fail, drm device will not be registered,
in this case, do not run qxl_drm_release()
[5.258534]
==
[5.258931] BUG: KASAN: user-memory-access in
qxl_destroy_monitors_object+0x42/0xa0 [qxl]
[5.259388]
Channel 1 has polarity bits for vsync and hsync signals but driver never
sets them. It turns out that with pre-HDMI2 controllers seemingly there
is no issue if polarity is not set. However, with HDMI2 controllers
(H6) there often comes to de-synchronization due to phase shift. This
causes
On 2/4/21 1:13 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20210203:
>
on x86_64:
Still seeing 2 unrelated issues:
WARNING: unmet direct dependencies detected for DRM_I915_WERROR
Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
!COMPILE_TEST [=y]
Selected by
On Thu, Feb 4, 2021, 18:18 Daniel Vetter wrote:
> On Thu, Feb 4, 2021 at 5:03 PM Toni Spets wrote:
> >
> >
> >
> > On Thu, Feb 4, 2021, 17:20 Daniel Vetter wrote:
> >>
> >> On Wed, Feb 03, 2021 at 09:53:40PM +0200, Toni Spets wrote:
> >> > The blocking implementation of the dirtyfb ioctl is
Over the year I got plenty of reports of troubles with H6 HDMI signal.
Sometimes monitor flickers, sometimes there was no image at all and
sometimes it didn't play well with AVR.
It turns out there are multiple issues. Patch 1 fixes clock issue,
which didn't adjust parent rate, even if it is
On 2/4/21 6:15 PM, Doug Anderson wrote:
Hi,
[...]
+static const struct regmap_range sn65dsi83_volatile_ranges[] = {
+ regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_LVDS_PLL),
Why is REG_RC_LVDS_PLL volatile?
See register 0xa bit 7, PLL_EN_STAT .
+ regmap_reg_range(REG_IRQ_STAT,
CLK_SET_RATE_PARENT flag is checked on parent clock instead of current
one. Fix that.
Fixes: 3f790433c3cb ("clk: sunxi-ng: Adjust MP clock parent rate when allowed")
Tested-by: Andre Heider
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi-ng/ccu_mp.c | 2 +-
1 file changed, 1 insertion(+),
On Wed, Feb 03, 2021 at 10:19:48PM +0100, Daniel Vetter wrote:
> tldr; DMA buffers aren't normal memory, expecting that you can use
> them like that (like calling get_user_pages works, or that they're
> accounting like any other normal memory) cannot be guaranteed.
>
> Since some userspace only
On Thu, Feb 04, 2021 at 06:16:27PM +0100, Daniel Vetter wrote:
> On Thu, Feb 4, 2021 at 5:13 PM Jason Gunthorpe wrote:
> > On Wed, Feb 03, 2021 at 10:19:48PM +0100, Daniel Vetter wrote:
> > > tldr; DMA buffers aren't normal memory, expecting that you can use
> > > them like that (like calling
On 2/4/21 7:38 PM, Doug Anderson wrote:
Hi,
Hi,
[...]
+properties:
+ compatible:
+const: ti,sn65dsi83
+
+ reg:
+const: 0x2d
+
+ enable-gpios:
+maxItems: 1
+description: GPIO specifier for bridge_en pin (active high).
I see two regulators: vcc and vcore. Shouldn't those
cpce value for 594 MHz is set differently in BSP driver. Fix that.
Fixes: c71c9b2fee17 ("drm/sun4i: Add support for Synopsys HDMI PHY")
Tested-by: Andre Heider
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On Thu, Feb 4, 2021, 17:20 Daniel Vetter wrote:
> On Wed, Feb 03, 2021 at 09:53:40PM +0200, Toni Spets wrote:
> > The blocking implementation of the dirtyfb ioctl is extremely slow when
> > used for damage tracking on RK3399. If this implementation is in place
> Xorg
> > will default to using it
As expected, HDMI controller clock should always match pixel clock. In
the past, changing HDMI controller rate would seemingly worsen
situation. However, that was the result of other bugs which are now
fixed.
Fix that by removing set_rate quirk and always set clock rate.
Fixes: 40bb9d3147b2
On Thu, Feb 4, 2021 at 9:37 AM James Park wrote:
>
> On Thu, Feb 4, 2021 at 3:37 AM Emil Velikov wrote:
> >
> > Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
> > At the same time drm.h pulls a lot of unneeded symbols.
> >
> > Add new guard DRM_FOURCC_STANDALONE, which
On Thu, Feb 4, 2021 at 3:37 AM Emil Velikov wrote:
>
> Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
> At the same time drm.h pulls a lot of unneeded symbols.
>
> Add new guard DRM_FOURCC_STANDALONE, which when set will use local
> declaration of said symbols.
>
> When
On 02/02/21, Marco Felsch wrote:
> Hi Oliver,
>
> On 21-02-02 18:35, Oliver Graute wrote:
> > Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD
> > to panel-simple.
> >
> > The panel spec from Variscite can be found at:
> >
On Thu, Feb 04, 2021 at 08:50:38AM -0500, Alex Deucher wrote:
> On Thu, Feb 4, 2021 at 2:48 AM John Hubbard wrote:
> >
> > On 12/15/20 1:27 PM, Jianxin Xiong wrote:
> > > This patch series adds dma-buf importer role to the RDMA driver in
> > > attempt to support RDMA using device memory such as
On 2/4/21 6:15 PM, Doug Anderson wrote:
Hi,
[...]
+properties:
+ compatible:
+const: ti,sn65dsi83
+
+ reg:
+const: 0x2d
+
+ enable-gpios:
+maxItems: 1
+description: GPIO specifier for bridge_en pin (active high).
I see two regulators: vcc and vcore. Shouldn't those be
It turns out that reasoning for lowering max. supported frequency is
wrong. Scrambling works just fine. Several now fixed bugs prevented
proper functioning, even with rates lower than 340 MHz. Issues were just
more pronounced with higher frequencies.
Fix that by allowing max. supported frequency
From: Colin Ian King
Don't populate the const array m_div_val on the stack but instead make
it static. Makes the object code smaller by 29 bytes:
Before:
textdata bss dechex filename
347364552 0 39288 9978 drivers/gpu/drm/mgag200/mgag200_mode.o
After:
textdata
Hi Colin,
Thank you for the patch.
On Thu, Feb 04, 2021 at 06:33:44PM +, Colin King wrote:
> From: Colin Ian King
>
> Don't populate the const array frs_limits on the stack but instead make
> it static. Makes the object code smaller by 128 bytes:
>
> Before:
>textdata bss
Hi Tong
Am 04.02.21 um 19:52 schrieb Tong Zhang:
Hi Thomas,
The original problem was qxl_device_init() can fail,
when it fails there is no need to call
qxl_modeset_fini(qdev);
qxl_device_fini(qdev);
But those two functions are otherwise called in the qxl_drm_release() -
OK,
On 2/4/21 10:44 AM, Alex Deucher wrote:
...
The argument is that vram is a scarce resource, but I don't know if
that is really the case these days. At this point, we often have as
much vram as system ram if not more.
I thought the main argument was that GPU memory could move at any time
W dniu 19.01.2021 o 05:41, Jun Nie pisze:
> With commit 55c5cc63ab, the hdmi_codec_set_jack() will report unsupport
> failure if set_jack handler is missing. Add set_jack handler to resolve
> this failure.
>
> Signed-off-by: Jun Nie
> ---
> .../gpu/drm/bridge/adv7511/adv7511_audio.c| 27
On Thu, Feb 4, 2021 at 1:29 PM Jason Gunthorpe wrote:
>
> On Thu, Feb 04, 2021 at 08:50:38AM -0500, Alex Deucher wrote:
> > On Thu, Feb 4, 2021 at 2:48 AM John Hubbard wrote:
> > >
> > > On 12/15/20 1:27 PM, Jianxin Xiong wrote:
> > > > This patch series adds dma-buf importer role to the RDMA
Hi,
On Thu, Feb 4, 2021 at 10:09 AM Marek Vasut wrote:
>
> On 2/4/21 6:15 PM, Doug Anderson wrote:
>
> Hi,
>
> [...]
>
> >> +properties:
> >> + compatible:
> >> +const: ti,sn65dsi83
> >> +
> >> + reg:
> >> +const: 0x2d
> >> +
> >> + enable-gpios:
> >> +maxItems: 1
> >> +
Rename the parameter 'unit' to 'gpu'. Expand GTT to the full name in the
comments.
Signed-off-by: Jianxin Xiong
---
pyverbs/dmabuf.pyx | 12
pyverbs/dmabuf_alloc.c | 12
pyverbs/dmabuf_alloc.h | 2 +-
pyverbs/mr.pyx | 6 ++--
tests/test_mr.py | 78
This series fixes a few issues related to the dma-buf support. It consists
of three patches. The first patch fixes a compilation warning for 32-bit
builds. Patch 2 renames a function parameter and expands an abbreviation.
Patch 3 adds check for DRM headers.
Pull request at github:
Compilation of pyverbs/dmabuf_alloc.c depends on a few DRM headers
that are installed by either the kernel-header or the libdrm package.
The installation is optional and the location is not unique.
The standard locations (such as /usr/include/drm, /usr/include/libdrm)
are checked first. If
Commit 6b0a3238289f ("verbs: Support dma-buf based memory region") caused
a build failure when building for 32b systems with gcc:
$ mkdir build && cd build && CFLAGS="-m32" cmake -GNinja .. \
-DIOCTL_MODE=both -DNO_PYVERBS=1 -DENABLE_WERROR=1 && ninja
...
../libibverbs/cmd_mr.c: In function
The series are:
Reviewed-and-Tested-by: Leo Liu
On 2021-02-04 9:44 a.m., Christian König wrote:
The VCN3 instances can do both decode as well as encode.
Share the scheduler load balancing score and remove fixing encode to
only the second instance.
Signed-off-by: Christian König
---
Hi
Am 04.02.21 um 15:57 schrieb Gerd Hoffmann:
This reverts commit b91907a6241193465ca92e357adf16822242296d.
This should be in the correct format, as given by 'dim cite'.
dim cite b91907a6241193465ca92e357adf16822242296d
b91907a62411 ("drm/qxl: do not run release if qxl failed to init")
From: Colin Ian King
Don't populate the const array frs_limits on the stack but instead make
it static. Makes the object code smaller by 128 bytes:
Before:
textdata bss dec hex filename
248457440 64 323497e5d ./drivers/gpu/drm/bridge/tc358768.o
After:
Hi
Am 04.02.21 um 19:17 schrieb Colin King:
From: Colin Ian King
Don't populate the const array m_div_val on the stack but instead make
it static. Makes the object code smaller by 29 bytes:
Before:
text data bss dechex filename
34736 4552 0 39288 9978
Hi Oliver,
On Tue, Feb 2, 2021 at 2:35 PM Oliver Graute wrote:
> +static const struct panel_desc sgd_gktw70sdad1sd = {
> + .timings = _gktw70sdad1sd_timing,
> + .num_timings = 1,
> + .bpc = 6,
> + .size = {
> + .width = 153,
> + .height = 86,
Am 04.02.21 um 15:57 schrieb Gerd Hoffmann:
dumb buffers are shadowed anyway, so there is no need to store them
in device memory. Use QXL_GEM_DOMAIN_CPU (TTM_PL_SYSTEM) instead.
Makes sense. I had similar issues in other drivers about the placement
of buffers. For them, all new buffers now
Am 04.02.21 um 15:57 schrieb Gerd Hoffmann:
Suggested-by: Thomas Zimmermann
Signed-off-by: Gerd Hoffmann
Thanks for this.
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
On Thu, Feb 04, 2021 at 04:59:51PM +, Russell King - ARM Linux admin wrote:
> On Thu, Feb 04, 2021 at 05:56:50PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Feb 04, 2021 at 04:52:24PM +, Russell King - ARM Linux admin
> > wrote:
> > > On Tue, Feb 02, 2021 at 03:06:05PM +0100, Greg
From: Colin Ian King
Don't populate the const array m_div_val on the stack but instead make
it static. Makes the object code smaller by 29 bytes:
Before:
textdata bss dechex filename
347364552 0 39288 9978 drivers/gpu/drm/mgag200/mgag200_mode.o
After:
textdata
Am 04.02.21 um 15:57 schrieb Gerd Hoffmann:
In case we have a shadow surface on shutdown release
it so it doesn't leak.
Signed-off-by: Gerd Hoffmann
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_display.c | 4
1 file changed, 4 insertions(+)
diff --git
On 3/9/20 18:48, Yukimasa Sugizaki wrote:
From: Yukimasa Sugizaki
The default timeout is 500 ms which is too short for some workloads
including Piglit. Adding this parameter will help users to run heavier
tasks.
Signed-off-by: Yukimasa Sugizaki
---
drivers/gpu/drm/v3d/v3d_sched.c | 24
On Mon, Feb 01, 2021 at 02:01:43PM +0200, Imre Deak wrote:
> Caching EDIDs for physical ports prevents updating the EDID if a port
> gets reconnected via a Connection Status Notification message, fix this.
>
> Fixes: db1a07956968 ("drm/dp_mst: Handle SST-only branch device case")
> Cc: Wayne Lin
On Thu, Feb 4, 2021 at 6:26 PM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> On Thu, Feb 04, 2021 at 06:19:22PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 4, 2021 at 5:28 PM Andrzej Hajda wrote:
> > > W dniu 04.02.2021 o 17:05, Daniel Vetter pisze:
> > > > On Thu, Feb 04, 2021 at 11:56:32AM +0100,
On Wed, Feb 03, 2021 at 12:42:55PM +0530, Jagan Teki wrote:
> SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from
> Texas Instruments.
>
> SN65DSI83, SN65DSI85 are variants of the same family of bridge
> controllers.
>
> Right now the bridge driver is supporting a single link,
Hi Daniel,
On Thu, Feb 04, 2021 at 06:19:22PM +0100, Daniel Vetter wrote:
> On Thu, Feb 4, 2021 at 5:28 PM Andrzej Hajda wrote:
> > W dniu 04.02.2021 o 17:05, Daniel Vetter pisze:
> > > On Thu, Feb 04, 2021 at 11:56:32AM +0100, Michael Tretter wrote:
> > >> On Thu, 04 Feb 2021 11:17:49 +0100,
On Thu, Feb 4, 2021 at 5:28 PM Andrzej Hajda wrote:
>
>
> W dniu 04.02.2021 o 17:05, Daniel Vetter pisze:
> > On Thu, Feb 04, 2021 at 11:56:32AM +0100, Michael Tretter wrote:
> >> On Thu, 04 Feb 2021 11:17:49 +0100, Daniel Vetter wrote:
> >>> On Wed, Feb 3, 2021 at 9:32 PM Michael Tretter
> >>>
On Thu, Feb 4, 2021 at 5:13 PM Jason Gunthorpe wrote:
> On Wed, Feb 03, 2021 at 10:19:48PM +0100, Daniel Vetter wrote:
> > tldr; DMA buffers aren't normal memory, expecting that you can use
> > them like that (like calling get_user_pages works, or that they're
> > accounting like any other normal
Hi,
On Sat, Jan 30, 2021 at 10:10 AM Marek Vasut wrote:
>
> Add driver for TI SN65DSI83 Single-Channel DSI to Single-Link LVDS bridge.
> The driver operates the chip over I2C bus. Currently the LVDS clock are
> always derived from DSI clock lane, which is the usual mode of operation,
> support
1 - 100 of 202 matches
Mail list logo
