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
