* Re: [Patch] video: remove pointless comments in drivers/video/console/vgacon.c
From: Paul Mundt @ 2011-01-19 6:02 UTC (permalink / raw)
To: Amerigo Wang
Cc: linux-kernel, Arnd Bergmann, Andrew Morton, Greg Kroah-Hartman,
Yannick Heneault, Matthew Garrett, open list:FRAMEBUFFER LAYER
In-Reply-To: <1295416803-17651-1-git-send-email-amwang@redhat.com>
On Wed, Jan 19, 2011 at 02:00:02PM +0800, Amerigo Wang wrote:
> Now vgacon_scrollback_startup() uses slab, not bootmem,
> so that comment is obsolete, the rest are useless.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
>
If you're going to do this then at least follow through and do the rest
of it. The comment is no longer applicable, but then neither is the
__init_refok annotation. Killing off the comment explaining why something
is (or was there) without killing off the thing that is referenced by the
comment is not terribly productive.
^ permalink raw reply
* [Patch] video: remove pointless comments in drivers/video/console/vgacon.c
From: Amerigo Wang @ 2011-01-19 6:00 UTC (permalink / raw)
To: linux-kernel
Cc: WANG Cong, Arnd Bergmann, Andrew Morton, Greg Kroah-Hartman,
Yannick Heneault, Matthew Garrett, open list:FRAMEBUFFER LAYER
Now vgacon_scrollback_startup() uses slab, not bootmem,
so that comment is obsolete, the rest are useless.
Signed-off-by: WANG Cong <amwang@redhat.com>
---
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index c97491b..b030aca 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -202,10 +202,6 @@ static void vgacon_scrollback_init(int pitch)
}
}
-/*
- * Called only duing init so call of alloc_bootmen is ok.
- * Marked __init_refok to silence modpost.
- */
static void __init_refok vgacon_scrollback_startup(void)
{
vgacon_scrollback = kcalloc(CONFIG_VGACON_SOFT_SCROLLBACK_SIZE, 1024, GFP_NOWAIT);
^ permalink raw reply related
* Re: [PATCH] drivers: ld9040 amoled driver support
From: Andrew Morton @ 2011-01-19 3:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110119032518.GD19486@linux-sh.org>
On Wed, 19 Jan 2011 12:25:18 +0900 Paul Mundt <lethal@linux-sh.org> wrote:
> For now the easiest option is still likely to be just making Andrew aware
> of it, while gradually leaning towards -mm as the primary path for
> backlight patches.
The current status of backlight (and drivers/leds/) it that I review
(lol) and merge the patches and send them upstream. I cc Richard on
them all and he reviews them if he has the time available.
^ permalink raw reply
* Re: [PATCH] drivers: ld9040 amoled driver support
From: Paul Mundt @ 2011-01-19 3:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D364EFF.6080401@samsung.com>
On Wed, Jan 19, 2011 at 11:39:59AM +0900, Donghwa Lee wrote:
> Dear Richard Purdie,
>
> I had sent ld9040 amoled driver patch file for several times with expectation for your comment.
> But, there was no comment about that. I was somewhat disappointed.
>
> That patch is working well on my board and it is very smilar framework as s6e63m0 that already
> included mainline. Please reply with any comment.
> I'm looking forward to your reply.
The backlight stuff seems to be effectively abandoned at this point, and
it's not clear if there is anyone else willing to maintain it. For these
sorts of situations patches are generally best fed through -mm, which
provides some time for review from unresponsive maintainers as well as
leading towards a merge path.
I'm not sure what the best way to handle the backlight stuff is however,
in that much of it keeps popping up on the fbdev list and each time we
either need to poke Richard multiple times or shuffle it off to Andrew.
This also understandably leads to frustration for people submitting new
drivers in that the submission path they are directed towards via
MAINTAINERS ends up largely being a black hole.
For now the easiest option is still likely to be just making Andrew aware
of it, while gradually leaning towards -mm as the primary path for
backlight patches.
^ permalink raw reply
* Re: [PATCH] drivers: ld9040 amoled driver support
From: Donghwa Lee @ 2011-01-19 2:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294893628-16998-1-git-send-email-dh09.lee@samsung.com>
Dear Richard Purdie,
I had sent ld9040 amoled driver patch file for several times with expectation for your comment.
But, there was no comment about that. I was somewhat disappointed.
That patch is working well on my board and it is very smilar framework as s6e63m0 that already
included mainline. Please reply with any comment.
I'm looking forward to your reply.
Thanks,
Donghwa Lee
On 2011-01-13 ¿ÀÈÄ 1:40 , Donghwa Lee wrote:
> This patch is ld9040 amoled panel driver.
> I resend because there was no comment.
>
> It is similar to s6e63m0 panel driver and use spi gpio to send panel
> information.
>
> Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>
> ---
> drivers/video/backlight/Kconfig | 8 +
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/ld9040.c | 927 ++++++++++++++++++++++++++++++++
> drivers/video/backlight/ld9040_gamma.h | 203 +++++++
> 4 files changed, 1139 insertions(+), 0 deletions(-)
> create mode 100644 drivers/video/backlight/ld9040.c
> create mode 100644 drivers/video/backlight/ld9040_gamma.h
>
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index e54a337..db3d123 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -109,6 +109,14 @@ config LCD_S6E63M0
> If you have an S6E63M0 LCD Panel, say Y to enable its
> LCD control driver.
>
> +config LCD_LD9040
> + tristate "LD9040 AMOLED LCD Driver"
> + depends on SPI && BACKLIGHT_CLASS_DEVICE
> + default n
> + help
> + If you have an LD9040 Panel, say Y to enable its
> + control driver.
> +
> endif # LCD_CLASS_DEVICE
>
> #
> diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
> index 44c0f81..457996c 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_LCD_VGG2432A4) += vgg2432a4.o
> obj-$(CONFIG_LCD_TDO24M) += tdo24m.o
> obj-$(CONFIG_LCD_TOSA) += tosa_lcd.o
> obj-$(CONFIG_LCD_S6E63M0) += s6e63m0.o
> +obj-$(CONFIG_LCD_LD9040) += ld9040.o
>
> obj-$(CONFIG_BACKLIGHT_CLASS_DEVICE) += backlight.o
> obj-$(CONFIG_BACKLIGHT_ATMEL_PWM) += atmel-pwm-bl.o
> diff --git a/drivers/video/backlight/ld9040.c b/drivers/video/backlight/ld9040.c
> new file mode 100644
> index 0000000..248f42f
> --- /dev/null
> +++ b/drivers/video/backlight/ld9040.c
> @@ -0,0 +1,927 @@
> +/*
> + * ld9040 AMOLED LCD panel driver.
> + *
> + * Author: Donghwa Lee <dh09.lee@samsung.com>
> + *
> + * Derived from drivers/video/backlight/s6e63m0.c
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> + */
> +
> +#include <linux/wait.h>
> +#include <linux/fb.h>
> +#include <linux/delay.h>
> +#include <linux/gpio.h>
> +#include <linux/spi/spi.h>
> +#include <linux/irq.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/lcd.h>
> +#include <linux/backlight.h>
> +
> +#include "ld9040_gamma.h"
> +
> +#define SLEEPMSEC 0x1000
> +#define ENDDEF 0x2000
> +#define DEFMASK 0xFF00
> +#define COMMAND_ONLY 0xFE
> +#define DATA_ONLY 0xFF
> +
> +#define MIN_BRIGHTNESS 0
> +#define MAX_BRIGHTNESS 24
> +#define POWER_IS_ON(pwr) ((pwr) <= FB_BLANK_NORMAL)
> +
> +struct ld9040 {
> + struct device *dev;
> + struct spi_device *spi;
> + unsigned int power;
> + unsigned int gamma_mode;
> + unsigned int current_brightness;
> + unsigned int gamma_table_count;
> +
> + struct lcd_device *ld;
> + struct backlight_device *bd;
> + struct lcd_platform_data *lcd_pd;
> +};
> +
> +static const unsigned short SEQ_SWRESET[] = {
> + 0x01, COMMAND_ONLY,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_USER_SETTING[] = {
> + 0xF0, 0x5A,
> +
> + DATA_ONLY, 0x5A,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_ELVSS_ON[] = {
> + 0xB1, 0x0D,
> +
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x16,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_GTCON[] = {
> + 0xF7, 0x09,
> +
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_PANEL_CONDITION[] = {
> + 0xF8, 0x05,
> +
> + DATA_ONLY, 0x65,
> + DATA_ONLY, 0x96,
> + DATA_ONLY, 0x71,
> + DATA_ONLY, 0x7D,
> + DATA_ONLY, 0x19,
> + DATA_ONLY, 0x3B,
> + DATA_ONLY, 0x0D,
> + DATA_ONLY, 0x19,
> + DATA_ONLY, 0x7E,
> + DATA_ONLY, 0x0D,
> + DATA_ONLY, 0xE2,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x7E,
> + DATA_ONLY, 0x7D,
> + DATA_ONLY, 0x07,
> + DATA_ONLY, 0x07,
> + DATA_ONLY, 0x20,
> + DATA_ONLY, 0x20,
> + DATA_ONLY, 0x20,
> + DATA_ONLY, 0x02,
> + DATA_ONLY, 0x02,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_GAMMA_SET1[] = {
> + 0xF9, 0x00,
> +
> + DATA_ONLY, 0xA7,
> + DATA_ONLY, 0xB4,
> + DATA_ONLY, 0xAE,
> + DATA_ONLY, 0xBF,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x91,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0xB2,
> + DATA_ONLY, 0xB4,
> + DATA_ONLY, 0xAA,
> + DATA_ONLY, 0xBB,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0xAC,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0xB3,
> + DATA_ONLY, 0xB1,
> + DATA_ONLY, 0xAA,
> + DATA_ONLY, 0xBC,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0xB3,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_GAMMA_CTRL[] = {
> + 0xFB, 0x02,
> +
> + DATA_ONLY, 0x5A,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_GAMMA_START[] = {
> + 0xF9, COMMAND_ONLY,
> +
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_APON[] = {
> + 0xF3, 0x00,
> +
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x0A,
> + DATA_ONLY, 0x02,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_DISPCTL[] = {
> + 0xF2, 0x02,
> +
> + DATA_ONLY, 0x08,
> + DATA_ONLY, 0x08,
> + DATA_ONLY, 0x10,
> + DATA_ONLY, 0x10,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_MANPWR[] = {
> + 0xB0, 0x04,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_PWR_CTRL[] = {
> + 0xF4, 0x0A,
> +
> + DATA_ONLY, 0x87,
> + DATA_ONLY, 0x25,
> + DATA_ONLY, 0x6A,
> + DATA_ONLY, 0x44,
> + DATA_ONLY, 0x02,
> + DATA_ONLY, 0x88,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_SLPOUT[] = {
> + 0x11, COMMAND_ONLY,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_SLPIN[] = {
> + 0x10, COMMAND_ONLY,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_DISPON[] = {
> + 0x29, COMMAND_ONLY,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_DISPOFF[] = {
> + 0x28, COMMAND_ONLY,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_VCI1_1ST_EN[] = {
> + 0xF3, 0x10,
> +
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x02,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_VL1_EN[] = {
> + 0xF3, 0x11,
> +
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x02,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_VL2_EN[] = {
> + 0xF3, 0x13,
> +
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x02,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_VCI1_2ND_EN[] = {
> + 0xF3, 0x33,
> +
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x02,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_VL3_EN[] = {
> + 0xF3, 0x37,
> +
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x02,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_VREG1_AMP_EN[] = {
> + 0xF3, 0x37,
> +
> + DATA_ONLY, 0x01,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x02,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_VGH_AMP_EN[] = {
> + 0xF3, 0x37,
> +
> + DATA_ONLY, 0x11,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x02,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_VGL_AMP_EN[] = {
> + 0xF3, 0x37,
> +
> + DATA_ONLY, 0x31,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x02,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_VMOS_AMP_EN[] = {
> + 0xF3, 0x37,
> +
> + DATA_ONLY, 0xB1,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x03,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_VINT_AMP_EN[] = {
> + 0xF3, 0x37,
> +
> + DATA_ONLY, 0xF1,
> + /* DATA_ONLY, 0x71, VMOS/VBL/VBH not used */
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x03,
> + /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_VBH_AMP_EN[] = {
> + 0xF3, 0x37,
> +
> + DATA_ONLY, 0xF9,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x03,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_VBL_AMP_EN[] = {
> + 0xF3, 0x37,
> +
> + DATA_ONLY, 0xFD,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x03,
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_GAM_AMP_EN[] = {
> + 0xF3, 0x37,
> +
> + DATA_ONLY, 0xFF,
> + /* DATA_ONLY, 0x73, VMOS/VBL/VBH not used */
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x03,
> + /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_SD_AMP_EN[] = {
> + 0xF3, 0x37,
> +
> + DATA_ONLY, 0xFF,
> + /* DATA_ONLY, 0x73, VMOS/VBL/VBH not used */
> + DATA_ONLY, 0x80,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x03,
> + /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_GLS_EN[] = {
> + 0xF3, 0x37,
> +
> + DATA_ONLY, 0xFF,
> + /* DATA_ONLY, 0x73, VMOS/VBL/VBH not used */
> + DATA_ONLY, 0x81,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x03,
> + /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_ELS_EN[] = {
> + 0xF3, 0x37,
> +
> + DATA_ONLY, 0xFF,
> + /* DATA_ONLY, 0x73, VMOS/VBL/VBH not used */
> + DATA_ONLY, 0x83,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x03,
> + /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
> + ENDDEF, 0x00
> +};
> +
> +static const unsigned short SEQ_EL_ON[] = {
> + 0xF3, 0x37,
> +
> + DATA_ONLY, 0xFF,
> + /* DATA_ONLY, 0x73, VMOS/VBL/VBH not used */
> + DATA_ONLY, 0x87,
> + DATA_ONLY, 0x00,
> + DATA_ONLY, 0x03,
> + /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
> + ENDDEF, 0x00
> +};
> +
> +static int ld9040_spi_write_byte(struct ld9040 *lcd, int addr, int data)
> +{
> + u16 buf[1];
> + struct spi_message msg;
> +
> + struct spi_transfer xfer = {
> + .len = 2,
> + .tx_buf = buf,
> + };
> +
> + buf[0] = (addr << 8) | data;
> +
> + spi_message_init(&msg);
> + spi_message_add_tail(&xfer, &msg);
> +
> + return spi_sync(lcd->spi, &msg);
> +}
> +
> +static int ld9040_spi_write(struct ld9040 *lcd, unsigned char address,
> + unsigned char command)
> +{
> + int ret = 0;
> +
> + if (address != DATA_ONLY)
> + ret = ld9040_spi_write_byte(lcd, 0x0, address);
> + if (command != COMMAND_ONLY)
> + ret = ld9040_spi_write_byte(lcd, 0x1, command);
> +
> + return ret;
> +}
> +
> +static int ld9040_panel_send_sequence(struct ld9040 *lcd,
> + const unsigned short *wbuf)
> +{
> + int ret = 0, i = 0;
> +
> + while ((wbuf[i] & DEFMASK) != ENDDEF) {
> + if ((wbuf[i] & DEFMASK) != SLEEPMSEC) {
> + ret = ld9040_spi_write(lcd, wbuf[i], wbuf[i+1]);
> + if (ret)
> + break;
> + } else
> + udelay(wbuf[i+1]*1000);
> + i += 2;
> + }
> +
> + return ret;
> +}
> +
> +static int _ld9040_gamma_ctl(struct ld9040 *lcd, const unsigned int *gamma)
> +{
> + unsigned int i = 0;
> + int ret = 0;
> +
> + /* start gamma table updating. */
> + ret = ld9040_panel_send_sequence(lcd, SEQ_GAMMA_START);
> + if (ret) {
> + dev_err(lcd->dev, "failed to disable gamma table updating.\n");
> + goto gamma_err;
> + }
> +
> + for (i = 0 ; i < GAMMA_TABLE_COUNT; i++) {
> + ret = ld9040_spi_write(lcd, DATA_ONLY, gamma[i]);
> + if (ret) {
> + dev_err(lcd->dev, "failed to set gamma table.\n");
> + goto gamma_err;
> + }
> + }
> +
> + /* update gamma table. */
> + ret = ld9040_panel_send_sequence(lcd, SEQ_GAMMA_CTRL);
> + if (ret)
> + dev_err(lcd->dev, "failed to update gamma table.\n");
> +
> +gamma_err:
> + return ret;
> +}
> +
> +static int ld9040_gamma_ctl(struct ld9040 *lcd, int gamma)
> +{
> + int ret = 0;
> +
> + ret = _ld9040_gamma_ctl(lcd, gamma_table.gamma_22_table[gamma]);
> +
> + return ret;
> +}
> +
> +
> +static int ld9040_ldi_init(struct ld9040 *lcd)
> +{
> + int ret, i;
> + const unsigned short *init_seq[] = {
> + SEQ_USER_SETTING,
> + SEQ_PANEL_CONDITION,
> + SEQ_DISPCTL,
> + SEQ_MANPWR,
> + SEQ_PWR_CTRL,
> + SEQ_ELVSS_ON,
> + SEQ_GTCON,
> + SEQ_GAMMA_SET1,
> + SEQ_GAMMA_CTRL,
> + SEQ_SLPOUT,
> + };
> +
> + for (i = 0; i < ARRAY_SIZE(init_seq); i++) {
> + ret = ld9040_panel_send_sequence(lcd, init_seq[i]);
> + /* workaround: minimum delay time for transferring CMD */
> + udelay(300);
> + if (ret)
> + break;
> + }
> +
> + return ret;
> +}
> +
> +static int ld9040_ldi_enable(struct ld9040 *lcd)
> +{
> + int ret = 0;
> +
> + ret = ld9040_panel_send_sequence(lcd, SEQ_DISPON);
> +
> + return ret;
> +}
> +
> +static int ld9040_ldi_disable(struct ld9040 *lcd)
> +{
> + int ret;
> +
> + ret = ld9040_panel_send_sequence(lcd, SEQ_DISPOFF);
> + ret = ld9040_panel_send_sequence(lcd, SEQ_SLPIN);
> +
> + return ret;
> +}
> +
> +static int ld9040_power_on(struct ld9040 *lcd)
> +{
> + int ret = 0;
> + struct lcd_platform_data *pd = NULL;
> + pd = lcd->lcd_pd;
> + if (!pd) {
> + dev_err(lcd->dev, "platform data is NULL.\n");
> + return -EFAULT;
> + }
> +
> + if (!pd->power_on) {
> + dev_err(lcd->dev, "power_on is NULL.\n");
> + return -EFAULT;
> + } else {
> + pd->power_on(lcd->ld, 1);
> + mdelay(pd->power_on_delay);
> + }
> +
> + if (!pd->reset) {
> + dev_err(lcd->dev, "reset is NULL.\n");
> + return -EFAULT;
> + } else {
> + pd->reset(lcd->ld);
> + mdelay(pd->reset_delay);
> + }
> +
> + ret = ld9040_ldi_init(lcd);
> + if (ret) {
> + dev_err(lcd->dev, "failed to initialize ldi.\n");
> + return ret;
> + }
> +
> + ret = ld9040_ldi_enable(lcd);
> + if (ret) {
> + dev_err(lcd->dev, "failed to enable ldi.\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int ld9040_power_off(struct ld9040 *lcd)
> +{
> + int ret = 0;
> + struct lcd_platform_data *pd = NULL;
> +
> + pd = lcd->lcd_pd;
> + if (!pd) {
> + dev_err(lcd->dev, "platform data is NULL.\n");
> + return -EFAULT;
> + }
> +
> + ret = ld9040_ldi_disable(lcd);
> + if (ret) {
> + dev_err(lcd->dev, "lcd setting failed.\n");
> + return -EIO;
> + }
> +
> + mdelay(pd->power_off_delay);
> +
> + if (!pd->power_on) {
> + dev_err(lcd->dev, "power_on is NULL.\n");
> + return -EFAULT;
> + } else
> + pd->power_on(lcd->ld, 0);
> +
> + return 0;
> +}
> +
> +static int ld9040_power(struct ld9040 *lcd, int power)
> +{
> + int ret = 0;
> +
> + if (POWER_IS_ON(power) && !POWER_IS_ON(lcd->power))
> + ret = ld9040_power_on(lcd);
> + else if (!POWER_IS_ON(power) && POWER_IS_ON(lcd->power))
> + ret = ld9040_power_off(lcd);
> +
> + if (!ret)
> + lcd->power = power;
> +
> + return ret;
> +}
> +
> +static int ld9040_set_power(struct lcd_device *ld, int power)
> +{
> + struct ld9040 *lcd = lcd_get_data(ld);
> +
> + if (power != FB_BLANK_UNBLANK && power != FB_BLANK_POWERDOWN &&
> + power != FB_BLANK_NORMAL) {
> + dev_err(lcd->dev, "power value should be 0, 1 or 4.\n");
> + return -EINVAL;
> + }
> +
> + return ld9040_power(lcd, power);
> +}
> +
> +static int ld9040_get_power(struct lcd_device *ld)
> +{
> + struct ld9040 *lcd = lcd_get_data(ld);
> +
> + return lcd->power;
> +}
> +
> +static int ld9040_get_brightness(struct backlight_device *bd)
> +{
> + return bd->props.brightness;
> +}
> +
> +static int ld9040_set_brightness(struct backlight_device *bd)
> +{
> + int ret = 0, brightness = bd->props.brightness;
> + struct ld9040 *lcd = bl_get_data(bd);
> +
> + if (brightness < MIN_BRIGHTNESS ||
> + brightness > bd->props.max_brightness) {
> + dev_err(&bd->dev, "lcd brightness should be %d to %d.\n",
> + MIN_BRIGHTNESS, MAX_BRIGHTNESS);
> + return -EINVAL;
> + }
> +
> + ret = ld9040_gamma_ctl(lcd, bd->props.brightness);
> + if (ret) {
> + dev_err(&bd->dev, "lcd brightness setting failed.\n");
> + return -EIO;
> + }
> +
> + return ret;
> +}
> +
> +static struct lcd_ops ld9040_lcd_ops = {
> + .set_power = ld9040_set_power,
> + .get_power = ld9040_get_power,
> +};
> +
> +static const struct backlight_ops ld9040_backlight_ops = {
> + .get_brightness = ld9040_get_brightness,
> + .update_status = ld9040_set_brightness,
> +};
> +
> +static ssize_t ld9040_sysfs_show_gamma_mode(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct ld9040 *lcd = dev_get_drvdata(dev);
> + char temp[10];
> +
> + switch (lcd->gamma_mode) {
> + case 0:
> + sprintf(temp, "2.2 mode\n");
> + strcat(buf, temp);
> + break;
> + default:
> + dev_info(dev, "gamma mode could be 0:2.2\n");
> + break;
> + }
> +
> + return strlen(buf);
> +}
> +
> +static ssize_t ld9040_sysfs_store_gamma_mode(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t len)
> +{
> + struct ld9040 *lcd = dev_get_drvdata(dev);
> + struct backlight_device *bd = NULL;
> + int brightness, rc;
> +
> + rc = strict_strtoul(buf, 0, (unsigned long *)&lcd->gamma_mode);
> + if (rc < 0)
> + return rc;
> +
> + bd = lcd->bd;
> +
> + brightness = bd->props.brightness;
> +
> + switch (lcd->gamma_mode) {
> + case 0:
> + _ld9040_gamma_ctl(lcd, gamma_table.gamma_22_table[brightness]);
> + break;
> + default:
> + dev_info(dev, "gamma mode could be 0:2.2\n");
> + _ld9040_gamma_ctl(lcd, gamma_table.gamma_22_table[brightness]);
> + break;
> + }
> + return len;
> +}
> +
> +static DEVICE_ATTR(gamma_mode, 0644,
> + ld9040_sysfs_show_gamma_mode, ld9040_sysfs_store_gamma_mode);
> +
> +static ssize_t ld9040_sysfs_show_gamma_table(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct ld9040 *lcd = dev_get_drvdata(dev);
> + char temp[3];
> +
> + sprintf(temp, "%d\n", lcd->gamma_table_count);
> + strcpy(buf, temp);
> +
> + return strlen(buf);
> +}
> +
> +static DEVICE_ATTR(gamma_table, 0644,
> + ld9040_sysfs_show_gamma_table, NULL);
> +
> +static int ld9040_probe(struct spi_device *spi)
> +{
> + int ret = 0;
> + struct ld9040 *lcd = NULL;
> + struct lcd_device *ld = NULL;
> + struct backlight_device *bd = NULL;
> +
> + lcd = kzalloc(sizeof(struct ld9040), GFP_KERNEL);
> + if (!lcd)
> + return -ENOMEM;
> +
> + /* ld9040 lcd panel uses 3-wire 9bits SPI Mode. */
> + spi->bits_per_word = 9;
> +
> + ret = spi_setup(spi);
> + if (ret < 0) {
> + dev_err(&spi->dev, "spi setup failed.\n");
> + goto out_free_lcd;
> + }
> +
> + lcd->spi = spi;
> + lcd->dev = &spi->dev;
> +
> + lcd->lcd_pd = (struct lcd_platform_data *)spi->dev.platform_data;
> + if (!lcd->lcd_pd) {
> + dev_err(&spi->dev, "platform data is NULL.\n");
> + goto out_free_lcd;
> + }
> +
> + ld = lcd_device_register("ld9040", &spi->dev, lcd, &ld9040_lcd_ops);
> + if (IS_ERR(ld)) {
> + ret = PTR_ERR(ld);
> + goto out_free_lcd;
> + }
> +
> + lcd->ld = ld;
> +
> + bd = backlight_device_register("ld9040-bl", &spi->dev,
> + lcd, &ld9040_backlight_ops, NULL);
> + if (IS_ERR(ld)) {
> + ret = PTR_ERR(ld);
> + goto out_free_lcd;
> + }
> +
> + bd->props.max_brightness = MAX_BRIGHTNESS;
> + bd->props.brightness = MAX_BRIGHTNESS;
> + lcd->bd = bd;
> +
> + /*
> + * it gets gamma table count available so it gets user
> + * know that.
> + */
> + lcd->gamma_table_count > + sizeof(gamma_table) / (MAX_GAMMA_LEVEL * sizeof(int));
> +
> + ret = device_create_file(&(spi->dev), &dev_attr_gamma_mode);
> + if (ret < 0)
> + dev_err(&(spi->dev), "failed to add sysfs entries\n");
> +
> + ret = device_create_file(&(spi->dev), &dev_attr_gamma_table);
> + if (ret < 0)
> + dev_err(&(spi->dev), "failed to add sysfs entries\n");
> +
> + /*
> + * if lcd panel was on from bootloader like u-boot then
> + * do not lcd on.
> + */
> + if (!lcd->lcd_pd->lcd_enabled) {
> + /*
> + * if lcd panel was off from bootloader then
> + * current lcd status is powerdown and then
> + * it enables lcd panel.
> + */
> + lcd->power = FB_BLANK_POWERDOWN;
> +
> + ld9040_power(lcd, FB_BLANK_UNBLANK);
> + } else
> + lcd->power = FB_BLANK_UNBLANK;
> +
> + dev_set_drvdata(&spi->dev, lcd);
> +
> + dev_info(&spi->dev, "ld9040 panel driver has been probed.\n");
> + return 0;
> +
> +out_free_lcd:
> + kfree(lcd);
> + return ret;
> +}
> +
> +static int __devexit ld9040_remove(struct spi_device *spi)
> +{
> + struct ld9040 *lcd = dev_get_drvdata(&spi->dev);
> +
> + ld9040_power(lcd, FB_BLANK_POWERDOWN);
> + lcd_device_unregister(lcd->ld);
> + kfree(lcd);
> +
> + return 0;
> +}
> +
> +#if defined(CONFIG_PM)
> +unsigned int beforepower;
> +
> +static int ld9040_suspend(struct spi_device *spi, pm_message_t mesg)
> +{
> + int ret = 0;
> + struct ld9040 *lcd = dev_get_drvdata(&spi->dev);
> +
> + dev_dbg(&spi->dev, "lcd->power = %d\n", lcd->power);
> +
> + beforepower = lcd->power;
> +
> + /*
> + * when lcd panel is suspend, lcd panel becomes off
> + * regardless of status.
> + */
> + ret = ld9040_power(lcd, FB_BLANK_POWERDOWN);
> +
> + return ret;
> +}
> +
> +static int ld9040_resume(struct spi_device *spi)
> +{
> + int ret = 0;
> + struct ld9040 *lcd = dev_get_drvdata(&spi->dev);
> +
> + /*
> + * after suspended, if lcd panel status is FB_BLANK_UNBLANK
> + * (at that time, power is FB_BLANK_UNBLANK) then
> + * it changes that status to FB_BLANK_POWERDOWN to get lcd on.
> + */
> + if (beforepower = FB_BLANK_UNBLANK)
> + lcd->power = FB_BLANK_POWERDOWN;
> +
> + dev_dbg(&spi->dev, "power = %d\n", beforepower);
> +
> + ret = ld9040_power(lcd, beforepower);
> +
> + return ret;
> +}
> +#else
> +#define ld9040_suspend NULL
> +#define ld9040_resume NULL
> +#endif
> +
> +/* Power down all displays on reboot, poweroff or halt. */
> +static void ld9040_shutdown(struct spi_device *spi)
> +{
> + struct ld9040 *lcd = dev_get_drvdata(&spi->dev);
> +
> + ld9040_power(lcd, FB_BLANK_POWERDOWN);
> +}
> +
> +static struct spi_driver ld9040_driver = {
> + .driver = {
> + .name = "ld9040",
> + .bus = &spi_bus_type,
> + .owner = THIS_MODULE,
> + },
> + .probe = ld9040_probe,
> + .remove = __devexit_p(ld9040_remove),
> + .shutdown = ld9040_shutdown,
> + .suspend = ld9040_suspend,
> + .resume = ld9040_resume,
> +};
> +
> +static int __init ld9040_init(void)
> +{
> + return spi_register_driver(&ld9040_driver);
> +}
> +
> +static void __exit ld9040_exit(void)
> +{
> + spi_unregister_driver(&ld9040_driver);
> +}
> +
> +module_init(ld9040_init);
> +module_exit(ld9040_exit);
> +
> +MODULE_AUTHOR("Donghwa Lee <dh09.lee@samsung.com>");
> +MODULE_DESCRIPTION("ld9040 LCD Driver");
> +MODULE_LICENSE("GPL");
> +
> diff --git a/drivers/video/backlight/ld9040_gamma.h b/drivers/video/backlight/ld9040_gamma.h
> new file mode 100644
> index 0000000..f199133
> --- /dev/null
> +++ b/drivers/video/backlight/ld9040_gamma.h
> @@ -0,0 +1,203 @@
> +/* linux/drivers/video/samsung/ld9040_brightness.h
> + *
> + * Gamma level definitions.
> + *
> + * Copyright (c) 2009 Samsung Electronics
> + * InKi Dae <inki.dae@samsung.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#ifndef _ld9040_BRIGHTNESS_H
> +#define _ld9040_BRIGHTNESS_H
> +
> +#define MAX_GAMMA_LEVEL 25
> +#define GAMMA_TABLE_COUNT 21
> +
> +/* gamma value: 2.2 */
> +static const unsigned int ld9040_22_300[] = {
> + 0x00, 0xa7, 0xb4, 0xae, 0xbf, 0x00, 0x91,
> + 0x00, 0xb2, 0xb4, 0xaa, 0xbb, 0x00, 0xac,
> + 0x00, 0xb3, 0xb1, 0xaa, 0xbc, 0x00, 0xb3
> +};
> +
> +static const unsigned int ld9040_22_290[] = {
> + 0x00, 0xa9, 0xb7, 0xae, 0xbd, 0x00, 0x89,
> + 0x00, 0xb7, 0xb6, 0xa8, 0xba, 0x00, 0xa4,
> + 0x00, 0xb1, 0xb4, 0xaa, 0xbb, 0x00, 0xaa
> +};
> +
> +static const unsigned int ld9040_22_280[] = {
> + 0x00, 0xa9, 0xb6, 0xad, 0xbf, 0x00, 0x86,
> + 0x00, 0xb8, 0xb5, 0xa8, 0xbc, 0x00, 0xa0,
> + 0x00, 0xb3, 0xb3, 0xa9, 0xbc, 0x00, 0xa7
> +};
> +
> +static const unsigned int ld9040_22_270[] = {
> + 0x00, 0xa8, 0xb8, 0xae, 0xbe, 0x00, 0x84,
> + 0x00, 0xb9, 0xb7, 0xa8, 0xbc, 0x00, 0x9d,
> + 0x00, 0xb2, 0xb5, 0xaa, 0xbc, 0x00, 0xa4
> +
> +};
> +static const unsigned int ld9040_22_260[] = {
> + 0x00, 0xa4, 0xb8, 0xb0, 0xbf, 0x00, 0x80,
> + 0x00, 0xb8, 0xb6, 0xaa, 0xbc, 0x00, 0x9a,
> + 0x00, 0xb0, 0xb5, 0xab, 0xbd, 0x00, 0xa0
> +};
> +
> +static const unsigned int ld9040_22_250[] = {
> + 0x00, 0xa4, 0xb9, 0xaf, 0xc1, 0x00, 0x7d,
> + 0x00, 0xb9, 0xb6, 0xaa, 0xbb, 0x00, 0x97,
> + 0x00, 0xb1, 0xb5, 0xaa, 0xbf, 0x00, 0x9d
> +};
> +
> +static const unsigned int ld9040_22_240[] = {
> + 0x00, 0xa2, 0xb9, 0xaf, 0xc2, 0x00, 0x7a,
> + 0x00, 0xb9, 0xb7, 0xaa, 0xbd, 0x00, 0x94,
> + 0x00, 0xb0, 0xb5, 0xab, 0xbf, 0x00, 0x9a
> +};
> +
> +static const unsigned int ld9040_22_230[] = {
> + 0x00, 0xa0, 0xb9, 0xaf, 0xc3, 0x00, 0x77,
> + 0x00, 0xb9, 0xb7, 0xab, 0xbe, 0x00, 0x90,
> + 0x00, 0xb0, 0xb6, 0xab, 0xbf, 0x00, 0x97
> +};
> +
> +static const unsigned int ld9040_22_220[] = {
> + 0x00, 0x9e, 0xba, 0xb0, 0xc2, 0x00, 0x75,
> + 0x00, 0xb9, 0xb8, 0xab, 0xbe, 0x00, 0x8e,
> + 0x00, 0xb0, 0xb6, 0xac, 0xbf, 0x00, 0x94
> +};
> +
> +static const unsigned int ld9040_22_210[] = {
> + 0x00, 0x9c, 0xb9, 0xb0, 0xc4, 0x00, 0x72,
> + 0x00, 0xb8, 0xb8, 0xac, 0xbf, 0x00, 0x8a,
> + 0x00, 0xb0, 0xb6, 0xac, 0xc0, 0x00, 0x91
> +};
> +
> +static const unsigned int ld9040_22_200[] = {
> + 0x00, 0x9a, 0xba, 0xb1, 0xc4, 0x00, 0x6f,
> + 0x00, 0xb8, 0xb8, 0xad, 0xc0, 0x00, 0x86,
> + 0x00, 0xb0, 0xb7, 0xad, 0xc0, 0x00, 0x8d
> +};
> +
> +static const unsigned int ld9040_22_190[] = {
> + 0x00, 0x97, 0xba, 0xb2, 0xc5, 0x00, 0x6c,
> + 0x00, 0xb8, 0xb8, 0xae, 0xc1, 0x00, 0x82,
> + 0x00, 0xb0, 0xb6, 0xae, 0xc2, 0x00, 0x89
> +};
> +
> +static const unsigned int ld9040_22_180[] = {
> + 0x00, 0x93, 0xba, 0xb3, 0xc5, 0x00, 0x69,
> + 0x00, 0xb8, 0xb9, 0xae, 0xc1, 0x00, 0x7f,
> + 0x00, 0xb0, 0xb6, 0xae, 0xc3, 0x00, 0x85
> +};
> +
> +static const unsigned int ld9040_22_170[] = {
> + 0x00, 0x8b, 0xb9, 0xb3, 0xc7, 0x00, 0x65,
> + 0x00, 0xb7, 0xb8, 0xaf, 0xc3, 0x00, 0x7a,
> + 0x00, 0x80, 0xb6, 0xae, 0xc4, 0x00, 0x81
> +};
> +
> +static const unsigned int ld9040_22_160[] = {
> + 0x00, 0x89, 0xba, 0xb3, 0xc8, 0x00, 0x62,
> + 0x00, 0xb6, 0xba, 0xaf, 0xc3, 0x00, 0x76,
> + 0x00, 0xaf, 0xb7, 0xae, 0xc4, 0x00, 0x7e
> +};
> +
> +static const unsigned int ld9040_22_150[] = {
> + 0x00, 0x82, 0xba, 0xb4, 0xc7, 0x00, 0x5f,
> + 0x00, 0xb5, 0xba, 0xb0, 0xc3, 0x00, 0x72,
> + 0x00, 0xae, 0xb8, 0xb0, 0xc3, 0x00, 0x7a
> +};
> +
> +static const unsigned int ld9040_22_140[] = {
> + 0x00, 0x7b, 0xbb, 0xb4, 0xc8, 0x00, 0x5b,
> + 0x00, 0xb5, 0xba, 0xb1, 0xc4, 0x00, 0x6e,
> + 0x00, 0xae, 0xb9, 0xb0, 0xc5, 0x00, 0x75
> +};
> +
> +static const unsigned int ld9040_22_130[] = {
> + 0x00, 0x71, 0xbb, 0xb5, 0xc8, 0x00, 0x57,
> + 0x00, 0xb5, 0xbb, 0xb0, 0xc5, 0x00, 0x6a,
> + 0x00, 0xae, 0xb9, 0xb1, 0xc6, 0x00, 0x70
> +};
> +
> +static const unsigned int ld9040_22_120[] = {
> + 0x00, 0x47, 0xba, 0xb6, 0xca, 0x00, 0x53,
> + 0x00, 0xb5, 0xbb, 0xb3, 0xc6, 0x00, 0x65,
> + 0x00, 0xae, 0xb8, 0xb3, 0xc7, 0x00, 0x6c
> +};
> +
> +static const unsigned int ld9040_22_110[] = {
> + 0x00, 0x13, 0xbb, 0xb7, 0xca, 0x00, 0x4f,
> + 0x00, 0xb4, 0xbb, 0xb3, 0xc7, 0x00, 0x60,
> + 0x00, 0xad, 0xb8, 0xb4, 0xc7, 0x00, 0x67
> +};
> +
> +static const unsigned int ld9040_22_100[] = {
> + 0x00, 0x13, 0xba, 0xb8, 0xcb, 0x00, 0x4b,
> + 0x00, 0xb3, 0xbc, 0xb4, 0xc7, 0x00, 0x5c,
> + 0x00, 0xac, 0xb8, 0xb4, 0xc8, 0x00, 0x62
> +};
> +
> +static const unsigned int ld9040_22_90[] = {
> + 0x00, 0x13, 0xb9, 0xb8, 0xcd, 0x00, 0x46,
> + 0x00, 0xb1, 0xbc, 0xb5, 0xc8, 0x00, 0x56,
> + 0x00, 0xaa, 0xb8, 0xb4, 0xc9, 0x00, 0x5d
> +};
> +
> +static const unsigned int ld9040_22_80[] = {
> + 0x00, 0x13, 0xba, 0xb9, 0xcd, 0x00, 0x41,
> + 0x00, 0xb0, 0xbe, 0xb5, 0xc9, 0x00, 0x51,
> + 0x00, 0xa9, 0xb9, 0xb5, 0xca, 0x00, 0x57
> +};
> +
> +static const unsigned int ld9040_22_70[] = {
> + 0x00, 0x13, 0xb9, 0xb9, 0xd0, 0x00, 0x3c,
> + 0x00, 0xaf, 0xbf, 0xb6, 0xcb, 0x00, 0x4b,
> + 0x00, 0xa8, 0xb9, 0xb5, 0xcc, 0x00, 0x52
> +};
> +
> +static const unsigned int ld9040_22_50[] = {
> + 0x00, 0x13, 0xb2, 0xba, 0xd2, 0x00, 0x30,
> + 0x00, 0xaf, 0xc0, 0xb8, 0xcd, 0x00, 0x3d,
> + 0x00, 0xa8, 0xb8, 0xb7, 0xcd, 0x00, 0x44
> +};
> +
> +struct ld9040_gamma {
> + unsigned int *gamma_22_table[MAX_GAMMA_LEVEL];
> +};
> +
> +static struct ld9040_gamma gamma_table = {
> + .gamma_22_table[0] = (unsigned int *)&ld9040_22_50,
> + .gamma_22_table[1] = (unsigned int *)&ld9040_22_70,
> + .gamma_22_table[2] = (unsigned int *)&ld9040_22_80,
> + .gamma_22_table[3] = (unsigned int *)&ld9040_22_90,
> + .gamma_22_table[4] = (unsigned int *)&ld9040_22_100,
> + .gamma_22_table[5] = (unsigned int *)&ld9040_22_110,
> + .gamma_22_table[6] = (unsigned int *)&ld9040_22_120,
> + .gamma_22_table[7] = (unsigned int *)&ld9040_22_130,
> + .gamma_22_table[8] = (unsigned int *)&ld9040_22_140,
> + .gamma_22_table[9] = (unsigned int *)&ld9040_22_150,
> + .gamma_22_table[10] = (unsigned int *)&ld9040_22_160,
> + .gamma_22_table[11] = (unsigned int *)&ld9040_22_170,
> + .gamma_22_table[12] = (unsigned int *)&ld9040_22_180,
> + .gamma_22_table[13] = (unsigned int *)&ld9040_22_190,
> + .gamma_22_table[14] = (unsigned int *)&ld9040_22_200,
> + .gamma_22_table[15] = (unsigned int *)&ld9040_22_210,
> + .gamma_22_table[16] = (unsigned int *)&ld9040_22_220,
> + .gamma_22_table[17] = (unsigned int *)&ld9040_22_230,
> + .gamma_22_table[18] = (unsigned int *)&ld9040_22_240,
> + .gamma_22_table[19] = (unsigned int *)&ld9040_22_250,
> + .gamma_22_table[20] = (unsigned int *)&ld9040_22_260,
> + .gamma_22_table[21] = (unsigned int *)&ld9040_22_270,
> + .gamma_22_table[22] = (unsigned int *)&ld9040_22_280,
> + .gamma_22_table[23] = (unsigned int *)&ld9040_22_290,
> + .gamma_22_table[24] = (unsigned int *)&ld9040_22_300,
> +};
> +
> +#endif
> +
^ permalink raw reply
* RE: Request for unicore32 architecture codes to merge into linux-next
From: Guan Xuetao @ 2011-01-19 2:20 UTC (permalink / raw)
To: 'Konrad Rzeszutek Wilk'
Cc: sfr, 'Arnd Bergmann', gregkh, jbarnes, dmitry.torokhov,
dtor, rubini, linux-arch, linux-kernel, linux-fbdev, linux-next
In-Reply-To: <20110118183319.GA13430@dumpdata.com>
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Wednesday, January 19, 2011 2:33 AM
> To: Guan Xuetao
> Cc: sfr@canb.auug.org.au; Arnd Bergmann; gregkh@suse.de; jbarnes@virtuousgeek.org; dmitry.torokhov@gmail.com; dtor@mail.ru;
> rubini@cvml.unipv.it; linux-arch@vger.kernel.org; linux-kernel@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
> next@vger.kernel.org
> Subject: Re: Request for unicore32 architecture codes to merge into linux-next
>
> On Sun, Jan 16, 2011 at 01:00:31AM +0800, Guan Xuetao wrote:
> > Hi,
> >
> > I want to merge unicore32 repo into linux-next tree, the position is (unicore32 branch):
> > git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git
>
> Where can one purchase this hardware for testing?
Please contact our company:
http://www.pkunity.com/english%20version/engcontact.htm
Guan Xuetao
^ permalink raw reply
* [PATCH 2/2] fb: avoid possible deadlock caused by fb_set_suspend
From: Herton Ronaldo Krzesinski @ 2011-01-18 23:09 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Herton Ronaldo Krzesinski
In-Reply-To: <1295392199-31264-1-git-send-email-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 D 0000000000000000 0 237 228 0x00000000
ffff8800774f3d68 0000000000000082 00000000000135c0 00000000000135c0
ffff880000000000 ffff8800774f3fd8 ffff8800774f3fd8 ffff880076ee4530
00000000000135c0 ffff8800774f3fd8 ffff8800774f2000 00000000000135c0
Call Trace:
[<ffffffff8141287a>] __mutex_lock_slowpath+0x11a/0x1e0
[<ffffffff814142f2>] ? _raw_spin_lock_irq+0x22/0x40
[<ffffffff814123d3>] mutex_lock+0x23/0x50
[<ffffffff8125dfc5>] lock_fb_info+0x25/0x60
[<ffffffff8125e3f0>] fb_set_suspend+0x20/0x80
[<ffffffff81263e2f>] store_fbstate+0x4f/0x70
[<ffffffff812e7f70>] dev_attr_store+0x20/0x30
[<ffffffff811c46b4>] sysfs_write_file+0xd4/0x160
[<ffffffff81155a26>] vfs_write+0xc6/0x190
[<ffffffff81155d51>] sys_write+0x51/0x90
[<ffffffff8100c012>] system_call_fastpath+0x16/0x1b
...
modprobe process stalled because has the fb_info lock (got inside
unregister_framebuffer) but waiting for the semaphore held by the
test process which is waiting to get the fb_info lock:
...
modprobe D 0000000000000000 0 230 218 0x00000000
ffff880077a4d618 0000000000000082 0000000000000001 0000000000000001
ffff880000000000 ffff880077a4dfd8 ffff880077a4dfd8 ffff8800775a2e20
00000000000135c0 ffff880077a4dfd8 ffff880077a4c000 00000000000135c0
Call Trace:
[<ffffffff81411fe5>] schedule_timeout+0x215/0x310
[<ffffffff81058051>] ? get_parent_ip+0x11/0x50
[<ffffffff814130dd>] __down+0x6d/0xb0
[<ffffffff81089f71>] down+0x41/0x50
[<ffffffff810629ac>] acquire_console_sem+0x2c/0x50
[<ffffffff812ca53d>] unbind_con_driver+0xad/0x2d0
[<ffffffff8126f5f7>] fbcon_event_notify+0x457/0x890
[<ffffffff814144ff>] ? _raw_spin_unlock_irqrestore+0x1f/0x50
[<ffffffff81058051>] ? get_parent_ip+0x11/0x50
[<ffffffff8141836d>] notifier_call_chain+0x4d/0x70
[<ffffffff8108a3b8>] __blocking_notifier_call_chain+0x58/0x80
[<ffffffff8108a3f6>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff8125dabb>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff8125e6ac>] unregister_framebuffer+0x7c/0x130
[<ffffffff8125e8b3>] remove_conflicting_framebuffers+0x153/0x180
[<ffffffff8125eef3>] register_framebuffer+0x93/0x2c0
[<ffffffffa0331112>] drm_fb_helper_single_fb_probe+0x252/0x2f0 [drm_kms_helper]
[<ffffffffa03314a3>] drm_fb_helper_initial_config+0x2f3/0x6d0 [drm_kms_helper]
[<ffffffffa03318dd>] ? drm_fb_helper_single_add_all_connectors+0x5d/0x1c0 [drm_kms_helper]
[<ffffffffa037b588>] intel_fbdev_init+0xa8/0x160 [i915]
[<ffffffffa0343d74>] i915_driver_load+0x854/0x12b0 [i915]
[<ffffffffa02f0e7e>] drm_get_pci_dev+0x19e/0x360 [drm]
[<ffffffff8141821d>] ? sub_preempt_count+0x9d/0xd0
[<ffffffffa0386f91>] i915_pci_probe+0x15/0x17 [i915]
[<ffffffff8124481f>] local_pci_probe+0x5f/0xd0
[<ffffffff81244f89>] pci_device_probe+0x119/0x120
[<ffffffff812eccaa>] ? driver_sysfs_add+0x7a/0xb0
[<ffffffff812ed003>] driver_probe_device+0xa3/0x290
[<ffffffff812ed1f0>] ? __driver_attach+0x0/0xb0
[<ffffffff812ed29b>] __driver_attach+0xab/0xb0
[<ffffffff812ed1f0>] ? __driver_attach+0x0/0xb0
[<ffffffff812ebd3e>] bus_for_each_dev+0x5e/0x90
[<ffffffff812ecc2e>] driver_attach+0x1e/0x20
[<ffffffff812ec6f2>] bus_add_driver+0xe2/0x320
[<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915]
[<ffffffff812ed536>] driver_register+0x76/0x140
[<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915]
[<ffffffff81245216>] __pci_register_driver+0x56/0xd0
[<ffffffffa02f1264>] drm_pci_init+0xe4/0xf0 [drm]
[<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915]
[<ffffffffa02e84a8>] drm_init+0x58/0x70 [drm]
[<ffffffffa03aa094>] i915_init+0x94/0x96 [i915]
[<ffffffff81002194>] do_one_initcall+0x44/0x190
[<ffffffff810a066b>] sys_init_module+0xcb/0x210
[<ffffffff8100c012>] system_call_fastpath+0x16/0x1b
...
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.
References: https://bugzilla.kernel.org/show_bug.cgi?id&232
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
---
drivers/video/fbmem.c | 4 +---
drivers/video/fbsysfs.c | 3 +++
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 05d09ac..6747e06 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1741,8 +1741,7 @@ void fb_set_suspend(struct fb_info *info, int state)
{
struct fb_event event;
- if (!lock_fb_info(info))
- return;
+ WARN_ON(info->state = FBINFO_STATE_EXITING);
event.info = info;
if (state) {
fb_notifier_call_chain(FB_EVENT_SUSPEND, &event);
@@ -1751,7 +1750,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 be361b5..2ba5370 100644
--- a/drivers/video/fbsysfs.c
+++ b/drivers/video/fbsysfs.c
@@ -401,9 +401,12 @@ static ssize_t store_fbstate(struct device *device,
if (state && state > 1)
return -EINVAL;
+ if (!lock_fb_info(fb_info))
+ return -ENODEV;
acquire_console_sem();
fb_set_suspend(fb_info, (int)state);
release_console_sem();
+ unlock_fb_info(fb_info);
return count;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/2] fb: avoid oops when fb is removed by remove_conflicting_framebuffers
From: Herton Ronaldo Krzesinski @ 2011-01-18 23:09 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Herton Ronaldo Krzesinski
Firmware framebuffers (which have the flag FBINFO_MISC_FIRMWARE) can be
removed and replaced by another native framebuffer, like what happens
when you boot with a vesa framebuffer and later loads a drm module with
modesetting enabled on x86.
When framebuffer which is going to replace the firmware framebuffer is
registered, unregister_framebuffer is called for the old firmware
framebuffer automatically inside remove_conflicting_framebuffers
function. The problem is that while this happens, the old framebuffer
can still be in use.
The first issue in this is that unregister_framebuffer can free/destroy
struct fb_info when calling fb_info->fbops->fb_destroy. The same struct
fb_info is given to file->private_data inside fb_open function, so if
there is an application that have old framebuffer open, and it closes it
after the framebuffer was replaced, fb_release will still get the old
struct fb_info from file->private_data. As it was freed, the kernel will
most likely oops accessing an already freed location inside fb_release.
To fix this, add a reference count to struct fb_info and use it, so the
struct will be only destroyed after the last user closes the framebuffer.
The second issue is that the file_operations framebuffer functions
reference registered_fb array without locking. This can cause a race and
oops if application using the old firmware framebuffer calls a
read/write/mmap/ioctl function while unregister_framebuffer is running,
in the window inside it where registered_fb for the old framebuffer is
set to NULL. To avoid this situation, do not get the framebuffer from
registered_fb array, instead get it from file->private_data which is set
on fb_open. While at it, also add a new fb_info state which is set when
the framebuffer is being unregistered, so that file_operations functions
can check and prevent access to framebuffer when possible, returning an
error if the framebuffer is being or already unregistered.
This addresses kernel.org bug #26232. A testcase is provided in the
ticket which triggers the problem on current kernels.
References: https://bugzilla.kernel.org/show_bug.cgi?id&232
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
---
drivers/video/fbmem.c | 170 ++++++++++++++++++++++++++++++++++-------------
drivers/video/fbsysfs.c | 2 +
include/linux/fb.h | 2 +
3 files changed, 127 insertions(+), 47 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 4ac1201..05d09ac 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -48,7 +48,7 @@ int num_registered_fb __read_mostly;
int lock_fb_info(struct fb_info *info)
{
mutex_lock(&info->lock);
- if (!info->fbops) {
+ if (unlikely(!info->fbops || info->state = FBINFO_STATE_EXITING)) {
mutex_unlock(&info->lock);
return 0;
}
@@ -56,6 +56,72 @@ int lock_fb_info(struct fb_info *info)
}
EXPORT_SYMBOL(lock_fb_info);
+static int fbops_lock_fb_info(struct fb_info *info)
+{
+ int err;
+
+ if (!info->screen_base)
+ return -ENODEV;
+
+ if (info->flags = FBINFO_MISC_FIRMWARE) {
+ err = lock_fb_info(info);
+ if (err) {
+ if (info->state = FBINFO_STATE_SUSPENDED)
+ err = -EPERM;
+ if (err < 1)
+ unlock_fb_info(info);
+ else
+ err = 0;
+ } else
+ err = -ENODEV;
+ return err;
+ }
+
+ if (info->state != FBINFO_STATE_RUNNING)
+ return -EPERM;
+
+ return 0;
+}
+
+static void fbops_unlock_fb_info(struct fb_info *info)
+{
+ if (info->flags = FBINFO_MISC_FIRMWARE)
+ unlock_fb_info(info);
+}
+
+static void fb_kref_init(struct fb_info *info)
+{
+ if (info->flags = FBINFO_MISC_FIRMWARE)
+ kref_init(&info->fwfb_rfcnt);
+}
+
+static void fb_kref_get(struct fb_info *info)
+{
+ if (info->flags = FBINFO_MISC_FIRMWARE)
+ kref_get(&info->fwfb_rfcnt);
+}
+
+static void fb_kref_release(struct kref *ref)
+{
+ struct fb_info *info = container_of(ref, struct fb_info, fwfb_rfcnt);
+
+ if (info->fbops->fb_destroy)
+ info->fbops->fb_destroy(info);
+}
+
+static int fb_kref_put(struct fb_info *info, bool in_unregister)
+{
+ if (info->flags = FBINFO_MISC_FIRMWARE)
+ return kref_put(&info->fwfb_rfcnt, fb_kref_release);
+
+ if (in_unregister && info->fbops->fb_destroy) {
+ info->fbops->fb_destroy(info);
+ return 1;
+ }
+
+ return 0;
+}
+
/*
* Helpers
*/
@@ -694,30 +760,30 @@ static ssize_t
fb_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
{
unsigned long p = *ppos;
- struct inode *inode = file->f_path.dentry->d_inode;
- int fbidx = iminor(inode);
- struct fb_info *info = registered_fb[fbidx];
+ struct fb_info *info = file->private_data;
u8 *buffer, *dst;
u8 __iomem *src;
- int c, cnt = 0, err = 0;
+ int c, cnt = 0, err;
unsigned long total_size;
- if (!info || ! info->screen_base)
- return -ENODEV;
+ err = fbops_lock_fb_info(info);
+ if (err)
+ return err;
- if (info->state != FBINFO_STATE_RUNNING)
- return -EPERM;
+ if (info->fbops->fb_read) {
+ err = info->fbops->fb_read(info, buf, count, ppos);
+ goto fb_read_exit;
+ }
- if (info->fbops->fb_read)
- return info->fbops->fb_read(info, buf, count, ppos);
-
total_size = info->screen_size;
if (total_size = 0)
total_size = info->fix.smem_len;
- if (p >= total_size)
- return 0;
+ if (p >= total_size) {
+ err = 0;
+ goto fb_read_exit;
+ }
if (count >= total_size)
count = total_size;
@@ -727,8 +793,10 @@ fb_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
buffer = kmalloc((count > PAGE_SIZE) ? PAGE_SIZE : count,
GFP_KERNEL);
- if (!buffer)
- return -ENOMEM;
+ if (!buffer) {
+ err = -ENOMEM;
+ goto fb_read_exit;
+ }
src = (u8 __iomem *) (info->screen_base + p);
@@ -754,37 +822,42 @@ fb_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
kfree(buffer);
- return (err) ? err : cnt;
+ if (!err)
+ err = cnt;
+
+fb_read_exit:
+ fbops_unlock_fb_info(info);
+ return err;
}
static ssize_t
fb_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos)
{
unsigned long p = *ppos;
- struct inode *inode = file->f_path.dentry->d_inode;
- int fbidx = iminor(inode);
- struct fb_info *info = registered_fb[fbidx];
+ struct fb_info *info = file->private_data;
u8 *buffer, *src;
u8 __iomem *dst;
- int c, cnt = 0, err = 0;
+ int c, cnt = 0, err;
unsigned long total_size;
- if (!info || !info->screen_base)
- return -ENODEV;
+ err = fbops_lock_fb_info(info);
+ if (err)
+ return err;
- if (info->state != FBINFO_STATE_RUNNING)
- return -EPERM;
+ if (info->fbops->fb_write) {
+ err = info->fbops->fb_write(info, buf, count, ppos);
+ goto fb_write_exit;
+ }
- if (info->fbops->fb_write)
- return info->fbops->fb_write(info, buf, count, ppos);
-
total_size = info->screen_size;
if (total_size = 0)
total_size = info->fix.smem_len;
- if (p > total_size)
- return -EFBIG;
+ if (p > total_size) {
+ err = -EFBIG;
+ goto fb_write_exit;
+ }
if (count > total_size) {
err = -EFBIG;
@@ -800,8 +873,10 @@ fb_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos)
buffer = kmalloc((count > PAGE_SIZE) ? PAGE_SIZE : count,
GFP_KERNEL);
- if (!buffer)
- return -ENOMEM;
+ if (!buffer) {
+ err = -ENOMEM;
+ goto fb_write_exit;
+ }
dst = (u8 __iomem *) (info->screen_base + p);
@@ -828,7 +903,12 @@ fb_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos)
kfree(buffer);
- return (cnt) ? cnt : err;
+ if (cnt)
+ err = cnt;
+
+fb_write_exit:
+ fbops_unlock_fb_info(info);
+ return err;
}
int
@@ -1141,9 +1221,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
static long fb_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
- struct inode *inode = file->f_path.dentry->d_inode;
- int fbidx = iminor(inode);
- struct fb_info *info = registered_fb[fbidx];
+ struct fb_info *info = file->private_data;
return do_fb_ioctl(info, cmd, arg);
}
@@ -1265,9 +1343,7 @@ static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd,
static long fb_compat_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
- struct inode *inode = file->f_path.dentry->d_inode;
- int fbidx = iminor(inode);
- struct fb_info *info = registered_fb[fbidx];
+ struct fb_info *info = file->private_data;
struct fb_ops *fb = info->fbops;
long ret = -ENOIOCTLCMD;
@@ -1303,8 +1379,7 @@ static long fb_compat_ioctl(struct file *file, unsigned int cmd,
static int
fb_mmap(struct file *file, struct vm_area_struct * vma)
{
- int fbidx = iminor(file->f_path.dentry->d_inode);
- struct fb_info *info = registered_fb[fbidx];
+ struct fb_info *info = file->private_data;
struct fb_ops *fb = info->fbops;
unsigned long off;
unsigned long start;
@@ -1380,6 +1455,8 @@ __releases(&info->lock)
if (res)
module_put(info->fbops->owner);
}
+ if (!res)
+ fb_kref_get(info);
#ifdef CONFIG_FB_DEFERRED_IO
if (info->fbdefio)
fb_deferred_io_open(info, inode, file);
@@ -1401,6 +1478,7 @@ __releases(&info->lock)
info->fbops->fb_release(info,1);
module_put(info->fbops->owner);
mutex_unlock(&info->lock);
+ fb_kref_put(info, false);
return 0;
}
@@ -1549,6 +1627,7 @@ register_framebuffer(struct fb_info *fb_info)
fb_info->node = i;
mutex_init(&fb_info->lock);
mutex_init(&fb_info->mm_lock);
+ fb_kref_init(fb_info);
fb_info->dev = device_create(fb_class, fb_info->device,
MKDEV(FB_MAJOR, i), NULL, "fb%d", i);
@@ -1622,9 +1701,9 @@ unregister_framebuffer(struct fb_info *fb_info)
goto done;
}
-
if (!lock_fb_info(fb_info))
return -ENODEV;
+ fb_info->state = FBINFO_STATE_EXITING;
event.info = fb_info;
ret = fb_notifier_call_chain(FB_EVENT_FB_UNBIND, &event);
unlock_fb_info(fb_info);
@@ -1644,10 +1723,7 @@ unregister_framebuffer(struct fb_info *fb_info)
device_destroy(fb_class, MKDEV(FB_MAJOR, i));
event.info = fb_info;
fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
-
- /* this may free fb info */
- if (fb_info->fbops->fb_destroy)
- fb_info->fbops->fb_destroy(fb_info);
+ fb_kref_put(fb_info, true);
done:
return ret;
}
@@ -1655,7 +1731,7 @@ done:
/**
* fb_set_suspend - low level driver signals suspend
* @info: framebuffer affected
- * @state: 0 = resuming, !=0 = suspending
+ * @state: 0 = resuming, 1 = suspending
*
* This is meant to be used by low level drivers to
* signal suspend/resume to the core & clients.
diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c
index 0a08f13..be361b5 100644
--- a/drivers/video/fbsysfs.c
+++ b/drivers/video/fbsysfs.c
@@ -398,6 +398,8 @@ static ssize_t store_fbstate(struct device *device,
char *last = NULL;
state = simple_strtoul(buf, &last, 0);
+ if (state && state > 1)
+ return -EINVAL;
acquire_console_sem();
fb_set_suspend(fb_info, (int)state);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index d1631d3..836f605 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -871,6 +871,7 @@ struct fb_info {
void *pseudo_palette; /* Fake palette of 16 colors */
#define FBINFO_STATE_RUNNING 0
#define FBINFO_STATE_SUSPENDED 1
+#define FBINFO_STATE_EXITING 2
u32 state; /* Hardware state i.e suspend */
void *fbcon_par; /* fbcon use-only private area */
/* From here on everything is device dependent */
@@ -885,6 +886,7 @@ struct fb_info {
resource_size_t size;
} ranges[0];
} *apertures;
+ struct kref fwfb_rfcnt;
};
static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
--
1.7.3.4
^ permalink raw reply related
* Re: Request for unicore32 architecture codes to merge into
From: Konrad Rzeszutek Wilk @ 2011-01-18 18:33 UTC (permalink / raw)
To: Guan Xuetao
Cc: sfr, Arnd Bergmann, gregkh, jbarnes, dmitry.torokhov, dtor,
rubini, linux-arch, linux-kernel, linux-fbdev, linux-next
In-Reply-To: <004901cbb4d5$b9bb1370$2d313a50$@mprc.pku.edu.cn>
On Sun, Jan 16, 2011 at 01:00:31AM +0800, Guan Xuetao wrote:
> Hi,
>
> I want to merge unicore32 repo into linux-next tree, the position is (unicore32 branch):
> git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git
Where can one purchase this hardware for testing?
^ permalink raw reply
* Re: Request for unicore32 architecture codes to merge into linux-next
From: Paul Mundt @ 2011-01-18 9:53 UTC (permalink / raw)
To: Guan Xuetao
Cc: sfr, 'Arnd Bergmann', gregkh, jbarnes, dmitry.torokhov,
dtor, rubini, linux-arch, linux-kernel, linux-fbdev, linux-next
In-Reply-To: <01bf01cbb6f2$cdba4a70$692edf50$@mprc.pku.edu.cn>
On Tue, Jan 18, 2011 at 05:33:44PM +0800, Guan Xuetao wrote:
> > -----Original Message-----
> > From: linux-next-owner@vger.kernel.org [mailto:linux-next-owner@vger.kernel.org] On Behalf Of Paul Mundt
> > Sent: Tuesday, January 18, 2011 5:11 PM
> > To: Guan Xuetao
> > Cc: sfr@canb.auug.org.au; 'Arnd Bergmann'; gregkh@suse.de; jbarnes@virtuousgeek.org; dmitry.torokhov@gmail.com; dtor@mail.ru;
> > rubini@cvml.unipv.it; linux-arch@vger.kernel.org; linux-kernel@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
> > next@vger.kernel.org
> > Subject: Re: Request for unicore32 architecture codes to merge into linux-next
> >
> > On Tue, Jan 18, 2011 at 05:07:41PM +0800, Guan Xuetao wrote:
> > > IMO, the whole architecture specific codes need to be merged first, and only some
> > > necessary drivers are included under staging. Then, I could split the staging drivers
> > > into corresponding mail-list, and then, additional drivers.
> > > Otherwise, there are no architecture basic for drivers review.
> > >
> > That's of course fine so long as the driver changes are reasonably
> > self-contained. The situation we want to avoid is that you end up with
> > drivers that depend on some private infrastructure of API where not
> > enough context is provided when the two are decoupled.
> >
> > In any event, the architecture bits are the most self-contained and have
> > had the most review of anything in this series of patches, so it probably
> > makes sense to work on getting those bits integrated and then dealing
> > with the rest incrementally.
> Then, I should:
> 1. merge reviewed arch dir and reviewed drivers (for now, i8042)
> 2. submit staging drivers to review
> Am I right?
>
That would at least make it easier to get parts of it merged while the
drivers get reviewed and reworked. If enough people are content with the
state of the architecture patches then there is no reason why they can't
be pulled in to -next once it's open for .39 changes. The drivers can
then gradually find their way in to -next via subsystem trees.
From my point of view (though I don't believe I'm a minority in this),
staging/ in general should be a last resort for new drivers. Since you
are at least actively replying and making changes that have been
requested, there should really be no need to go the staging route for
any of the drivers at all.
On the other hand, if it turns out you have a big chunk of crazed and
incomprehensible infrastructure like an interpreter or something equally
perverse in the middle somewhere that everything depends on, that does of
course complicate things and limit your options somewhat, but those sorts
of things are hopefully corner cases (I admit the fact that you're
linking libc in to the kernel has rather scared me away from reviewing
the rest of the patches under closer scrutiny). Your goal in general
should be to avoid staging completely and submit small logically isolated
components that can be reviewed and merged wholly independently of
anything else.
^ permalink raw reply
* RE: Request for unicore32 architecture codes to merge into linux-next
From: Guan Xuetao @ 2011-01-18 9:33 UTC (permalink / raw)
To: 'Paul Mundt'
Cc: sfr, 'Arnd Bergmann', gregkh, jbarnes, dmitry.torokhov,
dtor, rubini, linux-arch, linux-kernel, linux-fbdev, linux-next
In-Reply-To: <20110118091032.GA18525@linux-sh.org>
> -----Original Message-----
> From: linux-next-owner@vger.kernel.org [mailto:linux-next-owner@vger.kernel.org] On Behalf Of Paul Mundt
> Sent: Tuesday, January 18, 2011 5:11 PM
> To: Guan Xuetao
> Cc: sfr@canb.auug.org.au; 'Arnd Bergmann'; gregkh@suse.de; jbarnes@virtuousgeek.org; dmitry.torokhov@gmail.com; dtor@mail.ru;
> rubini@cvml.unipv.it; linux-arch@vger.kernel.org; linux-kernel@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
> next@vger.kernel.org
> Subject: Re: Request for unicore32 architecture codes to merge into linux-next
>
> On Tue, Jan 18, 2011 at 05:07:41PM +0800, Guan Xuetao wrote:
> > IMO, the whole architecture specific codes need to be merged first, and only some
> > necessary drivers are included under staging. Then, I could split the staging drivers
> > into corresponding mail-list, and then, additional drivers.
> > Otherwise, there are no architecture basic for drivers review.
> >
> That's of course fine so long as the driver changes are reasonably
> self-contained. The situation we want to avoid is that you end up with
> drivers that depend on some private infrastructure of API where not
> enough context is provided when the two are decoupled.
>
> In any event, the architecture bits are the most self-contained and have
> had the most review of anything in this series of patches, so it probably
> makes sense to work on getting those bits integrated and then dealing
> with the rest incrementally.
Then, I should:
1. merge reviewed arch dir and reviewed drivers (for now, i8042)
2. submit staging drivers to review
Am I right?
Thanks.
Guan Xuetao
^ permalink raw reply
* Re: Request for unicore32 architecture codes to merge into linux-next
From: Paul Mundt @ 2011-01-18 9:10 UTC (permalink / raw)
To: Guan Xuetao
Cc: sfr, 'Arnd Bergmann', gregkh, jbarnes, dmitry.torokhov,
dtor, rubini, linux-arch, linux-kernel, linux-fbdev, linux-next
In-Reply-To: <01b501cbb6ef$3299f2a0$97cdd7e0$@mprc.pku.edu.cn>
On Tue, Jan 18, 2011 at 05:07:41PM +0800, Guan Xuetao wrote:
> IMO, the whole architecture specific codes need to be merged first, and only some
> necessary drivers are included under staging. Then, I could split the staging drivers
> into corresponding mail-list, and then, additional drivers.
> Otherwise, there are no architecture basic for drivers review.
>
That's of course fine so long as the driver changes are reasonably
self-contained. The situation we want to avoid is that you end up with
drivers that depend on some private infrastructure of API where not
enough context is provided when the two are decoupled.
In any event, the architecture bits are the most self-contained and have
had the most review of anything in this series of patches, so it probably
makes sense to work on getting those bits integrated and then dealing
with the rest incrementally.
^ permalink raw reply
* RE: Request for unicore32 architecture codes to merge into linux-next
From: Guan Xuetao @ 2011-01-18 9:07 UTC (permalink / raw)
To: 'Paul Mundt'
Cc: sfr, 'Arnd Bergmann', gregkh, jbarnes, dmitry.torokhov,
dtor, rubini, linux-arch, linux-kernel, linux-fbdev, linux-next
In-Reply-To: <20110118043323.GF2122@linux-sh.org>
> -----Original Message-----
> From: Paul Mundt [mailto:lethal@linux-sh.org]
> Sent: Tuesday, January 18, 2011 12:33 PM
> To: Guan Xuetao
> Cc: sfr@canb.auug.org.au; Arnd Bergmann; gregkh@suse.de; jbarnes@virtuousgeek.org; dmitry.torokhov@gmail.com; dtor@mail.ru;
> rubini@cvml.unipv.it; linux-arch@vger.kernel.org; linux-kernel@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
> next@vger.kernel.org
> Subject: Re: Request for unicore32 architecture codes to merge into linux-next
>
> On Sun, Jan 16, 2011 at 01:00:31AM +0800, Guan Xuetao wrote:
> > drivers/staging/puv3/Kconfig | 125 ++
> > drivers/staging/puv3/Makefile | 22 +
> > drivers/staging/puv3/TODO | 7 +
> > drivers/staging/puv3/i8042-ucio.h | 89 ++
> > drivers/staging/puv3/puv3-atkbd.h | 43 +
> > drivers/staging/puv3/puv3_ac97.c | 369 +++++
> > drivers/staging/puv3/puv3_i2c.c | 309 ++++
> > drivers/staging/puv3/puv3_pcm.c | 435 ++++++
> > drivers/staging/puv3/puv3_pcm.h | 28 +
> > drivers/staging/puv3/puv3_umal.c | 2069 +++++++++++++++++++++++++
> > drivers/staging/puv3/puv3_unifb.c | 965 ++++++++++++
>
> Staging is not a shortcut around having things reviewed or broken out
> logically. It's of course fine to merge the bulk of things in one go for
> when a new architecture is going on, but logically disparate parts still
> need to be broken out and sent to the proper places for review. It's
> obvious you haven't done this for any of the non-arch bits and hiding
> things under staging is not going to make this step any less necessary.
>
> If you want your framebuffer driver reviewed, then split it out and
> submit it to the linux-fbdev list for review. Once that's had a going
> over and been Acked then of course it can be merged through whatever tree
> you like, and there's even a good chance that you don't need to bother
> with staging at all.
>
> Using staging as a review circumvention measure however is just not going
> to fly.
I understand.
IMO, the whole architecture specific codes need to be merged first, and only some
necessary drivers are included under staging. Then, I could split the staging drivers
into corresponding mail-list, and then, additional drivers.
Otherwise, there are no architecture basic for drivers review.
Thanks
Guan Xuetao
^ permalink raw reply
* Re: [PATCH] video: pxa3xx-gcu: Return -EFAULT when copy_from_user() fails
From: Paul Mundt @ 2011-01-18 4:38 UTC (permalink / raw)
To: Axel Lin
Cc: linux-kernel, Daniel Mack, Janine Kropp, Denis Oliver Kropp,
Eric Miao, linux-fbdev
In-Reply-To: <1294997951.12295.1.camel@mola>
On Fri, Jan 14, 2011 at 05:39:11PM +0800, Axel Lin wrote:
> Return -EFAULT instead of number of bytes that could not be copied if
> copy_from_user() fails.
>
> Also fix a typo in the comments.
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] video: nuc900fb: fix compile error
From: Paul Mundt @ 2011-01-18 4:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295253143.12890.3.camel@mola>
On Mon, Jan 17, 2011 at 04:32:23PM +0800, Axel Lin wrote:
> >From a4bd940fa4d162f95e51e67c7ec4973b1d5b6866 Mon Sep 17 00:00:00 2001
> From: Axel Lin <axel.lin@gmail.com>
> Date: Mon, 17 Jan 2011 16:24:36 +0800
> Subject: [PATCH 1/2] video: nuc900fb: fix compile error
>
> This patch fixes below compile error:
>
> CC drivers/video/nuc900fb.o
> drivers/video/nuc900fb.c: In function 'nuc900fb_suspend':
> drivers/video/nuc900fb.c:726: error: too few arguments to function 'nuc900fb_stop_lcd'
> drivers/video/nuc900fb.c: In function 'nuc900fb_resume':
> drivers/video/nuc900fb.c:743: error: 'bfinfo' undeclared (first use in this function)
> drivers/video/nuc900fb.c:743: error: (Each undeclared identifier is reported only once
> drivers/video/nuc900fb.c:743: error: for each function it appears in.)
> make[2]: *** [drivers/video/nuc900fb.o] Error 1
> make[1]: *** [drivers/video] Error 2
> make: *** [drivers] Error 2
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
On Mon, Jan 17, 2011 at 04:33:42PM +0800, Axel Lin wrote:
> >From f0064467b1f9696ebcade98ec75ef3fbc6cfe38f Mon Sep 17 00:00:00 2001
> From: Axel Lin <axel.lin@gmail.com>
> Date: Mon, 17 Jan 2011 16:25:57 +0800
> Subject: [PATCH 2/2] video: nuc900fb: properly free resources in nuc900fb_remove
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
Both applied, thanks.
^ permalink raw reply
* Re: Request for unicore32 architecture codes to merge into linux-next
From: Paul Mundt @ 2011-01-18 4:33 UTC (permalink / raw)
To: Guan Xuetao
Cc: sfr, Arnd Bergmann, gregkh, jbarnes, dmitry.torokhov, dtor,
rubini, linux-arch, linux-kernel, linux-fbdev, linux-next
In-Reply-To: <004901cbb4d5$b9bb1370$2d313a50$@mprc.pku.edu.cn>
On Sun, Jan 16, 2011 at 01:00:31AM +0800, Guan Xuetao wrote:
> drivers/staging/puv3/Kconfig | 125 ++
> drivers/staging/puv3/Makefile | 22 +
> drivers/staging/puv3/TODO | 7 +
> drivers/staging/puv3/i8042-ucio.h | 89 ++
> drivers/staging/puv3/puv3-atkbd.h | 43 +
> drivers/staging/puv3/puv3_ac97.c | 369 +++++
> drivers/staging/puv3/puv3_i2c.c | 309 ++++
> drivers/staging/puv3/puv3_pcm.c | 435 ++++++
> drivers/staging/puv3/puv3_pcm.h | 28 +
> drivers/staging/puv3/puv3_umal.c | 2069 +++++++++++++++++++++++++
> drivers/staging/puv3/puv3_unifb.c | 965 ++++++++++++
Staging is not a shortcut around having things reviewed or broken out
logically. It's of course fine to merge the bulk of things in one go for
when a new architecture is going on, but logically disparate parts still
need to be broken out and sent to the proper places for review. It's
obvious you haven't done this for any of the non-arch bits and hiding
things under staging is not going to make this step any less necessary.
If you want your framebuffer driver reviewed, then split it out and
submit it to the linux-fbdev list for review. Once that's had a going
over and been Acked then of course it can be merged through whatever tree
you like, and there's even a good chance that you don't need to bother
with staging at all.
Using staging as a review circumvention measure however is just not going
to fly.
^ permalink raw reply
* Re: [PATCH 1/2] video: nuc900fb: fix compile error
From: Wan ZongShun @ 2011-01-17 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295253143.12890.3.camel@mola>
2011/1/17 Axel Lin <axel.lin@gmail.com>:
> >From a4bd940fa4d162f95e51e67c7ec4973b1d5b6866 Mon Sep 17 00:00:00 2001
> From: Axel Lin <axel.lin@gmail.com>
> Date: Mon, 17 Jan 2011 16:24:36 +0800
> Subject: [PATCH 1/2] video: nuc900fb: fix compile error
>
> This patch fixes below compile error:
>
> CC drivers/video/nuc900fb.o
> drivers/video/nuc900fb.c: In function 'nuc900fb_suspend':
> drivers/video/nuc900fb.c:726: error: too few arguments to function 'nuc900fb_stop_lcd'
> drivers/video/nuc900fb.c: In function 'nuc900fb_resume':
> drivers/video/nuc900fb.c:743: error: 'bfinfo' undeclared (first use in this function)
> drivers/video/nuc900fb.c:743: error: (Each undeclared identifier is reported only once
> drivers/video/nuc900fb.c:743: error: for each function it appears in.)
> make[2]: *** [drivers/video/nuc900fb.o] Error 1
> make[1]: *** [drivers/video] Error 2
> make: *** [drivers] Error 2
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
> ---
> drivers/video/nuc900fb.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
> index 62498bd..29ef92f 100644
> --- a/drivers/video/nuc900fb.c
> +++ b/drivers/video/nuc900fb.c
> @@ -723,7 +723,7 @@ static int nuc900fb_suspend(struct platform_device *dev, pm_message_t state)
> struct fb_info *fbinfo = platform_get_drvdata(dev);
> struct nuc900fb_info *info = fbinfo->par;
>
> - nuc900fb_stop_lcd();
> + nuc900fb_stop_lcd(fbinfo);
> msleep(1);
> clk_disable(info->clk);
> return 0;
> @@ -740,7 +740,7 @@ static int nuc900fb_resume(struct platform_device *dev)
> msleep(1);
>
> nuc900fb_init_registers(fbinfo);
> - nuc900fb_activate_var(bfinfo);
> + nuc900fb_activate_var(fbinfo);
>
> return 0;
> }
Thanks for your patches.
Acked-by: Wan ZongShun <mcuos.com@gmail.com>
> --
> 1.7.2
>
>
>
>
--
*linux-arm-kernel mailing list
mail addr:linux-arm-kernel@lists.infradead.org
you can subscribe by:
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
* linux-arm-NUC900 mailing list
mail addr:NUC900@googlegroups.com
main web: https://groups.google.com/group/NUC900
you can subscribe it by sending me mail:
mcuos.com@gmail.com
^ permalink raw reply
* [PATCH 2/2] video: nuc900fb: properly free resources in
From: Axel Lin @ 2011-01-17 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295253143.12890.3.camel@mola>
From f0064467b1f9696ebcade98ec75ef3fbc6cfe38f Mon Sep 17 00:00:00 2001
From: Axel Lin <axel.lin@gmail.com>
Date: Mon, 17 Jan 2011 16:25:57 +0800
Subject: [PATCH 2/2] video: nuc900fb: properly free resources in nuc900fb_remove
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
drivers/video/nuc900fb.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
index 29ef92f..f838d9e 100644
--- a/drivers/video/nuc900fb.c
+++ b/drivers/video/nuc900fb.c
@@ -696,6 +696,8 @@ static int nuc900fb_remove(struct platform_device *pdev)
nuc900fb_stop_lcd(fbinfo);
msleep(1);
+ unregister_framebuffer(fbinfo);
+ nuc900fb_cpufreq_deregister(fbi);
nuc900fb_unmap_video_memory(fbinfo);
iounmap(fbi->io);
--
1.7.2
^ permalink raw reply related
* [PATCH 1/2] video: nuc900fb: fix compile error
From: Axel Lin @ 2011-01-17 8:32 UTC (permalink / raw)
To: linux-arm-kernel
From a4bd940fa4d162f95e51e67c7ec4973b1d5b6866 Mon Sep 17 00:00:00 2001
From: Axel Lin <axel.lin@gmail.com>
Date: Mon, 17 Jan 2011 16:24:36 +0800
Subject: [PATCH 1/2] video: nuc900fb: fix compile error
This patch fixes below compile error:
CC drivers/video/nuc900fb.o
drivers/video/nuc900fb.c: In function 'nuc900fb_suspend':
drivers/video/nuc900fb.c:726: error: too few arguments to function 'nuc900fb_stop_lcd'
drivers/video/nuc900fb.c: In function 'nuc900fb_resume':
drivers/video/nuc900fb.c:743: error: 'bfinfo' undeclared (first use in this function)
drivers/video/nuc900fb.c:743: error: (Each undeclared identifier is reported only once
drivers/video/nuc900fb.c:743: error: for each function it appears in.)
make[2]: *** [drivers/video/nuc900fb.o] Error 1
make[1]: *** [drivers/video] Error 2
make: *** [drivers] Error 2
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
drivers/video/nuc900fb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
index 62498bd..29ef92f 100644
--- a/drivers/video/nuc900fb.c
+++ b/drivers/video/nuc900fb.c
@@ -723,7 +723,7 @@ static int nuc900fb_suspend(struct platform_device *dev, pm_message_t state)
struct fb_info *fbinfo = platform_get_drvdata(dev);
struct nuc900fb_info *info = fbinfo->par;
- nuc900fb_stop_lcd();
+ nuc900fb_stop_lcd(fbinfo);
msleep(1);
clk_disable(info->clk);
return 0;
@@ -740,7 +740,7 @@ static int nuc900fb_resume(struct platform_device *dev)
msleep(1);
nuc900fb_init_registers(fbinfo);
- nuc900fb_activate_var(bfinfo);
+ nuc900fb_activate_var(fbinfo);
return 0;
}
--
1.7.2
^ permalink raw reply related
* Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI
From: David Miller @ 2011-01-17 4:30 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111.154846.233419170.davem@davemloft.net>
From: Alex Buell <alex.buell@munted.org.uk>
Date: Wed, 12 Jan 2011 23:43:02 +0000
> Jan 12 21:53:27 sodium pci@8,700000: PCI Error, primary error type[Master Abort]
> Jan 12 21:53:27 sodium kernel: /pci@8,700pci@8,pci@8,700000: PCter Aborpci@8,700000: PCI Error, primary error type[Master Abort]
> Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0080] was_block(0) space(Memory)
> Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI AFAR [00000000000a00a8]
> Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Secondary errors [(Master Abort)]
> Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Error, primary error type[Master Abort]
The address we're using seems right, but for some reason the device
is giving a master abort when we try to access the legacy VGA memory.
I did a little bit of research, and there is a bit in the VGA I/O
register set that needs to be set otherwise the VGA card will not
respond to video memory accesses.
Can you test to see if the following patch makes a difference?
diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c
index 4b8f215..00152f6 100644
--- a/drivers/video/s3fb.c
+++ b/drivers/video/s3fb.c
@@ -1053,6 +1053,13 @@ static int __devinit s3_pci_probe(struct pci_dev *dev, const struct pci_device_i
vga_wcrt(par->state.vgabase, 0x38, cr38);
vga_wcrt(par->state.vgabase, 0x39, cr39);
+ /* Ensure that the card will respond to legacy VGA memory
+ * accesses.
+ */
+ regval = vga_r(par->state.vgabase, VGA_MIS_R);
+ regval |= VGA_MIS_ENB_MEM_ACCESS;
+ vga_w(par->state.vgabase, VGA_MIS_W, regval);
+
strcpy(info->fix.id, s3_names [par->chip]);
info->fix.mmio_start = 0;
info->fix.mmio_len = 0;
^ permalink raw reply related
* RE: Request for unicore32 architecture codes to merge into linux-next
From: Guan Xuetao @ 2011-01-16 15:35 UTC (permalink / raw)
To: 'Dmitry Torokhov'
Cc: sfr, 'Arnd Bergmann', gregkh, jbarnes, rubini, linux-arch,
linux-kernel, linux-fbdev, linux-next
In-Reply-To: <20110115220809.GC19872@core.coreip.homeip.net>
> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Sunday, January 16, 2011 6:08 AM
> To: Guan Xuetao
> Cc: sfr@canb.auug.org.au; Arnd Bergmann; gregkh@suse.de; jbarnes@virtuousgeek.org; rubini@cvml.unipv.it; linux-
> arch@vger.kernel.org; linux-kernel@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-next@vger.kernel.org
> Subject: Re: Request for unicore32 architecture codes to merge into linux-next
>
> Hi,
>
> On Sun, Jan 16, 2011 at 01:00:31AM +0800, Guan Xuetao wrote:
> > Hi,
> >
> > I want to merge unicore32 repo into linux-next tree, the position is (unicore32 branch):
> > git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git
> >
>
> Have these changes been reviewed at all? Looking at the input parts I
> doubt it... We try _really_ hard to avoid sprinkling arch #ifedefs in
> the common code.
Many people helped me to review the patchset in linux-arch and linux-kernel mailist.
For ps2 driver, perhaps I should not introduce bugfix for the machine, so I remove the additional
modification, and only i8042 is necessary.
The patchset is rebased, and git dir and branch name remain the same.
Please update.
>
> So, for input:
>
> - how big is the difference between standard keytable and the one you
> are introducing? Looks like you are just adding 5 new keys that are
> not critical for booting. So please just update keymap from userpsace
> as we do for countless laptops and keyboards out there.
I understand.
And I remove the keytable.
>
> - Trying to enable mouse 1000 times can lead to loooong delays. Have
> you tried to figure out why you need the loop?
>
> - What kind of mice can be connected to teh devices? I am concerned that
> your super-strict protocol checks will cause more harm then good (i do
> not believe they are valied in general case, overflow is just and
> additional bit).
>
> Please split changes related into logically separated patches and post
> them on linux-input@vger.kernel.org (along with linux-kernel if you
> prefer) for review and comments.
>
> Thanks.
>
> --
> Dmitry
Thanks Dmitry.
Guan Xuetao
^ permalink raw reply
* Re: Request for unicore32 architecture codes to merge into linux-next
From: Dmitry Torokhov @ 2011-01-15 22:08 UTC (permalink / raw)
To: Guan Xuetao
Cc: sfr, Arnd Bergmann, gregkh, jbarnes, rubini, linux-arch,
linux-kernel, linux-fbdev, linux-next
In-Reply-To: <004901cbb4d5$b9bb1370$2d313a50$@mprc.pku.edu.cn>
Hi,
On Sun, Jan 16, 2011 at 01:00:31AM +0800, Guan Xuetao wrote:
> Hi,
>
> I want to merge unicore32 repo into linux-next tree, the position is (unicore32 branch):
> git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git
>
Have these changes been reviewed at all? Looking at the input parts I
doubt it... We try _really_ hard to avoid sprinkling arch #ifedefs in
the common code.
So, for input:
- how big is the difference between standard keytable and the one you
are introducing? Looks like you are just adding 5 new keys that are
not critical for booting. So please just update keymap from userpsace
as we do for countless laptops and keyboards out there.
- Trying to enable mouse 1000 times can lead to loooong delays. Have
you tried to figure out why you need the loop?
- What kind of mice can be connected to teh devices? I am concerned that
your super-strict protocol checks will cause more harm then good (i do
not believe they are valied in general case, overflow is just and
additional bit).
Please split changes related into logically separated patches and post
them on linux-input@vger.kernel.org (along with linux-kernel if you
prefer) for review and comments.
Thanks.
--
Dmitry
^ permalink raw reply
* Request for unicore32 architecture codes to merge into linux-next
From: Guan Xuetao @ 2011-01-15 17:00 UTC (permalink / raw)
To: sfr, Arnd Bergmann, gregkh, jbarnes, dmitry.torokhov, dtor,
rubini
Cc: linux-arch, linux-kernel, linux-fbdev, linux-next
Hi,
I want to merge unicore32 repo into linux-next tree, the position is (unicore32 branch):
git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git
Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
---
MAINTAINERS | 8 +
arch/unicore32/.gitignore | 21 +
arch/unicore32/Kconfig | 248 +++
arch/unicore32/Kconfig.debug | 68 +
arch/unicore32/Makefile | 97 ++
arch/unicore32/boot/Makefile | 47 +
arch/unicore32/boot/compressed/Makefile | 68 +
arch/unicore32/boot/compressed/head.S | 204 +++
arch/unicore32/boot/compressed/misc.c | 126 ++
arch/unicore32/boot/compressed/piggy.S.in | 6 +
arch/unicore32/boot/compressed/vmlinux.lds.in | 61 +
arch/unicore32/configs/debug_defconfig | 210 +++
arch/unicore32/configs/nb0916_defconfig | 202 +++
arch/unicore32/include/asm/Kbuild | 2 +
arch/unicore32/include/asm/assembler.h | 131 ++
arch/unicore32/include/asm/bitops.h | 47 +
arch/unicore32/include/asm/byteorder.h | 24 +
arch/unicore32/include/asm/cache.h | 27 +
arch/unicore32/include/asm/cacheflush.h | 211 +++
arch/unicore32/include/asm/checksum.h | 41 +
arch/unicore32/include/asm/cpu-single.h | 45 +
arch/unicore32/include/asm/cputype.h | 33 +
arch/unicore32/include/asm/delay.h | 52 +
arch/unicore32/include/asm/dma-mapping.h | 124 ++
arch/unicore32/include/asm/dma.h | 23 +
arch/unicore32/include/asm/elf.h | 94 ++
arch/unicore32/include/asm/fpstate.h | 26 +
arch/unicore32/include/asm/fpu-ucf64.h | 53 +
arch/unicore32/include/asm/futex.h | 143 ++
arch/unicore32/include/asm/gpio.h | 103 ++
arch/unicore32/include/asm/hwcap.h | 32 +
arch/unicore32/include/asm/io.h | 52 +
arch/unicore32/include/asm/irq.h | 107 ++
arch/unicore32/include/asm/irqflags.h | 53 +
arch/unicore32/include/asm/linkage.h | 22 +
arch/unicore32/include/asm/memblock.h | 46 +
arch/unicore32/include/asm/memory.h | 123 ++
arch/unicore32/include/asm/mmu.h | 17 +
arch/unicore32/include/asm/mmu_context.h | 87 +
arch/unicore32/include/asm/mutex.h | 20 +
arch/unicore32/include/asm/page.h | 80 +
arch/unicore32/include/asm/pci.h | 46 +
arch/unicore32/include/asm/pgalloc.h | 110 ++
arch/unicore32/include/asm/pgtable-hwdef.h | 55 +
arch/unicore32/include/asm/pgtable.h | 317 ++++
arch/unicore32/include/asm/processor.h | 92 ++
arch/unicore32/include/asm/ptrace.h | 176 +++
arch/unicore32/include/asm/sigcontext.h | 29 +
arch/unicore32/include/asm/stacktrace.h | 31 +
arch/unicore32/include/asm/string.h | 38 +
arch/unicore32/include/asm/suspend.h | 30 +
arch/unicore32/include/asm/system.h | 161 ++
arch/unicore32/include/asm/thread_info.h | 154 ++
arch/unicore32/include/asm/timex.h | 34 +
arch/unicore32/include/asm/tlb.h | 98 ++
arch/unicore32/include/asm/tlbflush.h | 195 +++
arch/unicore32/include/asm/traps.h | 21 +
arch/unicore32/include/asm/uaccess.h | 47 +
arch/unicore32/include/asm/unistd.h | 18 +
arch/unicore32/include/mach/PKUnity.h | 104 ++
arch/unicore32/include/mach/bitfield.h | 24 +
arch/unicore32/include/mach/dma.h | 41 +
arch/unicore32/include/mach/hardware.h | 45 +
arch/unicore32/include/mach/map.h | 20 +
arch/unicore32/include/mach/memory.h | 58 +
arch/unicore32/include/mach/ocd.h | 36 +
arch/unicore32/include/mach/pm.h | 43 +
arch/unicore32/include/mach/regs-ac97.h | 32 +
arch/unicore32/include/mach/regs-dmac.h | 81 +
arch/unicore32/include/mach/regs-gpio.h | 70 +
arch/unicore32/include/mach/regs-i2c.h | 63 +
arch/unicore32/include/mach/regs-intc.h | 28 +
arch/unicore32/include/mach/regs-nand.h | 79 +
arch/unicore32/include/mach/regs-ost.h | 92 ++
arch/unicore32/include/mach/regs-pci.h | 94 ++
arch/unicore32/include/mach/regs-pm.h | 126 ++
arch/unicore32/include/mach/regs-ps2.h | 20 +
arch/unicore32/include/mach/regs-resetc.h | 34 +
arch/unicore32/include/mach/regs-rtc.h | 37 +
arch/unicore32/include/mach/regs-sdc.h | 156 ++
arch/unicore32/include/mach/regs-spi.h | 98 ++
arch/unicore32/include/mach/regs-uart.h | 3 +
arch/unicore32/include/mach/regs-umal.h | 229 +++
arch/unicore32/include/mach/regs-unigfx.h | 200 +++
arch/unicore32/include/mach/uncompress.h | 34 +
arch/unicore32/kernel/Makefile | 34 +
arch/unicore32/kernel/asm-offsets.c | 112 ++
arch/unicore32/kernel/clock.c | 388 +++++
arch/unicore32/kernel/cpu-ucv2.c | 93 ++
arch/unicore32/kernel/debug-macro.S | 89 ++
arch/unicore32/kernel/debug.S | 85 +
arch/unicore32/kernel/dma.c | 180 +++
arch/unicore32/kernel/early_printk.c | 59 +
arch/unicore32/kernel/elf.c | 38 +
arch/unicore32/kernel/entry.S | 824 ++++++++++
arch/unicore32/kernel/fpu-ucf64.c | 126 ++
arch/unicore32/kernel/gpio.c | 122 ++
arch/unicore32/kernel/head.S | 252 +++
arch/unicore32/kernel/hibernate.c | 160 ++
arch/unicore32/kernel/hibernate_asm.S | 117 ++
arch/unicore32/kernel/init_task.c | 44 +
arch/unicore32/kernel/irq.c | 426 +++++
arch/unicore32/kernel/ksyms.c | 99 ++
arch/unicore32/kernel/ksyms.h | 15 +
arch/unicore32/kernel/module.c | 152 ++
arch/unicore32/kernel/pci.c | 404 +++++
arch/unicore32/kernel/pm.c | 123 ++
arch/unicore32/kernel/process.c | 389 +++++
arch/unicore32/kernel/ptrace.c | 598 +++++++
arch/unicore32/kernel/puv3-core.c | 260 ++++
arch/unicore32/kernel/puv3-nb0916.c | 175 +++
arch/unicore32/kernel/puv3-smw0919.c | 115 ++
arch/unicore32/kernel/pwm.c | 263 ++++
arch/unicore32/kernel/rtc.c | 380 +++++
arch/unicore32/kernel/setup.c | 360 +++++
arch/unicore32/kernel/setup.h | 30 +
arch/unicore32/kernel/signal.c | 494 ++++++
arch/unicore32/kernel/sleep.S | 202 +++
arch/unicore32/kernel/stacktrace.c | 131 ++
arch/unicore32/kernel/sys.c | 126 ++
arch/unicore32/kernel/time.c | 148 ++
arch/unicore32/kernel/traps.c | 333 ++++
arch/unicore32/kernel/vmlinux.lds.S | 61 +
arch/unicore32/lib/Makefile | 27 +
arch/unicore32/lib/backtrace.S | 163 ++
arch/unicore32/lib/clear_user.S | 57 +
arch/unicore32/lib/copy_from_user.S | 108 ++
arch/unicore32/lib/copy_page.S | 39 +
arch/unicore32/lib/copy_template.S | 214 +++
arch/unicore32/lib/copy_to_user.S | 96 ++
arch/unicore32/lib/delay.S | 51 +
arch/unicore32/lib/findbit.S | 98 ++
arch/unicore32/lib/strncpy_from_user.S | 45 +
arch/unicore32/lib/strnlen_user.S | 42 +
arch/unicore32/mm/Kconfig | 50 +
arch/unicore32/mm/Makefile | 15 +
arch/unicore32/mm/alignment.c | 523 +++++++
arch/unicore32/mm/cache-ucv2.S | 212 +++
arch/unicore32/mm/dma-swiotlb.c | 34 +
arch/unicore32/mm/extable.c | 24 +
arch/unicore32/mm/fault.c | 479 ++++++
arch/unicore32/mm/flush.c | 98 ++
arch/unicore32/mm/init.c | 517 ++++++
arch/unicore32/mm/iomap.c | 56 +
arch/unicore32/mm/ioremap.c | 261 ++++
arch/unicore32/mm/mm.h | 39 +
arch/unicore32/mm/mmu.c | 533 +++++++
arch/unicore32/mm/pgd.c | 102 ++
arch/unicore32/mm/proc-macros.S | 145 ++
arch/unicore32/mm/proc-syms.c | 23 +
arch/unicore32/mm/proc-ucv2.S | 134 ++
arch/unicore32/mm/tlb-ucv2.S | 89 ++
drivers/input/keyboard/Kconfig | 11 +
drivers/input/keyboard/atkbd.c | 4 +
drivers/input/mouse/psmouse-base.c | 41 +
drivers/input/serio/i8042.h | 2 +
drivers/pci/Makefile | 1 +
drivers/staging/puv3/Kconfig | 125 ++
drivers/staging/puv3/Makefile | 22 +
drivers/staging/puv3/TODO | 7 +
drivers/staging/puv3/i8042-ucio.h | 89 ++
drivers/staging/puv3/puv3-atkbd.h | 43 +
drivers/staging/puv3/puv3_ac97.c | 369 +++++
drivers/staging/puv3/puv3_i2c.c | 309 ++++
drivers/staging/puv3/puv3_pcm.c | 435 ++++++
drivers/staging/puv3/puv3_pcm.h | 28 +
drivers/staging/puv3/puv3_umal.c | 2069 +++++++++++++++++++++++++
drivers/staging/puv3/puv3_unifb.c | 965 ++++++++++++
include/asm-generic/ftrace.h | 16 +
include/asm-generic/sizes.h | 47 +
include/asm-generic/uaccess.h | 8 +-
include/linux/fb.h | 2 +
172 files changed, 23554 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH] video: pxa3xx-gcu: Return -EFAULT when copy_from_user()
From: Axel Lin @ 2011-01-14 9:39 UTC (permalink / raw)
To: linux-kernel
Cc: Daniel Mack, Janine Kropp, Denis Oliver Kropp, Eric Miao,
linux-fbdev
Return -EFAULT instead of number of bytes that could not be copied if
copy_from_user() fails.
Also fix a typo in the comments.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
drivers/video/pxa3xx-gcu.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/pxa3xx-gcu.c b/drivers/video/pxa3xx-gcu.c
index b81168d..cf4beb9 100644
--- a/drivers/video/pxa3xx-gcu.c
+++ b/drivers/video/pxa3xx-gcu.c
@@ -1,5 +1,5 @@
/*
- * pxa3xx-gc.c - Linux kernel module for PXA3xx graphics controllers
+ * pxa3xx-gcu.c - Linux kernel module for PXA3xx graphics controllers
*
* This driver needs a DirectFB counterpart in user space, communication
* is handled via mmap()ed memory areas and an ioctl.
@@ -421,7 +421,7 @@ pxa3xx_gcu_misc_write(struct file *filp, const char *buff,
buffer->next = priv->free;
priv->free = buffer;
spin_unlock_irqrestore(&priv->spinlock, flags);
- return ret;
+ return -EFAULT;
}
buffer->length = words;
--
1.7.2
^ permalink raw reply related
* [PATCH] OMAP: DSS2: Fix def_disp module param description
From: Jani Nikula @ 2011-01-13 12:42 UTC (permalink / raw)
To: linux-fbdev
MODULE_PARM_DESC() takes the name of the actual module parameter, not the
name of the variable, as input. Fix the module parameter description for
def_disp.
Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
---
drivers/video/omap2/dss/core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 8e89f60..cad73b1 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -62,7 +62,7 @@ static void dss_clk_disable_no_ctx(enum dss_clock clks);
static char *def_disp_name;
module_param_named(def_disp, def_disp_name, charp, 0);
-MODULE_PARM_DESC(def_disp_name, "default display name");
+MODULE_PARM_DESC(def_disp, "default display name");
#ifdef DEBUG
unsigned int dss_debug;
--
1.7.3.2
^ 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