On Thu, Sep 22, 2016 at 11:47 AM, Eric Engestrom
wrote:
> On Wed, Sep 21, 2016 at 04:59:19PM +0200, Tom Gundersen wrote:
>> There are many reasons other than ENOMEM that drm_dev_init() can
>> fail. Return ERR_PTR rather than NULL to be able to distinguish
>> these in the cal
On Thu, Sep 22, 2016 at 8:28 AM, Emil Velikov
wrote:
> On 21 September 2016 at 15:59, Tom Gundersen wrote:
>> If passing name == NULL to drm_drv_set_unique() we now get -ENOMEM
>> as kstrdup() returns NULL. Instead check for this explicitly and
>> return -EINVAL i
There are many reasons other than ENOMEM that drm_dev_init() can
fail. Return ERR_PTR rather than NULL to be able to distinguish
these in the caller.
Signed-off-by: Tom Gundersen
---
drivers/gpu/drm/arc/arcpgu_drv.c| 4 ++--
drivers/gpu/drm/arm/hdlcd_drv.c | 4
If passing name == NULL to drm_drv_set_unique() we now get -ENOMEM
as kstrdup() returns NULL. Instead check for this explicitly and
return -EINVAL if no name is provided.
Signed-off-by: Tom Gundersen
---
drivers/gpu/drm/drm_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers
On Fri, Sep 2, 2016 at 10:22 AM, David Herrmann
wrote:
> 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 dumb-buffers which can be blit into the
figure out
> the apertures automatically, and does VGA/VBE detection.
>
> o Generic firmware drivers that might be shadowed at any address in
> memory can use sysfb_evict_conflicts_firmware(), basically removing
> *all* firmware framebuffers in effect.
>
> This
t, drop the unused 'children_left' argument by
> of_platform_notify(). It is a left-over that somehow was never removed.
>
> Signed-off-by: David Herrmann
Reviewed-by: Tom Gundersen
> ---
> drivers/of/platform.c | 35 ++-
> include/linux/of_platfo
e x86 simple-framebuffer setup code to use the correct size in the
> non-VBE case.
>
> While at it, avoid variable abbreviations and rename 'len' to 'length',
> and use the correct types matching the screen_info definition.
>
> Signed-off-by: David Herrmann
Reviewed-by: Tom Gunder
ILITY_64BIT_BASE is set, the
> screen_info->ext_lfb_base field will contain the upper 32bit of the
> actual lfb_base. Make sure the address is not 0 (i.e., unset), as well as
> does not overflow the physical address type.
>
> Signed-off-by: David Herrmann
Reviewed-by: To
Hi David,
On Sun, Sep 1, 2013 at 3:36 PM, David Herrmann dh.herrm...@gmail.com wrote:
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
Hi David,
On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann wrote:
> Attached are two patches. The first one should fix this issue, the
> second one is the rebased ioremap_wc() patch from the other thread.
>
> Does this fix the issue (and the speed-problems)?
Sadly, no. I added a few printk's to
On Sun, Sep 8, 2013 at 2:13 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen t...@jklm.no wrote:
Hi David,
On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen t...@jklm.no wrote:
On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann dh.herrm...@gmail.com
Hi David,
On Wed, Sep 4, 2013 at 7:34 PM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Sun, Sep 1, 2013 at 3:36 PM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
With the upcoming 3.12 merge-window, I thought people might find themselves
with
nothing to do, so here's a new
On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann dh.herrm...@gmail.com wrote:
On Fri, Sep 6, 2013 at 2:10 PM, Tom Gundersen t...@jklm.no wrote:
Hi guys,
With current git (v3.11-5058-g57d7309) I get the following oops:
[5.434312] [ cut here ]
[5.434318] WARNING
Hi David,
On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen t...@jklm.no wrote:
On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann dh.herrm...@gmail.com wrote:
Attached are two patches. The first one should fix this issue, the
second one is the rebased ioremap_wc() patch from the other thread.
Does
Hi guys,
With current git (v3.11-5058-g57d7309) I get the following oops:
[5.434312] [ cut here ]
[5.434318] WARNING: CPU: 2 PID: 199 at arch/x86/mm/ioremap.c:171
__ioremap_caller+0x2e3/0x390()
[5.434321] Info: mapping multiple BARs. Your kernel is fine.
[
Hi guys,
I have been experiencing problems with suspend/resume on my ThinkPad
x60 for some time (sorry for being vague, I forget when it started).
With 3.1 it seems to behave much better (no crashes).
The problems I'm still seeing is that sometimes the computer does not
suspend when closing the
Hi guys,
I have been experiencing problems with suspend/resume on my ThinkPad
x60 for some time (sorry for being vague, I forget when it started).
With 3.1 it seems to behave much better (no crashes).
The problems I'm still seeing is that sometimes the computer does not
suspend when closing the
18 matches
Mail list logo
