On Thu, Jan 26, 2017 at 11:56:16PM +0100, Noralf Trønnes wrote:
> drm_debugfs_cleanup() now removes all minor->debugfs_list entries
> automatically, so the drm_driver.debugfs_cleanup callback is not
> needed.
>
> Cc: thierry.red...@gmail.com
> Signed-off-by: Noralf Trønnes
Already mentioned on t
On Thu, Jan 26, 2017 at 11:56:11PM +0100, Noralf Trønnes wrote:
> drm_debugfs_cleanup() now removes all minor->debugfs_list entries
> automatically, so it's not necessary to call
> drm_debugfs_remove_files(). Additionally it uses
> debugfs_remove_recursive() to clean up the debugfs files, so no nee
On Thu, Jan 26, 2017 at 11:56:02PM +0100, Noralf Trønnes wrote:
> This patchset removes the need for drivers to clean up their debugfs
> files on exit. It is done automatically in drm_debugfs_cleanup().
> This funtion is also called should the driver error out in it's
> drm_driver.debugfs_init call
On Thu, Jan 26, 2017 at 04:14:56PM +, Emil Velikov wrote:
> On 26 January 2017 at 15:49, Thierry Reding wrote:
> > On Fri, Jan 20, 2017 at 06:28:39PM +, Emil Velikov wrote:
> >> On 20 January 2017 at 16:17, Thierry Reding wrote:
> >> > On Fri, Jan 20, 2017 at 02:13:00PM +, Emil Veliko
https://bugzilla.kernel.org/show_bug.cgi?id=193341
Bug ID: 193341
Summary: AMDGPU: kernel NULL pointer dereferenced with hybrid
graphics
Product: Drivers
Version: 2.5
Kernel Version: 4.9.6
Hardware: x86-64
On Thu, Jan 26, 2017 at 11:05:45PM -0200, Gabriel Krisman Bertazi wrote:
> No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1
> output"). qxl_num_crtc defaults to 4 and is configurable as a module
> parameter.
>
> Signed-off-by: Gabriel Krisman Bertazi
Since I ended up read
On Thu, Jan 26, 2017 at 11:05:45PM -0200, Gabriel Krisman Bertazi wrote:
> No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1
> output"). qxl_num_crtc defaults to 4 and is configurable as a module
> parameter.
>
> Signed-off-by: Gabriel Krisman Bertazi
> ---
> drivers/gpu/d
On Thu, Jan 26, 2017 at 07:29:13PM +0100, Wladimir J. van der Laan wrote:
>
> Reviewed-By: Wladimir J. van der Laan
>
> I do wonder whether we'll need the split formats in practice -
> e.g. the GC3000 on the i.MX6qp, for which I suppose this is being done because
> of tiled buffers support in th
On Fri, Jan 27, 2017 at 07:23:58AM +0100, Thomas Hellstrom wrote:
> On 01/27/2017 03:29 AM, Michel Dänzer wrote:
> > On 26/01/17 09:46 AM, Sinclair Yeh wrote:
> >> On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote:
> >>> Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom:
> On 01/25
-lpthread is not always a valid flag to pull pthread support, especially
on Android it will fail to link due to a missing libpthread.so. The more
generic way to build-in pthread support is to use the -pthread CFLAG, so
let's use it instead.
Signed-off-by: Tomasz Figa
---
tests/exynos/Makefile.am
On Thu, Jan 26, 2017 at 9:48 PM, Liviu Dudau wrote:
>> I'm not certain number of people is a good metric, TBH. There are cases
>> where a lot of people are working on a driver, but the patches are not being
>> merged to the maintainer tree. In these cases, it makes sense to migrate the
>> driver t
On Thu, Jan 26, 2017 at 8:48 PM, Eric Anholt wrote:
>> - Should we require review or at least acks for patches committed by
>> the author? We have a bunch of drivers with effectively just 1 person
>> working on it, where getting real review is hard. But otoh a few of
>> those 1-person drivers will
On 01/27/2017 03:29 AM, Michel Dänzer wrote:
> On 26/01/17 09:46 AM, Sinclair Yeh wrote:
>> On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote:
>>> Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom:
On 01/25/2017 09:21 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
>
On Thu, Jan 26, 2017 at 8:11 PM, Sean Paul wrote:
> On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote:
>> - Should it be an entire separate tree for soc drivers? Problem here
>> is that we lack a volunteer group (and imo it really should be a group
>> to avoid the single-maintainer tro
On 26/01/17 09:46 AM, Sinclair Yeh wrote:
> On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote:
>> Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom:
>>> On 01/25/2017 09:21 AM, Michel Dänzer wrote:
From: Michel Dänzer
The current caching state may not be tt_cached, even
Hi Linus,
This is the main request for rc6, since really the one earlier was the
rc5 one :-)
The main thing are the nouveau specific race fixes for the connector locking bug
we fixed in -next and reverted here as it has quite large prereqs. These two
fixes should solve the problem at that level a
Thank you for comments,
I will update the patch and send v1.
On 01/26/2017 12:36 PM, Daniel Vetter wrote:
On Thu, Jan 26, 2017 at 09:22:46AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
From the description of the "DMA-BUF/GEM Object references
and lifetime overview" i
Commit 25d3db7600b87a4 ("mm, fs: reduce fault, page_mkwrite, and
pfn_mkwrite to take only vmf") causes the following build failure with
arm allmodconfig:
drivers/gpu/drm/armada/armada_gem.c:38:11: error: initialization from
incompatible pointer type [-Werror=incompatible-pointer-types]
drivers/gp
On 01/25/2017 07:38 AM, Daniel Vetter wrote:
> On Wed, Jan 25, 2017 at 07:20:45AM -0800, Dave Hansen wrote:
>> On 01/24/2017 10:21 PM, Daniel Vetter wrote:
>>> Hi Dave,
>>>
>>> Still waiting for your testing results on this one here ...
>>
>> It's definitely stable with that patch applied. No more
Hi,
On Wed, Jan 25, 2017 at 11:35:05PM +0100, Arnd Bergmann wrote:
> I ran into a couple of build problems on ARM, these are the changes that
> should be folded into the original patch that changed all the ->fault()
> prototypes
>
> Fixes: mmtom ("mm, fs: reduce fault, page_mkwrite, and pfn_mkwri
From: Oleksandr Andrushchenko
From the description of the "DMA-BUF/GEM Object references
and lifetime overview" it is not clear when exactly
dma_buf gets destroyed and memory freed: only driver
.release function mentioned which makes confusion on the
real buffer's lifetime.
Add more description
On 01/26/2017 12:45 PM, Chris Wilson wrote:
On Thu, Jan 26, 2017 at 11:36:05AM +0100, Daniel Vetter wrote:
On Thu, Jan 26, 2017 at 09:22:46AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
From the description of the "DMA-BUF/GEM Object references
and lifetime overview
page_flip_completed() dereferences 'work' variable after executing
queue_work(). This is not safe as the 'work' item might be already freed
by queued work:
BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 at addr
8803dc010f90
Call Trace:
__asan_report_load8_noabort+0
On 01/26/2017 06:36 AM, Fabio Estevam wrote:
> Commit 25d3db7600b87a4 ("mm, fs: reduce fault, page_mkwrite, and
> pfn_mkwrite to take only vmf") causes the following build failure with
> arm allmodconfig:
>
> drivers/gpu/drm/armada/armada_gem.c:38:11: error: initialization from
> incompatible p
On 27 January 2017 at 01:23, Emil Velikov wrote:
> On 27 January 2017 at 01:05, Gabriel Krisman Bertazi
> wrote:
>> qxl_device duplicates a pointer to struct device, which is not needed
>> since we already have it in the drm_device structure. Clean it up.
>>
>> Signed-off-by: Gabriel Krisman Ber
On 27 January 2017 at 01:05, Gabriel Krisman Bertazi
wrote:
> qxl_device duplicates a pointer to struct device, which is not needed
> since we already have it in the drm_device structure. Clean it up.
>
> Signed-off-by: Gabriel Krisman Bertazi
> ---
> drivers/gpu/drm/qxl/qxl_drv.h| 1 -
>
No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1
output"). qxl_num_crtc defaults to 4 and is configurable as a module
parameter.
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dri
qxl_device duplicates the pointer to struct pci_dev, which is not
needed since we already have it in the drm_device structure. Clean it
up.
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_drv.h | 1 -
drivers/gpu/drm/qxl/qxl_ioctl.c | 2 +-
drivers/gpu/drm/qxl/qxl_kms.c |
This is the recommended way to create the drm_device structure,
according to DRM documentation.
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_debugfs.c | 6 +++---
drivers/gpu/drm/qxl/qxl_display.c | 32
drivers/gpu/drm/qxl/qxl_drv.c | 3
qxl_device duplicates a pointer to struct device, which is not needed
since we already have it in the drm_device structure. Clean it up.
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/qxl/qxl_drv.h| 1 -
drivers/gpu/drm/qxl/qxl_kms.c| 1 -
drivers/gpu/drm/qxl/qxl_object.c
Originally based off of a patch by Kristian.
This new ioctl extends DRM_IOCTL_MODE_GETPLANE, by returning information
about the modifiers that will work with each format.
It's modified from Kristian's patch in that the modifiers and formats
are setup by the driver, and then a callback is used to
https://bugs.freedesktop.org/show_bug.cgi?id=99553
--- Comment #1 from darkbasic ---
It would be easier to track the few apps which work, unfortunately :(
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing l
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so it's not necessary to call drm_debugfs_remove_files().
Cc: alexander.deuc...@amd.com
Cc: christian.koe...@amd.com
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/radeon/radeon_device.c | 16
1
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so the drm_driver.debugfs_cleanup callback is not
needed.
Cc: tomi.valkei...@ti.com
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/omapdrm/omap_debugfs.c | 9 -
drivers/gpu/drm/omapdrm/omap_drv.c | 1
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so the drm_driver.debugfs_cleanup callback is not
needed.
Cc: thierry.red...@gmail.com
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tegra/drm.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so the drm_driver.debugfs_cleanup callback is not
needed. Also remove the unused tilcdc_module_ops.debugfs_cleanup()
callback. drm_debugfs_cleanup() removes all debugfs files using
debugfs_remove_recursive(), so there
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so it's not necessary to call
drm_debugfs_remove_files(). Additionally it uses
debugfs_remove_recursive() to clean up the debugfs files, so no need
for adding fake drm_info_node entries.
Cc: benjamin.gaign...@linaro.o
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so the drm_driver.debugfs_cleanup callback is not
needed.
Cc: e...@anholt.net
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/vc4/vc4_debugfs.c | 6 --
drivers/gpu/drm/vc4/vc4_drv.c | 1 -
drivers/gpu/drm/
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so the drm_driver.debugfs_cleanup callback is not
needed.
Cc: airl...@linux.ie
Cc: kra...@redhat.com
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/qxl/qxl_debugfs.c | 9 -
drivers/gpu/drm/qxl/qxl_drv.c
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so no need to do this explicitly. Additionally it
uses debugfs_remove_recursive() to clean up the debugfs files,
so no need for adding fake drm_info_node entries.
Cc: daniel.vet...@intel.com
Cc: jani.nik...@linux.inte
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so the drm_driver.debugfs_cleanup callback is not
needed. Additionally it uses debugfs_remove_recursive() to clean
up the debugfs files, so no need for adding fake drm_info_node
entries.
Cc: bske...@redhat.com
Signed-
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so the drm_driver.debugfs_cleanup callback is not
needed.
Cc: airl...@linux.ie
Cc: kra...@redhat.com
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 8
drivers/gpu/drm/virtio/vi
This patchset removes the need for drivers to clean up their debugfs
files on exit. It is done automatically in drm_debugfs_cleanup().
This funtion is also called should the driver error out in it's
drm_driver.debugfs_init callback.
Two drivers still use drm_debugfs_remove_files():
- tegra in it's
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so no need to call drm_debugfs_remove_files().
Also remove empty drm_driver.debugfs_cleanup callback.
Cc: alexander.deuc...@amd.com
Cc: christian.koe...@amd.com
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/amd/
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so no need to call drm_debugfs_remove_files().
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_atomic.c| 7 ---
drivers/gpu/drm/drm_crtc_internal.h | 1 -
drivers/gpu/drm/drm_debugfs.c | 9 --
Make it possible to compile test the driver on other platforms.
Cc: l.st...@pengutronix.de
Cc: linux+etna...@armlinux.org.uk
Cc: christian.gmei...@gmail.com
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/etnaviv/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so the drm_driver.debugfs_cleanup callback is not
needed.
Cc: l.st...@pengutronix.de
Cc: linux+etna...@armlinux.org.uk
Cc: christian.gmei...@gmail.com
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/etnaviv/etnavi
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so the drm_driver.debugfs_cleanup callback is not
needed.
Cc: liviu.du...@arm.com
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/arm/hdlcd_drv.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/g
Instead of having the drivers call drm_debugfs_remove_files() in
their drm_driver->debugfs_cleanup hook, do it automatically by
traversing minor->debugfs_list.
Also use debugfs_remove_recursive() so drivers who add their own
debugfs files don't have to keep track of them for removal.
Signed-off-by
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so no need to do this explicitly. Additionally it
uses debugfs_remove_recursive() to clean up the debugfs files,
so no need for adding fake drm_info_node entries.
And finally there's no need to clean up on error,
drm_d
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so it's not necessary to call
drm_debugfs_remove_files(). Additionally it uses
debugfs_remove_recursive() to clean up the debugfs files, so no need
to do that.
Cc: robdcl...@gmail.com
Signed-off-by: Noralf Trønnes
--
Call drm_debugfs_cleanup() in case drm_debugfs_init() fails to
cover for failure in the drm_driver.debugfs_init callback.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/dr
On Thu, Jan 26, 2017 at 4:09 PM, Rob Herring wrote:
> On Thu, Jan 26, 2017 at 1:51 PM, Rob Clark wrote:
>> On Thu, Jan 26, 2017 at 2:11 PM, Rob Herring wrote:
>>> On Tue, Jan 24, 2017 at 11:11 AM, Rob Clark wrote:
So, cleaning up the GPU bindings is something that has been on my TODO
On Thu, Jan 26, 2017 at 1:51 PM, Rob Clark wrote:
> On Thu, Jan 26, 2017 at 2:11 PM, Rob Herring wrote:
>> On Tue, Jan 24, 2017 at 11:11 AM, Rob Clark wrote:
>>> So, cleaning up the GPU bindings is something that has been on my TODO
>>> list for a while, but always $bigger_fires. Existing bindi
On Thu, Jan 26, 2017 at 02:12:16PM -0500, Sean Paul wrote:
> On Thu, Jan 26, 2017 at 05:42:12PM +, Liviu Dudau wrote:
> > On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote:
> > > Hi all,
> >
> > Hi Daniel,
> >
> > >
> > > We've discussed this a bit at LCA (with Dave and Eric), an
On Thu, Jan 26, 2017 at 08:57:25PM +0100, Daniel Vetter wrote:
> Hi Liviu
>
> On Thu, Jan 26, 2017 at 05:42:12PM +, Liviu Dudau wrote:
> > On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote:
> > > We've discussed this a bit at LCA (with Dave and Eric), and it's
> > > probably best
https://bugs.freedesktop.org/show_bug.cgi?id=99555
Bug ID: 99555
Summary: LIBGL_ALWAYS_INDIRECT=1 causes all opengl programms to
crash on second frame
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS:
Hi Liviu
On Thu, Jan 26, 2017 at 05:42:12PM +, Liviu Dudau wrote:
> On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote:
> > We've discussed this a bit at LCA (with Dave and Eric), and it's
> > probably best if I just summarize all the questions and opens and
> > throw them out here
On Thu, Jan 26, 2017 at 2:11 PM, Rob Herring wrote:
> On Tue, Jan 24, 2017 at 11:11 AM, Rob Clark wrote:
>> So, cleaning up the GPU bindings is something that has been on my TODO
>> list for a while, but always $bigger_fires. Existing bindings are a bit
>> ugly, but served a purpose when too man
Daniel Vetter writes:
> Hi all,
>
> We've discussed this a bit at LCA (with Dave and Eric), and it's
> probably best if I just summarize all the questions and opens and
> throw them out here for discussions:
>
> - When's a driver small enough for a shared tree, and when is a
> separate tree a goo
https://bugs.freedesktop.org/show_bug.cgi?id=77907
Vedran Miletić changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=99552
Vedran Miletić changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=74973
Vedran Miletić changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=74974
Vedran Miletić changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=99488
Vedran Miletić changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=64201
Vedran Miletić changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Vedran Miletić changed:
What|Removed |Added
Depends on||97250, 99552, 99540, 99539,
https://bugs.freedesktop.org/show_bug.cgi?id=64201
Vedran Miletić changed:
What|Removed |Added
Summary|OpenCL usage result |bfgminer OpenCL usage
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug ID: 99553
Summary: Tracker bug for runnning OpenCL applications on Clover
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: nor
https://bugs.freedesktop.org/show_bug.cgi?id=99552
Bug ID: 99552
Summary: Make Advanced Simulation Library (ASL) OpenCL GPU
support work on Clover and RadeonSI
Product: Mesa
Version: git
Hardware: All
OS: Al
On Thu, Jan 26, 2017 at 04:54:37PM +0100, Daniel Vetter wrote:
> On Thu, Jan 26, 2017 at 02:46:55PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 26, 2017 at 11:44:09AM +, Chris Wilson wrote:
> > > Since moving drm_crtc_get_hv_timings() into drm_modes.c, the compiler
> > > has been able to get sm
On Tue, Jan 24, 2017 at 11:11 AM, Rob Clark wrote:
> So, cleaning up the GPU bindings is something that has been on my TODO
> list for a while, but always $bigger_fires. Existing bindings are a bit
> ugly, but served a purpose when too many of the other drivers the GPU
> depends on where still wo
On Thu, Jan 26, 2017 at 05:42:12PM +, Liviu Dudau wrote:
> On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote:
> > Hi all,
>
> Hi Daniel,
>
> >
> > We've discussed this a bit at LCA (with Dave and Eric), and it's
> > probably best if I just summarize all the questions and opens an
On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote:
> Hi all,
>
> We've discussed this a bit at LCA (with Dave and Eric), and it's
> probably best if I just summarize all the questions and opens and
> throw them out here for discussions:
>
> - When's a driver small enough for a shared
On Wed, Jan 11, 2017 at 02:57:20PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> While reading the HDMI 2.0 spec I noticed some new things related to
> the RGB quantization range stuff, and after cross checking with
> CEA-861-F I spotted a some other things as well. So I f
On Thu, Jan 26, 2017 at 10:55:51AM +0100, Maarten Lankhorst wrote:
> Op 25-01-17 om 19:05 schreef Sinclair Yeh:
> > On Wed, Jan 25, 2017 at 09:36:36AM +0100, Maarten Lankhorst wrote:
> >> Op 25-01-17 om 09:09 schreef Thomas Hellstrom:
> >>> On 01/25/2017 05:54 AM, Daniel Vetter wrote:
> On Tue
On Thu, Jan 26, 2017 at 11:20:53PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> It adds the TV Encoder driver to support video output in PAL and NTSC
> format. The driver uses syscon/regmap interface to configure register
> bit sitting in SYSCTRL module for DAC power control.
>
Reviewed-by: S
On Thu, Jan 26, 2017 at 11:20:49PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> It adds interlace mode support in VOU TIMING_CTRL and channel control
> block, so that VOU driver gets ready to support output device in
> interlace mode like TV Encoder.
>
Reviewed-by: Sean Paul
> Signed-off-by:
On Mon, Jan 09, 2017 at 06:06:57PM +0100, Maarten Lankhorst wrote:
> We're protected by the connection_mutex lock against blocking modesets,
> but nonblocking modesets are performed without any locking. This is
> causing WARN in drm_wait_for_vblank and in general it's better to wait
> before modese
Reviewed-By: Wladimir J. van der Laan
I do wonder whether we'll need the split formats in practice -
e.g. the GC3000 on the i.MX6qp, for which I suppose this is being done because
of tiled buffers support in the PRE, has the "single buffer" feature
which allows rendering to a single buffer with
On Mon, Jan 09, 2017 at 06:06:56PM +0100, Maarten Lankhorst wrote:
> This will allow i915 to perform a wait on pending modeset using the
> same code.
I don't like commit messages that refer to the subject like this. I
can't even see the subject when I'm replying so I have approximately
zero idea w
On Sun, Jan 22, 2017 at 12:34 PM, Emil Velikov wrote:
> Analogous to the autoconf build add the following to the build
>
>-Wno-unused-parameter
>-Wno-missing-field-initializers
>
> Cc: Chih-Wei Huang
> Cc: Rob Herring
> Signed-off-by: Emil Velikov
> ---
> According to Rob's jenkins buil
On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote:
> Hi all,
Hi Daniel,
>
> We've discussed this a bit at LCA (with Dave and Eric), and it's
> probably best if I just summarize all the questions and opens and
> throw them out here for discussions:
>
> - When's a driver small enough
On Thu, Jan 26, 2017 at 04:32:17PM +0100, Philipp Zabel wrote:
> Vivante GC hardware uses simple 4x4 tiled and nested 64x64 supertiled
> formats as well as so-called split-tiled variants for dual-pipe
> hardware, where even and odd tiles start at different base addresses.
>
> Signed-off-by: Philip
On Thu, Jan 26, 2017 at 02:37:28PM +0200, Martin Peres wrote:
> Despite all the careful planing of the kernel, a link may become
> insufficient to handle the currently-set mode. At this point, the
> kernel should mark this particular configuration as being broken
> and potentially prune the mode be
On Thu, Jan 26, 2017 at 04:48:45PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 23, 2017 at 09:23:52AM +0100, Daniel Vetter wrote:
> > On Fri, Jan 20, 2017 at 09:46:17PM +0200, Ville Syrjälä wrote:
> > > On Tue, Jan 17, 2017 at 05:43:29PM +0100, Takashi Iwai wrote:
> > > > This is just a cleanup, no f
Hi all,
We've discussed this a bit at LCA (with Dave and Eric), and it's
probably best if I just summarize all the questions and opens and
throw them out here for discussions:
- When's a driver small enough for a shared tree, and when is a
separate tree a good idea? i915 and amdgpu are definitely
On Thu, Jan 26, 2017 at 04:59:21PM +0100, Maarten Lankhorst wrote:
> When writing some testcases for nonblocking modesets. I found out that the
> infinite wait on the old fb was causing issues.
>
> A nonblocking modeset with a hang on the old fb, followed by a blocking
> update was enough to trigg
Am Donnerstag, den 26.01.2017, 09:29 -0700 schrieb Dave Jiang:
>
> On 01/26/2017 06:36 AM, Fabio Estevam wrote:
> > Commit 25d3db7600b87a4 ("mm, fs: reduce fault, page_mkwrite, and
> > pfn_mkwrite to take only vmf") causes the following build failure with
> > arm allmodconfig:
> >
> > drivers/gpu
On 26 January 2017 at 15:49, Thierry Reding wrote:
> On Fri, Jan 20, 2017 at 06:28:39PM +, Emil Velikov wrote:
>> On 20 January 2017 at 16:17, Thierry Reding wrote:
>> > On Fri, Jan 20, 2017 at 02:13:00PM +, Emil Velikov wrote:
>> >> On 19 January 2017 at 09:19, Thierry Reding wrote:
>>
On Thu, Jan 26, 2017 at 05:26:00PM +0200, Jani Nikula wrote:
> IIUC the alt fix should be for nouveau, and just the revert should be
> enough for i915.
I see.
/me goes and reverts 3846fd9b86001bea171943cc3bb9222cb6da6b42, builds, boots...
Yap, looks good, thanks.
:-)
--
Regards/Gruss,
Bor
When writing some testcases for nonblocking modesets. I found out that the
infinite wait on the old fb was causing issues.
A nonblocking modeset with a hang on the old fb, followed by a blocking
update was enough to trigger it.
For old platforms patch 2 is needed else
kms_busy.extended-modeset-ha
With the atomic helper for pageflips there are no CS flips when
that require resetting, so on most platforms we can completely
skip the locking.
Because we may end up reverting the page_flip patch add an explicit
function pointer check so that if someone reverts the page flip patch
there will not
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index b535f782b2c0..34338678db26 100644
--- a/drivers/gpu/drm/drm_at
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7c19b3c7a4ee..35d25e58a37e 100644
--- a/drivers/gpu/drm/i915/intel_displ
On Thu, Jan 26, 2017 at 02:46:55PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 26, 2017 at 11:44:09AM +, Chris Wilson wrote:
> > Since moving drm_crtc_get_hv_timings() into drm_modes.c, the compiler
> > has been able to get smarter and spots that drm_mode_copy() is trying to
> > preserve garbage
On Fri, Jan 20, 2017 at 06:28:39PM +, Emil Velikov wrote:
> On 20 January 2017 at 16:17, Thierry Reding wrote:
> > On Fri, Jan 20, 2017 at 02:13:00PM +, Emil Velikov wrote:
> >> On 19 January 2017 at 09:19, Thierry Reding wrote:
> >> > On Wed, Jan 18, 2017 at 02:59:21PM +0100, Neil Armstr
Hi Dave,
Hope I'm not too late before the cutoff for the v4.11 with these patches.
Mostly an asorted set of fixes that we have discovered while playing with
the code and preparing for the next set of features.
Best regards,
Liviu
The following changes since commit f0493e653f9679114d1dfd54ab88b54
Vivante GC hardware uses simple 4x4 tiled and nested 64x64 supertiled
formats as well as so-called split-tiled variants for dual-pipe
hardware, where even and odd tiles start at different base addresses.
Signed-off-by: Philipp Zabel
---
include/uapi/drm/drm_fourcc.h | 41
Add the fb->offset[] value to the plane's physical start address
registe. Without that, packed formats are rendered incorrectly.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_planes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/g
1 - 100 of 160 matches
Mail list logo