CVS log for src/sys/arch/arm/omap/Attic/omap3_sdhc.c

Up to [cvs.NetBSD.org] / src / sys / arch / arm / omap

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

Remove old OMAP port.

This code was a mess and full of unmaintainable SoC and board specific
ifdefs. A modern devicetree port for OMAP3530 and AM335x based boards
now lives in arch/arm/ti. If someone is interested in bringing back
support for any boards lost in this transition, feel free, but please
do so using the new devicetree based model.

sdhc: Retire SDHC_FLAG_USE_ADMA2 flag.

ADMA2 support in sdhc is mature now, so no need for it to be opt-in.

Sync with HEAD

Sync with HEAD

Resolve a couple of conflicts (result of the uimin/uimax changes)

Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int.  The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER!  Some subsystems have

	#define min(a, b)	((a) < (b) ? (a) : (b))
	#define max(a, b)	((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX.  Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate.  But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all.  (Who knows, maybe in some cases integer
truncation is actually intended!)

update from HEAD

Sync with HEAD

Sync with HEAD

Sync with HEAD

fix typo

fix compilation.

Fix rejected patch.
  Support am335x's MMCHS2(sdhc@mainbus).
    Tested on Gumstix Pepper 43C.

Support am335x's MMCHS2(sdhc@mainbus).
  Tested on Gumstix Pepper 43C.

Support ADMA2 on OMAP4430.
 Tested on Gumstix DuoVero.

use symbolic interrupt level for sdmmc, no functional change.

Sync with HEAD

TI_DM37xx does not currently have a working omapscm(4), which provides
omap_devid().  Avoid using omap_devid() until correctly fixed.

Support OMAP 4430.  But ADMA2 don't working yet.
tested on Gumstix DuoVero.

Sync with HEAD

AM335x's sdhc@obio use offset 0x100.
Oops this space maybe use HL registers?  OMAP4430 use this space.

Sync with HEAD

Check ChipID == OMAP3530.  OVERO supports both OMAP3530/3503.

Sync with HEAD (as of 26th Dec)

