Here is the big driver core merge for 3.9-rc1
There are two major series here, both of which touch lots of drivers all
over the kernel, and will cause you some merge conflicts:
- add a new function called devm_ioremap_resource() to properly be
able to check return values.
- remove CONFIG_EXPERIMENTAL
If you need me to provide a merged tree to handle these resolutions,
please let me know.
Other than those patches, there's not much here, some minor fixes and
updates.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEABECAAYFAlEmV0cACgkQMUfUDdst+yncCQCfbmnQZju7kzWXk6PjdFuKspT9
weAAoMCzcAtEzzc4LXuUxxG/sXBVBCjW
=yWAQ
-----END PGP SIGNATURE-----
Merge tag 'driver-core-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core patches from Greg Kroah-Hartman:
"Here is the big driver core merge for 3.9-rc1
There are two major series here, both of which touch lots of drivers
all over the kernel, and will cause you some merge conflicts:
- add a new function called devm_ioremap_resource() to properly be
able to check return values.
- remove CONFIG_EXPERIMENTAL
Other than those patches, there's not much here, some minor fixes and
updates"
Fix up trivial conflicts
* tag 'driver-core-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (221 commits)
base: memory: fix soft/hard_offline_page permissions
drivercore: Fix ordering between deferred_probe and exiting initcalls
backlight: fix class_find_device() arguments
TTY: mark tty_get_device call with the proper const values
driver-core: constify data for class_find_device()
firmware: Ignore abort check when no user-helper is used
firmware: Reduce ifdef CONFIG_FW_LOADER_USER_HELPER
firmware: Make user-mode helper optional
firmware: Refactoring for splitting user-mode helper code
Driver core: treat unregistered bus_types as having no devices
watchdog: Convert to devm_ioremap_resource()
thermal: Convert to devm_ioremap_resource()
spi: Convert to devm_ioremap_resource()
power: Convert to devm_ioremap_resource()
mtd: Convert to devm_ioremap_resource()
mmc: Convert to devm_ioremap_resource()
mfd: Convert to devm_ioremap_resource()
media: Convert to devm_ioremap_resource()
iommu: Convert to devm_ioremap_resource()
drm: Convert to devm_ioremap_resource()
...
commit 195e672a76
OMAPDSS: DPI: Remove cpu_is_xxxx checks
made the mistake of assuming that cpu_is_omap34xx() is exclusive of
other cpu_is_* predicates whereas it includes cpu_is_omap3630().
So on an omap3630, code that was previously enabled by
if (cpu_is_omap34xx())
is now disabled as
dss_has_feature(FEAT_DPI_USES_VDDS_DSI)
fails.
So add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list.
Cc: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages so all explicit
error messages can be removed from the failure code paths.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 0e8276ef75 (OMAPDSS: DPI: always
use DSI PLL if available) made dpi.c use DSI PLL for its clock. This
works fine, for DPI, but has a nasty side effect on OMAP3:
On OMAP3 the same clock is used for DISPC fclk and LCD output. Thus,
after the above patch, DSI PLL is used for DISPC and LCD output. If
TV-out is used, the TV-out needs DISPC. And if DPI is turned off, the
DSI PLL is also turned off, disabling DISPC.
For this to work, we'd need proper DSS internal clock handling, with
refcounts, which is a non-trivial project.
This patch fixes the issue for now by disabling the use of DSI PLL for
DPI on OMAP3.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The previous patch changes dispc to get the dispc fck rate from dss core
driver. This was the only use of the dispc fck in dispc, and thus we can
now remove the clock handling.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Dispc currently gets dispc's fck with clk_get() and uses clk_get_rate()
to get the rate for scaling calculations. This causes a problem with
common clock framework, as omapdss uses the dispc functions inside a
spinlock, and common clock framework uses a mutex in clk_get_rate().
Looking at the DSS clock tree, the above use of the dispc fck is not
quite correct. The DSS_FCLK from PRCM goes to DSS core block, which has
a mux to select the clock for DISPC from various options, so the current
use of dispc fck bypasses that. Fortunately we never change the dispc
clock mux for now.
To fix the issue with clk_get_rate(), this patch caches the dss clock
rate in dss.c when it is set. Dispc will then ask for the clock rate
from dss. While this is not very elegant, it does fix the issue, and
it's not totally wrong when considering that the dispc fck actually
comes via dss.
In the future we should probably look into common clock framework and
see if that could be used to represent the DSS clock tree properly.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
omapdss_compat_init() and omapdss_compat_uninit() is called internally
by omapdss. This patch moves the calls to omapfb, omap_vout and omapdrm
drivers. omapdrm driver can later remove the call after non-compat
support has been implemented in omapdrm.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dpi.c uses dss_mgr_check_timings() to verify video timings, but that
function is in the compat layer. Change dpi.c to use the dispc's check
instead.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
This patch adds a new function, dispc_ovl_check(), which can be used to
verify scaling configuration for an overlay. The function gets both the
overlay and overlay manager as parameters, so that the caller does not
need to configure the hardware before using this function.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The whole dispc irq handling system we currently have is only needed for
compat layer, and thus can be moved from dispc.c to the compat layer.
This is quite straigtforward, but we need to add new dispc functions to
request and free the actual hardware irq: dispc_request_irq() and
dispc_free_irq().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We have two functions to wait for a dispc interrupt:
int omap_dispc_wait_for_irq_timeout(u32 irqmask, unsigned long timeout);
int omap_dispc_wait_for_irq_interruptible_timeout(u32 irqmask,
Of these, the former is not used at all, and can be removed. The latter
is only used by the compat layer, and can be moved to the compat layer
code.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dispc_mgr_enable_sync and dispc_mgr_disable_sync are only used with the
compat mode. Non-compat will use the simpler enable and disable
functions.
This patch moves the synchronous enable/disable code to the compat
layer. A new file is created, dispc-compat.c, which contains low level
dispc compat code (versus apply.c, which contains slightly higher level
compat code).
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Some of the output drivers need to handle FRAMEDONE interrupt from
DISPC. This creates a direct dependency to dispc code, and we need to
avoid this to make the compat code to work.
Instead of the output drivers registering for dispc interrupts, we
create new mgr-ops that are used to register a framedone handler. The
code implementing the mgr-ops is responsible for calling the handler
when DISPC FRAMEDONE interrupt happens. The compat layer is improved
accordingly to do the call to the framedone handler.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The output drivers need some operations from the overlay managers, like
enable and set_timings. These will affect the dispc registers, and need
to be synchronized with the composition-side changes with overlays and
overlay managers.
We want to handle these calls in the apply.c in the compatibility mode,
but when in non-compat mode, the calls need to be handled by some other
component (e.g. omapdrm).
To make this possible, this patch creates a set of function pointers in
a dss_mgr_ops struct, that is used to redirect the calls into the
correct destination.
The non-compat users can install their mgr ops with
dss_install_mgr_ops() function.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Most of the functions that are assigned to the fields in ovl struct are
in apply.c. By moving the function pointer setup into apply.c we can
make these functions static.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Most of the functions that are assigned to the fields in ovl-mgr struct
are in apply.c. By moving the function pointer setup into apply.c we can
make these functions static.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Overlay and overlay_manager structs will only be needed in the compat
mode.
This patch moves initialization of overlay and overlay_manager structs
to apply.c, so that they are handled in omapdss_compat_init().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add two new exported functions, omapdss_compat_init and
omapdss_compat_uninit, which are to be used by omapfb, omap_vout to
enable compatibility mode for omapdss. The functions are called by
omapdss internally for now, and moved to other drivers later.
The compatibility mode is implemented fully in the following patches.
For now, enabling compat mode only sets up the private data in apply.c.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We currently attach an output to a dssdev in the initialization code for
dssdevices in display.c. This works, but doesn't quite make sense: an
output entity represents (surprisingly) an output of DSS, which is
managed by an output driver. The output driver also handles adding new
dssdev's for that particular output.
It makes more sense to make the output-dssdev connection in the output
driver. This is also in line with common display framework.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
When enabling a hwmod, omap_hwmod refers to the register mentioned in the
hwmod struct's member 'prcm.omap4.context_offs' to see whether context was
lost or not. It increments the context lost count for the hwmod and then clears
the register.
All the DSS hwmods have the same register(RM_DSS_DSS_CONTEXT) as context_offs.
When DSS is enabled, the first hwmod to be enabled is the "dss_core" hwmod since
it's corresponding platform device is the parent platform device("omapdss_dss").
The dss_core hwmod updates it's context lost count correctly and clears the
register. When the hwmods corresponding to the children platform devices are
enabled, they see that the register is clear, and don't increment their context
lost count. Therefore, all the children platform devices never report a loss in
context.
The DISPC driver currently gets the context lost count for DSS power domain from
it's corresponding platform device instance("omapdss_dispc"). The DISPC platform
device is one of the child devices, and it's corresponding hwmod("dss_dispc")
doesn't report the context lost count correctly.
Modify dss_get_ctx_loss_count() such that it always takes the "omapdss_dss"
platform device as it's input, move the function to dss.c so that it has access
to that platform device.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add dss_get_core_pdev() which returns the platform device for dss core
device. The following patches use the core pdev to register sysfs files
in the compat code.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Move display sysfs related code from display.c to display-sysfs.c, for
clarity. The sysfs code will only be used for compat mode.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In order to make the scaling calculations independent of the current
hardware configuration (e.g. which manager is connected to this output),
we need to change the calc funcs to get all the variables needed for the
calculations via parameters.
This patch changes dispc_ovl_calc_scaling to get pclk and lclk as
parameters.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In order to make the scaling calculations independent of the current
hardware configuration (e.g. which manager is connected to this output),
we need to change the calc funcs to get all the variables needed for the
calculations via parameters.
This patch changes calc_scaling to get pclk and lclk as parameters.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In order to make the scaling calculations independent of the current
hardware configuration (e.g. which manager is connected to this output),
we need to change the calc funcs to get all the variables needed for the
calculations via parameters.
This patch changes check_horiz_timing_omap3() to get pclk and lclk as
parameters.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In order to make the scaling calculations independent of the current
hardware configuration (e.g. which manager is connected to this output),
we need to change the calc funcs to get all the variables needed for the
calculations via parameters.
This patch changes calc_core_clk() function to get pclk as a parameter.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Change the dispc_plane_pclk_rate and dispc_plane_lclk_rate functions to
return 0 if the given plane is the writeback plane. The clocks are not
valid for WB, but returning 0 from these functions instead of running
into BUG() will simplify the code that uses these functions.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dispc_mgr_go() should never be called with manager output disabled or if
the GO bit is already set. Change the current silent returns to
WARN_ONs.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Instead of doing direct register reads/writes, dispc_wb_enable() and
dispc_wb_is_enabled() functions can use the common overlay functions to
set and check the enable bit.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
WB will not be used with compat-mode, i.e. from omapfb. This means we
don't need the current complex dispc_wb_enable function, but can have a
simple register write version of the function.
This patch removes all the extra code from dispc_wb_enable()
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dispc_mgr_disable_digit_out() needs to wait until the DIGIT output is
turned off. This is done with either VSYNC irq on OMAP2/3 and
FRAMEDONETV on OMAP4+. It currently uses a rather hacky way to decide
what irq to use.
This patch changes dispc_mgr_disable_digit_out to use
dispc_mgr_get_framedone_irq to find out if there's framedone irq on this
SoC, and if not, uses VSYNC.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OMAP2/3 do not have FRAMEDONETV irq, but later omaps do. We currently
always return 0 from dispc_mgr_get_framedone_irq() for TV output to be
compatible with OMAP2/3.
This patch implements "no_framedone_tv" dispc-feature that is used in
dispc_mgr_get_framedone_irq to return either 0 for OMAP2/3, or the
correct IRQ number for FRAMEDONETV on OMAP4+.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dsi_get_dsidev_from_id() gives a WARN if DSI support is not compiled in.
This warning is not right, as it's valid to call
dsi_get_dsidev_from_id() to see if there is DSI support or not.
Remove the WARN().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
If the DSI support has not been compiled in or the SoC doesn't have DSI
hardware, dpi_get_dsidev() returns NULL. This NULL is passed to
dpi_verify_dsi_pll() causing a crash. The bug was added with commit
0e8276ef75 (OMAPDSS: DPI: always use DSI
PLL if available).
Fix this by checking if dsidev is NULL before calling
dpi_verify_dsi_pll().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Remove dispc_mgr_is_channel_enabled() and dss_mgr_get_timings()
declarations, as the function doesn't exist.
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>
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>
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>
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>
Linus Torvalds