Hi Tom,
Quick self intro: I have take over drivers/platform/x86
maintainership from Andy.
On 10/17/20 6:09 PM, t...@redhat.com wrote:
> From: Tom Rix
>
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal
Hi Sam,
On Sat, Oct 17, 2020 at 12:47:36PM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> On Sat, Oct 17, 2020 at 11:13:07AM +0200, Guido Günther wrote:
> > Hi Sam,
> > On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam Ravnborg wrote:
> > > Hi Guido.
> > > On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido G
Hi Caleb.
I have missed to provice review feedback so here goes.
There is some improvements that can be made as the infrastructure has
evolved since the driver was started.
But despite the number of comments below it is all trivial and the
driver looks good in general.
I look forward to see the n
Hi Guido
> On Sun, Oct 18, 2020 at 03:01:22PM +0200, Guido Günther wrote:
> Hi Sam,
> On Sat, Oct 17, 2020 at 12:47:36PM +0200, Sam Ravnborg wrote:
> > Hi Guido.
> >
> > On Sat, Oct 17, 2020 at 11:13:07AM +0200, Guido Günther wrote:
> > > Hi Sam,
> > > On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sa
On 10/17/20 10:43 PM, Greg KH wrote:
> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
>> From: Tom Rix
>>
>> This is a upcoming change to clean up a new warning treewide.
>> I am wondering if the change could be one mega patch (see below) or
>> normal patch per file about 100 p
On Sat, Oct 17, 2020 at 9:05 PM Jason Gunthorpe wrote:
>
> On Thu, Oct 15, 2020 at 03:02:45PM -0700, Jianxin Xiong wrote:
>
> > +static void ib_umem_dmabuf_invalidate_cb(struct dma_buf_attachment *attach)
> > +{
> > + struct ib_umem_dmabuf *umem_dmabuf = attach->importer_priv;
> > +
> > +
On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote:
> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > clang has a number of useful, new warnings see
> > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F9
Hi Dave,
It is a little urgent, so I am writing this right now.
As usual, I pulled in DRM repository code for an out of tree OpenChrome DRM
repository a few days ago.
While going through the changes I need to make to OpenChrome DRM to compile
with the latest Linux kernel, I noticed that ttm_bo_i
From: Daniel Vetter
[ Upstream commit 075342ea3d93044d68f821cf91c1a1a7d2fa569e ]
Gets rid of drmm_add_final_kfree, which I want to unexport so that it
stops confusion people about this transitional state of rolling drm
managed memory out.
This also fixes the missing drm_dev_put in the error pat
From: Neil Armstrong
[ Upstream commit 110003002291525bb209f47e6dbf121a63249a97 ]
The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM,
G12A/SM1 & G12B SoCs needs a quirk in the PWR registers at the GPU reset
time.
Since the Amlogic's integration of the GPU cores with the SoC is
From: Neil Armstrong
[ Upstream commit afcd0c7d3d4c22afc8befcfc906db6ce3058d3ee ]
This adds the required GPU quirks, including the quirk in the PWR
registers at the GPU reset time and the IOMMU quirk for shareability
issues observed on G52 in Amlogic G12B SoCs.
Signed-off-by: Neil Armstrong
Re
From: Neil Armstrong
[ Upstream commit 91e89097b86f566636ea5a7329c79d5521be46d2 ]
The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM,
G12A/SM1 & G12B SoCs needs a quirk in the PWR registers after each reset.
This adds a callback in the device compatible struct of permit this.
From: Jia Yang
[ Upstream commit da62cb7230f0871c30dc9789071f63229158d261 ]
I got a use-after-free report when doing some fuzz test:
If ttm_bo_init() fails, the "gbo" and "gbo->bo.base" will be
freed by ttm_buffer_object_destroy() in ttm_bo_init(). But
then drm_gem_vram_create() and drm_gem_vra
From: Zhenzhong Duan
[ Upstream commit 08d3ab4b46339bc6f97e83b54a3fb4f8bf8f4cd9 ]
It's allocating an array of a6xx_gpu_state_obj structure rathor than
its pointers.
This patch fix it.
Signed-off-by: Zhenzhong Duan
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/
From: Tian Tao
[ Upstream commit 13b0d4a9ae0c2d650993c48be797992eaf621332 ]
The memory used to be allocated with devres helpers and released
automatically. In rare circumstances, the memory's release could
have happened before the DRM device got released, which would have
caused memory corruptio
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/p
From: Navid Emamdoost
[ Upstream commit 9df0e0c1889677175037445d5ad1654d54176369 ]
in panfrost_perfcnt_enable_locked, pm_runtime_get_sync is called which
increments the counter even in case of failure, leading to incorrect
ref count. In case of failure, decrement the ref count before returning.
From: Qingqing Zhuo
[ Upstream commit ce271b40a91f781af3dee985c39e841ac5148766 ]
[why]
Current pipe merge and split logic only supports cases where new
dc_state is allocated and relies on dc->current_state to gather
information from previous dc_state.
Calls to validate_bandwidth on UPDATE_TYPE_
From: xinhui pan
[ Upstream commit 1545fbf97eafc1dbdc2923e58b4186b16a834784 ]
Remove the private obj from the internal list before we free aconnector.
[ 56.925828] BUG: unable to handle page fault for address: 8f84a870a560
[ 56.933272] #PF: supervisor read access in kernel mode
[ 56.9
From: Alvin Lee
[ Upstream commit 81b437f57e35a6caa3a4304e6fff0eba0a9f3266 ]
[Why]
When changing pixel formats for HDR (e.g. ARGB -> FP16)
there are configurations that change from 2 pipes to 1 pipe.
In these cases, it seems that disconnecting MPCC and doing
a surface update at the same time(aft
On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote:
> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > clang has a number of useful, new warnings see
> > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F9
From: Neil Armstrong
[ Upstream commit 91e89097b86f566636ea5a7329c79d5521be46d2 ]
The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM,
G12A/SM1 & G12B SoCs needs a quirk in the PWR registers after each reset.
This adds a callback in the device compatible struct of permit this.
From: Neil Armstrong
[ Upstream commit 110003002291525bb209f47e6dbf121a63249a97 ]
The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM,
G12A/SM1 & G12B SoCs needs a quirk in the PWR registers at the GPU reset
time.
Since the Amlogic's integration of the GPU cores with the SoC is
From: Neil Armstrong
[ Upstream commit afcd0c7d3d4c22afc8befcfc906db6ce3058d3ee ]
This adds the required GPU quirks, including the quirk in the PWR
registers at the GPU reset time and the IOMMU quirk for shareability
issues observed on G52 in Amlogic G12B SoCs.
Signed-off-by: Neil Armstrong
Re
From: Jia Yang
[ Upstream commit da62cb7230f0871c30dc9789071f63229158d261 ]
I got a use-after-free report when doing some fuzz test:
If ttm_bo_init() fails, the "gbo" and "gbo->bo.base" will be
freed by ttm_buffer_object_destroy() in ttm_bo_init(). But
then drm_gem_vram_create() and drm_gem_vra
From: Zhenzhong Duan
[ Upstream commit 08d3ab4b46339bc6f97e83b54a3fb4f8bf8f4cd9 ]
It's allocating an array of a6xx_gpu_state_obj structure rathor than
its pointers.
This patch fix it.
Signed-off-by: Zhenzhong Duan
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/
From: xinhui pan
[ Upstream commit 1545fbf97eafc1dbdc2923e58b4186b16a834784 ]
Remove the private obj from the internal list before we free aconnector.
[ 56.925828] BUG: unable to handle page fault for address: 8f84a870a560
[ 56.933272] #PF: supervisor read access in kernel mode
[ 56.9
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/p
From: Qingqing Zhuo
[ Upstream commit ce271b40a91f781af3dee985c39e841ac5148766 ]
[why]
Current pipe merge and split logic only supports cases where new
dc_state is allocated and relies on dc->current_state to gather
information from previous dc_state.
Calls to validate_bandwidth on UPDATE_TYPE_
From: Neil Armstrong
[ Upstream commit 110003002291525bb209f47e6dbf121a63249a97 ]
The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM,
G12A/SM1 & G12B SoCs needs a quirk in the PWR registers at the GPU reset
time.
Since the Amlogic's integration of the GPU cores with the SoC is
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/p
From: Zhenzhong Duan
[ Upstream commit 08d3ab4b46339bc6f97e83b54a3fb4f8bf8f4cd9 ]
It's allocating an array of a6xx_gpu_state_obj structure rathor than
its pointers.
This patch fix it.
Signed-off-by: Zhenzhong Duan
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/
From: xinhui pan
[ Upstream commit 1545fbf97eafc1dbdc2923e58b4186b16a834784 ]
Remove the private obj from the internal list before we free aconnector.
[ 56.925828] BUG: unable to handle page fault for address: 8f84a870a560
[ 56.933272] #PF: supervisor read access in kernel mode
[ 56.9
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/p
From: xinhui pan
[ Upstream commit 1545fbf97eafc1dbdc2923e58b4186b16a834784 ]
Remove the private obj from the internal list before we free aconnector.
[ 56.925828] BUG: unable to handle page fault for address: 8f84a870a560
[ 56.933272] #PF: supervisor read access in kernel mode
[ 56.9
On Sun, 2020-10-18 at 20:16 +0100, Matthew Wilcox wrote:
> On Sun, Oct 18, 2020 at 12:13:35PM -0700, James Bottomley wrote:
> > On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote:
> > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > > > clang has a number of useful, new w
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/p
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/p
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/p
On Mon, 19 Oct 2020 at 05:15, Kevin Brace wrote:
>
> Hi Dave,
>
> It is a little urgent, so I am writing this right now.
> As usual, I pulled in DRM repository code for an out of tree OpenChrome DRM
> repository a few days ago.
> While going through the changes I need to make to OpenChrome DRM to
Adding dri-devel too, not sure anyone is still listening on linux-fbdev.
On Sun, Oct 18, 2020 at 8:13 PM Peilin Ye wrote:
>
> Recently, in commit 6735b4632def ("Fonts: Support FONT_EXTRA_WORDS macros
> for built-in fonts"), we wrapped each of our built-in data buffers in a
> `font_data` structure
On Sun, Oct 18, 2020 at 10:09:06PM +0200, Daniel Vetter wrote:
> Adding dri-devel too, not sure anyone is still listening on linux-fbdev.
I see, thanks!
> On Sun, Oct 18, 2020 at 8:13 PM Peilin Ye wrote:
> >
> > Recently, in commit 6735b4632def ("Fonts: Support FONT_EXTRA_WORDS macros
> > for bu
On Sun, Oct 18, 2020 at 10:18 PM Peilin Ye wrote:
>
> On Sun, Oct 18, 2020 at 10:09:06PM +0200, Daniel Vetter wrote:
> > Adding dri-devel too, not sure anyone is still listening on linux-fbdev.
>
> I see, thanks!
>
> > On Sun, Oct 18, 2020 at 8:13 PM Peilin Ye wrote:
> > >
> > > Recently, in comm
On Sun, Oct 18, 2020 at 10:33:11PM +0200, Daniel Vetter wrote:
> On Sun, Oct 18, 2020 at 10:18 PM Peilin Ye wrote:
> > 2/2 is just updating the fb documentation:
> >
> > [PATCH 2/2] docs: fb: Add font_6x8 to available built-in fonts
> > https://lore.kernel.org/lkml/717bb41dda8e2ed615f3faadfbc3e215
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 01/13] drm/edid: A
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 02/13] drm/edid: P
Recently we added a new 6x8 font in commit e2028c8e6bf9 ("lib/fonts: add
font 6x8 for OLED display"). Add its name to the "compiled-in fonts"
list.
Signed-off-by: Peilin Ye
---
Resending +Cc: dri-devel, sorry if I spammed.
Documentation/fb/fbcon.rst | 2 +-
1 file changed, 1 insertion(+), 1 del
Hi Kevin.
On Sun, Oct 18, 2020 at 09:15:17PM +0200, Kevin Brace wrote:
> As usual, I pulled in DRM repository code for an out of tree OpenChrome DRM
> repository a few days ago.
I know you have been working on and off on the openchrome driver for a
long time now. Any chance we will see the drive
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 03/13] drm/dp_help
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 04/13] drm/i915: C
On Sun, Oct 18, 2020 at 10:45 PM Peilin Ye wrote:
>
> On Sun, Oct 18, 2020 at 10:33:11PM +0200, Daniel Vetter wrote:
> > On Sun, Oct 18, 2020 at 10:18 PM Peilin Ye wrote:
> > > 2/2 is just updating the fb documentation:
> > >
> > > [PATCH 2/2] docs: fb: Add font_6x8 to available built-in fonts
>
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 05/13] drm/i915: A
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 06/13] drm/i915: C
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 07/13] drm/dp_helpe
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 08/13] drm/i915: Ad
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 09/13] drm/edid: P
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 10/13] drm/dp_help
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 11/13] drm/i915: R
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, October 19, 2020 5:02 AM
> To: Nautiyal, Ankit K ; intel-
> g...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Kulkarni, Vandita
> ; ville.syrj...@linux.intel.com; Sharma, Swati2
>
> Subject: RE: [RFC 11/13] drm/i9
Hello all,
Regarding amdgpu, I've been using some Radeon 5700XTs for compute work with
kernels through 5.8.14. I recently tried kernel 5.9.0, and found that the
following is no longer allowed:
echo "m 1 200" | sudo tee /sys/class/drm/card0/device/pp_od_clk_voltage
Is this an expected change? I
Hi Marek,
Thank you for the patch.
On Sat, Oct 03, 2020 at 01:08:23AM +0200, Marek Vasut wrote:
> The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
> select input pixel data sampling edge. Add DT property "pixelclk-active",
> same as the one used by display timings, and co
Hi Linus,
Some fixes queued up already for i915 and amdgpu, I've also included
the fix for the clang warning you've seen.
Dave.
drm-next-2020-10-19:
drm fixes for 5.10-rc1
i915:
- Set all unused color plane offsets to ~0xfff again (Ville)
- Fix TGL DKL PHY DP vswing handling (Ville)
amdgpu:
-
> -Original Message-
> From: Jason Gunthorpe
> Sent: Friday, October 16, 2020 6:05 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
>
> Subject: Re: [PATCH
20. 10. 9. 오후 10:05에 Marek Szyprowski 이(가) 쓴 글:
> Add clock configuration for 154MHz pixelclock to Exynos542x HDMIPHY,
> which is required for 1920x1200@60Hz mode. The PLL configuration data
> has been taken from the vendor's kernel tree for the Odroid XU4 board.
Merged.
Thanks,
Inki Dae
>
>
64 matches
Mail list logo
