linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] radeonfb cannot map FB

[Rui S. <rs...@gr...>]

> x86 bioses only post the primary VGA card.  For secondary cards you'll
> either need to use a driver that can initialize the card itself, or
> use something like vgaarb and vbetool to post the secondary card
> before loading the driver.  If you would prefer to use the radeon
> card, there may be an option in the bios to use the radeon card as the
> primary rather than the integrated card, however, that would probably
> make the integrated card unusable.
>
> Alex
>   
Hi Alex,

    There is no option similar to "Init Display first" on this BIOS.
Howerver both cards must be initialized. I'm trying a radeon kernel
modesetting approach. I'll also pursue vgaarb and vbetool options.
    Thanks a lot for the information ?

Regards,
Rui

>
>
>   

Re: [Linux-fbdev-devel] radeonfb cannot map FB

[Alex D. <ale...@gm...>]

On Thu, Aug 27, 2009 at 7:04 AM, Rui Santos<rs...@gr...> wrote:
> Benjamin Herrenschmidt wrote:
>> On Mon, 2009-08-24 at 20:45 +0100, Rui Santos wrote:
>>
>>> Dear Benjamin Herrenschmidt, dear mailing list subscribers,
>>>
>>>      I'm trying to load radeonfb for an RV100 QY chipset. Whatever I
>>> type in the modprobe I always get:
>>>        radeonfb (0000:01:0c.0): cannot map FB
>>>        radeonfb: probe of 0000:01:0c.0 failed with error -5
>>>
>>
>> I suspect your BIOS isn't initializing the secondary card, radeonfb is
>> thus unable to use it.
>>
>> However, you probably don't need radeonfb. X.org should be able to get
>> it going as a secondary just fine, but your text consoles will have to
>> remain on the intel.
>>
>> In the long run (though it might already work with latest upstream), the
>> new radeon KMS should be able to initialize those.
>>
> Hi Ben, sorry for the late reply ( Motherboard crash),
>
> The system I'm trying to setup is an IBM SurePOS 500. It is supposed to
> work on a FB console (no X) in order to play some Videos :)
> I'm able to use a usb to vga in order to accomplish this but, using the
> integrated Radeon was preferable.
> So, you're saying that it is probably a BIOS related issue, not
> initializing the secondary Video card. Is there anyway I can make sure
> of it? If the BIOS is not initializing it properly, I may be able to
> contact IBM about it.

x86 bioses only post the primary VGA card.  For secondary cards you'll
either need to use a driver that can initialize the card itself, or
use something like vgaarb and vbetool to post the secondary card
before loading the driver.  If you would prefer to use the radeon
card, there may be an option in the bios to use the radeon card as the
primary rather than the integrated card, however, that would probably
make the integrated card unusable.

Alex

Re: [Linux-fbdev-devel] radeonfb cannot map FB

[Rui S. <rs...@gr...>]

Benjamin Herrenschmidt wrote:
> On Mon, 2009-08-24 at 20:45 +0100, Rui Santos wrote:
>   
>> Dear Benjamin Herrenschmidt, dear mailing list subscribers,
>>
>>      I'm trying to load radeonfb for an RV100 QY chipset. Whatever I
>> type in the modprobe I always get:
>>        radeonfb (0000:01:0c.0): cannot map FB
>>        radeonfb: probe of 0000:01:0c.0 failed with error -5
>>     
>
> I suspect your BIOS isn't initializing the secondary card, radeonfb is
> thus unable to use it.
>
> However, you probably don't need radeonfb. X.org should be able to get
> it going as a secondary just fine, but your text consoles will have to
> remain on the intel.
>
> In the long run (though it might already work with latest upstream), the
> new radeon KMS should be able to initialize those.
>   
Hi Ben, sorry for the late reply ( Motherboard crash),

The system I'm trying to setup is an IBM SurePOS 500. It is supposed to
work on a FB console (no X) in order to play some Videos :)
I'm able to use a usb to vga in order to accomplish this but, using the
integrated Radeon was preferable.
So, you're saying that it is probably a BIOS related issue, not
initializing the secondary Video card. Is there anyway I can make sure
of it? If the BIOS is not initializing it properly, I may be able to
contact IBM about it.

Once again, thanks a lot for your help,
> Cheers,
>   
Regards,
> Ben.
>   
Rui

>   
>>     I've tried latest 2.6.27.x and 2.6.30.x kernels. This a secondary
>> video card that I would like to connect a monitor to. The first video
>> card is an Intel 915G, which is working with vesafb.
>>
>>     Here is the output of lspci -vvv
>>     01:0c.0 VGA compatible controller: ATI Technologies Inc Radeon RV100
>> QY [Radeon 7000/VE] (prog-if 00 [VGA controller])
>>             Subsystem: ATI Technologies Inc Device 013b
>>             Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping+ SERR- FastB2B- DisINTx-
>>             Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>>     
>>> TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>       
>>             Interrupt: pin A routed to IRQ 18
>>             Region 0: Memory at d8000000 (32-bit, prefetchable) [size=128M]
>>             Region 1: I/O ports at dc00 [size=256]
>>             Region 2: Memory at fdee0000 (32-bit, non-prefetchable)
>> [size=64K]
>>             [virtual] Expansion ROM at fde00000 [disabled] [size=128K]
>>             Capabilities: [50] Power Management version 2
>>                     Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>                     Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>             Kernel modules: radeonfb
>>
>>     Can you or anyone give a hint on what I might be doing wrong:
>> modprobe radeonfb mode_option=800x600-16 panel_yres=600
>>     Or could this be some kind of hardware issue ?
>>
>>     Thanks a lot for your help,
>>
>> Regards,
>>
>> Rui Santos
>> http://www.ruisantos.com/
>>
>> Veni, vidi, Linux!
>>
>>     
>
>
>
>
>   

Re: [Linux-fbdev-devel] s3c2410fb: fix clockrate calculation

[Ben D. <be...@si...>]

