ping..
On Thu, Jan 23, 2014 at 1:48 PM, David Herrmann
wrote:
> We need to call dma_buf_end_cpu_access() in case a damage-request.
> Unlikely, but might happen during device unplug.
>
> Reviewed-by: Daniel Vetter
> Signed-off-by: David Herrmann
> ---
> drivers/gpu
ping..
On Thu, Jan 23, 2014 at 1:50 PM, David Herrmann
wrote:
> Probably a typo.. we obviously need "(bpp + 7) / 8" instead of
> "(bpp + 1) / 8". Unlikely to be hit in any sane code, but lets be safe.
> Use DIV_ROUND_UP() to avoid the problem entirely and
ping
On Mon, Jan 20, 2014 at 8:26 PM, David Herrmann
wrote:
> Remove double-whitespace and wrong indentation.
>
> Signed-off-by: David Herrmann
> ---
> drivers/gpu/drm/drm_gem.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu
ping
On Mon, Jan 20, 2014 at 8:26 PM, David Herrmann
wrote:
> All drivers currently need to clean up the vma-node manually. There is no
> fancy logic involved so lets just clean it up unconditionally. The
> vma-manager correctly catches multiple calls so we are fine.
>
> Signe
ping
On Thu, Jan 23, 2014 at 3:10 PM, David Herrmann
wrote:
> Hi
>
> On Thu, Jan 23, 2014 at 2:55 PM, Ville Syrj?l?
> wrote:
>> On Thu, Jan 23, 2014 at 01:53:15PM +0100, David Herrmann wrote:
>>> Lets make sure some basic expressions are always true:
>>&g
ping
On Tue, Jan 21, 2014 at 10:51 AM, Daniel Vetter wrote:
> On Mon, Jan 20, 2014 at 08:26:29PM +0100, David Herrmann wrote:
>> There is no need to initialize this variable, so drop it. Otherwise, the
>> compiler won't warn if we use it unintialized.
>>
>&g
Hi
On Sat, Feb 8, 2014 at 1:16 AM, Rian Quinn wrote:
> I noticed that the hotplug IOTCLs were removed. How are monitor hotplug
> events captured?
You get a "change"-uevent on the card-node. Use libudev with
udev_monitor to listen for them. Hotplug-events will have HOTPLUG=1 as
uevent-variable.
Hi
On Wed, Feb 12, 2014 at 2:25 PM, Daniel Vetter wrote:
> On Wed, Jan 29, 2014 at 03:01:52PM +0100, David Herrmann wrote:
>> Lets not trick ourselves into thinking "drm_device" objects are not
>> ref-counted. That's just utterly stupid. We manage "drm_minor
Hi
On Wed, Feb 12, 2014 at 5:40 PM, Greg KH wrote:
> On Wed, Feb 12, 2014 at 05:26:57PM +0100, Daniel Vetter wrote:
>> On Wed, Feb 12, 2014 at 3:44 PM, David Herrmann
>> wrote:
>> >>> +/**
>> >>> + * drm_dev_ref - Take reference of a DRM device
&g
Hi
On Wed, Feb 12, 2014 at 9:43 PM, Ville Syrj?l?
wrote:
> On Thu, Feb 13, 2014 at 06:14:04AM +1000, Dave Airlie wrote:
>> >
>> > The biggest remaining stumbling block is the backlight API, because
>> > opening the
>> > sysfs files requires root rights. I'll very likely write a little helper
>>
Hi
On Fri, Feb 21, 2014 at 8:09 AM, Thierry Reding
wrote:
> On Wed, Jan 29, 2014 at 03:01:53PM +0100, David Herrmann wrote:
> [...]
>> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
>> index c51333e..d3232b6 100644
>> --- a/drivers/gpu/drm/drm_stu
Hi
On Fri, Feb 21, 2014 at 8:30 AM, Thierry Reding
wrote:
> On Wed, Feb 12, 2014 at 02:36:24PM +0100, Daniel Vetter wrote:
>> On Wed, Jan 29, 2014 at 03:01:58PM +0100, David Herrmann wrote:
>> > Whenever we access minor->device, we are in a minor->kdev->...->fops
&g
Hi
On Fri, Feb 21, 2014 at 8:55 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> Non-legacy devices may not always support mode-setting functionality, so
> create the primary minor conditionally.
>
> One setup where this happens is the Tegra K1, where the Tegra DRM driver
> exposes the displ
s available.
>
> The remainder of the series cleans up some drm_core_check_feature()
> usage and drop some unused code related to that.
The series looks fine to me. Apart from "drm: Separate DRIVER_MODESET
and DRIVER_LEGACY" (and with Ilja's comment on 04/12):
Reviewed-by:
Hi
On Fri, Feb 21, 2014 at 8:01 AM, Thierry Reding
wrote:
> On Wed, Jan 29, 2014 at 03:01:52PM +0100, David Herrmann wrote:
> [...]
>> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> [...]
>> @@ -486,12 +490,10 @@ EXPORT_SYMBOL(drm_dev_alloc);
>&
Hi
On Fri, Feb 21, 2014 at 8:21 AM, Thierry Reding
wrote:
> On Wed, Jan 29, 2014 at 03:01:56PM +0100, David Herrmann wrote:
>> drm_get_minor() no longer allocates objects, and drm_unplug_minor() is now
>> the exact reverse of it. Rename it to _register/unregister() so their
>&g
to see the system-framebuffer platform-devices being registered
during architecture initialization. I haven't worked much there so any comments
are welcome. Otherwise, I will keep the HACK to add the devices during sysfb
module-init.
Regards
David
David Herrmann (9):
video: introduce syste
From: David Herrmann
For a long time now we have the problem that there are multiple drivers
available that try to use system framebuffers (like EFI, VESA/VBE, ...).
There is no way to control which driver gets access to the devices, but
instead works on a first-come-first-serve basis
From: David Herrmann
This adds the VESA BIOS Extension (VBE) device type. Platform code needs
to provide the "vbefb" platform-device with a screen_info structure as
platform code.
All drivers that depend on VBE can now register as bus drivers and bind
to SYSFB_VBE devices. T
From: David Herrmann
HACK: This should be provided by architecture setup code. But to show how it is
supposed to work, we now simply add a "vbefb" device during initialization.
The better way to do this is by moving this into arch-code. So for instance the
x86 boot initialization sho
From: David Herrmann
Fix the vesafb module to no longer use any static __init data. Also add a
module_exit() function that destroys the platform device.
Note that fbdev hotplugging is broken and the self-reference actually
prevents sane module-unloading. Anyway, this at least allows delayed
because the sysfb bus provides all devices now.
Signed-off-by: David Herrmann
---
drivers/video/Kconfig | 1 +
drivers/video/vesafb.c | 49 +++--
2 files changed, 16 insertions(+), 34 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
This provides a new DRM bus helper for the system framebuffer bus. It is
very similar in its functionality to the DRM_USB helper. It allows to
write DRM drivers that register as SYSFB drivers to the system.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/Kconfig | 5 ++
drivers/gpu/drm
into the framebuffer.
All buffer objects are backed by shmem so we can later add PRIME support.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/dvbe/Kconfig | 28 +++
drivers/gpu/drm/dvbe/Makefile| 4
pixel from the user's
buffer format into the target format while blitting.
Fast-paths for xrgb32/etc. could be implemented if we want to improve
blitting performance.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/dvbe/Kconfig | 1 +
drivers/gpu/drm/dvbe/Makefile| 2 +-
dr
.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/dvbe/Kconfig | 18 +++
drivers/gpu/drm/dvbe/Makefile | 1 +
drivers/gpu/drm/dvbe/dvbe.h | 23
drivers/gpu/drm/dvbe/dvbe_fbdev.c | 235 ++
drivers/gpu/drm/dvbe/dvbe_main.c | 2 +
5 files
Hi Dave
On Sun, Feb 17, 2013 at 11:02 PM, Dave Airlie wrote:
>>
>> This series tries to fix the mess with global system framebuffer access in
>> device drivers. Currently, architecture initialization sets the "screen_info"
>> object according to the system framebuffer that was detected during boo
Hi Dave
Sorry, I was busy reworking the HIDP layer. I finally got time to
continue my work on this again. See below:
On Mon, Feb 18, 2013 at 12:47 AM, Dave Airlie wrote:
[..snap..]
> As I said maybe I'm concentrating on the problem you aren't trying to fix,
> but then I'm not sure I've enough in
Hi Jesse
On Thu, Jan 10, 2013 at 1:22 AM, Jesse Barnes
wrote:
> On Fri, 28 Sep 2012 23:44:18 +0200
> David Herrmann wrote:
>
>> Hi
>>
>> This is revision 2 of the manpages for libdrm. I converted everything to
>> docbook
>> XML. This makes it easier to w
Hi Maarten
On Wed, Jan 16, 2013 at 3:16 PM, Maarten Lankhorst
wrote:
> Op 16-01-13 13:19, Maarten Lankhorst schreef:
>> ...
>> Jesse Barnes (1):
>> man: disable man page building until David saves us all
>>
> Looks like this commit might break building if you don't build against git
> dire
expensive xsltproc procedure can be
skipped.
Signed-off-by: David Herrmann
---
Hi
This is how I build manpages for kmscon and it worked until now so it should
also work for libdrm. I tried every kind of failure and out-of-tree builds and
everything worked. distcheck also passed fine.
I hope that
Hi Colin
On Thu, Jan 10, 2013 at 1:46 AM, Colin Walters wrote:
> It's not enough to check for xsltproc - the system may not have the
> docbook stylesheets installed. This patch also allows builders to
> override the generation/installation of manpages entirely; for
> example, manpages are of no
Hi Thierry
On Fri, Jan 18, 2013 at 1:22 PM, Thierry Reding
wrote:
> Due to the typo, none of the .xml files would end up in the release
> tarball and cause make distcheck as well as builds from the tarball to
> fail.
>
> Using $() isn't strictly necessary but other variables and expressions
> use
On Fri, Jan 18, 2013 at 5:00 PM, David Herrmann
wrote:
> Hi Thierry
>
> On Fri, Jan 18, 2013 at 1:22 PM, Thierry Reding
> wrote:
>> Due to the typo, none of the .xml files would end up in the release
>> tarball and cause make distcheck as well as builds from the tarball
Hi Mark
On Sun, Jan 20, 2013 at 7:39 AM, Mark Zhang wrote:
> Hi David:
>
> Sorry for jumping in. I pulled the ToT libdrm and it seems the manpages
> will not be built("make html" does nothing), any suggestions?
The manpages should be built automatically if you do "make". Or you
can try "make -C
Hi Jesse
On Fri, Jan 18, 2013 at 5:54 PM, Jesse Barnes
wrote:
> On Fri, 18 Jan 2013 17:01:59 +0100
> David Herrmann wrote:
>
>> On Fri, Jan 18, 2013 at 5:00 PM, David Herrmann
>> wrote:
>> > Hi Thierry
>> >
>> > On Fri, Jan 18, 2013 at 1:22
o the target format while blitting.
Fast-paths for xrgb32/etc. could be implemented if we want to improve
blitting performance.
Signed-off-by: David Herrmann
---
Hi
This driver is a very basic DRM driver with roughly the same functionality as
vesafb but with a userspace API that doesn't s
-point.
Thanks
David
David Herrmann (3):
drm: add pseudo filesystem for shared inodes
drm: use anon-inode instead of relying on cdevs
drm: init TTM dev_mapping in ttm_bo_device_init()
drivers/gpu/drm/ast/ast_ttm.c | 5 +++--
drivers/gpu/drm/cirrus/cirrus_ttm.c| 5 +++--
driv
However, most of this information is currently hidden and it's not clear
whether this address_space is suitable for driver access. Thus, unless
linux allows anonymous address_space objects or driver-core provides a
public inode per device, we're left with our own private internal mount
point
yed
initialization causes ugly conditions all over the place:
if (dev->dev_mapping)
do_sth();
To avoid delayed initialization and to stop reusing the inode of the
char-dev, we allocate an anonymous inode for each DRM device and reset
filp->f_mapping to it on ->open().
Signed-o
ve Airlie
Cc: Ben Skeggs
Cc: Maarten Lankhorst
Cc: Alex Deucher
Cc: Thomas Hellstrom
Signed-off-by: David Herrmann
---
drivers/gpu/drm/ast/ast_ttm.c | 5 +++--
drivers/gpu/drm/cirrus/cirrus_ttm.c| 5 +++--
drivers/gpu/drm/mgag200/mgag200_ttm.c | 5 +++--
drivers/gpu/drm/nouveau/
o find mask for
> + *
> + * Given a registered CRTC, return the mask bit of that CRTC for an
> + * encoder's possible_crtcs field.
I think this is a nice cleanup which we could pick up right away. Most
drivers can be simplified by using this. Only the name is misleading,
imo, I&#x
Hi
On Fri, Jan 3, 2014 at 5:13 PM, Russell King - ARM Linux
wrote:
> On Fri, Jan 03, 2014 at 05:05:46PM +0100, David Herrmann wrote:
>> Hi
>>
>> On Thu, Jan 2, 2014 at 10:27 PM, Russell King
>> wrote:
>> > The encoder possible_crtcs mask identifies which CRT
Hi
On Wed, Jan 8, 2014 at 7:31 PM, Damien Lespiau
wrote:
> Currently, drivers are expected to allocate private data and attach it
> to dev_private in struct drm_device.
>
> This has the unfortunate property to require driver code to juggle
> between the pointer to struct drm_device and dev->dev_
Hi
On Thu, Jan 9, 2014 at 1:11 PM, Damien Lespiau
wrote:
> On Wed, Jan 08, 2014 at 09:26:51PM +0100, Daniel Vetter wrote:
>> > So the parent structure is expected to have "struct drm_device" at
>> > offset 0? I'd rather like to see a "drm_dev_init()" alongside
>> > drm_dev_alloc() similar to dev
t. Rather than having
> drivers trying to track the position of their CRTCs in the list, expose
> the code which already exists for calculating the appropriate mask bit
> for a CRTC.
>
> Signed-off-by: Russell King
> Reviewed-by: David Herrmann
> [treding at nvidia.com: add drm_
Hi Russel
On Mon, Jan 13, 2014 at 1:47 PM, Russell King - ARM Linux
wrote:
> On Mon, Jan 13, 2014 at 12:58:54PM +0100, David Herrmann wrote:
>> Does that -1 ever make sense? We don't support mode-object-hotplugging
>> so all "drm_crtc" objects are known at initiali
Hi
On Mon, Jan 13, 2014 at 2:55 PM, Russell King - ARM Linux
wrote:
> On Mon, Jan 13, 2014 at 02:50:46PM +0100, David Herrmann wrote:
>> Hi Russel
>>
>> On Mon, Jan 13, 2014 at 1:47 PM, Russell King - ARM Linux
>> wrote:
>> > On Mon, Jan 13, 2014 at 12
Hi
On Tue, Jan 14, 2014 at 2:45 PM, Fengguang Wu wrote:
> Hi David,
>
> I'm not sure if this is a good bisect because the errors are noisy,
> however it's good to inform you of this possibility.
>
> First bad commit may be a3483353c ("drm: check for !kdev in
> drm_unplug_minor()")
To be honest,
Hi
On Fri, Jan 3, 2014 at 3:41 PM, David Herrmann wrote:
> Hi
>
> With 3.13-rc1 the required VFS core changes for anonymous backing inodes in
> DRM
> got merged. This series reworks the previous patches (I think from early
> August '13) and finally replaces the ugly drm_d
doesn't allocate anything, so looks good:
Reviewed-by: David Herrmann
Thanks
David
> Testcase: igt/gem_fd_exhaustion
> Reported-and-Suggested-by: Linus Torvalds
> Cc: Linus Torvalds
> References:
> http://lists.freedesktop.org/archives/intel-gfx/2014-January/038433.ht
Hi
On Mon, Jan 20, 2014 at 3:00 AM, Dave Airlie wrote:
>>> Hi
>>>
>>> On Fri, Jan 3, 2014 at 3:41 PM, David Herrmann
>>> wrote:
>>>> Hi
>>>>
>>>> With 3.13-rc1 the required VFS core changes for anonymous backing inodes
Probably a typo.. we obviously need "(bpp + 7) / 8" instead of
"(bpp + 1) / 8". Unlikely to be hit in any sane code, but lets be safe.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/udl/udl_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
We need to call dma_buf_end_cpu_access() in case a damage-request.
Unlikely, but might happen during device unplug.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/udl/udl_fb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm
t the importing one.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/udl/udl_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index df963a1..1069e57 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/dr
Remove double-whitespace and wrong indentation.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index bed5c3b..c1eaf35 100644
--- a/drivers/gpu/drm/drm_gem.c
All drivers currently need to clean up the vma-node manually. There is no
fancy logic involved so lets just clean it up unconditionally. The
vma-manager correctly catches multiple calls so we are fine.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_gem.c | 2 ++
1 file changed, 2
ut that may be slow on 32bit machines.. Or maybe
there should just be a "safe_mult32()" helper, which currently doesn't
exist (I think?).
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_crtc.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm
There is no need to initialize this variable, so drop it. Otherwise, the
compiler won't warn if we use it unintialized.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gp
Hi
On Tue, Jan 21, 2014 at 10:38 AM, Daniel Vetter wrote:
> On Mon, Jan 20, 2014 at 08:26:24PM +0100, David Herrmann wrote:
>> Probably a typo.. we obviously need "(bpp + 7) / 8" instead of
>> "(bpp + 1) / 8". Unlikely to be hit in any sane code, but lets
Hi
On Tue, Jan 21, 2014 at 10:49 AM, Daniel Vetter wrote:
> On Mon, Jan 20, 2014 at 08:26:28PM +0100, David Herrmann wrote:
>> Lets make sure some basic expressions are always true:
>> bpp != NULL
>> width != NULL
>> height != NULL
>> stride = bpp
Hi
On Tue, Jan 21, 2014 at 12:42 PM, Ville Syrj?l?
wrote:
> On Tue, Jan 21, 2014 at 12:17:35PM +0100, David Herrmann wrote:
>> Hi
>>
>> On Tue, Jan 21, 2014 at 10:49 AM, Daniel Vetter wrote:
>> > On Mon, Jan 20, 2014 at 08:26:28PM +0100, David Herrmann wrote:
&
Hi
On Thu, Jan 23, 2014 at 9:52 AM, Daniel Vetter
wrote:
> - This is _not_ a generic interface to create gem objects, but just an
> interface to make early boot services (like boot splash) with a
> generic KMS userspace driver possible. Hence it's better to move
> the documentation for thi
Hi
On Thu, Jan 23, 2014 at 9:52 AM, Daniel Vetter
wrote:
> Fairly incomplete, but at least a start.
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl | 6 +++-
> drivers/gpu/drm/drm_gem.c | 63
> +++---
> 2 files changed, 64 inse
Hi
On Thu, Jan 23, 2014 at 9:52 AM, Daniel Vetter
wrote:
> For giant hilarity the DocBook reference overview is only generated
> when in a level 2 section, not in a level 3 section. So we need to
> move this up a bit as a side-by-side section to the main PRIME
> documentation.
>
> Whatever.
I t
Hi
On Thu, Jan 23, 2014 at 9:52 AM, Daniel Vetter
wrote:
> Driver modules really don't have much business frobbing around with
> this: Splitting up modeset resources (if we ever get around to enable
> this for real) should be something purely controlled and managed by
> the drm core in a driver-
Hi
On Thu, Jan 23, 2014 at 10:37 AM, Daniel Vetter wrote:
> On Thu, Jan 23, 2014 at 10:28:42AM +0100, David Herrmann wrote:
>> Hi
>>
>> On Thu, Jan 23, 2014 at 9:52 AM, Daniel Vetter
>> wrote:
>> > For giant hilarity the DocBook reference overview is o
However, most of this information is currently hidden and it's not clear
whether this address_space is suitable for driver access. Thus, unless
linux allows anonymous address_space objects or driver-core provides a
public inode per device, we're left with our own private internal mount
poin
yed
initialization causes ugly conditions all over the place:
if (dev->dev_mapping)
do_sth();
To avoid delayed initialization and to stop reusing the inode of the
char-dev, we allocate an anonymous inode for each DRM device and reset
filp->f_mapping to it on ->open().
Signed-o
ve Airlie
Cc: Ben Skeggs
Cc: Maarten Lankhorst
Cc: Alex Deucher
Cc: Thomas Hellstrom
Signed-off-by: David Herrmann
---
drivers/gpu/drm/ast/ast_ttm.c | 5 +++--
drivers/gpu/drm/cirrus/cirrus_ttm.c| 5 +++--
drivers/gpu/drm/mgag200/mgag200_ttm.c | 5 +++--
drivers/gpu/drm/nouveau/
However, most of this information is currently hidden and it's not clear
whether this address_space is suitable for driver access. Thus, unless
linux allows anonymous address_space objects or driver-core provides a
public inode per device, we're left with our own private internal mount
poin
We need to call dma_buf_end_cpu_access() in case a damage-request.
Unlikely, but might happen during device unplug.
Reviewed-by: Daniel Vetter
Signed-off-by: David Herrmann
---
drivers/gpu/drm/udl/udl_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl
Probably a typo.. we obviously need "(bpp + 7) / 8" instead of
"(bpp + 1) / 8". Unlikely to be hit in any sane code, but lets be safe.
Use DIV_ROUND_UP() to avoid the problem entirely and make the core more
readable.
Reviewed-by: Daniel Vetter
Signed-off-by: David Herrmann
Hi
On Tue, Jan 21, 2014 at 10:41 AM, Daniel Vetter wrote:
> On Mon, Jan 20, 2014 at 08:26:25PM +0100, David Herrmann wrote:
>> Instead of rounding down to the next lower page-boundary, round up.
>> dma-buf guarantees that we can map buffers in multiples of a page, so if
>>
ut that may be slow on 32bit machines.. Or maybe
there should just be a "safe_mult32()" helper, which currently doesn't
exist (I think?).
Reviewed-by: Daniel Vetter
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_crtc.c | 17 +
1 file changed, 17 insertions(+)
Hi
On Thu, Jan 23, 2014 at 2:55 PM, Ville Syrj?l?
wrote:
> On Thu, Jan 23, 2014 at 01:53:15PM +0100, David Herrmann wrote:
>> Lets make sure some basic expressions are always true:
>> bpp != NULL
>> width != NULL
>> height != NULL
>> stride = bpp
overhead to paper of lazy user-space.
I have tested this with all hardware that I have at home, with a lot hand-over
combinations (with/without SYSFB, with efifb/vesafb/simplefb, with SimpleDRM,
...) and all worked great so far.
Comments welcome!
David
David Herrmann (11):
x86: sysfb: fool-pr
good to go. simplefb is unregistered by
sysfb_unregister() now, so no reason to keep the apertures (on non-x86,
there currently is no handover from simplefb, so we're fine. If it's
added, they need to provide something like sysfb_unregister() too)
Signed-off-by: David Herrmann
R
this is still ongoing, there's no need for non-developers to care for
X86_SYSFB so we can safely hide it behind FB_SIMPLE.
Signed-off-by: David Herrmann
---
arch/x86/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0952ecd..098228e 100644
and
unregister efifb.
Signed-off-by: David Herrmann
---
drivers/video/efifb.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index cd7c0df..ae9618f 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -73,7 +7
y embed it. Thus, we have to use a "apert_buf" buffer with enough
room for one "struct aperture".
Signed-off-by: David Herrmann
---
arch/x86/include/asm/sysfb.h | 6 +--
arch/x86/kernel/sysfb.c| 2 +-
arch/x86/kern
and unregister vesafb.
Signed-off-by: David Herrmann
---
drivers/video/vesafb.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/video/vesafb.c b/drivers/video/vesafb.c
index 1c7da3b..6170e7f 100644
--- a/drivers/video/vesafb.c
+++ b/drivers/video/vesaf
ly, a short documentation of the
different existing firmware-fbs and handover-mechanisms is put into
Documentation/firmware-fbs.txt.
Compared to remove_conflicting_framebuffers(), the sysfb interface is
independent of FBDEV. Thus, we can use it for DRM-only handovers.
Signed-off-by: David Her
We used to protect X86_SYSFB by depending on FB_SIMPLE so users don't
accidentally end up without a kernel console. Now that DRM_SIMPLEDRM also
provides a simple-framebuffer driver, we can whitelist this driver, too.
---
arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
sfb-devices, too.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/mgag200/mgag200_main.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 26868e5..0ee093c 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mai
out to be not as easy as you might
think, so lets just evict all sysfbs for now before loading i915.
A proper fix would be to make DRM code allow parallel device probing.
That's not going to happen soon, so be safe and make i915 evict all
sysfbs.
Signed-off-by: David Herrmann
---
drivers/gpu/
is allowed
(compared to earlier version of this driver) to avoid security issues.
Furthermore, this way we can support arbitrary modes as long as we have a
convertion-helper.
Signed-off-by: David Herrmann
---
MAINTAINERS | 8 +
drivers/gpu/drm/Kconfig
Create a simple fbdev device during SimpleDRM setup so legacy user-space
and fbcon can use it.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/simpledrm/Kconfig | 11 +++
drivers/gpu/drm/simpledrm/Makefile | 1 +
drivers/gpu/drm/simpledrm/simpledrm.c | 13
Hi
On Thu, Jan 23, 2014 at 5:51 PM, Ingo Molnar wrote:
>
> Just a couple of small nits:
>
> * David Herrmann wrote:
>
>> --- a/arch/x86/kernel/sysfb.c
>> +++ b/arch/x86/kernel/sysfb.c
>> @@ -33,11 +33,76 @@
>> #include
>> #include
>>
Hi
On Thu, Jan 23, 2014 at 6:14 PM, Ingo Molnar wrote:
>
> * David Herrmann wrote:
>
>> >> +#ifdef CONFIG_X86_SYSFB
>> >> +# include
>> >> +#endif
>> >
>> > I guess a single space is sufficient?
>> >
>> > Bet
Hi
On Thu, Jan 23, 2014 at 3:14 PM, David Herrmann
wrote:
> Hi
>
> Another round of SimpleDRM patches. I somehow lost track of the last ones and
> as
> this is a major rewrite, I'll just start at v1 again.
>
> Some comments up-front:
>
> - @Ingo: Patch
These are unused and can safely be dropped. DRM core verifies they're
non-NULL before it calls them.
Cc: Patrik Jakobsson
Signed-off-by: David Herrmann
---
drivers/gpu/drm/gma500/psb_drv.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_dr
this into their tree and push to Fengguang's
test-framework, I'd appreciate it a lot! I'm still waiting for a reply from him.
Thanks
David
David Herrmann (13):
drm: group dev-lifetime related members
drm: skip redundant minor-lookup in open path
drm: remove unused DRM_MINOR_UN
These members are all managed by DRM-core, lets group them together so
they're not split across the whole device.
Signed-off-by: David Herrmann
---
include/drm/drmP.h | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/include/drm/drmP.h b/includ
The drm_open_helper() function is only used internally for drm_open() so
we can safely pass in the minor-object directly instead of the minor-id.
This way, we avoid the additional minor IDR lookup, which we already do
twice in drm_stub_open() and drm_open().
Signed-off-by: David Herrmann
This constant is unused, remove it.
Signed-off-by: David Herrmann
---
include/drm/drmP.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 6bd2d74..89b9d58 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1005,7 +1005,6 @@ struct
Use enum for DRM_MINOR_* constants to avoid hard-coding the IDs.
Furthermore, add a DRM_MINOR_CNT so we can perform range-checks in
follow-ups.
This changes the IDs of the minor-types by -1, but they're not used as
indices so this is fine.
Signed-off-by: David Herrmann
---
include/drm/d
llow-up patches will replace open_count by it).
Also note that generic VFS revoke support could allow us to drop this
ref-count again. We could then just synchronously disable any fops->xy()
calls. However, this is not the case, yet, and no such patches are
in sight (and I seriously question the id
as the minor is used in an
open-file. This way, "struct file*"->private_data->dev is guaranteed to be
valid (which it has to, as we cannot reset it).
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_fops.c | 50 +-
drivers/gpu/
minor-ID allocation to
one base-ID instead of a single ID for each.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_stub.c | 110 +
1 file changed, 71 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub
801 - 900 of 1115 matches
Mail list logo
