Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 18 12月, 2012 1 次提交
  3. 01 11月, 2012 1 次提交
    • T
      ARM: OMAP1: Remove relative includes · 4e969010
      由 Tony Lindgren 提交于 
      As discussed on linux-arm-kernel, we want to avoid
relative includes for the arch/arm/*omap* code:

http://www.spinics.net/lists/linux-omap/msg80520.html

Note that eventually when the omap1 specific drivers
are fixed to not use cpu_is_omap macros and not depend
on mach/hardware.h, this patch can be reverted and these
headers can be local. But since just fixing the drivers for
omap2+ is already a big enough hassle, let's deal
with that properly first.

[tony@atomide.com: also drop unused include for ispvideo.c]
Signed-off-by: NTony Lindgren <tony@atomide.com>
      4e969010
  5. 19 10月, 2012 2 次提交
  7. 13 9月, 2012 1 次提交
    • T
      ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+ · dbc04161
      由 Tony Lindgren 提交于 
      As the plat and mach includes need to disappear for single zImage work,
we need to remove plat/hardware.h.

Do this by splitting plat/hardware.h into omap1 and omap2+ specific files.

The old plat/hardware.h already has omap1 only defines, so it gets moved
to mach/hardware.h for omap1. For omap2+, we use the local soc.h
that for now just includes the related SoC headers to keep this patch more
readable.

Note that the local soc.h still includes plat/cpu.h that can be dealt
with in later patches. Let's also include plat/serial.h from common.h for
all the board-*.c files. This allows making the include files local later
on without patching these files again.

Note that only minimal changes are done in this patch for the
drivers/watchdog/omap_wdt.c driver to keep things compiling. Further
patches are needed to eventually remove cpu_is_omap usage in the drivers.

Also only minimal changes are done to sound/soc/omap/* to remove the
unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's
no need to include omap44xx.h.

While at it, also sort some of the includes in the standard way.

Cc: linux-watchdog@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Liam Girdwood <lrg@ti.com>
Acked-by: NWim Van Sebroeck <wim@iguana.be>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      dbc04161
  9. 08 8月, 2012 1 次提交
  11. 09 7月, 2012 1 次提交
  13. 05 7月, 2012 2 次提交
    • V
      ARM: OMAP2+: am33xx: Change cpu_is_am33xx to soc_is_am33xx · 971b8a9c
      由 Vaibhav Hiremath 提交于 
      As per recent discussion on the linux-omap list, we are
moving in the direction where, we will have only architecture,
ARCH_OMAP2PLUS and all devices/platforms will be treated
as a SoC underneath.

So the first step in this direction is to adopt this change
for all new devices getting in, converting
cpu_is_am33xx/335x() ==> soc_is_am33xx/335x()
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      971b8a9c
    • V
      ARM: OMAP2+: am33xx: Make am33xx as a separate class · 1c213ba1
      由 Vaibhav Hiremath 提交于 
      Initially, we decided to make am33xx family of device to fall
under omap3 class (cpu_is_omap34xx() = true), since it carries
Cortex-A8 core. But while adding complete baseport support
(like, clock, power and hwmod) support, it is observed that,
we are creating more and more problems by treating am33xx device
as omap3 family, as nothing matches between them
(except cortex-A8 mpu).

So,  after long discussion we have came to the conclusion that,
we should not consider am33xx device as omap3 family, instead
create separate class (SOC_AM33XX) under OMAP2PLUS.
This means, for am33xx device, cpu_is_omap34xx() will return false,
and only cpu_is_am33xx() will be true.

Please refer to the link below, for mailing-list discussion on this -

http://www.spinics.net/lists/linux-omap/msg69439.htmlSigned-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
[tony@atomide.com: fixed typo, updated for soc_is changes]
Signed-off-by: NTony Lindgren <tony@atomide.com>
      1c213ba1
  15. 28 6月, 2012 2 次提交
  17. 26 5月, 2012 1 次提交
  19. 11 5月, 2012 1 次提交
  21. 10 5月, 2012 1 次提交
  23. 06 3月, 2012 1 次提交
  25. 20 12月, 2011 1 次提交
  27. 14 12月, 2011 5 次提交
  29. 08 10月, 2011 1 次提交
    • P
      ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection · b02b9172
      由 Paul Walmsley 提交于 
      The way that we detect which OMAP3 chips support I/O wakeup and
software I/O chain clock control is broken.

Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
than the AM3505/3517.  The TI81xx family of SoCs are at present
considered to be OMAP3 SoCs, but don't support I/O wakeup.  To resolve
this, convert the existing blacklist approach to an explicit,
whitelist support, in which only SoCs which are known to support I/O
wakeup are listed.  (At present, this only includes OMAP34xx,
OMAP3503, OMAP3515, OMAP3525, OMAP3530, and OMAP36xx.)

Also, the current code incorrectly detects the presence of a
software-controllable I/O chain clock on several chips that don't
support it.  This results in writes to reserved bitfields, unnecessary
delays, and console messages on kernels running on those chips:

    http://www.spinics.net/lists/linux-omap/msg58735.html

Convert this test to a feature test with a chip-by-chip whitelist.

Thanks to Dave Hylands <dhylands@gmail.com> for reporting this problem
and doing some testing to help isolate the cause.  Thanks to Steve
Sakoman <sakoman@gmail.com> for catching a bug in the first version of
this patch.  Thanks to Russell King <linux@arm.linux.org.uk> for
comments.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Dave Hylands <dhylands@gmail.com>
Cc: Steve Sakoman <sakoman@gmail.com>
Tested-by: NSteve Sakoman <sakoman@gmail.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: NKevin Hilman <khilman@ti.com>
      b02b9172
  31. 15 9月, 2011 3 次提交
  33. 14 9月, 2011 1 次提交
    • P
      OMAP3: id: remove identification codes that only correspond to marketing names · 1f1b0353
      由 Paul Walmsley 提交于 
      The OMAP3505/AM3505 appears to be based on the same silicon as the
OMAP3517/AM3517, with some features disabled via eFuse bits.  Follow
the same practice as OMAP3430 and identify these devices internally as
part of the OMAP3517/AM3517 family.

The OMAP3503/3515/3525/3530 chips appear to be based on the same silicon
as the OMAP3430, with some features disabled via eFuse bits.  Identify
these devices internally as part of the OMAP3430 family.

Remove the old OMAP35XX_CLASS, which actually covered two very different
chip families.  The OMAP3503/3515/3525/3530 chips will now be covered by
OMAP343X_CLASS, since the silicon appears to be identical.  For the
OMAP3517/AM3517 family, create a new class, OMAP3517_CLASS.

Thanks to Tony Lindgren <tony@atomide.com> for some help with the second
revision of this patch.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>
      1f1b0353
  35. 08 7月, 2011 2 次提交
  37. 18 2月, 2011 1 次提交
  39. 17 2月, 2011 1 次提交
  41. 28 1月, 2011 1 次提交
  43. 02 10月, 2010 1 次提交
  45. 24 9月, 2010 1 次提交
  47. 04 8月, 2010 1 次提交
    • A
      OMAP3630: Add ES1.1 and ES1.2 detection · b0a1a6ce
      由 Anand Gadiyar 提交于 
      Add revision detection for ES1.1 and ES1.2. Set default
revision as ES1.2.

Add CHIP_GE_OMAP3630ES1_1 to detect revisions 1.1 and later.
This is needed for at least one feature that is broken in
3630ES1.0 but exists on older (3430 ES3.1) and newer revisions.

Additionally, update some of the CHIP_GE_* macros to use other
macros for ease of maintenance.
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Manjunatha GK <manjugk@ti.com>
[tony@atomide.com: update to remove fallthrough handling]
Signed-off-by: NTony Lindgren <tony@atomide.com>
      b0a1a6ce
  49. 02 8月, 2010 1 次提交
  51. 12 3月, 2010 1 次提交
  53. 25 2月, 2010 1 次提交
    • V
      OMAP3 clock: add support for 192Mhz DPLL4M2 output · 7356f0b2
      由 Vishwanath BS 提交于 
      In 3630, DPLL4M2 output can be 96MHz or 192MHz (for SGX to run at
192). This patch has changes to support this feature. 96MHz clock is
generated by dividing 192Mhz clock by 2 using CM_CLKSEL_CORE register.
SGX can select Core Clock, 192MHz clock or CM_96M_FCLK as it's
functional clock. In summary changes done are:
1. Added a feature called omap3_has_192mhz_clk and enabled for 3630
2. Added a new clock node called omap_192m_alwon_ck
3. Made omap_96m_alwon_fck to derive its clock from omap_192m_alwon_ck
Signed-off-by: NVishwanath BS <Vishwanath.bs@ti.com>
[paul@pwsan.com: fixed whitespace]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      7356f0b2
  55. 16 2月, 2010 3 次提交