<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers, branch v2010.12-rc1</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>Coding Style cleanup</title>
<updated>2010-10-27T20:48:30+00:00</updated>
<author>
<name>Wolfgang Denk</name>
<email>wd@denx.de</email>
</author>
<published>2010-10-27T20:48:30+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=071bc923308832bbc541a887fece767d79a6dc7a'/>
<id>071bc923308832bbc541a887fece767d79a6dc7a</id>
<content type='text'>
Signed-off-by: Wolfgang Denk &lt;wd@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Wolfgang Denk &lt;wd@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: seperate block number into small parts for multi-write cmd</title>
<updated>2010-10-27T18:39:33+00:00</updated>
<author>
<name>Lei Wen</name>
<email>leiwen@marvell.com</email>
</author>
<published>2010-10-14T05:38:11+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0158126e252b6860e7a7d8408d0872278a3483cf'/>
<id>0158126e252b6860e7a7d8408d0872278a3483cf</id>
<content type='text'>
Constraint the mmc framework to only send no more than 65535
blocks in one go during the multi-write command. This constraint
comes due to the limitation of 16bit width block counter register
at some hardware.

Signed-off-by: Lei Wen &lt;leiwen@marvell.com&gt;
Cc: Reinhard Meyer &lt;u-boot@emk-elektronik.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Constraint the mmc framework to only send no more than 65535
blocks in one go during the multi-write command. This constraint
comes due to the limitation of 16bit width block counter register
at some hardware.

Signed-off-by: Lei Wen &lt;leiwen@marvell.com&gt;
Cc: Reinhard Meyer &lt;u-boot@emk-elektronik.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://git.denx.de/u-boot-i2c</title>
<updated>2010-10-26T18:55:39+00:00</updated>
<author>
<name>Wolfgang Denk</name>
<email>wd@denx.de</email>
</author>
<published>2010-10-26T18:55:39+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=90d8cff09918f1fdf15cdb4e6c55fb1712340710'/>
<id>90d8cff09918f1fdf15cdb4e6c55fb1712340710</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>ARMV7: OMAP: I2C driver: Fix bug found in 37XX testing</title>
<updated>2010-10-25T05:57:20+00:00</updated>
<author>
<name>Steve Sakoman</name>
<email>steve@sakoman.com</email>
</author>
<published>2010-10-22T20:48:00+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4df66894954ec6411d22e3a86070014d74bafb5c'/>
<id>4df66894954ec6411d22e3a86070014d74bafb5c</id>
<content type='text'>
On OMAP36/37XX the standard on chip pullups are not sufficient to
ensure proper i2c operation without external pullups or switching
to high speed mode and enabling special on chip pullups.

This is an issue for Beagle xM, which does not have external pullups
on the expansion board i2c lines.

The issue manifests itself as an AL (arbitration lost) error when
probing for a non-existent device (i.e. on a Beagle xM with no expansion
boards attached).  This issue does not occur on expansion boards that
include pullups or on Overo 37XX COM's since they include pull-ups.

This patch fixes the issue by checking for the AL bit in the i2c_probe
function.

Signed-off-by: Steve Sakoman &lt;steve.sakoman@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On OMAP36/37XX the standard on chip pullups are not sufficient to
ensure proper i2c operation without external pullups or switching
to high speed mode and enabling special on chip pullups.

This is an issue for Beagle xM, which does not have external pullups
on the expansion board i2c lines.

The issue manifests itself as an AL (arbitration lost) error when
probing for a non-existent device (i.e. on a Beagle xM with no expansion
boards attached).  This issue does not occur on expansion boards that
include pullups or on Overo 37XX COM's since they include pull-ups.

This patch fixes the issue by checking for the AL bit in the i2c_probe
function.

Signed-off-by: Steve Sakoman &lt;steve.sakoman@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx</title>
<updated>2010-10-23T19:59:42+00:00</updated>
<author>
<name>Wolfgang Denk</name>
<email>wd@denx.de</email>
</author>
<published>2010-10-23T19:59:42+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f2b382ea066d02d5ba44870024cc1295e85782ef'/>
<id>f2b382ea066d02d5ba44870024cc1295e85782ef</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://git.denx.de/u-boot-video</title>
<updated>2010-10-23T19:56:51+00:00</updated>
<author>
<name>Wolfgang Denk</name>
<email>wd@denx.de</email>
</author>
<published>2010-10-23T19:56:51+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=33a08c10c78baf67e41cd03d5732ddc338e8c2e9'/>
<id>33a08c10c78baf67e41cd03d5732ddc338e8c2e9</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://git.denx.de/u-boot-usb</title>
<updated>2010-10-23T19:49:28+00:00</updated>
<author>
<name>Wolfgang Denk</name>
<email>wd@denx.de</email>
</author>
<published>2010-10-23T19:49:28+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=b4039a54153994e7c9a9f1c42a2a70a9153b6587'/>
<id>b4039a54153994e7c9a9f1c42a2a70a9153b6587</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>cfi_flash: handle 'chip size exceeds address window' situation</title>
<updated>2010-10-23T19:04:49+00:00</updated>
<author>
<name>Ilya Yanok</name>
<email>yanok@emcraft.com</email>
</author>
<published>2010-10-21T15:20:12+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ec50a8e389863ac35bfd9d9a2e8b30187318e59e'/>
<id>ec50a8e389863ac35bfd9d9a2e8b30187318e59e</id>
<content type='text'>
On some boards we have flash mapped high in the address space with
considerably small window (say 0xFE000000 and 32MB). When we install
bigger chip (say 64MB) on such a board strange things happen
(flash_write() doesn't work at all, for ex). That's because cfi_flash
driver doesn't care about window size at all.
Of course, cleanest solution would probably be to just extend address
window to be able to map the whole flash but for legacy/compatibility
reasons some people prefer just truncate the flash size and never use
the upper part.
This patch adds an option for cfi_flash driver to handle this situation
properly. To achieve this we add the new function cfi_flash_bank_size()
which can be provided by the board code and weak-aliased to default
implementation that returns value from the CONFIG_SYS_FLASH_BANKS_SIZES
array if it's defined or 0 otherwise (the last case is added for
compatibility).
If non-zero flash bank size is provided and detected chip size is bigger
than provided address window size the warning will be displayed and
flash chip will be truncated.

