* Re: [PATCH] video: fbdev: uvesafb: use CONFIG_X86_PAE surround _PAGE_NX check code
From: Wang YanQing @ 2014-03-06 10:33 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: plagnioj, fengguang.wu, linux-fbdev, linux-kernel
In-Reply-To: <53184655.2090106@ti.com>
On Thu, Mar 06, 2014 at 11:56:37AM +0200, Tomi Valkeinen wrote:
> I don't like this, I think this makes the code more messy, just to avoid
> that warning.
>
> And it might even be buggy. For your patch to work correctly, you need
> to know the internals of _PAGE_NX, i.e. that when CONFIG_X86_PAE is not
> defined, _PAGE_NX is 0. But the driver should not depend on things like
> that. If _PAGE_NX is changed later, the driver will not work correctly.
>
Very right! Thanks.
^ permalink raw reply
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Daniel Mack @ 2014-03-06 10:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
On 03/06/2014 11:30 AM, Tomi Valkeinen wrote:
> On 06/03/14 12:18, Daniel Mack wrote:
>>> That's clearly not the right place for it, but I
>>> think it's easier to move it along the other files, and later move it
>>> back to drivers/video/.
>>
>> Maybe it might be worth adding a subdirectory for hardware accelerators?
>> Because this is what the pxa3xx-gcu thing is all about really. And it's
>> only a tiny transport layer that passed commands between the hardware
>> block and a DirectFB userspace driver.
>
> Well, there's drivers/gpu/. It sounds like a good match, and by "sounds"
> I mean the word "gpu" sounds like a good match. I'm not sure if other
> people have opinions on what drivers/gpu/ should contain, though.
Yes, you're right. Do you think we should do that in a 2nd step maybe,
after 3.15?
Daniel
^ permalink raw reply
* Re: [PATCH 00/11] SimpleDRM & Sysfb
From: David Herrmann @ 2014-03-06 12:16 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev@vger.kernel.org, Daniel Vetter, linux-kernel,
dri-devel@lists.freedesktop.org, Ingo Molnar
In-Reply-To: <531465FF.1000201@ti.com>
Hi Tomi
On Mon, Mar 3, 2014 at 12:22 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 03/03/14 13:09, David Herrmann wrote:
>
>>> What do you think, would it be possible to keep the sysfb stuff in
>>> arch/x86, and still be able to do the rest of the stuff here? And then
>>> move the sysfs from arch/x86 to drivers/video later?
>>
>> I don't think there's any need for that. Linus does conflict
>> resolution all day long, so a short hint in Dave's pull-request (plus
>> an example merge) should be enough. Same is true for -next, I think.
>
> True, but, well, the conflict with this one is not a few lines. "git
> diff |wc -l" gives 2494 lines for the conflict. It's not really complex
> to resolve that one, though, as it's really about copying all the stuff
> into its new place.
>
> So I'm not sure if that makes Linus think "this is simple one, 30 secs
> and done" or "who the f*** sends me this crap" ;). Especially for two
> reasons:
>
> - The fb-reogranization is not very critical, and often clean-ups are
> not worth it (although I think this one is good one, of course).
> - Conflicting fbdev changes coming from another tree
>
>> And this is really just a mechanical thing, nothing hard to do. But of
>> course, it's your decision. However, keeping the code in x86 is the
>> wrong thing to do. As discussed with Ingo, the patch that extends
>
> Yes, I didn't mean keeping the code in x86 for good, but just for one
> kernel version to make merging easier.
>
>> x86/sysfb is only provided for easier backporting. The followup patch
>> immediately removes it again and adds proper video/sysfb. I'd dislike
>> splitting these just to avoid merge conflicts. I can also maintain a
>> merge-fixup branch in my tree, if anyone wants that.
>
> You can have a try at merging. If you think it's trivial, maybe it is
> and we can just let Linus handle it:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
> work/fb-reorder
Ok, I'm fine with delaying this one more merge-window. However, to
make things easier, could you pick up the two fbdev cleanups? These
are:
fbdev: efifb: add dev->remove() callback
fbdev: vesafb: add dev->remove() callback
They only add ->remove() callbacks which are never triggered currently
except with my sysfb series. But I'd like to drop both to make the
series smaller.
Thanks
David
^ permalink raw reply
* Re: [PATCH v5 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2014-03-06 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53184C2E.3000807@ti.com>
On Thu, 2014-03-06 at 10:21 +0000, Tomi Valkeinen wrote:
> Is this an old HW, and presumably there won't be new users for it? If
> yes, this is probably fine.
There is a DRM driver in the works, actually...
> If not, you might want to look at the video
> ports and endpoints, which is used by at least three not-yet-merged series:
>
> [PATCHv3 00/41] OMAPDSS: DT support v3
> [PATCH v5 00/11] imx-drm dt bindings
> [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
>
> Using bindings like that would be more future proof, even if the current
> driver doesn't use them.
... and this makes me try to get out of its way. In other words, I fully
agree with you, but I don't think this applies to this particular patch,
as I'm not even trying to represent the display pipeline. The (optional)
"display-timings" sub-node has been "borrowed" from other older drivers
and can be easily deprecated in the future, replaced by standard ones
(whatever final shape they will take :-). All other extra properties are
CLCD-specific and orthogonal.
Pawel
^ permalink raw reply
* [PATCH] lib: remove FBCON dependency for fonts
From: David Herrmann @ 2014-03-07 10:14 UTC (permalink / raw)
To: linux-kernel
Cc: Geert Uytterhoeven, linux-fbdev, Tomi Valkeinen, Andrew Morton,
Greg Kroah-Hartman, David Herrmann
Fonts don't depend on CONFIG_FRAMEBUFFER_CONSOLE at all. Remove that.
Besides, CONFIG_FONT_SUPPORT is 'select'ed anyway, so the dependencies
aren't checked by most higher-level options.
It's a relict of the times when fonts where exclusive to the VT layer and
fbcon.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
lib/fonts/Kconfig | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/lib/fonts/Kconfig b/lib/fonts/Kconfig
index 4dc1b99..0ca66a3 100644
--- a/lib/fonts/Kconfig
+++ b/lib/fonts/Kconfig
@@ -9,7 +9,6 @@ if FONT_SUPPORT
config FONTS
bool "Select compiled-in fonts"
- depends on FRAMEBUFFER_CONSOLE
help
Say Y here if you would like to use fonts other than the default
your frame buffer console usually use.
@@ -22,7 +21,6 @@ config FONTS
config FONT_8x8
bool "VGA 8x8 font" if FONTS
- depends on FRAMEBUFFER_CONSOLE
default y if !SPARC && !FONTS
help
This is the "high resolution" font for the VGA frame buffer (the one
@@ -45,7 +43,6 @@ config FONT_8x16
config FONT_6x11
bool "Mac console 6x11 font (not supported by all drivers)" if FONTS
- depends on FRAMEBUFFER_CONSOLE
default y if !SPARC && !FONTS && MAC
help
Small console font with Macintosh-style high-half glyphs. Some Mac
@@ -53,7 +50,6 @@ config FONT_6x11
config FONT_7x14
bool "console 7x14 font (not supported by all drivers)" if FONTS
- depends on FRAMEBUFFER_CONSOLE
help
Console font with characters just a bit smaller than the default.
If the standard 8x16 font is a little too big for you, say Y.
@@ -61,7 +57,6 @@ config FONT_7x14
config FONT_PEARL_8x8
bool "Pearl (old m68k) console 8x8 font" if FONTS
- depends on FRAMEBUFFER_CONSOLE
default y if !SPARC && !FONTS && AMIGA
help
Small console font with PC-style control-character and high-half
@@ -69,7 +64,6 @@ config FONT_PEARL_8x8
config FONT_ACORN_8x8
bool "Acorn console 8x8 font" if FONTS
- depends on FRAMEBUFFER_CONSOLE
default y if !SPARC && !FONTS && ARM && ARCH_ACORN
help
Small console font with PC-style control characters and high-half
@@ -81,13 +75,13 @@ config FONT_MINI_4x6
config FONT_SUN8x16
bool "Sparc console 8x16 font"
- depends on FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC)
+ depends on !SPARC && FONTS || SPARC
help
This is the high resolution console font for Sun machines. Say Y.
config FONT_SUN12x22
bool "Sparc console 12x22 font (not supported by all drivers)"
- depends on FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC)
+ depends on !SPARC && FONTS || SPARC
help
This is the high resolution console font for Sun machines with very
big letters (like the letters used in the SPARC PROM). If the
@@ -95,7 +89,6 @@ config FONT_SUN12x22
config FONT_10x18
bool "console 10x18 font (not supported by all drivers)" if FONTS
- depends on FRAMEBUFFER_CONSOLE
help
This is a high resolution console font for machines with very
big letters. It fits between the sun 12x22 and the normal 8x16 font.
--
1.9.0
^ permalink raw reply related
* Re: [PATCH] lib: remove FBCON dependency for fonts
From: Geert Uytterhoeven @ 2014-03-07 10:39 UTC (permalink / raw)
To: David Herrmann
Cc: linux-kernel@vger.kernel.org, Linux Fbdev development list,
Tomi Valkeinen, Andrew Morton, Greg Kroah-Hartman
In-Reply-To: <1394187271-5857-1-git-send-email-dh.herrmann@gmail.com>
On Fri, Mar 7, 2014 at 11:14 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Fonts don't depend on CONFIG_FRAMEBUFFER_CONSOLE at all. Remove that.
> Besides, CONFIG_FONT_SUPPORT is 'select'ed anyway, so the dependencies
> aren't checked by most higher-level options.
CONFIG_FONT_SUPPORT is indeed selected, but the other options are about
which fonts to include by default. No dependencies are bypassed by the select.
Without the "depends on FRAMEBUFFER_CONSOLE", people who don't
have FRAMEBUFFER_CONSOLE set, but have set any of these:
config EARLY_PRINTK_EFI
select FONT_SUPPORT
config VIDEO_VIVI
select FONT_SUPPORT
select FONT_8x16
config SOLO6X10
select FONT_SUPPORT
select FONT_8x16
config USB_SISUSBVGA
select FONT_SUPPORT
...
select FONT_8x16
config SGI_NEWPORT_CONSOLE
select FONT_SUPPORT
config STI_CONSOLE
select FONT_SUPPORT
will now get more (unused) fonts in their kernel image.
> It's a relict of the times when fonts where exclusive to the VT layer and
> fbcon.
>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> ---
> lib/fonts/Kconfig | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/lib/fonts/Kconfig b/lib/fonts/Kconfig
> index 4dc1b99..0ca66a3 100644
> --- a/lib/fonts/Kconfig
> +++ b/lib/fonts/Kconfig
> @@ -9,7 +9,6 @@ if FONT_SUPPORT
>
> config FONTS
> bool "Select compiled-in fonts"
> - depends on FRAMEBUFFER_CONSOLE
> help
> Say Y here if you would like to use fonts other than the default
> your frame buffer console usually use.
> @@ -22,7 +21,6 @@ config FONTS
>
> config FONT_8x8
> bool "VGA 8x8 font" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> default y if !SPARC && !FONTS
> help
> This is the "high resolution" font for the VGA frame buffer (the one
> @@ -45,7 +43,6 @@ config FONT_8x16
>
> config FONT_6x11
> bool "Mac console 6x11 font (not supported by all drivers)" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> default y if !SPARC && !FONTS && MAC
> help
> Small console font with Macintosh-style high-half glyphs. Some Mac
> @@ -53,7 +50,6 @@ config FONT_6x11
>
> config FONT_7x14
> bool "console 7x14 font (not supported by all drivers)" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> help
> Console font with characters just a bit smaller than the default.
> If the standard 8x16 font is a little too big for you, say Y.
> @@ -61,7 +57,6 @@ config FONT_7x14
>
> config FONT_PEARL_8x8
> bool "Pearl (old m68k) console 8x8 font" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> default y if !SPARC && !FONTS && AMIGA
> help
> Small console font with PC-style control-character and high-half
> @@ -69,7 +64,6 @@ config FONT_PEARL_8x8
>
> config FONT_ACORN_8x8
> bool "Acorn console 8x8 font" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> default y if !SPARC && !FONTS && ARM && ARCH_ACORN
> help
> Small console font with PC-style control characters and high-half
> @@ -81,13 +75,13 @@ config FONT_MINI_4x6
>
> config FONT_SUN8x16
> bool "Sparc console 8x16 font"
> - depends on FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC)
> + depends on !SPARC && FONTS || SPARC
> help
> This is the high resolution console font for Sun machines. Say Y.
>
> config FONT_SUN12x22
> bool "Sparc console 12x22 font (not supported by all drivers)"
> - depends on FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC)
> + depends on !SPARC && FONTS || SPARC
> help
> This is the high resolution console font for Sun machines with very
> big letters (like the letters used in the SPARC PROM). If the
> @@ -95,7 +89,6 @@ config FONT_SUN12x22
>
> config FONT_10x18
> bool "console 10x18 font (not supported by all drivers)" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> help
> This is a high resolution console font for machines with very
> big letters. It fits between the sun 12x22 and the normal 8x16 font.
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
* Re: [PATCH] lib: remove FBCON dependency for fonts
From: David Herrmann @ 2014-03-07 10:47 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-kernel@vger.kernel.org, Linux Fbdev development list,
Tomi Valkeinen, Andrew Morton, Greg Kroah-Hartman
In-Reply-To: <CAMuHMdVxE2jXQE11swi8sM251GcWcdDYpgE37pCoxpb7oF1-Rg@mail.gmail.com>
Hi
On Fri, Mar 7, 2014 at 11:39 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, Mar 7, 2014 at 11:14 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> Fonts don't depend on CONFIG_FRAMEBUFFER_CONSOLE at all. Remove that.
>> Besides, CONFIG_FONT_SUPPORT is 'select'ed anyway, so the dependencies
>> aren't checked by most higher-level options.
>
> CONFIG_FONT_SUPPORT is indeed selected, but the other options are about
> which fonts to include by default. No dependencies are bypassed by the select.
Indeed, I missed that, sorry.
> Without the "depends on FRAMEBUFFER_CONSOLE", people who don't
> have FRAMEBUFFER_CONSOLE set, but have set any of these:
>
> config EARLY_PRINTK_EFI
> select FONT_SUPPORT
>
> config VIDEO_VIVI
> select FONT_SUPPORT
> select FONT_8x16
>
> config SOLO6X10
> select FONT_SUPPORT
> select FONT_8x16
>
> config USB_SISUSBVGA
> select FONT_SUPPORT
> ...
> select FONT_8x16
>
> config SGI_NEWPORT_CONSOLE
> select FONT_SUPPORT
>
> config STI_CONSOLE
> select FONT_SUPPORT
>
> will now get more (unused) fonts in their kernel image.
Why would they get more unused fonts? All those fonts are "default n"
(except for some arch-specific stuff and 8x8 and obviously 8x16). I
don't mind if we drop this, but it makes font-selection impossible if
fbcon is disabled, which is kinda unexpected.
Thanks
David
^ permalink raw reply
* Re: [PATCH] lib: remove FBCON dependency for fonts
From: Geert Uytterhoeven @ 2014-03-07 10:54 UTC (permalink / raw)
To: David Herrmann
Cc: linux-kernel@vger.kernel.org, Linux Fbdev development list,
Tomi Valkeinen, Andrew Morton, Greg Kroah-Hartman
In-Reply-To: <CANq1E4SbA5jCh+5UqyJ=oxdiYdbfkUcfrbB=jGjKRZJ-LAuaXg@mail.gmail.com>
On Fri, Mar 7, 2014 at 11:47 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> Without the "depends on FRAMEBUFFER_CONSOLE", people who don't
>> have FRAMEBUFFER_CONSOLE set, but have set any of these:
>>
>> config EARLY_PRINTK_EFI
>> select FONT_SUPPORT
>>
>> config VIDEO_VIVI
>> select FONT_SUPPORT
>> select FONT_8x16
>>
>> config SOLO6X10
>> select FONT_SUPPORT
>> select FONT_8x16
>>
>> config USB_SISUSBVGA
>> select FONT_SUPPORT
>> ...
>> select FONT_8x16
>>
>> config SGI_NEWPORT_CONSOLE
>> select FONT_SUPPORT
>>
>> config STI_CONSOLE
>> select FONT_SUPPORT
>>
>> will now get more (unused) fonts in their kernel image.
>
> Why would they get more unused fonts? All those fonts are "default n"
> (except for some arch-specific stuff and 8x8 and obviously 8x16). I
So they get the 8x8 and the arch-specific ones by default (FONTS=n).
> don't mind if we drop this, but it makes font-selection impossible if
> fbcon is disabled, which is kinda unexpected.
IIRC, drivers that "select FONT_8x16" have the font name hardcoded in
the driver, so allowing to select more fonts doesn't gain anything for them.
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
* Re: [PATCH] lib: remove FBCON dependency for fonts
From: David Herrmann @ 2014-03-07 10:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-kernel@vger.kernel.org, Linux Fbdev development list,
Tomi Valkeinen, Andrew Morton, Greg Kroah-Hartman
In-Reply-To: <CAMuHMdUheaE00m289h=x0gxf+PAbPjhhdAKATAHGgOgk9YROVQ@mail.gmail.com>
Hi
On Fri, Mar 7, 2014 at 11:54 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, Mar 7, 2014 at 11:47 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>> Without the "depends on FRAMEBUFFER_CONSOLE", people who don't
>>> have FRAMEBUFFER_CONSOLE set, but have set any of these:
>>>
>>> config EARLY_PRINTK_EFI
>>> select FONT_SUPPORT
>>>
>>> config VIDEO_VIVI
>>> select FONT_SUPPORT
>>> select FONT_8x16
>>>
>>> config SOLO6X10
>>> select FONT_SUPPORT
>>> select FONT_8x16
>>>
>>> config USB_SISUSBVGA
>>> select FONT_SUPPORT
>>> ...
>>> select FONT_8x16
>>>
>>> config SGI_NEWPORT_CONSOLE
>>> select FONT_SUPPORT
>>>
>>> config STI_CONSOLE
>>> select FONT_SUPPORT
>>>
>>> will now get more (unused) fonts in their kernel image.
>>
>> Why would they get more unused fonts? All those fonts are "default n"
>> (except for some arch-specific stuff and 8x8 and obviously 8x16). I
>
> So they get the 8x8 and the arch-specific ones by default (FONTS=n).
They also get it if they enable FRAMEBUFFER_CONSOLE (which most people
do, right?). I don't understand why we want multiple fonts compiled-in
at all, but ok, that's not up to me.
>> don't mind if we drop this, but it makes font-selection impossible if
>> fbcon is disabled, which is kinda unexpected.
>
> IIRC, drivers that "select FONT_8x16" have the font name hardcoded in
> the driver, so allowing to select more fonts doesn't gain anything for them.
I don't. I use get_default_font() in the new drm_log.c patches.
Anyhow, I'm fine with 8x16, I just thought people might want to select
other fonts. But I guess it's up to them to deal with that, as long as
I use get_default_font() I guess I don't care.
Feel free to drop this patch then.
Thanks
David
^ permalink raw reply
* Re: [PATCH] lib: remove FBCON dependency for fonts
From: Geert Uytterhoeven @ 2014-03-07 11:17 UTC (permalink / raw)
To: David Herrmann
Cc: linux-kernel@vger.kernel.org, Linux Fbdev development list,
Tomi Valkeinen, Andrew Morton, Greg Kroah-Hartman
In-Reply-To: <CANq1E4RehTJRG=5WEP42-R1AXzFOdFNF953Gh94Rjum=QgxHQQ@mail.gmail.com>
On Fri, Mar 7, 2014 at 11:58 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Fri, Mar 7, 2014 at 11:54 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Fri, Mar 7, 2014 at 11:47 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>>> Without the "depends on FRAMEBUFFER_CONSOLE", people who don't
>>>> have FRAMEBUFFER_CONSOLE set, but have set any of these:
>>>>
>>>> config EARLY_PRINTK_EFI
>>>> select FONT_SUPPORT
>>>>
>>>> config VIDEO_VIVI
>>>> select FONT_SUPPORT
>>>> select FONT_8x16
>>>>
>>>> config SOLO6X10
>>>> select FONT_SUPPORT
>>>> select FONT_8x16
>>>>
>>>> config USB_SISUSBVGA
>>>> select FONT_SUPPORT
>>>> ...
>>>> select FONT_8x16
>>>>
>>>> config SGI_NEWPORT_CONSOLE
>>>> select FONT_SUPPORT
>>>>
>>>> config STI_CONSOLE
>>>> select FONT_SUPPORT
>>>>
>>>> will now get more (unused) fonts in their kernel image.
>>>
>>> Why would they get more unused fonts? All those fonts are "default n"
>>> (except for some arch-specific stuff and 8x8 and obviously 8x16). I
>>
>> So they get the 8x8 and the arch-specific ones by default (FONTS=n).
>
> They also get it if they enable FRAMEBUFFER_CONSOLE (which most people
> do, right?). I don't understand why we want multiple fonts compiled-in
I was more thinking of the CONFIG_FB=n case.
> at all, but ok, that's not up to me.
Frame buffer users may do so.
>>> don't mind if we drop this, but it makes font-selection impossible if
>>> fbcon is disabled, which is kinda unexpected.
>>
>> IIRC, drivers that "select FONT_8x16" have the font name hardcoded in
>> the driver, so allowing to select more fonts doesn't gain anything for them.
>
> I don't. I use get_default_font() in the new drm_log.c patches.
Good ;-)
> Anyhow, I'm fine with 8x16, I just thought people might want to select
> other fonts. But I guess it's up to them to deal with that, as long as
> I use get_default_font() I guess I don't care.
If you want to allow people to select more fonts, you can drop the "depends on
FRAMEBUFFER_CONSOLE" for "config FONTS", and move the dependency
for the individual fonts into the "default y if" clause, right?
E.g.
config FONT_6x11
bool "Mac console 6x11 font (not supported by all drivers)" if FONTS
default y if !SPARC && !FONTS && MAC && FRAMEBUFFER_CONSOLE
help
(one more cleanup: several of the "!SPARC" can be removed, as they're
implied by e.g. "MAC" and "ARM").
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 -resend] sisfb: fix 1280x720 resolution support
From: Dan Carpenter @ 2014-03-07 11:18 UTC (permalink / raw)
To: linux-fbdev
It uses the wrong mode index because there is no break statement.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/video/fbdev/sis/init.c b/drivers/video/fbdev/sis/init.c
index 4f26bc28e60b..bd40f5ecd901 100644
--- a/drivers/video/fbdev/sis/init.c
+++ b/drivers/video/fbdev/sis/init.c
@@ -651,6 +651,7 @@ SiS_GetModeID_LCD(int VGAEngine, unsigned int VBFlags, int HDisplay, int VDispla
switch(VDisplay) {
case 720:
ModeIndex = ModeIndex_1280x720[Depth];
+ break;
case 768:
if(VGAEngine = SIS_300_VGA) {
ModeIndex = ModeIndex_300_1280x768[Depth];
^ permalink raw reply related
* Re: [PATCH v5 1/2] video: ARM CLCD: Add DT support
From: Tomi Valkeinen @ 2014-03-07 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1394119431.4160.84.camel@hornet>
[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]
On 06/03/14 17:23, Pawel Moll wrote:
> On Thu, 2014-03-06 at 10:21 +0000, Tomi Valkeinen wrote:
>> Is this an old HW, and presumably there won't be new users for it? If
>> yes, this is probably fine.
>
> There is a DRM driver in the works, actually...
>
>> If not, you might want to look at the video
>> ports and endpoints, which is used by at least three not-yet-merged series:
>>
>> [PATCHv3 00/41] OMAPDSS: DT support v3
>> [PATCH v5 00/11] imx-drm dt bindings
>> [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
>>
>> Using bindings like that would be more future proof, even if the current
>> driver doesn't use them.
>
> ... and this makes me try to get out of its way. In other words, I fully
> agree with you, but I don't think this applies to this particular patch,
> as I'm not even trying to represent the display pipeline. The (optional)
Right, you are not, at the moment. My point was, if the driver is
extended later to support pipelines, or common panel/encoder drivers,
you (most likely) need to have similar bindings than the other people use.
Note that the same DT bindings you add here should also work for the DRM
driver in the future. So, in fact, the question is extended to: will the
fbdev or drm driver support common panels/encoders?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [patch -resend] sisfb: fix 1280x720 resolution support
From: Tomi Valkeinen @ 2014-03-07 12:20 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20140307111853.GB2351@elgon.mountain>
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
On 07/03/14 13:18, Dan Carpenter wrote:
> It uses the wrong mode index because there is no break statement.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/video/fbdev/sis/init.c b/drivers/video/fbdev/sis/init.c
> index 4f26bc28e60b..bd40f5ecd901 100644
> --- a/drivers/video/fbdev/sis/init.c
> +++ b/drivers/video/fbdev/sis/init.c
> @@ -651,6 +651,7 @@ SiS_GetModeID_LCD(int VGAEngine, unsigned int VBFlags, int HDisplay, int VDispla
> switch(VDisplay) {
> case 720:
> ModeIndex = ModeIndex_1280x720[Depth];
> + break;
> case 768:
> if(VGAEngine == SIS_300_VGA) {
> ModeIndex = ModeIndex_300_1280x768[Depth];
>
Thanks, queued for 3.15.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/11] SimpleDRM & Sysfb
From: Tomi Valkeinen @ 2014-03-07 12:44 UTC (permalink / raw)
To: David Herrmann
Cc: dri-devel@lists.freedesktop.org, Ingo Molnar,
linux-fbdev@vger.kernel.org, Dave Airlie, Daniel Vetter,
linux-kernel, Tom Gundersen
In-Reply-To: <CANq1E4TmACNwyANaUsWufJL1ne4pk4Gv+g4y7b6xeO=Po-SN9g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3466 bytes --]
On 06/03/14 14:16, David Herrmann wrote:
> Hi Tomi
>
> On Mon, Mar 3, 2014 at 12:22 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 03/03/14 13:09, David Herrmann wrote:
>>
>>>> What do you think, would it be possible to keep the sysfb stuff in
>>>> arch/x86, and still be able to do the rest of the stuff here? And then
>>>> move the sysfs from arch/x86 to drivers/video later?
>>>
>>> I don't think there's any need for that. Linus does conflict
>>> resolution all day long, so a short hint in Dave's pull-request (plus
>>> an example merge) should be enough. Same is true for -next, I think.
>>
>> True, but, well, the conflict with this one is not a few lines. "git
>> diff |wc -l" gives 2494 lines for the conflict. It's not really complex
>> to resolve that one, though, as it's really about copying all the stuff
>> into its new place.
>>
>> So I'm not sure if that makes Linus think "this is simple one, 30 secs
>> and done" or "who the f*** sends me this crap" ;). Especially for two
>> reasons:
>>
>> - The fb-reogranization is not very critical, and often clean-ups are
>> not worth it (although I think this one is good one, of course).
>> - Conflicting fbdev changes coming from another tree
>>
>>> And this is really just a mechanical thing, nothing hard to do. But of
>>> course, it's your decision. However, keeping the code in x86 is the
>>> wrong thing to do. As discussed with Ingo, the patch that extends
>>
>> Yes, I didn't mean keeping the code in x86 for good, but just for one
>> kernel version to make merging easier.
>>
>>> x86/sysfb is only provided for easier backporting. The followup patch
>>> immediately removes it again and adds proper video/sysfb. I'd dislike
>>> splitting these just to avoid merge conflicts. I can also maintain a
>>> merge-fixup branch in my tree, if anyone wants that.
>>
>> You can have a try at merging. If you think it's trivial, maybe it is
>> and we can just let Linus handle it:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
>> work/fb-reorder
>
> Ok, I'm fine with delaying this one more merge-window. However, to
> make things easier, could you pick up the two fbdev cleanups? These
> are:
> fbdev: efifb: add dev->remove() callback
> fbdev: vesafb: add dev->remove() callback
>
> They only add ->remove() callbacks which are never triggered currently
> except with my sysfb series. But I'd like to drop both to make the
> series smaller.
Yes, I can take them if they work fine without the rest of the patches.
I could also take all the patches up to patch #6 via fbdev tree. Some of
the patches are for arch x86, but they seem to be still about
framebuffers. But maybe that causes conflicts with x86 tree, then =).
Then again, maybe we should just go forward and let Linus handle the
conflict. I'm planning to send the "normal" fbdev changes and the
fbdev-reorg separately (just in case Linus doesn't like the reorg), and
that already causes conflicts, very similar to what this series causes.
So in any case Linus has to handle that conflict, or use a resolution
offered by me. So if fbdev changes and this series are merged in
relatively early phase, I can then send the reorg series a bit later and
offer a conflict resolution that solves the conflicts for both series.
That way this series doesn't get delayed needlessly in the case that
Linus rejects the reorg series.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Tomi Valkeinen @ 2014-03-07 12:56 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <53143796.2050309@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]
On 03/03/14 10:04, Tomi Valkeinen wrote:
> Hi Rob, Pawel, Mark, Ian, Kumar,
Ping,
Any hints on how to continue with this?
> On 28/02/14 18:56, Russell King - ARM Linux wrote:
>> On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:
>>> This is totally unclear to me. How does it become a public standard?
>>> What's the forum for this?
>>
>> Me too. That's where I'd hope someone on devicetree-discuss will be
>> able to help us work out what's the right approach here. :)
>
> The story briefly so far: I've implemented DT support for OMAP display,
> and created bindings for various (non-OMAP) display components,
> including generic connector bindings for DVI, HDMI and analog-tv.
>
> Russell's point was that these connector bindings are very generic, i.e.
> they are not for any particular chip from a particular vendor, but for
> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
> shouldn't define such generic bindings without consulting the whole
> device-tree community (i.e including non-linux users).
>
> So the question is, is there such a community and a forum to bring up
> this kind of things? If yes, should we bring this up there? If yes, what
> kind of things in general should be brought into the attention of
> non-linux users?
>
> What I wonder here is that while a thing like DVI connector is, of
> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
> case still the same: we're defining global bindings for hardware that
> should work for everyone, not only Linux users?
>
> Tomi
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/11] SimpleDRM & Sysfb
From: David Herrmann @ 2014-03-07 13:05 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev@vger.kernel.org, Daniel Vetter, linux-kernel,
dri-devel@lists.freedesktop.org, Ingo Molnar
In-Reply-To: <5319BF40.70305@ti.com>
Hi
On Fri, Mar 7, 2014 at 1:44 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 06/03/14 14:16, David Herrmann wrote:
>> Hi Tomi
>>
>> On Mon, Mar 3, 2014 at 12:22 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On 03/03/14 13:09, David Herrmann wrote:
>>>
>>>>> What do you think, would it be possible to keep the sysfb stuff in
>>>>> arch/x86, and still be able to do the rest of the stuff here? And then
>>>>> move the sysfs from arch/x86 to drivers/video later?
>>>>
>>>> I don't think there's any need for that. Linus does conflict
>>>> resolution all day long, so a short hint in Dave's pull-request (plus
>>>> an example merge) should be enough. Same is true for -next, I think.
>>>
>>> True, but, well, the conflict with this one is not a few lines. "git
>>> diff |wc -l" gives 2494 lines for the conflict. It's not really complex
>>> to resolve that one, though, as it's really about copying all the stuff
>>> into its new place.
>>>
>>> So I'm not sure if that makes Linus think "this is simple one, 30 secs
>>> and done" or "who the f*** sends me this crap" ;). Especially for two
>>> reasons:
>>>
>>> - The fb-reogranization is not very critical, and often clean-ups are
>>> not worth it (although I think this one is good one, of course).
>>> - Conflicting fbdev changes coming from another tree
>>>
>>>> And this is really just a mechanical thing, nothing hard to do. But of
>>>> course, it's your decision. However, keeping the code in x86 is the
>>>> wrong thing to do. As discussed with Ingo, the patch that extends
>>>
>>> Yes, I didn't mean keeping the code in x86 for good, but just for one
>>> kernel version to make merging easier.
>>>
>>>> x86/sysfb is only provided for easier backporting. The followup patch
>>>> immediately removes it again and adds proper video/sysfb. I'd dislike
>>>> splitting these just to avoid merge conflicts. I can also maintain a
>>>> merge-fixup branch in my tree, if anyone wants that.
>>>
>>> You can have a try at merging. If you think it's trivial, maybe it is
>>> and we can just let Linus handle it:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
>>> work/fb-reorder
>>
>> Ok, I'm fine with delaying this one more merge-window. However, to
>> make things easier, could you pick up the two fbdev cleanups? These
>> are:
>> fbdev: efifb: add dev->remove() callback
>> fbdev: vesafb: add dev->remove() callback
>>
>> They only add ->remove() callbacks which are never triggered currently
>> except with my sysfb series. But I'd like to drop both to make the
>> series smaller.
>
> Yes, I can take them if they work fine without the rest of the patches.
>
> I could also take all the patches up to patch #6 via fbdev tree. Some of
> the patches are for arch x86, but they seem to be still about
> framebuffers. But maybe that causes conflicts with x86 tree, then =).
>
> Then again, maybe we should just go forward and let Linus handle the
> conflict. I'm planning to send the "normal" fbdev changes and the
> fbdev-reorg separately (just in case Linus doesn't like the reorg), and
> that already causes conflicts, very similar to what this series causes.
>
> So in any case Linus has to handle that conflict, or use a resolution
> offered by me. So if fbdev changes and this series are merged in
> relatively early phase, I can then send the reorg series a bit later and
> offer a conflict resolution that solves the conflicts for both series.
>
> That way this series doesn't get delayed needlessly in the case that
> Linus rejects the reorg series.
If you can take these two patches, that's fine. They're not strictly
needed by the series and I'd be happy to see them upstream. The other
sysfb patches should be merged together, so I don't think there's much
gain in applying them through fbdev.
The DRM tree is usually merged late, anyway, so I'll see whether we
will merge simpledrm through drm-next or not. If not, it'll be 3.16
then. If you can get the fbdev merge in early, that should be enough
for us to figure it out and provide a conflict-resolution. Btw., do
you want the generic sysfb-helper in drivers/video/ or
driver/video/fbdev? It's not limited to fbdev, so I'd put it in
drivers/video/.
Thanks
David
^ permalink raw reply
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Tomi Valkeinen @ 2014-03-07 13:08 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]
On 06/03/14 12:53, Daniel Mack wrote:
> On 03/06/2014 11:30 AM, Tomi Valkeinen wrote:
>> On 06/03/14 12:18, Daniel Mack wrote:
>
>>>> That's clearly not the right place for it, but I
>>>> think it's easier to move it along the other files, and later move it
>>>> back to drivers/video/.
>>>
>>> Maybe it might be worth adding a subdirectory for hardware accelerators?
>>> Because this is what the pxa3xx-gcu thing is all about really. And it's
>>> only a tiny transport layer that passed commands between the hardware
>>> block and a DirectFB userspace driver.
>>
>> Well, there's drivers/gpu/. It sounds like a good match, and by "sounds"
>> I mean the word "gpu" sounds like a good match. I'm not sure if other
>> people have opinions on what drivers/gpu/ should contain, though.
I have applied this series to fbdev tree for 3.15.
> Yes, you're right. Do you think we should do that in a 2nd step maybe,
> after 3.15?
Maybe. Then again, drivers/video is not so bad a location, after fbdev
stuff has been moved to drivers/video/fbdev/. drivers/gpu doesn't seem
to have a specific maintainer, but I guess that goes through drm maintainer.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/11] SimpleDRM & Sysfb
From: Tomi Valkeinen @ 2014-03-07 13:52 UTC (permalink / raw)
To: David Herrmann
Cc: dri-devel@lists.freedesktop.org, Ingo Molnar,
linux-fbdev@vger.kernel.org, Dave Airlie, Daniel Vetter,
linux-kernel, Tom Gundersen
In-Reply-To: <CANq1E4QXWYQE5DWOA7F39oHFd2ZnV5Ny4ykOw1=aJT+B_umy3Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]
On 07/03/14 15:05, David Herrmann wrote:
> If you can take these two patches, that's fine. They're not strictly
> needed by the series and I'd be happy to see them upstream. The other
> sysfb patches should be merged together, so I don't think there's much
> gain in applying them through fbdev.
Ok, I've applied them to fbdev tree.
> The DRM tree is usually merged late, anyway, so I'll see whether we
> will merge simpledrm through drm-next or not. If not, it'll be 3.16
> then. If you can get the fbdev merge in early, that should be enough
> for us to figure it out and provide a conflict-resolution. Btw., do
> you want the generic sysfb-helper in drivers/video/ or
> driver/video/fbdev? It's not limited to fbdev, so I'd put it in
> drivers/video/.
With a quick glance, it doesn't seem to depend on fbdev in any way,
right? That makes me think drivers/video/.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/11] SimpleDRM & Sysfb
From: David Herrmann @ 2014-03-07 14:06 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev@vger.kernel.org, linux-kernel,
dri-devel@lists.freedesktop.org
In-Reply-To: <5319CF23.6090103@ti.com>
Hi Tomi
On Fri, Mar 7, 2014 at 2:52 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 07/03/14 15:05, David Herrmann wrote:
>
>> If you can take these two patches, that's fine. They're not strictly
>> needed by the series and I'd be happy to see them upstream. The other
>> sysfb patches should be merged together, so I don't think there's much
>> gain in applying them through fbdev.
>
> Ok, I've applied them to fbdev tree.
Thanks!
>> The DRM tree is usually merged late, anyway, so I'll see whether we
>> will merge simpledrm through drm-next or not. If not, it'll be 3.16
>> then. If you can get the fbdev merge in early, that should be enough
>> for us to figure it out and provide a conflict-resolution. Btw., do
>> you want the generic sysfb-helper in drivers/video/ or
>> driver/video/fbdev? It's not limited to fbdev, so I'd put it in
>> drivers/video/.
>
> With a quick glance, it doesn't seem to depend on fbdev in any way,
> right? That makes me think drivers/video/.
Right! I will keep them in drivers/video/ then.
Thanks
David
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Philipp Zabel @ 2014-03-07 14:17 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree@vger.kernel.org, Linux Fbdev development list,
Russell King - ARM Linux, DRI Development, Andrzej Hajda,
Geert Uytterhoeven, Laurent Pinchart,
linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth
In-Reply-To: <53183730.5060205@ti.com>
Hi,
Am Donnerstag, den 06.03.2014, 10:52 +0200 schrieb Tomi Valkeinen:
> On 06/03/14 10:39, Geert Uytterhoeven wrote:
> > On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >> On 28/02/14 18:23, Russell King - ARM Linux wrote:
> >>
> >>> That's rather a lot of compatible strings. Another possibility is:
> >>>
> >>> compatible = "dvi-connector";
> >>> analog;
> >>> digital;
> >>> single-link;
> >>> dual-link;
> >>
> >> I made the following changes compared to the posted version. I decided
> >> to leave the "single-link" out, as it's implied if "digital" is set.
> >>
> >> Tomi
> >>
> >> @@ -6,11 +6,16 @@ Required properties:
> >>
> >> Optional properties:
> >> - label: a symbolic name for the connector
> >> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> >> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> >> +- analog: the connector has DVI analog pins
> >> +- digital: the connector has DVI digital pins
> >> +- dual-link: the connector has pins for DVI dual-link
> >>
> >> Required nodes:
> >> - Video port for DVI input
> >>
> >> +Note: One (or both) of 'analog' or 'digital' must be set.
> >
> > So dual-link needs both "digital" and "dual-link"?
>
> Yes. It is extra, but it felt clearer to me to have 'digital' as a
> matching property for 'analog'.
>
> Alternatively we could have three options:
>
> analog;
> digital-single-link;
> digital-dual-link;
>
> My reasoning to the format I chose was basically that when a connector
> supports 'digital', it contains TMDS clock and TMDS data for link 1.
> Adding dual link to that adds only TMDS data for link 2, so the second
> data link is kind of an additional feature, marked with a flag.
>
> Not a very big argument, and I'm fine with other format suggestions.
I'd prefer the analog / digital / dual-link variant for aesthetic
reasons. But looking at other connector types, I wonder if this should
be generalized even more:
For HDMI/DVI (digital) single-link means one clock pair and 3 TMDS data
pairs, dual-link means one clock pair and 6 data pairs.
On LVDS connectors, there usually are one clock pair and three (18-bit)
or four (24-bit) LVDS data pairs, in dual channel configuration two
clock pairs and 6 or 8 data pairs are used.
For DisplayPort there is no separate clock pair, but 1 to 4 data pairs,
and MIPI DSI again has one clock pair and a one or more data pairs.
There are already optional endpoint configuration properties
'data-lanes' and 'clock-lanes' for MIPI CSI-2 defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
Could/should this be aligned with the same?
regards
Philipp
^ permalink raw reply
* [PATCH] video: atmel_lcdfb: ensure the hardware is initialized with the correct mode
From: Antoine Ténart @ 2014-03-07 16:20 UTC (permalink / raw)
To: linux-arm-kernel
If no driver takeover the atmel_lcdfb, the lcd won't be in a working state
since atmel_lcdfb_set_par() will never be called. Enabling a driver which does,
like fbcon, will call the function and put atmel_lcdfb in a working state.
Fixes: b985172b328a (video: atmel_lcdfb: add device tree suport)
Signed-off-by: Antoine Ténart <antoine.tenart@free-electrons.com>
Reported-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/video/atmel_lcdfb.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index cd96162..b74e5f5d 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -1298,6 +1298,12 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
goto unregister_irqs;
}
+ ret = atmel_lcdfb_set_par(info);
+ if (ret < 0) {
+ dev_err(dev, "set par failed: %d\n", ret);
+ goto unregister_irqs;
+ }
+
dev_set_drvdata(dev, info);
/*
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCHv3 00/41] OMAPDSS: DT support v3
From: Tony Lindgren @ 2014-03-07 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <531823C5.1020008@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140305 23:32]:
> Hi Tony,
>
> On 21/01/14 12:56, Tomi Valkeinen wrote:
> > Hi,
> >
> > Here's version 3 of the DSS DT series.
>
> Can you have a look at the arch/arm/ parts in the series and ack if
> they're ok, i.e, patches 1, 2, 32.
Patches 1, 2 & 32 look OK to me, so for those please feel free to add:
Acked-by: Tony Lindgren <tony@atomide.com>
There's a minor merge conflict in pdata-quirks.c, but that's trivial
so it should be OK for you to queue those along with the DSS patches.
> Then there are the .dts patches, 22-30, for which I haven't been able to
> get any acks. I'm not sure who I should get acks from for those, but I
> don't mind adding yours if you want to give it.
>
> The .dts patches have had minor changes compared to the ones posted
> here, according to the DT bindings review comments, but nothing much has
> changed.
These will cause unnecessary merge conflicts all over the place:
Auto-merging arch/arm/boot/dts/omap4.dtsi
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap4.dtsi
Auto-merging arch/arm/boot/dts/omap4-sdp.dts
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap4-sdp.dts
Auto-merging arch/arm/boot/dts/omap4-panda-common.dtsi
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap4-panda-common.dtsi
Auto-merging arch/arm/boot/dts/omap3.dtsi
Auto-merging arch/arm/boot/dts/omap3-n900.dts
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap3-n900.dts
Auto-merging arch/arm/boot/dts/omap3-igep0020.dts
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap3-igep0020.dts
Auto-merging arch/arm/boot/dts/omap3-beagle.dts
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap3-beagle.dts
Auto-merging arch/arm/boot/dts/omap3-beagle-xm.dts
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap3-beagle-xm.dts
How about do a pull request for just the .dts changes against current
omap-for-v3.15/dt branch ASAP for me so I can pull it in? That is assuming
that just the .dts changes alone won't break anything.
Then make sure your series works both ways and maybe do a follow up
patch that flips things over after the dependencies are merged.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH] video: atmel_lcdfb: ensure the hardware is initialized with the correct mode
From: Alexandre Belloni @ 2014-03-07 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1394209254-23797-1-git-send-email-antoine.tenart@free-electrons.com>
On 07/03/2014 at 17:20:54 +0100, Antoine Ténart wrote :
> If no driver takeover the atmel_lcdfb, the lcd won't be in a working state
> since atmel_lcdfb_set_par() will never be called. Enabling a driver which does,
> like fbcon, will call the function and put atmel_lcdfb in a working state.
>
> Fixes: b985172b328a (video: atmel_lcdfb: add device tree suport)
>
> Signed-off-by: Antoine Ténart <antoine.tenart@free-electrons.com>
> Reported-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
> drivers/video/atmel_lcdfb.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index cd96162..b74e5f5d 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -1298,6 +1298,12 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
> goto unregister_irqs;
> }
>
> + ret = atmel_lcdfb_set_par(info);
> + if (ret < 0) {
> + dev_err(dev, "set par failed: %d\n", ret);
> + goto unregister_irqs;
> + }
> +
> dev_set_drvdata(dev, info);
>
> /*
> --
> 1.8.3.2
>
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] backlight: add new LP8860 backlight driver
From: Jingoo Han @ 2014-03-10 9:10 UTC (permalink / raw)
To: 'Daniel Jeong'
Cc: linux-fbdev, linux-kernel,
'Jean-Christophe Plagniol-Villard',
'Tomi Valkeinen', 'Bryan Wu', 'Lee Jones',
'Jingoo Han'
In-Reply-To: <1393838076-4559-1-git-send-email-gshark.jeong@gmail.com>
On Monday, March 03, 2014 6:15 PM, Daniel Jeong wrote:
>
(+CC Bryan Wu, Lee Jones)
Please add Bryan Wu, Lee Jones to CC list, when you send
patches for backlight.
> This patch adds LP8860 backlight device driver.
> LP8860 is a low EMI and High performance 4 channel LED Driver of TI.
> This device driver provide the way to control brightness and currnet
(+CC Bryan Wu, Lee Jones)
s/provide/provides
s/currnet/current
> of each channel and provide the way to write eeprom.
s/provide/provides
> To support dt structure, another patch file will be sent.
>
> Signed-off-by: Daniel Jeong <gshark.jeong@gmail.com>
> ---
'To support dt structure, another patch file will be sent.' is
NOT appropriate for the commit message. So, please move it as below.
Then, this message will not be included to the commit message, when
this patch will be merged to maintainer's tree.
Signed-off-by: Daniel Jeong <gshark.jeong@gmail.com>
---
To support dt structure, another patch file will be sent.
> drivers/video/backlight/Kconfig | 7 +
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/lp8860_bl.c | 528 +++++++++++++++++++++++++++++++
> include/linux/platform_data/lp8860_bl.h | 54 ++++
> 4 files changed, 590 insertions(+)
> create mode 100644 drivers/video/backlight/lp8860_bl.c
> create mode 100644 include/linux/platform_data/lp8860_bl.h
>
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 5a3eb2e..908048f 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -397,6 +397,13 @@ config BACKLIGHT_LP8788
> help
> This supports TI LP8788 backlight driver.
>
> +config BACKLIGHT_LP8860
> + tristate "Backlight Driver for LP8860"
> + depends on BACKLIGHT_CLASS_DEVICE && I2C
> + select REGMAP_I2C
> + help
> + This supports TI LP8860 Backlight Driver
> +
> config BACKLIGHT_OT200
> tristate "Backlight driver for ot200 visualisation device"
> depends on BACKLIGHT_CLASS_DEVICE && CS5535_MFGPT && GPIO_CS5535
> diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
> index bb82002..cbc5ac3 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -42,6 +42,7 @@ obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
> obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
> obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
> obj-$(CONFIG_BACKLIGHT_LP8788) += lp8788_bl.o
> +obj-$(CONFIG_BACKLIGHT_LP8860) += lp8860_bl.o
> obj-$(CONFIG_BACKLIGHT_LV5207LP) += lv5207lp.o
> obj-$(CONFIG_BACKLIGHT_MAX8925) += max8925_bl.o
> obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
> diff --git a/drivers/video/backlight/lp8860_bl.c b/drivers/video/backlight/lp8860_bl.c
> new file mode 100644
> index 0000000..4712e84
> --- /dev/null
> +++ b/drivers/video/backlight/lp8860_bl.c
> @@ -0,0 +1,528 @@
> +/*
> +* Simple driver for Texas Instruments lp8860 Backlight driver chip
> +*
> +* Copyright (C) 2014 Texas Instruments
> +* Author: Daniel Jeong <gshark.jeong@gmail.com>
> +* Ldd Mlp <ldd-mlp@list.ti.com>
> +*
> +* This program is free software; you can redistribute it and/or modify
> +* it under the terms of the GNU General Public License version 2 as
> +* published by the Free Software Foundation.
> +*
> +*/
> +#include <linux/module.h>
Please move this header in alphabetical order.
> +#include <linux/backlight.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/platform_data/lp8860_bl.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/uaccess.h>
> +
> +#define REG_CL0_BRT_H 0x00
> +#define REG_CL0_BRT_L 0x01
> +#define REG_CL0_I_H 0x02
> +#define REG_CL0_I_L 0x03
> +
> +#define REG_CL1_BRT_H 0x04
> +#define REG_CL1_BRT_L 0x05
> +#define REG_CL1_I 0x06
> +
> +#define REG_CL2_BRT_H 0x07
> +#define REG_CL2_BRT_L 0x08
> +#define REG_CL2_I 0x09
> +
> +#define REG_CL3_BRT_H 0x0a
> +#define REG_CL3_BRT_L 0x0b
> +#define REG_CL3_I 0x0c
> +
> +#define REG_CONF 0x0d
> +#define REG_STATUS 0x0e
> +#define REG_ID 0x12
> +
> +#define REG_ROM_CTRL 0x19
> +#define REG_ROM_UNLOCK 0x1a
> +#define REG_ROM_START 0x60
> +#define REG_ROM_END 0x78
> +
> +#define REG_EEPROM_START 0x60
> +#define REG_EEPROM_END 0x78
> +#define REG_MAX 0xFF
> +
> +struct lp8860_chip {
> + struct device *dev;
> + struct lp8860_platform_data *pdata;
> + struct backlight_device *bled[LP8860_LED_MAX];
> + struct regmap *regmap;
> +};
> +
> +/* brightness control */
> +static int lp8860_bled_update_status(struct backlight_device *bl,
> + enum lp8860_leds nsr)
> +{
> + int ret = -EINVAL;
> + struct lp8860_chip *pchip = bl_get_data(bl);
> +
> + if (pchip->pdata->mode)
> + return 0;
> +
> + if (bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
> + bl->props.brightness = 0;
> +
> + switch (nsr) {
> + case LP8860_LED0:
> + ret = regmap_write(pchip->regmap,
> + REG_CL0_BRT_H, bl->props.brightness >> 8);
> + ret |= regmap_write(pchip->regmap,
> + REG_CL0_BRT_L, bl->props.brightness & 0xff);
> + break;
> + case LP8860_LED1:
> + ret = regmap_write(pchip->regmap,
> + REG_CL1_BRT_H,
> + (bl->props.brightness >> 8) & 0x1f);
> + ret |> + regmap_write(pchip->regmap, REG_CL1_BRT_L,
> + bl->props.brightness & 0xff);
> + break;
> + case LP8860_LED2:
> + ret = regmap_write(pchip->regmap,
> + REG_CL2_BRT_H,
> + (bl->props.brightness >> 8) & 0x1f);
> + ret |> + regmap_write(pchip->regmap, REG_CL2_BRT_L,
> + bl->props.brightness & 0xff);
> + break;
> + case LP8860_LED3:
> + ret = regmap_write(pchip->regmap,
> + REG_CL3_BRT_H,
> + (bl->props.brightness >> 8) & 0x1f);
> + ret |> + regmap_write(pchip->regmap, REG_CL3_BRT_L,
> + bl->props.brightness & 0xff);
> + break;
> + default:
> + BUG();
> + }
> + if (ret < 0)
> + dev_err(pchip->dev, "fail : i2c access to register.\n");
> + else
> + ret = bl->props.brightness;
> +
> + return ret;
> +}
> +
> +static int lp8860_bled_get_brightness(struct backlight_device *bl,
> + enum lp8860_leds nsr)
> +{
> + struct lp8860_chip *pchip = bl_get_data(bl);
> + unsigned int rval_h, rval_l;
> + int ret = -EINVAL;
> +
> + switch (nsr) {
> + case LP8860_LED0:
> + ret = regmap_read(pchip->regmap, REG_CL0_BRT_H, &rval_h);
> + ret |= regmap_read(pchip->regmap, REG_CL0_BRT_L, &rval_l);
> + break;
> + case LP8860_LED1:
> + ret = regmap_read(pchip->regmap, REG_CL1_BRT_H, &rval_h);
> + ret |= regmap_read(pchip->regmap, REG_CL1_BRT_L, &rval_l);
> + break;
> + case LP8860_LED2:
> + ret = regmap_read(pchip->regmap, REG_CL2_BRT_H, &rval_h);
> + ret |= regmap_read(pchip->regmap, REG_CL2_BRT_L, &rval_l);
> + break;
> + case LP8860_LED3:
> + ret = regmap_read(pchip->regmap, REG_CL3_BRT_H, &rval_h);
> + ret |= regmap_read(pchip->regmap, REG_CL3_BRT_L, &rval_l);
> + break;
> + default:
> + BUG();
> + }
> + if (ret < 0) {
> + dev_err(pchip->dev, "fail : i2c access to register.\n");
> + return ret;
> + }
> + bl->props.brightness = (rval_h << 8) | rval_l;
> + return bl->props.brightness;
> +}
> +
> +static int lp8860_update_status_bled0(struct backlight_device *bl)
> +{
> + return lp8860_bled_update_status(bl, LP8860_LED0);
> +}
> +
> +static int lp8860_get_brightness_bled0(struct backlight_device *bl)
> +{
> + return lp8860_bled_get_brightness(bl, LP8860_LED0);
> +}
> +
> +static int lp8860_update_status_bled1(struct backlight_device *bl)
> +{
> + return lp8860_bled_update_status(bl, LP8860_LED1);
> +}
> +
> +static int lp8860_get_brightness_bled1(struct backlight_device *bl)
> +{
> + return lp8860_bled_get_brightness(bl, LP8860_LED1);
> +}
> +
> +static int lp8860_update_status_bled2(struct backlight_device *bl)
> +{
> + return lp8860_bled_update_status(bl, LP8860_LED2);
> +}
> +
> +static int lp8860_get_brightness_bled2(struct backlight_device *bl)
> +{
> + return lp8860_bled_get_brightness(bl, LP8860_LED2);
> +}
> +
> +static int lp8860_update_status_bled3(struct backlight_device *bl)
> +{
> + return lp8860_bled_update_status(bl, LP8860_LED3);
> +}
> +
> +static int lp8860_get_brightness_bled3(struct backlight_device *bl)
> +{
> + return lp8860_bled_get_brightness(bl, LP8860_LED3);
> +}
> +
> +#define lp8860_bled_ops(_id)\
> +{\
> + .options = BL_CORE_SUSPENDRESUME,\
> + .update_status = lp8860_update_status_bled##_id,\
> + .get_brightness = lp8860_get_brightness_bled##_id,\
> +}
> +
> +static const struct backlight_ops lp8860_bled_ops[LP8860_LED_MAX] = {
> + [LP8860_LED0] = lp8860_bled_ops(0),
> + [LP8860_LED1] = lp8860_bled_ops(1),
> + [LP8860_LED2] = lp8860_bled_ops(2),
> + [LP8860_LED3] = lp8860_bled_ops(3),
> +};
> +
> +/* current control */
> +static int lp8860_set_current(struct device *dev,
> + const char *buf, enum lp8860_leds nsr)
> +{
> + struct lp8860_chip *pchip = dev_get_drvdata(dev);
> + unsigned int ival;
> + ssize_t ret;
> +
> + ret = kstrtouint(buf, 10, &ival);
> + if (ret)
> + return ret;
> +
> + switch (nsr) {
> + case LP8860_LED0:
> + ival = min_t(unsigned int, ival, LP8860_LED0_BR_MAX);
> + ret = regmap_write(pchip->regmap, REG_CL0_I_H, ival >> 8);
> + ret |= regmap_write(pchip->regmap, REG_CL0_I_L, ival & 0xff);
> + break;
> + case LP8860_LED1:
> + ival = min_t(unsigned int, ival, LP8860_LED1_BR_MAX);
> + ret = regmap_write(pchip->regmap, REG_CL1_I, ival & 0xff);
> + break;
> + case LP8860_LED2:
> + ival = min_t(unsigned int, ival, LP8860_LED2_BR_MAX);
> + ret = regmap_write(pchip->regmap, REG_CL2_I, ival & 0xff);
> + break;
> + case LP8860_LED3:
> + ival = min_t(unsigned int, ival, LP8860_LED3_BR_MAX);
> + ret = regmap_write(pchip->regmap, REG_CL3_I, ival & 0xff);
> + break;
> + default:
> + BUG();
> + }
> + if (ret < 0)
> + dev_err(pchip->dev, "fail : i2c access error.\n");
> +
> + return ret;
> +}
> +
> +static ssize_t lp8860_current_store_bled0(struct device *dev,
> + struct device_attribute *devAttr,
> + const char *buf, size_t size)
> +{
> + int ret;
> +
> + ret = lp8860_set_current(dev, buf, LP8860_LED0);
> + if (ret < 0)
> + return ret;
> + return size;
> +}
> +
> +static ssize_t lp8860_current_store_bled1(struct device *dev,
> + struct device_attribute *devAttr,
> + const char *buf, size_t size)
> +{
> + int ret;
> +
> + ret = lp8860_set_current(dev, buf, LP8860_LED1);
> + if (ret < 0)
> + return ret;
> + return size;
> +}
> +
> +static ssize_t lp8860_current_store_bled2(struct device *dev,
> + struct device_attribute *devAttr,
> + const char *buf, size_t size)
> +{
> + int ret;
> +
> + ret = lp8860_set_current(dev, buf, LP8860_LED2);
> + if (ret < 0)
> + return ret;
> + return size;
> +}
> +
> +static ssize_t lp8860_current_store_bled3(struct device *dev,
> + struct device_attribute *devAttr,
> + const char *buf, size_t size)
> +{
> + int ret;
> +
> + ret = lp8860_set_current(dev, buf, LP8860_LED3);
> + if (ret < 0)
> + return ret;
> + return size;
> +}
> +
> +#define lp8860_attr(_name, _show, _store)\
> +{\
> + .attr = {\
> + .name = _name,\
> + .mode = S_IWUSR,\
> + },\
> + .show = _show,\
> + .store = _store,\
> +}
> +
> +static struct device_attribute lp8860_dev_attr[LP8860_LED_MAX] = {
> + [LP8860_LED0] = lp8860_attr("current", NULL,
> + lp8860_current_store_bled0),
> + [LP8860_LED1] = lp8860_attr("current", NULL,
> + lp8860_current_store_bled1),
> + [LP8860_LED2] = lp8860_attr("current", NULL,
> + lp8860_current_store_bled2),
> + [LP8860_LED3] = lp8860_attr("current", NULL,
> + lp8860_current_store_bled3),
> +};
> +
> +/*
> + * eeprom write and readback to check.
> + * eeprom register range is from 60h to 78h
> + * buffer value to write data [reg] [data]
> + * e.g) to change the register 0x60 value to 0xff
> + * buffer value should be 60 ff
> + */
> +static ssize_t lp8860_eeprom_store(struct device *dev,
> + struct device_attribute *devAttr,
> + const char *buf, size_t size)
> +{
> + struct lp8860_chip *pchip = dev_get_drvdata(dev);
> + unsigned int reg, data, rval;
> + char *tok;
> + int ret;
> +
> + /* register no. */
> + tok = strsep((char **)&buf, " ,\n");
> + if (tok = NULL)
> + goto err_input;
> + ret = kstrtouint(tok, 16, ®);
> + if (ret)
> + goto err_input;
> +
> + /* register value */
> + tok = strsep((char **)&buf, " ,\n");
> + if (tok = NULL)
> + goto err_input;
> + ret = kstrtouint(tok, 16, &data);
> + if (ret)
> + goto err_input;
> + /*
> + * EEPROM Programming sequence
> + * (program data permanently from registers to NVM)
> + * 1. Unlock EEPROM by writing
> + * the unlock codes to register 1Ah(08, BA, EF)
> + * 2. Write data to EEPROM registers (address 60h...78h)
> + * 3. Write EE_PROG to 1 in address 19h. (02h to address 19h)
> + * 4. Wait 100ms
If possible, please add the reason why 100ms is necessary.
100ms is very huge delay.
> + * 5. Write EE_PROG to 0 in address 19h. (00h to address 19h)
> + */
> + if (reg < REG_EEPROM_START || reg > REG_EEPROM_END || data > 0xff)
> + goto err_input;
> + ret = regmap_write(pchip->regmap, REG_ROM_UNLOCK, 0x08);
> + ret |= regmap_write(pchip->regmap, REG_ROM_UNLOCK, 0xba);
> + ret |= regmap_write(pchip->regmap, REG_ROM_UNLOCK, 0xef);
> + ret |= regmap_write(pchip->regmap, reg, data);
> + ret |= regmap_write(pchip->regmap, REG_ROM_CTRL, 0x02);
> + msleep(100);
> + ret |= regmap_write(pchip->regmap, REG_ROM_CTRL, 0x00);
> + if (ret < 0)
> + goto err_i2c;
> +
> + /* read back */
> + ret = regmap_write(pchip->regmap, REG_ROM_UNLOCK, 0x08);
> + ret |= regmap_write(pchip->regmap, REG_ROM_UNLOCK, 0xba);
> + ret |= regmap_write(pchip->regmap, REG_ROM_UNLOCK, 0xef);
> + ret |= regmap_write(pchip->regmap, REG_ROM_CTRL, 0x01);
> + msleep(100);
> + ret |= regmap_write(pchip->regmap, REG_ROM_CTRL, 0x00);
> + ret |= regmap_read(pchip->regmap, reg, &rval);
> + if (ret < 0)
> + goto err_i2c;
> + if (rval != data)
> + dev_err(pchip->dev, "fail : eeprom did not change.\n");
> +
> + return size;
> +
> +err_i2c:
> + dev_err(pchip->dev, "fail : i2c access error.\n");
> + return ret;
> +
> +err_input:
> + dev_err(pchip->dev, "fail : input fail.\n");
> + return -EINVAL;
> +}
> +
> +static DEVICE_ATTR(eeprom, S_IWUSR, NULL, lp8860_eeprom_store);
> +
> +/* backlight register and remove */
> +static char *lp8860_bled_name[LP8860_LED_MAX] = {
> + [LP8860_LED0] = "bled0",
> + [LP8860_LED1] = "bled1",
> + [LP8860_LED2] = "bled2",
> + [LP8860_LED3] = "bled3",
> +};
> +
> +static int lp8860_backlight_remove(struct lp8860_chip *pchip)
> +{
> + int icnt;
> +
> + device_remove_file(&(pchip->bled[0]->dev), &dev_attr_eeprom);
> + for (icnt = LP8860_LED0; icnt < LP8860_LED_MAX; icnt++) {
> + if (pchip->bled[icnt]) {
> + backlight_device_unregister(pchip->bled[icnt]);
> + device_remove_file(&(pchip->bled[icnt]->dev),
> + &lp8860_dev_attr[icnt]);
> + }
> + }
> + return 0;
> +}
> +
> +static int lp8860_backlight_registers(struct lp8860_chip *pchip)
> +{
> + struct backlight_properties props;
> + struct lp8860_platform_data *pdata = pchip->pdata;
> + int icnt, ret;
> +
> + props.type = BACKLIGHT_RAW;
> + for (icnt = LP8860_LED0; icnt < LP8860_LED_MAX; icnt++) {
> + props.max_brightness = pdata->max_brt[icnt];
> + pchip->bled[icnt] > + backlight_device_register(lp8860_bled_name[icnt],
devm_* functions will make the code simpler.
Thus, please use devm_backlight_device_register(), instead of
backlight_device_register().
> + pchip->dev, pchip,
> + &lp8860_bled_ops[icnt], &props);
> + if (IS_ERR(pchip->bled[icnt])) {
> + dev_err(pchip->dev, "fail : backlight register.\n");
> + ret = PTR_ERR(pchip->bled[icnt]);
> + goto err_out;
> + }
> +
> + ret = device_create_file(&(pchip->bled[icnt]->dev),
> + &lp8860_dev_attr[icnt]);
> + if (ret < 0) {
> + dev_err(pchip->dev, "fail : to add sysfs entries.\n");
> + goto err_out;
> + }
> + }
> + /* access eeprom */
> + ret = device_create_file(&(pchip->bled[LP8860_LED0]->dev),
> + &dev_attr_eeprom);
> + if (ret < 0) {
> + dev_err(pchip->dev, "fail : to add sysfs entries.\n");
> + goto err_out;
> + }
> + return 0;
> +
> +err_out:
> + lp8860_backlight_remove(pchip);
> + return ret;
> +}
> +
> +static const struct regmap_config lp8860_regmap = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = REG_MAX,
> +};
> +
> +static int lp8860_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct lp8860_chip *pchip;
> + struct lp8860_platform_data *pdata = dev_get_platdata(&client->dev);
> + int ret, icnt;
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> + dev_err(&client->dev, "fail : i2c functionality check.\n");
> + return -EOPNOTSUPP;
> + }
> +
> + pchip = devm_kzalloc(&client->dev,
> + sizeof(struct lp8860_chip), GFP_KERNEL);
> + if (!pchip)
> + return -ENOMEM;
> + pchip->dev = &client->dev;
> +
> + pchip->regmap = devm_regmap_init_i2c(client, &lp8860_regmap);
> + if (IS_ERR(pchip->regmap)) {
> + ret = PTR_ERR(pchip->regmap);
> + dev_err(pchip->dev, "fail : allocate i2c register map.\n");
> + return ret;
> + }
> +
> + if (pdata = NULL) {
> + pdata = devm_kzalloc(pchip->dev,
> + sizeof(struct lp8860_platform_data),
> + GFP_KERNEL);
> + if (pdata = NULL)
> + return -ENOMEM;
> + pdata->max_brt[LP8860_LED0] = 65535;
> + for (icnt = LP8860_LED1; icnt < LP8860_LED_MAX; icnt++)
> + pdata->max_brt[icnt] = 8191;
> + pchip->pdata = pdata;
> + } else {
> + pchip->pdata = pdata;
> + }
> + i2c_set_clientdata(client, pchip);
> + ret = lp8860_backlight_registers(pchip);
> + return ret;
> +}
> +
> +static int lp8860_remove(struct i2c_client *client)
> +{
> + return lp8860_backlight_remove(i2c_get_clientdata(client));
> +}
> +
> +static const struct i2c_device_id lp8860_id[] = {
> + {LP8860_NAME, 0},
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, lp8860_id);
> +static struct i2c_driver lp8860_i2c_driver = {
> + .driver = {
> + .name = LP8860_NAME,
> + },
Fix the indent style as below.
+ },
> + .probe = lp8860_probe,
> + .remove = lp8860_remove,
> + .id_table = lp8860_id,
> +};
> +
> +module_i2c_driver(lp8860_i2c_driver);
> +
> +MODULE_DESCRIPTION("Texas Instruments LP8860 Backlight Driver");
> +MODULE_AUTHOR("Daniel Jeong <gshark.jeong@gmail.com>");
> +MODULE_AUTHOR("Ldd Mlp <ldd-mlp@list.ti.com>");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/platform_data/lp8860_bl.h b/include/linux/platform_data/lp8860_bl.h
> new file mode 100644
> index 0000000..61bd0f5
> --- /dev/null
> +++ b/include/linux/platform_data/lp8860_bl.h
> @@ -0,0 +1,54 @@
> +/*
> + * Simple driver for Texas Instruments LM3642 LED Flash driver chip
> + * Copyright (C) 2014 Texas Instruments
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#ifndef __LINUX_LP8860_H
> +#define __LINUX_LP8860_H
Prefix 'LINUX' looks redundant.
Please replace '__LINUX_LP8860_H' with '__LP8860_H'.
If the datasheet of 'lp8860' is not closed, please let us
know where the datasheet is. It would be helpful for reviewing
your patch.
Best regards,
Jingoo Han
> +
> +#define LP8860_NAME "lp8860"
> +#define LP8860_ADDR 0x2d
> +
> +#define LP8860_LED0_BR_MAX 65535
> +#define LP8860_LED1_BR_MAX 8191
> +#define LP8860_LED2_BR_MAX 8191
> +#define LP8860_LED3_BR_MAX 8191
> +
> +#define LP8860_LED0_I_MAX 4095
> +#define LP8860_LED1_I_MAX 255
> +#define LP8860_LED2_I_MAX 255
> +#define LP8860_LED3_I_MAX 255
> +
> +enum lp8860_leds {
> + LP8860_LED0 = 0,
> + LP8860_LED1,
> + LP8860_LED2,
> + LP8860_LED3,
> + LP8860_LED_MAX
> +};
> +
> +enum lp8860_ctrl_mode {
> + LP8860_CTRL_I2C = 0,
> + LP8860_CTRL_I2C_PWM,
> +};
> +
> +/* struct lp8860 platform data
> + * @mode : control mode
> + * @max_brt : maximum brightness.
> + * LED0 0 ~ 65535
> + * LED1 0 ~ 8191
> + * LED2 0 ~ 8191
> + * LED3 0 ~ 8191
> + */
> +struct lp8860_platform_data {
> +
> + enum lp8860_ctrl_mode mode;
> + int max_brt[LP8860_LED_MAX];
> +};
> +
> +#endif /* __LINUX_LP8860_H */
> --
> 1.7.9.5
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Tomi Valkeinen @ 2014-03-10 10:32 UTC (permalink / raw)
To: Philipp Zabel
Cc: devicetree@vger.kernel.org, Linux Fbdev development list,
Russell King - ARM Linux, Sascha Hauer, Tomasz Figa,
DRI Development, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Geert Uytterhoeven, Laurent Pinchart,
Daniel Vetter, linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth
In-Reply-To: <1394201859.16309.14.camel@paszta.hi.pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
On 07/03/14 16:17, Philipp Zabel wrote:
> Hi,
>
> Am Donnerstag, den 06.03.2014, 10:52 +0200 schrieb Tomi Valkeinen:
>> analog;
>> digital-single-link;
>> digital-dual-link;
>>
>> My reasoning to the format I chose was basically that when a connector
>> supports 'digital', it contains TMDS clock and TMDS data for link 1.
>> Adding dual link to that adds only TMDS data for link 2, so the second
>> data link is kind of an additional feature, marked with a flag.
>>
>> Not a very big argument, and I'm fine with other format suggestions.
>
> I'd prefer the analog / digital / dual-link variant for aesthetic
> reasons. But looking at other connector types, I wonder if this should
> be generalized even more:
>
> For HDMI/DVI (digital) single-link means one clock pair and 3 TMDS data
> pairs, dual-link means one clock pair and 6 data pairs.
>
> On LVDS connectors, there usually are one clock pair and three (18-bit)
> or four (24-bit) LVDS data pairs, in dual channel configuration two
> clock pairs and 6 or 8 data pairs are used.
>
> For DisplayPort there is no separate clock pair, but 1 to 4 data pairs,
> and MIPI DSI again has one clock pair and a one or more data pairs.
>
> There are already optional endpoint configuration properties
> 'data-lanes' and 'clock-lanes' for MIPI CSI-2 defined in
> Documentation/devicetree/bindings/media/video-interfaces.txt.
> Could/should this be aligned with the same?
Hmm. Well, at least for HDMI and DP we anyway need the connector type,
which tells the form factor, and it also tells the TMDS details. So, we
could define the lanes in a common way, but we'd still need extra
information.
For MIPI DSI and (I believe) LVDS, we don't need connectors. Connectors,
as described in this binding, are meant for standard hotpluggable
connectors to which you can connect any device that has that same connector.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ 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