On Thu, Jan 26, 2023 at 01:49:12AM +0100, Samuel Thibault wrote:
> blit_x and blit_y are uint32_t, so fbcon currently cannot support fonts
> larger than 32x32.
"u32" you mean, right?
> The 32x32 case also needs shifting an unsigned int, to properly set bit
> 31, otherwise we get "UBSAN: shift-out
Am 26.01.23 um 01:28 schrieb Danilo Krummrich:
In dma_fence_allocate_private_stub() set the signaling bit of the newly
allocated private stub fence rather than the signaling bit of the
shared dma_fence_stub.
Fixes: c85d00d4fd8b ("dma-buf: set signaling bit for the stub fence")
Signed-off-by: Dan
Hi Jagan Teki,
> -Original Message-
> From: Jagan Teki
> Sent: Friday, January 20, 2023 3:19 AM
> To: 대인기/Tizen Platform Lab(SR)/삼성전자
> Cc: Marek Szyprowski ; Seung-Woo Kim
> ; Kyungmin Park ; Neil
> Armstrong ; Robert Foss ;
> Andrzej Hajda ; Sam Ravnborg ;
> thierry.red...@gmail.com; M
vicetree/bindings/display/bridge/ti,tfp410.example.dtb] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:1508: dt_binding_check] Error 2
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230125-tfp410_i2c-v1-1-66a
On Wed, 2023-01-25 at 14:56 +0100, Marek Vasut wrote:
> On 1/25/23 07:40, Liu Ying wrote:
> > A valid bridge is already found in lcdif_attach_bridge() and set
> > to lcdif->bridge, so lcdif->bridge cannot be a NULL pointer. Drop
> > the unnecessary NULL pointer check in KMS stage.
>
> Is it possib
On Tue, Jan 24, 2023 at 7:57 PM Harry Wentland wrote:
>
>
>
> On 1/24/23 10:37, Harry Wentland wrote:
> >
> >
> > On 1/23/23 15:30, Sebastian Wick wrote:
> >> A new property to control YCC and subsampling would be the more
> >> complete path here. If we actually want to fix this in the short-term
在 2023/1/21 23:03, Jason Gunthorpe 写道:
I would like to have a session at LSF to talk about Matthew's
physr discussion starter:
https://lore.kernel.org/linux-mm/ydykweu0htv8m...@casper.infradead.org/
I have become interested in this with some immediacy because of
IOMMUFD and this other discuss
On Wed, Jan 25, 2023 at 2:00 PM Joshua Ashton wrote:
>
>
>
> On 1/23/23 20:30, Sebastian Wick wrote:
> > A new property to control YCC and subsampling would be the more
> > complete path here. If we actually want to fix this in the short-term
> > though, we should handle the YCC and RGB Colorspace
From: John Harrison
The debugfs dump of requests was confused about what state requires
the execlist lock versus the GuC lock. There was also a bunch of
duplicated messy code between it and the error capture code.
So refactor the hung request search into a re-usable function. And
reduce the span
From: John Harrison
For understanding bug reports, it can be useful to have an explicit
dmesg print when a reset notification is received from GuC. As opposed
to simply inferring that this happened from other messages.
Signed-off-by: John Harrison
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/d
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active r
From: John Harrison
The GuC specific register state entry in the error capture object was
just called 'capture'. Although the companion 'node' entry was called
'guc_capture_node'. Rename the base entry to be 'guc_capture' instead
so that it is a) more consistent and b) more obvious what it is.
S
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown reasons that normally come down to a missing
w/a), it is useful to get as much information out of the system as
possible. Given that the GuC intentionally dies on such a situation,
it is no
From: John Harrison
intel_guc_find_hung_context() was not acquiring the correct spinlock
before searching the request list. So fix that up. While at it, add
some extra whitespace padding for readability.
Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU reset
with GuC")
C
From: John Harrison
When GuC support was added to error capture, the locking around the
request object was broken. Fix it up.
The context based search manages the spinlocking around the search
internally. So it needs to grab the reference count internally as
well. The execlist only request based
From: John Harrison
A hang situation has been observed where the only requests on the
context were either completed or not yet started according to the
breaadcrumbs. However, the register state claimed a batch was (maybe)
in progress. So, allow capture of the pending request on the grounds
that t
From: John Harrison
It is technically possible to get a hung context without a valid
request. In such a situation, try to provide as much information in
the error capture as possible rather than just aborting and capturing
nothing.
Similarly, in the case of an engine reset failure the GuC is not
In dma_fence_allocate_private_stub() set the signaling bit of the newly
allocated private stub fence rather than the signaling bit of the
shared dma_fence_stub.
Fixes: c85d00d4fd8b ("dma-buf: set signaling bit for the stub fence")
Signed-off-by: Danilo Krummrich
---
drivers/dma-buf/dma-fence.c |
On 1/18/2023 5:00 AM, Dmitry Baryshkov wrote:
Move a call to dsi_calc_pclk() out of calc_clk_rate directly towards
msm_dsi_host_get_phy_clk_req(). It is called for both 6g and v2 hosts.
Also, while we are at it, replace another dsi_get_pclk_rate() invocation
with using the stored value at msm
On 1/24/2023 10:46 PM, Dmitry Baryshkov wrote:
Hi,
On Wed, 25 Jan 2023 at 02:22, Abhinav Kumar wrote:
On 1/24/2023 12:22 AM, Dmitry Baryshkov wrote:
On 24/01/2023 03:32, Abhinav Kumar wrote:
On 1/22/2023 11:11 PM, Dmitry Baryshkov wrote:
QCM2290 doesn't seem to support reg-dma, smart-dma
On Wed, Jan 25, 2023 at 03:41:58PM -0800, Matt Roper wrote:
> Workaround Wa_18018781329 has applied to several recent Xe_HP-based
> platforms. However there are some extra gotchas to implementing this
> properly for MTL that we need to take into account:
>
> * Due to the separation of media and
GAMSTLB_CTRL and GAMCNTRL_CTRL became multicast/replicated registers on
Xe_HP. They should be defined accordingly and use MCR-aware operations.
These registers have only been used for some dg2/xehpsdv workarounds, so
this fix is mostly just for consistency/future-proofing; even lacking
the MCR an
Workaround Wa_18018781329 has applied to several recent Xe_HP-based
platforms. However there are some extra gotchas to implementing this
properly for MTL that we need to take into account:
* Due to the separation of media and render/compute into separate GTs,
this workaround needs to be imple
Register reset characteristics (i.e., whether the register maintains or
loses its value on engine reset) is an important factor that determines
which wa_list we want to add workarounds to. We recently found out that
the bspec documentation for the Xe_HP's "GAM" registers in the 0xC800 -
0xCFFF ran
On 1/25/2023 10:21 AM, Doug Anderson wrote:
Hi,
On Wed, Jan 25, 2023 at 9:22 AM Kuogee Hsieh wrote:
-void dp_ctrl_isr(struct dp_ctrl *dp_ctrl)
+irqreturn_t dp_ctrl_isr(struct dp_ctrl *dp_ctrl)
{
struct dp_ctrl_private *ctrl;
u32 isr;
+ irqreturn_t ret = IRQ_NONE;
On 1/24/23 15:14, T.J. Mercier wrote:
On Mon, Jan 23, 2023 at 11:49 PM Christian König
wrote:
Am 24.01.23 um 04:56 schrieb James Jones:
On 1/23/23 08:58, Laurent Pinchart wrote:
Hi Christian,
On Mon, Jan 23, 2023 at 05:29:18PM +0100, Christian König wrote:
Am 23.01.23 um 14:55 schrieb Laur
Hello Thomas and Gerd,
On 1/9/23 00:04, Dmitry Osipenko wrote:
> This series:
>
> 1. Makes minor fixes for drm_gem_lru and Panfrost
> 2. Brings refactoring for older code
> 3. Adds common drm-shmem memory shrinker
> 4. Enables shrinker for VirtIO-GPU driver
> 5. Switches Panfrost driver
'memory-region' is a common property and already has a type.
Signed-off-by: Rob Herring
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml
b/Documentation/devicetre
On 1/23/2023 09:51, Tvrtko Ursulin wrote:
On 20/01/2023 23:28, john.c.harri...@intel.com wrote:
From: John Harrison
-struct i915_request *intel_context_find_active_request(struct
intel_context *ce)
+struct i915_request *intel_context_find_active_request_get(struct
intel_context *ce)
TB
Hi Dave, Daniel,
Fixes for 6.2. This contains a fix for DP MST that avoids the big revert.
There are still some corner cases, but it fixes things for most users.
The following changes since commit 3f30a6e67ce49c0068f8058893326db46b6db11f:
Merge tag 'amd-drm-fixes-6.2-2023-01-19' of
https://g
On Wed, Jan 25, 2023 at 4:24 PM Laurent Pinchart
wrote:
>
> Hi Jonathan,
>
> Thank you for the patch.
>
> On Wed, Jan 25, 2023 at 04:09:09PM -0500, Jonathan Cormier wrote:
> > Add a i2c example with HDMI connector
> >
> > Signed-off-by: Jonathan Cormier
> > ---
> > .../bindings/display/bridge/ti
On 1/25/23 20:24, Jagan Teki wrote:
On Wed, Jan 25, 2023 at 11:33 PM Marek Vasut wrote:
On 1/25/23 18:35, Jagan Teki wrote:
[...]
exynos_dsi_register_te_irq is done after the bridge attach is done in
Exynos, here bridge attach is triggered in the component ops bind
call, since samsung-dsim
Reviewed-by: Lyude Paul
Will push upstream in a moment
On Wed, 2023-01-25 at 20:37 +0530, Deepak R Varma wrote:
> The current design of callback function disable() of struct
> nvkm_devinit_func is defined to return a u64 value. In its implementation
> in the driver modules, the function always r
On Wed, Jan 25, 2023 at 04:43:29PM -0300, Gustavo Sousa wrote:
> On Tue, Jan 24, 2023 at 05:14:06PM -0800, Matt Roper wrote:
> > Register reset characteristics (i.e., whether the register maintains or
> > loses its value on engine reset) is an important factor that determines
> > which wa_list we w
Hi Jonathan,
Thank you for the patch.
On Wed, Jan 25, 2023 at 04:09:09PM -0500, Jonathan Cormier wrote:
> Add a i2c example with HDMI connector
>
> Signed-off-by: Jonathan Cormier
> ---
> .../bindings/display/bridge/ti,tfp410.yaml | 42
> ++
> 1 file changed, 42 in
From: Michael Williamson
If the I2C bus is connected on the TFP410, then use the register
status bit to determine connection state. This is needed, in particular,
for polling the state when the Hot Plug detect is not connected to
a controlling CPU via GPIO/IRQ lane.
Signed-off-by: Michael Willi
Add a i2c example with HDMI connector
Signed-off-by: Jonathan Cormier
---
.../bindings/display/bridge/ti,tfp410.yaml | 42 ++
1 file changed, 42 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
b/Documentation/devicetree/bin
mmap_assert_write_locked() is used in vm_flags modifiers. Because
mmap_assert_write_locked() uses dump_mm() and vm_flags are sometimes
modified from from inside a module, it's necessary to export
dump_mm() function.
Signed-off-by: Suren Baghdasaryan
---
mm/debug.c | 1 +
1 file changed, 1 insert
Sorry! I've been pretty busy until now, this is:
Reviewed-by: Lyude Paul
Let me know if you've pushed it already or if you want me to push it to drm-
misc
On Wed, 2023-01-25 at 12:15 -0800, Kees Cook wrote:
> Ping. I'll take this via my tree unless someone else wants to take it...
>
> On Sun,
Replace direct modifications to vma->vm_flags with calls to modifier
functions to be able to track flag changes and to keep vma locking
correctness.
Signed-off-by: Suren Baghdasaryan
---
arch/arm/kernel/process.c | 2 +-
arch/ia64/mm/init.c
/ti-tfp410.c | 110 +++--
2 files changed, 124 insertions(+), 28 deletions(-)
---
base-commit: 93f875a8526a291005e7f38478079526c843cbec
change-id: 20230125-tfp410_i2c-3b270b0bf3e0
Best regards,
--
Jonathan Cormier
On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 2d6d790d9bed..6c7c70bf50dd 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -491,7 +491,13 @@ struct vm_area_struct {
>
On Wed 25-01-23 00:38:51, Suren Baghdasaryan wrote:
> mmap_assert_write_locked() is used in vm_flags modifiers. Because
> mmap_assert_write_locked() uses dump_mm() and vm_flags are sometimes
> modified from from inside a module, it's necessary to export
> dump_mm() function.
>
> Signed-off-by: Sur
On Wed 25-01-23 00:38:47, Suren Baghdasaryan wrote:
> To simplify the usage of VM_LOCKED_CLEAR_MASK in clear_vm_flags(),
> replace it with VM_LOCKED_MASK bitmask and convert all users.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Michal Hocko
> ---
> include/linux/mm.h | 4 ++--
> kernel/fo
This patchset was originally published as a part of per-VMA locking [1] and
was split after suggestion that it's viable on its own and to facilitate
the review process. It is now a preprequisite for the next version of per-VMA
lock patchset, which reuses vm_flags modifier functions to lock the VMA
On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> +/* Use when VMA is not part of the VMA tree and needs no locking */
> +static inline void init_vm_flags(struct vm_area_struct *vma,
> + unsigned long flags)
> +{
> + vma->vm_flags = flags;
vm_fl
From: Michael Williamson
The TFP410 driver does not support I2C. As such, the device remains in
Power Down if the I2C is enabled by the bootstrap pins.
Add basic support for the I2C interface, and provide support to take
the device out of power down when enabled. Also read the bootstrap mode
p
Replace indirect modifications to vma->vm_flags with calls to modifier
functions to be able to track flag changes and to keep vma locking
correctness. Add a BUG_ON check in ksm_madvise() to catch indirect
vm_flags modification attempts.
Signed-off-by: Suren Baghdasaryan
---
arch/powerpc/kvm/book
On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote:
> Replace indirect modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness. Add a BUG_ON check in ksm_madvise() to catch indirect
> vm_flags modification attempts.
T
On Wed, Jan 25, 2023 at 1:42 AM Michal Hocko wrote:
>
> On Wed 25-01-23 00:38:50, Suren Baghdasaryan wrote:
> > In cases when VMA flags are modified after VMA was isolated and mmap_lock
> > was downgraded, flags modifications would result in an assertion because
> > mmap write lock is not held.
>
On Wed, Jan 25, 2023 at 10:37 AM Matthew Wilcox wrote:
>
> On Wed, Jan 25, 2023 at 08:49:50AM -0800, Suren Baghdasaryan wrote:
> > On Wed, Jan 25, 2023 at 1:10 AM Peter Zijlstra wrote:
> > > > + /*
> > > > + * Flags, see mm.h.
> > > > + * WARNING! Do not modify directly.
> > > > +
To simplify the usage of VM_LOCKED_CLEAR_MASK in clear_vm_flags(),
replace it with VM_LOCKED_MASK bitmask and convert all users.
Signed-off-by: Suren Baghdasaryan
---
include/linux/mm.h | 4 ++--
kernel/fork.c | 2 +-
mm/hugetlb.c | 4 ++--
mm/mlock.c | 6 +++---
mm/mmap.c
On Wed, Jan 25, 2023 at 1:30 AM 'Michal Hocko' via kernel-team
wrote:
>
> On Wed 25-01-23 00:38:48, Suren Baghdasaryan wrote:
> > Replace direct modifications to vma->vm_flags with calls to modifier
> > functions to be able to track flag changes and to keep vma locking
> > correctness.
>
> Is this
On Wed, Jan 25, 2023 at 10:33 AM Matthew Wilcox wrote:
>
> On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> > +/* Use when VMA is not part of the VMA tree and needs no locking */
> > +static inline void init_vm_flags(struct vm_area_struct *vma,
> > +
vm_flags are among VMA attributes which affect decisions like VMA merging
and splitting. Therefore all vm_flags modifications are performed after
taking exclusive mmap_lock to prevent vm_flags updates racing with such
operations. Introduce modifier functions for vm_flags to be used whenever
flags a
On Wed, Jan 25, 2023 at 1:10 AM Peter Zijlstra wrote:
>
> On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
>
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 2d6d790d9bed..6c7c70bf50dd 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linu
On Wed, Jan 25, 2023 at 08:49:50AM -0800, Suren Baghdasaryan wrote:
> On Wed, Jan 25, 2023 at 1:10 AM Peter Zijlstra wrote:
> > > + /*
> > > + * Flags, see mm.h.
> > > + * WARNING! Do not modify directly.
> > > + * Use {init|reset|set|clear|mod}_vm_flags() functions instead.
> >
On Mon, 23 Jan 2023 17:51:25 +0800,
Hi Greg,
Sorry for my late reply.
Greg Kroah-Hartman wrote:
>
> On Mon, Jan 23, 2023 at 03:32:25PM +0800, Li Chen wrote:
> > This driver add support for Ambarella's uart, which
> > can be used for console and etc.
> >
> > Signed-off-by: Li Chen
> > Change-I
On Wed 25-01-23 00:38:46, Suren Baghdasaryan wrote:
> vm_flags are among VMA attributes which affect decisions like VMA merging
> and splitting. Therefore all vm_flags modifications are performed after
> taking exclusive mmap_lock to prevent vm_flags updates racing with such
> operations. Introduce
On Wed 25-01-23 00:38:48, Suren Baghdasaryan wrote:
> Replace direct modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness.
Is this a manual (git grep) based work or have you used Coccinele for
the patch generation?
On Wed 25-01-23 00:38:50, Suren Baghdasaryan wrote:
> In cases when VMA flags are modified after VMA was isolated and mmap_lock
> was downgraded, flags modifications would result in an assertion because
> mmap write lock is not held.
> Introduce mod_vm_flags_nolock to be used in such situation.
> P
From: Michael Williamson
The logic to configure polling (vs async/irq notification) of hot-plug
events was not correct. If the connected bridge requires polling,
then inform the upstream bridge we also require polling.
Signed-off-by: Michael Williamson
Signed-off-by: Jonathan Cormier
---
dri
In cases when VMA flags are modified after VMA was isolated and mmap_lock
was downgraded, flags modifications would result in an assertion because
mmap write lock is not held.
Introduce mod_vm_flags_nolock to be used in such situation.
Pass a hint to untrack_pfn to conditionally use mod_vm_flags_no
On Wed, Jan 25, 2023 at 9:08 AM Michal Hocko wrote:
>
> On Wed 25-01-23 08:57:48, Suren Baghdasaryan wrote:
> > On Wed, Jan 25, 2023 at 1:38 AM 'Michal Hocko' via kernel-team
> > wrote:
> > >
> > > On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote:
> > > > Replace indirect modifications to vma->
On Wed, Jan 25, 2023 at 1:38 AM 'Michal Hocko' via kernel-team
wrote:
>
> On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote:
> > Replace indirect modifications to vma->vm_flags with calls to modifier
> > functions to be able to track flag changes and to keep vma locking
> > correctness. Add a BUG
On Wed 25-01-23 08:57:48, Suren Baghdasaryan wrote:
> On Wed, Jan 25, 2023 at 1:38 AM 'Michal Hocko' via kernel-team
> wrote:
> >
> > On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote:
> > > Replace indirect modifications to vma->vm_flags with calls to modifier
> > > functions to be able to track
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:09PM +0100, Thomas Zimmermann wrote:
> Initialize the fb-helper structure immediately after its allocation
> in drm_fbdev_generic_setup(). That will make it easier to fill it with
> driver-specific values, such as the preferred BPP.
>
> Signed-off-by: Thom
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:07PM +0100, Thomas Zimmermann wrote:
> Signal failed hotplugging with a flag in struct drm_client_dev. If set,
> the client helpers will not further try to set up the fbdev display.
>
> This used to be signalled with a combination of cleared pointers in
>
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:06PM +0100, Thomas Zimmermann wrote:
> Test for connectors in the client code and remove a similar test
> from the generic fbdev emulation. Do nothing if the test fails.
> Not having connectors indicates a driver bug.
>
> Signed-off-by: Thomas Zimmermann
patch 1 in this series fixed a CLASSMAP usage error, this improves the
api so that misuse is less likely.
changes here:
0- Add William Swanson's public domain map macro:
https://github.com/swansontec/map-macro/blob/master/map.h
this makes 1 possible.
1- classname args to CLASSMAP macros we
lib/test_dynamic_debug.c is used to build 2 modules:
test_dynamic_debug.ko and test_dynamic_debug_submod.ko
Define DEBUG only in the main module, not in the submod. Its purpose
is to insure that prdbgs are enabled by default, so that a modprobe
without params actually logs something, showing that
Now that the DECLARE_DYNDBG_CLASSMAP macro has been split into
DYNDBG_CLASSMAP_DEFINE and DYNDBG_CLASSMAP_USE, lets differentiate
them according to their separate jobs.
Dyndbg's existing __dyndbg_classes[] section does:
. catalogs the classmaps defined by the module (or builtin modules)
. authori
CONFIG_DRM_USE_DYNAMIC_DEBUG=y has a regression; drm subsystem
modules, which depend upon drm.ko and use the drm.debug API, do not
get enabled when __drm_debug is set by `modprobe drm debug=0x1f`.
With =N, __drm_debug is checked before logging the msg, so the
end-of-modprobe debug=$init affected a
Cited commit uses stale macro name, fix this, and explain better.
When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
onto BITs in drm.debug. This still uses enum drm_debug_category, but
it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
This requires that the m
ddebug_apply_class_bitmap() does not alter its 2 bitmap args, make
this guarantee in the interface.
NOTE: the bitmap is also available in the dcp arg, but the 2 vars
serve a 2nd purpose; the CLASS_TYPE callers use them to translate
levels into their underlying disjoint representation.
no function
The dyndbg-to-trace feature is WIP, and not in mainline, so the
presence of the interface to use/test it is unhelpful/confusing.
So define DYNDBG_CLASSMAP_PARAM_T() as DYNDBG_CLASSMAP_PARAM() or
blank, depending upon ifdef DYDBG_TRACE, and update 4 params
controlling the T-flag to use it.
Signed-
__jump_label_patch currently will "crash the box" if it finds a
jump_entry not as expected; it makes no allowances for the well-formed
but incorrect "toggled" state. This patch changes panic-on-toggled
into a warning, allowing to reduce the problem to a repeatable script.
note: this patch is arch
Change function's 1st arg-type, by derefing in the caller.
The fn doesn't need any other fields in the struct.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic
Original name was a punt; but the macro is maybe general enough to put
in the API later. Rename and improve the macro towards that end.
Also tweak internal name constructed in the macro, to add a '_'
between the name components. This changes the .i file only.
no functional change.
Signed-off-b
DECLARE_DYNDBG_CLASSMAP's job was to allow modules to declare the debug
classes/categories they want dyndbg to >control on their behalf. Its
args give the class-names, their mapping to class_ids, and the sysfs
interface style (usually a class-bitmap). Modules wanting a drm.debug
style knob need t
currently, for verbose=3, this is logged:
dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
dyndbg: split into words: "class" "DRM_UT_CORE" "+p"
dyndbg: op='+'
dyndbg: flags=0x1
dyndbg: *flagsp=0x1 *maskp=0x
dyndbg: parsed: func="" file="" module="" format="" lineno=0-0
class=DRM_UT_C
Drop macro args after _var. Since DYNDBG_CLASSMAP_USE no longer
forwards to DYNDBG_CLASSMAP_DEFINE, it doesn't need those args to
forward. Keep only the _var arg, which is the extern'd struct
classmap with all the class info.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.
ARRAY_SIZE works here, since array decl is complete.
no functional change
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index bf47bcfad8e6..81b643ab
Inner fn adds mod_name param, allowing caller to guarantee that only
one module is affected by a prdbgs update. Outer fn preserves
kernel_param interface, passing NULL to inner fn.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 36 +---
Add query_module param to ddebug_apply_class_bitmap(). This allows
its caller to update just one module, or all (as currently). We'll
use this later to propagate drm.debug to each USEr as they're
modprobed.
No functional change.
Signed-off-by: Jim Cromie
---
after `modprobe i915`, heres the m
Dyndbg is required to enable prdbgs at compile-time if DEBUG is
defined. Show this works; add the defn to test_dynamic_debug.c,
and manually inspect/verify its effect at module load:
[ 15.292810] dyndbg: module:test_dynamic_debug attached 4 classes
[ 15.293189] dyndbg: 32 debug prints in mod
Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.
This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly mu
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n"
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/t
Hi everyone,
In v6.1 DRM_USE_DYNAMIC_DEBUG=y has a regression enabling drm.debug in
drivers at modprobe.
It is due to a chicken-egg problem loading modules; on `modprobe
i915`, drm is loaded 1st, and drm/parameters/debug is set. When
drm_debug_enabled() tested __drm_debug at runtime, this just w
Ping. I'll take this via my tree unless someone else wants to take it...
On Sun, Nov 27, 2022 at 10:30:41AM -0800, Kees Cook wrote:
> Both Coverity and GCC with -Wstringop-overflow noticed that
> nvif_outp_acquire_dp() accidentally defined its second argument with 1
> additional element:
>
> driv
GFX9.4.2 now supports per-VMID debug mode controls registers
(SPI_GDBG_PER_VMID_CNTL).
Because the KFD lets the HWS handle PASID-VMID mapping, the KFD will
forward all debug mode setting register writes to the HWS scheduler
using a new MAP_PROCESS API, so instead of writing to registers, return
th
On Wed, Jan 25, 2023 at 4:05 AM Michal Hocko wrote:
>
> On Tue 24-01-23 10:55:21, T.J. Mercier wrote:
> > On Tue, Jan 24, 2023 at 7:00 AM Michal Hocko wrote:
> > >
> > > On Mon 23-01-23 19:17:23, T.J. Mercier wrote:
> > > > When a buffer is exported to userspace, use memcg to attribute the
> > >
On Wed, Jan 25, 2023 at 9:31 AM Tvrtko Ursulin
wrote:
>
>
> Hi,
>
> On 25/01/2023 11:52, Michal Hocko wrote:
> > On Tue 24-01-23 19:46:28, Shakeel Butt wrote:
> >> On Tue, Jan 24, 2023 at 03:59:58PM +0100, Michal Hocko wrote:
> >>> On Mon 23-01-23 19:17:23, T.J. Mercier wrote:
> When a buffer
For uninitialized framebuffers, only release the DRM client and
free the fbdev memory. Do not attempt to clean up the framebuffer.
DRM fbdev clients have a two-step initialization: first create
the DRM client; then create the framebuffer device on the first
successful hotplug event. In cases where
Call drm_fb_helper_fini() in the generic-fbdev hotplug helper
to revert the effects of drm_fb_helper_init(). No full cleanup
is required.
v3:
* fix error in commit message (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fbdev_gene
The fbdev framebuffer cleanup in drm_fbdev_fb_destroy() calls
drm_fbdev_release() and drm_fbdev_cleanup(). Inline both into the
caller. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fbdev_generic.c | 17 ++---
1
Initialize the fb-helper's preferred_bpp field early from within
drm_fb_helper_prepare(); instead of the later client hot-plugging
callback. This simplifies the generic fbdev setup function.
No real changes, but all drivers' fbdev code has to be adapted.
v3:
* build with CONFIG_DRM_FBDEV_
The generic fbdev emulation names variables of type struct fb_info
both 'fbi' and 'info'. The latter seems to be more common in fbdev
code, so name fbi accordingly.
Also replace the duplicate variable in drm_fbdev_fb_destroy().
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canill
Move the fb-helper clean-up code into drm_fb_helper_unprepare(). No
functional changes.
v2:
* declare as static inline (kernel test robot)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fb_helper.c | 14 +-
include/drm/drm_fb_
Add various cleanups and changes to DRM's fbdev helpers and the
generic fbdev emulation. There's no clear theme here, just lots
of small things that need to be updated.
In the end, the code will better reflect which parts are in the
DRM client, which is fbdev emulation, and which are shared fbde
1 - 100 of 286 matches
Mail list logo