Signed-off-by: Ilya Yanok &lt;yanok@emcraft.com&gt;

Changed cfi_flash_bank_size() return type to unsigned long
to match caller function.
Signed-off-by: Wolfgang Denk &lt;wd@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On some boards we have flash mapped high in the address space with
considerably small window (say 0xFE000000 and 32MB). When we install
bigger chip (say 64MB) on such a board strange things happen
(flash_write() doesn't work at all, for ex). That's because cfi_flash
driver doesn't care about window size at all.
Of course, cleanest solution would probably be to just extend address
window to be able to map the whole flash but for legacy/compatibility
reasons some people prefer just truncate the flash size and never use
the upper part.
This patch adds an option for cfi_flash driver to handle this situation
properly. To achieve this we add the new function cfi_flash_bank_size()
which can be provided by the board code and weak-aliased to default
implementation that returns value from the CONFIG_SYS_FLASH_BANKS_SIZES
array if it's defined or 0 otherwise (the last case is added for
compatibility).
If non-zero flash bank size is provided and detected chip size is bigger
than provided address window size the warning will be displayed and
flash chip will be truncated.

Signed-off-by: Ilya Yanok &lt;yanok@emcraft.com&gt;

Changed cfi_flash_bank_size() return type to unsigned long
to match caller function.
Signed-off-by: Wolfgang Denk &lt;wd@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ehci-hcd.c: fix hanging under higher load</title>
<updated>2010-10-22T19:44:37+00:00</updated>
<author>
<name>Wolfgang Denk</name>
<email>wd@denx.de</email>
</author>
<published>2010-10-22T12:23:00+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=09c83a45b797aefbb41115af1b348494740460ce'/>
<id>09c83a45b797aefbb41115af1b348494740460ce</id>
<content type='text'>
This patch solves a problem with USB hanging under higher load on a
i.MX31 board.  It falls into class of typical USB problems and fixes:
if you don't understand the real cause, add a delay somewhere.

The problem appeared after introduction of ELF relocation, which
results in smaller code, which appears to run faster (probably because
it fits better in the cache); turning off the instruction cache,
adding debug printf()s and increasing the delay have all been found to
make the problem go away.

Moving the original "udelay(1)" up in the code to it's new place made
the problem appear much less frequently. Increasing the delay to 2
microseconds then made the code run reliably in all (hour-long) tests.
To be on the safe side, we set it to 5 microseconds here.

Signed-off-by: Heiko schocher &lt;hs@denx.de&gt;
Signed-off-by: Wolfgang Denk &lt;wd@denx.de&gt;
Cc: Remy Bohmer &lt;linux@bohmer.net&gt;
Cc: Stefano Babic &lt;sbabic@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch solves a problem with USB hanging under higher load on a
i.MX31 board.  It falls into class of typical USB problems and fixes:
if you don't understand the real cause, add a delay somewhere.

The problem appeared after introduction of ELF relocation, which
results in smaller code, which appears to run faster (probably because
it fits better in the cache); turning off the instruction cache,
adding debug printf()s and increasing the delay have all been found to
make the problem go away.

Moving the original "udelay(1)" up in the code to it's new place made
the problem appear much less frequently. Increasing the delay to 2
microseconds then made the code run reliably in all (hour-long) tests.
To be on the safe side, we set it to 5 microseconds here.

Signed-off-by: Heiko schocher &lt;hs@denx.de&gt;
Signed-off-by: Wolfgang Denk &lt;wd@denx.de&gt;
Cc: Remy Bohmer &lt;linux@bohmer.net&gt;
Cc: Stefano Babic &lt;sbabic@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: musb: constify a bit</title>
<updated>2010-10-22T19:41:46+00:00</updated>
<author>
<name>Mike Frysinger</name>
<email>vapier@gentoo.org</email>
</author>
<published>2010-10-20T11:15:35+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0228348e9c0361dcb1c7e2678a3d899aca15f258'/>
<id>0228348e9c0361dcb1c7e2678a3d899aca15f258</id>
<content type='text'>
These ep and root hub structures need not be writable.

Signed-off-by: Mike Frysinger &lt;vapier@gentoo.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These ep and root hub structures need not be writable.

Signed-off-by: Mike Frysinger &lt;vapier@gentoo.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
