<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/video, branch linux-2.6.14.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>[PATCH] Fix onboard video on SPARC Blade 100 for 2.6.{13,14,15}</title>
<updated>2006-01-08T02:15:09+00:00</updated>
<author>
<name>Luis F. Ortiz</name>
<email>lfo@Polyad.Org</email>
</author>
<published>2006-01-05T21:19:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1854ce394f42e1d52adbaa6fc21ff5ea33e976eb'/>
<id>1854ce394f42e1d52adbaa6fc21ff5ea33e976eb</id>
<content type='text'>
	I have recently been switching from using 2.4.32 on my trusty
old Sparc Blade 100 to using 2.6.15 .  Some of the problems I ran into
were distorted video when the console was active (missing first
character, skipped dots) and when running X windows (colored snow,
stripes, missing pixels).  A quick examination of the 2.6 versus 2.4
source for the ATY driver revealed alot of changes.

         A closer look at the code/data for the 64GR/XL chip revealed
two minor "typos" that the rewriter(s) of the code made.  The first is
a incorrect clock value (230 .vs. 235) and the second is a missing
flag (M64F_SDRAM_MAGIC_PLL).  Making both these changes seems to have
fixed my problem.  I tend to think the 235 value is the correct one,
as there is a 29.4 Mhz clock crystal close to the video chip and 235.2
(29.4*8) is too close to 235 to make it a coincidence.

	The flag for M64F_SDRAM_MAGIC_PLL was dropped during the
changes made by adaplas in file revision 1.72 on the old bitkeeper
repository.

	The change relating to the clock rate has been there forever,
at least in the 2.6 tree.  I'm not sure where to look for the old 2.5
tree or if anyone cares when it happened.

On SPARC Blades 100's, which use the ATY MACH64GR video chipset, the
clock crystal frequency is 235.2 Mhz, not 230 Mhz.  The chipset also
requires the use of M64F_SDRAM_MAGIC_PLL in order to setup the PLL
properly for the DRAM.

Signed-off-by: Luis F. Ortiz &lt;lfo@Polyad.Org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
	I have recently been switching from using 2.4.32 on my trusty
old Sparc Blade 100 to using 2.6.15 .  Some of the problems I ran into
were distorted video when the console was active (missing first
character, skipped dots) and when running X windows (colored snow,
stripes, missing pixels).  A quick examination of the 2.6 versus 2.4
source for the ATY driver revealed alot of changes.

         A closer look at the code/data for the 64GR/XL chip revealed
two minor "typos" that the rewriter(s) of the code made.  The first is
a incorrect clock value (230 .vs. 235) and the second is a missing
flag (M64F_SDRAM_MAGIC_PLL).  Making both these changes seems to have
fixed my problem.  I tend to think the 235 value is the correct one,
as there is a 29.4 Mhz clock crystal close to the video chip and 235.2
(29.4*8) is too close to 235 to make it a coincidence.

	The flag for M64F_SDRAM_MAGIC_PLL was dropped during the
changes made by adaplas in file revision 1.72 on the old bitkeeper
repository.

	The change relating to the clock rate has been there forever,
at least in the 2.6 tree.  I'm not sure where to look for the old 2.5
tree or if anyone cares when it happened.

On SPARC Blades 100's, which use the ATY MACH64GR video chipset, the
clock crystal frequency is 235.2 Mhz, not 230 Mhz.  The chipset also
requires the use of M64F_SDRAM_MAGIC_PLL in order to setup the PLL
properly for the DRAM.

Signed-off-by: Luis F. Ortiz &lt;lfo@Polyad.Org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] Return the line length via sysfs for fbdev</title>
<updated>2005-10-24T21:08:29+00:00</updated>
<author>
<name>James Simmons</name>
<email>jsimmons@infradead.org</email>
</author>
<published>2005-10-24T20:46:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c14e2cfc18659c6ca67c2e10417c432eb978d976'/>
<id>c14e2cfc18659c6ca67c2e10417c432eb978d976</id>
<content type='text'>
This small patch returns the stride/line length of the framebuffer via
sysfs.

Signed-off-by: James Simmons &lt;jsimmons@infradead.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This small patch returns the stride/line length of the framebuffer via
sysfs.

Signed-off-by: James Simmons &lt;jsimmons@infradead.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] vesafb: Fix display corruption on display blank</title>
<updated>2005-10-18T15:43:29+00:00</updated>
<author>
<name>Antonino A. Daplas</name>
<email>adaplas@gmail.com</email>
</author>
<published>2005-10-18T07:59:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bb7e257ef8d8ba43cab356aa1cc1b20d0106d45f'/>
<id>bb7e257ef8d8ba43cab356aa1cc1b20d0106d45f</id>
<content type='text'>
Reported by: Bob Tracy &lt;rct@gherkin.frus.com&gt;

 "...I've got a Toshiba notebook (730XCDT -- Pentium 150MMX) for which
  I'm using the Vesa FB driver.  When the machine has been idle for some
  time and the driver attempts to powerdown the display, rather than the
  display going blank, it goes gray with several strange lines.  When I
  hit the "shift" key or other-wise wake up the display, the old video
  state is not fully restored..."

