regulator: MAINTAINERS: update email address

I no longer work at TI.

Signed-off-by: Liam Girdwood <liam.r.girdwood@intel.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
pinctrl: samsung: removing duplicated condition for PINCTRL_SAMSUNG

Now, PINCTRL_SAMSUNG should be enabled with PINCTRL_EXYNOS so we don't
need to add 'depends on' condition already added in PINCTRL_EXYNOS.

Cc: Thomas Abraham <thomas.ab@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: pinctrl-mxs: Fix variables' definition type

Fix the following warnings when building with W=1 option:

drivers/pinctrl/pinctrl-mxs.c: In function 'mxs_dt_free_map':
drivers/pinctrl/pinctrl-mxs.c:151:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
drivers/pinctrl/pinctrl-mxs.c: In function 'mxs_pinctrl_enable':
drivers/pinctrl/pinctrl-mxs.c:208:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
drivers/pinctrl/pinctrl-mxs.c: In function 'mxs_pinconf_group_set':
drivers/pinctrl/pinctrl-mxs.c:265:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
drivers/pinctrl/pinctrl-mxs.c: In function 'mxs_pinctrl_parse_group':
drivers/pinctrl/pinctrl-mxs.c:376:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: mvebu: Fix compiler warnings

match->data is const void * where as dev.platform_data is just void *.
Add a cast to remove the const, which is causing the compiler warning:

drivers/pinctrl/mvebu/pinctrl-kirkwood.c:461:26: warning: assignment
discards 'const' qualifier from pointer target type

Dove has the exact same warning, so gets the same cast.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: mvebu: fix MPP6 value for kirkwood driver

Note that I am not sure about the MPP value for the PTP functionality.
It seems that the PTP references have been removed from the Marvell
hardware specifications available to me.

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
s390/thp: implement pmdp_set_wrprotect()

On s390, an architecture-specific implementation of the function
pmdp_set_wrprotect() is missing and the generic version is currently
being used. The generic version does not flush the tlb as it would be
needed on s390 when modifying an active pmd, which can lead to subtle
tlb errors on s390 when using transparent hugepages.

This patch adds an s390-specific implementation of pmdp_set_wrprotect()
including the missing tlb flush.

Cc: stable@vger.kernel.org
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Revert "pinctrl: single: support gpio request and free"

This reverts commit 2e8b2eab94c35d83bb7da71c63b4695f32ddca88.

Conflicts:
	drivers/pinctrl/pinctrl-single.c

ERROR: "__aeabi_uldivmod" [drivers/pinctrl/pinctrl-single.ko]
undefined!]

On Fri, Jan 11, 2013 at 4:00 PM, Russell King wrote:

> The above error happens in builds including pinctrl-single - the
> reason
> is this, where resource_size_t may be 64-bit.
>
>                 gpio->range.pin_base = (r.start - pcs->res->start) /
>                 mux_bytes;
>                 gpio->range.npins = (r.end - r.start) / mux_bytes + 1;

The reason of not fixing this issue and reverting the patch instead is
this patch can't handle another case. It's not easy to handle multiple
gpios sharing one pin register. So this gpio range feature will be
implemented by other patches.

Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
drm/i915: Disable AsyncFlip performance optimisations

This is a required workarounds for all products, especially on gen6+
where it causes the command streamer to fail to parse instructions
following a WAIT_FOR_EVENT. We use WAIT_FOR_EVENT for synchronising
between the GPU and the display engines, and so this bit being unset may
cause hangs.

References: https://bugzilla.kernel.org/show_bug.cgi?id=52311
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline waits

On SNB, if bit 13 of GFX_MODE, Flush TLB Invalidate Mode, is not set to 1,
the hardware can not program the scanline values. Those scanline values
then control when the signal is sent from the display engine to the render
ring for MI_WAIT_FOR_EVENTs. Note setting this bit means that TLB
invalidations must be performed explicitly through the appropriate bits
being set in PIPE_CONTROL.

References: https://bugzilla.kernel.org/show_bug.cgi?id=52311
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
iommu/intel: disable DMAR for g4x integrated gfx

DMAR support on g4x/gm45 integrated gpus seems to be totally busted.
So don't bother, but instead disable it by default to allow distros to
unconditionally enable DMAR support.

v2: Actually wire up the right quirk entry, spotted by Adam Jackson.

