On Tue, Jul 08, 2014 at 10:31:59AM +0530, sonika.jindal at intel.com wrote:
> From: Ville Syrj?l?
>
> Sprite planes support 180 degree rotation. The lower layers are now in
> place, so hook in the standard rotation property to expose the feature
> to the users.
>
> v2: Moving rotation_property t
>From: Ilyes Gouta [mailto:ilyes.gouta at gmail.com]
>Sent: Friday, July 11, 2014 2:00 PM
>To: Bridgman, John
>Cc: Alex Deucher; Koenig, Christian; Oded Gabbay; Deucher, Alexander; Lewycky,
>Andrew; LKML; Maling list - DRI developers
>Subject: Re: [PATCH 02/83] drm/radeon: reduce number of free V
does indeed run or keep it open for performance
issues?
--
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/20140711/07c7710d/attachment.html>
On Thu, Jul 10, 2014 at 11:55:26AM +0200, Thierry Reding wrote:
> On Wed, Mar 26, 2014 at 09:32:47AM +0100, Thierry Reding wrote:
> > On Tue, Mar 25, 2014 at 07:01:10PM +0100, Sam Ravnborg wrote:
> > > >
> > > > There are two things that don't work too well with this. First this
> > > > causes the
is enabled.
With the good old profile method the system is stable.
--
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
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
with SHA1 9611cb93fa65dde199f4f888bd034ffc80c7adf0, based on v3.16-rc3.
This pull includes the component helpers which have been merged into
Greg's dr
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk at oracle.com]
> Sent: Friday, July 11, 2014 12:42 PM
>
> On Fri, Jul 11, 2014 at 08:29:56AM +0200, Daniel Vetter wrote:
> > On Thu, Jul 10, 2014 at 09:08:24PM +, Tian, Kevin wrote:
> > > actually I'm curious whether it's still necessary to __d
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140711/ec0fef18/attachment.html>
On Fri, Jul 11, 2014 at 7:04 PM, Jerome Glisse wrote:
> Are we to assume that for eternity this will not work on iommu that do support
> PASID/ATS but are not from AMD ? If it was an APU specific function i would
> understand but it seems that the IOMMU API needs to grow. I am pretty sure
> Intel
n HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140711/bd9bbc2b/attachment.html>
>-Original Message-
>From: Jerome Glisse [mailto:j.glisse at gmail.com]
>Sent: Friday, July 11, 2014 2:52 PM
>To: Bridgman, John
>Cc: Oded Gabbay; David Airlie; Deucher, Alexander; linux-
>kernel at vger.kernel.org; dri-devel at lists.freedesktop.org; Lewycky, Andrew;
>Joerg Roedel; Gabba
>-Original Message-
>From: Jerome Glisse [mailto:j.glisse at gmail.com]
>Sent: Friday, July 11, 2014 2:11 PM
>To: Bridgman, John
>Cc: Oded Gabbay; David Airlie; Deucher, Alexander; linux-
>kernel at vger.kernel.org; dri-devel at lists.freedesktop.org; Lewycky, Andrew;
>Joerg Roedel; Gabba
On 07/11/2014 04:41 PM, Daniel Vetter wrote:
> On Fri, Jul 11, 2014 at 11:40:27AM +0900, Alexandre Courbot wrote:
>> On 07/10/2014 10:04 PM, Daniel Vetter wrote:
>>> On Tue, Jul 08, 2014 at 05:25:59PM +0900, Alexandre Courbot wrote:
On architectures for which access to GPU memory is non-cohere
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140711/98ead57b/attachment.html>
Am 11.07.2014 18:05, schrieb Jerome Glisse:
> On Fri, Jul 11, 2014 at 12:50:02AM +0300, Oded Gabbay wrote:
>> To support HSA on KV, we need to limit the number of vmids and pipes
>> that are available for radeon's use with KV.
>>
>> This patch reserves VMIDs 8-15 for KFD (so radeon can only use VMI
>-Original Message-
>From: Jerome Glisse [mailto:j.glisse at gmail.com]
>Sent: Friday, July 11, 2014 1:04 PM
>To: Oded Gabbay
>Cc: David Airlie; Deucher, Alexander; linux-kernel at vger.kernel.org; dri-
>devel at lists.freedesktop.org; Bridgman, John; Lewycky, Andrew; Joerg
>Roedel; Gabba
On Fri, 11 Jul 2014 17:47:05 +0200
Boris BREZILLON wrote:
> On Fri, 11 Jul 2014 11:41:12 -0400
> Rob Clark wrote:
>
> > On Fri, Jul 11, 2014 at 11:17 AM, Boris BREZILLON
> > wrote:
> > > Make use of lists instead of kfifo in order to dynamically allocate
> > > task entry when someone require s
Checking... we shouldn't need to call the lock from kfd any more.We should be
able to do any required locking in radeon kgd code.
>-Original Message-
>From: Jerome Glisse [mailto:j.glisse at gmail.com]
>Sent: Friday, July 11, 2014 12:35 PM
>To: Oded Gabbay
>Cc: David Airlie; Deucher, Alex
On Fri, 11 Jul 2014 11:41:12 -0400
Rob Clark wrote:
> On Fri, Jul 11, 2014 at 11:17 AM, Boris BREZILLON
> wrote:
> > Make use of lists instead of kfifo in order to dynamically allocate
> > task entry when someone require some delayed work, and thus preventing
> > drm_flip_work_queue from directl
On Thu, Jul 10, 2014 at 10:51:29PM +, Gabbay, Oded wrote:
> On Thu, 2014-07-10 at 18:24 -0400, Jerome Glisse wrote:
> > On Fri, Jul 11, 2014 at 12:45:27AM +0300, Oded Gabbay wrote:
> > > This patch set implements a Heterogeneous System Architecture
> > > (HSA) driver
> > > for radeon-family
On 07/11/2014 04:37 PM, Russell King - ARM Linux wrote:
> On Sat, Jul 05, 2014 at 01:58:37PM +0200, Sebastian Hesselbarth wrote:
>> On 07/05/2014 12:38 PM, Russell King wrote:
>>> Move the variant initialisation entirely to the CRTC init function -
>>> the variant support is really about the CRTC p
Make use of lists instead of kfifo in order to dynamically allocate
task entry when someone require some delayed work, and thus preventing
drm_flip_work_queue from directly calling func instead of queuing this
call.
This allow drm_flip_work_queue to be safely called even within irq
handlers.
Add n
>-Original Message-
>From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
>Of Alex Deucher
>Sent: Friday, July 11, 2014 12:23 PM
>To: Koenig, Christian
>Cc: Oded Gabbay; Lewycky, Andrew; LKML; Maling list - DRI developers;
>Deucher, Alexander
>Subject: Re: [PATCH
On Fri, Jul 11, 2014 at 12:50:13AM +0300, Oded Gabbay wrote:
> This patch adds 2 new IOCTL to kfd driver.
>
> The first IOCTL is KFD_IOC_CREATE_QUEUE that is used by the user-mode
> application to create a compute queue on the GPU.
>
> The second IOCTL is KFD_IOC_DESTROY_QUEUE that is used by the
On Fri, Jul 11, 2014 at 12:54:00AM +0300, Oded Gabbay wrote:
> From: Alexey Skidanov
>
> Added apertures initialization and appropriate ioctl
What is process aperture and what it is use for ? This is a very
cryptic commit message.
Cheers,
J?r?me
>
> Signed-off-by: Alexey Skidanov
> Signed-of
On Fri, Jul 11, 2014 at 12:53:48AM +0300, Oded Gabbay wrote:
> From: Evgeny Pinchuk
>
> Implemented new IOCTL to query the CPU and GPU clock counters.
>
> Signed-off-by: Evgeny Pinchuk
> Signed-off-by: Oded Gabbay
> ---
> drivers/gpu/hsa/radeon/kfd_chardev.c | 37
> ++
https://bugzilla.kernel.org/show_bug.cgi?id=79051
Jonathan Howard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=79071
Jonathan Howard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Fri, Jul 11, 2014 at 05:18:50PM +0200, Sebastian Hesselbarth wrote:
> On 07/11/2014 04:37 PM, Russell King - ARM Linux wrote:
>> What's left is the display-subsystem { } entity to describe the makeup
>> of the subsystem. That's not included as we currently need to pass
>> a block of memory, and
/glib2.0-f_gKLq/glib2.0-2.40.0/./glib/gmain.c:3928
__FUNCTION__ = "g_main_loop_run"
#7 0xb506b0ad in gtk_main () at
/build/gtk+3.0-sS5UZs/gtk+3.0-3.12.2/./gtk/gtkmain.c:1192
loop = 0x9f3312d8
#8 0xb7720a9e in main (argc=1, argv=0xbf9c1474) at main.c:680
shell = 0xb8ed70b8
settings =
error = 0x0
--
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/20140711/1bf6fa3a/attachment-0001.html>
use:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140711/5c7621cd/attachment-0001.html>
On Fri, Jul 11, 2014 at 12:50:15AM +0300, Oded Gabbay wrote:
> This patch adds the interrupt handling module, in kfd_interrupt.c,
> and its related members in different data structures to the KFD
> driver.
>
> The KFD interrupt module maintains an internal interrupt ring per kfd
> device. The inte
From: Christian K?nig
This patch adds an IOCTL for turning a pointer supplied by
userspace into a buffer object.
It imposes several restrictions upon the memory being mapped:
1. It must be page aligned (both start/end addresses, i.e ptr and size).
2. It must be normal system memory, not a poin
From: Christian K?nig
v2: use flag instead of boolean
v3: keep R600_PTE_GART as it is
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/r100.c| 2 +-
drivers/gpu/drm/radeon/r300.c| 8 ++--
drivers/gpu/drm/radeon/radeon.h | 10 ++
drivers/gpu/drm/radeo
On Fri, Jul 11, 2014 at 08:29:56AM +0200, Daniel Vetter wrote:
> On Thu, Jul 10, 2014 at 09:08:24PM +, Tian, Kevin wrote:
> > actually I'm curious whether it's still necessary to __detect__ PCH. Could
> > we assume a 1:1 mapping between GPU and PCH, e.g. BDW already hard
> > code the knowledge:
On Sat, Jul 05, 2014 at 01:58:37PM +0200, Sebastian Hesselbarth wrote:
> On 07/05/2014 12:38 PM, Russell King wrote:
> > Move the variant initialisation entirely to the CRTC init function -
> > the variant support is really about the CRTC properties than the whole
> > system, and we want to treat e
On Fri, Jul 11, 2014 at 06:56:12PM +, Bridgman, John wrote:
> >From: Jerome Glisse [mailto:j.glisse at gmail.com]
> >Sent: Friday, July 11, 2014 2:52 PM
> >To: Bridgman, John
> >Cc: Oded Gabbay; David Airlie; Deucher, Alexander; linux-
> >kernel at vger.kernel.org; dri-devel at lists.freedeskto
On Fri, Jul 11, 2014 at 12:50:13AM +0300, Oded Gabbay wrote:
> This patch adds 2 new IOCTL to kfd driver.
>
> The first IOCTL is KFD_IOC_CREATE_QUEUE that is used by the user-mode
> application to create a compute queue on the GPU.
>
> The second IOCTL is KFD_IOC_DESTROY_QUEUE that is used by the
ot available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140711/63aa3843/attachment-0001.sig>
On Fri, Jul 11, 2014 at 06:46:30PM +, Bridgman, John wrote:
> >From: Jerome Glisse [mailto:j.glisse at gmail.com]
> >Sent: Friday, July 11, 2014 2:11 PM
> >To: Bridgman, John
> >Cc: Oded Gabbay; David Airlie; Deucher, Alexander; linux-
> >kernel at vger.kernel.org; dri-devel at lists.freedeskto
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140711/8561933c/attachment.html>
On Fri, Jul 11, 2014 at 12:50:12AM +0300, Oded Gabbay wrote:
> This patch adds the kfd mmap handler that maps the physical address
> of a doorbell page to a user-space virtual address. That virtual address
> belongs to the process that uses the doorbell page.
>
> This mmap handler is called only f
Hello Fabio,
On 11 Jul 12:08 PM, Fabio Estevam wrote:
> On Fri, Jul 11, 2014 at 11:18 AM, Ezequiel Garcia
> wrote:
> > In order to support the "enable GPIO" available in many panel devices,
> > this commit adds a proper devicetree binding.
> >
> > By providing an enable GPIO in the devicetree, th
On Fri, Jul 11, 2014 at 12:50:11AM +0300, Oded Gabbay wrote:
> This patch adds the code base of the scheduler, which handles queue
> creation, deletion and scheduling on the CP of the GPU.
>
> Signed-off-by: Oded Gabbay
I would rather see all this squashed, this gave feeling that driver
can acce
On Fri, 11 Jul 2014 14:00:25 +0200
Boris BREZILLON wrote:
> On Fri, 11 Jul 2014 12:37:46 +0200
> Laurent Pinchart wrote:
>
> > Hi Boris,
> >
> > On Thursday 10 July 2014 14:56:26 Boris BREZILLON wrote:
> > > On Thu, 10 Jul 2014 13:16:21 +0200 Laurent Pinchart wrote:
> > > > On Monday 07 July 2
On Fri, Jul 11, 2014 at 06:02:39PM +, Bridgman, John wrote:
> >From: Jerome Glisse [mailto:j.glisse at gmail.com]
> >Sent: Friday, July 11, 2014 1:04 PM
> >To: Oded Gabbay
> >Cc: David Airlie; Deucher, Alexander; linux-kernel at vger.kernel.org; dri-
> >devel at lists.freedesktop.org; Bridgman,
On Fri, 11 Jul 2014 12:37:46 +0200
Laurent Pinchart wrote:
> Hi Boris,
>
> On Thursday 10 July 2014 14:56:26 Boris BREZILLON wrote:
> > On Thu, 10 Jul 2014 13:16:21 +0200 Laurent Pinchart wrote:
> > > On Monday 07 July 2014 18:42:59 Boris BREZILLON wrote:
> > > > The Atmel HLCDC (HLCD Controller
On Fri, Jul 11, 2014 at 04:01:02AM +0200, Ben Skeggs wrote:
> On Fri, Jul 11, 2014 at 11:49 AM, Alexandre Courbot
> wrote:
> > On 07/10/2014 06:43 PM, Peter De Schrijver wrote:
> >>
> >> On Thu, Jul 10, 2014 at 09:34:34AM +0200, Alexandre Courbot wrote:
> >>>
> >>> This series adds support for re
On Fri, Jul 11, 2014 at 03:49:06AM +0200, Alex Courbot wrote:
> On 07/10/2014 06:43 PM, Peter De Schrijver wrote:
> > On Thu, Jul 10, 2014 at 09:34:34AM +0200, Alexandre Courbot wrote:
> >> This series adds support for reclocking on GK20A. The first two patches
> >> touch
> >> the clock subsystem
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140711/8599560b/attachment-0001.html>
ceiving 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/20140711/51174227/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140711/6fc31fc9/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140711/170bc302/attachment.html>
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140711/d0f33c01/attachment.html>
On Fri, Jul 11, 2014 at 12:50:09AM +0300, Oded Gabbay wrote:
> This patch adds the code base of the hsa driver for
> AMD's GPUs.
>
> This driver is called kfd.
>
> This initial version supports the first HSA chip, Kaveri.
>
> This driver is located in a new directory structure under drivers/gpu.
On Fri, Jul 11, 2014 at 12:35 PM, Alexandre Courbot
wrote:
> On 07/10/2014 09:58 PM, Daniel Vetter wrote:
>>
>> On Tue, Jul 08, 2014 at 05:25:57PM +0900, Alexandre Courbot wrote:
>>>
>>> page_to_phys() is not the correct way to obtain the DMA address of a
>>> buffer on a non-PCI system. Use the D
On Fri, 2014-07-11 at 15:22 -0400, Jerome Glisse wrote:
> Just to be explicit, my point is that is you claim GPL in MODULE_LICENSE
> then this is a GPL licensed code, if you claim GPL with additional rights
> than this is dual licensed code. This is how i read and interpret this
> with additional r
Hi Boris,
On Thursday 10 July 2014 14:56:26 Boris BREZILLON wrote:
> On Thu, 10 Jul 2014 13:16:21 +0200 Laurent Pinchart wrote:
> > On Monday 07 July 2014 18:42:59 Boris BREZILLON wrote:
> > > The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
> > > at91sam9n12, at91sam9x5 fam
On Fri, Jul 11, 2014 at 12:50:08AM +0300, Oded Gabbay wrote:
> The KFD driver should be loaded when the radeon driver is loaded and
> should be finalized when the radeon driver is removed.
>
> This patch adds a function call to initialize kfd from radeon_init
> and a function call to finalize kfd
On Fri, Jul 11, 2014 at 12:50:07AM +0300, Oded Gabbay wrote:
> This patch adds a new interface to kfd2kgd_calls structure, which
> allows the kfd to lock and unlock the srbm_gfx_cntl register
Why does kfd needs to lock this register if kfd can not access
any of those register ? This sounds broken
On Fri, Jul 11, 2014 at 12:50:06AM +0300, Oded Gabbay wrote:
> This patch adds new interfaces to kfd2kgd_calls structure.
>
> The new interfaces allow the kfd driver to :
>
> 1. Allocated video memory through the radeon driver
> 2. Map and unmap video memory with GPUVM through the radeon driver
>
On Fri, Jul 11, 2014 at 12:50:05AM +0300, Oded Gabbay wrote:
> This patch adds a new interface to kfd2kgd_calls structure so that
> the kfd driver could get the virtual ram size of a specific
> radeon device.
>
> Signed-off-by: Oded Gabbay
What is vmem_size ? This need to be documented. I assume
On Thu, Jul 10, 2014 at 03:38:33PM -0700, Joe Perches wrote:
> On Fri, 2014-07-11 at 00:50 +0300, Oded Gabbay wrote:
> > This patch adds the interface between the radeon driver and the kfd
> > driver. The interface implementation is contained in
> > radeon_kfd.c and radeon_kfd.h.
> []
> > include/
On Fri, Jul 11, 2014 at 12:18 PM, Christian K?nig
wrote:
> Am 11.07.2014 18:05, schrieb Jerome Glisse:
>
>> On Fri, Jul 11, 2014 at 12:50:02AM +0300, Oded Gabbay wrote:
>>>
>>> To support HSA on KV, we need to limit the number of vmids and pipes
>>> that are available for radeon's use with KV.
>>>
On Fri, Jul 11, 2014 at 12:50:03AM +0300, Oded Gabbay wrote:
> Radeon and KFD share the doorbell aperture.
> Radeon sets it up, takes the doorbells required for its own rings
> and reports the setup to KFD.
> Radeon reserved doorbells are at the start of the doorbell aperture.
>
> Signed-off-by: O
On Fri, Jul 11, 2014 at 11:18 AM, Ezequiel Garcia
wrote:
> In order to support the "enable GPIO" available in many panel devices,
> this commit adds a proper devicetree binding.
>
> By providing an enable GPIO in the devicetree, the driver can now turn
> off and on the panel device, and/or the bac
On Fri, Jul 11, 2014 at 11:47 AM, Boris BREZILLON
wrote:
> On Fri, 11 Jul 2014 11:41:12 -0400
> Rob Clark wrote:
>
>> On Fri, Jul 11, 2014 at 11:17 AM, Boris BREZILLON
>> wrote:
>> > Make use of lists instead of kfifo in order to dynamically allocate
>> > task entry when someone require some del
On Fri, Jul 11, 2014 at 12:50:02AM +0300, Oded Gabbay wrote:
> To support HSA on KV, we need to limit the number of vmids and pipes
> that are available for radeon's use with KV.
>
> This patch reserves VMIDs 8-15 for KFD (so radeon can only use VMIDs
> 0-7) and also makes radeon thinks that KV ha
On Fri, Jul 11, 2014 at 11:49 AM, Alexandre Courbot
wrote:
> On 07/10/2014 06:43 PM, Peter De Schrijver wrote:
>>
>> On Thu, Jul 10, 2014 at 09:34:34AM +0200, Alexandre Courbot wrote:
>>>
>>> This series adds support for reclocking on GK20A. The first two patches
>>> touch
>>> the clock subsystem
On 07/11/2014 11:50 AM, Ben Skeggs wrote:
> On Fri, Jul 11, 2014 at 12:35 PM, Alexandre Courbot
> wrote:
>> On 07/10/2014 09:58 PM, Daniel Vetter wrote:
>>>
>>> On Tue, Jul 08, 2014 at 05:25:57PM +0900, Alexandre Courbot wrote:
page_to_phys() is not the correct way to obtain the DMA add
Am Freitag, den 11.07.2014, 11:57 +0900 schrieb Alexandre Courbot:
[...]
> >> Yeah, I am not familiar with i915 but it seems like we are on a similar
> >> boat
> >> here (excepted ARM is more constrained as to its memory mappings). The
> >> strategy in this series is, map buffers used by user-spac
On Fri, Jul 11, 2014 at 12:14:25AM +0200, Thomas Hellstr?m wrote:
>
> I agree, however that readability may be more important than the
> fastpath execution speed gained from this. But in my case not so
> much that I spontaneously feel like removing all branch prediction
> hints from the vmwgfx dri
On Fri, Jul 11, 2014 at 12:47:26AM +0300, Oded Gabbay wrote:
> This patch enables the KFD to retrieve the kfd_process
> object from the process's mm_struct. This is needed because kfd_process
> lifespan is bound to the process's mm_struct lifespan.
>
> When KFD is notified about an mm_struct tear-
On Fri, Jul 11, 2014 at 11:17 AM, Boris BREZILLON
wrote:
> Make use of lists instead of kfifo in order to dynamically allocate
> task entry when someone require some delayed work, and thus preventing
> drm_flip_work_queue from directly calling func instead of queuing this
> call.
> This allow drm_
On 07/10/2014 10:04 PM, Daniel Vetter wrote:
> On Tue, Jul 08, 2014 at 05:25:59PM +0900, Alexandre Courbot wrote:
>> On architectures for which access to GPU memory is non-coherent,
>> caches need to be flushed and invalidated explicitly when BO control
>> changes between CPU and GPU.
>>
>> This pa
On 07/10/2014 09:58 PM, Daniel Vetter wrote:
> On Tue, Jul 08, 2014 at 05:25:57PM +0900, Alexandre Courbot wrote:
>> page_to_phys() is not the correct way to obtain the DMA address of a
>> buffer on a non-PCI system. Use the DMA API functions for this, which
>> are portable and will allow us to use
In order to support the "enable GPIO" available in many panel devices,
this commit adds a proper devicetree binding.
By providing an enable GPIO in the devicetree, the driver can now turn
off and on the panel device, and/or the backlight device. Both the
backlight and the GPIO are optional propert
Instead of setting an initial value for the return code, set it explicitly
on each error path. This is just a cosmetic cleanup, as preparation for the
enable GPIO support.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 4 +++-
1 file changed, 3 insertions(+), 1 deleti
The current backlight support is broken; the driver expects a backlight-class
in the panel devicetree node. Fix this by implementing it properly, getting
an optional backlight from a phandle.
This shouldn't cause any backward-compatibility DT issue because the current
implementation doesn't work a
Using the managed variant to allocate the resource makes the code simpler
and less error-prone.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm
Just a cosmetic cleanup.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 8f88bfd..4b36e68 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_pa
Just a trivial cleanup to remove the variable.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index d581c53..8f88bfd 100644
--- a/drivers/
This commit adds the missing calls to of_node_put to release the node
that's currently held by the of_get_child_by_name() call in the panel
info parsing code.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/g
The current error path calls tilcdc_unload() in case of an error to release
the resources. However, this is wrong because not all resources have been
allocated by the time an error occurs in tilcdc_load().
To fix it, this commit adds proper labels to bail out at the different
stages in the load fu
Hello all,
This patchset adds the required changes to support an optional backlight
and GPIO for the tilcdc panel driver.
There was some code to support a backlight, but it was somewhat broken
and undocumented. I've followed the nice implementation in panel-simple
and added a similar one here.
T
On Thu, Jul 10, 2014 at 5:34 PM, Alexandre Courbot
wrote:
> This series adds support for reclocking on GK20A. The first two patches touch
> the clock subsystem to allow GK20A to operate, by making the presence of the
> thermal and voltage devices optional, and allowing pstates to be provided
> di
On 07/10/2014 06:43 PM, Peter De Schrijver wrote:
> On Thu, Jul 10, 2014 at 09:34:34AM +0200, Alexandre Courbot wrote:
>> This series adds support for reclocking on GK20A. The first two patches touch
>> the clock subsystem to allow GK20A to operate, by making the presence of the
>> thermal and volt
On 07/10/2014 06:50 PM, Mikko Perttunen wrote:
> Does GK20A itself have any kind of thermal protection capabilities?
> Upstream SOCTHERM support is not yet available (though I have a driver
> in my tree), so we are thinking of disabling CPU DVFS on boards that
> don't have always-on active cooling
On Fri, Jul 11, 2014 at 12:53:54AM +0300, Oded Gabbay wrote:
> This patch creates a workaround for a bug in amd_iommu driver, where
> the driver doesn't save all necessary information when going to
> suspend. The workaround removes a device from the IOMMU device list
> on suspend and register a re
Hi Ben,
On 07/11/2014 10:07 AM, Ben Skeggs wrote:
> On Thu, Jul 10, 2014 at 5:34 PM, Alexandre Courbot
> wrote:
>> This series adds support for reclocking on GK20A. The first two patches touch
>> the clock subsystem to allow GK20A to operate, by making the presence of the
>> thermal and voltage
On Fri, 2014-07-11 at 13:04 -0400, Jerome Glisse wrote:
> On Fri, Jul 11, 2014 at 12:50:09AM +0300, Oded Gabbay wrote:
[]
> > +static long kfd_ioctl(struct file *, unsigned int, unsigned long);
>
> Nitpick, avoid unsigned int just use unsigned.
I suggest unsigned int is much more common (and bett
On Fri, Jul 11, 2014 at 9:56 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> This patch adds an IOCTL for turning a pointer supplied by
> userspace into a buffer object.
>
> It imposes several restrictions upon the memory being mapped:
>
> 1. It must be page aligned (both start/end address
On Fri, Jul 11, 2014 at 9:56 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> v2: use flag instead of boolean
> v3: keep R600_PTE_GART as it is
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/r100.c| 2 +-
> drivers/gpu/drm/radeon/r300.c| 8 ++--
>
On 11/07/2014 03:42, Alexandre Courbot wrote:
> On 07/10/2014 06:50 PM, Mikko Perttunen wrote:
>> Does GK20A itself have any kind of thermal protection capabilities?
>> Upstream SOCTHERM support is not yet available (though I have a driver
>> in my tree), so we are thinking of disabling CPU DVFS on
On Fri, Jul 11, 2014 at 11:40:27AM +0900, Alexandre Courbot wrote:
> On 07/10/2014 10:04 PM, Daniel Vetter wrote:
> >On Tue, Jul 08, 2014 at 05:25:59PM +0900, Alexandre Courbot wrote:
> >>On architectures for which access to GPU memory is non-coherent,
> >>caches need to be flushed and invalidated
On Fri, Jul 11, 2014 at 11:35:23AM +0900, Alexandre Courbot wrote:
> On 07/10/2014 09:58 PM, Daniel Vetter wrote:
> >On Tue, Jul 08, 2014 at 05:25:57PM +0900, Alexandre Courbot wrote:
> >>page_to_phys() is not the correct way to obtain the DMA address of a
> >>buffer on a non-PCI system. Use the DM
On Thu, Jul 10, 2014 at 09:08:24PM +, Tian, Kevin wrote:
> actually I'm curious whether it's still necessary to __detect__ PCH. Could
> we assume a 1:1 mapping between GPU and PCH, e.g. BDW already hard
> code the knowledge:
>
> } else if (IS_BROADWELL(dev)) {
>
With the advent of universal drm planes and the introduction of generic
plane properties for rotations, we can query and program the hardware
for native rotation support.
NOTE: this depends upon the next release of libdrm to remove one
opencoded define.
v2: Use enum to determine primary plane, su
Hi Linus,
Nothing too scary, we have one outstanding i915 regression but Daniel has
promised the fix as soon as he's finished testing it a bit.
Fixes for the main x86 drivers:
radeon: dpm fixes, displayport regression fix
i915: quirks for backlight regression, edp reboot fix, valleyview black
This version is intended for upstreaming to the Linux kernel 3.17
Signed-off-by: Oded Gabbay
---
drivers/gpu/hsa/radeon/kfd_module.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/hsa/radeon/kfd_module.c
b/drivers/gpu/hsa/radeon/kfd_module.c
index c706236..c
1 - 100 of 185 matches
Mail list logo
