On 23 July 2014 01:40, Benjamin Gaignard
wrote:
> Adding LKML and David in diffusion list to get an opinion on this patch
>
> 2014-07-10 10:01 GMT+02:00 Fabien DESSENNE :
>> Hi,
>> Can anyone review this patch ?
It's been in drm-next for a few weeks.
Dave.
part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140723/a189799a/attachment.sig>
non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140723/d85aabca/attachment.sig>
;
intel_display_power_get(dev_priv, power_domain);
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140723/bc8e9037/attachment-0001.sig>
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140723/efa553aa/attachment.html>
tachments/20140723/413260b2/attachment.html>
On 21.07.2014 17:07, Christian K?nig wrote:
> Am 19.07.2014 03:15, schrieb Michel D?nzer:
>> On 19.07.2014 00:47, Christian K?nig wrote:
>>> Am 18.07.2014 05:07, schrieb Michel D?nzer:
>> [PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on >= SI
> I'm still not very keen with this chan
On 22 July 2014 18:51, Russell King wrote:
> On Fri, Jul 11, 2014 at 09:03:44PM +0100, Russell King wrote:
>> David,
>>
>> Please incorporate the latest Armada DRM updates, which can be found at:
>>
>> git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-armada-devel
>
> Ping?
>
sorry I wanted to c
On 23 July 2014 06:02, Paulo Zanoni wrote:
> 2014-06-05 1:01 GMT-03:00 Dave Airlie :
>> From: Dave Airlie
>>
>> This adds DP 1.2 MST support on Haswell systems.
>
> Hi
>
> It looks like drm-intel-nightly now includes this patch. It actually
> includes v7, but I couldn't find it on my mail dirs.
>
On Wed, Jul 23, 2014 at 5:06 AM, Stephen Rothwell
wrote:
> P.S. Daniel, that drm-intel tree commit has no Signed-off-by from its
> author ...
Oops, fixed. Thanks for pointing this out.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On 18.07.2014 20:45, Marek Ol??k wrote:
> If the requirements of GL_MAP_COHERENT_BIT are satisfied, then the
> patch is okay.
AFAICT GL_MAP_COHERENT_BIT simply means the app doesn't need to call
glMemoryBarrier() to ensure coherency between access to the mapping and
GL commands. Since we don't nee
On 07/22/2014 01:20 PM, Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 09:12:20AM +0200, Thierry Reding wrote:
>> From: Thierry Reding
>>
>> Currently the mipi_dsi_dcs_write() function requires the DCS command
>> byte to be embedded within the write buffer whereas mipi_dsi_dcs_read()
>> has a sepa
op 22-07-14 17:59, Christian K?nig schreef:
> Am 22.07.2014 17:42, schrieb Daniel Vetter:
>> On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig
>> wrote:
>>> Drivers exporting fences need to provide a fence->signaled and a fence->wait
>>> function, everything else like fence->enable_signaling or cal
Am 23.07.2014 05:54, schrieb Michel D?nzer:
> On 21.07.2014 17:07, Christian K?nig wrote:
>> Am 19.07.2014 03:15, schrieb Michel D?nzer:
>>> On 19.07.2014 00:47, Christian K?nig wrote:
Am 18.07.2014 05:07, schrieb Michel D?nzer:
>>> [PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140723/ea2b220d/attachment.html>
On 22/07/14 14:15, Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 12:52:43PM +0300, Oded Gabbay wrote:
>> On 22/07/14 12:21, Daniel Vetter wrote:
>>> On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay
>>> wrote:
> Exactly, just prevent userspace from submitting more. And if you have
> misbehav
Am 23.07.2014 08:40, schrieb Maarten Lankhorst:
> op 22-07-14 17:59, Christian K?nig schreef:
>> Am 22.07.2014 17:42, schrieb Daniel Vetter:
>>> On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig
>>> wrote:
Drivers exporting fences need to provide a fence->signaled and a
fence->wait
On Wed, Jul 23, 2014 at 8:52 AM, Christian K?nig
wrote:
>> In the preliminary patches where I can sync radeon with other GPU's I've
>> been very careful in all the places that call into fences, to make sure that
>> radeon wouldn't try to handle lockups for a different (possibly also radeon)
>> car
Am 23.07.2014 08:50, schrieb Oded Gabbay:
> On 22/07/14 14:15, Daniel Vetter wrote:
>> On Tue, Jul 22, 2014 at 12:52:43PM +0300, Oded Gabbay wrote:
>>> On 22/07/14 12:21, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay
wrote:
>> Exactly, just prevent userspace fro
On Wed, Jul 23, 2014 at 8:50 AM, Oded Gabbay wrote:
> On 22/07/14 14:15, Daniel Vetter wrote:
>>
>> On Tue, Jul 22, 2014 at 12:52:43PM +0300, Oded Gabbay wrote:
>>>
>>> On 22/07/14 12:21, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay
wrote:
>>
>> Exactl
op 23-07-14 08:52, Christian K?nig schreef:
> Am 23.07.2014 08:40, schrieb Maarten Lankhorst:
>> op 22-07-14 17:59, Christian K?nig schreef:
>>> Am 22.07.2014 17:42, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig
wrote:
> Drivers exporting fences need to prov
On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
wrote:
>> Can we somehow avoid the need to call fence_signal() at all? The interrupts
>> at least on radeon are way to unreliable for such a thing. Can
>> enable_signalling fail? What's the reason for fence_signaled() in the first
>> place?
> I
Am 23.07.2014 09:09, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
> wrote:
>>> Can we somehow avoid the need to call fence_signal() at all? The interrupts
>>> at least on radeon are way to unreliable for such a thing. Can
>>> enable_signalling fail? What's the reas
On 23.07.2014 15:42, Christian K?nig wrote:
> Am 23.07.2014 05:54, schrieb Michel D?nzer:
>> On 21.07.2014 17:07, Christian K?nig wrote:
>>> Am 19.07.2014 03:15, schrieb Michel D?nzer:
On 19.07.2014 00:47, Christian K?nig wrote:
> Am 18.07.2014 05:07, schrieb Michel D?nzer:
[PATCH
vere bug, should a point release (7.4.1) be made?
--
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/20140723/3fb33871/attachment.html>
Am 23.07.2014 09:06, schrieb Maarten Lankhorst:
> op 23-07-14 08:52, Christian K?nig schreef:
>> Am 23.07.2014 08:40, schrieb Maarten Lankhorst:
>>> op 22-07-14 17:59, Christian K?nig schreef:
Am 22.07.2014 17:42, schrieb Daniel Vetter:
> On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig
>>
19 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140723/f21ff5ac/attachment.sig>
On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig
wrote:
> It's not a locking problem I'm talking about here. Radeons lockup handling
> kicks in when anything calls into the driver from the outside, if you have a
> fence wait function that's called from the outside but doesn't handle
> lockups you
Am 23.07.2014 09:21, schrieb Michel D?nzer:
> On 23.07.2014 15:42, Christian K?nig wrote:
>> Am 23.07.2014 05:54, schrieb Michel D?nzer:
>>> On 21.07.2014 17:07, Christian K?nig wrote:
Am 19.07.2014 03:15, schrieb Michel D?nzer:
> On 19.07.2014 00:47, Christian K?nig wrote:
>> Am 18.07
op 23-07-14 09:15, Christian K?nig schreef:
> Am 23.07.2014 09:09, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
>> wrote:
Can we somehow avoid the need to call fence_signal() at all? The
interrupts at least on radeon are way to unreliable for such a thing
Am 23.07.2014 09:31, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig
> wrote:
>> It's not a locking problem I'm talking about here. Radeons lockup handling
>> kicks in when anything calls into the driver from the outside, if you have a
>> fence wait function that's called
Am 23.07.2014 09:32, schrieb Maarten Lankhorst:
> op 23-07-14 09:15, Christian K?nig schreef:
>> Am 23.07.2014 09:09, schrieb Daniel Vetter:
>>> On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
>>> wrote:
> Can we somehow avoid the need to call fence_signal() at all? The
> interrupts at
From: Christian K?nig
We must mask out the overflow bit as well, otherwise
the wptr will never match the rptr again and the interrupt
handler will loop forever.
Signed-off-by: Christian K?nig
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c | 1 +
drivers/gpu/drm/radeon/eve
gt; and read,
> dcs-write is just write. Hiding this fact in API does not seems to me
> good, but I guess
> it is rather matter of taste.
The symmetry isn't about the physical transfers. It's a logical
symmetry. Each DCS command is identified by a command, whether it's a
read or a write.
There's a similar dissymmetry in how the payload length is handled.
Currently peripheral drivers need to encode that within the payload
buffer, and DSI host drivers need to parse it out of that depending on
the type of write. That makes it needlessly difficult for host drivers
and I think the interface would be much easier to use if peripheral
drivers specified the payload (and its length) only and let drivers
obtain the length of writes from the .tx_len field.
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/20140723/9ab34c36/attachment.sig>
op 23-07-14 09:37, Christian K?nig schreef:
> Am 23.07.2014 09:31, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig
>> wrote:
>>> It's not a locking problem I'm talking about here. Radeons lockup handling
>>> kicks in when anything calls into the driver from the outside,
> Regardless of the fence implementation, why would it be a good idea to do a
> full lockup recovery when some other driver is
> calling your wait function? That doesn't seem to be a nice thing to do, so I
> think a timeout is the best error you could return here,
> other drivers have to deal wit
On Wed, Jul 23, 2014 at 9:37 AM, Christian K?nig
wrote:
> Am 23.07.2014 09:31, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig
>> wrote:
>>>
>>> It's not a locking problem I'm talking about here. Radeons lockup
>>> handling
>>> kicks in when anything calls into the driv
On Wed, Jul 23, 2014 at 9:58 AM, Christian K?nig
wrote:
> Just imagine an application using prime is locking up Radeon and because of
> that gets killed by the user. Nothing else in the system would use the
> Radeon hardware any more and so radeon gets only called by another driver
> waiting patie
On 07/23/2014 09:27 AM, Thierry Reding wrote:
> On Tue, Jul 22, 2014 at 12:23:07PM +0200, Andrzej Hajda wrote:
>> Hi Thierry,
>>
>> YoungJun's comment refreshed my memory about mipi_dsi_dcs_write return
>> value. It should be rather int than ssize_t. Why?
>> .transfer() returns the number of read b
Am 23.07.2014 10:07, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 9:58 AM, Christian K?nig
> wrote:
>> Just imagine an application using prime is locking up Radeon and because of
>> that gets killed by the user. Nothing else in the system would use the
>> Radeon hardware any more and so radeon
op 23-07-14 10:20, Christian K?nig schreef:
> Am 23.07.2014 10:07, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 9:58 AM, Christian K?nig
>> wrote:
>>> Just imagine an application using prime is locking up Radeon and because of
>>> that gets killed by the user. Nothing else in the system would
Am 23.07.2014 10:01, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 9:37 AM, Christian K?nig
> wrote:
>> Am 23.07.2014 09:31, schrieb Daniel Vetter:
>>> On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig
>>> wrote:
It's not a locking problem I'm talking about here. Radeons lockup
handli
On 23/07/14 10:05, Daniel Vetter wrote:
> On Wed, Jul 23, 2014 at 8:50 AM, Oded Gabbay wrote:
>> On 22/07/14 14:15, Daniel Vetter wrote:
>>>
>>> On Tue, Jul 22, 2014 at 12:52:43PM +0300, Oded Gabbay wrote:
On 22/07/14 12:21, Daniel Vetter wrote:
>
> On Tue, Jul 22, 2014 at 10:19
On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
wrote:
> In this case if the sync was to i915 the i915 lockup procedure would take
> care of itself. It wouldn't fix radeon, but it would at least unblock your
> intel card again. I haven't specifically added a special case to attempt to
> unb
Am 23.07.2014 10:42, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
> wrote:
>> In this case if the sync was to i915 the i915 lockup procedure would take
>> care of itself. It wouldn't fix radeon, but it would at least unblock your
>> intel card again. I haven't spe
On Wed, Jul 23, 2014 at 10:46 AM, Christian K?nig
wrote:
> Am 23.07.2014 10:42, schrieb Daniel Vetter:
>
>> On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
>> wrote:
>>>
>>> In this case if the sync was to i915 the i915 lockup procedure would take
>>> care of itself. It wouldn't fix radeon, b
On 23.07.2014 16:47, Christian K?nig wrote:
> From: Christian K?nig
>
> We must mask out the overflow bit as well, otherwise
> the wptr will never match the rptr again and the interrupt
> handler will loop forever.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Michel D?nzer
> Cc: stable a
Am 23.07.2014 10:54, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 10:46 AM, Christian K?nig
> wrote:
>> Am 23.07.2014 10:42, schrieb Daniel Vetter:
>>
>>> On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
>>> wrote:
In this case if the sync was to i915 the i915 lockup procedure would t
On Wed, Jul 23, 2014 at 11:27 AM, Christian K?nig
wrote:
> You submit a job to the hardware and then block the job to wait for radeon
> to be finished? Well than this would indeed require a hardware reset, but
> wouldn't that make the whole problem even worse?
>
> I mean currently we block one use
Am 23.07.2014 11:30, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 11:27 AM, Christian K?nig
> wrote:
>> You submit a job to the hardware and then block the job to wait for radeon
>> to be finished? Well than this would indeed require a hardware reset, but
>> wouldn't that make the whole proble
op 23-07-14 11:36, Christian K?nig schreef:
> Am 23.07.2014 11:30, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 11:27 AM, Christian K?nig
>> wrote:
>>> You submit a job to the hardware and then block the job to wait for radeon
>>> to be finished? Well than this would indeed require a hardware
On Wed, Jul 23, 2014 at 11:36 AM, Christian K?nig
wrote:
> Am 23.07.2014 11:30, schrieb Daniel Vetter:
>
>> On Wed, Jul 23, 2014 at 11:27 AM, Christian K?nig
>> wrote:
>>>
>>> You submit a job to the hardware and then block the job to wait for
>>> radeon
>>> to be finished? Well than this would i
Am 23.07.2014 11:38, schrieb Maarten Lankhorst:
> op 23-07-14 11:36, Christian K?nig schreef:
>> Am 23.07.2014 11:30, schrieb Daniel Vetter:
>>> On Wed, Jul 23, 2014 at 11:27 AM, Christian K?nig
>>> wrote:
You submit a job to the hardware and then block the job to wait for radeon
to be f
On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
wrote:
> The scheduler needs to keep track of a lot of fences, so I think we'll
> have to register callbacks, not a simple wait function. We must keep
> track of all the non-i915 fences for all oustanding batches. Also, the
> scheduler doesn't elimi
On Tue, Jul 22, 2014 at 9:14 PM, Jesse Barnes
wrote:
>> We don't have the code yet ready, but that's the direction i915 will
>> move towards for the near future. Jesse is working on some patches
>> already.
>
> Yeah I'd like to get some feedback from Maarten on my bits so I can get
> them ready f
Am 23.07.2014 11:44, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
> wrote:
>> The scheduler needs to keep track of a lot of fences, so I think we'll
>> have to register callbacks, not a simple wait function. We must keep
>> track of all the non-i915 fences for all oust
On Wed, Jul 23, 2014 at 11:47 AM, Christian K?nig
wrote:
> Am 23.07.2014 11:44, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
>> wrote:
>>>
>>> The scheduler needs to keep track of a lot of fences, so I think we'll
>>> have to register callbacks, not a simple wait func
op 23-07-14 11:47, Christian K?nig schreef:
> Am 23.07.2014 11:44, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
>> wrote:
>>> The scheduler needs to keep track of a lot of fences, so I think we'll
>>> have to register callbacks, not a simple wait function. We must kee
Am 23.07.2014 11:07, schrieb Michel D?nzer:
> On 23.07.2014 16:47, Christian K?nig wrote:
>> From: Christian K?nig
>>
>> We must mask out the overflow bit as well, otherwise
>> the wptr will never match the rptr again and the interrupt
>> handler will loop forever.
>>
>> Signed-off-by: Christian K
Am 23.07.2014 11:55, schrieb Maarten Lankhorst:
> op 23-07-14 11:47, Christian K?nig schreef:
>> Am 23.07.2014 11:44, schrieb Daniel Vetter:
>>> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
>>> wrote:
The scheduler needs to keep track of a lot of fences, so I think we'll
have to regi
On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig
wrote:
>
>> And the dma-buf would still have fences belonging to both drivers, and it
>> would still call from outside the driver.
>
>
> Calling from outside the driver is fine as long as the driver can do
> everything necessary to complete it's wo
On 07/23/2014 09:51 AM, Thierry Reding wrote:
> On Tue, Jul 22, 2014 at 11:33:11AM +0200, Andrzej Hajda wrote:
>> On 07/22/2014 10:12 AM, Thierry Reding wrote:
>>> On Tue, Jul 22, 2014 at 09:32:58AM +0200, Andrzej Hajda wrote:
On 07/22/2014 09:12 AM, Thierry Reding wrote:
> From: Thierry R
Sean,
On Tue, Jul 22, 2014 at 8:29 PM, Sean Paul wrote:
> On Thu, Jul 17, 2014 at 4:43 PM, Ajay Kumar
> wrote:
>> Move the DP training and video enable from the hotplug handler into
>> a seperate function and call the same during dpms ON.
>>
>> With existing code, DP HPD should be generated jus
This sounds good to me.
Marek
On Wed, Jul 23, 2014 at 8:32 AM, Michel D?nzer wrote:
> On 18.07.2014 20:45, Marek Ol??k wrote:
>> If the requirements of GL_MAP_COHERENT_BIT are satisfied, then the
>> patch is okay.
>
> AFAICT GL_MAP_COHERENT_BIT simply means the app doesn't need to call
> glMemor
https://bugzilla.kernel.org/show_bug.cgi?id=81001
Bug ID: 81001
Summary: radeon: fence wait failed (-35) after hybrid suspend,
leading to GPU reset and hangs
Product: Drivers
Version: 2.5
Kernel Version: 3.15+
Hardware:
On Wed, Jul 23, 2014 at 9:21 AM, Michel D?nzer wrote:
> On 23.07.2014 15:42, Christian K?nig wrote:
>> Am 23.07.2014 05:54, schrieb Michel D?nzer:
>>> On 21.07.2014 17:07, Christian K?nig wrote:
Am 19.07.2014 03:15, schrieb Michel D?nzer:
> On 19.07.2014 00:47, Christian K?nig wrote:
On Wed, Jul 23, 2014 at 2:52 AM, Christian K?nig
wrote:
> Am 23.07.2014 08:40, schrieb Maarten Lankhorst:
>
>> op 22-07-14 17:59, Christian K?nig schreef:
>>>
>>> Am 22.07.2014 17:42, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig
wrote:
>
> Drivers
Am 23.07.2014 12:52, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig
> wrote:
>>> And the dma-buf would still have fences belonging to both drivers, and it
>>> would still call from outside the driver.
>>
>> Calling from outside the driver is fine as long as the driver c
On Wed, Jul 23, 2014 at 2:36 PM, Christian K?nig
wrote:
> My idea was more that the fence framework provides a
> fence->process_signaling callback that is periodically called after
> enable_signaling is called to trigger manual signal processing in the
> driver.
>
> This would both be suitable as
op 23-07-14 14:36, Christian K?nig schreef:
> Am 23.07.2014 12:52, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig
>> wrote:
And the dma-buf would still have fences belonging to both drivers, and it
would still call from outside the driver.
>>>
>>> Calling fro
>-Original Message-
>From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch]
>Sent: Wednesday, July 23, 2014 3:06 AM
>To: Gabbay, Oded
>Cc: Jerome Glisse; Christian K?nig; David Airlie; Alex Deucher; Andrew
>Morton; Bridgman, John; Joerg Roedel; Lewycky, Andrew; Daenzer, Michel;
>Goz, Ben;
uls the purpose of the DCS functions. They should
really be making it easier for both host and peripheral drivers by
translating between DCS and the raw DSI packet data.
So what I'm currently thinking is that we need a better definition for
exactly what data should go into a struct mipi_dsi_msg. I think it
should be raw DSI data (that is, including the header and the payload)
so that the only job of drivers is to write it into the corresponding
FIFO registers and start the transmission.
Similarly, when receiving data the .transfer() function should pass up a
complete buffer (including the header and payload) to the receive buffer
and let some upper layer handle this. That way we can layer things in
helpers rather than having to duplicate the same code in each DSI host
driver.
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/20140723/481aec68/attachment.sig>
>-Original Message-
>From: Christian K?nig [mailto:deathsimple at vodafone.de]
>Sent: Wednesday, July 23, 2014 3:04 AM
>To: Gabbay, Oded; Jerome Glisse; David Airlie; Alex Deucher; Andrew
>Morton; Bridgman, John; Joerg Roedel; Lewycky, Andrew; Daenzer, Michel;
>Goz, Ben; Skidanov, Alexey;
On Tue, Jul 22, 2014 at 11:54 PM, Michel D?nzer wrote:
> On 21.07.2014 17:07, Christian K?nig wrote:
>> Am 19.07.2014 03:15, schrieb Michel D?nzer:
>>> On 19.07.2014 00:47, Christian K?nig wrote:
Am 18.07.2014 05:07, schrieb Michel D?nzer:
>>> [PATCH 5/5] drm/radeon: Use VRAM for indirect
op 23-07-14 15:16, Maarten Lankhorst schreef:
> op 23-07-14 14:36, Christian K?nig schreef:
>> Am 23.07.2014 12:52, schrieb Daniel Vetter:
>>> On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig
>>> wrote:
> And the dma-buf would still have fences belonging to both drivers, and it
> would st
Sorry for the noise! Please disregard the patch for now, it causes more trouble
than it solves!
- Tobias
?
Gesendet:?Mittwoch, 23. Juli 2014 um 15:57 Uhr
Von:?"Tobias Jakobi"
An:?linux-samsung-soc at vger.kernel.org
Cc:?dri-devel at lists.freedesktop.org, t.figa at samsung.com, inki.dae at
sam
On Wed, Jul 23, 2014 at 01:33:24PM +, Bridgman, John wrote:
>
>
> >-Original Message-
> >From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch]
> >Sent: Wednesday, July 23, 2014 3:06 AM
> >To: Gabbay, Oded
> >Cc: Jerome Glisse; Christian K?nig; David Airlie; Alex Deucher; Andrew
> >Mo
On Wed, Jul 23, 2014 at 09:04:24AM +0200, Christian K?nig wrote:
> Am 23.07.2014 08:50, schrieb Oded Gabbay:
> >On 22/07/14 14:15, Daniel Vetter wrote:
> >>On Tue, Jul 22, 2014 at 12:52:43PM +0300, Oded Gabbay wrote:
> >>>On 22/07/14 12:21, Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 10:19 A
>-Original Message-
>From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
>Vetter
>Sent: Wednesday, July 23, 2014 10:42 AM
>To: Bridgman, John
>Cc: Daniel Vetter; Gabbay, Oded; Jerome Glisse; Christian K?nig; David Airlie;
>Alex Deucher; Andrew Morton; Joerg Roedel;
>-Original Message-
>From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
>Of Bridgman, John
>Sent: Wednesday, July 23, 2014 11:07 AM
>To: Daniel Vetter
>Cc: Lewycky, Andrew; linux-mm; Daniel Vetter; Daenzer, Michel; linux-
>kernel at vger.kernel.org; Sellek, Tom;
On Wed, Jul 23, 2014 at 8:12 PM, Sean Paul wrote:
> On Wed, Jul 23, 2014 at 7:22 AM, Ajay kumar wrote:
>> Sean,
>>
>> On Tue, Jul 22, 2014 at 8:29 PM, Sean Paul wrote:
>>> On Thu, Jul 17, 2014 at 4:43 PM, Ajay Kumar
>>> wrote:
Move the DP training and video enable from the hotplug handler
Hi
A bunch of random cleanups I stumbled on when reworking the init-logic. Most of
them should be fairly trivial.
Also available in my fdo-repository:
http://cgit.freedesktop.org/~dvdhrm/linux/log/?h=drm-next
Comments welcome!
David
David Herrmann (12):
drm: remove unused "struct drm_freel
This object is unused, drop it.
Signed-off-by: David Herrmann
---
include/drm/drmP.h | 17 -
1 file changed, 17 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 335b7b8..d3d9be6 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -430,23 +430,6 @@
This object is not used except for static fields in drm_bufs *cough*.
Inline the watermark fields and drop the unused structure definition.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_bufs.c | 17 -
drivers/gpu/drm/drm_info.c | 2 +-
include/drm/drmP.h | 15 ++-
Lets order things correctly:
->load()
->fistopen()
->open()
->close()
->lastclose()
->unload()
This doesn't change much as only savage and radeon use ->firstopen() and
they just do map-initialization. Therefore, the global drm mutex makes
sure there cannot be any other f_op betwe
The ctxbitmap code is only used by legacy drivers so lets try to keep it
as separated as possible. Furthermore, the locking is non-obvious and
kinda weird with ctxlist_mutex *and* struct_mutex. Keeping all ctxbitmap
access in one file is much easier to review and makes drm_release() more
readable.
Linux doesn't run on i386, anymore. See:
commit d55c5a93db2d5fa95f233ab153f594365d95b777
Author: H. Peter Anvin
Date: Wed Nov 28 11:50:24 2012 -0800
x86, 386 removal: Remove CONFIG_CMPXCHG
All 486+ CPUs support CMPXCHG, so remove the fallback 386 support
co
The drm_file->is_master field is redundant as it's equivalent to:
drm_file->master && drm_file->master == drm_file->minor->master
1) "=>"
Whenever we set drm_file->is_master, we also set:
drm_file->minor->master = drm_file->master;
Whenever we clear drm_file->is_master, we also call
Testing the return value of list_entry() for NULL is a no-op (as it is
just a fancy container_of() / offsetof()). Drop the superfluous if-clause
and instead verify the actual root-node is available. This is probably
what it was meant to test for from the beginning, anyway.
Signed-off-by: David Her
If an active DRM-Master closes its device, we deauthenticate all clients
on that master. However, if an inactive DRM-Master closes its device, we
do nothing. This is quite inconsistent and breaks several scenarios:
1) If this was used as security mechanism, it fails horribly if a master
close
Most of the new DRM management functions are nowadays in drm_stub.c. By
moving the core module initialization to drm_stub.c we can make several
global variables static and keep the stub-open helper local.
The core files now look like this:
drm_stub.c: Core management
drm_drv.c: Ioctl dispatch
All that is left in drm_drv.c is ioctl management. Merge it into
drm_ioctl.c so we have all ioctl management in one file (and the name is
much more fitting).
Maybe we should now rename drm_stub.c to drm_drv.c again?
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_drv.c | 412 ---
Instead of allocating the minor-index during registration, we now do this
during allocation. This way, debug-messages between minor-allocation and
minor-registration will now use the correct minor instead of 0. Same is
done for unregistration vs. free, so debug-messages between
device-shutdown and
For each minor we allocate a sysfs device as minor->kdev. Currently, this
is allocated and registered in drm_minor_register(). This makes it
impossible to add sysfs-attributes to the device before it is registered.
Therefore, they are not added atomically, nor can we move device_add()
*after* ->loa
On Wed, 23 Jul 2014 11:47:15 +0200
Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 9:14 PM, Jesse Barnes
> wrote:
> >> We don't have the code yet ready, but that's the direction i915 will
> >> move towards for the near future. Jesse is working on some patches
> >> already.
> >
> > Yeah I'd like
On Wed, Jul 23, 2014 at 3:47 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> We must mask out the overflow bit as well, otherwise
> the wptr will never match the rptr again and the interrupt
> handler will loop forever.
>
> Signed-off-by: Christian K?nig
> Cc: stable at vger.kernel.org
A
Hi
On Wed, Jul 23, 2014 at 5:26 PM, David Herrmann
wrote:
> All that is left in drm_drv.c is ioctl management. Merge it into
> drm_ioctl.c so we have all ioctl management in one file (and the name is
> much more fitting).
>
> Maybe we should now rename drm_stub.c to drm_drv.c again?
>
> Signed-o
On Wed, Jul 23, 2014 at 11:26 AM, David Herrmann
wrote:
> Hi
>
> A bunch of random cleanups I stumbled on when reworking the init-logic. Most
> of
> them should be fairly trivial.
>
> Also available in my fdo-repository:
>http://cgit.freedesktop.org/~dvdhrm/linux/log/?h=drm-next
>
> Comments
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140723/4db82534/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140723/277a13a8/attachment.html>
1 - 100 of 140 matches
Mail list logo
