The following patches are the beginning of an effort to move work done for
the OLPC XO 1.5 machine into the mainline.  What's here is basic support
for the VX855 chipset, I2C, suspend/resume, and the OLPC panel display.
What's coming in the future is a reworking of the viafb driver into
something resembling a proper multifunction device, GPIO support, and
camera support.  But I'd like to start here.

If there's no objections, I'll start a tree and get it into linux-next in
the near future, with an eye toward a 2.6.35 merge.

Thanks,

jon

Chris Ball (2):
      viafb: Add 1200x900 DCON/LCD panel modes for OLPC XO-1.5
      viafb: Do not probe for LVDS/TMDS on OLPC XO-1.5

Deepak Saxena (3):
      Minimal support for viafb suspend/resume
      VIAFB: Update suspend/resume to selectively restore registers
      Remove cursor restore hack in viafb

Harald Welte (4):
      [FB] viafb: Fix various resource leaks during module_init()
      viafb: use proper pci config API
      viafb: Determine type of 2D engine and store it in chip_info
      viafb: rework the I2C support in the VIA framebuffer driver

Jonathan Corbet (5):
      viafb: Unmap the frame buffer on initialization error
      viafb: Retain GEMODE reserved bits
      viafb: complete support for VX800/VX855 accelerated framebuffer
      viafb: rework suspend/resume
      viafb: Only suspend/resume on VX855

Paul Fox (2):
      suppress verbose debug messages:  change printk() to DEBUG_MSG()
      fix register save count, so it matches the restore count.

 drivers/video/via/accel.c    |   87 ++++++++++++++-----
 drivers/video/via/accel.h    |   40 +++++++++
 drivers/video/via/chip.h     |    8 +
 drivers/video/via/dvi.c      |   35 +++----
 drivers/video/via/hw.c       |   84 +++++++++++++-----
 drivers/video/via/hw.h       |    4 
 drivers/video/via/ioctl.h    |    2 
 drivers/video/via/lcd.c      |   29 ++++--
 drivers/video/via/lcd.h      |    2 
 drivers/video/via/share.h    |    8 +
 ...
[ message continues ]

