On Tue, Oct 22, 2019 at 4:17 AM Dave Airlie wrote:
>
> On Tue, 22 Oct 2019 at 01:49, Sean Paul wrote:
> >
> > On Mon, Oct 21, 2019 at 4:11 AM Tomi Valkeinen
> > wrote:
> > >
> > > Hi,
> > >
> > > On 18/10/2019 23:11, Sean Paul wrote:
> > > > On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen
> >
On 2019-10-21 16:01, Daniel Thompson wrote:
On Fri, Oct 18, 2019 at 06:03:29PM +0530, Kiran Gunda wrote:
The auto string detection algorithm checks if the current WLED
sink configuration is valid. It tries enabling every sink and
checks if the OVP fault is observed. Based on this information
it
Hi Steve,
Thanks a lot for your review, and I will send a v2 patch ASAP.
> On 19/10/2019 08:28, Yi Wang wrote:
> > We get these warnings when build kernel W=1:
> > drivers/gpu/drm/panfrost/panfrost_perfcnt.c:35:6: warning: no previous
> > prototype for ‘panfrost_perfcnt_clean_cache_done’ [-Wmiss
On 2019-10-21 15:49, Daniel Thompson wrote:
On Fri, Oct 18, 2019 at 06:03:27PM +0530, Kiran Gunda wrote:
WLED4 peripheral is present on some PMICs like pmi8998 and
pm660l. It has a different register map and configurations
are also different. Add support for it.
Signed-off-by: Kiran Gunda
Revi
https://bugs.freedesktop.org/show_bug.cgi?id=112082
Andre Klapper changed:
What|Removed |Added
Group||spam
Version|DRI git
On 21/10/2019 23:45, Rob Herring wrote:
> Add support in CMA helpers to handle callers specifying
> DRM_MODE_DUMB_KERNEL_MAP flag. Existing behavior is maintained with this
> change. drm_gem_cma_dumb_create() always creates a kernel mapping as
> before. drm_gem_cma_dumb_create_internal() lets the c
pecify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/dma_resv-lockdep-annotations-priming/20191022-015539
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds
On Mon, Oct 21, 2019 at 03:12:26PM +, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2019 at 02:28:46PM +, Koenig, Christian wrote:
> > Am 21.10.19 um 15:57 schrieb Jason Gunthorpe:
> > > On Sun, Oct 20, 2019 at 02:21:42PM +, Koenig, Christian wrote:
> > >> Am 18.10.19 um 22:36 schrieb Jason
Be consistent with the rest of the code base.
No functional change.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
drivers/gpu/drm/virtio/virtgpu_plane.c | 12 ++--
drivers/gpu/drm/virtio/virtgpu_vq.c| 12 ++--
3 files changed, 14 insertion
Be consistent with the rest of the code base.
No functional change.
In theory this change is incompatible on bigendian machines,
but in practice 3d acceleration is supported only on little
endian machines, so the affected code paths never run on
bigendian machines.
Signed-off-by: Gerd Hoffmann
-
Return early for the no framebuffer (or disabled output) case.
Results in a simpler code flow for the remaining cases.
No functional change.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 62 ++
1 file changed, 33 insertions(+), 29 deletions(-)
No functional change.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 36 +++---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 0b5a760bc293..bc4b
Little patch series doing some cleanups in the virtio driver.
Patches #1 + #2 have been on the list before as single patches,
includes here again for patch dependency reasons.
please review,
Gerd
Gerd Hoffmann (5):
drm/virtio: print a single line with device features
drm/virtio: move byteor
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 0b3cdb0d83b0..2f5773e43557 100644
--- a/drivers/gpu/drm/virtio/virt
On Wed, 16 Oct 2019, Patrik Jakobsson wrote:
> Fix typo where bits got compared (x < y) instead of shifted (x << y).
Fixes: 3ad33ae2bc80 ("drm: Add SCDC helpers")
Cc: Thierry Reding
> Signed-off-by: Patrik Jakobsson
> ---
> include/drm/drm_scdc_helper.h | 6 +++---
> 1 file changed, 3 inserti
Hi John,
On 21/10/2019 21:03, John Stultz wrote:
> Lucky number 13! :)
>
> Last week in v12 I had re-added some symbol exports to support
> later patches I have pending to enable loading heaps from
> modules. He reminded me that back around v3 (its been awhile!) I
> had removed those exports due
From: Bartosz Golaszewski
Platform data fields other than fbdev are no longer used by the
backlight driver. Remove them.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
Reviewed-by: Linus Walleij
---
arch/sh/boards/mach-ecovec24/setup.c | 3 ---
1 file changed, 3 deletions(-)
From: Bartosz Golaszewski
Now that the last user of platform data (sh ecovec24) defines a proper
GPIO lookup and sets the 'default-on' device property, we can drop the
platform_data-specific GPIO handling and unify a big chunk of code.
The only field used from the platform data is now the fbdev
From: Bartosz Golaszewski
We no longer use any symbols from of_gpio.h. Remove this include.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Linus Walleij
Reviewed-by: Daniel Thompson
Reviewed-by: Andy Shevchenko
---
drivers/video/backlight/gpio_backlight.c | 1 -
1 file changed, 1 deletion(
From: Bartosz Golaszewski
Add a GPIO lookup entry and a device property for GPIO backlight to the
board file. Tie them to the platform device which is now registered using
platform_device_register_full() because of the properties. These changes
are inactive now but will be used once the gpio back
From: Bartosz Golaszewski
While working on my other series related to gpio-backlight[1] I noticed
that we could simplify the driver if we made the only user of platform
data use GPIO lookups and device properties. This series tries to do
that.
First two patches contain minor fixes. Third patch m
On Tue, Oct 08, 2019 at 02:42:54PM +0200, Benjamin Gaignard wrote:
> Few for_each macro set variables that are never used later which led
> to generate unused-but-set-variable warnings.
> Add (void)(foo) inside the macros to remove these warnings
>
> Signed-off-by: Benjamin Gaignard
OCD in me wo
On Wed, Oct 16, 2019 at 02:33:42PM +0200, Patrik Jakobsson wrote:
> Fix typo where bits got compared (x < y) instead of shifted (x << y).
>
> Signed-off-by: Patrik Jakobsson
> ---
> include/drm/drm_scdc_helper.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Oh my...
Reviewed-by
On Thu, Oct 17, 2019 at 12:41:37PM +0100, Russell King - ARM Linux admin wrote:
> On Thu, Oct 17, 2019 at 10:48:12AM +, Brian Starkey wrote:
> > On Thu, Oct 17, 2019 at 10:21:03AM +, james qian wang (Arm Technology
> > China) wrote:
> > > On Thu, Oct 17, 2019 at 08:20:56AM +, Brian Sta
On Tue, Oct 22, 2019 at 11:16:51AM +0300, Jani Nikula wrote:
> On Wed, 16 Oct 2019, Patrik Jakobsson wrote:
> > Fix typo where bits got compared (x < y) instead of shifted (x << y).
>
> Fixes: 3ad33ae2bc80 ("drm: Add SCDC helpers")
> Cc: Thierry Reding
I'm not sure we really need the Fixes: tag
Hi,
On Mon, Oct 21, 2019 at 07:11:12PM +0800, kbuild test robot wrote:
> Hi "Guido,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.4-rc4 next-20191018]
> [if your patch is applied to the wrong git tree, please drop us a note to h
On Fri, May 18, 2018 at 1:52 PM Andrzej Hajda wrote:
>
> On 26.04.2018 10:07, Jyri Sarha wrote:
> > Add device_link from panel device (supplier) to drm device (consumer)
> > when drm_panel_attach() is called. This patch should protect the
> > master drm driver if an attached panel driver unbinds w
On Tue, Oct 22, 2019 at 10:42:10AM +0200, Daniel Vetter wrote:
> On Thu, Oct 17, 2019 at 12:41:37PM +0100, Russell King - ARM Linux admin
> wrote:
> > On Thu, Oct 17, 2019 at 10:48:12AM +, Brian Starkey wrote:
> > > On Thu, Oct 17, 2019 at 10:21:03AM +, james qian wang (Arm Technology
> >
On Tue, Oct 22, 2019 at 10:48 AM Russell King - ARM Linux admin
wrote:
>
> On Tue, Oct 22, 2019 at 10:42:10AM +0200, Daniel Vetter wrote:
> > On Thu, Oct 17, 2019 at 12:41:37PM +0100, Russell King - ARM Linux admin
> > wrote:
> > > On Thu, Oct 17, 2019 at 10:48:12AM +, Brian Starkey wrote:
>
On Thu, Oct 17, 2019 at 03:26:33PM +0200, Gerd Hoffmann wrote:
> Switch qxl driver to the new mmap workflow,
> some cleanups, reduce memory fragmentation.
>
> Series needs latest drm-misc-next to build.
Nice stuff. On the series:
Reviewed-by: Daniel Vetter
>
> Gerd Hoffmann (5):
> drm/qxl:
On Thu, Oct 17, 2019 at 11:29:53PM -0500, Kangjie Lu wrote:
> `best_clock` is an object that may be sent out. Object `clock`
> contains uninitialized bytes that are copied to `best_clock`,
> which leads to memory disclosure and information leak.
>
> Signed-off-by: Kangjie Lu
> ---
> drivers/gpu/
Hey Daniel
On lunes, 14 de octubre de 2019 10:59:38 (CEST) Daniel Vetter wrote:
> On Fri, Oct 11, 2019 at 04:30:09PM +0200, Rohan Garg wrote:
> > DRM_IOCTL_DUMB_SET_LABEL lets you label GEM objects, making it
> > easier to debug issues in userspace applications.
> >
> > Changes in v2:
> > - Hois
Hi Thomas
On viernes, 11 de octubre de 2019 19:55:36 (CEST) Thomas Zimmermann wrote:
> Hi
>
> Am 11.10.19 um 19:09 schrieb Daniel Stone:
> > Hi Rohan,
> >
> > On Fri, 11 Oct 2019 at 15:30, Rohan Garg wrote:
> >> DRM_IOCTL_DUMB_SET_LABEL lets you label GEM objects, making it
> >> easier to debug
Hey
On viernes, 11 de octubre de 2019 19:09:52 (CEST) Daniel Stone wrote:
> Hi Rohan,
>
> On Fri, 11 Oct 2019 at 15:30, Rohan Garg wrote:
> > DRM_IOCTL_DUMB_SET_LABEL lets you label GEM objects, making it
> > easier to debug issues in userspace applications.
>
> I'm not sure if this was pointed
On Thu, Oct 17, 2019 at 11:41:50PM -0500, Kangjie Lu wrote:
> "clock" may be copied to "best_clock". Initializing best_clock
> is not sufficient. The fix initializes clock as well to avoid
> memory disclosures and informaiton leaks.
>
> Signed-off-by: Kangjie Lu
Again no leak here, but also does
On Fri, Oct 18, 2019 at 01:38:32PM +0200, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_kms.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
> b/drivers/gpu/drm/virtio/virtgpu_km
On Fri, Oct 18, 2019 at 02:23:52PM +0200, Gerd Hoffmann wrote:
> Be consistent with the rest of the code base.
>
> Signed-off-by: Gerd Hoffmann
Assuming sparse is all still pleased:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
> drivers/gpu/drm/virtio/
On Sat, 12 Oct 2019 09:15:26 +0200
Sam Ravnborg wrote:
> Hi Boris/Andrzej.
>
> >
> > >
> > >
> > > > Note that -ENOSYS is actually a valid case, it just
> > > > means the panel driver does not implement the hook.
> > >
> > >
> > > It would be good then to fix it in panel framework,
I think there is something I totally forgot about:
When there was never a driver bound to the GPU, and if runtime power
management gets enabled on that device, runtime suspend/resume works
as expected (I am not 100% sure on if that always works, but I will
recheck that).
In the past I know that at
On Sat, Oct 19, 2019 at 09:04:31PM +0200, Julia Lawall wrote:
>
>
> On Sat, 19 Oct 2019, Wambui Karuga wrote:
>
> > From: Wambui Karuga
> >
> > Remove unnecessary variable `ret` in drm_dp_atomic_find_vcpi_slots()
> > only used to hold the function return value and have the function
> > return t
wt., 22 paź 2019 o 10:36 Bartosz Golaszewski napisał(a):
>
> From: Bartosz Golaszewski
>
> While working on my other series related to gpio-backlight[1] I noticed
> that we could simplify the driver if we made the only user of platform
> data use GPIO lookups and device properties. This series tr
On Tue, Oct 22, 2019 at 10:58:02AM +0200, Rohan Garg wrote:
> Hey Daniel
> On lunes, 14 de octubre de 2019 10:59:38 (CEST) Daniel Vetter wrote:
> > On Fri, Oct 11, 2019 at 04:30:09PM +0200, Rohan Garg wrote:
> > > DRM_IOCTL_DUMB_SET_LABEL lets you label GEM objects, making it
> > > easier to debug
On Mon, Oct 21, 2019 at 01:52:49PM -0500, Navid Emamdoost wrote:
> In the impelementation of v3d_submit_cl_ioctl() there are two memory
> leaks. One is when allocation for bin fails, and the other is when bin
> initialization fails. If kcalloc fails to allocate memory for bin then
> render->base sh
> +++ 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))
> + if (WARN_ON(pi < 0)) {
> + kfree(nvbo);
> retu
On Tue, 22 Oct 2019, Thierry Reding wrote:
> On Tue, Oct 22, 2019 at 11:16:51AM +0300, Jani Nikula wrote:
>> On Wed, 16 Oct 2019, Patrik Jakobsson wrote:
>> > Fix typo where bits got compared (x < y) instead of shifted (x << y).
>>
>> Fixes: 3ad33ae2bc80 ("drm: Add SCDC helpers")
>> Cc: Thierry
This patch adds support to handle nearest-neighbor(NN) filter
option for the panel fitter / pipe scaler.
Nearest-neighbor filter, when applied for integer upscaling ratios,
can produce sharp and blurless outputs. This is pretty useful while
upscaling the old games to higher resolution displays.
T
Blurry outputs during upscaling the video buffer, is a generic problem
of graphics industry. One of the major reason behind this blurriness is
the interpolation of pixel values used by most of the upscaling hardwares.
Nearest-neighbor is a scaling mode, which works by filling in the missing
color
This patch does the following:
- Creates the CRTC property for scaling filter mode (for GEN11 and +).
- Applies the chosen filter value while enabling the panel fitter.
- Adds CRTC state readouts and comparisons.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/display/intel_display.c | 5
This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to pick a desired effect while scaling.
This option will be particularly useful in the scenarios where
Integer mode scaling is possible, and a UI client wants to pick
On Mon, Oct 21, 2019 at 01:15:21PM +0200, Christian König wrote:
> This patch is a stripped down version of the locking changes
> necessary to support dynamic DMA-buf handling.
>
> It adds a dynamic flag for both importers as well as exporters
> so that drivers can choose if they want the reservat
On Tue, Oct 22, 2019 at 12:01:30PM +0200, Daniel Vetter wrote:
> On Mon, Oct 21, 2019 at 01:15:21PM +0200, Christian König wrote:
> > This patch is a stripped down version of the locking changes
> > necessary to support dynamic DMA-buf handling.
> >
> > It adds a dynamic flag for both importers as
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
> This patch adds a scaling filter mode porperty
> to allow:
> - A driver/HW to showcase it's scaling filter capabilities.
> - A userspace to pick a desired effect while scaling.
>
> This option will be particularly useful in the sce
The DCS command has been named SET_PARTIAL_ROWS in the DCS spec since
v1.02, for more than a decade. Rename the enumeration to match the spec.
Cc: David Lechner
Cc: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/tiny/st7586.c | 2 +-
include/video/mipi_display.h | 2 +-
2 fil
Add execute queue and compressed pixel stream packet data types for
completeness.
Cc: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_mipi_dsi.c | 2 ++
include/video/mipi_display.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/dri
Some cleanup and prep work for compression. Users for these are in the
works, but hopefully we can proceed with this already. Should be pretty
straightforward.
BR,
Jani.
Jani Nikula (5):
drm/dsi: clean up DSI data type definitions
drm/dsi: add missing DSI data types
drm/dsi: add missing DSI
Update from the DCS specification.
Cc: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
include/video/mipi_display.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
index 6b6390dfa203..928f8c4b6658 100644
--- a/include/v
Rename picture parameter set (it's a long packet, not a long write) and
compression mode (it's not a DCS command) enumerations according to the
DSI specification. Order the types according to the spec. Use tabs
instead of spaces for indentation. Use all lower case for hex.
Cc: Vandita Kulkarni
Si
Add helper functions for sending the DSI compression mode and picture
parameter set data type packets. For the time being, limit the support
to using VESA DSC 1.1 and the default PPS. This may need updating if the
need arises for proprietary compression or non-default PPS, however keep
it simple fo
On Mon, Oct 21, 2019 at 01:15:22PM +0200, Christian König wrote:
> The attachment list is now protected by the dma_resv object.
> So we can drop holding this lock to allow concurrent attach
> and detach operations.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-buf.c | 16 ---
Hey Daniel,
> -Original Message-
> From: Daniel Vetter On Behalf Of Daniel Vetter
> Sent: Tuesday, October 22, 2019 3:39 PM
> To: Sharma, Shashank
> Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/3] drm: Introduce scaling filter
On Tue, Oct 22, 2019 at 10:36:24AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> The GPIO backlight driver currently requests the line 'as is', without
> acively setting its direction. This can lead to problems: if the line
> is in input mode by default, we won't be able to dr
Passing the plane structure to prepare_fb() and cleanup_fb() of
struct drm_simple_display_pipe_funcs unifies the interface with
struct drm_plane_helper_funcs. Implementations of these functions
can now be shared between simple-pipeline and 'full-pipeline' drivers.
Before, the functions received th
GEM VRAM provides an implementation for prepare_fb() and cleanup_fb()
of struct drm_simple_display_pipe_funcs. Switch over bochs.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/bochs/bochs_kms.c | 26 ++
1 file changed, 2 insertions(+), 24 deletions(-)
diff --git a
The implementation of the plane's call-back functions prepare_fb() and
cleanup_fb() for GEM VRAM helpers are sharable among drivers.
The first patch adapts the the interface of simple KSM helpers such that
bochs can benefit from the shared code. We add the helper functions in
patch #2. Patches #3
The new helpers pin and unpin a framebuffer's GEM VRAM objects during
plane updates. This should be sufficient for most drivers prepare_fb and
cleanup_fb implementations.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 81 +++
include/drm/drm_
GEM VRAM provides an implementation for prepare_fb() and cleanup_fb()
of struct drm_plane_helper_funcs. Switch over vboxvideo.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vboxvideo/vbox_mode.c | 61 ++-
1 file changed, 4 insertions(+), 57 deletions(-)
diff --git
This patch implements prepare_fb() and cleanup_fb() in hibmc with the
GEM VRAM helpers. In the current code, pinning the BO is performed by
hibmc_plane_atomic_update(), where the operation does not belong.
This patch also fixes a bug where the pinned BO was never unpinned.
Pinning multiple BOs wou
gs/du-next-20191022
for you to fetch changes up to 153f2971b58764b7238989489bd45ca0f491f74a:
arm64: dts: renesas: Add CMM units to Gen3 SoCs (2019-10-22 13:21:18 +0300)
- R-Car DU Color Management Modu
'du-next-20191016' of git://linuxtv.org/pinchartl/media into
> drm-next (2019-10-22 15:04:07 +1000)
>
> are available in the Git repository at:
>
> git://linuxtv.org/pinchartl/media.git tags/du-next-20191022
>
> for you to fetch changes up to 153f2971b58764b7238989489bd45c
/media.git tags/du-next-20191022
for you to fetch changes up to aad1552f1defd3a5334cd4b2573fae9963d4db57:
drm: rcar-du: crtc: Register GAMMA_LUT properties (2019-10-22 13:21:18 +0300)
- R-Car DU Color Management Modu
On Hyper-V, Generation 1 VMs can directly use VM's physical memory for
their framebuffers. This can improve the efficiency of framebuffer and
overall performence for VM. The physical memory assigned to framebuffer
must be contiguous. We use CMA allocator to get contiguouse physicial
memory when the
Hi Rob,
Thank you for the patch.
On Mon, Oct 21, 2019 at 04:45:46PM -0500, Rob Herring wrote:
> Introduce a new flag, DRM_MODE_DUMB_KERNEL_MAP, for struct
> drm_mode_create_dumb. This flag is for internal kernel use to indicate
> if dumb buffer allocation needs a kernel mapping. This is needed on
Hi Rob,
Thank you for the patch.
On Mon, Oct 21, 2019 at 04:45:47PM -0500, Rob Herring wrote:
> In preparation to allow DRM CMA users to adjust the DMA_ATTR_* flags,
> convert the CMA helper code to use the dma_*_attr APIs instead of the
> dma_*_wc variants.
>
> Only the DMA_ATTR_WRITE_COMBINE a
Hi Rob,
Thank you for the patch.
On Mon, Oct 21, 2019 at 04:45:48PM -0500, Rob Herring wrote:
> Add support in CMA helpers to handle callers specifying
> DRM_MODE_DUMB_KERNEL_MAP flag. Existing behavior is maintained with this
> change. drm_gem_cma_dumb_create() always creates a kernel mapping as
Hi Laurent,
On Tue, Oct 22, 2019 at 1:30 PM Laurent Pinchart
wrote:
> On Mon, Oct 21, 2019 at 04:45:48PM -0500, Rob Herring wrote:
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > @@ -419,6 +419,7 @@ int rockchip_gem_dumb_create(stru
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #34 from Carmen Bianca Bakker ---
Created attachment 145793
--> https://bugs.freedesktop.org/attachment.cgi?id=145793&action=edit
failed suspend 5.4.0rc2
Issue still occurs on 5.4rc2. In these logs, on the second suspension.
Thin
On 10/21/2019 12:58 PM, Jason Gunthorpe wrote:
On Mon, Oct 21, 2019 at 11:55:51AM -0400, Dennis Dalessandro wrote:
On 10/15/2019 2:12 PM, Jason Gunthorpe wrote:
This is still being tested, but I figured to send it to start getting help
from the xen, amd and hfi drivers which I cannot test here.
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
> This patch adds a scaling filter mode porperty
> to allow:
> - A driver/HW to showcase it's scaling filter capabilities.
> - A userspace to pick a desired effect while scaling.
>
> This option will be particularly useful in the sce
On Tue, Oct 22, 2019 at 10:12:29AM +, Sharma, Shashank wrote:
> Hey Daniel,
>
> > -Original Message-
> > From: Daniel Vetter On Behalf Of Daniel Vetter
> > Sent: Tuesday, October 22, 2019 3:39 PM
> > To: Sharma, Shashank
> > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freed
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
> This patch adds a scaling filter mode porperty
> to allow:
> - A driver/HW to showcase it's scaling filter capabilities.
> - A userspace to pick a desired effect while scaling.
>
> This option will be particularly useful in the sce
On Tue, Oct 22, 2019 at 11:16:14AM +0200, Karol Herbst wrote:
> I think there is something I totally forgot about:
>
> When there was never a driver bound to the GPU, and if runtime power
> management gets enabled on that device, runtime suspend/resume works
> as expected (I am not 100% sure on if
On Tue, Oct 22, 2019 at 6:14 AM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Mon, Oct 21, 2019 at 04:45:46PM -0500, Rob Herring wrote:
> > Introduce a new flag, DRM_MODE_DUMB_KERNEL_MAP, for struct
> > drm_mode_create_dumb. This flag is for internal kernel use to indicat
On Tue, Oct 22, 2019 at 2:45 PM Mika Westerberg
wrote:
>
> On Tue, Oct 22, 2019 at 11:16:14AM +0200, Karol Herbst wrote:
> > I think there is something I totally forgot about:
> >
> > When there was never a driver bound to the GPU, and if runtime power
> > management gets enabled on that device, r
Hey,
On Tue, 22 Oct 2019 at 11:30, Daniel Vetter wrote:
> On Tue, Oct 22, 2019 at 10:58:02AM +0200, Rohan Garg wrote:
> > This approach also future proof's us to be able to label any handles, not
> > just
> > GEM handle.
>
> I don't expect we'll ever merge any non-gem drivers in the future anymo
Hi Shashank,
On Tuesday, 22 October 2019 10:59:44 BST Shashank Sharma wrote:
> This patch adds a scaling filter mode porperty
> to allow:
> - A driver/HW to showcase it's scaling filter capabilities.
> - A userspace to pick a desired effect while scaling.
>
> This option will be particularly usefu
On Mon, Oct 21, 2019 at 04:34:32PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> During the discussion of patches that enhance the drm_dp_link helpers it
> was concluded that these helpers aren't very useful to begin with. Start
> pushing the equivalent code into individual drivers to u
On Tuesday, 22 October 2019 14:26:38 BST Mihail Atanassov wrote:
> Hi Shashank,
>
> On Tuesday, 22 October 2019 10:59:44 BST Shashank Sharma wrote:
> > This patch adds a scaling filter mode porperty
> > to allow:
> > - A driver/HW to showcase it's scaling filter capabilities.
> > - A userspace to
Den 17.10.2019 18.27, skrev Noralf Trønnes:
>
>
> Den 17.10.2019 13.49, skrev Andy Shevchenko:
>> GCC complains about dubious bitwise OR operand:
>>
>> drivers/gpu/drm/drm_mipi_dbi.c:1024:49: warning: dubious: x | !y
>> CC [M] drivers/gpu/drm/drm_mipi_dbi.o
>>
>> As long as buffer is consist
On Mon, Oct 21, 2019 at 04:34:33PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> During the discussion of patches that enhance the drm_dp_link helpers it
> was concluded that these helpers aren't very useful to begin with. Start
> pushing the equivalent code into individual drivers to u
On Mon, Oct 21, 2019 at 09:18:07AM +, Brian Starkey wrote:
> On Sat, Oct 19, 2019 at 09:41:27AM -0400, Andrew F. Davis wrote:
> > On 10/18/19 2:57 PM, Ayan Halder wrote:
> > > On Fri, Oct 18, 2019 at 11:49:22AM -0700, John Stultz wrote:
> > >> On Fri, Oct 18, 2019 at 11:41 AM Ayan Halder wrote
On Mon, Oct 21, 2019 at 04:34:35PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> During the discussion of patches that enhance the drm_dp_link helpers it
> was concluded that these helpers aren't very useful to begin with. Start
> pushing the equivalent code into individual drivers to u
On Mon, Oct 21, 2019 at 04:34:37PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> During the discussion of patches that enhance the drm_dp_link helpers it
> was concluded that these helpers aren't very useful to begin with. After
> all other drivers have been converted not to use these h
On Mon, Oct 21, 2019 at 04:34:36PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> During the discussion of patches that enhance the drm_dp_link helpers it
> was concluded that these helpers aren't very useful to begin with. Start
> pushing the equivalent code into individual drivers to u
On Mon, Oct 21, 2019 at 04:34:30PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Use microsecond sleeps for the clock recovery and channel equalization
> delays during link training. The duration of these delays can be from
> 100 us up to 16 ms. It is rude to busy-loop for that amount o
On 2019-10-22 8:20 a.m., Ville Syrjälä wrote:
> On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
>> This patch adds a scaling filter mode porperty
>> to allow:
>> - A driver/HW to showcase it's scaling filter capabilities.
>> - A userspace to pick a desired effect while scaling.
>
On Tue, Oct 22, 2019 at 12:25:16PM +0200, Thomas Zimmermann wrote:
> Passing the plane structure to prepare_fb() and cleanup_fb() of
> struct drm_simple_display_pipe_funcs unifies the interface with
> struct drm_plane_helper_funcs. Implementations of these functions
> can now be shared between simp
Reviewed-by: Anthony Koo
-Original Message-
From: sunpeng...@amd.com
Sent: Monday, October 21, 2019 3:44 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
lskre...@gmail.com
Cc: Koo, Anthony ; Wentland, Harry
; Li, Sun peng (Leo)
Subject: [PATCH v2] drm/amdgpu: A
Hi
Am 22.10.19 um 16:14 schrieb Daniel Vetter:
> On Tue, Oct 22, 2019 at 12:25:16PM +0200, Thomas Zimmermann wrote:
>> Passing the plane structure to prepare_fb() and cleanup_fb() of
>> struct drm_simple_display_pipe_funcs unifies the interface with
>> struct drm_plane_helper_funcs. Implementation
On Tue, Oct 22, 2019 at 10:50:42AM +0200, Daniel Vetter wrote:
> On Tue, Oct 22, 2019 at 10:48 AM Russell King - ARM Linux admin
> wrote:
> > I had a patches, which is why I raised the problem with the core:
> >
> > 6961edfee26d bridge hacks using device links
> >
> > but it never went further tha
From: Thierry Reding
During the discussion of patches that enhance the drm_dp_link helpers it
was concluded that these helpers aren't very useful to begin with. Start
pushing the equivalent code into individual drivers to ultimately remove
them.
v4: use bulk DPCD writes if possible (Daniel Vette
1 - 100 of 172 matches
Mail list logo