Note that according to intel marketing materials only g45 and gm45
support DMAR/VT-d. So we have reports for all relevant gen4 pci ids by
now. Still, keep all the other gen4 ids in the quirk table in case the
marketing stuff confused me again, which would not be the first time.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51921
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=538163
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=538163
Cc: Adam Jackson <ajax@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: stable@vger.kernel.org
Acked-By: David Woodhouse <David.Woodhouse@intel.com>
Tested-by: stathis <stathis@npcglib.org>
Tested-by: Mihai Moldovan <ionic@ionic.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: dump UTS_RELEASE into the error_state

Useful for statistics or on overflowing bug reports to keep things all
lined up.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/radeon: fix cursor corruption on DCE6 and newer

Aruba and newer gpu does not need the avivo cursor work around,
quite the opposite this work around lead to corruption.

agd5f: check DCE6 rather than ARUBA since the issue is DCE
version specific rather than family specific.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
radeon_display: Use pointer return error codes

drm_mode_addfb() expects fb_create return error code
instead of NULL.

Signed-off-by: xueminsu <xuemin.su@intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
drm/radeon: fix a rare case of double kfree

If one (but not both) allocations of p->chunks[].kpage[]
in radeon_cs_parser_init fail, the error path will free
the successfully allocated page, but leave a stale pointer
value in the kpage[] field. This will later cause a
double-free when radeon_cs_parser_fini is called.
This patch fixes the issue by forcing both pointers to NULL
after kfree in the error path.

The circumstances under which the problem happens are very
rare. The card must be AGP and the system must run out of
kmalloc area just at the right time so that one allocation
succeeds, while the other fails.

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
DM-RAID: Fix RAID10's check for sufficient redundancy

Before attempting to activate a RAID array, it is checked for sufficient
redundancy.  That is, we make sure that there are not too many failed
devices - or devices specified for rebuild - to undermine our ability to
activate the array.  The current code performs this check twice - once to
ensure there were not too many devices specified for rebuild by the user
('validate_rebuild_devices') and again after possibly experiencing a failure
to read the superblock ('analyse_superblocks').  Neither of these checks are
sufficient.  The first check is done properly but with insufficient
information about the possible failure state of the devices to make a good
determination if the array can be activated.  The second check is simply
done wrong in the case of RAID10 because it doesn't account for the
independence of the stripes (i.e. mirror sets).  The solution is to use the
properly written check ('validate_rebuild_devices'), but perform the check
after the superblocks have been read and we know which devices have failed.
This gives us one check instead of two and performs it in a location where
it can be done right.

Only RAID10 was affected and it was affected in the following ways:
- the code did not properly catch the condition where a user specified
  a device for rebuild that already had a failed device in the same mirror
  set.  (This condition would, however, be caught at a deeper level in MD.)
- the code triggers a false positive and denies activation when devices in
  independent mirror sets have failed - counting the failures as though they
  were all in the same set.

The most likely place this error was introduced (or this patch should have
been included) is in commit 4ec1e369 - first introduced in v3.7-rc1.
Consequently this fix should also go in v3.7.y, however there is a
small conflict on the .version in raid_target, so I'll submit a
separate patch to -stable.

Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
drm/radeon: Enable DMA_IB_SWAP_ENABLE on big endian hosts.

Fixes GPU hang during DMA ring IB test.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59672

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Merge branch 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux into drm-next

Alex writes:
Just some small misc fixes.

* 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: Enable DMA_IB_SWAP_ENABLE on big endian hosts.
  drm/radeon: fix a rare case of double kfree
  radeon_display: Use pointer return error codes
  drm/radeon: fix cursor corruption on DCE6 and newer
drm/exynos: let drm handle edid allocations

There's no need to allocate edid twice and do a memcpy when drm helpers
exist to do just that. This patch cleans that interaction up, and
doesn't keep the edid hanging around in the connector.

v4:
- removed error check for drm_mode_connector_update_edid_property
which is expected to fail for Virtual Connectors like VIDI.
Thanks to Seung-Woo Kim.

v3:
- removed MAX_EDID as it is not used anymore.

v2:
- changed vidi_get_edid callback inside vidi driver.

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
drm/exynos: added validation of edid for vidi connection

If edid of vidi from user is invalid, size calculated from a number
of cea extensions can be wrong. So, validation should be checked.

Changelog v2:
- just code cleanup
  . declare raw_edid only if vidi->connection is enabled.

Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
drm/exynos: free sg object if dma_map_sg is failed

This patch releases sgt's sg object allocated by sgt_alloc_table
correctly.

When exynos_gem_map_dma_buf was called by dma_buf_map_attachmemt(),
the sgt's sg object was allocated by sg_alloc_tale() so
if dma_map_sg() is failed, the sg object should be released.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>