Hi Sam
Am 20.07.22 um 17:08 schrieb Sam Ravnborg:
Hi Thomas,
On Wed, Jul 20, 2022 at 10:30:51AM +0200, Thomas Zimmermann wrote:
The plane helpers are included by dozens of files without any need. Only
a hand full of source files need anything from drm_plane_helper.h.
Untangle everything and t
Hi Marek,
Thank you for the patch.
On Thu, Jul 21, 2022 at 05:03:27AM +0200, Marek Vasut wrote:
> Densitron is a manufacturer of LCD panels.
> https://www.densitron.com
>
> Signed-off-by: Marek Vasut
> Cc: Guido Günther
> Cc: Jagan Teki
> Cc: Laurent Pinchart
> Cc: Linus Walleij
> Cc: Rob H
Hi Robert,
The same patch has been reviewed and applied as
86088f88a25c76baac304b6f887e5da2c30c4e07 in "drm/bridge: it6505: Fixes
bugs" series.
We accidentally sent this out as an individual patch and forgot to
revoke this after sending out the complete series.
Sorry about that.
Regards,
Pin-ye
Densitron is a manufacturer of LCD panels.
https://www.densitron.com
Signed-off-by: Marek Vasut
Cc: Guido Günther
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Linus Walleij
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: Thierry Reding
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1
Commit b05a79d4377f ("mm/gup: migrate device coherent pages when pinning
instead of failing") added a badly formatted if statement. Fix it.
Signed-off-by: Alistair Popple
Reported-by: David Hildenbrand
---
Apologies Andrew for missing this. Hopefully this fixes things.
mm/gup.c | 4 ++--
1 fi
Commit b05a79d4377f ("mm/gup: migrate device coherent pages when pinning
instead of failing") added a badly formatted if statement. Fix it.
Signed-off-by: Alistair Popple
Reported-by: David Hildenbrand
---
Apologies Andrew for missing this. Hopefully this fixes things.
mm/gup.c | 4 ++--
1 fi
On 7/19/2022 02:42, Tvrtko Ursulin wrote:
On 19/07/2022 01:05, John Harrison wrote:
On 7/18/2022 05:15, Tvrtko Ursulin wrote:
On 13/07/2022 00:31, john.c.harri...@intel.com wrote:
From: Matthew Brost
Remove bogus GEM_BUG_ON which compared kernel context timeline
seqno to
seqno in memor
On Tue, Jul 19, 2022 at 01:38:39PM +0530, Aradhya Bhatia wrote:
> Add am625-io-ctrl dt property to provide access to the control MMR
> registers for the OLDI TXes.
>
> These registers are used to control the power input to the OLDI TXes as
> well as to configure them in the Loopback test mode.
>
On Tue, Jul 19, 2022 at 01:38:38PM +0530, Aradhya Bhatia wrote:
> Add "ti,oldi-mode" property to indicate the tidss driver the OLDI output
> mode. The 2 OLDI TXes on am625-dss allow a 3 different types of panel
> connections with the board.
>
> 1. Single Link / Single Mode on OLDI TX 0 OR 1.
> 2.
Ever since I got the spell-check working in my editor this one has
been bugging me. Fix it.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/panel/panel-edp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-
On Wed, 20 Jul 2022 17:08:29 -0300
Jason Gunthorpe wrote:
> On Wed, Jul 20, 2022 at 01:41:13PM -0600, Alex Williamson wrote:
>
> > ie. we don't need the gfn, we only need the iova.
>
> Right, that makes sense
>
> > However then I start to wonder why we're passing in 1 for the number of
> >
On 07/17, Tales Lelo da Aparecida wrote:
> On 16/07/2022 19:25, Melissa Wen wrote:
> > AMD GPU display manager (DM) maps DRM pixel blend modes (None,
> > Pre-multiplied, Coverage) to MPC hw blocks through blend configuration
> > options. Describe relevant elements and how to set and test them to ge
The atna33xc20 has the same problem as panel-edp where it was caching
the EDID. Let's copy the fix over. See the patch ("drm/panel-edp:
Allow overriding the eDP EDID")
NOTE: the question will of course be asked why we've got a copy of
this code. panel-samsung-atna33xc20 was purposely _copied_ from
I found that writing to `/sys/kernel/debug/dri/*/eDP*/edid_override`
wasn't working for me. I could see the new EDID take effect in
`/sys/class/drm/card*-eDP*/edid` but userspace wasn't seeing it..
The problem was that panel-edp was caching the EDID that it read and
using that over and over again.
On 07/17, Tales Lelo da Aparecida wrote:
> On 16/07/2022 19:25, Melissa Wen wrote:
> > AMDGPU DM maps DRM color management properties (degamma, ctm and gamma)
> > to DC color correction entities. Part of this mapping is already
> > documented as code comments and can be converted as kernel docs.
>
Hi,
On Wed, Jul 20, 2022 at 12:12 PM Nícolas F. R. A. Prado
wrote:
>
> Add panel identification entry for the AUO B120XAN01.0 (product ID:
> 0x1062) panel.
>
> Signed-off-by: Nícolas F. R. A. Prado
>
> ---
> v1:
> https://lore.kernel.org/all/20220719203857.1488831-3-nfrapr...@collabora.com
>
>
Hi,
On Wed, Jul 20, 2022 at 11:52 AM Nícolas F. R. A. Prado
wrote:
>
> On Wed, Jul 20, 2022 at 09:49:35AM +0200, AngeloGioacchino Del Regno wrote:
> > Il 20/07/22 00:40, Doug Anderson ha scritto:
> > > Hi,
> > >
> > > On Tue, Jul 19, 2022 at 1:39 PM Nícolas F. R. A. Prado
> > > wrote:
> > > >
>
Hi,
On Wed, Jul 20, 2022 at 1:46 PM Rob Clark wrote:
>
> On Fri, Jul 8, 2022 at 8:25 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Wed, Jul 6, 2022 at 12:14 PM Stephen Boyd wrote:
> > >
> > > Set the panel orientation in drm when the panel is directly connected,
> > > i.e. we're not using an e
On 07/17, Tales Lelo da Aparecida wrote:
> On 16/07/2022 19:25, Melissa Wen wrote:
> > Describe structs and enums used to set blend mode properties to MPC
> > blocks. Some pieces of information are already available as code
> > comments, and were just formatted. Others were collected and summarised
Hi Dave, Daniel,
A couple more fixes for 5.19 this week. These are in addition to the
PR I sent late last week:
https://lists.freedesktop.org/archives/amd-gfx/2022-July/081597.html
The following changes since commit 2d4bd81fea1ad6ebba543bd6da3ef5179d130e6a:
drm/amd/display: Fix new dmub notif
On 7/20/2022 11:36 PM, Rob Clark wrote:
On Tue, Jul 12, 2022 at 12:15 PM Akhil P Oommen
wrote:
On 7/12/2022 10:14 PM, Rob Clark wrote:
On Mon, Jul 11, 2022 at 10:05 PM Akhil P Oommen
wrote:
On 7/12/2022 4:52 AM, Doug Anderson wrote:
Hi,
On Fri, Jul 8, 2022 at 11:00 PM Akhil P Oommen wrote
On Fri, Jul 8, 2022 at 8:25 AM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Jul 6, 2022 at 12:14 PM Stephen Boyd wrote:
> >
> > Set the panel orientation in drm when the panel is directly connected,
> > i.e. we're not using an external bridge. The external bridge case is
> > already handled by the pa
On Mon, Jun 27, 2022 at 4:56 AM Kalyan Thota wrote:
>
> Thanks for the comments, Dmitry. I haven't noticed mode->hdisplay being used.
> My idea was to run thru the topology and tie up the encoders with dspp to the
> CRTCs.
> Since mode is available only in the commit, we cannot use the
> dpu_en
On Wed, Jul 20, 2022 at 01:41:13PM -0600, Alex Williamson wrote:
> ie. we don't need the gfn, we only need the iova.
Right, that makes sense
> However then I start to wonder why we're passing in 1 for the number of
> pages because this previously notifier, now callback is called for the
> enti
On Tue, 19 Jul 2022 21:02:48 -0300
Jason Gunthorpe wrote:
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
> b/drivers/s390/crypto/vfio_ap_ops.c
> index a7d2a95796d360..bb1a1677c5c230 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -1226,34 +1226,14
The -mno-gnu-attribute option in dcn301 clk mgr makefile hides a soft vs
hard fp error for powerpc. After removing this flag, we can see some FPU
code remains there:
gcc-11.3.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o uses
hard
The -mno-gnu-attribute option in clk mgr makefile for dcn30 hides a soft
vs hard fp error for powerpc. After removing this flag, we can see some
FPU code remains there:
gcc-11.3.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o uses
ha
Many lines of code in dcn31_resource_construct are wrapped by DC_FP
macro to protect FPU operations; however, there is no FPU in this
region. Therefore, just remove the wrapper for clarity.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c | 6 --
1 file ch
The -mno-gnu-attribute option in dcn21 clk mgr makefile hides a soft vs
hard fp error for powerpc. After removing this flag, we can see some FPU
code remains there:
/gcc-11.3.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o uses
hard
Move remaining FPU code to DML folder that caused compilation error for
powerpc. This patch depends on [1] to prevent the error below:
/gcc-11.3.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o uses hard
float, drivers/gpu/drm/amd/a
An initial report from Guenter[1] shows some soft-fp vs hard-fp error
from DCN31 clk mgr for powerpc. I was not able to reproduce it
cross-compiling with gcc-powerpc-linux-gnu and gcc-11.3, but thanks to
Maíra tips, I can reproduce the issue using make.cross, as follows:
- wget https://raw.githubu
Add panel identification entry for the AUO B120XAN01.0 (product ID:
0x1062) panel.
Signed-off-by: Nícolas F. R. A. Prado
---
v1: https://lore.kernel.org/all/20220719203857.1488831-3-nfrapr...@collabora.com
Changes in v2:
- Move entry to the top so it respects the sorting
drivers/gpu/drm/panel
On 7/6/2022 12:32 PM, Kuogee Hsieh wrote:
Some userspace presumes that the first connected connector is the main
display, where it's supposed to display e.g. the login screen. For
laptops, this should be the main panel.
This patch call drm_helper_move_panel_connectors_to_head() after
drm_brid
On 7/20/2022 11:47 AM, Abhinav Kumar wrote:
On 7/6/2022 12:32 PM, Kuogee Hsieh wrote:
Some userspace presumes that the first connected connector is the main
display, where it's supposed to display e.g. the login screen. For
laptops, this should be the main panel.
This patch call drm_helper
On Wed, Jul 20, 2022 at 09:49:35AM +0200, AngeloGioacchino Del Regno wrote:
> Il 20/07/22 00:40, Doug Anderson ha scritto:
> > Hi,
> >
> > On Tue, Jul 19, 2022 at 1:39 PM Nícolas F. R. A. Prado
> > wrote:
> > >
> > > Add panel identification entry for the IVO R140NWF5 RH (product ID:
> > > 0x057
On Tue, Jul 19, 2022 at 03:41:43PM -0700, Doug Anderson wrote:
> Hi,
>
> On Tue, Jul 19, 2022 at 1:39 PM Nícolas F. R. A. Prado
> wrote:
> >
> > Add panel identification entry for the AUO B120XAN01.0 (product ID:
> > 0x1062) panel.
> >
> > Signed-off-by: Nícolas F. R. A. Prado
> > ---
> >
> > d
On Tue, Jul 12, 2022 at 12:15 PM Akhil P Oommen
wrote:
>
> On 7/12/2022 10:14 PM, Rob Clark wrote:
> > On Mon, Jul 11, 2022 at 10:05 PM Akhil P Oommen
> > wrote:
> >> On 7/12/2022 4:52 AM, Doug Anderson wrote:
> >>> Hi,
> >>>
> >>> On Fri, Jul 8, 2022 at 11:00 PM Akhil P Oommen
> >>> wrote:
> >
On Tue, Jul 19, 2022 at 11:56 AM Dmitry Osipenko
wrote:
>
> On 7/19/22 20:18, Rob Clark wrote:
> > +void
> > +drm_gem_lru_move_tail_locked(struct drm_gem_lru *lru, struct
> > drm_gem_object *obj)
> > +{
> > + WARN_ON(!mutex_is_locked(lru->lock));
>
> Nit: What about lockdep_assert_held_once(&
On Wed, Jul 20, 2022 at 05:35:32PM +0200, Danilo Krummrich wrote:
> Both, GEM and FB, CMA helpers were renamed to "GEM DMA" and "FB DMA",
> hence the task can be removed.
>
> Acked-by: Thomas Zimmermann
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Danilo Krummrich
It is good to see that so
On Wed, Jul 20, 2022 at 05:35:31PM +0200, Danilo Krummrich wrote:
> The field paddr of struct drm_gem_dma_object holds a DMA address, which
> might actually be a physical address. However, depending on the platform,
> it can also be a bus address or a virtual address managed by an IOMMU.
>
> Hence
Hi Danilo,
On Wed, Jul 20, 2022 at 05:31:26PM +0200, Danilo Krummrich wrote:
> Rename "GEM CMA" helpers to "GEM DMA" helpers - considering the
> hierarchy of APIs (mm/cma -> dma -> gem dma) calling them "GEM
> DMA" seems to be more applicable.
>
> Besides that, commit e57924d4ae80 ("drm/doc: Task
Hi Danilo,
On Wed, Jul 20, 2022 at 05:31:25PM +0200, Danilo Krummrich wrote:
> Rename "FB CMA" helpers to "FB DMA" helpers - considering the hierarchy
> of APIs (mm/cma -> dma -> fb dma) calling them "FB DMA" seems to be
> more applicable.
>
> Besides that, commit e57924d4ae80 ("drm/doc: Task to
On 16.07.2022 06:05, Jason Wang wrote:
Fix the double `wait' typo in comment.
Signed-off-by: Jason Wang
---
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/
On Tue, Jul 12, 2022 at 3:40 PM Hans de Goede wrote:
>
> Typically the acpi_video driver will initialize before radeon, which
> used to cause /sys/class/backlight/acpi_video0 to get registered and then
> radeon would register its own radeon_bl# device later. After which
> the drivers/acpi/video_de
On Tue, Jul 12, 2022 at 3:40 PM Hans de Goede wrote:
>
> Typically the acpi_video driver will initialize before amdgpu, which
> used to cause /sys/class/backlight/acpi_video0 to get registered and then
> amdgpu would register its own amdgpu_bl# device later. After which
> the drivers/acpi/video_de
On Tue, Jul 12, 2022 at 3:40 PM Hans de Goede wrote:
>
> On x86/ACPI boards the acpi_video driver will usually initializing before
initializing -> initialize
> the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
> to show up and then the kms driver registers its own native
HPD event after fbdev unregistration can cause registration of deferred
fbdev which will not be unregistered later, causing use-after-free.
To avoid it HPD handling should be suspended before fbdev unregistration.
It should fix following GPF:
[272.634530] general protection fault, probably for non
In case of deferred FB setup core can try to create new
framebuffer. Disallow it if hpd_suspended flag is set.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drive
HPD events during driver removal can be generated by hardware and
software frameworks - drm_dp_mst, the former we can avoid by disabling
interrupts, the latter can be triggered by any drm_dp_mst transaction,
and this is too late. Introducing suspended flag allows to solve this
chicken-egg problem.
i915->hotplug.dig_port_work can be queued from intel_hpd_irq_handler
called by IRQ handler or by intel_hpd_trigger_irq called from dp_mst.
Since dp_mst is suspended after irq handler uninstall, a cleaner approach
is to cancel hpd work after intel_dp_mst_suspend, otherwise we risk
use-after-free.
I
Hi Jani, Ville, Arun,
This patchset is replacement of patch
"drm/i915/display: disable HPD workers before display driver unregister" [1].
Ive decided to split patch into two parts - fbdev and MST, there are different
issues.
Ive also dropped shutdown path, as it has slightly different requirements
On Wed, Jul 20, 2022 at 12:44 PM Alex Deucher wrote:
>
> On Tue, Jul 12, 2022 at 3:39 PM Hans de Goede wrote:
> >
> > Before this commit when we want userspace to use the acpi_video backlight
> > device we register both the GPU's native backlight device and acpi_video's
> > firmware acpi_video# b
On Tue, Jul 12, 2022 at 3:39 PM Hans de Goede wrote:
>
> Before this commit when we want userspace to use the acpi_video backlight
> device we register both the GPU's native backlight device and acpi_video's
> firmware acpi_video# backlight device. This relies on userspace preferring
> firmware ty
On Tue, Jul 12, 2022 at 3:39 PM Hans de Goede wrote:
>
> Before this commit when we want userspace to use the acpi_video backlight
> device we register both the GPU's native backlight device and acpi_video's
> firmware acpi_video# backlight device. This relies on userspace preferring
> firmware ty
On PM660L, PMI8994 and PMI8998, the WLED has two address spaces. This
also fixes dtbs_check warnings like:
arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dtb: leds@d800: reg: [[55296],
[2]] is too long
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Rob Herring
---
.../devicetree/bindin
On 7/15/2022 12:14 PM, Abhinav Kumar wrote:
dpu_encoder_helper_phys_cleanup() was not populating neither
wb or intf to the intf_cfg before calling the reset_intf_cfg().
This causes the reset of the active bits of wb/intf to be
skipped which is incorrect.
Fix this by populating the relevant w
Samsung MIPI DSIM master can also be found in i.MX8MM SoC.
Add compatible and associated driver_data for it.
v3:
* enable DSIM_QUIRK_FIXUP_SYNC_POL quirk
v2:
* collect Laurent r-b
v1:
* none
Reviewed-by: Laurent Pinchart
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/samsung-dsim.c |
Samsung MIPI DSIM bridge can also be found in i.MX8MM SoC.
Add dt-bingings for it.
v3:
* collect Rob Acked-by
v2:
* updated comments
v1:
* new patch
Acked-by: Rob Herring
Signed-off-by: Jagan Teki
---
Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
1 file changed, 1
eLCDIF is expecting to have input_bus_flags as DE_LOW in order to
set active low during valid data transfer on each horizontal line.
Add DE_LOW flag via drm bridge timings.
v3, v2:
* none
v1:
* none
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/samsung-dsim.c | 5 +
1 file changed,
Finding the right input bus format throughout the pipeline is hard
so add atomic_get_input_bus_fmts callback and initialize with the
default RGB888_1X24 bus format on DSI-end.
This format can be used in pipeline for negotiating bus format between
the DSI-end of this bridge and the other component
Explicit fixing up of mode_flags is required for DSIM present
in i.MX8M SoC.
At least the LCDIF + DSIM needs active low sync polarities in
order to correlate the correct sync flags of the surrounding
components in the chain to make sure the whole pipeline can
work properly.
So, add DSIM_QUIRK_FIX
Add module init and exit functions for the bridge to register
and unregister dsi_driver.
Exynos drm driver stack will register the platform_driver separately
in the common of it's exynos_drm_drv.c including dsi_driver.
Register again would return -EBUSY, so return 0 for such cases as
dsi_driver i
The i.MX 8M Mini Applications Processor Reference Manual, Rev. 3, 11/2020
with 13.7.10.1 Master PLL PMS Value setting Register mentioned PMS_P offset
range from BIT[18-13] and the upstream driver is using the same offset.
However, offset 13 is not working on i.MX8M Mini platforms but downstream
NX
Host transfer() in DSI master will invoke only when the DSI commands
are sent from DSI devices like DSI Panel or DSI bridges and this
host transfer wouldn't invoke for I2C-based-DSI bridge drivers.
Handling DSI host initialization in transfer calls misses the
controller setup for I2C configured DS
In i.MX8M Mini/Nano SoC the DSI Phy requires a MIPI DPHY bit
to reset in order to activate the PHY and that can be done via
upstream i.MX8M blk-ctrl driver.
So, mark the phy get as optional.
v3, v2:
* none
v1:
* new patch
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/samsung-dsim.c | 2
In order to make a common Samsung DSIM bridge driver some platform
specific glue code needs to maintain separately as it is hard to
maintain platform specific glue and conventional component_ops on
the drm bridge drivers side.
This patch is trying to support that glue code initialization based
on
The child devices in MIPI DSI can be binding with OF-graph
and also via child nodes.
The OF-graph interface represents the child devices via
remote and associated endpoint numbers like
dsi {
compatible = "fsl,imx8mm-mipi-dsim";
ports {
port@0 {
reg = <0>;
Samsung MIPI DSIM controller is common DSI IP that can be used in various
SoCs like Exynos, i.MX8M Mini/Nano.
In order to access this DSI controller between various platform SoCs,
the ideal way to incorporate this in the drm stack is via the drm bridge
driver.
This patch is trying to differentiat
From: Marek Szyprowski
Restore the proper bridge chain by finding the previous bridge
in the chain instead of passing NULL.
This establishes a proper bridge chain while attaching downstream
bridges.
v3:
* new patch
Signed-off-by: Marek Szyprowski
Signed-off-by: Jagan Teki
---
drivers/gpu/dr
This series supports common bridge support for Samsung MIPI DSIM
which is used in Exynos and i.MX8MM SoC's.
Previous v2 can be available here [1].
The final bridge supports both the Exynos and i.MX8MM DSI devices.
On, summary this patch-set break the entire DSIM driver into
- platform specific g
Distinguish the condition: _DPRINTK_FLAGS_ENABLED from the bit:
_DPRINTK_FLAGS_PRINT, and re-define former in terms of latter, in
preparation to add a 2nd bit: _DPRINTK_FLAGS_TRACE
Update JUMP_LABEL code block to check _DPRINTK_FLAGS_ENABLED symbol.
Also add a 'K' to get new symbol _DPRINTK_FLAGS_
Add include/trace/events/drm.h, with 2 new events: drm_debug() &
drm_devdbg(), and call them from drm_dbg() & drm_dev_dbg(). This is
easy, cuz the callers already build the vaf that the callee wants.
This allows the 3-5k drm.debug/on-dyndbg callsites to independently
(re-)direct messages to trace
upgrade the callchain to drm_dbg() and drm_dev_dbg(); add a struct
_ddebug ptr parameter to them, and supply that additional param by
replacing the '_no_desc' flavor of dyndbg Factory macro currently used
with the flavor that supplies the descriptor.
NOTES:
The descriptor gives these fns access t
1st, internals:
adds: ddebug_trace()
uses trace_console() temporarily to issue printk:console event
uses internal-ish __ftrace_trace_stack code:
4-context buffer stack, barriers per Steve Rostedt
call it from new mid-layer funcs:
ddebug_printk() - ddebug_trace or vprintk (to syslog)
d
The field paddr of struct drm_gem_dma_object holds a DMA address, which
might actually be a physical address. However, depending on the platform,
it can also be a bus address or a virtual address managed by an IOMMU.
Hence, rename the field to dma_addr, which is more applicable.
In order to do th
Both, GEM and FB, CMA helpers were renamed to "GEM DMA" and "FB DMA",
hence the task can be removed.
Acked-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Signed-off-by: Danilo Krummrich
---
Documentation/gpu/todo.rst | 13 -
1 file changed, 13 deletions(-)
diff --git a/Docume
add new flag, and OR it into _DPRINTK_FLAGS_ENABLED definition
CC: vincent.whitchu...@axis.com
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 38
Hi Dave and Daniel,
This is basically only the guc regression fix.
The other patch is just a dependency to make the
important patch to apply cleanly without conflict.
drm-intel-fixes-2022-07-20-1:
- Fix the regression caused by the lack of GuC v70.
Let's accept the fallback to v69.
Thanks,
Rod
clone DRM.debug interface to DRM.tracebits: ie declare __drm_trace,
map its bits to drm-debug-categories, except this interface enables
messages to tracefs, not to syslog.
1- we reuse the drm_debug_classes class-map added previously.
this reflects the single source of both syslog/trace events
In order to use dynamic-debug's jump-label optimization in drm-debug,
its clarifying to refine drm_debug_enabled into 3 uses:
1. drm_debug_enabled - legacy, public
2. __drm_debug_enabled - optimized for dyndbg jump-label enablement.
3. _drm_debug_enabled - pr_debug instrumented, observable
1.
drm_print.c calls pr_debug() just once, from __drm_printfn_debug(),
which is a generic/service fn. The callsite is compile-time enabled
by DEBUG in both DYNAMIC_DEBUG=y/n builds.
For dyndbg builds, reverting this callsite back to bare printk is
correcting a few anti-features:
1- callsite is gene
clone the nvkm_printk,_,__ macro ladder into nvkm_drmdbg,_,__.
And alter debug, trace, spam macros to use the renamed ladder.
This *sets-up* to remove the _subdev->debug >= (l) condition from the
__ macro, once the bitmap-param is wired up correctly (pointing at the
right state-bit-vector), and fi
nouveau has additional debug variables to consider:
drivers/gpu/drm/nouveau/include/nvkm/core/device.h
131:if (_device->debug >= (l)) \
drivers/gpu/drm/nouveau/include/nvkm/core/client.h
39: if (_client->debug >= NV_DBG_##l)
change drm_dev_dbg & drm_dbg to macros, which forward to the renamed
functions (with __ prefix added).
Those functions sit below the categorized layer of macros implementing
the DRM debug.category API, and implement most of it. These are good
places to insert dynamic-debug jump-label mechanics, w
These 2 macros used drm_debug_enabled() on DRM_UT_{DRIVER,ATOMIC}
respectively, replace those with drm_dbg_##cat invocations.
this results in new class'd prdbg callsites:
:#> grep nouveau /proc/dynamic_debug/control | grep class | wc
1161130 15584
:#> grep nouveau /proc/dynamic_debug/co
Undo the 1-line change that reduced count of prdbgs from 632 to 119.
ie: s/NV_SUBDEV_DBG_##l/NV_DBG_##l/
So heres what happened: new symbol is 15 (or 10), and fails this macro
test, so gets compiled out, and the dev_dbg is excluded.
if (CONFIG_NOUVEAU_DEBUG >= (l) && _subdev->debug >= (l
Change nvkm_subdev.debug to a ulong, so dyndbg can maybe use it.
Move macro decl from nv-drm.c to subdev.c, and add a struct
ddebug_classes_bitmap_param and a module_param_cb() that creates the
sysfs-knob.
Finally, in nvkm_subdev_ctor(), *attempt* to set dyndbg's pointer to
the debug address, so
lkp robot told me:
>> drivers/gpu/drm/drm_ioc32.c:989:2:
error: call to undeclared function '_dynamic_func_call_cls';
ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
DRM_DEBUG("comm=\"%s\", pid=%d, dev=0x%lx, auth=%d, %s\n",
Si
Walk the module's vector of callsites backwards; ie N..0. This
"corrects" the backwards appearance of a module's prdbg vector when
walked 0..N. I think this is due to linker mechanics, which I'm
inclined to treat as immutable, and the order is fixable in display.
No functional changes.
Combined
From: "Steven Rostedt (Google)"
Steve's patch, carried til upstream.
There's several places that open code the following logic:
TP_STRUCT__entry(__dynamic_array(char, msg, MSG_MAX)),
TP_fast_assign(vsnprintf(__get_str(msg), MSG_MAX, vaf->fmt, *vaf->va);)
To load a string created by variabl
Add an explanation of the new "class CLASS_NAME" syntax and meaning,
noting that the module determines if CLASS_NAME applies to it.
Signed-off-by: Jim Cromie
---
Documentation/admin-guide/dynamic-debug-howto.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/admin
Add kernel_param_ops and callbacks to apply a class-map to a
sysfs-node, which then can control classes defined in that class-map.
This supports uses like:
echo 0x3 > /sys/module/drm/parameters/debug
IE add these:
- int param_set_dyndbg_classes()
- int param_get_dyndbg_classes()
- struct ke
These 2 macros formerly used dev_info, and they still check
subdev->debug to gate the printing. So dyndbg control is redundant
ATM (and possibly confusing, since its off by default).
prdbg count is up from 3, or from 65 (with VMM_DEBUG here)
[7.765379] dyndbg: 516 debug prints in module nouv
drm_print defines all of these:
drm_dbg_{core,kms,prime,atomic,vbl,lease,_dp,_drmres}
but not drm_dbg_driver itself, since it was the original drm_dbg.
To improve namespace symmetry, change the drm_dbg defn to
drm_dbg_driver, and redef grandfathered name to symmetric one.
This will help with
ddebug_trace() currently issues a single printk:console event.
Replace that, adding include/trace/events/dyndbg.h, which defines 2
new events:
- dyndbg:prdbg - from trace_prdbg() - if !dev
- dyndbg:devdbg - from trace_devdbg() - if !!dev
This links the legacy pr_debug API to tracefs, via dyndbg
Demonstrate use of DECLARE_DYNDBG_CLASSMAP macro, and expose them as
sysfs-nodes for testing.
For each of the 4 class-map-types:
- declare a class-map of that type,
- declare the enum corresponding to those class-names
- share _base across 0..30 range
- add a __pr_debug_cls() call for eac
For selftest purposes, add __pr_debug_cls(class, fmt, ...)
I didn't think we'd need to define this, since DRM effectively has it
already in drm_dbg, drm_devdbg. But test_dynamic_debug needs it in
order to demonstrate all the moving parts.
Note the __ prefix; its not intended for general use, at
dyndbg's control-parser: ddebug_parse_query(), requires that search
terms: module, func, file, lineno, are used only once in a query; a
thing cannot be named both foo and bar.
The cited commit added an overriding module modname, taken from the
module loader, which is authoritative. So it set quer
Add ddebug_attach_module_classes(), call it from ddebug_add_module().
It scans the classes/section its given, finds records where the
module-name matches the module being added, and adds them to the
module's maps list. No locking here, since the record
isn't yet linked into the ddebug_tables list.
DRM issues ~10 exclusive categories of debug messages; to represent
this directly in dyndbg, add a new field: struct _ddebug.class_id:5.
This gives us 32 classes, which is a practical usability limit
with a bitmap interface:
#> echo 0x012345678 > /sys/module/drm/parameters/debug
All existing c
1 - 100 of 192 matches
Mail list logo
