On Fri, Jul 18, 2014 at 5:19 AM, Michel D?nzer wrote:
> On 17.07.2014 21:00, Marek Ol??k wrote:
>> On Thu, Jul 17, 2014 at 12:01 PM, Michel D?nzer
>> wrote:
>>> From: Michel D?nzer
>>>
>>> This is hopefully safe: The kernel makes sure writes to these mappings
>>> finish before the GPU might sta
GL_MAP_READ_BIT is always unconditionally set for glBufferData, which
is the most-used function. However, st/mesa can look at the
immutability flag to distinguish between BufferData and BufferStorage
before pipe_buffer_create is called, and set the read flag if the
caller is BufferStorage and GL_MA
're the co-author on this file; nice to meet you!
--
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/20140718/6464c28e/attachment.html>
Add MODULE_DEVICE_TABLE calls for the various OF match tables that
currently don't have one. This allows the module to be
autoloaded based on devicetree information.
Signed-off-by: Sjoerd Simons
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c| 1 +
drivers/gpu/drm/exynos/exynos_drm_rotator.c |
This reverts commit d089621896c3530a9bd309f96e9c9124d07f6c3f was
original to prevent multiple MODULE_DEVICE_TABLE in one module.
Which, as a side-effect broke autoloading of the module.
Since 21bdd17b21b45ea48e06e23918d681afbe0622e9 it is possible to have
multiple calls to MODULE_DEVICE_TABLE, so
This reverts commit de1d3677017a1d58419722b60564cb56bd9462c3, which was
original added to fix build errors when building exynosdrm as a single
module caused by multiple MODULE_DEVICE_TABLE in one module. Which, as
a side-effect broke autoloading of the module.
Since 21bdd17b21b45ea48e06e23918d681a
The exynos DRM module currently is not automatically loaded when build as a
module. This is due to the simple fact that it doesn't have any
MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed previously
as it wasn't possible at the time to have multiple calls to MODULE_DEVICE_TABLE
(default
> depending on vm_size)");
> module_param_named(vm_block_size, radeon_vm_block_size, int, 0444);
>
> MODULE_PARM_DESC(deep_color, "Deep Color support (1 = enable, 0 = disable
> (default))");
>
------ next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140718/e4422250/attachment.sig>
read from
> there by the same mesa - is that expected?
This is weird. It should have been installed in /etc.
--
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
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/20140718/6a01b674/attachment.html>
iast |Mesa and X developer
> ___
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140718/25c84a2b/attachment.sig>
This patch adds LPM transfer support for video or command data.
With this patch, Exynos MIPI DSI controller can transfer command or
video data with HS or LP mode in accordance with mode_flags set
by LCD Panel driver.
Signed-off-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/ex
This patch adds below two flags for LPM transfer, and it attaches LPM flags
to a msg in accordance with master's mode_flags set by LCD Panel driver.
MIPI_DSI_MODE_CMD_LPM: low power command transfer
MIPI_DSI_MODE_VIDEO_LPM: low power video transfer
MIPI DSI spec says,
"the host processor con
This patch series adds LPM tranfer support for video and command data.
For this, this patch adds two flags, and makes MIPI DSI host to send
commands to LCD Panel device with LPM if mode_flags of LCD Panel driver
includes LPM flag.
And also it applies this feature to Exynos MIPI DSI driver.
Inki
On Fri, Jul 18, 2014 at 5:47 PM, 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 change since I still don't understand
>>> the reason why it's faster than with GT
On 18.07.2014 12:58, Dieter N?tzel wrote:
> Am 18.07.2014 05:07, schrieb Michel D?nzer:
>> On 17.07.2014 19:09, Christian K?nig wrote:
>>> Am 17.07.2014 12:01, schrieb Michel D?nzer:
[PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on >= SI
>>>
>>> I'm still not very keen with this change
On 18.07.2014 15:56, Christian K?nig wrote:
> From: Christian K?nig
>
> v3: completely rewritten. We now just remember which areas
> of the PT to clear and do so on the next command submission.
>
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=79980
>
> Signed-off-by: Christian K?nig
Hi Dave,
Just flushing out my random drm patches queue. Nothing fancy in here at
all.
Cheers, Daniel
The following changes since commit b957f457fbce30cc4901dc28f2b56f2b15dfe84a:
drm/radeon: use helpers (2014-07-18 14:25:23 +1000)
are available in the git repository at:
git://anongit.free
Hi Dave,
drm-intel-next-2014-07-11:
- fbc improvements when stolen memory is tight (Ben)
- cdclk handling improvements for vlv/chv (Ville)
- proper fix for stuck primary planes on gmch platforms with cxsr (Imre&Ebgert
Eich)
- gen8 hw semaphore support (Ben)
- more execlist prep work from Oscar M
Hi Dave,
Oops, missed the -fixes train. But in any case nothing really shocking in
here, 2 reverts, 1 quirk and a regression fix a WARN.
Cheers, Daniel
The following changes since commit 1795cd9b3a91d4b5473c97f491d63892442212ab:
Linux 3.16-rc5 (2014-07-13 14:04:33 -0700)
are available in th
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 change since I still don't understand
>> the reason why it's faster than with GTT. Definitely needs more testing
>> on a wider range of systems.
> Sure
On Fri, 18 Jul 2014 16:51:52 +0200
Boris BREZILLON wrote:
> Hi Thierry,
>
> Oops, I missed this reply.
>
> On Tue, 15 Jul 2014 12:31:37 +0200
> Thierry Reding wrote:
>
> > On Tue, Jul 15, 2014 at 12:06:19PM +0200, Boris BREZILLON wrote:
> > > On Mon, 14 Jul 2014 12:05:43 +0200 Thierry Reding
On Thu, Jul 3, 2014 at 5:33 PM, Sachin Kamat
wrote:
> From: Sachin Kamat
>
> Makes the code a bit more readable.
>
> Signed-off-by: Sachin Kamat
> Signed-off-by: Sachin Kamat
> Acked-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_gem_cma_helper.c |2 +-
> 1 file changed, 1 insertion(+)
We should prefer `const struct pci_device_id` over
`DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines.
This issue was reported by checkpatch.
A simplified version of the semantic patch that makes this change is as
follows (http://coccinelle.lip6.fr/):
//
@@
identifier i;
declarer
Hi Thierry,
Oops, I missed this reply.
On Tue, 15 Jul 2014 12:31:37 +0200
Thierry Reding wrote:
> On Tue, Jul 15, 2014 at 12:06:19PM +0200, Boris BREZILLON wrote:
> > On Mon, 14 Jul 2014 12:05:43 +0200 Thierry Reding > gmail.com> wrote:
> > > On Mon, Jul 07, 2014 at 06:42:59PM +0200, Boris BRE
On Fri, 2014-07-18 at 09:28 -0700, James Bottomley wrote:
> On Fri, 2014-07-18 at 17:26 +0200, Benoit Taine wrote:
> > We should prefer `const struct pci_device_id` over
> > `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines.
> > This issue was reported by checkpatch.
>
> What kernel
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #36 from Alex Deucher ---
Created attachment 143411
--> https://bugzilla.kernel.org/attachment.cgi?id=143411&action=edit
disable runpm by default on problematic systems
This patch disables runpm by default on the Asus K73TA laptop s
https://bugzilla.kernel.org/show_bug.cgi?id=74551
--- Comment #19 from Alex Deucher ---
Created attachment 143401
--> https://bugzilla.kernel.org/attachment.cgi?id=143401&action=edit
disable runpm by default on problematic systems
The attached patch will disable runpm by default on problematic
On Fri, Jul 18, 2014 at 5:38 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Signed-off-by: Christian K?nig
Applied to my 3.17 tree.
Thanks,
Alex
> ---
> drivers/gpu/drm/radeon/radeon_device.c | 6 +-
> drivers/gpu/drm/radeon/radeon_drv.c| 4 ++--
> 2 files changed, 7 inserti
On Thu, Jul 17, 2014 at 11:29:55PM -0400, Rob Clark wrote:
> Slightly overdue, but retrofit recently added helpers to drivers.
> Note that there are a couple places left in core, but they get
> replaced in the atomic series and I didn't feel like making extra
> conflicts for myself.
>
> Rob Clark
On Thu, Jul 17, 2014 at 11:25:18AM -0400, Sean Paul wrote:
> drm_select_eld should check for mode_config.connection_mutex as
> well as mode_config.mutex
>
> Signed-off-by: Sean Paul
Indeed. Although the commit message is a bit thin, it should explain why
we need the connection mutex, too. Pimped
https://bugzilla.kernel.org/show_bug.cgi?id=74551
--- Comment #18 from maxis11 ---
(In reply to Alex Deucher from comment #17)
> (In reply to maxis11 from comment #16)
> >
> > So it seems that this is Acer BIOS problem freezes laptop, when trying to
> > turn off dGPU. Am I right?
>
>
> Either
On Sat, Jul 19, 2014 at 07:14:12AM +1000, Dave Airlie wrote:
> >
> > We have almost 1000 more uses of the non-macro version than the "macro"
> > version in the kernel today:
> > $ git grep -w DEFINE_PCI_DEVICE_TABLE | wc -l
> > 262
> > $ git grep "const struct pci_device_id" | wc -l
> > 1254
>
> d
From: Christian K?nig
VM sizes smaller than 1GB doesn't make much sense anyway.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_device.c | 14 +++---
drivers/gpu/drm/radeon/radeon_drv.c| 4 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/driver
From: Christian K?nig
Calling radeon_vm_bo_find on the IB BO during CS
is illegal and can lead to an crash.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 2 ++
drivers/gpu/drm/radeon/radeon_cs.c | 6 +++---
drivers/gpu/drm/radeon/radeon_kms.c | 26 +---
If the requirements of GL_MAP_COHERENT_BIT are satisfied, then the
patch is okay.
Marek
On Fri, Jul 18, 2014 at 5:19 AM, Michel D?nzer wrote:
> On 17.07.2014 21:00, Marek Ol??k wrote:
>> On Thu, Jul 17, 2014 at 12:01 PM, Michel D?nzer
>> wrote:
>>> From: Michel D?nzer
>>>
>>> This is hopeful
https://bugzilla.kernel.org/show_bug.cgi?id=74551
--- Comment #17 from Alex Deucher ---
(In reply to maxis11 from comment #16)
>
> So it seems that this is Acer BIOS problem freezes laptop, when trying to
> turn off dGPU. Am I right?
Either that or it requires some special system specific hand
cause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140718/374b8002/attachment.html>
d(hard_reset, radeon_hard_reset, int, 0444);
>>
>> -MODULE_PARM_DESC(vm_size, "VM address space size in megabytes (default
>> 4GB)");
>> +MODULE_PARM_DESC(vm_size, "VM address space size in gigabytes (default
>> 4GB)");
>> module_param_named(vm_size, radeon_vm_size, int, 0444);
>>
>> MODULE_PARM_DESC(vm_block_size, "VM page table size in bits (default 9)");
>> --
>> 1.9.1
>>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-let-s-use-GB-for-vm_size-v2.patch
Type: text/x-diff
Size: 3854 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140718/81af6caa/attachment.patch>
Am 18.07.2014 11:44, schrieb Michel D?nzer:
> On 18.07.2014 15:56, Christian K?nig wrote:
>> From: Christian K?nig
>>
>> v3: completely rewritten. We now just remember which areas
>> of the PT to clear and do so on the next command submission.
>>
>> Bug: https://bugs.freedesktop.org/show_bug.
On Fri, Jul 18, 2014 at 7:48 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Calling radeon_vm_bo_find on the IB BO during CS
> is illegal and can lead to an crash.
>
> Signed-off-by: Christian K?nig
Applied to my 3.16 tree.
Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon.h |
On Fri, Jul 18, 2014 at 2:56 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> v3: completely rewritten. We now just remember which areas
> of the PT to clear and do so on the next command submission.
>
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=79980
>
> Signed-off-by: Christia
On 18.07.2014 12:26, Alex Deucher wrote:
> On Thu, Jul 17, 2014 at 8:41 PM, Michel D?nzer wrote:
>> On 18.07.2014 01:29, Alex Deucher wrote:
>>> @@ -55,10 +55,13 @@ int radeon_gem_object_create(struct radeon_device
>>> *rdev, int size,
>>> alignment = PAGE_SIZE;
>>> }
>>>
>>>
On Fri, Jul 18, 2014 at 05:26:47PM +0200, Benoit Taine wrote:
> We should prefer `const struct pci_device_id` over
> `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines.
> This issue was reported by checkpatch.
Honestly, I prefer the macro -- it stands-out more. Maybe the style
guide
On 17.07.2014 21:00, Marek Ol??k wrote:
> On Thu, Jul 17, 2014 at 12:01 PM, Michel D?nzer wrote:
>> From: Michel D?nzer
>>
>> This is hopefully safe: The kernel makes sure writes to these mappings
>> finish before the GPU might start reading from them, and the GPU caches
>> are invalidated at the
Hi Thierry,
Thanks for your comments.
On Fri, Jul 18, 2014 at 4:18 AM, Thierry Reding
wrote:
> On Fri, Jul 18, 2014 at 02:20:39AM +0530, Ajay kumar wrote:
>> +devicetree at vger.kernel.org
>>
>> On Fri, Jul 18, 2014 at 2:13 AM, Ajay Kumar
>> wrote:
>> > Add DT binding documentation for panel-l
On Fri, Jul 18, 2014 at 7:56 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> VM sizes smaller than 1GB doesn't make much sense anyway.
>
> Signed-off-by: Christian K?nig
Applied to my 3.16 tree.
Alex
> ---
> drivers/gpu/drm/radeon/radeon_device.c | 14 +++---
> drivers/gpu/drm
On 17.07.2014 19:09, Christian K?nig wrote:
> Am 17.07.2014 12:01, schrieb Michel D?nzer:
>> In order to try and improve X(Shm)PutImage performance with glamor, I
>> implemented support for write-combined CPU mappings of BOs in GTT.
>>
>> This did provide a nice speedup, but to my surprise, using V
On Fri, 2014-07-18 at 11:17 -0700, Greg KH wrote:
> On Fri, Jul 18, 2014 at 09:54:32AM -0700, James Bottomley wrote:
> > On Fri, 2014-07-18 at 09:43 -0700, Greg KH wrote:
> > > On Fri, Jul 18, 2014 at 12:22:13PM -0400, John W. Linville wrote:
> > > > On Fri, Jul 18, 2014 at 05:26:47PM +0200, Benoit
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_device.c | 6 +-
drivers/gpu/drm/radeon/radeon_drv.c| 4 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_dev
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140718/73baaae4/attachment.html>
On Fri, Jul 18, 2014 at 09:54:32AM -0700, James Bottomley wrote:
> On Fri, 2014-07-18 at 09:43 -0700, Greg KH wrote:
> > On Fri, Jul 18, 2014 at 12:22:13PM -0400, John W. Linville wrote:
> > > On Fri, Jul 18, 2014 at 05:26:47PM +0200, Benoit Taine wrote:
> > > > We should prefer `const struct pci_d
Now that fallback to gtt is fixed for cpu access, we can
remove this limit.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=78717
v2: use new gart_pin_size to accurately track available gtt.
v3: fix comment
Signed-off-by: Alex Deucher
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/radeon/
Gives more accurate count and prevents failures when we can't
allocate memory for the tests.
Signed-off-by: Alex Deucher
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_test.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon
Gives a more accurate limit than the previous code.
Signed-off-by: Alex Deucher
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gem.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/rade
So we know how large an allocation we can allow.
v2: incorporate Michel's comments
Signed-off-by: Alex Deucher
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h| 4
drivers/gpu/drm/radeon/radeon_object.c | 16 +---
2 files changed, 17 insertions(+), 3 d
On Fri, 2014-07-18 at 09:43 -0700, Greg KH wrote:
> On Fri, Jul 18, 2014 at 12:22:13PM -0400, John W. Linville wrote:
> > On Fri, Jul 18, 2014 at 05:26:47PM +0200, Benoit Taine wrote:
> > > We should prefer `const struct pci_device_id` over
> > > `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding styl
Hi Thierry,
On 07/17/2014 07:38 PM, Thierry Reding wrote:
> On Thu, Jul 17, 2014 at 06:01:24PM +0900, YoungJun Cho wrote:
>> This patch adds DT bindings for s6e3fa0 panel.
>> The bindings describes panel resources and display timings.
>
> The commit message here should preferably say which platfor
Hi Thierry,
Thank you a lot for kind comments.
On 07/17/2014 07:36 PM, Thierry Reding wrote:
> On Thu, Jul 17, 2014 at 06:01:25PM +0900, YoungJun Cho wrote:
> [...]
>> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
>> b/drivers/gpu/drm/panel/panel-s6e3fa0.c
> [...]
>> +/* Manufacturer Comman
From: Christian K?nig
Scales much better than scanning the address range linearly.
v2: store pfn instead of address
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/radeon/radeon.h | 7 ++-
drivers/gpu/drm/radeon/radeon_gem.c | 4 +-
d
On Thu, Jul 17, 2014 at 11:29 PM, Rob Clark wrote:
> Slightly overdue, but retrofit recently added helpers to drivers.
> Note that there are a couple places left in core, but they get
> replaced in the atomic series and I didn't feel like making extra
> conflicts for myself.
>
> Rob Clark (10):
>
rchives/dri-devel/attachments/20140718/266e6a18/attachment.html>
On Fri, 2014-07-18 at 09:43 -0700, Greg KH wrote:
> On Fri, Jul 18, 2014 at 12:22:13PM -0400, John W. Linville wrote:
> > On Fri, Jul 18, 2014 at 05:26:47PM +0200, Benoit Taine wrote:
> > > We should prefer `const struct pci_device_id` over
> > > `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding styl
On Fri, Jul 18, 2014 at 12:22:13PM -0400, John W. Linville wrote:
> On Fri, Jul 18, 2014 at 05:26:47PM +0200, Benoit Taine wrote:
> > We should prefer `const struct pci_device_id` over
> > `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines.
> > This issue was reported by checkpatch.
>
On 18.07.2014 01:29, Alex Deucher wrote:
> @@ -55,10 +55,13 @@ int radeon_gem_object_create(struct radeon_device *rdev,
> int size,
> alignment = PAGE_SIZE;
> }
>
> - /* maximun bo size is the minimun btw visible vram and gtt size */
> - max_size = min(rdev->mc.visibl
On Fri, 2014-07-18 at 17:26 +0200, Benoit Taine wrote:
> We should prefer `const struct pci_device_id` over
> `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines.
> This issue was reported by checkpatch.
What kernel coding style? checkpatch isn't the arbiter of style, if
that's the o
From: Christian K?nig
Let's try to fix bugs related to this instead of just disabling it.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_vm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
b/drivers/gpu/drm/radeon/rad
From: Christian K?nig
Scales much better than scanning the address range linearly.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/radeon/radeon.h | 7 ++-
drivers/gpu/drm/radeon/radeon_gem.c | 4 +-
drivers/gpu/drm/radeon/radeon_trace
From: Christian K?nig
Won't work anyway, instead WARN_ON if the VA list isn't
empty when we free the BO.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_object.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_obje
From: Christian K?nig
Don't wait for the BO to be used again, just
update the PT on the next VM use.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h| 7 +-
drivers/gpu/drm/radeon/radeon_cs.c | 3 ++-
drivers/gpu/drm/radeon/radeon_vm.c | 51 +
From: Christian K?nig
v3: completely rewritten. We now just remember which areas
of the PT to clear and do so on the next command submission.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=79980
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h| 13 --
drivers/
Am 18.07.2014 05:07, schrieb Michel D?nzer:
> On 17.07.2014 19:09, Christian K?nig wrote:
>> Am 17.07.2014 12:01, schrieb Michel D?nzer:
>>> In order to try and improve X(Shm)PutImage performance with glamor, I
>>> implemented support for write-combined CPU mappings of BOs in GTT.
>>>
>>> This did
https://bugzilla.kernel.org/show_bug.cgi?id=74551
--- Comment #16 from maxis11 ---
(In reply to Alex Deucher from comment #15)
> (In reply to maxis11 from comment #13)
> > (In reply to Alex Deucher from comment #12)
> > > (In reply to maxis11 from comment #6)
> > > > BTW runpm works with 3.12.7 a
Hi Linus,
one nouveau deadlock fix, one qxl irq handling fix,
and a set of radeon pageflipping changes that fix regressions in
pageflipping since -rc1 along with a leak and backlight fix.
the pageflipping fixes are a bit bigger than I'd like, but
there has been a few people focused on testing t
type||
--
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/20140718/155c2da2/attachment.html>
ng 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/20140718/da05695d/attachment.html>
in the background, but clicking on a facebook chat, it just lost it. So,
there it is.
--
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/attachment
Am 17.07.2014 22:50, schrieb Alex Deucher:
> Hi Dave,
>
> A few more fixes for 3.16. The pageflipping fixes I dropped last week
> have finally shaped up so this is mostly fixes for fallout from the
> pageflipping code changes. Also fix a memory leak and a black screen
> when restoring the backli
+devicetree at vger.kernel.org
On Fri, Jul 18, 2014 at 2:13 AM, Ajay Kumar wrote:
> From: Vincent Palatin
>
> Add DT binding documentation for ps8622/ps8625 bridge driver.
>
> Signed-off-by: Vincent Palatin
> Signed-off-by: Ajay Kumar
> ---
> .../devicetree/bindings/drm/bridge/ps8622.txt
+devicetree at vger.kernel.org
On Fri, Jul 18, 2014 at 2:13 AM, Ajay Kumar wrote:
> Add DT binding documentation for panel-lvds driver.
>
> Signed-off-by: Ajay Kumar
> ---
> .../devicetree/bindings/panel/panel-lvds.txt | 50
>
> 1 file changed, 50 insertions(+)
>
From: Rahul Sharma
This patch adds ps8622 lvds bridge discovery code to the dp driver.
Signed-off-by: Rahul Sharma
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/exynos/exynos_dp_core.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drive
From: Vincent Palatin
Add DT binding documentation for ps8622/ps8625 bridge driver.
Signed-off-by: Vincent Palatin
Signed-off-by: Ajay Kumar
---
.../devicetree/bindings/drm/bridge/ps8622.txt | 21
1 file changed, 21 insertions(+)
create mode 100644 Documentation/d
From: Vincent Palatin
This patch adds drm_bridge driver for parade DisplayPort
to LVDS bridge chip.
Signed-off-by: Vincent Palatin
Signed-off-by: Andrew Bresticker
Signed-off-by: Sean Paul
Signed-off-by: Rahul Sharma
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/bridge/Kconfig |8 +
d
exynos_dp supports a simple bridge chain with ptn3460 bridge
and an LVDS panel attached to it.
This patch creates the bridge chain with ptn3460 as the head
of the list and panel_binder being the tail.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 12 +++-
1 fi
Modify the driver to invoke callbacks for the next bridge
in the bridge chain.
Also, remove the drm_connector implementation from ptn3460,
since the same is implemented using panel_binder.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/bridge/ptn3460.c| 137 +-
Add a dummy bridge which binds all of the drm_bridge callbacks
to corresponding drm_panel callbacks.
In theory, this is just a glue layer for the last bridge and
the panel attached to it.
This driver also implements the required drm_connector ops
for the encoder(on which the entire bridge chain i
Add helper functions to create bridge chain and to call the
corresponding next_bridge functions.
Signed-off-by: Ajay Kumar
Suggested-by: Rob Clark
---
include/drm/drm_crtc.h | 72
1 file changed, 72 insertions(+)
diff --git a/include/drm/drm_c
Add DT binding documentation for panel-lvds driver.
Signed-off-by: Ajay Kumar
---
.../devicetree/bindings/panel/panel-lvds.txt | 50
1 file changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
diff --git a/Documentatio
This patch adds a simple driver to handle all the LCD and LED
powerup/down routines needed to support eDP/LVDS panels.
The LCD and LED units are usually powered up via regulators,
and almost on all boards, we will have a BACKLIGHT_EN pin to
enable/ disable the backlight.
Sometimes, we can have LCD
Add drm_panel controls to support powerup/down of the
eDP panel, if one is present at the sink side.
Signed-off-by: Ajay Kumar
---
.../devicetree/bindings/video/exynos_dp.txt|2 +
drivers/gpu/drm/exynos/Kconfig |1 +
drivers/gpu/drm/exynos/exynos_dp_core.c
Most of the panels need an init sequence as mentioned below:
-- poweron LCD unit/LCD_EN
-- start video data
-- poweron LED unit/BACKLIGHT_EN
And, a de-init sequence as mentioned below:
-- poweroff LED unit/BACKLIGHT_EN
-- stop video data
-- poweroff L
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 just few ms before
calling enable_irq in dp_poweron.
This patch removes that stringent time constraint.
Signed-off-by: Ajay Kum
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
This patchset also consolidates various inputs from the drm community
regarding the bridge chaining concept:
(1) [RFC V2 0/3] drm/bridge: panel and chaining
https://bugzilla.kernel.org/show_bug.cgi?id=74551
--- Comment #15 from Alex Deucher ---
(In reply to maxis11 from comment #13)
> (In reply to Alex Deucher from comment #12)
> > (In reply to maxis11 from comment #6)
> > > BTW runpm works with 3.12.7 and 3.12.8 (with 3.13 and later runpm=1
> > > f
https://bugzilla.kernel.org/show_bug.cgi?id=80551
Bug ID: 80551
Summary: Second video card failed to initialize with message
'Invalid ROM contents'
Product: Drivers
Version: 2.5
Kernel Version: 3.14-1-amd64
Hardware: IA
per board, so
they shouldn't go into the device tree at all.
> > + -panel-width-mm: physical panel width [mm]
> > + -panel-height-mm: physical panel height [mm]
Same here.
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/20140718/d0bc7872/attachment.sig>
96 matches
Mail list logo
