On Thu, Jan 24, 2019 at 05:58:24PM +0100, Daniel Vetter wrote:
> This should not result in any changes.
I'd love to merge https://patchwork.freedesktop.org/series/53951/
instead (which will -- among other things -- switch qxl over to the
generic fbdev emulation and remove the code you are
== Series Details ==
Series: series starting with [01/33] drm/i915/execlists: Move RPCS setup to
context pin
URL : https://patchwork.freedesktop.org/series/55708/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5478 -> Patchwork_12035
== Series Details ==
Series: series starting with [01/33] drm/i915/execlists: Move RPCS setup to
context pin
URL : https://patchwork.freedesktop.org/series/55708/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/execlists: Move RPCS setup to
== Series Details ==
Series: series starting with [01/33] drm/i915/execlists: Move RPCS setup to
context pin
URL : https://patchwork.freedesktop.org/series/55708/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6abb3bdb8c37 drm/i915/execlists: Move RPCS setup to context pin
Remove the struct_mutex requirement for looking up the vma for an
object.
v2: Highlight how the race for duplicate vma creation is resolved on
reacquiring the lock with a short comment.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 6
Previously we only accommodated having a vma pinned by a small number of
users, with the maximum being pinned for use by the display engine. As
such, we used a small bitfield only large enough to allow the vma to
be pinned twice (for back/front buffers) in each scanout plane. Keeping
the maximum
Always perform the requested reset, even if we believe the engine is
idle. Presumably there was a reason the caller wanted the reset, and in
the near future we lose the easy tracking for whether the engine is
idle.
Signed-off-by: Chris Wilson
Reviewed-by: John Harrison
---
The global seqno is defunct and so we have no meaningful indicator of
forward progress for an engine. You need to listen to the request
signaling tracepoints instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 2 --
drivers/gpu/drm/i915/i915_trace.h | 25
Our goal is to remove struct_mutex and replace it with fine grained
locking. One of the thorny issues is our eviction logic for reclaiming
space for an execbuffer (or GTT mmaping, among a few other examples).
While eviction itself is easy to move under a per-VM mutex, performing
the activity
Now that the submission backends are controlled via their own spinlocks,
with a wave of a magic wand we can lift the struct_mutex requirement
around GPU reset. That is we allow the submission frontend (userspace)
to keep on submitting while we process the GPU reset as we can suspend
the backend
Now that we know we measure the size of the engine->emit_breadcrumb()
correctly, we can remove the previous manual counting.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 4 ++--
drivers/gpu/drm/i915/intel_engine_cs.c | 7 +++
drivers/gpu/drm/i915/intel_lrc.c
From: Tvrtko Ursulin
Timeline barrier allows serialization between different timelines.
After calling i915_timeline_set_barrier with a request, all following
submissions on this timeline will be set up as depending on this request,
or barrier. Once the barrier has been completed it
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else
In bringup on simulated HW even rudimentary tests are slow, and so many
may fail that we want to be able to filter out the noise to focus on the
specific problem. Even just the tests groups provided for igt is not
specific enough, and we would like to isolate one particular subtest
(and probably
Now that we have allocated ourselves a cacheline to store a breadcrumb,
we can emit a write from the GPU into the timeline's HWSP of the
per-context seqno as we complete each request. This drops the mirroring
of the per-engine HWSP and allows each context to operate independently.
We do not need
Instead of tediously and fragilely counting up the number of dwords
required to emit the breadcrumb to seal a request, fake a request and
measure it automatically once during engine setup.
The downside is that this requires a fair amount of mocking to create a
proper breadcrumb. Still, should be
If we restrict ourselves to only using a cacheline for each timeline's
HWSP (we could go smaller, but want to avoid needless polluting
cachelines on different engines between different contexts), then we can
suballocate a single 4k page into 64 different timeline HWSP. By
treating each fresh
A starting point to counter the pervasive struct_mutex. For the goal of
avoiding (or at least blocking under them!) global locks during user
request submission, a simple but important step is being able to manage
each clients GTT separately. For which, we want to replace using the
struct_mutex as
The guc (and huc) currently inexcruitably depend on struct_mutex for
device reinitialisation from inside the reset, and indeed taking any
mutex here is verboten (as we must be able to reset from underneath any
of our mutexes). That makes recovering the guc unviable without, for
example, reserving
To allow requests to forgo a common execution timeline, one question we
need to be able to answer is "is this request running?". To track
whether a request has started on HW, we can emit a breadcrumb at the
beginning of the request and check its timeline's HWSP to see if the
breadcrumb has
From: Tvrtko Ursulin
Configuring RPCS in context image just before pin is sufficient and will
come extra handy in one of the following patches.
v2:
* Split image setup a bit differently. (Chris Wilson)
v3:
* Update context image after reset as well - otherwise the application
of pinned
Currently we only allocate an object and vma if we are using a GGTT
virtual HWSP, and a plain struct page for a physical HWSP. For
convenience later on with global timelines, it will be useful to always
have the status page being tracked by a struct i915_vma. Make it so.
Signed-off-by: Chris
Supplement the per-engine HWSP with a per-timeline HWSP. That is a
per-request pointer through which we can check a local seqno,
abstracting away the presumption of a global seqno. In this first step,
we point each request back into the engine's HWSP so everything
continues to work with the global
Missed breadcrumb detection is defunct due to the tight coupling with
dma_fence signaling and the myriad ways we may signal fences from
everywhere but from an interrupt, i.e. we frequently signal a fence
before we even see its interrupt. This means that even if we miss an
interrupt for a fence, it
Now that we pin timelines around use, we have a clearly defined lifetime
and convenient points at which we can track only the active timelines.
This allows us to reduce the list iteration to only consider those
active timelines and not all.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Simplify by using sizeof(u32) to convert from the index inside the HWSP
to the byte offset. This has the advantage of not only being shorter
(and so not upsetting checkpatch!) but that it matches use where we are
writing to byte addresses using other commands than MI_STORE_DWORD_IMM.
We have a number of tasks that we like to run when idle and parking the
GPU into a powersaving mode. A few of those tasks are using the global
idle point as a convenient moment when all previous execution has been
required (and so we know that the GPU is not still touching random
user memory).
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We
Having introduced per-context seqno, we know have a means to identity
progress across the system without feel of rollback as befell the
global_seqno. That is we can program a MI_SEMAPHORE_WAIT operation in
advance of submission safe in the knowledge that our target seqno and
address is stable.
Trim the struct_mutex hold and exclude the call to i915_gem_set_wedged()
as a reminder that it must be callable without struct_mutex held.
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 7
We don't want to busywait on the GPU if we have other work to do. If we
give non-busywaiting workloads higher (initial) priority than workloads
that require a busywait, we will prioritise work that is ready to run
immediately.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c
Allocate a page for use as a status page by a group of timelines, as we
only need a dword of storage for each (rounded up to the cacheline for
safety) we can pack multiple timelines into the same page. Each timeline
will then be able to track its own HW seqno.
v2: Reuse the common per-engine HWSP
In the next patch, we add another user that wants to check whether
requests can be merge into a single HW execution, and in the future we
want to add more conditions under which requests from the same context
cannot be merge. In preparation, extract out can_merge_rq().
Signed-off-by: Chris Wilson
In preparation for the next few commits, make resetting the GPU atomic.
Currently, we have prepared gen6+ for atomic resetting of individual
engines, but now there is a requirement to perform the whole device
level reset (just the register poking) from inside an atomic context.
Signed-off-by:
In preparation for enabling HW semaphores, we need to keep in flight
timeline HWSP alive until the entire system is idle, as any other
timeline active on the GPU may still refer back to the already retired
timeline. We both have to delay recycling available cachelines and
unpinning old HWSP until
Currently, the list of timelines is serialised by the struct_mutex, but
to alleviate difficulties with using that mutex in future, move the
list management under its own dedicated mutex.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h |
A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the
thundering i915_wait_request herd"), the issue of handling multiple
clients waiting in parallel was brought to our attention. The
requirement was that every client should be woken immediately upon its
request being signaled,
Hi,
On Fri, 25 Jan 2019 01:21:26 + "Li, Weinan Z" wrote:
>
> I am not sure about the problem. The commit id "0cce2823ed37" is just
> for the patch of "drm/i915/gvt: Refine error handling for
> prepare_execlist_workload". Is there any other problems I missed?
Its just that the subject line
Thank Stephen.
I am not sure about the problem. The commit id "0cce2823ed37" is just for the
patch of "drm/i915/gvt: Refine error handling for prepare_execlist_workload".
Is there any other problems I missed?
Regards.
-Weinan
> -Original Message-
> From: Jani Nikula
On Thu, Jan 24, 2019 at 12:23:45PM +0100, Maarten Lankhorst wrote:
> Op 23-01-2019 om 18:31 schreef Matt Roper:
> > On Tue, Jan 22, 2019 at 01:12:07PM -0800, Manasi Navare wrote:
> >> On Gen 11 platform, to enable resolutions like 5K@120 where
> >> the pixel clock is greater than pipe pixel rate,
On Tue, 2019-01-22 at 14:42 -0800, Dhinakaran Pandiyan wrote:
> On Wed, 2019-01-16 at 15:43 -0800, José Roberto de Souza wrote:
> > If the sink and source supports HBR3, TP4 should be used as link
> > training pattern.
> > For PSR2 there is no register to set and enable TP4 but according
> > to
>
Quoting Tvrtko Ursulin (2019-01-24 11:42:02)
> +static int gen8_emit_rpcs_config(struct i915_request *rq,
> +struct intel_context *ce,
> +struct intel_sseu sseu)
> +{
> + u64 offset;
> + u32 *cs;
> +
> + cs =
Quoting Ville Syrjälä (2019-01-15 13:43:41)
> On Mon, Jan 14, 2019 at 09:55:10AM +, Tvrtko Ursulin wrote:
> >
> > On 11/01/2019 19:46, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > To overcome display engine stride limits we'll want to remap the
> > > pages in the GTT. To that
Quoting Ville Syrjala (2019-01-24 18:58:02)
> From: Ville Syrjälä
>
> Extend the rotated vma mock selftest to cover remapped vmas as
> well.
>
> TODO: reindent the loops I guess? Left like this for now to
> ease review
Probably leave it as is for the moment. Looks like we need to split the
Quoting Ville Syrjala (2019-01-24 19:11:57)
> From: Ville Syrjälä
>
> Add a live selftest to excercise rotated/remapped vmas. We simply
> write through the rotated/remapped vma, and confirm that the data
> appears in the right page when read through the normal vma.
>
> Not sure what the fallout
On Wednesday, January 23, 2019 6:04 AM, Kees Cook wrote
>
> Variables declared in a switch statement before any case statements
> cannot be initialized, so move all instances out of the switches.
> After this, future always-initialized stack variables will work
> and not throw warnings like this:
On Thu, Jan 24, 2019 at 02:01:14PM +0100, Maarten Lankhorst wrote:
> From: Hans de Goede
>
> We really want to have fastboot enabled by default to avoid an ugly
> modeset during boot.
>
> Rather then enabling it everywhere, lets start with enabling it on
> Skylake and newer.
>
> Signed-off-by:
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev18)
URL : https://patchwork.freedesktop.org/series/48194/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M]
From: Tvrtko Ursulin
Timeline barrier allows serialization between different timelines.
After calling i915_timeline_set_barrier with a request, all following
submissions on this timeline will be set up as depending on this request,
or barrier. Once the barrier has been completed it
== Series Details ==
Series: drm/i915: GTT remapping for display (rev7)
URL : https://patchwork.freedesktop.org/series/55415/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5475_full -> Patchwork_12033_full
Summary
---
Em qui, 2019-01-24 às 10:52 -0800, Lucas De Marchi escreveu:
> On Wed, Jan 23, 2019 at 05:15:26PM -0800, Paulo Zanoni wrote:
> > Em qui, 2019-01-17 às 12:21 -0800, Lucas De Marchi escreveu:
> > > Fix the TODO leftover in the code by changing the argument in MG_PLL
> > > macros. The MG_PLL ids used
== Series Details ==
Series: drm/i915: GTT remapping for display (rev7)
URL : https://patchwork.freedesktop.org/series/55415/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5475 -> Patchwork_12033
Summary
---
== Series Details ==
Series: drm/i915: GTT remapping for display (rev7)
URL : https://patchwork.freedesktop.org/series/55415/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Add a new "remapped" gtt_view
== Series Details ==
Series: drm/i915: GTT remapping for display (rev7)
URL : https://patchwork.freedesktop.org/series/55415/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
02b1fe191700 drm/i915: Add a new "remapped" gtt_view
-:96: CHECK:LINE_SPACING: Please don't use multiple
From: Ville Syrjälä
v2: Rebase due to can_remap()
---
drivers/gpu/drm/i915/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c6f59bfb4744..c720891b31c9 100644
---
== Series Details ==
Series: drm/i915: GTT remapping for display (rev6)
URL : https://patchwork.freedesktop.org/series/55415/
State : failure
== Summary ==
Applying: drm/i915: Add a new "remapped" gtt_view
Using index info to reconstruct a base tree...
M
From: Ville Syrjälä
Add a live selftest to excercise rotated/remapped vmas. We simply
write through the rotated/remapped vma, and confirm that the data
appears in the right page when read through the normal vma.
Not sure what the fallout of making all rotated/remapped vmas
mappable/fenceable
== Series Details ==
Series: drm/i915: GTT remapping for display (rev5)
URL : https://patchwork.freedesktop.org/series/55415/
State : failure
== Summary ==
Applying: drm/i915: Add a new "remapped" gtt_view
Using index info to reconstruct a base tree...
M
From: Ville Syrjälä
With gtt remapping plugged in we can simply raise the stride
limit on gen4+. Let's just pick the limit to match the render
engine max stride (256KiB).
No remapping CCS because the virtual address of each page actually
matters due to the new hash mode
From: Ville Syrjälä
The display engine stride limits are getting in our way. On SKL+
we are limited to 8k pixels, which is easily exceeded with three
4k displays. To overcome this limitation we can remap the pages
in the GTT to provide the display engine with a view of memory
with a smaller
From: Ville Syrjälä
Extend the rotated vma mock selftest to cover remapped vmas as
well.
TODO: reindent the loops I guess? Left like this for now to
ease review
v2: Include the vma type in the error message (Chris)
v3: Deal with trimmed sg
v4: Drop leftover debugs
Cc: Chris Wilson
On Wed, Jan 23, 2019 at 05:15:26PM -0800, Paulo Zanoni wrote:
Em qui, 2019-01-17 às 12:21 -0800, Lucas De Marchi escreveu:
Fix the TODO leftover in the code by changing the argument in MG_PLL
macros. The MG_PLL ids used to access the register values can be
converted from tc_port rather than
Chris Wilson writes:
> Quoting Koenig, Christian (2019-01-22 08:49:30)
>> Am 22.01.19 um 00:20 schrieb Chris Wilson:
>> > Rather than every backend and GPU driver reinventing the same wheel for
>> > user level debugging of HW execution, the common dma-fence framework
>> > should include the
Quoting Tvrtko Ursulin (2019-01-24 17:55:20)
>
> On 21/01/2019 22:21, Chris Wilson wrote:
> > Missed breadcrumb detection is defunct due to the tight coupling with
>
> How it is defunct.. oh because there is no irq_count any more... could
> you describe the transition from irq_count to
Hi Daniel.
On Thu, Jan 24, 2019 at 05:58:14PM +0100, Daniel Vetter wrote:
> Should not result in any changes.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Junwei Zhang
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: Daniel Vetter
> Cc: Sean Paul
> Cc: YueHaibing
> Cc: Sam
On 21/01/2019 22:21, Chris Wilson wrote:
Missed breadcrumb detection is defunct due to the tight coupling with
How it is defunct.. oh because there is no irq_count any more... could
you describe the transition from irq_count to irq_fired and then to
nothing briefly?
dma_fence signaling
Hi Daniel.
On Thu, Jan 24, 2019 at 05:58:11PM +0100, Daniel Vetter wrote:
> The fbdev emulation helpers pretty much assume that this is set.
> Let's do it for everyone.
I do not know this code at all.
But I failed to follow the code from the patch description.
It do not give _me_ a clue why the
Den 24.01.2019 17.58, skrev Daniel Vetter:
> The fbdev split between fix and var information is kinda
> pointless for drm drivers since everything is fixed: The fbdev
> emulation doesn't support changing modes at all.
>
> Create a new simplified helper and use it in the generic fbdev
> helper
Hi Daniel.
> +
> + /**
> + * @DRIVER_HAVE_DMA:
> + *
> + * Driver supports DMA, the userspace DMA API will be supported. Only
> + * for legacy drivers. Do not use.
> + */
> + DRIVER_HAVE_DMA = BIT(4),
What about grouping all the "legacy, do not
On Thu, Jan 24, 2019 at 5:58 PM Daniel Vetter wrote:
>
> Looking at the oldest/most popular drivers ${driver}drmfb seems to be
> the standard, except i915.ko went with "inteldrmfb". I guess renaming
> that for consistency won't hurt, it definitely confused me when I
> started with kms 10 years
On 18/01/2019 14:01, Chris Wilson wrote:
Previously, our view has been always to run the engines independently
within a context. (Multiple engines happened before we had contexts and
timelines, so they always operated independently and that behaviour
persisted into contexts.) However, at the
== Series Details ==
Series: series starting with [1/3] drm/i915: Measure the required reserved size
for request emission
URL : https://patchwork.freedesktop.org/series/55684/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5475_full -> Patchwork_12028_full
Hi all,
Flushing out my "I got bored over holidays" queue. A bit of docs, a bit of
simplication and a bunch of fbdev helper refactor. Review and comments
very much appreciated.
Cheers, Daniel
Daniel Vetter (26):
drm/irq: Don't check for DRIVER_HAVE_IRQ in drm_irq_(un)install
drm: Switch
This changes the fb name from "nouveaufb" to "nouveaudrmfb".
Aside: I wonder whether the in_interrupt() check is good enough for
the nouveau acceleration. Cargo-cult says drm_can_sleep() is needed,
which isn't actually working if you pick a .config without PREEMPT.
For the generic fbdev defio
Should not result in any changes.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Alex Deucher
Cc: "Christian König"
Cc: Junwei Zhang
Cc: Daniel Vetter
---
drivers/gpu/drm/mgag200/mgag200_drv.h | 2 +-
drivers/gpu/drm/mgag200/mgag200_fb.c | 8 +---
2 files changed, 2 insertions(+), 8
And move the documenation we alreay have into kerneldoc, plus a bit of
polish while at it.
FIXME: Updates for drm_driver.driver_features are missing, need to get
Sam's patches landed first.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-internals.rst | 62 -
== Series Details ==
Series: some cleanups, mostly around fbdev emulation
URL : https://patchwork.freedesktop.org/series/55690/
State : failure
== Summary ==
Applying: drm/irq: Don't check for DRIVER_HAVE_IRQ in drm_irq_(un)install
Applying: drm: Switch DRIVER_ flags to an enum
Applying:
Should not cause any changes.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: Samuel Li
Cc: "Michel Dänzer"
Cc: Huang Rui
Cc: Junwei Zhang
Cc: Daniel Vetter
Cc: Daniel Stone
Cc: Shirish S
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 24
This changes the fb name from "inteldrmfb" to "i915drmfb".
Signed-off-by: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_fbdev.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git
Looking at the oldest/most popular drivers ${driver}drmfb seems to be
the standard, except i915.ko went with "inteldrmfb". I guess renaming
that for consistency won't hurt, it definitely confused me when I
started with kms 10 years ago.
I hope this never became uapi ... worst case drivers can
This will change the fb name from "msm" to "msmdrmfb".
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
drivers/gpu/drm/msm/msm_fbdev.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git
This is only used by drm_irq_install(), which is an optional helper.
And the right choice is to set it for all pci devices, and not for
everything else.
Any driver with special needs should just use request_irq() directly,
and there's plenty of drivers doing that already.
Signed-off-by: Daniel
This will give the exynos fbdev a name!
Signed-off-by: Daniel Vetter
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
---
If a non-legacy driver calls these it's valid to assume there is
interrupt support. The flag is really only needed for legacy drivers.
Also remove all the flag usage from non-legacy drivers.
Signed-off-by: Daniel Vetter
Cc: linux-arm-ker...@lists.infradead.org
Cc:
This will set an fb name for the first time!
Signed-off-by: Daniel Vetter
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
---
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 4 +---
1 file changed, 1 insertion(+), 3
Not used by drivers anymore.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 38 +
include/drm/drm_fb_helper.h | 4
2 files changed, 5 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c
It's 0.
Signed-off-by: Daniel Vetter
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Patrik Jakobsson
Cc: Ben Skeggs
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: Hans de Goede
Cc: Greg
This should not result in any changes.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Sean Paul
Cc: Mikulas Patocka
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Emil Lundmark
---
drivers/gpu/drm/udl/udl_fb.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
This should not result in any changes.
v2: Rebase over vbox changes - vbox gained it's own line to fill
fix.id.
Signed-off-by: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Hans de Goede
Cc: Daniel Vetter
Cc: Alexander Kapshuk
Cc: Bartlomiej Zolnierkiewicz
---
Another driver that didn't set fbinfo->fix.id before.
Signed-off-by: Daniel Vetter
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/fb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tegra/fb.c
This should not result in any changes.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_fb.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git
This will change the fb name from "psbdrmfb" to "gma500drmfb".
Signed-off-by: Daniel Vetter
Cc: Patrik Jakobsson
---
drivers/gpu/drm/gma500/framebuffer.c | 7 +--
drivers/gpu/drm/gma500/framebuffer.h | 2 +-
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git
This should not result in any changes.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_fb.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git
This changes the fb name from "omapdrm" to "omapdrmfb".
Signed-off-by: Daniel Vetter
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_fbdev.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
Should not result in any changes.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: Junwei Zhang
Cc: Xinliang Liu
Cc: "Christian König"
Cc: Ajit Negi
Cc: Souptick Joarder
Cc: Daniel Vetter
Cc: John Garry
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +-
Should not result in any changes.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Junwei Zhang
Cc: Alex Deucher
Cc: "Christian König"
Cc: Daniel Vetter
Cc: Sean Paul
Cc: YueHaibing
Cc: Sam Bobroff
---
drivers/gpu/drm/ast/ast_drv.h | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 7 +--
2
Should not result in any changes.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/cirrus/cirrus_drv.h | 2 +-
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 8 +---
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h
The fbdev emulation helpers pretty much assume that this is set.
Let's do it for everyone.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index
Only changes the name of the fb from "armada-drmfb" to armadafb.
Signed-off-by: Daniel Vetter
Cc: Russell King
---
drivers/gpu/drm/armada/armada_fbdev.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
The fbdev split between fix and var information is kinda
pointless for drm drivers since everything is fixed: The fbdev
emulation doesn't support changing modes at all.
Create a new simplified helper and use it in the generic fbdev
helper code. Follow-up patches will beef it up more and roll
it
1 - 100 of 164 matches
Mail list logo
