Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

15 participants
7027 discussions

[PATCH v3 00/16] Add DRM for stih4xx platforms

by Benjamin Gaignard

This series of patches add the support of DRM/KMS drivers for STMicroelectronics chipsets stih416 and stih407. patcheset version 3: - Correctly split code between probe and bind funtions - Squash some commits - remove HQ-VDP device code to have a smaller patcheset, we will introduce it later. patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v3 patcheset version 2: - Use componentized device instead of register sub-devices in master driver probe function - Fix Makefile and Kconfig to only allow built-in compilation patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v2 patcheset version 1: - First path submission Hardware is split in two main blocks: Compositor and TVout. Each of them includes specific hardware IPs and the display timing are controlled by a specific Video Timing Generator hardware IP (VTG). Compositor is made of the follow hardware IPs: - GDP (Generic Display Pipeline) which is an entry point for graphic (RGB) buffers - VDP (Video Diplay Pipeline) which is an entry point for video (YUV) buffers - HQVDP (High Quality Video Display Processor) that supports scaling, deinterlacing and some miscellaneous image quality improvements. It fetches the Video decoded buffers from memory, processes them and pushes them to the Compositor through a HW dedicated bus. - Mixer is responsible of mixing all the entries depending of their respective z-order and layout TVout is divided in 3 parts: - HDMI to generate HDMI signals, depending of chipset version HDMI phy can change. - HDA to generate signals for HD analog TV - VIP to control/switch data path coming from Compositor On stih416 compositor and Tvout are on different dies so a Video Trafic Advance inter-die Communication mechanism (VTAC) is needed. +---------------------------------------------+ +----------------------------------------+ | +-------------------------------+ +----+ | | +----+ +--------------------------+ | | | | | | | | | | | +---------+ +----+ | | | | +----+ +------+ | | | | | | | | | VIP |---->|HDMI| | | | | |GPD +------------->| | | | | | | | | | | | +----+ | | | | +----+ |Mixer |--|-->| | | | | |---|->| switcher| | | | | | | | | | | | | | | | | +----+ | | | | | | | | | | | | | | | |---->|HDA | | | | | +------+ | |VTAC|========>|VTAC| | +---------+ +----+ | | | | | | | | | | | | | | | | Compositor | | | | | | | | TVout | | | +-------------------------------+ | | | | | | +--------------------------+ | | ^ | | | | | | ^ | | | | | | | | | | | | +--------------+ | | | | | | +-------------+ | | | VTG (master) |----->| | | | | |----->| VTG (slave) | | | +--------------+ +----+ | | +----+ +-------------+ | |Digital die | | Analog Die| +---------------------------------------------+ +----------------------------------------+ On stih407 Compositor and Tvout are on the same die +-----------------------------------------------------------------+ | +-------------------------------+ +--------------------------+ | | | | | +---------+ +----+ | | | | +----+ +------+ | | | VIP |---->|HDMI| | | | | |GPD +------------->| | | | | | +----+ | | | | +----+ |Mixer |--|--|->| switcher| | | | | +----+ +-----+ | | | | | | +----+ | | | | |VDP +-->+HQVDP+--->| | | | | |---->|HDA | | | | | +----+ +-----+ +------+ | | +---------+ +----+ | | | | | | | | | | Compositor | | TVout | | | +-------------------------------+ +--------------------------+ | | ^ ^ | | | | | | +--------------+ | | | VTG | | | +--------------+ | |Digital die | +-----------------------------------------------------------------+ In addition of the drivers for the IPs listed before a thin I2C driver (hdmiddc) is used by HDMI driver to retrieve EDID for monitor. To unify interfaces of GDP and VDP we create a "layer" interface called by compositor to control both GPD and VDP. Hardware have memory contraints (alignment, contiguous) so we use CMA drm helpers functions to allocate frame buffer. File naming convention is: - sti_* for IPs drivers - sti_drm_* for drm functions implementation. Benjamin Gaignard (16): drm: sti: add VTG driver drm: sti: add VTAC drivers drm: sti: add HDMI driver drm: sti: add I2C client driver for HDMI drm: sti: add HDA driver drm: sti: add TVOut driver drm: sti: add sti layer interface definition drm: sti: add GDP layer drm: sti: add VID layer drm: sti: add Mixer drm: sti: add Compositor drm: sti: add debug to GDP drm: sti: add debug to VID drm: sti: add debug to TVout drm: sti: add debug to mixer drm: sti: Add DRM driver itself drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/sti/Kconfig | 26 + drivers/gpu/drm/sti/Makefile | 22 + drivers/gpu/drm/sti/sti_compositor.c | 267 +++++++ drivers/gpu/drm/sti/sti_compositor.h | 84 +++ drivers/gpu/drm/sti/sti_ddc.c | 56 ++ drivers/gpu/drm/sti/sti_drm_connector.c | 195 +++++ drivers/gpu/drm/sti/sti_drm_connector.h | 16 + drivers/gpu/drm/sti/sti_drm_crtc.c | 440 ++++++++++++ drivers/gpu/drm/sti/sti_drm_crtc.h | 21 + drivers/gpu/drm/sti/sti_drm_drv.c | 338 +++++++++ drivers/gpu/drm/sti/sti_drm_drv.h | 36 + drivers/gpu/drm/sti/sti_drm_encoder.c | 201 ++++++ drivers/gpu/drm/sti/sti_drm_encoder.h | 16 + drivers/gpu/drm/sti/sti_drm_plane.c | 195 +++++ drivers/gpu/drm/sti/sti_drm_plane.h | 16 + drivers/gpu/drm/sti/sti_gdp.c | 726 +++++++++++++++++++ drivers/gpu/drm/sti/sti_gdp.h | 75 ++ drivers/gpu/drm/sti/sti_hda.c | 852 ++++++++++++++++++++++ drivers/gpu/drm/sti/sti_hda.h | 14 + drivers/gpu/drm/sti/sti_hdmi.c | 1071 ++++++++++++++++++++++++++++ drivers/gpu/drm/sti/sti_hdmi.h | 198 +++++ drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 398 +++++++++++ drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c | 224 ++++++ drivers/gpu/drm/sti/sti_layer.c | 309 ++++++++ drivers/gpu/drm/sti/sti_layer.h | 113 +++ drivers/gpu/drm/sti/sti_mixer.c | 405 +++++++++++ drivers/gpu/drm/sti/sti_mixer.h | 54 ++ drivers/gpu/drm/sti/sti_tvout.c | 904 +++++++++++++++++++++++ drivers/gpu/drm/sti/sti_tvout.h | 105 +++ drivers/gpu/drm/sti/sti_vid.c | 259 +++++++ drivers/gpu/drm/sti/sti_vid.h | 34 + drivers/gpu/drm/sti/sti_vtac_rx.c | 169 +++++ drivers/gpu/drm/sti/sti_vtac_tx.c | 182 +++++ drivers/gpu/drm/sti/sti_vtac_utils.h | 52 ++ drivers/gpu/drm/sti/sti_vtg.c | 468 ++++++++++++ drivers/gpu/drm/sti/sti_vtg.h | 20 + drivers/gpu/drm/sti/sti_vtg_utils.c | 99 +++ drivers/gpu/drm/sti/sti_vtg_utils.h | 29 + 40 files changed, 8692 insertions(+) create mode 100644 drivers/gpu/drm/sti/Kconfig create mode 100644 drivers/gpu/drm/sti/Makefile create mode 100644 drivers/gpu/drm/sti/sti_compositor.c create mode 100644 drivers/gpu/drm/sti/sti_compositor.h create mode 100644 drivers/gpu/drm/sti/sti_ddc.c create mode 100644 drivers/gpu/drm/sti/sti_drm_connector.c create mode 100644 drivers/gpu/drm/sti/sti_drm_connector.h create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.c create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.h create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.c create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.h create mode 100644 drivers/gpu/drm/sti/sti_drm_encoder.c create mode 100644 drivers/gpu/drm/sti/sti_drm_encoder.h create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.c create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.h create mode 100644 drivers/gpu/drm/sti/sti_gdp.c create mode 100644 drivers/gpu/drm/sti/sti_gdp.h create mode 100644 drivers/gpu/drm/sti/sti_hda.c create mode 100644 drivers/gpu/drm/sti/sti_hda.h create mode 100644 drivers/gpu/drm/sti/sti_hdmi.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi.h create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c create mode 100644 drivers/gpu/drm/sti/sti_layer.c create mode 100644 drivers/gpu/drm/sti/sti_layer.h create mode 100644 drivers/gpu/drm/sti/sti_mixer.c create mode 100644 drivers/gpu/drm/sti/sti_mixer.h create mode 100644 drivers/gpu/drm/sti/sti_tvout.c create mode 100644 drivers/gpu/drm/sti/sti_tvout.h create mode 100644 drivers/gpu/drm/sti/sti_vid.c create mode 100644 drivers/gpu/drm/sti/sti_vid.h create mode 100644 drivers/gpu/drm/sti/sti_vtac_rx.c create mode 100644 drivers/gpu/drm/sti/sti_vtac_tx.c create mode 100644 drivers/gpu/drm/sti/sti_vtac_utils.h create mode 100644 drivers/gpu/drm/sti/sti_vtg.c create mode 100644 drivers/gpu/drm/sti/sti_vtg.h create mode 100644 drivers/gpu/drm/sti/sti_vtg_utils.c create mode 100644 drivers/gpu/drm/sti/sti_vtg_utils.h -- 1.9.1

