few changes to drivers, no kernel config was added. As the SoCs are quite
old and the code is unmaintained start the process of removing support by
deleting the header file and code that depends on it along with the macro
SOC_OMAP3. Other Ti SoCs shouldn't be affected, other than for us to have
less code to maintain.
Differential Revision: https://reviews.freebsd.org/D936
Reviewed by: rpaulo, loos
- Don't allow high-speed mode on OMAP4 due to hardware erratum.
- Check the proper bit in the status register when waiting for the
controller to come out of reset.
- Add handling for the "non-removable" fdt property by always returning
"card is present" status.
- Add the non-removable property for the MMC card on a Beaglebone Black.
- Add the non-removable property for Pandaboard as a workaround.
For Pandaboard the card detect pin is handled by the twl6030 fpga device
which gets an interrupt on pin change and then has to query the fpga
for the actual status. We don't have code to do that yet.
Submitted by: Svatopluk Kraus <onwahe@gmail.com>
to check the status property in their probe routines.
Simplebus used to only instantiate its children whose status="okay"
but that was improper behavior, fixed in r261352. Now that it doesn't
check anymore and probes all its children; the children all have to
do the check because really only the children know how to properly
interpret their status property strings.
Right now all existing drivers only understand "okay" versus something-
that's-not-okay, so they all use the new ofw_bus_status_okay() helper.
host.host_ocr, examine the correct field when setting up the hardware. Also,
the offset for the capabilties register should be 0x140, not 0x240.
Submitted by: Ilya Bakulin <ilya@bakulin.de>
Pointy hat to: me
Use the published compatible strings (our own invention, "ti,mmchs" is
still accepted as well, for now).
Don't blindly turn on 8-bit bus mode, because even though the conroller
supports it, the board has to be wired appropriately as well. Use the
published property (bus-width=<n>) and honor all the valid values (1,4,8).
The eMMC device on a Beaglebone Black is wired for 8-bit, update the dts.
The mmchs controller can inherently do both 1.8v and 3.0v on the first
device and 1.8v only on other devices, unless an external transceiver is
used. Set the voltage automatically for the first device and honor
the published fdt property (ti,dualvolt) for other devices.
Thanks go to Ilya Bakulin for figuring out the voltage compatibility stuff.
The MMCHS hardware is pretty much a standard SDHCI v2.0 controller with a
couple quirks, which are now supported by sdhci(4) as of r254507.
This should work for all TI SoCs that use the MMCHS hardware, but it has
only been tested on AM335x right now, so this enables it on those platforms
but leaves the existing ti_mmchs driver in place for other OMAP variants
until they can be tested.
This initial incarnation lacks DMA support (coming soon). Even without it
this improves performance pretty noticibly over the ti_mmchs driver,
primarily because it now does multiblock IO.