vesafb recently added a blank method which has only 2 states, powerup and
powerdown.  The powerdown state is used for all blanking levels, but in his
case, powerdown does not work correctly for higher levels of display
powersaving. Thus, for intermediate power levels, use software blanking,
and use only hardware blanking for an explicit powerdown.

Signed-off-by: Antonino Daplas &lt;adaplas@pol.net&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reported by: Bob Tracy &lt;rct@gherkin.frus.com&gt;

 "...I've got a Toshiba notebook (730XCDT -- Pentium 150MMX) for which
  I'm using the Vesa FB driver.  When the machine has been idle for some
  time and the driver attempts to powerdown the display, rather than the
  display going blank, it goes gray with several strange lines.  When I
  hit the "shift" key or other-wise wake up the display, the old video
  state is not fully restored..."

vesafb recently added a blank method which has only 2 states, powerup and
powerdown.  The powerdown state is used for all blanking levels, but in his
case, powerdown does not work correctly for higher levels of display
powersaving. Thus, for intermediate power levels, use software blanking,
and use only hardware blanking for an explicit powerdown.

Signed-off-by: Antonino Daplas &lt;adaplas@pol.net&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Add some basic .gitignore files</title>
<updated>2005-10-18T15:26:15+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@g5.osdl.org</email>
</author>
<published>2005-10-18T15:26:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1e65174a3378494608e8ed7f8c74d658be9a0fb2'/>
<id>1e65174a3378494608e8ed7f8c74d658be9a0fb2</id>
<content type='text'>
This still leaves driver and architecture-specific subdirectories alone,
but gets rid of the bulk of the "generic" generated files that we should
ignore.

Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This still leaves driver and architecture-specific subdirectories alone,
but gets rid of the bulk of the "generic" generated files that we should
ignore.

Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] SVGATextMode fix</title>
<updated>2005-10-17T15:59:10+00:00</updated>
<author>
<name>Samuel Thibault</name>
<email>samuel.thibault@ens-lyon.org</email>
</author>
<published>2005-10-17T03:29:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0aec4867dca149e2049e8439b76bd82ad9dac52c'/>
<id>0aec4867dca149e2049e8439b76bd82ad9dac52c</id>
<content type='text'>
Fix bug 5441.

I didn't know about messy programs like svgatextmode...  Couldn't this be
integrated in some linux/drivers/video/console/svgacon.c ?...  So because
of the existence of the svgatextmode program, the kernel is not supposed to
touch to CRT_OVERFLOW/SYNC_END/DISP/DISP_END/OFFSET ?

Disabling the check in vgacon_resize() might help indeed, but I'm really
not sure whether it will work for any chipset: in my patch, CRT registers
are set at each console switch, since stty rows/cols apply to consoles
separately...

The attached solution is to keep the test, but if it fails, we assume that
the caller knows what it does (i.e.  it is svgatextmode) and then disable
any further call to vgacon_doresize.  Svgatextmode is usually used to
_expand_ the display, not to shrink it.  And it is harmless in the case of
a too big stty rows/cols: the display will just be cropped.  I tested it on
my laptop, and it works fine with svgatextmode.

A better solution would be that svgatextmode explicitely tells the kernel
not to care about video timing, but for this an interface needs be defined
and svgatextmode be patched.

Signed-off-by: Samuel Thibault &lt;samuel.thibault@ens-lyon.org&gt;
Cc: "Antonino A. Daplas" &lt;adaplas@pol.net&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix bug 5441.

I didn't know about messy programs like svgatextmode...  Couldn't this be
integrated in some linux/drivers/video/console/svgacon.c ?...  So because
of the existence of the svgatextmode program, the kernel is not supposed to
touch to CRT_OVERFLOW/SYNC_END/DISP/DISP_END/OFFSET ?

Disabling the check in vgacon_resize() might help indeed, but I'm really
not sure whether it will work for any chipset: in my patch, CRT registers
are set at each console switch, since stty rows/cols apply to consoles
separately...

The attached solution is to keep the test, but if it fails, we assume that
the caller knows what it does (i.e.  it is svgatextmode) and then disable
any further call to vgacon_doresize.  Svgatextmode is usually used to
_expand_ the display, not to shrink it.  And it is harmless in the case of
a too big stty rows/cols: the display will just be cropped.  I tested it on
my laptop, and it works fine with svgatextmode.

