Re: [PATCH v6 3/5] drm: Add support to get EDID from ACPI
Hi Mario,
On Thu, Feb 15, 2024 at 8:04 PM Mario Limonciello
wrote:
> On 2/15/2024 12:47, Ville Syrjälä wrote:
> > On Thu, Feb 15, 2024 at 12:20:56PM -0600, Mario Limonciello wrote:
> >> On 2/14/2024 17:13, Ville Syrjälä wrote:
> >>> On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
> >>>> --- a/include/drm/drm_connector.h
> >>>> +++ b/include/drm/drm_connector.h
> >>>> @@ -1886,6 +1886,12 @@ struct drm_connector {
> >>>>
> >>>>/** @hdr_sink_metadata: HDR Metadata Information read from
> >>>> sink */
> >>>>struct hdr_sink_metadata hdr_sink_metadata;
> >>>> +
> >>>> + /**
> >>>> + * @acpi_edid_allowed: Get the EDID from the BIOS, if available.
> >>>> + * This is only applicable to eDP and LVDS displays.
> >>>> + */
> >>>> + bool acpi_edid_allowed;
> >>>
> >>> Aren't there other bools/small stuff in there for tighter packing?
> >>
> >> Does the compiler automatically do the packing if you put bools nearby
> >> in a struct? If so; TIL.
> >
> > Yes. Well, depends on the types and their alignment requirements
> > of course, and/or whether you specified __packed or not.
> >
> > You can use 'pahole' to find the holes in structures.
>
> Thanks! I don't see a __packed attribute on struct drm_connector, but
> I'll put it near by other bools in case that changes in the future.
FTR, don't add __packed unless you have a very good reason to do so.
With __packed, the compiler will emit multiple byte-accesses to
access multi-byte integrals on platforms that do not support unaligned
memory access.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 08/43] drm/fbdev: Add fbdev-shmem
Hi Thomas,
On Tue, Apr 16, 2024 at 2:07 PM Thomas Zimmermann wrote:
> Am 16.04.24 um 13:25 schrieb Javier Martinez Canillas:
> > Thomas Zimmermann writes:
> > Do I understand correctly that info->fix.smem_start doesn't have to be set
> > because that's only used for I/O memory?
>
> It's the start of the framebuffer memory in physical memory. Setting
> smem_start only makes sense if the framebuffer is physically continuous,
> which isn't the case here.
Nothing really needs fix.smem_start, it's mainly for informative use.
However, if smem_start is not page-aligned, userspace does need to
know the start offset inside the page (see below).
> > This also made me think why info->fix.smem_len is really needed. Can't we
> > make the fbdev core to only look at that if info->screen_size is not set ?
>
> The fbdev core doesn't use smem_len AFAICT. But smem_len is part of the
> fbdev UAPI, so I set it. I assume that programs use it to go to the end
> of the framebuffer memory.
On fbdev drivers also exporting MMIO to userspace, /dev/fbX contains
two parts: first the frame buffer, followed by the MMIO registers.
Both parts are an integral number of pages, based on fix.smem_{start,len}
resp. fix.mmio_{start,len}.
Old XFree86 used the MMIO part to implement hardware acceleration
when running on top of fbdev.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 00/13] drm/display: Convert helpers Kconfig symbols to depends on
Hi Jani,
On Tue, Apr 9, 2024 at 1:13 PM Jani Nikula wrote:
> On Tue, 09 Apr 2024, Geert Uytterhoeven wrote:
> > On Tue, Apr 9, 2024 at 12:04 PM Jani Nikula
> > wrote:
> >> On Tue, 09 Apr 2024, Geert Uytterhoeven wrote:
> >> > The user should not need to know which helpers are needed for the driver
> >> > he is interested in. When a symbol selects another symbol, it should
> >> > just make sure the dependencies of the target symbol are met.
> >>
> >> It's really not "just make sure". This leads to perpetual illegal
> >> configurations, and duct tape fixes. Select should not be used for
> >> visible symbols or symbols with dependencies [1].
> >
> > In other words: none of these helpers should be visible...
>
> ...and should have no dependencies? :p
Unless they do have dependencies.
> >> What we'd need for usability is not more abuse of select, but rather 1)
> >> warnings for selecting symbols with dependencies, and 2) a way to enable
> >
> > Kconfig already warns if dependencies of selected symbols are not met.
>
> But it does lead to cases where a builtin tries to use a symbol from a
> module, failing at link time, not config time. Then I regularly see
> patches trying to fix this with IS_REACHABLE(), making it a silent
> runtime failure instead, when it should've been a config issue.
If a symbol for a builtin selects a symbol for a module, the latter
becomes builtin, too, so that does not cause such issues?
You can get such issues when a boolean symbol depends on a tristate
symbol...
> >> a kconfig option with all its dependencies, recursively. This is what we
> >> lack.
> >
> > You cannot force-enable all dependencies of the target symbol, as some
> > of these dependencies may be impossible to meet on the system you are
> > configuring a kernel for.
>
> Surely kconfig should be able to figure out if they're possible or not.
>
> > The current proper way is to add these dependencies to the source
> > symbol, which is what we have been doing everywhere else. Another
> > solution may be to teach Kconfig to ignore any symbols that select a
> > symbol with unmet dependencies.
>
> ...
>
> It seems like your main argument in favour of using select is that it's
> more convenient for people who configure the kernel. Because the user
> should be able to just enable a driver, and that would select everything
> that's needed. But where do we draw the line? Then what qualifies for
> "depends on"?
Hard (platform and subsystem) dependencies.
> Look at config DRM_I915 and where select abuse has lead us. Like, why
> don't we just select DRM, PCI and X86 as well instead of depend. :p
X86 and PCI are hard platform dependencies.
DRM is a subsystem dependency.
> A lot of things we have to select because it appears to generally be the
> case that if some places select and some places depends on a symbol,
> it'll lead to circular dependencies.
True. So all library code (incl. helpers) should be selected, and
not be used as a dependency.
The user shouldn't be aware that the driver uses library code (or not).
> Sure there may be a usability issue with using depends on. But the
> proper fix isn't hacking in kconfig files, it's to fix the usability in
> kconfig the tool UI. But nobody steps up, because at least I find the
> kconfig source to be inpenetrable. I've tried many times, and given up.
As long as Kconfig does not handle dependencies of selected symbols
automatically, adding explicit dependencies to the origin symbols is
the only workable solution.
> I mean, if you want to enable a driver D, it could, at a minimum, show
> you a tree of (possibly alternative) things you also need to enable. But
And this series is actually making that harder, by turning all these
selects of helpers into dependencies...
> if the dependencies aren't there, you won't even see the config for
> D. That's not something that should be "fixed" by abusing select in
> kconfig files.
I consider not seeing symbols when a hard dependency is not met as
a good thing. If everything was visible all the time, you would
have a very hard (well, harder than the current already-hard ;-)
time configuring your kernel.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RESEND v7 08/37] clocksource: sh_tmu: CLOCKSOURCE support.
Hi Sato-san,
On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
wrote:
> Allows initialization as CLOCKSOURCE.
>
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
> --- a/drivers/clocksource/sh_tmu.c
> +++ b/drivers/clocksource/sh_tmu.c
> @@ -495,7 +514,12 @@ static int sh_tmu_map_memory(struct sh_tmu_device *tmu)
>
> static int sh_tmu_parse_dt(struct sh_tmu_device *tmu)
> {
> - struct device_node *np = tmu->pdev->dev.of_node;
> + struct device_node *np;
Technically, np might be used uninitialized.
> +
> + if (tmu->pdev)
> + np = tmu->pdev->dev.of_node;
If you would set up tmu->np in sh_tmu_setup_pdev()...
> + if (tmu->np)
> + np = tmu->np;
... you could just assign np = tmu->np unconditionally.
>
> tmu->model = SH_TMU;
> tmu->num_channels = 3;
> @@ -665,6 +734,7 @@ static void __exit sh_tmu_exit(void)
> platform_driver_unregister(_tmu_device_driver);
> }
>
> +TIMER_OF_DECLARE(sh_tmu, "renesas,tmu", sh_tmu_of_register);
As there are now two entry points, the device is actually probed twice:
once from TIMER_OF_DECLARE/sh_tmu_of_register(), and a second
time from platform_driver/sh_tmu_probe().
E.g. on Armadillo-800-EVA with R-Mobile A1 (booting Linux on ARM
(not SH), and using TMU as the main clock source):
timer@fff8 ch0: used for clock events
timer@fff8 ch0: used for periodic clock events
timer@fff8 ch1: used as clock source
clocksource: timer@fff8: mask: 0x max_cycles:
0x, max_idle_ns: 154445288668 ns
...
fff8.timer ch0: used for clock events
genirq: Flags mismatch irq 16. 00015a04 (fff8.timer) vs.
00015a04 (timer@fff8)
fff8.timer ch0: failed to request irq 16
fff8.timer ch1: used as clock source
clocksource: fff8.timer: mask: 0x max_cycles:
0x, max_idle_ns: 154445288668 ns
After this, the timer seems to be stuck, and the boot is blocked.
On Marzen with R-Car H1 (booting Linux on ARM (not SH), and using
arm_global_timer as the main clock source), I also see the double
timer probe, but no such lock-up. I expect you to see the double
timer probe on SH775x, too?
The double probe can be fixed by adding a call to
of_node_set_flag(np, OF_POPULATED) at the end of sh_tmu_of_register()
in case of success, cfr. [1].
I haven't found the cause of the stuck timer on R-Mobile A1 yet;
both the TMU clock and the A4R power domain seem to be activated...
> #ifdef CONFIG_SUPERH
> sh_early_platform_init("earlytimer", _tmu_device_driver);
> #endif
[1] "[PATCH] clocksource/drivers/renesas-ostm: Avoid reprobe after
successful early probe"
https://lore.kernel.org/all/bd027379713cbaafa21ffe9e848ebb7f475ca0e7.1710930542.git.geert+rene...@glider.be/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 00/13] drm/display: Convert helpers Kconfig symbols to depends on
Hi Jani,
On Tue, Apr 9, 2024 at 12:04 PM Jani Nikula wrote:
> On Tue, 09 Apr 2024, Geert Uytterhoeven wrote:
> > The user should not need to know which helpers are needed for the driver
> > he is interested in. When a symbol selects another symbol, it should
> > just make sure the dependencies of the target symbol are met.
>
> It's really not "just make sure". This leads to perpetual illegal
> configurations, and duct tape fixes. Select should not be used for
> visible symbols or symbols with dependencies [1].
In other words: none of these helpers should be visible...
> What we'd need for usability is not more abuse of select, but rather 1)
> warnings for selecting symbols with dependencies, and 2) a way to enable
Kconfig already warns if dependencies of selected symbols are not met.
> a kconfig option with all its dependencies, recursively. This is what we
> lack.
You cannot force-enable all dependencies of the target symbol, as some
of these dependencies may be impossible to meet on the system you are
configuring a kernel for.
The current proper way is to add these dependencies to the source
symbol, which is what we have been doing everywhere else. Another
solution may be to teach Kconfig to ignore any symbols that select a
symbol with unmet dependencies.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 00/13] drm/display: Convert helpers Kconfig symbols to depends on
Hi Maxime,
On Wed, 27 Mar 2024, Maxime Ripard wrote:
Jani recently pointed out that the Kconfig symbols are a bit difficult
to work with at the moment when they depend on each other, and that
using depends on would be a better idea, but no one really did the work
so far.
So here it goes :)
It's been tested by comparing the riscv defconfig, arm
multi_v7_defconfig, arm64 defconfig, drm-misc-arm, drm-misc-arm64 and
drm-misc-x86 before and after this series and making sure they are
identical.
That is not true: comparing drm-misc/for-linux-next to v6.9-rc2,
arm/multi_v7_defconfig, arm64/defconfig, and riscv/defconfig lost
several of:
- CONFIG_DRM_DW_HDMI,
- CONFIG_DRM_DW_HDMI_AHB_AUDIO,
- CONFIG_DRM_DW_HDMI_CEC,
- CONFIG_DRM_DW_HDMI_I2S_AUDIO,
- CONFIG_DRM_IMX_HDMI.
- CONFIG_DRM_MESON_DW_HDMI,
- CONFIG_DRM_RCAR_DW_HDMI,
- CONFIG_DRM_SUN8I_DW_HDMI,
- CONFIG_ROCKCHIP_DW_HDMI,
- CONFIG_SND_MESON_G12A_TOHDMITX,
Let me know what you think,
IMHO this series looks like a big usuability issue for anyone
configuring the kernel, and you try to work around this by sprinkling
"default y" around.
The user should not need to know which helpers are needed for the driver
he is interested in. When a symbol selects another symbol, it should
just make sure the dependencies of the target symbol are met.
Thanks for reverting ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 09/13] drm: Switch DRM_DISPLAY_DP_AUX_BUS to depends on
Hi Maxime,
Thanks for your patch, which is now commit 4d15125d7fe637f4
("drm: Switch DRM_DISPLAY_DP_AUX_BUS to depends on") in
drm/drm-next (next-20240402 and later).
On Wed, 27 Mar 2024, Maxime Ripard wrote:
Most of our helpers have relied on being selected so far through
Kconfig, but that creates issues when we have multiple layers of helpers
with some depending on others.
Indeed, select doesn't select a dependency's dependencies, and thus
isn't super intuitive. Depends on however doesn't have that limitation,
(Almost?) Everywhere else we fixed that by also selecting the
dependencies, which is more user-friendly.
so we can just switch all the drivers that were selecting
DRM_DISPLAY_DP_AUX_BUS to depend on it.
Reviewed-by: Jani Nikula
Signed-off-by: Maxime Ripard
--- a/drivers/gpu/drm/display/Kconfig
+++ b/drivers/gpu/drm/display/Kconfig
@@ -9,10 +9,11 @@ config DRM_DISPLAY_HELPER
config DRM_DISPLAY_DP_AUX_BUS
tristate "DRM DisplayPort AUX bus support"
depends on DRM
depends on OF || COMPILE_TEST
+ default y
(quoting Linus) "What is so special about your driver, that it needs to
default to enabled?".
Especially as there is no help available for this option, so the casual
user has no idea if this is needed or not.
And a general comment for this series: many defconfigs need to be
updated, as drivers are no longer enabled because they need
functionality that now needs to be enabled explicitly.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 20/21] drm/rcar-du: Allow build with COMPILE_TEST=y
On Mon, Apr 8, 2024 at 7:05 PM Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> Allow rcar-du to be built with COMPILE_TEST=y for greater
> coverage. Builds fine on x86/x86_64 at least.
Also on rv64 and m68k.
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: linux-renesas-...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RESEND v7 21/37] dt-bindings: serial: renesas, scif: Add scif-sh7751.
Hi Sato-san,
On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
wrote:
> Add Renesas SH7751 SCIF.
>
> Signed-off-by: Yoshinori Sato
> Reviewed-by: Geert Uytterhoeven
> --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> @@ -18,6 +18,7 @@ properties:
>- items:
>- enum:
>- renesas,scif-r7s72100 # RZ/A1H
> + - renesas,scif-sh7751 # SH7751
>- const: renesas,scif # generic SCIF compatible UART
>
>- items:
If this is applied after "[PATCH v2 2/2] dt-bindings: serial:
renesas,scif: Validate 'interrupts' and 'interrupt-names'"[1], an extra
"- renesas,scif-sh7751" line should be added to the 4-interrupt section
(below "- renesas,scif-r7s72100").
[1]
https://lore.kernel.org/all/20240307114217.34784-3-prabhakar.mahadev-lad...@bp.renesas.com/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RESEND v7 28/37] dt-bindings: soc: renesas: sh: Add SH7751 based target
Hi Sato-san,
On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
wrote:
> Signed-off-by: Yoshinori Sato
Thanks for the update!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/renesas/sh.yaml
> + compatible:
> +oneOf:
As adding more SoCs is expected, having oneOf from the start is fine.
> + - description: SH7751R based platform
> +items:
> + - enum:
> + - renesas,rts7751r2d # Renesas SH4 2D graphics board
> + - iodata,landisk # LANDISK HDL-U
> + - iodata,usl-5p # USL-5P
> + - const: renesas,sh7751r
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RESEND v7 23/37] dt-bindings: display: sm501 register definition helper
Hi Sato-san,
Thanks for your patch!
On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
wrote:
> Miscellaneous Timing and Miscellaneous Control registers definition.
Please do not put raw register value definitions into DT bindings.
> Signed-off-by: Yoshinori Sato
> --- /dev/null
> +++ b/include/dt-bindings/display/sm501.h
> +/* Miscellaneous timing */
> +#define SM501_MISC_TIMING_EX_HOLD_00
> +#define SM501_MISC_TIMING_EX_HOLD_16 1
> +#define SM501_MISC_TIMING_EX_HOLD_32 2
> +#define SM501_MISC_TIMING_EX_HOLD_48 3
> +#define SM501_MISC_TIMING_EX_HOLD_64 4
> +#define SM501_MISC_TIMING_EX_HOLD_80 5
> +#define SM501_MISC_TIMING_EX_HOLD_96 6
> +#define SM501_MISC_TIMING_EX_HOLD_112 7
> +#define SM501_MISC_TIMING_EX_HOLD_128 8
> +#define SM501_MISC_TIMING_EX_HOLD_144 9
> +#define SM501_MISC_TIMING_EX_HOLD_160 10
> +#define SM501_MISC_TIMING_EX_HOLD_176 11
> +#define SM501_MISC_TIMING_EX_HOLD_192 12
> +#define SM501_MISC_TIMING_EX_HOLD_208 13
> +#define SM501_MISC_TIMING_EX_HOLD_224 14
> +#define SM501_MISC_TIMING_EX_HOLD_240 15
E.g. these are used by the (not very descriptive) "ex" property:
ex:
$ref: /schemas/types.yaml#/definitions/uint32
description: Extend bus holding time.
Please instead use an enum for the actual holding time ([ 0, 16, 32,
...]) in the DT bindings, and convert from actual holding time to
register value in the driver.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RESEND v7 14/37] clk: Compatible with narrow registers
K_DIVIDER_REG_16BIT - by default 32bit register accesses are used for
> + * the gate register. Setting this flag makes the register accesses
> 16bit.
> */
> struct clk_divider {
> struct clk_hw hw;
> void __iomem*reg;
> u8 shift;
> u8 width;
> - u8 flags;
> + u16 flags;
> const struct clk_div_table *table;
> spinlock_t *lock;
> };
> @@ -726,18 +738,18 @@ struct clk_hw *__clk_hw_register_divider(struct device
> *dev,
> struct device_node *np, const char *name,
> const char *parent_name, const struct clk_hw *parent_hw,
> const struct clk_parent_data *parent_data, unsigned long
> flags,
> - void __iomem *reg, u8 shift, u8 width, u8 clk_divider_flags,
> + void __iomem *reg, u8 shift, u8 width, u32 clk_divider_flags,
"u16 clk_divider_flags", to match clk_divider.flags.
> const struct clk_div_table *table, spinlock_t *lock);
> struct clk_hw *__devm_clk_hw_register_divider(struct device *dev,
> struct device_node *np, const char *name,
> const char *parent_name, const struct clk_hw *parent_hw,
> const struct clk_parent_data *parent_data, unsigned long
> flags,
> - void __iomem *reg, u8 shift, u8 width, u8 clk_divider_flags,
> + void __iomem *reg, u8 shift, u8 width, u32 clk_divider_flags,
Likewise.
> const struct clk_div_table *table, spinlock_t *lock);
> struct clk *clk_register_divider_table(struct device *dev, const char *name,
> const char *parent_name, unsigned long flags,
> void __iomem *reg, u8 shift, u8 width,
> - u8 clk_divider_flags, const struct clk_div_table *table,
> + u32 clk_divider_flags, const struct clk_div_table *table,
Likewise.
> spinlock_t *lock);
> /**
> * clk_register_divider - register a divider clock with the clock framework
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RESEND v7 34/37] sh: Add dtbs target support.
On Thu, Apr 4, 2024 at 7:16 AM Yoshinori Sato
wrote:
> Signed-off-by: Yoshinori Sato
My
Reviewed-by: Geert Uytterhoeven
on v6 is still valid.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RESEND v7 33/37] sh: j2_mimas_v2.dts update
Hi Sato-san,
On Thu, Apr 4, 2024 at 7:16 AM Yoshinori Sato
wrote:
> Signed-off-by: Yoshinori Sato
>From my comments for v6:
Please enhance the one-line summary, e.g.
sh: j2_mimas_v2: Update CPU compatible value
For the actual changes:
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RESEND v7 13/37] dt-bindings: clock: sh7750-cpg: Add renesas,sh7750-cpg header.
Hi Sato-san,
Thanks for the update!
On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
wrote:
>
> SH7750 CPG Clock output define.
(from my comments on v6) Please improve the patch description.
> Signed-off-by: Yoshinori Sato
> index ..04c10b0834ee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/renesas,sh7750-cpg.yaml
The actual bindings LGTM.
> +examples:
> + - |
> +#include
> +cpg: clock-controller@ffc0 {
> +#clock-cells = <1>;
> +#power-domain-cells = <0>;
> +compatible = "renesas,sh7751r-cpg";
> +clocks = <>;
> +clock-names = "extal";
> +reg = <0xffc0 20>, <0xfe0a 16>;
> +reg-names = "FRQCR", "CLKSTP00";
> +renesas,mode = <0>;
> +};
Please read
https://docs.kernel.org/devicetree/bindings/dts-coding-style.html#order-of-properties-in-device-node
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RESEND v7 09/37] dt-binding: Add compatible SH7750 SoC
On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
wrote:
> Signed-off-by: Yoshinori Sato
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] drm: DRM_DEBUG_MODESET_LOCK should depend on DRM
There is no point in asking the user about enabling DRM debug tracing when configuring a kernel without DRM support. Signed-off-by: Geert Uytterhoeven --- drivers/gpu/drm/Kconfig | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 2e1b23ccf30423a9..a24c48acf235449a 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -119,9 +119,7 @@ config DRM_DEBUG_DP_MST_TOPOLOGY_REFS config DRM_DEBUG_MODESET_LOCK bool "Enable backtrace history for lock contention" - depends on STACKTRACE_SUPPORT - depends on DEBUG_KERNEL - depends on EXPERT + depends on DRM && STACKTRACE_SUPPORT && DEBUG_KERNEL && EXPERT select STACKDEPOT default y if DEBUG_WW_MUTEX_SLOWPATH help -- 2.34.1
[PATCH] drm: DRM_WERROR should depend on DRM
There is no point in asking the user about enforcing the DRM compiler
warning policy when configuring a kernel without DRM support.
Fixes: f89632a9e5fa6c47 ("drm: Add CONFIG_DRM_WERROR")
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f2bcf5504aa77679..2e1b23ccf30423a9 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -423,7 +423,7 @@ config DRM_PRIVACY_SCREEN
config DRM_WERROR
bool "Compile the drm subsystem with warnings as errors"
- depends on EXPERT
+ depends on DRM && EXPERT
default n
help
A kernel build should not cause any compiler warnings, and this
--
2.34.1
Re: Build regressions/improvements in v6.9-rc1
On Mon, 25 Mar 2024, Geert Uytterhoeven wrote:
Below is the list of build error/warning regressions/improvements in
v6.9-rc1[1] compared to v6.8[2].
Summarized:
- build errors: +8/-8
+ /kisskb/src/crypto/scompress.c: error: unused variable 'dst_page'
[-Werror=unused-variable]: => 174:38
xtensa-gcc13/xtensa-allmodconfig
+ /kisskb/src/drivers/gpu/drm/msm/adreno/adreno_gen7_0_0_snapshot.h: error:
'gen7_0_0_external_core_regs' defined but not used [-Werror=unused-variable]:
=> 924:19
+ /kisskb/src/drivers/gpu/drm/msm/adreno/adreno_gen7_2_0_snapshot.h: error:
'gen7_2_0_external_core_regs' defined but not used [-Werror=unused-variable]:
=> 748:19
arm64-gcc5/arm64-allmodconfig
powerpc-gcc5/powerpc-allmodconfig
powerpc-gcc5/powerpc-allyesconfig
powerpc-gcc5/ppc32_allmodconfig
powerpc-gcc5/ppc64_book3e_allmodconfig
powerpc-gcc5/ppc64le_allmodconfig
sparc64-gcc5/sparc64-allmodconfig
+ /kisskb/src/drivers/gpu/drm/xe/xe_lrc.c: error: "END" redefined [-Werror]:
=> 100
mips-gcc8/mips-allmodconfig
mips-gcc13/mips-allmodconfig
+ error: arch/sparc/kernel/process_32.o: relocation truncated to fit:
R_SPARC_WDISP22 against `.text': => (.fixup+0xc), (.fixup+0x4)
+ error: arch/sparc/kernel/signal_32.o: relocation truncated to fit:
R_SPARC_WDISP22 against `.text': => (.fixup+0x18), (.fixup+0x8), (.fixup+0x0),
(.fixup+0x20), (.fixup+0x10)
+ error: relocation truncated to fit: R_SPARC_WDISP22 against `.init.text':
=> (.head.text+0x5100), (.head.text+0x5040)
+ error: relocation truncated to fit: R_SPARC_WDISP22 against symbol
`leon_smp_cpu_startup' defined in .text section in
arch/sparc/kernel/trampoline_32.o: => (.init.text+0xa4)
sparc64-gcc13/sparc-allmodconfig
[1]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/4cece764965020c22cff7665b18a012006359095/
(all 138 configs)
[2]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/e8f897f4afef0031fe618a8e94127a0934896aba/
(all 138 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 00/14] Add support for suppressing warning backtraces
Hi Günter,
On Tue, Mar 12, 2024 at 6:03 PM Guenter Roeck wrote:
> Some unit tests intentionally trigger warning backtraces by passing bad
> parameters to kernel API functions. Such unit tests typically check the
> return value from such calls, not the existence of the warning backtrace.
>
> Such intentionally generated warning backtraces are neither desirable
> nor useful for a number of reasons.
> - They can result in overlooked real problems.
> - A warning that suddenly starts to show up in unit tests needs to be
> investigated and has to be marked to be ignored, for example by
> adjusting filter scripts. Such filters are ad-hoc because there is
> no real standard format for warnings. On top of that, such filter
> scripts would require constant maintenance.
>
> One option to address problem would be to add messages such as "expected
> warning backtraces start / end here" to the kernel log. However, that
> would again require filter scripts, it might result in missing real
> problematic warning backtraces triggered while the test is running, and
> the irrelevant backtrace(s) would still clog the kernel log.
>
> Solve the problem by providing a means to identify and suppress specific
> warning backtraces while executing test code. Support suppressing multiple
> backtraces while at the same time limiting changes to generic code to the
> absolute minimum. Architecture specific changes are kept at minimum by
> retaining function names only if both CONFIG_DEBUG_BUGVERBOSE and
> CONFIG_KUNIT are enabled.
>
> The first patch of the series introduces the necessary infrastructure.
> The second patch introduces support for counting suppressed backtraces.
> This capability is used in patch three to implement unit tests.
> Patch four documents the new API.
> The next two patches add support for suppressing backtraces in drm_rect
> and dev_addr_lists unit tests. These patches are intended to serve as
> examples for the use of the functionality introduced with this series.
> The remaining patches implement the necessary changes for all
> architectures with GENERIC_BUG support.
Thanks for your series!
I gave it a try on m68k, just running backtrace-suppression-test,
and that seems to work fine.
> Design note:
> Function pointers are only added to the __bug_table section if both
> CONFIG_KUNIT and CONFIG_DEBUG_BUGVERBOSE are enabled to avoid image
> size increases if CONFIG_KUNIT=n. There would be some benefits to
> adding those pointers all the time (reduced complexity, ability to
> display function names in BUG/WARNING messages). That change, if
> desired, can be made later.
Unfortunately this also increases kernel size in the CONFIG_KUNIT=m
case (ca. 80 KiB for atari_defconfig), making it less attractive to have
kunit and all tests enabled as modules in my standard kernel.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: arm: ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/sun4i/sun4i-drm-hdmi.ko] undefined!
On Thu, Mar 14, 2024 at 10:27 AM Geert Uytterhoeven
wrote:
> On Sat, Mar 9, 2024 at 3:34 PM David Laight wrote:
> > From: Maxime Ripard
> > > Sent: 04 March 2024 11:46
> > >
> > > On Mon, Mar 04, 2024 at 12:11:36PM +0100, Arnd Bergmann wrote:
> > > > On Mon, Mar 4, 2024, at 09:07, Naresh Kamboju wrote:
> > > > > The arm defconfig builds failed on today's Linux next tag
> > > > > next-20240304.
> > > > >
> > > > > Build log:
> > > > > -
> > > > > ERROR: modpost: "__aeabi_uldivmod"
> > > > > [drivers/gpu/drm/sun4i/sun4i-drm-hdmi.ko] undefined!
> > > > >
> > > >
> > > > Apparently caused by the 64-bit division in 358e76fd613a
> > > > ("drm/sun4i: hdmi: Consolidate atomic_check and mode_valid"):
> > > >
> > > >
> > > > +static enum drm_mode_status
> > > > +sun4i_hdmi_connector_clock_valid(const struct drm_connector *connector,
> > > > +const struct drm_display_mode *mode,
> > > > +unsigned long long clock)
> > > > {
> > > > - struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
> > > > - unsigned long rate = mode->clock * 1000;
> > > > - unsigned long diff = rate / 200; /* +-0.5% allowed by HDMI spec
> > > > */
> > > > + const struct sun4i_hdmi *hdmi =
> > > > drm_connector_to_sun4i_hdmi(connector);
> > > > + unsigned long diff = clock / 200; /* +-0.5% allowed by HDMI
> > > > spec */
> > > > long rounded_rate;
> > > >
> > > > This used to be a 32-bit division. If the rate is never more than
> > > > 4.2GHz, clock could be turned back into 'unsigned long' to avoid
> > > > the expensive div_u64().
> > >
> > > I sent a fix for it this morning:
> > > https://lore.kernel.org/r/20240304091225.366325-1-mrip...@kernel.org
> > >
> > > The framework will pass an unsigned long long because HDMI character
> > > rates can go up to 5.9GHz.
> >
> > You could do:
> > /* The max clock is 5.9GHz, split the divide */
> > u32 diff = (u32)(clock / 8) / (200/8);
>
> +1, as the issue is still present in current next, as per the recent
> nagging from the build bots.
Oops, s/next/upstream/.
Well, less 32-bit build testing for the next few days :-(
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: arm: ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/sun4i/sun4i-drm-hdmi.ko] undefined!
On Sat, Mar 9, 2024 at 3:34 PM David Laight wrote:
> From: Maxime Ripard
> > Sent: 04 March 2024 11:46
> >
> > On Mon, Mar 04, 2024 at 12:11:36PM +0100, Arnd Bergmann wrote:
> > > On Mon, Mar 4, 2024, at 09:07, Naresh Kamboju wrote:
> > > > The arm defconfig builds failed on today's Linux next tag next-20240304.
> > > >
> > > > Build log:
> > > > -
> > > > ERROR: modpost: "__aeabi_uldivmod"
> > > > [drivers/gpu/drm/sun4i/sun4i-drm-hdmi.ko] undefined!
> > > >
> > >
> > > Apparently caused by the 64-bit division in 358e76fd613a
> > > ("drm/sun4i: hdmi: Consolidate atomic_check and mode_valid"):
> > >
> > >
> > > +static enum drm_mode_status
> > > +sun4i_hdmi_connector_clock_valid(const struct drm_connector *connector,
> > > +const struct drm_display_mode *mode,
> > > +unsigned long long clock)
> > > {
> > > - struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
> > > - unsigned long rate = mode->clock * 1000;
> > > - unsigned long diff = rate / 200; /* +-0.5% allowed by HDMI spec */
> > > + const struct sun4i_hdmi *hdmi =
> > > drm_connector_to_sun4i_hdmi(connector);
> > > + unsigned long diff = clock / 200; /* +-0.5% allowed by HDMI spec
> > > */
> > > long rounded_rate;
> > >
> > > This used to be a 32-bit division. If the rate is never more than
> > > 4.2GHz, clock could be turned back into 'unsigned long' to avoid
> > > the expensive div_u64().
> >
> > I sent a fix for it this morning:
> > https://lore.kernel.org/r/20240304091225.366325-1-mrip...@kernel.org
> >
> > The framework will pass an unsigned long long because HDMI character
> > rates can go up to 5.9GHz.
>
> You could do:
> /* The max clock is 5.9GHz, split the divide */
> u32 diff = (u32)(clock / 8) / (200/8);
+1, as the issue is still present in current next, as per the recent
nagging from the build bots.
> The code should really use u32 and u64.
> Otherwise the sizes are different on 32bit.
The code is already using a variety of types (long, unsigned long long,
unsigned long) :-(
max_t(unsigned long, rounded_rate, clock) -
min_t(unsigned long, rounded_rate, clock) < diff)
At least u64 should make it very clear clock does not fit in 32-bit.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/6] auxdisplay/ht16k33: Replace use of fb_blank with backlight helper
On Wed, Mar 13, 2024 at 4:49 PM Thomas Zimmermann wrote:
> Replace the use of struct backlight_properties.fb_blank with a
> call to backlight_get_brightness(). The helper implement the same
> logic as the driver's function.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 11/14] s390: Add support for suppressing warning backtraces
Hi Günter,
On Tue, Mar 12, 2024 at 6:06 PM Guenter Roeck wrote:
> Add name of functions triggering warning backtraces to the __bug_table
> object section to enable support for suppressing WARNING backtraces.
>
> To limit image size impact, the pointer to the function name is only added
> to the __bug_table section if both CONFIG_KUNIT and CONFIG_DEBUG_BUGVERBOSE
> are enabled. Otherwise, the __func__ assembly parameter is replaced with a
> (dummy) NULL parameter to avoid an image size increase due to unused
> __func__ entries (this is necessary because __func__ is not a define but a
> virtual variable).
>
> Signed-off-by: Guenter Roeck
Thanks for your patch!
> --- a/arch/s390/include/asm/bug.h
> +++ b/arch/s390/include/asm/bug.h
> @@ -8,19 +8,30 @@
>
> #ifdef CONFIG_DEBUG_BUGVERBOSE
>
> +#if IS_ENABLED(CONFIG_KUNIT)
> +# define HAVE_BUG_FUNCTION
> +# define __BUG_FUNC_PTR" .long %0-.\n"
> +# define __BUG_FUNC__func__
> +#else
> +# define __BUG_FUNC_PTR
> +# define __BUG_FUNCNULL
> +#endif /* IS_ENABLED(CONFIG_KUNIT) */
> +
> #define __EMIT_BUG(x) do { \
> asm_inline volatile(\
> "0: mc 0,0\n" \
> ".section .rodata.str,\"aMS\",@progbits,1\n"\
> "1: .asciz \""__FILE__"\"\n" \
> ".previous\n" \
> - ".section __bug_table,\"awM\",@progbits,%2\n" \
> + ".section __bug_table,\"awM\",@progbits,%3\n" \
This change conflicts with commit 3938490e78f443fb ("s390/bug:
remove entry size from __bug_table section") in linus/master.
I guess it should just be dropped?
> "2: .long 0b-.\n" \
> " .long 1b-.\n" \
> - " .short %0,%1\n"\
> - " .org2b+%2\n"\
> + __BUG_FUNC_PTR \
> + " .short %1,%2\n"\
> + " .org2b+%3\n"\
> ".previous\n" \
> - : : "i" (__LINE__), \
> + : : "i" (__BUG_FUNC), \
> + "i" (__LINE__), \
> "i" (x),\
> "i" (sizeof(struct bug_entry)));\
> } while (0)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 08/43] drm/fbdev: Add fbdev-shmem
Hi Thomas,
On Wed, Mar 13, 2024 at 10:24 AM Thomas Zimmermann wrote:
> Am 13.03.24 um 10:03 schrieb Geert Uytterhoeven:
> > On Wed, Mar 13, 2024 at 9:19 AM Thomas Zimmermann
> > wrote:
> >> Am 12.03.24 um 17:14 schrieb Geert Uytterhoeven:
> >>> On Tue, Mar 12, 2024 at 4:48 PM Thomas Zimmermann
> >>> wrote:
> >>>> Add an fbdev emulation for SHMEM-based memory managers. The code is
> >>>> similar to fbdev-generic, but does not require an addition shadow
> >>>> buffer for mmap(). Fbdev-shmem operates directly on the buffer object's
> >>>> SHMEM pages. Fbdev's deferred-I/O mechanism updates the hardware state
> >>>> on write operations.
> >>>>
> >>>> Signed-off-by: Thomas Zimmermann
> >>> Thanks for your patch!
> >>>
> >>>> --- /dev/null
> >>>> +++ b/drivers/gpu/drm/drm_fbdev_shmem.c
> >>>> +static int drm_fbdev_shmem_helper_fb_probe(struct drm_fb_helper
> >>>> *fb_helper,
> >>>> + struct
> >>>> drm_fb_helper_surface_size *sizes)
> >>>> +{
> >>>> + struct drm_client_dev *client = _helper->client;
> >>>> + struct drm_device *dev = fb_helper->dev;
> >>>> + struct drm_client_buffer *buffer;
> >>>> + struct drm_gem_shmem_object *shmem;
> >>>> + struct drm_framebuffer *fb;
> >>>> + struct fb_info *info;
> >>>> + u32 format;
> >>>> + struct iosys_map map;
> >>>> + int ret;
> >>>> +
> >>>> + drm_dbg_kms(dev, "surface width(%d), height(%d) and bpp(%d)\n",
> >>>> + sizes->surface_width, sizes->surface_height,
> >>>> + sizes->surface_bpp);
> >>>> +
> >>>> + format = drm_mode_legacy_fb_format(sizes->surface_bpp,
> >>>> sizes->surface_depth);
> >>> Oops, one more caller of the imprecise
> >>> let's-guess-the-format-from-bpp-and-depth machinery to get rid of...
> >> Right, that has been discussed in another thread. I'll change this call
> >> to the drm_driver_() function.
> > You mean drm_driver_legacy_fb_format()? That has the same issues.
>
> We have the video= parameter with its bpp argument. So we won't ever
> fully remove that function.
For that to work with monochrome and greyscale displays, it should
fall back to DRM_FORMAT_Rx (or _Dx) if depth <= 8 and DRM_FORMAT_Cx
is not supported by the underlying primary plane or driver.
Hmm, perhaps I should indeed implement the fallback in
drm_driver_legacy_fb_format() instead of drm_fb_helper_find_format()
(like I did in [1]).
> >>>> + buffer = drm_client_framebuffer_create(client,
> >>>> sizes->surface_width,
> >>>> + sizes->surface_height,
> >>>> format);
> >>> [...]
> >>>
> >>>> +}
> >>>> +/**
> >>>> + * drm_fbdev_shmem_setup() - Setup fbdev emulation for GEM SHMEM helpers
> >>>> + * @dev: DRM device
> >>>> + * @preferred_bpp: Preferred bits per pixel for the device.
> >>>> + * 32 is used if this is zero.
> >>>> + *
> >>>> + * This function sets up fbdev emulation for GEM DMA drivers that
> >>>> support
> >>>> + * dumb buffers with a virtual address and that can be mmap'ed.
> >>>> + * drm_fbdev_shmem_setup() shall be called after the DRM driver
> >>>> registered
> >>>> + * the new DRM device with drm_dev_register().
> >>>> + *
> >>>> + * Restore, hotplug events and teardown are all taken care of. Drivers
> >>>> that do
> >>>> + * suspend/resume need to call drm_fb_helper_set_suspend_unlocked()
> >>>> themselves.
> >>>> + * Simple drivers might use drm_mode_config_helper_suspend().
> >>>> + *
> >>>> + * This function is safe to call even when there are no connectors
> >>>> present.
> >>>> + * Setup will be retried on the next hotplug event.
> >>>> + *
> >>>> + * The fbdev is destroyed by drm_dev_unregister().
> >>>> + */
> >>>> +void drm_fbdev_shmem_setup(struct drm_device *dev, unsigned int
> >>>> preferred_bpp)
> >>> As t
Re: [PATCH 08/43] drm/fbdev: Add fbdev-shmem
Hi Thomas,
On Wed, Mar 13, 2024 at 9:19 AM Thomas Zimmermann wrote:
> Am 12.03.24 um 17:14 schrieb Geert Uytterhoeven:
> > On Tue, Mar 12, 2024 at 4:48 PM Thomas Zimmermann
> > wrote:
> >> Add an fbdev emulation for SHMEM-based memory managers. The code is
> >> similar to fbdev-generic, but does not require an addition shadow
> >> buffer for mmap(). Fbdev-shmem operates directly on the buffer object's
> >> SHMEM pages. Fbdev's deferred-I/O mechanism updates the hardware state
> >> on write operations.
> >>
> >> Signed-off-by: Thomas Zimmermann
> > Thanks for your patch!
> >
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/drm_fbdev_shmem.c
> >> +static int drm_fbdev_shmem_helper_fb_probe(struct drm_fb_helper
> >> *fb_helper,
> >> + struct
> >> drm_fb_helper_surface_size *sizes)
> >> +{
> >> + struct drm_client_dev *client = _helper->client;
> >> + struct drm_device *dev = fb_helper->dev;
> >> + struct drm_client_buffer *buffer;
> >> + struct drm_gem_shmem_object *shmem;
> >> + struct drm_framebuffer *fb;
> >> + struct fb_info *info;
> >> + u32 format;
> >> + struct iosys_map map;
> >> + int ret;
> >> +
> >> + drm_dbg_kms(dev, "surface width(%d), height(%d) and bpp(%d)\n",
> >> + sizes->surface_width, sizes->surface_height,
> >> + sizes->surface_bpp);
> >> +
> >> + format = drm_mode_legacy_fb_format(sizes->surface_bpp,
> >> sizes->surface_depth);
> > Oops, one more caller of the imprecise
> > let's-guess-the-format-from-bpp-and-depth machinery to get rid of...
>
> Right, that has been discussed in another thread. I'll change this call
> to the drm_driver_() function.
You mean drm_driver_legacy_fb_format()? That has the same issues.
> >> + buffer = drm_client_framebuffer_create(client,
> >> sizes->surface_width,
> >> + sizes->surface_height,
> >> format);
> > [...]
> >
> >> +}
> >> +/**
> >> + * drm_fbdev_shmem_setup() - Setup fbdev emulation for GEM SHMEM helpers
> >> + * @dev: DRM device
> >> + * @preferred_bpp: Preferred bits per pixel for the device.
> >> + * 32 is used if this is zero.
> >> + *
> >> + * This function sets up fbdev emulation for GEM DMA drivers that support
> >> + * dumb buffers with a virtual address and that can be mmap'ed.
> >> + * drm_fbdev_shmem_setup() shall be called after the DRM driver registered
> >> + * the new DRM device with drm_dev_register().
> >> + *
> >> + * Restore, hotplug events and teardown are all taken care of. Drivers
> >> that do
> >> + * suspend/resume need to call drm_fb_helper_set_suspend_unlocked()
> >> themselves.
> >> + * Simple drivers might use drm_mode_config_helper_suspend().
> >> + *
> >> + * This function is safe to call even when there are no connectors
> >> present.
> >> + * Setup will be retried on the next hotplug event.
> >> + *
> >> + * The fbdev is destroyed by drm_dev_unregister().
> >> + */
> >> +void drm_fbdev_shmem_setup(struct drm_device *dev, unsigned int
> >> preferred_bpp)
> > As this is a completely new function, can we please get a
> > preferred_format parameter instead?
>
> An understandable question. But as it is, the patchset has a trivial
> change in each driver. And the preferred_bpp parameter has the same
> meaning as the bpp value in the video= parameter. So it's ok-ish for now.
OK.
> Using a format parameter here is really a much larger update and touches
> the internals of the fbdev emulation. I'm not even sure that we should
> have a parameter at all. Since in-kernel clients should behave like
> userspace clients, we could try to figure out the format from the
> driver's primary planes. That's a patchset of its own.
How do you figure out "the" format from the driver's primary plane?
Isn't that a list of formats (always including XR24) , so the driver
still needs to specify a preferred format?
A while ago, I had a look into replacing preferred_{depth,bpp} by
preferred_format, but I was held back by the inconsistencies in some
drivers (e.g. depth 24 vs. 32). Perhaps an incremental approach
(use preferred_format if available, else fall back to legacy
preferred_{depth,bpp} handling) would be more suitable?
FTR, my main use-case is letting fbdev emulation distinguish between
DRM_FORMAT_Rx and DRM_FORMAT_Cx, which share the values of depth
and bpp.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 08/43] drm/fbdev: Add fbdev-shmem
Hi Thomas,
On Tue, Mar 12, 2024 at 4:48 PM Thomas Zimmermann wrote:
> Add an fbdev emulation for SHMEM-based memory managers. The code is
> similar to fbdev-generic, but does not require an addition shadow
> buffer for mmap(). Fbdev-shmem operates directly on the buffer object's
> SHMEM pages. Fbdev's deferred-I/O mechanism updates the hardware state
> on write operations.
>
> Signed-off-by: Thomas Zimmermann
Thanks for your patch!
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_fbdev_shmem.c
> +static int drm_fbdev_shmem_helper_fb_probe(struct drm_fb_helper *fb_helper,
> + struct drm_fb_helper_surface_size
> *sizes)
> +{
> + struct drm_client_dev *client = _helper->client;
> + struct drm_device *dev = fb_helper->dev;
> + struct drm_client_buffer *buffer;
> + struct drm_gem_shmem_object *shmem;
> + struct drm_framebuffer *fb;
> + struct fb_info *info;
> + u32 format;
> + struct iosys_map map;
> + int ret;
> +
> + drm_dbg_kms(dev, "surface width(%d), height(%d) and bpp(%d)\n",
> + sizes->surface_width, sizes->surface_height,
> + sizes->surface_bpp);
> +
> + format = drm_mode_legacy_fb_format(sizes->surface_bpp,
> sizes->surface_depth);
Oops, one more caller of the imprecise
let's-guess-the-format-from-bpp-and-depth machinery to get rid of...
> + buffer = drm_client_framebuffer_create(client, sizes->surface_width,
> + sizes->surface_height, format);
[...]
> +}
> +/**
> + * drm_fbdev_shmem_setup() - Setup fbdev emulation for GEM SHMEM helpers
> + * @dev: DRM device
> + * @preferred_bpp: Preferred bits per pixel for the device.
> + * 32 is used if this is zero.
> + *
> + * This function sets up fbdev emulation for GEM DMA drivers that support
> + * dumb buffers with a virtual address and that can be mmap'ed.
> + * drm_fbdev_shmem_setup() shall be called after the DRM driver registered
> + * the new DRM device with drm_dev_register().
> + *
> + * Restore, hotplug events and teardown are all taken care of. Drivers that
> do
> + * suspend/resume need to call drm_fb_helper_set_suspend_unlocked()
> themselves.
> + * Simple drivers might use drm_mode_config_helper_suspend().
> + *
> + * This function is safe to call even when there are no connectors present.
> + * Setup will be retried on the next hotplug event.
> + *
> + * The fbdev is destroyed by drm_dev_unregister().
> + */
> +void drm_fbdev_shmem_setup(struct drm_device *dev, unsigned int
> preferred_bpp)
As this is a completely new function, can we please get a
preferred_format parameter instead?
> +{
> + struct drm_fb_helper *fb_helper;
> + int ret;
> +
> + drm_WARN(dev, !dev->registered, "Device has not been registered.\n");
> + drm_WARN(dev, dev->fb_helper, "fb_helper is already set!\n");
> +
> + fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
> + if (!fb_helper)
> + return;
> + drm_fb_helper_prepare(dev, fb_helper, preferred_bpp,
> _fbdev_shmem_helper_funcs);
> +
> + ret = drm_client_init(dev, _helper->client, "fbdev",
> _fbdev_shmem_client_funcs);
> + if (ret) {
> + drm_err(dev, "Failed to register client: %d\n", ret);
> + goto err_drm_client_init;
> + }
> +
> + drm_client_register(_helper->client);
> +
> + return;
> +
> +err_drm_client_init:
> + drm_fb_helper_unprepare(fb_helper);
> + kfree(fb_helper);
> +}
> +EXPORT_SYMBOL(drm_fbdev_shmem_setup);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 22/22] drm: ensure drm headers are self-contained and pass kernel-doc
Hi Jani,
On Thu, Mar 7, 2024 at 9:44 AM Jani Nikula wrote:
> On Thu, 07 Mar 2024, kernel test robot wrote:
> > kernel test robot noticed the following build errors:
>
> So I'm trying to make include/drm/ttm/ttm_caching.h self-contained by
> including with [1], but it fails like below.
>
> Cc: Thomas and Geert, better ideas for the include there? Looks like
> include/asm-generic/pgtable-nop4d.h isn't self-contained on m68k.
I have sent a fix
https://lore.kernel.org/r/ba359be013f379ff10f3afcea13e2f78dd9717be.1709804021.git.ge...@linux-m68k.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] m68k: pgtable: Add missing #include
When just including :
include/asm-generic/pgtable-nop4d.h:9:18: error: unknown type name ‘pgd_t’
9 | typedef struct { pgd_t pgd; } p4d_t;
| ^
Make self-contained by including .
Reported-by: Jani Nikula
Closes: https://lore.kernel.org/r/878r2uxwha@intel.com
Signed-off-by: Geert Uytterhoeven
---
Jani: Feel free to pick this up as a dependency.
Else I will queue this in the m68k tree for v6.10.
arch/m68k/include/asm/pgtable.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/m68k/include/asm/pgtable.h b/arch/m68k/include/asm/pgtable.h
index 27525c6a12fd0c7f..49fcfd7348600594 100644
--- a/arch/m68k/include/asm/pgtable.h
+++ b/arch/m68k/include/asm/pgtable.h
@@ -2,6 +2,8 @@
#ifndef __M68K_PGTABLE_H
#define __M68K_PGTABLE_H
+#include
+
#ifdef __uClinux__
#include
#else
--
2.34.1
Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
Hi Maxime,
On Mon, Mar 4, 2024 at 11:20 AM Maxime Ripard wrote:
> On Mon, Mar 04, 2024 at 11:07:22AM +0100, Geert Uytterhoeven wrote:
> > On Mon, Mar 4, 2024 at 10:15 AM Maxime Ripard wrote:
> > > On Mon, Mar 04, 2024 at 09:12:38AM +0100, Geert Uytterhoeven wrote:
> > > > On Sun, Mar 3, 2024 at 10:30 AM Geert Uytterhoeven
> > > > wrote:
> > > > ERROR: modpost: "__udivdi3" [drivers/gpu/drm/sun4i/sun4i-drm-hdmi.ko]
> > > > undefined!
> > > > make[3]: *** [scripts/Makefile.modpost:145: Module.symvers] Error 1
> > > > make[2]: *** [Makefile:1871: modpost] Error 2
> > > > make[1]: *** [Makefile:240: __sub-make] Error 2
> > > > make: *** [Makefile:240: __sub-make] Error 2
> > > >
> > > > No warnings found in log.
> > > > --->8---
> > >
> > > The driver is meant for a controller featured in an SoC with a Cortex-A8
> > > ARM CPU and less than a GiB/s memory bandwidth.
> >
> > Good, so the hardware cannot possibly need 64-bit pixel clock values ;-)
>
> This is an early patch to convert that function into a framework hook
> implementation. HDMI 2.1 has a max TMDS character rate of slightly less
> than 6GHz, so larger than 2^32 - 1.
>
> So yes, this driver doesn't need to. The framework does however.
That's gonna be interesting, as the Common Clock Framework does not
support 64-bit clock rates on 32-bit platforms yet...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v2] drm: renesas: shmobile: Call drm_helper_force_disable_all() at shutdown time
From: Douglas Anderson
Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown time.
This is important because drm_helper_force_disable_all() will cause
panels to get disabled cleanly which may be important for their power
sequencing. Future changes will remove any custom powering off in
individual panel drivers so the DRM drivers need to start getting this
right.
The fact that we should call drm_atomic_helper_shutdown() in the case of
OS shutdown comes straight out of the kernel doc "driver instance
overview" in drm_drv.c.
Suggested-by: Maxime Ripard
Signed-off-by: Douglas Anderson
Link:
https://lore.kernel.org/r/20230901164111.RFT.15.Iaf638a1d4c8b3c307a6192efabb4cbb06b195f15@changeid
[geert: s/drm_helper_force_disable_all/drm_atomic_helper_shutdown/]
[geert: shmob_drm_remove() already calls drm_atomic_helper_shutdown]
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
v2:
- Add Reviewed-by.
Tested on Atmark Techno Armadillo-800-EVA.
---
drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
index e83c3e52251dedf9..0250d5f00bf102dc 100644
--- a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
@@ -171,6 +171,13 @@ static void shmob_drm_remove(struct platform_device *pdev)
drm_kms_helper_poll_fini(ddev);
}
+static void shmob_drm_shutdown(struct platform_device *pdev)
+{
+ struct shmob_drm_device *sdev = platform_get_drvdata(pdev);
+
+ drm_atomic_helper_shutdown(>ddev);
+}
+
static int shmob_drm_probe(struct platform_device *pdev)
{
struct shmob_drm_platform_data *pdata = pdev->dev.platform_data;
@@ -273,6 +280,7 @@ static const struct of_device_id shmob_drm_of_table[]
__maybe_unused = {
static struct platform_driver shmob_drm_platform_driver = {
.probe = shmob_drm_probe,
.remove_new = shmob_drm_remove,
+ .shutdown = shmob_drm_shutdown,
.driver = {
.name = "shmob-drm",
.of_match_table = of_match_ptr(shmob_drm_of_table),
--
2.34.1
Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
Hi Maxime,
On Mon, Mar 4, 2024 at 10:15 AM Maxime Ripard wrote:
> On Mon, Mar 04, 2024 at 09:12:38AM +0100, Geert Uytterhoeven wrote:
> > On Sun, Mar 3, 2024 at 10:30 AM Geert Uytterhoeven
> > wrote:
> > > On Sun, Mar 3, 2024 at 3:30 AM Randy Dunlap wrote:
> > > > On 3/2/24 14:10, Guenter Roeck wrote:
> > > > > While checkpatch is indeed of arguable value, I think it would help a
> > > > > lot not having to bother about the persistent _build_ failures on
> > > > > 32-bit systems. You mentioned the fancy drm CI system above, but they
> > > > > don't run tests and not even test builds on 32-bit targets, which has
> > > > > repeatedly caused (and currently does cause) build failures in drm
> > > > > code when trying to build, say, arm:allmodconfig in linux-next. Most
> > > > > trivial build failures in linux-next (and, yes, sometimes mainline)
> > > > > could be prevented with a simple generic CI.
> > > >
> > > > Yes, definitely. Thanks for bringing that up.
> > >
> > > +1
> >
> > > Kisskb can send out email when builds get broken, and when they get
> > > fixed again. I receive such emails for the m68k builds.
> >
> > Like this (yes, one more in DRM; sometimes I wonder if DRM is meant only
> > for 64-bit little-endian platforms with +200 GiB/s memory bandwidth):
> >
> > ---8<---
> > Subject: kisskb: FAILED linux-next/m68k-allmodconfig/m68k-gcc8 Mon Mar 04,
> > 06:35
> > To: ge...@linux-m68k.org
> > Date: Mon, 04 Mar 2024 08:05:14 -
> >
> > FAILED linux-next/m68k-allmodconfig/m68k-gcc8 Mon Mar 04, 06:35
> >
> > http://kisskb.ellerman.id.au/kisskb/buildresult/15135537/
> >
> > Commit: Add linux-next specific files for 20240304
> > 67908bf6954b7635d33760ff6dfc189fc26ccc89
> > Compiler: m68k-linux-gcc (GCC) 8.5.0 / GNU ld (GNU Binutils) 2.36.1
> >
> > Possible errors
> > ---
> >
> > ERROR: modpost: "__udivdi3" [drivers/gpu/drm/sun4i/sun4i-drm-hdmi.ko]
> > undefined!
> > make[3]: *** [scripts/Makefile.modpost:145: Module.symvers] Error 1
> > make[2]: *** [Makefile:1871: modpost] Error 2
> > make[1]: *** [Makefile:240: __sub-make] Error 2
> > make: *** [Makefile:240: __sub-make] Error 2
> >
> > No warnings found in log.
> > ------->8---
>
> The driver is meant for a controller featured in an SoC with a Cortex-A8
> ARM CPU and less than a GiB/s memory bandwidth.
Good, so the hardware cannot possibly need 64-bit pixel clock values ;-)
BTW, doesn't the build fail on arm32, too?
> And I just sent a fix for that one, thanks for the report.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] drm/sun4i: hdmi: Fix u64 div on 32bit arch
Hi Maxime,
Thanks for your patch!
On Mon, Mar 4, 2024 at 10:12 AM Maxime Ripard wrote:
> Commit 358e76fd613a ("drm/sun4i: hdmi: Consolidate atomic_check and
> mode_valid") changed the clock rate from an unsigned long to an unsigned
> long long resulting in a a 64-bit division that might not be supported
> on all platforms.
Why was this changed to unsigned long long?
Can a valid pixel clock really not fit in 32-bit?
> The resulted in compilation being broken at least for m68k, xtensa and
> some arm configurations, at least.
>
> Fixes: 358e76fd613a ("drm/sun4i: hdmi: Consolidate atomic_check and
> mode_valid")
> Reported-by: Geert Uytterhoeven
> Reported-by: Naresh Kamboju
> Closes:
> https://lore.kernel.org/r/CA+G9fYvG9KE15PGNoLu+SBVyShe+u5HBLQ81+kK9Zop6u=y...@mail.gmail.com/
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202403011839.klixh4wc-...@intel.com/
> Signed-off-by: Maxime Ripard
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> @@ -163,11 +163,11 @@ static enum drm_mode_status
> sun4i_hdmi_connector_clock_valid(const struct drm_connector *connector,
> const struct drm_display_mode *mode,
> unsigned long long clock)
> {
> const struct sun4i_hdmi *hdmi =
> drm_connector_to_sun4i_hdmi(connector);
> - unsigned long diff = clock / 200; /* +-0.5% allowed by HDMI spec */
> + unsigned long diff = div_u64(clock, 200); /* +-0.5% allowed by HDMI
> spec */
I'd rather see clock changed back to unsigned long.
> long rounded_rate;
>
> if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> return MODE_BAD;
>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Sun, Mar 3, 2024 at 10:30 AM Geert Uytterhoeven wrote:
> On Sun, Mar 3, 2024 at 3:30 AM Randy Dunlap wrote:
> > On 3/2/24 14:10, Guenter Roeck wrote:
> > > While checkpatch is indeed of arguable value, I think it would help a
> > > lot not having to bother about the persistent _build_ failures on
> > > 32-bit systems. You mentioned the fancy drm CI system above, but they
> > > don't run tests and not even test builds on 32-bit targets, which has
> > > repeatedly caused (and currently does cause) build failures in drm
> > > code when trying to build, say, arm:allmodconfig in linux-next. Most
> > > trivial build failures in linux-next (and, yes, sometimes mainline)
> > > could be prevented with a simple generic CI.
> >
> > Yes, definitely. Thanks for bringing that up.
>
> +1
> Kisskb can send out email when builds get broken, and when they get
> fixed again. I receive such emails for the m68k builds.
Like this (yes, one more in DRM; sometimes I wonder if DRM is meant only
for 64-bit little-endian platforms with +200 GiB/s memory bandwidth):
---8<---
Subject: kisskb: FAILED linux-next/m68k-allmodconfig/m68k-gcc8 Mon Mar 04, 06:35
To: ge...@linux-m68k.org
Date: Mon, 04 Mar 2024 08:05:14 -
FAILED linux-next/m68k-allmodconfig/m68k-gcc8 Mon Mar 04, 06:35
http://kisskb.ellerman.id.au/kisskb/buildresult/15135537/
Commit: Add linux-next specific files for 20240304
67908bf6954b7635d33760ff6dfc189fc26ccc89
Compiler: m68k-linux-gcc (GCC) 8.5.0 / GNU ld (GNU Binutils) 2.36.1
Possible errors
---
ERROR: modpost: "__udivdi3" [drivers/gpu/drm/sun4i/sun4i-drm-hdmi.ko] undefined!
make[3]: *** [scripts/Makefile.modpost:145: Module.symvers] Error 1
make[2]: *** [Makefile:1871: modpost] Error 2
make[1]: *** [Makefile:240: __sub-make] Error 2
make: *** [Makefile:240: __sub-make] Error 2
No warnings found in log.
------->8---
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Sun, Mar 3, 2024 at 3:30 AM Randy Dunlap wrote:
> On 3/2/24 14:10, Guenter Roeck wrote:
> > On Thu, Feb 29, 2024 at 12:21 PM Linus Torvalds
> > wrote:
> >> On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov wrote:
> >>>
> >>> However, I think a better approach would be *not* to add the
> >>> .gitlab-ci.yaml
> >>> file in the root of the source tree, but instead change the very same repo
> >>> setting to point to a particular entry YAML, *inside* the repo (somewhere
> >>> under "ci" directory) instead.
> >>
> >> I really don't want some kind of top-level CI for the base kernel project.
> >>
> >> We already have the situation that the drm people have their own ci
> >> model. II'm ok with that, partly because then at least the maintainers
> >> of that subsystem can agree on the rules for that one subsystem.
> >>
> >> I'm not at all interested in having something that people will then
> >> either fight about, or - more likely - ignore, at the top level
> >> because there isn't some global agreement about what the rules are.
> >>
> >> For example, even just running checkpatch is often a stylistic thing,
> >> and not everybody agrees about all the checkpatch warnings.
> >
> > While checkpatch is indeed of arguable value, I think it would help a
> > lot not having to bother about the persistent _build_ failures on
> > 32-bit systems. You mentioned the fancy drm CI system above, but they
> > don't run tests and not even test builds on 32-bit targets, which has
> > repeatedly caused (and currently does cause) build failures in drm
> > code when trying to build, say, arm:allmodconfig in linux-next. Most
> > trivial build failures in linux-next (and, yes, sometimes mainline)
> > could be prevented with a simple generic CI.
>
> Yes, definitely. Thanks for bringing that up.
+1
> > Sure, argue against checkpatch as much as you like, but the code
> > should at least _build_, and it should not be necessary for random
> > people to report build failures to the submitters.
>
> I do 110 randconfig builds nightly (10 each of 11 $ARCH/$BITS).
> That's about all the horsepower that I have. and I am not a CI. :)
>
> So I see quite a bit of what you are saying. It seems that Arnd is
> in the same boat.
You don't even have to do your own builds (although it does help),
and can look at e.g. http://kisskb.ellerman.id.au/kisskb/
Kisskb can send out email when builds get broken, and when they get
fixed again. I receive such emails for the m68k builds.
I have the feeling this is not used up to its full potential yet.
My initial plan with the "Build regressions/improvements in ..." emails
[1] was to fully automate this, and enable it for the other daily builds
(e.g. linux-next), too, but there are only so many hours in a day...
[1] https://lore.kernel.org/all/20240226081253.3688538-1-ge...@linux-m68k.org/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 34/37] sh: Add dtbs target support.
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
wrote:
> Signed-off-by: Yoshinori Sato
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 13/37] dt-bindings: clock: sh7750-cpg: Add renesas,sh7750-cpg header.
Hi Sato-san,
Thanks for your patch!
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
wrote:
> SH7750 CPG Clock output define.
Please improve the patch description.
> Signed-off-by: Yoshinori Sato
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/renesas,sh7750-cpg.yaml
> @@ -0,0 +1,103 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/renesas,sh7750-cpg.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SH7750/7751 Clock Pulse Generator (CPG)
> +
> +maintainers:
> + - Yoshinori Sato
> +
> +description:
> + The Clock Pulse Generator (CPG) generates core clocks for the SoC. It
> + includes PLLs, and variable ratio dividers.
> +
> + The CPG may also provide a Clock Domain for SoC devices, in combination
> with
> + the CPG Module Stop (MSTP) Clocks.
> +
> +properties:
> + compatible:
> +enum:
> + - renesas,sh7750-cpg # SH7750
> + - renesas,sh7750s-cpg# SH775S
> + - renesas,sh7750r-cpg# SH7750R
> + - renesas,sh7751-cpg # SH7751
> + - renesas,sh7751r-cpg# SH7751R
> +
> + reg: true
> +
> + reg-names: true
> +
> + clocks: true
clocks:
maxItems: 1
> +
> + clock-names: true
clock-names:
const: extal
> +examples:
> + - |
> +#include
> +cpg: clock-controller@ffc0 {
> +#clock-cells = <1>;
> +#power-domain-cells = <0>;
> +compatible = "renesas,sh7751r-cpg";
> +clocks = <>;
> +clock-names = "xtal";
"extal"
"xtal" is an output pin, connected to a crystal resonator.
"extal" is the clock input put (either crystal resonator or exteral
clock input.
> +reg = <0xffc0 20>, <0xfe0a 16>;
> +reg-names = "FRQCR", "CLKSTP00";
> +renesas,mode = <0>;
> +};
> diff --git a/include/dt-bindings/clock/sh7750-cpg.h
> b/include/dt-bindings/clock/sh7750-cpg.h
> new file mode 100644
> index ..17d5a8076aac
> --- /dev/null
> +++ b/include/dt-bindings/clock/sh7750-cpg.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> + *
> + * Copyright 2023 Yoshinori Sato
> + */
> +
> +#ifndef __DT_BINDINGS_CLOCK_SH7750_H__
> +#define __DT_BINDINGS_CLOCK_SH7750_H__
> +
> +#define SH7750_CPG_PLLOUT 0
> +
> +#define SH7750_CPG_FCK 1
PCK?
> +#define SH7750_CPG_BCK 2
> +#define SH7750_CPG_ICK 3
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 15/37] clk: renesas: Add SH7750/7751 CPG Driver
CLK_GATE_REG_8BIT |
> CLK_GATE_SET_TO_DISABLE,
> + >clklock);
> + if (IS_ERR(reg_hw)) {
> + ret = PTR_ERR(reg_hw);
> + goto error;
> + }
> + data->hws[num_clk++] = reg_hw;
> + }
> + if (cpg->feat & MSTP_CLKSTP) {
> + for (i = 0; i < ARRAY_SIZE(clkstpout); i++) {
> + if (i == 2 && !(cpg->feat & MSTP_CSTP2))
> + continue;
Set maximum loop counter upfront?
> + reg_hw = clk_hw_register_clkstp(node, clkstpout[i],
> + divout[0],
> cpg->clkstp00,
> + i, >clklock);
> + if (IS_ERR(reg_hw)) {
> + ret = PTR_ERR(reg_hw);
> + goto error;
> + }
> + data->hws[num_clk++] = reg_hw;
> + }
> + }
> + data->num = num_clk;
> + ret = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, data);
> + if (ret < 0)
> + goto error;
> + return 0;
> +
> +error:
> + pr_err("%pOF: failed to register clock (%d)\n",
> + node, ret);
> + for (num_clk--; num_clk >= 0; num_clk--)
> + kfree(data->hws[num_clk]);
> + kfree(data);
> + return ret;
> +}
> +
> +static struct cpg_priv *sh7750_cpg_setup(struct device_node *node, u32 feat)
> +{
> + unsigned int num_parents;
> + u32 mode;
> + struct cpg_priv *cpg;
> + int ret = 0;
> +
> + num_parents = of_clk_get_parent_count(node);
> + if (num_parents < 1) {
> + pr_err("%s: no parent found", node->name);
> + return ERR_PTR(-ENODEV);
> + }
Do you need num_parents?
> +
> + of_property_read_u32_index(node, "renesas,mode", 0, );
mode may be used uninitialized, if "renesas,mode" is missing.
> + if (mode >= 7) {
> + pr_err("%s: Invalid clock mode setting (%u)\n",
> + node->name, mode);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + cpg = kzalloc(sizeof(struct cpg_priv), GFP_KERNEL);
> + if (!cpg)
> + return ERR_PTR(-ENOMEM);
> +
> + cpg->frqcr = of_iomap(node, 0);
> + if (cpg->frqcr == NULL) {
> + pr_err("%pOF: failed to map divide register", node);
> + ret = -ENODEV;
> + goto cpg_free;
> + }
> +
> + if (feat & MSTP_CLKSTP) {
> + cpg->clkstp00 = of_iomap(node, 1);
> + if (cpg->clkstp00 == NULL) {
> + pr_err("%pOF: failed to map clkstp00 register", node);
> + ret = -ENODEV;
> + goto unmap_frqcr;
> + }
> + }
> + cpg->feat = feat;
> + cpg->mode = mode;
> +
> + ret = register_pll(node, cpg);
> + if (ret < 0)
> + goto unmap_clkstp00;
> +
> + ret = register_div(node, cpg);
> + if (ret < 0)
> + goto unmap_clkstp00;
> +
Perhaps "cpg_data = cpg;" here, and return an error code instead? ...
> + return cpg;
> +
> +unmap_clkstp00:
> + iounmap(cpg->clkstp00);
> +unmap_frqcr:
> + iounmap(cpg->frqcr);
> +cpg_free:
> + kfree(cpg);
> + return ERR_PTR(ret);
> +}
> +
> +static void __init sh7750_cpg_init(struct device_node *node)
> +{
> + cpg_data = sh7750_cpg_setup(node, cpg_feature[CPG_SH7750]);
> + if (IS_ERR(cpg_data))
> + cpg_data = NULL;
... then all cpg_data handling can be removed here...
> +}
> +static int sh7750_cpg_probe(struct platform_device *pdev)
> +{
> + u32 feature;
> +
> + if (cpg_data)
> + return 0;
> + feature = *(u32 *)of_device_get_match_data(>dev);
> + cpg_data = sh7750_cpg_setup(pdev->dev.of_node, feature);
> + if (IS_ERR(cpg_data))
> + return PTR_ERR(cpg_data);
> + return 0;
... and this can be simplified to
return sh7750_cpg_setup(...);
> +}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 33/37] sh: j2_mimas_v2.dts update
Hi Sato-san,
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
wrote:
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
Please enhance the one-line summary, e.g.
sh: j2_mimas_v2: Update CPU compatible value
For the actual changes:
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 28/37] dt-bindings: soc: renesas: sh: Add SH7751 based target
Hi Sato-san,
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
wrote:
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/renesas/sh.yaml
> @@ -0,0 +1,32 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/renesas/sh.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SuperH Platform
> +
> +maintainers:
> + - Yoshinori Sato
> +
> +properties:
> + $nodename:
> +const: '/'
> + compatible:
> +oneOf:
> + - description: RTS7751R2D Plus
> +items:
> + - enum:
> + - renesas,rts7751r2d # Renesas SH4 2D graphics board
> + - const: renesas,sh7751r
> +
> + - description: Julian board
> +items:
> + - enum:
> + - iodata,landisk # LANDISK HDL-U
> + - iodata,usl-5p # USL-5P
> + - const: renesas,sh7751r
As both use the same fallback compatible value, I would just merge
them into a single section for SH7751R.
> +
> +additionalProperties: true
> +
> +...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 14/37] clk: Compatible with narrow registers
Hi Sato-san,
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
wrote:
> divider and gate only support 32-bit registers.
> Older hardware uses narrower registers, so I want to be able to handle
> 8-bit and 16-bit wide registers.
>
> Seven clk_divider flags are used, and if I add flags for 8bit access and
> 16bit access, 8bit will not be enough, so I expanded it to u16.
>
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
> --- a/drivers/clk/clk-gate.c
> +++ b/drivers/clk/clk-gate.c
> @@ -143,6 +161,18 @@ struct clk_hw *__clk_hw_register_gate(struct device *dev,
> return ERR_PTR(-EINVAL);
> }
Please add a check for invalid CLK_GATE_HIWORD_MASK
and register width combinations:
if (clk_gate_flags & (CLK_GATE_REG_16BIT | CLK_GATE_REG_8BIT)) {
pr_err("HIWORD_MASK needs 32-bit registers\n");
return ERR_PTR(-EINVAL);
}
> }
> + if (clk_gate_flags & CLK_GATE_REG_16BIT) {
> + if (bit_idx > 15) {
> + pr_err("gate bit exceeds 16 bits\n");
> + return ERR_PTR(-EINVAL);
> + }
> + }
> + if (clk_gate_flags & CLK_GATE_REG_8BIT) {
> + if (bit_idx > 7) {
> + pr_err("gate bit exceeds 8 bits\n");
> + return ERR_PTR(-EINVAL);
> + }
> + }
>
> /* allocate the gate */
> gate = kzalloc(sizeof(*gate), GFP_KERNEL);
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index ace3a4ce2fc9..e2dfc1f083f4 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -508,12 +508,16 @@ void of_fixed_clk_setup(struct device_node *np);
> * CLK_GATE_BIG_ENDIAN - by default little endian register accesses are used
> for
> * the gate register. Setting this flag makes the register accesses big
> * endian.
> + * CLK_GATE_REG_8BIT - by default 32bit register accesses are used for
> + * the gate register. Setting this flag makes the register accesses
> 8bit.
> + * CLK_GATE_REG_16BIT - by default 32bit register accesses are used for
> + * the gate register. Setting this flag makes the register accesses
> 16bit.
> */
> struct clk_gate {
> struct clk_hw hw;
> void __iomem*reg;
> u8 bit_idx;
> - u8 flags;
> + u32 flags;
There is no need to increase the size of the flags field for the gate clock.
> spinlock_t *lock;
> };
>
> @@ -522,6 +526,8 @@ struct clk_gate {
> #define CLK_GATE_SET_TO_DISABLEBIT(0)
> #define CLK_GATE_HIWORD_MASK BIT(1)
> #define CLK_GATE_BIG_ENDIANBIT(2)
> +#define CLK_GATE_REG_8BIT BIT(3)
> +#define CLK_GATE_REG_16BIT BIT(4)
>
> extern const struct clk_ops clk_gate_ops;
> struct clk_hw *__clk_hw_register_gate(struct device *dev,
The rest LGTM.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/6] arm64: dts: renesas: r8a774a1: Enable GPU
Hi Matt,
On Tue, Feb 27, 2024 at 10:31 AM Matt Coster wrote:
>
> Hi Adam,
>
> Thanks for these patches! I'll just reply to this one patch, but my
> comments apply to them all.
>
> On 27/02/2024 03:45, Adam Ford wrote:
> > The GPU on the RZ/G2M is a Rogue GX6250 which uses firmware
> > rogue_4.45.2.58_v1.fw available from Imagination.
> >
> > When enumerated, it appears as:
> > powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
> > powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
>
> These messages are printed after verifying the firmware blob’s headers,
> *before* attempting to upload it to the device. Just because they appear
> in dmesg does *not* imply the device is functional beyond the handful of
> register reads in pvr_load_gpu_id().
>
> Since Mesa does not yet have support for this GPU, there’s not a lot
> that can be done to actually test these bindings.
OK.
> When we added upstream support for the first GPU (the AXE core in TI’s
> AM62), we opted to wait until userspace was sufficiently progressed to
> the point it could be used for testing. This thought process still
> applies when adding new GPUs.
>
> Our main concern is that adding bindings for GPUs implies a level of
> support that cannot be tested. That in turn may make it challenging to
> justify UAPI changes if/when they’re needed to actually make these GPUs
> functional.
I guess that applies to "[PATCH 00/11] Device tree support for
Imagination Series5 GPU", too, which has been in linux-next for about
a month?
https://lore.kernel.org/all/20240109171950.31010-1-...@ti.com/
> > Signed-off-by: Adam Ford
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > index a8a44fe5e83b..8923d9624b39 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > @@ -2352,6 +2352,16 @@ gic: interrupt-controller@f101 {
> > resets = < 408>;
> > };
> >
> > + gpu: gpu@fd00 {
> > + compatible = "renesas,r8a774a1-gpu", "img,img-axe";
>
> The GX6250 is *not* an AXE core - it shouldn’t be listed as compatible
> with one. For prior art, see [1] where we added support for the MT8173
> found in Elm Chromebooks R13 (also a Series6XT GPU).
IC. And the bindings in [2].
>
> > + reg = <0 0xfd00 0 0x2>;
> > + clocks = < CPG_MOD 112>;
> > + clock-names = "core";
>
> Series6XT cores have three clocks (see [1] again). I don’t have a
> Renesas TRM to hand – do you know if their docs go into detail on the
> GPU integration?
Not really. The diagram in the Hardware User's Manual just shows the
following clock inputs:
- Clock (ZGϕ) from CPG,
- Clock (S3D1ϕ) from CPG,
- MSTP (ST112) from CPG.
ZG is the main (programmable) 3DGE clock, running at up to 600 MHz.
S3D1 is the fixed 266 MHz AXI bus clock.
MSTP112 is the gateable module clock (part of the SYSC/CPG clock
domain), and its parent is ZG.
According to the sources:
- "core" is the primary clock used by the entire GPU core, so we use
MSTP112 for that.
- "sys" is the optional system bus clock, so that could be S3D1,
- "mem" is the optional memory clock, no idea what that would map to.
But IMHO the two optional clocks do not matter at all (the driver
doesn't care about their rates, and just enables them together with
the core clock), and S3D1 is always-on, so I'd just limit clocks to
a single item.
Just wondering: is the availability of 1 clock specific to AXE, or to
the AXE integration on AM62x?
> + interrupts = ;
> + power-domains = < R8A774A1_PD_3DG_B>;
> + resets = < 112>;
> + };
> [1]:
> https://gitlab.freedesktop.org/imagination/linux/-/blob/b3506b8bc45ed6d4005eb32a994df0e33d6613f1/arch/arm64/boot/dts/mediatek/mt8173.dtsi#L993-1006
[2]
https://gitlab.freedesktop.org/imagination/linux/-/blob/b3506b8bc45ed6d4005eb32a994df0e33d6613f1/Documentation/devicetree/bindings/gpu/img,powervr.yaml
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/6] dt-bindings: gpu: powervr-rogue: Add PowerVR support for some Renesas GPUs
On Tue, Feb 27, 2024 at 9:09 AM Geert Uytterhoeven wrote:
> On Tue, Feb 27, 2024 at 8:48 AM Geert Uytterhoeven
> wrote:
> > On Tue, Feb 27, 2024 at 4:46 AM Adam Ford wrote:
> > > Update the binding to add support for various Renesas SoC's with PowerVR
> > > Rogue GX6250 and GX6650 GPUs. These devices only need one clock, so
> > > update
> > > the table to indicate such like what was done for the ti,am62-gpu.
> > >
> > > Signed-off-by: Adam Ford
>
> > > --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> > > +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
>
> > > + - renesas,r8a77951-gpu
> >
> > ... # PowerVR Series 6XT GX6650 on R-Car H3 ES2.0+
>
> All compatible values for R-Car H3 variants use the r8a7795 "base" value,
> so that should be:
>
> - renesas,r8a7795-gpu # PowerVR Series 6XT GX6650 on R-Car H3
Same for R-Car M3-W, so
- renesas,r8a77960-gpu # PowerVR Series 6XT GX6250 on R-Car M3-W
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 6/6] arm64: dts: renesas: r8a77961: Enable GPU
On Tue, Feb 27, 2024 at 4:46 AM Adam Ford wrote:
> The GPU on the R-Car M3-W+ is a Rogue GX6250 which uses firmware
> rogue_4.45.2.58_v1.fw available from Imagination.
>
> When enumerated, it appears as:
> powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
> powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
>
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 5/6] arm64: dts: renesas: r8a77960: Enable GPU
On Tue, Feb 27, 2024 at 4:46 AM Adam Ford wrote:
> The GPU on the R-Car M3-W is a Rogue GX6250 which uses firmware
> rogue_4.45.2.58_v1.fw available from Imagination.
>
> When enumerated, it appears as:
> powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
> powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
>
> Signed-off-by: Adam Ford
On Salvator-X with R-Car M3-W ES1.0:
powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
[drm] Initialized powervr 1.0.0 20230904 for fd00.gpu on minor 1
Reviewed-by: Geert Uytterhoeven
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 4/6] arm64: dts: renesas: r8a77951: Enable GPU
Hi Adam,
Thanks for your patch!
On Tue, Feb 27, 2024 at 4:46 AM Adam Ford wrote:
> The GPU on the R-Car H3 is a Rogue GX6650 which uses firmware
> rogue_4.46.6.61_v1.fw available from Imagination.
s/61/62/
>
> When enumerated, it appears as:
> powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.46.6.62_v1.fw
> powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
Do you have a different build number?
On Salvator-XS with R-Car H3 ES2.0:
powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.46.6.62_v1.fw
powervr fd00.gpu: [drm] FW version v1.0 (build 6538781 OS)
[drm] Initialized powervr 1.0.0 20230904 for fd00.gpu on minor 1
>
> Signed-off-by: Adam Ford
Tested-by: Geert Uytterhoeven
> --- a/arch/arm64/boot/dts/renesas/r8a77951.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
> @@ -2771,6 +2771,16 @@ gic: interrupt-controller@f101 {
> resets = < 408>;
> };
>
> + gpu: gpu@fd00 {
> + compatible = "renesas,r8a77951-gpu", "img,img-axe";
renesas,r8a7795-gpu
> + reg = <0 0xfd00 0 0x2>;
> + clocks = < CPG_MOD 112>;
> + clock-names = "core";
> + interrupts = ;
> + power-domains = < R8A7795_PD_3DG_E>;
> + resets = < 112>;
> + };
> +
> pciec0: pcie@fe00 {
> compatible = "renesas,pcie-r8a7795",
> "renesas,pcie-rcar-gen3";
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 3/6] arm64: dts: renesas: r8a774e1: Enable GPU
On Tue, Feb 27, 2024 at 4:46 AM Adam Ford wrote:
> The GPU on the RZ/G2H is a Rogue GX6650 which uses firmware
> rogue_4.46.6.62_v1.fw available from Imagination.
>
> When enumerated, it appears as:
> powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.46.6.62_v1.fw
> powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
>
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/6] arm64: dts: renesas: r8a774a1: Enable GPU
On Tue, Feb 27, 2024 at 4:46 AM Adam Ford wrote:
> The GPU on the RZ/G2M is a Rogue GX6250 which uses firmware
> rogue_4.45.2.58_v1.fw available from Imagination.
>
> When enumerated, it appears as:
> powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
> powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
>
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/6] dt-bindings: gpu: powervr-rogue: Add PowerVR support for some Renesas GPUs
Hi Adam,
On Tue, Feb 27, 2024 at 8:48 AM Geert Uytterhoeven wrote:
> On Tue, Feb 27, 2024 at 4:46 AM Adam Ford wrote:
> > Update the binding to add support for various Renesas SoC's with PowerVR
> > Rogue GX6250 and GX6650 GPUs. These devices only need one clock, so update
> > the table to indicate such like what was done for the ti,am62-gpu.
> >
> > Signed-off-by: Adam Ford
> > --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> > +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> > + - renesas,r8a77951-gpu
>
> ... # PowerVR Series 6XT GX6650 on R-Car H3 ES2.0+
All compatible values for R-Car H3 variants use the r8a7795 "base" value,
so that should be:
- renesas,r8a7795-gpu # PowerVR Series 6XT GX6650 on R-Car H3
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/6] dt-bindings: gpu: powervr-rogue: Add PowerVR support for some Renesas GPUs
On Tue, Feb 27, 2024 at 8:48 AM Geert Uytterhoeven wrote:
>
> Hi Adam,
>
> On Tue, Feb 27, 2024 at 4:46 AM Adam Ford wrote:
> > Update the binding to add support for various Renesas SoC's with PowerVR
> > Rogue GX6250 and GX6650 GPUs. These devices only need one clock, so update
> > the table to indicate such like what was done for the ti,am62-gpu.
> >
> > Signed-off-by: Adam Ford
>
> Thanks for your patch!
>
> > --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> > +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> > @@ -14,6 +14,11 @@ properties:
> >compatible:
> > items:
> >- enum:
> > + - renesas,r8a774a1-gpu
>
> I would add a comment like this:
>
> - renesas,r8a774a1-gpu # PowerVR Series 6XT GX6650 on RZ/G2M
After reading [1], s/Series 6XT/Series6XT/g.
[1] "[PATCH 00/11] Device tree support for Imagination Series5 GPU"
https://lore.kernel.org/all/20240109171950.31010-1-...@ti.com/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/6] dt-bindings: gpu: powervr-rogue: Add PowerVR support for some Renesas GPUs
Hi Adam,
On Tue, Feb 27, 2024 at 4:46 AM Adam Ford wrote:
> Update the binding to add support for various Renesas SoC's with PowerVR
> Rogue GX6250 and GX6650 GPUs. These devices only need one clock, so update
> the table to indicate such like what was done for the ti,am62-gpu.
>
> Signed-off-by: Adam Ford
Thanks for your patch!
> --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> @@ -14,6 +14,11 @@ properties:
>compatible:
> items:
>- enum:
> + - renesas,r8a774a1-gpu
I would add a comment like this:
- renesas,r8a774a1-gpu # PowerVR Series 6XT GX6650 on RZ/G2M
> + - renesas,r8a774e1-gpu
.. # PowerVR Series 6XT GX6650 on RZ/G2H
> + - renesas,r8a77951-gpu
... # PowerVR Series 6XT GX6650 on R-Car H3 ES2.0+
> + - renesas,r8a77960-gpu
... # PowerVR Series 6XT GX6250 on R-Car M3-W
> + - renesas,r8a77961-gpu
... # PowerVR Series 6XT GX6250 on R-Car M3-W+
>- ti,am62-gpu
>- const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
>
> @@ -51,7 +56,13 @@ allOf:
>properties:
> compatible:
>contains:
> -const: ti,am62-gpu
> +enum:
> + - ti,am62-gpu
> + - renesas,r8a774a1-gpu
> + - renesas,r8a774e1-gpu
> + - renesas,r8a77951-gpu
> + - renesas,r8a77960-gpu
> + - renesas,r8a77961-gpu
Please preserve alphabetical sort order.
> then:
>properties:
> clocks:
> --
> 2.43.0
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 08/37] clocksource: sh_tmu: CLOCKSOURCE support.
, "ch->tmu->name,".
> return;
> }
> }
>
> static int sh_tmu_register(struct sh_tmu_channel *ch, const char *name,
> + struct device_node *np,
np is unneeded.
>bool clockevent, bool clocksource)
> {
> if (clockevent) {
> ch->tmu->has_clockevent = true;
> - sh_tmu_register_clockevent(ch, name);
> + sh_tmu_register_clockevent(ch, name, np);
> } else if (clocksource) {
> ch->tmu->has_clocksource = true;
> sh_tmu_register_clocksource(ch, name);
> @@ -465,53 +477,59 @@ static int sh_tmu_channel_setup(struct sh_tmu_channel
> *ch, unsigned int index,
> else
> ch->base = tmu->mapbase + 8 + ch->index * 12;
>
> - ch->irq = platform_get_irq(tmu->pdev, index);
> + if (tmu->pdev)
> + ch->irq = platform_get_irq(tmu->pdev, index);
> + else
> + ch->irq = of_irq_get(np, index);
You can use of_irq_get() unconditionally.
> if (ch->irq < 0)
> return ch->irq;
>
> ch->cs_enabled = false;
> ch->enable_count = 0;
>
> - return sh_tmu_register(ch, dev_name(>pdev->dev),
> + return sh_tmu_register(ch, tmu->name, np,
No need to pass np.
>clockevent, clocksource);
> }
>
> -static int sh_tmu_map_memory(struct sh_tmu_device *tmu)
> +static int sh_tmu_map_memory(struct sh_tmu_device *tmu, struct device_node
> *np)
> {
> struct resource *res;
>
> - res = platform_get_resource(tmu->pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(>pdev->dev, "failed to get I/O memory\n");
> - return -ENXIO;
> - }
> + if (tmu->pdev) {
> + res = platform_get_resource(tmu->pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + pr_err("sh_tmu failed to get I/O memory\n");
> + return -ENXIO;
> + }
> +
> + tmu->mapbase = ioremap(res->start, resource_size(res));
> + } else
> + tmu->mapbase = of_iomap(np, 0);
You can use of_iomap() unconditionally.
>
> - tmu->mapbase = ioremap(res->start, resource_size(res));
> if (tmu->mapbase == NULL)
> return -ENXIO;
>
> return 0;
> }
>
> -static int sh_tmu_parse_dt(struct sh_tmu_device *tmu)
> +static int sh_tmu_parse_dt(struct sh_tmu_device *tmu, struct device_node *np)
> {
> - struct device_node *np = tmu->pdev->dev.of_node;
> -
> tmu->model = SH_TMU;
> tmu->num_channels = 3;
>
> of_property_read_u32(np, "#renesas,channels", >num_channels);
>
> if (tmu->num_channels != 2 && tmu->num_channels != 3) {
> - dev_err(>pdev->dev, "invalid number of channels %u\n",
> - tmu->num_channels);
> + pr_err("%s: invalid number of channels %u\n",
> + tmu->name, tmu->num_channels);
Please wrap the line after, not before, "ch->tmu->name,".
> return -EINVAL;
> }
>
> return 0;
> }
>
> -static int sh_tmu_setup(struct sh_tmu_device *tmu, struct platform_device
> *pdev)
> +static int sh_tmu_setup(struct sh_tmu_device *tmu,
> + struct platform_device *pdev, struct device_node *np)
> {
> unsigned int i;
> int ret;
> @@ -531,14 +554,17 @@ static int sh_tmu_setup(struct sh_tmu_device *tmu,
> struct platform_device *pdev)
> tmu->model = id->driver_data;
> tmu->num_channels = hweight8(cfg->channels_mask);
> } else {
> - dev_err(>pdev->dev, "missing platform data\n");
> + pr_err("%s missing platform data\n", tmu->name);
> return -ENXIO;
> }
>
> /* Get hold of clock. */
> - tmu->clk = clk_get(>pdev->dev, "fck");
> + if (pdev)
> + tmu->clk = clk_get(>pdev->dev, "fck");
> + else
> + tmu->clk = of_clk_get(np, 0);
You can use of_clk_get() unconditionally.
> if (IS_ERR(tmu->clk)) {
> - dev_err(>pdev->dev, "cannot get clock\n");
> + pr_err("%s: cannot get clock\n", tmu->name);
> return PTR_ERR(tmu->clk);
> }
>
> @@ -665,12 +711,17 @@ static void __exit sh_tmu_exit(void)
> platform_driver_unregister(_tmu_device_driver);
> }
>
> +subsys_initcall(sh_tmu_init);
> +module_exit(sh_tmu_exit);
> +#endif
> +
> #ifdef CONFIG_SUPERH
> +#ifdef CONFIG_SH_DEVICE_TREE
> +TIMER_OF_DECLARE(sh_tmu, "renesas,tmu", sh_tmu_of_register);
Probably this TIMER_OF_DECLARE() should be done unconditionally,
like is done in drivers/clocksource/renesas-ostm.c.
I gave that a try on R-Mobile A1, which also has TMU, but it didn't
seem to work (timer not firing?). So I suspect there are some missing
clk_enable() calls. In the case of the platform driver, these are
handled using pm_runtime_get_sync().
> +#else
> sh_early_platform_init("earlytimer", _tmu_device_driver);
> #endif
> -
> -subsys_initcall(sh_tmu_init);
> -module_exit(sh_tmu_exit);
> +#endif
>
> MODULE_AUTHOR("Magnus Damm");
> MODULE_DESCRIPTION("SuperH TMU Timer Driver");
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 02/37] sh: Kconfig unified OF supported targets.
Hi Sato-san,
On Tue, Jan 9, 2024 at 9:23 AM Yoshinori Sato
wrote:
> Targets that support OF should be treated as one board.
>
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
> --- a/arch/sh/Kconfig
> +++ b/arch/sh/Kconfig
> @@ -710,6 +710,7 @@ choice
> prompt "Kernel command line"
> optional
> default CMDLINE_OVERWRITE
> + depends on !OF || USE_BUILTIN_DTB
This is still useful in the generic OF case.
I think it would be good to model this similar to what arm/arm64/riscv
are using (from bootloader / extend / force).
> help
> Setting this option allows the kernel command line arguments
> to be set.
> diff --git a/arch/sh/boards/Kconfig b/arch/sh/boards/Kconfig
> index 109bec4dad94..e7e52779ef62 100644
> --- a/arch/sh/boards/Kconfig
> +++ b/arch/sh/boards/Kconfig
> @@ -19,16 +19,9 @@ config SH_DEVICE_TREE
> select TIMER_OF
> select COMMON_CLK
> select GENERIC_CALIBRATE_DELAY
> -
> -config SH_JCORE_SOC
> - bool "J-Core SoC"
> - select SH_DEVICE_TREE
> - select CLKSRC_JCORE_PIT
> - select JCORE_AIC
> - depends on CPU_J2
> - help
> - Select this option to include drivers core components of the
> - J-Core SoC, including interrupt controllers and timers.
> + select GENERIC_IRQ_CHIP
> + select SYS_SUPPORTS_PCI
> + select GENERIC_PCI_IOMAP if PCI
>
> config SH_SOLUTION_ENGINE
> bool "SolutionEngine"
> @@ -293,6 +286,7 @@ config SH_LANDISK
> bool "LANDISK"
> depends on CPU_SUBTYPE_SH7751R
> select HAVE_PCI
> + select SYS_SUPPORTS_PCI
> help
> I-O DATA DEVICE, INC. "LANDISK Series" support.
>
> @@ -369,6 +363,16 @@ config SH_APSH4AD0A
> help
> Select AP-SH4AD-0A if configuring for an ALPHAPROJECT AP-SH4AD-0A.
>
> +config SH_OF_BOARD
> + bool "General Open Firmware boards"
> + select SH_DEVICE_TREE
> + select CLKSRC_JCORE_PIT if CPU_J2
> + select JCORE_AIC if CPU_J2
Please move these selects to CPU_J2 instead...
> + select HAVE_PCI if CPU_SUBTYPE_SH7751R
... and this to CPU_SUBTYPE_SH7751R, else it will become
a long unmaintainable list soon...
> + help
> + This board means general OF supported targets.
> +
> +
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/6] drm/tests/drm_buddy: fix 32b build
Hi Matthew,
On Mon, Feb 26, 2024 at 10:58 AM Matthew Auld wrote:
> On 19/02/2024 12:24, Matthew Auld wrote:
> > On 19/02/2024 10:48, Matthew Auld wrote:
> >> On 19/02/2024 10:30, Christian König wrote:
> >>> Am 19.02.24 um 11:28 schrieb Matthew Auld:
> >>>> On 19/02/2024 09:53, Christian König wrote:
> >>>>> Am 19.02.24 um 10:42 schrieb Matthew Auld:
> >>>>>> On 15/02/2024 17:44, Matthew Auld wrote:
> >>>>>>> Doesn't seem to compile on 32b, presumably due to u64 mod/division.
> >>>>>>> Simplest is to just switch over to u32 here. Also make print
> >>>>>>> modifiers
> >>>>>>> consistent with that.
> >>>>>>>
> >>>>>>> Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous
> >>>>>>> test")
> >>>>>>> Reported-by: Geert Uytterhoeven
> >>>>>>> Signed-off-by: Matthew Auld
> >>>>>>> Cc: Arunpravin Paneer Selvam
> >>>>>>> Cc: Christian König
> >>>>>>> Cc: Maxime Ripard
> >>>>>>
> >>>>>> Any chance someone can push just this single patch here, since it
> >>>>>> fixes 32b build? It already has an r-b from Arun.
> >>>>>
> >>>>> Already working on this. Just give me a few more minutes.
> >>>>
> >>>> Thanks.
> >>>
> >>> No, problem. I would have pushed this earlier, but my build server
> >>> doesn't want to work any more. Looks like the SSD has passed its
> >>> warranty :(
> >>>
> >>> Should I push the other three patches to drm-misc-fixes as well? I
> >>> currently can't even build test them.
> >>
> >> Need to send a v2 for that. One minor change in the test just to be
> >> consistent with using u32. Thanks.
> >
> > Sent v2. If you could push that when you get a chance. Thanks.
> >
> > https://patchwork.freedesktop.org/series/130075/
>
> Gentle ping on merging v2.
Your v1 and a fix from Linus already made it upstream:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/gpu/drm/tests?h=v6.8-rc6
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] drm: renesas: rz-du: Fix redefinition errors related to rzg2l_du_vsp_*()
Hi Biju,
On Thu, Feb 22, 2024 at 10:56 AM Biju Das wrote:
> Fix the redefinition errors for the below functions on x86 by replacing
Not just on x86, I assume?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: linux-next: build failure after merge of the drm-misc tree
Hi Biju,
On Thu, Feb 22, 2024 at 9:14 AM Biju Das wrote:
> > -Original Message-
> > From: Stephen Rothwell
> > Sent: Thursday, February 22, 2024 1:46 AM
> > Subject: linux-next: build failure after merge of the drm-misc tree
> >
> > After merging the drm-misc tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c:47:6: error: redefinition of
> > 'rzg2l_du_vsp_enable'
> >47 | void rzg2l_du_vsp_enable(struct rzg2l_du_crtc *crtc)
> > | ^~~
> > In file included from drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h:18,
> > from drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c:30:
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h:72:20: note: previous
> > definition of 'rzg2l_du_vsp_enable' with type 'void(struct rzg2l_du_crtc
> > *)'
> >72 | static inline void rzg2l_du_vsp_enable(struct rzg2l_du_crtc *crtc)
> > { };
> > |^~~
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c:61:6: error: redefinition of
> > 'rzg2l_du_vsp_disable'
> >61 | void rzg2l_du_vsp_disable(struct rzg2l_du_crtc *crtc)
> > | ^~~~
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h:73:20: note: previous
> > definition of 'rzg2l_du_vsp_disable' with type 'void(struct rzg2l_du_crtc
> > *)'
> >73 | static inline void rzg2l_du_vsp_disable(struct rzg2l_du_crtc
> > *crtc) { };
> > |^~~~
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c:66:6: error: redefinition of
> > 'rzg2l_du_vsp_atomic_flush'
> >66 | void rzg2l_du_vsp_atomic_flush(struct rzg2l_du_crtc *crtc)
> > | ^
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h:74:20: note: previous
> > definition of 'rzg2l_du_vsp_atomic_flush' with type 'void(struct
> > rzg2l_du_crtc *)'
> >74 | static inline void rzg2l_du_vsp_atomic_flush(struct rzg2l_du_crtc
> > *crtc) { };
> > |^
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c:76:19: error: redefinition of
> > 'rzg2l_du_vsp_get_drm_plane'
> >76 | struct drm_plane *rzg2l_du_vsp_get_drm_plane(struct rzg2l_du_crtc
> > *crtc,
> > | ^~
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h:75:33: note: previous
> > definition of 'rzg2l_du_vsp_get_drm_plane' with type 'struct drm_plane
> > *(struct rzg2l_du_crtc *, unsigned int)'
> >75 | static inline struct drm_plane *rzg2l_du_vsp_get_drm_plane(struct
> > rzg2l_du_crtc *crtc,
> > | ^~
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c:302:5: error: redefinition of
> > 'rzg2l_du_vsp_init'
> > 302 | int rzg2l_du_vsp_init(struct rzg2l_du_vsp *vsp, struct device_node
> > *np,
> > | ^
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h:66:19: note: previous
> > definition of 'rzg2l_du_vsp_init' with type 'int(struct rzg2l_du_vsp *,
> > struct device_node *, unsigned int)'
> >66 | static inline int rzg2l_du_vsp_init(struct rzg2l_du_vsp *vsp,
> > struct device_node *np,
> > | ^
> >
> > Caused by commit
> >
> > 768e9e61b3b9 ("drm: renesas: Add RZ/G2L DU Support")
> >
> > I have used the drm-misc tree from next-20240221 for today.
>
> I will send an incremental patch to fix this build error with x86 on drm-next.
>
> I need to use the macro #if IS_ENABLED(CONFIG_VIDEO_RENESAS_VSP1)
> in drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h to fix this error.
Looks like you're also missing an EXPORT_SYMBOL_GPL(rzg2l_du_vsp_enable)?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: Build regressions/improvements in v6.8-rc5
On Mon, 19 Feb 2024, Geert Uytterhoeven wrote:
JFYI, when comparing v6.8-rc5[1] to v6.8-rc4[3], the summaries are:
- build errors: +6/-14
+ /kisskb/src/arch/arm64/include/asm/jump_label.h: error: invalid 'asm': invalid
operand: => 25:2
arm64-gcc5/arm64-allmodconfig
+ /kisskb/src/arch/sparc/kernel/setup_64.c: error: no previous prototype for
'alloc_irqstack_bootmem' [-Werror=missing-prototypes]: => 602:13
sparc64-gcc{5,13}/sparc64-{allmod,allno,def}config
+ /kisskb/src/arch/sparc/kernel/time_64.c: error: no previous prototype for
'sched_clock' [-Werror=missing-prototypes]: => 880:20
sparc64-gcc5/sparc64-{allmod,allno,def}config
sparc64-gcc13/sparc64-{allno,def}config
+ error: modpost: "__moddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko]
undefined!: => N/A
+ error: modpost: "__umoddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko]
undefined!: => N/A
m68k-gcc8/m68k-allmodconfig
xtensa-gcc13/xtensa-allmodconfig
parisc-gcc13/parisc-allmodconfig
Fixes available
+ {standard input}: Error: unknown pseudo-op: `.cfi_def_cfa_offse': => 605
SH ICE crickets
[1]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/b401b621758e46812da61fa58a67c3fd8d91de0d/
(144 out of 239 configs)
[3]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/841c35169323cd833294798e58b9bf63fa4fa1de/
(238 out of 239 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: Re: [PULL] drm-misc-fixes
Hi Maxime, Dave,
On Thu, Feb 15, 2024 at 5:45 PM Geert Uytterhoeven wrote:
> On Thu, Feb 15, 2024 at 5:09 PM Maxime Ripard wrote:
> On Thu, Feb 15, 2024 at 01:41:24PM +0100, Geert Uytterhoeven wrote:
> > > On Thu, 15 Feb 2024, Maxime Ripard wrote:
> > > > Matthew Auld (1):
> > > > drm/tests/drm_buddy: add alloc_contiguous test
> > >
> > > Please drop this one.
> > >
> > > nore...@ellerman.id.au reported a build failure on m68k (and presumably
> > > other 32-bit platforms) in next-20240215:
> > >
> > > ERROR: modpost: "__umoddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko]
> > > undefined!
> > > ERROR: modpost: "__moddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko]
> > > undefined!
> > >
> > > Reverting commit a64056bb5a3215bd ("drm/tests/drm_buddy: add
> > > alloc_contiguous test") fixes the issue.
> >
> > From a quick cross-compile test with arm(32), it seems to work there
> > interestingly:
> >
> > ./tools/testing/kunit/kunit.py run \
> > --kunitconfig=drivers/gpu/drm//tests \
> > --cross_compile arm-linux-gnu- --arch arm
>
> shmobile_defconfig + CONFIG_DRM_KUNIT_TEST=y + CONFIG_KUNIT=y:
>
> arm-linux-gnueabihf-ld: drivers/gpu/drm/tests/drm_buddy_test.o: in
> function `drm_test_buddy_alloc_contiguous':
> drm_buddy_test.c:(.text+0xe0): undefined reference to `__aeabi_uldivmod'
>
> > But I agree, with should wait for a fix or a revert before merging this.
>
> Great, thanks!
Unfortunately the breakage still made it upstream.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
Hi Maxime,
On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard wrote:
> On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > proprietary firmware image, which is currently only available for Texas
> > Instruments K3 AM62x SoCs. Hence add a dependency on ARCH_K3, to
> > prevent asking the user about this driver when configuring a kernel
> > without Texas Instruments K3 Multicore SoC support.
>
> This wasn't making sense the first time you sent it, and now that commit
> log is just plain wrong. We have firmwares for the G6110, GX6250,
> GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
> Renesas, Mediatek, Rockchip, TI and StarFive, so across three
I am so happy to be proven wrong!
Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.
> architectures and 5 platforms. In two months.
That sounds like great progress, thanks a lot!
Where can I find these firmwares? Linux-firmware[1] seems to lack all
but the original K3 AM62x one.
Thanks again!
[1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: Re: [PULL] drm-misc-fixes
Hi Maxime,
On Thu, Feb 15, 2024 at 5:09 PM Maxime Ripard wrote:
On Thu, Feb 15, 2024 at 01:41:24PM +0100, Geert Uytterhoeven wrote:
> > On Thu, 15 Feb 2024, Maxime Ripard wrote:
> > > Matthew Auld (1):
> > > drm/tests/drm_buddy: add alloc_contiguous test
> >
> > Please drop this one.
> >
> > nore...@ellerman.id.au reported a build failure on m68k (and presumably
> > other 32-bit platforms) in next-20240215:
> >
> > ERROR: modpost: "__umoddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko]
> > undefined!
> > ERROR: modpost: "__moddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko]
> > undefined!
> >
> > Reverting commit a64056bb5a3215bd ("drm/tests/drm_buddy: add
> > alloc_contiguous test") fixes the issue.
>
> From a quick cross-compile test with arm(32), it seems to work there
> interestingly:
>
> ./tools/testing/kunit/kunit.py run \
> --kunitconfig=drivers/gpu/drm//tests \
> --cross_compile arm-linux-gnu- --arch arm
shmobile_defconfig + CONFIG_DRM_KUNIT_TEST=y + CONFIG_KUNIT=y:
arm-linux-gnueabihf-ld: drivers/gpu/drm/tests/drm_buddy_test.o: in
function `drm_test_buddy_alloc_contiguous':
drm_buddy_test.c:(.text+0xe0): undefined reference to `__aeabi_uldivmod'
> But I agree, with should wait for a fix or a revert before merging this.
Great, thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v2] drm: Spelling s/hardward/hardware/g
Fix misspellings of "hardware".
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Neil Armstrong
Reviewed-by: Thomas Zimmermann
---
v2:
- Add Reviewed-by.
---
include/drm/drm_bridge.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index e39da5807ba71c2d..57d647722cf79704 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -107,7 +107,7 @@ struct drm_bridge_funcs {
* Since this function is both called from the check phase of an atomic
* commit, and the mode validation in the probe paths it is not allowed
* to look at anything else but the passed-in mode, and validate it
-* against configuration-invariant hardward constraints. Any further
+* against configuration-invariant hardware constraints. Any further
* limits which depend upon the configuration can only be checked in
* @mode_fixup.
*
--
2.34.1
[PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
Using the Imagination Technologies PowerVR Series 6 GPU requires a
proprietary firmware image, which is currently only available for Texas
Instruments K3 AM62x SoCs. Hence add a dependency on ARCH_K3, to
prevent asking the user about this driver when configuring a kernel
without Texas Instruments K3 Multicore SoC support.
Fixes: 4babef0708656c54 ("drm/imagination: Add skeleton PowerVR driver")
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Nishanth Menon
---
v2:
- Add Reviewed-by,
- Clarify the firmware dependency.
---
drivers/gpu/drm/imagination/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/imagination/Kconfig
b/drivers/gpu/drm/imagination/Kconfig
index 3bfa2ac212dccb73..af492dbd9afd4ed9 100644
--- a/drivers/gpu/drm/imagination/Kconfig
+++ b/drivers/gpu/drm/imagination/Kconfig
@@ -6,6 +6,7 @@ config DRM_POWERVR
depends on ARM64
depends on DRM
depends on PM
+ depends on ARCH_K3 || COMPILE_TEST
select DRM_EXEC
select DRM_GEM_SHMEM_HELPER
select DRM_SCHED
--
2.34.1
Re: [PULL] drm-misc-fixes
Hi Maxime,
On Thu, 15 Feb 2024, Maxime Ripard wrote:
Here's this week drm-misc-fixes PR
Maxime
drm-misc-fixes-2024-02-15:
A suspend/resume error fix for ivpu, a couple of scheduler fixes for
nouveau, a patch to support large page arrays in prime, a uninitialized
variable fix in crtc, a locking fix in rockchip/vop2 and a buddy
allocator error reporting fix.
The following changes since commit 5f8408aca66772d3aa9b4831577b2ac5ec41bcd9:
accel/ivpu: Add job status for jobs aborted by the driver (2024-02-06 13:37:34
+0100)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2024-02-15
for you to fetch changes up to a64056bb5a3215bd31c8ce17d609ba0f4d5c55ea:
drm/tests/drm_buddy: add alloc_contiguous test (2024-02-14 15:22:21 +0100)
A suspend/resume error fix for ivpu, a couple of scheduler fixes for
nouveau, a patch to support large page arrays in prime, a uninitialized
variable fix in crtc, a locking fix in rockchip/vop2 and a buddy
allocator error reporting fix.
Matthew Auld (1):
drm/tests/drm_buddy: add alloc_contiguous test
Please drop this one.
nore...@ellerman.id.au reported a build failure on m68k (and presumably
other 32-bit platforms) in next-20240215:
ERROR: modpost: "__umoddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined!
ERROR: modpost: "__moddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined!
Reverting commit a64056bb5a3215bd ("drm/tests/drm_buddy: add
alloc_contiguous test") fixes the issue.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] ARM: multi_v7_defconfig: Enable BACKLIGHT_CLASS_DEVICE
Hi Marek,
On Fri, Feb 2, 2024 at 10:51 AM Marek Szyprowski
wrote:
> Commit 72fee6b0a3a4 ("fbdev: Restrict FB_SH_MOBILE_LCDC to SuperH")
> disabled availablity of the SH_MOBILE_LCDC driver on the RENESAS arch.
> This innocent change has a significant side-effect on the ARM's
> multi_v7_defconfig, because FB_BACKLIGHT symbol is no longer selected,
> what in turn leaves BACKLIGHT_CLASS_DEVICE symbol selected only as
> a module. The latter disables some backlight related code in the DRM
Oops, sorry for that.
> core, because the DRM core is set to be compiled-in in this defconfig.
> This leaves all DRM display panels without integrated backlight control,
> even if the needed modules have been properly loaded and probed.
Hmm, that's bad.
Is there any way to fix this in DRM?
A quick grep shows that DRM is using the full monty of
IS_{BUILTIN,ENABLED,MODULE,REACHABLE}(CONFIG_BACKLIGHT_CLASS_DEVICE).
Probably not all of them are in perfect sync?
Several DRM drivers do select BACKLIGHT_CLASS_DEVICE, but if that
does not work in the modular case, it should be fixed.
> Fix this by selecting BACKLIGHT_CLASS_DEVICE to be compiled-in in
> multi_v7_defconfig.
>
> Signed-off-by: Marek Szyprowski
Sounds like a good interim solution.
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] fbdev: Restrict FB_SH_MOBILE_LCDC to SuperH
Since commit f402f7a02af6956d ("staging: board: Remove Armadillo-800-EVA
board staging code"), there are no more users of the legacy SuperH
Mobile LCDC framebuffer driver on Renesas ARM platforms. All former
users on these platforms have been converted to the SH-Mobile DRM
driver, using DT.
Suggested-by: Arnd Bergmann
Signed-off-by: Geert Uytterhoeven
---
Commit f402f7a02af6956d is in staging-next (next-20240129 and later).
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 2d0bcc1d786e50bb..b688900bb67eed55 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1554,7 +1554,7 @@ config FB_FSL_DIU
config FB_SH_MOBILE_LCDC
tristate "SuperH Mobile LCDC framebuffer support"
depends on FB && HAVE_CLK && HAS_IOMEM
- depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
+ depends on SUPERH || COMPILE_TEST
depends on FB_DEVICE
select FB_BACKLIGHT
select FB_DEFERRED_IO
--
2.34.1
Re: Build regressions/improvements in v6.8-rc1
On Tue, 23 Jan 2024, Geert Uytterhoeven wrote:
Below is the list of build error/warning regressions/improvements in
v6.8-rc1[1] compared to v6.7[2].
Summarized:
- build errors: +68/-18
- build warnings: +129/-1487
Happy fixing! ;-)
Thanks to the linux-next team for providing the build service.
[1]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/6613476e225e090cc9aad49be7fa504e290dd33d/
(all 239 configs)
[2]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/0dd3ee31125508cd67f7e7172247f05b7fd1753a/
(all 239 configs)
*** ERRORS ***
68 error regressions:
+ /kisskb/src/arch/powerpc/sysdev/udbg_memcons.c: error: no previous prototype
for 'memcons_getc' [-Werror=missing-prototypes]: => 80:5
+ /kisskb/src/arch/powerpc/sysdev/udbg_memcons.c: error: no previous prototype
for 'memcons_getc_poll' [-Werror=missing-prototypes]: => 57:5
+ /kisskb/src/arch/powerpc/sysdev/udbg_memcons.c: error: no previous prototype
for 'memcons_putc' [-Werror=missing-prototypes]: => 44:6
powerpc-gcc{5,12,13}/ppc64_book3e_allmodconfig
+ /kisskb/src/arch/sh/kernel/cpu/init.c: error: no previous prototype for
'l2_cache_init' [-Werror=missing-prototypes]: => 99:29
sh4-gcc1[123]/se7{619,750}_defconfig
sh4-gcc1[123]/sh-{all{mod,no,yes},def}config
sh4-gcc11/sh-allnoconfig
+ /kisskb/src/arch/sh/math-emu/math.c: error: no previous prototype for
'do_fpu_inst' [-Werror=missing-prototypes]: => 492:5
sh4-gcc1[123]/sh-all{mod,yes}config
+ /kisskb/src/arch/sh/mm/cache-sh2.c: error: no previous prototype for
'sh2_cache_init' [-Werror=missing-prototypes]: => 85:13
sh4-gcc1[123]/se7619_defconfig
sh4-gcc1[123]/sh-all{mod,yes}config
+ /kisskb/src/arch/sh/mm/nommu.c: error: no previous prototype for
'kmap_coherent' [-Werror=missing-prototypes]: => 80:7
+ /kisskb/src/arch/sh/mm/nommu.c: error: no previous prototype for
'kmap_coherent_init' [-Werror=missing-prototypes]: => 76:13
+ /kisskb/src/arch/sh/mm/nommu.c: error: no previous prototype for
'kunmap_coherent' [-Werror=missing-prototypes]: => 86:6
sh4-gcc1[123]/se7619_defconfig
sh4-gcc1[123]/sh-allnoconfig
sh4-gcc12/sh-allyesconfig
+ /kisskb/src/arch/sparc/include/asm/floppy_64.h: error: no previous prototype
for 'sparc_floppy_irq' [-Werror=missing-prototypes]: => 200:13
+ /kisskb/src/arch/sparc/include/asm/floppy_64.h: error: no previous prototype
for 'sun_pci_fd_dma_callback' [-Werror=missing-prototypes]: => 437:6
sparc64-gcc{5,11,12,13}/sparc64-allmodconfig
+ /kisskb/src/arch/sparc/kernel/traps_64.c: error: no previous prototype for
'do_mcd_err' [-Werror=missing-prototypes]: => 2035:6
+ /kisskb/src/arch/sparc/kernel/traps_64.c: error: no previous prototype for
'is_no_fault_exception' [-Werror=missing-prototypes]: => 253:6
+ /kisskb/src/arch/sparc/kernel/traps_64.c: error: no previous prototype for
'sun4v_nonresum_error_user_handled' [-Werror=missing-prototypes]: => 2153:6
+ /kisskb/src/arch/sparc/prom/misc_64.c: error: no previous prototype for
'prom_get_mmu_ihandle' [-Werror=missing-prototypes]: => 165:5
+ /kisskb/src/arch/sparc/prom/p1275.c: error: no previous prototype for
'prom_cif_init' [-Werror=missing-prototypes]: => 52:6
+ /kisskb/src/kernel/dma.c: error: no previous prototype for 'free_dma'
[-Werror=missing-prototypes]: => 88:6
+ /kisskb/src/kernel/dma.c: error: no previous prototype for 'request_dma'
[-Werror=missing-prototypes]: => 70:5
sparc64-gcc{5,1[123]}/sparc64-{all{mod,no},def}config
+ /kisskb/src/arch/sparc/lib/cmpdi2.c: error: no previous prototype for
'__cmpdi2' [-Werror=missing-prototypes]: => 6:11
sparc64-gcc{5,1[123]}/sparc-{all{mod,no},def}config
+ /kisskb/src/arch/sparc/mm/init_64.c: error: no previous prototype for
'vmemmap_free' [-Werror=missing-prototypes]: => 2644:6
sparc64-gcc{5,1[123]}/sparc64-{allmod,def}config
+ /kisskb/src/arch/sparc/power/hibernate.c: error: no previous prototype for
'pfn_is_nosave' [-Werror=missing-prototypes]: => 22:5
+ /kisskb/src/arch/sparc/power/hibernate.c: error: no previous prototype for
'restore_processor_state' [-Werror=missing-prototypes]: => 35:6
+ /kisskb/src/arch/sparc/power/hibernate.c: error: no previous prototype for
'save_processor_state' [-Werror=missing-prototypes]: => 30:6
+ /kisskb/src/drivers/gpu/drm/xe/xe_lrc.c: error: "CTX_VALID" redefined
[-Werror]: => 24, 24:0
+ /kisskb/src/drivers/mtd/maps/sun_uflash.c: error: no previous prototype for
'uflash_devinit' [-Werror=missing-prototypes]: => 50:5
sparc64-gcc{5,1[123]}/sparc64-allmodconfig
+ /kisskb/src/arch/sparc/vdso/vclock_gettime.c: error: no previous prototype for
'__vdso_clock_gettime' [-Werror=missing-prototypes]: => 254:1
+ /kisskb/src/arch/sparc/vdso/vclock_gettime.c: error: no previous prototype for
'__vdso_clock_gettime_stick' [-Werror=missing-prototypes]: => 282:1
+ /kisskb/src/arch/sparc/vdso/vclock_gettime.c: error: no previous proto
[PATCH] fbcon: Fix incorrect printed function name in fbcon_prepare_logo()
If the boot logo does not fit, a message is printed, including a wrong
function name prefix. Instead of correcting the function name (or using
__func__), just use "fbcon", like is done in several other messages.
While at it, modernize the call by switching to pr_info().
Signed-off-by: Geert Uytterhoeven
---
drivers/video/fbdev/core/fbcon.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 63af6ab034b5f1bb..1183e7a871f8b270 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -631,8 +631,7 @@ static void fbcon_prepare_logo(struct vc_data *vc, struct
fb_info *info,
if (logo_lines > vc->vc_bottom) {
logo_shown = FBCON_LOGO_CANSHOW;
- printk(KERN_INFO
- "fbcon_init: disable boot-logo (boot-logo bigger than
screen).\n");
+ pr_info("fbcon: disable boot-logo (boot-logo bigger than
screen).\n");
} else {
logo_shown = FBCON_LOGO_DRAW;
vc->vc_top = logo_lines;
--
2.34.1
Re: [PATCH 19/45] tty: vt: make init parameter of consw::con_init() a bool
Hi Jiri,
On Thu, Jan 18, 2024 at 9:03 AM Jiri Slaby (SUSE) wrote:
> The 'init' parameter of consw::con_init() is true for the first call of
> the hook on a particular console. So make the parameter a bool.
>
> And document the hook.
>
> Signed-off-by: Jiri Slaby (SUSE)
Thanks for your patch!
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -367,7 +367,7 @@ static const char *vgacon_startup(void)
> return display_desc;
> }
>
> -static void vgacon_init(struct vc_data *c, int init)
> +static void vgacon_init(struct vc_data *c, bool init)
> {
> struct uni_pagedict *p;
>
Below, there is one more line to update:
-/* set dimensions manually if init != 0 since vc_resize()
will fail */
+/* set dimensions manually if init is true since
vc_resize() will fail */
With the above fixed:
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 17/37] dt-bindings: interrupt-controller: renesas,sh7751-intc: Add json-schema
Hi Sato-san,
On Wed, Jan 17, 2024 at 10:46 AM Yoshinori Sato
wrote:
> On Tue, 09 Jan 2024 21:30:34 +0900,
> Linus Walleij wrote:
> > On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
> > wrote:
> >
> > > + renesas,icr-irlm:
> > > +$ref: /schemas/types.yaml#/definitions/flag
> > > +description: If true four independent interrupt requests mode
> > > (ICR.IRLM is 1).
> > > +
> > > + renesas,ipr-map:
> > > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > > +description: |
> > > + IRQ to IPR mapping definition.
> > > + 1st - INTEVT code
> > > + 2nd - Register
> > > + 3rd - bit index
> >
> > (...)
> >
> > > +renesas,ipr-map = <0x240 IPRD IPR_B12>, /* IRL0 */
> > > + <0x2a0 IPRD IPR_B8>, /* IRL1 */
> > > + <0x300 IPRD IPR_B4>, /* IRL2 */
> > > + <0x360 IPRD IPR_B0>, /* IRL3 */
> > (...)
> >
> > Is it really necessary to have all this in the device tree?
> >
> > You know from the compatible that this is "renesas,sh7751-intc"
> > and I bet this table will be the same for any sh7751 right?
> >
> > Then just put it in a table in the driver instead and skip this from
> > the device tree and bindings. If more interrupt controllers need
> > to be supported by the driver, you can simply look up the table from
> > the compatible string.
>
> The SH interrupt controller has the same structure, only this part is
> different for each SoC.
> Currently, we are targeting only the 7751, but in the future we plan to
> handle all SoCs.
> Is it better to differentiate SoC only by compatible?
Yes, it is better to differentiate SoC only by compatible value.
When you describe all differences explicitly using properties, you
might discover later that you missed something important, causing
backwards compatibility issues with old DTBs.
DT is a stable ABI, while you can always update a driver when needed.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 01/37] sh: passing FDT address to kernel startup.
On Tue, Jan 9, 2024 at 9:23 AM Yoshinori Sato
wrote:
> R4 is caller saved in SH ABI.
> Save it so it doesn't get corrupted until it's needed for initialization.
>
> Signed-off-by: Yoshinori Sato
My
Reviewed-by: Geert Uytterhoeven
on v3 is still valid.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 25/37] dt-bindings: vendor-prefixes: Add iodata
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
wrote:
> Add IO DATA DEVICE INC.
> https://www.iodata.com/
>
> Signed-off-by: Yoshinori Sato
My
Reviewed-by: Geert Uytterhoeven
on v3 is still valid.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 09/37] dt-bindings: timer: renesas, tmu: add renesas, tmu-sh7750
Hi Sato-san,
On Tue, Jan 9, 2024 at 9:23 AM Yoshinori Sato
wrote:
> Add SH7750 TMU entry.
>
> I wanted to replace interrupts and interrupt-names in the if compatible is
> "renesas,tmu-7750", but it seems that I can't rewrite it as expected.
> This resulted in a redundant conditional statement.
>
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
> --- a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml
> +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml
> @@ -39,14 +39,15 @@ properties:
>- renesas,tmu-r8a779a0 # R-Car V3U
>- renesas,tmu-r8a779f0 # R-Car S4-8
>- renesas,tmu-r8a779g0 # R-Car V4H
> + - renesas,tmu-sh7750 # SH7750
OK
>- const: renesas,tmu
>
>reg:
> maxItems: 1
>
> - interrupts:
> -minItems: 2
> -maxItems: 3
> + interrupts: true
> +
> + interrupt-names: true
I would drop this change (see below).
>
>clocks:
> maxItems: 1
> @@ -75,21 +76,55 @@ required:
>- clock-names
>- power-domains
>
> -if:
> - not:
> -properties:
> - compatible:
> -contains:
> - enum:
> -- renesas,tmu-r8a7740
> -- renesas,tmu-r8a7778
> -- renesas,tmu-r8a7779
> -then:
> - required:
> -- resets
> -
> additionalProperties: false
>
> +allOf:
> + - if:
> + not:
> +properties:
> + compatible:
> +contains:
> + enum:
> +- renesas,tmu-r8a7740
> +- renesas,tmu-r8a7778
> +- renesas,tmu-r8a7779
> +- renesas,tmu-sh7750
Adding renesas,tmu-sh7750 to this list is OK.
> +
> +then:
> + required:
> +- resets
> +
> + - if:
> + not:
> +properties:
> + compatible:
> +contains:
> + enum:
> +- renesas,tmu-sh7750
> +
> +then:
> + properties:
> +interrupts:
> + minItems: 2
> + maxItems: 3
> +interrupt-names:
> + items:
> +- const: tuni0
> +- const: tuni1
> +- const: tuni2
> +
> +else:
> + properties:
> +interrupts:
> + minItems: 2
> + maxItems: 4
> +interrupt-names:
> + items:
> +- const: tuni0
> +- const: tuni1
> +- const: tuni2
> +- const: ticpi2
> +
> examples:
>- |
> #include
The new interrupt logic is not really correct: several TMU instances
on other SoCs do support the fourth interrupt. It just was not
documented before, or supported by the driver.
I have sent a patch to document the fourth interrupt[1]. Once that
patch has been applied, adding support for sh7751 involves adding just
two new lines.
[1] "PATCH] dt-bindings: timer: renesas,tmu: Document input capture
interrupt"
https://lore.kernel.org/r/fb1e38c93e62221f94304edd980a2fb79c1f2995.1705325608.git.geert+rene...@glider.be
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 22/37] dt-bindings: display: smi,sm501: SMI SM501 binding json-schema
Hi Sato-san,
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
wrote:
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
> ---
> .../bindings/display/smi,sm501.yaml | 417 ++
> 1 file changed, 417 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/smi,sm501.yaml
Surely Documentation/devicetree/bindings/display/sm501fb.txt should
be removed, too?
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/smi,sm501.yaml
> + crt:
> +type: object
> +description: CRT output control
> +properties:
> + edid:
> +$ref: /schemas/types.yaml#/definitions/uint8-array
> +description: |
> + verbatim EDID data block describing attached display.
> + Data from the detailed timing descriptor will be used to
> + program the display controller.
> +
> + smi,flags:
> +$ref: /schemas/types.yaml#/definitions/string-array
> +description: Display control flags.
> +items:
> + anyOf:
> +- const: use-init-done
> +- const: disable-at-exit
> +- const: use-hwcursor
> +- const: use-hwaccel
The "use-*" flags look like software policy, not hardware description,
and thus do not belong in DT?
> +- const: panel-no-fpen
> +- const: panel-no-vbiasen
> +- const: panel-inv-fpen
> +- const: panel-inv-vbiasen
> +maxItems: 8
> +
> + bpp:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: Color depth
> +
> + panel:
> +type: object
> +description: Panel output control
> +properties:
> + edid:
> +$ref: /schemas/types.yaml#/definitions/uint8-array
> +description: |
> + verbatim EDID data block describing attached display.
> + Data from the detailed timing descriptor will be used to
> + program the display controller.
> +
> + smi,flags:
> +$ref: /schemas/types.yaml#/definitions/string-array
> +description: Display control flags.
> +items:
> + anyOf:
> +- const: use-init-done
> +- const: disable-at-exit
> +- const: use-hwcursor
> +- const: use-hwaccel
The "use-*" flags look like software policy, not hardware description,
and thus do not belong in DT?
> +- const: panel-no-fpen
> +- const: panel-no-vbiasen
> +- const: panel-inv-fpen
> +- const: panel-inv-vbiasen
> +maxItems: 8
> +
> + bpp:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: Color depth
> +
> + smi,devices:
> +$ref: /schemas/types.yaml#/definitions/string-array
> +description: Select SM501 device functions.
> +items:
> + anyOf:
> +- const: usb-host
> +- const: usb-slave
> +- const: ssp0
> +- const: ssp1
> +- const: uart0
> +- const: uart1
> +- const: fbaccel
> +- const: ac97
> +- const: i2s
> +- const: gpio
> +minItems: 1
> +maxItems: 10
I think it would be better to have individual subnodes for the sub devices,
with status = "ok"/"disabled".
If you go that route, you do need some fallback code to handle the lack
of subnodes in the existing user in arch/powerpc/boot/dts/charon.dts.
BTW, why can sm501_pci_initdata get away with setting ".devices
= SM501_USE_ALL"? Or, would it hurt to enable all subdevices
unconditionally?
> +
> + smi,mclk:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: mclk frequency.
> +
> + smi,m1xclk:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: m1xclk frequency.
These two should be clock specifiers (i.e. phandles pointing to clock
nodes + optional clock indices).
> +
> + misc-timing:
> +type: object
> +description: Miscellaneous Timing register values.
> +properties:
> + ex:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: Extend bus holding time.
> +enum: [0, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208,
> 224, 240]
> +
> + xc:
> +$ref: /schemas/types.yaml#/definitions/string
> +description: Xscale clock input select.
> + items:
> + enum:
> +- internal-pll
> +- hclk
> +- gpio33
Software policy instead of hardware description again?
I am not familiar with how the SM501 works, so I cannot comment on
the other properties, but several of them look like they need rework.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 21/37] dt-bindings: serial: renesas, scif: Add scif-sh7751.
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
wrote:
> Add Renesas SH7751 SCIF.
>
> Signed-off-by: Yoshinori Sato
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 26/37] dt-bindings: vendor-prefixes: Add smi
Hi Conor,
On Tue, Jan 9, 2024 at 7:06 PM Conor Dooley wrote:
> On Tue, Jan 09, 2024 at 05:23:23PM +0900, Yoshinori Sato wrote:
> > Add Silicon Mortion Technology Corporation
Motion
> > https://www.siliconmotion.com/
> >
> > Signed-off-by: Yoshinori Sato
> > ---
> > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > index 94ed63d9f7de..a338bdd743ab 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > @@ -1283,6 +1283,8 @@ patternProperties:
> > description: Skyworks Solutions, Inc.
> >"^smartlabs,.*":
> > description: SmartLabs LLC
> > + "^smi,.*":
> > +description: Silicon Motion Technology Corporation
>
> How come "smi" is used for a company with this name?
> Why is it not something like SMTC? There's probably some history here
> that I am unaware of.
See Documentation/devicetree/bindings/display/sm501fb.txt
The stock ticker is "SIMO", though.
https://www.nasdaq.com/market-activity/stocks/simo
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 08/22] [v2] arch: consolidate arch_irq_work_raise prototypes
On Wed, Nov 8, 2023 at 2:01 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The prototype was hidden in an #ifdef on x86, which causes a warning:
>
> kernel/irq_work.c:72:13: error: no previous prototype for
> 'arch_irq_work_raise' [-Werror=missing-prototypes]
This issue is now present upstream.
> Some architectures have a working prototype, while others don't.
> Fix this by providing it in only one place that is always visible.
>
> Acked-by: Catalin Marinas
> Acked-by: Palmer Dabbelt
> Acked-by: Guo Ren
> Reviewed-by: Alexander Gordeev
> Signed-off-by: Arnd Bergmann
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] vt: remove superfluous CONFIG_HW_CONSOLE
On Mon, Jan 8, 2024 at 2:41 PM Lukas Bulwahn wrote:
> The config HW_CONSOLE is always identical to the config VT and is not
> visible in the kernel's build menuconfig. So, CONFIG_HW_CONSOLE is
> redundant.
>
> Replace all references to CONFIG_HW_CONSOLE with CONFIG_VT and remove
> CONFIG_HW_CONSOLE.
>
> Signed-off-by: Lukas Bulwahn
Reviewed-by: Geert Uytterhoeven
> arch/m68k/amiga/config.c | 2 +-
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v15 3/5] drm: renesas: Add RZ/G2L DU Support
On Wed, Dec 13, 2023 at 4:50 PM Laurent Pinchart
wrote:
> On Wed, Dec 13, 2023 at 04:47:09PM +0100, Maxime Ripard wrote:
> > On Tue, Nov 28, 2023 at 10:51:27AM +, Biju Das wrote:
> > > The LCD controller is composed of Frame Compression Processor (FCPVD),
> > > Video Signal Processor (VSPD), and Display Unit (DU).
> > >
> > > It has DPI/DSI interfaces and supports a maximum resolution of 1080p
> > > along with 2 RPFs to support the blending of two picture layers and
> > > raster operations (ROPs).
> > >
> > > The DU module is connected to VSPD. Add RZ/G2L DU support for RZ/G2L
> > > alike SoCs.
> > >
> > > Signed-off-by: Biju Das
> >
> > I'd still like a review from Geert or Laurent, I don't know the SoC.
I don't consider myself sufficiently familiar with DRM and the DU.
Kieran?
> I won't have time soon, and this driver has been blocked for way too
> long due to that :-S
Indeed...
[deleted 278 lines of needlessly quoted text]
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v5 09/37] dt-bindings: timer: renesas, tmu: add renesas, tmu-sh7750
Hi Sato-san,
On Tue, Dec 5, 2023 at 10:46 AM Yoshinori Sato
wrote:
> Add SH7750 TMU entry.
>
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
> --- a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml
> +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml
> @@ -21,6 +21,7 @@ properties:
>compatible:
> items:
>- enum:
> + - renesas,tmu-sh7750 # SH7750
Please preserve alphabetical sort order.
>- renesas,tmu-r8a7740 # R-Mobile A1
>- renesas,tmu-r8a774a1 # RZ/G2M
>- renesas,tmu-r8a774b1 # RZ/G2N
The rest LGTM.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v5 20/37] serial: sh-sci: fix SH4 OF support.
Hi Sato-san,
Thanks for your patch!
On Tue, Dec 5, 2023 at 10:46 AM Yoshinori Sato
wrote:
> - fix earlycon name.
> - fix earlyprintk hung (NULL pointer reference).
- fix SERIAL_SH_SCI_EARLYCON enablement
> Signed-off-by: Yoshinori Sato
Reviewed-by: Geert Uytterhoeven
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -658,7 +658,7 @@ config SERIAL_SH_SCI_EARLYCON
> depends on SERIAL_SH_SCI=y
> select SERIAL_CORE_CONSOLE
> select SERIAL_EARLYCON
> - default ARCH_RENESAS
> + default ARCH_RENESAS || SUPERH
>
> config SERIAL_SH_SCI_DMA
> bool "DMA support" if EXPERT
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v5 24/37] dt-binding: sh: cpus: Add SH CPUs json-schema
Hi Sato-san,
On Tue, Dec 5, 2023 at 10:46 AM Yoshinori Sato
wrote:
> Renesas SH series and compatible ISA CPUs.
>
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sh/cpus.yaml
> @@ -0,0 +1,73 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sh/cpus.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SuperH CPUs
> +
> +maintainers:
> + - Yoshinori Sato
> +
> +description: |+
> + The device tree allows to describe the layout of CPUs in a system through
> + the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
> + defining properties for every cpu.
> +
> + Bindings for CPU nodes follow the Devicetree Specification, available from:
> +
> + https://www.devicetree.org/specifications/
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> + - renesas,sh2a
> + - renesas,sh3
> + - renesas,sh4
> + - renesas,sh4a
> + - jcore,j2
> + - const: renesas,sh2
Plain "renesas,sh2" should be accepted, too.
> +
> + clock-frequency:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: |
> + CPU core clock freqency.
frequency
Although clocks below is more flexible.
> +
> + clocks: true
maxItems: 1
> +
> + clock-names: true
> +
> + reg:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +const: 0
Some SH systems are SMP, so non-zero values should be accepted.
> +
> + device_type: true
> +
> +required:
> + - compatible
> + - reg
> + - device_type
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> +#include
fatal error: dt-bindings/clock/sh7750.h: No such file or directory
sh7750-cpg.h
> +cpus {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +cpu: cpu@0 {
> +compatible = "renesas,sh4", "renesas,sh2";
> +device_type = "cpu";
> +reg = <0>;
> +clocks = < SH7750_CPG_ICK>;
> +clock-names = "ick";
> +icache-size = <16384>;
> +icache-line-size = <32>;
> +dcache-size = <32768>;
> +dcache-line-size = <32>;
> +};
> +};
> +...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v5 17/37] dt-bindings: interrupt-controller: renesas,sh7751-intc: Add json-schema
Hi Sato-san,
On Tue, Dec 5, 2023 at 10:46 AM Yoshinori Sato
wrote:
> Renesas SH7751 INTC json-schema.
>
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.yaml
> +examples:
> + - |
> +#include
make dt_binding_check:
fatal error: dt-bindings/interrupt-controller/sh_intc.h: No such file
or directory
sh7751-intc.h
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v5 21/37] dt-bindings: serial: renesas, scif: Add scif-sh7751.
Hi Sato-san,
On Tue, Dec 5, 2023 at 10:46 AM Yoshinori Sato
wrote:
> Add Renesas SH7751 SCIF.
>
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
> --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> @@ -17,6 +17,7 @@ properties:
> oneOf:
>- items:
>- enum:
> + - renesas,scif-sh7751 # SH7751
Please preserve alphabetical sort order.
The actual compatible value LGTM.
>- renesas,scif-r7s72100 # RZ/A1H
>- const: renesas,scif # generic SCIF compatible UART
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v5 12/37] dt-bindings: pci: pci-sh7751: Add SH7751 PCI
Hi Sato-san,
On Tue, Dec 5, 2023 at 10:46 AM Yoshinori Sato
wrote:
> Renesas SH7751 PCI Controller json-schema.
>
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/renesas,sh7751-pci.yaml
> @@ -0,0 +1,128 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/renesas,sh7751-pci.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SH7751 PCI Host controller
> +
> +maintainers:
> + - Yoshinori Sato
> +
> +allOf:
> + - $ref: /schemas/pci/pci-bus.yaml#
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> + - renesas,sh7751-pci
> +
> + reg:
> +minItems: 2
> +maxItems: 2
Please add "reg-names", as there is more than one entry.
If that is not sufficient to document what each entry means, please add
"description"s, too.
> + renesas,memory:
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +description: |
> + PCI BMDMA src/dst memory area.
Isn't that the purpose of the "dma-ranges" property?
> +
> + renesas,bcr1:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: |
> + SH7751 PCIC PCIBCR1 value. This value makes add the value of BSC's
> BCR1.
What does this mean?
> +
> + renesas,mcrmask:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: |
> + SH7751 PCIC PCIMCR value. This value makes clear bit in the value of
> BSC's MCR.
What does this mean?
> +
> + renesas,intm:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: |
> + SH7751 PCIC PCIINTM value.
> +
> + renesas,aintm:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: |
> + SH7751 PCIC PCIIANTM value.
> +
> + renesas,lsr:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: |
> + SH7751 PCIC PCILSR0 and PCILSR1 values.
> + First word is PCILSR0, Second word is PCILSR1.
> +
> + renesas,lar:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: |
> + SH7751 PCIC PCILSA0 and PCILAR1 values.
> + First word is PCILAR0, Second word is PCILAR1.
> +
> + renesas,dmabt:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: |
> + SH7751 PCIC PCIDMABT value.
> +
> + renesas,pintm:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: |
> + SH7751 PCIC PCIPINTM value.
> +
> + renesas,config:
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +description: |
> + SH7751 PCIC PCICONFIG values array. Register Number and value pair
> list.
Several of these properties look like pure hardware programming.
Can these values be derived from other (standard) DT properties?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v5 11/37] pci: pci-sh7751: Add SH7751 PCI driver
Hi Arnd,
On Tue, Dec 5, 2023 at 2:26 PM Arnd Bergmann wrote:
> On Tue, Dec 5, 2023, at 10:45, Yoshinori Sato wrote:
> > + bscres = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > + bsc = devm_ioremap_resource(>dev, bscres);
> > + if (IS_ERR(bsc))
> > + return PTR_ERR(bsc);
> > +
> > + if (of_property_read_u32_array(pdev->dev.of_node,
> > +"renesas,memory", memory, 2) < 0) {
> > + /*
> > + * If no memory range is specified,
> > + * the entire main memory will be targeted for DMA.
> > + */
> > + memory[0] = memory_start;
> > + memory[1] = memory_end - memory_start;
> > + }
>
> There is a generic "dma-ranges" proerty for describing
> which memory is visible by a bus.
I was just going to give that comment on the bindings patch ;-)
> > --- /dev/null
> > +++ b/drivers/pci/controller/pci-sh7751.h
> > @@ -0,0 +1,76 @@
>
> If the header is only included from one file, just removed
> it and add the register definitions to the driver directly.
$ git grep pci-sh7751.h
arch/sh/drivers/pci/pci-sh4.h:#include "pci-sh7751.h"
drivers/pci/controller/pci-sh7751.c:#include "pci-sh7751.h"
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] drm: renesas: shmobile: Call drm_helper_force_disable_all() at shutdown time
Hi Laurent,
On Tue, Dec 5, 2023 at 1:16 PM Laurent Pinchart
wrote:
> On Tue, Dec 05, 2023 at 12:30:02PM +0100, Geert Uytterhoeven wrote:
> > From: Douglas Anderson
> >
> > Based on grepping through the source code, this driver appears to be
> > missing a call to drm_atomic_helper_shutdown() at system shutdown time.
> > This is important because drm_helper_force_disable_all() will cause
> > panels to get disabled cleanly which may be important for their power
> > sequencing. Future changes will remove any custom powering off in
> > individual panel drivers so the DRM drivers need to start getting this
> > right.
> >
> > The fact that we should call drm_atomic_helper_shutdown() in the case of
> > OS shutdown comes straight out of the kernel doc "driver instance
> > overview" in drm_drv.c.
> >
> > Suggested-by: Maxime Ripard
> > Signed-off-by: Douglas Anderson
> > Link:
> > https://lore.kernel.org/r/20230901164111.RFT.15.Iaf638a1d4c8b3c307a6192efabb4cbb06b195f15@changeid
> > [geert: s/drm_helper_force_disable_all/drm_atomic_helper_shutdown/]
> > [geert: shmob_drm_remove() already calls drm_atomic_helper_shutdown]
> > Signed-off-by: Geert Uytterhoeven
>
> Reviewed-by: Laurent Pinchart
Thanks!
> > Panel-simple does print two new warnings:
> >
> > +panel-simple panel: Skipping disable of already disabled panel
> > +panel-simple panel: Skipping unprepare of already unprepared panel
>
> Have you investigated where this comes from ?
Meh, I knew I forgot something ;-)
The panel is unprepared and disabled a first time from shmob_drm's
.shutdown() callback:
shmob_drm_shutdown
drm_atomic_helper_shutdown
drm_atomic_helper_disable_all
drm_atomic_commit
drm_atomic_helper_commit
commit_tail
drm_atomic_helper_commit_tail
drm_atomic_helper_commit_modeset_disables
disable_outputs
drm_atomic_bridge_chain_disable
drm_panel_disable
drm_atomic_bridge_chain_post_disable
drm_panel_unprepare
And a second time from simple_panel's .shutdown() callback():
panel_simple_platform_shutdown
panel_simple_shutdown
drm_panel_disable
drm_panel_unprepare
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] drm: renesas: shmobile: Call drm_helper_force_disable_all() at shutdown time
From: Douglas Anderson
Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown time.
This is important because drm_helper_force_disable_all() will cause
panels to get disabled cleanly which may be important for their power
sequencing. Future changes will remove any custom powering off in
individual panel drivers so the DRM drivers need to start getting this
right.
The fact that we should call drm_atomic_helper_shutdown() in the case of
OS shutdown comes straight out of the kernel doc "driver instance
overview" in drm_drv.c.
Suggested-by: Maxime Ripard
Signed-off-by: Douglas Anderson
Link:
https://lore.kernel.org/r/20230901164111.RFT.15.Iaf638a1d4c8b3c307a6192efabb4cbb06b195f15@changeid
[geert: s/drm_helper_force_disable_all/drm_atomic_helper_shutdown/]
[geert: shmob_drm_remove() already calls drm_atomic_helper_shutdown]
Signed-off-by: Geert Uytterhoeven
---
Tested on Atmark Techno Armadillo-800-EVA, where the PWM instance
driving the backlight is now stopped on shutdown.
Panel-simple does print two new warnings:
+panel-simple panel: Skipping disable of already disabled panel
+panel-simple panel: Skipping unprepare of already unprepared panel
reboot: System halted
---
drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
index bd16d4780c6436c3..a15162be26f259a4 100644
--- a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
@@ -171,6 +171,13 @@ static void shmob_drm_remove(struct platform_device *pdev)
drm_kms_helper_poll_fini(ddev);
}
+static void shmob_drm_shutdown(struct platform_device *pdev)
+{
+ struct shmob_drm_device *sdev = platform_get_drvdata(pdev);
+
+ drm_atomic_helper_shutdown(>ddev);
+}
+
static int shmob_drm_probe(struct platform_device *pdev)
{
struct shmob_drm_platform_data *pdata = pdev->dev.platform_data;
@@ -274,6 +281,7 @@ static const struct of_device_id shmob_drm_of_table[]
__maybe_unused = {
static struct platform_driver shmob_drm_platform_driver = {
.probe = shmob_drm_probe,
.remove_new = shmob_drm_remove,
+ .shutdown = shmob_drm_shutdown,
.driver = {
.name = "shmob-drm",
.of_match_table = of_match_ptr(shmob_drm_of_table),
--
2.34.1
amdgpu header files (was: Re: [git pull] drm for 6.7-rc1)
On Tue, 31 Oct 2023, Dave Airlie wrote:
This is the main drm pull request for 6.7.
Highlights:
- AMD adds some more upcoming HW platforms
Alex Deucher (24):
drm/amdgpu: update to the latest GC 11.5 headers
Candice Li (8):
drm/amd: Add umc v12_0_0 ip headers
Lang Yu (57):
drm/amdgpu: add gc headers for gc 11.5.0
drm/amdgpu: add mmhub 3.3.0 headers
drm/amdgpu: add VPE 6.1.0 header files
drm/amdgpu: add UMSCH 4.0 register headers
Li Ma (11):
drm/amdgpu: add header files for MP 14.0.0
drm/amdgpu: fix missing stuff in NBIO v7.11
Qingqing Zhuo (38):
drm/amd/display: Add dcn35 register header files
Saleemkhan Jamadar (9):
drm/amdgpu: add vcn 4_0_5 header files
Yang Wang (16):
drm/amd/pm: add smu_13_0_6 mca dump support
benl (3):
drm/amdgpu: add nbio 7.11 registers
.../amd/include/asic_reg/dcn/dcn_3_5_0_offset.h| 15255 +
.../amd/include/asic_reg/dcn/dcn_3_5_0_sh_mask.h | 53412 +
.../drm/amd/include/asic_reg/gc/gc_11_5_0_offset.h | 1
.../amd/include/asic_reg/gc/gc_11_5_0_sh_mask.h| 36579
.../include/asic_reg/mmhub/mmhub_3_3_0_offset.h| 1395 +
.../include/asic_reg/mmhub/mmhub_3_3_0_sh_mask.h | 6722 +++
.../amd/include/asic_reg/mp/mp_13_0_6_sh_mask.h|28 +
.../drm/amd/include/asic_reg/mp/mp_14_0_0_offset.h | 359 +
.../amd/include/asic_reg/mp/mp_14_0_0_sh_mask.h| 534 +
.../amd/include/asic_reg/nbio/nbio_7_11_0_offset.h | 9400 +++
.../include/asic_reg/nbio/nbio_7_11_0_sh_mask.h| 57857 +++
.../amd/include/asic_reg/umc/umc_12_0_0_offset.h |33 +
.../amd/include/asic_reg/umc/umc_12_0_0_sh_mask.h |95 +
.../amd/include/asic_reg/vcn/vcn_4_0_0_offset.h| 422 +
.../amd/include/asic_reg/vcn/vcn_4_0_0_sh_mask.h | 882 +
.../amd/include/asic_reg/vcn/vcn_4_0_5_offset.h| 1797 +
.../amd/include/asic_reg/vcn/vcn_4_0_5_sh_mask.h | 8614 +++
.../amd/include/asic_reg/vpe/vpe_6_1_0_offset.h| 1553 +
.../amd/include/asic_reg/vpe/vpe_6_1_0_sh_mask.h | 4393 ++
These huge files can be reduced by 50%: all the *_SHIFT definitions are
redundant, as they can be derived from the corresponding *_MASK
definitions at compile-time, cfr. .
E.g.:
#define AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER__SHIFT0x0
#define AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER_RESET__SHIFT 0xf
#define AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER_MASK 0x00FFL
#define AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER_RESET_MASK0x8000L
AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER__SHIFT =
__bf_shf(AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER_MASK)
AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER_RESET__SHIFT =
__bf_shf(AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER_RESET_MASK)
set_reg_field_value_masks() takes a shift and a mask, while it
could calculate the shift at run-time.
set_reg_field_values() takes pairs of shifts and masks, but the shifts
are not needed; lots of tables can be halved, etc...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] drm/imagination: DRM_POWERVR should depend on ARCH_K3
Hi Maxime,
On Wed, Nov 29, 2023 at 12:34 PM Maxime Ripard wrote:
> On Wed, Nov 29, 2023 at 12:08:17PM +0100, Geert Uytterhoeven wrote:
> > On Wed, Nov 29, 2023 at 11:50 AM Maxime Ripard wrote:
> > > On Wed, Nov 29, 2023 at 11:10:51AM +0100, Geert Uytterhoeven wrote:
> > > > On Wed, Nov 29, 2023 at 10:23 AM Maxime Ripard
> > > > wrote:
> > > > > On Wed, Nov 29, 2023 at 09:58:12AM +0100, Geert Uytterhoeven wrote:
> > > > > > On Wed, Nov 29, 2023 at 9:35 AM Maxime Ripard
> > > > > > wrote:
> > > > > > > On Tue, Nov 28, 2023 at 08:16:18PM +0100, Geert Uytterhoeven
> > > > > > > wrote:
> > > > > > > > On Tue, Nov 28, 2023 at 8:03 PM Javier Martinez Canillas
> > > > > > > > wrote:
> > > > > > > > > Geert Uytterhoeven writes:
> > > > > > > > > > The Imagination Technologies PowerVR Series 6 GPU is
> > > > > > > > > > currently only
> > > > > > > > > > supported on Texas Instruments K3 AM62x SoCs. Hence add a
> > > > > > > > > > dependency on
> > > > > > > > > > ARCH_K3, to prevent asking the user about this driver when
> > > > > > > > > > configuring a
> > > > > > > > > > kernel without Texas Instruments K3 Multicore SoC support.
> > > > > > > > > >
> > > > > > > > > > Fixes: 4babef0708656c54 ("drm/imagination: Add skeleton
> > > > > > > > > > PowerVR driver")
> > > > > > > > > > Signed-off-by: Geert Uytterhoeven
> > > > > >
> > > > > > > > > In any case, I agree with you that restricting to only K3
> > > > > > > > > makes sense.
> > > > > > > >
> > > > > > > > I am looking forward to adding || SOC_AM33XX || ARCH_RENESAS ||
> > > > > > > > ...,
> > > > > > > > eventually ;-)
> > > > > > >
> > > > > > > I disagree. This is to handle a generic IP, just like panfrost,
> > > > > > > lima, or
> > > > > > > etnaviv, and we certaintly don't want to maintain the Kconfig
> > > > > > > list of
> > > > > > > every possible architecture and SoC family it might or might not
> > > > > > > be
> > > > > > > found.
> > > > > >
> > > > > > While PowerVR is a generic IP, I believe it needs a non-generic
> > > > > > firmware, which is currently only available for AM62x SoCs.
> > >
> > > I just asked, it's not true in most cases. There's some exceptions
> > > (GX6250 for example) that could require different firmwares depending on
> > > the SoC it's used in, but it's not the case here.
> >
> > OK, please tell me how to use it on e.g. R-Car Gen3.
>
> I'm not very familiar with the R-Car family of SoCs.
>
> However, if I'm to trust that page:
> https://www.renesas.com/us/en/products/automotive-products/automotive-system-chips-socs
>
> None of them feature the same GPU than the AM62x, so that question is
> completely different?
According to the documentation I have, they contain PowerVR Series6XT
or Series7XE GPUs.
DRM_POWERVR claims to support "Imagination Technologies PowerVR
(Series 6 or later) or IMG GPU".
> > > > > I'm not sure it's actually true, but let's consider it is. Then what?
> > > > > If
> > > > > the firmware isn't there and/or the DT bits too, then nothing will
> > > > > happen. We would have wasted a couple of 100kB on a system that is
> > > > > taking somewhere in the 100MB-10GB range, and that's pretty much it.
> > > >
> > > > I am talking about posing the question to the user to enable the driver
> > > > or not. Which applies to everyone who configures a kernel.
> > >
> > > If that user doesn't use a defconfig, doesn't use any variant of
> > > *defconfig make target. Plus, the driver still isn't enabled by default.
> > >
> > > > > If you have we take that patch in though, we have:
> > > > >
> > > > > - To keep merging patches as firmwares become available.
> > > >
> > > > You need to keep merging patches to update DT bindings, DTS,
> > > > So
Re: [PATCH] drm/imagination: DRM_POWERVR should depend on ARCH_K3
Hi Maxime,
On Wed, Nov 29, 2023 at 11:50 AM Maxime Ripard wrote:
> On Wed, Nov 29, 2023 at 11:10:51AM +0100, Geert Uytterhoeven wrote:
> > On Wed, Nov 29, 2023 at 10:23 AM Maxime Ripard wrote:
> > > On Wed, Nov 29, 2023 at 09:58:12AM +0100, Geert Uytterhoeven wrote:
> > > > On Wed, Nov 29, 2023 at 9:35 AM Maxime Ripard
> > > > wrote:
> > > > > On Tue, Nov 28, 2023 at 08:16:18PM +0100, Geert Uytterhoeven wrote:
> > > > > > On Tue, Nov 28, 2023 at 8:03 PM Javier Martinez Canillas
> > > > > > wrote:
> > > > > > > Geert Uytterhoeven writes:
> > > > > > > > The Imagination Technologies PowerVR Series 6 GPU is currently
> > > > > > > > only
> > > > > > > > supported on Texas Instruments K3 AM62x SoCs. Hence add a
> > > > > > > > dependency on
> > > > > > > > ARCH_K3, to prevent asking the user about this driver when
> > > > > > > > configuring a
> > > > > > > > kernel without Texas Instruments K3 Multicore SoC support.
> > > > > > > >
> > > > > > > > Fixes: 4babef0708656c54 ("drm/imagination: Add skeleton PowerVR
> > > > > > > > driver")
> > > > > > > > Signed-off-by: Geert Uytterhoeven
> > > >
> > > > > > > In any case, I agree with you that restricting to only K3 makes
> > > > > > > sense.
> > > > > >
> > > > > > I am looking forward to adding || SOC_AM33XX || ARCH_RENESAS || ...,
> > > > > > eventually ;-)
> > > > >
> > > > > I disagree. This is to handle a generic IP, just like panfrost, lima,
> > > > > or
> > > > > etnaviv, and we certaintly don't want to maintain the Kconfig list of
> > > > > every possible architecture and SoC family it might or might not be
> > > > > found.
> > > >
> > > > While PowerVR is a generic IP, I believe it needs a non-generic
> > > > firmware, which is currently only available for AM62x SoCs.
>
> I just asked, it's not true in most cases. There's some exceptions
> (GX6250 for example) that could require different firmwares depending on
> the SoC it's used in, but it's not the case here.
OK, please tell me how to use it on e.g. R-Car Gen3.
> > > I'm not sure it's actually true, but let's consider it is. Then what? If
> > > the firmware isn't there and/or the DT bits too, then nothing will
> > > happen. We would have wasted a couple of 100kB on a system that is
> > > taking somewhere in the 100MB-10GB range, and that's pretty much it.
> >
> > I am talking about posing the question to the user to enable the driver
> > or not. Which applies to everyone who configures a kernel.
>
> If that user doesn't use a defconfig, doesn't use any variant of
> *defconfig make target. Plus, the driver still isn't enabled by default.
>
> > > If you have we take that patch in though, we have:
> > >
> > > - To keep merging patches as firmwares become available.
> >
> > You need to keep merging patches to update DT bindings, DTS,
> > SoC-specific drivers, the DRM driver itself, ... too.
>
> The DT binding and DRM driver is already there, the SoC specific drivers
The DT binding only lists "ti,am62-gpu" with "img,img-axe" as a fallback.
> are probably already there by the time you reach GPU enablement, and the
> DT doesn't have to be upstream.
And getting it upstream requires updating the bindings...
> > > - If we update linux-firmware only, then the driver is still not
> > > loading even though it could.
> > >
> > > - If we have gotten our firmware through some other mean, then the
> > > driver is still not loading even though it could.
> >
> > You will still need to update parts of the kernel, too.
>
> Not really, no. We can use the AM62x as an example. The only thing that
> was required to enable the driver (excluding the driver itself of
> course) was a single DT patch, without anything you've mentioned so far.
Who added:
Documentation/devicetree/bindings/gpu/img,powervr.yaml- - ti,am62-gpu
Documentation/devicetree/bindings/gpu/img,powervr.yaml: - const:
img,img-axe # IMG AXE GPU model/revision is fully discoverable
?
> > As long as none of that has happened, asking about the PowerVR driver
> > on non-AM62x hardware is futile...
>
> Maybe. Just like asking whether you want to enable the U
Re: [PATCH] drm/imagination: DRM_POWERVR should depend on ARCH_K3
Hi Maxime,
On Wed, Nov 29, 2023 at 10:23 AM Maxime Ripard wrote:
> On Wed, Nov 29, 2023 at 09:58:12AM +0100, Geert Uytterhoeven wrote:
> > On Wed, Nov 29, 2023 at 9:35 AM Maxime Ripard wrote:
> > > On Tue, Nov 28, 2023 at 08:16:18PM +0100, Geert Uytterhoeven wrote:
> > > > On Tue, Nov 28, 2023 at 8:03 PM Javier Martinez Canillas
> > > > wrote:
> > > > > Geert Uytterhoeven writes:
> > > > > > The Imagination Technologies PowerVR Series 6 GPU is currently only
> > > > > > supported on Texas Instruments K3 AM62x SoCs. Hence add a
> > > > > > dependency on
> > > > > > ARCH_K3, to prevent asking the user about this driver when
> > > > > > configuring a
> > > > > > kernel without Texas Instruments K3 Multicore SoC support.
> > > > > >
> > > > > > Fixes: 4babef0708656c54 ("drm/imagination: Add skeleton PowerVR
> > > > > > driver")
> > > > > > Signed-off-by: Geert Uytterhoeven
> >
> > > > > In any case, I agree with you that restricting to only K3 makes sense.
> > > >
> > > > I am looking forward to adding || SOC_AM33XX || ARCH_RENESAS || ...,
> > > > eventually ;-)
> > >
> > > I disagree. This is to handle a generic IP, just like panfrost, lima, or
> > > etnaviv, and we certaintly don't want to maintain the Kconfig list of
> > > every possible architecture and SoC family it might or might not be
> > > found.
> >
> > While PowerVR is a generic IP, I believe it needs a non-generic
> > firmware, which is currently only available for AM62x SoCs.
>
> I'm not sure it's actually true, but let's consider it is. Then what? If
> the firmware isn't there and/or the DT bits too, then nothing will
> happen. We would have wasted a couple of 100kB on a system that is
> taking somewhere in the 100MB-10GB range, and that's pretty much it.
I am talking about posing the question to the user to enable the driver
or not. Which applies to everyone who configures a kernel.
> If you have we take that patch in though, we have:
>
> - To keep merging patches as firmwares become available.
You need to keep merging patches to update DT bindings, DTS,
SoC-specific drivers, the DRM driver itself, ... too.
> - If we update linux-firmware only, then the driver is still not
> loading even though it could.
>
> - If we have gotten our firmware through some other mean, then the
> driver is still not loading even though it could.
You will still need to update parts of the kernel, too.
As long as none of that has happened, asking about the PowerVR driver
on non-AM62x hardware is futile...
> It makes life harder for everyone: maintainers, users, devs, based on
> the state of some external project that might or might not be updated in
> sync.
>
> > Once it becomes truly generic, I'm happy to drop all platform
> > dependencies. Until then, there is no point in asking everyone who
> > configures an arm64 kernel about this driver, unless they also enabled
> > K3 support.
>
> Whether it's truly generic, whatever that means, is irrelevant here.
It is.
BTW, playing the devil's advocate: why is there a dependency on ARM64?
PowerVR GPUs are also present on (at least) arm32 and Intel?
Oh, dropping that would expose this question to Linus, causing his
wrath to come down on you... ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] drm/imagination: DRM_POWERVR should depend on ARCH_K3
Hi Javier,
On Wed, Nov 29, 2023 at 10:13 AM Javier Martinez Canillas
wrote:
> Geert Uytterhoeven writes:
> > On Wed, Nov 29, 2023 at 9:35 AM Maxime Ripard wrote:
> >> On Tue, Nov 28, 2023 at 08:16:18PM +0100, Geert Uytterhoeven wrote:
> >> > On Tue, Nov 28, 2023 at 8:03 PM Javier Martinez Canillas
> >> > wrote:
> >> > > Geert Uytterhoeven writes:
> >> > > > The Imagination Technologies PowerVR Series 6 GPU is currently only
> >> > > > supported on Texas Instruments K3 AM62x SoCs. Hence add a
> >> > > > dependency on
> >> > > > ARCH_K3, to prevent asking the user about this driver when
> >> > > > configuring a
> >> > > > kernel without Texas Instruments K3 Multicore SoC support.
> >> > > >
> >> > > > Fixes: 4babef0708656c54 ("drm/imagination: Add skeleton PowerVR
> >> > > > driver")
> >> > > > Signed-off-by: Geert Uytterhoeven
> >
> >> > > In any case, I agree with you that restricting to only K3 makes sense.
> >> >
> >> > I am looking forward to adding || SOC_AM33XX || ARCH_RENESAS || ...,
> >> > eventually ;-)
> >>
> >> I disagree. This is to handle a generic IP, just like panfrost, lima, or
> >> etnaviv, and we certaintly don't want to maintain the Kconfig list of
> >> every possible architecture and SoC family it might or might not be
> >> found.
> >
> > While PowerVR is a generic IP, I believe it needs a non-generic
> > firmware, which is currently only available for AM62x SoCs.
> > Once it becomes truly generic, I'm happy to drop all platform
> > dependencies. Until then, there is no point in asking everyone who
> > configures an arm64 kernel about this driver, unless they also enabled
> > K3 support.
>
> That's true but it will require a Kconfig patch every time that there is a
> design with a different SoC using this generic IP.
It also requires a DT bindings patch, to add a new compatible value,
plus whatever missing properties for SoC integration (e.g. resets).
And a DTS integration patch.
And patches for various on-SoC resources (e.g. clocks).
And perhaps a DRM driver update.
> So when should be added? Once there's an upstream DTS that has a GPU device?
> Once there's a firmware for it in linux-firmware?
It can be added when handling the above. As all patches should be
tested, the firmware must be available first.
When critical mass is reached, platform dependencies can be dropped.
I do hope that will happen rather sooner than later!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] drm/imagination: DRM_POWERVR should depend on ARCH_K3
Hi Maxime,
On Wed, Nov 29, 2023 at 9:35 AM Maxime Ripard wrote:
> On Tue, Nov 28, 2023 at 08:16:18PM +0100, Geert Uytterhoeven wrote:
> > On Tue, Nov 28, 2023 at 8:03 PM Javier Martinez Canillas
> > wrote:
> > > Geert Uytterhoeven writes:
> > > > The Imagination Technologies PowerVR Series 6 GPU is currently only
> > > > supported on Texas Instruments K3 AM62x SoCs. Hence add a dependency on
> > > > ARCH_K3, to prevent asking the user about this driver when configuring a
> > > > kernel without Texas Instruments K3 Multicore SoC support.
> > > >
> > > > Fixes: 4babef0708656c54 ("drm/imagination: Add skeleton PowerVR driver")
> > > > Signed-off-by: Geert Uytterhoeven
> > > In any case, I agree with you that restricting to only K3 makes sense.
> >
> > I am looking forward to adding || SOC_AM33XX || ARCH_RENESAS || ...,
> > eventually ;-)
>
> I disagree. This is to handle a generic IP, just like panfrost, lima, or
> etnaviv, and we certaintly don't want to maintain the Kconfig list of
> every possible architecture and SoC family it might or might not be
> found.
While PowerVR is a generic IP, I believe it needs a non-generic
firmware, which is currently only available for AM62x SoCs.
Once it becomes truly generic, I'm happy to drop all platform
dependencies. Until then, there is no point in asking everyone who
configures an arm64 kernel about this driver, unless they also enabled
K3 support.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] drm/imagination: DRM_POWERVR should depend on ARCH_K3
Hi Javier,
On Tue, Nov 28, 2023 at 8:03 PM Javier Martinez Canillas
wrote:
> Geert Uytterhoeven writes:
> > The Imagination Technologies PowerVR Series 6 GPU is currently only
> > supported on Texas Instruments K3 AM62x SoCs. Hence add a dependency on
> > ARCH_K3, to prevent asking the user about this driver when configuring a
> > kernel without Texas Instruments K3 Multicore SoC support.
> >
> > Fixes: 4babef0708656c54 ("drm/imagination: Add skeleton PowerVR driver")
> > Signed-off-by: Geert Uytterhoeven
> > ---
>
> Indeed. Although I wonder what is the supposed policy since for example
> the DRM_PANFROST symbol only depends on ARM || ARM64 and others such as
I think ARM Mali is sufficiently ubiquitous on ARM/ARM64 systems to
have just an ARM/ARM64 dependency...
> DRM_ETNAVIV don't even have an SoC or architecture dependency.
Vivante GPUs are found in DTS files on at least 4 architectures.
Might be worthwhile to add some dependencies, though...
> In any case, I agree with you that restricting to only K3 makes sense.
I am looking forward to adding || SOC_AM33XX || ARCH_RENESAS || ...,
eventually ;-)
> Reviewed-by: Javier Martinez Canillas
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] drm/imagination: DRM_POWERVR should depend on ARCH_K3
The Imagination Technologies PowerVR Series 6 GPU is currently only
supported on Texas Instruments K3 AM62x SoCs. Hence add a dependency on
ARCH_K3, to prevent asking the user about this driver when configuring a
kernel without Texas Instruments K3 Multicore SoC support.
Fixes: 4babef0708656c54 ("drm/imagination: Add skeleton PowerVR driver")
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/imagination/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/imagination/Kconfig
b/drivers/gpu/drm/imagination/Kconfig
index 3bfa2ac212dccb73..af492dbd9afd4ed9 100644
--- a/drivers/gpu/drm/imagination/Kconfig
+++ b/drivers/gpu/drm/imagination/Kconfig
@@ -6,6 +6,7 @@ config DRM_POWERVR
depends on ARM64
depends on DRM
depends on PM
+ depends on ARCH_K3 || COMPILE_TEST
select DRM_EXEC
select DRM_GEM_SHMEM_HELPER
select DRM_SCHED
--
2.34.1
Re: [PATCH 4/8] drm/shmobile: Do not include
On Tue, Nov 28, 2023 at 11:47 AM Thomas Zimmermann wrote:
> Remove unnecessary include statements for .
> The file contains helpers for non-atomic code and should not be
> required by most drivers. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 5/8] drm/solomon: Do not include
On Tue, Nov 28, 2023 at 11:47 AM Thomas Zimmermann wrote:
> Remove unnecessary include statements for .
> The file contains helpers for non-atomic code and should not be
> required by most drivers. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v15 4/5] MAINTAINERS: Update entries for Renesas DRM drivers
On Tue, Nov 28, 2023 at 11:52 AM Biju Das wrote:
> The rcar-du has never been maintained in drm-misc. So exclude only
> this driver from drm-misc. Also, add the tree entry for sh_mobile.
>
> Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven # shmob_drm
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi Stephen,
On Wed, Nov 22, 2023 at 1:29 AM Stephen Rothwell wrote:
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/accel/ivpu/ivpu_hw_37xx.c
>
> between commit:
>
> 3f7c0634926d ("accel/ivpu/37xx: Fix hangs related to MMIO reset")
>
> from the drm-misc-fixes tree and commits:
>
> 3de6d9597892 ("accel/ivpu: Pass D0i3 residency time to the VPU firmware")
> cc19fedab8bd ("accel/ivpu/37xx: Print warning when VPUIP is not idle during
> power down")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks for your resolution!
> --- a/drivers/accel/ivpu/ivpu_hw_37xx.c
> +++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
> @@@ -720,14 -731,19 +733,14 @@@ static int ivpu_hw_37xx_power_down(stru
> {
> int ret = 0;
>
> - if (!ivpu_hw_37xx_is_idle(vdev))
> - ivpu_warn(vdev, "VPU not idle during power down\n");
> + ivpu_hw_37xx_save_d0i3_entry_timestamp(vdev);
>
> - if (ivpu_hw_37xx_reset(vdev)) {
> - ivpu_err(vdev, "Failed to reset VPU\n");
> - ret = -EIO;
> + if (!ivpu_hw_37xx_is_idle(vdev)) {
> + ivpu_warn(vdev, "VPU not idle during power down\n");
> + if (ivpu_hw_37xx_reset(vdev))
> + ivpu_warn(vdev, "Failed to reset the VPU\n");
> }
>
> - if (ivpu_pll_disable(vdev)) {
> - ivpu_err(vdev, "Failed to disable PLL\n");
> - ret = -EIO;
> - }
> -
> if (ivpu_hw_37xx_d0i3_enable(vdev)) {
> ivpu_err(vdev, "Failed to enter D0I3\n");
> ret = -EIO;
I've just run into the same conflict, and I think you lost the split
into two if-statements in the last hunk of commit 3f7c0634926d
("accel/ivpu/37xx: Fix hangs related to MMIO reset")?
My resolution is:
--- a/drivers/accel/ivpu/ivpu_hw_37xx.c
+++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
@@@ -720,11 -731,16 +733,13 @@@ static int ivpu_hw_37xx_power_down(stru
{
int ret = 0;
+ ivpu_hw_37xx_save_d0i3_entry_timestamp(vdev);
+
- if (!ivpu_hw_37xx_is_idle(vdev)) {
+ if (!ivpu_hw_37xx_is_idle(vdev))
ivpu_warn(vdev, "VPU not idle during power down\n");
- if (ivpu_hw_37xx_reset(vdev))
- ivpu_warn(vdev, "Failed to reset the VPU\n");
- }
- if (ivpu_pll_disable(vdev)) {
- ivpu_err(vdev, "Failed to disable PLL\n");
+ if (ivpu_hw_37xx_reset(vdev)) {
+ ivpu_err(vdev, "Failed to reset VPU\n");
ret = -EIO;
}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v9 03/20] dt-bindings: gpu: Add Imagination Technologies PowerVR/IMG GPU
Hi Donald,
On Wed, Nov 22, 2023 at 5:36 PM Donald Robson wrote:
> From: Sarah Walker
>
> Add the device tree binding documentation for the IMG AXE GPU used in
> TI AM62 SoCs.
>
> Co-developed-by: Frank Binns
> Signed-off-by: Frank Binns
> Signed-off-by: Sarah Walker
> Signed-off-by: Donald Robson
Thanks for your patch, which is now commit 6a85c3b14728f0d5
("dt-bindings: gpu: Add Imagination Technologies PowerVR/IMG GPU") in
drm-misc/for-linux-next.
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> +properties:
> + compatible:
> +items:
> + - enum:
> + - ti,am62-gpu
> + - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
Why the double "img", and not just "img,axe"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