12 years, 2 months

[PATCH 0/2] Updates to fence api

by Maarten Lankhorst

The following series implements small updates to the fence api. I've found them useful when implementing the fence API in ttm and i915. The last patch enables RCU on top of the api. I've found this less useful, but it was the condition on which Thomas Hellstrom was ok with converting TTM to fence, so I had to keep it in. If nobody objects I'll probably merge that patch through drm, because some care is needed in ttm before it can flip the switch on rcu. --- Maarten Lankhorst (2): reservation: update api and add some helpers [RFC] reservation: add suppport for read-only access using rcu

12 years, 2 months

[PATCH 0/6] dma-buf synchronization patches (updated)

by Maarten Lankhorst

The following series implements fence and converts dma-buf and android sync to use it. Patch 5 and 6 add support for polling to dma-buf, blocking until all fences are signaled. Patches that received some minor updates: - seqno fence (wait condition member added) - android (whitespace changes and a comment removed) - add poll support to dma-buf (added comment) --- Maarten Lankhorst (6): fence: dma-buf cross-device synchronization (v17) seqno-fence: Hardware dma-buf implementation of fencing (v5) dma-buf: use reservation objects android: convert sync to fence api, v5 reservation: add support for fences to enable cross-device synchronisation dma-buf: add poll support, v3 Documentation/DocBook/device-drivers.tmpl | 3 drivers/base/Kconfig | 9 drivers/base/Makefile | 2 drivers/base/dma-buf.c | 130 +++ drivers/base/fence.c | 467 ++++++++++++ drivers/gpu/drm/drm_prime.c | 8 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 drivers/gpu/drm/nouveau/nouveau_drm.c | 1 drivers/gpu/drm/nouveau/nouveau_gem.h | 1 drivers/gpu/drm/nouveau/nouveau_prime.c | 7 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 drivers/gpu/drm/radeon/radeon_drv.c | 2 drivers/gpu/drm/radeon/radeon_prime.c | 8 drivers/gpu/drm/ttm/ttm_object.c | 2 drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 drivers/staging/android/Kconfig | 1 drivers/staging/android/Makefile | 2 drivers/staging/android/ion/ion.c | 2 drivers/staging/android/sw_sync.c | 4 drivers/staging/android/sync.c | 903 ++++++++---------------- drivers/staging/android/sync.h | 82 +- drivers/staging/android/sync_debug.c | 247 +++++++ drivers/staging/android/trace/sync.h | 12 include/drm/drmP.h | 2 include/linux/dma-buf.h | 21 - include/linux/fence.h | 329 +++++++++ include/linux/reservation.h | 20 + include/linux/seqno-fence.h | 119 +++ include/trace/events/fence.h | 125 +++ 30 files changed, 1863 insertions(+), 654 deletions(-) create mode 100644 drivers/base/fence.c create mode 100644 drivers/staging/android/sync_debug.c create mode 100644 include/linux/fence.h create mode 100644 include/linux/seqno-fence.h create mode 100644 include/trace/events/fence.h -- Signature

