On Wed, 2011-09-14 at 11:04 +0530, K, Mythri P wrote:
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;
+
+
I can't see this one queued up anywhere. Did it just slip through the
cracks, or are there any problems with it?
BR,
Bjarne Steinsbo
On Tue, Aug 16, 2011 at 4:33 PM, Bjarne Steinsbo bstein...@gmail.com wrote:
Pointers to functions that are annotated as __devexit should be
protected by the
I can't see this one queued up anywhere. Did it just slip through the
cracks, or are there any problems with it?
BR,
Bjarne Steinsbo
On Tue, Aug 16, 2011 at 8:54 AM, Felipe Balbi ba...@ti.com wrote:
On Fri, Aug 12, 2011 at 05:28:26PM +0200, Bjarne Steinsbo wrote:
Not in use anymore.
I can't see this one queued up anywhere. Did it just slip through the
cracks, or are there any problems with it?
BR,
Bjarne Steinsbo
On Tue, Aug 16, 2011 at 8:54 AM, Felipe Balbi ba...@ti.com wrote:
On Fri, Aug 12, 2011 at 05:28:07PM +0200, Bjarne Steinsbo wrote:
Don't call
I can't see this one queued up anywhere. Did it just slip through the
cracks, or are there any problems with it?
BR,
Bjarne Steinsbo
On Tue, Aug 16, 2011 at 8:53 AM, Felipe Balbi ba...@ti.com wrote:
On Fri, Aug 12, 2011 at 05:27:52PM +0200, Bjarne Steinsbo wrote:
`keypad_pads' is referred to
On Wed, 2011-09-14 at 13:57 +0530, K, Mythri P wrote:
On Wed, Sep 14, 2011 at 12:44 PM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Wed, 2011-09-14 at 11:04 +0530, K, Mythri P wrote:
Hi,
On Mon, Sep 12, 2011 at 10:16 PM, Rob Clark robdcl...@gmail.com wrote:
On Mon, Sep 12, 2011 at
On Wed, Sep 14, 2011 at 2:04 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Wed, 2011-09-14 at 13:57 +0530, K, Mythri P wrote:
On Wed, Sep 14, 2011 at 12:44 PM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Wed, 2011-09-14 at 11:04 +0530, K, Mythri P wrote:
Hi,
On Mon, Sep 12,
Current implementation of the irq_disable only calls chip-irq_disable.
This fails to disable interrupt on some chip implementations, as there
are two alternative chip specific functions for this task,
chip-irq_disable and chip-irq_mask. Added alternative path for
chip-irq_disable also.
On Wed, 2011-09-14 at 14:18 +0530, K, Mythri P wrote:
On Wed, Sep 14, 2011 at 2:04 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Wed, 2011-09-14 at 13:57 +0530, K, Mythri P wrote:
On Wed, Sep 14, 2011 at 12:44 PM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
snip
I don't understand
Ok I failed with sending to lkml, sending it again there separately.
Sorry for confusion. ;)
On Wed, 2011-09-14 at 10:53 +0200, Kristo, Tero wrote:
Current implementation of the irq_disable only calls chip-irq_disable.
This fails to disable interrupt on some chip implementations, as there
are
Paul,
Looks like I was unsubscribed from linux-omap sometime last week.
Why? no idea!
Anyways, I just looked at your mails. Will be responding with
details in next hour. Will also attempt to re-subscribe in meantime.
~sanjeev
-Original Message-
From: Paul Walmsley
On Wednesday 14 September 2011 01:57 AM, Tony Lindgren wrote:
* Santosh Shilimkarsantosh.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
If there are no review comments on this patch, can this be merged?
Thanks and Regards,
Parth
-Original Message-
From: Saxena, Parth
Sent: Thursday, September 08, 2011 6:33 PM
To: linux-...@lists.infradead.org
Cc: linux-omap@vger.kernel.org; Saxena, Parth; Basheer, Mansoor Ahamed
Hello.
On 13-09-2011 17:02, Tarun Kanti DebBarma wrote:
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 Vch...@ti.com
Signed-off-by: Tarun Kanti
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Tuesday, September 13, 2011 11:33 PM
To: Premi, Sanjeev
Cc: nota...@gmail.com; t...@atomide.com; linux-omap@vger.kernel.org
Subject: OMAP3505 revisions?
Hi Sanjeev
Am looking at your commit 4cac6018, which
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 Wed, 14 Sep 2011, Premi, Sanjeev wrote:
Looks like I was unsubscribed from linux-omap sometime last week.
Why? no idea!
Bummer.
Anyways, I just looked at your mails. Will be responding with
details in next hour. Will also attempt to re-subscribe in meantime.
Thanks. Could you try a
Hi Sanjeev,
On Wed, 14 Sep 2011, Premi, Sanjeev wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
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
Hello Gražvydas,
On Mon, 5 Sep 2011, Grazvydas Ignotas wrote:
On Mon, Sep 5, 2011 at 5:43 AM, Paul Walmsley p...@pwsan.com wrote:
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 84cc0bd..d7138070 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, September 14, 2011 5:11 PM
To: Premi, Sanjeev
Cc: nota...@gmail.com; t...@atomide.com; linux-omap@vger.kernel.org
Subject: RE: OMAP3505 revisions?
On Wed, 14 Sep 2011, Premi, Sanjeev wrote:
Looks
Hello Tero,
On Fri, 2 Sep 2011, Tero Kristo wrote:
On Fri, 2011-09-02 at 11:20 +0200, Paul Walmsley wrote:
If it would help, I'd be happy to do a first draft of the OMAP3430 PRM
hwmod data.
If you can do this it would help, as you have much better understanding
of the hwmod data than
Hi,
On Wed, Sep 14, 2011 at 2:27 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Wed, 2011-09-14 at 14:18 +0530, K, Mythri P wrote:
On Wed, Sep 14, 2011 at 2:04 PM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Wed, 2011-09-14 at 13:57 +0530, K, Mythri P wrote:
On Wed, Sep 14, 2011 at
This contains support for VIDEO3 pipeline and zorder support for OMAP4 Display
controller. Apart form this the patches do some code clean up or minor fixes.
The patch set is based on Tomi's master branch and some additional patch sets
posted by Tomi on linux-omap. The patches can be tested on the
dispc_ovl_setup() currently takes a large number of overlay arguments, most of
these are members of the overlay_info struct. Replace these arguments by
passing a overlay_info pointer instead.
In configure_overlay(), we create an overlay_info struct called new_oi, this is
a copy of the overlay
dispc_ovl_enable_replication() and dispc_ovl_set_fifo_threshold() are currently
called in configure_overlay(). These are the only functions which cause DISPC
register writes of overlay parameters outside of dispc_ovl_setup().
Move these to dispc_ovl_setup() and pass replication, fifo_low and
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
Hi Paul,
This patch does not apply, after the v2 of 1_6, see below:
On 09/14/11 00:28, Paul Walmsley wrote:
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
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
Create a helper function called dispc_mgr_is_lcd() which returns true if the
manager is LCD or LCD2.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git
dispc_mgr_pclk_rate() is used to calculate minimum required functional clock for
scaling in calc_fclk() and calc_fclk_five_taps(). This function returns the
correct pixel clock for LCD and LCD2 managers, but not for TV manager. Extend
this function so that it gets the correct pixel clock for TV
The function calc_fclk_five_taps() uses a fixed value of pixels per line which
is used in calculations to get the minimum fclk needed for scaling with five
taps to work.
Remove this by providing the width of the panel connected to the manager.
Signed-off-by: Archit Taneja arc...@ti.com
---
Move DISPC scaling related code from dispc_ovl_setup() to a new function
dispc_ovl_calc_scaling(). Use overlay caps to check if the overlay can scale or
not. No functional changes are made.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 131
Create a dss_range_param member called FEAT_PARAM_DOWNSCALE to get the maximum
downscaling possible on the current platform. Use this in
dispc_ovl_calc_scaling().
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c|2 +-
Hi Paul,
Same problem (as with 3_6) here...
On 09/14/11 00:28, Paul Walmsley wrote:
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
---
On Wed, 14 Sep 2011, Igor Grinberg wrote:
Hi Paul,
Same problem (as with 3_6) here...
Thanks, I'll repost those. In the meantime, maybe try pulling the branch
'id_3517_cleanup_3.2' from git://git.pwsan.com/linux-2.6 ?
- Paul
--
To unsubscribe from this list: send the line unsubscribe
On Wed, 2011-09-14 at 14:10 +0200, Paul Walmsley wrote:
Hello Tero,
On Fri, 2 Sep 2011, Tero Kristo wrote:
On Fri, 2011-09-02 at 11:20 +0200, Paul Walmsley wrote:
If it would help, I'd be happy to do a first draft of the OMAP3430 PRM
hwmod data.
If you can do this it would
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
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
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
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
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
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(+),
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 09/14/11 15:29, Paul Walmsley wrote:
On Wed, 14 Sep 2011, Igor Grinberg wrote:
Hi Paul,
Same problem (as with 3_6) here...
Thanks, I'll repost those. In the meantime, maybe try pulling the branch
'id_3517_cleanup_3.2' from git://git.pwsan.com/linux-2.6 ?
I've applied those manually
hi Kevin
On Tue, Sep 13, 2011 at 11:54 PM, Hilman, Kevin wrote:
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:
snip
In addition to Russell's comments about using the
On Wed, Sep 14, 2011 at 4:49 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 13-09-2011 17:02, Tarun Kanti DebBarma wrote:
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
Hi Igor,
On Wed, 14 Sep 2011, Igor Grinberg wrote:
I've applied those manually on top of v3.1-rc3:
--cut
[0.00] Linux version 3.1.0-rc3-6-ga942f6de
(grinberg@grinberg-linux) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) )
#1 SMP Wed Sep 14
The request functions now verify the success of omap_dm_timer_prepare() call
after a timer is acquired. If *_prepare() fails then we have to release the
timer. In order to avoid race condition during this time, include *_prepare()
within lock.
Signed-off-by: Tarun Kanti DebBarma
Add error handling code to export APIs.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 101 ++---
arch/arm/plat-omap/include/plat/dmtimer.h | 24
2
On 09/14/11 16:10, Paul Walmsley wrote:
Hi Igor,
Could you try this patch on top of the ones that you are testing?
After applying the patch to your id_3517_cleanup_3.2 branch:
--cut---
[0.00] Linux version 3.1.0-rc4-00014-gbe89163 (grinberg@grinberg-linux)
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 Wed, 14 Sep 2011, Premi, Sanjeev wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, September 14, 2011 5:11 PM
To: Premi, Sanjeev
Cc: nota...@gmail.com; t...@atomide.com; linux-omap@vger.kernel.org
Subject: RE: OMAP3505 revisions?
This patch-set adds support for suspension to RAM and
resumption on the AM3517. This includes:
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.
Caveat:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, September 14, 2011 7:19 PM
To: Premi, Sanjeev
Cc: nota...@gmail.com; t...@atomide.com; Igor Grinberg;
linux-omap@vger.kernel.org
Subject: RE: OMAP3505 revisions?
On Wed, 14 Sep 2011, Premi, Sanjeev
Without this patch it is possible to select the VIDEO_OMAP3
driver which then selects OMAP_IOVMM. But the omap iommu
driver is not compiled without IOMMU_SUPPORT enabled. Fix
that by forcing OMAP_IOMMU and OMAP_IOVMM are enabled before
VIDEO_OMAP3 can be selected.
Cc: Ohad Ben-Cohen
On Wed, 2011-09-14 at 17:50 +0530, K, Mythri P wrote:
Hi,
On Wed, Sep 14, 2011 at 2:27 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Wed, 2011-09-14 at 14:18 +0530, K, Mythri P wrote:
On Wed, Sep 14, 2011 at 2:04 PM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Wed, 2011-09-14
In one particular place the old form of checking for TLL mode is used.
This patch fixes the same by using macros to check for TLL mode.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
patch is created on top of runtime patches from keshava hsoted at
On Wed, Sep 14, 2011 at 7:57 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
In one particular place the old form of checking for TLL mode is used.
This patch fixes the same by using macros to check for TLL mode.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
patch is created on top
* Shilimkar, Santosh santosh.shilim...@ti.com [110913 22:01]:
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
Ping?
On Tue, Sep 06, 2011 at 10:02:15AM -0400, Joerg Roedel wrote:
The following build error occurs with 3.1-rc5:
CC drivers/media/video/omap3isp/ispccdc.o
/home/data/repos/linux.trees.git/drivers/media/video/omap3isp/ispccdc.c: In
function 'ccdc_lsc_config':
On Tue, Sep 13, 2011 at 03:26:29PM -0400, Ohad Ben-Cohen wrote:
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
Mauro,
On Wednesday 14 September 2011 17:33:03 Roedel, Joerg wrote:
Ping?
I've acked the patch on September the 6th and asked in the e-mail if you could
pick it and push it to v3.1. Is there anything else I need to do ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the
Hi Paul
On Wed, Sep 14, 2011 at 7:21 PM, Premi, Sanjeev wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, September 14, 2011 7:19 PM
To: Premi, Sanjeev
Cc: nota...@gmail.com; t...@atomide.com; Igor
On Wednesday 14 September 2011 08:51 PM, Tony Lindgren wrote:
* Shilimkar, Santoshsantosh.shilim...@ti.com [110913 22:01]:
Tony,
On Wed, Sep 14, 2011 at 2:06 AM, Tony Lindgrent...@atomide.com wrote:
* Santosh Shilimkarsantosh.shilim...@ti.com [110904 06:23]:
OMAP WakeupGen is the interrupt
Hi Keshava,
On 8/25/2011 9:01 AM, Munegowda, Keshava wrote:
From: Benoit Coussonb-cous...@ti.com
Following 4 hwmod structures are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of
* Santosh santosh.shilim...@ti.com [110914 09:16]:
First and foremost, I have to go with the approach here because MPUSS
hardware team put a requirement that GIC and wakeupgen should always be
kept in sync. If needed we can discuss this off-the list with Richard.
Below is the extract from
On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
* Santoshsantosh.shilim...@ti.com [110914 09:16]:
First and foremost, I have to go with the approach here because MPUSS
hardware team put a requirement that GIC and wakeupgen should always be
kept in sync. If needed we can discuss
* Santosh santosh.shilim...@ti.com [110914 09:40]:
On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
* Santoshsantosh.shilim...@ti.com [110914 09:16]:
Thanks for the clarification. It seems to me the spec is most likely
wrong as we've had the GIC working for over two years now
On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote:
* Santoshsantosh.shilim...@ti.com [110914 09:40]:
On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
* Santoshsantosh.shilim...@ti.com [110914 09:16]:
Thanks for the clarification. It seems to me the spec is most
On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote:
* Santoshsantosh.shilim...@ti.com [110914 09:40]:
On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
* Santoshsantosh.shilim...@ti.com [110914 09:16]:
Thanks for the clarification. It seems to me the spec is most
yes. I've mentioned it after the signed-off by section..
On Wed, Sep 14, 2011 at 8:11 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Wed, Sep 14, 2011 at 7:57 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
In one particular place the old form of checking for TLL mode is used.
This
Hi Rusty,
On Wed, Jun 22, 2011 at 1:46 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Wed, Jun 22, 2011 at 5:42 AM, Rusty Russell ru...@rustcorp.com.au wrote:
On Tue, 21 Jun 2011 10:18:33 +0300, Ohad Ben-Cohen o...@wizery.com wrote:
+#define VIRTIO_ID_RPMSG 10 /* virtio remote
On Wed, Sep 14, 2011 at 5:07 PM, Joerg Roedel joerg.roe...@amd.com wrote:
Without this patch it is possible to select the VIDEO_OMAP3
driver which then selects OMAP_IOVMM. But the omap iommu
driver is not compiled without IOMMU_SUPPORT enabled. Fix
that by forcing OMAP_IOMMU and OMAP_IOVMM are
* Santosh santosh.shilim...@ti.com [110914 09:49]:
On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote:
* Santoshsantosh.shilim...@ti.com [110914 09:40]:
On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
* Santoshsantosh.shilim...@ti.com [110914 09:16]:
Thanks for
Hi Paul
On 8/28/2011 23:09, Paul Walmsley wrote:
Just doublechecking on this patch. Does anything need to be changed
before we merge this? I can take a look at the autogeneration script if
that's the only issue left.
Sorry, I have been out on holiday. I believe that was the only problem
Hi Paul,
On 8/28/2011 23:11, Paul Walmsley wrote:
Hi Jon,
On Thu, 7 Jul 2011, Jon Hunter wrote:
Various clock fixes for OMAP3 and OMAP4 devices.
Just doublechecking on these patches, some of them don't have
Signed-off-by:'s from you. Seems like we should add those?
Ok, let me look at
On 14 September 2011 15:40, S, Venkatraman svenk...@ti.com wrote:
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
Hi,
* Tarun Kanti DebBarma tarun.ka...@ti.com [110908 13:36]:
Register timer devices by going through hwmod database using
hwmod API. The driver probes each of the registered devices.
Functionality which are already performed by hwmod framework
are removed from timer code. New set of timers
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
omap3_cpuinfo() is filled with useless strcpy() calls; remove them.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Tested-by: Igor Grinberg grinb...@compulab.co.il
Tested-by: Abhilash Koyamangalath abhilash...@ti.com
---
arch/arm/mach-omap2/id.c | 48
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
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
Tested-by: Igor Grinberg grinb...@compulab.co.il
Tested-by: Abhilash Koyamangalath abhilash...@ti.com
---
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
Tested-by: Igor Grinberg grinb...@compulab.co.il
Tested-by: Abhilash Koyamangalath abhilash...@ti.com
---
* Tony Lindgren t...@atomide.com [110914 14:12]:
Also, as we don't need the support for different register offsets
for the first two omap4 timers, please rather implement support
for the new timers and the timeouts directly in plat-omap/dmtimer.c.
That way we can still keep the minimal
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 lines that
need to be patched to add support for new
In preparation for OMAP_CHIP() removal, split pwrdm_init() into three
functions. This allows some of them to be called multiple times: for
example, pwrdm_register_pwrdms() can be called once to register
powerdomains that are common to a group of SoCs, and once to register
powerdomains that are
In preparation for OMAP_CHIP() removal, split clkdm_init() into four
functions. This allows some of them to be called multiple times: for
example, clkdm_register_clkdms() can be called once to register
clockdomains that are common to a group of SoCs, and once to register
clockdomains that are
At Tony's request, remove the omap_chip bitmasks from the powerdomain
definitions. Instead, initialize powerdomains based on one or more
lists that are applicable to a particular SoC family, variant, and
silicon revision.
Gražvydas Ignotas nota...@gmail.com found and reported a bug in a
related
Hello Aaro,
On Tue, 6 Sep 2011, Aaro Koskinen wrote:
Should the timer12 be also removed from the common omap3xxx_hwmods
list, as it is not available on (some?) HS devices. See
e.g. http://marc.info/?l=linux-omapm=129433066521102w=2
Currently RM-680 boot is broken because of this.
Hmmm. I
Now that all of the users of the OMAP_CHIP bitfield code have been converted
to use lists, the OMAP_CHIP code, data, and declarations can be removed.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
This version has been updated to apply after the recent changes. It also
removes a few stray
* Koyamangalath, Abhilash abhilash...@ti.com [110812 00:12]:
Hi
@@ -58,6 +59,24 @@ static struct powerdomain *_pwrdm_lookup(const char
*name)
list_for_each_entry(temp_pwrdm, pwrdm_list, node) {
if (!strcmp(name, temp_pwrdm-name)) {
+
Santosh Shilimkar santosh.shilim...@ti.com writes:
This patch adds MPUSS(MPU Sub System) power domain
CSWR(Close Switch Retention) support to system wide suspend.
For both MPUSS RET support, CPUs are programmed to OFF state.
is 'both' in the wrong place in this sentence? I think you meant:
* hvaib...@ti.com hvaib...@ti.com [110829 05:52]:
From: Vaibhav Hiremath hvaib...@ti.com
This patch set adds support for AM335x device having
Cortex-A8 MPU.
AM335X is treated as another OMAP3 variant, where,
along with existing cpu class OMAP34XX, new cpu class AM33XX is created
and the
On Wed, 14 Sep 2011 21:38:43 +0300, Ohad Ben-Cohen o...@wizery.com wrote:
Hi Rusty,
On Wed, Jun 22, 2011 at 1:46 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Wed, Jun 22, 2011 at 5:42 AM, Rusty Russell ru...@rustcorp.com.au
wrote:
On Tue, 21 Jun 2011 10:18:33 +0300, Ohad Ben-Cohen
* Paul Walmsley p...@pwsan.com [110830 11:13]:
On Tue, 23 Aug 2011, Hemant Pedanekar wrote:
This patch set is the v2 of TI816X clock and hwmods patches sent earlier.
The clock data is currently added only for TI816X, while minimal hwmod data
common for TI816X and TI814X is added.
Tony Lindgren wrote on Thursday, September 15, 2011 6:03 AM:
* Paul Walmsley p...@pwsan.com [110830 11:13]:
On Tue, 23 Aug 2011, Hemant Pedanekar wrote:
This patch set is the v2 of TI816X clock and hwmods patches sent earlier.
The clock data is currently added only for TI816X, while
On Thursday 15 September 2011 12:34 AM, Tony Lindgren wrote:
* Santosh santosh.shilim...@ti.com [110914 09:49]:
On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote:
* Santoshsantosh.shilim...@ti.com [110914 09:40]:
On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
*
1 - 100 of 105 matches
Mail list logo
