Commit 7566bcc76b ("spi: pxa2xx: Move is_lpss_ssp() tests to caller") did
not check LPSS before calling lpss_ssp_setup() in pxa2xx_spi_resume().
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the clock property for the watchdog on rk3288 socs.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
The file arch/x86/xen/mmu.c has some functions that can be annotated
with "__init".
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Some more functions in arch/x86/xen/setup.c can be made "__init".
xen_ignore_unusable() can be made "static".
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
In many places in arch/x86/xen/setup.c wrong types are used for
physical addresses (u64 or unsigned long long). Use phys_addr_t
instead.
Use macros already defined instead of open coding them.
Correct some other type mismatches.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Remove extern declarations in arch/x86/xen/setup.c which are either
not used or redundant. Move needed other extern declarations to
xen-ops.h
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
An interesting bug occurs on Pineview through which the root cause is
that the writes of the PTE values into the GTT is not serialised with
subsequent memory access through the GTT (when using WC updates of the
PTE values). This is despite there being a posting read after the GTT
update. However, by changing the address of the posting read, the memory
access is indeed serialised correctly.
Whilst we are manipulating the memory barriers, we can remove the
compiler :memory restraint on the intermediate PTE writes knowing that
we explicitly perform a posting read afterwards.
v2: Replace posting reads with explicit write memory barriers - in
particular this is advantages in case of single page objects. Update
comments to mention this issue is only with WC writes.
Testcase: igt/gem_exec_big #pnv
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88191
Tested-by: huax.lu@intel.com (v1)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Commit fbc4572e9c48e45b ("drm/bridge: make bridge registration independent of
drm flow") introduced some drm/bridge API modifications. Make the necessary
changes so that we can avoid the build breakage:
drivers/gpu/drm/bridge/dw_hdmi.c: In function 'dw_hdmi_bridge_destroy':
drivers/gpu/drm/bridge/dw_hdmi.c:1378:2: error: implicit declaration of function 'drm_bridge_cleanup' [-Werror=implicit-function-declaration]
drivers/gpu/drm/bridge/dw_hdmi.c: At top level:
drivers/gpu/drm/bridge/dw_hdmi.c:1471:2: error: unknown field 'destroy' specified in initializer
drivers/gpu/drm/bridge/dw_hdmi.c: In function 'dw_hdmi_register':
drivers/gpu/drm/bridge/dw_hdmi.c:1535:2: error: implicit declaration of function 'drm_bridge_init' [-Werror=implicit-function-declaration]
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
So sti doesn't build because the bridge interfaces changes didn't
catch up to its new DVO driver.
Now I might just carry this patch, but I might just push the
bridge pull into a side-pull until someone resolves it.
So this might not be the right solution to the problem, so
please figure it out and let me know ASAP.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
If devm_request_threaded_irq() fails we should jump to 'err_iahb' label that
will disable the clocks that were previously enabled.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Commits 65cef1311d ("x86, microcode: Add a disable chicken bit") and
a18a0f6850 ("x86, microcode: Don't initialize microcode code on
paravirt") allow microcode driver skip initialization when microcode
loading is not permitted.
However, they don't prevent the driver from being loaded since the
init code returns 0. If at some point later the driver gets unloaded
this will result in an oops while trying to deregister the (never
registered) device.
To avoid this, make init code return an error on paravirt or when
microcode loading is disabled. The driver will then never be loaded.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: http://lkml.kernel.org/r/1422411669-25147-1-git-send-email-boris.ostrovsky@oracle.com
Reported-by: James Digwall <james@dingwall.me.uk>
Cc: stable@vger.kernel.org # 3.18
Signed-off-by: Borislav Petkov <bp@suse.de>
Currently ->get_dqblk() and ->set_dqblk() use struct fs_disk_quota which
tracks space limits and usage in 512-byte blocks. However VFS quotas
track usage in bytes (as some filesystems require that) and we need to
somehow pass this information. Upto now it wasn't a problem because we
didn't do any unit conversion (thus VFS quota routines happily stuck
number of bytes into d_bcount field of struct fd_disk_quota). Only if
you tried to use Q_XGETQUOTA or Q_XSETQLIM for VFS quotas (or Q_GETQUOTA
/ Q_SETQUOTA for XFS quotas), you got bogus results. Hardly anyone
tried this but reportedly some Samba users hit the problem in practice.
So when we want interfaces compatible we need to fix this.
We bite the bullet and define another quota structure used for passing
information from/to ->get_dqblk()/->set_dqblk. It's somewhat sad we have
to have more conversion routines in fs/quota/quota.c and another copying
of quota structure slows down getting of quota information by about 2%
but it seems cleaner than overloading e.g. units of d_bcount to bytes.
CC: stable@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jan Kara <jack@suse.cz>
Commit 6fb1ca92a6 "udf: Fix race between write(2) and close(2)"
changed the condition when preallocation is released. The idea was that
we don't want to release the preallocation for an inode on close when
there are other writeable file descriptors for the inode. However the
condition was written in the opposite way so we released preallocation
only if there were other writeable file descriptors. Fix the problem by
changing the condition properly.
CC: stable@vger.kernel.org
Fixes: 6fb1ca92a6
Reported-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Jan Kara <jack@suse.cz>
When setting the video bus supported formats for a display device using
drm_display_info_set_bus_formats(), check for the proper variable after
duplicating memory.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
'make pdfdocs' failed for 80211.tmpl and reported errors of the form:
'document type does not allow element "refentry" here'
Fix this by moving </section> tags to a location that makes sense,
this fixes the errors and the pdf looks OK in relevant areas.
Signed-off-by: Sharon Dvir <sharon.dvir1@mail.huji.ac.il>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Force bridge connector detection at the end of the bridge attach.
This is needed to detect the bridge connector early.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Tested-by: Rahul Sharma <rahul.sharma@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Tested-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add drm_panel calls to the driver to make the panel and
bridge work together in tandem.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Tested-by: Rahul Sharma <rahul.sharma@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Tested-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Currently, third party bridge drivers(ptn3460) are dependent
on the corresponding encoder driver init, since bridge driver
needs a drm_device pointer to finish drm initializations.
The encoder driver passes the drm_device pointer to the
bridge driver. Because of this dependency, third party drivers
like ptn3460 doesn't adhere to the driver model.
In this patch, we reframe the bridge registration framework
so that bridge initialization is split into 2 steps, and
bridge registration happens independent of drm flow:
--Step 1: gather all the bridge settings independent of drm and
add the bridge onto a global list of bridges.
--Step 2: when the encoder driver is probed, call drm_bridge_attach
for the corresponding bridge so that the bridge receives
drm_device pointer and continues with connector and other
drm initializations.
The old set of bridge helpers are removed, and a set of new helpers
are added to accomplish the 2 step initialization.
The bridge devices register themselves onto global list of bridges
when they get probed by calling "drm_bridge_add".
The parent encoder driver waits till the bridge is available
in the lookup table(by calling "of_drm_find_bridge") and then
continues with its initialization.
The encoder driver should also call "drm_bridge_attach" to pass
on the drm_device to the bridge object.
drm_bridge_attach inturn calls "bridge->funcs->attach" so that
bridge can continue with drm related initializations.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Tested-by: Rahul Sharma <rahul.sharma@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Tested-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Assign the pointer to bridge ops structure(drm_bridge_funcs) in
the bridge driver itself, instead of passing it to drm_bridge_init.
This will allow bridge driver developer to pack bridge private
information inside the bridge object and pass only the drm-relevant
information to drm_bridge_init.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Tested-by: Rahul Sharma <rahul.sharma@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Tested-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This patch does the following changes:
-- Use usleep_range instead of udelay.
-- Remove driver_private member from ptn3460 structure.
-- Make all possible functions and structures static.
-- Use dev_err for non-DRM errors.
-- Arrange header files alphabetically.
-- s/edid/EDID in all error messages.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Tested-by: Rahul Sharma <rahul.sharma@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Tested-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Shanghai AVIC Optoelectronics TM070DDH03 is a 7" 1024x600 TFT LCD
panel connecting to a 24-bit RGB LVDS interface.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Shanghai AVIC Optoelectronics Co., Ltd. is a subsidiary of Tianma
Microelectronics Co., Ltd. and designs and manufactures TFT LCDs.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Before shutting down the display using the DCS display_off command, wait
for 4 frames according to the datasheet.
Furthermore, after enabling the power supply, the supply voltage needs
around 10 ms to settle. After that, another 120 ms is required before a
DCS exit_sleep_mode command can be sent.
While at it, no longer send the DCS soft_reset command. This is totally
unnecessary because we've just powered up the display, hence it will be
in a reset state already.
Signed-off-by: Thierry Reding <treding@nvidia.com>
After switching the display on (using the DCS display_on command), wait
for 6 frames (100ms at 60 Hz) to give the display more time to prepare.
Failing to do this results in the panel not initializing properly in a
large number of cases.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This patch adds support for the GiantPlus GPG48273QS5 4.3" WQVGA TFT LCD
panel to the simple-panel driver.
This panel is connected via a parallel bus and uses both HSYNC and
VSYNC, whose lengths are unfortunately not clearly defined. The
datasheet only specifies the front- and backporch length, but the timing
diagram suggests that both sync signals should be asserted for exactly
one clock cycle.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The mipi_dsi_packet_create() function dereferences the msg pointer
before checking that it's valid. Move the dereference down to where it
is required to avoid potentially dereferencing a NULL pointer.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Both playback and capture callbacks are identical, so let's merge
them.
Tested-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The current code deals with the stream start / stop solely via
line6_pcm_acquire() and line6_pcm_release(). This was (supposedly)
intended to avoid the races, but it doesn't work as expected. The
concurrent acquire and release calls can be performed without proper
protections, thus this might result in memory corruption.
Furthermore, we can't take a mutex to protect the whole function
because it can be called from the PCM trigger callback that is an
atomic context. Also spinlock isn't appropriate because the function
allocates with kmalloc with GFP_KERNEL. That is, these function just
lead to singular problems.
This is an attempt to reduce the existing races. First off, separate
both the stream buffer management and the stream URB management. The
former is protected via a newly introduced state_mutex while the
latter is protected via each line6_pcm_stream lock.
Secondly, the stream state are now managed in opened and running bit
flags of each line6_pcm_stream. Not only this a bit clearer than
previous combined bit flags, this also gives a better abstraction.
These rewrites allows us to make common hw_params and hw_free
callbacks for both playback and capture directions.
For the monitor and impulse operations, still line6_pcm_acquire() and
line6_pcm_release() are used. They call internally the corresponding
functions for both playback and capture streams with proper lock or
mutex. Unlike the previous versions, these function don't take the
bit masks but the only single type value. Also they are supposed to
be applied only as duplex operations.
Tested-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Clearing prev_fsize in line6_pcm_acquire() is pretty racy.
This can be called at any time while the stream is being played.
Rather better to clear prev_fbuf and prev_fsize at the proper place
like the stream stop for capture, and just after copying the monitor /
impulse data inside the spinlock.
Tested-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The impulse and monitor handling in submit_audio_out_urb() isn't
protected thus this can be racy with the capture stream handling.
This patch extends the range to protect via each stream's spinlock
(now the whole submit_audio_*_urb() are covered), and take the capture
stream lock additionally for the impulse and monitor handling part.
Tested-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Move the check of multi configurations before snd_card_new() as a
short path, and reduce superfluous pointer references.
Tested-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Instead of allocating the private data individually in each driver's
probe at first, let snd_card_new() allocate the data that is called in
line6_probe(). This simplifies the primary probe functions.
Tested-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The interface argument is used just for retrieving the assigned
device, which can be already found in line6->ifcdev. Drop them from
the callbacks. Also, pass the usb id to private_init so that the
driver can deal with it there. This is a preliminary work for the
further cleanup to move the whole allocation into driver.c.
Tested-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A minor optimization; while pausing, the driver just copies the zero
that doesn't need any volume changes.
Tested-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The PCM stream buffer allocation and free are identical for both
playback and capture streams. Provide single helper functions.
These are used only in pcm.c, thus they can be even static.
Tested-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The codes to unlink and sync URBs are identical for both playback and
capture streams. Consolidate to single helper functions.
Tested-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
