On Wed, Feb 09, 2022 at 01:47:01AM +, Kasireddy, Vivek wrote:
> Hi Ville,
>
> >
> > On Tue, Feb 08, 2022 at 05:10:42AM +, Kasireddy, Vivek wrote:
> > > Hi Tvrtko, Ville,
> > >
> > > > On 07/02/2022 13:24, Ville Syrjälä wrote:
> > > > > On Mon, Feb 07, 2022 at 11:47:16AM +, Tvrtko
A cover letter with the changelog, the base and maybe a pointer to a git
tree would be nice.
> +static int handle_mmio_cb(struct intel_gvt_mmio_table_iter *iter, u32 offset,
> + u32 device, u32 size)
> +{
> + if (size < 1024 || offset ==
On Tue, Feb 08, 2022 at 06:11:51AM -0500, Zhi Wang wrote:
> The code of saving initial HW state snapshot has been moved into i915.
> Let the GVT-g core logic use that snapshot.
Looks good:
Reviewed-by: Christoph Hellwig
On Tue, Feb 08, 2022 at 06:11:50AM -0500, Zhi Wang wrote:
> + struct drm_i915_private *dev_priv = iter->i915;
> + u32 *mmio, i;
> +
> + for (i = offset; i < offset + size; i += 4) {
> + mmio = iter->data + i;
> + *mmio =
On Tue, Feb 08, 2022 at 05:15:00PM +0200, Jani Nikula wrote:
> > #ifdef CONFIG_DRM_I915_GVT
> > +
> > +#define D_BDW (1 << 0)
> > +#define D_SKL (1 << 1)
> > +#define D_KBL (1 << 2)
> > +#define D_BXT (1 << 3)
> > +#define D_CFL (1 << 4)
> > +
> > +#define D_GEN9PLUS (D_SKL
== Series Details ==
Series: Use drm_clflush* instead of clflush (rev6)
URL : https://patchwork.freedesktop.org/series/99450/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11205 -> Patchwork_22218
Summary
---
On Tue, Feb 08, 2022 at 05:15:02PM -0800, Daniele Ceraolo Spurio wrote:
On 2/7/2022 11:01 PM, Lucas De Marchi wrote:
The ADS initialitazion was using 2 passes to calculate the regset sent
to GuC to initialize each engine: the first pass to just have the final
object size and the second to set
On Mon, Feb 07, 2022 at 12:36:42PM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
First release of GuC for DG2.
Signed-off-by: John Harrison
CC: Tomasz Mistat
CC: Ramalingam C
CC: Daniele Ceraolo Spurio
Reviewed-by: Lucas De Marchi
Lucas De Marchi
---
== Series Details ==
Series: More GT register cleanup
URL : https://patchwork.freedesktop.org/series/99872/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11205_full -> Patchwork_22217_full
Summary
---
**FAILURE**
== Series Details ==
Series: Use drm_clflush* instead of clflush (rev6)
URL : https://patchwork.freedesktop.org/series/99450/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Use drm_clflush* instead of clflush (rev6)
URL : https://patchwork.freedesktop.org/series/99450/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
46bf608d395e drm: Add arch arm64 for drm_clflush_virt_range
-:24: WARNING:INCLUDE_LINUX: Use #include
On Wed, Feb 09, 2022 at 07:23:04AM +0100, Thomas Zimmermann wrote:
Hi
Am 08.02.22 um 11:45 schrieb Lucas De Marchi:
First the simplest ones:
- iosys_map_memset(): when abstracting system and I/O memory,
just like the memcpy() use case, memset() also has dedicated
Use drm_clflush_virt_range instead of directly invoking clflush. This
will prevent compiler errors when building for non-x86 architectures.
v2(Michael Cheng): Remove extra clflush
v3(Michael Cheng): Remove memory barrier since drm_clflush_virt_range
takes care of it.
Replace all occurance of cache_clflush_range with
drm_clflush_virt_range. This will prevent compile errors on non-x86
platforms.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 12 ++--
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
Use drm_clflush_virt_range instead of clflushopt and remove the memory
barrier, since drm_clflush_virt_range takes care of that.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git
Drop invalidate_csb_entries and directly call drm_clflush_virt_range.
This allows for one less function call, and prevent complier errors when
building for non-x86 architectures.
v2(Michael Cheng): Drop invalidate_csb_entries function and directly
invoke drm_clflush_virt_range.
This patch series re-work a few i915 functions to use drm_clflush_virt_range
instead of calling clflush or clflushopt directly. This will prevent errors
when building for non-x86 architectures.
Re-work intel_write_status_page to use drm_clflush_virt_range. This
will prevent compiler errors when building for non-x86 architectures.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_engine.h | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git
Add arm64 support for drm_clflush_virt_range. dcache_clean_inval_poc
performs a flush by first performing a clean, follow by an invalidation
operation.
v2 (Michael Cheng): Use correct macro for cleaning and invalidation the
dcache.
Signed-off-by: Michael Cheng
---
Hi
Am 08.02.22 um 11:45 schrieb Lucas De Marchi:
First the simplest ones:
- iosys_map_memset(): when abstracting system and I/O memory,
just like the memcpy() use case, memset() also has dedicated
functions to be called for using IO memory.
-
Em Tue, 8 Feb 2022 02:45:08 -0800
Lucas De Marchi escreveu:
> First the simplest ones:
>
> - iosys_map_memset(): when abstracting system and I/O memory,
> just like the memcpy() use case, memset() also has dedicated
> functions to be called for using IO memory.
> -
== Series Details ==
Series: More GT register cleanup
URL : https://patchwork.freedesktop.org/series/99872/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11205 -> Patchwork_22217
Summary
---
**SUCCESS**
No
On 2/7/22 07:36, Tvrtko Ursulin wrote:
On 20/01/2022 22:16, Casey Bowman wrote:
In this RFC I would like to ask the community their thoughts
on how we can best handle splitting architecture-specific
calls.
I would like to address the following:
1. How do we want to split architecture
== Series Details ==
Series: More GT register cleanup
URL : https://patchwork.freedesktop.org/series/99872/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./include/linux/find.h:40:31: warning:
== Series Details ==
Series: More GT register cleanup
URL : https://patchwork.freedesktop.org/series/99872/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9a3768557554 drm/i915/gt: Drop duplicate register definition for VDBOX_CGCTL3F18
827feabcfa0f drm/i915/gt: Move SFC lock
We have both a parameterized RING_MI_MODE() macro and an RCS-specific
MI_MODE; drop the latter and use the former everywhere.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_regs.h | 6 ++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8
Switch all register offsets to use lowercase hex values for consistency.
Also strip any unnecessary leading 0's. For example, "_MMIO(0x0D08)"
becomes "_MMIO(0xd08)."
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 234
1 file changed, 117
The random order of register definitions we have today causes a lot of
confusion and unintentional duplication when new registers/bits are
added to the driver. Let's order the GT register file by MMIO offset
A couple duplicated/unused register definitions are dropped while doing
this re-order:
There's a lot of inconsistent spacing and indentation in our register
definitions. Let's clean things up a bit and follow some consistent
rules:
* "#define" always starts in column 0
* There's exactly one space between '#define' and the name of a
register.
* There's exactly three spaces
These SFC registers were defined in an usual way, taking an engine as a
parameter rather than an engine MMIO base offset. Let's adjust them to
match the style used by other per-engine registers and move them to
intel_engine_regs.h.
While doing this move, we can drop GEN12_HCP_SFC_FORCED_LOCK
Another collection of cleanup patches for intel_gt_regs.h to make it a
bit less painful to work with.
Cc: Jani Nikula
Matt Roper (6):
drm/i915/gt: Drop duplicate register definition for VDBOX_CGCTL3F18
drm/i915/gt: Move SFC lock bits to intel_engine_regs.h
drm/i915/gt: Use parameterized
Due to some mistaken merge conflict resolution, we wound up with a copy
of VDBOX_CGCTL3F18 in both intel_engine_regs.h and intel_gt_regs.h.
Since this is a per-engine register, referenced relative to an engine's
base offset, drop the copy from intel_gt_regs.h
Signed-off-by: Matt Roper
---
On 2/7/22 05:02, Jani Nikula wrote:
On Thu, 20 Jan 2022, Casey Bowman wrote:
In this RFC I would like to ask the community their thoughts
on how we can best handle splitting architecture-specific
calls.
I would like to address the following:
1. How do we want to split architecture calls?
On Tue, 2022-02-08 at 19:34 -0800, Matthew Brost wrote:
> On Tue, Feb 08, 2022 at 02:55:07PM -0800, Teres Alexis, Alan Previn wrote:
> > On Tue, 2022-02-08 at 14:18 -0800, Matthew Brost wrote:
> > > On Tue, Feb 08, 2022 at 11:38:13AM -0800, Teres Alexis, Alan Previn wrote:
> > > > Hi Matt, thank
On Tue, Feb 08, 2022 at 07:34:37PM -0800, Matthew Brost wrote:
> On Tue, Feb 08, 2022 at 02:55:07PM -0800, Teres Alexis, Alan Previn wrote:
> >
> > On Tue, 2022-02-08 at 14:18 -0800, Matthew Brost wrote:
> > > On Tue, Feb 08, 2022 at 11:38:13AM -0800, Teres Alexis, Alan Previn wrote:
> > > > Hi
On Tue, Feb 08, 2022 at 02:55:07PM -0800, Teres Alexis, Alan Previn wrote:
>
> On Tue, 2022-02-08 at 14:18 -0800, Matthew Brost wrote:
> > On Tue, Feb 08, 2022 at 11:38:13AM -0800, Teres Alexis, Alan Previn wrote:
> > > Hi Matt, thank you for taking the time to review the codes.
> > > Answering
> -Original Message-
> From: Łukasz Bartosik
> Sent: Tuesday, February 8, 2022 8:20 AM
> To: Jani Nikula ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> Tvrtko Ursulin
> Cc: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org; upstr...@semihalf.com; Ville Syrjälä
> ; Roper, Matthew D
>
== Series Details ==
Series: drm/i915/display/tgl+: Implement new PLL programming step
URL : https://patchwork.freedesktop.org/series/99867/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11205_full -> Patchwork_22216_full
Hi Ville,
>
> On Tue, Feb 08, 2022 at 05:10:42AM +, Kasireddy, Vivek wrote:
> > Hi Tvrtko, Ville,
> >
> > > On 07/02/2022 13:24, Ville Syrjälä wrote:
> > > > On Mon, Feb 07, 2022 at 11:47:16AM +, Tvrtko Ursulin wrote:
> > > >>
> > > >> On 07/02/2022 10:58, Ville Syrjälä wrote:
> > > >>>
== Series Details ==
Series: GuC HWCONFIG with documentation (rev3)
URL : https://patchwork.freedesktop.org/series/99787/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11205_full -> Patchwork_22214_full
Summary
---
On 2/7/2022 11:01 PM, Lucas De Marchi wrote:
The ADS initialitazion was using 2 passes to calculate the regset sent
to GuC to initialize each engine: the first pass to just have the final
object size and the second to set each register in place in the final
gem object.
However in order to
On 2/7/2022 11:01 PM, Lucas De Marchi wrote:
Currently guc_mmio_reg_add() relies on having enough memory available in
the array to add a new slot. It uses
`GEM_BUG_ON(count >= regset->size);` to protect going above the
threshold.
In order to allow guc_mmio_reg_add() to handle the memory
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
include/linux/dma-buf-map.h
between commit:
e8c1f36157ce ("dma-buf-map: Fix dot vs comma in example")
from the drm tree and commit:
7938f4218168 ("dma-buf-map: Rename to iosys-map")
from the drm-intel tree.
I
== Series Details ==
Series: discrete card 64K page support (rev6)
URL : https://patchwork.freedesktop.org/series/99119/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11205_full -> Patchwork_22213_full
Summary
---
== Series Details ==
Series: drm/i915/display/tgl+: Implement new PLL programming step
URL : https://patchwork.freedesktop.org/series/99867/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11205 -> Patchwork_22216
Summary
On 2/8/22 22:08, Daniel Vetter wrote:
> This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
>
> With
>
> commit 27599aacbaefcbf2af7b06b0029459bbf682000d
> Author: Thomas Zimmermann
> Date: Tue Jan 25 10:12:18 2022 +0100
>
> fbdev: Hot-unplug firmware fb devices on forced
Hello Daniel,
On 2/8/22 22:08, Daniel Vetter wrote:
> Allows us to delete a bunch of hand-rolled stuff. Also to simplify the
> code we initialize the cursor_work completely when we allocate the
> fbcon_ops structure, instead of trying to cope with console
> re-initialization.
>
Maybe also make
== Series Details ==
Series: drm/i915/display/tgl+: Implement new PLL programming step
URL : https://patchwork.freedesktop.org/series/99867/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915/display/tgl+: Implement new PLL programming step
URL : https://patchwork.freedesktop.org/series/99867/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2f56199b0301 drm/i915/display/tgl+: Implement new PLL programming step
-:50:
== Series Details ==
Series: fbcon patches, take two
URL : https://patchwork.freedesktop.org/series/99865/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11205 -> Patchwork_22215
Summary
---
**FAILURE**
Serious
== Series Details ==
Series: fbcon patches, take two
URL : https://patchwork.freedesktop.org/series/99865/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
It looks like for this series I forgot to Cc dri-devel, although these
patches are the same as the ones in
https://patchwork.freedesktop.org/series/99711/,
just extracted since not dependent on the iosys-map discussion.
Lucas De Marchi
On Mon, Feb 07, 2022 at 11:01:39PM -0800, Lucas De Marchi
== Series Details ==
Series: fbcon patches, take two
URL : https://patchwork.freedesktop.org/series/99865/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2d681145150e fbcon: delete a few unneeded forward decl
-:65: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email
== Series Details ==
Series: GuC HWCONFIG with documentation (rev3)
URL : https://patchwork.freedesktop.org/series/99787/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11205 -> Patchwork_22214
Summary
---
On Tue, Feb 08, 2022 at 02:45:09AM -0800, Lucas De Marchi wrote:
> Add a variant of shmem_read() that takes a iosys_map pointer rather
> than a plain pointer as argument. It's mostly a copy __shmem_rw() but
> adapting the api and removing the write support since there's currently
> only need to
On 2/8/22 22:08, Daniel Vetter wrote:
> Avoids two forward declarations, and more importantly, matches what
> I've done in my fbcon scrolling restore patches - so I need this to
> avoid a bunch of conflicts in rebasing since we ended up merging
> Helge's series instead.
>
> Signed-off-by: Daniel
On Tue, 2022-02-08 at 14:18 -0800, Matthew Brost wrote:
> On Tue, Feb 08, 2022 at 11:38:13AM -0800, Teres Alexis, Alan Previn wrote:
> > Hi Matt, thank you for taking the time to review the codes.
> > Answering your question inline below.
> >
> >
> > On Fri, 2022-02-04 at 10:19 -0800, Matthew
On Tue, Feb 08, 2022 at 02:45:08AM -0800, Lucas De Marchi wrote:
> First the simplest ones:
>
> - iosys_map_memset(): when abstracting system and I/O memory,
> just like the memcpy() use case, memset() also has dedicated
> functions to be called for using IO memory.
>
On 08.02.2022 22:05, Jordan Justen wrote:
> i915_drm.h now defines the format of the returned
> DRM_I915_QUERY_HWCONFIG_BLOB query item. Since i915 receives this from
> the black box GuC software, it should verify that the data matches
> that format before sending it to user-space.
>
> The
Tvrtko Ursulin writes:
> Will GuC folks be reviewing this work?
I don't know. If you mean the i915 devs interfacing with the GuC, I know
John/Rodrigo seemed a bit resistant writing the patches to give
userspace this trivial format guarantee on the blob.
So, I hoped they would write the patches
== Series Details ==
Series: GuC HWCONFIG with documentation (rev3)
URL : https://patchwork.freedesktop.org/series/99787/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: GuC HWCONFIG with documentation (rev3)
URL : https://patchwork.freedesktop.org/series/99787/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e77bdf7a8928 drm/i915/guc: Add fetch of hwconfig table
-:78: WARNING:FILE_PATH_CHANGES: added, moved or
== Series Details ==
Series: discrete card 64K page support (rev6)
URL : https://patchwork.freedesktop.org/series/99119/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11205 -> Patchwork_22213
Summary
---
**SUCCESS**
On Tue, Feb 08, 2022 at 11:38:13AM -0800, Teres Alexis, Alan Previn wrote:
> Hi Matt, thank you for taking the time to review the codes.
> Answering your question inline below.
>
>
> On Fri, 2022-02-04 at 10:19 -0800, Matthew Brost wrote:
> > On Wed, Jan 26, 2022 at 02:48:18AM -0800, Alan Previn
== Series Details ==
Series: discrete card 64K page support (rev6)
URL : https://patchwork.freedesktop.org/series/99119/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: discrete card 64K page support (rev6)
URL : https://patchwork.freedesktop.org/series/99119/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3661cc75d2f0 drm/i915: add needs_compact_pt flag
d28e89eb3a6f drm/i915: enforce min GTT alignment for discrete
Opened the issue at https://gitlab.freedesktop.org/drm/intel/-/issues/5077 ,
included dmesg + video. Feel free to let me know if you need any more info, or
need me to try any patches
On Tue, 2022-02-08 at 13:06 +, Souza, Jose wrote:
> On Mon, 2022-02-07 at 16:38 -0500, Lyude Paul wrote:
> >
On 08.02.2022 22:05, Jordan Justen wrote:
> From: John Harrison
>
> Implement support for fetching the hardware description table from the
> GuC. The call is made twice - once without a destination buffer to
> query the size and then a second time to fill in the buffer.
>
> Note that the
A new programming step was added to combo and TC PLL sequences.
If override_AFC_startup is set in VBT, driver should overwrite
AFC_startup value to 0x7 in PLL's div0 register.
The current understating is that only TGL needs this and all display
12 and newer platforms will have a older VBT or a
== Series Details ==
Series: drm/dp, drm/i915: 128b/132b updates (rev6)
URL : https://patchwork.freedesktop.org/series/99324/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11203_full -> Patchwork_22212_full
Summary
---
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
With
commit 27599aacbaefcbf2af7b06b0029459bbf682000d
Author: Thomas Zimmermann
Date: Tue Jan 25 10:12:18 2022 +0100
fbdev: Hot-unplug firmware fb devices on forced removal
this should be fixed properly and we can remove this
Ideally console_lock becomes an implementation detail of fbcon.c and
doesn't show up anywhere in fbmem.c. We're still pretty far from that,
but at least the register/unregister code is there now.
With this the do_fb_ioctl() handler is the only code in fbmem.c still
calling console_lock().
Well except when the olpc dcon fbdev driver is enabled, that thing
digs around in there in rather unfixable ways.
Cc oldc_dcon maintainers as fyi.
v2: I typoed the config name (0day)
Cc: kernel test robot
Cc: Jens Frederich
Cc: Jon Nettleton
Cc: Greg Kroah-Hartman
Cc:
There's a bunch of confusions going on here:
- The deferred fbcon setup notifier should only be cleaned up from
fb_console_exit(), to be symmetric with fb_console_init()
- We also need to make sure we don't race with the work, which means
temporarily dropping the console lock (or we can
Accessing the one in fbmem.c without taking the right locks is a bad
idea. Instead maintain our own private copy, which is fully protected
by console_lock() (like everything else in fbcon.c). That copy is
serialized through fbcon_fb_registered/unregistered() calls.
Also this means we do not need
con2fb_release_oldinfo() has a bunch more kfree() calls than
fbcon_exit(), but since kfree() on NULL is harmless doing that in both
places should be ok. This is also a bit more symmetric now again with
fbcon_open also allocating the fbcon_ops structure.
Acked-by: Sam Ravnborg
Signed-off-by:
Now we get to the real motiviation, because fbmem.c insists that
that's the right lock for these.
Ofc fbcon.c has a lot more places where it probably should call
lock_fb_info(). But looking at fbmem.c at least most of these seem to
be protected by console_lock() too, which is probably what papers
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong thing. But it's confusing, so fix it by moving it a tad
later.
Acked-by: Sam
No idea why con2fb_acquire_newinfo() initializes much less than
fbcon_startup(), but so be it. From a quick look most of the
un-initialized stuff should be fairly harmless, but who knows.
Note that the error handling for the con2fb_acquire_newinfo() failure
case was very strange: Callers updated
It doesn't ever fail anymore.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Greg Kroah-Hartman
Cc: Claudio Suarez
Cc: Du Cheng
Cc: Tetsuo Handa
---
drivers/video/fbdev/core/fbcon.c | 37 +++-
1 file changed, 13
There's two minor behaviour changes in here:
- in error paths we now consistently call fb_ops->fb_release
- fb_release really can't fail (fbmem.c ignores it too) and there's no
reasonable cleanup we can do anyway.
Note that everything in fbcon.c is protected by the big console_lock()
lock
It's only one flag and slightly tidier code.
Acked-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Tetsuo Handa
Cc: Greg Kroah-Hartman
Cc: Du Cheng
Cc: Thomas Zimmermann
Cc: Claudio Suarez
---
drivers/video/fbdev/core/fbcon.c | 11
Allows us to delete a bunch of hand-rolled stuff. Also to simplify the
code we initialize the cursor_work completely when we allocate the
fbcon_ops structure, instead of trying to cope with console
re-initialization.
The motiviation here is that fbcon code stops using the fb_info.queue,
which
It was only used by fbcon, and that now switched to its own,
private work.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
---
include/linux/fb.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
fb_set_var requires we hold the fb_info lock. Or at least this now
matches what the ioctl does ...
Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here,
but I will not fix them up.
Also in practice this isn't a big deal, because really variable fbdev
state is actually protected
Before
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
it was possible to load fbcon and fbdev drivers in any order, which
means that fbcon init had to handle the case where fbdev
Half of it is protected by console_lock, but the other half is a lot
more awkward: Registration/deregistration of fbdev are serialized, but
we don't really clear out anything in con2fb_map and so there's
potential for use-after free mixups.
First step is to encapsulate the lookup.
Acked-by: Sam
I didn't bother with any code movement to fix the others, these just
got a bit in the way.
v2: Rebase on top of Helge's reverts.
Acked-by: Sam Ravnborg (v1)
Reviewed-by: Geert Uytterhoeven (v1)
Signed-off-by: Daniel Vetter
Cc: Helge Deller
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Du
Avoids two forward declarations, and more importantly, matches what
I've done in my fbcon scrolling restore patches - so I need this to
avoid a bunch of conflicts in rebasing since we ended up merging
Helge's series instead.
Signed-off-by: Daniel Vetter
Cc: Helge Deller
Cc: Daniel Vetter
Cc:
Hi all,
Second round, mostly just compile fixed and some minor polish to commit
messages. Also MAINTAINERS patch and fbcon scrolling patches are out
because they landed already.
There's still a handful here that need review (and somehow intel-gfx-ci
just keeled over on this).
Cheers, Daniel
On 24/11/2021 18:07, Zbigniew Kempczyński wrote:
On Wed, Nov 24, 2021 at 08:45:50AM +, Tvrtko Ursulin wrote:
On 24/11/2021 08:04, Zbigniew Kempczyński wrote:
On Tue, Nov 23, 2021 at 09:49:04AM +, Tvrtko Ursulin wrote:
On 22/11/2021 19:13, Zbigniew Kempczyński wrote:
In short -
i915_drm.h now defines the format of the returned
DRM_I915_QUERY_HWCONFIG_BLOB query item. Since i915 receives this from
the black box GuC software, it should verify that the data matches
that format before sending it to user-space.
The verification makes a single simple pass through the blob
Also, document DRM_I915_QUERY_HWCONFIG_BLOB with this struct.
v3:
* Add various changes suggested by Tvrtko
Cc: Daniel Vetter
Signed-off-by: Jordan Justen
---
include/uapi/drm/i915_drm.h | 32
1 file changed, 32 insertions(+)
diff --git
From: Rodrigo Vivi
The DRM_I915_QUERY_HWCONFIG_BLOB query item returns a blob of data
which it receives from the GuC software. This blob provides some
useful data about the hardware for drivers.
Although the blob is not fully documented at this time, the basic
format is an array of u32 values.
From: John Harrison
Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a destination buffer to
query the size and then a second time to fill in the buffer.
Note that the table is only available on ADL-P and later platforms.
Cc:
This is John/Rodrigo's 2 patches with some minor changes, and I added
2 patches.
"drm/i915/uapi: Add query for hwconfig blob" was changed:
* Rename DRM_I915_QUERY_HWCONFIG_TABLE to DRM_I915_QUERY_HWCONFIG_BLOB
as requested by Joonas.
* Reword commit message
* I added Acked-by to this
On Tue, Feb 08, 2022 at 03:04:51PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 09:30:56AM +0100, Geert Uytterhoeven wrote:
> > Hi Daniel,
> >
> > Thanks for your patch!
> >
> > On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter wrote:
> > > Well except when the olpc dcon fbdev driver is
On Tue, Feb 08, 2022 at 08:00:38PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:52PM +0100, Daniel Vetter wrote:
> > Well except when the olpc dcon fbdev driver is enabled, that thing
> > digs around in there in rather unfixable ways.
> >
> > Cc oldc_dcon maintainers
On Tue, Feb 08, 2022 at 10:31:10AM +, Tvrtko Ursulin wrote:
On 02/02/2022 16:26, Lucas De Marchi wrote:
On Wed, Feb 02, 2022 at 10:26:46AM +, Tvrtko Ursulin wrote:
On 01/02/2022 17:28, Lucas De Marchi wrote:
On Tue, Feb 01, 2022 at 07:09:14PM +0200, Jani Nikula wrote:
On Tue, 01
add test to check handling of misaligned offsets and sizes
v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot
v6:
* use NEEDS_COMPACT_PT instead of hard coding for DG2
v7:
* use
1 - 100 of 280 matches
Mail list logo
