On Wed, Sep 14, 2011 at 1:57 AM, Tony Lindgren wrote:
> * Santosh Shilimkar [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
On Wed, Sep 14, 2011 at 1:53 AM, Tony Lindgren wrote:
> * Santosh Shilimkar [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
Tony,
On Wed, Sep 14, 2011 at 2:06 AM, Tony Lindgren wrote:
> * Santosh Shilimkar [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 gen
Hi,
On Mon, Sep 12, 2011 at 10:16 PM, Rob Clark wrote:
> On Mon, Sep 12, 2011 at 8:24 AM, K, Mythri P wrote:
>>> +bool ti_hdmi_4xxx_detect(struct hdmi_ip_data *ip_data)
>>> +{
>>> + int r;
>>> +
>>> + void __iomem *base = hdmi_core_sys_base(ip_data);
>>> +
>>> + /* HPD */
>>> +
On Tue, Sep 13, 2011 at 11:03 PM, Kevin Hilman wrote:
> Santosh writes:
>
>> On Tuesday 13 September 2011 02:36 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar writes:
>>>
This patch adds the CPU0 and CPU1 off mode support. CPUX close switch
retention (CSWR) is not supported by hardware
On Wed, Sep 14, 2011 at 12:32 AM, David Woodhouse 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 natural alignmen
On Wed, Sep 14, 2011 at 4:45 AM, Tony Lindgren wrote:
> * Tarun Kanti DebBarma [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 releasi
* Tarun Kanti DebBarma [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 for the timer spe
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
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
---
arch
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
Cc: Hemant Pedan
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
---
arch/arm/plat-omap/include/plat/cpu.h | 33 ++---
1 files changed, 10 insertions(+), 23 deletions(-)
omap3_cpuinfo() is filled with useless strcpy() calls; remove them.
Signed-off-by: Paul Walmsley
Cc: Sanjeev Premi
---
arch/arm/mach-omap2/id.c | 48 +-
1 files changed, 22 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch
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
Cc: Sanjeev Premi
---
arch/arm/mach-omap2/id.c | 10 +-
arch/arm/plat-omap/include/plat/cpu.h |3 ++-
2 files changed, 11 i
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 on
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 se
* Santosh Shilimkar [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 interrupts and enable bits
* Santosh Shilimkar [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 because it makes the w
* Santosh Shilimkar [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 read the mailing list ar
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
Cc: J
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 s
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
Cc: Joerg Roedel
Cc: David Woodhouse
Cc: David Brown
Cc: Stepan Moskovchenko
---
drivers/iommu/amd_i
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
---
drivers/iommu/omap-iommu.c |6 +-
1 files changed, 5 insertions(
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
Cc: David Brown
Cc: Stepan Moskovchenko
---
drivers/iommu/msm_iommu.c |
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 d
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 PT
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 i
Hi Abhilash,
"Koyamangalath, Abhilash" writes:
> Hi
>
> On Wed, Aug 31, 2011 at 4:28 AM, Hilman, Kevin wrote:
>>
>> Abhilash K V writes:
>>
>>> 1. Patch to disable dynamic sleep (as it is not supported
>>>on AM35xx).
>>> 2. Imported the unique suspend/resume sequence for AM3517,
>>>cont
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 t
Santosh writes:
> On Tuesday 13 September 2011 02:36 AM, Kevin Hilman wrote:
>> Santosh Shilimkar 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 mode isn't supported on OMAP4430 E
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 Girdwoo
On Fri, Sep 9, 2011 at 10:02 PM, Munegowda, Keshava
wrote:
> On Thu, Aug 25, 2011 at 12:31 PM, Keshava Munegowda
> wrote:
>> From: Keshava Munegowda
>>
>> The Hwmod structures and Runtime PM features are implemented
>> For EHCI and OHCI drivers of OMAP3 and OMAP4.
>> The global suspend/resume of
Cliff Brake gmail.com> writes:
>
> On Thu, Jul 28, 2011 at 5:05 PM, Cliff Brake 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
> # CONFIG_USB_MUSB_HOST is not set
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 ser
From: Charulatha V
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 *_get_context
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 De
From: Charulatha V
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
Reviewed-by:
From: Charulatha V
Remove cpu-is checks while enabling/disabling OMAP GPIO module during a gpio
request/free.
Signed-off-by: Charulatha V
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/gpio.c |2 +
arch/arm/plat-omap/include/plat/gpio.h |1 +
drivers/gpio/gpio-omap
From: Charulatha V
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 powerdomain poi
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
Signed-o
From: Charulatha V
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
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap1/gpio7xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --g
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
Signed-off-by: Charulatha V
Reviewed-by: Santosh Shilimkar
---
a
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
Signed-off-by: Tarun Kanti DebBarma
Reviewed-by: Santosh Shilimkar
---
drivers/gpio/gpio-omap.c |
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
Signed-off-by: Charulatha V
Reviewed-by: Santosh Shili
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
Signed-off-by: Tarun Kanti DebBarma
Reviewed-by: Santosh Shilimkar
---
drivers/gpio/gpio-om
From: Charulatha V
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
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/gpio.c |8
arch/arm/plat-omap/include/plat/gpio.h |
From: Charulatha V
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
Reviewed-by: Santosh Shilimkar
---
From: Charulatha V
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 omap_gpio_resume_afte
From: Nishanth Menon
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
Signed-off-by: Tarun Kanti DebBarma
Reviewed-by: Santosh Shili
From: Charulatha V
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 type and only
From: Nishanth Menon
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: Nishanth Men
From: Nishanth Menon
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
Signed-off-by: Tarun Kanti DebBarma
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
Reviewed-by: Santosh Shilimkar
---
drivers/gpio/gpio-omap.c | 62 +++
From: Nishanth Menon
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
Signed-off-by: Tarun Kanti DebBarma
Reviewed-by:
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
Reviewed-by: Santosh Shilimkar
---
drivers/gpio/gpio-omap.c | 53 +
1 files
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.
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
Signed-off-by: Charulatha V
Reviewed-by: Santosh Shilimkar
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 us
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
Sig
From: Charulatha V
Use regs->pinctrl field instead of using the macro OMAP1510_GPIO_PIN_CONTROL
Signed-off-by: Charulatha V
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap1/gpio15xx.c |1 +
arch/arm/plat-omap/include/plat/gpio.h |1 +
drivers/gpio/gpio-omap.c
On Tue, Sep 13, 2011 at 1:44 PM, Roedel, Joerg 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, afaik.
>>
>> It
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 mes
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 t
Hi
On Wed, Aug 31, 2011 at 4:28 AM, Hilman, Kevin wrote:
>
> Abhilash K V 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.
>> 3. A
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 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
Hi Joerg,
On Tue, Sep 13, 2011 at 1:10 PM, Roedel, Joerg 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 support arbitrary page-s
On Tue, Sep 13, 2011 at 1:00 PM, Roedel, Joerg 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,
Ohad.
--
To unsubsc
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 ++-
> drivers/iomm
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 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 read the com
On Tue, Sep 13, 2011 at 1:26 AM, Per Forlin wrote:
> On 1 September 2011 21:05, Venkatraman S 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 function, to prevent double unm
2011/9/13 Jassi Brar :
> 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
>>
>> one issue i noticed is with a device_prep_dma_genxfer, i don't need
>> device_prep_slave_sg any more,
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
>
> one issue i noticed is with a device_prep_dma_genxfer, i don't need
> device_prep_slave_sg any more,
Yeah, the damengine would nee
On Tuesday 13 September 2011 01:09 PM, Jean Pihet wrote:
Hi Santosh,
On Tue, Sep 13, 2011 at 7:37 AM, Santosh wrote:
On Tuesday 13 September 2011 12:22 AM, Kevin Hilman wrote:
[..]
static inline int omap4_finish_suspend(unsigned long cpu_state)
{}
This one should return 0, as I al
2011/9/13 Barry Song <21cn...@gmail.com>:
> 2011/9/13 Jassi Brar :
>> 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 based tra
Hi Santosh,
On Tue, Sep 13, 2011 at 7:37 AM, Santosh wrote:
> On Tuesday 13 September 2011 12:22 AM, Kevin Hilman wrote:
>>
>> Santosh Shilimkar writes:
>>
>>> This patch adds the MPUSS OSWR (Open Switch Retention) support. The MPUSS
>>> OSWR configuration is as below.
>>> - CPUx L1 and l
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; linux-ke
76 matches
Mail list logo