2019-05-19 12:07:45 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2015-12-09 17:27:48 +00:00
|
|
|
menu "OMAPFB Panel and Encoder Drivers"
|
2019-04-01 15:46:57 +00:00
|
|
|
depends on FB_OMAP2_DSS
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
|
2015-12-09 17:27:48 +00:00
|
|
|
config FB_OMAP2_ENCODER_OPA362
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
tristate "OPA362 external analog amplifier"
|
|
|
|
|
help
|
|
|
|
|
Driver for OPA362 external analog TV amplifier controlled
|
|
|
|
|
through a GPIO.
|
|
|
|
|
|
2015-12-09 17:27:48 +00:00
|
|
|
config FB_OMAP2_ENCODER_TFP410
|
2019-04-01 15:46:57 +00:00
|
|
|
tristate "TFP410 DPI to DVI Encoder"
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
help
|
|
|
|
|
Driver for TFP410 DPI to DVI encoder.
|
|
|
|
|
|
2015-12-09 17:27:48 +00:00
|
|
|
config FB_OMAP2_ENCODER_TPD12S015
|
2019-04-01 15:46:57 +00:00
|
|
|
tristate "TPD12S015 HDMI ESD protection and level shifter"
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
help
|
|
|
|
|
Driver for TPD12S015, which offers HDMI ESD protection and level
|
|
|
|
|
shifting.
|
|
|
|
|
|
2015-12-09 17:27:48 +00:00
|
|
|
config FB_OMAP2_CONNECTOR_DVI
|
2019-04-01 15:46:57 +00:00
|
|
|
tristate "DVI Connector"
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
depends on I2C
|
|
|
|
|
help
|
|
|
|
|
Driver for a generic DVI connector.
|
|
|
|
|
|
2015-12-09 17:27:48 +00:00
|
|
|
config FB_OMAP2_CONNECTOR_HDMI
|
2019-04-01 15:46:57 +00:00
|
|
|
tristate "HDMI Connector"
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
help
|
|
|
|
|
Driver for a generic HDMI connector.
|
|
|
|
|
|
2015-12-09 17:27:48 +00:00
|
|
|
config FB_OMAP2_CONNECTOR_ANALOG_TV
|
2019-04-01 15:46:57 +00:00
|
|
|
tristate "Analog TV Connector"
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
help
|
|
|
|
|
Driver for a generic analog TV connector.
|
|
|
|
|
|
2015-12-09 17:27:48 +00:00
|
|
|
config FB_OMAP2_PANEL_DPI
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
tristate "Generic DPI panel"
|
|
|
|
|
help
|
|
|
|
|
Driver for generic DPI panels.
|
|
|
|
|
|
2015-12-09 17:27:48 +00:00
|
|
|
config FB_OMAP2_PANEL_DSI_CM
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
tristate "Generic DSI Command Mode Panel"
|
|
|
|
|
depends on BACKLIGHT_CLASS_DEVICE
|
|
|
|
|
help
|
|
|
|
|
Driver for generic DSI command mode panels.
|
|
|
|
|
|
2015-12-09 17:27:48 +00:00
|
|
|
config FB_OMAP2_PANEL_SONY_ACX565AKM
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
tristate "ACX565AKM Panel"
|
|
|
|
|
depends on SPI && BACKLIGHT_CLASS_DEVICE
|
2019-08-16 12:22:27 +00:00
|
|
|
depends on DRM_PANEL_SONY_ACX565AKM = n
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
help
|
|
|
|
|
This is the LCD panel used on Nokia N900
|
|
|
|
|
|
2015-12-09 17:27:48 +00:00
|
|
|
config FB_OMAP2_PANEL_LGPHILIPS_LB035Q02
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
tristate "LG.Philips LB035Q02 LCD Panel"
|
|
|
|
|
depends on SPI
|
|
|
|
|
help
|
|
|
|
|
LCD Panel used on the Gumstix Overo Palo35
|
|
|
|
|
|
2015-12-09 17:27:48 +00:00
|
|
|
config FB_OMAP2_PANEL_SHARP_LS037V7DW01
|
2019-04-01 15:46:57 +00:00
|
|
|
tristate "Sharp LS037V7DW01 LCD Panel"
|
|
|
|
|
depends on BACKLIGHT_CLASS_DEVICE
|
2019-08-16 12:22:27 +00:00
|
|
|
depends on DRM_PANEL_SHARP_LS037V7DW01 = n
|
2019-04-01 15:46:57 +00:00
|
|
|
help
|
|
|
|
|
LCD Panel used in TI's SDP3430 and EVM boards
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
|
2015-12-09 17:27:48 +00:00
|
|
|
config FB_OMAP2_PANEL_TPO_TD028TTEC1
|
2019-04-01 15:46:57 +00:00
|
|
|
tristate "TPO TD028TTEC1 LCD Panel"
|
|
|
|
|
depends on SPI
|
2019-08-16 12:22:27 +00:00
|
|
|
depends on DRM_PANEL_TPO_TD028TTEC1 = n
|
2019-04-01 15:46:57 +00:00
|
|
|
help
|
|
|
|
|
LCD panel used in Openmoko.
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
|
2015-12-09 17:27:48 +00:00
|
|
|
config FB_OMAP2_PANEL_TPO_TD043MTEA1
|
2019-04-01 15:46:57 +00:00
|
|
|
tristate "TPO TD043MTEA1 LCD Panel"
|
|
|
|
|
depends on SPI
|
2019-08-16 12:22:27 +00:00
|
|
|
depends on DRM_PANEL_TPO_TD043MTEA1 = n
|
2019-04-01 15:46:57 +00:00
|
|
|
help
|
|
|
|
|
LCD Panel used in OMAP3 Pandora
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
|
2015-12-09 17:27:48 +00:00
|
|
|
config FB_OMAP2_PANEL_NEC_NL8048HL11
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
tristate "NEC NL8048HL11 Panel"
|
|
|
|
|
depends on SPI
|
|
|
|
|
depends on BACKLIGHT_CLASS_DEVICE
|
2019-08-16 12:22:27 +00:00
|
|
|
depends on DRM_PANEL_NEC_NL8048HL11 = n
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
help
|
2019-04-01 15:46:57 +00:00
|
|
|
This NEC NL8048HL11 panel is TFT LCD used in the
|
|
|
|
|
Zoom2/3/3630 sdp boards.
|
omapfb: copy omapdss & displays for omapfb
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
2015-12-09 16:28:28 +00:00
|
|
|
|
|
|
|
|
endmenu
|
