Alexis
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130625/8a115e53/attachment.pgp>
on-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130625/f4ccbc33/attachment.pgp>
2013/6/25 Rob Clark :
> On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae wrote:
>>> that
>>> should be the role of kernel memory management which of course needs
>>> synchronization btw A and B. But in no case this should be done using
>>> dma-buf. dma-buf is for sharing content btw different devices not
--
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130625/345510ae/attachment.pgp>
On Tue, Jun 25, 2013 at 11:46:01PM +0200, Yves-Alexis Perez wrote:
> But if that introduce regressions, shouldn't workarounds be found then?
> Sorry if I keep repeating that but brightness keys handling in-kernel is
> quite a useful feature and losing it (because of the ?behave exactly
> like Windo
s,
--
Yves-Alexis
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130625/d78f51ec/attachment-0001.pgp>
On Tue, Jun 25, 2013 at 11:30:37PM +0200, Yves-Alexis Perez wrote:
> On mar., 2013-06-25 at 22:14 +0100, Matthew Garrett wrote:
> > Which, as we've already established, you don't - Lenovo broke it. Your
> > Thinkpad claims to have 100 available levels, and most of them don't
> > work. The kernel
On Tue, Jun 25, 2013 at 11:10:11PM +0200, Yves-Alexis Perez wrote:
> On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote:
> > I agree, we should standardise the behaviour. And the only way we can
> > standardise the behaviour is to leave it up to userspace.
> >
> It's pretty clear we disagr
On Tue, Jun 25, 2013 at 10:43:57PM +0200, Yves-Alexis Perez wrote:
> On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote:
> > Right, the kernel has special-casing to hook the backlight keys up to
> > the ACPI backlight control. This is an awful thing, because there's no
> > way to detect th
.
--
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/20130625/4d11b0ec/attachment.html>
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commits 2d05eae1c92f
("drm/i915: Propagate errors back from fb set-base") and d62cf62ad07d
("drm/i915: Quirk the pipe A quirk in the modeset state checker") from
Linus' tree and co
https://bugzilla.kernel.org/show_bug.cgi?id=57381
Nigel Cunningham changed:
What|Removed |Added
CC||nigel at tuxonice.net
--- Comment
From: YoungJun Cho
The drm_gem_mmap_obj() has to be protected with dev->struct_mutex,
but some caller functions do not. So it adds mutex lock to missing
callers and adds WARN_ON assertion whether drm_gem_mmap_obj() is
called with mutex lock or not.
Signed-off-by: YoungJun Cho
Signed-off-by: Seu
https://bugzilla.kernel.org/show_bug.cgi?id=57381
--- Comment #19 from Harald Judt 2013-06-25 19:10:07 ---
> echo disabled >
> "/sys/devices/pci:00/:00:01.0/:01:00.0/power/async"
> echo disabled >
> "/sys/devices/pci:00/:00:01.0/:01:00.1/power/async"
>
> This seems
From: YoungJun Cho
If idr_alloc() is failed, obj->name can be error value. Also
it cleans up duplicated flink processing code.
Signed-off-by: YoungJun Cho
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/drm_gem.c | 18 +++---
1 files changed, 7 ins
From: YoungJun Cho
The dma_buf_fd() can return error when it fails to prepare fd,
so the dma_buf needs to be put.
Signed-off-by: YoungJun Cho
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/drm_prime.c | 39 ---
1 files chan
Signed-off-by: Seung-Woo Kim
Signed-off-by: YoungJun Cho
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/drm_prime.c | 32
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index afff7c8
From: YoungJun Cho
When drm_prime_add_buf_handle() returns failure for an exported
dma_buf, the dma_buf was already allocated and its refcount was
increased, so it needs to be put.
Signed-off-by: YoungJun Cho
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/drm_p
During exporting dma_buf, it can fail after dma_buf is exported. In this case,
exported dma_buf should be release with putting.
Also dma_buf_fd can be failed to get fd, but failure cases are not handled.
Error handling routine is not quite clean, so I send this patch set as RFC.
Seung-Woo Kim (1)
On Tue, Jun 25, 2013 at 6:08 PM, Matthew Garrett wrote:
> On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote:
>
>> Before Linux support for acpi_osi("Windows 2012") (and when booting with
>> acpi_osi="!Windows 2012"), brightness keys were handled by the kernel
>> just fine, whether
no one is interested in the data of
>>> the buffer, why are you sharing it in the first place?
>>>
>>
>> Just used as a storage. i.e., Task A fills the buffer with "AA"
>> using CPU, And Task B fills the buffer with "BB" using DMA. They
>> don't share data of the buffer, but they share *memory region* of the
>> buffer. That would be very useful for the embedded systems with very
>> small size system memory.
>
> Just so i understand. You want to share backing memory, you don't want
> to share content ie you want to do memory management in userspace.
> This sounds wrong on so many level (not even considering the security
> implication).
>
> If Task A need memory and then can release it for Task B usage
Not true. Task A can never release memory because All task A can do is to
unreference dma buf object of sync object. And please know that user
interfaces hasn't been implemented yet, and we just have a plan for it as I
already mentioned.
> that
> should be the role of kernel memory management which of course needs
> synchronization btw A and B. But in no case this should be done using
> dma-buf. dma-buf is for sharing content btw different devices not
> sharing resources.
>
hmm, is that true? And are you sure? Then how do you think about
reservation? the reservation also uses dma-buf with same reason as long as
I know: actually, we use reservation to use dma-buf. As you may know, a
reservation object is allocated and initialized when a buffer object is
exported to a dma buf.
Thanks,
Inki Dae
>
> Also don't over complicate the vram case, just consider desktop gpu as
> using system memory directly. They can do it and they do it. Migration
> to vram is orthogonal to all this, it's an optimization so to speak.
>
> Cheers,
> Jerome
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130625/d27a3ed5/attachment-0001.html>
On Tue, Jun 25, 2013 at 06:10:35PM +0200, Daniel Vetter wrote:
> Do we have any chances to amend this mistake by (gradually) phasing
> out support for the direct keypress forwarding in ACPI? Or at least
> some plans?
We could make the default value of brightness_switch_enabled a config
variable
On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote:
> Before Linux support for acpi_osi("Windows 2012") (and when booting with
> acpi_osi="!Windows 2012"), brightness keys were handled by the kernel
> just fine, whether in console, in the display manager or in my desktop
> environme
Hi Russell,
Thanks a lot for writing the Armada DRM driver.
I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
aka PXA2128). After a bit of fighting, I have it running. Could you share your
X driver, or your methodology for testing hardware cursors? I'd like to test
your wo
On Mon, Jun 24, 2013 at 11:57:43PM +0200, Petter Reinholdtsen wrote:
> [Petter Reinholdtsen 2013-06-11]
> > Sure. This is my first try, so I hope I got it right.
>
> Does the silence mean I got the kernel patch formatting right, or that
> I should try again?
Nah, silence just means that your pat
On Tue, Jun 25, 2013 at 11:46:01PM +0200, Yves-Alexis Perez wrote:
> But if that introduce regressions, shouldn't workarounds be found then?
> Sorry if I keep repeating that but brightness keys handling in-kernel is
> quite a useful feature and losing it (because of the “behave exactly
> like Windo
On Tue, Jun 25, 2013 at 11:30:37PM +0200, Yves-Alexis Perez wrote:
> On mar., 2013-06-25 at 22:14 +0100, Matthew Garrett wrote:
> > Which, as we've already established, you don't - Lenovo broke it. Your
> > Thinkpad claims to have 100 available levels, and most of them don't
> > work. The kernel
On Tue, Jun 25, 2013 at 11:10:11PM +0200, Yves-Alexis Perez wrote:
> On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote:
> > I agree, we should standardise the behaviour. And the only way we can
> > standardise the behaviour is to leave it up to userspace.
> >
> It's pretty clear we disagr
https://bugs.freedesktop.org/show_bug.cgi?id=63520
--- Comment #22 from PJBrs ---
This fixes it!--great, thanks very much! Is this patch already in master? And
will it also go in the 9.0 / 9.1 stable branches?
Anyway, thanks very much again for your time, glad I could be of some help too.
--
Y
On Tue, Jun 25, 2013 at 10:43:57PM +0200, Yves-Alexis Perez wrote:
> On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote:
> > Right, the kernel has special-casing to hook the backlight keys up to
> > the ACPI backlight control. This is an awful thing, because there's no
> > way to detect th
https://bugzilla.kernel.org/show_bug.cgi?id=57381
Nigel Cunningham changed:
What|Removed |Added
CC||ni...@tuxonice.net
--- Comment #20
from Mike Lothian ---
I've not had another lockup since doing this
--
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/
https://bugzilla.kernel.org/show_bug.cgi?id=57381
--- Comment #19 from Harald Judt 2013-06-25 19:10:07 ---
> echo disabled >
> "/sys/devices/pci:00/:00:01.0/:01:00.0/power/async"
> echo disabled >
> "/sys/devices/pci:00/:00:01.0/:01:00.1/power/async"
>
> This seems
On Tue, Jun 25, 2013 at 3:09 AM, Dave Airlie wrote:
> On Sun, Jun 16, 2013 at 6:41 AM, Daniel Vetter
> wrote:
>> This has originally been added in
>>
>> commit a3a0544b2c84e1d7a2022b558ecf66d8c6a8dd93
>> Author: Dave Airlie
>> Date: Mon Aug 31 15:16:30 2009 +1000
>>
>> drm/kms: add explic
On Tue, Jun 18, 2013 at 12:46 PM, Russell King - ARM Linux
wrote:
>> > Note: the existing stuff does have the nice side effect of being able
>> > to pass buffers which do not have a struct page * associated with them
>> > through the dma_buf API - I think we can still preserve that by having
>> >
On Tue, Jun 25, 2013 at 11:03:01AM -0400, Jerome Glisse wrote:
> On Fri, Jun 21, 2013 at 3:28 PM, Konrad Rzeszutek Wilk
> wrote:
> > Hey,
> >
> > I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18
> > (3.9.6) I can get it to boot and work just fine with Xen. If I use v3.10-r
On Sun, Jun 16, 2013 at 6:41 AM, Daniel Vetter
wrote:
> This has originally been added in
>
> commit a3a0544b2c84e1d7a2022b558ecf66d8c6a8dd93
> Author: Dave Airlie
> Date: Mon Aug 31 15:16:30 2009 +1000
>
> drm/kms: add explicit encoder disable function and detach harder.
>
> I think it's
On Fri, Jun 21, 2013 at 3:28 PM, Konrad Rzeszutek Wilk
wrote:
> Hey,
>
> I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18
> (3.9.6) I can get it to boot and work just fine with Xen. If I use v3.10-rc6
> I found that i915 would halt with a
>
> [drm:intel_pipe_set_base] *ERR
On Tue, Jun 25, 2013 at 10:17 AM, Inki Dae wrote:
> 2013/6/25 Rob Clark :
>> On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae wrote:
that
should be the role of kernel memory management which of course needs
synchronization btw A and B. But in no case this should be done using
dma-buf
On Tue, Jun 25, 2013 at 9:18 AM, Konrad Rzeszutek Wilk
wrote:
> Dave Airlie wrote:
>
>>On Tue, Jun 25, 2013 at 4:34 AM, Konrad Rzeszutek Wilk
>> wrote:
>>> On Mon, Jun 24, 2013 at 08:26:18PM +0200, Daniel Vetter wrote:
On Mon, Jun 24, 2013 at 7:32 PM, Konrad Rzeszutek Wilk
wrote:
On Tue, Jun 25, 2013 at 06:10:35PM +0200, Daniel Vetter wrote:
> Do we have any chances to amend this mistake by (gradually) phasing
> out support for the direct keypress forwarding in ACPI? Or at least
> some plans?
We could make the default value of brightness_switch_enabled a config
variable
On Tue, Jun 25, 2013 at 6:08 PM, Matthew Garrett wrote:
> On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote:
>
>> Before Linux support for acpi_osi("Windows 2012") (and when booting with
>> acpi_osi="!Windows 2012"), brightness keys were handled by the kernel
>> just fine, whether
On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote:
> Before Linux support for acpi_osi("Windows 2012") (and when booting with
> acpi_osi="!Windows 2012"), brightness keys were handled by the kernel
> just fine, whether in console, in the display manager or in my desktop
> environme
On Tue, Jun 25, 2013 at 11:03:01AM -0400, Jerome Glisse wrote:
> On Fri, Jun 21, 2013 at 3:28 PM, Konrad Rzeszutek Wilk
> wrote:
> > Hey,
> >
> > I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18
> > (3.9.6) I can get it to boot and work just fine with Xen. If I use v3.10-r
On Fri, Jun 21, 2013 at 3:28 PM, Konrad Rzeszutek Wilk
wrote:
> Hey,
>
> I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18
> (3.9.6) I can get it to boot and work just fine with Xen. If I use v3.10-rc6
> I found that i915 would halt with a
>
> [drm:intel_pipe_set_base] *ERR
On Tue, Jun 25, 2013 at 10:17 AM, Inki Dae wrote:
> 2013/6/25 Rob Clark :
>> On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae wrote:
that
should be the role of kernel memory management which of course needs
synchronization btw A and B. But in no case this should be done using
dma-buf
On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae wrote:
>> that
>> should be the role of kernel memory management which of course needs
>> synchronization btw A and B. But in no case this should be done using
>> dma-buf. dma-buf is for sharing content btw different devices not
>> sharing resources.
>>
>
2013/6/25 Rob Clark :
> On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae wrote:
>>> that
>>> should be the role of kernel memory management which of course needs
>>> synchronization btw A and B. But in no case this should be done using
>>> dma-buf. dma-buf is for sharing content btw different devices not
On Tue, Jun 25, 2013 at 4:34 AM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Jun 24, 2013 at 08:26:18PM +0200, Daniel Vetter wrote:
>> On Mon, Jun 24, 2013 at 7:32 PM, Konrad Rzeszutek Wilk
>> wrote:
>> > On Mon, Jun 24, 2013 at 07:09:12PM +0200, Daniel Vetter wrote:
>> >> On Mon, Jun 24, 2013 at 11:4
https://bugs.freedesktop.org/show_bug.cgi?id=65958
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #3 from M
On Mon, Jun 24, 2013 at 11:57:43PM +0200, Petter Reinholdtsen wrote:
> [Petter Reinholdtsen 2013-06-11]
> > Sure. This is my first try, so I hope I got it right.
>
> Does the silence mean I got the kernel patch formatting right, or that
> I should try again?
Nah, silence just means that your pat
On 06/24/2013 03:27 PM, David Herrmann wrote:
> + sdrm->fb_map = ioremap(sdrm->fb_base, sdrm->fb_size);
This should probably be ioremap_wc. Otherwise it will be *really* slow
if used in legacy mode and it may cause conflicts with the
pgprot_writecombine mode for mmap.
(Watching boot messages
[Petter Reinholdtsen 2013-06-11]
> Sure. This is my first try, so I hope I got it right.
Does the silence mean I got the kernel patch formatting right, or that
I should try again?
http://lists.freedesktop.org/archives/dri-devel/2013-June/039787.html >
contain the complete patch with description
On 06/22/2013 03:17 PM, Rafael J. Wysocki wrote:
> On Saturday, June 22, 2013 02:11:14 PM Shuah Khan wrote:
>> Add a new interface get_pm_transition() to return pm_transition state.
>> This interface is intended to be used from dev_pm_ops class and type
>> suspend interfaces that call legacy pm ops
On Fri, 21 Jun 2013 14:52:17 +0200, Philipp Zabel
wrote:
> This depends on the patch "genirq: Generic chip: Add linear irq domain
> support"
> and removes the custom IPU irq_chip and irq_domain_ops. Instead, the generic
> irq chip implementation is reused.
>
> Signed-off-by: Philipp Zabel
Ack
BIOS Information
Vendor: Hewlett-Packard
Version: 361A0 Ver. F.11
System Information
Manufacturer: Hewlett-Packard
Product Name: HP Mini
Version: F.11
Wake-up Type: Power Switch
SKU Number: FW376UA#ABA
Family: 103C_5335KV
00:02.0 VGA
On Sun, Jun 23, 2013 at 1:38 PM, H. Peter Anvin wrote:
> On 06/23/2013 01:30 PM, Dave Airlie wrote:
> Why do you care about performance when PAT is disabled?
>>
>> breaking old boxes just because, is just going to get reverted when I
>> get the first regression report that you broke old boxes.
On 06/24/13 13:28, Rahul Sharma wrote:
[...]
I never got these patches. I'm not subscribed to devicetree-devel or
linux-samsung so I only got two replies to patch #0, but none of the
code. Can you or Rajul resend?
Sure mike.
Acked-by: Mike Turquette
Applied with Mike's ack.
Thanks,
- K
On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae wrote:
>> that
>> should be the role of kernel memory management which of course needs
>> synchronization btw A and B. But in no case this should be done using
>> dma-buf. dma-buf is for sharing content btw different devices not
>> sharing resources.
>>
>
On Tue, Jun 25, 2013 at 3:09 AM, Dave Airlie wrote:
> On Sun, Jun 16, 2013 at 6:41 AM, Daniel Vetter wrote:
>> This has originally been added in
>>
>> commit a3a0544b2c84e1d7a2022b558ecf66d8c6a8dd93
>> Author: Dave Airlie
>> Date: Mon Aug 31 15:16:30 2009 +1000
>>
>> drm/kms: add explicit
On Tue, Jun 18, 2013 at 12:46 PM, Russell King - ARM Linux
wrote:
>> > Note: the existing stuff does have the nice side effect of being able
>> > to pass buffers which do not have a struct page * associated with them
>> > through the dma_buf API - I think we can still preserve that by having
>> >
2013/6/22 Jerome Glisse :
> On Fri, Jun 21, 2013 at 12:55 PM, Inki Dae wrote:
>> 2013/6/21 Lucas Stach :
>>> Hi Inki,
>>>
>>> please refrain from sending HTML Mails, it makes proper quoting without
>>> messing up the layout everywhere pretty hard.
>>>
>>
>> Sorry about that. I should have used tex
On 06/24/13 13:28, Rahul Sharma wrote:
[...]
> I never got these patches. I'm not subscribed to devicetree-devel or
> linux-samsung so I only got two replies to patch #0, but none of the
> code. Can you or Rajul resend?
>
Sure mike.
>>>
>>> Acked-by: Mike Turquette
>>>
Use the new DRM infrastructure to kick out firmware drivers before probing
the real driver.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_d
If we load a real hardware DRM driver, we want all firmware drivers to be
unloaded. Historically, this was done via
remove_conflicting_framebuffers(), but for DRM drivers (like SimpleDRM) we
need a new way.
This patch introduces DRIVER_FIRMWARE and DRM apertures to provide a quite
similar way to k
Create a simple fbdev device during SimpleDRM setup so legacy user-space
and fbcon can use it.
fbdev deletion is quite buggy. A unregister_framebuffer() call followed by
a printk() causes NULL-derefs in hide_cursor() and other places in the VT
layer. Hence, we leak the fbdev device currently to ma
The SimpleDRM driver binds to simple-framebuffer devices and provides a
DRM/KMS API. It provides only a single CRTC+encoder+connector combination
plus one initial mode.
Userspace can create one dumb-buffer and attach it to the CRTC. Only if
the buffer is destroyed, a new buffer can be created. The
The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
x86 causes troubles when loading multiple fbdev drivers. The global
"struct screen_info" does not provide any state-tracking about which
drivers use the FBs. request_mem_region() theoretically works, but
unfortunately vesafb/
If we create proper platform-devices in x86 boot-code, we can use simplefb
for VBE or EFI framebuffers, too. However, there is normally no OF support
so we introduce a platform_data object so x86 boot-code can pass the
paramaters via plain old platform-data.
This also removes the OF dependency as
Hi
This is my second revision of the dvbe driver. I renamed it to SimpleDRM to
show the resemblence with the recently introduced simplefb.c fbdev driver. The
driver is supposed to be the most basic DRM driver similar to efifb.c, vesafb.c,
offb.c, simplefb.c, ...
It provides a single virtual CRTC+e
70 matches
Mail list logo
