| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Created a new platform driver for the platform device created by the
control module mfd core, wrt usb. This driver has API's to power on/off
the phy and the API's to write to musb mailbox.
(p.s. the mailbox for musb in omap4 is present in system control
module)
Change-Id: I3260e7e9b2091b75620b85ede5b2a09d097a9b37
[kishon@ti.com: wrote the original API's related to USB functions]
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Radhesh Fadnis <radhesh.fadnis@ti.com>
|
|
This patch introduces a MFD core device driver for
OMAP system control module.
The control module allows software control of
various static modes supported by the device. It is
composed of two control submodules: general control
module and device (padconfiguration) control
module.
In this patch, the children defined are for:
. USB-phy pin control
. Bangap temperature sensor
Device driver is probed with postcore_initcall.
However, as some of the APIs exposed by this driver
may be needed in very early init phase, an early init
class is also available: "early_omap_control".
Change-Id: I0e5a62508dbdfe0a677c9d833cf52474cd8b625e
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Radhesh Fadnis <radhesh.fadnis@ti.com>
|
|
If a buffer is passed in which is still being read by the GPU,
wait for it to become writable. If userspace takes care not
to pass in an in-use buffer, this will have no effect, but if
userspace does not know to synchronize with the GPU this will
prevent rendering artifacts resulting from writing a future
frame into a buffer the GPU is still reading.
Signed-off-by: Rob Clark <rob@ti.com>
|
|
Signed-off-by: Rob Clark <rob@ti.com>
|
|
Signed-off-by: Hervé Fache <h-fache@ti.com>
|
|
Signed-off-by: Hervé Fache <h-fache@ti.com>
|
|
Signed-off-by: Hervé Fache <h-fache@ti.com>
|
|
On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using
PM_WKEN1_CORE/PM_WKEN_PER regs.
Add api to control the module level wakeup mechanism from info provided from
hwmod data.
omap_hwmod_enable/disable_wakeup is used from serial.c which should
configure PM_WKEN register to enable or disable the module level wakeup.
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
|
|
During _reset of the (hwmod)device, the dmadisable is set so that it
does not prevent idling of the system. (NOTE: having dmadisable to 0,
prevents the system to idle)
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Huzefa Kankroliwala <huzefank@ti.com>
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
|
|
On OMAP4+, the clkdm association is moved to hwmod while on older OMAPs'
its associated with a clk.
Hence look for a clkdm in both clk and hwmod and warn only when
its missing in both. Also fix the pr_warning() to print the correct
hwmod name.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
|
|
Add an API to get main clock name associated with a given @oh.
This will avoid the need to construct fclk names during early
initialization in order to get fclk handle using clk_get().
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
|
|
Some functions like _omap4_disable_module() and _omap4_wait_target_disable()
are (will be) used on all OMAPs OMAP4 and beyond which support module level
control. Fix the error checks in these functions to return if called on
any platform pre OMAP4 (i.e OMAP2 and OMAP3) instead of checking for
!cpu_is_omap44xx(). This avoids having to update the error check with a
'&& !cpu_is_omap54xx()' when OMAP5 is introduced and possibly similar updates
when further OMAP generations are added.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
|
|
The regulators are usually defined in the board file, and support
has been added to publish the regulator data relevant to the
remote processor resource manager. This data would be used by the
generic rpmsg resmgr driver layer to request/release and control
a regulator on behalf of the remote processor through the rpmsg
resmgr framework.
Change-Id: I901b6c215d9307ea4a28ff191dcf1dec76233686
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
|
|
AESS device creation occurs only during initialization, hence fix below
modpost check warning by marking omap_init_aess() function as __init.
"WARNING: vmlinux.o(.text+0x1f2b0): Section mismatch in reference from the \
function omap_init_aess() to the function .init.text:omap_device_build()
The function omap_init_aess() references
the function __init omap_device_build().
This is often because omap_init_aess lacks a __init
annotation or the annotation of omap_device_build is wrong."
Change-Id: I8f21e687c1817de0e945ab716e9401449b4ec05a
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
|
|
Change-Id: I4db4159c0ca217268b7cce8ffdc5c3bbb82a85a8
Signed-off-by: Liam Girdwood <lrg@ti.com>
|
|
Extracts the device data from hwmod database and create a platform device
using omap device build.
The device build is done during postcore_initcall.
Change-Id: I153d9dd5f4139d43e408d8ed1b0c641868821623
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Radhesh Fadnis <radhesh.fadnis@ti.com>
|
|
Signed-off-by: Francois Mazard <f-mazard@ti.com>
Signed-off-by: Pierre Moos <p-moos@ti.com>
Signed-off-by: Sebastien Guirec <s-guiriec@ti.com>
|
|
Add McASP platform device for OMAP4/5
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
|
|
The current rpmsg resmgr implementation for auxclks is based on the
clock names being supplied from the remote processor. The number of
auxclks and the associated clock names can vary from one OMAP version
to another and are defined using clock data on the Linux-side.
This implemenation is changed to use ids so that the remote processor
code can remain agnostic of the clock names. The number and clock
names are published in the mach layer, and the generic rpmsg resmgr
omap layer queries the names associated with an id by using a
auxclk_lookup ops function defined in the MACH layer.
Change-Id: Ie7b7d4fa3d143d2d267a447805ba12305f2c8c61
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
There can be any number of different regulators that needs to be
controlled from the remote processor and these are specific to
each board. The corresponding mach layer provides a new op to get
the desired regulator data, and this can looked up using a platform
agnostic id.
The specific rprm regulator data has provision to identify whether
a regulator voltage is fixed or variable, and this info is used
accordingly in calling the regulator_set_voltage API.
Change-Id: I335fdc66eae1c4b2318074ec09d7d3441ad237b3
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
The Camera usecases require the ISS optional clock to be enabled
for complete functionality. This optional clock drives the CSI
interfaces required for the camera sensors.
The ISS request and release functions now properly enable and
disable the optional clock using the clock API directly and using
the name retrieved from the platform data.
Change-Id: I7f806b79aa86e6badfcd7abaf2ffaf334df29d97
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
We currently use regulator resource only for omap, and it has different
settings depending on the board being used. So, it is moved to the omap
resmgr file, where it can use the pdata in order to get the information
needed to work on different OMAP boards.
Change-Id: I25dabdb147679db1bb3a61ce106cd6475050822c
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
The ops supplied through the platform data for the omap
rpmsg resmgr driver is no longer containing only constraint
operations. The module local variable used to store this
has therefore been renamed appropriately to mach_ops.
Change-Id: I2963bdb9f7246f6d10fad8ef9ea1ef2d5d85bbc8
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
The rpmsg_recv_done manipulates the receive virtqueue to
process an incoming message. This function makes use of the
virtqueue_get_buf, virtqueue_add_buf and virtqueue_kick
Virtio APIs. These API require the caller to ensure that no
other virtqueue operations are called at the same time.
Mutex protection is therefore added around these calls on
the receive virtqueue.
This locking also resolves a racy condition with the current
receive path. The rpmsg_recv_done is executed in a kthread
context, meaning that multiple threads can execute the same
virtqueue function at the same time. In some cases, this is
causing 2 threads to execute the rpmsg_recv_done call for
two different messages, but results in acting on the same
buffer index maintained in the virtio driver, and throws
an error like,
virtio_rpmsg_bus virtio0: input:id 192 is not a head!
virtio_rpmsg_bus virtio0: uhm, incoming signal, but no used buffer
Change-Id: I57cc16ac78c504c3c146cf7b396a9272c0bc83fb
Signed-off-by: Chandra Sekhar.Anagani <chandu@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
This implements a new register ioctl specifically meant for sgx
buffers. rpmsg_omx clients are expected to call register ioctl
for the specific buffer type (ion or sgx) before sending a buffer
to .write for mapping. The registration allows the rpmsg_omx
driver to hold a reference to the ion buffers making up the sgx
buffer, thereby preventing the buffer(s) to be freed up from
under the remote processor.
The individual imported ion handles are expected to be passed
into the .write call.
When a client no longer expects remote processor to use the buffer,
client should call unregister ioctl. A separate unregister ioctl
for pvr buffers is not created, and the same ion unregister ioctl
is expected to be used for all the ion handles a sgx buffer is
comprised of.
Change-Id: I12d088851f259724e10bed642956bd263b19df1d
Signed-off-by: Tyler Luu <tluu@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
PVRExportFDToIONHandles was being called directly by rpmsg-omx.
This is now abstracted by ion and drivers should use
omap_ion_fd_to_handles instead.
Change-Id: Id9886d490e9730cfeac83a3602a7b4e91811e9b8
Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
Signed-off-by: Rodrigo Obregon <robregon@ti.com>
|
|
PVRExportFDToIONHandles was being called directly by rpmsg omx
driver. This is no more the case and hence PVR related header
can be removed.
Change-Id: Ied23ac3708fd297f5aa4b4080e2de494b80df401
Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
|
|
An omx object is created when opening the rpmsg-omx device. However
the "reply_arrived" completion event is not initialized until the
connection message is sent across.
When the rpmsg_omx driver is removed (like in recovery), all pending
threads waiting on the "reply_arrived" are unblocked by a complete_all
call, however, if the rpmsg-omx device was only opened, such event is
not initialized yet, so the complete_all call will dereference a null
object causing a panic.
This patch moves the initialization of the "reply_arrived" completion
event to the open call, after the allocation of the omx object.
Change-Id: Ia5ff93709ab5011cdfe0337173c286ad6d3ab209
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
|
|
The ION fd registration and deregistration ioctls has the
arguments reversed in the copy_to_user() calls. The same
has been fixed.
Also included a minor additional case for returning a NULL
ION handle back to user-space.
Change-Id: I9fbb481f55b003b421589af757319a3a3d54aa19
Signed-off-by: Tyler Luu <tluu@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
|
|
The error code, ENXIO is used in rpmsg_omx driver to indicate
a terminal error on the remote processor side. This status is
maintained during the recovery of the remote processor, while
the cdev gets reinitialized/recreated.
The rpmsg_omx's write file operation is currently not returning
this error. This has been added now to have it behave in the
same way as the read file operation.
Change-Id: Ic84427860381769019867fad87bbace09cfb1eb8
Signed-off-by: Vidhoon Viswanathan <vidhoon@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
|
|
Change-Id: Ic1d8d82f6bd366f39af2ef4cf9e58fc0614b21fd
Signed-off-by: David Schleef <ds@ti.com>
|
|
directory
The function omap_get_clk_by_name is not exported. Therefore, we will
have issue if we want to build omap_rpmsg_resmgr as a module. Now, this
called have been moved to mach-omap2/rpmsg_resmgr.c which is always
builtin. Now, ISS optional clock struct clk is exported as part of the
platform data to its omap driver.
Change-Id: I76dac4188f227af591733b02e965a892b5fccdf8
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
|
|
ISS needs an additional clock in order to enable the camera sensors
and become fully functional. This additional clock (iss_ctrlclk) is
different from the functional clock (iss_fck). The iss_fck is enabled
automatically through the device's pm_runtime_get_sync, but the opt
clock needs to be managed by the rpmsg resmgr driver. The name of this
this opt clock is published to the driver through the rpmsg resmgr
platform data.
Change-Id: I29f8aedd7cd8ca84be81b0e6c0d7cfcb7947a43d
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
Support has been added to the machine-specific rpmsg resmgr layer
to add the desired auxclk data for OMAP4 and OMAP5 devices. This
data will be used by the generic rpmsg resmgr layer through a
lookup_auxclk ops function. The data supplies the clock names for
the auxclk and its source's parent based on ids.
Change-Id: I2725ef2bb9ac0d5cdabb2364fc11ae3029b64c20
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
Support has been added to the machine-specific rpmsg resmgr layer
to retrieve and store the regulator data (defined in the board file).
A lookup_regulator op function is added to the mach-ops to retrieve
this data by the generic omap rpmsg resmgr layer based on the
regulator id.
Change-Id: I715e1b3c9f53a85bc785fcb42dfd8a7ce24d6131
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
as soon as possible as it is inappropriate to mess with clocks in this driver."
This reverts commit c9b84b5b766c7696116ef016e8820fdd91bdc764.
|
|
|
|
This reverts commit 93a3ee949d1999bc8ba2fd1d1d207cbbb76992e7.
|
|
|
|
|
|
Signed-off-by: Xavier Boudet <x-boudet@ti.com>
|
|
Signed-off-by: Xavier Boudet <x-boudet@ti.com>
|
|
Signed-off-by: Xavier Boudet <x-boudet@ti.com>
|
|
Signed-off-by: Xavier Boudet <x-boudet@ti.com>
|
|
Signed-off-by: Xavier Boudet <x-boudet@ti.com>
|
|
Signed-off-by: Xavier Boudet <x-boudet@ti.com>
|
|
Signed-off-by: Xavier Boudet <x-boudet@ti.com>
|
|
Signed-off-by: Sebastien Jan <s-jan@ti.com>
|
