There are two ways to run a pattern in LP5523.
One is using legacy sysfs files such as 'enginex_mode','enginex_load' and
'enginex_leds'. ('x' is from 1 to 3).
Among them, 'enginex_leds' are used for selecting specific LED channel MUX.
(MUX means which LEDs are used for running a pattern from LED 1 to 9.)
The other way is using the firmware interface.
In this mode, the default LED MUX strings are used.
In other words, LED MUX is not configurable on the fly.
This patch enables dynamic LED MUX configuration when the firmware is loaded.
By accessing the sysfs file 'enginex_leds', the LED channels can be configured.
To synchronize the operation mode, each engine mode should be set to 'LOAD'.
The documentation is updated as well.
Cc: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Whenever the engine is loaded by the user-application, the operation mode is
reset first. But it has a problem in case of multiple engine used because
previous engine settings are cleared.
The driver should update not whole 8bits but each engine bit by masking.
On the other hands, whole engines should be reset when the driver is unloaded
and on initializing the LP5523 driver.
So, new functions are used for this handling - lp5521/5523_stop_all_engines().
Cc: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This is the other of the LP3943 MFD driver.
LP3943 can be used as a PWM generator, up to 2 channels.
* Two PWM generators supported
* Supported PWM operations
request, free, config, enable and disable
* Pin assignment
A driver data, 'pin_used' is checked when a PWM is requested.
If the output pin is already assigned, then returns as failure.
If the pin is available, 'pin_used' is set.
When the PWM is not used anymore, then it is cleared.
It is defined as unsigned long type for atomic bit operation APIs,
but only LSB 16bits are used because LP3943 has 16 outputs.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
LP3943 has 16 output pins which can be used as GPIO expander and PWM generator.
* Regmap I2C interface for R/W LP3943 registers
* Atomic operations for output pin assignment
The driver should check whether requested pin is available or not.
If the pin is already used, pin request returns as a failure.
A driver data, 'pin_used' is checked when gpio_request() and
pwm_request() are called. If the pin is available, then pin_used is set.
And it is cleared when gpio_free() and pwm_free().
* Device tree support
Compatible strings for GPIO and PWM driver.
LP3943 platform data is PWM related, so parsing the device tree is
implemented in the PWM driver.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This is one of LP3943 MFD driver.
LP3943 is configurable as a GPIO expander, up to 16 GPIOs.
* Application note: how to configure LP3943 as a GPIO expander
http://www.ti.com/lit/an/snva287a/snva287a.pdf
* Supported GPIO controller operations
request, free, direction_input, direction_output, get and set
* GPIO direction register not supported
LP3943 doesn't have the GPIO direction register. It only provides input and
output status registers.
So, private data for the direction should be handled manually.
This variable is updated whenever the direction is changed and
used in 'get' operation.
* Pin assignment
A driver data, 'pin_used' is checked when a GPIO is requested.
If the GPIO is already assigned, then returns as failure.
If the GPIO is available, 'pin_used' is set.
When the GPIO is not used anymore, then it is cleared.
It is defined as unsigned long type for atomic bit operation APIs,
but only LSB 16bits are used because LP3943 has 16 outputs.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
It can be a problem when a pattern is loaded via the firmware interface.
LP55xx common driver has already locked the mutex in 'lp55xx_firmware_loaded()'.
So it should be deleted.
On the other hand, locks are required in store_engine_load()
on updating program memory.
Reported-by: Pali Rohár <pali.rohar@gmail.com>
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Cc: <stable@vger.kernel.org>
LP8555 is one of the LP855x family devices.
This device needs pre_init_device() and post_init_device() driver
structure. It's same as LP8557, so the device configuration code is
shared with LP8557. Backlight outputs are generated from dual DC-DC boost
converters. It's configurable EPROM settings which are defined in the
platform data.
Driver documentation and device tree bindings are updated.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Now, all legacy application interfaces are restored.
Each driver documentation is updated.
Cc: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch reduces the number of programming commands.
(Count of sending commands)
Old code: 32 + program size (32 counts for clearing program memory)
New code: 32
Pattern buffer is initialized to 0 in this function.
Just update new program data and remaining buffers are filled with 0.
So it's needless to clear whole area.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
git commit db6eaf8388
(leds-lp5523: use generic firmware interface) causes an application conflict.
This interface should be maintained for compatibility.
Restored device attributes are 'engineN_mode', 'engineN_load' and
'engineN_leds'. (N = 1, 2 or 3)
A 'selftest' attribute macro is replaced with LP55xx common macro.
Those are accessed when a LED pattern is run by an application.
Use a mutex in lp5523_update_program_memory()
: This function is called when an user-application writes a 'engineN_load' file
or pattern data is loaded from generic firmware interface.
So, writing program memory should be protected.
If an error occurs on accessing this area, just it returns as -EINVAL quickly.
This error code is exact same as old driver function, lp5523_do_store_load()
because it should be kept for an user-application compatibility.
Even the driver is changed, we can use the application without re-compiling
sources.
Reported-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LED MUX start and stop address should be updated in the program memory
on LP5523 initialization.
LED pattern doesn't work without additional MUX address configuration.
This handling is done by new function, lp5523_init_program_engine().
Eventually, it's called during device initialization, lp5523_post_init_device().
This is a conflict after git commit 632418bf65
(leds-lp5523: clean up lp5523_configure()).
So it should be fixed.
Cc: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp5523_load_engine()
It is called whenever the operation mode is changed to 'load'.
It is used for simple operation mode change.
It will be used when engine mode and LED selection is updated in later patch.
lp5523_load_engine_and_select_page()
Change the operation mode to 'load' and select program page number.
This is used for programming a LED pattern at a time.
So load_engine() is replaced with new API, load_engine_and_select_page()
in lp5523_firmware_loaded().
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch reduces the number of programming commands.
(Count of sending commands)
Old code: 32 + program size (32 counts for clearing program memory)
New code: 32
Pattern buffer is initialized to 0 in this function.
Just update new program data and remaining buffers are filled with 0.
So it's needless to clear whole area.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
git commit 9ce7cb170f
may cause an application confict, engineN_mode and engineN_load.
This interface should be maintained for compatibility.
Restored device attributes are 'engineN_mode' and 'engineN_load'.
A 'selftest' attribute macro is replaced with LP55xx common macro.
Use a mutex in lp5521_update_program_memory()
: This function is called when an user-application writes a 'engineN_load' file
or pattern data is loaded from generic firmware interface.
So, writing program memory should be protected.
If an error occurs on accessing this area, just it returns as -EINVAL quickly.
This error code is exact same as old driver function, lp5521_do_store_load()
because it should be kept for an user-application compatibility.
Even the driver is changed, we can use the application without re-compiling
sources.
'led_pattern' attribute is not included
: engineN_mode and _load were created for custom user-application.
'led_pattern' is an exception. I added this attribute not for custom application
but for simple test. Now it is used only in LP5562 driver, not LP5521.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch provides common macros for LP5521 and LP5523 device attributes and
functions.
(Device attributes)
LP5521: 'mode', 'load' and 'selftest'
LP5523: 'mode', 'load', 'leds' and 'selftest'
(Permissions)
mode: R/W
load: Write-only
leds: R/W
selftest: Read-only
Couple of lines are duplicate, so use these macros for adding device attributes
in LP5521 and LP5523 drivers.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP55xx family devices have internal three program engines which are used for
loading LED patterns. To maintain legacy device attributes, specific data
structure is used, 'mode' and 'led_mux'. The mode is used for showing/storing
current engine mode such like disabled, load and run. Then led_mux is used for
showing/storing current output LED selection.
This is only for LP5523/55231.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP8501 can drive up to 9 channels like LP5523.
LEDs can be controlled directly via the I2C and programmable engines are
supported.
LP55xx common driver
LP8501 is one of LP55xx family device, so LP55xx common code are used.
Chip specific data is defined in the structure, 'lp55xx_device_config'.
Differences between LP8501 and LP5523
Different register layout for LED output control and others.
LP8501 specific feature for separate output power selection.
LP8501 doesn't support external clock detection.
Different programming engine data.
LP8501 specific feature - output power selection
Output channels are selected by power selection - Vout or Vdd.
Separate power for VDD1-6 and VDD7-9 are available.
It is configurable in the platform data.
To support this feature, LP55xx DT structure and header are changed.
Device tree binding is updated as well.
LED pattern data
Example pattern data is updated in the driver documentation.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Fix a warning below.
drivers/regulator/lp872x.c:910:33: warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
And checkpatch warnings are fixed.
WARNING: space prohibited before semicolon
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
In watchdog_ping(), 'start' is called automatically when 'ping' function call
is not configured.
Softdog driver has same handling in both cases - start and ping, so 'ping' OPS
can be removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
The LP55xx DT structure is applicable to the LP5562 device.
The driver and documentation are updated.
Compatible property of the DT
: LP5521 and LP5223 were manufactured by National Semiconductor.
LP5562 is a new device from Texas Instruments.
Cc: Gabriel Fernandez <gabriel.fernandez@stericsson.com>
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Currently, the LP55xx DT structure supports max 3 channels.
However, LP5523 has max 9 channels and LP5562 has 4 channels.
To enhance this constraint, the DT structure has been changed.
(a) Use the child node for various channel settings instead of fixed array
(b) Remove 'num_channel' property.
This value can be retrieved by counting the children node.
(c) 'chan-name' property supported
(d) Documentation updates for LP5521 and LP5523
(cooloney@gmail.com: fix a coding style issue in leds-lp55xx.txt)
Cc: Gabriel Fernandez <gabriel.fernandez@stericsson.com>
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The interrupt and charging parameters are configurable in the device tree
structure. In the board test, a GPIO is used for handling LP8727
interrupts. The device tree binding documentation is added also.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
This patch enables the DT structure of the LP8720 and LP8725 device.
The LP872x platform data is generated when the device tree is configured.
Even if the platform data is NULL, it is no issue at all because the driver is
configured with the default mode.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Enable supporting the DT structure of LP855x family devices. If the
platform data is NULL, the driver tries to parse a DT structure. Then,
the platform data is copied from the DT. Documentation is added as well.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The 'load_new_rom_data' was used for checking whether new ROM data should
be updated or not.
However, we can decide it with 'size_program' data. If the size is
greater than 0, it means updating ROM area is required. Otherwise, the
default ROM data will be used. Therefore, this duplicate platform data
can be removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The brightness of LP855x devices is controlled by I2C register or PWM
input . This mode was selected through the platform data, but it can be
chosen by the driver internally without platform data configuration.
How to decide the control mode:
If the PWM period has specific value, the mode is PWM input.
On the other hand, the mode is register-based.
This mode selection is done on the _probe().
Move 'mode' from a header file to the driver private data structure,
'lp855 x'. And correlated code was replaced.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Now LP55xx provides automatic clock detection API, lp55xx_is_extclk_used().
The clock configuration can be done by the driver itself.
(a) Concept
The default value is set by each driver with clock selection.
The internal clock selection bit is updated in case that the external clock
is not detected or clock rate is not 32KHz.
(b) Change on LP55xx platform data
The clock configuration is done automatically, so no need to define
'update_config' in the platform side.
Correlated information are removed in the documentations and header.
(c) Definitions moved from header to driver files
CONFIG register values are moved each driver, LP5521 and LP5562.
Not necessary definitions are removed also.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Program execution is timed with 32768Hz clock in the LP55xx family devices.
To run LED functionalities, LP55xx devices provide two options.
One is using internal clock. The other is using external clock.
This patch enables external clock detection automatically.
If external clock is not detected, then the internal clock will be used in the
LP55xx driver.
Valid clock rate is 32768Hz in LP55xx devices.
This new API is used in each LP55xx driver like LP5521 and LP5562.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
According to a sysfs documentation(Documentation/filesystem/sysfs.txt),
scnprintf() should be used in a read operation method.
It guarantees safe buffer size(PAGE_SIZE) which is allocated by the sysfs.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LM355x and LM3642 support flash and torch functionality.
(Camera driver) (LED trigger for camera) (LED driver)
Turn on the flash ...> ledtrig_flash_ctrl(true) ...> LM355x or LM3642
brightness ctrl
<actual driving here>
Flash/torch LEDs are controlled by other driver using LED camera trigger
APIs, ledtrig_flash_ctrl()/ledtrig_torch_ctrl().
Then, actual device control is activated by each LED driver such like
LM355x or LM3642.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Some LED devices support flash/torch functionality through the LED subsystem.
This patch enables direct LED trigger controls by the driver.
Flash on/off and torch on/off can be done simply by other driver space.
Two trigger APIs are added, ledtrig_flash_ctrl() and ledtrig_torch_ctrl().
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Macros are used in case that an inline function doesn't work.
Otherwise, use an empty inline function.
(a) Case of !CONFIG_LEDS_TRIGGERS
Following macros are replaced with inline functions.
led_trigger_register_simple()
led_trigger_unregister_simple()
led_trigger_event()
To make inline types, the structure, 'led_trigger' should be defined.
This structure has no member at all.
(b) Case of !CONFIG_LEDS_TRIGGER_IDE_DISK
ledtrig_ide_activity() macro is replaced with an inline function as well.
(c) DEFINE_LED_TRIGGER() and DEFINE_LED_TRIGGER_GLOBAL()
Struct 'led_trigger' is defined both cases, with CONFIG_LEDS_TRIGGERS and
without CONFIG_LEDS_TRIGGERS.
Those macros are moved out of CONFIG_LED_TRIGGERS because of no-dependency
on CONFIG_LEDS_TRIGGERS.
(d) Fix build errors in mmc-core driver
After replacing macros with inline functions, following build errors occur.
(condition: CONFIG_LEDS_TRIGGERS is not set)
drivers/mmc/core/core.c: In function 'mmc_request_done':
drivers/mmc/core/core.c:164:25: error: 'struct mmc_host' has no member named 'led'
drivers/mmc/core/core.c: In function 'mmc_start_request':
drivers/mmc/core/core.c:254:24: error: 'struct mmc_host' has no member named 'led'
make[3]: *** [drivers/mmc/core/core.o] Error 1
The reason of these errors is non-existent member variable, 'led'.
It is only valid when CONFIG_LEDS_TRIGGERS is set.
But now, it can be used without this dependency.
To fix build errors, member 'led' is always used without its config option in
'include/linux/mmc/host.h'.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
For better driver management, new subdirectory, 'trigger' is created.
All LED trigger drivers are moved into this directory.
Internal header, 'leds.h' is included in each LED trigger drivers.
Fix the location of header file, "leds.h" -> "../leds.h" in driver files.
One exception is here, 'ledtrig-timer.c'.
There is no need to include 'leds.h'. so '#include "leds.h"' line was removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP5562 can drive up to 4 channels, RGB and White.
LEDs can be controlled directly via the led class control interface.
LP55xx common driver
LP5562 is one of LP55xx family device, so LP55xx common code are used.
On the other hand, chip specific configuration is defined in the structure
'lp55xx_device_config'
LED pattern data
LP5562 has also internal program memory which is used for running various LED
patterns. LP5562 driver supports the firmware interface and the predefined
pattern data as well.
LP5562 device attributes: 'led_pattern' and 'engine_mux'
A 'led_pattern' is an index code which runs the predefined pattern data.
And 'engine_mux' is updated with the firmware interface is activated.
Detailed description has been updated in the documentation files,
'leds-lp55xx.txt' and 'leds-lp5562.txt'.
Changes on the header file
LP5562 configurable definitions are added.
Pattern RGB data is fixed as constant value.
(No side effect on other devices, LP5521 or LP5523.)
(cooloney@gmail.com: remove redundant mutex_unlock(). Reported by Dan
Carpenter <dan.carpenter@oracle.com>)
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The sysfs allocates PAGE_SIZE. It is used by each R/W operation method.
Use it instead of another buffer size.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
Regulator core driver provides enable GPIO control for enabling/disabling a
regulator. Now, enable GPIO is shared among regulators.
Use this internal working, so unnecessary code are removed.
GPIO enable pin configurations are added in digital LDO and analog LDO drivers.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Reviewed-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The regulator_dev has regulator_enable_gpio structure.
'ena_gpio' and 'ena_gpio_invert' were moved to in regulator_enable_gpio.
regulator_dev ---> regulator_enable_gpio
.ena_gpio .gpio
.ena_gpio_invert .ena_gpio_invert
Pointer, 'ena_pin' is used for checking valid enable GPIO pin.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Reviewed-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
To support shared enable GPIO pin, replace GPIO code with new static functions
Reference count: 'enable_count'
Balance the reference count of each GPIO and actual pin control.
The count is incremented with enabling GPIO.
On the other hand, it is decremented on disabling GPIO.
Actual GPIO pin is enabled at the initial use.(enable_count = 0)
The pin is disabled if it is not used(shared) any more. (enable_count <=1)
Regardless of the enable count, update GPIO state of the regulator.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Reviewed-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
A Regulator can be enabled by external GPIO pin.
This is configurable in the regulator_config.
At this moment, the GPIO can be owned by only one regulator device.
In some devices, multiple regulators are enabled by shared one GPIO pin.
This patch extends this limitation, enabling shared enable GPIO of regulators.
New list for enable GPIO: 'regulator_ena_gpio_list'
This manages enable GPIO list.
New structure for supporting shared enable GPIO: 'regulator_enable_gpio'
The enable count is used for balancing GPIO control count.
This count is incremented when GPIO is enabled.
On the other hand, it's decremented when GPIO is disabled.
Reference count: 'request_count'
The reference count, 'request_count' is incremented/decremented on
requesting/freeing the GPIO. This count makes sure only free the GPIO
when it has no users.
How it works
If the GPIO is already used, skip requesting new GPIO usage.
The GPIO is new one, request GPIO function and add it to the list of
enable GPIO.
This list is used for balancing enable GPIO count and pin control.
Updating a GPIO and invert code moved
'ena_gpio' and 'ena_gpio_invert' of the regulator_config were moved to
new function, regulator_ena_gpio_request().
Use regulator_enable_pin structure rather than regulator_dev.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Reviewed-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
TI LP8788 PMU supports regulators, battery charger, RTC, ADC, backlight
dri= ver and current sinks. This patch enables LP8788 backlight module.
(Brightness mode)
The brightness is controlled by PWM input or I2C register.
All modes are supported in the driver.
(Platform data)
Configurable data can be defined in the platform side.
name : backlight driver name. (default: "lcd-backlight")
initial_brightness : initial value of backlight brightness
bl_mode : brightness control by PWM or lp8788 register
dim_mode : dimming mode selection
full_scale : full scale current setting
rise_time : brightness ramp up step time
fall_time : brightness ramp down step time
pwm_pol : PWM polarity setting when bl_mode is PWM based
period_ns : platform specific PWM period value. unit is nano.
The default values are set in case no platform data is defined.
[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Thierry Reding <thierry.reding@avionic-design.de>
Cc: "devendra.aaru" <devendra.aaru@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Getting the brightness value is not critical, no need to read the actual
register value. To simplify it, just return the 'bl->props.brightness'
value. Then, lp855x_read_byte() can be removed, not used any more.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
LP8557 is one of LP855x family device, but it has different register map
and initialization process. To support this device, device specific
configuration is done through the lp855x_device_config structure.
Few register definitions are fixed for better readability.
BRIGHTNESS_CTRL -> LP855X_BRIGHTNESS_CTRL
DEVICE_CTRL -> LP855X_DEVICE_CTRL
EEPROM_START -> LP855X_EEPROM_START
EEPROM_END -> LP855X_EEPROM_END
EPROM_START -> LP8556_EPROM_START
EPROM_END -> LP8556_EPROM_END
And LP8557 register definitions are added. New register function,
lp855x_update_bit() is added.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
At this moment, LP855x device driver has fixed register configuration.
For example, fixed register addresses and values are set on the device
initialization. But new device of LP855x family, LP8557 has different
register map and initialization sequence. To support new device
architecture, initialization process should be changed.
Introduce new structure: lp855x_device_config
=============================================
With lp855x_device_config, device specific features are configurable.
Use configurable function calls and register addresses rather than fixed values.
Change on device initialization
===============================
In old LP855x driver architecture, the device initialization was simple.
- Just update the brightness/device control register/ROM area(optional).
In new LP855x driver architecture, two more works are added - pre_init and
post_init.
Those init functions are optional, used for new device LP8557.
New device initialization flow: generic sequence
=================================================
1) pre_init_device()
2) update the brightness register
3) update the device control register
4) update ROM area if need
5) post_init_device()
Name change
===========
Use generic name 'lp855x_configure()' instead of 'lp855x_init_registers()'.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Update changed platform data information.
Add leds-lp55xx.txt which includes the firmware interface description.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP55XX common device attributes, 'led_current' and 'max_current' are created
while loading the driver.
Those are LED device attributes which are removed automatically on releasing
led class devices - led_classdev_unregister().
Therefore, this duplicate code should be removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Now LP5521 and LP5523 drivers are based on new lp55xx structure.
So the author and copyrights are updated.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The LP55xx common driver provides a new header, leds-lp55xx.h.
This driver enables removing duplicate code for both drivers and
making coherent driver structure.
LP5521 and LP5523/55231 platform data were merged into one common file.
Therefore, the LP5521/5523 platform code need to be fixed.
This patch has been already acked.
For ux500: https://lkml.org/lkml/2012/10/11/417
Acked-by: Linus Walleij <linus.walleij@linaro.org>
For omap: https://lkml.org/lkml/2012/10/11/334
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Remove unused definitions and change hex values to capital letters
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Old data structures and I2C function are not used any more.
Each driver uses the lp55xx common data and functions.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Replace lp5521/5523_unregister_sysfs() with lp55xx_unregister_sysfs().
On unloading the driver, running engines should be stopped.
Use explicit driver function, lp5521/5523_stop_engine().
Unused functions are removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp55xx_unregister_sysfs() is used for removing lp55xx device attributes.
Chip specific and engine attributes are removed on unloading the driver.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP5521 and LP5523 have a selftest function which is run via the sysfs.
Use lp55xx driver data and R/W functions rather than lp5521/5523 private data
and functions.
Additionally, if-statements are changed for code simplicity.
Unused functions, lp5521/5523_read() are removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp5521/5523_register_sysfs() are replaced with lp55xx common driver function,
lp55xx_register_sysfs().
Chip specific device attributes are configurable using 'dev_attr_group'.
Error condition name is changed:
use specific error condition, 'err_register_sysfs' rather than unclear name,
'fail2'.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
To support device specific attributes, new common driver function is added.
Eventually those are created on registering the sysfs with common dev attrs.
Furthermore, this patch makes adding device attributes simple in each driver.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP55xx common driver provides generic firmware interface
for running a LED pattern.
LP5521 and LP5523 have many device attributes for running patterns.
This patch cleans up those complex code.
Removed device attributes:
engine1_mode
engine2_mode
engine3_mode
engine1_load
engine2_load
engine3_load
engine1_leds
engine2_leds
engine3_leds
All device attributes and functions are replaced with two callback functions,
'firmware_cb' and 'run_engine'.
New engine functions:
lp5523_load/stop/run_engine(), lp5523_update_program_memory() and
lp5523_wait_opmode_done()
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP55xx common driver provides generic firmware interface
for running a LED pattern.
LP5521 and LP5523 have many device attributes for running patterns.
This patch cleans up those complex code.
Removed device attributes:
engine1_mode
engine2_mode
engine3_mode
engine1_load
engine2_load
engine3_load
led_pattern
All device attributes and functions are replaced with two callback functions,
'firmware_cb' and 'run_engine'.
New engine functions:
lp5521_load/stop/run_engine(), lp5521_update_program_memory() and
lp5521_wait_opmode_done()
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch provides additional device attributes which enable
loading the firmware. ('select_engine' and 'run_engine')
To run a LED pattern, two parts of driver should be enabled.
Common features : lp55xx-common
===============================
Firmware interface for loading LED patterns
Chip specific features : leds-lp5521, leds-lp5523
=================================================
Register addresses for loading firmware data
Register addresses for running selected engine
Pattern programming sequence
============================
LP55xx chips have three program engines.
To load and run a LED pattern, the programming sequence is as follows.
(1) Select an engine number (1/2/3)
(2) Set engine mode to load
(3) Write pattern data into selected area
(4) Set engine mode to run
This sequence is almost same as the firmware interface.
(1) Select an engine number : 'select_engine' dev attribute
(2) Mode change to load : 'loading' of firmware class
(3) Write pattern data into selected area : 'data' of firmware class
(4) Mode change to run : 'run_engine' dev attribute
(1) and (4) are device specific features which provide callback functions
(2) and (3) are common features.
For example,
echo 1 or 2 or 3 > /sys/bus/i2c/devices/xxxx/select_engine
echo 1 > /sys/class/firmware/lp5521/loading
echo "4000600040FF6000" > /sys/class/firmware/lp5521/data
echo 0 > /sys/class/firmware/lp5521/loading
echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
As soon as 'loading' is set to 0, registered callback is called.
Inside the callback, the selected engine is loaded and memory is updated.
To run programmed pattern, 'run_engine' attribute should be enabled.
Device specific data structure
==============================
o Firmware callback
load selected engine and update program memory
o Run engine
change the engine mode
o 'engine_idx' and firmware data, 'fw'
Those are used in the driver internally with callback functions
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP55xx family chips have internal program memory which run various patterns.
Using this memory, LEDs continue on blinking/dimming without continuous I2C
commands. That means the I2C HOST can be entered into sleep once the memory
is updated.
An application can get hex data from a file and write them into
the program memory through the I2C. This is general firwmare interface.
This patch is the initial step for adding the firmware interface.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Use lp55xx_unregister_leds() rather than duplicate code.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
To unregister led class devices and sysfs attributes,
LP5521 and LP5523 have each driver function.
This patch makes both drivers simple using common driver function,
lp55xx_unregister_leds().
And some unused variables are removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LED current is configurable via the sysfs.
Max current is a read-only attribute.
These attributes code can be shared in lp55xx common driver.
Device attributes: 'led_current' and 'max_current'
move to lp55xx common driver
Replaced functions:
show_max_current() => lp55xx_show_max_current()
show_current() => lp55xx_show_current()
store_current() => lp55xx_store_current()
LED setting function: set_led_current()
Current registers are device specific, so configurable function is added
in each driver.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp5521_set_brightness() and lp5523_set_brightness() are replaced with
common function, lp55xx_set_brightness().
This function is invoked when the brightness of each LED channel is updated.
LP5521 and LP5523 have different register address for the brightness control,
so this work is done by chip specific brightness_work_fn().
lp5521/5523_led_brightness_work():
use lp55xx_led and lp55xx_chip data structure.
use lp55xx write function.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp5521_init_led() and lp5523_init_led() are replaced with one common function,
lp55xx_init_led().
Max channels is configurable, so it's used in lp55xx_init_led().
'LP5523_LEDS' are changed to 'LP5523_MAX_LEDS'.
lp55xx_set_brightness, lp55xx_led_attributes: skeleton
Will be filled in next patches.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LED class devices are registered in lp5521_register_leds() and
lp5523_register_leds().
Two separate functions are merged into consolidated lp55xx function,
lp55xx_register_leds().
Error handling fix:
Unregistering LEDS are handled in lp55xx_register_leds() when LED registration
failure occurs. So each driver error handler is changed to 'err_register_leds'
Chip dependency: 'brightness_work_fn' and 'set_led_current'
To make the structure abstract, both functions are configured in each driver.
Those functions should be done by each driver because register control is
chip-dependant work.
lp55xx_init_led: skeleton
Will be filled in next patch
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Two separate de-init functions are merged into one common function.
And it is used in err_post_init of lp55xx_init_device().
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp5521/5523_init_device() are replaced with lp55xx common function,
lp55xx_init_device().
Error handler in init_device:
deinit function are matched with 'err_post_init' section in
lp55xx_init_device().
Remove LP5523 engine intialization code:
Engine functionality is not mandatory but optional.
Moreover engine initialization is done internally with device reset command.
Therefore, this code is unnecessary.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP5521/5523 chip configuration is replaced with lp55xx common function,
lp55xx_post_init_device().
Name change:
lp5521/5523_configure() to lp5521/5523_post_init_device()
These are called in init function.
Register access function
Argument type is changed from 'i2c_client' to 'lp55xx_chip'.
Use exported R/W functions of lp55xx common driver.
Temporary variables in lp5521/5523_init_device()
These functions will be removed but temporary variables are needed for
blocking build warnings - incompatible pointer.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP5521/5523 chip detection functions are replaced with lp55xx common function,
lp55xx_detect_device().
Chip dependent address and values are configurable in each driver.
In init function, chip detection is executed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP5521/5523 reset device functions are moved to lp55xx common driver.
Value of register address and value are chip dependent.
Those are configured in each driver.
In init function, reset command is executed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP5521/5523 platform data functions are moved to lp55xx common driver.
New init function, lp55xx_init_device() is created.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch is a preceding step for making common lp55xx init function.
Return code:
Do not use 'OR' arithmetic for the result.
If some error occurs, just return it.
Remove engine verification code:
To check whether internal engine works or not, many lines of code are executed.
However, this job is unnecessary during the chip initialization because
the engine usage is not mandatory but optional function.
LED engines are enabled when specific LED pattern is loaded.
Therefore, this verification code is removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch is a preceding step for making common lp55xx init function.
LP5521_REG_R_CURRENT register code moved:
Chip specific code moved from lp5521_init_device() to lp5521_configure().
Remove engine init function:
LP5521 has internal program engines which are used for running LED patterns.
(blinking, ramp up/down and other emotional visual effects)
Engine initialization is done by reset command in lp5521_init_device().
Remove this duplicate code.
Return code:
Do not use 'OR' arithmetic for the result.
If some error occus, just return it.
Enable latency:
Use explicit named function, lp5521_wait_enable_done().
According to the datasheet, 500us is guaranteed time.
Thus wait time is changed from 1000us to 500us.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP5521 and LP5523 data structures have common features.
Use common lp55xx data structures rather than chip specific data.
Legacy code in probe is replaced with this new data structures.
lp55xx_chip : Common data between lp5521_chip and lp5523_chip
lp55xx_led : Common LED structure between lp5521_led and lp5523_led
lp55xx_platform_data : Common platform data between lp5521_platform_data and
lp5523_platform_data
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Change the name of chip data structure and platform data.
This patch is a preceding step for cleaning up lp5521/5523 probe and remove.
These data will be replaced with new lp55xx common data structures
in next patch.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch supports basic common driver code for LP5521, LP5523/55231 devices.
( Driver Structure Data )
lp55xx_led and lp55xx_chip
In lp55xx common driver, two different data structure is used.
o lp55xx_led
control multi output LED channels such as led current, channel index.
o lp55xx_chip
general chip control such like the I2C and platform data.
For example, LP5521 has maximum 3 LED channels.
LP5523/55231 has 9 output channels.
lp55xx_chip for LP5521 ... lp55xx_led #1
lp55xx_led #2
lp55xx_led #3
lp55xx_chip for LP5523 ... lp55xx_led #1
lp55xx_led #2
.
.
lp55xx_led #9
( Platform Data )
LP5521 and LP5523/55231 have own specific platform data.
However, this data can be handled with just one platform data structure.
The lp55xx platform data is declared in the header.
This structure is derived from leds-lp5521.h and leds-lp5523.h
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Chip specific function is configured when the device is initialized.
So _configure() is moved to each device init function.
If chip configuration gets failed, the device is de-initialized in
each _init_device(), not probe().
For compile error fix, function type declarations are added.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Use explicit each driver function rather than raw command.
These function will be merged into the lp55xx common driver.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
To make LED unregistration code simple, new function, _unregister_leds()
is added in each driver.
This patch is a preceding step for lp55xx common driver architecture.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
To make LED initialization code simple, new function, _register_leds()
is added at each driver.
This patch is a preceding step for lp55xx common driver architecture.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Device de-initialization code is moved to _deinit_device() at each driver.
This patch is a preceding step for lp55xx common driver architecture.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
To make _probe() simple, device initialization code is moved to
_init_device() at each driver.
This patch is a preceding step for lp55xx common driver architecture.
leds-lp5521:
When 'lp5521_init_device()' gets failed, error handling should be 'fail1'
rather than 'fail2'.
fail1: releasing platform resource and return code
fail2: releasing allocated LED devices with handling 'fail1'
The 'lp5521_init_device()' is called before creating LED devices.
Thus, 'goto fail1' is proper error handler of this function.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The lp8788-keyled is a platform driver of lp8788-mfd. The platform
device is allocated when mfd_add_devices() is called in lp8788-mfd.
On the other hand, 'lp->dev' is the i2c client device.
Therefore, this 'platform_device' is a proper parent device in case
of resource managed mem alloc, registering led device and device
kernel messages.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch supports the TPS65910 PMU function on the AM3517 Craneboard.
The IRQ pin, SYS_NIRQ is dedicated connection between the AM3517 and
the TPS65910 PMU.
To handle the PMU IRQs, mux configuration is required.
Platform data configuration:
.IRQ number : SYS_NIRQ (M_IRQ_7)
.External clock source : external 32KHz clock is connected
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This patch enables the NAND device on the AM3517 Craneboard.
MTD partitions are created as below.
0x000000000000-0x000000080000 : "X-Loader"
0x000000080000-0x000000240000 : "U-Boot"
0x000000240000-0x000000280000 : "U-Boot Env"
0x000000280000-0x000000780000 : "Kernel"
0x000000780000-0x000010000000 : "File System"
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Use 'platform_device' in kernel messages rather than i2c client device
node. lp8788_update_charger_params() needs additional argument, 'pdev'.
Then, remove unnecessary lp8788 private data in lp8788_irq_register().
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
The lp8788-charger is a platform driver of lp8788-mfd. The platform device
is allocated when mfd_add_devices() is called in lp8788-mfd. On the other
hand, 'lp->dev' is the i2c client device.
Therefore, this 'platform_device' is a proper parent device in case of
resource managed mem alloc and device kernel message.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
Use 'dev' of iio device in a kernel message rather than i2c client device node.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The lp8788-adc is a platform driver of lp8788-mfd.
The platform device is allocated when mfd_add_devices() is called
in lp8788-mfd.
On the other hand, 'lp->dev' is the i2c client device.
Therefore, this 'platform_device' is a proper parent device of
iio device and device kernel message.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Use 'platform_device' rather than i2c client device node.
Argument is added in lp8788_config_ldo_enable_mode().
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The lp8788-ldo is a platform driver of lp8788-mfd.
The platform device is allocated when mfd_add_devices() is called
in lp8788-mfd.
On the other hand, 'lp->dev' is the i2c client device.
Therefore, this 'platform_device' is a proper parent device in case of
resource managed mem alloc, registering regulators and device kernel messages.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Milo Kim