* Re: Future desktop on dumb frame buffers?
From: Jesse Barnes @ 2011-03-21 19:25 UTC (permalink / raw)
To: timofonic timofonic
Cc: Linux Fbdev development list, Geert Uytterhoeven,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
wayland-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <AANLkTimjOs8ZuKRUt1aOizhbRw2-Ni4bTPty-dKpZ-rz-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 21 Mar 2011 19:19:43 +0000
timofonic timofonic <timofonic@gmail.com> wrote:
> So if KMS is so cool and provides many advantages over fbdev and
> such... Why isn't more widely used intead of still relying on fbdev?
> Why still using fbdev emulation (that is partial and somewhat broken,
> it seems) instead using KMS directly?
Used by what? All three major GPU device classes have KMS support
(Intel, ATI, and nVidia). If you want it for a particular device, you
can always port it over.
As for fbdev emulation, what's still using it? There's nothing
stopping projects from converting over; X and Wayland can already
handle KMS APIs just fine.
> I know the graphic driver situation is quite bad on Linux, especially
> on the embedded world. Fbdev seems is still quite used there by binary
> blob drivers.
Probably for a couple of reasons:
1) inertia: fbdev has been around a lot longer, and provides most of
what embedded devices need anyway
2) feature set: why bother doing a full KMS driver if you're not
going to use any of the additional features it would provide (output
management, memory management, execution management)
Jesse
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: timofonic timofonic @ 2011-03-21 19:19 UTC (permalink / raw)
To: Jesse Barnes
Cc: Linux Fbdev development list, Geert Uytterhoeven,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
wayland-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20110321110040.6f1ea6d3@jbarnes-desktop>
Hello.
I have some rants and questions about fbdev, KMS and graphics stuff to
Linux. I'm just a mere user and occasional system administrator (and
going to start computer programming soon), but I hope to be able to
understand this situation better.
So if KMS is so cool and provides many advantages over fbdev and
such... Why isn't more widely used intead of still relying on fbdev?
Why still using fbdev emulation (that is partial and somewhat broken,
it seems) instead using KMS directly?
I know the graphic driver situation is quite bad on Linux, especially
on the embedded world. Fbdev seems is still quite used there by binary
blob drivers.
I was a fan of projects like DirectFB and such, but it seems they lack
the manpower or fuel to keep the project relevant. Maybe Wayland can
be their substitute and even have a broader usage too.
I hope KMS gets stronger and the graphic drivers get more into the
open source world (instead violating GPL and doing an attitude I think
should be illegal), that news about open source PowerVR SGX drivers
seems very positive (and surprising, because Imagination Technologies
seems quite against FOSS).
I hope all this gets to suck a bit less. Linux graphics stack
foundation based on KMS, TTM/GEM, advanced hardware accelerated video
decoding of most formats (by using OpenCL plus FFMpeg/LibAV, for
example), Gallium3D and full OpenGL 4.x support could make me very
happy as user and future developer...
Sadly, stuff like S3TC and such makes me very sad. I hope it gets
resolved sucessfully, patents are the nightmare of the technology...
Regards.
On Mon, Mar 21, 2011 at 6:00 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Sat, 19 Mar 2011 12:20:24 +0100
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
>> As noone responded to my question in
>> http://www.spinics.net/lists/dri-devel/msg08851.html
>> (yes, it was a bit hidden in a thread), I'm asking it here again (and
>> also on the Wayland
>> mailing list).
>>
>> Basically I'm still puzzled about this KMS thing. If the name "Kernel
>> Mode Setting"
>> covers it, then how does it compare to plain fbdev? Just additional frame buffer
>> memory management?
>> Also, some people may remember we did have kernel messages (e.g. oops, panic)
>> on graphical consoles with fbdev, until people started not liking them
>> showing up
>> on their X desktops...
>
> We support panic these days as well, but people still don't like seeing
> them. :)
>
> The DRM KMS APIs provide everything fbdev provides, plus memory
> management, a way to expose acceleration (via GEM or TTM), and a way to
> manage multiple outputs reasonably.
>
>> Furthermore, everybody states that "future desktop" (that's
>> http://wayland.freedesktop.org/)
>> will require KMS drivers.
>> How do/will we handle this on dumb frame buffers? It's not like we can't do
>> "advanced" things like compositing using the CPU. Transparency may stretch
>> it a bit on lower end CPUs, but you don't always need that.
>
> There's nothing in DRM that precludes doing simple fbdev-like drivers
> as well, though for many embedded uses I wouldn't expect it to provide
> a whole lot of benefit.
>
> --
> Jesse Barnes, Intel Open Source Technology Center
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
^ permalink raw reply
* Re: [GIT PULL] omap display subsystem changes for 2.6.39
From: Tomi Valkeinen @ 2011-03-21 18:17 UTC (permalink / raw)
To: John S; +Cc: Paul Mundt, linux-fbdev@vger.kernel.org,
linux-omap@vger.kernel.org
In-Reply-To: <AANLkTi=_zTJ0XeVC=MxqN6CzFqaXW0H6TbHEao3OihRb@mail.gmail.com>
On Mon, 2011-03-21 at 12:43 -0500, John S wrote:
> On Mon, Mar 21, 2011 at 3:21 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > Hi Paul,
> >
> > Here are OMAP display subsystem patches for 2.6.39 merge window. Quite a
> > bit of them, and many changes also in arch/arm/mach-omap2, which
> > unfortunately couldn't go through Tony's linux-omap tree due to
> > dependencies on DSS driver code.
<snip>
> some of these patches had problems related to HDMI:
> http://www.spinics.net/lists/linux-omap/msg48740.html
> Was this issue resolved?
No. We haven't been able to reproduce, and I haven't heard of anyone
else reporting problems. So I believe the patches are good enough for
rc1.
Tomi
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Jesse Barnes @ 2011-03-21 18:00 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux Fbdev development list, dri-devel, wayland-devel
In-Reply-To: <AANLkTimJWpebAskcjA+qQUDWXjiH6aHta4fri9z6OxRN@mail.gmail.com>
On Sat, 19 Mar 2011 12:20:24 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> As noone responded to my question in
> http://www.spinics.net/lists/dri-devel/msg08851.html
> (yes, it was a bit hidden in a thread), I'm asking it here again (and
> also on the Wayland
> mailing list).
>
> Basically I'm still puzzled about this KMS thing. If the name "Kernel
> Mode Setting"
> covers it, then how does it compare to plain fbdev? Just additional frame buffer
> memory management?
> Also, some people may remember we did have kernel messages (e.g. oops, panic)
> on graphical consoles with fbdev, until people started not liking them
> showing up
> on their X desktops...
We support panic these days as well, but people still don't like seeing
them. :)
The DRM KMS APIs provide everything fbdev provides, plus memory
management, a way to expose acceleration (via GEM or TTM), and a way to
manage multiple outputs reasonably.
> Furthermore, everybody states that "future desktop" (that's
> http://wayland.freedesktop.org/)
> will require KMS drivers.
> How do/will we handle this on dumb frame buffers? It's not like we can't do
> "advanced" things like compositing using the CPU. Transparency may stretch
> it a bit on lower end CPUs, but you don't always need that.
There's nothing in DRM that precludes doing simple fbdev-like drivers
as well, though for many embedded uses I wouldn't expect it to provide
a whole lot of benefit.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [GIT PULL] omap display subsystem changes for 2.6.39
From: John S @ 2011-03-21 17:55 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Paul Mundt, linux-fbdev, linux-omap
In-Reply-To: <1300701083.2891.77.camel@deskari>
On Mon, Mar 21, 2011 at 3:21 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Paul,
>
> Here are OMAP display subsystem patches for 2.6.39 merge window. Quite a
> bit of them, and many changes also in arch/arm/mach-omap2, which
> unfortunately couldn't go through Tony's linux-omap tree due to
> dependencies on DSS driver code.
>
> The patches are mostly aiming to get OMAP4 display support up and
> running and both HDMI and DVI outputs should now work on Blaze and Panda
> boards.
>
> One problem I noticed just now, the committer names seem a bit messed
> up. For example, Archit Taneja has three different style names there. Do
> you think I should rebase and fix them? Not a big job, but it'll mean,
> well, rebasing.
>
> There's a minor conflict in Overo's board file. I have pushed
> "for-paul-merged" branch to gitorious, which contains a merge with
> Linus' tree. I'm not sure that is the best way to show how to fix the
> conflict, but hopefully it'll give the idea.
>
> Tomi
>
>
> The following changes since commit a44f99c7efdb88fa41128065c9a9445c19894e34:
>
> Merge branch 'trivial' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6 (2011-03-20 18:14:55 -0700)
>
> are available in the git repository at:
>
> git://gitorious.org/linux-omap-dss2/linux.git for-paul
>
> Archit Taneja (9):
> OMAP2PLUS: DSS2: Generalize naming of PRCM related clock enums in DSS driver
> OMAP2PLUS: DSS2: Generalize external clock names in struct dss of dss.c
> OMAP2PLUS: DSS2: FEATURES: DISPC overlay code cleanup
> OMAP2PLUS: DSS2: FEATURES: Function to Provide the max fck supported
> OMAP2PLUS: DSS2: Make members of dss_clk_source generic
> OMAP2PLUS: DSS2: Use dss features to get clock source names of current OMAP
> OMAP2PLUS: DSS2: DSI: Generalize DSI PLL Clock Naming
> OMAP: DSS2: Functions to request/release DSI VCs
> OMAP: DSS2: Use request / release calls in Taal for DSI Virtual Channels.
>
> Jani Nikula (1):
> OMAP: DSS2: Fix def_disp module param description
>
> Janorkar, Mayuresh (2):
> OMAPFB: Adding a check for timings in set_def_mode
> OMAP: OMAPFB: Adding help for FB_OMAP_LCD_VGA option
>
> Jarkko Nikula (1):
> omapfb: Fix linker error in drivers/video/omap/lcd_2430sdp.c
>
> K, Mythri P (1):
> OMAP4: HDMI: Add HDMI structure in the board file for OMAP4 PANDA
>
> Mayuresh Janorkar (2):
> OMAP2PLUS: DSS2: Add OMAP4 Kconfig support
> OMAP4: DSS2: Add hwmod device names for OMAP4.
>
> Murthy, Raghuveer (5):
> OMAP: DSS2: Adding dss_features for independent core clk divider
> OMAP: DSS2: Renaming register macro DISPC_DIVISOR(ch)
> OMAP4: DSS2: Using dss_features to set independent core clock divider
> OMAP: DSS2: Implement OMAP4 DSS fclk support
> OMAP4: PandaBoard: Adding DVI support
>
> Mythri P K (9):
> OMAP4: DSS2: Add display type HDMI to DSS2
> OMAP4: DSS2: HDMI: Select between HDMI VENC clock source.
> OMAP4: DSS2: HDMI: Dispc gamma enable set/reset function for TV.
> OMAP4: DSS2: HDMI: HDMI driver header file addition
> OMAP4: DSS2: HDMI: HDMI driver addition in the DSS
> OMAP4: DSS2: HDMI: HDMI panel driver addition in the DSS
> OMAP4: DSS2: HDMI: Add makefile and kconfig changes to enable HDMI in OMAP4
> OMAP4: DSS: HDMI: Call to HDMI module init to register driver.
> OMAP4: HDMI: Add HDMI structure in the board file for OMAP4 SDP
>
> Samreen (1):
> OMAP2/3/4: DSS2: Enable Display SubSystem as modules
>
> Semwal, Sumit (2):
> OMAP2PLUS:DSS2: add opt_clock_available in pdata
> OMAP2PLUS:DSS2: Use opt_clock_available from pdata
>
> Senthilvadivu Guruswamy (9):
> OMAP2,3: DSS2: Build omap_device for each DSS HWIP
> OMAP2, 3: DSS2: DSS: create platform_driver, move init, exit to driver
> OMAP2, 3: DSS2: Move clocks from core driver to dss driver
> OMAP2, 3: DSS2: RFBI: create platform_driver, move init, exit to driver
> OMAP2, 3: DSS2: DISPC: create platform_driver, move init, exit to driver
> OMAP2, 3: DSS2: VENC: create platform_driver, move init, exit to driver
> OMAP2, 3: DSS2: DSI: create platform_driver, move init, exit to driver
> OMAP2,3: DSS2: Use platform device to get baseaddr
> OMAP2,3: DSS2: Get DSS IRQ from platform device
>
> Steve Sakoman (5):
> OMAP: DSS2: Add support for LG Philips LB035Q02 panel
> OMAP: DSS2: Add DSS2 support for Overo
> omap: overo: Add regulator for ads7846
> OMAP: Add gpio-leds support for Overo
> OMAP: Add gpio-keys support for Overo
>
> Sumit Semwal (4):
> OMAP2, 3: DSS2: remove forced clk-disable from omap_dss_remove
> OMAP2,3: DSS2: replace printk with dev_dbg in init
> OMAP2PLUS: clocks: Align DSS clock names and roles
> OMAP4: DSS2: clocks: Add ick as dummy clock
>
> Taneja, Archit (5):
> OMAP2PLUS: DSS2: Cleanup clock source related code
> OMAP4: DSS2: Clock source changes for OMAP4
> OMAP2PLUS: DSS2: FEATURES: Fix usage of dss_reg_field and dss_clk_source_name
> OMAP: DSS2: FEATURES: Functions to return min and max values of parameters
> OMAP: DSS2: FEATURES: DSI PLL parameter cleanup
>
> Tomi Valkeinen (25):
> OMAP: 3430SDP: Remove unused vdda_dac supply
> OMAP: DSS2: Delay regulator_get() calls
> OMAP: DSS2: Support for Samsung LTE430WQ-F0C
> MAINTAINERS: Update OMAP DSS maintainer
> OMAP: DSS2: Clean up a switch-case
> OMAP: DSS2: FEATURES: Remove SDI from 3630 displays
> OMAP: DSS2: FEATURES: Remove DSI & SDI from OMAP2
> OMAP: DSS2: Check for SDI HW before accessing SDI registers
> OMAP: DSS2: Remove unused list
> OMAP: DSS2: DSI: remove unused function
> OMAP: DSS2: Remove FB_OMAP_BOOTLOADER_INIT support
> OMAP: DSS2: Remove pdev argument from dpi_init
> OMAP: DSS2: Move DPI & SDI init into DSS plat driver
> OMAP: DSS2: Remove unneeded cpu_is_xxx checks
> HACK: OMAP: DSS2: Fix OMAP2_DSS_USE_DSI_PLL
> HACK: OMAP: DSS2: add delay after enabling clocks
> OMAP: DSS2: fix omap_dispc_register_isr() fail path
> HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to prevent crash
> OMAP: DSS2: DSI: Restructure IRQ handler
> OMAP: DSS2: DSI: Add ISR support
> OMAP: DSS2: DSI: use ISR in send_bta_sync
> OMAP: DSS2: DSI: use ISR for BTA in framedone
> OMAP: DSS2: DSI: catch DSI errors in send_bta_sync
> OMAP: DSS2: DSI: fix IRQ debug prints
> OMAP: DSS2: Clean up for dpll4_m4_ck handling
>
> archit taneja (1):
> OMAP: DSS2: Have separate irq handlers for DISPC and DSI
>
some of these patches had problems related to HDMI:
http://www.spinics.net/lists/linux-omap/msg48740.html
Was this issue resolved?
> MAINTAINERS | 4 +-
> arch/arm/configs/omap2plus_defconfig | 11 +
> arch/arm/mach-omap2/board-3430sdp.c | 6 +-
> arch/arm/mach-omap2/board-4430sdp.c | 75 ++
> arch/arm/mach-omap2/board-cm-t35.c | 2 +-
> arch/arm/mach-omap2/board-devkit8000.c | 12 +-
> arch/arm/mach-omap2/board-igep0020.c | 10 +-
> arch/arm/mach-omap2/board-omap3beagle.c | 12 +-
> arch/arm/mach-omap2/board-omap3evm.c | 12 +-
> arch/arm/mach-omap2/board-omap3pandora.c | 3 +-
> arch/arm/mach-omap2/board-omap3stalker.c | 12 +-
> arch/arm/mach-omap2/board-omap4panda.c | 203 +++-
> arch/arm/mach-omap2/board-overo.c | 357 +++++-
> arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
> arch/arm/mach-omap2/board-zoom-peripherals.c | 12 +-
> arch/arm/mach-omap2/clock2420_data.c | 8 +-
> arch/arm/mach-omap2/clock2430_data.c | 8 +-
> arch/arm/mach-omap2/clock3xxx_data.c | 14 +-
> arch/arm/mach-omap2/clock44xx_data.c | 15 +-
> arch/arm/mach-omap2/display.c | 80 ++
> arch/arm/mach-omap2/omap_hwmod_2420_data.c | 13 +-
> arch/arm/mach-omap2/omap_hwmod_2430_data.c | 12 +-
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 23 +-
> arch/arm/plat-omap/include/plat/display.h | 15 +-
> drivers/video/omap/Kconfig | 7 +-
> drivers/video/omap2/displays/Kconfig | 6 +
> drivers/video/omap2/displays/Makefile | 1 +
> drivers/video/omap2/displays/panel-generic-dpi.c | 25 +
> .../omap2/displays/panel-lgphilips-lb035q02.c | 279 ++++
> drivers/video/omap2/displays/panel-taal.c | 123 +-
> drivers/video/omap2/dss/Kconfig | 14 +-
> drivers/video/omap2/dss/Makefile | 2 +
> drivers/video/omap2/dss/core.c | 480 +-------
> drivers/video/omap2/dss/dispc.c | 335 ++++--
> drivers/video/omap2/dss/display.c | 35 +-
> drivers/video/omap2/dss/dpi.c | 45 +-
> drivers/video/omap2/dss/dsi.c | 967 +++++++++++----
> drivers/video/omap2/dss/dss.c | 763 +++++++++--
> drivers/video/omap2/dss/dss.h | 153 ++-
> drivers/video/omap2/dss/dss_features.c | 163 ++-
> drivers/video/omap2/dss/dss_features.h | 27 +
> drivers/video/omap2/dss/hdmi.c | 1332 ++++++++++++++++++++
> drivers/video/omap2/dss/hdmi.h | 415 ++++++
> drivers/video/omap2/dss/hdmi_omap4_panel.c | 222 ++++
> drivers/video/omap2/dss/manager.c | 13 +-
> drivers/video/omap2/dss/overlay.c | 10 +-
> drivers/video/omap2/dss/rfbi.c | 128 ++-
> drivers/video/omap2/dss/sdi.c | 62 +-
> drivers/video/omap2/dss/venc.c | 128 ++-
> drivers/video/omap2/omapfb/Kconfig | 6 +-
> drivers/video/omap2/omapfb/omapfb-main.c | 23 +-
> 51 files changed, 5323 insertions(+), 1362 deletions(-)
> create mode 100644 drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
> create mode 100644 drivers/video/omap2/dss/hdmi.c
> create mode 100644 drivers/video/omap2/dss/hdmi.h
> create mode 100644 drivers/video/omap2/dss/hdmi_omap4_panel.c
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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
* [PATCH v3] matroxfb: remove incorrect Matrox G200eV support
From: Gary Hade @ 2011-03-21 17:28 UTC (permalink / raw)
To: linux-fbdev, linux-kernel, Linus Torvalds
Cc: Darrick J. Wong, Krzysztof Helt, Petr Vandrovec, Andrew Morton,
Christian Toutant, Gary Hade
From: Gary Hade <garyhade@us.ibm.com>
Remove incorrect Matrox G200eV support that was previously
added by commit e3a1938805d2e81b27d3d348788644f3bad004f2
A serious issue with the incorrect G200eV support that reproduces
on the Matrox G200eV equipped IBM x3650 M2 is the total lack of
text (login banner, login prompt, etc) on the console when X is
not running and total lack of text on all of the virtual consoles
after X is started.
Any concerns that the incorrect code (upstream since October 2008)
has been successfully used on non-IBM G200eV equipped system(s)
appear to be unwarranted. In addition to the serious/non-intermittent
nature of issues that have been spotted on IBM systems, complete
removal of the incorrect code is clearly supported by the following
Matrox (Yannick Heneault) provided input.
"It impossible that this patch should have work on a system.
The patch only declare the G200eV as a regular G200 which is
not case. Many registers are different, including at least the
PLL programming sequence. If the G200eV is programmed like a
regular G200, it will not display anything."
v1 - Initial patch that removed the incorrect code for _all_
G200eV equipped systems.
v2 - Darrick Wong provided patch that blacklisted the incorrect
code on G200eV equipped IBM systems leaving it enabled on
all G200eV equipped non-IBM systems.
v3 - Same code changes included with v1 plus additional
justification for complete removal of the incorrect code.
Signed-off-by: Gary Hade <garyhade@us.ibm.com>
Cc: Darrick J. Wong <djwong@us.ibm.com>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Yannick Heneault <yannick_heneault@matrox.com>
Cc: Christian Toutant <ctoutant@matrox.com>
---
drivers/video/matrox/matroxfb_base.c | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/drivers/video/matrox/matroxfb_base.c b/drivers/video/matrox/matroxfb_base.c
index a082deb..a74439a 100644
--- a/drivers/video/matrox/matroxfb_base.c
+++ b/drivers/video/matrox/matroxfb_base.c
@@ -1461,13 +1461,6 @@ static struct board {
MGA_G100,
&vbG100,
"MGA-G100 (AGP)"},
- {PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200EV_PCI, 0xFF,
- 0, 0,
- DEVF_G200,
- 230000,
- MGA_G200,
- &vbG200,
- "MGA-G200eV (PCI)"},
{PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200_PCI, 0xFF,
0, 0,
DEVF_G200,
@@ -2119,8 +2112,6 @@ static struct pci_device_id matroxfb_devices[] = {
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G100_AGP,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200EV_PCI,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200_PCI,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200_AGP,
^ permalink raw reply related
* Re: [PATCH 08/20] video: msm: Refactor mdp_regs
From: Brian Swetland @ 2011-03-21 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D8789AA.8050803@codeaurora.org>
On Mon, Mar 21, 2011 at 10:23 AM, Bryan Huntsman <bryanh@codeaurora.org> wrote:
> On 03/20/2011 10:17 PM, Janorkar, Mayuresh wrote:
>>> diff --git a/drivers/video/msm/mdp_ppp.h b/drivers/video/msm/mdp_ppp.h
>>> new file mode 100644
>>> index 0000000..ef3b125
>>> --- /dev/null
>>> +++ b/drivers/video/msm/mdp_ppp.h
>>> @@ -0,0 +1,50 @@
>>> +/* drivers/video/msm/mdp_ppp.h
>>> + *
>>> + * Copyright (C) 2009 Google Incorporated
>>
>> If you want correct copyright info (to 2009-2011) here.
>
> Carl is submitting a change made by Google in 2009. I believe having
> 2009 as the only copyright year is correct. Carl/Brian, please correct
> me here if the date of the change was more than 2009. Thanks.
Google is fine with leaving our copyright line as originally authored.
No need to modify it.
Thanks,
Brian
^ permalink raw reply
* Re: [PATCH 08/20] video: msm: Refactor mdp_regs
From: Bryan Huntsman @ 2011-03-21 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB033D22EB6E@dbde02.ent.ti.com>
On 03/20/2011 10:17 PM, Janorkar, Mayuresh wrote:
...
>> diff --git a/drivers/video/msm/mdp_ppp.h b/drivers/video/msm/mdp_ppp.h
>> new file mode 100644
>> index 0000000..ef3b125
>> --- /dev/null
>> +++ b/drivers/video/msm/mdp_ppp.h
>> @@ -0,0 +1,50 @@
>> +/* drivers/video/msm/mdp_ppp.h
>> + *
>> + * Copyright (C) 2009 Google Incorporated
>
> If you want correct copyright info (to 2009-2011) here.
Carl is submitting a change made by Google in 2009. I believe having
2009 as the only copyright year is correct. Carl/Brian, please correct
me here if the date of the change was more than 2009. Thanks.
- Bryan
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH 07/20] video: msm: Allow users to request a larger x
From: Russell King - ARM Linux @ 2011-03-21 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB033D22EAE7@dbde02.ent.ti.com>
On Mon, Mar 21, 2011 at 10:10:09AM +0530, Janorkar, Mayuresh wrote:
> > + fix->line_length = var->xres * var->bits_per_pixel / 8;
> Why to divide by 8? Atleast use >>3, bitwise operations that would take
> less cpu cycles)
> As I stated earlier define a new macro for var also.
Modern compilers know about such things. >> 3 vs / 8 (probably) makes no
difference to the generated code with the toolchains we use.
^ permalink raw reply
* Re: Xrandr and udlfb
From: Alexander Todorov @ 2011-03-21 15:27 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <4D84BB47.2030100@otb.bg>
На 19.03.2011 16:18, Alexander Todorov написа:
> Hello folks,
> does udlfb support Xrandr? What I need is to be able to rotate the display which
> for some reason I can't.
>
Hello,
I've found this post about udlfb rotation:
http://plugable.com/2010/01/02/displaylink-linux-rotation/
As it seems there are some drawbacks.
Can anyone give information about current status of rotation support for udlfb
and which is the preferred way to implement it?
Thanks,
Alexander.
^ permalink raw reply
* [patch v2] fbdev: sh_mobile_lcdc: checking NULL instead of IS_ERR()
From: Dan Carpenter @ 2011-03-21 15:03 UTC (permalink / raw)
To: linux-fbdev
backlight_device_register() returns an ERR_PTR. It doesn't return NULL.
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
V2: print the error code as well.
This patch is againts linux-next, in case you missed that earlier.
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index bf2629f..757665b 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -1088,8 +1088,9 @@ static struct backlight_device *sh_mobile_lcdc_bl_probe(struct device *parent,
bl = backlight_device_register(ch->cfg.bl_info.name, parent, ch,
&sh_mobile_lcdc_bl_ops, NULL);
- if (!bl) {
- dev_err(parent, "unable to register backlight device\n");
+ if (IS_ERR(bl)) {
+ dev_err(parent, "unable to register backlight device: %ld\n",
+ PTR_ERR(bl));
return NULL;
}
^ permalink raw reply related
* Re: [PATCH 18/20] video: msm: Prevent DMA lockups when switching
From: Sergei Shtylyov @ 2011-03-21 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1300485585-27640-1-git-send-email-carlv@codeaurora.org>
Hello.
Carl Vanderlip wrote:
> Forces the lcdc off and waits a frame vsync period to prevent the MDP DMA
> engine crashing if the DMA bit depth is changed. A sleep cannot be used
> because lcdc_dma_start is called in irq context.
Maybe I'm blind again but I don't see any waiting...
> Authors:
> Dima Zavin <dima@android.com>
> Rebecca Schultz Zavin <rebecca@android.com>
> Colin Cross <ccross@android.com>
> Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
> ---
> drivers/video/msm/mdp.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
> diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
> index b3f334ad..49d956a 100644
> --- a/drivers/video/msm/mdp.c
> +++ b/drivers/video/msm/mdp.c
> @@ -564,6 +564,13 @@ void mdp_hw_init(struct mdp_info *mdp)
> mdp_writel(mdp, 1, 0x60);
> mdp_writel(mdp, 1, MDP_EBI2_PORTMAP_MODE);
>
> + /* disable lcdc */
> + mdp_writel(mdp, 0, MDP_LCDC_CTL);
> + /* enable auto clock gating for all blocks by default */
> + mdp_writel(mdp, 0xffffffff, MDP_CGC_EN);
> + /* reset color/gamma correct parms */
> + mdp_writel(mdp, 0, MDP_DMA_P_COLOR_CORRECT_CONFIG);
> +
> mdp_writel(mdp, 0, MDP_CMD_DEBUG_ACCESS_BASE + 0x01f8);
> mdp_writel(mdp, 0, MDP_CMD_DEBUG_ACCESS_BASE + 0x01fc);
> mdp_writel(mdp, 1, 0x60);
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 17/20] video: msm: Prevent framebuffer glitch during initialization
From: Sergei Shtylyov @ 2011-03-21 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1300485574-27600-1-git-send-email-carlv@codeaurora.org>
Hello.
Carl Vanderlip wrote:
> Holds a reference to the mdp_clk until lateinit, and moves the frambuffer
> initialization to device_init.
Maybe I'm just blind but I don't see where the patch does the latter...
> The framebuffer lcdc driver will grab a
> reference to mdp_clk, which prevents the clock from being disabled by
> clock_late_init.
> Authors:
> Dima Zavin <dima@android.com>
> Rebecca Schultz Zavin <rebecca@android.com>
> Colin Cross <ccross@android.com>
> Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
> ---
> drivers/video/msm/mdp.c | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
> diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
> index 0bb19fa..b3f334ad 100644
> --- a/drivers/video/msm/mdp.c
> +++ b/drivers/video/msm/mdp.c
> @@ -38,6 +38,7 @@ struct class *mdp_class;
>
> static DECLARE_WAIT_QUEUE_HEAD(mdp_ppp_waitqueue);
> static unsigned int mdp_irq_mask;
> +struct clk *mdp_clk_to_disable_later;
Why not just 'mdp_clk'? :-)
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 15/20] video: msm: convert printk to pr_*
From: Sergei Shtylyov @ 2011-03-21 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1300485552-27519-1-git-send-email-carlv@codeaurora.org>
Hello.
Carl Vanderlip wrote:
> Reword debugging messages to use pr_err and pr_warning
> Authors:
> Dima Zavin <dima@android.com>
> Rebecca Schultz Zavin <rebecca@android.com>
> Colin Cross <ccross@android.com>
> Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
> ---
> drivers/video/msm/mdp.c | 11 ++++-------
> 1 files changed, 4 insertions(+), 7 deletions(-)
> diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
> index 8184ca9..b03204d 100644
> --- a/drivers/video/msm/mdp.c
> +++ b/drivers/video/msm/mdp.c
> @@ -42,16 +42,13 @@ DEFINE_MUTEX(mdp_mutex);
>
> static int locked_enable_mdp_irq(struct mdp_info *mdp, uint32_t mask)
> {
> - int ret = 0;
> -
> BUG_ON(!mask);
>
> /* if the mask bits are already set return an error, this interrupt
> * is already enabled */
> if (mdp_irq_mask & mask) {
> - printk(KERN_ERR "mdp irq already on already on %x %x\n",
> - mdp_irq_mask, mask);
> - ret = -1;
> + pr_err("mdp irq already on %x %x\n", mdp_irq_mask, mask);
> + return -1;
This change to *return* is not described.
WBR, Sergei
^ permalink raw reply
* Re: [GIT PULL] omap display subsystem changes for 2.6.39
From: Tomi Valkeinen @ 2011-03-21 13:05 UTC (permalink / raw)
To: Paul Mundt; +Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
In-Reply-To: <1300701083.2891.77.camel@deskari>
Hi,
On Mon, 2011-03-21 at 04:51 -0500, Tomi Valkeinen wrote:
> Hi Paul,
>
> Here are OMAP display subsystem patches for 2.6.39 merge window. Quite a
> bit of them, and many changes also in arch/arm/mach-omap2, which
> unfortunately couldn't go through Tony's linux-omap tree due to
> dependencies on DSS driver code.
>
> The patches are mostly aiming to get OMAP4 display support up and
> running and both HDMI and DVI outputs should now work on Blaze and Panda
> boards.
>
> One problem I noticed just now, the committer names seem a bit messed
> up. For example, Archit Taneja has three different style names there. Do
> you think I should rebase and fix them? Not a big job, but it'll mean,
> well, rebasing.
>
> There's a minor conflict in Overo's board file. I have pushed
> "for-paul-merged" branch to gitorious, which contains a merge with
> Linus' tree. I'm not sure that is the best way to show how to fix the
> conflict, but hopefully it'll give the idea.
>
> Tomi
>
>
> The following changes since commit a44f99c7efdb88fa41128065c9a9445c19894e34:
>
> Merge branch 'trivial' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6 (2011-03-20 18:14:55 -0700)
>
> are available in the git repository at:
>
> git://gitorious.org/linux-omap-dss2/linux.git for-paul
I forgot to mention that this branch is based on Tony's omap-for-linus
branch, which got merged last week.
Tomi
^ permalink raw reply
* [GIT PULL] omap display subsystem changes for 2.6.39
From: Tomi Valkeinen @ 2011-03-21 9:51 UTC (permalink / raw)
To: Paul Mundt; +Cc: linux-fbdev, linux-omap
Hi Paul,
Here are OMAP display subsystem patches for 2.6.39 merge window. Quite a
bit of them, and many changes also in arch/arm/mach-omap2, which
unfortunately couldn't go through Tony's linux-omap tree due to
dependencies on DSS driver code.
The patches are mostly aiming to get OMAP4 display support up and
running and both HDMI and DVI outputs should now work on Blaze and Panda
boards.
One problem I noticed just now, the committer names seem a bit messed
up. For example, Archit Taneja has three different style names there. Do
you think I should rebase and fix them? Not a big job, but it'll mean,
well, rebasing.
There's a minor conflict in Overo's board file. I have pushed
"for-paul-merged" branch to gitorious, which contains a merge with
Linus' tree. I'm not sure that is the best way to show how to fix the
conflict, but hopefully it'll give the idea.
Tomi
The following changes since commit a44f99c7efdb88fa41128065c9a9445c19894e34:
Merge branch 'trivial' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6 (2011-03-20 18:14:55 -0700)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git for-paul
Archit Taneja (9):
OMAP2PLUS: DSS2: Generalize naming of PRCM related clock enums in DSS driver
OMAP2PLUS: DSS2: Generalize external clock names in struct dss of dss.c
OMAP2PLUS: DSS2: FEATURES: DISPC overlay code cleanup
OMAP2PLUS: DSS2: FEATURES: Function to Provide the max fck supported
OMAP2PLUS: DSS2: Make members of dss_clk_source generic
OMAP2PLUS: DSS2: Use dss features to get clock source names of current OMAP
OMAP2PLUS: DSS2: DSI: Generalize DSI PLL Clock Naming
OMAP: DSS2: Functions to request/release DSI VCs
OMAP: DSS2: Use request / release calls in Taal for DSI Virtual Channels.
Jani Nikula (1):
OMAP: DSS2: Fix def_disp module param description
Janorkar, Mayuresh (2):
OMAPFB: Adding a check for timings in set_def_mode
OMAP: OMAPFB: Adding help for FB_OMAP_LCD_VGA option
Jarkko Nikula (1):
omapfb: Fix linker error in drivers/video/omap/lcd_2430sdp.c
K, Mythri P (1):
OMAP4: HDMI: Add HDMI structure in the board file for OMAP4 PANDA
Mayuresh Janorkar (2):
OMAP2PLUS: DSS2: Add OMAP4 Kconfig support
OMAP4: DSS2: Add hwmod device names for OMAP4.
Murthy, Raghuveer (5):
OMAP: DSS2: Adding dss_features for independent core clk divider
OMAP: DSS2: Renaming register macro DISPC_DIVISOR(ch)
OMAP4: DSS2: Using dss_features to set independent core clock divider
OMAP: DSS2: Implement OMAP4 DSS fclk support
OMAP4: PandaBoard: Adding DVI support
Mythri P K (9):
OMAP4: DSS2: Add display type HDMI to DSS2
OMAP4: DSS2: HDMI: Select between HDMI VENC clock source.
OMAP4: DSS2: HDMI: Dispc gamma enable set/reset function for TV.
OMAP4: DSS2: HDMI: HDMI driver header file addition
OMAP4: DSS2: HDMI: HDMI driver addition in the DSS
OMAP4: DSS2: HDMI: HDMI panel driver addition in the DSS
OMAP4: DSS2: HDMI: Add makefile and kconfig changes to enable HDMI in OMAP4
OMAP4: DSS: HDMI: Call to HDMI module init to register driver.
OMAP4: HDMI: Add HDMI structure in the board file for OMAP4 SDP
Samreen (1):
OMAP2/3/4: DSS2: Enable Display SubSystem as modules
Semwal, Sumit (2):
OMAP2PLUS:DSS2: add opt_clock_available in pdata
OMAP2PLUS:DSS2: Use opt_clock_available from pdata
Senthilvadivu Guruswamy (9):
OMAP2,3: DSS2: Build omap_device for each DSS HWIP
OMAP2, 3: DSS2: DSS: create platform_driver, move init, exit to driver
OMAP2, 3: DSS2: Move clocks from core driver to dss driver
OMAP2, 3: DSS2: RFBI: create platform_driver, move init, exit to driver
OMAP2, 3: DSS2: DISPC: create platform_driver, move init, exit to driver
OMAP2, 3: DSS2: VENC: create platform_driver, move init, exit to driver
OMAP2, 3: DSS2: DSI: create platform_driver, move init, exit to driver
OMAP2,3: DSS2: Use platform device to get baseaddr
OMAP2,3: DSS2: Get DSS IRQ from platform device
Steve Sakoman (5):
OMAP: DSS2: Add support for LG Philips LB035Q02 panel
OMAP: DSS2: Add DSS2 support for Overo
omap: overo: Add regulator for ads7846
OMAP: Add gpio-leds support for Overo
OMAP: Add gpio-keys support for Overo
Sumit Semwal (4):
OMAP2, 3: DSS2: remove forced clk-disable from omap_dss_remove
OMAP2,3: DSS2: replace printk with dev_dbg in init
OMAP2PLUS: clocks: Align DSS clock names and roles
OMAP4: DSS2: clocks: Add ick as dummy clock
Taneja, Archit (5):
OMAP2PLUS: DSS2: Cleanup clock source related code
OMAP4: DSS2: Clock source changes for OMAP4
OMAP2PLUS: DSS2: FEATURES: Fix usage of dss_reg_field and dss_clk_source_name
OMAP: DSS2: FEATURES: Functions to return min and max values of parameters
OMAP: DSS2: FEATURES: DSI PLL parameter cleanup
Tomi Valkeinen (25):
OMAP: 3430SDP: Remove unused vdda_dac supply
OMAP: DSS2: Delay regulator_get() calls
OMAP: DSS2: Support for Samsung LTE430WQ-F0C
MAINTAINERS: Update OMAP DSS maintainer
OMAP: DSS2: Clean up a switch-case
OMAP: DSS2: FEATURES: Remove SDI from 3630 displays
OMAP: DSS2: FEATURES: Remove DSI & SDI from OMAP2
OMAP: DSS2: Check for SDI HW before accessing SDI registers
OMAP: DSS2: Remove unused list
OMAP: DSS2: DSI: remove unused function
OMAP: DSS2: Remove FB_OMAP_BOOTLOADER_INIT support
OMAP: DSS2: Remove pdev argument from dpi_init
OMAP: DSS2: Move DPI & SDI init into DSS plat driver
OMAP: DSS2: Remove unneeded cpu_is_xxx checks
HACK: OMAP: DSS2: Fix OMAP2_DSS_USE_DSI_PLL
HACK: OMAP: DSS2: add delay after enabling clocks
OMAP: DSS2: fix omap_dispc_register_isr() fail path
HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to prevent crash
OMAP: DSS2: DSI: Restructure IRQ handler
OMAP: DSS2: DSI: Add ISR support
OMAP: DSS2: DSI: use ISR in send_bta_sync
OMAP: DSS2: DSI: use ISR for BTA in framedone
OMAP: DSS2: DSI: catch DSI errors in send_bta_sync
OMAP: DSS2: DSI: fix IRQ debug prints
OMAP: DSS2: Clean up for dpll4_m4_ck handling
archit taneja (1):
OMAP: DSS2: Have separate irq handlers for DISPC and DSI
MAINTAINERS | 4 +-
arch/arm/configs/omap2plus_defconfig | 11 +
arch/arm/mach-omap2/board-3430sdp.c | 6 +-
arch/arm/mach-omap2/board-4430sdp.c | 75 ++
arch/arm/mach-omap2/board-cm-t35.c | 2 +-
arch/arm/mach-omap2/board-devkit8000.c | 12 +-
arch/arm/mach-omap2/board-igep0020.c | 10 +-
arch/arm/mach-omap2/board-omap3beagle.c | 12 +-
arch/arm/mach-omap2/board-omap3evm.c | 12 +-
arch/arm/mach-omap2/board-omap3pandora.c | 3 +-
arch/arm/mach-omap2/board-omap3stalker.c | 12 +-
arch/arm/mach-omap2/board-omap4panda.c | 203 +++-
arch/arm/mach-omap2/board-overo.c | 357 +++++-
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
arch/arm/mach-omap2/board-zoom-peripherals.c | 12 +-
arch/arm/mach-omap2/clock2420_data.c | 8 +-
arch/arm/mach-omap2/clock2430_data.c | 8 +-
arch/arm/mach-omap2/clock3xxx_data.c | 14 +-
arch/arm/mach-omap2/clock44xx_data.c | 15 +-
arch/arm/mach-omap2/display.c | 80 ++
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 13 +-
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 12 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 23 +-
arch/arm/plat-omap/include/plat/display.h | 15 +-
drivers/video/omap/Kconfig | 7 +-
drivers/video/omap2/displays/Kconfig | 6 +
drivers/video/omap2/displays/Makefile | 1 +
drivers/video/omap2/displays/panel-generic-dpi.c | 25 +
.../omap2/displays/panel-lgphilips-lb035q02.c | 279 ++++
drivers/video/omap2/displays/panel-taal.c | 123 +-
drivers/video/omap2/dss/Kconfig | 14 +-
drivers/video/omap2/dss/Makefile | 2 +
drivers/video/omap2/dss/core.c | 480 +-------
drivers/video/omap2/dss/dispc.c | 335 ++++--
drivers/video/omap2/dss/display.c | 35 +-
drivers/video/omap2/dss/dpi.c | 45 +-
drivers/video/omap2/dss/dsi.c | 967 +++++++++++----
drivers/video/omap2/dss/dss.c | 763 +++++++++--
drivers/video/omap2/dss/dss.h | 153 ++-
drivers/video/omap2/dss/dss_features.c | 163 ++-
drivers/video/omap2/dss/dss_features.h | 27 +
drivers/video/omap2/dss/hdmi.c | 1332 ++++++++++++++++++++
drivers/video/omap2/dss/hdmi.h | 415 ++++++
drivers/video/omap2/dss/hdmi_omap4_panel.c | 222 ++++
drivers/video/omap2/dss/manager.c | 13 +-
drivers/video/omap2/dss/overlay.c | 10 +-
drivers/video/omap2/dss/rfbi.c | 128 ++-
drivers/video/omap2/dss/sdi.c | 62 +-
drivers/video/omap2/dss/venc.c | 128 ++-
drivers/video/omap2/omapfb/Kconfig | 6 +-
drivers/video/omap2/omapfb/omapfb-main.c | 23 +-
51 files changed, 5323 insertions(+), 1362 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
create mode 100644 drivers/video/omap2/dss/hdmi.c
create mode 100644 drivers/video/omap2/dss/hdmi.h
create mode 100644 drivers/video/omap2/dss/hdmi_omap4_panel.c
^ permalink raw reply
* Re: Regression: black screen with Radeon KMS in 2.6.38 (2.6.37.4
From: Dave Airlie @ 2011-03-21 5:58 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <4D86E4E6.3040403@tds.net>
On Mon, Mar 21, 2011 at 3:40 PM, John Lindgren <john.lindgren@tds.net> wrote:
> Hi,
>
> I want to report a bug in the Linux kernel 2.6.38. Loading the radeon
> module causes the console to go completely blank (laptop backlight on, but
> nothing displayed). The system still responds to ctrl-alt-del and reboots.
> This is a regression from the previous kernel, 2.6.37.4, where kernel mode
> setting works flawlessly.
>
> With radeon.modeset=0, or with the module blacklisted, the system boots
> fine, and I can use X, but without the powersaving features available
> through KMS.
Please post to dri-devel list, but my first guess is missing fbcon or
something like that.
can't tell without complete dmesg.
Alternative file a bug on kernel bugzilla, with the complete dmesg attached.
Dave.
^ permalink raw reply
* Re: Regression: black screen with Radeon KMS in 2.6.38 (2.6.37.4
From: Benjamin Herrenschmidt @ 2011-03-21 5:51 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <4D86E4E6.3040403@tds.net>
On Mon, 2011-03-21 at 01:40 -0400, John Lindgren wrote:
> Hi,
>
> I want to report a bug in the Linux kernel 2.6.38. Loading the radeon
> module causes the console to go completely blank (laptop backlight on,
> but nothing displayed). The system still responds to ctrl-alt-del and
> reboots. This is a regression from the previous kernel, 2.6.37.4, where
> kernel mode setting works flawlessly.
>
> With radeon.modeset=0, or with the module blacklisted, the system boots
> fine, and I can use X, but without the powersaving features available
> through KMS.
You should probably report that to the appropriate freedesktop mailing
lists & bugzilla. I am not directly involved in the dev. of KMS.
Cheers,
Ben.
> System: Toshiba Satellite A305-S6916
> Graphics: ATI Radeon Mobility HD 3650
> Kernel: 2.6.38 (x86_64)
>
> Kernel log when loading the module:
>
> Mar 21 00:57:38 localhost kernel: [drm] Initialized drm 1.1.0 20060810
> Mar 21 00:57:38 localhost kernel: [drm] radeon defaulting to kernel modesetting.
> Mar 21 00:57:38 localhost kernel: [drm] radeon kernel modesetting enabled.
> Mar 21 00:57:38 localhost kernel: radeon 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> Mar 21 00:57:38 localhost kernel: radeon 0000:01:00.0: setting latency timer to 64
> Mar 21 00:57:38 localhost kernel: [drm] initializing kernel modesetting (RV635 0x1002:0x9591).
> Mar 21 00:57:38 localhost kernel: [drm] register mmio base: 0xD6300000
> Mar 21 00:57:38 localhost kernel: [drm] register mmio size: 65536
> Mar 21 00:57:38 localhost kernel: ATOM BIOS: Tosh_IEC_Potomac_M86_DDR2
> Mar 21 00:57:38 localhost kernel: radeon 0000:01:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
> Mar 21 00:57:38 localhost kernel: radeon 0000:01:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
> Mar 21 00:57:38 localhost kernel: [drm] Detected VRAM RAMQ2M, BAR%6M
> Mar 21 00:57:38 localhost kernel: [drm] RAM width 128bits DDR
> Mar 21 00:57:38 localhost kernel: [TTM] Zone kernel: Available graphics memory: 2027544 kiB.
> Mar 21 00:57:38 localhost kernel: [TTM] Initializing pool allocator.
> Mar 21 00:57:38 localhost kernel: [drm] radeon: 512M of VRAM memory ready
> Mar 21 00:57:38 localhost kernel: [drm] radeon: 512M of GTT memory ready.
> Mar 21 00:57:38 localhost kernel: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> Mar 21 00:57:38 localhost kernel: [drm] Driver supports precise vblank timestamp query.
> Mar 21 00:57:38 localhost kernel: radeon 0000:01:00.0: irq 49 for MSI/MSI-X
> Mar 21 00:57:38 localhost kernel: radeon 0000:01:00.0: radeon: using MSI.
> Mar 21 00:57:38 localhost kernel: [drm] radeon: irq initialized.
> Mar 21 00:57:38 localhost kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072
> Mar 21 00:57:38 localhost kernel: [drm] Loading RV635 Microcode
> Mar 21 00:57:38 localhost kernel: radeon 0000:01:00.0: WB enabled
> Mar 21 00:57:38 localhost kernel: [drm] ring test succeeded in 1 usecs
> Mar 21 00:57:38 localhost kernel: [drm] radeon: ib pool ready.
> Mar 21 00:57:38 localhost kernel: [drm] ib test succeeded in 0 usecs
> Mar 21 00:57:38 localhost kernel: [drm] Enabling audio support
> Mar 21 00:57:38 localhost kernel: HDMI hot plug event: Pin=3 Presence_Detect=0 ELD_Valid=0
>
>
> If there is any more info I can provide, please ask.
>
> -- John Lindgren
^ permalink raw reply
* RE: [patch] fbdev: sh_mobile_lcdc: checking NULL instead of IS_ERR()
From: Janorkar, Mayuresh @ 2011-03-21 5:43 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110319043647.GZ2008@bicker>
> -----Original Message-----
> From: Dan Carpenter [mailto:error27@gmail.com]
> Sent: Monday, March 21, 2011 10:09 AM
> To: Janorkar, Mayuresh
> Cc: Guennadi Liakhovetski; Magnus Damm; linux-fbdev@vger.kernel.org;
> kernel-janitors@vger.kernel.org; Paul Mundt
> Subject: Re: [patch] fbdev: sh_mobile_lcdc: checking NULL instead of
> IS_ERR()
>
> On Mon, Mar 21, 2011 at 09:47:50AM +0530, Janorkar, Mayuresh wrote:
> > > backlight_device_register() returns an ERR_PTR. It doesn't return
> NULL.
> >
> > The patch is not applying on the master branch of fbdev tree.
> > I could find another branch: fbdev/shmobile on the tree.
> > It is a good idea to mention this in the description of the patch.
> >
>
> Sorry, I'm working against linux-next so I wasn't aware.
That's fine :). I saw fbdev in the subject line and To: Paul Mundt so thought this has been developed on fbdev master. But its good idea to mention the base of your patch.
>
> > >
> > > Signed-off-by: Dan Carpenter <error27@gmail.com>
> > >
> > > diff --git a/drivers/video/sh_mobile_lcdcfb.c
> > > b/drivers/video/sh_mobile_lcdcfb.c
> > > index bf2629f..a53abe1 100644
> > > --- a/drivers/video/sh_mobile_lcdcfb.c
> > > +++ b/drivers/video/sh_mobile_lcdcfb.c
> > > @@ -1088,7 +1088,7 @@ static struct backlight_device
> > > *sh_mobile_lcdc_bl_probe(struct device *parent,
> > >
> > > bl = backlight_device_register(ch->cfg.bl_info.name, parent, ch,
> > > &sh_mobile_lcdc_bl_ops, NULL);
> > > - if (!bl) {
> > > + if (IS_ERR(bl)) {
> > > dev_err(parent, "unable to register backlight device\n");
> >
> >
> > How about printing the error number here?
> >
>
> Ok. That's a good idea.
>
> > > return NULL;
> >
> > Code is not checking for return value where this function is called.
> >
> > A code snippet where this function is called:
> > /* probe the backlight is there is one defined */
> > if (ch->cfg.bl_info.max_brightness)
> > ch->bl = sh_mobile_lcdc_bl_probe(&pdev->dev, ch);
> >
> > If the return value is not checked then whats the use of return value?
> >
>
> It is checked actually. Look at the places which would dereference
> ->bl.
Yes, got it, it is checked it in start and stop.
>
> > > }
> > > --
> > > 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
* Regression: black screen with Radeon KMS in 2.6.38 (2.6.37.4 worked
From: John Lindgren @ 2011-03-21 5:40 UTC (permalink / raw)
To: linux-fbdev
Hi,
I want to report a bug in the Linux kernel 2.6.38. Loading the radeon
module causes the console to go completely blank (laptop backlight on,
but nothing displayed). The system still responds to ctrl-alt-del and
reboots. This is a regression from the previous kernel, 2.6.37.4, where
kernel mode setting works flawlessly.
With radeon.modeset=0, or with the module blacklisted, the system boots
fine, and I can use X, but without the powersaving features available
through KMS.
System: Toshiba Satellite A305-S6916
Graphics: ATI Radeon Mobility HD 3650
Kernel: 2.6.38 (x86_64)
Kernel log when loading the module:
Mar 21 00:57:38 localhost kernel: [drm] Initialized drm 1.1.0 20060810
Mar 21 00:57:38 localhost kernel: [drm] radeon defaulting to kernel modesetting.
Mar 21 00:57:38 localhost kernel: [drm] radeon kernel modesetting enabled.
Mar 21 00:57:38 localhost kernel: radeon 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Mar 21 00:57:38 localhost kernel: radeon 0000:01:00.0: setting latency timer to 64
Mar 21 00:57:38 localhost kernel: [drm] initializing kernel modesetting (RV635 0x1002:0x9591).
Mar 21 00:57:38 localhost kernel: [drm] register mmio base: 0xD6300000
Mar 21 00:57:38 localhost kernel: [drm] register mmio size: 65536
Mar 21 00:57:38 localhost kernel: ATOM BIOS: Tosh_IEC_Potomac_M86_DDR2
Mar 21 00:57:38 localhost kernel: radeon 0000:01:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
Mar 21 00:57:38 localhost kernel: radeon 0000:01:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
Mar 21 00:57:38 localhost kernel: [drm] Detected VRAM RAMQ2M, BAR%6M
Mar 21 00:57:38 localhost kernel: [drm] RAM width 128bits DDR
Mar 21 00:57:38 localhost kernel: [TTM] Zone kernel: Available graphics memory: 2027544 kiB.
Mar 21 00:57:38 localhost kernel: [TTM] Initializing pool allocator.
Mar 21 00:57:38 localhost kernel: [drm] radeon: 512M of VRAM memory ready
Mar 21 00:57:38 localhost kernel: [drm] radeon: 512M of GTT memory ready.
Mar 21 00:57:38 localhost kernel: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
Mar 21 00:57:38 localhost kernel: [drm] Driver supports precise vblank timestamp query.
Mar 21 00:57:38 localhost kernel: radeon 0000:01:00.0: irq 49 for MSI/MSI-X
Mar 21 00:57:38 localhost kernel: radeon 0000:01:00.0: radeon: using MSI.
Mar 21 00:57:38 localhost kernel: [drm] radeon: irq initialized.
Mar 21 00:57:38 localhost kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072
Mar 21 00:57:38 localhost kernel: [drm] Loading RV635 Microcode
Mar 21 00:57:38 localhost kernel: radeon 0000:01:00.0: WB enabled
Mar 21 00:57:38 localhost kernel: [drm] ring test succeeded in 1 usecs
Mar 21 00:57:38 localhost kernel: [drm] radeon: ib pool ready.
Mar 21 00:57:38 localhost kernel: [drm] ib test succeeded in 0 usecs
Mar 21 00:57:38 localhost kernel: [drm] Enabling audio support
Mar 21 00:57:38 localhost kernel: HDMI hot plug event: Pin=3 Presence_Detect=0 ELD_Valid=0
If there is any more info I can provide, please ask.
-- John Lindgren
^ permalink raw reply
* RE: [PATCH 15/20] video: msm: convert printk to pr_*
From: Janorkar, Mayuresh @ 2011-03-21 5:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1300485552-27519-1-git-send-email-carlv@codeaurora.org>
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of Carl Vanderlip
> Sent: Saturday, March 19, 2011 3:29 AM
> To: David Brown; Daniel Walker; Bryan Huntsman
> Cc: Brian Swetland; Dima Zavin; Rebecca Schultz Zavin; Colin Cross; linux-
> fbdev@vger.kernel.org; Carl Vanderlip; linux-arm-
> kernel@lists.infradead.org; linux-arm-msm@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [PATCH 15/20] video: msm: convert printk to pr_*
>
> Reword debugging messages to use pr_err and pr_warning
>
> Authors:
> Dima Zavin <dima@android.com>
> Rebecca Schultz Zavin <rebecca@android.com>
> Colin Cross <ccross@android.com>
>
> Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
> ---
> drivers/video/msm/mdp.c | 11 ++++-------
> 1 files changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
> index 8184ca9..b03204d 100644
> --- a/drivers/video/msm/mdp.c
> +++ b/drivers/video/msm/mdp.c
> @@ -42,16 +42,13 @@ DEFINE_MUTEX(mdp_mutex);
>
> static int locked_enable_mdp_irq(struct mdp_info *mdp, uint32_t mask)
> {
> - int ret = 0;
> -
> BUG_ON(!mask);
>
> /* if the mask bits are already set return an error, this interrupt
> * is already enabled */
> if (mdp_irq_mask & mask) {
> - printk(KERN_ERR "mdp irq already on already on %x %x\n",
> - mdp_irq_mask, mask);
> - ret = -1;
> + pr_err("mdp irq already on %x %x\n", mdp_irq_mask, mask);
> + return -1;
Please use standard error codes.
http://lxr.linux.no/#linux+v2.6.38/include/asm-generic/errno-base.h
The code would be more readable.
Plus it would help in debugging.
> }
> /* if the mdp irq is not already enabled enable it */
> if (!mdp_irq_mask) {
> @@ -172,9 +169,9 @@ static int mdp_wait(struct mdp_info *mdp, uint32_t
> mask, wait_queue_head_t *wq)
>
> spin_lock_irqsave(&mdp->lock, irq_flags);
> if (mdp_irq_mask & mask) {
> + pr_warning("%s: timeout waiting for mdp to complete 0x%x\n",
> + __func__, mask);
> locked_disable_mdp_irq(mdp, mask);
> - printk(KERN_WARNING "timeout waiting for mdp to complete
> %x\n",
> - mask);
> ret = -ETIMEDOUT;
> }
> spin_unlock_irqrestore(&mdp->lock, irq_flags);
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>
> --
> 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 13/20] video: msm: Debugging for send_blit
From: Janorkar, Mayuresh @ 2011-03-21 5:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1300485510-27439-1-git-send-email-carlv@codeaurora.org>
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of Carl Vanderlip
> Sent: Saturday, March 19, 2011 3:29 AM
> To: David Brown; Daniel Walker; Bryan Huntsman
> Cc: Brian Swetland; Dima Zavin; Rebecca Schultz Zavin; Colin Cross; linux-
> fbdev@vger.kernel.org; Carl Vanderlip; linux-arm-
> kernel@lists.infradead.org; linux-arm-msm@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [PATCH 13/20] video: msm: Debugging for send_blit
>
> Allows for mdp_writel_dbg to be redefined as needed to debug blits.
>
> Authors:
> Dima Zavin <dima@android.com>
> Rebecca Schultz Zavin <rebecca@android.com>
> Colin Cross <ccross@android.com>
>
> Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
> ---
> drivers/video/msm/mdp_hw.h | 2 +-
> drivers/video/msm/mdp_ppp.c | 61 ++++++++++++++++++++++----------------
> ----
> 2 files changed, 33 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/video/msm/mdp_hw.h b/drivers/video/msm/mdp_hw.h
> index acb48f5..fdf9e5e 100644
> --- a/drivers/video/msm/mdp_hw.h
> +++ b/drivers/video/msm/mdp_hw.h
> @@ -87,7 +87,7 @@ int mdp_ppp_blit(const struct mdp_info *mdp, struct
> mdp_blit_req *req,
> #define MDP_DISPLAY0_ADDR (0x00054)
> #define MDP_DISPLAY1_ADDR (0x00058)
> #define MDP_EBI2_PORTMAP_MODE (0x0005c)
> -#define MDP_MODE (0x00060)
> +#define MDP_PPP_CMD_MODE (0x00060)
> #define MDP_TV_OUT_STATUS (0x00064)
> #define MDP_HW_VERSION (0x00070)
> #define MDP_SW_RESET (0x00074)
> diff --git a/drivers/video/msm/mdp_ppp.c b/drivers/video/msm/mdp_ppp.c
> index 3d190b9..290c29a 100644
> --- a/drivers/video/msm/mdp_ppp.c
> +++ b/drivers/video/msm/mdp_ppp.c
> @@ -331,45 +331,48 @@ static void get_chroma_addr(struct mdp_img *img,
> struct mdp_rect *rect,
> }
> }
>
> +#define mdp_writel_dbg(mdp, val, reg) mdp_writel((mdp), (val), (reg))
> +
> static int send_blit(const struct mdp_info *mdp, struct mdp_blit_req
> *req,
> struct ppp_regs *regs, struct file *src_file,
> struct file *dst_file)
> {
> - mdp_writel(mdp, 1, 0x060);
> - mdp_writel(mdp, regs->src_rect, PPP_ADDR_SRC_ROI);
> - mdp_writel(mdp, regs->src0, PPP_ADDR_SRC0);
> - mdp_writel(mdp, regs->src1, PPP_ADDR_SRC1);
> - mdp_writel(mdp, regs->src_ystride, PPP_ADDR_SRC_YSTRIDE);
> - mdp_writel(mdp, regs->src_cfg, PPP_ADDR_SRC_CFG);
> - mdp_writel(mdp, regs->src_pack, PPP_ADDR_SRC_PACK_PATTERN);
> -
> - mdp_writel(mdp, regs->op, PPP_ADDR_OPERATION);
> - mdp_writel(mdp, regs->phasex_init, PPP_ADDR_PHASEX_INIT);
> - mdp_writel(mdp, regs->phasey_init, PPP_ADDR_PHASEY_INIT);
> - mdp_writel(mdp, regs->phasex_step, PPP_ADDR_PHASEX_STEP);
> - mdp_writel(mdp, regs->phasey_step, PPP_ADDR_PHASEY_STEP);
> -
> - mdp_writel(mdp, (req->alpha << 24) | (req->transp_mask & 0xffffff),
> +#if 0
> + mdp_writel_dbg(mdp, 1, MDP_PPP_CMD_MODE);
> +#endif
Unused code? You can add a comment explaining why is this not being used couurently.
> + mdp_writel_dbg(mdp, regs->src_rect, PPP_ADDR_SRC_ROI);
> + mdp_writel_dbg(mdp, regs->src0, PPP_ADDR_SRC0);
> + mdp_writel_dbg(mdp, regs->src1, PPP_ADDR_SRC1);
> + mdp_writel_dbg(mdp, regs->src_ystride, PPP_ADDR_SRC_YSTRIDE);
> + mdp_writel_dbg(mdp, regs->src_cfg, PPP_ADDR_SRC_CFG);
> + mdp_writel_dbg(mdp, regs->src_pack, PPP_ADDR_SRC_PACK_PATTERN);
> +
> + mdp_writel_dbg(mdp, regs->op, PPP_ADDR_OPERATION);
> + mdp_writel_dbg(mdp, regs->phasex_init, PPP_ADDR_PHASEX_INIT);
> + mdp_writel_dbg(mdp, regs->phasey_init, PPP_ADDR_PHASEY_INIT);
> + mdp_writel_dbg(mdp, regs->phasex_step, PPP_ADDR_PHASEX_STEP);
> + mdp_writel_dbg(mdp, regs->phasey_step, PPP_ADDR_PHASEY_STEP);
> +
> + mdp_writel_dbg(mdp, regs->edge, PPP_ADDR_EDGE);
> + mdp_writel_dbg(mdp, (req->alpha << 24) | (req->transp_mask &
> 0xffffff),
> PPP_ADDR_ALPHA_TRANSP);
>
> - mdp_writel(mdp, regs->dst_cfg, PPP_ADDR_DST_CFG);
> - mdp_writel(mdp, regs->dst_pack, PPP_ADDR_DST_PACK_PATTERN);
> - mdp_writel(mdp, regs->dst_rect, PPP_ADDR_DST_ROI);
> - mdp_writel(mdp, regs->dst0, PPP_ADDR_DST0);
> - mdp_writel(mdp, regs->dst1, PPP_ADDR_DST1);
> - mdp_writel(mdp, regs->dst_ystride, PPP_ADDR_DST_YSTRIDE);
> + mdp_writel_dbg(mdp, regs->dst_cfg, PPP_ADDR_DST_CFG);
> + mdp_writel_dbg(mdp, regs->dst_pack, PPP_ADDR_DST_PACK_PATTERN);
> + mdp_writel_dbg(mdp, regs->dst_rect, PPP_ADDR_DST_ROI);
> + mdp_writel_dbg(mdp, regs->dst0, PPP_ADDR_DST0);
> + mdp_writel_dbg(mdp, regs->dst1, PPP_ADDR_DST1);
> + mdp_writel_dbg(mdp, regs->dst_ystride, PPP_ADDR_DST_YSTRIDE);
>
> - mdp_writel(mdp, regs->edge, PPP_ADDR_EDGE);
> if (regs->op & PPP_OP_BLEND_ON) {
> - mdp_writel(mdp, regs->dst0, PPP_ADDR_BG0);
> - mdp_writel(mdp, regs->dst1, PPP_ADDR_BG1);
> - mdp_writel(mdp, regs->dst_ystride, PPP_ADDR_BG_YSTRIDE);
> - mdp_writel(mdp, src_img_cfg[req->dst.format],
> PPP_ADDR_BG_CFG);
> - mdp_writel(mdp, pack_pattern[req->dst.format],
> - PPP_ADDR_BG_PACK_PATTERN);
> + mdp_writel_dbg(mdp, regs->bg0, PPP_ADDR_BG0);
> + mdp_writel_dbg(mdp, regs->bg1, PPP_ADDR_BG1);
> + mdp_writel_dbg(mdp, regs->bg_ystride, PPP_ADDR_BG_YSTRIDE);
> + mdp_writel_dbg(mdp, regs->bg_cfg, PPP_ADDR_BG_CFG);
> + mdp_writel_dbg(mdp, regs->bg_pack, PPP_ADDR_BG_PACK_PATTERN);
> }
> flush_imgs(req, regs, src_file, dst_file);
> - mdp_writel(mdp, 0x1000, MDP_DISPLAY0_START);
> + mdp_writel_dbg(mdp, 0x1000, MDP_DISPLAY0_START);
> return 0;
> }
>
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>
> --
> 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 11/20] video: msm: Add MDP FB DMA configuration
From: Janorkar, Mayuresh @ 2011-03-21 5:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1300485470-27360-1-git-send-email-carlv@codeaurora.org>
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of Carl Vanderlip
> Sent: Saturday, March 19, 2011 3:28 AM
> To: Russell King; David Brown; Daniel Walker; Bryan Huntsman
> Cc: Brian Swetland; Dima Zavin; Rebecca Schultz Zavin; Colin Cross; linux-
> fbdev@vger.kernel.org; Carl Vanderlip; linux-arm-
> kernel@lists.infradead.org; linux-arm-msm@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [PATCH 11/20] video: msm: Add MDP FB DMA configuration
>
> Setup configure_dma, check_output_format and set_output_format functions.
>
> Authors:
> Dima Zavin <dima@android.com>
> Rebecca Schultz Zavin <rebecca@android.com>
> Colin Cross <ccross@android.com>
>
> Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
> ---
> arch/arm/mach-msm/include/mach/msm_fb.h | 3 ++
> drivers/video/msm/mdp.c | 61
> ++++++++++++++++++++++++++++++-
> drivers/video/msm/mdp_hw.h | 16 ++++++++
> drivers/video/msm/msm_fb.c | 5 ++-
> 4 files changed, 83 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-msm/include/mach/msm_fb.h b/arch/arm/mach-
> msm/include/mach/msm_fb.h
> index 2d0899c..238ea2a 100644
> --- a/arch/arm/mach-msm/include/mach/msm_fb.h
> +++ b/arch/arm/mach-msm/include/mach/msm_fb.h
> @@ -123,6 +123,9 @@ struct mdp_device {
> int (*blit)(struct mdp_device *mdp, struct fb_info *fb,
> struct mdp_blit_req *req);
> void (*set_grp_disp)(struct mdp_device *mdp, uint32_t disp_id);
> + void (*configure_dma)(struct mdp_device *mdp);
> + int (*check_output_format)(struct mdp_device *mdp, int bpp);
> + int (*set_output_format)(struct mdp_device *mdp, int bpp);
> };
>
> struct class_interface;
> diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
> index 95e19e5..15241b4 100644
> --- a/drivers/video/msm/mdp.c
> +++ b/drivers/video/msm/mdp.c
> @@ -223,7 +223,7 @@ static void mdp_dma_to_mddi(void *priv, uint32_t addr,
> uint32_t stride,
> DMA_OUT_SEL_AHB |
> DMA_IBUF_NONCONTIGUOUS;
>
> - dma2_cfg |= DMA_IBUF_FORMAT_RGB565;
> + dma2_cfg |= mdp->format;
>
> dma2_cfg |= DMA_OUT_SEL_MDDI;
>
> @@ -304,6 +304,62 @@ void put_img(struct file *src_file, struct file
> *dst_file)
> {
> }
>
> +void mdp_configure_dma(struct mdp_device *mdp_dev)
> +{
> + struct mdp_info *mdp = container_of(mdp_dev, struct mdp_info,
> mdp_dev);
> + uint32_t dma_cfg;
> +
> + if (!mdp->dma_config_dirty)
> + return;
> + dma_cfg = mdp_readl(mdp, MDP_DMA_P_CONFIG);
> + dma_cfg &= ~DMA_IBUF_FORMAT_MASK;
> + dma_cfg &= ~DMA_PACK_PATTERN_MASK;
> + dma_cfg |= (mdp->format | mdp->pack_pattern);
> + mdp_writel(mdp, dma_cfg, MDP_DMA_P_CONFIG);
> + mdp->dma_config_dirty = false;
> +
> + return;
> +}
> +
> +int mdp_check_output_format(struct mdp_device *mdp_dev, int bpp)
> +{
> + switch (bpp) {
> + case 16:
> + case 24:
> + case 32:
> + break;
Why break?
You can return with a value 0 from here.
> + default:
> + return -EINVAL;
> + }
> + return 0;
> +}
> +
> +int mdp_set_output_format(struct mdp_device *mdp_dev, int bpp)
> +{
> + struct mdp_info *mdp = container_of(mdp_dev, struct mdp_info,
> mdp_dev);
> + uint32_t format, pack_pattern;
> +
> + switch (bpp) {
> + case 16:
> + format = DMA_IBUF_FORMAT_RGB565;
> + pack_pattern = DMA_PACK_PATTERN_RGB;
> + break;
> + case 24:
> + case 32:
> + format = DMA_IBUF_FORMAT_RGB888_OR_ARGB8888;
> + break;
> + default:
> + return -EINVAL;
> + }
> + if (format != mdp->format || pack_pattern != mdp->pack_pattern) {
> + mdp->format = format;
> + mdp->pack_pattern = pack_pattern;
> + mdp->dma_config_dirty = true;
> + }
> +
> + return 0;
> +}
> +
> int mdp_blit_and_wait(struct mdp_info *mdp, struct mdp_blit_req *req,
> struct file *src_file, unsigned long src_start,
> unsigned long src_len, struct file *dst_file,
> @@ -540,6 +596,9 @@ int mdp_probe(struct platform_device *pdev)
> mdp->mdp_dev.dma_wait = mdp_dma_wait;
> mdp->mdp_dev.blit = mdp_blit;
> mdp->mdp_dev.set_grp_disp = mdp_set_grp_disp;
> + mdp->mdp_dev.set_output_format = mdp_set_output_format;
> + mdp->mdp_dev.check_output_format = mdp_check_output_format;
> + mdp->mdp_dev.configure_dma = mdp_configure_dma;
>
> ret = mdp_out_if_register(&mdp->mdp_dev, MSM_MDDI_PMDH_INTERFACE,
> mdp,
> MDP_DMA_P_DONE, mdp_dma_to_mddi);
> diff --git a/drivers/video/msm/mdp_hw.h b/drivers/video/msm/mdp_hw.h
> index 34a204e..cc48218 100644
> --- a/drivers/video/msm/mdp_hw.h
> +++ b/drivers/video/msm/mdp_hw.h
> @@ -42,6 +42,9 @@ struct mdp_info {
> int irq;
> struct clk *clk;
> struct mdp_out_interface out_if[MSM_MDP_NUM_INTERFACES];
> + int format;
> + int pack_pattern;
> + bool dma_config_dirty;
> };
>
> extern int mdp_out_if_register(struct mdp_device *mdp_dev, int interface,
> @@ -183,6 +186,15 @@ int mdp_ppp_blit(const struct mdp_info *mdp, struct
> mdp_blit_req *req,
> #define MDP_TEST_CAPTURED_DCLK (0xd0210)
> #define MDP_TEST_MISR_CAPT_VAL_DCLK (0xd0214)
> #define MDP_LCDC_CTL (0xe0000)
> +
> +#define MDP_DMA_P_START (0x00044)
> +#define MDP_DMA_P_CONFIG (0x90000)
> +#define MDP_DMA_P_SIZE (0x90004)
> +#define MDP_DMA_P_IBUF_ADDR (0x90008)
> +#define MDP_DMA_P_IBUF_Y_STRIDE (0x9000c)
> +#define MDP_DMA_P_OUT_XY (0x90010)
> +#define MDP_DMA_P_COLOR_CORRECT_CONFIG (0x90070)
> +
> #define MDP_LCDC_HSYNC_CTL (0xe0004)
> #define MDP_LCDC_VSYNC_CTL (0xe0008)
> #define MDP_LCDC_ACTIVE_HCTL (0xe000c)
> @@ -629,8 +641,11 @@ int mdp_ppp_blit(const struct mdp_info *mdp, struct
> mdp_blit_req *req,
> #define DMA_PACK_LOOSE 0
> #define DMA_PACK_ALIGN_LSB 0
> #define DMA_PACK_ALIGN_MSB (1<<7)
> +#define DMA_PACK_PATTERN_MASK (0x3f<<8)
> #define DMA_PACK_PATTERN_RGB \
> (MDP_GET_PACK_PATTERN(0, CLR_R, CLR_G, CLR_B, 2)<<8)
> +#define DMA_PACK_PATTERN_BGR \
> + (MDP_GET_PACK_PATTERN(0, CLR_B, CLR_G, CLR_R, 2)<<8)
>
> #define DMA_OUT_SEL_AHB 0
> #define DMA_OUT_SEL_MDDI (1<<14)
> @@ -645,6 +660,7 @@ int mdp_ppp_blit(const struct mdp_info *mdp, struct
> mdp_blit_req *req,
>
> #define DMA_IBUF_FORMAT_RGB565 (1<<20)
> #define DMA_IBUF_FORMAT_RGB888_OR_ARGB8888 0
> +#define DMA_IBUF_FORMAT_MASK (1 << 20)
>
> #define DMA_IBUF_NONCONTIGUOUS (1<<21)
>
> diff --git a/drivers/video/msm/msm_fb.c b/drivers/video/msm/msm_fb.c
> index 6af8b41..ccd7417 100644
> --- a/drivers/video/msm/msm_fb.c
> +++ b/drivers/video/msm/msm_fb.c
> @@ -332,7 +332,7 @@ static int msmfb_check_var(struct fb_var_screeninfo
> *var, struct fb_info *info)
> if ((var->xres != info->var.xres) ||
> (var->yres != info->var.yres) ||
> (var->xoffset != info->var.xoffset) ||
> - (var->bits_per_pixel != info->var.bits_per_pixel) ||
> + (mdp->check_output_format(mdp, var->bits_per_pixel)) ||
> (var->grayscale != info->var.grayscale))
> return -EINVAL;
>
> @@ -365,6 +365,7 @@ static int msmfb_set_par(struct fb_info *info)
> var->blue.length = 5;
> } else
> return -1;
> + mdp->set_output_format(mdp, var->bits_per_pixel);
> fix->line_length = var->xres * var->bits_per_pixel / 8;
>
> return 0;
> @@ -519,6 +520,8 @@ static void setup_fb_info(struct msmfb_info *msmfb)
> fb_info->var.blue.length = 5;
> fb_info->var.blue.msb_right = 0;
>
> + mdp->set_output_format(mdp, fb_info->var.bits_per_pixel);
> +
> r = fb_alloc_cmap(&fb_info->cmap, 16, 0);
> fb_info->pseudo_palette = PP;
>
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>
> --
> 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 08/20] video: msm: Refactor mdp_regs
From: Janorkar, Mayuresh @ 2011-03-21 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1300485404-27241-1-git-send-email-carlv@codeaurora.org>
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of Carl Vanderlip
> Sent: Saturday, March 19, 2011 3:27 AM
> To: David Brown; Daniel Walker; Bryan Huntsman
> Cc: Brian Swetland; Dima Zavin; Rebecca Schultz Zavin; Colin Cross; linux-
> fbdev@vger.kernel.org; Carl Vanderlip; linux-arm-
> kernel@lists.infradead.org; linux-arm-msm@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [PATCH 08/20] video: msm: Refactor mdp_regs
>
> To begin splitting hw specific PPP operations into different files,
> the mdp_regs struct will be moved into a new generic header file
> for PPP operations.
>
> Authors:
> Dima Zavin <dima@android.com>
> Rebecca Schultz Zavin <rebecca@android.com>
> Colin Cross <ccross@android.com>
>
> Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
> ---
> drivers/video/msm/mdp_ppp.c | 49 +++++++++++++-------------------------
> ----
> drivers/video/msm/mdp_ppp.h | 50
> +++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 65 insertions(+), 34 deletions(-)
> create mode 100644 drivers/video/msm/mdp_ppp.h
>
> diff --git a/drivers/video/msm/mdp_ppp.c b/drivers/video/msm/mdp_ppp.c
> index 2b04027..05f3e33 100644
> --- a/drivers/video/msm/mdp_ppp.c
> +++ b/drivers/video/msm/mdp_ppp.c
> @@ -19,6 +19,7 @@
> #include <mach/msm_fb.h>
>
> #include "mdp_hw.h"
> +#include "mdp_ppp.h"
> #include "mdp_scale_tables.h"
>
> #define DLOG(x...) do {} while (0)
> @@ -27,28 +28,6 @@
> static int downscale_y_table = MDP_DOWNSCALE_MAX;
> static int downscale_x_table = MDP_DOWNSCALE_MAX;
>
> -struct mdp_regs {
> - uint32_t src0;
> - uint32_t src1;
> - uint32_t dst0;
> - uint32_t dst1;
> - uint32_t src_cfg;
> - uint32_t dst_cfg;
> - uint32_t src_pack;
> - uint32_t dst_pack;
> - uint32_t src_rect;
> - uint32_t dst_rect;
> - uint32_t src_ystride;
> - uint32_t dst_ystride;
> - uint32_t op;
> - uint32_t src_bpp;
> - uint32_t dst_bpp;
> - uint32_t edge;
> - uint32_t phasex_init;
> - uint32_t phasey_init;
> - uint32_t phasex_step;
> - uint32_t phasey_step;
> -};
>
> static uint32_t pack_pattern[] = {
> PPP_ARRAY0(PACK_PATTERN)
> @@ -88,7 +67,8 @@ static uint32_t bg_op_chroma[] = {
> PPP_ARRAY1(CHROMA_SAMP, BG)
> };
>
> -static void rotate_dst_addr_x(struct mdp_blit_req *req, struct mdp_regs
> *regs)
> +static void rotate_dst_addr_x(struct mdp_blit_req *req,
> + struct ppp_regs *regs)
> {
> regs->dst0 += (req->dst_rect.w -
> min((uint32_t)16, req->dst_rect.w)) * regs->dst_bpp;
> @@ -96,7 +76,8 @@ static void rotate_dst_addr_x(struct mdp_blit_req *req,
> struct mdp_regs *regs)
> min((uint32_t)16, req->dst_rect.w)) * regs->dst_bpp;
> }
>
> -static void rotate_dst_addr_y(struct mdp_blit_req *req, struct mdp_regs
> *regs)
> +static void rotate_dst_addr_y(struct mdp_blit_req *req,
> + struct ppp_regs *regs)
> {
> regs->dst0 += (req->dst_rect.h -
> min((uint32_t)16, req->dst_rect.h)) *
> @@ -107,7 +88,7 @@ static void rotate_dst_addr_y(struct mdp_blit_req *req,
> struct mdp_regs *regs)
> }
>
> static void blit_rotate(struct mdp_blit_req *req,
> - struct mdp_regs *regs)
> + struct ppp_regs *regs)
> {
> if (req->flags = MDP_ROT_NOP)
> return;
> @@ -126,7 +107,7 @@ static void blit_rotate(struct mdp_blit_req *req,
> regs->op |= PPP_OP_FLIP_LR;
> }
>
> -static void blit_convert(struct mdp_blit_req *req, struct mdp_regs *regs)
> +static void blit_convert(struct mdp_blit_req *req, struct ppp_regs *regs)
> {
> if (req->src.format = req->dst.format)
> return;
> @@ -165,7 +146,7 @@ static uint32_t transp_convert(struct mdp_blit_req
> *req)
> }
> #undef GET_BIT_RANGE
>
> -static void blit_blend(struct mdp_blit_req *req, struct mdp_regs *regs)
> +static void blit_blend(struct mdp_blit_req *req, struct ppp_regs *regs)
> {
> /* TRANSP BLEND */
> if (req->transp_mask != MDP_TRANSP_NOP) {
> @@ -332,7 +313,7 @@ static void get_edge_info(uint32_t src, uint32_t
> src_coord, uint32_t dst,
> *interp2 += src_coord;
> }
>
> -static int get_edge_cond(struct mdp_blit_req *req, struct mdp_regs *regs)
> +static int get_edge_cond(struct mdp_blit_req *req, struct ppp_regs *regs)
> {
> int32_t luma_interp[4];
> int32_t luma_repeat[4];
> @@ -432,7 +413,7 @@ static int get_edge_cond(struct mdp_blit_req *req,
> struct mdp_regs *regs)
> }
>
> static int blit_scale(const struct mdp_info *mdp, struct mdp_blit_req
> *req,
> - struct mdp_regs *regs)
> + struct ppp_regs *regs)
> {
> uint32_t phase_init_x, phase_init_y, phase_step_x, phase_step_y;
> uint32_t scale_factor_x, scale_factor_y;
> @@ -500,7 +481,7 @@ static int blit_scale(const struct mdp_info *mdp,
> struct mdp_blit_req *req,
> }
>
> static void blit_blur(const struct mdp_info *mdp, struct mdp_blit_req
> *req,
> - struct mdp_regs *regs)
> + struct ppp_regs *regs)
> {
> if (!(req->flags & MDP_BLUR))
> return;
> @@ -534,7 +515,7 @@ static void get_len(struct mdp_img *img, struct
> mdp_rect *rect, uint32_t bpp,
>
> static int valid_src_dst(unsigned long src_start, unsigned long src_len,
> unsigned long dst_start, unsigned long dst_len,
> - struct mdp_blit_req *req, struct mdp_regs *regs)
> + struct mdp_blit_req *req, struct ppp_regs *regs)
> {
> unsigned long src_min_ok = src_start;
> unsigned long src_max_ok = src_start + src_len;
> @@ -575,7 +556,7 @@ static int valid_src_dst(unsigned long src_start,
> unsigned long src_len,
> }
>
>
> -static void flush_imgs(struct mdp_blit_req *req, struct mdp_regs *regs,
> +static void flush_imgs(struct mdp_blit_req *req, struct ppp_regs *regs,
> struct file *src_file, struct file *dst_file)
> {
> }
> @@ -601,7 +582,7 @@ static void get_chroma_addr(struct mdp_img *img,
> struct mdp_rect *rect,
> }
>
> static int send_blit(const struct mdp_info *mdp, struct mdp_blit_req
> *req,
> - struct mdp_regs *regs, struct file *src_file,
> + struct ppp_regs *regs, struct file *src_file,
> struct file *dst_file)
> {
> mdp_writel(mdp, 1, 0x060);
> @@ -646,7 +627,7 @@ int mdp_ppp_blit(const struct mdp_info *mdp, struct
> mdp_blit_req *req,
> struct file *src_file, unsigned long src_start, unsigned long
> src_len,
> struct file *dst_file, unsigned long dst_start, unsigned long
> dst_len)
> {
> - struct mdp_regs regs = {0};
> + struct ppp_regs regs = {0};
>
> if (unlikely(req->src.format >= MDP_IMGTYPE_LIMIT ||
> req->dst.format >= MDP_IMGTYPE_LIMIT)) {
> diff --git a/drivers/video/msm/mdp_ppp.h b/drivers/video/msm/mdp_ppp.h
> new file mode 100644
> index 0000000..ef3b125
> --- /dev/null
> +++ b/drivers/video/msm/mdp_ppp.h
> @@ -0,0 +1,50 @@
> +/* drivers/video/msm/mdp_ppp.h
> + *
> + * Copyright (C) 2009 Google Incorporated
If you want correct copyright info (to 2009-2011) here.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef _VIDEO_MSM_MDP_PPP_H_
> +#define _VIDEO_MSM_MDP_PPP_H_
> +
> +#include <linux/types.h>
> +
> +struct ppp_regs {
> + uint32_t src0;
> + uint32_t src1;
> + uint32_t dst0;
> + uint32_t dst1;
> + uint32_t src_cfg;
> + uint32_t dst_cfg;
> + uint32_t src_pack;
> + uint32_t dst_pack;
> + uint32_t src_rect;
> + uint32_t dst_rect;
> + uint32_t src_ystride;
> + uint32_t dst_ystride;
> + uint32_t op;
> + uint32_t src_bpp;
> + uint32_t dst_bpp;
> + uint32_t edge;
> + uint32_t phasex_init;
> + uint32_t phasey_init;
> + uint32_t phasex_step;
> + uint32_t phasey_step;
> +
> + uint32_t bg0;
> + uint32_t bg1;
> + uint32_t bg_cfg;
> + uint32_t bg_bpp;
> + uint32_t bg_pack;
> + uint32_t bg_ystride;
> +};
> +
> +#endif /* _VIDEO_MSM_MDP_PPP_H_ */
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>
> --
> 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 09/20] video: msm: Split out MDP2.2 HW specific code.
From: Janorkar, Mayuresh @ 2011-03-21 5:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1300485423-27281-1-git-send-email-carlv@codeaurora.org>
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of Carl Vanderlip
> Sent: Saturday, March 19, 2011 3:27 AM
> To: Russell King; David Brown; Daniel Walker; Bryan Huntsman
> Cc: Brian Swetland; Dima Zavin; Rebecca Schultz Zavin; Colin Cross; linux-
> fbdev@vger.kernel.org; Carl Vanderlip; linux-arm-
> kernel@lists.infradead.org; linux-arm-msm@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [PATCH 09/20] video: msm: Split out MDP2.2 HW specific code.
>
> Moving MDP2.2 HW specific code allows for reuse of PPP code
> when adding other MDP HW versions. Splitting also begins
> simplification of mdp_probe function.
>
> Authors:
> Dima Zavin <dima@android.com>
> Rebecca Schultz Zavin <rebecca@android.com>
> Colin Cross <ccross@android.com>
>
> Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
> ---
> arch/arm/mach-msm/Kconfig | 5 +
> drivers/video/msm/Makefile | 4 +-
> drivers/video/msm/mdp.c | 14 +-
> drivers/video/msm/mdp_ppp.c | 358 ++++-----------
> -----
> drivers/video/msm/mdp_ppp.h | 12 +
> .../video/msm/{mdp_scale_tables.c => mdp_ppp22.c} | 333
> ++++++++++++++++++-
> drivers/video/msm/mdp_scale_tables.h | 38 --
> 7 files changed, 417 insertions(+), 347 deletions(-)
> rename drivers/video/msm/{mdp_scale_tables.c => mdp_ppp22.c} (69%)
> delete mode 100644 drivers/video/msm/mdp_scale_tables.h
>
> diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
> index df9d74e..d6e75c3 100644
> --- a/arch/arm/mach-msm/Kconfig
> +++ b/arch/arm/mach-msm/Kconfig
> @@ -76,6 +76,11 @@ config HAS_MSM_DEBUG_UART_PHYS
> config MSM_VIC
> bool
>
> +config MSM_MDP22
> + bool
> + depends on ARCH_MSM7X00A
> + default y
Please add some help here.
> +
> menu "Qualcomm MSM Board Type"
>
> config MACH_HALIBUT
> diff --git a/drivers/video/msm/Makefile b/drivers/video/msm/Makefile
> index 802d6ae..0666aef 100644
> --- a/drivers/video/msm/Makefile
> +++ b/drivers/video/msm/Makefile
> @@ -5,7 +5,9 @@ obj-y := msm_fb.o
>
> # MDP DMA/PPP engine
> #
> -obj-y += mdp.o mdp_scale_tables.o mdp_ppp.o
> +obj-y += mdp.o mdp_ppp.o
> +
> +obj-$(CONFIG_MSM_MDP22) += mdp_ppp22.o
>
> # MDDI interface
> #
> diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
> index 765df06..6aa9ed5 100644
> --- a/drivers/video/msm/mdp.c
> +++ b/drivers/video/msm/mdp.c
> @@ -30,6 +30,7 @@
> #include <linux/platform_device.h>
>
> #include "mdp_hw.h"
> +#include "mdp_ppp.h"
>
> struct class *mdp_class;
>
> @@ -453,7 +454,13 @@ int register_mdp_client(struct class_interface *cint)
> }
>
> #include "mdp_csc_table.h"
> -#include "mdp_scale_tables.h"
> +
> +void mdp_hw_init(struct mdp_info *mdp)
> +{
> +#ifdef CONFIG_MSM_MDP22
> + mdp_ppp_init_scale(mdp);
> +#endif
> +}
>
> int mdp_probe(struct platform_device *pdev)
> {
> @@ -551,15 +558,12 @@ int mdp_probe(struct platform_device *pdev)
> mdp_writel(mdp, 0, MDP_CMD_DEBUG_ACCESS_BASE + 0x01e0);
> mdp_writel(mdp, 0, MDP_CMD_DEBUG_ACCESS_BASE + 0x01e4);
>
> - for (n = 0; n < ARRAY_SIZE(mdp_upscale_table); n++)
> - mdp_writel(mdp, mdp_upscale_table[n].val,
> - mdp_upscale_table[n].reg);
> -
> for (n = 0; n < 9; n++)
> mdp_writel(mdp, mdp_default_ccs[n], 0x40440 + 4 * n);
> mdp_writel(mdp, mdp_default_ccs[9], 0x40500 + 4 * 0);
> mdp_writel(mdp, mdp_default_ccs[10], 0x40500 + 4 * 0);
> mdp_writel(mdp, mdp_default_ccs[11], 0x40500 + 4 * 0);
> + mdp_hw_init(mdp);
>
> /* register mdp device */
> mdp->mdp_dev.dev.parent = &pdev->dev;
> diff --git a/drivers/video/msm/mdp_ppp.c b/drivers/video/msm/mdp_ppp.c
> index 05f3e33..3d190b9 100644
> --- a/drivers/video/msm/mdp_ppp.c
> +++ b/drivers/video/msm/mdp_ppp.c
> @@ -20,14 +20,14 @@
>
> #include "mdp_hw.h"
> #include "mdp_ppp.h"
> -#include "mdp_scale_tables.h"
>
> #define DLOG(x...) do {} while (0)
>
> -#define MDP_DOWNSCALE_BLUR (MDP_DOWNSCALE_MAX + 1)
> -static int downscale_y_table = MDP_DOWNSCALE_MAX;
> -static int downscale_x_table = MDP_DOWNSCALE_MAX;
> +#define IMG_LEN(rect_h, w, rect_w, bpp) (((rect_h) * w) * bpp)
>
> +#define Y_TO_CRCB_RATIO(format) \
> + ((format = MDP_Y_CBCR_H2V2 || format = MDP_Y_CRCB_H2V2) ? 2 :\
> + (format = MDP_Y_CBCR_H2V1 || format = MDP_Y_CRCB_H2V1) ? 1 : 1)
>
> static uint32_t pack_pattern[] = {
> PPP_ARRAY0(PACK_PATTERN)
> @@ -67,6 +67,19 @@ static uint32_t bg_op_chroma[] = {
> PPP_ARRAY1(CHROMA_SAMP, BG)
> };
>
> +static void set_src_region(struct mdp_img *img, struct mdp_rect *rect,
> + struct ppp_regs *regs)
> +{
> + regs->src_rect = (rect->h << 16) | (rect->w & 0x1fff);
> +
[cosmetic comment]: unnecessary extra line?
> +}
> +
> +static inline void set_dst_region(struct mdp_rect *rect, struct ppp_regs
> *regs)
> +{
> + regs->dst_rect = (rect->h << 16) | (rect->w & 0xfff);
> +
[cosmetic comment]: unnecessary extra line?
> +}
> +
> static void rotate_dst_addr_x(struct mdp_blit_req *req,
> struct ppp_regs *regs)
> {
> @@ -181,254 +194,30 @@ static void blit_blend(struct mdp_blit_req *req,
> struct ppp_regs *regs)
> }
>
> regs->op |= bg_op_chroma[req->dst.format];
> -}
> -
> -#define ONE_HALF (1LL << 32)
> -#define ONE (1LL << 33)
> -#define TWO (2LL << 33)
> -#define THREE (3LL << 33)
> -#define FRAC_MASK (ONE - 1)
> -#define INT_MASK (~FRAC_MASK)
> -
> -static int scale_params(uint32_t dim_in, uint32_t dim_out, uint32_t
> origin,
> - uint32_t *phase_init, uint32_t *phase_step)
> -{
> - /* to improve precicsion calculations are done in U31.33 and
> converted
> - * to U3.29 at the end */
> - int64_t k1, k2, k3, k4, tmp;
> - uint64_t n, d, os, os_p, od, od_p, oreq;
> - unsigned rpa = 0;
> - int64_t ip64, delta;
> -
> - if (dim_out % 3 = 0)
> - rpa = !(dim_in % (dim_out / 3));
> -
> - n = ((uint64_t)dim_out) << 34;
> - d = dim_in;
> - if (!d)
> - return -1;
> - do_div(n, d);
> - k3 = (n + 1) >> 1;
> - if ((k3 >> 4) < (1LL << 27) || (k3 >> 4) > (1LL << 31)) {
> - DLOG("crap bad scale\n");
> - return -1;
> - }
> - n = ((uint64_t)dim_in) << 34;
> - d = (uint64_t)dim_out;
> - if (!d)
> - return -1;
> - do_div(n, d);
> - k1 = (n + 1) >> 1;
> - k2 = (k1 - ONE) >> 1;
> -
> - *phase_init = (int)(k2 >> 4);
> - k4 = (k3 - ONE) >> 1;
> -
> - if (rpa) {
> - os = ((uint64_t)origin << 33) - ONE_HALF;
> - tmp = (dim_out * os) + ONE_HALF;
> - if (!dim_in)
> - return -1;
> - do_div(tmp, dim_in);
> - od = tmp - ONE_HALF;
> - } else {
> - os = ((uint64_t)origin << 1) - 1;
> - od = (((k3 * os) >> 1) + k4);
> - }
> -
> - od_p = od & INT_MASK;
> - if (od_p != od)
> - od_p += ONE;
> -
> - if (rpa) {
> - tmp = (dim_in * od_p) + ONE_HALF;
> - if (!dim_in)
> - return -1;
> - do_div(tmp, dim_in);
> - os_p = tmp - ONE_HALF;
> - } else {
> - os_p = ((k1 * (od_p >> 33)) + k2);
> - }
> -
> - oreq = (os_p & INT_MASK) - ONE;
> -
> - ip64 = os_p - oreq;
> - delta = ((int64_t)(origin) << 33) - oreq;
> - ip64 -= delta;
> - /* limit to valid range before the left shift */
> - delta = (ip64 & (1LL << 63)) ? 4 : -4;
> - delta <<= 33;
> - while (abs((int)(ip64 >> 33)) > 4)
> - ip64 += delta;
> - *phase_init = (int)(ip64 >> 4);
> - *phase_step = (uint32_t)(k1 >> 4);
> - return 0;
> -}
> -
> -static void load_scale_table(const struct mdp_info *mdp,
> - struct mdp_table_entry *table, int len)
> -{
> - int i;
> - for (i = 0; i < len; i++)
> - mdp_writel(mdp, table[i].val, table[i].reg);
> -}
> -
> -enum {
> -IMG_LEFT,
> -IMG_RIGHT,
> -IMG_TOP,
> -IMG_BOTTOM,
> -};
> -
> -static void get_edge_info(uint32_t src, uint32_t src_coord, uint32_t dst,
> - uint32_t *interp1, uint32_t *interp2,
> - uint32_t *repeat1, uint32_t *repeat2) {
> - if (src > 3 * dst) {
> - *interp1 = 0;
> - *interp2 = src - 1;
> - *repeat1 = 0;
> - *repeat2 = 0;
> - } else if (src = 3 * dst) {
> - *interp1 = 0;
> - *interp2 = src;
> - *repeat1 = 0;
> - *repeat2 = 1;
> - } else if (src > dst && src < 3 * dst) {
> - *interp1 = -1;
> - *interp2 = src;
> - *repeat1 = 1;
> - *repeat2 = 1;
> - } else if (src = dst) {
> - *interp1 = -1;
> - *interp2 = src + 1;
> - *repeat1 = 1;
> - *repeat2 = 2;
> - } else {
> - *interp1 = -2;
> - *interp2 = src + 1;
> - *repeat1 = 2;
> - *repeat2 = 2;
> - }
> - *interp1 += src_coord;
> - *interp2 += src_coord;
> -}
> -
> -static int get_edge_cond(struct mdp_blit_req *req, struct ppp_regs *regs)
> -{
> - int32_t luma_interp[4];
> - int32_t luma_repeat[4];
> - int32_t chroma_interp[4];
> - int32_t chroma_bound[4];
> - int32_t chroma_repeat[4];
> - uint32_t dst_w, dst_h;
> -
> - memset(&luma_interp, 0, sizeof(int32_t) * 4);
> - memset(&luma_repeat, 0, sizeof(int32_t) * 4);
> - memset(&chroma_interp, 0, sizeof(int32_t) * 4);
> - memset(&chroma_bound, 0, sizeof(int32_t) * 4);
> - memset(&chroma_repeat, 0, sizeof(int32_t) * 4);
> - regs->edge = 0;
> -
> - if (req->flags & MDP_ROT_90) {
> - dst_w = req->dst_rect.h;
> - dst_h = req->dst_rect.w;
> - } else {
> - dst_w = req->dst_rect.w;
> - dst_h = req->dst_rect.h;
> - }
> -
> - if (regs->op & (PPP_OP_SCALE_Y_ON | PPP_OP_SCALE_X_ON)) {
> - get_edge_info(req->src_rect.h, req->src_rect.y, dst_h,
> - &luma_interp[IMG_TOP], &luma_interp[IMG_BOTTOM],
> - &luma_repeat[IMG_TOP], &luma_repeat[IMG_BOTTOM]);
> - get_edge_info(req->src_rect.w, req->src_rect.x, dst_w,
> - &luma_interp[IMG_LEFT], &luma_interp[IMG_RIGHT],
> - &luma_repeat[IMG_LEFT], &luma_repeat[IMG_RIGHT]);
> - } else {
> - luma_interp[IMG_LEFT] = req->src_rect.x;
> - luma_interp[IMG_RIGHT] = req->src_rect.x + req->src_rect.w -
> 1;
> - luma_interp[IMG_TOP] = req->src_rect.y;
> - luma_interp[IMG_BOTTOM] = req->src_rect.y + req->src_rect.h -
> 1;
> - luma_repeat[IMG_LEFT] = 0;
> - luma_repeat[IMG_TOP] = 0;
> - luma_repeat[IMG_RIGHT] = 0;
> - luma_repeat[IMG_BOTTOM] = 0;
> - }
> -
> - chroma_interp[IMG_LEFT] = luma_interp[IMG_LEFT];
> - chroma_interp[IMG_RIGHT] = luma_interp[IMG_RIGHT];
> - chroma_interp[IMG_TOP] = luma_interp[IMG_TOP];
> - chroma_interp[IMG_BOTTOM] = luma_interp[IMG_BOTTOM];
> -
> - chroma_bound[IMG_LEFT] = req->src_rect.x;
> - chroma_bound[IMG_RIGHT] = req->src_rect.x + req->src_rect.w - 1;
> - chroma_bound[IMG_TOP] = req->src_rect.y;
> - chroma_bound[IMG_BOTTOM] = req->src_rect.y + req->src_rect.h - 1;
> -
> - if (IS_YCRCB(req->src.format)) {
> - chroma_interp[IMG_LEFT] = chroma_interp[IMG_LEFT] >> 1;
> - chroma_interp[IMG_RIGHT] = (chroma_interp[IMG_RIGHT] + 1) >>
> 1;
> -
> - chroma_bound[IMG_LEFT] = chroma_bound[IMG_LEFT] >> 1;
> - chroma_bound[IMG_RIGHT] = chroma_bound[IMG_RIGHT] >> 1;
> - }
>
> - if (req->src.format = MDP_Y_CBCR_H2V2 ||
> - req->src.format = MDP_Y_CRCB_H2V2) {
> - chroma_interp[IMG_TOP] = (chroma_interp[IMG_TOP] - 1) >> 1;
> - chroma_interp[IMG_BOTTOM] = (chroma_interp[IMG_BOTTOM] + 1)
> - >> 1;
> - chroma_bound[IMG_TOP] = (chroma_bound[IMG_TOP] + 1) >> 1;
> - chroma_bound[IMG_BOTTOM] = chroma_bound[IMG_BOTTOM] >> 1;
> - }
> -
> - chroma_repeat[IMG_LEFT] = chroma_bound[IMG_LEFT] -
> - chroma_interp[IMG_LEFT];
> - chroma_repeat[IMG_RIGHT] = chroma_interp[IMG_RIGHT] -
> - chroma_bound[IMG_RIGHT];
> - chroma_repeat[IMG_TOP] = chroma_bound[IMG_TOP] -
> - chroma_interp[IMG_TOP];
> - chroma_repeat[IMG_BOTTOM] = chroma_interp[IMG_BOTTOM] -
> - chroma_bound[IMG_BOTTOM];
> -
> - if (chroma_repeat[IMG_LEFT] < 0 || chroma_repeat[IMG_LEFT] > 3 ||
> - chroma_repeat[IMG_RIGHT] < 0 || chroma_repeat[IMG_RIGHT] > 3 ||
> - chroma_repeat[IMG_TOP] < 0 || chroma_repeat[IMG_TOP] > 3 ||
> - chroma_repeat[IMG_BOTTOM] < 0 || chroma_repeat[IMG_BOTTOM] > 3
> ||
> - luma_repeat[IMG_LEFT] < 0 || luma_repeat[IMG_LEFT] > 3 ||
> - luma_repeat[IMG_RIGHT] < 0 || luma_repeat[IMG_RIGHT] > 3 ||
> - luma_repeat[IMG_TOP] < 0 || luma_repeat[IMG_TOP] > 3 ||
> - luma_repeat[IMG_BOTTOM] < 0 || luma_repeat[IMG_BOTTOM] > 3)
> - return -1;
> -
> - regs->edge |= (chroma_repeat[IMG_LEFT] & 3) << MDP_LEFT_CHROMA;
> - regs->edge |= (chroma_repeat[IMG_RIGHT] & 3) << MDP_RIGHT_CHROMA;
> - regs->edge |= (chroma_repeat[IMG_TOP] & 3) << MDP_TOP_CHROMA;
> - regs->edge |= (chroma_repeat[IMG_BOTTOM] & 3) << MDP_BOTTOM_CHROMA;
> - regs->edge |= (luma_repeat[IMG_LEFT] & 3) << MDP_LEFT_LUMA;
> - regs->edge |= (luma_repeat[IMG_RIGHT] & 3) << MDP_RIGHT_LUMA;
> - regs->edge |= (luma_repeat[IMG_TOP] & 3) << MDP_TOP_LUMA;
> - regs->edge |= (luma_repeat[IMG_BOTTOM] & 3) << MDP_BOTTOM_LUMA;
> - return 0;
> + /* since we always blend src + dst -> dst, copy most of the
> + * configuration from dest to bg */
> + regs->bg0 = regs->dst0;
> + regs->bg1 = regs->dst1;
> + regs->bg_cfg = src_img_cfg[req->dst.format];
> + regs->bg_bpp = regs->dst_bpp;
> + regs->bg_pack = pack_pattern[req->dst.format];
> + regs->bg_ystride = regs->dst_ystride;
> }
>
> static int blit_scale(const struct mdp_info *mdp, struct mdp_blit_req
> *req,
> struct ppp_regs *regs)
> {
> - uint32_t phase_init_x, phase_init_y, phase_step_x, phase_step_y;
> - uint32_t scale_factor_x, scale_factor_y;
> - uint32_t downscale;
> - uint32_t dst_w, dst_h;
> + struct mdp_rect dst_rect;
>
> + memcpy(&dst_rect, &req->dst_rect, sizeof(dst_rect));
> if (req->flags & MDP_ROT_90) {
> - dst_w = req->dst_rect.h;
> - dst_h = req->dst_rect.w;
> - } else {
> - dst_w = req->dst_rect.w;
> - dst_h = req->dst_rect.h;
> + dst_rect.w = req->dst_rect.h;
> + dst_rect.h = req->dst_rect.w;
> }
> - if ((req->src_rect.w = dst_w) && (req->src_rect.h = dst_h) &&
> - !(req->flags & MDP_BLUR)) {
> +
> + if ((req->src_rect.w = dst_rect.w) && (req->src_rect.h =
> dst_rect.h)
> + && !(req->flags & MDP_BLUR)) {
> regs->phasex_init = 0;
> regs->phasey_init = 0;
> regs->phasex_step = 0;
> @@ -436,73 +225,35 @@ static int blit_scale(const struct mdp_info *mdp,
> struct mdp_blit_req *req,
> return 0;
> }
>
> - if (scale_params(req->src_rect.w, dst_w, 1, &phase_init_x,
> - &phase_step_x) ||
> - scale_params(req->src_rect.h, dst_h, 1, &phase_init_y,
> - &phase_step_y))
> +#ifdef CONFIG_MSM_MDP22
> + if (mdp_ppp_cfg_scale(mdp, regs, &req->src_rect, &dst_rect,
> + req->src.format, req->dst.format)) {
> + DLOG("crap, bad scale\n");
> return -1;
> -
> - scale_factor_x = (dst_w * 10) / req->src_rect.w;
> - scale_factor_y = (dst_h * 10) / req->src_rect.h;
> -
> - if (scale_factor_x > 8)
> - downscale = MDP_DOWNSCALE_PT8TO1;
> - else if (scale_factor_x > 6)
> - downscale = MDP_DOWNSCALE_PT6TOPT8;
> - else if (scale_factor_x > 4)
> - downscale = MDP_DOWNSCALE_PT4TOPT6;
> - else
> - downscale = MDP_DOWNSCALE_PT2TOPT4;
> - if (downscale != downscale_x_table) {
> - load_scale_table(mdp, mdp_downscale_x_table[downscale], 64);
> - downscale_x_table = downscale;
> }
> +#endif
>
> - if (scale_factor_y > 8)
> - downscale = MDP_DOWNSCALE_PT8TO1;
> - else if (scale_factor_y > 6)
> - downscale = MDP_DOWNSCALE_PT6TOPT8;
> - else if (scale_factor_y > 4)
> - downscale = MDP_DOWNSCALE_PT4TOPT6;
> - else
> - downscale = MDP_DOWNSCALE_PT2TOPT4;
> - if (downscale != downscale_y_table) {
> - load_scale_table(mdp, mdp_downscale_y_table[downscale], 64);
> - downscale_y_table = downscale;
> - }
> -
> - regs->phasex_init = phase_init_x;
> - regs->phasey_init = phase_init_y;
> - regs->phasex_step = phase_step_x;
> - regs->phasey_step = phase_step_y;
> regs->op |= (PPP_OP_SCALE_Y_ON | PPP_OP_SCALE_X_ON);
> return 0;
> -
> }
>
> static void blit_blur(const struct mdp_info *mdp, struct mdp_blit_req
> *req,
> struct ppp_regs *regs)
> {
> +#ifdef CONFIG_MSM_MDP22
> + int ret;
> +#endif
> if (!(req->flags & MDP_BLUR))
> return;
>
> - if (!(downscale_x_table = MDP_DOWNSCALE_BLUR &&
> - downscale_y_table = MDP_DOWNSCALE_BLUR)) {
> - load_scale_table(mdp, mdp_gaussian_blur_table, 128);
> - downscale_x_table = MDP_DOWNSCALE_BLUR;
> - downscale_y_table = MDP_DOWNSCALE_BLUR;
> - }
> -
> +#ifdef CONFIG_MSM_MDP22
> + ret = mdp_ppp_load_blur(mdp);
> + if (ret)
> + return;
> +#endif
> regs->op |= (PPP_OP_SCALE_Y_ON | PPP_OP_SCALE_X_ON);
> }
>
> -
> -#define IMG_LEN(rect_h, w, rect_w, bpp) (((rect_h) * w) * bpp)
> -
> -#define Y_TO_CRCB_RATIO(format) \
> - ((format = MDP_Y_CBCR_H2V2 || format = MDP_Y_CRCB_H2V2) ? 2 :\
> - (format = MDP_Y_CBCR_H2V1 || format = MDP_Y_CRCB_H2V1) ? 1 : 1)
> -
> static void get_len(struct mdp_img *img, struct mdp_rect *rect, uint32_t
> bpp,
> uint32_t *len0, uint32_t *len1)
> {
> @@ -555,7 +306,6 @@ static int valid_src_dst(unsigned long src_start,
> unsigned long src_len,
> return 1;
> }
>
> -
> static void flush_imgs(struct mdp_blit_req *req, struct ppp_regs *regs,
> struct file *src_file, struct file *dst_file)
> {
> @@ -643,22 +393,29 @@ int mdp_ppp_blit(const struct mdp_info *mdp, struct
> mdp_blit_req *req,
> return -EINVAL;
> }
>
> + if (unlikely(req->src_rect.x + req->src_rect.w > req->src.width ||
> + req->src_rect.y + req->src_rect.h > req->src.height ||
> + req->dst_rect.x + req->dst_rect.w > req->dst.width ||
> + req->dst_rect.y + req->dst_rect.h > req->dst.height)) {
> + printk(KERN_ERR "mdp_ppp: img rect extends outside of
> img!\n");
> + return -EINVAL;
> + }
> +
> /* set the src image configuration */
> regs.src_cfg = src_img_cfg[req->src.format];
> regs.src_cfg |= (req->src_rect.x & 0x1) ? PPP_SRC_BPP_ROI_ODD_X : 0;
> regs.src_cfg |= (req->src_rect.y & 0x1) ? PPP_SRC_BPP_ROI_ODD_Y : 0;
> - regs.src_rect = (req->src_rect.h << 16) | req->src_rect.w;
> regs.src_pack = pack_pattern[req->src.format];
>
> /* set the dest image configuration */
> regs.dst_cfg = dst_img_cfg[req->dst.format] | PPP_DST_OUT_SEL_AXI;
> - regs.dst_rect = (req->dst_rect.h << 16) | req->dst_rect.w;
> regs.dst_pack = pack_pattern[req->dst.format];
>
> /* set src, bpp, start pixel and ystride */
> regs.src_bpp = bytes_per_pixel[req->src.format];
> regs.src0 = src_start + req->src.offset;
> regs.src_ystride = req->src.width * regs.src_bpp;
> + set_src_region(&req->src, &req->src_rect, ®s);
> get_chroma_addr(&req->src, &req->src_rect, regs.src0, regs.src_bpp,
> regs.src_cfg, ®s.src1, ®s.src_ystride);
> regs.src0 += (req->src_rect.x + (req->src_rect.y * req->src.width))
> *
> @@ -668,6 +425,7 @@ int mdp_ppp_blit(const struct mdp_info *mdp, struct
> mdp_blit_req *req,
> regs.dst_bpp = bytes_per_pixel[req->dst.format];
> regs.dst0 = dst_start + req->dst.offset;
> regs.dst_ystride = req->dst.width * regs.dst_bpp;
> + set_dst_region(&req->dst_rect, ®s);
> get_chroma_addr(&req->dst, &req->dst_rect, regs.dst0, regs.dst_bpp,
> regs.dst_cfg, ®s.dst1, ®s.dst_ystride);
> regs.dst0 += (req->dst_rect.x + (req->dst_rect.y * req->dst.width))
> *
> @@ -703,9 +461,11 @@ int mdp_ppp_blit(const struct mdp_info *mdp, struct
> mdp_blit_req *req,
> req->dst_rect.x = req->dst_rect.x & (~0x1);
> req->dst_rect.w = req->dst_rect.w & (~0x1);
> }
> - if (get_edge_cond(req, ®s))
> - return -EINVAL;
>
> +#ifdef CONFIG_MSM_MDP22
> + if (mdp_ppp_cfg_edge_cond(req, ®s))
> + return -EINVAL;
> +#endif
> send_blit(mdp, req, ®s, src_file, dst_file);
> return 0;
> }
> diff --git a/drivers/video/msm/mdp_ppp.h b/drivers/video/msm/mdp_ppp.h
> index ef3b125..c3cd895 100644
> --- a/drivers/video/msm/mdp_ppp.h
> +++ b/drivers/video/msm/mdp_ppp.h
> @@ -47,4 +47,16 @@ struct ppp_regs {
> uint32_t bg_ystride;
> };
>
> +struct mdp_info;
> +struct mdp_rect;
> +struct mdp_blit_req;
> +
> +void mdp_ppp_init_scale(const struct mdp_info *mdp);
> +int mdp_ppp_cfg_scale(const struct mdp_info *mdp, struct ppp_regs *regs,
> + struct mdp_rect *src_rect, struct mdp_rect *dst_rect,
> + uint32_t src_format, uint32_t dst_format);
> +int mdp_ppp_load_blur(const struct mdp_info *mdp);
> +
> +int mdp_ppp_cfg_edge_cond(struct mdp_blit_req *req, struct ppp_regs
> *regs);
> +
> #endif /* _VIDEO_MSM_MDP_PPP_H_ */
> diff --git a/drivers/video/msm/mdp_scale_tables.c
> b/drivers/video/msm/mdp_ppp22.c
> similarity index 69%
> rename from drivers/video/msm/mdp_scale_tables.c
> rename to drivers/video/msm/mdp_ppp22.c
> index 604783b..8cfcff2 100644
> --- a/drivers/video/msm/mdp_scale_tables.c
> +++ b/drivers/video/msm/mdp_ppp22.c
> @@ -1,6 +1,6 @@
> -/* drivers/video/msm_fb/mdp_scale_tables.c
> +/* drivers/video/msm/mdp_ppp22.c
> *
> - * Copyright (C) 2007 QUALCOMM Incorporated
> + * Copyright (C) 2007, 2011 Code Aurora Forum. All rights reserved.
> * Copyright (C) 2007 Google Incorporated
> *
> * This software is licensed under the terms of the GNU General Public
> @@ -13,10 +13,33 @@
> * GNU General Public License for more details.
> */
>
> -#include "mdp_scale_tables.h"
> +#include <linux/kernel.h>
> +#include <linux/io.h>
> +#include <linux/msm_mdp.h>
> +
> #include "mdp_hw.h"
> +#include "mdp_ppp.h"
> +
> +struct mdp_table_entry {
> + uint32_t reg;
> + uint32_t val;
> +};
> +
> +enum {
> + MDP_DOWNSCALE_PT2TOPT4,
> + MDP_DOWNSCALE_PT4TOPT6,
> + MDP_DOWNSCALE_PT6TOPT8,
> + MDP_DOWNSCALE_PT8TO1,
> + MDP_DOWNSCALE_MAX,
> +
> + /* not technically in the downscale table list */
> + MDP_DOWNSCALE_BLUR,
> +};
>
> -struct mdp_table_entry mdp_upscale_table[] = {
> +static int downscale_x_table;
> +static int downscale_y_table;
> +
> +static struct mdp_table_entry mdp_upscale_table[] = {
> { 0x5fffc, 0x0 },
> { 0x50200, 0x7fc00000 },
> { 0x5fffc, 0xff80000d },
> @@ -764,3 +787,305 @@ struct mdp_table_entry mdp_gaussian_blur_table[] = {
> { 0x5fffc, 0x20000080 },
> { 0x5037c, 0x20000080 },
> };
> +
> +static void load_table(const struct mdp_info *mdp,
> + struct mdp_table_entry *table, int len)
> +{
> + int i;
> + for (i = 0; i < len; i++)
> + mdp_writel(mdp, table[i].val, table[i].reg);
> +}
> +
> +enum {
> + IMG_LEFT,
> + IMG_RIGHT,
> + IMG_TOP,
> + IMG_BOTTOM,
> +};
> +
> +static void get_edge_info(uint32_t src, uint32_t src_coord, uint32_t dst,
> + uint32_t *interp1, uint32_t *interp2,
> + uint32_t *repeat1, uint32_t *repeat2) {
> + if (src > 3 * dst) {
> + *interp1 = 0;
> + *interp2 = src - 1;
> + *repeat1 = 0;
> + *repeat2 = 0;
> + } else if (src = 3 * dst) {
> + *interp1 = 0;
> + *interp2 = src;
> + *repeat1 = 0;
> + *repeat2 = 1;
> + } else if (src > dst && src < 3 * dst) {
> + *interp1 = -1;
> + *interp2 = src;
> + *repeat1 = 1;
> + *repeat2 = 1;
> + } else if (src = dst) {
> + *interp1 = -1;
> + *interp2 = src + 1;
> + *repeat1 = 1;
> + *repeat2 = 2;
> + } else {
> + *interp1 = -2;
> + *interp2 = src + 1;
> + *repeat1 = 2;
> + *repeat2 = 2;
> + }
> + *interp1 += src_coord;
> + *interp2 += src_coord;
> +}
> +
> +int mdp_ppp_cfg_edge_cond(struct mdp_blit_req *req, struct ppp_regs
> *regs)
> +{
> + int32_t luma_interp[4];
> + int32_t luma_repeat[4];
> + int32_t chroma_interp[4];
> + int32_t chroma_bound[4];
> + int32_t chroma_repeat[4];
> + uint32_t dst_w, dst_h;
> +
> + memset(&luma_interp, 0, sizeof(int32_t) * 4);
> + memset(&luma_repeat, 0, sizeof(int32_t) * 4);
> + memset(&chroma_interp, 0, sizeof(int32_t) * 4);
> + memset(&chroma_bound, 0, sizeof(int32_t) * 4);
> + memset(&chroma_repeat, 0, sizeof(int32_t) * 4);
> + regs->edge = 0;
> +
> + if (req->flags & MDP_ROT_90) {
> + dst_w = req->dst_rect.h;
> + dst_h = req->dst_rect.w;
> + } else {
> + dst_w = req->dst_rect.w;
> + dst_h = req->dst_rect.h;
> + }
> +
> + if (regs->op & (PPP_OP_SCALE_Y_ON | PPP_OP_SCALE_X_ON)) {
> + get_edge_info(req->src_rect.h, req->src_rect.y, dst_h,
> + &luma_interp[IMG_TOP], &luma_interp[IMG_BOTTOM],
> + &luma_repeat[IMG_TOP], &luma_repeat[IMG_BOTTOM]);
> + get_edge_info(req->src_rect.w, req->src_rect.x, dst_w,
> + &luma_interp[IMG_LEFT], &luma_interp[IMG_RIGHT],
> + &luma_repeat[IMG_LEFT], &luma_repeat[IMG_RIGHT]);
> + } else {
> + luma_interp[IMG_LEFT] = req->src_rect.x;
> + luma_interp[IMG_RIGHT] = req->src_rect.x + req->src_rect.w -
> 1;
> + luma_interp[IMG_TOP] = req->src_rect.y;
> + luma_interp[IMG_BOTTOM] = req->src_rect.y + req->src_rect.h -
> 1;
> + luma_repeat[IMG_LEFT] = 0;
> + luma_repeat[IMG_TOP] = 0;
> + luma_repeat[IMG_RIGHT] = 0;
> + luma_repeat[IMG_BOTTOM] = 0;
> + }
> +
> + chroma_interp[IMG_LEFT] = luma_interp[IMG_LEFT];
> + chroma_interp[IMG_RIGHT] = luma_interp[IMG_RIGHT];
> + chroma_interp[IMG_TOP] = luma_interp[IMG_TOP];
> + chroma_interp[IMG_BOTTOM] = luma_interp[IMG_BOTTOM];
> +
> + chroma_bound[IMG_LEFT] = req->src_rect.x;
> + chroma_bound[IMG_RIGHT] = req->src_rect.x + req->src_rect.w - 1;
> + chroma_bound[IMG_TOP] = req->src_rect.y;
> + chroma_bound[IMG_BOTTOM] = req->src_rect.y + req->src_rect.h - 1;
> +
> + if (IS_YCRCB(req->src.format)) {
> + chroma_interp[IMG_LEFT] = chroma_interp[IMG_LEFT] >> 1;
> + chroma_interp[IMG_RIGHT] = (chroma_interp[IMG_RIGHT] + 1) >>
> 1;
> +
> + chroma_bound[IMG_LEFT] = chroma_bound[IMG_LEFT] >> 1;
> + chroma_bound[IMG_RIGHT] = chroma_bound[IMG_RIGHT] >> 1;
> + }
> +
> + if (req->src.format = MDP_Y_CBCR_H2V2 ||
> + req->src.format = MDP_Y_CRCB_H2V2) {
> + chroma_interp[IMG_TOP] = (chroma_interp[IMG_TOP] - 1) >> 1;
> + chroma_interp[IMG_BOTTOM] = (chroma_interp[IMG_BOTTOM] + 1)
> + >> 1;
> + chroma_bound[IMG_TOP] = (chroma_bound[IMG_TOP] + 1) >> 1;
> + chroma_bound[IMG_BOTTOM] = chroma_bound[IMG_BOTTOM] >> 1;
> + }
> +
> + chroma_repeat[IMG_LEFT] = chroma_bound[IMG_LEFT] -
> + chroma_interp[IMG_LEFT];
> + chroma_repeat[IMG_RIGHT] = chroma_interp[IMG_RIGHT] -
> + chroma_bound[IMG_RIGHT];
> + chroma_repeat[IMG_TOP] = chroma_bound[IMG_TOP] -
> + chroma_interp[IMG_TOP];
> + chroma_repeat[IMG_BOTTOM] = chroma_interp[IMG_BOTTOM] -
> + chroma_bound[IMG_BOTTOM];
> +
> + if (chroma_repeat[IMG_LEFT] < 0 || chroma_repeat[IMG_LEFT] > 3 ||
> + chroma_repeat[IMG_RIGHT] < 0 || chroma_repeat[IMG_RIGHT] > 3 ||
> + chroma_repeat[IMG_TOP] < 0 || chroma_repeat[IMG_TOP] > 3 ||
> + chroma_repeat[IMG_BOTTOM] < 0 || chroma_repeat[IMG_BOTTOM] > 3
> ||
> + luma_repeat[IMG_LEFT] < 0 || luma_repeat[IMG_LEFT] > 3 ||
> + luma_repeat[IMG_RIGHT] < 0 || luma_repeat[IMG_RIGHT] > 3 ||
> + luma_repeat[IMG_TOP] < 0 || luma_repeat[IMG_TOP] > 3 ||
> + luma_repeat[IMG_BOTTOM] < 0 || luma_repeat[IMG_BOTTOM] > 3)
> + return -1;
Please use error codes defined by linux-kernel.
Please refer to:
http://lxr.linux.no/#linux+v2.6.38/include/asm-generic/errno-base.h
Here you can use -EINVAL for invalid value.
> +
> + regs->edge |= (chroma_repeat[IMG_LEFT] & 3) << MDP_LEFT_CHROMA;
> + regs->edge |= (chroma_repeat[IMG_RIGHT] & 3) << MDP_RIGHT_CHROMA;
> + regs->edge |= (chroma_repeat[IMG_TOP] & 3) << MDP_TOP_CHROMA;
> + regs->edge |= (chroma_repeat[IMG_BOTTOM] & 3) << MDP_BOTTOM_CHROMA;
> + regs->edge |= (luma_repeat[IMG_LEFT] & 3) << MDP_LEFT_LUMA;
> + regs->edge |= (luma_repeat[IMG_RIGHT] & 3) << MDP_RIGHT_LUMA;
> + regs->edge |= (luma_repeat[IMG_TOP] & 3) << MDP_TOP_LUMA;
> + regs->edge |= (luma_repeat[IMG_BOTTOM] & 3) << MDP_BOTTOM_LUMA;
> + return 0;
> +}
> +
> +#define ONE_HALF (1LL << 32)
> +#define ONE (1LL << 33)
> +#define TWO (2LL << 33)
> +#define THREE (3LL << 33)
> +#define FRAC_MASK (ONE - 1)
> +#define INT_MASK (~FRAC_MASK)
> +
> +static int scale_params(uint32_t dim_in, uint32_t dim_out, uint32_t
> origin,
> + uint32_t *phase_init, uint32_t *phase_step)
> +{
> + /* to improve precicsion calculations are done in U31.33 and
> converted
> + * to U3.29 at the end */
[cosmetic comment]: Multiline comments?
> + int64_t k1, k2, k3, k4, tmp;
> + uint64_t n, d, os, os_p, od, od_p, oreq;
> + unsigned rpa = 0;
> + int64_t ip64, delta;
> +
> + if (dim_out % 3 = 0)
> + rpa = !(dim_in % (dim_out / 3));
> +
> + n = ((uint64_t)dim_out) << 34;
> + d = dim_in;
> + if (!d)
> + return -1;
Please use standard error codes.
> + do_div(n, d);
> + k3 = (n + 1) >> 1;
> + if ((k3 >> 4) < (1LL << 27) || (k3 >> 4) > (1LL << 31))
> + return -1;
> +
> + n = ((uint64_t)dim_in) << 34;
> + d = (uint64_t)dim_out;
> + if (!d)
> + return -1;
Same: Please use standard error codes.
> + do_div(n, d);
> + k1 = (n + 1) >> 1;
> + k2 = (k1 - ONE) >> 1;
> +
> + *phase_init = (int)(k2 >> 4);
> + k4 = (k3 - ONE) >> 1;
> +
> + if (rpa) {
> + os = ((uint64_t)origin << 33) - ONE_HALF;
> + tmp = (dim_out * os) + ONE_HALF;
> + if (!dim_in)
> + return -1;
> + do_div(tmp, dim_in);
> + od = tmp - ONE_HALF;
> + } else {
> + os = ((uint64_t)origin << 1) - 1;
> + od = (((k3 * os) >> 1) + k4);
> + }
> +
> + od_p = od & INT_MASK;
> + if (od_p != od)
> + od_p += ONE;
> +
> + if (rpa) {
> + tmp = (dim_in * od_p) + ONE_HALF;
> + if (!dim_in)
> + return -1;
> + do_div(tmp, dim_in);
> + os_p = tmp - ONE_HALF;
> + } else {
> + os_p = ((k1 * (od_p >> 33)) + k2);
> + }
> +
> + oreq = (os_p & INT_MASK) - ONE;
> +
> + ip64 = os_p - oreq;
> + delta = ((int64_t)(origin) << 33) - oreq;
> + ip64 -= delta;
> + /* limit to valid range before the left shift */
> + delta = (ip64 & (1LL << 63)) ? 4 : -4;
> + delta <<= 33;
> + while (abs((int)(ip64 >> 33)) > 4)
> + ip64 += delta;
> + *phase_init = (int)(ip64 >> 4);
> + *phase_step = (uint32_t)(k1 >> 4);
> + return 0;
> +}
> +
> +int mdp_ppp_cfg_scale(const struct mdp_info *mdp, struct ppp_regs *regs,
> + struct mdp_rect *src_rect, struct mdp_rect *dst_rect,
> + uint32_t src_format, uint32_t dst_format)
> +{
> + int downscale;
> + uint32_t phase_init_x, phase_init_y, phase_step_x, phase_step_y;
> + uint32_t scale_factor_x, scale_factor_y;
> +
> + if (scale_params(src_rect->w, dst_rect->w, 1, &phase_init_x,
> + &phase_step_x) ||
> + scale_params(src_rect->h, dst_rect->h, 1, &phase_init_y,
> + &phase_step_y))
> + return -1;
Error code?
> +
> + regs->phasex_init = phase_init_x;
> + regs->phasey_init = phase_init_y;
> + regs->phasex_step = phase_step_x;
> + regs->phasey_step = phase_step_y;
> +
> + scale_factor_x = (dst_rect->w * 10) / src_rect->w;
> + scale_factor_y = (dst_rect->h * 10) / src_rect->h;
> +
> + if (scale_factor_x > 8)
> + downscale = MDP_DOWNSCALE_PT8TO1;
> + else if (scale_factor_x > 6)
> + downscale = MDP_DOWNSCALE_PT6TOPT8;
> + else if (scale_factor_x > 4)
> + downscale = MDP_DOWNSCALE_PT4TOPT6;
> + else
> + downscale = MDP_DOWNSCALE_PT2TOPT4;
> +
> + if (downscale != downscale_x_table) {
> + load_table(mdp, mdp_downscale_x_table[downscale], 64);
> + downscale_x_table = downscale;
> + }
> +
> + if (scale_factor_y > 8)
> + downscale = MDP_DOWNSCALE_PT8TO1;
> + else if (scale_factor_y > 6)
> + downscale = MDP_DOWNSCALE_PT6TOPT8;
> + else if (scale_factor_y > 4)
> + downscale = MDP_DOWNSCALE_PT4TOPT6;
> + else
> + downscale = MDP_DOWNSCALE_PT2TOPT4;
> +
> + if (downscale != downscale_y_table) {
> + load_table(mdp, mdp_downscale_y_table[downscale], 64);
> + downscale_y_table = downscale;
> + }
> +
> + return 0;
> +}
> +
> +
[cosmetic comment]: Extra line?
> +int mdp_ppp_load_blur(const struct mdp_info *mdp)
> +{
> + if (!(downscale_x_table = MDP_DOWNSCALE_BLUR &&
> + downscale_y_table = MDP_DOWNSCALE_BLUR)) {
> + load_table(mdp, mdp_gaussian_blur_table, 128);
> + downscale_x_table = MDP_DOWNSCALE_BLUR;
> + downscale_y_table = MDP_DOWNSCALE_BLUR;
> + }
> +
> + return 0;
> +}
> +
> +void mdp_ppp_init_scale(const struct mdp_info *mdp)
> +{
> + downscale_x_table = MDP_DOWNSCALE_MAX;
> + downscale_y_table = MDP_DOWNSCALE_MAX;
> +
> + load_table(mdp, mdp_upscale_table, ARRAY_SIZE(mdp_upscale_table));
> +}
> diff --git a/drivers/video/msm/mdp_scale_tables.h
> b/drivers/video/msm/mdp_scale_tables.h
> deleted file mode 100644
> index 34077b1..0000000
> --- a/drivers/video/msm/mdp_scale_tables.h
> +++ /dev/null
> @@ -1,38 +0,0 @@
> -/* drivers/video/msm_fb/mdp_scale_tables.h
> - *
> - * Copyright (C) 2007 QUALCOMM Incorporated
> - * Copyright (C) 2007 Google Incorporated
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - */
> -#ifndef _MDP_SCALE_TABLES_H_
> -#define _MDP_SCALE_TABLES_H_
> -
> -#include <linux/types.h>
> -struct mdp_table_entry {
> - uint32_t reg;
> - uint32_t val;
> -};
> -
> -extern struct mdp_table_entry mdp_upscale_table[64];
> -
> -enum {
> - MDP_DOWNSCALE_PT2TOPT4,
> - MDP_DOWNSCALE_PT4TOPT6,
> - MDP_DOWNSCALE_PT6TOPT8,
> - MDP_DOWNSCALE_PT8TO1,
> - MDP_DOWNSCALE_MAX,
> -};
> -
> -extern struct mdp_table_entry *mdp_downscale_x_table[MDP_DOWNSCALE_MAX];
> -extern struct mdp_table_entry *mdp_downscale_y_table[MDP_DOWNSCALE_MAX];
> -extern struct mdp_table_entry mdp_gaussian_blur_table[];
> -
> -#endif
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>
> --
> 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
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