summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-08-30IB/cm: Expose service ID in request eventsHaggai Eran
Expose the service ID on an incoming CM or SIDR request to the event handler. This will allow the RDMA CM module to de-multiplex connection requests based on the information encoded in the service ID. Acked-by: Sean Hefty <sean.hefty@intel.com> Signed-off-by: Haggai Eran <haggaie@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-08-30IB/ipoib: Return IPoIB devices matching connection parametersGuy Shapiro
Implement the get_net_device_by_port_pkey_ip callback that returns network device to ib_core according to connection parameters. Check the ipoib device and iterate over all child devices to look for a match. For each IPoIB device we iterate through all upper devices when searching for a matching IP, in order to support bonding. Signed-off-by: Guy Shapiro <guysh@mellanox.com> Signed-off-by: Haggai Eran <haggaie@mellanox.com> Signed-off-by: Yotam Kenneth <yotamke@mellanox.com> Signed-off-by: Shachar Raindel <raindel@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-08-30IB/core: Find the network device matching connection parametersYotam Kenneth
In the case of IPoIB, and maybe in other cases, the network device is managed by an upper-layer protocol (ULP). In order to expose this network device to other users of the IB device, let ULPs implement a callback that returns network device according to connection parameters. The IB device and port, together with the P_Key and the GID should be enough to uniquely identify the ULP net device. However, in current kernels there can be multiple IPoIB interfaces created with the same GID. Furthermore, such configuration may be desireable to support ipvlan-like configurations for RDMA CM with IPoIB. To resolve the device in these cases the code will also take the IP address as an additional input. Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Haggai Eran <haggaie@mellanox.com> Signed-off-by: Yotam Kenneth <yotamke@mellanox.com> Signed-off-by: Shachar Raindel <raindel@mellanox.com> Signed-off-by: Guy Shapiro <guysh@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-08-30IB/core: lock client data with lists_rwsemHaggai Eran
An ib_client callback that is called with the lists_rwsem locked only for read is protected from changes to the IB client lists, but not from ib_unregister_device() freeing its client data. This is because ib_unregister_device() will remove the device from the device list with lists_rwsem locked for write, but perform the rest of the cleanup, including the call to remove() without that lock. Mark client data that is undergoing de-registration with a new going_down flag in the client data context. Lock the client data list with lists_rwsem for write in addition to using the spinlock, so that functions calling the callback would be able to lock only lists_rwsem for read and let callbacks sleep. Since ib_unregister_client() now marks the client data context, no need for remove() to search the context again, so pass the client data directly to remove() callbacks. Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Haggai Eran <haggaie@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-08-30IB/core: Add rwsem to allow reading device list or client listHaggai Eran
Currently the RDMA subsystem's device list and client list are protected by a single mutex. This prevents adding user-facing APIs that iterate these lists, since using them may cause a deadlock. The patch attempts to solve this problem by adding a read-write semaphore to protect the lists. Readers now don't need the mutex, and are safe just by read-locking the semaphore. The ib_register_device, ib_register_client, ib_unregister_device, and ib_unregister_client functions are modified to lock the semaphore for write during their respective list modification. Also, in order to make sure client callbacks are called only between add() and remove() calls, the code is changed to only add items to the lists after the add() calls and remove from the lists before the remove() calls. This patch attempts to solve a similar need [1] that was seen in the RoCE v2 patch series. [1] http://www.spinics.net/lists/linux-rdma/msg24733.html Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Cc: Matan Barak <matanb@mellanox.com> Signed-off-by: Haggai Eran <haggaie@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-08-30Linux 4.2v4.2Linus Torvalds
2015-08-31drm/exynos: fix build warning to exynos_drm_gem.cInki Dae
Signed-off-by: Inki Dae <daeinki@gmail.com>
2015-08-31drm/exynos: Properly report supported formats for each deviceMarek Szyprowski
Exynos DRM reported that all planes for all supported sub-devices supports only three pixel formats: XRGB24, ARGB24 and NV12. This patch lets each Exynos DRM sub-drivers to provide the list of supported pixel formats and registers this list to DRM core. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: add render node supportJoonyoung Shim
This patch allows clients who want to use render node to access rendering relevant ioctls - g2d, post processor and gem allocation. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: implement atomic_{begin/flush} of DECONHyungwon Hwang
Each CRTC's atomic_{begin/flush} must stop/start the update of shadow registers to active register in the functions. This patch achieves these purpose by moving the setting of protection bits to those functions from decon_update_plane. v2: rebased to the branch exynos-drm-next Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: remove legacy ->suspend()/resume()Gustavo Padovan
These legacy helpers should only be used by shadow-attaching drivers. KMS drivers has its own way to handle suspend/resume and don't need to use these two helpers. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <daeinki@gmail.com>
2015-08-31drm/exynos: Enable atomic modesetting featureGustavo Padovan
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Now that atomic modesetting is implemented for exynos enable the DRIVER_ATOMIC flag on the driver's features. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: remove wait queue for pending page flipGustavo Padovan
Exynos atomic commit procedures already does this job of waiting for pending updates to finish, that means using pending_flip_queue is pointless now because the disable CRTC procedure will never happen during a page_flip. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: wait all planes updates to finishGustavo Padovan
Add infrastructure to wait for all planes updates to finish by using an atomic_t variable to track how many pending updates we are waiting plus a wait_queue for the wait part. It also changes vblank behaviour and keeps it enabled for all types of updates Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: add atomic asynchronous commitGustavo Padovan
The atomic modesetting interfaces supports async commits that should be implemented by the drivers. If drm core requests an async commit exynos_atomic_commit() will now schedule a work task to run the update later. It also serializes commits that needs to run on the same crtc, putting the following commit to wait until the current one is finished. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: fimd: only finish update if START == START_SGustavo Padovan
fimd_update_plane() programs BUF_START[win] and during the update BUF_START[win] is copied to BUF_START_S[win] (its shadow register) and starts scanning out, then it raises a irq. The fimd_irq_handler, in the case we have a pending_fb, will check the fb value was copied to START_S register and finish the update in case of success. Based on patch from Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: add macro to get the address of START_S regGustavo Padovan
This macro is need to get the value of the START shadow register, that will tell if an framebuffer is currently displayed on the screen or not. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: check for pending fb before finish updateGustavo Padovan
The current code was ignoring the end of update for all overlay planes, caring only for the primary plane update in case of pageflip. This change adds a change to start to check for pending updates for all planes through exynos_plane->pending_fb. At the start of plane update the pending_fb is set with the fb to be shown on the screen. Then only when to fb is already presented in the screen we set pending_fb to NULL to signal that the update was finished. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com> fixup! drm/exynos: check for pending fb before finish update
2015-08-31drm/exynos: fimd: move window protect code to prepare/cleanup_planeGustavo Padovan
Only set/clear the update bit in the CRTC's .atomic_begin()/flush() so all planes are really committed at the same time. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: add prepare and cleanup phases for planesGustavo Padovan
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> .prepare_plane() and .cleanup_plane() allows to perform extra operations before and after the update of planes. For FIMD for example this will be used to enable disable the shadow protection bit. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: fimd: unify call to exynos_drm_crtc_finish_pageflip()Gustavo Padovan
Unify handling of finished plane update to prepare for a following patch that will check for the START and START_S regs to really make sure that the plane was updated. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: don't track enabled state at exynos_crtcGustavo Padovan
struct drm_crtc already stores the enabled state of the crtc thus we don't need to replicate enabled in exynos_drm_crtc. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-30Merge remote-tracking branches 'asoc/topic/wm8996', 'asoc/topic/xtensa' and ↵Mark Brown
'asoc/topic/zx296702' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/wm8741', 'asoc/topic/wm8753', ↵Mark Brown
'asoc/topic/wm8904', 'asoc/topic/wm8960' and 'asoc/topic/wm8983' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/wm0010', 'asoc/topic/wm5100', ↵Mark Brown
'asoc/topic/wm5110', 'asoc/topic/wm8004' and 'asoc/topic/wm8731' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/txx9', 'asoc/topic/uda134x', ↵Mark Brown
'asoc/topic/ux500' and 'asoc/topic/width' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/tas2552', 'asoc/topic/tas5086', ↵Mark Brown
'asoc/topic/tegra', 'asoc/topic/tlv' and 'asoc/topic/topology' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/ssm2518', 'asoc/topic/sta529', ↵Mark Brown
'asoc/topic/sti' and 'asoc/topic/sti-sas' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/rt5677', 'asoc/topic/sh', ↵Mark Brown
'asoc/topic/simple', 'asoc/topic/sirf-codec' and 'asoc/topic/spear' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/rt298', 'asoc/topic/rt5640', ↵Mark Brown
'asoc/topic/rt5651' and 'asoc/topic/rt5670' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/rcar', 'asoc/topic/reg-default', ↵Mark Brown
'asoc/topic/rl6231', 'asoc/topic/rockchip' and 'asoc/topic/rt286' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/pm-ops', 'asoc/topic/pxa' and ↵Mark Brown
'asoc/topic/qcom' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/mediatek', 'asoc/topic/mtk', ↵Mark Brown
'asoc/topic/nuc900', 'asoc/topic/of-name' and 'asoc/topic/omap' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/max98090', 'asoc/topic/max98095', ↵Mark Brown
'asoc/topic/max98357a', 'asoc/topic/max9877' and 'asoc/topic/max98925' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/intel', 'asoc/topic/kirkwood', ↵Mark Brown
'asoc/topic/lm49453', 'asoc/topic/max9768' and 'asoc/topic/max98088' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/fsl-spdif', 'asoc/topic/fsl-ssi', ↵Mark Brown
'asoc/topic/gtm601', 'asoc/topic/ics43432' and 'asoc/topic/ids' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/fsi', 'asoc/topic/fsl', ↵Mark Brown
'asoc/topic/fsl-asrc', 'asoc/topic/fsl-card' and 'asoc/topic/fsl-sai' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/davinci', ↵Mark Brown
'asoc/topic/davinci-vcif', 'asoc/topic/doc' and 'asoc/topic/dpcm' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/cs42l56', 'asoc/topic/cs42l73', ↵Mark Brown
'asoc/topic/cs4349' and 'asoc/topic/da732x' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/const', 'asoc/topic/cs35l32', ↵Mark Brown
'asoc/topic/cs4265' and 'asoc/topic/cs42l52' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/au1x', 'asoc/topic/bcm2835', ↵Mark Brown
'asoc/topic/blackfin' and 'asoc/topic/card' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/88pm860x', 'asoc/topic/ac97', ↵Mark Brown
'asoc/topic/ak4542', 'asoc/topic/arizona' and 'asoc/topic/atmel' into asoc-next
2015-08-30Merge remote-tracking branch 'asoc/topic/ssm4567' into asoc-nextMark Brown
2015-08-30Merge remote-tracking branch 'asoc/topic/rt5645' into asoc-nextMark Brown
2015-08-30Merge remote-tracking branch 'asoc/topic/pcm1681' into asoc-nextMark Brown
2015-08-30Merge remote-tracking branch 'asoc/topic/dapm' into asoc-nextMark Brown
2015-08-30Merge remote-tracking branch 'asoc/topic/core' into asoc-nextMark Brown
2015-08-30Merge remote-tracking branches 'asoc/fix/adav80x', 'asoc/fix/arizona', ↵Mark Brown
'asoc/fix/max98090', 'asoc/fix/rt5640', 'asoc/fix/samsung' and 'asoc/fix/wm8994' into asoc-linus
2015-08-30Merge remote-tracking branch 'asoc/fix/rt5645' into asoc-linusMark Brown
2015-08-30ASoC: zx296702-i2s: Fix resource leak when unload moduleAxel Lin
Use devm_* API to fix leaks in current code. 1. Use devm_kzalloc to fix memory leak for zx_i2s when unload the module. 2. Use devm_snd_soc_register_component to ensure component is unregistered when unload the module. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Jun Nie <jun.nie@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>