Add helper function msi_desc_to_pci_sysdata() to retrieve sysdata from
an MSI descriptor. To avoid pulling include/linux/pci.h into
include/linux/msi.h, msi_desc_to_pci_sysdata() is implemented as a normal
function instead of an inline function.
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Reviewed-by: Yijing Wang <wangyijing@huawei.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Stuart Yoder <stuart.yoder@freescale.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Alexander Gordeev <agordeev@redhat.com>
Link: http://lkml.kernel.org/r/1436428847-8886-2-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Update the last pr_warning callsite in drivers/irqchip.
Signed-off-by: Wang Long <long.wanglong@huawei.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <wanglong@laoqinren.net>
Cc: <peifeiyue@huawei.com>
Cc: <jason@lakedaemon.net>
Cc: <kgene@kernel.org>
Cc: <k.kozlowski@samsung.com>
Link: http://lkml.kernel.org/r/1437466261-147373-1-git-send-email-long.wanglong@huawei.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
As it turns out the current IRQ number will *always* be available from
SIR register which renders the reads of PENDING registers as plain
unnecessary overhead.
In order to catch any situation where SIR reads as zero, we're adding
a WARN() to turn it into a very verbose error and users actually
report it.
With this patch average running time of omap_intc_handle_irq() reduced
from about 28.5us to 19.8us as measured by the kernel function
profiler.
Tested with BeagleBoneBlack Rev A5C.
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Cc: Linux ARM Kernel Mailing List <linux-arm-kernel@lists.infradead.org>
Link: http://lkml.kernel.org/r/20150720204910.GH5394@saruman.tx.rr.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Use eth_zero_addr to assign the zero address to the given address
array instead of memset when second argument is address of zero.
The Coccinelle semantic patch that makes this change is as follows:
// <smpl>
@eth_zero_addr@
expression e;
@@
-memset(e,0x00,ETH_ALEN);
+eth_zero_addr(e);
// </smpl>
Signed-off-by: Vaishali Thakkar <vthakkar1994@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Fix code indentation error by replacing tab in place of spaces.
Signed-off-by: Sunil Shahu <shshahu@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
COLORSPACE_JPEG should only be used for JPEGs. Use SMPTE170M instead,
which is how YCbCr images are usually encoded.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Format mac addresses with the normal kernel extension.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
task_struct and the asm offsets becoming too large for the AArch64 ISA
- preparatory patch for moving irq_data struct members (applied now to
reduce dependency for the next merging window)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVr5iXAAoJEGvWsS0AyF7x+j4P/Ak5EnDp9k+q8gn4Q+xd+XWS
2i/43LgH0Q4n1BruttzYGIzYHVP3j1TVy41dIcQeFTf3nubl7Pz197H63t8lY51I
C9wiMjavWZ8YetzHsE+3K/7NkuHYom5q0V9PmzgzQ/DXVfgv8G2F1iwoBqXlfhxg
N0UTZKzr0dx9jxPmmHBThuReAjiDeLK2qLXiNpbUwAUyfTWq+Q/NQWxuBBqTCjd9
biICv0kFHVI0UH39Q9K78xi4VZ9fpcmsb5mTiijbGJTgLqrC+XkSCIBiKmMm/2sI
lxS5mKcprCh4X1xaBSQ/iyAqWOyZ5Z0oTV7b9dLN0Ai+0cnAIYuYkFeCZwvrfhXz
bg4O0lY91QzXn6SVBgu6i/coblR/O8s49VqRpqoFZogCQHAdBstjzLo9IFUp16To
Dv2I1pn3Z8qCbeRXZdRYLa5/WKfjdWkTkW8ucyX97eE4N/PSa4213w37HUOtPboE
HAGJpahrAbeYE+6AViZwUQ8QT0Q6UESm4OtOV5lP/m9vxVDq38uxHUK7ilqHhJt7
yDvIr5Ufvi4g0Grj9SGSuAa2c1C3GV2eTBekXeZ5w+VAo2ITVGx6xSVpsA7PFYP9
vS6j9X0oNR5LXkGRZW2sxbQZsRPnQBeQuSopo4CuRD9aszKS4XrCJ+R1U8EM/ixi
82fmhx1hjwJPkTcds9lY
=GPY8
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull ARM64 fixes from Catalin Marinas:
- arm64 build fix following the move of the thread_struct to the end of
task_struct and the asm offsets becoming too large for the AArch64
ISA
- preparatory patch for moving irq_data struct members (applied now to
reduce dependency for the next merging window)
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
ARM64/irq: Use access helper irq_data_get_affinity_mask()
arm64: switch_to: calculate cpu context pointer using separate register
Running `make modules_install` ordinarily will overwrite existing
modules. This is the desired behavior, and is how pretty much every
other `make install` target works.
However, if CONFIG_MODULE_COMPRESS is enabled, modules are passed
through gzip and xz which then do the file writing. Both gzip and xz
will error out if the file already exists, unless -f is passed.
This patch adds -f so that the behavior is uniform.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
Initialize the ARCH_* overrides before including the arch Makefile, to
avoid picking up the values from the environment. The variables can
still be overriden on the make command line, but this won't happen
by accident.
Signed-off-by: Michal Marek <mmarek@suse.com>
Two nice things here:
- drm_dev_register will truly register everything in the right order
if the driver doesn't have a ->load callback. Before this we had to
init the primary mode_group after the device nodes where already
registered.
- Less things to keep track of when reworking the connector locking,
yay!
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
It's been dead code since forever since mode groups haven't ever been
implemented. On top of that it's also been non-functional since we
only ever filtered the getresources ioctl and not any of the others
nor the mode object lookup code.
Given overwhelming evidence it looks like this isn't a feature we
need, hence remove it.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Remaining manual work in the drm core&helpers. Nothing special here,
no surprises.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This function takes two locks, both of them the wrong ones. This
wasn't an oversight from my fb locking rework since both patches
landed in parallel. We really only need fb_lock when walking that
list, since everything we can reach from that is refcounted properly
already.
v2: Drop unused dev spotted by 0day.
Cc: Rob Clark <robdclark@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
region_is_ram() looks up the iomem_resource table to check if
a target range is in RAM. However, it always returns with -1
due to invalid range checks. It always breaks the loop at the
first entry of the table.
Another issue is that it compares p->flags and flags, but it always
fails. flags is declared as int, which makes it as a negative value
with IORESOURCE_BUSY (0x80000000) set while p->flags is unsigned long.
Fix the range check and flags so that region_is_ram() works as
advertised.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Cc: Mike Travis <travis@sgi.com>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Roland Dreier <roland@purestorage.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1437088996-28511-4-git-send-email-toshi.kani@hp.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
__ioremap_caller() calls region_is_ram() to walk through the
iomem_resource table to check if a target range is in RAM, which was
added to improve the lookup performance over page_is_ram() (commit
906e36c5c7 "x86: use optimized ioresource lookup in ioremap
function"). page_is_ram() was no longer used when this change was
added, though.
__ioremap_caller() then calls walk_system_ram_range(), which had
replaced page_is_ram() to improve the lookup performance (commit
c81c8a1eee "x86, ioremap: Speed up check for RAM pages").
Since both checks walk through the same iomem_resource table for
the same purpose, there is no need to call both functions.
Aside of that walk_system_ram_range() is the only useful check at the
moment because region_is_ram() always returns -1 due to an
implementation bug. That bug in region_is_ram() cannot be fixed
without breaking existing ioremap callers, which rely on the subtle
difference of walk_system_ram_range() versus non page aligned ranges.
Once these offending callers are fixed we can use region_is_ram() and
remove walk_system_ram_range().
[ tglx: Massaged changelog ]
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Cc: Roland Dreier <roland@purestorage.com>
Cc: Mike Travis <travis@sgi.com>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1437088996-28511-3-git-send-email-toshi.kani@hp.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
__ioremap_check_ram() has a WARN_ONCE() which is emitted when the
given pfn range is not RAM. The warning is bogus in two aspects:
- it never triggers since walk_system_ram_range() only calls
__ioremap_check_ram() for RAM ranges.
- the warning message is wrong as it says: "ioremap on RAM' after it
established that the pfn range is not RAM.
Move the WARN_ONCE() to __ioremap_caller(), and update the message to
include the address range so we get an actual warning when something
tries to ioremap system RAM.
[ tglx: Massaged changelog ]
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Cc: Roland Dreier <roland@purestorage.com>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1437088996-28511-2-git-send-email-toshi.kani@hp.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
When zones were originally introduced, the expectation functions were
all extended to perform lookup using the zone. However, insertion was
not modified to check the zone. This means that two expectations which
are intended to apply for different connections that have the same tuple
but exist in different zones cannot both be tracked.
Fixes: 5d0aa2ccd4 (netfilter: nf_conntrack: add support for "conntrack zones")
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
This is useful to subscribe to HDMI hotplug events via the
V4L2_CID_DV_RX_POWER_PRESENT control.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
When probed from device tree, the i2c client driver can handle the interrupt
on its own.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Add support for probing the TC358743 subdevice from device tree.
The reference clock must be supplied using the common clock bindings.
MIPI CSI-2 specific properties are parsed from the OF graph endpoint
node and support for a non-continuous MIPI CSI-2 clock is added.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The crossbar for eDMA works exactly the same way as sDMA, but sDMA
requires an offset of 1, while no offset is needed for eDMA.
Based on the patch from Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Now that we also grab the connection_mutex and so fixed the race with
atomic modeset we can use the iterator there too.
The other special case is drm_connector_unplug_all which would have a
locking inversion with the sysfs store/show functions if we'd grab the
mode_config.mutex around the unplug. We could just grab
connection_mutex instead, but that's a bit too much a dirty trick for
my taste. Also it's only used by udl, which doesn't do any other kind
of connector hotplugging, so should be race-free. Hence just stick
with a comment for now.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Now that dp mst hotplug takes all locks we can amend the locking rules
for the iterators. This is needed before we can roll these out in the
atomic code to avoid getting burried in WARNINGs.
v2: Rebase onto the extracted list locking assert and add a comment to
explain the rules.
v3: Fixup German->English translation fail in the comment.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Similar with the i915 take all modeset locks for mst hotplug. This is
needed to make sure radeon holds both mode_config.mutex and
mode_config.connection_mutex when updating the connector_list, which
is the new (interim) locking regime we want for that.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
While auditing various users of the connector/encoder lists I realized
that the atomic code is a very prolific user of them. And it only ever
grabs the mode_config->connection_mutex, but not the
mode_config->mutex like all the other code walking encoder/connector
lists.
The problem is that we can't grab the mode_config.mutex late in atomic
code since that would lead to locking inversions. And we don't want to
grab it unconditionally like the legacy set_config modeset path since
that would render all the fine-grained locking moot.
Instead just grab more locks in the dp mst hotplug code. Note that
drm_connector_init (which is the one adding the connector to these
lists) already uses drm_modeset_lock_all.
The other reason for grabbing all locks is that the dpms off in the
unplug function amounts to a modeset, so better to take all required
locks for that.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Ever since framebuffers are reference counted we have a special lock
for the global fb list. Make sure users of that list do hold that
lock when using the new iterators.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Just so I have a user for this macro.
v2: Use the right macro - somehow I thought gcc should scream at me,
but list_for_each isn't really typesafe unfortunately. Spotted by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Because of DP MST connectors can now be hotplugged and we must hold
the right lock when walking the connector lists. Enforce this by
checking the locking in our shiny new list walking macros.
v2: Extract the locking check into a small static inline helper to
help readability. This will be more important when we make the
read list access rules more complicated in later patches. Inspired by
comments from Chris. Unfortunately, due to header loops around the
definition of struct drm_device the function interface is a bit funny.
v3: Encoders aren't hotadded/removed. For each dp mst encoder we
statically create one fake encoder per pipe so that we can support as
many mst sinks as the hw can (Dave).
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This is now truly only duct-tape to keep locking checks happy since
calling this function when hpd or polling are already enabled is a
bug. The fbdev helper can't cope with hotplug changes yet at this
point, only after that.
Otoh a bit more robustness in this function can't hurt, and with this
fbdev can actually cope with hotplug changes. And it's also more
consistent with the connector hotadd/remove dp mst needs to do.
Therefore document this as new official behavior.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
So on first looks this seems superflous since drivers should ensure
correct ordering to not make this a problem. Otoh ordering constraints
between hdp, fbdev load and enabling polling are already tricky on
some hardware and it helps to be more robust.
But the real goal is to just shut up a locking WARN_ON I'd like to
add, which means init code gets some additional locks just for
uniformity.
v2: Also grab the lock for the public poll_enable, not just poll_init
which is used for resume, with the same justification.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
And roll them out across drm_* files. The point here isn't code
prettification (it helps with that too) but that some of these lists
aren't static any more. And having macros will gives us a convenient
place to put locking checks into.
I didn't add an iterator for props since that's only used by a
list_for_each_entry_safe in the driver teardown code.
Search&replace was done with the below cocci spatch. Note that there's
a bunch more places that didn't match and which would need some manual
changes, but I've intentially left these out for this mostly automated
patch.
iterator name drm_for_each_crtc;
struct drm_crtc *crtc;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
+ drm_for_each_crtc (crtc, dev) {
...
}
@@
iterator name drm_for_each_encoder;
struct drm_encoder *encoder;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
+ drm_for_each_encoder (encoder, dev) {
...
}
@@
iterator name drm_for_each_fb;
struct drm_framebuffer *fb;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(fb, &dev->mode_config.fb_list, head) {
+ drm_for_each_fb (fb, dev) {
...
}
@@
iterator name drm_for_each_connector;
struct drm_connector *connector;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ drm_for_each_connector (connector, dev) {
...
}
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
No need to pass the planelist when everyone just uses
dev->mode_config.plane_list anyway.
I want to add a pile more of iterators with unified (obj, dev)
arguments. This is just prep.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Add V4L2_SUBDEV_FL_HAS_DEVNODE to subdev flags, in order to
enable a subdev device node.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Add support for registering the sensor subdevice using the v4l2-async API.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Currently the cobalt driver refuses to load if fewer than 8 PCIe lanes
are assigned. This patch changes this and just issues a warning. The
only time it will refuse to load is if the number of assigned lanes is less
than what the PCIe host is capable of since this suggests that the card
isn't seated correctly in the slot.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
When vb2_is_busy() it should still be possible to call S_DV_TIMINGS
provided the new timings are the same as the current timings.
For input 1 (test generator) the size is always 1080p, so just return
that.
Fixes a v4l2-compliance issue.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
There was a race condition where during cleanup/release operation
on-going streaming would cause a kernel panic because the hardware
module was disabled prematurely with IRQ still pending.
Fixes: 417d2e507e ("[media] media: platform: add VPFE capture driver support for AM437X")
Cc: <stable@vger.kernel.org> # v4.0+
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
This fixes an issue introduced in commit b23c843992 (usb: dwc3:
gadget: fix DEPSTARTCFG for non-EP0 EPs) that made sure we would
only use DEPSTARTCFG once per SetConfig.
The trick is that we should use one DEPSTARTCFG per SetConfig *OR*
SetInterface. SetInterface was completely missed from the original
patch.
This problem became aparent after commit 76e838c9f7 (usb: dwc3:
gadget: return error if command sent to DEPCMD register fails)
added checking of the return status of device endpoint commands.
'Set Endpoint Transfer Resource' command was caught failing
occasionally. This is because the Transfer Resource
Index was not getting reset during a SET_INTERFACE request.
Finally, to fix the issue, was we have to do is make sure that
our start_config_issued flag gets reset whenever we receive a
SetInterface request.
To verify the problem (and its fix), all we have to do is run
test 9 from testusb with 'testusb -t 9 -s 2048 -a -c 5000'.
Tested-by: Huang Rui <ray.huang@amd.com>
Tested-by: Subbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com>
Fixes: b23c843992 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs)
Cc: <stable@vger.kernel.org> # v3.2+
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Add the bdisp (2D blitter for STMicroelectronics SoC) dt nodes for the
first of the two bdisp devices, defining register address, interrupt and
clock.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
It's causing piles of issues since we've stopped forcing full detect
cycles in the sysfs interfaces with
commit c484f02d0f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Mar 6 12:36:42 2015 +0000
drm: Lighten sysfs connector 'status'
The original justification for this was that the hpd handlers could
use the unknown state as a hint to force a full detection. But current
i915 code isn't doing that any more, and no one else really uses reset
on resume. So instead just keep the old state around.
References: http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/62584
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100641
Cc: Rui Matos <tiagomatos@gmail.com>
Cc: Julien Wajsberg <felash@gmail.com>
Cc: kuddel.mail@gmx.de
Cc: Lennart Poettering <mzxreary@0pointer.de>
Cc: stable@vger.kernel.org
Acked-by: Rob Clark <robdclark@gmail.com>
Tested-by: Rui Tiago Cação Matos <tiagomatos@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This adds suspend/resume callbacks, which are common for each DAI.
To be able to continue the last playback/capture after resume
when suspend was done during a playback/capture, in the callbacks
we do backup/restore of registers which were set before prepare stage.
Registers to be backup/restore are defined in a backup list array.
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is a preparatory patch for moving irq_data struct members.
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Commit 0c8c0f03e3 ("x86/fpu, sched: Dynamically allocate 'struct fpu'")
moved the thread_struct to the bottom of task_struct. As a result, the
offset is now too large to be used in an immediate add on arm64 with
some kernel configs:
arch/arm64/kernel/entry.S: Assembler messages:
arch/arm64/kernel/entry.S:588: Error: immediate out of range
arch/arm64/kernel/entry.S:597: Error: immediate out of range
This patch calculates the offset using an additional register instead of
an immediate offset.
Fixes: 0c8c0f03e3 ("x86/fpu, sched: Dynamically allocate 'struct fpu'")
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The PWR_DWN is Bit 7, so current code does not set the PWR_DWN bit. Fix it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
