From: Mythri P K mythr...@ti.com
1.Add some H/w indexable registers missed in definition.
2.Remove usage of struct hdmi_reg and use u16 instead.
3.Move the avi_infoframe parameters comments above the field.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
Hi,
On Fri, 2011-09-16 at 11:32 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
1.Add some H/w indexable registers missed in definition.
2.Remove usage of struct hdmi_reg and use u16 instead.
3.Move the avi_infoframe parameters comments above the field.
Please split this
On OMAP3, in order to enable alpha blending for LCD and TV managers, we needed
to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On
OMAP4, alpha blending is always enabled by default, if the above bits are set,
we switch to an OMAP3 compatibility mode where the zorder values
Add support for VIDEO3 pipeline on OMAP4:
- Add VIDEO3 pipeline information in dss_features and omapdss.h
- Add VIDEO3 pipeline register coefficients in dispc.h
- Create a new overlay structure corresponding to VIDEO3.
- Make changes in dispc.c for VIDEO3
Signed-off-by: Archit Taneja
Add zorder support on OMAP4, this feature allows deciding the visibility order
of the overlays based on the zorder value provided as an overlay info parameter
or a sysfs attribute of the overlay object.
Use the overlay cap OMAP_DSS_OVL_CAP_ZORDER to determine whether zorder is
supported for the
This contains support for VIDEO3 pipeline and zorder support for OMAP4 Display
controller.
This set originally had some more miscellaneous patches. Those patches have been
separated out and this set is created since it makes some trivial changes in the
omap_vout driver.
The patch set is based on
On Thursday 15 September 2011 07:02 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:51:57PM +0530, Rajendra Nayak wrote:
The TWL driver seems to set the default .valid_modes_mask to
(REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY) and .valid_ops_mask
to (REGULATOR_CHANGE_VOLTAGE |
On Thursday 15 September 2011 07:03 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:51:58PM +0530, Rajendra Nayak wrote:
The parameters to set_consumer_device_supply() can be considered
invalid (and hence it could return -EINVAL) if nether consumer_dev nor
consumer_dev_name are passed, not
On Thursday 15 September 2011 07:14 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:
.../devicetree/bindings/regulator/regulator.txt| 37 +
drivers/of/Kconfig |6 ++
drivers/of/Makefile
On Thursday 15 September 2011 07:16 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
+Required properties:
+- compatible: Must be regulator,ti,twl-reg;
I'd expect listings for the specific chips too.
I just did'nt do that because we have just one driver
On Thursday 15 September 2011 07:20 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:02PM +0530, Rajendra Nayak wrote:
.../devicetree/bindings/regulator/regulator.txt| 19
drivers/of/of_regulator.c | 31
On Friday 16 September 2011 04:33 AM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:50:35PM -0600, Grant Likely wrote:
We've got two competing approaches here. For reg and interrupts, the
proposal on the table that we talked about at LPC is to do reg-names
and interrupts-names so as to
On Thursday 15 September 2011 07:29 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:06PM +0530, Rajendra Nayak wrote:
+#ifdef CONFIG_OF
+ struct device_node *node;
+ node = of_get_regulator(dev, id);
+ if (!node)
+ goto out;
+ list_for_each_entry(rdev,
On Thursday 15 September 2011 07:51 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:07PM +0530, Rajendra Nayak wrote:
of_regulator_register_devices() registers all regulators
as platform devices. Use this to register all twl regulators
from the twl driver probe.
Regulators can be devices
On Friday 16 September 2011 03:42 AM, Grant Likely wrote:
On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure passed from device tree.
'consumer_supplies' which is part of
On Friday 16 September 2011 03:48 AM, Grant Likely wrote:
On Thu, Sep 15, 2011 at 04:52:01PM +0530, Rajendra Nayak wrote:
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
On Fri, Sep 16, 2011 at 11:17 AM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Fri, Sep 16, 2011 at 6:10 AM, Frank Rowand frank.row...@am.sony.com
wrote:
On 09/15/11 06:22, Keshava Munegowda wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs core driver does not
On Fri, Sep 16, 2011 at 12:41:53PM +0530, Rajendra Nayak wrote:
On Thursday 15 September 2011 07:02 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:51:57PM +0530, Rajendra Nayak wrote:
There is no need for all the board files to pass this information
additionally, when the driver already
On Fri, Sep 16, 2011 at 12:45:55PM +0530, Rajendra Nayak wrote:
On Thursday 15 September 2011 07:14 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:
+- apply-uV: apply uV constraint if min == max
This seems a bit Linux/runtime policy specific (especially
On Fri, Sep 16, 2011 at 12:47:05PM +0530, Rajendra Nayak wrote:
On Thursday 15 September 2011 07:16 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
+Required properties:
+- compatible: Must be regulator,ti,twl-reg;
I'd expect listings for the specific
On Fri, Sep 16, 2011 at 12:49:17PM +0530, Rajendra Nayak wrote:
On Thursday 15 September 2011 07:20 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:02PM +0530, Rajendra Nayak wrote:
+# For fixed voltage regulators
+- supply-name: Name of the regulator supply
+- microvolts: Output voltage
On Fri, Sep 16, 2011 at 12:51:06PM +0530, Rajendra Nayak wrote:
On Thursday 15 September 2011 07:29 PM, Mark Brown wrote:
This seems wrong, why are we adding things to the regulator_map which is
really only there for lookups when we already did the lookup using the
device tree?
I did this
On Friday 16 September 2011 02:27 PM, Mark Brown wrote:
On Fri, Sep 16, 2011 at 12:41:53PM +0530, Rajendra Nayak wrote:
On Thursday 15 September 2011 07:02 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:51:57PM +0530, Rajendra Nayak wrote:
There is no need for all the board files to pass
On Friday 16 September 2011 02:30 PM, Mark Brown wrote:
On Fri, Sep 16, 2011 at 12:47:05PM +0530, Rajendra Nayak wrote:
On Thursday 15 September 2011 07:16 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
+Required properties:
+- compatible: Must be
On Friday 16 September 2011 02:31 PM, Mark Brown wrote:
On Fri, Sep 16, 2011 at 12:49:17PM +0530, Rajendra Nayak wrote:
On Thursday 15 September 2011 07:20 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:02PM +0530, Rajendra Nayak wrote:
+# For fixed voltage regulators
+- supply-name:
[...]
1. Modify the inline access functions to take the PEND and others
if needed registers as a parameter
2. Modify mach-omap2/timer.c to initialize the PEND and others
in the SoC specific timer_init function
Just to make my understanding complete, need some clarifications:
As we would
Hello.
On 15-09-2011 18:19, Kishon Vijay Abraham I wrote:
Setting OTG_INTERFSEL to UTMI interferes with charger detection resulting
in incorrect detection of charger type. Hence OTG_INTERFSEL is configured to
ULPI initially and changed to UTMI only after receiving USB_EVENT_ID or
On Fri, Sep 16, 2011 at 12:54:18PM +0530, Rajendra Nayak wrote:
On Friday 16 September 2011 03:42 AM, Grant Likely wrote:
However, I can imagine it possible for a regulator to have multiple
parents. It may just be better to go with something like the gpio
scheme ofphandle gpio-specifier
On Thu, Sep 15, 2011 at 1:45 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
This doesn't work on platforms that may have more than one possible
iommu driver, like x86 for example.
Ok.
Acked-by: Ohad Ben-Cohen o...@wizery.com
(cc'ing Laurent for the VIDEO_OMAP3 part)
--
To unsubscribe from this
This set includes patches which do the following:
- Fix crash if a we call dssdev-driver-update for a disabled panel.
- Fix the issue of not being able to request for a buffer which is larger than
what we did the last time.
- Fix a small bug in omap_vout_isr()
- Remove some redundant code in
The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf and mmap
prevent
requesting a larger size buffer than what is allocated at kernel boot during
omap_vout_probe.
The requested size is compared with vout-buffer_size, this isn't correct as
vout-buffer_size is later set to the size
Currently, there is a lot of redundant code is between DPI and VENC panels, this
can be made common by moving out field/interlace specific code to a separate
function called omapvid_handle_interlace_display(). There is no functional
change made.
Signed-off-by: Archit Taneja arc...@ti.com
---
Currently, in omap_vout_isr(), if the panel type is DPI, and if we
get either VSYNC or VSYNC2 interrupts, we proceed ahead to set the
current buffers state to VIDEOBUF_DONE and prepare to display the
next frame in the queue.
On OMAP4, because we have 2 LCD managers, the panel type itself is not
Add support for DSI panels. DSI video mode panels will work directly. For
command mode panels, we will need to trigger updates regularly. This isn't done
by the omap_vout driver currently. It can still be supported if we connect a
framebuffer device to the panel and configure it in auto update
Remove the code in omap_vout_probe() which calls display-driver-update() for
all the displays. This isn't correct because:
- An update in probe doesn't make sense, because we don't have any valid content
to show at this time.
- Calling update for a panel which isn't enabled is not supported by
Hi Kevin,
On 9/2/2011 4:25 PM, Cousson, Benoit wrote:
Most devices are using the same default omap_device_pm_latency structure
during device built. In order to avoid the duplication of the same
structure everywhere, add a default structure that will be used if
the device does not have an
On Fri, Sep 16, 2011 at 1:30 AM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Fri, Sep 16, 2011 at 1:13 AM, Tony Lindgren t...@atomide.com wrote:
* Shilimkar, Santosh santosh.shilim...@ti.com [110915 10:49]:
On Thu, Sep 15, 2011 at 11:23 PM, Tony Lindgren t...@atomide.com wrote:
Hi,
On Thu, Sep 15, 2011 at 12:02 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2011-09-15 at 11:54 +0530, K, Mythri P wrote:
Hi,
On Thu, Sep 15, 2011 at 11:27 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Thu, 2011-09-15 at 11:11 +0530, K, Mythri P wrote:
Hi,
On Wed,
Hi,
Sorry for the delayed response.
From: Laurent Pinchart [laurent.pinch...@ideasonboard.com]
Sent: Thursday, September 08, 2011 10:51 PM
To: Ravi, Deepthy
Cc: linux-me...@vger.kernel.org; t...@atomide.com; li...@arm.linux.org.uk;
Hi Deepthy,
On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote:
On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote:
On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote:
From: Vaibhav Hiremath hvaib...@ti.com
In order to support TVP5146 (for that matter any
I am owning a ZOOM am3517evm evaluation board, where I want to run the
latest linux kernel (mainline).
I am not able to boot this board. Are there any patches to fix this
issues? The deliverd kernel (2.6.32-psp09.00.01.06.sdk)
boots fine.
You're not alone. This platform is not completely
Sergei,
Thanks for your comments.
On Fri, Sep 16, 2011 at 3:18 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 15-09-2011 18:19, Kishon Vijay Abraham I wrote:
Setting OTG_INTERFSEL to UTMI interferes with charger detection resulting
in incorrect detection of charger type. Hence
On Fri, Sep 16, 2011 at 07:21:41PM +0530, ABRAHAM, KISHON VIJAY wrote:
Sergei,
Thanks for your comments.
On Fri, Sep 16, 2011 at 3:18 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 15-09-2011 18:19, Kishon Vijay Abraham I wrote:
Setting OTG_INTERFSEL to UTMI interferes
Hi Kevin,
This is the updated version of the initial series that introduced a
notifier in order to create an omap_device from a platform_device bound
to DT node as suggested by Grant.
For the moment, the informations are all extracted from the hwmod data.
The idea is to focus first on the
Split the omap_device_build_ss into two smaller functions
that will allow to populate a platform_device already allocated by
device-tree.
The functionality of the omap_device_build_ss is still the same, but
the omap_device_alloc will be usable with devices already built by
device-tree.
Add a notifier called during device_add phase. If an of_node is present,
retrieve the hwmod entry in order to populate properly the omap_device
structure.
For the moment the resource from the device-tree are overloaded.
DT does not support named resource yet, and thus, most driver
will not work
Kevin,
On Fri, Sep 16, 2011 at 12:46 AM, Kevin Hilman khil...@ti.com wrote:
Hi Jean,
Jean Pihet jean.pi...@newoldbits.com writes:
Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat
API to the new PM QoS API.
Since the constraint is on the MPU subsystem, use the
Hi Sricharan,
On 9/9/2011 6:02 PM, R, Sricharan wrote:
The address spaces, irqs and dma reqs count API returns the
number of corresponding entries in a hwmod including a additional
null value or a -1 terminator in the structure introduced
recently. More information here:
212738a4
Kevin,
On Fri, Sep 16, 2011 at 1:47 AM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints to the
underlying layer by calling the
Jean Pihet jean.pi...@newoldbits.com writes:
Kevin,
On Fri, Sep 16, 2011 at 1:47 AM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the
OMAP mux now provides a service routine to parse pending wakeup events
and to call registered ISR whenever active wakeups are detected. This
routine is called directly from PRCM interrupt handler.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/mux.c | 38
PM interrupt handling is now done through the PRCM chain handler. The
interrupt handling logic is also split in two parts, to server IO and
WKUP events separately. This allows us to handle IO chain events in a
clean way.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c
Just for PRCM chain handler testing purposes. This should be replaced with
a proper implementation.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/serial.c | 71 -
1 files changed, 69 insertions(+), 2 deletions(-)
diff --git
This is no longer needed as it will be handled within serial driver itself.
This part should be properly handled with serial runtime support.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 19 ---
1 files
Hello,
This patch set is the version 8 for the OMAP PRCM chain interrupt handler.
The driver is providing a chain handler for PRCM interrupt events, which
can be then individually used by different drivers. Currently PRCM interrupt
is owned by the PM core code and it is impossible for other users
This patch is just a temporary hack to allow serial to work properly with
the PRCM chain handler. Should be replaced with a proper implementation
by serial runtime PM support.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |
From: R, Govindraj govindraj.r...@ti.com
Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.
Use the wakeup_enable flag and enable wakeup capability
for the given pads. Wakeup capability will be enabled/disabled
These are no longer needed as omap_hwmod takes care of multiplexing of pads.
Should be handled properly with serial runtime PM support patches.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 25 +
1
This driver will eventually support OMAP soc PRM module features, e.g. PRCM
chain interrupts.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
drivers/power/Kconfig|7
drivers/power/Makefile |1 +
This patch is temporary until Benoit can provide final version.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 65
1 files changed, 65 insertions(+), 0 deletions(-)
diff --git
From: R, Govindraj govindraj.r...@ti.com
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/mux.c| 30 ++
arch/arm/mach-omap2/mux.h
Introduce a chained interrupt handler mechanism for the PRCM
interrupt, so that individual PRCM event can cleanly be handled by
handlers in separate drivers. We do this by introducing PRCM event
names, which are then matched to the particular PRCM interrupt bit
depending on the specific OMAP SoC
Temporary testing related patch, not meant for integration.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
Temporary patch for testing purposes, not meant for integration.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/mux.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 9127273..5b38f1e 100644
This patch is temporary until Paul can provide a final version.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 56
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git
This is handled automatically by the PRCM chain interrupt mechanism now.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index
Prevents a hang when omap_device would want to print something for
serial console device while enabling / disabling its clocks.
Should be handled properly by serial runtime PM support.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
---
Jean Pihet jean.pi...@newoldbits.com writes:
Kevin,
On Fri, Sep 16, 2011 at 12:46 AM, Kevin Hilman khil...@ti.com wrote:
Hi Jean,
Jean Pihet jean.pi...@newoldbits.com writes:
Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat
API to the new PM QoS API.
Since the
During the idle/suspend path, we expect the console lock to be held so
that no console output is done during/after the UARTs are idled.
However, when using the no_console_suspend argument on the
command-line, the console driver does not take the console lock. This
allows the possibility of
Cousson, Benoit b-cous...@ti.com writes:
Hi Kevin,
On 9/2/2011 4:25 PM, Cousson, Benoit wrote:
Most devices are using the same default omap_device_pm_latency structure
during device built. In order to avoid the duplication of the same
structure everywhere, add a default structure that will
Tony,
Please pull the following PM cleanups for v3.2
Kevin
The following changes since commit fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c:
Linux 3.1-rc3 (2011-08-22 11:42:53 -0700)
are available in the git repository at:
git://gitorious.org/khilman/linux-omap-pm.git for_3.2/pm-cleanup
Santosh Shilimkar santosh.shilim...@ti.com writes:
When MPUSS hits off-mode e, L2 cache is lost. This patch adds L2X0
^^^
extra 'e' ?
necessary maintenance operations and context restoration in the
low power code.
Signed-off-by: Santosh Shilimkar
Hi Santosh,
Santosh Shilimkar santosh.shilim...@ti.com writes:
Add OMAP4 CPUIDLE support. CPU1 is left with defualt idle and
the low power state for it is managed via cpu-hotplug.
This patch adds MPUSS low power states in cpuidle.
C1 - CPU0 ON + CPU1 ON + MPU ON
C2 - CPU0 OFF
From: Jon Hunter jon-hun...@ti.com
Various clock fixes for OMAP3 and OMAP4 devices.
Jon Hunter (4):
OMAP4: Add missing clock divider for OCP_ABE_ICLK
OMAP3+: use DPLLs recalc function instead of omap2_get_dpll_rate
OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices
OMAP4:
On 09/16/11 00:31, Munegowda, Keshava wrote:
On Fri, Sep 16, 2011 at 11:17 AM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Fri, Sep 16, 2011 at 6:10 AM, Frank Rowand frank.row...@am.sony.com
wrote:
On 09/15/11 06:22, Keshava Munegowda wrote:
From: Keshava Munegowda
From: Jon Hunter jon-hun...@ti.com
The parent clock of the OCP_ABE_ICLK is the AESS_FCLK and the
parent clock of the AESS_FCLK is the ABE_FCLK...
ABE_FCLK -- AESS_FCLK -- OCP_ABE_ICLK
The AESS_FCLK and OCP_ABE_ICLK clocks both have dividers which
determine their operational frequency. However,
From: Mike Turquette mturque...@ti.com
OMAP4 DPLL_ABE can enable a 4X multipler on top of the normal MN multipler
and divider. This is achieved by setting CM_CLKMODE_DPLL_ABE.DPLL_REGM4XEN
bit in CKGEN module of CM1. From the OMAP4 TRM:
Fdpll = Fref x 2 x (4 x M/(N+1)) in case REGM4XEN bit field
From: Mike Turquette mturque...@ti.com
omap3_noncore_dpll_set_rate uses omap2_dpll_round_rate explicitly. Instead
use the struct clk pointer's round_rate function to allow for DPLL's with
special needs.
Also the rounded rate can differ from target rate, so to better reflect
reality set clk-rate
From: Jon Hunter jon-hun...@ti.com
This is a continuation of Mike Turquette's patch OMAP3+: use
DPLL's round_rate when setting rate.
omap3_noncore_dpll_set_rate() and omap3_noncore_dpll_enable() call
omap2_get_dpll_rate() explicitly. It may be necessary for some
DPLLs to use a different function
From: Jon Hunter jon-hun...@ti.com
The OMAP36xx and OMAP4xxx DPLLs have a different internal reference
clock frequency (fint) operating range than OMAP3430. Update the
dpll_test_fint() function to check for the correct frequency ranges
for OMAP36xx and OMAP4xxx.
For OMAP36xx and OMAP4xxx
From: Jon Hunter jon-hun...@ti.com
Currently the interface clocks for the two SLIMBUS peripherals are
named slimbus1_fck and slimbus2_fck. Rename these clocks to be
slimbus1_ick and slimbus2_ick so it is clear that these are
interface clocks and not functional clocks.
Signed-off-by: Jon Hunter
v2-v3:
- s/KB/KiB/ (David W)
v1-v2:
- split to patches (by keeping the old code around until all drivers are
converted) (Joerg)
Ohad Ben-Cohen (6):
iommu/core: split mapping to page sizes as supported by the hardware
iommu/omap: announce supported page sizes
iommu/msm: announce
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to
Let the IOMMU core know we support 4KiB, 64KiB, 1MiB and 16MiB page sizes.
This way the IOMMU core can split any arbitrary-sized physically
contiguous regions (that it needs to map) as needed.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: David Brown dav...@codeaurora.org
Cc: Stepan
Let the IOMMU core know we support arbitrary page sizes (as long as
they're an order of 4KiB).
This way the IOMMU core will retain the existing behavior we're used to;
it will let us map regions that:
- their size is an order of 4KiB
- they are naturally aligned
Signed-off-by: Ohad Ben-Cohen
Let the IOMMU core know we support arbitrary page sizes (as long as
they're an order of 4KiB).
This way the IOMMU core will retain the existing behavior we're used to;
it will let us map regions that:
- their size is an order of 4KiB
- they are naturally aligned
Note: Intel IOMMU hardware
Let the IOMMU core know we support 4KiB, 64KiB, 1MiB and 16MiB page sizes.
This way the IOMMU core can split any arbitrary-sized physically
contiguous regions (that it needs to map) as needed.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Hiroshi DOYU hiroshi.d...@nokia.com
---
Now that all IOMMU drivers are converted to the new
register_iommu_pgsize() API, the old code can be removed, and
we can s/register_iommu_pgsize/register_iommu/.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Joerg Roedel joerg.roe...@amd.com
Cc: David Woodhouse dw...@infradead.org
Cc: David
Santosh Shilimkar santosh.shilim...@ti.com writes:
Fix the address overlap with Emulation domain (EMU).
The previous mapping was entering into EMU mapping
and was not as per comments. Fix the mapping accordingly.
[giris...@ti.com: Helped fixing comments.]
Signed-off-by: Girish S G
Jean Pihet jean.pi...@newoldbits.com writes:
When a PM QoS device latency constraint is requested or removed the
PM QoS layer notifies the underlying layer with the updated aggregated
constraint value. The constraint is stored in the powerdomain constraints
list and then applied to the
On Fri, Sep 16, 2011 at 6:33 PM, Peter Lyon lordva...@gmail.com wrote:
With kernel.org down for maintenance, what is the recommended git
mirror to use instead of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git?
Mainline is temporarily available at
* DebBarma, Tarun Kanti tarun.ka...@ti.com [110916 01:56]:
[...]
1. Modify the inline access functions to take the PEND and others
if needed registers as a parameter
2. Modify mach-omap2/timer.c to initialize the PEND and others
in the SoC specific timer_init function
Just to
Hi Arnd,
Please pull the first part of omap cleanup from:
git://github.com/tmlind/linux.git cleanup
This series cleans up early_init functions and removes
CHIP_IS macro usage. This makes it easier to have SoC
specific init functions so adding support for new omap
variants does not require
Hi Arnd,
Please pull omap voltage cleanup series:
git://github.com/tmlind/linux.git voltage
This has a dependency to the cleanup part 1 series. As
this contains some voltage fixes too, it's a separate
series. You can either pull it into cleanup or keep it
separate.
Regards,
Tony
The
94 matches
Mail list logo
