Without the include we get build errors like:

drivers/power/smb347-charger.c: In function 'smb347_probe':
drivers/power/smb347-charger.c:1039:2: error: implicit declaration of function 'IS_ERR' [-Werror=implicit-function-declaration]
drivers/power/smb347-charger.c:1040:3: error: implicit declaration of function 'PTR_ERR' [-Werror=implicit-function-declaration]
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

CURRENT_NOW and VOLTAGE_NOW should be instantaneous readings
from power supply(ex: battery).

smb347 charger driver reports charge voltage for VOLTAGE_NOW
and charge current for CURRENT_NOW attributes which are not
instantaneous readings.

This patch removes the battery VOLTAGE_NOW and CURRENT_NOW
properties from the driver and also removes hw_to_current()
which is not required anymore.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

max17047 is improved version of max17042 chip. It has few HW bug
fixes with minor changes in register set.

max17050 is same as max17047 chip except its silicon packging. So from
driver's point of view there is no difference btw max1047 and max1050.

This patch adds the support to dynamically detect the chip type and
adds steps to initialize the max17047 chip.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

Currently, the capacity exported by this driver refers to reg 0x0e,
which is the absolute state of charge which according to SBS
refers to the design capacity/ energy of the battery. It can be
> 100 % and drops below 100 % for a fully charged battery with
the battery aging.

This is not what the user exspects of a remaining capacity
indication between 0 and 100 % with 100 % referring to
a fully charged battery. This is provided by SBS reg 0x0d,
which is the relative state of charge referring to the
full charge capacity.
Signed-off-by: Nikolaus Voss <n.voss@weinmann.de>
Acked-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

We can't use "isp" after freeing it.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

Since we have defined DS2781_PARAM_EEPROM_SIZE and
DS2781_USER_EEPROM_SIZE, use them to simplify the code.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

By using cm_notify_event function, charger driver can report several
charger events (e.g. battery full and external power in/out, etc) to
Charger-Manager. Charger-Manager can properly and immediately control
chargers by the reported event.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Donggeun Kim <dg77.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

Charger-Manager needs to check battery health in normal state
as well as suspend-to-RAM state. When the battery is fully charged,
Charger-Manager needs to determine when the chargers restart charging.

This patch allows Charger-Manager to monitor battery health in normal
state and handle operation for chargers after battery is fully charged.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Donggeun Kim <dg77.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

The smb347-charger driver does a lot of read-modify-write to the device
registers. Instead of open-coding everything we can take advantage of
regmap API which provides nice functions to do this kind of things.

In addition there is no need for custom debugfs file for dumping
registers as this is already provided by the regmap API.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

There is a potential problem if we call smb347_irq_enable() from
smb347_irq_init() because smb347_irq_enable() makes the device registers
read-only once it returns and smb347_irq_init() expects them to still be
read-write. Currently no harm happens because it is the last call we make
in smb347_irq_init().

Anyway a better place for enabling IRQs is at the end of probe function
and this is also symmetric to call smb347_irq_disable() which is done at
the beginning of remove function.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

The naming used in the driver for some functions is not very clear what
the functions are really doing. To make this a bit easier to understand
we rename few functions which were badly named.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

This reduces the amount of boilerplate code in the driver and
makes it a bit simpler.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

This patch checks if the usb or mains charging is enabled by the
platform before registering with the power supply class.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

These patches clean up some ugliness and brings the variable
initialisation formatting more into line with other drivers.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

If no platform data at all is supplied the driver crashes,
extend the checks to be more careful so we can compile in the
driver and boot also without platform data present.
Acked-by: Arun Murthy <arun.murthy@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

If no platform data at all is supplied the driver crashes,
extend the checks to be more careful so we can compile in the
driver and boot also without platform data present.
Acked-by: Arun Murthy <arun.murthy@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

If no platform data at all is supplied the driver crashes,
extend the checks to be more careful so we can compile in the
driver and boot also without platform data present.
Acked-by: Arun Murthy <arun.murthy@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

For some reason the maintainers file only specifies power
supply core files.

We're surely interested in individual drivers as well, so fix
the entry.
Reported-by: Grazvydas Ignotas <notasas@gmail.com>
Reported-by: NeilBrown <neilb@suse.de>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>

suspend/resume functions take action based upon the fuel gauge
interrupt. If the rquest irq fails we should assign 0 to client->irq.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

IRQ registration should happen only after power supply object usable.
This patch fixes the ordering of power supply and irq registration
calls.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

On Mon, Apr 02, 2012 at 01:53:23PM +1000, Benjamin Herrenschmidt wrote:
> > drivers/built-in.o: In function `.nouveau_pm_trigger':
> > (.text+0xa56e8): undefined reference to `.power_supply_is_system_supplied'
> >
> > nouveau probably needs to depends on CONFIG_POWER_SUPPLY to force a module
> > build with the latter is =m
>
> Ok, not that trivial...
>
> The problem is more like POWER_SUPPLY should be a bool, not a tristate.
>
> If you think about it: you don't want things like nouveau to depend on a
> random subsystem like that, people will never get it. In fact,
> POWER_SUPPLY provides empty inline stubs when not enabled, so that's
> really designed to not have depends...
>
> However that -cannot- work if POWER_SUPPLY is modular and the drivers
> who use it are not.
>
> The only fixes here that make sense I can think of
> that don't also involve Kconfig horrors are:
>
>  - Ugly: in power_supply.h, use the extern variant if
>
>       defined(CONFIG_POWER_SUPPLY) ||
>        (defined(CONFIG_POWER_SUPPLY_MODULE) && defined(MODULE))
>
> IE. use the stub if power supply is a module and what is being built is
> built-in. Of course that's not only ugly, it somewhat sucks from a user
> perspective as the subsystem now exists but can't be used by some
> drivers...
>
>  - Better: Just make the bloody thing a bool :-) The power supply
> framework itself is small enough, just make it a boolean option and
> avoid the problem entirely. The actual power supply sub drivers can
> remain modular of course.
Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>

This adds a new sysfs file called 'voltage_ocv' which gives the
Open Circuit Voltage of the battery.

This property can be used for platform shutdown policies and
can be useful for initial capacity estimations.

Note: This patch is generated against linux-next branch.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

This is what we do for the rest of the drivers, saves some bytes.

Plus a small style change while at it.
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

This patch adds suspend/resume methods to the driver.

In suspend method irq line is disabled to avoid i2c
read/write errors from the interrupt handler as the
i2c bus itself could be in suspend state.
In resume function irq line will be re-enabled.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

This patch fixes driver's remove function: it should free the IRQ.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

There are a couple issues here caused by confusion between sizeof()
and ARRAY_SIZE().  "table_size" should be the number of elements, but we
should allocate it with kcalloc() so that we allocate the correct number
of bytes.

In max17042_init_model() we don't allocate enough space so we go past
the end of the array in max17042_read_model_data() and
max17042_model_data_compare().

In max17042_verify_model_lock() we allocate the right amount of space
but we call max17042_read_model_data() with the wrong number of elements
and also in the for loop we go past the end of the array.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dirk Brandewie <dirk.brandewie@gmail.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>

Pull power management fixes from Rafael J. Wysocki:
 "Fix for an issue causing hibernation to hang on systems with highmem
  (that practically means i386) due to broken memory management (bug
  introduced in 3.2, so -stable material) and PM documentation update
  making the freezer documentation follow the code again after some
  recent updates."

* tag 'pm-for-3.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  PM / Freezer / Docs: Update documentation about freezing of tasks
  PM / Hibernate: fix the number of pages used for hibernate/thaw buffering

The autofs packet size has had a very unfortunate size problem on x86:
because the alignment of 'u64' differs in 32-bit and 64-bit modes, and
because the packet data was not 8-byte aligned, the size of the autofsv5
packet structure differed between 32-bit and 64-bit modes despite
looking otherwise identical (300 vs 304 bytes respectively).

