05 Jan, 2016
1 commit
-
The separate struct bgpio_chip has been a pain to handle, both
by being confusingly similar in name to struct gpio_chip and
for being contained inside a struct so that struct gpio_chip
is contained in a struct contained in a struct, making several
steps of dereferencing necessary.Make things simpler: include the fields directly into
, #ifdef:ed for CONFIG_GENERIC_GPIO, and
get rid of the altogether. Prefix
some of the member variables with bgpio_* and add proper
kerneldoc while we're at it.Modify all users to handle the change and use a struct
gpio_chip directly. And while we're at it: replace all
container_of() dereferencing by gpiochip_get_data() and
registering the gpio_chip with gpiochip_add_data().Cc: arm@kernel.org
Cc: Alexander Shiyan
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Kukjin Kim
Cc: Alexandre Courbot
Cc: Brian Norris
Cc: Florian Fainelli
Cc: Sudeep Holla
Cc: Lorenzo Pieralisi
Cc: Nicolas Pitre
Cc: Olof Johansson
Cc: Vladimir Zapolskiy
Cc: Rabin Vincent
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: bcm-kernel-feedback-list@broadcom.com
Acked-by: Gregory Fong
Acked-by: Liviu Dudau
Acked-by: H Hartley Sweeten
Acked-by: Tony Lindgren
Acked-by: Krzysztof Kozlowski
Acked-by: Lee Jones
Signed-off-by: Linus Walleij
04 Mar, 2015
1 commit
-
Now, as all VE platforms have to be booted with DT,
the code handling non-DT case can be removed.Signed-off-by: Pawel Moll
Signed-off-by: Lee Jones
04 Nov, 2014
1 commit
-
The device tree structure is composed of two lists; the 'allnodes' list
which is a singly linked list containing every node in the tree, and the
child->parent structure where each parent node has a singly linked list
of children. All of the data in the allnodes list can be easily
reproduced with the parent-child lists, so of_allnodes is actually
unnecessary. Remove it entirely which saves a bit of memory and
simplifies the data structure quite a lot.Signed-off-by: Grant Likely
Cc: Rob Herring
Cc: Gaurav Minocha
Cc: Pantelis Antoniou
16 May, 2014
3 commits
-
The last reason for static memory mapping is the HBI (board
identification number) check early in the machine code.Moving the check to the sysreg driver makes it possible to
completely remove the early mapping and init functions.Signed-off-by: Pawel Moll
Acked-by: Lee Jones -
This patch - finally, after over 6 months! :-( - addresses
Samuel's request to split the vexpress-sysreg driver into
smaller portions and define the device in a form of MFD
cells:* LEDs code has been completely removed and replaced with
"gpio-leds" nodes in the tree (referencing dedicated
GPIO subnodes in sysreg - bindings documentation updated);
this also better fits the reality as some variants of the
motherboard don't have all the LEDs populated* syscfg bridge code has been extracted into a separate
driver (placed in drivers/misc for no better place)* all the ID & MISC registers are defined as sysconf
making them available for other drivers should they need
to use them (and also to the user via /sys/kernel/debug/regmap
which can be helpful in platform debugging)Signed-off-by: Pawel Moll
Acked-by: Lee Jones -
Components of the Versatile Express platform (configuration
microcontrollers on motherboard and daughterboards in particular)
talk to each other over a custom configuration bus. They
provide miscellaneous functions (from clock generator control
to energy sensors) which are represented as platform devices
(and Device Tree nodes). The transactions on the bus can
be generated by different "bridges" in the system, some
of which are universal for the whole platform (for the price
of high transfer latencies), others restricted to a subsystem
(but much faster).Until now drivers for such functions were using custom "func"
API, which is being replaced in this patch by regmap calls.
This required:* a rework (and move to drivers/bus directory, as suggested
by Samuel and Arnd) of the config bus core, which is much
simpler now and uses device model infrastructure (class)
to keep track of the bridges; non-DT case (soon to be
retired anyway) is simply covered by a special device
registration function* the new config-bus driver also takes over device population,
so there is no need for special matching table for
of_platform_populate nor "simple-bus" hack in the arm64
model dtsi file (relevant bindings documentation has
been updated); this allows all the vexpress devices
fit into normal device model, making it possible
to remove plenty of early inits and other hacks in
the near future* adaptation of the syscfg bridge implementation in the
sysreg driver, again making it much simpler; there is
a special case of the "energy" function spanning two
registers, where they should be both defined in the tree
now, but backward compatibility is maintained in the code* modification of the relevant drivers:
* hwmon - just a straight-forward API change
* power/reset driver - API change
* regulator - API change plus error handling
simplification
* osc clock driver - this one required larger rework
in order to turn in into a standard platform driverSigned-off-by: Pawel Moll
Acked-by: Mark Brown
Acked-by: Lee Jones
Acked-by: Guenter Roeck
Acked-by: Mike Turquette
19 Mar, 2014
1 commit
-
'site' variable should be initialized with 0 so that when 'site'
property doesn't exist in DTB it can be handled correctly.'0' value means board site number is motherboard (see
Documentation/devicetree/bindings/arm/vexpress.txt for details).Signed-off-by: Semen Protsenko
Signed-off-by: Lee Jones
19 Jun, 2013
1 commit
-
The driver can be used on either arm or arm64 platforms, but
the latter doesn't have any platform-specific configuration
options, so it must be possible to manually enable the driver.As the gpiolib is optional for arm64 arch, the gpio/led code
must be compiled conditionally.Signed-off-by: Pawel Moll
Acked-by: Catalin Marinas
Signed-off-by: Samuel Ortiz
09 Apr, 2013
1 commit
-
The registration of the "leds-gpio" device was using
"vexpress_sysreg_dev" as a parent before it was actually
set to something different than NULL.Trivial fix by reordering the code.
Reported-by: Lorenzo Pieralisi
Signed-off-by: Pawel Moll
Signed-off-by: Samuel Ortiz
25 Feb, 2013
1 commit
-
Pull MFS updates from Samuel Ortiz:
"This is the MFD pull request for the 3.9 merge window.No new drivers this time, but a bunch of fairly big cleanups:
- Roger Quadros worked on a OMAP USBHS and TLL platform data
consolidation, OMAP5 support and clock management code cleanup.- The first step of a major sync for the ab8500 driver from Lee
Jones. In particular, the debugfs and the sysct interfaces got
extended and improved.- Peter Ujfalusi sent a nice patchset for cleaning and fixing the
twl-core driver, with a much needed module id lookup code
improvement.- The regular wm5102 and arizona cleanups and fixes from Mark Brown.
- Laxman Dewangan extended the palmas APIs in order to implement the
palmas GPIO and rt drivers.- Laxman also added DT support for the tps65090 driver.
- The Intel SCH and ICH drivers got a couple fixes from Aaron Sierra
and Darren Hart.- Linus Walleij patchset for the ab8500 driver allowed ab8500 and
ab9540 based devices to switch to the new abx500 pin-ctrl driver.- The max8925 now has device tree and irqdomain support thanks to
Qing Xu.- The recently added rtsx driver got a few cleanups and fixes for a
better card detection code path and now also supports the RTS5227
chipset, thanks to Wei Wang and Roger Tseng."* tag 'mfd-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6: (109 commits)
mfd: lpc_ich: Use devres API to allocate private data
mfd: lpc_ich: Add Device IDs for Intel Wellsburg PCH
mfd: lpc_sch: Accomodate partial population of the MFD devices
mfd: da9052-i2c: Staticize da9052_i2c_fix()
mfd: syscon: Fix sparse warning
mfd: twl-core: Fix kernel panic on boot
mfd: rtsx: Fix issue that booting OS with SD card inserted
mfd: ab8500: Fix compile error
mfd: Add missing GENERIC_HARDIRQS dependecies
Documentation: Add docs for max8925 dt
mfd: max8925: Add dts
mfd: max8925: Support dt for backlight
mfd: max8925: Fix onkey driver irq base
mfd: max8925: Fix mfd device register failure
mfd: max8925: Add irqdomain for dt
mfd: vexpress: Allow vexpress-sysreg to self-initialise
mfd: rtsx: Support RTS5227
mfd: rtsx: Implement driving adjustment to device-dependent callbacks
mfd: vexpress: Add pseudo-GPIO based LEDs
mfd: ab8500: Rename ab8500 to abx500 for hwmon driver
...
14 Feb, 2013
2 commits
-
The vexpress_sysreg_init() is a core_initcall() already and it can
trigger the early initialisation if a matching node is found. This patch
allows the SoC code to avoid calling vexpress_sysreg_of_early_init()
explicitly.Signed-off-by: Catalin Marinas
Acked-by: Arnd Bergmann
Acked-by: Pawel Moll
Signed-off-by: Samuel Ortiz -
The LEDs on the Versatile Express motherboard are controlled
through simple memory-mapped register. This patch extends
the pseudo-GPIO controller definition for these lines and
creates generic "leds-gpio" device using themSigned-off-by: Pawel Moll
Signed-off-by: Samuel Ortiz
29 Jan, 2013
1 commit
-
The patch 52666298a 'mfd: vexpress-sysreg: Don't skip initialization
on probe' adds a call to vexpress_sysreg_setup from a non-__init
function, so this also has to lose its __init annotation.Signed-off-by: Arnd Bergmann
Cc: Pawel Moll
Cc: arm@kernel.org
Signed-off-by: Olof Johansson
24 Jan, 2013
1 commit
-
The vexpress-sysreg driver does not have to be initialized
early, when the platform doesn't require this. Unfortunately
in such case it wasn't initialized correctly - master site
lookup and config bridge registration were missing. Fixed now.Signed-off-by: Pawel Moll
04 Jan, 2013
1 commit
-
CONFIG_HOTPLUG is going away as an option. As a result, the __dev*
markings need to be removed.This change removes the use of __devinit, __devexit_p, __devinitdata,
__devinitconst, and __devexit from these drivers.Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.Cc: Bill Pemberton
Cc: Samuel Ortiz
Signed-off-by: Greg Kroah-Hartman
08 Dec, 2012
1 commit
-
As the current LEDs code breaks other platform, remove it.
It shall be replaced by a generic "MMIO LEDs" driver.
Reported-by: Stephen Warren
Signed-off-by: Pawel Moll
Tested-by: Stephen Warren
Signed-off-by: Olof Johansson
06 Nov, 2012
1 commit
-
This is a platform driver for Versatile Express' "system
register" block. It's a random collection of registers providing
the following functionality:- low level platform functions like board ID access; in order to
use those, the driver must be initialized early, either statically
or based on the DT- config bus bridge via "system control" interface; as the response
from the controller does not generate interrupt (yet), the status
register is periodically polled using a timer- pseudo GPIO lines providing MMC card status and Flash WP#
signal control- LED interface for a set of 8 LEDs on the motherboard, with
"heartbeat", "mmc0" and "cpu0" to "cpu5" as default triggersSigned-off-by: Pawel Moll