12 years, 2 months

Re: [Linaro-mm-sig] [PATCH v6 05/11] drivers: of: add automated assignment of reserved regions to client devices

by Grant Likely

On Wed, 14 May 2014 10:15:38 +0100, "Jon Medhurst (Tixy)" <tixy(a)linaro.org> wrote: > On Sun, 2014-03-02 at 13:40 +0800, Grant Likely wrote: > > On Fri, 28 Feb 2014 14:42:50 +0100, Marek Szyprowski <m.szyprowski(a)samsung.com> wrote: > > > This patch adds code for automated assignment of reserved memory regions > > > to struct device. reserved_mem->ops->device_init()/device_cleanup() > > > callbacks are called to perform reserved memory driver specific > > > initialization and cleanup > > > > > > Based on previous code provided by Josh Cartwright <joshc(a)codeaurora.org> > > > > > > Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> > > > > Hi Marek, > > > > I've not applied this one yet, only because there is still the open > > issue of whether or not these functions should be called from drivers or > > from core code. I don't actually have any problems with the content of > > this patch. Once the user is sorted out I'll merge it. > > Has anything more come of these patches? I see some of the series is now > in Linux 3.15, but the actual patches to let people use the feature > aren't there yet, namely patches 5 though 8. > > My personal immediate interest in these is as a mechanism on arm64 to > limit CMA to a region of memory that is actually DMA-able devices (e.g. > below 4GB for 32-bit devices without an iommu). > > For reference, the mail archives for this series is at > http://lkml.org/lkml/2014/2/28/237 IIRC, the issue I have with patch 5-8 is that I don't like the driver core going off and doing automagical things to attach regions to devices. I've not seen any more discussion on this topic since I merged the patches I was okay with, but I may have missed something. g.

12 years, 2 months

[PATCH v2 00/19] Add DRM for stih4xx platforms

by Benjamin Gaignard