A better solution would be that svgatextmode explicitely tells the kernel
not to care about video timing, but for this an interface needs be defined
and svgatextmode be patched.

Signed-off-by: Samuel Thibault &lt;samuel.thibault@ens-lyon.org&gt;
Cc: "Antonino A. Daplas" &lt;adaplas@pol.net&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] zaurus: fix compilation with cpufreq disabled</title>
<updated>2005-10-15T00:10:12+00:00</updated>
<author>
<name>Pavel Machek</name>
<email>pavel@ucw.cz</email>
</author>
<published>2005-10-14T22:59:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6edb7467be2195e7eeb6844e37668253af216100'/>
<id>6edb7467be2195e7eeb6844e37668253af216100</id>
<content type='text'>
This fixes compilation with CPU_FREQ disabled.

Signed-off-by: Pavel Machek &lt;pavel@suse.cz&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes compilation with CPU_FREQ disabled.

Signed-off-by: Pavel Machek &lt;pavel@suse.cz&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SPARC]: Fix p9100 framebuffer in 2.6</title>
<updated>2005-10-07T20:05:56+00:00</updated>
<author>
<name>Tom 'spot' Callaway</name>
<email>tcallawa@redhat.com</email>
</author>
<published>2005-10-07T20:05:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d85c3553df5e24cb3117385f0a17e1cc0436d148'/>
<id>d85c3553df5e24cb3117385f0a17e1cc0436d148</id>
<content type='text'>
The attached patch fixes the p9100 framebuffer so that text is viewable
(not black on black, like it was before the patch). The linux logo
displays for a very short period of time, then is replaced by a grey
box. This leads me to believe that this framebuffer would have problems
in X, but since there hasn't been a weitek driver for X in several
millennia, this isn't something that I can confirm or deny.

But this patch does get color console working on my SPARCbook 3TX.

Signed-off-by: Tom 'spot' Callaway &lt;tcallawa@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The attached patch fixes the p9100 framebuffer so that text is viewable
(not black on black, like it was before the patch). The linux logo
displays for a very short period of time, then is replaced by a grey
box. This leads me to believe that this framebuffer would have problems
in X, but since there hasn't been a weitek driver for X in several
millennia, this isn't something that I can confirm or deny.

But this patch does get color console working on my SPARCbook 3TX.

Signed-off-by: Tom 'spot' Callaway &lt;tcallawa@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] pmac/radeonfb: Add suspend support for M11 chip in new iBook 12"</title>
<updated>2005-10-02T00:01:48+00:00</updated>
<author>
<name>Sven Henkel</name>
<email>shenkel@gmail.com</email>
</author>
<published>2005-10-01T22:29:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=14bfd1ff94f519a59b1e88e682819332d7e98171'/>
<id>14bfd1ff94f519a59b1e88e682819332d7e98171</id>
<content type='text'>
This adds suspend support for the Radeon M11 chip in 12" iBooks
manufactured after July 2005.  I don't know if the new 14" iBooks also
have that chip, so they might also be supported.

The chip identifies itself as "RV350 NV" (pci id 0x4e56), revision 0x80.
Apple calls it "Snowy", xfree86 names it "ATI FireGL Mobility T2 (M11)
NV (AGP)".  So, we seem to be lucky here: The suspend-code for the M10
(which also is a "RV350 NV") works flawless for that chip.

Signed-off-by: Sven Henkel &lt;shenkel@gmail.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This adds suspend support for the Radeon M11 chip in 12" iBooks
manufactured after July 2005.  I don't know if the new 14" iBooks also
have that chip, so they might also be supported.

The chip identifies itself as "RV350 NV" (pci id 0x4e56), revision 0x80.
Apple calls it "Snowy", xfree86 names it "ATI FireGL Mobility T2 (M11)
NV (AGP)".  So, we seem to be lucky here: The suspend-code for the M10
(which also is a "RV350 NV") works flawless for that chip.

Signed-off-by: Sven Henkel &lt;shenkel@gmail.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6</title>
<updated>2005-09-30T15:43:13+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@g5.osdl.org</email>
</author>
<published>2005-09-30T15:43:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c4a7c77fcb8c0ef16e7193fb8cab2654282bbfab'/>
<id>c4a7c77fcb8c0ef16e7193fb8cab2654282bbfab</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge master.kernel.org:/home/rmk/linux-2.6-arm</title>
<updated>2005-09-30T15:39:56+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@g5.osdl.org</email>
</author>
<published>2005-09-30T15:39:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1dd465cac8d3ba18a9840d032f6604147269c031'/>
<id>1dd465cac8d3ba18a9840d032f6604147269c031</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
</feed>
