Only the 'offsets' array was initialized to zero.
Since bo_create only sets the handles which are
necessary, were we passing garbage data to the
kernel when calling drmModeAddFB2 later.
The issue only seems to appear when passing e.g.
NV12 data to the kernel, a case where not only
handles[0] is us
Only the 'offsets' array was initialized to zero.
Since bo_create only sets the handles which are
necessary, were we passing garbage data to the
kernel when calling drmModeAddFB2 later.
The issue only seems to appear when passing e.g.
NV12 data to the kernel, a case where not only
handles[0] is us
Signed-off-by: Daniel Stone
---
include/drm/drm.h | 2 ++
include/drm/drm_mode.h | 24 +++-
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 44ef685..66028a6 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
Pull new drm.h and drm_mode.h definitions for client caps and atomic
ioctl.
Signed-off-by: Daniel Stone
---
include/drm/drm.h | 23 ++-
include/drm/drm_mode.h | 43 ---
2 files changed, 62 insertions(+), 4 deletions(-)
diff --git
This is the userspace counterpart to:
http://lists.freedesktop.org/archives/dri-devel/2015-April/081488.html
Cheers,
Daniel
Add an ioctl which allows users to create blob properties from supplied
data. Currently this only supports modes, creating a drm_display_mode from
the userspace drm_mode_modeinfo.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/drm_crtc.c | 160 +++-
driv
Reference-count drm_property_blob objects, changing the API to
ref/unref.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/drm_crtc.c | 164 +
include/drm/drm_crtc.h | 17 ++---
2 files changed, 159 insertions(+), 22 deletions(-)
diff --git a/driv
Create a new global blob_lock mutex, which protects the blob property
list from insertion and/or deletion.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/drm_crtc.c | 18 +++---
include/drm/drm_crtc.h | 3 +++
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/driv
Introduce a common helper for the pattern of:
- allocate new blob property
- potentially free old blob property
- replace content of indicative property with new blob ID
- change member pointer on modeset object
Signed-off-by: Daniel Stone
Cc: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c
Previously, when updating the path blob property, we would leak the
existing one. Make this symmetrical with the tile and EDID blob
pointers.
Signed-off-by: Daniel Stone
Cc: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_crt
Just change an if (success) branch to if (fail) return;
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/drm_atomic_helper.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index d536817..
One failure path in crtc_helper had an open-coded CRTC state destroy
which didn't actually call through to the driver's specified state
destroy. Fix that.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/drm_crtc_helper.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/d
Hi,
This is the spritual successor to the modes-as-blob-properties patchset.
There are some fairly drastic differences though, namely:
- the referenced object in this case is the blob property - being just
a dumb chunk of data - rather than attempting to refcount modes;
meaning that ...
On Mon, Apr 20, 2015 at 6:33 PM, Alex Deucher wrote:
> I'm pleased to announce the initial release of the new amdgpu driver.
> This is a partial replacement for the radeon driver for newer AMD
> asics. A number of components are still shared. Here is a comparison
> of the radeon and amdgpu stack
I'm pleased to announce the initial release of the new amdgpu driver.
This is a partial replacement for the radeon driver for newer AMD
asics. A number of components are still shared. Here is a comparison
of the radeon and amdgpu stacks:
1. radeon stack
kernel driver: radeon.ko
libdrm: libdrm_ra
On 04/20/2015 03:28 PM, Chris Wilson wrote:
> The intention of using video=: is primarily to select
> the user's preferred resolution at startup. Currently we always create a
> new mode irrespective of whether the monitor has a native mode at the
> desired resolution. This has the issue that we may
The hardware is limited to 2^9 - 1 (511) bytes transfers, and current
driver has no protections in case users attempt to do larger transfers.
The code will just stomp over status register and mayhem ensues.
Let's split larger transfers into digestable chunks. Doing this allows
Atmel MXT driver on
Hi Hans,
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
owner at vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Friday, April 17, 2015 2:17 PM
>
> On 04/13/2015 03:19 PM, Kamil Debski wrote:
> > Hi Hans,
> >
> > Thank you so much for the review.
> >
> > From: linux-media-owner at
--- next part --
A non-text attachment was scrubbed...
Name: original.patch
Type: text/x-patch
Size: 1709 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150420/16a6ff01/attachment.bin>
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/20150420/e1ddb0bc/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=96351
--- Comment #17 from George Cheban ---
"make defconfig" = no drivers when booting with compiled kernel.
Can't change .config in /linux dir, even when using "rm .config" and replacing
it with renamed copy of already existing config for 3.12 kernel
The intention of using video=: is primarily to select
the user's preferred resolution at startup. Currently we always create a
new mode irrespective of whether the monitor has a native mode at the
desired resolution. This has the issue that we may then select the fake
mode rather the native mode du
Hi Dave,
Below is a qxl lockdep spew that I got with Linus' tree a few days
ago. I actually suspect this is present in older kernels too as the
DRM merge hasn't landed yet. If you have any ideas, I'd appreciate
it. I tried to look at the locking a bit, but I'm not familiar with
the ww ticket lo
(SyS_exit_group) from []
(ret_fast_syscall+0x0/0x4c)
[ 226.600250] ---[ end trace 0f3a4a8e4c514be4 ]---
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150420/a527e3e8/attachment-0001.sig>
On Mon, Apr 20, 2015 at 03:06:30PM +0200, Radek Dostál wrote:
> Hi Chris,
>
> On 04/20/2015 02:26 PM, Chris Wilson wrote:
> > The intention of using video=: > the user's preferred resolution at startup. Currently we always create a
> > GTF mode irrespective of whether the monitor has a native mod
Hi Chris,
On 04/20/2015 01:44 PM, Chris Wilson wrote:
> Ah, maybe this on top of the previous try:
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 88f5a74..5d22ca0 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_pro
https://bugzilla.kernel.org/show_bug.cgi?id=96351
--- Comment #16 from Alex Deucher ---
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ git clone http://github.com/ignatenkobrain/kernel-package.git
$ cd linux
$ git bisect start
$ git bisect bad v3.19
$ git bisect go
On 2015å¹´04æ20æ¥ 13:34, Mark yao wrote:
> On 2015å¹´04æ19æ¥ 00:55, Heiko Stübner wrote:
>> Am Donnerstag, 16. April 2015, 16:41:51 schrieb Ãrjan Eide:
>>> Set vm_pgoff to 0 after using it to look up the GEM node, before
>>> passing
>>> it on rockchip_gem_mmap_buf() where the offset must b
On 2015å¹´04æ19æ¥ 00:55, Heiko Stübner wrote:
> Am Donnerstag, 16. April 2015, 16:41:51 schrieb Ãrjan Eide:
>> Set vm_pgoff to 0 after using it to look up the GEM node, before passing
>> it on rockchip_gem_mmap_buf() where the offset must be from the start of
>> the buffer.
>>
>> Passing in th
The intention of using video=:inital_config() and so
on a non-GTF monitor we then end up with a loss of signal. Oops. This
invalid fake mode would also be exported to userspace, who potentially
may make the same mistake.
To avoid this issue, we filter out the added command line mode if we
detect t
Hi Chris,
On 04/20/2015 01:00 PM, Chris Wilson wrote:
> Can you do a WARN_ON(list_empty(&connector->modes)) here to see at what
> point we set up the invalid GTF mode?
sure please see attached patch adding WARN_ON and corresponding output
of dmesg. As mentioned in the original commit, the mode is
Hi Chris,
On 04/20/2015 12:48 PM, Chris Wilson wrote:
>> Unfortunately you can not do that. I already tried. At the time when
>> > drm_helper_probe_add_cmdline_mode is called EDID informations are not
>> > yet available.
> My understanding is that it should be. fb_helper.initial_config does a
> pr
On Mon, Apr 20, 2015 at 01:20:05PM +0200, Radek Dostál wrote:
> Hi Chris,
>
> On 04/20/2015 01:00 PM, Chris Wilson wrote:
> > Can you do a WARN_ON(list_empty(&connector->modes)) here to see at what
> > point we set up the invalid GTF mode?
>
> sure please see attached patch adding WARN_ON and co
Hi Chris,
On 04/20/2015 11:58 AM, Chris Wilson wrote:
> Hmm, so that should be before the clock comparison as well to fix your
> example. Not as neat.
indeed that is required.
> The other idea I was considering was not adding the GTF cmdline mode if
> the probed modes already contain one of a ma
sktop.org/archives/dri-devel/attachments/20150420/dea040b5/attachment.html>
ts.freedesktop.org/archives/dri-devel/attachments/20150420/2a4f2b66/attachment.html>
Hi Ãrjan,
On Thu, Apr 16, 2015 at 10:41 PM, Ãrjan Eide wrote:
>
> Set vm_pgoff to 0 after using it to look up the GEM node, before passing
> it on rockchip_gem_mmap_buf() where the offset must be from the start of
> the buffer.
>
> Passing in the fake offset currently works because the
> dma_mm
Hi Ãrjan,
On Thu, Apr 16, 2015 at 10:41 PM, Ãrjan Eide wrote:
> arm_iommu_mmap_attrs() ignores the page offset in vma->vm_pgoff that was
> specified in the mmap call. Any user of dma_mmap_* will get an
> unexpected result when the device uses the IOMMU DMA ops.
>
> Some DRM driver that use dma_
If the handler registers late, already registered clients must
reprobe their connectors in case they require the handler to
switch DDC lines. That is the case on MacBook Pros, which use
a gmux chip as handler.
Inspired by Matthew Garrett, who did this in vga_switcheroo_enable()
instead, which dela
On Mon, Apr 20, 2015 at 12:57:33PM +0200, Radek Dostál wrote:
> Hi Chris,
>
> On 04/20/2015 12:48 PM, Chris Wilson wrote:
> >> Unfortunately you can not do that. I already tried. At the time when
> >> > drm_helper_probe_add_cmdline_mode is called EDID informations are not
> >> > yet available.
>
On Mon, Apr 20, 2015 at 12:38:25PM +0200, Radek Dostál wrote:
> Hi Chris,
>
> On 04/20/2015 11:58 AM, Chris Wilson wrote:
> > Hmm, so that should be before the clock comparison as well to fix your
> > example. Not as neat.
>
> indeed that is required.
>
> > The other idea I was considering was
Hi Chris,
On 04/20/2015 11:09 AM, Chris Wilson wrote:
> The EDID modes should be earlier in the list, and so higher priority
> than the cmdline mode. The only instance I see that breaking down is if
> the mode gets created by drm_pick_cmdline_mode, i.e.
indeed at the beginning the command line mo
On Mon, Apr 20, 2015 at 10:46:08AM +0100, Chris Wilson wrote:
> On Mon, Apr 20, 2015 at 11:36:04AM +0200, Radek Dostál wrote:
> > Hi Chris,
> >
> > On 04/20/2015 11:09 AM, Chris Wilson wrote:
> > > The EDID modes should be earlier in the list, and so higher priority
> > > than the cmdline mode. T
On Mon, Apr 20, 2015 at 11:36:04AM +0200, Radek Dostál wrote:
> Hi Chris,
>
> On 04/20/2015 11:09 AM, Chris Wilson wrote:
> > The EDID modes should be earlier in the list, and so higher priority
> > than the cmdline mode. The only instance I see that breaking down is if
> > the mode gets created
On Mon, Apr 20, 2015 at 07:26:33AM +0200, Radek Dostal wrote:
> commit eaf99c749d43 ("drm: Perform cmdline mode parsing during connector
> initialisation") breaks HDMI output on BeagleBone Black with LG TV
> (model 19LS4R-ZA) when "video=HDMI-A-1:1280x720 at 60" is specified on
> the command line.
On Fri, Apr 17, 2015 at 01:26:21PM +0200, Josef Holzmayr wrote:
> Am 17.04.2015 um 13:23 schrieb Chris Wilson:
> >On Thu, Apr 16, 2015 at 02:16:29PM +0200, Josef Holzmayr wrote:
> >>DRM probe should not repoll a connector if it is already
> >>connected and the DRM_CONNECTOR_POLL_DISCONNECT flag is
On 2015å¹´04æ20æ¥ 07:00, Heiko Stübner wrote:
> platform_get_irq() can return negative error values and we already test for
> these. Therefore the variable holding this value should be signed to not
> loose possible error values.
>
> Reported-by: David Binderman
> Signed-off-by: Heiko Stuebner
Hi Dave
I'm interesting to maintain the rockchip drm, so add entry for
Rockchip drm.
and some fixes.
Can you land them?
The following changes since commit aa219a0dd7774e2454a5687e7d38e947a131cdee:
Merge tag 'drm-intel-next-fixes-2015-04-15' of
git://anongit.freedesktop.org/dr
On Sat, Apr 18, 2015 at 12:04:18AM -0700, Todd Previte wrote:
> For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
> device must attempt at least 7 times to read the EDID when it receives an
> I2C defer. The normal DRM code makes only 7 retries, regardless of whether
> or no
commit eaf99c749d43 ("drm: Perform cmdline mode parsing during connector
initialisation") breaks HDMI output on BeagleBone Black with LG TV
(model 19LS4R-ZA) when "video=HDMI-A-1:1280x720 at 60" is specified on
the command line.
The reason is newly added mode
'"1280x720" 60 74440 1280 1336 1472 16
Hi Linus,
First up, this tree contains a backmerge of your tree, as it merges cleanly
but then fails to build on ARM due to an API change, I've included the
fixed up patch in the merge commit.
The unmerged, unfixed tree is in my drm-next branch if you want to confirm
things. The fixup is 3 trivi
Hi Heiko,
On Sun, Apr 19, 2015 at 12:30 AM, Heiko Stübner wrote:
> platform_get_irq() can return negative error values and we already test for
> these. Therefore the variable holding this value should be signed to not
> loose error values.
>
> Reported-by: David Binderman
> Signed-off-by: Heiko
n irq;
vop->irq = (unsigned int)irq;
-Dan
>
> /* vop AHP clk */
> struct clk *hclk;
> --
> 2.1.4
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150420/bbd497d9/attachment.html>
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/20150420/372fa7d6/attachment.html>
platform_get_irq() can return negative error values and we already test for
these. Therefore the variable holding this value should be signed to not
loose possible error values.
Reported-by: David Binderman
Signed-off-by: Heiko Stuebner
Reviewed-By: Daniel Kurtz
---
changed since v1:
- instead
Mark Yao looks after the Rockchip drm drivers and should thus also get
patches touching these.
Signed-off-by: Heiko Stuebner
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7687fc6..7e4d386 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -
56 matches
Mail list logo
