Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 07 4月, 2013 1 次提交
    • A
      spi: Initialize cs_gpio and cs_gpios with -ENOENT · 446411e1
      由 Andreas Larsson 提交于 
      The return value from of_get_named_gpio is -ENOENT when the given index
matches a hole in the "cs-gpios" property phandle list. However, the
default value of cs_gpio in struct spi_device and entries of cs_gpios in
struct spi_master is -EINVAL, which is documented to indicate that a
GPIO line should not be used for the given spi_device.

This sets the default value of cs_gpio in struct spi_device and entries
of cs_gpios in struct spi_master to -ENOENT. Thus, -ENOENT is the only
value used to indicate that no GPIO line should be used.
Signed-off-by: NAndreas Larsson <andreas@gaisler.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      446411e1
  3. 11 2月, 2013 1 次提交
  5. 09 2月, 2013 1 次提交
    • L
      spi: Add helper functions for setting up transfers · 6d9eecd4
      由 Lars-Peter Clausen 提交于 
      Quite often the pattern used for setting up and transferring a synchronous SPI
transaction looks very much like the following:

	struct spi_message msg;
	struct spi_transfer xfers[] = {
		...
	};

	spi_message_init(&msg);
	spi_message_add_tail(&xfers[0], &msg);
	...
	spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);

	ret = spi_sync(&msg);

This patch adds two new helper functions for handling this case. The first
helper function spi_message_init_with_transfers() takes a spi_message and an
array of spi_transfers. It will initialize the message and then call
spi_message_add_tail() for each transfer in the array. E.g. the following

	spi_message_init(&msg);
	spi_message_add_tail(&xfers[0], &msg);
	...
	spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);

can be rewritten as

	spi_message_init_with_transfers(&msg, xfers, ARRAY_SIZE(xfers));

The second function spi_sync_transfer() takes a SPI device and an array of
spi_transfers. It will allocate a new spi_message (on the stack) and add all
transfers in the array to the message. Finally it will call spi_sync() on the
message.

E.g. the follwing

	struct spi_message msg;
	struct spi_transfer xfers[] = {
		...
	};

	spi_message_init(&msg);
	spi_message_add_tail(&xfers[0], &msg);
	...
	spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);

	ret = spi_sync(spi, &msg);

can be rewritten as

	struct spi_transfer xfers[] = {
		...
	};

	ret = spi_sync_transfer(spi, xfers, ARRAY_SIZE(xfers));

A coccinelle script to find such instances will follow.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      6d9eecd4
  7. 08 2月, 2013 3 次提交
  9. 31 1月, 2013 1 次提交
  11. 26 1月, 2013 1 次提交
  13. 08 1月, 2013 1 次提交
    • M
      spi/pxa2xx: embed the ssp_device to platform data · 851bacf5
      由 Mika Westerberg 提交于 
      The spi-pxa2xx-pci glue driver had to implement pxa_ssp_request()/free() in
order to support the spi-pxa2xx platform driver. Since the ACPI enabled
platforms can use the same platform driver we would need to implement
pxa_ssp_request()/free() in some central place that can be shared by the
ACPI and PCI glue code.

Instead of doing that we can make pxa_ssp_request()/free() to be available
only when CONFIG_ARCH_PXA is set. On other arches these are being stubbed
out in preference to passing the ssp_device from the platform data
directly.

We also change the SPI bus number to be taken from ssp->port_id instead of
platform device id. This way the supporting code that passes the ssp can
decide the number (or it can set it to the same as pdev->id).
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      851bacf5
  15. 22 11月, 2012 2 次提交
  17. 31 10月, 2012 1 次提交
  19. 17 10月, 2012 2 次提交
    • D
      UAPI: Remove empty non-UAPI Kbuild files · 64d7155c
      由 David Howells 提交于 
      Remove non-UAPI Kbuild files that have become empty as a result of UAPI
disintegration.  They used to have only header-y lines in them and those have
now moved to the Kbuild files in the corresponding uapi/ directories.

Possibly these should not be removed but rather have a comment inserted to say
they are intentionally left blank.  This would make it easier to add generated
header lines in future without having to restore the infrastructure.

Note that at this point not all the UAPI disintegration parts have been merged,
so it is likely that more empty Kbuild files will turn up.

