The original intention was to avoid CPU page table unmaps
when BOs move between the GTT and SYSTEM domain.
The problem is that this never correctly handled changes
in the caching attributes or backing pages.
Just drop this for now and simply unmap the CPU page
tables in all cases.
Signed-off-by:
On Thu, Jul 16, 2020 at 4:00 PM Maxime Ripard wrote:
>
> On Tue, Jul 14, 2020 at 03:13:01PM +0800, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai
> >
> > Some LCD panels do not support 24-bit true color, or 8bits per channel
> > RGB. Many low end ones only support up to 6 bits per channel natively.
>
On Thu, Jul 16, 2020 at 4:04 PM Maxime Ripard wrote:
>
> Hi,
>
> On Tue, Jul 14, 2020 at 03:13:05PM +0800, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai
> >
> > The Primo73 is an MSI branded Allwinner A20-based 7-inch tablet. It has
> > a metal back case with a plastic insert around where the WiFi a
Dave Airlie writes:
> On Thu, 16 Jul 2020 at 00:59, Thomas Zimmermann wrote:
> >
> > This patchset puts device initialization in the correct order and
> > adds support for G200 Desktop chips (PCI ids 0x520 and 0x521).
>
> why? :-)
>
> I'm pretty sure I NAKed the previous version because
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #67 from Anthony Ruhier (anthony.ruh...@gmail.com) ---
No freeze for me too, and I compiled firefox yesterday, which usually triggers
a freeze on 5.7, and nothing yet. That's some really good news if it stays
true, thanks a lot Duncan!
> … to fix it.
I suggest to replace this wording by the tag “Fixes”.
…
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -276,8 +276,10 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size,
> int *align, u32 flags,
> break;
> }
>
> - if (WARN_ON(pi < 0))
> +
On 7/15/20 2:29 PM, Rob Clark wrote:
From: Rob Clark
If there is no interconnect-names, but there is an interconnects
property, then of_icc_get(dev, "gfx-mem"); would return an error
rather than NULL.
Also, if there is no interconnect-names property, there will never
be a ocmem path. But of_i
On 2020/07/15 20:17, Tetsuo Handa wrote:
> On 2020/07/15 18:48, Dan Carpenter wrote:
>>> @@ -216,7 +216,7 @@ static void bit_clear_margins(struct vc_data *vc,
>>> struct fb_info *info,
>>> region.color = color;
>>> region.rop = ROP_COPY;
>>>
>>> - if (rw && !bottom_only) {
>>> + if (
On 2020/07/15 18:48, Dan Carpenter wrote:
>> @@ -216,7 +216,7 @@ static void bit_clear_margins(struct vc_data *vc, struct
>> fb_info *info,
>> region.color = color;
>> region.rop = ROP_COPY;
>>
>> -if (rw && !bottom_only) {
>> +if ((int) rw > 0 && !bottom_only) {
>>
Clang warns:
drivers/gpu/drm/i915/display/intel_combo_phy.c:268:3: warning: variable
'ret' is uninitialized when used here [-Wuninitialized]
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_TX_DW8_LN0(phy),
^~~
drivers/gpu/drm/i915/display/intel_combo_phy.c:261:10: note
The variable ret has been assigned the value '-EINVAL'. The assignment
in the if() is redundant. We can remove it.
Signed-off-by: Jing Xiangfeng
---
drivers/gpu/drm/drm_auth.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 800ac39
On Tue, Jul 14, 2020 at 09:03:14PM +0200, Noralf Trønnes wrote:
>
>
> Den 14.07.2020 19.40, skrev Peter Stuge:
> > Hi Noralf,
> >
> > Noralf Trønnes wrote:
> >> I would like to keep the SET_BUFFER request since it will serve as a
> >> syncing point between the host and the device. I'm no USB exp
On 2020/7/15 20:05, Daniel Vetter wrote:
On Wed, Jul 15, 2020 at 03:05:59PM +0800, Jing Xiangfeng wrote:
The variable ret has been assigned the value '-EINVAL'. The assignment
in the if() is redundant. We can remove it.
Nope, that's not correct. Before this assignement ret is guaranteed to
nouveau_bo_alloc() misses to call kfree() in an error path. Add the
missed function call to fix it.
Signed-off-by: Jing Xiangfeng
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/dr
On 2020/07/16 0:12, Dan Carpenter wrote:
> I've complained about integer overflows in fbdev for a long time...
>
> What I'd like to see is something like the following maybe. I don't
> know how to get the vc_data in fbmem.c so it doesn't include your checks
> for negative.
Yes. Like I said "Thus
On Thu, Jul 16, 2020 at 12:29:00AM +0900, Tetsuo Handa wrote:
> On 2020/07/16 0:12, Dan Carpenter wrote:
> > I've complained about integer overflows in fbdev for a long time...
> >
> > What I'd like to see is something like the following maybe. I don't
> > know how to get the vc_data in fbmem.c s
On Thu, Jul 16, 2020 at 09:59:38AM +0800, Jing Xiangfeng wrote:
>
>
> On 2020/7/15 20:05, Daniel Vetter wrote:
> > On Wed, Jul 15, 2020 at 03:05:59PM +0800, Jing Xiangfeng wrote:
> > > The variable ret has been assigned the value '-EINVAL'. The assignment
> > > in the if() is redundant. We can re
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #68 from Stratos Zolotas (str...@gmail.com) ---
(In reply to Stratos Zolotas from comment #60)
>
> To make things looks more strange... I have a non-explicable development
> with this issue. When it appeared to me I was in the middle
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #69 from Anthony Ruhier (anthony.ruh...@gmail.com) ---
(In reply to Stratos Zolotas from comment #68)
> (In reply to Stratos Zolotas from comment #60)
> >
> > To make things looks more strange... I have a non-explicable development
>
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #70 from Stratos Zolotas (str...@gmail.com) ---
(In reply to Anthony Ruhier from comment #69)
>
> You're talking about having the bug with 5.7.7 vanilla, right? Not with the
> revert of the commits quoted above?
Yes! It seemed to ha
Hi Sam
Am 08.07.20 um 19:19 schrieb Sam Ravnborg:
> Hi Thomas.
>
> On Wed, Jul 08, 2020 at 09:49:07AM +0200, Thomas Zimmermann wrote:
>> Calling drmm_vram_helper_alloc_mm() sets up a managed instance of
>> VRAM MM. Releasing the DRM device also frees the memory manager.
>>
>> The patch also updat
drm-misc-next-2020-07-16:
drm-misc-next for v5.9:
UAPI Changes:
Cross-subsystem Changes:
- Add ckoenig as dma-buf maintainer.
- Revert invalid fix for dma-fence-chain, and fix selftest.
- Add fixmes to amifb about APUS support.
- Use array3_size in fbcon_prepare_logo, and struct_size() in alloc_a
The helper doesn't expose any not-mapable memory resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem_vram_helper.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index e
The driver doesn't expose any not-mapable memory resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_b
The driver does support some not-mapable resources, but
those are already handled correctly in the switch/case
statement in the code.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers
The original intention was to avoid CPU page table unmaps
when BOs move between the GTT and SYSTEM domain.
The problem is that this never correctly handled changes
in the caching attributes or backing pages.
Just drop this for now and simply unmap the CPU page
tables in all cases.
Signed-off-by:
The driver doesn't expose any not-mapable memory resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_ttm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index a6e67149ef4a..820eb190d292
Not used any more. And it is bad design to use a TTM flag
to do a check inside a driver.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_driver.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 71b195e78c7c..9b2
The driver doesn't expose any not-mapable memory resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 54
The driver doesn't expose any not-mapable memory resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index
This is the second patchset for converting ast to managed DRM interfaces.
This one addresses memory management. There will be another, final round
of patches for converting DRM device structures as well.
Patch #1 introduces managed initialization for VRAM MM. Other drivers
using the VRAM helpers s
VRAM size detection is only relevant to the memory management. Move
the code into ast_mm.c.
While at it, rename the function to ast_get_vram_size(). The function
argument's type is now struct ast_private. The result is stored in a
local variable and not in struct ast_private any longer.
Signed-of
Although built upon TTM, the ast driver's VRAM MM helper does not
expose TTM to its users. Rename the related ast file to ast_mm.c.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/Makefile| 2 +-
drivers/gpu/drm/ast/{ast_ttm.c => ast_mm.c} | 0
2 files changed, 1 inserti
Cleaning up ast's MM code with ast_mm_fini() resets the write-combine
flags on the VRAM I/O memory. Drop ast_mm_fini() in favor of an auto-
release callback. Releasing the device also executes the callback.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 1 -
drivers/gpu/d
Calling drmm_vram_helper_init() sets up a managed instance of
VRAM MM. Releasing the DRM device also frees the memory manager.
The patch also updates the DRM documentation for VRAM helpers. The
tutorial now describes the new managed interface. The old interfaces
are deprecated and should not be us
As a first step to managed MM code in ast, switch over VRAM MM helpers.
v2:
* updated to use drmm_vram_helper_init()
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mm.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_
Posting the GPU requires the correct DRAM type to be stored in
struct ast_private. Therefore first initialize the DRAM info and
then post the GPU. This restores the original order of instructions
in this function.
Signed-off-by: Thomas Zimmermann
Acked-by: Benjamin Herrenschmidt
Fixes: bad09da6d
Am 16.07.20 um 14:50 schrieb Christian König:
> The helper doesn't expose any not-mapable memory resources.
>
> Signed-off-by: Christian König
Reviewed-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> d
Hi,
this patchset could have benefited from a cover letter.
Am 16.07.20 um 14:50 schrieb Christian König:
> The original intention was to avoid CPU page table unmaps
> when BOs move between the GTT and SYSTEM domain.
>
> The problem is that this never correctly handled changes
> in the caching a
Hi Thomas.
On Thu, Jul 16, 2020 at 02:53:47PM +0200, Thomas Zimmermann wrote:
> This is the second patchset for converting ast to managed DRM interfaces.
> This one addresses memory management. There will be another, final round
> of patches for converting DRM device structures as well.
>
> Patch
On Thu, Jul 16, 2020 at 05:03:23PM +0800, Qinglang Miao wrote:
> From: Yongqiang Liu
>
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Yongqiang Liu
> ---
> drivers/gpu/host1x/debug.c | 28
> 1 file changed, 4 insertions(+), 24 deletions(
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets. See the 'v1' notes below for more info.
v8:
Commit: "device core: Introduce DMA range map, supplanting ...
The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.
Hi Ondrej,
On Thu, Jul 16, 2020 at 02:37:51PM +0200, Ondrej Jirman wrote:
> When extending the driver for xbd599 panel support I tried to do minimal
> changes and keep the existing initialization timing.
>
> It turned out that it's not good enough and the existing init sequence
> is too aggressive
On Fri, 03 Jul 2020, Sam Ravnborg wrote:
> Improve the documentation for backlight_device and
> adapt it to kernel-doc style.
>
> The updated documentation is more strict on how locking is used.
> With the update neither update_lock nor ops_lock may be used
> outside the backlight core.
> This re
Hi Lee.
On Thu, Jul 16, 2020 at 03:39:41PM +0100, Lee Jones wrote:
> On Fri, 03 Jul 2020, Sam Ravnborg wrote:
>
> > Improve the documentation for backlight_device and
> > adapt it to kernel-doc style.
> >
> > The updated documentation is more strict on how locking is used.
> > With the update ne
On Thu, 16 Jul 2020, Sam Ravnborg wrote:
> Hi Lee.
>
> On Thu, Jul 16, 2020 at 03:39:41PM +0100, Lee Jones wrote:
> > On Fri, 03 Jul 2020, Sam Ravnborg wrote:
> >
> > > Improve the documentation for backlight_device and
> > > adapt it to kernel-doc style.
> > >
> > > The updated documentation i
Some Poco F1 phones have an LCD panel from Tianma, model nt36672a,
with a resolution of 1080x2246 that operates in DSI video mode.
Add the drm panel driver for it.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Androi
Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support
for the same.
Most of the panel data is taken from downstream panel dts, and is converted to
drm-panel based driver by me.
It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other
dependent patches is her
The nt36672a panel from Tianma is a FHD+ panel with a resolution of 1080x2246
and 6.18 inches size. It is found in some of the Poco F1 phones.
Signed-off-by: Sumit Semwal
---
.../display/panel/tianma,nt36672a.yaml| 110 ++
1 file changed, 110 insertions(+)
create mode 10
https://bugzilla.kernel.org/show_bug.cgi?id=208573
--- Comment #4 from Thomas Langkamp (thomas.langk...@medicalschool-hamburg.de)
---
Maybe it has something to do with my X470 Board not being PCI-E 4.0?
I switched to a better PSU today, but that did not help either.
Both screens completely black
On Thu, Jul 16, 2020 at 06:38:44PM +0200, Paul Cercueil wrote:
> Add support for the Image Processing Unit (IPU) found in all Ingenic
> SoCs.
>
> The IPU can upscale and downscale a source frame of arbitrary size
> ranging from 4x4 to 4096x4096 on newer SoCs, with bicubic filtering
> on newer SoCs
On Thu, Jul 16, 2020 at 06:38:43PM +0200, Paul Cercueil wrote:
> All Ingenic SoCs starting from the JZ4725B support OSD mode.
>
> In this mode, two separate planes can be used. They can have different
> positions and sizes, and one can be overlayed on top of the other.
>
> v2: Use fallthrough; in
flags is unused since the driver was introduced in commit 45d59d704080
("drm: Add new driver for MXSFB controller").
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/
Hi Paul.
On Thu, Jul 16, 2020 at 06:38:35PM +0200, Paul Cercueil wrote:
> plane->index is NOT the index of the color plane in a YUV frame.
> Actually, a YUV frame is represented by a single drm_plane, even though
> it contains three Y, U, V planes.
>
> v2-v3: No change
>
> Cc: sta...@vger.kernel
Den 14.07.2020 21.38, skrev Peter Stuge:
> Noralf Trønnes wrote:
>>> In all cases, the driver on the host knows/has available how many bytes
>>> were successfully transfered.
>>
>> I was thinking about the device, that it could get out of sync. Let's
>> say the host sends a 1k framebuffer and hal
On Thu, Jul 16, 2020 at 02:56:46PM +0200, Paul Cercueil wrote:
> The FRD350H54004 panel was marked as having active-high VSYNC and HSYNC
> signals, which sorts-of worked, but resulted in the picture fading out
> under certain circumstances.
>
> Fix this issue by marking VSYNC and HSYNC signals act
On Thu, Jul 16, 2020 at 02:57:30PM +0200, Sebastian Reichel wrote:
> Convert panel-dsi-cm bindings to YAML and add
> missing properties while at it.
>
> Reviewed-by: Laurent Pinchart
> Reviewed-by: Rob Herring
> Signed-off-by: Sebastian Reichel
Hi Sebastian.
Look good now. Applied this patch
Hi,
On Thu, Jul 16, 2020 at 07:52:58PM +0200, Sam Ravnborg wrote:
> On Thu, Jul 16, 2020 at 02:57:30PM +0200, Sebastian Reichel wrote:
> > Convert panel-dsi-cm bindings to YAML and add
> > missing properties while at it.
> >
> > Reviewed-by: Laurent Pinchart
> > Reviewed-by: Rob Herring
> > Sig
https://bugzilla.kernel.org/show_bug.cgi?id=208587
Bug ID: 208587
Summary: amdgpu hang and gnome shell crash if playing video on
5600M with DRI_PRIME
Product: Drivers
Version: 2.5
Kernel Version: 5.8.0-rc5
Hardware: x86
https://bugzilla.kernel.org/show_bug.cgi?id=208589
Bug ID: 208589
Summary: amdgpu screen corruption with DRI_PRIME on external
monitor at resolution 2560x1440 and more then 60hz
Product: Drivers
Version: 2.5
Kernel Version: 5.8.0
Hi Thomas.
On Tue, Jul 14, 2020 at 10:32:37AM +0200, Thomas Zimmermann wrote:
> The drm_gem_vram_create() function is the only caller of the internal
> helepr drm_gem_vram_init(). Streamline the code by putting all code into
helper
> the create function.
>
> Signed-off-by: Thomas Zimmermann
Acke
On Tue, Jul 14, 2020 at 10:32:38AM +0200, Thomas Zimmermann wrote:
> Don't override the GEM object functions unconditionally. If the driver
> sets the GEM functions, VRAM helpers will now them. The idea has been
s/now/own
> taken from SHMEM helpers. If drivers need special versions of some of
> the
On Mon, Jul 13, 2020 at 02:49:23PM +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn
On Mon, Jul 13, 2020 at 02:39:13PM +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn
Hi Suraj.
On Sat, Jul 11, 2020 at 08:41:26PM +0530, Suraj Upadhyay wrote:
> On Fri, Jul 10, 2020 at 07:56:43PM +0200, Sam Ravnborg wrote:
> > Hi Suraj.
> >
> > On Tue, Jul 07, 2020 at 10:04:14PM +0530, Suraj Upadhyay wrote:
> > >
> > > This patchset converts logging to drm_* functions in drm cor
On boe_nv133fhm_n62 (and presumably on boe_nv133fhm_n61) a scope shows
a small spike on the HPD line right when you power the panel on. The
picture looks something like this:
+--
|
|
|
Power ---+
Hi Steve and others.
On Fri, Jul 10, 2020 at 06:40:26PM -0400, Steve Cohen wrote:
> BUG: KASAN: use-after-free in drm_gem_open_ioctl
>
> There is potential for use-after-free here if the GEM object
> handle is closed between the idr lookup and retrieving the size
> from the object since a local r
On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst wrote:
>
> Hi everybody,
>
> with the mentioned commit Nouveau isn't able to load firmware onto the
> GPU on one of my systems here. Even though the issue doesn't always
> happen I am quite confident this is the commit breaking it.
>
> I am still digging
On Wed, 2020-07-15 at 16:59 +0200, Thomas Zimmermann wrote:
> This patch adds support for G200 desktop cards. We can reuse the whole
> memory and modesetting code. A few PCI and DAC register values have to
> be updated accordingly.
>
> The most significant change is in the PLL setup. The get the c
Hi, Dave & Daniel:
This include converting mtk_dsi to drm_bridge API.
Regards,
Chun-Kuang.
The following changes since commit 5ab546f5e6309373aef01a8d398e163ab7a78431:
drm/mediatek: mtk_hdmi: Remove debug messages for function calls (2020-07-05
06:39:21 +0800)
are available in the Git repos
[+cc Sasha -- stable kernel regression]
[+cc Patrick, Kai-Heng, LKML]
On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst wrote:
> >
> > Hi everybody,
> >
> > with the mentioned commit Nouveau isn't able to load firmware onto the
> > GPU on
Hi all,
On Wed, 15 Jul 2020 at 12:57, Daniel Vetter wrote:
> On Wed, Jul 15, 2020 at 1:47 PM Daniel Stone wrote:
> > On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen
> > wrote:
> > > Yes, this is used as part of the Android stack on Chrome OS (need to
> > > see if ChromeOS specific, but
> > > h
On Fri, Jul 17, 2020 at 1:54 AM Bjorn Helgaas wrote:
>
> [+cc Sasha -- stable kernel regression]
> [+cc Patrick, Kai-Heng, LKML]
>
> On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> > On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst wrote:
> > >
> > > Hi everybody,
> > >
> > > with the
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: cefd5db37208da458fa10f83f866f2f37eef70e9
commit: 4a33206e976be79b832d5a826565b5cb430de877 [1066/1110] drm/amd/sriov
porting sriov cap to vcn3.0
config: parisc-randconfig-r015-20200717 (attached as .config)
compiler:
Hi Stefan,
On Thu, Jul 09, 2020 at 12:25:42PM +0200, Stefan Agner wrote:
> On 2020-06-16 03:50, Laurent Pinchart wrote:
> > On Thu, Jun 11, 2020 at 09:33:11PM +0200, Stefan Agner wrote:
> >> On 2020-05-30 05:10, Laurent Pinchart wrote:
> >> > The DRM simple display pipeline helper only supports a
Hi Christian,
On Mon, Jun 22, 2020 at 11:29:33AM +0200, Daniel Vetter wrote:
> On Mon, Jun 22, 2020 at 09:58:44AM +0200, Christian König wrote:
> > Am 21.06.20 um 04:07 schrieb Laurent Pinchart:
> > > Most of the DRM drivers uAPI headers are licensed under the MIT license,
> > > and carry copies o
Hi Linus,
Weekly fixes pull, big bigger than I'd normally like, but they are
fairly scattered and small individually. The vmwgfx one is a black
screen regression, otherwise the largest is an MST encoder fix for
amdgpu which results in a WARN in some cases, and a scattering of i915
fixes.
I'm trac
https://bugzilla.kernel.org/show_bug.cgi?id=208587
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #31 from Alex Deucher (alexdeuc...@gmail.com) ---
Duplicate of bug 207979.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-d
https://bugzilla.kernel.org/show_bug.cgi?id=208589
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
The pull request you sent on Fri, 17 Jul 2020 13:42:02 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-17-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8882572675c1bb1cc544f4e229a11661f1fc52e4
Thank you!
--
Deet-doot-dot, I am a bot.
https:/
Hi Lyude.
On Thu, Jul 16, 2020 at 06:43:40PM -0400, Lyude Paul wrote:
> On Wed, 2020-07-15 at 16:59 +0200, Thomas Zimmermann wrote:
> > This patch adds support for G200 desktop cards. We can reuse the whole
> > memory and modesetting code. A few PCI and DAC register values have to
> > be updated a
Hi Sam
Am 16.07.20 um 22:11 schrieb Sam Ravnborg:
> On Tue, Jul 14, 2020 at 10:32:38AM +0200, Thomas Zimmermann wrote:
>> Don't override the GEM object functions unconditionally. If the driver
>> sets the GEM functions, VRAM helpers will now them. The idea has been
> s/now/own
Ooops, I forgot a w
On Thu, Jul 16, 2020 at 05:03:33PM +0800, Qinglang Miao wrote:
> From: Liu Shixin
>
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Liu Shixin
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-
85 matches
Mail list logo
