Re: [U-Boot] [PATCH 6/7] tegra: add SPI SLINK driver
On 01/11/2013 11:44 AM, Allen Martin wrote:
Add driver for tegra SPI SLINK style driver. This controller is
similar to the tegra20 SPI SFLASH controller. The difference is
that the SLINK controller is a genernal purpose SPI controller and the
SFLASH controller is special purpose and can only talk to FLASH
devices. In addition there are potentially many instances of an SLINK
controller on tegra and only a single instance of SFLASH. Tegra20 is
currently ths only version of tegra that instantiates an SFLASH
controller.
This driver supports basic PIO mode of operation and is configurable
(CONFIG_OF_CONTROL) to be driven off devicetree bindings. Up to 4
devices per controller may be attached, although typically only a
single chip select line is exposed from tegra per controller so in
reality this is usually limited to 1.
To enable this driver, use CONFIG_TEGRA_SLINK
diff --git a/drivers/spi/tegra_slink.c b/drivers/spi/tegra_slink.c
+void spi_init(void)
+{
+ int node = 0, i;
+ struct tegra_spi_ctrl *ctrl;
+ for (i = 0; i CONFIG_TEGRA_SLINK_CTRLS; i++) {
+ ctrl = spi_ctrls[i];
+#ifdef CONFIG_OF_CONTROL
Is this ever false for Tegra upstream? I don't think so.
+ node = fdtdec_next_compatible(gd-fdt_blob, node,
+ COMPAT_NVIDIA_TEGRA20_SLINK);
+ if (!node)
+ break;
+ ctrl-regs = (struct slink_tegra *)fdtdec_get_addr(gd-fdt_blob,
+node, reg);
+ if ((fdt_addr_t)ctrl-regs == FDT_ADDR_T_NONE) {
+ debug(%s: no slink register found\n, __func__);
+ break;
Shouldn't most of the breaks in this loop be continues, so that any
other nodes can be parsed? After all, this loop is trying to initialize
all SLINK controllers in the DT right?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] tegra: fdt: add apbdma node
On Fri, Jan 11, 2013 at 04:08:55PM -0800, Stephen Warren wrote:
On 01/11/2013 11:44 AM, Allen Martin wrote:
Add apbdma node for tegra20 and tegra30, copied directly from tegra
Linux dtsi files.
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
+ apbdma: dma {
+ compatible = nvidia,tegra20-apbdma;
+ reg = 0x6000a000 0x1200;
...
intc: interrupt-controller@50041000 {
Can the nodes be kept sorted by address?
They're already unsorted. I'll add a new patch to sort them, then add
this one on top.
-Allen
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] tegra: spi: add fdt support to tegra SPI SFLASH driver
On Fri, Jan 11, 2013 at 04:13:42PM -0800, Stephen Warren wrote:
On 01/11/2013 11:44 AM, Allen Martin wrote:
Add support for configuring tegra SPI driver from devicetree.
Support is keyed off CONFIG_OF_CONTROL. Add entry in seaboard dts
file for spi controller to describe seaboard spi.
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
.dtsi changes would typically be in a separate patch.
ok
+ spi@7000c380 {
+ compatible = nvidia,tegra20-sflash;
+ reg = 0x7000c380 0x80;
+ interrupts = 0 39 0x04;
+ nvidia,dma-request-selector = apbdma 11;
+ spi-max-frequency = 2500;
spi-max-frequency is board-specific; it should appear in the board .dts
file not the SoC .dtsi file.
ok
diff --git a/drivers/spi/tegra_spi.c b/drivers/spi/tegra_spi.c
@@ -85,7 +91,41 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
spi-slave.bus = bus;
spi-slave.cs = cs;
spi-freq = max_hz;
+#ifdef CONFIG_OF_CONTROL
+ int node = fdtdec_next_compatible(gd-fdt_blob, 0,
+ COMPAT_NVIDIA_TEGRA20_SFLASH);
I assume this function gets called once, and hence the line above simply
finds the first sflash node in the device tree. What if there's more
than one node? There certainly can be more than one SPI controller,
although perhaps the sflash controller only has one instance on any
current chip and it's the other IP block (SPI) that has multiple
instances in practice.
SFLASH only exists in tegra20, and there is only one. This driver can
only handle a single controller anyway. I highly doubt there will
ever be another chip with an SFLASH controller, never mind more than
one, but if there is, this driver will need lots of modification to
support multiple. All newer chips have SLINK controllers only.
This function can be called more than once, like if you type sf
probe multiple times, but it passes in 0 as the initial node offset,
so it will always return the first compatible node. So theoretically
if there ever is a tegra with more than one SFLASH controller, with
this patch the driver will operate like it did before this patch, it
will support the first controller only.
-Allen
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] tegra30: fdt: add SPI SLINK nodes
On Fri, Jan 11, 2013 at 04:17:18PM -0800, Stephen Warren wrote:
On 01/11/2013 11:44 AM, Allen Martin wrote:
Add tegra30 SPI SLINK nodes to fdt.
diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
/* PERIPH_ID_I2C_DVC, CLK_M */
clocks = tegra_car 47;
};
+ spi@7000d400 {
Blank line needed before the new node.
ok
+ compatible = nvidia,tegra30-slink, nvidia,tegra20-slink;
+ reg = 0x7000d400 0x200;
I can't tell if the sort order is correct here; not enough context in
the diff.
It's not, I'll fix.
+ interrupts = 0 59 0x04;
+ nvidia,dma-request-selector = apbdma 15;
+ spi-max-frequency = 2500;
Same comment about that property being board-specific.
ok
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ /* PERIPH_ID_SBC1, PLLP_OUT0 */
+ clocks = tegra_car 41;
+ };
-Allen
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] tegra: add SPI SLINK driver
On Fri, Jan 11, 2013 at 04:22:46PM -0800, Stephen Warren wrote:
On 01/11/2013 11:44 AM, Allen Martin wrote:
Add driver for tegra SPI SLINK style driver. This controller is
similar to the tegra20 SPI SFLASH controller. The difference is
that the SLINK controller is a genernal purpose SPI controller and the
SFLASH controller is special purpose and can only talk to FLASH
devices. In addition there are potentially many instances of an SLINK
controller on tegra and only a single instance of SFLASH. Tegra20 is
currently ths only version of tegra that instantiates an SFLASH
controller.
This driver supports basic PIO mode of operation and is configurable
(CONFIG_OF_CONTROL) to be driven off devicetree bindings. Up to 4
devices per controller may be attached, although typically only a
single chip select line is exposed from tegra per controller so in
reality this is usually limited to 1.
To enable this driver, use CONFIG_TEGRA_SLINK
diff --git a/drivers/spi/tegra_slink.c b/drivers/spi/tegra_slink.c
+void spi_init(void)
+{
+ int node = 0, i;
+ struct tegra_spi_ctrl *ctrl;
+ for (i = 0; i CONFIG_TEGRA_SLINK_CTRLS; i++) {
+ ctrl = spi_ctrls[i];
+#ifdef CONFIG_OF_CONTROL
Is this ever false for Tegra upstream? I don't think so.
No, but I think it's worthwhile to keep it under #ifdef so this driver
could be used from the SPL if the need ever comes up. I tested by
forcing it off for this driver and it works.
+ node = fdtdec_next_compatible(gd-fdt_blob, node,
+ COMPAT_NVIDIA_TEGRA20_SLINK);
+ if (!node)
+ break;
+ ctrl-regs = (struct slink_tegra *)fdtdec_get_addr(gd-fdt_blob,
+ node, reg);
+ if ((fdt_addr_t)ctrl-regs == FDT_ADDR_T_NONE) {
+ debug(%s: no slink register found\n, __func__);
+ break;
Shouldn't most of the breaks in this loop be continues, so that any
other nodes can be parsed? After all, this loop is trying to initialize
all SLINK controllers in the DT right?
True, and looking at this code I think the driver is going to do
something bad if any of the controllers are not fully specified and
you go to use it later. I think the controller structure needs a
valid flag.
-Allen
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BDI3000 - Unprotect flash sectors
On 01/11/2013 02:41 AM, Waibel Georg wrote: Hello, i'm not sure if this is the right place for this question...however, here it is: i'm using a BDI3000 to program uboot to the flash (Spansion S29GL512P) on a MPC5200B base board. Erasing / Programming works fine as long as the flash sectors are not protected (via PPB bit). On a protected sector the erase command fails (what makes sense). I thought I can use the unlock command to unprotect the sectors, but this command seems not to work: unlock 0xfff0 1000 Hi Georg, do you get the same error if you create an ERASE list and have UNLOCK added as the mode for those sectors that need to be unlocked ? Issue then ERASE or UNLOCK without any parameter in the telnet session and see if that makes any difference. Also, make sure that address 0xfff0 is the correct sector address. Failing that, please try using the CFI interface of your flash. Check in your flash memory data sheet for all the CFI commands. Try to unlock a sector and then read back the status register to see what the reported error is. Use MD and MM commands to issue the CFI commands to your flash. Hope this helps -- sinan Unlocking flash at 0xfff0 # Invalid parameter for flash programming Any ideas what I'm doing wrong? Flash configuration: [FLASH] CHIPTYPEMIRRORX16 CHIPSIZE0x0400 BUSWIDTH16 WORKSPACE 0x Regards Georg Waibel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] tegra: fdt: add apbdma node
On 01/11/2013 08:19 PM, Allen Martin wrote:
On Fri, Jan 11, 2013 at 04:08:55PM -0800, Stephen Warren wrote:
On 01/11/2013 11:44 AM, Allen Martin wrote:
Add apbdma node for tegra20 and tegra30, copied directly from tegra
Linux dtsi files.
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
+ apbdma: dma {
+ compatible = nvidia,tegra20-apbdma;
+ reg = 0x6000a000 0x1200;
...
intc: interrupt-controller@50041000 {
Can the nodes be kept sorted by address?
They're already unsorted. I'll add a new patch to sort them, then add
this one on top.
Ah yes.
You can use the kernel as a reference, but FYI the order I have
attempted to impose there is:
1) Any nodes that already exist in any /include/d file, in the order
they appear in the /include/d file.
2) Any nodes with a reg property, in order of their address.
3) Any nodes without a reg property, alphabetically by node name.
If U-Boot follows the same rules, diff'ing the .dts files between U-Boot
and the kernel should be easy.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] tegra: fdt: add apbdma node
On Fri, Jan 11, 2013 at 10:07:41PM -0800, Stephen Warren wrote:
On 01/11/2013 08:19 PM, Allen Martin wrote:
On Fri, Jan 11, 2013 at 04:08:55PM -0800, Stephen Warren wrote:
On 01/11/2013 11:44 AM, Allen Martin wrote:
Add apbdma node for tegra20 and tegra30, copied directly from tegra
Linux dtsi files.
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
+ apbdma: dma {
+ compatible = nvidia,tegra20-apbdma;
+ reg = 0x6000a000 0x1200;
...
intc: interrupt-controller@50041000 {
Can the nodes be kept sorted by address?
They're already unsorted. I'll add a new patch to sort them, then add
this one on top.
Ah yes.
You can use the kernel as a reference, but FYI the order I have
attempted to impose there is:
1) Any nodes that already exist in any /include/d file, in the order
they appear in the /include/d file.
2) Any nodes with a reg property, in order of their address.
3) Any nodes without a reg property, alphabetically by node name.
If U-Boot follows the same rules, diff'ing the .dts files between U-Boot
and the kernel should be easy.
Ok, thanks, I'll try to follow the same rules.
BTW: cache-controller and interrupt-controller are out of order in the
kernel dtsi files.
-Allen
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
