<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/spi, branch v2013.04</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>Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'</title>
<updated>2013-04-14T08:38:37+00:00</updated>
<author>
<name>Albert ARIBAUD</name>
<email>albert.u.boot@aribaud.net</email>
</author>
<published>2013-04-14T08:38:37+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=8dc16cf9dd6196d99969d12741df186a61a2f9a3'/>
<id>8dc16cf9dd6196d99969d12741df186a61a2f9a3</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: mxc_spi: Set master mode for all channels</title>
<updated>2013-04-13T15:46:42+00:00</updated>
<author>
<name>Fabio Estevam</name>
<email>fabio.estevam@freescale.com</email>
</author>
<published>2013-04-09T13:06:25+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0f1411bc8dade4472ca802f46f75714e67301bb0'/>
<id>0f1411bc8dade4472ca802f46f75714e67301bb0</id>
<content type='text'>
The glitch in the SPI clock line, which commit 3cea335c34 (spi: mxc_spi: Fix spi
clock glitch durant reset) solved, is back now and itwas re-introduced by
commit d36b39bf0d (spi: mxc_spi: Fix ECSPI reset handling).

Actually the glitch is happening due to always toggling between slave mode
and master mode by configuring the CHANNEL_MODE bits in this reset function.

Since the spi driver only supports master mode, set the mode for all channels
always to master mode in order to have a stable, "glitch-free" SPI clock line.

Signed-off-by: Fabio Estevam &lt;fabio.estevam@freescale.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The glitch in the SPI clock line, which commit 3cea335c34 (spi: mxc_spi: Fix spi
clock glitch durant reset) solved, is back now and itwas re-introduced by
commit d36b39bf0d (spi: mxc_spi: Fix ECSPI reset handling).

Actually the glitch is happening due to always toggling between slave mode
and master mode by configuring the CHANNEL_MODE bits in this reset function.

Since the spi driver only supports master mode, set the mode for all channels
always to master mode in order to have a stable, "glitch-free" SPI clock line.

Signed-off-by: Fabio Estevam &lt;fabio.estevam@freescale.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'u-boot/master' into 'u-boot-arm/master'</title>
<updated>2013-04-12T20:07:57+00:00</updated>
<author>
<name>Albert ARIBAUD</name>
<email>albert.u.boot@aribaud.net</email>
</author>
<published>2013-04-12T20:07:57+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=18122019972ca639ee3b581257e3a63ff7c8efeb'/>
<id>18122019972ca639ee3b581257e3a63ff7c8efeb</id>
<content type='text'>
Conflicts:
	drivers/video/exynos_fb.c
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Conflicts:
	drivers/video/exynos_fb.c
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master'</title>
<updated>2013-04-04T13:44:57+00:00</updated>
<author>
<name>Albert ARIBAUD</name>
<email>albert.u.boot@aribaud.net</email>
</author>
<published>2013-04-04T13:44:57+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=fed029f3c31b7d5df674b5090a13356b631918c7'/>
<id>fed029f3c31b7d5df674b5090a13356b631918c7</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 'u-boot-imx/master' into 'u-boot-arm/master'</title>
<updated>2013-04-04T09:49:32+00:00</updated>
<author>
<name>Albert ARIBAUD</name>
<email>albert.u.boot@aribaud.net</email>
</author>
<published>2013-04-04T09:49:32+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=be08abc2429c2e9cbce3d0abc1d315171d683520'/>
<id>be08abc2429c2e9cbce3d0abc1d315171d683520</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: mxc_spi: Fix ECSPI reset handling</title>
<updated>2013-04-04T08:23:09+00:00</updated>
<author>
<name>Dirk Behme</name>
<email>dirk.behme@de.bosch.com</email>
</author>
<published>2013-03-20T22:03:44+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d36b39bf0d1dbe4ef03f7fc1f20b2e52eb90acf5'/>
<id>d36b39bf0d1dbe4ef03f7fc1f20b2e52eb90acf5</id>
<content type='text'>
Reviewing the ECSPI reset handling shows two issues:

1. For the enable/reset bit (MXC_CSPICTRL_EN) in the control reg
   (ECSPIx_CONGREG) the i.MX6 technical reference manual states:

   -- cut --
   ECSPIx_CONREG[0]: EN: Writing zero to this bit disables the block
   and resets the internal logic with the exception of the ECSPI_CONREG.
   -- cut --

   Note the exception mentioned: The CONREG itself isn't reset.

   Fix this by manually writing the reset value 0 to the whole register.
   This sets the EN bit to zero, too (i.e. includes the old
   ~MXC_CSPICTRL_EN).

2. We want to reset the whole SPI block here. So it makes no sense
   to first read the old value of the CONREG and write it back, later.
   This will give us the old (historic/random) value of the CONREG back.
   And doesn't reset the CONREG.

   To get a clean CONREG after the reset of the block, too, don't use
   the old (historic/random) value of the CONREG while doing the reset.
   And read the clean CONREG after the reset.

This was found while working on a SPI boot device where the i.MX6 boot
ROM has already initialized the SPI block. The initialization by the
boot ROM might be different to what the U-Boot driver wants to configure.
I.e. we need a clean reset of SPI block, including the CONREG.

Signed-off-by: Dirk Behme &lt;dirk.behme@de.bosch.com&gt;
CC: Stefano Babic &lt;sbabic@denx.de&gt;
CC: Fabio Estevam &lt;fabio.estevam@freescale.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reviewing the ECSPI reset handling shows two issues:

