On Mon, 5 Oct 2020 at 08:44, Tomeu Vizoso wrote:
>
> On Fri, 19 Jun 2020 at 11:00, Steven Price wrote:
> >
> > On 11/06/2020 09:58, Tomeu Vizoso wrote:
> > > Mesa now supports some Bifrost devices, so enable it.
> > >
> > > Signed-off-by: Tomeu Vizoso
> >
> > Reviewed-by: Steven Price
> >
> > I
Besides the intended change, commit 3437f5f6c979 ("drm/amdgpu: add gfx
support for van gogh (v2)") also set the source files gfx_v10_0.c to be
executable, i.e., changed from old mode 644 to new mode 755.
Set to the usual mode for source and headers files. No functional change.
Signed-off-by: Luka
On 10/2/20 4:03 PM, Douglas Anderson wrote:
> On some panels hooked up to the ti-sn65dsi86 bridge chip we found that
> link training was failing. Specifically, we'd see:
>
> ti_sn65dsi86 2-002d: [drm:ti_sn_bridge_enable] *ERROR* Link training
> failed, link is off (-5)
>
> The panel was hooked
Set link rate by using OPP set rate api so that CX level will be set
accordingly based on the link rate.
Changes in v2:
-- remove dev from dp_ctrl_put() parameters
-- address review comments
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 26 +
drivers/gpu/
On Sat, Oct 03, 2020 at 11:40:22AM +0200, Daniel Vetter wrote:
> > That leaves the only interesting places as vb2_dc_get_userptr() and
> > vb2_vmalloc_get_userptr() which both completely fail to follow the
> > REQUIRED behavior in the function's comment about checking PTEs. It
> > just DMA maps th
On 2020-09-30 09:24, Rajendra Nayak wrote:
On 9/30/2020 1:54 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2020-09-29 10:10:26)
Set link rate by using OPP set rate api so that CX level will be set
accordingly base on the link rate.
s/base/based/
Signed-off-by: Kuogee Hsieh
---
diff --git
NXP's i.MX8MM has an LCDIF as well.
Signed-off-by: Marek Vasut
Cc: Fabio Estevam
Cc: Guido Günther
Cc: Lucas Stach
Cc: NXP Linux Team
Cc: Rob Herring
Cc: Shawn Guo
---
Documentation/devicetree/bindings/display/mxsfb.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devi
Hi,
Le dim. 4 oct. 2020 à 21:59, Sam Ravnborg a écrit :
Hi Paul.
On Sun, Oct 04, 2020 at 04:17:58PM +0200, Paul Cercueil wrote:
This reverts commit 37054fc81443cc6a8c3a38395f384412b8373d82.
In the changelog please refer to commits like this:
37054fc81443 ("gpu/drm: ingenic: Add option to m
On 28-08-20, 11:37, Viresh Kumar wrote:
> dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
> find the OPP table with error -ENODEV (i.e. OPP table not present for
> the device). And we can call dev_pm_opp_of_remove_table()
> unconditionally here.
>
> While at it, also create
The only usage of dw_hdmi_i2s_ops is to assign its address to the ops
field in the hdmi_codec_pdata struct, which is a const pointer. Make it
const to allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 2 +-
This reverts commit 37054fc81443cc6a8c3a38395f384412b8373d82.
At the very moment this commit was created, the DMA API it relied on was
modified in the DMA tree, which caused the driver to break in
linux-next.
Revert it for now, and it will be resubmitted later to work with the new
DMA API.
Signe
From: Douglas AndersonSent: Friday, October 2, 2020 4:04 PMTo: Andrzej Hajda; Neil Armstrong; Sam RavnborgCc: Rob Clark; Bjorn Andersson; Steev Klimaszewski; Douglas Anderson; Daniel Vetter; David Airlie; Jernej Skrabec; Jonas Karlman; Laurent Pinchart; dri-devel@lists.freedesktop.org; linux-ker.
On Sat, Oct 03, 2020 at 03:52:32PM -0700, John Hubbard wrote:
> On 10/3/20 2:45 AM, Daniel Vetter wrote:
> > On Sat, Oct 3, 2020 at 12:39 AM John Hubbard wrote:
> > >
> > > On 10/2/20 10:53 AM, Daniel Vetter wrote:
> > > > For $reasons I've stumbled over this code and I'm not sure the change
> >
On Fri, 02 Oct 2020, Rob Herring wrote:
> Another round of wack-a-mole. The json-schema default is additional
> unknown properties are allowed, but for DT all properties should be
> defined.
>
> Cc: Thierry Reding
> Cc: Linus Walleij
> Cc: Stephen Boyd
> Cc: Shawn Guo
> Cc: Bjorn Andersson
>
Hi Robin, Neil,
On Wed, 16 Sep 2020 10:26:43 +0200
Neil Armstrong wrote:
> Hi Robin,
>
> On 16/09/2020 01:51, Robin Murphy wrote:
> > According to a downstream commit I found in the Khadas vendor kernel,
> > the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows
> > how to handle
On Mon, 5 Oct 2020 09:34:06 +0100
Steven Price wrote:
> On 05/10/2020 09:15, Boris Brezillon wrote:
> > Hi Robin, Neil,
> >
> > On Wed, 16 Sep 2020 10:26:43 +0200
> > Neil Armstrong wrote:
> >
> >> Hi Robin,
> >>
> >> On 16/09/2020 01:51, Robin Murphy wrote:
> >>> According to a downstream
On 05/10/2020 09:15, Boris Brezillon wrote:
Hi Robin, Neil,
On Wed, 16 Sep 2020 10:26:43 +0200
Neil Armstrong wrote:
Hi Robin,
On 16/09/2020 01:51, Robin Murphy wrote:
According to a downstream commit I found in the Khadas vendor kernel,
the GPU on G12b is wired up for ACE-lite, so (now tha
On 05/10/2020 09:39, Boris Brezillon wrote:
On Mon, 5 Oct 2020 09:34:06 +0100
Steven Price wrote:
On 05/10/2020 09:15, Boris Brezillon wrote:
Hi Robin, Neil,
On Wed, 16 Sep 2020 10:26:43 +0200
Neil Armstrong wrote:
Hi Robin,
On 16/09/2020 01:51, Robin Murphy wrote:
According to a dow
On Fri, Oct 02, 2020 at 06:41:43PM -0500, Rob Herring wrote:
[...]
> .../arm/tegra/nvidia,tegra20-pmc.yaml | 2 ++
[...]
> .../bindings/sound/nvidia,tegra186-dspk.yaml | 2 ++
> .../sound/nvidia,tegra210-admaif.yaml | 2 ++
> .../bindings/sound/nvidia,tegra210-dmic.yaml | 2 +
Hi Jianxin,
Am 04.10.20 um 21:12 schrieb Jianxin Xiong:
Dma-buf is a standard cross-driver buffer sharing mechanism that can be
used to support peer-to-peer access from RDMA devices.
Device memory exported via dma-buf is associated with a file descriptor.
This is passed to the user space as a p
On Fri, Oct 02, 2020 at 06:41:43PM -0500, Rob Herring wrote:
> Another round of wack-a-mole. The json-schema default is additional
> unknown properties are allowed, but for DT all properties should be
> defined.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
Hi Paul,
On Sun, 04 Oct 2020 22:11:23 +0200 Paul Cercueil wrote:
>
> Pushed to drm-misc-next with the changelog fix, thanks.
>
> Stephen:
> Now it should build fine again. Could you remove the BROKEN flag?
Thanks for letting me know, but the fix has not appeared in any drm
tree included in linu
On Fri, Oct 02, 2020 at 10:55:52AM -0700, Rob Clark wrote:
> On Fri, Oct 2, 2020 at 4:05 AM Ville Syrjälä
> wrote:
> >
> > On Fri, Oct 02, 2020 at 01:52:56PM +0300, Ville Syrjälä wrote:
> > > On Thu, Oct 01, 2020 at 05:25:55PM +0200, Daniel Vetter wrote:
> > > > On Thu, Oct 1, 2020 at 5:15 PM Rob
Ping? Bunch of trivial cleanups and removal of the caching placement flags.
Any comments on this?
Thanks,
Christian.
Am 01.10.20 um 13:28 schrieb Christian König:
Not used any more.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_tt.h | 1 -
1 file changed, 1 deletion(-)
diff --gi
On Sat, Oct 03, 2020 at 04:58:51AM +, Chrisanthus, Anitha wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter
> > Sent: Friday, October 2, 2020 2:19 AM
> > To: Chrisanthus, Anitha
> > Cc: dri-devel@lists.freedesktop.org; Paauwe, Bob J
> > ; Dea, Edmund J ;
> > Vetter, Daniel
On Wed, 30 Sep 2020 17:35:31 -0500, Bjorn Andersson wrote:
> While the signal on GPIO4 to drive the backlight controller indeed is
> pulse width modulated its purpose is specifically to control the
> brightness of a backlight.
>
> Drop the #pwm-cells and instead expose a new property to configure
On Sat, Oct 03, 2020 at 12:39:28PM -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> clang static analysis reports this problem:
>
> cdv_intel_dp.c:2101:2: warning: Attempt to free released memory
> kfree(gma_connector);
> ^~~~
>
> In cdv_intel_dp_init() when the
On Sun, Oct 04, 2020 at 12:21:39PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Before we remove dev->struct_mutex from the retire path, we have to deal
> with the situation of a submit retiring before the submit ioctl returns.
>
> To deal with this, ring->submits will hold a reference to the s
On Mon, Oct 05, 2020 at 05:24:19PM +0800, Hillf Danton wrote:
>
> On Sun, 4 Oct 2020 12:21:45
> > From: Rob Clark
> >
> > Now that the inactive_list is protected by mm_lock, and everything
> > else on per-obj basis is protected by obj->lock, we no longer depend
> > on struct_mutex.
> >
> > Sig
On Mon, Oct 05, 2020 at 11:01:50PM +1100, Stephen Rothwell wrote:
> Hi Paul,
>
> On Sun, 04 Oct 2020 22:11:23 +0200 Paul Cercueil wrote:
> >
> > Pushed to drm-misc-next with the changelog fix, thanks.
> >
> > Stephen:
> > Now it should build fine again. Could you remove the BROKEN flag?
>
> Tha
On Sun, Oct 04, 2020 at 10:06:53PM +0200, Rikard Falkeborn wrote:
> The only usage of dw_hdmi_i2s_ops is to assign its address to the ops
> field in the hdmi_codec_pdata struct, which is a const pointer. Make it
> const to allow the compiler to put it in read-only memory.
>
> Signed-off-by: Rikard
On Mon, Oct 05, 2020 at 03:15:24PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 02, 2020 at 10:55:52AM -0700, Rob Clark wrote:
> > On Fri, Oct 2, 2020 at 4:05 AM Ville Syrjälä
> > wrote:
> > >
> > > On Fri, Oct 02, 2020 at 01:52:56PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Oct 01, 2020 at 05:25:5
On Sun, Oct 04, 2020 at 12:21:34PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> It is somewhat redundant with the gpu tracepoints, and anyways not too
> useful to justify spamming the log when debug traces are enabled.
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gp
On Sun, Oct 04, 2020 at 12:21:35PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Small cleanup, update_fences() is used in the hangcheck path, but also
> in the normal retire path.
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 28 ++
On Sun, Oct 04, 2020 at 12:21:36PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Rather than relying on the big dev->struct_mutex hammer, introduce a
> more specific lock for protecting the bo lists.
Most excellent.
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/d
On Sun, Oct 04, 2020 at 12:21:37PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Before adding another lock, give ring->lock a more descriptive name.
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 ++--
> drivers/gpu/drm/msm/adren
On Sun, Oct 04, 2020 at 12:21:38PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> One less place to rely on dev->struct_mutex.
>
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gem_submit.c | 2 ++
> drivers/gpu/drm/msm/msm_gpu.c| 37 +++
Make it more clear what the resource manager function
does and nuke the wrapper function.
v2: nuke the wrapper
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 5 -
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ob
W dniu 04.10.2020 o 21:14, Sam Ravnborg pisze:
> Hi Marek.
>
> On Wed, Sep 30, 2020 at 01:40:42PM +0200, Marek Szyprowski wrote:
>> This patch restores DRM connector registration in the TC358764 bridge
>> driver and restores usage of the old drm_panel_* API, thus allows dynamic
>> panel registrati
On Sun, Oct 04, 2020 at 12:21:39PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Before we remove dev->struct_mutex from the retire path, we have to deal
> with the situation of a submit retiring before the submit ioctl returns.
>
> To deal with this, ring->submits will hold a reference to the s
On Sun, Oct 04, 2020 at 12:21:40PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> It cannot be atomically updated with obj->active_count, and the only
> purpose is a useless WARN_ON() (which becomes a buggy WARN_ON() once
> retire_submits() is not serialized with incoming submits via
> struct_mute
On Mon, Oct 5, 2020 at 10:19 PM Maxime Ripard wrote:
>
> Hi Chen-Yu,
>
> Sorry for the delay
>
> On Sat, Aug 29, 2020 at 02:43:53PM +0800, Chen-Yu Tsai wrote:
> > > +static int sun4i_tcon_register_panel(struct drm_device *drm,
> > > +struct sun4i_tcon *tcon)
> >
On Sun, Oct 04, 2020 at 12:21:41PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Now that we are not relying on dev->struct_mutex to protect the
> ring->submits lists, drop the struct_mutex lock.
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 8
Am 02.10.20 um 14:31 schrieb Daniel Vetter:
On Fri, Oct 2, 2020 at 1:31 PM Christian König
wrote:
Amdgpu was the only user of this.
Signed-off-by: Christian König
Uh this smells like a fishy band-aid. And the original commit
introducing this also doesn't sched any light on why this should
ha
From: Philip Yang
[ Upstream commit 1d0e16ac1a9e800598dcfa5b6bc53b704a103390 ]
Set ttm->sg to NULL after kfree, to avoid memory corruption backtrace:
[ 420.932812] kernel BUG at
/build/linux-do9eLF/linux-4.15.0/mm/slub.c:295!
[ 420.934182] invalid opcode: [#1] SMP NOPTI
[ 420.935445] Mo
From: Sudheesh Mavila
[ Upstream commit 97cf32996c46d9935cc133d910a75fb687dd6144 ]
SMU10_UMD_PSTATE_PEAK_FCLK value should not be used to set the DPM.
Suggested-by: Evan Quan
Reviewed-by: Evan Quan
Signed-off-by: Sudheesh Mavila
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
d
From: Philip Yang
[ Upstream commit 1d0e16ac1a9e800598dcfa5b6bc53b704a103390 ]
Set ttm->sg to NULL after kfree, to avoid memory corruption backtrace:
[ 420.932812] kernel BUG at
/build/linux-do9eLF/linux-4.15.0/mm/slub.c:295!
[ 420.934182] invalid opcode: [#1] SMP NOPTI
[ 420.935445] Mo
From: Flora Cui
[ Upstream commit 898c7302f4de1d91065e80fc46552b3ec70894ff ]
max_caps might be 0, thus hdcp_work might be ZERO_SIZE_PTR
Signed-off-by: Flora Cui
Reviewed-by: Feifei Xu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm
From: Philip Yang
[ Upstream commit 1d0e16ac1a9e800598dcfa5b6bc53b704a103390 ]
Set ttm->sg to NULL after kfree, to avoid memory corruption backtrace:
[ 420.932812] kernel BUG at
/build/linux-do9eLF/linux-4.15.0/mm/slub.c:295!
[ 420.934182] invalid opcode: [#1] SMP NOPTI
[ 420.935445] Mo
From: Zack Rusin
[ Upstream commit f54c4442893b8dfbd3aff8e903c54dfff1aef990 ]
ttm_mem_type_manager_func.get_node was changed to return -ENOSPC
instead of setting the node pointer to NULL. Unfortunately
vmwgfx still had two places where it was explicitly converting
-ENOSPC to 0 causing regression
From: Philip Yang
[ Upstream commit 1d0e16ac1a9e800598dcfa5b6bc53b704a103390 ]
Set ttm->sg to NULL after kfree, to avoid memory corruption backtrace:
[ 420.932812] kernel BUG at
/build/linux-do9eLF/linux-4.15.0/mm/slub.c:295!
[ 420.934182] invalid opcode: [#1] SMP NOPTI
[ 420.935445] Mo
From: Philip Yang
[ Upstream commit 1d0e16ac1a9e800598dcfa5b6bc53b704a103390 ]
Set ttm->sg to NULL after kfree, to avoid memory corruption backtrace:
[ 420.932812] kernel BUG at
/build/linux-do9eLF/linux-4.15.0/mm/slub.c:295!
[ 420.934182] invalid opcode: [#1] SMP NOPTI
[ 420.935445] Mo
On Tue, 22 Sep 2020 15:16:48 +0100
Robin Murphy wrote:
> Midgard GPUs have ACE-Lite master interfaces which allows systems to
> integrate them in an I/O-coherent manner. It seems that from the GPU's
> viewpoint, the rest of the system is its outer shareable domain, and so
> even when snoop signal
On Mon, Oct 5, 2020 at 4:37 PM Christian König
wrote:
>
> Am 02.10.20 um 14:31 schrieb Daniel Vetter:
> > On Fri, Oct 2, 2020 at 1:31 PM Christian König
> > wrote:
> >> Amdgpu was the only user of this.
> >>
> >> Signed-off-by: Christian König
> > Uh this smells like a fishy band-aid. And the or
Hi!
On Fri 02-10-20 15:06:03, Jason Gunthorpe wrote:
> This get_vaddr_frames() thing looks impossible to use properly. How on
> earth does a driver guarentee
>
> "If @start belongs to VM_IO | VM_PFNMAP vma, we don't touch page
> structures and the caller must make sure pfns aren't reused for
>
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 1/8] drm/ttm: remove TTM_PAGE_FLAG_WRITE
>
>Not used any more.
Reviewe
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 2/8] drm/ttm: move ttm_set_memory.h out of include
>
>This is not someth
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 3/8] drm/ttm: cleanup ttm_handle_caching_state_failure
>
>Remove unuse
On 05/10/2020 15:50, Boris Brezillon wrote:
On Tue, 22 Sep 2020 15:16:48 +0100
Robin Murphy wrote:
Midgard GPUs have ACE-Lite master interfaces which allows systems to
integrate them in an I/O-coherent manner. It seems that from the GPU's
viewpoint, the rest of the system is its outer shareabl
On Mon, Oct 5, 2020 at 4:27 PM Christian König
wrote:
>
> Make it more clear what the resource manager function
> does and nuke the wrapper function.
>
> v2: nuke the wrapper
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
I think adding a bdev back pointer to res_man would be ni
On Fri, Oct 02, 2020 at 06:41:43PM -0500, Rob Herring wrote:
> Another round of wack-a-mole. The json-schema default is additional
> unknown properties are allowed, but for DT all properties should be
> defined.
>
> Signed-off-by: Rob Herring
> ---
>
> I'll take this thru the DT tree.
>
> [...
On Mon, 5 Oct 2020 16:16:32 +0100
Steven Price wrote:
> On 05/10/2020 15:50, Boris Brezillon wrote:
> > On Tue, 22 Sep 2020 15:16:48 +0100
> > Robin Murphy wrote:
> >
> >> Midgard GPUs have ACE-Lite master interfaces which allows systems to
> >> integrate them in an I/O-coherent manner. It se
Not entirely sure how the patches for autosel were selected, but this
patch is no good for 5.8, since the patch which introduced the breakage
in the first place is only in 5.9 (in particular it was
58e4d686d456c3e356439ae160ff4a0728940b8e, drm/ttm: cleanup
ttm_mem_type_manager_func.get_node interfa
On Mon, Oct 5, 2020 at 4:02 PM Daniel Vetter wrote:
>
> On Mon, Oct 05, 2020 at 05:24:19PM +0800, Hillf Danton wrote:
> >
> > On Sun, 4 Oct 2020 12:21:45
> > > From: Rob Clark
> > >
> > > Now that the inactive_list is protected by mm_lock, and everything
> > > else on per-obj basis is protected
> -Original Message-
> From: Jason Gunthorpe
> Sent: Monday, October 05, 2020 6:13 AM
> 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: [RFC PA
On Mon, Oct 5, 2020 at 6:56 AM Daniel Vetter wrote:
>
> On Sun, Oct 04, 2020 at 12:21:39PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Before we remove dev->struct_mutex from the retire path, we have to deal
> > with the situation of a submit retiring before the submit ioctl returns.
> >
On Sun, Oct 4, 2020 at 9:21 PM Rob Clark wrote:
>
> From: Rob Clark
>
> This doesn't remove *all* the struct_mutex, but it covers the worst
> of it, ie. shrinker/madvise/free/retire. The submit path still uses
> struct_mutex, but it still needs *something* serialize a portion of
> the submit pat
On Mon, Oct 5, 2020 at 7:02 AM Daniel Vetter wrote:
>
> On Mon, Oct 05, 2020 at 05:24:19PM +0800, Hillf Danton wrote:
> >
> > On Sun, 4 Oct 2020 12:21:45
> > > From: Rob Clark
> > >
> > > Now that the inactive_list is protected by mm_lock, and everything
> > > else on per-obj basis is protected
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 6/8] drm/ttm: add caching state to ttm_bus_placement
>
>And implement se
On Mon, Oct 5, 2020 at 4:47 PM Paul Cercueil wrote:
>
> Hi,
>
> Le lun. 5 oct. 2020 à 16:05, Daniel Vetter a écrit :
> > On Mon, Oct 05, 2020 at 11:01:50PM +1100, Stephen Rothwell wrote:
> >> Hi Paul,
> >>
> >> On Sun, 04 Oct 2020 22:11:23 +0200 Paul Cercueil
> >> wrote:
> >> >
> >> > Pushed
On Mon 05-10-20 14:38:54, Jason Gunthorpe wrote:
> When get_vaddr_frames() does its hacky follow_pfn() loop it should never
> be allowed to extract a struct page from a normal VMA. This could allow a
> serious use-after-free problem on any kernel memory.
>
> Restrict this to only work on VMA's wit
On Mon, Oct 5, 2020 at 7:58 PM Jason Gunthorpe wrote:
>
> On Mon, Oct 05, 2020 at 07:53:08PM +0200, Jan Kara wrote:
> > On Mon 05-10-20 14:38:54, Jason Gunthorpe wrote:
> > > When get_vaddr_frames() does its hacky follow_pfn() loop it should never
> > > be allowed to extract a struct page from a n
On Mon, Oct 5, 2020 at 7:28 PM Jason Gunthorpe wrote:
>
> On Sun, Oct 04, 2020 at 06:09:29PM +0200, Daniel Vetter wrote:
> > On Sun, Oct 4, 2020 at 2:51 PM Jason Gunthorpe wrote:
> > >
> > > On Sat, Oct 03, 2020 at 11:40:22AM +0200, Daniel Vetter wrote:
> > >
> > > > > That leaves the only intere
On Mon, Oct 5, 2020 at 6:49 PM Rob Clark wrote:
>
> On Mon, Oct 5, 2020 at 7:02 AM Daniel Vetter wrote:
> >
> > On Mon, Oct 05, 2020 at 05:24:19PM +0800, Hillf Danton wrote:
> > >
> > > On Sun, 4 Oct 2020 12:21:45
> > > > From: Rob Clark
> > > >
> > > > Now that the inactive_list is protected b
On Mon, Oct 5, 2020 at 6:24 PM Kristian Høgsberg wrote:
>
> On Sun, Oct 4, 2020 at 9:21 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > This doesn't remove *all* the struct_mutex, but it covers the worst
> > of it, ie. shrinker/madvise/free/retire. The submit path still uses
> > struct_mute
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 7/8] drm/ttm: use caching instead of placement for
>ttm_io_prot
>
>Inste
The default behavior for json-schema is any unknown property is allowed.
That is generally not the behavior we want for DT. In order to disallow
extra properties, schemas need to define 'additionalProperties: false'
typically. Ideally, we'd just add that automatically with the tools, but
there are
In order to add meta-schema checks for additional/unevaluatedProperties
being present, all schema need to make this explicit. As the top-level
board/SoC schemas always have additional properties, add
'additionalProperties: true'.
Signed-off-by: Rob Herring
---
Documentation/devicetree/bindings/a
In cases where we don't reference another schema, 'additionalProperties'
can be used instead. This is preferred for now as 'unevaluatedProperties'
support isn't implemented yet.
In a few cases, this means adding some missing property definitions of
which most are for SPI bus properties. 'unevaluat
This doesn't yet do anything in the tools, but make it explicit so we can
check either 'unevaluatedProperties' or 'additionalProperties' is present
in schemas.
'unevaluatedProperties' is appropriate when including another schema (via
'$ref') and all possible properties and/or child nodes are not
e
In order to add meta-schema checks for additional/unevaluatedProperties
being present, all schema need to make this explicit. As common/shared
schema are included by other schemas, they should always allow for
additionalProperties.
Signed-off-by: Rob Herring
---
Documentation/devicetree/bindings
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 8/8] drm/ttm: nuke caching placement flags
>
>Changing the caching on th
Patch series covers following thigns:
1. Split and differentiate between EHL and JSL platfrom
2. Update voltage swing table for eDP on JSL platform
Changes since V3 :
- Changed IS_EHL_JSL to IS_JSL_EHL
- Renamed IS_EHL_REVID to IS_JSL_EHL_REVID
- Reverted removal of IS_ELK
Split the basic platform definition, macros, and PCI IDs to
differentiate between EHL and JSL platforms.
Changes since V3 :
- Changed IS_EHL_JSL to IS_JSL_EHL
- Renamed IS_EHL_REVID to IS_JSL_EHL_REVID
- Reverted removal of IS_ELKHARTLAKE and also
added IS_JASPERL
JSL has update in vswing table for eDP.
BSpec: 21257
Changes since V3 :
- Changed IS_EHL_JSL to IS_JSL_EH
- Reverted removal of IS_ELKHARTLAKE and also
added IS_JASPERLAKE
- Corrected mistake of using IS_ELKHARTLAKE twice and
missing IS_JASPERLAKE
On Mon, Oct 5, 2020 at 8:37 PM Jason Gunthorpe wrote:
>
> On Mon, Oct 05, 2020 at 08:16:33PM +0200, Daniel Vetter wrote:
>
> > > kvm is some similar hack added for P2P DMA, see commit
> > > add6a0cd1c5ba51b201e1361b05a5df817083618. It might be protected by
> > > notifiers..
> >
> > Yeah my thinki
Split the basic platform definition, macros, and PCI IDs to
differentiate between EHL and JSL platforms.
Changes since V3 :
- Changed IS_EHL_JSL to IS_JSL_EHL
- Renamed IS_EHL_REVID to IS_JSL_EHL_REVID
- Reverted removal of IS_ELKHARTLAKE and also
added IS_JASPERL
Patch series covers following thigns:
1. Split and differentiate between EHL and JSL platfrom
2. Update voltage swing table for eDP on JSL platform
Changes since V3 :
- Changed IS_EHL_JSL to IS_JSL_EHL
- Renamed IS_EHL_REVID to IS_JSL_EHL_REVID
- Reverted removal of IS_ELK
JSL has update in vswing table for eDP.
BSpec: 21257
Changes since V3 :
- Changed IS_EHL_JSL to IS_JSL_EH
- Reverted removal of IS_ELKHARTLAKE and also
added IS_JASPERLAKE
- Corrected mistake of using IS_ELKHARTLAKE twice and
missing IS_JASPERLAKE
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 4/8] drm/ttm: rename TTM caching enum
>
>Cleanup the enum name and its v
On Mon, Oct 5, 2020 at 3:22 AM Lukas Bulwahn wrote:
>
> Besides the intended change, commit 3437f5f6c979 ("drm/amdgpu: add gfx
> support for van gogh (v2)") also set the source files gfx_v10_0.c to be
> executable, i.e., changed from old mode 644 to new mode 755.
>
> Set to the usual mode for sour
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 5/8] drm/ttm: set the tt caching state at creation time
>
>All drivers c
> -Original Message-
> From: Christian König
> Sent: Monday, October 05, 2020 3:55 AM
> To: Xiong, Jianxin ; linux-r...@vger.kernel.org;
> dri-devel@lists.freedesktop.org
> Cc: Doug Ledford ; Jason Gunthorpe ; Leon
> Romanovsky ; Sumit Semwal
> ; Vetter, Daniel
> Subject: Re: [RFC PATCH
On Mon, Oct 05, 2020 at 01:38:27PM -0500, Rob Herring wrote:
> This doesn't yet do anything in the tools, but make it explicit so we can
> check either 'unevaluatedProperties' or 'additionalProperties' is present
> in schemas.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
__
On Mon, Oct 05, 2020 at 01:38:28PM -0500, Rob Herring wrote:
> In cases where we don't reference another schema, 'additionalProperties'
> can be used instead. This is preferred for now as 'unevaluatedProperties'
> support isn't implemented yet.
Acked-by: Mark Brown
signature.asc
Description: PG
On Mon, Oct 05, 2020 at 01:38:30PM -0500, Rob Herring wrote:
> In order to add meta-schema checks for additional/unevaluatedProperties
> being present, all schema need to make this explicit. As common/shared
> schema are included by other schemas, they should always allow for
> additionalProperties
> -Original Message-
> From: Jason Gunthorpe
> Sent: Monday, October 05, 2020 9:33 AM
> 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: [RFC
On Mon, Oct 05, 2020 at 01:38:27PM -0500, Rob Herring wrote:
> This doesn't yet do anything in the tools, but make it explicit so we can
> check either 'unevaluatedProperties' or 'additionalProperties' is present
> in schemas.
>
> 'unevaluatedProperties' is appropriate when including another schem
On Mon, Oct 05, 2020 at 01:38:27PM -0500, Rob Herring wrote:
> This doesn't yet do anything in the tools, but make it explicit so we can
> check either 'unevaluatedProperties' or 'additionalProperties' is present
> in schemas.
>
> 'unevaluatedProperties' is appropriate when including another schem
On Mon, Oct 05, 2020 at 01:38:28PM -0500, Rob Herring wrote:
> In cases where we don't reference another schema, 'additionalProperties'
> can be used instead. This is preferred for now as 'unevaluatedProperties'
> support isn't implemented yet.
>
> In a few cases, this means adding some missing pr
1 - 100 of 128 matches
Mail list logo
