Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 11 9月, 2012 1 次提交
  3. 09 7月, 2012 2 次提交
  5. 26 6月, 2012 1 次提交
  7. 22 6月, 2012 1 次提交
    • P
      ARM: OMAP2+: HDQ1W: use omap_device · 96b1b29d
      由 Paul Walmsley 提交于 
      Convert the old-style device registration code for HDQ1W to use
omap_device.  This will allow the driver to be converted to use PM
runtime and to take advantage of the OMAP IP block management
infrastructure (hwmod, PM, etc.).

A side benefit of this conversion is that it also makes the HDQ device
available on OMAP2420.  The previous code only enabled it on 2430 and
3430.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>
Tested-by: NNeilBrown <neilb@suse.de>
      96b1b29d
  9. 10 5月, 2012 2 次提交
  11. 09 5月, 2012 2 次提交
  13. 18 4月, 2012 1 次提交
    • P
      ARM: OMAP2+: clean up some cppcheck warnings · eeb3711b
      由 Paul Walmsley 提交于 
      Resolve some warnings identified by cppcheck in arch/arm/mach-omap2:

    [arch/arm/mach-omap2/usb-tusb6010.c:129]: (style) Checking if unsigned variable 'tmp' is less than zero.
    [arch/arm/mach-omap2/prm_common.c:241]: (error) Possible null pointer dereference: irq_setup - otherwise it is redundant to check if irq_setup is null at line 247
    [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'per_clkdm' is assigned a value that is never used
    [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'core_clkdm' is assigned a value that is never used
    [arch/arm/mach-omap2/pm24xx.c:185]: (style) Variable 'only_idle' is assigned a value that is never used
    [arch/arm/mach-omap2/mux.c:254]: (error) Possible null pointer dereference: mux
    [arch/arm/mach-omap2/mux.c:258]: (error) Possible null pointer dereference: mux
    [arch/arm/mach-omap2/gpmc-onenand.c:178]: (style) Variable 'tick_ns' is assigned a value that is never used
    [arch/arm/mach-omap2/gpio.c:56]: (error) Possible null pointer dereference: pdata - otherwise it is redundant to check if pdata is null at line 57
    [arch/arm/mach-omap2/devices.c:45]: (style) Variable 'l' is assigned a value that is never used
    [arch/arm/mach-omap2/board-omap3evm.c:641] -> [arch/arm/mach-omap2/board-omap3evm.c:639]: (style) Found duplicate branches for if and else.
    [arch/arm/mach-omap2/am35xx-emac.c:95]: (style) Variable 'regval' is assigned a value that is never used
    [arch/arm/mach-omap2/devices.c:74]: (style) Variable 'l' is assigned a value that is never used
    [arch/arm/mach-omap2/pm34xx.c:277]: (style) Variable 'per_prev_state' is assigned a value that is never used
    [arch/arm/plat-omap/dmtimer.c:352]: (error) Possible null pointer dereference: timer - otherwise it is redundant to check if timer is null at line 354
    [arch/arm/plat-omap/omap_device.c:478]: (style) Variable 'c' is assigned a value that is never used
    [arch/arm/plat-omap/usb.c:42]: (style) Variable 'status' is assigned a value that is never used
    [arch/arm/mach-omap1/clock.c:197]: (style) Variable 'dpll1_rate' is assigned a value that is never used
    [arch/arm/mach-omap1/lcd_dma.c:60]: (style) struct or union member 'lcd_dma_info::size' is never used
    [arch/arm/mach-omap1/pm.c:572]: (style) Variable 'entry' is assigned a value that is never used

Some of them are pretty good catches, such as gpio.c:56 and
usb-tusb6010.c:129.

Thanks to Jarkko Nikula for some comments on the sscanf() warnings.
It seems that the kernel sscanf() ignores the field width anyway for the
%d format, so those changes have been dropped from this second version.

Thanks to Daniel Marjamäki <daniel.marjamaki@gmail.com> for pointing
out that a variable was unnecessarily marked static in the
board-omap3evm.c change.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Charulatha Varadarajan <charu@ti.com>
Cc: Daniel Marjamäki <daniel.marjamaki@gmail.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: Charulatha Varadarajan <charu@ti.com> # for gpio.c
      eeb3711b
  15. 17 3月, 2012 1 次提交
  17. 12 3月, 2012 2 次提交
  19. 25 2月, 2012 2 次提交
  21. 24 2月, 2012 1 次提交
    • T
      ARM: OMAP2+: Fix OMAP_HDQ_BASE build error · e3a98fe1
      由 Tony Lindgren 提交于 
      If CONFIG_SOC_OMAP3430 is not set and CONFIG_HDQ_MASTER_OMAP
is selected for w1 driver we get the following error:

arch/arm/mach-omap2/devices.c:662:13: error:
'OMAP_HDQ_BASE' undeclared here (not in a function)

Looks like OMAP_HDQ_BASE is valid for all omaps except
2420, so we can remove the ifdef and not register
the device on 2420.
Signed-off-by: NTony Lindgren <tony@atomide.com>
      e3a98fe1
  23. 27 1月, 2012 1 次提交
    • J
      ARM: OMAP2+: arch/arm/mach-omap2/devices.c: introduce missing kfree · e0feca89
      由 Julia Lawall 提交于 
      pdata needs to be freed before leaving the function in an error case.

A simplified version of the semantic match that finds the problem is as
follows: (http://coccinelle.lip6.fr)

// <smpl>
@r exists@
local idexpression x;
statement S;
identifier f1;
position p1,p2;
expression *ptr != NULL;
@@

x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
     when != if (...) { <+...x...+> }
x->f1
...>
(
 return \(0\|<+...x...+>\|ptr\);
|
 return@p2 ...;
)

@script:python@
p1 << r.p1;
p2 << r.p2;
@@

print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      e0feca89
  25. 16 1月, 2012 1 次提交
  27. 14 12月, 2011 1 次提交
  29. 05 12月, 2011 1 次提交
  31. 05 11月, 2011 1 次提交
    • P
      ARM: OMAP2+: devices: Fixes for McPDM · 927dbbb2
      由 Peter Ujfalusi 提交于 
      Commit f718e2c0 (ARM: OMAP2+: devices:
Remove all omap_device_pm_latency structures) removed these structures.
Commit 3528c58e (OMAP: omap_device:
when building return platform_device instead of omap_device) now
returns platform_device instead of omap_device.

Fix up the omap-mcpdm init function since this part comes via sound
tree, and there has been changes regarding to hwmod/omap_device_build.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
CC: Benoit Cousson <b-cousson@ti.com>
CC: Kevin Hilman <khilman@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: NTony Lindgren <tony@atomide.com>
      927dbbb2
  33. 05 10月, 2011 2 次提交
  35. 22 9月, 2011 1 次提交
  37. 16 9月, 2011 1 次提交
    • K
      OMAP: omap_device: when building return platform_device instead of omap_device · 3528c58e
      由 Kevin Hilman 提交于 
      All of the device init and device driver interaction with omap_device
is done using platform_device pointers.  To make this more explicit,
have omap_device return a platform_device pointer instead of an
omap_device pointer.

All current users of the omap_device pointer were only using it to get
at the platform_device pointer or struct device pointer, so fixing all
of the users was trivial.

This also makes it more difficult for device init code to directly
access members of struct omap_device, and allows for easier changing
of omap_device internals.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
      3528c58e
  39. 08 8月, 2011 1 次提交
  41. 05 7月, 2011 1 次提交
  43. 01 6月, 2011 1 次提交
  45. 31 3月, 2011 1 次提交
  47. 22 3月, 2011 4 次提交
  49. 19 3月, 2011 1 次提交
  51. 09 3月, 2011 2 次提交
  53. 02 3月, 2011 3 次提交
    • K
      OMAP: adapt hsmmc to hwmod framework · 4621d5f8
      由 Kishore Kadiyala 提交于 
      OMAP2420 platform consists of mmc block as in omap1 and not the
hsmmc block as present in omap2430, omap3, omap4 platforms.
Removing all base address macro defines except keeping one for OMAP2420 and
adapting only hsmmc device registration and driver to hwmod framework.

Changes involves:
1) Remove controller reset in devices.c which is taken care of
   by hwmod framework.
2) Using omap-device layer to register device and utilizing data from
   hwmod data file for base address, dma channel number, Irq_number,
   device attribute.
3) Update the driver to use dev_attr to find whether controller
   supports dual volt cards
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
Reviewed-by: NBalaji T K <balajitk@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
CC: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      4621d5f8
    • K
      OMAP: hsmmc: Move mux configuration to hsmmc.c · d8d0a61c
      由 Kishore Kadiyala 提交于 
      Moving the definition of mux setting API from devices.c to hsmmc.c
and renaming it from "omap2_mmc_mux" to "omap_hsmmc_mux".
Also calling "omap_hsmmc_mux" from omap2_hsmmc_init.
Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
Cc: Chris Ball <cjb@laptop.org
Cc: Tony Lindgren <tony@atomide.com
Signed-off-by: NTony Lindgren <tony@atomide.com>
      d8d0a61c
    • A
      omap: mmc: split out init for 2420 · e08016d0
      由 Anand Gadiyar 提交于 
      The MMC controller on the OMAP2420 is different from those
on the OMAP2430, OMAP3 and OMAP4 families - all of the latter
are identical. The one on the OMAP2420 is closer to that
on OMAP1 chips.

Currently, the n8x0 is the only OMAP2420 platform supported
in mainline which registers the MMC controller. Upcoming
changes to register the controllers using hwmod data are
potentially invasive. To reduce the risk, separate out the
2420 controller registration from the common init function
and update its only user. Also seperating out mux settings
for OMAP2420.
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Chris Ball <cjb@laptop.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      e08016d0
  55. 25 2月, 2011 1 次提交