1. For the enable/reset bit (MXC_CSPICTRL_EN) in the control reg
   (ECSPIx_CONGREG) the i.MX6 technical reference manual states:

   -- cut --
   ECSPIx_CONREG[0]: EN: Writing zero to this bit disables the block
   and resets the internal logic with the exception of the ECSPI_CONREG.
   -- cut --

   Note the exception mentioned: The CONREG itself isn't reset.

   Fix this by manually writing the reset value 0 to the whole register.
   This sets the EN bit to zero, too (i.e. includes the old
   ~MXC_CSPICTRL_EN).

2. We want to reset the whole SPI block here. So it makes no sense
   to first read the old value of the CONREG and write it back, later.
   This will give us the old (historic/random) value of the CONREG back.
   And doesn't reset the CONREG.

   To get a clean CONREG after the reset of the block, too, don't use
   the old (historic/random) value of the CONREG while doing the reset.
   And read the clean CONREG after the reset.

This was found while working on a SPI boot device where the i.MX6 boot
ROM has already initialized the SPI block. The initialization by the
boot ROM might be different to what the U-Boot driver wants to configure.
I.e. we need a clean reset of SPI block, including the CONREG.

Signed-off-by: Dirk Behme &lt;dirk.behme@de.bosch.com&gt;
CC: Stefano Babic &lt;sbabic@denx.de&gt;
CC: Fabio Estevam &lt;fabio.estevam@freescale.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Consolidate bool type</title>
<updated>2013-04-01T20:33:52+00:00</updated>
<author>
<name>York Sun</name>
<email>yorksun@freescale.com</email>
</author>
<published>2013-04-01T18:29:11+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=472d546054dadacca91530bad42ad06f6408124e'/>
<id>472d546054dadacca91530bad42ad06f6408124e</id>
<content type='text'>
'bool' is defined in random places. This patch consolidates them into a
single header file include/linux/types.h, using stdbool.h introduced in C99.

All other #define, typedef and enum are removed. They are all consistent with
true = 1, false = 0.

Replace FALSE, False with false. Replace TRUE, True with true.
Skip *.py, *.php, lib/* files.

Signed-off-by: York Sun &lt;yorksun@freescale.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
'bool' is defined in random places. This patch consolidates them into a
single header file include/linux/types.h, using stdbool.h introduced in C99.

All other #define, typedef and enum are removed. They are all consistent with
true = 1, false = 0.

Replace FALSE, False with false. Replace TRUE, True with true.
Skip *.py, *.php, lib/* files.

Signed-off-by: York Sun &lt;yorksun@freescale.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: exynos: Fix compiler warnings for non-dt systems</title>
<updated>2013-03-29T02:16:25+00:00</updated>
<author>
<name>Vivek Gautam</name>
<email>gautam.vivek@samsung.com</email>
</author>
<published>2013-03-05T03:49:57+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=7d1795840889b4f21fbfb4196119d0c923706a54'/>
<id>7d1795840889b4f21fbfb4196119d0c923706a54</id>
<content type='text'>
Enclosing process_nodes() and spi_get_config() inside
CONFIG_OF_CONTROL, since they are compiled only for DT systems.

This fixes following warning:
exynos_spi.c:391:12: warning: 'process_nodes' defined but not used [-Wunused-function]

Signed-off-by: Vivek Gautam &lt;gautam.vivek@samsung.com&gt;
Acked-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Minkyu Kang &lt;mk7.kang@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Enclosing process_nodes() and spi_get_config() inside
CONFIG_OF_CONTROL, since they are compiled only for DT systems.

This fixes following warning:
exynos_spi.c:391:12: warning: 'process_nodes' defined but not used [-Wunused-function]

Signed-off-by: Vivek Gautam &lt;gautam.vivek@samsung.com&gt;
Acked-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Minkyu Kang &lt;mk7.kang@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'u-boot/master' into 'u-boot-arm/master'</title>
<updated>2013-03-28T17:50:01+00:00</updated>
<author>
<name>Albert ARIBAUD</name>
<email>albert.u.boot@aribaud.net</email>
</author>
<published>2013-03-28T17:50:01+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=009d75ccc11d27b9a083375a88bb93cb746b4800'/>
<id>009d75ccc11d27b9a083375a88bb93cb746b4800</id>
<content type='text'>
Conflicts:
	drivers/spi/tegra20_sflash.c
	include/fdtdec.h
	lib/fdtdec.c
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Conflicts:
	drivers/spi/tegra20_sflash.c
	include/fdtdec.h
	lib/fdtdec.c
</pre>
</div>
</content>
</entry>
<entry>
<title>tegra114: add SPI driver</title>
<updated>2013-03-25T16:56:07+00:00</updated>
<author>
<name>Allen Martin</name>
<email>amartin@nvidia.com</email>
</author>
<published>2013-03-16T18:58:13+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=77c42e80b936cf44334a59a7890c775712f5b707'/>
<id>77c42e80b936cf44334a59a7890c775712f5b707</id>
<content type='text'>
Add driver for tegra114 SPI controller.  This controller is not
compatible with either the tegra20 or tegra30 controllers, so it
requires a new driver.

Signed-off-by: Allen Martin &lt;amartin@nvidia.com&gt;
Signed-off-by: Tom Warren &lt;twarren@nvidia.com&gt;
Reviewed-by: Stephen Warren &lt;swarren@nvidia.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add driver for tegra114 SPI controller.  This controller is not
compatible with either the tegra20 or tegra30 controllers, so it
requires a new driver.

Signed-off-by: Allen Martin &lt;amartin@nvidia.com&gt;
Signed-off-by: Tom Warren &lt;twarren@nvidia.com&gt;
Reviewed-by: Stephen Warren &lt;swarren@nvidia.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