This series of patches add the support of DRM/KMS drivers for STMicroelectronics chipsets stih416 and stih407. patcheset version 2: - Use componentized device instead of register sub-devices in master driver probe function - Fix Makefile and Kconfig to only allow built-in compilation patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v2 patcheset version 1: - First path submission Hardware is split in two main blocks: Compositor and TVout. Each of them includes specific hardware IPs and the display timing are controlled by a specific Video Timing Generator hardware IP (VTG). Compositor is made of the follow hardware IPs: - GDP (Generic Display Pipeline) which is an entry point for graphic (RGB) buffers - VDP (Video Diplay Pipeline) which is an entry point for video (YUV) buffers - HQVDP (High Quality Video Display Processor) that supports scaling, deinterlacing and some miscellaneous image quality improvements. It fetches the Video decoded buffers from memory, processes them and pushes them to the Compositor through a HW dedicated bus. - Mixer is responsible of mixing all the entries depending of their respective z-order and layout TVout is divided in 3 parts: - HDMI to generate HDMI signals, depending of chipset version HDMI phy can change. - HDA to generate signals for HD analog TV - VIP to control/switch data path coming from Compositor On stih416 compositor and Tvout are on different dies so a Video Trafic Advance inter-die Communication mechanism (VTAC) is needed. +---------------------------------------------+ +----------------------------------------+ | +-------------------------------+ +----+ | | +----+ +--------------------------+ | | | | | | | | | | | +---------+ +----+ | | | | +----+ +------+ | | | | | | | | | VIP |---->|HDMI| | | | | |GPD +------------->| | | | | | | | | | | | +----+ | | | | +----+ |Mixer |--|-->| | | | | |---|->| switcher| | | | | | | | | | | | | | | | | +----+ | | | | | | | | | | | | | | | |---->|HDA | | | | | +------+ | |VTAC|========>|VTAC| | +---------+ +----+ | | | | | | | | | | | | | | | | Compositor | | | | | | | | TVout | | | +-------------------------------+ | | | | | | +--------------------------+ | | ^ | | | | | | ^ | | | | | | | | | | | | +--------------+ | | | | | | +-------------+ | | | VTG (master) |----->| | | | | |----->| VTG (slave) | | | +--------------+ +----+ | | +----+ +-------------+ | |Digital die | | Analog Die| +---------------------------------------------+ +----------------------------------------+ On stih407 Compositor and Tvout are on the same die +-----------------------------------------------------------------+ | +-------------------------------+ +--------------------------+ | | | | | +---------+ +----+ | | | | +----+ +------+ | | | VIP |---->|HDMI| | | | | |GPD +------------->| | | | | | +----+ | | | | +----+ |Mixer |--|--|->| switcher| | | | | +----+ +-----+ | | | | | | +----+ | | | | |VDP +-->+HQVDP+--->| | | | | |---->|HDA | | | | | +----+ +-----+ +------+ | | +---------+ +----+ | | | | | | | | | | Compositor | | TVout | | | +-------------------------------+ +--------------------------+ | | ^ ^ | | | | | | +--------------+ | | | VTG | | | +--------------+ | |Digital die | +-----------------------------------------------------------------+ In addition of the drivers for the IPs listed before a thin I2C driver (hdmiddc) is used by HDMI driver to retrieve EDID for monitor. To unify interfaces of GDP and VDP we create a "layer" interface called by compositor to control both GPD and VDP. Hardware have memory contraints (alignment, contiguous) so we use CMA drm helpers functions to allocate frame buffer. File naming convention is: - sti_* for IPs drivers - sti_drm_* for drm functions implementation. Benjamin Gaignard (18): drm: sti: add bindings for DRM driver drm: sti: add VTG driver drm: sti: add VTAC drivers drm: sti: add HDMI driver drm: sti: add I2C client driver for HDMI drm: sti: add HDA driver drm: sti: add TVOut driver drm: sti: add sti layer interface definition drm: sti: add GDP layer drm: sti: add VID layer drm: sti: add Mixer drm: sti: add Compositor drm: sti: add debug to GDP drm: sti: add debug to VID drm: sti: add debug to TVout drm: sti: add debug to mixer drm: sti: Add DRM driver itself drm: sti: add HQVDP driver Vincent Abriou (1): drm: sti: rename mixer registers to be main/aux independent .../devicetree/bindings/gpu/st,stih4xx.txt | 187 ++++ drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/sti/Kconfig | 26 + drivers/gpu/drm/sti/Makefile | 23 + drivers/gpu/drm/sti/sti_compositor.c | 222 ++++ drivers/gpu/drm/sti/sti_compositor.h | 84 ++ drivers/gpu/drm/sti/sti_ddc.c | 56 + drivers/gpu/drm/sti/sti_drm_connector.c | 195 ++++ drivers/gpu/drm/sti/sti_drm_connector.h | 16 + drivers/gpu/drm/sti/sti_drm_crtc.c | 440 ++++++++ drivers/gpu/drm/sti/sti_drm_crtc.h | 21 + drivers/gpu/drm/sti/sti_drm_drv.c | 447 ++++++++ drivers/gpu/drm/sti/sti_drm_drv.h | 39 + drivers/gpu/drm/sti/sti_drm_encoder.c | 201 ++++ drivers/gpu/drm/sti/sti_drm_encoder.h | 16 + drivers/gpu/drm/sti/sti_drm_plane.c | 195 ++++ drivers/gpu/drm/sti/sti_drm_plane.h | 16 + drivers/gpu/drm/sti/sti_gdp.c | 726 +++++++++++++ drivers/gpu/drm/sti/sti_gdp.h | 75 ++ drivers/gpu/drm/sti/sti_hda.c | 853 +++++++++++++++ drivers/gpu/drm/sti/sti_hda.h | 14 + drivers/gpu/drm/sti/sti_hdmi.c | 1072 +++++++++++++++++++ drivers/gpu/drm/sti/sti_hdmi.h | 198 ++++ drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 398 +++++++ drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c | 224 ++++ drivers/gpu/drm/sti/sti_hqvdp.c | 1107 ++++++++++++++++++++ drivers/gpu/drm/sti/sti_hqvdp.h | 55 + drivers/gpu/drm/sti/sti_hqvdp_lut.h | 373 +++++++ drivers/gpu/drm/sti/sti_layer.c | 324 ++++++ drivers/gpu/drm/sti/sti_layer.h | 116 ++ drivers/gpu/drm/sti/sti_mixer.c | 405 +++++++ drivers/gpu/drm/sti/sti_mixer.h | 54 + drivers/gpu/drm/sti/sti_tvout.c | 884 ++++++++++++++++ drivers/gpu/drm/sti/sti_tvout.h | 105 ++ drivers/gpu/drm/sti/sti_vid.c | 259 +++++ drivers/gpu/drm/sti/sti_vid.h | 34 + drivers/gpu/drm/sti/sti_vtac_rx.c | 167 +++ drivers/gpu/drm/sti/sti_vtac_tx.c | 182 ++++ drivers/gpu/drm/sti/sti_vtac_utils.h | 52 + drivers/gpu/drm/sti/sti_vtg.c | 467 +++++++++ drivers/gpu/drm/sti/sti_vtg.h | 20 + drivers/gpu/drm/sti/sti_vtg_utils.c | 99 ++ drivers/gpu/drm/sti/sti_vtg_utils.h | 29 + 44 files changed, 10479 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpu/st,stih4xx.txt create mode 100644 drivers/gpu/drm/sti/Kconfig create mode 100644 drivers/gpu/drm/sti/Makefile create mode 100644 drivers/gpu/drm/sti/sti_compositor.c create mode 100644 drivers/gpu/drm/sti/sti_compositor.h create mode 100644 drivers/gpu/drm/sti/sti_ddc.c create mode 100644 drivers/gpu/drm/sti/sti_drm_connector.c create mode 100644 drivers/gpu/drm/sti/sti_drm_connector.h create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.c create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.h create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.c create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.h create mode 100644 drivers/gpu/drm/sti/sti_drm_encoder.c create mode 100644 drivers/gpu/drm/sti/sti_drm_encoder.h create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.c create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.h create mode 100644 drivers/gpu/drm/sti/sti_gdp.c create mode 100644 drivers/gpu/drm/sti/sti_gdp.h create mode 100644 drivers/gpu/drm/sti/sti_hda.c create mode 100644 drivers/gpu/drm/sti/sti_hda.h create mode 100644 drivers/gpu/drm/sti/sti_hdmi.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi.h create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c create mode 100644 drivers/gpu/drm/sti/sti_hqvdp.c create mode 100644 drivers/gpu/drm/sti/sti_hqvdp.h create mode 100644 drivers/gpu/drm/sti/sti_hqvdp_lut.h create mode 100644 drivers/gpu/drm/sti/sti_layer.c create mode 100644 drivers/gpu/drm/sti/sti_layer.h create mode 100644 drivers/gpu/drm/sti/sti_mixer.c create mode 100644 drivers/gpu/drm/sti/sti_mixer.h create mode 100644 drivers/gpu/drm/sti/sti_tvout.c create mode 100644 drivers/gpu/drm/sti/sti_tvout.h create mode 100644 drivers/gpu/drm/sti/sti_vid.c create mode 100644 drivers/gpu/drm/sti/sti_vid.h create mode 100644 drivers/gpu/drm/sti/sti_vtac_rx.c create mode 100644 drivers/gpu/drm/sti/sti_vtac_tx.c create mode 100644 drivers/gpu/drm/sti/sti_vtac_utils.h create mode 100644 drivers/gpu/drm/sti/sti_vtg.c create mode 100644 drivers/gpu/drm/sti/sti_vtg.h create mode 100644 drivers/gpu/drm/sti/sti_vtg_utils.c create mode 100644 drivers/gpu/drm/sti/sti_vtg_utils.h -- 1.9.1

