On 09/01/2011 08:46 PM, Kevin Hilman wrote:
javier Martinjavier.mar...@vista-silicon.com writes:
Hi Kevin,
thanks for your help.
CPU is staying in C0 probably because UARTs are not being idled, so SoC
cannot hit deeper idle states. Try the following at the command line to
to enable UART
On Friday 02 September 2011 11:02 AM, Valkeinen, Tomi wrote:
On Fri, 2011-09-02 at 10:45 +0530, Archit Taneja wrote:
Hi,
On Thursday 01 September 2011 06:44 PM, Valkeinen, Tomi wrote:
On Tue, 2011-08-30 at 16:21 +0530, Archit Taneja wrote:
Add initial support for DSI video mode panels:
- Add
Hi,
On Monday 22 August 2011 01:56 PM, Valkeinen, Tomi wrote:
OMAP DSS normally gets power from VCXIO on OMAP4. Add configuration for
this into twl-common.c
Mark VCXIO as always_on, as VCXIO is used by multiple components,
including the MPU, and turning it off when DSS doesn't need it would
On Monday 22 August 2011 01:57 PM, Valkeinen, Tomi wrote:
Currently when changing the manager of an overlay, set_manager() directly
calls dispc to set the overlay's destination.
Change this to be more in line with other overlay configurations, and
this will also remove the need to have dispc
On Wednesday 31 August 2011 06:51 PM, Valkeinen, Tomi wrote:
The current driver had a hardcoded minimum value of 2 for pixel clock
divisor (PCD). This doesn't seem to be right.
OMAP4 TRM says that PCD can be 1 when not downscaling, and inverted
pixel clock (IPC) is off.
OMAP3 TRM says the
Hi Paul,
On Thursday 01 September 2011 05:30 AM, Paul Walmsley wrote:
Hi,
a comment:
On Wed, 31 Aug 2011, Keerthy wrote:
div_ts_ck feeds only the temperature sensor functional clock
and also has a clksel associated (for divider selection). Mapping this
as the functional clock for the
On 2 September 2011 08:05, Jarkko Nikula jarkko.nik...@bitmer.com wrote:
Other usual things to check that display is off (echo 1
/sys/class/graphics/fb0/blank) and no cable to musb/otg port.
Haven't tried myself with recent kernel but does EHCI and hub on XM let to
idle cpu at all? At least
On Fri, 2011-09-02 at 12:20 +0530, Archit Taneja wrote:
On Monday 22 August 2011 01:57 PM, Valkeinen, Tomi wrote:
Currently when changing the manager of an overlay, set_manager()
directly
calls dispc to set the overlay's destination.
Change this to be more in line with other overlay
Ming Lei, Thomas,
Sorry if it is a bit late to jump in.
On Mon, Aug 22, 2011 at 10:27 AM, Thomas Renninger tr...@suse.de wrote:
On Saturday, August 20, 2011 04:40:09 AM Ming Lei wrote:
Hi,
2011/8/20 Thomas Renninger tr...@suse.de:
On Friday, August 19, 2011 05:04:04 PM
On Friday 02 September 2011 12:55 PM, Valkeinen, Tomi wrote:
On Fri, 2011-09-02 at 12:20 +0530, Archit Taneja wrote:
On Monday 22 August 2011 01:57 PM, Valkeinen, Tomi wrote:
Currently when changing the manager of an overlay, set_manager()
directly
calls dispc to set the overlay's
Hi,
On Fri, Sep 2, 2011 at 3:26 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
It was known that cpu_id is always the current cpu with current
implementation when this got introduced.
But the perf events API must not change back and forth for userspace
compatibility. Therefore the cpu_id was
On Fri, 2011-09-02 at 12:10 +0530, Archit Taneja wrote:
Hi,
On Monday 22 August 2011 01:56 PM, Valkeinen, Tomi wrote:
OMAP DSS normally gets power from VCXIO on OMAP4. Add configuration
for
this into twl-common.c
Mark VCXIO as always_on, as VCXIO is used by multiple components,
Hi,
* Benoit Cousson b-cous...@ti.com [110901 19:52]:
Create an OMAP3 generic board to start the DT migration.
I don't think this needs to be SoC specific, we can add multiple
DT_MACHINE_START entries into a single file. So it should be
just board-omap-dt.c.
+#include mux.h
+#include
* Benoit Cousson b-cous...@ti.com [110901 19:52]:
In order to avoid conflict with the new board-omap3-dt.c file,
remove the .dt_compat entry from the beagle regular board
file.
Any DT work for OMAP3 will have to be done on the generic DT
board file to avoid breaking the legacy board support
Hi Tony,
On 9/2/2011 10:09 AM, Tony Lindgren wrote:
Hi,
* Benoit Coussonb-cous...@ti.com [110901 19:52]:
Create an OMAP3 generic board to start the DT migration.
I don't think this needs to be SoC specific, we can add multiple
DT_MACHINE_START entries into a single file. So it should be
On 9/2/2011 10:12 AM, Tony Lindgren wrote:
* Benoit Coussonb-cous...@ti.com [110901 19:52]:
In order to avoid conflict with the new board-omap3-dt.c file,
remove the .dt_compat entry from the beagle regular board
file.
Any DT work for OMAP3 will have to be done on the generic DT
board file to
On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
Now, that kernel.org is back, I'll pull you branches :-).
Umm. Are you sure? What are you checking - that some kernel.org
servers are reachable or that master.kernel.org is reachable (it
isn't.)
--
To unsubscribe from this list:
On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote:
On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
Now, that kernel.org is back, I'll pull you branches :-).
Umm. Are you sure? What are you checking - that some kernel.org
servers are reachable or that master.kernel.org is
On Fri, 2011-09-02 at 11:43 +0530, Archit Taneja wrote:
Sending a null packet to start the DDR clk is rather OMAP specific
internal thing, so I don't want to require the panel driver to need
to
know that it must send a null packet to start the clock. So if the
ddr
clk is not started
On Thu, 2011-09-01 at 15:05 +0200, Thomas Weber wrote:
Add support for Innolux AT070TN83, a 7 inch LCD
with RGB-Interface and touch panel to panel-generic-dpi.
Tested with Devkit8000.
Signed-off-by: Thomas Weber we...@corscience.de
---
drivers/video/omap2/displays/panel-generic-dpi.c |
Hi Tero,
On Thu, 1 Sep 2011, Tero Kristo wrote:
I've been looking at this now and got one question below. Otherwise your
comments look okay to me and I can work with those.
Great. As you work on it, please let me know if there's something that
doesn't make sense with this arrangement. I
On Fri, Sep 02, 2011 at 11:13:03AM +0200, Cousson, Benoit wrote:
On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote:
On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
Now, that kernel.org is back, I'll pull you branches :-).
Umm. Are you sure? What are you checking - that
On 9/2/2011 11:21 AM, Russell King - ARM Linux wrote:
On Fri, Sep 02, 2011 at 11:13:03AM +0200, Cousson, Benoit wrote:
On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote:
On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
Now, that kernel.org is back, I'll pull you branches
On 01/09/11 20:08, Stephen Warren wrote:
Marc Dietich wrote at Thursday, September 01, 2011 5:14 AM:
I'll add Stephen Warren from NVIDIA to the CC list. He has more HW to test
on.
Here are the results I found:
Harmony:
Tegra USB3 - SMSC9514 hub: NOT affected
(Unplugging LAN cable, or
* Cousson, Benoit b-cous...@ti.com [110902 11:13]:
Hi Tony,
On 9/2/2011 10:09 AM, Tony Lindgren wrote:
Hi,
* Benoit Coussonb-cous...@ti.com [110901 19:52]:
Create an OMAP3 generic board to start the DT migration.
I don't think this needs to be SoC specific, we can add multiple
* Cousson, Benoit b-cous...@ti.com [110902 11:26]:
On 9/2/2011 10:12 AM, Tony Lindgren wrote:
* Benoit Coussonb-cous...@ti.com [110901 19:52]:
In order to avoid conflict with the new board-omap3-dt.c file,
remove the .dt_compat entry from the beagle regular board
file.
Any DT work for
* Grazvydas Ignotas nota...@gmail.com [110715 12:27]:
On Wed, Jul 13, 2011 at 6:36 PM, Chris Ball c...@laptop.org wrote:
Hi,
On Wed, Jul 13 2011, Grazvydas Ignotas wrote:
it seems this series got lost in time, at least patches 01, 02, 03,
04, 05, 06, 07, 08, 12 look like valid
From: Mythri P K mythr...@ti.com
HDMI IP block is common between TI OMAP4 Procerssor and Netra processor although
the Display subsytem is different.Also the IP block in future OMAP may differ
from the one existing in OMAP4. Thus to reuse the code between these two
processors , and maintain the
From: Mythri P K mythr...@ti.com
Define HDMI timings structure for hdmi.c to use instead of OMAP DSS timing
strucutre, As hdmi has few additional parameters such as vsync and hsync
polarity which is missing in DSS timing structure.
Signed-off-by: Mythri P K mythr...@ti.com
---
From: Mythri P K mythr...@ti.com
Functions that are included in HDMI IP driver is renamed to have IP specific
names so that it will not conflict with similar functions from other IP.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c| 18
From: Mythri P K mythr...@ti.com
Clean up to move the EDID definition to hdmi.c from the header file which is IP
dependent.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 10 ++
drivers/video/omap2/dss/hdmi.h | 10 --
2 files changed, 10
From: Mythri P K mythr...@ti.com
Some of the header file definitions that are there in the hdmi.h are generic
and can be used across OMAP's, Thus moving generic definition to new file.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dss.h | 18 ---
From: Mythri P K mythr...@ti.com
As the pll and the video configuration info are part of the ip_data those
structures are moved to the ip_data structure. Also the functions are modified
accordingly to take care of this movement.
Signed-off-by: Mythri P K mythr...@ti.com
---
From: Mythri P K mythr...@ti.com
Some of the header file definitions of HDMI IP are needed by audio driver thus
moving the common defintion to more generic location Include/video.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c |2 +-
From: Mythri P K mythr...@ti.com
To make the current hdmi DSS driver compatible with future OMAP having
different IP blocks( A combination of different core, PHY, PLL blocks),
Add HDMI hdmi functions as a function pointer in dss_features to abstract
hdmi dss driver IP agnostic, hdmi dss driver
From: Mythri P K mythr...@ti.com
As the panel driver will remain generic across OMAP's renaming it to
hdmi_panel.c
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/Makefile |2 +-
.../omap2/dss/{hdmi_omap4_panel.c = hdmi_panel.c} |2 +-
2 files
From: Mythri P K mythr...@ti.com
As the base_address of the HDMI might differ across SoC's, offset of the HDMI
logical blocks and base address got from the platform data are passed
dynamically to the functions that modify HDMI IP registers.
Signed-off-by: Mythri P K mythr...@ti.com
---
From: Mythri P K mythr...@ti.com
Splitting HDMI IP dependent IP configuring code from HDMI DSS dependent code and
moving to a new IP file.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/Makefile |2 +-
drivers/video/omap2/dss/hdmi.c
just another measurement point
Stephen Warren wrote at Thursday:
Here are the results I found:
Harmony:
Tegra USB3 - SMSC9514 hub: NOT affected
(Unplugging LAN cable, or disabling SMSC9514 LAN driver doesn't change
this)
Seaboard (springbank; clamshell):
Tegra USB1 - no hub: Affected
Hi,
On Mon, Aug 29, 2011 at 03:16:55PM +0530, Gupta, Ajay Kumar wrote:
I have compiled the differences in the register map between am35x and
ti81xx and they are listed below.
===
Register am35x [has
On 9/2/2011 12:43 PM, Tony Lindgren wrote:
* Cousson, Benoitb-cous...@ti.com [110902 11:13]:
Hi Tony,
On 9/2/2011 10:09 AM, Tony Lindgren wrote:
Hi,
* Benoit Coussonb-cous...@ti.com [110901 19:52]:
Create an OMAP3 generic board to start the DT migration.
I don't think this needs to be
* Cousson, Benoit b-cous...@ti.com [110902 14:10]:
On 9/2/2011 12:43 PM, Tony Lindgren wrote:
* Cousson, Benoitb-cous...@ti.com [110902 11:13]:
Hi Tony,
On 9/2/2011 10:09 AM, Tony Lindgren wrote:
Hi,
* Benoit Coussonb-cous...@ti.com [110901 19:52]:
Create an OMAP3 generic board
On Wed, 2011-08-31 at 18:49 +0200, Arnd Bergmann wrote:
On Monday 29 August 2011, Luciano Coelho wrote:
From: Randy Dunlap rdun...@xenotime.net
Combine MFD_SUPPORT (which only enabled the remainder of the MFD
menu) and MFD_CORE. This allows other drivers to select MFD_CORE
without
Hi Paul,
On Fri, 2011-09-02 at 11:20 +0200, Paul Walmsley wrote:
Hi Tero,
On Thu, 1 Sep 2011, Tero Kristo wrote:
I've been looking at this now and got one question below. Otherwise your
comments look okay to me and I can work with those.
Great. As you work on it, please let me know
On 9/2/2011 1:57 PM, Tony Lindgren wrote:
* Cousson, Benoitb-cous...@ti.com [110902 14:10]:
On 9/2/2011 12:43 PM, Tony Lindgren wrote:
* Cousson, Benoitb-cous...@ti.com [110902 11:13]:
Hi Tony,
On 9/2/2011 10:09 AM, Tony Lindgren wrote:
Hi,
* Benoit Coussonb-cous...@ti.com[110901
* Cousson, Benoit b-cous...@ti.com [110902 14:47]:
.tap= OMAP2_L4_IO_ADDRESS(0x4900a000),
BTW, how can we get rid of that OMAP2_L4_IO_ADDRESS?
That needs to be mapped early for SoC detection to work
for cpu_is_omap stuff :(
In fact only the tap should be required at map_io
* Paul Walmsley p...@pwsan.com [110902 04:58]:
Remove the OMAP_CHIP bitmasks from the powerdomain and clockdomain
code. In their place, use lists of powerdomains and clockdomains to
register for particular chips and chip families.
The intention of this change is to reduce the number of
On 9/2/2011 12:48 PM, Tony Lindgren wrote:
* Cousson, Benoitb-cous...@ti.com [110902 11:26]:
On 9/2/2011 10:12 AM, Tony Lindgren wrote:
* Benoit Coussonb-cous...@ti.com [110901 19:52]:
In order to avoid conflict with the new board-omap3-dt.c file,
remove the .dt_compat entry from the
Hi Arnd,
On Wed, 31 Aug 2011 18:49:37 +0200, Arnd Bergmann wrote:
On Monday 29 August 2011, Luciano Coelho wrote:
From: Randy Dunlap rdun...@xenotime.net
Combine MFD_SUPPORT (which only enabled the remainder of the MFD
menu) and MFD_CORE. This allows other drivers to select MFD_CORE
On 9/1/2011 12:23 AM, Hilman, Kevin wrote:
Benoit Coussonb-cous...@ti.com writes:
From: Nishanth Menonn...@ti.com
Provide a quick set of access functions:
a) Convert omap_device to platform_device - This is the flip of
to_omap_device for equivalent usage
b) Convert omap_device to device
* Cousson, Benoit b-cous...@ti.com [110902 15:02]:
On 9/2/2011 12:48 PM, Tony Lindgren wrote:
I'm not sure it is that simple. We have 20+ OMAP3+ boards supported
so far. Dropping pdata when a driver is adapted means that all these
boards should be properly adapted to DT and tested...
. create a PM layer plugin for per-device constraints, compiled under
CONFIG_OMAP_PM_CONSTRAINTS=y
. implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints to the
underlying layer
. implement the low level code
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 PM_QOS_CPU_DMA_LATENCY
class of PM QoS. The resulting MPU constraints are used by cpuidle to
decide the next power state of the MPU subsystem.
Created arch/arm/plat-omap/omap-pm-constraints.c file from
arch/arm/plat-omap/omap-pm-noop.c and the associated Kconfig option
OMAP_PM_CONSTRAINTS.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/plat-omap/Kconfig |7 +
arch/arm/plat-omap/Makefile |1 +
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 corresponding power domain.
The power domains get the
Figures are added to the power domains structs for RET and OFF modes.
Note: the latency figures for MPU, PER, CORE, NEON have been obtained
from actual measurements.
The latency figures for the other power domains are preliminary and
shall be added.
Tested on OMAP3 Beagleboard in RET/OFF using
Hwmod is queried from the OMAP_PM layer to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
latency
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 corresponding function at hwmod level.
Note: the bus throughput function is implemented but currently is
a no-op. A new PM QoS
Since cpuidle is a CPU centric framework it decides the MPU
next power state based on the MPU exit_latency and target_residency
figures.
The rest of the power domains get their next power state programmed
from the devices PM QoS framework, via the devices wake-up latency
constraints.
Note: the
Update the data from the measurements performed at HW and SW levels.
Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
for a detailed explanation on where are the numbers magically coming from.
ToDo:
- Measure the wake-up latencies for all power domains for OMAP3
-
Hi Kevin,
Here are a couple of cleanups on top of your (old) for_3.2/omap_device branch
rebased on top of -rc4 + Tony's cleanup patches.
Since I cannot pull your latest version, I repost the whole series.
patches are available here:
git://gitorious.org/omap-pm/linux.git
Replace the multiple omap2_get_XXX_device APIs with the new
omap_hwmod_name_get_dev that uses the hwmod name to get the proper
device.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c |4 ++--
1 files changed, 2
From: Nishanth Menon n...@ti.com
An API which translates a standard hwmod name to corresponding
platform_device is useful for drivers when they need to look up the
device associated with a hwmod name to map back into the device
structure pointers. These ideally should be used by drivers in
mach
Replace the struct device parameter of omap2_set_init_voltage
by the hwmod name. It will avoid having to store explicitely
the device pointer into a static variable.
Moreover, it will be a little bit more scalable if we introduce
new DVFS devices.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Since the device pointer is now retrieved using the hwmod name, remove
the static variables used to store the device pointers for DSP, MPU, IVA
and L3 devices for PM/DVFS usage.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm.c | 47
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 explicit one.
Next patches will clean the duplicated
Remove all these duplicated structures since a default one is now
available.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/devices.c| 46 +++--
arch/arm/mach-omap2/display.c| 11 +
Since misc devices have nothing in common besides fitting in no
other category, there is no need to group them in one Kconfig
symbol. Simply removing the symbol gets rid of all sorts of
Kconfig warnings about missing dependencies when another driver
selects a misc driver without also selecting
We currently have two symbols to control compilation the MFD subsystem,
MFD_SUPPORT and MFD_CORE. The MFD_SUPPORT is actually not required
at all, it only hides the submenu when not set, with the effect that
Kconfig warns about missing dependencies when another driver selects
an MFD driver while
On 9/1/2011 8:30 PM, Hilman, Kevin wrote:
Benoit Coussonb-cous...@ti.com writes:
Split the omap_device_build_ss into two smaller functions
that will allow to populate a platform_device already alocated by
device-tree.
The functionality of the omap_device_build_ss is still the same, but
On 9/1/2011 8:38 PM, Hilman, Kevin wrote:
Benoit Coussonb-cous...@ti.com writes:
Add two helpers function to parse a property that contains multiple
strings.
These functions might be exported and moved to a common place if they
can to be useful elsewhere.
Signed-off-by: Benoit
Hi,
If you compare am35x and da8x then you would find that they are
mostly
same and so should be merged. They both have one musb instances.
Ti81xx has two musb interface and huge differences in register map as
listed Above so ti81xx should be in a separate file.
Apart from this,
On 9/2/2011 1:40 AM, Hilman, Kevin wrote:
Benoit Coussonb-cous...@ti.com writes:
Add a notifier called during device_add phase. If a of_node is present,
retrieve the hwmod entry in order to populate propely the omap_device
structure.
For the moment the resource from the device-tree are
On Friday 02 September 2011, Jean Delvare wrote:
Doing this is a good idea, but incidentally I have just spent some time
with the same problem and ended up with a solution that I like better,
which is removing CONFIG_MFD_SUPPORT altogether.
The point is that there is no use enabling
Cousson, Benoit b-cous...@ti.com writes:
[...]
@@ -471,72 +572,31 @@ struct platform_device *omap_device_build_ss(const
char *pdev_name, int pdev_id,
goto odbs_exit;
}
- pr_debug(omap_device: %s: building with %d hwmods\n, pdev_name,
-oh_cnt);
+ /* Set
Marc Zyngier wrote at Friday, September 02, 2011 3:51 AM:
On 01/09/11 20:08, Stephen Warren wrote:
Marc Dietich wrote at Thursday, September 01, 2011 5:14 AM:
I'll add Stephen Warren from NVIDIA to the CC list. He has more HW to test
on.
Here are the results I found:
Harmony:
javier Martin javier.mar...@vista-silicon.com writes:
On 2 September 2011 08:05, Jarkko Nikula jarkko.nik...@bitmer.com wrote:
Other usual things to check that display is off (echo 1
/sys/class/graphics/fb0/blank) and no cable to musb/otg port.
Haven't tried myself with recent kernel but
5 first patches are relatively small iommu fixes/cleanups.
2 last patches are proposals for core iommu extensions:
- Add fault report mechanism, needed for recovery of remote processors
trying to access unmapped addresses.
- Add splitting of memory regions to pages in the iommu core itself
Tiny cleanup that removes a redundant 'return' statement.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/iommu/omap-iommu.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 90744af..4311bc3
Users of the IOMMU API (kvm specifically) assume that iommu_unmap()
returns the order of the unmapped page.
Fix omap_iommu_unmap() to do so and adopt omap-iovmm accordingly.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/iommu/omap-iommu.c | 13 -
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
omap_iovmm requires page-aligned buffers, and that sometimes causes
omap3isp failures (i.e. whenever the buffer passed from userspace is not
page-aligned).
Remove this limitation by rounding the address of the first page entry
down, and
Add iommu fault report mechanism to the IOMMU API, so implementations
could report about mmu faults (translation errors, hardware errors,
etc..).
Fault reports can be used in several ways:
- mere logging
- reset the device that accessed the faulting address (may be necessary
in case the device
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.
Conversely, when unmapping a memory region, iterate through its pages,
until the region is completely unmapped.
The logic to do
Users of the IOMMU API (kvm specifically) assume that iommu_unmap()
returns the order of the unmapped page (on success).
Fix msm_iommu_unmap() accordingly.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Stepan Moskovchenko step...@codeaurora.org
Cc: David Brown dav...@codeaurora.org
---
Replace iommu's alignment checks with the existing IS_ALIGNED macro,
to drop a few lines of code and utilize IS_ALIGNED's type safety.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/iommu/iommu.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git
Hi Tony,
Your testing-board branch currently has a couple new boards that are
missing the boot_params to atag_offset conversion (patch below.)
There's a patch below to fix this, but maybe it's better to just rebase
your testing-board branch onto Russell's devel-stable branch (where he's
merged
On Fri, Sep 02, 2011 at 08:32:34PM +0300, Ohad Ben-Cohen wrote:
Users of the IOMMU API (kvm specifically) assume that iommu_unmap()
returns the order of the unmapped page (on success).
Fix msm_iommu_unmap() accordingly.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Stepan Moskovchenko
On Fri, 2 Sep 2011, Kevin Hilman wrote:
Hi Tony,
Your testing-board branch currently has a couple new boards that are
missing the boot_params to atag_offset conversion (patch below.)
There's a patch below to fix this, but maybe it's better to just rebase
your testing-board branch onto
On Fri, 2 Sep 2011, Nicolas Pitre wrote:
On Fri, 2 Sep 2011, Kevin Hilman wrote:
Hi Tony,
Your testing-board branch currently has a couple new boards that are
missing the boot_params to atag_offset conversion (patch below.)
There's a patch below to fix this, but maybe it's better
Hi Jarkko,
Jarkko Nikula jarkko.nik...@bitmer.com writes:
[...]
Note that patch 01/14 has from address to my disabled google account. This
is since the patch is already committed in to
for_3.2/omap_device branch of Kevin's git tree.
The current version of my branch is not the final, as it
90 matches
Mail list logo