[PATCH v2 0/3]Enable CONFIG_VT support for S390

[PATCH v2 0/3]Enable CONFIG_VT support for S390

[Farhan Ali]

Hi,

This series of patches add support for an additional tty
and console for a S390 KVM guest using a virtio-gpu device[1].

Patch 1 enables the "Graphics support" menu which is
needed to enable dummy console, since the VT layer needs it.
It also fixes a build error for Opencore framebuffer driver. 

Patch 2 fixes few linker issues.

Patch 3 add support for enabling VT layer for S390.


ChangeLog
---------
v1 -> v2

v1 was posted under a different subject and here is a link to it:
https://www.spinics.net/lists/linux-s390/msg18175.html

   - Combine patch 1 and 2 from v1 into one patch (patch 1).
   - Additional patches to enable CONFIG_VT for S390.


Thanks
Farhan


[1] https://lists.nongnu.org/archive/html/qemu-devel/2017-09/msg04184.html


Farhan Ali (3):
  Kconfig : Remove HAS_IOMEM dependency for Graphics support
  s390/char : Rename EBCDIC keymap variables
  s390/setup : enable display support for KVM guest

 arch/s390/kernel/setup.c      |  2 ++
 drivers/s390/char/defkeymap.c | 66 ++++++++++++++++++++++---------------------
 drivers/s390/char/keyboard.c  | 32 ++++++++++-----------
 drivers/s390/char/keyboard.h  | 11 ++++++++
 drivers/tty/Kconfig           |  2 +-
 drivers/video/Kconfig         |  1 -
 drivers/video/console/Kconfig |  2 +-
 drivers/video/fbdev/Kconfig   |  2 +-
 8 files changed, 66 insertions(+), 52 deletions(-)

-- 
2.7.4

[PATCH v2 0/3]Enable CONFIG_VT support for S390

[Farhan Ali]

Hi,

This series of patches add support for an additional tty
and console for a S390 KVM guest using a virtio-gpu device[1].

Patch 1 enables the "Graphics support" menu which is
needed to enable dummy console, since the VT layer needs it.
It also fixes a build error for Opencore framebuffer driver. 

Patch 2 fixes few linker issues.

Patch 3 add support for enabling VT layer for S390.


ChangeLog
---------
v1 -> v2

v1 was posted under a different subject and here is a link to it:
https://www.spinics.net/lists/linux-s390/msg18175.html

   - Combine patch 1 and 2 from v1 into one patch (patch 1).
   - Additional patches to enable CONFIG_VT for S390.


Thanks
Farhan


[1] https://lists.nongnu.org/archive/html/qemu-devel/2017-09/msg04184.html


Farhan Ali (3):
  Kconfig : Remove HAS_IOMEM dependency for Graphics support
  s390/char : Rename EBCDIC keymap variables
  s390/setup : enable display support for KVM guest

 arch/s390/kernel/setup.c      |  2 ++
 drivers/s390/char/defkeymap.c | 66 ++++++++++++++++++++++---------------------
 drivers/s390/char/keyboard.c  | 32 ++++++++++-----------
 drivers/s390/char/keyboard.h  | 11 ++++++++
 drivers/tty/Kconfig           |  2 +-
 drivers/video/Kconfig         |  1 -
 drivers/video/console/Kconfig |  2 +-
 drivers/video/fbdev/Kconfig   |  2 +-
 8 files changed, 66 insertions(+), 52 deletions(-)

-- 
2.7.4

[PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Farhan Ali]

The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
added the HAS_IOMEM dependecy for "Graphics support". This disabled the
"Graphics support" menu for S390. But if we enable VT layer for S390,
we would also need to enable the dummy console. So let's remove the
HAS_IOMEM dependency.

Move this dependency to Opencores framebuffer driver which would fail to build
with CONFIG_HAS_IOMEM disabled:

ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!

Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
Tested-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
---
 drivers/video/Kconfig       | 1 -
 drivers/video/fbdev/Kconfig | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 3c20af9..41e7ba9 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -3,7 +3,6 @@
 #
 
 menu "Graphics support"
-	depends on HAS_IOMEM
 
 config HAVE_FB_ATMEL
 	bool
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 2f615b7..ec9c9ce 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -966,7 +966,7 @@ config FB_PVR2
 
 config FB_OPENCORES
 	tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
-	depends on FB && HAS_DMA
+	depends on FB && HAS_DMA && HAS_IOMEM
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
-- 
2.7.4

[PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Farhan Ali]

The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
added the HAS_IOMEM dependecy for "Graphics support". This disabled the
"Graphics support" menu for S390. But if we enable VT layer for S390,
we would also need to enable the dummy console. So let's remove the
HAS_IOMEM dependency.

Move this dependency to Opencores framebuffer driver which would fail to build
with CONFIG_HAS_IOMEM disabled:

ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!

Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
Tested-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
---
 drivers/video/Kconfig       | 1 -
 drivers/video/fbdev/Kconfig | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 3c20af9..41e7ba9 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -3,7 +3,6 @@
 #
 
 menu "Graphics support"
-	depends on HAS_IOMEM
 
 config HAVE_FB_ATMEL
 	bool
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 2f615b7..ec9c9ce 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -966,7 +966,7 @@ config FB_PVR2
 
 config FB_OPENCORES
 	tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
-	depends on FB && HAS_DMA
+	depends on FB && HAS_DMA && HAS_IOMEM
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
-- 
2.7.4

[PATCH v2 2/3] s390/char : Rename EBCDIC keymap variables

[Farhan Ali]

The Linux Virtual Terminal (VT) layer provides a default keymap
which is compiled when VT layer is enabled. But at the same time
we are also compiling the EBCDIC keymap and this causes the linker
to complain.

So let's rename the EBCDIC keymap variables to prevent linker
conflict.

Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 drivers/s390/char/defkeymap.c | 66 ++++++++++++++++++++++---------------------
 drivers/s390/char/keyboard.c  | 32 ++++++++++-----------
 drivers/s390/char/keyboard.h  | 11 ++++++++
 3 files changed, 61 insertions(+), 48 deletions(-)

diff --git a/drivers/s390/char/defkeymap.c b/drivers/s390/char/defkeymap.c
index 98a5c45..193142c 100644
--- a/drivers/s390/char/defkeymap.c
+++ b/drivers/s390/char/defkeymap.c
@@ -9,7 +9,9 @@
 #include <linux/kbd_kern.h>
 #include <linux/kbd_diacr.h>
 
