On 10/15/2014 10:51 PM, Rob Clark wrote:
> On Wed, Oct 15, 2014 at 4:44 PM, Thomas Hellstrom
> wrote:
>> On 10/15/2014 10:38 PM, Rob Clark wrote:
>>> On Wed, Oct 15, 2014 at 4:35 PM, Rob Clark wrote:
On Wed, Oct 15, 2014 at 4:17 PM, Thomas Hellstrom >>> vmware.com> wrote:
> On 10/15/201
On 10/15/2014 10:38 PM, Rob Clark wrote:
> On Wed, Oct 15, 2014 at 4:35 PM, Rob Clark wrote:
>> On Wed, Oct 15, 2014 at 4:17 PM, Thomas Hellstrom
>> wrote:
>>> On 10/15/2014 09:46 PM, Rob Clark wrote:
On Wed, Oct 15, 2014 at 3:24 PM, Thomas Hellstrom >>> vmware.com> wrote:
> On 10/15/20
Hi!
On 09/25/2014 06:52 PM, Rian Quinn wrote:
> I have been doing a lot of work with LibDRM, including Multi-Monitor work on
> Intel and VMWare. Do you guy?s know if there is an easy way to tell VMWare to
> add more virtual display?s for testing? LibDRM reports something like 8
> different conn
On 10/15/2014 09:46 PM, Rob Clark wrote:
> On Wed, Oct 15, 2014 at 3:24 PM, Thomas Hellstrom
> wrote:
>> On 10/15/2014 09:00 PM, Rob Clark wrote:
>>> Signed-off-by: Rob Clark
>>> ---
>>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 7 +++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/dr
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/8a7bdc3f/attachment-0001.html>
On 10/15/2014 09:00 PM, Rob Clark wrote:
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 18b54ac..f0267b8 100644
> --- a/driv
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/bc623602/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=86351
--- Comment #2 from Christian Birchinger ---
Created attachment 153911
--> https://bugzilla.kernel.org/attachment.cgi?id=153911&action=edit
asound /proc info
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=86351
--- Comment #1 from Christian Birchinger ---
Created attachment 153901
--> https://bugzilla.kernel.org/attachment.cgi?id=153901&action=edit
lsmod output
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=86351
Bug ID: 86351
Summary: HDMI audio garbled output on Radeon R9 280X
Product: Drivers
Version: 2.5
Kernel Version: 3.17
Hardware: All
OS: Linux
Tree: Mainline
On Wed, Oct 15, 2014 at 4:44 PM, Thomas Hellstrom
wrote:
> On 10/15/2014 10:38 PM, Rob Clark wrote:
>> On Wed, Oct 15, 2014 at 4:35 PM, Rob Clark wrote:
>>> On Wed, Oct 15, 2014 at 4:17 PM, Thomas Hellstrom >> vmware.com> wrote:
On 10/15/2014 09:46 PM, Rob Clark wrote:
> On Wed, Oct 15,
On 14.10.2014 15:44, ?? ?? wrote:
>
> I'm tinkering around in radeon DRM code as a hobby so if you have a
> couple of minutes, could you explain, how GTT works for Radeon module?
> I've seen mentions of it here and there on the Internet, and tried to
> ping developers on IRC, but the overal
On Wed, Oct 15, 2014 at 4:35 PM, Rob Clark wrote:
> On Wed, Oct 15, 2014 at 4:17 PM, Thomas Hellstrom
> wrote:
>> On 10/15/2014 09:46 PM, Rob Clark wrote:
>>> On Wed, Oct 15, 2014 at 3:24 PM, Thomas Hellstrom >> vmware.com> wrote:
On 10/15/2014 09:00 PM, Rob Clark wrote:
> Signed-off-by
On Wed, Oct 15, 2014 at 4:17 PM, Thomas Hellstrom
wrote:
> On 10/15/2014 09:46 PM, Rob Clark wrote:
>> On Wed, Oct 15, 2014 at 3:24 PM, Thomas Hellstrom
>> wrote:
>>> On 10/15/2014 09:00 PM, Rob Clark wrote:
Signed-off-by: Rob Clark
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 7 +
Hello Alan Cox,
The patch 4d8d096e9ae8: "gma500: introduce the framebuffer support
code" from Nov 3, 2011, leads to the following static checker warning:
drivers/gpu/drm/gma500/framebuffer.c:488 psbfb_create()
warning: passing freed memory 'backing'
drivers/gpu/drm/gma500/framebu
On Wed, Oct 15, 2014 at 3:24 PM, Thomas Hellstrom
wrote:
> On 10/15/2014 09:00 PM, Rob Clark wrote:
>> Signed-off-by: Rob Clark
>> ---
>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> b/drivers/gpu/
On 10/14/2014 12:03 PM, Thierry Reding wrote:
> On Tue, Oct 14, 2014 at 10:59:26AM +0200, Andrzej Hajda wrote:
>> On 10/13/2014 12:16 PM, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> Implement generic read and write commands. Selection of the proper data
>>> type for packets is done auto
n HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/5022c2ba/attachment.html>
Signed-off-by: Rob Clark
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 18b54ac..f0267b8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwg
On 2014? 10? 10? 21:39, Andrzej Hajda wrote:
> On 10/02/2014 12:52 PM, Inki Dae wrote:
>> On 2014? 10? 02? 17:58, Joonyoung Shim wrote:
>>> Hi Andrzej,
>>>
>>> On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
The patch disables vblanks during dpms off only if pagefilp has
not been finished. I
; for wzy, also fails after 1. w).
What is the value of sd is returned when the swizzle .wx is passed to
lookup_native_swizzle?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://li
d fresh
32bit OS installation and nope again does not work == corruption is there.
--
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/20141015/193387c6/attachment.html>
On 10/15/2014 01:11 PM, Thierry Reding wrote:
> On Wed, Oct 15, 2014 at 01:01:16PM +0200, Andrzej Hajda wrote:
>> On 10/14/2014 04:16 PM, Thierry Reding wrote:
>>> On Tue, Oct 14, 2014 at 03:53:26PM +0200, Andrzej Hajda wrote:
On 10/14/2014 01:29 PM, Thierry Reding wrote:
> On Tue, Oct 14,
In short, that new API assumes that transfer callback must interpret
> >>>> write buffer
> >>>> differently than before :) Ie that sometimes at the beginning of the
> >>>> buffer
> >>>> there will be additional bytes.
> >>> Right, we never defined exactly which part of code would take which data
> >>> and into what data it would be transformed. That obviously breaks as
> >>> soon as two implementations make different assumptions. =)
> >> In previous version of this patch [1] you have made different assumption,
> >> and in the discussion you were clearly aware of the current implementation,
> >> so your reaction here surprises me little bit. Maybe some misunderstanding.
> >> Anyway I am glad we are now both aware of the problem.
> >>
> >> [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/110647
> > It's possible I didn't realize the full complexity of the problem at the
> > time. To summarize, I think the helpers in the core should do as much
> > work as they possibly can, so that drivers don't have to duplicate the
> > same over and over again. That is, the DCS helpers that are under
> > discussion here should create a buffer that reflects the packet that is
> > to be sent to the DSI peripheral, including the specific layout of the
> > header. So a struct mipi_dsi_msg contains the following information:
> >
> > - .channel + .type make up the DI (Data ID) field in the packet
> > header
> >
> > for short packets:
> > - .tx_buf[0] and .tx_buf[1] correspond to Data 0 and Data 1
> > fields in the packet header (both of these are only present if
> > .tx_len is larger than 0 and 1, and default to 0 otherwise)
> >
> > for long packets:
> > - .tx_buf[0] and .tx_buf[1] correspond to the word count
> > - .tx_buf[2..] represent the payload (word count - 2 bytes)
> >
> > That's pretty much what section 8.4 General Packet Structure of the DSI
> > specification describes. This intentionally leaves out the header ECC
> > and 16-bit packet footer (checksum). These are typically implemented in
> > hardware, and if they aren't we can provide helpers that compute them
> > based on the header, and the payload in .tx_buf. That way all the packet
> > composition defined in the specification is handled by common code and a
> > driver only needs to have the hardware-specific knowledge, namely where
> > the various pieces need to be written in order to transmit them as
> > desired.
> >
> > Does that make sense?
> According to DSI specification we can describe DSI
> message/command/transaction
> on two levels:
> 1. Application layer - message is described by a triplet (data_type,
> channel_id, data).
> 2. Protocol layer - message is described as a four byte packet header,
> optionally
> followed by packet data (payload) and checksum (which we can skip it
> here as it should be generated by HW).
>
> In the current API the 1st approach is used. There is no defined
> standard how to program
> DSI host to generate specific message, so this approach seems to be the
> most natural in general case.
>
> On the other side all DSI hosts I looked at use approach based on
> protocol layer, ie.
> packet header is written to one FIFO register and payload to another
> (exynos, intel, omap) or the same (tegra).
>
> Your proposition is something close to 2nd approach, maybe it would be
> better to convert to completely to 2nd approach:
>
> struct mipi_dsi_msg {
> u8 header[4]; /* u32 header; ??? */
> void *payload; /* NULL in case of short packets */
> size_t payload_len;
> ...
> };
>
> Anyway, I think conversion to protocol layer should be done by helper
> but this helper should be called rather from dsi host,
> otherwise we can encounter some day dsi host which we need to feed with
> data differently and we will need to perform
> back-conversion from protocol layer to app layer, it will not be
> difficult it will be just ugly :)
>
> What about creating helpers to make dsi packets from current dsi
> message. Sth like:
>
> ... drm_mipi_create_packet(struct mipi_dsi_packet *pkt, struct
> mipi_dsi_msg *msg)
> {
> if (long packet) {
> pkt->header = ...;
> pkt->payload = msg->tx_buf;
> pkt->len = msg->tx_len;
> } else {
> pkt->header = ...;
> pkt->payload = NULL;
> pkt->len = 0;
> }
> }
>
> This way in dsi host we will have sth like:
>
> host_transfer(...msg) {
> struct mipi_dsi_packet pkt;
>
> drm_mipi_create_packet(&pkt, msg);
>
> writel(msg.header, REG_HDR);
>
>for (i = 0; i < pkt.len; i += 4)
> writel(pkt.payload[i..i+3], REG_PAYLOAD);
> }
>
> Please note that this way we can avoid dynamic memory
> allocation/copy/deallocation, I know it is cheap, but it does not seems
> to be necessary.
Yes, that sounds pretty reasonable on a quick glance. I guess the
mipi_dsi_create_packet() function could take an additional parameter at
some point to generate the header ECC and checksum for hardware that
can't do it on the fly.
I'll give this a shot to see how it's going to work in practice. Given
how Exynos currently uses the application layer interface it should be
possible to use the helper as a means to transition more easily. Do you
plan on converting to the helper once it's available? It seems like it
would fit your hardware better than the current approach.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/c5f180f0/attachment.sig>
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/7c802f28/attachment.sig>
On 10/14/2014 04:16 PM, Thierry Reding wrote:
> On Tue, Oct 14, 2014 at 03:53:26PM +0200, Andrzej Hajda wrote:
>> On 10/14/2014 01:29 PM, Thierry Reding wrote:
>>> On Tue, Oct 14, 2014 at 01:25:44PM +0200, Andrzej Hajda wrote:
On 10/14/2014 12:57 PM, Thierry Reding wrote:
> On Tue, Oct 14,
120x2880
Two separate DP1.2 connectors, each using MST, for a 2x2 tile.
Cheers,
Dan
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/275e23a8/attachment.html>
veau and radeon drm drivers all support video
> decoding user space in some form.
Well yes, because they are GPUs that happen to have video decoding
engines on the same board and use the same method of command-stream
submission that they use for 2D or 3D work.
For standalone video decoding hardware, the only drivers that I know of
are in drivers/media.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/2c420a23/attachment-0001.sig>
7;t know how, so dealing with it in userspace
seems like a better option.
Just for my understanding, is it typical for each of these panels to be
standalone (own housing, ...) or are there monitors that actually take
two connectors and each of them drives a different part of the same
panel? A quick search on the internet indicates that the former is more
common (I haven't actually been able to find an example of the latter).
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/a8fc9762/attachment.sig>
, whereas we have nothing
like that at all in DRM.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/7297a8b1/attachment.sig>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/247094d8/attachment.html>
it X but hung then I SysRqd.
--
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/20141015/80d08f55/attachment.html>
[...]
--
Ben Hutchings
Horngren's Observation:
Among economists, the real world is often a special case.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/91dd8f0b/attachment-0001.sig>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/6eb561e6/attachment.html>
freedesktop.org/archives/dri-devel/attachments/20141015/b58bc54c/attachment.html>
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/d3dd1c84/attachment.html>
bug?
Seems unlikely.
--
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/20141015/1cd13e7f/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141015/5e0a85a8/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/724ce292/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=86301
dave.mueller at gmx.ch changed:
What|Removed |Added
Regression|No |Yes
--
You are receiving this ma
https://bugzilla.kernel.org/show_bug.cgi?id=86301
Bug ID: 86301
Summary: BUG_ON triggered in nouveau driver on !CONFIG_SMP
systems
Product: Drivers
Version: 2.5
Kernel Version: 3.17
Hardware: Intel
OS: L
closest earlier version you tried?
--
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/20141015/7ce285f9/attachment.html>
On 14 October 2014 21:40, Thierry Reding wrote:
> On Tue, Oct 14, 2014 at 01:23:22PM +1000, Dave Airlie wrote:
>> Hi,
>>
>> So I've been hacking on mutter and the gnome pieces for tiling, and
>> I've at least fixed mutter locally so maximise windows works and the
>> heads are in the right order.
>
be better with current Mesa Git master, see bug 84662.
--
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/20141015/b4a74382/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=59681
--- Comment #3 from Alexander E. Patrakov ---
Created attachment 153801
--> https://bugzilla.kernel.org/attachment.cgi?id=153801&action=edit
New dmesg with two dock + undock attempts
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=59681
--- Comment #2 from Alexander E. Patrakov ---
There was good progress on this undock bug since the report.
HD audio (with PulseAudio always opening the mixer) no longer is a thing that
prevents undocking. And, if I press the Undock button now, un
bed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/f4401d0c/attachment.html>
Hi Herrmann
> -Original Message-
> From: David Herrmann [mailto:dh.herrmann at gmail.com]
> Sent: Monday, October 13, 2014 10:27 PM
> To: Cheng, Yao
> Cc: Intel Graphics Development; Jiang, Fei; dri-devel at
> lists.freedesktop.org;
> Vetter, Daniel
> Subject: Re: [RFC PATCH 2/3] drm/ipvr
Thx Kelley/Reding for comments,
Yes, the vxd392 is a totally different IP and it also exist on Intel's non-GEN
platforms such as Merrifield. If we put it inside i915 there'll be issue if we
someday supports Merrifield.
-Original Message-
From: Sean V Kelley [mailto:sean.v.kel...@intel.co
Nikula, thx for reminder, will update it.
-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
Sent: Tuesday, October 14, 2014 9:27 PM
To: Cheng, Yao; intel-gfx at lists.freedesktop.org
Cc: Jiang, Fei; dri-devel at lists.freedesktop.org; Vetter, Daniel
Subject: Re: [I
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/8171b57b/attachment.html>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/a1e86ccb/attachment.html>
primarily in V4L2. I'm not sure that's the best fit given that
> it was originally designed for video capturing, but they've evolved some
> infrastructure to deal with encoding/decoding, whereas we have nothing
> like that at all in DRM.
>
That isn't true. i915, nouveau and radeon drm drivers all support video
decoding user space in some form.
St?phane
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141015/f03b4a55/attachment.html>
53 matches
Mail list logo
