Hello,
I have the pleasure to announce that the X.org Developer Conference 2014
will
be held in Bordeaux, France from October 8th to October 10th. The venue is
located in the campus of the University of Bordeaux 1, in the computer
science
research lab called LaBRI.
The official page for the eve
|high
--
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/20140502/26ef4675/attachment.html>
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140502/685f583c/attachment-0001.html>
bbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140502/e8ca409c/attachment.html>
On 22.04.2014 21:51, Alex Deucher wrote:
> On Tue, Apr 22, 2014 at 3:53 AM, Michel D?nzer wrote:
>> From: Michel D?nzer
>>
>> The way the tile mode array index was calculated only makes sense for
>> the CIK specific macrotile mode array. For SI, we need to use one of the
>> tile mode array indice
From: Dave Airlie
This mode group id_list was never being freed.
v2: take David's suggestion to free in minor_free.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 6 ++
drivers/gpu/drm/drm_stub.c | 1 +
include/drm/drm_crtc.h | 1 +
3 files changed, 8 insertions(+)
diff
replaced by
cgts_tcc_disable |= RREG32(CGTS_TCC_DISABLE);
--
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/20140502/936b70fc/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=74911
--- Comment #5 from Michel D?nzer ---
(In reply to Ivan Bulatovic from comment #3)
> Apologies, it opts out after a minute just like you've said it would.
Yep, that timeout is one of the biggest downsides of building the driver into
the kernel in
https://bugzilla.kernel.org/show_bug.cgi?id=74911
--- Comment #6 from Michel D?nzer ---
(In reply to Ivan Bulatovic from comment #2)
> Don't mean to be rude or anything, but I don't know if it is recommended (or
> desirable) to commit a piece of code to mainline that will _require_ a blob
> that
|--- |NOTOURBUG
--
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/20140502/df44c9c6/attachment.html>
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/20140502/f9f65c4e/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140502/84c20447/attachment.html>
.
Preferably using git send-email, but at least using git format-patch.
--
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/20140502/7f0f4
Hi,
Branch: http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-i915-mst-support
Okay I've gotten this to light up some monitors using -modesetting so it
must be ready for an initial posting,
Tested on Haswell so far with Lenovo Ultradock and with Ancell MST Hub devices,
(checked it can detect
From: Dave Airlie
This just adds the defines from the DP 1.2 spec, which we
will use later.
Signed-off-by: Dave Airlie
---
include/drm/drm_dp_helper.h | 78 +
1 file changed, 78 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/dr
From: Dave Airlie
This adds an encoder type for DP MST encoders.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 1 +
include/uapi/drm/drm_mode.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a3fe324..f1753e6 10
From: Dave Airlie
These are just from the Haswell spec.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8f84555..557b37a 100644
From: Dave Airlie
This can be called to update things after dynamic connectors/encoders
are created/deleted.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 9 +
include/drm/drm_crtc.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/d
From: Dave Airlie
This is the initial import of the helper for displayport multistream.
It consists of a topology manager, init/destroy/set mst state
It supports DP 1.2 MST sideband msg protocol handler - via hpd irqs
connector detect and edid retrieval interface.
It supports i2c device over
From: Dave Airlie
this is just prep work for mst support.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_ddi.c | 20 +---
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drive
From: Dave Airlie
DP MST will need connectors that aren't connected to specific
encoders, add some checks in advance to avoid oopses.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 +---
drivers/gpu/drm/i915/i915_irq.c | 4
drivers/gpu/drm/i915/
From: Dave Airlie
This adds DP 1.2 MST support on Haswell systems.
Notes:
a) this reworks irq handling for DP MST ports, so that we can
avoid the mode config locking in the current hpd handlers, as
we need to process up/down msgs at a better time.
b) it introduces a new MST output type.
c) it
TODO: fix fbcon
I forgot to mention no fbcon yet :-)
Dave.
On 2 May 2014 14:39, Dave Airlie wrote:
> Hi,
>
> Branch: http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-i915-mst-support
>
> Okay I've gotten this to light up some monitors using -modesetting so it
> must be ready for an initial
From: Dave Airlie
This fixes the main warning tracebacks I've been seeing here.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_ddi.c | 5 +
drivers/gpu/drm/i915/intel_dp_mst.c | 2 ++
drivers/gpu/drm/i915/intel_opregion.c | 1 +
3 files changed, 8 insertions(+)
diff --gi
On 01.05.2014 07:49, Alexandre Courbot wrote:
> Agreed. Besides I hope the day won't come where we have to go through
> 2 layers of memory translation for the GPU...
That's actually the method of operation that gives us the best
performance. GPU likes big pages, and without IOMMU translation you'd
On 29.04.2014 23:29, Christian K?nig wrote:
> From: Christian K?nig
>
> Instead of trying to flip inside the vblank period when
> the buffer is idle, offload blocking for idle to a kernel
> thread and program the flip directly into the hardware.
>
> Signed-off-by: Christian K?nig
[...]
> +/**
>
On Fri, May 02, 2014 at 02:39:37PM +1000, Dave Airlie wrote:
> Hi,
>
> Branch: http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-i915-mst-support
>
> Okay I've gotten this to light up some monitors using -modesetting so it
> must be ready for an initial posting,
I see that connectors are add
Latest patches for GK20A, taking comments received for v3 into account.
Changes since v3:
- use only pfn_to_page() and page_to_pfn() in GK20A's FB. These functions
are present on every arch and the physical address to page frame number
conversion is also consistently a shift of PAGE_SHIFT. Thi
Some chips that use system memory exclusively (e.g. GK20A) do not
expose 2 BAR regions. For them only BAR1 exists, and it should be used
for USERD mapping. Do not map BAR3 if its resource does not exist.
Signed-off-by: Alexandre Courbot
Reviewed-by: Thierry Reding
---
drivers/gpu/drm/nouveau/co
Adapt the NVC0 BAR driver to make it able to support chips that do not
expose a BAR3. When this happens, BAR1 is then used for USERD mapping
and the BAR alloc() functions is disabled, making GPU objects unable
to rely on BAR for data access and falling back to PRAMIN.
Signed-off-by: Alexandre Cour
Add support for initializing the priv ring of GK20A. This is done by the
BIOS on desktop GPUs, but needs to be done by hand on Tegra.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/Makefile | 1 +
drivers/gpu/drm/nouveau/core/include/subdev/ibus.h | 1 +
drive
Add a simple FB device for GK20A, as well as a RAM implementation based
on contiguous DMA memory allocations suitable for chips that use system
memory as video RAM.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/Makefile | 2 +
drivers/gpu/drm/nouveau/core/includ
GK20A's FIFO is compatible with NVE0, but only features 128 channels and
1 runlist.
Signed-off-by: Alexandre Courbot
Reviewed-by: Thierry Reding
---
drivers/gpu/drm/nouveau/Makefile | 1 +
drivers/gpu/drm/nouveau/core/engine/fifo/gk20a.c | 35 ++
drivers
nvc0_graph_ctor() would only let the graphics engine be enabled if its
oclass has a proper microcode linked to it. This prevents GR from being
enabled at all on chips that rely exclusively on external firmware, even
though such a use-case is valid.
Relax the conditions enabling the GR engine to al
Pad the microcode to a multiple of 0x40 words, otherwise firmware will
fail to run from non-prepadded firmware files.
Signed-off-by: Alexandre Courbot
Reviewed-by: Thierry Reding
---
drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers
Add a GR device for GK20A based on NVE4, with the correct classes
definitions (GK20A's 3D class is 0xa297).
Most of the NVE4 code can be used on GK20A, so make relevant bits of
NVE4 available to other chips as well.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/Makefile
Set the correct subdev/engine classes when GK20A (0xea) is probed.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/core/engine/device/nve0.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
b/drivers/gpu/drm/no
ttm_tt_cache_flush's implementation was removed in 2009 by commit
c9c97b8c, but its declaration has been hiding in ttm_bo_driver.h since
then.
It has been surviving in the dark for too long now ; give it the coup
de gr?ce.
Signed-off-by: Alexandre Courbot
---
include/drm/ttm/ttm_bo_driver.h | 1
Am 02.05.2014 04:20, schrieb Michel D?nzer:
> On 22.04.2014 21:51, Alex Deucher wrote:
>> On Tue, Apr 22, 2014 at 3:53 AM, Michel D?nzer wrote:
>>> From: Michel D?nzer
>>>
>>> The way the tile mode array index was calculated only makes sense for
>>> the CIK specific macrotile mode array. For SI,
not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140502/53d6236d/attachment-0001.sig>
ilable
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140502/991e7db2/attachment.sig>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140502/78dca875/attachment.html>
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140502/fbe0693c/attachment.html>
Am 01.05.2014 19:29, schrieb Jay Cornwall:
> On 2014-05-01 11:52, Christian K?nig wrote:
>
> Some minor comment fixes inline. I've been using v3 of this patch on
> SI for quite a while, with no visible failures.
Thanks for the notes. I've added them to my v5 of the patch and also
updated the fil
https://bugzilla.kernel.org/show_bug.cgi?id=75211
--- Comment #8 from Christian K?nig ---
Created attachment 134701
--> https://bugzilla.kernel.org/attachment.cgi?id=134701&action=edit
Possible fix.
Please try to reproduce the issue with the attached patch applied.
It would still not work cor
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #4 from Christian K?nig ---
(In reply to Clemens Ladisch from comment #3)
> 3.14:
> 16205, pll dividers - fb: 135.8 ref: 2, post 6
>
> With the patch:
> 162000 - 161990, pll dividers - fb: 271.5 ref: 4, post 6
>
> And the patch indee
> I'm a little worried about this case. AFAICT this would drop the flip if
> a previous one is still pending? I'm not sure current userspace can
> actually hit this
Yeah, that concerned me as well. The old code dropped the the new flip
as well, so I'm pretty sure that the new handling is right and
b;
> > +
> > +struct drm_tegra_pushbuf {
> > + uint32_t *ptr;
> > +};
>
> Hmm, single-member structs always makes me cringe a bit. But in this
> case it's much better than a double-pointer IMO.
>
> But perhaps some of the members in the private-struct might be useful
> out here? For instance, if "uint32_t *end;" was also available, we
> could do:
>
> inline void drm_tegra_pushbuf_push_word(struct drm_tegra_pushbuf
> *pushbuf, uint32_t value)
> {
>assert(pushbuf->ptr < pushbuf->end);
>*pushbuf->ptr++ = value;
> }
>
> ...and easily pick up bugs with too few words? The helper would of
> course be in the header-file, so the write gets inlined nicely.
Sounds good. If you have no strong objections, I'd like to keep that for
a follow on patch when there's more code that actively uses this API. It
should be fairly safe to make more members public via drm_tegra_pushbuf
rather than the other way around, so I'd like to err on the side of
carefulness for a bit longer.
Thanks for the review, and apologies for being sluggish.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140502/d26b7c0c/attachment.sig>
ld fit. Others are
either installed (and therefore shouldn't be exposing these macros) or
have a very specific purpose (xf86atomic.h).
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140502/4a0ac752/attachment.sig>
y `/home/kusma/src/libdrm/tests/tegra'
> make: *** [check-am] Error 2
> make: Leaving directory `/home/kusma/src/libdrm/tests/tegra'
I've modified the tests to default to /dev/dri/card0 if no device was
specified on the command-line.
Thierry
-- next part ---
width / 2, fb->height / 2,
> > 0x);
> > + if (err < 0) {
> > + fprintf(stderr, "failed to fill rectangle: %s\n",
> > + strerror(-err));
> > + return 1;
> > + }
> > +
> &g
NODEV;
> > +
> > + crtc = drmModeGetCrtc(screen->fd, encoder->crtc_id);
> > + if (!crtc) {
> > + drmModeFreeEncoder(encoder);
> > + return -ENODEV;
> > + }
> > +
> > + screen->old_fb = crtc->buffer_id;
> > +
> > + fb = drmModeGetFB(screen->fd, crtc->buffer_id);
> > + if (!fb) {
> > + /* TODO: create new framebuffer */
>
> What's the implications of not doing what this TODO says?
It currently just means that we don't want to deal with this situation,
which I think shouldn't be happening in the first place anyway. So the
TODO is there mostly as a reminder that this could happen and that there
*might* be something more useful than returning an error that could be
done.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140502/13d24a80/attachment.sig>
//lists.freedesktop.org/archives/dri-devel/attachments/20140502/761ecc89/attachment.html>
And I
have no setup where I could reproduce it. I eventually managed to
trigger a similar error by explicitly passing both -Wl,--as-needed and
-Wl,--no-copy-dt-needed-entries in LDFLAGS at configure time. I now have
a version that builds with or without these flags, so I hope that
everyone will now be happy.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140502/eb599cf6/attachment-0001.sig>
On Fri, May 2, 2014 at 4:06 PM, Thierry Reding
wrote:
> On Thu, Apr 10, 2014 at 07:13:22PM +0200, Erik Faye-Lund wrote:
>>
>> But this raises the question, how is job->cmdbufs (and job->relocs)
>> supposed to get free'd?
>>
>> I'm a bit curious as to what the expected life-time of these objects
>
On Fri, May 2, 2014 at 4:12 PM, Thierry Reding
wrote:
> On Thu, Apr 10, 2014 at 07:15:14PM +0200, Erik Faye-Lund wrote:
>> On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
>> wrote:
>> > diff --git a/libdrm.h b/libdrm.h
>> > new file mode 100644
>> > index ..23926e6f6741
>> > --- /dev
On Fri, May 2, 2014 at 4:25 PM, Thierry Reding
wrote:
> On Thu, Apr 10, 2014 at 07:28:16PM +0200, Erik Faye-Lund wrote:
>> On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
>> wrote:
>> > diff --git a/tests/tegra/gr2d-fill.c b/tests/tegra/gr2d-fill.c
>> > new file mode 100644
>> > index 00
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140502/213b7103/attachment.html>
On Fri, May 2, 2014 at 4:42 PM, Thierry Reding
wrote:
> On Thu, Apr 10, 2014 at 07:33:33PM +0200, Erik Faye-Lund wrote:
>> On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
>> wrote:
>> > From: Thierry Reding
>> >
>> > This library provides helpers for common functionality needed by test
>> > pro
e that actively uses this API. It
> > should be fairly safe to make more members public via drm_tegra_pushbuf
> > rather than the other way around, so I'd like to err on the side of
> > carefulness for a bit longer.
>
> Hmm, isn't it the *current* code that is "careless" in this case? The
> client doesn't have enough context to validate this itself (without
> having access to the end-pointer)?
What I meant was being careful about how much we expose. Whatever we
expose now we can potentially never hide again because code may depend
on it being public. I don't think it's particularly careless to require
the caller to prepare a buffer. If they then write past its end, that's
their issue. That's like malloc()ing a buffer and then filling it with
more bytes than you've allocated. That's not the level of safety that
this API needs in my opinion.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140502/d2f7fda4/attachment.sig>
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> +int drm_open(const char *path)
> +{
> + int fd, err;
> +
> + fd = open(path, O_RDWR);
> + if (fd < 0)
> + return -errno;
> +
> + err = drmSetMaster(fd);
> + if (err < 0) {
> + close(
On Mon, Apr 28, 2014 at 4:25 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Testing the update pending bit directly after issuing an
> update is nonsense cause depending on the pixel clock the
> CRTC needs a bit of time to execute the flip even when we
> are in the VBLANK period.
>
> This
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140502/f04ac369/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=75211
--- Comment #9 from Darren Salt ---
No crash now.
However, the kernel log is spammed with
[drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:14]
I did notice what looked like some X spam too, but that's been lost over an X
re
On Fri, May 2, 2014 at 5:16 PM, Thierry Reding
wrote:
> On Fri, May 02, 2014 at 04:53:55PM +0200, Erik Faye-Lund wrote:
>> On Fri, May 2, 2014 at 4:06 PM, Thierry Reding
>> wrote:
>> > On Thu, Apr 10, 2014 at 07:13:22PM +0200, Erik Faye-Lund wrote:
>> >> > diff --git a/tegra/pushbuf.c b/tegra/p
Am 02.05.2014 17:24, schrieb Alex Deucher:
> On Mon, Apr 28, 2014 at 4:25 AM, Christian K?nig
> wrote:
>> From: Christian K?nig
>>
>> Testing the update pending bit directly after issuing an
>> update is nonsense cause depending on the pixel clock the
>> CRTC needs a bit of time to execute the fl
On Fri, May 2, 2014 at 12:23 PM, Christian K?nig
wrote:
> Am 02.05.2014 17:24, schrieb Alex Deucher:
>
>> On Mon, Apr 28, 2014 at 4:25 AM, Christian K?nig
>> wrote:
>>>
>>> From: Christian K?nig
>>>
>>> Testing the update pending bit directly after issuing an
>>> update is nonsense cause dependi
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140502/598c24b9/attachment.patch>
I've bisected a resume regression on a Lenovo x120e to
177cf92de4aa97ec1435987e91696ed8b5023130 (drm/crtc-helpers: fix dpms on
logic). Everything works fine with this patch reverted on top of
3.15-rc3. I realize it is correcting a coding error that has been in
place since 3.11, but it is also causi
On 05/02/2014 11:21 AM, Alex Deucher wrote:
> On Fri, May 2, 2014 at 12:40 PM, Tim Gardner
> wrote:
>> I've bisected a resume regression on a Lenovo x120e to
>> 177cf92de4aa97ec1435987e91696ed8b5023130 (drm/crtc-helpers: fix dpms on
>> logic). Everything works fine with this patch reverted on top
ein the platform appears to be locked up (no console,
>>> no network). See attached bisect log and lspci. The BIOS version is 1.15.
>>>
>>
>> Does the attached patch help? I haven't had a chance to unwind all
>> the logic in the crtc helper code.
>>
>&
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #5 from Clemens Ladisch ---
It's an Eizo S2100, but this should not matter because the clocks seen by the
monitor are always about the same (162MHz/75kHz/60Hz). If some were out of
range, the monitor would show an error message, but w
ake it work.
--
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/20140502/f965e205/attachment.html>
Alex Deucher (1):
bump version to 2.4.54 for release
Daniel Kurtz (1):
Use signed location for drmModeSetPlane
Maarten Lankhorst (2):
nouveau: safen up nouveau_device list usage against concurrent access
amend previous commit to actually compile
Rob Clark (2):
modet
"upscacle" 1080 to 1080, cause that will kill
performance.
--
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/2014
75 matches
Mail list logo
