dispc_wb_setup() handles configuration only for mem-to-mem case. This
patch adds the necessary configuration to handle also display capture
mode.
We need to set CAPTUREMODE to 0 (continuous capture), and WBDELAYCOUNT
according to the vertical timings of the display, so that the WB FIFO
has time to flush before the next frame starts.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The color conversion coefficients for RGB to YUV conversion (used with
writeback) don't result in the correct result. This patch sets the
correct coefficients.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
When doing mem-to-mem writeback, there's no pixelclock. However, the
code that calculates scaling factors check that there is a pixel clock.
We can just skip the check when doing mem-to-mem writeback.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Mflag thresholds for all pipelines are set in dispc_init_mflag(), but we
are missing that for WB pipeline. Add WB configuration.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Fifo thresholds for all pipelines are set in dispc_init_fifos(), but we
are missing it for WB pipeline. Add that.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Burst size for all pipelines is set in dispc_configure_burst_sizes(),
but we are missing WB pipe. So add that.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add handling of OMAP_DSS_CHANNEL_WB to dispc_ovl_set_channel_out() and
dispc_ovl_get_channel_out().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Refactor dispc_ovl_get_channel_out() to a bit cleaner form, which makes
it easier to add support for writeback in the following patch.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
At the moment we have a function to get the number of writeback
pipelines supported. However, the function is used in a wrong way,
causing a wrong pipeline to get configured when trying to use WB. Also,
we only have a single writeback pipeline on any of the DSS versions.
To fix and simplify this, create a 'has_writeback' flag into the dispc
driver, and after checking the flag, use OMAP_DSS_WB pipeline
explicitly when calling the configuration functions.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OMAP5+ DSS has a writeback pipeline, but this was not specified in the
features list for OMAP5 DSS.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
By default DISPC asserts hsync and vsync sequentially, i.e. there's
first hsync and that is immediately followed by vsync. This is the only
available behaviour on OMAP2/3, and default behaviour on OMAP4+.
OMAP4+ has ALIGN bit in POL_FREQ register, which makes DISPC assert both
syncs at the same time.
It has been observed that some panels don't like sequential syncs (AM5
EVM's panel). After studying the datasheets for multiple panels and
encoders, and MIPI DPI spec, it looks like there is no standard way to
handle this.
Sometimes the datasheets don't mention the required syncs behaviour at
all, sometimes the datasheets have images that hint towards simultaneous
syncs, and sometimes it is explicitly mentioned that simultaneous syncs
are needed. No panels or encoders requiring sequential sync was found.
It thus seems to be safe to default to simultaneous syncs when the ALIGN
bit is available. This fixed AM5 EVM's panel, and no side effects have
been observed on other panels or encoders.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Update omapdss driver to set the state of the pins to:
- "default on resume
- "sleep" on suspend
By optionally putting the pins into sleep state in the suspend callback
we can accomplish two things.
- minimize current leakage from pins and thus save power,
- prevent the IP from driving pins output in an uncontrolled manner,
which may happen if the power domain drops the domain regulator.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
An spi_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Drivers needs to export the OF id table and this be built into
the module or udev won't have the necessary information to autoload
the driver module when the device is registered via OF.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
This change is needed to properly lock I2C bus driver, which serves DDC.
Prior to this change i2c_put_adapter() is misused, which may lead to
an overflow over zero of I2C bus driver user counter.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reconfigure and restart audio when display is enabled, if audio
playback was active before. This is needed in a situation when an
audio+video stream application opens the audio stream before the
video. When video stream is opened the display mode may change and
that aborts audio playback, because the display is momentarily
turned off.
The audio configuration is stored when it is successfully applied and
a boolean is set when the audio playback is started and unset when
stopped. This data is used to reconfigure the audio when display is
re-enabled. The audio playback is aborted if the reconfiguration fails.
A new spin lock is introduced in order to protect state variables
related to audio playback status. This is needed for the transition
from display enabled state (when audio start/stop commands can be
written to HW) to display disabled state (when audio start/stop
commands update only the hdmi.audio_playing variable) to always
serialize correctly with the start/stop audio commands. The already
existing mutex can not be used, because the audio start and stop
commands are executed in atomic context.
For example: when display is turned back on we take the spinlock and
we can be sure that the audio start/stop status will not change while
we update the HW according to hdmi.audio_playing state and set
hdmi.display_enabled to true. After releasing the lock
hdmi.display_enabled is true and all audio_start and audio_stop
commands write their stuff directly to HW.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
With two exceptions (drm/qxl and drm/radeon) all vm_operations_struct
structs should be constant.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Fix omap_dss_find_output_by_port_node() port parameter refcount
decrementation. The only user of dss_of_port_get_parent_device()
function is omap_dss_find_output_by_port_node() and it assumes the
refcount of the port parameter is not decremented by the call.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
After the commit 736e60ddc2 ("OMAPDSS:
componentize omapdss") the dss core device will wait until all the
subdevices have been successfully probed. However, we don't have a
working driver for RFBI, so if RFBI device exists, omapdss will never
get probed.
All the .dtsi files set RFBI as disabled, except am4372.dtsi. This
causes omapdss probe to not finish on AM4 devices.
This patch makes omapdss driver skip adding rfbi device as a
subcomponent, solving the issue.
This should be reverted when we have a working RFBI driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Felipe Balbi <balbi@ti.com>
At the moment when HDMI video output is stopped, we just clear the
enable bit and return. While it's unclear if this can cause any issues,
I think it's still better to wait for FRAMEDONE interrupt after clearing
the enable bit so that we're sure the HDMI IP has finished.
As we don't have any ready-made irq handling for HDMI, and this only
needs to be done when disabling the HDMI output, this patch implements a
simple loop with sleep, polling the FRAMEDONE bit.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Error handling in hdmi_power_on_full() is not correct, and could leave
resources unfreed.
Fix this by arranging the error labels correctly.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The current driver does both x and y decimation on OMAP3 DSS. Testing
shows that x decimation rarely works, leading to underflows.
The exact reason for this is unclear, as the underflows seem to happen
even with low pixel clock rates, and I would presume that if the DSS can
manage a display with 140MHz pixel clock, it could manage x decimation
with factor 2 with a low pixel clock (~30MHz).
So it is possible that there is a problem somewhere else, in memory
management, or DSS DMA, or similar. I have not found anything that would
help this.
So, to fix the downscaling scaling, this patch removes x decimation for
OMAP3. This will limit some of the more demanding downscaling scenarios,
but one could argue that using DSS to downscale such a large amount is
insane in the first place, as the produced image is rather bad quality.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The DISPC's scaling code seems to presume that decimation always
succeeds, and so we always do find a suitable downscaling setup.
However, this is not the case, and the algorithm can fail.
When that happens, the code just proceeds with wrong results, causing
issues later.
Add the necessary checks to bail out if the scaling algorithm failed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The DISPC driver uses 64 bit arithmetic to calculate the required clock
rate for scaling. The code does not seem to work correctly, and instead
calculates with 32 bit numbers, giving wrong result.
Fix the code by typecasting values to u64 first, so that the
calculations do happen in 64 bits.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
pixel_inc and row_inc work differently on OMAP2/3 and OMAP4+ DSS. On
OMAP2/3 DSS, the pixel_inc is _not_ added by the HW at the end of the
line, after the last pixel, whereas on OMAP4+ it is.
The driver currently works for OMAP4+, but does not handle OMAP2/3
correctly, which leads to tilted image when row_inc is used.
This patch adds a flag to DISPC driver so that the pixel_inc is added
when required.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
On OMAP3/AM43xx some scaling factors cause underflows/synclosts. After
studying this, I found that sometimes the driver uses three-tap scaling
with downscaling factor smaller than x0.5. This causes issues, as x0.5
is the limit for three-tap scaling.
The driver has FEAT_PARAM_DOWNSCALE parameter, but that seems to be for
five-tap scaling, which allows scaling down to x0.25.
This patch adds checks for both horizontal and vertical scaling. For
horizontal the HW always uses 5 taps, so the limit is x0.25.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
After calculating the required decimation for scaling, the dispc driver
checks once more if the resulting configuration is valid by calling
check_horiz_timing_omap3().
Earlier calls to this function have correctly used in_width and
in_height as parameters, but the last call uses width and height. This
causes the driver to possibly reject scaling that would work.
This patch fixes the parameters.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
DISPC needs even input buffer width for YUV modes. The DISPC driver
doesn't check this at the moment (although omapdrm does), but worse,
when DISPC driver does x predecimation the result may be uneven. This
causes sometimes sync losts, underflows, or just visual errors.
This patch makes DISPC driver return an error if the user gives uneven
input width for a YUV buffer. It also makes the input width even in case
of predecimation.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Errata i631 description:
"When in YUV4:2:0 format in 1D burst, the DISPC DMA skips lines when
fetching Chroma sampling."
Workaround:
"If YUV4:2:0-1D burst is required: Set
DISPC_VIDp_ATTRIBUTES[22]DOUBLESTRIDE to 0x0 and
DISPC_VIDp_ATTRIBUTES[13:12]ROTATION to 0x1 or 0x3"
The description is somewhat confusing, but testing has shown that DSS
fetches extra rows from memory when using NV12 format in 1D mode. If the
memory after the framebuffer is inaccessible, this leads to OCP errors.
The driver always uses DOUBLESTRIDE=0 when using 1D mode, so we only
need to handle the ROTATION part.
The issue exist on all OMAP4 and OMAP5 based DSS IPs.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Now that we are using components in omapdss, there's no need for
separate handling of dss and dispc driver init. Thus we can move the dss
and dispc init and unit func pointers to the lists we use for the other
dss submodules.
We can now also handle errors returned by the registration functions
properly: if registering a driver fails, we can stop processing and
return the error.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
omapdss kernel module contains drivers for multiple devices, one for
each DSS submodule. The probing we have at the moment is a mess, and
doesn't give us proper deferred probing nor ensure that all the devices
are probed before omapfb/omapdrm start using omapdss.
This patch solves the mess by using the component system for DSS
submodules.
The changes to all DSS submodules (dispc, dpi, dsi, hdmi4/5, rfbi, sdi,
venc) are the same: probe & remove functions are changed to bind &
unbind, and new probe & remove functions are added which call
component_add/del.
The dss_core driver (dss.c) acts as a component master. Adding and
matching the components is simple: all dss device's child devices are
added as components.
However, we do have some dependencies between the drivers. The order in
which they should be probed is reflected by the list in core.c
(dss_output_drv_reg_funcs). The drivers are registered in that order,
which causes the components to be added in that order, which makes the
components to be bound in that order. This feels a bit fragile, and we
probably should improve the code to manage binds in random order.
However, for now, this works fine.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
We have a list of function pointers to dss submodule uninit functions.
It makes sense to do the uninit in the reverse order to init, but that
is not currently the case.
This patch reorders the uninit calls to be the reverse of init order.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The following patches will add component handling to omapdss, improving
the handling of deferred probing. However, at the moment we're using
quite a lot of __inits and __exits in the driver, which prevent normal
dynamic probing and removal.
This patch removes most of the uses of __init and __exit, so that we can
register drivers after module init, and so that we can unregister
drivers even if the module is built-in.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The return value of dss_init_ports() is not handled at all, causing
crashes later if the call failed.
This patch adds the error handling, and we also move the call to a
slightly earlier place to make bailing out easier.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Refactor dss probe function by extracting the setup for video plls into
a separate function. The call to this function is also moved to a
slightly earlier phase, so that in error case we can bail out more
easily.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
We have a flag, 'dss_initialized', which tells omapfb and omapdrm if
omapdss is available. At the moment it can be set even if the dss
submodules are not all ready, in case something gets deferred.
Move the flag to dss_core driver so that it'll signal the availability
of the dss drivers move accurately.
For now, it'll signal that dss_core is ready, which is not quite correct
but still better than previously. The following patches will add
component system to omapdss, and after those patches 'dss_initialized'
will signal that all the submodules are ready.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Since kobject_init_and_add takes a format string, make sure that the
passed in name cannot be accidentally parsed.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
There is a constraint in the OMAP4 HDMI IP that requires to use
the 8-channel code when transmitting more than two channels.
The constraint doesn't apply for OMAP5 so don't force the channel
allocation in the sound driver as it can be done specifically for
OMAP4 later in the hdmi4 core.
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Mark Brown <broonie@kernel.org>
Downmix inhibit in HDMI_CORE_FC_AUDICONF3 register is in
bit 4 while CEA861_AUDIO_INFOFRAME_DB5_DM_INH sets bit 7.
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
As per TRM, HDMI_WP_AUDIO_CFG[2] LEFT_BEFORE = 0 is reserved,
so it must always be set to 1 (the first sample is the left).
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OMAP4 HDMI IP uses the 8-channel layout with 8-channel speaker
allocation mask when transmitting more than two channels. But
the channel count field (CC) of the Audio InfoFrame's DB1 is
not updated for 8-channels.
As per HDMI Compliance Test 7.31 "Audio InfoFrame", CC = 7 is
required for 8-channels CA masks (0x13 and 0x1F).
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Since 39b2bbe3d7 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Also make use of gpiod_get*_optional where applicable.
Apart from simplification of the affected drivers this is another step
towards making the flags argument to gpiod_get*() mandatory.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add handling of missed events in omap_dss_pm_notif which are
needed to support hibernation (suspend to disk).
Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We don't need VT switch when suspending/resuming, so disable it. This
speeds up suspend/resume.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: NeilBrown <neil@brown.name>
This series converts of_graph_get_next_endpoint to decrement the refcount of
the passed prev parameter. This allows to add a for_each_endpoint_of_node
helper macro to loop over all endpoints in a device tree node.
The of_graph_get_port_by_id function is added to retrieve a port by its known
port id (contained in the reg property) from the device tree.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJU9Vn9AAoJEFDCiBxwnmDriPMP/2Bzx7kYdRkTFICqGsITHcUf
pjMEf7htHdg+lFn6jBYtLW42NqZMX+kI1BIpd6RzEjKxAhbp0tr7FVwn0Kds2rQw
6ikwtZsd6oBR61Xv0sZWMwNbfn2MUcl7M9k+Sh6kDUBph5IEMZ5F+n8dRYHhA+MH
rs9PGTH2DmRE1HXvWBjsE8QVgfia4WRp5OipDkOxNhCpkbzU4XqbVoBh/6BmJ54R
Dxq3srM479CyRY3o4+KT4ajhS7g4aU7WTQMxIXtU0cLcYMvfkcHoYwNBw+bjSn3s
eYfjpw96XHhS4abVzo8QziN1oNV/i/Y4wpqIOKwY5TnA+Gt+sEnFXjGHa331QdpL
WdisAQg/6MFPlR4D7gkBWEjoeeMn4FkyiFSHntYclywOxv/Cbc/l1cOyPkS3zxIa
v6KH7zu5J83sICx8TlZv0YLnES1GtixCuWukaKzyLiAXqHVGullkBvUauQwRrtEW
73CjIGpCTQMY5xmt/8V8JFi1HQLbDBRlHkX2WOzcrByLLgiGaUeKRvjYcYtaBm7q
Q25E10lnW3cGf+kljlPfc3NVxgtQUGaQKsx+wzICnz6h+0gdEzsTcAWB3Qp891jX
q+RSqEsT93oSAhPxJYQGvEu4wPfmOrh7QvProwj8mR1Jp6TyvgGi9pOtHU+YwOz+
EZD+c6mhdOfuWgD8GqT/
=jtB3
-----END PGP SIGNATURE-----
Merge tag 'of-graph-for-4.0' of git://git.pengutronix.de/git/pza/linux into for-next
Pull of-graph helpers from Philipp Zabel:
of: Add of-graph helpers to loop over endpoints and find ports by id
This series converts of_graph_get_next_endpoint to decrement the refcount of
the passed prev parameter. This allows to add a for_each_endpoint_of_node
helper macro to loop over all endpoints in a device tree node.
The of_graph_get_port_by_id function is added to retrieve a port by its known
port id (contained in the reg property) from the device tree.
It was found that having two displays enabled and having an NV12 overlay
on one of the displays will cause underflows/synclosts. Debugging this
pointed to some issue with MFLAG.
It is unclear why this issue is happening, but it looks like there is a
HW bug related to MFLAG and FIFO management. Disabling MFLAG makes this
issue go away, but then we lose the benefit of MFLAG. Also forcing MFLAG
always on makes the issue go away.
Also, using certain values for MFLAG_START, MFLAG thresholds and PRELOAD
makes the issue go away, but there was no obvious logic to which values
work and which don't.
As a workaround until more information about this is found, force MFLAG
always on to make NV12 usable.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OMAP5 has support for MFLAG feature, which allows DSS to dynamically
increase the priority of DISPC's DMA traffic. At the moment we don't
have support for it.
It was noticed that on DRA7 with high bandwidth use cases we see FIFO
underflows. Implementing MFLAG support removed those underflows.
Interestingly, on OMAP5 uEVM no such overflows were seen.
This patch adds a simple MFLAG implementation, where we use a fixed
MFLAG threshold value based on the FIFO size. The thresholds are set to
4/8 of fifo size for low threshold, and 5/8 of fifo size for high
threshold.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
At the moment we don't setup FIFO thresholds by default in omapdss. It's
supposed to be done by the user of omapdss. And that is missing from
omapdrm, causing unoptimal thresholds to be used when using omapdrm.
While I believe it's in theory better to allow the user of omapdss to
setup the fifo thresholds, in practice we always use the same values,
and we could as well setup the thresholds in omapdss.
Furthermore, in omapdss init we always swap the FIFO used for GFX and WB
overlays, but we don't swap the FIFO thresholds for those overlays
(which is the reason for omapdrm using unoptimal HW reset values). So
it would make sense to setup the thresholds to account for the swapping
of the FIFOs.
So, this patch adds code to setup default FIFO tresholds at omapdss
init.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Dispc driver presumes that the callers handle locking for all normal
functions. However, omapdrm doesn't handle this, and presumes that all
overlay manager registers are private to that overlay manager, and thus
presumes that configurations for overlay managers can be written via
different threads freely.
For many registers the above is true. The exceptions are DISPC_CONTROL
and DISPC_CONFIG registers, which contain bits for both LCD and TV
overlay managers.
Fixing this properly in omapdrm means a big omapdrm rewrite. So, for
now, add locking to dispc for the problematic registers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Somnath Mukherjee <somnath@ti.com>
omapdrm doesn't always configure the overlays correctly, causing the
overlay setup functions to be called with zero timings. This leads to
division by zero error.
This happens, for example, when a HDMI cable is not connected, but a
user tries to setup a plane with scaling.
Fixing omapdrm is a big job, so for now let's check for the bad timings
in DISPC and return an error.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The common 'struct videomode' does not have a flag to select when the
sync signals should be driven.
The default behavior of DISPC HW is to drive the sync signal on the
opposite pixel clock edge from data signal, which is also what the
videomode_to_omap_video_timings() uses.
However, it looks like what panels usually expect is that the data and
sync signals are driven on the same edge, so let's change
videomode_to_omap_video_timings() to set the sync_pclk_edge accordingly.
Note that this only affect panels drivers that use
videomode_to_omap_video_timings(), probably when getting the video
timings directly from DT data. The drivers can still configure the
sync_pclk_edge independently if they so wish.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
When configuring the lcd timings, instead of writing enum values
directly to the HW, use switch-case to get the value to be programmed.
This is safer and also allows us to change the enum values.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
DISPC can drive data lines either on rising or falling pixel clock edge,
which can be configured by the user.
Sync lines can also be driven on rising or falling pixel clock edge, but
additionally the HW can be configured to drive the sync lines on
opposite clock edge from the data lines.
This opposite edge setting does not make any sense, as the same effect
can be achieved by just setting the sync lines to be driven on the other
edge compared to the data lines. It feels like some kind of backward
compatibility option, even if all DSS versions seem to have the same
implementation.
To simplify the code and configuration of the signals, and to make the
dispc timings more compatible with what is used on other platforms,
let's just remove the whole opposite-edge support.
The drivers that used OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES setting are
changed so that they use the opposite setting from the data edge.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
TFP410 requires that DE is active high and the data and syncs are driven
on rising pixel clock edge. However, at the moment the driver doesn't
request such syncs, and the end result is that the sync settings depend
on default values, which are not right in all cases.
Set the sync values explicitly.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The DISPC driver checks that the buffer address is not 0. However, when
using TILER, the address space is TILER specific and 0 is a valid
address.
Fix the check to allow address of 0 for TILER.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: srinivas pulukuru <srinivas.pulukuru@ti.com>
omapdss's sysfs directories for displays used to have 'name' file,
giving the name for the display. This file was later renamed to
'display_name' to avoid conflicts with i2c sysfs 'name' file. Looks like
at least xserver-xorg-video-omap3 requires the 'name' file to be
present.
To fix the regression, this patch creates new kobjects for each display,
allowing us to create sysfs directories for the displays. This way we
have the whole directory for omapdss, and there will be no sysfs file
clashes with the underlying display device's sysfs files.
We can thus add the 'name' sysfs file back.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: NeilBrown <neilb@suse.de>
It has been observed that the current SDA-HOLD time is too short for
some board/cable/monitor combinations. Increase the SDA-HOLD time to
1000ns.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
AM43xx supports pixel clock divider of 1, just like all OMAP3+ SoCs. Fix
the minimum divider value.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Decrementing the reference count of the previous endpoint node allows to
use the of_graph_get_next_endpoint function in a for_each_... style macro.
All current users of this function that pass a non-NULL prev parameter
(that is, soc_camera and imx-drm) are changed to not decrement the passed
prev argument's refcount themselves.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
the check of the return code is missing, user space does not get notified
about the error condition:
omapdss OVERLAY error: overlay 2 horizontally not inside the display area (403 + 800 >= 800)
omapdss APPLY error: failed to apply settings: illegal configuration.
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add support for DRA7xx DPI output.
DRA7xx has three DPI outputs, each of which gets its input from a DISPC
channel. However, DRA72x has only one video PLL, and DRA74x has two
video PLLs. In both cases the video PLLs need to be shared between
multiple outputs. The driver doesn't handle this at the moment.
Also, DRA7xx requires configuring CONTROL module bits to route the clock
from the PLL to the used DISPC channel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add support for DRA7xx to the HDMI driver.
The HDMI block on DRA7xx is the same as on OMAP5, except we need to
enable and disable the HDMI PLL via the CONTROL module.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
On DRA7xx, DISPC needs to write output signal polarities not only to a
DISPC register, like for all earlier DSS versions, but to control
module's CTRL_CORE_SMA_SW_1 register.
This patch adds support to write the polarities to control module.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add DRA7xx support to DISPC driver. The DISPC block is the same as on
OMAP5, except the PLL's used for clocking are "videoX", not "dsiX".
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
DRA7xx SoCs have one (DRA72x) or two (DRA74x) video PLLs. They are
basically the same as DSI PLLs on OMAPs, but without the rest of the DSI
hardware. The video PLLs also require some configuration via the CONTROL
module.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add functions which configure the control module register
CTRL_CORE_DSS_PLL_CONTROL found in DRA7xx SoCs. This register configures
whether the PLL registers are accessed internally by DSS, or externally
using OCP2SCP interface. They also configure muxes which route the PLL
output to a particular LCD overlay manager within DSS.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
A race issue has been observed with the encoder-tpd12s015 driver, which
leads to errors when trying to read EDID. This has only now been
observed, as OMAP4 and OMAP5 boards used SoC's GPIOs for LS_OE GPIO. On
dra7-evm boards, the LS_OE is behind a i2c controlled GPIO expander,
which increases the time to set the LS_OE.
This patch simplifies the handling of the LS_OE gpio in the driver by
removing the interrupt handling totally. The only time we actually need
to enable LS_OE is when we are reading the EDID, and thus we can just
set and clear the LS_OE gpio inside the read_edid() function.
This also has the additional benefit of very slightly decreasing the
power consumption.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The OMAP5 HW supports directing DIGIT channel to DPI output, but the
driver doesn't support that. However, we have marked that configuration
as possible in the dss features, so in certain cases the driver tries to
use that configuration, leading to broken display.
Fix the problem by allowing DIGIT channel to go only to HDMI output.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In some cases we need global identifiers for the DSS PLLs, for example
when configuring clock muxing on DRA7. For this purpose let's add a
'enum dss_pll_id'.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Assigning ddata->invert_polarity to itself is not very useful; the
context suggests that the right-hand side should have been
pdata->invert_polarity.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
opa362 is amplifier for video and can be connected to the tvout pads
of the OMAP3. It has one gpio control for enable/disable of the output
(high impedance).
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Marek Belisko <marek@goldelico.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
After the commit ef691ff48b (OMAPDSS: DT: Get source endpoint by
matching reg-id) we look for the SDI output using the port number.
However, the SDI driver doesn't set the port number, which causes the
SDI display to not initialize.
Fix this by setting the SDI port number to 1. We use a hardcoded value,
as SDI was used only on OMAP3 and it's always port number 1 there.
Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The regulator_disable() doesn't accept NULL pointers.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
HDMI hardware parameters structs for OMAP4 and OMAP5 contained two
initializers for 'clkdco_max'. The first one was a remnant with wrong
value.
Remove the extra initializer entries.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Here's the set of driver core patches for 3.19-rc1.
They are dominated by the removal of the .owner field in platform
drivers. They touch a lot of files, but they are "simple" changes, just
removing a line in a structure.
Other than that, a few minor driver core and debugfs changes. There are
some ath9k patches coming in through this tree that have been acked by
the wireless maintainers as they relied on the debugfs changes.
Everything has been in linux-next for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlSOD20ACgkQMUfUDdst+ylLPACg2QrW1oHhdTMT9WI8jihlHVRM
53kAoLeteByQ3iVwWurwwseRPiWa8+MI
=OVRS
-----END PGP SIGNATURE-----
Merge tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core update from Greg KH:
"Here's the set of driver core patches for 3.19-rc1.
They are dominated by the removal of the .owner field in platform
drivers. They touch a lot of files, but they are "simple" changes,
just removing a line in a structure.
Other than that, a few minor driver core and debugfs changes. There
are some ath9k patches coming in through this tree that have been
acked by the wireless maintainers as they relied on the debugfs
changes.
Everything has been in linux-next for a while"
* tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits)
Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries"
fs: debugfs: add forward declaration for struct device type
firmware class: Deletion of an unnecessary check before the function call "vunmap"
firmware loader: fix hung task warning dump
devcoredump: provide a one-way disable function
device: Add dev_<level>_once variants
ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries
ath: use seq_file api for ath9k debugfs files
debugfs: add helper function to create device related seq_file
drivers/base: cacheinfo: remove noisy error boot message
Revert "core: platform: add warning if driver has no owner"
drivers: base: support cpu cache information interface to userspace via sysfs
drivers: base: add cpu_device_create to support per-cpu devices
topology: replace custom attribute macros with standard DEVICE_ATTR*
cpumask: factor out show_cpumap into separate helper function
driver core: Fix unbalanced device reference in drivers_probe
driver core: fix race with userland in device_add()
sysfs/kernfs: make read requests on pre-alloc files use the buffer.
sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
fs: sysfs: return EGBIG on write if offset is larger than file size
...
The i2c_put_adapter() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The bit field for IEC958_AES2_CON_SOURCE is bits 3-0 in
HDMI_CORE_FC_AUDSCHNLS2, not imaginary bits 3-4 (reverse order).
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Remove __exit qualifier from hdmi_uninit_output() because it is used
also in omapdss_hdmihw_probe().
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Enabling idle mode during audio playback causes the glitches on OMAP5
HDMI. The TRM also suggests to use no-idle for HDMI audio playback.
This patch sets HDMI idle mode to no-idle for the duration of the
playback, and restores it back to original value afterwards.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In new model these callbacks are obsolete since the ASoC component
drivers are integrated into the HDMI drivers and no callbacks are
needed anymore.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Implements callbacks for OMAP HDMI audio platform driver and registers
it in probe function. Unregistering is done in remove function.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Removes the OMAP5 HDMI audio callbacks for the old external DAI driver.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Implements callbacks for OMAP HDMI audio platform driver and registers
it in probe function. Unregistering is done in remove function.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Removes the OMAP4 HDMI audio callbacks for the old external DAI driver.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Make hdmi_mode_has_audio() more user friedly by taking hdmi_config as
parameter.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tomi Valkeinen