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 re
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
it, 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/
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
Rev
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 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 and attach it to
Hi David,
On Wed, Sep 4, 2013 at 7:34 PM, David Herrmann wrote:
> Hi
>
> On Sun, Sep 1, 2013 at 3:36 PM, David Herrmann wrote:
>> Hi
>>
>> With the upcoming 3.12 merge-window, I thought people might find themselves
>> with
>> nothing to do, so here's a new SimpleDRM series. Comments welcome!
>>
On Sun, Sep 8, 2013 at 2:13 AM, David Herrmann wrote:
> Hi
>
> On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen wrote:
>> Hi David,
>>
>> On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen wrote:
>>> On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann
>>> wr
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 ve
Hi David,
On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen wrote:
> 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.
>>
>> D
On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann wrote:
> On Fri, Sep 6, 2013 at 2:10 PM, Tom Gundersen wrote:
>> Hi guys,
>>
>> With current git (v3.11-5058-g57d7309) I get the following oops:
>>
>> [5.434312] [ cut here ]
>> [
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.
[5
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 l
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 l
18 matches
Mail list logo