Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 3 年多

通知 13
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 26 3月, 2009 3 次提交
  3. 17 2月, 2009 1 次提交
  5. 07 1月, 2009 2 次提交
  7. 05 1月, 2009 4 次提交
    • N
      atmel-mci: move atmel-mci.h file to include/linux · c42aa775
      由 Nicolas Ferre 提交于 
      Needed to use the atmel-mci driver in an architecture
independant maner.
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      c42aa775
    • A
      avr32: Hammerhead board support · dd5e1339
      由 Alex Raimondi 提交于 
      The Hammerhead platform is built around a AVR32 32-bit microcontroller
from Atmel.  It offers versatile peripherals, such as ethernet, usb
device, usb host etc.

The board also incooperates a power supply and is a Power over Ethernet
(PoE) Powered Device (PD).

Additonally, a Cyclone III FPGA from Altera is integrated on the board.
The FPGA is mapped into the 32-bit AVR memory bus. The FPGA offers two
DDR2 SDRAM interfaces, which will cover even the most exceptional need
of memory bandwidth. Together with the onboard video decoder the board
is ready for video processing.

This patch does include the basic support for the fpga device driver,
but not the device driver itself.
Signed-off-by: NAlex Raimondi <mailinglist@miromico.ch>
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      dd5e1339
    • A
      avr32: Allow reserving multiple pins at once · adde42b5
      由 Alex Raimondi 提交于 
      at32_reserve_pin now takes an u32 bitmask rather than a single pin.
This allows to reserve multiple pins at once.

Remove (undocumented) SDCS (pin PE26) from reservation in board
setup code.
Signed-off-by: NAlex Raimondi <raimondi@miromico.ch>
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      adde42b5
    • K
      avr: struct device - replace bus_id with dev_name(), dev_set_name() · 5f6333bd
      由 Kay Sievers 提交于 
      (I did not compile or test it, please let me know, or help fixing
 it, if something is wrong with the conversion)

This patch is part of a larger patch series which will remove
the "char bus_id[20]" name string from struct device. The device
name is managed in the kobject anyway, and without any size
limitation, and just needlessly copied into "struct device".

To set and read the device name dev_name(dev) and dev_set_name(dev)
must be used. If your code uses static kobjects, which it shouldn't
do, "const char *init_name" can be used to statically provide the
name the registered device should have. At registration time, the
init_name field is cleared, to enforce the use of dev_name(dev) to
access the device name at a later time.

We need to get rid of all occurrences of bus_id in the entire tree
to be able to enable the new interface. Please apply this patch,
and possibly convert any remaining remaining occurrences of bus_id.

We want to submit a patch to -next, which will remove bus_id from
"struct device", to find the remaining pieces to convert, and finally
switch over to the new api, which will remove the 20 bytes array
and does no longer have a size limitation.

Thanks,
Kay

From: Kay Sievers <kay.sievers@vrfy.org>
Subject: avr: struct device - replace bus_id with dev_name(), dev_set_name()

Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      5f6333bd
  9. 24 10月, 2008 1 次提交
  11. 23 10月, 2008 3 次提交
  13. 16 10月, 2008 2 次提交
  15. 13 10月, 2008 1 次提交
  17. 12 10月, 2008 1 次提交
  19. 06 10月, 2008 3 次提交
    • H
      atmel-mci: Add experimental DMA support · 65e8b083
      由 Haavard Skinnemoen 提交于 
      This adds support for DMA transfers through the generic DMA engine
framework with the DMA slave extensions.

The driver has been tested using mmc-block and ext3fs on several SD,
SDHC and MMC+ cards. Reads and writes work fine, with read transfer
rates up to 7.5 MiB/s on fast cards with debugging disabled.

Unfortunately, the driver has been known to lock up from time to time
with DMA enabled, so DMA support is currently optional and marked
EXPERIMENTAL. However, I didn't see any problems while testing 13
different cards (MMC, SD and SDHC of different brands and sizes), so I
suspect the "Initialize BLKR before sending data transfer command" fix
that was posted earlier fixed this as well.
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      65e8b083
    • H
      atmel-mci: Platform code for supporting multiple mmc slots · 6b918657
      由 Haavard Skinnemoen 提交于 
      Add the necessary platform infrastructure to support multiple mmc/sdcard
slots all at once through a single controller. Currently, the driver
will use the first valid slot it finds and stick with that, but later
patches will add support for switching between several slots on the fly.

Extend the platform data structure with per-slot information: MMC/SDcard
bus width and card detect/write protect pins. This will affect the pin
muxing as well as the capabilities announced to the mmc core.

