Add DT data for OMAP3 IGEPv2 board. The board has the following displays:
dvi: uses TFP410 encoder to convert DPI to DVI
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sre@debian.org>
[tomi.valkeinen@ti.com: some modifications] Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
Tomi Valkeinen [Tue, 21 Aug 2012 12:35:42 +0000 (15:35 +0300)]
OMAPDSS: Add DT support to DSI
Add the code to make the DSI driver work with device tree on OMAP3 and
OMAP4.
A minor hack is needed at the moment in the DSI driver: the DSS driver
needs to know the ID number of a DSI device, as clocks are routed in
different ways to the DSI devices. At the moment we don't have any
proper way to manage this, so this patchs adds a simple lookup table
that is used to deduce the ID from the DSI device's base address.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
Tomi Valkeinen [Mon, 16 Dec 2013 13:13:24 +0000 (15:13 +0200)]
OMAPDSS: Add DT support to DSS
Add DT support for DSS. Contrary to the non-DT version, the DSS in DT
mode contains DPI and SDI outputs, which better reflects the hardware.
The non-DT code will be removed after all boards have been converted to
DT, so there's no need to change the non-DT code to act the same way.
The code for DPI and SDI needs to be refined later to make it possible
to add multiple DPI ports. For now, handling just a single DPI port is
enough for all the boards.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
Tomi Valkeinen [Thu, 2 Jan 2014 10:54:31 +0000 (12:54 +0200)]
OMAPDSS: Improve regulator names for DT
The regulator names used for DSS components are somewhat ugly for DT
use. As we're just adding DT support, it's simple to change the
regulator names.
This patch makes the DSS driver get the regulators with somewhat cleaner
names when bootin with DT. For example, this allows us to define HDMI's
VDDA regulator in the DT data as:
vdda-supply = <...>;
instead of
vdda_hdmi_dac-supply = <...>;
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
Tomi Valkeinen [Tue, 6 Aug 2013 06:50:52 +0000 (09:50 +0300)]
OMAPFB: search for default display with DT alias
Improve the search for the default display in two ways:
* compare the given display name to the display's alias
* if no display name is given, look for "display0" DT alias
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
Tomi Valkeinen [Tue, 6 Aug 2013 06:50:22 +0000 (09:50 +0300)]
OMAPDSS: get dssdev->alias from DT alias
We currently create a "displayX" style alias name for all displays,
using a number that is incremented for each registered display. With the
new DSS device model there is no clear order in which the displays are
registered, and thus the numbering is somewhat random.
This patch improves the behavior for DT case so that if the displays
have been assigned DT aliases, those aliases will be used as DSS
aliases.
This means that "display0" is always the one specified in the DT alias,
and thus display0 can be used as default display in case the user didn't
specify a default display.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
Tomi Valkeinen [Tue, 6 Aug 2013 06:41:32 +0000 (09:41 +0300)]
OMAPDSS: add 'label' support for DT
Add support to get the label (i.e. a "nickname") for a display from the
DT data. If there is no label defined, use the display's alias (e.g.
'display0') as a name.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
Tomi Valkeinen [Thu, 19 Dec 2013 10:34:19 +0000 (12:34 +0200)]
ARM: OMAP2+: DT 'compatible' tweak for displays
As there is no common panel framework in the kernel, we have OMAP
specific panel drivers. However, the DT data should be generic. This
brings the issue that some other platform could use the same panels, and
would need to create a driver with the same 'compatible' string as the
OMAP driver.
In the long run, we have to get a common panel framework. For the time
being, this patch solves the issue:
At early boot time, we go through the DT nodes looking for the panels
the kernel supports for OMAP. For each found node, the 'compatible'
string is prepended with "omapdss,", i.e. "sony,acx565akm" becomes
"omapdss,sony,acx565akm". The OMAP display drivers all have "omapdss,"
at the beginning of their compatible field.
This allows us to have generic DT data, but OMAP specific display
drivers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
Tomi Valkeinen [Mon, 18 Mar 2013 13:50:25 +0000 (15:50 +0200)]
ARM: OMAP2+: add omapdss_init_of()
The OMAP display architecture requires a bunch of platform devices which
are not created via .dts (for now). We also need to pass a few function
pointers and the DSS hardware version from the arch code to omapdss
driver.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which handles those tasks.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
Tomi Valkeinen [Thu, 13 Feb 2014 09:15:06 +0000 (11:15 +0200)]
ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path
Set 'ti,set-rate-parent' property for clocks in the dpll4_m4 clock
path, which is used for DSS functional clock. This fixes DSS driver's
clock rate configuration, which needs the rate to be propagated properly
to the divider node (dpll4_m4_ck).
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Christoph Fritz <chf.fritz@googlemail.com> Tested-by: Marek Belisko <marek@goldelico.com> Acked-by: Tony Lindgren <tony@atomide.com>
Tomi Valkeinen [Thu, 13 Feb 2014 09:14:58 +0000 (11:14 +0200)]
ARM: dts: use ti,fixed-factor-clock for dpll4_m4x2_mul_ck
We need to use set-rate-parent for dpll4_m4 clock path, so use the
ti,fixed-factor-clock version which supports set-rate-parent property.
The set-rate-parent flag itself is set in the following patch, this one
just changes the clock driver to ti,fixed-factor-clock without any other
changes.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Christoph Fritz <chf.fritz@googlemail.com> Tested-by: Marek Belisko <marek@goldelico.com> Acked-by: Tony Lindgren <tony@atomide.com>
Tomi Valkeinen [Thu, 13 Feb 2014 08:58:32 +0000 (10:58 +0200)]
ARM: dts: fix DPLL4 x2 clkouts on 3630
OMAP3630 DPLL4 is different than on OMAP3430, in that it doesn't have
the x2 multiplier for its outputs. This is not currently reflected in
the clock DT data.
Fix the issue by setting the clock multiplier to 1 (instead of 2) for the
DPLL4 output clocks.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Christoph Fritz <chf.fritz@googlemail.com> Tested-by: Marek Belisko <marek@goldelico.com> Acked-by: Tero Kristo <t-kristo@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
Tomi Valkeinen [Wed, 12 Feb 2014 13:45:57 +0000 (15:45 +0200)]
ARM: dts: fix omap3 dss clock handle names
The DSS fclk and iclk handles are named differently on OMAP3430 ES1 than
on later OMAP revisions. The ES1 has handles 'dss1_alwon_fck_3430es1'
and 'dss_ick_3430es1', whereas later revisions have similar names but
ending with 'es2'.
This means we don't have one clock handle to which we could refer to
when defining the DSS clocks.
However, as the namespaces are separate for ES1 and ES2+ OMAPs, we can
just rename the handles to 'dss1_alwon_fck' and 'dss_ick' for both ES1
and ES2+, removing the issue.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Christoph Fritz <chf.fritz@googlemail.com> Tested-by: Marek Belisko <marek@goldelico.com> Acked-by: Tero Kristo <t-kristo@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
Suman Anna [Thu, 6 Mar 2014 00:24:19 +0000 (18:24 -0600)]
ARM: dts: OMAP5: Add IOMMU nodes
The IOMMU DT nodes have been added for the DSP and IPU
subsystems. The MMUs in OMAP5 are identical to those in
OMAP4, including the bus error back capability on IPU.
Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Add the IOMMU nodes for the DSP and IPU subsystems. The MMU
within the IPU sub-system also supports a bus error back
capability, not available on the DSP MMU.
Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
[s-anna@ti.com: IPU bus error back addition] Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Add the DT node for the IOMMU within the DSP subsystem. The entry
is disabled to keep in line with the hwmod usage as intended by
the deprecated CONFIG_OMAP_IOMMU_IVA2 flag.
Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
[s-anna@ti.com: split the entry and disable the node] Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Suman Anna [Thu, 6 Mar 2014 00:24:14 +0000 (18:24 -0600)]
ARM: OMAP5: hwmod data: add mmu data for ipu & dsp
A new MMU hwmod class and data structures are created
to represent the MMUs within the IPU and DSP processor
subsystems in OMAP5. The MMUs in OMAP5 are identical to
those in OMAP4.
Cc: Benoit Cousson <bcousson@baylibre.com> Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Suman Anna [Thu, 6 Mar 2014 00:24:13 +0000 (18:24 -0600)]
ARM: OMAP2+: use pdata quirks for iommu reset lines
The OMAP iommu driver performs the reset management for the
iommu instances in processor sub-systems using the omap_device
API which are currently supplied as platform data ops. Use pdata
quirks to maintain the functionality as the OMAP iommu driver
gets converted to use DT nodes, until the reset portions are
decoupled from omap_hwmod/omap_device into a separate reset
driver.
This patch adds the pdata quirks for the reset management of
iommus within the DSP (OMAP3 & OMAP4) and IPU subsystems (OMAP4).
Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Suman Anna [Thu, 6 Mar 2014 00:24:12 +0000 (18:24 -0600)]
ARM: OMAP2+: change the ISP device archdata MMU name for DT
The IOMMU DT adaptation support uses the device name instead
of an iommu object name. Fixup the ISP device archdata MMU
name at runtime if using DT-boot. This allows the OMAP3 camera
to be functional in both legacy and DT boots. The iommu object
names should eventually vanish when all the IOMMU users have
been converted to DT nodes.
Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Suman Anna [Thu, 6 Mar 2014 00:24:11 +0000 (18:24 -0600)]
ARM: OMAP3: fix iva mmu programming issues
The IVA MMU is not functional when used through the hwmod and
omap_device layers. Add fixes to clockdomain and hwmod data
to have it functional. The hwmod changes are needed to enable
the clock, and the SWSUP change is needed to wakeup the domain
because the power domain is programmed to be in RET, and there
is no automatic power domain switching to ON.
Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
CONFIG_OMAP_IOMMU_IVA2 was defined originally to avoid conflicting
usage by tidspbridge and other iommu users. The same can be achieved
by marking the DT node disabled, so remove this obsolete flag and
the corresponding hwmod data can be enabled.
Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
[s-anna@ti.com: revise commit log] Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
video: atmel_lcdfb: ensure the hardware is initialized with the correct mode
If no driver takeover the atmel_lcdfb, the lcd won't be in a working state
since atmel_lcdfb_set_par() will never be called. Enabling a driver which does,
like fbcon, will call the function and put atmel_lcdfb in a working state.
David Herrmann [Thu, 23 Jan 2014 14:14:56 +0000 (15:14 +0100)]
fbdev: vesafb: add dev->remove() callback
If x86-sysfb platform-devices are removed from a system, we should
properly unload vesafb. Otherwise, we end up releasing the parent while
our vesa framebuffer is still running. This currently works just fine, but
will cause problems on handover to real hw. So add the ->remove() callback
and unregister vesafb.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
David Herrmann [Thu, 23 Jan 2014 14:14:55 +0000 (15:14 +0100)]
fbdev: efifb: add dev->remove() callback
If x86-sysfb platform-devices are removed from a system, we should
properly unload efifb. Otherwise, we end up releasing the parent while our
efi framebuffer is still running. This currently works just fine, but will
cause problems on handover to real hw. So add the ->remove() callback and
unregister efifb.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Daniel Mack [Wed, 5 Mar 2014 16:12:48 +0000 (17:12 +0100)]
video: pxa3xx-gcu: provide an empty .open call
This is necessary in order to make the core set file->private_data to
miscdev in use. We need that information later to dereference the
container of the device, so we can get access to our private struct from
other callbacks.
Signed-off-by: Daniel Mack <zonque@gmail.com> Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Daniel Mack [Wed, 5 Mar 2014 16:12:47 +0000 (17:12 +0100)]
video: pxa3xx-gcu: pass around struct device *
Instead of passing around struct platform_device, use struct device.
That saves one level of dereference. Also, call platform devices pdev,
and provide a shortcut for &pdev->dev.
Signed-off-by: Daniel Mack <zonque@gmail.com> Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Wang YanQing [Wed, 5 Mar 2014 15:56:19 +0000 (23:56 +0800)]
video: fbdev: uvesafb: Remove impossible code path in uvesafb_init_info
Because uvesafb_vbe_init will fail when get zero avaiable modes,
and we have checked the return value of uvesafb_vbe_init_mode,
so it is impossible to pass NULL as mode into uvesafb_init_info.
[ This patch fix warning report by fengguang.wu@intel.com
"drivers/video/fbdev/uvesafb.c:1509 uvesafb_init_info()
error: we previously assumed 'mode' could be null" ]
Signed-off-by: Wang YanQing <udknight@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Wang YanQing [Wed, 5 Mar 2014 15:54:18 +0000 (23:54 +0800)]
video: fbdev: uvesafb: Remove redundant NULL check in uvesafb_remove
Because uvesafb_par is allocated as part of fb_info in uvesafb_probe,
so we don't need to do NULL check for both fb_info and uvesafb_par in
uvesafb_remove.
[ This patch also fix a warning report by fengguang.wu@intel.com
"drivers/video/fbdev/uvesafb.c:1815 uvesafb_remove()
warn: variable dereferenced before check 'par'" ]
Signed-off-by: Wang YanQing <udknight@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add ABB device nodes for OMAP443x family of devices. abb_iva is
populated, but disabled as it is not used on current OMAP443x family,
but the node is used on OMAP446x family. Data is based on OMAP443x
Technical Reference Manual revision AN (April 2013).
ABB device nodes for OMAP4460 device Data is based on OMAP4460
Technical Reference Manual revision Z (April 2013)
[nm@ti.com: co-developer] Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: dts: omap5: added dt properties to adapt to the new phy framwork
Added device tree bindings for dwc3, usb2 and usb3 PHYs. The documentation
of these can be found at Documentation/devicetree/bindings/phy/phy-bindings.txt
and Documentation/devicetree/bindings/phy/ti-phy.txt.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
drivers/built-in.o: In function `ocfb_remove':
ocfb.c:(.text+0x27fee): undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `ocfb_probe':
ocfb.c:(.text+0x28418): undefined reference to `dma_alloc_coherent'
ocfb.c:(.text+0x284d2): undefined reference to `dma_free_coherent'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tomi Valkeinen [Wed, 10 Apr 2013 11:12:14 +0000 (14:12 +0300)]
OMAPDSS: convert pixel clock to common videomode style
omapdss has its own video-timings struct, but we want to move the common
videomode.
The first step is to change the omapdss's pixelclock unit from kHz to
Hz. Also, omapdss uses "pixel_clock" field name, whereas the common
videomode uses "pixelclock" field name. This patch changes the field
name also, as that makes it easy to spot any non-converted pixel_clock
uses.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Roger Quadros [Thu, 27 Feb 2014 14:18:31 +0000 (16:18 +0200)]
ARM: dts: Update echi-omap DT binding example usage
Remove non-compatible id from examples.
CC: Alan Stern <stern@rowland.harvard.edu> CC: Nishant Menon <nm@ti.com> CC: Kevin Hilman <khilman@linaro.org> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Roger Quadros [Thu, 27 Feb 2014 14:18:30 +0000 (16:18 +0200)]
ARM: dts: Get rid of incompatible ids for hci-omap USB host nodes
The OMAP EHCI and OHCI controllers are not compatible with drivers
other than "ti,ehci-omap" and "ti,ohci-omap3" respectively, so get
rid of the incompatible ids.
CC: Alan Stern <stern@rowland.harvard.edu> CC: Nishant Menon <nm@ti.com> CC: Kevin Hilman <khilman@linaro.org> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Pekon Gupta [Wed, 5 Feb 2014 13:28:34 +0000 (18:58 +0530)]
ARM: dts: am43xx: add support for parallel NAND flash
This patch:
- enables GPMC h/w and ELM h/w engine for AM43xx devices (am4372.dtsi)
- adds pinmux and DT node for Micron 4K-paged x8 NAND device (MT29F4G08AB)
present on following boards:
am43x-epos-evm:
On this board, NAND Flash control lines are muxed with QSPI, Thus only
one of the two can be used at a time. Selection is controlled by:
(a) dynamically driving following GPIO pin from software
GPMC_A0(GPIO) == 0 NAND is selected (default)
GPMC_A0(GPIO) == 1 eMMC is selected
Signed-off-by: Pekon Gupta <pekon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Pekon Gupta [Wed, 5 Feb 2014 13:28:32 +0000 (18:58 +0530)]
ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt
This patch updated MTD/NAND DT node binding to replace deprecated bindings
as per following commit.
commit ac65caf514ec3e55e8d3d510ee37f80dd97418fe
ARM: OMAP2+: cleaned-up DT support of various ECC schemes
Also Refer: Documentation/devicetree/bindings/mtd/gpmc-nand.txt
Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Pekon Gupta <pekon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
This patch has following updates, specific to MTD/NAND DT
- update MTD NAND partition table to keep compatibility between
different boards and mainline u-boot.
- prefix 'NAND.' in names of NAND device MTD partitions to differentiate them
from other MTD device partitions (like NOR and QSPI)
Partition_Name Partition_Size
/dev/mtd0 NAND.SPL 1 block-size*
/dev/mtd1 NAND.SPL.backup1 1 block-size*
/dev/mtd2 NAND.SPL.backup2 1 block-size*
/dev/mtd3 NAND.SPL.backup3 1 block-size*
/dev/mtd5 NAND.u-boot-spl-os 2 block-size* [for falcon boot]
/dev/mtd4 NAND.u-boot 1 MB
/dev/mtd6 NAND.u-boot-env 1 block-size*
/dev/mtd7 NAND.u-boot-env.backup1 1 block-size*
/dev/mtd8 NAND.kernel till 0xA00000
/dev/mtd9 NAND.file-system till end of device
* am335x-evm uses NAND device with block-size=128KiB
Signed-off-by: Pekon Gupta <pekon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Pekon Gupta [Wed, 5 Feb 2014 13:28:30 +0000 (18:58 +0530)]
ARM: OMAP2+: gpmc: update gpmc_hwecc_bch_capable() for new platforms and ECC schemes
This patch
- refactors gpmc_hwecc_bch_capable()
- add checks for new platforms like dra7xx, am43xx
- add checks for OMAP3 SoC, w.r.t. new ECC schemes spawned in following commit:
commit ac65caf514ec3e55e8d3d510ee37f80dd97418fe
ARM: OMAP2+: cleaned-up DT support of various ECC schemes
Signed-off-by: Pekon Gupta <pekon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
projects / linux-beck.git / log