12 years, 3 months

Re: [Linaro-mm-sig] Questions regarding DMA buffer sharing using IOMMU

by Laura Abbott

On 5/12/2014 7:37 AM, Pintu Kumar wrote: > Hi, > Thanks for the reply. > > ---------------------------------------- >> From: arnd(a)arndb.de >> To: linux-arm-kernel(a)lists.infradead.org >> CC: pintu.k(a)outlook.com; linux-mm(a)kvack.org; linux-kernel(a)vger.kernel.org; linaro-mm-sig(a)lists.linaro.org >> Subject: Re: Questions regarding DMA buffer sharing using IOMMU >> Date: Mon, 12 May 2014 14:00:57 +0200 >> >> On Monday 12 May 2014 15:12:41 Pintu Kumar wrote: >>> Hi, >>> I have some queries regarding IOMMU and CMA buffer sharing. >>> We have an embedded linux device (kernel 3.10, RAM: 256Mb) in >>> which camera and codec supports IOMMU but the display does not support IOMMU. >>> Thus for camera capture we are using iommu buffers using >>> ION/DMABUF. But for all display rendering we are using CMA buffers. >>> So, the question is how to achieve buffer sharing (zero-copy) >>> between Camera and Display using only IOMMU? >>> Currently we are achieving zero-copy using CMA. And we are >>> exploring options to use IOMMU. >>> Now we wanted to know which option is better? To use IOMMU or CMA? >>> If anybody have come across these design please share your thoughts and results. >> >> There is a slight performance overhead in using the IOMMU in general, >> because the IOMMU has to fetch the page table entries from memory >> at least some of the time. > > Ok, we need to check performance later > >> >> If that overhead is within the constraints you have for transfers between >> camera and codec, you are always better off using IOMMU since that >> means you don't have to do memory migration. > > Transfer between camera is codec is fine. But our major concern is single buffer > sharing between camera & display. Here camera supports iommu but display does not support iommu. > Is it possible to render camera preview (iommu buffers) on display (not iommu and required physical contiguous overlay memory)? > I'm pretty sure the answer is no for zero copy IOMMU buffers if one of your devices does not support IOMMU. If the data is coming in as individual pages and the hardware does not support scattered pages there isn't much you can do except copy to a contiguous buffer. At least with Ion, the heap types can be set up in a particular way such that the client need never know about the existence of an IOMMU or not. > Also is it possible to buffer sharing between 2 iommu supported devices? > I don't see why not but there isn't a lot of information to go on here. Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

