* [PATCH] fsl-diu-fb: remove the ioctl interface
From: Timur Tabi @ 2011-06-21 21:27 UTC (permalink / raw)
To: lethal, linux-fbdev, agust, yorksun, linuxppc-dev
The ioctl interface in the Freescale DIU framebuffer driver is just a
collection of miscellaneous functions which were only used in a one-time
demo application that was never distributed. Plus, the ioctls were spread
across two types (both conflicting), and the demo app didn't even use all
of them.
Removing the ioctl interface also allows us to clean up the header file and
remove other unusued stuff.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
There's a warning about dummy_ad_addr that will be fixed in a future patch.
Documentation/ioctl/ioctl-number.txt | 2 -
drivers/video/fsl-diu-fb.c | 157 ++++++++++------------------------
include/linux/fsl-diu-fb.h | 94 --------------------
3 files changed, 44 insertions(+), 209 deletions(-)
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 3a46e36..6c83c07 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -108,7 +108,6 @@ Code Seq#(hex) Include File Comments
'E' 00-0F xen/evtchn.h conflict!
'F' all linux/fb.h conflict!
'F' 01-02 drivers/scsi/pmcraid.h conflict!
-'F' 20 drivers/video/fsl-diu-fb.h conflict!
'F' 20 drivers/video/intelfb/intelfb.h conflict!
'F' 20 linux/ivtvfb.h conflict!
'F' 20 linux/matroxfb.h conflict!
@@ -147,7 +146,6 @@ Code Seq#(hex) Include File Comments
'M' 01-16 mtd/mtd-abi.h conflict!
and drivers/mtd/mtdchar.c
'M' 01-03 drivers/scsi/megaraid/megaraid_sas.h
-'M' 00-0F drivers/video/fsl-diu-fb.h conflict!
'N' 00-1F drivers/usb/scanner.h
'O' 00-06 mtd/ubi-user.h UBI
'P' all linux/soundcard.h conflict!
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index bedf5be..db2abaf 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -37,6 +37,50 @@
#include <linux/fsl-diu-fb.h>
#include "edid.h"
+/* Minimum value that the pixel clock can be set to in pico seconds
+ * This is determined by platform clock/3 where the minimum platform
+ * clock is 533MHz. This gives 5629 pico seconds.
+ */
+#define MIN_PIX_CLK 5629
+#define MAX_PIX_CLK 96096
+
+#define FSL_AOI_NUM 6 /* 5 AOIs and one dummy AOI */
+
+/* INT_STATUS/INT_MASK field descriptions */
+#define INT_VSYNC 0x01 /* Vsync interrupt */
+#define INT_VSYNC_WB 0x02 /* Vsync interrupt for write back operation */
+#define INT_UNDRUN 0x04 /* Under run exception interrupt */
+#define INT_PARERR 0x08 /* Display parameters error interrupt */
+#define INT_LS_BF_VS 0x10 /* Lines before vsync. interrupt */
+
+/* Panels'operation modes */
+#define MFB_TYPE_OUTPUT 0 /* Panel output to display */
+#define MFB_TYPE_OFF 1 /* Panel off */
+#define MFB_TYPE_WB 2 /* Panel written back to memory */
+#define MFB_TYPE_TEST 3 /* Panel generate color bar */
+
+/* HW cursor parameters */
+#define MAX_CURS 32
+
+struct diu_hw {
+ struct diu *diu_reg;
+ spinlock_t reg_lock;
+ __u32 mode; /* DIU operation mode */
+};
+
+struct diu_addr {
+ __u8 __iomem *vaddr; /* Virtual address */
+ dma_addr_t paddr; /* Physical address */
+ __u32 offset;
+};
+
+struct diu_pool {
+ struct diu_addr ad;
+ struct diu_addr gamma;
+ struct diu_addr pallete;
+ struct diu_addr cursor;
+};
+
/*
* These parameters give default parameters
* for video output 1024x768,
@@ -991,118 +1035,6 @@ static int fsl_diu_blank(int blank_mode, struct fb_info *info)
return 0;
}
-static int fsl_diu_ioctl(struct fb_info *info, unsigned int cmd,
- unsigned long arg)
-{
- struct mfb_info *mfbi = info->par;
- struct diu_ad *ad = mfbi->ad;
- struct mfb_chroma_key ck;
- unsigned char global_alpha;
- struct aoi_display_offset aoi_d;
- __u32 pix_fmt;
- void __user *buf = (void __user *)arg;
-
- if (!arg)
- return -EINVAL;
- switch (cmd) {
- case MFB_SET_PIXFMT:
- if (copy_from_user(&pix_fmt, buf, sizeof(pix_fmt)))
- return -EFAULT;
- ad->pix_fmt = pix_fmt;
- pr_debug("Set pixel format to 0x%08x\n", ad->pix_fmt);
- break;
- case MFB_GET_PIXFMT:
- pix_fmt = ad->pix_fmt;
- if (copy_to_user(buf, &pix_fmt, sizeof(pix_fmt)))
- return -EFAULT;
- pr_debug("get pixel format 0x%08x\n", ad->pix_fmt);
- break;
- case MFB_SET_AOID:
- if (copy_from_user(&aoi_d, buf, sizeof(aoi_d)))
- return -EFAULT;
- mfbi->x_aoi_d = aoi_d.x_aoi_d;
- mfbi->y_aoi_d = aoi_d.y_aoi_d;
- pr_debug("set AOI display offset of index %d to (%d,%d)\n",
- mfbi->index, aoi_d.x_aoi_d, aoi_d.y_aoi_d);
- fsl_diu_check_var(&info->var, info);
- fsl_diu_set_aoi(info);
- break;
- case MFB_GET_AOID:
- aoi_d.x_aoi_d = mfbi->x_aoi_d;
- aoi_d.y_aoi_d = mfbi->y_aoi_d;
- if (copy_to_user(buf, &aoi_d, sizeof(aoi_d)))
- return -EFAULT;
- pr_debug("get AOI display offset of index %d (%d,%d)\n",
- mfbi->index, aoi_d.x_aoi_d, aoi_d.y_aoi_d);
- break;
- case MFB_GET_ALPHA:
- global_alpha = mfbi->g_alpha;
- if (copy_to_user(buf, &global_alpha, sizeof(global_alpha)))
- return -EFAULT;
- pr_debug("get global alpha of index %d\n", mfbi->index);
- break;
- case MFB_SET_ALPHA:
- /* set panel information */
- if (copy_from_user(&global_alpha, buf, sizeof(global_alpha)))
- return -EFAULT;
- ad->src_size_g_alpha = (ad->src_size_g_alpha & (~0xff)) |
- (global_alpha & 0xff);
- mfbi->g_alpha = global_alpha;
- pr_debug("set global alpha for index %d\n", mfbi->index);
- break;
- case MFB_SET_CHROMA_KEY:
- /* set panel winformation */
- if (copy_from_user(&ck, buf, sizeof(ck)))
- return -EFAULT;
-
- if (ck.enable &&
- (ck.red_max < ck.red_min ||
- ck.green_max < ck.green_min ||
- ck.blue_max < ck.blue_min))
- return -EINVAL;
-
- if (!ck.enable) {
- ad->ckmax_r = 0;
- ad->ckmax_g = 0;
- ad->ckmax_b = 0;
- ad->ckmin_r = 255;
- ad->ckmin_g = 255;
- ad->ckmin_b = 255;
- } else {
- ad->ckmax_r = ck.red_max;
- ad->ckmax_g = ck.green_max;
- ad->ckmax_b = ck.blue_max;
- ad->ckmin_r = ck.red_min;
- ad->ckmin_g = ck.green_min;
- ad->ckmin_b = ck.blue_min;
- }
- pr_debug("set chroma key\n");
- break;
- case FBIOGET_GWINFO:
- if (mfbi->type = MFB_TYPE_OFF)
- return -ENODEV;
- /* get graphic window information */
- if (copy_to_user(buf, ad, sizeof(*ad)))
- return -EFAULT;
- break;
- case FBIOGET_HWCINFO:
- pr_debug("FBIOGET_HWCINFO:0x%08x\n", FBIOGET_HWCINFO);
- break;
- case FBIOPUT_MODEINFO:
- pr_debug("FBIOPUT_MODEINFO:0x%08x\n", FBIOPUT_MODEINFO);
- break;
- case FBIOGET_DISPINFO:
- pr_debug("FBIOGET_DISPINFO:0x%08x\n", FBIOGET_DISPINFO);
- break;
-
- default:
- printk(KERN_ERR "Unknown ioctl command (0x%08X)\n", cmd);
- return -ENOIOCTLCMD;
- }
-
- return 0;
-}
-
/* turn on fb if count = 1
*/
static int fsl_diu_open(struct fb_info *info, int user)
@@ -1162,7 +1094,6 @@ static struct fb_ops fsl_diu_ops = {
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
.fb_imageblit = cfb_imageblit,
- .fb_ioctl = fsl_diu_ioctl,
.fb_open = fsl_diu_open,
.fb_release = fsl_diu_release,
};
diff --git a/include/linux/fsl-diu-fb.h b/include/linux/fsl-diu-fb.h
index 781d467..234c38e 100644
--- a/include/linux/fsl-diu-fb.h
+++ b/include/linux/fsl-diu-fb.h
@@ -20,55 +20,8 @@
#ifndef __FSL_DIU_FB_H__
#define __FSL_DIU_FB_H__
-/* Arbitrary threshold to determine the allocation method
- * See mpc8610fb_set_par(), map_video_memory(), and unmap_video_memory()
- */
-#define MEM_ALLOC_THRESHOLD (1024*768*4+32)
-/* Minimum value that the pixel clock can be set to in pico seconds
- * This is determined by platform clock/3 where the minimum platform
- * clock is 533MHz. This gives 5629 pico seconds.
- */
-#define MIN_PIX_CLK 5629
-#define MAX_PIX_CLK 96096
-
#include <linux/types.h>
-struct mfb_alpha {
- int enable;
- int alpha;
-};
-
-struct mfb_chroma_key {
- int enable;
- __u8 red_max;
- __u8 green_max;
- __u8 blue_max;
- __u8 red_min;
- __u8 green_min;
- __u8 blue_min;
-};
-
-struct aoi_display_offset {
- int x_aoi_d;
- int y_aoi_d;
-};
-
-#define MFB_SET_CHROMA_KEY _IOW('M', 1, struct mfb_chroma_key)
-#define MFB_SET_BRIGHTNESS _IOW('M', 3, __u8)
-
-#define MFB_SET_ALPHA 0x80014d00
-#define MFB_GET_ALPHA 0x40014d00
-#define MFB_SET_AOID 0x80084d04
-#define MFB_GET_AOID 0x40084d04
-#define MFB_SET_PIXFMT 0x80014d08
-#define MFB_GET_PIXFMT 0x40014d08
-
-#define FBIOGET_GWINFO 0x46E0
-#define FBIOPUT_GWINFO 0x46E1
-
-#ifdef __KERNEL__
-#include <linux/spinlock.h>
-
/*
* These are the fields of area descriptor(in DDR memory) for every plane
*/
@@ -165,39 +118,6 @@ struct diu {
__be32 plut;
} __attribute__ ((packed));
-struct diu_hw {
- struct diu *diu_reg;
- spinlock_t reg_lock;
-
- __u32 mode; /* DIU operation mode */
-};
-
-struct diu_addr {
- __u8 __iomem *vaddr; /* Virtual address */
- dma_addr_t paddr; /* Physical address */
- __u32 offset;
-};
-
-struct diu_pool {
- struct diu_addr ad;
- struct diu_addr gamma;
- struct diu_addr pallete;
- struct diu_addr cursor;
-};
-
-#define FSL_DIU_BASE_OFFSET 0x2C000 /* Offset of DIU */
-#define INT_LCDC 64 /* DIU interrupt number */
-
-#define FSL_AOI_NUM 6 /* 5 AOIs and one dummy AOI */
- /* 1 for plane 0, 2 for plane 1&2 each */
-
-/* Minimum X and Y resolutions */
-#define MIN_XRES 64
-#define MIN_YRES 64
-
-/* HW cursor parameters */
-#define MAX_CURS 32
-
/* Modes of operation of DIU */
#define MFB_MODE0 0 /* DIU off */
#define MFB_MODE1 1 /* All three planes output to display */
@@ -205,18 +125,4 @@ struct diu_pool {
#define MFB_MODE3 3 /* All three planes written back to memory */
#define MFB_MODE4 4 /* Color bar generation */
-/* INT_STATUS/INT_MASK field descriptions */
-#define INT_VSYNC 0x01 /* Vsync interrupt */
-#define INT_VSYNC_WB 0x02 /* Vsync interrupt for write back operation */
-#define INT_UNDRUN 0x04 /* Under run exception interrupt */
-#define INT_PARERR 0x08 /* Display parameters error interrupt */
-#define INT_LS_BF_VS 0x10 /* Lines before vsync. interrupt */
-
-/* Panels'operation modes */
-#define MFB_TYPE_OUTPUT 0 /* Panel output to display */
-#define MFB_TYPE_OFF 1 /* Panel off */
-#define MFB_TYPE_WB 2 /* Panel written back to memory */
-#define MFB_TYPE_TEST 3 /* Panel generate color bar */
-
-#endif /* __KERNEL__ */
#endif /* __FSL_DIU_FB_H__ */
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Geert Uytterhoeven @ 2011-06-21 20:49 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-fbdev, linux-media, dri-devel, FlorianSchandinat
In-Reply-To: <1308670579-15138-1-git-send-email-laurent.pinchart@ideasonboard.com>
Hi Laurent,
On Tue, Jun 21, 2011 at 17:36, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> +The following types and visuals are supported.
> +
> +- FB_TYPE_PACKED_PIXELS
> +
> +- FB_TYPE_PLANES
You forgot FB_TYPE_INTERLEAVED_PLANES, FB_TYPE_TEXT, and
FB_TYPE_VGA_PLANES. Ah, that's the "feel free to extend the API doc" :-)
> +The FOURCC-based API replaces format descriptions by four character codes
> +(FOURCC). FOURCCs are abstract identifiers that uniquely define a format
> +without explicitly describing it. This is the only API that supports YUV
> +formats. Drivers are also encouraged to implement the FOURCC-based API for RGB
> +and grayscale formats.
> +
> +Drivers that support the FOURCC-based API report this capability by setting
> +the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field.
> +
> +FOURCC definitions are located in the linux/videodev2.h header. However, and
> +despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to V4L2
> +and don't require usage of the V4L2 subsystem. FOURCC documentation is
> +available in Documentation/DocBook/v4l/pixfmt.xml.
> +
> +To select a format, applications set the FB_VMODE_FOURCC bit in the
> +fb_var_screeninfo vmode field, and set the fourcc field to the desired FOURCC.
> +The bits_per_pixel, red, green, blue, transp and nonstd fields must be set to
> +0 by applications and ignored by drivers. Note that the grayscale and fourcc
> +fields share the same memory location. Application must thus not set the
> +grayscale field to 0.
These are the only parts I don't like: (ab)using the vmode field (this
isn't really a
vmode flag), and the union of grayscale and fourcc (avoid unions where
possible).
What about storing the FOURCC value in nonstd instead?
As FOURCC values are always 4 ASCII characters (hence all 4 bytes must
be non-zero),
I don't think there are any conflicts with existing values of nonstd.
To make it even safer and easier to parse, you could set bit 31 of
nonstd as a FOURCC
indicator.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-06-21 15:36 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-media, dri-devel, FlorianSchandinat
In-Reply-To: <4DDAE63A.3070203@gmx.de>
This API will be used to support YUV frame buffer formats in a standard
way.
Last but not least, create a much needed fbdev API documentation and
document the format setting APIs.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Documentation/fb/api.txt | 284 ++++++++++++++++++++++++++++++++++++++++++++++
include/linux/fb.h | 12 ++-
2 files changed, 294 insertions(+), 2 deletions(-)
create mode 100644 Documentation/fb/api.txt
A bit late, but here's a patch that implements an fbdev format configuration
API to support YUV formats. My next step is to implement a prototype in an
fbdev driver to make sure the API works well.
Thanks to Florian Tobias Schandinat for providing feedback on the initial RFC.
Comments are as usual more than welcome. If you feel like writing a couple of
lines of documentation, feel free to extend the API doc. That's much needed.
diff --git a/Documentation/fb/api.txt b/Documentation/fb/api.txt
new file mode 100644
index 0000000..d4cd6ec
--- /dev/null
+++ b/Documentation/fb/api.txt
@@ -0,0 +1,284 @@
+ The Frame Buffer Device API
+ ---------------------------
+
+Last revised: June 21, 2011
+
+
+0. Introduction
+---------------
+
+This document describes the frame buffer API used by applications to interact
+with frame buffer devices. In-kernel APIs between device drivers and the frame
+buffer core are not described.
+
+Due to a lack of documentation in the original frame buffer API, drivers
+behaviours differ in subtle (and not so subtle) ways. This document describes
+the recommended API implementation, but applications should be prepared to
+deal with different behaviours.
+
+
+1. Capabilities
+---------------
+
+Device and driver capabilities are reported in the fixed screen information
+capabilities field.
+
+struct fb_fix_screeninfo {
+ ...
+ __u16 capabilities; /* see FB_CAP_* */
+ ...
+};
+
+Application should use those capabilities to find out what features they can
+expect from the device and driver.
+
+- FB_CAP_FOURCC
+
+The driver supports the four character code (FOURCC) based format setting API.
+When supported, formats are configured using a FOURCC instead of manually
+specifying color components layout.
+
+
+2. Types and visuals
+--------------------
+
+Pixels are stored in memory in hardware-dependent formats. Applications need
+to be aware of the pixel storage format in order to write image data to the
+frame buffer memory in the format expected by the hardware.
+
+Formats are described by frame buffer types and visuals. Some visuals require
+additional information, which are stored in the variable screen information
+bits_per_pixel, grayscale, fourcc, red, green, blue and transp fields.
+
+The following types and visuals are supported.
+
+- FB_TYPE_PACKED_PIXELS
+
+Color components (usually RGB or YUV) are packed together into macropixels
+that are stored in a single plane. The exact color components layout is
+described in a visual-dependent way.
+
+Frame buffer visuals that don't use multiple color components per pixel
+(such as monochrome and pseudo-color visuals) are reported as packed frame
+buffer types, even though they don't stricly speaking pack color components
+into macropixels.
+
+- FB_TYPE_PLANES
+
+Color components are stored in separate planes. Planes are located
+contiguously in memory.
+
+- FB_VISUAL_MONO01
+
+Pixels are black or white and stored on one bit. A bit set to 1 represents a
+black pixel and a bit set to 0 a white pixel. Pixels are packed together in
+bytes with 8 pixels per byte.
+
+FB_VISUAL_MONO01 is used with FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_MONO10
+
+Pixels are black or white and stored on one bit. A bit set to 1 represents a
+white pixel and a bit set to 0 a black pixel. Pixels are packed together in
+bytes with 8 pixels per byte.
+
+FB_VISUAL_MONO01 is used with FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_TRUECOLOR
+
+Pixels are broken into red, green and blue components, and each component
+indexes a read-only lookup table for the corresponding value. Lookup tables
+are device-dependent, and provide linear or non-linear ramps.
+
+Each component is stored in memory according to the variable screen
+information red, green, blue and transp fields.
+
+- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR
+
+Pixel values are encoded as indices into a colormap that stores red, green and
+blue components. The colormap is read-only for FB_VISUAL_STATIC_PSEUDOCOLOR
+and read-write for FB_VISUAL_PSEUDOCOLOR.
+
+Each pixel value is stored in the number of bits reported by the variable
+screen information bits_per_pixel field. Pixels are contiguous in memory.
+
+FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR are used with
+FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_DIRECTCOLOR
+
+Pixels are broken into red, green and blue components, and each component
+indexes a programmable lookup table for the corresponding value.
+
+Each component is stored in memory according to the variable screen
+information red, green, blue and transp fields.
+
+- FB_VISUAL_FOURCC
+
+Pixels are stored in memory as described by the format FOURCC identifier
+stored in the variable screen information fourcc field.
+
+
+3. Screen information
+---------------------
+
+Screen information are queried by applications using the FBIOGET_FSCREENINFO
+and FBIOGET_VSCREENINFO ioctls. Those ioctls take a pointer to a
+fb_fix_screeninfo and fb_var_screeninfo structure respectively.
+
+struct fb_fix_screeninfo stores device independent unchangeable information
+about the frame buffer device and the current format. Those information can't
+be directly modified by applications, but can be changed by the driver when an
+application modifies the format.
+
+struct fb_fix_screeninfo {
+ char id[16]; /* identification string eg "TT Builtin" */
+ unsigned long smem_start; /* Start of frame buffer mem */
+ /* (physical address) */
+ __u32 smem_len; /* Length of frame buffer mem */
+ __u32 type; /* see FB_TYPE_* */
+ __u32 type_aux; /* Interleave for interleaved Planes */
+ __u32 visual; /* see FB_VISUAL_* */
+ __u16 xpanstep; /* zero if no hardware panning */
+ __u16 ypanstep; /* zero if no hardware panning */
+ __u16 ywrapstep; /* zero if no hardware ywrap */
+ __u32 line_length; /* length of a line in bytes */
+ unsigned long mmio_start; /* Start of Memory Mapped I/O */
+ /* (physical address) */
+ __u32 mmio_len; /* Length of Memory Mapped I/O */
+ __u32 accel; /* Indicate to driver which */
+ /* specific chip/card we have */
+ __u16 capabilities; /* see FB_CAP_* */
+ __u16 reserved[2]; /* Reserved for future compatibility */
+};
+
+struct fb_var_screeninfo stores device independent changeable information
+about a frame buffer device, its current format and video mode, as well as
+other miscellaneous parameters.
+
+struct fb_var_screeninfo {
+ __u32 xres; /* visible resolution */
+ __u32 yres;
+ __u32 xres_virtual; /* virtual resolution */
+ __u32 yres_virtual;
+ __u32 xoffset; /* offset from virtual to visible */
+ __u32 yoffset; /* resolution */
+
+ __u32 bits_per_pixel; /* guess what */
+ union {
+ __u32 grayscale; /* != 0 Graylevels instead of colors */
+ __u32 fourcc; /* video mode */
+ };
+
+ 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 */
+
+ __u32 activate; /* see FB_ACTIVATE_* */
+
+ __u32 height; /* height of picture in mm */
+ __u32 width; /* width of picture in mm */
+
+ __u32 accel_flags; /* (OBSOLETE) see fb_info.flags */
+
+ /* Timing: All values in pixclocks, except pixclock (of course) */
+ __u32 pixclock; /* pixel clock in ps (pico seconds) */
+ __u32 left_margin; /* time from sync to picture */
+ __u32 right_margin; /* time from picture to sync */
+ __u32 upper_margin; /* time from sync to picture */
+ __u32 lower_margin;
+ __u32 hsync_len; /* length of horizontal sync */
+ __u32 vsync_len; /* length of vertical sync */
+ __u32 sync; /* see FB_SYNC_* */
+ __u32 vmode; /* see FB_VMODE_* */
+ __u32 rotate; /* angle we rotate counter clockwise */
+ __u32 reserved[5]; /* Reserved for future compatibility */
+};
+
+To modify variable information, applications call the FBIOPUT_VSCREENINFO
+ioctl with a pointer to a fb_var_screeninfo structure. If the call is
+successful, the driver will update the fixed screen information accordingly.
+
+Instead of filling the complete fb_var_screeninfo structure manually,
+applications should call the FBIOGET_VSCREENINFO ioctl and modify only the
+fields they care about.
+
+
+4. Format configuration
+-----------------------
+
+Frame buffer devices offer two ways to configure the frame buffer format: the
+legacy API and the FOURCC-based API.
+
+
+The legacy API has been the only frame buffer format configuration API for a
+long time and is thus widely used by application. It is the recommended API
+for applications when using RGB and grayscale formats, as well as legacy
+non-standard formats.
+
+To select a format, applications set the fb_var_screeninfo bits_per_pixel field
+to the desired frame buffer depth. Values up to 8 will usually map to
+monochrome, grayscale or pseudocolor visuals, although this is not required.
+
+- For grayscale formats, applications set the grayscale field to a non-zero
+ value. The red, blue, green and transp fields must be set to 0 by
+ applications and ignored by drivers. Drivers must fill the red, blue and
+ green offsets to 0 and lengths to the bits_per_pixel value.
+
+- For pseudocolor formats, applications set the grayscale field to a zero
+ value. The red, blue, green and transp fields must be set to 0 by
+ applications and ignored by drivers. Drivers must fill the red, blue and
+ green offsets to 0 and lengths to the bits_per_pixel value.
+
+- For truecolor and directcolor formats, applications set the grayscale field
+ to a zero value, and the red, blue, green and transp fields to describe the
+ layout of color components in memory.
+
+struct fb_bitfield {
+ __u32 offset; /* beginning of bitfield */
+ __u32 length; /* length of bitfield */
+ __u32 msb_right; /* != 0 : Most significant bit is */
+ /* right */
+};
+
+ Pixel values are bits_per_pixel wide and are split in non-overlapping red,
+ green, blue and alpha (transparency) components. Location and size of each
+ component in the pixel value are described by the fb_bitfield offset and
+ length fields. Offset are computed from the right.
+
+ Pixels are always stored in an integer number of bytes. If the number of
+ bits per pixel is not a multiple of 8, pixel values are padded to the next
+ multiple of 8 bits.
+
+Upon successful format configuration, drivers update the fb_fix_screeninfo
+type, visual and line_length fields depending on the selected format.
+
+
+The FOURCC-based API replaces format descriptions by four character codes
+(FOURCC). FOURCCs are abstract identifiers that uniquely define a format
+without explicitly describing it. This is the only API that supports YUV
+formats. Drivers are also encouraged to implement the FOURCC-based API for RGB
+and grayscale formats.
+
+Drivers that support the FOURCC-based API report this capability by setting
+the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field.
+
+FOURCC definitions are located in the linux/videodev2.h header. However, and
+despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to V4L2
+and don't require usage of the V4L2 subsystem. FOURCC documentation is
+available in Documentation/DocBook/v4l/pixfmt.xml.
+
+To select a format, applications set the FB_VMODE_FOURCC bit in the
+fb_var_screeninfo vmode field, and set the fourcc field to the desired FOURCC.
+The bits_per_pixel, red, green, blue, transp and nonstd fields must be set to
+0 by applications and ignored by drivers. Note that the grayscale and fourcc
+fields share the same memory location. Application must thus not set the
+grayscale field to 0.
+
+Upon successful format configuration, drivers update the fb_fix_screeninfo
+type, visual and line_length fields depending on the selected format. The
+visual field is set to FB_VISUAL_FOURCC.
+
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 6a82748..359e98e 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -69,6 +69,7 @@
#define FB_VISUAL_PSEUDOCOLOR 3 /* Pseudo color (like atari) */
#define FB_VISUAL_DIRECTCOLOR 4 /* Direct color */
#define FB_VISUAL_STATIC_PSEUDOCOLOR 5 /* Pseudo color readonly */
+#define FB_VISUAL_FOURCC 6 /* Visual identified by a V4L2 FOURCC */
#define FB_ACCEL_NONE 0 /* no hardware accelerator */
#define FB_ACCEL_ATARIBLITT 1 /* Atari Blitter */
@@ -154,6 +155,8 @@
#define FB_ACCEL_PUV3_UNIGFX 0xa0 /* PKUnity-v3 Unigfx */
+#define FB_CAP_FOURCC 1 /* Device supports FOURCC-based formats */
+
struct fb_fix_screeninfo {
char id[16]; /* identification string eg "TT Builtin" */
unsigned long smem_start; /* Start of frame buffer mem */
@@ -171,7 +174,8 @@ struct fb_fix_screeninfo {
__u32 mmio_len; /* Length of Memory Mapped I/O */
__u32 accel; /* Indicate to driver which */
/* specific chip/card we have */
- __u16 reserved[3]; /* Reserved for future compatibility */
+ __u16 capabilities; /* see FB_CAP_* */
+ __u16 reserved[2]; /* Reserved for future compatibility */
};
/* Interpretation of offset for color fields: All offsets are from the right,
@@ -220,6 +224,7 @@ struct fb_bitfield {
#define FB_VMODE_INTERLACED 1 /* interlaced */
#define FB_VMODE_DOUBLE 2 /* double scan */
#define FB_VMODE_ODD_FLD_FIRST 4 /* interlaced: top line first */
+#define FB_VMODE_FOURCC 8 /* video mode expressed as a FOURCC */
#define FB_VMODE_MASK 255
#define FB_VMODE_YWRAP 256 /* ywrap instead of panning */
@@ -246,7 +251,10 @@ struct fb_var_screeninfo {
__u32 yoffset; /* resolution */
__u32 bits_per_pixel; /* guess what */
- __u32 grayscale; /* != 0 Graylevels instead of colors */
+ union {
+ __u32 grayscale; /* != 0 Graylevels instead of colors */
+ __u32 fourcc; /* FOURCC format */
+ };
struct fb_bitfield red; /* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* Re: [PATCHv2 20/28] OMAP: DSS2: Use PM runtime & HWMOD support
From: Tomi Valkeinen @ 2011-06-21 15:18 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-fbdev, b-cousson, paul
In-Reply-To: <87vcvzz1bc.fsf@ti.com>
On Tue, 2011-06-21 at 07:49 -0700, Kevin Hilman wrote:
> Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
>
> > Use PM runtime and HWMOD support to handle enabling and disabling of DSS
> > modules.
> >
> > Each DSS module will have get and put functions which can be used to
> > enable and disable that module. The functions use pm_runtime and hwmod
> > opt-clocks to enable the hardware.
> >
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>
> Runtime PM usage is much better on this version, thanks!
>
> Like Paul, I'm not crazy about the helper functions, especially the ones
> that don't do much other than call runtime PM with some debug code
> around them since runtime PM already has useful debug.
>
> However, you're the maintainer and the one who has to debug this code
> more than I do, so that decision is up to you.
I have to say I'm not familiar with runtime PM's debug (yet, I need to
check it out), but if I'm debugging DSS, I'm not interested in runtime
PM's debug concerning some other drivers or any verbose details about
runtime PM.
So by having the wrappers I can just observe DSS debug, and see when DSS
enables/disables runtime PM etc.
If runtime PM's debug allows me to easily only see debugs about DSS,
then I agree that the wrappers are extra.
Tomi
^ permalink raw reply
* Re: [PATCHv2 20/28] OMAP: DSS2: Use PM runtime & HWMOD support
From: Kevin Hilman @ 2011-06-21 14:49 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, b-cousson, paul
In-Reply-To: <1307627810-3768-21-git-send-email-tomi.valkeinen@ti.com>
Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
> Use PM runtime and HWMOD support to handle enabling and disabling of DSS
> modules.
>
> Each DSS module will have get and put functions which can be used to
> enable and disable that module. The functions use pm_runtime and hwmod
> opt-clocks to enable the hardware.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Runtime PM usage is much better on this version, thanks!
Like Paul, I'm not crazy about the helper functions, especially the ones
that don't do much other than call runtime PM with some debug code
around them since runtime PM already has useful debug.
However, you're the maintainer and the one who has to debug this code
more than I do, so that decision is up to you.
Acked-by: Kevin Hilman <khilman@ti.com>
Kevin
^ permalink raw reply
* Re: [PATCH] locomo: drop special locomo_{read/write}l in favor of
From: Dmitry Torokhov @ 2011-06-21 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201106201454.18070.hartleys@visionengravers.com>
On Mon, Jun 20, 2011 at 02:54:17PM -0700, H Hartley Sweeten wrote:
> All the locomo registers are 16-bit ioremap'ed memory addresses.
>
> Make the locomo drivers use generic purpose io routines: ioread16
> and iowrite16 instead of directly accessing memory.
>
> There are still a couple checkpatch warnings about lines exceeding
> 79 characters.
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Input parts look good to me.
Acked-by: Dmitry Torokhov <dtor@mail.ru>
--
Dmitry
^ permalink raw reply
* Re: [PATCHv2 15/28] OMAP4: HWMOD: Modify DSS opt clocks
From: Tomi Valkeinen @ 2011-06-21 6:20 UTC (permalink / raw)
To: b-cousson; +Cc: linux-fbdev, paul, khilman, linux-omap mailing list
In-Reply-To: <1308137027.1974.39.camel@deskari>
On Wed, 2011-06-15 at 14:23 +0300, Tomi Valkeinen wrote:
> On Thu, 2011-06-09 at 16:56 +0300, Tomi Valkeinen wrote:
> > Add missing DSS optional clocks to HWMOD data for OMAP4xxx.
> >
> > Add HWMOD_CONTROL_OPT_CLKS_IN_RESET flag for dispc to fix dispc reset.
> >
> > Cc: Benoit Cousson <b-cousson@ti.com>
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>
> Benoit (and/or Paul/Kevin), can you ack this and the other HWMOD
> patches, or give comments?
Ping.
Tomi
^ permalink raw reply
* Re: [PATCH 2/2] video: omap2: Compile omap2 support only when
From: Tomi Valkeinen @ 2011-06-21 5:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E0022B5.9000500@linaro.org>
On Tue, 2011-06-21 at 10:18 +0530, Tushar Behera wrote:
> Hi,
>
> On Monday 20 June 2011 06:36 PM, Tomi Valkeinen wrote:
> > On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote:
> >> Currently display support for omap2 is selected by default and
> >> it gets built for all the configurations.
> >>
> >> Instead of it being a built-in feature, it's compilation should
> >> depend on the config option CONFIG_FB_OMAP2.
> >
> > No, I don't think so. omap2 directory contains vram, vrfb and omapdss,
> > all of which can be used without omapfb driver. vram and vrfb can be
> > even used without omapdss driver.
> Even if I build the kernel with i386_defconfig, I get some compiled
> files within drivers/video/omap2.
>
> $ make ARCH=x86 i386_defconfig O=out_dir
> $ make ARCH=x86 O=out_dir
>
> $ ls out_dir/drivers/video/omap2
> built-in.o displays modules.builtin modules.order
>
> IMHO, drivers/video/omap2/ should not be compiled if the kernel is not
> built for omap2.
Ok. Yes, that's a known "problem". We could have a OMAPx check there,
but then again, the driver is a driver for the DSS HW, which could, at
least in theory, used in other SoCs.
I don't think any driver should normally depend on ARCH_something or
MACH_something.
I think this is more of a "problem" with the build system. The same
thing can be seen with, for example, drivers/video/backlight/ and
drivers/video/display/ directories. In practice the created files do not
affect the kernel in any way, as far as I see.
Tomi
^ permalink raw reply
* Re: [PATCH 1/2] config: omap2+: force fb and dss support as built-in
From: Tushar Behera @ 2011-06-21 5:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1308575086.2076.55.camel@deskari>
On Monday 20 June 2011 06:34 PM, Tomi Valkeinen wrote:
> On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote:
>> In certain board files, there are references to vram related functions
>> which are defined in drivers/video/omap2/vram.c. Because of this direct
>> dependency, CONFIG_FB_OMAP2 should be a built-in feature.
>
> arch/arm/plat-omap/include/plat/vram.h defines dummy inline function in
> case vram.c is not compiled in, so the board files should compile fine.
>
>> As per the current architecture, CONFIG_FB_OMAP2 is dependent on
>> CONFIG_OMAP2_DSS. Hence CONFIG_OMAP2_DSS support should also be selected
>> by default.
>
> The configuration is fine as it is. And anyway, if things do not compile
> when something is configured as a module, the correct fix is hardly just
> changing the feature to be compiled built-in =).
Agreed. :)
I am not an expert in DSS. I just wanted to raise my concern.
>
>> Cc: Tony Lindgren<tony@atomide.com>
>> Cc: Samreen<samreen@ti.com>
>> Signed-off-by: Tushar Behera<tushar.behera@linaro.org>
>> ---
>> arch/arm/mach-omap2/built-in.o: In function `rx51_video_mem_init':
>> linux-linaro-2.6.39/arch/arm/mach-omap2/board-rx51-video.c:97: undefined reference to `omap_vram_set_sdram_vram'
>> arch/arm/plat-omap/built-in.o: In function `omap_reserve':
>> linux-linaro-2.6.39/arch/arm/plat-omap/common.c:66: undefined reference to `omap_vram_reserve_sdram_memblock'
>> arch/arm/plat-omap/built-in.o: In function `omap_detect_sram':
>> linux-linaro-2.6.39/arch/arm/plat-omap/sram.c:179: undefined reference to `omap_vram_reserve_sram'
>> make[1]: *** [.tmp_vmlinux1] Error 1
>> make: *** [sub-make] Error 2
>
> Compiles fine for me. Perhaps you are using some old kernel?
As mentioned in the cover letter, we get this error only if 2/2 is
applied and 1/2 is not applied.
I tested this by applying 2/2 on v3.0-rc4 and using omap2plus_defconfig.
>
> Tomi
>
>
--
Tushar Behera
^ permalink raw reply
* Re: [PATCH 2/2] video: omap2: Compile omap2 support only when needed
From: Tushar Behera @ 2011-06-21 4:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1308575201.2076.57.camel@deskari>
Hi,
On Monday 20 June 2011 06:36 PM, Tomi Valkeinen wrote:
> On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote:
>> Currently display support for omap2 is selected by default and
>> it gets built for all the configurations.
>>
>> Instead of it being a built-in feature, it's compilation should
>> depend on the config option CONFIG_FB_OMAP2.
>
> No, I don't think so. omap2 directory contains vram, vrfb and omapdss,
> all of which can be used without omapfb driver. vram and vrfb can be
> even used without omapdss driver.
Even if I build the kernel with i386_defconfig, I get some compiled
files within drivers/video/omap2.
$ make ARCH=x86 i386_defconfig O=out_dir
$ make ARCH=x86 O=out_dir
$ ls out_dir/drivers/video/omap2
built-in.o displays modules.builtin modules.order
IMHO, drivers/video/omap2/ should not be compiled if the kernel is not
built for omap2.
>
> Is this patch fixing some real problem?
This patch does not fix any other problem.
>
> Tomi
>
>
--
Tushar Behera
^ permalink raw reply
* Re: Regression in panic
From: Mandeep Singh Baines @ 2011-06-20 23:20 UTC (permalink / raw)
To: David Rientjes
Cc: Dave Airlie, Andrew Morton, Jesse Barnes, Olof Johansson,
linux-fbdev, dri-devel, linux-kernel, Chris Fowler
In-Reply-To: <alpine.DEB.2.00.1106201601220.15259@chino.kir.corp.google.com>
On Mon, Jun 20, 2011 at 4:03 PM, David Rientjes <rientjes@google.com> wrote:
> On Mon, 20 Jun 2011, Mandeep Singh Baines wrote:
>
>> Hi Dave,
>>
>> I think this change is causing a regression I'm seeing in panic.
>> Before this change, I'd get a
>> reboot on panic (we've configured as such).
>>
>> With this change, my machine gets wedged if the machine is running in
>> X when the panic occurs.
>>
>> I traced the code flow to this:
>>
>> bust_spinlocks(0);
>> ->unblank_screen();
>> ->do_unblank_screen(0);
>> ->vc->vc_sw->con_blank(vc, 0, 0);
>> ->fbcon_blank(vc, 0, 0);
>> ->update_screen(vc);
>> ->redraw_screen(vc, 0);
>> ->vc->vc_sw->con_switch(vc);
>> ->fbcon_switch(vc);
>> ->ops->update_start(info);
>> ->bit_update_start(info);
>> ->fb_pan_display(info, &ops->var);
>> ->info->fbops->fb_pan_display(var, info);
>> ->drm_fb_helper_pan_display(var, info);
>> ->mutex_lock(&dev->mode_config.mutex); *this blocks*
>>
>> With this change, there is now a lot going on in the panic path. Stuff
>> that I'm not sure is safe when panicking. In addition to the
>> mutex_lock, there is also a del_timer_sync()
>> now happening in the context of panic().
>>
>> I see this bug with a 2.6.38 kernel but did a quick scan of a newer
>> kernels and did not see anything that changed in this path so I
>> suspect its still there.
>>
>> Reverting this change fixes the regression.
>>
>
> Chris Fowler reports something similar when running 2.6.38 by inducing a
> kernel panic via the oom killer -- see
> http://marc.info/?l=linux-kernel&m\x130805985022791. I've added him to the
> cc so he can participate in the thread and cherry-pick any fixes (last
> status update was that he was going to be trying 2.6.38.8).
>
One potential fix might be to convert the mutex_lock to a try if
oops_in_progress but
I suspect oops_in_progress checks may be needed in a bunch of other places in
the screen_unblank code path.
^ permalink raw reply
* Re: Regression in panic
From: David Rientjes @ 2011-06-20 23:03 UTC (permalink / raw)
To: Mandeep Singh Baines
Cc: Dave Airlie, Andrew Morton, Jesse Barnes, Olof Johansson,
linux-fbdev, dri-devel, linux-kernel, Chris Fowler
In-Reply-To: <BANLkTingstCoWk0H20nN1J7t3H=mndSdnL2YpeW2R46fhL2kpA@mail.gmail.com>
On Mon, 20 Jun 2011, Mandeep Singh Baines wrote:
> Hi Dave,
>
> I think this change is causing a regression I'm seeing in panic.
> Before this change, I'd get a
> reboot on panic (we've configured as such).
>
> With this change, my machine gets wedged if the machine is running in
> X when the panic occurs.
>
> I traced the code flow to this:
>
> bust_spinlocks(0);
> ->unblank_screen();
> ->do_unblank_screen(0);
> ->vc->vc_sw->con_blank(vc, 0, 0);
> ->fbcon_blank(vc, 0, 0);
> ->update_screen(vc);
> ->redraw_screen(vc, 0);
> ->vc->vc_sw->con_switch(vc);
> ->fbcon_switch(vc);
> ->ops->update_start(info);
> ->bit_update_start(info);
> ->fb_pan_display(info, &ops->var);
> ->info->fbops->fb_pan_display(var, info);
> ->drm_fb_helper_pan_display(var, info);
> ->mutex_lock(&dev->mode_config.mutex); *this blocks*
>
> With this change, there is now a lot going on in the panic path. Stuff
> that I'm not sure is safe when panicking. In addition to the
> mutex_lock, there is also a del_timer_sync()
> now happening in the context of panic().
>
> I see this bug with a 2.6.38 kernel but did a quick scan of a newer
> kernels and did not see anything that changed in this path so I
> suspect its still there.
>
> Reverting this change fixes the regression.
>
Chris Fowler reports something similar when running 2.6.38 by inducing a
kernel panic via the oom killer -- see
http://marc.info/?l=linux-kernel&m\x130805985022791. I've added him to the
cc so he can participate in the thread and cherry-pick any fixes (last
status update was that he was going to be trying 2.6.38.8).
^ permalink raw reply
* Regression in panic
From: Mandeep Singh Baines @ 2011-06-20 22:15 UTC (permalink / raw)
To: Dave Airlie, Andrew Morton, Jesse Barnes, Olof Johansson
Cc: linux-fbdev, dri-devel, linux-kernel
On Tue, Jun 22, 2010 at 8:12 PM, Dave Airlie <airlied@gmail.com> wrote:
> From: Jesse Barnes <jbarnes@virtuousgeek.org>
>
> Jesse's initial patch commit said:
>
> "At panic time (i.e. when oops_in_progress is set) we should try a bit
> harder to update the screen and make sure output gets to the VT, since
> some drivers are capable of flipping back to it.
>
> So make sure we try to unblank and update the display if called from a
> panic context."
>
> I've enhanced this to add a flag to the vc that console layer can set
> to indicate they want this behaviour to occur. This also adds support
> to fbcon for that flag and adds an fb flag for drivers to indicate
> they want to use the support. It enables this for KMS drivers.
>
> Signed-off-by: Dave Airlie <airlied@redhat.com>
Hi Dave,
I think this change is causing a regression I'm seeing in panic.
Before this change, I'd get a
reboot on panic (we've configured as such).
With this change, my machine gets wedged if the machine is running in
X when the panic occurs.
I traced the code flow to this:
bust_spinlocks(0);
->unblank_screen();
->do_unblank_screen(0);
->vc->vc_sw->con_blank(vc, 0, 0);
->fbcon_blank(vc, 0, 0);
->update_screen(vc);
->redraw_screen(vc, 0);
->vc->vc_sw->con_switch(vc);
->fbcon_switch(vc);
->ops->update_start(info);
->bit_update_start(info);
->fb_pan_display(info, &ops->var);
->info->fbops->fb_pan_display(var, info);
->drm_fb_helper_pan_display(var, info);
->mutex_lock(&dev->mode_config.mutex); *this blocks*
With this change, there is now a lot going on in the panic path. Stuff
that I'm not sure is safe when panicking. In addition to the
mutex_lock, there is also a del_timer_sync()
now happening in the context of panic().
I see this bug with a 2.6.38 kernel but did a quick scan of a newer
kernels and did not see anything that changed in this path so I
suspect its still there.
Reverting this change fixes the regression.
Regards,
Mandeep
> ---
> drivers/char/vt.c | 13 +++++++++----
> drivers/gpu/drm/i915/intel_fb.c | 4 +---
> drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 +
> drivers/gpu/drm/radeon/radeon_fb.c | 2 +-
> drivers/video/console/fbcon.c | 4 +++-
> include/linux/console_struct.h | 1 +
> include/linux/fb.h | 4 ++++
> include/linux/vt_kern.h | 7 +++++++
> 8 files changed, 27 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/char/vt.c b/drivers/char/vt.c
> index 7cdb6ee..6e04c9e 100644
> --- a/drivers/char/vt.c
> +++ b/drivers/char/vt.c
> @@ -698,7 +698,10 @@ void redraw_screen(struct vc_data *vc, int is_switch)
> update_attr(vc);
> clear_buffer_attributes(vc);
> }
> - if (update && vc->vc_mode != KD_GRAPHICS)
> +
> + /* Forcibly update if we're panicing */
> + if ((update && vc->vc_mode != KD_GRAPHICS) ||
> + vt_force_oops_output(vc))
> do_update_region(vc, vc->vc_origin, vc->vc_screenbuf_size / 2);
> }
> set_cursor(vc);
> @@ -736,6 +739,7 @@ static void visual_init(struct vc_data *vc, int num, int init)
> vc->vc_hi_font_mask = 0;
> vc->vc_complement_mask = 0;
> vc->vc_can_do_color = 0;
> + vc->vc_panic_force_write = false;
> vc->vc_sw->con_init(vc, init);
> if (!vc->vc_complement_mask)
> vc->vc_complement_mask = vc->vc_can_do_color ? 0x7700 : 0x0800;
> @@ -2498,7 +2502,7 @@ static void vt_console_print(struct console *co, const char *b, unsigned count)
> goto quit;
> }
>
> - if (vc->vc_mode != KD_TEXT)
> + if (vc->vc_mode != KD_TEXT && !vt_force_oops_output(vc))
> goto quit;
>
> /* undraw cursor first */
> @@ -3703,7 +3707,8 @@ void do_unblank_screen(int leaving_gfx)
> return;
> }
> vc = vc_cons[fg_console].d;
> - if (vc->vc_mode != KD_TEXT)
> + /* Try to unblank in oops case too */
> + if (vc->vc_mode != KD_TEXT && !vt_force_oops_output(vc))
> return; /* but leave console_blanked != 0 */
>
> if (blankinterval) {
> @@ -3712,7 +3717,7 @@ void do_unblank_screen(int leaving_gfx)
> }
>
> console_blanked = 0;
> - if (vc->vc_sw->con_blank(vc, 0, leaving_gfx))
> + if (vc->vc_sw->con_blank(vc, 0, leaving_gfx) || vt_force_oops_output(vc))
> /* Low-level driver cannot restore -> do it ourselves */
> update_screen(vc);
> if (console_blank_hook)
> diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
> index c3c5052..bd5d87a 100644
> --- a/drivers/gpu/drm/i915/intel_fb.c
> +++ b/drivers/gpu/drm/i915/intel_fb.c
> @@ -128,7 +128,7 @@ static int intelfb_create(struct intel_fbdev *ifbdev,
>
> strcpy(info->fix.id, "inteldrmfb");
>
> - info->flags = FBINFO_DEFAULT;
> + info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
> info->fbops = &intelfb_ops;
>
> /* setup aperture base/size for vesafb takeover */
> @@ -146,8 +146,6 @@ static int intelfb_create(struct intel_fbdev *ifbdev,
> info->fix.smem_start = dev->mode_config.fb_base + obj_priv->gtt_offset;
> info->fix.smem_len = size;
>
> - info->flags = FBINFO_DEFAULT;
> -
> info->screen_base = ioremap_wc(dev->agp->base + obj_priv->gtt_offset,
> size);
> if (!info->screen_base) {
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> index c9a4a0d..9b2d3b7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> @@ -250,6 +250,7 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
> info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_COPYAREA |
> FBINFO_HWACCEL_FILLRECT |
> FBINFO_HWACCEL_IMAGEBLIT;
> + info->flags |= FBINFO_CAN_FORCE_OUTPUT;
> info->fbops = &nouveau_fbcon_ops;
> info->fix.smem_start = dev->mode_config.fb_base + nvbo->bo.offset -
> dev_priv->vm_vram_base;
> diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c
> index dc1634b..dbf8696 100644
> --- a/drivers/gpu/drm/radeon/radeon_fb.c
> +++ b/drivers/gpu/drm/radeon/radeon_fb.c
> @@ -224,7 +224,7 @@ static int radeonfb_create(struct radeon_fbdev *rfbdev,
>
> drm_fb_helper_fill_fix(info, fb->pitch, fb->depth);
>
> - info->flags = FBINFO_DEFAULT;
> + info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
> info->fbops = &radeonfb_ops;
>
> tmp = radeon_bo_gpu_offset(rbo) - rdev->mc.vram_start;
> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> index b0a3fa0..7eadb35 100644
> --- a/drivers/video/console/fbcon.c
> +++ b/drivers/video/console/fbcon.c
> @@ -283,7 +283,8 @@ static inline int fbcon_is_inactive(struct vc_data *vc, struct fb_info *info)
> struct fbcon_ops *ops = info->fbcon_par;
>
> return (info->state != FBINFO_STATE_RUNNING ||
> - vc->vc_mode != KD_TEXT || ops->graphics);
> + vc->vc_mode != KD_TEXT || ops->graphics) &&
> + !vt_force_oops_output(vc);
> }
>
> static inline int get_color(struct vc_data *vc, struct fb_info *info,
> @@ -1073,6 +1074,7 @@ static void fbcon_init(struct vc_data *vc, int init)
> if (p->userfont)
> charcnt = FNTCHARCNT(p->fontdata);
>
> + vc->vc_panic_force_write = !!(info->flags & FBINFO_CAN_FORCE_OUTPUT);
> vc->vc_can_do_color = (fb_get_color_depth(&info->var, &info->fix)!=1);
> vc->vc_complement_mask = vc->vc_can_do_color ? 0x7700 : 0x0800;
> if (charcnt = 256) {
> diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
> index 38fe59d..d7d9acd 100644
> --- a/include/linux/console_struct.h
> +++ b/include/linux/console_struct.h
> @@ -105,6 +105,7 @@ struct vc_data {
> struct vc_data **vc_display_fg; /* [!] Ptr to var holding fg console for this display */
> unsigned long vc_uni_pagedir;
> unsigned long *vc_uni_pagedir_loc; /* [!] Location of uni_pagedir variable for this console */
> + bool vc_panic_force_write; /* when oops/panic this VC can accept forced output/blanking */
> /* additional information is in vt_kern.h */
> };
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 8e5a9df..25f4950 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -812,6 +812,10 @@ struct fb_tile_ops {
> */
> #define FBINFO_BE_MATH 0x100000
>
> +/* report to the VT layer that this fb driver can accept forced console
> + output like oopses */
> +#define FBINFO_CAN_FORCE_OUTPUT 0x200000
> +
> struct fb_info {
> int node;
> int flags;
> diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
> index 7f56db4..56cce34 100644
> --- a/include/linux/vt_kern.h
> +++ b/include/linux/vt_kern.h
> @@ -100,6 +100,13 @@ extern int unbind_con_driver(const struct consw *csw, int first, int last,
> int deflt);
> int vty_init(const struct file_operations *console_fops);
>
> +static inline bool vt_force_oops_output(struct vc_data *vc)
> +{
> + if (oops_in_progress && vc->vc_panic_force_write)
> + return true;
> + return false;
> +}
> +
> /*
> * vc_screen.c shares this temporary buffer with the console write code so that
> * we can easily avoid touching user space while holding the console spinlock.
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* [PATCH] locomo: drop special locomo_{read/write}l in favor of io{read/write}16
From: H Hartley Sweeten @ 2011-06-20 21:54 UTC (permalink / raw)
To: linux-arm-kernel
All the locomo registers are 16-bit ioremap'ed memory addresses.
Make the locomo drivers use generic purpose io routines: ioread16
and iowrite16 instead of directly accessing memory.
There are still a couple checkpatch warnings about lines exceeding
79 characters.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Lennert Buytenhek <buytenh@secretlab.ca>
---
diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index b55c362..3ced960 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -141,13 +141,14 @@ static struct locomo_dev_info locomo_devices[] = {
static void locomo_handler(unsigned int irq, struct irq_desc *desc)
{
struct locomo *lchip = irq_get_chip_data(irq);
- int req, i;
+ u16 req;
+ int i;
/* Acknowledge the parent IRQ */
desc->irq_data.chip->irq_ack(&desc->irq_data);
/* check why this interrupt was generated */
- req = locomo_readl(lchip->base + LOCOMO_ICR) & 0x0f00;
+ req = ioread16(lchip->base + LOCOMO_ICR) & 0x0f00;
if (req) {
/* generate the next interrupt(s) */
@@ -168,19 +169,21 @@ static void locomo_ack_irq(struct irq_data *d)
static void locomo_mask_irq(struct irq_data *d)
{
struct locomo *lchip = irq_data_get_irq_chip_data(d);
- unsigned int r;
- r = locomo_readl(lchip->base + LOCOMO_ICR);
+ u16 r;
+
+ r = ioread16(lchip->base + LOCOMO_ICR);
r &= ~(0x0010 << (d->irq - lchip->irq_base));
- locomo_writel(r, lchip->base + LOCOMO_ICR);
+ iowrite16(r, lchip->base + LOCOMO_ICR);
}
static void locomo_unmask_irq(struct irq_data *d)
{
struct locomo *lchip = irq_data_get_irq_chip_data(d);
- unsigned int r;
- r = locomo_readl(lchip->base + LOCOMO_ICR);
+ u16 r;
+
+ r = ioread16(lchip->base + LOCOMO_ICR);
r |= (0x0010 << (d->irq - lchip->irq_base));
- locomo_writel(r, lchip->base + LOCOMO_ICR);
+ iowrite16(r, lchip->base + LOCOMO_ICR);
}
static struct irq_chip locomo_chip = {
@@ -265,11 +268,11 @@ locomo_init_one_child(struct locomo *lchip, struct locomo_dev_info *info)
#ifdef CONFIG_PM
struct locomo_save_data {
- u16 LCM_GPO;
- u16 LCM_SPICT;
- u16 LCM_GPE;
- u16 LCM_ASD;
- u16 LCM_SPIMD;
+ u16 LCM_GPO; /* GPIO */
+ u16 LCM_SPICT; /* SPI */
+ u16 LCM_GPE; /* GPIO */
+ u16 LCM_ASD; /* ADSTART */
+ u16 LCM_SPIMD; /* SPI */
};
static int locomo_suspend(struct platform_device *dev, pm_message_t state)
@@ -286,30 +289,31 @@ static int locomo_suspend(struct platform_device *dev, pm_message_t state)
spin_lock_irqsave(&lchip->lock, flags);
- save->LCM_GPO = locomo_readl(lchip->base + LOCOMO_GPO); /* GPIO */
- locomo_writel(0x00, lchip->base + LOCOMO_GPO);
- save->LCM_SPICT = locomo_readl(lchip->base + LOCOMO_SPI + LOCOMO_SPICT); /* SPI */
- locomo_writel(0x40, lchip->base + LOCOMO_SPI + LOCOMO_SPICT);
- save->LCM_GPE = locomo_readl(lchip->base + LOCOMO_GPE); /* GPIO */
- locomo_writel(0x00, lchip->base + LOCOMO_GPE);
- save->LCM_ASD = locomo_readl(lchip->base + LOCOMO_ASD); /* ADSTART */
- locomo_writel(0x00, lchip->base + LOCOMO_ASD);
- save->LCM_SPIMD = locomo_readl(lchip->base + LOCOMO_SPI + LOCOMO_SPIMD); /* SPI */
- locomo_writel(0x3C14, lchip->base + LOCOMO_SPI + LOCOMO_SPIMD);
-
- locomo_writel(0x00, lchip->base + LOCOMO_PAIF);
- locomo_writel(0x00, lchip->base + LOCOMO_DAC);
- locomo_writel(0x00, lchip->base + LOCOMO_BACKLIGHT + LOCOMO_TC);
-
- if ((locomo_readl(lchip->base + LOCOMO_LED + LOCOMO_LPT0) & 0x88) && (locomo_readl(lchip->base + LOCOMO_LED + LOCOMO_LPT1) & 0x88))
- locomo_writel(0x00, lchip->base + LOCOMO_C32K); /* CLK32 off */
+ save->LCM_GPO = ioread16(lchip->base + LOCOMO_GPO);
+ save->LCM_SPICT = ioread16(lchip->base + LOCOMO_SPI + LOCOMO_SPICT);
+ save->LCM_GPE = ioread16(lchip->base + LOCOMO_GPE);
+ save->LCM_ASD = ioread16(lchip->base + LOCOMO_ASD);
+ save->LCM_SPIMD = ioread16(lchip->base + LOCOMO_SPI + LOCOMO_SPIMD);
+ iowrite16(0x00, lchip->base + LOCOMO_GPO);
+ iowrite16(0x40, lchip->base + LOCOMO_SPI + LOCOMO_SPICT);
+ iowrite16(0x00, lchip->base + LOCOMO_GPE);
+ iowrite16(0x00, lchip->base + LOCOMO_ASD);
+ iowrite16(0x3C14, lchip->base + LOCOMO_SPI + LOCOMO_SPIMD);
+
+ iowrite16(0x00, lchip->base + LOCOMO_PAIF);
+ iowrite16(0x00, lchip->base + LOCOMO_DAC);
+ iowrite16(0x00, lchip->base + LOCOMO_BACKLIGHT + LOCOMO_TC);
+
+ if ((ioread16(lchip->base + LOCOMO_LED + LOCOMO_LPT0) & 0x88) &&
+ (ioread16(lchip->base + LOCOMO_LED + LOCOMO_LPT1) & 0x88))
+ iowrite16(0x00, lchip->base + LOCOMO_C32K); /* CLK32 off */
else
/* 18MHz already enabled, so no wait */
- locomo_writel(0xc1, lchip->base + LOCOMO_C32K); /* CLK32 on */
+ iowrite16(0xc1, lchip->base + LOCOMO_C32K); /* CLK32 on */
- locomo_writel(0x00, lchip->base + LOCOMO_TADC); /* 18MHz clock off*/
- locomo_writel(0x00, lchip->base + LOCOMO_AUDIO + LOCOMO_ACC); /* 22MHz/24MHz clock off */
- locomo_writel(0x00, lchip->base + LOCOMO_FRONTLIGHT + LOCOMO_ALS); /* FL */
+ iowrite16(0x00, lchip->base + LOCOMO_TADC); /* 18MHz clock off*/
+ iowrite16(0x00, lchip->base + LOCOMO_AUDIO + LOCOMO_ACC); /* 22MHz/24MHz clock off */
+ iowrite16(0x00, lchip->base + LOCOMO_FRONTLIGHT + LOCOMO_ALS); /* FL */
spin_unlock_irqrestore(&lchip->lock, flags);
@@ -320,7 +324,7 @@ static int locomo_resume(struct platform_device *dev)
{
struct locomo *lchip = platform_get_drvdata(dev);
struct locomo_save_data *save;
- unsigned long r;
+ u16 r;
unsigned long flags;
save = lchip->saved_state;
@@ -329,20 +333,20 @@ static int locomo_resume(struct platform_device *dev)
spin_lock_irqsave(&lchip->lock, flags);
- locomo_writel(save->LCM_GPO, lchip->base + LOCOMO_GPO);
- locomo_writel(save->LCM_SPICT, lchip->base + LOCOMO_SPI + LOCOMO_SPICT);
- locomo_writel(save->LCM_GPE, lchip->base + LOCOMO_GPE);
- locomo_writel(save->LCM_ASD, lchip->base + LOCOMO_ASD);
- locomo_writel(save->LCM_SPIMD, lchip->base + LOCOMO_SPI + LOCOMO_SPIMD);
+ iowrite16(save->LCM_GPO, lchip->base + LOCOMO_GPO);
+ iowrite16(save->LCM_SPICT, lchip->base + LOCOMO_SPI + LOCOMO_SPICT);
+ iowrite16(save->LCM_GPE, lchip->base + LOCOMO_GPE);
+ iowrite16(save->LCM_ASD, lchip->base + LOCOMO_ASD);
+ iowrite16(save->LCM_SPIMD, lchip->base + LOCOMO_SPI + LOCOMO_SPIMD);
- locomo_writel(0x00, lchip->base + LOCOMO_C32K);
- locomo_writel(0x90, lchip->base + LOCOMO_TADC);
+ iowrite16(0x00, lchip->base + LOCOMO_C32K);
+ iowrite16(0x90, lchip->base + LOCOMO_TADC);
- locomo_writel(0, lchip->base + LOCOMO_KEYBOARD + LOCOMO_KSC);
- r = locomo_readl(lchip->base + LOCOMO_KEYBOARD + LOCOMO_KIC);
+ iowrite16(0, lchip->base + LOCOMO_KEYBOARD + LOCOMO_KSC);
+ r = ioread16(lchip->base + LOCOMO_KEYBOARD + LOCOMO_KIC);
r &= 0xFEFF;
- locomo_writel(r, lchip->base + LOCOMO_KEYBOARD + LOCOMO_KIC);
- locomo_writel(0x1, lchip->base + LOCOMO_KEYBOARD + LOCOMO_KCMD);
+ iowrite16(r, lchip->base + LOCOMO_KEYBOARD + LOCOMO_KIC);
+ iowrite16(0x1, lchip->base + LOCOMO_KEYBOARD + LOCOMO_KCMD);
spin_unlock_irqrestore(&lchip->lock, flags);
@@ -371,7 +375,7 @@ __locomo_probe(struct device *me, struct resource *mem, int irq)
{
struct locomo_platform_data *pdata = me->platform_data;
struct locomo *lchip;
- unsigned long r;
+ u16 r;
int i, ret = -ENODEV;
lchip = kzalloc(sizeof(struct locomo), GFP_KERNEL);
@@ -398,54 +402,53 @@ __locomo_probe(struct device *me, struct resource *mem, int irq)
}
/* locomo initialize */
- locomo_writel(0, lchip->base + LOCOMO_ICR);
+ iowrite16(0, lchip->base + LOCOMO_ICR);
/* KEYBOARD */
- locomo_writel(0, lchip->base + LOCOMO_KEYBOARD + LOCOMO_KIC);
+ iowrite16(0, lchip->base + LOCOMO_KEYBOARD + LOCOMO_KIC);
/* GPIO */
- locomo_writel(0, lchip->base + LOCOMO_GPO);
- locomo_writel((LOCOMO_GPIO(1) | LOCOMO_GPIO(2) | LOCOMO_GPIO(13) | LOCOMO_GPIO(14))
- , lchip->base + LOCOMO_GPE);
- locomo_writel((LOCOMO_GPIO(1) | LOCOMO_GPIO(2) | LOCOMO_GPIO(13) | LOCOMO_GPIO(14))
- , lchip->base + LOCOMO_GPD);
- locomo_writel(0, lchip->base + LOCOMO_GIE);
+ iowrite16(0, lchip->base + LOCOMO_GPO);
+ r = LOCOMO_GPIO(1) | LOCOMO_GPIO(2) | LOCOMO_GPIO(13) | LOCOMO_GPIO(14);
+ iowrite16(r, lchip->base + LOCOMO_GPE);
+ iowrite16(r, lchip->base + LOCOMO_GPD);
+ iowrite16(0, lchip->base + LOCOMO_GIE);
/* Frontlight */
- locomo_writel(0, lchip->base + LOCOMO_FRONTLIGHT + LOCOMO_ALS);
- locomo_writel(0, lchip->base + LOCOMO_FRONTLIGHT + LOCOMO_ALD);
+ iowrite16(0, lchip->base + LOCOMO_FRONTLIGHT + LOCOMO_ALS);
+ iowrite16(0, lchip->base + LOCOMO_FRONTLIGHT + LOCOMO_ALD);
/* Longtime timer */
- locomo_writel(0, lchip->base + LOCOMO_LTINT);
+ iowrite16(0, lchip->base + LOCOMO_LTINT);
/* SPI */
- locomo_writel(0, lchip->base + LOCOMO_SPI + LOCOMO_SPIIE);
+ iowrite16(0, lchip->base + LOCOMO_SPI + LOCOMO_SPIIE);
- locomo_writel(6 + 8 + 320 + 30 - 10, lchip->base + LOCOMO_ASD);
- r = locomo_readl(lchip->base + LOCOMO_ASD);
+ iowrite16(6 + 8 + 320 + 30 - 10, lchip->base + LOCOMO_ASD);
+ r = ioread16(lchip->base + LOCOMO_ASD);
r |= 0x8000;
- locomo_writel(r, lchip->base + LOCOMO_ASD);
+ iowrite16(r, lchip->base + LOCOMO_ASD);
- locomo_writel(6 + 8 + 320 + 30 - 10 - 128 + 4, lchip->base + LOCOMO_HSD);
- r = locomo_readl(lchip->base + LOCOMO_HSD);
+ iowrite16(6 + 8 + 320 + 30 - 10 - 128 + 4, lchip->base + LOCOMO_HSD);
+ r = ioread16(lchip->base + LOCOMO_HSD);
r |= 0x8000;
- locomo_writel(r, lchip->base + LOCOMO_HSD);
+ iowrite16(r, lchip->base + LOCOMO_HSD);
- locomo_writel(128 / 8, lchip->base + LOCOMO_HSC);
+ iowrite16(128 / 8, lchip->base + LOCOMO_HSC);
/* XON */
- locomo_writel(0x80, lchip->base + LOCOMO_TADC);
+ iowrite16(0x80, lchip->base + LOCOMO_TADC);
udelay(1000);
/* CLK9MEN */
- r = locomo_readl(lchip->base + LOCOMO_TADC);
+ r = ioread16(lchip->base + LOCOMO_TADC);
r |= 0x10;
- locomo_writel(r, lchip->base + LOCOMO_TADC);
+ iowrite16(r, lchip->base + LOCOMO_TADC);
udelay(100);
/* init DAC */
- r = locomo_readl(lchip->base + LOCOMO_DAC);
+ r = ioread16(lchip->base + LOCOMO_DAC);
r |= LOCOMO_DAC_SCLOEB | LOCOMO_DAC_SDAOEB;
- locomo_writel(r, lchip->base + LOCOMO_DAC);
+ iowrite16(r, lchip->base + LOCOMO_DAC);
- r = locomo_readl(lchip->base + LOCOMO_VER);
+ r = ioread16(lchip->base + LOCOMO_VER);
printk(KERN_INFO "LoCoMo Chip: %lu%lu\n", (r >> 8), (r & 0xff));
/*
@@ -541,26 +544,26 @@ void locomo_gpio_set_dir(struct device *dev, unsigned int bits, unsigned int dir
{
struct locomo *lchip = dev_get_drvdata(dev);
unsigned long flags;
- unsigned int r;
+ u16 r;
if (!lchip)
return;
spin_lock_irqsave(&lchip->lock, flags);
- r = locomo_readl(lchip->base + LOCOMO_GPD);
+ r = ioread16(lchip->base + LOCOMO_GPD);
if (dir)
r |= bits;
else
r &= ~bits;
- locomo_writel(r, lchip->base + LOCOMO_GPD);
+ iowrite16(r, lchip->base + LOCOMO_GPD);
- r = locomo_readl(lchip->base + LOCOMO_GPE);
+ r = ioread16(lchip->base + LOCOMO_GPE);
if (dir)
r |= bits;
else
r &= ~bits;
- locomo_writel(r, lchip->base + LOCOMO_GPE);
+ iowrite16(r, lchip->base + LOCOMO_GPE);
spin_unlock_irqrestore(&lchip->lock, flags);
}
@@ -570,13 +573,13 @@ int locomo_gpio_read_level(struct device *dev, unsigned int bits)
{
struct locomo *lchip = dev_get_drvdata(dev);
unsigned long flags;
- unsigned int ret;
+ u16 ret;
if (!lchip)
return -ENODEV;
spin_lock_irqsave(&lchip->lock, flags);
- ret = locomo_readl(lchip->base + LOCOMO_GPL);
+ ret = ioread16(lchip->base + LOCOMO_GPL);
spin_unlock_irqrestore(&lchip->lock, flags);
ret &= bits;
@@ -588,13 +591,13 @@ int locomo_gpio_read_output(struct device *dev, unsigned int bits)
{
struct locomo *lchip = dev_get_drvdata(dev);
unsigned long flags;
- unsigned int ret;
+ u16 ret;
if (!lchip)
return -ENODEV;
spin_lock_irqsave(&lchip->lock, flags);
- ret = locomo_readl(lchip->base + LOCOMO_GPO);
+ ret = ioread16(lchip->base + LOCOMO_GPO);
spin_unlock_irqrestore(&lchip->lock, flags);
ret &= bits;
@@ -606,19 +609,19 @@ void locomo_gpio_write(struct device *dev, unsigned int bits, unsigned int set)
{
struct locomo *lchip = dev_get_drvdata(dev);
unsigned long flags;
- unsigned int r;
+ u16 r;
if (!lchip)
return;
spin_lock_irqsave(&lchip->lock, flags);
- r = locomo_readl(lchip->base + LOCOMO_GPO);
+ r = ioread16(lchip->base + LOCOMO_GPO);
if (set)
r |= bits;
else
r &= ~bits;
- locomo_writel(r, lchip->base + LOCOMO_GPO);
+ iowrite16(r, lchip->base + LOCOMO_GPO);
spin_unlock_irqrestore(&lchip->lock, flags);
}
@@ -626,35 +629,35 @@ EXPORT_SYMBOL(locomo_gpio_write);
static void locomo_m62332_sendbit(void *mapbase, int bit)
{
- unsigned int r;
+ u16 r;
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r &= ~(LOCOMO_DAC_SCLOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
udelay(DAC_DATA_HOLD_TIME); /* 300 nsec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r &= ~(LOCOMO_DAC_SCLOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
udelay(DAC_SCL_LOW_HOLD_TIME); /* 4.7 usec */
if (bit & 1) {
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r |= LOCOMO_DAC_SDAOEB;
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_HIGH_SETUP_TIME); /* 1000 nsec */
} else {
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r &= ~(LOCOMO_DAC_SDAOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
}
udelay(DAC_DATA_SETUP_TIME); /* 250 nsec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r |= LOCOMO_DAC_SCLOEB;
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_HIGH_SETUP_TIME); /* 1000 nsec */
udelay(DAC_SCL_HIGH_HOLD_TIME); /* 4.0 usec */
}
@@ -664,7 +667,7 @@ void locomo_m62332_senddata(struct locomo_dev *ldev, unsigned int dac_data, int
struct locomo *lchip = locomo_chip_driver(ldev);
int i;
unsigned char data;
- unsigned int r;
+ u16 r;
void *mapbase = lchip->base;
unsigned long flags;
@@ -672,14 +675,14 @@ void locomo_m62332_senddata(struct locomo_dev *ldev, unsigned int dac_data, int
/* Start */
udelay(DAC_BUS_FREE_TIME); /* 5.0 usec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r |= LOCOMO_DAC_SCLOEB | LOCOMO_DAC_SDAOEB;
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_HIGH_SETUP_TIME); /* 1000 nsec */
udelay(DAC_SCL_HIGH_HOLD_TIME); /* 4.0 usec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r &= ~(LOCOMO_DAC_SDAOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_START_HOLD_TIME); /* 5.0 usec */
udelay(DAC_DATA_HOLD_TIME); /* 300 nsec */
@@ -690,21 +693,21 @@ void locomo_m62332_senddata(struct locomo_dev *ldev, unsigned int dac_data, int
}
/* Check A bit */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r &= ~(LOCOMO_DAC_SCLOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
udelay(DAC_SCL_LOW_HOLD_TIME); /* 4.7 usec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r &= ~(LOCOMO_DAC_SDAOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r |= LOCOMO_DAC_SCLOEB;
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_HIGH_SETUP_TIME); /* 1000 nsec */
udelay(DAC_SCL_HIGH_HOLD_TIME); /* 4.7 usec */
- if (locomo_readl(mapbase + LOCOMO_DAC) & LOCOMO_DAC_SDAOEB) { /* High is error */
+ if (ioread16(mapbase + LOCOMO_DAC) & LOCOMO_DAC_SDAOEB) { /* High is error */
printk(KERN_WARNING "locomo: m62332_senddata Error 1\n");
goto out;
}
@@ -718,21 +721,21 @@ void locomo_m62332_senddata(struct locomo_dev *ldev, unsigned int dac_data, int
}
/* Check A bit */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r &= ~(LOCOMO_DAC_SCLOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
udelay(DAC_SCL_LOW_HOLD_TIME); /* 4.7 usec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r &= ~(LOCOMO_DAC_SDAOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r |= LOCOMO_DAC_SCLOEB;
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_HIGH_SETUP_TIME); /* 1000 nsec */
udelay(DAC_SCL_HIGH_HOLD_TIME); /* 4.7 usec */
- if (locomo_readl(mapbase + LOCOMO_DAC) & LOCOMO_DAC_SDAOEB) { /* High is error */
+ if (ioread16(mapbase + LOCOMO_DAC) & LOCOMO_DAC_SDAOEB) { /* High is error */
printk(KERN_WARNING "locomo: m62332_senddata Error 2\n");
goto out;
}
@@ -743,45 +746,45 @@ void locomo_m62332_senddata(struct locomo_dev *ldev, unsigned int dac_data, int
}
/* Check A bit */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r &= ~(LOCOMO_DAC_SCLOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
udelay(DAC_SCL_LOW_HOLD_TIME); /* 4.7 usec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r &= ~(LOCOMO_DAC_SDAOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r |= LOCOMO_DAC_SCLOEB;
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_HIGH_SETUP_TIME); /* 1000 nsec */
udelay(DAC_SCL_HIGH_HOLD_TIME); /* 4.7 usec */
- if (locomo_readl(mapbase + LOCOMO_DAC) & LOCOMO_DAC_SDAOEB) { /* High is error */
+ if (ioread16(mapbase + LOCOMO_DAC) & LOCOMO_DAC_SDAOEB) { /* High is error */
printk(KERN_WARNING "locomo: m62332_senddata Error 3\n");
}
out:
/* stop */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r &= ~(LOCOMO_DAC_SCLOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
udelay(DAC_SCL_LOW_HOLD_TIME); /* 4.7 usec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r |= LOCOMO_DAC_SCLOEB;
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_HIGH_SETUP_TIME); /* 1000 nsec */
udelay(DAC_SCL_HIGH_HOLD_TIME); /* 4 usec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r |= LOCOMO_DAC_SDAOEB;
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_HIGH_SETUP_TIME); /* 1000 nsec */
udelay(DAC_SCL_HIGH_HOLD_TIME); /* 4 usec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
+ r = ioread16(mapbase + LOCOMO_DAC);
r |= LOCOMO_DAC_SCLOEB | LOCOMO_DAC_SDAOEB;
- locomo_writel(r, mapbase + LOCOMO_DAC);
+ iowrite16(r, mapbase + LOCOMO_DAC);
udelay(DAC_LOW_SETUP_TIME); /* 1000 nsec */
udelay(DAC_SCL_LOW_HOLD_TIME); /* 4.7 usec */
@@ -804,10 +807,10 @@ void locomo_frontlight_set(struct locomo_dev *dev, int duty, int vr, int bpwf)
locomo_gpio_write(dev->dev.parent, LOCOMO_GPIO_FL_VR, 0);
spin_lock_irqsave(&lchip->lock, flags);
- locomo_writel(bpwf, lchip->base + LOCOMO_FRONTLIGHT + LOCOMO_ALS);
+ iowrite16(bpwf, lchip->base + LOCOMO_FRONTLIGHT + LOCOMO_ALS);
udelay(100);
- locomo_writel(duty, lchip->base + LOCOMO_FRONTLIGHT + LOCOMO_ALD);
- locomo_writel(bpwf | LOCOMO_ALC_EN, lchip->base + LOCOMO_FRONTLIGHT + LOCOMO_ALS);
+ iowrite16(duty, lchip->base + LOCOMO_FRONTLIGHT + LOCOMO_ALD);
+ iowrite16(bpwf | LOCOMO_ALC_EN, lchip->base + LOCOMO_FRONTLIGHT + LOCOMO_ALS);
spin_unlock_irqrestore(&lchip->lock, flags);
}
EXPORT_SYMBOL(locomo_frontlight_set);
diff --git a/arch/arm/include/asm/hardware/locomo.h b/arch/arm/include/asm/hardware/locomo.h
index 74e51d6..dc90c21 100644
--- a/arch/arm/include/asm/hardware/locomo.h
+++ b/arch/arm/include/asm/hardware/locomo.h
@@ -13,9 +13,6 @@
#ifndef _ASM_ARCH_LOCOMO
#define _ASM_ARCH_LOCOMO
-#define locomo_writel(val,addr) ({ *(volatile u16 *)(addr) = (val); })
-#define locomo_readl(addr) (*(volatile u16 *)(addr))
-
/* LOCOMO version */
#define LOCOMO_VER 0x00
diff --git a/drivers/input/keyboard/locomokbd.c b/drivers/input/keyboard/locomokbd.c
index b1ab298..ddb9595 100644
--- a/drivers/input/keyboard/locomokbd.c
+++ b/drivers/input/keyboard/locomokbd.c
@@ -31,6 +31,7 @@
#include <linux/device.h>
#include <linux/interrupt.h>
#include <linux/ioport.h>
+#include <linux/io.h>
#include <asm/hardware/locomo.h>
#include <asm/irq.h>
@@ -86,35 +87,35 @@ struct locomokbd {
/* helper functions for reading the keyboard matrix */
static inline void locomokbd_charge_all(unsigned long membase)
{
- locomo_writel(0x00FF, membase + LOCOMO_KSC);
+ iowrite16(0x00FF, membase + LOCOMO_KSC);
}
static inline void locomokbd_activate_all(unsigned long membase)
{
- unsigned long r;
+ u16 r;
- locomo_writel(0, membase + LOCOMO_KSC);
- r = locomo_readl(membase + LOCOMO_KIC);
+ iowrite16(0, membase + LOCOMO_KSC);
+ r = ioread16(membase + LOCOMO_KIC);
r &= 0xFEFF;
- locomo_writel(r, membase + LOCOMO_KIC);
+ iowrite16(r, membase + LOCOMO_KIC);
}
static inline void locomokbd_activate_col(unsigned long membase, int col)
{
- unsigned short nset;
- unsigned short nbset;
+ u16 nset;
+ u16 nbset;
nset = 0xFF & ~(1 << col);
nbset = (nset << 8) + nset;
- locomo_writel(nbset, membase + LOCOMO_KSC);
+ iowrite16(nbset, membase + LOCOMO_KSC);
}
static inline void locomokbd_reset_col(unsigned long membase, int col)
{
- unsigned short nbset;
+ u16 nbset;
nbset = ((0xFF & ~(1 << col)) << 8) + 0xFF;
- locomo_writel(nbset, membase + LOCOMO_KSC);
+ iowrite16(nbset, membase + LOCOMO_KSC);
}
/*
@@ -126,7 +127,7 @@ static inline void locomokbd_reset_col(unsigned long membase, int col)
/* Scan the hardware keyboard and push any changes up through the input layer */
static void locomokbd_scankeyboard(struct locomokbd *locomokbd)
{
- unsigned int row, col, rowd;
+ u16 row, col, rowd;
unsigned long flags;
unsigned int num_pressed;
unsigned long membase = locomokbd->base;
@@ -141,7 +142,7 @@ static void locomokbd_scankeyboard(struct locomokbd *locomokbd)
locomokbd_activate_col(membase, col);
udelay(KB_DELAY);
- rowd = ~locomo_readl(membase + LOCOMO_KIB);
+ rowd = ~ioread16(membase + LOCOMO_KIB);
for (row = 0; row < KB_ROWS; row++) {
unsigned int scancode, pressed, key;
@@ -194,11 +195,11 @@ static irqreturn_t locomokbd_interrupt(int irq, void *dev_id)
struct locomokbd *locomokbd = dev_id;
u16 r;
- r = locomo_readl(locomokbd->base + LOCOMO_KIC);
+ r = ioread16(locomokbd->base + LOCOMO_KIC);
if ((r & 0x0001) = 0)
return IRQ_HANDLED;
- locomo_writel(r & ~0x0100, locomokbd->base + LOCOMO_KIC); /* Ack */
+ iowrite16(r & ~0x0100, locomokbd->base + LOCOMO_KIC); /* Ack */
/** wait chattering delay **/
udelay(100);
@@ -222,8 +223,8 @@ static int locomokbd_open(struct input_dev *dev)
struct locomokbd *locomokbd = input_get_drvdata(dev);
u16 r;
- r = locomo_readl(locomokbd->base + LOCOMO_KIC) | 0x0010;
- locomo_writel(r, locomokbd->base + LOCOMO_KIC);
+ r = ioread16(locomokbd->base + LOCOMO_KIC) | 0x0010;
+ iowrite16(r, locomokbd->base + LOCOMO_KIC);
return 0;
}
@@ -232,8 +233,8 @@ static void locomokbd_close(struct input_dev *dev)
struct locomokbd *locomokbd = input_get_drvdata(dev);
u16 r;
- r = locomo_readl(locomokbd->base + LOCOMO_KIC) & ~0x0010;
- locomo_writel(r, locomokbd->base + LOCOMO_KIC);
+ r = ioread16(locomokbd->base + LOCOMO_KIC) & ~0x0010;
+ iowrite16(r, locomokbd->base + LOCOMO_KIC);
}
static int __devinit locomokbd_probe(struct locomo_dev *dev)
diff --git a/drivers/leds/leds-locomo.c b/drivers/leds/leds-locomo.c
index 1f7c10f..6cc6b69 100644
--- a/drivers/leds/leds-locomo.c
+++ b/drivers/leds/leds-locomo.c
@@ -12,6 +12,7 @@
#include <linux/init.h>
#include <linux/device.h>
#include <linux/leds.h>
+#include <linux/io.h>
#include <mach/hardware.h>
#include <asm/hardware/locomo.h>
@@ -24,9 +25,9 @@ static void locomoled_brightness_set(struct led_classdev *led_cdev,
local_irq_save(flags);
if (value)
- locomo_writel(LOCOMO_LPT_TOFH, locomo_dev->mapbase + offset);
+ iowrite16(LOCOMO_LPT_TOFH, locomo_dev->mapbase + offset);
else
- locomo_writel(LOCOMO_LPT_TOFL, locomo_dev->mapbase + offset);
+ iowrite16(LOCOMO_LPT_TOFL, locomo_dev->mapbase + offset);
local_irq_restore(flags);
}
diff --git a/drivers/video/backlight/locomolcd.c b/drivers/video/backlight/locomolcd.c
index be20b5c..37f325c 100644
--- a/drivers/video/backlight/locomolcd.c
+++ b/drivers/video/backlight/locomolcd.c
@@ -18,6 +18,7 @@
#include <linux/interrupt.h>
#include <linux/fb.h>
#include <linux/backlight.h>
+#include <linux/io.h>
#include <asm/hardware/locomo.h>
#include <asm/irq.h>
@@ -49,13 +50,13 @@ static void locomolcd_on(int comadj)
mdelay(10);
/* TFTCRST | CPSOUT=0 | CPSEN */
- locomo_writel(0x01, locomolcd_dev->mapbase + LOCOMO_TC);
+ iowrite16(0x01, locomolcd_dev->mapbase + LOCOMO_TC);
/* Set CPSD */
- locomo_writel(6, locomolcd_dev->mapbase + LOCOMO_CPSD);
+ iowrite16(6, locomolcd_dev->mapbase + LOCOMO_CPSD);
/* TFTCRST | CPSOUT=0 | CPSEN */
- locomo_writel((0x04 | 0x01), locomolcd_dev->mapbase + LOCOMO_TC);
+ iowrite16((0x04 | 0x01), locomolcd_dev->mapbase + LOCOMO_TC);
mdelay(10);
locomo_gpio_set_dir(locomolcd_dev->dev.parent, LOCOMO_GPIO_LCD_MOD, 0);
@@ -65,7 +66,7 @@ static void locomolcd_on(int comadj)
static void locomolcd_off(int comadj)
{
/* TFTCRST=1 | CPSOUT=1 | CPSEN = 0 */
- locomo_writel(0x06, locomolcd_dev->mapbase + LOCOMO_TC);
+ iowrite16(0x06, locomolcd_dev->mapbase + LOCOMO_TC);
mdelay(1);
locomo_gpio_write(locomolcd_dev->dev.parent, LOCOMO_GPIO_LCD_VSHA_ON, 0);
@@ -75,7 +76,7 @@ static void locomolcd_off(int comadj)
mdelay(700);
/* TFTCRST=0 | CPSOUT=0 | CPSEN = 0 */
- locomo_writel(0, locomolcd_dev->mapbase + LOCOMO_TC);
+ iowrite16(0, locomolcd_dev->mapbase + LOCOMO_TC);
locomo_gpio_write(locomolcd_dev->dev.parent, LOCOMO_GPIO_LCD_MOD, 0);
locomo_gpio_write(locomolcd_dev->dev.parent, LOCOMO_GPIO_LCD_VSHD_ON, 0);
}
^ permalink raw reply related
* Re: Framebuffer driver for controller with indirect addressing?
From: Steve Strobel @ 2011-06-20 21:02 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <0LlUqt-1Pye1R36EZ-00bCDF@mrelay.perfora.net>
At 06:18 PM 6/17/2011, Bernie Thompson wrote:
>On Fri, Jun 17, 2011 at 4:10 PM, Steve Strobel
><steve.strobel@link-comm.com> wrote:
> > It does not have address lines, so the framebuffer memory
> > is not directly accessible
> >
> > If someone could point me to a driver that works in a similar way, it would
> > help me out a lot. Â Thanks.
>
>Hi Steve - there are several drivers that handle this kind of case,
>including the udlfb driver for DisplayLink USB graphics chips (in the
>kernel tree /drivers/video/udlfb.c)
That helps a lot. I will check it out. Is there
something other than the source code that I
should read to get up to speed on it?
>The main unsolved challenge is fbdev (in the memory mapped framebuffer
>case) assumes writes to the framebuffer take effect immediately. [snip]
If I am understanding you right, the challenge is
knowing when to flush the changed framebuffer memory to the graphics hardware.
>1) Use of /driver/video/fb_defio.c to use the MMU to trigger...
I don't know if a Blackfin system could support
that method or not. It doesn't have a full MMU
with virtual memory (it runs uClinux), but it
does have a memory protection unit. I suppose
all that would be needed is to be notified when
the framebuffer memory is written to; I think it could do that.
>2) Use of an ioctl to allow the user mode client to inform the
>framebuffer of changed pixels (usually xorg forwarding X DAMAGE
>notifications, which are well matched for this purpose). This works
>well and is simple, however we don't yet have a standardized ioctl, so
>several drivers have different ioctls and thus custom x servers,
>instead of being supported by the standard xf86-video-fbdev driver.
Since this is a custom embedded system, we are in
control of all of the software on it. So we can
just make sure that everything included is set up for the same ioctl.
>#2 would be the quickest way to give Linux a clean way of handling
>remote (non-directly-addressable) framebuffers.
>
>Others may have some additional suggestions.
Someone suggested to me using the double-buffer
flipping logic. Does it get flipped on every
screen refresh, or just when the contents of one buffer have been changed?
>Hope that helps. Best wishes,
>Bernie
>http://plugable.com/
Thanks a bunch,
Steve
---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:steve.strobel@link-comm.com
^ permalink raw reply
* [PATCH] ARM: amba: Link fb device to its parent
From: Loïc Minier @ 2011-06-20 20:44 UTC (permalink / raw)
To: linux-arm-kernel
Some pieces of userspace like debian-installer expect to find the fb0
driver name by readlink-ing /sys/class/graphics/fb0/device/driver but
this was broken with amba-clcd as it sets up fb_info manually and missed
the .device parent pointer.
Signed-off-by: Loïc Minier <loic.minier@linaro.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Paul Mundt <lethal@linux-sh.org>
---
drivers/video/amba-clcd.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 5fc983c..cf03ad0 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -447,6 +447,8 @@ static int clcdfb_register(struct clcd_fb *fb)
goto out;
}
+ fb->fb.device = &fb->dev->dev;
+
fb->fb.fix.mmio_start = fb->dev->res.start;
fb->fb.fix.mmio_len = resource_size(&fb->dev->res);
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 2/2] video: omap2: Compile omap2 support only when
From: Tomi Valkeinen @ 2011-06-20 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1308566761-2850-3-git-send-email-tushar.behera@linaro.org>
On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote:
> Currently display support for omap2 is selected by default and
> it gets built for all the configurations.
>
> Instead of it being a built-in feature, it's compilation should
> depend on the config option CONFIG_FB_OMAP2.
No, I don't think so. omap2 directory contains vram, vrfb and omapdss,
all of which can be used without omapfb driver. vram and vrfb can be
even used without omapdss driver.
Is this patch fixing some real problem?
Tomi
^ permalink raw reply
* Re: [PATCH 1/2] config: omap2+: force fb and dss support as
From: Tomi Valkeinen @ 2011-06-20 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1308566761-2850-2-git-send-email-tushar.behera@linaro.org>
On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote:
> In certain board files, there are references to vram related functions
> which are defined in drivers/video/omap2/vram.c. Because of this direct
> dependency, CONFIG_FB_OMAP2 should be a built-in feature.
arch/arm/plat-omap/include/plat/vram.h defines dummy inline function in
case vram.c is not compiled in, so the board files should compile fine.
> As per the current architecture, CONFIG_FB_OMAP2 is dependent on
> CONFIG_OMAP2_DSS. Hence CONFIG_OMAP2_DSS support should also be selected
> by default.
The configuration is fine as it is. And anyway, if things do not compile
when something is configured as a module, the correct fix is hardly just
changing the feature to be compiled built-in =).
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Samreen <samreen@ti.com>
> Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
> ---
> arch/arm/mach-omap2/built-in.o: In function `rx51_video_mem_init':
> linux-linaro-2.6.39/arch/arm/mach-omap2/board-rx51-video.c:97: undefined reference to `omap_vram_set_sdram_vram'
> arch/arm/plat-omap/built-in.o: In function `omap_reserve':
> linux-linaro-2.6.39/arch/arm/plat-omap/common.c:66: undefined reference to `omap_vram_reserve_sdram_memblock'
> arch/arm/plat-omap/built-in.o: In function `omap_detect_sram':
> linux-linaro-2.6.39/arch/arm/plat-omap/sram.c:179: undefined reference to `omap_vram_reserve_sram'
> make[1]: *** [.tmp_vmlinux1] Error 1
> make: *** [sub-make] Error 2
Compiles fine for me. Perhaps you are using some old kernel?
Tomi
^ permalink raw reply
* RE: [PATCH 1/2] config: omap2+: force fb and dss support as built-in
From: Premi, Sanjeev @ 2011-06-20 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110620122032.GJ2082@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Monday, June 20, 2011 5:51 PM
> To: Premi, Sanjeev
> Cc: Tushar Behera; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org;
> linux-fbdev@vger.kernel.org; linux-omap@vger.kernel.org;
> tony@atomide.com; lethal@linux-sh.org;
> linaro-dev@lists.linaro.org; patches@linaro.org; Nilofer, Samreen
> Subject: Re: [PATCH 1/2] config: omap2+: force fb and dss
> support as built-in
>
> On Mon, Jun 20, 2011 at 05:37:07PM +0530, Premi, Sanjeev wrote:
> > [sp] Instead of changing the omap2plus_defconfig, shouldn't the
> > board specific file be fixed instead?
>
> The board specific configuration files in the mainline kernel are
> deprecated and are gradually being removed.
>
[sp] I didn't mean board specific config file, but:
linux-linaro-2.6.39/arch/arm/mach-omap2/board-rx51-video.c
~sanjeev
^ permalink raw reply
* Re: [PATCH 1/2] config: omap2+: force fb and dss support as
From: Russell King - ARM Linux @ 2011-06-20 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024D625A5C@dbde02.ent.ti.com>
On Mon, Jun 20, 2011 at 05:37:07PM +0530, Premi, Sanjeev wrote:
> [sp] Instead of changing the omap2plus_defconfig, shouldn't the
> board specific file be fixed instead?
The board specific configuration files in the mainline kernel are
deprecated and are gradually being removed.
^ permalink raw reply
* RE: [PATCH 1/2] config: omap2+: force fb and dss support as built-in
From: Premi, Sanjeev @ 2011-06-20 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1308566761-2850-2-git-send-email-tushar.behera@linaro.org>
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tushar Behera
> Sent: Monday, June 20, 2011 4:16 PM
> To: linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org;
> linux-fbdev@vger.kernel.org; linux-omap@vger.kernel.org
> Cc: linux@arm.linux.org.uk; tony@atomide.com;
> lethal@linux-sh.org; linaro-dev@lists.linaro.org;
> patches@linaro.org; Nilofer, Samreen
> Subject: [PATCH 1/2] config: omap2+: force fb and dss support
> as built-in
>
> In certain board files, there are references to vram related functions
> which are defined in drivers/video/omap2/vram.c. Because of
> this direct
> dependency, CONFIG_FB_OMAP2 should be a built-in feature.
>
> As per the current architecture, CONFIG_FB_OMAP2 is dependent on
> CONFIG_OMAP2_DSS. Hence CONFIG_OMAP2_DSS support should also
> be selected
> by default.
>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Samreen <samreen@ti.com>
> Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
> ---
> arch/arm/mach-omap2/built-in.o: In function `rx51_video_mem_init':
> linux-linaro-2.6.39/arch/arm/mach-omap2/board-rx51-video.c:97:
> undefined reference to `omap_vram_set_sdram_vram'
> arch/arm/plat-omap/built-in.o: In function `omap_reserve':
> linux-linaro-2.6.39/arch/arm/plat-omap/common.c:66: undefined
> reference to `omap_vram_reserve_sdram_memblock'
> arch/arm/plat-omap/built-in.o: In function `omap_detect_sram':
> linux-linaro-2.6.39/arch/arm/plat-omap/sram.c:179: undefined
> reference to `omap_vram_reserve_sram'
> make[1]: *** [.tmp_vmlinux1] Error 1
> make: *** [sub-make] Error 2
>
> arch/arm/configs/omap2plus_defconfig | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/configs/omap2plus_defconfig
> b/arch/arm/configs/omap2plus_defconfig
> index d5f00d7..c3ffff2 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -138,11 +138,11 @@ CONFIG_FIRMWARE_EDID=y
> CONFIG_FB_MODE_HELPERS=y
> CONFIG_FB_TILEBLITTING=y
> CONFIG_FB_OMAP_LCD_VGA=y
> -CONFIG_OMAP2_DSS=m
> +CONFIG_OMAP2_DSS=y
> CONFIG_OMAP2_DSS_RFBI=y
> CONFIG_OMAP2_DSS_SDI=y
> CONFIG_OMAP2_DSS_DSI=y
> -CONFIG_FB_OMAP2=m
> +CONFIG_FB_OMAP2=y
> CONFIG_PANEL_GENERIC_DPI=m
> CONFIG_PANEL_SHARP_LS037V7DW01=m
> CONFIG_PANEL_NEC_NL8048HL11_01B=m
[sp] Instead of changing the omap2plus_defconfig, shouldn't the
board specific file be fixed instead?
~sanjeev
> --
> 1.7.4.1
>
> --
> 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 2/2] video: omap2: Compile omap2 support only when needed
From: Tushar Behera @ 2011-06-20 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1308566761-2850-1-git-send-email-tushar.behera@linaro.org>
Currently display support for omap2 is selected by default and
it gets built for all the configurations.
Instead of it being a built-in feature, it's compilation should
depend on the config option CONFIG_FB_OMAP2.
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Tomi Valkeinen <tomi.valkeinen@nokia.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
---
drivers/video/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 8b83129..a19e44e 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -133,7 +133,7 @@ obj-$(CONFIG_FB_SH_MOBILE_HDMI) += sh_mobile_hdmi.o
obj-$(CONFIG_FB_SH_MOBILE_MERAM) += sh_mobile_meram.o
obj-$(CONFIG_FB_SH_MOBILE_LCDC) += sh_mobile_lcdcfb.o
obj-$(CONFIG_FB_OMAP) += omap/
-obj-y += omap2/
+obj-$(CONFIG_FB_OMAP2) += omap2/
obj-$(CONFIG_XEN_FBDEV_FRONTEND) += xen-fbfront.o
obj-$(CONFIG_FB_CARMINE) += carminefb.o
obj-$(CONFIG_FB_MB862XX) += mb862xx/
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/2] config: omap2+: force fb and dss support as built-in
From: Tushar Behera @ 2011-06-20 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1308566761-2850-1-git-send-email-tushar.behera@linaro.org>
In certain board files, there are references to vram related functions
which are defined in drivers/video/omap2/vram.c. Because of this direct
dependency, CONFIG_FB_OMAP2 should be a built-in feature.
As per the current architecture, CONFIG_FB_OMAP2 is dependent on
CONFIG_OMAP2_DSS. Hence CONFIG_OMAP2_DSS support should also be selected
by default.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Samreen <samreen@ti.com>
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
---
arch/arm/mach-omap2/built-in.o: In function `rx51_video_mem_init':
linux-linaro-2.6.39/arch/arm/mach-omap2/board-rx51-video.c:97: undefined reference to `omap_vram_set_sdram_vram'
arch/arm/plat-omap/built-in.o: In function `omap_reserve':
linux-linaro-2.6.39/arch/arm/plat-omap/common.c:66: undefined reference to `omap_vram_reserve_sdram_memblock'
arch/arm/plat-omap/built-in.o: In function `omap_detect_sram':
linux-linaro-2.6.39/arch/arm/plat-omap/sram.c:179: undefined reference to `omap_vram_reserve_sram'
make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [sub-make] Error 2
arch/arm/configs/omap2plus_defconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index d5f00d7..c3ffff2 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -138,11 +138,11 @@ CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_OMAP_LCD_VGA=y
-CONFIG_OMAP2_DSS=m
+CONFIG_OMAP2_DSS=y
CONFIG_OMAP2_DSS_RFBI=y
CONFIG_OMAP2_DSS_SDI=y
CONFIG_OMAP2_DSS_DSI=y
-CONFIG_FB_OMAP2=m
+CONFIG_FB_OMAP2=y
CONFIG_PANEL_GENERIC_DPI=m
CONFIG_PANEL_SHARP_LS037V7DW01=m
CONFIG_PANEL_NEC_NL8048HL11_01B=m
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/2] video: Make omap2 support conditional
From: Tushar Behera @ 2011-06-20 10:57 UTC (permalink / raw)
To: linux-arm-kernel
Currently drivers/video/omap2 is built by default with every configuration
of the kernel. Current patchset makes the omap2 video support conditional
on appropriate config option.
[Patch 2/2] was first generated, but that resulted in a build error.
[Patch 1/2] was created to fix that build error.
These patches have only been tested for build consistency and have not been
tested on any related hardware.
Tushar Behera (2):
config: omap2+: force fb and dss support as built-in
video: omap2: Compile omap2 support only when needed
arch/arm/configs/omap2plus_defconfig | 4 ++--
drivers/video/Makefile | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--
1.7.4.1
^ permalink raw reply
* Re: [PATCH] fb: avoid possible deadlock caused by fb_set_suspend
From: Bruno Prémont @ 2011-06-18 9:19 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Florian Tobias Schandinat, lethal, linux-fbdev, francis.moro,
torvalds, linux-kernel, Herton Ronaldo Krzesinski, stable
In-Reply-To: <20110618104311.6d80ba50@neptune.home>
Guennadi, could you have a look at (completely untested) patch which avoids
possible deadlock due to inverted lock taking order on hotplug as well
as "readding" lock_fb_info() for fb_set_suspend() call after Herton's
patch to fb_set_suspend().
Thanks,
Bruno
On Sat, 18 June 2011 Bruno Prémont <bonbons@linux-vserver.org> wrote:
> On Fri, 17 June 2011 Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
> > From: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
> >
> > A lock ordering issue can cause deadlocks: in framebuffer/console code,
> > all needed struct fb_info locks are taken before acquire_console_sem(),
> > in places which need to take console semaphore.
> >
> > But fb_set_suspend is always called with console semaphore held, and
> > inside it we call lock_fb_info which gets the fb_info lock, inverse
> > locking order of what the rest of the code does. This causes a real
> > deadlock issue, when we write to state fb sysfs attribute (which calls
> > fb_set_suspend) while a framebuffer is being unregistered by
> > remove_conflicting_framebuffers, as can be shown by following show
> > blocked state trace on a test program which loads i915 and runs another
> > forked processes writing to state attribute:
> >
> > Test process with semaphore held and trying to get fb_info lock:
>
> ...
>
> > fb-test2 which reproduces above is available on kernel.org bug #26232.
> > To solve this issue, avoid calling lock_fb_info inside fb_set_suspend,
> > and move it out to where needed (callers of fb_set_suspend must call
> > lock_fb_info before if needed). So far, the only place which needs to
> > call lock_fb_info is store_fbstate, all other places which calls
> > fb_set_suspend are suspend/resume hooks that should not need the lock as
> > they should be run only when processes are already frozen in
> > suspend/resume.
>
> From a quick look through FB drivers in 2.6.39 I've found one that would need
> more work:
> - drivers/video/sh_mobile_hdmi.c: sh_hdmi_edid_work_fn()
> Should get changed to
> a) right locking order in case (hdmi->hp_state = HDMI_HOTPLUG_CONNECTED)
> b) lock fb_info in the other case
> For this one fb_set_suspend() does get call in a hotplug worker,
> thus independently on suspend/resume process.
>
> The rest does match the suspend/resume hook pattern mentioned.
>
> Bruno
>
>
> > References: https://bugzilla.kernel.org/show_bug.cgi?id&232
> > Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
> > Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> > Cc: stable@kernel.org
> > ---
> > drivers/video/fbmem.c | 3 ---
> > drivers/video/fbsysfs.c | 3 +++
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> > index 5aac00e..ad93629 100644
> > --- a/drivers/video/fbmem.c
> > +++ b/drivers/video/fbmem.c
> > @@ -1738,8 +1738,6 @@ void fb_set_suspend(struct fb_info *info, int state)
> > {
> > struct fb_event event;
> >
> > - if (!lock_fb_info(info))
> > - return;
> > event.info = info;
> > if (state) {
> > fb_notifier_call_chain(FB_EVENT_SUSPEND, &event);
> > @@ -1748,7 +1746,6 @@ void fb_set_suspend(struct fb_info *info, int state)
> > info->state = FBINFO_STATE_RUNNING;
> > fb_notifier_call_chain(FB_EVENT_RESUME, &event);
> > }
> > - unlock_fb_info(info);
> > }
> >
> > /**
> > diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c
> > index 04251ce..67afa9c 100644
> > --- a/drivers/video/fbsysfs.c
> > +++ b/drivers/video/fbsysfs.c
> > @@ -399,9 +399,12 @@ static ssize_t store_fbstate(struct device *device,
> >
> > state = simple_strtoul(buf, &last, 0);
> >
> > + if (!lock_fb_info(fb_info))
> > + return -ENODEV;
> > console_lock();
> > fb_set_suspend(fb_info, (int)state);
> > console_unlock();
> > + unlock_fb_info(fb_info);
> >
> > return count;
> > }
diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index 2b9e56a..b1a13ab 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -1151,27 +1151,27 @@ static void sh_hdmi_edid_work_fn(struct work_struct *work)
ch = info->par;
- console_lock();
+ if (lock_fb_info(info)) {
+ console_lock();
- /* HDMI plug in */
- if (!sh_hdmi_must_reconfigure(hdmi) &&
- info->state = FBINFO_STATE_RUNNING) {
- /*
- * First activation with the default monitor - just turn
- * on, if we run a resume here, the logo disappears
- */
- if (lock_fb_info(info)) {
+ /* HDMI plug in */
+ if (!sh_hdmi_must_reconfigure(hdmi) &&
+ info->state = FBINFO_STATE_RUNNING) {
+ /*
+ * First activation with the default monitor - just turn
+ * on, if we run a resume here, the logo disappears
+ */
info->var.width = hdmi->var.width;
info->var.height = hdmi->var.height;
sh_hdmi_display_on(hdmi, info);
- unlock_fb_info(info);
+ } else {
+ /* New monitor or have to wake up */
+ fb_set_suspend(info, 0);
}
- } else {
- /* New monitor or have to wake up */
- fb_set_suspend(info, 0);
- }
- console_unlock();
+ console_unlock();
+ unlock_fb_info(info);
+ }
} else {
ret = 0;
if (!hdmi->info)
@@ -1181,12 +1181,15 @@ static void sh_hdmi_edid_work_fn(struct work_struct *work)
fb_destroy_modedb(hdmi->monspec.modedb);
hdmi->monspec.modedb = NULL;
- console_lock();
+ if (lock_fb_info(info)) {
+ console_lock();
- /* HDMI disconnect */
- fb_set_suspend(hdmi->info, 1);
+ /* HDMI disconnect */
+ fb_set_suspend(hdmi->info, 1);
- console_unlock();
+ console_unlock();
+ unlock_fb_info(info);
+ }
pm_runtime_put(hdmi->dev);
}
^ 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