* 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
* [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
* [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
* 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
* 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
* [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 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
* 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: [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: 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
* [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
* [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
* Re: [RFC 00/22] OMAPDSS: DT support
From: Tony Lindgren @ 2013-09-04 17:20 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Laurent Pinchart, Nishanth Menon, Felipe Balbi, Santosh Shilimkar
In-Reply-To: <52243362.3090905@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130901 23:50]:
> On 02/09/13 09:15, Tony Lindgren wrote:
> >
> > Yes but the old bindings still need to be supported because people
> > are doing devices using those. So any kind of temporary binding will be
> > a pain to support.
>
> If old bindings need to be supported, then we also need to support the
> current state for Panda and SDP, i.e. there are no DSS related DT
> bindings, but displays still work. Which means we'll have to keep the
> current hacky DSS device construction mechanism for Panda and SDP.
Yes we want to keep things working for the users where possible and
not cause regressions. At least some kind of output about what the
user needs to do to update to latest kernel and some documentation
is would be needed..
> Although maybe it's cleaner to somehow inject the DSS DT nodes for Panda
> and SDP in case they are missing from the real DT data.
.. but naturally that would certainly make users life easier :)
> Doesn't supporting old bindings also mean that we can never get rid of
> the hwmods? Or will there be code that injects the missing interrupt
> etc. entries?
I certainly hope we won't be stuck with that and can define most of
the hwmod related data in the .dts files. We should be able to
provide at least some debug output so users know what needs to
be done to upgrade.
But yeah, if there were popular devices with the .dtb in ROM using
the legacy hwmod binding, then we'd be stuck with building or generating
the data in the kernel. Or load the data later on via /lib/firmware and
let deferred probe deal with it.
> >> Well, one difference is that the temporary bindings would give us
> >> working display, but having only basic bindings would not. So I don't
> >> see any reason to add only the basic bindings. Or how would it work?
> >
> > You might be able to use just a minimal binding for now using the
> > basic reg, interrupt and entries for the various components. Those will
> > be still valid when the CDF bindings are available.
>
> Well, the entries will be valid, but the displays won't work with just
> the basic bindings. I could perhaps add a new hack that creates the
> required panel devices and video pipeline connections dynamically in
> code for Panda and SDP, a bit like what the code does now, except the
> basic DSS entries would be in the DT. But that would just add another
> set of DT data that I would need to support in the future, and there
> would be three different cases to support for Panda and SDP:
>
> - DT data with no DSS related nodes
> - DT data with basic DSS related nodes
> - DT data with full DSS
>
> So... If old bindings have to be supported, I'd rather try to minimize
> the pain, and not add anything but the final bindings. In retrospect, it
> was a bit of a mistake to add the hacky DT display support for Panda and
> SDP, as it won't be very nice to keep supporting those.
Yes if that just makes things more complex, it's probably best to work
on getting the generic binding done instead.
Or just rely on getting the configuration from kernel cmdline and always
use just the basic bindings? That might help keep things working for
the "DT data with no DSS related nodes" case?
Regards,
Tony
Regards,
Tony
^ permalink raw reply
* [RFC PATCH] amba: Ensure drvdata is NULL
From: Michal Simek @ 2013-09-04 14:44 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 7224 bytes --]
This patch is inpired by the patch for drvdata
"device-core: Ensure drvdata = NULL when no driver is bound"
(sha1: 0998d0631001288a5974afc0b2a5f568bcdecb4d)
Also it fixes all occurences in drivers.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
arch/arm/kernel/etm.c | 6 ------
drivers/amba/bus.c | 2 ++
drivers/dma/pl330.c | 3 ---
drivers/input/serio/ambakmi.c | 2 --
drivers/mmc/host/mmci.c | 2 --
drivers/rtc/rtc-pl030.c | 2 --
drivers/rtc/rtc-pl031.c | 2 --
drivers/spi/spi-pl022.c | 1 -
drivers/tty/serial/amba-pl010.c | 3 ---
drivers/tty/serial/amba-pl011.c | 3 ---
drivers/video/amba-clcd.c | 2 --
drivers/watchdog/sp805_wdt.c | 1 -
12 files changed, 2 insertions(+), 27 deletions(-)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index 8ff0ecd..131a6ab 100644
--- a/arch/arm/kernel/etm.c
+++ b/arch/arm/kernel/etm.c
@@ -385,7 +385,6 @@ out:
return ret;
out_unmap:
- amba_set_drvdata(dev, NULL);
iounmap(t->etb_regs);
out_release:
@@ -398,8 +397,6 @@ static int etb_remove(struct amba_device *dev)
{
struct tracectx *t = amba_get_drvdata(dev);
- amba_set_drvdata(dev, NULL);
-
iounmap(t->etb_regs);
t->etb_regs = NULL;
@@ -588,7 +585,6 @@ out:
return ret;
out_unmap:
- amba_set_drvdata(dev, NULL);
iounmap(t->etm_regs);
out_release:
@@ -601,8 +597,6 @@ static int etm_remove(struct amba_device *dev)
{
struct tracectx *t = amba_get_drvdata(dev);
- amba_set_drvdata(dev, NULL);
-
iounmap(t->etm_regs);
t->etm_regs = NULL;
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index c670727..9762090 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -373,6 +373,7 @@ static int amba_probe(struct device *dev)
if (ret == 0)
break;
+ amba_set_drvdata(pcdev, NULL);
pm_runtime_disable(dev);
pm_runtime_set_suspended(dev);
pm_runtime_put_noidle(dev);
@@ -391,6 +392,7 @@ static int amba_remove(struct device *dev)
pm_runtime_get_sync(dev);
ret = drv->remove(pcdev);
+ amba_set_drvdata(pcdev, NULL);
pm_runtime_put_noidle(dev);
/* Undo the runtime PM settings in amba_probe() */
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index fa645d8..626f99e 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -3026,8 +3026,6 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
return 0;
probe_err3:
- amba_set_drvdata(adev, NULL);
-
/* Idle the DMAC */
list_for_each_entry_safe(pch, _p, &pdmac->ddma.channels,
chan.device_node) {
@@ -3061,7 +3059,6 @@ static int pl330_remove(struct amba_device *adev)
of_dma_controller_free(adev->dev.of_node);
dma_async_device_unregister(&pdmac->ddma);
- amba_set_drvdata(adev, NULL);
/* Idle the DMAC */
list_for_each_entry_safe(pch, _p, &pdmac->ddma.channels,
diff --git a/drivers/input/serio/ambakmi.c b/drivers/input/serio/ambakmi.c
index 4e2fd44..b7c206d 100644
--- a/drivers/input/serio/ambakmi.c
+++ b/drivers/input/serio/ambakmi.c
@@ -167,8 +167,6 @@ static int amba_kmi_remove(struct amba_device *dev)
{
struct amba_kmi_port *kmi = amba_get_drvdata(dev);
- amba_set_drvdata(dev, NULL);
-
serio_unregister_port(kmi->io);
clk_put(kmi->clk);
iounmap(kmi->base);
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index c3785ed..07e17f1 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1678,8 +1678,6 @@ static int mmci_remove(struct amba_device *dev)
{
struct mmc_host *mmc = amba_get_drvdata(dev);
- amba_set_drvdata(dev, NULL);
-
if (mmc) {
struct mmci_host *host = mmc_priv(mmc);
diff --git a/drivers/rtc/rtc-pl030.c b/drivers/rtc/rtc-pl030.c
index 22bacdb..a804f75 100644
--- a/drivers/rtc/rtc-pl030.c
+++ b/drivers/rtc/rtc-pl030.c
@@ -153,8 +153,6 @@ static int pl030_remove(struct amba_device *dev)
{
struct pl030_rtc *rtc = amba_get_drvdata(dev);
- amba_set_drvdata(dev, NULL);
-
writel(0, rtc->base + RTC_CR);
free_irq(dev->irq[0], rtc);
diff --git a/drivers/rtc/rtc-pl031.c b/drivers/rtc/rtc-pl031.c
index 0f0609b..c9ca86e 100644
--- a/drivers/rtc/rtc-pl031.c
+++ b/drivers/rtc/rtc-pl031.c
@@ -305,7 +305,6 @@ static int pl031_remove(struct amba_device *adev)
{
struct pl031_local *ldata = dev_get_drvdata(&adev->dev);
- amba_set_drvdata(adev, NULL);
free_irq(adev->irq[0], ldata);
rtc_device_unregister(ldata->rtc);
iounmap(ldata->base);
@@ -392,7 +391,6 @@ out_no_irq:
rtc_device_unregister(ldata->rtc);
out_no_rtc:
iounmap(ldata->base);
- amba_set_drvdata(adev, NULL);
out_no_remap:
kfree(ldata);
out:
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index abef061..e12813e 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2306,7 +2306,6 @@ pl022_remove(struct amba_device *adev)
amba_release_regions(adev);
tasklet_disable(&pl022->pump_transfers);
spi_unregister_master(pl022->master);
- amba_set_drvdata(adev, NULL);
return 0;
}
diff --git a/drivers/tty/serial/amba-pl010.c b/drivers/tty/serial/amba-pl010.c
index c368405..f630b78 100644
--- a/drivers/tty/serial/amba-pl010.c
+++ b/drivers/tty/serial/amba-pl010.c
@@ -728,7 +728,6 @@ static int pl010_probe(struct amba_device *dev, const struct amba_id *id)
amba_set_drvdata(dev, uap);
ret = uart_add_one_port(&amba_reg, &uap->port);
if (ret) {
- amba_set_drvdata(dev, NULL);
amba_ports[i] = NULL;
clk_put(uap->clk);
unmap:
@@ -745,8 +744,6 @@ static int pl010_remove(struct amba_device *dev)
struct uart_amba_port *uap = amba_get_drvdata(dev);
int i;
- amba_set_drvdata(dev, NULL);
-
uart_remove_one_port(&amba_reg, &uap->port);
for (i = 0; i < ARRAY_SIZE(amba_ports); i++)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 28b35ad..2a1efe0 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2143,7 +2143,6 @@ static int pl011_probe(struct amba_device *dev, const struct amba_id *id)
amba_set_drvdata(dev, uap);
ret = uart_add_one_port(&amba_reg, &uap->port);
if (ret) {
- amba_set_drvdata(dev, NULL);
amba_ports[i] = NULL;
pl011_dma_remove(uap);
}
@@ -2156,8 +2155,6 @@ static int pl011_remove(struct amba_device *dev)
struct uart_amba_port *uap = amba_get_drvdata(dev);
int i;
- amba_set_drvdata(dev, NULL);
-
uart_remove_one_port(&amba_reg, &uap->port);
for (i = 0; i < ARRAY_SIZE(amba_ports); i++)
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..0bab6ab 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -594,8 +594,6 @@ static int clcdfb_remove(struct amba_device *dev)
{
struct clcd_fb *fb = amba_get_drvdata(dev);
- amba_set_drvdata(dev, NULL);
-
clcdfb_disable(fb);
unregister_framebuffer(&fb->fb);
if (fb->fb.cmap.len)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index 58df98a..3f786ce 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -268,7 +268,6 @@ static int sp805_wdt_remove(struct amba_device *adev)
struct sp805_wdt *wdt = amba_get_drvdata(adev);
watchdog_unregister_device(&wdt->wdd);
- amba_set_drvdata(adev, NULL);
watchdog_set_drvdata(&wdt->wdd, NULL);
return 0;
--
1.8.2.3
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [PATCH/RFC v3 06/19] video: display: OF support
From: Philipp Zabel @ 2013-09-04 14:21 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: dri-devel, linux-fbdev, linux-media
In-Reply-To: <1376089398-13322-7-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Hi Laurent,
Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
> Extend the notifier with DT node matching support, and add helper functions to
> build the notifier and link entities based on a graph representation in
> DT.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> drivers/video/display/display-core.c | 334 +++++++++++++++++++++++++++++++
> drivers/video/display/display-notifier.c | 187 +++++++++++++++++
> include/video/display.h | 45 +++++
> 3 files changed, 566 insertions(+)
>
> diff --git a/drivers/video/display/display-core.c b/drivers/video/display/display-core.c
> index c3b47d3..328ead7 100644
> --- a/drivers/video/display/display-core.c
> +++ b/drivers/video/display/display-core.c
[...]
> @@ -420,6 +599,161 @@ int display_entity_link_graph(struct device *dev, struct list_head *entities)
> }
> EXPORT_SYMBOL_GPL(display_entity_link_graph);
>
> +#ifdef CONFIG_OF
> +
> +static int display_of_entity_link_entity(struct device *dev,
> + struct display_entity *entity,
> + struct list_head *entities,
> + struct display_entity *root)
> +{
> + u32 link_flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
> + const struct device_node *node = entity->dev->of_node;
the current device tree matching implementation only allows one display
entity per linux device. How about adding an of_node pointer to struct
display_entity directly and allow multiple display entity nodes below in
a single device node in the device tree?
lvds-encoder {
channel@0 {
port@0 {
lvds0_input: endpoint {
};
};
port@1 {
lvds0_output: endpoint {
};
};
};
channel@1 {
port@0 {
lvds1_input: endpoint {
};
};
lvds1: port@1 {
lvds1_output: endpoint {
};
};
};
};
> + struct media_entity *local = &entity->entity;
> + struct device_node *ep = NULL;
> + int ret = 0;
> +
> + dev_dbg(dev, "creating links for entity %s\n", local->name);
> +
> + while (1) {
> + struct media_entity *remote = NULL;
> + struct media_pad *remote_pad;
> + struct media_pad *local_pad;
> + struct display_of_link link;
> + struct display_entity *ent;
> + struct device_node *next;
> +
> + /* Get the next endpoint and parse its link. */
> + next = display_of_get_next_endpoint(node, ep);
> + if (next = NULL)
> + break;
> +
> + of_node_put(ep);
> + ep = next;
> +
> + dev_dbg(dev, "processing endpoint %s\n", ep->full_name);
> +
> + ret = display_of_parse_link(ep, &link);
> + if (ret < 0) {
> + dev_err(dev, "failed to parse link for %s\n",
> + ep->full_name);
> + continue;
> + }
> +
> + /* Skip source pads, they will be processed from the other end of
> + * the link.
> + */
> + if (link.local_port >= local->num_pads) {
> + dev_err(dev, "invalid port number %u on %s\n",
> + link.local_port, link.local_node->full_name);
> + display_of_put_link(&link);
> + ret = -EINVAL;
> + break;
> + }
> +
> + local_pad = &local->pads[link.local_port];
> +
> + if (local_pad->flags & MEDIA_PAD_FL_SOURCE) {
> + dev_dbg(dev, "skipping source port %s:%u\n",
> + link.local_node->full_name, link.local_port);
> + display_of_put_link(&link);
> + continue;
> + }
> +
> + /* Find the remote entity. If not found, just skip the link as
> + * it goes out of scope of the entities handled by the notifier.
> + */
> + list_for_each_entry(ent, entities, list) {
> + if (ent->dev->of_node = link.remote_node) {
> + remote = &ent->entity;
> + break;
> + }
> + }
> +
> + if (root->dev->of_node = link.remote_node)
> + remote = &root->entity;
> +
> + if (remote = NULL) {
> + dev_dbg(dev, "no entity found for %s\n",
> + link.remote_node->full_name);
> + display_of_put_link(&link);
> + continue;
> + }
> +
> + if (link.remote_port >= remote->num_pads) {
> + dev_err(dev, "invalid port number %u on %s\n",
> + link.remote_port, link.remote_node->full_name);
> + display_of_put_link(&link);
> + ret = -EINVAL;
> + break;
> + }
> +
> + remote_pad = &remote->pads[link.remote_port];
> +
> + display_of_put_link(&link);
> +
> + /* Create the media link. */
> + dev_dbg(dev, "creating %s:%u -> %s:%u link\n",
> + remote->name, remote_pad->index,
> + local->name, local_pad->index);
> +
> + ret = media_entity_create_link(remote, remote_pad->index,
> + local, local_pad->index,
> + link_flags);
> + if (ret < 0) {
> + dev_err(dev,
> + "failed to create %s:%u -> %s:%u link\n",
> + remote->name, remote_pad->index,
> + local->name, local_pad->index);
> + break;
> + }
> + }
> +
> + of_node_put(ep);
> + return ret;
> +}
[...]
For example like this:
diff --git a/drivers/video/display/display-core.c b/drivers/video/display/display-core.c
index 7910c23..a04feed 100644
--- a/drivers/video/display/display-core.c
+++ b/drivers/video/display/display-core.c
@@ -302,6 +302,9 @@ int display_entity_init(struct display_entity *entity, unsigned int num_sinks,
kref_init(&entity->ref);
entity->state = DISPLAY_ENTITY_STATE_OFF;
+ if (!entity->of_node && entity->dev)
+ entity->of_node = entity->dev->of_node;
+
num_pads = num_sinks + num_sources;
pads = kzalloc(sizeof(*pads) * num_pads, GFP_KERNEL);
if (pads = NULL)
@@ -665,7 +668,7 @@ static int display_of_entity_link_entity(struct device *dev,
struct display_entity *root)
{
u32 link_flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
- const struct device_node *node = entity->dev->of_node;
+ const struct device_node *node = entity->of_node;
struct media_entity *local = &entity->entity;
struct device_node *ep = NULL;
int num_sink, ret = 0;
@@ -727,13 +730,13 @@ static int display_of_entity_link_entity(struct device *dev,
* it goes out of scope of the entities handled by the notifier.
*/
list_for_each_entry(ent, entities, list) {
- if (ent->dev->of_node = link.remote_node) {
+ if (ent->of_node = link.remote_node) {
remote = &ent->entity;
break;
}
}
- if (root && root->dev->of_node = link.remote_node)
+ if (root && root->of_node = link.remote_node)
remote = &root->entity;
if (remote = NULL) {
diff --git a/drivers/video/display/display-notifier.c b/drivers/video/display/display-notifier.c
index a3998c7..d0da6e5 100644
--- a/drivers/video/display/display-notifier.c
+++ b/drivers/video/display/display-notifier.c
@@ -28,28 +28,30 @@ static DEFINE_MUTEX(display_entity_mutex);
* Notifiers
*/
-static bool match_platform(struct device *dev,
+static bool match_platform(struct display_entity *entity,
struct display_entity_match *match)
{
pr_debug("%s: matching device '%s' with name '%s'\n", __func__,
- dev_name(dev), match->match.platform.name);
+ dev_name(entity->dev), match->match.platform.name);
- return !strcmp(match->match.platform.name, dev_name(dev));
+ return !strcmp(match->match.platform.name, dev_name(entity->dev));
}
-static bool match_dt(struct device *dev, struct display_entity_match *match)
+static bool match_dt(struct display_entity *entity,
+ struct display_entity_match *match)
{
pr_debug("%s: matching device node '%s' with node '%s'\n", __func__,
- dev->of_node->full_name, match->match.dt.node->full_name);
+ entity->of_node->full_name, match->match.dt.node->full_name);
- return match->match.dt.node = dev->of_node;
+ return match->match.dt.node = entity->of_node;
}
static struct display_entity_match *
display_entity_notifier_match(struct display_entity_notifier *notifier,
struct display_entity *entity)
{
- bool (*match_func)(struct device *, struct display_entity_match *);
+ bool (*match_func)(struct display_entity *,
+ struct display_entity_match *);
struct display_entity_match *match;
pr_debug("%s: matching entity '%s' (ptr 0x%p dev '%s')\n", __func__,
@@ -66,7 +68,7 @@ display_entity_notifier_match(struct display_entity_notifier *notifier,
break;
}
- if (match_func(entity->dev, match))
+ if (match_func(entity, match))
return match;
}
diff --git a/include/video/display.h b/include/video/display.h
index 4c402bee..d1f8833 100644
--- a/include/video/display.h
+++ b/include/video/display.h
@@ -228,6 +228,7 @@ struct display_entity {
struct list_head list;
struct device *dev;
struct module *owner;
+ struct device_node *of_node;
struct kref ref;
char name[32];
--
1.8.4.rc3
regards
Philipp
^ permalink raw reply related
* [PATCH 2/2] mm/driver: use __free_reserved_page() to simplify the code
From: Xishi Qiu @ 2013-09-04 10:41 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, james.hogan, monstr, benh, paulus,
Andrew Morton
Cc: Xishi Qiu, microblaze-uclinux, linuxppc-dev, linux-fbdev, LKML,
linux-mm
Use __free_reserved_page() to simplify the code in the others.
Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
---
drivers/video/acornfb.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/video/acornfb.c b/drivers/video/acornfb.c
index 6488a73..4ef302a 100644
--- a/drivers/video/acornfb.c
+++ b/drivers/video/acornfb.c
@@ -1205,9 +1205,7 @@ free_unused_pages(unsigned int virtual_start, unsigned int virtual_end)
* the page.
*/
page = virt_to_page(virtual_start);
- ClearPageReserved(page);
- init_page_count(page);
- free_page(virtual_start);
+ __free_reserved_page(page);
virtual_start += PAGE_SIZE;
mb_freed += PAGE_SIZE / 1024;
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] mm/arch: use __free_reserved_page() to simplify the code
From: Xishi Qiu @ 2013-09-04 10:41 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, james.hogan, monstr, benh, paulus,
Andrew Morton
Cc: Xishi Qiu, microblaze-uclinux, linuxppc-dev, linux-fbdev, LKML,
linux-mm
Use __free_reserved_page() to simplify the code in arch.
It used split_page() in consistent_alloc()/__dma_alloc_coherent()/dma_alloc_coherent(),
so page->_count = 1, and we can free it safely.
__free_reserved_page()
ClearPageReserved()
init_page_count() // it won't change the value
__free_page()
Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
---
arch/metag/kernel/dma.c | 4 +---
arch/microblaze/mm/consistent.c | 7 ++-----
arch/powerpc/mm/dma-noncoherent.c | 4 +---
3 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/arch/metag/kernel/dma.c b/arch/metag/kernel/dma.c
index 8c00ded..db589ad 100644
--- a/arch/metag/kernel/dma.c
+++ b/arch/metag/kernel/dma.c
@@ -305,9 +305,7 @@ void dma_free_coherent(struct device *dev, size_t size,
if (pfn_valid(pfn)) {
struct page *page = pfn_to_page(pfn);
- ClearPageReserved(page);
-
- __free_page(page);
+ __free_reserved_page(page);
continue;
}
}
diff --git a/arch/microblaze/mm/consistent.c b/arch/microblaze/mm/consistent.c
index 5226b09..dbbf224 100644
--- a/arch/microblaze/mm/consistent.c
+++ b/arch/microblaze/mm/consistent.c
@@ -176,8 +176,7 @@ void consistent_free(size_t size, void *vaddr)
page = virt_to_page(vaddr);
do {
- ClearPageReserved(page);
- __free_page(page);
+ __free_reserved_page(page);
page++;
} while (size -= PAGE_SIZE);
#else
@@ -194,9 +193,7 @@ void consistent_free(size_t size, void *vaddr)
pte_clear(&init_mm, (unsigned int)vaddr, ptep);
if (pfn_valid(pfn)) {
page = pfn_to_page(pfn);
-
- ClearPageReserved(page);
- __free_page(page);
+ __free_reserved_page(page);
}
}
vaddr += PAGE_SIZE;
diff --git a/arch/powerpc/mm/dma-noncoherent.c b/arch/powerpc/mm/dma-noncoherent.c
index 6747eec..7b6c107 100644
--- a/arch/powerpc/mm/dma-noncoherent.c
+++ b/arch/powerpc/mm/dma-noncoherent.c
@@ -287,9 +287,7 @@ void __dma_free_coherent(size_t size, void *vaddr)
pte_clear(&init_mm, addr, ptep);
if (pfn_valid(pfn)) {
struct page *page = pfn_to_page(pfn);
-
- ClearPageReserved(page);
- __free_page(page);
+ __free_reserved_page(page);
}
}
addr += PAGE_SIZE;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v3 0/5] ARM: vf610: Add DCU framebuffer driver for Vybrid VF610 platform
From: Tomi Valkeinen @ 2013-09-04 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <81BA6E5E0BC2344391CABCEE22D1B6D8403CB3@039-SN1MPN1-002.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
Hi,
On 03/09/13 11:21, Wang Huan-B18965 wrote:
> Hi, Jean-Christophe, Tomi,
>
> Could you please help to review these patches?
> Thanks!
There seemed to be some strong opinions that there should be a drm
driver for this hardware, instead of an fb driver. So as there seems to
be disagreements about this, I'll leave this series to Jean-Christophe,
who's the primary maintainer.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [PATCH] add bochs dispi interface framebuffer driver
From: Gerd Hoffmann @ 2013-09-04 9:54 UTC (permalink / raw)
Cc: Gerd Hoffmann, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
open list, open list:FRAMEBUFFER LAYER
This patchs adds a frame buffer driver for (virtual/emulated) vga cards
implementing the bochs dispi interface. Supported hardware are the
bochs vga card with vbe extension and the qemu standard vga.
The driver uses a fixed depth of 32bpp. Otherwise it supports the full
(but small) feature set of the bochs dispi interface: Resolution
switching and display panning. It is tweaked to maximize fbcon speed,
so you'll get the comfort of the framebuffer console in kvm guests
without performance penalty.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/video/Kconfig | 18 ++
drivers/video/Makefile | 1 +
drivers/video/bochsfb.c | 460 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 479 insertions(+)
create mode 100644 drivers/video/bochsfb.c
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4cf1e1d..3f0ead4 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -284,6 +284,24 @@ config FB_CIRRUS
Say N unless you have such a graphics board or plan to get one
before you next recompile the kernel.
+config FB_BOCHS
+ tristate "Bochs dispi interface support"
+ depends on FB && PCI
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ ---help---
+ This is the frame buffer driver for (virtual/emulated) vga
+ cards implementing the bochs dispi interface. Supported
+ hardware are the bochs vga card with vbe extension and the
+ qemu standard vga.
+
+ The driver handles the PCI variants only. It uses a fixed
+ depth of 32bpp, anything else doesn't make sense these days.
+
+ Say Y here if you plan to run the kernel in a virtual machine
+ emulated by bochs or qemu.
+
config FB_PM2
tristate "Permedia2 support"
depends on FB && ((AMIGA && BROKEN) || PCI)
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index e8bae8d..a946a36 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -103,6 +103,7 @@ obj-$(CONFIG_FB_GOLDFISH) += goldfishfb.o
obj-$(CONFIG_FB_68328) += 68328fb.o
obj-$(CONFIG_FB_GBE) += gbefb.o
obj-$(CONFIG_FB_CIRRUS) += cirrusfb.o
+obj-$(CONFIG_FB_BOCHS) += bochsfb.o
obj-$(CONFIG_FB_ASILIANT) += asiliantfb.o
obj-$(CONFIG_FB_PXA) += pxafb.o
obj-$(CONFIG_FB_PXA168) += pxa168fb.o
diff --git a/drivers/video/bochsfb.c b/drivers/video/bochsfb.c
new file mode 100644
index 0000000..b31472e
--- /dev/null
+++ b/drivers/video/bochsfb.c
@@ -0,0 +1,460 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+#include <linux/mm.h>
+#include <linux/vmalloc.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/fb.h>
+#include <linux/pm.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <linux/console.h>
+#include <asm/io.h>
+
+#define VBE_DISPI_IOPORT_INDEX 0x01CE
+#define VBE_DISPI_IOPORT_DATA 0x01CF
+
+#define VBE_DISPI_INDEX_ID 0x0
+#define VBE_DISPI_INDEX_XRES 0x1
+#define VBE_DISPI_INDEX_YRES 0x2
+#define VBE_DISPI_INDEX_BPP 0x3
+#define VBE_DISPI_INDEX_ENABLE 0x4
+#define VBE_DISPI_INDEX_BANK 0x5
+#define VBE_DISPI_INDEX_VIRT_WIDTH 0x6
+#define VBE_DISPI_INDEX_VIRT_HEIGHT 0x7
+#define VBE_DISPI_INDEX_X_OFFSET 0x8
+#define VBE_DISPI_INDEX_Y_OFFSET 0x9
+#define VBE_DISPI_INDEX_VIDEO_MEMORY_64K 0xa
+
+#define VBE_DISPI_ID0 0xB0C0
+#define VBE_DISPI_ID1 0xB0C1
+#define VBE_DISPI_ID2 0xB0C2
+#define VBE_DISPI_ID3 0xB0C3
+#define VBE_DISPI_ID4 0xB0C4
+#define VBE_DISPI_ID5 0xB0C5
+
+#define VBE_DISPI_DISABLED 0x00
+#define VBE_DISPI_ENABLED 0x01
+#define VBE_DISPI_GETCAPS 0x02
+#define VBE_DISPI_8BIT_DAC 0x20
+#define VBE_DISPI_LFB_ENABLED 0x40
+#define VBE_DISPI_NOCLEARMEM 0x80
+
+enum bochs_types {
+ BOCHS_QEMU_STDVGA,
+ BOCHS_UNKNOWN,
+};
+
+static const char *bochs_names[] = {
+ [ BOCHS_QEMU_STDVGA ] = "QEMU standard vga",
+ [ BOCHS_UNKNOWN ] = "unknown",
+};
+
+struct bochs_par {
+ void __iomem *mmio;
+ int ioports;
+};
+
+static struct fb_fix_screeninfo bochsfb_fix = {
+ .id = "bochsfb",
+ .type = FB_TYPE_PACKED_PIXELS,
+ .visual = FB_VISUAL_TRUECOLOR,
+ .accel = FB_ACCEL_NONE,
+ .xpanstep = 1,
+ .ypanstep = 1,
+};
+
+static struct fb_var_screeninfo bochsfb_var = {
+ .xres = 1024,
+ .yres = 768,
+ .bits_per_pixel = 32,
+#ifdef __BIG_ENDIAN
+ .transp = { .length = 8, .offset = 0 },
+ .red = { .length = 8, .offset = 8 },
+ .green = { .length = 8, .offset = 16 },
+ .blue = { .length = 8, .offset = 24 },
+#else
+ .transp = { .length = 8, .offset = 24 },
+ .red = { .length = 8, .offset = 16 },
+ .green = { .length = 8, .offset = 8 },
+ .blue = { .length = 8, .offset = 0 },
+#endif
+ .height = -1,
+ .width = -1,
+ .vmode = FB_VMODE_NONINTERLACED,
+ .pixclock = 10000,
+ .left_margin = 16,
+ .right_margin = 16,
+ .upper_margin = 16,
+ .lower_margin = 16,
+ .hsync_len = 8,
+ .vsync_len = 8,
+};
+
+static char *mode;
+module_param(mode, charp, 0);
+MODULE_PARM_DESC(mode, "Initial video mode, default is '1024x768'");
+
+static u16 bochs_read(struct fb_info *info, u16 reg)
+{
+ struct bochs_par *bochs = info->par;
+ u16 ret = 0;
+
+ if (bochs->mmio) {
+ int offset = 0x500 + (reg << 1);
+ ret = readw(bochs->mmio + offset);
+ } else {
+ outw(reg, VBE_DISPI_IOPORT_INDEX);
+ ret = inw(VBE_DISPI_IOPORT_DATA);
+ }
+ return ret;
+}
+
+static void bochs_write(struct fb_info *info, u16 reg, u16 val)
+{
+ struct bochs_par *bochs = info->par;
+
+ if (bochs->mmio) {
+ int offset = 0x500 + (reg << 1);
+ writew(val, bochs->mmio + offset);
+ } else {
+ outw(reg, VBE_DISPI_IOPORT_INDEX);
+ outw(val, VBE_DISPI_IOPORT_DATA);
+ }
+}
+
+static int bochsfb_check_var(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ uint32_t x,y, xv,yv, pixels;
+
+ if (var->bits_per_pixel != 32 ||
+ var->xres > 65535 ||
+ var->xres_virtual > 65535 ||
+ (var->vmode & FB_VMODE_MASK) != FB_VMODE_NONINTERLACED)
+ return -EINVAL;
+
+ x = var->xres;
+ y = var->yres;
+ xv = var->xres_virtual;
+ yv = var->yres_virtual;
+ if (xv < x)
+ xv = x;
+ pixels = info->fix.smem_len * 8 / info->var.bits_per_pixel;
+ yv = pixels / xv;
+ if (y > yv)
+ return -EINVAL;
+
+ var->xres = x;
+ var->yres = y;
+ var->xres_virtual = xv;
+ var->yres_virtual = yv;
+ var->xoffset = 0;
+ var->yoffset = 0;
+
+ return 0;
+}
+
+static int bochsfb_set_par(struct fb_info *info)
+{
+ dev_dbg(info->dev, "set mode: real: %dx%d, virtual: %dx%d\n",
+ info->var.xres, info->var.yres,
+ info->var.xres_virtual, info->var.yres_virtual);
+
+ info->fix.line_length = info->var.xres * info->var.bits_per_pixel / 8;
+
+ bochs_write(info, VBE_DISPI_INDEX_BPP, info->var.bits_per_pixel);
+ bochs_write(info, VBE_DISPI_INDEX_XRES, info->var.xres);
+ bochs_write(info, VBE_DISPI_INDEX_YRES, info->var.yres);
+ bochs_write(info, VBE_DISPI_INDEX_BANK, 0);
+ bochs_write(info, VBE_DISPI_INDEX_VIRT_WIDTH, info->var.xres_virtual);
+ bochs_write(info, VBE_DISPI_INDEX_VIRT_HEIGHT, info->var.yres_virtual);
+ bochs_write(info, VBE_DISPI_INDEX_X_OFFSET, info->var.xoffset);
+ bochs_write(info, VBE_DISPI_INDEX_Y_OFFSET, info->var.yoffset);
+
+ bochs_write(info, VBE_DISPI_INDEX_ENABLE,
+ VBE_DISPI_ENABLED | VBE_DISPI_LFB_ENABLED);
+ return 0;
+}
+
+static int bochsfb_setcolreg(unsigned regno, unsigned red, unsigned green,
+ unsigned blue, unsigned transp,
+ struct fb_info *info)
+{
+ if (regno < 16 && info->var.bits_per_pixel = 32) {
+ red >>= 8;
+ green >>= 8;
+ blue >>= 8;
+ ((u32 *)(info->pseudo_palette))[regno] + (red << info->var.red.offset) |
+ (green << info->var.green.offset) |
+ (blue << info->var.blue.offset);
+ }
+ return 0;
+}
+
+static int bochsfb_pan_display(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ bochs_write(info, VBE_DISPI_INDEX_X_OFFSET, var->xoffset);
+ bochs_write(info, VBE_DISPI_INDEX_Y_OFFSET, var->yoffset);
+ return 0;
+}
+
+static struct fb_ops bochsfb_ops = {
+ .owner = THIS_MODULE,
+ .fb_check_var = bochsfb_check_var,
+ .fb_set_par = bochsfb_set_par,
+ .fb_setcolreg = bochsfb_setcolreg,
+ .fb_pan_display = bochsfb_pan_display,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+};
+
+static int
+bochsfb_pci_init(struct pci_dev *dp, const struct pci_device_id *ent)
+{
+ struct fb_info *p;
+ unsigned long addr, size, mem, ioaddr, iosize;
+ struct bochs_par *bochs;
+ u16 id;
+ int rc = -ENODEV;
+
+ p = framebuffer_alloc(sizeof(struct bochs_par), &dp->dev);
+ if (p = NULL) {
+ dev_err(&dp->dev, "Cannot allocate framebuffer structure\n");
+ return -ENOMEM;
+ }
+ bochs = p->par;
+
+ if (pci_enable_device(dp) < 0) {
+ dev_err(&dp->dev, "Cannot enable PCI device\n");
+ goto err_out;
+ }
+
+ if ((ent->driver_data = BOCHS_QEMU_STDVGA) &&
+ (dp->resource[2].flags & IORESOURCE_MEM)) {
+ /* mmio bar with vga and bochs registers present */
+ if (pci_request_region(dp, 2, "bochsfb") != 0) {
+ dev_err(&dp->dev, "Cannot request mmio region\n");
+ rc = -EBUSY;
+ goto err_out;
+ }
+ ioaddr = pci_resource_start(dp, 2);
+ iosize = pci_resource_len(dp, 2);
+ bochs->mmio = ioremap(ioaddr, iosize);
+ if (bochs->mmio = NULL) {
+ dev_err(&dp->dev, "Cannot map mmio region\n");
+ rc = -ENOMEM;
+ goto err_out;
+ }
+ } else {
+ ioaddr = VBE_DISPI_IOPORT_INDEX;
+ iosize = 2;
+ if (!request_region(ioaddr, iosize, "bochsfb")) {
+ dev_err(&dp->dev, "Cannot request ioports\n");
+ rc = -EBUSY;
+ goto err_out;
+ }
+ bochs->ioports = 1;
+ }
+
+ id = bochs_read(p, VBE_DISPI_INDEX_ID);
+ mem = bochs_read(p, VBE_DISPI_INDEX_VIDEO_MEMORY_64K) * 64 * 1024;
+ if ((id & 0xfff0) != VBE_DISPI_ID0) {
+ dev_err(&dp->dev, "ID mismatch\n");
+ goto err_out;
+ }
+
+ if ((dp->resource[0].flags & IORESOURCE_MEM) = 0)
+ goto err_out;
+ addr = pci_resource_start(dp, 0);
+ size = pci_resource_len(dp, 0);
+ if (addr = 0)
+ goto err_out;
+ if (size != mem) {
+ dev_err(&dp->dev, "Size mismatch: pci=%ld, bochs=%ld\n", size, mem);
+ size = min(size, mem);
+ }
+
+ p->apertures = alloc_apertures(1);
+ if (!p->apertures) {
+ rc = -ENOMEM;
+ goto err_out;
+ }
+ p->apertures->ranges[0].base = addr;
+ p->apertures->ranges[0].size = size;
+ remove_conflicting_framebuffers(p->apertures, "bochsfb", false);
+
+ if (pci_request_region(dp, 0, "bochsfb") != 0) {
+ dev_err(&dp->dev, "Cannot request framebuffer\n");
+ rc = -EBUSY;
+ goto err_out;
+ }
+
+ p->screen_base = ioremap(addr, size);
+ if (p->screen_base = NULL) {
+ dev_err(&dp->dev, "Cannot map framebuffer\n");
+ rc = -ENOMEM;
+ goto err_out;
+ }
+ memset(p->screen_base, 0, size);
+
+ dev_info(&dp->dev,"Found bochs VGA, ID 0x%x, type \"%s\".\n",
+ id, bochs_names[ent->driver_data]);
+ dev_info(&dp->dev,"Framebuffer size %ld kB @ 0x%lx, %s @ 0x%lx.\n",
+ size / 1024, addr,
+ bochs->ioports ? "ioports" : "mmio",
+ ioaddr);
+
+ pci_set_drvdata(dp, p);
+ p->fbops = &bochsfb_ops;
+ p->flags = FBINFO_FLAG_DEFAULT
+ | FBINFO_READS_FAST
+ | FBINFO_HWACCEL_XPAN
+ | FBINFO_HWACCEL_YPAN;
+ p->pseudo_palette = kmalloc(sizeof(u32) * 16, GFP_KERNEL);
+ p->fix = bochsfb_fix;
+ p->fix.smem_start = addr;
+ p->fix.smem_len = size;
+
+ if (screen_info.orig_video_isVGA = VIDEO_TYPE_VLFB ||
+ screen_info.orig_video_isVGA = VIDEO_TYPE_EFI) {
+ dev_info(&dp->dev,"Picking up default res %dx%d from %s.\n",
+ screen_info.lfb_width, screen_info.lfb_height,
+ screen_info.orig_video_isVGA = VIDEO_TYPE_VLFB ?
+ "vesa" : "efi");
+ screen_info.orig_video_isVGA = 0;
+ bochsfb_var.xres = screen_info.lfb_width;
+ bochsfb_var.yres = screen_info.lfb_height;
+ }
+
+ p->var = bochsfb_var;
+ bochsfb_check_var(&p->var, p);
+ if (mode) {
+ dev_info(&dp->dev,"Looking up configured res \"%s\" in modedb.\n",
+ mode);
+ fb_find_mode(&p->var, p, mode, NULL, 0, NULL, 32);
+ }
+
+ if (register_framebuffer(p) < 0) {
+ dev_err(&dp->dev,"Framebuffer failed to register\n");
+ goto err_out;
+ }
+
+ dev_info(&dp->dev,"fb%d: bochs VGA frame buffer initialized.\n",
+ p->node);
+
+ return 0;
+
+err_out:
+ if (bochs->mmio)
+ iounmap(bochs->mmio);
+ if (bochs->ioports)
+ release_region(VBE_DISPI_IOPORT_INDEX, 2);
+ if (p->screen_base)
+ iounmap(p->screen_base);
+ pci_release_regions(dp);
+ framebuffer_release(p);
+ return rc;
+}
+
+static void bochsfb_remove(struct pci_dev *dp)
+{
+ struct fb_info *p = pci_get_drvdata(dp);
+ struct bochs_par *bochs = p->par;
+
+ if (p->screen_base = NULL)
+ return;
+ unregister_framebuffer(p);
+ if (bochs->mmio)
+ iounmap(bochs->mmio);
+ if (bochs->ioports)
+ release_region(VBE_DISPI_IOPORT_INDEX, 2);
+ if (p->screen_base)
+ iounmap(p->screen_base);
+ pci_release_regions(dp);
+ kfree(p->pseudo_palette);
+ framebuffer_release(p);
+}
+
+static struct pci_device_id bochsfb_pci_tbl[] = {
+ {
+ .vendor = 0x1234,
+ .device = 0x1111,
+ .subvendor = 0x1af4,
+ .subdevice = 0x1100,
+ .driver_data = BOCHS_QEMU_STDVGA,
+ },
+ {
+ .vendor = 0x1234,
+ .device = 0x1111,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .driver_data = BOCHS_UNKNOWN,
+ },
+ { /* end of list */ }
+};
+
+MODULE_DEVICE_TABLE(pci, bochsfb_pci_tbl);
+
+static struct pci_driver bochsfb_driver = {
+ .name = "bochsfb",
+ .id_table = bochsfb_pci_tbl,
+ .probe = bochsfb_pci_init,
+ .remove = bochsfb_remove,
+};
+
+#ifndef MODULE
+static int __init bochsfb_setup(char *options)
+{
+ char *this_opt;
+
+ if (!options || !*options)
+ return 0;
+
+ while ((this_opt = strsep(&options, ",")) != NULL) {
+ if (!*this_opt)
+ continue;
+ if (!strncmp(this_opt, "mode:", 5))
+ mode = this_opt + 5;
+ else
+ mode = this_opt;
+ }
+ return 0;
+}
+#endif
+
+int __init bochs_init(void)
+{
+#ifndef MODULE
+ char *option = NULL;
+
+ if (fb_get_options("bochsfb", &option))
+ return -ENODEV;
+ bochsfb_setup(option);
+#endif
+ return pci_register_driver(&bochsfb_driver);
+}
+
+module_init(bochs_init);
+
+static void __exit bochsfb_exit(void)
+{
+ pci_unregister_driver(&bochsfb_driver);
+}
+
+module_exit(bochsfb_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Gerd Hoffmann <kraxel@redhat.com>");
+MODULE_DESCRIPTION("bochs dispi interface framebuffer driver");
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v11 0/8] PHY framework
From: Kishon Vijay Abraham I @ 2013-09-04 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130903155030.GA21525@kroah.com>
On Tuesday 03 September 2013 09:20 PM, Greg KH wrote:
> On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote:
>> Hi Greg,
>>
>> On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote:
>>>> On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote:
>>>>> Added a generic PHY framework that provides a set of APIs for the PHY drivers
>>>>> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
>>>>> the PHY with or without using phandle.
>>>>>
>>>>> This framework will be of use only to devices that uses external PHY (PHY
>>>>> functionality is not embedded within the controller).
>>>>>
>>>>> The intention of creating this framework is to bring the phy drivers spread
>>>>> all over the Linux kernel to drivers/phy to increase code re-use and to
>>>>> increase code maintainability.
>>>>>
>>>>> Comments to make PHY as bus wasn't done because PHY devices can be part of
>>>>> other bus and making a same device attached to multiple bus leads to bad
>>>>> design.
>>>>>
>>>>> If the PHY driver has to send notification on connect/disconnect, the PHY
>>>>> driver should make use of the extcon framework. Using this susbsystem
>>>>> to use extcon framwork will have to be analysed.
>>>>>
>>>>> You can find this patch series @
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing
>>>>
>>>> Looks like there are not further comments on this series. Can you take this in
>>>> your misc tree?
>>>
>>> Do you want me to queue these for you ? There are quite a few users for
>>> this framework already and I know of at least 2 others which will show
>>> up for v3.13.
>>
>> Can you queue this patch series? There are quite a few users already for this
>> framework.
>
> It will have to wait for 3.13 as the merge window for new features has
> been closed for a week or so. Sorry, I'll queue this up after 3.12-rc1
> is out.
Alright, thanks.
-Kishon
^ permalink raw reply
* Re: [RFC 00/22] OMAPDSS: DT support
From: Tomi Valkeinen @ 2013-09-04 7:41 UTC (permalink / raw)
To: Stefan Roese
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Nishanth Menon, Felipe Balbi, Santosh Shilimkar,
Tony Lindgren
In-Reply-To: <5226E13E.1030807@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2406 bytes --]
On 04/09/13 10:29, Stefan Roese wrote:
> On 28.08.2013 13:40, Tero Kristo wrote:
>> On 08/28/2013 01:14 PM, Tomi Valkeinen wrote:
>>> On 28/08/13 12:48, Tero Kristo wrote:
>>>> On 08/28/2013 12:22 PM, Tomi Valkeinen wrote:
>>>>> Hi,
>>>>>
>>>>> I'm seeing odd clock behavior with Beagle, booting with DT. I'm using
>>>>> v3.11-rc7 + DSS DT patches.
>>>>
>>>> I guess you are not using the clock DT patches? Just making sure I
>>>> didn't break anything.
>>>
>>> No, plain rc7 with my DSS DT patches.
>>>
>>>>> So, for some reason, the first clk_set_rate goes wrong. Any ideas?
>>>>
>>>> Hmm, strange. I am not seeing similar behavior, but I am calling
>>>> clk_set_rate in different location.... also I am using clock DT patches
>>>> (don't try the current version though, as I am reworking them.)
>>>>
>>>> [ 0.000000] dpll4_ck: 432000000
>>>> [ 0.000000] dpll4_m4_ck: 72000000
>>>> [ 0.000000] dpll4_m4x2_ck: 144000000
>>>> [ 0.000000] dss1_alwon_fck_3430es2: 144000000
>>>> [ 0.000000] dpll4_ck: 432000000
>>>> [ 0.000000] dpll4_m4_ck: 86400000
>>>> [ 0.000000] dpll4_m4x2_ck: 172800000
>>>> [ 0.000000] dss1_alwon_fck_3430es2: 172800000
>>>>
>>>> Do you see the error only when setting to some specific rate (86400000)
>>>> or it doesn't matter?
>>>
>>> I also tried setting to 72000000, with the same result.
>>>
>>> Do you know if I can somehow easily get debug prints from the clock
>>> framework, that could lighten up the issue?
>>
>> There isn't any good config option for that, I would suggest add prints
>> to the clk_set_rate and then for the clocks you are interested in, print
>> results for the recalc_rate / set_rate ops also.
>
> Tomi, did you make any progress on this issue? If not I'll try to dig
> into it later this week.
No, I haven't had time to debug this. And as this seems to show only
with DT, it's not a very high priority for me. DSS DT for OMAP4 is the
main priority, as the board files have already been removed for OMAP4
boards.
> BTW: Whats the current plan for your OMAPDSS DT patchset? Is it queued
> for v3.12 (this merge windows)? And do you have a git tree to pull the
> latest version from?
The git tree was mentioned in the intro mail.
No, DSS DT won't be in for 3.12. My current feeling is that it will
still take multiple kernel versions until it can be merged.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [RFC 00/22] OMAPDSS: DT support
From: Stefan Roese @ 2013-09-04 7:29 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Nishanth Menon, Felipe Balbi, Santosh Shilimkar,
Tony Lindgren
In-Reply-To: <5224458F.9070401@ti.com>
On 28.08.2013 13:40, Tero Kristo wrote:
> On 08/28/2013 01:14 PM, Tomi Valkeinen wrote:
>> On 28/08/13 12:48, Tero Kristo wrote:
>>> On 08/28/2013 12:22 PM, Tomi Valkeinen wrote:
>>>> Hi,
>>>>
>>>> I'm seeing odd clock behavior with Beagle, booting with DT. I'm using
>>>> v3.11-rc7 + DSS DT patches.
>>>
>>> I guess you are not using the clock DT patches? Just making sure I
>>> didn't break anything.
>>
>> No, plain rc7 with my DSS DT patches.
>>
>>>> So, for some reason, the first clk_set_rate goes wrong. Any ideas?
>>>
>>> Hmm, strange. I am not seeing similar behavior, but I am calling
>>> clk_set_rate in different location.... also I am using clock DT patches
>>> (don't try the current version though, as I am reworking them.)
>>>
>>> [ 0.000000] dpll4_ck: 432000000
>>> [ 0.000000] dpll4_m4_ck: 72000000
>>> [ 0.000000] dpll4_m4x2_ck: 144000000
>>> [ 0.000000] dss1_alwon_fck_3430es2: 144000000
>>> [ 0.000000] dpll4_ck: 432000000
>>> [ 0.000000] dpll4_m4_ck: 86400000
>>> [ 0.000000] dpll4_m4x2_ck: 172800000
>>> [ 0.000000] dss1_alwon_fck_3430es2: 172800000
>>>
>>> Do you see the error only when setting to some specific rate (86400000)
>>> or it doesn't matter?
>>
>> I also tried setting to 72000000, with the same result.
>>
>> Do you know if I can somehow easily get debug prints from the clock
>> framework, that could lighten up the issue?
>
> There isn't any good config option for that, I would suggest add prints
> to the clk_set_rate and then for the clocks you are interested in, print
> results for the recalc_rate / set_rate ops also.
Tomi, did you make any progress on this issue? If not I'll try to dig
into it later this week.
BTW: Whats the current plan for your OMAPDSS DT patchset? Is it queued
for v3.12 (this merge windows)? And do you have a git tree to pull the
latest version from?
Thanks,
Stefan
^ permalink raw reply
* [PATCH] pwm-backlight: add support for device tree gpio control
From: Mike Dunn @ 2013-09-03 19:26 UTC (permalink / raw)
To: thierry.reding
Cc: Mike Dunn, Richard Purdie, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Grant Likely,
Rob Herring, linux-pwm, linux-fbdev, linux-kernel, devicetree,
Robert Jarzmik, Marek Vasut
This patch adds support for controlling an arbitrary number of gpios to the
pwm-backlight driver. This was left as a TODO when initial device tree support
was added by Thierry a while back. This functionality replaces the callbacks
that are passed in the platform data for non-DT cases. Users can avail
themselves of this feature by adding a 'gpios' property to the 'backlight' node.
When the update_status() callback in backlight_ops runs, the gpios listed in the
property are asserted/deasserted if the specified brightness is non-zero/zero.
Tested on a pxa270-based Palm Treo 680.
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
---
Thanks for looking!
.../bindings/video/backlight/pwm-backlight.txt | 4 +
drivers/video/backlight/pwm_bl.c | 128 ++++++++++++++++++---
2 files changed, 113 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
index 1e4fc72..4583e68 100644
--- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
+++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
@@ -14,6 +14,9 @@ Required properties:
Optional properties:
- pwm-names: a list of names for the PWM devices specified in the
"pwms" property (see PWM binding[0])
+ - gpios: An arbitrary number of gpios that must be asserted when the
+ backlight is on, and de-asserted when off. They will be asserted
+ in the order they appear, and de-asserted in reverse order.
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
@@ -25,4 +28,5 @@ Example:
brightness-levels = <0 4 8 16 32 64 128 255>;
default-brightness-level = <6>;
+ gpios = <&gpio 77 0>, <&gpio 25 1>; /* gpio 25 is active low */
};
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 1fea627..1e2ab52 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -20,6 +20,12 @@
#include <linux/pwm.h>
#include <linux/pwm_backlight.h>
#include <linux/slab.h>
+#include <linux/of_gpio.h>
+
+struct pwm_bl_gpio {
+ unsigned int gpio;
+ enum of_gpio_flags flags;
+};
struct pwm_bl_data {
struct pwm_device *pwm;
@@ -27,6 +33,8 @@ struct pwm_bl_data {
unsigned int period;
unsigned int lth_brightness;
unsigned int *levels;
+ unsigned int num_gpios;
+ struct pwm_bl_gpio *gpios;
int (*notify)(struct device *,
int brightness);
void (*notify_after)(struct device *,
@@ -94,14 +102,77 @@ static const struct backlight_ops pwm_backlight_ops = {
};
#ifdef CONFIG_OF
+static int pwm_backlight_dt_notify(struct device *dev, int brightness)
+{
+ struct backlight_device *bl = dev_get_drvdata(dev);
+ struct pwm_bl_data *pb = bl_get_data(bl);
+ int i;
+
+ if (brightness) {
+ for (i = 0; i < pb->num_gpios; i++) {
+ if (pb->gpios[i].flags = OF_GPIO_ACTIVE_LOW)
+ gpio_set_value(pb->gpios[i].gpio, 0);
+ else
+ gpio_set_value(pb->gpios[i].gpio, 1);
+ }
+ return 0;
+ }
+
+ /* de-assert gpios in reverse order, in case this is important */
+ for (i = pb->num_gpios - 1; i >= 0; i--) {
+ if (pb->gpios[i].flags = OF_GPIO_ACTIVE_LOW)
+ gpio_set_value(pb->gpios[i].gpio, 1);
+ else
+ gpio_set_value(pb->gpios[i].gpio, 0);
+ }
+ return 0;
+}
+
+static void pwm_backlight_dt_exit(struct pwm_bl_data *pb)
+{
+ int i;
+
+ for (i = 0; i < pb->num_gpios; i++)
+ gpio_free(pb->gpios[i].gpio);
+}
+
+static int pwm_backlight_dt_init(struct device *dev, struct pwm_bl_data *pb)
+{
+ int i, j, ret;
+
+ /* request gpios and drive in the inactive state */
+ for (i = 0; i < pb->num_gpios; i++) {
+ char gpio_name[32];
+ unsigned long flags;
+ if (pb->gpios[i].flags = OF_GPIO_ACTIVE_LOW)
+ flags = GPIOF_OUT_INIT_LOW;
+ else
+ flags = GPIOF_OUT_INIT_HIGH;
+ snprintf(gpio_name, 32, "%s.%d", dev_name(dev), i);
+ ret = gpio_request_one(pb->gpios[i].gpio, flags, gpio_name);
+ if (ret) {
+ dev_err(dev, "gpio #%d request failed\n", i);
+ goto gpio_err;
+ }
+ }
+ return 0;
+
+ gpio_err:
+ for (j = 0; j < i; j++)
+ gpio_free(pb->gpios[j].gpio);
+ return ret;
+}
+
static int pwm_backlight_parse_dt(struct device *dev,
- struct platform_pwm_backlight_data *data)
+ struct platform_pwm_backlight_data *data,
+ struct pwm_bl_data *pb)
{
struct device_node *node = dev->of_node;
struct property *prop;
int length;
u32 value;
- int ret;
+ int ret, i, num_gpios;
+ size_t gpiosize;
if (!node)
return -ENODEV;
@@ -138,13 +209,29 @@ static int pwm_backlight_parse_dt(struct device *dev,
data->max_brightness--;
}
- /*
- * TODO: Most users of this driver use a number of GPIOs to control
- * backlight power. Support for specifying these needs to be
- * added.
- */
+ /* read gpios from DT property */
+ num_gpios = of_gpio_count(node);
+ if (num_gpios = -ENOENT)
+ return 0; /* no 'gpios' property present */
+ if (num_gpios < 0) {
+ dev_err(dev, "invalid DT node: gpios\n");
+ return -EINVAL;
+ }
+ gpiosize = sizeof(struct pwm_bl_gpio) * num_gpios;
+ pb->gpios = devm_kzalloc(dev, gpiosize, GFP_KERNEL);
+ if (!pb->gpios)
+ return -ENOMEM;
+ for (i = 0; i < num_gpios; i++) {
+ int gpio;
+ enum of_gpio_flags flags;
+ gpio = of_get_gpio_flags(node, i, &flags);
+ pb->gpios[i].gpio = (unsigned int)gpio;
+ pb->gpios[i].flags = flags;
+ }
+ pb->num_gpios = (unsigned int)num_gpios;
+ pb->notify = pwm_backlight_dt_notify;
- return 0;
+ return pwm_backlight_dt_init(dev, pb);
}
static struct of_device_id pwm_backlight_of_match[] = {
@@ -155,10 +242,12 @@ static struct of_device_id pwm_backlight_of_match[] = {
MODULE_DEVICE_TABLE(of, pwm_backlight_of_match);
#else
static int pwm_backlight_parse_dt(struct device *dev,
- struct platform_pwm_backlight_data *data)
+ struct platform_pwm_backlight_data *data,
+ struct pwm_bl_data *pb)
{
return -ENODEV;
}
+static void pwm_backlight_dt_exit(struct pwm_bl_data *pb) {}
#endif
static int pwm_backlight_probe(struct platform_device *pdev)
@@ -171,8 +260,14 @@ static int pwm_backlight_probe(struct platform_device *pdev)
unsigned int max;
int ret;
+ pb = devm_kzalloc(&pdev->dev, sizeof(*pb), GFP_KERNEL);
+ if (!pb) {
+ dev_err(&pdev->dev, "no memory for state\n");
+ return -ENOMEM;
+ }
+
if (!data) {
- ret = pwm_backlight_parse_dt(&pdev->dev, &defdata);
+ ret = pwm_backlight_parse_dt(&pdev->dev, &defdata, pb);
if (ret < 0) {
dev_err(&pdev->dev, "failed to find platform data\n");
return ret;
@@ -187,20 +282,14 @@ static int pwm_backlight_probe(struct platform_device *pdev)
return ret;
}
- pb = devm_kzalloc(&pdev->dev, sizeof(*pb), GFP_KERNEL);
- if (!pb) {
- dev_err(&pdev->dev, "no memory for state\n");
- ret = -ENOMEM;
- goto err_alloc;
- }
-
if (data->levels) {
max = data->levels[data->max_brightness];
pb->levels = data->levels;
} else
max = data->max_brightness;
- pb->notify = data->notify;
+ if (pb->notify = NULL) /* not using DT and its built-in notify() */
+ pb->notify = data->notify;
pb->notify_after = data->notify_after;
pb->check_fb = data->check_fb;
pb->exit = data->exit;
@@ -250,9 +339,9 @@ static int pwm_backlight_probe(struct platform_device *pdev)
}
bl->props.brightness = data->dft_brightness;
+ platform_set_drvdata(pdev, bl);
backlight_update_status(bl);
- platform_set_drvdata(pdev, bl);
return 0;
err_alloc:
@@ -271,6 +360,7 @@ static int pwm_backlight_remove(struct platform_device *pdev)
pwm_disable(pb->pwm);
if (pb->exit)
pb->exit(&pdev->dev);
+ pwm_backlight_dt_exit(pb);
return 0;
}
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH v11 0/8] PHY framework
From: Greg KH @ 2013-09-03 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5225FF63.6080608@ti.com>
On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote:
> Hi Greg,
>
> On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote:
> >> On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote:
> >>> Added a generic PHY framework that provides a set of APIs for the PHY drivers
> >>> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
> >>> the PHY with or without using phandle.
> >>>
> >>> This framework will be of use only to devices that uses external PHY (PHY
> >>> functionality is not embedded within the controller).
> >>>
> >>> The intention of creating this framework is to bring the phy drivers spread
> >>> all over the Linux kernel to drivers/phy to increase code re-use and to
> >>> increase code maintainability.
> >>>
> >>> Comments to make PHY as bus wasn't done because PHY devices can be part of
> >>> other bus and making a same device attached to multiple bus leads to bad
> >>> design.
> >>>
> >>> If the PHY driver has to send notification on connect/disconnect, the PHY
> >>> driver should make use of the extcon framework. Using this susbsystem
> >>> to use extcon framwork will have to be analysed.
> >>>
> >>> You can find this patch series @
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing
> >>
> >> Looks like there are not further comments on this series. Can you take this in
> >> your misc tree?
> >
> > Do you want me to queue these for you ? There are quite a few users for
> > this framework already and I know of at least 2 others which will show
> > up for v3.13.
>
> Can you queue this patch series? There are quite a few users already for this
> framework.
It will have to wait for 3.13 as the merge window for new features has
been closed for a week or so. Sorry, I'll queue this up after 3.12-rc1
is out.
greg k-h
^ permalink raw reply
* Re: [PATCH v11 0/8] PHY framework
From: Kishon Vijay Abraham I @ 2013-09-03 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130827192059.GZ3005@radagast>
Hi Greg,
On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote:
>> On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote:
>>> Added a generic PHY framework that provides a set of APIs for the PHY drivers
>>> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
>>> the PHY with or without using phandle.
>>>
>>> This framework will be of use only to devices that uses external PHY (PHY
>>> functionality is not embedded within the controller).
>>>
>>> The intention of creating this framework is to bring the phy drivers spread
>>> all over the Linux kernel to drivers/phy to increase code re-use and to
>>> increase code maintainability.
>>>
>>> Comments to make PHY as bus wasn't done because PHY devices can be part of
>>> other bus and making a same device attached to multiple bus leads to bad
>>> design.
>>>
>>> If the PHY driver has to send notification on connect/disconnect, the PHY
>>> driver should make use of the extcon framework. Using this susbsystem
>>> to use extcon framwork will have to be analysed.
>>>
>>> You can find this patch series @
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing
>>
>> Looks like there are not further comments on this series. Can you take this in
>> your misc tree?
>
> Do you want me to queue these for you ? There are quite a few users for
> this framework already and I know of at least 2 others which will show
> up for v3.13.
Can you queue this patch series? There are quite a few users already for this
framework.
Thanks
Kishon
^ permalink raw reply
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