From: Farhan Ali <hidden> Date: 2018-01-25 15:47:54
Hi,
This series of patches are in preparation for enabling an additional
tty and console for a S390 KVM guest using a virtio-gpu device[1].
One of the steps to do this would be to enable CONFIG_VT for S390,
and this would also require the dummy console (CONFIG_DUMMY_CONSOLE).
Patch 1 enables the "Graphics support" menu which is
needed to enable dummy console, since the VT layer needs it.
Patch 2 fixes a Kconfig dependency issue for opencores
framebuffer devices. This issue was exposed by the previous
patch.
Thanks
Farhan
[1] https://lists.nongnu.org/archive/html/qemu-devel/2017-09/msg04184.html
Farhan Ali (2):
Kconfig : Remove HAS_IOMEM dependency for Graphics support
fbdev: Kconfig: Add HAS_IOMEM dependency for FB_OPENCORES
drivers/video/Kconfig | 1 -
drivers/video/fbdev/Kconfig | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
--
2.7.4
From: Farhan Ali <hidden> Date: 2018-01-25 15:47:48
The Opencores framebuffer device uses I/O memory and with
CONFIG_HAS_IOMEM disabled will lead to build errors:
ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
Fix this by adding HAS_IOMEM dependency for FB_OPENCORES.
Signed-off-by: Farhan Ali <redacted>
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Farhan Ali <hidden> Date: 2018-01-25 15:48:14
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.
Signed-off-by: Farhan Ali <redacted>
Tested-by: Dong Jia Shi <redacted>
---
drivers/video/Kconfig | 1 -
1 file changed, 1 deletion(-)
From: Thomas Huth <hidden> Date: 2018-01-26 12:31:32
On 25.01.2018 16:47, Farhan Ali wrote:
quoted hunk
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.
Signed-off-by: Farhan Ali <redacted>
Tested-by: Dong Jia Shi <redacted>
---
drivers/video/Kconfig | 1 -
1 file changed, 1 deletion(-)
From: Thomas Huth <hidden> Date: 2018-01-26 12:33:59
On 25.01.2018 16:47, Farhan Ali wrote:
quoted hunk
The Opencores framebuffer device uses I/O memory and with
CONFIG_HAS_IOMEM disabled will lead to build errors:
ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
Fix this by adding HAS_IOMEM dependency for FB_OPENCORES.
Signed-off-by: Farhan Ali <redacted>
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Tomi Valkeinen <hidden> Date: 2018-01-26 12:38:46
On 26/01/18 14:33, Thomas Huth wrote:
On 25.01.2018 16:47, Farhan Ali wrote:
quoted
The Opencores framebuffer device uses I/O memory and with
CONFIG_HAS_IOMEM disabled will lead to build errors:
ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
Fix this by adding HAS_IOMEM dependency for FB_OPENCORES.
Signed-off-by: Farhan Ali <redacted>
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
I think it would be better if fbdevs in general would depend on
HAS_IOMEM ... or could there be any frame buffer devices without IOMEM ?
There are some small ones which are updated with, say, i2c
(ssd1307fb.c). I think those don't need iomem.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Hi Farhan,
On Thu, Jan 25, 2018 at 4:47 PM, Farhan Ali [off-list ref] wrote:
This series of patches are in preparation for enabling an additional
tty and console for a S390 KVM guest using a virtio-gpu device[1].
One of the steps to do this would be to enable CONFIG_VT for S390,
and this would also require the dummy console (CONFIG_DUMMY_CONSOLE).
Patch 1 enables the "Graphics support" menu which is
needed to enable dummy console, since the VT layer needs it.
Patch 2 fixes a Kconfig dependency issue for opencores
framebuffer devices. This issue was exposed by the previous
patch.
Thanks
Farhan
[1] https://lists.nongnu.org/archive/html/qemu-devel/2017-09/msg04184.html
Farhan Ali (2):
Kconfig : Remove HAS_IOMEM dependency for Graphics support
fbdev: Kconfig: Add HAS_IOMEM dependency for FB_OPENCORES
drivers/video/Kconfig | 1 -
drivers/video/fbdev/Kconfig | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
Shouldn't the order of your two patches be inverted, to avoid patch 1
introducing
build breakage fixed by patch 2?
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
From: Farhan Ali <hidden> Date: 2018-01-26 14:32:22
On 01/26/2018 07:38 AM, Tomi Valkeinen wrote:
On 26/01/18 14:33, Thomas Huth wrote:
quoted
On 25.01.2018 16:47, Farhan Ali wrote:
quoted
The Opencores framebuffer device uses I/O memory and with
CONFIG_HAS_IOMEM disabled will lead to build errors:
ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
Fix this by adding HAS_IOMEM dependency for FB_OPENCORES.
Signed-off-by: Farhan Ali <redacted>
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
I think it would be better if fbdevs in general would depend on
HAS_IOMEM ... or could there be any frame buffer devices without IOMEM ?
There are some small ones which are updated with, say, i2c
(ssd1307fb.c). I think those don't need iomem.
Tomi
Most of the other framebuffer devices are fenced of by architecture
dependency or PCI dependency. So I am hesitant to introduce a blanket
dependency for all fbdevs.
Thank you guys for reviewing!
Thanks
Farhan
From: Farhan Ali <hidden> Date: 2018-01-26 14:35:46
On 01/26/2018 08:41 AM, Geert Uytterhoeven wrote:
Hi Farhan,
On Thu, Jan 25, 2018 at 4:47 PM, Farhan Ali [off-list ref] wrote:
quoted
This series of patches are in preparation for enabling an additional
tty and console for a S390 KVM guest using a virtio-gpu device[1].
One of the steps to do this would be to enable CONFIG_VT for S390,
and this would also require the dummy console (CONFIG_DUMMY_CONSOLE).
Patch 1 enables the "Graphics support" menu which is
needed to enable dummy console, since the VT layer needs it.
Patch 2 fixes a Kconfig dependency issue for opencores
framebuffer devices. This issue was exposed by the previous
patch.
Thanks
Farhan
[1] https://lists.nongnu.org/archive/html/qemu-devel/2017-09/msg04184.html
Farhan Ali (2):
Kconfig : Remove HAS_IOMEM dependency for Graphics support
fbdev: Kconfig: Add HAS_IOMEM dependency for FB_OPENCORES
drivers/video/Kconfig | 1 -
drivers/video/fbdev/Kconfig | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
Shouldn't the order of your two patches be inverted, to avoid patch 1
introducing
build breakage fixed by patch 2?
Gr{oetje,eeting}s,
Geert
Hi Geert,
I wasn't sure what would be the best ordering since we would never hit
the issue if patch 1 didn't exist. But if the preference is to invert
the ordering of patches, then I will change the ordering.
Thank you for reviewing.
Thanks
Farhan
--
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
Hi Farhan,
On Fri, Jan 26, 2018 at 3:35 PM, Farhan Ali [off-list ref] wrote:
On 01/26/2018 08:41 AM, Geert Uytterhoeven wrote:
quoted
On Thu, Jan 25, 2018 at 4:47 PM, Farhan Ali [off-list ref]
wrote:
quoted
This series of patches are in preparation for enabling an additional
tty and console for a S390 KVM guest using a virtio-gpu device[1].
One of the steps to do this would be to enable CONFIG_VT for S390,
and this would also require the dummy console (CONFIG_DUMMY_CONSOLE).
Patch 1 enables the "Graphics support" menu which is
needed to enable dummy console, since the VT layer needs it.
Patch 2 fixes a Kconfig dependency issue for opencores
framebuffer devices. This issue was exposed by the previous
patch.
Thanks
Farhan
[1]
https://lists.nongnu.org/archive/html/qemu-devel/2017-09/msg04184.html
Farhan Ali (2):
Kconfig : Remove HAS_IOMEM dependency for Graphics support
fbdev: Kconfig: Add HAS_IOMEM dependency for FB_OPENCORES
drivers/video/Kconfig | 1 -
drivers/video/fbdev/Kconfig | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
Shouldn't the order of your two patches be inverted, to avoid patch 1
introducing
build breakage fixed by patch 2?
Gr{oetje,eeting}s,
Geert
Hi Geert,
I wasn't sure what would be the best ordering since we would never hit the
issue if patch 1 didn't exist. But if the preference is to invert the
ordering of patches, then I will change the ordering.
Alternatively, you can combine two patches into a single patch, which
moves the dependency from the whole subsystem to the driver that needs
it (are there more?).
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
From: Farhan Ali <hidden> Date: 2018-01-26 16:26:59
On 01/26/2018 10:06 AM, Geert Uytterhoeven wrote:
quoted
Hi Geert,
I wasn't sure what would be the best ordering since we would never hit the
issue if patch 1 didn't exist. But if the preference is to invert the
ordering of patches, then I will change the ordering.
Alternatively, you can combine two patches into a single patch, which
moves the dependency from the whole subsystem to the driver that needs
it (are there more?).
Gr{oetje,eeting}s,
Geert
I like the idea of combining both patches into one.
There are other fbdev drivers that use iomem (found by grepping for
"devm_ioremap_resource"):
CONFIG_FB_S3C (s3c-fb.c)
CONFIG_FB_CLPS711X (clps711x-fb.c)
CONFIG_FB_JZ4740 (jz4740_fb.c)
CONFIG_FB_DA8XX (da8xx-fb.c)
CONFIG_FB_WM8505 (wm8505fb.c)
CONFIG_OMAP2_VRFB (omap2/omapfb/vrfb.c)
CONFIG_FB_OMAP2 (omap2/omapfb/dss/*
CONFIG_FB_MXS (mxsfb.c)
CONFIG_PXA3XX_GCU (pxa3xx-gcu.c)
CONFIG_FB_XILINX (xilinxfb.c)
All of these are already fenced off by architecture dependencies (which
I am assuming enables CONFIG_HAS_IOMEM by default). If we want to be
cautious I can add HAS_IOMEM dependency for all of them.
Thanks
Farhan
From: Christian Borntraeger <hidden> Date: 2018-01-30 13:22:48
Yes, merging sounds good.
Farhan, can you maybe resend t whole series together with your CONFIG_VT rework?
On 01/26/2018 05:26 PM, Farhan Ali wrote:
On 01/26/2018 10:06 AM, Geert Uytterhoeven wrote:
quoted
quoted
Hi Geert,
I wasn't sure what would be the best ordering since we would never hit the
issue if patch 1 didn't exist. But if the preference is to invert the
ordering of patches, then I will change the ordering.
Alternatively, you can combine two patches into a single patch, which
moves the dependency from the whole subsystem to the driver that needs
it (are there more?).
Gr{oetje,eeting}s,
Geert
I like the idea of combining both patches into one.
There are other fbdev drivers that use iomem (found by grepping for "devm_ioremap_resource"):
CONFIG_FB_S3C (s3c-fb.c)
CONFIG_FB_CLPS711X (clps711x-fb.c)
CONFIG_FB_JZ4740 (jz4740_fb.c)
CONFIG_FB_DA8XX (da8xx-fb.c)
CONFIG_FB_WM8505 (wm8505fb.c)
CONFIG_OMAP2_VRFB (omap2/omapfb/vrfb.c)
CONFIG_FB_OMAP2 (omap2/omapfb/dss/*
CONFIG_FB_MXS (mxsfb.c)
CONFIG_PXA3XX_GCU (pxa3xx-gcu.c)
CONFIG_FB_XILINX (xilinxfb.c)
All of these are already fenced off by architecture dependencies (which I am assuming enables CONFIG_HAS_IOMEM by default). If we want to be cautious I can add HAS_IOMEM dependency for all of them.
Thanks
Farhan