* [GIT PULL] fbdev changes for 3.12
From: Tomi Valkeinen @ 2013-09-05 6:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, linux-fbdev, Ingo Molnar,
Jean-Christophe PLAGNIOL-VILLARD
[-- Attachment #1: Type: text/plain, Size: 5166 bytes --]
Hi Linus,
Here are the fbdev changes for 3.12.
There's a conflict in drivers/video/simplefb.c, which you can resolve by using
the version in your tree.
I guess the simplefb changes were taken through Ingo's tree because the series
includes x86 arch changes, but it would have been nice to see the patches in
the linux-next...
Tomi
The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b:
Linux 3.11-rc2 (2013-07-21 12:05:29 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-3.12
for you to fetch changes up to 028cd86b794f4a7f09525587c8e9ab6b03a6fa0f:
video: da8xx-fb: fix the polarities of the hsync/vsync pulse (2013-08-30 14:51:30 +0300)
----------------------------------------------------------------
fbdev changes for 3.12:
* Improvements to da8xx-fb to make it support v2 of the LCDC IP, used e.g. in
BeagleBone
* Himax HX8369 controller support
* Various small fixes and cleanups
----------------------------------------------------------------
Afzal Mohammed (11):
video: da8xx-fb: fb_check_var enhancement
video: da8xx-fb: simplify lcd_reset
video: da8xx-fb: use modedb helper to update var
video: da8xx-fb: remove unneeded "var" initialization
video: da8xx-fb: store current display information
video: da8xx-fb: store clk rate even if !CPUFREQ
video: da8xx-fb: store struct device *
video: da8xx-fb: report correct pixclock
video: da8xx-fb: enable sync lost intr for v2 ip
video: da8xx-fb: ensure non-null cfg in pdata
video: da8xx-fb: reorganize panel detection
Alexandre Belloni (1):
fb: backlight: HX8357: Add HX8369 support
Alexandre Courbot (1):
simplefb: add support for a8b8g8r8 pixel format
Alexandru Juncu (1):
matroxfb: replace kmalloc and memset with kzalloc.
Boris BREZILLON (1):
at91/avr32/atmel_lcdfb: prepare clk before calling enable
Chen Gang (1):
drivers: video: fbcmap: remove the redundency and incorrect checkings
Daniel Mack (1):
fbmem: move EXPORT_SYMBOL annotation next to symbol declarations
Darren Etheridge (13):
video: da8xx-fb: pix clk and clk div handling cleanup
video: da8xx-fb: fb_set_par support
video: da8xx-fb: improve readability of code
video: da8xx-fb: fix 24bpp raster configuration
video: da8xx-fb: use devres
video: da8xx-fb: set upstream clock rate (if reqd)
video: da8xx-fb: make clock naming consistent
video: da8xx-fb: let compiler decide what to inline
video: da8xx-fb: adding am33xx as dependency
video: da8xx-fb fixing incorrect porch mappings
video: da8xx-fb: fixing timing off by one errors
video: da8xx-fb: support lcdc v2 timing register expansion
video: da8xx-fb: fix the polarities of the hsync/vsync pulse
Fabio Estevam (1):
video: mxsfb: Let device core handle pinctrl
Greg Kroah-Hartman (1):
video: output: convert class code to use dev_groups
Julia Lawall (2):
video: mxsfb: simplify use of devm_ioremap_resource
video: xilinxfb: replace devm_request_and_ioremap by devm_ioremap_resource
Mark Brown (1):
video: exynos: Ensure definitions match prototypes
Maxime Ripard (1):
video: hx8357: Make IM pins optional
Michael Opdenacker (1):
drivers/video: remove unused parameter in Kconfig
Mythri P K (1):
OMAPDSS: HDMI: Fix AVI infoframe bug
Peter Jones (1):
Release efifb's colormap in efifb_destroy()
Shingo Nakao (1):
backlight: lp855x: set zero brightness at FBBLANK
Tomi Valkeinen (3):
Merge branch '3.12/da8xx' into 3.12/fbdev
OMAPDSS: HDMI: Fix possible NULL reference
OMAPDSS: fix WARN_ON in 'alpha_blending_enabled' sysfs file
.../bindings/video/simple-framebuffer.txt | 1 +
drivers/video/Kconfig | 15 +-
drivers/video/atmel_lcdfb.c | 8 +-
drivers/video/backlight/hx8357.c | 269 ++++++++++++--
drivers/video/backlight/lp855x_bl.c | 2 +-
drivers/video/da8xx-fb.c | 387 ++++++++++++---------
drivers/video/efifb.c | 1 +
drivers/video/exynos/exynos_mipi_dsi_lowlevel.c | 1 +
drivers/video/fbcmap.c | 7 +-
drivers/video/fbmem.c | 29 +-
drivers/video/matrox/matroxfb_base.c | 3 +-
drivers/video/mxsfb.c | 15 +-
drivers/video/omap2/dss/hdmi.c | 5 +-
drivers/video/omap2/dss/manager-sysfs.c | 8 +-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 42 ++-
drivers/video/output.c | 20 +-
drivers/video/simplefb.c | 1 +
drivers/video/xilinxfb.c | 8 +-
include/video/da8xx-fb.h | 5 +
19 files changed, 542 insertions(+), 285 deletions(-)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [GIT PULL] OMAP fbdev changes for 3.12
From: Tomi Valkeinen @ 2013-09-05 6:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, linux-fbdev, linux-omap, Tony Lindgren,
Jean-Christophe PLAGNIOL-VILLARD
[-- Attachment #1: Type: text/plain, Size: 7593 bytes --]
Hi Linus,
Here are the OMAP specific fbdev changes for 3.12.
I've got this pull request separate from the main fbdev pull request, as this
contains a bunch of OMAP board file changes and thus could possibly be
rejected in case of bad conflicts.
The removal of the old display drivers depend on the board file changes, so
Tony Lindgren suggested taking them together via fbdev tree. These are in
linux-next, and also Tony didn't see any conflicts with any of the branches he
had, so they should go in clean.
Tomi
The following changes since commit b36f4be3de1b123d8601de062e7dbfc904f305fb:
Linux 3.11-rc6 (2013-08-18 14:36:53 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-3.12-omap-legacy-removal
for you to fetch changes up to 9560dc1059222d059d494a64e5da4c54d23838da:
OMAPDSS: rename omap_dss_device's 'device' field to 'dst' (2013-08-30 08:51:11 +0300)
----------------------------------------------------------------
OMAP specific fbdev changes for 3.12:
* Change the OMAP board files to use the new OMAP display drivers
* Remove all the old drivers, and the related auxiliary code.
----------------------------------------------------------------
Tomi Valkeinen (35):
ARM: OMAP2+: Remove legacy DSS initialization for omap4
ARM: OMAP2+: Add selected display drivers to omap2plus_defconfig
ARM: OMAP: dss-common: use new display drivers
ARM: OMAP: 4430SDP: remove picodlp device data
ARM: OMAP: overo: use new display drivers
ARM: OMAP: rx51: use new display drivers
ARM: OMAP: beagle: use new display drivers
ARM: OMAP: devkit8000: use new display drivers
ARM: OMAP: 2430SDP: use new display drivers
ARM: OMAP: LDP: use new display drivers
ARM: OMAP: omap3stalker: use new display drivers
ARM: OMAP: igep0020: use new display drivers
ARM: OMAP: cm-t35: use new display drivers
ARM: OMAP: H4: use new display drivers
ARM: OMAP: 3430SDP: use new display drivers
ARM: OMAP: OMAP3EVM: use new display drivers
ARM: OMAP: Pandora: use new display drivers
ARM: OMAP: Zoom: use new display drivers
ARM: OMAP: AM3517EVM: use new display drivers
ARM: OMAP2+: Remove old display drivers from omap2plus_defconfig
OMAPDSS: RFBI: Mark RFBI as broken
OMAPDSS: remove omap_dss_device->channel field
OMAPDSS: fix DPI and SDI device ids
OMAPDSS: SDI: change regulator handling
OMAPDSS: DPI: change regulator handling
OMAPDSS: remove all old panel drivers
OMAPDSS: DPI: remove code related to old panel model
OMAPDSS: HDMI: remove code related to old panel model
OMAPDSS: DSI: remove code related to old panel model
OMAPDSS: SDI: remove code related to old panel model
OMAPDSS: VENC: remove code related to old panel model
OMAPDSS: RFBI: remove code related to old panel model
OMAPDSS: DSS: remove legacy dss bus support
OMAPDSS: rename omap_dss_device's 'output' to 'src'
OMAPDSS: rename omap_dss_device's 'device' field to 'dst'
arch/arm/configs/omap2plus_defconfig | 12 +-
arch/arm/mach-omap2/board-2430sdp.c | 57 +-
arch/arm/mach-omap2/board-3430sdp.c | 83 +-
arch/arm/mach-omap2/board-am3517evm.c | 113 +-
arch/arm/mach-omap2/board-cm-t35.c | 100 +-
arch/arm/mach-omap2/board-devkit8000.c | 96 +-
arch/arm/mach-omap2/board-h4.c | 48 +-
arch/arm/mach-omap2/board-igep0020.c | 36 +-
arch/arm/mach-omap2/board-ldp.c | 68 +-
arch/arm/mach-omap2/board-omap3beagle.c | 56 +-
arch/arm/mach-omap2/board-omap3evm.c | 87 +-
arch/arm/mach-omap2/board-omap3pandora.c | 48 +-
arch/arm/mach-omap2/board-omap3stalker.c | 61 +-
arch/arm/mach-omap2/board-overo.c | 160 +-
arch/arm/mach-omap2/board-rx51-peripherals.c | 12 +
arch/arm/mach-omap2/board-rx51-video.c | 35 +-
arch/arm/mach-omap2/board-zoom-display.c | 30 +-
arch/arm/mach-omap2/display.c | 4 +-
arch/arm/mach-omap2/dss-common.c | 244 ++-
arch/arm/mach-omap2/dss-common.h | 2 -
drivers/gpu/drm/omapdrm/omap_encoder.c | 2 +-
drivers/video/omap2/Kconfig | 1 -
drivers/video/omap2/Makefile | 1 -
drivers/video/omap2/displays-new/encoder-tfp410.c | 14 +-
.../video/omap2/displays-new/encoder-tpd12s015.c | 14 +-
drivers/video/omap2/displays/Kconfig | 75 -
drivers/video/omap2/displays/Makefile | 11 -
drivers/video/omap2/displays/panel-acx565akm.c | 798 ----------
drivers/video/omap2/displays/panel-generic-dpi.c | 744 ----------
.../omap2/displays/panel-lgphilips-lb035q02.c | 262 ----
drivers/video/omap2/displays/panel-n8x0.c | 616 --------
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 290 ----
drivers/video/omap2/displays/panel-picodlp.c | 559 -------
drivers/video/omap2/displays/panel-picodlp.h | 288 ----
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 198 ---
drivers/video/omap2/displays/panel-taal.c | 1551 --------------------
drivers/video/omap2/displays/panel-tfp410.c | 353 -----
.../video/omap2/displays/panel-tpo-td043mtea1.c | 596 --------
drivers/video/omap2/dss/Kconfig | 1 +
drivers/video/omap2/dss/Makefile | 5 +-
drivers/video/omap2/dss/apply.c | 4 +-
drivers/video/omap2/dss/core.c | 324 +---
drivers/video/omap2/dss/dpi.c | 121 +-
drivers/video/omap2/dss/dsi.c | 275 +---
drivers/video/omap2/dss/dss.h | 45 -
drivers/video/omap2/dss/hdmi.c | 307 +---
drivers/video/omap2/dss/hdmi_panel.c | 414 ------
drivers/video/omap2/dss/output.c | 22 +-
drivers/video/omap2/dss/rfbi.c | 135 +-
drivers/video/omap2/dss/sdi.c | 119 +-
drivers/video/omap2/dss/venc.c | 122 +-
include/video/omap-panel-data.h | 118 --
include/video/omapdss.h | 106 +-
53 files changed, 973 insertions(+), 8870 deletions(-)
delete mode 100644 drivers/video/omap2/displays/Kconfig
delete mode 100644 drivers/video/omap2/displays/Makefile
delete mode 100644 drivers/video/omap2/displays/panel-acx565akm.c
delete mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
delete mode 100644 drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
delete mode 100644 drivers/video/omap2/displays/panel-n8x0.c
delete mode 100644 drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
delete mode 100644 drivers/video/omap2/displays/panel-picodlp.c
delete mode 100644 drivers/video/omap2/displays/panel-picodlp.h
delete mode 100644 drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
delete mode 100644 drivers/video/omap2/displays/panel-taal.c
delete mode 100644 drivers/video/omap2/displays/panel-tfp410.c
delete mode 100644 drivers/video/omap2/displays/panel-tpo-td043mtea1.c
delete mode 100644 drivers/video/omap2/dss/hdmi_panel.c
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [GIT PULL] fbdev changes for 3.12
From: David Herrmann @ 2013-09-05 7:48 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Linus Torvalds, linux-kernel, linux-fbdev, Ingo Molnar,
Jean-Christophe PLAGNIOL-VILLARD
In-Reply-To: <5228294E.8050401@ti.com>
Hi Tomi
On Thu, Sep 5, 2013 at 8:48 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Linus,
>
> Here are the fbdev changes for 3.12.
>
> There's a conflict in drivers/video/simplefb.c, which you can resolve by using
> the version in your tree.
No, both need to be merged. The current version lacks support for
ABGR8888. The fbdev tree lacks the DRM format, which should be:
{ "a8b8g8r8", 32, {0, 8}, {8, 8}, {16, 8}, {24, 8}, DRM_FORMAT_ABGR8888 }
> I guess the simplefb changes were taken through Ingo's tree because the series
> includes x86 arch changes, but it would have been nice to see the patches in
> the linux-next...
simplefb was in linux-next. I also acked the fixup from Stephen. See
this commit from a pre-3.12 -next tree:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/include/linux/platform_data/simplefb.h?idDed8fb588e517a2ef917c6757ee11ee47348978
It was merged through -tip around 1 month ago. It does mainly change
the way x86 provides firmware-fb information to drivers so -tip seemed
fine to me.
On another note, could you have a look at:
[PATCH] efifb: prevent null dereferences by removing unused array
indices from dmi_list
That somehow didn't make it in your fbdev-next pull.
Thanks
David
^ permalink raw reply
* Re: [GIT PULL] fbdev changes for 3.12
From: Stephen Rothwell @ 2013-09-05 7:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Herrmann, Tomi Valkeinen, linux-kernel, linux-fbdev,
Ingo Molnar, Jean-Christophe PLAGNIOL-VILLARD
In-Reply-To: <CANq1E4Rd2eEaNnX8b3WAQcQX-T4+fR-4OMAtoSaAp9XwdGLpSg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]
Hi Linus,
On Thu, 5 Sep 2013 09:48:18 +0200 David Herrmann <dh.herrmann@gmail.com> wrote:
>
> On Thu, Sep 5, 2013 at 8:48 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >
> > Here are the fbdev changes for 3.12.
> >
> > There's a conflict in drivers/video/simplefb.c, which you can resolve by using
> > the version in your tree.
>
> No, both need to be merged. The current version lacks support for
> ABGR8888. The fbdev tree lacks the DRM format, which should be:
> { "a8b8g8r8", 32, {0, 8}, {8, 8}, {16, 8}, {24, 8}, DRM_FORMAT_ABGR8888 }
>
> > I guess the simplefb changes were taken through Ingo's tree because the series
> > includes x86 arch changes, but it would have been nice to see the patches in
> > the linux-next...
>
> simplefb was in linux-next. I also acked the fixup from Stephen. See
> this commit from a pre-3.12 -next tree:
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/include/linux/platform_data/simplefb.h?id=44ed8fb588e517a2ef917c6757ee11ee47348978
In case it is not obvious, this is the extra merge fix patch I have been
carrying (after using the version of drivers/video/simplefb.c from the
tip tree - which is already in your tree):
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 14 Aug 2013 14:29:27 +1000
Subject: [PATCH] simplefb: merge conflict fix
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/linux/platform_data/simplefb.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/platform_data/simplefb.h b/include/linux/platform_data/simplefb.h
index 53774b0..c395d4c 100644
--- a/include/linux/platform_data/simplefb.h
+++ b/include/linux/platform_data/simplefb.h
@@ -27,6 +27,7 @@
{ "a8r8g8b8", 32, {16, 8}, {8, 8}, {0, 8}, {24, 8}, DRM_FORMAT_ARGB8888 }, \
{ "x2r10g10b10", 32, {20, 10}, {10, 10}, {0, 10}, {0, 0}, DRM_FORMAT_XRGB2101010 }, \
{ "a2r10g10b10", 32, {20, 10}, {10, 10}, {0, 10}, {30, 2}, DRM_FORMAT_ARGB2101010 }, \
+ { "a8b8g8r8", 32, {0, 8}, {8, 8}, {16, 8}, {24, 8}, DRM_FORMAT_ABGR8888 }, \
}
/*
--
1.8.4.rc0
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [GIT PULL] fbdev changes for 3.12
From: Tomi Valkeinen @ 2013-09-05 8:02 UTC (permalink / raw)
To: David Herrmann
Cc: Linus Torvalds, linux-kernel, linux-fbdev, Ingo Molnar,
Jean-Christophe PLAGNIOL-VILLARD, Stephen Rothwell
In-Reply-To: <CANq1E4Rd2eEaNnX8b3WAQcQX-T4+fR-4OMAtoSaAp9XwdGLpSg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
On 05/09/13 10:48, David Herrmann wrote:
>> There's a conflict in drivers/video/simplefb.c, which you can resolve by using
>> the version in your tree.
>
> No, both need to be merged. The current version lacks support for
> ABGR8888. The fbdev tree lacks the DRM format, which should be:
> { "a8b8g8r8", 32, {0, 8}, {8, 8}, {16, 8}, {24, 8}, DRM_FORMAT_ABGR8888 }
Ah, right you are. a8b8g8r8 looks too much like a8r8g8b8, so my morning
groggy eyes didn't see that.
>> I guess the simplefb changes were taken through Ingo's tree because the series
>> includes x86 arch changes, but it would have been nice to see the patches in
>> the linux-next...
>
> simplefb was in linux-next. I also acked the fixup from Stephen. See
> this commit from a pre-3.12 -next tree:
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/include/linux/platform_data/simplefb.h?id=44ed8fb588e517a2ef917c6757ee11ee47348978
Right. And I have the mail about the conflict from Stephen in my
mailbox, which I had read, but successfully forgot about it during my
vacation.
So, what I said about conflict resolution and the series missing from
linux-next was wrong, and the conflict resolution in linux-next is what
should be used.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v2] efifb: prevent null dereferences by removing unused array indices from dmi_list
From: Tomi Valkeinen @ 2013-09-05 8:12 UTC (permalink / raw)
To: James Bates
Cc: David Herrmann, Peter Jones, Jean-Christophe Plagniol-Villard,
linux-fbdev, linux-kernel, H. Peter Anvin
In-Reply-To: <1376684395.6529.5.camel@hermes>
[-- Attachment #1: Type: text/plain, Size: 4245 bytes --]
Hi James,
Can you resend this? I don't know how I could apply the patch from this
mail without re-creating it manually.
Tomi
On 16/08/13 23:19, James Bates wrote:
> On Fri, 2013-08-16 at 15:37 +0200, David Herrmann wrote:
>> Hi
>> (CC'ing hpa)
>>
>> Yepp, this patch looks good:
>> Reviewed-by: David Herrmann <dh.herrmann@gmail.com <mailto:dh.herrmann@gmail.com>>
>>
>> However, I'd like to see some code to prevent this from happening
>> again. It isn't really obvious that removing an entry will result in a
>> NULL-deref. I am not the maintainer of this code, but I'd really like
>> to see a "(dmi_list[i].optname && !strcmp())" check in efifb_setup().
>> Otherwise we _will_ run into this again.
>>
>> Side note: this code got moved to arch/x86/kernel/sysfb_efi.c in the
>> x86 tree. I am adding hpa here so he will remember this once Linus
>> gets a merge conflict (iff the sysfb changes get merged through the
>> x86 tree).
>>
>> Thanks
>> David
> Sure thing, here is the patch again, with the extra check in
> efifb_setup() (it turns out one can simply
> switch around the order of the checks: implicitly initialized dmi_list
> items will have base == 0):
>
> Full patch v2:
> the dmi_list array is initialized using gnu designated initializers, and
> therefore
> contains fewer explicitly defined entries as there are elements in it. This
> is because the enum above with M_blabla constants contains more items
> than the designated
> initializer. Those elements not explicitly initialized are implicitly
> set to 0.
>
> Now efifb_setup(), L.322 & L.323, loops through all these array
> elements, and performs
> a strcmp o a field (optname) in each item. For non explicitly
> initialized elements this
> will be a null pointer:
>
> for (i = 0; i < M_UNKNOWN; i++) {
> if (!strcmp(this_opt,
> dmi_list[i].optname) &&
>
> On my macbook6,1 the predefined values are for some reason incorrect,
> and most parameters
> are preset correctly by my efi bootloader (elilo). but
> stride/line_length is not detected
> correctly and so I wish to set it explicitly using a
> "video=efifb:stride:2048" command-line
> argument. Because of the above null dereference, an exception
> (presumably) occurs before
> the parsing code (L.333) is ever reached. I say presumably since the mac
> hangs on boot
> without a console, and I can therefore not see any output.
>
> By removing the unused values from the enum, and thus preventing
> implicitly initialized items
> in the dmi_list array, the null dereference does not occur, my customer
> command-line arg is
> parsed correctly, and my console displays correctly.
>
> This patch removes the unused enum values, and also guards against any
> future implicit
> initializing by inverting the check order in the if statement, and
> checking first whether
> dmi_list[i].base is null.
>
> Signed-off-by: James Bates <james.h.bates@yahoo.com
> <mailto:james.h.bates@yahoo.com>>
> ---
> drivers/video/efifb.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
> index 50fe668..161757b 100644
> --- a/drivers/video/efifb.c
> +++ b/drivers/video/efifb.c
> @@ -50,12 +50,9 @@ enum {
> M_MINI_3_1, /* Mac Mini, 3,1th gen */
> M_MINI_4_1, /* Mac Mini, 4,1th gen */
> M_MB, /* MacBook */
> - M_MB_2, /* MacBook, 2nd rev. */
> - M_MB_3, /* MacBook, 3rd rev. */
> M_MB_5_1, /* MacBook, 5th rev. */
> M_MB_6_1, /* MacBook, 6th rev. */
> M_MB_7_1, /* MacBook, 7th rev. */
> - M_MB_SR, /* MacBook, 2nd gen, (Santa Rosa) */
> M_MBA, /* MacBook Air */
> M_MBA_3, /* Macbook Air, 3rd rev */
> M_MBP, /* MacBook Pro */
> @@ -323,8 +320,8 @@ static int __init efifb_setup(char *options)
> if (!*this_opt) continue;
>
> for (i = 0; i < M_UNKNOWN; i++) {
> - if (!strcmp(this_opt, dmi_list[i].optname) &&
> - dmi_list[i].base != 0) {
> + if (dmi_list[i].base != 0 &&
> + !strcmp(this_opt, dmi_list[i].optname)) {
> screen_info.lfb_base = dmi_list[i].base;
> screen_info.lfb_linelength = dmi_list[i].stride;
> screen_info.lfb_width = dmi_list[i].width;
> --
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [PATCH] video/drm: Drop superfluous "select VT_HW_CONSOLE_BINDING"
From: Geert Uytterhoeven @ 2013-09-05 8:20 UTC (permalink / raw)
To: David Herrmann, H. Peter Anvin
Cc: Inki Dae, David Airlie, Geoff Levand, dri-devel, linux-fbdev,
linux-kernel, Geert Uytterhoeven
commit 765d5b9c2b72f5b99722cdfcf4bf8f88c556cf92 ("fbdev: fbcon: select
VT_HW_CONSOLE_BINDING") made FRAMEBUFFER_CONSOLE always select
VT_HW_CONSOLE_BINDING, but forgot to remove
select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
from the individual drivers' sections that already did this before.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/gpu/drm/exynos/Kconfig | 1 -
drivers/video/Kconfig | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 772c62a..1344d34 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -5,7 +5,6 @@ config DRM_EXYNOS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
help
Choose this option if you have a Samsung SoC EXYNOS chipset.
If M is selected the module will be called exynosdrm.
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 9788340..f60e3fa 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2174,7 +2174,6 @@ config FB_PS3
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
- select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
---help---
Include support for the virtual frame buffer in the PS3 platform.
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] video/drm: Drop superfluous "select VT_HW_CONSOLE_BINDING"
From: David Herrmann @ 2013-09-05 8:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: H. Peter Anvin, Inki Dae, David Airlie, Geoff Levand,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel
In-Reply-To: <1378369230-7786-1-git-send-email-geert@linux-m68k.org>
Hi
On Thu, Sep 5, 2013 at 10:20 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> commit 765d5b9c2b72f5b99722cdfcf4bf8f88c556cf92 ("fbdev: fbcon: select
> VT_HW_CONSOLE_BINDING") made FRAMEBUFFER_CONSOLE always select
> VT_HW_CONSOLE_BINDING, but forgot to remove
>
> select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
>
> from the individual drivers' sections that already did this before.
Yepp, looks good. Maybe we should just drop it entirely. It's 200
lines of code and no additional dependencies. Anyway, nice catch:
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Thanks
David
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> drivers/gpu/drm/exynos/Kconfig | 1 -
> drivers/video/Kconfig | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 772c62a..1344d34 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -5,7 +5,6 @@ config DRM_EXYNOS
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
> help
> Choose this option if you have a Samsung SoC EXYNOS chipset.
> If M is selected the module will be called exynosdrm.
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 9788340..f60e3fa 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2174,7 +2174,6 @@ config FB_PS3
> select FB_SYS_COPYAREA
> select FB_SYS_IMAGEBLIT
> select FB_SYS_FOPS
> - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
> ---help---
> Include support for the virtual frame buffer in the PS3 platform.
>
> --
> 1.7.9.5
>
^ permalink raw reply
* RE: [PATCH] video/drm: Drop superfluous "select VT_HW_CONSOLE_BINDING"
From: Inki Dae @ 2013-09-05 10:00 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1378369230-7786-1-git-send-email-geert@linux-m68k.org>
> -----Original Message-----
> From: Geert Uytterhoeven [mailto:geert@linux-m68k.org]
> Sent: Thursday, September 05, 2013 5:21 PM
> To: David Herrmann; H. Peter Anvin
> Cc: Inki Dae; David Airlie; Geoff Levand; dri-devel@lists.freedesktop.org;
> linux-fbdev@vger.kernel.org; linux-kernel@vger.kernel.org; Geert
> Uytterhoeven
> Subject: [PATCH] video/drm: Drop superfluous "select
> VT_HW_CONSOLE_BINDING"
>
> commit 765d5b9c2b72f5b99722cdfcf4bf8f88c556cf92 ("fbdev: fbcon: select
> VT_HW_CONSOLE_BINDING") made FRAMEBUFFER_CONSOLE always select
> VT_HW_CONSOLE_BINDING, but forgot to remove
>
> select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
>
> from the individual drivers' sections that already did this before.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> drivers/gpu/drm/exynos/Kconfig | 1 -
> drivers/video/Kconfig | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig
> b/drivers/gpu/drm/exynos/Kconfig
> index 772c62a..1344d34 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -5,7 +5,6 @@ config DRM_EXYNOS
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
> help
> Choose this option if you have a Samsung SoC EXYNOS chipset.
> If M is selected the module will be called exynosdrm.
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 9788340..f60e3fa 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2174,7 +2174,6 @@ config FB_PS3
> select FB_SYS_COPYAREA
> select FB_SYS_IMAGEBLIT
> select FB_SYS_FOPS
> - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
> ---help---
> Include support for the virtual frame buffer in the PS3 platform.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Thanks,
Inki Dae
>
> --
> 1.7.9.5
^ permalink raw reply
* [PATCH] simplefb: print some info about the registered fb
From: Tom Gundersen @ 2013-09-06 11:49 UTC (permalink / raw)
To: linux-fbdev
Cc: linux-kernel, tomi.valkeinen, plagnioj, Tom Gundersen,
Stephen Warren, David Herrmann
In-Reply-To: <1378467880-1040-1-git-send-email-teg@jklm.no>
This is similar to the output printed by efifb.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
---
Hi,
Sorry for the resend, got the ml address wrong.
-t
drivers/video/simplefb.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index 8d78106..4196686 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -220,6 +220,14 @@ static int simplefb_probe(struct platform_device *pdev)
}
info->pseudo_palette = (void *)(info + 1);
+ dev_info(&pdev->dev, "framebuffer at 0x%lx, mapped to 0x%p\n",
+ info->fix.smem_start, info->screen_base);
+ dev_info(&pdev->dev, "format=%s, mode=%dx%dx%d, linelength=%d\n",
+ params.format->name,
+ info->var.xres, info->var.yres,
+ info->var.bits_per_pixel,
+ info->fix.line_length);
+
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
--
1.8.4
^ permalink raw reply related
* [BUG] simplefb not showing any output
From: Tom Gundersen @ 2013-09-06 16:14 UTC (permalink / raw)
To: linux-fbdev
Hi guys,
I have been trying simplefb from mainline (v3.11-5058-g57d7309), with
a couple of patches on top (one to make simplefb actually load on my
system, posted to x86 earlier today, and one to make it show some
output posted to this list earlier today).
The driver seems to load ok, but sadly it does not give any output. If
I boot via the gummiboot menu the screen remains black, and if I don't
enter the gummiboot menu the screen remains grey (it is a Mac).
Except for that the machine works (I can log on blindly in order to reboot).
Is this a known problem? Any suggestions on where to start debugging?
Any more info I could provide?
The output given during boot is
calling simplefb_driver_init+0x0/0x14 @ 1
simple-framebuffer simple-framebuffer.0: simplefb: framebuffer at
0x90000000, mapped to 0xffffc90009b00000
simple-framebuffer simple-framebuffer.0: simplefb: format a8r8g8b8,
mode is 1366x768x32, linelengthV32
simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!
initcall simplefb_driver_init+0x0/0x14 returned 0 after 1072 usecs
-t
^ permalink raw reply
* Re: [BUG] simplefb not showing any output
From: David Herrmann @ 2013-09-06 16:57 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
Hi Tom
( 2 more mails and you might get the fbdev ML right ;) )
On Fri, Sep 6, 2013 at 6:14 PM, Tom Gundersen <teg@jklm.no> wrote:
> Hi guys,
>
> I have been trying simplefb from mainline (v3.11-5058-g57d7309), with
> a couple of patches on top (one to make simplefb actually load on my
> system, posted to x86 earlier today, and one to make it show some
> output posted to this list earlier today).
>
> The driver seems to load ok, but sadly it does not give any output. If
> I boot via the gummiboot menu the screen remains black, and if I don't
> enter the gummiboot menu the screen remains grey (it is a Mac).
>
> Except for that the machine works (I can log on blindly in order to reboot).
>
> Is this a known problem? Any suggestions on where to start debugging?
> Any more info I could provide?
>
> The output given during boot is
>
> calling simplefb_driver_init+0x0/0x14 @ 1
> simple-framebuffer simple-framebuffer.0: simplefb: framebuffer at
> 0x90000000, mapped to 0xffffc90009b00000
> simple-framebuffer simple-framebuffer.0: simplefb: format a8r8g8b8,
> mode is 1366x768x32, linelengthV32
> simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!
> initcall simplefb_driver_init+0x0/0x14 returned 0 after 1072 usecs
Ok, this looks all good. Few questions:
- Is CONFIG_FB_EFI enabled? If not, please enable it and try again
(hint: CONFIG_FB_VESA doesn't hurt either)
- Could you try the _same_ kernel config but disable CONFIG_X86_SYSFB.
This will avoid creating simple-fb devices and instead load efifb
again. Does efifb work? Does efifb print the same offsets as your
simplefb printk()?
- Are you sure that it's an simplefb problem? Please make sure fbcon
is enabled (could you attach your dmesg output?). You could also try
SSH'ing into the machine and starting some fbdev program (like X with
xf86-video-fbdev installed). Or does fbcon with efifb work?
Thanks
David
^ permalink raw reply
* Re: [BUG] simplefb not showing any output
From: Tom Gundersen @ 2013-09-06 17:12 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
On Fri, Sep 6, 2013 at 6:57 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> ( 2 more mails and you might get the fbdev ML right ;) )
Modern technology...
> - Is CONFIG_FB_EFI enabled? If not, please enable it and try again
> (hint: CONFIG_FB_VESA doesn't hurt either)
FB_EFI was enabled, FB_VESA was not, but I'll enable it. Out of
interest, how could this affect the situation? If I understand
correctly these drivers won't be loaded as long as simple-framebuffer
is created, or am I missing something?
> - Could you try the _same_ kernel config but disable CONFIG_X86_SYSFB.
> This will avoid creating simple-fb devices and instead load efifb
> again. Does efifb work? Does efifb print the same offsets as your
> simplefb printk()?
Yeah, efifb works fine, I'll double-check everything and note down the offsets.
> - Are you sure that it's an simplefb problem? Please make sure fbcon
> is enabled (could you attach your dmesg output?). You could also try
> SSH'ing into the machine and starting some fbdev program (like X with
> xf86-video-fbdev installed). Or does fbcon with efifb work?
fbcon with efifb works fine (so I guess trying X is not necessary?).
Cheers,
Tom
^ permalink raw reply
* Re: [BUG] simplefb not showing any output
From: David Herrmann @ 2013-09-06 17:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
Hi
On Fri, Sep 6, 2013 at 7:12 PM, Tom Gundersen <teg@jklm.no> wrote:
> On Fri, Sep 6, 2013 at 6:57 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> ( 2 more mails and you might get the fbdev ML right ;) )
>
> Modern technology...
>
>> - Is CONFIG_FB_EFI enabled? If not, please enable it and try again
>> (hint: CONFIG_FB_VESA doesn't hurt either)
>
> FB_EFI was enabled, FB_VESA was not, but I'll enable it. Out of
> interest, how could this affect the situation? If I understand
> correctly these drivers won't be loaded as long as simple-framebuffer
> is created, or am I missing something?
In case you disable X86_SYSFB vesafb might still be used (I wasn't
sure you used efifb). And there might be some nasty Kconfig-select
logic that I overlooked (like FB_BOOT_VESA_SUPPORT).. Just to be sure.
>> - Could you try the _same_ kernel config but disable CONFIG_X86_SYSFB.
>> This will avoid creating simple-fb devices and instead load efifb
>> again. Does efifb work? Does efifb print the same offsets as your
>> simplefb printk()?
>
> Yeah, efifb works fine, I'll double-check everything and note down the offsets.
Just to be clear, efifb still with the new x86-sysfb infrastructure
works? Because I moved some efifb quirks from efifb.c to
x86/kernel/sysfb_efi.c. So even with CONFIG_X86_SYSFB=n the situation
is still different from pre-3.12.
>> - Are you sure that it's an simplefb problem? Please make sure fbcon
>> is enabled (could you attach your dmesg output?). You could also try
>> SSH'ing into the machine and starting some fbdev program (like X with
>> xf86-video-fbdev installed). Or does fbcon with efifb work?
>
> fbcon with efifb works fine (so I guess trying X is not necessary?).
Yeah, if fbcon+efifb works, no need to test X.
Regards
David
^ permalink raw reply
* [PATCH 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2013-09-06 17:23 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds basic DT bindings for the PL11x CLCD cells
and make their fbdev driver use them.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
.../devicetree/bindings/video/arm,pl11x.txt | 87 +++++++++
drivers/video/Kconfig | 1 +
drivers/video/amba-clcd.c | 214 +++++++++++++++++++++
3 files changed, 302 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt
diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt
new file mode 100644
index 0000000..178aebb
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
@@ -0,0 +1,87 @@
+* ARM PrimeCell Color LCD Controller (CLCD) PL110/PL111
+
+See also Documentation/devicetree/bindings/arm/primecell.txt
+
+Required properties:
+
+- compatible: must be one of:
+ "arm,pl110", "arm,primecell"
+ "arm,pl111", "arm,primecell"
+- reg: base address and size of the control registers block
+- interrupts: either a single interrupt specifier representing the
+ combined interrupt output (CLCDINTR) or an array of
+ four interrupt specifiers for CLCDMBEINTR,
+ CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR; in the
+ latter case interrupt names must be specified
+ (see below)
+- interrupt-names: when four interrupts are specified, their names:
+ "mbe", "vcomp", "lnbu", "fuf"
+ must be specified in order respective to the
+ interrupt specifiers
+- clocks: contains phandle and clock specifier pairs for the entries
+ in the clock-names property. See
+ Documentation/devicetree/binding/clock/clock-bindings.txt
+- clocks names: should contain "clcdclk" and "apb_pclk"
+
+Optional properties:
+
+- video-ram: phandle to a node describing specialized video memory
+ (that is *not* described in the top level "memory" node)
+ that must be used as a framebuffer, eg. due to restrictions
+ of the system interconnect; the node must contain a
+ standard reg property describing the address and the size
+ of the memory area
+- max-framebuffer-size: maximum size in bytes of the framebuffer the
+ system can handle, eg. in terms of available
+ memory bandwidth
+
+In the simplest case of a display panel being connected directly to the
+CLCD, it can be described in the node:
+
+- panel-dimensions: (optional) array of two numbers (width and height)
+ describing physical dimension in mm of the panel
+- panel-type: (required) must be "tft" or "stn", defines panel type
+- panel-tft-interface: (for "tft" panel type) array of 3 numbers defining
+ widths in bits of the R, G and B components
+- panel-tft-rb-swapped: (for "tft" panel type) if present means that
+ the R & B components are swapped on the board
+- panel-stn-color: (for "stn" panel type) if present means that
+ the panel is a colour STN display, if missing
+ is a monochrome display
+- panel-stn-dual: (for "stn" panel type) if present means that there
+ are two STN displays connected
+- panel-stn-4bit: (for monochrome "stn" panel) if present means
+ that the monochrome display is connected
+ via 4 bit-wide interface
+- display-timings: standard display timings sub-node, see
+ Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+ clcd@1f0000 {
+ compatible = "arm,pl111", "arm,primecell";
+ reg = <0x1f0000 0x1000>;
+ interrupts = <14>;
+ clocks = <&v2m_oscclk1>, <&smbclk>;
+ clock-names = "clcdclk", "apb_pclk";
+
+ video-ram = <&v2m_vram>;
+ max-framebuffer-size = <614400>; /* 640x480 16bpp */
+
+ panel-type = "tft";
+ panel-tft-interface = <8 8 8>;
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
+ };
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4cf1e1d..375bf63 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -316,6 +316,7 @@ config FB_ARMCLCD
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select VIDEOMODE_HELPERS if OF
help
This framebuffer device driver is for the ARM PrimeCell PL110
Colour LCD controller. ARM PrimeCells provide the building
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..145ca5a 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -25,6 +25,11 @@
#include <linux/amba/clcd.h>
#include <linux/clk.h>
#include <linux/hardirq.h>
+#include <linux/dma-mapping.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <video/of_display_timing.h>
+#include <video/of_videomode.h>
#include <asm/sizes.h>
@@ -542,6 +547,212 @@ static int clcdfb_register(struct clcd_fb *fb)
return ret;
}
+#ifdef CONFIG_OF
+static int clcdfb_of_get_tft_panel(struct device_node *node,
+ struct clcd_panel *panel)
+{
+ int err;
+ u32 rgb[3];
+ int r, g, b;
+
+ err = of_property_read_u32_array(node, "panel-tft-interface", rgb, 3);
+ if (err)
+ return err;
+
+ r = rgb[0];
+ g = rgb[1];
+ b = rgb[2];
+
+ /* Bypass pixel clock divider, data output on the falling edge */
+ panel->tim2 = TIM2_BCD | TIM2_IPC;
+
+ /* TFT display, vert. comp. interrupt at the start of the back porch */
+ panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
+
+ if (r >= 4 && g >= 4 && b >= 4)
+ panel->caps |= CLCD_CAP_444;
+ if (r >= 5 && g >= 5 && b >= 5)
+ panel->caps |= CLCD_CAP_5551;
+ if (r >= 5 && g >= 6 && b >= 5)
+ panel->caps |= CLCD_CAP_565;
+ if (r >= 8 && g >= 8 && b >= 8)
+ panel->caps |= CLCD_CAP_888;
+
+ if (of_get_property(node, "panel-tft-rb-swapped", NULL))
+ panel->caps &= ~CLCD_CAP_RGB;
+ else
+ panel->caps &= ~CLCD_CAP_BGR;
+
+ return 0;
+}
+
+static int clcdfb_of_init_display(struct clcd_fb *fb)
+{
+ struct device_node *node = fb->dev->dev.of_node;
+ u32 max_size;
+ u32 dimensions[2];
+ char *mode_name;
+ int len, err;
+ const char *panel_type;
+
+ fb->panel = devm_kzalloc(&fb->dev->dev, sizeof(*fb->panel), GFP_KERNEL);
+ if (!fb->panel)
+ return -ENOMEM;
+
+ err = of_get_fb_videomode(fb->dev->dev.of_node, &fb->panel->mode,
+ OF_USE_NATIVE_MODE);
+ if (err)
+ return err;
+
+ len = snprintf(NULL, 0, "%ux%u@%u", fb->panel->mode.xres,
+ fb->panel->mode.yres, fb->panel->mode.refresh);
+ mode_name = devm_kzalloc(&fb->dev->dev, len + 1, GFP_KERNEL);
+ snprintf(mode_name, len + 1, "%ux%u@%u", fb->panel->mode.xres,
+ fb->panel->mode.yres, fb->panel->mode.refresh);
+ fb->panel->mode.name = mode_name;
+
+ err = of_property_read_u32(node, "max-framebuffer-size", &max_size);
+ if (!err)
+ fb->panel->bpp = max_size / (fb->panel->mode.xres *
+ fb->panel->mode.yres) * 8;
+ else
+ fb->panel->bpp = 32;
+
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ fb->panel->cntl |= CNTL_BEBO;
+#endif
+
+ if (of_property_read_u32_array(node, "panel-dimensions",
+ dimensions, 2) == 0) {
+ fb->panel->width = dimensions[0];
+ fb->panel->height = dimensions[1];
+ } else {
+ fb->panel->width = -1;
+ fb->panel->height = -1;
+ }
+
+ panel_type = of_get_property(node, "panel-type", &len);
+ if (strncmp(panel_type, "tft", len) == 0)
+ return clcdfb_of_get_tft_panel(node, fb->panel);
+ else
+ return -EINVAL;
+}
+
+static int clcdfb_of_vram_setup(struct clcd_fb *fb)
+{
+ const __be32 *prop = of_get_property(fb->dev->dev.of_node, "video-ram",
+ NULL);
+ struct device_node *node = of_find_node_by_phandle(be32_to_cpup(prop));
+ u64 size;
+ int err;
+
+ if (!node)
+ return -ENODEV;
+
+ err = clcdfb_of_init_display(fb);
+ if (err)
+ return err;
+
+ fb->fb.screen_base = of_iomap(node, 0);
+ if (!fb->fb.screen_base)
+ return -ENOMEM;
+
+ fb->fb.fix.smem_start = of_translate_address(node,
+ of_get_address(node, 0, &size, NULL));
+ fb->fb.fix.smem_len = size;
+
+ return 0;
+}
+
+static int clcdfb_of_vram_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+ unsigned long off, user_size, kernel_size;
+
+ off = vma->vm_pgoff << PAGE_SHIFT;
+ user_size = vma->vm_end - vma->vm_start;
+ kernel_size = fb->fb.fix.smem_len;
+
+ if (off >= kernel_size || user_size > (kernel_size - off))
+ return -ENXIO;
+
+ return remap_pfn_range(vma, vma->vm_start,
+ __phys_to_pfn(fb->fb.fix.smem_start) + vma->vm_pgoff,
+ user_size,
+ pgprot_writecombine(vma->vm_page_prot));
+}
+
+static void clcdfb_of_vram_remove(struct clcd_fb *fb)
+{
+ iounmap(fb->fb.screen_base);
+}
+
+static int clcdfb_of_dma_setup(struct clcd_fb *fb)
+{
+ unsigned long framesize;
+ dma_addr_t dma;
+ int err;
+
+ err = clcdfb_of_init_display(fb);
+ if (err)
+ return err;
+
+ framesize = fb->panel->mode.xres * fb->panel->mode.yres *
+ fb->panel->bpp / 8;
+ fb->fb.screen_base = dma_alloc_writecombine(&fb->dev->dev, framesize,
+ &dma, GFP_KERNEL);
+ if (!fb->fb.screen_base)
+ return -ENOMEM;
+
+ fb->fb.fix.smem_start = dma;
+ fb->fb.fix.smem_len = framesize;
+
+ return 0;
+}
+
+static int clcdfb_of_dma_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+ return dma_mmap_writecombine(&fb->dev->dev, vma, fb->fb.screen_base,
+ fb->fb.fix.smem_start, fb->fb.fix.smem_len);
+}
+
+static void clcdfb_of_dma_remove(struct clcd_fb *fb)
+{
+ dma_free_writecombine(&fb->dev->dev, fb->fb.fix.smem_len,
+ fb->fb.screen_base, fb->fb.fix.smem_start);
+}
+
+static struct clcd_board *clcdfb_of_get_board(struct amba_device *dev)
+{
+ struct clcd_board *board = devm_kzalloc(&dev->dev, sizeof(*board),
+ GFP_KERNEL);
+ struct device_node *node = dev->dev.of_node;
+
+ if (!board)
+ return NULL;
+
+ board->name = of_node_full_name(node);
+ board->caps = CLCD_CAP_ALL;
+ board->check = clcdfb_check;
+ board->decode = clcdfb_decode;
+ if (of_find_property(node, "video-ram", NULL)) {
+ board->setup = clcdfb_of_vram_setup;
+ board->mmap = clcdfb_of_vram_mmap;
+ board->remove = clcdfb_of_vram_remove;
+ } else {
+ board->setup = clcdfb_of_dma_setup;
+ board->mmap = clcdfb_of_dma_mmap;
+ board->remove = clcdfb_of_dma_remove;
+ }
+
+ return board;
+}
+#else
+static struct clcd_board *clcdfb_of_get_board(struct amba_dev *dev)
+{
+ return NULL;
+}
+#endif
+
static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
{
struct clcd_board *board = dev->dev.platform_data;
@@ -549,6 +760,9 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
int ret;
if (!board)
+ board = clcdfb_of_get_board(dev);
+
+ if (!board)
return -EINVAL;
ret = amba_request_regions(dev, NULL);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 2/2] ARM: vexpress: Add CLCD Device Tree properties
From: Pawel Moll @ 2013-09-06 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1378488201-21146-1-git-send-email-pawel.moll@arm.com>
... for V2M-P1 motherboard CLCD (limited to 640x480 16bpp and using
dedicated video RAM bank) and for V2P-CA9 (up to 1024x768 16bpp).
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 25 +++++++++++++++++++++++--
arch/arm/boot/dts/vexpress-v2m.dtsi | 25 +++++++++++++++++++++++--
arch/arm/boot/dts/vexpress-v2p-ca9.dts | 20 ++++++++++++++++++++
3 files changed, 66 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index ac870fb..91dff88 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -41,7 +41,7 @@
bank-width = <4>;
};
- vram@2,00000000 {
+ v2m_vram: vram@2,00000000 {
compatible = "arm,vexpress-vram";
reg = <2 0x00000000 0x00800000>;
};
@@ -233,6 +233,27 @@
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
+
+ video-ram = <&v2m_vram>;
+ max-framebuffer-size = <614400>; /* 640x480 16bpp */
+
+ /* This is the best the CLCD can do here */
+ panel-type = "tft";
+ panel-tft-interface = <8 8 8>;
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
};
};
@@ -282,7 +303,7 @@
/* CLCD clock */
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 1>;
- freq-range = <23750000 63500000>;
+ freq-range = <23750000 65000000>;
#clock-cells = <0>;
clock-output-names = "v2m:oscclk1";
};
diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi
index f142036..4bc348c 100644
--- a/arch/arm/boot/dts/vexpress-v2m.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
@@ -40,7 +40,7 @@
bank-width = <4>;
};
- vram@3,00000000 {
+ v2m_vram: vram@3,00000000 {
compatible = "arm,vexpress-vram";
reg = <3 0x00000000 0x00800000>;
};
@@ -232,6 +232,27 @@
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
+
+ video-ram = <&v2m_vram>;
+ max-framebuffer-size = <614400>; /* 640x480 16bpp */
+
+ /* This is the best the CLCD can do here */
+ panel-type = "tft";
+ panel-tft-interface = <8 8 8>;
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
};
};
@@ -281,7 +302,7 @@
/* CLCD clock */
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 1>;
- freq-range = <23750000 63500000>;
+ freq-range = <23750000 65000000>;
#clock-cells = <0>;
clock-output-names = "v2m:oscclk1";
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
index 62d9b22..fbe1c998 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
@@ -73,6 +73,26 @@
interrupts = <0 44 4>;
clocks = <&oscclk1>, <&oscclk2>;
clock-names = "clcdclk", "apb_pclk";
+
+ max-framebuffer-size = <1572864>; /* 1024x768 16bpp */
+
+ /* This is the best the CLCD can do here */
+ panel-type = "tft";
+ panel-tft-interface = <8 8 8>;
+ display-timings {
+ native-mode = <&clcd_timing0>;
+ clcd_timing0: xga {
+ clock-frequency = <63500127>;
+ hactive = <1024>;
+ hback-porch = <152>;
+ hfront-porch = <48>;
+ hsync-len = <104>;
+ vactive = <768>;
+ vback-porch = <23>;
+ vfront-porch = <3>;
+ vsync-len = <4>;
+ };
+ };
};
memory-controller@100e0000 {
--
1.8.1.2
^ permalink raw reply related
* Re: [BUG] simplefb not showing any output
From: Tom Gundersen @ 2013-09-06 17:46 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
On Fri, Sep 6, 2013 at 7:19 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Fri, Sep 6, 2013 at 7:12 PM, Tom Gundersen <teg@jklm.no> wrote:
>> On Fri, Sep 6, 2013 at 6:57 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>> ( 2 more mails and you might get the fbdev ML right ;) )
>>
>> Modern technology...
>>
>>> - Is CONFIG_FB_EFI enabled? If not, please enable it and try again
>>> (hint: CONFIG_FB_VESA doesn't hurt either)
>>
>> FB_EFI was enabled, FB_VESA was not, but I'll enable it. Out of
>> interest, how could this affect the situation? If I understand
>> correctly these drivers won't be loaded as long as simple-framebuffer
>> is created, or am I missing something?
>
> In case you disable X86_SYSFB vesafb might still be used (I wasn't
> sure you used efifb). And there might be some nasty Kconfig-select
> logic that I overlooked (like FB_BOOT_VESA_SUPPORT).. Just to be sure.
Ok. All is now enabled and the behavior is the same.
>>> - Could you try the _same_ kernel config but disable CONFIG_X86_SYSFB.
>>> This will avoid creating simple-fb devices and instead load efifb
>>> again. Does efifb work? Does efifb print the same offsets as your
>>> simplefb printk()?
>>
>> Yeah, efifb works fine, I'll double-check everything and note down the offsets.
>
> Just to be clear, efifb still with the new x86-sysfb infrastructure
> works? Because I moved some efifb quirks from efifb.c to
> x86/kernel/sysfb_efi.c. So even with CONFIG_X86_SYSFB=n the situation
> is still different from pre-3.12.
Turns out I must have messed up my initial testing (maybe I only
tested with an old kernel on efifb). With the current kernel both
X86_SYSFB=y (i.e., simplefb) and X86_SYSFB=n (i.e., efifb) are broken.
Only when I log in and "modprobe i915" do I get an fbcon, before that
the screen is black.
For the record here is the relevant dmesg outputs (they appear to be ok):
efifb: probing for efifb
efifb: framebuffer at 0x90000000, mapped to 0xffffc90009b00000, using
4224k, total 4224k
efifb: mode is 1366x768x32, linelengthV32, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift$:16:8:0
simple-framebuffer simple-framebuffer.0: framebuffer at 0x90000000,
mapped to 0xffffc90009b00000
simple-framebuffer simple-framebuffer.0: format¨r8g8b8,
mode\x1366x768x32, linelengthV32
simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!
>>> - Are you sure that it's an simplefb problem? Please make sure fbcon
>>> is enabled (could you attach your dmesg output?). You could also try
>>> SSH'ing into the machine and starting some fbdev program (like X with
>>> xf86-video-fbdev installed). Or does fbcon with efifb work?
>>
>> fbcon with efifb works fine (so I guess trying X is not necessary?).
>
> Yeah, if fbcon+efifb works, no need to test X.
Scratch this, I'll have to do some more testing. I'll get back to you.
-t
^ permalink raw reply
* Re: [PATCH] simplefb: print some info about the registered fb
From: Stephen Warren @ 2013-09-06 19:11 UTC (permalink / raw)
To: Tom Gundersen
Cc: linux-fbdev, linux-kernel, tomi.valkeinen, plagnioj,
David Herrmann
In-Reply-To: <1378468153-1375-1-git-send-email-teg@jklm.no>
On 09/06/2013 05:49 AM, Tom Gundersen wrote:
> This is similar to the output printed by efifb.
Fine by me,
Acked-by: Stephen Warren <swarren@nvidia.com>
^ permalink raw reply
* Re: [PATCH] simplefb: print some info about the registered fb
From: David Herrmann @ 2013-09-07 11:16 UTC (permalink / raw)
To: Tom Gundersen
Cc: linux-fbdev@vger.kernel.org, linux-kernel, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Stephen Warren
In-Reply-To: <1378468153-1375-1-git-send-email-teg@jklm.no>
Hi Tom
On Fri, Sep 6, 2013 at 1:49 PM, Tom Gundersen <teg@jklm.no> wrote:
> This is similar to the output printed by efifb.
>
> Signed-off-by: Tom Gundersen <teg@jklm.no>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: David Herrmann <dh.herrmann@gmail.com>
> ---
>
> Hi,
>
> Sorry for the resend, got the ml address wrong.
>
> -t
>
> drivers/video/simplefb.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
> index 8d78106..4196686 100644
> --- a/drivers/video/simplefb.c
> +++ b/drivers/video/simplefb.c
> @@ -220,6 +220,14 @@ static int simplefb_probe(struct platform_device *pdev)
> }
> info->pseudo_palette = (void *)(info + 1);
>
> + dev_info(&pdev->dev, "framebuffer at 0x%lx, mapped to 0x%p\n",
> + info->fix.smem_start, info->screen_base);
Could we get smem_len, too? Something like:
dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%lx bytes, mapped
to 0x%p\n",
info->fix.smem_start, (unsigned
long)info->fix.smem_len, info->screen_base);
(smem_len is __u32, so cast it to avoid truncation if it's defined as
long somewhere. Not sure whether we actually have 16bit int somewhere,
though)
Cheers
David
> + dev_info(&pdev->dev, "format=%s, mode=%dx%dx%d, linelength=%d\n",
> + params.format->name,
> + info->var.xres, info->var.yres,
> + info->var.bits_per_pixel,
> + info->fix.line_length);
> +
> ret = register_framebuffer(info);
> if (ret < 0) {
> dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
> --
> 1.8.4
>
^ permalink raw reply
* [PATCH v2] simplefb: print some info about the registered fb
From: Tom Gundersen @ 2013-09-07 11:43 UTC (permalink / raw)
To: linux-fbdev
Cc: linux-kernel, tomi.valkeinen, plagnioj, Tom Gundersen,
David Herrmann
In-Reply-To: <CANq1E4Rxo3Az0hwCzzQyKz6z_uyVq-9bgAzNzm9StkWoAbkN_A@mail.gmail.com>
This is similar to the output printed by efifb.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
---
v2: also print smem_len as requested by David
drivers/video/simplefb.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index 8d78106..80cf074 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -220,6 +220,14 @@ static int simplefb_probe(struct platform_device *pdev)
}
info->pseudo_palette = (void *)(info + 1);
+ dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%lx bytes, mapped to 0x%p\n",
+ info->fix.smem_start, (unsigned long) info->fix.smem_len,
+ info->screen_base);
+ dev_info(&pdev->dev, "format=%s, mode=%dx%dx%d, linelength=%d\n",
+ params.format->name,
+ info->var.xres, info->var.yres,
+ info->var.bits_per_pixel, info->fix.line_length);
+
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
--
1.8.4
^ permalink raw reply related
* Re: [BUG] simplefb not showing any output
From: Tom Gundersen @ 2013-09-07 11:47 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
On Sat, Sep 7, 2013 at 1:18 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Sat, Sep 7, 2013 at 11:26 AM, Tom Gundersen <teg@jklm.no> wrote:
>> On Fri, Sep 6, 2013 at 6:11 PM, Tom Gundersen <teg@jklm.no> wrote:
>>> The driver seems to load ok, but sadly it does not give any output. If
>>> I boot via the gummiboot menu the screen remains black, and if I don't
>>> enter the gummiboot menu the screen remains grey (it is a Mac).
>>
>> My apologies, this was a config error (I somehow ended up with
>> FRAMEBUFFER_CONSOLE=m, which works fine with inteldrmfb, but obviously
>> not with any of the compiled in ones).
>
> Good, I almost went crazy looking for an error. Does that mean
> simplefb works for you?
Sorry about that! Yes, it now works.
> I guess the x86-sysfb patch is still needed?
Yes, that is still needed.
> Now I only wonder why the i915 issue showed up. Is it also solved with
> a built-in fbcon?
Sadly, no, that problem persists.
A related question: is it expected that simplefb should be
significantly slower than efifb, or is that something worth looking
into? My boot with simplefb is roughly five seconds slower than with
efifb. Coincidentally, I notice the same (or similar slowdown) with
inteldrmfb when I see the oops (but not otherwise).
Cheers,
Tom
^ permalink raw reply
* Re: [BUG] simplefb not showing any output
From: David Herrmann @ 2013-09-07 12:25 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4974 bytes --]
Hi Tom
On Sat, Sep 7, 2013 at 1:47 PM, Tom Gundersen <teg@jklm.no> wrote:
> On Sat, Sep 7, 2013 at 1:18 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> On Sat, Sep 7, 2013 at 11:26 AM, Tom Gundersen <teg@jklm.no> wrote:
>>> On Fri, Sep 6, 2013 at 6:11 PM, Tom Gundersen <teg@jklm.no> wrote:
>>>> The driver seems to load ok, but sadly it does not give any output. If
>>>> I boot via the gummiboot menu the screen remains black, and if I don't
>>>> enter the gummiboot menu the screen remains grey (it is a Mac).
>>>
>>> My apologies, this was a config error (I somehow ended up with
>>> FRAMEBUFFER_CONSOLE=m, which works fine with inteldrmfb, but obviously
>>> not with any of the compiled in ones).
>>
>> Good, I almost went crazy looking for an error. Does that mean
>> simplefb works for you?
>
> Sorry about that! Yes, it now works.
No worries. Going crazy is part of working on the kernel, I guess.
>> I guess the x86-sysfb patch is still needed?
>
> Yes, that is still needed.
Ok, I will keep watching it then.
>> Now I only wonder why the i915 issue showed up. Is it also solved with
>> a built-in fbcon?
>
> Sadly, no, that problem persists.
I will let Daniel know on IRC.
> A related question: is it expected that simplefb should be
> significantly slower than efifb, or is that something worth looking
> into? My boot with simplefb is roughly five seconds slower than with
> efifb. Coincidentally, I notice the same (or similar slowdown) with
> inteldrmfb when I see the oops (but not otherwise).
That is probably related to the missing write-combine tag in ioremap.
Stephen, any objections to this attached patch?
Tom, if this solves the speed-issues, I will send it out once I get home.
Thanks
David
(Patch also attached in case of new-lines issues)
From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
From: David Herrmann <dh.herrmann@gmail.com>
Date: Sat, 7 Sep 2013 14:22:01 +0200
Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
introduce it along the way. Note that ioremap_wc() is aliases to
ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
architectures to either provide it or use the same alias.
Reported-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
drivers/video/simplefb.c | 4 ++--
include/linux/io.h | 2 ++
lib/devres.c | 28 ++++++++++++++++++++++++++++
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index 8d78106..a29f1c4 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -212,8 +212,8 @@ static int simplefb_probe(struct platform_device *pdev)
info->fbops = &simplefb_ops;
info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
- info->screen_base = devm_ioremap(&pdev->dev, info->fix.smem_start,
- info->fix.smem_len);
+ info->screen_base = devm_ioremap_wc(&pdev->dev, info->fix.smem_start,
+ info->fix.smem_len);
if (!info->screen_base) {
framebuffer_release(info);
return -ENODEV;
diff --git a/include/linux/io.h b/include/linux/io.h
index f4f42fa..c529410 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -62,6 +62,8 @@ void __iomem *devm_ioremap(struct device *dev,
resource_size_t offset,
unsigned long size);
void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
unsigned long size);
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ unsigned long size);
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 8235331..34af7a9 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device
*dev, resource_size_t offset,
EXPORT_SYMBOL(devm_ioremap_nocache);
/**
+ * devm_ioremap_wc - Managed ioremap_wc()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_wc(). Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ unsigned long size)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_wc(offset, size);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_wc);
+
+/**
* devm_iounmap - Managed iounmap()
* @dev: Generic device to unmap for
* @addr: Address to unmap
--
1.8.4
[-- Attachment #2: 0001-devm-simplefb-introduce-and-use-devm_ioremap_wc.patch --]
[-- Type: application/octet-stream, Size: 3229 bytes --]
From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
From: David Herrmann <dh.herrmann@gmail.com>
Date: Sat, 7 Sep 2013 14:22:01 +0200
Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
introduce it along the way. Note that ioremap_wc() is aliases to
ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
architectures to either provide it or use the same alias.
Reported-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
drivers/video/simplefb.c | 4 ++--
include/linux/io.h | 2 ++
lib/devres.c | 28 ++++++++++++++++++++++++++++
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index 8d78106..a29f1c4 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -212,8 +212,8 @@ static int simplefb_probe(struct platform_device *pdev)
info->fbops = &simplefb_ops;
info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
- info->screen_base = devm_ioremap(&pdev->dev, info->fix.smem_start,
- info->fix.smem_len);
+ info->screen_base = devm_ioremap_wc(&pdev->dev, info->fix.smem_start,
+ info->fix.smem_len);
if (!info->screen_base) {
framebuffer_release(info);
return -ENODEV;
diff --git a/include/linux/io.h b/include/linux/io.h
index f4f42fa..c529410 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -62,6 +62,8 @@ void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
unsigned long size);
void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
unsigned long size);
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ unsigned long size);
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 8235331..34af7a9 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
EXPORT_SYMBOL(devm_ioremap_nocache);
/**
+ * devm_ioremap_wc - Managed ioremap_wc()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_wc(). Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ unsigned long size)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_wc(offset, size);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_wc);
+
+/**
* devm_iounmap - Managed iounmap()
* @dev: Generic device to unmap for
* @addr: Address to unmap
--
1.8.4
^ permalink raw reply related
* Re: [BUG] simplefb not showing any output
From: Tom Gundersen @ 2013-09-07 13:02 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
On Sat, Sep 7, 2013 at 2:25 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Sat, Sep 7, 2013 at 1:47 PM, Tom Gundersen <teg@jklm.no> wrote:
>> A related question: is it expected that simplefb should be
>> significantly slower than efifb, or is that something worth looking
>> into? My boot with simplefb is roughly five seconds slower than with
>> efifb. Coincidentally, I notice the same (or similar slowdown) with
>> inteldrmfb when I see the oops (but not otherwise).
>
> That is probably related to the missing write-combine tag in ioremap.
> Stephen, any objections to this attached patch?
> Tom, if this solves the speed-issues, I will send it out once I get home.
This solves the speed issues. Thanks!
Feel free to add my tested-by.
Cheers,
Tom
> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
> From: David Herrmann <dh.herrmann@gmail.com>
> Date: Sat, 7 Sep 2013 14:22:01 +0200
> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
>
> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
> introduce it along the way. Note that ioremap_wc() is aliases to
> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
> architectures to either provide it or use the same alias.
>
> Reported-by: Tom Gundersen <teg@jklm.no>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
> drivers/video/simplefb.c | 4 ++--
> include/linux/io.h | 2 ++
> lib/devres.c | 28 ++++++++++++++++++++++++++++
> 3 files changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
> index 8d78106..a29f1c4 100644
> --- a/drivers/video/simplefb.c
> +++ b/drivers/video/simplefb.c
> @@ -212,8 +212,8 @@ static int simplefb_probe(struct platform_device *pdev)
>
> info->fbops = &simplefb_ops;
> info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
> - info->screen_base = devm_ioremap(&pdev->dev, info->fix.smem_start,
> - info->fix.smem_len);
> + info->screen_base = devm_ioremap_wc(&pdev->dev, info->fix.smem_start,
> + info->fix.smem_len);
> if (!info->screen_base) {
> framebuffer_release(info);
> return -ENODEV;
> diff --git a/include/linux/io.h b/include/linux/io.h
> index f4f42fa..c529410 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -62,6 +62,8 @@ void __iomem *devm_ioremap(struct device *dev,
> resource_size_t offset,
> unsigned long size);
> void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
> unsigned long size);
> +void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
> + unsigned long size);
> void devm_iounmap(struct device *dev, void __iomem *addr);
> int check_signature(const volatile void __iomem *io_addr,
> const unsigned char *signature, int length);
> diff --git a/lib/devres.c b/lib/devres.c
> index 8235331..34af7a9 100644
> --- a/lib/devres.c
> +++ b/lib/devres.c
> @@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device
> *dev, resource_size_t offset,
> EXPORT_SYMBOL(devm_ioremap_nocache);
>
> /**
> + * devm_ioremap_wc - Managed ioremap_wc()
> + * @dev: Generic device to remap IO address for
> + * @offset: BUS offset to map
> + * @size: Size of map
> + *
> + * Managed ioremap_wc(). Map is automatically unmapped on driver detach.
> + */
> +void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
> + unsigned long size)
> +{
> + void __iomem **ptr, *addr;
> +
> + ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr)
> + return NULL;
> +
> + addr = ioremap_wc(offset, size);
> + if (addr) {
> + *ptr = addr;
> + devres_add(dev, ptr);
> + } else
> + devres_free(ptr);
> +
> + return addr;
> +}
> +EXPORT_SYMBOL(devm_ioremap_wc);
> +
> +/**
> * devm_iounmap - Managed iounmap()
> * @dev: Generic device to unmap for
> * @addr: Address to unmap
> --
> 1.8.4
^ permalink raw reply
* Re: [PATCH v2] simplefb: print some info about the registered fb
From: Geert Uytterhoeven @ 2013-09-07 13:55 UTC (permalink / raw)
To: Tom Gundersen
Cc: Linux Fbdev development list, linux-kernel@vger.kernel.org,
Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD, David Herrmann
In-Reply-To: <1378554210-943-1-git-send-email-teg@jklm.no>
On Sat, Sep 7, 2013 at 1:43 PM, Tom Gundersen <teg@jklm.no> wrote:
> + dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%lx bytes, mapped to 0x%p\n",
> + info->fix.smem_start, (unsigned long) info->fix.smem_len,
Please drop the cast, and use 0x%x. __u32 is unsigned int everywhere (where it
matters --- we don't do 16-bit ints).
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
^ permalink raw reply
* [PATCH v3] simplefb: print some info about the registered fb
From: Tom Gundersen @ 2013-09-07 14:08 UTC (permalink / raw)
To: linux-fbdev
Cc: linux-kernel, tomi.valkeinen, plagnioj, Tom Gundersen,
David Herrmann
In-Reply-To: <CAMuHMdXDAA3PgbgNrccStUZGByDXuSsMG_yJMwwUWXwMvyOfsA@mail.gmail.com>
This is similar to the output printed by efifb.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
---
v2: also print smem_len, as requested by David
v3: don't cast, as requested by Geert
drivers/video/simplefb.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index a29f1c4..50cbceb 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -220,6 +220,14 @@ static int simplefb_probe(struct platform_device *pdev)
}
info->pseudo_palette = (void *)(info + 1);
+ dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
+ info->fix.smem_start, info->fix.smem_len,
+ info->screen_base);
+ dev_info(&pdev->dev, "format=%s, mode=%dx%dx%d, linelength=%d\n",
+ params.format->name,
+ info->var.xres, info->var.yres,
+ info->var.bits_per_pixel, info->fix.line_length);
+
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
--
1.8.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox