Enable the GCC clock driver in the MSM8996 device tree and
update the uartblsp2dm1 serial node to use the correct clocks.
Signed-off-by: Devesh Jhunjhunwala <deveshj@codeaurora.org>
Drivers that are registered at an initcall level may have to
wait until late_init before the probe deferral mechanism can
retry their probe functions. It is possible that their
dependencies were resolved much earlier, in some cases even
before the next initcall level. Invoke one probe retry cycle
at every _sync initcall level, allowing these drivers to be
probed earlier.
A real world example of how this change helps follows. On the
MSM8974, there are 3 devices that need to be probed in order
for the display driver to be able to probe and bring up a
display panel. These are the gdsc_mdss (a regulator device), the
mmsscc-dsi device (a display clock controller), and the
dsipllcc device (a PLL controller). Here is a kernel log that
shows these devices probing in the wrong order:
[0.503253] mmsscc-dsi fd8c0000.qcom,mmsscc-dsi: Failed to get pixel source. -- [1]
[0.505210] dsipllcc fd8c0000.qcom,dsipllcc: Failed to get MDSS GDSC -- [2]
[0.523264] gdsc_mdss: no parameters -- [3]
Only gdsc_mdss successfully probed at 0.52 seconds. Now without
_this_ change, the current probe deferral mechanism results in
the devices probing at or after late_init:
[9.196006] dsipllcc fd8c0000.qcom,dsipllcc: Registered DSI PLL clocks. -- [2]
[9.357440] mmsscc-dsi fd8c0000.qcom,mmsscc-dsi: Registered MMSSCC DSI clocks. -- [1]
Thus the display can only be brought up after 9.35 seconds. However,
by allowing a probe retry after each initcall level, this number
reduces drastically:
[0.608252] dsipllcc fd8c0000.qcom,dsipllcc: Registered DSI PLL clocks. -- [2]
[0.613758] mmsscc-dsi fd8c0000.qcom,mmsscc-dsi: Registered MMSSCC DSI clocks.-- [1]
Thus the display can be brought up just after 0.61 seconds.
Change-Id: I83d8ac89e591e89e27934c0402449437b61b2124
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
This is a snapshot of kryo l2 accessors driver as of
msm-3.18 commit:
e70ad0cd5efdd9dc91a77dcdac31d6132e1315c1 (Promotion of
kernel.lnx.3.18-151201.)
Signed-off-by: Devesh Jhunjhunwala <deveshj@codeaurora.org>
Add clock tree support for MSM8996 and MSMCOBALT, and add corresponding dt
bindings header files.
Change-Id: If0281f96ce5dd29b04f190efa1527888bc240bb5
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Support added for MSM clock and modifications in the clk framework to use
the MSM clock framework.
Change-Id: Ibbcf0ffbf9d30dde2dcb0e943225ad95dd4e857d
Signed-off-by: Taniya Das <tdas@codeaurora.org>
The clock_set_rate_complete even is used to monitor the latency
of the clk_set_rate API, and the clock_state event is used to
add support in debugfs to take a snapshot of all the clocks
present and their current state to ftrace.
This is a squash of the following commits:
1. clk: qcom: Add support to record clock state using ftrace
2. tracing: power: Define clock_set_rate_complete trace event
Signed-off-by: Taniya Das <tdas@codeaurora.org>
PM_QOS_SUM is a new enum type supported in the upstream kernel. The target
qos value for PM_QOS_SUM type is updated as the sum of all the priorities
that are applicable to the current CPU.
Change-Id: I89152db4fbbf08db113b52e6c5fee4aba9b70933
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
Send the list of cpus whose qos has been affected along with the changed
value. Driver listening in for notifier can use this to apply the qos value
for the respective cpus.
Change-Id: I8f3c2ea624784c806c55de41cc7c7fcf8ebf02da
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
[mattw@codeaurora.org: resolve trivial context conflicts]
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Conflicts:
kernel/power/qos.c
QoS request for CPU_DMA_LATENCY can be better optimized if the request
can be set only for the required cpus and not all cpus. This helps save
power on other cores, while still gauranteeing the quality of service.
Enhance the QoS constraints data structures to support target value for
each core. Requests specify if the QoS is applicable to all cores
(default) or to a selective subset of the cores or to a core(s), that the
IRQ is affine to.
QoS requests that need to track an IRQ can be set to apply only on the
cpus to which the IRQ's smp_affinity attribute is set to. The QoS
framework will automatically track IRQ migration between the cores. The
QoS is updated to be applied only to the core(s) that the IRQ has been
migrated to.
Idle and interested drivers can request a PM QoS value for a constraint
across all cpus, or a specific cpu or a set of cpus. Separate APIs have
been added to request for individual cpu or a cpumask. The default
behaviour of PM QoS is maintained i.e, requests that do not specify a
type of the request will continue to be effected on all cores. Requests
that want to specify an affinity of cpu(s) or an irq, can modify the PM
QoS request data structures by specifying the type of the request and
either the mask of the cpus or the IRQ number depending on the type.
Updating the request does not reset the type of the request.
The userspace sysfs interface does not support CPU/IRQ affinity.
Change-Id: I09ae85a1e8585d44440e86d63504ad734e8e3e36
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
Conflicts:
kernel/power/qos.c
QoS add requests uses a handle to the priority list that is used
internally to save the request, but this does not extend well. Also,
dev_pm_qos structure definition seems to use a list object directly.
The 'derivative' relationship seems to be broken.
Use pm_qos_request objects instead of passing around the protected
priority list object.
Change-Id: Ie4c9c22dd4ea13265fe01f080ba68cf77d9d484d
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
[mattw@codeaurora.org: resolve context conflicts and extend
struct modifications to additional affected users]
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Conflicts:
include/linux/pm_qos.h
This change enables some regulator and qpnp drivers.
Change-Id: Ic66cb1e9ed2d73a4f3f15b5bae0895c3c0aae808
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Being able to write to spmi registers via userspace is required
for quick debug and development. Enable it.
The regmap framework uses dev_name to create debugfs dir names.
So update the spmi devices to have proper names.
Change-Id: I8a5da203b212df9a7f1410e3fcf6ee7b429856b6
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
struct pmic_arb_irq_spec serves no real purpose. It is used only
in the translate function and the code is much cleaner without it.
Change-Id: I4daae954b8e01b33a9c7f5a343a31c15b4787382
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
PMIC interrupts each have an internal latched status bit which is
not visible from any register. This status bit is set as soon as
the conditions specified in the interrupt type and polarity
registers are met even if the interrupt is not enabled. When it
is set, nothing else changes within the PMIC and no interrupt
notification packets are sent. If the internal latched status
bit is set when an interrupt is enabled, then the value is
immediately propagated into the interrupt latched status register
and an interrupt notification packet is sent out from the PMIC
over SPMI.
This PMIC hardware behavior can lead to a situation where the
handler for a level triggered interrupt is called immediately
after enable_irq() is called even though the interrupt physically
triggered while it was disabled within the genirq framework.
This situation takes place if the the interrupt fires twice after
calling disable_irq(). The first time it fires, the level flow
handler will mask and disregard it. Unfortunately, the second
time it fires, the internal latched status bit is set within the
PMIC and no further notification is received. When enable_irq()
is called later, the interrupt is unmasked (enabled in the PMIC)
which results in the PMIC immediately sending an interrupt
notification packet out over SPMI. This breaks the semantics
of level triggered interrupts within the genirq framework since
they should be completely ignored while disabled.
The PMIC internal latched status behavior also affects how
interrupts are treated during suspend. While entering suspend,
all interrupts not specified as wakeup mode are masked. Upon
resume, these interrupts are unmasked. Thus if any of the
non-wakeup PMIC interrupts fired while the system was suspended,
then the PMIC will send interrupt notification packets out via
SPMI as soon as they are unmasked during resume. This behavior
violates genirq semantics as well since non-wakeup interrupts
should be completely ignored during suspend.
Modify the qpnpint_irq_unmask() function so that the interrupt
latched status clear register is written immediately before the
interrupt enable register. This clears the internal latched
status bit of the interrupt so that it cannot trigger spuriously
immediately upon being enabled.
Also, while resuming an irq, an unmask could be called even if it
was not previously masked. So, before writing these registers,
check if the interrupt is already enabled within the PMIC. If it
is, then no further register writes are required. This
condition check ensures that a valid latched status register bit
is not cleared until it is properly handled.
Change-Id: Ie05845b692a151c39943aa3e2aad6bcae4194d83
Signed-off-by: David Collins <collinsd@codeaurora.org>
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
irq_enable which is called when the device resumes. Note that the
irq_enable is called regardless of whether the interrupt was
marked enabled/disabled in the descriptor or whether it was
masked/unmaked at the controller while resuming.
The current driver unconditionally clears the interrupt in its
irq_enable callback. This is dangerous as any interrupts that
happen right before the resume could be missed.
Remove the irq_enable callback and use mask/unmask instead.
Change-Id: I58695ae0c4905a699003d35498dc36c2a947f3f0
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
We see a unmapped irqs trigger right around bootup. This could
likely be because the bootloader exited leaving the interrupts
in an unknown or unhandled state. Ack and mask the interrupt
if one is found. A request_irq later will unmask it and also
setup proper mapping structures.
Change-Id: Icc2fc4f1bd9b3333e5856fce2daa5ba2b69e9a87
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The current driver disables/enables the ACC bit when any interrupt
in that peripheral is being masked or unmasked.
However, the ACC bits were meant to be disabled and enabled when
all interrupts in that peripheral are disabled and any interrupts in
it are enabled respt.
The driver ends up masking the peripheral (i.e. all the interrupts
in that peripheral) if any one interrupt in that peripheral is masked.
There could be other interrupts enabled which will not trigger after this.
Fix this by changing the driver to disable or enable when all the
interrupts in the peripheral are disabled or when the first enable of an
interrupt in that peripheral happens.
Note that we will need to keep track of the enabled interrupts for an
apid. There are other things like ppid and owner information tracked per
apid. Introduce a per apid structure to track all the three.
Change-Id: I256546a7a4683a463beb6d0eb360a0edd4e5c11d
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The current driver uses a mix of radix tree and a fwd lookup
table to translate between apid and ppid. It is buggy and confusing.
Instead simply use a radix tree for v1 hardware and use the
forward lookup table for v2.
Change-Id: I74e1dc0c3dbbf2b311786af7d80a9d4810d510d7
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The driver currently uses "apid" and "chan" to mean apid. Remove
the use of chan and use only apid.
On a SPMI bus there is allocation to manage up to 4K peripherals.
However, in practice only few peripherals are instantiated
and only few among the instantiated ones actually interrupt.
APID is CPU's way of keeping track of peripherals that could interrupt.
There is a table that maps the 256 interrupting peripherals to
a number between 0 and 255. This number is called APID.Information about
that interrupting peripheral is stored in registers offset by its
corresponding number between 0 and 255.
Change-Id: Icdb82da24232a5382ed03b7437c3207db1befa94
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Usually *_dev best used for structures that embed a struct device in
them. spmi_pmic_arb_dev doesn't embed one. It is simply a driver data
structure. Use an appropriate name for it.
Change-Id: I432eeb0273cac78638440cd00c64cc568ccd68c5
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
There are many places in the driver that left shift the bit to
generate a bit mask. It is simpler to use BIT() macro.
Change-Id: I05ac8469304458a0f26aafd1292fcbb65d312f0a
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The system crashes due to bad access when reading from an non configured
peripheral and when writing to peripheral which is not owned by current
ee. This patch verifies ownership to avoid crashing on
write.
For reads, since the forward mapping table, data_channel->ppid, is
towards the end of the block, we use the core size to figure the
max number of ppids supported. The table starts at an offset of 0x800
within the block, so size - 0x800 will give us the area used by the
table. Since each table is 4 bytes long (core_size - 0x800) / 4 will
gives us the number of data_channel supported.
This new protection is functional on hw v2.
Change-Id: I74e3452963a7dda9a8c8aaef76de3117cabc454b
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Add support for more than 128 peripherals by taking a lazy
caching approach to the mapping tables. Instead of reading and
caching the tables at boot given some fixed size, read them and
cache them on an as needed basis. We still assume a max size of
512 peripherals, trading off some space for simplicity.
Based on a patch by Gilad Avidov <gavidov@codeaurora.org> and
Sagar Dharia <sdharia@codeaurora.org>.
Change-Id: I90ae4100195eef3303b3d6501d3c3ffdbce085b7
Cc: Gilad Avidov <gavidov@codeaurora.org>
Cc: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The current driver uses irq_read_line api which is not standard.
Instead use a gpio and register for an interrupt when it changes
states. And upon a change in state interrupt is received, read the
gpio state to determine whether it is high or low.
Change-Id: Ie4b1226cedfb44e65a84349da4b3eef5fe988dff
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The get_revid_data() could return NULL. Check for this condition
in addition to checking for error conditions.
Change-Id: I3ddbb6645dae0fcfe4f667b8d7b09b2143fe5e2d
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The regulator registration api's need a descriptor to access mode
matching functions. Pass in NULL since mem-acc-regulators don't use mode
matching functions.
Change-Id: I4a23021e004fa749715c246e4685df8c5b75131f
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
4.4 kernel has renamed regulator_set_optimum_mode api as regulator_set_load.
Update proxy-consumer to use it.
Change-Id: Ie56f8d26c1eadd4f2a12a5529683b8f402511e80
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The regulator registration api's need a descriptor to access mode
matching functions. rpm-smd-regulators don't use that feature.
Pass in a descriptor with that function pointer set to NULL.
Change-Id: I4a23021e004fa749715c246e4685df8c5b75131f
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The regulator registration api's need a descriptor to access mode
matching functions. qpnp-regulators, cpr3-regulators, kryo-regulators don't
use that feature. Pass in a descriptor with that function pointer set to NULL.
Change-Id: I0c89fa99c0b9960ce4e14e3a60ed55901bdd8b09
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The regulator registration api's need a descriptor to access mode
matching functions. spm-regualtors don't use that feature. Pass in a
descriptor with that function pointer set to NULL.
Change-Id: Ia37b1904e717369ff2f45012c2d43ec5f912b10b
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The 4.4 kernel changes alarm_start_relative() to return void.
Update the qpnp-fg driver to skip checking the return value.
Change-Id: I607d341875a73ce326244d6864a4f3f3e32099ed
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Change,
a0c7b16 regulator: of: Provide simplified DT parsing method
enables to register a regulator without constructing an regulator_init_data
structure. The regulator_init_data is instantiated within the
registration api and is filled with information by parsing the regualtor
device node.
Avail of this convenience while registering regulators in the
driver.
Change-Id: I0d3c6e221b60a79ab011a180c7daa687b69580b1
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Change,
a0c7b16 regulator: of: Provide simplified DT parsing method
enables to register a regulator without constructing an regulator_init_data
structure. The regulator_init_data is instantiated within the
registration api and is filled with information by parsing the regualtor
device node.
Avail of this convenience while registering OTG regulators in the
smb135x and smb1351 drivers.
Change-Id: I2eb2866f9941db797ede1676e92bb87b4a23c925
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Change,
a0c7b16 regulator: of: Provide simplified DT parsing method
enables to register a regulator without constructing an regulator_init_data
structure. The regulator_init_data is instantiated within the
registration api and is filled with information by parsing the regualtor
device node.
Avail of this convenience while registering OTG regulators in the
qpnp-smbcharger driver.
Change-Id: I2ba14d3bea7d839f8055401d69d7461d2f54aa8e
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The power_supply class in 4.4 kernel changes power_supply
registration to pass in a descriptor and a configuration
structure. Update msm power_supply registering drivers with
the new scheme.
Change-Id: Iaf63a96ab01f9d4676681ee4e6cf61ac2e8d3f4d
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
API's like
power_supply_set_supply_type
power_supply_set_online,
power_supply_set_present
power_supply_set_current_limit
power_supply_set_health_state
power_supply_set_supply_type
power_supply_set_dp_dm
can be replaced by using
power_supply_set_property introduced in the 4.4 kernel.
Update all such callsites to use power_supply_set_property.
Change-Id: I10df60c8012358b6773a8bd1802a26d9540ade9b
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Conflicts:
drivers/power/qpnp-smbcharger.c
Replace all call sites which invoke the get/set_property apis on the
power_supply object with power_supply_get/set_property() api call.
Change-Id: Ibd4c5db6a50734f827878589df1f3e48a0062a06
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
__get_cpu_ptr is now deprecated. Switch to using this_cpu_ptr
Change-Id: If9a6c5d886ef4dd4f82915220c5c954588ead096
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
This is a snapshot of the SPM driver from 3.18 kernel. The upstream spm.c
file is used as a idle driver. So updated spm driver from 3.18 kernel to
msm-spm.c on 4.4 kernel.
Change-Id: I73b020214fdcc7eb695cf8f5b52cf7885a0a10cd
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
This reverts commit b2296bd43e.
The change results in the following incorrect behavior.
If a given regulator has a parent supply and the regulator is
enabled either before or during regulator_register(), then
regulator_enable() is called on the supply. Unfortunately, there
is no matching regulator_disable() call. This means that the
parent supply will stay enabled forever even if the child is
disabled later.
The stated goal of the change was to enable the parent of a
regulator which was enabled based on its machine constraints.
However, the only constraints that leads to enable() being called
for a regulator are boot-on or always-on. If these have been
specified for a child regulator then they should have also been
specified for its parent regulator. Therefore, there should be
no need to explicitly enable the parent when the child is
registered.
Change-Id: Ib8e6db65dcd44c27ef99509ff0cfd2f8e16e9f65
CRs-Fixed: 540315
Signed-off-by: David Collins <collinsd@codeaurora.org>
[Removed it form regulator_resolve_supply]
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The current ordering of statements in the rdev_deinit_debugfs()
function causes freed memory to be dereferenced. This occurs
because the regulator_put(rdev->debug_consumer) call results in
debugfs_remove_recursive() being called on
rdev->debug_consumer->debugfs after it was previously removed
by the debugfs_remove_recursive() call to the parent dentry
rdev->debugfs.
Correct this by setting rdev->debug_consumer->debugfs to NULL
after calling debugfs_remove_recursive() for the parent directory
rdev->debugfs. This ensures that the regulator_put() call does
not try to remove the already removed subdirectory and also that
the debugfs callbacks which make use of rdev->debug_consumer are
removed before rdev->debug_consumer is freed in the regulator_put()
call.
Change-Id: Icb7da7949e401f64cf9e71c732cb40e43ddbdc01
Signed-off-by: David Collins <collinsd@codeaurora.org>
Ensure that regulator_put() is called on the core debugfs
consumer pointer for a given regulator when the debugfs interface
is no longer needed. This includes inside of the
regulator_unregister() function as well as in the error return
path of rdev_init_debugfs().
Change-Id: I10563ae1716f31bdc5840d22633fdbfe278330f1
Signed-off-by: David Collins <collinsd@codeaurora.org>
Introduce a regulator_list_corner_voltage function for consumers
that need to know the maximum absolute voltage that may be
physically configured when a regulator is operating at a given
voltage corner.
Change-Id: Ide7a0b502796774fcad01f5cb5679f0938c72f96
Signed-off-by: David Collins <collinsd@codeaurora.org>
[adharmap: fixed merge conflicts]
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Conflicts:
include/linux/regulator/consumer.h
Since the regulator debugfs consumer does not call
regulator_allow_bypass() on its regulator handles, regulators
will not be placed on bypass mode even if all other consumers
request for this. Fix this by introducing an open offset count
that can be used to selectively disregard the debugfs consumer.
Also, introduce a debugfs file to allow or disallow bypass
mode on each regulator by leveraging on the new open offset count.
Change-Id: If12534dac5e6b1c82acac9b5250137b4f816b922
Signed-off-by: Osvaldo Banuelos <osvaldob@codeaurora.org>
Add a call to regulator_proxy_consumer_register() at the end of
regulator_register() and a call to
regulator_proxy_consumer_unregister() at the beginning of
regulator_unregister(). These calls ensure that proxy consumer
features may be used by any type of regulator regardless of the
driver supporting it.
Change-Id: Ia70da1df47042fa673c42f389136557f868d19a3
Signed-off-by: David Collins <collinsd@codeaurora.org>
[abhimany: resolve trivial merge conflicts]
Signed-off-by: Abhimanyu Kapur <abhimany@codeaurora.org>
[adharmap: resolve trivial merge conflicts]
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Move regulator debugfs functions into core.c. This change allows the user
to read and edit regulator information in user space through the debugfs
file system.
Change-Id: I21fa2c1d5d4ab27871ebb543134c2cee5ad70ded
Signed-off-by: Brandon Leong <bleong@codeaurora.org>
[abhimany: constify reg ops]
Signed-off-by: Abhimanyu Kapur <abhimany@codeaurora.org>
[adharmap: resolve merge conflicts, renamed set_optimum to set_load]
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Conflicts:
drivers/regulator/core.c
Add error messages into the regulator_check_voltage() and
regulator_check_consumers() functions which explain exactly what
is not correct about given voltage requests. This makes
debugging regulator_set_voltage() errors easier.
Change-Id: I8b3ec8d6a78c94b436b57bd2228b8bd5c362cecd
Signed-off-by: David Collins <collinsd@codeaurora.org>
The regulator framework checks if the current mode is the same as the
one being requested inside of regulator_set_mode. However, when
DRMS changing is allowed, regulator_enable calls drms_uA_update.
This function does not check the value of get_mode before calling
set_mode.
Modify drms_uA_update so that set_mode is only called if the requested
mode is different from the current mode returned by get_mode.
Change-Id: Ifb4f3069cf946e8474565ee82508c1ff45b36543
Signed-off-by: David Collins <collinsd@codeaurora.org>
[adharmap: resolved merge conflicts]
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
