* Re: [PATCH 5/6] FBDEV: JZ4740: Get rid of enumeration value not handled
From: Lars-Peter Clausen @ 2011-03-01 14:23 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1202f26b58f8dea782600827a158f08b1775953b.1298980528.git.mcuelenaere@gmail.com>
On 03/01/2011 01:06 PM, Maurus Cuelenaere wrote:
> Convert enum jz4740_fb_lcd_type to #define's in order to get rid of these
> warnings.
>
Nack. If it is not handled the code is wrong.
If this is because you only handle SLCD types in some SLCD specific functions add a
default:
BUG();
> Signed-off-by: Maurus Cuelenaere <mcuelenaere@gmail.com>
> ---
> arch/mips/include/asm/mach-jz4740/jz4740_fb.h | 40 ++++++++++++-------------
> 1 files changed, 19 insertions(+), 21 deletions(-)
>
> diff --git a/arch/mips/include/asm/mach-jz4740/jz4740_fb.h b/arch/mips/include/asm/mach-jz4740/jz4740_fb.h
> index eaaac43..d6c11f2 100644
> --- a/arch/mips/include/asm/mach-jz4740/jz4740_fb.h
> +++ b/arch/mips/include/asm/mach-jz4740/jz4740_fb.h
> @@ -17,27 +17,25 @@
>
> #include <linux/fb.h>
>
> -enum jz4740_fb_lcd_type {
> - JZ_LCD_TYPE_GENERIC_16_BIT = 0,
> - JZ_LCD_TYPE_GENERIC_18_BIT = 0 | (1 << 4),
> - JZ_LCD_TYPE_SPECIAL_TFT_1 = 1,
> - JZ_LCD_TYPE_SPECIAL_TFT_2 = 2,
> - JZ_LCD_TYPE_SPECIAL_TFT_3 = 3,
> - JZ_LCD_TYPE_NON_INTERLACED_CCIR656 = 5,
> - JZ_LCD_TYPE_INTERLACED_CCIR656 = 7,
> - JZ_LCD_TYPE_SINGLE_COLOR_STN = 8,
> - JZ_LCD_TYPE_SINGLE_MONOCHROME_STN = 9,
> - JZ_LCD_TYPE_DUAL_COLOR_STN = 10,
> - JZ_LCD_TYPE_DUAL_MONOCHROME_STN = 11,
> - JZ_LCD_TYPE_8BIT_SERIAL = 12,
> +#define JZ_LCD_TYPE_GENERIC_16_BIT (0)
> +#define JZ_LCD_TYPE_GENERIC_18_BIT (0 | (1 << 4))
> +#define JZ_LCD_TYPE_SPECIAL_TFT_1 (1)
> +#define JZ_LCD_TYPE_SPECIAL_TFT_2 (2)
> +#define JZ_LCD_TYPE_SPECIAL_TFT_3 (3)
> +#define JZ_LCD_TYPE_NON_INTERLACED_CCIR656 (5)
> +#define JZ_LCD_TYPE_INTERLACED_CCIR656 (7)
> +#define JZ_LCD_TYPE_SINGLE_COLOR_STN (8)
> +#define JZ_LCD_TYPE_SINGLE_MONOCHROME_STN (9)
> +#define JZ_LCD_TYPE_DUAL_COLOR_STN (10)
> +#define JZ_LCD_TYPE_DUAL_MONOCHROME_STN (11)
> +#define JZ_LCD_TYPE_8BIT_SERIAL (12)
>
> - JZ_SLCD_TYPE_PARALLEL_8_BIT = 1 | (1 << 5),
> - JZ_SLCD_TYPE_PARALLEL_16_BIT = 0 | (1 << 5),
> - JZ_SLCD_TYPE_PARALLEL_18_BIT = 2 | (1 << 5),
> - JZ_SLCD_TYPE_SERIAL_8_BIT = 1 | (3 << 5),
> - JZ_SLCD_TYPE_SERIAL_16_BIT = 0 | (3 << 5),
> - JZ_SLCD_TYPE_SERIAL_18_BIT = 2 | (3 << 5),
> -};
> +#define JZ_SLCD_TYPE_PARALLEL_8_BIT (1 | (1 << 5))
> +#define JZ_SLCD_TYPE_PARALLEL_16_BIT (0 | (1 << 5))
> +#define JZ_SLCD_TYPE_PARALLEL_18_BIT (2 | (1 << 5))
> +#define JZ_SLCD_TYPE_SERIAL_8_BIT (1 | (3 << 5))
> +#define JZ_SLCD_TYPE_SERIAL_16_BIT (0 | (3 << 5))
> +#define JZ_SLCD_TYPE_SERIAL_18_BIT (2 | (3 << 5))
>
> #define JZ4740_FB_SPECIAL_TFT_CONFIG(start, stop) (((start) << 16) | (stop))
>
> @@ -58,7 +56,7 @@ struct jz4740_fb_platform_data {
> struct fb_videomode *modes;
>
> unsigned int bpp;
> - enum jz4740_fb_lcd_type lcd_type;
> + unsigned int lcd_type;
>
> struct {
> uint32_t spl;
Nack
^ permalink raw reply
* Re: [PATCH 1/6] FBDEV: JZ4740: Refactor GPIO pin operations
From: Maurus Cuelenaere @ 2011-03-01 17:18 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <7f854ef86a16dd03f415965b3535c607c401941e.1298980528.git.mcuelenaere@gmail.com>
Op 01-03-11 14:56, Lars-Peter Clausen schreef:
> On 03/01/2011 01:05 PM, Maurus Cuelenaere wrote:
>> Encapsulate all GPIO pins related operations into 1 function which'll make it
>> easier to add on SLCD support.
>>
>> Signed-off-by: Maurus Cuelenaere <mcuelenaere@gmail.com>
>> ---
>> drivers/video/jz4740_fb.c | 82 +++++++++++++++++++++-----------------------
>> 1 files changed, 39 insertions(+), 43 deletions(-)
>>
>> diff --git a/drivers/video/jz4740_fb.c b/drivers/video/jz4740_fb.c
>> index 7e61e68..65741d0 100644
>> --- a/drivers/video/jz4740_fb.c
>> +++ b/drivers/video/jz4740_fb.c
>> @@ -178,59 +178,60 @@ static const struct jz_gpio_bulk_request jz_lcd_data_pins[] = {
>> JZ_GPIO_BULK_PIN(LCD_DATA17),
>> };
>>
>> -static unsigned int jzfb_num_ctrl_pins(struct jzfb *jzfb)
>> +enum jzfb_pin_operation {
>> + REQUEST_PINS,
>> + FREE_PINS,
>> + RESUME_PINS,
>> + SUSPEND_PINS,
>> +};
> Please add a JZFB_ prefix.
Ok.
--
Maurus Cuelenaere
^ permalink raw reply
* Re: [PATCH 2/6] FBDEV: JZ4740: Initialize jzfb->fb earlier
From: Maurus Cuelenaere @ 2011-03-01 17:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <80cfeb81c3b4bae96f8ade317a08566c87493578.1298980528.git.mcuelenaere@gmail.com>
Op 01-03-11 14:58, Lars-Peter Clausen schreef:
> On 03/01/2011 01:05 PM, Maurus Cuelenaere wrote:
>> There's no reason to not do this, and this is needed in the upcoming SLCD
>> support patches.
>>
> Is there any specific reason, why this change can't be done in the patch adding
> SLCD support?
I've done this separately because this isn't strictly SLCD-only and thought it
deserved its own commit.
Will merge this.
--
Maurus Cuelenaere
^ permalink raw reply
* Re: [PATCH 3/6] FBDEV: JZ4740: Initialize framebuffer properly
From: Maurus Cuelenaere @ 2011-03-01 17:21 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1d49e2b9aa2fa143c14a9782fd4e67cb50610ca8.1298980528.git.mcuelenaere@gmail.com>
> On 03/01/2011 01:06 PM, Maurus Cuelenaere wrote:
>> Use the jzfb_enable() function instead of manually faking it in jzfb_probe().
>> Also add the reverse operation when the framebuffer couldn't be registered.
>>
>> Signed-off-by: Maurus Cuelenaere <mcuelenaere@gmail.com>
>> ---
>> drivers/video/jz4740_fb.c | 8 +++-----
>> 1 files changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/jz4740_fb.c b/drivers/video/jz4740_fb.c
>> index cea7b7e..2f3ea57 100644
>> --- a/drivers/video/jz4740_fb.c
>> +++ b/drivers/video/jz4740_fb.c
>> @@ -707,16 +707,13 @@ static int __devinit jzfb_probe(struct platform_device *pdev)
>>
>> fb_alloc_cmap(&fb->cmap, 256, 0);
>>
>> - clk_enable(jzfb->ldclk);
>> - jzfb->is_enabled = 1;
>> -
>> - writel(jzfb->framedesc->next, jzfb->base + JZ_REG_LCD_DA0);
>> -
>> fb->mode = NULL;
>> jzfb_set_par(fb);
>>
>> jzfb_pins_operation(jzfb, REQUEST_PINS);
>>
>> + jzfb_blank(FB_BLANK_UNBLANK, fb);
>> +
> I'd prefer:
> jzfb_enable(jzfb);
> jzfb->is_enabled = 1;
>
> since there is no need for locking here.
>
Ok.
--
Maurus Cuelenaere
^ permalink raw reply
* Re: [RFC/PATCH 4/6] FBDEV: JZ4740: Add Smart LCD controller support
From: Maurus Cuelenaere @ 2011-03-01 17:25 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <56c410783be268e00d09e2c9450e56925bd815a8.1298980528.git.mcuelenaere@gmail.com>
> On 03/01/2011 01:06 PM, Maurus Cuelenaere wrote:
>> This patch adds SLCD support to the Ingenic Jz4740 framebuffer driver.
>> Besides adding the new LCD types to the platform data, this adds chip select
>> and register select active low support (SLCD only). Also, this exports some
>> functions related to starting and stopping the SLCD image transfer and sending
>> commands.
>>
>> A lot of this code was based on work by Maarten ter Huurne:
>> https://github.com/mthuurne/opendingux-kernel/commit/3dba5b5e7a868b1067acae8d1b5a19121b77bc6a
>>
>> Signed-off-by: Maurus Cuelenaere <mcuelenaere@gmail.com>
> Looks mostly good :)
>
>> ---
>> arch/mips/include/asm/mach-jz4740/jz4740_fb.h | 33 ++
>> drivers/video/jz4740_fb.c | 435 ++++++++++++++++++++++---
>> 2 files changed, 429 insertions(+), 39 deletions(-)
>>
>> diff --git a/arch/mips/include/asm/mach-jz4740/jz4740_fb.h b/arch/mips/include/asm/mach-jz4740/jz4740_fb.h
>> index 6a50e6f..eaaac43 100644
>> --- a/arch/mips/include/asm/mach-jz4740/jz4740_fb.h
>> +++ b/arch/mips/include/asm/mach-jz4740/jz4740_fb.h
>> @@ -30,6 +30,13 @@ enum jz4740_fb_lcd_type {
>> JZ_LCD_TYPE_DUAL_COLOR_STN = 10,
>> JZ_LCD_TYPE_DUAL_MONOCHROME_STN = 11,
>> JZ_LCD_TYPE_8BIT_SERIAL = 12,
>> +
>> + JZ_SLCD_TYPE_PARALLEL_8_BIT = 1 | (1 << 5),
>> + JZ_SLCD_TYPE_PARALLEL_16_BIT = 0 | (1 << 5),
>> + JZ_SLCD_TYPE_PARALLEL_18_BIT = 2 | (1 << 5),
>> + JZ_SLCD_TYPE_SERIAL_8_BIT = 1 | (3 << 5),
>> + JZ_SLCD_TYPE_SERIAL_16_BIT = 0 | (3 << 5),
>> + JZ_SLCD_TYPE_SERIAL_18_BIT = 2 | (3 << 5),
> I would prefer
> JZ_LCD_TYPE_SLCD_...
Ok.
>> };
> Maybe add
> #define JZ_LCD_TYPE_SLCD (1 << 5)
> #define JZ_LCD_TYPE_SLCD_SERIAL (JZ_LCD_TYPE_SLCD | (1 << 6))
Ok.
>
>>
>> #define JZ4740_FB_SPECIAL_TFT_CONFIG(start, stop) (((start) << 16) | (stop))
>> @@ -62,6 +69,32 @@ struct jz4740_fb_platform_data {
>>
>> unsigned pixclk_falling_edge:1;
>> unsigned date_enable_active_low:1;
>> + unsigned chip_select_active_low:1;
>> + unsigned register_select_active_low:1;
>> };
>>
>> +struct platform_device;
>> +
>> +/*
>> + * JzFB SLCD related functions
>> + *
>> + * jz4740_fb_slcd_disable_transfer: disables the current image transfer going
>> + * on between memory and the LCD controller
>> + * jz4740_fb_slcd_enable_transfer: the reverse operation of the above
>> + * jz4740_fb_slcd_send_cmd: sends a command without any data to the LCD
>> + * controller
>> + * jz4740_fb_slcd_send_cmd_data: sends a command with a data argument to the LCD
>> + * controller
>> + *
>> + * These functions can sleep and thus should not be called from an atomic
>> + * context. Also, make sure you disable the SLCD image transfer *before* sending
>> + * any commands and do not forget to re-enable it.
>> + */
>> +extern void jz4740_fb_slcd_disable_transfer(struct platform_device *pdev);
>> +extern void jz4740_fb_slcd_enable_transfer(struct platform_device *pdev);
>> +extern void jz4740_fb_slcd_send_cmd_data(struct platform_device *pdev,
>> + unsigned int cmd, unsigned int data);
>> +extern void jz4740_fb_slcd_send_cmd(struct platform_device *pdev,
>> + unsigned int cmd);
>> +
>> #endif
>> diff --git a/drivers/video/jz4740_fb.c b/drivers/video/jz4740_fb.c
>> index 2f3ea57..4064812 100644
>> --- a/drivers/video/jz4740_fb.c
>> +++ b/drivers/video/jz4740_fb.c
>> @@ -26,6 +26,7 @@
>>
>> #include <linux/dma-mapping.h>
>>
>> +#include <asm/mach-jz4740/dma.h>
>> #include <asm/mach-jz4740/jz4740_fb.h>
>> #include <asm/mach-jz4740/gpio.h>
>>
>> @@ -107,6 +108,40 @@
>>
>> #define JZ_LCD_STATE_DISABLED BIT(0)
>>
>> +#define JZ_REG_SLCD_CFG 0xA0
>> +#define JZ_REG_SLCD_CTRL 0xA4
>> +#define JZ_REG_SLCD_STATE 0xA8
>> +#define JZ_REG_SLCD_DATA 0xAC
>> +#define JZ_REG_SLCD_FIFO 0xB0
>> +
>> +#define JZ_SLCD_CFG_BURST_8_WORD BIT(14)
>> +#define JZ_SLCD_CFG_DWIDTH_MASK (7 << 10)
>> +#define JZ_SLCD_CFG_DWIDTH_18 (0 << 10)
>> +#define JZ_SLCD_CFG_DWIDTH_16 (1 << 10)
>> +#define JZ_SLCD_CFG_DWIDTH_8_x3 (2 << 10)
>> +#define JZ_SLCD_CFG_DWIDTH_8_x2 (3 << 10)
>> +#define JZ_SLCD_CFG_DWIDTH_8_x1 (4 << 10)
>> +#define JZ_SLCD_CFG_DWIDTH_9_x2 (7 << 10)
>> +#define JZ_SLCD_CFG_CWIDTH_MASK (3 << 8)
>> +#define JZ_SLCD_CFG_CWIDTH(n) ((n) << 8)
>> +#define JZ_SLCD_CFG_CWIDTH_16BIT (0 << 8)
>> +#define JZ_SLCD_CFG_CWIDTH_8BIT (1 << 8)
>> +#define JZ_SLCD_CFG_CWIDTH_18BIT (2 << 8)
>> +#define JZ_SLCD_CFG_CS_ACTIVE_HIGH BIT(4)
>> +#define JZ_SLCD_CFG_RS_CMD_HIGH BIT(3)
>> +#define JZ_SLCD_CFG_CLK_ACTIVE_RISING BIT(1)
>> +#define JZ_SLCD_CFG_TYPE_SERIAL BIT(0)
>> +
>> +#define JZ_SLCD_CTRL_DMA_EN (1 << 0)
>> +
>> +#define JZ_SLCD_STATE_BUSY (1 << 0)
>> +
>> +#define JZ_SLCD_DATA_RS_DATA (0 << 31)
>> +#define JZ_SLCD_DATA_RS_COMMAND (1 << 31)
>> +
>> +#define JZ_SLCD_FIFO_RS_DATA (0 << 31)
>> +#define JZ_SLCD_FIFO_RS_COMMAND (1 << 31)
>> +
>> struct jzfb_framedesc {
>> uint32_t next;
>> uint32_t addr;
>> @@ -118,6 +153,7 @@ struct jzfb {
>> struct fb_info *fb;
>> struct platform_device *pdev;
>> void __iomem *base;
>> + phys_t phys_base;
>> struct resource *mem;
>> struct jz4740_fb_platform_data *pdata;
>>
>> @@ -126,6 +162,7 @@ struct jzfb {
>> dma_addr_t vidmem_phys;
>> struct jzfb_framedesc *framedesc;
>> dma_addr_t framedesc_phys;
>> + struct jz4740_dma_chan *slcd_dma;
>>
>> struct clk *ldclk;
>> struct clk *lpclk;
>> @@ -136,6 +173,9 @@ struct jzfb {
>> uint32_t pseudo_palette[16];
>> };
>>
>> +#define JZFB_IS_SLCD(jzfb) ((jzfb)->pdata->lcd_type & (1 << 5))
>> +#define JZFB_IS_SLCD_SERIAL_TYPE(jzfb) ((jzfb)->pdata->lcd_type & (2 << 5))
> These two should be static inline bool.
Ok.
>> +static void send_panel_command(struct jzfb *jzfb, u32 cmd)
> You've been using u{16,32} throughout the whole patch, since the existing code
> uses uint_{16,32}t you should stick to them.
Ok, probably a restant from the original opendingux patch.
>> +{
>> + u16 slcd_cfg = readw(jzfb->base + JZ_REG_SLCD_CFG);
>> +
>> + jzfb_slcd_wait(jzfb);
>> +
>> + switch (slcd_cfg & JZ_SLCD_CFG_CWIDTH_MASK) {
>> + case JZ_SLCD_CFG_CWIDTH_8BIT:
>> + writel(JZ_SLCD_DATA_RS_COMMAND | ((cmd & 0xff00) >> 8),
>> + jzfb->base + JZ_REG_SLCD_DATA);
>> + jzfb_slcd_wait(jzfb);
>> + writel(JZ_SLCD_DATA_RS_COMMAND | (cmd & 0xff),
>> + jzfb->base + JZ_REG_SLCD_DATA);
>> + break;
>> +
>> + case JZ_SLCD_CFG_CWIDTH_16BIT:
>> + writel(JZ_SLCD_DATA_RS_COMMAND | (cmd & 0xffff),
>> + jzfb->base + JZ_REG_SLCD_DATA);
>> + break;
>> +
>> + case JZ_SLCD_CFG_CWIDTH_18BIT:
>> + writel(JZ_SLCD_DATA_RS_COMMAND | ((cmd & 0xff00) << 2) |
>> + ((cmd & 0xff) << 1), jzfb->base + JZ_REG_SLCD_DATA);
>> + break;
>> + }
>> +}
>> +
>> +static void send_panel_data(struct jzfb *jzfb, u32 data)
>> +{
>> + u16 slcd_cfg = readw(jzfb->base + JZ_REG_SLCD_CFG);
>> +
>> + switch (slcd_cfg & JZ_SLCD_CFG_DWIDTH_MASK) {
>> + case JZ_SLCD_CFG_DWIDTH_18:
>> + case JZ_SLCD_CFG_DWIDTH_9_x2:
>> + data = ((data & 0xff) << 1) | ((data & 0xff00) << 2);
>> + data = ((data << 6) & 0xfc0000) | ((data << 4) & 0xfc00) |
>> + ((data << 2) & 0x0000fc);
>> + break;
>> +
>> + case JZ_SLCD_CFG_DWIDTH_16:
>> + default:
>> + data &= 0xffff;
>> + break;
>> + }
>> +
>> + jzfb_slcd_wait(jzfb);
>> + writel(JZ_SLCD_DATA_RS_DATA | data, jzfb->base + JZ_REG_SLCD_DATA);
>> +}
>> +
>> +void jz4740_fb_slcd_disable_transfer(struct platform_device *pdev)
>> +{
>> + struct jzfb *jzfb = platform_get_drvdata(pdev);
>> +
>> + mutex_lock(&jzfb->lock);
>> +
>> + if (jzfb->is_enabled) {
>> + jz4740_dma_disable(jzfb->slcd_dma);
>> + jzfb_slcd_wait(jzfb);
>> + }
>> +
>> + mutex_unlock(&jzfb->lock);
>> +}
>> +EXPORT_SYMBOL_GPL(jz4740_fb_slcd_disable_transfer);
>> +
>> +void jz4740_fb_slcd_enable_transfer(struct platform_device *pdev)
>> +{
>> + struct jzfb *jzfb = platform_get_drvdata(pdev);
>> +
>> + mutex_lock(&jzfb->lock);
>> +
>> + if (jzfb->is_enabled)
>> + jzfb_slcd_start_dma(jzfb);
>> +
>> + mutex_unlock(&jzfb->lock);
>> +}
>> +EXPORT_SYMBOL_GPL(jz4740_fb_slcd_enable_transfer);
>> +
>> +void jz4740_fb_slcd_send_cmd_data(struct platform_device *pdev,
>> + unsigned int cmd, unsigned int data)
>> +{
>> + struct jzfb *jzfb = platform_get_drvdata(pdev);
>> +
>> + mutex_lock(&jzfb->lock);
>> +
>> + if (!jzfb->is_enabled)
>> + clk_enable(jzfb->ldclk);
>> +
>> + send_panel_command(jzfb, cmd);
>> + send_panel_data(jzfb, data);
>> +
>> + if (!jzfb->is_enabled) {
>> + jzfb_slcd_wait(jzfb);
>> + clk_disable(jzfb->ldclk);
>> + }
>> +
>> + mutex_unlock(&jzfb->lock);
>> +}
>> +EXPORT_SYMBOL_GPL(jz4740_fb_slcd_send_cmd_data);
>> +
>> +void jz4740_fb_slcd_send_cmd(struct platform_device *pdev, unsigned int cmd)
>> +{
>> + struct jzfb *jzfb = platform_get_drvdata(pdev);
>> +
>> + mutex_lock(&jzfb->lock);
>> +
>> + if (!jzfb->is_enabled)
>> + clk_enable(jzfb->ldclk);
>> +
>> + send_panel_command(jzfb, cmd);
>> +
>> + if (!jzfb->is_enabled) {
>> + jzfb_slcd_wait(jzfb);
>> + clk_disable(jzfb->ldclk);
>> + }
>> +
>> + mutex_unlock(&jzfb->lock);
>> +}
>> +EXPORT_SYMBOL_GPL(jz4740_fb_slcd_send_cmd);
> jz4740_fb_slcd_send_cmd_data and jz4740_fb_slcd_send_cmd are almost identical
> it might makes sense to merge them.
Something like
void jz4740_fb_slcd_send_cmd(struct platform_device *pdev, unsigned int cmd,
unsigned int data, bool with_data);
?
You can't use data = 0 as "do not send data" as this could be a valid parameter.
> I don't like the idea of adding a jzfb specific interface for talking to the
> lcd panels, because it will tightly couple the panel driver to the framebuffer
> driver and it won't be possible to reuse for some board using the same panel
> but a different SoC.
>
Me neither, but the only "good" way forward I see is emulating an SPI interface
over this..
Do you think this is acceptable?
--
Maurus Cuelenaere
^ permalink raw reply
* Re: [PATCH 5/6] FBDEV: JZ4740: Get rid of enumeration value not handled
From: Maurus Cuelenaere @ 2011-03-01 17:26 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1202f26b58f8dea782600827a158f08b1775953b.1298980528.git.mcuelenaere@gmail.com>
> On 03/01/2011 01:06 PM, Maurus Cuelenaere wrote:
>> Convert enum jz4740_fb_lcd_type to #define's in order to get rid of these
>> warnings.
>>
> Nack. If it is not handled the code is wrong.
> If this is because you only handle SLCD types in some SLCD specific functions add a
> default:
> BUG();
Ok, that's also a way to handle it.
>> Signed-off-by: Maurus Cuelenaere <mcuelenaere@gmail.com>
>> ---
>> arch/mips/include/asm/mach-jz4740/jz4740_fb.h | 40 ++++++++++++-------------
>> 1 files changed, 19 insertions(+), 21 deletions(-)
>>
>> diff --git a/arch/mips/include/asm/mach-jz4740/jz4740_fb.h b/arch/mips/include/asm/mach-jz4740/jz4740_fb.h
>> index eaaac43..d6c11f2 100644
>> --- a/arch/mips/include/asm/mach-jz4740/jz4740_fb.h
>> +++ b/arch/mips/include/asm/mach-jz4740/jz4740_fb.h
>> @@ -17,27 +17,25 @@
>>
>> #include <linux/fb.h>
>>
>> -enum jz4740_fb_lcd_type {
>> - JZ_LCD_TYPE_GENERIC_16_BIT = 0,
>> - JZ_LCD_TYPE_GENERIC_18_BIT = 0 | (1 << 4),
>> - JZ_LCD_TYPE_SPECIAL_TFT_1 = 1,
>> - JZ_LCD_TYPE_SPECIAL_TFT_2 = 2,
>> - JZ_LCD_TYPE_SPECIAL_TFT_3 = 3,
>> - JZ_LCD_TYPE_NON_INTERLACED_CCIR656 = 5,
>> - JZ_LCD_TYPE_INTERLACED_CCIR656 = 7,
>> - JZ_LCD_TYPE_SINGLE_COLOR_STN = 8,
>> - JZ_LCD_TYPE_SINGLE_MONOCHROME_STN = 9,
>> - JZ_LCD_TYPE_DUAL_COLOR_STN = 10,
>> - JZ_LCD_TYPE_DUAL_MONOCHROME_STN = 11,
>> - JZ_LCD_TYPE_8BIT_SERIAL = 12,
>> +#define JZ_LCD_TYPE_GENERIC_16_BIT (0)
>> +#define JZ_LCD_TYPE_GENERIC_18_BIT (0 | (1 << 4))
>> +#define JZ_LCD_TYPE_SPECIAL_TFT_1 (1)
>> +#define JZ_LCD_TYPE_SPECIAL_TFT_2 (2)
>> +#define JZ_LCD_TYPE_SPECIAL_TFT_3 (3)
>> +#define JZ_LCD_TYPE_NON_INTERLACED_CCIR656 (5)
>> +#define JZ_LCD_TYPE_INTERLACED_CCIR656 (7)
>> +#define JZ_LCD_TYPE_SINGLE_COLOR_STN (8)
>> +#define JZ_LCD_TYPE_SINGLE_MONOCHROME_STN (9)
>> +#define JZ_LCD_TYPE_DUAL_COLOR_STN (10)
>> +#define JZ_LCD_TYPE_DUAL_MONOCHROME_STN (11)
>> +#define JZ_LCD_TYPE_8BIT_SERIAL (12)
>>
>> - JZ_SLCD_TYPE_PARALLEL_8_BIT = 1 | (1 << 5),
>> - JZ_SLCD_TYPE_PARALLEL_16_BIT = 0 | (1 << 5),
>> - JZ_SLCD_TYPE_PARALLEL_18_BIT = 2 | (1 << 5),
>> - JZ_SLCD_TYPE_SERIAL_8_BIT = 1 | (3 << 5),
>> - JZ_SLCD_TYPE_SERIAL_16_BIT = 0 | (3 << 5),
>> - JZ_SLCD_TYPE_SERIAL_18_BIT = 2 | (3 << 5),
>> -};
>> +#define JZ_SLCD_TYPE_PARALLEL_8_BIT (1 | (1 << 5))
>> +#define JZ_SLCD_TYPE_PARALLEL_16_BIT (0 | (1 << 5))
>> +#define JZ_SLCD_TYPE_PARALLEL_18_BIT (2 | (1 << 5))
>> +#define JZ_SLCD_TYPE_SERIAL_8_BIT (1 | (3 << 5))
>> +#define JZ_SLCD_TYPE_SERIAL_16_BIT (0 | (3 << 5))
>> +#define JZ_SLCD_TYPE_SERIAL_18_BIT (2 | (3 << 5))
>>
>> #define JZ4740_FB_SPECIAL_TFT_CONFIG(start, stop) (((start) << 16) | (stop))
>>
>> @@ -58,7 +56,7 @@ struct jz4740_fb_platform_data {
>> struct fb_videomode *modes;
>>
>> unsigned int bpp;
>> - enum jz4740_fb_lcd_type lcd_type;
>> + unsigned int lcd_type;
>>
>> struct {
>> uint32_t spl;
>
> Nack
Ok.
Thanks for the review!
--
Maurus Cuelenaere
^ permalink raw reply
* matroxfb: remove incorrect Matrox G200eV support
From: Gary Hade @ 2011-03-01 17:50 UTC (permalink / raw)
To: linux-fbdev, linux-kernel
Cc: Darrick J. Wong, Krzysztof Helt, Petr Vandrovec, Andrew Morton,
Linus Torvalds, Gary Hade
From: Gary Hade <garyhade@us.ibm.com>
Remove incorrect Matrox G200eV support that was previously added
by commit e3a1938805d2e81b27d3d348788644f3bad004f2
One serious issue with the G200eV support that I have reproduced
on a Matrox G200eV equipped IBM x3650 M2 is the lack of text (login
banner, login prompt, etc) on the console when X not running and
lack of text on all of the virtual consoles after X is started.
Signed-off-by: Gary Hade <garyhade@us.ibm.com>
Cc: Darrick J. Wong <djwong@us.ibm.com>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
---
drivers/video/matrox/matroxfb_base.c | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/drivers/video/matrox/matroxfb_base.c b/drivers/video/matrox/matroxfb_base.c
index a082deb..a74439a 100644
--- a/drivers/video/matrox/matroxfb_base.c
+++ b/drivers/video/matrox/matroxfb_base.c
@@ -1461,13 +1461,6 @@ static struct board {
MGA_G100,
&vbG100,
"MGA-G100 (AGP)"},
- {PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200EV_PCI, 0xFF,
- 0, 0,
- DEVF_G200,
- 230000,
- MGA_G200,
- &vbG200,
- "MGA-G200eV (PCI)"},
{PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200_PCI, 0xFF,
0, 0,
DEVF_G200,
@@ -2119,8 +2112,6 @@ static struct pci_device_id matroxfb_devices[] = {
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G100_AGP,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200EV_PCI,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200_PCI,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200_AGP,
^ permalink raw reply related
* Re: [RFC/PATCH 4/6] FBDEV: JZ4740: Add Smart LCD controller support
From: Lars-Peter Clausen @ 2011-03-01 18:25 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <56c410783be268e00d09e2c9450e56925bd815a8.1298980528.git.mcuelenaere@gmail.com>
On 03/01/2011 06:25 PM, Maurus Cuelenaere wrote:
>> On 03/01/2011 01:06 PM, Maurus Cuelenaere wrote:
>>> This patch adds SLCD support to the Ingenic Jz4740 framebuffer driver.
>>> Besides adding the new LCD types to the platform data, this adds chip select
>>> and register select active low support (SLCD only). Also, this exports some
>>> functions related to starting and stopping the SLCD image transfer and sending
>>> commands.
>>>
>>> A lot of this code was based on work by Maarten ter Huurne:
>>> https://github.com/mthuurne/opendingux-kernel/commit/3dba5b5e7a868b1067acae8d1b5a19121b77bc6a
>>>
>>> Signed-off-by: Maurus Cuelenaere <mcuelenaere@gmail.com>
>> Looks mostly good :)
>>
>>> ---
>>> arch/mips/include/asm/mach-jz4740/jz4740_fb.h | 33 ++
>>> drivers/video/jz4740_fb.c | 435 ++++++++++++++++++++++---
>>> 2 files changed, 429 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/arch/mips/include/asm/mach-jz4740/jz4740_fb.h b/arch/mips/include/asm/mach-jz4740/jz4740_fb.h
>>> index 6a50e6f..eaaac43 100644
>>> --- a/arch/mips/include/asm/mach-jz4740/jz4740_fb.h
>>> +++ b/arch/mips/include/asm/mach-jz4740/jz4740_fb.h
>>> @@ -30,6 +30,13 @@ enum jz4740_fb_lcd_type {
>>> JZ_LCD_TYPE_DUAL_COLOR_STN = 10,
>>> JZ_LCD_TYPE_DUAL_MONOCHROME_STN = 11,
>>> JZ_LCD_TYPE_8BIT_SERIAL = 12,
>>> +
>>> + JZ_SLCD_TYPE_PARALLEL_8_BIT = 1 | (1 << 5),
>>> + JZ_SLCD_TYPE_PARALLEL_16_BIT = 0 | (1 << 5),
>>> + JZ_SLCD_TYPE_PARALLEL_18_BIT = 2 | (1 << 5),
>>> + JZ_SLCD_TYPE_SERIAL_8_BIT = 1 | (3 << 5),
>>> + JZ_SLCD_TYPE_SERIAL_16_BIT = 0 | (3 << 5),
>>> + JZ_SLCD_TYPE_SERIAL_18_BIT = 2 | (3 << 5),
>> I would prefer
>> JZ_LCD_TYPE_SLCD_...
>
> Ok.
>
>>> };
>> Maybe add
>> #define JZ_LCD_TYPE_SLCD (1 << 5)
>> #define JZ_LCD_TYPE_SLCD_SERIAL (JZ_LCD_TYPE_SLCD | (1 << 6))
>
> Ok.
>
>>
>>>
>>> #define JZ4740_FB_SPECIAL_TFT_CONFIG(start, stop) (((start) << 16) | (stop))
>>> @@ -62,6 +69,32 @@ struct jz4740_fb_platform_data {
>>>
>>> unsigned pixclk_falling_edge:1;
>>> unsigned date_enable_active_low:1;
>>> + unsigned chip_select_active_low:1;
>>> + unsigned register_select_active_low:1;
>>> };
>>>
>>> +struct platform_device;
>>> +
>>> +/*
>>> + * JzFB SLCD related functions
>>> + *
>>> + * jz4740_fb_slcd_disable_transfer: disables the current image transfer going
>>> + * on between memory and the LCD controller
>>> + * jz4740_fb_slcd_enable_transfer: the reverse operation of the above
>>> + * jz4740_fb_slcd_send_cmd: sends a command without any data to the LCD
>>> + * controller
>>> + * jz4740_fb_slcd_send_cmd_data: sends a command with a data argument to the LCD
>>> + * controller
>>> + *
>>> + * These functions can sleep and thus should not be called from an atomic
>>> + * context. Also, make sure you disable the SLCD image transfer *before* sending
>>> + * any commands and do not forget to re-enable it.
>>> + */
>>> +extern void jz4740_fb_slcd_disable_transfer(struct platform_device *pdev);
>>> +extern void jz4740_fb_slcd_enable_transfer(struct platform_device *pdev);
>>> +extern void jz4740_fb_slcd_send_cmd_data(struct platform_device *pdev,
>>> + unsigned int cmd, unsigned int data);
>>> +extern void jz4740_fb_slcd_send_cmd(struct platform_device *pdev,
>>> + unsigned int cmd);
>>> +
>>> #endif
>>> diff --git a/drivers/video/jz4740_fb.c b/drivers/video/jz4740_fb.c
>>> index 2f3ea57..4064812 100644
>>> --- a/drivers/video/jz4740_fb.c
>>> +++ b/drivers/video/jz4740_fb.c
>>> @@ -26,6 +26,7 @@
>>>
>>> #include <linux/dma-mapping.h>
>>>
>>> +#include <asm/mach-jz4740/dma.h>
>>> #include <asm/mach-jz4740/jz4740_fb.h>
>>> #include <asm/mach-jz4740/gpio.h>
>>>
>>> @@ -107,6 +108,40 @@
>>>
>>> #define JZ_LCD_STATE_DISABLED BIT(0)
>>>
>>> +#define JZ_REG_SLCD_CFG 0xA0
>>> +#define JZ_REG_SLCD_CTRL 0xA4
>>> +#define JZ_REG_SLCD_STATE 0xA8
>>> +#define JZ_REG_SLCD_DATA 0xAC
>>> +#define JZ_REG_SLCD_FIFO 0xB0
>>> +
>>> +#define JZ_SLCD_CFG_BURST_8_WORD BIT(14)
>>> +#define JZ_SLCD_CFG_DWIDTH_MASK (7 << 10)
>>> +#define JZ_SLCD_CFG_DWIDTH_18 (0 << 10)
>>> +#define JZ_SLCD_CFG_DWIDTH_16 (1 << 10)
>>> +#define JZ_SLCD_CFG_DWIDTH_8_x3 (2 << 10)
>>> +#define JZ_SLCD_CFG_DWIDTH_8_x2 (3 << 10)
>>> +#define JZ_SLCD_CFG_DWIDTH_8_x1 (4 << 10)
>>> +#define JZ_SLCD_CFG_DWIDTH_9_x2 (7 << 10)
>>> +#define JZ_SLCD_CFG_CWIDTH_MASK (3 << 8)
>>> +#define JZ_SLCD_CFG_CWIDTH(n) ((n) << 8)
>>> +#define JZ_SLCD_CFG_CWIDTH_16BIT (0 << 8)
>>> +#define JZ_SLCD_CFG_CWIDTH_8BIT (1 << 8)
>>> +#define JZ_SLCD_CFG_CWIDTH_18BIT (2 << 8)
>>> +#define JZ_SLCD_CFG_CS_ACTIVE_HIGH BIT(4)
>>> +#define JZ_SLCD_CFG_RS_CMD_HIGH BIT(3)
>>> +#define JZ_SLCD_CFG_CLK_ACTIVE_RISING BIT(1)
>>> +#define JZ_SLCD_CFG_TYPE_SERIAL BIT(0)
>>> +
>>> +#define JZ_SLCD_CTRL_DMA_EN (1 << 0)
>>> +
>>> +#define JZ_SLCD_STATE_BUSY (1 << 0)
>>> +
>>> +#define JZ_SLCD_DATA_RS_DATA (0 << 31)
>>> +#define JZ_SLCD_DATA_RS_COMMAND (1 << 31)
>>> +
>>> +#define JZ_SLCD_FIFO_RS_DATA (0 << 31)
>>> +#define JZ_SLCD_FIFO_RS_COMMAND (1 << 31)
>>> +
>>> struct jzfb_framedesc {
>>> uint32_t next;
>>> uint32_t addr;
>>> @@ -118,6 +153,7 @@ struct jzfb {
>>> struct fb_info *fb;
>>> struct platform_device *pdev;
>>> void __iomem *base;
>>> + phys_t phys_base;
>>> struct resource *mem;
>>> struct jz4740_fb_platform_data *pdata;
>>>
>>> @@ -126,6 +162,7 @@ struct jzfb {
>>> dma_addr_t vidmem_phys;
>>> struct jzfb_framedesc *framedesc;
>>> dma_addr_t framedesc_phys;
>>> + struct jz4740_dma_chan *slcd_dma;
>>>
>>> struct clk *ldclk;
>>> struct clk *lpclk;
>>> @@ -136,6 +173,9 @@ struct jzfb {
>>> uint32_t pseudo_palette[16];
>>> };
>>>
>>> +#define JZFB_IS_SLCD(jzfb) ((jzfb)->pdata->lcd_type & (1 << 5))
>>> +#define JZFB_IS_SLCD_SERIAL_TYPE(jzfb) ((jzfb)->pdata->lcd_type & (2 << 5))
>> These two should be static inline bool.
>
> Ok.
>
>>> +static void send_panel_command(struct jzfb *jzfb, u32 cmd)
>> You've been using u{16,32} throughout the whole patch, since the existing code
>> uses uint_{16,32}t you should stick to them.
>
> Ok, probably a restant from the original opendingux patch.
>
>>> +{
>>> + u16 slcd_cfg = readw(jzfb->base + JZ_REG_SLCD_CFG);
>>> +
>>> + jzfb_slcd_wait(jzfb);
>>> +
>>> + switch (slcd_cfg & JZ_SLCD_CFG_CWIDTH_MASK) {
>>> + case JZ_SLCD_CFG_CWIDTH_8BIT:
>>> + writel(JZ_SLCD_DATA_RS_COMMAND | ((cmd & 0xff00) >> 8),
>>> + jzfb->base + JZ_REG_SLCD_DATA);
>>> + jzfb_slcd_wait(jzfb);
>>> + writel(JZ_SLCD_DATA_RS_COMMAND | (cmd & 0xff),
>>> + jzfb->base + JZ_REG_SLCD_DATA);
>>> + break;
>>> +
>>> + case JZ_SLCD_CFG_CWIDTH_16BIT:
>>> + writel(JZ_SLCD_DATA_RS_COMMAND | (cmd & 0xffff),
>>> + jzfb->base + JZ_REG_SLCD_DATA);
>>> + break;
>>> +
>>> + case JZ_SLCD_CFG_CWIDTH_18BIT:
>>> + writel(JZ_SLCD_DATA_RS_COMMAND | ((cmd & 0xff00) << 2) |
>>> + ((cmd & 0xff) << 1), jzfb->base + JZ_REG_SLCD_DATA);
>>> + break;
>>> + }
>>> +}
>>> +
>>> +static void send_panel_data(struct jzfb *jzfb, u32 data)
>>> +{
>>> + u16 slcd_cfg = readw(jzfb->base + JZ_REG_SLCD_CFG);
>>> +
>>> + switch (slcd_cfg & JZ_SLCD_CFG_DWIDTH_MASK) {
>>> + case JZ_SLCD_CFG_DWIDTH_18:
>>> + case JZ_SLCD_CFG_DWIDTH_9_x2:
>>> + data = ((data & 0xff) << 1) | ((data & 0xff00) << 2);
>>> + data = ((data << 6) & 0xfc0000) | ((data << 4) & 0xfc00) |
>>> + ((data << 2) & 0x0000fc);
>>> + break;
>>> +
>>> + case JZ_SLCD_CFG_DWIDTH_16:
>>> + default:
>>> + data &= 0xffff;
>>> + break;
>>> + }
>>> +
>>> + jzfb_slcd_wait(jzfb);
>>> + writel(JZ_SLCD_DATA_RS_DATA | data, jzfb->base + JZ_REG_SLCD_DATA);
>>> +}
>>> +
>>> +void jz4740_fb_slcd_disable_transfer(struct platform_device *pdev)
>>> +{
>>> + struct jzfb *jzfb = platform_get_drvdata(pdev);
>>> +
>>> + mutex_lock(&jzfb->lock);
>>> +
>>> + if (jzfb->is_enabled) {
>>> + jz4740_dma_disable(jzfb->slcd_dma);
>>> + jzfb_slcd_wait(jzfb);
>>> + }
>>> +
>>> + mutex_unlock(&jzfb->lock);
>>> +}
>>> +EXPORT_SYMBOL_GPL(jz4740_fb_slcd_disable_transfer);
>>> +
>>> +void jz4740_fb_slcd_enable_transfer(struct platform_device *pdev)
>>> +{
>>> + struct jzfb *jzfb = platform_get_drvdata(pdev);
>>> +
>>> + mutex_lock(&jzfb->lock);
>>> +
>>> + if (jzfb->is_enabled)
>>> + jzfb_slcd_start_dma(jzfb);
>>> +
>>> + mutex_unlock(&jzfb->lock);
>>> +}
>>> +EXPORT_SYMBOL_GPL(jz4740_fb_slcd_enable_transfer);
>>> +
>>> +void jz4740_fb_slcd_send_cmd_data(struct platform_device *pdev,
>>> + unsigned int cmd, unsigned int data)
>>> +{
>>> + struct jzfb *jzfb = platform_get_drvdata(pdev);
>>> +
>>> + mutex_lock(&jzfb->lock);
>>> +
>>> + if (!jzfb->is_enabled)
>>> + clk_enable(jzfb->ldclk);
>>> +
>>> + send_panel_command(jzfb, cmd);
>>> + send_panel_data(jzfb, data);
>>> +
>>> + if (!jzfb->is_enabled) {
>>> + jzfb_slcd_wait(jzfb);
>>> + clk_disable(jzfb->ldclk);
>>> + }
>>> +
>>> + mutex_unlock(&jzfb->lock);
>>> +}
>>> +EXPORT_SYMBOL_GPL(jz4740_fb_slcd_send_cmd_data);
>>> +
>>> +void jz4740_fb_slcd_send_cmd(struct platform_device *pdev, unsigned int cmd)
>>> +{
>>> + struct jzfb *jzfb = platform_get_drvdata(pdev);
>>> +
>>> + mutex_lock(&jzfb->lock);
>>> +
>>> + if (!jzfb->is_enabled)
>>> + clk_enable(jzfb->ldclk);
>>> +
>>> + send_panel_command(jzfb, cmd);
>>> +
>>> + if (!jzfb->is_enabled) {
>>> + jzfb_slcd_wait(jzfb);
>>> + clk_disable(jzfb->ldclk);
>>> + }
>>> +
>>> + mutex_unlock(&jzfb->lock);
>>> +}
>>> +EXPORT_SYMBOL_GPL(jz4740_fb_slcd_send_cmd);
>> jz4740_fb_slcd_send_cmd_data and jz4740_fb_slcd_send_cmd are almost identical
>> it might makes sense to merge them.
>
> Something like
> void jz4740_fb_slcd_send_cmd(struct platform_device *pdev, unsigned int cmd,
> unsigned int data, bool with_data);
> ?
>
> You can't use data = 0 as "do not send data" as this could be a valid parameter.
>
>> I don't like the idea of adding a jzfb specific interface for talking to the
>> lcd panels, because it will tightly couple the panel driver to the framebuffer
>> driver and it won't be possible to reuse for some board using the same panel
>> but a different SoC.
>>
I've seen that you are writing quite a few registers at once in the G240400RTSW
driver. So it might makes sense to have a single function which takes an array
of uint32_t, with all these values instead of switching back and forth between
the framebuffer and panel driver.
You could encode whether a certain word is a command or data through the most
upper bit as it is done in the actual register as well.
Something like
void jz4740_fb_slcd_send_cmd(struct device *dev, const uint32_t *data, size_t num)
{
struct jzfb *jzfb = dev_get_drvdata(dev);
uint32_t d;
mutex_lock(&jzfb->lock);
if (!jzfb->is_enabled)
clk_enable(jzfb->ldclk);
for(; num; --num, ++data) {
d = *data;
if (d & JZ_SLCD_DATA_RS_CMD)
d = jz4740_fb_slcd_panel_cmd(d);
else
d = jz4740_fb_slcd_panel_daya(d)
jzfb_slcd_wait(jzfb);
writel(d, jzfb->base + JZ_REG_SLCD_DATA);
}
if (!jzfb->is_enabled) {
jzfb_slcd_wait(jzfb);
clk_disable(jzfb->ldclk);
}
mutex_unlock(&jzfb->lock);
}
>
> Me neither, but the only "good" way forward I see is emulating an SPI interface
> over this..
> Do you think this is acceptable?
>
Since the driver is not actually talking SPI over the bus I don't think this is
an option.
What might be an option is to provide a generic callback structure for the
panel driver.
struct panel_platform_data {
void (*panel_write)(void *data, const uint32_t *data, size_t num);
void *panel_data;
};
So that the panel driver doesn't reference the jzfb driver directly.
- Lars
^ permalink raw reply
* Re: matroxfb: remove incorrect Matrox G200eV support
From: Linus Torvalds @ 2011-03-01 18:29 UTC (permalink / raw)
To: Gary Hade
Cc: linux-fbdev, linux-kernel, Darrick J. Wong, Krzysztof Helt,
Petr Vandrovec, Andrew Morton
In-Reply-To: <20110301175026.GA18770@us.ibm.com>
On Tue, Mar 1, 2011 at 9:50 AM, Gary Hade <garyhade@us.ibm.com> wrote:
>
> Remove incorrect Matrox G200eV support that was previously added
> by commit e3a1938805d2e81b27d3d348788644f3bad004f2
That commit goes back to 2.6.28 (and is dated Oct 2008).
That means that you really need to describe the problem more:
> One serious issue with the G200eV support that I have reproduced
> on a Matrox G200eV equipped IBM x3650 M2 is the lack of text (login
> banner, login prompt, etc) on the console when X not running and
> lack of text on all of the virtual consoles after X is started.
.. but without the commit, you get no fb at all, right? So even with
the commit, at worst you'd just be able to not use the matroxfb
driver, right?
What I'm trying to say is that I suspect there are G200eV users that
likely prefer having the support in - even though it's not perfect.
And the fact that the commit has been there for 2.5 years without
comments makes me very loath to just revert it.
Linus
^ permalink raw reply
* [PATCH] video/tmiofb: silence warnings introduced by mfd changes
From: Andres Salomon @ 2011-03-01 18:53 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Samuel Ortiz, linux-next, linux-kernel, linux-fbdev
In-Reply-To: <20110301154230.df32be17.sfr@canb.auug.org.au>
On Tue, 1 Mar 2011 15:42:30 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Samuel,
>
> After merging the mfd tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
>
> drivers/video/tmiofb.c: In function 'tmiofb_hw_init':
> drivers/video/tmiofb.c:270: warning: initialization discards
> qualifiers from pointer target type drivers/video/tmiofb.c: In
> function 'tmiofb_hw_mode': drivers/video/tmiofb.c:314: warning:
> initialization discards qualifiers from pointer target type
> drivers/video/tmiofb.c:314: warning: unused variable 'cell'
> drivers/video/tmiofb.c: In function 'tmiofb_probe':
> drivers/video/tmiofb.c:683: warning: initialization discards
> qualifiers from pointer target type drivers/video/tmiofb.c: In
> function 'tmiofb_remove': drivers/video/tmiofb.c:811: warning:
> initialization discards qualifiers from pointer target type
> drivers/video/tmiofb.c: In function 'tmiofb_suspend':
> drivers/video/tmiofb.c:941: warning: initialization discards
> qualifiers from pointer target type drivers/video/tmiofb.c: In
> function 'tmiofb_resume': drivers/video/tmiofb.c:973: warning:
> initialization discards qualifiers from pointer target type
>
> Introduced by commits 2a79bb1d72f5ac22dff96de340d90d512f852ecb ("mfd:
> mfd_cell is now implicitly available to tc6393xb drivers") and
> b6361637190e6cb7acb84509499942ada69e7136 ("fb: Use mfd_data instead of
> driver_data for tmio-fb").
>
Oops, this should fix that.
From: Andres Salomon <dilinger@queued.net>
This silences warnings such as
drivers/video/tmiofb.c: In function 'tmiofb_hw_init':
drivers/video/tmiofb.c:270: warning: initialization discards qualifiers from pointer target type
These were added by me in commit 2a79bb1d.
Signed-off-by: Andres Salomon <dilinger@queued.net>
---
drivers/video/tmiofb.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/video/tmiofb.c b/drivers/video/tmiofb.c
index 7e57d3b..9710bf8 100644
--- a/drivers/video/tmiofb.c
+++ b/drivers/video/tmiofb.c
@@ -267,7 +267,7 @@ static int tmiofb_hw_stop(struct platform_device *dev)
*/
static int tmiofb_hw_init(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct fb_info *info = platform_get_drvdata(dev);
struct tmiofb_par *par = info->par;
const struct resource *nlcr = &cell->resources[0];
@@ -311,7 +311,6 @@ static int tmiofb_hw_init(struct platform_device *dev)
*/
static void tmiofb_hw_mode(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
struct tmio_fb_data *data = mfd_get_data(dev);
struct fb_info *info = platform_get_drvdata(dev);
struct fb_videomode *mode = info->mode;
@@ -680,7 +679,7 @@ static struct fb_ops tmiofb_ops = {
static int __devinit tmiofb_probe(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct tmio_fb_data *data = mfd_get_data(dev);
struct resource *ccr = platform_get_resource(dev, IORESOURCE_MEM, 1);
struct resource *lcr = platform_get_resource(dev, IORESOURCE_MEM, 0);
@@ -808,7 +807,7 @@ err_ioremap_ccr:
static int __devexit tmiofb_remove(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct fb_info *info = platform_get_drvdata(dev);
int irq = platform_get_irq(dev, 0);
struct tmiofb_par *par;
@@ -938,7 +937,7 @@ static int tmiofb_suspend(struct platform_device *dev, pm_message_t state)
#ifdef CONFIG_FB_TMIO_ACCELL
struct tmiofb_par *par = info->par;
#endif
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
int retval = 0;
console_lock();
@@ -970,7 +969,7 @@ static int tmiofb_suspend(struct platform_device *dev, pm_message_t state)
static int tmiofb_resume(struct platform_device *dev)
{
struct fb_info *info = platform_get_drvdata(dev);
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
int retval = 0;
console_lock();
--
1.7.2.3
^ permalink raw reply related
* Re: [RFC/PATCH 4/6] FBDEV: JZ4740: Add Smart LCD controller support
From: Maurus Cuelenaere @ 2011-03-01 19:00 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <56c410783be268e00d09e2c9450e56925bd815a8.1298980528.git.mcuelenaere@gmail.com>
> On 03/01/2011 06:25 PM, Maurus Cuelenaere wrote:
>>> On 03/01/2011 01:06 PM, Maurus Cuelenaere wrote:
>>>> This patch adds SLCD support to the Ingenic Jz4740 framebuffer driver.
>>>> Besides adding the new LCD types to the platform data, this adds chip select
>>>> and register select active low support (SLCD only). Also, this exports some
>>>> functions related to starting and stopping the SLCD image transfer and sending
>>>> commands.
<snip>
>>>> +{
>>>> + u16 slcd_cfg = readw(jzfb->base + JZ_REG_SLCD_CFG);
>>>> +
>>>> + jzfb_slcd_wait(jzfb);
>>>> +
>>>> + switch (slcd_cfg & JZ_SLCD_CFG_CWIDTH_MASK) {
>>>> + case JZ_SLCD_CFG_CWIDTH_8BIT:
>>>> + writel(JZ_SLCD_DATA_RS_COMMAND | ((cmd & 0xff00) >> 8),
>>>> + jzfb->base + JZ_REG_SLCD_DATA);
>>>> + jzfb_slcd_wait(jzfb);
>>>> + writel(JZ_SLCD_DATA_RS_COMMAND | (cmd & 0xff),
>>>> + jzfb->base + JZ_REG_SLCD_DATA);
>>>> + break;
>>>> +
>>>> + case JZ_SLCD_CFG_CWIDTH_16BIT:
>>>> + writel(JZ_SLCD_DATA_RS_COMMAND | (cmd & 0xffff),
>>>> + jzfb->base + JZ_REG_SLCD_DATA);
>>>> + break;
>>>> +
>>>> + case JZ_SLCD_CFG_CWIDTH_18BIT:
>>>> + writel(JZ_SLCD_DATA_RS_COMMAND | ((cmd & 0xff00) << 2) |
>>>> + ((cmd & 0xff) << 1), jzfb->base + JZ_REG_SLCD_DATA);
>>>> + break;
>>>> + }
>>>> +}
>>>> +
>>>> +static void send_panel_data(struct jzfb *jzfb, u32 data)
>>>> +{
>>>> + u16 slcd_cfg = readw(jzfb->base + JZ_REG_SLCD_CFG);
>>>> +
>>>> + switch (slcd_cfg & JZ_SLCD_CFG_DWIDTH_MASK) {
>>>> + case JZ_SLCD_CFG_DWIDTH_18:
>>>> + case JZ_SLCD_CFG_DWIDTH_9_x2:
>>>> + data = ((data & 0xff) << 1) | ((data & 0xff00) << 2);
>>>> + data = ((data << 6) & 0xfc0000) | ((data << 4) & 0xfc00) |
>>>> + ((data << 2) & 0x0000fc);
>>>> + break;
>>>> +
>>>> + case JZ_SLCD_CFG_DWIDTH_16:
>>>> + default:
>>>> + data &= 0xffff;
>>>> + break;
>>>> + }
>>>> +
>>>> + jzfb_slcd_wait(jzfb);
>>>> + writel(JZ_SLCD_DATA_RS_DATA | data, jzfb->base + JZ_REG_SLCD_DATA);
>>>> +}
>>>> +
>>>> +void jz4740_fb_slcd_disable_transfer(struct platform_device *pdev)
>>>> +{
>>>> + struct jzfb *jzfb = platform_get_drvdata(pdev);
>>>> +
>>>> + mutex_lock(&jzfb->lock);
>>>> +
>>>> + if (jzfb->is_enabled) {
>>>> + jz4740_dma_disable(jzfb->slcd_dma);
>>>> + jzfb_slcd_wait(jzfb);
>>>> + }
>>>> +
>>>> + mutex_unlock(&jzfb->lock);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(jz4740_fb_slcd_disable_transfer);
>>>> +
>>>> +void jz4740_fb_slcd_enable_transfer(struct platform_device *pdev)
>>>> +{
>>>> + struct jzfb *jzfb = platform_get_drvdata(pdev);
>>>> +
>>>> + mutex_lock(&jzfb->lock);
>>>> +
>>>> + if (jzfb->is_enabled)
>>>> + jzfb_slcd_start_dma(jzfb);
>>>> +
>>>> + mutex_unlock(&jzfb->lock);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(jz4740_fb_slcd_enable_transfer);
>>>> +
>>>> +void jz4740_fb_slcd_send_cmd_data(struct platform_device *pdev,
>>>> + unsigned int cmd, unsigned int data)
>>>> +{
>>>> + struct jzfb *jzfb = platform_get_drvdata(pdev);
>>>> +
>>>> + mutex_lock(&jzfb->lock);
>>>> +
>>>> + if (!jzfb->is_enabled)
>>>> + clk_enable(jzfb->ldclk);
>>>> +
>>>> + send_panel_command(jzfb, cmd);
>>>> + send_panel_data(jzfb, data);
>>>> +
>>>> + if (!jzfb->is_enabled) {
>>>> + jzfb_slcd_wait(jzfb);
>>>> + clk_disable(jzfb->ldclk);
>>>> + }
>>>> +
>>>> + mutex_unlock(&jzfb->lock);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(jz4740_fb_slcd_send_cmd_data);
>>>> +
>>>> +void jz4740_fb_slcd_send_cmd(struct platform_device *pdev, unsigned int cmd)
>>>> +{
>>>> + struct jzfb *jzfb = platform_get_drvdata(pdev);
>>>> +
>>>> + mutex_lock(&jzfb->lock);
>>>> +
>>>> + if (!jzfb->is_enabled)
>>>> + clk_enable(jzfb->ldclk);
>>>> +
>>>> + send_panel_command(jzfb, cmd);
>>>> +
>>>> + if (!jzfb->is_enabled) {
>>>> + jzfb_slcd_wait(jzfb);
>>>> + clk_disable(jzfb->ldclk);
>>>> + }
>>>> +
>>>> + mutex_unlock(&jzfb->lock);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(jz4740_fb_slcd_send_cmd);
>>> jz4740_fb_slcd_send_cmd_data and jz4740_fb_slcd_send_cmd are almost identical
>>> it might makes sense to merge them.
>> Something like
>> void jz4740_fb_slcd_send_cmd(struct platform_device *pdev, unsigned int cmd,
>> unsigned int data, bool with_data);
>> ?
>>
>> You can't use data = 0 as "do not send data" as this could be a valid parameter.
>>
>>> I don't like the idea of adding a jzfb specific interface for talking to the
>>> lcd panels, because it will tightly couple the panel driver to the framebuffer
>>> driver and it won't be possible to reuse for some board using the same panel
>>> but a different SoC.
>>>
> I've seen that you are writing quite a few registers at once in the G240400RTSW
> driver. So it might makes sense to have a single function which takes an array
> of uint32_t, with all these values instead of switching back and forth between
> the framebuffer and panel driver.
> You could encode whether a certain word is a command or data through the most
> upper bit as it is done in the actual register as well.
>
> Something like
> void jz4740_fb_slcd_send_cmd(struct device *dev, const uint32_t *data, size_t num)
> {
> struct jzfb *jzfb = dev_get_drvdata(dev);
> uint32_t d;
>
> mutex_lock(&jzfb->lock);
>
> if (!jzfb->is_enabled)
> clk_enable(jzfb->ldclk);
>
> for(; num; --num, ++data) {
> d = *data;
> if (d & JZ_SLCD_DATA_RS_CMD)
> d = jz4740_fb_slcd_panel_cmd(d);
> else
> d = jz4740_fb_slcd_panel_daya(d)
> jzfb_slcd_wait(jzfb);
> writel(d, jzfb->base + JZ_REG_SLCD_DATA);
> }
>
> if (!jzfb->is_enabled) {
> jzfb_slcd_wait(jzfb);
> clk_disable(jzfb->ldclk);
> }
>
> mutex_unlock(&jzfb->lock);
> }
>
Right, now if this would also do mdelay (e.g. (BIT(30) | 5) means mdelay(5)), I
could do away with jz4740_fb_slcd_{en,dis}able_transfer() :)
That probably shouldn't be done in the framebuffer driver though, so I'll just
stick to something like this:
struct panel_platform_data {
void (*lock)(void *);
void (*unlock)(void *);
void (*write)(const uint32_t *data, size_t num, void *);
void *platform_data;
};
>> Me neither, but the only "good" way forward I see is emulating an SPI interface
>> over this..
>> Do you think this is acceptable?
>>
> Since the driver is not actually talking SPI over the bus I don't think this is
> an option.
> What might be an option is to provide a generic callback structure for the
> panel driver.
>
> struct panel_platform_data {
> void (*panel_write)(void *data, const uint32_t *data, size_t num);
> void *panel_data;
> };
>
> So that the panel driver doesn't reference the jzfb driver directly.
>
>
>
>
Right, but that still doesn't make the LCD panel driver any less tightly coupled
with the Jz4740 SLCD format.
Looking at the Renesas R61509 datasheet, they call this "80-system 8/9/16/18-bit
interface", an x-bit parallel interface with CS, WR, RD and RS (register select).
So SPI doesn't fit the bill, but I can't seem to find any other Linux driver bus
better-suited to do this (apart from creating a new one).
I guess using a generic callback is the best solution, so next patch iteration
will include this unless someone else comes up with something better.
--
Maurus Cuelenaere
^ permalink raw reply
* [PATCH 0/5] s3fb: various changes
From: Ondrej Zary @ 2011-03-01 19:17 UTC (permalink / raw)
To: Ondrej Zajicek; +Cc: linux-fbdev, Kernel development list
This patch set adds new hardware support, fixes some display problems and also
improves performance of s3fb driver.
Everything was tested on various Trio32, Trio64V+, Trio64V2/DX, Virge,
Virge/DX, Trio3D and Trio3D/2X cards.
It assumes that David Miller's "Make SVGA oriented FBs work on multi-domain
PCI" patch set is applied.
Signed-off-by: David S. Miller <davem@davemloft.net>
--
Ondrej Zary
^ permalink raw reply
* [PATCH 1/5] s3fb: maximize virtual vertical size for fast scrolling
From: Ondrej Zary @ 2011-03-01 19:18 UTC (permalink / raw)
To: Ondrej Zajicek; +Cc: linux-fbdev, Kernel development list
Maximize virtual vertical framebuffer size during init to allow fast scrolling
(accelerated by panning).
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.38-rc4-/drivers/video/s3fb.c 2011-02-20 19:11:28.000000000 +0100
+++ linux-2.6.38-rc4/drivers/video/s3fb.c 2011-02-20 19:17:04.000000000 +0100
@@ -1060,6 +1060,14 @@ static int __devinit s3_pci_probe(struct
goto err_find_mode;
}
+ /* maximize virtual vertical size for fast scrolling */
+ info->var.yres_virtual = info->fix.smem_len * 8 /
+ (info->var.bits_per_pixel * info->var.xres_virtual);
+ if (info->var.yres_virtual < info->var.yres) {
+ dev_err(info->device, "virtual vertical size smaller than real\n");
+ goto err_find_mode;
+ }
+
rc = fb_alloc_cmap(&info->cmap, 256, 0);
if (rc < 0) {
dev_err(info->device, "cannot allocate colormap\n");
--
Ondrej Zary
^ permalink raw reply
* [PATCH 2/5] s3fb: add support for 86C365 Trio3D
From: Ondrej Zary @ 2011-03-01 19:18 UTC (permalink / raw)
To: Ondrej Zajicek; +Cc: linux-fbdev, Kernel development list
Add support for S3 Trio3D (86C365) cards to s3fb driver. Tested with one 4MB card.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.38-rc4-/drivers/video/s3fb.c 2011-02-20 20:11:18.000000000 +0100
+++ linux-2.6.38-rc4/drivers/video/s3fb.c 2011-02-20 20:31:34.000000000 +0100
@@ -64,6 +64,8 @@ static const struct svga_fb_format s3fb_
static const struct svga_pll s3_pll = {3, 129, 3, 33, 0, 3,
35000, 240000, 14318};
+static const struct svga_pll s3_trio3d_pll = {3, 129, 3, 31, 0, 4,
+ 230000, 460000, 14318};
static const int s3_memsizes[] = {4096, 0, 3072, 8192, 2048, 6144, 1024, 512};
@@ -72,7 +74,8 @@ static const char * const s3_names[] = {
"S3 Plato/PX", "S3 Aurora64VP", "S3 Virge",
"S3 Virge/VX", "S3 Virge/DX", "S3 Virge/GX",
"S3 Virge/GX2", "S3 Virge/GX2P", "S3 Virge/GX2P",
- "S3 Trio3D/1X", "S3 Trio3D/2X", "S3 Trio3D/2X"};
+ "S3 Trio3D/1X", "S3 Trio3D/2X", "S3 Trio3D/2X",
+ "S3 Trio3D"};
#define CHIP_UNKNOWN 0x00
#define CHIP_732_TRIO32 0x01
@@ -93,6 +96,7 @@ static const char * const s3_names[] = {
#define CHIP_360_TRIO3D_1X 0x10
#define CHIP_362_TRIO3D_2X 0x11
#define CHIP_368_TRIO3D_2X 0x12
+#define CHIP_365_TRIO3D 0x13
#define CHIP_XXX_TRIO 0x80
#define CHIP_XXX_TRIO64V2_DXGX 0x81
@@ -341,7 +345,8 @@ static void s3_set_pixclock(struct fb_in
u8 regval;
int rv;
- rv = svga_compute_pll(&s3_pll, 1000000000 / pixclock, &m, &n, &r, info->node);
+ rv = svga_compute_pll((par->chip = CHIP_365_TRIO3D) ? &s3_trio3d_pll : &s3_pll,
+ 1000000000 / pixclock, &m, &n, &r, info->node);
if (rv < 0) {
printk(KERN_ERR "fb%d: cannot set requested pixclock, keeping old value\n", info->node);
return;
@@ -598,7 +603,8 @@ static int s3fb_set_par(struct fb_info *
if (par->chip = CHIP_360_TRIO3D_1X ||
par->chip = CHIP_362_TRIO3D_2X ||
- par->chip = CHIP_368_TRIO3D_2X) {
+ par->chip = CHIP_368_TRIO3D_2X ||
+ par->chip = CHIP_365_TRIO3D) {
dbytes = info->var.xres * ((bpp+7)/8);
vga_wcrt(par->state.vgabase, 0x91, (dbytes + 7) / 8);
vga_wcrt(par->state.vgabase, 0x90, (((dbytes + 7) / 8) >> 8) | 0x80);
@@ -1012,13 +1018,15 @@ static int __devinit s3_pci_probe(struct
regval = vga_rcrt(par->state.vgabase, 0x36);
if (par->chip = CHIP_360_TRIO3D_1X ||
par->chip = CHIP_362_TRIO3D_2X ||
- par->chip = CHIP_368_TRIO3D_2X) {
+ par->chip = CHIP_368_TRIO3D_2X ||
+ par->chip = CHIP_365_TRIO3D) {
switch ((regval & 0xE0) >> 5) {
case 0: /* 8MB -- only 4MB usable for display */
case 1: /* 4MB with 32-bit bus */
case 2: /* 4MB */
info->screen_size = 4 << 20;
break;
+ case 4: /* 2MB on 365 Trio3D */
case 6: /* 2MB */
info->screen_size = 2 << 20;
break;
@@ -1233,6 +1241,7 @@ static struct pci_device_id s3_devices[]
{PCI_DEVICE(PCI_VENDOR_ID_S3, 0x8A11), .driver_data = CHIP_357_VIRGE_GX2P},
{PCI_DEVICE(PCI_VENDOR_ID_S3, 0x8A12), .driver_data = CHIP_359_VIRGE_GX2P},
{PCI_DEVICE(PCI_VENDOR_ID_S3, 0x8A13), .driver_data = CHIP_36X_TRIO3D_1X_2X},
+ {PCI_DEVICE(PCI_VENDOR_ID_S3, 0x8904), .driver_data = CHIP_365_TRIO3D},
{0, 0, 0, 0, 0, 0, 0}
};
--
Ondrej Zary
^ permalink raw reply
* [PATCH 3/5] s3fb: fix 15/16bpp modes with over 115MHz pixclocks on 86C365 Trio3D
From: Ondrej Zary @ 2011-03-01 19:18 UTC (permalink / raw)
To: Ondrej Zajicek; +Cc: linux-fbdev, Kernel development list
Enable pixel multiplexing in 15/16bpp modes when pixclock is over 115MHz
on Trio3D (86C365) cards to fix artifacts on the left side of screen.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.38-rc4-/drivers/video/s3fb.c 2011-02-20 20:48:41.000000000 +0100
+++ linux-2.6.38-rc4/drivers/video/s3fb.c 2011-02-22 23:31:16.000000000 +0100
@@ -675,6 +675,15 @@
svga_wcrt_mask(par->state.vgabase, 0x67, 0x20, 0xF0);
else
svga_wcrt_mask(par->state.vgabase, 0x67, 0x30, 0xF0);
+ } else if (par->chip = CHIP_365_TRIO3D) {
+ svga_wcrt_mask(par->state.vgabase, 0x50, 0x10, 0x30);
+ if (info->var.pixclock > 8695) {
+ svga_wcrt_mask(par->state.vgabase, 0x67, 0x30, 0xF0);
+ hmul = 2;
+ } else {
+ svga_wcrt_mask(par->state.vgabase, 0x67, 0x20, 0xF0);
+ multiplex = 1;
+ }
} else {
svga_wcrt_mask(par->state.vgabase, 0x50, 0x10, 0x30);
svga_wcrt_mask(par->state.vgabase, 0x67, 0x30, 0xF0);
@@ -691,6 +700,15 @@
svga_wcrt_mask(par->state.vgabase, 0x67, 0x40, 0xF0);
else
svga_wcrt_mask(par->state.vgabase, 0x67, 0x50, 0xF0);
+ } else if (par->chip = CHIP_365_TRIO3D) {
+ svga_wcrt_mask(par->state.vgabase, 0x50, 0x10, 0x30);
+ if (info->var.pixclock > 8695) {
+ svga_wcrt_mask(par->state.vgabase, 0x67, 0x50, 0xF0);
+ hmul = 2;
+ } else {
+ svga_wcrt_mask(par->state.vgabase, 0x67, 0x40, 0xF0);
+ multiplex = 1;
+ }
} else {
svga_wcrt_mask(par->state.vgabase, 0x50, 0x10, 0x30);
svga_wcrt_mask(par->state.vgabase, 0x67, 0x50, 0xF0);
--
Ondrej Zary
^ permalink raw reply
* [PATCH 4/5]: s3fb: enable DTPC
From: Ondrej Zary @ 2011-03-01 19:18 UTC (permalink / raw)
To: Ondrej Zajicek; +Cc: linux-fbdev, Kernel development list
Enable Data Transfer Position Control (DTPC). This is needed at least on
Virge/DX to correctly display at higher pixclocks.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.38-rc4-/drivers/video/s3fb.c 2011-02-28 17:28:27.000000000 +0100
+++ linux-2.6.38-rc4/drivers/video/s3fb.c 2011-02-28 18:53:00.000000000 +0100
@@ -126,6 +126,8 @@
static const struct vga_regset s3_start_address_regs[] = {{0x0d, 0, 7}, {0x0c, 0, 7}, {0x31, 4, 5}, {0x51, 0, 1}, VGA_REGSET_END};
static const struct vga_regset s3_offset_regs[] = {{0x13, 0, 7}, {0x51, 4, 5}, VGA_REGSET_END}; /* set 0x43 bit 2 to 0 */
+static const struct vga_regset s3_dtpc_regs[] = {{0x3B, 0, 7}, {0x5D, 6, 6}, VGA_REGSET_END};
+
static const struct svga_timing_regs s3_timing_regs = {
s3_h_total_regs, s3_h_display_regs, s3_h_blank_start_regs,
s3_h_blank_end_regs, s3_h_sync_start_regs, s3_h_sync_end_regs,
@@ -485,6 +487,7 @@
struct s3fb_info *par = info->par;
u32 value, mode, hmul, offset_value, screen_size, multiplex, dbytes;
u32 bpp = info->var.bits_per_pixel;
+ u32 htotal, hsstart;
if (bpp != 0) {
info->fix.ypanstep = 1;
@@ -604,7 +607,9 @@
if (par->chip = CHIP_360_TRIO3D_1X ||
par->chip = CHIP_362_TRIO3D_2X ||
par->chip = CHIP_368_TRIO3D_2X ||
- par->chip = CHIP_365_TRIO3D) {
+ par->chip = CHIP_365_TRIO3D ||
+ par->chip = CHIP_375_VIRGE_DX ||
+ par->chip = CHIP_385_VIRGE_GX) {
dbytes = info->var.xres * ((bpp+7)/8);
vga_wcrt(par->state.vgabase, 0x91, (dbytes + 7) / 8);
vga_wcrt(par->state.vgabase, 0x90, (((dbytes + 7) / 8) >> 8) | 0x80);
@@ -612,6 +617,16 @@
vga_wcrt(par->state.vgabase, 0x66, 0x81);
}
+ if (par->chip = CHIP_356_VIRGE_GX2 ||
+ par->chip = CHIP_357_VIRGE_GX2P ||
+ par->chip = CHIP_359_VIRGE_GX2P ||
+ par->chip = CHIP_360_TRIO3D_1X ||
+ par->chip = CHIP_362_TRIO3D_2X ||
+ par->chip = CHIP_368_TRIO3D_2X)
+ vga_wcrt(par->state.vgabase, 0x34, 0x00);
+ else /* enable Data Transfer Position Control (DTPC) */
+ vga_wcrt(par->state.vgabase, 0x34, 0x10);
+
svga_wcrt_mask(par->state.vgabase, 0x31, 0x00, 0x40);
multiplex = 0;
hmul = 1;
@@ -745,9 +760,14 @@
hmul, info->node);
/* Set interlaced mode start/end register */
- value = info->var.xres + info->var.left_margin + info->var.right_margin + info->var.hsync_len;
- value = ((value * hmul) / 8) - 5;
- vga_wcrt(par->state.vgabase, 0x3C, (value + 1) / 2);
+ htotal = info->var.xres + info->var.left_margin + info->var.right_margin + info->var.hsync_len;
+ htotal = ((htotal * hmul) / 8) - 5;
+ vga_wcrt(par->state.vgabase, 0x3C, (htotal + 1) / 2);
+
+ /* Set Data Transfer Position */
+ hsstart = ((info->var.xres + info->var.right_margin) * hmul) / 8;
+ value = clamp((htotal + hsstart + 1) / 2, hsstart + 4, htotal + 1);
+ svga_wcrt_multi(par->state.vgabase, s3_dtpc_regs, value);
memset_io(info->screen_base, 0x00, screen_size);
/* Device and screen back on */
--
Ondrej Zary
^ permalink raw reply
* [PATCH 5/5] s3fb: use new start address register
From: Ondrej Zary @ 2011-03-01 19:18 UTC (permalink / raw)
To: Ondrej Zajicek; +Cc: linux-fbdev, Kernel development list
Use "new" start address register 0x69 (bits 16-20) instead of "old" 0x31
(bits 16-17) and 0x51 (bits 18-19). This is needed for panning to work
correctly on Trio3D/2X cards (and does no harm on other ones).
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.38-rc4-/drivers/video/s3fb.c 2011-03-01 18:38:58.000000000 +0100
+++ linux-2.6.38-rc4/drivers/video/s3fb.c 2011-03-01 18:39:35.000000000 +0100
@@ -123,7 +123,7 @@ static const struct vga_regset s3_v_sync
static const struct vga_regset s3_v_sync_end_regs[] = {{0x11, 0, 3}, VGA_REGSET_END};
static const struct vga_regset s3_line_compare_regs[] = {{0x18, 0, 7}, {0x07, 4, 4}, {0x09, 6, 6}, {0x5E, 6, 6}, VGA_REGSET_END};
-static const struct vga_regset s3_start_address_regs[] = {{0x0d, 0, 7}, {0x0c, 0, 7}, {0x31, 4, 5}, {0x51, 0, 1}, VGA_REGSET_END};
+static const struct vga_regset s3_start_address_regs[] = {{0x0d, 0, 7}, {0x0c, 0, 7}, {0x69, 0, 4}, VGA_REGSET_END};
static const struct vga_regset s3_offset_regs[] = {{0x13, 0, 7}, {0x51, 4, 5}, VGA_REGSET_END}; /* set 0x43 bit 2 to 0 */
static const struct vga_regset s3_dtpc_regs[] = {{0x3B, 0, 7}, {0x5D, 6, 6}, VGA_REGSET_END};
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support
From: Geert Uytterhoeven @ 2011-03-01 20:22 UTC (permalink / raw)
To: Magnus Damm
Cc: Damian, Guennadi Liakhovetski, linux-sh, linux-fbdev, taki, matsu,
dri-devel
In-Reply-To: <AANLkTikpL3m_8YVMiRRRULmB_Px9asdK-Fto07WeyJgG@mail.gmail.com>
On Tue, Mar 1, 2011 at 09:25, Magnus Damm <magnus.damm@gmail.com> wrote:
> On Thu, Feb 24, 2011 at 3:05 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Thu, Feb 24, 2011 at 00:28, Magnus Damm <magnus.damm@gmail.com> wrote:
>>> Please ditch the SH_FB_YUV constant all together. No need to build
>>> some abstraction on top of a hackish interface. Just check if nonstd
>>> is non-zero in the driver and assume that means YUV for now. That's
>>> good enough.
>>
>> For YUV (do you mean YCbCr?), I'm inclined to suggest adding a new FB_VISUAL_*
>> type instead, which indicates the fb_var_screeninfo.{red,green,blue} fields are
>> YCbCr instead of RGB.
>> Depending on the frame buffer organization, you also need new FB_TYPE_*/FB_AUX_*
>> types.
>
> I'm all for extending the common code instead of hiding code in
> drivers. But I wonder how much overlap there is with V4L2 for
> instance. I remember adding support for some NVxx formats for V4L2
> some years ago. It's mainly used for Video input on Renesas SoCs
> though:
>
> http://kerneltrap.org/mailarchive/git-commits-head/2008/12/31/4560474
>
> So I was hoping that something like the above could be added to fbdev
> too, but it looks like more code is needed.
>
> Do you have any idea on how to tie in the valid range of each color
> channel? The LCDC hardware block can select between 0->255 range or
> 16->235/240 for the YUV channels. In V4L2 this is handled by
> v4l2_colorspace, the 0->255 maps directly to V4L2_COLORSPACE_JPEG.
Unfortunately not. Unlike for the YCbCr visual, I don't see a field we
can easily
(ab)use for that. Except if it's limited to standard 16-235/240 Y vs.
full 0-255 Y,
for which we could just have 2 different visual types.
> And how does all this relate to KMS? I'd prefer to keep this code in
> one place if possible.
Good question!
I'm still puzzled about this KMS thing. If the name "Kernel Mode Setting"
covers it, then how does it compare to plain fbdev? Just additional frame buffer
memory management?
Furthermore, everybody states that "future X/desktop" will require KMS drivers.
How do/will we handle this on dumb frame buffers? It's not like we can't do
"advanced" things like compositing using the CPU. Transparency may stretch
it a bit on lower end CPUs, but you don't always need that.
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] tmio: silence warnings introduced by mfd changes
From: Andres Salomon @ 2011-03-01 20:32 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Samuel Ortiz, linux-next, linux-kernel, linux-fbdev, linux-usb,
linux-mtd, linux-mmc, Ian Molton, Chris Ball, David Woodhouse,
David Brownell, Greg Kroah-Hartman
In-Reply-To: <20110301105322.48754094@debxo>
On Tue, 1 Mar 2011 10:53:22 -0800
Andres Salomon <dilinger@queued.net> wrote:
> On Tue, 1 Mar 2011 15:42:30 +1100
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi Samuel,
> >
> > After merging the mfd tree, today's linux-next build (x86_64
> > allmodconfig) produced these warnings:
> >
> > drivers/video/tmiofb.c: In function 'tmiofb_hw_init':
> > drivers/video/tmiofb.c:270: warning: initialization discards
> > qualifiers from pointer target type drivers/video/tmiofb.c: In
> > function 'tmiofb_hw_mode': drivers/video/tmiofb.c:314: warning:
> > initialization discards qualifiers from pointer target type
> > drivers/video/tmiofb.c:314: warning: unused variable 'cell'
> > drivers/video/tmiofb.c: In function 'tmiofb_probe':
> > drivers/video/tmiofb.c:683: warning: initialization discards
> > qualifiers from pointer target type drivers/video/tmiofb.c: In
> > function 'tmiofb_remove': drivers/video/tmiofb.c:811: warning:
> > initialization discards qualifiers from pointer target type
> > drivers/video/tmiofb.c: In function 'tmiofb_suspend':
> > drivers/video/tmiofb.c:941: warning: initialization discards
> > qualifiers from pointer target type drivers/video/tmiofb.c: In
> > function 'tmiofb_resume': drivers/video/tmiofb.c:973: warning:
> > initialization discards qualifiers from pointer target type
> >
> > Introduced by commits 2a79bb1d72f5ac22dff96de340d90d512f852ecb
> > ("mfd: mfd_cell is now implicitly available to tc6393xb drivers")
> > and b6361637190e6cb7acb84509499942ada69e7136 ("fb: Use mfd_data
> > instead of driver_data for tmio-fb").
> >
>
> Oops, this should fix that.
>
>
>
Actually, I noticed that I screwed this up for the other tmio drivers
as well. Here's a patch that addresses them all (you can
ignore the previous patch).
From: Andres Salomon <dilinger@queued.net>
This silences warnings such as
drivers/video/tmiofb.c: In function 'tmiofb_hw_init':
drivers/video/tmiofb.c:270: warning: initialization discards qualifiers from pointer target type
These were added by me in commit 2a79bb1d.
Signed-off-by: Andres Salomon <dilinger@queued.net>
moo
Signed-off-by: Andres Salomon <dilinger@queued.net>
---
drivers/mmc/host/tmio_mmc.c | 8 ++++----
drivers/mtd/nand/tmio_nand.c | 8 ++++----
drivers/usb/host/ohci-tmio.c | 8 ++++----
drivers/video/tmiofb.c | 11 +++++------
4 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index 4d34fbd..39918cc 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -1191,7 +1191,7 @@ static const struct mmc_host_ops tmio_mmc_ops = {
#ifdef CONFIG_PM
static int tmio_mmc_suspend(struct platform_device *dev, pm_message_t state)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct mmc_host *mmc = platform_get_drvdata(dev);
int ret;
@@ -1206,7 +1206,7 @@ static int tmio_mmc_suspend(struct platform_device *dev, pm_message_t state)
static int tmio_mmc_resume(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct mmc_host *mmc = platform_get_drvdata(dev);
int ret = 0;
@@ -1229,7 +1229,7 @@ out:
static int __devinit tmio_mmc_probe(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct tmio_mmc_data *pdata;
struct resource *res_ctl;
struct tmio_mmc_host *host;
@@ -1344,7 +1344,7 @@ out:
static int __devexit tmio_mmc_remove(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct mmc_host *mmc = platform_get_drvdata(dev);
platform_set_drvdata(dev, NULL);
diff --git a/drivers/mtd/nand/tmio_nand.c b/drivers/mtd/nand/tmio_nand.c
index 2383b8f..38fb167 100644
--- a/drivers/mtd/nand/tmio_nand.c
+++ b/drivers/mtd/nand/tmio_nand.c
@@ -319,7 +319,7 @@ static int tmio_nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
static int tmio_hw_init(struct platform_device *dev, struct tmio_nand *tmio)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
int ret;
if (cell->enable) {
@@ -363,7 +363,7 @@ static int tmio_hw_init(struct platform_device *dev, struct tmio_nand *tmio)
static void tmio_hw_stop(struct platform_device *dev, struct tmio_nand *tmio)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
tmio_iowrite8(FCR_MODE_POWER_OFF, tmio->fcr + FCR_MODE);
if (cell->disable)
@@ -515,7 +515,7 @@ static int tmio_remove(struct platform_device *dev)
#ifdef CONFIG_PM
static int tmio_suspend(struct platform_device *dev, pm_message_t state)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
if (cell->suspend)
cell->suspend(dev);
@@ -526,7 +526,7 @@ static int tmio_suspend(struct platform_device *dev, pm_message_t state)
static int tmio_resume(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
/* FIXME - is this required or merely another attack of the broken
* SHARP platform? Looks suspicious.
diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c
index eeed164..3558491 100644
--- a/drivers/usb/host/ohci-tmio.c
+++ b/drivers/usb/host/ohci-tmio.c
@@ -185,7 +185,7 @@ static struct platform_driver ohci_hcd_tmio_driver;
static int __devinit ohci_hcd_tmio_drv_probe(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct resource *regs = platform_get_resource(dev, IORESOURCE_MEM, 0);
struct resource *config = platform_get_resource(dev, IORESOURCE_MEM, 1);
struct resource *sram = platform_get_resource(dev, IORESOURCE_MEM, 2);
@@ -274,7 +274,7 @@ static int __devexit ohci_hcd_tmio_drv_remove(struct platform_device *dev)
{
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct tmio_hcd *tmio = hcd_to_tmio(hcd);
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
usb_remove_hcd(hcd);
tmio_stop_hc(dev);
@@ -293,7 +293,7 @@ static int __devexit ohci_hcd_tmio_drv_remove(struct platform_device *dev)
#ifdef CONFIG_PM
static int ohci_hcd_tmio_drv_suspend(struct platform_device *dev, pm_message_t state)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct tmio_hcd *tmio = hcd_to_tmio(hcd);
@@ -326,7 +326,7 @@ static int ohci_hcd_tmio_drv_suspend(struct platform_device *dev, pm_message_t s
static int ohci_hcd_tmio_drv_resume(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct tmio_hcd *tmio = hcd_to_tmio(hcd);
diff --git a/drivers/video/tmiofb.c b/drivers/video/tmiofb.c
index 7e57d3b..9710bf8 100644
--- a/drivers/video/tmiofb.c
+++ b/drivers/video/tmiofb.c
@@ -267,7 +267,7 @@ static int tmiofb_hw_stop(struct platform_device *dev)
*/
static int tmiofb_hw_init(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct fb_info *info = platform_get_drvdata(dev);
struct tmiofb_par *par = info->par;
const struct resource *nlcr = &cell->resources[0];
@@ -311,7 +311,6 @@ static int tmiofb_hw_init(struct platform_device *dev)
*/
static void tmiofb_hw_mode(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
struct tmio_fb_data *data = mfd_get_data(dev);
struct fb_info *info = platform_get_drvdata(dev);
struct fb_videomode *mode = info->mode;
@@ -680,7 +679,7 @@ static struct fb_ops tmiofb_ops = {
static int __devinit tmiofb_probe(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct tmio_fb_data *data = mfd_get_data(dev);
struct resource *ccr = platform_get_resource(dev, IORESOURCE_MEM, 1);
struct resource *lcr = platform_get_resource(dev, IORESOURCE_MEM, 0);
@@ -808,7 +807,7 @@ err_ioremap_ccr:
static int __devexit tmiofb_remove(struct platform_device *dev)
{
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
struct fb_info *info = platform_get_drvdata(dev);
int irq = platform_get_irq(dev, 0);
struct tmiofb_par *par;
@@ -938,7 +937,7 @@ static int tmiofb_suspend(struct platform_device *dev, pm_message_t state)
#ifdef CONFIG_FB_TMIO_ACCELL
struct tmiofb_par *par = info->par;
#endif
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
int retval = 0;
console_lock();
@@ -970,7 +969,7 @@ static int tmiofb_suspend(struct platform_device *dev, pm_message_t state)
static int tmiofb_resume(struct platform_device *dev)
{
struct fb_info *info = platform_get_drvdata(dev);
- struct mfd_cell *cell = mfd_get_cell(dev);
+ const struct mfd_cell *cell = mfd_get_cell(dev);
int retval = 0;
console_lock();
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support
From: Damian @ 2011-03-02 6:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1298456210-26519-2-git-send-email-dhobsong@igel.co.jp>
On 2011/03/01 17:59, Magnus Damm wrote:
> On Thu, Feb 24, 2011 at 12:38 PM, Damian<dhobsong@igel.co.jp> wrote:
>> Ok, I see what you're saying. But if the SH_FB_YUV flag is disappearing, I
>> guess it makes sense to ditch the second patch in this series as well, since
>> that's just further abstraction (albeit locally).
>
> Yep, I think so. Thanks for your help!
Ok, then I will resubmit only the first patch of the series as
[PATCH v2] fbdev: sh_mobile_lcdc: Add YUV input support
Thanks,
Damian
>
> / magnus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Damian Hobson-Garcia
IGEL Co.,Ltd
http://www.igel.co.jp
^ permalink raw reply
* [PATCH v2] fbdev: sh_mobile_lcdc: Add YUV input support
From: Damian @ 2011-03-02 6:42 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1298526433-6621-1-git-send-email-dhobsong@igel.co.jp>
Supports YCbCr420sp, YCbCr422sp, and YCbCr44sp, formats
(bpp = 12, 16, and 24) respectively.
When double-buffering both Y planes appear before the C planes (Y-Y-C-C),
as opposed to Y-C-Y-C.
Set .nonstd in struct sh_mobile_lcdc_chan_cfg to enable YUV mode, and use
.bpp to distiguish between the 3 modes.
The value of .nonstd is copied to bits 16-31 of LDDFR in the LCDC and
should be set accordingly.
.nonstd must be set to 0 for RGB mode.
Due to the encoding of YUV data, the framebuffer will clear to green
instead of black.
In YUV 420 mode, panning is only possible in 2 line increments.
Additionally in YUV 420 mode the vertical resolution of the framebuffer
must be an even number.
Signed-off-by: Damian Hobson-Garcia <dhobsong@igel.co.jp>
---
Changed from v1
* Drop the use of SH_FB_YUV defines everywhere
* Delete the now unnecessary <linux/sh_mobile_fb.h>
* Delete the second patch in the series (now only this patch remains)
drivers/video/sh_mobile_lcdcfb.c | 141
++++++++++++++++++++++++++++++--------
drivers/video/sh_mobile_lcdcfb.h | 2 +-
include/video/sh_mobile_lcdc.h | 1 +
3 files changed, 115 insertions(+), 29 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c
b/drivers/video/sh_mobile_lcdcfb.c
index bf12e53..173973b 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -67,6 +67,7 @@ static unsigned long lcdc_offs_mainlcd[NR_CH_REGS] = {
[LDSM1R] = 0x428,
[LDSM2R] = 0x42c,
[LDSA1R] = 0x430,
+ [LDSA2R] = 0x434,
[LDMLSR] = 0x438,
[LDHCNR] = 0x448,
[LDHSYNR] = 0x44c,
@@ -151,6 +152,7 @@ static bool banked(int reg_nr)
case LDDFR:
case LDSM1R:
case LDSA1R:
+ case LDSA2R:
case LDMLSR:
case LDHCNR:
case LDHSYNR:
@@ -463,6 +465,7 @@ static int sh_mobile_lcdc_start(struct
sh_mobile_lcdc_priv *priv)
struct sh_mobile_lcdc_board_cfg *board_cfg;
unsigned long tmp;
int bpp = 0;
+ unsigned long ldddsr;
int k, m;
int ret = 0;
@@ -541,16 +544,21 @@ static int sh_mobile_lcdc_start(struct
sh_mobile_lcdc_priv *priv)
}
/* word and long word swap */
- switch (bpp) {
- case 16:
- lcdc_write(priv, _LDDDSR, lcdc_read(priv, _LDDDSR) | 6);
- break;
- case 24:
- lcdc_write(priv, _LDDDSR, lcdc_read(priv, _LDDDSR) | 7);
- break;
- case 32:
- lcdc_write(priv, _LDDDSR, lcdc_read(priv, _LDDDSR) | 4);
- break;
+ ldddsr = lcdc_read(priv, _LDDDSR);
+ if (priv->ch[0].info->var.nonstd)
+ lcdc_write(priv, _LDDDSR, ldddsr | 7);
+ else {
+ switch (bpp) {
+ case 16:
+ lcdc_write(priv, _LDDDSR, ldddsr | 6);
+ break;
+ case 24:
+ lcdc_write(priv, _LDDDSR, ldddsr | 7);
+ break;
+ case 32:
+ lcdc_write(priv, _LDDDSR, ldddsr | 4);
+ break;
+ }
}
for (k = 0; k < ARRAY_SIZE(priv->ch); k++) {
@@ -561,21 +569,40 @@ static int sh_mobile_lcdc_start(struct
sh_mobile_lcdc_priv *priv)
/* set bpp format in PKF[4:0] */
tmp = lcdc_read_chan(ch, LDDFR);
- tmp &= ~0x0001001f;
- switch (ch->info->var.bits_per_pixel) {
- case 16:
- tmp |= 0x03;
- break;
- case 24:
- tmp |= 0x0b;
- break;
- case 32:
- break;
+ tmp &= ~0x0003031f;
+ if (ch->info->var.nonstd) {
+ tmp |= (ch->info->var.nonstd << 16);
+ switch (ch->info->var.bits_per_pixel) {
+ case 12:
+ break;
+ case 16:
+ tmp |= (0x1 << 8);
+ break;
+ case 24:
+ tmp |= (0x2 << 8);
+ break;
+ }
+ } else {
+ switch (ch->info->var.bits_per_pixel) {
+ case 16:
+ tmp |= 0x03;
+ break;
+ case 24:
+ tmp |= 0x0b;
+ break;
+ case 32:
+ break;
+ }
}
lcdc_write_chan(ch, LDDFR, tmp);
/* point out our frame buffer */
lcdc_write_chan(ch, LDSA1R, ch->info->fix.smem_start);
+ if (ch->info->var.nonstd)
+ lcdc_write_chan(ch, LDSA2R,
+ ch->info->fix.smem_start +
+ ch->info->var.xres *
+ ch->info->var.yres_virtual);
/* set line size */
lcdc_write_chan(ch, LDMLSR, ch->info->fix.line_length);
@@ -804,9 +831,15 @@ static int sh_mobile_fb_pan_display(struct
fb_var_screeninfo *var,
struct sh_mobile_lcdc_priv *priv = ch->lcdc;
unsigned long ldrcntr;
unsigned long new_pan_offset;
+ unsigned long base_addr_y, base_addr_c;
+ unsigned long c_offset;
- new_pan_offset = (var->yoffset * info->fix.line_length) +
- (var->xoffset * (info->var.bits_per_pixel / 8));
+ if (!var->nonstd)
+ new_pan_offset = (var->yoffset * info->fix.line_length) +
+ (var->xoffset * (info->var.bits_per_pixel / 8));
+ else
+ new_pan_offset = (var->yoffset * info->fix.line_length) +
+ (var->xoffset);
if (new_pan_offset = ch->pan_offset)
return 0; /* No change, do nothing */
@@ -814,7 +847,26 @@ static int sh_mobile_fb_pan_display(struct
fb_var_screeninfo *var,
ldrcntr = lcdc_read(priv, _LDRCNTR);
/* Set the source address for the next refresh */
- lcdc_write_chan_mirror(ch, LDSA1R, ch->dma_handle + new_pan_offset);
+ base_addr_y = ch->dma_handle + new_pan_offset;
+ if (var->nonstd) {
+ /* Set y offset */
+ c_offset = (var->yoffset *
+ info->fix.line_length *
+ (info->var.bits_per_pixel - 8)) / 8;
+ base_addr_c = ch->dma_handle + var->xres * var->yres_virtual +
+ c_offset;
+ /* Set x offset */
+ if (info->var.bits_per_pixel = 24)
+ base_addr_c += 2 * var->xoffset;
+ else
+ base_addr_c += var->xoffset;
+ } else
+ base_addr_c = 0;
+
+ lcdc_write_chan_mirror(ch, LDSA1R, base_addr_y);
+ if (base_addr_c)
+ lcdc_write_chan_mirror(ch, LDSA2R, base_addr_c);
+
if (lcdc_chan_is_sublcd(ch))
lcdc_write(ch->lcdc, _LDRCNTR, ldrcntr ^ LDRCNTR_SRS);
else
@@ -885,7 +937,10 @@ static void sh_mobile_fb_reconfig(struct fb_info *info)
/* Couldn't reconfigure, hopefully, can continue as before */
return;
- info->fix.line_length = mode1.xres * (ch->cfg.bpp / 8);
+ if (info->var.nonstd)
+ info->fix.line_length = mode1.xres;
+ else
+ info->fix.line_length = mode1.xres * (ch->cfg.bpp / 8);
/*
* fb_set_var() calls the notifier change internally, only if
@@ -980,8 +1035,22 @@ static struct fb_ops sh_mobile_lcdc_ops = {
.fb_check_var = sh_mobile_check_var,
};
-static int sh_mobile_lcdc_set_bpp(struct fb_var_screeninfo *var, int bpp)
+static int sh_mobile_lcdc_set_bpp(struct fb_var_screeninfo *var, int bpp,
+ int nonstd)
{
+ if (nonstd) {
+ switch (bpp) {
+ case 12:
+ case 16:
+ case 24:
+ var->bits_per_pixel = bpp;
+ var->nonstd = nonstd;
+ return 0;
+ default:
+ return -EINVAL;
+ }
+ }
+
switch (bpp) {
case 16: /* PKF[4:0] = 00011 - RGB 565 */
var->red.offset = 11;
@@ -1260,6 +1329,14 @@ static int __devinit sh_mobile_lcdc_probe(struct
platform_device *pdev)
k < cfg->num_cfg && lcd_cfg;
k++, lcd_cfg++) {
unsigned long size = lcd_cfg->yres * lcd_cfg->xres;
+ /* NV12 buffers must have even number of lines */
+ if ((cfg->nonstd) && cfg->bpp = 12 &&
+ (lcd_cfg->yres & 0x1)) {
+ dev_err(&pdev->dev, "yres must be multiple of 2"
+ " for YCbCr420 mode.\n");
+ error = -EINVAL;
+ goto err1;
+ }
if (size > max_size) {
max_cfg = lcd_cfg;
@@ -1274,7 +1351,11 @@ static int __devinit sh_mobile_lcdc_probe(struct
platform_device *pdev)
max_cfg->xres, max_cfg->yres);
info->fix = sh_mobile_lcdc_fix;
- info->fix.smem_len = max_size * (cfg->bpp / 8) * 2;
+ info->fix.smem_len = max_size * 2 * cfg->bpp / 8;
+
+ /* Only pan in 2 line steps for NV12 */
+ if (cfg->nonstd && cfg->bpp = 12)
+ info->fix.ypanstep = 2;
if (!mode) {
mode = &default_720p;
@@ -1292,7 +1373,7 @@ static int __devinit sh_mobile_lcdc_probe(struct
platform_device *pdev)
var->yres_virtual = var->yres * 2;
var->activate = FB_ACTIVATE_NOW;
- error = sh_mobile_lcdc_set_bpp(var, cfg->bpp);
+ error = sh_mobile_lcdc_set_bpp(var, cfg->bpp, cfg->nonstd);
if (error)
break;
@@ -1316,7 +1397,11 @@ static int __devinit
sh_mobile_lcdc_probe(struct platform_device *pdev)
}
info->fix.smem_start = ch->dma_handle;
- info->fix.line_length = var->xres * (cfg->bpp / 8);
+ if (var->nonstd)
+ info->fix.line_length = var->xres;
+ else
+ info->fix.line_length = var->xres * (cfg->bpp / 8);
+
info->screen_base = buf;
info->device = &pdev->dev;
ch->display_var = *var;
diff --git a/drivers/video/sh_mobile_lcdcfb.h
b/drivers/video/sh_mobile_lcdcfb.h
index 9ecee2f..c953cb0 100644
--- a/drivers/video/sh_mobile_lcdcfb.h
+++ b/drivers/video/sh_mobile_lcdcfb.h
@@ -8,7 +8,7 @@
/* per-channel registers */
enum { LDDCKPAT1R, LDDCKPAT2R, LDMT1R, LDMT2R, LDMT3R, LDDFR, LDSM1R,
- LDSM2R, LDSA1R, LDMLSR, LDHCNR, LDHSYNR, LDVLNR, LDVSYNR, LDPMR,
+ LDSM2R, LDSA1R, LDSA2R, LDMLSR, LDHCNR, LDHSYNR, LDVLNR,
LDVSYNR, LDPMR,
LDHAJR,
NR_CH_REGS };
diff --git a/include/video/sh_mobile_lcdc.h
b/include/video/sh_mobile_lcdc.h
index daabae5..650ff17 100644
--- a/include/video/sh_mobile_lcdc.h
+++ b/include/video/sh_mobile_lcdc.h
@@ -77,6 +77,7 @@ struct sh_mobile_lcdc_chan_cfg {
struct sh_mobile_lcdc_lcd_size_cfg lcd_size_cfg;
struct sh_mobile_lcdc_board_cfg board_cfg;
struct sh_mobile_lcdc_sys_bus_cfg sys_bus_cfg; /* only for SYSn I/F */
+ int nonstd;
};
struct sh_mobile_lcdc_info {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] omapfb: Fix linker error in
From: Tomi Valkeinen @ 2011-03-02 7:58 UTC (permalink / raw)
To: Jarkko Nikula; +Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
In-Reply-To: <1298968837-13584-1-git-send-email-jhnikula@gmail.com>
On Tue, 2011-03-01 at 02:40 -0600, Jarkko Nikula wrote:
> There is a linker error from lcd_2430sdp.c if CONFIG_TWL4030_CORE is not
> set. This can be triggered on OMAP2 builds when OMAP3 or OMAP4 are not set.
>
> drivers/built-in.o: In function `sdp2430_panel_disable':
> drivers/video/omap/lcd_2430sdp.c:123: undefined reference to `twl_i2c_write_u8'
> drivers/video/omap/lcd_2430sdp.c:124: undefined reference to `twl_i2c_write_u8'
> drivers/built-in.o: In function `sdp2430_panel_enable':
> drivers/video/omap/lcd_2430sdp.c:110: undefined reference to `twl_i2c_write_u8'
> drivers/video/omap/lcd_2430sdp.c:112: undefined reference to `twl_i2c_write_u8'
>
> Fix this by selecting the TWL4030_CORE for MACH_OMAP_2430SDP when building
> with CONFIG_FB_OMAP as there is no own Kconfig entry for lcd_2430 and it is
> compiled always when both MACH_OMAP_2430SDP and FB_OMAP are set.
Thanks, applied.
Tomi
^ permalink raw reply
* Re: [PATCH] tmio: silence warnings introduced by mfd changes
From: Samuel Ortiz @ 2011-03-02 10:34 UTC (permalink / raw)
To: Andres Salomon
Cc: Stephen Rothwell, linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Ian Molton, Chris Ball,
David Woodhouse, David Brownell, Greg Kroah-Hartman
In-Reply-To: <20110301123220.705d3368@debxo>
Hi Andres,
On Tue, Mar 01, 2011 at 12:32:20PM -0800, Andres Salomon wrote:
> On Tue, 1 Mar 2011 10:53:22 -0800
> Andres Salomon <dilinger@queued.net> wrote:
>
> > On Tue, 1 Mar 2011 15:42:30 +1100
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > Hi Samuel,
> > >
> > > After merging the mfd tree, today's linux-next build (x86_64
> > > allmodconfig) produced these warnings:
> > >
> > > drivers/video/tmiofb.c: In function 'tmiofb_hw_init':
> > > drivers/video/tmiofb.c:270: warning: initialization discards
> > > qualifiers from pointer target type drivers/video/tmiofb.c: In
> > > function 'tmiofb_hw_mode': drivers/video/tmiofb.c:314: warning:
> > > initialization discards qualifiers from pointer target type
> > > drivers/video/tmiofb.c:314: warning: unused variable 'cell'
> > > drivers/video/tmiofb.c: In function 'tmiofb_probe':
> > > drivers/video/tmiofb.c:683: warning: initialization discards
> > > qualifiers from pointer target type drivers/video/tmiofb.c: In
> > > function 'tmiofb_remove': drivers/video/tmiofb.c:811: warning:
> > > initialization discards qualifiers from pointer target type
> > > drivers/video/tmiofb.c: In function 'tmiofb_suspend':
> > > drivers/video/tmiofb.c:941: warning: initialization discards
> > > qualifiers from pointer target type drivers/video/tmiofb.c: In
> > > function 'tmiofb_resume': drivers/video/tmiofb.c:973: warning:
> > > initialization discards qualifiers from pointer target type
> > >
> > > Introduced by commits 2a79bb1d72f5ac22dff96de340d90d512f852ecb
> > > ("mfd: mfd_cell is now implicitly available to tc6393xb drivers")
> > > and b6361637190e6cb7acb84509499942ada69e7136 ("fb: Use mfd_data
> > > instead of driver_data for tmio-fb").
> > >
> >
> > Oops, this should fix that.
> >
> >
> >
>
>
> Actually, I noticed that I screwed this up for the other tmio drivers
> as well. Here's a patch that addresses them all (you can
> ignore the previous patch).
Patch applied, thanks for fixing that.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support
From: Alan Cox @ 2011-03-02 11:27 UTC (permalink / raw)
To: Corbin Simpson
Cc: Geert Uytterhoeven, matsu, linux-fbdev, taki, linux-sh,
Magnus Damm, dri-devel, Damian, Guennadi Liakhovetski
In-Reply-To: <AANLkTikFPdZ1ER=Cb59LL2CwBTA2NExSiVaTPzbGsE_o@mail.gmail.com>
On Tue, 1 Mar 2011 13:31:19 -0800
Corbin Simpson <mostawesomedude@gmail.com> wrote:
> I am slightly curious about this as well; I have a device with only YUV
> scanout and was considering KMS, but don't know what the best approach is.
The problem with hiding behind a fake RGB frame buffer is you've then
completely stuffed any framebuffer based apps that could use YUV happily
(eg framebuffer video playback).
Far better to make the kernel tell the truth in these cases. You'll need
to add some tweaks to the fb code for it and a YUV boot penguin.[1]
If you want to run X on it then you can use shadowfb on the X side to do
your YUV/RGB adaptation.
Alan
--
[1] Am I the only one who thinks the fb code also needs an imagine of an
embarassed penguin that has wet itself to go with oops output ?
^ permalink raw reply
* Re: (WARNING) possible deadlock in del_timer_sync, called from
From: Steven Rostedt @ 2011-03-02 18:12 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: linux-fbdev, linux-kernel, Thomas Gleixner
In-Reply-To: <4D6BB403.9000908@ladisch.de>
On Mon, Feb 28, 2011 at 03:41:07PM +0100, Clemens Ladisch wrote:
> While using the FB console, I tried to change the console log level
> with SysRq, and got this warning that del_timer_sync() is used in
> an interrupt handler:
Ug, del_timer_sync() can be called from interrupt context:
printk -> vt_console_print -> hide_cursor -> fbcon_cursor
-> fbcon_del_cursor_time -> del_timer_sync()
printk is allowed to be called from interrupt context. This is indeed a
true bug.
-- Steve
>
> SysRq :
> ------------[ cut here ]------------
> WARNING: at kernel/timer.c:983 del_timer_sync+0x93/0xae()
> Hardware name: System Product Name
> Modules linked in: soundcore firewire_ohci firewire_core ohci_hcd ehci_hcd
> Pid: 0, comm: kworker/0:1 Not tainted 2.6.38-rc6+ #235
> Call Trace:
> <IRQ> [<ffffffff8103a6df>] ? warn_slowpath_common+0x80/0x98
> [<ffffffff8103a70c>] ? warn_slowpath_null+0x15/0x17
> [<ffffffff810452a7>] ? del_timer_sync+0x93/0xae
> [<ffffffff81045214>] ? del_timer_sync+0x0/0xae
> [<ffffffff8120725a>] ? fbcon_del_cursor_timer+0x32/0x3d
> [<ffffffff812077f0>] ? fbcon_cursor+0x9a/0x152
> [<ffffffff8125fd84>] ? hide_cursor+0x2c/0x7d
> [<ffffffff8126022b>] ? vt_console_print+0xd9/0x2f7
> [<ffffffff8103a891>] ? __call_console_drivers+0x67/0x79
> [<ffffffff8103a8fc>] ? _call_console_drivers+0x59/0x5d
> [<ffffffff8103ae3e>] ? console_unlock+0x160/0x1ce
> [<ffffffff8103b44a>] ? vprintk+0x358/0x38e
> [<ffffffff81466199>] ? printk+0x3c/0x3e
> [<ffffffff812594ce>] ? __handle_sysrq+0x23/0x157
> [<ffffffff812594f0>] ? __handle_sysrq+0x45/0x157
> [<ffffffff81259758>] ? sysrq_filter+0x116/0x17b
> [<ffffffff8139b9c5>] ? input_pass_event+0xbe/0x111
> [<ffffffff8139b907>] ? input_pass_event+0x0/0x111
> [<ffffffff8139cfb4>] ? input_handle_event+0x42a/0x439
> [<ffffffff8139d0e9>] ? input_event+0x5b/0x7a
> [<ffffffff813a37f3>] ? atkbd_interrupt+0x50f/0x5e0
> [<ffffffff8139735c>] ? serio_interrupt+0x40/0x7c
> [<ffffffff81398647>] ? i8042_interrupt+0x289/0x2a3
> [<ffffffff8107ae98>] ? handle_IRQ_event+0x20/0xa8
> [<ffffffff8107cd68>] ? handle_edge_irq+0x103/0x14f
> [<ffffffff81004a2b>] ? handle_irq+0x83/0x8c
> [<ffffffff81004067>] ? do_IRQ+0x48/0xaf
> [<ffffffff81469a93>] ? ret_from_intr+0x0/0x13
> <EOI> [<ffffffff8105d49e>] ? tick_broadcast_oneshot_control+0x1a/0xfb
> [<ffffffff810098cc>] ? default_idle+0x27/0x43
> [<ffffffff810098ce>] ? default_idle+0x29/0x43
> [<ffffffff810098cc>] ? default_idle+0x27/0x43
> [<ffffffff81009a33>] ? c1e_idle+0xcd/0xf4
> [<ffffffff810012e5>] ? cpu_idle+0x5f/0x96
> [<ffffffff81462b7c>] ? start_secondary+0x1e3/0x1e5
> ---[ end trace 80565a42945fc993 ]---
> Changing Loglevel
> Loglevel set to 3
>
>
> To add insult to injury, my cursor is configured not to blink.
>
>
> Regards,
> Clemens
> --
> 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
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