* Re: Introduce a new helper framework for buffer synchronization
From: Rob Clark @ 2013-05-14 13:38 UTC (permalink / raw)
To: Inki Dae
Cc: linux-fbdev, DRI mailing list, Kyungmin Park, myungjoo.ham,
YoungJun Cho, linux-arm-kernel, linux-media
In-Reply-To: <006a01ce504e$0de3b0e0$29ab12a0$%dae@samsung.com>
On Mon, May 13, 2013 at 10:52 PM, Inki Dae <inki.dae@samsung.com> wrote:
>> well, for cache management, I think it is a better idea.. I didn't
>> really catch that this was the motivation from the initial patch, but
>> maybe I read it too quickly. But cache can be decoupled from
>> synchronization, because CPU access is not asynchronous. For
>> userspace/CPU access to buffer, you should:
>>
>> 1) wait for buffer
>> 2) prepare-access
>> 3) ... do whatever cpu access to buffer ...
>> 4) finish-access
>> 5) submit buffer for new dma-operation
>>
>
>
> For data flow from CPU to DMA device,
> 1) wait for buffer
> 2) prepare-access (dma_buf_begin_cpu_access)
> 3) cpu access to buffer
>
>
> For data flow from DMA device to CPU
> 1) wait for buffer
Right, but CPU access isn't asynchronous (from the point of view of
the CPU), so there isn't really any wait step at this point. And if
you do want the CPU to be able to signal a fence from userspace for
some reason, you probably what something file/fd based so the
refcnting/cleanup when process dies doesn't leave some pending DMA
action wedged. But I don't really see the point of that complexity
when the CPU access isn't asynchronous in the first place.
BR,
-R
> 2) finish-access (dma_buf_end _cpu_access)
> 3) dma access to buffer
>
> 1) and 2) are coupled with one function: we have implemented
> fence_helper_commit_reserve() for it.
>
> Cache control(cache clean or cache invalidate) is performed properly
> checking previous access type and current access type.
> And the below is actual codes for it,
^ permalink raw reply
* Re: [PATCH 1/2] video: exynos_dp: Add parsing of gpios pins to exynos-dp driver
From: Tomasz Figa @ 2013-05-14 14:16 UTC (permalink / raw)
To: Vikas Sajjan
Cc: jg1.han, linux-samsung-soc, kgene.kim, devicetree-discuss,
patches, linaro-kernel, rpurdie, FlorianSchandinat, linux-fbdev
In-Reply-To: <1368536152-13370-2-git-send-email-vikas.sajjan@linaro.org>
Hi Vikas,
On Tuesday 14 of May 2013 18:25:51 Vikas Sajjan wrote:
> Adds GPIO parsing functionality for "LCD backlight" and "LCD enable"
> GPIO pins of exynos dp controller.
>
> Signed-off-by: Vikas Sajjan <vikas.sajjan@linaro.org>
> ---
> drivers/video/exynos/exynos_dp_core.c | 45
> +++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+)
>
I don't think that Exynos DP driver is right place for such code. Backlight
and LCD drivers are responsible for backlight and LCD power control using
backlight and LCD subsystems.
IMHO the correct solution would be to either extend existing backlight/lcd
drivers found in drivers/video/backlight to support direct GPIO control and
parse GPIO pins from device tree or create new gpio_bl and gpio_lcd drivers.
CCing Richard, Florian and linux-fbdev.
Best regards,
Tomasz
^ permalink raw reply
* Re: Build regressions/improvements in v3.10-rc1 (cris)
From: Jesper Nilsson @ 2013-05-14 16:33 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Kernel Development, Linux Fbdev development list,
linux-cris-kernel
In-Reply-To: <CAMuHMdW6p6tP=wwBNV9uAAbwwgpyzMiPxsBSJNOUazhznYC4iQ@mail.gmail.com>
On Tue, May 14, 2013 at 02:06:51PM +0200, Geert Uytterhoeven wrote:
> On Sun, May 12, 2013 at 10:44 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > drivers/video/console/fonts.c:71:2: error: #error No fonts configured.: 2 errors in 2 logs
> > v3.10-rc1/cris/cris-allmodconfig v3.10-rc1/cris/cris-allyesconfig
> >
> > Fbdev issue?
>
> This is caused by cris not using the generic drivers/Kconfig, and thus not
> traversing drivers/video/console/Kconfig.
> As the build system does traverse drivers/video/console/Makefile, fonts.c
> is compiled with an inconsistent configuration.
>
> Two solutions:
> 1. Add drivers/video/console/Kconfig to arch/cris/Kconfig,
> 2. Switch cris to drivers/Kconfig,
>
> I prefer two, as this is what's done by all (except h8300) other
> architectures. This will seriously broaden the scope of allmodconfig,
> though, and require more fixes (e.g. missing <asm/vga.h>).
I would have no objections a conversion of CRIS to use the
drivers/Kconfig, though it feels a bit strange to compile
video drivers for SoCs that don't have any video out hardware.
> Note: The decision logic for compiling drivers/video/console/fonts.c is
> overly complicated, and seems to be buggy for some stuff living
> outside drivers drivers/video (drivers/media/platform/vivi.c and
> drivers/staging/media/solo6x10/solo6x10-enc.c). I think this should
> be resolved in Kconfig logic, using a new FONT_SUPPORT
> symbol (FONTS is already taken).
>
> 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
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply
* Re: [PATCH V5 5/5] fbcon: queue work on power efficient wq
From: Tejun Heo @ 2013-05-14 17:57 UTC (permalink / raw)
To: Viresh Kumar
Cc: davem, airlied, axboe, tglx, peterz, mingo, rostedt,
linux-rt-users, linux-kernel, robin.randhawa, Steve.Bannister,
Liviu.Dudau, charles.garcia-tobin, arvind.chauhan, linaro-kernel,
patches, linux-fbdev
In-Reply-To: <89924f001e3ddd66ab41a16500569a976ea846fd.1366803121.git.viresh.kumar@linaro.org>
On Wed, Apr 24, 2013 at 05:12:57PM +0530, Viresh Kumar wrote:
> fbcon uses workqueues and it has no real dependency of scheduling these on the
> cpu which scheduled them.
>
> On a idle system, it is observed that and idle cpu wakes up many times just to
> service this work. It would be better if we can schedule it on a cpu which the
> scheduler believes to be the most appropriate one.
>
> This patch replaces system_wq with system_power_efficient_wq.
>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Dave, applied this to wq/for-3.11. Please holler if you want this to
be routed differently.
Thanks!
--
tejun
^ permalink raw reply
* Re: [PATCH v3 6/9] radeon: Switch to arch_phys_wc_add and add a missing ..._del
From: Andy Lutomirski @ 2013-05-14 21:35 UTC (permalink / raw)
To: Jerome Glisse
Cc: Alex Deucher, linux-kernel, dri-devel, linux-fbdev, Daniel Vetter,
Dave Airlie
In-Reply-To: <CAH3drwbSLdjd4Y8x8YfzhM5WK+A-L7mnYeS0kdqu7MwEB5kbCQ@mail.gmail.com>
On Tue, May 14, 2013 at 6:37 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
> On Tue, May 14, 2013 at 8:58 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> On Mon, May 13, 2013 at 7:58 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>>
>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>
> I believe it will break something but we could deal with the fallout
> once it happens.
FWIW, I'm running with this code on my machine right now using the
radeon driver. Everything seems fine. If I build without MTRRs and
without PAT, though, graphics are slow (as expected). So I think
everything's okay.
--Andy
^ permalink raw reply
* [PATCH] ps3fb: Fix compile warning
From: Geoff Levand @ 2013-05-15 3:12 UTC (permalink / raw)
To: linux-fbdev
Fix the following compile warning when -Wparentheses is set:
drivers/video/ps3fb.c: warning: suggest parentheses around ‘+’ inside ‘<<’
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
Hi Florian,
Please apply.
-Geoff
drivers/video/ps3fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
index d9f08c6..a397271d 100644
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -710,7 +710,7 @@ static int ps3fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
r = vm_iomap_memory(vma, info->fix.smem_start, info->fix.smem_len);
dev_dbg(info->device, "ps3fb: mmap framebuffer P(%lx)->V(%lx)\n",
- info->fix.smem_start + vma->vm_pgoff << PAGE_SHIFT,
+ (info->fix.smem_start + vma->vm_pgoff) << PAGE_SHIFT,
vma->vm_start);
return r;
--
1.8.1.2
^ permalink raw reply related
* RE: Introduce a new helper framework for buffer synchronization
From: Inki Dae @ 2013-05-15 5:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51909DB4.2060208@canonical.com>
> -----Original Message-----
> From: Rob Clark [mailto:robdclark@gmail.com]
> Sent: Tuesday, May 14, 2013 10:39 PM
> To: Inki Dae
> Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun
> Cho; linux-arm-kernel@lists.infradead.org; linux-media@vger.kernel.org
> Subject: Re: Introduce a new helper framework for buffer synchronization
>
> On Mon, May 13, 2013 at 10:52 PM, Inki Dae <inki.dae@samsung.com> wrote:
> >> well, for cache management, I think it is a better idea.. I didn't
> >> really catch that this was the motivation from the initial patch, but
> >> maybe I read it too quickly. But cache can be decoupled from
> >> synchronization, because CPU access is not asynchronous. For
> >> userspace/CPU access to buffer, you should:
> >>
> >> 1) wait for buffer
> >> 2) prepare-access
> >> 3) ... do whatever cpu access to buffer ...
> >> 4) finish-access
> >> 5) submit buffer for new dma-operation
> >>
> >
> >
> > For data flow from CPU to DMA device,
> > 1) wait for buffer
> > 2) prepare-access (dma_buf_begin_cpu_access)
> > 3) cpu access to buffer
> >
> >
> > For data flow from DMA device to CPU
> > 1) wait for buffer
>
> Right, but CPU access isn't asynchronous (from the point of view of
> the CPU), so there isn't really any wait step at this point. And if
> you do want the CPU to be able to signal a fence from userspace for
> some reason, you probably what something file/fd based so the
> refcnting/cleanup when process dies doesn't leave some pending DMA
> action wedged. But I don't really see the point of that complexity
> when the CPU access isn't asynchronous in the first place.
>
There was my missing comments, please see the below sequence.
For data flow from CPU to DMA device and then from DMA device to CPU,
1) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...)
- including prepare-access (dma_buf_begin_cpu_access)
2) cpu access to buffer
3) wait for buffer <- at device driver
- but CPU is already accessing the buffer so blocked.
4) signal <- at user side - ioctl(fd, DMA_BUF_PUT_FENCE, ...)
5) the thread, blocked at 3), is waked up by 4).
- and then finish-access (dma_buf_end_cpu_access)
6) dma access to buffer
7) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...)
- but DMA is already accessing the buffer so blocked.
8) signal <- at device driver
9) the thread, blocked at 7), is waked up by 8)
- and then prepare-access (dma_buf_begin_cpu_access)
10 cpu access to buffer
Basically, 'wait for buffer' includes buffer synchronization, committing
processing, and cache operation. The buffer synchronization means that a
current thread should wait for other threads accessing a shared buffer until
the completion of their access. And the committing processing means that a
current thread possesses the shared buffer so any trying to access the
shared buffer by another thread makes the thread to be blocked. However, as
I already mentioned before, it seems that these user interfaces are so ugly
yet. So we need better way.
Give me more comments if there is my missing point :)
Thanks,
Inki Dae
> BR,
> -R
>
>
> > 2) finish-access (dma_buf_end _cpu_access)
> > 3) dma access to buffer
> >
> > 1) and 2) are coupled with one function: we have implemented
> > fence_helper_commit_reserve() for it.
> >
> > Cache control(cache clean or cache invalidate) is performed properly
> > checking previous access type and current access type.
> > And the below is actual codes for it,
^ permalink raw reply
* [PATCH] console/font: Refactor font support code selection logic
From: Geert Uytterhoeven @ 2013-05-15 11:40 UTC (permalink / raw)
To: Florian Tobias Schandinat, linux-fbdev
Cc: Hans Verkuil, Ismael Luceno, Thomas Winischhofer,
Thomas Bogendoerfer, Helge Deller, linux-media, devel, linux-usb,
linux-kernel, Geert Uytterhoeven
The current Makefile rules to build font support are messy and buggy.
Replace them by Kconfig rules:
- Introduce CONFIG_FONT_SUPPORT, which controls the building of all font
code,
- Select CONFIG_FONT_SUPPORT for all drivers that use fonts,
- Select CONFIG_FONT_8x16 for all drivers that default to the VGA8x16
font,
- Drop the bogus console dependency for CONFIG_VIDEO_VIVI.
This fixes (if CONFIG_SOLO6X10=y and there are no built-in console
drivers):
drivers/built-in.o: In function `solo_osd_print':
drivers/staging/media/solo6x10/solo6x10-enc.c:144: undefined reference to `.find_font'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/media/platform/Kconfig | 2 +-
drivers/staging/media/solo6x10/Kconfig | 2 ++
drivers/usb/misc/sisusbvga/Kconfig | 1 +
drivers/video/console/Kconfig | 12 ++++++++++--
drivers/video/console/Makefile | 14 +++++---------
5 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0cbe1ff..c1f29d5 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -220,7 +220,7 @@ if V4L_TEST_DRIVERS
config VIDEO_VIVI
tristate "Virtual Video Driver"
depends on VIDEO_DEV && VIDEO_V4L2 && !SPARC32 && !SPARC64
- depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE
+ select FONT_SUPPORT
select FONT_8x16
select VIDEOBUF2_VMALLOC
default n
diff --git a/drivers/staging/media/solo6x10/Kconfig b/drivers/staging/media/solo6x10/Kconfig
index ec32776..b34bb6c 100644
--- a/drivers/staging/media/solo6x10/Kconfig
+++ b/drivers/staging/media/solo6x10/Kconfig
@@ -1,6 +1,8 @@
config SOLO6X10
tristate "Softlogic 6x10 MPEG codec cards"
depends on PCI && VIDEO_DEV && SND && I2C
+ select FONT_SUPPORT
+ select FONT_8x16
select VIDEOBUF2_DMA_SG
select VIDEOBUF2_DMA_CONTIG
select SND_PCM
diff --git a/drivers/usb/misc/sisusbvga/Kconfig b/drivers/usb/misc/sisusbvga/Kconfig
index 0d03a52..36bc28c 100644
--- a/drivers/usb/misc/sisusbvga/Kconfig
+++ b/drivers/usb/misc/sisusbvga/Kconfig
@@ -2,6 +2,7 @@
config USB_SISUSBVGA
tristate "USB 2.0 SVGA dongle support (Net2280/SiS315)"
depends on (USB_MUSB_HDRC || USB_EHCI_HCD)
+ select FONT_SUPPORT if USB_SISUSBVGA_CON
---help---
Say Y here if you intend to attach a USB2VGA dongle based on a
Net2280 and a SiS315 chip.
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index bc922c4..baf27dc 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -62,6 +62,7 @@ config MDA_CONSOLE
config SGI_NEWPORT_CONSOLE
tristate "SGI Newport Console support"
depends on SGI_IP22
+ select FONT_SUPPORT
help
Say Y here if you want the console on the Newport aka XL graphics
card of your Indy. Most people say Y here.
@@ -91,6 +92,7 @@ config FRAMEBUFFER_CONSOLE
tristate "Framebuffer Console support"
depends on FB
select CRC32
+ select FONT_SUPPORT
help
Low-level framebuffer-based console driver.
@@ -123,12 +125,18 @@ config FRAMEBUFFER_CONSOLE_ROTATION
config STI_CONSOLE
bool "STI text console"
depends on PARISC
+ select FONT_SUPPORT
default y
help
The STI console is the builtin display/keyboard on HP-PARISC
machines. Say Y here to build support for it into your kernel.
The alternative is to use your primary serial port as a console.
+config FONT_SUPPORT
+ tristate
+
+if FONT_SUPPORT
+
config FONTS
bool "Select compiled-in fonts"
depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE
@@ -158,7 +166,6 @@ config FONT_8x8
config FONT_8x16
bool "VGA 8x16 font" if FONTS
- depends on FRAMEBUFFER_CONSOLE || SGI_NEWPORT_CONSOLE || STI_CONSOLE || USB_SISUSBVGA_CON
default y if !SPARC && !FONTS
help
This is the "high resolution" font for the VGA frame buffer (the one
@@ -226,7 +233,6 @@ config FONT_10x18
config FONT_AUTOSELECT
def_bool y
- depends on FRAMEBUFFER_CONSOLE || SGI_NEWPORT_CONSOLE || STI_CONSOLE || USB_SISUSBVGA_CON
depends on !FONT_8x8
depends on !FONT_6x11
depends on !FONT_7x14
@@ -238,5 +244,7 @@ config FONT_AUTOSELECT
depends on !FONT_10x18
select FONT_8x16
+endif # FONT_SUPPORT
+
endmenu
diff --git a/drivers/video/console/Makefile b/drivers/video/console/Makefile
index a862e91..3a11b63 100644
--- a/drivers/video/console/Makefile
+++ b/drivers/video/console/Makefile
@@ -18,14 +18,14 @@ font-objs-$(CONFIG_FONT_MINI_4x6) += font_mini_4x6.o
font-objs += $(font-objs-y)
-# Each configuration option enables a list of files.
+obj-$(CONFIG_FONT_SUPPORT) += font.o
obj-$(CONFIG_DUMMY_CONSOLE) += dummycon.o
-obj-$(CONFIG_SGI_NEWPORT_CONSOLE) += newport_con.o font.o
-obj-$(CONFIG_STI_CONSOLE) += sticon.o sticore.o font.o
+obj-$(CONFIG_SGI_NEWPORT_CONSOLE) += newport_con.o
+obj-$(CONFIG_STI_CONSOLE) += sticon.o sticore.o
obj-$(CONFIG_VGA_CONSOLE) += vgacon.o
obj-$(CONFIG_MDA_CONSOLE) += mdacon.o
-obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon.o bitblit.o font.o softcursor.o
+obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon.o bitblit.o softcursor.o
ifeq ($(CONFIG_FB_TILEBLITTING),y)
obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += tileblit.o
endif
@@ -34,8 +34,4 @@ obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon_rotate.o fbcon_cw.o fbcon_ud.o \
fbcon_ccw.o
endif
-obj-$(CONFIG_FB_STI) += sticore.o font.o
-
-ifeq ($(CONFIG_USB_SISUSBVGA_CON),y)
-obj-$(CONFIG_USB_SISUSBVGA) += font.o
-endif
+obj-$(CONFIG_FB_STI) += sticore.o
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] console/font: Refactor font support code selection logic
From: Hans Verkuil @ 2013-05-15 11:45 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Florian Tobias Schandinat, linux-fbdev, Ismael Luceno,
Thomas Winischhofer, Thomas Bogendoerfer, Helge Deller,
linux-media, devel, linux-usb, linux-kernel
In-Reply-To: <1368618050-26895-1-git-send-email-geert@linux-m68k.org>
On Wed 15 May 2013 13:40:50 Geert Uytterhoeven wrote:
> The current Makefile rules to build font support are messy and buggy.
> Replace them by Kconfig rules:
> - Introduce CONFIG_FONT_SUPPORT, which controls the building of all font
> code,
> - Select CONFIG_FONT_SUPPORT for all drivers that use fonts,
> - Select CONFIG_FONT_8x16 for all drivers that default to the VGA8x16
> font,
> - Drop the bogus console dependency for CONFIG_VIDEO_VIVI.
>
> This fixes (if CONFIG_SOLO6X10=y and there are no built-in console
> drivers):
>
> drivers/built-in.o: In function `solo_osd_print':
> drivers/staging/media/solo6x10/solo6x10-enc.c:144: undefined reference to `.find_font'
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
That looks much more sane. Thanks!
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
> ---
> drivers/media/platform/Kconfig | 2 +-
> drivers/staging/media/solo6x10/Kconfig | 2 ++
> drivers/usb/misc/sisusbvga/Kconfig | 1 +
> drivers/video/console/Kconfig | 12 ++++++++++--
> drivers/video/console/Makefile | 14 +++++---------
> 5 files changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 0cbe1ff..c1f29d5 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -220,7 +220,7 @@ if V4L_TEST_DRIVERS
> config VIDEO_VIVI
> tristate "Virtual Video Driver"
> depends on VIDEO_DEV && VIDEO_V4L2 && !SPARC32 && !SPARC64
> - depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE
> + select FONT_SUPPORT
> select FONT_8x16
> select VIDEOBUF2_VMALLOC
> default n
> diff --git a/drivers/staging/media/solo6x10/Kconfig b/drivers/staging/media/solo6x10/Kconfig
> index ec32776..b34bb6c 100644
> --- a/drivers/staging/media/solo6x10/Kconfig
> +++ b/drivers/staging/media/solo6x10/Kconfig
> @@ -1,6 +1,8 @@
> config SOLO6X10
> tristate "Softlogic 6x10 MPEG codec cards"
> depends on PCI && VIDEO_DEV && SND && I2C
> + select FONT_SUPPORT
> + select FONT_8x16
> select VIDEOBUF2_DMA_SG
> select VIDEOBUF2_DMA_CONTIG
> select SND_PCM
> diff --git a/drivers/usb/misc/sisusbvga/Kconfig b/drivers/usb/misc/sisusbvga/Kconfig
> index 0d03a52..36bc28c 100644
> --- a/drivers/usb/misc/sisusbvga/Kconfig
> +++ b/drivers/usb/misc/sisusbvga/Kconfig
> @@ -2,6 +2,7 @@
> config USB_SISUSBVGA
> tristate "USB 2.0 SVGA dongle support (Net2280/SiS315)"
> depends on (USB_MUSB_HDRC || USB_EHCI_HCD)
> + select FONT_SUPPORT if USB_SISUSBVGA_CON
> ---help---
> Say Y here if you intend to attach a USB2VGA dongle based on a
> Net2280 and a SiS315 chip.
> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
> index bc922c4..baf27dc 100644
> --- a/drivers/video/console/Kconfig
> +++ b/drivers/video/console/Kconfig
> @@ -62,6 +62,7 @@ config MDA_CONSOLE
> config SGI_NEWPORT_CONSOLE
> tristate "SGI Newport Console support"
> depends on SGI_IP22
> + select FONT_SUPPORT
> help
> Say Y here if you want the console on the Newport aka XL graphics
> card of your Indy. Most people say Y here.
> @@ -91,6 +92,7 @@ config FRAMEBUFFER_CONSOLE
> tristate "Framebuffer Console support"
> depends on FB
> select CRC32
> + select FONT_SUPPORT
> help
> Low-level framebuffer-based console driver.
>
> @@ -123,12 +125,18 @@ config FRAMEBUFFER_CONSOLE_ROTATION
> config STI_CONSOLE
> bool "STI text console"
> depends on PARISC
> + select FONT_SUPPORT
> default y
> help
> The STI console is the builtin display/keyboard on HP-PARISC
> machines. Say Y here to build support for it into your kernel.
> The alternative is to use your primary serial port as a console.
>
> +config FONT_SUPPORT
> + tristate
> +
> +if FONT_SUPPORT
> +
> config FONTS
> bool "Select compiled-in fonts"
> depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE
> @@ -158,7 +166,6 @@ config FONT_8x8
>
> config FONT_8x16
> bool "VGA 8x16 font" if FONTS
> - depends on FRAMEBUFFER_CONSOLE || SGI_NEWPORT_CONSOLE || STI_CONSOLE || USB_SISUSBVGA_CON
> default y if !SPARC && !FONTS
> help
> This is the "high resolution" font for the VGA frame buffer (the one
> @@ -226,7 +233,6 @@ config FONT_10x18
>
> config FONT_AUTOSELECT
> def_bool y
> - depends on FRAMEBUFFER_CONSOLE || SGI_NEWPORT_CONSOLE || STI_CONSOLE || USB_SISUSBVGA_CON
> depends on !FONT_8x8
> depends on !FONT_6x11
> depends on !FONT_7x14
> @@ -238,5 +244,7 @@ config FONT_AUTOSELECT
> depends on !FONT_10x18
> select FONT_8x16
>
> +endif # FONT_SUPPORT
> +
> endmenu
>
> diff --git a/drivers/video/console/Makefile b/drivers/video/console/Makefile
> index a862e91..3a11b63 100644
> --- a/drivers/video/console/Makefile
> +++ b/drivers/video/console/Makefile
> @@ -18,14 +18,14 @@ font-objs-$(CONFIG_FONT_MINI_4x6) += font_mini_4x6.o
>
> font-objs += $(font-objs-y)
>
> -# Each configuration option enables a list of files.
> +obj-$(CONFIG_FONT_SUPPORT) += font.o
>
> obj-$(CONFIG_DUMMY_CONSOLE) += dummycon.o
> -obj-$(CONFIG_SGI_NEWPORT_CONSOLE) += newport_con.o font.o
> -obj-$(CONFIG_STI_CONSOLE) += sticon.o sticore.o font.o
> +obj-$(CONFIG_SGI_NEWPORT_CONSOLE) += newport_con.o
> +obj-$(CONFIG_STI_CONSOLE) += sticon.o sticore.o
> obj-$(CONFIG_VGA_CONSOLE) += vgacon.o
> obj-$(CONFIG_MDA_CONSOLE) += mdacon.o
> -obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon.o bitblit.o font.o softcursor.o
> +obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon.o bitblit.o softcursor.o
> ifeq ($(CONFIG_FB_TILEBLITTING),y)
> obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += tileblit.o
> endif
> @@ -34,8 +34,4 @@ obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon_rotate.o fbcon_cw.o fbcon_ud.o \
> fbcon_ccw.o
> endif
>
> -obj-$(CONFIG_FB_STI) += sticore.o font.o
> -
> -ifeq ($(CONFIG_USB_SISUSBVGA_CON),y)
> -obj-$(CONFIG_USB_SISUSBVGA) += font.o
> -endif
> +obj-$(CONFIG_FB_STI) += sticore.o
>
^ permalink raw reply
* Re: Introduce a new helper framework for buffer synchronization
From: Rob Clark @ 2013-05-15 14:06 UTC (permalink / raw)
To: Inki Dae
Cc: linux-fbdev, DRI mailing list, Kyungmin Park, myungjoo.ham,
YoungJun Cho, linux-arm-kernel, linux-media
In-Reply-To: <00cf01ce512b$bacc5540$3064ffc0$%dae@samsung.com>
On Wed, May 15, 2013 at 1:19 AM, Inki Dae <inki.dae@samsung.com> wrote:
>
>
>> -----Original Message-----
>> From: Rob Clark [mailto:robdclark@gmail.com]
>> Sent: Tuesday, May 14, 2013 10:39 PM
>> To: Inki Dae
>> Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun
>> Cho; linux-arm-kernel@lists.infradead.org; linux-media@vger.kernel.org
>> Subject: Re: Introduce a new helper framework for buffer synchronization
>>
>> On Mon, May 13, 2013 at 10:52 PM, Inki Dae <inki.dae@samsung.com> wrote:
>> >> well, for cache management, I think it is a better idea.. I didn't
>> >> really catch that this was the motivation from the initial patch, but
>> >> maybe I read it too quickly. But cache can be decoupled from
>> >> synchronization, because CPU access is not asynchronous. For
>> >> userspace/CPU access to buffer, you should:
>> >>
>> >> 1) wait for buffer
>> >> 2) prepare-access
>> >> 3) ... do whatever cpu access to buffer ...
>> >> 4) finish-access
>> >> 5) submit buffer for new dma-operation
>> >>
>> >
>> >
>> > For data flow from CPU to DMA device,
>> > 1) wait for buffer
>> > 2) prepare-access (dma_buf_begin_cpu_access)
>> > 3) cpu access to buffer
>> >
>> >
>> > For data flow from DMA device to CPU
>> > 1) wait for buffer
>>
>> Right, but CPU access isn't asynchronous (from the point of view of
>> the CPU), so there isn't really any wait step at this point. And if
>> you do want the CPU to be able to signal a fence from userspace for
>> some reason, you probably what something file/fd based so the
>> refcnting/cleanup when process dies doesn't leave some pending DMA
>> action wedged. But I don't really see the point of that complexity
>> when the CPU access isn't asynchronous in the first place.
>>
>
> There was my missing comments, please see the below sequence.
>
> For data flow from CPU to DMA device and then from DMA device to CPU,
> 1) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...)
> - including prepare-access (dma_buf_begin_cpu_access)
> 2) cpu access to buffer
> 3) wait for buffer <- at device driver
> - but CPU is already accessing the buffer so blocked.
> 4) signal <- at user side - ioctl(fd, DMA_BUF_PUT_FENCE, ...)
> 5) the thread, blocked at 3), is waked up by 4).
> - and then finish-access (dma_buf_end_cpu_access)
right, I understand you can have background threads, etc, in
userspace. But there are already plenty of synchronization primitives
that can be used for cpu->cpu synchronization, either within the same
process or between multiple processes. For cpu access, even if it is
handled by background threads/processes, I think it is better to use
the traditional pthreads or unix synchronization primitives. They
have existed forever, they are well tested, and they work.
So while it seems nice and orthogonal/clean to couple cache and
synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the
same generic way, but I think in practice we have to make things more
complex than they otherwise need to be to do this. Otherwise I think
we'll be having problems with badly behaved or crashing userspace.
BR,
-R
> 6) dma access to buffer
> 7) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...)
> - but DMA is already accessing the buffer so blocked.
> 8) signal <- at device driver
> 9) the thread, blocked at 7), is waked up by 8)
> - and then prepare-access (dma_buf_begin_cpu_access)
> 10 cpu access to buffer
>
> Basically, 'wait for buffer' includes buffer synchronization, committing
> processing, and cache operation. The buffer synchronization means that a
> current thread should wait for other threads accessing a shared buffer until
> the completion of their access. And the committing processing means that a
> current thread possesses the shared buffer so any trying to access the
> shared buffer by another thread makes the thread to be blocked. However, as
> I already mentioned before, it seems that these user interfaces are so ugly
> yet. So we need better way.
>
> Give me more comments if there is my missing point :)
>
> Thanks,
> Inki Dae
>
>> BR,
>> -R
>>
>>
>> > 2) finish-access (dma_buf_end _cpu_access)
>> > 3) dma access to buffer
>> >
>> > 1) and 2) are coupled with one function: we have implemented
>> > fence_helper_commit_reserve() for it.
>> >
>> > Cache control(cache clean or cache invalidate) is performed properly
>> > checking previous access type and current access type.
>> > And the below is actual codes for it,
>
^ permalink raw reply
* Re: [PATCH v3 6/9] radeon: Switch to arch_phys_wc_add and add a missing ..._del
From: Jerome Glisse @ 2013-05-15 14:49 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Alex Deucher, linux-kernel, dri-devel, linux-fbdev, Daniel Vetter,
Dave Airlie
In-Reply-To: <CALCETrVo-6cnKZsDJnBJcwGjpPbW9QAYriyjAZavaZ8O2OkjnQ@mail.gmail.com>
On Tue, May 14, 2013 at 5:35 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Tue, May 14, 2013 at 6:37 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
>> On Tue, May 14, 2013 at 8:58 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>> On Mon, May 13, 2013 at 7:58 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>>>
>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>>
>> I believe it will break something but we could deal with the fallout
>> once it happens.
>
> FWIW, I'm running with this code on my machine right now using the
> radeon driver. Everything seems fine. If I build without MTRRs and
> without PAT, though, graphics are slow (as expected). So I think
> everything's okay.
>
> --Andy
I am worried on p4 where i last see issue with that notably with agp.
Cheers,
Jerome
^ permalink raw reply
* Re: fb driver for logiCVC
From: Bruno Prémont @ 2013-05-15 16:41 UTC (permalink / raw)
To: Davor Joja; +Cc: linux-kernel, linux-fbdev
In-Reply-To: <9D79B9A9194389468A922F618415D0A401229E7E@abc.xylon.local>
Hello Davor,
On Tue, 14 May 2013 "Davor Joja" wrote:
> Can I get suggestion how to send driver to this list which consists of
> several files and folders, as one (big) patch or as described in
> "how-to" as link to some ftp or git?
> My previous mail has not been replied, because of link to driver or
> other issue (tested on kernel 3.8)?
You should also send it to linux-fbdev (CCed) so interested people have
a better chance of seeing it (and quoting previous mail below).
If you have a git tree with history it might be nice. Otherwise it's
easier to review if you can split the big-patch into multiple incremental
parts adding some functionality each (that incremental nature would also
be expected from a git tree).
Your tree at https://github.com/logicbricks/linux_kernel looks weird,
you seem to have imported just the subfolders of kernel tree you worked
on instead of cloning e.g. v3.8 release and applying your driver on top
of it. This way it's not possible to merge your tree and it's rather hard
to find out what belongs to your driver or not.
Bruno
On Wed, 08 May 2013 "Davor Joja" wrote:
> I am sending link to frame buffer driver for Xylon "logiCVC" FPGA IP
> core, so I would kindly ask for driver review.
> logiCVC is Configurable Video Controller developed for Xilinx FPGA
> devices.
> logiCVC device together with xylonfb driver is widely used in Xilinx
> Targeted Referent Designs on Zynq SoC platforms (ZC702, ZC706, ZED, TED,
> Xilinx customers and Xilinx university program) and on custom projects
> from Xylon and Xylon customers.
>
> Driver implements platform and open firmware registration types.
> It has built in interface with V4L2 ADV7511 HDMI transmitter driver for
> handling EDID and miscellaneous clock generator SI570 driver.
> I would seek an advice for above mentioned and other issues which will
> get to surface in review.
>
> For now fb driver runs on 3.8 kernel (ARM architecture), and it was
> tested in all its configurations with:
> - Xylon test application
> - fbdev - Frame buffer device test application
> - DirectFB,
> - QT
> - Ubuntu 10.04 (16bpp and 32bpp color depth) Driver build was tested by
> Open Source Technology Center.
>
> Latest driver is available at
> https://github.com/logicbricks/linux_kernel.git under
> "drivers/video/xylon" and "include/linux" "Documentation (xylonfb
> devicetree parameters)"
> It is available on https://github.com/xilinx but not latest version.
>
> I have placed on ftp.logicbricks.com logiCVC datasheet, application
> note, current xylonfb driver user manual and test applications.
> Username: xylonfb
> Password: xylonfb
^ permalink raw reply
* Re: [PATCH v3 6/9] radeon: Switch to arch_phys_wc_add and add a missing ..._del
From: Andy Lutomirski @ 2013-05-15 18:22 UTC (permalink / raw)
To: Jerome Glisse
Cc: Alex Deucher, linux-kernel, dri-devel, linux-fbdev, Daniel Vetter,
Dave Airlie
In-Reply-To: <CAH3drwb743_q5ZrNDNsnOUUNVDMcefaq9NH3+t863OGc98-D-Q@mail.gmail.com>
On Wed, May 15, 2013 at 7:49 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
> On Tue, May 14, 2013 at 5:35 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Tue, May 14, 2013 at 6:37 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
>>> On Tue, May 14, 2013 at 8:58 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>> On Mon, May 13, 2013 at 7:58 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>>>>
>>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>>>
>>> I believe it will break something but we could deal with the fallout
>>> once it happens.
>>
>> FWIW, I'm running with this code on my machine right now using the
>> radeon driver. Everything seems fine. If I build without MTRRs and
>> without PAT, though, graphics are slow (as expected). So I think
>> everything's okay.
>>
>> --Andy
>
> I am worried on p4 where i last see issue with that notably with agp.
Do you remember any details? It looks like PAT is enabled on Pentium
4 (i.e. famliy 0xF).
--Andy
^ permalink raw reply
* [PATCH] video: Use less worrisome language in fbdev handoff
From: Adam Jackson @ 2013-05-15 21:04 UTC (permalink / raw)
To: linux-fbdev
For some reason people see "conflicting" and think it's a problem, even
though it's totally normal. Just call it a handoff.
Signed-off-by: Adam Jackson <ajax@redhat.com>
---
drivers/video/fbmem.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 098bfc6..2ec56a2 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1576,10 +1576,9 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
if (fb_do_apertures_overlap(gen_aper, a) ||
(primary && gen_aper && gen_aper->count &&
gen_aper->ranges[0].base = VGA_FB_PHYS)) {
-
- printk(KERN_INFO "fb: conflicting fb hw usage "
- "%s vs %s - removing generic driver\n",
- name, registered_fb[i]->fix.id);
+ printk(KERN_INFO "fb: Handoff from generic %s "
+ "driver to %s\n", registered_fb[i]->fix.id,
+ name);
do_unregister_framebuffer(registered_fb[i]);
}
}
--
1.8.2.1
^ permalink raw reply related
* Re: [PATCH 1/2] video: exynos_dp: Add parsing of gpios pins to exynos-dp driver
From: 한진구 @ 2013-05-16 2:04 UTC (permalink / raw)
To: Tomasz Figa, Vikas Sajjan
Cc: 한진구, linux-samsung-soc@vger.kernel.org,
김국진, devicetree-discuss@lists.ozlabs.org,
patches@linaro.org, linaro-kernel@lists.linaro.org,
rpurdie@rpsys.net, FlorianSchandinat@gmx.de,
linux-fbdev@vger.kernel.org
In-Reply-To: <1528008.HgBKZQmFTy@amdc1227>
VHVlc2RheSwgTWF5IDE0LCAyMDEzIDExOjE3IFBNLCBWaWthcyBTYWpqYW4gd3JvdGU6DQo+IA0K
PiBIaSBWaWthcywNCj4gDQo+IE9uIFR1ZXNkYXkgMTQgb2YgTWF5IDIwMTMgMTg6MjU6NTEgVmlr
YXMgU2FqamFuIHdyb3RlOg0KPiA+ICBBZGRzIEdQSU8gcGFyc2luZyBmdW5jdGlvbmFsaXR5IGZv
ciAiTENEIGJhY2tsaWdodCIgYW5kICJMQ0QgZW5hYmxlIg0KPiA+ICBHUElPIHBpbnMgb2YgZXh5
bm9zIGRwIGNvbnRyb2xsZXIuDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBWaWthcyBTYWpqYW4g
PHZpa2FzLnNhamphbkBsaW5hcm8ub3JnPg0KPiA+IC0tLQ0KPiA+ICBkcml2ZXJzL3ZpZGVvL2V4
eW5vcy9leHlub3NfZHBfY29yZS5jIHwgICA0NQ0KPiA+ICsrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKyAxIGZpbGUgY2hhbmdlZCwgNDUgaW5zZXJ0aW9ucygrKQ0KPiA+DQo+IA0KPiBJ
IGRvbid0IHRoaW5rIHRoYXQgRXh5bm9zIERQIGRyaXZlciBpcyByaWdodCBwbGFjZSBmb3Igc3Vj
aCBjb2RlLiBCYWNrbGlnaHQNCj4gYW5kIExDRCBkcml2ZXJzIGFyZSByZXNwb25zaWJsZSBmb3Ig
YmFja2xpZ2h0IGFuZCBMQ0QgcG93ZXIgY29udHJvbCB1c2luZw0KPiBiYWNrbGlnaHQgYW5kIExD
RCBzdWJzeXN0ZW1zLg0KPiANCj4gSU1ITyB0aGUgY29ycmVjdCBzb2x1dGlvbiB3b3VsZCBiZSB0
byBlaXRoZXIgZXh0ZW5kIGV4aXN0aW5nIGJhY2tsaWdodC9sY2QNCj4gZHJpdmVycyBmb3VuZCBp
biBkcml2ZXJzL3ZpZGVvL2JhY2tsaWdodCB0byBzdXBwb3J0IGRpcmVjdCBHUElPIGNvbnRyb2wg
YW5kDQo+IHBhcnNlIEdQSU8gcGlucyBmcm9tIGRldmljZSB0cmVlIG9yIGNyZWF0ZSBuZXcgZ3Bp
b19ibCBhbmQgZ3Bpb19sY2QgZHJpdmVycy4NCg0KSGkgVmlrYXMgU2FqaWFuLA0KDQpJIGFncmVl
IHdpdGggVG9tYXN6IEZpZ2EncyBvcGluaW9uLg0KQmFja2xpZ2h0L0xDRCBmcmFtZXdvcmsgc2hv
dWxkIGJlIHVzZWQuDQplRFAgcGFuZWwgYmFja2xpZ2h0IG9uIFNNREs1MjEwIGJvYXJkIGNhbiBi
ZSBjb250cm9sbGVkIGJ5IFBXTTsNCnRodXMsIHB3bS1iYWNrbGlnaHQgZHJpdmVyIHNob3VsZCBi
ZSB1c2VkLg0KQWxzbywgZURQIHBhbmVsIHJlc2V0IHBpbiBzaG91bGQgYmUgY29udHJvbGxlZCBi
eSB1c2luZw0KcGxhdGZvcm0tbGNkIGRyaXZlci4NCg0KPiANCj4gQ0NpbmcgUmljaGFyZCwgRmxv
cmlhbiBhbmQgbGludXgtZmJkZXYuDQoNCkFsc28sIEkgaGF2ZSBiZWVuIGRvaW5nIGJhY2tsaWdo
dCByZXZpZXdzIGluc3RlYWQgb2YgUmljaGFyZCwNCnBsZWFzZSBkbyBDQydpbmcgbWUuDQoNCkJl
c3QgcmVnYXJkcywNCkppbmdvbyBIYW4NCg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBUb21hc3oN
Cg=
^ permalink raw reply
* [PATCH 0/2] video: da8xx-fb trival cleanup
From: Lad Prabhakar @ 2013-05-16 7:22 UTC (permalink / raw)
To: DLOS, LFBDEV, Florian Tobias Schandinat; +Cc: LKML, Lad, Prabhakar
From: Lad, Prabhakar <prabhakar.csengg@gmail.com>
This patch series cleans the header inclusion and uses devm_* api
in the driver.
This patch series applies on 3.10-rc1 and is only boot
tested enabling FB driver.
Lad, Prabhakar (2):
video: da8xx-fb: remove unwanted header inclusion and sort the
alphabetically
video:da8xx-fb: Convert to devm_* api
drivers/video/da8xx-fb.c | 62 ++++++++++++---------------------------------
1 files changed, 17 insertions(+), 45 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH 1/2] video: da8xx-fb: remove unwanted header inclusion and sort the alphabetically
From: Lad Prabhakar @ 2013-05-16 7:22 UTC (permalink / raw)
To: DLOS, LFBDEV, Florian Tobias Schandinat; +Cc: LKML, Lad, Prabhakar
In-Reply-To: <1368688257-18705-1-git-send-email-prabhakar.csengg@gmail.com>
From: Lad, Prabhakar <prabhakar.csengg@gmail.com>
This patch removes unwanted header inclusion and sorts them alphabetically
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
drivers/video/da8xx-fb.c | 23 ++++++++++-------------
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 0810939..aafe8b9 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -19,25 +19,22 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/fb.h>
+
+#include <linux/clk.h>
+#include <linux/console.h>
+#include <linux/cpufreq.h>
#include <linux/dma-mapping.h>
-#include <linux/device.h>
+#include <linux/fb.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
#include <linux/platform_device.h>
-#include <linux/uaccess.h>
#include <linux/pm_runtime.h>
-#include <linux/interrupt.h>
-#include <linux/wait.h>
-#include <linux/clk.h>
-#include <linux/cpufreq.h>
-#include <linux/console.h>
-#include <linux/spinlock.h>
-#include <linux/slab.h>
+#include <linux/uaccess.h>
+
#include <linux/delay.h>
#include <linux/lcm.h>
+
#include <video/da8xx-fb.h>
-#include <asm/div64.h>
#define DRIVER_NAME "da8xx_lcdc"
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/2] video:da8xx-fb: Convert to devm_* api
From: Lad Prabhakar @ 2013-05-16 7:22 UTC (permalink / raw)
To: DLOS, LFBDEV, Florian Tobias Schandinat; +Cc: LKML, Lad, Prabhakar
In-Reply-To: <1368688257-18705-1-git-send-email-prabhakar.csengg@gmail.com>
From: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Use devm_ioremap_resource instead of reques_mem_region()/ioremap() and
devm_request_irq() instead of request_irq().
This ensures more consistent error values and simplifies error paths.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
drivers/video/da8xx-fb.c | 39 +++++++--------------------------------
1 files changed, 7 insertions(+), 32 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index aafe8b9..d35ea1d 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -134,7 +134,6 @@
#define LOWER_MARGIN 32
static void __iomem *da8xx_fb_reg_base;
-static struct resource *lcdc_regs;
static unsigned int lcd_revision;
static irq_handler_t lcdc_irq_handler;
static wait_queue_head_t frame_done_wq;
@@ -1015,12 +1014,9 @@ static int fb_remove(struct platform_device *dev)
par->p_palette_base);
dma_free_coherent(NULL, par->vram_size, par->vram_virt,
par->vram_phys);
- free_irq(par->irq, par);
pm_runtime_put_sync(&dev->dev);
pm_runtime_disable(&dev->dev);
framebuffer_release(info);
- iounmap(da8xx_fb_reg_base);
- release_mem_region(lcdc_regs->start, resource_size(lcdc_regs));
}
return 0;
@@ -1212,12 +1208,12 @@ static int fb_probe(struct platform_device *device)
{
struct da8xx_lcdc_platform_data *fb_pdata device->dev.platform_data;
+ static struct resource *lcdc_regs;
struct lcd_ctrl_config *lcd_cfg;
struct fb_videomode *lcdc_info;
struct fb_info *da8xx_fb_info;
struct clk *fb_clk = NULL;
struct da8xx_fb_par *par;
- resource_size_t len;
int ret, i;
unsigned long ulcm;
@@ -1227,29 +1223,14 @@ static int fb_probe(struct platform_device *device)
}
lcdc_regs = platform_get_resource(device, IORESOURCE_MEM, 0);
- if (!lcdc_regs) {
- dev_err(&device->dev,
- "Can not get memory resource for LCD controller\n");
- return -ENOENT;
- }
-
- len = resource_size(lcdc_regs);
-
- lcdc_regs = request_mem_region(lcdc_regs->start, len, lcdc_regs->name);
- if (!lcdc_regs)
- return -EBUSY;
-
- da8xx_fb_reg_base = ioremap(lcdc_regs->start, len);
- if (!da8xx_fb_reg_base) {
- ret = -EBUSY;
- goto err_request_mem;
- }
+ da8xx_fb_reg_base = devm_ioremap_resource(&device->dev, lcdc_regs);
+ if (IS_ERR(da8xx_fb_reg_base))
+ return PTR_ERR(da8xx_fb_reg_base);
fb_clk = clk_get(&device->dev, "fck");
if (IS_ERR(fb_clk)) {
dev_err(&device->dev, "Can not get device clock\n");
- ret = -ENODEV;
- goto err_ioremap;
+ return -ENODEV;
}
pm_runtime_enable(&device->dev);
@@ -1430,8 +1411,8 @@ static int fb_probe(struct platform_device *device)
lcdc_irq_handler = lcdc_irq_handler_rev02;
}
- ret = request_irq(par->irq, lcdc_irq_handler, 0,
- DRIVER_NAME, par);
+ ret = devm_request_irq(&device->dev, par->irq, lcdc_irq_handler, 0,
+ DRIVER_NAME, par);
if (ret)
goto irq_freq;
return 0;
@@ -1460,12 +1441,6 @@ err_pm_runtime_disable:
pm_runtime_put_sync(&device->dev);
pm_runtime_disable(&device->dev);
-err_ioremap:
- iounmap(da8xx_fb_reg_base);
-
-err_request_mem:
- release_mem_region(lcdc_regs->start, len);
-
return ret;
}
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] drivers: video: mxsfb: clean use of devm_ioremap_resource()
From: Jingoo Han @ 2013-05-16 8:41 UTC (permalink / raw)
To: Laurent Navet, FlorianSchandinat@gmx.de
Cc: linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Jingoo Han
In-Reply-To: <1368523508-30967-1-git-send-email-laurent.navet@gmail.com>
VHVlc2RheSwgTWF5IDE0LCAyMDEzIDY6MjUgUE0sIExhdXJlbnQgTmF2ZXQgd3JvdGU6DQo+IA0K
PiBDaGVjayBvZiAncmVzJyBhbmQgY2FsbHMgdG8gZGV2X2VyciBhcmUgYWxyZWFkeSBkb25lIGlu
IGRldm1faW9yZW1hcF9yZXNvdXJjZSwNCj4gc28gbm8gbmVlZCB0byBkbyB0aGVtIHR3aWNlLg0K
PiANCj4gU2lnbmVkLW9mZi1ieTogTGF1cmVudCBOYXZldCA8bGF1cmVudC5uYXZldEBnbWFpbC5j
b20+DQo+IC0tLQ0KPiAgZHJpdmVycy92aWRlby9teHNmYi5jIHwgICAxNCArKysrLS0tLS0tLS0t
LQ0KPiAgMSBmaWxlIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKSwgMTAgZGVsZXRpb25zKC0pDQo+
IA0KPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy92aWRlby9teHNmYi5jIGIvZHJpdmVycy92aWRlby9t
eHNmYi5jDQo+IGluZGV4IDIxMjIzZDQuLjBmM2QwZmMgMTAwNjQ0DQo+IC0tLSBhL2RyaXZlcnMv
dmlkZW8vbXhzZmIuYw0KPiArKysgYi9kcml2ZXJzL3ZpZGVvL214c2ZiLmMNCj4gQEAgLTg4NCw5
ICs4ODQsMTAgQEAgc3RhdGljIGludCBteHNmYl9wcm9iZShzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNl
ICpwZGV2KQ0KPiAgCQlwZGV2LT5pZF9lbnRyeSA9IG9mX2lkLT5kYXRhOw0KPiANCj4gIAlyZXMg
PSBwbGF0Zm9ybV9nZXRfcmVzb3VyY2UocGRldiwgSU9SRVNPVVJDRV9NRU0sIDApOw0KPiAtCWlm
ICghcmVzKSB7DQo+IC0JCWRldl9lcnIoJnBkZXYtPmRldiwgIkNhbm5vdCBnZXQgbWVtb3J5IElP
IHJlc291cmNlXG4iKTsNCj4gLQkJcmV0dXJuIC1FTk9ERVY7DQo+ICsJaG9zdC0+YmFzZSA9IGRl
dm1faW9yZW1hcF9yZXNvdXJjZSgmcGRldi0+ZGV2LCByZXMpOw0KPiArCWlmIChJU19FUlIoaG9z
dC0+YmFzZSkpIHsNCj4gKwkJcmV0ID0gUFRSX0VSUihob3N0LT5iYXNlKTsNCj4gKwkJZ290byBm
Yl9yZWxlYXNlOw0KDQpJdCBtYWtlcyBidWlsZCB3YXJuaW5nIGFzIGJlbG93Og0KDQpkcml2ZXJz
L3ZpZGVvL214c2ZiLmM6ODg3OjEzOiB3YXJuaW5nOiAnaG9zdCcgaXMgdXNlZCB1bmluaXRpYWxp
emVkIGluIHRoaXMgZnVuY3Rpb24gWy1XdW5pbml0aWFsaXplZF0NCmRyaXZlcnMvdmlkZW8vbXhz
ZmIuYzo5NjU6MjE6IHdhcm5pbmc6ICdmYl9pbmZvJyBtYXkgYmUgdXNlZCB1bmluaXRpYWxpemVk
IGluIHRoaXMgZnVuY3Rpb24gWy1XdW5pbml0aWFsaXplZF0NCg0KSXQgYnJlYWtzIHRoZSBhc3Np
Z25tZW50Lg0KCWhvc3QgPSB0b19pbXhmYl9ob3N0KGZiX2luZm8pOw0KDQpBbHNvLCAnZ290byBm
Yl9yZWxlYXNlOycgaXMgbm90IGdvb2QuDQpQbGVhc2UgdXNlICcgcmV0dXJuIFBUUl9FUlIoaG9z
dC0+YmFzZSk7JyBhcyBiZWxvdzoNCisgICAgICAgaG9zdC0+YmFzZSA9IGRldm1faW9yZW1hcF9y
ZXNvdXJjZSgmcGRldi0+ZGV2LCByZXMpOw0KKyAgICAgICBpZiAoSVNfRVJSKGhvc3QtPmJhc2Up
KQ0KKyAgICAgICAgICAgICAgIHJldHVybiBQVFJfRVJSKGhvc3QtPmJhc2UpOw0KDQoNCkJlc3Qg
cmVnYXJkcywNCkppbmdvbyBIYW4NCg0KPiAgCX0NCj4gDQo+ICAJZmJfaW5mbyA9IGZyYW1lYnVm
ZmVyX2FsbG9jKHNpemVvZihzdHJ1Y3QgbXhzZmJfaW5mbyksICZwZGV2LT5kZXYpOw0KPiBAQCAt
ODk3LDEzICs4OTgsNiBAQCBzdGF0aWMgaW50IG14c2ZiX3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9k
ZXZpY2UgKnBkZXYpDQo+IA0KPiAgCWhvc3QgPSB0b19pbXhmYl9ob3N0KGZiX2luZm8pOw0KPiAN
Cj4gLQlob3N0LT5iYXNlID0gZGV2bV9pb3JlbWFwX3Jlc291cmNlKCZwZGV2LT5kZXYsIHJlcyk7
DQo+IC0JaWYgKElTX0VSUihob3N0LT5iYXNlKSkgew0KPiAtCQlkZXZfZXJyKCZwZGV2LT5kZXYs
ICJpb3JlbWFwIGZhaWxlZFxuIik7DQo+IC0JCXJldCA9IFBUUl9FUlIoaG9zdC0+YmFzZSk7DQo+
IC0JCWdvdG8gZmJfcmVsZWFzZTsNCj4gLQl9DQo+IC0NCj4gIAlob3N0LT5wZGV2ID0gcGRldjsN
Cj4gIAlwbGF0Zm9ybV9zZXRfZHJ2ZGF0YShwZGV2LCBob3N0KTsNCj4gDQo+IC0tDQo+IDEuNy4x
MC40DQo
^ permalink raw reply
* Re: [PATCH] drivers: video: mxsfb: clean use of devm_ioremap_resource()
From: Laurent Navet @ 2013-05-16 9:46 UTC (permalink / raw)
To: jg1.han
Cc: FlorianSchandinat@gmx.de, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <19650694.136921368693687337.JavaMail.weblogic@epml12>
2013/5/16, Jingoo Han <jg1.han@samsung.com>:
> It makes build warning as below:
>
> drivers/video/mxsfb.c:887:13: warning: 'host' is used uninitialized in this
> function [-Wuninitialized]
> drivers/video/mxsfb.c:965:21: warning: 'fb_info' may be used uninitialized
> in this function [-Wuninitialized]
>
> It breaks the assignment.
> host = to_imxfb_host(fb_info);
>
> Also, 'goto fb_release;' is not good.
> Please use ' return PTR_ERR(host->base);' as below:
> + host->base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(host->base))
> + return PTR_ERR(host->base);
>
>
> Best regards,
> Jingoo Han
Thank's for reviewing, I'll look at and resend.
Laurent,
^ permalink raw reply
* RE: fb driver for logiCVC
From: Davor Joja @ 2013-05-16 10:35 UTC (permalink / raw)
To: Bruno Prémont; +Cc: linux-kernel, linux-fbdev
In-Reply-To: <20130515184112.251bb949@neptune.home>
SGVsbG8gQnJ1bm8sDQoNClRoYW5rIHlvdSBmb3IgdGhlIGFuc3dlciENCg0KSSBkaWQgbm90IHNl
bmQgaXQgYmVmb3JlIHRvIGxpbnV4LWZiZGV2IHNpbmNlIEkgdGhvdWdodCB0aGF0IGl0IGlzIG1v
cmUgbGlrZWx5IHRvIGdldCBhbnN3ZXIgYXQgbGludXgta2VybmVsIGxpc3QuDQpXaWxsIGRvIHRo
YXQgZnJvbSBub3cuDQoNClVuZm9ydHVuYXRlbHksIEkgaGF2ZSB0aGlzIGRyaXZlciBvbiBtZW50
aW9uZWQgZ2l0IG9ubHkgZm9yIGZldyB3ZWVrcywgc28gdGhlcmUgaXMgbm8gdXNhYmxlIGhpc3Rv
cnkuDQpTaW5jZSB0aGlzIGlzIG5ldyBkcml2ZXIsIHRlc3RlZCBhbmQgZnVuY3Rpb25hbCAob24g
a2VybmVsIDMuOCksIHdpdGhvdXQgZ2l0IGhpc3RvcnkgYXMgc3RhdGVkIGFib3ZlLCBkbyB5b3Ug
aGF2ZSBpZGVhIGhvdyB0byBicmVhayBpdCB0byBzbWFsbGVyIHBpZWNlcz8gSSBjYW4gb25seSB0
aGluayBvZmYgYXMgb25lIGJpZyBwYXRjaCBhZ2FpbnN0IDMuOC54IHZlcnNpb24uDQpUaGF0IGNv
dWxkIGJlIGFjY2VwdGVkIGZvciBuZXcgZHJpdmVyPw0KDQpZb3UgYXJlIHJpZ2h0IGFib3V0IGdp
dCwgaXQgaXMgbm90IG9yZ2FuaXplZCBpbiBzdGFuZGFyZCB3YXkuDQpJdCBpcyBjcmVhdGVkIGZv
ciBvdXIgY3VzdG9tZXJzIHRvIGVhc2lseSBnZXQgbGF0ZXN0IGRyaXZlcnMgZm9yIFh5bG9uIElQ
IGNvcmVzIGJlY2F1c2UgdGhleSBhbHJlYWR5IGtub3cgd2hhdCB0aGV5IG5lZWQgYW5kIGluIHdo
aWNoIGZvbGRlciB0byBzZWFyY2guIE1heWJlIHRoaXMgd2FzIG5vdCBnb29kIGlkZWEgdG8gc2Vu
ZCB0aGF0IGdpdCBsaW5rIGZvciByZXZpZXcuIFdpbGwgc3RpdGNoIHRvIHBhdGNoZXMgaW4gdGhl
IGZ1dHVyZSwgZXZlbiBmb3IgbmV3IGRyaXZlcnMuDQoNClJlZ2FyZHMsDQpEYXZvcg0KDQoNCi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcnVubyBQcsOpbW9udCBbbWFpbHRvOmJv
bmJvbnNAbGludXgtdnNlcnZlci5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBNYXkgMTUsIDIwMTMg
Njo0MSBQTQ0KVG86IERhdm9yIEpvamENCkNjOiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3Jn
OyBsaW51eC1mYmRldkB2Z2VyLmtlcm5lbC5vcmcNClN1YmplY3Q6IFJlOiBmYiBkcml2ZXIgZm9y
IGxvZ2lDVkMNCg0KSGVsbG8gRGF2b3IsDQoNCk9uIFR1ZSwgMTQgTWF5IDIwMTMgIkRhdm9yIEpv
amEiIHdyb3RlOg0KPiBDYW4gSSBnZXQgc3VnZ2VzdGlvbiBob3cgdG8gc2VuZCBkcml2ZXIgdG8g
dGhpcyBsaXN0IHdoaWNoIGNvbnNpc3RzIG9mIA0KPiBzZXZlcmFsIGZpbGVzIGFuZCBmb2xkZXJz
LCBhcyBvbmUgKGJpZykgcGF0Y2ggb3IgYXMgZGVzY3JpYmVkIGluIA0KPiAiaG93LXRvIiBhcyBs
aW5rIHRvIHNvbWUgZnRwIG9yIGdpdD8NCj4gTXkgcHJldmlvdXMgbWFpbCBoYXMgbm90IGJlZW4g
cmVwbGllZCwgYmVjYXVzZSBvZiBsaW5rIHRvIGRyaXZlciBvciANCj4gb3RoZXIgaXNzdWUgKHRl
c3RlZCBvbiBrZXJuZWwgMy44KT8NCg0KWW91IHNob3VsZCBhbHNvIHNlbmQgaXQgdG8gbGludXgt
ZmJkZXYgKENDZWQpIHNvIGludGVyZXN0ZWQgcGVvcGxlIGhhdmUgYSBiZXR0ZXIgY2hhbmNlIG9m
IHNlZWluZyBpdCAoYW5kIHF1b3RpbmcgcHJldmlvdXMgbWFpbCBiZWxvdykuDQoNCklmIHlvdSBo
YXZlIGEgZ2l0IHRyZWUgd2l0aCBoaXN0b3J5IGl0IG1pZ2h0IGJlIG5pY2UuIE90aGVyd2lzZSBp
dCdzIGVhc2llciB0byByZXZpZXcgaWYgeW91IGNhbiBzcGxpdCB0aGUgYmlnLXBhdGNoIGludG8g
bXVsdGlwbGUgaW5jcmVtZW50YWwgcGFydHMgYWRkaW5nIHNvbWUgZnVuY3Rpb25hbGl0eSBlYWNo
ICh0aGF0IGluY3JlbWVudGFsIG5hdHVyZSB3b3VsZCBhbHNvIGJlIGV4cGVjdGVkIGZyb20gYSBn
aXQgdHJlZSkuDQoNCllvdXIgdHJlZSBhdCBodHRwczovL2dpdGh1Yi5jb20vbG9naWNicmlja3Mv
bGludXhfa2VybmVsIGxvb2tzIHdlaXJkLCB5b3Ugc2VlbSB0byBoYXZlIGltcG9ydGVkIGp1c3Qg
dGhlIHN1YmZvbGRlcnMgb2Yga2VybmVsIHRyZWUgeW91IHdvcmtlZCBvbiBpbnN0ZWFkIG9mIGNs
b25pbmcgZS5nLiB2My44IHJlbGVhc2UgYW5kIGFwcGx5aW5nIHlvdXIgZHJpdmVyIG9uIHRvcCBv
ZiBpdC4gVGhpcyB3YXkgaXQncyBub3QgcG9zc2libGUgdG8gbWVyZ2UgeW91ciB0cmVlIGFuZCBp
dCdzIHJhdGhlciBoYXJkIHRvIGZpbmQgb3V0IHdoYXQgYmVsb25ncyB0byB5b3VyIGRyaXZlciBv
ciBub3QuDQoNCkJydW5vDQoNCk9uIFdlZCwgMDggTWF5IDIwMTMgIkRhdm9yIEpvamEiIHdyb3Rl
Og0KPiBJIGFtIHNlbmRpbmcgbGluayB0byBmcmFtZSBidWZmZXIgZHJpdmVyIGZvciBYeWxvbiAi
bG9naUNWQyIgRlBHQSBJUCANCj4gY29yZSwgc28gSSB3b3VsZCBraW5kbHkgYXNrIGZvciBkcml2
ZXIgcmV2aWV3Lg0KPiBsb2dpQ1ZDIGlzIENvbmZpZ3VyYWJsZSBWaWRlbyBDb250cm9sbGVyIGRl
dmVsb3BlZCBmb3IgWGlsaW54IEZQR0EgDQo+IGRldmljZXMuDQo+IGxvZ2lDVkMgZGV2aWNlIHRv
Z2V0aGVyIHdpdGggeHlsb25mYiBkcml2ZXIgaXMgd2lkZWx5IHVzZWQgaW4gWGlsaW54IA0KPiBU
YXJnZXRlZCBSZWZlcmVudCBEZXNpZ25zIG9uIFp5bnEgU29DIHBsYXRmb3JtcyAoWkM3MDIsIFpD
NzA2LCBaRUQsIA0KPiBURUQsIFhpbGlueCBjdXN0b21lcnMgYW5kIFhpbGlueCB1bml2ZXJzaXR5
IHByb2dyYW0pIGFuZCBvbiBjdXN0b20gDQo+IHByb2plY3RzIGZyb20gWHlsb24gYW5kIFh5bG9u
IGN1c3RvbWVycy4NCj4gDQo+IERyaXZlciBpbXBsZW1lbnRzIHBsYXRmb3JtIGFuZCBvcGVuIGZp
cm13YXJlIHJlZ2lzdHJhdGlvbiB0eXBlcy4NCj4gSXQgaGFzIGJ1aWx0IGluIGludGVyZmFjZSB3
aXRoIFY0TDIgQURWNzUxMSBIRE1JIHRyYW5zbWl0dGVyIGRyaXZlciANCj4gZm9yIGhhbmRsaW5n
IEVESUQgYW5kIG1pc2NlbGxhbmVvdXMgY2xvY2sgZ2VuZXJhdG9yIFNJNTcwIGRyaXZlci4NCj4g
SSB3b3VsZCBzZWVrIGFuIGFkdmljZSBmb3IgYWJvdmUgbWVudGlvbmVkIGFuZCBvdGhlciBpc3N1
ZXMgd2hpY2ggd2lsbCANCj4gZ2V0IHRvIHN1cmZhY2UgaW4gcmV2aWV3Lg0KPiANCj4gRm9yIG5v
dyBmYiBkcml2ZXIgcnVucyBvbiAzLjgga2VybmVsIChBUk0gYXJjaGl0ZWN0dXJlKSwgYW5kIGl0
IHdhcyANCj4gdGVzdGVkIGluIGFsbCBpdHMgY29uZmlndXJhdGlvbnMgd2l0aDoNCj4gLSBYeWxv
biB0ZXN0IGFwcGxpY2F0aW9uDQo+IC0gZmJkZXYgLSBGcmFtZSBidWZmZXIgZGV2aWNlIHRlc3Qg
YXBwbGljYXRpb24NCj4gLSBEaXJlY3RGQiwNCj4gLSBRVA0KPiAtIFVidW50dSAxMC4wNCAoMTZi
cHAgYW5kIDMyYnBwIGNvbG9yIGRlcHRoKSBEcml2ZXIgYnVpbGQgd2FzIHRlc3RlZCANCj4gYnkg
T3BlbiBTb3VyY2UgVGVjaG5vbG9neSBDZW50ZXIuDQo+IA0KPiBMYXRlc3QgZHJpdmVyIGlzIGF2
YWlsYWJsZSBhdA0KPiBodHRwczovL2dpdGh1Yi5jb20vbG9naWNicmlja3MvbGludXhfa2VybmVs
LmdpdCB1bmRlciANCj4gImRyaXZlcnMvdmlkZW8veHlsb24iIGFuZCAiaW5jbHVkZS9saW51eCIg
IkRvY3VtZW50YXRpb24gKHh5bG9uZmIgDQo+IGRldmljZXRyZWUgcGFyYW1ldGVycykiDQo+IEl0
IGlzIGF2YWlsYWJsZSBvbiBodHRwczovL2dpdGh1Yi5jb20veGlsaW54IGJ1dCBub3QgbGF0ZXN0
IHZlcnNpb24uDQo+IA0KPiBJIGhhdmUgcGxhY2VkIG9uIGZ0cC5sb2dpY2JyaWNrcy5jb20gbG9n
aUNWQyBkYXRhc2hlZXQsIGFwcGxpY2F0aW9uIA0KPiBub3RlLCBjdXJyZW50IHh5bG9uZmIgZHJp
dmVyIHVzZXIgbWFudWFsIGFuZCB0ZXN0IGFwcGxpY2F0aW9ucy4NCj4gVXNlcm5hbWU6IHh5bG9u
ZmINCj4gUGFzc3dvcmQ6IHh5bG9uZmINCg=
^ permalink raw reply
* [PATCH] acornfb: remove dead code
From: Paul Bolle @ 2013-05-16 10:51 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-fbdev, linux-kernel
acornfb checks for HAS_VIDC while support for that macro was removed in
v2.6.23 (when the arm26 port was removed). So we can remove a bit of
dead code.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
Untested (do not have the hardware, do not build with CONFIG_FB_ACORN
set myself, etc.).
drivers/video/acornfb.c | 266 +-----------------------------------------------
drivers/video/acornfb.h | 29 ------
2 files changed, 1 insertion(+), 294 deletions(-)
diff --git a/drivers/video/acornfb.c b/drivers/video/acornfb.c
index 6488a73..7e8346e 100644
--- a/drivers/video/acornfb.c
+++ b/drivers/video/acornfb.c
@@ -38,14 +38,6 @@
#include "acornfb.h"
/*
- * VIDC machines can't do 16 or 32BPP modes.
- */
-#ifdef HAS_VIDC
-#undef FBCON_HAS_CFB16
-#undef FBCON_HAS_CFB32
-#endif
-
-/*
* Default resolution.
* NOTE that it has to be supported in the table towards
* the end of this file.
@@ -106,238 +98,6 @@ static struct vidc_timing current_vidc;
extern unsigned int vram_size; /* set by setup.c */
-#ifdef HAS_VIDC
-
-#define MAX_SIZE 480*1024
-
-/* CTL VIDC Actual
- * 24.000 0 8.000
- * 25.175 0 8.392
- * 36.000 0 12.000
- * 24.000 1 12.000
- * 25.175 1 12.588
- * 24.000 2 16.000
- * 25.175 2 16.783
- * 36.000 1 18.000
- * 24.000 3 24.000
- * 36.000 2 24.000
- * 25.175 3 25.175
- * 36.000 3 36.000
- */
-struct pixclock {
- u_long min_clock;
- u_long max_clock;
- u_int vidc_ctl;
- u_int vid_ctl;
-};
-
-static struct pixclock arc_clocks[] = {
- /* we allow +/-1% on these */
- { 123750, 126250, VIDC_CTRL_DIV3, VID_CTL_24MHz }, /* 8.000MHz */
- { 82500, 84167, VIDC_CTRL_DIV2, VID_CTL_24MHz }, /* 12.000MHz */
- { 61875, 63125, VIDC_CTRL_DIV1_5, VID_CTL_24MHz }, /* 16.000MHz */
- { 41250, 42083, VIDC_CTRL_DIV1, VID_CTL_24MHz }, /* 24.000MHz */
-};
-
-static struct pixclock *
-acornfb_valid_pixrate(struct fb_var_screeninfo *var)
-{
- u_long pixclock = var->pixclock;
- u_int i;
-
- if (!var->pixclock)
- return NULL;
-
- for (i = 0; i < ARRAY_SIZE(arc_clocks); i++)
- if (pixclock > arc_clocks[i].min_clock &&
- pixclock < arc_clocks[i].max_clock)
- return arc_clocks + i;
-
- return NULL;
-}
-
-/* VIDC Rules:
- * hcr : must be even (interlace, hcr/2 must be even)
- * hswr : must be even
- * hdsr : must be odd
- * hder : must be odd
- *
- * vcr : must be odd
- * vswr : >= 1
- * vdsr : >= 1
- * vder : >= vdsr
- * if interlaced, then hcr/2 must be even
- */
-static void
-acornfb_set_timing(struct fb_var_screeninfo *var)
-{
- struct pixclock *pclk;
- struct vidc_timing vidc;
- u_int horiz_correction;
- u_int sync_len, display_start, display_end, cycle;
- u_int is_interlaced;
- u_int vid_ctl, vidc_ctl;
- u_int bandwidth;
-
- memset(&vidc, 0, sizeof(vidc));
-
- pclk = acornfb_valid_pixrate(var);
- vidc_ctl = pclk->vidc_ctl;
- vid_ctl = pclk->vid_ctl;
-
- bandwidth = var->pixclock * 8 / var->bits_per_pixel;
- /* 25.175, 4bpp = 79.444ns per byte, 317.776ns per word: fifo = 2,6 */
- if (bandwidth > 143500)
- vidc_ctl |= VIDC_CTRL_FIFO_3_7;
- else if (bandwidth > 71750)
- vidc_ctl |= VIDC_CTRL_FIFO_2_6;
- else if (bandwidth > 35875)
- vidc_ctl |= VIDC_CTRL_FIFO_1_5;
- else
- vidc_ctl |= VIDC_CTRL_FIFO_0_4;
-
- switch (var->bits_per_pixel) {
- case 1:
- horiz_correction = 19;
- vidc_ctl |= VIDC_CTRL_1BPP;
- break;
-
- case 2:
- horiz_correction = 11;
- vidc_ctl |= VIDC_CTRL_2BPP;
- break;
-
- case 4:
- horiz_correction = 7;
- vidc_ctl |= VIDC_CTRL_4BPP;
- break;
-
- default:
- case 8:
- horiz_correction = 5;
- vidc_ctl |= VIDC_CTRL_8BPP;
- break;
- }
-
- if (var->sync & FB_SYNC_COMP_HIGH_ACT) /* should be FB_SYNC_COMP */
- vidc_ctl |= VIDC_CTRL_CSYNC;
- else {
- if (!(var->sync & FB_SYNC_HOR_HIGH_ACT))
- vid_ctl |= VID_CTL_HS_NHSYNC;
-
- if (!(var->sync & FB_SYNC_VERT_HIGH_ACT))
- vid_ctl |= VID_CTL_VS_NVSYNC;
- }
-
- sync_len = var->hsync_len;
- display_start = sync_len + var->left_margin;
- display_end = display_start + var->xres;
- cycle = display_end + var->right_margin;
-
- /* if interlaced, then hcr/2 must be even */
- is_interlaced = (var->vmode & FB_VMODE_MASK) = FB_VMODE_INTERLACED;
-
- if (is_interlaced) {
- vidc_ctl |= VIDC_CTRL_INTERLACE;
- if (cycle & 2) {
- cycle += 2;
- var->right_margin += 2;
- }
- }
-
- vidc.h_cycle = (cycle - 2) / 2;
- vidc.h_sync_width = (sync_len - 2) / 2;
- vidc.h_border_start = (display_start - 1) / 2;
- vidc.h_display_start = (display_start - horiz_correction) / 2;
- vidc.h_display_end = (display_end - horiz_correction) / 2;
- vidc.h_border_end = (display_end - 1) / 2;
- vidc.h_interlace = (vidc.h_cycle + 1) / 2;
-
- sync_len = var->vsync_len;
- display_start = sync_len + var->upper_margin;
- display_end = display_start + var->yres;
- cycle = display_end + var->lower_margin;
-
- if (is_interlaced)
- cycle = (cycle - 3) / 2;
- else
- cycle = cycle - 1;
-
- vidc.v_cycle = cycle;
- vidc.v_sync_width = sync_len - 1;
- vidc.v_border_start = display_start - 1;
- vidc.v_display_start = vidc.v_border_start;
- vidc.v_display_end = display_end - 1;
- vidc.v_border_end = vidc.v_display_end;
-
- if (machine_is_a5k())
- __raw_writeb(vid_ctl, IOEB_VID_CTL);
-
- if (memcmp(¤t_vidc, &vidc, sizeof(vidc))) {
- current_vidc = vidc;
-
- vidc_writel(0xe0000000 | vidc_ctl);
- vidc_writel(0x80000000 | (vidc.h_cycle << 14));
- vidc_writel(0x84000000 | (vidc.h_sync_width << 14));
- vidc_writel(0x88000000 | (vidc.h_border_start << 14));
- vidc_writel(0x8c000000 | (vidc.h_display_start << 14));
- vidc_writel(0x90000000 | (vidc.h_display_end << 14));
- vidc_writel(0x94000000 | (vidc.h_border_end << 14));
- vidc_writel(0x98000000);
- vidc_writel(0x9c000000 | (vidc.h_interlace << 14));
- vidc_writel(0xa0000000 | (vidc.v_cycle << 14));
- vidc_writel(0xa4000000 | (vidc.v_sync_width << 14));
- vidc_writel(0xa8000000 | (vidc.v_border_start << 14));
- vidc_writel(0xac000000 | (vidc.v_display_start << 14));
- vidc_writel(0xb0000000 | (vidc.v_display_end << 14));
- vidc_writel(0xb4000000 | (vidc.v_border_end << 14));
- vidc_writel(0xb8000000);
- vidc_writel(0xbc000000);
- }
-#ifdef DEBUG_MODE_SELECTION
- printk(KERN_DEBUG "VIDC registers for %dx%dx%d:\n", var->xres,
- var->yres, var->bits_per_pixel);
- printk(KERN_DEBUG " H-cycle : %d\n", vidc.h_cycle);
- printk(KERN_DEBUG " H-sync-width : %d\n", vidc.h_sync_width);
- printk(KERN_DEBUG " H-border-start : %d\n", vidc.h_border_start);
- printk(KERN_DEBUG " H-display-start : %d\n", vidc.h_display_start);
- printk(KERN_DEBUG " H-display-end : %d\n", vidc.h_display_end);
- printk(KERN_DEBUG " H-border-end : %d\n", vidc.h_border_end);
- printk(KERN_DEBUG " H-interlace : %d\n", vidc.h_interlace);
- printk(KERN_DEBUG " V-cycle : %d\n", vidc.v_cycle);
- printk(KERN_DEBUG " V-sync-width : %d\n", vidc.v_sync_width);
- printk(KERN_DEBUG " V-border-start : %d\n", vidc.v_border_start);
- printk(KERN_DEBUG " V-display-start : %d\n", vidc.v_display_start);
- printk(KERN_DEBUG " V-display-end : %d\n", vidc.v_display_end);
- printk(KERN_DEBUG " V-border-end : %d\n", vidc.v_border_end);
- printk(KERN_DEBUG " VIDC Ctrl (E) : 0x%08X\n", vidc_ctl);
- printk(KERN_DEBUG " IOEB Ctrl : 0x%08X\n", vid_ctl);
-#endif
-}
-
-static int
-acornfb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
- u_int trans, struct fb_info *info)
-{
- union palette pal;
-
- if (regno >= current_par.palette_size)
- return 1;
-
- pal.p = 0;
- pal.vidc.reg = regno;
- pal.vidc.red = red >> 12;
- pal.vidc.green = green >> 12;
- pal.vidc.blue = blue >> 12;
-
- current_par.palette[regno] = pal;
-
- vidc_writel(pal.p);
-
- return 0;
-}
-#endif
-
#ifdef HAS_VIDC20
#include <mach/acornfb.h>
@@ -634,16 +394,7 @@ acornfb_adjust_timing(struct fb_info *info, struct fb_var_screeninfo *var, u_int
/* hsync_len must be even */
var->hsync_len = (var->hsync_len + 1) & ~1;
-#ifdef HAS_VIDC
- /* left_margin must be odd */
- if ((var->left_margin & 1) = 0) {
- var->left_margin -= 1;
- var->right_margin += 1;
- }
-
- /* right_margin must be odd */
- var->right_margin |= 1;
-#elif defined(HAS_VIDC20)
+#if defined(HAS_VIDC20)
/* left_margin must be even */
if (var->left_margin & 1) {
var->left_margin += 1;
@@ -787,11 +538,7 @@ static int acornfb_set_par(struct fb_info *info)
break;
case 8:
current_par.palette_size = VIDC_PALETTE_SIZE;
-#ifdef HAS_VIDC
- info->fix.visual = FB_VISUAL_STATIC_PSEUDOCOLOR;
-#else
info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
-#endif
break;
#ifdef HAS_VIDC20
case 16:
@@ -971,9 +718,6 @@ static void acornfb_init_fbinfo(void)
#if defined(HAS_VIDC20)
fb_info.var.red.length = 8;
fb_info.var.transp.length = 4;
-#elif defined(HAS_VIDC)
- fb_info.var.red.length = 4;
- fb_info.var.transp.length = 1;
#endif
fb_info.var.green = fb_info.var.red;
fb_info.var.blue = fb_info.var.red;
@@ -1310,14 +1054,6 @@ static int acornfb_probe(struct platform_device *dev)
fb_info.fix.smem_start = handle;
}
#endif
-#if defined(HAS_VIDC)
- /*
- * Archimedes/A5000 machines use a fixed address for their
- * framebuffers. Free unused pages
- */
- free_unused_pages(PAGE_OFFSET + size, PAGE_OFFSET + MAX_SIZE);
-#endif
-
fb_info.fix.smem_len = size;
current_par.palette_size = VIDC_PALETTE_SIZE;
diff --git a/drivers/video/acornfb.h b/drivers/video/acornfb.h
index fb2a7ff..175c8ff 100644
--- a/drivers/video/acornfb.h
+++ b/drivers/video/acornfb.h
@@ -13,10 +13,6 @@
#include <asm/hardware/iomd.h>
#define VIDC_PALETTE_SIZE 256
#define VIDC_NAME "VIDC20"
-#elif defined(HAS_VIDC)
-#include <asm/hardware/memc.h>
-#define VIDC_PALETTE_SIZE 16
-#define VIDC_NAME "VIDC"
#endif
#define EXTEND8(x) ((x)|(x)<<8)
@@ -101,31 +97,6 @@ struct modex_params {
const struct modey_params *modey;
};
-#ifdef HAS_VIDC
-
-#define VID_CTL_VS_NVSYNC (1 << 3)
-#define VID_CTL_HS_NHSYNC (1 << 2)
-#define VID_CTL_24MHz (0)
-#define VID_CTL_25MHz (1)
-#define VID_CTL_36MHz (2)
-
-#define VIDC_CTRL_CSYNC (1 << 7)
-#define VIDC_CTRL_INTERLACE (1 << 6)
-#define VIDC_CTRL_FIFO_0_4 (0 << 4)
-#define VIDC_CTRL_FIFO_1_5 (1 << 4)
-#define VIDC_CTRL_FIFO_2_6 (2 << 4)
-#define VIDC_CTRL_FIFO_3_7 (3 << 4)
-#define VIDC_CTRL_1BPP (0 << 2)
-#define VIDC_CTRL_2BPP (1 << 2)
-#define VIDC_CTRL_4BPP (2 << 2)
-#define VIDC_CTRL_8BPP (3 << 2)
-#define VIDC_CTRL_DIV3 (0 << 0)
-#define VIDC_CTRL_DIV2 (1 << 0)
-#define VIDC_CTRL_DIV1_5 (2 << 0)
-#define VIDC_CTRL_DIV1 (3 << 0)
-
-#endif
-
#ifdef HAS_VIDC20
/*
* VIDC20 registers
--
1.7.11.7
^ permalink raw reply related
* [PATCH 25/33] drivers/video/omap2: don't check resource with devm_ioremap_resource
From: Wolfram Sang @ 2013-05-16 11:15 UTC (permalink / raw)
To: linux-kernel
Cc: Wolfram Sang, Tomi Valkeinen, Florian Tobias Schandinat,
linux-omap, linux-fbdev
In-Reply-To: <1368702961-4325-1-git-send-email-wsa@the-dreams.de>
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---
drivers/video/omap2/vrfb.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index 5261229..f346b02 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -353,11 +353,6 @@ static int __init vrfb_probe(struct platform_device *pdev)
/* first resource is the register res, the rest are vrfb contexts */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!mem) {
- dev_err(&pdev->dev, "can't get vrfb base address\n");
- return -EINVAL;
- }
-
vrfb_base = devm_ioremap_resource(&pdev->dev, mem);
if (IS_ERR(vrfb_base))
return PTR_ERR(vrfb_base);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 26/33] drivers/video/omap2/dss: don't check resource with devm_ioremap_resource
From: Wolfram Sang @ 2013-05-16 11:15 UTC (permalink / raw)
To: linux-kernel
Cc: Wolfram Sang, Tomi Valkeinen, Florian Tobias Schandinat,
linux-omap, linux-fbdev
In-Reply-To: <1368702961-4325-1-git-send-email-wsa@the-dreams.de>
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---
drivers/video/omap2/dss/hdmi.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 17f4d55..a109934 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -1065,10 +1065,6 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev)
mutex_init(&hdmi.ip_data.lock);
res = platform_get_resource(hdmi.pdev, IORESOURCE_MEM, 0);
- if (!res) {
- DSSERR("can't get IORESOURCE_MEM HDMI\n");
- return -EINVAL;
- }
/* Base address taken from platform */
hdmi.ip_data.base_wp = devm_ioremap_resource(&pdev->dev, res);
--
1.7.10.4
^ permalink raw reply related
* Re: fb driver for logiCVC
From: Geert Uytterhoeven @ 2013-05-16 11:23 UTC (permalink / raw)
To: Davor Joja
Cc: Bruno Prémont, linux-kernel@vger.kernel.org,
Linux Fbdev development list
In-Reply-To: <ABCSCiTtUDvkm6WeI5J00000073@abc.logicbricks.com>
On Thu, May 16, 2013 at 12:35 PM, Davor Joja <Davor.Joja@logicbricks.com> wrote:
> Unfortunately, I have this driver on mentioned git only for few weeks, so there is no usable history.
> Since this is new driver, tested and functional (on kernel 3.8), without git history as stated above, do you have idea how to break it to smaller pieces? I can only think off as one big patch against 3.8.x version.
> That could be accepted for new driver?
A single patch is OK for a new driver.
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
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