On Wed, 2019-04-17 at 15:37 -0700, José Roberto de Souza wrote:
> A new macro that is going to be added in a further patch will need to
> adjust the offset returned by _MMIO_TRANS2(), so here adding
> _TRANS2() and moving most of the implementation of _MMIO_TRANS2() to
> it and while at it taking
== Series Details ==
Series: series starting with [v5,1/3] drm/i915/bdw+: Move misc display IRQ
handling to it own function
URL : https://patchwork.freedesktop.org/series/59787/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5964_full -> Patchwork_12853_full
== Series Details ==
Series: series starting with [v5,1/3] drm/i915/bdw+: Move misc display IRQ
handling to it own function
URL : https://patchwork.freedesktop.org/series/59787/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5964 -> Patchwork_12853
== Series Details ==
Series: series starting with [v5,1/3] drm/i915/bdw+: Move misc display IRQ
handling to it own function
URL : https://patchwork.freedesktop.org/series/59787/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/bdw+: Move misc
== Series Details ==
Series: series starting with [v5,1/3] drm/i915/bdw+: Move misc display IRQ
handling to it own function
URL : https://patchwork.freedesktop.org/series/59787/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c17cacf29b8b drm/i915/bdw+: Move misc display IRQ
A new macro that is going to be added in a further patch will need to
adjust the offset returned by _MMIO_TRANS2(), so here adding
_TRANS2() and moving most of the implementation of _MMIO_TRANS2() to
it and while at it taking the opportunity to rename pipe to trans.
Cc: Rodrigo Vivi
Cc:
PSR registers are a mess, some have the full address while others just
have the additional offset from psr_mmio_base.
For BDW+ psr_mmio_base is nothing more than TRANSCODER_EDP_OFFSET +
0x800 and using it makes more difficult for people with an PSR
register address or PSR register name from from
Just moving it to reduce the tabs and avoid break code lines.
No behavior changes intended here.
v2:
- Reading misc display IRQ outside of gen8_de_misc_irq_handler() as
other irq handlers (Dhinakaran)
Cc: Dhinakaran Pandiyan
Reviewed-by: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
On Thu, Apr 18, 2019 at 1:54 PM Thomas Gleixner wrote:
>
> On Thu, 18 Apr 2019, Alexander Potapenko wrote:
> > On Thu, Apr 18, 2019 at 11:06 AM Thomas Gleixner wrote:
> > > - save_stack_trace(>stack_trace);
> > > + b->stack_len = stack_trace_save(b->stack_entries, MAX_STACK, 2);
> >
On Thu, Apr 18, 2019 at 10:41:27AM +0200, Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace by using the storage
> array based interfaces.
>
> Signed-off-by: Thomas Gleixner
> Cc: Catalin Marinas
> Cc: linux...@kvack.org
Acked-by: Catalin Marinas
On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote:
> All architectures which support stacktrace carry duplicated code and
> do the stack storage and filtering at the architecture side.
>
> Provide a consolidated interface with a callback function for consuming the
> stack entries
On Thu, Apr 18, 2019 at 11:06 AM Thomas Gleixner wrote:
>
> Replace the indirection through struct stack_trace with an invocation of
> the storage array based interface.
>
> Signed-off-by: Thomas Gleixner
> Cc: dm-de...@redhat.com
> Cc: Mike Snitzer
> Cc: Alasdair Kergon
> ---
>
On Thu, Apr 18, 2019 at 10:41:22AM +0200, Thomas Gleixner wrote:
> The struct stack_trace indirection in the stack depot functions is a truly
> pointless excercise which requires horrible code at the callsites.
>
> Provide interfaces based on plain storage arrays.
>
> Signed-off-by: Thomas
On 2019/04/17, Emil Velikov wrote:
> On 2019/04/17, Christian König wrote:
> > This is to work around problems with libva and vainfo.
> >
> This part reverts a commit from 2013. Something I would wager that will cause
> multiple problems across the board.
>
> If we look at the intel libva driver
On 2019/04/17, Christian König wrote:
> This is to work around problems with libva and vainfo.
>
This part reverts a commit from 2013. Something I would wager that will cause
multiple problems across the board.
If we look at the intel libva driver in particular, as-is this will cause all
get
Hi William,
Sorry for the late reply.
> > Currently, there are 3 different macros, namely sizeof_field, SIZEOF_FIELD
> > and FIELD_SIZEOF which are used to calculate the size of a member of
> > structure, so to bring uniformity in entire kernel source tree lets use
> > FIELD_SIZEOF and replace
On 4/18/2019 4:36 PM, Colin King wrote:
From: Colin Ian King
There is a spelling mistake in a gvt_dbg_core debug message. Fix it.
Signed-off-by: Colin Ian King
Reviewed-by: Mukesh Ojha
Cheers,
-Mukesh
---
drivers/gpu/drm/i915/gvt/vgpu.c | 2 +-
1 file changed, 1 insertion(+), 1
Den 20.04.2019 12.45, skrev Noralf Trønnes:
> This moves the modesetting code from drm_fb_helper to drm_client so it
> can be shared by all internal clients.
>
> Changes this time:
> - Use full drm_client_init/release for the modesets (Daniel Vetter)
> - drm_client_for_each_modeset: use
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: c5fdcd8bd5c596bfc70b6be93e6f04d910c51308
commit: c5fdcd8bd5c596bfc70b6be93e6f04d910c51308 [9/9] drm-tip:
2019y-04m-19d-20h-56m-16s UTC integration manifest
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc
== Series Details ==
Series: drm: Fire off KMS hotplug events if probe detect says the connector is
connected (rev3)
URL : https://patchwork.freedesktop.org/series/59691/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5964 -> Patchwork_12852
== Series Details ==
Series: drm: Fire off KMS hotplug events if probe detect says the connector is
connected (rev3)
URL : https://patchwork.freedesktop.org/series/59691/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
56fec13ce383 drm: Fire off KMS hotplug events if probe
The hotplug detection routine of drm_helper_hpd_irq_event() can detect
changing of status of connector, but it can not detect changing of
properties of the connector.
e.g. changing of edid while suspend/resume, changing of dp lanes in dp aux.
Following scenario explains one of them; A detection
On Thu, Apr 18, 2019 at 7:33 PM Jani Nikula wrote:
>
> On Thu, 18 Apr 2019, Gwan-gyeong Mun wrote:
> > The hotplug detection routine of drm_helper_hpd_irq_event() can detect
> > changing of status of connector, but it can not detect changing of
> > properties of the connector.
> > e.g. changing
== Series Details ==
Series: drm/i915: Start writeback from the shrinker (rev2)
URL : https://patchwork.freedesktop.org/series/25332/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5963_full -> Patchwork_12851_full
Summary
== Series Details ==
Series: drm/i915: Start writeback from the shrinker (rev2)
URL : https://patchwork.freedesktop.org/series/25332/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5963 -> Patchwork_12851
Summary
---
== Series Details ==
Series: drm/fb-helper: Move modesetting code to drm_client (rev3)
URL : https://patchwork.freedesktop.org/series/58597/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5963_full -> Patchwork_12850_full
== Series Details ==
Series: drm/i915: Start writeback from the shrinker (rev2)
URL : https://patchwork.freedesktop.org/series/25332/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Start writeback from the shrinker
When we are called to relieve mempressue via the shrinker, the only way
we can make progress is either by discarding unwanted pages (those
objects that userspace has marked MADV_DONTNEED) or by reclaiming the
dirty objects via swap. As we know that is the only way to make further
progress, we can
== Series Details ==
Series: drm/fb-helper: Move modesetting code to drm_client (rev3)
URL : https://patchwork.freedesktop.org/series/58597/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5963 -> Patchwork_12850
Summary
== Series Details ==
Series: drm/fb-helper: Move modesetting code to drm_client (rev3)
URL : https://patchwork.freedesktop.org/series/58597/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
== Series Details ==
Series: drm/fb-helper: Move modesetting code to drm_client (rev3)
URL : https://patchwork.freedesktop.org/series/58597/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
caf4eff8b046 drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
3f7a665802ce
No functional changes, just moving code as-is and fixing includes.
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_client_modeset.c | 706 ++-
drivers/gpu/drm/drm_fb_helper.c | 691 --
An example to showcase the client API.
TODO:
A bootsplash client needs a way to tell drm_fb_helper to stay away,
otherwise it will chime in on setup and hotplug.
Most DRM drivers register fbdev before calling drm_dev_register() (the
generic emulation is an exception). This have to be reversed for
This moves the modesetting code from drm_fb_helper to drm_client so it
can be shared by all internal clients.
Changes this time:
- Use full drm_client_init/release for the modesets (Daniel Vetter)
- drm_client_for_each_modeset: use lockdep_assert_held (Daniel Vetter)
- Hook up to
Move the modeset commit code to drm_client_modeset.
No changes except exporting API.
v2: Move to drm_client_modeset.c instead of drm_client.c
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client_modeset.c | 287 +++
drivers/gpu/drm/drm_fb_helper.c | 282
The values are already present in the modeset.
This is done in preparation for the removal of struct drm_fb_helper_crtc.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 12
include/drm/drm_fb_helper.h
Prepare for moving drm_fb_helper modesetting code to drm_client.
drm_client will be linked to drm.ko, so move
__drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config()
out of drm_kms_helper.ko.
While at it, fix two checkpatch complaints:
- WARNING: Block comments use a trailing */
All drivers add all their connectors so there's no need to keep around an
array of available connectors.
Rename functions which signature is changed since they will be moved to
drm_client in a later patch.
Signed-off-by: Noralf Trønnes
---
Documentation/gpu/todo.rst | 3 +
drm_fb_helper_is_bound() is used to check if DRM userspace is in control.
This is done by looking at the fb on the primary plane. By the time
fb-helper gets around to committing, it's possible that the facts have
changed.
Avoid this race by holding the drm_device->master_mutex lock while
It now only contains the modeset so use that directly instead and attach
a modeset array to drm_client_dev. drm_fb_helper will use this array.
Code will later be moved to drm_client, so add code there in a new file
drm_client_modeset.c with MIT license to match drm_fb_helper.c.
The modeset
This prepares the modeset code so it can be moved out as-is in the next
patch.
v3: Remove stray newline
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 62 +++--
include/drm/drm_fb_helper.h | 4 ---
2 files
This makes the necessary changes so the commit code can be moved out to
drm_client as-is in the next patch. It's split up to ease review.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 122 +---
1 file changed, 81 insertions(+), 41 deletions(-)
Getting rotation info is cheap so we can do it on demand.
This is done in preparation for the removal of struct drm_fb_helper_crtc.
Cc: Hans de Goede
Signed-off-by: Noralf Trønnes
Acked-by: Daniel Vetter
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 131
Quoting Fernando Pacheco (2019-04-20 00:00:15)
> GPU reset is now available with GuC enabled,
> so re-enable our check that this reset is usable
> from atomic context.
>
> Signed-off-by: Fernando Pacheco
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx
Quoting Fernando Pacheco (2019-04-20 00:00:14)
> This reverts commit fe62365f9f80a1c1d438c54fba21f5108a182de8.
>
> Signed-off-by: Fernando Pacheco
Many thanks,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Quoting Fernando Pacheco (2019-04-20 00:00:13)
> Currently we pin the GuC or HuC firmware image just
> before uploading. Perma-pin during uC initialization
> instead and use the range reserved at the top of the
> address space.
>
> Moving the firmware resulted in needing to:
> - use an additional
Quoting Fernando Pacheco (2019-04-20 00:00:12)
> GuC and HuC depend on struct_mutex for device
> reinitialization. Moving away from this dependency
> requires perma-pinning the firmware images in GGTT.
> The upper portion of the GuC address space has
> a sizeable hole (several MB) that is
Quoting Fernando Pacheco (2019-04-20 00:00:11)
> The uC firmware init function is called during
> GuC/HuC init early phases. Rename to include "_early"
> and properly reflect which phase we are at.
>
> The uC firmware fini function is cleaning up the
> state set/created on firmware fetch. Replace
48 matches
Mail list logo
