* [PATCH 4/5] viafb: fix IGA1 modesetting on VX900
From: Florian Tobias Schandinat @ 2012-02-22 18:53 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat, stable
In-Reply-To: <cover.1329936280.git.FlorianSchandinat@gmx.de>
Even if the documentation calls this bit "Reserved" it has to be set
to 0 for correct modesetting on IGA1.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: stable@vger.kernel.org
---
drivers/video/via/hw.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index e6e7a8f..376af05 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1804,6 +1804,9 @@ static void hw_init(void)
break;
}
+ /* magic required on VX900 for correct modesetting on IGA1 */
+ via_write_reg_mask(VIACR, 0x45, 0x00, 0x01);
+
/* probably this should go to the scaling code one day */
via_write_reg_mask(VIACR, 0xFD, 0, 0x80); /* VX900 hw scale on IGA2 */
viafb_write_regx(scaling_parameters, ARRAY_SIZE(scaling_parameters));
--
1.7.9
^ permalink raw reply related
* [PATCH 3/5] viafb: select HW scaling on VX900 for IGA2
From: Florian Tobias Schandinat @ 2012-02-22 18:53 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat, stable
In-Reply-To: <cover.1329936280.git.FlorianSchandinat@gmx.de>
VX900 can do hardware scaling for both IGAs in contrast to previous
hardware which could do it only for IGA2. This patch ensures that
we set the parameter for IGA2 and not for IGA1. This fixes hardware
scaling on VX900 until we have the infrastructure to support it for
both IGAs.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: stable@vger.kernel.org
---
drivers/video/via/hw.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 4d799c8..e6e7a8f 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1805,6 +1805,7 @@ static void hw_init(void)
}
/* probably this should go to the scaling code one day */
+ via_write_reg_mask(VIACR, 0xFD, 0, 0x80); /* VX900 hw scale on IGA2 */
viafb_write_regx(scaling_parameters, ARRAY_SIZE(scaling_parameters));
/* Fill VPIT Parameters */
--
1.7.9
^ permalink raw reply related
* [PATCH 2/5] viafb: Fix bug in centering code
From: Florian Tobias Schandinat @ 2012-02-22 18:53 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <cover.1329936280.git.FlorianSchandinat@gmx.de>
Obviously this is a typo and although there were no effects observed
it's probably better to fix it.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/hw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index d35ced7..4d799c8 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1477,7 +1477,7 @@ static struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
timing.hor_sync_end = timing.hor_sync_start + var->hsync_len;
timing.hor_total = timing.hor_sync_end + var->left_margin + dx;
timing.hor_blank_start = timing.hor_addr + dx;
- timing.hor_blank_end = timing.hor_total - dy;
+ timing.hor_blank_end = timing.hor_total - dx;
timing.ver_addr = cyres;
timing.ver_sync_start = timing.ver_addr + var->lower_margin + dy;
timing.ver_sync_end = timing.ver_sync_start + var->vsync_len;
--
1.7.9
^ permalink raw reply related
* [PATCH 1/5] viafb: another workaround for OLPCs weird wiring
From: Florian Tobias Schandinat @ 2012-02-22 18:53 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <cover.1329936280.git.FlorianSchandinat@gmx.de>
On OLPC we must not touch this I2C bus or it will hang.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/viafbdev.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 4791165..9cfa92e 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -1752,8 +1752,10 @@ static void __devinit i2c_bus_probe(struct viafb_shared *shared)
shared->i2c_31 = via_aux_probe(viafb_find_i2c_adapter(VIA_PORT_31));
/* FIXME: what is this? */
- printk(KERN_INFO "viafb: Probing I2C bus 0x2C\n");
- shared->i2c_2C = via_aux_probe(viafb_find_i2c_adapter(VIA_PORT_2C));
+ if (!machine_is_olpc()) {
+ printk(KERN_INFO "viafb: Probing I2C bus 0x2C\n");
+ shared->i2c_2C = via_aux_probe(viafb_find_i2c_adapter(VIA_PORT_2C));
+ }
printk(KERN_INFO "viafb: Finished I2C bus probing");
}
--
1.7.9
^ permalink raw reply related
* [PATCH 0/5] viafb misc patches
From: Florian Tobias Schandinat @ 2012-02-22 18:53 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
Hi all,
this is another patch series for viafb. 1 and 2 are fixes for
previous patch series; 3 and 4 are fixes for our VX900 support;
5 is a cleanup
Best regards,
Florian Tobias Schandinat
Florian Tobias Schandinat (5):
viafb: another workaround for OLPCs weird wiring
viafb: Fix bug in centering code
viafb: select HW scaling on VX900 for IGA2
viafb: fix IGA1 modesetting on VX900
viafb: LCD bpp cleanup
drivers/video/via/chip.h | 1 -
drivers/video/via/hw.c | 22 +++++++---------------
drivers/video/via/hw.h | 2 +-
drivers/video/via/lcd.c | 21 ++++++++-------------
drivers/video/via/viafbdev.c | 8 +++++---
5 files changed, 21 insertions(+), 33 deletions(-)
--
1.7.9
^ permalink raw reply
* Re: [PATCH 00/16] OMAPDSS: old OMAPFB cleanup
From: Tony Lindgren @ 2012-02-22 18:50 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, archit, linux-omap
In-Reply-To: <1329220343.1845.65.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120214 03:21]:
> Hi Tony,
>
> On Tue, 2012-01-24 at 12:00 +0200, Tomi Valkeinen wrote:
> > Now that all omap2+ boards have been changed to use the newer omapdss driver,
> > this patch series removes omap2+ support from the old omapfb driver
> > (drivers/video/omap), and thus makes it an omap1 dss/fb driver.
> >
> > The use of SRAM for video ram had earlier been disabled by removing the SRAM
> > allocation (fee926bb0d399b1eaaf38f9f694bbf2747c4b8a2), and now this series also
> > removes the support from the omap fb drivers.
> >
> > Also various cleanup patches allow us to remove remove OMAP_TAG_LCD and
> > OMAP_TAG_FBMEM.
> >
> > All in all, the series removes quite a bit of unneeded code and cleans up the
> > links between the board files and the display drivers, and this should help
> > with device tree adaptation.
Great, looks good to me. I've acked the arch/arm/*omap*/* patches.
There may be some trivial merge conflicts with the includes with
my cleanup branch for the io.h changes.
> > Some of the patches affect the newer omapdss and omapfb drivers, but mostly the
> > patches deal with omap1. I have compile tested the series for both omap1 and
> > omap2, but I have only tested this on OMAP3 and OMAP4 boards, as I don't have
> > OMAP1/2 boards. I think N770's display won't work after these patches, but
> > other OMAP1 boards should be ok. To fix N770's display requires knowledge of
> > the hardware setup, which is currently passed from the bootloader.
>
> Tony, do you have any feedback on this? I think the arch/arm changes are
> quite clean as such, but are you ok with (possibly) breaking N770's
> display? The other OMAP1 boards should, at least in theory, work as well
> as before.
>
> For N770, the bootloader passes the reset GPIO number and number of
> datalines, and I have no idea what those are.
I think they should be:
conf->nreset_gpio = 13
conf->data_lines = 24
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 16/16] OMAPFB: remove remaining OMAP arch checks
From: Tony Lindgren @ 2012-02-22 18:11 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-17-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> Now that the old omapfb driver is only omap1 display driver, there's no
> need to check if the arch is omap1. This patch removes the few remaining
> checks for the arch.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 15/16] OMAP1: Remove unused LCD devices from board files
From: Tony Lindgren @ 2012-02-22 18:11 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-16-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> Some OMAP1 board files define LCD platform_devices, but there are no
> corresponding LCD drivers for those in the kernel. Thus remove these LCD
> devices.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 14/16] OMAP: Remove OMAP_TAG_LCD and OMAP_TAG_FBMEM
From: Tony Lindgren @ 2012-02-22 18:11 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-15-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> These tags are no longer used and can be removed.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 13/16] OMAP1: pass LCD config with omapfb_set_lcd_config()
From: Tony Lindgren @ 2012-02-22 18:10 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-14-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> LCD config for old omapfb driver is passed with OMAP_TAG_LCD from board
> files or from the bootloader. In an effort to remove OMAP_TAG_LCD, this
> patch adds omapfb_set_lcd_config() function that the board files can
> call to set the LCD config.
>
> This has the drawback that configuration can no longer come from the
> bootloader. Of the boards supported by the kernel, this should only
> affect N770 which depends on the data from the bootloader. This patch
> adds an LCD config for N770 to its board files, but that is most
> probably broken. Fixing this would need information about the HW setup
> in N770 boards.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 12/16] OMAPFB: remove omapfb_set_platform_data()
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-13-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> omapfb_set_platform_data() is no longer used, so remove it.
>
> 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
* 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 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 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 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 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: 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: 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: 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: 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: 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: 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: 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: [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
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