Parent the MII bus properly:  it's a child of the EMAC device,
not a free-standing beastie.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Generalizes dm644x pinmux.

The existing pinmux layer works only when the PINMUX register has single bit
field to enable the secondary function. DM646x can support secondary as well
as tertiary pin functions. This new pinmux layer is similar to the one being
used by OMAP architecture.

Checkpatch script reports a false positive error at line no.465 of this patch.

This patch is based on the work originally done by Vladimir Barinov, when he
was in MontaVista.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Commit 178bb537
(use __raw_writel) introduced a bug in davinci_set_dma_params
and davinci_get_dma_params. I forgot about CCNT.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Let musb_hdrc on DaVinci use the clock framework, now that it
seems to work right.

 * add USBCLK to dm644x support (it's already there for dm355)
 * only enable it when the driver asks for that
 * make the musb_hdrc driver use that clock

The original failures seem to have been caused by really buggy code
implementing the clock APIs.  Now they're working right.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Fix an init sequence bug with the MUSB driver on a DaVinci EVM:
don't initialize it until after the pcf8574 GPIO expander is ready.
This prevent oopsing.

And since the DaVinci GPIOs have been renumbered ... use the new number
for the GPIO on that pcf8574 chip.  (Eventually that number should be
passed through platform_data to the driver.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Fix remaining checkpatch problems.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Make sure that PHYLIB is selected along with TI_DAVINCI_EMAC,
to prevent link errors.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Don't register the EMAC device except on chips that have one.

Fix lots of goofy whitespace with the EMAC setup.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

A "cat /proc/iomem" showed why mmc0 is now broken on dm355:

  01e00000-01e00fff : davinci_mmc.1
    01e00000-01e00fff : davinci_mmc
  01e10000-01e10fff : davinci_mmc.0
    01e10000-01e10fff : davinci_nand
      01e10000-01e10fff : davinci_mmc
  02000000-03ffffff : davinci_nand

What was the MMC0 controller address on dm6446 chips is the AEMIF
control register bank on dm355 chips, used by the NAND driver.

Use the right address, and now MMC0 works.  (In PIO mode, and
with that ASM-to-C conversion patch reverted.)  And for that
matter, the dm9000 starts working again.  Win!  Maybe the NAND
driver will be happier too...
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

This reverts commit 5912086e.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Fixes the 2.6.28-rc8-davinci1 booting on dm646x EVM.

davinci_psc_init is not being called for DM646x EVM, hence davinci_psc_mux
is not defined for DM646x. This is resulting in DM646x board not booting up.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Partially parameterize the ALE and CLE masks; there's a bunch of
other stuff that should come from platform_data too, but this
patch doesn't change that stuff.

While we're doing this ... fix the related "sparse" errors.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Start splitting out the board-specific NAND support better,
by having board-specific flash init functions.  DM355 EVM
has a newer and faster chip.

It's still in the wrong place, but at least it's better
factored now ... which will help later when it's moved to
the board-*.c files.  (NOTE:  sffsdr support is missing;
it might not actually need to set the EMIF A1CR register.)

Also update the header comment slightly, listing key
assumptions made by this driver ... and delete a broken
comment in the dm6446 setup code, that's not the value
it was writing.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Update/bugfix hardware ECC config handling.  The driver should still
be able to build without that support enabled (else remove its Kconfig
option!); remove frowned-upon inline #ifdeffery.

Also suffix all the original ECC logic with _1bit to distinguish it
from the DM355's enhanced ECC hardware (corrects 4 single-bit errors
per 512 bytes), which should get good support.

Note that I think the issue with flash access on the DM355 EVM is
likely to be ECC related.  Specifically, the original LSP uses that
enhanced ECC hardware, and thus needs 10 bytes of data per 512 byte
block ... which seems to be stored INLINE rather than in the OOB
region, because of a Linux restriction to 32 bytes of ECC data.
(One hopes that restriction gets lifted ASAP.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Update/bugfix partition config handling.  This removes some inlines in
the body of the driver, bugfixes cmdlinepart handling, bugfixes the
"no partitions" cases, and cleans up properly on driver removal.

Yes, these bugs are common in MTD drivers; I think the MTD framework
should eventually get help, maybe like this, to help un-obfuscate
drivers (which almost all have such #ifdeffery today).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Speed up transfers between NAND and RAM by using the io{read,write}*_rep()
calls to replace a more limited read-only I/O loop.  On a similar arm926
board this gave a significant speedup (ISTR 16%) in a userspace "dd"
benchmark.

Also add a comment explaining some key assumptions (wiring) this makes.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

That define was only used for polling for card presence,
which now we let mmc core do it in a more reliable way.

No need to keep that define here.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

There's no need for a file included only once, remove it
and move the register definition to davinci_mmc.c.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Make rw_threshold and use_dma a module parameter,
thus getting rid of struct mmcsd_config_def.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Add missing __init and __exit where appropriate.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Mostly tab fixes, but also removing some extra lines and
putting module_init() close to its argument function.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

On Mon, Dec 15, 2008 at 09:19:05PM +0200, Felipe Balbi wrote:
> cool, will fix :-)
>
> good catch with the missing branch, thanks

here you are

==================== cut here ====================

>From 43fbab69f7d19e39c7c270c4aa1652b0efea0a8f Mon Sep 17 00:00:00 2001
From: Felipe Balbi <felipe.balbi@nokia.com>
Date: Mon, 15 Dec 2008 18:08:36 +0200
Subject: [patch-v2.6.28 3/8] mmc: host: davinci: reimplement read/write fifo in C

It's easier to follow and to maintain.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

There were a bunch of useless function prototypes in
davinci_mmc.h. Remove them and reorganize the file
so we don't really need those.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Fix most of checkpatch.pl ERRORS with davinci_mmc.c. Also
fix up a few comments in the beggining of the file.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Fix checkpatch.pl bugs ... mostly return-with-parens.  And also
fix some whitespace bugs, one of which was reported by checkpatch
(bad indentation).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Update more of the RX and TX buffer descriptor (BD) handling to
properly distinguish between __iomem pointers and normal data
memory address space, getting rid of 32 "cast removes address
space of expression" messages.

This patch doesn't resolve all the issues sparse reports.  In fact
there are now 48 new "dereference of noderef expression" messages.
They mean that a patch is needed to convert BD member accessors to
use readl/writel calls.

Plus, there are several related issues that sparse won't warn about.
The initial i/o space addresses -- SRAM used for BDs, and controller
registers -- should come from ioremap.  Reverse mappings shouldn't
usually be needed, and if they are they should avoid io_v2p() and
virt_to_phys() calls.  And the need to use casts so often is wrong,
especially with __force annotations.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Fix about half the warnings from "make C=1" (sparse), and start on
the __iomem issues associated with the CPPI buffer descriptor data.
All of the remaining warnings come from address space issues.  For
this driver, fixing all those issues will be quite messy.

One of these warnings highlighted minor goofiness in how the module
infrastructure was used; fix that too.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Do spinlock initialization during davinci_emac::probe(), when
the lock is allocated, not each time it's opened.  That's the
correct place to do such work.

More significantly, fix a bug: one of the three spinlocks was
never getting initialized, preventing the system from booting
in some cases (e.g. running with lockdep).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

CC      drivers/net/davinci_emac.o
drivers/net/davinci_emac.c: In function 'emac_adjust_link':
drivers/net/davinci_emac.c:2323: error: incompatible type for argument 1 of '_spin_lock_irqsave'
make[2]: *** [drivers/net/davinci_emac.o] Error 1
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

NAND devices can't be hotpluggable. We can use that
to shrink code size a bit by using platform_driver_probe().
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

Those mux settings are only valid for dm6446, so put that
under a conditional.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

Cleanup only. Removing whitespaces from <mach/nand.h>
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

Make dm355's nand flash probe with current driver.
For some reason, the current driver marks way too many
blocks as bad blocks. Later patches will be needed to
fix it.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

On Sat, Dec 13, 2008 at 12:54:17AM +0200, Felipe Balbi wrote:
> On Fri, Dec 12, 2008 at 02:52:14PM -0800, David Brownell wrote:
> > Just update the individual patches and save the effort.
> > Less work for you, fewer bits wasted on the Internet.  ;)
>
> Sure, just did it. Will retest (sanity) and reply with the newer patch
> soon.

here it is:

==== cut here ====

>From 964d8b463ea8d32c27249d6e1b64ed6143551dd8 Mon Sep 17 00:00:00 2001
From: Felipe Balbi <felipe.balbi@nokia.com>
Date: Wed, 10 Dec 2008 01:41:52 +0200
Subject: [patch-v2.6.28 06/10] mtd: nand: davinci: add missing __init and __exit

Add __init to init-only functions, __exit to exit-only
functions.

Also, switch two __devinit to __init, as nand devices
can't be hotpluggable.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

add a more meaningful set of debugging messages.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

On Fri, Dec 12, 2008 at 07:52:28PM +0200, Felipe Balbi wrote:
> From: Felipe Balbi <felipe.balbi@nokia.com>
>
> introduce a structure to hold davinci_nand device
> data.
>
> Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

New version below:

====== cut here ======

>From 1d2f9999a56bd0a71510ce09e0e863d15d98013d Mon Sep 17 00:00:00 2001
From: Felipe Balbi <felipe.balbi@nokia.com>
Date: Fri, 12 Dec 2008 16:15:07 +0200
Subject: [patch-v2.6.28 04/10] mtd: nand: introduce davinci_nand_info

introduce a structure to hold davinci_nand device
data.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

nand_vaddr was already ioremaped, so it's already
a void __iomem pointer. Do not cast it uselessly.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

checkpatch.pl fixes to davinci_nand.c
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

Later patch will come to use it in davinci_nand.c and get
rid of a define there. In DM355, the base is different, so
better to apply this patch before adding support for DM355
nand chip.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

Checkpatch likes EXPORT_SYMBOL below function definition.
Also, add export of davinci_pause_dma and davinci_resume_dma.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>