Set struct fb_ops and with FB_DEFAULT_IO_OPS, fbdev's initializer
for I/O memory. Sets the callbacks to the cfb_ and fb_io_ functions.
Select the correct modules with Kconfig's FB_IO_HELPERS token.
The macro and token set the currently selected values, so there is
no functional change.
v2:
Set struct fb_ops and with FB_DEFAULT_IO_OPS, fbdev's initializer
for I/O memory. Sets the callbacks to the cfb_ and fb_io_ functions.
Select the correct modules with Kconfig's FB_IO_HELPERS token.
The macro and token set the currently selected values, so there is
no functional change.
v2:
Hi
Am 01.08.23 um 12:11 schrieb Jocelyn Falempe:
On 28/07/2023 14:12, Roger Sewell wrote:
Thomas, Jocelyn,
JF> I think the culprit is probably this patch:
JF> https://patchwork.freedesktop.org/patch/486242/
JF>
JF> before this patch,
JF> mgag200_simple_display_pipe_mode_valid() always return
On 12/07/23 8:10 am, Manikandan Muralidharan wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> This patch series aims to add support for XLCDC IP of sam9x7 SoC family
> to the DRM subsystem.XLCDC IP has additional registers and new
> configu
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
:
- rebased to todays drm-misc-next
- Squashed together the two mediatek patches
- Adapted the subject prefix for the arcpgu as pointed out by Thomas
Zimmermann. (This affected two patches originally, one of them was merged
already before anyhow (next-20230801~41^2~34^2~179).)
All these
On Tue, Aug 01, 2023 at 10:00:24AM +, Ran Sun wrote:
> Fix the following errors reported by checkpatch:
>
> ERROR: open brace '{' following struct go on the same line
> ERROR: trailing whitespace
> ERROR: space prohibited before open square bracket '['
>
Thanks for fixing up your tooling to
On 01/08/2023 12:13, Thomas Zimmermann wrote:
> Set struct fb_ops and with FB_DEFAULT_IO_OPS, fbdev's initializer
> for I/O memory. Sets the callbacks to the cfb_ and fb_io_ functions.
> Select the correct modules with Kconfig's FB_IO_HELPERS token.
>
> The macro and token set the currently select
On Tue, 01 Aug 2023, Bagas Sanjaya wrote:
> And it is unfortunate that you and @208suo.com people doesn't reply to
> review comments (try searching lore.kernel.org)
Essentially a one-way firehose of patches pointed at our general
direction is not benefitial to the community. It's not participatio
On Tue, 01 Aug 2023 18:10:25 +0800, Keith Zhao wrote:
> StarFive SoCs JH7110 display system:
> lcd-controller bases verisilicon dc8200 IP,
> and hdmi bases Innosilicon IP.
> Add bindings for them.
>
> Signed-off-by: Keith Zhao
> ---
> .../starfive/starfive,display-subsystem.yaml | 41 +++
Hi,
On Tue, Aug 01, 2023 at 06:10:25PM +0800, Keith Zhao wrote:
> diff --git
> a/Documentation/devicetree/bindings/display/starfive/starfive,jh7110-dc8200.yaml
>
> b/Documentation/devicetree/bindings/display/starfive/starfive,jh7110-dc8200.yaml
> new file mode 100644
> index 0..bebe2050
On Tue, Aug 01, 2023 at 06:10:26PM +0800, Keith Zhao wrote:
> Add the dc controller and hdmi node for the Starfive JH7110 SoC.
>
> Signed-off-by: Keith Zhao
> ---
> .../jh7110-starfive-visionfive-2.dtsi | 87 +++
> arch/riscv/boot/dts/starfive/jh7110.dtsi | 43 ++
On Tue, Aug 01, 2023 at 06:10:27PM +0800, Keith Zhao wrote:
> These are mainly used internally in vs-drm,
> I'm not sure if the new modifiers can be used with the existing ones.
> If there is a problem, I will improve it further.
>
> Signed-off-by: Keith Zhao
> ---
> include/uapi/drm/drm_fourcc.
On Tue, Aug 01, 2023 at 06:10:28PM +0800, Keith Zhao wrote:
> +#define DRV_NAME "starfive"
> +#define DRV_DESC "Starfive DRM driver"
Shouldn't it be verisilicon?
> +#define DRV_DATE "202305161"
> +#define DRV_MAJOR1
> +#define DRV_MINOR0
> +
> +static struct platform_driver vs
Changes in v8:
- Changed lut_size to be a mtk_disp_gamma_set_common() function
parameter to pass lut size from AAL
Changes in v7:
- Added check for NULL dev for AAL-gamma case
- Added get_lut_size callback for AAL-gamma
- Added comment to clarify SoC 10/12 bits support and old vs new
reg
From: "Jason-JH.Lin"
Adjust the parameters in mtk_drm_gamma_set_common()
- add (struct device *dev) to get lut_diff from gamma's driver data
- remove (bool lut_diff) and use false as default value in the function
Signed-off-by: Jason-JH.Lin
Signed-off-by: AngeloGioacchino Del Regno
Review
Invert the check for state->gamma_lut and move it at the beginning
of the function to reduce indentation: this prepares the code for
keeping readability on later additions.
This commit brings no functional changes.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Jason-JH.Lin
Reviewed-by
Newer SoCs support a bigger Gamma LUT table: wire up a callback
to retrieve the correct LUT size for each different Gamma IP.
Co-developed-by: Jason-JH.Lin
Signed-off-by: Jason-JH.Lin
[Angelo: Rewritten commit message/description + porting]
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by
Use drm_color_lut_extract() to avoid open-coding the bits reduction
calculations for each color channel and use a struct drm_color_lut
to temporarily store the information instead of an array of u32.
Also, slightly improve the precision of the HW LUT calculation in the
LUT DIFF case by performing
Move the write to DISP_GAMMA_CFG to enable the Gamma LUT to after
programming the actual table to avoid potential visual glitches during
table modification.
Note:
GAMMA should get enabled in between vblanks, but this requires many
efforts in order to make this happen, as that requires migrating al
Add support for 12-bit gamma lookup tables and introduce the first
user for it: MT8195.
While at it, also reorder the variables in mtk_gamma_set_common()
and rename `lut_base` to `lut0_base` to improve readability.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Jason-JH.Lin
Reviewed-by:
Newer Gamma IP have got multiple LUT banks: support specifying the
size of the LUT banks and handle bank-switching before programming
the LUT in mtk_gamma_set_common() in preparation for adding support
for MT8195 and newer SoCs.
Suggested-by: Jason-JH.Lin
[Angelo: Refactored original commit]
Sign
Make the code more robust and improve readability by using bitfield
macros instead of open coding bit operations.
While at it, also add a definition for LUT_BITS_DEFAULT.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
---
drivers/gpu/drm/med
Disable relay mode at the end of LUT programming to make sure that the
processed image goes through.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 4
1 file changed, 4 insertions(+)
diff
New SoCs, like MT8195, not only may support bigger lookup tables, but
have got a different register layout to support bigger precision:
support specifying the number of `lut_bits` for each SoC and use it
in mtk_gamma_set_common() to perform the right calculation.
Signed-off-by: AngeloGioacchino De
The kerneldoc for struct mtk_disp_aal was entirely wrong: rewrite it
to actually document the structure.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk
All of the SoCs that don't have dithering control in the gamma IP
have got a GAMMA_LUT_TYPE bit that tells to the IP if the LUT is
"descending" (bit set) or "rising" (bit cleared): make sure to set
it correctly after programming the LUT.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Jas
The mtk_disp_gamma structure was completely undocumented: add some
kerneldoc documentation to it.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp
Hi,
On Tue, Aug 01, 2023 at 06:10:30PM +0800, Keith Zhao wrote:
> add hdmi driver as encoder and connect
>
> Signed-off-by: Keith Zhao
You've ignored most of the comments I made on the previous version, so
please go back to that mail and fix everything you've ignored.
https://lore.kernel.org/d
Hi,
On Tue, Aug 01, 2023 at 06:10:29PM +0800, Keith Zhao wrote:
> +static int vs_crtc_atomic_set_property(struct drm_crtc *crtc,
> +struct drm_crtc_state *state,
> +struct drm_property *property,
> +
On Tue, Aug 01, 2023 at 05:32:38AM +, Kasireddy, Vivek wrote:
> > You get another invalidate because the memfd removes the zero pages
> > that hmm_range_fault installed in the PTEs before replacing them with
> > actual writable pages. Then you do the move, and another
> > hmm_range_fault, and
Jocelyn, Thomas,
Jocelyn, your patch works perfectly - thank you.
May I leave it to the two of you to decide what should happen about
propagating this patch ? (I have set out my user's point of view about
it in my email of Fri, 28 Jul 2023 10:11:00 +0100, but obviously my
opinion is not binding
On 01.08.23 14:19, Jason Gunthorpe wrote:
On Tue, Aug 01, 2023 at 05:32:38AM +, Kasireddy, Vivek wrote:
You get another invalidate because the memfd removes the zero pages
that hmm_range_fault installed in the PTEs before replacing them with
actual writable pages. Then you do the move, and
On Tue, Aug 01, 2023 at 02:22:12PM +0200, David Hildenbrand wrote:
> On 01.08.23 14:19, Jason Gunthorpe wrote:
> > On Tue, Aug 01, 2023 at 05:32:38AM +, Kasireddy, Vivek wrote:
> >
> > > > You get another invalidate because the memfd removes the zero pages
> > > > that hmm_range_fault installe
On 01.08.23 14:23, Jason Gunthorpe wrote:
On Tue, Aug 01, 2023 at 02:22:12PM +0200, David Hildenbrand wrote:
On 01.08.23 14:19, Jason Gunthorpe wrote:
On Tue, Aug 01, 2023 at 05:32:38AM +, Kasireddy, Vivek wrote:
You get another invalidate because the memfd removes the zero pages
that hmm
On Tue, Aug 01, 2023 at 02:26:03PM +0200, David Hildenbrand wrote:
> On 01.08.23 14:23, Jason Gunthorpe wrote:
> > On Tue, Aug 01, 2023 at 02:22:12PM +0200, David Hildenbrand wrote:
> > > On 01.08.23 14:19, Jason Gunthorpe wrote:
> > > > On Tue, Aug 01, 2023 at 05:32:38AM +, Kasireddy, Vivek wr
On 01.08.23 14:26, Jason Gunthorpe wrote:
On Tue, Aug 01, 2023 at 02:26:03PM +0200, David Hildenbrand wrote:
On 01.08.23 14:23, Jason Gunthorpe wrote:
On Tue, Aug 01, 2023 at 02:22:12PM +0200, David Hildenbrand wrote:
On 01.08.23 14:19, Jason Gunthorpe wrote:
On Tue, Aug 01, 2023 at 05:32:38A
Ther are many pointers assigned first, which need not to be initialized, so
remove the NULL assignment.
Signed-off-by: Ruan Jinjie
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c | 2 +-
drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c | 2 +-
drivers/gpu/drm/amd/pm/powerpla
Il 01/08/23 13:02, Uwe Kleine-König ha scritto:
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in re
Hi,
On 2023/8/1 18:10, Keith Zhao wrote:
Implement drm device registration interface
Signed-off-by: Keith Zhao
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/verisilicon/Kconfig | 25 ++
drivers/gpu/drm/verisi
Hi,
On 2023/8/1 21:40, suijingfeng wrote:
So, you patch will be pass the compile test, I guess.
You patch will *NOT* pass the compile test, I guess.
On Tue, Aug 01, 2023 at 06:10:24PM +0800, Keith Zhao wrote:
> update starfive maintainers
>
> Signed-off-by: Keith Zhao
Why is this a standalone patch, before you've even added any of the
files in question?
> ---
> MAINTAINERS | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MA
Hi,
On 2023/8/1 21:40, suijingfeng wrote:
+if DRM_VERISILICON
+
+config STARFIVE_HDMI
+ bool "Starfive specific extensions HDMI"
+ help
+ This selects support for StarFive SoC specific extensions
+ for the Innosilicon HDMI driver. If you want to enable
+ HDMI on JH7110 ba
On Tue, Aug 01, 2023 at 06:10:25PM +0800, Keith Zhao wrote:
> StarFive SoCs JH7110 display system:
> lcd-controller bases verisilicon dc8200 IP,
> and hdmi bases Innosilicon IP.
> Add bindings for them.
Please, you can use more than 46 characters in a line!
Also, "v1 v1" does not a v2 make.
>
>
On 7/26/2023 7:36 PM, Colin Ian King wrote:
Pointer pexec is being assigned a value however it is never read. The
assignment is redundant and can be removed. Replace sizeof(*pexec)
with sizeof the type and remove the declaration of pointer pexec.
Signed-off-by: Colin Ian King
Reviewed-by:
Hi,
This series revisits a once-trendy topic: TLB invalidation
support for multi-gt. It's a theme that's been passed around and
reshaped by several of us.
I've filtered out most of the original changes from this series,
initially sent by Mauro [1]. His ideas were inspired by some
changes from Ch
From: Chris Wilson
Prepare for supporting more TLB invalidation scenarios by moving
the current MMIO invalidation to its own file.
Signed-off-by: Chris Wilson
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Andi Shyti
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/Makefile
Create a new intel_gt_defines.h inside the gt/ directory as a
placeholder for all the generic GT based defines.
As of now place only I915_MAX_GT.
Co-developed-by: Chris Wilson
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt_defines.h | 11 +++
drivers/gpu/drm/i915/i915_d
From: Chris Wilson
With multi-GT devices, the object may have been bound on each GT.
Invalidate the TLBs across all GT before releasing the pages
back to the system.
Signed-off-by: Chris Wilson
Cc: Fei Yang
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i
The inclusion of intel_gt_defines.h was initially added to
i915_drv.h to provide the definition of I915_MAX_GT, where it was
originally defined.
However, since I915_MAX_GT is now included in
i915_gem_object_types.h, it sis no longer required in i915_drv.h.
Signed-off-by: Andi Shyti
Cc: Chris Wil
On 01/08/2023 12:25, Thomas Zimmermann wrote:
Hi
Am 01.08.23 um 12:11 schrieb Jocelyn Falempe:
On 28/07/2023 14:12, Roger Sewell wrote:
Thomas, Jocelyn,
JF> I think the culprit is probably this patch:
JF> https://patchwork.freedesktop.org/patch/486242/
JF>
JF> before this patch,
JF> mgag200_
Hi,
On Tue, Aug 1, 2023 at 12:24 AM Nikita Travkin wrote:
>
> Add timings for InnoLux N140HCA-EAC. This panel is found on some laptops
> such as Acer Aspire 1.
>
> Signed-off-by: Nikita Travkin
> ---
> Timings taken per datasheet:
> http://www.58display.com/ggs/20180713155310173_N140HCA-EAC_Rev.
Hi,
On 2023/8/1 21:40, suijingfeng wrote:
+#define DRV_DATE "202305161"
The date is not correct here, generally it should have 8 numbers,
while you have 9 digits, why you are so special ?
I'm also interesting in RISCV arch, I got attracted by your patch.
I just want to join into the d
On 8/1/23 16:19, Andi Shyti wrote:
Hi,
This series revisits a once-trendy topic: TLB invalidation
support for multi-gt. It's a theme that's been passed around and
reshaped by several of us.
I've filtered out most of the original changes from this series,
initially sent by Mauro [1]. His idea
Hi,
On Fri, Jul 28, 2023 at 10:24 AM Doug Anderson wrote:
>
> Hi,
>
> On Fri, Jul 28, 2023 at 8:31 AM Benjamin Tissoires wrote:
> >
> > On Jul 27 2023, Douglas Anderson wrote:
> > >
> > > The big motivation for this patch series is mostly described in the patch
> > > ("drm/panel: Add a way for o
On Tue, Aug 1, 2023 at 4:37 AM Karol Herbst wrote:
> On Mon, Jul 31, 2023 at 9:16 PM Dave Airlie wrote:
> >
> > From: Dave Airlie
> >
> > nouveau > 10 years ago had a plan for new multiplexer inside a
> multiplexer
> > API using nvif. It never fully reached fruition, fast forward 10 years,
> >
Am 31.07.23 um 18:14 schrieb Limonciello, Mario:
On 7/31/2023 8:26 AM, Ruan Jinjie wrote:
Ther are many ternary operators, the true or false judgement
of which is unnecessary in C language semantics.
s/Ther/There/
Unnecessary; sure. But don't they improve the readability quite a bit?
No,
On Mon, Jul 31, 2023 at 11:02:57PM +0200, Marek Vasut wrote:
> Add entry for Innolux G156HCE-L01 15.6" 1920x1080 24bpp
> dual-link LVDS TFT panel. Documentation is available at [1].
>
> [1]
> https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G156HCE-L01_Rev.C3_Datasheet.pdf
>
> S
Hi Jagan
My apologies for dropping the ball on this one, and thanks to Frieder
for the nudge.
On Wed, 12 Apr 2023 at 07:25, Jagan Teki wrote:
>
> Hi Dave,
>
> Added Maxime, Laurent [which I thought I added before]
>
> On Tue, Mar 28, 2023 at 10:38 PM Jagan Teki
> wrote:
> >
> > For a given bri
On Tue, 28 Mar 2023 at 18:08, Jagan Teki wrote:
>
> In order to satisfy the MIPI DSI initialization sequence the bridge
> init order has been altered with the help of pre_enable_prev_first
> in pre_enable and post_disable bridge operations.
>
> Document the affected bridge init order with an examp
Hi
Am 01.08.23 um 16:24 schrieb Jocelyn Falempe:
On 01/08/2023 12:25, Thomas Zimmermann wrote:
Hi
Am 01.08.23 um 12:11 schrieb Jocelyn Falempe:
On 28/07/2023 14:12, Roger Sewell wrote:
Thomas, Jocelyn,
JF> I think the culprit is probably this patch:
JF> https://patchwork.freedesktop.org/pa
Hi
Am 01.08.23 um 14:21 schrieb Roger Sewell:
Jocelyn, Thomas,
Jocelyn, your patch works perfectly - thank you.
That's an interesting find. I briefly looked through the code that
validates the modes, but there's no obvious reason why it would now work.
May I leave it to the two of you to
On Tue, Aug 1, 2023 at 5:15 PM Faith Ekstrand wrote:
> On Tue, Aug 1, 2023 at 4:37 AM Karol Herbst wrote:
>
>> On Mon, Jul 31, 2023 at 9:16 PM Dave Airlie wrote:
>> >
>> > From: Dave Airlie
>> >
>> > nouveau > 10 years ago had a plan for new multiplexer inside a
>> multiplexer
>> > API using n
Hi
Am 01.08.23 um 13:22 schrieb Hans Verkuil:
On 01/08/2023 12:13, Thomas Zimmermann wrote:
Set struct fb_ops and with FB_DEFAULT_IO_OPS, fbdev's initializer
for I/O memory. Sets the callbacks to the cfb_ and fb_io_ functions.
Select the correct modules with Kconfig's FB_IO_HELPERS token.
The
ping! What's the status of this patchset?
Am 07.07.23 um 11:52 schrieb Arnd Bergmann:
From: Arnd Bergmann
The list of dependencies here is phrased as an opt-out, but this is missing
a lot of architectures that don't actually support VGA consoles, and some
of the entries are stale:
- powerpc
Hi Jason, Daniel, etal
This is V5, Im hoping to land this one.
patchwork will probably call this set v3
113361 fix DRM_USE_DYNAMIC_DEBUG regression - revs 1,2
111652 DRM_USE_DYNAMIC_DEBUG regression - older, also 2 revs
It (patch 14 mainly):
Fixes: aad0214f3026 ("dyndbg: add DECLARE_DYNDBG_CL
Incorrect CFLAGS- usage failed to add -DDYNAMIC_DEBUG_MODULE,
which broke builds with:
CONFIG_DRM_USE_DYNAMIC_DEBUG=y
CONFIG_DYNAMIC_DEBUG_CORE=y
but without DYNAMIC_DEBUG
Nobody noticed because a larger regression emerged.
Also add subdir-ccflags so that all drivers pick up the addition.
Fixes
struct ddebug_class_param keeps a ref to the state-storage of the
param, make both flavors use the same unsigned long under-type.
ISTM this is simpler and safer.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 2 +-
lib/dynamic_debug.c | 2 +-
2 files changed, 2 insertion
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
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
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
rename param_set_dyndbg_classes: add _module_ name & arg, old name is
wrapper to new. New arg allows caller to specify that only one module
is affected by a prdbgs update.
Outer fn preserves kernel_param interface, passing NULL to inner fn.
This selectivity will be used later to narrow the scope
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 596d0664c29f..719c5b6a
currently, for verbose=3, these are logged (blank lines for clarity):
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="
old_bits arg is currently a pointer to the input bits, but this could
allow inadvertent changes to the input by the fn. Disallow this.
And constify new_bits while here.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-
check for actual changes before announcing them, declutter logs.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 2a5cbb68d88d..a8973d1a6896 100644
--- a/lib/dynamic_
Remove the NAMED class types; these 2 classmap types accept class
names at the PARAM interface, for example:
echo +DRM_UT_CORE,-DRM_UT_KMS > /sys/module/drm/parameters/debug_names
The code works, but its only used by test-dynamic-debug, and wasn't
asked for by anyone else, so simplify things fo
"externs should be avoided in .c files" needs an exception for linker
symbols, like those that mark the start, stop of many kernel sections.
Since code already checks REALNAME to avoid linker-scripts entirely,
add a new else-if block to look at them instead. As a simple
heuristic, treat all words
"externs should be avoided in .c files" needs an exception for linker
symbols, like those that mark the start, stop of many kernel sections.
Since code already checks REALNAME to avoid linker-scripts entirely,
add a new else-if block to look at them instead. As a simple
heuristic, treat all words
DECLARE_DYNDBG_CLASSMAP() has a design error; it fails a basic K&R
rule: "define once, refer many times".
When DRM_USE_DYNAMIC_DEBUG=y, DECLARE_DYNDBG_CLASSMAP() is used across
DRM core & drivers; they all repeat the same classmap-defn args, which
must match for the modules to respond together whe
Change function's 1st arg-type, and deref 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_d
Add a for_each iterator to walk a counted vector member in a struct
(ie the box), and use it to replace 8 open-coded loops.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynami
Extract input validation code, from param_set_dyndbg_module_classes()
(the sys-node >handler) to new: ddebug_classparam_clamp_input(kp),
call it from former. It takes kernel-param arg, so it can complain
about "foo: bad input".
Reuse ddparam_clamp_input(kp) in ddebug_sync_classbits(),
to validate
move macro from test-dynamic-debug.c into header, and refine it.
Distinguish the 2 use cases of DYNDBG_CLASSMAP_PARAM*
1.DYNDBG_CLASSMAP_PARAM_REF
for DRM, to pass in extern __drm_debug by name.
dyndbg keeps bits in it, so drm can still use it as before
2.DYNDBG_CLASSMAP_PARAM
new us
Lots of burn-in testing needed before signing, upstreaming.
NOTE: I set default Y to maximize testing by default.
Is there a better way to do this ?
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/Kconfi
Make the test-module buildable with CONFIG_DYNAMIC_DEBUG_CORE; add
CFLAGS_$ofile defns to supply -DDYNAMIC_DEBUG_MODULE to cc. Change
the Kconfig entry to allow building with just _CORE, and fix the help
text.
Signed-off-by: Jim Cromie
---
lib/Kconfig.debug | 10 +-
lib/Makefile |
Add a DRM_CLASSMAP_USE declaration to 2nd batch of helpers and *_drv.c
files. For drivers, add the decl just above the module's PARAMs,
since it identifies the "inherited" drm.debug param.
Note: with CONFIG_DRM_USE_DYNAMIC_DEBUG=y, a module not also declaring
DRM_CLASSMAP_USE will have its class'
Add some basic info on classmap usage and api
Signed-off-by: Jim Cromie
---
.../admin-guide/dynamic-debug-howto.rst | 64 ++-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst
b/Documentation/admin-guide/dynamic
Reword the warning to complain about line length 1st, since thats
whats actually tested.
Cc: a...@canonical.com
Cc: j...@perches.com
Signed-off-by: Jim Cromie
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.
101 - 200 of 325 matches
Mail list logo
