Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 26 11月, 2012 11 次提交
  3. 22 11月, 2012 1 次提交
    • I
      ARM - OMAP: ads7846: fix pendown debounce setting · 0a0d6285
      由 Igor Grinberg 提交于 
      Commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code) have enabled the
pendown GPIO debounce time setting by the below sequence:

  gpio_request_one()
  gpio_set_debounce()
  gpio_free()

It also revealed a bug in the OMAP GPIO handling code which prevented
the GPIO debounce clock to be disabled and CORE transition to low power
states.

Commit c9c55d92 (gpio/omap: fix off-mode bug: clear debounce settings on
free/reset) fixes the OMAP GPIO handling code by making sure that the
GPIO debounce clock gets disabled if no GPIO is requested from current
bank.

While fixing the OMAP GPIO handling code (in the right way), the above
commit makes the gpio_request->set_debounce->free sequence invalid as
after freeing the GPIO, the debounce settings are lost.

Fix the debounce settings by moving the debounce initialization to the
actual GPIO requesting code - the ads7846 driver.
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      0a0d6285
  5. 20 11月, 2012 1 次提交
  7. 19 11月, 2012 1 次提交
    • L
      ARM: davinci: dm644x: fix out range signal for ED · e37212aa
      由 Lad, Prabhakar 提交于 
      Fix the video clock setting when custom timings are used with
pclock <= 27MHz. Existing video clock selection uses PLL2 mode
which results in a 54MHz clock whereas using the MXI mode results
in a 27MHz clock (which is the one actually desired).

This bug affects the Enhanced Definition (ED) support on DM644x.
Without this patch, out-range signals errors are were observed on
the TV when viewing ED. An out-of-range signal is often caused when
the field rate is above the rate that the television will handle.
Signed-off-by: NLad, Prabhakar <prabhakar.lad@ti.com>
Signed-off-by: NManjunath Hadli <manjunath.hadli@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
[nsekhar@ti.com: reword commit message based on on-list discussion]
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      e37212aa
  9. 18 11月, 2012 1 次提交
  11. 16 11月, 2012 4 次提交
  13. 14 11月, 2012 1 次提交
  15. 13 11月, 2012 2 次提交
    • F
      ARM: boot: Fix usage of kecho · 2d4d07b9
      由 Fabio Estevam 提交于 
      Since commit edc88ceb (ARM: be really quiet when building with 'make -s') the
following output is generated when building a kernel for ARM:

echo '  Kernel: arch/arm/boot/Image is ready'
  Kernel: arch/arm/boot/Image is ready
  Building modules, stage 2.
echo '  Kernel: arch/arm/boot/zImage is ready'
  Kernel: arch/arm/boot/zImage is ready

As per Documentation/kbuild/makefiles.txt the correct way of using kecho is
'@$(kecho)'.

Make this change so no more unwanted 'echo' messages are displayed.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      2d4d07b9
    • K
      ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC · 1ef43369
      由 Kevin Hilman 提交于 
      On OMAP4 boards using the TWL6030 PMIC, the sys_drm_msecure is
connected to the MSECURE input of the TWL6030 PMIC.  This signal
controls the secure-mode operation of the PMIC.  If its not mux'd
correctly, some functionality of the PMIC will not be accessible since
the PMIC will be in secure mode.

For example, if the TWL RTC is in secure mode, most of its registers
are read-only, meaning (re)programming the RTC (e.g. for wakeup from
suspend) will fail.

To fix, ensure the signal is properly mux'd as output when TWL is
intialized.

This fix is required when using recent versions of u-boot (>= v2012.04.01)
since u-boot is no longer setting the default mux for this pin.
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      1ef43369
  17. 12 11月, 2012 3 次提交
  19. 09 11月, 2012 1 次提交
  21. 08 11月, 2012 3 次提交
  23. 07 11月, 2012 1 次提交
  25. 06 11月, 2012 2 次提交
  27. 04 11月, 2012 1 次提交
  29. 31 10月, 2012 3 次提交
    • P
      ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init · bc05244e
      由 Paul Walmsley 提交于 
      Resolve this kernel boot message:

omap_hwmod: mcpdm: cannot be enabled for reset (3)

The McPDM on OMAP4 can only receive its functional clock from an
off-chip source.  This source is not guaranteed to be present on the
board, and when present, it is controlled by I2C.  This would
introduce a board dependency to the early hwmod code which it was not
designed to handle.  Also, neither the driver for this off-chip clock
provider nor the I2C code is available early in boot when the hwmod
code is attempting to enable and reset IP blocks.  This effectively
makes it impossible to enable and reset this device during hwmod init.

At its core, this patch is a workaround for an OMAP hardware problem.
It should be possible to configure the OMAP to provide any IP block's
functional clock from an on-chip source.  (This is true for almost
every IP block on the chip.  As far as I know, McPDM is the only
exception.)  If the kernel cannot reset and configure IP blocks, it
cannot guarantee a sane SoC state.  Relying on an optional off-chip
clock also creates a board dependency which is beyond the scope of the
early hwmod code.

This patch works around the issue by marking the McPDM hwmod record
with the HWMOD_EXT_OPT_MAIN_CLK flag.  This prevents the hwmod
code from touching the device early during boot.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Péter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      bc05244e
    • P
      ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block during init · 5fb3d522
      由 Paul Walmsley 提交于 
      Add HWMOD_EXT_OPT_MAIN_CLK flag to indicate that this IP block is
dependent on an off-chip functional clock that is not guaranteed to be
present during initialization.  IP blocks marked with this flag are
left in the INITIALIZED state during kernel init.

This is a workaround for a hardware problem.  It should be possible to
guarantee that at least one clock source will be present and active
for any IP block's main functional clock.  This ensures that the hwmod
code can enable and reset the IP block.  Resetting the IP block during
kernel init prevents any bogus bootloader, ROM code, or previous OS
configuration from affecting the kernel.  Hopefully a clock
multiplexer can be added on future SoCs.

N.B., at some point in the future, it should be possible to query the
clock framework for this type of information.  Then this flag should
no longer be needed.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      5fb3d522
    • P
      ARM: dt: tegra: fix length of pad control and mux registers · 322337b8
      由 Pritesh Raithatha 提交于 
      The reg property contains <base length> not <base last_offset>. Fix
the length values to be length not last_offset.

Cc: stable@vger.kernel.org
Signed-off-by: NPritesh Raithatha <praithatha@nvidia.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
      322337b8
  31. 30 10月, 2012 3 次提交
  33. 29 10月, 2012 1 次提交