2013/6/22 Jerome Glisse j.gli...@gmail.com:
On Fri, Jun 21, 2013 at 12:55 PM, Inki Dae daei...@gmail.com wrote:
2013/6/21 Lucas Stach l.st...@pengutronix.de:
Hi Inki,
please refrain from sending HTML Mails, it makes proper quoting without
messing up the layout everywhere pretty hard.
On Tue, Jun 18, 2013 at 12:46 PM, Russell King - ARM Linux
li...@arm.linux.org.uk 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
On Tue, Jun 25, 2013 at 3:09 AM, Dave Airlie airl...@gmail.com wrote:
On Sun, Jun 16, 2013 at 6:41 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
This has originally been added in
commit a3a0544b2c84e1d7a2022b558ecf66d8c6a8dd93
Author: Dave Airlie airl...@redhat.com
Date: Mon Aug 31
On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae daei...@gmail.com 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
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 Turquettemturque...@linaro.org
Applied with
On Sun, Jun 23, 2013 at 1:38 PM, H. Peter Anvin h...@zytor.com 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
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 Fri, 21 Jun 2013 14:52:17 +0200, Philipp Zabel p.za...@pengutronix.de
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:
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
[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?
URL: http://lists.freedesktop.org/archives/dri-devel/2013-June/039787.html
contain the complete patch with
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 go
https://bugs.freedesktop.org/show_bug.cgi?id=65958
Mike Lothian m...@fireburn.co.uk changed:
What|Removed |Added
CC||m...@fireburn.co.uk
2013/6/25 Rob Clark robdcl...@gmail.com:
On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae daei...@gmail.com 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
On Tue, Jun 25, 2013 at 10:17 AM, Inki Dae daei...@gmail.com wrote:
2013/6/25 Rob Clark robdcl...@gmail.com:
On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae daei...@gmail.com wrote:
that
should be the role of kernel memory management which of course needs
synchronization btw A and B. But in no case
On Fri, Jun 21, 2013 at 3:28 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com 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
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
konrad.w...@oracle.com 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
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
environment
On Tue, Jun 25, 2013 at 6:08 PM, Matthew Garrett mj...@srcf.ucam.org 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,
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
https://bugzilla.kernel.org/show_bug.cgi?id=57381
--- Comment #19 from Harald Judt h.j...@gmx.at 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
https://bugzilla.kernel.org/show_bug.cgi?id=57381
Nigel Cunningham ni...@tuxonice.net changed:
What|Removed |Added
CC||ni...@tuxonice.net
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 this
https://bugs.freedesktop.org/show_bug.cgi?id=63520
--- Comment #22 from PJBrs pj...@floorenpj.xs4all.nl ---
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
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 disagree on
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 has no
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 Windows
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
From: YoungJun Cho yj44@samsung.com
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 yj44@samsung.com
Signed-off-by: Seung-Woo Kim
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/drm_prime.c | 32
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git
From: YoungJun Cho yj44@samsung.com
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 yj44@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
From: YoungJun Cho yj44@samsung.com
If idr_alloc() is failed, obj-name can be error value. Also
it cleans up duplicated flink processing code.
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park
From: YoungJun Cho yj44@samsung.com
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
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
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
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
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
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
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.
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
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
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
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 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
>>>
>>
>> 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 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 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
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 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
>>>
[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 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
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/20130
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
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]
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
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
>
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 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
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
https://bugzilla.kernel.org/show_bug.cgi?id=57381
Nigel Cunningham changed:
What|Removed |Added
CC||nigel at tuxonice.net
--- Comment
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
.
--
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>
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
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: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
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>
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
66 matches
Mail list logo