12 years, 3 months

Re: [Linaro-mm-sig] Questions regarding DMA buffer sharing using IOMMU

by Arnd Bergmann

On Monday 12 May 2014 15:12:41 Pintu Kumar wrote: > Hi, > I have some queries regarding IOMMU and CMA buffer sharing. > We have an embedded linux device (kernel 3.10, RAM: 256Mb) in > which camera and codec supports IOMMU but the display does not support IOMMU. > Thus for camera capture we are using iommu buffers using > ION/DMABUF. But for all display rendering we are using CMA buffers. > So, the question is how to achieve buffer sharing (zero-copy) > between Camera and Display using only IOMMU? > Currently we are achieving zero-copy using CMA. And we are > exploring options to use IOMMU. > Now we wanted to know which option is better? To use IOMMU or CMA? > If anybody have come across these design please share your thoughts and results. There is a slight performance overhead in using the IOMMU in general, because the IOMMU has to fetch the page table entries from memory at least some of the time. If that overhead is within the constraints you have for transfers between camera and codec, you are always better off using IOMMU since that means you don't have to do memory migration. Note however, that we don't have a way to describe IOMMU relations to devices in DT, so whatever you come up with to do this will most likely be incompatible with what we do in future kernel versions. Arnd

12 years, 3 months

[PATCH] cma: increase CMA_ALIGNMENT upper limit to 12

by Marc Carino

Certain platforms contain peripherals which have contiguous memory alignment requirements, necessitating the use of the alignment argument when obtaining CMA memory. The current default maximum CMA_ALIGNMENT of order 9 translates into a 1MB alignment on systems with a 4K page size. To accommodate systems with peripherals with even larger alignment requirements, increase the upper-bound of CMA_ALIGNMENT from order 9 to order 12. Marc Carino (1): cma: increase CMA_ALIGNMENT upper limit to 12 drivers/base/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.9.1

12 years, 3 months

[PATCH v1 00/19] Add DRM for stih4xx platforms

by Benjamin Gaignard

