This patch adds IPP subsystem-based gsc driver for exynos5 series.
GSC is stand for General SCaler and supports the following features:
- image scaler/rotator/crop/flip/csc and input/output DMA operations.
- image rotation and image effect functions.
- writeback and display output operations.
- M2M operation to crop, scale, rotation and csc.
The below is GSC hardware path:
Memory------->GSC------>Memory
FIMD--------->GSC------>HDMI
FIMD--------->GSC------>Memory
Memory------->GSC------>FIMD, Mixer
This driver is registered to IPP subsystem framework to be used by user side
and user can control the GSC hardware through some interfaces of IPP subsystem
framework.
Changelog v1 ~ v5:
- added comments, code fixups and cleanups.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Jinyoung Jeon <jy0.jeon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin.park <kyungmin.park@samsung.com>
This patch adds IPP subsystem-based rotator driver.
And Rotator supports the following features.
- Image crop operation support.
- Rotate operation support to 90, 180 or 270 degree.
- Flip operation support to vertical, horizontal or both.
. as limitaions, the pixel format to source buffer should be
same as the one to destination buffer and no scaler.
This driver is registered to IPP subsystem framework to be used by user side
and user can control the Rotator hardware through some interfaces of IPP
subsystem framework.
Changelog v6:
- fix build warning.
Changelog v1 ~ v5:
- added comments, code fixups and cleanups.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Youngjun Cho <yj44.cho@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
FIMC is stand for Fully Interfactive Mobile Camera and
supports image scaler/rotator/crop/flip/csc and input/output DMA operations
and also supports writeback and display output operations.
This driver is registered to IPP subsystem framework to be used by user side
and user can control the FIMC hardware through some interfaces of IPP subsystem
framework.
Changelog v6:
- fix build warning.
Changelog v1 ~ v5:
- add comments, code fixups and cleanups.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Jinyoung Jeon <jy0.jeon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
This patch adds Image Post Processing(IPP) support for exynos drm driver.
IPP supports image scaler/rotator and input/output DMA operations
using IPP subsystem framework to control FIMC, Rotator and GSC hardware
and supports some user interfaces for user side.
And each IPP-based drivers support Memory to Memory operations
with various converting. And in case of FIMC hardware, it also supports
Writeback and Display output operations through local path.
Features:
- Memory to Memory operation support.
- Various pixel formats support.
- Image scaling support.
- Color Space Conversion support.
- Image crop operation support.
- Rotate operation support to 90, 180 or 270 degree.
- Flip operation support to vertical, horizontal or both.
- Writeback operation support to display blended image of FIMD fifo on screen
A summary to IPP Subsystem operations:
First of all, user should get property capabilities from IPP subsystem
and set these properties to hardware registers for desired operations.
The properties could be pixel format, position, rotation degree and
flip operation.
And next, user should set source and destination buffer data using
DRM_EXYNOS_IPP_QUEUE_BUF ioctl command with gem handles to source and
destinition buffers.
And next, user can control user-desired hardware with desired operations
such as play, stop, pause and resume controls.
And finally, user can aware of dma operation completion and also get
destination buffer that it contains user-desried result through dequeue
command.
IOCTL commands:
- DRM_EXYNOS_IPP_GET_PROPERTY
. get ipp driver capabilitis and id.
- DRM_EXYNOS_IPP_SET_PROPERTY
. set format, position, rotation, flip to source and destination buffers
- DRM_EXYNOS_IPP_QUEUE_BUF
. enqueue/dequeue buffer and make event list.
- DRM_EXYNOS_IPP_CMD_CTRL
. play/stop/pause/resume control.
Event:
- DRM_EXYNOS_IPP_EVENT
. a event to notify dma operation completion to user side.
Basic control flow:
Open -> Get properties -> User choose desired IPP sub driver(FIMC, Rotator
or GSCALER) -> Set Property -> Create gem handle -> Enqueue to source and
destination buffers -> Command control(Play) -> Event is notified to User
-> User gets destinition buffer complated -> (Enqueue to source and
destination buffers -> Event is notified to User) * N -> Queue/Dequeue to
source and destination buffers -> Command control(Stop) -> Free gem handle
-> Close
Changelog v1 ~ v5:
- added comments, code fixups and cleanups.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Jinyoung Jeon <jy0.jeon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Changelog v4:
- fix condition to drm_iommu_detach_device funtion.
Changelog v3:
- add dma_parms->max_segment_size setting of drm_device->dev.
- use devm_kzalloc instead of kzalloc.
Changelog v2:
- fix iommu attach condition.
. check archdata.dma_ops of drm device instead of
subdrv device's one.
- code clean to exynos_drm_iommu.c file.
. remove '#ifdef CONFIG_ARM_DMA_USE_IOMMU' from exynos_drm_iommu.c
and add it to driver/gpu/drm/exynos/Kconfig.
Changelog v1:
This patch adds iommu support for exynos drm framework with dma mapping
api. In this patch, we used dma mapping api to allocate physical memory
and maps it with iommu table and removed some existing codes and added
new some codes for iommu support.
GEM allocation requires one device object to use dma mapping api so
this patch uses one iommu mapping for all sub drivers. In other words,
all sub drivers have same iommu mapping.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Changelog v3:
- use __u64 instead of pointer in ioctl struct.
The G2D is a 2D graphic accelerator that supports Bit Block Transfer.
This G2D driver is exynos drm specific and supports only G2D(version
4.1) of later Exynos series from Exynos4X12 because supporting DMA.
The G2D is performed by two tasks simply.
1. Configures the rendering parameters, such as foreground color and
coordinates data by setting the drawing context registers.
2. Start the rendering process by setting thre relevant command
registers accordingly.
The G2D version 4.1 supports DMA mode as host interface. User can make
command list to reduce HOST(ARM) loads. The contents of The command list
is setted to relevant registers of G2D by DMA.
The command list is composed Header and command sets and Tail.
- Header: The number of command set(4Bytes)
- Command set: Register offset(4Bytes) + Register data(4Bytes)
- Tail: Pointer of base address of the other command list(4Bytes)
By Tail field, the G2D can process many command lists without halt at
one go.
The G2D has following the rendering pipeline.
--> Primitive Drawing --> Rotation --> Clipping --> Bilinear Sampling
--> Color Key --> ROP --> Mask Operation --> Alpha Blending -->
Dithering --> FrameBuffer
And supports various operations from the rendering pipeline.
- copy
- fast solid color fill
- window clipping
- rotation
- flip
- 4 operand raster operation(ROP4)
- masking operation
- alpha blending
- color key
- dithering
- etc
User should make the command list to data and registers needed by
operation to use. The Exynos G2D driver only manages the command lists
received from user. Some registers needs memory base address(physical
address) of image. User doesn't know its physical address, so fills the
gem handle of that memory than address to command sets, then G2D driver
converts it to memory base address.
We adds three ioctls and one event for Exynos G2D.
- ioctls
DRM_EXYNOS_G2D_GET_VER: get the G2D hardware version
DRM_EXYNOS_G2D_SET_CMDLIST: set the command list from user to driver
DRM_EXYNOS_G2D_EXEC: execute the command lists setted to driver
- event
DRM_EXYNOS_G2D_EVENT: event to give notification completion of the
command list to user
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
this patch adds exynos specific codes for DRM Prime feature.
with this patch, user application can get file descriptor
from gem handle through DRM_IOCTL_PRIME_HANDLE_TO_FD ioctl
command(export) and also gem handle from file descriptor
through DRM_IOCTL_PRIME_FD_TO_HANLDE(import) ioctl command.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
this driver would be used for wireless display. virtual display
driver has independent crtc, encoder and connector and to use
this driver, user application should send edid data to this driver
from wireless display.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
The exynos drm driver has several subdrv. They each can be module but it
causes unfixed probe order of exynodr drm driver and each subdrv. It
also needs some weird codes such as exynos_drm_fbdev_reinit and
exynos_drm_mode_group_reinit. This patch can remove weird codes and
clear codes through we doesn't modularity each subdrv.
Also this removes unnecessary codes related module.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch is hdmi display support for exynos drm driver.
There is already v4l2 based exynos hdmi driver in drivers/media/video/s5p-tv
and some low level code is already in s5p-tv and even headers for register
define are almost same. but in this patch, we decide not to consider separated
common code with s5p-tv.
Exynos HDMI is composed of 5 blocks, mixer, vp, hdmi, hdmiphy and ddc.
1. mixer. The piece of hardware responsible for mixing and blending multiple
data inputs before passing it to an output device. The mixer is capable of
handling up to three image layers. One is the output of VP. Other two are
images in RGB format. The blending factor, and layers' priority are controlled
by mixer's registers. The output is passed to HDMI.
2. vp (video processor). It is used for processing of NV12/NV21 data. An image
stored in RAM is accessed by DMA. The output in YCbCr444 format is send to
mixer.
3. hdmi. The piece of HW responsible for generation of HDMI packets. It takes
pixel data from mixer and transforms it into data frames. The output is send
to HDMIPHY interface.
4. hdmiphy. Physical interface for HDMI. Its duties are sending HDMI packets to
HDMI connector. Basically, it contains a PLL that produces source clock for
mixer, vp and hdmi.
5. ddc (display data channel). It is dedicated i2c channel to exchange display
information as edid with display monitor.
With plane support, exynos hdmi driver fully supports two mixer layes and vp
layer. Also vp layer supports multi buffer plane pixel formats having non
contigus memory spaces.
In exynos drm driver, common drm_hdmi driver to interface with drm framework
has opertion pointers for mixer and hdmi. this drm_hdmi driver is registered as
sub driver of exynos_drm. hdmi has hdmiphy and ddc i2c clients and controls
them. mixer controls all overlay layers in both mixer and vp.
Vblank interrupts for hdmi are handled by mixer internally because drm
framework cannot support multiple irq id. And pipe number is used to check
which display device irq happens.
History
v2: this version
- drm plane feature support to handle overlay layers.
- multi buffer plane pixel format support for vp layer.
- vp layer support
RFCv1: original
- at https://lkml.org/lkml/2011/11/4/164
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
The exynos fimd supports 5 window overlays. Only one window overlay of
fimd is used by the crtc, so we need plane feature to use the rest
window overlays.
This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it
is the ioctl to decide for user to assign which window overlay.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables
only FIMD yet but we will add HDMI support also in the future.
this patch is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git
branch name: drm-next
commit-id: 88ef4e3f4f
you can refer to our working repository below:
http://git.infradead.org/users/kmpark/linux-2.6-samsung
branch name: samsung-drm
We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
based on Linux framebuffer) but couldn't so because lowlevel codes
of s3c-fb.c are included internally and so FIMD module of this driver has
its own lowlevel codes.
We used GEM framework for buffer management and DMA APIs(dma_alloc_*)
for buffer allocation so we can allocate physically continuous memory
for DMA through it and also we could use CMA later if CMA is applied to
mainline.
Refer to this link for CMA(Continuous Memory Allocator):
http://lkml.org/lkml/2011/7/20/45
this driver supports only physically continuous memory(non-iommu).
Links to previous versions of the patchset:
v1: < https://lwn.net/Articles/454380/ >
v2: < http://www.spinics.net/lists/kernel/msg1224275.html >
v3: < http://www.spinics.net/lists/dri-devel/msg13755.html >
v4: < http://permalink.gmane.org/gmane.comp.video.dri.devel/60439 >
v5: < http://comments.gmane.org/gmane.comp.video.dri.devel/60802 >
Changelog v2:
DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
this feature maps user address space to physical memory region
once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl.
DRM: code clean and add exception codes.
Changelog v3:
DRM: Support multiple irq.
FIMD and HDMI have their own irq handler but DRM Framework can regiter
only one irq handler this patch supports mutiple irq for Samsung SoC.
DRM: Consider modularization.
each DRM, FIMD could be built as a module.
DRM: Have indenpendent crtc object.
crtc isn't specific to SoC Platform so this patch gets a crtc
to be used as common object.
created crtc could be attached to any encoder object.
DRM: code clean and add exception codes.
Changelog v4:
DRM: remove is_defult from samsung_fb.
is_default isn't used for default framebuffer.
DRM: code refactoring to fimd module.
this patch is be considered with multiple display objects and
would use its own request_irq() to register a irq handler instead of
drm framework's one.
DRM: remove find_samsung_drm_gem_object()
DRM: move kernel private data structures and definitions to driver folder.
samsung_drm.h would contain only public information for userspace
ioctl interface.
DRM: code refactoring to gem modules.
buffer module isn't dependent of gem module anymore.
DRM: fixed security issue.
DRM: remove encoder porinter from specific connector.
samsung connector doesn't need to have generic encoder.
DRM: code clean and add exception codes.
Changelog v5:
DRM: updated fimd(display controller) driver.
added various pixel formats, color key and pixel blending features.
DRM: removed end_buf_off from samsung_drm_overlay structure.
this variable isn't used and end buffer address would be
calculated by each sub driver.
DRM: use generic function for mmap_offset.
replaced samsung_drm_gem_create_mmap_offset() and
samsung_drm_free_mmap_offset() with generic ones applied
to mainline recentrly.
DRM: removed unnecessary codes and added exception codes.
DRM: added comments and code clean.
Changelog v6:
DRM: added default config options.
DRM: added padding for 64-bit align.
DRM: changed prefix 'samsung' to 'exynos'
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