Pull up following revision(s) (requested by jmcneill in ticket #1017):
	sys/arch/arm/omap/omap3_sdhc.c: revision 1.18
AM335x EDMA3 has an alignment restriction for both SAM and DAM in constant
addressing mode. In these cases, the physical address must be aligned to
256-bits. To handle this, pre-allocate a MAXPHYS sized bounce buffer and
use it for unaligned transfers.
Fixes "edma errint!" problem mentioned in port-arm/50288.

Pull up following revision(s) (requested by jmcneill in ticket #1022):
	sys/dev/sdmmc/sdhc.c: revision 1.89
	sys/arch/arm/omap/omap3_sdhc.c: revision 1.19
	sys/dev/sdmmc/sdhcvar.h: revision 1.25
	sys/arch/evbarm/beagle/beagle_machdep.c: revision 1.62
allow vendor specific code to hook into bus width changes
Support 8-bit eMMC for TI AM335x. On my BeagleBone Black,
Before: 134217728 bytes transferred in 9.410 secs (14263307 bytes/sec)
After:  134217728 bytes transferred in 7.518 secs (17852850 bytes/sec)
enable 8-bit mode on AM335X SDMMC2

Support 8-bit eMMC for TI AM335x. On my BeagleBone Black,

Before: 134217728 bytes transferred in 9.410 secs (14263307 bytes/sec)
After:  134217728 bytes transferred in 7.518 secs (17852850 bytes/sec)

AM335x EDMA3 has an alignment restriction for both SAM and DAM in constant
addressing mode. In these cases, the physical address must be aligned to
256-bits. To handle this, pre-allocate a MAXPHYS sized bounce buffer and
use it for unaligned transfers.

Fixes "edma errint!" problem mentioned in port-arm/50288.

Sync with HEAD

Simplify sdhc(4) locking

Sync with HEAD

Pull up following revision(s) (requested by bouyer in ticket #704):
	sys/arch/arm/omap/omap_edma.c: revision 1.1
	sys/arch/arm/omap/omap_edma.h: revision 1.1
	sys/arch/arm/omap/files.omap2: revision 1.30
	sys/arch/arm/omap/omap2_obiovar.h: revision 1.3
	sys/arch/arm/omap/omap3_sdhc.c: revision 1.16
	sys/arch/arm/omap/omap2_reg.h: revision 1.29
	sys/arch/evbarm/conf/BEAGLEBONE: revision 1.31
	sys/arch/arm/omap/omap2_obio.c: revision 1.22
 - Add a driver for the Enhanced Direct Memory Access controller found
   in the AM335x SoC. Written by Jared D. McNeill, with some final debug by me.
 - Supports only DMA (not QDMA) yet, and there's no support for DMA event
   matrix yet (this means that only primary DMA events can be used)
 - Add support for DMA transfers. From Jared D. McNeill, with final debug by
   me. With this I can get nearly 20MB/s from my sdcard on the BB black at 1Ghz
   (not bad for a 50Mhz 4-bits bus), and still 15MB/s on the BB white at
   low speed (275Mhz).
 - Add the edma controller, and enable DMA for sdhc0 and sdhc1

Add support for DMA transfers. From Jared D. McNeill, with final debug by me.
With this I can get nearly 20MB/s from my sdcard on the BB black at 1Ghz
(not bad for a 50Mhz 4-bits bus), and still 15MB/s on the BB white at
low speed (275Mhz).

Sync with HEAD

spell "regulator" correctly

Rebase to HEAD as of a few days ago.

sync with head.

for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.

this commit was splitted into small chunks to avoid
a limitation of cvs.  ("Protocol error: too many arguments")

sync with head

OMAP4/OMAP5 changes.

sync with head

fix a bug in obiosdhc_bus_clock where SYSCTL_CEN bit wasnt being cleared or set properly, from Rui Paulo

Add TIAM335X SDMMC BASE definitions

resync from head

Initial OMAP4 changes.
Attaches but ...
sdhc0 at obio2 addr 0x4809c000-0x4809ceff intr 115: SDHC controller
sdhc0: SD Host Specification 1.0, rev.0
sdmmc0 at sdhc0 slot 0
sdhc0: INIT Procedure timeout
sdmmc0: couldn't supply clock
sdmmc0: couldn't enable card: 60

resync with head

sync with head

sync with (a bit old) head

beagleboard supports 8-bit SD mode

no need to print irq twice

dont set SDHC_FLAG_SINGLE_ONLY for OMAP3530 either

TI_AM335X SDHCI does not need SDHC_FLAG_SINGLE_ONLY.  This was
drastically hindering transfer rate performance.

I suspect SDHC_FLAG_SINGLE_ONLY is bogus on most/all other TI-flavored
SDHCI cores as well, but I am unable to confirm.

Implement TI AM335x's SDHC reset quirk.  Beaglebone SDHC works now!

On the AM335x, we first must wait for the controller to acknowledge
the reset; then we can wait for the reset to complete.

I believe this quirk also applies to the OMAP4 ES, but I don't have
one of those to test and we don't seem to have an obvious conditional
for it anyway.

This quirk may work for controllers that don't require it too, but I
am nervous about doing it by default because if we miss the reset
acknowledgement, then we'll just time out even though everything is
really hunky-dory.

Also, for all sdhc, don't bother writing 0 in sdhc_soft_reset while
waiting for the reset to complete; there is no need.

ok matt

Improved SDHC support for OMAP3.
From jmcneill.

Initial kludgerific attempt at making sdhc work on the AM335x.

There's a timing issue somewhere in the whole sdmmc thing so that
this doesn't actually work without SDMMC_DEBUG or some specially
crafted debugging messages, and the SoC-specific code needs to be
separated out here another way, but it's a little progress.

Added kernel option OMAP_3430 to allow easy differentiation between the
BEAGLEBOARD and N900 kernels; otherwise no real change.

Resulting N900 kernel tested with no visible regression.

<gimpy> go for it

Merge improved arm support (especially Cortex) from HEAD
including OMAP and BCM53xx support.

Resync to 2012-11-19 00:00:00 UTC

sync with head

file omap3_sdhc.c was added on branch matt-nb6-plus on 2012-11-28 22:40:36 +0000

file omap3_sdhc.c was added on branch yamt-pagecache on 2012-10-30 17:19:08 +0000

Support omap3 SDHC driver.  tested on OVERO only.

First pass at supporting the SD/MMC controllers on TI OMAP3/OMAP4 SoCs.
They are "mostly" SDHC.