* Re: [PATCH 00/13] sa1100fb cleanups
From: Florian Tobias Schandinat @ 2012-02-19 22:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120204093744.GQ889@n2100.arm.linux.org.uk>
Hi Russell,
On 02/04/2012 09:37 AM, Russell King - ARM Linux wrote:
> Here's another bunch of SA11x0 stuff - its framebuffer driver. This
> set of patches fixes some section mismatch warnings, moves the board
> configuration out to the board files, converts the Shannon stuff to
> use gpiolib rather than poking at GPDR/GPSR/GPCR directly.
>
> The function hooks for LCD and backlight power control are moved into
> the platform data passed from the board, eliminating the global function
> pointers.
This series looks good to me.
Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> This series will conflict with the previous series (in the case of
> Assabet, the conflict is quite large) so I'd prefer to keep this in my
> tree for the next merge window.
Sure, feel free to proceed with this series as you like.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH 5/5] fbdev: s/#if CONFIG/#ifdef CONFIG/
From: Florian Tobias Schandinat @ 2012-02-19 22:44 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Jiri Kosina, linux-kernel, linux-fbdev
In-Reply-To: <1329664319-3128-5-git-send-email-geert@linux-m68k.org>
On 02/19/2012 03:11 PM, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
(I assume you want that to go mainline via Jiri's tree)
Best regards,
Florian Tobias Schandinat
> Cc: linux-fbdev@vger.kernel.org
> ---
> drivers/video/au1100fb.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/au1100fb.c b/drivers/video/au1100fb.c
> index de9da67..4da1895 100644
> --- a/drivers/video/au1100fb.c
> +++ b/drivers/video/au1100fb.c
> @@ -532,7 +532,7 @@ static int __devinit au1100fb_drv_probe(struct platform_device *dev)
> for (page = (unsigned long)fbdev->fb_mem;
> page < PAGE_ALIGN((unsigned long)fbdev->fb_mem + fbdev->fb_len);
> page += PAGE_SIZE) {
> -#if CONFIG_DMA_NONCOHERENT
> +#ifdef CONFIG_DMA_NONCOHERENT
> SetPageReserved(virt_to_page(CAC_ADDR((void *)page)));
> #else
> SetPageReserved(virt_to_page(page));
^ permalink raw reply
* [PATCH] video: s3c-fb: use devm_request_irq()
From: Jingoo Han @ 2012-02-20 10:40 UTC (permalink / raw)
To: linux-fbdev
The devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_request_irq of these functions.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index e22bf9d..1fb7ddf 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1433,7 +1433,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
goto err_lcd_clk;
}
sfb->irq_no = res->start;
- ret = request_irq(sfb->irq_no, s3c_fb_irq,
+ ret = devm_request_irq(dev, sfb->irq_no, s3c_fb_irq,
0, "s3c_fb", sfb);
if (ret) {
dev_err(dev, "irq request failed\n");
@@ -1499,7 +1499,6 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
err_pm_runtime:
pm_runtime_put_sync(sfb->dev);
- free_irq(sfb->irq_no, sfb);
err_lcd_clk:
pm_runtime_disable(sfb->dev);
@@ -1535,8 +1534,6 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
if (sfb->windows[win])
s3c_fb_release_win(sfb, sfb->windows[win]);
- free_irq(sfb->irq_no, sfb);
-
if (!sfb->variant.has_clksel) {
clk_disable(sfb->lcd_clk);
clk_put(sfb->lcd_clk);
--
1.7.1
^ permalink raw reply related
* Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
From: Guennadi Liakhovetski @ 2012-02-20 16:09 UTC (permalink / raw)
To: Daniel Vetter
Cc: Laurent Pinchart, Tomasz Stanislawski, linux-fbdev, Sakari Ailus,
Pawel Osciak, Magnus Damm, Marcus Lorentzon, dri-devel,
Alexander Deucher, Rob Clark, linux-media, Marek Szyprowski
In-Reply-To: <20120217095554.GA5511@phenom.ffwll.local>
On Fri, 17 Feb 2012, Daniel Vetter wrote:
> On Fri, Feb 17, 2012 at 12:25:51AM +0100, Laurent Pinchart wrote:
> > Hello everybody,
> >
> > First of all, I would like to thank all the attendees for their participation
> > in the mini-summit that helped make the meeting a success.
> >
> > Here are my consolidated notes that cover both the Linaro Connect meeting and
> > the ELC meeting. They're also available at
> > http://www.ideasonboard.org/media/meetings/.
>
> Looks like you've been all really busy ;-) A few quick comments below.
>
> > Kernel Display and Video API Consolidation mini-summit at ELC 2012
> > ------------------------------------------------------------------
>
> [snip]
>
> > *** Common video mode data structure and EDID parser ***
> >
> > Goal: Sharing an EDID parser between DRM/KMS, FBDEV and V4L2.
> >
> > The DRM EDID parser is currently the most advanced implementation and will
> > be taken as a starting point.
I'm certainly absolutely in favour of creating a common EDID parser, and
the DRM/KMS implementation might indeed be the most complete / advanced
one, but at least back in 2010 as I was working on the sh-mobile HDMI
driver, some functinality was still missing there, which I had to add to
fbdev independently. Unless those features have been added to DRM / KMS
since then you might want to use the fbdev version. See
http://thread.gmane.org/gmane.linux.ports.arm.omap/55193/focusU337
as well as possibly some other discussions from that period
http://marc.info/?l=linux-fbdev&r=1&b 1010&w=4
> > Different subsystems use different data structures to describe video
> > mode/timing information:
> >
> > - struct drm_mode_modeinfo in DRM/KMS
> > - struct fb_videomode in FBDEV
> > - struct v4l2_bt_timings in V4L2
> >
> > A new common video mode/timing data structure (struct media_video_mode_info,
> > exact name is to be defined), not tied to any specific subsystem, is
> > required to share the EDID parser. That structure won't be exported to
> > userspace.
> >
> > Helper functions will be implemented in the subsystems to convert between
> > that generic structure and the various subsystem-specific structures.
> >
> > The mode list is stored in the DRM connector in the EDID parser. A new mode
> > list data structure can be added, or a callback function can be used by the
> > parser to give modes one at a time to the caller.
> >
> > 3D needs to be taken into account (this is similar to interlacing).
> >
> > Action points:
> > - Laurent to work on a proposal. The DRM/KMS EDID parser will be reused.
>
> I think we should include kernel cmdline video mode parsing here, afaik
> kms and fbdev are rather similar (won't work if they're too different,
> obviously).
This has been a pretty hot discussion topic wrt sh-mobile LCDC / HDMI
too:-) The goal was to (1) take into account driver's capabilities: not
all standard HDMI modes were working properly, (2) use EDID data, (3) give
the user a chance to select a specific mode. Also here a generic solution
would be very welcome, without breaking existing configurations, of
course:)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
From: David Airlie @ 2012-02-20 16:19 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Tomasz Stanislawski, linux-fbdev, Sakari Ailus, Marcus Lorentzon,
Pawel Osciak, Magnus Damm, dri-devel, Alexander Deucher,
Rob Clark, Marek Szyprowski, linux-media, Daniel Vetter
In-Reply-To: <Pine.LNX.4.64.1202201633100.2836@axis700.grange>
>
> I'm certainly absolutely in favour of creating a common EDID parser,
> and
> the DRM/KMS implementation might indeed be the most complete /
> advanced
> one, but at least back in 2010 as I was working on the sh-mobile HDMI
> driver, some functinality was still missing there, which I had to add
> to
> fbdev independently. Unless those features have been added to DRM /
> KMS
> since then you might want to use the fbdev version. See
>
> http://thread.gmane.org/gmane.linux.ports.arm.omap/55193/focusU337
>
> as well as possibly some other discussions from that period
>
> http://marc.info/?l=linux-fbdev&r=1&b 1010&w=4
One feature missing from the drm EDID parser doesn't mean the fbdev one is better in all cases.
Whoever takes over the merging process will have to check for missing bits anyways to avoid regressions.
> >
> > I think we should include kernel cmdline video mode parsing here,
> > afaik
> > kms and fbdev are rather similar (won't work if they're too
> > different,
> > obviously).
>
> This has been a pretty hot discussion topic wrt sh-mobile LCDC / HDMI
> too:-) The goal was to (1) take into account driver's capabilities:
> not
> all standard HDMI modes were working properly, (2) use EDID data, (3)
> give
> the user a chance to select a specific mode. Also here a generic
> solution
> would be very welcome, without breaking existing configurations, of
> course:)
The reason the drm has a more enhanced command line parser is to allow
for multiple devices otherwise it should parse mostly the same I thought
I based the drm one directly on the fbdev one + connector specifiers.
Dave.
^ permalink raw reply
* Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
From: Guennadi Liakhovetski @ 2012-02-20 16:40 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Sakari Ailus, Sumit Semwal, Jesse Barker, Jesse Barnes, Rob Clark,
Pawel Osciak, Marek Szyprowski, Tomasz Stanislawski, Magnus Damm,
Marcus Lorentzon, Alexander Deucher, linux-media, dri-devel,
linux-fbdev
In-Reply-To: <1775349.d0yvHiVdjB@avalon>
On Fri, 17 Feb 2012, Laurent Pinchart wrote:
[snip]
> *** Synchronous pipeline changes ***
>
> Goal: Create an API to apply complex changes to a video pipeline atomically.
>
> Needed for complex camera use cases. On the DRM/KMS side, the approach is to
> use one big ioctl to configure the whole pipeline.
>
> One solution is a commit ioctl, through the media controller device, that
> would be dispatched to entities internally with a prepare step and a commit
> step.
>
> Parameters to be committed need to be stored in a context. We can either use
> one cross-device context, or per-device contexts that would then need to be
> associated with the commit operation.
>
> Action points:
> - Sakari will provide a proof-of-concept and/or proposal if needed.
I actually have been toying with a related idea, namely replacing the
current ACTIVE / TRY configuration pair as not sufficiently clearly defined
and too restrictive with a more flexible concept of an arbitrary number of
configuration contexts. The idea was to allow the user to create such
contexts and use atomic commands to instruct the pipeline to switch between
them. However, as I started writing down an RFC, this was exactly the point,
where I stopped: what defines a configuration and in which order shall
configuration commands be executed when switching between them?
In short, my idea was to allow contexts to contain any configuration
options: not only geometry and pixel format as what TRY is using ATM, but
also any controls. The API would add commands like
handle = context_alloc(mode);
/*
* mode can be DEFAULT to start a new configuration, based on
* driver defaults, or CLONE to start with the currently active
* configuration
*/
context_configure(handle);
/*
* all configuration commands from now on happen in the background
* and only affect the specified context
*/
/* perform any configuration */
context_switch(handle);
/* activate one of pre-configured contexts */
The problem, however, is, how to store contexts and how to perform the
switch. We would, probably, have to define a notion of a "complete
configuration," which would consist of some generic parameters and,
optionally, driver-specific ones. Then the drivers (in the downstream
order?) would just be instructed to switch to a specific configuration
and each of them would then decide in which order they have to commit
specific parameters. This must assume, that regardless in what state a
device currently is, switching to context X always produces the same
result.
Alternative approaches, like, store each context as a sequence of
user-provided configuration commands, and play them back, when switching,
would produce unpredictable results, depending on the state, before the
switch, especially when using the CLONE context-creation mode.
Anyway, my tuppence to consider.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH] i740fb: fix compile error when CONFIG_MTRR is not selected
From: Ondrej Zary @ 2012-02-20 20:49 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-fbdev, linux-kernel, Stephen Rothwell, linux-next
In-Reply-To: <1329687211-6545-1-git-send-email-FlorianSchandinat@gmx.de>
On Sunday 19 February 2012 22:33:31 Florian Tobias Schandinat wrote:
> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> ---
> drivers/video/i740fb.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/i740fb.c b/drivers/video/i740fb.c
> index 8be0302..fe574d8 100644
> --- a/drivers/video/i740fb.c
> +++ b/drivers/video/i740fb.c
> @@ -1179,9 +1179,9 @@ static void __devexit i740fb_remove(struct pci_dev
> *dev) struct fb_info *info = pci_get_drvdata(dev);
>
> if (info) {
> -#ifdef CONFIG_MTRR
> struct i740fb_par *par = info->par;
>
> +#ifdef CONFIG_MTRR
> if (par->mtrr_reg >= 0) {
> mtrr_del(par->mtrr_reg, 0, 0);
> par->mtrr_reg = -1;
Thanks for fixing my stupid bug. I thought that I tested it without
CONFIG_MTRR. But obviously didn't.
--
Ondrej Zary
^ permalink raw reply
* fb_set_suspend usage in suspend/resume
From: Manjunathappa, Prakash @ 2012-02-21 14:17 UTC (permalink / raw)
To: linux-fbdev
Hi,
I got to know from man pages that fb_set_suspend will signal about suspend and resume
of low level driver to FB core and client drivers. But why do majority of FB drivers
in drivers/video/ folder doesnot call fb_set_suspend in their suspend and resume implementation?
Thanks,
Prakash
^ permalink raw reply
* [PATCH 1/8] ARM: OMAP2+: Move DISPC L3 firewall to happen in omap_display_init()
From: Tony Lindgren @ 2012-02-21 23:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120221233619.18709.87982.stgit@kaulin.local>
Otherwise we cannot move most of plat/io.h to be a local
iomap.h for mach-omap2.
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/display.c | 3 +++
drivers/video/omap2/dss/dispc.c | 5 -----
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 3677b1f..5a7f12f 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -191,6 +191,9 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
memset(&pdata, 0, sizeof(pdata));
if (cpu_is_omap24xx()) {
+ /* L3 firewall setting: enable access to OCM RAM */
+ __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
+
curr_dss_hwmod = omap2_dss_hwmod_data;
oh_count = ARRAY_SIZE(omap2_dss_hwmod_data);
} else if (cpu_is_omap34xx()) {
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e1626a1..cce0820 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3272,11 +3272,6 @@ static void _omap_dispc_initial_config(void)
if (dss_has_feature(FEAT_FUNCGATED))
REG_FLD_MOD(DISPC_CONFIG, 1, 9, 9);
- /* L3 firewall setting: enable access to OCM RAM */
- /* XXX this should be somewhere in plat-omap */
- if (cpu_is_omap24xx())
- __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
-
_dispc_setup_color_conv_coef();
dispc_set_loadmode(OMAP_DSS_LOAD_FRAME_ONLY);
^ permalink raw reply related
* [PATCH 8/8] ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
From: Tony Lindgren @ 2012-02-21 23:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120221233619.18709.87982.stgit@kaulin.local>
Drivers should no longer use omap_read/write functions
but instead use ioremap + read/write functions.
As some USB legacy code is still shared between omap1 and
omap2420, let's limit the omap_read/write to plat/usb.h.
Also, let's make drivers/video/omap/lcdc.c depend on
ARCH_OMAP1 as it is not needed for omap2+.
Note that the long term fix is to update the drivers to
use ioremap and read/write functions. That can now be
done as a separate patch series that is limited to the
USB drivers.
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/common.h | 10 --------
arch/arm/mach-omap2/io.c | 40 ---------------------------------
arch/arm/plat-omap/include/plat/usb.h | 40 +++++++++++++++++++++++++++++++++
drivers/video/omap/Kconfig | 2 +-
4 files changed, 41 insertions(+), 51 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 09ca9e9..f78ec4e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -242,15 +242,5 @@ struct omap_sdrc_params;
extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1);
-/*
- * NOTE: Please use ioremap + __raw_read/write where possible instead of these
- */
-extern u8 omap_readb(u32 pa);
-extern u16 omap_readw(u32 pa);
-extern u32 omap_readl(u32 pa);
-extern void omap_writeb(u8 v, u32 pa);
-extern void omap_writew(u16 v, u32 pa);
-extern void omap_writel(u32 v, u32 pa);
-
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 0119807..3203128 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -487,43 +487,3 @@ void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
_omap2_init_reprogram_sdrc();
}
}
-
-/*
- * NOTE: Please use ioremap + __raw_read/write where possible instead of these
- */
-
-u8 omap_readb(u32 pa)
-{
- return __raw_readb(OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_readb);
-
-u16 omap_readw(u32 pa)
-{
- return __raw_readw(OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_readw);
-
-u32 omap_readl(u32 pa)
-{
- return __raw_readl(OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_readl);
-
-void omap_writeb(u8 v, u32 pa)
-{
- __raw_writeb(v, OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_writeb);
-
-void omap_writew(u16 v, u32 pa)
-{
- __raw_writew(v, OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_writew);
-
-void omap_writel(u32 v, u32 pa)
-{
- __raw_writel(v, OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_writel);
diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h
index dc864b5..5f6ced4 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -3,6 +3,7 @@
#ifndef __ASM_ARCH_OMAP_USB_H
#define __ASM_ARCH_OMAP_USB_H
+#include <linux/io.h>
#include <linux/usb/musb.h>
#include <plat/board.h>
@@ -105,6 +106,45 @@ extern int omap4430_phy_set_clk(struct device *dev, int on);
extern int omap4430_phy_init(struct device *dev);
extern int omap4430_phy_exit(struct device *dev);
extern int omap4430_phy_suspend(struct device *dev, int suspend);
+
+/*
+ * NOTE: Please update omap USB drivers to use ioremap + read/write
+ */
+
+#define OMAP2_L4_IO_OFFSET 0xb2000000
+#define OMAP2_L4_IO_ADDRESS(pa) IOMEM((pa) + OMAP2_L4_IO_OFFSET)
+
+static inline u8 omap_readb(u32 pa)
+{
+ return __raw_readb(OMAP2_L4_IO_ADDRESS(pa));
+}
+
+static inline u16 omap_readw(u32 pa)
+{
+ return __raw_readw(OMAP2_L4_IO_ADDRESS(pa));
+}
+
+static inline u32 omap_readl(u32 pa)
+{
+ return __raw_readl(OMAP2_L4_IO_ADDRESS(pa));
+}
+
+static inline void omap_writeb(u8 v, u32 pa)
+{
+ __raw_writeb(v, OMAP2_L4_IO_ADDRESS(pa));
+}
+
+
+static inline void omap_writew(u16 v, u32 pa)
+{
+ __raw_writew(v, OMAP2_L4_IO_ADDRESS(pa));
+}
+
+static inline void omap_writel(u32 v, u32 pa)
+{
+ __raw_writel(v, OMAP2_L4_IO_ADDRESS(pa));
+}
+
#endif
extern void am35x_musb_reset(void);
diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig
index 84ff232..295d1cc 100644
--- a/drivers/video/omap/Kconfig
+++ b/drivers/video/omap/Kconfig
@@ -11,7 +11,7 @@ config FB_OMAP
config FB_OMAP_LCDC_EXTERNAL
bool "External LCD controller support"
- depends on FB_OMAP
+ depends on FB_OMAP && ARCH_OMAP1
help
Say Y here, if you want to have support for boards with an
external LCD controller connected to the SoSSI/RFBI interface.
^ permalink raw reply related
* Re: [PATCH 1/8] ARM: OMAP2+: Move DISPC L3 firewall to happen in omap_display_init()
From: Tomi Valkeinen @ 2012-02-22 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120221234035.18709.40664.stgit@kaulin.local>
[-- Attachment #1: Type: text/plain, Size: 2021 bytes --]
Hi,
On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
> Otherwise we cannot move most of plat/io.h to be a local
> iomap.h for mach-omap2.
>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/display.c | 3 +++
> drivers/video/omap2/dss/dispc.c | 5 -----
> 2 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> index 3677b1f..5a7f12f 100644
> --- a/arch/arm/mach-omap2/display.c
> +++ b/arch/arm/mach-omap2/display.c
> @@ -191,6 +191,9 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
> memset(&pdata, 0, sizeof(pdata));
>
> if (cpu_is_omap24xx()) {
> + /* L3 firewall setting: enable access to OCM RAM */
> + __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
> +
> curr_dss_hwmod = omap2_dss_hwmod_data;
> oh_count = ARRAY_SIZE(omap2_dss_hwmod_data);
> } else if (cpu_is_omap34xx()) {
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index e1626a1..cce0820 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -3272,11 +3272,6 @@ static void _omap_dispc_initial_config(void)
> if (dss_has_feature(FEAT_FUNCGATED))
> REG_FLD_MOD(DISPC_CONFIG, 1, 9, 9);
>
> - /* L3 firewall setting: enable access to OCM RAM */
> - /* XXX this should be somewhere in plat-omap */
> - if (cpu_is_omap24xx())
> - __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
> -
> _dispc_setup_color_conv_coef();
>
> dispc_set_loadmode(OMAP_DSS_LOAD_FRAME_ONLY);
>
I think the whole raw_writel line can be removed. It's been copied from
the old omapfb, and my understanding is that it's about using SRAM for
framebuffer. Using SRAM for fb is no longer supported, and I have a
patch set that removes the remaining SRAM code from omapfb/omapdss.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 8/8] ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
From: Tomi Valkeinen @ 2012-02-22 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120221234051.18709.3571.stgit@kaulin.local>
[-- Attachment #1: Type: text/plain, Size: 689 bytes --]
On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
> Drivers should no longer use omap_read/write functions
> but instead use ioremap + read/write functions.
>
> As some USB legacy code is still shared between omap1 and
> omap2420, let's limit the omap_read/write to plat/usb.h.
>
> Also, let's make drivers/video/omap/lcdc.c depend on
> ARCH_OMAP1 as it is not needed for omap2+.
I'm ok with the lcdc.c change, but I also have a patch series that makes
the same change, plus removes the omap2 code from drivers/video/omap/.
Can you check the series, and give ack if the arch/arm side looks fine?
It's this one: [PATCH 00/16] OMAPDSS: old OMAPFB cleanup
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
From: James Simmons @ 2012-02-22 16:03 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Daniel Vetter, Tomasz Stanislawski, linux-fbdev, Sakari Ailus,
Pawel Osciak, Magnus Damm, Marcus Lorentzon, dri-devel,
Alexander Deucher, Rob Clark, linux-media, Marek Szyprowski
In-Reply-To: <2168398.Pv8ir5xFGf@avalon>
> > Imo we should ditch this - fb accel doesn't belong into the kernel. Even
> > on hw that still has a blitter for easy 2d accel without a complete 3d
> > state setup necessary, it's not worth it. Chris Wilson from our team once
> > played around with implementing fb accel in the kernel (i915 hw still has
> > a blitter engine in the latest generations). He quickly noticed that to
> > have decent speed, competitive with s/w rendering by the cpu he needs the
> > entire batch and buffer management stuff from userspace. And to really
> > beat the cpu, you need even more magic.
> >
> > If you want fast 2d accel, use something like cairo.
>
> Our conclusion on this is that we should not expose an explicit 2D
> acceleration API at the kernel level. If really needed, hardware 2D
> acceleration could be implemented as a DRM device to handle memory management,
> commands ring setup, synchronization, ... but I'm not even sure if that's
> worth it. I might not have conveyed it well in my notes.
Fbcon scrolling at be painful at HD or better modes. Fbcon needs 3
possible accels; copyarea, imageblit, and fillrect. The first two could be
hooked from the TTM layer. Its something I plan to experiment to see if
its worth it.
^ permalink raw reply
* Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
From: Daniel Vetter @ 2012-02-22 16:24 UTC (permalink / raw)
To: James Simmons
Cc: Laurent Pinchart, Daniel Vetter, Tomasz Stanislawski, linux-fbdev,
Sakari Ailus, Pawel Osciak, Magnus Damm, Marcus Lorentzon,
dri-devel, Alexander Deucher, Rob Clark, linux-media,
Marek Szyprowski
In-Reply-To: <alpine.LFD.2.02.1202221559510.3721@casper.infradead.org>
On Wed, Feb 22, 2012 at 04:03:21PM +0000, James Simmons wrote:
>
> > > Imo we should ditch this - fb accel doesn't belong into the kernel. Even
> > > on hw that still has a blitter for easy 2d accel without a complete 3d
> > > state setup necessary, it's not worth it. Chris Wilson from our team once
> > > played around with implementing fb accel in the kernel (i915 hw still has
> > > a blitter engine in the latest generations). He quickly noticed that to
> > > have decent speed, competitive with s/w rendering by the cpu he needs the
> > > entire batch and buffer management stuff from userspace. And to really
> > > beat the cpu, you need even more magic.
> > >
> > > If you want fast 2d accel, use something like cairo.
> >
> > Our conclusion on this is that we should not expose an explicit 2D
> > acceleration API at the kernel level. If really needed, hardware 2D
> > acceleration could be implemented as a DRM device to handle memory management,
> > commands ring setup, synchronization, ... but I'm not even sure if that's
> > worth it. I might not have conveyed it well in my notes.
>
> Fbcon scrolling at be painful at HD or better modes. Fbcon needs 3
> possible accels; copyarea, imageblit, and fillrect. The first two could be
> hooked from the TTM layer. Its something I plan to experiment to see if
> its worth it.
Let's bite into this ;-) I know that fbcon scrolling totally sucks on big
screens, but I also think it's a total waste of time to fix this. Imo
fbcon has 2 use-cases:
- display an OOSP.
- allow me to run fsck (or any other desaster-recovery stuff).
It can do that quite fine already.
Flamy yours, Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
From: Rob Clark @ 2012-02-22 16:28 UTC (permalink / raw)
To: Daniel Vetter
Cc: James Simmons, Laurent Pinchart, Tomasz Stanislawski, linux-fbdev,
Sakari Ailus, Pawel Osciak, Magnus Damm, Marcus Lorentzon,
dri-devel, Alexander Deucher, linux-media, Marek Szyprowski
In-Reply-To: <20120222162424.GE4872@phenom.ffwll.local>
On Wed, Feb 22, 2012 at 10:24 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Feb 22, 2012 at 04:03:21PM +0000, James Simmons wrote:
>>
>> > > Imo we should ditch this - fb accel doesn't belong into the kernel. Even
>> > > on hw that still has a blitter for easy 2d accel without a complete 3d
>> > > state setup necessary, it's not worth it. Chris Wilson from our team once
>> > > played around with implementing fb accel in the kernel (i915 hw still has
>> > > a blitter engine in the latest generations). He quickly noticed that to
>> > > have decent speed, competitive with s/w rendering by the cpu he needs the
>> > > entire batch and buffer management stuff from userspace. And to really
>> > > beat the cpu, you need even more magic.
>> > >
>> > > If you want fast 2d accel, use something like cairo.
>> >
>> > Our conclusion on this is that we should not expose an explicit 2D
>> > acceleration API at the kernel level. If really needed, hardware 2D
>> > acceleration could be implemented as a DRM device to handle memory management,
>> > commands ring setup, synchronization, ... but I'm not even sure if that's
>> > worth it. I might not have conveyed it well in my notes.
>>
>> Fbcon scrolling at be painful at HD or better modes. Fbcon needs 3
>> possible accels; copyarea, imageblit, and fillrect. The first two could be
>> hooked from the TTM layer. Its something I plan to experiment to see if
>> its worth it.
>
> Let's bite into this ;-) I know that fbcon scrolling totally sucks on big
> screens, but I also think it's a total waste of time to fix this. Imo
> fbcon has 2 use-cases:
> - display an OOSP.
> - allow me to run fsck (or any other desaster-recovery stuff).
>
> It can do that quite fine already.
and for just fbcon scrolling, if you really wanted to you could
implement it by just shuffling pages around in a GART..
(although, someone, *please* re-write fbcon)
BR,
-R
> Flamy yours, Daniel
> --
> Daniel Vetter
> Mail: daniel@ffwll.ch
> Mobile: +41 (0)79 365 57 48
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
From: Chris Wilson @ 2012-02-22 16:36 UTC (permalink / raw)
To: Daniel Vetter, James Simmons
Cc: Tomasz Stanislawski, linux-fbdev, Sakari Ailus, Marcus Lorentzon,
Pawel Osciak, Magnus Damm, dri-devel, Alexander Deucher,
Rob Clark, linux-media, Marek Szyprowski
In-Reply-To: <20120222162424.GE4872@phenom.ffwll.local>
On Wed, 22 Feb 2012 17:24:24 +0100, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Feb 22, 2012 at 04:03:21PM +0000, James Simmons wrote:
> > Fbcon scrolling at be painful at HD or better modes. Fbcon needs 3
> > possible accels; copyarea, imageblit, and fillrect. The first two could be
> > hooked from the TTM layer. Its something I plan to experiment to see if
> > its worth it.
>
> Let's bite into this ;-) I know that fbcon scrolling totally sucks on big
> screens, but I also think it's a total waste of time to fix this. Imo
> fbcon has 2 use-cases:
> - display an OOSP.
> - allow me to run fsck (or any other desaster-recovery stuff).
3. Show panics.
Ensuring that nothing prevents the switch to fbcon and displaying the
panic message is the reason why we haven't felt inclined to accelerate
fbcon - it just gets messy for no real gain.
For example: https://bugs.freedesktop.org/attachment.cgi?idH933
which doesn't handle flushing of pending updates via the GPU when
writing with the CPU during interrupts (i.e. a panic).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
From: Clark, Rob @ 2012-02-22 16:40 UTC (permalink / raw)
To: Chris Wilson
Cc: Daniel Vetter, James Simmons, Tomasz Stanislawski, linux-fbdev,
Sakari Ailus, Marcus Lorentzon, Pawel Osciak, Magnus Damm,
dri-devel, Alexander Deucher, Marek Szyprowski, linux-media
In-Reply-To: <e39f63$3q903a@fmsmga002.fm.intel.com>
On Wed, Feb 22, 2012 at 10:36 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Wed, 22 Feb 2012 17:24:24 +0100, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Wed, Feb 22, 2012 at 04:03:21PM +0000, James Simmons wrote:
>> > Fbcon scrolling at be painful at HD or better modes. Fbcon needs 3
>> > possible accels; copyarea, imageblit, and fillrect. The first two could be
>> > hooked from the TTM layer. Its something I plan to experiment to see if
>> > its worth it.
>>
>> Let's bite into this ;-) I know that fbcon scrolling totally sucks on big
>> screens, but I also think it's a total waste of time to fix this. Imo
>> fbcon has 2 use-cases:
>> - display an OOSP.
>> - allow me to run fsck (or any other desaster-recovery stuff).
> 3. Show panics.
>
> Ensuring that nothing prevents the switch to fbcon and displaying the
> panic message is the reason why we haven't felt inclined to accelerate
> fbcon - it just gets messy for no real gain.
and when doing 2d accel on a 3d core.. it basically amounts to
putting a shader compiler in the kernel. Wheeee!
> For example: https://bugs.freedesktop.org/attachment.cgi?idH933
> which doesn't handle flushing of pending updates via the GPU when
> writing with the CPU during interrupts (i.e. a panic).
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
From: Adam Jackson @ 2012-02-22 17:00 UTC (permalink / raw)
To: James Simmons
Cc: Laurent Pinchart, Tomasz Stanislawski, linux-fbdev, Sakari Ailus,
Marcus Lorentzon, Pawel Osciak, Magnus Damm, dri-devel,
Alexander Deucher, Rob Clark, Marek Szyprowski, linux-media
In-Reply-To: <alpine.LFD.2.02.1202221559510.3721@casper.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 562 bytes --]
On Wed, 2012-02-22 at 16:03 +0000, James Simmons wrote:
> Fbcon scrolling at be painful at HD or better modes. Fbcon needs 3
> possible accels; copyarea, imageblit, and fillrect. The first two could be
> hooked from the TTM layer. Its something I plan to experiment to see if
> its worth it.
In my ideal world, the "framebuffer console" is something like vte under
wayland, which avoids this entirely. Scrolling on early boot until you
manage to get into initramfs would still be slow, but whatever, that's a
debugging feature anyway.
- ajax
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
From: James Simmons @ 2012-02-22 17:26 UTC (permalink / raw)
To: Clark, Rob
Cc: Chris Wilson, Daniel Vetter, Tomasz Stanislawski, linux-fbdev,
Sakari Ailus, Marcus Lorentzon, Pawel Osciak, Magnus Damm,
dri-devel, Alexander Deucher, Marek Szyprowski, linux-media
In-Reply-To: <CAO8GWqnVLfu5p3yNbE-BNqXfUu=2JX3S82GoJFS1baRwV126pQ@mail.gmail.com>
> > Ensuring that nothing prevents the switch to fbcon and displaying the
> > panic message is the reason why we haven't felt inclined to accelerate
> > fbcon - it just gets messy for no real gain.
>
> and when doing 2d accel on a 3d core.. it basically amounts to
> putting a shader compiler in the kernel. Wheeee!
Yikes. I'm not suggesting that. In fact I doubt accelerating the imageblit
would be worthy it due to the small size of the images being pushed. The
real cost is the copyarea which is used for scrolling when no panning is
available.
> > For example: https://bugs.freedesktop.org/attachment.cgi?idH933
> > which doesn't handle flushing of pending updates via the GPU when
> > writing with the CPU during interrupts (i.e. a panic).
> > -Chris
> >
> > --
> > Chris Wilson, Intel Open Source Technology Centre
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 03/16] OMAPDSS: Remove video SRAM support
From: Tony Lindgren @ 2012-02-22 18:06 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-4-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> OMAP SRAM can be used as video memory on OMAP1 and 2. However, there
> usually is very little SRAM available, thus limiting its use, and no
> board supported by the kernel currently uses it.
>
> This patch removes the use of SRAM as video ram for the omapdss driver
> to simplify memory handling.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
For the arch/arm/*omap*/* parts:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 04/16] OMAPFB: Remove video SRAM support (old omapfb)
From: Tony Lindgren @ 2012-02-22 18:06 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-5-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> OMAP SRAM can be used as video memory on OMAP1 and 2. However, there
> usually is very little SRAM available, thus limiting its use, and no
> board supported by the kernel currently uses it.
>
> This patch removes the use of SRAM as video ram for the old omapfb
> driver to simplify memory handling.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 05/16] OMAP2+: remove unneeded #include omapfb.h
From: Tony Lindgren @ 2012-02-22 18:07 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-6-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/mach-omap2/io.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index 3f174d5..7fee69c 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -21,7 +21,6 @@
> #include <linux/init.h>
> #include <linux/io.h>
> #include <linux/clk.h>
> -#include <linux/omapfb.h>
>
> #include <asm/tlb.h>
>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 06/16] OMAP: N770: remove HWA742 platform data
From: Tony Lindgren @ 2012-02-22 18:08 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-7-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> In an effort to clean up the old omapfb driver, this patch removes
> HWA742 (the display chip used in N770) platform data. This can be done
> as N770 is the only user of HWA742, and the platform data contains only
> one field, te_connected, which we can just presume to be true in the
> HWA742 driver.
>
> This allows us to remove omapfb_set_ctrl_platform_data(), and the
> mechanism to pass the platform data, in a later patch.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 07/16] OAMPFB: remove unused omapfb_set_ctrl_platform_data()
From: Tony Lindgren @ 2012-02-22 18:08 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-8-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> omapfb_set_ctrl_platform_data() is no longer used, so it can be removed.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 08/16] OMAPFB: remove early mem alloc from old omapfb
From: Tony Lindgren @ 2012-02-22 18:09 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-9-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> arch/arm/plat-omap/fb.c contains code to alloc omapfb buffers at early
> boot time according to information given from the bootloader or board
> file.
>
> This code isn't currently used by any board, and is anyway something
> that the newer vram.c could handle. So remove the alloc code and in
> later patches make old omapfb driver use vram.c.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ 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