[..]
Can you please tell me what the mount options are for this setup?
I'm guessing you've got wsize=1024, in which case, can you please try
the following patch?
The mount options for nfs is rw.
Yes, in my setup wsize=1024 when the issue happened.
I tried your patch and I was not able to see
Hi,
From: Laurent Pinchart [laurent.pinch...@ideasonboard.com]
Sent: Thursday, September 08, 2011 10:21 PM
To: Ravi, Deepthy
Cc: linux-omap@vger.kernel.org; t...@atomide.com; li...@arm.linux.org.uk;
linux-arm-ker...@lists.infradead.org;
Hi Santosh,
On Tue, Sep 13, 2011 at 7:37 AM, Santosh santosh.shilim...@ti.com wrote:
On Tuesday 13 September 2011 12:22 AM, Kevin Hilman wrote:
Santosh Shilimkarsantosh.shilim...@ti.com writes:
This patch adds the MPUSS OSWR (Open Switch Retention) support. The MPUSS
OSWR configuration is
2011/9/13 Barry Song 21cn...@gmail.com:
2011/9/13 Jassi Brar jaswinder.si...@linaro.org:
On 12 September 2011 21:56, Barry Song 21cn...@gmail.com wrote:
Define a new api that could be used for doing fancy data transfers
like interleaved to contiguous copy and vice-versa.
Traditional SG_list
On Tuesday 13 September 2011 01:09 PM, Jean Pihet wrote:
Hi Santosh,
On Tue, Sep 13, 2011 at 7:37 AM, Santoshsantosh.shilim...@ti.com wrote:
On Tuesday 13 September 2011 12:22 AM, Kevin Hilman wrote:
[..]
static inline int omap4_finish_suspend(unsigned long cpu_state)
{}
This one
On 13 September 2011 13:16, Barry Song 21cn...@gmail.com wrote:
if test pass, to the patch, and even for the moment, to the API's idea
Acked-by: Barry Song baohua.s...@csr.com
one issue i noticed is with a device_prep_dma_genxfer, i don't need
device_prep_slave_sg any more,
Yeah, the
2011/9/13 Jassi Brar jaswinder.si...@linaro.org:
On 13 September 2011 13:16, Barry Song 21cn...@gmail.com wrote:
if test pass, to the patch, and even for the moment, to the API's idea
Acked-by: Barry Song baohua.s...@csr.com
one issue i noticed is with a device_prep_dma_genxfer, i don't need
On Tue, Sep 13, 2011 at 1:26 AM, Per Forlin per.for...@linaro.org wrote:
On 1 September 2011 21:05, Venkatraman S svenk...@ti.com wrote:
Reuse omap_hsmmc_dma_cleanup even for normal dma teardown in
omap_hsmmc_dma_cb. Consolidate multiple points of dma unmap into a
single location in post_req
On Mon, Sep 12, 2011 at 12:21:13PM -0400, Ohad Ben-Cohen wrote:
On Mon, Sep 12, 2011 at 7:02 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
I still don't get the need for this. It would make sense to encode
different types of faults, like page-faults or interrupt-faults.
Right.
When I
On Wed, Sep 07, 2011 at 02:53:24PM -0400, Ohad Ben-Cohen wrote:
drivers/iommu/amd_iommu.c | 20 ++-
drivers/iommu/intel-iommu.c | 20 ++-
drivers/iommu/iommu.c | 129
+++
drivers/iommu/msm_iommu.c |8 ++-
On Tue, Sep 13, 2011 at 1:00 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
For now I think it is the best to remove this IOMMU_ERROR thing. It is
inherent to the function call already. When a real use-case comes up we
can easily add it later.
I'm fine with this, will post an update.
Thanks,
Hi Joerg,
On Tue, Sep 13, 2011 at 1:10 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
Please split this patch into the core-change and patches for the
individual iommu-drivers and post this as a seperate patch-set.
But we'll be breaking bisectibility this way, no ?
Intel IOMMU does not
On Tue, Sep 13, 2011 at 06:34:23AM -0400, Ohad Ben-Cohen wrote:
Hi Joerg,
On Tue, Sep 13, 2011 at 1:10 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
Please split this patch into the core-change and patches for the
individual iommu-drivers and post this as a seperate patch-set.
But we'll
Hi
On Wed, Aug 31, 2011 at 4:28 AM, Hilman, Kevin wrote:
Abhilash K V abhilash...@ti.com writes:
1. Patch to disable dynamic sleep (as it is not supported
on AM35xx).
2. Imported the unique suspend/resume sequence for AM3517,
contained in the new file arch/arm/mach-omap2/sleep3517.S.
Hello Mark, Tony,
On Tuesday 30 August 2011 13:39:51 Ujfalusi, Peter wrote:
Hello,
Small cleanup for the tpa6130a2 driver for model handling:
Remove the model_id from platform_data, and use the device name/device_data
to distinguish between the supported models of TPA.
Would you have time
On Tue, Sep 13, 2011 at 03:11:41PM +0300, Péter Ujfalusi wrote:
Would you have time to take a look at this series (it got the Tested-by from
Jarkko)?
I'm fine with it, I'm waiting for Liam's review.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
On Tue, Sep 13, 2011 at 1:44 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
Not necessarily. You could implement this side-by-side with the old code
until all drivers are converted and remove the old code then. This keeps
bisectability.
Ok.
Intel IOMMU does not support arbitrary page-sizes,
From: Charulatha V ch...@ti.com
Use regs-pinctrl field instead of using the macro OMAP1510_GPIO_PIN_CONTROL
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap1/gpio15xx.c |1 +
Getting rid of ifdefs within the function by adding register offset intctrl
and associating OMAP_GPIO_INT_CONTROL in respective SoC specific files.
Also, use wkup_status register consistently instead of referring to wakeup
clear and wakeup set register offsets.
Signed-off-by: Charulatha V
The *_runtime_suspend/resume() callbacks perform basic operations
necessary before/after turning off/on clocks using *_runtime_put/get*().
This happens when modules are fully initialized and functional.
They don't have to be called during initialization. As we need the clocks
to be turned on/off
Since *_prepare_for_idle() and *_resume_after_idle() are called
with interrupts disabled they should be kept as simple as possible.
So, moving most of the stuff to *_runtime_suspend/resume() callbacks.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Wakeup enable register offset initialized according to OMAP versions
during device registration. Use this to avoid version checks.
Starting with OMAP4, legacy registers should not be used in combination
with the updated regsiters. Use wkup_en register consistently for
all SoCs wherever applicable.
There is no need to operate on all the banks every time the function is called.
Just operate on the current bank passed by the framework.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c | 53
From: Nishanth Menon n...@ti.com
GPIO debounce registers need to be saved and restored for proper functioning
of driver. To save the registers, we cannot cut the clock before the save,
hence move the clk disable after the save.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Tarun Kanti
Context is now saved dynamically in respective functions whenever and
whichever registers are modified. This avoid overhead of saving all
registers context in the runtime suspend callback.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar
From: Nishanth Menon n...@ti.com
GPIO IP revisions such as those used in OMAP4 have a set_dataout
while the previous revisions used a single dataout register.
Depending on what is available restore the dataout settings
to the right register.
Signed-off-by: Nishanth Menon n...@ti.com
From: Nishanth Menon n...@ti.com
Setup the dataout register before restoring OE. This is to make
sure that we have valid data in dataout register which would be
made available in output pins as soon as OE is enabled. Else,
there is risk of unknown data getting out into gpio pins.
Signed-off-by:
From: Charulatha V ch...@ti.com
The only bank-type (method) used in the OMAP GPIO driver is MPUIO type as they
need to be handled separately. Identify the same using a flag and remove all
METHOD_* macros.
mpuio_init() function is defined under #ifdefs. It is required only in case
of MPUIO bank
From: Charulatha V ch...@ti.com
The context lost count is modified in omap_sram_idle() path when
pwrdm_post_transition() is called. But pwrdm_post_transition() is called
only after omap_gpio_resume_after_idle() is called. Correct this so that
context lost count is modified before calling
From: Charulatha V ch...@ti.com
The gpio_bank_count is the count of number of GPIO devices in a SoC. Remove this
dependency from the driver by using list. Also remove the dependency on array of
pointers to gpio_bank struct of all GPIO devices.
Signed-off-by: Charulatha V ch...@ti.com
From: Nishanth Menon n...@ti.com
Setup the interrupt enable registers only after we have configured the
required edge and required configurations, not before, to prevent
spurious events as part of restore routine.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Tarun Kanti DebBarma
From: Charulatha V ch...@ti.com
Non-wakeup GPIOs are available only in OMAP2. Avoid cpu_is checks by making
non_wakeup_gpios as part of pdata.
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/gpio.c |8
Call runtime pm APIs pm_runtime_get_sync() and pm_runtime_put_sync()
for enabling/disabling clocks appropriately. Remove syscore_ops and
instead use SET_RUNTIME_PM_OPS macro.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh
By adding level and edge detection register offsets and then initializing them
correctly according to OMAP versions during device registrations we can now
remove
lot of revision checks in these functions.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V
Remove un-necessary bit masking. Since the register are 4 byte aligned
and readl would work as is. The 'enabled' mask is already taking care
to mask for bank width.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar
It is not required to use hard-coded offsets any more in context save and
restore functions and instead use the generic offsets which have been correctly
initialized during device registration.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
From: Charulatha V ch...@ti.com
In all OMAP1 SoCs, the MPUIO bank width is 16 bits. But, in OMAP7xx,
it is wrongly initialised to 32. Fix this.
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap1/gpio7xx.c |2 +-
1 files
With register offsets now defined for respective OMAP versions we can get rid
of cpu_class_* checks. This function now has common initialization code for
all OMAP versions. Initialization specific to OMAP16xx has been moved within
omap16xx_gpio_init().
Signed-off-by: Tarun Kanti DebBarma
From: Charulatha V ch...@ti.com
In omap3, save/restore context is implemented for GPIO banks 2-6 as GPIO bank1
is in wakeup domain. Instead of identifying bank's power domain by bank id,
use 'loses_context' flag which is filled by pwrdm_can_ever_lose_context()
during dev_init.
For getting the
From: Charulatha V ch...@ti.com
Remove cpu-is checks while enabling/disabling OMAP GPIO module during a gpio
request/free.
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/gpio.c |2 +
Unless the dbclk aliases are assigned, clk_get(bank-dev, dbclk)
would not fetch the associated clock handle. As a result, we would
not be able to turn on/off the debounce clock. This was preventing
the gpio modules going to low power mode whenever dbclk is enabled.
Signed-off-by: Tarun Kanti
From: Charulatha V ch...@ti.com
Currently gpio_context array used to save gpio bank's context, is used only for
OMAP3 architecture. Move gpio_context as part of gpio_bank structure so that it
can be specific to each gpio bank and can be used for any OMAP architecture
Signed-off-by: Charulatha V
From: Charulatha V ch...@ti.com
Modify omap_gpio_prepare_for_idle() omap_gpio_resume_after_idle() functions
to handle save context restore context respectively in the OMAP GPIO driver
itself instead of calling these functions from pm specific files.
For this, in gpio_prepare_for_idle(), call
This series is continuation of cleanup of OMAP GPIO driver and fixes.
The cleanup include getting rid of cpu_is_* checks wherever possible,
use of gpio_bank list instead of static array, use of unique platform
specific value associated data member to OMAP platforms to avoid
cpu_is_* checks. The
Cliff Brake cliff.brake at gmail.com writes:
On Thu, Jul 28, 2011 at 5:05 PM, Cliff Brake cliff.brake at gmail.com
wrote:
My kernel config is:
CONFIG_USB_MUSB_HDRC=y
# CONFIG_USB_MUSB_TUSB6010 is not set
CONFIG_USB_MUSB_OMAP2PLUS=y
# CONFIG_USB_MUSB_AM35X is not set
#
On Fri, Sep 9, 2011 at 10:02 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Thu, Aug 25, 2011 at 12:31 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
The Hwmod structures and Runtime PM features are implemented
For EHCI and OHCI
On Tue, 2011-09-13 at 13:27 +0100, Mark Brown wrote:
On Tue, Sep 13, 2011 at 03:11:41PM +0300, Péter Ujfalusi wrote:
Would you have time to take a look at this series (it got the Tested-by
from
Jarkko)?
I'm fine with it, I'm waiting for Liam's review.
Acked-by: Liam Girdwood
Santosh santosh.shilim...@ti.com writes:
On Tuesday 13 September 2011 02:36 AM, Kevin Hilman wrote:
Santosh Shilimkarsantosh.shilim...@ti.com writes:
This patch adds the CPU0 and CPU1 off mode support. CPUX close switch
retention (CSWR) is not supported by hardware design.
The CPUx OFF
Hi Sanjeev
Am looking at your commit 4cac6018, which touches
arch/arm/mach-omap2/id.c. That commit implements SoC detection for the
3505 in a different way than the implementations for other OMAP2+ devices:
it doesn't enumerate the possible TAP revisions for OMAP3505. The TRM
doesn't seem
Hi Abhilash,
Koyamangalath, Abhilash abhilash...@ti.com writes:
Hi
On Wed, Aug 31, 2011 at 4:28 AM, Hilman, Kevin wrote:
Abhilash K V abhilash...@ti.com writes:
1. Patch to disable dynamic sleep (as it is not supported
on AM35xx).
2. Imported the unique suspend/resume sequence for
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
Start using the generic fault report mechanism, as provided by
the IOMMU core, and remove its now-redundant omap_iommu_set_isr API.
Currently we're only interested in letting upper layers know about the
fault, so in case the faulting device is a remote processor, they could
restart it.
Dynamic
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 4KB, 64KB, 1MB and 16MB 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 Moskovchenko
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
Let the IOMMU core know we support arbitrary page sizes (as long as
they're an order of 4KB).
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 4KB
- they are naturally aligned
Note: Intel IOMMU hardware doesn't
Let the IOMMU core know we support 4KB, 64KB, 1MB and 16MB 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
---
drivers/iommu/omap-iommu.c |6 +-
1 files
Let the IOMMU core know we support arbitrary page sizes (as long as
they're an order of 4KB).
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 4KB
- they are naturally aligned
Signed-off-by: Ohad Ben-Cohen
* Santosh Shilimkar santosh.shilim...@ti.com [110904 06:22]:
On certain architectures, there might be a need to mark certain
addresses with strongly ordered memory attributes to avoid ordering
issues at the interconnect level.
This is something Russell needs to look.
You might want to also
* Santosh Shilimkar santosh.shilim...@ti.com [110904 06:22]:
On OMAP4 SOC intecronnects has many write buffers in the async bridges
and they can be drained only with stongly ordered accesses.
This is not correct, strongly ordered access does not guarantee
anything here. If it fixes issues, it's
* Santosh Shilimkar santosh.shilim...@ti.com [110904 06:23]:
OMAP WakeupGen is the interrupt controller extension used along
with ARM GIC to wake the CPU out from low power states on
external interrupts.
The WakeupGen unit is responsible for generating wakeup event
from the incoming
Clean up the SoC detection code for some OMAP3 devices. The main goal
is to make the AM3517 family detection code work like the rest of the
OMAP3 SoCs, although this series does some other cleanup of this code
at the same time. This patch series will be a prerequisite for the
OMAP_CHIP removal
The OMAP3505/AM3505 appears to be based on the same silicon as the
OMAP3517/AM3517, with some features disabled via eFuse bits. Follow
the same practice as OMAP3430 and identify these devices internally as
part of the OMAP3517/AM3517 family.
The OMAP3503/3515/3525/3530 chips appear to be based
Use explicit revision codes for OMAP/AM 3505/3517 ES levels, as the rest
of the OMAP2+ SoCs do in mach-omap2/cpu.c.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/id.c | 10 +-
arch/arm/plat-omap/include/plat/cpu.h |3
omap3_cpuinfo() is filled with useless strcpy() calls; remove them.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/id.c | 48 +-
1 files changed, 22 insertions(+), 26 deletions(-)
diff --git
The OMAP_REVBITS_* macros are just used as otherwise meaningless
aliases for the numbers zero through five, so remove these macros.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/plat-omap/include/plat/cpu.h | 33 ++---
1 files changed, 10 insertions(+),
Emit a warning to the console in omap3_check_revision() if that code
cannot determine what type of SoC the system is currently running on.
Remove some extra whitespace, remove some duplicate code, and
add an appropriate comment to a fallthrough case.
Signed-off-by: Paul Walmsley p...@pwsan.com
omap3_cpuinfo() contains essentially duplicated code from
omap3_check_revision(), just for the purpose of determining the chip ES level.
Set the cpu_rev char array pointer in omap3_check_revision() instead,
and drop the now-useless code from omap3_cpuinfo().
Signed-off-by: Paul Walmsley
On Tue, 2011-09-13 at 22:31 +0300, Ohad Ben-Cohen wrote:
+ * Traditionally the IOMMU core just handed us the mappings directly,
+ * after making sure the size is an order of a 4KB page and that the
+ * mapping has natural alignment.
+ *
+ * To retain this behavior, we currently advertise that
* Tarun Kanti DebBarma tarun.ka...@ti.com [110908 13:36]:
Since the exported APIs can be called from interrupt context
extend spinlock protection to some more relevant APIs to avoid
race condition.
We should have locking for requesting and releasing a timer etc,
but I don't see need for that
On Wed, Sep 14, 2011 at 4:45 AM, Tony Lindgren t...@atomide.com wrote:
* Tarun Kanti DebBarma tarun.ka...@ti.com [110908 13:36]:
Since the exported APIs can be called from interrupt context
extend spinlock protection to some more relevant APIs to avoid
race condition.
We should have locking
On Wed, Sep 14, 2011 at 12:32 AM, David Woodhouse dw...@infradead.org wrote:
On Tue, 2011-09-13 at 22:31 +0300, Ohad Ben-Cohen wrote:
+ * Traditionally the IOMMU core just handed us the mappings directly,
+ * after making sure the size is an order of a 4KB page and that the
+ * mapping has
On Tue, Sep 13, 2011 at 11:03 PM, Kevin Hilman khil...@ti.com wrote:
Santosh santosh.shilim...@ti.com writes:
On Tuesday 13 September 2011 02:36 AM, Kevin Hilman wrote:
Santosh Shilimkarsantosh.shilim...@ti.com writes:
This patch adds the CPU0 and CPU1 off mode support. CPUX close switch
Hi,
On Mon, Sep 12, 2011 at 10:16 PM, Rob Clark robdcl...@gmail.com wrote:
On Mon, Sep 12, 2011 at 8:24 AM, K, Mythri P mythr...@ti.com wrote:
+bool ti_hdmi_4xxx_detect(struct hdmi_ip_data *ip_data)
+{
+ int r;
+
+ void __iomem *base = hdmi_core_sys_base(ip_data);
+
+ /*
Tony,
On Wed, Sep 14, 2011 at 2:06 AM, Tony Lindgren t...@atomide.com wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [110904 06:23]:
OMAP WakeupGen is the interrupt controller extension used along
with ARM GIC to wake the CPU out from low power states on
external interrupts.
The
On Wed, Sep 14, 2011 at 1:53 AM, Tony Lindgren t...@atomide.com wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [110904 06:22]:
On certain architectures, there might be a need to mark certain
addresses with strongly ordered memory attributes to avoid ordering
issues at the interconnect
On Wed, Sep 14, 2011 at 1:57 AM, Tony Lindgren t...@atomide.com wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [110904 06:22]:
On OMAP4 SOC intecronnects has many write buffers in the async bridges
and they can be drained only with stongly ordered accesses.
This is not correct, strongly
77 matches
Mail list logo