It is probably necessary to make the files non-empty to prevent the patch
program from automatically deleting them when it reduces them to nothing.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
      64d7155c
    • A
      spi: tsc2005: delete soon-obsolete e-mail address · 2f5f1ce9
      由 Aaro Koskinen 提交于 
      Delete soon-obsolete e-mail address.
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      2f5f1ce9
  21. 09 10月, 2012 1 次提交
  23. 18 8月, 2012 6 次提交
  25. 07 7月, 2012 1 次提交
  27. 27 6月, 2012 1 次提交
  29. 11 6月, 2012 1 次提交
  31. 20 5月, 2012 1 次提交
  33. 09 5月, 2012 1 次提交
  35. 28 4月, 2012 1 次提交
  37. 19 4月, 2012 1 次提交
  39. 16 3月, 2012 2 次提交
    • P
      device.h: audit and cleanup users in main include dir · 313162d0
      由 Paul Gortmaker 提交于 
      The <linux/device.h> header includes a lot of stuff, and
it in turn gets a lot of use just for the basic "struct device"
which appears so often.

Clean up the users as follows:

1) For those headers only needing "struct device" as a pointer
in fcn args, replace the include with exactly that.

2) For headers not really using anything from device.h, simply
delete the include altogether.

3) For headers relying on getting device.h implicitly before
being included themselves, now explicitly include device.h

4) For files in which doing #1 or #2 uncovers an implicit
dependency on some other header, fix by explicitly adding
the required header(s).

Any C files that were implicitly relying on device.h to be
present have already been dealt with in advance.

Total removals from #1 and #2: 51.  Total additions coming
from #3: 9.  Total other implicit dependencies from #4: 7.

As of 3.3-rc1, there were 110, so a net removal of 42 gives
about a 38% reduction in device.h presence in include/*
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      313162d0
    • A
      ARM: orion: spi: remove enable_clock_fix which is not used · d34b7d45
      由 Andrew Lunn 提交于 
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      d34b7d45
  41. 15 3月, 2012 1 次提交
  43. 10 3月, 2012 2 次提交
  45. 08 3月, 2012 1 次提交
    • L
      spi: create a message queueing infrastructure · ffbbdd21
      由 Linus Walleij 提交于 
      This rips the message queue in the PL022 driver out and pushes
it into (optional) common infrastructure. Drivers that want to
use the message pumping thread will need to define the new
per-messags transfer methods and leave the deprecated transfer()
method as NULL.

Most of the design is described in the documentation changes that
are included in this patch.

Since there is a queue that need to be stopped when the system
is suspending/resuming, two new calls are implemented for the
device drivers to call in their suspend()/resume() functions:
spi_master_suspend() and spi_master_resume().

ChangeLog v1->v2:
- Remove Kconfig entry and do not make the queue support optional
  at all, instead be more agressive and have it as part of the
  compulsory infrastructure.
- If the .transfer() method is implemented, delete print a small
  deprecation notice and do not start the transfer pump.
- Fix a bitrotted comment.
ChangeLog v2->v3:
- Fix up a problematic sequence courtesy of Chris Blair.
- Stop rather than destroy the queue on suspend() courtesy of
  Chris Blair.
Signed-off-by: NChris Blair <chris.blair@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      ffbbdd21
  47. 31 1月, 2012 1 次提交
  49. 18 11月, 2011 1 次提交
  51. 01 11月, 2011 1 次提交
    • M
      backlight: fix broken regulator API usage in l4f00242t03 · 0556dc34
      由 Mark Brown 提交于 
      The regulator support in the l4f00242t03 is very non-idiomatic.  Rather
than requesting the regulators based on the device name and the supply
names used by the device the driver requires boards to pass system
specific supply names around through platform data.  The driver also
conditionally requests the regulators based on this platform data, adding
unneeded conditional code to the driver.

Fix this by removing the platform data and converting to the standard
idiom, also updating all in tree users of the driver.  As no datasheet
appears to be available for the LCD I'm guessing the names for the
supplies based on the existing users and I've no ability to do anything
more than compile test.

The use of regulator_set_voltage() in the driver is also problematic,
since fixed voltages are required the expectation would be that the
voltages would be fixed in the constraints set by the machines rather than
manually configured by the driver, but is less problematic.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0556dc34
  53. 16 7月, 2011 1 次提交
  55. 04 6月, 2011 1 次提交
  57. 20 5月, 2011 1 次提交