Skip to content

L
linux-davinci
Switch branch/tag
  1. 11 Dec, 2008 11 commits
    • David Brownell's avatar
      ASoC -- EVM driver grows dm355 support (?) · 9a5668e7
      David Brownell authored 
      Teach the "davinci-evm" ASoC support to handle both DM6446
and DM355 EVM boards by recognizing which board they're using,
then setting up appropropriately.

The only particularly ugly bit here is clock handling, where
we need to "know" the right clock name to use.  This solution
is simple, but may not work on some yet-to-be-seen boards
that would want "McBSPCLK0".

Note that this includes a minor bugfix:  now that DaVinci
kernels can support multiple boards, board-specific ASoC
components need to verify they're running on the right
board before initializing.
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      9a5668e7
    • David Brownell's avatar
      psc_mux() -- it's not all about dm6446 · 144f4d82
      David Brownell authored 
      Generalize the psc_mux() stuff to stop assuming there are only
DM6446 chips, and specifically to handle things the DM355 EVM
will need:  SPI0, MMC0, MMC1, ASP1.

Note that I think the clock framework (PSC) and pinmux framework
really ought to be properly separated.  The pinmux stuff seems
like it should fit well into devices-dmXXX.c logic, with boards
declaring what device they use and how they're configured.  That
works cleanly on other platforms.

Likewise with muxing IRQ and EDMA channels.  Do it all as part
of device setup.  (And maybe let it be reconfigured at runtime
for oddball systems.)
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      144f4d82
    • David Brownell's avatar
      it's ASP, not McBSP · 06d1ea92
      David Brownell authored 
      The DaVinci <mach/mcbsp.h> is full of useless stuff:

 (a) It's used with chips that don't *have* a McBSP; instead,
     they have an ASP.

 (b) Most of the registers and utilities apply to nothing I
     can find.  Not ASP; not the McBSP on chips like dm642.

Replace with <mach/asp.h> since these DaVinci chips *do* have
one or more ASP modules.
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      06d1ea92
    • David Brownell's avatar
      DaVinci ASoC: fix multiboard buglet · da23213c
      David Brownell authored 
      Minor bugfix:  now that DaVinci kernels can support multiple
boards, board-specific ASoC components need to verify they're
running on the right board before initializing.
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      da23213c
    • David Brownell's avatar
      remove ancient/obsolete OSS-ism · 2a899dac
      David Brownell authored 
      Remove remnants of an old OSS-audio-for-DaVinci patch, which
tried to make some OMAP-specific AIC23 code do double duty as
DaVinci AIC33 codec support.

Nowadays there's sane ASoC support for both AIC23 and AIC33
codecs, and there seems to be no need for this OSS remnant.
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      2a899dac
    • David Brownell's avatar
      dm355 evm ethernet support · a84fe539
      David Brownell authored 
      Let the DM355 EVM use its dm9000 ethernet controller; just
declare it.  Relies on the patch fixing GPIO IRQs.
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      a84fe539
    • David Brownell's avatar
      dm355evm input driver · 0180687d
      David Brownell authored 
      Simple input driver support for the events reported by the
MSP430 firmware on the DM355 EVM.  Verified using the remote
included with the kit; docs weren't quite right.  Some of
the keycode selections might need improvement; I'm hoping
I implemented the remapping support right, so there's at
least a runtime workaround.

Keys on the remote seem to repeat undesirably.  Someone might
want to see what's up with that, and fix it; it might just
be an issue of tracking RC5 state and using the toggle.
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      0180687d
    • David Brownell's avatar
      dm355evm rtc driver · 55893c82
      David Brownell authored 
      Simple RTC driver for the MSP430 firmware on the DM355 EVM board.
Other than not supporting atomic reads/writes of all four bytes,
this is quite reasonable as a basic no-alarm RTC.
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      55893c82
    • David Brownell's avatar
      dm355 evm i2c config updates · c4437ba6
      David Brownell authored 
      Board support for the dm355evm_msp MFD driver.  This provides I2C
initialization for new-style drivers, as used by that MFD driver
and by mainline drivers for this board's audio and video codecs.

It also updates the I2C bus to use 400 kHz.  The 20 kHz value was
leftover from the DM6446 EVM, where the msp430 used an execrable
bit-banged I2C implementation.  The msp430 on the DM355 EVM uses
hardware I2C, and appears to have no such problems.
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      c4437ba6
    • David Brownell's avatar
      dm355evm msp430 MFD driver · 16dc708f
      David Brownell authored 
      Basic MFD framework for the MSP430 microcontroller firmware used
on the dm355evm board:

 - Provides an interface for other drivers: register read/write
   utilities, and register declarations.

 - Directly exports:
     * Many signals through the GPIO framework
         + LEDs
         + SW6 through gpio sysfs
	 + NTSC/nPAL jumper through gpio sysfs
	 + ... more could be added later, e.g. MMC signals
     * Child devices:
	+ LEDs, via leds-gpio child (and default triggers)
	+ RTC, via rtc-dm355evm child device
	+ Buttons and IR control, via dm355evm_keys

 - Supports power-off system call.  Use the reset button to power
   the board back up; the power supply LED will be on, but the
   MSP430 waits to re-activate the regulators.

 - On probe() this:
     * Announces firmware revision
     * Turns off the banked LEDs
     * Exports the resources noted above
     * Hooks the power-off support
     * Muxes tvp5146 -or- imager for video input

Unless the new tvp514x driver (tracked for mainline) is configured,
this assumes that some custom imager driver handles video-in.

This completely ignores the registers reporting the output voltages
on the various power supplies.  Someone could add a hwmon interface
if that seems useful.
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      16dc708f
    • David Brownell's avatar
      davinci gpio bugfixes · 2f8e9a6e
      David Brownell authored 
      Update the DaVinci GPIO code to work better on non-dm6446 parts,
notably the dm355:

 - Only handle the number of GPIOs the chip actually has.  So
   for example on dm6467, GPIO-42 is the last GPIO, and trying
   to use GPIO-43 now fails cleanly; or GPIO-72 on dm6446.

 - Enable GPIO interrupts on each 16-bit GPIO-irq bank ...
   previously, only the first five were enabled, so GPIO-80
   and above (on dm355) wouldn't trigger IRQs.

 - Use the right IRQ for each GPIO bank.  The wrong values were
   used for dm355 chips, so GPIO IRQs got routed incorrectly.

 - Handle up to four pairs of 16-bit GPIO banks ... previously
   only three were handled, so accessing GPIO-96 and up (e.g. on
   dm355) would oops.

 - Update several comments that were dm6446-specific.

Verified by receiving GPIO-1 (dm9000) and GPIO-5 (msp430) IRQs
on the DM355 EVM.

One thing this doesn't do is handle the way some of the GPIO
numbers on dm6467 are reserved but aren't valid as GPIOs.  Some
bitmap logic could fix that if needed.
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      2f8e9a6e
  3. 22 Nov, 2008 2 commits
  5. 21 Nov, 2008 25 commits
  7. 20 Nov, 2008 2 commits