We first fixed that up by making the 64-bit compat mode know about this
problem in commit a32744d4 ("autofs: work around unhappy compat
problem on x86-64"), and that made a 32-bit 'systemd' work happily on a
64-bit kernel because everything then worked the same way as on a 32-bit
kernel.

But it turned out that 'automount' had actually known and worked around
this problem in user space, so fixing the kernel to do the proper 32-bit
compatibility handling actually *broke* 32-bit automount on a 64-bit
kernel, because it knew that the packet sizes were wrong and expected
those incorrect sizes.

As a result, we ended up reverting that compatibility mode fix, and
thus breaking systemd again, in commit fcbf94b9.

With both automount and systemd doing a single read() system call, and
verifying that they get *exactly* the size they expect but using
different sizes, it seemed that fixing one of them inevitably seemed to
break the other.  At one point, a patch I seriously considered applying
from Michael Tokarev did a "strcmp()" to see if it was automount that
was doing the operation.  Ugly, ugly.

However, a prettier solution exists now thanks to the packetized pipe
mode.  By marking the communication pipe as being packetized (by simply
setting the O_DIRECT flag), we can always just write the bigger packet
size, and if user-space does a smaller read, it will just get that
partial end result and the extra alignment padding will simply be thrown
away.

This makes both automount and systemd happy, since they now get the size
they asked for, and the kernel side of autofs simply no longer needs to
care - it could pad out the packet arbitrarily.

Of course, if there is some *other* user of autofs (please, please,
please tell me it ain't so - and we haven't heard of any) that tries to
read the packets with multiple writes, that other user will now be
broken - the whole point of the packetized mode is that one system call
gets exactly one packet, and you cannot read a packet in pieces.
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Miller <davem@davemloft.net>
Cc: Ian Kent <raven@themaw.net>
Cc: Thomas Meyer <thomas@m3y3r.de>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

The file Documentation/power/freezing-of-tasks.txt was still referencing
the TIF_FREEZE flag, that was removed by the commit
d88e4cb6(freezer: remove now unused
TIF_FREEZE).

This patch removes all the references of TIF_FREEZE that were left
behind.
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

The actual internal pipe implementation is already really about
individual packets (called "pipe buffers"), and this simply exposes that
as a special packetized mode.

When we are in the packetized mode (marked by O_DIRECT as suggested by
Alan Cox), a write() on a pipe will not merge the new data with previous
writes, so each write will get a pipe buffer of its own.  The pipe
buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn
will tell the reader side to break the read at that boundary (and throw
away any partial packet contents that do not fit in the read buffer).

End result: as long as you do writes less than PIPE_BUF in size (so that
the pipe doesn't have to split them up), you can now treat the pipe as a
packet interface, where each read() system call will read one packet at
a time.  You can just use a sufficiently big read buffer (PIPE_BUF is
sufficient, since bigger than that doesn't guarantee atomicity anyway),
and the return value of the read() will naturally give you the size of
the packet.

NOTE! We do not support zero-sized packets, and zero-sized reads and
writes to a pipe continue to be no-ops.  Also note that big packets will
currently be split at write time, but that the size at which that
happens is not really specified (except that it's bigger than PIPE_BUF).
Currently that limit is the system page size, but we might want to
explicitly support bigger packets some day.

The main user for this is going to be the autofs packet interface,
allowing us to stop having to care so deeply about exact packet sizes
(which have had bugs with 32/64-bit compatibility modes).  But user
space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will
fail with an EINVAL on kernels that do not support this interface.
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Miller <davem@davemloft.net>
Cc: Ian Kent <raven@themaw.net>
Cc: Thomas Meyer <thomas@m3y3r.de>
Cc: stable@kernel.org  # needed for systemd/autofs interaction fix
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull staging tree fixes from Greg Kroah-Hartman:
 "Here are some tiny drivers/staging/ bugfixes.  Some build fixes that
  were recently reported, as well as one kfree bug that is hitting a
  number of users."

* tag 'staging-3.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  staging: ozwpan: Fix bug where kfree is called twice.
  staging: octeon-ethernet: fix build errors by including interrupt.h
  staging: zcache: fix Kconfig crypto dependency
  staging: tidspbridge: remove usage of OMAP2_L4_IO_ADDRESS

Pull USB fixes from Greg Kroah-Hartman:
 "Here are a number of small USB fixes for 3.4-rc5.

  Nothing major, as before, some USB gadget fixes.  There's a crash fix
  for a number of ASUS laptops on resume that had been reported by a
  number of different people.  We think the fix might also pertain to
  other machines, as this was a BIOS bug, and they seem to travel to
  different models and manufacturers quite easily.  Other than that,
  some other reported problems fixed as well."

* tag 'usb-3.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  usb: gadget: udc-core: fix incompatibility with dummy-hcd
  usb: gadget: udc-core: fix wrong call order
  USB: cdc-wdm: fix race leading leading to memory corruption
  USB: EHCI: fix crash during suspend on ASUS computers
  usb gadget: uvc: uvc_request_data::length field must be signed
  usb: gadget: dummy: do not call pullup() on udc_stop()
  usb: musb: davinci.c: add missing unregister
  usb: musb: drop __deprecated flag
  USB: gadget: storage gadgets send wrong error code for unknown commands
  usb: otg: gpio_vbus: Add otg transceiver events and notifiers

Pull btrfs fixes from Chris Mason:
 "This has our collection of bug fixes.  I missed the last rc because I
  thought our patches were making NFS crash during my xfs test runs.
  Turns out it was an NFS client bug fixed by someone else while I tried
  to bisect it.

  All of these fixes are small, but some are fairly high impact.  The
  biggest are fixes for our mount -o remount handling, a deadlock due to
  GFP_KERNEL allocations in readdir, and a RAID10 error handling bug.

  This was tested against both 3.3 and Linus' master as of this morning."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: (26 commits)
  Btrfs: reduce lock contention during extent insertion
  Btrfs: avoid deadlocks from GFP_KERNEL allocations during btrfs_real_readdir
  Btrfs: Fix space checking during fs resize
  Btrfs: fix block_rsv and space_info lock ordering
  Btrfs: Prevent root_list corruption
  Btrfs: fix repair code for RAID10
  Btrfs: do not start delalloc inodes during sync
  Btrfs: fix that check_int_data mount option was ignored
  Btrfs: don't count CRC or header errors twice while scrubbing
  Btrfs: fix btrfs_ioctl_dev_info() crash on missing device
  btrfs: don't return EINTR
  Btrfs: double unlock bug in error handling
  Btrfs: always store the mirror we read the eb from
  fs/btrfs/volumes.c: add missing free_fs_devices
  btrfs: fix early abort in 'remount'
  Btrfs: fix max chunk size check in chunk allocator
  Btrfs: add missing read locks in backref.c
  Btrfs: don't call free_extent_buffer twice in iterate_irefs
  Btrfs: Make free_ipath() deal gracefully with NULL pointers
  Btrfs: avoid possible use-after-free in clear_extent_bit()
  ...

Pull ARM SoC fixes from Olof Johansson:
 "Nothing controversial, just another batch of fixes:

   - Samsung/exynos fixes for more merge window fallout: build errors
     and warnings mostly, but also some clock/device setup issues on
     exynos4/5
   - PXA bug and warning fixes related to gpio and pinmux
   - IRQ domain conversion bugfixes for U300 and MSM
   - A regulator setup fix for U300"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: PXA2xx: MFP: fix potential direction bug
  ARM: PXA2xx: MFP: fix bug with MFP_LPM_KEEP_OUTPUT
  arm/sa1100: fix sa1100-rtc memory resource
  ARM: pxa: fix gpio wakeup setting
  ARM: SAMSUNG: add missing MMC_CAP2_BROKEN_VOLTAGE capability
  ARM: EXYNOS: Fix compilation error when CONFIG_OF is not defined
  ARM: EXYNOS: Fix resource on dev-dwmci.c
  ARM: S3C24XX: Fix build warning for S3C2410_PM
  ARM: mini2440_defconfig: Fix build error
  ARM: msm: Fix gic irqdomain support
  ARM: EXYNOS: Fix incorrect initialization of GIC
  ARM: EXYNOS: use 'exynos4-sdhci' as device name for sdhci controllers
  ARM: u300: bump all IRQ numbers by one
  ARM: ux300: Fix unimplementable regulation constraints

Pull drm fixes from Dave Airlie:
 "As soon as I sent the non-urgent stack, two important fixes come in:

   - i915: fixes SNB GPU hangs in a number of 3D apps

   - radeon: initial fix for VGA on LLano system, 3 or 4 of us have
     spent time debugging this, and Jerome finally figured out the magic
     bit the BIOS/fglrx set that we didn't.  This at least should get
     things working, there may be future reliability fixes."

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/i915: Set the Stencil Cache eviction policy to non-LRA mode.
  drm/radeon/kms: need to set up ss on DP bridges as well

This reverts commit a32744d4.

While that commit was technically the right thing to do, and made the
x86-64 compat mode work identically to native 32-bit mode (and thus
fixing the problem with a 32-bit systemd install on a 64-bit kernel), it
turns out that the automount binaries had workarounds for this compat
problem.

Now, the workarounds are disgusting: doing an "uname()" to find out the
architecture of the kernel, and then comparing it for the 64-bit cases
and fixing up the size of the read() in automount for those.  And they
were confused: it's not actually a generic 64-bit issue at all, it's
very much tied to just x86-64, which has different alignment for an
'u64' in 64-bit mode than in 32-bit mode.

But the end result is that fixing the compat layer actually breaks the
case of a 32-bit automount on a x86-64 kernel.

There are various approaches to fix this (including just doing a
"strcmp()" on current->comm and comparing it to "automount"), but I
think that I will do the one that teaches pipes about a special "packet
mode", which will allow user space to not have to care too deeply about
the padding at the end of the autofs packet.

That change will make the compat workaround unnecessary, so let's revert
it first, and get automount working again in compat mode.  The
packetized pipes will then fix autofs for systemd.
Reported-and-requested-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Ian Kent <raven@themaw.net>
Cc: stable@kernel.org # for 3.3
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Clearing bit 5 of CACHE_MODE_0 is necessary to prevent GPU hangs in
OpenGL programs such as Google MapsGL, Google Earth, and gzdoom when
using separate stencil buffers.  Without it, the GPU tries to use the
LRA eviction policy, which isn't supported.  This was supposed to be off
by default, but seems to be on for many machines.

This cannot be done in gen6_init_clock_gating with most of the other
workaround bits; the render ring needs to exist.  Otherwise, the
register write gets dropped on the floor (one printk will show it
changed, but a second printk immediately following shows the value
reverts to the old one).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47535
Cc: stable@vger.kernel.org
Cc: Rob Castle <futuredub@gmail.com>
Cc: Eric Appleman <erappleman@gmail.com>
Cc: aaron667@gmx.net
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Makes Nutmeg DP to VGA bridges work for me.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=42490

Noticed by Jerome Glisse (after weeks of debugging).
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>