Two in one go:
- it is allowed to call dma_fence_wait() while holding a
dma_resv_lock(). This is fundamental to how eviction works with ttm,
so required.
- it is allowed to call dma_fence_wait() from memory reclaim contexts,
specifically from shrinker callbacks (which i915 does), and from mm
Hi Thomas
On Fri, Jun 12, 2020 at 08:28:40AM +0200, Thomas Zimmermann wrote:
> Hi Sam
>
> Am 11.06.20 um 21:24 schrieb Sam Ravnborg:
> > Hi Thomas.
> > On Thu, Jun 11, 2020 at 10:28:09AM +0200, Thomas Zimmermann wrote:
> >> Converts the ast driver to drm_info() and drm_err(). No functional
> >> c
Just some tiny edits:
- fix link to struct dma_fence
- give slightly more meaningful title - the polling here is about
implicit fences, explicit fences (in sync_file or drm_syncobj) also
have their own polling
v2: I misplaced the .rst include change corresponding to this patch.
Reviewed-by: T
Design is similar to the lockdep annotations for workers, but with
some twists:
- We use a read-lock for the execution/worker/completion side, so that
this explicit annotation can be more liberally sprinkled around.
With read locks lockdep isn't going to complain if the read-side
isn't neste
Hi
Am 12.06.20 um 09:01 schrieb Sam Ravnborg:
> Hi Thomas
>
> On Fri, Jun 12, 2020 at 08:28:40AM +0200, Thomas Zimmermann wrote:
>> Hi Sam
>>
>> Am 11.06.20 um 21:24 schrieb Sam Ravnborg:
>>> Hi Thomas.
>>> On Thu, Jun 11, 2020 at 10:28:09AM +0200, Thomas Zimmermann wrote:
Converts the ast d
Hi
Am 12.06.20 um 03:36 schrieb Gurchetan Singh:
> This is useful for the next patch. Also, should we only unmap the
> amount entries that we mapped with the dma-api?
It looks like you're moving virtio code into shmem. It would be nice to
have a cover letter explaining the series.
>
> Signed-o
On Fri, Jun 12, 2020 at 11:37:33AM +0200, Markus Elfring wrote:
> > In fucntin msm_submitqueue_create, the queue is a local
> > variable, in return -EINVAL branch, queue didn`t add to ctx`s
> > list yet, and also didn`t kfree, this maybe bring in potential
> > memleak.
>
> I suggest to improve als
On Fri, Jun 12, 2020 at 09:36:09AM +0200, Markus Elfring wrote:
> > Function msm_gpu_crashstate_capture maybe called for several
> > times, and then the state->bos is a potential memleak. Also
> > the state->pos maybe alloc failed, but now without any handle.
> > This change is to fix some potentia
On Fri, Jun 12, 2020 at 11:47:55AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 12.06.20 um 03:36 schrieb Gurchetan Singh:
> > This is useful for the next patch. Also, should we only unmap the
> > amount entries that we mapped with the dma-api?
>
> It looks like you're moving virtio code into shm
On Wed, Jun 10, 2020 at 9:38 AM kernel test robot wrote:
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on drm-exynos/exynos-drm-next]
> [also build test WARNING on drm-intel/for-linux-next
> tegra-drm/drm/tegra/for-next linus/master v5.7 next-20200609]
> [cannot
Hi Linus.
On Fri, Jun 12, 2020 at 01:04:02PM +0200, Linus Walleij wrote:
> On Wed, Jun 10, 2020 at 9:38 AM kernel test robot wrote:
>
> > I love your patch! Perhaps something to improve:
> >
> > [auto build test WARNING on drm-exynos/exynos-drm-next]
> > [also build test WARNING on drm-intel/for-
When going through a disable/enable cycle without changing the framebuffer
the optimization added by commit 3954ff10e06e causes the screen stay
blank. Add a bool to force an update to fix that.
Cc: 1882...@bugs.launchpad.net
Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't
On Fri, Jun 12, 2020 at 12:16 PM Gerd Hoffmann wrote:
>
> On Fri, Jun 12, 2020 at 11:47:55AM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 12.06.20 um 03:36 schrieb Gurchetan Singh:
> > > This is useful for the next patch. Also, should we only unmap the
> > > amount entries that we mapped wit
On Fri, Jun 12, 2020 at 01:04:02PM +0200, Linus Walleij wrote:
> On Wed, Jun 10, 2020 at 9:38 AM kernel test robot wrote:
>
> > I love your patch! Perhaps something to improve:
> >
> > [auto build test WARNING on drm-exynos/exynos-drm-next]
> > [also build test WARNING on drm-intel/for-linux-next
On 2020-06-12 13:40, Bernard Zhao wrote:
In function mtk_dsi_clk_hs_state, remove unnecessary conversion
to bool return, this change is to make the code a bit readable.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
From: Thierry Reding
In order to remove the dependency on the simple-bus compatible string,
which causes the OF driver core to register all child devices, make the
host1x driver explicitly register its children.
Signed-off-by: Thierry Reding
---
drivers/gpu/host1x/dev.c | 6 ++
1 file chan
From: Thierry Reding
In order to remove the dependency on the simple-bus compatible string,
which causes the OF driver core to register all child devices, make the
display-hub driver explicitly register the display controller children.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/hu
Hi Eugeniu,
On Tue, Jun 09, 2020 at 04:29:59PM +0200, Eugeniu Rosca wrote:
> Hi Laurent,
>
> On Sun, Jun 07, 2020 at 05:41:58AM +0300, Laurent Pinchart wrote:
> > Note that the CMM driver is controlled by the DU driver. As the DU
> > driver will reenable the display during resume, it will call
> >
Hi Eugeniu
On Mon, Jun 08, 2020 at 11:44:32AM +0200, Eugeniu Rosca wrote:
> Hello,
>
> Many thanks for your comments and involvement.
>
> On Sun, Jun 07, 2020 at 05:41:58AM +0300, Laurent Pinchart wrote:
> > On Fri, Jun 05, 2020 at 03:53:15PM +0200, Jacopo Mondi wrote:
> > > On Fri, Jun 05, 2020 a
Hi Jacopo,
On Fri, Jun 12, 2020 at 05:00:32PM +0200, Jacopo Mondi wrote:
> On Tue, Jun 09, 2020 at 04:29:59PM +0200, Eugeniu Rosca wrote:
> > On Sun, Jun 07, 2020 at 05:41:58AM +0300, Laurent Pinchart wrote:
> > > Note that the CMM driver is controlled by the DU driver. As the DU
> > > driver will
On Fri, Jun 12, 2020 at 9:22 AM Bernard Zhao wrote:
>
> In function is_support_sw_smu, remove unnecessary conversion
> to bool return, this change is to make the code a bit readable.
>
> Signed-off-by: Bernard Zhao
Vega20 support was removed from this code path so the patch is no
longer relevant
On Fri, Jun 12, 2020 at 9:22 AM Bernard Zhao wrote:
>
> In function fill_iram_v_2, the ram_table->bright_neg_gain`s
> first element [0][0] seems to be missing. This change is just
> to make the code a bit readable.
>
> Signed-off-by: Bernard Zhao
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm
Hi Eugeniu,
On Fri, Jun 12, 2020 at 05:36:07PM +0200, Eugeniu Rosca wrote:
> On Fri, Jun 12, 2020 at 06:10:05PM +0300, Laurent Pinchart wrote:
> > On Fri, Jun 12, 2020 at 05:00:32PM +0200, Jacopo Mondi wrote:
> > > On Tue, Jun 09, 2020 at 04:29:59PM +0200, Eugeniu Rosca wrote:
> > > > On Sun, Jun
Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
which means vblank state isn't ill-defined and fail-y at driver load
before the first modeset on each crtc.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
Cc: Rodrigo Siqueira
Cc:
The atomic helpers try really hard to not lose track of things,
duplicating enabled tracking in the driver is at best confusing.
Double-enabling or disabling is a bug in atomic helpers.
In the fb_dirty function we can just assume that the fb always exists,
simple display pipe helpers guarantee tha
Same patch as the mipi-dbi one, atomic tracks this for us already, we
just have to check the right thing.
Signed-off-by: Daniel Vetter
Cc: "Noralf Trønnes"
---
drivers/gpu/drm/tiny/repaper.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/tiny/
Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
which means vblank state isn't ill-defined and fail-y at driver load
before the first modeset on each crtc.
Signed-off-by: Daniel Vetter
Cc: Philipp Zabel
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fab
Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
which means vblank state isn't ill-defined and fail-y at driver load
before the first modeset on each crtc.
Signed-off-by: Daniel Vetter
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: linux-arm-ker...@lists.i
Only when vblanks are supported ofc.
Some drivers do this already, but most unfortunately missed it. This
opens up bugs after driver load, before the crtc is enabled for the
first time. syzbot spotted this when loading vkms as a secondary
output. Given how many drivers are buggy it's best to solve
Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
which means vblank state isn't ill-defined and fail-y at driver load
before the first modeset on each crtc.
Signed-off-by: Daniel Vetter
Cc: VMware Graphics
Cc: Roland Scheidegger
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |
Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
which means vblank state isn't ill-defined and fail-y at driver load
before the first modeset on each crtc.
Signed-off-by: Daniel Vetter
Cc: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_crtc.c | 3 +--
1 file changed, 1 insertio
On Thu, Jun 11, 2020 at 7:51 PM Tanmay Shah wrote:
>
> From: Chandan Uddaraju
>
> Add bindings for Snapdragon DisplayPort controller driver.
>
> Changes in V2:
> Provide details about sel-gpio
>
> Changes in V4:
> Provide details about max dp lanes
> Change the commit text
>
> Changes in V5:
> mo
Hi,
On 6/12/20 12:20 AM, Uwe Kleine-König wrote:
On Sun, Jun 07, 2020 at 08:18:34PM +0200, Hans de Goede wrote:
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
So far we've kept the PWM_OUTPUT_ENABLE bit
Hi,
On 6/11/20 11:37 PM, Uwe Kleine-König wrote:
Hello,
On Sun, Jun 07, 2020 at 08:18:36PM +0200, Hans de Goede wrote:
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Signed-off-by: Hans de Goede
---
drivers/pwm/pwm-crc.c | 29 +
Hi,
On 6/11/20 11:21 PM, Uwe Kleine-König wrote:
Hello,
On Mon, Jun 08, 2020 at 04:35:00PM +0200, Daniel Vetter wrote:
On Sat, Jun 06, 2020 at 10:25:45PM +0200, Hans de Goede wrote:
Hi All,
This patch series converts the i915 driver's cpde for controlling the
panel's backlight with an exter
On Thu, Jun 11, 2020 at 08:22:29PM -0700, Rob Clark wrote:
> On Thu, Jun 11, 2020 at 3:29 PM Jordan Crouse wrote:
> >
> > Add support for using per-instance pagetables if all the dependencies are
> > available.
> >
> > Signed-off-by: Jordan Crouse
> > ---
> >
> > drivers/gpu/drm/msm/adreno/a6xx_
On 2020-06-12 12:00 p.m., Daniel Vetter wrote:
> Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
> which means vblank state isn't ill-defined and fail-y at driver load
> before the first modeset on each crtc.
>
> Signed-off-by: Daniel Vetter
> Cc: Alex Deucher
> Cc: Nicho
On Fri, Jun 12, 2020 at 1:24 PM Harry Wentland wrote:
>
> On 2020-06-12 12:00 p.m., Daniel Vetter wrote:
> > Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
> > which means vblank state isn't ill-defined and fail-y at driver load
> > before the first modeset on each crtc.
>
On Fri, Jun 05, 2020 at 12:03:19AM +0300, Ville Syrjälä wrote:
> On Thu, Jun 04, 2020 at 08:01:03PM +, Almahallawy, Khaled wrote:
> > On Thu, 2020-06-04 at 22:06 +0300, Ville Syrjälä wrote:
> > > On Thu, Jun 04, 2020 at 10:33:48AM +0530, Vidya Srinivas wrote:
> > > > Signed-off-by: Khaled Almah
On Thu, Jun 04, 2020 at 08:01:03PM +, Almahallawy, Khaled wrote:
> On Thu, 2020-06-04 at 22:06 +0300, Ville Syrjälä wrote:
> > On Thu, Jun 04, 2020 at 10:33:48AM +0530, Vidya Srinivas wrote:
> > > Signed-off-by: Khaled Almahallawy
> > > Signed-off-by: Vidya Srinivas
> > > ---
> > > drivers/g
On Fri, Jun 12, 2020 at 11:25:42AM -0700, Manasi Navare wrote:
> On Fri, Jun 05, 2020 at 12:03:19AM +0300, Ville Syrjälä wrote:
> > On Thu, Jun 04, 2020 at 08:01:03PM +, Almahallawy, Khaled wrote:
> > > On Thu, 2020-06-04 at 22:06 +0300, Ville Syrjälä wrote:
> > > > On Thu, Jun 04, 2020 at 10:3
On Fri, Jun 12, 2020 at 11:33:45AM -0700, Manasi Navare wrote:
> On Thu, Jun 04, 2020 at 08:01:03PM +, Almahallawy, Khaled wrote:
> > On Thu, 2020-06-04 at 22:06 +0300, Ville Syrjälä wrote:
> > > On Thu, Jun 04, 2020 at 10:33:48AM +0530, Vidya Srinivas wrote:
> > > > Signed-off-by: Khaled Almah
On Fri, Jun 12, 2020 at 09:36:37PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 12, 2020 at 11:25:42AM -0700, Manasi Navare wrote:
> > On Fri, Jun 05, 2020 at 12:03:19AM +0300, Ville Syrjälä wrote:
> > > On Thu, Jun 04, 2020 at 08:01:03PM +, Almahallawy, Khaled wrote:
> > > > On Thu, 2020-06-04 at
On Fri, Jun 12, 2020 at 3:17 AM Gerd Hoffmann wrote:
>
> On Fri, Jun 12, 2020 at 11:47:55AM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 12.06.20 um 03:36 schrieb Gurchetan Singh:
> > > This is useful for the next patch. Also, should we only unmap the
> > > amount entries that we mapped with
On Fri, Jun 12, 2020 at 11:44:13AM -0700, Manasi Navare wrote:
> On Fri, Jun 12, 2020 at 09:36:37PM +0300, Ville Syrjälä wrote:
> > On Fri, Jun 12, 2020 at 11:25:42AM -0700, Manasi Navare wrote:
> > > On Fri, Jun 05, 2020 at 12:03:19AM +0300, Ville Syrjälä wrote:
> > > > On Thu, Jun 04, 2020 at 08:
On Fri, Jun 12, 2020 at 10:01:19PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 12, 2020 at 11:44:13AM -0700, Manasi Navare wrote:
> > On Fri, Jun 12, 2020 at 09:36:37PM +0300, Ville Syrjälä wrote:
> > > On Fri, Jun 12, 2020 at 11:25:42AM -0700, Manasi Navare wrote:
> > > > On Fri, Jun 05, 2020 at 12:
On Fri, Jun 12, 2020 at 12:12:25PM -0700, Manasi Navare wrote:
> On Fri, Jun 12, 2020 at 10:01:19PM +0300, Ville Syrjälä wrote:
> > On Fri, Jun 12, 2020 at 11:44:13AM -0700, Manasi Navare wrote:
> > > On Fri, Jun 12, 2020 at 09:36:37PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Jun 12, 2020 at 11:
The kernel test robot noted that if "OF" is defined (which is needed
to select DRM_TI_SN65DSI86 at all) but not OF_GPIO that we'd get
compile failures because some of the members that we access in "struct
gpio_chip" are only defined "#if defined(CONFIG_OF_GPIO)".
All the GPIO bits in the driver ar
The ti_sn_bridge_gpio_set() got the return value of
regmap_update_bits() but didn't check it. The function can't return
an error value, but we should at least print a warning if it didn't
work.
This fixes a compiler warning about setting "ret" but not using it.
Fixes: 27ed2b3f22ed ("drm/bridge:
When building we were getting an error:
warning: cannot understand function prototype:
'const unsigned int ti_sn_bridge_dp_rate_lut[] = '
Arrays aren't supposed to be marked with "/**" kerneldoc comments. Fix.
Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver")
Sig
This fixes a kernel doc warning due to a typo:
warning: Function parameter or member 'ln_polrs' not described in
'ti_sn_bridge'
Fixes: 5bebaeadb30e ("drm/bridge: ti-sn65dsi86: Implement lane reordering +
polarity")
Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
---
Changes in v2:
On Fri, Jun 12, 2020 at 10:21:31PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 12, 2020 at 12:12:25PM -0700, Manasi Navare wrote:
> > On Fri, Jun 12, 2020 at 10:01:19PM +0300, Ville Syrjälä wrote:
> > > On Fri, Jun 12, 2020 at 11:44:13AM -0700, Manasi Navare wrote:
> > > > On Fri, Jun 12, 2020 at 09:
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.7 next-20200612]
[cannot apply to drm/drm-next]
[if your patch is applied
Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
which means vblank state isn't ill-defined and fail-y at driver load
before the first modeset on each crtc.
v2: Compile fix. Oops.
Signed-off-by: Daniel Vetter
Cc: VMware Graphics
Cc: Roland Scheidegger
---
drivers/gpu/dr
On Tue, Jun 09, 2020 at 08:49:53PM +0300, Adrian Ratiu wrote:
> This provides an example DT binding for the MIPI DSI host controller
It's not an example. It defines the exact binding for this peripheral.
> present on the i.MX6 SoC based on Synopsis DesignWare v1.01 IP.
>
> Cc: Rob Herring
> Cc:
Hi Dmitry,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on next-20200612]
[cannot apply to tegra/for-next robh/for-next v5.7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system
From: Bhanuprakash Modem
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file
on the connector, "vrr_range".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
v6:
* Rebase (manasi)
v5:
* Rename to v
From: Aditya Swarup
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v5:
* Fix the vrr prop not being set in kernel (Manasi)
* Unset the prop on connector disconnect
DP sink device sets the Ignore MSA bit in its
DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
ignore the MSA video timing parameters and its ability to support
seamless video timing change over a range of timing exposed by
DisplayID and EDID.
This is required for the sink to indicate t
This is an initial set of patches for enabling VRR support in i915.
This series has patches for:
1. adding a drm dpcd helper to read ignore MSA
bit in sink's DPCD indicating sink support for VRR
2. Attach and set VRR capable connector prop for Intel DP conn
3. Expose VRR min and max through de
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.7 next-20200612]
[cannot apply to drm/drm-next]
[if your patch is applied
From: Bhanuprakash Modem
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file
on the connector, "vrr_range".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
v7:
* Fix cmpilation due to rebase
v6:
Hi Manasi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
linus/master next-20200612]
[cannot apply to tegra-drm/drm/tegra/for-next drm/drm-next v5.7]
[if your patch is
Hi Manasi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
linus/master next-20200612]
[cannot apply to tegra-drm/drm/tegra/for-next drm/drm-next v5.7]
[if your patch is
64 matches
Mail list logo
