1. 11 5月, 2012 2 次提交
    • R
      OMAPDSS: Provide an interface for audio support · 9c0b8420
      Ricardo Neri 提交于
      There exist several display technologies and standards that support audio as
      well. Hence, it is relevant to update the DSS device driver to provide an audio
      interface that may be used by an audio driver or any other driver interested in
      the functionality.
      
      The audio_enable function is intended to prepare the relevant
      IP for playback (e.g., enabling an audio FIFO, taking in/out of reset
      some IP, enabling companion chips, etc). It is intended to be called before
      audio_start. The audio_disable function performs the reverse operation and is
      intended to be called after audio_stop.
      
      While a given DSS device driver may support audio, it is possible that for
      certain configurations audio is not supported (e.g., an HDMI display using a
      VESA video timing). The audio_supported function is intended to query whether
      the current configuration of the display supports audio.
      
      The audio_config function is intended to configure all the relevant audio
      parameters of the display. In order to make the function independent of any
      specific DSS device driver, a struct omap_dss_audio is defined. Its purpose
      is to contain all the required parameters for audio configuration. At the
      moment, such structure contains pointers to IEC-60958 channel status word and
      CEA-861 audio infoframe structures. This should be enough to support HDMI and
      DisplayPort, as both are based on CEA-861 and IEC-60958. The omap_dss_audio
      structure may be extended in the future if required.
      
      The audio_enable/disable, audio_config and audio_supported functions could be
      implemented as functions that may sleep. Hence, they should not be called
      while holding a spinlock or a readlock.
      
      The audio_start/audio_stop function is intended to effectively start/stop audio
      playback after the configuration has taken place. These functions are designed
      to be used in an atomic context. Hence, audio_start should return quickly and be
      called only after all the needed resources for audio playback (audio FIFOs,
      DMA channels, companion chips, etc) have been enabled to begin data transfers.
      audio_stop is designed to only stop the audio transfers. The resources used
      for playback are released using audio_disable.
      
      A new enum omap_dss_audio_state is introduced to help the implementations of
      the interface to keep track of the audio state. The initial state is _DISABLED;
      then, the state transitions to _CONFIGURED, and then, when it is ready to
      play audio, to _ENABLED. The state _PLAYING is used when the audio is being
      rendered.
      Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
      9c0b8420
    • G
      OMAPDSS: VENC: allow switching venc output type at runtime · 0aca3c63
      Grazvydas Ignotas 提交于
      VENC output type (composite/svideo) doesn't have to be fixed by board
      wiring, it is possible to also provide composite signal through svideo
      luminance connector (software enabled), which is what pandora does.
      
      Having to recompile the kernel for users who have TV connector types
      that don't match default board setting is very inconvenient, especially
      for users of a consumer device, so add support for switching VENC output
      type at runtime over a new sysfs file output_type.
      Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      0aca3c63
  2. 07 3月, 2012 1 次提交
  3. 27 11月, 2011 1 次提交
  4. 19 7月, 2011 1 次提交
    • D
      ARM: 6999/1: head, zImage: Always Enter the kernel in ARM state · 540b5738
      Dave Martin 提交于
      Currently, the documented kernel entry requirements are not
      explicit about whether the kernel should be entered in ARM or
      Thumb, leading to an ambiguitity about how to enter Thumb-2
      kernels.  As a result, the kernel is reliant on the zImage
      decompressor to enter the kernel proper in the correct instruction
      set state.
      
      This patch changes the boot entry protocol for head.S and Image to
      be the same as for zImage: in all cases, the kernel is now entered
      in ARM.
      
      Documentation/arm/Booting is updated to reflect this new policy.
      
      A different rule will be needed for Cortex-M class CPUs as and when
      support for those lands in mainline, since these CPUs don't support
      the ARM instruction set at all: a note is added to the effect that
      the kernel must be entered in Thumb on such systems.
      Signed-off-by: NDave Martin <dave.martin@linaro.org>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      540b5738
  5. 18 7月, 2011 1 次提交
    • N
      ARM: mach-s3c2400: delete · 632b7cf6
      Nicolas Pitre 提交于
      On Tue, 28 Jun 2011, Ben Dooks wrote:
      
      > On Tue, Jun 28, 2011 at 11:22:57PM +0200, Arnd Bergmann wrote:
      >
      > > On a related note, what about mach-s3c2400? It seems to be even more
      > > incomplete.
      >
      > Probably the same fate awaits that. It is so old that there's little
      > incentive to do anything with it.
      
      So out it goes as well.
      
      The PORT_S3C2400 definition in include/linux/serial_core.h is left there
      to prevent a reuse of the same number for another port type.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      632b7cf6
  6. 29 6月, 2011 2 次提交
  7. 20 6月, 2011 1 次提交
  8. 23 5月, 2011 1 次提交
  9. 12 5月, 2011 1 次提交
  10. 31 3月, 2011 1 次提交
  11. 14 2月, 2011 1 次提交
  12. 01 2月, 2011 1 次提交
  13. 25 1月, 2011 2 次提交
    • S
      ARM: 6617/1: mmc, Add zboot from MMC support for SuperH Mobile ARM · f45b1149
      Simon Horman 提交于
      This allows a ROM-able zImage to be written to MMC and
      for SuperH Mobile ARM to boot directly from the MMCIF
      hardware block.
      
      This is achieved by the MaskROM loading the first portion
      of the image into MERAM and then jumping to it. This portion
      contains loader code which copies the entire image to SDRAM
      and jumps to it. From there the zImage boot code proceeds
      as normal, uncompressing the image into its final location
      and then jumping to it.
      
      Cc: Magnus Damm <magnus.damm@gmail.com>
      
      Russell, please consider merging this for 2.6.38.
      
      This patch depends on:
      * "mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h"
        which will be merged though Paul Mundt's rmobile sh-2.6.
        The absence of this patch will break the build if
        the (new) CONFIG_ZBOOT_ROM_MMCIF option is set.
        There are no subtle side-effects.
      
      v2:
      Addressed comments by Magnus Damm
      * Fix copyright in vrl4.c
      * Fix use of #define CONFIG_ZBOOT_ROM_MMCIF in mmcif-sh7372.c
      * Initialise LED GPIO lines in head-ap4evb.txt instead of mmcif-sh7372.c
        as this is considered board-specific.
      
      v3:
      Addressed comments made in person by Magnus Damm
      * Move mmcif_loader to be earlier in the image and
        reduce the number of blocks of boot program loaded by the MaskRom
        from 40 to 8 accordingly.
      * Move LED GPIO initialisation into mmcif_progress_init
        - This leaves the partner jet script unbloated
      Other
      * inline mmcif_update_progress so it is a static inline in a header file
      
      v4:
      * Use htole16() and htole32() in v4rl.c to ensure
        that the output is little endian
      
      v5:
      Addressed comments by Russell King
      * Simplify assembly code
      * Jump to code rather than an address <- bug fix
      * Use (void __iomem *) as appropriate
      Roll in mackerel support
      * This was previously a separate patch, only because of the order
        in which this code was developed
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f45b1149
    • R
      ARM: lh7a40x: remove unmaintained platform support · 82e6923e
      Russell King 提交于
      lh7a40x has only been receiving updates for updates to generic code.
      The last involvement from the maintainer according to the git logs was
      in 2006.  As such, it is a maintainence burden with no benefit.
      
      This gets rid of two defconfigs.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      82e6923e
  14. 22 12月, 2010 1 次提交
  15. 10 11月, 2010 1 次提交
  16. 04 11月, 2010 1 次提交
  17. 07 10月, 2010 1 次提交
  18. 10 8月, 2010 1 次提交
  19. 04 8月, 2010 1 次提交
    • J
      Documentation: update broken web addresses. · 0ea6e611
      Justin P. Mattock 提交于
      Below you will find an updated version from the original series bunching all patches into one big patch
      updating broken web addresses that are located in Documentation/*
      Some of the addresses date as far far back as 1995 etc... so searching became a bit difficult,
      the best way to deal with these is to use web.archive.org to locate these addresses that are outdated.
      Now there are also some addresses pointing to .spec files some are located, but some(after searching
      on the companies site)where still no where to be found. In this case I just changed the address
      to the company site this way the users can contact the company and they can locate them for the users.
      Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
      Signed-off-by: NThomas Weber <weber@corscience.de>
      Signed-off-by: NMike Frysinger <vapier.adi@gmail.com>
      Cc: Paulo Marques <pmarques@grupopie.com>
      Cc: Randy Dunlap <rdunlap@xenotime.net>
      Cc: Michael Neuling <mikey@neuling.org>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      0ea6e611
  20. 27 7月, 2010 1 次提交
    • L
      ARM: 6225/1: make TCM allocation static and common for all archs · 1dbd30e9
      Linus Walleij 提交于
      This changes the TCM handling so that a fixed area is reserved at
      0xfffe0000-0xfffeffff for TCM. This areas is used by XScale but
      XScale does not have TCM so the mechanisms are mutually exclusive.
      
      This change is needed to make TCM detection more dynamic while
      still being able to compile code into it, and is a must for the
      unified ARM goals: the current TCM allocation at different places
      in memory for each machine would be a nightmare if you want to
      compile a single image for more than one machine with TCM so it
      has to be nailed down in one place.
      Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1dbd30e9
  21. 28 5月, 2010 6 次提交
  22. 23 4月, 2010 1 次提交
  23. 14 4月, 2010 1 次提交
  24. 16 2月, 2010 1 次提交
  25. 09 2月, 2010 1 次提交
  26. 19 1月, 2010 1 次提交
  27. 15 1月, 2010 1 次提交
  28. 09 12月, 2009 1 次提交
  29. 01 12月, 2009 2 次提交
  30. 01 10月, 2009 1 次提交
  31. 16 9月, 2009 1 次提交