Andrew Morton wrote:
> On Thu, 20 Aug 2009 22:50:47 +0100
> Ben Dooks <be...@si...> wrote:
> 
>> In the final part of the calculation for the tft display clockrate we
>> divide the output pf s3c2410fb_calc_pixclk() by 2 which leaves us with
>> a rounding error if the result is odd.
>>
>> Change to using DIV_ROUND_UP() to ensure that we always choose a higher
>> divisor and thus a lower frequency.
>>
>> Signed-off-by: Ben Dooks <be...@si...>
>>
>> ---
>>  drivers/video/s3c2410fb.c |    4 +++-
>>  2 files changed, 5 insertions(+), 2 deletions(-)
>>  
>> Index: b/drivers/video/s3c2410fb.c
>> ===================================================================
>> --- a/drivers/video/s3c2410fb.c	2009-08-20 08:45:41.000000000 +0100
>> +++ b/drivers/video/s3c2410fb.c	2009-08-20 08:45:42.000000000 +0100
>> @@ -369,7 +369,9 @@ static void s3c2410fb_activate_var(struc
>>  	void __iomem *regs = fbi->io;
>>  	int type = fbi->regs.lcdcon1 & S3C2410_LCDCON1_TFT;
>>  	struct fb_var_screeninfo *var = &info->var;
>> -	int clkdiv = s3c2410fb_calc_pixclk(fbi, var->pixclock) / 2;
>> +	int clkdiv;
>> +
>> +	clkdiv = DIV_ROUND_UP(s3c2410fb_calc_pixclk(fbi, var->pixclock), 2);
>>  
>>  	printk(KERN_INFO "%s: pixclock=%d, clkdiv=%d\n",
>>  	       __func__, var->pixclock, clkdiv);
> 
> The changelog forgot to tell us what the impact of this bug is, so I
> cannot work out whether we need this fix in 2.6.32, 2.6.31, 2.6.30.x, ....

Sorry, found this whilst working on a new machine and the pix clock being
too fast for the display. The machine is not yet merged into the mainline
so this not an important fix.

-- 
Ben Dooks, Software Engineer, Simtec Electronics

http://www.simtec.co.uk/

[Linux-fbdev-devel] [PATCH 3/3] viafb: improve viafb_par

[Florian T. S. <Flo...@gm...>]

viafb: improve viafb_par

This patch introduces viafb_shared and is the beginning of a smooth
transition to use it. viafb_shared should contain all general,
non-surface specific data that should be shared along all viafb
framebuffers while viafb_par should only contain things that are
specific to each surface or in other words extend fb_info. This change
is intended to clean the dual/multi framebuffer handling up.
This removes the annoyance that viafbinfo1->par points to a different
structure than viaparinfo1.
As the last change is fundamental it is difficult to ensure that all
parts of the driver do not depend on the previous brokenness but the
chance of regressions is very low.

Signed-off-by: Florian Tobias Schandinat <Flo...@gm...>
---
 dvi.c      |    6 ++--
 lcd.c      |    6 ++--
 via_i2c.c  |   64 ++++++++++++++++++++++++++++++------------------------------
 viafbdev.c |   35 ++++++++++++--------------------
 viafbdev.h |   19 +++++++++++++++--
 vt1636.c   |    4 +-
 6 files changed, 69 insertions(+), 65 deletions(-)

diff --git a/drivers/video/via/dvi.c b/drivers/video/via/dvi.c
index d696544..c5c32b6 100644
--- a/drivers/video/via/dvi.c
+++ b/drivers/video/via/dvi.c
@@ -160,7 +160,7 @@ int viafb_tmds_trasmitter_identify(void)
 
 static void tmds_register_write(int index, u8 data)
 {
-	viaparinfo->i2c_stuff.i2c_port =
+	viaparinfo->shared->i2c_stuff.i2c_port =
 		viaparinfo->chip_info->tmds_chip_info.i2c_port;
 
 	viafb_i2c_writebyte(viaparinfo->chip_info->tmds_chip_info.
@@ -172,7 +172,7 @@ static int tmds_register_read(int index)
 {
 	u8 data;
 
-	viaparinfo->i2c_stuff.i2c_port =
+	viaparinfo->shared->i2c_stuff.i2c_port =
 		viaparinfo->chip_info->tmds_chip_info.i2c_port;
 	viafb_i2c_readbyte((u8) viaparinfo->chip_info->
 	    tmds_chip_info.tmds_chip_slave_addr,
@@ -182,7 +182,7 @@ static int tmds_register_read(int index)
 
 static int tmds_register_read_bytes(int index, u8 *buff, int buff_len)
 {
-	viaparinfo->i2c_stuff.i2c_port =
+	viaparinfo->shared->i2c_stuff.i2c_port =
 		viaparinfo->chip_info->tmds_chip_info.i2c_port;
 	viafb_i2c_readbytes((u8) viaparinfo->chip_info->tmds_chip_info.
 			 tmds_chip_slave_addr, (u8) index, buff, buff_len);
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 78c6b33..144d34b 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -207,13 +207,13 @@ static bool lvds_identify_integratedlvds(void)
 
 int viafb_lvds_trasmitter_identify(void)
 {
-	viaparinfo->i2c_stuff.i2c_port = I2CPORTINDEX;
+	viaparinfo->shared->i2c_stuff.i2c_port = I2CPORTINDEX;
 	if (viafb_lvds_identify_vt1636()) {
 		viaparinfo->chip_info->lvds_chip_info.i2c_port = I2CPORTINDEX;
 		DEBUG_MSG(KERN_INFO
 			  "Found VIA VT1636 LVDS on port i2c 0x31 \n");
 	} else {
-		viaparinfo->i2c_stuff.i2c_port = GPIOPORTINDEX;
+		viaparinfo->shared->i2c_stuff.i2c_port = GPIOPORTINDEX;
 		if (viafb_lvds_identify_vt1636()) {
 			viaparinfo->chip_info->lvds_chip_info.i2c_port =
 				GPIOPORTINDEX;
@@ -470,7 +470,7 @@ static int lvds_register_read(int index)
 {
 	u8 data;
 
-	viaparinfo->i2c_stuff.i2c_port = GPIOPORTINDEX;
+	viaparinfo->shared->i2c_stuff.i2c_port = GPIOPORTINDEX;
 	viafb_i2c_readbyte((u8) viaparinfo->chip_info->
 	    lvds_chip_info.lvds_chip_slave_addr,
 			(u8) index, &data);
diff --git a/drivers/video/via/via_i2c.c b/drivers/video/via/via_i2c.c
index 0f3ed4e..15543e9 100644
--- a/drivers/video/via/via_i2c.c
+++ b/drivers/video/via/via_i2c.c
@@ -97,7 +97,7 @@ int viafb_i2c_readbyte(u8 slave_addr, u8 index, u8 *pdata)
 	mm1[0] = index;
 	msgs[0].len = 1; msgs[1].len = 1;
 	msgs[0].buf = mm1; msgs[1].buf = pdata;
-	i2c_transfer(&viaparinfo->i2c_stuff.adapter, msgs, 2);
+	i2c_transfer(&viaparinfo->shared->i2c_stuff.adapter, msgs, 2);
 
 	return 0;
 }
@@ -111,7 +111,7 @@ int viafb_i2c_writebyte(u8 slave_addr, u8 index, u8 data)
 	msgs.addr = slave_addr / 2;
 	msgs.len = 2;
 	msgs.buf = msg;
-	return i2c_transfer(&viaparinfo->i2c_stuff.adapter, &msgs, 1);
+	return i2c_transfer(&viaparinfo->shared->i2c_stuff.adapter, &msgs, 1);
 }
 
 int viafb_i2c_readbytes(u8 slave_addr, u8 index, u8 *buff, int buff_len)
@@ -125,53 +125,53 @@ int viafb_i2c_readbytes(u8 slave_addr, u8 index, u8 *buff, int buff_len)
 	mm1[0] = index;
 	msgs[0].len = 1; msgs[1].len = buff_len;
 	msgs[0].buf = mm1; msgs[1].buf = buff;
-	i2c_transfer(&viaparinfo->i2c_stuff.adapter, msgs, 2);
+	i2c_transfer(&viaparinfo->shared->i2c_stuff.adapter, msgs, 2);
 	return 0;
 }
 
 int viafb_create_i2c_bus(void *viapar)
 {
 	int ret;
-	struct viafb_par *par = (struct viafb_par *)viapar;
-
-	strcpy(par->i2c_stuff.adapter.name, "via_i2c");
-	par->i2c_stuff.i2c_port = 0x0;
-	par->i2c_stuff.adapter.owner = THIS_MODULE;
-	par->i2c_stuff.adapter.id = 0x01FFFF;
-	par->i2c_stuff.adapter.class = 0;
-	par->i2c_stuff.adapter.algo_data = &par->i2c_stuff.algo;
-	par->i2c_stuff.adapter.dev.parent = NULL;
-	par->i2c_stuff.algo.setsda = via_i2c_setsda;
-	par->i2c_stuff.algo.setscl = via_i2c_setscl;
-	par->i2c_stuff.algo.getsda = via_i2c_getsda;
-	par->i2c_stuff.algo.getscl = via_i2c_getscl;
-	par->i2c_stuff.algo.udelay = 40;
-	par->i2c_stuff.algo.timeout = 20;
-	par->i2c_stuff.algo.data = &par->i2c_stuff;
-
-	i2c_set_adapdata(&par->i2c_stuff.adapter, &par->i2c_stuff);
+	struct via_i2c_stuff *i2c_stuff =
+		&((struct viafb_par *)viapar)->shared->i2c_stuff;
+
+	strcpy(i2c_stuff->adapter.name, "via_i2c");
+	i2c_stuff->i2c_port = 0x0;
+	i2c_stuff->adapter.owner = THIS_MODULE;
+	i2c_stuff->adapter.id = 0x01FFFF;
+	i2c_stuff->adapter.class = 0;
+	i2c_stuff->adapter.algo_data = &i2c_stuff->algo;
+	i2c_stuff->adapter.dev.parent = NULL;
+	i2c_stuff->algo.setsda = via_i2c_setsda;
+	i2c_stuff->algo.setscl = via_i2c_setscl;
+	i2c_stuff->algo.getsda = via_i2c_getsda;
+	i2c_stuff->algo.getscl = via_i2c_getscl;
+	i2c_stuff->algo.udelay = 40;
+	i2c_stuff->algo.timeout = 20;
+	i2c_stuff->algo.data = i2c_stuff;
+
+	i2c_set_adapdata(&i2c_stuff->adapter, i2c_stuff);
 
 	/* Raise SCL and SDA */
-	par->i2c_stuff.i2c_port = I2CPORTINDEX;
-	via_i2c_setsda(&par->i2c_stuff, 1);
-	via_i2c_setscl(&par->i2c_stuff, 1);
+	i2c_stuff->i2c_port = I2CPORTINDEX;
+	via_i2c_setsda(i2c_stuff, 1);
+	via_i2c_setscl(i2c_stuff, 1);
 
-	par->i2c_stuff.i2c_port = GPIOPORTINDEX;
-	via_i2c_setsda(&par->i2c_stuff, 1);
-	via_i2c_setscl(&par->i2c_stuff, 1);
+	i2c_stuff->i2c_port = GPIOPORTINDEX;
+	via_i2c_setsda(i2c_stuff, 1);
+	via_i2c_setscl(i2c_stuff, 1);
 	udelay(20);
 
-	ret = i2c_bit_add_bus(&par->i2c_stuff.adapter);
+	ret = i2c_bit_add_bus(&i2c_stuff->adapter);
 	if (ret == 0)
-		DEBUG_MSG("I2C bus %s registered.\n",
-		par->i2c_stuff.adapter.name);
+		DEBUG_MSG("I2C bus %s registered.\n", i2c_stuff->adapter.name);
 	else
 		DEBUG_MSG("Failed to register I2C bus %s.\n",
-			par->i2c_stuff.adapter.name);
+			i2c_stuff->adapter.name);
 	return ret;
 }
 
 void viafb_delete_i2c_buss(void *par)
 {
-	i2c_del_adapter(&((struct viafb_par *)par)->i2c_stuff.adapter);
+	i2c_del_adapter(&((struct viafb_par *)par)->shared->i2c_stuff.adapter);
 }
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index a17e138..4a8853a 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -1943,40 +1943,30 @@ static int __devinit via_pci_probe(void)
 	char *tmpc, *tmpm;
 	char *tmpc_sec, *tmpm_sec;
 	int vmode_index;
-	u32 tmds_length, lvds_length, crt_length, chip_length, viafb_par_length;
+	u32 viafb_par_length;
 
 	DEBUG_MSG(KERN_INFO "VIAFB PCI Probe!!\n");
 
 	viafb_par_length = ALIGN(sizeof(struct viafb_par), BITS_PER_LONG/8);
-	tmds_length = ALIGN(sizeof(struct tmds_setting_information),
-		BITS_PER_LONG/8);
-	lvds_length = ALIGN(sizeof(struct lvds_setting_information),
-		BITS_PER_LONG/8);
-	crt_length = ALIGN(sizeof(struct lvds_setting_information),
-		BITS_PER_LONG/8);
-	chip_length = ALIGN(sizeof(struct chip_information), BITS_PER_LONG/8);
 
 	/* Allocate fb_info and ***_par here, also including some other needed
 	 * variables
 	*/
-	viafbinfo = framebuffer_alloc(viafb_par_length + 2 * lvds_length +
-	tmds_length + crt_length + chip_length, NULL);
+	viafbinfo = framebuffer_alloc(viafb_par_length +
+		ALIGN(sizeof(struct viafb_shared), BITS_PER_LONG/8), NULL);
 	if (!viafbinfo) {
 		printk(KERN_ERR"Could not allocate memory for viafb_info.\n");
 		return -ENODEV;
 	}
 
 	viaparinfo = (struct viafb_par *)viafbinfo->par;
-	viaparinfo->tmds_setting_info = (struct tmds_setting_information *)
-		((unsigned long)viaparinfo + viafb_par_length);
-	viaparinfo->lvds_setting_info = (struct lvds_setting_information *)
-		((unsigned long)viaparinfo->tmds_setting_info + tmds_length);
-	viaparinfo->lvds_setting_info2 = (struct lvds_setting_information *)
-		((unsigned long)viaparinfo->lvds_setting_info + lvds_length);
-	viaparinfo->crt_setting_info = (struct crt_setting_information *)
-		((unsigned long)viaparinfo->lvds_setting_info2 + lvds_length);
-	viaparinfo->chip_info = (struct chip_information *)
-		((unsigned long)viaparinfo->crt_setting_info + crt_length);
+	viaparinfo->shared = viafbinfo->par + viafb_par_length;
+	viaparinfo->tmds_setting_info = &viaparinfo->shared->tmds_setting_info;
+	viaparinfo->lvds_setting_info = &viaparinfo->shared->lvds_setting_info;
+	viaparinfo->lvds_setting_info2 =
+		&viaparinfo->shared->lvds_setting_info2;
+	viaparinfo->crt_setting_info = &viaparinfo->shared->crt_setting_info;
+	viaparinfo->chip_info = &viaparinfo->shared->chip_info;
 
 	if (viafb_dual_fb)
 		viafb_SAMM_ON = 1;
@@ -2142,6 +2132,7 @@ static int __devinit via_pci_probe(void)
 		viaparinfo->iga_path = IGA1;
 		viaparinfo1->iga_path = IGA2;
 		memcpy(viafbinfo1, viafbinfo, sizeof(struct fb_info));
+		viafbinfo1->par = viaparinfo1;
 		viafbinfo1->screen_base = viafbinfo->screen_base +
 			viafb_second_offset;
 
@@ -2193,7 +2184,7 @@ static int __devinit via_pci_probe(void)
 		  viafbinfo->node, viafbinfo->fix.id, default_var.xres,
 		  default_var.yres, default_var.bits_per_pixel);
 
-	viafb_init_proc(&viaparinfo->proc_entry);
+	viafb_init_proc(&viaparinfo->shared->proc_entry);
 	viafb_init_dac(IGA2);
 	return 0;
 }
@@ -2214,7 +2205,7 @@ static void __devexit via_pci_remove(void)
 	if (viafb_dual_fb)
 		framebuffer_release(viafbinfo1);
 
-	viafb_remove_proc(viaparinfo->proc_entry);
+	viafb_remove_proc(viaparinfo->shared->proc_entry);
 }
 
 #ifndef MODULE
diff --git a/drivers/video/via/viafbdev.h b/drivers/video/via/viafbdev.h
index 2763922..1d1fe35 100644
--- a/drivers/video/via/viafbdev.h
+++ b/drivers/video/via/viafbdev.h
@@ -37,6 +37,20 @@
 #define VERSION_OS          0	/* 0: for 32 bits OS, 1: for 64 bits OS */
 #define VERSION_MINOR       4
 
+struct viafb_shared {
+	struct proc_dir_entry *proc_entry;	/*viafb proc entry */
+
+	/* I2C stuff */
+	struct via_i2c_stuff i2c_stuff;
+
+	/* All the information will be needed to set engine */
+	struct tmds_setting_information tmds_setting_info;
+	struct crt_setting_information crt_setting_info;
+	struct lvds_setting_information lvds_setting_info;
+	struct lvds_setting_information lvds_setting_info2;
+	struct chip_information chip_info;
+};
+
 struct viafb_par {
 	void __iomem *io_virt;	/*iospace virtual memory address */
 	unsigned int fbmem;	/*framebuffer physical memory address */
@@ -47,12 +61,11 @@ struct viafb_par {
 	u32 VQ_start;		/* Virtual Queue Start Address */
 	u32 VQ_end;		/* Virtual Queue End Address */
 	u32 iga_path;
-	struct proc_dir_entry *proc_entry;	/*viafb proc entry */
 
-	/* I2C stuff */
-	struct via_i2c_stuff i2c_stuff;
+	struct viafb_shared *shared;
 
 	/* All the information will be needed to set engine */
+	/* depreciated, use the ones in shared directly */
 	struct tmds_setting_information *tmds_setting_info;
 	struct crt_setting_information *crt_setting_info;
 	struct lvds_setting_information *lvds_setting_info;
diff --git a/drivers/video/via/vt1636.c b/drivers/video/via/vt1636.c
index 322a9f9..a6b3749 100644
--- a/drivers/video/via/vt1636.c
+++ b/drivers/video/via/vt1636.c
@@ -27,7 +27,7 @@ u8 viafb_gpio_i2c_read_lvds(struct lvds_setting_information
 {
 	u8 data;
 
-	viaparinfo->i2c_stuff.i2c_port = plvds_chip_info->i2c_port;
+	viaparinfo->shared->i2c_stuff.i2c_port = plvds_chip_info->i2c_port;
 	viafb_i2c_readbyte(plvds_chip_info->lvds_chip_slave_addr, index, &data);
 
 	return data;
@@ -39,7 +39,7 @@ void viafb_gpio_i2c_write_mask_lvds(struct lvds_setting_information
 {
 	int index, data;
 
-	viaparinfo->i2c_stuff.i2c_port = plvds_chip_info->i2c_port;
+	viaparinfo->shared->i2c_stuff.i2c_port = plvds_chip_info->i2c_port;
 
 	index = io_data.Index;
 	data = viafb_gpio_i2c_read_lvds(plvds_setting_info, plvds_chip_info,
-- 
1.6.3.2

[Linux-fbdev-devel] [PATCH 2/3] viafb: another small cleanup of viafb_par

[Florian T. S. <Flo...@gm...>]

viafb: another small cleanup of viafb_par

This removes the completly useless io variable as well as the temporary
used variables mmio_base and mmio_len in favor to use directly the
fb_info variables.
This is a code cleanup only, no runtime change expected.

Signed-off-by: Florian Tobias Schandinat <Flo...@gm...>
---
 hw.c       |    3 +--
 hw.h       |    3 +--
 viafbdev.c |    9 ++++-----
 viafbdev.h |    3 ---
 4 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 5be4a67..86050e7 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -2496,8 +2496,7 @@ void viafb_crt_enable(void)
 	viafb_write_reg_mask(CR36, VIACR, 0x0, BIT5 + BIT4);
 }
 
-void viafb_get_mmio_info(unsigned long *mmio_base,
-	unsigned long *mmio_len)
+void viafb_get_mmio_info(unsigned long *mmio_base, u32 *mmio_len)
 {
 	struct pci_dev *pdev = NULL;
 	u32 vendor, device;
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 874ea3f..cf1dfd5 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -923,8 +923,7 @@ int viafb_get_pixclock(int hres, int vres, int vmode_refresh);
 int viafb_get_refresh(int hres, int vres, u32 float_refresh);
 void viafb_update_device_setting(int hres, int vres, int bpp,
 			   int vmode_refresh, int flag);
-void viafb_get_mmio_info(unsigned long *mmio_base,
-	unsigned long *mmio_len);
+void viafb_get_mmio_info(unsigned long *mmio_base, u32 *mmio_len);
 
 void viafb_set_iga_path(void);
 void viafb_set_primary_address(u32 addr);
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 924177c..a17e138 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -69,8 +69,6 @@ static void viafb_setup_fixinfo(struct fb_fix_screeninfo *fix,
 
 	fix->smem_start = viaparinfo->fbmem;
 	fix->smem_len = viaparinfo->fbmem_free;
-	fix->mmio_start = viaparinfo->mmio_base;
-	fix->mmio_len = viaparinfo->mmio_len;
 
 	fix->type = FB_TYPE_PACKED_PIXELS;
 	fix->type_aux = 0;
@@ -2004,9 +2002,10 @@ static int __devinit via_pci_probe(void)
 		return -ENOMEM;
 	}
 
-	viafb_get_mmio_info(&viaparinfo->mmio_base, &viaparinfo->mmio_len);
-	viaparinfo->io_virt = ioremap_nocache(viaparinfo->mmio_base,
-		viaparinfo->mmio_len);
+	viafb_get_mmio_info(&viafbinfo->fix.mmio_start,
+		&viafbinfo->fix.mmio_len);
+	viaparinfo->io_virt = ioremap_nocache(viafbinfo->fix.mmio_start,
+		viafbinfo->fix.mmio_len);
 	if (!viaparinfo->io_virt) {
 		printk(KERN_WARNING "ioremap failed: hardware acceleration disabled\n");
 		viafb_accel = 0;
diff --git a/drivers/video/via/viafbdev.h b/drivers/video/via/viafbdev.h
index cd871f9..2763922 100644
--- a/drivers/video/via/viafbdev.h
+++ b/drivers/video/via/viafbdev.h
@@ -41,9 +41,6 @@ struct viafb_par {
 	void __iomem *io_virt;	/*iospace virtual memory address */
 	unsigned int fbmem;	/*framebuffer physical memory address */
 	unsigned int memsize;	/*size of fbmem */
-	unsigned int io;	/*io space address */
-	unsigned long mmio_base;	/*mmio base address */
-	unsigned long mmio_len;	/*mmio base length */
 	u32 fbmem_free;		/* Free FB memory */
 	u32 fbmem_used;		/* Use FB memory size */
 	u32 cursor_start;	/* Cursor Start Address */
-- 
1.6.3.2

[Linux-fbdev-devel] [PATCH 1/3] viafb: remove LVDS initialization

[Florian T. S. <Flo...@gm...>]

viafb: remove LVDS initialization

At least for VX800 this initialization is not very good as some parts of
the register are written with reserved values. This makes the display go
white in some configurations and not usable until the framebuffer is
removed. It's better to not initialize it as it allows to use a
previously (by BIOS) correctly configured display.
This patch makes some displays work but might cause problems on others.
This is bad but can not be easily avoided. If this causes some
regressions it's probably the best to fix it in the 'active' display
setup code.

Signed-off-by: Florian Tobias Schandinat <Flo...@gm...>
---
 viamode.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/video/via/viamode.c b/drivers/video/via/viamode.c
index 464903c..fbc2013 100644
--- a/drivers/video/via/viamode.c
+++ b/drivers/video/via/viamode.c
@@ -313,8 +313,7 @@ struct io_reg CX700_ModeXregs[] = { {VIASR, SR10, 0xFF, 0x01},
 {VIACR, CR96, 0xFF, 0x00},
 {VIACR, CR97, 0xFF, 0x00},
 {VIACR, CR99, 0xFF, 0x00},
-{VIACR, CR9B, 0xFF, 0x00},
-{VIACR, CRD2, 0xFF, 0xFF}	/* TMDS/LVDS control register.         */
+{VIACR, CR9B, 0xFF, 0x00}
 };
 
 /* Video Mode Table */
-- 
1.6.3.2

Re: [Linux-fbdev-devel] radeonfb cannot map FB

[Benjamin H. <be...@ke...>]

On Mon, 2009-08-24 at 20:45 +0100, Rui Santos wrote:
> Dear Benjamin Herrenschmidt, dear mailing list subscribers,
> 
>      I'm trying to load radeonfb for an RV100 QY chipset. Whatever I
> type in the modprobe I always get:
>        radeonfb (0000:01:0c.0): cannot map FB
>        radeonfb: probe of 0000:01:0c.0 failed with error -5

I suspect your BIOS isn't initializing the secondary card, radeonfb is
thus unable to use it.

However, you probably don't need radeonfb. X.org should be able to get
it going as a secondary just fine, but your text consoles will have to
remain on the intel.

In the long run (though it might already work with latest upstream), the
new radeon KMS should be able to initialize those.

Cheers,
Ben.

>     I've tried latest 2.6.27.x and 2.6.30.x kernels. This a secondary
> video card that I would like to connect a monitor to. The first video
> card is an Intel 915G, which is working with vesafb.
> 
>     Here is the output of lspci -vvv
>     01:0c.0 VGA compatible controller: ATI Technologies Inc Radeon RV100
> QY [Radeon 7000/VE] (prog-if 00 [VGA controller])
>             Subsystem: ATI Technologies Inc Device 013b
>             Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping+ SERR- FastB2B- DisINTx-
>             Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>             Interrupt: pin A routed to IRQ 18
>             Region 0: Memory at d8000000 (32-bit, prefetchable) [size=128M]
>             Region 1: I/O ports at dc00 [size=256]
>             Region 2: Memory at fdee0000 (32-bit, non-prefetchable)
> [size=64K]
>             [virtual] Expansion ROM at fde00000 [disabled] [size=128K]
>             Capabilities: [50] Power Management version 2
>                     Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                     Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>             Kernel modules: radeonfb
> 
>     Can you or anyone give a hint on what I might be doing wrong:
> modprobe radeonfb mode_option=800x600-16 panel_yres=600
>     Or could this be some kind of hardware issue ?
> 
>     Thanks a lot for your help,
> 
> Regards,
> 
> Rui Santos
> http://www.ruisantos.com/
> 
> Veni, vidi, Linux!
> 

[Linux-fbdev-devel] open and close semanthics

[Alessio S. <al...@ma...>]

Hi, can somebody give me an authoritative answer:
what is the semanthics associated to the "open" and "release" (close) calls?

More specifically, "open" and "release" can/must/must not change any 
setting (resolution etc)?

Should those functions keep a "counter" of how many programs opened it?

bye, thank you
Alessio

Re: [Linux-fbdev-devel] radeonfb cannot map FB

[Alex D. <ale...@gm...>]

On Mon, Aug 24, 2009 at 3:45 PM, Rui Santos<rs...@gr...> wrote:
> Dear Benjamin Herrenschmidt, dear mailing list subscribers,
>
>     I'm trying to load radeonfb for an RV100 QY chipset. Whatever I
> type in the modprobe I always get:
>       radeonfb (0000:01:0c.0): cannot map FB
>       radeonfb: probe of 0000:01:0c.0 failed with error -5
>
>    I've tried latest 2.6.27.x and 2.6.30.x kernels. This a secondary
> video card that I would like to connect a monitor to. The first video
> card is an Intel 915G, which is working with vesafb.
>
>    Here is the output of lspci -vvv
>    01:0c.0 VGA compatible controller: ATI Technologies Inc Radeon RV100
> QY [Radeon 7000/VE] (prog-if 00 [VGA controller])
>            Subsystem: ATI Technologies Inc Device 013b
>            Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping+ SERR- FastB2B- DisINTx-
>            Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>            Interrupt: pin A routed to IRQ 18
>            Region 0: Memory at d8000000 (32-bit, prefetchable) [size=128M]
>            Region 1: I/O ports at dc00 [size=256]
>            Region 2: Memory at fdee0000 (32-bit, non-prefetchable)
> [size=64K]
>            [virtual] Expansion ROM at fde00000 [disabled] [size=128K]
>            Capabilities: [50] Power Management version 2
>                    Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                    Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>            Kernel modules: radeonfb
>
>    Can you or anyone give a hint on what I might be doing wrong:
> modprobe radeonfb mode_option=800x600-16 panel_yres=600
>    Or could this be some kind of hardware issue ?

radeonfb doesn't currently have any code to post secondary x86 cards
so they won't work unless they have been posted by the system bios.

Alex

[Linux-fbdev-devel] radeonfb cannot map FB

[Rui S. <rs...@gr...>]

Dear Benjamin Herrenschmidt, dear mailing list subscribers,

     I'm trying to load radeonfb for an RV100 QY chipset. Whatever I
type in the modprobe I always get:
       radeonfb (0000:01:0c.0): cannot map FB
       radeonfb: probe of 0000:01:0c.0 failed with error -5

    I've tried latest 2.6.27.x and 2.6.30.x kernels. This a secondary
video card that I would like to connect a monitor to. The first video
card is an Intel 915G, which is working with vesafb.

    Here is the output of lspci -vvv
    01:0c.0 VGA compatible controller: ATI Technologies Inc Radeon RV100
QY [Radeon 7000/VE] (prog-if 00 [VGA controller])
            Subsystem: ATI Technologies Inc Device 013b
            Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR- FastB2B- DisINTx-
            Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
            Interrupt: pin A routed to IRQ 18
            Region 0: Memory at d8000000 (32-bit, prefetchable) [size=128M]
            Region 1: I/O ports at dc00 [size=256]
            Region 2: Memory at fdee0000 (32-bit, non-prefetchable)
[size=64K]
            [virtual] Expansion ROM at fde00000 [disabled] [size=128K]
            Capabilities: [50] Power Management version 2
                    Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                    Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
            Kernel modules: radeonfb

    Can you or anyone give a hint on what I might be doing wrong:
modprobe radeonfb mode_option=800x600-16 panel_yres=600
    Or could this be some kind of hardware issue ?

    Thanks a lot for your help,

Regards,

Rui Santos
http://www.ruisantos.com/

Veni, vidi, Linux!

[Linux-fbdev-devel] [PATCH] viafb: remove unused video device stuff

[Florian T. S. <Flo...@gm...>]

viafb: remove unused video device stuff

This patch removes everything related to video devices from the driver
as it did not influence the driver operation. This patch does change the
userspace behaviour as it removes two IOCTLs and one module parameter.
But this is good as it removes useless stuff and helps the user to
figure out the options that do affect the driver behaviour (which are
still too many).

Signed-off-by: Florian Tobias Schandinat <Flo...@gm...>
---
 ioctl.h    |    6 +----
 viafbdev.c |   77 ------------------------------------------------------------
 viafbdev.h |    6 ----
 3 files changed, 1 insertions(+), 88 deletions(-)

diff --git a/drivers/video/via/ioctl.h b/drivers/video/via/ioctl.h
index 842fe30..de89980 100644
--- a/drivers/video/via/ioctl.h
+++ b/drivers/video/via/ioctl.h
@@ -50,8 +50,6 @@
 #define VIAFB_GET_GAMMA_LUT		0x56494124
 #define VIAFB_SET_GAMMA_LUT		0x56494125
 #define VIAFB_GET_GAMMA_SUPPORT_STATE	0x56494126
-#define VIAFB_SET_VIDEO_DEVICE		0x56494127
-#define VIAFB_GET_VIDEO_DEVICE		0x56494128
 #define VIAFB_SET_SECOND_MODE		0x56494129
 #define VIAFB_SYNC_SURFACE		0x56494130
 #define VIAFB_GET_DRIVER_CAPS		0x56494131
@@ -179,9 +177,7 @@ struct viafb_ioctl_setting {
 	unsigned short second_dev_bpp;
 	/* Indicate which device are primary display device. */
 	unsigned int primary_device;
-	/* Indicate which device will show video. only valid in duoview mode */
-	unsigned int video_device_status;
-	unsigned int struct_reserved[34];
+	unsigned int struct_reserved[35];
 	struct viafb_ioctl_lcd_attribute lcd_attributes;
 };
 
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 86835ee..924177c 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -36,9 +36,6 @@ static char *viafb_mode1 = "640x480";
 /* Added for specifying active devices.*/
 char *viafb_active_dev = "";
 
-/* Added for specifying video on devices.*/
-char *viafb_video_dev = "";
-
 /*Added for specify lcd output port*/
 char *viafb_lcd_port = "";
 char *viafb_dvi_port = "";
@@ -50,8 +47,6 @@ static void apply_second_mode_setting(struct fb_var_screeninfo
 	*sec_var);
 static void retrieve_device_setting(struct viafb_ioctl_setting
 	*setting_info);
-static void viafb_set_video_device(u32 video_dev_info);
-static void viafb_get_video_device(u32 *video_dev_info);
 
 static struct fb_ops viafb_ops;
 
@@ -488,7 +483,6 @@ static int viafb_ioctl(struct fb_info *info, u_int cmd, u_long arg)
 
 	u32 __user *argp = (u32 __user *) arg;
 	u32 gpu32;
-	u32 video_dev_info = 0;
 
 	DEBUG_MSG(KERN_INFO "viafb_ioctl: 0x%X !!\n", cmd);
 	memset(&u, 0, sizeof(u));
@@ -720,15 +714,6 @@ static int viafb_ioctl(struct fb_info *info, u_int cmd, u_long arg)
 		if (put_user(state_info, argp))
 			return -EFAULT;
 		break;
-	case VIAFB_SET_VIDEO_DEVICE:
-		get_user(video_dev_info, argp);
-		viafb_set_video_device(video_dev_info);
-		break;
-	case VIAFB_GET_VIDEO_DEVICE:
-		viafb_get_video_device(&video_dev_info);
-		if (put_user(video_dev_info, argp))
-			return -EFAULT;
-		break;
 	case VIAFB_SYNC_SURFACE:
 		DEBUG_MSG(KERN_INFO "lobo VIAFB_SYNC_SURFACE\n");
 		break;
@@ -1309,32 +1294,6 @@ static void viafb_set_device(struct device_t active_dev)
 	viafb_set_iga_path();
 }
 
-static void viafb_set_video_device(u32 video_dev_info)
-{
-	viaparinfo->video_on_crt = STATE_OFF;
-	viaparinfo->video_on_dvi = STATE_OFF;
-	viaparinfo->video_on_lcd = STATE_OFF;
-
-	/* Check available device to enable: */
-	if ((video_dev_info & CRT_Device) == CRT_Device)
-		viaparinfo->video_on_crt = STATE_ON;
-	else if ((video_dev_info & DVI_Device) == DVI_Device)
-		viaparinfo->video_on_dvi = STATE_ON;
-	else if ((video_dev_info & LCD_Device) == LCD_Device)
-		viaparinfo->video_on_lcd = STATE_ON;
-}
-
-static void viafb_get_video_device(u32 *video_dev_info)
-{
-	*video_dev_info = None_Device;
-	if (viaparinfo->video_on_crt == STATE_ON)
-		*video_dev_info |= CRT_Device;
-	else if (viaparinfo->video_on_dvi == STATE_ON)
-		*video_dev_info |= DVI_Device;
-	else if (viaparinfo->video_on_lcd == STATE_ON)
-		*video_dev_info |= LCD_Device;
-}
-
 static int get_primary_device(void)
 {
 	int primary_device = 0;
@@ -1506,18 +1465,6 @@ static void retrieve_device_setting(struct viafb_ioctl_setting
 		setting_info->device_status |= LCD_Device;
 	if (viafb_LCD2_ON == 1)
 		setting_info->device_status |= LCD2_Device;
-	if ((viaparinfo->video_on_crt == 1) && (viafb_CRT_ON == 1)) {
-		setting_info->video_device_status =
-			viaparinfo->crt_setting_info->iga_path;
-	} else if ((viaparinfo->video_on_dvi == 1) && (viafb_DVI_ON == 1)) {
-		setting_info->video_device_status =
-			viaparinfo->tmds_setting_info->iga_path;
-	} else if ((viaparinfo->video_on_lcd == 1) && (viafb_LCD_ON == 1)) {
-		setting_info->video_device_status =
-			viaparinfo->lvds_setting_info->iga_path;
-	} else {
-		setting_info->video_device_status = 0;
-	}
 
 	setting_info->samm_status = viafb_SAMM_ON;
 	setting_info->primary_device = get_primary_device();
@@ -1606,24 +1553,6 @@ static void parse_active_dev(void)
 	}
 }
 
-static void parse_video_dev(void)
-{
-	viaparinfo->video_on_crt = STATE_OFF;
-	viaparinfo->video_on_dvi = STATE_OFF;
-	viaparinfo->video_on_lcd = STATE_OFF;
-
-	if (!strncmp(viafb_video_dev, "CRT", 3)) {
-		/* Video on CRT */
-		viaparinfo->video_on_crt = STATE_ON;
-	} else if (!strncmp(viafb_video_dev, "DVI", 3)) {
-		/* Video on DVI */
-		viaparinfo->video_on_dvi = STATE_ON;
-	} else if (!strncmp(viafb_video_dev, "LCD", 3)) {
-		/* Video on LCD */
-		viaparinfo->video_on_lcd = STATE_ON;
-	}
-}
-
 static int parse_port(char *opt_str, int *output_interface)
 {
 	if (!strncmp(opt_str, "DVP0", 4))
@@ -2054,7 +1983,6 @@ static int __devinit via_pci_probe(void)
 	if (viafb_dual_fb)
 		viafb_SAMM_ON = 1;
 	parse_active_dev();
-	parse_video_dev();
 	parse_lcd_port();
 	parse_dvi_port();
 
@@ -2354,8 +2282,6 @@ static int __init viafb_setup(char *options)
 		else if (!strncmp(this_opt, "viafb_lcd_mode=", 15))
 			strict_strtoul(this_opt + 15, 0,
 				(unsigned long *)&viafb_lcd_mode);
-		else if (!strncmp(this_opt, "viafb_video_dev=", 16))
-			viafb_video_dev = kstrdup(this_opt + 16, GFP_KERNEL);
 		else if (!strncmp(this_opt, "viafb_lcd_port=", 15))
 			viafb_lcd_port = kstrdup(this_opt + 15, GFP_KERNEL);
 		else if (!strncmp(this_opt, "viafb_dvi_port=", 15))
@@ -2476,9 +2402,6 @@ module_param(viafb_lcd_mode, int, 0);
 MODULE_PARM_DESC(viafb_lcd_mode,
 	"Set Flat Panel mode(Default=OPENLDI)");
 
-module_param(viafb_video_dev, charp, 0);
-MODULE_PARM_DESC(viafb_video_dev, "Specify video devices.");
-
 module_param(viafb_lcd_port, charp, 0);
 MODULE_PARM_DESC(viafb_lcd_port, "Specify LCD output port.");
 
diff --git a/drivers/video/via/viafbdev.h b/drivers/video/via/viafbdev.h
index e5a247c..cd871f9 100644
--- a/drivers/video/via/viafbdev.h
+++ b/drivers/video/via/viafbdev.h
@@ -61,12 +61,6 @@ struct viafb_par {
 	struct lvds_setting_information *lvds_setting_info;
 	struct lvds_setting_information *lvds_setting_info2;
 	struct chip_information *chip_info;
-
-	/* some information related to video playing */
-	int video_on_crt;
-	int video_on_dvi;
-	int video_on_lcd;
-
 };
 
 extern unsigned int viafb_second_virtual_yres;
-- 
1.6.3.2

[Linux-fbdev-devel] [PATCH v2] fb: do not ignore fb_set_par errors

[Florian T. S. <Flo...@gm...>]

fb: do not ignore fb_set_par errors

At the moment about half of the framebuffer drivers can return an error
code in fb_set_par. Until now it would be silently ignored by fbmem.c
and fbcon.c. This patch fixes fbmem.c to return the error code and
restore var on error. But it is not clear in which video mode the device
is when fb_set_par fails. It would be good and reasonable if it were in
the old state but there is no guarantee that this is true for all
existing drivers. Additionally print a message if a failing fb_set_par
is detected in fbmem.c or fbcon.c.
Although most errors should be caught by the previous fb_check_var some
errors can't as they are dynamic (memory allocations, ...) and can only
be detected while performing the operations which is forbidden in
fb_check_var.
This patch shouldn't have a negative impact on normal operation as all
drivers return 0 on success. The impact in case of error depends heavily
on the driver and caller but it's expected to be better than before.

Signed-off-by: Florian Tobias Schandinat <Flo...@gm...>
---
v2: print warning/error messages if fb_set_par fails
---
 drivers/video/console/fbcon.c |   48 +++++++++++++++++++++++++++++++---------
 drivers/video/fbmem.c         |   15 +++++++++++-
 2 files changed, 50 insertions(+), 13 deletions(-)

diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 3a44695..4bee7c2 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -725,7 +725,7 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
 				  int oldidx, int found)
 {
 	struct fbcon_ops *ops = oldinfo->fbcon_par;
-	int err = 0;
+	int err = 0, ret;
 
 	if (oldinfo->fbops->fb_release &&
 	    oldinfo->fbops->fb_release(oldinfo, 0)) {
@@ -752,8 +752,14 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
 		  newinfo in an undefined state. Thus, a call to
 		  fb_set_par() may be needed for the newinfo.
 		*/
-		if (newinfo->fbops->fb_set_par)
-			newinfo->fbops->fb_set_par(newinfo);
+		if (newinfo->fbops->fb_set_par) {
+			ret = newinfo->fbops->fb_set_par(newinfo);
+
+			if (ret)
+				printk(KERN_ERR "con2fb_release_oldinfo: "
+					"detected unhandled fb_set_par error, "
+					"error code %d\n", ret);
+		}
 	}
 
 	return err;
@@ -763,11 +769,18 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
 				int unit, int show_logo)
 {
 	struct fbcon_ops *ops = info->fbcon_par;
+	int ret;
 
 	ops->currcon = fg_console;
 
-	if (info->fbops->fb_set_par && !(ops->flags & FBCON_FLAGS_INIT))
-		info->fbops->fb_set_par(info);
+	if (info->fbops->fb_set_par && !(ops->flags & FBCON_FLAGS_INIT)) {
+		ret = info->fbops->fb_set_par(info);
+
+		if (ret)
+			printk(KERN_ERR "con2fb_init_display: detected "
+				"unhandled fb_set_par error, "
+				"error code %d\n", ret);
+	}
 
 	ops->flags |= FBCON_FLAGS_INIT;
 	ops->graphics = 0;
@@ -1006,7 +1019,7 @@ static void fbcon_init(struct vc_data *vc, int init)
 	struct vc_data *svc = *default_mode;
 	struct display *t, *p = &fb_display[vc->vc_num];
 	int logo = 1, new_rows, new_cols, rows, cols, charcnt = 256;
-	int cap;
+	int cap, ret;
 
 	if (info_idx == -1 || info == NULL)
 	    return;
@@ -1092,8 +1105,15 @@ static void fbcon_init(struct vc_data *vc, int init)
 	 */
 	if (CON_IS_VISIBLE(vc) && vc->vc_mode == KD_TEXT) {
 		if (info->fbops->fb_set_par &&
-		    !(ops->flags & FBCON_FLAGS_INIT))
-			info->fbops->fb_set_par(info);
+		    !(ops->flags & FBCON_FLAGS_INIT)) {
+			ret = info->fbops->fb_set_par(info);
+
+			if (ret)
+				printk(KERN_ERR "fbcon_init: detected "
+					"unhandled fb_set_par error, "
+					"error code %d\n", ret);
+		}
+
 		ops->flags |= FBCON_FLAGS_INIT;
 	}
 
@@ -2119,7 +2139,7 @@ static int fbcon_switch(struct vc_data *vc)
 	struct fbcon_ops *ops;
 	struct display *p = &fb_display[vc->vc_num];
 	struct fb_var_screeninfo var;
-	int i, prev_console, charcnt = 256;
+	int i, ret, prev_console, charcnt = 256;
 
 	info = registered_fb[con2fb_map[vc->vc_num]];
 	ops = info->fbcon_par;
@@ -2174,8 +2194,14 @@ static int fbcon_switch(struct vc_data *vc)
 
 	if (old_info != NULL && (old_info != info ||
 				 info->flags & FBINFO_MISC_ALWAYS_SETPAR)) {
-		if (info->fbops->fb_set_par)
-			info->fbops->fb_set_par(info);
+		if (info->fbops->fb_set_par) {
+			ret = info->fbops->fb_set_par(info);
+
+			if (ret)
+				printk(KERN_ERR "fbcon_switch: detected "
+					"unhandled fb_set_par error, "
+					"error code %d\n", ret);
+		}
 
 		if (old_info != info)
 			fbcon_del_cursor_timer(old_info);
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index a85c818..008f95a 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -954,6 +954,7 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
 			goto done;
 
 		if ((var->activate & FB_ACTIVATE_MASK) == FB_ACTIVATE_NOW) {
+			struct fb_var_screeninfo old_var;
 			struct fb_videomode mode;
 
 			if (info->fbops->fb_get_caps) {
@@ -963,10 +964,20 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
 					goto done;
 			}
 
+			old_var = info->var;
 			info->var = *var;
 
-			if (info->fbops->fb_set_par)
-				info->fbops->fb_set_par(info);
+			if (info->fbops->fb_set_par) {
+				ret = info->fbops->fb_set_par(info);
+
+				if (ret) {
+					info->var = old_var;
+					printk(KERN_WARNING "detected "
+						"fb_set_par error, "
+						"error code: %d\n", ret);
+					goto done;
+				}
+			}
 
 			fb_pan_display(info, &info->var);
 			fb_set_cmap(&info->cmap, info);
-- 
1.6.3.2

Re: [Linux-fbdev-devel] [PATCH] fb: do not ignore fb_set_par errors

[Florian T. S. <Flo...@gm...>]

Andrew Morton schrieb:
> On Thu, 20 Aug 2009 11:59:56 +0000
> Florian Tobias Schandinat <Flo...@gm...> wrote:
> 
>> at the moment about half of the framebuffer drivers can return an error
>> code in fb_set_par. Until now it would be silently ignored by fbmem.c
>> and fbcon.c. The following patch fixes fbmem.c to pass it on but I have
>> no idea what the right behaviour in fbcon.c would look like.
>> Any comments?
> 
> Nobody really maintains this code any more and I don't know to whom
> your question should be addressed.  All I can suggest is that you
> decide what is the best path to take, and propose that we take it!  

Okay. I think it's difficult to ensure that we always end up with a 
working console. I assume that this is a very very rare case and as a 
start it should be enough to detect those cases and print an error message.

> Yes, it seems reasonable to me - if we ignore this the machine will
> probably crash later anyway.
> 
> A well-behaved driver should leave the hardware in an unchanged state
> if it's going to return an error (IMO).
> 
> Do you know of any bug reports which are due to this lack of checking?

No, I just hit the problem by thinking about how dynamic errors can be 
handled and looking at some drivers and fbmem.c.

> If you're concerned about the effects of this change, perhaps you
> should add a nice big printk when we decide to error out, so that it
> makes it easier for bug reporters (and responders!) to work out what
> happened?

That's a very good idea. Will add this too and resend the patch.


Thanks,

Florian Tobias Schandinat

Re: [Linux-fbdev-devel] [PATCH] fb: do not ignore fb_set_par errors

[Andrew M. <ak...@li...>]

On Thu, 20 Aug 2009 11:59:56 +0000
Florian Tobias Schandinat <Flo...@gm...> wrote:

> at the moment about half of the framebuffer drivers can return an error
> code in fb_set_par. Until now it would be silently ignored by fbmem.c
> and fbcon.c. The following patch fixes fbmem.c to pass it on but I have
> no idea what the right behaviour in fbcon.c would look like.
> Any comments?

Nobody really maintains this code any more and I don't know to whom
your question should be addressed.  All I can suggest is that you
decide what is the best path to take, and propose that we take it!  

On Thu, 20 Aug 2009 11:59:57 +0000
Florian Tobias Schandinat <Flo...@gm...> wrote:

> fb: do not ignore fb_set_par errors
> 
> At the moment about half of the framebuffer drivers can return an error
> code in fb_set_par. Until now it would be silently ignored by fbmem.c
> and fbcon.c. This patch fixes fbmem.c to return the error code and
> restore var on error. But it is not clear in which video mode the device
> is when fb_set_par fails. It would be good and reasonable if it were in
> the old state but there is no guarantee that this is true for all
> existing drivers.
> Although most errors should be caught by the previous fb_check_var some
> errors can't as they are dynamic (memory allocations, ...) and can only
> be detected while performing the operations which is forbidden in
> fb_check_var.
> This patch shouldn't have a negative impact on normal operation as all
> drivers return 0 on success. The impact in case of error depends heavily
> on the driver and caller but it's expected to be better than before.
> 
> Signed-off-by: Florian Tobias Schandinat <Flo...@gm...>
> ---
>  drivers/video/fbmem.c |   12 ++++++++++--
>  1 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index a85c818..85c1595 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -954,6 +954,7 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
>  			goto done;
>  
>  		if ((var->activate & FB_ACTIVATE_MASK) == FB_ACTIVATE_NOW) {
> +			struct fb_var_screeninfo old_var;
>  			struct fb_videomode mode;
>  
>  			if (info->fbops->fb_get_caps) {
> @@ -963,10 +964,17 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
>  					goto done;
>  			}
>  
> +			old_var = info->var;
>  			info->var = *var;
>  
> -			if (info->fbops->fb_set_par)
> -				info->fbops->fb_set_par(info);
> +			if (info->fbops->fb_set_par) {
> +				ret = info->fbops->fb_set_par(info);
> +
> +				if (ret) {
> +					info->var = old_var;
> +					goto done;
> +				}
> +			}

Yes, it seems reasonable to me - if we ignore this the machine will
probably crash later anyway.

A well-behaved driver should leave the hardware in an unchanged state
if it's going to return an error (IMO).

Do you know of any bug reports which are due to this lack of checking?

If you're concerned about the effects of this change, perhaps you
should add a nice big printk when we decide to error out, so that it
makes it easier for bug reporters (and responders!) to work out what
happened?

Re: [Linux-fbdev-devel] s3c2410fb: fix clockrate calculation

[Andrew M. <ak...@li...>]

On Thu, 20 Aug 2009 22:50:47 +0100
Ben Dooks <be...@si...> wrote:

> In the final part of the calculation for the tft display clockrate we
> divide the output pf s3c2410fb_calc_pixclk() by 2 which leaves us with
> a rounding error if the result is odd.
> 
> Change to using DIV_ROUND_UP() to ensure that we always choose a higher
> divisor and thus a lower frequency.
> 
> Signed-off-by: Ben Dooks <be...@si...>
> 
> ---
>  drivers/video/s3c2410fb.c |    4 +++-
>  2 files changed, 5 insertions(+), 2 deletions(-)
>  
> Index: b/drivers/video/s3c2410fb.c
> ===================================================================
> --- a/drivers/video/s3c2410fb.c	2009-08-20 08:45:41.000000000 +0100
> +++ b/drivers/video/s3c2410fb.c	2009-08-20 08:45:42.000000000 +0100
> @@ -369,7 +369,9 @@ static void s3c2410fb_activate_var(struc
>  	void __iomem *regs = fbi->io;
>  	int type = fbi->regs.lcdcon1 & S3C2410_LCDCON1_TFT;
>  	struct fb_var_screeninfo *var = &info->var;
> -	int clkdiv = s3c2410fb_calc_pixclk(fbi, var->pixclock) / 2;
> +	int clkdiv;
> +
> +	clkdiv = DIV_ROUND_UP(s3c2410fb_calc_pixclk(fbi, var->pixclock), 2);
>  
>  	printk(KERN_INFO "%s: pixclock=%d, clkdiv=%d\n",
>  	       __func__, var->pixclock, clkdiv);

The changelog forgot to tell us what the impact of this bug is, so I
cannot work out whether we need this fix in 2.6.32, 2.6.31, 2.6.30.x, ....

[Linux-fbdev-devel] s3c2410fb: fix clockrate calculation

[Ben D. <be...@si...>]

In the final part of the calculation for the tft display clockrate we
divide the output pf s3c2410fb_calc_pixclk() by 2 which leaves us with
a rounding error if the result is odd.

Change to using DIV_ROUND_UP() to ensure that we always choose a higher
divisor and thus a lower frequency.

Signed-off-by: Ben Dooks <be...@si...>

---
 drivers/video/s3c2410fb.c |    4 +++-
 2 files changed, 5 insertions(+), 2 deletions(-)
 
Index: b/drivers/video/s3c2410fb.c
===================================================================
--- a/drivers/video/s3c2410fb.c	2009-08-20 08:45:41.000000000 +0100
+++ b/drivers/video/s3c2410fb.c	2009-08-20 08:45:42.000000000 +0100
@@ -369,7 +369,9 @@ static void s3c2410fb_activate_var(struc
 	void __iomem *regs = fbi->io;
 	int type = fbi->regs.lcdcon1 & S3C2410_LCDCON1_TFT;
 	struct fb_var_screeninfo *var = &info->var;
-	int clkdiv = s3c2410fb_calc_pixclk(fbi, var->pixclock) / 2;
+	int clkdiv;
+
+	clkdiv = DIV_ROUND_UP(s3c2410fb_calc_pixclk(fbi, var->pixclock), 2);
 
 	printk(KERN_INFO "%s: pixclock=%d, clkdiv=%d\n",
 	       __func__, var->pixclock, clkdiv);

-- 
Ben (be...@fl..., http://www.fluff.org/)

  'a smiley only costs 4 bytes'

[Linux-fbdev-devel] [RFC][PATCH] omapfb: Reorder Register_framebuffer call

[Aguirre R. S. A. <saa...@ti...>]

From: Sergio Aguirre <saa...@ti...>

This fixes the issue in which mm_lock mutex was attempted to be
used without initializing previously.

Signed-off-by: Sergio Aguirre <saa...@ti...>
---
 drivers/video/omap/omapfb_main.c |   20 +++++++++++---------
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index 125e605..60f9482 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -1503,12 +1503,21 @@ static int fbinfo_init(struct omapfb_device *fbdev, struct fb_info *info)
 	var->rotate	  = def_rotate;
 	var->bits_per_pixel = fbdev->panel->bpp;
 
+	r = register_framebuffer(info);
+	if (r != 0) {
+		dev_err(fbdev->dev,
+			"registering framebuffer failed\n");
+		return r;
+	}
+
 	set_fb_var(info, var);
 	set_fb_fix(info);
 
 	r = fb_alloc_cmap(&info->cmap, 16, 0);
-	if (r != 0)
+	if (r != 0) {
 		dev_err(fbdev->dev, "unable to allocate color map memory\n");
+		unregister_framebuffer(info);
+	}
 
 	return r;
 }
@@ -1773,15 +1782,8 @@ static int omapfb_do_probe(struct platform_device *pdev,
 	init_state++;
 
 	vram = 0;
-	for (i = 0; i < fbdev->mem_desc.region_cnt; i++) {
-		r = register_framebuffer(fbdev->fb_info[i]);
-		if (r != 0) {
-			dev_err(fbdev->dev,
-				"registering framebuffer %d failed\n", i);
-			goto cleanup;
-		}
+	for (i = 0; i < fbdev->mem_desc.region_cnt; i++)
 		vram += fbdev->mem_desc.region[i].size;
-	}
 
 	fbdev->state = OMAPFB_ACTIVE;
 
-- 
1.6.3.2

[Linux-fbdev-devel] [PATCH] fb: do not ignore fb_set_par errors

[Florian T. S. <Flo...@gm...>]

fb: do not ignore fb_set_par errors

At the moment about half of the framebuffer drivers can return an error
code in fb_set_par. Until now it would be silently ignored by fbmem.c
and fbcon.c. This patch fixes fbmem.c to return the error code and
restore var on error. But it is not clear in which video mode the device
is when fb_set_par fails. It would be good and reasonable if it were in
the old state but there is no guarantee that this is true for all
existing drivers.
Although most errors should be caught by the previous fb_check_var some
errors can't as they are dynamic (memory allocations, ...) and can only
be detected while performing the operations which is forbidden in
fb_check_var.
This patch shouldn't have a negative impact on normal operation as all
drivers return 0 on success. The impact in case of error depends heavily
on the driver and caller but it's expected to be better than before.

Signed-off-by: Florian Tobias Schandinat <Flo...@gm...>
---
 drivers/video/fbmem.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index a85c818..85c1595 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -954,6 +954,7 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
 			goto done;
 
 		if ((var->activate & FB_ACTIVATE_MASK) == FB_ACTIVATE_NOW) {
+			struct fb_var_screeninfo old_var;
 			struct fb_videomode mode;
 
 			if (info->fbops->fb_get_caps) {
@@ -963,10 +964,17 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
 					goto done;
 			}
 
+			old_var = info->var;
 			info->var = *var;
 
-			if (info->fbops->fb_set_par)
-				info->fbops->fb_set_par(info);
+			if (info->fbops->fb_set_par) {
+				ret = info->fbops->fb_set_par(info);
+
+				if (ret) {
+					info->var = old_var;
+					goto done;
+				}
+			}
 
 			fb_pan_display(info, &info->var);
 			fb_set_cmap(&info->cmap, info);
-- 
1.6.3.2

[Linux-fbdev-devel] [RFC] fbcon: fb_set_par error handling

[Florian T. S. <Flo...@gm...>]

Hi all,

at the moment about half of the framebuffer drivers can return an error
code in fb_set_par. Until now it would be silently ignored by fbmem.c
and fbcon.c. The following patch fixes fbmem.c to pass it on but I have
no idea what the right behaviour in fbcon.c would look like.
Any comments?

The following files might return a non-zero value:
(false positives are possible as I scanned them only superficial)

drivers/gpu/drm/i915/intel_fb.c
drivers/gpu/drm/radeon/radeon_fb.c
drivers/video/matrox/matroxfb_crtc2.c
drivers/video/matrox/matroxfb_base.c
drivers/video/vt8623fb.c
drivers/video/vermilion/vermilion.c
drivers/video/uvesafb.c
drivers/video/neofb.c
drivers/video/aty/radeon_base.c
drivers/video/aty/atyfb_base.c
drivers/video/aty/aty128fb.c
drivers/video/platinumfb.c
drivers/video/intelfb/intelfbdrv.c
drivers/video/omap/omapfb_main.c
drivers/video/skeletonfb.c
drivers/video/s3fb.c
drivers/video/savage/savagefb_driver.c
drivers/video/gxt4500.c
drivers/video/tmiofb.c
drivers/video/pxafb.c
drivers/video/mbx/mbxfb.c
drivers/video/sis/sis_main.c
drivers/video/mx3fb.c
drivers/video/arkfb.c
drivers/video/fsl-diu-fb.c
drivers/video/valkyriefb.c
drivers/video/pm2fb.c
drivers/video/sstfb.c
drivers/video/imsttfb.c
drivers/video/carminefb.c
drivers/video/riva/fbdev.c
drivers/video/sh7760fb.c
drivers/video/sm501fb.c
drivers/video/ps3fb.c
drivers/video/controlfb.c

Re: [Linux-fbdev-devel] Getting DSS2 to mainline

[Tony L. <to...@at...>]

* Tomi Valkeinen <tom...@no...> [090817 14:25]:
> Hi,
>
> As I'm new to sending patches upstream, I'm not sure how to go forward  
> with DSS2 now. Should I send it to linux-arm-kernel mailing list, or  
> directly to main linux kernel mailing list? Or is there a route through  
> fbdev-devel list for DSS2 to go forward?

I suggest send them to fbdev-devel list and cc linux-omap. For the clock
alias patches you might want to also cc linux-arm-kernel.

Regards,

Tony

[Linux-fbdev-devel] [PATCH 2/4 v2] viafb: remove duplicated mode information

[Florian T. S. <Flo...@gm...>]

viafb: remove duplicated mode information

This patch removes the mode information from viafbdev.c and uses the one
of viamode.c instead. This is possible because horizontal and vertical
address are the same as horizontal and vertical resolution. The  reduced
blanking modes in the table are no problem because they have a higher
index than the normal modes and therefore always the normal modes are
selected just as the old behaviour.

Signed-off-by: Florian Tobias Schandinat <Flo...@gm...>
---
v2: adjusted error handling
---
 viafbdev.c |   57 ++++++++-------------------------------------------------
 viafbdev.h |    6 +-----
 2 files changed, 9 insertions(+), 54 deletions(-)

diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 72759b6..50e9300 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -53,51 +53,6 @@ static void retrieve_device_setting(struct viafb_ioctl_setting
 static void viafb_set_video_device(u32 video_dev_info);
 static void viafb_get_video_device(u32 *video_dev_info);
 
-/* Mode information */
-static const struct viafb_modeinfo viafb_modentry[] = {
-	{480, 640, VIA_RES_480X640},
-	{640, 480, VIA_RES_640X480},
-	{800, 480, VIA_RES_800X480},
-	{800, 600, VIA_RES_800X600},
-	{1024, 768, VIA_RES_1024X768},
-	{1152, 864, VIA_RES_1152X864},
-	{1280, 1024, VIA_RES_1280X1024},
-	{1600, 1200, VIA_RES_1600X1200},
-	{1440, 1050, VIA_RES_1440X1050},
-	{1280, 768, VIA_RES_1280X768,},
-	{1280, 800, VIA_RES_1280X800},
-	{1280, 960, VIA_RES_1280X960},
-	{1920, 1440, VIA_RES_1920X1440},
-	{848, 480, VIA_RES_848X480},
-	{1400, 1050, VIA_RES_1400X1050},
-	{720, 480, VIA_RES_720X480},
-	{720, 576, VIA_RES_720X576},
-	{1024, 512, VIA_RES_1024X512},
-	{1024, 576, VIA_RES_1024X576},
-	{1024, 600, VIA_RES_1024X600},
-	{1280, 720, VIA_RES_1280X720},
-	{1920, 1080, VIA_RES_1920X1080},
-	{1366, 768, VIA_RES_1368X768},
-	{1680, 1050, VIA_RES_1680X1050},
-	{960, 600, VIA_RES_960X600},
-	{1000, 600, VIA_RES_1000X600},
-	{1024, 576, VIA_RES_1024X576},
-	{1024, 600, VIA_RES_1024X600},
-	{1088, 612, VIA_RES_1088X612},
-	{1152, 720, VIA_RES_1152X720},
-	{1200, 720, VIA_RES_1200X720},
-	{1280, 600, VIA_RES_1280X600},
-	{1360, 768, VIA_RES_1360X768},
-	{1440, 900, VIA_RES_1440X900},
-	{1600, 900, VIA_RES_1600X900},
-	{1600, 1024, VIA_RES_1600X1024},
-	{1792, 1344, VIA_RES_1792X1344},
-	{1856, 1392, VIA_RES_1856X1392},
-	{1920, 1200, VIA_RES_1920X1200},
-	{2048, 1536, VIA_RES_2048X1536},
-	{0, 0, VIA_RES_INVALID}
-};
-
 static struct fb_ops viafb_ops;
 
 
@@ -1239,12 +1194,16 @@ int viafb_get_mode_index(int hres, int vres)
 	u32 i;
 	DEBUG_MSG(KERN_INFO "viafb_get_mode_index!\n");
 
-	for (i = 0; viafb_modentry[i].mode_index != VIA_RES_INVALID; i++)
-		if (viafb_modentry[i].xres == hres &&
-			viafb_modentry[i].yres == vres)
+	for (i = 0; i < NUM_TOTAL_MODETABLE; i++)
+		if (CLE266Modes[i].mode_array &&
+			CLE266Modes[i].crtc[0].crtc.hor_addr == hres &&
+			CLE266Modes[i].crtc[0].crtc.ver_addr == vres)
 			break;
 
-	return viafb_modentry[i].mode_index;
+	if (i == NUM_TOTAL_MODETABLE)
+		return VIA_RES_INVALID;
+
+	return CLE266Modes[i].ModeIndex;
 }
 
 static void check_available_device_to_enable(int device_id)
diff --git a/drivers/video/via/viafbdev.h b/drivers/video/via/viafbdev.h
index ea0df4f..cd3dff7 100644
--- a/drivers/video/via/viafbdev.h
+++ b/drivers/video/via/viafbdev.h
@@ -70,11 +70,7 @@ struct viafb_par {
 	int video_on_lcd;
 
 };
-struct viafb_modeinfo {
-	u32 xres;
-	u32 yres;
-	int mode_index;
-};
+
 extern unsigned int viafb_second_virtual_yres;
 extern unsigned int viafb_second_virtual_xres;
 extern unsigned int viafb_second_offset;
-- 
1.6.3.2

Re: [Linux-fbdev-devel] Getting DSS2 to mainline

[Geert U. <gee...@gm...>]

On Mon, Aug 17, 2009 at 14:17, Florian Tobias
Schandinat<Flo...@gm...> wrote:
> Tomi Valkeinen schrieb:
>> As I'm new to sending patches upstream, I'm not sure how to go forward
>> with DSS2 now. Should I send it to linux-arm-kernel mailing list, or
>> directly to main linux kernel mailing list? Or is there a route through
>> fbdev-devel list for DSS2 to go forward?
>
> I am also new to this process but from what I've heard I decided to
> always cc Andrew Morton <ak...@li...> when I think that
> something is mature enough for inclusion. That works very well, thanks
> Andrew.
> Sending them only to linux-fbdev-devel looks rather like a dead end at
> least if I look on the fate of some patches in the archive.
> I always cc the LKML but until now I didn't hear anything from there
> either so I doubt that would be the right way.
>
> I'm sorry if anything of the above is incorrect, it's just my experience.

Yes, CCing Andrew Morton is The Right Thing To Do.

Thanks!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] Getting DSS2 to mainline

[Florian T. S. <Flo...@gm...>]

Hi,

Tomi Valkeinen schrieb:
> Hi,
> 
> As I'm new to sending patches upstream, I'm not sure how to go forward 
> with DSS2 now. Should I send it to linux-arm-kernel mailing list, or 
> directly to main linux kernel mailing list? Or is there a route through 
> fbdev-devel list for DSS2 to go forward?

I am also new to this process but from what I've heard I decided to 
always cc Andrew Morton <ak...@li...> when I think that 
something is mature enough for inclusion. That works very well, thanks 
Andrew.
Sending them only to linux-fbdev-devel looks rather like a dead end at 
least if I look on the fate of some patches in the archive.
I always cc the LKML but until now I didn't hear anything from there 
either so I doubt that would be the right way.

I'm sorry if anything of the above is incorrect, it's just my experience.


Regards,

Florian Tobias Schandinat

[Linux-fbdev-devel] [PATCH 4/4] viafb: cleanup virtual memory handling

[Florian T. S. <Flo...@gm...>]

viafb: cleanup virtual memory handling

This patch cleans the handling of ioremapped video memory up. The
following changes were made:

info->screen_base - viafb_FB_MM
(VRAM offset calculation) was replaced by
info->fix.smem_start - viafbinfo->fix.smem_start
which is essentially the same calculation but done with physical instead
virtual addresses.

*->fbmem_virt
was replaced by
viafbinfo->screen_base
This is true for viafbinfo and viafbinfo1 as the par pointers are equal.

An early initialization of viafbinfo1->fix.smem* was removed as done
later in viafb_setup_fixinfo.

This patch highlights that the only usage of the ioremapped video memory
in the driver is for hardware cursor handling. Even if it has to hold
the used virtual screen mapped for old-fashioned read/write calls (vs.
mmap'ed) a lot virtual memory could be saved by only ioremapping
on demand.

Code cleanup, no runtime changes expected.

Signed-off-by: Florian Tobias Schandinat <Flo...@gm...>
---
 global.c   |    1 -
 global.h   |    1 -
 viafbdev.c |   27 ++++++++-------------------
 viafbdev.h |    1 -
 4 files changed, 8 insertions(+), 22 deletions(-)

diff --git a/drivers/video/via/global.c b/drivers/video/via/global.c
index 468be24..1096fd5 100644
--- a/drivers/video/via/global.c
+++ b/drivers/video/via/global.c
@@ -46,7 +46,6 @@ int viafb_hotplug_refresh = 60;
 unsigned int viafb_second_offset;
 int viafb_second_size;
 int viafb_primary_dev = None_Device;
-void __iomem *viafb_FB_MM;
 unsigned int viafb_second_xres = 640;
 unsigned int viafb_second_yres = 480;
 unsigned int viafb_second_virtual_xres;
diff --git a/drivers/video/via/global.h b/drivers/video/via/global.h
index 7543d5f..11382e5 100644
--- a/drivers/video/via/global.h
+++ b/drivers/video/via/global.h
@@ -77,7 +77,6 @@ extern int viafb_hotplug_Yres;
 extern int viafb_hotplug_bpp;
 extern int viafb_hotplug_refresh;
 extern int viafb_primary_dev;
-extern void __iomem *viafb_FB_MM;
 extern struct fb_cursor viacursor;
 
 extern unsigned int viafb_second_xres;
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index e48e493..ab1f491 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -832,8 +832,7 @@ static void viafb_fillrect(struct fb_info *info,
 	/* Source Base Address */
 	writel(0x0, viaparinfo->io_virt + VIA_REG_SRCBASE);
 	/* Destination Base Address */
-	writel(((unsigned long) (info->screen_base) -
-		   (unsigned long) viafb_FB_MM) >> 3,
+	writel((info->fix.smem_start - viafbinfo->fix.smem_start) >> 3,
 		   viaparinfo->io_virt + VIA_REG_DSTBASE);
 	/* Pitch */
 	pitch = (info->var.xres_virtual + 7) & ~7;
@@ -887,12 +886,10 @@ static void viafb_copyarea(struct fb_info *info,
 	}
 
 	/* Source Base Address */
-	writel(((unsigned long) (info->screen_base) -
-		   (unsigned long) viafb_FB_MM) >> 3,
+	writel((info->fix.smem_start - viafbinfo->fix.smem_start) >> 3,
 		   viaparinfo->io_virt + VIA_REG_SRCBASE);
 	/* Destination Base Address */
-	writel(((unsigned long) (info->screen_base) -
-		   (unsigned long) viafb_FB_MM) >> 3,
+	writel((info->fix.smem_start - viafbinfo->fix.smem_start) >> 3,
 		   viaparinfo->io_virt + VIA_REG_DSTBASE);
 	/* Pitch */
 	pitch = (info->var.xres_virtual + 7) & ~7;
@@ -951,8 +948,7 @@ static void viafb_imageblit(struct fb_info *info,
 	/* Source Base Address */
 	writel(0x0, viaparinfo->io_virt + VIA_REG_SRCBASE);
 	/* Destination Base Address */
-	writel(((unsigned long) (info->screen_base) -
-		   (unsigned long) viafb_FB_MM) >> 3,
+	writel((info->fix.smem_start - viafbinfo->fix.smem_start) >> 3,
 		   viaparinfo->io_virt + VIA_REG_DSTBASE);
 	/* Pitch */
 	pitch = (info->var.xres_virtual + 7) & ~7;
@@ -1170,7 +1166,7 @@ static int viafb_cursor(struct fb_info *info, struct fb_cursor *cursor)
 			}
 		}
 
-		memcpy(((struct viafb_par *)(info->par))->fbmem_virt +
+		memcpy(viafbinfo->screen_base +
 		       ((struct viafb_par *)(info->par))->cursor_start,
 		       cr_data->bak, CURSOR_SIZE);
 out:
@@ -2070,11 +2066,9 @@ static int __devinit via_pci_probe(void)
 	viafb_get_fb_info(&viaparinfo->fbmem, &viaparinfo->memsize);
 	viaparinfo->fbmem_free = viaparinfo->memsize;
 	viaparinfo->fbmem_used = 0;
-	viaparinfo->fbmem_virt = ioremap_nocache(viaparinfo->fbmem,
+	viafbinfo->screen_base = ioremap_nocache(viaparinfo->fbmem,
 		viaparinfo->memsize);
-	viafbinfo->screen_base = (char *)viaparinfo->fbmem_virt;
-
-	if (!viaparinfo->fbmem_virt) {
+	if (!viafbinfo->screen_base) {
 		printk(KERN_INFO "ioremap failed\n");
 		return -ENOMEM;
 	}
@@ -2107,7 +2101,6 @@ static int __devinit via_pci_probe(void)
 			viafb_second_size * 1024 * 1024;
 	}
 
-	viafb_FB_MM = viaparinfo->fbmem_virt;
 	tmpm = viafb_mode;
 	tmpc = strsep(&tmpm, "x");
 	strict_strtoul(tmpc, 0, &default_xres);
@@ -2200,8 +2193,6 @@ static int __devinit via_pci_probe(void)
 		viaparinfo1->memsize = viaparinfo->memsize -
 			viafb_second_offset;
 		viaparinfo->memsize = viafb_second_offset;
-		viaparinfo1->fbmem_virt = viaparinfo->fbmem_virt +
-			viafb_second_offset;
 		viaparinfo1->fbmem = viaparinfo->fbmem + viafb_second_offset;
 
 		viaparinfo1->fbmem_used = viaparinfo->fbmem_used;
@@ -2223,8 +2214,6 @@ static int __devinit via_pci_probe(void)
 		memcpy(viafbinfo1, viafbinfo, sizeof(struct fb_info));
 		viafbinfo1->screen_base = viafbinfo->screen_base +
 			viafb_second_offset;
-		viafbinfo1->fix.smem_start = viaparinfo1->fbmem;
-		viafbinfo1->fix.smem_len = viaparinfo1->fbmem_free;
 
 		default_var.xres = viafb_second_xres;
 		default_var.yres = viafb_second_yres;
@@ -2286,7 +2275,7 @@ static void __devexit via_pci_remove(void)
 	unregister_framebuffer(viafbinfo);
 	if (viafb_dual_fb)
 		unregister_framebuffer(viafbinfo1);
-	iounmap((void *)viaparinfo->fbmem_virt);
+	iounmap((void *)viafbinfo->screen_base);
 	iounmap(viaparinfo->io_virt);
 
 	viafb_delete_i2c_buss(viaparinfo);
diff --git a/drivers/video/via/viafbdev.h b/drivers/video/via/viafbdev.h
index 9231877..e5a247c 100644
--- a/drivers/video/via/viafbdev.h
+++ b/drivers/video/via/viafbdev.h
@@ -38,7 +38,6 @@
 #define VERSION_MINOR       4
 
 struct viafb_par {
-	void __iomem *fbmem_virt;	/*framebuffer virtual memory address */
 	void __iomem *io_virt;	/*iospace virtual memory address */
 	unsigned int fbmem;	/*framebuffer physical memory address */
 	unsigned int memsize;	/*size of fbmem */
-- 
1.6.3.2