Re: [PATCH] initramfs: restore default compression behaviour
Hi Masahiro, >From: Masahiro Yamada >Sent: Wednesday, March 11, 2020 23:12 >To: Eugeniy Paltsev >Cc: Linux Kernel Mailing List; arcml; Vineet Gupta; Alexey Brodkin >Subject: Re: [PATCH] initramfs: restore default compression behaviour > >Hi Eugeniy. > >On Wed, Mar 11, 2020 at 7:22 PM Eugeniy Paltsev > wrote: >> >> Even though INITRAMFS_SOURCE kconfig option isn't set in most of >> defconfigs it is used (set) extensively by various build systems. >> Commit f26661e12765 ("initramfs: make initramfs compression choice >> non-optional") has changed default compression mode. Previously we >> compress initramfs using available compression algorithm. Now >> we don't use any compression at all by default. >> It significantly increases the image size in case of build system >> chooses embedded initramfs. Initially I faced with this issue while >> using buildroot. >> >> As of today it's not possible to set preferred compression mode >> in target defconfig as this option depends on INITRAMFS_SOURCE >> being set. >> Modification of build systems doesn't look like good option in this >> case as it requires to check against kernel version when setting >> compression mode. The reason for this is that kconfig options >> describing compression mode was renamed (in same patch series) > >Which commit? > >I do not remember the renaming of kconfig options >with this regard. Ok, I've checked it again - looks like I was confused a bit by "CONFIG_INITRAMFS_COMPRESSION" option as in v5.5 kernel I have in ".config": CONFIG_INITRAMFS_COMPRESSION=".gz" And for v5.6-rc1 I have in ".config": CONFIG_INITRAMFS_COMPRESSION_GZIP=y But they are different options actually... > >> so >> we are not able to simply enable one option for old and new kernels. >> >> Given that I propose to use GZIP as default here instead of NO >> compression. It should be used only when available but given that >> gzip is enabled by default it looks like good enough choice. > > >Another solution would be to move >INITRAMFS_COMPRESSION_NONE to the end of the choice menu. > >The default of the choice menu is the first visible entry. > >GZIP if RD_GZIP is defined, BZIP2 if RD_BZIP2 is defined ... Thanks for advice. It looks like an excellent option here, I'll send a patch. > >> Signed-off-by: Eugeniy Paltsev >> --- >> usr/Kconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/usr/Kconfig b/usr/Kconfig >> index bdf5bbd40727..690ef9020819 100644 >> --- a/usr/Kconfig >> +++ b/usr/Kconfig >> @@ -102,6 +102,7 @@ config RD_LZ4 >> >> choice >> prompt "Built-in initramfs compression mode" >> + default INITRAMFS_COMPRESSION_GZIP if RD_GZIP >> depends on INITRAMFS_SOURCE != "" >> help >> This option allows you to decide by which algorithm the builtin >> -- >> 2.21.1 >> >-- >Best Regards >Masahiro Yamada ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2] initramfs: restore default compression behavior
Even though INITRAMFS_SOURCE kconfig option isn't set in most of defconfigs it is used (set) extensively by various build systems. Commit f26661e12765 ("initramfs: make initramfs compression choice non-optional") has changed default compression mode. Previously we compress initramfs using available compression algorithm. Now we don't use any compression at all by default. It significantly increases the image size in case of build system chooses embedded initramfs. Initially I faced with this issue while using buildroot. As of today it's not possible to set preferred compression mode in target defconfig as this option depends on INITRAMFS_SOURCE being set. Modification of all build systems either doesn't look like good option. Let's instead rewrite initramfs compression mode choices list the way that "INITRAMFS_COMPRESSION_NONE" will be the last option in the list. In that case it will be chosen only if all other options (which implements any compression) are not available. Signed-off-by: Eugeniy Paltsev --- usr/Kconfig | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/usr/Kconfig b/usr/Kconfig index bdf5bbd40727..96afb03b65f9 100644 --- a/usr/Kconfig +++ b/usr/Kconfig @@ -124,17 +124,6 @@ choice If in doubt, select 'None' -config INITRAMFS_COMPRESSION_NONE - bool "None" - help - Do not compress the built-in initramfs at all. This may sound wasteful - in space, but, you should be aware that the built-in initramfs will be - compressed at a later stage anyways along with the rest of the kernel, - on those architectures that support this. However, not compressing the - initramfs may lead to slightly higher memory consumption during a - short time at boot, while both the cpio image and the unpacked - filesystem image will be present in memory simultaneously - config INITRAMFS_COMPRESSION_GZIP bool "Gzip" depends on RD_GZIP @@ -207,4 +196,15 @@ config INITRAMFS_COMPRESSION_LZ4 If you choose this, keep in mind that most distros don't provide lz4 by default which could cause a build failure. +config INITRAMFS_COMPRESSION_NONE + bool "None" + help + Do not compress the built-in initramfs at all. This may sound wasteful + in space, but, you should be aware that the built-in initramfs will be + compressed at a later stage anyways along with the rest of the kernel, + on those architectures that support this. However, not compressing the + initramfs may lead to slightly higher memory consumption during a + short time at boot, while both the cpio image and the unpacked + filesystem image will be present in memory simultaneously + endchoice -- 2.21.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 1/2] DRM: ARC: add HDMI 2.0 TX encoder support
The Synopsys ARC SoCs (like HSDK4xD) include on-chip DesignWare HDMI encoders. Support them with a platform driver to provide platform glue data to the dw-hdmi driver. Signed-off-by: Eugeniy Paltsev --- MAINTAINERS | 6 ++ drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/arc/Kconfig | 7 ++ drivers/gpu/drm/arc/Makefile | 1 + drivers/gpu/drm/arc/arc-dw-hdmi.c | 126 ++ 5 files changed, 141 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/arc/arc-dw-hdmi.c diff --git a/MAINTAINERS b/MAINTAINERS index a6fbdf354d34..a6dd992c5f95 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1258,6 +1258,12 @@ S: Supported F: drivers/gpu/drm/arc/ F: Documentation/devicetree/bindings/display/snps,arcpgu.txt +ARC DW HDMI DRIVER +M: Eugeniy Paltsev +S: Supported +F: drivers/gpu/drm/arc/arc-dw-hdmi.c +F: Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.txt + ARCNET NETWORK LAYER M: Michael Grzeschik L: net...@vger.kernel.org diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 6493088a0fdd..5b0bcf7f45cd 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -109,7 +109,7 @@ obj-y += panel/ obj-y += bridge/ obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/ obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/ -obj-$(CONFIG_DRM_ARCPGU)+= arc/ +obj-y += arc/ obj-y += hisilicon/ obj-$(CONFIG_DRM_ZTE) += zte/ obj-$(CONFIG_DRM_MXSFB)+= mxsfb/ diff --git a/drivers/gpu/drm/arc/Kconfig b/drivers/gpu/drm/arc/Kconfig index e8f3d63e0b91..baec9d2a4fba 100644 --- a/drivers/gpu/drm/arc/Kconfig +++ b/drivers/gpu/drm/arc/Kconfig @@ -8,3 +8,10 @@ config DRM_ARCPGU Choose this option if you have an ARC PGU controller. If M is selected the module will be called arcpgu. + +config DRM_ARC_DW_HDMI + tristate "ARC DW HDMI" + depends on DRM && OF + select DRM_DW_HDMI + help + Synopsys DW HDMI driver for various ARC development boards diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile index c7028b7427b3..7a156d8c2c3c 100644 --- a/drivers/gpu/drm/arc/Makefile +++ b/drivers/gpu/drm/arc/Makefile @@ -1,3 +1,4 @@ # SPDX-License-Identifier: GPL-2.0-only arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_sim.o arcpgu_drv.o obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o +obj-$(CONFIG_DRM_ARC_DW_HDMI) += arc-dw-hdmi.o diff --git a/drivers/gpu/drm/arc/arc-dw-hdmi.c b/drivers/gpu/drm/arc/arc-dw-hdmi.c new file mode 100644 index ..4869dd668a51 --- /dev/null +++ b/drivers/gpu/drm/arc/arc-dw-hdmi.c @@ -0,0 +1,126 @@ +// SPDX-License-Identifier: GPL-2.0+ +// +// Synopsys DW HDMI driver for various ARC development boards +// +// Copyright (C) 2020 Synopsys +// Author: Eugeniy Paltsev + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static const struct dw_hdmi_mpll_config snps_hdmi_mpll_cfg[] = { + { + 2700, { + { 0x00B3, 0x }, + { 0x00B3, 0x }, + { 0x00B3, 0x } + }, + }, { + 7425, { + { 0x0072, 0x0001}, + { 0x0072, 0x0001}, + { 0x0072, 0x0001} + }, + }, { + 14850, { + { 0x0051, 0x0002}, + { 0x0051, 0x0002}, + { 0x0051, 0x0002} + }, + }, { + ~0UL, { + { 0x00B3, 0x }, + { 0x00B3, 0x }, + { 0x00B3, 0x }, + }, + } +}; + +static const struct dw_hdmi_curr_ctrl snps_hdmi_cur_ctr[] = { + /* pixelclkbpp8bpp10 bpp12 */ + { 2700, { 0x, 0x, 0x }, }, + { 7425, { 0x0008, 0x0008, 0x0008 }, }, + { 14850, { 0x001b, 0x001b, 0x001b }, }, + { ~0UL, { 0x, 0x, 0x }, } +}; + + +static const struct dw_hdmi_phy_config snps_hdmi_phy_config[] = { + /* pixelclk symbol termvlev */ + { 2700, 0x8009, 0x0004, 0x0232}, + { 7425, 0x8009, 0x0004, 0x0232}, + { 14850, 0x8009, 0x0004, 0x0232}, + { ~0UL, 0x8009, 0x0004, 0x0232} +}; + +static enum drm_mode_status snps_dw_hdmi_mode_valid(struct drm_connector *con, + const struct drm_display_mode *mode) +{ + return MODE_OK; +} + +static struct dw_hdmi_plat_data snps_dw_hdmi_drv_data = { + .mpll_cfg = snps_hdmi_mpll_cfg, + .cur_ctr= snps_hdmi_cur_ctr, + .phy_config = snps_hdmi_phy_config, + .mode_valid = snps_dw_hdmi_mode_valid, +}; + +static const struct of_device_id snps_dw_hdmi_dt_ids[] = { + { + .
[PATCH 0/2] DRM: ARC: add HDMI 2.0 TX encoder support
Eugeniy Paltsev (2): DRM: ARC: add HDMI 2.0 TX encoder support dt-bindings: Document the Synopsys ARC HDMI TX bindings .../display/bridge/snps,arc-dw-hdmi.txt | 73 ++ MAINTAINERS | 6 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/arc/Kconfig | 7 + drivers/gpu/drm/arc/Makefile | 1 + drivers/gpu/drm/arc/arc-dw-hdmi.c | 126 ++ 6 files changed, 214 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.txt create mode 100644 drivers/gpu/drm/arc/arc-dw-hdmi.c -- 2.21.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 2/2] dt-bindings: Document the Synopsys ARC HDMI TX bindings
This patch adds documentation of device tree bindings for the Synopsys HDMI 2.0 TX encoder driver for ARC SoCs. Signed-off-by: Eugeniy Paltsev --- .../display/bridge/snps,arc-dw-hdmi.txt | 73 +++ 1 file changed, 73 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.txt diff --git a/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.txt b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.txt new file mode 100644 index ..d5e006b392cc --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.txt @@ -0,0 +1,73 @@ +Synopsys DesignWare HDMI 2.0 TX encoder driver for ARC SoCs + + +The HDMI transmitter is a Synopsys DesignWare HDMI 2.0 TX controller IP +with a companion of Synopsys DesignWare HDMI 2.0 TX PHY IP. + +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt +with the following device-specific properties. + + +Required properties: + +- compatible : Shall contain + - "snps,dw-hdmi-hsdk" for HSDK4xD compatible HDMI TX + +- reg: See dw_hdmi.txt. +- interrupts: HDMI interrupt number. +- clocks: See dw_hdmi.txt. +- clock-names: Must contain "iahb" and "isfr" as defined in dw_hdmi.txt. +- ports: See dw_hdmi.txt. The DWC HDMI shall have one port numbered 0 + corresponding to the video input of the controller and one port numbered 1 + corresponding to its HDMI output. + +Example: + +hdmi: hdmi@0x1 { + compatible = "snps,dw-hdmi-hsdk"; + reg = <0x1 0x1>; + reg-io-width = <4>; + interrupts = <14>; + clocks = <&apbclk>, <&hdmi_pix_clk>; + clock-names = "iahb", "isfr"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + hdmi_enc_input: endpoint { + remote-endpoint = <&pgu_output>; + }; + }; + + port@1 { + reg = <1>; + hdmi_enc_out: endpoint { + remote-endpoint = <&hdmi_con>; + }; + }; + }; +}; + +hdmi-out { + ... + + port { + hdmi_con: endpoint { + remote-endpoint = <&hdmi_enc_out>; + }; + }; +}; + +pgu { + ... + + port_o: port { + pgu_output: endpoint { + remote-endpoint = <&hdmi_enc_input>; + }; + }; +}; -- 2.21.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCHv2 00/50] Add log level to show_stack()
Changes to v2: - Removed excessive pr_cont("\n") (nits by Senozhatsky) - Leave backtrace debugging messages with pr_debug() (noted by Russell King and Will Deacon) - Correct microblaze_unwind_inner() declaration (Thanks to Michal Simek and kbuild test robot) - Fix copy'n'paste typo in show_stack_loglvl() for sparc (kbuild robot) - Fix backtrace output on xtensa (Thanks Max Filippov) - Add loglevel to show_stack() on s390 (kbuild robot) - Collected all Reviewed-by and Acked-by (thanks!) Add log level argument to show_stack(). Done in three stages: 1. Introducing show_stack_loglvl() for every architecture 2. Migrating old users with an explicit log level 3. Renaming show_stack_loglvl() into show_stack() Justification: o It's a design mistake to move a business-logic decision into platform realization detail. o I have currently two patches sets that would benefit from this work: Removing console_loglevel jumps in sysrq driver [1] Hung task warning before panic [2] - suggested by Tetsuo (but he probably didn't realise what it would involve). o While doing (1), (2) the backtraces were adjusted to headers and other messages for each situation - so there won't be a situation when the backtrace is printed, but the headers are missing because they have lesser log level (or the reverse). The least important for upstream, but maybe still worth to note that every company I've worked in so far had an off-list patch to print backtrace with the needed log level (but only for the architecture they cared about). If you have other ideas how you will benefit from show_stack() with a log level - please, reply to this cover letter. See also discussion on v1: https://lore.kernel.org/linux-riscv/20191106083538.z5nlpuf64cigx...@pathway.suse.cz/ Cc: Andrew Morton Cc: Greg Kroah-Hartman Cc: Ingo Molnar Cc: Jiri Slaby Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Steven Rostedt Cc: Tetsuo Handa Thanks, Dmitry [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-d...@arista.com/T/#u [2]: https://lkml.kernel.org/r/41fd7652-df1f-26f6-aba0-b87ebae07...@i-love.sakura.ne.jp Dmitry Safonov (50): kallsyms/printk: Add loglvl to print_ip_sym() alpha: Add show_stack_loglvl() arc: Add show_stack_loglvl() arm/asm: Add loglvl to c_backtrace() arm: Add loglvl to unwind_backtrace() arm: Add loglvl to dump_backtrace() arm: Wire up dump_backtrace_{entry,stm} arm: Add show_stack_loglvl() arm64: Add loglvl to dump_backtrace() arm64: Add show_stack_loglvl() c6x: Add show_stack_loglvl() csky: Add show_stack_loglvl() h8300: Add show_stack_loglvl() hexagon: Add show_stack_loglvl() ia64: Pass log level as arg into ia64_do_show_stack() ia64: Add show_stack_loglvl() m68k: Add show_stack_loglvl() microblaze: Add loglvl to microblaze_unwind_inner() microblaze: Add loglvl to microblaze_unwind() microblaze: Add show_stack_loglvl() mips: Add show_stack_loglvl() nds32: Add show_stack_loglvl() nios2: Add show_stack_loglvl() openrisc: Add show_stack_loglvl() parisc: Add show_stack_loglvl() powerpc: Add show_stack_loglvl() riscv: Add show_stack_loglvl() s390: Add show_stack_loglvl() sh: Add loglvl to dump_mem() sh: Remove needless printk() sh: Add loglvl to printk_address() sh: Add loglvl to show_trace() sh: Add show_stack_loglvl() sparc: Add show_stack_loglvl() um/sysrq: Remove needless variable sp um: Add show_stack_loglvl() unicore32: Remove unused pmode argument in c_backtrace() unicore32: Add loglvl to c_backtrace() unicore32: Add show_stack_loglvl() x86: Add missing const qualifiers for log_lvl x86: Add show_stack_loglvl() xtensa: Add loglvl to show_trace() xtensa: Add show_stack_loglvl() sysrq: Use show_stack_loglvl() x86/amd_gart: Print stacktrace for a leak with KERN_ERR power: Use show_stack_loglvl() kdb: Don't play with console_loglevel sched: Print stack trace with KERN_INFO kernel: Use show_stack_loglvl() kernel: Rename show_stack_loglvl() => show_stack() arch/alpha/kernel/traps.c| 22 +++ arch/arc/include/asm/bug.h | 3 ++- arch/arc/kernel/stacktrace.c | 17 +++- arch/arc/kernel/troubleshoot.c | 2 +- arch/arm/include/asm/bug.h | 3 ++- arch/arm/include/asm/traps.h | 3 ++- arch/arm/include/asm/unwind.h| 3 ++- arch/arm/kernel/traps.c | 40 arch/arm/kernel/unwind.c | 7 ++--- arch/arm/lib/backtrace-clang.S | 9 +-- arch/arm/lib/backtrace.S | 14 +++--- arch/arm64/include/asm/stacktrace.h | 3 ++- arch/arm64/kernel/process.c | 2 +- arch/arm64/kernel/traps.c| 19 ++--- arch/c6x/kernel/traps.c | 18 +++-- arch/csky/kernel/dumpstack.c | 9 --- arch/csky/kernel/ptrace.c| 4 +-- arch/h8300/kernel/traps.c| 12 - arch/hexagon/kernel/traps.c | 25 +
[PATCHv2 03/50] arc: Add show_stack_loglvl()
Currently, the log-level of show_stack() depends on a platform realization. It creates situations where the headers are printed with lower log level or higher than the stacktrace (depending on a platform or user). Furthermore, it forces the logic decision from user to an architecture side. In result, some users as sysrq/kdb/etc are doing tricks with temporary rising console_loglevel while printing their messages. And in result it not only may print unwanted messages from other CPUs, but also omit printing at all in the unlucky case where the printk() was deferred. Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems an easier approach than introducing more printk buffers. Also, it will consolidate printings with headers. Introduce show_stack_loglvl(), that eventually will substitute show_stack(). As a good side-effect header "Stack Trace:" is now printed with the same log level as the rest of backtrace. Cc: Vineet Gupta Cc: linux-snps-arc@lists.infradead.org [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-d...@arista.com/T/#u Signed-off-by: Dmitry Safonov --- arch/arc/include/asm/bug.h | 3 ++- arch/arc/kernel/stacktrace.c | 21 +++-- arch/arc/kernel/troubleshoot.c | 2 +- 3 files changed, 18 insertions(+), 8 deletions(-) diff --git a/arch/arc/include/asm/bug.h b/arch/arc/include/asm/bug.h index 0be19fd1a412..4c453ba96c51 100644 --- a/arch/arc/include/asm/bug.h +++ b/arch/arc/include/asm/bug.h @@ -13,7 +13,8 @@ struct task_struct; void show_regs(struct pt_regs *regs); -void show_stacktrace(struct task_struct *tsk, struct pt_regs *regs); +void show_stacktrace(struct task_struct *tsk, struct pt_regs *regs, +const char *loglvl); void show_kernel_fault_diag(const char *str, struct pt_regs *regs, unsigned long address); void die(const char *str, struct pt_regs *regs, unsigned long address); diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c index 1e440bbfa876..24f9cd8a12c9 100644 --- a/arch/arc/kernel/stacktrace.c +++ b/arch/arc/kernel/stacktrace.c @@ -158,9 +158,11 @@ arc_unwind_core(struct task_struct *tsk, struct pt_regs *regs, /* Call-back which plugs into unwinding core to dump the stack in * case of panic/OOPs/BUG etc */ -static int __print_sym(unsigned int address, void *unused) +static int __print_sym(unsigned int address, void *arg) { - printk(" %pS\n", (void *)address); + const char *loglvl = arg; + + printk("%s %pS\n", loglvl, (void *)address); return 0; } @@ -217,17 +219,24 @@ static int __get_first_nonsched(unsigned int address, void *unused) *- */ -noinline void show_stacktrace(struct task_struct *tsk, struct pt_regs *regs) +noinline void show_stacktrace(struct task_struct *tsk, struct pt_regs *regs, + const char *loglvl) { - pr_info("\nStack Trace:\n"); - arc_unwind_core(tsk, regs, __print_sym, NULL); + printk("%s\nStack Trace:\n", loglvl); + arc_unwind_core(tsk, regs, __print_sym, (void *)loglvl); } EXPORT_SYMBOL(show_stacktrace); /* Expected by sched Code */ +void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp, + const char *loglvl) +{ + show_stacktrace(tsk, NULL, loglvl); +} + void show_stack(struct task_struct *tsk, unsigned long *sp) { - show_stacktrace(tsk, NULL); + show_stack_loglvl(tsk, sp, KERN_DEFAULT); } /* Another API expected by schedular, shows up in "ps" as Wait Channel diff --git a/arch/arc/kernel/troubleshoot.c b/arch/arc/kernel/troubleshoot.c index d2999503fb8a..660681101523 100644 --- a/arch/arc/kernel/troubleshoot.c +++ b/arch/arc/kernel/troubleshoot.c @@ -242,5 +242,5 @@ void show_kernel_fault_diag(const char *str, struct pt_regs *regs, /* Show stack trace if this Fatality happened in kernel mode */ if (!user_mode(regs)) - show_stacktrace(current, regs); + show_stacktrace(current, regs, KERN_DEFAULT); } -- 2.25.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/2] dt-bindings: Document the Synopsys ARC HDMI TX bindings
Hi Eugeniy. On Mon, Mar 16, 2020 at 05:46:47PM +0300, Eugeniy Paltsev wrote: > This patch adds documentation of device tree bindings for the Synopsys > HDMI 2.0 TX encoder driver for ARC SoCs. > > Signed-off-by: Eugeniy Paltsev > --- > .../display/bridge/snps,arc-dw-hdmi.txt | 73 +++ New bindings in DT Schema format please (.yaml files). We are working on migrating all bindings to DT Schema format. Sam > 1 file changed, 73 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.txt > > diff --git > a/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.txt > b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.txt > new file mode 100644 > index ..d5e006b392cc > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.txt > @@ -0,0 +1,73 @@ > +Synopsys DesignWare HDMI 2.0 TX encoder driver for ARC SoCs > + > + > +The HDMI transmitter is a Synopsys DesignWare HDMI 2.0 TX controller IP > +with a companion of Synopsys DesignWare HDMI 2.0 TX PHY IP. > + > +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in > +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt > +with the following device-specific properties. > + > + > +Required properties: > + > +- compatible : Shall contain > + - "snps,dw-hdmi-hsdk" for HSDK4xD compatible HDMI TX > + > +- reg: See dw_hdmi.txt. > +- interrupts: HDMI interrupt number. > +- clocks: See dw_hdmi.txt. > +- clock-names: Must contain "iahb" and "isfr" as defined in dw_hdmi.txt. > +- ports: See dw_hdmi.txt. The DWC HDMI shall have one port numbered 0 > + corresponding to the video input of the controller and one port numbered 1 > + corresponding to its HDMI output. > + > +Example: > + > +hdmi: hdmi@0x1 { > + compatible = "snps,dw-hdmi-hsdk"; > + reg = <0x1 0x1>; > + reg-io-width = <4>; > + interrupts = <14>; > + clocks = <&apbclk>, <&hdmi_pix_clk>; > + clock-names = "iahb", "isfr"; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + hdmi_enc_input: endpoint { > + remote-endpoint = <&pgu_output>; > + }; > + }; > + > + port@1 { > + reg = <1>; > + hdmi_enc_out: endpoint { > + remote-endpoint = <&hdmi_con>; > + }; > + }; > + }; > +}; > + > +hdmi-out { > + ... > + > + port { > + hdmi_con: endpoint { > + remote-endpoint = <&hdmi_enc_out>; > + }; > + }; > +}; > + > +pgu { > + ... > + > + port_o: port { > + pgu_output: endpoint { > + remote-endpoint = <&hdmi_enc_input>; > + }; > + }; > +}; > -- > 2.21.1 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2] initramfs: restore default compression behavior
On Mon, Mar 16, 2020 at 8:25 PM Eugeniy Paltsev wrote: > > Even though INITRAMFS_SOURCE kconfig option isn't set in most of > defconfigs it is used (set) extensively by various build systems. > Commit f26661e12765 ("initramfs: make initramfs compression choice > non-optional") has changed default compression mode. Previously we > compress initramfs using available compression algorithm. Now > we don't use any compression at all by default. > It significantly increases the image size in case of build system > chooses embedded initramfs. Initially I faced with this issue while > using buildroot. > > As of today it's not possible to set preferred compression mode > in target defconfig as this option depends on INITRAMFS_SOURCE > being set. Modification of all build systems either doesn't look > like good option. > > Let's instead rewrite initramfs compression mode choices list > the way that "INITRAMFS_COMPRESSION_NONE" will be the last option > in the list. In that case it will be chosen only if all other > options (which implements any compression) are not available. > > Signed-off-by: Eugeniy Paltsev Applied to linux-kbuild. Thanks. > --- > usr/Kconfig | 22 +++--- > 1 file changed, 11 insertions(+), 11 deletions(-) > > diff --git a/usr/Kconfig b/usr/Kconfig > index bdf5bbd40727..96afb03b65f9 100644 > --- a/usr/Kconfig > +++ b/usr/Kconfig > @@ -124,17 +124,6 @@ choice > > If in doubt, select 'None' > > -config INITRAMFS_COMPRESSION_NONE > - bool "None" > - help > - Do not compress the built-in initramfs at all. This may sound > wasteful > - in space, but, you should be aware that the built-in initramfs will > be > - compressed at a later stage anyways along with the rest of the > kernel, > - on those architectures that support this. However, not compressing > the > - initramfs may lead to slightly higher memory consumption during a > - short time at boot, while both the cpio image and the unpacked > - filesystem image will be present in memory simultaneously > - > config INITRAMFS_COMPRESSION_GZIP > bool "Gzip" > depends on RD_GZIP > @@ -207,4 +196,15 @@ config INITRAMFS_COMPRESSION_LZ4 > If you choose this, keep in mind that most distros don't provide lz4 > by default which could cause a build failure. > > +config INITRAMFS_COMPRESSION_NONE > + bool "None" > + help > + Do not compress the built-in initramfs at all. This may sound > wasteful > + in space, but, you should be aware that the built-in initramfs will > be > + compressed at a later stage anyways along with the rest of the > kernel, > + on those architectures that support this. However, not compressing > the > + initramfs may lead to slightly higher memory consumption during a > + short time at boot, while both the cpio image and the unpacked > + filesystem image will be present in memory simultaneously > + > endchoice > -- > 2.21.1 > -- Best Regards Masahiro Yamada ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] initramfs: restore default compression behaviour
On Mon, Mar 16, 2020 at 8:22 PM Eugeniy Paltsev wrote: > > Hi Masahiro, > > >From: Masahiro Yamada > >Sent: Wednesday, March 11, 2020 23:12 > >To: Eugeniy Paltsev > >Cc: Linux Kernel Mailing List; arcml; Vineet Gupta; Alexey Brodkin > >Subject: Re: [PATCH] initramfs: restore default compression behaviour > > > >Hi Eugeniy. > > > >On Wed, Mar 11, 2020 at 7:22 PM Eugeniy Paltsev > > wrote: > >> > >> Even though INITRAMFS_SOURCE kconfig option isn't set in most of > >> defconfigs it is used (set) extensively by various build systems. > >> Commit f26661e12765 ("initramfs: make initramfs compression choice > >> non-optional") has changed default compression mode. Previously we > >> compress initramfs using available compression algorithm. Now > >> we don't use any compression at all by default. > >> It significantly increases the image size in case of build system > >> chooses embedded initramfs. Initially I faced with this issue while > >> using buildroot. > >> > >> As of today it's not possible to set preferred compression mode > >> in target defconfig as this option depends on INITRAMFS_SOURCE > >> being set. > >> Modification of build systems doesn't look like good option in this > >> case as it requires to check against kernel version when setting > >> compression mode. The reason for this is that kconfig options > >> describing compression mode was renamed (in same patch series) > > > >Which commit? > > > >I do not remember the renaming of kconfig options > >with this regard. > > Ok, I've checked it again - looks like I was confused a bit by > "CONFIG_INITRAMFS_COMPRESSION" option > as in v5.5 kernel I have in ".config": > CONFIG_INITRAMFS_COMPRESSION=".gz" > > And for v5.6-rc1 I have in ".config": > CONFIG_INITRAMFS_COMPRESSION_GZIP=y > > But they are different options actually... Right. There is no prompt for CONFIG_INITRAMFS_COMPRESSION. So, users have no control of it. Because this is just a matter of the file extension, commit 65e00e04e5aea34 moved the logic to Makefile. -- Best Regards Masahiro Yamada ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc