are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150306/252cd1e2/attachment.html>
This patch fixes DRM_EXYNOS7DECON to DRM_EXYNOS7_DECON.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index a5e7461..0a67803 100644
--- a/drivers/gp
On 2015ë
02ì 18ì¼ 02:14, Charles Keepax wrote:
> The commit "drm/exynos: remove exynos_plane_dpms" (d9ea6256) removed the
> use of the enabled flag, which means that the code may attempt to call
> win_enable on a NULL crtc. This results in the following oops on
Hmm... it's strange. plane->fun
When registering drivers, the symlinks for mapping between driver
and module are created in sysfs. But the drm drivers registered
by drm_pci_init() create wrong symlinks, because correct owner
module of pci driver is not passed to pci_register_driver().
For example, the i915 driver creates the fo
Hi Linus,
radeon, imx, msm, i915 fixes,
the msm, imx and i915 ones are fairly run of the mill,
radeon had some DP audio and posting reads for irq fixes,
along with a fix for 32-bit kernels with new cards, we were
using unsigned long to represent GPU side memory space, but
since that changed siz
On 2015ë
02ì 20ì¼ 19:54, Dan Carpenter wrote:
> of_iomap() doesn't return error pointers, it returns NULL on error.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> ind
On 2015ë
02ì 18ì¼ 20:17, Andrzej Hajda wrote:
> These files are not used anymore.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_connector.c | 245
> --
> drivers/gpu/drm/exynos/exynos_drm_connector.h | 20 --
"defaul" -> "default"
Signed-off-by: Vincent Batts
---
drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 5d684be..3b00690 100644
--- a/drivers/gpu/drm/radeon/rad
Hi Rob,
> On Fri, Mar 6, 2015 at 1:12 PM, Rob Clark wrote:
>> On Thu, Mar 5, 2015 at 3:20 PM, Hai Li wrote:
>>> The framebuffer var width and height should reflect the size of
>>> framebuffer memory allocated, which is the entire surface size.
>>>
>>> In case of dual DSI connectors with TILE pro
This reverts commit 080b4929b7452dc1fea32ac1d32e7e571e7fb38b.
Chris noticed that "negative values wait forever" is indeed intended
behaviour and the issue is just that we didn't have a testcase (fixed
now) and that a regression slipped through (fixed and on track for all
stable kernels).
So lets
This reverts commit 080b4929b7452dc1fea32ac1d32e7e571e7fb38b.
Chris noticed that "negative values wait forever" is indeed intended
behaviour and the issue is just that we didn't have a testcase (fixed
now) and that a regression slipped through (fixed and on track for all
stable kernels).
So lets
Hi Dave,
drm-intel-next-2015-02-27:
- Y tiling support for scanout from Tvrtko&Damien
- Remove more UMS support
- some small prep patches for OLR removal from John Harrison
- first few patches for dynamic pagetable allocation from Ben Widawsky, rebased
by tons of other people
- DRRS support patc
On 03/06/15 17:36, Tony Lindgren wrote:
> * Jyri Sarha [150306 07:37]:
>> Use new binding for the external tda19988 HDMI encoder.
>
> Can this be merged separately after the driver code is
> merged with things still working?
>
Yes absolutely. That is why DRM_TILCDC_SLAVE_COMPAT is there for.
Che
Use new binding for the external tda19988 HDMI encoder.
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am335x-boneblack.dts | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
If I read Documentation/kbuild/makefiles.txt section 3.6 right, this
patch should not be needed. However, without this patch the objects
needed for DRM_TILCDC_SLAVE_COMPAT are not linked, if DRM_TILCDC is
built as module.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/Makefile | 1 +
1 file chang
Adds a CONFIG_DRM_TILCDC_SLAVE_COMPAT module for "ti,tilcdc,slave"
node conversion. The implementation is in tilcdc_slave_compat.c and it
uses tilcdc_slave_compat.dts as a basis for creating a DTS
overlay. The DTS overlay adds an external tda998x encoder to tilcdc
that corresponds to the old tda998
This patch should be dropped/reverterd if/after "of: Decrement refcount
of previous endpoint in of_graph_get_next_endpoint" patch has been
merged.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_external.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tilcdc/til
Add support for an external compontised DRM encoder. The external
encoder can be connected to tilcdc trough device tree graph binding.
The binding document for tilcdc has been updated. The current
implementation supports only tda998x encoder.
I got the idea and some lines of code from Jean-Francoi
Remove tilcdc slave support for tda998x driver. The tilcdc slave
support would conflicts with componentized use of tda998x.
Signed-off-by: Jyri Sarha
---
.../devicetree/bindings/drm/tilcdc/slave.txt | 18 -
drivers/gpu/drm/tilcdc/Makefile| 1 -
drivers/gpu/drm/tilcdc
Force crtc dpms off before destroying the crtc instead of just
checking the dpms state. This fixes warning message and frozen picture
after tilcdc module unloading.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --
Changes since first version of the patch-set:
- Rename DRM_TILCDC_INIT to DRM_TILCDC_SLAVE_COMPAT and make it visible
- Add separate:
drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint
- Reduce info-level spam
- Use component_master_add_with_match()
- Be more explicit abou
Hi Sean, Hans,
I am sorry to reply so late, I was busy with other work. I am preparing the
next version
of the CEC framework and I would like to discuss your comment.
From: Sean Young [mailto:s...@mess.org]
Sent: Friday, January 23, 2015 12:08 PM
>
> On Thu, Jan 22, 2015 at 05:04:35PM +0100, Kam
On Fri, Mar 6, 2015 at 1:49 PM, Bjorn Helgaas wrote:
> On Tue, Feb 24, 2015 at 03:23:27PM -0500, Alex Deucher wrote:
>> On Tue, Feb 24, 2015 at 3:12 PM, Alex Williamson
>> wrote:
>> > I'd kinda like to use pci_ignore_hotplug() for devices in use by a
>> > user via vfio-pci, but the interface seem
--enable-install-test-programs allows tests to be installed in $bindir.
This is disabled by default, but very useful when cross compiling.
Signed-off-by: Daniel Kurtz
---
tests/proptest/Makefile.am | 5 +
1 file changed, 5 insertions(+)
diff --git a/tests/proptest/Makefile.am b/tests/propte
There is a rockchip drm kms driver.
Add "rockchip" to the static lists of driver names in the the standard
set of tests.
Signed-off-by: Daniel Kurtz
---
tests/kmstest/main.c | 1 +
tests/modetest/modetest.c | 2 +-
tests/proptest/proptest.c | 2 +-
tests/vbltest/vbltest.c | 2 +-
4 files
We don't want tile 0,0 to artificially constrain the size of the legacy
fbdev device. Instead when reducing fb_size to be the minimum of all
displays, only consider the rightmost and bottommost tiles.
Signed-off-by: Rob Clark
Tested-by: Hai Li
---
drivers/gpu/drm/drm_fb_helper.c | 26 +
Flip conditional to reduce indentation level of rest of fxn, and use
min/max to make the code clearer.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_fb_helper.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b
Signed-off-by: Rob Clark
---
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
index a5d889a8..ff04877 100644
--- a/drivers/gpu/drm/rockch
Signed-off-by: Rob Clark
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 84f8dfe..e71e331 100644
--- a/drivers/gpu/drm/exynos/exynos_
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index cc0ae04..5c1aca4 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu
Fix fb_width/height to properly take account tiles (for ex, DP MST).
Also fixes for fb_width/height vs surface_width/height confusion that
I noticed in a handful of drivers.
Rob Clark (5):
drm/cma: use correct fb width/height
drm/exynos: use correct fb width/height
drm/rockchip: use correct
On Fri, Mar 06, 2015 at 08:58:40AM -0500, Alex Deucher wrote:
> On Fri, Mar 6, 2015 at 7:36 AM, Chris Wilson
> wrote:
> > Since the beginning, sysfs/connector/status has done a heavyweight
> > detection of the current connector status. But no user, such as upowerd
> > or logind, has ever desired
On Fri, Mar 06, 2015 at 02:10:44PM +, Emil Velikov wrote:
> On 05/03/15 16:20, Damien Lespiau wrote:
> > A couple of things I wanted to do for the longest time:
> >
> > - Have (intel's) libdrm use the kernel i915_pciids.h so we can just copy
> > the
> > file when updating
> > - Star
On 05/03/15 16:20, Damien Lespiau wrote:
> A couple of things I wanted to do for the longest time:
>
> - Have (intel's) libdrm use the kernel i915_pciids.h so we can just copy the
> file when updating
> - Start a new object, struct drm_intel_device where we could put common code
> ac
On Fri, Mar 06, 2015 at 10:13:42PM +0900, Inki Dae wrote:
> On 2015ë
02ì 18ì¼ 02:14, Charles Keepax wrote:
> > The commit "drm/exynos: remove exynos_plane_dpms" (d9ea6256) removed the
> > use of the enabled flag, which means that the code may attempt to call
> > win_enable on a NULL crtc. This
Hi
On Fri, Mar 6, 2015 at 1:36 PM, Chris Wilson
wrote:
> Since the beginning, sysfs/connector/status has done a heavyweight
> detection of the current connector status. But no user, such as upowerd
> or logind, has ever desired to initiate a probe. Move the probing into a
> new attribute so that
On Fri, Mar 6, 2015 at 1:12 PM, Rob Clark wrote:
> On Thu, Mar 5, 2015 at 3:20 PM, Hai Li wrote:
>> The framebuffer var width and height should reflect the size of
>> framebuffer memory allocated, which is the entire surface size.
>>
>> In case of dual DSI connectors with TILE properties, this ch
On Thu, Mar 5, 2015 at 3:20 PM, Hai Li wrote:
> The framebuffer var width and height should reflect the size of
> framebuffer memory allocated, which is the entire surface size.
>
> In case of dual DSI connectors with TILE properties, this change
> makes the whole image show on the dual DSI panel,
On Tue, Feb 24, 2015 at 03:23:27PM -0500, Alex Deucher wrote:
> On Tue, Feb 24, 2015 at 3:12 PM, Alex Williamson
> wrote:
> > I'd kinda like to use pci_ignore_hotplug() for devices in use by a
> > user via vfio-pci, but the interface seems only partially implemented
> > since we can only set ignor
Since the beginning, sysfs/connector/status has done a heavyweight
detection of the current connector status. But no user, such as upowerd
or logind, has ever desired to initiate a probe. Move the probing into a
new attribute so that existing readers get the behaviour they desire.
v2: David Herrma
On 03/06/15 11:58, Russell King - ARM Linux wrote:
> On Fri, Mar 06, 2015 at 10:33:27AM +0200, Jyri Sarha wrote:
>> Would it be Ok to add a check that master->ops->add_components is defined,
>> before calling it in find_componets() (drivers/base/component.c:120) and
>> return 0 if it is not?
>
> No
On Thu, Mar 05, 2015 at 12:35:55PM +0800, Zhigang Gong wrote:
> There is one minor conflict when apply the KMD patch to latest
> drm-intel-nightly branch. It should be easy to fix.
>
> Another issue is that IMO, we should bump libdrm's version number
> when increase these new APIs. Then in Beignet
On Thu, Mar 05, 2015 at 12:35:55PM +0800, Zhigang Gong wrote:
> There is one minor conflict when apply the KMD patch to latest
> drm-intel-nightly branch. It should be easy to fix.
>
> Another issue is that IMO, we should bump libdrm's version number
> when increase these new APIs. Then in Beignet
On Fri, Mar 06, 2015 at 12:21:42PM +0200, Jyri Sarha wrote:
> On 03/06/15 11:58, Russell King - ARM Linux wrote:
> >On Fri, Mar 06, 2015 at 10:33:27AM +0200, Jyri Sarha wrote:
> >>Would it be Ok to add a check that master->ops->add_components is defined,
> >>before calling it in find_componets() (d
On 03/02/15 18:01, Russell King - ARM Linux wrote:
> On Thu, Feb 26, 2015 at 04:55:32PM +0200, Jyri Sarha wrote:
>> +ret = component_bind_all(dev->dev, dev);
>> +if (ret < 0) {
>> +dev_err(dev->dev, "Binding subcomponents failed: %d\n", ret);
>
> Do you need to print this? The
> -Original Message-
> From: Stefan Agner [mailto:stefan at agner.ch]
> Sent: Wednesday, March 04, 2015 11:04 PM
> To: Wang Jianwei-B52261
> Cc: dri-devel at lists.freedesktop.org; jbarnes at virtuousgeek.org; Wood
> Scott-B07421; Xiubo Li; Wang Huan-B18965; linux-kernel at vger.kernel.or
On Fri, Mar 06, 2015 at 10:33:27AM +0200, Jyri Sarha wrote:
> Would it be Ok to add a check that master->ops->add_components is defined,
> before calling it in find_componets() (drivers/base/component.c:120) and
> return 0 if it is not?
No:
http://ftp.arm.linux.org.uk/cgit/linux-arm.git/commit/?h
On Tue, Mar 3, 2015 at 3:56 AM, Maarten Lankhorst
wrote:
> A normal wait adds to the front of the tail. By doing something
> similar to fence_default_wait the fence code can run without racing.
>
> This is a complete fix for "panic on suspend from KDE with radeon",
> and a partial fix for "Radeon:
On Thu, Mar 5, 2015 at 5:14 AM, Oded Gabbay wrote:
> Signed-off-by: Oded Gabbay
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_process.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> b/drivers/gpu/drm/amd/amdkfd/kf
On Thu, Mar 5, 2015 at 5:14 AM, Oded Gabbay wrote:
> Signed-off-by: Oded Gabbay
> Reviewed-by: Ben Goz
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> b/drivers/gpu/drm/
On Thu, Mar 5, 2015 at 5:14 AM, Oded Gabbay wrote:
> fence_wait_timeout() is an exported kernel symbol, so we should rename our
> local function to something different.
>
> Signed-off-by: Oded Gabbay
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 4 +
On Fri, Mar 6, 2015 at 7:36 AM, Chris Wilson
wrote:
> Since the beginning, sysfs/connector/status has done a heavyweight
> detection of the current connector status. But no user, such as upowerd
> or logind, has ever desired to initiate a probe. Move the probing into a
> new attribute so that exi
* Jyri Sarha [150306 07:57]:
> On 03/06/15 17:36, Tony Lindgren wrote:
> >* Jyri Sarha [150306 07:37]:
> >>Use new binding for the external tda19988 HDMI encoder.
> >
> >Can this be merged separately after the driver code is
> >merged with things still working?
> >
>
> Yes absolutely. That is wh
On Thu, Mar 05, 2015 at 05:52:50PM -0800, Haixia Shi wrote:
> On Thu, Mar 5, 2015 at 2:33 AM, Chris Wilson
> wrote:
> > On Wed, Mar 04, 2015 at 06:26:23PM -0800, Haixia Shi wrote:
> >> This also limits the maximum frequency of page flips by the vrefresh rate.
> >>
> >> Signed-off-by: Haixia Shi
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150306/f36b7ea8/attachment.html>
* Jyri Sarha [150306 07:37]:
> Use new binding for the external tda19988 HDMI encoder.
Can this be merged separately after the driver code is
merged with things still working?
Otherwise we can have glitches with the output working and
have dependencies between kernel branches.
Regards,
Tony
>
effect is a compilation warning for nouveau driver - patch attached.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150306/4f9d9902/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=94331
--- Comment #1 from Michel Dänzer ---
(In reply to sulamiification from comment #0)
> Because of the panic messsage I am assuming it is at least related to radeon.
Why is that? If you mean because of 'drm_kms_helper', that message appears
regard
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150306/e86ce552/attachment.html>
60 matches
Mail list logo
