| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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>
|
|
From Michal Simek:
* 'arm-next' of git://git.xilinx.com/linux-xlnx:
zynq: move static peripheral mappings
zynq: remove use of CLKDEV_LOOKUP
zynq: use pl310 device tree bindings
zynq: use GIC device tree bindings
+ Linux 3.7-rc3
|
|
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.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>
|
|
Using devm_request_and_ioremap provides better memory handling and
improves readability.
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>
|
|
Merging in Greg's tty tree including a cleanup patch needed by the OMAP serial
header cleanups.
* depends/tty: (305 commits)
tty/serial/8250: Make omap hardware workarounds local to 8250.h
serial/8250/8250_early: Prevent rounding error in uartclk
serial: samsung: use clk_prepare_enable and clk_disable_unprepare
TTY: Report warning when low_latency flag is wrongly used
console: use might_sleep in console_lock
TTY: move tty buffers to tty_port
TTY: add port -> tty link
TTY: tty_buffer, cache pointer to tty->buf
TTY: move TTY_FLUSH* flags to tty_port
TTY: n_tty, propagate n_tty_data
TTY: move ldisc data from tty_struct: locks
TTY: move ldisc data from tty_struct: read_* and echo_* and canon_* stuff
TTY: move ldisc data from tty_struct: bitmaps
TTY: move ldisc data from tty_struct: simple members
TTY: n_tty, add ldisc data to n_tty
TTY: audit, stop accessing tty->icount
TTY: n_tty, remove bogus checks
TTY: n_tty, simplify read_buf+echo_buf allocation
TTY: hci_ldisc, remove invalid check in open
TTY: ldisc, wait for idle ldisc in release
...
|
|
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>
|
|
Merge omapdss miscellaneous patches.
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen
Pull Xen bugfixes from Konrad Rzeszutek Wilk:
- Use appropriate macros instead of hand-rolling our own (ARM).
- Fixes if FB/KBD closed unexpectedly.
- Fix memory leak in /dev/gntdev ioctl calls.
- Fix overflow check in xenbus_file_write.
- Document cleanup.
- Performance optimization when migrating guests.
* tag 'stable/for-linus-3.7-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
xen/mmu: Use Xen specific TLB flush instead of the generic one.
xen/arm: use the __HVC macro
xen/xenbus: fix overflow check in xenbus_file_write()
xen-kbdfront: handle backend CLOSED without CLOSING
xen-fbfront: handle backend CLOSED without CLOSING
xen/gntdev: don't leak memory from IOCTL_GNTDEV_MAP_GRANT_REF
x86: remove obsolete comment from asm/xen/hypervisor.h
|
|
Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED. If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.
So, treat an unexpected backend CLOSED state the same as CLOSING.
Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
|
The dispc error handler tries to "fix" issues by disabling and enabling
panel. This is problematic, as we're trying to remove the dependency
from omapdss to the omap_dss_devices. It's also racy, and doesn't really
fix anything.
This patch removes the use of omap_dss_device from the error handler,
and just disables and enables the associated overlay manager. This
should produce similar results as the previous solution, without using
dssdev.
However, the error handling is still horrible. But the problem boils
down to one question, to which I don't have a clear answer: what to do
when a HW error happens?
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The dispc's error handler has a loop inside another loop, and both use
the same loop variable. This is clearly wrong, and this patch makes a
new variable for the inner loop.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
dss_generic_clk_source_names is missing the names for clocks from DSI2
PLL. Add them.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The current omapfb code goes over all the modes found from the monitors
EDID data, and searches for a mode that is compatible with the DSS
hardware and has the highest x-res.
While this works ok as such, it proves problematic when using DSI PLL
for pixel clock. Calculating DSI PLL dividers is not the fastest of the
operations, and while doing it for one mode is usually ok, doing it for
20 modes is noticable.
Also, the first mode given in the EDID data should be the native mode of
the monitor, and thus also the best mode, so if that can be used, no
need to look further.
This patch changes the code to use the first mode that is compatible
with the DSS hardware.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
It seems that using the second EDID block causes more problems than is
of any help. The first mode in the extended block will get
FB_MODE_IS_FIRST set, which will override the first mode from the first
EDID block, thus making the default videomode selection not to work
properly.
This patch removes the use of the extended edid block for now.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The hdmi driver tries to find the given video timings from its static
list of timings, to find the required ID for the mode. The check tries
to find exact match for the pixel clock, among other checks.
with omapfb driver there can be some amount of error in the give pixel
clock, as the pixel clock is converted between Hz and ps, thus the
hdmi's check fails to find the mode.
This patch makes the check more allowing, by rounding the pixel clocks
to nearest MHz.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ricardo Neri <ricardo.neri@ti.com>
|
|
Add 1920x1200 video mode to hdmi driver's static modelist.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ricardo Neri <ricardo.neri@ti.com>
|
|
This patch makes use of the hdmi_power_[on|off]_core() functions added
in the previous patch. The functions are used when reading EDID or
detecting if a monitor is connected.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ricardo Neri <ricardo.neri@ti.com>
|
|
There's currently just one power-on function for HDMI, which enables the
IP and the video output. When reading EDID or detecting if a monitor is
connected, we don't need the video output.
Enabling the video output for these operations is not a big problem in
itself, but the quick enable/disable cycles caused by the operations
seem to cause sync lost errors from time to time. Also, this makes it
possible to read the EDID before the full video path has been set up.
This patch splits the hdmi_power_on into two parts, hdmi_power_on_core
and hdmi_power_on_full. The "full" version does what hdmi_power_on does
currently, and hdmi_power_on_core only enables the core IP. Similar
changes are made for power_off.
Note that these don't allow the HDMI IP to be first enabled, and later
enable the video output, but the HDMI IP will first need to be powered
off before calling the full version. So this is rather limited
implementation, but it fills the needs for reading EDID.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ricardo Neri <ricardo.neri@ti.com>
|
|
DISPC irqs need to be handled from the compat layer and also in the
future by the omapdrm. To make this possible, this patchs adds a set of
helper functions, so that the irqs can be managed without direct
register reads/writes.
The following functions are added, and all the current direct reg
reads/writes are changed to use these.
u32 dispc_read_irqstatus(void);
void dispc_clear_irqstatus(u32 mask);
u32 dispc_read_irqenable(void);
void dispc_write_irqenable(u32 mask);
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Add new dispc function, dispc_ovl_enabled(). This returns if the overlay
enable bit is set in the registers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
We need a low level manager-enable function for omapdrm. We have that
function as dispc internal func, _enable_mgr_out().
This patch exposes that function, and renames it to dispc_mgr_enable().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The current dispc_mgr_enable/disable function are blocking, and do a bit
too much for omapdrm. We'll expose new enable & disable functions that
will just set the bits in the registers in the following patches.
This patch renames the current functions to *_sync, to make it clear
that they are blocking, and also to free up the dispc_mgr_enable/disable
names for these new functions.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Use dss_feat_get_num_ovls() in dispc.c instead of
omap_dss_get_num_overlays() to remove the dependency to overlay.c. Note
that we still have uses of omap_dss_get_num_overlays() in dispc.c, but
these will be moved out in the future patches.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Currently omapdss driver sets up the initial connections between
overlays, overlay manager and a panel, based on default display
parameter coming from the board file or via module parameters.
This is unnecessary, as it's the higher level component that should
decide what display to use and how. This patch removes the code from
omapdss, and implements similar code to omapfb.
The def_disp module parameter and the default display platform_data
parameter are kept in omapdss, but omapdss doesn't do anything with
them. It will just return the default display name with
dss_get_default_display_name() call, which omapfb uses. This is done to
keep the backward compatibility.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Export dss_get_def_display_name() with the name of
omapdss_get_def_display_name() so that omapfb can use it after the next
patch which moves default display handling to omapfb.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Add the missing unlock on the error handling path in function
hdmi_dump_regs().
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: Sumit Semwal <sumit.semwal@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Commit 185bae1095188aa199c9be64d6030d8dbfc65e0a ("OMAPDSS: DSS: Cleanup
cpu_is_xxxx checks") broke the DSS clocks configuration by erroneously
using the clock parameters applicable to all other OMAP34xx SoCs for the
OMAP363x. This went unnoticed probably because the cpu_is_omap34xx()
class check wasn't seen as matching the OMAP363x subclass.
Fix it by checking for the OMAP363x subclass before checking for the
OMAP34xx class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Add this missing SPI dependency and prevent the driver from building
without SPI, because functions of the spi driver are used in this
driver.
drivers/video/backlight/ili9320.c:51: undefined reference to `spi_sync'
Also, a prompt string for CONFIG_LCD_ILI9320 is added for explicit
selection.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
If dsi_get_dsidev_from_id() is called with a DSI module id that does not
exist on the board, the function will crash as omap_dss_get_output()
will return NULL.
This happens on omap3 boards when dumping DSI clocks, as the dumping
code will try to get the dsidev for DSI modules 0 and 1, but omap3 only
has DSI module 0.
Also clean up the id -> output mapping, so that if the function is
called with invalid module ID it will return NULL.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Archit Taneja <archit@ti.com>
|
|
omap-for-v3.8/cleanup-headers-serial-take2
This is the first set of omap cleanup patches for v3.8 merge
window to remove most of the remaining plat includes to get us
closer to ARM common zImage support.
To avoid a huge amount of trivial merge conflicts with includes,
this branch is based on several small topic branches coordinated
with the driver subsystem maintainers. These branches are based on
v3.7-rc1 and can also be merged into the related driver subsystem
branches as needed:
omap-for-v3.8/cleanup-headers-prepare few trivial driver changes
omap-for-v3.8/cleanup-headers-dma move of the DMA header
omap-for-v3.8/cleanup-headers-gpmc GPMC and MTD changes
omap-for-v3.8/cleanup-headers-mmc MMC related changes
omap-for-v3.8/cleanup-headers-dss DSS related changes
omap-for-v3.8/cleanup-headers-asoc ASoC related changes
Note that for the dma-omap.h, it was decided that it should be
is completed. For the related discussion, please see:
https://patchwork.kernel.org/patch/1519591/#
After these patches we still have a few plat headers remaining
that will be handled in later pull requests.
|