This series of patches add the support of DRM/KMS drivers for STMicroelectronics chipsets stih416 and stih407. Hardware is split in two main blocks: Compositor and TVout. Each of them includes specific hardware IPs and the display timing are controlled by a specific Video Timing Generator hardware IP (VTG). Compositor is made of the follow hardware IPs: - GDP (Generic Display Pipeline) which is an entry point for graphic (RGB) buffers - VDP (Video Diplay Pipeline) which is an entry point for video (YUV) buffers - HQVDP (High Quality Video Display Processor) that supports scaling, deinterlacing and some miscellaneous image quality improvements. It fetches the Video decoded buffers from memory, processes them and pushes them to the Compositor through a HW dedicated bus. - Mixer is responsible of mixing all the entries depending of their respective z-order and layout TVout is divided in 3 parts: - HDMI to generate HDMI signals, depending of chipset version HDMI phy can change. - HDA to generate signals for HD analog TV - VIP to control/switch data path coming from Compositor On stih416 compositor and Tvout are on different dies so a Video Trafic Advance inter-die Communication mechanism (VTAC) is needed. +---------------------------------------------+ +----------------------------------------+ | +-------------------------------+ +----+ | | +----+ +--------------------------+ | | | | | | | | | | | +---------+ +----+ | | | | +----+ +------+ | | | | | | | | | VIP |---->|HDMI| | | | | |GPD +------------->| | | | | | | | | | | | +----+ | | | | +----+ |Mixer |--|-->| | | | | |---|->| switcher| | | | | | | | | | | | | | | | | +----+ | | | | | | | | | | | | | | | |---->|HDA | | | | | +------+ | |VTAC|========>|VTAC| | +---------+ +----+ | | | | | | | | | | | | | | | | Compositor | | | | | | | | TVout | | | +-------------------------------+ | | | | | | +--------------------------+ | | ^ | | | | | | ^ | | | | | | | | | | | | +--------------+ | | | | | | +-------------+ | | | VTG (master) |----->| | | | | |----->| VTG (slave) | | | +--------------+ +----+ | | +----+ +-------------+ | |Digital die | | Analog Die| +---------------------------------------------+ +----------------------------------------+ On stih407 Compositor and Tvout are on the same die +-----------------------------------------------------------------+ | +-------------------------------+ +--------------------------+ | | | | | +---------+ +----+ | | | | +----+ +------+ | | | VIP |---->|HDMI| | | | | |GPD +------------->| | | | | | +----+ | | | | +----+ |Mixer |--|--|->| switcher| | | | | +----+ +-----+ | | | | | | +----+ | | | | |VDP +-->+HQVDP+--->| | | | | |---->|HDA | | | | | +----+ +-----+ +------+ | | +---------+ +----+ | | | | | | | | | | Compositor | | TVout | | | +-------------------------------+ +--------------------------+ | | ^ ^ | | | | | | +--------------+ | | | VTG | | | +--------------+ | |Digital die | +-----------------------------------------------------------------+ In addition of the drivers for the IPs listed before a thin I2C driver (hdmiddc) is used by HDMI driver to retrieve EDID for monitor. To unify interfaces of GDP and VDP we create a "layer" interface called by compositor to control both GPD and VDP. Hardware have memory contraints (alignment, contiguous) so we use CMA drm helpers functions to allocate frame buffer. File naming convention is: - sti_* for IPs drivers - sti_drm_* for drm functions implementation. Benjamin Gaignard (18): drm: sti: add bindings for DRM driver drm: sti: add VTG driver drm: sti: add VTAC drivers drm: sti: add HDMI driver drm: sti: add I2C client driver for HDMI drm: sti: add HDA driver drm: sti: add TVOut driver drm: sti: add sti layer interface definition drm: sti: add GDP layer drm: sti: add VID layer drm: sti: add Mixer drm: sti: add Compositor drm: sti: add debug to GDP drm: sti: add debug to VID drm: sti: add debug to TVout drm: sti: add debug to mixer drm: sti: Add DRM driver itself drm: sti: add HQVDP driver Vincent Abriou (1): drm: sti: rename mixer registers to be main/aux independent .../devicetree/bindings/gpu/st,stih4xx.txt | 177 ++++ drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/sti/Kconfig | 26 + drivers/gpu/drm/sti/Makefile | 23 + drivers/gpu/drm/sti/sti_compositor.c | 189 ++++ drivers/gpu/drm/sti/sti_compositor.h | 84 ++ drivers/gpu/drm/sti/sti_ddc.c | 56 + drivers/gpu/drm/sti/sti_drm_connector.c | 195 ++++ drivers/gpu/drm/sti/sti_drm_connector.h | 16 + drivers/gpu/drm/sti/sti_drm_crtc.c | 440 ++++++++ drivers/gpu/drm/sti/sti_drm_crtc.h | 21 + drivers/gpu/drm/sti/sti_drm_drv.c | 484 +++++++++ drivers/gpu/drm/sti/sti_drm_drv.h | 48 + drivers/gpu/drm/sti/sti_drm_encoder.c | 201 ++++ drivers/gpu/drm/sti/sti_drm_encoder.h | 16 + drivers/gpu/drm/sti/sti_drm_plane.c | 195 ++++ drivers/gpu/drm/sti/sti_drm_plane.h | 16 + drivers/gpu/drm/sti/sti_gdp.c | 726 +++++++++++++ drivers/gpu/drm/sti/sti_gdp.h | 75 ++ drivers/gpu/drm/sti/sti_hda.c | 826 +++++++++++++++ drivers/gpu/drm/sti/sti_hda.h | 14 + drivers/gpu/drm/sti/sti_hdmi.c | 1045 +++++++++++++++++++ drivers/gpu/drm/sti/sti_hdmi.h | 198 ++++ drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 398 +++++++ drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c | 224 ++++ drivers/gpu/drm/sti/sti_hqvdp.c | 1089 ++++++++++++++++++++ drivers/gpu/drm/sti/sti_hqvdp.h | 55 + drivers/gpu/drm/sti/sti_hqvdp_lut.h | 373 +++++++ drivers/gpu/drm/sti/sti_layer.c | 324 ++++++ drivers/gpu/drm/sti/sti_layer.h | 116 +++ drivers/gpu/drm/sti/sti_mixer.c | 405 ++++++++ drivers/gpu/drm/sti/sti_mixer.h | 54 + drivers/gpu/drm/sti/sti_tvout.c | 863 ++++++++++++++++ drivers/gpu/drm/sti/sti_tvout.h | 105 ++ drivers/gpu/drm/sti/sti_vid.c | 259 +++++ drivers/gpu/drm/sti/sti_vid.h | 34 + drivers/gpu/drm/sti/sti_vtac_rx.c | 140 +++ drivers/gpu/drm/sti/sti_vtac_tx.c | 152 +++ drivers/gpu/drm/sti/sti_vtac_utils.h | 52 + drivers/gpu/drm/sti/sti_vtg.c | 438 ++++++++ drivers/gpu/drm/sti/sti_vtg.h | 20 + drivers/gpu/drm/sti/sti_vtg_utils.c | 99 ++ drivers/gpu/drm/sti/sti_vtg_utils.h | 29 + 44 files changed, 10303 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpu/st,stih4xx.txt create mode 100644 drivers/gpu/drm/sti/Kconfig create mode 100644 drivers/gpu/drm/sti/Makefile create mode 100644 drivers/gpu/drm/sti/sti_compositor.c create mode 100644 drivers/gpu/drm/sti/sti_compositor.h create mode 100644 drivers/gpu/drm/sti/sti_ddc.c create mode 100644 drivers/gpu/drm/sti/sti_drm_connector.c create mode 100644 drivers/gpu/drm/sti/sti_drm_connector.h create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.c create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.h create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.c create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.h create mode 100644 drivers/gpu/drm/sti/sti_drm_encoder.c create mode 100644 drivers/gpu/drm/sti/sti_drm_encoder.h create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.c create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.h create mode 100644 drivers/gpu/drm/sti/sti_gdp.c create mode 100644 drivers/gpu/drm/sti/sti_gdp.h create mode 100644 drivers/gpu/drm/sti/sti_hda.c create mode 100644 drivers/gpu/drm/sti/sti_hda.h create mode 100644 drivers/gpu/drm/sti/sti_hdmi.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi.h create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c create mode 100644 drivers/gpu/drm/sti/sti_hqvdp.c create mode 100644 drivers/gpu/drm/sti/sti_hqvdp.h create mode 100644 drivers/gpu/drm/sti/sti_hqvdp_lut.h create mode 100644 drivers/gpu/drm/sti/sti_layer.c create mode 100644 drivers/gpu/drm/sti/sti_layer.h create mode 100644 drivers/gpu/drm/sti/sti_mixer.c create mode 100644 drivers/gpu/drm/sti/sti_mixer.h create mode 100644 drivers/gpu/drm/sti/sti_tvout.c create mode 100644 drivers/gpu/drm/sti/sti_tvout.h create mode 100644 drivers/gpu/drm/sti/sti_vid.c create mode 100644 drivers/gpu/drm/sti/sti_vid.h create mode 100644 drivers/gpu/drm/sti/sti_vtac_rx.c create mode 100644 drivers/gpu/drm/sti/sti_vtac_tx.c create mode 100644 drivers/gpu/drm/sti/sti_vtac_utils.h create mode 100644 drivers/gpu/drm/sti/sti_vtg.c create mode 100644 drivers/gpu/drm/sti/sti_vtg.h create mode 100644 drivers/gpu/drm/sti/sti_vtg_utils.c create mode 100644 drivers/gpu/drm/sti/sti_vtg_utils.h -- 1.9.0

12 years, 3 months

mem-hotplug: Can arm receive memory-hotplug feature from x86 platform

by xiaofeng.yan

Hi all, I found some scenario could need memory-hotplug feature in their product based on platform ARM. A typical scenario can be described as follows: Developer reserve some memory which can't be accessed by kernel and other function can use these memory before system start up. After booting, system can reclaim the memory reserved with memory-hot plug mechanism. for example , user can add the reserved memory by the next command. #echo "PHYSICAL_ADDRESS_OF_MEMORY, SIZE_FOR_ADDING_MEMORY" > /kernel/sys/addmemory/addmemory. PHYSICAL_ADDRESS_OF_MEMORY: the begging position for adding memory SIZE_FOR_ADDING_MEMORY: the memory size you want to add. the unit should be integral multiple of a section size. So my question is whether arm support memory-hot plug or not in next plan. I am very interested to move the feature from x86 to arm. I have finish the above function and realize dynamic memory addition. I can push my patches if possible. Give me your suggestion. Thanks xiaofeng.yan

12 years, 3 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig