omapfb compilation fails on x86 (but not on omap):
drivers/video/omap2/omapfb/omapfb-ioctl.c: In function ‘omapfb_ioctl’:
drivers/video/omap2/omapfb/omapfb-ioctl.c:861:23: error: ‘SZ_1M’ undeclared (first use in this function)
drivers/video/omap2/omapfb/omapfb-ioctl.c:861:23: note: each undeclared identifier is reported only once for each function it appears in
Fix this by including linux/sizes.h.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Do not fail if dpll4_m4_ck is missing. The clock is not there on omap24xx,
so this should not be a hard error.
The patch retains the functionality before the commit 185bae10 (OMAPDSS:
DSS: Cleanup cpu_is_xxxx checks).
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Register the DSS driver after SPI probe. This simplifies the
initialization. This is similar to what is being done e.g.
in panel-acx565akm.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add a dispc_features struct for OMAP5. Previously, OMAP5 used the same
struct as OMAP4. The new struct for OMAP5 contains the updated register
field offset and maximum limit for overlay manager width and height.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The overlay manager width and height vary in OMAP5 from previous OMAPs
in terms of maximum limit and register field positions. Add parameters
in dispc_features for these. Also remove params related to manager width
and height from dss_features, as we want to maintain a feature list for
individual IPs.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Variable r is never set to any value different to zero.
Delete the if statement as it will never executed.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Commit 952cbaaa9b (OMAPFB: Change
dssdev->manager references) added checks for OMAPFB_WAITFORVSYNC ioctl
to verify that the display, output and overlay manager exist. However,
the code erroneously uses && for each part, which means that
OMAPFB_WAITFORVSYNC may crash the kernel if no display, output or
manager is associated with the framebuffer.
This patch fixes the issue by using ||.
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Conflicts:
drivers/video/omap2/dss/Kconfig
drivers/video/omap2/omapfb/omapfb-ioctl.c
drivers/video/omap2/omapfb/omapfb-main.c
Merge changes to make omapfb use common dma_alloc, and remove omap's
custom vram allocator.
This reverts commit 14840b9a83.
The commit breaks audio, and a new version will be applied later.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OMAP specific vram allocator is no longer used, and we can remove init
call to the vram allocator.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
As omapfb no longer uses omap specific vram allocator we can remove the
vram pre-allocation from rx51 board file.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Use dma_alloc_attrs to allocate memory instead of omap specific vram
allocator. After this we can remove the omap vram allocator.
There are some downsides to this change:
1) dma_alloc_attrs doesn't let us allocate at certain physical address.
However, this should not be a problem as this feature of vram allocator
is only used when reserving the framebuffer that was initialized by the
bootloader, and we don't currently support "passing" a framebuffer from
the bootloader to the kernel anyway.
2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
we don't need the ioremap when using VRFB. This patch uses
DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
not operational.
3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
changed the ioctl to return 64M for all the values, which, I hope, the
applications will interpret as "there's enough vram".
4) "vram" kernel parameter to define how much ram to reserve for video
use no longer works. The user needs to enable CMA and use "cma"
parameter.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Use DMA_BIT_MASK() for fb's coherent_dma_mask for clarity.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
When doing a manual update in dss_mgr_start_update, we clear the shadow dirty
flags. Although there isn't any harm in clearing them. The need to clear them
out here should never arrive.
When applying configurations for a manual update manager, we never do any
register writes, i.e, calls to dss_mgr_write_regs and dss_mgr_write_regs_extra
never happen while applying. We do all these writes only when we call
dss_mgr_start_update. Hence, there is never a time when the shadow registers
are dirty.
Remove the call to mg_clear_shadow_dirty.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The bool was_updating is never really used for anything. It is set to the
current value of mp->updating, but not used anywhere. Remove this variable.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
An overlay's channel out field isn't a shadow register. The TRM says that it's
taken into effect immediately. This understanding was missing and channel out
was treated as a shadow parameter, and in overlay's private data as extra info.
Program channel out bits directly in dss_ovl_set_manager(). In order to do this
safely, we need to be totally sure that the overlay is disabled in hardware. For
auto update managers, we can assume that the overlay was truly disabled at
dss_ovl_unset_manager() through the wait_pending_extra_info_updates() call.
However, when unsetting manager for an overlay that was previously connected to
a manager in manual update, we can't be sure if the overlay is truly disabled.
That is, op->enabled might not reflect the actual state of the overlay in
hardware. The older manager may require a manual update transfer to truly
disable the overlay. We expect the user of OMAPDSS to take care of this, in
OMAPDSS, we make sure that an overlay's manager isn't unset if there if
extra_info is still dirty for that overlay.
The wrong understanding of channel out bits also explains the reason why we see
sync lost when changing an overlay's manager which was previously connected to a
manual update manager. The following sequence of events caused this:
- When we disable the overlay, no register writes are actually done since the
manager is manual update, op->enabled is set to false, and the
extra_info_dirty flag is set. However, in hardware, the overlay is still
enabled in both shadow and working registers.
- When we unset the manager, the software just configures the overlay's manager
to point to NULL.
- When we set the overlay to a new manager(which is in auto update) through
dss_ovl_set_manager, the check for op->enabled passes, the channel field in
extra info is set to the new manager. When we do an apply on this manager,
the new channel out field is set in the hardware immediately, and since the
overlay enable bit is still set in hardware, the new manager sees that the
overlay is enabled, and tries to retrieve pixels from it, this leads to sync
lost as it might be in the middle of processing a frame when we set the
channel out bit.
The solution to this was to ensure that user space does another update after
disabling the overlay, this actually worked because the overlay was now truly
disabled, and an immediate write to channel out didn't impact since the manager
saw the new overlay as disabled, and doesn't try to retrieve pixels from it.
Remove channel as an extra_info field. Make dss_ovl_unset_manager more strict
about the overlay being disabled when detaching the manager. For overlays
connected to a manual update manager, unset_manager fails if we need another
update to disable the overlay.
We still need to a manual update to ensure the overlay is disabled to get change
the overlay's manager. We could work on doing a dummy update by using DISPC's
capability to gate the different video port signals. This is left for later.
Remove the comment about the sync lost issue.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
When calculating row and pixel increments for graphics and video pipes, we need
to consider the dimensions of the input frame to know how to read from the
buffer. Hence, we need to calculate these parameters from the input to the
pipeline.
For writeback, the row and pixel increments need to be calculated based on the
output of the writeback pipeline, i.e, the dimensions of the frame after
scaling. Ensure that dispc driver uses values of out_width and out_height when
calling calc_dma/calc_tiler_rotation_offset.
For graphics and video pipes, the original code passed the original height as
frame_height to calc_dma_rotation_offset, and not the predecimated height. This
is left as it is for now. We need to figure out why pre decimated height isn't
needed.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Since writeback writes to a buffer instead of reading from one, predecimation
doesn't make sense for it. Configure the width and height predecimation limits
to 1 if the plane is writeback.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dispc_ovl_calc_scaling_44xx() doesn't work correctly for writeback. There are
two issues with it:
- the function tries to calculate pixel clock for the input plane using
dispc_plane_pclk_rate(), calling this with writeback as input plane results in
a BUG(), this function shouldn't be called for writeback at all. Fix this by
calculating pixel clock only when we are not in mem to mem mode.
- the maximum input_width is the product of the downscale ratio supported and
the and the given output_width. This was calculated incorrectly by dividing
output_width with maxdownscale. Fix this.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Normally the omapdss driver gets the regulators using the regulator
names assigned for omapdss. However, in an effort to get a minimal DSS
support for DT enabled kernel on selected boards, we will add omapdss
devices and platform data the old way even for DT kernel. This causes
the problem that omapdss cannot find the regulators using omapdss's
regulator names.
This patch creates a temporary workaround for DSI and HDMI by trying to
get the regulators also using native OMAP4 regulator names.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
This function is now used in the driver init path to handle
probe errors properly. Thus, it may be possible to use this function
outside the exit path.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Fix sparse warning:
drivers/video/omap2/dss/dispc.c:3320:6: warning: symbol
'dispc_dump_irqs' was not declared. Should it be static?
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Creating the accessory devices, such as audio, from the HDMI driver
allows to regard HDMI as a single entity with audio an display
functionality. This intends to follow the design of drivers such
as MFD, in which a single entity handles the creation of the accessory
devices. Such devices are then used by domain-specific drivers; audio in
this case.
Also, this is in line with the DT implementation of HDMI, in which we will
have a single node to describe this feature of the OMAP SoC.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
It could be possible that the DMA port differs accross diferent HDMI IPs. Thus,
add an IP-specific function to obtain the address offset and size of the DMA
data port.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The display must be uninitialized in order to free the requested GPIOs.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Do not blindly assume that the panel could be initialized.
While there, group mutex initialization at a single place.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Do not assume blindly that the DSS driver was registered successfully.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Minor cleanup to give to the resource variable a more proper name.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The return value of wait_for_completion_timeout() is always
>= 0 with unsigned int type.
So the condition "ret < 0" or "ret >= 0" is pointless.
Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The return value of wait_for_completion_timeout() is always
>= 0 with unsigned int type.
So the condition "ret < 0" or "ret >= 0" is pointless.
Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
check_horiz_timing_omap3() has a variable named 'DS'. i386 uses DS name
for something else, causing a compilation error. As 'DS' is not a very
good local variable name in the first place, let's change it to 'ds',
fixing the issue.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We currently get the decision whether to use PRCM or DSI PLL clock for
DPI from the board file. This is not a good way to handle it, and it
won't work with device tree.
This patch changes DPI to always use DSI PLL if it's available.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The SoCs that have DSI module should have a working DSI PLL. However,
some rare boards have not connected the powers to the DSI PLL.
This patch adds a function that tries to power up the DSI PLL, and
reports if that doesn't succeed. DPI uses this function to fall back to
PRCM clocks if DSI PLL doesn't work.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Instead of using dpi_use_dsi_pll() to check if dsi pll is to be used, we
can just check if dpi.dsidev != NULL.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dss.c currently exposes functions to configure the dispc source clock
and lcd source clock. There are configured separately from the output
drivers.
However, there is no safe way for the output drivers to handle dispc
clock, as it's shared between the outputs. Thus, if, say, the DSI driver
sets up DSI PLL and configures both the dispc and lcd clock sources to
that DSI PLL, the resulting dispc clock could be too low for, say, HDMI.
Thus the output drivers should really only be concerned about the lcd
clock, which is what the output drivers actually use. There's lot to do
to clean up the dss clock handling, but this patch takes one step
forward and removes the use of dss_select_dispc_clk_source() from the
output drivers.
After this patch, the output drivers only configure the lcd source
clock. On omap4+ the dispc src clock is never changed from the default
PRCM source. On omap3, where the dispc and lcd clocks are actually the
same, setting the lcd clock source sets the dispc clock source.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We don't currently set the dss fck when starting up. This is not a
problem, as we setup the fck later when configuring the pixel clocks. Or
this is how it was for omap2, for the rest of the omaps this may not be
so.
For DSI, HDMI and also for DPI when using DSI PLL, we don't need to
change the dss fck, and thus it may be left unconfigured. Usually the
dss fck is already setup fine by default, but we can't trust this.
This patch sets the dss fck to maximum at probe time.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dss_calc_clock_rates() was removed earlier as it was not used, but it is
needed for DSI PLL calculations, so this patch adds it back.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
It looks like on many OMAP versions powers for both HSClk and HSDiv to
be enabled to have a functional HSDiv.
This patch fixes the issue by forcing both powers on.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The DSI PLL and HSDivider can be used to generate the pixel clock for
LCD overlay manager, which then goes to DPI output. On the DPI output
pin the voltage of the signal is shifted from the OMAP's internal
minimal voltage to 1.8V range. The shifting is not instant, and the
higher the clock frequency, the less time there is to shift the signal
to nominal voltage.
If the HSDivider's divider is greater than one and odd, the resulting
pixel clock does not have 50% duty cycle. For example, with a divider of
3, the duty cycle is 33%.
When combining high frequency (in the area of 140MHz+) and non-50% duty
cycle, it has been observed the the shifter does not have enough time to
shift the voltage enough, and this leads to bad signal which is rejected
by monitors.
As a workaround this patch makes the divider calculation skip all odd
dividers when the required pixel clock is over 100MHz. The limit of
100MHz is a guesstimate.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
DPI may use DSI PLL, so it depends on DSI. However, currently DPI driver
is added first, which causes DPI initialization to fail when it tries to
get the DSI PLL.
This patch changes the init order to fix this.
A better solution would be to separate DSI PLL and DSI drivers. They
have dependencies, though, but we could still have DSI PLL as an
independent entity that we could initialize before any of the output
drivers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
- Fix a bunch of deadlock situations:
* State recovery can deadlock if we fail to release sequence ids before
scheduling the recovery thread.
* Calling deactivate_super() from an RPC workqueue thread can deadlock
because of the call to rpc_shutdown_client.
- Display the device name correctly in /proc/*/mounts
- Fix a number of incorrect error return values:
* When NFSv3 mounts fail due to a timeout.
* On NFSv4.1 backchannel setup failure
* On NFSv4 open access checks
- pnfs_find_alloc_layout() must check the layout pointer for NULL
- Fix a regression in the legacy DNS resolved
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQlXRyAAoJEGcL54qWCgDy1G4QALUjERF6VBaDUVRVDe3cyrNr
1y5niKU19ysaXuNKtsGquVr3y72c0xyzCFLan8ZqJl1kXpYTDIyoDc0NBT3reffo
T4rbw8SXVFVk+iVcJQgnFo5tblHVsVk+fvZPezBknaBb/uI/kxIbicZHHxvASyzM
G0Ge/MC709x07tu3wJSyOtvD55j6bfpwbon6yjOKdN8/S2nOEsNOBjAunOWrKtsa
2v3uWC9APQqIF5z6dfhAVCEMRrQMame6W6b5LuY/MSQpLAwUUYeCGzjc1TMeWvnS
n66iCqQ0TCVgJH+7fYnrzPm5uNk4Am2XhM3QY1B0j8zl73ZWIs4PfjdoBytLnqF+
SykNVUl72WqdJnWPCtk6LvoctyOsSMK5pJj4jadvNqDKgFkuRZkWb28bqux2OlHg
ZCmnEZiew5tV+2anF6sgEaEhSyKNR/1h1ilXOy2TaV93qX+ec8tg+TE6C6YQR/R+
IoOoYD8Hbe/R/D76WK0xOOQbrXIQvKb1zvlIRx7W6d5gWpg9IceNLcBfCiF1GjPf
0PKxTbBSbSg44IRolPIprsZx6YzCI6wj2UzdPC7riozfZdSZ+T6Hh7z8rhhTjsHS
D5emunX93kMp5QSSrw6EtdTkRJ++DB+cpjK5SP7UydHsWSGnKbd8eIv7viZu5J5O
FLcHHWKIan9wQCslGQkO
=NjEu
-----END PGP SIGNATURE-----
Merge tag 'nfs-for-3.7-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs
Pull NFS client bugfixes from Trond Myklebust:
- Fix a bunch of deadlock situations:
* State recovery can deadlock if we fail to release sequence ids
before scheduling the recovery thread.
* Calling deactivate_super() from an RPC workqueue thread can
deadlock because of the call to rpc_shutdown_client.
- Display the device name correctly in /proc/*/mounts
- Fix a number of incorrect error return values:
* When NFSv3 mounts fail due to a timeout.
* On NFSv4.1 backchannel setup failure
* On NFSv4 open access checks
- pnfs_find_alloc_layout() must check the layout pointer for NULL
- Fix a regression in the legacy DNS resolved
* tag 'nfs-for-3.7-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
NFS4: nfs4_opendata_access should return errno
NFSv4: Initialise the NFSv4.1 slot table highest_used_slotid correctly
SUNRPC: return proper errno from backchannel_rqst
NFS: add nfs_sb_deactive_async to avoid deadlock
nfs: Show original device name verbatim in /proc/*/mount{s,info}
nfsv3: Make v3 mounts fail with ETIMEDOUTs instead EIO on mountd timeouts
nfs: Check whether a layout pointer is NULL before free it
NFS: fix bug in legacy DNS resolver.
NFSv4: nfs4_locku_done must release the sequence id
NFSv4.1: We must release the sequence id when we fail to get a session slot
NFS: Wait for session recovery to finish before returning
Pull thermal management & ACPI update from Zhang Rui,
Ho humm. Normally these things go through Len. But it's just three
small fixes, I guess I can pull directly too.
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
exynos4_tmu_driver_ids should be exynos_tmu_driver_ids.
ACPI video: Ignore errors after _DOD evaluation.
thermal: solve compilation errors in rcar_thermal
Pull i2c embedded fixes from Wolfram Sang:
"Two patches are usual stuff.
The bigger patch is needed to correct a wrong decision made in this
merge window. We hoped to get the PIOQUEUE mode in the mxs driver
working with DMA, but it turned out to be too broken (leading to data
loss), so we now think it is best to remove it entirely and work only
with DMA now. The patch should be in 3.7. IMO, so users never get
the chance to use both modes in parallel."
* 'i2c-embedded/for-current' of git://git.pengutronix.de/git/wsa/linux:
i2c: tegra: set irq name as device name
i2c-nomadik: Fixup clock handling
i2c: mxs: remove broken PIOQUEUE support
Tomi Valkeinen
Aaro Koskinen
Archit Taneja
Matthias Brugger
Tushar Behera
Ricardo Neri
Chuansheng Liu
Linus Torvalds