This was part of Harald's "make viafb a first-class citizen using
pci_driver" patch, but somehow got dropped when that patch went into
mainline.

Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
 drivers/video/via/viafbdev.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 91bfe6d..4a34d4f 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -1991,7 +1991,7 @@ static int __devinit via_pci_probe(struct pci_dev *pdev,
 		if (!viafbinfo1) {
 			printk(KERN_ERR
 			"allocate the second framebuffer struct error\n");
-			goto out_delete_i2c;
+			goto out_unmap_screen;
 		}
 		viaparinfo1 = viafbinfo1->par;
 		memcpy(viaparinfo1, viaparinfo, viafb_par_length);
@@ -2086,6 +2086,8 @@ out_dealloc_cmap:
 out_fb1_release:
 	if (viafbinfo1)
 		framebuffer_release(viafbinfo1);
+out_unmap_screen:
+	iounmap(viafbinfo->screen_base);
 out_delete_i2c:
 	viafb_delete_i2c_buss(viaparinfo);
 out_fb_release:
-- 
1.7.0.1

--

[ message continues ]

Well it was dropped because the patch introducing the goto_error_out 
logic wasn't backported that time because I planned to rewrite the 
framebuffer initialization to use a common function for multiple 
framebuffers.
As we now (due to your previous patches) have this logic it looks good 
to me.


Thanks,


--

[ message continues ]

Commit c3e25673843153ea75fda79a47cf12f10a25ca37 (viafb: 2D engine rewrite)
changed the setting of the GEMODE register so that the reserved bits are no
longer preserved.  Fix that; at the same time, move this code to its own
function and restore the use of symbolic constants.

Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
 drivers/video/via/accel.c |   48 ++++++++++++++++++++++++++++++---------------
 1 files changed, 32 insertions(+), 16 deletions(-)

diff --git a/drivers/video/via/accel.c b/drivers/video/via/accel.c
index d5077df..78c0a2b 100644
--- a/drivers/video/via/accel.c
+++ b/drivers/video/via/accel.c
@@ -165,12 +165,41 @@ static int hw_bitblt_1(void __iomem *engine, u8 op, u32 width, u32 height,
 	return 0;
 }
 
+/*
+ * Figure out an appropriate bytes-per-pixel setting.
+ */
+static int viafb_set_bpp(void __iomem *engine, u8 bpp)
+{
+	u32 gemode;
+
+	/* Preserve the reserved bits */
+	gemode = readl(engine + VIA_REG_GEMODE) & 0xfffffcff;
+	switch (bpp) {
+	case 8:
+		gemode |= VIA_GEM_8bpp;
+		break;
+	case 16:
+		gemode |= VIA_GEM_16bpp;
+		break;
+	case 32:
+		gemode |= VIA_GEM_32bpp;
+		break;
+	default:
+		printk(KERN_WARNING "hw_bitblt_2: Unsupported bpp %d\n", bpp);
+		return -EINVAL;
+	}
+	writel(gemode, engine + VIA_REG_GEMODE);
+	return 0;
+}
+
+
 static int hw_bitblt_2(void __iomem *engine, u8 op, u32 width, u32 height,
 	u8 dst_bpp, u32 dst_addr, u32 dst_pitch, u32 dst_x, u32 dst_y,
 	u32 *src_mem, u32 src_addr, u32 src_pitch, u32 src_x, u32 src_y,
 	u32 fg_color, u32 bg_color, u8 fill_rop)
 {
 	u32 ge_cmd = 0, tmp, i;
+	int ret;
 
 	if (!op || op > 3) {
 		printk(KERN_WARNING "hw_bitblt_2: Invalid operation: %d\n", op);
@@ -204,22 +233,9 @@ static int hw_bitblt_2(void __iomem *engine, u8 op, u32 width, u32 height,
 		}
 	}
 
-	switch (dst_bpp) {
-	case 8:
-		tmp = 0x00000000;
-		break;
-	case 16:
-		tmp = 0x00000100;
-		break;
-	case 32:
-		tmp = 0x00000300;
-		break;
-	default:
-		printk(KERN_WARNING ...
[ message continues ]

Hi Jon,


in your later patch "[PATCH 06/16] viafb: complete support for 
VX800/VX855 accelerated framebuffer" you reintroduce initializing those 
bits to 0. That's fine but I can't see a reason for preserving this bits 
here as it adds useless overhead unless the hardware itself changed some 
of those bits and behaves differently according to those bits. 
Additionally the first 2 bits are not reserved but provide a rotation 
where 00 is what we want (no rotation).
And if you rip code off hw_bitblt_2 it would be better to do the same 
with hw_bitblt_1. A quick look reveals that the same function can be 
used there (the error message would need to be adjusted but that's minor).
So nack@preserving (unless it would cause problems otherwise) but 
ack@ripping code off and sharing between hw_bitblt_1 & hw_bitblt_2.


Thanks,


--

[ message continues ]

On Fri, 09 Apr 2010 05:07:34 +0200

Somehow the cost of an additional MMIO read at mode setting time is
just not going to keep me up at night.

I will admit that I've learned to be rather superstitious when it comes
to messing with reserved bits.  Hardware designers like to hide
functionality like "bring down the wrath of the gods" behind such
bits.  The old code preserved them and worked, so I did the same.  I


That had crossed my mind; there is quite a bit of duplicated code
between those two very long functions.  At the time I was focused on
making things work, and I didn't want to mess with code that I couldn't
actually test.  So further cleanup is on my list, but I would prefer to
defer it for a little bit.

Thanks,

jon
--

[ message continues ]

Hi Jon,


Well it's not only mode setting its for each hardware accelerated 

...if you insist on it its okay with me. I still disagree but its 

The code (and the spec regarding the reserved bits also) is obviously 
identical so please don't ignore it. If you decide to put it in a 
separate function please do so for both blit engines especially if they 
really do the same as in this case. As you say they are mostly identical 
and that's by design. Please keep them in sync if possible. They exist 
that way to be a stateless and to avoid cluttering if's around.
(no need to say that I'll test those patches on my CLE266 and VX800 as 
soon as they apply cleanly to mainline)


Thanks,

Florian Tobias Schandinat
--

[ message continues ]

On Fri, 09 Apr 2010 22:23:06 +0200

In fact, I already came to this conclusion and have added a patch to
have both functions use the same code.

Thanks,

jon
--

[ message continues ]

From: Harald Welte <laforge@gnumonks.org>

The current code executed from module_init() in viafb does not have
proper error checking and [partial] resoure release paths in case
an error happens half way through driver initialization.

This patch adresses the most obvious of those issues, such as a
leftover i2c bus if module_init (and thus module load) fails.

[jc: fixed merge conflicts]
Signed-off-by: Harald Welte <HaraldWelte@viatech.com>
---
 drivers/video/via/viafbdev.c |   52 ++++++++++++++++++++++++++++++-----------
 1 files changed, 38 insertions(+), 14 deletions(-)

diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 3028e7d..91bfe6d 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -1,5 +1,5 @@
 /*
- * Copyright 1998-2008 VIA Technologies, Inc. All Rights Reserved.
+ * Copyright 1998-2009 VIA Technologies, Inc. All Rights Reserved.
  * Copyright 2001-2008 S3 Graphics, Inc. All Rights Reserved.
 
  * This program is free software; you can redistribute it and/or
@@ -1847,7 +1847,7 @@ static int __devinit via_pci_probe(struct pci_dev *pdev,
 				   const struct pci_device_id *ent)
 {
 	u32 default_xres, default_yres;
-	int vmode_index;
+	int rc, vmode_index;
 	u32 viafb_par_length;
 
 	DEBUG_MSG(KERN_INFO "VIAFB PCI Probe!!\n");
@@ -1862,7 +1862,7 @@ static int __devinit via_pci_probe(struct pci_dev *pdev,
 		&pdev->dev);
 	if (!viafbinfo) {
 		printk(KERN_ERR"Could not allocate memory for viafb_info.\n");
-		return -ENODEV;
+		return -ENOMEM;
 	}
 
 	viaparinfo = (struct viafb_par *)viafbinfo->par;
@@ -1886,7 +1886,9 @@ static int __devinit via_pci_probe(struct pci_dev *pdev,
 		viafb_dual_fb = 0;
 
 	/* Set up I2C bus stuff */
-	viafb_create_i2c_bus(viaparinfo);
+	rc = viafb_create_i2c_bus(viaparinfo);
+	if (rc)
+		goto out_fb_release;
 
 	viafb_init_chip_info(pdev, ent);
 	viaparinfo->fbmem = pci_resource_start(pdev, 0);
@@ -1897,7 +1899,8 @@ static int __devinit via_pci_probe(struct pci_dev ...
[ message continues ]

I don't know whether this is right (changing the return code) as Andrew 
recommend a while ago:
"It should return -ENOMEM rather than -1, but that's minor."

rc = -ENOMEM;

Otherwise it looks okay.


Thanks,

Florian Tobias Schandinat
--

[ message continues ]

On Thu, 08 Apr 2010 20:22:57 +0200

To me it seems like -ENOMEM could be a bit confusing here; there's a lot of
things that could go wrong with that same error return.

That said, I did some digging around, and -ENOMEM does seem to be the

Indeed.  Fixed.

Thanks,

jon
--

[ message continues ]

From: Harald Welte <laforge@gnumonks.org>

This will help us for the upcoming support for 2D acceleration using
the M1 engine.

[jc: fixed merge conflicts]
Signed-off-by: Harald Welte <HaraldWelte@viatech.com>
---
 drivers/video/via/chip.h |    8 ++++++++
 drivers/video/via/hw.c   |   15 +++++++++++++++
 2 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/drivers/video/via/chip.h b/drivers/video/via/chip.h
index 474f428..f799e2c 100644
--- a/drivers/video/via/chip.h
+++ b/drivers/video/via/chip.h
@@ -122,9 +122,17 @@ struct lvds_chip_information {
 	int i2c_port;
 };
 
+/* The type of 2D engine */
+enum via_2d_engine {
+	VIA_2D_ENG_H2,
+	VIA_2D_ENG_H5,
+	VIA_2D_ENG_M1,
+};
+
 struct chip_information {
 	int gfx_chip_name;
 	int gfx_chip_revision;
+	enum via_2d_engine twod_engine;
 	struct tmds_chip_information tmds_chip_info;
 	struct lvds_chip_information lvds_chip_info;
 	struct lvds_chip_information lvds_chip_info2;
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index f2e4bda..963704e 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -2034,6 +2034,21 @@ static void init_gfx_chip_info(struct pci_dev *pdev,
 				CX700_REVISION_700;
 		}
 	}
+
+	/* Determine which 2D engine we have */
+	switch (viaparinfo->chip_info->gfx_chip_name) {
+	case UNICHROME_VX800:
+	case UNICHROME_VX855:
+		viaparinfo->chip_info->twod_engine = VIA_2D_ENG_M1;
+		break;
+	case UNICHROME_K8M890:
+	case UNICHROME_P4M900:
+		viaparinfo->chip_info->twod_engine = VIA_2D_ENG_H5;
+		break;
+	default:
+		viaparinfo->chip_info->twod_engine = VIA_2D_ENG_H2;
+		break;
+	}
 }
 
 static void init_tmds_chip_info(void)
-- 
1.7.0.1

--

[ message continues ]

That's probably a good idea (although most things are already done in 
the separate blitting functions).
Just a minor nit:
Could we change the default so that if someone adds support for a new 
IGP (and misses this function) we default to either the newest or 
preferably to none? I've just seen too much poorly maintained code in 
this driver and defaulting to the oldest is hence a bad idea.
Otherwise it's fine.


Thanks,


--

[ message continues ]

On Fri, 09 Apr 2010 05:20:28 +0200

That would require making an exhaustive list of older chipset types.
It could probably be inferred through inspection of the code, but I
worry about making assumptions in this area...

Thanks,

jon
--

[ message continues ]

Such list already exists. gfx_chip_name = pdi->driver_data in hw.c (and 
only there) so what is needed is the list viafb_pci_table in viafbdev.c 
(relatively at the end) of all chips:
UNICHROME_CLE266
UNICHROME_PM800
UNICHROME_K400
UNICHROME_K800
UNICHROME_CN700
UNICHROME_K8M890
UNICHROME_CX700
UNICHROME_P4M900
UNICHROME_CN750
UNICHROME_VX800
UNICHROME_VX855

Would appreciate it if you could use this info.


Thanks,

Florian Tobias Schandinat
--

[ message continues ]

[Getting back to the older stuff...]

On Fri, 09 Apr 2010 22:34:16 +0200

I've spent a bit of time looking at this.  What's really needed is a
better way of abstracting the chip types so that we can maybe get rid
of all those switch statements throughout the driver.  For the purposes
of getting this work in, I'm not quite prepared to make that change,
though I could certainly consider doing it in the future.

In the absence of that, the only course of action which makes sense is
to simply fail the initialization if an unknown chip type shows up
there.  That's easy, and I can do it.  But, given that this was a
"minor nit," can we leave it as-is for now?  There's a *lot* of things
to clean up in this driver, I'd like to make it better a step at a time
rather than trying to do the whole thing at once.

Thanks,

jon
--

[ message continues ]

Yes, if you  feel too uncomfortable with changing it and agree that the 
whole stuff should be made more maintainable later on I am okay with 
 > better a step at a time rather than trying to do the whole thing at once.

This is indeed very true.


Thanks,

Florian Tobias Schandinat
--

[ message continues ]

Hi!


i agree with that step by step strategy.

I always felt conservative about making too big changes.  After all, it is hard
to find people who actually own and use all those various models of graphics
chips, and even more so: who want to try + test recent mainline and check for
regressions :(

VIA's resources are extremely limited, and they can barely complete the work
required for new products...  I know it's unfortunate, but VIA is a very small
company.

Regards,
	Harald
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
--

[ message continues ]

From: Deepak Saxena <dsaxena@laptop.org>

The existing code in VIAFB, taken from the openchrome driver,
causes the system to lock up upon moving the mouse pointer. This
patch uses the selective register restore from the official
VIA driver to keep this from happening.

This fixes http://dev.laptop.org/ticket/9565

[jc: extensive reworking to merge with 2.6.34 and to deal with some
 coding issues.  This code still needs improvement, though; that will
 come in a later patch.]

Signed-off-by: Deepak Saxena <dsaxena@laptop.org>
---
 drivers/video/via/viafbdev.c |   79 +++++++++++++++++++++++++++++++++++++++---
 drivers/video/via/viafbdev.h |   76 +++++++++++++++++++++++++++++++++++++++-
 2 files changed, 148 insertions(+), 7 deletions(-)

diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 5a5964f..56d5416 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -1850,9 +1850,9 @@ static int viafb_suspend(struct pci_dev *pdev, pm_message_t state)
 	if (state.event == PM_EVENT_SUSPEND) {
 		acquire_console_sem();
 
-		memcpy_fromio(viaparinfo->shared->saved_regs,
+		memcpy_fromio(&viaparinfo->shared->saved_video_regs,
 			      viaparinfo->shared->engine_mmio + 0x100,
-			      0x100 * sizeof(u32));
+			      sizeof(struct via_video_regs));
 
 		fb_set_suspend(viafbinfo, 1);
 
@@ -1869,6 +1869,10 @@ static int viafb_suspend(struct pci_dev *pdev, pm_message_t state)
 
 static int viafb_resume(struct pci_dev *pdev)
 {
+	volatile struct via_video_regs  *viaVidEng =
+		(volatile struct via_video_regs *)(viaparinfo->shared->engine_mmio + 0x200);
+	struct via_video_regs  *localVidEng = &viaparinfo->shared->saved_video_regs;
+
 	acquire_console_sem();
 	pci_set_power_state(pdev, PCI_D0);
 	pci_restore_state(pdev);
@@ -1876,9 +1880,74 @@ static int viafb_resume(struct pci_dev *pdev)
     		goto fail;
 	pci_set_master(pdev);
 
-	memcpy_toio(viaparinfo->shared->engine_mmio + 0x100,
-		    viaparinfo->shared->saved_regs,
-		 ...
[ message continues ]

From: Harald Welte <laforge@gnumonks.org>

This patch alters viafb to use the proper Linux in-kernel API to access
PCI configuration space, rather than poking at I/O ports by itself.

Signed-off-by: Harald Welte <HaraldWelte@viatech.com>
---
 drivers/video/via/hw.c |   64 +++++++++++++++++++++++++++++------------------
 drivers/video/via/hw.h |    4 +-
 2 files changed, 41 insertions(+), 27 deletions(-)

diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index ea0f8ec..f2e4bda 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -2542,24 +2542,37 @@ static void disable_second_display_channel(void)
 	viafb_write_reg_mask(CR6A, VIACR, BIT6, BIT6);
 }
 
+static u_int16_t via_function3[] = {
+	CLE266_FUNCTION3, KM400_FUNCTION3, CN400_FUNCTION3, CN700_FUNCTION3,
+	CX700_FUNCTION3, KM800_FUNCTION3, KM890_FUNCTION3, P4M890_FUNCTION3,
+	P4M900_FUNCTION3, VX800_FUNCTION3, VX855_FUNCTION3,
+};
+
+/* Get the BIOS-configured framebuffer size from PCI configuration space
+ * of function 3 in the respective chipset */
 int viafb_get_fb_size_from_pci(void)
 {
-	unsigned long configid, deviceid, FBSize = 0;
-	int VideoMemSize;
-	int DeviceFound = false;
-
-	for (configid = 0x80000000; configid < 0x80010800; configid += 0x100) {
-		outl(configid, (unsigned long)0xCF8);
-		deviceid = (inl((unsigned long)0xCFC) >> 16) & 0xffff;
-
-		switch (deviceid) {
-		case CLE266:
-		case KM400:
-			outl(configid + 0xE0, (unsigned long)0xCF8);
-			FBSize = inl((unsigned long)0xCFC);
-			DeviceFound = true;	/* Found device id */
-			break;
+	int i;
+	u_int8_t offset = 0;
+	u_int32_t FBSize;
+	u_int32_t VideoMemSize;
+
+	/* search for the "FUNCTION3" device in this chipset */
+	for (i = 0; i < ARRAY_SIZE(via_function3); i++) {
+		struct pci_dev *pdev;
+
+		pdev = pci_get_device(PCI_VENDOR_ID_VIA, via_function3[i],
+				      NULL);
+		if (!pdev)
+			continue;
+
+		DEBUG_MSG(KERN_INFO "Device ID = %x\n", pdev->device);
 
+		switch (pdev->device) {
+		case ...
[ message continues ]

Hi,

something I am wondering about is whether we can't simply do:
viaparinfo->memsize = pci_resource_len(pdev, 0);
I suppose that this is not possible meaning that the pci len can be 
longer than the actual memory but I just wanted to use the moment to 
make sure.


Would it be possible to replace this loop with a lookup table that uses 
the fact that we already know which IGP we have?

This function was not designed to return an error (memsize is not 
checked). Either return a default value (let's say 8MB) or add a check 

Thanks,

Florian Tobias Schandinat
--

[ message continues ]

On Thu, 08 Apr 2010 20:42:17 +0200

That would make sense.  But if somebody who is closer to the hardware than

That's a good point.  I put in a check.

Thanks,

jon
--

[ message continues ]

Hi Jon + Florian,


I believe it is not safe to simply use the pci_resource_len(pdev, 0).

At least in some of the hardware I've been working with in the past, the
PCI resource length was always fixed, independent of how large the BIOS
configured the shared video memory.

So please don't use that method.

Regards,
	Harald
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
--

[ message continues ]

The code is only known to work there, and is strongly suspected to not work
on other chipsets.

Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
 drivers/video/via/viafbdev.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index f834440..2e70c79 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -1916,6 +1916,12 @@ static int viafb_suspend(struct pci_dev *pdev, pm_message_t state)
 	int i;
 	void __iomem *iomem = viaparinfo->shared->engine_mmio;
 
+/*
+ * This code is currently only known to work on VX855
+ */
+	if (viaparinfo->shared->chip_info.gfx_chip_name != UNICHROME_VX855)
+		return -ENOTSUPP;
+
 	if (state.event == PM_EVENT_SUSPEND) {
 		acquire_console_sem();
 
@@ -1940,6 +1946,12 @@ static int viafb_resume(struct pci_dev *pdev)
 	int i;
 	void __iomem *iomem = viaparinfo->shared->engine_mmio;
 
+/*
+ * This code is currently only known to work on VX855
+ */
+	if (viaparinfo->shared->chip_info.gfx_chip_name != UNICHROME_VX855)
+		return -ENOTSUPP;
+
 	acquire_console_sem();
 	pci_set_power_state(pdev, PCI_D0);
 	pci_restore_state(pdev);
-- 
1.7.0.1

--

[ message continues ]

Eliminate volatile pointers and direct dereferencing of iomem
pointers.  In terms of register operations it should be the same as
before.

Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
 drivers/video/via/viafbdev.c |  142 +++++++++++++++++++++++-------------------
 drivers/video/via/viafbdev.h |   74 ----------------------
 2 files changed, 77 insertions(+), 139 deletions(-)

diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 684a5c4..f834440 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -1845,14 +1845,82 @@ out_default:
 
 
 #ifdef CONFIG_PM
+/*
+ * The registers to save and restore, listed in the requisite order.  This
+ * is an adaption of Deepak Saxena's suspend/restore code, which had been
+ * annotated thusly:
+ *
+ * Following set of register restores is black magic takend
+ * from the VIA X driver. Most of it is from the LeaveVT() and
+ * EnterVT() path and some is gleaned by looking at other bits
+ * of code to figure out what registers to touch.
+ */
+static const u32 via_regs_to_save[] = {
+	0x208,	/* Alpha win/hardware icon location start */
+	0x20c,	/* " location end */
+	0x210,	/* Alpha window control */
+	0x21c,	/* Alpha stream frame buffer stride */
+	0x220,	/* Primary display color key */
+	0x224,	/* Alpha window/hardware icon FB start */
+	0x228,	/* Chroma key lower bound */
+	0x22c,	/* Chroma key upper bound */
+	0x230,	/* Video stream 1 control */
+	0x234,	/* Video window 1 fetch count */
+	0x238,	/* VW1 fetch buffer Y start address 1 */
+	0x23c,	/* VW1 FB stride */
+	0x240,	/* VW1 starting location */
+	0x244,	/* VW1 ending location */
+	0x248,	/* VW1 FB Y starting address 2 */
+	0x24c,	/* VW1 display zoom control */
+	0x250,	/* VW1 minify & interpolation control */
+	0x254,	/* VW1 FB Y starting address 0 */
+	0x258,	/* VW1 FIFO depth and threshold control */
+	0x25c,	/* VW1 starting location offset */
+	0x26c,	/* VW1 display count on screen control */
+	0x284,	/* VW1 ...
[ message continues ]

From: Deepak Saxena <dsaxena@laptop.org>

Signed-off-by: Deepak Saxena <dsaxena@laptop.org>
---
 drivers/video/via/viafbdev.c |    9 ---------
 1 files changed, 0 insertions(+), 9 deletions(-)

diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 56d5416..684a5c4 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -1940,15 +1940,6 @@ static int viafb_resume(struct pci_dev *pdev)
 	viaVidEng->cursor_bg = localVidEng->cursor_bg;
 	viaVidEng->cursor_fg = localVidEng->cursor_fg;
 
-	/*
-	 * Magic register dance to  make cursor reappear.
-	 *
-	 * Currently hardcoded settings need to clean this all
-	 * up later...
-	 */
-	viaVidEng->hi_control = 0xb6000005;
-	viaVidEng->compose   |= 0xc0000000;
-
 	fb_set_suspend(viafbinfo, 0);
 
 fail:
-- 
1.7.0.1

--

[ message continues ]

From: Deepak Saxena <dsaxena@laptop.org>

This patch adds minimal support for suspend/resume of the
VIA framebuffer device. It requires a version of OFW
that restores the video mode.

This patch is OLPC-specific as the proper upstream solution
is to move the VIA video path to using the kernel modesetting
infrastructure and doing a proper save/restore in the kernel.

[jc: extensive changes for 2.6.34 merge]
Signed-off-by: Deepak Saxena <dsaxena@laptop.org>
---
 drivers/video/via/viafbdev.c |   51 ++++++++++++++++++++++++++++++++++++++++++
 drivers/video/via/viafbdev.h |    3 ++
 2 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index ea3018e..88298e1 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -1843,6 +1843,53 @@ out_default:
 	*yres = 480;
 }
 
+
+#ifdef CONFIG_PM
+static int viafb_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+	if (state.event == PM_EVENT_SUSPEND) {
+		acquire_console_sem();
+
+		memcpy_fromio(viaparinfo->shared->saved_regs,
+			      viaparinfo->shared->engine_mmio + 0x100,
+			      0xff * sizeof(u32));
+
+		fb_set_suspend(viafbinfo, 1);
+
+		viafb_sync(viafbinfo);
+
+		pci_save_state(pdev);
+		pci_disable_device(pdev);
+		pci_set_power_state(pdev, pci_choose_state(pdev, state));
+		release_console_sem();
+	}
+
+	return 0;
+}
+
+static int viafb_resume(struct pci_dev *pdev)
+{
+	acquire_console_sem();
+	pci_set_power_state(pdev, PCI_D0);
+	pci_restore_state(pdev);
+	if (pci_enable_device(pdev))
+    		goto fail;
+	pci_set_master(pdev);
+
+	memcpy_toio(viaparinfo->shared->engine_mmio + 0x100,
+		    viaparinfo->shared->saved_regs,
+		    0x100 * sizeof(u32));
+
+	fb_set_suspend(viafbinfo, 0);
+
+fail:
+	release_console_sem();
+	return 0;
+}
+
+#endif
+
+
 static int __devinit via_pci_probe(struct pci_dev *pdev,
 				   const struct pci_device_id *ent)
 {
@@ -2219,6 +2266,10 @@ static struct pci_driver ...
[ message continues ]

From: Paul Fox <pgf@laptop.org>

---
 drivers/video/via/via_i2c.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/video/via/via_i2c.c b/drivers/video/via/via_i2c.c
index 18bbbdd..86e6e8d 100644
--- a/drivers/video/via/via_i2c.c
+++ b/drivers/video/via/via_i2c.c
@@ -26,7 +26,7 @@ static void via_i2c_setscl(void *data, int state)
 	u8 val;
 	struct via_i2c_adap_cfg *adap_data = data;
 
-	printk(KERN_DEBUG "reading index 0x%02x from IO 0x%x\n",
+	DEBUG_MSG(KERN_DEBUG "reading index 0x%02x from IO 0x%x\n",
 		adap_data->ioport_index, adap_data->io_port);
 	val = viafb_read_reg(adap_data->io_port,
 			     adap_data->ioport_index) & 0xF0;
@@ -140,7 +140,7 @@ static int create_i2c_bus(struct i2c_adapter *adapter,
 			  struct via_i2c_adap_cfg *adap_cfg,
 			  struct pci_dev *pdev)
 {
-	printk(KERN_DEBUG "viafb: creating bus adap=0x%p, algo_bit_data=0x%p, adap_cfg=0x%p\n", adapter, algo, adap_cfg);
+	DEBUG_MSG(KERN_DEBUG "viafb: creating bus adap=0x%p, algo_bit_data=0x%p, adap_cfg=0x%p\n", adapter, algo, adap_cfg);
 
 	algo->setsda = via_i2c_setsda;
 	algo->setscl = via_i2c_setscl;
@@ -182,7 +182,7 @@ static struct via_i2c_adap_cfg adap_configs[] = {
 int viafb_create_i2c_busses(struct viafb_par *viapar)
 {
 	int i, ret;
-	printk(KERN_DEBUG "%s: entering\n", __FUNCTION__);
+	DEBUG_MSG(KERN_DEBUG "%s: entering\n", __FUNCTION__);
 
 	for (i = 0; i < VIAFB_NUM_I2C; i++) {
 		struct via_i2c_adap_cfg *adap_cfg = &adap_configs[i];
-- 
1.7.0.1

--

[ message continues ]

This patch is fine.


Thanks,

Florian Tobias Schandinat


--

[ message continues ]

From: Harald Welte <laforge@gnumonks.org>

This patch changes the way how the various I2C busses are used internally
inside the viafb driver:  Previosuly, only a single i2c_adapter was created,
even thougt two different hardware I2C busses are accessed: A structure member
in a global variable was modified to indicate the bus to be used.

Now, all existing hardware busses are registered with the i2c core, and the
viafb_i2c_{read,write}byte[s]() function take the adapter number as function
call parameter, rather than referring to the global structure member.

[jc: even more painful merge with mainline changes ->2.6.34]
[jc: painful merge with OLPC changes]

Signed-off-by: Harald Welte <HaraldWelte@viatech.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
 drivers/video/via/dvi.c      |   35 ++++-----
 drivers/video/via/lcd.c      |   15 ++--
 drivers/video/via/via_i2c.c  |  172 ++++++++++++++++++++++++++----------------
 drivers/video/via/via_i2c.h  |   43 +++++++----
 drivers/video/via/viafbdev.c |    6 +-
 drivers/video/via/viafbdev.h |    4 +-
 drivers/video/via/vt1636.c   |   36 ++++-----
 drivers/video/via/vt1636.h   |    2 +-
 8 files changed, 181 insertions(+), 132 deletions(-)

diff --git a/drivers/video/via/dvi.c b/drivers/video/via/dvi.c
index 67b3693..00d001e 100644
--- a/drivers/video/via/dvi.c
+++ b/drivers/video/via/dvi.c
@@ -96,7 +96,7 @@ int viafb_tmds_trasmitter_identify(void)
 	viaparinfo->chip_info->tmds_chip_info.tmds_chip_name = VT1632_TMDS;
 	viaparinfo->chip_info->
 		tmds_chip_info.tmds_chip_slave_addr = VT1632_TMDS_I2C_ADDR;
-	viaparinfo->chip_info->tmds_chip_info.i2c_port = I2CPORTINDEX;
+	viaparinfo->chip_info->tmds_chip_info.i2c_port = VIA_I2C_ADAP_31;
 	if (check_tmds_chip(VT1632_DEVICE_ID_REG, VT1632_DEVICE_ID) != FAIL) {
 		/*
 		 * Currently only support 12bits,dual edge,add 24bits mode later
@@ -110,7 +110,7 @@ int viafb_tmds_trasmitter_identify(void)
 			  viaparinfo->chip_info->tmds_chip_info.i2c_port);
 		return OK;
 	} else ...
[ message continues ]

I don't know I2C too well and this patch has certainly its issues (the 
FIXMEs, the hardcoded VIAFB_NUM_I2C, probably others) but in general it 
looks okay. Therefore I think it should be merged and the issues should 
be fixed afterwards.


Thanks,


--

[ message continues ]

From: Paul Fox <pgf@laptop.org>

Signed-off-by: Paul Fox <pgf@laptop.org>
---
 drivers/video/via/viafbdev.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 88298e1..5a5964f 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -1852,7 +1852,7 @@ static int viafb_suspend(struct pci_dev *pdev, pm_message_t state)
 
 		memcpy_fromio(viaparinfo->shared->saved_regs,
 			      viaparinfo->shared->engine_mmio + 0x100,
-			      0xff * sizeof(u32));
+			      0x100 * sizeof(u32));
 
 		fb_set_suspend(viafbinfo, 1);
 
-- 
1.7.0.1

--

[ message continues ]

From: Chris Ball <cjb@laptop.org>

The i2c transactions involved in detecting LVDS (9 seconds) and TMDS
(16 seconds) add an extra 25 seconds to viafb load time on the XO-1.5.

[jc: minor merge conflict fixed]
Signed-off-by: Chris Ball <cjb@laptop.org>
---
 drivers/video/via/hw.c  |    4 ++++
 drivers/video/via/lcd.c |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 7be462e..47ba09a 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -2054,6 +2054,10 @@ static void init_gfx_chip_info(struct pci_dev *pdev,
 
 static void init_tmds_chip_info(void)
 {
+#ifdef CONFIG_OLPC_XO_1_5
+	if (machine_is_olpc())
+		return;
+#endif
 	viafb_tmds_trasmitter_identify();
 
 	if (INTERFACE_NONE == viaparinfo->chip_info->tmds_chip_info.
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index e0e2310..37a9746 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -208,6 +208,10 @@ static bool lvds_identify_integratedlvds(void)
 
 int viafb_lvds_trasmitter_identify(void)
 {
+#ifdef CONFIG_OLPC_XO_1_5
+	if (machine_is_olpc())
+		return FAIL;
+#endif
 	viaparinfo->shared->i2c_stuff.i2c_port = I2CPORTINDEX;
 	if (viafb_lvds_identify_vt1636()) {
 		viaparinfo->chip_info->lvds_chip_info.i2c_port = I2CPORTINDEX;
-- 
1.7.0.1

--

[ message continues ]

I don't like the idea of OLPC specific code. Isn't there any way to 
speed this up in general?
There is not yet even an option for OLPC_XO_1_5 (in contrast to 
CONFIG_OLPC) in mainline. Is such a thing planned?
I can't really see anything that would speak for accepting this patch 
now in current mainline, sorry.


Thanks,


--

[ message continues ]

On Fri, 09 Apr 2010 23:40:55 +0200

Architecture-specific code happens.  OLPCs are wired differently; if
you go trying to do LVDS out those GPIO ports on an OLPC, you'll not
end up talking to the hardware you think you're talking to.  The best

Yes, it is.  That's part of the remaining OLPC support code which has

If you can come up with a better solution to the problem, I'm all
ears.  But without it you'll have a hard time running mainline kernels
on XO 1.5 systems.  It is all coming, but the OLPC folks are scrambling
to get everything together; I don't think we really need to make things
harder for them.

That said, machine_is_olpc() is properly defined for all
configurations, so the #ifdefs can (and should) come out.

jon
--

[ message continues ]

Sadly no as you probably know the OLPC hardware much better than me.

I'm not sure I get you right here. If you talk about removing the 
defines and only letting the machine check that is something that I 
would accept now. If this is not what you meant I think it would be 
better to move this patch to the series adding the config option.


Thanks,

Florian Tobias Schandinat
--

[ message continues ]

On Sat, 10 Apr 2010 02:42:52 +0200

Yes, that is what I mean; the ifdefs don't need to be there.  Had I
thought that through I would have removed them before posting the patch.

jon
--

[ message continues ]

Hi Florian,



I think there is little choice in this matter.  It is a _very_ uncommon
hardware design decision to attach anything but the DDC to one of the
I2C ports of the graphics chip, and the assumption that there is only
DDC connected is made in VIA's BIOS (not used in OLPC), the linux
framebuffer driver, as well as VIA's own Xorg driver and I believe as
well in OpenChrome, too :(

OLPC has told me that the particular chip that is attached to I2C is
also very timing sensitive and not 100% I2C compliant, so I think it is
the safe choice to not try to do DDC on that port for the OLPC 1.5.

-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
--

[ message continues ]

From: Chris Ball <cjb@laptop.org>

[jc: extensive merge conflict fixes]
Signed-off-by: Chris Ball <cjb@laptop.org>
---
 drivers/video/via/hw.c      |    1 +
 drivers/video/via/ioctl.h   |    2 +-
 drivers/video/via/lcd.c     |   10 ++++++++++
 drivers/video/via/lcd.h     |    2 ++
 drivers/video/via/share.h   |    8 ++++++++
 drivers/video/via/viamode.c |   14 ++++++++++++++
 6 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 963704e..7be462e 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -63,6 +63,7 @@ static struct pll_map pll_value[] = {
 	 CX700_52_977M,	VX855_52_977M},
 	{CLK_56_250M, CLE266_PLL_56_250M, K800_PLL_56_250M,
 	 CX700_56_250M, VX855_56_250M},
+	{CLK_57_275M, 0, 0, 0, VX855_57_275M},
 	{CLK_60_466M, CLE266_PLL_60_466M, K800_PLL_60_466M,
 	 CX700_60_466M, VX855_60_466M},
 	{CLK_61_500M, CLE266_PLL_61_500M, K800_PLL_61_500M,
diff --git a/drivers/video/via/ioctl.h b/drivers/video/via/ioctl.h
index de89980..c430fa2 100644
--- a/drivers/video/via/ioctl.h
+++ b/drivers/video/via/ioctl.h
@@ -75,7 +75,7 @@
 /*SAMM operation flag*/
 #define OP_SAMM            0x80
 
-#define LCD_PANEL_ID_MAXIMUM	22
+#define LCD_PANEL_ID_MAXIMUM	23
 
 #define STATE_ON            0x1
 #define STATE_OFF           0x0
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 71e3200..e0e2310 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -456,6 +456,16 @@ static int fp_id_to_vindex(int panel_id)
 		viaparinfo->lvds_setting_info->LCDDithering = 1;
 		return VIA_RES_480X640;
 		break;
+	case 0x17:
+		/* OLPC XO-1.5 panel */
+		viaparinfo->lvds_setting_info->lcd_panel_hres = 1200;
+		viaparinfo->lvds_setting_info->lcd_panel_vres = 900;
+		viaparinfo->lvds_setting_info->lcd_panel_id =
+			LCD_PANEL_IDD_1200X900;
+		viaparinfo->lvds_setting_info->device_lcd_dualedge = 0;
+		viaparinfo->lvds_setting_info->LCDDithering = 0;
+		return ...
[ message continues ]

What will happen if someone with no VX855 will try to enter 1200x900 
mode? Probably the world won't be destroyed but I have a really ugly 
feeling that the driver is not well prepared for this situation. Haven't 
tested yet as I'm waiting for the official forward port but I think it 
might be better to reschedule this patch for later or add some PLL 
values that are supposed to work (using/executing the formulas in the 
VIA open source X driver)
Otherwise it looks fine.


Thanks,


--

[ message continues ]

On Fri, 09 Apr 2010 23:27:30 +0200

OK, I'm certainly exposing my relative lack of understanding of
framebuffer issues (I'm here to add a camera driver, remember? :),
but...is this really something that older chipsets can't handle?  Or is

If it's really not acceptable, then it will stay out, but I would
rather get it merged.  I will leave it in the series for now; it can
come out later if need be.

Thanks,

jon
--

[ message continues ]

It's not the chipsets that are incapable (AFAIK) it's just that the 
patch is only adding the right PLL values for frequency generation for 
VX855 and set the values for all other chipsets to 0. Yeah that means 
this panel size wasn't supported before (by the driver). 0 is certainly 
not what we want and I think about replacing this whole fixed table with 
the formulas used in VIAs OpenSource X driver (although those are a bit 
more complicated I expected when I looked at unichrome). However this 
will certainly be a big change that needs a lot of thought and testing 
so nothing that will happen very soon.
I am just worried what will happen if one tries to set this mode with an 

Yeah please leave it in the series for now. I'd just appreciate it very 
much if one were to generate the missing values before this gets into 
mainline....or replacing this hardcoded values.


Thanks,

Florian Tobias Schandinat
--

[ message continues ]

This patch is a painful merge of change
a90bab567ece3e915d0ccd55ab00c9bb333fa8c0 (viafb: Add support for 2D
accelerated framebuffer on VX800/VX855) in the OLPC tree, originally by
Harald Welte.  Harald's changelog read:

	The VX800/VX820 and the VX855/VX875 chipsets have a different 2D
    	acceleration engine called "M1".  The M1 engine has some subtle
    	(and some not-so-subtle) differences to the previous engines, so
    	support for accelerated framebuffer on those chipsets was disabled
    	so far.

This merge tries to preserve Harald's changes in the framework of the
much-changed 2.6.34 viafb code.

Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
 drivers/video/via/accel.c |   39 +++++++++++++++++++++++++++++++++------
 drivers/video/via/accel.h |   40 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 73 insertions(+), 6 deletions(-)

diff --git a/drivers/video/via/accel.c b/drivers/video/via/accel.c
index 78c0a2b..7fe1c1d 100644
--- a/drivers/video/via/accel.c
+++ b/drivers/video/via/accel.c
@@ -328,6 +328,7 @@ int viafb_init_engine(struct fb_info *info)
 {
 	struct viafb_par *viapar = info->par;
 	void __iomem *engine;
+	int highest_reg, i;
 	u32 vq_start_addr, vq_end_addr, vq_start_low, vq_end_low, vq_high,
 		vq_len, chip_name = viapar->shared->chip_info.gfx_chip_name;
 
@@ -339,6 +340,18 @@ int viafb_init_engine(struct fb_info *info)
 		return -ENOMEM;
 	}
 
+	/* Initialize registers to reset the 2D engine */
+	switch (viapar->shared->chip_info.twod_engine) {
+	case VIA_2D_ENG_M1:
+		highest_reg = 0x5c;
+		break;
+	default:
+		highest_reg = 0x40;
+		break;
+	}
+	for (i = 0; i <= highest_reg; i+= 4)
+		writel(0x0, engine + i);
+
 	switch (chip_name) {
 	case UNICHROME_CLE266:
 	case UNICHROME_K400:
@@ -375,6 +388,8 @@ int viafb_init_engine(struct fb_info *info)
 	switch (chip_name) {
 	case UNICHROME_K8M890:
 	case UNICHROME_P4M900:
+	case UNICHROME_VX800:
+	case UNICHROME_VX855:
 		writel(0x00100000, engine + ...
[ message continues ]

The patch itself looks good. However I have a few minor issues below 

this obsoletes
	/* Init 2D engine reg to reset 2D engine */
	writel(0x0, engine + VIA_REG_KEYCONTROL);

As in the previous patch I'd appreciate a default of
	printk(KERN_ALERT "viafb_xy: FIXME");
I have to admit to be consistent a few switches that are already there 

All of these defines are unused. I admit that it is my fault. I've not 
yet found a way I like to use them as the meaning of the same hardware 
address changed. I think the most clean long term solution would be to 
put the engines in separate files and the definitions in private headers 
to at least avoid the need to decode the engine version in the name.
However as the old headers already contain a bunch of trash feel free to 

Thanks,

Florian Tobias Schandinat
--

[ message continues ]

On Fri, 09 Apr 2010 06:21:18 +0200

Ah, good point, the separate write is superfluous.  Removed.



Harald's initial patch included a mechanism for remapping register writes
on the fly depending on which engine was in use; these defines were used
for that purpose.  Your reworking of the 2D code obliterated that patch,
and made it mostly unnecessary.  I kept the defines around, though, because
I thought that documenting the registers can only be a good thing.

Thanks,

jon
--

[ message continues ]

Hi Jon,


Thanks a lot for your work I appreciate it very much.
However there are 2 things I'd like to ask for:

Could you please forward port them to latest mainline? There went some 
changes in for 2.6.34 that break some of your patches (but not many and 
at least the first conflict is easy to fix) as I generally prefer to 
test a version that does not contain too much changes from myself.


Yeah, that's already a whole bunch of stuff. I agree that it's time to 

At least I'd like to see your work as early as possible so that we can 
avoid conflicts (in patches and design). I hope this will get a bit 
better after viafb is split up.
I don't have a strong opinion on the patch submission route as long as I 
have the possibility to work on viafb and get some patches in as getting 
to far ahead/away from mainline really sucks especially if one has not 
all the hardware to test with. That said I'd be glad if we could 
work/discuss the issues on these patches and get them in the next merge 
window somehow.
Fortunately I still have a bit time left to finish the review of the 
remaining patches in the next days but I would really appreciate it very 
much if you could publish your work more frequently in the future.


Thanks,

--

[ message continues ]

On Fri, 09 Apr 2010 07:43:35 +0200

The OLPC tree is currently based on 2.6.34-rc1.  I forgot that your


Sorry, the only working platform I had was the OLPC 2.6.31 tree, and
there was little point in publishing that by the time it was ready to
be seen.  That said, I *did* point out the tree where the work could be
seen for anybody who was interested.

In any case, it's very much my intent to get this stuff out there and
in for the next merge window.

Thanks for the reviews, I'll get to the specific issues in a bit.

jon
--

[ message continues ]

Well the time I looked in your tree I didn't see any of the remaining 
suspend/resume efforts. Okay perhaps I should have rechecked it now and 
than.
Please correct me if I am wrong but the remaining 6 patches concerning 
suspend&resume look like a real big FIXME. So at the end it is expected 
to work only on VX855 and needs something called OFW?
It doesn't seem to make much sense to review each of them because the 
following patches might or might not correct some of the issues of the 
other. It is really a pain to have 6 patches trying to add a single 
feature. Is there any way to fix this mess. (I assume you didn't merge 
them due to authorship issues?)
I think it might be better to drop those for now and wait for viafb to 
be in a better shape before adding this feature. The mode setting should 
be in a pretty good shape just 1 or 2 kernel versions ahead so that the 
dependency on OFW can be dropped I think.

Sorry but I really think this is not in a shape where merging it is an 
option. I think it would be better to skip those suspend/resume patches 
for the next merge window.


Thanks,

Florian Tobias Schandinat
--

[ message continues ]

On Sat, 10 Apr 2010 01:32:36 +0200

OFW = OpenFirmware.  You could say BIOS instead.  It's pretty normal to

It's true that one needs to look at the end product.  I only looked at
the S/R code recently, and tried to fix some of the biggest issues that

Well, if we want to keep s/r out of tree, we can do that.  It will
complicate the merge of the other stuff, since it's got hooks into the
GPIO and camera code too.  But, like everything else I've posted so
far, it's not the work that I personally set out to do.  I can push
that work on others :)

That said, the suspend/resume support in this patch set makes suspend
work on one chipset, and probably comes pretty close on the others
without breaking anything there.  I don't see the harm in merging it;
it makes the code better than it is now.  I would rather not have to
separate it out from the rest.  But I'll not fight over this one; if
there's real opposition then we can force OLPC to continue to carry it
out of tree.

jon
--

[ message continues ]

At least I'd like some more time (multiple weeks) to have a look at this 
issue & patches and try to come up with improvements that make it likely 
work on other IGPs and eventually not needing any BIOS/OFW. I agree its 
already an improvement but certainly one of the kind I like less as VIA 
could come up with such "improvements" too. IMHO it's a bad thing to 
push one chipset first if the target is to support all equally well (as 
long as the hardware permits).
So I'd be glad if you could go on with the patches that are less painful 
and get them ready for the merge window (as I really don't have a clue 
how long it will take me to get the suspend/resume stuff to a state I 
consider acceptable). Perhaps we should make suspend and resume a 
configure option and mark it as experimental?


Thanks,

Florian Tobias Schandinat
--

[ message continues ]

In my case (Commell LE 365) the BIOS offers an option to restore graphics
to text mode on resume so the manual call of 'fbset -a $MODE' works
pretty well, only the acceleration has issues.
I don't remember if accel can get revived with vanilla 2.6.34-rc2 if it
was disabled before suspend.

When I get time to, I will give these patches a try. A central GIT tree
where all viafb patches get collected would definitely be nice (even with
multiple semi-throw-away "topic" branches).

Thanks,
Bruno
--

[ message continues ]

Good news! After some hours of hacking, damaging a filesystem and nearly 
smashing my SD card I've found a promising way to implement suspend and 
resume in viafb based on the first patch of this series. I think this is 
something that can be done for the next merge window. I'll start a clean 
implementation after Jon sent an updated patch series (including the 

Goal basically reached:
- likely to work on all IGPs as nothing directly IGP dependent is there
- works without OFW/BIOS

However:
- suspending is very slow, looks like it takes double the time compared 
to before s&r support was added to viafb (this is also with only the 
original patch)
- output device setting is messed up (example: before suspend the output 
was on DVI, after resume on CRT)
- does not restore some values in the mmio but reinitializes it instead. 

Acceleration doesn't work in 2.6.34-rc2 or later after resume (limited 
only to the cursor, the rest works for me). It will work after the 

Yes, I guess that would be a good idea at least now where 2 people are 
actively working on viafb. I have also a few minor patches ready I'll 
send in a few days (after having repaired my development environment).


Best regards,

Florian Tobias Schandinat
--

[ message continues ]

[Trying to get caught up again ... ]

On Tue, 13 Apr 2010 05:03:33 +0200


I'd missed that on my previous reading.  Do you want me to post a new

You mean, double the time without actually dealing with the frame

Code using MMIO (the camera in particular) definitely needs stuff
done; the OLPC code can currently suspend and resume with the camera
streaming and it all works.

What I'd done was to move core S/R into via-core.c (which you've not
yet seen, but which I hope to get posted tomorrow) and give subdevices
a hook so they can be called for S/R events.  That lets each subdev
ensure that its own needs are met.

Now, I'd been expecting to strip that out on the assumption that the
current S/R code wasn't going to make it upstream.  I could change

As a starting point, I've set up:

	git://git.lwn.net/linux-2.6.git viafb-next

That's for patches aimed at linux-next.  It contains the last series I
sent out, plus one embarrassing compilation fix.  Once I have other
stuff ready for review (soon!), I'll stick it into a different branch.

Incidentally, the "olpc-2.6.31-cam" branch there has the full set of
code as used by OLPC now.  That branch reflects a lot history of
figuring out how this hardware actually works (sometimes it looks
vaguely like what's in the datasheet, but I think that's coincidental);
some real cleanup needs to happen on the way to the mainline.

Thanks,

jon
--

[ message continues ]