--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/33d5ba80/attachment.html>
On Wed, Jan 22, 2014 at 11:09 PM, Andrzej Hajda wrote:
> Hi,
>
> It seems I have not added description to this patch.
> In this patch porch is calculated in compatible way to
> drm_display_mode_from_videomode core function.
> The way it was seems to me incorrect and it did not work on my hw.
>
> A
le
your own report with all the necessary information.
--
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/20140123/250bfa92/attachment.html>
rt --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/6354ab59/attachment.html>
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/bd665787/attachment.html>
is 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/20140123/86dc1996/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/e4848f36/attachment.html>
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/20140123/eb2506b7/attachment.html>
At Thu, 23 Jan 2014 06:35:12 +,
Lin, Mengdong wrote:
>
> > -Original Message-
> > From: Takashi Iwai [mailto:tiwai at suse.de]
> > Sent: Thursday, January 23, 2014 1:19 AM
> > To: Daniel Vetter
> > Cc: Lin, Mengdong; Barnes, Jesse; Zanoni, Paulo R;
> > alsa-devel at alsa-project.org; i
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/20633e49/attachment.html>
nst git d8c7740ddabeb456243e40dc3cf0e86c7fca09d0
--
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/20140123/827aef49/attachment.html>
On Thu, Jan 23, 2014 at 8:57 AM, Takashi Iwai wrote:
>> Thanks for clarification!
>> Maybe we can add output info (eg. display port number) to the eld entries
>> under /proc/asound/cardx. Is it okay?
>
> It's possible, but the proc file is just a help. It can't be the
> API. For accessing the i
Hi all,
So I've finally gotten around to honor my promise for some nice drm_mm.c
documentation and got slightly sidetracked. I have more cleanups in my queue
(mostly to better document the modesetting functions and polish the kerneldoc
reference sections a bit) but David Herrmann suggested that re
- 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 this from the GEM section to the KMS section,
next to the creation of
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 insertions(+), 5 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Doc
v2: Also do s/RETURNS/Returns/, less yelling in docs is always good.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_edid.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b924306b8
The stylesheet doesn't allow this in normal paragraphs.
Cc: David Herrmann dh.herrmann at gmail.com>
Acked-by: David Herrmann dh.herrmann at gmail.com>
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a
Split up the DocBook into the core drm part and a 2nd part for
driver documentation. As an example add a very (very!) basic
skeleton for i915.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 80 ++
1 file changed, 73 insertions(+), 7 dele
Currently it's sitting in the mode setting helper section, which isn't
quite right. Looks much better in the memory management section next
to TTM and GEM.
Cc: David Herrmann
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 12 ++--
1 file changed, 6 insertions(+), 6 de
Those all died with
commit 0111be42186fc5461b9e9d579014c70869ab3152
Author: Ville Syrj?l?
Date: Fri Oct 4 14:53:41 2013 +0300
drm: Kill drm perf counter leftovers
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 14 +++---
1 file changed, 3 insertions(+), 11 del
By consolidating them all into one section at the very end. And to
make double-sure that no one gets confused start with a stern warning
against any use of them. And prefix all subsections with "Legacy".
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 56 +++
Thierry created such nice kerneldocs, it's a shame we've left them
lingering!
For the fun of it also add a bit of kerneldoc to the header so that we
can also include that. Just in case someone adds kerneldoc in there.
Cc: Thierry Reding thierry.reding at gmail.com>
Signed-off-by: Daniel Vetter
-
PRIME fds aren't actually GEM fds but are (like the modeset API)
independent of the underlying buffer manager, as long as that one uses
uint32_t as handles. So move that entire section out of the GEM
section and reword it a bit to clarify which parts of PRIME are
generic, and which are the mandator
This was missed in
commit c700c67bae6698fbc6bd20e2ae5dc62ddd367b3b
Author: David Herrmann
Date: Sat Jul 27 13:39:28 2013 +0200
drm/mm: remove unused API
Cc: David Herrmann
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/dri
While at it do a tiny bit of interface cleanup and convert boolean
return values to bool. With this patch all exported functions and inline
helpers which are part of the drm_mm public interface are documented.
Also drop superflous extern function modifiers since most of drm_mm.h
doesn't use them -
This should be done in the driver chapter instead.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 10 --
1 file changed, 10 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index d5b087dee14d..9625cf7aa96a 100644
--- a/Document
Stumbled over while reviewing all occurences in the DRM doc talking
about suspend/resume.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl| 7 +--
drivers/gpu/drm/drm_crtc_helper.c | 9 +
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/Documentation
kerneldoc polish will follow in the next patch.
Hopefully documenting the lru scan support a bit better spurse someone
to give this a shot in the ttm eviction code. At least in i915 it
helped quite a lot with memory thrashing on platforms where eviction
was (we've fixed that too meanwhile) fairly
It's only used by imx, and that one gets it wrong - there's no need
to deteach the encoder before removing it.
And really, neither current drm modesetting code nor all the userspace
we have can handle dynamic changes in the set of possible encoders for
a given connector. So let's just remove this
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-agnostic fashion. As usual imx disagrees, but
that's due to the conv
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.
To have a complete set of references add the missing kerneldoc for all
fun
I've done quite a bit of cleanups, clarifications and mostly
integrating kerneldoc. So I guess I should add myself.
Also split up the copyright notices per holder to make it clear which
year ranges are covered.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 16 +++
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
On 01/23/2014 01:44 PM, Jingoo Han wrote:
> On Wednesday, January 22, 2014 6:36 PM, Jani Nikula wrote:
>> On Mon, 20 Jan 2014, Liu Ying wrote:
>>> We don't have to turn backlight on/off everytime a blanking
>>> or unblanking event comes because the backlight status may
>>> have already been what w
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
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 only generated
> > when in a level 2 section, not in a level 3 section. So we need to
> > move this up a bit a
On Thu, Jan 23, 2014 at 10:21:33AM +0100, David Herrmann wrote:
> 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
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 only generated
>> > when in a level 2 sectio
On 01/23/2014 05:27 PM, Liu Ying wrote:
> On 01/23/2014 01:44 PM, Jingoo Han wrote:
>> On Wednesday, January 22, 2014 6:36 PM, Jani Nikula wrote:
>>> On Mon, 20 Jan 2014, Liu Ying wrote:
We don't have to turn backlight on/off everytime a blanking
or unblanking event comes because the bac
On Thu, Jan 23, 2014 at 10:45:09AM +0100, David Herrmann wrote:
> 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 hilar
On Thu, Jan 23, 2014 at 10:42:02AM +0100, David Herrmann wrote:
> 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) sh
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/d37870b9/attachment.html>
ives/dri-devel/attachments/20140123/596ad12a/attachment.html>
|Drivers/DRI/Radeon
--
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/20140123/91c697a1/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/5f16dd27/attachment.html>
dri-devel/attachments/20140123/c60ed80b/attachment.html>
archives/dri-devel/attachments/20140123/322125ac/attachment-0001.html>
dri-devel/attachments/20140123/4c0d028a/attachment.html>
Hi Daniel,
Thank you for the patch.
On Thursday 23 January 2014 09:52:26 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 t
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/ccfaa5ff/attachment.html>
Hi David,
On Thursday 23 January 2014 10:14:35 David Herrmann wrote:
> 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
Hi Magnus,
On Thursday 23 January 2014 18:52:29 Magnus Damm wrote:
> On Wed, Jan 22, 2014 at 12:32 AM, Laurent Pinchart wrote:
> > Add DT bindings for the R-Car DU with support for core resources
> > (memory, IRQ and clocks). Output configuration must still be passed
> > through platform data usin
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/82518532/attachment.html>
vel/attachments/20140123/fe066432/attachment.html>
On Mon, 28 Oct 2013, Stefan Demharter wrote:
> Hi all,
>
> i've got a system with a muxed intel+ati card and had a problem with
> hibernation:
> Vgaswitcheroo didn't restore the states of the graphics cards and the state
> of the mux after resume.
>
> I have solved the issue with the attached pa
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/74fcc2b5/attachment.html>
dri-devel/attachments/20140123/ffdc2d29/attachment.html>
vel/attachments/20140123/73e3c8c5/attachment-0001.html>
ow and there is no audio.
So is this fixed then?
--
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/20140123/a5ec93c4/attachment.html>
vel/attachments/20140123/5bf2b5bc/attachment.html>
|font with compiz|font with compiz with SB
--
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/20140123/9a4ce
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/3579df85/attachment.html>
vel/attachments/20140123/b76b9ed0/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/4e2ecf28/attachment.html>
vel/attachments/20140123/d33fa041/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/7e8737c6/attachment-0001.html>
Our current DRM design uses a single address_space for all users of the
same DRM device. However, there is no way to create an anonymous
address_space without an underlying inode. Therefore, we wait for the
first ->open() callback on a registered char-dev and take-over the inode
of the char-dev. Th
DRM drivers share a common address_space across all character-devices of a
single DRM device. This allows simple buffer eviction and mapping-control.
However, DRM core currently waits for the first ->open() on any char-dev
to mark the underlying inode as backing inode of the device. This delayed
in
With dev->anon_inode we have a global address_space ready for operation
right from the beginning. Therefore, there is no need to do a delayed
setup with TTM. Instead, set dev_mapping during initialization in
ttm_bo_device_init() and remove any "if (dev_mapping)" conditions.
Cc: Dave Airlie
Cc: Be
Our current DRM design uses a single address_space for all users of the
same DRM device. However, there is no way to create an anonymous
address_space without an underlying inode. Therefore, we wait for the
first ->open() callback on a registered char-dev and take-over the inode
of the char-dev. Th
On Thu, Jan 23, 2014 at 12:21:42PM +0100, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Thursday 23 January 2014 09:52:26 Daniel Vetter wrote:
> > - This is _not_ a generic interface to create gem objects, but just an
> > interface to make early boot services (like bo
- 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 this from the GEM section to the KMS section,
next to the creation of
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/u
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
---
drivers/gpu/drm/u
On Thu, Jan 23, 2014 at 10:05:19AM +, Russell King - ARM Linux wrote:
> On Thu, Jan 23, 2014 at 11:00:28AM +0100, Daniel Vetter wrote:
> > On Thu, Jan 23, 2014 at 10:42:02AM +0100, David Herrmann wrote:
> > > If there's ever hardware that truly supports sub-device hotplugging,
> > > we can supp
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
>> an exporter does not pa
Lets make sure some basic expressions are always true:
bpp != NULL
width != NULL
height != NULL
stride = bpp * width < 2^32
size = stride * height < 2^32
PAGE_ALIGN(size) < 2^32
At least the udl driver doesn't check for multiplication-overflows, so
lets just make sure it will never hap
Hi Daniel,
On Thursday 23 January 2014 13:47:31 Daniel Vetter wrote:
> On Thu, Jan 23, 2014 at 12:21:42PM +0100, Laurent Pinchart wrote:
> > On Thursday 23 January 2014 09:52:26 Daniel Vetter wrote:
> > > - This is _not_ a generic interface to create gem objects, but just an
> > > interface to m
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gart.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 0e9143b..a8f9b46 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
From: Christian K?nig
Otherwise we allocate a new VMID on nearly every submit.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 2 ++
drivers/gpu/drm/radeon/radeon_gart.c | 8 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_fence.c | 6 +++---
drivers/gpu/drm/radeon/radeon_trace.h | 21 -
2 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm
Hi Daniel,
Thank you for the patch.
On Thursday 23 January 2014 13:48:17 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 t
On Thu, Jan 23, 2014 at 01:56:51PM +0100, Laurent Pinchart wrote:
> > > >
> > > > Drivers must first validate the requested frame buffer
> > > > parameters passed
> > > > @@ -1052,6 +998,71 @@ int max_width, max_height;
> > > > drm_framebuffer_unregister_private.
>
- 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 this from the GEM section to the KMS section,
next to the creation of
|Drivers/Gallium/r600
--
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/20140123/5c4fcf1a/attachment.html>
vel/attachments/20140123/901f7115/attachment.html>
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 * width < 2^32
> size = stride * height < 2^32
> PAGE_ALIGN(size) < 2^32
>
> At least the udl driver do
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/3108a7d5/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140123/d7743f3d/attachment.html>
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 * width < 2^32
>> size = stride * height
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 #1 and #2 are unchanged from the previous ML discussions. I
included them in this series as the other patches depen
With CONFIG_X86_SYSFB=y, probing real hw-drivers may result in
resource-conflicts and drivers will refuse to load. A call to
request_mem_region() will fail, if the region overlaps with the mem-region
used by simplefb. The common desktop DRM drivers (intel, nouveau, radeon)
are not affected as they
Turns out, people do not read help-texts of new config-options and enable
them nonetheless. So several reports came in with X86_SYSFB=y and
FB_SIMPLE=n, which in almost all situations prevents firmware-fbs from
being probed.
X86_SYSFB clearly states that it turns legacy vesa/efi framebuffers into
If x86-sysfb platform-devices are removed from a system, we should
properly unload efifb. Otherwise, we end up releasing the parent while our
efi framebuffer is still running. This currently works just fine, but will
cause problems on handover to real hw. So add the ->remove() callback and
unregist
To get a generic remove_conflicting_framebuffers() for
firmware-framebuffers, we need to store the apertures in the platform-data
of each framebuffer. So make x86-sysfb do that for simple-framebuffer
devices.
Unfortunately, "struct apertures_struct" contains a VLA so we cannot
easily embed it. Thu
If x86-sysfb platform-devices are removed from a system, we should
properly unload vesafb. Otherwise, we end up releasing the parent while
our vesa framebuffer is still running. This currently works just fine, but
will cause problems on handover to real hw. So add the ->remove() callback
and unregi
We supported many different firmware-fbs in linux for a long time. On x86,
we tried to unify the different types into platform-devices so their
lifetime and drivers can be more easily controlled. This patch moves the
x86-specific sysfb_*() helpers into drivers/video/sysfb.c so other
architectures c
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
1 - 100 of 147 matches
Mail list logo
