With the introduction of output entities, managers will now connect to outputs.
Create helper ops for overlays and managers named get_device. This will abstract
away the information on how to get the device from an overlay or an overlay
manager. The get_device ops currently retrieve the output via a
ovl->manager->device reference. This will be later replaced by
ovl->manager->output->device references.
Signed-off-by: Archit Taneja <archit@ti.com>
Add set_output/unset_output ops for overlay managers, these form links between
managers and outputs. Create a function in dss features which tell all the
output instances that connect to a manager, use it when a manager tries to set
an output. Add a constraint of not unsetting an output when the manager is
enabled.
Keep the omap_dss_device pointer and set/unset_device ops in overlay_manager for
now to not break things. Keep the dss feature function get_supported_displays
as it's used in some places. These will be removed later.
Signed-off-by: Archit Taneja <archit@ti.com>
An output entity represented by the struct omap_dss_output connects to a
omap_dss_device entity. Add functions to set or unset an output's device. This
is similar to how managers and devices were connected previously. An output can
connect to a device without being connected to a manager. However, the output
needs to eventually connect to a manager so that the connected panel can be
enabled.
Keep the omap_overlay_manager pointer in omap_dss_device for now to prevent
breaking things. This will be removed later when outputs are supported
completely.
Signed-off-by: Archit Taneja <archit@ti.com>
The current OMAPDSS design contains 3 software entities: Overlays, Managers and
Devices. These map to pipelines, overlay managers and the panels respectively in
hardware. One or more overlays connect to a manager to represent a composition,
the manager connects to a device(generally a display) to display the content.
The part of DSS hardware which isn't represented by any of the above entities
are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI,
HDMI, VENC and so on. Currently, an overlay manager directly connects to the
display, and the output to which it is actually connected is ignored. The panel
driver of the display is responsible of calling output specific functions to
configure the output.
Adding outputs as a new software entity gives us the following benefits:
- Have exact information on the possible connections between managers and
outputs: A manager can't connect to each and every output, there only limited
hardware links between a manager's video port and some of the outputs.
- Remove hacks related to connecting managers and devices: Currently, default
links between managers and devices are set in a not so clean way. Matching is
done via comparing the device type, and the display types supported by the
manager. This isn't sufficient to establish all the possible links between
managers, outputs and devices in hardware.
- Make panel drivers more generic: The DSS panel drivers currently call
interface/output specific functions to configure the hardware IP. When making
these calls, the driver isn't actually aware of the underlying output. The
output driver extracts information from the panel's omap_dss_device pointer
to figure out which interface it is connected to, and then configures the
corresponding output block. An example of this is when a DSI panel calls
dsi functions, the dsi driver figures out whether the panel is connected
to DSI1 or DSI2. This isn't correct, and having output as entities will
give the panel driver the exact information on which output to configure.
Having outputs also gives the opportunity to make panel drivers generic
across different platforms/SoCs, this is achieved as omap specific output
calls can be replaced by ops of a particular output type.
- Have more complex connections between managers, outputs and devices: OMAPDSS
currently doesn't support use cases like 2 outputs connect to a single
device. This can be achieved by extending properties of outputs to connect to
more managers or devices.
- Represent writeback as an output: The writeback pipeline fits well in OMAPDSS
as compared to overlays, managers or devices.
Add a new struct to represent outputs. An output struct holds pointers to the
manager and device structs to which it is connected. Add functions which can
register/unregister an output, or look for one. Create an enum which represent
each output instance.
Signed-off-by: Archit Taneja <archit@ti.com>
OMAP4's GFX overlay has smaller fifo than the rest of the overlays
(including writeback "overlay"). This seems to be the reason for
underflows in some more demanding scenarios.
We can avoid the problems by using the WB fifo for GFX overlay, and vice
versa. WB usage is not supported yet, but when it will, it should
perform just fine with smaller fifo as there are no hard realtime
constraints with WB.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Currently the way to configure clocks related to DSI (both DSI and DISPC
clocks) happens via omapdss platform data. The reason for this is that
configuring the DSS clocks is a very complex problem, and it's
impossible for the SW to know requirements about things like
interference.
However, for general cases it should be fine to calculate the dividers
for clocks in the SW. The calculated clocks are probably not perfect,
but should work.
This patch adds support to calculate the dividers when using DSI command
mode panels. The panel gives the required DDR clock rate and LP clock
rate, and the DSI driver configures itself and DISPC accordingly.
This patch is somewhat ugly, though. The code does its job by modifying
the platform data where the clock dividers would be if the board file
gave them. This is not how it's going to be in the future, but allows us
to have quite simple patch and keep the backward compatibility.
It also allows the developer to still give the exact dividers from the
board file when there's need for that, as long as the panel driver does
not override them.
There are also other areas for improvement. For example, it would be
better if the panel driver could ask for a DSI clock in a certain range,
as, at least command mode panels, the panel can work fine with many
different clock speeds.
While the patch is not perfect, it allows us to remove the hardcoded
clock dividers from the board file, making it easier to bring up a new
panel and to use device tree from omapdss.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We currently manage HDMI GPIOs in the board files via
platform_enable/disable calls. This won't work with device tree, and in
any case the correct place to manage the GPIOs is in the HDMI driver.
This patch moves the handling of the GPIOs to the HDMI driver. The GPIO
handling is moved to the common hdmi.c file, and this probably needs to
be revisited when adding OMAP5 HDMI support to see if the GPIO handling
needs to be moved to IP specific files.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
The DISPC_IRQ bit definitions pertaining to channel LCD3 as DISPC_IRQ_VSYNC3,
DISPC_IRQ_SYNC_LOST3, DISPC_IRQ_ACBIAS_COUNT_STAT3 AND DISPC_IRQ_FRAMEDONE3
which were incorrectly set in previous LCD3 patches have been corrected here.
Reported-by: Mark Tyler <mark.tyler@ti.com>
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The RFBI driver currently relies on the omap_dss_device struct to receive the
rfbi specific timings requested by the panel driver. This makes the RFBI
interface driver dependent on the omap_dss_device struct.
Make the RFBI driver data maintain it's own rfbi specific timings field. The
panel driver is expected to call omapdss_rfbi_set_interface_timings() to
configure the rfbi timings before the interface is enabled.
Signed-off-by: Archit Taneja <archit@ti.com>
The DSI driver currently relies on the omap_dss_device struct to receive the
video mode timings requested by the panel driver. This makes the DSI interface
driver dependent on the omap_dss_device struct.
Make the DSI driver data maintain it's own video mode timings field. The panel
driver is expected to call omapdss_dsi_set_videomode_timings() to configure the
video mode timings before the interface is enabled.
Signed-off-by: Archit Taneja <archit@ti.com>
The struct omap_dss_dsi_videomode_data holds fields which need to be configured
for DSI to operate in video mode. Rename the struct to dsi_videomode_timings.
One reason to do this is because most of the fields in the struct are timings
related. The other reason is to create a generic op for output specific
timings. This generic op can be considered as a way to set custom or private
timings for the output.
In the case of OMAP, DSI and RFBI require some more timings apart from the
relgular DISPC timings. The structs omap_dss_videomode_timings and rfbi_timings
can be considered as these output specific timings respectively.
Signed-off-by: Archit Taneja <archit@ti.com>
The DSI driver currently relies on the omap_dss_device struct to know the mode
of operation of the DSI protocol(command or video mode). This makes the DSI
interface driver dependent on the omap_dss_device struct.
Make the DSI driver data maintain it's own operation mode field. The panel
driver is expected to call omapdss_dsi_set_operation_mode() before the interface
is enabled.
Signed-off-by: Archit Taneja <archit@ti.com>
The SDI driver currently relies on the omap_dss_device struct to configure the
number of data pairs as specified by the panel. This makes the SDI interface
driver dependent on the omap_dss_device struct.
Make the SDI driver data maintain it's own data lines field. A panel driver
is expected to call omapdss_sdi_set_datapairs() before enabling the interface.
Even though we configure the number of data pairs here, this function would be
finally mapped to a generic interface op called set_data_lines. The datapairs
argument type has been changed from u8 to int at some places to be in sync with
the 'set_data_lines' ops of other interfaces.
Signed-off-by: Archit Taneja <archit@ti.com>
The DPI driver currently relies on the omap_dss_device struct to configure the
number of data lines as specified by the panel. This makes the DPI interface
driver dependent on the omap_dss_device struct.
Make the DPI driver data maintain it's own data lines field. A panel driver
is expected to call omapdss_dpi_set_data_lines() before enabling the interface.
Signed-off-by: Archit Taneja <archit@ti.com>
The RFBI driver currently relies on the omap_dss_device struct to configure the
number of data lines as specified by the panel. This makes the RFBI interface
driver dependent on the omap_dss_device struct.
Make the RFBI driver data maintain it's own data lines field. A panel driver
is expected to call omapdss_rfbi_set_data_lines() to configure the pixel format
before enabling the interface or calling omap_rfbi_configure().
Signed-off-by: Archit Taneja <archit@ti.com>
The RFBI driver currently relies on the omap_dss_device struct to receive the
desired pixel size of the panel. This makes the RFBI interface driver dependent
on the omap_dss_device struct.
Make the RFBI driver data maintain it's own pixel format field. A panel driver
is expected to call omapdss_rfbi_set_pixel_size() to configure the pixel format
before enabling the interface or calling omap_rfbi_configure().
Signed-off-by: Archit Taneja <archit@ti.com>
The DSI driver currently relies on the omap_dss_device struct to receive the
desired pixel format of the panel. This makes the DSI interface driver dependent
on the omap_dss_device struct.
Make the DSI driver data maintain it's own pixel format field. The panel driver
is expected to call omapdss_dsi_set_pixel_format() to configure the pixel format
before the interface is enabled.
Signed-off-by: Archit Taneja <archit@ti.com>
RFBI drivers requires configuration of the update area. Since we don't support
partial updates, the size to be configures is the panel size itself.
Add a timings field in RFBI's driver data. Apart from x_res and y_res, all the
other fields are configured to an initial value when RFBI is enabled. A panel
driver is expected to call omapdss_rfbi_set_size() configure the size of the
panel.
Signed-off-by: Archit Taneja <archit@ti.com>
Partial update suppport was removed from DISPC and DSI sometime back. The RFBI
driver still tries to support partial update without the underlying support in
DISPC.
Remove partial update support from RFBI, only support updates which span acros
the whole panel size. This also helps in DSI and RFBI having similar update
ops.
Signed-off-by: Archit Taneja <archit@ti.com>
Create function omapdss_sdi_set_timings(). Configuring new timings is done the
same way as before, SDI is disabled, and re-enabled with the new timings in
dssdev. This just moves the code from the panel drivers to the SDI driver.
The panel drivers shouldn't be aware of how SDI manages to configure a new set
of timings. This should be taken care of by the SDI driver itself.
Signed-off-by: Archit Taneja <archit@ti.com>
DSI command mode panels don't need to configure a full set of timings to
configure DSI, they only require the width and the height of the panel in
pixels.
Use omapdss_dsi_set_size for command mode panels, omapdss_dsi_set_timings is
meant for video mode panels. When performing rotation via chaning the address
mode of the panel, we would need to swap width and height when doing 90 or 270
rotation. Make sure that omapdss_dsi_set_size() makes the new width and height
visible to DSI.
Signed-off-by: Archit Taneja <archit@ti.com>
The DSI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC and DSI blocks accordingly. This makes the DSI interface
driver dependent on the omap_dss_device struct.
Make the DSI driver data maintain it's own timings field. A DSI video mode panel
driver is expected to call omapdss_dsi_set_timings() to set these timings before
the panel is enabled.
Signed-off-by: Archit Taneja <archit@ti.com>
The DPI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC accordingly. This makes the DPI interface driver dependent
on the omap_dss_device struct.
Make the DPI driver data maintain it's own timings field. The panel driver is
expected to call dpi_set_timings()(renamed to omapdss_dpi_set_timings) to set
these timings before the panel is enabled.
In the set_timings() op, we still ensure that the omap_dss_device timings
(dssdev->panel.timings) are configured. This will later be configured only by
the DPI panel drivers.
Signed-off-by: Archit Taneja <archit@ti.com>
Patch works around the below silicon errata:
During LCDC initialization, there is the potential for a FIFO
underflow condition to occur. A FIFO underflow condition
occurs when the input FIFO is completely empty and the LCDC
raster controller logic that drives data to the output pins
attempts to fetch data from the FIFO. When a FIFO underflow
condition occurs, incorrect data will be driven out on the
LCDC data pins.
Software should poll the FUF bit field in the LCD_STAT register
to check if an error condition has occurred or service the
interrupt if FUF_EN is enabled when FUF occurs. If the FUF bit
field has been set to 1, this will indicate an underflow
condition has occurred and then the software should execute a
reset of the LCDC via the LPSC.
This problem may occur if the LCDC FIFO threshold size
(LCDDMA_CTRL[TH_FIFO_READY]) is left at its default value after
reset. Increasing the FIFO threshold size will reduce or
eliminate underflows. Setting the threshold size to 256 double
words or larger is recommended.
Above issue is described in section 2.1.3 of silicon errata
http://www.ti.com/lit/er/sprz313e/sprz313e.pdf
Signed-off-by: Rajashekhara, Sudhakar <sudhakar.raj@ti.com>
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
The API can be used to allocate and free MERAM blocks directly, without
going through ICBs.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
There's no reason to use abstract operation pointers to implement the
MERAM API. Replace them by direct function calls.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The MERAM operations meram_register, meram_unregister and meram_update
handle LCDC cache. In preparation for "raw" MERAM allocation, rename
them to more appropriate names.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
For DSI operation in videomode, DISPC logic levels for the signals HSYNC, VSYNC
and DE need to be specified to DSI via the fields VP_HSYNC_POL, VP_VSYNC_POL and
VP_DE_POL in DSI_CTRL registers.
This information is completely internal to DSS as logic levels for the above
signals hold no meaning on the DSI bus. Hence a DSI panel driver should be
totally oblivious of these fields.
Fix the logic levels/polarities in the DISPC and DSI registers to a default
value. This is done by overriding these fields in omap_video_timings struct
filled by the panel driver for DISPC, and use the equivalent default values
when programming DSI_CTRL registers. Also, remove the redundant polarity related
fields in omap_dss_dsi_videomode_data.
Signed-off-by: Archit Taneja <archit@ti.com>
Add a parameter called interlace which tells whether the timings are in
interlaced or progressive mode. This aligns the omap_video_timings struct with
the Xorg modeline configuration.
It also removes the hack needed to write to divide the manager height by 2 if
the connected interface is VENC.
Signed-off-by: Archit Taneja <archit@ti.com>
omap_panel_config contains fields which are finally written to DISPC_POL_FREQo
registers. These are now held by omap_video_timings and are set when the manager
timings are applied.
Remove the omap_panel_config enum, and remove all it's references from panel or
interface drivers.
Signed-off-by: Archit Taneja <archit@ti.com>
Some panel timing related fields are contained in omap_panel_config in the form
of flags. The fields are:
- Hsync logic level
- Vsync logic level
- Data driven on rising/falling edge of pixel clock
- Output enable/Data enable logic level
- HSYNC/VSYNC driven on rising/falling edge of pixel clock
Out of these parameters, Hsync and Vsync logic levels are a part of the timings
in the Xorg modeline configuration. So it makes sense to move the to
omap_video_timings. The rest aren't a part of modeline, but it still makes
sense to move these since they are related to panel timings.
These fields stored in omap_panel_config in dssdev are configured for LCD
panels, and the corresponding LCD managers in the DISPC_POL_FREQo registers.
Add the above fields in omap_video_timings. Represent their state via new enums.
Add these parameters to the omap_video_timings instances in the panel drivers.
Keep the corresponding IVS, IHS, IPC, IEO, RF and ONOFF flags in
omap_panel_config for now. The struct will be removed later.
Signed-off-by: Archit Taneja <archit@ti.com>
Remove omap_lcd_display_type enum
The enum omap_lcd_display_type is used to configure the lcd display type in
DISPC. Remove this enum and always set display type to TFT by creating function
dss_mgr_set_lcd_type_tft().
Signed-off-by: Archit Taneja <archit@ti.com>
Remove OMAP_DSS_LCD_TFT as a omap_panel_config flag.
We don't support passive matrix displays any more. Remove this flag from all the
panel drivers.
Force the display_type to OMAP_DSS_LCD_DISPLAY_TFT in the interface drivers.
Signed-off-by: Archit Taneja <archit@ti.com>
The support for LCD3 manager has been added into the manager module. LCD3 panel
has registers as DISPC_CONTROL3 and DISPC_CONFIG3 just like those in LCD and
LCD2 panels. These registers control the Display Controller (DISPC) module for
LCD3 output. The three LCDs support Display Serial Interface (DSI), Remote Frame
Buffer Interface (RFBI) and Parallel CMOS Output Interface (DPI). These LCDs can
be connected through parallel output interface using DISPC and RFBI or DPI. For
serial interface DSS uses DSI.
The LCD3 panel, just like LCD and LCD2 panels, has a clock switch in DSS_CTRL
register which has been enabled. The clock switch chooses between DSS_CLK and
DPLL_DSI1_C_CLK1 as source for LCD3_CLK. New IRQs as DISPC_IRQ_VSYNC3,
DISPC_IRQ_FRAMEDONE3, DISPC_IRQ_ACBIAS_COUNT_STAT3 and DISPC_IRQ_SYNC_LOST3 have
been added specific to the new manager.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OMAP5 Display Subsystem (DSS) architecture comes with a additional LCD3 channel
with its own dedicated overlay manager. The current patch adds LCD3 channel and
basic register support for LCD3 channel. It adds register addresses for various
Display Controller (DISPC) registers like DISPC_DEFAULT_COLOR, DISPC_TIMING_H,
DISPC_DIVISORo, etc.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We have two almost the same enums: omap_channel and
omap_dss_overlay_managers. omap_channel is used almost everywhere, and
omap_channel assigns explicit values to the enum values which are needed
for proper operation.
omap_dss_overlay_managers is only used in one place, so it's easy to
remove it, which is what this patch does.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
It includes:
- driver for AUO-K1900 and AUO-K1901 epaper controller
- large updates for OMAP (e.g. decouple HDMI audio and video)
- some updates for Exynos and SH Mobile
- various other small fixes and cleanups
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
iQIcBAABAgAGBQJPyAhmAAoJECSVL5KnPj1PBcoQAIWftuoXo3sk94f5jKcV4Ucx
MthEc5iEpMVs8xaEruHHNHXWv8ic0x/PfdC2xrpKOEbNXQcNPlb/QE2xWmBRxmT1
ucDyu10HJ36jKcwcK4ra5IQwOW+GtbTBEoBZT+WNAjxHZtJmxzjQGM4C12zVQpdJ
+qV2RP93JmsJoVBL9aKVAg1Ko135LLfD8TcKd+z8TmgFnLfSwKhfl7Jtd2xXwyvz
/hmW3kJUEnD8E5wuj+/g8sKJhQkGalEiITTqG2j2vJyFgxHSqyLSw8BBixrFW1uT
B9VnZsHF35ccCo+96UZRH4QsGJTx08+rea/qsv8IMSGczyRp5ey1ufjL+CzKiiIN
FWfex6fY0HHqZGAopQhjag54e914SIbSxdBwWS/iRrtVt3e9d03BzkhYs4rXl4Ey
CTC5obzWNTbQ6hLEjgWfVKkKcrF56BnRn3zGPgCTKGp2NK3vODdBkt/EmzUFvCWR
CcyQhh+PvZzEWp3XsdOGossYs/0aP4bO+7XPGJxZaa3+WVcRaZwAG/uZvJXXBfnp
DGRFy4wPsTTwKYIx4+t/KrsLtNVKioSMS5GEtuM1YEb8pA7mkUIkqwJv1I261h58
heTr6vWUsviUqHlKALJ+1CdwWGr3CtktCZssGsSUri61nm8CvlSRn2Nr2aJ/L3RN
AkemC/33RE5X/+lfkdMx
=tmIU
-----END PGP SIGNATURE-----
Merge tag 'fbdev-updates-for-3.5' of git://github.com/schandinat/linux-2.6
Pull fbdev updates from Florian Tobias Schandinat:
- driver for AUO-K1900 and AUO-K1901 epaper controller
- large updates for OMAP (e.g. decouple HDMI audio and video)
- some updates for Exynos and SH Mobile
- various other small fixes and cleanups
* tag 'fbdev-updates-for-3.5' of git://github.com/schandinat/linux-2.6: (130 commits)
video: bfin_adv7393fb: Fix cleanup code
video: exynos_dp: reduce delay time when configuring video setting
video: exynos_dp: move sw reset prioir to enabling sw defined function
video: exynos_dp: use devm_ functions
fb: handle NULL pointers in framebuffer release
OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request
OMAPDSS: Apply VENC timings even if panel is disabled
OMAPDSS: VENC/DISPC: Delay dividing Y resolution for managers connected to VENC
OMAPDSS: DISPC: Support rotation through TILER
OMAPDSS: VRFB: remove compiler warnings when CONFIG_BUG=n
OMAPFB: remove compiler warnings when CONFIG_BUG=n
OMAPDSS: remove compiler warnings when CONFIG_BUG=n
OMAPDSS: DISPC: fix usage of dispc_ovl_set_accu_uv
OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays
OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods
OMAPDSS: DISPC: Update Accumulator configuration for chroma plane
drivers/video: fsl-diu-fb: don't initialize the THRESHOLDS registers
video: exynos mipi dsi: support reverse panel type
video: exynos mipi dsi: Properly interpret the interrupt source flags
video: exynos mipi dsi: Avoid races in probe()
...
Lots of normal development commits, but perhaps most notable changes are:
* HDMI rework to properly decouple the HDMI audio part from the HDMI video part.
* Restructure omapdss core driver so that it's possible to implement device
tree support. This included changing how platform data is passed to the
drivers, changing display device registration and improving the panel driver's
ability to configure the underlying video output interface.
* Basic support for DSI packet interleaving
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPu2LWAAoJEPo9qoy8lh71bo0P/2iTw1WLHiRqOwwXSqOQHm2U
EFzA4T36qS29h5g9yA1uHnRo2CO7UVL6kOFShk5vzpiBjwZ0e0nPPUxK919hyYEP
vbrOq4dzdIx4+IYhlFusMKi1OR2JhbmOjE7gx3e1fNby7XxXY2TO2/i98lVKT0bi
wcJN3cTtXcwZOjApxudIf0J4A/0YRzqGIumnkYKwZWqiW5Rv1+dfb5/Ml5fhYvsH
IehLQZs8IHtCbM7qw1yDeVAnBUgsuLPCyep3W/zm1MEscboevifw50sFIRwG5GBQ
cmid+Fi7u3R0/yv/UK2XBGFf7PbeZxWyM5nuZ5raajS/X0mxT1fkGcre1AxNzvgE
3gjfS9m40WKLpod1hsbXZsX1ksCiBddvT5xkgoiyhfa2G2TDGnOEHmKE4sYuq7qF
Zc2YuJMahb+iWrPN966Io4PpgscMEjP732b0tg03MtwgR+liajqiuMzA56PDHaTA
bwwFNS3DVIoEpgeN778PWQJ1mRprlYnK7lyJvpGlrEnDh9tM0Xi/35QDlFl1hvAp
ZKD9oSkK0cIvZB690J6pRoaVv0PfjHspxFDX28FICTQROV2lJ5P9JOwGi+Bk9FwD
eBPchUsivnAuhVthp3YwFod5JyN5ZVSD+9Xe9dXUwstRJo9dJMYLY+E41+N4UUS9
BS2/SKvWqc2NcmIgerO3
=I8Se
-----END PGP SIGNATURE-----
Merge tag 'omapdss-for-3.5' of git://github.com/tomba/linux into fbdev-next
Omapdss driver changes for 3.5 merge window.
Lots of normal development commits, but perhaps most notable changes are:
* HDMI rework to properly decouple the HDMI audio part from the HDMI video part.
* Restructure omapdss core driver so that it's possible to implement device
tree support. This included changing how platform data is passed to the
drivers, changing display device registration and improving the panel driver's
ability to configure the underlying video output interface.
* Basic support for DSI packet interleaving
These cleanups are basically all over the place. The idea is to collect
changes with minimal impact but large number of changes so we can avoid
them from distracting in the diffstat in the other series.
A significant number of lines get removed here, in particular because
the ixp2000 and ixp23xx platforms get removed. These have never been
extremely popular and have fallen into disuse over time with no active
maintainer taking care of them. The u5500 soc never made it into a
product, so we are removing it from the ux500 platform.
Many good cleanups also went into the at91 and omap platforms, as has
been the case for a number of releases.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPuemiAAoJEIwa5zzehBx3L9oQAKiu0bsCiT6BM3VC5VGpluk7
YVLH/fkYGdSUTeGrpjeaoxxZnN5M1CLwErg3DxWcyYidy0zfmqitC8t2KQxZMxuf
bt+hn4flpFnXMNm31B9xBCXOOVAvteZHYS35FdSKGyWo5Kz2WKM8ZrrihkAA7jVi
U75x4+shFPtIhLNg2sJg4e/9D1T14ypElB7W989NzxMtco5fbukVd6vDBHPlFDG3
RVI2z2MbWUj3HVmdoyB+09ekruys0MQsbPOGo8D4aeJicrli/JBtL1r1w6ZZ6I8v
Pe0+CbgemMWS69I37Zuxt35Bejpdofa8nKhT1jBrH4uHYxroKkhhx+VMTtuCcFVw
Q2DhbbHImiW3598c0jkGi7Gk+TalTxkStMQiO3bqYAHApftdqFUgkpFSnOC/Jxgj
Y6nUmd+GVPS+r0dDwZg4z5/AnUQd6t8Azp784muPDDxgTV1ZfdaC0LlLjdWesvMO
x+PQib/U7NdxN5lifV6xCXpPoCQsgshrOkVUQiKVHmzaghm9MXgB8qrzXdTz3dLL
XtR3+1KmSDTfHPSlTq/9vIN4RJtsKUnDWzNViTElEql36KzT7l5mJnBe6CJWirJh
7JNyH0p6XDZfc2q7LgdiSU0dv/j9LzBaYUukQCyUI3Tk+5zKgAdKbYNJpRcfPuoO
BK6OKbjCAoAHL+/nDU2s
=Hcjs
-----END PGP SIGNATURE-----
Merge tag 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull first batch of arm-soc cleanups from Olof Johansson:
"These cleanups are basically all over the place. The idea is to
collect changes with minimal impact but large number of changes so we
can avoid them from distracting in the diffstat in the other series.
A significant number of lines get removed here, in particular because
the ixp2000 and ixp23xx platforms get removed. These have never been
extremely popular and have fallen into disuse over time with no active
maintainer taking care of them. The u5500 soc never made it into a
product, so we are removing it from the ux500 platform.
Many good cleanups also went into the at91 and omap platforms, as has
been the case for a number of releases."
Trivial modify-delete conflicts in arch/arm/mach-{ixp2000,ixp23xx}
* tag 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (152 commits)
ARM: clps711x: Cleanup IRQ handling
ARM clps711x: Removed unused header mach/time.h
ARM: clps711x: Added note about support EP731x CPU to Kconfig
ARM: clps711x: Added missing register definitions
ARM: clps711x: Used own subarch directory for store header file
Dove: Fix Section mismatch warnings
ARM: orion5x: ts78xx debugging changes
ARM: orion5x: remove PM dependency from ts78xx
ARM: orion5x: ts78xx fix NAND resource off by one
ARM: orion5x: ts78xx whitespace cleanups
Orion5x: Fix Section mismatch warnings
Orion5x: Fix warning: struct pci_dev declared inside paramter list
ARM: clps711x: Combine header files into one for clps711x-targets
ARM: S3C24XX: Use common macro to define resources on mach-qt2410.c
ARM: S3C24XX: Use common macro to define resources on mach-osiris.c
ARM: EXYNOS: Adapt to cpuidle core time keeping and irq enable
ARM: S5PV210: Use common macro to define resources on mach-smdkv210.c
ARM: S5PV210: Use common macro to define resources on dev-audio.c
ARM: S5PC100: Use common macro to define resources on dev-audio.c
ARM: S5P64X0: Use common macro to define resources on dev-audio.c
...
TILER is a block in OMAP4's DMM which lets DSS fetch frames in a rotated manner.
Physical memory can be mapped to a portion of OMAP's system address space called
TILER address space. The TILER address space is split into 8 views. Each view
represents a rotated or mirrored form of the mapped physical memory. When a
DISPC overlay's base address is programmed to one of these views, the TILER
fetches the pixels according to the orientation of the view. A view is further
split into 4 containers, each container holds elements of a particular size.
Rotation can be achieved at the granularity of elements in the container. For
more information on TILER, refer to the Memory Subsytem section in OMAP4 TRM.
Rotation type TILER has been added which is used to exploit the capabilities of
these 8 views for performing various rotations.
When fetching from addresses mapped to TILER space, the DISPC DMA can fetch
pixels in either 1D or 2D bursts. The fetch depends on which TILER container we
are accessing. Accessing 8, 16 and 32 bit sized containers requires 2D bursts,
and page mode sized containers require 1D bursts.
The DSS2 user is expected to provide the Tiler address of the view that it is
interested in. This is passed to the paddr and p_uv_addr parameters in
omap_overlay_info. It is also expected to provide the stride value based on the
view's orientation and container type, this should be passed to the screen_width
parameter of omap_overlay_info. In calc_tiler_rotation_offset screen_width is
used to calculate the required row_inc for DISPC. x_predecim and y_predecim are
also used to calculate row_inc and pix_inc thereby adding predecimation support
for TILER.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Latest SuperH HDMI uses not only HDMI Core Register (HTOP0)
but also HDMI Control Register (HTOP1).
This patch adds HDMI Control Register support.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Latest SuperH HDMI allows 32bit access only.
But the data is 8bit. So, we can keep compatibility by switching 8/32 bit access.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
There exist several display technologies and standards that support audio as
well. Hence, it is relevant to update the DSS device driver to provide an audio
interface that may be used by an audio driver or any other driver interested in
the functionality.
The audio_enable function is intended to prepare the relevant
IP for playback (e.g., enabling an audio FIFO, taking in/out of reset
some IP, enabling companion chips, etc). It is intended to be called before
audio_start. The audio_disable function performs the reverse operation and is
intended to be called after audio_stop.
While a given DSS device driver may support audio, it is possible that for
certain configurations audio is not supported (e.g., an HDMI display using a
VESA video timing). The audio_supported function is intended to query whether
the current configuration of the display supports audio.
The audio_config function is intended to configure all the relevant audio
parameters of the display. In order to make the function independent of any
specific DSS device driver, a struct omap_dss_audio is defined. Its purpose
is to contain all the required parameters for audio configuration. At the
moment, such structure contains pointers to IEC-60958 channel status word and
CEA-861 audio infoframe structures. This should be enough to support HDMI and
DisplayPort, as both are based on CEA-861 and IEC-60958. The omap_dss_audio
structure may be extended in the future if required.
The audio_enable/disable, audio_config and audio_supported functions could be
implemented as functions that may sleep. Hence, they should not be called
while holding a spinlock or a readlock.
The audio_start/audio_stop function is intended to effectively start/stop audio
playback after the configuration has taken place. These functions are designed
to be used in an atomic context. Hence, audio_start should return quickly and be
called only after all the needed resources for audio playback (audio FIFOs,
DMA channels, companion chips, etc) have been enabled to begin data transfers.
audio_stop is designed to only stop the audio transfers. The resources used
for playback are released using audio_disable.
A new enum omap_dss_audio_state is introduced to help the implementations of
the interface to keep track of the audio state. The initial state is _DISABLED;
then, the state transitions to _CONFIGURED, and then, when it is ready to
play audio, to _ENABLED. The state _PLAYING is used when the audio is being
rendered.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct omap_display_platform_data. It was used just as a
wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
dss hwmods do not need the platform data. This should also work better
for DT, as we can create omapdss device programmatically in generic omap
boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
that the dss hwmod drivers can call.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Conflicts:
drivers/video/omap2/displays/panel-taal.c
Merge OMAP DSS related board file changes. The branch will also be
merged through linux-omap tree to solve conflicts.
