[PATCH] omap_vout: Set DSS overlay_info only if paddr is non zero
The omap_vout driver tries to set the DSS overlay_info using set_overlay_info()
when the physical address for the overlay is still not configured. This happens
in omap_vout_probe() and vidioc_s_fmt_vid_out().
The calls to omapvid_init(which internally calls set_overlay_info()) are removed
from these functions. They don't need to be called as the omap_vout_device
struct anyway maintains the overlay related changes made. Also, remove the
explicit call to set_overlay_info() in vidioc_streamon(), this was used to set
the paddr, this isn't needed as omapvid_init() does the same thing later.
These changes are required as the DSS2 driver since 3.3 kernel doesn't let you
set the overlay info with paddr as 0.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 36 -
1 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 1fb7d5b..dffcf66 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1157,13 +1157,6 @@ static int vidioc_s_fmt_vid_out(struct file *file, void
*fh,
/* set default crop and win */
omap_vout_new_format(vout-pix, vout-fbuf, vout-crop, vout-win);
- /* Save the changes in the overlay strcuture */
- ret = omapvid_init(vout, 0);
- if (ret) {
- v4l2_err(vout-vid_dev-v4l2_dev, failed to change mode\n);
- goto s_fmt_vid_out_exit;
- }
-
ret = 0;
s_fmt_vid_out_exit:
@@ -1664,20 +1657,6 @@ static int vidioc_streamon(struct file *file, void *fh,
enum v4l2_buf_type i)
omap_dispc_register_isr(omap_vout_isr, vout, mask);
- for (j = 0; j ovid-num_overlays; j++) {
- struct omap_overlay *ovl = ovid-overlays[j];
-
- if (ovl-manager ovl-manager-device) {
- struct omap_overlay_info info;
- ovl-get_overlay_info(ovl, info);
- info.paddr = addr;
- if (ovl-set_overlay_info(ovl, info)) {
- ret = -EINVAL;
- goto streamon_err1;
- }
- }
- }
-
/* First save the configuration in ovelray structure */
ret = omapvid_init(vout, addr);
if (ret)
@@ -2071,11 +2050,12 @@ static int __init omap_vout_create_video_devices(struct
platform_device *pdev)
}
video_set_drvdata(vfd, vout);
- /* Configure the overlay structure */
- ret = omapvid_init(vid_dev-vouts[k], 0);
- if (!ret)
- goto success;
+ dev_info(pdev-dev, : registered and initialized
+video device %d\n, vfd-minor);
+ if (k == (pdev-num_resources - 1))
+ return 0;
+ continue;
error2:
if (vout-vid_info.rotation_type == VOUT_ROT_VRFB)
omap_vout_release_vrfb(vout);
@@ -2085,12 +2065,6 @@ error1:
error:
kfree(vout);
return ret;
-
-success:
- dev_info(pdev-dev, : registered and initialized
-video device %d\n, vfd-minor);
- if (k == (pdev-num_resources - 1))
- return 0;
}
return -ENODEV;
--
1.7.5.4
--
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] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Tue, Mar 06, 2012 at 04:25:30, Tony Lindgren wrote:
Hi,
* Vaibhav Hiremath hvaib...@ti.com [120119 06:01]:
OMAP device has 32k-sync timer which is currently used as a
clocksource in the kernel (omap2plus_defconfig).
The current implementation uses compile time selection between
gp-timer and 32k-sync timer, which breaks multi-omap build for
the devices like AM33xx, where 32k-sync timer is not available.
So use hwmod database lookup mechanism, through which at run-time
we can identify availability of 32k-sync timer on the device,
else fall back to gp-timer.
...
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -69,52 +69,55 @@ void read_persistent_clock(struct timespec *ts)
int __init omap_init_clocksource_32k(void)
{
- static char err[] __initdata = KERN_ERR
- %s: can't register clocksource!\n;
-
- if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
- u32 pbase;
- unsigned long size = SZ_4K;
- void __iomem *base;
- struct clk *sync_32k_ick;
-
- if (cpu_is_omap16xx()) {
- pbase = OMAP16XX_TIMER_32K_SYNCHRONIZED;
- size = SZ_1K;
- } else if (cpu_is_omap2420())
- pbase = OMAP2420_32KSYNCT_BASE + 0x10;
- else if (cpu_is_omap2430())
- pbase = OMAP2430_32KSYNCT_BASE + 0x10;
- else if (cpu_is_omap34xx())
- pbase = OMAP3430_32KSYNCT_BASE + 0x10;
- else if (cpu_is_omap44xx())
- pbase = OMAP4430_32KSYNCT_BASE + 0x10;
- else
+ u32 pbase;
+ unsigned long size = SZ_4K;
+ void __iomem *base;
+ struct clk *sync_32k_ick;
+
+ if (cpu_is_omap16xx()) {
+ pbase = OMAP16XX_TIMER_32K_SYNCHRONIZED;
+ size = SZ_1K;
+ } else if (cpu_class_is_omap2()) {
+ struct omap_hwmod *oh;
+ const char *oh_name = counter_32k;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh || oh-slaves_cnt == 0) {
+ pr_err(Could not lookup %s hwmod\n, oh_name);
return -ENODEV;
+ }
+ pbase = oh-slaves[0]-addr-pa_start + 0x10;
+ } else {
+ return -ENODEV;
+ }
How about have separate omap1 and omap2+ init functions that
call a common function and passes the pbase as a parameter?
That way we can get rid of the cpu_is_omap tests here.
Ok, let me clean this code accordingly and submit the next version.
Thanks,
Vaibhav
Regards,
Tony
--
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: oprofile and ARM A9 hardware counter
On Wed, Mar 07, 2012 at 02:49:46AM +, Ming Lei wrote: Hi Will, Hello, On Fri, Jan 27, 2012 at 11:54 PM, Will Deacon will.dea...@arm.com wrote: Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so you may miss samples if they occur during critical kernel sections (and if you look at a profile, spin_unlock_irqrestore will be quite high). Also looks no any irq handler functions can be observed at a profile even though they may be run at a very high frequency. So could we configure ARM PMU interrupt as FIQ to address the above issues? I thought about that in the past but the problem is finding hardware which allows this. It probably means that you need a second GIC which can route interrupts onto the FIQ line into the CPU. Given that FIQ is usually claimed for secure interrupts, there could also still be latency issues here. A better (read: highly invasive) way to fix this is using interrupt priorities at the distributor. You then have to hack the interrupt disabling code so that it disables interrupts below a certain priority if they occur during an IRQ-off section. The re-enabling code would then have to undo those decisions and allow the interrupts to be serviced. Pretty nasty stuff. Will -- 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/3] ARM: OMAP2/3: Add idle_st bits for ST_32KSYNC timer to prcm-common header
On Tue, Mar 06, 2012 at 04:26:40, Tony Lindgren wrote: * Vaibhav Hiremath hvaib...@ti.com [120119 06:01]: Add missing idle_st bit for 32k-sync timer into the prcm-common header file, required for hwmod data. These should be queued by Paul when the related hwmod changes are done. Paul, Can you queue this up into your next-branch? Thanks, Vaibhav Regards, Tony Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/prcm-common.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index 5aa5435..29955d5 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -177,6 +177,8 @@ /* PM_WKST_WKUP, CM_IDLEST_WKUP shared bits */ #define OMAP24XX_ST_GPIOS_SHIFT2 #define OMAP24XX_ST_GPIOS_MASK (1 2) +#define OMAP24XX_ST_32KSYNC_SHIFT 1 +#define OMAP24XX_ST_32KSYNC_MASK (1 1) #define OMAP24XX_ST_GPT1_SHIFT 0 #define OMAP24XX_ST_GPT1_MASK (1 0) @@ -307,6 +309,8 @@ #define OMAP3430_ST_SR1_MASK (1 6) #define OMAP3430_ST_GPIO1_SHIFT3 #define OMAP3430_ST_GPIO1_MASK (1 3) +#define OMAP3430_ST_32KSYNC_SHIFT 2 +#define OMAP3430_ST_32KSYNC_MASK (1 2) #define OMAP3430_ST_GPT12_SHIFT1 #define OMAP3430_ST_GPT12_MASK (1 1) #define OMAP3430_ST_GPT1_SHIFT 0 -- 1.7.0.4 -- 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 0/3] ARM: OMAP1/2+: 32k-timer: Add hwmod lookup for 32k-timer
On Tue, Mar 06, 2012 at 04:27:52, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120123 00:16]: On Thu, Jan 19, 2012 at 19:58:21, Hiremath, Vaibhav wrote: This patch series cleans up the existing 32k-sync timer implementation without any major code change and adds hwmod lookup for omap2+ devices, if lookup fails then fall back to gp-timer. ... Tony, If there are no review comments, can this be merged? Made a minor comment on the first patch, it would be nice to get that clean-up merged. The other two depend on some some hwmod data shrinkage by Paul.. Working on it, will be submitting next version soon. Thanks, Vaibhav Regards, Tony -- 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 2/2] ARM: OMAP: sram: Add am33xx SRAM support (minimal)
On Tue, Mar 06, 2012 at 04:44:13, Tony Lindgren wrote:
* Bedia, Vaibhav vaibhav.be...@ti.com [120213 07:36]:
On Mon, Feb 13, 2012 at 19:54:05, Peter Korsgaard wrote:
Afzal == Afzal Mohammed af...@ti.com writes:
Afzal From: Vaibhav Bedia vaibhav.be...@ti.com
Afzal Update SRAM start size for am33xx SoC's.
This is a really awkward quoting style :|
I don't particular know the omap sram stuff, but doesn't the 33xx have
2x 64K blocks of SRAM?
Yes, but since the lower 64KB will not be available on non-GP device and
only A8 can access it, for now we make use of the higher 64KB which is
referred
to as the OCMC RAM in the TRM. This will also enable SRAM usage by other
drivers
like PRU and McASP.
Afzal +static inline int am33xx_sram_init(void)
Afzal +{
Afzal + return 0;
I know you mentioned it in the commit message, but it might be good with
a comment here as well that this dummy function is needed to not get the
34xx
init function called for 33xx, so it doesn't get removed when somebody
decides to cleanup.
You are right in saying that the dummy function is needed to avoid 34xx
SRAM init.
We'll have some PM related code coming in soon and hopefully the SRAM code
won't change
Without us noticing ;)
OK, applying into fixes-non-critical-part2. Our sram.c should get turned
into a device driver, there's been already similar sram driver posted
to LAKML. So that should allow us to remove the cpu_is_ checks.
I think I missed this, let me check the post.
Thanks,
Vaibhav
Regards,
Tony
--
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] mmc: omap_hsmmc: Clean up use/abuse of pdev-id
On Monday 05 March 2012 01:24 PM, Rajendra Nayak wrote: On Friday 24 February 2012 03:40 PM, Rajendra Nayak wrote: Chris, On Thursday 23 February 2012 04:56 PM, Rajendra Nayak wrote: Re-sending as these patches did not make it to the lists due to issues with my 'git send-email' This series mainly cleans up all instances of hardcoding's in the driver based on pdev-id. This is cleanup leading to the DT adaptation of omap_hsmmc driver. v2 mainly has some minor changes to get rid of a debug print which was still using host-id and getting rid of 'id' field entirely from omap_hsmmc_host struct. The series is tested on OMAP4SDP, OMAP4panda, OMAP3beagle and OMAP2430SDP boards. This series is reviewed/tested and acked by Balaji and Venkat. Care to pull this in for 3.4? I have one other cleanup patch on top of this series to make all remaining pr_* prints in the driver to dev_* [1]. It would be great if you could pick that up as well. These patches are cleanups leading to the DT conversion of omap_hsmmc driver. Chris, Ping. I am basing my DT support patches on top of these cleanups. Would be great if you can have a look and pull them in. Chris, just realized the last two requests from me to get this merged weren't addressed to you directly, but instead you were copied. Resending with you in 'To', hope this lands in your inbox :) regards, Rajendra regards, Rajendra [1] http://marc.info/?l=linux-mmcm=132999677405098w=3 regards, Rajendra Balaji T K (3): mmc: omap_hsmmc: use platform_get_resource_byname for tx/rx DMA channels mmc: omap_hsmmc: remove unused .set_sleep function mmc: omap_hsmmc: Use OMAP_HSMMC_SUPPORTS_DUAL_VOLT flag to remove host-id based hardcoding Rajendra Nayak (3): mmc: omap_hsmmc: Get rid of omap_hsmmc_1_set_power function mmc: omap_hsmmc: Get rid of omap_hsmmc_4_set_power function mmc: omap_hsmmc: Don't expect MMC1 to always have vmmc supply arch/arm/plat-omap/include/plat/mmc.h | 2 - drivers/mmc/host/omap_hsmmc.c | 175 +++-- 2 files changed, 16 insertions(+), 161 deletions(-) -- 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: Latest OMAP4 build errors
On Tue, Mar 06, 2012 at 05:01:53PM +, Arnd Bergmann wrote: On Tuesday 06 March 2012, Russell King - ARM Linux wrote: On Tue, Feb 28, 2012 at 12:11:37PM +0200, Ohad Ben-Cohen wrote: On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann a...@arndb.de wrote: I think 'depends' would be better here, because selecting IOMMU_SUPPORT has other side-effects that a user might not want. It's just as likely that someone wants to disable IOMMU_SUPPORT and needs to find OMAP_REMOTEPROC as wanting to enable OMAP_REMOTEPROC and having to find IOMMU_SUPPORT. In most cases, the defconfig should just set both. Ok, 'depends on' it is. We're a week on, which means I now have a full set of 7 builds on the website for OMAP4430 all of which have failed in part due to this as yet unresolved problem. What's happening to get it fixed and those fixes into whatever tree is necessary for them (presumably arm-soc)? Ohad has sent a series of patches for review and there were no comments on those. The fix was part of it as far as I remember. I'm still waiting for a pull request from Ohad. Given that we're coming to the end of what could be the _final_ week before the merge window opens, this is not good news. Read: maybe three days before final. The fact is that OMAP is - yet again - in a totally rotten state in terms of what's queued up in the armsoc tree. It is - yet again - completely unbuildable for many configurations. Just go and have a look at: http://www.arm.linux.org.uk/developer/build/ to see what an utterly crappy state OMAP is in again. Last nights build was my tree plus latest arm-soc. Some of those issues have patches (I had been applying one patch manually to the build tree) but that's not the point - they're not in arm-soc, so the OMAP code in arm-soc is not yet ready for mainline. So, as OMAP is soo broken, and as promised after the last merge window - I don't want any OMAP stuff going upstream from armsoc until we get error free builds from the allno and old configs on the builder. -- 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: [GIT PULL] HSI framework
On Wed, 2012-03-07 at 11:49 +0100, Sebastian Reichel wrote: Hi Linus, I've noticed that you have not pulled this (yet). I would like to confirm that we at Intel are also very interested to have HSI upstream. I believe this code base is more than worth merging since it has many users and it has proven itself in real Nokia products. Would you please pull it? Hi, I think we never got a reply why the HSI framework has not been pulled into 3.3. So what needs to be done to get it pulled into 3.4? Hi, Because this question is for Linus, he should be in To: instead of Cc: - correcting. -- Best Regards, Artem Bityutskiy -- 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 v3 06/13] gpio/omap: fix trigger type to unsigned
The GPIO trigger parameter is of type unsigned.
enum {
IRQ_TYPE_NONE = 0x,
IRQ_TYPE_EDGE_RISING= 0x0001,
IRQ_TYPE_EDGE_FALLING = 0x0002,
IRQ_TYPE_EDGE_BOTH = (IRQ_TYPE_EDGE_FALLING |
IRQ_TYPE_EDGE_RISING),
IRQ_TYPE_LEVEL_HIGH = 0x0004,
IRQ_TYPE_LEVEL_LOW = 0x0008,
IRQ_TYPE_LEVEL_MASK = (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH),
IRQ_TYPE_SENSE_MASK = 0x000f,
IRQ_TYPE_PROBE = 0x0010,
...
};
Even though gpio_irq_type(struct irq_data *d, unsigned type) has the right type
of parameter, the subsequent called functions set_gpio_triggering() and
set_gpio_trigger() wrongly makes it signed integer. Fix this.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/gpio/gpio-omap.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index de5fe8f..bb994db 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -234,7 +234,7 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
}
static inline void set_gpio_trigger(struct gpio_bank *bank, int gpio,
- int trigger)
+ unsigned trigger)
{
void __iomem *base = bank-base;
u32 gpio_bit = 1 gpio;
@@ -316,7 +316,8 @@ static void _toggle_gpio_edge_triggering(struct gpio_bank
*bank, int gpio)
static void _toggle_gpio_edge_triggering(struct gpio_bank *bank, int gpio) {}
#endif
-static int _set_gpio_triggering(struct gpio_bank *bank, int gpio, int trigger)
+static int _set_gpio_triggering(struct gpio_bank *bank, int gpio,
+ unsigned trigger)
{
void __iomem *reg = bank-base;
void __iomem *base = bank-base;
--
1.7.0.4
--
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 v3 09/13] gpio/omap: remove suspend/resume callbacks
Both omap_gpio_suspend() and omap_gpio_resume() does programming
of wakeup_en register.
_gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
_gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
This is redundant in omap_gpio_suspend() because wakeup_en
register automatically gets initialized in _set_gpio_wakeup()
and set_gpio_trigger() while being called either from
chip.irq_set_wake() or chip.irq_set_type().
This is redundant in omap_gpio_resume() because wakeup_en
register is programmed in omap_gpio_restore_context() called
which is called from runtime resume callback.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
drivers/gpio/gpio-omap.c | 47 --
1 files changed, 0 insertions(+), 47 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 186ce92..8b4a7ba 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1132,50 +1132,6 @@ err_exit:
#ifdef CONFIG_ARCH_OMAP2PLUS
-#if defined(CONFIG_PM_SLEEP)
-static int omap_gpio_suspend(struct device *dev)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct gpio_bank *bank = platform_get_drvdata(pdev);
- void __iomem *base = bank-base;
- unsigned long flags;
-
- if (!bank-mod_usage || !bank-loses_context)
- return 0;
-
- if (!bank-regs-wkup_en || !bank-context.wake_en)
- return 0;
-
- spin_lock_irqsave(bank-lock, flags);
- _gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
- _gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
- spin_unlock_irqrestore(bank-lock, flags);
-
- return 0;
-}
-
-static int omap_gpio_resume(struct device *dev)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct gpio_bank *bank = platform_get_drvdata(pdev);
- void __iomem *base = bank-base;
- unsigned long flags;
-
- if (!bank-mod_usage || !bank-loses_context)
- return 0;
-
- if (!bank-regs-wkup_en || !bank-context.wake_en)
- return 0;
-
- spin_lock_irqsave(bank-lock, flags);
- _gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
- _gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
- spin_unlock_irqrestore(bank-lock, flags);
-
- return 0;
-}
-#endif /* CONFIG_PM_SLEEP */
-
#if defined(CONFIG_PM_RUNTIME)
static void omap_gpio_restore_context(struct gpio_bank *bank);
@@ -1407,14 +1363,11 @@ static void omap_gpio_restore_context(struct gpio_bank
*bank)
}
#endif /* CONFIG_PM_RUNTIME */
#else
-#define omap_gpio_suspend NULL
-#define omap_gpio_resume NULL
#define omap_gpio_runtime_suspend NULL
#define omap_gpio_runtime_resume NULL
#endif
static const struct dev_pm_ops gpio_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(omap_gpio_suspend, omap_gpio_resume)
SET_RUNTIME_PM_OPS(omap_gpio_runtime_suspend, omap_gpio_runtime_resume,
NULL)
};
--
1.7.0.4
--
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 v3 12/13] gpio/omap: fix incorrect context restore logic in omap_gpio_runtime_resume
In omap_gpio_runtime_resume() the context restore should be independent
of bank-enabled_non_wakeup_gpios. This was preventing context restore
of GPIO lines which are not wakeup enabled.
Reported-by: Govindraj Raja govindraj.r...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
drivers/gpio/gpio-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 2e8e476..ccfbae0 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1227,7 +1227,7 @@ static int omap_gpio_runtime_resume(struct device *dev)
__raw_writel(bank-context.risingdetect,
bank-base + bank-regs-risingdetect);
- if (!bank-enabled_non_wakeup_gpios || !bank-workaround_enabled) {
+ if (!bank-workaround_enabled) {
spin_unlock_irqrestore(bank-lock, flags);
return 0;
}
--
1.7.0.4
--
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 v3 13/13] gpio/omap: fix incorrect update to context.irqenable1
In _enable_gpio_irqbank() when bank-regs-set_irqenable is valid,
gpio_mask can be directly set by writing to set_irqenable register
without overwriting current value. In order to ensure the same is
stored in context.irqenable1, we must read from regs-irqenable
instead of overwriting it with gpio_mask.
The overwriting makes sense only in the second case where irqenable
is explicitly read and updated with new gpio_mask before writing it
back. However, for consistency reading regs-irqenable into the
bank-context.irqenable1 takes care of both the scenarios.
if (bank-regs-set_irqenable) {
reg += bank-regs-set_irqenable;
l = gpio_mask;
} else {
reg += bank-regs-irqenable;
l = __raw_readl(reg);
if (bank-regs-irqenable_inv)
l = ~gpio_mask;
else
l |= gpio_mask;
}
Make the same change for _disable_gpio_irqbank().
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
drivers/gpio/gpio-omap.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index ccfbae0..8b0d3ab 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -453,7 +453,8 @@ static void _enable_gpio_irqbank(struct gpio_bank *bank,
int gpio_mask)
}
__raw_writel(l, reg);
- bank-context.irqenable1 = l;
+ bank-context.irqenable1 =
+ __raw_readl(bank-base + bank-regs-irqenable);
}
static void _disable_gpio_irqbank(struct gpio_bank *bank, int gpio_mask)
@@ -474,7 +475,8 @@ static void _disable_gpio_irqbank(struct gpio_bank *bank,
int gpio_mask)
}
__raw_writel(l, reg);
- bank-context.irqenable1 = l;
+ bank-context.irqenable1 =
+ __raw_readl(bank-base + bank-regs-irqenable);
}
static inline void _set_gpio_irqenable(struct gpio_bank *bank, int gpio, int
enable)
--
1.7.0.4
--
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 v3 03/13] gpio/omap: remove suspend_wakeup field from struct gpio_bank
Since we already have bank-context.wake_en to keep track
of gpios which are wakeup enabled, there is no need to have
this field any more.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/gpio/gpio-omap.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 895df7f..14c61e2 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -54,7 +54,6 @@ struct gpio_bank {
void __iomem *base;
u16 irq;
u16 virtual_irq_start;
- u32 suspend_wakeup;
u32 saved_wakeup;
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
@@ -500,11 +499,11 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int
gpio, int enable)
spin_lock_irqsave(bank-lock, flags);
if (enable)
- bank-suspend_wakeup |= gpio_bit;
+ bank-context.wake_en |= gpio_bit;
else
- bank-suspend_wakeup = ~gpio_bit;
+ bank-context.wake_en = ~gpio_bit;
- __raw_writel(bank-suspend_wakeup, bank-base + bank-regs-wkup_en);
+ __raw_writel(bank-context.wake_en, bank-base + bank-regs-wkup_en);
spin_unlock_irqrestore(bank-lock, flags);
return 0;
@@ -776,7 +775,7 @@ static int omap_mpuio_suspend_noirq(struct device *dev)
spin_lock_irqsave(bank-lock, flags);
bank-saved_wakeup = __raw_readl(mask_reg);
- __raw_writel(0x ~bank-suspend_wakeup, mask_reg);
+ __raw_writel(0x ~bank-context.wake_en, mask_reg);
spin_unlock_irqrestore(bank-lock, flags);
return 0;
@@ -1150,7 +1149,7 @@ static int omap_gpio_suspend(struct device *dev)
if (!bank-mod_usage || !bank-loses_context)
return 0;
- if (!bank-regs-wkup_en || !bank-suspend_wakeup)
+ if (!bank-regs-wkup_en || !bank-context.wake_en)
return 0;
wakeup_enable = bank-base + bank-regs-wkup_en;
@@ -1158,7 +1157,7 @@ static int omap_gpio_suspend(struct device *dev)
spin_lock_irqsave(bank-lock, flags);
bank-saved_wakeup = __raw_readl(wakeup_enable);
_gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
- _gpio_rmw(base, bank-regs-wkup_en, bank-suspend_wakeup, 1);
+ _gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
spin_unlock_irqrestore(bank-lock, flags);
return 0;
--
1.7.0.4
--
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 v3 02/13] gpio/omap: fix wakeup_en register update in _set_gpio_wakeup()
There are two ways through which wakeup_en register can be programmed using gpiolib APIs as shown below. It is seen that in the second case in _set_gpio_wakeup(), even though bank-suspend_wakeup is updated correctly, its value is not programmed in wakeup_en register. Fix this. chip.irq_set_type()-gpio_irq_type()-_set_gpio_triggering()-set_gpio_trigger() chip.irq_set_wake()-gpio_wake_enable()-_set_gpio_wakeup() Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- drivers/gpio/gpio-omap.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index c9369d2..895df7f 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -504,6 +504,7 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable) else bank-suspend_wakeup = ~gpio_bit; + __raw_writel(bank-suspend_wakeup, bank-base + bank-regs-wkup_en); spin_unlock_irqrestore(bank-lock, flags); return 0; -- 1.7.0.4 -- 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 v3 07/13] gpio/omap: fix _set_gpio_irqenable implementation
This function should be capable of both enabling and disabling interrupts
based upon the *enable* parameter. Right now the function only enables
the interrupt and *enable* is not used at all. So add the interrupt
disable capability also using the parameter.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/gpio/gpio-omap.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index bb994db..19f8f44 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -475,7 +475,10 @@ static void _disable_gpio_irqbank(struct gpio_bank *bank,
int gpio_mask)
static inline void _set_gpio_irqenable(struct gpio_bank *bank, int gpio, int
enable)
{
- _enable_gpio_irqbank(bank, GPIO_BIT(bank, gpio));
+ if (enable)
+ _enable_gpio_irqbank(bank, GPIO_BIT(bank, gpio));
+ else
+ _disable_gpio_irqbank(bank, GPIO_BIT(bank, gpio));
}
/*
--
1.7.0.4
--
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 v3 11/13] gpio/omap: fix dataout register overwrite in _set_gpio_dataout_*
In the existing _set_gpio_dataout_*() implementation, the dataout register is overwritten every time the function is called. This is not intended behavior because that would end up one user of a GPIO line overwriting what is written by another. Fix this so that previous value is always preserved until explicitly changed by respective user/driver of the GPIO line. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- drivers/gpio/gpio-omap.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 04c2677..2e8e476 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -114,6 +114,7 @@ static void _set_gpio_dataout_reg(struct gpio_bank *bank, int gpio, int enable) else reg += bank-regs-clr_dataout; + l |= __raw_readl(bank-base + bank-regs-set_dataout); __raw_writel(l, reg); bank-context.dataout = l; } @@ -130,6 +131,8 @@ static void _set_gpio_dataout_mask(struct gpio_bank *bank, int gpio, int enable) l |= gpio_bit; else l = ~gpio_bit; + + l |= __raw_readl(bank-base + bank-regs-set_dataout); __raw_writel(l, reg); bank-context.dataout = l; } -- 1.7.0.4 -- 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 v3 10/13] gpio/omap: fix missing dataout context save in _set_gpio_dataout_reg
There are two functions, _set_gpio_dataout_reg() and _set_gpio_dataout_mask() which writes to dataout register and the dataout context must be saved. It is missing in the first function, _set_gpio_dataout_reg(). Fix this. Reported-by: Govindraj Raja govindraj.r...@ti.com Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- drivers/gpio/gpio-omap.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 8b4a7ba..04c2677 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -115,6 +115,7 @@ static void _set_gpio_dataout_reg(struct gpio_bank *bank, int gpio, int enable) reg += bank-regs-clr_dataout; __raw_writel(l, reg); + bank-context.dataout = l; } /* set data out value using mask register */ -- 1.7.0.4 -- 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 v3 01/13] gpio/omap: remove saved_fallingdetect, saved_risingdetect fields
Since we already have context.fallingdetect and context.risingdetect
there is no more need to have these additional fields. Also, getting
rid of extra reads associated with them.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/gpio/gpio-omap.c | 19 ---
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 752ae9b..c9369d2 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -60,8 +60,6 @@ struct gpio_bank {
u32 enabled_non_wakeup_gpios;
struct gpio_regs context;
u32 saved_datain;
- u32 saved_fallingdetect;
- u32 saved_risingdetect;
u32 level_mask;
u32 toggle_mask;
spinlock_t lock;
@@ -1234,11 +1232,9 @@ static int omap_gpio_runtime_suspend(struct device *dev)
bank-saved_datain = __raw_readl(bank-base +
bank-regs-datain);
- l1 = __raw_readl(bank-base + bank-regs-fallingdetect);
- l2 = __raw_readl(bank-base + bank-regs-risingdetect);
+ l1 = bank-context.fallingdetect;
+ l2 = bank-context.risingdetect;
- bank-saved_fallingdetect = l1;
- bank-saved_risingdetect = l2;
l1 = ~bank-enabled_non_wakeup_gpios;
l2 = ~bank-enabled_non_wakeup_gpios;
@@ -1297,9 +1293,9 @@ static int omap_gpio_runtime_resume(struct device *dev)
}
}
- __raw_writel(bank-saved_fallingdetect,
+ __raw_writel(bank-context.fallingdetect,
bank-base + bank-regs-fallingdetect);
- __raw_writel(bank-saved_risingdetect,
+ __raw_writel(bank-context.risingdetect,
bank-base + bank-regs-risingdetect);
l = __raw_readl(bank-base + bank-regs-datain);
@@ -1316,14 +1312,15 @@ static int omap_gpio_runtime_resume(struct device *dev)
* No need to generate IRQs for the rising edge for gpio IRQs
* configured with falling edge only; and vice versa.
*/
- gen0 = l bank-saved_fallingdetect;
+ gen0 = l bank-context.fallingdetect;
gen0 = bank-saved_datain;
- gen1 = l bank-saved_risingdetect;
+ gen1 = l bank-context.risingdetect;
gen1 = ~(bank-saved_datain);
/* FIXME: Consider GPIO IRQs with level detections properly! */
- gen = l (~(bank-saved_fallingdetect) ~(bank-saved_risingdetect));
+ gen = l (~(bank-context.fallingdetect)
+~(bank-context.risingdetect));
/* Consider all GPIO IRQs needed to be updated */
gen |= gen0 | gen1;
--
1.7.0.4
--
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 v3 00/13] gpio/omap: Some more driver cleanup and fixes
The cleanup is mostly getting rid of redundant fields in struct gpio_bank{}
as we already have them as part of bank-context now. Also, remove un-used
variable from gpio_irq_handler.
The fixes include correction of _set_gpio_irqenable() implementation,
missing wakeup_en register update in set_gpio_wakeup(), type mismatch
of gpio trigger parameter in set_gpio_trigger(), incorrect dataout
register update in set_gpio_dataout_() and few corrections in context
save logic.
It is baselined on top of Kevin's following series:
gpio/omap: cleanup and runtime PM conversion for v3.4
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
for_3.4/gpio/runtime-pm-cleanup
Series is available here for reference:
git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev
for_3.4/gpio_further_cleanup_fixes
Power Test: Off-mode and Retention on OMAP3430 (Suspend and Idle paths).
Functional Test: OMAP2430, OMAP3430SDP, ZOOM3, OMAP4430, OMAP4-BLAZE
v3:
- Added 4 more additional patches to the previous series
which are all bug fixes.
v2:
- Added a new patch to update wakeup_en register in _set_gpio_wakeup()
in addition to updating bank-context.wake_en.
- Added a new patch to remove redundant decoding of gpio offset in
gpio_get(), _get_gpio_datain() and _get_gpio_dataout().
- Added a new patch to remove suspend/resume callbacks because the
operations performed with the callbacks are redundant.
Tarun Kanti DebBarma (13):
gpio/omap: remove saved_fallingdetect, saved_risingdetect fields
gpio/omap: fix wakeup_en register update in _set_gpio_wakeup()
gpio/omap: remove suspend_wakeup field from struct gpio_bank
gpio/omap: remove saved_wakeup field from struct gpio_bank
gpio/omap: get rid of retrigger variable in gpio_irq_handler
gpio/omap: fix trigger type to unsigned
gpio/omap: fix _set_gpio_irqenable implementation
gpio/omap: remove redundant decoding of gpio offset
gpio/omap: remove suspend/resume callbacks
gpio/omap: fix missing dataout context save in _set_gpio_dataout_reg
gpio/omap: fix dataout register overwrite in _set_gpio_dataout_*
gpio/omap: fix incorrect context restore logic in omap_gpio_runtime_resume
gpio/omap: fix incorrect update to context.irqenable1
drivers/gpio/gpio-omap.c | 125 +
1 files changed, 36 insertions(+), 89 deletions(-)
--
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 v3 05/13] gpio/omap: get rid of retrigger variable in gpio_irq_handler
This local variable is just assigned zero and then OR'ed with isr. It does not appear to serve any purpose and so removing it. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Felipe Balbi ba...@ti.com --- drivers/gpio/gpio-omap.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 3765654..de5fe8f 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -626,7 +626,6 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) u32 isr; unsigned int gpio_irq, gpio_index; struct gpio_bank *bank; - u32 retrigger = 0; int unmasked = 0; struct irq_chip *chip = irq_desc_get_chip(desc); @@ -663,8 +662,6 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) chained_irq_exit(chip, desc); } - isr |= retrigger; - retrigger = 0; if (!isr) break; -- 1.7.0.4 -- 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 v3 08/13] gpio/omap: remove redundant decoding of gpio offset
In gpio_get(), _get_gpio_datain() and _get_gpio_dataout() get rid of
un-necessary operation to compute gpio mask. The gpio offset passed
to gpio_get() is sufficient to do that.
Here is Russell's original comment:
Can someone explain to me this:
#define GPIO_INDEX(bank, gpio) (gpio % bank-width)
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
static int _get_gpio_datain(struct gpio_bank *bank, int gpio)
{
void __iomem *reg = bank-base + bank-regs-datain;
return (__raw_readl(reg) GPIO_BIT(bank, gpio)) != 0;
}
static int gpio_get(struct gpio_chip *chip, unsigned offset)
{
struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
void __iomem *reg = bank-base;
int gpio = chip-base + offset;
u32 mask = GPIO_BIT(bank, gpio);
if (gpio_is_input(bank, mask))
return _get_gpio_datain(bank, gpio);
else
return _get_gpio_dataout(bank, gpio);
}
Given that bank-width on OMAP is either 32 or 16, and GPIO numbers for
any GPIO chip are always aligned to 32 or 16, why does this code bother
adding the chips base gpio number and then modulo the width?
Surely this means if - for argument sake - you registered a GPIO chip
with 8 lines followed by one with 16 lines, GPIO0..7 would be chip 0
bit 0..7, GPIO8..15 would be chip 1 bit 8..15, GPIO16..23 would be
chip 1 bit 0..7.
However, if you registered a GPIO chip with 16 lines first, it would
mean GPIO0..15 would be chip 0 bit 0..15, and GPIO16..31 would be
chip 1 bit 0..15.
Surely this kind of behaviour is not intended?
Is there a reason why the bitmask can't just be (1 offset) where
offset is passed into these functions as GPIO number - chip-base ?
Reported-by: Russell King - ARM Linux li...@arm.linux.org.uk
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
drivers/gpio/gpio-omap.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 19f8f44..186ce92 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -133,18 +133,18 @@ static void _set_gpio_dataout_mask(struct gpio_bank
*bank, int gpio, int enable)
bank-context.dataout = l;
}
-static int _get_gpio_datain(struct gpio_bank *bank, int gpio)
+static int _get_gpio_datain(struct gpio_bank *bank, int offset)
{
void __iomem *reg = bank-base + bank-regs-datain;
- return (__raw_readl(reg) GPIO_BIT(bank, gpio)) != 0;
+ return (__raw_readl(reg) (1 offset)) != 0;
}
-static int _get_gpio_dataout(struct gpio_bank *bank, int gpio)
+static int _get_gpio_dataout(struct gpio_bank *bank, int offset)
{
void __iomem *reg = bank-base + bank-regs-dataout;
- return (__raw_readl(reg) GPIO_BIT(bank, gpio)) != 0;
+ return (__raw_readl(reg) (1 offset)) != 0;
}
static inline void _gpio_rmw(void __iomem *base, u32 reg, u32 mask, bool set)
@@ -849,19 +849,15 @@ static int gpio_is_input(struct gpio_bank *bank, int mask)
static int gpio_get(struct gpio_chip *chip, unsigned offset)
{
struct gpio_bank *bank;
- void __iomem *reg;
- int gpio;
u32 mask;
- gpio = chip-base + offset;
bank = container_of(chip, struct gpio_bank, chip);
- reg = bank-base;
- mask = GPIO_BIT(bank, gpio);
+ mask = (1 offset);
if (gpio_is_input(bank, mask))
- return _get_gpio_datain(bank, gpio);
+ return _get_gpio_datain(bank, offset);
else
- return _get_gpio_dataout(bank, gpio);
+ return _get_gpio_dataout(bank, offset);
}
static int gpio_output(struct gpio_chip *chip, unsigned offset, int value)
--
1.7.0.4
--
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 v3 04/13] gpio/omap: remove saved_wakeup field from struct gpio_bank
There is no more need to have saved_wakeup because bank-context.wake_en
already holds that value. So getting rid of read/write operation associated
with this field.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/gpio/gpio-omap.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 14c61e2..3765654 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -54,7 +54,6 @@ struct gpio_bank {
void __iomem *base;
u16 irq;
u16 virtual_irq_start;
- u32 saved_wakeup;
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
struct gpio_regs context;
@@ -774,7 +773,6 @@ static int omap_mpuio_suspend_noirq(struct device *dev)
unsigned long flags;
spin_lock_irqsave(bank-lock, flags);
- bank-saved_wakeup = __raw_readl(mask_reg);
__raw_writel(0x ~bank-context.wake_en, mask_reg);
spin_unlock_irqrestore(bank-lock, flags);
@@ -790,7 +788,7 @@ static int omap_mpuio_resume_noirq(struct device *dev)
unsigned long flags;
spin_lock_irqsave(bank-lock, flags);
- __raw_writel(bank-saved_wakeup, mask_reg);
+ __raw_writel(bank-context.wake_en, mask_reg);
spin_unlock_irqrestore(bank-lock, flags);
return 0;
@@ -1143,7 +1141,6 @@ static int omap_gpio_suspend(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct gpio_bank *bank = platform_get_drvdata(pdev);
void __iomem *base = bank-base;
- void __iomem *wakeup_enable;
unsigned long flags;
if (!bank-mod_usage || !bank-loses_context)
@@ -1152,10 +1149,7 @@ static int omap_gpio_suspend(struct device *dev)
if (!bank-regs-wkup_en || !bank-context.wake_en)
return 0;
- wakeup_enable = bank-base + bank-regs-wkup_en;
-
spin_lock_irqsave(bank-lock, flags);
- bank-saved_wakeup = __raw_readl(wakeup_enable);
_gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
_gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
spin_unlock_irqrestore(bank-lock, flags);
@@ -1173,12 +1167,12 @@ static int omap_gpio_resume(struct device *dev)
if (!bank-mod_usage || !bank-loses_context)
return 0;
- if (!bank-regs-wkup_en || !bank-saved_wakeup)
+ if (!bank-regs-wkup_en || !bank-context.wake_en)
return 0;
spin_lock_irqsave(bank-lock, flags);
_gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
- _gpio_rmw(base, bank-regs-wkup_en, bank-saved_wakeup, 1);
+ _gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
spin_unlock_irqrestore(bank-lock, flags);
return 0;
--
1.7.0.4
--
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: [GIT PULL] HSI framework
On Thu, Jan 19, 2012 at 02:14:19PM +0200, Artem Bityutskiy wrote: On Fri, 2012-01-13 at 15:25 +0200, Carlos Chinea wrote: Hi Linus, I have been working in an HSI framework. The High Speed Synchronous Serial Interface (HSI) is a serial interface mainly used for connecting application engines (APE) with cellular modem engines (CMT) in cellular handsets. The framework is currently being used for some people and we would like to see it integrated into the kernel for 3.3. There is no HW controller drivers in this pull, but some people have already some of them pending which they would like to push as soon as this integrated. I am also working on the acceptance for an TI OMAP one, based on a compatible legacy version of the interface called SSI. Hi Linus, I've noticed that you have not pulled this (yet). I would like to confirm that we at Intel are also very interested to have HSI upstream. I believe this code base is more than worth merging since it has many users and it has proven itself in real Nokia products. Would you please pull it? Hi, I think we never got a reply why the HSI framework has not been pulled into 3.3. So what needs to be done to get it pulled into 3.4? -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v3 02/13] gpio/omap: fix wakeup_en register update in _set_gpio_wakeup()
On Wednesday 07 March 2012 12:15 PM, Tarun Kanti DebBarma wrote: There are two ways through which wakeup_en register can be programmed using gpiolib APIs as shown below. It is seen that in the second case in _set_gpio_wakeup(), even though bank-suspend_wakeup is updated correctly, its value is not programmed in wakeup_en register. Fix this. chip.irq_set_type()-gpio_irq_type()-_set_gpio_triggering()-set_gpio_trigger() chip.irq_set_wake()-gpio_wake_enable()-_set_gpio_wakeup() Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- Looks good. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com 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] omap2+: add drm device
On Tue, 2012-03-06 at 09:29 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
Can there be more than one omapdrm device? I guess not. If so, the id
should be -1.
in the past, we have used multiple devices (using the platform-data to
divide up the dss resources), although this was sort of a
special-case. But in theory you could have multiple. (Think of a
multi-seat scenario, where multiple compositors need to run and each
need to be drm-master of their own device to do mode-setting on their
corresponding display.)
I think if we use .id = -1, then we'd end up with a funny looking
bus-id for the device: platform:omapdrm:-1
I don't know about that, but it's the way platform devices are meant to
be used if there can be only one instance. If the case where there are
multiple omapdrm devices is rather theoretical, or only used for certain
debugging scenarios or such, I think having the id as -1 in the mainline
is cleaner.
well, I don't care much one way or another, but need to check if there
is a small patch needed in drm core code that generates the bus-id for
.id = -1..
Hmm, why does the drm core care about it?
And generally, I think if the bus id is -1, there is no bus id in a
sense. For example, with bus id 0 you'll get a device omapdrm.0. With
bus id -1 you'll get a device omapdrm.
+arch_initcall(omap_init_gpu);
+
+void omapdrm_reserve_vram(void)
+{
+#ifdef CONFIG_CMA
+ /*
+ * Create private 32MiB contiguous memory area for omapdrm.0
device
+ * TODO revisit size.. if uc/wc buffers are allocated from CMA
pages
+ * then the amount of memory we need goes up..
+ */
+ dma_declare_contiguous(omap_drm_device.dev, 32 * SZ_1M, 0, 0);
What does this actually do? Does it reserve the memory, i.e. it's not
usable for others? If so, shouldn't there be a way for the user to
configure it?
It can be re-used by others.. see http://lwn.net/Articles/479297/
The link didn't tell much. I looked at the patches, and
dma_declare_contiguous allocates the memory with memblock_alloc. So is
that allocated memory available for any users? If so, why does the
function want a device pointer as an argument...
Is the memory available for normal kmalloc, or only available via the
CMA functions? Surely there must be some downside to the above? =) And
if so, it should be configurable. You could have a board with no display
at all, and you probably don't want to have 32MB allocated for DRM in
that case.
Basically the short version is memory from a CMA carveout can be
re-used for unpinnable memory. Not kmalloc, but it can be used for
anon userspace pages, for example. Userspace needs memory too.
Okay, let me ask the other way. Is 32MB enough for everyone? Hardcoding
a value like that without any possibility to adjust it just sounds like
a rather bad thing.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v3 09/13] gpio/omap: remove suspend/resume callbacks
On Wednesday 07 March 2012 12:15 PM, Tarun Kanti DebBarma wrote: Both omap_gpio_suspend() and omap_gpio_resume() does programming of wakeup_en register. _gpio_rmw(base, bank-regs-wkup_en, 0x, 0); _gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1); This is redundant in omap_gpio_suspend() because wakeup_en register automatically gets initialized in _set_gpio_wakeup() and set_gpio_trigger() while being called either from chip.irq_set_wake() or chip.irq_set_type(). This is redundant in omap_gpio_resume() because wakeup_en s/This is/This is also register is programmed in omap_gpio_restore_context() called which is called from runtime resume callback. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com 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 v3 10/13] gpio/omap: fix missing dataout context save in _set_gpio_dataout_reg
On Wednesday 07 March 2012 12:16 PM, Tarun Kanti DebBarma wrote: There are two functions, _set_gpio_dataout_reg() and _set_gpio_dataout_mask() which writes to dataout register and the dataout context must be saved. It is missing in the first function, _set_gpio_dataout_reg(). Fix this. Reported-by: Govindraj Raja govindraj.r...@ti.com Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- Good catch. Is the suspend/resume caught this issue? This can go as a fix as well. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com 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 v3 08/13] gpio/omap: remove redundant decoding of gpio offset
On Wednesday 07 March 2012 12:15 PM, Tarun Kanti DebBarma wrote:
In gpio_get(), _get_gpio_datain() and _get_gpio_dataout() get rid of
un-necessary operation to compute gpio mask. The gpio offset passed
to gpio_get() is sufficient to do that.
Here is Russell's original comment:
Can someone explain to me this:
#define GPIO_INDEX(bank, gpio) (gpio % bank-width)
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
static int _get_gpio_datain(struct gpio_bank *bank, int gpio)
{
void __iomem *reg = bank-base + bank-regs-datain;
return (__raw_readl(reg) GPIO_BIT(bank, gpio)) != 0;
}
static int gpio_get(struct gpio_chip *chip, unsigned offset)
{
struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
void __iomem *reg = bank-base;
int gpio = chip-base + offset;
u32 mask = GPIO_BIT(bank, gpio);
if (gpio_is_input(bank, mask))
return _get_gpio_datain(bank, gpio);
else
return _get_gpio_dataout(bank, gpio);
}
Given that bank-width on OMAP is either 32 or 16, and GPIO numbers for
any GPIO chip are always aligned to 32 or 16, why does this code bother
adding the chips base gpio number and then modulo the width?
Surely this means if - for argument sake - you registered a GPIO chip
with 8 lines followed by one with 16 lines, GPIO0..7 would be chip 0
bit 0..7, GPIO8..15 would be chip 1 bit 8..15, GPIO16..23 would be
chip 1 bit 0..7.
However, if you registered a GPIO chip with 16 lines first, it would
mean GPIO0..15 would be chip 0 bit 0..15, and GPIO16..31 would be
chip 1 bit 0..15.
Surely this kind of behaviour is not intended?
Is there a reason why the bitmask can't just be (1 offset) where
offset is passed into these functions as GPIO number - chip-base ?
Reported-by: Russell King - ARM Linux li...@arm.linux.org.uk
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Looks good.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
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] omap2+: add drm device
On Tue, 2012-03-06 at 09:50 -0600, Gross, Andy wrote: On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: I have to say I don't know much about DMM, but my understanding is that DMM is a bigger entity, of which TILER is only a small part, and DMM manages all memory accesses. Can there be other users for the DMM than DRM? I know there could be other users for the TILER, and I know you want to combine that with the DRM driver, but I'm wondering about the other parts of DMM than the TILER. Somehow having a DMM driver inside omapdrm sounds strange. The DMM does indeed contain a number of entities. However, the TILER portion is the only part that requires a driver. All other register modifications (LISA map settings, EMIF, etc) are done statically in the loader or u-boot and never changed again. As such, DMM has become synonymous with TILER. Ok. Well, as I said, I don't know much about that, just sounds rather strange to me =). Does this DMM has become synonymous mean that people just started calling TILER DMM, and thus the name has stuck, or are there technical reasons to handle it as DMM in the kernel? If the former, and if TILER is the technically exact name for it, perhaps it would make sense to call it TILER, as that's what (at least I) would be looking for if I read the TRM and try to find the code for the TILER. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v3 12/13] gpio/omap: fix incorrect context restore logic in omap_gpio_runtime_resume
On Wednesday 07 March 2012 12:16 PM, Tarun Kanti DebBarma wrote:
In omap_gpio_runtime_resume() the context restore should be independent
of bank-enabled_non_wakeup_gpios. This was preventing context restore
of GPIO lines which are not wakeup enabled.
Reported-by: Govindraj Raja govindraj.r...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
drivers/gpio/gpio-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 2e8e476..ccfbae0 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1227,7 +1227,7 @@ static int omap_gpio_runtime_resume(struct device *dev)
__raw_writel(bank-context.risingdetect,
bank-base + bank-regs-risingdetect);
- if (!bank-enabled_non_wakeup_gpios || !bank-workaround_enabled) {
+ if (!bank-workaround_enabled) {
This doesn't seem to be right.
Don't you want to avoid GPIO restore for banks which are in
always on domain. Infact the purpose of enabled_non_wakeup_gpios
is exactly that ? Isn't it.
What am I missing ?
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 v3 13/13] gpio/omap: fix incorrect update to context.irqenable1
On Wednesday 07 March 2012 12:16 PM, Tarun Kanti DebBarma wrote:
In _enable_gpio_irqbank() when bank-regs-set_irqenable is valid,
gpio_mask can be directly set by writing to set_irqenable register
without overwriting current value. In order to ensure the same is
stored in context.irqenable1, we must read from regs-irqenable
instead of overwriting it with gpio_mask.
The overwriting makes sense only in the second case where irqenable
is explicitly read and updated with new gpio_mask before writing it
back. However, for consistency reading regs-irqenable into the
bank-context.irqenable1 takes care of both the scenarios.
if (bank-regs-set_irqenable) {
reg += bank-regs-set_irqenable;
l = gpio_mask;
} else {
reg += bank-regs-irqenable;
l = __raw_readl(reg);
if (bank-regs-irqenable_inv)
l = ~gpio_mask;
else
l |= gpio_mask;
}
Make the same change for _disable_gpio_irqbank().
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
OK.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
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 v3 11/13] gpio/omap: fix dataout register overwrite in _set_gpio_dataout_*
On Wednesday 07 March 2012 12:16 PM, Tarun Kanti DebBarma wrote: In the existing _set_gpio_dataout_*() implementation, the dataout register is overwritten every time the function is called. This is not intended behavior because that would end up one user of a GPIO line overwriting what is written by another. Fix this so that previous value is always preserved until explicitly changed by respective user/driver of the GPIO line. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- This can also go as fix. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com 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
[PATCH] omap_hwmod: Allow io_ring wakeup configuration for all modules.
From: Govindraj.R govindraj.r...@ti.com
Some modules doesn't have SYSC_HAS_ENAWAKEUP bit available
(ex: usb host uhh module) in absence of this flag
omap_hwmod_enable/disable_wakeup avoids configuring
pad mux wakeup capability.
Configure sysc if SYSC_HAS_ENAWAKEUP is available and for other cases
try enabling/disabling wakeup from mux_pad pins.
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 30 --
1 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index eba6cd3..89582df 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2475,14 +2475,15 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
unsigned long flags;
u32 v;
- if (!oh-class-sysc ||
- !(oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP))
- return -EINVAL;
-
spin_lock_irqsave(oh-_lock, flags);
- v = oh-_sysc_cache;
- _enable_wakeup(oh, v);
- _write_sysconfig(v, oh);
+
+ if (oh-class-sysc
+ (oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP)) {
+ v = oh-_sysc_cache;
+ _enable_wakeup(oh, v);
+ _write_sysconfig(v, oh);
+ }
+
_set_idle_ioring_wakeup(oh, true);
spin_unlock_irqrestore(oh-_lock, flags);
@@ -2506,14 +2507,15 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
unsigned long flags;
u32 v;
- if (!oh-class-sysc ||
- !(oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP))
- return -EINVAL;
-
spin_lock_irqsave(oh-_lock, flags);
- v = oh-_sysc_cache;
- _disable_wakeup(oh, v);
- _write_sysconfig(v, oh);
+
+ if (oh-class-sysc ||
+ (oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP)) {
+ v = oh-_sysc_cache;
+ _disable_wakeup(oh, v);
+ _write_sysconfig(v, oh);
+ }
+
_set_idle_ioring_wakeup(oh, false);
spin_unlock_irqrestore(oh-_lock, flags);
--
1.7.5.4
--
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] plat-omap: mcbsp: Configure wakeup in later phase
On 03/05/2012 09:50 PM, Tony Lindgren wrote: Just checking.. I assume this one is already taken care of with your other McBSP changes? Yes it is. I just resent it against the moved McBSP driver for ASoC. -- Péter -- 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 00/21] OMAPDSS: DT preparation patches
Hi,
I started cleaning up and restructuring omapdss for device tree, and here's the
first set of patches from that ordeal. There's nothing DT specific in these
patches, but they are mostly generic cleanups that make sense even without DT.
The custom pdev creation depends on the following patches posted on l-o:
ARM: OMAP: remove omap_device_parent
ARM: OMAP: omap_device: Expose omap_device_{alloc, delete, register}
This series can also be found from:
git://gitorious.org/linux-omap-dss2/linux.git work/devtree-base
Tomi
Tomi Valkeinen (21):
OMAPDSS: panel-dvi: add PD gpio handling
OMAP: board-files: remove custom PD GPIO handling for DVI output
OMAPDSS: TFP410: rename dvi - tfp410
OMAPDSS: TFP410: rename dvi files to tfp410
OMAPDSS: TFP410: pdata rewrite
OMAPDSS: DSI: use dsi_get_dsidev_id(dsidev) instead of dsidev-id
OMAPDSS: Taal: move reset gpio handling to taal driver
OMAPDSS: clean up the omapdss platform data mess
OMAPDSS: remove return from platform_driver_unreg
OMAPDSS: use platform_driver_probe for core/dispc/dss
OMAPDSS: register dss drivers in module init
OMAPDSS: create custom pdevs for DSS omap_devices
OMAPDSS: create DPI SDI devices
OMAPDSS: create DPI SDI drivers
OMAPDSS: remove uses of dss_runtime_get/put
OMAPDSS: handle output-driver reg/unreg more dynamically
OMAPDSS: move the creation of debugfs files
OMAPDSS: use platform_driver_probe for dsi/hdmi/rfbi/venc/dpi/sdi
OMAPDSS: add __init __exit
OMAPFB: add __init __exit
OMAPDSS: change default_device handling
arch/arm/mach-omap2/board-3430sdp.c| 38 +---
arch/arm/mach-omap2/board-4430sdp.c| 16 --
arch/arm/mach-omap2/board-am3517evm.c | 25 +--
arch/arm/mach-omap2/board-cm-t35.c | 30 +--
arch/arm/mach-omap2/board-devkit8000.c | 30 +--
arch/arm/mach-omap2/board-igep0020.c | 32 +--
arch/arm/mach-omap2/board-omap3beagle.c| 37 +---
arch/arm/mach-omap2/board-omap3evm.c | 29 +--
arch/arm/mach-omap2/board-omap3stalker.c | 29 +--
arch/arm/mach-omap2/board-omap4panda.c | 39 +---
arch/arm/mach-omap2/board-overo.c | 25 +--
arch/arm/mach-omap2/display.c | 172 +++--
drivers/video/omap2/displays/Kconfig |8 +-
drivers/video/omap2/displays/Makefile |2 +-
drivers/video/omap2/displays/panel-taal.c | 15 ++
.../omap2/displays/{panel-dvi.c = panel-tfp410.c} | 186 --
drivers/video/omap2/dss/core.c | 260 +---
drivers/video/omap2/dss/dispc.c| 50 ++---
drivers/video/omap2/dss/dpi.c | 38 ++--
drivers/video/omap2/dss/dsi.c | 86 ++-
drivers/video/omap2/dss/dss.c | 46 ++---
drivers/video/omap2/dss/dss.h | 76 +-
drivers/video/omap2/dss/hdmi.c | 55 +
drivers/video/omap2/dss/rfbi.c | 31 +--
drivers/video/omap2/dss/sdi.c | 31 ++-
drivers/video/omap2/dss/venc.c | 31 +--
drivers/video/omap2/omapfb/omapfb-main.c |9 +-
.../{omap-panel-dvi.h = omap-panel-tfp410.h} | 18 +-
include/video/omapdss.h|5 -
29 files changed, 628 insertions(+), 821 deletions(-)
rename drivers/video/omap2/displays/{panel-dvi.c = panel-tfp410.c} (56%)
rename include/video/{omap-panel-dvi.h = omap-panel-tfp410.h} (63%)
--
1.7.4.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 01/21] OMAPDSS: panel-dvi: add PD gpio handling
The driver for the DVI framer should handle the power-down signal of the
framer, instead of the current way of handling it in the board files.
This patch adds power_down_gpio into the device's platform data, and
adds the necessary code in the driver to request and handle the GPIO.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-dvi.c | 31 ++
include/video/omap-panel-dvi.h |2 +
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-dvi.c
b/drivers/video/omap2/displays/panel-dvi.c
index 03eb14a..876b798 100644
--- a/drivers/video/omap2/displays/panel-dvi.c
+++ b/drivers/video/omap2/displays/panel-dvi.c
@@ -21,6 +21,7 @@
#include linux/slab.h
#include video/omapdss.h
#include linux/i2c.h
+#include linux/gpio.h
#include drm/drm_edid.h
#include video/omap-panel-dvi.h
@@ -44,6 +45,8 @@ struct panel_drv_data {
struct omap_dss_device *dssdev;
struct mutex lock;
+
+ int pd_gpio;
};
static inline struct panel_dvi_platform_data
@@ -54,6 +57,7 @@ static inline struct panel_dvi_platform_data
static int panel_dvi_power_on(struct omap_dss_device *dssdev)
{
+ struct panel_drv_data *ddata = dev_get_drvdata(dssdev-dev);
struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
int r;
@@ -70,6 +74,9 @@ static int panel_dvi_power_on(struct omap_dss_device *dssdev)
goto err1;
}
+ if (gpio_is_valid(ddata-pd_gpio))
+ gpio_set_value(ddata-pd_gpio, 1);
+
return 0;
err1:
omapdss_dpi_display_disable(dssdev);
@@ -79,11 +86,15 @@ err0:
static void panel_dvi_power_off(struct omap_dss_device *dssdev)
{
+ struct panel_drv_data *ddata = dev_get_drvdata(dssdev-dev);
struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
return;
+ if (gpio_is_valid(ddata-pd_gpio))
+ gpio_set_value(ddata-pd_gpio, 0);
+
if (pdata-platform_disable)
pdata-platform_disable(dssdev);
@@ -92,7 +103,9 @@ static void panel_dvi_power_off(struct omap_dss_device
*dssdev)
static int panel_dvi_probe(struct omap_dss_device *dssdev)
{
+ struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
struct panel_drv_data *ddata;
+ int r;
ddata = kzalloc(sizeof(*ddata), GFP_KERNEL);
if (!ddata)
@@ -104,6 +117,21 @@ static int panel_dvi_probe(struct omap_dss_device *dssdev)
ddata-dssdev = dssdev;
mutex_init(ddata-lock);
+ if (pdata)
+ ddata-pd_gpio = pdata-power_down_gpio;
+ else
+ ddata-pd_gpio = -1;
+
+ if (gpio_is_valid(ddata-pd_gpio)) {
+ r = gpio_request_one(ddata-pd_gpio, GPIOF_OUT_INIT_LOW,
+ tfp410 pd);
+ if (r) {
+ dev_err(dssdev-dev, Failed to request PD GPIO %d\n,
+ ddata-pd_gpio);
+ ddata-pd_gpio = -1;
+ }
+ }
+
dev_set_drvdata(dssdev-dev, ddata);
return 0;
@@ -115,6 +143,9 @@ static void __exit panel_dvi_remove(struct omap_dss_device
*dssdev)
mutex_lock(ddata-lock);
+ if (gpio_is_valid(ddata-pd_gpio))
+ gpio_free(ddata-pd_gpio);
+
dev_set_drvdata(dssdev-dev, NULL);
mutex_unlock(ddata-lock);
diff --git a/include/video/omap-panel-dvi.h b/include/video/omap-panel-dvi.h
index 87ad567b..4ad41fc 100644
--- a/include/video/omap-panel-dvi.h
+++ b/include/video/omap-panel-dvi.h
@@ -27,11 +27,13 @@ struct omap_dss_device;
* @platform_enable: platform specific panel enable function
* @platform_disable: platform specific panel disable function
* @i2c_bus_num: i2c bus id for the panel
+ * @power_down_gpio: gpio number for PD pin (or -1 if not available)
*/
struct panel_dvi_platform_data {
int (*platform_enable)(struct omap_dss_device *dssdev);
void (*platform_disable)(struct omap_dss_device *dssdev);
u16 i2c_bus_num;
+ int power_down_gpio;
};
#endif /* __OMAP_PANEL_DVI_H */
--
1.7.4.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 03/21] OMAPDSS: TFP410: rename dvi - tfp410
The driver for the TFP410 DVI framer chip was named quite badly as DVI
panel driver. This patch renames the code to use tfp410 name for the
driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-3430sdp.c |4 +-
arch/arm/mach-omap2/board-am3517evm.c|4 +-
arch/arm/mach-omap2/board-cm-t35.c |4 +-
arch/arm/mach-omap2/board-devkit8000.c |4 +-
arch/arm/mach-omap2/board-igep0020.c |4 +-
arch/arm/mach-omap2/board-omap3beagle.c |4 +-
arch/arm/mach-omap2/board-omap3evm.c |4 +-
arch/arm/mach-omap2/board-omap3stalker.c |4 +-
arch/arm/mach-omap2/board-omap4panda.c |4 +-
arch/arm/mach-omap2/board-overo.c|4 +-
drivers/video/omap2/displays/Kconfig |8 +-
drivers/video/omap2/displays/Makefile|2 +-
drivers/video/omap2/displays/panel-dvi.c | 94 +++---
include/video/omap-panel-dvi.h | 12 ++--
14 files changed, 78 insertions(+), 78 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 7105005..2c153bb 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -157,14 +157,14 @@ static struct omap_dss_device sdp3430_lcd_device = {
.platform_disable = sdp3430_panel_disable_lcd,
};
-static struct panel_dvi_platform_data dvi_panel = {
+static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= -1,
};
static struct omap_dss_device sdp3430_dvi_device = {
.name = dvi,
.type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name= dvi,
+ .driver_name= tfp410,
.data = dvi_panel,
.phy.dpi.data_lines = 24,
};
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 958dd97..c38dac1 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -320,14 +320,14 @@ static struct omap_dss_device am3517_evm_tv_device = {
.platform_disable = am3517_evm_panel_disable_tv,
};
-static struct panel_dvi_platform_data dvi_panel = {
+static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= -1,
};
static struct omap_dss_device am3517_evm_dvi_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = dvi,
- .driver_name= dvi,
+ .driver_name= tfp410,
.data = dvi_panel,
.phy.dpi.data_lines = 24,
};
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 5a361c9..94d5167 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -225,14 +225,14 @@ static struct omap_dss_device cm_t35_lcd_device = {
.phy.dpi.data_lines = 18,
};
-static struct panel_dvi_platform_data dvi_panel = {
+static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= CM_T35_DVI_EN_GPIO,
};
static struct omap_dss_device cm_t35_dvi_device = {
.name = dvi,
.type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name= dvi,
+ .driver_name= tfp410,
.data = dvi_panel,
.phy.dpi.data_lines = 24,
};
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 07edb6d..d1bead0 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -140,14 +140,14 @@ static struct omap_dss_device devkit8000_lcd_device = {
.phy.dpi.data_lines = 24,
};
-static struct panel_dvi_platform_data dvi_panel = {
+static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= -1,
};
static struct omap_dss_device devkit8000_dvi_device = {
.name = dvi,
.type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name= dvi,
+ .driver_name= tfp410,
.data = dvi_panel,
.phy.dpi.data_lines = 24,
};
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 21188f8..ae1b157 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -443,7 +443,7 @@ static struct twl4030_gpio_platform_data
igep_twl4030_gpio_pdata = {
.setup = igep_twl_gpio_setup,
};
-static struct panel_dvi_platform_data dvi_panel = {
+static struct tfp410_platform_data dvi_panel = {
.i2c_bus_num= 3,
.power_down_gpio= IGEP2_GPIO_DVI_PUP,
};
@@ -451,7 +451,7 @@ static struct panel_dvi_platform_data dvi_panel = {
static struct omap_dss_device igep2_dvi_device = {
.type =
[PATCH 02/21] OMAP: board-files: remove custom PD GPIO handling for DVI output
Now that the panel-dvi driver handles the PD (power-down) GPIO, we can
remove the custom PD handling from the board files.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-3430sdp.c | 32 +
arch/arm/mach-omap2/board-am3517evm.c| 19 +
arch/arm/mach-omap2/board-cm-t35.c | 24 +
arch/arm/mach-omap2/board-devkit8000.c | 24 +
arch/arm/mach-omap2/board-igep0020.c | 26 +-
arch/arm/mach-omap2/board-omap3beagle.c | 31 +--
arch/arm/mach-omap2/board-omap3evm.c | 23 +
arch/arm/mach-omap2/board-omap3stalker.c | 23 +
arch/arm/mach-omap2/board-omap4panda.c | 33 +
arch/arm/mach-omap2/board-overo.c| 19 +
drivers/video/omap2/displays/panel-dvi.c | 13 ---
include/video/omap-panel-dvi.h |4 ---
12 files changed, 14 insertions(+), 257 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 383717b..7105005 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -113,9 +113,6 @@ static struct gpio sdp3430_dss_gpios[] __initdata = {
{SDP3430_LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, LCD Backlight},
};
-static int lcd_enabled;
-static int dvi_enabled;
-
static void __init sdp3430_display_init(void)
{
int r;
@@ -129,44 +126,18 @@ static void __init sdp3430_display_init(void)
static int sdp3430_panel_enable_lcd(struct omap_dss_device *dssdev)
{
- if (dvi_enabled) {
- printk(KERN_ERR cannot enable LCD, DVI is enabled\n);
- return -EINVAL;
- }
-
gpio_direction_output(SDP3430_LCD_PANEL_ENABLE_GPIO, 1);
gpio_direction_output(SDP3430_LCD_PANEL_BACKLIGHT_GPIO, 1);
- lcd_enabled = 1;
-
return 0;
}
static void sdp3430_panel_disable_lcd(struct omap_dss_device *dssdev)
{
- lcd_enabled = 0;
-
gpio_direction_output(SDP3430_LCD_PANEL_ENABLE_GPIO, 0);
gpio_direction_output(SDP3430_LCD_PANEL_BACKLIGHT_GPIO, 0);
}
-static int sdp3430_panel_enable_dvi(struct omap_dss_device *dssdev)
-{
- if (lcd_enabled) {
- printk(KERN_ERR cannot enable DVI, LCD is enabled\n);
- return -EINVAL;
- }
-
- dvi_enabled = 1;
-
- return 0;
-}
-
-static void sdp3430_panel_disable_dvi(struct omap_dss_device *dssdev)
-{
- dvi_enabled = 0;
-}
-
static int sdp3430_panel_enable_tv(struct omap_dss_device *dssdev)
{
return 0;
@@ -187,8 +158,7 @@ static struct omap_dss_device sdp3430_lcd_device = {
};
static struct panel_dvi_platform_data dvi_panel = {
- .platform_enable= sdp3430_panel_enable_dvi,
- .platform_disable = sdp3430_panel_disable_dvi,
+ .power_down_gpio= -1,
};
static struct omap_dss_device sdp3430_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 4b1cfe3..958dd97 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -320,25 +320,8 @@ static struct omap_dss_device am3517_evm_tv_device = {
.platform_disable = am3517_evm_panel_disable_tv,
};
-static int am3517_evm_panel_enable_dvi(struct omap_dss_device *dssdev)
-{
- if (lcd_enabled) {
- printk(KERN_ERR cannot enable DVI, LCD is enabled\n);
- return -EINVAL;
- }
- dvi_enabled = 1;
-
- return 0;
-}
-
-static void am3517_evm_panel_disable_dvi(struct omap_dss_device *dssdev)
-{
- dvi_enabled = 0;
-}
-
static struct panel_dvi_platform_data dvi_panel = {
- .platform_enable= am3517_evm_panel_enable_dvi,
- .platform_disable = am3517_evm_panel_disable_dvi,
+ .power_down_gpio= -1,
};
static struct omap_dss_device am3517_evm_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index d73316e..5a361c9 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -202,25 +202,6 @@ static void cm_t35_panel_disable_lcd(struct
omap_dss_device *dssdev)
gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
}
-static int cm_t35_panel_enable_dvi(struct omap_dss_device *dssdev)
-{
- if (lcd_enabled) {
- printk(KERN_ERR cannot enable DVI, LCD is enabled\n);
- return -EINVAL;
- }
-
- gpio_set_value(CM_T35_DVI_EN_GPIO, 0);
- dvi_enabled = 1;
-
- return 0;
-}
-
-static void cm_t35_panel_disable_dvi(struct omap_dss_device *dssdev)
-{
- gpio_set_value(CM_T35_DVI_EN_GPIO, 1);
- dvi_enabled = 0;
-}
-
static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
{
return 0;
@@
[PATCH 04/21] OMAPDSS: TFP410: rename dvi files to tfp410
Now that the tfp410 driver has been renamed in the code, this patch
finishes the renaming by renaming the files.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-3430sdp.c|2 +-
arch/arm/mach-omap2/board-am3517evm.c |2 +-
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c|2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3stalker.c |2 +-
arch/arm/mach-omap2/board-omap4panda.c |2 +-
arch/arm/mach-omap2/board-overo.c |2 +-
drivers/video/omap2/displays/Makefile |2 +-
.../omap2/displays/{panel-dvi.c = panel-tfp410.c} |2 +-
.../{omap-panel-dvi.h = omap-panel-tfp410.h} |0
13 files changed, 12 insertions(+), 12 deletions(-)
rename drivers/video/omap2/displays/{panel-dvi.c = panel-tfp410.c} (99%)
rename include/video/{omap-panel-dvi.h = omap-panel-tfp410.h} (100%)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 2c153bb..fdcbaaf 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -37,7 +37,7 @@
#include plat/dma.h
#include plat/gpmc.h
#include video/omapdss.h
-#include video/omap-panel-dvi.h
+#include video/omap-panel-tfp410.h
#include plat/gpmc-smc91x.h
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index c38dac1..fadd25f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -37,7 +37,7 @@
#include plat/usb.h
#include video/omapdss.h
#include video/omap-panel-generic-dpi.h
-#include video/omap-panel-dvi.h
+#include video/omap-panel-tfp410.h
#include mux.h
#include control.h
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 94d5167..54d8f0f 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -43,7 +43,7 @@
#include plat/usb.h
#include video/omapdss.h
#include video/omap-panel-generic-dpi.h
-#include video/omap-panel-dvi.h
+#include video/omap-panel-tfp410.h
#include plat/mcspi.h
#include mach/hardware.h
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index d1bead0..677f16e 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -47,7 +47,7 @@
#include plat/usb.h
#include video/omapdss.h
#include video/omap-panel-generic-dpi.h
-#include video/omap-panel-dvi.h
+#include video/omap-panel-tfp410.h
#include plat/mcspi.h
#include linux/input/matrix_keypad.h
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index ae1b157..6e56ccc 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -32,7 +32,7 @@
#include plat/gpmc.h
#include plat/usb.h
#include video/omapdss.h
-#include video/omap-panel-dvi.h
+#include video/omap-panel-tfp410.h
#include plat/onenand.h
#include mux.h
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 5f858e9..df6acae 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -42,7 +42,7 @@
#include plat/board.h
#include common.h
#include video/omapdss.h
-#include video/omap-panel-dvi.h
+#include video/omap-panel-tfp410.h
#include plat/gpmc.h
#include plat/nand.h
#include plat/usb.h
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 840fb99..1a34bee 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -46,7 +46,7 @@
#include common.h
#include plat/mcspi.h
#include video/omapdss.h
-#include video/omap-panel-dvi.h
+#include video/omap-panel-tfp410.h
#include mux.h
#include sdram-micron-mt46h32m32lf-6.h
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index 8a292cc..d05e7a7 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -41,7 +41,7 @@
#include plat/usb.h
#include video/omapdss.h
#include video/omap-panel-generic-dpi.h
-#include video/omap-panel-dvi.h
+#include video/omap-panel-tfp410.h
#include plat/mcspi.h
#include linux/input/matrix_keypad.h
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 8196d6e..959b4ed 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -40,7 +40,7 @@
#include common.h
#include plat/usb.h
#include plat/mmc.h
-#include video/omap-panel-dvi.h
+#include video/omap-panel-tfp410.h
#include hsmmc.h
[PATCH 05/21] OMAPDSS: TFP410: pdata rewrite
To ease device tree adaptation in the future, rewrite TFP410 platform
data handling to be done inside probe(), so that probe() is the only
place where we need to handle the DT/pdata choice.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-tfp410.c | 72 ++-
1 files changed, 38 insertions(+), 34 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tfp410.c
b/drivers/video/omap2/displays/panel-tfp410.c
index 4b867bf..a369d2c 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -47,13 +47,9 @@ struct panel_drv_data {
struct mutex lock;
int pd_gpio;
-};
-static inline struct tfp410_platform_data
-*get_pdata(const struct omap_dss_device *dssdev)
-{
- return dssdev-data;
-}
+ struct i2c_adapter *i2c_adapter;
+};
static int tfp410_power_on(struct omap_dss_device *dssdev)
{
@@ -90,11 +86,11 @@ static void tfp410_power_off(struct omap_dss_device *dssdev)
static int tfp410_probe(struct omap_dss_device *dssdev)
{
- struct tfp410_platform_data *pdata = get_pdata(dssdev);
struct panel_drv_data *ddata;
int r;
+ int i2c_bus_num;
- ddata = kzalloc(sizeof(*ddata), GFP_KERNEL);
+ ddata = devm_kzalloc(dssdev-dev, sizeof(*ddata), GFP_KERNEL);
if (!ddata)
return -ENOMEM;
@@ -104,10 +100,15 @@ static int tfp410_probe(struct omap_dss_device *dssdev)
ddata-dssdev = dssdev;
mutex_init(ddata-lock);
- if (pdata)
+ if (dssdev-data) {
+ struct tfp410_platform_data *pdata = dssdev-data;
+
ddata-pd_gpio = pdata-power_down_gpio;
- else
+ i2c_bus_num = pdata-i2c_bus_num;
+ } else {
ddata-pd_gpio = -1;
+ i2c_bus_num = -1;
+ }
if (gpio_is_valid(ddata-pd_gpio)) {
r = gpio_request_one(ddata-pd_gpio, GPIOF_OUT_INIT_LOW,
@@ -115,13 +116,31 @@ static int tfp410_probe(struct omap_dss_device *dssdev)
if (r) {
dev_err(dssdev-dev, Failed to request PD GPIO %d\n,
ddata-pd_gpio);
- ddata-pd_gpio = -1;
+ return r;
}
}
+ if (i2c_bus_num != -1) {
+ struct i2c_adapter *adapter;
+
+ adapter = i2c_get_adapter(i2c_bus_num);
+ if (!adapter) {
+ dev_err(dssdev-dev, Failed to get I2C adapter, bus
%d\n,
+ i2c_bus_num);
+ r = -EINVAL;
+ goto err_i2c;
+ }
+
+ ddata-i2c_adapter = adapter;
+ }
+
dev_set_drvdata(dssdev-dev, ddata);
return 0;
+err_i2c:
+ if (gpio_is_valid(ddata-pd_gpio))
+ gpio_free(ddata-pd_gpio);
+ return r;
}
static void __exit tfp410_remove(struct omap_dss_device *dssdev)
@@ -130,14 +149,15 @@ static void __exit tfp410_remove(struct omap_dss_device
*dssdev)
mutex_lock(ddata-lock);
+ if (ddata-i2c_adapter)
+ i2c_put_adapter(ddata-i2c_adapter);
+
if (gpio_is_valid(ddata-pd_gpio))
gpio_free(ddata-pd_gpio);
dev_set_drvdata(dssdev-dev, NULL);
mutex_unlock(ddata-lock);
-
- kfree(ddata);
}
static int tfp410_enable(struct omap_dss_device *dssdev)
@@ -269,27 +289,17 @@ static int tfp410_read_edid(struct omap_dss_device
*dssdev,
u8 *edid, int len)
{
struct panel_drv_data *ddata = dev_get_drvdata(dssdev-dev);
- struct tfp410_platform_data *pdata = get_pdata(dssdev);
- struct i2c_adapter *adapter;
int r, l, bytes_read;
mutex_lock(ddata-lock);
- if (pdata-i2c_bus_num == 0) {
+ if (!ddata-i2c_adapter) {
r = -ENODEV;
goto err;
}
- adapter = i2c_get_adapter(pdata-i2c_bus_num);
- if (!adapter) {
- dev_err(dssdev-dev, Failed to get I2C adapter, bus %d\n,
- pdata-i2c_bus_num);
- r = -EINVAL;
- goto err;
- }
-
l = min(EDID_LENGTH, len);
- r = tfp410_ddc_read(adapter, edid, l, 0);
+ r = tfp410_ddc_read(ddata-i2c_adapter, edid, l, 0);
if (r)
goto err;
@@ -299,7 +309,7 @@ static int tfp410_read_edid(struct omap_dss_device *dssdev,
if (len EDID_LENGTH edid[0x7e] 0) {
l = min(EDID_LENGTH, len - EDID_LENGTH);
- r = tfp410_ddc_read(adapter, edid + EDID_LENGTH,
+ r = tfp410_ddc_read(ddata-i2c_adapter, edid + EDID_LENGTH,
l, EDID_LENGTH);
if (r)
goto err;
@@ -319,21 +329,15 @@ err:
static bool tfp410_detect(struct omap_dss_device *dssdev)
{
struct
[PATCH 06/21] OMAPDSS: DSI: use dsi_get_dsidev_id(dsidev) instead of dsidev-id
The DSI driver uses dsi_get_dsidev_id() to get the ID number for the DSI instance. However, there were a few places where dsidev-id was used instead of the function. Fix those places to use the function. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/dsi.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c index 662d14f..3e656be 100644 --- a/drivers/video/omap2/dss/dsi.c +++ b/drivers/video/omap2/dss/dsi.c @@ -2396,7 +2396,7 @@ static int dsi_cio_init(struct omap_dss_device *dssdev) DSSDBGF(); - r = dsi-enable_pads(dsidev-id, dsi_get_lane_mask(dssdev)); + r = dsi-enable_pads(dsi_get_dsidev_id(dsidev), dsi_get_lane_mask(dssdev)); if (r) return r; @@ -2506,7 +2506,7 @@ err_cio_pwr: dsi_cio_disable_lane_override(dsidev); err_scp_clk_dom: dsi_disable_scp_clk(dsidev); - dsi-disable_pads(dsidev-id, dsi_get_lane_mask(dssdev)); + dsi-disable_pads(dsi_get_dsidev_id(dsidev), dsi_get_lane_mask(dssdev)); return r; } @@ -2520,7 +2520,7 @@ static void dsi_cio_uninit(struct omap_dss_device *dssdev) dsi_cio_power(dsidev, DSI_COMPLEXIO_POWER_OFF); dsi_disable_scp_clk(dsidev); - dsi-disable_pads(dsidev-id, dsi_get_lane_mask(dssdev)); + dsi-disable_pads(dsi_get_dsidev_id(dsidev), dsi_get_lane_mask(dssdev)); } static void dsi_config_tx_fifo(struct platform_device *dsidev, -- 1.7.4.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 07/21] OMAPDSS: Taal: move reset gpio handling to taal driver
The reset GPIO for Taal panel driver is currently requested in the
4430sdp board file. This patch moves the gpio request/free into the Taal
driver, where it should be.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 16
drivers/video/omap2/displays/panel-taal.c | 15 +++
2 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 4e90715..3a05173 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -724,21 +724,6 @@ static struct omap_dss_device sdp4430_lcd2_device = {
.channel= OMAP_DSS_CHANNEL_LCD2,
};
-static void sdp4430_lcd_init(void)
-{
- int r;
-
- r = gpio_request_one(dsi1_panel.reset_gpio, GPIOF_DIR_OUT,
- lcd1_reset_gpio);
- if (r)
- pr_err(%s: Could not get lcd1_reset_gpio\n, __func__);
-
- r = gpio_request_one(dsi2_panel.reset_gpio, GPIOF_DIR_OUT,
- lcd2_reset_gpio);
- if (r)
- pr_err(%s: Could not get lcd2_reset_gpio\n, __func__);
-}
-
static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
.hpd_gpio = HDMI_GPIO_HPD,
};
@@ -824,7 +809,6 @@ static void __init omap_4430sdp_display_init(void)
if (r)
pr_err(%s: Could not get display_sel GPIO\n, __func__);
- sdp4430_lcd_init();
sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
/*
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index 00c5c61..6e240fe 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -993,6 +993,15 @@ static int taal_probe(struct omap_dss_device *dssdev)
dev_set_drvdata(dssdev-dev, td);
+ if (gpio_is_valid(panel_data-reset_gpio)) {
+ r = gpio_request_one(panel_data-reset_gpio, GPIOF_OUT_INIT_LOW,
+ taal rst);
+ if (r) {
+ dev_err(dssdev-dev, failed to request reset gpio\n);
+ goto err_rst_gpio;
+ }
+ }
+
taal_hw_reset(dssdev);
if (panel_data-use_dsi_backlight) {
@@ -1075,6 +1084,9 @@ err_gpio:
if (bldev != NULL)
backlight_device_unregister(bldev);
err_bl:
+ if (gpio_is_valid(panel_data-reset_gpio))
+ gpio_free(panel_data-reset_gpio);
+err_rst_gpio:
destroy_workqueue(td-workqueue);
err_wq:
free_regulators(panel_config-regulators, panel_config-num_regulators);
@@ -1115,6 +1127,9 @@ static void __exit taal_remove(struct omap_dss_device
*dssdev)
/* reset, to be sure that the panel is in a valid state */
taal_hw_reset(dssdev);
+ if (gpio_is_valid(panel_data-reset_gpio))
+ gpio_free(panel_data-reset_gpio);
+
free_regulators(td-panel_config-regulators,
td-panel_config-num_regulators);
--
1.7.4.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 09/21] OMAPDSS: remove return from platform_driver_unreg
For unknown reasons we seem to have a return in each of the omapdss's
uninit functions, which is a void function.
Remove the returns.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c |2 +-
drivers/video/omap2/dss/dsi.c |2 +-
drivers/video/omap2/dss/dss.c |2 +-
drivers/video/omap2/dss/hdmi.c |2 +-
drivers/video/omap2/dss/rfbi.c |2 +-
drivers/video/omap2/dss/venc.c |2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 703bb20..5985c3c 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3447,5 +3447,5 @@ int dispc_init_platform_driver(void)
void dispc_uninit_platform_driver(void)
{
- return platform_driver_unregister(omap_dispchw_driver);
+ platform_driver_unregister(omap_dispchw_driver);
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 4e2f7ff..cf59f40 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4849,5 +4849,5 @@ int dsi_init_platform_driver(void)
void dsi_uninit_platform_driver(void)
{
- return platform_driver_unregister(omap_dsihw_driver);
+ platform_driver_unregister(omap_dsihw_driver);
}
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 4a6b5ee..7d3facc 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -857,5 +857,5 @@ int dss_init_platform_driver(void)
void dss_uninit_platform_driver(void)
{
- return platform_driver_unregister(omap_dsshw_driver);
+ platform_driver_unregister(omap_dsshw_driver);
}
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index cacf856..b4ad13b 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -915,5 +915,5 @@ int hdmi_init_platform_driver(void)
void hdmi_uninit_platform_driver(void)
{
- return platform_driver_unregister(omapdss_hdmihw_driver);
+ platform_driver_unregister(omapdss_hdmihw_driver);
}
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 788a0ef..dfd8ec5 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -1019,5 +1019,5 @@ int rfbi_init_platform_driver(void)
void rfbi_uninit_platform_driver(void)
{
- return platform_driver_unregister(omap_rfbihw_driver);
+ platform_driver_unregister(omap_rfbihw_driver);
}
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 9c3daf7..c933733 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -909,5 +909,5 @@ void venc_uninit_platform_driver(void)
if (cpu_is_omap44xx())
return;
- return platform_driver_unregister(omap_venchw_driver);
+ platform_driver_unregister(omap_venchw_driver);
}
--
1.7.4.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 08/21] OMAPDSS: clean up the omapdss platform data mess
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct omap_display_platform_data. It was used just as a
wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
dss hwmods do not need the platform data. This should also work better
for DT, as we can create omapdss device programmatically in generic omap
boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
that the dss hwmod drivers can call.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 37 ++---
drivers/video/omap2/dss/core.c | 35 +++
drivers/video/omap2/dss/dispc.c | 21 ++---
drivers/video/omap2/dss/dsi.c | 17 +++--
drivers/video/omap2/dss/dss.h |3 +++
drivers/video/omap2/dss/hdmi.c |2 --
include/video/omapdss.h |5 -
7 files changed, 61 insertions(+), 59 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 3677b1f..279c124 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -185,10 +185,23 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
struct omap_hwmod *oh;
struct platform_device *pdev;
int i, oh_count;
- struct omap_display_platform_data pdata;
const struct omap_dss_hwmod_data *curr_dss_hwmod;
- memset(pdata, 0, sizeof(pdata));
+ /* create omapdss device */
+
+ board_data-dsi_enable_pads = omap_dsi_enable_pads;
+ board_data-dsi_disable_pads = omap_dsi_disable_pads;
+ board_data-get_context_loss_count = omap_pm_get_dev_context_loss_count;
+
+ omap_display_device.dev.platform_data = board_data;
+
+ r = platform_device_register(omap_display_device);
+ if (r 0) {
+ pr_err(Unable to register omapdss device\n);
+ return r;
+ }
+
+ /* create devices for dss hwmods */
if (cpu_is_omap24xx()) {
curr_dss_hwmod = omap2_dss_hwmod_data;
@@ -201,15 +214,6 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
}
- if (board_data-dsi_enable_pads == NULL)
- board_data-dsi_enable_pads = omap_dsi_enable_pads;
- if (board_data-dsi_disable_pads == NULL)
- board_data-dsi_disable_pads = omap_dsi_disable_pads;
-
- pdata.board_data = board_data;
- pdata.board_data-get_context_loss_count =
- omap_pm_get_dev_context_loss_count;
-
for (i = 0; i oh_count; i++) {
oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
if (!oh) {
@@ -219,21 +223,16 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
}
pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
- curr_dss_hwmod[i].id, oh, pdata,
- sizeof(struct omap_display_platform_data),
+ curr_dss_hwmod[i].id, oh,
+ NULL, 0,
NULL, 0, 0);
if (WARN((IS_ERR(pdev)), Could not build omap_device for %s\n,
curr_dss_hwmod[i].oh_name))
return -ENODEV;
}
- omap_display_device.dev.platform_data = board_data;
- r = platform_device_register(omap_display_device);
- if (r 0)
- printk(KERN_ERR Unable to register OMAP-Display device\n);
-
- return r;
+ return 0;
}
static void dispc_disable_outputs(void)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 8613f86..3efd473 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -87,6 +87,41 @@ struct regulator *dss_get_vdds_sdi(void)
return reg;
}
+int dss_get_ctx_loss_count(struct device *dev)
+{
+ struct omap_dss_board_info *board_data = core.pdev-dev.platform_data;
+ int cnt;
+
+ if (!board_data || !board_data-get_context_loss_count)
+ return -ENOENT;
+
+ cnt = board_data-get_context_loss_count(dev);
+
+ WARN_ONCE(cnt 0, get_context_loss_count failed: %d\n, cnt);
+
+ return cnt;
+}
+
+int dss_dsi_enable_pads(int dsi_id, unsigned lane_mask)
+{
+ struct omap_dss_board_info *board_data = core.pdev-dev.platform_data;
+
+ if (!board_data || !board_data-dsi_enable_pads)
+ return -ENOENT;
+
+ return board_data-dsi_enable_pads(dsi_id, lane_mask);
+}
+
+void dss_dsi_disable_pads(int dsi_id, unsigned lane_mask)
+{
+ struct
[PATCH 10/21] OMAPDSS: use platform_driver_probe for core/dispc/dss
The platform devices for omapdss, dss and dispc drivers are always
present, so we can use platform_driver_probe instead of
platform_driver_register.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c |3 +--
drivers/video/omap2/dss/dispc.c |3 +--
drivers/video/omap2/dss/dss.c |3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 3efd473..80fbfd7 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -341,7 +341,6 @@ static int omap_dss_resume(struct platform_device *pdev)
}
static struct platform_driver omap_dss_driver = {
- .probe = omap_dss_probe,
.remove = omap_dss_remove,
.shutdown = omap_dss_shutdown,
.suspend= omap_dss_suspend,
@@ -576,7 +575,7 @@ static int __init omap_dss_init(void)
if (r)
return r;
- r = platform_driver_register(omap_dss_driver);
+ r = platform_driver_probe(omap_dss_driver, omap_dss_probe);
if (r) {
omap_dss_bus_unregister();
return r;
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 5985c3c..c71d4c5 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3431,7 +3431,6 @@ static const struct dev_pm_ops dispc_pm_ops = {
};
static struct platform_driver omap_dispchw_driver = {
- .probe = omap_dispchw_probe,
.remove = omap_dispchw_remove,
.driver = {
.name = omapdss_dispc,
@@ -3442,7 +3441,7 @@ static struct platform_driver omap_dispchw_driver = {
int dispc_init_platform_driver(void)
{
- return platform_driver_register(omap_dispchw_driver);
+ return platform_driver_probe(omap_dispchw_driver, omap_dispchw_probe);
}
void dispc_uninit_platform_driver(void)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 7d3facc..34cc84f 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -841,7 +841,6 @@ static const struct dev_pm_ops dss_pm_ops = {
};
static struct platform_driver omap_dsshw_driver = {
- .probe = omap_dsshw_probe,
.remove = omap_dsshw_remove,
.driver = {
.name = omapdss_dss,
@@ -852,7 +851,7 @@ static struct platform_driver omap_dsshw_driver = {
int dss_init_platform_driver(void)
{
- return platform_driver_register(omap_dsshw_driver);
+ return platform_driver_probe(omap_dsshw_driver, omap_dsshw_probe);
}
void dss_uninit_platform_driver(void)
--
1.7.4.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 11/21] OMAPDSS: register dss drivers in module init
We do the dss driver registration in a rather strange way: we have the
higher level omapdss driver, and we use that driver's probe function to
register the drivers for the rest of the dss devices.
There doesn't seem to be any reason for that, so this patch changes the
registration for all drivers to happen in the module init.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c | 135 +++-
1 files changed, 77 insertions(+), 58 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 80fbfd7..95d312c 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -218,42 +218,6 @@ static int omap_dss_probe(struct platform_device *pdev)
dss_init_overlay_managers(pdev);
dss_init_overlays(pdev);
- r = dss_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize DSS platform driver\n);
- goto err_dss;
- }
-
- r = dispc_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize dispc platform driver\n);
- goto err_dispc;
- }
-
- r = rfbi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize rfbi platform driver\n);
- goto err_rfbi;
- }
-
- r = venc_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize venc platform driver\n);
- goto err_venc;
- }
-
- r = dsi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize DSI platform driver\n);
- goto err_dsi;
- }
-
- r = hdmi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize hdmi\n);
- goto err_hdmi;
- }
-
r = dss_initialize_debugfs();
if (r)
goto err_debugfs;
@@ -281,18 +245,6 @@ static int omap_dss_probe(struct platform_device *pdev)
err_register:
dss_uninitialize_debugfs();
err_debugfs:
- hdmi_uninit_platform_driver();
-err_hdmi:
- dsi_uninit_platform_driver();
-err_dsi:
- venc_uninit_platform_driver();
-err_venc:
- dispc_uninit_platform_driver();
-err_dispc:
- rfbi_uninit_platform_driver();
-err_rfbi:
- dss_uninit_platform_driver();
-err_dss:
return r;
}
@@ -304,13 +256,6 @@ static int omap_dss_remove(struct platform_device *pdev)
dss_uninitialize_debugfs();
- hdmi_uninit_platform_driver();
- dsi_uninit_platform_driver();
- venc_uninit_platform_driver();
- rfbi_uninit_platform_driver();
- dispc_uninit_platform_driver();
- dss_uninit_platform_driver();
-
dss_uninit_overlays(pdev);
dss_uninit_overlay_managers(pdev);
@@ -559,6 +504,80 @@ static int omap_dss_bus_register(void)
/* INIT */
+static int __init omap_dss_register_drivers(void)
+{
+ int r;
+
+ r = platform_driver_probe(omap_dss_driver, omap_dss_probe);
+ if (r)
+ return r;
+
+ r = dss_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize DSS platform driver\n);
+ goto err_dss;
+ }
+
+ r = dispc_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize dispc platform driver\n);
+ goto err_dispc;
+ }
+
+ r = rfbi_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize rfbi platform driver\n);
+ goto err_rfbi;
+ }
+
+ r = venc_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize venc platform driver\n);
+ goto err_venc;
+ }
+
+ r = dsi_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize DSI platform driver\n);
+ goto err_dsi;
+ }
+
+ r = hdmi_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize hdmi\n);
+ goto err_hdmi;
+ }
+
+ return 0;
+
+err_hdmi:
+ dsi_uninit_platform_driver();
+err_dsi:
+ venc_uninit_platform_driver();
+err_venc:
+ rfbi_uninit_platform_driver();
+err_rfbi:
+ dispc_uninit_platform_driver();
+err_dispc:
+ dss_uninit_platform_driver();
+err_dss:
+ platform_driver_unregister(omap_dss_driver);
+
+ return r;
+}
+
+static void __exit omap_dss_unregister_drivers(void)
+{
+ hdmi_uninit_platform_driver();
+ dsi_uninit_platform_driver();
+ venc_uninit_platform_driver();
+ rfbi_uninit_platform_driver();
+ dispc_uninit_platform_driver();
+ dss_uninit_platform_driver();
+
+ platform_driver_unregister(omap_dss_driver);
+}
+
#ifdef CONFIG_OMAP2_DSS_MODULE
static void omap_dss_bus_unregister(void)
{
@@ -575,7 +594,7 @@ static int __init omap_dss_init(void)
if (r)
return r;
- r =
[PATCH 12/21] OMAPDSS: create custom pdevs for DSS omap_devices
Instead of using omap_device_build() to create the omap_devices for DSS
hwmods, create them with a custom function. This will allow us to create
a parent-child hierarchy for the devices so that the omapdss_core device
is parent for the rest of the dss hwmod devices.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 88 ++--
1 files changed, 74 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 279c124..3227eca 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -179,13 +179,71 @@ static void omap_dsi_disable_pads(int dsi_id, unsigned
lane_mask)
omap4_dsi_mux_pads(dsi_id, 0);
}
+static struct platform_device *create_dss_pdev(const char *pdev_name,
+ int pdev_id, const char *oh_name, void *pdata, int pdata_len,
+ struct platform_device *parent)
+{
+ struct platform_device *pdev;
+ struct omap_device *od;
+ struct omap_hwmod *ohs[1];
+ struct omap_hwmod *oh;
+ int r;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ r = -ENODEV;
+ goto err;
+ }
+
+ pdev = platform_device_alloc(pdev_name, pdev_id);
+ if (!pdev) {
+ pr_err(Could not create pdev for %s\n, pdev_name);
+ r = -ENOMEM;
+ goto err;
+ }
+
+ if (parent != NULL)
+ pdev-dev.parent = parent-dev;
+
+ if (pdev-id != -1)
+ dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
+ else
+ dev_set_name(pdev-dev, %s, pdev-name);
+
+ ohs[0] = oh;
+ od = omap_device_alloc(pdev, ohs, 1, NULL, 0);
+ if (!od) {
+ pr_err(Could not alloc omap_device for %s\n, pdev_name);
+ r = -ENOMEM;
+ goto err;
+ }
+
+ r = platform_device_add_data(pdev, pdata, pdata_len);
+ if (r) {
+ pr_err(Could not set pdata for %s\n, pdev_name);
+ goto err;
+ }
+
+ r = omap_device_register(pdev);
+ if (r) {
+ pr_err(Could not register omap_device for %s\n, pdev_name);
+ goto err;
+ }
+
+ return pdev;
+
+err:
+ return ERR_PTR(r);
+}
+
int __init omap_display_init(struct omap_dss_board_info *board_data)
{
int r = 0;
- struct omap_hwmod *oh;
struct platform_device *pdev;
int i, oh_count;
const struct omap_dss_hwmod_data *curr_dss_hwmod;
+ struct platform_device *dss_pdev;
/* create omapdss device */
@@ -214,22 +272,24 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
}
- for (i = 0; i oh_count; i++) {
- oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
- if (!oh) {
- pr_err(Could not look up %s\n,
- curr_dss_hwmod[i].oh_name);
- return -ENODEV;
- }
+ dss_pdev = NULL;
- pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
- curr_dss_hwmod[i].id, oh,
+ for (i = 0; i oh_count; i++) {
+ pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,
+ curr_dss_hwmod[i].id,
+ curr_dss_hwmod[i].oh_name,
NULL, 0,
- NULL, 0, 0);
+ dss_pdev);
+
+ if (IS_ERR(pdev)) {
+ pr_err(Could not build omap_device for %s\n,
+ curr_dss_hwmod[i].oh_name);
+
+ return PTR_ERR(pdev);
+ }
- if (WARN((IS_ERR(pdev)), Could not build omap_device for %s\n,
- curr_dss_hwmod[i].oh_name))
- return -ENODEV;
+ if (i == 0)
+ dss_pdev = pdev;
}
return 0;
--
1.7.4.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 13/21] OMAPDSS: create DPI SDI devices
We currently have separate device/driver for each DSS HW module. The DPI
and SDI outputs are more or less parts of the DSS or DISPC hardware
modules, but in SW it makes sense to represent them as device/driver
pairs similarly to all the other outputs. This also makes sense for
device tree, as each node under dss will be a platform device, and
handling DPI SDI somehow differently than the rest would just make the
code more complex.
This patch modifies arch/arm/mach-omap2/display.c to create platform
devices for DPI and SDI, and later patches will implement driver for
them.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 57 +
1 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 3227eca..f102d1f 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -237,6 +237,46 @@ err:
return ERR_PTR(r);
}
+static struct platform_device *create_simple_dss_pdev(const char *pdev_name,
+ int pdev_id, void *pdata, int pdata_len,
+ struct platform_device *parent)
+{
+ struct platform_device *pdev;
+ int r;
+
+ pdev = platform_device_alloc(pdev_name, pdev_id);
+ if (!pdev) {
+ pr_err(Could not create pdev for %s\n, pdev_name);
+ r = -ENOMEM;
+ goto err;
+ }
+
+ if (parent != NULL)
+ pdev-dev.parent = parent-dev;
+
+ if (pdev-id != -1)
+ dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
+ else
+ dev_set_name(pdev-dev, %s, pdev-name);
+
+ r = platform_device_add_data(pdev, pdata, pdata_len);
+ if (r) {
+ pr_err(Could not set pdata for %s\n, pdev_name);
+ goto err;
+ }
+
+ r = omap_device_register(pdev);
+ if (r) {
+ pr_err(Could not register omap_device for %s\n, pdev_name);
+ goto err;
+ }
+
+ return pdev;
+
+err:
+ return ERR_PTR(r);
+}
+
int __init omap_display_init(struct omap_dss_board_info *board_data)
{
int r = 0;
@@ -292,6 +332,23 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
dss_pdev = pdev;
}
+ /* Create devices for DPI and SDI */
+
+ pdev = create_simple_dss_pdev(omapdss_dpi, -1, NULL, 0, dss_pdev);
+ if (IS_ERR(pdev)) {
+ pr_err(Could not build platform_device for omapdss_dpi\n);
+ return PTR_ERR(pdev);
+ }
+
+ if (cpu_is_omap34xx()) {
+ pdev = create_simple_dss_pdev(omapdss_sdi, -1, NULL, 0,
+ dss_pdev);
+ if (IS_ERR(pdev)) {
+ pr_err(Could not build platform_device for
omapdss_sdi\n);
+ return PTR_ERR(pdev);
+ }
+ }
+
return 0;
}
--
1.7.4.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 14/21] OMAPDSS: create DPI SDI drivers
We currently have separate device/driver for each DSS HW module. The DPI
and SDI outputs are more or less parts of the DSS or DISPC hardware
modules, but in SW it makes sense to represent them as device/driver
pairs similarly to all the other outputs. This also makes sense for
device tree, as each node under dss will be a platform device, and
handling DPI SDI somehow differently than the rest would just make the
code more complex.
This patch modifies the dpi.c and sdi.c to create drivers for the
platform devices.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c | 18 ++
drivers/video/omap2/dss/dpi.c | 23 +--
drivers/video/omap2/dss/dss.c | 20 +---
drivers/video/omap2/dss/dss.h | 26 --
drivers/video/omap2/dss/sdi.c | 25 +++--
5 files changed, 71 insertions(+), 41 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 95d312c..654962a 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -524,6 +524,18 @@ static int __init omap_dss_register_drivers(void)
goto err_dispc;
}
+ r = dpi_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize dpi platform driver\n);
+ goto err_dpi;
+ }
+
+ r = sdi_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize sdi platform driver\n);
+ goto err_sdi;
+ }
+
r = rfbi_init_platform_driver();
if (r) {
DSSERR(Failed to initialize rfbi platform driver\n);
@@ -557,6 +569,10 @@ err_dsi:
err_venc:
rfbi_uninit_platform_driver();
err_rfbi:
+ sdi_uninit_platform_driver();
+err_sdi:
+ dpi_uninit_platform_driver();
+err_dpi:
dispc_uninit_platform_driver();
err_dispc:
dss_uninit_platform_driver();
@@ -572,6 +588,8 @@ static void __exit omap_dss_unregister_drivers(void)
dsi_uninit_platform_driver();
venc_uninit_platform_driver();
rfbi_uninit_platform_driver();
+ sdi_uninit_platform_driver();
+ dpi_uninit_platform_driver();
dispc_uninit_platform_driver();
dss_uninit_platform_driver();
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index faaf305..5b7bbab 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -378,12 +378,31 @@ int dpi_init_display(struct omap_dss_device *dssdev)
return 0;
}
-int dpi_init(void)
+static int omap_dpi_probe(struct platform_device *pdev)
{
return 0;
}
-void dpi_exit(void)
+static int omap_dpi_remove(struct platform_device *pdev)
{
+ return 0;
}
+static struct platform_driver omap_dpi_driver = {
+ .probe = omap_dpi_probe,
+ .remove = omap_dpi_remove,
+ .driver = {
+ .name = omapdss_dpi,
+ .owner = THIS_MODULE,
+ },
+};
+
+int dpi_init_platform_driver(void)
+{
+ return platform_driver_register(omap_dpi_driver);
+}
+
+void dpi_uninit_platform_driver(void)
+{
+ platform_driver_unregister(omap_dpi_driver);
+}
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 34cc84f..3156851 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -782,18 +782,6 @@ static int omap_dsshw_probe(struct platform_device *pdev)
dss.lcd_clk_source[0] = OMAP_DSS_CLK_SRC_FCK;
dss.lcd_clk_source[1] = OMAP_DSS_CLK_SRC_FCK;
- r = dpi_init();
- if (r) {
- DSSERR(Failed to initialize DPI\n);
- goto err_dpi;
- }
-
- r = sdi_init();
- if (r) {
- DSSERR(Failed to initialize SDI\n);
- goto err_sdi;
- }
-
rev = dss_read_reg(DSS_REVISION);
printk(KERN_INFO OMAP DSS rev %d.%d\n,
FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
@@ -801,10 +789,7 @@ static int omap_dsshw_probe(struct platform_device *pdev)
dss_runtime_put();
return 0;
-err_sdi:
- dpi_exit();
-err_dpi:
- dss_runtime_put();
+
err_runtime_get:
pm_runtime_disable(pdev-dev);
dss_put_clocks();
@@ -813,9 +798,6 @@ err_runtime_get:
static int omap_dsshw_remove(struct platform_device *pdev)
{
- dpi_exit();
- sdi_exit();
-
pm_runtime_disable(pdev-dev);
dss_put_clocks();
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index d37ed80..1981626 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -269,17 +269,12 @@ int dss_calc_clock_div(bool is_tft, unsigned long req_pck,
/* SDI */
#ifdef CONFIG_OMAP2_DSS_SDI
-int sdi_init(void);
-void sdi_exit(void);
+int sdi_init_platform_driver(void);
+void sdi_uninit_platform_driver(void);
int sdi_init_display(struct
[PATCH 15/21] OMAPDSS: remove uses of dss_runtime_get/put
Now that the omapdss_core device is the parent for all other dss
devices, we don't need to use the dss_runtime_get/put anymore. Instead,
enabling omapdss_core will happen automatically when a child device is
enabled.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c |7 ---
drivers/video/omap2/dss/dpi.c | 16 +---
drivers/video/omap2/dss/dsi.c | 12 +---
drivers/video/omap2/dss/dss.c |7 +--
drivers/video/omap2/dss/dss.h |3 ---
drivers/video/omap2/dss/hdmi.c | 34 ++
drivers/video/omap2/dss/rfbi.c | 12 +---
drivers/video/omap2/dss/sdi.c |7 ---
drivers/video/omap2/dss/venc.c | 12 +---
9 files changed, 11 insertions(+), 99 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index c71d4c5..1fbe480 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3407,19 +3407,12 @@ static int omap_dispchw_remove(struct platform_device
*pdev)
static int dispc_runtime_suspend(struct device *dev)
{
dispc_save_context();
- dss_runtime_put();
return 0;
}
static int dispc_runtime_resume(struct device *dev)
{
- int r;
-
- r = dss_runtime_get();
- if (r 0)
- return r;
-
dispc_restore_context();
return 0;
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 5b7bbab..511df3c 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -202,10 +202,6 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
goto err_reg_enable;
}
- r = dss_runtime_get();
- if (r)
- goto err_get_dss;
-
r = dispc_runtime_get();
if (r)
goto err_get_dispc;
@@ -244,8 +240,6 @@ err_dsi_pll_init:
err_get_dsi:
dispc_runtime_put();
err_get_dispc:
- dss_runtime_put();
-err_get_dss:
if (cpu_is_omap34xx())
regulator_disable(dpi.vdds_dsi_reg);
err_reg_enable:
@@ -266,7 +260,6 @@ void omapdss_dpi_display_disable(struct omap_dss_device
*dssdev)
}
dispc_runtime_put();
- dss_runtime_put();
if (cpu_is_omap34xx())
regulator_disable(dpi.vdds_dsi_reg);
@@ -283,21 +276,14 @@ void dpi_set_timings(struct omap_dss_device *dssdev,
DSSDBG(dpi_set_timings\n);
dssdev-panel.timings = *timings;
if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE) {
- r = dss_runtime_get();
- if (r)
- return;
-
r = dispc_runtime_get();
- if (r) {
- dss_runtime_put();
+ if (r)
return;
- }
dpi_set_mode(dssdev);
dispc_mgr_go(dssdev-manager-id);
dispc_runtime_put();
- dss_runtime_put();
}
}
EXPORT_SYMBOL(dpi_set_timings);
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index cf59f40..4bee235 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4802,7 +4802,6 @@ static int omap_dsihw_remove(struct platform_device
*dsidev)
static int dsi_runtime_suspend(struct device *dev)
{
dispc_runtime_put();
- dss_runtime_put();
return 0;
}
@@ -4811,20 +4810,11 @@ static int dsi_runtime_resume(struct device *dev)
{
int r;
- r = dss_runtime_get();
- if (r)
- goto err_get_dss;
-
r = dispc_runtime_get();
if (r)
- goto err_get_dispc;
+ return r;
return 0;
-
-err_get_dispc:
- dss_runtime_put();
-err_get_dss:
- return r;
}
static const struct dev_pm_ops dsi_pm_ops = {
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 3156851..da528b7 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -59,6 +59,9 @@ struct dss_reg {
#define REG_FLD_MOD(idx, val, start, end) \
dss_write_reg(idx, FLD_MOD(dss_read_reg(idx), val, start, end))
+static int dss_runtime_get(void);
+static void dss_runtime_put(void);
+
static struct {
struct platform_device *pdev;
void __iomem*base;
@@ -703,7 +706,7 @@ static void dss_put_clocks(void)
clk_put(dss.dss_clk);
}
-int dss_runtime_get(void)
+static int dss_runtime_get(void)
{
int r;
@@ -714,7 +717,7 @@ int dss_runtime_get(void)
return r 0 ? r : 0;
}
-void dss_runtime_put(void)
+static void dss_runtime_put(void)
{
int r;
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 1981626..24aadde 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -230,9 +230,6 @@ int dss_ovl_check(struct omap_overlay *ovl,
int
[PATCH 16/21] OMAPDSS: handle output-driver reg/unreg more dynamically
Initialize and uninitialize the output drivers by using arrays of
pointers to the init/uninit functions. This simplifies the code
slightly.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c | 111 +---
drivers/video/omap2/dss/dss.h | 41 ---
2 files changed, 59 insertions(+), 93 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 654962a..ac4f2cb 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -503,10 +503,54 @@ static int omap_dss_bus_register(void)
}
/* INIT */
+static int (*dss_output_drv_reg_funcs[])(void) __initdata = {
+#ifdef CONFIG_OMAP2_DSS_DPI
+ dpi_init_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_SDI
+ sdi_init_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_RFBI
+ rfbi_init_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_VENC
+ venc_init_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_DSI
+ dsi_init_platform_driver,
+#endif
+#ifdef CONFIG_OMAP4_DSS_HDMI
+ hdmi_init_platform_driver,
+#endif
+};
+
+static void (*dss_output_drv_unreg_funcs[])(void) __exitdata = {
+#ifdef CONFIG_OMAP2_DSS_DPI
+ dpi_uninit_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_SDI
+ sdi_uninit_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_RFBI
+ rfbi_uninit_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_VENC
+ venc_uninit_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_DSI
+ dsi_uninit_platform_driver,
+#endif
+#ifdef CONFIG_OMAP4_DSS_HDMI
+ hdmi_uninit_platform_driver,
+#endif
+};
+
+static bool dss_output_drv_loaded[ARRAY_SIZE(dss_output_drv_reg_funcs)];
static int __init omap_dss_register_drivers(void)
{
int r;
+ int i;
r = platform_driver_probe(omap_dss_driver, omap_dss_probe);
if (r)
@@ -524,56 +568,18 @@ static int __init omap_dss_register_drivers(void)
goto err_dispc;
}
- r = dpi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize dpi platform driver\n);
- goto err_dpi;
- }
-
- r = sdi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize sdi platform driver\n);
- goto err_sdi;
- }
-
- r = rfbi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize rfbi platform driver\n);
- goto err_rfbi;
- }
-
- r = venc_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize venc platform driver\n);
- goto err_venc;
- }
-
- r = dsi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize DSI platform driver\n);
- goto err_dsi;
- }
-
- r = hdmi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize hdmi\n);
- goto err_hdmi;
+ /*
+* It's ok if the output-driver register fails. It happens, for example,
+* when there is no output-device (e.g. SDI for OMAP4).
+*/
+ for (i = 0; i ARRAY_SIZE(dss_output_drv_reg_funcs); ++i) {
+ r = dss_output_drv_reg_funcs[i]();
+ if (r == 0)
+ dss_output_drv_loaded[i] = true;
}
return 0;
-err_hdmi:
- dsi_uninit_platform_driver();
-err_dsi:
- venc_uninit_platform_driver();
-err_venc:
- rfbi_uninit_platform_driver();
-err_rfbi:
- sdi_uninit_platform_driver();
-err_sdi:
- dpi_uninit_platform_driver();
-err_dpi:
- dispc_uninit_platform_driver();
err_dispc:
dss_uninit_platform_driver();
err_dss:
@@ -584,12 +590,13 @@ err_dss:
static void __exit omap_dss_unregister_drivers(void)
{
- hdmi_uninit_platform_driver();
- dsi_uninit_platform_driver();
- venc_uninit_platform_driver();
- rfbi_uninit_platform_driver();
- sdi_uninit_platform_driver();
- dpi_uninit_platform_driver();
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(dss_output_drv_unreg_funcs); ++i) {
+ if (dss_output_drv_loaded[i])
+ dss_output_drv_unreg_funcs[i]();
+ }
+
dispc_uninit_platform_driver();
dss_uninit_platform_driver();
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 24aadde..af7bed1 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -265,14 +265,9 @@ int dss_calc_clock_div(bool is_tft, unsigned long req_pck,
struct dispc_clock_info *dispc_cinfo);
/* SDI */
-#ifdef CONFIG_OMAP2_DSS_SDI
int sdi_init_platform_driver(void);
void sdi_uninit_platform_driver(void);
int sdi_init_display(struct omap_dss_device *display);
-#else
-static inline int sdi_init_platform_driver(void) { return 0; }
-static inline void sdi_uninit_platform_driver(void) { }
-#endif
/*
[PATCH 17/21] OMAPDSS: move the creation of debugfs files
Instead of having an ugly #ifdef mess in the core.c for creating debugfs
files, add a dss_debugfs_create_file() function that the dss drivers
can use to create the debugfs files.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c | 46 +++---
drivers/video/omap2/dss/dispc.c |7 +-
drivers/video/omap2/dss/dsi.c | 42 +--
drivers/video/omap2/dss/dss.c |4 ++-
drivers/video/omap2/dss/dss.h | 11 +
drivers/video/omap2/dss/hdmi.c |4 ++-
drivers/video/omap2/dss/rfbi.c |4 ++-
drivers/video/omap2/dss/venc.c |4 ++-
8 files changed, 48 insertions(+), 74 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index ac4f2cb..a744474 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -156,34 +156,6 @@ static int dss_initialize_debugfs(void)
debugfs_create_file(clk, S_IRUGO, dss_debugfs_dir,
dss_debug_dump_clocks, dss_debug_fops);
-#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
- debugfs_create_file(dispc_irq, S_IRUGO, dss_debugfs_dir,
- dispc_dump_irqs, dss_debug_fops);
-#endif
-
-#if defined(CONFIG_OMAP2_DSS_DSI)
defined(CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS)
- dsi_create_debugfs_files_irq(dss_debugfs_dir, dss_debug_fops);
-#endif
-
- debugfs_create_file(dss, S_IRUGO, dss_debugfs_dir,
- dss_dump_regs, dss_debug_fops);
- debugfs_create_file(dispc, S_IRUGO, dss_debugfs_dir,
- dispc_dump_regs, dss_debug_fops);
-#ifdef CONFIG_OMAP2_DSS_RFBI
- debugfs_create_file(rfbi, S_IRUGO, dss_debugfs_dir,
- rfbi_dump_regs, dss_debug_fops);
-#endif
-#ifdef CONFIG_OMAP2_DSS_DSI
- dsi_create_debugfs_files_reg(dss_debugfs_dir, dss_debug_fops);
-#endif
-#ifdef CONFIG_OMAP2_DSS_VENC
- debugfs_create_file(venc, S_IRUGO, dss_debugfs_dir,
- venc_dump_regs, dss_debug_fops);
-#endif
-#ifdef CONFIG_OMAP4_DSS_HDMI
- debugfs_create_file(hdmi, S_IRUGO, dss_debugfs_dir,
- hdmi_dump_regs, dss_debug_fops);
-#endif
return 0;
}
@@ -192,6 +164,19 @@ static void dss_uninitialize_debugfs(void)
if (dss_debugfs_dir)
debugfs_remove_recursive(dss_debugfs_dir);
}
+
+int dss_debugfs_create_file(const char *name, void (*write)(struct seq_file *))
+{
+ struct dentry *d;
+
+ d = debugfs_create_file(name, S_IRUGO, dss_debugfs_dir,
+ write, dss_debug_fops);
+
+ if (IS_ERR(d))
+ return PTR_ERR(d);
+
+ return 0;
+}
#else /* CONFIG_DEBUG_FS CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
static inline int dss_initialize_debugfs(void)
{
@@ -200,6 +185,11 @@ static inline int dss_initialize_debugfs(void)
static inline void dss_uninitialize_debugfs(void)
{
}
+static inline int dss_debugfs_create_file(const char *name,
+ void (*write)(struct seq_file *))
+{
+ return 0;
+}
#endif /* CONFIG_DEBUG_FS CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
/* PLATFORM DEVICE */
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 1fbe480..a555e32 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2571,7 +2571,7 @@ void dispc_dump_irqs(struct seq_file *s)
}
#endif
-void dispc_dump_regs(struct seq_file *s)
+static void dispc_dump_regs(struct seq_file *s)
{
int i, j;
const char *mgr_names[] = {
@@ -3387,6 +3387,11 @@ static int omap_dispchw_probe(struct platform_device
*pdev)
dispc_runtime_put();
+ dss_debugfs_create_file(dispc, dispc_dump_regs);
+
+#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
+ dss_debugfs_create_file(dispc_irq, dispc_dump_irqs);
+#endif
return 0;
err_runtime_get:
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 4bee235..0a1c5e3 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1883,22 +1883,6 @@ static void dsi2_dump_irqs(struct seq_file *s)
dsi_dump_dsidev_irqs(dsidev, s);
}
-
-void dsi_create_debugfs_files_irq(struct dentry *debugfs_dir,
- const struct file_operations *debug_fops)
-{
- struct platform_device *dsidev;
-
- dsidev = dsi_get_dsidev_from_id(0);
- if (dsidev)
- debugfs_create_file(dsi1_irqs, S_IRUGO, debugfs_dir,
- dsi1_dump_irqs, debug_fops);
-
- dsidev = dsi_get_dsidev_from_id(1);
- if (dsidev)
- debugfs_create_file(dsi2_irqs, S_IRUGO, debugfs_dir,
- dsi2_dump_irqs, debug_fops);
-}
#endif
static void dsi_dump_dsidev_regs(struct platform_device *dsidev,
@@ -1999,21 +1983,6 @@ static void dsi2_dump_regs(struct seq_file *s)
dsi_dump_dsidev_regs(dsidev, s);
}
-void dsi_create_debugfs_files_reg(struct dentry
[PATCH 18/21] OMAPDSS: use platform_driver_probe for dsi/hdmi/rfbi/venc/dpi/sdi
Now that the core.c doesn't fail if output driver's init fails, we can
change the uses of platform_driver_register to platform_driver_probe.
This will allow us to use __init in the following patches.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c |3 +--
drivers/video/omap2/dss/dsi.c |3 +--
drivers/video/omap2/dss/hdmi.c |3 +--
drivers/video/omap2/dss/rfbi.c |3 +--
drivers/video/omap2/dss/sdi.c |3 +--
drivers/video/omap2/dss/venc.c |3 +--
6 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 511df3c..5ca216b 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -375,7 +375,6 @@ static int omap_dpi_remove(struct platform_device *pdev)
}
static struct platform_driver omap_dpi_driver = {
- .probe = omap_dpi_probe,
.remove = omap_dpi_remove,
.driver = {
.name = omapdss_dpi,
@@ -385,7 +384,7 @@ static struct platform_driver omap_dpi_driver = {
int dpi_init_platform_driver(void)
{
- return platform_driver_register(omap_dpi_driver);
+ return platform_driver_probe(omap_dpi_driver, omap_dpi_probe);
}
void dpi_uninit_platform_driver(void)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 0a1c5e3..9402d00 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4803,7 +4803,6 @@ static const struct dev_pm_ops dsi_pm_ops = {
};
static struct platform_driver omap_dsihw_driver = {
- .probe = omap_dsihw_probe,
.remove = omap_dsihw_remove,
.driver = {
.name = omapdss_dsi,
@@ -4814,7 +4813,7 @@ static struct platform_driver omap_dsihw_driver = {
int dsi_init_platform_driver(void)
{
- return platform_driver_register(omap_dsihw_driver);
+ return platform_driver_probe(omap_dsihw_driver, omap_dsihw_probe);
}
void dsi_uninit_platform_driver(void)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 10295fc..2f369ed 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -871,7 +871,6 @@ static const struct dev_pm_ops hdmi_pm_ops = {
};
static struct platform_driver omapdss_hdmihw_driver = {
- .probe = omapdss_hdmihw_probe,
.remove = omapdss_hdmihw_remove,
.driver = {
.name = omapdss_hdmi,
@@ -882,7 +881,7 @@ static struct platform_driver omapdss_hdmihw_driver = {
int hdmi_init_platform_driver(void)
{
- return platform_driver_register(omapdss_hdmihw_driver);
+ return platform_driver_probe(omapdss_hdmihw_driver,
omapdss_hdmihw_probe);
}
void hdmi_uninit_platform_driver(void)
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index b07010b..b2b0d5e 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -995,7 +995,6 @@ static const struct dev_pm_ops rfbi_pm_ops = {
};
static struct platform_driver omap_rfbihw_driver = {
- .probe = omap_rfbihw_probe,
.remove = omap_rfbihw_remove,
.driver = {
.name = omapdss_rfbi,
@@ -1006,7 +1005,7 @@ static struct platform_driver omap_rfbihw_driver = {
int rfbi_init_platform_driver(void)
{
- return platform_driver_register(omap_rfbihw_driver);
+ return platform_driver_probe(omap_rfbihw_driver, omap_rfbihw_probe);
}
void rfbi_uninit_platform_driver(void)
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 684a4de..2cbcc00 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -187,7 +187,6 @@ static int omap_sdi_remove(struct platform_device *pdev)
}
static struct platform_driver omap_sdi_driver = {
- .probe = omap_sdi_probe,
.remove = omap_sdi_remove,
.driver = {
.name = omapdss_sdi,
@@ -197,7 +196,7 @@ static struct platform_driver omap_sdi_driver = {
int sdi_init_platform_driver(void)
{
- return platform_driver_register(omap_sdi_driver);
+ return platform_driver_probe(omap_sdi_driver, omap_sdi_probe);
}
void sdi_uninit_platform_driver(void)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index a9c7c7c..ca0bcdd 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -879,7 +879,6 @@ static const struct dev_pm_ops venc_pm_ops = {
};
static struct platform_driver omap_venchw_driver = {
- .probe = omap_venchw_probe,
.remove = omap_venchw_remove,
.driver = {
.name = omapdss_venc,
@@ -893,7 +892,7 @@ int venc_init_platform_driver(void)
if (cpu_is_omap44xx())
return 0;
- return
[PATCH 19/21] OMAPDSS: add __init __exit
Now that we are using platform_driver_probe() we can add __inits and
__exits all around.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c |4 ++--
drivers/video/omap2/dss/dispc.c | 10 +-
drivers/video/omap2/dss/dpi.c | 10 +-
drivers/video/omap2/dss/dsi.c | 10 +-
drivers/video/omap2/dss/dss.c | 10 +-
drivers/video/omap2/dss/hdmi.c | 10 +-
drivers/video/omap2/dss/rfbi.c | 10 +-
drivers/video/omap2/dss/sdi.c | 10 +-
drivers/video/omap2/dss/venc.c | 10 +-
9 files changed, 42 insertions(+), 42 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index a744474..aa294d7 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -193,7 +193,7 @@ static inline int dss_debugfs_create_file(const char *name,
#endif /* CONFIG_DEBUG_FS CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
/* PLATFORM DEVICE */
-static int omap_dss_probe(struct platform_device *pdev)
+static int __init omap_dss_probe(struct platform_device *pdev)
{
struct omap_dss_board_info *pdata = pdev-dev.platform_data;
int r;
@@ -471,7 +471,7 @@ static void omap_dss_unregister_device(struct
omap_dss_device *dssdev)
}
/* BUS */
-static int omap_dss_bus_register(void)
+static int __init omap_dss_bus_register(void)
{
int r;
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index a555e32..71272a6 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3318,7 +3318,7 @@ static void _omap_dispc_initial_config(void)
}
/* DISPC HW IP initialisation */
-static int omap_dispchw_probe(struct platform_device *pdev)
+static int __init omap_dispchw_probe(struct platform_device *pdev)
{
u32 rev;
int r = 0;
@@ -3400,7 +3400,7 @@ err_runtime_get:
return r;
}
-static int omap_dispchw_remove(struct platform_device *pdev)
+static int __exit omap_dispchw_remove(struct platform_device *pdev)
{
pm_runtime_disable(pdev-dev);
@@ -3429,7 +3429,7 @@ static const struct dev_pm_ops dispc_pm_ops = {
};
static struct platform_driver omap_dispchw_driver = {
- .remove = omap_dispchw_remove,
+ .remove = __exit_p(omap_dispchw_remove),
.driver = {
.name = omapdss_dispc,
.owner = THIS_MODULE,
@@ -3437,12 +3437,12 @@ static struct platform_driver omap_dispchw_driver = {
},
};
-int dispc_init_platform_driver(void)
+__init int dispc_init_platform_driver(void)
{
return platform_driver_probe(omap_dispchw_driver, omap_dispchw_probe);
}
-void dispc_uninit_platform_driver(void)
+__exit void dispc_uninit_platform_driver(void)
{
platform_driver_unregister(omap_dispchw_driver);
}
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 5ca216b..f93c3ad 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -364,30 +364,30 @@ int dpi_init_display(struct omap_dss_device *dssdev)
return 0;
}
-static int omap_dpi_probe(struct platform_device *pdev)
+static int __init omap_dpi_probe(struct platform_device *pdev)
{
return 0;
}
-static int omap_dpi_remove(struct platform_device *pdev)
+static int __exit omap_dpi_remove(struct platform_device *pdev)
{
return 0;
}
static struct platform_driver omap_dpi_driver = {
- .remove = omap_dpi_remove,
+ .remove = __exit_p(omap_dpi_remove),
.driver = {
.name = omapdss_dpi,
.owner = THIS_MODULE,
},
};
-int dpi_init_platform_driver(void)
+__init int dpi_init_platform_driver(void)
{
return platform_driver_probe(omap_dpi_driver, omap_dpi_probe);
}
-void dpi_uninit_platform_driver(void)
+__exit void dpi_uninit_platform_driver(void)
{
platform_driver_unregister(omap_dpi_driver);
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 9402d00..d510d0e 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4643,7 +4643,7 @@ static void dsi_put_clocks(struct platform_device *dsidev)
}
/* DSI1 HW IP initialisation */
-static int omap_dsihw_probe(struct platform_device *dsidev)
+static int __init omap_dsihw_probe(struct platform_device *dsidev)
{
u32 rev;
int r, i, dsi_module = dsi_get_dsidev_id(dsidev);
@@ -4756,7 +4756,7 @@ err_runtime_get:
return r;
}
-static int omap_dsihw_remove(struct platform_device *dsidev)
+static int __exit omap_dsihw_remove(struct platform_device *dsidev)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
@@ -4803,7 +4803,7 @@ static const struct dev_pm_ops dsi_pm_ops = {
};
static struct platform_driver omap_dsihw_driver = {
- .remove = omap_dsihw_remove,
+ .remove =
[PATCH 20/21] OMAPFB: add __init __exit
Change omapfb to use platform_driver_probe and add __init __exit.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index b00db40..a0967dc 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2307,7 +2307,7 @@ static int omapfb_init_display(struct omapfb2_device
*fbdev,
return 0;
}
-static int omapfb_probe(struct platform_device *pdev)
+static int __init omapfb_probe(struct platform_device *pdev)
{
struct omapfb2_device *fbdev = NULL;
int r = 0;
@@ -2448,7 +2448,7 @@ err0:
return r;
}
-static int omapfb_remove(struct platform_device *pdev)
+static int __exit omapfb_remove(struct platform_device *pdev)
{
struct omapfb2_device *fbdev = platform_get_drvdata(pdev);
@@ -2462,8 +2462,7 @@ static int omapfb_remove(struct platform_device *pdev)
}
static struct platform_driver omapfb_driver = {
- .probe = omapfb_probe,
- .remove = omapfb_remove,
+ .remove = __exit_p(omapfb_remove),
.driver = {
.name = omapfb,
.owner = THIS_MODULE,
@@ -2474,7 +2473,7 @@ static int __init omapfb_init(void)
{
DBG(omapfb_init\n);
- if (platform_driver_register(omapfb_driver)) {
+ if (platform_driver_probe(omapfb_driver, omapfb_probe)) {
printk(KERN_ERR failed to register omapfb driver\n);
return -ENODEV;
}
--
1.7.4.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 21/21] OMAPDSS: change default_device handling
We currently have a two ways to set a default panel device for dss, to
which the overlays are connected when the omapdss driver is loaded:
- in textual format (name of the display) as cmdline parameter
- as a pointer to the panel device from board file via pdata
The current code handles this in a bit too complex way by using both of
the above methods during runtime. However, with DT we don't have pdata
anymore, so the code handling the second case won't work anymore. The
current code has also the problem that it modifies the platform_data.
This patch simplifies the code a bit by using the pointer method only
inside the probe function, and stores the name of the panel device. This
way we only need to handle the textual format during operation and also
avoid modifying the platform_data.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index aa294d7..dd8f07c 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -43,6 +43,8 @@ static struct {
struct regulator *vdds_dsi_reg;
struct regulator *vdds_sdi_reg;
+
+ const char *default_display_name;
} core;
static char *def_disp_name;
@@ -212,6 +214,11 @@ static int __init omap_dss_probe(struct platform_device
*pdev)
if (r)
goto err_debugfs;
+ if (def_disp_name)
+ core.default_display_name = def_disp_name;
+ else if (pdata-default_device)
+ core.default_display_name = pdata-default_device-name;
+
for (i = 0; i pdata-num_devices; ++i) {
struct omap_dss_device *dssdev = pdata-devices[i];
@@ -225,9 +232,6 @@ static int __init omap_dss_probe(struct platform_device
*pdev)
goto err_register;
}
-
- if (def_disp_name strcmp(def_disp_name, dssdev-name) == 0)
- pdata-default_device = dssdev;
}
return 0;
@@ -350,7 +354,6 @@ static int dss_driver_probe(struct device *dev)
int r;
struct omap_dss_driver *dssdrv = to_dss_driver(dev-driver);
struct omap_dss_device *dssdev = to_dss_device(dev);
- struct omap_dss_board_info *pdata = core.pdev-dev.platform_data;
bool force;
DSSDBG(driver_probe: dev %s/%s, drv %s\n,
@@ -359,7 +362,8 @@ static int dss_driver_probe(struct device *dev)
dss_init_device(core.pdev, dssdev);
- force = pdata-default_device == dssdev;
+ force = core.default_display_name
+ strcmp(core.default_display_name, dssdev-name) == 0;
dss_recheck_connections(dssdev, force);
r = dssdrv-probe(dssdev);
--
1.7.4.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 08/12] gpio/twl: Allocate irq_desc dynamically for SPARSE_IRQ support
Hi Grant,
That fix is tightly coupled with the previous twl4030-irq change, so it
will be good to pulled it with the twl series through MFD if you are OK
with that?
Care to ack this one and the next one?
Thanks,
Benoit
On 3/2/2012 5:50 PM, Benoit Cousson wrote:
Do not use the board pdata for irq_base, but allocate them dynamically
to allow a proper support of SPARSE_IRQ.
Fix an unneeded line wrap.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Acked-by: Felipe Balbiba...@ti.com
---
drivers/gpio/gpio-twl4030.c | 33 +
1 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 697396c..49e5c6e 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -395,23 +395,26 @@ static int gpio_twl4030_remove(struct platform_device
*pdev);
static int __devinit gpio_twl4030_probe(struct platform_device *pdev)
{
struct twl4030_gpio_platform_data *pdata = pdev-dev.platform_data;
- int ret;
+ int ret, irq_base;
/* maybe setup IRQs */
- if (pdata-irq_base) {
- if (is_module()) {
- dev_err(pdev-dev,
- can't dispatch IRQs from modules\n);
- goto no_irqs;
- }
- ret = twl4030_sih_setup(pdev-dev, TWL4030_MODULE_GPIO,
- pdata-irq_base);
- if (ret 0)
- return ret;
- WARN_ON(ret != pdata-irq_base);
- twl4030_gpio_irq_base = ret;
+ if (is_module()) {
+ dev_err(pdev-dev, can't dispatch IRQs from modules\n);
+ goto no_irqs;
+ }
+
+ irq_base = irq_alloc_descs(-1, 0, TWL4030_GPIO_MAX, 0);
+ if (irq_base 0) {
+ dev_err(pdev-dev, Failed to alloc irq_descs\n);
+ return irq_base;
}
+ ret = twl4030_sih_setup(pdev-dev, TWL4030_MODULE_GPIO, irq_base);
+ if (ret 0)
+ return ret;
+
+ twl4030_gpio_irq_base = irq_base;
+
no_irqs:
/*
* NOTE: boards may waste power if they don't set pullups
@@ -443,9 +446,7 @@ no_irqs:
ret = gpiochip_add(twl_gpiochip);
if (ret 0) {
- dev_err(pdev-dev,
- could not register gpiochip, %d\n,
- ret);
+ dev_err(pdev-dev, could not register gpiochip, %d\n, ret);
twl_gpiochip.ngpio = 0;
gpio_twl4030_remove(pdev);
} else if (pdata-setup) {
--
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] omap2+: add drm device
On Wed, Mar 7, 2012 at 5:59 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-03-06 at 09:29 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
Can there be more than one omapdrm device? I guess not. If so, the id
should be -1.
in the past, we have used multiple devices (using the platform-data to
divide up the dss resources), although this was sort of a
special-case. But in theory you could have multiple. (Think of a
multi-seat scenario, where multiple compositors need to run and each
need to be drm-master of their own device to do mode-setting on their
corresponding display.)
I think if we use .id = -1, then we'd end up with a funny looking
bus-id for the device: platform:omapdrm:-1
I don't know about that, but it's the way platform devices are meant to
be used if there can be only one instance. If the case where there are
multiple omapdrm devices is rather theoretical, or only used for certain
debugging scenarios or such, I think having the id as -1 in the mainline
is cleaner.
well, I don't care much one way or another, but need to check if there
is a small patch needed in drm core code that generates the bus-id for
.id = -1..
Hmm, why does the drm core care about it?
Because it is the one generating the bus-id.. see
drivers/gpu/drm/drm_platform.c drm_platform_set_busid()
Anyways, it's just a detail about how libdrm/drmOpen() can
differentiate between multiple instances of the same driver, similar
to how PCI bus-id is used in the desktop world. It is not difficult
to change in drm_platform_set_busid(), although not sure if that would
be considered an ABI change to userspace. (Maybe it is less critical,
I'm under the impression that other platform-drm users didn't even
realize we had a bus-id.)
And generally, I think if the bus id is -1, there is no bus id in a
sense. For example, with bus id 0 you'll get a device omapdrm.0. With
bus id -1 you'll get a device omapdrm.
+arch_initcall(omap_init_gpu);
+
+void omapdrm_reserve_vram(void)
+{
+#ifdef CONFIG_CMA
+ /*
+ * Create private 32MiB contiguous memory area for omapdrm.0
device
+ * TODO revisit size.. if uc/wc buffers are allocated from CMA
pages
+ * then the amount of memory we need goes up..
+ */
+ dma_declare_contiguous(omap_drm_device.dev, 32 * SZ_1M, 0, 0);
What does this actually do? Does it reserve the memory, i.e. it's not
usable for others? If so, shouldn't there be a way for the user to
configure it?
It can be re-used by others.. see http://lwn.net/Articles/479297/
The link didn't tell much. I looked at the patches, and
dma_declare_contiguous allocates the memory with memblock_alloc. So is
that allocated memory available for any users? If so, why does the
function want a device pointer as an argument...
Is the memory available for normal kmalloc, or only available via the
CMA functions? Surely there must be some downside to the above? =) And
if so, it should be configurable. You could have a board with no display
at all, and you probably don't want to have 32MB allocated for DRM in
that case.
Basically the short version is memory from a CMA carveout can be
re-used for unpinnable memory. Not kmalloc, but it can be used for
anon userspace pages, for example. Userspace needs memory too.
Okay, let me ask the other way. Is 32MB enough for everyone? Hardcoding
a value like that without any possibility to adjust it just sounds like
a rather bad thing.
The main requirement is that, on omap3 or before (platforms without
DMM) you need enough to allocate all of your scanout buffers.
I'm not against having a bootarg to adjust, although I strongly prefer
sane defaults and not requiring a million bootargs just to boot in
some usable fashion.
BR,
-R
Tomi
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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] omap2+: add drm device
On Wed, 2012-03-07 at 07:06 -0600, Rob Clark wrote: On Wed, Mar 7, 2012 at 5:59 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hmm, why does the drm core care about it? Because it is the one generating the bus-id.. see drivers/gpu/drm/drm_platform.c drm_platform_set_busid() Anyways, it's just a detail about how libdrm/drmOpen() can differentiate between multiple instances of the same driver, similar to how PCI bus-id is used in the desktop world. It is not difficult to change in drm_platform_set_busid(), although not sure if that would be considered an ABI change to userspace. (Maybe it is less critical, I'm under the impression that other platform-drm users didn't even realize we had a bus-id.) Ok. Well, I'm fine with id 0 also, if it makes sense in the DRM side. It was just something that caught my eye. Okay, let me ask the other way. Is 32MB enough for everyone? Hardcoding a value like that without any possibility to adjust it just sounds like a rather bad thing. The main requirement is that, on omap3 or before (platforms without DMM) you need enough to allocate all of your scanout buffers. I'm not against having a bootarg to adjust, although I strongly prefer sane defaults and not requiring a million bootargs just to boot in some usable fashion. Well, those are two different things. I'm fine with a default of 32MB. My point was, what if I need more, or I don't need any. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] omap2+: add drm device
On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Tue, 2012-03-06 at 09:50 -0600, Gross, Andy wrote: On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: I have to say I don't know much about DMM, but my understanding is that DMM is a bigger entity, of which TILER is only a small part, and DMM manages all memory accesses. Can there be other users for the DMM than DRM? I know there could be other users for the TILER, and I know you want to combine that with the DRM driver, but I'm wondering about the other parts of DMM than the TILER. Somehow having a DMM driver inside omapdrm sounds strange. The DMM does indeed contain a number of entities. However, the TILER portion is the only part that requires a driver. All other register modifications (LISA map settings, EMIF, etc) are done statically in the loader or u-boot and never changed again. As such, DMM has become synonymous with TILER. Ok. Well, as I said, I don't know much about that, just sounds rather strange to me =). Does this DMM has become synonymous mean that people just started calling TILER DMM, and thus the name has stuck, or are there technical reasons to handle it as DMM in the kernel? If the former, and if TILER is the technically exact name for it, perhaps it would make sense to call it TILER, as that's what (at least I) would be looking for if I read the TRM and try to find the code for the TILER. Well, dmm is the name in hwmod, so either way we are sort of stuck with that.. but if you look in the TRM, you'd be looking for dynamic memory manager, so I tend to think dmm is the better name. But for some reason the old driver (in some product kernels but never made it upstream) was called tiler, which might be part of the reason that people have started using the names interchangeably. At any rate, neither tiler nor dmm appear in any userspace facing API (instead you just have some bits you can set in the flags you specify if you want tiled buffer or not when allocating a gem buffer object). So I guess it isn't as critical. BR, -R Tomi ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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_hwmod: Allow io_ring wakeup configuration for all modules.
On Wed, Mar 7, 2012 at 5:49 PM, Govindraj.R govindraj.r...@ti.com wrote:
From: Govindraj.R govindraj.r...@ti.com
Some modules doesn't have SYSC_HAS_ENAWAKEUP bit available
(ex: usb host uhh module) in absence of this flag
omap_hwmod_enable/disable_wakeup avoids configuring
pad mux wakeup capability.
Configure sysc if SYSC_HAS_ENAWAKEUP is available and for other cases
try enabling/disabling wakeup from mux_pad pins.
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 30 --
1 files changed, 16 insertions(+), 14 deletions(-)
[...]
@@ -2506,14 +2507,15 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
unsigned long flags;
u32 v;
- if (!oh-class-sysc ||
- !(oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP))
- return -EINVAL;
-
spin_lock_irqsave(oh-_lock, flags);
- v = oh-_sysc_cache;
- _disable_wakeup(oh, v);
- _write_sysconfig(v, oh);
+
+ if (oh-class-sysc ||
+ (oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP)) {
This condition check should have been _and_ ()
sorry for the typo,
Here [1] is the updated patch.
--
Thanks,
Govindraj.R
[1]:
From b3aa1dac5909cad1b959f5b97bbf408b2f974060 Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Wed, 7 Mar 2012 17:14:02 +0530
Subject: [PATCH] omap_hwmod: Allow io_ring wakeup configuration for all
modules.
Some modules doesn't have SYSC_HAS_ENAWAKEUP bit available
(ex: usb host uhh module) in absence of this flag
omap_hwmod_enable/disable_wakeup avoids configuring
pad mux wakeup capability.
Configure sysc if SYSC_HAS_ENAWAKEUP is available and for other cases
try enabling/disabling wakeup from mux_pad pins.
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 30 --
1 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index eba6cd3..9605fad 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2475,14 +2475,15 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
unsigned long flags;
u32 v;
- if (!oh-class-sysc ||
- !(oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP))
- return -EINVAL;
-
spin_lock_irqsave(oh-_lock, flags);
- v = oh-_sysc_cache;
- _enable_wakeup(oh, v);
- _write_sysconfig(v, oh);
+
+ if (oh-class-sysc
+ (oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP)) {
+ v = oh-_sysc_cache;
+ _enable_wakeup(oh, v);
+ _write_sysconfig(v, oh);
+ }
+
_set_idle_ioring_wakeup(oh, true);
spin_unlock_irqrestore(oh-_lock, flags);
@@ -2506,14 +2507,15 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
unsigned long flags;
u32 v;
- if (!oh-class-sysc ||
- !(oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP))
- return -EINVAL;
-
spin_lock_irqsave(oh-_lock, flags);
- v = oh-_sysc_cache;
- _disable_wakeup(oh, v);
- _write_sysconfig(v, oh);
+
+ if (oh-class-sysc
+ (oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP)) {
+ v = oh-_sysc_cache;
+ _disable_wakeup(oh, v);
+ _write_sysconfig(v, oh);
+ }
+
_set_idle_ioring_wakeup(oh, false);
spin_unlock_irqrestore(oh-_lock, flags);
--
1.7.5.4
0001-omap_hwmod-Allow-io_ring-wakeup-configuration-for-al.patch
Description: Binary data
Re: [PATCH v2 0/6] mmc: omap_hsmmc: Clean up use/abuse of pdev-id
Hi Rajendra, On Wed, Mar 07 2012, Rajendra Nayak wrote: Chris, Ping. I am basing my DT support patches on top of these cleanups. Would be great if you can have a look and pull them in. Chris, just realized the last two requests from me to get this merged weren't addressed to you directly, but instead you were copied. Resending with you in 'To', hope this lands in your inbox :) Sorry for the delay, thanks for the ping; I've pushed these to mmc-next for 3.4 now. Thanks, - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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/4] mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect
On Mon, Mar 5, 2012 at 3:55 PM, T Krishnamoorthy, Balaji balaj...@ti.com wrote: On Mon, Mar 5, 2012 at 2:46 PM, Rajendra Nayak rna...@ti.com wrote: On Friday 02 March 2012 10:52 PM, Tony Lindgren wrote: BTW, with -rc5, looks like re-inserting omap_hsmmc on omap4 fails to detect any cards, and then fails to unload. This works on omap3 just fine. Any ideas why that would be? Yeah, looks like thats broken. I am not sure whats going wrong though. I just enabled CONFIG_MMC_DEBUG and saw these logs below. Venkat/Balaji, care to look at this one? Let me check this OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset. Addng the offset to platform_device resource structure increments the start address for every insmod operation. MMC command fails on re-insertion as module due incorrect register base. Fix this by updating the ioremap base address only. Signed-off-by: Balaji T K balaj...@ti.com --- Note: eMMC detection is still failing on resertion due to card vcc power off on rmmod drivers/mmc/host/omap_hsmmc.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index fd0c661..4e1f8f6 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1870,8 +1870,6 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) if (res == NULL || irq 0) return -ENXIO; - res-start += pdata-reg_offset; - res-end += pdata-reg_offset; res = request_mem_region(res-start, resource_size(res), pdev-name); if (res == NULL) return -EBUSY; @@ -1896,7 +1894,7 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) host-irq = irq; host-id= pdev-id; host-slot_id = 0; - host-mapbase = res-start; + host-mapbase = res-start + pdata-reg_offset; host-base = ioremap(host-mapbase, SZ_4K); host-power_mode = MMC_POWER_OFF; host-next_data.cookie = 1; -- 1.7.0.4 # insmod omap_hsmmc.ko [ 43.358398] omap_hsmmc omap_hsmmc.0: context was not lost [ 43.364105] omap_hsmmc omap_hsmmc.0: enabled [ 44.434661] mmc0: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 44.442352] omap_hsmmc omap_hsmmc.0: Set clock to 0Hz [ 44.474365] omap_hsmmc omap_hsmmc.0: disabled [ 44.482208] omap_hsmmc omap_hsmmc.4: context was not lost [ 44.482208] omap_hsmmc omap_hsmmc.4: enabled [ 44.546600] omap_hsmmc omap_hsmmc.0: context was not lost [ 44.552276] omap_hsmmc omap_hsmmc.0: enabled [ 44.552276] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz [ 44.563720] mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 18 width 0 timing 0 [ 44.572174] omap_hsmmc omap_hsmmc.0: Set clock to 0Hz [ 44.613800] mmc0: clock 40Hz busmode 2 powermode 2 cs 0 Vdd 18 width 0 timing 0 [ 44.621887] omap_hsmmc omap_hsmmc.0: Set clock to 40Hz [ 44.735290] mmc0: starting CMD52 arg 0c00 flags 0195 [ 44.741271] omap_hsmmc omap_hsmmc.0: mmc0: CMD52, argument 0x0c00 [ 45.560241] mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 45.567871] omap_hsmmc omap_hsmmc.4: Set clock to 0Hz [ 45.591491] omap_hsmmc omap_hsmmc.4: disabled # # # rmmod omap_hsmmc [ 607.302307] omap_hsmmc omap_hsmmc.4: context was not lost [ 607.308044] omap_hsmmc omap_hsmmc.4: enabled [ 607.312591] omap_hsmmc omap_hsmmc.4: disabled [ 607.317199] omap_hsmmc omap_hsmmc.4: context was not lost [ 607.322875] omap_hsmmc omap_hsmmc.4: enabled -- Thanks and Regards, Balaji T K -- 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] omap2+: add drm device
On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Does this DMM has become synonymous mean that people just started calling TILER DMM, and thus the name has stuck, or are there technical reasons to handle it as DMM in the kernel? If the former, and if TILER is the technically exact name for it, perhaps it would make sense to call it TILER, as that's what (at least I) would be looking for if I read the TRM and try to find the code for the TILER. Tomi Well the breakdown of the DMM/Tiler kind of goes like this. The DMM defines a set of registers used to manipulate the PAT table that backs the address space with physical memory. The Tiler portion of the DMM really just describes the address space that is exposed. Depending on what address range you access, you'll get a different mode of access and rotation. Management of the address space is attributed to the Tiler as well and that is where we have managed the address space and provided APIs to reserve address space and pin/unpin memory to those regions. From a hardware perspective, we need access to the resources provided by the DMM so that we can do the PAT programming and that can only be gotten from the hwmod entry. And if you use the hwmod device entry, you have to match the name used for that entry. Regards, Andy -- 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 v3] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
On Mon, Mar 5, 2012 at 12:18 PM, Kevin Hilman khil...@ti.com wrote:
Felipe Balbi ba...@ti.com writes:
Hi,
On Thu, Mar 01, 2012 at 12:36:57PM -0800, Kevin Hilman wrote:
Matt Porter mpor...@ti.com writes:
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616 (net/smsc911x: Add regulator support) added
the requirement that platforms provide vdd33a and vddvario supplies.
Signed-off-by: Matt Porter mpor...@ti.com
[...]
/*
* Initialize smsc911x device connected to the GPMC. Note that we
* assume that pin multiplexing is done in the board-*.c file,
@@ -55,6 +101,12 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
+ ret = platform_device_register(gpmc_smsc911x_regulator);
+ if (ret 0) {
+ pr_err(Unable to register smsc911x regulators: %d\n, ret);
+ return;
+ }
+
Boards that have more than one instance of the smsc911x (OMAP3/Overo)
barf here because of trying to register the same device twice.
We need something like the patch below to make Overo boot again.
Kevin
From 4114dea2fb897ab75d05eaa943d29454034fc025 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Thu, 1 Mar 2012 12:30:42 -0800
Subject: [PATCH] ARM: OMAP2+: gpmc-smsc911x: only register regulators once
commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) added regulators which are registered during
gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo) have more
than one instance of the SMSC911x and result in attempting to register
the same regulator more than once which causes a panic(). Fix this by
tracking the regulator registration ensuring only a single device is
registered.
Cc: Matt Porter mpor...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/gpmc-smsc911x.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index bbb870c..95e6c7d 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -88,6 +88,8 @@ static struct platform_device gpmc_smsc911x_regulator = {
},
};
+static bool regulator_registered;
+
/*
* Initialize smsc911x device connected to the GPMC. Note that we
* assume that pin multiplexing is done in the board-*.c file,
@@ -101,10 +103,14 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
- ret = platform_device_register(gpmc_smsc911x_regulator);
- if (ret 0) {
- pr_err(Unable to register smsc911x regulators: %d\n, ret);
- return;
+ if (!regulator_registered) {
+ ret = platform_device_register(gpmc_smsc911x_regulator);
+ if (ret 0) {
+ pr_err(Unable to register smsc911x regulators: %d\n,
+ ret);
+ return;
+ }
+ regulator_registered = true;
Wow, this is quite a hack. Is the regulator part of the SMSC911x
device or is it outside ? If it's outside the SMSC91xx (which I
believe it is) there should be a regulator driver instead of this
hack. For boards which don't provide such a regulator (and tie the
supply pin to some constant voltage source) there should be a constant
regulator supplying the pin. But this patch is quite hacky.
Are you referring to my patch or to the original $SUBJECT patch? It's
not terribly clear.
My patch doesn't add any regulators, it just fixes a bug when this init
function is called more than once.
The addition of the regulators was done in $SUBJECT patch, not my fix.
In either case $SUBJECT patch is already in Tony's fixes queue, so if it
is going be merged, then my fix above is needed also to not break
Overo and any other platform that has more than one smsc911x instance.
Kevin
Have you tested this fix? The only regulator consumer supply would be:
static struct regulator_consumer_supply gpmc_smsc911x_supply[] = {
REGULATOR_SUPPLY(vddvario, smsc911x.0),
REGULATOR_SUPPLY(vdd33a, smsc911x.0),
};
I don't think the second smsc911x on the Overo, smsc911x.1, would
find it due to the dev_id.
--
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: Latest OMAP4 build errors
Hi, Arnd Olof, some urgent changes are needed, see below. * Russell King - ARM Linux li...@arm.linux.org.uk [120307 01:34]: On Tue, Mar 06, 2012 at 05:01:53PM +, Arnd Bergmann wrote: On Tuesday 06 March 2012, Russell King - ARM Linux wrote: On Tue, Feb 28, 2012 at 12:11:37PM +0200, Ohad Ben-Cohen wrote: On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann a...@arndb.de wrote: I think 'depends' would be better here, because selecting IOMMU_SUPPORT has other side-effects that a user might not want. It's just as likely that someone wants to disable IOMMU_SUPPORT and needs to find OMAP_REMOTEPROC as wanting to enable OMAP_REMOTEPROC and having to find IOMMU_SUPPORT. In most cases, the defconfig should just set both. Ok, 'depends on' it is. We're a week on, which means I now have a full set of 7 builds on the website for OMAP4430 all of which have failed in part due to this as yet unresolved problem. What's happening to get it fixed and those fixes into whatever tree is necessary for them (presumably arm-soc)? Ohad has sent a series of patches for review and there were no comments on those. The fix was part of it as far as I remember. I'm still waiting for a pull request from Ohad. Given that we're coming to the end of what could be the _final_ week before the merge window opens, this is not good news. Read: maybe three days before final. The fact is that OMAP is - yet again - in a totally rotten state in terms of what's queued up in the armsoc tree. It is - yet again - completely unbuildable for many configurations. Just go and have a look at: http://www.arm.linux.org.uk/developer/build/ to see what an utterly crappy state OMAP is in again. Last nights build was my tree plus latest arm-soc. Some of those issues have patches (I had been applying one patch manually to the build tree) but that's not the point - they're not in arm-soc, so the OMAP code in arm-soc is not yet ready for mainline. Yes looks like there's an issue with getting urgent patches applied into the arm-soc tree.. The patches to fix these issues are known and other issues and warnings should be all sorted out now except for some MMC changes that are still being discussed. So, as OMAP is soo broken, and as promised after the last merge window - I don't want any OMAP stuff going upstream from armsoc until we get error free builds from the allno and old configs on the builder. What I got queued up in fixes-non-critical-part2 should fix all those errors and warnings. Arnd Olof, I've posted one fix that should be applied to arm-soc tree at [1]. I've also posted a request to revert one commit in arm-soc tree at [2]. As it seems that you did not apply those to arm-soc, please apply them, or repull the following two branches ASAP: Re-pull fixes-non-critical containing one revert: Revert ARM: OMAP2+: Fix multiple randconfig errors with SOC_OMAP and SOC_OMAP_NOOP git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-non-critical Re-pull cleanup again containing one fix: ARM: OMAP2+: Fix L4_EMU_34XX_BASE error after iomap changes git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap cleanup Note that the second one I just pushed, however the patch is known to work for the build errors after merging arm-soc with Russell's changes. Arnd Olof, for future, how you want to handle urgent issues like this? Regards, Tony [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg64149.html [2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg64151.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 v3] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
* Russ Dill russ.d...@ti.com [120307 07:28]:
On Mon, Mar 5, 2012 at 12:18 PM, Kevin Hilman khil...@ti.com wrote:
In either case $SUBJECT patch is already in Tony's fixes queue, so if it
is going be merged, then my fix above is needed also to not break
Overo and any other platform that has more than one smsc911x instance.
Kevin
Have you tested this fix? The only regulator consumer supply would be:
static struct regulator_consumer_supply gpmc_smsc911x_supply[] = {
REGULATOR_SUPPLY(vddvario, smsc911x.0),
REGULATOR_SUPPLY(vdd33a, smsc911x.0),
};
I don't think the second smsc911x on the Overo, smsc911x.1, would
find it due to the dev_id.
Hmm yeah sounds like there's some further changes needed. Dropping
the second version from fixes until we have somebody reply with
tested-by using two smsc911x instances.
Regards,
Tony
--
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/4] mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect
* Chris Ball c...@laptop.org [120307 07:11]: Hi Balaji, On Wed, Mar 07 2012, T Krishnamoorthy, Balaji wrote: OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset. Addng the offset to platform_device resource structure increments the start address for every insmod operation. MMC command fails on re-insertion as module due incorrect register base. Fix this by updating the ioremap base address only. Signed-off-by: Balaji T K balaj...@ti.com Is this a regression, or has it never worked in mainline? Features that never worked originally so this can wait for the merge window. It happens on re-inserting of the card. Note: eMMC detection is still failing on resertion due to card vcc power off on rmmod And this? That sounds like a separate issue that needs to be fixed. Regards, Tony -- 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 01/21] OMAPDSS: panel-dvi: add PD gpio handling
Hi,
On Wednesday 07 March 2012 06:14 PM, Tomi Valkeinen wrote:
The driver for the DVI framer should handle the power-down signal of the
framer, instead of the current way of handling it in the board files.
What does framer mean?
This patch adds power_down_gpio into the device's platform data, and
adds the necessary code in the driver to request and handle the GPIO.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-dvi.c | 31 ++
include/video/omap-panel-dvi.h |2 +
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-dvi.c
b/drivers/video/omap2/displays/panel-dvi.c
index 03eb14a..876b798 100644
--- a/drivers/video/omap2/displays/panel-dvi.c
+++ b/drivers/video/omap2/displays/panel-dvi.c
@@ -21,6 +21,7 @@
#includelinux/slab.h
#includevideo/omapdss.h
#includelinux/i2c.h
+#includelinux/gpio.h
#includedrm/drm_edid.h
#includevideo/omap-panel-dvi.h
@@ -44,6 +45,8 @@ struct panel_drv_data {
struct omap_dss_device *dssdev;
struct mutex lock;
+
+ int pd_gpio;
};
static inline struct panel_dvi_platform_data
@@ -54,6 +57,7 @@ static inline struct panel_dvi_platform_data
static int panel_dvi_power_on(struct omap_dss_device *dssdev)
{
+ struct panel_drv_data *ddata = dev_get_drvdata(dssdev-dev);
struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
int r;
@@ -70,6 +74,9 @@ static int panel_dvi_power_on(struct omap_dss_device *dssdev)
goto err1;
}
+ if (gpio_is_valid(ddata-pd_gpio))
+ gpio_set_value(ddata-pd_gpio, 1);
+
return 0;
err1:
omapdss_dpi_display_disable(dssdev);
@@ -79,11 +86,15 @@ err0:
static void panel_dvi_power_off(struct omap_dss_device *dssdev)
{
+ struct panel_drv_data *ddata = dev_get_drvdata(dssdev-dev);
struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
return;
+ if (gpio_is_valid(ddata-pd_gpio))
+ gpio_set_value(ddata-pd_gpio, 0);
+
if (pdata-platform_disable)
pdata-platform_disable(dssdev);
@@ -92,7 +103,9 @@ static void panel_dvi_power_off(struct omap_dss_device
*dssdev)
static int panel_dvi_probe(struct omap_dss_device *dssdev)
{
+ struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
struct panel_drv_data *ddata;
+ int r;
ddata = kzalloc(sizeof(*ddata), GFP_KERNEL);
if (!ddata)
@@ -104,6 +117,21 @@ static int panel_dvi_probe(struct omap_dss_device *dssdev)
ddata-dssdev = dssdev;
mutex_init(ddata-lock);
+ if (pdata)
+ ddata-pd_gpio = pdata-power_down_gpio;
+ else
+ ddata-pd_gpio = -1;
+
+ if (gpio_is_valid(ddata-pd_gpio)) {
+ r = gpio_request_one(ddata-pd_gpio, GPIOF_OUT_INIT_LOW,
+ tfp410 pd);
+ if (r) {
+ dev_err(dssdev-dev, Failed to request PD GPIO %d\n,
+ ddata-pd_gpio);
+ ddata-pd_gpio = -1;
Is the power down gpio not a necessary thing? If it is, we should quit
here itself, shouldn't we?
Archit
+ }
+ }
+
dev_set_drvdata(dssdev-dev, ddata);
return 0;
@@ -115,6 +143,9 @@ static void __exit panel_dvi_remove(struct omap_dss_device
*dssdev)
mutex_lock(ddata-lock);
+ if (gpio_is_valid(ddata-pd_gpio))
+ gpio_free(ddata-pd_gpio);
+
dev_set_drvdata(dssdev-dev, NULL);
mutex_unlock(ddata-lock);
diff --git a/include/video/omap-panel-dvi.h b/include/video/omap-panel-dvi.h
index 87ad567b..4ad41fc 100644
--- a/include/video/omap-panel-dvi.h
+++ b/include/video/omap-panel-dvi.h
@@ -27,11 +27,13 @@ struct omap_dss_device;
* @platform_enable: platform specific panel enable function
* @platform_disable: platform specific panel disable function
* @i2c_bus_num: i2c bus id for the panel
+ * @power_down_gpio: gpio number for PD pin (or -1 if not available)
*/
struct panel_dvi_platform_data {
int (*platform_enable)(struct omap_dss_device *dssdev);
void (*platform_disable)(struct omap_dss_device *dssdev);
u16 i2c_bus_num;
+ int power_down_gpio;
};
#endif /* __OMAP_PANEL_DVI_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 08/21] OMAPDSS: clean up the omapdss platform data mess
On Wednesday 07 March 2012 06:14 PM, Tomi Valkeinen wrote:
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct omap_display_platform_data. It was used just as a
wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
dss hwmods do not need the platform data. This should also work better
for DT, as we can create omapdss device programmatically in generic omap
boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
that the dss hwmod drivers can call.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 37 ++---
drivers/video/omap2/dss/core.c | 35 +++
drivers/video/omap2/dss/dispc.c | 21 ++---
drivers/video/omap2/dss/dsi.c | 17 +++--
drivers/video/omap2/dss/dss.h |3 +++
drivers/video/omap2/dss/hdmi.c |2 --
include/video/omapdss.h |5 -
7 files changed, 61 insertions(+), 59 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 3677b1f..279c124 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -185,10 +185,23 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
struct omap_hwmod *oh;
struct platform_device *pdev;
int i, oh_count;
- struct omap_display_platform_data pdata;
const struct omap_dss_hwmod_data *curr_dss_hwmod;
- memset(pdata, 0, sizeof(pdata));
+ /* create omapdss device */
+
+ board_data-dsi_enable_pads = omap_dsi_enable_pads;
+ board_data-dsi_disable_pads = omap_dsi_disable_pads;
+ board_data-get_context_loss_count = omap_pm_get_dev_context_loss_count;
Why are the checks for board data being NULL removed here?
+
+ omap_display_device.dev.platform_data = board_data;
+
+ r = platform_device_register(omap_display_device);
+ if (r 0) {
+ pr_err(Unable to register omapdss device\n);
+ return r;
+ }
+
+ /* create devices for dss hwmods */
if (cpu_is_omap24xx()) {
curr_dss_hwmod = omap2_dss_hwmod_data;
@@ -201,15 +214,6 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
}
- if (board_data-dsi_enable_pads == NULL)
- board_data-dsi_enable_pads = omap_dsi_enable_pads;
- if (board_data-dsi_disable_pads == NULL)
- board_data-dsi_disable_pads = omap_dsi_disable_pads;
-
- pdata.board_data = board_data;
- pdata.board_data-get_context_loss_count =
- omap_pm_get_dev_context_loss_count;
-
for (i = 0; i oh_count; i++) {
oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
if (!oh) {
@@ -219,21 +223,16 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
}
pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
- curr_dss_hwmod[i].id, oh,pdata,
- sizeof(struct omap_display_platform_data),
+ curr_dss_hwmod[i].id, oh,
+ NULL, 0,
NULL, 0, 0);
if (WARN((IS_ERR(pdev)), Could not build omap_device for %s\n,
curr_dss_hwmod[i].oh_name))
return -ENODEV;
}
- omap_display_device.dev.platform_data = board_data;
- r = platform_device_register(omap_display_device);
- if (r 0)
- printk(KERN_ERR Unable to register OMAP-Display device\n);
-
- return r;
+ return 0;
}
static void dispc_disable_outputs(void)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 8613f86..3efd473 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -87,6 +87,41 @@ struct regulator *dss_get_vdds_sdi(void)
return reg;
}
+int dss_get_ctx_loss_count(struct device *dev)
+{
+ struct omap_dss_board_info *board_data = core.pdev-dev.platform_data;
+ int cnt;
+
+ if (!board_data || !board_data-get_context_loss_count)
+ return -ENOENT;
why do we check board_data being NULL here and not in omap_display_init()?
Archit
+
+ cnt = board_data-get_context_loss_count(dev);
+
+ WARN_ONCE(cnt 0, get_context_loss_count failed: %d\n, cnt);
+
+ return cnt;
+}
+
+int dss_dsi_enable_pads(int dsi_id, unsigned lane_mask)
+{
+ struct omap_dss_board_info *board_data = core.pdev-dev.platform_data;
+
+ if
Re: [PATCH v3] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
Hi Russ,
Russ Dill russ.d...@ti.com writes:
On Mon, Mar 5, 2012 at 12:18 PM, Kevin Hilman khil...@ti.com wrote:
Felipe Balbi ba...@ti.com writes:
Hi,
On Thu, Mar 01, 2012 at 12:36:57PM -0800, Kevin Hilman wrote:
Matt Porter mpor...@ti.com writes:
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616 (net/smsc911x: Add regulator support) added
the requirement that platforms provide vdd33a and vddvario supplies.
Signed-off-by: Matt Porter mpor...@ti.com
[...]
/*
* Initialize smsc911x device connected to the GPMC. Note that we
* assume that pin multiplexing is done in the board-*.c file,
@@ -55,6 +101,12 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
+ ret = platform_device_register(gpmc_smsc911x_regulator);
+ if (ret 0) {
+ pr_err(Unable to register smsc911x regulators: %d\n, ret);
+ return;
+ }
+
Boards that have more than one instance of the smsc911x (OMAP3/Overo)
barf here because of trying to register the same device twice.
We need something like the patch below to make Overo boot again.
Kevin
From 4114dea2fb897ab75d05eaa943d29454034fc025 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Thu, 1 Mar 2012 12:30:42 -0800
Subject: [PATCH] ARM: OMAP2+: gpmc-smsc911x: only register regulators once
commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) added regulators which are registered during
gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo) have more
than one instance of the SMSC911x and result in attempting to register
the same regulator more than once which causes a panic(). Fix this by
tracking the regulator registration ensuring only a single device is
registered.
Cc: Matt Porter mpor...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/gpmc-smsc911x.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index bbb870c..95e6c7d 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -88,6 +88,8 @@ static struct platform_device gpmc_smsc911x_regulator = {
},
};
+static bool regulator_registered;
+
/*
* Initialize smsc911x device connected to the GPMC. Note that we
* assume that pin multiplexing is done in the board-*.c file,
@@ -101,10 +103,14 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
- ret = platform_device_register(gpmc_smsc911x_regulator);
- if (ret 0) {
- pr_err(Unable to register smsc911x regulators: %d\n, ret);
- return;
+ if (!regulator_registered) {
+ ret = platform_device_register(gpmc_smsc911x_regulator);
+ if (ret 0) {
+ pr_err(Unable to register smsc911x regulators: %d\n,
+ ret);
+ return;
+ }
+ regulator_registered = true;
Wow, this is quite a hack. Is the regulator part of the SMSC911x
device or is it outside ? If it's outside the SMSC91xx (which I
believe it is) there should be a regulator driver instead of this
hack. For boards which don't provide such a regulator (and tie the
supply pin to some constant voltage source) there should be a constant
regulator supplying the pin. But this patch is quite hacky.
Are you referring to my patch or to the original $SUBJECT patch? It's
not terribly clear.
My patch doesn't add any regulators, it just fixes a bug when this init
function is called more than once.
The addition of the regulators was done in $SUBJECT patch, not my fix.
In either case $SUBJECT patch is already in Tony's fixes queue, so if it
is going be merged, then my fix above is needed also to not break
Overo and any other platform that has more than one smsc911x instance.
Kevin
Have you tested this fix?
Yes. On 3530/Overo.
The only regulator consumer supply would be:
static struct regulator_consumer_supply gpmc_smsc911x_supply[] = {
REGULATOR_SUPPLY(vddvario, smsc911x.0),
REGULATOR_SUPPLY(vdd33a, smsc911x.0),
};
I don't think the second smsc911x on the Overo, smsc911x.1, would
find it due to the dev_id.
It's not about finding the second regulator. As stated in the
changelog, it's about the duplicate attempt to register the exact same
platform_device.
Duplicate attempts to register the exact same platform_device cause
kobject to panic and give up[1]. So, any platform that calls
gpmc_smsc911x_init() twice (Overo and T35 in mainline) will panic on
boot.
This patch fixes those platforms so they can boot.
Kevin
[1]
[0.337036] kobject (c06b1730): tried to init an initialized object,
something is seriously wrong.
[0.346679] [c001421c]
Re: [PATCH 7/7] OMAPDSS: HDMI: hot plug detect fix
On Thu, Mar 01, 2012 at 02:26:35PM +0200, Tomi Valkeinen wrote: From: Rob Clark r...@ti.com The OMAPDSS: HDMI: PHY burnout fix commit switched the HDMI driver over to using a GPIO for plug detect. Unfortunately the -detect() method was not also updated, causing HDMI to no longer work for the omapdrm driver (because it would actually check if a connection was detected before attempting to enable display). Signed-off-by: Rob Clark r...@ti.com Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com You forgot to tell me what the git commit id is for this patch (it's ca888a7958b3d808e4efd08ceff88913f4212c69, right?) And why isn't this needed for the 3.0 kernel as well? 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
[GIT PULL] ARM: OMAP2+: PM: core support for SMPS regulators for v3.4
Tony, Please pull the following support for using regulators to control the on-chip VC/VP managed voltage domains. The regulator driver support for this is already queued in the regulator tree, and this is the supporting core work. This combined with the CPUfreq changes to use the regulator framework will finally result in MPU DVFS working in mainline. Kevin The following changes since commit b01543dfe67bb1d191998e90d20534dc354de059: Linux 3.3-rc4 (2012-02-18 15:53:33 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/pm/smps-regulator for you to fetch changes up to c15f1d84bb3ddd668593e9bca53221a2f82e9e99: ARM: OMAP2+: voltage: ensure voltage used is exact voltage from OPP table (2012-03-06 17:37:14 -0800) Kevin Hilman (1): ARM: OMAP2+: voltage: ensure voltage used is exact voltage from OPP table Tero Kristo (4): arm: omap3: voltage: fix channel configuration arm: omap3: add common twl configurations for vdd1 and vdd2 arm: omap3: twl: add external controllers for core voltage regulators arm: omap4: add common twl configurations for vdd1, vdd2 and vdd3 arch/arm/mach-omap2/twl-common.c | 147 + arch/arm/mach-omap2/vc3xxx_data.c |1 + arch/arm/mach-omap2/voltage.c | 21 +- 3 files changed, 166 insertions(+), 3 deletions(-) -- 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
[GIT PULL] cpufreq: OMAP updates for v3.4
Dave, Please pull the following OMAP CPUfreq driver changes for v3.4. Thanks, Kevin The following changes since commit b01543dfe67bb1d191998e90d20534dc354de059: Linux 3.3-rc4 (2012-02-18 15:53:33 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/cpufreq for you to fetch changes up to 42daffd2d6c665716d442d518022ecaad17ddf64: cpufreq: OMAP: specify range for voltage scaling (2012-03-02 13:55:57 -0800) Afzal Mohammed (1): cpufreq: OMAP: specify range for voltage scaling Kevin Hilman (1): cpufreq: OMAP: scale voltage along with frequency Russell King (1): cpufreq: OMAP driver depends CPUfreq tables drivers/cpufreq/Kconfig.arm|5 +++ drivers/cpufreq/Makefile |2 +- drivers/cpufreq/omap-cpufreq.c | 72 +--- 3 files changed, 73 insertions(+), 6 deletions(-) -- 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: [GIT PULL] cpufreq: OMAP updates for v3.4
On Wed, Mar 07, 2012 at 12:20:41PM -0800, Kevin Hilman wrote: Dave, Please pull the following OMAP CPUfreq driver changes for v3.4. pulled, thanks. Dave -- 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: help: BeagleBoard xM RevC ethernet port
On Thu, 1 Mar 2012, Govindraj wrote: On Wed, Feb 29, 2012 at 11:36 PM, Brian Austin brian.aus...@cirrus.com wrote: Applying this patch gives this on my beagleboard xM revC Linux debian 3.3.0-rc4 Unable to set up timer: unexpected error Failed to bring up eth0. Works for me on 3.3-rc4 + sent patch on beagle xm revc here this the log [1] Ensure you have selected following for ehci and usb Ethernet adapter support. CONFIG_USB_EHCI_HCD CONFIG_USB_EHCI_HCD_OMAP CONFIG_USB_NET_SMSC95XX Thanks for the config. Unfortunately this does nothing for Debian Unstable on the beagleboard Xm RevC DHCPREQUEST on eth0 to 255.255.255.255 port 67 Unable to set up timer: unexpected error Failed to bring up eth0. root@debian:~# [ 310.470581] smsc95xx 1-2.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 Kernel log shows the device getting registered. [4.768096] smsc95xx 1-2.1:1.0: eth0: register 'smsc95xx' at usb-ehci-omap.0-2.1, smsc95xx USB 2.0 Ethernet, 76:22:51:1f:d9:b6 I'm guessing this is a Debian problem. The Debian kernel binary 3.2.7-x5 works fine. I'm building from git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git with tag v3.3-rc4. Thanks, Brian -- 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: help: BeagleBoard xM RevC ethernet port
On Wed, 7 Mar 2012, Brian Austin wrote: On Thu, 1 Mar 2012, Govindraj wrote: On Wed, Feb 29, 2012 at 11:36 PM, Brian Austin brian.aus...@cirrus.com wrote: Applying this patch gives this on my beagleboard xM revC Linux debian 3.3.0-rc4 Unable to set up timer: unexpected error Failed to bring up eth0. Works for me on 3.3-rc4 + sent patch on beagle xm revc here this the log [1] Ensure you have selected following for ehci and usb Ethernet adapter support. CONFIG_USB_EHCI_HCD CONFIG_USB_EHCI_HCD_OMAP CONFIG_USB_NET_SMSC95XX Thanks for the config. Unfortunately this does nothing for Debian Unstable on the beagleboard Xm RevC I should rephrase this. It does actually show up in the kernel log so the kernel sees the device. My bad. It just wont grab an IP from Debian. DHCPREQUEST on eth0 to 255.255.255.255 port 67 Unable to set up timer: unexpected error Failed to bring up eth0. root@debian:~# [ 310.470581] smsc95xx 1-2.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 Kernel log shows the device getting registered. [4.768096] smsc95xx 1-2.1:1.0: eth0: register 'smsc95xx' at usb-ehci-omap.0-2.1, smsc95xx USB 2.0 Ethernet, 76:22:51:1f:d9:b6 I'm guessing this is a Debian problem. The Debian kernel binary 3.2.7-x5 works fine. I'm building from git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git with tag v3.3-rc4. Thanks, Brian -- 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] ARM: OMAP2+: Fix build issues with missing include of linux/bug.h
Otherwise we can get the following for some .config files: arch/arm/mach-omap2/powerdomain-common.c: In function 'omap2_pwrdm_get_mem_bank_onstate_mask': arch/arm/mach-omap2/powerdomain-common.c:64:3: error: implicit declaration of function 'WARN_ON' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors Signed-off-by: Tony Lindgren t...@atomide.com --- Looks like this is needed for some .config files with current for-next --- a/arch/arm/mach-omap2/clkt_clksel.c +++ b/arch/arm/mach-omap2/clkt_clksel.c @@ -43,6 +43,7 @@ #include linux/errno.h #include linux/clk.h #include linux/io.h +#include linux/bug.h #include plat/clock.h --- a/arch/arm/mach-omap2/powerdomain-common.c +++ b/arch/arm/mach-omap2/powerdomain-common.c @@ -13,6 +13,7 @@ #include linux/errno.h #include linux/kernel.h +#include linux/bug.h #include pm.h #include cm.h #include cm-regbits-34xx.h --- a/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c +++ b/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c @@ -15,6 +15,7 @@ #include linux/io.h #include linux/errno.h #include linux/delay.h +#include linux/bug.h #include plat/prcm.h --- a/arch/arm/mach-omap2/powerdomains3xxx_data.c +++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c @@ -13,6 +13,7 @@ #include linux/kernel.h #include linux/init.h +#include linux/bug.h #include plat/cpu.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: Latest OMAP4 build errors
Hi, On Wed, Mar 7, 2012 at 9:10 AM, Tony Lindgren t...@atomide.com wrote: Hi, Arnd Olof, some urgent changes are needed, see below. * Russell King - ARM Linux li...@arm.linux.org.uk [120307 01:34]: On Tue, Mar 06, 2012 at 05:01:53PM +, Arnd Bergmann wrote: On Tuesday 06 March 2012, Russell King - ARM Linux wrote: On Tue, Feb 28, 2012 at 12:11:37PM +0200, Ohad Ben-Cohen wrote: On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann a...@arndb.de wrote: I think 'depends' would be better here, because selecting IOMMU_SUPPORT has other side-effects that a user might not want. It's just as likely that someone wants to disable IOMMU_SUPPORT and needs to find OMAP_REMOTEPROC as wanting to enable OMAP_REMOTEPROC and having to find IOMMU_SUPPORT. In most cases, the defconfig should just set both. Ok, 'depends on' it is. We're a week on, which means I now have a full set of 7 builds on the website for OMAP4430 all of which have failed in part due to this as yet unresolved problem. What's happening to get it fixed and those fixes into whatever tree is necessary for them (presumably arm-soc)? Ohad has sent a series of patches for review and there were no comments on those. The fix was part of it as far as I remember. I'm still waiting for a pull request from Ohad. Given that we're coming to the end of what could be the _final_ week before the merge window opens, this is not good news. Read: maybe three days before final. The fact is that OMAP is - yet again - in a totally rotten state in terms of what's queued up in the armsoc tree. It is - yet again - completely unbuildable for many configurations. Just go and have a look at: http://www.arm.linux.org.uk/developer/build/ to see what an utterly crappy state OMAP is in again. Last nights build was my tree plus latest arm-soc. Some of those issues have patches (I had been applying one patch manually to the build tree) but that's not the point - they're not in arm-soc, so the OMAP code in arm-soc is not yet ready for mainline. Yes looks like there's an issue with getting urgent patches applied into the arm-soc tree.. The patches to fix these issues are known and other issues and warnings should be all sorted out now except for some MMC changes that are still being discussed. So, as OMAP is soo broken, and as promised after the last merge window - I don't want any OMAP stuff going upstream from armsoc until we get error free builds from the allno and old configs on the builder. What I got queued up in fixes-non-critical-part2 should fix all those errors and warnings. Arnd Olof, I've posted one fix that should be applied to arm-soc tree at [1]. I've also posted a request to revert one commit in arm-soc tree at [2]. As it seems that you did not apply those to arm-soc, please apply them, or repull the following two branches ASAP: Done (repulled the branches). Stephen Rothwell has not surfaced on irc yet, so hopefully this means it'll make it into today's linux-next. Re-pull fixes-non-critical containing one revert: Revert ARM: OMAP2+: Fix multiple randconfig errors with SOC_OMAP and SOC_OMAP_NOOP git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-non-critical Re-pull cleanup again containing one fix: ARM: OMAP2+: Fix L4_EMU_34XX_BASE error after iomap changes git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap cleanup Note that the second one I just pushed, however the patch is known to work for the build errors after merging arm-soc with Russell's changes. Looks like you pasted the wrong subject above -- the mail below contains the patch that you added though so it looked OK to me (the subject above was the previous top-of-branch before you added the last one). Arnd Olof, for future, how you want to handle urgent issues like this? Personally I missed the requests since they ended up in the chain of replies and I didn't notice them, my mistake. A separate email requesting pulls or patch application it to a...@kernel.org would reduce the risk of that happening (Flagging the subject with [URGENT] wouldn't hurt). -Olof -- 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: Latest OMAP4 build errors
* Olof Johansson o...@lixom.net [120307 13:46]: On Wed, Mar 7, 2012 at 9:10 AM, Tony Lindgren t...@atomide.com wrote: What I got queued up in fixes-non-critical-part2 should fix all those errors and warnings. Arnd Olof, I've posted one fix that should be applied to arm-soc tree at [1]. I've also posted a request to revert one commit in arm-soc tree at [2]. As it seems that you did not apply those to arm-soc, please apply them, or repull the following two branches ASAP: Done (repulled the branches). Stephen Rothwell has not surfaced on irc yet, so hopefully this means it'll make it into today's linux-next. Thanks! Re-pull fixes-non-critical containing one revert: Revert ARM: OMAP2+: Fix multiple randconfig errors with SOC_OMAP and SOC_OMAP_NOOP git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-non-critical Re-pull cleanup again containing one fix: ARM: OMAP2+: Fix L4_EMU_34XX_BASE error after iomap changes git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap cleanup Note that the second one I just pushed, however the patch is known to work for the build errors after merging arm-soc with Russell's changes. Looks like you pasted the wrong subject above -- the mail below contains the patch that you added though so it looked OK to me (the subject above was the previous top-of-branch before you added the last one). Oops, sorry about that. The end result looks right. Arnd Olof, for future, how you want to handle urgent issues like this? Personally I missed the requests since they ended up in the chain of replies and I didn't notice them, my mistake. A separate email requesting pulls or patch application it to a...@kernel.org would reduce the risk of that happening (Flagging the subject with [URGENT] wouldn't hurt). OK thanks, will do that next time if there's something urgent. I'll send a pull request shortly for fixes-non-critical-part2 that should sort out the remaining issues. Regards, Tony -- 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
[GIT PULL] Urgent pre-emptive fixes for next merge window
Hi Arnd Olof,
The following contains fixes for the next merge window.
Included are the issues noted by Russell.
I've tested it against the current next tree with
omap1_defconfig, omap2plus_defconfig, and Russell's
omap3430-ldp and omap4430-sdp seed configs, and the
related allnoconfigs.
One more patch seems to be needed for some .config
files that I've just posted as [PATCH] ARM: OMAP2+:
Fix build issues with missing include of linux/bug.h.
I'd like to figure out what exactly causes that, so
as soon as that's done, I'll send a pull request for
that.
Please note that arm-soc/for-next and ASoC changes
in next can have minor merge with these fixes.
I saw the following with today's next tree:
1. These fixes can conflict with some ASoC changes
using cpu_is_omap4430 that should be replaced with
cpu_is_omap443x (or cpu_is_omap44xx) to avoid
breaking build. This series removes cpu_is_omap4430
as it is broken as noted in the changelog. As an
earlier patch already fixed an issue in dma.c,
this series is based on commit d82ba995.
2. For arch/arm/mach-omap2/io.c this series can cause
a minor conflict with clean-up with the includes.
This can break build if include common.h is
not kept.
For reference, here's what I resolved with when doing
a test merge against current next tree:
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@@ -528,20 -485,6 +528,20 @@@ void __init omap4_panda_display_init(vo
omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
+static void omap4_panda_init_rev(void)
+{
- if (cpu_is_omap4430()) {
++ if (cpu_is_omap443x()) {
+ /* PandaBoard 4430 */
+ /* ASoC audio configuration */
+ panda_abe_audio_data.card_name = PandaBoard;
+ panda_abe_audio_data.has_hsmic = 1;
+ } else {
+ /* PandaBoard ES */
+ /* ASoC audio configuration */
+ panda_abe_audio_data.card_name = PandaBoardES;
+ }
+}
+
static void __init omap4_panda_init(void)
{
int package = OMAP_PACKAGE_CBS;
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@@ -29,18 -30,19 +29,18 @@@
#include plat/sram.h
#include plat/sdrc.h
#include plat/serial.h
+#include plat/omap-pm.h
+#include plat/omap_hwmod.h
+#include plat/multi.h
-#include clock2xxx.h
-#include clock3xxx.h
-#include clock44xx.h
-
+#include iomap.h
+ #include common.h
-#include plat/omap-pm.h
#include voltage.h
#include powerdomain.h
-
#include clockdomain.h
- #include common.h
-#include plat/omap_hwmod.h
-#include plat/multi.h
+#include clock2xxx.h
+#include clock3xxx.h
+#include clock44xx.h
/*
* The machine specific code may provide the extra mapping besides the
And the pull request is below.
Regards,
Tony
The following changes since commit d82ba9954b6b2c4ac91ec6f6f42be8c5215d0619:
Peter Ujfalusi (1):
OMAP4: dma: Correct CPU version check for dma_common_ch_end
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
fixes-non-critical-part2
Afzal Mohammed (1):
ARM: OMAP2+: id: Add am33xx SoC type detection
Bernhard Walle (1):
ARM: OMAP2+: GPMC: Export gpmc_enable_hwecc and gpmc_calculate_ecc
Danny Kukawka (2):
ARM: OMAP: clock.c: included linux/debugfs.h twice
ARM: OMAP2+: included some headers twice
Felipe Contreras (1):
ARM: OMAP: mailbox: trivial whitespace fix
Grazvydas Ignotas (1):
ARM: omap: pandora: fix usbhs platform data
Ilya Yanok (1):
ARM: OMAP2+: ads7846_init: put gpio_pendown into pdata if it's provided
Jon Hunter (1):
ARM: OMAP: Remove definition cpu_is_omap4430()
Kevin Hilman (2):
ARM: OMAP2+: PM: fix section mismatch with omap2_init_processor_devices()
ARM: OMAP2+: PM: fix wakeupgen warning when hotplug disabled
Masanari Iida (1):
ARM: OMAP1: Fix typo in lcd_dma.c
Ohad Ben-Cohen (1):
ARM: OMAP: don't build hwspinlock in vain
Tarun Kanti DebBarma (1):
ARM: OMAP: dmtimer: fix missing content/correction in low-power mode
support
Tony Lindgren (3):
ARM: OMAP1: Fix section mismatch for omap1_init_early()
ARM: OMAP2+: Fix omap24xx_io_desc warning if SoC subtypes are not selected
ARM: OMAP2: Fix section warning for n8x0 when CONFIG_MMC_OMAP is not set
Vaibhav Bedia (1):
ARM: OMAP: sram: Add am33xx SRAM support (minimal)
Yuan Jiangli (1):
ARM: OMAP3+: PM: VP: fix integer truncation error
arch/arm/mach-omap1/io.c |2 +-
arch/arm/mach-omap1/lcd_dma.c |2 +-
arch/arm/mach-omap2/Makefile |4 ++-
arch/arm/mach-omap2/board-ldp.c|1 -
arch/arm/mach-omap2/board-n8x0.c |8 ++--
arch/arm/mach-omap2/board-omap3pandora.c | 10 +++---
arch/arm/mach-omap2/common-board-devices.c |8 +++--
arch/arm/mach-omap2/control.h
Re: [GIT PULL] Urgent pre-emptive fixes for next merge window
On Wed, Mar 7, 2012 at 2:59 PM, Tony Lindgren t...@atomide.com wrote: The following changes since commit d82ba9954b6b2c4ac91ec6f6f42be8c5215d0619: Peter Ujfalusi (1): OMAP4: dma: Correct CPU version check for dma_common_ch_end are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-non-critical-part2 Pulled, thanks. -Olof -- 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: [GIT PULL] fixing and cleaning up rpmsg/remoteproc for 3.4
On Tue, Mar 6, 2012 at 10:09 AM, Ohad Ben-Cohen o...@wizery.com wrote: Hi Arnd, Please pull: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git rpmsg-fixes-and-more-for-3.4 To get a few rpmsg/remoteproc fixes, cleanups and some generalization work for 3.4. Again, I should have sent the Kconfig patch earlier in a separate pull request. Sorry about that. Pulled, thanks. -Olof -- 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: [GIT PULL] Urgent pre-emptive fixes for next merge window
* Olof Johansson o...@lixom.net [120307 14:41]: On Wed, Mar 7, 2012 at 2:59 PM, Tony Lindgren t...@atomide.com wrote: The following changes since commit d82ba9954b6b2c4ac91ec6f6f42be8c5215d0619: Peter Ujfalusi (1): OMAP4: dma: Correct CPU version check for dma_common_ch_end are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-non-critical-part2 Pulled, thanks. Thanks. Once the remoteproc updates are there, things build even without IOMMU_SUPPORT selected. So that leaves the include linux/bug.h issue and the ASoC cpu_is_omap4430 issue. I'll let Peter know about the ASoC issue. Regards, Tony -- 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: Latest OMAP4 build errors
On Wed, Mar 07, 2012 at 02:44:59PM -0800, Tony Lindgren wrote: OK thanks, will do that next time if there's something urgent. I'll send a pull request shortly for fixes-non-critical-part2 that should sort out the remaining issues. FYI, I've just updated the build tree with what's in arm-soc (as of a couple of minutes ago), which contained a bunch of OMAP updates, so I'm hopeful that tomorrows results should show an improvement. It'll start its run in about 2h20. -- 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] ARM: OMAP2+: Fix build issues with missing include of linux/bug.h
* Tony Lindgren t...@atomide.com [120307 13:04]: Looks like this is needed for some .config files with current for-next This is because of next/master commit 6c03438ed (kernel.h: doesn't explicitly use bug.h, so don't include it). Will update the commit message to say: Otherwise we can get the following if bug.h is not included from kernel.h: arch/arm/mach-omap2/powerdomain-common.c: In function 'omap2_pwrdm_get_mem_bank_onstate_mask': arch/arm/mach-omap2/powerdomain-common.c:64:3: error: implicit declaration of function 'WARN_ON' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/mach-omap2/clkt_clksel.c +++ b/arch/arm/mach-omap2/clkt_clksel.c @@ -43,6 +43,7 @@ #include linux/errno.h #include linux/clk.h #include linux/io.h +#include linux/bug.h #include plat/clock.h --- a/arch/arm/mach-omap2/powerdomain-common.c +++ b/arch/arm/mach-omap2/powerdomain-common.c @@ -13,6 +13,7 @@ #include linux/errno.h #include linux/kernel.h +#include linux/bug.h #include pm.h #include cm.h #include cm-regbits-34xx.h --- a/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c +++ b/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c @@ -15,6 +15,7 @@ #include linux/io.h #include linux/errno.h #include linux/delay.h +#include linux/bug.h #include plat/prcm.h --- a/arch/arm/mach-omap2/powerdomains3xxx_data.c +++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c @@ -13,6 +13,7 @@ #include linux/kernel.h #include linux/init.h +#include linux/bug.h #include plat/cpu.h ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 v2] ARM: OMAP2+: Fix build issues with missing include of linux/bug.h
Otherwise we can get the following if bug.h is not included from kernel.h: arch/arm/mach-omap2/powerdomain-common.c: In function 'omap2_pwrdm_get_mem_bank_onstate_mask': arch/arm/mach-omap2/powerdomain-common.c:64:3: error: implicit declaration of function 'WARN_ON' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap2/clkt_clksel.c b/arch/arm/mach-omap2/clkt_clksel.c index e25364d..04d551b 100644 --- a/arch/arm/mach-omap2/clkt_clksel.c +++ b/arch/arm/mach-omap2/clkt_clksel.c @@ -43,6 +43,7 @@ #include linux/errno.h #include linux/clk.h #include linux/io.h +#include linux/bug.h #include plat/clock.h diff --git a/arch/arm/mach-omap2/powerdomain-common.c b/arch/arm/mach-omap2/powerdomain-common.c index f97afff..c0aeabf 100644 --- a/arch/arm/mach-omap2/powerdomain-common.c +++ b/arch/arm/mach-omap2/powerdomain-common.c @@ -13,6 +13,7 @@ #include linux/errno.h #include linux/kernel.h +#include linux/bug.h #include pm.h #include cm.h #include cm-regbits-34xx.h diff --git a/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c b/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c index 6a17e4c..0f0a9f1 100644 --- a/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c +++ b/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c @@ -15,6 +15,7 @@ #include linux/io.h #include linux/errno.h #include linux/delay.h +#include linux/bug.h #include plat/prcm.h diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c b/arch/arm/mach-omap2/powerdomains3xxx_data.c index 8ef26da..b7ea468 100644 --- a/arch/arm/mach-omap2/powerdomains3xxx_data.c +++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c @@ -13,6 +13,7 @@ #include linux/kernel.h #include linux/init.h +#include linux/bug.h #include plat/cpu.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] ARM: OMAP2+: Fix build issues with missing include of linux/bug.h
On Wed, Mar 7, 2012 at 5:28 PM, Tony Lindgren t...@atomide.com wrote: Otherwise we can get the following if bug.h is not included from kernel.h: arch/arm/mach-omap2/powerdomain-common.c: In function 'omap2_pwrdm_get_mem_bank_onstate_mask': arch/arm/mach-omap2/powerdomain-common.c:64:3: error: implicit declaration of function 'WARN_ON' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors Signed-off-by: Tony Lindgren t...@atomide.com Applied to next/fixes-non-critical. Thanks! -Olof -- 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] ARM: OMAP2+: Fix build issues with missing include of linux/bug.h
* Olof Johansson o...@lixom.net [120307 16:59]: On Wed, Mar 7, 2012 at 5:28 PM, Tony Lindgren t...@atomide.com wrote: Otherwise we can get the following if bug.h is not included from kernel.h: arch/arm/mach-omap2/powerdomain-common.c: In function 'omap2_pwrdm_get_mem_bank_onstate_mask': arch/arm/mach-omap2/powerdomain-common.c:64:3: error: implicit declaration of function 'WARN_ON' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors Signed-off-by: Tony Lindgren t...@atomide.com Applied to next/fixes-non-critical. Thanks! Thanks a lot! Tony -- 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: [GIT PULL] ARM: OMAP2+: PM: core support for SMPS regulators for v3.4
* Kevin Hilman khil...@ti.com [120307 11:42]: Tony, Please pull the following support for using regulators to control the on-chip VC/VP managed voltage domains. The regulator driver support for this is already queued in the regulator tree, and this is the supporting core work. This combined with the CPUfreq changes to use the regulator framework will finally result in MPU DVFS working in mainline. Nice.. However this one might be missing some header changes? I'm getting the following: arch/arm/mach-omap2/twl-common.c:174:15: error: variable 'omap3_vdd1_drvdata' has initializer but incomplete type arch/arm/mach-omap2/twl-common.c:175:2: error: unknown field 'get_voltage' specified in initializer arch/arm/mach-omap2/twl-common.c:175:2: warning: excess elements in struct initializer [enabled by default] arch/arm/mach-omap2/twl-common.c:175:2: warning: (near initialization for 'omap3_vdd1_drvdata') [enabled by default] arch/arm/mach-omap2/twl-common.c:176:2: error: unknown field 'set_voltage' specified in initializer arch/arm/mach-omap2/twl-common.c:176:2: warning: excess elements in struct initializer [enabled by default] arch/arm/mach-omap2/twl-common.c:176:2: warning: (near initialization for 'omap3_vdd1_drvdata') [enabled by default] arch/arm/mach-omap2/twl-common.c:179:15: error: variable 'omap3_vdd2_drvdata' has initializer but incomplete type arch/arm/mach-omap2/twl-common.c:180:2: error: unknown field 'get_voltage' specified in initializer arch/arm/mach-omap2/twl-common.c:180:2: warning: excess elements in struct initializer [enabled by default] arch/arm/mach-omap2/twl-common.c:180:2: warning: (near initialization for 'omap3_vdd2_drvdata') [enabled by default] arch/arm/mach-omap2/twl-common.c:181:2: error: unknown field 'set_voltage' specified in initializer arch/arm/mach-omap2/twl-common.c:181:2: warning: excess elements in struct initializer [enabled by default] arch/arm/mach-omap2/twl-common.c:181:2: warning: (near initialization for 'omap3_vdd2_drvdata') [enabled by default] arch/arm/mach-omap2/twl-common.c: In function 'omap3_pmic_get_config': arch/arm/mach-omap2/twl-common.c:193:3: error: invalid use of undefined type 'struct twl_regulator_driver_data' arch/arm/mach-omap2/twl-common.c:198:3: error: invalid use of undefined type 'struct twl_regulator_driver_data' arch/arm/mach-omap2/twl-common.c: At top level: arch/arm/mach-omap2/twl-common.c:400:15: error: variable 'omap4_vdd1_drvdata' has initializer but incomplete type arch/arm/mach-omap2/twl-common.c:401:2: error: unknown field 'get_voltage' specified in initializer arch/arm/mach-omap2/twl-common.c:401:2: warning: excess elements in struct initializer [enabled by default] arch/arm/mach-omap2/twl-common.c:401:2: warning: (near initialization for 'omap4_vdd1_drvdata') [enabled by default] arch/arm/mach-omap2/twl-common.c:402:2: error: unknown field 'set_voltage' specified in initializer arch/arm/mach-omap2/twl-common.c:402:2: warning: excess elements in struct initializer [enabled by default] arch/arm/mach-omap2/twl-common.c:402:2: warning: (near initialization for 'omap4_vdd1_drvdata') [enabled by default] arch/arm/mach-omap2/twl-common.c:405:15: error: variable 'omap4_vdd2_drvdata' has initializer but incomplete type arch/arm/mach-omap2/twl-common.c:406:2: error: unknown field 'get_voltage' specified in initializer arch/arm/mach-omap2/twl-common.c:406:2: warning: excess elements in struct initializer [enabled by default] arch/arm/mach-omap2/twl-common.c:406:2: warning: (near initialization for 'omap4_vdd2_drvdata') [enabled by default] arch/arm/mach-omap2/twl-common.c:407:2: error: unknown field 'set_voltage' specified in initializer arch/arm/mach-omap2/twl-common.c:407:2: warning: excess elements in struct initializer [enabled by default] arch/arm/mach-omap2/twl-common.c:407:2: warning: (near initialization for 'omap4_vdd2_drvdata') [enabled by default] arch/arm/mach-omap2/twl-common.c:410:15: error: variable 'omap4_vdd3_drvdata' has initializer but incomplete type arch/arm/mach-omap2/twl-common.c:411:2: error: unknown field 'get_voltage' specified in initializer arch/arm/mach-omap2/twl-common.c:411:2: warning: excess elements in struct initializer [enabled by default] arch/arm/mach-omap2/twl-common.c:411:2: warning: (near initialization for 'omap4_vdd3_drvdata') [enabled by default] arch/arm/mach-omap2/twl-common.c:412:2: error: unknown field 'set_voltage' specified in initializer arch/arm/mach-omap2/twl-common.c:412:2: warning: excess elements in struct initializer [enabled by default] arch/arm/mach-omap2/twl-common.c:412:2: warning: (near initialization for 'omap4_vdd3_drvdata') [enabled by default] arch/arm/mach-omap2/twl-common.c: In function 'omap4_pmic_get_config': arch/arm/mach-omap2/twl-common.c:425:3: error: invalid use of undefined type 'struct twl_regulator_driver_data' arch/arm/mach-omap2/twl-common.c:431:3: error: invalid use of undefined type 'struct
[PATCH 02/12] ARM: OMAP2+: hwmod: add function to iterate over struct omap_hwmod_ocp_if
To reduce the number of lines of data in the OMAP portion of the Linux
code base, subsequent patches will remove the lists of hwmod
interconnect links from the static hwmod data. These lists will be
built dynamically during boot. To ease this transition, this patch
centralizes the way that interconnect links are iterated into a single
function, _fetch_next_ocp_if().
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 115 ++
1 files changed, 67 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 503047a..96a03d7 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -169,6 +169,29 @@ static struct omap_hwmod *mpu_oh;
/* Private functions */
/**
+ * _fetch_next_ocp_if - return @i'th OCP interface in an array
+ * @p: ptr to a ptr to the list_head inside the ocp_if to return (not yet used)
+ * @old: ptr to an array of struct omap_hwmod_ocp_if records
+ * @i: pointer to the index into the @old array
+ *
+ * Return a pointer to the next struct omap_hwmod_ocp_if record in a
+ * sequence. Currently returns a struct omap_hwmod_ocp_if record
+ * corresponding to the element index pointed to by @i in the @old
+ * array, and increments the index pointed to by @i.
+ */
+static struct omap_hwmod_ocp_if *_fetch_next_ocp_if(struct list_head **p,
+ struct omap_hwmod_ocp_if
**old,
+ int *i)
+{
+ struct omap_hwmod_ocp_if *oi;
+
+ oi = old[*i];
+ *i = *i + 1;
+
+ return oi;
+}
+
+/**
* _update_sysc_cache - return the module OCP_SYSCONFIG register, keep copy
* @oh: struct omap_hwmod *
*
@@ -582,16 +605,13 @@ static int _init_main_clk(struct omap_hwmod *oh)
*/
static int _init_interface_clks(struct omap_hwmod *oh)
{
+ struct omap_hwmod_ocp_if *os;
struct clk *c;
- int i;
+ int i = 0;
int ret = 0;
- if (oh-slaves_cnt == 0)
- return 0;
-
- for (i = 0; i oh-slaves_cnt; i++) {
- struct omap_hwmod_ocp_if *os = oh-slaves[i];
-
+ while (i oh-slaves_cnt) {
+ os = _fetch_next_ocp_if(NULL, oh-slaves, i);
if (!os-clk)
continue;
@@ -643,21 +663,19 @@ static int _init_opt_clks(struct omap_hwmod *oh)
*/
static int _enable_clocks(struct omap_hwmod *oh)
{
- int i;
+ struct omap_hwmod_ocp_if *os;
+ int i = 0;
pr_debug(omap_hwmod: %s: enabling clocks\n, oh-name);
if (oh-_clk)
clk_enable(oh-_clk);
- if (oh-slaves_cnt 0) {
- for (i = 0; i oh-slaves_cnt; i++) {
- struct omap_hwmod_ocp_if *os = oh-slaves[i];
- struct clk *c = os-_clk;
+ while (i oh-slaves_cnt) {
+ os = _fetch_next_ocp_if(NULL, oh-slaves, i);
- if (c (os-flags OCPIF_SWSUP_IDLE))
- clk_enable(c);
- }
+ if (os-_clk (os-flags OCPIF_SWSUP_IDLE))
+ clk_enable(os-_clk);
}
/* The opt clocks are controlled by the device driver. */
@@ -673,21 +691,19 @@ static int _enable_clocks(struct omap_hwmod *oh)
*/
static int _disable_clocks(struct omap_hwmod *oh)
{
- int i;
+ struct omap_hwmod_ocp_if *os;
+ int i = 0;
pr_debug(omap_hwmod: %s: disabling clocks\n, oh-name);
if (oh-_clk)
clk_disable(oh-_clk);
- if (oh-slaves_cnt 0) {
- for (i = 0; i oh-slaves_cnt; i++) {
- struct omap_hwmod_ocp_if *os = oh-slaves[i];
- struct clk *c = os-_clk;
+ while (i oh-slaves_cnt) {
+ os = _fetch_next_ocp_if(NULL, oh-slaves, i);
- if (c (os-flags OCPIF_SWSUP_IDLE))
- clk_disable(c);
- }
+ if (os-_clk (os-flags OCPIF_SWSUP_IDLE))
+ clk_disable(os-_clk);
}
/* The opt clocks are controlled by the device driver. */
@@ -997,8 +1013,9 @@ static int _get_addr_space_by_name(struct omap_hwmod *oh,
const char *name,
struct omap_hwmod_ocp_if *os;
bool found = false;
- for (i = 0; i oh-slaves_cnt; i++) {
- os = oh-slaves[i];
+ i = 0;
+ while (i oh-slaves_cnt) {
+ os = _fetch_next_ocp_if(NULL, oh-slaves, i);
if (!os-addr)
return -ENOENT;
@@ -1035,15 +1052,15 @@ static int _get_addr_space_by_name(struct omap_hwmod
*oh, const char *name,
*/
static int __init _find_mpu_port_index(struct omap_hwmod *oh)
{
- int i;
+ struct omap_hwmod_ocp_if *os;
+ int i = 0;
int found = 0;
-
[PATCH 12/12] ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP
N800 logs this message on boot:
[0.182281] omap_hwmod: iva: cannot be enabled for reset (3)
Fix by creating basic IVA1 and DSP hwmods for OMAP2420, and a basic IVA2
hwmod for OMAP2430. There is still more information to be added, but
this should resolve the immediate issue.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 46 ++--
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 11 ++-
2 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b01b66a..2c087ff 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -43,10 +43,41 @@
* IP blocks
*/
-/* IVA2 (IVA2) */
+/* IVA1 (IVA1) */
+static struct omap_hwmod_class iva1_hwmod_class = {
+ .name = iva1,
+};
+
+static struct omap_hwmod_rst_info omap2420_iva_resets[] = {
+ { .name = iva, .rst_shift = 8 },
+};
+
static struct omap_hwmod omap2420_iva_hwmod = {
.name = iva,
- .class = iva_hwmod_class,
+ .class = iva1_hwmod_class,
+ .clkdm_name = iva1_clkdm,
+ .rst_lines = omap2420_iva_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap2420_iva_resets),
+ .main_clk = iva1_ifck,
+};
+
+/* DSP */
+static struct omap_hwmod_class dsp_hwmod_class = {
+ .name = dsp,
+};
+
+static struct omap_hwmod_rst_info omap2420_dsp_resets[] = {
+ { .name = logic, .rst_shift = 0 },
+ { .name = mmu, .rst_shift = 1 },
+};
+
+static struct omap_hwmod omap2420_dsp_hwmod = {
+ .name = dsp,
+ .class = dsp_hwmod_class,
+ .clkdm_name = dsp_clkdm,
+ .rst_lines = omap2420_dsp_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap2420_dsp_resets),
+ .main_clk = dsp_fck,
};
/* I2C common */
@@ -234,7 +265,15 @@ static struct omap_hwmod_ocp_if omap2420_l4_core__i2c2 = {
static struct omap_hwmod_ocp_if omap2420_l3__iva = {
.master = omap2xxx_l3_main_hwmod,
.slave = omap2420_iva_hwmod,
- .clk= iva1_ifck,
+ .clk= core_l3_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* DSP - L3 interface */
+static struct omap_hwmod_ocp_if omap2420_l3__dsp = {
+ .master = omap2xxx_l3_main_hwmod,
+ .slave = omap2420_dsp_hwmod,
+ .clk= dsp_ick,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
@@ -402,6 +441,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[]
__initdata = {
omap2420_l4_core__i2c1,
omap2420_l4_core__i2c2,
omap2420_l3__iva,
+ omap2420_l3__dsp,
omap2420_l4_wkup__timer1,
omap2xxx_l4_core__timer2,
omap2xxx_l4_core__timer3,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 23ca551..b359bfb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -45,9 +45,18 @@
*/
/* IVA2 (IVA2) */
+static struct omap_hwmod_rst_info omap2430_iva_resets[] = {
+ { .name = logic, .rst_shift = 0 },
+ { .name = mmu, .rst_shift = 1 },
+};
+
static struct omap_hwmod omap2430_iva_hwmod = {
.name = iva,
.class = iva_hwmod_class,
+ .clkdm_name = dsp_clkdm,
+ .rst_lines = omap2430_iva_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap2430_iva_resets),
+ .main_clk = dsp_fck,
};
/* I2C common */
@@ -599,7 +608,7 @@ static struct omap_hwmod_ocp_if omap2430_l4_core__mcspi3 = {
static struct omap_hwmod_ocp_if omap2430_l3__iva = {
.master = omap2xxx_l3_main_hwmod,
.slave = omap2430_iva_hwmod,
- .clk= dsp_fck,
+ .clk= core_l3_ick,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
--
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 11/12] ARM: OMAP3: hwmod data: add IVA hard reset lines, main clock, clockdomain
The IVA hwmod data is missing some fields that cause the following
warning on boot:
[0.118011] omap_hwmod: iva: cannot be enabled for reset (3)
Fix by encoding the IP block's main functional clock, reset lines, and
clockdomain.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index c05a445..1bf1888 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -98,9 +98,19 @@ static struct omap_hwmod omap3xxx_mpu_hwmod = {
};
/* IVA2 (IVA2) */
+static struct omap_hwmod_rst_info omap3xxx_iva_resets[] = {
+ { .name = logic, .rst_shift = 0 },
+ { .name = seq0, .rst_shift = 1 },
+ { .name = seq1, .rst_shift = 2 },
+};
+
static struct omap_hwmod omap3xxx_iva_hwmod = {
.name = iva,
.class = iva_hwmod_class,
+ .clkdm_name = iva2_clkdm,
+ .rst_lines = omap3xxx_iva_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap3xxx_iva_resets),
+ .main_clk = iva2_ck,
};
/* timer class */
--
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 00/12] ARM: OMAP2+: hwmod: remove link arrays
The hwmod code and data format was originally designed to minimize boot time and for autogenerated data files. Compactness was traded for precomputation. Now that the emphasis is on reducing the number of lines in the OMAP source tree, this trade can be reversed. This series removes the precomputed link arrays from the hwmod data, and converts the code to register IP blocks by their interconnects, rather than directly. This results in a significant reduction in lines of source, at the cost of some additional boot time. The change also makes it easier to share more IP block data across SoCs. This series has a dependency on the 'hwmod_data_cleanup_3.4' branch posted earlier. This series is also available via git://git.pwsan.com/linux-2.6 in the hwmod_remove_link_arrays_cleanup_3.4 branch. Boot-tested on N800. Boot and suspend-tested on OMAP35xx Beagleboard and OMAP44xx Pandaboard. - Paul --- hwmod_remove_link_arrays_cleanup_3.4 textdata bss dec hex filename 3831449 297100 5382832 9511381 9121d5 vmlinux.omap2plus_defconfig.orig 3832257 297708 5382864 9512829 91277d vmlinux.omap2plus_defconfig Paul Walmsley (12): ARM: OMAP2+: hwmod: add _find_mpu_rt_port() ARM: OMAP2+: hwmod: add function to iterate over struct omap_hwmod_ocp_if ARM: OMAP2+: hwmod: consolidate finding the MPU port index and storing it ARM: OMAP2+: hwmod: add support for link registration ARM: OMAP2+: hwmod data: convert to link registration ARM: OMAP: hwmod: remove code support for direct hwmod registration ARM: OMAP2+: hwmod data: remove forward declarations, reorganize ARM: OMAP2xxx: hwmod data: share common hwmods between OMAP2420 and OMAP2430 ARM: OMAP2xxx: hwmod data: share common interface data ARM: OMAP3: hwmod data: fix IVA interface clock ARM: OMAP3: hwmod data: add IVA hard reset lines, main clock, clockdomain ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP arch/arm/mach-omap2/omap_hwmod.c | 410 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1563 +- arch/arm/mach-omap2/omap_hwmod_2430_data.c | 2316 ++--- .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 266 + arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 562 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 5047 +--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4882 --- arch/arm/mach-omap2/omap_hwmod_common_data.h | 71 arch/arm/plat-omap/include/plat/omap_hwmod.h | 31 9 files changed, 6324 insertions(+), 8824 deletions(-) -- 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 09/12] ARM: OMAP2xxx: hwmod data: share common interface data
Several struct omap_hwmod_ocp_if records can be shared between OMAP2420
and OMAP2430. Move these shared records out of the chip-specific files
into mach-omap2/omap_hwmod_2xxx_interconnect_data.c. This should save some
memory and source lines, at the cost of readability.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 281 +---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 256 +-
.../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 266 ++-
arch/arm/mach-omap2/omap_hwmod_common_data.h | 39 ++-
4 files changed, 324 insertions(+), 518 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 75c57d3..b01b66a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -212,85 +212,6 @@ static struct omap_hwmod omap2420_mcbsp2_hwmod = {
* interfaces
*/
-/* L3 - L4_CORE interface */
-static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
- .master = omap2xxx_l3_main_hwmod,
- .slave = omap2xxx_l4_core_hwmod,
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
-/* MPU - L3 interface */
-static struct omap_hwmod_ocp_if omap2420_mpu__l3_main = {
- .master = omap2xxx_mpu_hwmod,
- .slave = omap2xxx_l3_main_hwmod,
- .user = OCP_USER_MPU,
-};
-
-/* DSS - l3 */
-static struct omap_hwmod_ocp_if omap2420_dss__l3 = {
- .master = omap2xxx_dss_core_hwmod,
- .slave = omap2xxx_l3_main_hwmod,
- .fw = {
- .omap2 = {
- .l3_perm_bit = OMAP2_L3_CORE_FW_CONNID_DSS,
- .flags = OMAP_FIREWALL_L3,
- }
- },
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
-/* l4 core - mcspi1 interface */
-static struct omap_hwmod_ocp_if omap2420_l4_core__mcspi1 = {
- .master = omap2xxx_l4_core_hwmod,
- .slave = omap2xxx_mcspi1_hwmod,
- .clk= mcspi1_ick,
- .addr = omap2_mcspi1_addr_space,
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
-/* l4 core - mcspi2 interface */
-static struct omap_hwmod_ocp_if omap2420_l4_core__mcspi2 = {
- .master = omap2xxx_l4_core_hwmod,
- .slave = omap2xxx_mcspi2_hwmod,
- .clk= mcspi2_ick,
- .addr = omap2_mcspi2_addr_space,
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
-/* L4_CORE - L4_WKUP interface */
-static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
- .master = omap2xxx_l4_core_hwmod,
- .slave = omap2xxx_l4_wkup_hwmod,
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
-/* L4 CORE - UART1 interface */
-static struct omap_hwmod_ocp_if omap2_l4_core__uart1 = {
- .master = omap2xxx_l4_core_hwmod,
- .slave = omap2xxx_uart1_hwmod,
- .clk= uart1_ick,
- .addr = omap2xxx_uart1_addr_space,
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
-/* L4 CORE - UART2 interface */
-static struct omap_hwmod_ocp_if omap2_l4_core__uart2 = {
- .master = omap2xxx_l4_core_hwmod,
- .slave = omap2xxx_uart2_hwmod,
- .clk= uart2_ick,
- .addr = omap2xxx_uart2_addr_space,
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
-/* L4 PER - UART3 interface */
-static struct omap_hwmod_ocp_if omap2_l4_core__uart3 = {
- .master = omap2xxx_l4_core_hwmod,
- .slave = omap2xxx_uart3_hwmod,
- .clk= uart3_ick,
- .addr = omap2xxx_uart3_addr_space,
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
/* L4 CORE - I2C1 interface */
static struct omap_hwmod_ocp_if omap2420_l4_core__i2c1 = {
.master = omap2xxx_l4_core_hwmod,
@@ -335,105 +256,6 @@ static struct omap_hwmod_ocp_if omap2420_l4_wkup__timer1
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
-/* l4_core - timer2 */
-static struct omap_hwmod_ocp_if omap2420_l4_core__timer2 = {
- .master = omap2xxx_l4_core_hwmod,
- .slave = omap2xxx_timer2_hwmod,
- .clk= gpt2_ick,
- .addr = omap2xxx_timer2_addrs,
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
-/* l4_core - timer3 */
-static struct omap_hwmod_ocp_if omap2420_l4_core__timer3 = {
- .master = omap2xxx_l4_core_hwmod,
- .slave = omap2xxx_timer3_hwmod,
- .clk= gpt3_ick,
- .addr = omap2xxx_timer3_addrs,
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
-/* l4_core - timer4 */
-static struct omap_hwmod_ocp_if omap2420_l4_core__timer4 = {
- .master = omap2xxx_l4_core_hwmod,
- .slave = omap2xxx_timer4_hwmod,
- .clk
[PATCH 10/12] ARM: OMAP3: hwmod data: fix IVA interface clock
The OMAP3 hwmod data listed iva2_ck as an interface clock between the
IVA and L3. This is incorrect. iva2_ck is not an interface clock.
Since it cannot auto-idle, specifying it here prevents the IVA and at
least one of the CORE clockdomains from going idle, which causes PM
problems such as these upon system suspend:
[ 70.626129] Powerdomain (iva2_pwrdm) didn't enter target state 1
[ 70.626190] Powerdomain (core_pwrdm) didn't enter target state 1
Fix by specifying the actual interface clock in the hwmod data.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3b245e9..c05a445 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -2325,7 +2325,7 @@ static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__l4_sec
= {
static struct omap_hwmod_ocp_if omap3xxx_l3__iva = {
.master = omap3xxx_l3_main_hwmod,
.slave = omap3xxx_iva_hwmod,
- .clk= iva2_ck,
+ .clk= core_l3_ick,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
--
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 01/12] ARM: OMAP2+: hwmod: add _find_mpu_rt_port()
Most IP blocks on the OMAP SoC have an interconnect link that is
intended to be used by the MPU to communicate with the IP block.
Several parts of the hwmod code need to be able to identify this link.
Currently, this is open-coded. However, future patches will change
the way that interconnect links are represented and will make
identifying the link more complex. So to avoid code duplication, this
patch centralizes the MPU port link identification code into a new
function, _find_mpu_rt_port().
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 39 --
1 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 3462dc5..503047a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1061,6 +1061,27 @@ static int __init _find_mpu_port_index(struct omap_hwmod
*oh)
}
/**
+ * _find_mpu_rt_port - return omap_hwmod_ocp_if accessible by the MPU
+ * @oh: struct omap_hwmod *
+ *
+ * Given a pointer to a struct omap_hwmod record @oh, return a pointer
+ * to the struct omap_hwmod_ocp_if record that is used by the MPU to
+ * communicate with the IP block. This interface need not be directly
+ * connected to the MPU (and almost certainly is not), but is directly
+ * connected to the IP block represented by @oh. Returns a pointer
+ * to the struct omap_hwmod_ocp_if * upon success, or returns NULL upon
+ * error or if there does not appear to be a path from the MPU to this
+ * IP block.
+ */
+static struct omap_hwmod_ocp_if *_find_mpu_rt_port(struct omap_hwmod *oh)
+{
+ if (!oh || oh-_int_flags _HWMOD_NO_MPU_PORT || oh-slaves_cnt == 0)
+ return NULL;
+
+ return oh-slaves[oh-_mpu_port_index];
+};
+
+/**
* _find_mpu_rt_addr_space - return MPU register target address space for @oh
* @oh: struct omap_hwmod *
*
@@ -1073,10 +1094,7 @@ static struct omap_hwmod_addr_space * __init
_find_mpu_rt_addr_space(struct omap
struct omap_hwmod_addr_space *mem;
int found = 0, i = 0;
- if (!oh || oh-_int_flags _HWMOD_NO_MPU_PORT || oh-slaves_cnt == 0)
- return NULL;
-
- os = oh-slaves[oh-_mpu_port_index];
+ os = _find_mpu_rt_port(oh);
if (!os-addr)
return NULL;
@@ -1334,12 +1352,11 @@ static int _wait_target_ready(struct omap_hwmod *oh)
if (!oh)
return -EINVAL;
- if (oh-_int_flags _HWMOD_NO_MPU_PORT)
+ if (oh-flags HWMOD_NO_IDLEST)
return 0;
- os = oh-slaves[oh-_mpu_port_index];
-
- if (oh-flags HWMOD_NO_IDLEST)
+ os = _find_mpu_rt_port(oh);
+ if (!os)
return 0;
/* XXX check module SIDLEMODE */
@@ -2709,6 +2726,7 @@ int omap_hwmod_get_resource_byname(struct omap_hwmod *oh,
unsigned int type,
struct powerdomain *omap_hwmod_get_pwrdm(struct omap_hwmod *oh)
{
struct clk *c;
+ struct omap_hwmod_ocp_if *oi;
if (!oh)
return NULL;
@@ -2716,9 +2734,10 @@ struct powerdomain *omap_hwmod_get_pwrdm(struct
omap_hwmod *oh)
if (oh-_clk) {
c = oh-_clk;
} else {
- if (oh-_int_flags _HWMOD_NO_MPU_PORT)
+ oi = _find_mpu_rt_port(oh);
+ if (!oi)
return NULL;
- c = oh-slaves[oh-_mpu_port_index]-_clk;
+ c = oi-_clk;
}
if (!c-clkdm)
--
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 06/12] ARM: OMAP: hwmod: remove code support for direct hwmod registration
Now that the data has been converted to use interface registration, we
can remove the (now unused) direct hwmod registration code.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 124 +++---
arch/arm/plat-omap/include/plat/omap_hwmod.h |7 -
2 files changed, 33 insertions(+), 98 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index edbeefa..f3d264a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -173,12 +173,6 @@ static LIST_HEAD(omap_hwmod_list);
static struct omap_hwmod *mpu_oh;
/*
- * link_registration: set to true if hwmod interfaces are being registered
- * directly; set to false if hwmods are being registered directly
- */
-static bool link_registration;
-
-/*
* linkspace: ptr to a buffer that struct omap_hwmod_link records are
* allocated from - used to reduce the number of small memory
* allocations, which has a significant impact on performance
@@ -195,32 +189,22 @@ static unsigned short free_ls, max_ls, ls_supp;
/* Private functions */
/**
- * _fetch_next_ocp_if - return next OCP interface in an array or list
+ * _fetch_next_ocp_if - return the next OCP interface in a list
* @p: ptr to a ptr to the list_head inside the ocp_if to return
- * @old: ptr to an array of struct omap_hwmod_ocp_if records
- * @i: pointer to the index into the @old array
- *
- * Return a pointer to the next struct omap_hwmod_ocp_if record in a
- * sequence. If hwmods are being registered directly, then return a
- * struct omap_hwmod_ocp_if record corresponding to the element index
- * pointed to by @i in the
- * @old array. Otherwise, return a pointer to the struct
- * omap_hwmod_ocp_if record containing the struct list_head record pointed
- * to by @p, and set the pointer pointed to by @p to point to the next
- * struct list_head record in the list.
+ * @i: pointer to the index of the element pointed to by @p in the list
+ *
+ * Return a pointer to the struct omap_hwmod_ocp_if record
+ * containing the struct list_head pointed to by @p, and increment
+ * @p such that a future call to this routine will return the next
+ * record.
*/
static struct omap_hwmod_ocp_if *_fetch_next_ocp_if(struct list_head **p,
- struct omap_hwmod_ocp_if
**old,
int *i)
{
struct omap_hwmod_ocp_if *oi;
- if (!link_registration) {
- oi = old[*i];
- } else {
- oi = list_entry(*p, struct omap_hwmod_link, node)-ocp_if;
- *p = (*p)-next;
- }
+ oi = list_entry(*p, struct omap_hwmod_link, node)-ocp_if;
+ *p = (*p)-next;
*i = *i + 1;
@@ -642,16 +626,15 @@ static int _init_main_clk(struct omap_hwmod *oh)
static int _init_interface_clks(struct omap_hwmod *oh)
{
struct omap_hwmod_ocp_if *os;
- struct list_head *p = NULL;
+ struct list_head *p;
struct clk *c;
int i = 0;
int ret = 0;
- if (link_registration)
- p = oh-slave_ports.next;
+ p = oh-slave_ports.next;
while (i oh-slaves_cnt) {
- os = _fetch_next_ocp_if(p, oh-slaves, i);
+ os = _fetch_next_ocp_if(p, i);
if (!os-clk)
continue;
@@ -704,7 +687,7 @@ static int _init_opt_clks(struct omap_hwmod *oh)
static int _enable_clocks(struct omap_hwmod *oh)
{
struct omap_hwmod_ocp_if *os;
- struct list_head *p = NULL;
+ struct list_head *p;
int i = 0;
pr_debug(omap_hwmod: %s: enabling clocks\n, oh-name);
@@ -712,11 +695,10 @@ static int _enable_clocks(struct omap_hwmod *oh)
if (oh-_clk)
clk_enable(oh-_clk);
- if (link_registration)
- p = oh-slave_ports.next;
+ p = oh-slave_ports.next;
while (i oh-slaves_cnt) {
- os = _fetch_next_ocp_if(p, oh-slaves, i);
+ os = _fetch_next_ocp_if(p, i);
if (os-_clk (os-flags OCPIF_SWSUP_IDLE))
clk_enable(os-_clk);
@@ -736,7 +718,7 @@ static int _enable_clocks(struct omap_hwmod *oh)
static int _disable_clocks(struct omap_hwmod *oh)
{
struct omap_hwmod_ocp_if *os;
- struct list_head *p = NULL;
+ struct list_head *p;
int i = 0;
pr_debug(omap_hwmod: %s: disabling clocks\n, oh-name);
@@ -744,11 +726,10 @@ static int _disable_clocks(struct omap_hwmod *oh)
if (oh-_clk)
clk_disable(oh-_clk);
- if (link_registration)
- p = oh-slave_ports.next;
+ p = oh-slave_ports.next;
while (i oh-slaves_cnt) {
- os = _fetch_next_ocp_if(p, oh-slaves, i);
+ os = _fetch_next_ocp_if(p, i);
if (os-_clk (os-flags OCPIF_SWSUP_IDLE))
[PATCH 04/12] ARM: OMAP2+: hwmod: add support for link registration
Add support for direct IP block interconnect (link) registration to
the hwmod code via a new function, omap_hwmod_register_links(). This
will replace direct registration of hwmods, and a subsequent patch
will remove omap_hwmod_register().
This change will allow a subsequent patch to remove the hwmod data
link arrays. This will reduce the size of the hwmod static data and
also make it easier to generate the data files. It will also make it
possible to share some of the struct omap_hwmod records across
multiple SoCs, since the link array pointers will be removed from the
struct omap_hwmod.
The downside is that boot time will increase. Minimizing boot time
was the reason why the link arrays were originally introduced.
Removing them will require extra computation during boot to allocate
memory and associate IP blocks with their interconnects. However,
since the current kernel development focus is on reducing the number
of lines in arch/arm/mach-omap2/, boot time impact is now seemingly
considered a lower priority.
This patch contains additional complexity to reduce the number of
memory allocations required for this change. This reduces the boot
time impact: total hwmod link registration time was ~ 2655
microseconds with a simple allocation strategy, but is now ~ 549
microseconds[1] with the approach taken by this patch.
1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average
of 7 samples. Total uncertainty is +/- 61 microseconds.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 297 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h | 24 ++
2 files changed, 305 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 3c733a8..edbeefa 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -137,6 +137,7 @@
#include linux/mutex.h
#include linux/spinlock.h
#include linux/slab.h
+#include linux/bootmem.h
#include common.h
#include plat/cpu.h
@@ -159,25 +160,54 @@
/* Name of the OMAP hwmod for the MPU */
#define MPU_INITIATOR_NAME mpu
+/*
+ * Number of struct omap_hwmod_link records per struct
+ * omap_hwmod_ocp_if record (master-slave and slave-master)
+ */
+#define LINKS_PER_OCP_IF 2
+
/* omap_hwmod_list contains all registered struct omap_hwmods */
static LIST_HEAD(omap_hwmod_list);
/* mpu_oh: used to add/remove MPU initiator from sleepdep list */
static struct omap_hwmod *mpu_oh;
+/*
+ * link_registration: set to true if hwmod interfaces are being registered
+ * directly; set to false if hwmods are being registered directly
+ */
+static bool link_registration;
+
+/*
+ * linkspace: ptr to a buffer that struct omap_hwmod_link records are
+ * allocated from - used to reduce the number of small memory
+ * allocations, which has a significant impact on performance
+ */
+static struct omap_hwmod_link *linkspace;
+
+/*
+ * free_ls, max_ls: array indexes into linkspace; representing the
+ * next free struct omap_hwmod_link index, and the maximum number of
+ * struct omap_hwmod_link records allocated (respectively)
+ */
+static unsigned short free_ls, max_ls, ls_supp;
/* Private functions */
/**
- * _fetch_next_ocp_if - return @i'th OCP interface in an array
- * @p: ptr to a ptr to the list_head inside the ocp_if to return (not yet used)
+ * _fetch_next_ocp_if - return next OCP interface in an array or list
+ * @p: ptr to a ptr to the list_head inside the ocp_if to return
* @old: ptr to an array of struct omap_hwmod_ocp_if records
* @i: pointer to the index into the @old array
*
* Return a pointer to the next struct omap_hwmod_ocp_if record in a
- * sequence. Currently returns a struct omap_hwmod_ocp_if record
- * corresponding to the element index pointed to by @i in the @old
- * array, and increments the index pointed to by @i.
+ * sequence. If hwmods are being registered directly, then return a
+ * struct omap_hwmod_ocp_if record corresponding to the element index
+ * pointed to by @i in the
+ * @old array. Otherwise, return a pointer to the struct
+ * omap_hwmod_ocp_if record containing the struct list_head record pointed
+ * to by @p, and set the pointer pointed to by @p to point to the next
+ * struct list_head record in the list.
*/
static struct omap_hwmod_ocp_if *_fetch_next_ocp_if(struct list_head **p,
struct omap_hwmod_ocp_if
**old,
@@ -185,7 +215,13 @@ static struct omap_hwmod_ocp_if *_fetch_next_ocp_if(struct
list_head **p,
{
struct omap_hwmod_ocp_if *oi;
- oi = old[*i];
+ if (!link_registration) {
+ oi = old[*i];
+ } else {
+ oi = list_entry(*p, struct omap_hwmod_link, node)-ocp_if;
+ *p = (*p)-next;
+ }
+
*i = *i + 1;
return oi;
@@ -606,12 +642,16 @@ static int