Note that board code is now required to supply a mci_platform_data
struct to at32_add_device_mci().
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      6b918657
    • A
      avr32: Replace static clock list with dynamic linked list · 300bb762
      由 Alex Raimondi 提交于 
      This replaces the at32_clock_list array with a linked list.
Clocks can now be registered (added) to the list.
Signed-off-by: NAlex Raimondi <raimondi@miromico.ch>
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      300bb762
  21. 22 9月, 2008 5 次提交
  23. 01 9月, 2008 1 次提交
  25. 08 8月, 2008 3 次提交
  27. 05 8月, 2008 2 次提交
  29. 27 7月, 2008 1 次提交
    • D
      avr32: some mmc/sd cleanups · 3c26e170
      由 David Brownell 提交于 
      Minor cleanups for the MMC/SD support on avr32:

 - Make at32_add_device_mci() properly initialize "missing"
   platform data ... so boards like STK1002 won't try GPIO 0.

 - Switch over to gpio_is_valid() instead of testing for only
   one designated value.

 - Provide STK1002 platform data for the unlikely case that
   switches are set so first Ethernet controller isn't in use.
   (That's the only way to get card detect and writeprotect
   switch sensing on the STK1000.)

And get rid of one "unused variable" warning.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      3c26e170
  31. 26 7月, 2008 1 次提交
    • D
      gpio: sysfs interface · d8f388d8
      由 David Brownell 提交于 
      This adds a simple sysfs interface for GPIOs.

    /sys/class/gpio
    	/export ... asks the kernel to export a GPIO to userspace
    	/unexport ... to return a GPIO to the kernel
        /gpioN ... for each exported GPIO #N
	    /value ... always readable, writes fail for input GPIOs
	    /direction ... r/w as: in, out (default low); write high, low
	/gpiochipN ... for each gpiochip; #N is its first GPIO
	    /base ... (r/o) same as N
	    /label ... (r/o) descriptive, not necessarily unique
	    /ngpio ... (r/o) number of GPIOs; numbered N .. N+(ngpio - 1)

GPIOs claimed by kernel code may be exported by its owner using a new
gpio_export() call, which should be most useful for driver debugging.
Such exports may optionally be done without a "direction" attribute.

Userspace may ask to take over a GPIO by writing to a sysfs control file,
helping to cope with incomplete board support or other "one-off"
requirements that don't merit full kernel support:

  echo 23 > /sys/class/gpio/export
	... will gpio_request(23, "sysfs") and gpio_export(23);
	use /sys/class/gpio/gpio-23/direction to (re)configure it,
	when that GPIO can be used as both input and output.
  echo 23 > /sys/class/gpio/unexport
	... will gpio_free(23), when it was exported as above

The extra D-space footprint is a few hundred bytes, except for the sysfs
resources associated with each exported GPIO.  The additional I-space
footprint is about two thirds of the current size of gpiolib (!).  Since
no /dev node creation is involved, no "udev" support is needed.

Related changes:

  * This adds a device pointer to "struct gpio_chip".  When GPIO
    providers initialize that, sysfs gpio class devices become children of
    that device instead of being "virtual" devices.

  * The (few) gpio_chip providers which have such a device node have
    been updated.

  * Some gpio_chip drivers also needed to update their module "owner"
    field ...  for which missing kerneldoc was added.

  * Some gpio_chips don't support input GPIOs.  Those GPIOs are now
    flagged appropriately when the chip is registered.

Based on previous patches, and discussion both on and off LKML.

A Documentation/ABI/testing/sysfs-gpio update is ready to submit once this
merges to mainline.

[akpm@linux-foundation.org: a few maintenance build fixes]
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Guennadi Liakhovetski <g.liakhovetski@pengutronix.de>
Cc: Greg KH <greg@kroah.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d8f388d8
  33. 24 7月, 2008 1 次提交
  35. 18 7月, 2008 1 次提交
    • B
      avr32: clean up mci platform code · fbfca4b8
      由 Ben Nizette 提交于 
      This patch does a few small cleanups around the atmel mci platform code
and in the atmel-mci driver.  The platform changes simply removes an
unused variable, uses the fact that by the end we always have some form
of platform data and notes that GPIO_PIN_NONE != 0.  This last point
could cause the incorrect attempt to twice reserve pin PA0.

While we've got the hood up, add linux/err.h to the atmel-mci.c include
list.  It needs it and generally pulls it by voodoo but I did once
stumble across a config which don't build.

This is against Linus' latest git.
Signed-off-by: NBen Nizette <bn@niasdigital.com>
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      fbfca4b8
  37. 15 7月, 2008 1 次提交
    • H
      atmel-mci: Driver for Atmel on-chip MMC controllers · 7d2be074
      由 Haavard Skinnemoen 提交于 
      This is a driver for the MMC controller on the AP7000 chips from
