RE: [PATCH] omap: Add macros to evaluate cpu revision
@@ -460,4 +461,35 @@ OMAP3_HAS_FEATURE(isp, ISP) OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK) OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP) +/* + * Map revision bits to silicon specific revisions + */ +#define ES_1_0 OMAP_REVBITS_00 probably need ES_1_1, 1_2 (considering 3630) This should be okay, since the 3630 is out with these revisions, but... +#define ES_2_0 OMAP_REVBITS_10 +#define ES_2_1 OMAP_REVBITS_20 makes sense to go to 2_2 +#define ES_3_0 OMAP_REVBITS_30 +#define ES_3_1 OMAP_REVBITS_40 +#define ES_3_1_2 OMAP_REVBITS_50 3_2? This may not make sense to add now as there are no 2.2 or 3.2 revisions of any OMAP3/4 silicon? - Anand-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Wed, Jul 21, 2010 at 09:25:28PM -0700, Zach Pfeffer wrote: Yes it is a problem, as Russell has brought up, but there's something I probably haven't communicated well. I'll use the following example: There are 3 devices: A CPU, a decoder and a video output device. All 3 devices need to map the same 12 MB buffer at the same time. Why do you need the same buffer mapped by the CPU? Let's take your example of a video decoder and video output device. Surely the CPU doesn't want to be writing to the same memory region used for the output picture as the decoder is writing to. So what's the point of mapping that memory into the CPU's address space? Surely the video output device doesn't need to see the input data to the decoder either? Surely, all you need is: 1. a mapping for the CPU for a chunk of memory to pass data to the decoder. 2. a mapping for the decoder to see the chunk of memory to receive data from the CPU. 3. a mapping for the decoder to see a chunk of memory used for the output video buffer. 4. a mapping for the output device to see the video buffer. So I don't see why everything needs to be mapped by everything else. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Wed, Jul 21, 2010 at 09:30:34PM -0700, Zach Pfeffer wrote: This goes to the nub of the issue. We need a lot of 1 MB physically contiguous chunks. The system is going to fragment and we'll never get our 12 1 MB chunks that we'll need, since the DMA API allocator uses the system pool it will never succeed. By the DMA API allocator I assume you mean the coherent DMA interface, The DMA coherent API and DMA streaming APIs are two separate sub-interfaces of the DMA API and are not dependent on each other. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Wed, Jul 21, 2010 at 08:50:26PM -0700, Zach Pfeffer wrote: On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote: On Tue, 13 Jul 2010 10:02:23 +0100 Zach Pfeffer said this new VCM infrastructure can be useful for video4linux. However, I don't think we need 3,000-lines another abstraction layer to solve video4linux's issue nicely. Its only 3000 lines because I haven't converted the code to use function pointers. I don't understand - you've made this claim a couple of times. I can't see how converting the code to use function pointers (presumably to eliminate those switch statements) would reduce the number of lines of code. Please explain (or show via new patches) how does converting this to function pointers significantly reduce the number of lines of code. We might then be able to put just _one_ of these issues to bed. Getting back to the point. There is no API that can handle large buffer allocation and sharing with low-level attribute control for virtual address spaces outside the CPU. I think we've dealt with the attribute issue to death now. Shall we repeat it again? The DMA API et al. take a CPU centric view of virtual space management, sharing has to be explicitly written and external virtual space management is left up to device driver writers. I think I've also shown that not to be the case with example code. The code behind the DMA API can be changed on a per-device basis (currently on ARM we haven't supported that because no one's asked for it yet) so that it can support multiple IOMMUs even of multiple different types. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap3: Remove non-existent config option
From: Yogesh Marathe yogesh_mara...@ti.com
The definition of iva2 device in iommu_device
is wrapped inside CONFIG_MPU_BRIDGE_IOMMU, but
this option is not defined in KConfig.
This patch removes the wrapper and makes iva2
available as another iommu_device.
Signed-off-by: Yogesh Marathe yogesh_mara...@ti.com
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/omap-iommu.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index f5a1aad..bb8c01d 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -35,7 +35,6 @@ static struct iommu_device omap3_devices[] = {
.clk_name = cam_ick,
},
},
-#if defined(CONFIG_MPU_BRIDGE_IOMMU)
{
.base = 0x5d00,
.irq = 28,
@@ -45,7 +44,6 @@ static struct iommu_device omap3_devices[] = {
.clk_name = iva2_ck,
},
},
-#endif
};
#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
--
1.6.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: Add macros to evaluate cpu revision
On 07/22/2010 01:53 AM, Gadiyar, Anand wrote: @@ -460,4 +461,35 @@ OMAP3_HAS_FEATURE(isp, ISP) OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK) OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP) +/* + * Map revision bits to silicon specific revisions + */ +#define ES_1_0 OMAP_REVBITS_00 probably need ES_1_1, 1_2 (considering 3630) This should be okay, since the 3630 is out with these revisions, but... +#define ES_2_0 OMAP_REVBITS_10 +#define ES_2_1 OMAP_REVBITS_20 makes sense to go to 2_2 +#define ES_3_0 OMAP_REVBITS_30 +#define ES_3_1 OMAP_REVBITS_40 +#define ES_3_1_2 OMAP_REVBITS_50 3_2? This may not make sense to add now as there are no 2.2 or 3.2 revisions of any OMAP3/4 silicon? Agreed for 3 and 4, but considering this is arch/arm/plat-omap/include/plat/cpu.h, does it make sense in looking all OMAPs? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: Add macros to evaluate cpu revision
-Original Message- From: Menon, Nishanth Sent: Thursday, July 22, 2010 3:08 PM To: Gadiyar, Anand Cc: Premi, Sanjeev; linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: Add macros to evaluate cpu revision On 07/22/2010 01:53 AM, Gadiyar, Anand wrote: @@ -460,4 +461,35 @@ OMAP3_HAS_FEATURE(isp, ISP) OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK) OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP) +/* + * Map revision bits to silicon specific revisions + */ +#define ES_1_0 OMAP_REVBITS_00 probably need ES_1_1, 1_2 (considering 3630) This should be okay, since the 3630 is out with these revisions, but... +#define ES_2_0 OMAP_REVBITS_10 +#define ES_2_1 OMAP_REVBITS_20 makes sense to go to 2_2 +#define ES_3_0 OMAP_REVBITS_30 +#define ES_3_1 OMAP_REVBITS_40 +#define ES_3_1_2 OMAP_REVBITS_50 3_2? This may not make sense to add now as there are no 2.2 or 3.2 revisions of any OMAP3/4 silicon? Agreed for 3 and 4, but considering this is arch/arm/plat-omap/include/plat/cpu.h, does it make sense in looking all OMAPs? In this case, the best option would be to prefix OMAP34X_/ OMAP36X_ OMAP44X_ etc and define the ES revisions for each context. ~sanjeev Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] OMAP: DSS2: Zorder enum in display.h
-Original Message-
From: Taneja, Archit
Sent: Thursday, July 22, 2010 9:42 AM
To: Premi, Sanjeev; tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Semwal, Sumit; Nilofer, Samreen
Subject: RE: [PATCH 1/3] OMAP: DSS2: Zorder enum in display.h
-Original Message-
From: Premi, Sanjeev
Sent: Wednesday, July 21, 2010 7:47 PM
To: Taneja, Archit; tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Semwal, Sumit; Nilofer,
Samreen; Taneja, Archit
Subject: RE: [PATCH 1/3] OMAP: DSS2: Zorder enum in display.h
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Archit Taneja
Sent: Monday, July 19, 2010 5:40 PM
To: tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Semwal, Sumit; Nilofer, Samreen;
Taneja, Archit
Subject: [PATCH 1/3] OMAP: DSS2: Zorder enum in display.h
From: Sumit Semwal sumit.sem...@ti.com
Add Zorder enum in display.h
Patches 1 and 2 in the series can easily be conbined into one.
Separating few line changes in header file from
implementation across 2 patches isn't useful.
[archit] We are introducing a new DSS feature for OMAP4 in every
patch series. In order to clearly explain the feature introduced,
the first patch of every series makes changes on in the display.h
header which is central to the DSS2 code.
If this is not a accepted norm or a strong enough reason to have a
separate small patch, I can rework these series, I would need more
comments from others though.
[sp] I understand the festure intoduction, but spliting patches across
headers and implementation doesn't seem to be logical.
~sanjeev
snap
+enum omap_overlay_zorder {
+ OMAP_DSS_OVL_ZORDER_0 = 0x0,
+ OMAP_DSS_OVL_ZORDER_1 = 0x1,
+ OMAP_DSS_OVL_ZORDER_2 = 0x2,
+ OMAP_DSS_OVL_ZORDER_3 = 0x3,
+};
Is _DSS_ really needed in these emums? considering that
enum itself doesn't contain _dss_ in its name.
[archit] I agree with this, but the present header is inconsistent
with the point you have made, there are other enums which don't have
_dss_ but have _DSS_ in its enum members. We should try to make
this uniform (unless there is a motive behind it).
~sanjeev
Regards,
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: Add macros to evaluate cpu revision
Sanjeev, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Thursday, July 22, 2010 3:20 PM To: Menon, Nishanth; Gadiyar, Anand Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] omap: Add macros to evaluate cpu revision -Original Message- From: Menon, Nishanth Sent: Thursday, July 22, 2010 3:08 PM To: Gadiyar, Anand Cc: Premi, Sanjeev; linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: Add macros to evaluate cpu revision On 07/22/2010 01:53 AM, Gadiyar, Anand wrote: @@ -460,4 +461,35 @@ OMAP3_HAS_FEATURE(isp, ISP) OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK) OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP) +/* + * Map revision bits to silicon specific revisions + */ +#define ES_1_0 OMAP_REVBITS_00 probably need ES_1_1, 1_2 (considering 3630) This should be okay, since the 3630 is out with these revisions, but... +#define ES_2_0 OMAP_REVBITS_10 +#define ES_2_1 OMAP_REVBITS_20 makes sense to go to 2_2 +#define ES_3_0 OMAP_REVBITS_30 +#define ES_3_1 OMAP_REVBITS_40 +#define ES_3_1_2 OMAP_REVBITS_50 3_2? This may not make sense to add now as there are no 2.2 or 3.2 revisions of any OMAP3/4 silicon? Agreed for 3 and 4, but considering this is arch/arm/plat-omap/include/plat/cpu.h, does it make sense in looking all OMAPs? In this case, the best option would be to prefix OMAP34X_/ OMAP36X_ OMAP44X_ etc and define the ES revisions for each context. Can please put the usecase need here. Do you want to use this for ERRATA handling or OPP handling etc etc ? Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: Add macros to evaluate cpu revision
Premi, Sanjeev had written, on 07/22/2010 04:49 AM, the following: -Original Message- From: Menon, Nishanth Sent: Thursday, July 22, 2010 3:08 PM To: Gadiyar, Anand Cc: Premi, Sanjeev; linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: Add macros to evaluate cpu revision On 07/22/2010 01:53 AM, Gadiyar, Anand wrote: @@ -460,4 +461,35 @@ OMAP3_HAS_FEATURE(isp, ISP) OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK) OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP) +/* + * Map revision bits to silicon specific revisions + */ +#define ES_1_0 OMAP_REVBITS_00 probably need ES_1_1, 1_2 (considering 3630) This should be okay, since the 3630 is out with these revisions, but... +#define ES_2_0 OMAP_REVBITS_10 +#define ES_2_1 OMAP_REVBITS_20 makes sense to go to 2_2 +#define ES_3_0 OMAP_REVBITS_30 +#define ES_3_1 OMAP_REVBITS_40 +#define ES_3_1_2 OMAP_REVBITS_50 3_2? This may not make sense to add now as there are no 2.2 or 3.2 revisions of any OMAP3/4 silicon? Agreed for 3 and 4, but considering this is arch/arm/plat-omap/include/plat/cpu.h, does it make sense in looking all OMAPs? In this case, the best option would be to prefix OMAP34X_/ OMAP36X_ OMAP44X_ etc and define the ES revisions for each context. doing that is gonna make the code real dirty looking. at the very least mebbe bracket it in with #ifdef with CONFIG_OMAP2PLUS? -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: Add macros to evaluate cpu revision
-Original Message- From: Menon, Nishanth Sent: Thursday, July 22, 2010 4:18 PM To: Premi, Sanjeev Cc: Gadiyar, Anand; linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: Add macros to evaluate cpu revision Premi, Sanjeev had written, on 07/22/2010 04:49 AM, the following: -Original Message- From: Menon, Nishanth Sent: Thursday, July 22, 2010 3:08 PM To: Gadiyar, Anand Cc: Premi, Sanjeev; linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: Add macros to evaluate cpu revision On 07/22/2010 01:53 AM, Gadiyar, Anand wrote: @@ -460,4 +461,35 @@ OMAP3_HAS_FEATURE(isp, ISP) OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK) OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP) +/* + * Map revision bits to silicon specific revisions + */ +#define ES_1_0 OMAP_REVBITS_00 probably need ES_1_1, 1_2 (considering 3630) This should be okay, since the 3630 is out with these revisions, but... +#define ES_2_0 OMAP_REVBITS_10 +#define ES_2_1 OMAP_REVBITS_20 makes sense to go to 2_2 +#define ES_3_0 OMAP_REVBITS_30 +#define ES_3_1 OMAP_REVBITS_40 +#define ES_3_1_2 OMAP_REVBITS_50 3_2? This may not make sense to add now as there are no 2.2 or 3.2 revisions of any OMAP3/4 silicon? Agreed for 3 and 4, but considering this is arch/arm/plat-omap/include/plat/cpu.h, does it make sense in looking all OMAPs? In this case, the best option would be to prefix OMAP34X_/ OMAP36X_ OMAP44X_ etc and define the ES revisions for each context. doing that is gonna make the code real dirty looking. at the dirty?? How come? The intent is to increase readability. very least mebbe bracket it in with #ifdef with CONFIG_OMAP2PLUS? What purpose does this #ifdef. The macro should/could be used quite generically. Here is a sample usage from one of the patch I am reworking for submission here: @@ -488,7 +494,9 @@ void omap_sram_idle(void) * of AUTO_CNT = 1 enabled. This takes care of errata 1.142. * Hence store/restore the SDRC_POWER register here. */ - if (omap_rev() = OMAP3430_REV_ES3_0 + if ((cpu_is_omap3630() + || cpu_is_omap3505() || cpu_is_omap3517() + || cpu_rev_ge(34xx, OMAP34XX_ES_3_0)) omap_type() != OMAP2_DEVICE_TYPE_GP core_next_state == PWRDM_POWER_OFF) sdrc_pwr = sdrc_read_reg(SDRC_POWER); Don't try to look more into the actual content of this example, but try to use existing macros to re-implement this condition. omap_rev() is always OMAP3430_REV_ES3_0 for all OMAP35x devices; even for OMAP3530 at ES2.1 level (0x35302034 0x34304034) And the original condition doesn't hold good. Try to visualize silicon revision viz. 2.1 for OMAP3505 requiring the same example condition to be updated. ~sanjeev -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/20] omap: zoom: add fixed regulator device for wlan
On 07/21/2010 08:59 PM, ext Mark Brown wrote:
On Wed, Jul 21, 2010 at 08:33:44PM +0300, Ohad Ben-Cohen wrote:
+static struct regulator_consumer_supply zoom_vmmc3_supply = {
+ .supply = vmmc,
+};
This looks like a misconfiguration on the consumer - I'd strongly expect
the consumer to have a dev_name specified also with the name being in
terms of the consumer device.
you need to add something like
.dev_name = mmci-omap-hs.2
regards,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 18/20] mmc: sdio: enable a default power off mode of the card
On 07/21/2010 08:33 PM, ext Ohad Ben-Cohen wrote: Add support for an SDIO device to stay powered off even without the presence of an SDIO function driver. A host should explicitly ask for it by means of MMC_CAP_DONT_POWER_CARD, and the SDIO function driver should know it needs to call sdio_claim_power before accessing the device. Signed-off-by: Ohad Ben-Coheno...@wizery.com Shouldn't this be the default behaviour? If there is no function driver for any of the functions of the card, then sdio core shold power off the card. I don't see a need for a special capability flag for this. in fact MMC_CAP_DONT_POWER_CARD does not seem like an mmc host's capability flag, it seems more like a request from the board to keep the card powered off. regards, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: Add macros to evaluate cpu revision
Premi, Sanjeev had written, on 07/22/2010 06:20 AM, the following: -Original Message- From: Menon, Nishanth Sent: Thursday, July 22, 2010 4:18 PM To: Premi, Sanjeev Cc: Gadiyar, Anand; linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: Add macros to evaluate cpu revision Premi, Sanjeev had written, on 07/22/2010 04:49 AM, the following: -Original Message- From: Menon, Nishanth Sent: Thursday, July 22, 2010 3:08 PM To: Gadiyar, Anand Cc: Premi, Sanjeev; linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: Add macros to evaluate cpu revision On 07/22/2010 01:53 AM, Gadiyar, Anand wrote: @@ -460,4 +461,35 @@ OMAP3_HAS_FEATURE(isp, ISP) OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK) OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP) +/* + * Map revision bits to silicon specific revisions + */ +#define ES_1_0 OMAP_REVBITS_00 probably need ES_1_1, 1_2 (considering 3630) This should be okay, since the 3630 is out with these revisions, but... +#define ES_2_0 OMAP_REVBITS_10 +#define ES_2_1 OMAP_REVBITS_20 makes sense to go to 2_2 +#define ES_3_0 OMAP_REVBITS_30 +#define ES_3_1 OMAP_REVBITS_40 +#define ES_3_1_2 OMAP_REVBITS_50 3_2? This may not make sense to add now as there are no 2.2 or 3.2 revisions of any OMAP3/4 silicon? Agreed for 3 and 4, but considering this is arch/arm/plat-omap/include/plat/cpu.h, does it make sense in looking all OMAPs? In this case, the best option would be to prefix OMAP34X_/ OMAP36X_ OMAP44X_ etc and define the ES revisions for each context. doing that is gonna make the code real dirty looking. at the dirty?? How come? The intent is to increase readability. huh? should we start the old debate again? Read this thread http://marc.info/?l=linux-omapm=127903615629407w=2 very least mebbe bracket it in with #ifdef with CONFIG_OMAP2PLUS? What purpose does this #ifdef. The macro should/could be used quite generically. Now we are back in a full circle - if you would like to introduce the patch for ALL omap silicon, you might want to consider 2420 and so on.. at the very least. introducing this for OMAP3 and 4 alone does not allow logic to scale up. information about the cputype is already being passed as a parameter, so it is just a matter of figuring out which ES revs should be defined there.. Here is a sample usage from one of the patch I am reworking for submission here: @@ -488,7 +494,9 @@ void omap_sram_idle(void) * of AUTO_CNT = 1 enabled. This takes care of errata 1.142. * Hence store/restore the SDRC_POWER register here. */ - if (omap_rev() = OMAP3430_REV_ES3_0 + if ((cpu_is_omap3630() + || cpu_is_omap3505() || cpu_is_omap3517() + || cpu_rev_ge(34xx, OMAP34XX_ES_3_0)) cpu_rev_ge(34xx, OMAP34XX_ES_3_0) - this is the cause of my comment on dirty code - redundant OMAP34XX_ in the macro when I do say it is 34xx in the first parameter! omap_type() != OMAP2_DEVICE_TYPE_GP core_next_state == PWRDM_POWER_OFF) sdrc_pwr = sdrc_read_reg(SDRC_POWER); Don't try to look more into the actual content of this example, but try to use existing macros to re-implement this condition. omap_rev() is always OMAP3430_REV_ES3_0 for all OMAP35x devices; even for OMAP3530 at ES2.1 level (0x35302034 0x34304034) And the original condition doesn't hold good. Try to visualize silicon revision viz. 2.1 for OMAP3505 requiring the same example condition to be updated. I see similar potential use in enabling quirks and features (the above code btw could be better handled with a single variable errata which is populated with a flag at pm_init time.. ~sanjeev -- Regards, Nishanth Menon -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: Add macros to evaluate cpu revision
snip---snip Here is a sample usage from one of the patch I am reworking for submission here: @@ -488,7 +494,9 @@ void omap_sram_idle(void) * of AUTO_CNT = 1 enabled. This takes care of errata 1.142. * Hence store/restore the SDRC_POWER register here. */ - if (omap_rev() = OMAP3430_REV_ES3_0 + if ((cpu_is_omap3630() + || cpu_is_omap3505() || cpu_is_omap3517() + || cpu_rev_ge(34xx, OMAP34XX_ES_3_0)) cpu_rev_ge(34xx, OMAP34XX_ES_3_0) - this is the cause of my comment on dirty code - redundant OMAP34XX_ in the macro when I do say it is 34xx in the first parameter! omap_type() != OMAP2_DEVICE_TYPE_GP core_next_state == PWRDM_POWER_OFF) sdrc_pwr = sdrc_read_reg(SDRC_POWER); Don't try to look more into the actual content of this example, but try to use existing macros to re-implement this condition. omap_rev() is always OMAP3430_REV_ES3_0 for all OMAP35x devices; even for OMAP3530 at ES2.1 level (0x35302034 0x34304034) And the original condition doesn't hold good. Try to visualize silicon revision viz. 2.1 for OMAP3505 requiring the same example condition to be updated. I see similar potential use in enabling quirks and features (the above code btw could be better handled with a single variable errata which is populated with a flag at pm_init time.. Will have detailed response later... But, 3530, 3505 and 3517 are not erratas. These are different silicons. AND this patch has no relation to power management. More and more silicons are going to be added to linux-omap tree as they are based. They all will follow their own revision lifecycle. I have no issues to go back and add the 2420 etc. but I don't have much information on their revision history. If you provide me info, I can update the patch OR you can submit a follow-up patch with related changes. The macros don't change due to addition of additional silicon revisions. ~sanjeev ~sanjeev -- Regards, Nishanth Menon -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Thu, Jul 22, 2010 at 08:51:51AM +0100, Russell King - ARM Linux wrote: On Wed, Jul 21, 2010 at 08:50:26PM -0700, Zach Pfeffer wrote: On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote: On Tue, 13 Jul 2010 10:02:23 +0100 Zach Pfeffer said this new VCM infrastructure can be useful for video4linux. However, I don't think we need 3,000-lines another abstraction layer to solve video4linux's issue nicely. Its only 3000 lines because I haven't converted the code to use function pointers. I don't understand - you've made this claim a couple of times. I can't see how converting the code to use function pointers (presumably to eliminate those switch statements) would reduce the number of lines of code. Please explain (or show via new patches) how does converting this to function pointers significantly reduce the number of lines of code. We might then be able to put just _one_ of these issues to bed. Aye. Its getting worked on. Once its done I'll push it. Getting back to the point. There is no API that can handle large buffer allocation and sharing with low-level attribute control for virtual address spaces outside the CPU. I think we've dealt with the attribute issue to death now. Shall we repeat it again? I think the only point of agreement is that all mappings must have compatible attributes, the issue of multiple mappings is still outstanding, as is needing more fine grained control of the attributes of a set of compatible mappings (I still need to digest your examples a little). The DMA API et al. take a CPU centric view of virtual space management, sharing has to be explicitly written and external virtual space management is left up to device driver writers. I think I've also shown that not to be the case with example code. The code behind the DMA API can be changed on a per-device basis (currently on ARM we haven't supported that because no one's asked for it yet) so that it can support multiple IOMMUs even of multiple different types. I'm seeing that now. As I become more familiar with the DMA API the way forward may become more clear to me. I certainly appreciate the time you've spent discussing things and the code examples you've listed. For example, it fairly clear how I can use a scatter list to describe a mapping of big buffers. I can start down this path and see what shakes out. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Thu, Jul 22, 2010 at 08:34:55AM +0100, Russell King - ARM Linux wrote: On Wed, Jul 21, 2010 at 09:25:28PM -0700, Zach Pfeffer wrote: Yes it is a problem, as Russell has brought up, but there's something I probably haven't communicated well. I'll use the following example: There are 3 devices: A CPU, a decoder and a video output device. All 3 devices need to map the same 12 MB buffer at the same time. Why do you need the same buffer mapped by the CPU? Let's take your example of a video decoder and video output device. Surely the CPU doesn't want to be writing to the same memory region used for the output picture as the decoder is writing to. So what's the point of mapping that memory into the CPU's address space? It may, especially if you're doing some software post processing. Also by mapping all the buffers its extremly fast to pass the buffers around in this senario - the buffer passing becomes a simple signal. Surely the video output device doesn't need to see the input data to the decoder either? No, but other devices may (like the CPU). Surely, all you need is: 1. a mapping for the CPU for a chunk of memory to pass data to the decoder. 2. a mapping for the decoder to see the chunk of memory to receive data from the CPU. 3. a mapping for the decoder to see a chunk of memory used for the output video buffer. 4. a mapping for the output device to see the video buffer. So I don't see why everything needs to be mapped by everything else. That's fair, but we do share buffers and we do have many, very large mappings, and we do need to pull these from a separate pools because they need to exhibit a particular allocation profile. I agree with you that things should work like you've listed, but with Qualcomm's ARM multimedia engines we're seeing some different usage scenarios. Its the giant buffers, needing to use our own buffer allocator, the need to share and the need to swap out virtual IOMMU space (which we haven't talked about much) which make the DMA API seem like a mismatch. (we haven't even talked about graphics usage ;) ). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Thu, Jul 22, 2010 at 08:39:17AM +0100, Russell King - ARM Linux wrote: On Wed, Jul 21, 2010 at 09:30:34PM -0700, Zach Pfeffer wrote: This goes to the nub of the issue. We need a lot of 1 MB physically contiguous chunks. The system is going to fragment and we'll never get our 12 1 MB chunks that we'll need, since the DMA API allocator uses the system pool it will never succeed. By the DMA API allocator I assume you mean the coherent DMA interface, The DMA coherent API and DMA streaming APIs are two separate sub-interfaces of the DMA API and are not dependent on each other. I didn't know that, but yes. As far as I can tell they both allocate memory from the VM. We'd need a way to hook in our our own minimized mapping allocator. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] USB: musb: omap2430: add mode change from A to B
--text follows this line--
Hi,
On Mon, 15 Mar 2010 18:23:42 +0800, Wang Hui hui.w...@windriver.com wrote:
On omap2/3 series platforms, the musb can't raise id pin change
detection interrupt, so we must change otg mode through sysfs
interface manually. Currently when the musb is in B mode, if we
want musb to be changed to A mode, we should plug a mini-A cable
and then execute echo host /sys/devices/platform/musb_hdrc/mode.
But if the musb is in A mode, we can't change it to B mode through
this method.
To solve this problem, add a process for sending end session request.
This process works like this, if the musb is in A mode, it will send
an end session request first, then it will follow original routine:
start a new session, during this session, it will identify whether
A or B is plugging in the socket, then it will init controller to A
or B mode according to its identification.
Just curious about how to do this in a more automatic way.
I think setup a daemon to monitor the musb_hdrc mode and try to alter
it's state via sysfs interface will work, but it may be error prone and
not always desirable solution.
Can we query the id pin state periodically in the kernel and change to
corresponding role?
Regards,
Kanru
Usage: change cable as you desired,
change musb mode by #echo host[peripheral] /sys/devices/\
platform/musb_hdrc/mode,
then you will get required musb mode.
Signed-off-by: Wang Hui hui.w...@windriver.com
---
drivers/usb/musb/omap2430.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 3fe1686..b02897e 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -194,6 +194,11 @@ int musb_platform_set_mode(struct musb *musb, u8
musb_mode)
{
u8 devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
+ if ((devctl MUSB_DEVCTL_BDEVICE) == 0x0) {
+ devctl = ~MUSB_DEVCTL_SESSION;
+ musb_writeb(musb-mregs, MUSB_DEVCTL, devctl);
+ }
+
devctl |= MUSB_DEVCTL_SESSION;
musb_writeb(musb-mregs, MUSB_DEVCTL, devctl);
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Thu, Jul 22, 2010 at 01:47:36PM +0900, FUJITA Tomonori wrote: On Wed, 21 Jul 2010 20:50:26 -0700 Zach Pfeffer zpfef...@codeaurora.org wrote: On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote: On Tue, 13 Jul 2010 10:02:23 +0100 Zach Pfeffer said this new VCM infrastructure can be useful for video4linux. However, I don't think we need 3,000-lines another abstraction layer to solve video4linux's issue nicely. Its only 3000 lines because I haven't converted the code to use function pointers. The main point is adding a new abstraction that don't provide the huge benefit. I disagree. In its current form the API may not be appropriate for inclusion into the kernel, but it provides a common framework for handling a class of problems that have been solved many times in the kernel: large buffer management, IOMMU interoperation and fine grained mapping control. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] USB: musb: omap2430: add mode change from A to B
On 07/22/2010 06:16 PM, Kan-Ru Chen wrote: Just curious about how to do this in a more automatic way. I think setup a daemon to monitor the musb_hdrc mode and try to alter it's state via sysfs interface will work, but it may be error prone and not always desirable solution. Can we query the id pin state periodically in the kernel and change to corresponding role? the transceiver has an interrupt for id pin changes. You can use that instead of polling. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Thu, Jul 22, 2010 at 01:43:26PM +0900, FUJITA Tomonori wrote: On Wed, 21 Jul 2010 21:30:34 -0700 Zach Pfeffer zpfef...@codeaurora.org wrote: On Wed, Jul 21, 2010 at 10:44:37AM +0900, FUJITA Tomonori wrote: On Tue, 20 Jul 2010 15:20:01 -0700 Zach Pfeffer zpfef...@codeaurora.org wrote: I'm not saying that it's reasonable to pass (or even allocate) a 1MB buffer via the DMA API. But given a bunch of large chunks of memory, is there any API that can manage them (asked this on the other thread as well)? What is the problem about mapping a 1MB buffer with the DMA API? Possibly, an IOMMU can't find space for 1MB but it's not the problem of the DMA API. This goes to the nub of the issue. We need a lot of 1 MB physically contiguous chunks. The system is going to fragment and we'll never get our 12 1 MB chunks that we'll need, since the DMA API allocator uses the system pool it will never succeed. For this reason we reserve a pool of 1 MB chunks (and 16 MB, 64 KB etc...) to satisfy our requests. This same use case is seen on most embedded media engines that are getting built today. We don't need a new abstraction to reserve some memory. If you want pre-allocated memory pool per device (and share them with some), the DMA API can for coherent memory (see dma_alloc_from_coherent). You can extend the DMA API if necessary. That function won't work for us. We can't use bitmap_find_free_region(), we need to use our own allocator. If anything we need a dma_alloc_from_custom(my_allocator). Take a look at: mm: iommu: A physical allocator for the VCMM vcm_alloc_max_munch() -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/15] ti dspbridge: Remove CamelCase, reagroup variables
On Fri, Jul 09, 2010 at 09:23:54PM -0500, Rene Sapiens wrote: The intention of this serie of patches is to rename the remaining variables with camel case. Words will be renamed avoiding CamelCase and Hungarian notation. Also the variables in the prototypes will be renamed to make them match with the ones in the function definitions. The variables to be renamed are: snip All applied, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/15] ti dspbridge: Remove CamelCase, reagroup variables
On Fri, Jul 16, 2010 at 07:17:12PM -0500, Omar Ramirez Luna wrote: On 7/9/2010 9:23 PM, Sapiens, Rene wrote: The intention of this serie of patches is to rename the remaining variables with camel case. Words will be renamed avoiding CamelCase and Hungarian notation. Also the variables in the prototypes will be renamed to make them match with the ones in the function definitions. [...] 74 files changed, 2471 insertions(+), 2439 deletions(-) Some of your patches produce: warning: drivers/staging/tidspbridge/include/dspbridge/dspdefs.h has type 100644, expected 100755 None of the files had their permissions changed so I guess they should be fine to merge, unless anybody else complains... so ACK. Yeah, Rene, what are you doing changing the mode of these files? Git shows those types of mode changes. Ick, I'll edit them all out... thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/11] staging: tidspbridge: remove GlobalTypes.h
On Mon, Jul 12, 2010 at 05:56:04PM -0500, Nishanth Menon wrote: Remove custom globaltypes.h header This patch doesn't apply :( thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/11] staging: tidspbridge: replace CONST with c standard const
On Mon, Jul 12, 2010 at 05:56:05PM -0500, Nishanth Menon wrote: Signed-off-by: Nishanth Menon n...@ti.com This one doesn't apply either, so I'll just stop applying this series here. Care to redo the rest of them against the next linux-next so you can sync back up? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] staging: tidspbridge: remove GlobalTypes.h
From: Menon, Nishanth n...@ti.com Remove custom globaltypes.h header Signed-off-by: Nishanth Menon n...@ti.com --- drivers/staging/tidspbridge/hw/GlobalTypes.h | 291 -- drivers/staging/tidspbridge/hw/MMURegAcM.h |1 - drivers/staging/tidspbridge/hw/hw_defs.h |2 - drivers/staging/tidspbridge/hw/hw_mmu.c | 32 --- 4 files changed, 0 insertions(+), 326 deletions(-) delete mode 100644 drivers/staging/tidspbridge/hw/GlobalTypes.h diff --git a/drivers/staging/tidspbridge/hw/GlobalTypes.h b/drivers/staging/tidspbridge/hw/GlobalTypes.h deleted file mode 100644 index 4d142a1..000 --- a/drivers/staging/tidspbridge/hw/GlobalTypes.h +++ /dev/null @@ -1,291 +0,0 @@ -/* - * GlobalTypes.h - * - * DSP-BIOS Bridge driver support functions for TI OMAP processors. - * - * Global HW definitions - * - * Copyright (C) 2007 Texas Instruments, Inc. - * - * This package is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR - * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED - * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. - */ - -#ifndef _GLOBALTYPES_H -#define _GLOBALTYPES_H - -/* - * Definition: RET_CODE_BASE - * - * DESCRIPTION: Base value for return code offsets - */ -#define RET_CODE_BASE 0 - -/* - * Definition: *BIT_OFFSET - * - * DESCRIPTION: offset in bytes from start of 32-bit word. - */ -#define LOWER16BIT_OFFSET0 -#define UPPER16BIT_OFFSET2 - -#define LOWER8BIT_OFFSET 0 -#define LOWER_MIDDLE8BIT_OFFSET1 -#define UPPER_MIDDLE8BIT_OFFSET2 -#define UPPER8BIT_OFFSET 3 - -#define LOWER8BIT_OF16_OFFSET 0 -#define UPPER8BIT_OF16_OFFSET 1 - -/* - * Definition: *BIT_SHIFT - * - * DESCRIPTION: offset in bits from start of 32-bit word. - */ -#define LOWER16BIT_SHIFT 0 -#define UPPER16BIT_SHIFT 16 - -#define LOWER8BIT_SHIFT 0 -#define LOWER_MIDDLE8BIT_SHIFT8 -#define UPPER_MIDDLE8BIT_SHIFT16 -#define UPPER8BIT_SHIFT 24 - -#define LOWER8BIT_OF16_SHIFT 0 -#define UPPER8BIT_OF16_SHIFT 8 - -/* - * Definition: LOWER16BIT_MASK - * - * DESCRIPTION: 16 bit mask used for inclusion of lower 16 bits i.e. mask out - * the upper 16 bits - */ -#define LOWER16BIT_MASK0x - -/* - * Definition: LOWER8BIT_MASK - * - * DESCRIPTION: 8 bit masks used for inclusion of 8 bits i.e. mask out - * the upper 16 bits - */ -#define LOWER8BIT_MASK0x00FF - -/* - * Definition: RETURN32BITS_FROM16LOWER_AND16UPPER(lower16_bits, upper16_bits) - * - * DESCRIPTION: Returns a 32 bit value given a 16 bit lower value and a 16 - * bit upper value - */ -#define RETURN32BITS_FROM16LOWER_AND16UPPER(lower16_bits, upper16_bits)\ -(u32)lower16_bits) LOWER16BIT_MASK)) | \ - (u32)upper16_bits) LOWER16BIT_MASK) UPPER16BIT_SHIFT))) - -/* - * Definition: RETURN16BITS_FROM8LOWER_AND8UPPER(lower16_bits, upper16_bits) - * - * DESCRIPTION: Returns a 16 bit value given a 8 bit lower value and a 8 - *bit upper value - */ -#define RETURN16BITS_FROM8LOWER_AND8UPPER(lower8_bits, upper8_bits)\ -(u32)lower8_bits) LOWER8BIT_MASK)) | \ - (u32)upper8_bits) LOWER8BIT_MASK) UPPER8BIT_OF16_SHIFT))) - -/* - * Definition: RETURN32BITS_FROM48BIT_VALUES(lower8_bits, lower_middle8_bits, - * lower_upper8_bits, upper8_bits) - * - * DESCRIPTION: Returns a 32 bit value given four 8 bit values - */ -#define RETURN32BITS_FROM48BIT_VALUES(lower8_bits, lower_middle8_bits,\ - lower_upper8_bits, upper8_bits)\ - (u32)lower8_bits) LOWER8BIT_MASK)) | \ - (u32)lower_middle8_bits) LOWER8BIT_MASK) \ - LOWER_MIDDLE8BIT_SHIFT)) | \ - (u32)lower_upper8_bits) LOWER8BIT_MASK) \ - UPPER_MIDDLE8BIT_SHIFT)) | \ - (u32)upper8_bits) LOWER8BIT_MASK) \ - UPPER8BIT_SHIFT))) - -/* - * Definition: READ_LOWER16BITS_OF32(value32bits) - * - * DESCRIPTION: Returns a 16 lower bits of 32bit value - */ -#define READ_LOWER16BITS_OF32(value32bits)\ -((u16)((u32)(value32bits) LOWER16BIT_MASK)) - -/* - * Definition: READ_UPPER16BITS_OF32(value32bits) - * - * DESCRIPTION: Returns a 16 lower bits of 32bit value - */ -#define READ_UPPER16BITS_OF32(value32bits)\ - (((u16)((u32)(value32bits) UPPER16BIT_SHIFT)) \ - LOWER16BIT_MASK) - -/* - * Definition: READ_LOWER8BITS_OF32(value32bits) - * - * DESCRIPTION: Returns a 8 lower bits of 32bit value - */ -#define READ_LOWER8BITS_OF32(value32bits)\ -((u8)((u32)(value32bits) LOWER8BIT_MASK)) - -/* - * Definition: READ_LOWER_MIDDLE8BITS_OF32(value32bits) - * - * DESCRIPTION: Returns a 8 lower middle bits of 32bit value - */ -#define
[PATCH 6/6] staging: tidspbridge: remove dbdefs.h
From: Menon, Nishanth n...@ti.com Remove yet another custom definition header Signed-off-by: Nishanth Menon n...@ti.com --- .../staging/tidspbridge/include/dspbridge/dbdefs.h |1 - .../staging/tidspbridge/include/dspbridge/dbtype.h | 69 .../tidspbridge/include/dspbridge/host_os.h|1 - 3 files changed, 0 insertions(+), 71 deletions(-) delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dbtype.h diff --git a/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h b/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h index a815b67..8f84735 100644 --- a/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h +++ b/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h @@ -21,7 +21,6 @@ #include linux/types.h -#include dspbridge/dbtype.h /* GPP side type definitions */ #include dspbridge/rms_sh.h /* Types shared between GPP and DSP */ #define PG_SIZE4K 4096 diff --git a/drivers/staging/tidspbridge/include/dspbridge/dbtype.h b/drivers/staging/tidspbridge/include/dspbridge/dbtype.h deleted file mode 100644 index ca5eaf8..000 --- a/drivers/staging/tidspbridge/include/dspbridge/dbtype.h +++ /dev/null @@ -1,69 +0,0 @@ -/* - * dbtype.h - * - * DSP-BIOS Bridge driver support functions for TI OMAP processors. - * - * This header defines data types for DSP/BIOS Bridge APIs and device - * driver modules. It also defines the Hungarian prefix to use for each - * base type. - * - * Copyright (C) 2008 Texas Instruments, Inc. - * - * This package is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR - * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED - * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. - */ - -#ifndef DBTYPE_ -#define DBTYPE_ - -/*===*/ -/* Argument specification syntax */ -/*===*/ - -#ifndef IN -#define IN /* Following parameter is for input. */ -#endif - -#ifndef OUT -#define OUT/* Following parameter is for output. */ -#endif - -#ifndef OPTIONAL -#define OPTIONAL /* Function may optionally use previous parameter. */ -#endif - -#ifndef CONST -#define CONST const -#endif - -/*===*/ -/* NULL character (normally used for string termination) */ -/*===*/ - -#ifndef NULL_CHAR -#define NULL_CHAR'\0' /* Null character. */ -#endif - -/*===*/ -/* Basic Type definitions (with Prefixes for Hungarian notation) */ -/*===*/ - -#ifndef OMAPBRIDGE_TYPES -#define OMAPBRIDGE_TYPES -typedef volatile unsigned short reg_uword16; -#endif - -#define TEXT(x) x - -#define DLLIMPORT -#define DLLEXPORT - -/* Define DSPAPIDLL correctly in dspapi.h */ -#define _DSPSYSDLL32_ - -#endif /* DBTYPE_ */ diff --git a/drivers/staging/tidspbridge/include/dspbridge/host_os.h b/drivers/staging/tidspbridge/include/dspbridge/host_os.h index a91c136..6b4feb4 100644 --- a/drivers/staging/tidspbridge/include/dspbridge/host_os.h +++ b/drivers/staging/tidspbridge/include/dspbridge/host_os.h @@ -42,7 +42,6 @@ #include linux/vmalloc.h #include linux/ioport.h #include linux/platform_device.h -#include dspbridge/dbtype.h #include plat/clock.h #include linux/clk.h #include plat/mailbox.h -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] staging: tidspbridge: replace CONST with c standard const
From: Menon, Nishanth n...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/staging/tidspbridge/core/chnl_sm.c |4 ++--
drivers/staging/tidspbridge/core/io_sm.c |2 +-
drivers/staging/tidspbridge/core/msg_sm.c |2 +-
drivers/staging/tidspbridge/core/tiomap3430.c |2 +-
.../staging/tidspbridge/include/dspbridge/chnl.h |2 +-
.../staging/tidspbridge/include/dspbridge/cmm.h|2 +-
.../staging/tidspbridge/include/dspbridge/cod.h|2 +-
.../staging/tidspbridge/include/dspbridge/dev.h|8
.../staging/tidspbridge/include/dspbridge/disp.h |4 ++--
.../staging/tidspbridge/include/dspbridge/dmm.h|2 +-
.../tidspbridge/include/dspbridge/dspchnl.h|4 ++--
.../tidspbridge/include/dspbridge/dspdefs.h| 10 +-
.../staging/tidspbridge/include/dspbridge/dspio.h |2 +-
.../staging/tidspbridge/include/dspbridge/dspmsg.h |2 +-
drivers/staging/tidspbridge/include/dspbridge/io.h |2 +-
.../staging/tidspbridge/include/dspbridge/nldr.h |4 ++--
.../tidspbridge/include/dspbridge/nldrdefs.h |4 ++--
.../staging/tidspbridge/include/dspbridge/node.h | 10 +-
.../staging/tidspbridge/include/dspbridge/proc.h |6 +++---
.../staging/tidspbridge/include/dspbridge/pwr.h|4 ++--
drivers/staging/tidspbridge/pmgr/chnl.c|2 +-
drivers/staging/tidspbridge/pmgr/cmm.c |2 +-
drivers/staging/tidspbridge/pmgr/cod.c |4 ++--
drivers/staging/tidspbridge/pmgr/dev.c |4 ++--
drivers/staging/tidspbridge/pmgr/dmm.c |2 +-
drivers/staging/tidspbridge/pmgr/dspapi.c |2 +-
drivers/staging/tidspbridge/pmgr/io.c |2 +-
drivers/staging/tidspbridge/rmgr/disp.c|4 ++--
drivers/staging/tidspbridge/rmgr/nldr.c|4 ++--
drivers/staging/tidspbridge/rmgr/node.c| 14 +++---
drivers/staging/tidspbridge/rmgr/proc.c|8
drivers/staging/tidspbridge/rmgr/pwr.c |4 ++--
32 files changed, 65 insertions(+), 65 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/chnl_sm.c
b/drivers/staging/tidspbridge/core/chnl_sm.c
index db106f3..39e9691 100644
--- a/drivers/staging/tidspbridge/core/chnl_sm.c
+++ b/drivers/staging/tidspbridge/core/chnl_sm.c
@@ -383,7 +383,7 @@ func_cont:
*/
int bridge_chnl_create(OUT struct chnl_mgr **channel_mgr,
struct dev_object *hdev_obj,
- IN CONST struct chnl_mgrattrs *mgr_attrts)
+ IN const struct chnl_mgrattrs *mgr_attrts)
{
int status = 0;
struct chnl_mgr *chnl_mgr_obj = NULL;
@@ -777,7 +777,7 @@ int bridge_chnl_idle(struct chnl_object *chnl_obj, u32
timeout,
*/
int bridge_chnl_open(OUT struct chnl_object **chnl,
struct chnl_mgr *hchnl_mgr, s8 chnl_mode,
- u32 ch_id, CONST IN struct chnl_attr *pattrs)
+ u32 ch_id, const IN struct chnl_attr *pattrs)
{
int status = 0;
struct chnl_mgr *chnl_mgr_obj = hchnl_mgr;
diff --git a/drivers/staging/tidspbridge/core/io_sm.c
b/drivers/staging/tidspbridge/core/io_sm.c
index 31b623a..27f4481 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -163,7 +163,7 @@ static int register_shm_segs(struct io_mgr *hio_mgr,
*/
int bridge_io_create(OUT struct io_mgr **io_man,
struct dev_object *hdev_obj,
- IN CONST struct io_attrs *mgr_attrts)
+ IN const struct io_attrs *mgr_attrts)
{
int status = 0;
struct io_mgr *pio_mgr = NULL;
diff --git a/drivers/staging/tidspbridge/core/msg_sm.c
b/drivers/staging/tidspbridge/core/msg_sm.c
index a86f0ce..6434854 100644
--- a/drivers/staging/tidspbridge/core/msg_sm.c
+++ b/drivers/staging/tidspbridge/core/msg_sm.c
@@ -383,7 +383,7 @@ func_end:
* Put a message onto a msg_ctrl queue.
*/
int bridge_msg_put(struct msg_queue *msg_queue_obj,
- IN CONST struct dsp_msg *pmsg, u32 utimeout)
+ IN const struct dsp_msg *pmsg, u32 utimeout)
{
struct msg_frame *msg_frame_obj;
struct msg_mgr *hmsg_mgr;
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 745e1a5..428389b 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -237,7 +237,7 @@ static void bad_page_dump(u32 pa, struct page *pg)
* Bridge Driver entry point.
*/
void bridge_drv_entry(OUT struct bridge_drv_interface **drv_intf,
- IN CONST char *driver_file_name)
+ IN const char *driver_file_name)
{
DBC_REQUIRE(driver_file_name != NULL);
diff
[PATCH v2 0/6] staging: tidspbridge: header cleanup series
Rebased version of the patches that couldn't be applied. Original set: [1] http://marc.info/?l=linux-kernelm=127897548706686w=2 [2] http://marc.info/?l=linux-kernelm=127982129204138w=2 Fixed unexpected change while replacing IN modifier [3] http://marc.info/?l=linux-kernelm=127972475532227w=2 Menon, Nishanth (6): staging: tidspbridge: remove GlobalTypes.h staging: tidspbridge: replace CONST with c standard const staging: tidspbridge: remove IN modifier staging: tidspbridge: remove OPTIONAL staging: tidspbridge: remove OUT define staging: tidspbridge: remove dbdefs.h drivers/staging/tidspbridge/core/_tiomap_pwr.h | 14 +- drivers/staging/tidspbridge/core/chnl_sm.c | 20 +- drivers/staging/tidspbridge/core/dsp-clock.c |4 +- drivers/staging/tidspbridge/core/io_sm.c | 26 +- drivers/staging/tidspbridge/core/msg_sm.c |6 +- drivers/staging/tidspbridge/core/tiomap3430.c | 28 +- drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 14 +- drivers/staging/tidspbridge/core/tiomap_io.c |6 +- drivers/staging/tidspbridge/core/tiomap_io.h | 14 +- drivers/staging/tidspbridge/dynload/cload.c|2 +- .../tidspbridge/dynload/tramp_table_c6000.c|2 +- drivers/staging/tidspbridge/gen/uuidutil.c |6 +- drivers/staging/tidspbridge/hw/GlobalTypes.h | 291 drivers/staging/tidspbridge/hw/MMURegAcM.h |1 - drivers/staging/tidspbridge/hw/hw_defs.h |2 - drivers/staging/tidspbridge/hw/hw_mmu.c| 32 --- .../staging/tidspbridge/include/dspbridge/cfg.h| 28 +- .../staging/tidspbridge/include/dspbridge/chnl.h |4 +- .../staging/tidspbridge/include/dspbridge/clk.h|4 +- .../staging/tidspbridge/include/dspbridge/cmm.h| 14 +- .../staging/tidspbridge/include/dspbridge/cod.h| 20 +- .../staging/tidspbridge/include/dspbridge/dbdcd.h | 74 +++--- .../tidspbridge/include/dspbridge/dbdcddef.h |6 +- .../staging/tidspbridge/include/dspbridge/dbdefs.h |1 - .../staging/tidspbridge/include/dspbridge/dbtype.h | 69 - .../staging/tidspbridge/include/dspbridge/dev.h| 46 ++-- .../staging/tidspbridge/include/dspbridge/disp.h |8 +- .../staging/tidspbridge/include/dspbridge/dmm.h|6 +- .../staging/tidspbridge/include/dspbridge/drv.h| 12 +- .../tidspbridge/include/dspbridge/dspapi-ioctl.h |2 +- .../tidspbridge/include/dspbridge/dspchnl.h| 16 +- .../tidspbridge/include/dspbridge/dspdefs.h| 44 ++-- .../staging/tidspbridge/include/dspbridge/dspdrv.h |2 +- .../staging/tidspbridge/include/dspbridge/dspio.h |8 +- .../staging/tidspbridge/include/dspbridge/dspmsg.h |6 +- .../tidspbridge/include/dspbridge/host_os.h|1 - drivers/staging/tidspbridge/include/dspbridge/io.h |4 +- .../staging/tidspbridge/include/dspbridge/io_sm.h | 10 +- .../staging/tidspbridge/include/dspbridge/mgr.h| 16 +- .../staging/tidspbridge/include/dspbridge/msg.h|2 +- .../staging/tidspbridge/include/dspbridge/nldr.h | 12 +- .../tidspbridge/include/dspbridge/nldrdefs.h | 10 +- .../staging/tidspbridge/include/dspbridge/node.h | 40 ++-- .../tidspbridge/include/dspbridge/nodepriv.h |2 +- .../staging/tidspbridge/include/dspbridge/proc.h | 18 +- .../staging/tidspbridge/include/dspbridge/pwr.h|8 +- .../staging/tidspbridge/include/dspbridge/strm.h | 22 +- .../tidspbridge/include/dspbridge/uuidutil.h |6 +- drivers/staging/tidspbridge/pmgr/chnl.c|4 +- drivers/staging/tidspbridge/pmgr/cmm.c | 14 +- drivers/staging/tidspbridge/pmgr/cod.c | 18 +- drivers/staging/tidspbridge/pmgr/dev.c | 36 ++-- drivers/staging/tidspbridge/pmgr/dmm.c |6 +- drivers/staging/tidspbridge/pmgr/dspapi.c |4 +- drivers/staging/tidspbridge/pmgr/io.c |4 +- drivers/staging/tidspbridge/pmgr/msg.c |2 +- drivers/staging/tidspbridge/rmgr/dbdcd.c | 94 drivers/staging/tidspbridge/rmgr/disp.c| 10 +- drivers/staging/tidspbridge/rmgr/drv.c |6 +- drivers/staging/tidspbridge/rmgr/dspdrv.c |2 +- drivers/staging/tidspbridge/rmgr/mgr.c | 14 +- drivers/staging/tidspbridge/rmgr/nldr.c| 22 +- drivers/staging/tidspbridge/rmgr/node.c| 44 ++-- drivers/staging/tidspbridge/rmgr/proc.c| 18 +- drivers/staging/tidspbridge/rmgr/pwr.c |8 +- drivers/staging/tidspbridge/rmgr/strm.c| 18 +- drivers/staging/tidspbridge/services/cfg.c |8 +- 67 files changed, 462 insertions(+), 859 deletions(-) delete mode 100644 drivers/staging/tidspbridge/hw/GlobalTypes.h delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dbtype.h -- To unsubscribe
Re: Serial console not working after waking up from sleep
Sapiens, Rene rene.sapiens at ti.com writes: You can do a telnet to the device... you should be able to work with it but your serial session will show the garbage. Regards, Rene Hello, I am in essentially the same position, but currently working off of the pm-head branch. I am just using an initramfs, and have tried a few variations. With no_console_suspend set, I can trigger a wakeup using the wakeup_timer_seconds. The power usage goes back to the pre-suspend level, and I see text indicating a successful wakeup, but the console never comes back. Without no_console_suspend set, I can trigger the wakeup again with wakeup_timer_seconds, a console prompt comes back, but is unresponsive. I saw Rene's response about using Telnet, but this implies that there is an ethernet interface available. I have a custom board that only has a serial interface for external visibility, so at this point I lose insight into what is happening on the board. I have two questions, if people would be so willing to oblige: 1) Does anyone know why the console doesn't come back after wakeup? Is this something that may work in the future? 2) Does the console freezing mean that the other COM ports also don't work? Would communication on other interfaces continue to work? For example, a GPS plugged into one of the other COM ports? Thanks, Tyler -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] staging: tidspbridge: header cleanup series
On Thu, Jul 22, 2010 at 04:03:44PM -0500, Omar Ramirez Luna wrote: Rebased version of the patches that couldn't be applied. All applied, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/20] native support for wl1271 on ZOOM
On Wed, 21 Jul 2010, Ohad Ben-Cohen wrote: This patch series adds native support for wl1271 on ZOOM. Changes since v1: - introduce a fixed regulator device to control the power of wl1271 - allow to propagate private board-specific data to SDIO function drivers - allow SDIO function driver to control the card's power via new API - make it possible to keep the card's power down (without depending on an explicit SDIO function driver power-down request) Thanks to these changes, we no longer need a separate platform device (carrying e.g. the external irq information of the device), and no longer need to emulate virtual card detect events. The two board muxing pathces were already taken by Tony, and are resent here just to make it easier for people to use/test these pathces. The changes to the MMC core really needs careful review; there still might be some pitfalls that haven't been covered. E.g., one thing we plan to look at next is their bahvior together with SDIO Suspend/Resume. Special thanks to Roger Quadros and Nicolas Pitre for their extensive review and helpful suggestions. FYI, I do intend to review those patches, but I'll be flying home in a couple hours, and once there I'll be gone on vacation for 2 weeks. So this review won't happen right away. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/20] omap: zoom: add fixed regulator device for wlan
On Thu, Jul 22, 2010 at 2:16 PM, Roger Quadros roger.quad...@nokia.com wrote:
On 07/21/2010 08:59 PM, ext Mark Brown wrote:
On Wed, Jul 21, 2010 at 08:33:44PM +0300, Ohad Ben-Cohen wrote:
+static struct regulator_consumer_supply zoom_vmmc3_supply = {
+ .supply = vmmc,
+};
This looks like a misconfiguration on the consumer - I'd strongly expect
the consumer to have a dev_name specified also with the name being in
terms of the consumer device.
you need to add something like
.dev_name = mmci-omap-hs.2
I already set the .dev member of the consumer in a similar manner to
how all other regulators are configured in this board - please check
out patch 13:
https://patchwork.kernel.org/patch/113418/
Does this look reasonable to you ?
Thanks,
Ohad.
regards,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 19/20] omap: zoom: keep the MMC3 wl1271 device powered off
Hi Gever,
On Wed, Jul 21, 2010 at 9:55 PM, Gabay, Benzy ben...@ti.com wrote:
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: Wednesday, July 21, 2010 12:34 PM
To: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org;
linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk; Chikkature
Rajashekar, Madhusudhan; Luciano Coelho; a...@linux-foundation.org; San
Mehat; Roger Quadros; Tony Lindgren; Nicolas Pitre; Pandita, Vikram; Kalle
Valo; Ohad Ben-Cohen
Subject: [PATCH v2 19/20] omap: zoom: keep the MMC3 wl1271 device powered off
Keep the MMC3 wl1271 WLAN device powered off until its
SDIO function driver requests otherwise.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 1 +
arch/arm/mach-omap2/hsmmc.c | 3 +++
arch/arm/mach-omap2/hsmmc.h | 1 +
arch/arm/plat-omap/include/plat/mmc.h | 3 +++
drivers/mmc/host/omap_hsmmc.c | 3 +++
5 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 3230801..3ab9125 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -217,6 +217,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.gpio_wp = -EINVAL,
.gpio_cd = -EINVAL,
.ocr_mask = MMC_VDD_165_195,
+ .dont_power_card = true,
.priv_data = omap_zoom_wlan_data,
},
{} /* Terminator */
...
--
1.7.0.4
[Benzy Gabay] small comment: Please make sure that all 127x related changes
are not bounded only to MMC3.
On OMAP4 WLAN is used on MMC5.
The only place MMC3 is bound is in the board files (see code snippet
above), so that should be ok.
I can probably split this patch to make this more obvious just by
reading the diffstat if you prefer.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/20] sdio: add TI + wl1271 ids
Hi Marcel, On Wed, Jul 21, 2010 at 8:58 PM, Marcel Holtmann mar...@holtmann.org wrote: Add SDIO IDs for TI and for TI's wl1271 wlan device. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- include/linux/mmc/sdio_ids.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h index 33b2ea0..0d313c6 100644 --- a/include/linux/mmc/sdio_ids.h +++ b/include/linux/mmc/sdio_ids.h @@ -43,4 +43,7 @@ #define SDIO_DEVICE_ID_SIANO_NOVA_A0 0x1100 #define SDIO_DEVICE_ID_SIANO_STELLAR 0x5347 +#define SDIO_VENDOR_ID_TI 0x0097 +#define SDIO_DEVICE_ID_TI_WL1271 0x4076 + are we still doing this non-sense for no real reason. What is so wrong with keeping the IDs inside the driver code? Either way we can't go so wrong here (having global VENDOR_IDs can potentially prevent redefinitions of the same ID in different drivers, but that's probably not that big of an issue too). But if we prefer people to stop adding IDs to this global pool, let's at least make it clear. We can probably seal it with some please don't add new IDs if you don't have to footnote (care to send such patch ? :) Thanks, Ohad. Personally I don't even see a point for these ID defines at all. Just use the bare numbers in SDIO_DEVICE and put a comment above what kind of device this is. Regards Marcel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/20] native support for wl1271 on ZOOM
On Fri, Jul 23, 2010 at 1:56 AM, Nicolas Pitre n...@fluxnic.net wrote: On Wed, 21 Jul 2010, Ohad Ben-Cohen wrote: This patch series adds native support for wl1271 on ZOOM. Changes since v1: - introduce a fixed regulator device to control the power of wl1271 - allow to propagate private board-specific data to SDIO function drivers - allow SDIO function driver to control the card's power via new API - make it possible to keep the card's power down (without depending on an explicit SDIO function driver power-down request) Thanks to these changes, we no longer need a separate platform device (carrying e.g. the external irq information of the device), and no longer need to emulate virtual card detect events. The two board muxing pathces were already taken by Tony, and are resent here just to make it easier for people to use/test these pathces. The changes to the MMC core really needs careful review; there still might be some pitfalls that haven't been covered. E.g., one thing we plan to look at next is their bahvior together with SDIO Suspend/Resume. Special thanks to Roger Quadros and Nicolas Pitre for their extensive review and helpful suggestions. FYI, I do intend to review those patches, but I'll be flying home in a couple hours, and once there I'll be gone on vacation for 2 weeks. So this review won't happen right away. Thanks, Nicolas. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap:mailbox-provide multiple reader support
Phil,
Thanks for looking at the patch.
On Wed, Jul 21, 2010 at 4:45 AM, ext-phil.2.carm...@nokia.com wrote:
Apologies - top posting and not quoting properly due to having to use MS's
braindead OWA.
It appears that most of the changes are simply indentation changes caused
by the inclusion of a new inner block here:
-- I don't know if we can say most of the changes are simply
indentation changes.
+ if (atomic_inc_return(mbox-use_count) == 1) {
rather than just using a goto to skip past the unneeded parts. (Hmmm, is it
not simply an immediate return now?)
The goto/return is both more idiomatic in linux, and I'm sure a simpler patch.
-- Sure, I will make the change.
Phil
From: linux-omap-ow...@vger.kernel.org [linux-omap-ow...@vger.kernel.org] On
Behalf Of ext Hari Kanigeri [h-kanige...@ti.com]
Sent: 21 July 2010 01:41
To: Linux Omap; Tony Lindgren; Doyu Hiroshi (Nokia-MS/Helsinki)
Cc: Ohad Ben-Cohen; Hari Kanigeri
Subject: [PATCH 2/2] omap:mailbox-provide multiple reader support
This patch provides mutiple readers support for a mailbox
instance.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h | 6 ++-
arch/arm/plat-omap/mailbox.c | 63
2 files changed, 40 insertions(+), 29 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 0486d64..c8e47d8 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -68,13 +68,15 @@ struct omap_mbox {
void *priv;
void (*err_notify)(void);
+ atomic_t use_count;
+ struct blocking_notifier_head notifier;
};
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
void omap_mbox_init_seq(struct omap_mbox *);
-struct omap_mbox *omap_mbox_get(const char *);
-void omap_mbox_put(struct omap_mbox *);
+struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
+void omap_mbox_put(struct omap_mbox *, struct notifier_block *nb);
int omap_mbox_register(struct device *parent, struct omap_mbox *);
int omap_mbox_unregister(struct omap_mbox *);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index baac315..f9f2af4 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -149,8 +149,8 @@ static void mbox_rx_work(struct work_struct *work)
if (unlikely(len != sizeof(msg)))
pr_err(%s: kfifo_out anomaly detected\n, __func__);
- if (mq-callback)
- mq-callback((void *)msg);
+ blocking_notifier_call_chain(mq-mbox-notifier, len,
+ (void *)msg);
}
}
@@ -252,28 +252,30 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
}
}
- ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
- mbox-name, mbox);
- if (unlikely(ret)) {
- printk(KERN_ERR
- failed to register mailbox interrupt:%d\n, ret);
- goto fail_request_irq;
- }
+ if (atomic_inc_return(mbox-use_count) == 1) {
+ ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
+ mbox-name, mbox);
+ if (unlikely(ret)) {
+ printk(KERN_ERR failed to register mailbox
interrupt:
+ %d\n, ret);
+ goto fail_request_irq;
+ }
- mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
- if (!mq) {
- ret = -ENOMEM;
- goto fail_alloc_txq;
- }
- mbox-txq = mq;
+ mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
+ if (!mq) {
+ ret = -ENOMEM;
+ goto fail_alloc_txq;
+ }
+ mbox-txq = mq;
- mq = mbox_queue_alloc(mbox, mbox_rx_work, NULL);
- if (!mq) {
- ret = -ENOMEM;
- goto fail_alloc_rxq;
+ mq = mbox_queue_alloc(mbox, mbox_rx_work, NULL);
+ if (!mq) {
+ ret = -ENOMEM;
+ goto fail_alloc_rxq;
+ }
+ mbox-rxq = mq;
+ mq-mbox = mbox;
}
- mbox-rxq = mq;
-
return 0;
fail_alloc_rxq:
@@ -281,6 +283,7 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
fail_alloc_txq:
free_irq(mbox-irq, mbox);
fail_request_irq:
+ atomic_dec(mbox-use_count);
if (likely(mbox-ops-shutdown)) {
if (atomic_dec_return(mbox_refcount) == 0)
Re: [PATCH 2/2] omap:mailbox-provide multiple reader support
Fernando,
Thanks for looking at the patch.
On Tue, Jul 20, 2010 at 4:59 PM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
Hi Hari,
@@ -252,28 +252,30 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
}
}
- ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
- mbox-name, mbox);
- if (unlikely(ret)) {
- printk(KERN_ERR
- failed to register mailbox interrupt:%d\n, ret);
- goto fail_request_irq;
- }
+ if (atomic_inc_return(mbox-use_count) == 1) {
What happen if a thread is preempted by other thread which also uses the same
mailbox after doing the atomic_inc?
The second thread also will call atomic_inc_return and in this case the value
returned will be 2 and it will not initialize the mbox queues but it will
return success status, in this point the second thread will think it could
get the mailbox handle without any issue. However the first thread still can
fail and not initialize correctly the mailbox leading second thread to not
work properly or crash.
I think all the initialization should be protected and not just the use_count.
-- How about changing mboxes_lock from spinlock to mutex and
protecting the initialization code ? I guess then the variables don't
have to be atomic too. please share your thougts.
Please let me know what you think.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] USB: musb: omap2430: add mode change from A to B
On Thu, 22 Jul 2010 19:40:44 +0300, Felipe Balbi m...@felipebalbi.com wrote: On 07/22/2010 06:16 PM, Kan-Ru Chen wrote: Just curious about how to do this in a more automatic way. I think setup a daemon to monitor the musb_hdrc mode and try to alter it's state via sysfs interface will work, but it may be error prone and not always desirable solution. Can we query the id pin state periodically in the kernel and change to corresponding role? the transceiver has an interrupt for id pin changes. You can use that instead of polling. Thanks, I see. The twl4030_usb transceiver did get the id pin chanegs 7twl4030_usb twl4030_usb: HW_CONDITIONS 0x50/80; link 1 7twl4030_usb twl4030_usb: HW_CONDITIONS 0x54/84; link 3 So the problem is when OTG enter a_host mode then disconnected, it becomes idle. Plug the peripheral device back would not trigger new session unless I do echo otg /sys/devices/platform/musb_hdrc/mode -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] OMAP: DSS2: Add new overlay object for Video3 pipeline
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Taneja, Archit
Sent: Monday, July 19, 2010 5:26 PM
To: tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Semwal, Sumit; Mittal, Mukund; Taneja,
Archit
Subject: [PATCH 3/5] OMAP: DSS2: Add new overlay object for Video3 pipeline
From: Sumit Semwal sumit.sem...@ti.com
Add new overlay object for the Video3 pipeline in overlay.c.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/manager.c | 13 +++--
drivers/video/omap2/dss/overlay.c | 18 ++
2 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/video/omap2/dss/manager.c
b/drivers/video/omap2/dss/manager.c
index 96073f5..bccb7b6
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -35,6 +35,7 @@
#include dss.h
#define MAX_DSS_MANAGERS (cpu_is_omap44xx() ? 3 : 2)
+#define MAX_DSS_OVERLAYS (cpu_is_omap44xx() ? 4 : 3)
static int num_managers;
static struct list_head manager_list;
@@ -450,7 +451,7 @@ struct manager_cache_data {
static struct {
spinlock_t lock;
- struct overlay_cache_data overlay_cache[3];
+ struct overlay_cache_data overlay_cache[4];
struct manager_cache_data manager_cache[3];
bool irq_enabled;
@@ -893,7 +894,7 @@ static int configure_dispc(void)
{
struct overlay_cache_data *oc;
struct manager_cache_data *mc;
- const int num_ovls = ARRAY_SIZE(dss_cache.overlay_cache);
+ const int num_ovls = MAX_DSS_OVERLAYS;
[Hiremath, Vaibhav] You may want to clean this up, since now you have global
definition MAX_DSS_OVERLAYS.
Applies to everywhere its being used.
const int num_mgrs = MAX_DSS_MANAGERS;
int i;
int r;
@@ -1000,7 +1001,7 @@ void dss_setup_partial_planes(struct omap_dss_device
*dssdev,
{
struct overlay_cache_data *oc;
struct manager_cache_data *mc;
- const int num_ovls = ARRAY_SIZE(dss_cache.overlay_cache);
+ const int num_ovls = MAX_DSS_OVERLAYS;
[Hiremath, Vaibhav] Ditto.
struct omap_overlay_manager *mgr;
int i;
u16 x, y, w, h;
@@ -1132,7 +1133,7 @@ void dss_start_update(struct omap_dss_device *dssdev)
{
struct manager_cache_data *mc;
struct overlay_cache_data *oc;
- const int num_ovls = ARRAY_SIZE(dss_cache.overlay_cache);
+ const int num_ovls = MAX_DSS_OVERLAYS;
[Hiremath, Vaibhav] Ditto.
const int num_mgrs = MAX_DSS_MANAGERS;
struct omap_overlay_manager *mgr;
int i;
@@ -1162,8 +1163,8 @@ static void dss_apply_irq_handler(void *data, u32
mask)
{
struct manager_cache_data *mc;
struct overlay_cache_data *oc;
- const int num_ovls = ARRAY_SIZE(dss_cache.overlay_cache);
- const int num_mgrs = ARRAY_SIZE(dss_cache.manager_cache);
+ const int num_ovls = MAX_DSS_OVERLAYS;
+ const int num_mgrs = MAX_DSS_MANAGERS;
int i, r;
bool mgr_busy[MAX_DSS_MANAGERS];
diff --git a/drivers/video/omap2/dss/overlay.c
b/drivers/video/omap2/dss/overlay.c
index 29aa157..2f8f89c
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -36,6 +36,8 @@
#include dss.h
+#define MAX_DSS_OVERLAYS (cpu_is_omap44xx() ? 4 : 3)
+
[Hiremath, Vaibhav] Since this definition is being used in multiple file,
consider moving this to dss.h file so that we have one place to see/modify in
the future.
Thanks,
Vaibhav
static int num_overlays;
static struct list_head overlay_list;
@@ -510,11 +512,11 @@ static void omap_dss_add_overlay(struct omap_overlay
*overlay)
list_add_tail(overlay-list, overlay_list);
}
-static struct omap_overlay *dispc_overlays[3];
+static struct omap_overlay *dispc_overlays[4];
void dss_overlay_setup_dispc_manager(struct omap_overlay_manager *mgr)
{
- mgr-num_overlays = 3;
+ mgr-num_overlays = MAX_DSS_OVERLAYS;
mgr-overlays = dispc_overlays;
}
@@ -535,7 +537,7 @@ void dss_init_overlays(struct platform_device *pdev)
num_overlays = 0;
- for (i = 0; i 3; ++i) {
+ for (i = 0; i MAX_DSS_OVERLAYS; ++i) {
struct omap_overlay *ovl;
ovl = kzalloc(sizeof(*ovl), GFP_KERNEL);
@@ -571,6 +573,14 @@ void dss_init_overlays(struct platform_device *pdev)
OMAP_DSS_OVL_CAP_DISPC;
ovl-info.global_alpha = 255;
break;
+ case 3:
+ ovl-name = vid3;
+ ovl-id = OMAP_DSS_VIDEO3;
+ ovl-supported_modes = OMAP_DSS_COLOR_VID3_OMAP3;
+ ovl-caps = OMAP_DSS_OVL_CAP_SCALE |
+ OMAP_DSS_OVL_CAP_DISPC;
+ ovl-info.global_alpha = 255;
+
foo
unsubscribe -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] OMAP: DSS2: Add new overlay object for Video3 pipeline
Hi,
-Original Message-
From: Hiremath, Vaibhav
Sent: Friday, July 23, 2010 10:54 AM
To: Taneja, Archit; tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Semwal, Sumit; Mittal, Mukund
Subject: RE: [PATCH 3/5] OMAP: DSS2: Add new overlay object
for Video3 pipeline
snap
struct overlay_cache_data *oc;
struct manager_cache_data *mc;
- const int num_ovls = ARRAY_SIZE(dss_cache.overlay_cache);
+ const int num_ovls = MAX_DSS_OVERLAYS;
[Hiremath, Vaibhav] You may want to clean this up, since now
you have global definition MAX_DSS_OVERLAYS.
Applies to everywhere its being used.
const int num_mgrs = MAX_DSS_MANAGERS;
int i;
int r;
@@ -1000,7 +1001,7 @@ void dss_setup_partial_planes(struct
omap_dss_device *dssdev, {
struct overlay_cache_data *oc;
struct manager_cache_data *mc;
- const int num_ovls = ARRAY_SIZE(dss_cache.overlay_cache);
+ const int num_ovls = MAX_DSS_OVERLAYS;
[Hiremath, Vaibhav] Ditto.
struct omap_overlay_manager *mgr;
int i;
u16 x, y, w, h;
@@ -1132,7 +1133,7 @@ void dss_start_update(struct omap_dss_device
*dssdev) {
struct manager_cache_data *mc;
struct overlay_cache_data *oc;
- const int num_ovls = ARRAY_SIZE(dss_cache.overlay_cache);
+ const int num_ovls = MAX_DSS_OVERLAYS;
[Hiremath, Vaibhav] Ditto.
const int num_mgrs = MAX_DSS_MANAGERS;
struct omap_overlay_manager *mgr;
int i;
@@ -1162,8 +1163,8 @@ static void dss_apply_irq_handler(void *data,
u32
mask)
{
struct manager_cache_data *mc;
struct overlay_cache_data *oc;
- const int num_ovls = ARRAY_SIZE(dss_cache.overlay_cache);
- const int num_mgrs = ARRAY_SIZE(dss_cache.manager_cache);
+ const int num_ovls = MAX_DSS_OVERLAYS;
+ const int num_mgrs = MAX_DSS_MANAGERS;
int i, r;
bool mgr_busy[MAX_DSS_MANAGERS];
diff --git a/drivers/video/omap2/dss/overlay.c
b/drivers/video/omap2/dss/overlay.c
index 29aa157..2f8f89c
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -36,6 +36,8 @@
#include dss.h
+#define MAX_DSS_OVERLAYS (cpu_is_omap44xx() ? 4 : 3)
+
[Hiremath, Vaibhav] Since this definition is being used in
multiple file, consider moving this to dss.h file so that we
have one place to see/modify in the future.
Thanks,
Vaibhav
Thanks for the comments, I will incorporate the following changes:
-remove const int num_mgrs and num_ovls variables as they are replaced
by the new globals everywhere.
-shift the MAX_DSS_OVERLAYS and MAX_DSS_MANAGERS to dss.h
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] OMAP: DSS2: Video3 pipeline IRQs
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Archit Taneja
Sent: Monday, July 19, 2010 5:26 PM
To: tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Semwal, Sumit; Mittal, Mukund; Taneja,
Archit
Subject: [PATCH 4/5] OMAP: DSS2: Video3 pipeline IRQs
From: Sumit Semwal sumit.sem...@ti.com
Introduce Video3 pipeline IRQS for dumps and error handling
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
arch/arm/plat-omap/include/plat/display.h |2 ++
drivers/video/omap2/dss/dispc.c | 23 ++-
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/display.h b/arch/arm/plat-
omap/include/plat/display.h
index be83766..91796b6
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -44,6 +44,8 @@
#define DISPC_IRQ_WAKEUP (1 16)
#define DISPC_IRQ_SYNC_LOST_2 (1 17)
#define DISPC_IRQ_VSYNC2 (1 18)
+#define DISPC_IRQ_VID3_END_WIN (1 19)
+#define DISPC_IRQ_VID3_FIFO_UNDERFLOW(1 20)
#define DISPC_IRQ_ACBIAS_COUNT_STAT2 (1 21)
#define DISPC_IRQ_FRAMEDONE2 (1 22)
diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index 00aad04..8345ed7
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -173,7 +173,8 @@ struct dispc_reg { u16 idx; };
DISPC_IRQ_SYNC_LOST | \
DISPC_IRQ_SYNC_LOST_DIGIT | \
(cpu_is_omap44xx() ? \
- DISPC_IRQ_SYNC_LOST_2 : 0))
+ (DISPC_IRQ_VID3_FIFO_UNDERFLOW | \
+ DISPC_IRQ_SYNC_LOST_2) : 0))
[Hiremath, Vaibhav] This looks bit suspicious to me, against which tree this
patch has been generated? I think you have missed some of the patches in
between.
#define DISPC_MAX_NR_ISRS8
@@ -2540,6 +2541,8 @@ void dispc_dump_irqs(struct seq_file *s)
PIS(VSYNC2);
PIS(ACBIAS_COUNT_STAT2);
PIS(SYNC_LOST_2);
+ PIS(VID3_FIFO_UNDERFLOW);
+ PIS(VID3_END_WIN);
}
#undef PIS
}
@@ -3151,6 +3154,24 @@ static void dispc_error_worker(struct work_struct
*work)
}
}
+ if (errors DISPC_IRQ_VID3_FIFO_UNDERFLOW) {
+ DSSERR(VID3_FIFO_UNDERFLOW, disabling VID2\n);
[Hiremath, Vaibhav] typo mistake VID2 = VID3
Thanks,
Vaibhav
+ for (i = 0; i omap_dss_get_num_overlays(); ++i) {
+ struct omap_overlay *ovl;
+ ovl = omap_dss_get_overlay(i);
+
+ if (!(ovl-caps OMAP_DSS_OVL_CAP_DISPC))
+ continue;
+
+ if (ovl-id == 3) {
+ dispc_enable_plane(ovl-id, 0);
+ dispc_go(ovl-manager-id);
+ mdelay(50);
+ break;
+ }
+ }
+ }
+
if (errors DISPC_IRQ_SYNC_LOST) {
struct omap_overlay_manager *manager = NULL;
bool enable = false;
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/5] OMAP: DSS2: Context Save and Restore of Video3 pipeline registers
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Taneja, Archit
Sent: Monday, July 19, 2010 5:26 PM
To: tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Janorkar, Mayuresh; Mittal, Mukund; Taneja,
Archit
Subject: [PATCH 5/5] OMAP: DSS2: Context Save and Restore of Video3 pipeline
registers
From: Mayuresh Janorkar ma...@ti.com
Context Save and Restore of Video3 pipeline registers.
[Hiremath, Vaibhav] I still fill, we are un-necessary dividing the patch here.
This patch can very well be part of another patch,
[PATCH 2/5] OMAP: DSS2: Add Video 3 pipeline functionality in DISPC
In-fact, for me this should be consolidated single patch, something like,
OMAP: DSS2: Add Video-3 pipeline functionality
I don't see any reason why we are fragmenting this into multiple patches.
Thanks,
Vaibhav
Signed-off-by: Mayuresh Janorkar ma...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 104
+++
1 files changed, 104 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index 8cda961..5a6c10e
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -397,6 +397,58 @@ void dispc_save_context(void)
SR(VID_FIR_COEF_V(1, 7));
SR(VID_PRELOAD(1));
+
+ /* VID3 */
+ if (cpu_is_omap44xx()) {
+ SR(VID3_WB_BA0(0));
+ SR(VID3_WB_BA1(0));
+ SR(VID3_POSITION);
+ SR(VID3_WB_SIZE(0));
+ SR(VID3_WB_ATTRIBUTES(0));
+ SR(VID3_WB_BUF_THRESHOLD(0));
+ SR(VID3_WB_BUF_SIZE_STATUS(0));
+ SR(VID3_WB_ROW_INC(0));
+ SR(VID3_WB_PIXEL_INC(0));
+ SR(VID3_WB_FIR(0));
+ SR(VID3_WB_PICTURE_SIZE(0));
+ SR(VID3_WB_ACCU0(0));
+ SR(VID3_WB_ACCU1(0));
+
+ SR(VID3_WB_FIR_COEF_H(0, 0));
+ SR(VID3_WB_FIR_COEF_H(0, 1));
+ SR(VID3_WB_FIR_COEF_H(0, 2));
+ SR(VID3_WB_FIR_COEF_H(0, 3));
+ SR(VID3_WB_FIR_COEF_H(0, 4));
+ SR(VID3_WB_FIR_COEF_H(0, 5));
+ SR(VID3_WB_FIR_COEF_H(0, 6));
+ SR(VID3_WB_FIR_COEF_H(0, 7));
+
+ SR(VID3_WB_FIR_COEF_HV(0, 0));
+ SR(VID3_WB_FIR_COEF_HV(0, 1));
+ SR(VID3_WB_FIR_COEF_HV(0, 2));
+ SR(VID3_WB_FIR_COEF_HV(0, 3));
+ SR(VID3_WB_FIR_COEF_HV(0, 4));
+ SR(VID3_WB_FIR_COEF_HV(0, 5));
+ SR(VID3_WB_FIR_COEF_HV(0, 6));
+ SR(VID3_WB_FIR_COEF_HV(0, 7));
+
+ SR(VID3_WB_CONV_COEF(0, 0));
+ SR(VID3_WB_CONV_COEF(0, 1));
+ SR(VID3_WB_CONV_COEF(0, 2));
+ SR(VID3_WB_CONV_COEF(0, 3));
+ SR(VID3_WB_CONV_COEF(0, 4));
+
+ SR(VID3_WB_FIR_COEF_V(0, 0));
+ SR(VID3_WB_FIR_COEF_V(0, 1));
+ SR(VID3_WB_FIR_COEF_V(0, 2));
+ SR(VID3_WB_FIR_COEF_V(0, 3));
+ SR(VID3_WB_FIR_COEF_V(0, 4));
+ SR(VID3_WB_FIR_COEF_V(0, 5));
+ SR(VID3_WB_FIR_COEF_V(0, 6));
+ SR(VID3_WB_FIR_COEF_V(0, 7));
+
+ SR(VID3_PRELOAD);
+ }
}
void dispc_restore_context(void)
@@ -553,6 +605,58 @@ void dispc_restore_context(void)
RR(VID_PRELOAD(1));
+ /* VID3 */
+ if (cpu_is_omap44xx()) {
+ SR(VID3_WB_BA0(0));
+ SR(VID3_WB_BA1(0));
+ SR(VID3_POSITION);
+ SR(VID3_WB_SIZE(0));
+ SR(VID3_WB_ATTRIBUTES(0));
+ SR(VID3_WB_BUF_THRESHOLD(0));
+ SR(VID3_WB_BUF_SIZE_STATUS(0));
+ SR(VID3_WB_ROW_INC(0));
+ SR(VID3_WB_PIXEL_INC(0));
+ SR(VID3_WB_FIR(0));
+ SR(VID3_WB_PICTURE_SIZE(0));
+ SR(VID3_WB_ACCU0(0));
+ SR(VID3_WB_ACCU1(0));
+
+ SR(VID3_WB_FIR_COEF_H(0, 0));
+ SR(VID3_WB_FIR_COEF_H(0, 1));
+ SR(VID3_WB_FIR_COEF_H(0, 2));
+ SR(VID3_WB_FIR_COEF_H(0, 3));
+ SR(VID3_WB_FIR_COEF_H(0, 4));
+ SR(VID3_WB_FIR_COEF_H(0, 5));
+ SR(VID3_WB_FIR_COEF_H(0, 6));
+ SR(VID3_WB_FIR_COEF_H(0, 7));
+
+ SR(VID3_WB_FIR_COEF_HV(0, 0));
+ SR(VID3_WB_FIR_COEF_HV(0, 1));
+ SR(VID3_WB_FIR_COEF_HV(0, 2));
+ SR(VID3_WB_FIR_COEF_HV(0, 3));
+ SR(VID3_WB_FIR_COEF_HV(0, 4));
+ SR(VID3_WB_FIR_COEF_HV(0, 5));
+ SR(VID3_WB_FIR_COEF_HV(0, 6));
+ SR(VID3_WB_FIR_COEF_HV(0, 7));
+
+ SR(VID3_WB_CONV_COEF(0, 0));
+ SR(VID3_WB_CONV_COEF(0, 1));
+ SR(VID3_WB_CONV_COEF(0, 2));
+ SR(VID3_WB_CONV_COEF(0, 3));
RE: [PATCH 4/5] OMAP: DSS2: Video3 pipeline IRQs
-Original Message-
From: Hiremath, Vaibhav
Sent: Friday, July 23, 2010 11:10 AM
To: Taneja, Archit; tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Semwal, Sumit; Mittal,
Mukund; Taneja, Archit
Subject: RE: [PATCH 4/5] OMAP: DSS2: Video3 pipeline IRQs
snap
@@ -173,7 +173,8 @@ struct dispc_reg { u16 idx; };
DISPC_IRQ_SYNC_LOST | \
DISPC_IRQ_SYNC_LOST_DIGIT | \
(cpu_is_omap44xx() ? \
-DISPC_IRQ_SYNC_LOST_2 : 0))
+
(DISPC_IRQ_VID3_FIFO_UNDERFLOW | \
+DISPC_IRQ_SYNC_LOST_2) : 0))
[Hiremath, Vaibhav] This looks bit suspicious to me, against
which tree this patch has been generated? I think you have
missed some of the patches in between.
[Archit] This patch series sits over a previously sent RFC:
https://patchwork.kernel.org/patch/111901/
#define DISPC_MAX_NR_ISRS 8
@@ -2540,6 +2541,8 @@ void dispc_dump_irqs(struct seq_file *s)
PIS(VSYNC2);
PIS(ACBIAS_COUNT_STAT2);
PIS(SYNC_LOST_2);
+ PIS(VID3_FIFO_UNDERFLOW);
+ PIS(VID3_END_WIN);
}
#undef PIS
}
@@ -3151,6 +3154,24 @@ static void dispc_error_worker(struct
work_struct
*work)
}
}
+ if (errors DISPC_IRQ_VID3_FIFO_UNDERFLOW) {
+ DSSERR(VID3_FIFO_UNDERFLOW, disabling VID2\n);
[Hiremath, Vaibhav] typo mistake VID2 = VID3
Thanks,
Vaibhav
Will fix this.
Thanks,
Archit--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] OMAP: DSS2: Video3 pipeline IRQs
-Original Message-
From: Taneja, Archit
Sent: Friday, July 23, 2010 11:17 AM
To: Hiremath, Vaibhav; tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Semwal, Sumit; Mittal, Mukund
Subject: RE: [PATCH 4/5] OMAP: DSS2: Video3 pipeline IRQs
-Original Message-
From: Hiremath, Vaibhav
Sent: Friday, July 23, 2010 11:10 AM
To: Taneja, Archit; tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Semwal, Sumit; Mittal,
Mukund; Taneja, Archit
Subject: RE: [PATCH 4/5] OMAP: DSS2: Video3 pipeline IRQs
snap
@@ -173,7 +173,8 @@ struct dispc_reg { u16 idx; };
DISPC_IRQ_SYNC_LOST | \
DISPC_IRQ_SYNC_LOST_DIGIT | \
(cpu_is_omap44xx() ? \
- DISPC_IRQ_SYNC_LOST_2 : 0))
+
(DISPC_IRQ_VID3_FIFO_UNDERFLOW | \
+ DISPC_IRQ_SYNC_LOST_2) : 0))
[Hiremath, Vaibhav] This looks bit suspicious to me, against
which tree this patch has been generated? I think you have
missed some of the patches in between.
[Archit] This patch series sits over a previously sent RFC:
https://patchwork.kernel.org/patch/111901/
[Hiremath, Vaibhav] Ohhh, I missed it completely. Perhaps it would be good if
you could mention this dependency in you PATCH [0/x].
I think Sanjeev has already provided some comments, so I would rather prefer to
review latest version (when you post it again).
Thanks,
Vaibhav
#define DISPC_MAX_NR_ISRS8
@@ -2540,6 +2541,8 @@ void dispc_dump_irqs(struct seq_file *s)
PIS(VSYNC2);
PIS(ACBIAS_COUNT_STAT2);
PIS(SYNC_LOST_2);
+ PIS(VID3_FIFO_UNDERFLOW);
+ PIS(VID3_END_WIN);
}
#undef PIS
}
@@ -3151,6 +3154,24 @@ static void dispc_error_worker(struct
work_struct
*work)
}
}
+ if (errors DISPC_IRQ_VID3_FIFO_UNDERFLOW) {
+ DSSERR(VID3_FIFO_UNDERFLOW, disabling VID2\n);
[Hiremath, Vaibhav] typo mistake VID2 = VID3
Thanks,
Vaibhav
Will fix this.
Thanks,
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/5] OMAP: DSS2: Context Save and Restore of Video3 pipeline registers
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Taneja, Archit Sent: Monday, July 19, 2010 5:26 PM To: tomi.valkei...@nokia.com Cc: linux-omap@vger.kernel.org; Janorkar, Mayuresh; Mittal, Mukund; Taneja, Archit Subject: [PATCH 5/5] OMAP: DSS2: Context Save and Restore of Video3 pipeline registers From: Mayuresh Janorkar ma...@ti.com Context Save and Restore of Video3 pipeline registers. [Hiremath, Vaibhav] I still fill, we are un-necessary dividing the patch here. This patch can very well be part of another patch, [PATCH 2/5] OMAP: DSS2: Add Video 3 pipeline functionality in DISPC In-fact, for me this should be consolidated single patch, something like, OMAP: DSS2: Add Video-3 pipeline functionality I don't see any reason why we are fragmenting this into multiple patches. Thanks, Vaibhav [Archit] Okay, Does the following split sound good?: -OMAP: DSS2: [1/2]Add Video-3 pipeline functionality in dispc - This patch will have all dispc related changes -OMAP: DSS2: [2/2]Add Video-3 pipeline overlay object - This patch will add the new overlay and changes required in manager, irqs etc Or does a single patch make more sense? Thanks, Archit-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/5] OMAP: DSS2: Context Save and Restore of Video3 pipeline registers
-Original Message- From: Taneja, Archit Sent: Friday, July 23, 2010 11:26 AM To: Hiremath, Vaibhav; tomi.valkei...@nokia.com Cc: linux-omap@vger.kernel.org; Janorkar, Mayuresh; Mittal, Mukund Subject: RE: [PATCH 5/5] OMAP: DSS2: Context Save and Restore of Video3 pipeline registers -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Taneja, Archit Sent: Monday, July 19, 2010 5:26 PM To: tomi.valkei...@nokia.com Cc: linux-omap@vger.kernel.org; Janorkar, Mayuresh; Mittal, Mukund; Taneja, Archit Subject: [PATCH 5/5] OMAP: DSS2: Context Save and Restore of Video3 pipeline registers From: Mayuresh Janorkar ma...@ti.com Context Save and Restore of Video3 pipeline registers. [Hiremath, Vaibhav] I still fill, we are un-necessary dividing the patch here. This patch can very well be part of another patch, [PATCH 2/5] OMAP: DSS2: Add Video 3 pipeline functionality in DISPC In-fact, for me this should be consolidated single patch, something like, OMAP: DSS2: Add Video-3 pipeline functionality I don't see any reason why we are fragmenting this into multiple patches. Thanks, Vaibhav [Archit] Okay, Does the following split sound good?: -OMAP: DSS2: [1/2]Add Video-3 pipeline functionality in dispc - This patch will have all dispc related changes -OMAP: DSS2: [2/2]Add Video-3 pipeline overlay object - This patch will add the new overlay and changes required in manager, irqs etc Or does a single patch make more sense? [Hiremath, Vaibhav] I still feel single patch makes more sense here. Thanks, Vaibhav Thanks, Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