-u_short plain_map[NR_KEYS] = {
+#include "keyboard.h"
+
+u_short ebc_plain_map[NR_KEYS] = {
 	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,
 	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,
 	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,
@@ -85,12 +87,12 @@ static u_short shift_ctrl_map[NR_KEYS] = {
 	0xf20a,	0xf108,	0xf200,	0xf200,	0xf200,	0xf200,	0xf200,	0xf200,
 };
 
-ushort *key_maps[MAX_NR_KEYMAPS] = {
-	plain_map, shift_map, NULL, NULL,
+ushort *ebc_key_maps[MAX_NR_KEYMAPS] = {
+	ebc_plain_map, shift_map, NULL, NULL,
 	ctrl_map, shift_ctrl_map, NULL,
 };
 
-unsigned int keymap_count = 4;
+unsigned int ebc_keymap_count = 4;
 
 
 /*
@@ -99,7 +101,7 @@ unsigned int keymap_count = 4;
  * the default and allocate dynamically in chunks of 512 bytes.
  */
 
-char func_buf[] = {
+char ebc_func_buf[] = {
 	'\033', '[', '[', 'A', 0, 
 	'\033', '[', '[', 'B', 0, 
 	'\033', '[', '[', 'C', 0, 
@@ -123,37 +125,37 @@ char func_buf[] = {
 };
 
 
-char *funcbufptr = func_buf;
-int funcbufsize = sizeof(func_buf);
-int funcbufleft = 0;          /* space left */
-
-char *func_table[MAX_NR_FUNC] = {
-	func_buf + 0,
-	func_buf + 5,
-	func_buf + 10,
-	func_buf + 15,
-	func_buf + 20,
-	func_buf + 25,
-	func_buf + 31,
-	func_buf + 37,
-	func_buf + 43,
-	func_buf + 49,
-	func_buf + 55,
-	func_buf + 61,
-	func_buf + 67,
-	func_buf + 73,
-	func_buf + 79,
-	func_buf + 85,
-	func_buf + 91,
-	func_buf + 97,
-	func_buf + 103,
-	func_buf + 109,
+char *ebc_funcbufptr = ebc_func_buf;
+int ebc_funcbufsize = sizeof(ebc_func_buf);
+int ebc_funcbufleft = 0;          /* space left */
+
+char *ebc_func_table[MAX_NR_FUNC] = {
+	ebc_func_buf + 0,
+	ebc_func_buf + 5,
+	ebc_func_buf + 10,
+	ebc_func_buf + 15,
+	ebc_func_buf + 20,
+	ebc_func_buf + 25,
+	ebc_func_buf + 31,
+	ebc_func_buf + 37,
+	ebc_func_buf + 43,
+	ebc_func_buf + 49,
+	ebc_func_buf + 55,
+	ebc_func_buf + 61,
+	ebc_func_buf + 67,
+	ebc_func_buf + 73,
+	ebc_func_buf + 79,
+	ebc_func_buf + 85,
+	ebc_func_buf + 91,
+	ebc_func_buf + 97,
+	ebc_func_buf + 103,
+	ebc_func_buf + 109,
 	NULL,
 };
 
-struct kbdiacruc accent_table[MAX_DIACR] = {
+struct kbdiacruc ebc_accent_table[MAX_DIACR] = {
 	{'^', 'c', 0003},	{'^', 'd', 0004},
 	{'^', 'z', 0032},	{'^', 0012, 0000},
 };
 
-unsigned int accent_table_size = 4;
+unsigned int ebc_accent_table_size = 4;
diff --git a/drivers/s390/char/keyboard.c b/drivers/s390/char/keyboard.c
index 5b505fd..db1fbf9 100644
--- a/drivers/s390/char/keyboard.c
+++ b/drivers/s390/char/keyboard.c
@@ -54,24 +54,24 @@ kbd_alloc(void) {
 	kbd = kzalloc(sizeof(struct kbd_data), GFP_KERNEL);
 	if (!kbd)
 		goto out;
-	kbd->key_maps = kzalloc(sizeof(key_maps), GFP_KERNEL);
+	kbd->key_maps = kzalloc(sizeof(ebc_key_maps), GFP_KERNEL);
 	if (!kbd->key_maps)
 		goto out_kbd;
-	for (i = 0; i < ARRAY_SIZE(key_maps); i++) {
-		if (key_maps[i]) {
-			kbd->key_maps[i] = kmemdup(key_maps[i],
+	for (i = 0; i < ARRAY_SIZE(ebc_key_maps); i++) {
+		if (ebc_key_maps[i]) {
+			kbd->key_maps[i] = kmemdup(ebc_key_maps[i],
 						   sizeof(u_short) * NR_KEYS,
 						   GFP_KERNEL);
 			if (!kbd->key_maps[i])
 				goto out_maps;
 		}
 	}
-	kbd->func_table = kzalloc(sizeof(func_table), GFP_KERNEL);
+	kbd->func_table = kzalloc(sizeof(ebc_func_table), GFP_KERNEL);
 	if (!kbd->func_table)
 		goto out_maps;
-	for (i = 0; i < ARRAY_SIZE(func_table); i++) {
-		if (func_table[i]) {
-			kbd->func_table[i] = kstrdup(func_table[i],
+	for (i = 0; i < ARRAY_SIZE(ebc_func_table); i++) {
+		if (ebc_func_table[i]) {
+			kbd->func_table[i] = kstrdup(ebc_func_table[i],
 						     GFP_KERNEL);
 			if (!kbd->func_table[i])
 				goto out_func;
@@ -81,22 +81,22 @@ kbd_alloc(void) {
 		kzalloc(sizeof(fn_handler_fn *) * NR_FN_HANDLER, GFP_KERNEL);
 	if (!kbd->fn_handler)
 		goto out_func;
-	kbd->accent_table = kmemdup(accent_table,
+	kbd->accent_table = kmemdup(ebc_accent_table,
 				    sizeof(struct kbdiacruc) * MAX_DIACR,
 				    GFP_KERNEL);
 	if (!kbd->accent_table)
 		goto out_fn_handler;
-	kbd->accent_table_size = accent_table_size;
+	kbd->accent_table_size = ebc_accent_table_size;
 	return kbd;
 
 out_fn_handler:
 	kfree(kbd->fn_handler);
 out_func:
-	for (i = 0; i < ARRAY_SIZE(func_table); i++)
+	for (i = 0; i < ARRAY_SIZE(ebc_func_table); i++)
 		kfree(kbd->func_table[i]);
 	kfree(kbd->func_table);
 out_maps:
-	for (i = 0; i < ARRAY_SIZE(key_maps); i++)
+	for (i = 0; i < ARRAY_SIZE(ebc_key_maps); i++)
 		kfree(kbd->key_maps[i]);
 	kfree(kbd->key_maps);
 out_kbd:
@@ -112,10 +112,10 @@ kbd_free(struct kbd_data *kbd)
 
 	kfree(kbd->accent_table);
 	kfree(kbd->fn_handler);
-	for (i = 0; i < ARRAY_SIZE(func_table); i++)
+	for (i = 0; i < ARRAY_SIZE(ebc_func_table); i++)
 		kfree(kbd->func_table[i]);
 	kfree(kbd->func_table);
-	for (i = 0; i < ARRAY_SIZE(key_maps); i++)
+	for (i = 0; i < ARRAY_SIZE(ebc_key_maps); i++)
 		kfree(kbd->key_maps[i]);
 	kfree(kbd->key_maps);
 	kfree(kbd);
@@ -131,7 +131,7 @@ kbd_ascebc(struct kbd_data *kbd, unsigned char *ascebc)
 	int i, j, k;
 
 	memset(ascebc, 0x40, 256);
-	for (i = 0; i < ARRAY_SIZE(key_maps); i++) {
+	for (i = 0; i < ARRAY_SIZE(ebc_key_maps); i++) {
 		keymap = kbd->key_maps[i];
 		if (!keymap)
 			continue;
@@ -158,7 +158,7 @@ kbd_ebcasc(struct kbd_data *kbd, unsigned char *ebcasc)
 	int i, j, k;
 
 	memset(ebcasc, ' ', 256);
-	for (i = 0; i < ARRAY_SIZE(key_maps); i++) {
+	for (i = 0; i < ARRAY_SIZE(ebc_key_maps); i++) {
 		keymap = kbd->key_maps[i];
 		if (!keymap)
 			continue;
diff --git a/drivers/s390/char/keyboard.h b/drivers/s390/char/keyboard.h
index a074d97..c467589 100644
--- a/drivers/s390/char/keyboard.h
+++ b/drivers/s390/char/keyboard.h
@@ -14,6 +14,17 @@
 
 struct kbd_data;
 
+extern int ebc_funcbufsize, ebc_funcbufleft;
+extern char *ebc_func_table[MAX_NR_FUNC];
+extern char ebc_func_buf[];
+extern char *ebc_funcbufptr;
+extern unsigned int ebc_keymap_count;
+
+extern struct kbdiacruc ebc_accent_table[];
+extern unsigned int ebc_accent_table_size;
+extern unsigned short *ebc_key_maps[MAX_NR_KEYMAPS];
+extern unsigned short ebc_plain_map[NR_KEYS];
+
 typedef void (fn_handler_fn)(struct kbd_data *);
 
 /*
-- 
2.7.4

[PATCH v2 2/3] s390/char : Rename EBCDIC keymap variables

[Farhan Ali]

The Linux Virtual Terminal (VT) layer provides a default keymap
which is compiled when VT layer is enabled. But at the same time
we are also compiling the EBCDIC keymap and this causes the linker
to complain.

So let's rename the EBCDIC keymap variables to prevent linker
conflict.

Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 drivers/s390/char/defkeymap.c | 66 ++++++++++++++++++++++---------------------
 drivers/s390/char/keyboard.c  | 32 ++++++++++-----------
 drivers/s390/char/keyboard.h  | 11 ++++++++
 3 files changed, 61 insertions(+), 48 deletions(-)

diff --git a/drivers/s390/char/defkeymap.c b/drivers/s390/char/defkeymap.c
index 98a5c45..193142c 100644
--- a/drivers/s390/char/defkeymap.c
+++ b/drivers/s390/char/defkeymap.c
@@ -9,7 +9,9 @@
 #include <linux/kbd_kern.h>
 #include <linux/kbd_diacr.h>
 
-u_short plain_map[NR_KEYS] = {
+#include "keyboard.h"
+
+u_short ebc_plain_map[NR_KEYS] = {
 	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,
 	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,
 	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,	0xf000,
@@ -85,12 +87,12 @@ static u_short shift_ctrl_map[NR_KEYS] = {
 	0xf20a,	0xf108,	0xf200,	0xf200,	0xf200,	0xf200,	0xf200,	0xf200,
 };
 
-ushort *key_maps[MAX_NR_KEYMAPS] = {
-	plain_map, shift_map, NULL, NULL,
+ushort *ebc_key_maps[MAX_NR_KEYMAPS] = {
+	ebc_plain_map, shift_map, NULL, NULL,
 	ctrl_map, shift_ctrl_map, NULL,
 };
 
-unsigned int keymap_count = 4;
+unsigned int ebc_keymap_count = 4;
 
 
 /*
@@ -99,7 +101,7 @@ unsigned int keymap_count = 4;
  * the default and allocate dynamically in chunks of 512 bytes.
  */
 
-char func_buf[] = {
+char ebc_func_buf[] = {
 	'\033', '[', '[', 'A', 0, 
 	'\033', '[', '[', 'B', 0, 
 	'\033', '[', '[', 'C', 0, 
@@ -123,37 +125,37 @@ char func_buf[] = {
 };
 
 
-char *funcbufptr = func_buf;
-int funcbufsize = sizeof(func_buf);
-int funcbufleft = 0;          /* space left */
-
-char *func_table[MAX_NR_FUNC] = {
-	func_buf + 0,
-	func_buf + 5,
-	func_buf + 10,
-	func_buf + 15,
-	func_buf + 20,
-	func_buf + 25,
-	func_buf + 31,
-	func_buf + 37,
-	func_buf + 43,
-	func_buf + 49,
-	func_buf + 55,
-	func_buf + 61,
-	func_buf + 67,
-	func_buf + 73,
-	func_buf + 79,
-	func_buf + 85,
-	func_buf + 91,
-	func_buf + 97,
-	func_buf + 103,
-	func_buf + 109,
+char *ebc_funcbufptr = ebc_func_buf;
+int ebc_funcbufsize = sizeof(ebc_func_buf);
+int ebc_funcbufleft = 0;          /* space left */
+
+char *ebc_func_table[MAX_NR_FUNC] = {
+	ebc_func_buf + 0,
+	ebc_func_buf + 5,
+	ebc_func_buf + 10,
+	ebc_func_buf + 15,
+	ebc_func_buf + 20,
+	ebc_func_buf + 25,
+	ebc_func_buf + 31,
+	ebc_func_buf + 37,
+	ebc_func_buf + 43,
+	ebc_func_buf + 49,
+	ebc_func_buf + 55,
+	ebc_func_buf + 61,
+	ebc_func_buf + 67,
+	ebc_func_buf + 73,
+	ebc_func_buf + 79,
+	ebc_func_buf + 85,
+	ebc_func_buf + 91,
+	ebc_func_buf + 97,
+	ebc_func_buf + 103,
+	ebc_func_buf + 109,
 	NULL,
 };
 
-struct kbdiacruc accent_table[MAX_DIACR] = {
+struct kbdiacruc ebc_accent_table[MAX_DIACR] = {
 	{'^', 'c', 0003},	{'^', 'd', 0004},
 	{'^', 'z', 0032},	{'^', 0012, 0000},
 };
 
-unsigned int accent_table_size = 4;
+unsigned int ebc_accent_table_size = 4;
diff --git a/drivers/s390/char/keyboard.c b/drivers/s390/char/keyboard.c
index 5b505fd..db1fbf9 100644
--- a/drivers/s390/char/keyboard.c
+++ b/drivers/s390/char/keyboard.c
@@ -54,24 +54,24 @@ kbd_alloc(void) {
 	kbd = kzalloc(sizeof(struct kbd_data), GFP_KERNEL);
 	if (!kbd)
 		goto out;
-	kbd->key_maps = kzalloc(sizeof(key_maps), GFP_KERNEL);
+	kbd->key_maps = kzalloc(sizeof(ebc_key_maps), GFP_KERNEL);
 	if (!kbd->key_maps)
 		goto out_kbd;
-	for (i = 0; i < ARRAY_SIZE(key_maps); i++) {
-		if (key_maps[i]) {
-			kbd->key_maps[i] = kmemdup(key_maps[i],
+	for (i = 0; i < ARRAY_SIZE(ebc_key_maps); i++) {
+		if (ebc_key_maps[i]) {
+			kbd->key_maps[i] = kmemdup(ebc_key_maps[i],
 						   sizeof(u_short) * NR_KEYS,
 						   GFP_KERNEL);
 			if (!kbd->key_maps[i])
 				goto out_maps;
 		}
 	}
-	kbd->func_table = kzalloc(sizeof(func_table), GFP_KERNEL);
+	kbd->func_table = kzalloc(sizeof(ebc_func_table), GFP_KERNEL);
 	if (!kbd->func_table)
 		goto out_maps;
-	for (i = 0; i < ARRAY_SIZE(func_table); i++) {
-		if (func_table[i]) {
-			kbd->func_table[i] = kstrdup(func_table[i],
+	for (i = 0; i < ARRAY_SIZE(ebc_func_table); i++) {
+		if (ebc_func_table[i]) {
+			kbd->func_table[i] = kstrdup(ebc_func_table[i],
 						     GFP_KERNEL);
 			if (!kbd->func_table[i])
 				goto out_func;
@@ -81,22 +81,22 @@ kbd_alloc(void) {
 		kzalloc(sizeof(fn_handler_fn *) * NR_FN_HANDLER, GFP_KERNEL);
 	if (!kbd->fn_handler)
 		goto out_func;
-	kbd->accent_table = kmemdup(accent_table,
+	kbd->accent_table = kmemdup(ebc_accent_table,
 				    sizeof(struct kbdiacruc) * MAX_DIACR,
 				    GFP_KERNEL);
 	if (!kbd->accent_table)
 		goto out_fn_handler;
-	kbd->accent_table_size = accent_table_size;
+	kbd->accent_table_size = ebc_accent_table_size;
 	return kbd;
 
 out_fn_handler:
 	kfree(kbd->fn_handler);
 out_func:
-	for (i = 0; i < ARRAY_SIZE(func_table); i++)
+	for (i = 0; i < ARRAY_SIZE(ebc_func_table); i++)
 		kfree(kbd->func_table[i]);
 	kfree(kbd->func_table);
 out_maps:
-	for (i = 0; i < ARRAY_SIZE(key_maps); i++)
+	for (i = 0; i < ARRAY_SIZE(ebc_key_maps); i++)
 		kfree(kbd->key_maps[i]);
 	kfree(kbd->key_maps);
 out_kbd:
@@ -112,10 +112,10 @@ kbd_free(struct kbd_data *kbd)
 
 	kfree(kbd->accent_table);
 	kfree(kbd->fn_handler);
-	for (i = 0; i < ARRAY_SIZE(func_table); i++)
+	for (i = 0; i < ARRAY_SIZE(ebc_func_table); i++)
 		kfree(kbd->func_table[i]);
 	kfree(kbd->func_table);
-	for (i = 0; i < ARRAY_SIZE(key_maps); i++)
+	for (i = 0; i < ARRAY_SIZE(ebc_key_maps); i++)
 		kfree(kbd->key_maps[i]);
 	kfree(kbd->key_maps);
 	kfree(kbd);
@@ -131,7 +131,7 @@ kbd_ascebc(struct kbd_data *kbd, unsigned char *ascebc)
 	int i, j, k;
 
 	memset(ascebc, 0x40, 256);
-	for (i = 0; i < ARRAY_SIZE(key_maps); i++) {
+	for (i = 0; i < ARRAY_SIZE(ebc_key_maps); i++) {
 		keymap = kbd->key_maps[i];
 		if (!keymap)
 			continue;
@@ -158,7 +158,7 @@ kbd_ebcasc(struct kbd_data *kbd, unsigned char *ebcasc)
 	int i, j, k;
 
 	memset(ebcasc, ' ', 256);
-	for (i = 0; i < ARRAY_SIZE(key_maps); i++) {
+	for (i = 0; i < ARRAY_SIZE(ebc_key_maps); i++) {
 		keymap = kbd->key_maps[i];
 		if (!keymap)
 			continue;
diff --git a/drivers/s390/char/keyboard.h b/drivers/s390/char/keyboard.h
index a074d97..c467589 100644
--- a/drivers/s390/char/keyboard.h
+++ b/drivers/s390/char/keyboard.h
@@ -14,6 +14,17 @@
 
 struct kbd_data;
 
+extern int ebc_funcbufsize, ebc_funcbufleft;
+extern char *ebc_func_table[MAX_NR_FUNC];
+extern char ebc_func_buf[];
+extern char *ebc_funcbufptr;
+extern unsigned int ebc_keymap_count;
+
+extern struct kbdiacruc ebc_accent_table[];
+extern unsigned int ebc_accent_table_size;
+extern unsigned short *ebc_key_maps[MAX_NR_KEYMAPS];
+extern unsigned short ebc_plain_map[NR_KEYS];
+
 typedef void (fn_handler_fn)(struct kbd_data *);
 
 /*
-- 
2.7.4

[PATCH v2 3/3] s390/setup : enable display support for KVM guest

[Farhan Ali]

The S390 architecture does not support any graphics hardware,
but with the latest support for Virtio GPU in Linux and Virtio
GPU emulation in QEMU, it's possible to enable graphics for
S390 using the Virtio GPU device.

To enable display we need to enable the Linux Virtual Terminal (VT)
layer for S390. But the VT subsystem initializes quite early
at boot so we need a dummy console driver till the Virtio GPU
driver is initialized and we can run the framebuffer console.

The framebuffer console over a Virtio GPU device can be run
in combination with the serial SCLP console (default on S390).
The SCLP console can still be accessed by management applications
(eg: via Libvirt's virsh console).

Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 arch/s390/kernel/setup.c      | 2 ++
 drivers/tty/Kconfig           | 2 +-
 drivers/video/console/Kconfig | 2 +-
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index 793da97..0c1070c 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -220,6 +220,8 @@ static void __init conmode_default(void)
 		SET_CONSOLE_SCLP;
 #endif
 	}
+	if (IS_ENABLED(CONFIG_VT) && IS_ENABLED(CONFIG_DUMMY_CONSOLE))
+		conswitchp = &dummy_con;
 }
 
 #ifdef CONFIG_CRASH_DUMP
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index cc2b4d9..8481007 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -11,7 +11,7 @@ if TTY
 
 config VT
 	bool "Virtual terminal" if EXPERT
-	depends on !S390 && !UML
+	depends on !UML
 	select INPUT
 	default y
 	---help---
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 7f1f1fb..8ba2565 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -9,7 +9,7 @@ config VGA_CONSOLE
 	depends on !4xx && !PPC_8xx && !SPARC && !M68K && !PARISC && !FRV && \
 		!SUPERH && !BLACKFIN && !AVR32 && !MN10300 && !CRIS && \
 		(!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) && \
-		!ARM64 && !ARC && !MICROBLAZE && !OPENRISC
+		!ARM64 && !ARC && !MICROBLAZE && !OPENRISC && !S390
 	default y
 	help
 	  Saying Y here will allow you to use Linux in text mode through a
-- 
2.7.4

[PATCH v2 3/3] s390/setup : enable display support for KVM guest

[Farhan Ali]

The S390 architecture does not support any graphics hardware,
but with the latest support for Virtio GPU in Linux and Virtio
GPU emulation in QEMU, it's possible to enable graphics for
S390 using the Virtio GPU device.

To enable display we need to enable the Linux Virtual Terminal (VT)
layer for S390. But the VT subsystem initializes quite early
at boot so we need a dummy console driver till the Virtio GPU
driver is initialized and we can run the framebuffer console.

The framebuffer console over a Virtio GPU device can be run
in combination with the serial SCLP console (default on S390).
The SCLP console can still be accessed by management applications
(eg: via Libvirt's virsh console).

Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 arch/s390/kernel/setup.c      | 2 ++
 drivers/tty/Kconfig           | 2 +-
 drivers/video/console/Kconfig | 2 +-
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index 793da97..0c1070c 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -220,6 +220,8 @@ static void __init conmode_default(void)
 		SET_CONSOLE_SCLP;
 #endif
 	}
+	if (IS_ENABLED(CONFIG_VT) && IS_ENABLED(CONFIG_DUMMY_CONSOLE))
+		conswitchp = &dummy_con;
 }
 
 #ifdef CONFIG_CRASH_DUMP
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index cc2b4d9..8481007 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -11,7 +11,7 @@ if TTY
 
 config VT
 	bool "Virtual terminal" if EXPERT
-	depends on !S390 && !UML
+	depends on !UML
 	select INPUT
 	default y
 	---help---
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 7f1f1fb..8ba2565 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -9,7 +9,7 @@ config VGA_CONSOLE
 	depends on !4xx && !PPC_8xx && !SPARC && !M68K && !PARISC && !FRV && \
 		!SUPERH && !BLACKFIN && !AVR32 && !MN10300 && !CRIS && \
 		(!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) && \
-		!ARM64 && !ARC && !MICROBLAZE && !OPENRISC
+		!ARM64 && !ARC && !MICROBLAZE && !OPENRISC && !S390
 	default y
 	help
 	  Saying Y here will allow you to use Linux in text mode through a
-- 
2.7.4

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

On 02/01/2018 07:41 PM, Farhan Ali wrote:
> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
> "Graphics support" menu for S390. But if we enable VT layer for S390,
> we would also need to enable the dummy console. So let's remove the
> HAS_IOMEM dependency.
> 
> Move this dependency to Opencores framebuffer driver which would fail to build
> with CONFIG_HAS_IOMEM disabled:
> 
> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
> Tested-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>

This also enables several PCI based graphic device driver on s390.
This makes no sense but they all compile fine so I guess this is ok.

I think patch 2 and 3 are clearly for the s390 tree, patch 1 seems trivial
Also ccing Bart. Can we maybe get an ack to carry this patch also via the s390
tree?


> ---
>  drivers/video/Kconfig       | 1 -
>  drivers/video/fbdev/Kconfig | 2 +-
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 3c20af9..41e7ba9 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -3,7 +3,6 @@
>  #
> 
>  menu "Graphics support"
> -	depends on HAS_IOMEM
> 
>  config HAVE_FB_ATMEL
>  	bool
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 2f615b7..ec9c9ce 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -966,7 +966,7 @@ config FB_PVR2
> 
>  config FB_OPENCORES
>  	tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
> -	depends on FB && HAS_DMA
> +	depends on FB && HAS_DMA && HAS_IOMEM
>  	select FB_CFB_FILLRECT
>  	select FB_CFB_COPYAREA
>  	select FB_CFB_IMAGEBLIT
> 

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

On 02/01/2018 07:41 PM, Farhan Ali wrote:
> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
> "Graphics support" menu for S390. But if we enable VT layer for S390,
> we would also need to enable the dummy console. So let's remove the
> HAS_IOMEM dependency.
> 
> Move this dependency to Opencores framebuffer driver which would fail to build
> with CONFIG_HAS_IOMEM disabled:
> 
> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
> Tested-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>

This also enables several PCI based graphic device driver on s390.
This makes no sense but they all compile fine so I guess this is ok.

I think patch 2 and 3 are clearly for the s390 tree, patch 1 seems trivial
Also ccing Bart. Can we maybe get an ack to carry this patch also via the s390
tree?


> ---
>  drivers/video/Kconfig       | 1 -
>  drivers/video/fbdev/Kconfig | 2 +-
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 3c20af9..41e7ba9 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -3,7 +3,6 @@
>  #
> 
>  menu "Graphics support"
> -	depends on HAS_IOMEM
> 
>  config HAVE_FB_ATMEL
>  	bool
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 2f615b7..ec9c9ce 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -966,7 +966,7 @@ config FB_PVR2
> 
>  config FB_OPENCORES
>  	tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
> -	depends on FB && HAS_DMA
> +	depends on FB && HAS_DMA && HAS_IOMEM
>  	select FB_CFB_FILLRECT
>  	select FB_CFB_COPYAREA
>  	select FB_CFB_IMAGEBLIT
> 

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Thomas Huth]

On 01.02.2018 19:41, Farhan Ali wrote:
> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
> "Graphics support" menu for S390. But if we enable VT layer for S390,
> we would also need to enable the dummy console. So let's remove the
> HAS_IOMEM dependency.
> 
> Move this dependency to Opencores framebuffer driver which would fail to build
> with CONFIG_HAS_IOMEM disabled:
> 
> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
> Tested-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
> ---
>  drivers/video/Kconfig       | 1 -
>  drivers/video/fbdev/Kconfig | 2 +-
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 3c20af9..41e7ba9 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -3,7 +3,6 @@
>  #
>  
>  menu "Graphics support"
> -	depends on HAS_IOMEM
>  
>  config HAVE_FB_ATMEL
>  	bool
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 2f615b7..ec9c9ce 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -966,7 +966,7 @@ config FB_PVR2
>  
>  config FB_OPENCORES
>  	tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
> -	depends on FB && HAS_DMA
> +	depends on FB && HAS_DMA && HAS_IOMEM
>  	select FB_CFB_FILLRECT
>  	select FB_CFB_COPYAREA
>  	select FB_CFB_IMAGEBLIT
> 

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Thomas Huth]

On 01.02.2018 19:41, Farhan Ali wrote:
> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
> "Graphics support" menu for S390. But if we enable VT layer for S390,
> we would also need to enable the dummy console. So let's remove the
> HAS_IOMEM dependency.
> 
> Move this dependency to Opencores framebuffer driver which would fail to build
> with CONFIG_HAS_IOMEM disabled:
> 
> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
> Tested-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
> ---
>  drivers/video/Kconfig       | 1 -
>  drivers/video/fbdev/Kconfig | 2 +-
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 3c20af9..41e7ba9 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -3,7 +3,6 @@
>  #
>  
>  menu "Graphics support"
> -	depends on HAS_IOMEM
>  
>  config HAVE_FB_ATMEL
>  	bool
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 2f615b7..ec9c9ce 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -966,7 +966,7 @@ config FB_PVR2
>  
>  config FB_OPENCORES
>  	tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
> -	depends on FB && HAS_DMA
> +	depends on FB && HAS_DMA && HAS_IOMEM
>  	select FB_CFB_FILLRECT
>  	select FB_CFB_COPYAREA
>  	select FB_CFB_IMAGEBLIT
> 

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Bartlomiej Zolnierkiewicz]

Hi,

[ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]

On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
> On 02/01/2018 07:41 PM, Farhan Ali wrote:
> > The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
> > added the HAS_IOMEM dependecy for "Graphics support". This disabled the
> > "Graphics support" menu for S390. But if we enable VT layer for S390,
> > we would also need to enable the dummy console. So let's remove the
> > HAS_IOMEM dependency.
> >
> > Move this dependency to Opencores framebuffer driver which would fail to build
> > with CONFIG_HAS_IOMEM disabled:
> > 
> > ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!

"Graphics support" menu covers other things (i.e. DRM), I assume that
they were also checked to not break due to this change?

Moreover it seems that after this change "Graphics support" menu will
be also enabled (besides s390) for score, tile and um architectures,
I assume that this is okay?

> > Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
> > Tested-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
> 
> This also enables several PCI based graphic device driver on s390.
> This makes no sense but they all compile fine so I guess this is ok.
> 
> I think patch 2 and 3 are clearly for the s390 tree, patch 1 seems trivial
> Also ccing Bart. Can we maybe get an ack to carry this patch also via the s390
> tree?
> 
> 
> > ---
> >  drivers/video/Kconfig       | 1 -
> >  drivers/video/fbdev/Kconfig | 2 +-
> >  2 files changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index 3c20af9..41e7ba9 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -3,7 +3,6 @@
> >  #
> > 
> >  menu "Graphics support"
> > -	depends on HAS_IOMEM
> > 
> >  config HAVE_FB_ATMEL
> >  	bool
> > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> > index 2f615b7..ec9c9ce 100644
> > --- a/drivers/video/fbdev/Kconfig
> > +++ b/drivers/video/fbdev/Kconfig
> > @@ -966,7 +966,7 @@ config FB_PVR2
> > 
> >  config FB_OPENCORES
> >  	tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
> > -	depends on FB && HAS_DMA
> > +	depends on FB && HAS_DMA && HAS_IOMEM
> >  	select FB_CFB_FILLRECT
> >  	select FB_CFB_COPYAREA
> >  	select FB_CFB_IMAGEBLIT

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Bartlomiej Zolnierkiewicz]

Hi,

[ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]

On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
> On 02/01/2018 07:41 PM, Farhan Ali wrote:
> > The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
> > added the HAS_IOMEM dependecy for "Graphics support". This disabled the
> > "Graphics support" menu for S390. But if we enable VT layer for S390,
> > we would also need to enable the dummy console. So let's remove the
> > HAS_IOMEM dependency.
> >
> > Move this dependency to Opencores framebuffer driver which would fail to build
> > with CONFIG_HAS_IOMEM disabled:
> > 
> > ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!

"Graphics support" menu covers other things (i.e. DRM), I assume that
they were also checked to not break due to this change?

Moreover it seems that after this change "Graphics support" menu will
be also enabled (besides s390) for score, tile and um architectures,
I assume that this is okay?

> > Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
> > Tested-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
> 
> This also enables several PCI based graphic device driver on s390.
> This makes no sense but they all compile fine so I guess this is ok.
> 
> I think patch 2 and 3 are clearly for the s390 tree, patch 1 seems trivial
> Also ccing Bart. Can we maybe get an ack to carry this patch also via the s390
> tree?
> 
> 
> > ---
> >  drivers/video/Kconfig       | 1 -
> >  drivers/video/fbdev/Kconfig | 2 +-
> >  2 files changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index 3c20af9..41e7ba9 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -3,7 +3,6 @@
> >  #
> > 
> >  menu "Graphics support"
> > -	depends on HAS_IOMEM
> > 
> >  config HAVE_FB_ATMEL
> >  	bool
> > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> > index 2f615b7..ec9c9ce 100644
> > --- a/drivers/video/fbdev/Kconfig
> > +++ b/drivers/video/fbdev/Kconfig
> > @@ -966,7 +966,7 @@ config FB_PVR2
> > 
> >  config FB_OPENCORES
> >  	tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
> > -	depends on FB && HAS_DMA
> > +	depends on FB && HAS_DMA && HAS_IOMEM
> >  	select FB_CFB_FILLRECT
> >  	select FB_CFB_COPYAREA
> >  	select FB_CFB_IMAGEBLIT

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Farhan Ali]

On 02/08/2018 08:11 AM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
> 
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
>>> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
>>> "Graphics support" menu for S390. But if we enable VT layer for S390,
>>> we would also need to enable the dummy console. So let's remove the
>>> HAS_IOMEM dependency.
>>>
>>> Move this dependency to Opencores framebuffer driver which would fail to build
>>> with CONFIG_HAS_IOMEM disabled:
>>>
>>> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> "Graphics support" menu covers other things (i.e. DRM), I assume that
> they were also checked to not break due to this change?
> 
Yes, DRM compiled fine. And we (s390) would need the DRM subsystem for 
Virtio GPU as well.

> Moreover it seems that after this change "Graphics support" menu will
> be also enabled (besides s390) for score, tile and um architectures,
> I assume that this is okay?
> 
>>> Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
>>> Tested-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
>>
>> This also enables several PCI based graphic device driver on s390.
>> This makes no sense but they all compile fine so I guess this is ok.
>>
>> I think patch 2 and 3 are clearly for the s390 tree, patch 1 seems trivial
>> Also ccing Bart. Can we maybe get an ack to carry this patch also via the s390
>> tree?
>>
>>
>>> ---
>>>   drivers/video/Kconfig       | 1 -
>>>   drivers/video/fbdev/Kconfig | 2 +-
>>>   2 files changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>>> index 3c20af9..41e7ba9 100644
>>> --- a/drivers/video/Kconfig
>>> +++ b/drivers/video/Kconfig
>>> @@ -3,7 +3,6 @@
>>>   #
>>>
>>>   menu "Graphics support"
>>> -	depends on HAS_IOMEM
>>>
>>>   config HAVE_FB_ATMEL
>>>   	bool
>>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>>> index 2f615b7..ec9c9ce 100644
>>> --- a/drivers/video/fbdev/Kconfig
>>> +++ b/drivers/video/fbdev/Kconfig
>>> @@ -966,7 +966,7 @@ config FB_PVR2
>>>
>>>   config FB_OPENCORES
>>>   	tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
>>> -	depends on FB && HAS_DMA
>>> +	depends on FB && HAS_DMA && HAS_IOMEM
>>>   	select FB_CFB_FILLRECT
>>>   	select FB_CFB_COPYAREA
>>>   	select FB_CFB_IMAGEBLIT
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
> 

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Farhan Ali]

On 02/08/2018 08:11 AM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
> 
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
>>> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
>>> "Graphics support" menu for S390. But if we enable VT layer for S390,
>>> we would also need to enable the dummy console. So let's remove the
>>> HAS_IOMEM dependency.
>>>
>>> Move this dependency to Opencores framebuffer driver which would fail to build
>>> with CONFIG_HAS_IOMEM disabled:
>>>
>>> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> "Graphics support" menu covers other things (i.e. DRM), I assume that
> they were also checked to not break due to this change?
> 
Yes, DRM compiled fine. And we (s390) would need the DRM subsystem for 
Virtio GPU as well.

> Moreover it seems that after this change "Graphics support" menu will
> be also enabled (besides s390) for score, tile and um architectures,
> I assume that this is okay?
> 
>>> Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
>>> Tested-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
>>
>> This also enables several PCI based graphic device driver on s390.
>> This makes no sense but they all compile fine so I guess this is ok.
>>
>> I think patch 2 and 3 are clearly for the s390 tree, patch 1 seems trivial
>> Also ccing Bart. Can we maybe get an ack to carry this patch also via the s390
>> tree?
>>
>>
>>> ---
>>>   drivers/video/Kconfig       | 1 -
>>>   drivers/video/fbdev/Kconfig | 2 +-
>>>   2 files changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>>> index 3c20af9..41e7ba9 100644
>>> --- a/drivers/video/Kconfig
>>> +++ b/drivers/video/Kconfig
>>> @@ -3,7 +3,6 @@
>>>   #
>>>
>>>   menu "Graphics support"
>>> -	depends on HAS_IOMEM
>>>
>>>   config HAVE_FB_ATMEL
>>>   	bool
>>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>>> index 2f615b7..ec9c9ce 100644
>>> --- a/drivers/video/fbdev/Kconfig
>>> +++ b/drivers/video/fbdev/Kconfig
>>> @@ -966,7 +966,7 @@ config FB_PVR2
>>>
>>>   config FB_OPENCORES
>>>   	tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
>>> -	depends on FB && HAS_DMA
>>> +	depends on FB && HAS_DMA && HAS_IOMEM
>>>   	select FB_CFB_FILLRECT
>>>   	select FB_CFB_COPYAREA
>>>   	select FB_CFB_IMAGEBLIT
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
> 

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

On 02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
> 
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
>>> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
>>> "Graphics support" menu for S390. But if we enable VT layer for S390,
>>> we would also need to enable the dummy console. So let's remove the
>>> HAS_IOMEM dependency.
>>>
>>> Move this dependency to Opencores framebuffer driver which would fail to build
>>> with CONFIG_HAS_IOMEM disabled:
>>>
>>> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> "Graphics support" menu covers other things (i.e. DRM), I assume that
> they were also checked to not break due to this change?
> 
> Moreover it seems that after this change "Graphics support" menu will
> be also enabled (besides s390) for score, tile and um architectures,
> I assume that this is okay?

I can add this patch to my next tree (after merge window) and check for
any errors from all the build bots.

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

On 02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
> 
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
>>> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
>>> "Graphics support" menu for S390. But if we enable VT layer for S390,
>>> we would also need to enable the dummy console. So let's remove the
>>> HAS_IOMEM dependency.
>>>
>>> Move this dependency to Opencores framebuffer driver which would fail to build
>>> with CONFIG_HAS_IOMEM disabled:
>>>
>>> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> "Graphics support" menu covers other things (i.e. DRM), I assume that
> they were also checked to not break due to this change?
> 
> Moreover it seems that after this change "Graphics support" menu will
> be also enabled (besides s390) for score, tile and um architectures,
> I assume that this is okay?

I can add this patch to my next tree (after merge window) and check for
any errors from all the build bots.

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

I added all three patches to my next tree
https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git/log/?h=next
This will hoepfully reveal any fallout.

Would be good to have an ACK from the score, tile and um maintainers in case
they verified that this change did not break anything.



On 02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
> 
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
>>> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
>>> "Graphics support" menu for S390. But if we enable VT layer for S390,
>>> we would also need to enable the dummy console. So let's remove the
>>> HAS_IOMEM dependency.
>>>
>>> Move this dependency to Opencores framebuffer driver which would fail to build
>>> with CONFIG_HAS_IOMEM disabled:
>>>
>>> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> "Graphics support" menu covers other things (i.e. DRM), I assume that
> they were also checked to not break due to this change?
> 
> Moreover it seems that after this change "Graphics support" menu will
> be also enabled (besides s390) for score, tile and um architectures,
> I assume that this is okay?
> 
>>> Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
>>> Tested-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
>>
>> This also enables several PCI based graphic device driver on s390.
>> This makes no sense but they all compile fine so I guess this is ok.
>>
>> I think patch 2 and 3 are clearly for the s390 tree, patch 1 seems trivial
>> Also ccing Bart. Can we maybe get an ack to carry this patch also via the s390
>> tree?
>>
>>
>>> ---
>>>  drivers/video/Kconfig       | 1 -
>>>  drivers/video/fbdev/Kconfig | 2 +-
>>>  2 files changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>>> index 3c20af9..41e7ba9 100644
>>> --- a/drivers/video/Kconfig
>>> +++ b/drivers/video/Kconfig
>>> @@ -3,7 +3,6 @@
>>>  #
>>>
>>>  menu "Graphics support"
>>> -	depends on HAS_IOMEM
>>>
>>>  config HAVE_FB_ATMEL
>>>  	bool
>>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>>> index 2f615b7..ec9c9ce 100644
>>> --- a/drivers/video/fbdev/Kconfig
>>> +++ b/drivers/video/fbdev/Kconfig
>>> @@ -966,7 +966,7 @@ config FB_PVR2
>>>
>>>  config FB_OPENCORES
>>>  	tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
>>> -	depends on FB && HAS_DMA
>>> +	depends on FB && HAS_DMA && HAS_IOMEM
>>>  	select FB_CFB_FILLRECT
>>>  	select FB_CFB_COPYAREA
>>>  	select FB_CFB_IMAGEBLIT
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
> 

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

I added all three patches to my next tree
https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git/log/?h=next
This will hoepfully reveal any fallout.

Would be good to have an ACK from the score, tile and um maintainers in case
they verified that this change did not break anything.



On 02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
> 
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
>>> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
>>> "Graphics support" menu for S390. But if we enable VT layer for S390,
>>> we would also need to enable the dummy console. So let's remove the
>>> HAS_IOMEM dependency.
>>>
>>> Move this dependency to Opencores framebuffer driver which would fail to build
>>> with CONFIG_HAS_IOMEM disabled:
>>>
>>> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> "Graphics support" menu covers other things (i.e. DRM), I assume that
> they were also checked to not break due to this change?
> 
> Moreover it seems that after this change "Graphics support" menu will
> be also enabled (besides s390) for score, tile and um architectures,
> I assume that this is okay?
> 
>>> Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
>>> Tested-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
>>
>> This also enables several PCI based graphic device driver on s390.
>> This makes no sense but they all compile fine so I guess this is ok.
>>
>> I think patch 2 and 3 are clearly for the s390 tree, patch 1 seems trivial
>> Also ccing Bart. Can we maybe get an ack to carry this patch also via the s390
>> tree?
>>
>>
>>> ---
>>>  drivers/video/Kconfig       | 1 -
>>>  drivers/video/fbdev/Kconfig | 2 +-
>>>  2 files changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>>> index 3c20af9..41e7ba9 100644
>>> --- a/drivers/video/Kconfig
>>> +++ b/drivers/video/Kconfig
>>> @@ -3,7 +3,6 @@
>>>  #
>>>
>>>  menu "Graphics support"
>>> -	depends on HAS_IOMEM
>>>
>>>  config HAVE_FB_ATMEL
>>>  	bool
>>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>>> index 2f615b7..ec9c9ce 100644
>>> --- a/drivers/video/fbdev/Kconfig
>>> +++ b/drivers/video/fbdev/Kconfig
>>> @@ -966,7 +966,7 @@ config FB_PVR2
>>>
>>>  config FB_OPENCORES
>>>  	tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
>>> -	depends on FB && HAS_DMA
>>> +	depends on FB && HAS_DMA && HAS_IOMEM
>>>  	select FB_CFB_FILLRECT
>>>  	select FB_CFB_COPYAREA
>>>  	select FB_CFB_IMAGEBLIT
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
> 

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

On 02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
> 
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
>>> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
>>> "Graphics support" menu for S390. But if we enable VT layer for S390,
>>> we would also need to enable the dummy console. So let's remove the
>>> HAS_IOMEM dependency.
>>>
>>> Move this dependency to Opencores framebuffer driver which would fail to build
>>> with CONFIG_HAS_IOMEM disabled:
>>>
>>> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> "Graphics support" menu covers other things (i.e. DRM), I assume that
> they were also checked to not break due to this change?
> 
> Moreover it seems that after this change "Graphics support" menu will
> be also enabled (besides s390) for score, tile and um architectures,
> I assume that this is okay?



Turns out that patch fails to build with.

So what about the following approach instead:

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 3c20af999893..5ae512fe52ed 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -47,3 +47,28 @@ endif
 
 
 endmenu
+
+config DUMMY_CONSOLE
+       bool
+       depends on VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y
+       default y
+
+config DUMMY_CONSOLE_COLUMNS
+        int "Initial number of console screen columns"
+        depends on DUMMY_CONSOLE && !ARM
+        default 160 if PARISC
+        default 80
+        help
+          On PA-RISC, the default value is 160, which should fit a 1280x1024
+          monitor.
+          Select 80 if you use a 640x480 resolution by default.
+
+config DUMMY_CONSOLE_ROWS
+        int "Initial number of console screen rows"
+        depends on DUMMY_CONSOLE && !ARM
+        default 64 if PARISC
+        default 25
+        help
+          On PA-RISC, the default value is 64, which should fit a 1280x1024
+          monitor.
+          Select 25 if you use a 640x480 resolution by default.
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 7f1f1fbcef9e..97ae3c349666 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -91,31 +91,6 @@ config SGI_NEWPORT_CONSOLE
           Say Y here if you want the console on the Newport aka XL graphics
           card of your Indy.  Most people say Y here.
 
-config DUMMY_CONSOLE
-       bool
-       depends on VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y 
-       default y
-
-config DUMMY_CONSOLE_COLUMNS
-        int "Initial number of console screen columns"
-        depends on DUMMY_CONSOLE && !ARM
-        default 160 if PARISC
-        default 80
-        help
-          On PA-RISC, the default value is 160, which should fit a 1280x1024
-          monitor.
-          Select 80 if you use a 640x480 resolution by default.
-
-config DUMMY_CONSOLE_ROWS
-        int "Initial number of console screen rows"
-        depends on DUMMY_CONSOLE && !ARM
-        default 64 if PARISC
-        default 25
-        help
-          On PA-RISC, the default value is 64, which should fit a 1280x1024
-          monitor.
-          Select 25 if you use a 640x480 resolution by default.
-
 config FRAMEBUFFER_CONSOLE
        bool "Framebuffer Console support"
        depends on FB && !UML

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

On 02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
> 
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
>>> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
>>> "Graphics support" menu for S390. But if we enable VT layer for S390,
>>> we would also need to enable the dummy console. So let's remove the
>>> HAS_IOMEM dependency.
>>>
>>> Move this dependency to Opencores framebuffer driver which would fail to build
>>> with CONFIG_HAS_IOMEM disabled:
>>>
>>> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> "Graphics support" menu covers other things (i.e. DRM), I assume that
> they were also checked to not break due to this change?
> 
> Moreover it seems that after this change "Graphics support" menu will
> be also enabled (besides s390) for score, tile and um architectures,
> I assume that this is okay?



Turns out that patch fails to build with.

So what about the following approach instead:

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 3c20af999893..5ae512fe52ed 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -47,3 +47,28 @@ endif
 
 
 endmenu
+
+config DUMMY_CONSOLE
+       bool
+       depends on VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y
+       default y
+
+config DUMMY_CONSOLE_COLUMNS
+        int "Initial number of console screen columns"
+        depends on DUMMY_CONSOLE && !ARM
+        default 160 if PARISC
+        default 80
+        help
+          On PA-RISC, the default value is 160, which should fit a 1280x1024
+          monitor.
+          Select 80 if you use a 640x480 resolution by default.
+
+config DUMMY_CONSOLE_ROWS
+        int "Initial number of console screen rows"
+        depends on DUMMY_CONSOLE && !ARM
+        default 64 if PARISC
+        default 25
+        help
+          On PA-RISC, the default value is 64, which should fit a 1280x1024
+          monitor.
+          Select 25 if you use a 640x480 resolution by default.
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 7f1f1fbcef9e..97ae3c349666 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -91,31 +91,6 @@ config SGI_NEWPORT_CONSOLE
           Say Y here if you want the console on the Newport aka XL graphics
           card of your Indy.  Most people say Y here.
 
-config DUMMY_CONSOLE
-       bool
-       depends on VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y 
-       default y
-
-config DUMMY_CONSOLE_COLUMNS
-        int "Initial number of console screen columns"
-        depends on DUMMY_CONSOLE && !ARM
-        default 160 if PARISC
-        default 80
-        help
-          On PA-RISC, the default value is 160, which should fit a 1280x1024
-          monitor.
-          Select 80 if you use a 640x480 resolution by default.
-
-config DUMMY_CONSOLE_ROWS
-        int "Initial number of console screen rows"
-        depends on DUMMY_CONSOLE && !ARM
-        default 64 if PARISC
-        default 25
-        help
-          On PA-RISC, the default value is 64, which should fit a 1280x1024
-          monitor.
-          Select 25 if you use a 640x480 resolution by default.
-
 config FRAMEBUFFER_CONSOLE
        bool "Framebuffer Console support"
        depends on FB && !UML

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

On 02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
> 
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
>>> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
>>> "Graphics support" menu for S390. But if we enable VT layer for S390,
>>> we would also need to enable the dummy console. So let's remove the
>>> HAS_IOMEM dependency.
>>>
>>> Move this dependency to Opencores framebuffer driver which would fail to build
>>> with CONFIG_HAS_IOMEM disabled:
>>>
>>> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> "Graphics support" menu covers other things (i.e. DRM), I assume that
> they were also checked to not break due to this change?
> 
> Moreover it seems that after this change "Graphics support" menu will
> be also enabled (besides s390) for score, tile and um architectures,
> I assume that this is okay?



Turns out that patch fails to build with.

So what about the following approach instead:

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 3c20af999893..5ae512fe52ed 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -47,3 +47,28 @@ endif
 
 
 endmenu
+
+config DUMMY_CONSOLE
+       bool
+       depends on VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y
+       default y
+
+config DUMMY_CONSOLE_COLUMNS
+        int "Initial number of console screen columns"
+        depends on DUMMY_CONSOLE && !ARM
+        default 160 if PARISC
+        default 80
+        help
+          On PA-RISC, the default value is 160, which should fit a 1280x1024
+          monitor.
+          Select 80 if you use a 640x480 resolution by default.
+
+config DUMMY_CONSOLE_ROWS
+        int "Initial number of console screen rows"
+        depends on DUMMY_CONSOLE && !ARM
+        default 64 if PARISC
+        default 25
+        help
+          On PA-RISC, the default value is 64, which should fit a 1280x1024
+          monitor.
+          Select 25 if you use a 640x480 resolution by default.
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 7f1f1fbcef9e..97ae3c349666 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -91,31 +91,6 @@ config SGI_NEWPORT_CONSOLE
           Say Y here if you want the console on the Newport aka XL graphics
           card of your Indy.  Most people say Y here.
 
-config DUMMY_CONSOLE
-       bool
-       depends on VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y 
-       default y
-
-config DUMMY_CONSOLE_COLUMNS
-        int "Initial number of console screen columns"
-        depends on DUMMY_CONSOLE && !ARM
-        default 160 if PARISC
-        default 80
-        help
-          On PA-RISC, the default value is 160, which should fit a 1280x1024
-          monitor.
-          Select 80 if you use a 640x480 resolution by default.
-
-config DUMMY_CONSOLE_ROWS
-        int "Initial number of console screen rows"
-        depends on DUMMY_CONSOLE && !ARM
-        default 64 if PARISC
-        default 25
-        help
-          On PA-RISC, the default value is 64, which should fit a 1280x1024
-          monitor.
-          Select 25 if you use a 640x480 resolution by default.
-
 config FRAMEBUFFER_CONSOLE
        bool "Framebuffer Console support"
        depends on FB && !UML

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

An even simpler approach would be:

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index cbe1d978693a..35b7aba4b6a0 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -952,6 +952,10 @@ config S390_HYPFS_FS
 
 source "arch/s390/kvm/Kconfig"
 
+config DUMMY_CONSOLE
+       bool
+       default y
+
 config S390_GUEST
        def_bool y
        prompt "s390 support for virtio devices"

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

An even simpler approach would be:

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index cbe1d978693a..35b7aba4b6a0 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -952,6 +952,10 @@ config S390_HYPFS_FS
 
 source "arch/s390/kvm/Kconfig"
 
+config DUMMY_CONSOLE
+       bool
+       default y
+
 config S390_GUEST
        def_bool y
        prompt "s390 support for virtio devices"

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

An even simpler approach would be:

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index cbe1d978693a..35b7aba4b6a0 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -952,6 +952,10 @@ config S390_HYPFS_FS
 
 source "arch/s390/kvm/Kconfig"
 
+config DUMMY_CONSOLE
+       bool
+       default y
+
 config S390_GUEST
        def_bool y
        prompt "s390 support for virtio devices"

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] s390/console: enable dummy console for vt

[Christian Borntraeger]

To enable the virtual terminal layer with virtio-gpu, we need to
provide the dummy console. This console is hidden behind CONFIG_IOMEM
via the graphics support. Instead of fully enabling the graphic
drivers lets just provide a Kconfig option for the dummy console.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
New version: instead of moving around the graphic and console stuff,
let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
 arch/s390/Kconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index cbe1d978693a..a69690f616f3 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -952,6 +952,11 @@ config S390_HYPFS_FS
 
 source "arch/s390/kvm/Kconfig"
 
+config DUMMY_CONSOLE
+       bool
+       depends on VT
+       default y
+
 config S390_GUEST
 	def_bool y
 	prompt "s390 support for virtio devices"
-- 
2.14.3

Re: [PATCH] s390/console: enable dummy console for vt

[Geert Uytterhoeven]

Hi Christian,

On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
<borntraeger@de.ibm.com> wrote:
> To enable the virtual terminal layer with virtio-gpu, we need to
> provide the dummy console. This console is hidden behind CONFIG_IOMEM
> via the graphics support. Instead of fully enabling the graphic
> drivers lets just provide a Kconfig option for the dummy console.
>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> New version: instead of moving around the graphic and console stuff,
> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>  arch/s390/Kconfig | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index cbe1d978693a..a69690f616f3 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>
>  source "arch/s390/kvm/Kconfig"
>
> +config DUMMY_CONSOLE
> +       bool
> +       depends on VT
> +       default y
> +
>  config S390_GUEST
>         def_bool y
>         prompt "s390 support for virtio devices"

Really?

You already have your own copy of HAS_IOMEM, which makes it hard for
people to track which one applies where.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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] s390/console: enable dummy console for vt

[Geert Uytterhoeven]

Hi Christian,

On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
<borntraeger@de.ibm.com> wrote:
> To enable the virtual terminal layer with virtio-gpu, we need to
> provide the dummy console. This console is hidden behind CONFIG_IOMEM
> via the graphics support. Instead of fully enabling the graphic
> drivers lets just provide a Kconfig option for the dummy console.
>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> New version: instead of moving around the graphic and console stuff,
> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>  arch/s390/Kconfig | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index cbe1d978693a..a69690f616f3 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>
>  source "arch/s390/kvm/Kconfig"
>
> +config DUMMY_CONSOLE
> +       bool
> +       depends on VT
> +       default y
> +
>  config S390_GUEST
>         def_bool y
>         prompt "s390 support for virtio devices"

Really?

You already have your own copy of HAS_IOMEM, which makes it hard for
people to track which one applies where.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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] s390/console: enable dummy console for vt

[Geert Uytterhoeven]

Hi Christian,

On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
<borntraeger@de.ibm.com> wrote:
> To enable the virtual terminal layer with virtio-gpu, we need to
> provide the dummy console. This console is hidden behind CONFIG_IOMEM
> via the graphics support. Instead of fully enabling the graphic
> drivers lets just provide a Kconfig option for the dummy console.
>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> New version: instead of moving around the graphic and console stuff,
> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>  arch/s390/Kconfig | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index cbe1d978693a..a69690f616f3 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>
>  source "arch/s390/kvm/Kconfig"
>
> +config DUMMY_CONSOLE
> +       bool
> +       depends on VT
> +       default y
> +
>  config S390_GUEST
>         def_bool y
>         prompt "s390 support for virtio devices"

Really?

You already have your own copy of HAS_IOMEM, which makes it hard for
people to track which one applies where.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] s390/console: enable dummy console for vt

[Christian Borntraeger]

On 02/15/2018 12:26 PM, Geert Uytterhoeven wrote:
> Hi Christian,
> 
> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
> <borntraeger@de.ibm.com> wrote:
>> To enable the virtual terminal layer with virtio-gpu, we need to
>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>> via the graphics support. Instead of fully enabling the graphic
>> drivers lets just provide a Kconfig option for the dummy console.
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>> New version: instead of moving around the graphic and console stuff,
>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>  arch/s390/Kconfig | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>> index cbe1d978693a..a69690f616f3 100644
>> --- a/arch/s390/Kconfig
>> +++ b/arch/s390/Kconfig
>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>
>>  source "arch/s390/kvm/Kconfig"
>>
>> +config DUMMY_CONSOLE
>> +       bool
>> +       depends on VT
>> +       default y
>> +
>>  config S390_GUEST
>>         def_bool y
>>         prompt "s390 support for virtio devices"
> 
> Really?
> 
> You already have your own copy of HAS_IOMEM, which makes it hard for
> people to track which one applies where.
> 

I am open for better suggestions. One idea that I had was to reverse
the logic in s390 (and use the common code HAS_IOMEM)

like


diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index cbe1d978693a..123dd593ea20 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -715,8 +715,8 @@ endif       # PCI
 config PCI_DOMAINS
        def_bool PCI
 
-config HAS_IOMEM
-       def_bool PCI
+config NO_IOMEM
+       def_bool y if !PCI
 
 config IOMMU_HELPER
        def_bool PCI


This would enable CONFIG_VT and also CONFIG_DUMMY_CONSOLE as long as
PCI is enabled. If DUMMY_CONSOLE is not enabled (e.g. due to missing PCI),
we get a crash in the VT layer as conswitchp is then null.

Somewhat tricky.

Re: [PATCH] s390/console: enable dummy console for vt

[Christian Borntraeger]

On 02/15/2018 12:26 PM, Geert Uytterhoeven wrote:
> Hi Christian,
> 
> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
> <borntraeger@de.ibm.com> wrote:
>> To enable the virtual terminal layer with virtio-gpu, we need to
>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>> via the graphics support. Instead of fully enabling the graphic
>> drivers lets just provide a Kconfig option for the dummy console.
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>> New version: instead of moving around the graphic and console stuff,
>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>  arch/s390/Kconfig | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>> index cbe1d978693a..a69690f616f3 100644
>> --- a/arch/s390/Kconfig
>> +++ b/arch/s390/Kconfig
>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>
>>  source "arch/s390/kvm/Kconfig"
>>
>> +config DUMMY_CONSOLE
>> +       bool
>> +       depends on VT
>> +       default y
>> +
>>  config S390_GUEST
>>         def_bool y
>>         prompt "s390 support for virtio devices"
> 
> Really?
> 
> You already have your own copy of HAS_IOMEM, which makes it hard for
> people to track which one applies where.
> 

I am open for better suggestions. One idea that I had was to reverse
the logic in s390 (and use the common code HAS_IOMEM)

like


diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index cbe1d978693a..123dd593ea20 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -715,8 +715,8 @@ endif       # PCI
 config PCI_DOMAINS
        def_bool PCI
 
-config HAS_IOMEM
-       def_bool PCI
+config NO_IOMEM
+       def_bool y if !PCI
 
 config IOMMU_HELPER
        def_bool PCI


This would enable CONFIG_VT and also CONFIG_DUMMY_CONSOLE as long as
PCI is enabled. If DUMMY_CONSOLE is not enabled (e.g. due to missing PCI),
we get a crash in the VT layer as conswitchp is then null.

Somewhat tricky.

Re: [PATCH] s390/console: enable dummy console for vt

[Thomas Huth]

On 15.02.2018 12:26, Geert Uytterhoeven wrote:
> Hi Christian,
> 
> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
> <borntraeger@de.ibm.com> wrote:
>> To enable the virtual terminal layer with virtio-gpu, we need to
>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>> via the graphics support. Instead of fully enabling the graphic
>> drivers lets just provide a Kconfig option for the dummy console.
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>> New version: instead of moving around the graphic and console stuff,
>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>  arch/s390/Kconfig | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>> index cbe1d978693a..a69690f616f3 100644
>> --- a/arch/s390/Kconfig
>> +++ b/arch/s390/Kconfig
>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>
>>  source "arch/s390/kvm/Kconfig"
>>
>> +config DUMMY_CONSOLE
>> +       bool
>> +       depends on VT
>> +       default y
>> +
>>  config S390_GUEST
>>         def_bool y
>>         prompt "s390 support for virtio devices"
> 
> Really?
> 
> You already have your own copy of HAS_IOMEM, which makes it hard for
> people to track which one applies where.

I think I agree with Geert - let's better fix this in a proper way
instead of doing hacks like this. I guess there will be other
architectures in the future that might want to use the dummy console
without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
better to me.

 Thomas

Re: [PATCH] s390/console: enable dummy console for vt

[Thomas Huth]

On 15.02.2018 12:26, Geert Uytterhoeven wrote:
> Hi Christian,
> 
> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
> <borntraeger@de.ibm.com> wrote:
>> To enable the virtual terminal layer with virtio-gpu, we need to
>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>> via the graphics support. Instead of fully enabling the graphic
>> drivers lets just provide a Kconfig option for the dummy console.
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>> New version: instead of moving around the graphic and console stuff,
>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>  arch/s390/Kconfig | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>> index cbe1d978693a..a69690f616f3 100644
>> --- a/arch/s390/Kconfig
>> +++ b/arch/s390/Kconfig
>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>
>>  source "arch/s390/kvm/Kconfig"
>>
>> +config DUMMY_CONSOLE
>> +       bool
>> +       depends on VT
>> +       default y
>> +
>>  config S390_GUEST
>>         def_bool y
>>         prompt "s390 support for virtio devices"
> 
> Really?
> 
> You already have your own copy of HAS_IOMEM, which makes it hard for
> people to track which one applies where.

I think I agree with Geert - let's better fix this in a proper way
instead of doing hacks like this. I guess there will be other
architectures in the future that might want to use the dummy console
without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
better to me.

 Thomas

Re: [PATCH] s390/console: enable dummy console for vt

[Thomas Huth]

On 15.02.2018 12:26, Geert Uytterhoeven wrote:
> Hi Christian,
> 
> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
> <borntraeger@de.ibm.com> wrote:
>> To enable the virtual terminal layer with virtio-gpu, we need to
>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>> via the graphics support. Instead of fully enabling the graphic
>> drivers lets just provide a Kconfig option for the dummy console.
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>> New version: instead of moving around the graphic and console stuff,
>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>  arch/s390/Kconfig | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>> index cbe1d978693a..a69690f616f3 100644
>> --- a/arch/s390/Kconfig
>> +++ b/arch/s390/Kconfig
>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>
>>  source "arch/s390/kvm/Kconfig"
>>
>> +config DUMMY_CONSOLE
>> +       bool
>> +       depends on VT
>> +       default y
>> +
>>  config S390_GUEST
>>         def_bool y
>>         prompt "s390 support for virtio devices"
> 
> Really?
> 
> You already have your own copy of HAS_IOMEM, which makes it hard for
> people to track which one applies where.

I think I agree with Geert - let's better fix this in a proper way
instead of doing hacks like this. I guess there will be other
architectures in the future that might want to use the dummy console
without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
better to me.

 Thomas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] s390/console: enable dummy console for vt

[Christian Borntraeger]

On 02/15/2018 12:57 PM, Thomas Huth wrote:
> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>> Hi Christian,
>>
>> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>> <borntraeger@de.ibm.com> wrote:
>>> To enable the virtual terminal layer with virtio-gpu, we need to
>>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>>> via the graphics support. Instead of fully enabling the graphic
>>> drivers lets just provide a Kconfig option for the dummy console.
>>>
>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>> ---
>>> New version: instead of moving around the graphic and console stuff,
>>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>>  arch/s390/Kconfig | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>>> index cbe1d978693a..a69690f616f3 100644
>>> --- a/arch/s390/Kconfig
>>> +++ b/arch/s390/Kconfig
>>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>>
>>>  source "arch/s390/kvm/Kconfig"
>>>
>>> +config DUMMY_CONSOLE
>>> +       bool
>>> +       depends on VT
>>> +       default y
>>> +
>>>  config S390_GUEST
>>>         def_bool y
>>>         prompt "s390 support for virtio devices"
>>
>> Really?
>>
>> You already have your own copy of HAS_IOMEM, which makes it hard for
>> people to track which one applies where.
> 
> I think I agree with Geert - let's better fix this in a proper way
> instead of doing hacks like this. I guess there will be other
> architectures in the future that might want to use the dummy console
> without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
> better to me.

The question is, what is the proper fix?

Re: [PATCH] s390/console: enable dummy console for vt

[Christian Borntraeger]

On 02/15/2018 12:57 PM, Thomas Huth wrote:
> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>> Hi Christian,
>>
>> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>> <borntraeger@de.ibm.com> wrote:
>>> To enable the virtual terminal layer with virtio-gpu, we need to
>>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>>> via the graphics support. Instead of fully enabling the graphic
>>> drivers lets just provide a Kconfig option for the dummy console.
>>>
>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>> ---
>>> New version: instead of moving around the graphic and console stuff,
>>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>>  arch/s390/Kconfig | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>>> index cbe1d978693a..a69690f616f3 100644
>>> --- a/arch/s390/Kconfig
>>> +++ b/arch/s390/Kconfig
>>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>>
>>>  source "arch/s390/kvm/Kconfig"
>>>
>>> +config DUMMY_CONSOLE
>>> +       bool
>>> +       depends on VT
>>> +       default y
>>> +
>>>  config S390_GUEST
>>>         def_bool y
>>>         prompt "s390 support for virtio devices"
>>
>> Really?
>>
>> You already have your own copy of HAS_IOMEM, which makes it hard for
>> people to track which one applies where.
> 
> I think I agree with Geert - let's better fix this in a proper way
> instead of doing hacks like this. I guess there will be other
> architectures in the future that might want to use the dummy console
> without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
> better to me.

The question is, what is the proper fix?

Re: [PATCH] s390/console: enable dummy console for vt

[Christian Borntraeger]

On 02/15/2018 12:57 PM, Thomas Huth wrote:
> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>> Hi Christian,
>>
>> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>> <borntraeger@de.ibm.com> wrote:
>>> To enable the virtual terminal layer with virtio-gpu, we need to
>>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>>> via the graphics support. Instead of fully enabling the graphic
>>> drivers lets just provide a Kconfig option for the dummy console.
>>>
>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>> ---
>>> New version: instead of moving around the graphic and console stuff,
>>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>>  arch/s390/Kconfig | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>>> index cbe1d978693a..a69690f616f3 100644
>>> --- a/arch/s390/Kconfig
>>> +++ b/arch/s390/Kconfig
>>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>>
>>>  source "arch/s390/kvm/Kconfig"
>>>
>>> +config DUMMY_CONSOLE
>>> +       bool
>>> +       depends on VT
>>> +       default y
>>> +
>>>  config S390_GUEST
>>>         def_bool y
>>>         prompt "s390 support for virtio devices"
>>
>> Really?
>>
>> You already have your own copy of HAS_IOMEM, which makes it hard for
>> people to track which one applies where.
> 
> I think I agree with Geert - let's better fix this in a proper way
> instead of doing hacks like this. I guess there will be other
> architectures in the future that might want to use the dummy console
> without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
> better to me.

The question is, what is the proper fix?

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] s390/console: enable dummy console for vt

[Farhan Ali]

On 02/15/2018 07:02 AM, Christian Borntraeger wrote:
> 
> 
> On 02/15/2018 12:57 PM, Thomas Huth wrote:
>> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>>> Hi Christian,
>>>
>>> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>>> <borntraeger@de.ibm.com> wrote:
>>>> To enable the virtual terminal layer with virtio-gpu, we need to
>>>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>>>> via the graphics support. Instead of fully enabling the graphic
>>>> drivers lets just provide a Kconfig option for the dummy console.
>>>>
>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>>> ---
>>>> New version: instead of moving around the graphic and console stuff,
>>>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>>>   arch/s390/Kconfig | 5 +++++
>>>>   1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>>>> index cbe1d978693a..a69690f616f3 100644
>>>> --- a/arch/s390/Kconfig
>>>> +++ b/arch/s390/Kconfig
>>>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>>>
>>>>   source "arch/s390/kvm/Kconfig"
>>>>
>>>> +config DUMMY_CONSOLE
>>>> +       bool
>>>> +       depends on VT
>>>> +       default y
>>>> +
>>>>   config S390_GUEST
>>>>          def_bool y
>>>>          prompt "s390 support for virtio devices"
>>>
>>> Really?
>>>
>>> You already have your own copy of HAS_IOMEM, which makes it hard for
>>> people to track which one applies where.
>>
>> I think I agree with Geert - let's better fix this in a proper way
>> instead of doing hacks like this. I guess there will be other
>> architectures in the future that might want to use the dummy console
>> without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
>> better to me.
> 
> The question is, what is the proper fix?
> 

How about we only fence off sub menu items such as DRM or GPU or Fbdev, 
which actually uses io memory, in drivers/video/Kconfig? Similar to what 
Thomas suggested for moving the CONFIG_IOMEM dependency for fbdevs?

Re: [PATCH] s390/console: enable dummy console for vt

[Farhan Ali]

On 02/15/2018 07:02 AM, Christian Borntraeger wrote:
> 
> 
> On 02/15/2018 12:57 PM, Thomas Huth wrote:
>> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>>> Hi Christian,
>>>
>>> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>>> <borntraeger@de.ibm.com> wrote:
>>>> To enable the virtual terminal layer with virtio-gpu, we need to
>>>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>>>> via the graphics support. Instead of fully enabling the graphic
>>>> drivers lets just provide a Kconfig option for the dummy console.
>>>>
>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>>> ---
>>>> New version: instead of moving around the graphic and console stuff,
>>>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>>>   arch/s390/Kconfig | 5 +++++
>>>>   1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>>>> index cbe1d978693a..a69690f616f3 100644
>>>> --- a/arch/s390/Kconfig
>>>> +++ b/arch/s390/Kconfig
>>>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>>>
>>>>   source "arch/s390/kvm/Kconfig"
>>>>
>>>> +config DUMMY_CONSOLE
>>>> +       bool
>>>> +       depends on VT
>>>> +       default y
>>>> +
>>>>   config S390_GUEST
>>>>          def_bool y
>>>>          prompt "s390 support for virtio devices"
>>>
>>> Really?
>>>
>>> You already have your own copy of HAS_IOMEM, which makes it hard for
>>> people to track which one applies where.
>>
>> I think I agree with Geert - let's better fix this in a proper way
>> instead of doing hacks like this. I guess there will be other
>> architectures in the future that might want to use the dummy console
>> without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
>> better to me.
> 
> The question is, what is the proper fix?
> 

How about we only fence off sub menu items such as DRM or GPU or Fbdev, 
which actually uses io memory, in drivers/video/Kconfig? Similar to what 
Thomas suggested for moving the CONFIG_IOMEM dependency for fbdevs?

Re: [PATCH] s390/console: enable dummy console for vt

[Farhan Ali]

On 02/15/2018 07:02 AM, Christian Borntraeger wrote:
> 
> 
> On 02/15/2018 12:57 PM, Thomas Huth wrote:
>> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>>> Hi Christian,
>>>
>>> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>>> <borntraeger@de.ibm.com> wrote:
>>>> To enable the virtual terminal layer with virtio-gpu, we need to
>>>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>>>> via the graphics support. Instead of fully enabling the graphic
>>>> drivers lets just provide a Kconfig option for the dummy console.
>>>>
>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>>> ---
>>>> New version: instead of moving around the graphic and console stuff,
>>>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>>>   arch/s390/Kconfig | 5 +++++
>>>>   1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>>>> index cbe1d978693a..a69690f616f3 100644
>>>> --- a/arch/s390/Kconfig
>>>> +++ b/arch/s390/Kconfig
>>>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>>>
>>>>   source "arch/s390/kvm/Kconfig"
>>>>
>>>> +config DUMMY_CONSOLE
>>>> +       bool
>>>> +       depends on VT
>>>> +       default y
>>>> +
>>>>   config S390_GUEST
>>>>          def_bool y
>>>>          prompt "s390 support for virtio devices"
>>>
>>> Really?
>>>
>>> You already have your own copy of HAS_IOMEM, which makes it hard for
>>> people to track which one applies where.
>>
>> I think I agree with Geert - let's better fix this in a proper way
>> instead of doing hacks like this. I guess there will be other
>> architectures in the future that might want to use the dummy console
>> without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
>> better to me.
> 
> The question is, what is the proper fix?
> 

How about we only fence off sub menu items such as DRM or GPU or Fbdev, 
which actually uses io memory, in drivers/video/Kconfig? Similar to what 
Thomas suggested for moving the CONFIG_IOMEM dependency for fbdevs?

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] s390/console: enable dummy console for vt

[Christian Borntraeger]

On 02/19/2018 02:35 PM, Farhan Ali wrote:
> 
> 
> On 02/15/2018 07:02 AM, Christian Borntraeger wrote:
>>
>>
>> On 02/15/2018 12:57 PM, Thomas Huth wrote:
>>> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>>>> Hi Christian,
>>>>
>>>> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>>>> <borntraeger@de.ibm.com> wrote:
>>>>> To enable the virtual terminal layer with virtio-gpu, we need to
>>>>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>>>>> via the graphics support. Instead of fully enabling the graphic
>>>>> drivers lets just provide a Kconfig option for the dummy console.
>>>>>
>>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>>>> ---
>>>>> New version: instead of moving around the graphic and console stuff,
>>>>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>>>>   arch/s390/Kconfig | 5 +++++
>>>>>   1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>>>>> index cbe1d978693a..a69690f616f3 100644
>>>>> --- a/arch/s390/Kconfig
>>>>> +++ b/arch/s390/Kconfig
>>>>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>>>>
>>>>>   source "arch/s390/kvm/Kconfig"
>>>>>
>>>>> +config DUMMY_CONSOLE
>>>>> +       bool
>>>>> +       depends on VT
>>>>> +       default y
>>>>> +
>>>>>   config S390_GUEST
>>>>>          def_bool y
>>>>>          prompt "s390 support for virtio devices"
>>>>
>>>> Really?
>>>>
>>>> You already have your own copy of HAS_IOMEM, which makes it hard for
>>>> people to track which one applies where.
>>>
>>> I think I agree with Geert - let's better fix this in a proper way
>>> instead of doing hacks like this. I guess there will be other
>>> architectures in the future that might want to use the dummy console
>>> without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
>>> better to me.
>>
>> The question is, what is the proper fix?
>>
> 
> How about we only fence off sub menu items such as DRM or GPU or Fbdev, which actually uses io memory, in drivers/video/Kconfig? Similar to what Thomas suggested for moving the CONFIG_IOMEM dependency for fbdevs?

Can you spin a patch?

Re: [PATCH] s390/console: enable dummy console for vt

[Christian Borntraeger]

On 02/19/2018 02:35 PM, Farhan Ali wrote:
> 
> 
> On 02/15/2018 07:02 AM, Christian Borntraeger wrote:
>>
>>
>> On 02/15/2018 12:57 PM, Thomas Huth wrote:
>>> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>>>> Hi Christian,
>>>>
>>>> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>>>> <borntraeger@de.ibm.com> wrote:
>>>>> To enable the virtual terminal layer with virtio-gpu, we need to
>>>>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>>>>> via the graphics support. Instead of fully enabling the graphic
>>>>> drivers lets just provide a Kconfig option for the dummy console.
>>>>>
>>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>>>> ---
>>>>> New version: instead of moving around the graphic and console stuff,
>>>>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>>>>   arch/s390/Kconfig | 5 +++++
>>>>>   1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>>>>> index cbe1d978693a..a69690f616f3 100644
>>>>> --- a/arch/s390/Kconfig
>>>>> +++ b/arch/s390/Kconfig
>>>>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>>>>
>>>>>   source "arch/s390/kvm/Kconfig"
>>>>>
>>>>> +config DUMMY_CONSOLE
>>>>> +       bool
>>>>> +       depends on VT
>>>>> +       default y
>>>>> +
>>>>>   config S390_GUEST
>>>>>          def_bool y
>>>>>          prompt "s390 support for virtio devices"
>>>>
>>>> Really?
>>>>
>>>> You already have your own copy of HAS_IOMEM, which makes it hard for
>>>> people to track which one applies where.
>>>
>>> I think I agree with Geert - let's better fix this in a proper way
>>> instead of doing hacks like this. I guess there will be other
>>> architectures in the future that might want to use the dummy console
>>> without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
>>> better to me.
>>
>> The question is, what is the proper fix?
>>
> 
> How about we only fence off sub menu items such as DRM or GPU or Fbdev, which actually uses io memory, in drivers/video/Kconfig? Similar to what Thomas suggested for moving the CONFIG_IOMEM dependency for fbdevs?

Can you spin a patch?

Re: [PATCH] s390/console: enable dummy console for vt

[Christian Borntraeger]

On 02/19/2018 02:35 PM, Farhan Ali wrote:
> 
> 
> On 02/15/2018 07:02 AM, Christian Borntraeger wrote:
>>
>>
>> On 02/15/2018 12:57 PM, Thomas Huth wrote:
>>> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>>>> Hi Christian,
>>>>
>>>> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>>>> <borntraeger@de.ibm.com> wrote:
>>>>> To enable the virtual terminal layer with virtio-gpu, we need to
>>>>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>>>>> via the graphics support. Instead of fully enabling the graphic
>>>>> drivers lets just provide a Kconfig option for the dummy console.
>>>>>
>>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>>>> ---
>>>>> New version: instead of moving around the graphic and console stuff,
>>>>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>>>>   arch/s390/Kconfig | 5 +++++
>>>>>   1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>>>>> index cbe1d978693a..a69690f616f3 100644
>>>>> --- a/arch/s390/Kconfig
>>>>> +++ b/arch/s390/Kconfig
>>>>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>>>>
>>>>>   source "arch/s390/kvm/Kconfig"
>>>>>
>>>>> +config DUMMY_CONSOLE
>>>>> +       bool
>>>>> +       depends on VT
>>>>> +       default y
>>>>> +
>>>>>   config S390_GUEST
>>>>>          def_bool y
>>>>>          prompt "s390 support for virtio devices"
>>>>
>>>> Really?
>>>>
>>>> You already have your own copy of HAS_IOMEM, which makes it hard for
>>>> people to track which one applies where.
>>>
>>> I think I agree with Geert - let's better fix this in a proper way
>>> instead of doing hacks like this. I guess there will be other
>>> architectures in the future that might want to use the dummy console
>>> without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
>>> better to me.
>>
>> The question is, what is the proper fix?
>>
> 
> How about we only fence off sub menu items such as DRM or GPU or Fbdev, which actually uses io memory, in drivers/video/Kconfig? Similar to what Thomas suggested for moving the CONFIG_IOMEM dependency for fbdevs?

Can you spin a patch?

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] s390/console: enable dummy console for vt

[Farhan Ali]

On 02/19/2018 08:37 AM, Christian Borntraeger wrote:
> 
> 
> On 02/19/2018 02:35 PM, Farhan Ali wrote:
>>
>>
>> On 02/15/2018 07:02 AM, Christian Borntraeger wrote:
>>>
>>>
>>> On 02/15/2018 12:57 PM, Thomas Huth wrote:
>>>> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>>>>> Hi Christian,
>>>>>
>>>>> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>>>>> <borntraeger@de.ibm.com> wrote:
>>>>>> To enable the virtual terminal layer with virtio-gpu, we need to
>>>>>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>>>>>> via the graphics support. Instead of fully enabling the graphic
>>>>>> drivers lets just provide a Kconfig option for the dummy console.
>>>>>>
>>>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>>>>> ---
>>>>>> New version: instead of moving around the graphic and console stuff,
>>>>>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>>>>>    arch/s390/Kconfig | 5 +++++
>>>>>>    1 file changed, 5 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>>>>>> index cbe1d978693a..a69690f616f3 100644
>>>>>> --- a/arch/s390/Kconfig
>>>>>> +++ b/arch/s390/Kconfig
>>>>>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>>>>>
>>>>>>    source "arch/s390/kvm/Kconfig"
>>>>>>
>>>>>> +config DUMMY_CONSOLE
>>>>>> +       bool
>>>>>> +       depends on VT
>>>>>> +       default y
>>>>>> +
>>>>>>    config S390_GUEST
>>>>>>           def_bool y
>>>>>>           prompt "s390 support for virtio devices"
>>>>>
>>>>> Really?
>>>>>
>>>>> You already have your own copy of HAS_IOMEM, which makes it hard for
>>>>> people to track which one applies where.
>>>>
>>>> I think I agree with Geert - let's better fix this in a proper way
>>>> instead of doing hacks like this. I guess there will be other
>>>> architectures in the future that might want to use the dummy console
>>>> without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
>>>> better to me.
>>>
>>> The question is, what is the proper fix?
>>>
>>
>> How about we only fence off sub menu items such as DRM or GPU or Fbdev, which actually uses io memory, in drivers/video/Kconfig? Similar to what Thomas suggested for moving the CONFIG_IOMEM dependency for fbdevs?
> 
> Can you spin a patch?
> 
Yes, I will post it as V3.

Re: [PATCH] s390/console: enable dummy console for vt

[Farhan Ali]

On 02/19/2018 08:37 AM, Christian Borntraeger wrote:
> 
> 
> On 02/19/2018 02:35 PM, Farhan Ali wrote:
>>
>>
>> On 02/15/2018 07:02 AM, Christian Borntraeger wrote:
>>>
>>>
>>> On 02/15/2018 12:57 PM, Thomas Huth wrote:
>>>> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>>>>> Hi Christian,
>>>>>
>>>>> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>>>>> <borntraeger@de.ibm.com> wrote:
>>>>>> To enable the virtual terminal layer with virtio-gpu, we need to
>>>>>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>>>>>> via the graphics support. Instead of fully enabling the graphic
>>>>>> drivers lets just provide a Kconfig option for the dummy console.
>>>>>>
>>>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>>>>> ---
>>>>>> New version: instead of moving around the graphic and console stuff,
>>>>>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>>>>>    arch/s390/Kconfig | 5 +++++
>>>>>>    1 file changed, 5 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>>>>>> index cbe1d978693a..a69690f616f3 100644
>>>>>> --- a/arch/s390/Kconfig
>>>>>> +++ b/arch/s390/Kconfig
>>>>>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>>>>>
>>>>>>    source "arch/s390/kvm/Kconfig"
>>>>>>
>>>>>> +config DUMMY_CONSOLE
>>>>>> +       bool
>>>>>> +       depends on VT
>>>>>> +       default y
>>>>>> +
>>>>>>    config S390_GUEST
>>>>>>           def_bool y
>>>>>>           prompt "s390 support for virtio devices"
>>>>>
>>>>> Really?
>>>>>
>>>>> You already have your own copy of HAS_IOMEM, which makes it hard for
>>>>> people to track which one applies where.
>>>>
>>>> I think I agree with Geert - let's better fix this in a proper way
>>>> instead of doing hacks like this. I guess there will be other
>>>> architectures in the future that might want to use the dummy console
>>>> without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
>>>> better to me.
>>>
>>> The question is, what is the proper fix?
>>>
>>
>> How about we only fence off sub menu items such as DRM or GPU or Fbdev, which actually uses io memory, in drivers/video/Kconfig? Similar to what Thomas suggested for moving the CONFIG_IOMEM dependency for fbdevs?
> 
> Can you spin a patch?
> 
Yes, I will post it as V3.

Re: [PATCH] s390/console: enable dummy console for vt

[Farhan Ali]

On 02/19/2018 08:37 AM, Christian Borntraeger wrote:
> 
> 
> On 02/19/2018 02:35 PM, Farhan Ali wrote:
>>
>>
>> On 02/15/2018 07:02 AM, Christian Borntraeger wrote:
>>>
>>>
>>> On 02/15/2018 12:57 PM, Thomas Huth wrote:
>>>> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>>>>> Hi Christian,
>>>>>
>>>>> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>>>>> <borntraeger@de.ibm.com> wrote:
>>>>>> To enable the virtual terminal layer with virtio-gpu, we need to
>>>>>> provide the dummy console. This console is hidden behind CONFIG_IOMEM
>>>>>> via the graphics support. Instead of fully enabling the graphic
>>>>>> drivers lets just provide a Kconfig option for the dummy console.
>>>>>>
>>>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>>>>> ---
>>>>>> New version: instead of moving around the graphic and console stuff,
>>>>>> let's just keep an s390 specific variant of CONFIG_DUMMY_CONSOLE
>>>>>>    arch/s390/Kconfig | 5 +++++
>>>>>>    1 file changed, 5 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>>>>>> index cbe1d978693a..a69690f616f3 100644
>>>>>> --- a/arch/s390/Kconfig
>>>>>> +++ b/arch/s390/Kconfig
>>>>>> @@ -952,6 +952,11 @@ config S390_HYPFS_FS
>>>>>>
>>>>>>    source "arch/s390/kvm/Kconfig"
>>>>>>
>>>>>> +config DUMMY_CONSOLE
>>>>>> +       bool
>>>>>> +       depends on VT
>>>>>> +       default y
>>>>>> +
>>>>>>    config S390_GUEST
>>>>>>           def_bool y
>>>>>>           prompt "s390 support for virtio devices"
>>>>>
>>>>> Really?
>>>>>
>>>>> You already have your own copy of HAS_IOMEM, which makes it hard for
>>>>> people to track which one applies where.
>>>>
>>>> I think I agree with Geert - let's better fix this in a proper way
>>>> instead of doing hacks like this. I guess there will be other
>>>> architectures in the future that might want to use the dummy console
>>>> without CONFIG_IOMEM, so fixing this in drivers/video/ instead sounds
>>>> better to me.
>>>
>>> The question is, what is the proper fix?
>>>
>>
>> How about we only fence off sub menu items such as DRM or GPU or Fbdev, which actually uses io memory, in drivers/video/Kconfig? Similar to what Thomas suggested for moving the CONFIG_IOMEM dependency for fbdevs?
> 
> Can you spin a patch?
> 
Yes, I will post it as V3.

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel