2011-10-04 17:19:01 +07:00
|
|
|
config DRM_EXYNOS
|
|
|
|
tristate "DRM Support for Samsung SoC EXYNOS Series"
|
2016-02-03 19:42:45 +07:00
|
|
|
depends on OF && DRM && (ARCH_S3C64XX || ARCH_EXYNOS || ARCH_MULTIPLATFORM)
|
2011-10-04 17:19:01 +07:00
|
|
|
select DRM_KMS_HELPER
|
2013-08-30 16:10:51 +07:00
|
|
|
select VIDEOMODE_HELPERS
|
2017-10-23 19:49:34 +07:00
|
|
|
select SND_SOC_HDMI_CODEC if SND_SOC
|
2011-10-04 17:19:01 +07:00
|
|
|
help
|
|
|
|
Choose this option if you have a Samsung SoC EXYNOS chipset.
|
|
|
|
If M is selected the module will be called exynosdrm.
|
|
|
|
|
2015-10-26 19:03:43 +07:00
|
|
|
if DRM_EXYNOS
|
|
|
|
|
2012-10-20 21:53:42 +07:00
|
|
|
config DRM_EXYNOS_IOMMU
|
2015-01-20 21:31:14 +07:00
|
|
|
bool
|
2016-06-17 14:54:27 +07:00
|
|
|
depends on EXYNOS_IOMMU
|
2015-01-20 21:31:14 +07:00
|
|
|
default y
|
2012-10-20 21:53:42 +07:00
|
|
|
|
2015-10-26 19:03:44 +07:00
|
|
|
comment "CRTCs"
|
|
|
|
|
2011-10-04 17:19:01 +07:00
|
|
|
config DRM_EXYNOS_FIMD
|
2015-10-26 19:03:45 +07:00
|
|
|
bool "FIMD"
|
2015-10-26 19:03:43 +07:00
|
|
|
depends on !FB_S3C
|
2014-07-17 16:01:21 +07:00
|
|
|
select MFD_SYSCON
|
2011-10-04 17:19:01 +07:00
|
|
|
help
|
|
|
|
Choose this option if you want to use Exynos FIMD for DRM.
|
drm/exynos: added hdmi display support
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>
2011-12-21 15:39:39 +07:00
|
|
|
|
2015-06-12 19:59:00 +07:00
|
|
|
config DRM_EXYNOS5433_DECON
|
2015-10-26 19:03:45 +07:00
|
|
|
bool "DECON on Exynos5433"
|
2015-06-12 19:59:00 +07:00
|
|
|
help
|
|
|
|
Choose this option if you want to use Exynos5433 DECON for DRM.
|
|
|
|
|
2015-02-05 22:54:04 +07:00
|
|
|
config DRM_EXYNOS7_DECON
|
2015-10-26 19:03:45 +07:00
|
|
|
bool "DECON on Exynos7"
|
2015-10-26 19:03:43 +07:00
|
|
|
depends on !FB_S3C
|
2015-02-05 22:54:04 +07:00
|
|
|
help
|
|
|
|
Choose this option if you want to use Exynos DECON for DRM.
|
|
|
|
|
2015-10-26 19:03:44 +07:00
|
|
|
config DRM_EXYNOS_MIXER
|
2015-10-26 19:03:45 +07:00
|
|
|
bool "Mixer"
|
2015-10-26 19:03:44 +07:00
|
|
|
help
|
|
|
|
Choose this option if you want to use Exynos Mixer for DRM.
|
|
|
|
|
|
|
|
config DRM_EXYNOS_VIDI
|
2015-10-26 19:03:45 +07:00
|
|
|
bool "Virtual Display"
|
2015-10-26 19:03:44 +07:00
|
|
|
help
|
|
|
|
Choose this option if you want to use Exynos VIDI for DRM.
|
|
|
|
|
|
|
|
comment "Encoders and Bridges"
|
|
|
|
|
2014-03-17 19:03:56 +07:00
|
|
|
config DRM_EXYNOS_DPI
|
2015-10-26 19:03:45 +07:00
|
|
|
bool "Parallel output"
|
2015-10-26 19:03:44 +07:00
|
|
|
depends on DRM_EXYNOS_FIMD
|
2014-03-17 19:03:56 +07:00
|
|
|
select DRM_PANEL
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
This enables support for Exynos parallel output.
|
|
|
|
|
2014-04-03 23:19:56 +07:00
|
|
|
config DRM_EXYNOS_DSI
|
2015-10-26 19:03:45 +07:00
|
|
|
bool "MIPI-DSI host"
|
2015-10-26 19:03:43 +07:00
|
|
|
depends on DRM_EXYNOS_FIMD || DRM_EXYNOS5433_DECON || DRM_EXYNOS7_DECON
|
2014-04-03 23:19:56 +07:00
|
|
|
select DRM_MIPI_DSI
|
|
|
|
select DRM_PANEL
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
This enables support for Exynos MIPI-DSI device.
|
|
|
|
|
2014-01-31 04:19:22 +07:00
|
|
|
config DRM_EXYNOS_DP
|
2016-03-29 08:57:03 +07:00
|
|
|
bool "EXYNOS specific extensions for Analogix DP driver"
|
2015-10-26 19:03:43 +07:00
|
|
|
depends on DRM_EXYNOS_FIMD || DRM_EXYNOS7_DECON
|
2016-03-29 08:57:03 +07:00
|
|
|
select DRM_ANALOGIX_DP
|
2014-01-31 04:19:22 +07:00
|
|
|
default DRM_EXYNOS
|
2014-08-01 00:42:14 +07:00
|
|
|
select DRM_PANEL
|
2014-01-31 04:19:22 +07:00
|
|
|
help
|
|
|
|
This enables support for DP device.
|
|
|
|
|
drm/exynos: added hdmi display support
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>
2011-12-21 15:39:39 +07:00
|
|
|
config DRM_EXYNOS_HDMI
|
2015-10-26 19:03:45 +07:00
|
|
|
bool "HDMI"
|
2016-08-05 20:38:32 +07:00
|
|
|
depends on DRM_EXYNOS_MIXER || DRM_EXYNOS5433_DECON
|
2017-07-17 18:48:14 +07:00
|
|
|
select CEC_CORE if CEC_NOTIFIER
|
drm/exynos: added hdmi display support
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>
2011-12-21 15:39:39 +07:00
|
|
|
help
|
|
|
|
Choose this option if you want to use Exynos HDMI for DRM.
|
2012-03-21 08:55:26 +07:00
|
|
|
|
2015-10-26 19:03:44 +07:00
|
|
|
config DRM_EXYNOS_MIC
|
2015-10-26 19:03:45 +07:00
|
|
|
bool "Mobile Image Compressor"
|
2015-10-26 19:03:44 +07:00
|
|
|
depends on DRM_EXYNOS5433_DECON
|
2012-03-21 08:55:26 +07:00
|
|
|
help
|
2015-10-26 19:03:44 +07:00
|
|
|
Choose this option if you want to use Exynos MIC for DRM.
|
|
|
|
|
|
|
|
comment "Sub-drivers"
|
2012-05-17 18:06:32 +07:00
|
|
|
|
|
|
|
config DRM_EXYNOS_G2D
|
2015-10-26 19:03:45 +07:00
|
|
|
bool "G2D"
|
2016-03-29 08:28:55 +07:00
|
|
|
depends on VIDEO_SAMSUNG_S5P_G2D=n
|
2015-07-20 15:03:35 +07:00
|
|
|
select FRAME_VECTOR
|
2012-05-17 18:06:32 +07:00
|
|
|
help
|
|
|
|
Choose this option if you want to use Exynos G2D for DRM.
|
drm/exynos: add ipp subsystem
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>
2012-12-14 16:10:31 +07:00
|
|
|
|
2012-12-14 15:58:55 +07:00
|
|
|
config DRM_EXYNOS_FIMC
|
2015-10-26 19:03:45 +07:00
|
|
|
bool "FIMC"
|
drm/exynos: ipp: Remove Exynos DRM IPP subsystem
Exynos DRM IPP subsystem is in fact non-functional and frankly speaking
dead-code. This patch clearly marks that Exynos DRM IPP subsystem is
broken and never really functional. It will be replaced by a completely
rewritten API.
Exynos DRM IPP user-space API can be obsoleted for the following
reasons:
1. Exynos DRM IPP user-space API can be optional in Exynos DRM, so
userspace should not rely that it is always available and should have
a software fallback in case it is not there.
2. The only mode which was initially semi-working was memory-to-memory
image processing. The remaining modes (LCD-"writeback" and "output")
were never operational due to missing code (both in mainline and even
vendor kernels).
3. Exynos DRM IPP mainline user-space API compatibility for
memory-to-memory got broken very early by commit 083500baefd5 ("drm:
remove DRM_FORMAT_NV12MT", which removed the support for tiled formats,
the main feature which made this API somehow useful on Exynos platforms
(video codec that time produced only tiled frames, to implement xvideo
or any other video overlay, one has to de-tile them for proper
display).
4. Broken drivers. Especially once support for IOMMU has been added,
it revealed that drivers don't configure DMA operations properly and in
many cases operate outside the provided buffers trashing memory around.
5. Need for external patches. Although IPP user-space API has been used
in some vendor kernels, but in such cases there were additional patches
applied (like reverting mentioned 083500baefd5 patch) what means that
those userspace apps which might use it, still won't work with the
mainline kernel version.
We don't have time machines, so we cannot change it, but Exynos DRM IPP
extension should never have been merged to mainline in that form.
Exynos IPP subsystem and user-space API will be rewritten, so remove
current IPP core code and mark existing drivers as BROKEN.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-12-14 22:10:15 +07:00
|
|
|
depends on BROKEN && MFD_SYSCON
|
2012-12-14 15:58:55 +07:00
|
|
|
help
|
|
|
|
Choose this option if you want to use Exynos FIMC for DRM.
|
2012-12-14 15:58:56 +07:00
|
|
|
|
|
|
|
config DRM_EXYNOS_ROTATOR
|
2015-10-26 19:03:45 +07:00
|
|
|
bool "Rotator"
|
drm/exynos: ipp: Remove Exynos DRM IPP subsystem
Exynos DRM IPP subsystem is in fact non-functional and frankly speaking
dead-code. This patch clearly marks that Exynos DRM IPP subsystem is
broken and never really functional. It will be replaced by a completely
rewritten API.
Exynos DRM IPP user-space API can be obsoleted for the following
reasons:
1. Exynos DRM IPP user-space API can be optional in Exynos DRM, so
userspace should not rely that it is always available and should have
a software fallback in case it is not there.
2. The only mode which was initially semi-working was memory-to-memory
image processing. The remaining modes (LCD-"writeback" and "output")
were never operational due to missing code (both in mainline and even
vendor kernels).
3. Exynos DRM IPP mainline user-space API compatibility for
memory-to-memory got broken very early by commit 083500baefd5 ("drm:
remove DRM_FORMAT_NV12MT", which removed the support for tiled formats,
the main feature which made this API somehow useful on Exynos platforms
(video codec that time produced only tiled frames, to implement xvideo
or any other video overlay, one has to de-tile them for proper
display).
4. Broken drivers. Especially once support for IOMMU has been added,
it revealed that drivers don't configure DMA operations properly and in
many cases operate outside the provided buffers trashing memory around.
5. Need for external patches. Although IPP user-space API has been used
in some vendor kernels, but in such cases there were additional patches
applied (like reverting mentioned 083500baefd5 patch) what means that
those userspace apps which might use it, still won't work with the
mainline kernel version.
We don't have time machines, so we cannot change it, but Exynos DRM IPP
extension should never have been merged to mainline in that form.
Exynos IPP subsystem and user-space API will be rewritten, so remove
current IPP core code and mark existing drivers as BROKEN.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-12-14 22:10:15 +07:00
|
|
|
depends on BROKEN
|
2012-12-14 15:58:56 +07:00
|
|
|
help
|
|
|
|
Choose this option if you want to use Exynos Rotator for DRM.
|
|
|
|
|
2012-12-14 15:58:57 +07:00
|
|
|
config DRM_EXYNOS_GSC
|
2015-10-26 19:03:45 +07:00
|
|
|
bool "GScaler"
|
drm/exynos: ipp: Remove Exynos DRM IPP subsystem
Exynos DRM IPP subsystem is in fact non-functional and frankly speaking
dead-code. This patch clearly marks that Exynos DRM IPP subsystem is
broken and never really functional. It will be replaced by a completely
rewritten API.
Exynos DRM IPP user-space API can be obsoleted for the following
reasons:
1. Exynos DRM IPP user-space API can be optional in Exynos DRM, so
userspace should not rely that it is always available and should have
a software fallback in case it is not there.
2. The only mode which was initially semi-working was memory-to-memory
image processing. The remaining modes (LCD-"writeback" and "output")
were never operational due to missing code (both in mainline and even
vendor kernels).
3. Exynos DRM IPP mainline user-space API compatibility for
memory-to-memory got broken very early by commit 083500baefd5 ("drm:
remove DRM_FORMAT_NV12MT", which removed the support for tiled formats,
the main feature which made this API somehow useful on Exynos platforms
(video codec that time produced only tiled frames, to implement xvideo
or any other video overlay, one has to de-tile them for proper
display).
4. Broken drivers. Especially once support for IOMMU has been added,
it revealed that drivers don't configure DMA operations properly and in
many cases operate outside the provided buffers trashing memory around.
5. Need for external patches. Although IPP user-space API has been used
in some vendor kernels, but in such cases there were additional patches
applied (like reverting mentioned 083500baefd5 patch) what means that
those userspace apps which might use it, still won't work with the
mainline kernel version.
We don't have time machines, so we cannot change it, but Exynos DRM IPP
extension should never have been merged to mainline in that form.
Exynos IPP subsystem and user-space API will be rewritten, so remove
current IPP core code and mark existing drivers as BROKEN.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-12-14 22:10:15 +07:00
|
|
|
depends on BROKEN && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
|
2012-12-14 15:58:57 +07:00
|
|
|
help
|
|
|
|
Choose this option if you want to use Exynos GSC for DRM.
|
2015-06-12 19:59:02 +07:00
|
|
|
|
2015-10-26 19:03:43 +07:00
|
|
|
endif
|