* [RFC] Standardize YUV support in the fbdev API
From: Laurent Pinchart @ 2011-05-17 22:07 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-media, dri-devel
Hi everybody,
I need to implement support for a YUV frame buffer in an fbdev driver. As the
fbdev API doesn't support this out of the box, I've spent a couple of days
reading fbdev (and KMS) code and thinking about how we could cleanly add YUV
support to the API. I'd like to share my findings and thoughts, and hopefully
receive some comments back.
The terms 'format', 'pixel format', 'frame buffer format' and 'data format'
will be used interchangeably in this e-mail. They all refer to the way pixels
are stored in memory, including both the representation of a pixel as integer
values and the layout of those integer values in memory.
History and current situation
-----------------------------
The fbdev API predates YUV frame buffers. In those old days developers only
cared (and probably thought) about RGB frame buffers, and they developed an
API that could express all kind of weird RGB layout in memory (such as R-
GGGGGGGGGGG-BBBB for instance, I can't imagine hardware implementing that).
This resulted in individual bit field description for the red, green, blue and
alpha components:
struct fb_bitfield {
__u32 offset; /* beginning of bitfield */
__u32 length; /* length of bitfield */
__u32 msb_right; /* != 0 : Most significant bit is */
/* right */
};
Grayscale formats were pretty common, so a grayscale field tells color formats
(grayscale = 0) from grayscale formats (grayscale != 0).
People already realized that hardware developers were crazily inventive (the
word to remember here is crazily), and that non-standard formats would be
needed at some point. The fb_var_screeninfo ended up containing the following
format-related fields.
struct fb_var_screeninfo {
...
__u32 bits_per_pixel; /* guess what */
__u32 grayscale; /* != 0 Graylevels instead of colors */
struct fb_bitfield red; /* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
struct fb_bitfield blue;
struct fb_bitfield transp; /* transparency */
__u32 nonstd; /* != 0 Non standard pixel format */
...
};
Two bits have been specified for the nonstd field:
#define FB_NONSTD_HAM 1 /* Hold-And-Modify (HAM) */
#define FB_NONSTD_REV_PIX_IN_B 2 /* order of pixels in each byte is reversed
*/
The FB_NONSTD_HAM bit is used by the video/amifb.c driver only to enable HAM
mode[1]. I very much doubt that any new hardware will implement HAM mode (and
I certainly hope none will).
The FB_NONSTD_REV_PIX_IN_B is used in video/fb_draw.h by the generic bitblit,
fillrect and copy area implementations, not directly by drivers.
A couple of drivers hardcode the nonstd field to 1 for some reason. Those are
video/arcfb.c (1bpp gray display), video/hecubafb.c (1bpp gray display) and
video/metronomefb.c (8bpp gray display).
The following drivers use nonstd for various other (and sometimes weird)
purposes:
video/arkfb.c
Used in 4bpp mode only, to control fb_setcolreg operation
video/fsl-diu-fb.c
Set var->nonstd bits into var->sync (why?)
video/pxafb.c
Encode frame buffer xpos and ypos in the nonstd field
video/s3fb.c
Used in 4bpp mode only, to control fb_setcolreg operation
video/vga16fb.c
When panning in non-8bpp, non-text mode, decrement xoffset
Do some other weird stuff when not 0
video/i810/i810_main.c
Select direct color mode when set to 1 (truecolor otherwise)
Fast forward a couple of years, hardware provides support for YUV frame
buffers. Several drivers had to provide YUV format selection to applications,
without any standard API to do so. All of them used the nonstd field for that
purpose:
media/video/ivtv/
Enable YUV mode when set to 1
video/pxafb.c
Encode pixel format in the nonstd field
video/sh_mobile_lcdfb.c
If bpp = 12 and nonstd != 0, enable NV12 mode
If bpp = 16 or bpp = 24, ?
video/omap/omapfb_main.c
Select direct color mode when set to 1 (depend on bpp otherwise)
Used as a pixel format identifier (YUV422, YUV420 or YUY422)
video/omap2/omapfb/omapfb-main.c
Select direct color mode when set to 1 (depend on bpp otherwise)
Used as a pixel format identifier (YUV422 or YUY422)
Those drivers use the nonstd field in different, incompatible ways.
Other related APIs
------------------
Beside the fbdev API, two other kernel/userspace APIs deal with video-related
modes and formats.
- Kernel Mode Setting (KMS)
The KMS API is similar in purpose to XRandR. Its main purpose is to provide a
kernel API to configure output video modes. As such, it doesn't care about
frame buffer formats, as they are irrelevant at the CRTC output.
In addition to handling video modes, the KMS API also provides support for
creating (and managing) frame buffer devices, as well as dumb scan-out
buffers. In-memory data format is relevant there, but KMS only handles width,
height, pitch, depth and bit-per-pixel information. The API doesn't care
whether the frame buffer or the dumb scan-out buffer contains RGB or YUV data.
An RFC[2] has recently been posted to the dri-devel mailing list to "add
overlays as first class KMS objects". The proposal includes explicit overlay
format support, and discussions have so far pushed towards reusing V4L format
codes for the KMS API.
- Video 4 Linux (V4L)
The V4L API version 2 (usually called V4L2) has since the beginning included
explicit support for data format, referred to as pixel formats.
Pixel formats are identified by a 32-bit number in the form of a four
characters code (4CC or FCC[3]). The list of FCCs defined by V4L2 is available
in [4].
A pixel format uniquely defines the layout of pixel data in memory, including
the format type (RGB, YUV, ...), number of bits per components, components
order and subsampling. It doesn't define the range of acceptable values for
pixel components (such as full-range YUV vs. BT.601[5]), which is carried
through a separate colorspace identifier[6].
YUV support in the fbdev API
----------------------------
Experience with the V4L2 API, both for desktop and embedded devices, and the
KMS API, suggests that recent hardware tend to standardize on a relatively
small number of pixel formats that don't require bitfield-level descriptions.
A pixel format definition based on identifiers should thus fullfill the
hardware needs for the foreseeable future.
Given the overlap between the KMS, V4L2 and fbdev APIs, the need to share data
and buffers between those subsystems, and the planned use of V4L2 FCCs in the
KMS overlay API, I believe using V4L2 FCCs to identify fbdev formats would be
a wise decision.
To select a frame buffer YUV format, the fb_var_screeninfo structure will need
to be extended with a format field. The fbdev API and ABI must not be broken,
which prevents us from changing the current structure layout and replacing the
existing format selection mechanism (through the red, green, blue and alpha
bitfields) completely.
Several solutions exist to introduce a format field in the fb_var_screeninfo
structure.
- Use the nonstd field as a format identifier. Existing drivers that use the
nonstd field for other purposes wouldn't be able to implement the new API
while keeping their existing API. This isn't a show stopper for drivers using
the FB_NONSTD_HAM and FB_NONSTD_REV_PIX_IN_B bits, as they don't need to
support any non-RGB format.
Existing drivers that support YUV formats through the nonstd field would have
to select between the current and the new API, without being able to implement
both.
- Use one of the reserved fields as a format identifier. Applications are
supposed to zero the fb_var_screeninfo structure before passing it to the
kernel, but experience showed that many applications forget to do so. Drivers
would then be unable to find out whether applications request a particular
format, or just forgot to initialize the field.
- Add a new FB_NONSTD_FORMAT bit to the nonstd field, and pass the format
through a separate field. If an application sets the FB_NONSTD_FORMAT bit in
the nonstd field, drivers will ignore the red, green, blue, transp and
grayscale fields, and use the format identifier to configure the frame buffer
format. The grayscale field would then be unneeded and could be reused as a
format identifier. Alternatively, one of the reserved fields could be used for
that purpose.
Existing drivers that support YUV formats through the nonstd field don't use
the field's most significant bits. They could implement both their current API
and the new API if the FB_NONSTD_FORMAT bit is stored in one of the nonstd
MSBs.
- Other solutions are possible, such as adding new ioctls. Those solutions are
more intrusive, and require larger changes to both userspace and kernelspace
code.
The third solution has my preference. Comments and feedback will be
appreciated. I will then work on a proof of concept and submit patches.
[1] http://en.wikipedia.org/wiki/Hold_And_Modify
[2] http://lwn.net/Articles/440192/
[3] http://www.fourcc.org/
[4] http://lxr.linux.no/linux+v2.6.38/include/linux/videodev2.h#L271
[5] http://en.wikipedia.org/wiki/Rec._601
[6] http://lxr.linux.no/linux+v2.6.38/include/linux/videodev2.h#L175
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [GIT PULL] viafb updates for 2.6.40
From: Florian Tobias Schandinat @ 2011-05-17 18:30 UTC (permalink / raw)
To: linux-fbdev
Hi Paul,
please pull the viafb updates below.
They contain major cleanups, a better PLL/clock management and some notable
changes for users like write-combining speeding userspace apps up by a factor
around 6 (on newer hardware) and other things making viafb more likely to work.
Also some small changes to make the life of OLPC XO 1.5 users easier.
Thanks,
Florian Tobias Schandinat
The following changes since commit b4ce6a285b65be4fb858728b3bbe9011242b769f:
Florian Tobias Schandinat (1):
viafb: fix OLPC DCON refresh rate
are available in the git repository at:
git://github.com/schandinat/linux-2.6.git viafb-next
Daniel Drake (1):
viafb: Automatic OLPC XO-1.5 configuration
Florian Tobias Schandinat (25):
viafb: move initialization code
viafb: no need to write CRTC values twice
viafb: kill crt_setting_information
viafb: allow some pll calculations
viafb: remove unused max_hres/vres
viafb: call viafb_get_clk_value only in viafb_set_vclock
viafb: prepare for PLL separation
viafb: add clock source selection and PLL power management support
viafb: add primary/secondary clock on/off switches
viafb: split clock and PLL code to an extra file
viafb: add VIA slapping capability
viafb: add engine clock support
viafb: gather common good, old VGA initialization in one place
viafb: some small cleanup for global variables
viafb: replace custom return values
viafb: delete clock and PLL initialization
viafb: fix OLPC XO 1.5 device connection
viafb: reduce OLPC refresh a bit
viafb: add X server compatibility mode
Merge branch 'viafb-olpc' into viafb-next
Merge branch 'viafb-cleanup' into viafb-next
Merge branch 'viafb-pll' into viafb-next
viafb: use write combining for video ram
viafb: try to map less memory in case of failure
viafb: remove unused CEA mode
drivers/video/Kconfig | 11 +
drivers/video/via/Makefile | 2 +-
drivers/video/via/chip.h | 6 -
drivers/video/via/dvi.c | 160 +----------
drivers/video/via/dvi.h | 2 +-
drivers/video/via/global.c | 4 -
drivers/video/via/global.h | 2 -
drivers/video/via/hw.c | 624 ++++++++++++++---------------------------
drivers/video/via/hw.h | 15 +-
drivers/video/via/lcd.c | 23 +-
drivers/video/via/lcd.h | 2 +-
drivers/video/via/share.h | 17 +-
drivers/video/via/via-core.c | 9 +-
drivers/video/via/via_clock.c | 349 +++++++++++++++++++++++
drivers/video/via/via_clock.h | 76 +++++
drivers/video/via/viafbdev.c | 62 +++--
drivers/video/via/viafbdev.h | 4 -
drivers/video/via/viamode.c | 46 +---
drivers/video/via/viamode.h | 9 -
19 files changed, 718 insertions(+), 705 deletions(-)
create mode 100644 drivers/video/via/via_clock.c
create mode 100644 drivers/video/via/via_clock.h
^ permalink raw reply
* Re: [PATCH 2/2] trivial: Changed the printk loglevel when not able to
From: Catalin Marinas @ 2011-05-17 17:43 UTC (permalink / raw)
To: anish; +Cc: linux, lethal, linux-fbdev, linux-kernel
In-Reply-To: <1305653342.2182.15.camel@anish-desktop>
On 17 May 2011 18:29, anish <anish198519851985@gmail.com> wrote:
> When not able to allocate memory we were using KERN_INFO as
> log level in printk so changed to KERN_ERR
> Â Signed-off-by: anish kumar<anish198519851985@gmail.com>
Maybe KERN_WARN?
--
Catalin
^ permalink raw reply
* [PATCH 2/2] trivial: Changed the printk loglevel when not able to
From: anish @ 2011-05-17 17:41 UTC (permalink / raw)
To: linux, lethal; +Cc: linux-fbdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
When not able to allocate memory we were using KERN_INFO as
log level in printk so changed to KERN_ERR
Signed-off-by: anish kumar<anish198519851985@gmail.com>
---
drivers/video/amba-clcd.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index cb7ec86..e87d98b 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -551,7 +551,7 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
fb = kzalloc(sizeof(*fb), GFP_KERNEL);
if (!fb) {
- printk(KERN_INFO "CLCD: could not allocate new clcd_fb struct\n");
+ printk(KERN_ERR "CLCD: could not allocate new clcd_fb struct\n");
ret = -ENOMEM;
goto free_region;
}
--
1.7.0.4
[-- Attachment #2: 0002-Changed-the-printk-loglevel-when-not-able-to-allocat.patch --]
[-- Type: text/x-patch, Size: 983 bytes --]
From 19bbb666a6067a6ba280e2cb984c924bcaf06f52 Mon Sep 17 00:00:00 2001
From: anish kumar <anish198519851985@gmail.com>
Date: Tue, 17 May 2011 22:50:59 +0530
Subject: [PATCH 2/2] Changed the printk loglevel when not able to allocate memory
When not able to allocate memory we were using KERN_INFO so just
changed to KERN_ERR
Signed-off-by: anish kumar<anish198519851985@gmail.com>
---
drivers/video/amba-clcd.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index cb7ec86..e87d98b 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -551,7 +551,7 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
fb = kzalloc(sizeof(*fb), GFP_KERNEL);
if (!fb) {
- printk(KERN_INFO "CLCD: could not allocate new clcd_fb struct\n");
+ printk(KERN_ERR "CLCD: could not allocate new clcd_fb struct\n");
ret = -ENOMEM;
goto free_region;
}
--
1.7.0.4
^ permalink raw reply related
* [patch 1/2] trivial: preferred form for passing a size of struct
From: anish @ 2011-05-17 17:40 UTC (permalink / raw)
To: linux, lethal; +Cc: linux-fbdev, linux-kernel
The preferred form for passing a size of a struct is the following:
p = kmalloc(sizeof(*p), ...);
Please refer Documentation/Codingstyle chapter 14
Signed-off-by: anish kumar<anish198519851985@gmail.com>
---
drivers/video/amba-clcd.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 5fc983c..cb7ec86 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -549,7 +549,7 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
goto out;
}
- fb = kzalloc(sizeof(struct clcd_fb), GFP_KERNEL);
+ fb = kzalloc(sizeof(*fb), GFP_KERNEL);
if (!fb) {
printk(KERN_INFO "CLCD: could not allocate new clcd_fb struct\n");
ret = -ENOMEM;
--
1.7.0.4
^ permalink raw reply related
* Re: i80 (Intel 8080-like) command interface to LCDs - how to implement
From: Heiko Stübner @ 2011-05-17 16:25 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <201105171359.43658.heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
Am Dienstag 17 Mai 2011, 13:59:40 schrieb Heiko Stübner:
> I'm trying to find the best way on implementing an i80 interface
> (especially the command mode) between a s3c2416 and an AUO-K1900 (epaper
> controller).
>
> On the host side it is usable at least in all Samsung SoCs following the
> S3C2443 and on the device side I've found, apart from the K1900, for
> example the ili9320 and STM32F10xxx displays controllers using this
> interface.
>
> It looks a bit like a cross between SPI and I2C but fits neither category -
> at least for my understanding.
after some more thoughts while cycling home, would it be sane to implement it
as spi devices like:
lcd-ctrl <->i80_device (spi_device) <->spi-layer <-> i80_spi_master
i80_device would implement the message logic as described below
i80_spi_master would control the registers
the write-enable/read-enable bit settings can be determined by the direction
of the transfer, but how do I determine the value to set for RS?
The idea I had was to set bits_per_word to n+1, i.e. the register has 18 data
bits and I would use the 19th bit do transmit the required RS setting.
Does this look at least halfway plausible?
Thanks
Heiko
[rest of this mail included as I have just added spi-devel to the recipients]
> pins/pins consist of:
> CS ... chip-select
> RS ... control or data register select
> WE ... write enable
> RE ... read enable
> D0-Dn ... data 0-n for variing values of n
> (I've seen up to 18 data bits)
>
>
> commands can look like:
> (* set command mode)
> * set chip-select
>
> * set RS to control (mostly low)
> * set WE to high
> * write command to D
> * unset WE
> * set RS to data
>
> * set WE
> * write data to D
> * unset WE
> * set WE
> * write data to D
> * unset WE
> ...
> * set RE
> * read data from D
> * unset RE
> ...
> * unset chip-select
> (* unset command mode)
>
> the fourth possible state (read-control) is also used by the ili9320.
>
> looks a lot like an i2c-transfer, i.e. something like
> {
> { WC, 6001 }, //for write-control
> { WD, 576 }, //for write-data
> { WD, 12 }, //for write-data
> { RD, *buf } //for read-data
> }
> could represent the above command-sequence.
>
>
> So, is this a new bus type or does it fit somehow into spi or i2c or some
> other bus-type I don't know yet? Or, does code for i80 exist somewhere I
> haven't looked yet?
^ permalink raw reply
* i80 (Intel 8080-like) command interface to LCDs - how to implement
From: Heiko Stübner @ 2011-05-17 11:59 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner
Hi,
I'm trying to find the best way on implementing an i80 interface (especially
the command mode) between a s3c2416 and an AUO-K1900 (epaper controller).
On the host side it is usable at least in all Samsung SoCs following the
S3C2443 and on the device side I've found, apart from the K1900, for example
the ili9320 and STM32F10xxx displays controllers using this interface.
It looks a bit like a cross between SPI and I2C but fits neither category - at
least for my understanding.
pins/pins consist of:
CS ... chip-select
RS ... control or data register select
WE ... write enable
RE ... read enable
D0-Dn ... data 0-n for variing values of n
(I've seen up to 18 data bits)
commands can look like:
(* set command mode)
* set chip-select
* set RS to control (mostly low)
* set WE to high
* write command to D
* unset WE
* set RS to data
* set WE
* write data to D
* unset WE
* set WE
* write data to D
* unset WE
...
* set RE
* read data from D
* unset RE
...
* unset chip-select
(* unset command mode)
the fourth possible state (read-control) is also used by the ili9320.
looks a lot like an i2c-transfer, i.e. something like
{
{ WC, 6001 }, //for write-control
{ WD, 576 }, //for write-data
{ WD, 12 }, //for write-data
{ RD, *buf } //for read-data
}
could represent the above command-sequence.
So, is this a new bus type or does it fit somehow into spi or i2c or some other
bus-type I don't know yet? Or, does code for i80 exist somewhere I haven't
looked yet?
Thanks in advance
Heiko
^ permalink raw reply
* [PATCH] video: s3c2410fb: use resource_size()
From: Jingoo Han @ 2011-05-17 9:45 UTC (permalink / raw)
To: linux-fbdev
This patch uses the resource_size help function instead of
manually calculating the resource size. It can reduce the chance
of introducing off-by-one errors.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c2410fb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index 61c819e..4226ec3 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -867,7 +867,7 @@ static int __devinit s3c24xxfb_probe(struct platform_device *pdev,
goto dealloc_fb;
}
- size = (res->end - res->start) + 1;
+ size = resource_size(res);
info->mem = request_mem_region(res->start, size, pdev->name);
if (info->mem = NULL) {
dev_err(&pdev->dev, "failed to get memory region\n");
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] omap: Remove support for omap2evm (Re: Updated mach-types
From: Liam Girdwood @ 2011-05-16 13:45 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-fbdev@vger.kernel.org, Russell King - ARM Linux, Paul Mundt,
Subhasish Ghosh, Mark Brown, Srinath, alsa-devel@alsa-project.org,
Valkeinen, Tomi, Arun C, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20110513144031.GV31483@atomide.com>
On 13/05/11 15:40, Tony Lindgren wrote:
> * Jarkko Nikula <jhnikula@gmail.com> [110513 05:15]:
>> On Fri, 13 May 2011 04:54:07 -0700
>> Tony Lindgren <tony@atomide.com> wrote:
>>
>>> * Tony Lindgren <tony@atomide.com> [110324 10:57]:
>>>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110320 04:39]:
>>>>> On Sun, Mar 20, 2011 at 11:03:22AM +0000, Russell King - ARM Linux wrote:
>>>>>
>>>>> Note that OMAP references machine_is_omap2evm() yet this has never been
>>>>> merged.
>>>>>
>>>>> arch/arm/plat-omap/include/plat/uncompress.h:
>>>>>
>>>>> DEBUG_LL_OMAP2(1, omap2evm);
>>>>>
>>>>> so this entry needs to be removed.
>>>>
>>>> Hmm looks like we have LCD support and ASoC support for it, but no
>>>> board :)
>>>>
>>>> Anybody working with this board?
>>>>
>>>> If so, please send patches for the related board-*.c support ASAP.
>>>> Otherwise let's plan on deleting the related support.
>>>
>>> No patches, so let's remove it. Here's the patch to do that,
>>> I'm planning to add this to my devel-cleanup branch.
>>>
>> Remove also from sound/soc/omap/Kconfig as well. You could put my
>> ack for sound/soc/omap part but remember cc also Mark and Liam.
>
> Thanks, here's the updated patch.
>
> Regards,
>
> Tony
>
>
> From: Tony Lindgren <tony@atomide.com>
> Date: Fri, 13 May 2011 04:41:32 -0700
> Subject: [PATCH] omap: Remove support for omap2evm
>
> The board support has never been merged for it as noticed
> by Russell King <linux@arm.linux.org.uk>. So let's remove the
> related dead code.
>
> Cc: linux-fbdev@vger.kernel.org
> Cc: alsa-devel@alsa-project.org
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Cc: Liam Girdwood <lrg@ti.com>
> Cc: Paul Mundt <lethal@linux-sh.org>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Acked-by: Jarkko Nikula <jhnikula@gmail.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
Acked-by: Liam Girdwood <lrg@ti.com>
^ permalink raw reply
* Re: [PATCH v3] viafb: Automatic OLPC XO-1.5 configuration
From: Florian Tobias Schandinat @ 2011-05-16 8:33 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110510213411.38D0F9D401C@zog.reactivated.net>
On 05/10/2011 09:34 PM, Daniel Drake wrote:
> Currently, a long set of viafb options are needed to get the XO-1.5
> laptop to output video (there is only 1 configuration that works, that
> can't really be autodetected).
>
> This patch automatically detects and configures viafb for the XO-1.5
> laptop, meaning all that is required for working display is that
> viafb is loaded.
Applied.
Thanks,
Florian Tobias Schandinat
> Signed-off-by: Daniel Drake<dsd@laptop.org>
> ---
> drivers/video/via/viafbdev.c | 39 ++++++++++++++++++++++++++++++---------
> 1 files changed, 30 insertions(+), 9 deletions(-)
>
> v2: incorporates all feedback from Florian
> v3: drop unnecessary viafb_bpp override
>
> diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
> index 7b4390e..cf43c80 100644
> --- a/drivers/video/via/viafbdev.c
> +++ b/drivers/video/via/viafbdev.c
> @@ -24,6 +24,7 @@
> #include<linux/slab.h>
> #include<linux/stat.h>
> #include<linux/via-core.h>
> +#include<asm/olpc.h>
>
> #define _MASTER_FILE
> #include "global.h"
> @@ -1011,8 +1012,13 @@ static int __init parse_active_dev(void)
> /* Note: The previous of active_dev is primary device,
> and the following is secondary device. */
> if (!viafb_active_dev) {
> - viafb_CRT_ON = STATE_ON;
> - viafb_SAMM_ON = STATE_OFF;
> + if (machine_is_olpc()) { /* LCD only */
> + viafb_LCD_ON = STATE_ON;
> + viafb_SAMM_ON = STATE_OFF;
> + } else {
> + viafb_CRT_ON = STATE_ON;
> + viafb_SAMM_ON = STATE_OFF;
> + }
> } else if (!strcmp(viafb_active_dev, "CRT+DVI")) {
> /* CRT+DVI */
> viafb_CRT_ON = STATE_ON;
> @@ -1665,8 +1671,13 @@ static int parse_mode(const char *str, u32 *xres, u32 *yres)
> char *ptr;
>
> if (!str) {
> - *xres = 640;
> - *yres = 480;
> + if (machine_is_olpc()) {
> + *xres = 1200;
> + *yres = 900;
> + } else {
> + *xres = 640;
> + *yres = 480;
> + }
> return 0;
> }
>
> @@ -1922,11 +1933,16 @@ void __devexit via_fb_pci_remove(struct pci_dev *pdev)
> }
>
> #ifndef MODULE
> -static int __init viafb_setup(char *options)
> +static int __init viafb_setup(void)
> {
> char *this_opt;
> + char *options;
> +
> DEBUG_MSG(KERN_INFO "viafb_setup!\n");
>
> + if (fb_get_options("viafb",&options))
> + return -ENODEV;
> +
> if (!options || !*options)
> return 0;
>
> @@ -2000,11 +2016,16 @@ static int __init viafb_setup(char *options)
> int __init viafb_init(void)
> {
> u32 dummy_x, dummy_y;
> + int r;
> +
> + if (machine_is_olpc())
> + /* Apply XO-1.5-specific configuration. */
> + viafb_lcd_panel_id = 23;
> +
> #ifndef MODULE
> - char *option = NULL;
> - if (fb_get_options("viafb",&option))
> - return -ENODEV;
> - viafb_setup(option);
> + r = viafb_setup();
> + if (r< 0)
> + return r;
> #endif
> if (parse_mode(viafb_mode,&dummy_x,&dummy_y)
> || !viafb_get_mode(dummy_x, dummy_y)
^ permalink raw reply
* I80 interface on S3C and manual command mode
From: Heiko Stübner @ 2011-05-15 19:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I'm working on porting a kernel to a device which has an epaper-controller
connected to the I80 interface of an S3C2416 and uses its "manual command
mode", via SIFCCON[0,1,2], as the datasheet calls it.
While digging around the mailinglists I found patches by Inki Dae that
implement the I80 basics. (cpu_mode struct and probe_win).
As there are multiple versions available in the fbdev patchwork and the i80
interface seems to have been dropped in the latest version from 2011-04 I'd
like ask if there are "final" versions laying around somewhere.
Also, to not reinvent the wheel, does an implementation of the i80 interface
[via SIFCCONx] for s3c-fb exist somewhere per chance?
Thanks
Heiko
^ permalink raw reply
* Re: [PATCH] omap: Remove support for omap2evm (Re: Updated
From: Mark Brown @ 2011-05-14 16:30 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jarkko Nikula, Russell King - ARM Linux, linux-arm-kernel,
linux-omap, Subhasish Ghosh, Srinath, Arun C, linux-fbdev,
alsa-devel, Tomi Valkeinen, Liam Girdwood, Paul Mundt
In-Reply-To: <20110513144031.GV31483@atomide.com>
On Fri, May 13, 2011 at 07:40:32AM -0700, Tony Lindgren wrote:
> Date: Fri, 13 May 2011 04:41:32 -0700
> Subject: [PATCH] omap: Remove support for omap2evm
>
> The board support has never been merged for it as noticed
> by Russell King <linux@arm.linux.org.uk>. So let's remove the
> related dead code.
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
^ permalink raw reply
* Re: [PATCH] video: mb862xxfb: Require either FB_MB862XX_PCI_GDC or
From: Anatolij Gustschin @ 2011-05-13 16:07 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1305204137.4065.394.camel@localhost>
On Thu, 12 May 2011 13:42:17 +0100
Ben Hutchings <ben@decadent.org.uk> wrote:
> The driver can be built as either a PCI or platform (OF) driver. It
> might make sense to built it as both (though that is not currently
> possible) but it certainly doesn't make sense to build it as neither!
> Add dependencies and add a choice group to ensure that exactly one of
> FB_MB862XX_PCI_GDC and FB_MB862XX_LIME is selected.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Acked-by: Anatolij Gustschin <agust@denx.de>
^ permalink raw reply
* [PATCH 5/5] video: mb862xxfb: add support for L1 displaying
From: Anatolij Gustschin @ 2011-05-13 15:54 UTC (permalink / raw)
To: linux-fbdev
Allow displaying L1 video data on top of the primary L0 layer.
The L1 layer position and dimensions can be configured and the
layer enabled/disabled by using the appropriate L1 controls
added by this patch.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
drivers/video/mb862xx/mb862xx_reg.h | 31 +++++++++
drivers/video/mb862xx/mb862xxfb.c | 116 ++++++++++++++++++++++++++++++++++-
drivers/video/mb862xx/mb862xxfb.h | 27 ++++++++
3 files changed, 173 insertions(+), 1 deletions(-)
diff --git a/drivers/video/mb862xx/mb862xx_reg.h b/drivers/video/mb862xx/mb862xx_reg.h
index 5784b01..9df48b8 100644
--- a/drivers/video/mb862xx/mb862xx_reg.h
+++ b/drivers/video/mb862xx/mb862xx_reg.h
@@ -51,10 +51,16 @@
#define GC_L0OA0 0x00000024
#define GC_L0DA0 0x00000028
#define GC_L0DY_L0DX 0x0000002c
+#define GC_L1M 0x00000030
+#define GC_L1DA 0x00000034
#define GC_DCM1 0x00000100
#define GC_L0EM 0x00000110
#define GC_L0WY_L0WX 0x00000114
#define GC_L0WH_L0WW 0x00000118
+#define GC_L1EM 0x00000120
+#define GC_L1WY_L1WX 0x00000124
+#define GC_L1WH_L1WW 0x00000128
+#define GC_DLS 0x00000180
#define GC_DCM2 0x00000104
#define GC_DCM3 0x00000108
#define GC_CPM_CUTC 0x000000a0
@@ -66,6 +72,11 @@
#define GC_CPM_CEN0 0x00100000
#define GC_CPM_CEN1 0x00200000
+#define GC_DCM1_DEN 0x80000000
+#define GC_DCM1_L1E 0x00020000
+#define GC_L1M_16 0x80000000
+#define GC_L1M_YC 0x40000000
+#define GC_L1M_CS 0x20000000
#define GC_DCM01_ESY 0x00000004
#define GC_DCM01_SC 0x00003f00
@@ -77,6 +88,7 @@
#define GC_L0M_L0C_16 0x80000000
#define GC_L0EM_L0EC_24 0x40000000
#define GC_L0M_L0W_UNIT 64
+#define GC_L1EM_DM 0x02000000
#define GC_DISP_REFCLK_400 400
@@ -101,6 +113,25 @@
#define I2C_TRX 0x80
#define I2C_LRB 0x10
+/* Capture registers and bits */
+#define GC_CAP_VCM 0x00000000
+#define GC_CAP_CSC 0x00000004
+#define GC_CAP_VCS 0x00000008
+#define GC_CAP_CBM 0x00000010
+#define GC_CAP_CBOA 0x00000014
+#define GC_CAP_CBLA 0x00000018
+#define GC_CAP_IMG_START 0x0000001C
+#define GC_CAP_IMG_END 0x00000020
+#define GC_CAP_CMSS 0x00000048
+#define GC_CAP_CMDS 0x0000004C
+
+#define GC_VCM_VIE 0x80000000
+#define GC_VCM_CM 0x03000000
+#define GC_VCM_VS_PAL 0x00000002
+#define GC_CBM_OO 0x80000000
+#define GC_CBM_HRV 0x00000010
+#define GC_CBM_CBST 0x00000001
+
/* Carmine specific */
#define MB86297_DRAW_BASE 0x00020000
#define MB86297_DISP0_BASE 0x00100000
diff --git a/drivers/video/mb862xx/mb862xxfb.c b/drivers/video/mb862xx/mb862xxfb.c
index a9779f8..c098b88 100644
--- a/drivers/video/mb862xx/mb862xxfb.c
+++ b/drivers/video/mb862xx/mb862xxfb.c
@@ -27,7 +27,7 @@
#define NR_PALETTE 256
#define MB862XX_MEM_SIZE 0x1000000
-#define CORALP_MEM_SIZE 0x4000000
+#define CORALP_MEM_SIZE 0x2000000
#define CARMINE_MEM_SIZE 0x8000000
#define DRV_NAME "mb862xxfb"
@@ -309,6 +309,97 @@ static int mb862xxfb_blank(int mode, struct fb_info *fbi)
return 0;
}
+static int mb862xxfb_ioctl(struct fb_info *fbi, unsigned int cmd,
+ unsigned long arg)
+{
+ struct mb862xxfb_par *par = fbi->par;
+ struct mb862xx_l1_cfg *l1_cfg = &par->l1_cfg;
+ void __user *argp = (void __user *)arg;
+ int *enable;
+ u32 l1em = 0;
+
+ switch (cmd) {
+ case MB862XX_L1_GET_CFG:
+ if (copy_to_user(argp, l1_cfg, sizeof(*l1_cfg)))
+ return -EFAULT;
+ break;
+ case MB862XX_L1_SET_CFG:
+ if (copy_from_user(l1_cfg, argp, sizeof(*l1_cfg)))
+ return -EFAULT;
+ if ((l1_cfg->sw >= l1_cfg->dw) && (l1_cfg->sh >= l1_cfg->dh)) {
+ /* downscaling */
+ outreg(cap, GC_CAP_CSC,
+ pack((l1_cfg->sh << 11) / l1_cfg->dh,
+ (l1_cfg->sw << 11) / l1_cfg->dw));
+ l1em = inreg(disp, GC_L1EM);
+ l1em &= ~GC_L1EM_DM;
+ } else if ((l1_cfg->sw <= l1_cfg->dw) &&
+ (l1_cfg->sh <= l1_cfg->dh)) {
+ /* upscaling */
+ outreg(cap, GC_CAP_CSC,
+ pack((l1_cfg->sh << 11) / l1_cfg->dh,
+ (l1_cfg->sw << 11) / l1_cfg->dw));
+ outreg(cap, GC_CAP_CMSS,
+ pack(l1_cfg->sw >> 1, l1_cfg->sh));
+ outreg(cap, GC_CAP_CMDS,
+ pack(l1_cfg->dw >> 1, l1_cfg->dh));
+ l1em = inreg(disp, GC_L1EM);
+ l1em |= GC_L1EM_DM;
+ }
+
+ if (l1_cfg->mirror) {
+ outreg(cap, GC_CAP_CBM,
+ inreg(cap, GC_CAP_CBM) | GC_CBM_HRV);
+ l1em |= l1_cfg->dw * 2 - 8;
+ } else {
+ outreg(cap, GC_CAP_CBM,
+ inreg(cap, GC_CAP_CBM) & ~GC_CBM_HRV);
+ l1em &= 0xffff0000;
+ }
+ outreg(disp, GC_L1EM, l1em);
+ break;
+ case MB862XX_L1_ENABLE:
+ enable = (int *)arg;
+ if (*enable) {
+ outreg(disp, GC_L1DA, par->cap_buf);
+ outreg(cap, GC_CAP_IMG_START,
+ pack(l1_cfg->sy >> 1, l1_cfg->sx));
+ outreg(cap, GC_CAP_IMG_END,
+ pack(l1_cfg->sh, l1_cfg->sw));
+ outreg(disp, GC_L1M, GC_L1M_16 | GC_L1M_YC | GC_L1M_CS |
+ (par->l1_stride << 16));
+ outreg(disp, GC_L1WY_L1WX,
+ pack(l1_cfg->dy, l1_cfg->dx));
+ outreg(disp, GC_L1WH_L1WW,
+ pack(l1_cfg->dh - 1, l1_cfg->dw));
+ outreg(disp, GC_DLS, 1);
+ outreg(cap, GC_CAP_VCM,
+ GC_VCM_VIE | GC_VCM_CM | GC_VCM_VS_PAL);
+ outreg(disp, GC_DCM1, inreg(disp, GC_DCM1) |
+ GC_DCM1_DEN | GC_DCM1_L1E);
+ } else {
+ outreg(cap, GC_CAP_VCM,
+ inreg(cap, GC_CAP_VCM) & ~GC_VCM_VIE);
+ outreg(disp, GC_DCM1,
+ inreg(disp, GC_DCM1) & ~GC_DCM1_L1E);
+ }
+ break;
+ case MB862XX_L1_CAP_CTL:
+ enable = (int *)arg;
+ if (*enable) {
+ outreg(cap, GC_CAP_VCM,
+ inreg(cap, GC_CAP_VCM) | GC_VCM_VIE);
+ } else {
+ outreg(cap, GC_CAP_VCM,
+ inreg(cap, GC_CAP_VCM) & ~GC_VCM_VIE);
+ }
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
/* framebuffer ops */
static struct fb_ops mb862xxfb_ops = {
.owner = THIS_MODULE,
@@ -320,6 +411,7 @@ static struct fb_ops mb862xxfb_ops = {
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
.fb_imageblit = cfb_imageblit,
+ .fb_ioctl = mb862xxfb_ioctl,
};
/* initialize fb_info data */
@@ -328,6 +420,7 @@ static int mb862xxfb_init_fbinfo(struct fb_info *fbi)
struct mb862xxfb_par *par = fbi->par;
struct mb862xx_gc_mode *mode = par->gc_mode;
unsigned long reg;
+ int stride;
fbi->fbops = &mb862xxfb_ops;
fbi->pseudo_palette = par->pseudo_palette;
@@ -420,6 +513,27 @@ static int mb862xxfb_init_fbinfo(struct fb_info *fbi)
fbi->fix.line_length = (fbi->var.xres_virtual *
fbi->var.bits_per_pixel) / 8;
fbi->fix.smem_len = fbi->fix.line_length * fbi->var.yres_virtual;
+
+ /*
+ * reserve space for capture buffers and two cursors
+ * at the end of vram: 720x576 * 2 * 2.2 + 64x64 * 16.
+ */
+ par->cap_buf = par->mapped_vram - 0x1bd800 - 0x10000;
+ par->cap_len = 0x1bd800;
+ par->l1_cfg.sx = 0;
+ par->l1_cfg.sy = 0;
+ par->l1_cfg.sw = 720;
+ par->l1_cfg.sh = 576;
+ par->l1_cfg.dx = 0;
+ par->l1_cfg.dy = 0;
+ par->l1_cfg.dw = 720;
+ par->l1_cfg.dh = 576;
+ stride = par->l1_cfg.sw * (fbi->var.bits_per_pixel / 8);
+ par->l1_stride = stride / 64 + ((stride % 64) ? 1 : 0);
+ outreg(cap, GC_CAP_CBM, GC_CBM_OO | GC_CBM_CBST |
+ (par->l1_stride << 16));
+ outreg(cap, GC_CAP_CBOA, par->cap_buf);
+ outreg(cap, GC_CAP_CBLA, par->cap_buf + par->cap_len);
return 0;
}
diff --git a/drivers/video/mb862xx/mb862xxfb.h b/drivers/video/mb862xx/mb862xxfb.h
index f0f57ea..12ba0f0 100644
--- a/drivers/video/mb862xx/mb862xxfb.h
+++ b/drivers/video/mb862xx/mb862xxfb.h
@@ -1,6 +1,26 @@
#ifndef __MB862XX_H__
#define __MB862XX_H__
+struct mb862xx_l1_cfg {
+ unsigned short sx;
+ unsigned short sy;
+ unsigned short sw;
+ unsigned short sh;
+ unsigned short dx;
+ unsigned short dy;
+ unsigned short dw;
+ unsigned short dh;
+ int mirror;
+};
+
+#define MB862XX_BASE 'M'
+#define MB862XX_L1_GET_CFG _IOR(MB862XX_BASE, 0, struct mb862xx_l1_cfg*)
+#define MB862XX_L1_SET_CFG _IOW(MB862XX_BASE, 1, struct mb862xx_l1_cfg*)
+#define MB862XX_L1_ENABLE _IOW(MB862XX_BASE, 2, int)
+#define MB862XX_L1_CAP_CTL _IOW(MB862XX_BASE, 3, int)
+
+#ifdef __KERNEL__
+
#define PCI_VENDOR_ID_FUJITSU_LIMITED 0x10cf
#define PCI_DEVICE_ID_FUJITSU_CORALP 0x2019
#define PCI_DEVICE_ID_FUJITSU_CORALPA 0x201e
@@ -38,6 +58,8 @@ struct mb862xxfb_par {
void __iomem *mmio_base; /* remapped registers */
size_t mapped_vram; /* length of remapped vram */
size_t mmio_len; /* length of register region */
+ unsigned long cap_buf; /* capture buffers offset */
+ size_t cap_len; /* length of capture buffers */
void __iomem *host; /* relocatable reg. bases */
void __iomem *i2c;
@@ -60,6 +82,9 @@ struct mb862xxfb_par {
struct i2c_adapter *adap; /* GDC I2C bus adapter */
int i2c_rs;
+ struct mb862xx_l1_cfg l1_cfg;
+ int l1_stride;
+
u32 pseudo_palette[16];
};
@@ -85,4 +110,6 @@ extern int mb862xx_i2c_init(struct mb862xxfb_par *par);
#define pack(a, b) (((a) << 16) | (b))
+#endif /* __KERNEL__ */
+
#endif
--
1.7.1
^ permalink raw reply related
* [PATCH 4/5] video: mb862xx: add support for controller's I2C bus adapter
From: Anatolij Gustschin @ 2011-05-13 15:54 UTC (permalink / raw)
To: linux-fbdev
Add adapter driver for I2C adapter in Coral-P(A)/Lime GDCs.
So we can easily access devices on controller's I2C bus using
i2c-dev interface.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
drivers/video/mb862xx/Makefile | 2 +-
drivers/video/mb862xx/mb862xx-i2c.c | 168 +++++++++++++++++++++++++++++++++++
drivers/video/mb862xx/mb862xx_reg.h | 21 +++++
drivers/video/mb862xx/mb862xxfb.c | 2 +
drivers/video/mb862xx/mb862xxfb.h | 3 +
5 files changed, 195 insertions(+), 1 deletions(-)
create mode 100644 drivers/video/mb862xx/mb862xx-i2c.c
diff --git a/drivers/video/mb862xx/Makefile b/drivers/video/mb862xx/Makefile
index d777771..3a36c45 100644
--- a/drivers/video/mb862xx/Makefile
+++ b/drivers/video/mb862xx/Makefile
@@ -2,4 +2,4 @@
# Makefile for the MB862xx framebuffer driver
#
-obj-$(CONFIG_FB_MB862XX) := mb862xxfb.o mb862xxfb_accel.o
+obj-$(CONFIG_FB_MB862XX) := mb862xxfb.o mb862xxfb_accel.o mb862xx-i2c.o
diff --git a/drivers/video/mb862xx/mb862xx-i2c.c b/drivers/video/mb862xx/mb862xx-i2c.c
new file mode 100644
index 0000000..d50cc71
--- /dev/null
+++ b/drivers/video/mb862xx/mb862xx-i2c.c
@@ -0,0 +1,168 @@
+/*
+ * Coral-P(A)/Lime I2C adapter driver
+ *
+ * (C) 2011 DENX Software Engineering, Anatolij Gustschin <agust@denx.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/fb.h>
+#include <linux/i2c.h>
+#include <linux/io.h>
+
+#include "mb862xxfb.h"
+#include "mb862xx_reg.h"
+
+static int mb862xx_i2c_wait_event(struct i2c_adapter *adap)
+{
+ struct mb862xxfb_par *par = adap->algo_data;
+ u32 reg;
+
+ do {
+ reg = inreg(i2c, GC_I2C_BCR);
+ if (reg & (I2C_INT | I2C_BER))
+ break;
+ } while (1);
+
+ return (reg & I2C_BER) ? 0 : 1;
+}
+
+static int mb862xx_i2c_do_address(struct i2c_adapter *adap, int addr)
+{
+ struct mb862xxfb_par *par = adap->algo_data;
+
+ outreg(i2c, GC_I2C_DAR, addr);
+ outreg(i2c, GC_I2C_CCR, I2C_CLOCK_AND_ENABLE);
+ outreg(i2c, GC_I2C_BCR, par->i2c_rs ? I2C_REPEATED_START : I2C_START);
+ if (!mb862xx_i2c_wait_event(adap))
+ return -EIO;
+ par->i2c_rs = !(inreg(i2c, GC_I2C_BSR) & I2C_LRB);
+ return par->i2c_rs;
+}
+
+static int mb862xx_i2c_write_byte(struct i2c_adapter *adap, u8 byte)
+{
+ struct mb862xxfb_par *par = adap->algo_data;
+
+ outreg(i2c, GC_I2C_DAR, byte);
+ outreg(i2c, GC_I2C_BCR, I2C_START);
+ if (!mb862xx_i2c_wait_event(adap))
+ return -EIO;
+ return !(inreg(i2c, GC_I2C_BSR) & I2C_LRB);
+}
+
+static int mb862xx_i2c_read_byte(struct i2c_adapter *adap, u8 *byte, int last)
+{
+ struct mb862xxfb_par *par = adap->algo_data;
+
+ outreg(i2c, GC_I2C_BCR, I2C_START | (last ? 0 : I2C_ACK));
+ if (!mb862xx_i2c_wait_event(adap))
+ return 0;
+ *byte = inreg(i2c, GC_I2C_DAR);
+ return 1;
+}
+
+void mb862xx_i2c_stop(struct i2c_adapter *adap)
+{
+ struct mb862xxfb_par *par = adap->algo_data;
+
+ outreg(i2c, GC_I2C_BCR, I2C_STOP);
+ outreg(i2c, GC_I2C_CCR, I2C_DISABLE);
+ par->i2c_rs = 0;
+}
+
+static int mb862xx_i2c_read(struct i2c_adapter *adap, struct i2c_msg *m)
+{
+ int i, ret = 0;
+ int last = m->len - 1;
+
+ for (i = 0; i < m->len; i++) {
+ if (!mb862xx_i2c_read_byte(adap, &m->buf[i], i = last)) {
+ ret = -EIO;
+ break;
+ }
+ }
+ return ret;
+}
+
+static int mb862xx_i2c_write(struct i2c_adapter *adap, struct i2c_msg *m)
+{
+ int i, ret = 0;
+
+ for (i = 0; i < m->len; i++) {
+ if (!mb862xx_i2c_write_byte(adap, m->buf[i])) {
+ ret = -EIO;
+ break;
+ }
+ }
+ return ret;
+}
+
+static int mb862xx_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
+ int num)
+{
+ struct mb862xxfb_par *par = adap->algo_data;
+ struct i2c_msg *m;
+ int addr;
+ int i = 0, err = 0;
+
+ dev_dbg(par->dev, "%s: %d msgs\n", __func__, num);
+
+ for (i = 0; i < num; i++) {
+ m = &msgs[i];
+ if (!m->len) {
+ dev_dbg(par->dev, "%s: null msgs\n", __func__);
+ continue;
+ }
+ addr = m->addr;
+ if (m->flags & I2C_M_RD)
+ addr |= 1;
+
+ err = mb862xx_i2c_do_address(adap, addr);
+ if (err < 0)
+ break;
+ if (m->flags & I2C_M_RD)
+ err = mb862xx_i2c_read(adap, m);
+ else
+ err = mb862xx_i2c_write(adap, m);
+ }
+
+ if (i)
+ mb862xx_i2c_stop(adap);
+
+ return (err < 0) ? err : i;
+}
+
+static u32 mb862xx_func(struct i2c_adapter *adap)
+{
+ return I2C_FUNC_SMBUS_BYTE_DATA;
+}
+
+static const struct i2c_algorithm mb862xx_algo = {
+ .master_xfer = mb862xx_xfer,
+ .functionality = mb862xx_func,
+};
+
+static struct i2c_adapter mb862xx_i2c_adapter = {
+ .name = "MB862xx I2C adapter",
+ .algo = &mb862xx_algo,
+ .owner = THIS_MODULE,
+};
+
+int mb862xx_i2c_init(struct mb862xxfb_par *par)
+{
+ int ret;
+
+ mb862xx_i2c_adapter.algo_data = par;
+ par->adap = &mb862xx_i2c_adapter;
+
+ ret = i2c_add_adapter(par->adap);
+ if (ret < 0) {
+ dev_err(par->dev, "failed to add %s\n",
+ mb862xx_i2c_adapter.name);
+ }
+ return ret;
+}
diff --git a/drivers/video/mb862xx/mb862xx_reg.h b/drivers/video/mb862xx/mb862xx_reg.h
index 737fc01..5784b01 100644
--- a/drivers/video/mb862xx/mb862xx_reg.h
+++ b/drivers/video/mb862xx/mb862xx_reg.h
@@ -80,6 +80,27 @@
#define GC_DISP_REFCLK_400 400
+/* I2C */
+#define GC_I2C_BSR 0x00000000 /* BSR */
+#define GC_I2C_BCR 0x00000004 /* BCR */
+#define GC_I2C_CCR 0x00000008 /* CCR */
+#define GC_I2C_ADR 0x0000000C /* ADR */
+#define GC_I2C_DAR 0x00000010 /* DAR */
+
+#define I2C_DISABLE 0x00000000
+#define I2C_STOP 0x00000000
+#define I2C_START 0x00000010
+#define I2C_REPEATED_START 0x00000030
+#define I2C_CLOCK_AND_ENABLE 0x0000003f
+#define I2C_READY 0x01
+#define I2C_INT 0x01
+#define I2C_INTE 0x02
+#define I2C_ACK 0x08
+#define I2C_BER 0x80
+#define I2C_BEIE 0x40
+#define I2C_TRX 0x80
+#define I2C_LRB 0x10
+
/* Carmine specific */
#define MB86297_DRAW_BASE 0x00020000
#define MB86297_DISP0_BASE 0x00100000
diff --git a/drivers/video/mb862xx/mb862xxfb.c b/drivers/video/mb862xx/mb862xxfb.c
index ffb6a2c..a9779f8 100644
--- a/drivers/video/mb862xx/mb862xxfb.c
+++ b/drivers/video/mb862xx/mb862xxfb.c
@@ -772,6 +772,8 @@ static int coralp_init(struct mb862xxfb_par *par)
} else {
return -ENODEV;
}
+
+ mb862xx_i2c_init(par);
return 0;
}
diff --git a/drivers/video/mb862xx/mb862xxfb.h b/drivers/video/mb862xx/mb862xxfb.h
index d7e7cb7..f0f57ea 100644
--- a/drivers/video/mb862xx/mb862xxfb.h
+++ b/drivers/video/mb862xx/mb862xxfb.h
@@ -57,11 +57,14 @@ struct mb862xxfb_par {
unsigned int refclk; /* disp. reference clock */
struct mb862xx_gc_mode *gc_mode; /* GDC mode init data */
int pre_init; /* don't init display if 1 */
+ struct i2c_adapter *adap; /* GDC I2C bus adapter */
+ int i2c_rs;
u32 pseudo_palette[16];
};
extern void mb862xxfb_init_accel(struct fb_info *info, int xres);
+extern int mb862xx_i2c_init(struct mb862xxfb_par *par);
#if defined(CONFIG_FB_MB862XX_LIME) && defined(CONFIG_FB_MB862XX_PCI_GDC)
#error "Select Lime GDC or CoralP/Carmine support, but not both together"
--
1.7.1
^ permalink raw reply related
* [PATCH 3/5] video: mb862xxfb: relocate register space to get contiguous vram
From: Anatolij Gustschin @ 2011-05-13 15:54 UTC (permalink / raw)
To: linux-fbdev
By default the GDC registers are located in the middle of the 64MiB
area for video RAM and registers. When 32MiB VRAM or more is used,
relocate the register space to the top of the 64MiB space so that
we get the contiguous VRAM for GDC frame buffer layers, drawing
frames, capture and cursor buffers.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
drivers/video/mb862xx/mb862xx_reg.h | 6 ++----
drivers/video/mb862xx/mb862xxfb.c | 14 +++++++++++++-
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/video/mb862xx/mb862xx_reg.h b/drivers/video/mb862xx/mb862xx_reg.h
index 2ba65e1..737fc01 100644
--- a/drivers/video/mb862xx/mb862xx_reg.h
+++ b/drivers/video/mb862xx/mb862xx_reg.h
@@ -5,11 +5,8 @@
#ifndef _MB862XX_REG_H
#define _MB862XX_REG_H
-#ifdef MB862XX_MMIO_BOTTOM
-#define MB862XX_MMIO_BASE 0x03fc0000
-#else
#define MB862XX_MMIO_BASE 0x01fc0000
-#endif
+#define MB862XX_MMIO_HIGH_BASE 0x03fc0000
#define MB862XX_I2C_BASE 0x0000c000
#define MB862XX_DISP_BASE 0x00010000
#define MB862XX_CAP_BASE 0x00018000
@@ -23,6 +20,7 @@
#define GC_IMASK 0x00000024
#define GC_SRST 0x0000002c
#define GC_CCF 0x00000038
+#define GC_RSW 0x0000005c
#define GC_CID 0x000000f0
#define GC_REVISION 0x00000084
diff --git a/drivers/video/mb862xx/mb862xxfb.c b/drivers/video/mb862xx/mb862xxfb.c
index a1b81e7..ffb6a2c 100644
--- a/drivers/video/mb862xx/mb862xxfb.c
+++ b/drivers/video/mb862xx/mb862xxfb.c
@@ -742,6 +742,12 @@ static int coralp_init(struct mb862xxfb_par *par)
par->refclk = GC_DISP_REFCLK_400;
+ if (par->mapped_vram >= 0x2000000) {
+ /* relocate gdc registers space */
+ writel(1, par->fb_base + MB862XX_MMIO_BASE + GC_RSW);
+ udelay(1); /* wait at least 20 bus cycles */
+ }
+
ver = inreg(host, GC_CID);
cn = (ver & GC_CID_CNAME_MSK) >> 8;
ver = ver & GC_CID_VERSION_MSK;
@@ -907,7 +913,13 @@ static int __devinit mb862xx_pci_probe(struct pci_dev *pdev,
case PCI_DEVICE_ID_FUJITSU_CORALPA:
par->fb_base_phys = pci_resource_start(par->pdev, 0);
par->mapped_vram = CORALP_MEM_SIZE;
- par->mmio_base_phys = par->fb_base_phys + MB862XX_MMIO_BASE;
+ if (par->mapped_vram >= 0x2000000) {
+ par->mmio_base_phys = par->fb_base_phys +
+ MB862XX_MMIO_HIGH_BASE;
+ } else {
+ par->mmio_base_phys = par->fb_base_phys +
+ MB862XX_MMIO_BASE;
+ }
par->mmio_len = MB862XX_MMIO_SIZE;
par->type = BT_CORALP;
break;
--
1.7.1
^ permalink raw reply related
* [PATCH 2/5] video: mb862xxfb: use pre-initialized configuration for PCI GDCs
From: Anatolij Gustschin @ 2011-05-13 15:54 UTC (permalink / raw)
To: linux-fbdev
If the bootloader has already initialized the display
controller, do not re-initialize it in the driver. Take over
the bootloader's configuration instead. This is already supported
for non PCI GDCs Lime and Mint. Add this functionality for PCI
GDCs Coral-P and Coral-PA. It is useful to avoid flicker and
also avoids unneeded init delays while booting.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
drivers/video/mb862xx/mb862xxfb.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/video/mb862xx/mb862xxfb.c b/drivers/video/mb862xx/mb862xxfb.c
index 8257958..a1b81e7 100644
--- a/drivers/video/mb862xx/mb862xxfb.c
+++ b/drivers/video/mb862xx/mb862xxfb.c
@@ -746,13 +746,21 @@ static int coralp_init(struct mb862xxfb_par *par)
cn = (ver & GC_CID_CNAME_MSK) >> 8;
ver = ver & GC_CID_VERSION_MSK;
if (cn = 3) {
+ unsigned long reg;
+
dev_info(par->dev, "Fujitsu Coral-%s GDC Rev.%d found\n",\
(ver = 6) ? "P" : (ver = 8) ? "PA" : "?",
par->pdev->revision);
- outreg(host, GC_CCF, GC_CCF_CGE_166 | GC_CCF_COT_133);
- udelay(200);
- outreg(host, GC_MMR, GC_MMR_CORALP_EVB_VAL);
- udelay(10);
+ reg = inreg(disp, GC_DCM1);
+ if (reg & GC_DCM01_DEN && reg & GC_DCM01_L0E)
+ par->pre_init = 1;
+
+ if (!par->pre_init) {
+ outreg(host, GC_CCF, GC_CCF_CGE_166 | GC_CCF_COT_133);
+ udelay(200);
+ outreg(host, GC_MMR, GC_MMR_CORALP_EVB_VAL);
+ udelay(10);
+ }
/* Clear interrupt status */
outreg(host, GC_IST, 0);
} else {
--
1.7.1
^ permalink raw reply related
* [PATCH 1/5] video: mb862xxfb: correct fix.smem_len field initialization
From: Anatolij Gustschin @ 2011-05-13 15:54 UTC (permalink / raw)
To: linux-fbdev
Initialize smem_len field to the actual frame buffer size and
not to the whole video RAM size. This prevents overwriting
other video memory (which could be used by other layers, cursors
or accelerated drivers) by frame buffer applications relying on
fix.smem_len.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
drivers/video/mb862xx/mb862xxfb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/mb862xx/mb862xxfb.c b/drivers/video/mb862xx/mb862xxfb.c
index c76e663..8257958 100644
--- a/drivers/video/mb862xx/mb862xxfb.c
+++ b/drivers/video/mb862xx/mb862xxfb.c
@@ -336,7 +336,6 @@ static int mb862xxfb_init_fbinfo(struct fb_info *fbi)
strcpy(fbi->fix.id, DRV_NAME);
fbi->fix.smem_start = (unsigned long)par->fb_base_phys;
- fbi->fix.smem_len = par->mapped_vram;
fbi->fix.mmio_start = (unsigned long)par->mmio_base_phys;
fbi->fix.mmio_len = par->mmio_len;
fbi->fix.accel = FB_ACCEL_NONE;
@@ -420,6 +419,7 @@ static int mb862xxfb_init_fbinfo(struct fb_info *fbi)
FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;
fbi->fix.line_length = (fbi->var.xres_virtual *
fbi->var.bits_per_pixel) / 8;
+ fbi->fix.smem_len = fbi->fix.line_length * fbi->var.yres_virtual;
return 0;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 0/5] mb862xxfb driver update for 2.6.40
From: Anatolij Gustschin @ 2011-05-13 15:54 UTC (permalink / raw)
To: linux-fbdev
This patch series extends the driver for Coral GDCs to support
such controller features as video layer L1 and I2C bus for video
decoder chips. First three patches are small fixes and improvements.
These patches can also be pulled from
git://git.denx.de/linux-2.6-agust.git mb862xxfb-for-next
Anatolij Gustschin (5):
video: mb862xxfb: correct fix.smem_len field initialization
video: mb862xxfb: use pre-initialized configuration for PCI GDCs
video: mb862xxfb: relocate register space to get contiguous vram
video: mb862xx: add support for controller's I2C bus adapter
video: mb862xxfb: add support for L1 displaying
drivers/video/mb862xx/Makefile | 2 +-
drivers/video/mb862xx/mb862xx-i2c.c | 168 +++++++++++++++++++++++++++++++++++
drivers/video/mb862xx/mb862xx_reg.h | 58 +++++++++++-
drivers/video/mb862xx/mb862xxfb.c | 150 +++++++++++++++++++++++++++++--
drivers/video/mb862xx/mb862xxfb.h | 30 ++++++
5 files changed, 396 insertions(+), 12 deletions(-)
create mode 100644 drivers/video/mb862xx/mb862xx-i2c.c
^ permalink raw reply
* Re: Updated mach-types update
From: Tomi Valkeinen @ 2011-05-13 14:53 UTC (permalink / raw)
To: Tony Lindgren
Cc: Russell King - ARM Linux, linux-arm-kernel, linux-omap,
Subhasish Ghosh, Srinath, Arun C, linux-fbdev, alsa-devel,
Jarkko Nikula
In-Reply-To: <20110513115406.GQ31483@atomide.com>
On Fri, 2011-05-13 at 04:54 -0700, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [110324 10:57]:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110320 04:39]:
> > > On Sun, Mar 20, 2011 at 11:03:22AM +0000, Russell King - ARM Linux wrote:
> > >
> > > Note that OMAP references machine_is_omap2evm() yet this has never been
> > > merged.
> > >
> > > arch/arm/plat-omap/include/plat/uncompress.h:
> > >
> > > DEBUG_LL_OMAP2(1, omap2evm);
> > >
> > > so this entry needs to be removed.
> >
> > Hmm looks like we have LCD support and ASoC support for it, but no
> > board :)
> >
> > Anybody working with this board?
> >
> > If so, please send patches for the related board-*.c support ASAP.
> > Otherwise let's plan on deleting the related support.
>
> No patches, so let's remove it. Here's the patch to do that,
> I'm planning to add this to my devel-cleanup branch.
For removing the lcd driver:
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tomi
^ permalink raw reply
* [PATCH] omap: Remove support for omap2evm (Re: Updated mach-types
From: Tony Lindgren @ 2011-05-13 14:40 UTC (permalink / raw)
To: Jarkko Nikula
Cc: Russell King - ARM Linux, linux-arm-kernel, linux-omap,
Subhasish Ghosh, Srinath, Arun C, linux-fbdev, alsa-devel,
Tomi Valkeinen, Mark Brown, Liam Girdwood, Paul Mundt
In-Reply-To: <20110513151916.77eba011.jhnikula@gmail.com>
* Jarkko Nikula <jhnikula@gmail.com> [110513 05:15]:
> On Fri, 13 May 2011 04:54:07 -0700
> Tony Lindgren <tony@atomide.com> wrote:
>
> > * Tony Lindgren <tony@atomide.com> [110324 10:57]:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110320 04:39]:
> > > > On Sun, Mar 20, 2011 at 11:03:22AM +0000, Russell King - ARM Linux wrote:
> > > >
> > > > Note that OMAP references machine_is_omap2evm() yet this has never been
> > > > merged.
> > > >
> > > > arch/arm/plat-omap/include/plat/uncompress.h:
> > > >
> > > > DEBUG_LL_OMAP2(1, omap2evm);
> > > >
> > > > so this entry needs to be removed.
> > >
> > > Hmm looks like we have LCD support and ASoC support for it, but no
> > > board :)
> > >
> > > Anybody working with this board?
> > >
> > > If so, please send patches for the related board-*.c support ASAP.
> > > Otherwise let's plan on deleting the related support.
> >
> > No patches, so let's remove it. Here's the patch to do that,
> > I'm planning to add this to my devel-cleanup branch.
> >
> Remove also from sound/soc/omap/Kconfig as well. You could put my
> ack for sound/soc/omap part but remember cc also Mark and Liam.
Thanks, here's the updated patch.
Regards,
Tony
From: Tony Lindgren <tony@atomide.com>
Date: Fri, 13 May 2011 04:41:32 -0700
Subject: [PATCH] omap: Remove support for omap2evm
The board support has never been merged for it as noticed
by Russell King <linux@arm.linux.org.uk>. So let's remove the
related dead code.
Cc: linux-fbdev@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-omap/include/plat/uncompress.h
index 30b891c..2b576f1 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -129,7 +129,6 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
DEBUG_LL_OMAP1(3, sx1);
/* omap2 based boards using UART1 */
- DEBUG_LL_OMAP2(1, omap2evm);
DEBUG_LL_OMAP2(1, omap_2430sdp);
DEBUG_LL_OMAP2(1, omap_apollon);
DEBUG_LL_OMAP2(1, omap_h4);
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index 49226a1..25db556 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -30,7 +30,6 @@ objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o
objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o
objs-y$(CONFIG_MACH_OMAP_LDP) += lcd_ldp.o
-objs-y$(CONFIG_MACH_OMAP2EVM) += lcd_omap2evm.o
objs-y$(CONFIG_MACH_OMAP3EVM) += lcd_omap3evm.o
objs-y$(CONFIG_MACH_OMAP3_BEAGLE) += lcd_omap3beagle.o
objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
diff --git a/drivers/video/omap/lcd_omap2evm.c b/drivers/video/omap/lcd_omap2evm.c
deleted file mode 100644
index 7e7a65c..0000000
--- a/drivers/video/omap/lcd_omap2evm.c
+++ /dev/null
@@ -1,192 +0,0 @@
-/*
- * LCD panel support for the MISTRAL OMAP2EVM board
- *
- * Author: Arun C <arunedarath@mistralsolutions.com>
- *
- * Derived from drivers/video/omap/lcd_omap3evm.c
- * Derived from drivers/video/omap/lcd-apollon.c
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#include <linux/module.h>
-#include <linux/platform_device.h>
-#include <linux/gpio.h>
-#include <linux/i2c/twl.h>
-
-#include <plat/mux.h>
-#include <asm/mach-types.h>
-
-#include "omapfb.h"
-
-#define LCD_PANEL_ENABLE_GPIO 154
-#define LCD_PANEL_LR 128
-#define LCD_PANEL_UD 129
-#define LCD_PANEL_INI 152
-#define LCD_PANEL_QVGA 148
-#define LCD_PANEL_RESB 153
-
-#define TWL_LED_LEDEN 0x00
-#define TWL_PWMA_PWMAON 0x00
-#define TWL_PWMA_PWMAOFF 0x01
-
-static unsigned int bklight_level;
-
-static int omap2evm_panel_init(struct lcd_panel *panel,
- struct omapfb_device *fbdev)
-{
- gpio_request(LCD_PANEL_ENABLE_GPIO, "LCD enable");
- gpio_request(LCD_PANEL_LR, "LCD lr");
- gpio_request(LCD_PANEL_UD, "LCD ud");
- gpio_request(LCD_PANEL_INI, "LCD ini");
- gpio_request(LCD_PANEL_QVGA, "LCD qvga");
- gpio_request(LCD_PANEL_RESB, "LCD resb");
-
- gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 1);
- gpio_direction_output(LCD_PANEL_RESB, 1);
- gpio_direction_output(LCD_PANEL_INI, 1);
- gpio_direction_output(LCD_PANEL_QVGA, 0);
- gpio_direction_output(LCD_PANEL_LR, 1);
- gpio_direction_output(LCD_PANEL_UD, 1);
-
- twl_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL_LED_LEDEN);
- twl_i2c_write_u8(TWL4030_MODULE_PWMA, 0x01, TWL_PWMA_PWMAON);
- twl_i2c_write_u8(TWL4030_MODULE_PWMA, 0x02, TWL_PWMA_PWMAOFF);
- bklight_level = 100;
-
- return 0;
-}
-
-static void omap2evm_panel_cleanup(struct lcd_panel *panel)
-{
- gpio_free(LCD_PANEL_RESB);
- gpio_free(LCD_PANEL_QVGA);
- gpio_free(LCD_PANEL_INI);
- gpio_free(LCD_PANEL_UD);
- gpio_free(LCD_PANEL_LR);
- gpio_free(LCD_PANEL_ENABLE_GPIO);
-}
-
-static int omap2evm_panel_enable(struct lcd_panel *panel)
-{
- gpio_set_value(LCD_PANEL_ENABLE_GPIO, 0);
- return 0;
-}
-
-static void omap2evm_panel_disable(struct lcd_panel *panel)
-{
- gpio_set_value(LCD_PANEL_ENABLE_GPIO, 1);
-}
-
-static unsigned long omap2evm_panel_get_caps(struct lcd_panel *panel)
-{
- return 0;
-}
-
-static int omap2evm_bklight_setlevel(struct lcd_panel *panel,
- unsigned int level)
-{
- u8 c;
- if ((level >= 0) && (level <= 100)) {
- c = (125 * (100 - level)) / 100 + 2;
- twl_i2c_write_u8(TWL4030_MODULE_PWMA, c, TWL_PWMA_PWMAOFF);
- bklight_level = level;
- }
- return 0;
-}
-
-static unsigned int omap2evm_bklight_getlevel(struct lcd_panel *panel)
-{
- return bklight_level;
-}
-
-static unsigned int omap2evm_bklight_getmaxlevel(struct lcd_panel *panel)
-{
- return 100;
-}
-
-struct lcd_panel omap2evm_panel = {
- .name = "omap2evm",
- .config = OMAP_LCDC_PANEL_TFT | OMAP_LCDC_INV_VSYNC |
- OMAP_LCDC_INV_HSYNC,
-
- .bpp = 16,
- .data_lines = 18,
- .x_res = 480,
- .y_res = 640,
- .hsw = 3,
- .hfp = 0,
- .hbp = 28,
- .vsw = 2,
- .vfp = 1,
- .vbp = 0,
-
- .pixel_clock = 20000,
-
- .init = omap2evm_panel_init,
- .cleanup = omap2evm_panel_cleanup,
- .enable = omap2evm_panel_enable,
- .disable = omap2evm_panel_disable,
- .get_caps = omap2evm_panel_get_caps,
- .set_bklight_level = omap2evm_bklight_setlevel,
- .get_bklight_level = omap2evm_bklight_getlevel,
- .get_bklight_max = omap2evm_bklight_getmaxlevel,
-};
-
-static int omap2evm_panel_probe(struct platform_device *pdev)
-{
- omapfb_register_panel(&omap2evm_panel);
- return 0;
-}
-
-static int omap2evm_panel_remove(struct platform_device *pdev)
-{
- return 0;
-}
-
-static int omap2evm_panel_suspend(struct platform_device *pdev,
- pm_message_t mesg)
-{
- return 0;
-}
-
-static int omap2evm_panel_resume(struct platform_device *pdev)
-{
- return 0;
-}
-
-struct platform_driver omap2evm_panel_driver = {
- .probe = omap2evm_panel_probe,
- .remove = omap2evm_panel_remove,
- .suspend = omap2evm_panel_suspend,
- .resume = omap2evm_panel_resume,
- .driver = {
- .name = "omap2evm_lcd",
- .owner = THIS_MODULE,
- },
-};
-
-static int __init omap2evm_panel_drv_init(void)
-{
- return platform_driver_register(&omap2evm_panel_driver);
-}
-
-static void __exit omap2evm_panel_drv_exit(void)
-{
- platform_driver_unregister(&omap2evm_panel_driver);
-}
-
-module_init(omap2evm_panel_drv_init);
-module_exit(omap2evm_panel_drv_exit);
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index b592298..99054cf 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -65,14 +65,6 @@ config SND_OMAP_SOC_OVERO
Say Y if you want to add support for SoC audio on the
Gumstix Overo or CompuLab CM-T35
-config SND_OMAP_SOC_OMAP2EVM
- tristate "SoC Audio support for OMAP2EVM board"
- depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP2EVM
- select SND_OMAP_SOC_MCBSP
- select SND_SOC_TWL4030
- help
- Say Y if you want to add support for SoC audio on the omap2evm board.
-
config SND_OMAP_SOC_OMAP3EVM
tristate "SoC Audio support for OMAP3EVM board"
depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP3EVM
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index ba9fc65..6c2c87e 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -13,7 +13,6 @@ snd-soc-rx51-objs := rx51.o
snd-soc-ams-delta-objs := ams-delta.o
snd-soc-osk5912-objs := osk5912.o
snd-soc-overo-objs := overo.o
-snd-soc-omap2evm-objs := omap2evm.o
snd-soc-omap3evm-objs := omap3evm.o
snd-soc-am3517evm-objs := am3517evm.o
snd-soc-sdp3430-objs := sdp3430.o
diff --git a/sound/soc/omap/omap2evm.c b/sound/soc/omap/omap2evm.c
deleted file mode 100644
index 29b60d6..0000000
--- a/sound/soc/omap/omap2evm.c
+++ /dev/null
@@ -1,139 +0,0 @@
-/*
- * omap2evm.c -- SoC audio machine driver for omap2evm board
- *
- * Author: Arun KS <arunks@mistralsolutions.com>
- *
- * Based on sound/soc/omap/overo.c by Steve Sakoman
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#include <linux/clk.h>
-#include <linux/platform_device.h>
-#include <sound/core.h>
-#include <sound/pcm.h>
-#include <sound/soc.h>
-
-#include <asm/mach-types.h>
-#include <mach/hardware.h>
-#include <mach/gpio.h>
-#include <plat/mcbsp.h>
-
-#include "omap-mcbsp.h"
-#include "omap-pcm.h"
-
-static int omap2evm_hw_params(struct snd_pcm_substream *substream,
- struct snd_pcm_hw_params *params)
-{
- struct snd_soc_pcm_runtime *rtd = substream->private_data;
- struct snd_soc_dai *codec_dai = rtd->codec_dai;
- struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
- int ret;
-
- /* Set codec DAI configuration */
- ret = snd_soc_dai_set_fmt(codec_dai,
- SND_SOC_DAIFMT_I2S |
- SND_SOC_DAIFMT_NB_NF |
- SND_SOC_DAIFMT_CBM_CFM);
- if (ret < 0) {
- printk(KERN_ERR "can't set codec DAI configuration\n");
- return ret;
- }
-
- /* Set cpu DAI configuration */
- ret = snd_soc_dai_set_fmt(cpu_dai,
- SND_SOC_DAIFMT_I2S |
- SND_SOC_DAIFMT_NB_NF |
- SND_SOC_DAIFMT_CBM_CFM);
- if (ret < 0) {
- printk(KERN_ERR "can't set cpu DAI configuration\n");
- return ret;
- }
-
- /* Set the codec system clock for DAC and ADC */
- ret = snd_soc_dai_set_sysclk(codec_dai, 0, 26000000,
- SND_SOC_CLOCK_IN);
- if (ret < 0) {
- printk(KERN_ERR "can't set codec system clock\n");
- return ret;
- }
-
- return 0;
-}
-
-static struct snd_soc_ops omap2evm_ops = {
- .hw_params = omap2evm_hw_params,
-};
-
-/* Digital audio interface glue - connects codec <--> CPU */
-static struct snd_soc_dai_link omap2evm_dai = {
- .name = "TWL4030",
- .stream_name = "TWL4030",
- .cpu_dai_name = "omap-mcbsp-dai.1",
- .codec_dai_name = "twl4030-hifi",
- .platform_name = "omap-pcm-audio",
- .codec_name = "twl4030-codec",
- .ops = &omap2evm_ops,
-};
-
-/* Audio machine driver */
-static struct snd_soc_card snd_soc_omap2evm = {
- .name = "omap2evm",
- .dai_link = &omap2evm_dai,
- .num_links = 1,
-};
-
-static struct platform_device *omap2evm_snd_device;
-
-static int __init omap2evm_soc_init(void)
-{
- int ret;
-
- if (!machine_is_omap2evm())
- return -ENODEV;
- printk(KERN_INFO "omap2evm SoC init\n");
-
- omap2evm_snd_device = platform_device_alloc("soc-audio", -1);
- if (!omap2evm_snd_device) {
- printk(KERN_ERR "Platform device allocation failed\n");
- return -ENOMEM;
- }
-
- platform_set_drvdata(omap2evm_snd_device, &snd_soc_omap2evm);
-
- ret = platform_device_add(omap2evm_snd_device);
- if (ret)
- goto err1;
-
- return 0;
-
-err1:
- printk(KERN_ERR "Unable to add platform device\n");
- platform_device_put(omap2evm_snd_device);
-
- return ret;
-}
-module_init(omap2evm_soc_init);
-
-static void __exit omap2evm_soc_exit(void)
-{
- platform_device_unregister(omap2evm_snd_device);
-}
-module_exit(omap2evm_soc_exit);
-
-MODULE_AUTHOR("Arun KS <arunks@mistralsolutions.com>");
-MODULE_DESCRIPTION("ALSA SoC omap2evm");
-MODULE_LICENSE("GPL");
^ permalink raw reply related
* Re: Updated mach-types update
From: Jarkko Nikula @ 2011-05-13 12:19 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-fbdev, Russell King - ARM Linux, Ghosh, Srinath, alsa-devel,
Tomi Valkeinen, Arun C, linux-omap, linux-arm-kernel, Subhasish
In-Reply-To: <20110513115406.GQ31483@atomide.com>
On Fri, 13 May 2011 04:54:07 -0700
Tony Lindgren <tony@atomide.com> wrote:
> * Tony Lindgren <tony@atomide.com> [110324 10:57]:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110320 04:39]:
> > > On Sun, Mar 20, 2011 at 11:03:22AM +0000, Russell King - ARM Linux wrote:
> > >
> > > Note that OMAP references machine_is_omap2evm() yet this has never been
> > > merged.
> > >
> > > arch/arm/plat-omap/include/plat/uncompress.h:
> > >
> > > DEBUG_LL_OMAP2(1, omap2evm);
> > >
> > > so this entry needs to be removed.
> >
> > Hmm looks like we have LCD support and ASoC support for it, but no
> > board :)
> >
> > Anybody working with this board?
> >
> > If so, please send patches for the related board-*.c support ASAP.
> > Otherwise let's plan on deleting the related support.
>
> No patches, so let's remove it. Here's the patch to do that,
> I'm planning to add this to my devel-cleanup branch.
>
Remove also from sound/soc/omap/Kconfig as well. You could put my
ack for sound/soc/omap part but remember cc also Mark and Liam.
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
^ permalink raw reply
* Re: Updated mach-types update
From: Tony Lindgren @ 2011-05-13 11:54 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-arm-kernel, linux-omap, Subhasish Ghosh, Srinath, Arun C,
linux-fbdev, alsa-devel, Tomi Valkeinen, Jarkko Nikula
In-Reply-To: <20110324175945.GV2811@atomide.com>
* Tony Lindgren <tony@atomide.com> [110324 10:57]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110320 04:39]:
> > On Sun, Mar 20, 2011 at 11:03:22AM +0000, Russell King - ARM Linux wrote:
> >
> > Note that OMAP references machine_is_omap2evm() yet this has never been
> > merged.
> >
> > arch/arm/plat-omap/include/plat/uncompress.h:
> >
> > DEBUG_LL_OMAP2(1, omap2evm);
> >
> > so this entry needs to be removed.
>
> Hmm looks like we have LCD support and ASoC support for it, but no
> board :)
>
> Anybody working with this board?
>
> If so, please send patches for the related board-*.c support ASAP.
> Otherwise let's plan on deleting the related support.
No patches, so let's remove it. Here's the patch to do that,
I'm planning to add this to my devel-cleanup branch.
Regards,
Tony
From: Tony Lindgren <tony@atomide.com>
Date: Fri, 13 May 2011 04:41:32 -0700
Subject: [PATCH] omap: Remove support for omap2evm
The board support has never been merged for it as noticed
by Russell King <linux@arm.linux.org.uk>. So let's remove the
related dead code.
Cc: linux-fbdev@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-omap/include/plat/uncompress.h
index 30b891c..2b576f1 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -129,7 +129,6 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
DEBUG_LL_OMAP1(3, sx1);
/* omap2 based boards using UART1 */
- DEBUG_LL_OMAP2(1, omap2evm);
DEBUG_LL_OMAP2(1, omap_2430sdp);
DEBUG_LL_OMAP2(1, omap_apollon);
DEBUG_LL_OMAP2(1, omap_h4);
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index 49226a1..25db556 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -30,7 +30,6 @@ objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o
objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o
objs-y$(CONFIG_MACH_OMAP_LDP) += lcd_ldp.o
-objs-y$(CONFIG_MACH_OMAP2EVM) += lcd_omap2evm.o
objs-y$(CONFIG_MACH_OMAP3EVM) += lcd_omap3evm.o
objs-y$(CONFIG_MACH_OMAP3_BEAGLE) += lcd_omap3beagle.o
objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
diff --git a/drivers/video/omap/lcd_omap2evm.c b/drivers/video/omap/lcd_omap2evm.c
deleted file mode 100644
index 7e7a65c..0000000
--- a/drivers/video/omap/lcd_omap2evm.c
+++ /dev/null
@@ -1,192 +0,0 @@
-/*
- * LCD panel support for the MISTRAL OMAP2EVM board
- *
- * Author: Arun C <arunedarath@mistralsolutions.com>
- *
- * Derived from drivers/video/omap/lcd_omap3evm.c
- * Derived from drivers/video/omap/lcd-apollon.c
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#include <linux/module.h>
-#include <linux/platform_device.h>
-#include <linux/gpio.h>
-#include <linux/i2c/twl.h>
-
-#include <plat/mux.h>
-#include <asm/mach-types.h>
-
-#include "omapfb.h"
-
-#define LCD_PANEL_ENABLE_GPIO 154
-#define LCD_PANEL_LR 128
-#define LCD_PANEL_UD 129
-#define LCD_PANEL_INI 152
-#define LCD_PANEL_QVGA 148
-#define LCD_PANEL_RESB 153
-
-#define TWL_LED_LEDEN 0x00
-#define TWL_PWMA_PWMAON 0x00
-#define TWL_PWMA_PWMAOFF 0x01
-
-static unsigned int bklight_level;
-
-static int omap2evm_panel_init(struct lcd_panel *panel,
- struct omapfb_device *fbdev)
-{
- gpio_request(LCD_PANEL_ENABLE_GPIO, "LCD enable");
- gpio_request(LCD_PANEL_LR, "LCD lr");
- gpio_request(LCD_PANEL_UD, "LCD ud");
- gpio_request(LCD_PANEL_INI, "LCD ini");
- gpio_request(LCD_PANEL_QVGA, "LCD qvga");
- gpio_request(LCD_PANEL_RESB, "LCD resb");
-
- gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 1);
- gpio_direction_output(LCD_PANEL_RESB, 1);
- gpio_direction_output(LCD_PANEL_INI, 1);
- gpio_direction_output(LCD_PANEL_QVGA, 0);
- gpio_direction_output(LCD_PANEL_LR, 1);
- gpio_direction_output(LCD_PANEL_UD, 1);
-
- twl_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL_LED_LEDEN);
- twl_i2c_write_u8(TWL4030_MODULE_PWMA, 0x01, TWL_PWMA_PWMAON);
- twl_i2c_write_u8(TWL4030_MODULE_PWMA, 0x02, TWL_PWMA_PWMAOFF);
- bklight_level = 100;
-
- return 0;
-}
-
-static void omap2evm_panel_cleanup(struct lcd_panel *panel)
-{
- gpio_free(LCD_PANEL_RESB);
- gpio_free(LCD_PANEL_QVGA);
- gpio_free(LCD_PANEL_INI);
- gpio_free(LCD_PANEL_UD);
- gpio_free(LCD_PANEL_LR);
- gpio_free(LCD_PANEL_ENABLE_GPIO);
-}
-
-static int omap2evm_panel_enable(struct lcd_panel *panel)
-{
- gpio_set_value(LCD_PANEL_ENABLE_GPIO, 0);
- return 0;
-}
-
-static void omap2evm_panel_disable(struct lcd_panel *panel)
-{
- gpio_set_value(LCD_PANEL_ENABLE_GPIO, 1);
-}
-
-static unsigned long omap2evm_panel_get_caps(struct lcd_panel *panel)
-{
- return 0;
-}
-
-static int omap2evm_bklight_setlevel(struct lcd_panel *panel,
- unsigned int level)
-{
- u8 c;
- if ((level >= 0) && (level <= 100)) {
- c = (125 * (100 - level)) / 100 + 2;
- twl_i2c_write_u8(TWL4030_MODULE_PWMA, c, TWL_PWMA_PWMAOFF);
- bklight_level = level;
- }
- return 0;
-}
-
-static unsigned int omap2evm_bklight_getlevel(struct lcd_panel *panel)
-{
- return bklight_level;
-}
-
-static unsigned int omap2evm_bklight_getmaxlevel(struct lcd_panel *panel)
-{
- return 100;
-}
-
-struct lcd_panel omap2evm_panel = {
- .name = "omap2evm",
- .config = OMAP_LCDC_PANEL_TFT | OMAP_LCDC_INV_VSYNC |
- OMAP_LCDC_INV_HSYNC,
-
- .bpp = 16,
- .data_lines = 18,
- .x_res = 480,
- .y_res = 640,
- .hsw = 3,
- .hfp = 0,
- .hbp = 28,
- .vsw = 2,
- .vfp = 1,
- .vbp = 0,
-
- .pixel_clock = 20000,
-
- .init = omap2evm_panel_init,
- .cleanup = omap2evm_panel_cleanup,
- .enable = omap2evm_panel_enable,
- .disable = omap2evm_panel_disable,
- .get_caps = omap2evm_panel_get_caps,
- .set_bklight_level = omap2evm_bklight_setlevel,
- .get_bklight_level = omap2evm_bklight_getlevel,
- .get_bklight_max = omap2evm_bklight_getmaxlevel,
-};
-
-static int omap2evm_panel_probe(struct platform_device *pdev)
-{
- omapfb_register_panel(&omap2evm_panel);
- return 0;
-}
-
-static int omap2evm_panel_remove(struct platform_device *pdev)
-{
- return 0;
-}
-
-static int omap2evm_panel_suspend(struct platform_device *pdev,
- pm_message_t mesg)
-{
- return 0;
-}
-
-static int omap2evm_panel_resume(struct platform_device *pdev)
-{
- return 0;
-}
-
-struct platform_driver omap2evm_panel_driver = {
- .probe = omap2evm_panel_probe,
- .remove = omap2evm_panel_remove,
- .suspend = omap2evm_panel_suspend,
- .resume = omap2evm_panel_resume,
- .driver = {
- .name = "omap2evm_lcd",
- .owner = THIS_MODULE,
- },
-};
-
-static int __init omap2evm_panel_drv_init(void)
-{
- return platform_driver_register(&omap2evm_panel_driver);
-}
-
-static void __exit omap2evm_panel_drv_exit(void)
-{
- platform_driver_unregister(&omap2evm_panel_driver);
-}
-
-module_init(omap2evm_panel_drv_init);
-module_exit(omap2evm_panel_drv_exit);
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index ba9fc65..6c2c87e 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -13,7 +13,6 @@ snd-soc-rx51-objs := rx51.o
snd-soc-ams-delta-objs := ams-delta.o
snd-soc-osk5912-objs := osk5912.o
snd-soc-overo-objs := overo.o
-snd-soc-omap2evm-objs := omap2evm.o
snd-soc-omap3evm-objs := omap3evm.o
snd-soc-am3517evm-objs := am3517evm.o
snd-soc-sdp3430-objs := sdp3430.o
diff --git a/sound/soc/omap/omap2evm.c b/sound/soc/omap/omap2evm.c
deleted file mode 100644
index 29b60d6..0000000
--- a/sound/soc/omap/omap2evm.c
+++ /dev/null
@@ -1,139 +0,0 @@
-/*
- * omap2evm.c -- SoC audio machine driver for omap2evm board
- *
- * Author: Arun KS <arunks@mistralsolutions.com>
- *
- * Based on sound/soc/omap/overo.c by Steve Sakoman
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#include <linux/clk.h>
-#include <linux/platform_device.h>
-#include <sound/core.h>
-#include <sound/pcm.h>
-#include <sound/soc.h>
-
-#include <asm/mach-types.h>
-#include <mach/hardware.h>
-#include <mach/gpio.h>
-#include <plat/mcbsp.h>
-
-#include "omap-mcbsp.h"
-#include "omap-pcm.h"
-
-static int omap2evm_hw_params(struct snd_pcm_substream *substream,
- struct snd_pcm_hw_params *params)
-{
- struct snd_soc_pcm_runtime *rtd = substream->private_data;
- struct snd_soc_dai *codec_dai = rtd->codec_dai;
- struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
- int ret;
-
- /* Set codec DAI configuration */
- ret = snd_soc_dai_set_fmt(codec_dai,
- SND_SOC_DAIFMT_I2S |
- SND_SOC_DAIFMT_NB_NF |
- SND_SOC_DAIFMT_CBM_CFM);
- if (ret < 0) {
- printk(KERN_ERR "can't set codec DAI configuration\n");
- return ret;
- }
-
- /* Set cpu DAI configuration */
- ret = snd_soc_dai_set_fmt(cpu_dai,
- SND_SOC_DAIFMT_I2S |
- SND_SOC_DAIFMT_NB_NF |
- SND_SOC_DAIFMT_CBM_CFM);
- if (ret < 0) {
- printk(KERN_ERR "can't set cpu DAI configuration\n");
- return ret;
- }
-
- /* Set the codec system clock for DAC and ADC */
- ret = snd_soc_dai_set_sysclk(codec_dai, 0, 26000000,
- SND_SOC_CLOCK_IN);
- if (ret < 0) {
- printk(KERN_ERR "can't set codec system clock\n");
- return ret;
- }
-
- return 0;
-}
-
-static struct snd_soc_ops omap2evm_ops = {
- .hw_params = omap2evm_hw_params,
-};
-
-/* Digital audio interface glue - connects codec <--> CPU */
-static struct snd_soc_dai_link omap2evm_dai = {
- .name = "TWL4030",
- .stream_name = "TWL4030",
- .cpu_dai_name = "omap-mcbsp-dai.1",
- .codec_dai_name = "twl4030-hifi",
- .platform_name = "omap-pcm-audio",
- .codec_name = "twl4030-codec",
- .ops = &omap2evm_ops,
-};
-
-/* Audio machine driver */
-static struct snd_soc_card snd_soc_omap2evm = {
- .name = "omap2evm",
- .dai_link = &omap2evm_dai,
- .num_links = 1,
-};
-
-static struct platform_device *omap2evm_snd_device;
-
-static int __init omap2evm_soc_init(void)
-{
- int ret;
-
- if (!machine_is_omap2evm())
- return -ENODEV;
- printk(KERN_INFO "omap2evm SoC init\n");
-
- omap2evm_snd_device = platform_device_alloc("soc-audio", -1);
- if (!omap2evm_snd_device) {
- printk(KERN_ERR "Platform device allocation failed\n");
- return -ENOMEM;
- }
-
- platform_set_drvdata(omap2evm_snd_device, &snd_soc_omap2evm);
-
- ret = platform_device_add(omap2evm_snd_device);
- if (ret)
- goto err1;
-
- return 0;
-
-err1:
- printk(KERN_ERR "Unable to add platform device\n");
- platform_device_put(omap2evm_snd_device);
-
- return ret;
-}
-module_init(omap2evm_soc_init);
-
-static void __exit omap2evm_soc_exit(void)
-{
- platform_device_unregister(omap2evm_snd_device);
-}
-module_exit(omap2evm_soc_exit);
-
-MODULE_AUTHOR("Arun KS <arunks@mistralsolutions.com>");
-MODULE_DESCRIPTION("ALSA SoC omap2evm");
-MODULE_LICENSE("GPL");
^ permalink raw reply related
* [PATCH] video: mb862xxfb: Require either FB_MB862XX_PCI_GDC or
From: Ben Hutchings @ 2011-05-12 12:42 UTC (permalink / raw)
To: linux-fbdev
The driver can be built as either a PCI or platform (OF) driver. It
might make sense to built it as both (though that is not currently
possible) but it certainly doesn't make sense to build it as neither!
Add dependencies and add a choice group to ensure that exactly one of
FB_MB862XX_PCI_GDC and FB_MB862XX_LIME is selected.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/video/Kconfig | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 1d0aa5e..eb468f6 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2254,29 +2254,34 @@ config FB_METRONOME
config FB_MB862XX
tristate "Fujitsu MB862xx GDC support"
depends on FB
+ depends on PCI || (OF && PPC)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
---help---
Frame buffer driver for Fujitsu Carmine/Coral-P(A)/Lime controllers.
+choice
+ prompt "GDC variant"
+ depends on FB_MB862XX
+
config FB_MB862XX_PCI_GDC
bool "Carmine/Coral-P(A) GDC"
- depends on PCI && FB_MB862XX
+ depends on PCI
---help---
This enables framebuffer support for Fujitsu Carmine/Coral-P(A)
PCI graphics controller devices.
config FB_MB862XX_LIME
bool "Lime GDC"
- depends on FB_MB862XX
- depends on OF && !FB_MB862XX_PCI_GDC
- depends on PPC
+ depends on OF && PPC
select FB_FOREIGN_ENDIAN
select FB_LITTLE_ENDIAN
---help---
Framebuffer support for Fujitsu Lime GDC on host CPU bus.
+endchoice
+
config FB_EP93XX
tristate "EP93XX frame buffer support"
depends on FB && ARCH_EP93XX
--
1.7.4.4
^ permalink raw reply related
* [PATCHv2 8/8] OMAP: DSS2: OMAPFB: Reduce stack usage
From: Tomi Valkeinen @ 2011-05-12 11:40 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1305200413-23697-1-git-send-email-tomi.valkeinen@ti.com>
omapfb_mode_to_timings() had struct fb_info, struct fb_var and struct
fb_ops allocated from stack. This caused the stack usage grow quite
high.
Use kzalloc to allocate the structs instead.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 95 +++++++++++++++++++-----------
1 files changed, 61 insertions(+), 34 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 9a5b4bc..505bc12 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1996,9 +1996,9 @@ static int omapfb_create_framebuffers(struct omapfb2_device *fbdev)
static int omapfb_mode_to_timings(const char *mode_str,
struct omap_video_timings *timings, u8 *bpp)
{
- struct fb_info fbi;
- struct fb_var_screeninfo var;
- struct fb_ops fbops;
+ struct fb_info *fbi;
+ struct fb_var_screeninfo *var;
+ struct fb_ops *fbops;
int r;
#ifdef CONFIG_OMAP2_DSS_VENC
@@ -2016,39 +2016,66 @@ static int omapfb_mode_to_timings(const char *mode_str,
/* this is quite a hack, but I wanted to use the modedb and for
* that we need fb_info and var, so we create dummy ones */
- memset(&fbi, 0, sizeof(fbi));
- memset(&var, 0, sizeof(var));
- memset(&fbops, 0, sizeof(fbops));
- fbi.fbops = &fbops;
-
- r = fb_find_mode(&var, &fbi, mode_str, NULL, 0, NULL, 24);
-
- if (r != 0) {
- timings->pixel_clock = PICOS2KHZ(var.pixclock);
- timings->hbp = var.left_margin;
- timings->hfp = var.right_margin;
- timings->vbp = var.upper_margin;
- timings->vfp = var.lower_margin;
- timings->hsw = var.hsync_len;
- timings->vsw = var.vsync_len;
- timings->x_res = var.xres;
- timings->y_res = var.yres;
-
- switch (var.bits_per_pixel) {
- case 16:
- *bpp = 16;
- break;
- case 24:
- case 32:
- default:
- *bpp = 24;
- break;
- }
+ *bpp = 0;
+ fbi = NULL;
+ var = NULL;
+ fbops = NULL;
- return 0;
- } else {
- return -EINVAL;
+ fbi = kzalloc(sizeof(*fbi), GFP_KERNEL);
+ if (fbi = NULL) {
+ r = -ENOMEM;
+ goto err;
+ }
+
+ var = kzalloc(sizeof(*var), GFP_KERNEL);
+ if (var = NULL) {
+ r = -ENOMEM;
+ goto err;
+ }
+
+ fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
+ if (fbops = NULL) {
+ r = -ENOMEM;
+ goto err;
+ }
+
+ fbi->fbops = fbops;
+
+ r = fb_find_mode(var, fbi, mode_str, NULL, 0, NULL, 24);
+ if (r = 0) {
+ r = -EINVAL;
+ goto err;
}
+
+ timings->pixel_clock = PICOS2KHZ(var->pixclock);
+ timings->hbp = var->left_margin;
+ timings->hfp = var->right_margin;
+ timings->vbp = var->upper_margin;
+ timings->vfp = var->lower_margin;
+ timings->hsw = var->hsync_len;
+ timings->vsw = var->vsync_len;
+ timings->x_res = var->xres;
+ timings->y_res = var->yres;
+
+ switch (var->bits_per_pixel) {
+ case 16:
+ *bpp = 16;
+ break;
+ case 24:
+ case 32:
+ default:
+ *bpp = 24;
+ break;
+ }
+
+ r = 0;
+
+err:
+ kfree(fbi);
+ kfree(var);
+ kfree(fbops);
+
+ return r;
}
static int omapfb_set_def_mode(struct omapfb2_device *fbdev,
--
1.7.4.1
^ permalink raw reply related
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