Atmel. It should in theory work on AT91 systems too with some
tweaking, but since the DMA interface is quite different, it's not
entirely clear if it's worth merging this with the at91_mci driver.

This driver has been around for a while in BSPs and kernel sources
provided by Atmel, but this particular version uses the generic DMA
Engine framework (with the slave extensions) instead of an
avr32-only DMA controller framework.

This driver can also use PIO transfers when no DMA channels are
available, and for transfers where using DMA may be difficult or
impractical for some reason (e.g. the DMA setup overhead is usually
not worth it for very short transfers, and badly aligned buffers or
lengths are difficult to handle.)

Currently, the driver only support PIO transfers. DMA support has been
split out to a separate patch to hopefully make it easier to review.

The driver has been tested using mmc-block and ext3fs on several SD,
SDHC and MMC+ cards. Reads and writes work fine, with read transfer
rates up to 3.5 MiB/s on fast cards with debugging disabled.

The driver has also been tested using the mmc_test module on the same
cards. All tests except 7, 9, 15 and 17 succeed. The first two are
unsupported by all the cards I have, so I don't know if the driver
handles this correctly. The last two fail because the hardware flags a
Data CRC Error instead of a Data Timeout error. I'm not sure how to deal
with that.

Documentation for this controller can be found in many data sheets from
Atmel, including the AT32AP7000 data sheet which can be found here:

http://www.atmel.com/dyn/products/datasheets.asp?family_id=682Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      7d2be074
  39. 09 7月, 2008 1 次提交
    • H
      dmaengine: Driver for the Synopsys DesignWare DMA controller · 3bfb1d20
      由 Haavard Skinnemoen 提交于 
      This adds a driver for the Synopsys DesignWare DMA controller (aka
DMACA on AVR32 systems.) This DMA controller can be found integrated
on the AT32AP7000 chip and is primarily meant for peripheral DMA
transfer, but can also be used for memory-to-memory transfers.

This patch is based on a driver from David Brownell which was based on
an older version of the DMA Engine framework. It also implements the
proposed extensions to the DMA Engine API for slave DMA operations.

The dmatest client shows no problems, but there may still be room for
improvement performance-wise. DMA slave transfer performance is
definitely "good enough"; reading 100 MiB from an SD card running at ~20
MHz yields ~7.2 MiB/s average transfer rate.

Full documentation for this controller can be found in the Synopsys
DW AHB DMAC Databook:

http://www.synopsys.com/designware/docs/iip/DW_ahb_dmac/latest/doc/dw_ahb_dmac_db.pdf

The controller has lots of implementation options, so it's usually a
good idea to check the data sheet of the chip it's intergrated on as
well. The AT32AP7000 data sheet can be found here:

http://www.atmel.com/dyn/products/datasheets.asp?family_id=682


Changes since v4:
  * Use client_count instead of dma_chan_is_in_use()
  * Add missing include
  * Unmap buffers unless client told us not to

Changes since v3:
  * Update to latest DMA engine and DMA slave APIs
  * Embed the hw descriptor into the sw descriptor
  * Clean up and update MODULE_DESCRIPTION, copyright date, etc.

Changes since v2:
  * Dequeue all pending transfers in terminate_all()
  * Rename dw_dmac.h -> dw_dmac_regs.h
  * Define and use controller-specific dma_slave data
  * Fix up a few outdated comments
  * Define hardware registers as structs (doesn't generate better
    code, unfortunately, but it looks nicer.)
  * Get number of channels from platform_data instead of hardcoding it
    based on CONFIG_WHATEVER_CPU.
  * Give slave clients exclusive access to the channel

Acked-by: Maciej Sosnowski <maciej.sosnowski@intel.com>,
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      3bfb1d20
  41. 04 7月, 2008 1 次提交
  43. 02 7月, 2008 1 次提交
    • H
      avr32: Power Management support ("standby" and "mem" modes) · 02a00cf6
      由 Haavard Skinnemoen 提交于 
      Implement Standby support. In this mode, we'll suspend all drivers,
put the SDRAM in self-refresh mode and switch off the HSB bus
("frozen" mode.)

Implement Suspend-to-mem support. In this mode, we suspend all
drivers, put the SDRAM into self-refresh mode and switch off all
internal clocks except the 32 kHz oscillator ("stop" mode.)

The lowest-level suspend code runs from a small portion of SRAM
allocated at startup time. This gets rid of a small potential race
with the SDRAM where we might try to enter self-refresh mode in the
middle of an icache burst. We also relocate all interrupt and
exception handlers to SRAM during the small window when we enter and
exit the low-power modes.

We don't need to do any special tricks to start and stop the PLL. The
main clock is automatically gated by hardware until the PLL is stable.
Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      02a00cf6