| Age | Commit message (Collapse) | Author |
|---|
|
The lgphilips panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_generic_dpi_data struct, which is needed by the panel driver
to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
|
|
The lgphilips panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the
panel driver itself.
Use the platform data as defined for generic dpi panels to pass gpio information
to the lgphilips driver.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja <archit@ti.com>
|
|
The generic dpi panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the
panel driver itself.
Add a generic way of passing gpio information to the generic dpi panel driver
via it's platform_data. This information includes the number of gpios used by
the panel, the gpio number and logic level (active high/low) for each gpio. This
gpio data will be used by the driver to request and configure the gpios required
by the panel.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
|
|
The omap_dss_device structs's max_backlight_level is used to pass maximum
backlight level for the platform. However, no board file using this panel
populates this field. Therefore, we remove it's usage from the panel driver.
Signed-off-by: Archit Taneja <archit@ti.com>
|
|
Use devm_kzalloc instead of kzalloc to allocate driver data for the picodlp
panel driver. This simplifies the driver's probe and remove functions.
Signed-off-by: Archit Taneja <archit@ti.com>
|
|
Use devm_kzalloc instead of kzalloc to allocate driver data for the lg phillips
panel driver. This simplifies the driver's probe and remove functions.
Cc: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Archit Taneja <archit@ti.com>
|
|
Use devm_kzalloc instead of kzalloc to allocate driver data for the generic dpi
panel driver. This simplifies the driver's probe and remove functions.
Signed-off-by: Archit Taneja <archit@ti.com>
|
|
The n8x0 panel contains support to call platform backlight functions.
These are not used by any board, and can be removed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
|
|
NEC-nl8048hl11 driver contains support to call platform backlight
functions. These are not used by any board, and can be removed.
Signed-off-by: Archit Taneja <archit@ti.com>
|
|
Sharp ls037v7dw01 driver contains support to call platform backlight
functions. These are not used by any board, and can be removed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
|
|
acx565akm has support to call set_backlight/get_backlight in platform
code. They are not used by any board, and thus can be removed from the
driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
|
|
Structs for platform data of omapdss panels are found in headers in the
'include/video/' path. Board files populate these structs with platform
specific values, and the panel driver uses these to configure the panel.
Currently, each panel has it's own header in the above path. Move all the
omapdss panel platform data structs to a single header omap-panel-data.h.
This is useful because:
- All other omapdss panel drivers will be modified to use platform data. This
would lead to a lot of panel headers usable only by omapdss. A lot of these
platform data structs are trivial, and don't really need a separate header.
- Platform data would be eventually removed, and platform information would be
passed via device tree. Therefore, omapdss panel platform data structs are
temporary, and will be easier to remove if they are all in the same header.
- All board files will have to include the same header to configure a panel's
platform data, that makes the board files more consistent.
Signed-off-by: Archit Taneja <archit@ti.com>
|
|
The support outputs struct for overlay managers is incorrect for OMAP4. Make
these changes:
- DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
output.
- the TV manager can suppport DPI, but the omapdss driver doesn't support that
yet, we require some muxing at the DSS level, and we also need to configure
the hdmi pll in the DPI driver so that the TV manager has a pixel clock. We
don't support that yet.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
This driver uses omap_dss_device that it gets from a board file through
SPI platfrom_data pointer to pass data from SPI to DSS portion of the
driver by using dev_set_drvdata(). However this trick no longer works,
as DSS core no longer uses omap_dss_device from a board file to create
the real device, so use a global pointer to accomplish this instead,
like other SPI panel drivers do.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Pull ARM SoC board specific changes from Arnd Bergmann:
"These updates are all for board specific code, including
- defconfig updates for shmobile, davinci, bcm2835, imx, omap and
tegra
- SD/MMC and I2C support on bcm2835 (Raspberry PI)
- minor updates for PXA
- shmobile updates to GPIO usage in board files
- More things in OMAP board files are moved over to device tree
probing
- Better support for audio devices on some OMAP platforms"
* tag 'boards' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (55 commits)
ARM: imx_v4_v5_defconfig: Add VPU support
ARM: imx: configs: enable netfilter support
ARM: OMAP2+: Fix twl section warnings related to omap_twl4030_audio_init
ARM: OMAP2+: omap2plus_defconfig: enable omap1 rtc
RX-51: Register twl4030-madc device
RX-51: Add leds lp5523 names from Maemo 5 2.6.28 kernel
ARM: OMAP2+: AM33XX: omap2plus_defconfig: Add support for few drivers
ARM: OMAP1: nokia770: enable CBUS/Retu
ARM: OMAP2+: omap2plus_defconfig: enable CMA allocator
ARM: OMAP2+: omap2plus_defconfig: enable TFP410 chip support
ARM: OMAP3: igep0020: simplify GPIO LEDs dependencies
ARM: OMAP2+: craneboard: support the TPS65910 PMU
ARM: OMAP2+: craneboard: support NAND device
ARM: OMAP3: cm-t3517: add MMC support
ARM: OMAP2+: Remove apollon board support
ARM: shmobile: armadillo800eva: set clock rates before timer init
ARM: tegra: defconfig updates
ARM: shmobile: mackerel: Use gpio_request_one()
ARM: shmobile: kzm9g: Use gpio_request_one()
ARM: shmobile: bonito: Use gpio_request_one()
...
|
|
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 195e672a76056478cc79f5c48343164c9237852e
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>
|
|
As apollon board doesn't used anymore, remove it.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[tony@atomide.com: dropped uncompress.h changes, it's gone]
Signed-off-by: Tony Lindgren <tony@atomide.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>
|
|
CONFIG_HOTPLUG is going away as an option. As a result, the __dev*
markings need to be removed.
This change removes the use of __devinit, __devexit_p, __devinitdata,
__devinitconst, and __devexit from these drivers.
Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.
Cc: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
These devices are not available on other architectures, so
let's limit them to omap.
If the driver subsystem maintainers want to build test
system wide changes without building for each target,
it's easy to carry a test patch that just strips out the
depends entries from Kconfig files.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Commit 0e8276ef75f5c7811b038d1d23b2b42c16efc5ac (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>
|
|
This reverts commit b41deecbda70067b26a3a7704fdf967a7940935b.
The simpler locking causes huge latencies when two processes use the
omapfb, even if they use different framebuffers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
fb2display() has a for loop which always returns at the first iteration.
Replace the loop with a simple if.
This removes the smatch warning:
drivers/video/omap2/omapfb/omapfb.h:153 fb2display() info: loop could be
replaced with if statement.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
omapfb_find_best_mode() doesn't check for the return value of kmalloc.
Fix this. This also removes the smatch warning:
drivers/video/omap2/omapfb/omapfb-main.c:2256 omapfb_find_best_mode()
error: potential null dereference 'specs'. (kzalloc returns null)
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Use devm_kzalloc to allocate omapfb2_device. This fixes possible memory
leak:
drivers/video/omap2/omapfb/omapfb-main.c:2553 omapfb_probe() warn:
possible memory leak of 'fbdev'
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>
|
|
Export DISPC functions.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Export dss_features related functions.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Export dss_mgr_ops related functions.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Separate the core DSS files and compat layer files in the Makefile for
clarity.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Move creation of the sysfs files for displays to the compat layer.
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>
|
|
Commit 5d89bcc341771d95e3a2996218e5949a6627f59e (OMAPDSS: remove initial
display code from omapdss) moved setting up the initial overlay, overlay
manager, output and display connections from omapdss to omapfb.
However, currently omapfb only handles the connection related to the
default display, which means that no overlay managers are connected to
other displays.
This patch changes omapfb to go through all dssdevs, and connect an
overlay manager to them.
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>
|
|
omapfb gives a WARN_ONCE if a predefined physical address is given for
allocating the framebuffer memory, as this is not currently supported.
However, the same warning happens if omapfb fails to allocate memory
during runtime, as when the allocation has failed, omapfb tries to
re-allocate the old memory with the physical address of the old memory
area.
Remove the warning from omapfb_alloc_fbmem, as it serves no purpose on
the failure case above, and move it to omapfb_parse_vram_param, so that
we only warn if physical address is given via omapfb module parameters.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Kernel lock verification code has lately detected possible circular
locking in omapfb. The exact problem is unclear, but omapfb's current
locking seems to be overly complex.
This patch simplifies the locking in the following ways:
- Remove explicit omapfb mem region locking. I couldn't figure out the
need for this, as long as we take care to take omapfb lock.
- Get omapfb lock always, even if the operation is possibly only related
to one fb_info. Better safe than sorry, and normally there's only one
user for the fb so this shouldn't matter.
- Make sure fb_info lock is taken first, then omapfb lock.
With this patch the warnings about possible circular locking does not
happen anymore.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Currently omapfb_realloc_fbmem() calls dssdev->sync to ensure any
possible frame update is finished. This patch moves the call to
dssdev->sync from omapfb_realloc_fbmem to the callers of
omapfb_realloc_fbmem.
This keeps dssdev related calls out from omapfb_realloc_fbmem, which
makes sense as the function should only deal with fb memory. Also, this
seems to avoid a lockdep warning about possible circular locking.
However, the exact reason for that warning is still unclear.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
