receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/dd5a645e/attachment.html>
Hi Shunqian,
On Wed, Jun 15, 2016 at 9:04 PM, Shunqian Zheng
wrote:
> Use DMA API instead of architecture internal functions like
> __cpuc_flush_dcache_area() etc.
>
> To support the virtual device like DRM the virtual slave iommu
> added in the previous patch, attaching to which the DRM can use
Hi Shunqian,
On Wed, Jun 15, 2016 at 9:04 PM, Shunqian Zheng
wrote:
> Rockchip DRM used the arm special API, arm_iommu_*(), to attach
> iommu for ARM32 SoCs. This patch convert to common iommu API
> so it would support ARM64 like RK3399.
>
> The general idea is domain_alloc(), attach_device() an
Hi Shunqian,
On Wed, Jun 15, 2016 at 9:04 PM, Shunqian Zheng
wrote:
> An virtual master device like DRM need to attach to iommu
> domain to share the mapping with VOPs(the one with actual
> iommu slaves).
> DRM attaches to iommu and allocates buffers before VOPs enabled,
> which means there may
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/b7bf3909/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/7d516335/attachment.html>
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/a1405198/attachment.html>
Am 15.06.2016 um 22:15 schrieb Arnd Bergmann:
> In the AMD powerplay driver, a pointer is checked for validity by
> comparing against an integer '0', which causes a harmless warning
> when building with "make W=1":
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/processpptables.c:1502:16:
> erro
On Wed, Jun 15, 2016 at 10:05 PM, Russell King - ARM Linux
wrote:
> On Wed, Jun 15, 2016 at 09:29:38PM +0200, Daniel Vetter wrote:
>> On Wed, Jun 15, 2016 at 7:21 PM, Liviu Dudau wrote:
>> > Could be the tda998x_drv fault, but I'm getting this splat:
>>
>> Yeah, tda9998x needs to be fixed to _not
In the AMD powerplay driver, a pointer is checked for validity by
comparing against an integer '0', which causes a harmless warning
when building with "make W=1":
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/processpptables.c:1502:16: error:
ordered comparison of pointer with integer zero [-Werr
From: Arnd Bergmann
Date: Wed, 15 Jun 2016 17:45:51 +0200
> The skfp driver has been moved to drivers/net/fddi/skfp a long time
> ago, but we still attempt to include headers from the old location,
> which causes a warning when building with W=1:
>
> cc1: error: /git/arm-soc/drivers/net/skfp: No
On Wed, Jun 15, 2016 at 6:33 PM, Chris Wilson
wrote:
> On Wed, Jun 15, 2016 at 06:01:41PM +0200, Daniel Vetter wrote:
>> On Wed, Jun 15, 2016 at 01:10:35PM +0100, Chris Wilson wrote:
>> > On Tue, Jun 14, 2016 at 08:51:07PM +0200, Daniel Vetter wrote:
>> > > There can only be one current master, a
On Wed, Jun 15, 2016 at 7:21 PM, Liviu Dudau wrote:
> On Wed, Jun 15, 2016 at 07:13:15PM +0200, Daniel Vetter wrote:
>> On Wed, Jun 15, 2016 at 6:17 PM, Liviu Dudau wrote:
>> > On Wed, Jun 15, 2016 at 05:23:10PM +0200, Daniel Vetter wrote:
>> >> On Wed, Jun 15, 2016 at 03:51:34PM +0100, Liviu Dud
Enable the basic hdmi audio function on rk3036 kylin board.
Signed-off-by: Yakir Yang
---
arch/arm/boot/dts/rk3036-kylin.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/rk3036-kylin.dts
b/arch/arm/boot/dts/rk3036-kylin.dts
index 1df1557..070cfe1 100644
--- a/arch/a
Using I2S as the audio input source, and force the mclk_fs to 256.
Signed-off-by: Yakir Yang
---
arch/arm/boot/dts/rk3036.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 843d2be..ecff071 100644
-
Using the common hdmi-codec driver to support hdmi audio function.
Signed-off-by: Yakir Yang
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 237 ++-
drivers/gpu/drm/rockchip/inno_hdmi.h | 2 +
2 files changed, 237 insertions(+), 2 deletions(-)
diff --git a/drivers/
On Wed, Jun 15, 2016 at 06:21:04PM +0100, Liviu Dudau wrote:
> Could be the tda998x_drv fault, but I'm getting this splat:
>
> [1.347687] kobject_add_internal failed for card0-HDMI-A-1 (error: -2
> parent: card0)
Right, so this is -ENOENT - I expect that it's complaining that the
parent does
On Wed, Jun 15, 2016 at 09:29:38PM +0200, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 7:21 PM, Liviu Dudau wrote:
> > Could be the tda998x_drv fault, but I'm getting this splat:
>
> Yeah, tda9998x needs to be fixed to _not_ register it's connector
> before the overall (componentized) driver is
From: Simon Xue
This patch makes it possible to compile the rockchip-iommu driver on
ARM64 platform to be used with 64-bit SoCs equipped with this type
of IOMMU.
Signed-off-by: Simon Xue
Signed-off-by: Shunqian Zheng
Reviewed-by: Tomasz Figa
---
drivers/iommu/Kconfig | 2 +-
1 file changed,
Use DMA API instead of architecture internal functions like
__cpuc_flush_dcache_area() etc.
To support the virtual device like DRM the virtual slave iommu
added in the previous patch, attaching to which the DRM can use
it own domain->dev for dma_map_*(), dma_sync_*() even VOP is disabled.
With th
Rockchip DRM used the arm special API, arm_iommu_*(), to attach
iommu for ARM32 SoCs. This patch convert to common iommu API
so it would support ARM64 like RK3399.
The general idea is domain_alloc(), attach_device() and
arch_setup_dma_ops() to set dma_ops manually for DRM at the last.
Signed-off-
An virtual master device like DRM need to attach to iommu
domain to share the mapping with VOPs(the one with actual
iommu slaves).
DRM attaches to iommu and allocates buffers before VOPs enabled,
which means there may have not real iommu devices can be used
to do dma mapping.
This patch creates a
From: Simon Xue
The iommu_dma_alloc() in iommu/dma-iommu.c calls iommu_map_sg()
that requires the callback iommu_ops .map_sg(). Adding the
default_iommu_map_sg() to rockchip iommu accordingly.
Signed-off-by: Simon Xue
Signed-off-by: Shunqian Zheng
Reviewed-by: Tomasz Figa
---
drivers/iommu/r
From: Simon Xue
Even though the iommu shares irq with its master, using the *dev of iommu
instead of master's *dev for devm_{request,free}_irq makes things clear.
Signed-off-by: Simon Xue
Signed-off-by: Shunqian Zheng
Reviewed-by: Tomasz Figa
---
drivers/iommu/rockchip-iommu.c | 4 ++--
1 fi
This series patches mainly for ARM64 supporting.
To do this, it first add virtual iommu slave device which DRM can attach to,
convert DRM driver to use common iommu API instead of the ARM32
functions, and then use DMA API in iommu driver to map, to flush cache.
Mainly changes of V3:
- Instead
Hi Dave,
radeon and amdgpu fixes for 4.7. Highlights:
- fixes for GPU VM passthrough
- fixes for powerplay on Polaris GPUs
- pll fixes for rs780/880
The following changes since commit 27bf60db2485c09eba3b473ce5ffbaa4bba0c24e:
Merge tag 'drm-amdkfd-fixes-2016-06-03' of
git://people.freedeskto
On Wed, Jun 15, 2016 at 7:13 PM, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 6:17 PM, Liviu Dudau wrote:
>> On Wed, Jun 15, 2016 at 05:23:10PM +0200, Daniel Vetter wrote:
>>> On Wed, Jun 15, 2016 at 03:51:34PM +0100, Liviu Dudau wrote:
>>> > Add support for the new family of Display Processors
On Wed, Jun 15, 2016 at 6:17 PM, Liviu Dudau wrote:
> On Wed, Jun 15, 2016 at 05:23:10PM +0200, Daniel Vetter wrote:
>> On Wed, Jun 15, 2016 at 03:51:34PM +0100, Liviu Dudau wrote:
>> > Add support for the new family of Display Processors from ARM Ltd.
>> > This commit adds basic support for Mali
On Wed, Jun 15, 2016 at 06:35:37PM +0100, Chris Wilson wrote:
> On Wed, Jun 15, 2016 at 06:21:04PM +0100, Liviu Dudau wrote:
> > On Wed, Jun 15, 2016 at 07:13:15PM +0200, Daniel Vetter wrote:
> > > On Wed, Jun 15, 2016 at 6:17 PM, Liviu Dudau
> > > wrote:
> > > > On Wed, Jun 15, 2016 at 05:23:10P
On Wed, Jun 15, 2016 at 06:21:04PM +0100, Liviu Dudau wrote:
> On Wed, Jun 15, 2016 at 07:13:15PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 15, 2016 at 6:17 PM, Liviu Dudau wrote:
> > > On Wed, Jun 15, 2016 at 05:23:10PM +0200, Daniel Vetter wrote:
> > >> On Wed, Jun 15, 2016 at 03:51:34PM +0100
On Wed, Jun 15, 2016 at 07:13:15PM +0200, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 6:17 PM, Liviu Dudau wrote:
> > On Wed, Jun 15, 2016 at 05:23:10PM +0200, Daniel Vetter wrote:
> >> On Wed, Jun 15, 2016 at 03:51:34PM +0100, Liviu Dudau wrote:
> >> > Add support for the new family of Display
On Wed, Jun 15, 2016 at 04:35:24PM +0100, Eric Engestrom wrote:
> On Wed, Jun 15, 2016 at 03:51:35PM +0100, Liviu Dudau wrote:
> > Add MAINTAINERS entry for ARM Mali-DP driver and update the
> > HDLCD file matching pattern to cover only HDLCD rather than
> > the whole drivers/gpu/drm/arm directory.
On Wed, Jun 15, 2016 at 01:10:35PM +0100, Chris Wilson wrote:
> On Tue, Jun 14, 2016 at 08:51:07PM +0200, Daniel Vetter wrote:
> > There can only be one current master, and it's for the overall device.
> > Render/control minors don't support master-based auth at all.
> >
> > This simplifies the ma
On Wed, Jun 15, 2016 at 12:54:24PM +0100, Chris Wilson wrote:
> On Tue, Jun 14, 2016 at 08:51:04PM +0200, Daniel Vetter wrote:
> > Simplifies cleanup, and there's no reason drivers should ever care
> > about authmagic at all - it's all handled in the core.
> >
> > And with that, Ladies and Gentlem
On Wed, Jun 15, 2016 at 12:48:23PM +0100, Chris Wilson wrote:
> On Tue, Jun 14, 2016 at 08:51:02PM +0200, Daniel Vetter wrote:
> > Another place gone where modern drivers could have hit
> > dev->struct_mutex.
> >
> > To avoid too deeply nesting control flow rework it a bit.
> >
> > Signed-off-by:
On Wed, Jun 15, 2016 at 12:31:20PM +0100, Chris Wilson wrote:
> On Tue, Jun 14, 2016 at 08:50:59PM +0200, Daniel Vetter wrote:
> > For modern drivers pretty much the only thing drm_master does is
> > handling authentication for the primary/legacy drm_minor node. Instead
> > of having it all over dr
I have fixed up all -Wmissing-include-dirs on ARM randconfig builds,
so we could make this the default, but I have not tested this at all
on other architectures.
This enables it anyway, just to see what other warnings we get
when the build bot analyses the branch.
Don't apply (yet).
Signed-off-b
For rtl8188ee, we pass -Idrivers/net/wireless/rtlwifi/ to gcc,
however that directy no longer exists, so evidently this option
is no longer required here and can be removed to avoid a warning
when building with 'make W=1' or 'gcc -Wmissing-include-dirs'
Signed-off-by: Arnd Bergmann
---
drivers/n
The skfp driver has been moved to drivers/net/fddi/skfp a long time
ago, but we still attempt to include headers from the old location,
which causes a warning when building with W=1:
cc1: error: /git/arm-soc/drivers/net/skfp: No such file or directory
[-Werror=missing-include-dirs]
cc1: error: dr
The AMD ACP driver adds "-I../acp -I../acp/include" to the gcc command
line, which makes no sense, since these are evaluated relative to the
build directory. When we build with "make W=1", they instead cause
a warning:
cc1: error: ../acp/: No such file or directory [-Werror=missing-include-dirs]
c
The machine specific header files are exported for traditional
platforms, but not for the ones that use ARCH_MULTIPLATFORM, as
they could conflict with one another.
In case of ARM_SINGLE_ARMV7M, we end up also exporting them,
but that appears to be a mistake, and we should treat it the
same way as
On Wed, Jun 15, 2016 at 01:50:02PM +0100, Emil Velikov wrote:
> On 14 June 2016 at 19:50, Daniel Vetter wrote:
> > Master-based auth only exists for the legacy/primary drm_minor, hence
> > there can only be one per device. The goal here is to untangle the
> > epic dereference games of minor->maste
Three platforms used to have header files in include/mach that
are now all gone, but the removed directories are still being
included, which leads to -Wmissing-include-dirs warnings.
This removes the extra -I flags.
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-mvebu/Makefile| 3 +--
arch/
When building with separate object directories and driver specific
Makefiles that add additional header include paths, Kbuild adjusts
the gcc flags so that we include both the directory in the source
tree and in the object tree.
However, due to another bug I fixed earlier, this did not actually
in
There are very few files that need add an -I$(obj) gcc for the preprocessor
or the assembler. For C files, we add always these for both the objtree and
srctree, but for the other ones we require the Makefile to add them, and
Kbuild then adds it for both trees.
As a preparation for changing the mea
When $(LINUXINCLUDE) is added to the cflags of a target that
normall doesn't have it (e.g. HOSTCFLAGS), each entry in the
list is expanded so that we search both $(objtree) and $(srctree),
which is a bit silly, as we already know which of the two we
want for each entry in LINUXINCLUDE.
Also, a fol
arch/$(hdr-arch)/include/generated/uapi is included twice in the
header search path, which is unnecessary, so this changes the
top-level Makefile to drop the second instance by filtering out
everything from USERINCLUDE that was already part of LINUXINCLUDE.
This should have very little effect othe
When we build with O=objdir and objdir is directly below the source tree,
$(srctree) becomes '..'.
When a Makefile adds a CFLAGS option like -Ipath/to/headers and
we are building with a separate object directory, Kbuild tries to
add two -I options, one for the source tree and one for the object
tr
This warning is enabled at "make W=1" level, and found a bunch of
actual problems in code that adds -I flags to nonexisting directories.
All of these are harmless, but clearly wrong.
Kbuild itself also adds a bunch of extra directories, including in
some cases those outside of the kernel tree (e.g
On Tue, Jun 14, 2016 at 11:48:31PM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> More misc stuff all over:
> - best_encoder cleanup from Boris.
> - drm_simple_display_pipe helpers from Noralf. Looks really neat imo, and
> there's 2-3 in-flight drivers which look like they could/should use it.
> A
Hi Dave,
I would like to add the Mali DP driver to the drm-next tree.
It has got several reviews and now the Acks from the relevant people.
The tree is based on drm-intel/topic/drm-misc tree with tag
topic/drm-misc-2016-06-14 and also needs two patches from Daniel to
function correctly [1][2]. H
On Wed, Jun 15, 2016 at 06:01:41PM +0200, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 01:10:35PM +0100, Chris Wilson wrote:
> > On Tue, Jun 14, 2016 at 08:51:07PM +0200, Daniel Vetter wrote:
> > > There can only be one current master, and it's for the overall device.
> > > Render/control minors
On Wed, Jun 15, 2016 at 4:32 PM, Christian König
wrote:
> Am 15.06.2016 um 22:15 schrieb Arnd Bergmann:
>>
>> In the AMD powerplay driver, a pointer is checked for validity by
>> comparing against an integer '0', which causes a harmless warning
>> when building with "make W=1":
>>
>> drivers/gpu/
On Wed, Jun 15, 2016 at 03:29:16PM +0100, Liviu.Dudau at arm.com wrote:
> On Wed, Jun 15, 2016 at 12:24:26PM +0200, Daniel Vetter wrote:
> > It's not obvious at first sight that this is a fastpath, make that
> > clearer with a goto. Fallout from a discussion with Liviu on irc.
> >
> > v2: Drop bog
On Wed, Jun 15, 2016 at 03:51:34PM +0100, Liviu Dudau wrote:
> Add support for the new family of Display Processors from ARM Ltd.
> This commit adds basic support for Mali DP500, DP550 and DP650
> parts, with only the display engine being supported at the moment.
>
> Cc: David Brown
> Cc: Brian S
On Wed, Jun 15, 2016 at 06:12:08PM +0200, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 04:35:24PM +0100, Eric Engestrom wrote:
> > On Wed, Jun 15, 2016 at 03:51:35PM +0100, Liviu Dudau wrote:
> > > Add MAINTAINERS entry for ARM Mali-DP driver and update the
> > > HDLCD file matching pattern to co
On Wed, Jun 15, 2016 at 04:03:04PM +0100, Liviu Dudau wrote:
> Hi Stephen,
>
> I would like to add the Mali DP DRM driver tree to linux-next. I'm planning
> to send a pull request for inclusion into v4.8 and I hope that getting a
> wider exposure for a few weeks is beneficial.
>
> Please add the
On Wed, Jun 15, 2016 at 05:23:10PM +0200, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 03:51:34PM +0100, Liviu Dudau wrote:
> > Add support for the new family of Display Processors from ARM Ltd.
> > This commit adds basic support for Mali DP500, DP550 and DP650
> > parts, with only the display en
On Tue, Jun 14, 2016 at 11:48:31PM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> More misc stuff all over:
> - best_encoder cleanup from Boris.
> - drm_simple_display_pipe helpers from Noralf. Looks really neat imo, and
> there's 2-3 in-flight drivers which look like they could/should use it.
> A
On Wed, Jun 15, 2016 at 05:21:02PM +0200, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 04:03:04PM +0100, Liviu Dudau wrote:
> > Hi Stephen,
> >
> > I would like to add the Mali DP DRM driver tree to linux-next. I'm planning
> > to send a pull request for inclusion into v4.8 and I hope that getti
On Wed, Jun 15, 2016 at 01:37:35PM +0200, Lukas Wunner wrote:
> On Tue, Jun 14, 2016 at 04:18:00PM -0400, Alex Deucher wrote:
> > On Thu, Jun 9, 2016 at 2:50 AM, Daniel Vetter wrote:
> > > On Wed, Jun 08, 2016 at 06:47:27PM +0200, Lukas Wunner wrote:
> > >> Second iteration of my endeavour to rid
On 14.06.2016 17:06, Daniel Vetter wrote:
> On Tue, Jun 14, 2016 at 04:25:28PM +0900, Michel Dänzer wrote:
>> On 14.06.2016 14:53, Daniel Vetter wrote:
>>> On Tue, Jun 14, 2016 at 11:09:10AM +0900, Michel Dänzer wrote:
On 06/13/16 23:06, Daniel Vetter wrote:
> On Mon, Jun 13, 2016 at 05:
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/b9ec4dd4/attachment.html>
On 06/14/2016 01:12 PM, Boris Brezillon wrote:
> Add basic support for the sii902x RGB -> HDMI bridge.
> This driver does not support audio output yet.
>
Thanks for incorporating the comments.
Acked-by: Archit Taneja
> Signed-off-by: Boris Brezillon
> Tested-by: Nicolas Ferre
> ---
> Change
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/55109b45/attachment.html>
On Wed, Jun 15, 2016 at 03:51:35PM +0100, Liviu Dudau wrote:
> Add MAINTAINERS entry for ARM Mali-DP driver and update the
> HDLCD file matching pattern to cover only HDLCD rather than
> the whole drivers/gpu/drm/arm directory.
>
> Signed-off-by: Liviu Dudau
> ---
> MAINTAINERS | 10 +-
>
On 14.06.2016 18:35, Daniel Vetter wrote:
> On Tue, Jun 14, 2016 at 11:09 AM, Michel Dänzer
> wrote:
>> On 14.06.2016 18:03, Daniel Vetter wrote:
>>> Somehow this escaped us, this is a KMS ioctl which should only be used
>>> by the master (which is the thing that's also in control of kms
>>> res
Hi Stephen,
I would like to add the Mali DP DRM driver tree to linux-next. I'm planning
to send a pull request for inclusion into v4.8 and I hope that getting a
wider exposure for a few weeks is beneficial.
Please add the following git tree:
git://linux-arm.org/linux-ld for-upstream/mali-dp
Add MAINTAINERS entry for ARM Mali-DP driver and update the
HDLCD file matching pattern to cover only HDLCD rather than
the whole drivers/gpu/drm/arm directory.
Signed-off-by: Liviu Dudau
---
MAINTAINERS | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/
Add support for the new family of Display Processors from ARM Ltd.
This commit adds basic support for Mali DP500, DP550 and DP650
parts, with only the display engine being supported at the moment.
Cc: David Brown
Cc: Brian Starkey
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/Kconfig
Add DT bindings documentation for the Mali Display Processor. The bindings
describe the Mali DP500, DP550 and DP650 processors from ARM Ltd.
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Liviu Dudau
Acked-by: Rob Herring
---
.../devicetree/bindings/display/
Hello,
This is the fifth revision of the driver for the Mali Display Processors (Mali
DP).
Currently, the driver supports the Display Engine found in Mali DP500, DP550
and DP650, with up to 3 planes that can be rotated by the hardware. There are
features that the hardware supports that are not cu
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/fc59c57a/attachment.html>
x27;s still a kernel bug.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/b2a32da6/attachment-0001.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/6f4d1276/attachment-0001.html>
On Fri, Jun 03, 2016 at 03:21:30PM +0100, Russell King wrote:
> Convert DT component matching to use component_match_add_release().
>
> Signed-off-by: Russell King
> ---
> drivers/iommu/mtk_iommu.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
Applied, thanks.
On Wed, Jun 15, 2016 at 12:24:26PM +0200, Daniel Vetter wrote:
> It's not obvious at first sight that this is a fastpath, make that
> clearer with a goto. Fallout from a discussion with Liviu on irc.
>
> v2: Drop bogus hunks that crept in.
>
> Cc: Liviu.Dudau at arm.com
> Acked-by: Liviu.Dudau at
On 06/15/16 11:39, Jyri Sarha wrote:
> Some fixes and cleanups that should get merged to tilcdc even if my
> atomic changes are still a work in progress.
>
I forgot to add changelog. So here it is:
Changes since first version:
- "drm/tilcdc: Restore old dpms state in pm_resume()"
- Fix typos f
Alex do you want to pull that in through your branches or should I send
Dave a separate pull request for the TTM changes?
BTW: I'm trying to enable this on radeon as well. In theory it should
work out of the box.
Regards,
Christian.
Am 15.06.2016 um 13:44 schrieb Christian König:
> From: Chri
On Tue, Jun 14, 2016 at 07:50:58PM +0200, Daniel Vetter wrote:
> stall_checks carefully picked out the right commit to stall on, then
> promptly used the wrong variable. Due to the break in the next loop
> iteration this could be the 3rd commit, or if the list only has 2
> entries commit would now
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/6f957803/attachment.html>
On 15 June 2016 at 13:49, Dave Airlie wrote:
> Excuse me for top posting.
>
> So I finally got back to this patch, still don't like it.
>
> Apart from the doing 3 things in once which is just annoying, current
> userspace for tiled monitors
> relies on the behaviour that the cached edids are retri
Ulf Hansson writes:
> Due to the previous changes to genpd, which removed the suspend_power_off
> flag, several of the system PM callbacks is no longer doing any additional
> checks but only invoking a corresponding pm_generic_* helper function.
>
> To clean up the code let's remove these wrapper
Ulf Hansson writes:
> If the PM domain is powered off when the first device starts its system PM
> prepare phase, genpd prevents any further attempts to power on the PM
> domain during the following system PM phases. Not until the system PM
> complete phase is finalized for all devices in the PM
On 06/15/2016 01:11 PM, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 10:37:24AM +0200, Paul Bolle wrote:
>> [Added Sinclair, Thomas, and "VMware Graphics".]
>>
>> On do, 2016-04-14 at 07:34 -0700, Joe Perches wrote:
>>> On Thu, 2016-04-14 at 13:32 +0200, Paul Bolle wrote:
On do, 2016-03-03 a
On 14 June 2016 at 19:50, Daniel Vetter wrote:
> Master-based auth only exists for the legacy/primary drm_minor, hence
> there can only be one per device. The goal here is to untangle the
> epic dereference games of minor->master and master->minor which is
> just massively confusing.
>
Good riddan
Excuse me for top posting.
So I finally got back to this patch, still don't like it.
Apart from the doing 3 things in once which is just annoying, current
userspace for tiled monitors
relies on the behaviour that the cached edids are retrieved before the
connector is show to userspace.
This is s
From: Christian König
This boosts Xonotic from 38fps to 47fps when artificially limiting VRAM to
256MB for testing. It should improve all CPU bound rendering situations
where we have a lot of swapping to/from VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |
From: Christian König
When we pipeline evictions the page directory could already be
moving somewhere else when grab_id is called.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++
2 files changed, 4 insertion
From: Christian König
Free up the memory immediately, remember the last eviction for each domain and
make new allocations depend on the last eviction to be completed.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 49 ++---
drivers/gpu/drm/ttm/ttm_bo_u
From: Christian König
As far as I can see no need for a custom implementation any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 37 -
1 file changed, 4 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/dr
From: Christian König
Instead of using the flag just remember the fence of the last move operation.
This avoids waiting for command submissions pipelined after the move, but
before accessing the BO with the CPU again.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 4
From: Christian König
It isn't used and not waiting for the GPU after scheduling a move is
actually quite dangerous.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 +--
drivers/gpu/drm/nouveau/nouveau_bo.c| 1 -
drivers/gpu/drm/radeon/radeon_ttm.c | 3
On Tue, Jun 14, 2016 at 04:18:00PM -0400, Alex Deucher wrote:
> On Thu, Jun 9, 2016 at 2:50 AM, Daniel Vetter wrote:
> > On Wed, Jun 08, 2016 at 06:47:27PM +0200, Lukas Wunner wrote:
> >> Second iteration of my endeavour to rid nouveau, radeon and amdgpu of
> >> runtime pm ref leaks.
> >>
> >> Pat
When trying to split up the initialisation phase and the registration
phase, one immediate problem encountered is trying to use our own i2c
devices before registration with userspace (to read EDID during device
discovery). drm_dp_aux in particular only offers an interface for setting
up the device
Rather than have both drm_dp_aux lock within its transfer, and i2c to
lock around the transfer, use the same lock by filling in the locking
callbacks that i2c wants to use. We require our own hw_mutex as we
bypass i2c_transfer for drm_dp_dpcd_access().
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Up to now, the recommendation was for drivers to call drm_dev_register()
followed by drm_connector_register_all(). Now that
drm_connector_register() is safe against multiple invocations, we can
move drm_connector_register_all() to drm_dev_register() and not suffer
from any backwards compatibility i
Up to now, the recommendation was for drivers to call drm_dev_register()
followed by drm_connector_register_all(). Now that
drm_connector_register() is safe against multiple invocations, we can
move drm_connector_register_all() to drm_dev_register() and not suffer
from any backwards compatibility i
Up to now, the recommendation was for drivers to call drm_dev_register()
followed by drm_connector_register_all(). Now that
drm_connector_register() is safe against multiple invocations, we can
move drm_connector_register_all() to drm_dev_register() and not suffer
from any backwards compatibility i
Up to now, the recommendation was for drivers to call drm_dev_register()
followed by drm_connector_register_all(). Now that
drm_connector_register() is safe against multiple invocations, we can
move drm_connector_register_all() to drm_dev_register() and not suffer
from any backwards compatibility i
1 - 100 of 168 matches
Mail list logo