RE: [PATCH v3 2/5] OMAP4 HSMMC: Adding hsmmc support to board file
Kishore, > -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Russell > King > Sent: Saturday, May 15, 2010 3:35 AM > To: Tony Lindgren > Cc: Kadiyala, Kishore; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; > Chikkature Rajashekar, > Madhusudhan; jarkko.lavi...@nokia.com; p...@pwsan.com; adrian.hun...@nokia.com > Subject: Re: [PATCH v3 2/5] OMAP4 HSMMC: Adding hsmmc support to board file > > On Fri, May 14, 2010 at 02:56:51PM -0700, Tony Lindgren wrote: > > * kishore kadiyala [100513 13:06]: > > > Support for MMC1 & MMC2 controllers is added to the board file. > > > Also includes configuration of MMC1 Card detect initially. > > > > This patch does not seem to apply, I don't know where you're getting > > the sdp4430_vmmc_supply in this patch? > > > > I suggest you forget about the card detect patches for now and > > first produce a minimal set of patches to get the MMC working > > for board-4430sdp.c. The card detect patches should be applied > > only after board-4430sdp.c works for MMC. And we're running out > > of time for this merge window. > > Absolutely - we _really_ _really_ _really_ need to get MMC usable > on the 4430SDP for this merge window - don't care about the card > detection provided the system can find a MMC card which is left > plugged in. > > To do this makes the overall 4430SDP more usable than it currently > is with mainline kernels. > Why is it taking so much time to get 4-5 patches in shape for mainline?? What is expected is just basic MMC support and no advance features yet. 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] OMAP3: musb: remove unneeded include files
Removed include files from usb-musb.c which were not required. Signed-off-by: Ajay Kumar Gupta --- Patch created against latest linux-omap/master. arch/arm/mach-omap2/usb-musb.c |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c index 63104dd..1929f3b 100644 --- a/arch/arm/mach-omap2/usb-musb.c +++ b/arch/arm/mach-omap2/usb-musb.c @@ -16,19 +16,11 @@ * published by the Free Software Foundation. */ -#include -#include -#include #include -#include #include -#include - #include -#include #include -#include #include #ifdef CONFIG_USB_MUSB_SOC -- 1.6.2.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] OMAP3: musb: remove unneeded inits in musb_plat
Removed unneeded 'power' and 'mode' field from musb_config as
they are now getting updated by the values provided from board
files at usb_musb_init().
Signed-off-by: Ajay Kumar Gupta
---
Patch created against today's linux-omap/master.
arch/arm/mach-omap2/usb-musb.c | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 6d41fa7..63104dd 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -55,21 +55,8 @@ static struct musb_hdrc_config musb_config = {
};
static struct musb_hdrc_platform_data musb_plat = {
-#ifdef CONFIG_USB_MUSB_OTG
- .mode = MUSB_OTG,
-#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
- .mode = MUSB_HOST,
-#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
- .mode = MUSB_PERIPHERAL,
-#endif
/* .clock is set dynamically */
.config = &musb_config,
-
- /* REVISIT charge pump on TWL4030 can supply up to
-* 100 mA ... but this value is board-specific, like
-* "mode", and should be passed to usb_musb_init().
-*/
- .power = 50, /* up to 100 mA */
};
static u64 musb_dmamask = DMA_BIT_MASK(32);
--
1.6.2.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] musb: host: release dma channels if no active io
Currently DMA channels are allocated and they remain allocated
even if there is no active data transfer. Added channel_release()
whenever there is no pending request.
Signed-off-by: Ajay Kumar Gupta
---
This patch is against today's linus's tree.
drivers/usb/musb/musb_host.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 877d20b..d78b887 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -387,11 +387,21 @@ static void musb_advance_schedule(struct musb *musb,
struct urb *urb,
*/
if (list_empty(&qh->hep->urb_list)) {
struct list_head*head;
+ struct dma_controller *dma = musb->dma_controller;
- if (is_in)
+ if (is_in) {
ep->rx_reinit = 1;
- else
+ if (ep->rx_channel) {
+ dma->channel_release(ep->rx_channel);
+ ep->rx_channel = NULL;
+ }
+ } else {
ep->tx_reinit = 1;
+ if (ep->tx_channel) {
+ dma->channel_release(ep->tx_channel);
+ ep->tx_channel = NULL;
+ }
+ }
/* Clobber old pointers to this qh */
musb_ep_set_qh(ep, is_in, NULL);
--
1.6.2.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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Fri, May 14, 2010 at 7:35 PM, Alan Stern wrote: > On Fri, 14 May 2010, Rafael J. Wysocki wrote: > >> > > How do you handle situations where the CPU is currently idle but an >> > > event (such as I/O completion) is expected to occur in the near future? >> > > You don't want to power-off and reboot then, do you? >> > >> > The idle code looks at next_timer_interrupt() value, then if the >> > next timer event if far enough ahead, the system powers down and >> > wakes to the timer interrupt. It also wakes to device interrupts. >> >> For the record, waking to interrupts doesn't work on quite some systems >> (like ACPI-based PCs for one example). > > Ironically, it appears that ACPI-based PCs are in a position to benefit > more from opportunistic suspend and suspend blockers than are embedded > systems -- and yet they are being proposed for use on cell phones > rather than on desktops. > I would also use it on a desktop. -- Arve Hjønnevåg -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Fri, May 14, 2010 at 7:58 PM, Alan Stern wrote: > On Fri, 14 May 2010, Brian Swetland wrote: > >> It provides useful functionality -- you apparently disagree, but the >> wakelock/suspendblock model is in use, shipping, and solving problems >> for quite a lot of android devices that have been shipping for a while >> now. We actively go to lowest power state in idle (on omap, msm, >> etc), and use drivers that aggressively declock and depower modules >> (similar to runtime pm), but we have found that using the >> opportunistic suspend model combined with wakelocks allows us to >> attain even lower average power consumption in always-connected, >> actively-syncing devices. > > Can you explain this in more detail? Are you saying that some devices > go on generating interrupts and causing timers to be scheduled, even > though what they're doing isn't important enough to prevent the system > from powering down? In tickless mode, the time until next timer is a signed int, so the longest the kernel will ever sleep is ~2 seconds at a go. In practice, userspace entities often have polling behavior that can trigger more often than that, and I've observed some kernel periodic timers (haven't cataloged them recently) that happen more often than once a second. When we go to full suspend, we know that only specific wakeup sources (keyboard gpios, baseband voice/ip events, rtc alarms, etc) are going to wake us up. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Fri, 14 May 2010, Brian Swetland wrote: > It provides useful functionality -- you apparently disagree, but the > wakelock/suspendblock model is in use, shipping, and solving problems > for quite a lot of android devices that have been shipping for a while > now. We actively go to lowest power state in idle (on omap, msm, > etc), and use drivers that aggressively declock and depower modules > (similar to runtime pm), but we have found that using the > opportunistic suspend model combined with wakelocks allows us to > attain even lower average power consumption in always-connected, > actively-syncing devices. Can you explain this in more detail? Are you saying that some devices go on generating interrupts and causing timers to be scheduled, even though what they're doing isn't important enough to prevent the system from powering down? Alan Stern -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Fri, 14 May 2010, Magnus Damm wrote: > I agree with you Tony. I thought shutting down CPUs for power > managment purposes could be done without freezing user space. At least > that's what we do today with SH-Mobile. If you can shut down and restart CPUs in the time periods between transitions into and out of the idle loop, then yes -- userspace doesn't need to be suspended. After all, if the idle loop is running then no user threads are runnable. (Not necessarily true on SMP systems, but you know what I mean.) > Still not sure how the system wide suspend is different from Runtime > PM and CPUidle from the hardware perspective... For embedded systems, apparently the difference is minimal. For other systems, like ACPI-based PCs, there is a big difference: Powering down devices and CPUs still leaves large parts of the system running. In addition, these larger systems generally don't have aggressive runtime PM support, so a significant fraction (maybe more than 50%) of devices won't be powered down when they are idle -- whereas system suspend powers virtually everything down. Alan Stern -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Fri, 14 May 2010, Rafael J. Wysocki wrote: > > > How do you handle situations where the CPU is currently idle but an > > > event (such as I/O completion) is expected to occur in the near future? > > > You don't want to power-off and reboot then, do you? > > > > The idle code looks at next_timer_interrupt() value, then if the > > next timer event if far enough ahead, the system powers down and > > wakes to the timer interrupt. It also wakes to device interrupts. > > For the record, waking to interrupts doesn't work on quite some systems > (like ACPI-based PCs for one example). Ironically, it appears that ACPI-based PCs are in a position to benefit more from opportunistic suspend and suspend blockers than are embedded systems -- and yet they are being proposed for use on cell phones rather than on desktops. Alan Stern -- 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 v2] musb: add musb support for AM35x
Hi,
> Ajay Kumar Gupta wrote:
> > AM35x is based on OMAP35x but has an updated musb interface which
> > uses CPPI4.1 DMA engine.
> >
> > Current patch supports only PIO mode transfers.
> >
> > Signed-off-by: Ajay Kumar Gupta
> > ---
> > Changes from v1: (Based on Sergei's comment)
> > - Moved PHY clock and OTGMODE settings to board files
> > - Added clk_disable/put in exit path
> > - Removed unwanted code related to vbus
> > - Removed unhandled interrupt check
> > - Added timeout in phy_on()
> > I had to use MACH_OMAP3517EVM as there is no ARCH_xxx config specific to
> > AM3517 platforms other than ARCH_OMAP3.
> >
> > drivers/usb/musb/Kconfig | 4 +-
> > drivers/usb/musb/Makefile | 4 +
> > drivers/usb/musb/am3517.c | 517
[..]
> > +
> > +static inline void phy_on(void)
> > +{
> > + unsigned long timeout = jiffies + msecs_to_jiffies(100);
> > + u32 devconf2;
> > +
> > + /*
> > + * Start the on-chip PHY and its PLL.
> > + */
> > + devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
> > +
> > + devconf2 &= ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN |
> > + CONF2_PHY_GPIOMODE);
> > + devconf2 |= CONF2_PHY_PLLON | CONF2_DATPOL;
> > +
> > + omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
> > +
> > + DBG(1, "Waiting for PHY clock good...\n");
> > + while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
> > + & CONF2_PHYCLKGD)) {
> > + cpu_relax();
> > +
> > + if (time_after(jiffies, timeout)) {
> > + DBG(1, "musb PHY clock good timed out\n");
> > + return;
> A 'break' would have been more appropriate.
Why?
'break' would bring in additional instruction and finally it would
return as the loop is already at the bottom of the function.
>
> > + }
> > + }
> > +}
> > +
[..]
> > +int musb_platform_set_mode(struct musb *musb, u8 musb_mode)
> > +{
> > + u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
> > +
> > + devconf2 &= ~CONF2_OTGMODE;
> > + switch (musb_mode) {
> > +#ifdef CONFIG_USB_MUSB_HDRC_HCD
> > + case MUSB_HOST: /* Force VBUS valid, ID = 0 */
> > + devconf2 |= CONF2_FORCE_HOST;
> > + break;
> > +#endif
> > +#ifdef CONFIG_USB_GADGET_MUSB_HDRC
> > + case MUSB_PERIPHERAL: /* Force VBUS valid, ID = 1 */
> > + devconf2 |= CONF2_FORCE_DEVICE;
> > + break;
> > +#endif
> > +#ifdef CONFIG_USB_MUSB_OTG
> > + case MUSB_OTG: /* Don't override the VBUS/ID
> comparators */
> > + devconf2 |= CONF2_NO_OVERRIDE;
> > + break;
> > +#endif
> > + default:
> > + DBG(2, "Trying to set unsupported mode %u\n",
> musb_mode);
> > + }
> Either the switch case or the compile time flag is redundant.
No. both has to be there.
'musb_mode' is an entry from user via sysfs for changing the
operating mode and if some modes are not even configured in
kernel then we should not switch the mode and also warn the
user for this.
Ajay
>
> > +
> > + omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
> > + return 0;
[..]
--
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 1/2] omap3 nand: cleanup for not to use GPMC virtual address
Few more comments below.
* Sukumar Ghorai [100514 08:18]:
> +
> +/**
> + * gmpc_ecc_init - Initialize the HW ECC for NAND flash in GPMC controller
> + * @cs: Chip select number
> + * @ecc_size: bytes for which ECC will be generated
> + */
> +void gpmc_ecc_init(int cs, int ecc_size)
> +{
> + unsigned int val = 0x0;
> +
> + /* Read from ECC Control Register */
> + val = gpmc_read_reg(GPMC_ECC_CONTROL);
> +
> + /* Clear all ECC | Enable Reg1 */
> + val = ((0x0001<<8) | 0x0001);
> + gpmc_write_reg(GPMC_ECC_CONTROL, val);
> +
> + /* Read from ECC Size Config Register */
> + val = gpmc_read_reg(GPMC_ECC_SIZE_CONFIG);
> + /* ECCSIZE1=512 | Select eccResultsize[0-3] */
> + val = ecc_size >> 1) - 1) << 22) | (0x000F));
> + gpmc_write_reg(GPMC_ECC_SIZE_CONFIG, val);
> +}
There should be some locking as only one chipselect can use
the ECC or prefetch engine at a time. If you have NAND in
two chipselects, bad things would happen..
Maybe something like:
int gpmc_ecc_request(int cs);
void gpmc_ecc_free(int cs);
int gpmc_prefetch_request(int cs);
void gpmc_prefetch_free(int cs);
Other than that, looks like a good clean-up so we can easily
add the platform init code for all the board files.
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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Fri, May 14, 2010 at 3:45 PM, Kevin Hilman wrote: >>> Personally, I suspect that lack of this feature is not the real >>> obstacle to getting these out-of-tree drivers upstream. Having this >>> API upstream will not change the product schedules and corporate >>> cultures that have prevented code from making its way upstream. >> >> But apparently it is considered as a suitable excuse. > > No, it is not a _technical_ excuse. Just a healthy, experience-based > dose of skepticism. > > It was expressed because I find the arguments above for merging > because it prevents out-of-tree drivers from merging quite > unconvincing. This is not just about opportunistic suspend + suspend > blockers specifically but comes from several years experience in the > embedded Linux world. It provides useful functionality -- you apparently disagree, but the wakelock/suspendblock model is in use, shipping, and solving problems for quite a lot of android devices that have been shipping for a while now. We actively go to lowest power state in idle (on omap, msm, etc), and use drivers that aggressively declock and depower modules (similar to runtime pm), but we have found that using the opportunistic suspend model combined with wakelocks allows us to attain even lower average power consumption in always-connected, actively-syncing devices. It has been claimed that because Android userspace makes use of this functionality a number of silicon vendors who want to submit code upstream are inconvenienced by having to maintain "android" and "mainline" versions of their drivers. I can't speak for them, since nobody has identified the particular inconvenienced vendors to me, nor have they spoken with me directly, but personally I do find that having to maintain two different versions of drivers (one version for upstream, one for shipping products) is inconvenient. 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: [PATCH] MMC: OMAP HS-MMC: convert to dev_pm_ops
On Fri, May 14, 2010 at 09:51:21AM -0700, Kevin Hilman wrote: > > I don't see a reason either, but it requires patching the MMC core as > well as all the users. As I'm not an MMC core person, I thought this > best left to someone in that domain. > > Fixing the core and callers could easily be done on top of this patch. I've sent a patch that fixes up all the callers now and Andrew has taken it into -mm. -- 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: iommu- update ducati mmu irq define name
2.6.34-rc6 kernel has the Ducati mmu irq define name changed, which is
resulting in compilation error.
Signed-off-by: Hari Kanigeri
---
arch/arm/mach-omap2/omap-iommu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index eb9bee7..f5a1aad 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -59,7 +59,7 @@ static struct platform_device
*omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
static struct iommu_device omap4_devices[] = {
{
.base = OMAP4_MMU1_BASE,
- .irq = INT_44XX_DUCATI_MMU_IRQ,
+ .irq = OMAP44XX_IRQ_DUCATI_MMU,
.pdata = {
.name = "ducati",
.nr_tlb_entries = 32,
--
1.7.0
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
"Rafael J. Wysocki" writes: > On Friday 14 May 2010, Kevin Hilman wrote: >> Kevin Hilman writes: >> >> > "Rafael J. Wysocki" writes: >> > >> >> On Thursday 13 May 2010, Tony Lindgren wrote: >> >>> * Rafael J. Wysocki [100513 14:16]: >> > >> > [...] >> > >> >>> >> >>> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved >> >>> > differently, while there's a growing number of out-of-tree drivers >> >>> > depending >> >>> > on this framework. We need those drivers in and because we don't have >> >>> > any >> >>> > viable alternative at hand, we have no good reason to reject it. >> >>> >> >>> Nothing is preventing merging the drivers can be merged without >> >>> these calls. >> >> >> >> And yet, there _is_ a growing nuber of drivers that don't get merge >> >> because >> >> of that. That's _reality_. Are you going to discuss with facts, or what? >> > >> > It may be reality, but IMO, "preventing other drivers" isn't a good >> > *technical* argument for merging a feature. It feels like these "for >> > the 'good' of the community" arguments are being used to trump the >> > technical arguments. Maybe we need to keep the separate. >> >> To continue along the "for the good of the community" path... >> >> If it truly is the lack of a suspend blocker API that is preventing >> the merge of these out of tree drivers, I second Mark's proposal[1] to >> merge a noop version of the API while the technical issues continue to >> be discussed. > > I'm against that, sorry. OK, I'll bite... Why? >> Then we would see how many drivers get submitted and merged. >> >> Personally, I suspect that lack of this feature is not the real >> obstacle to getting these out-of-tree drivers upstream. Having this >> API upstream will not change the product schedules and corporate >> cultures that have prevented code from making its way upstream. > > But apparently it is considered as a suitable excuse. No, it is not a _technical_ excuse. Just a healthy, experience-based dose of skepticism. It was expressed because I find the arguments above for merging because it prevents out-of-tree drivers from merging quite unconvincing. This is not just about opportunistic suspend + suspend blockers specifically but comes from several years experience in the embedded Linux world. Kevin -- 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 08/17] omap: mailbox: only compile for configured archs
On Sat, May 15, 2010 at 12:27 AM, Kanigeri, Hari wrote:
>>
>> - if (cpu_is_omap3430()) {
>> + if (false);
>
> -- Is this statement needed ?
Yeah, so:
if (false);
#if 0
else if (foo) {
}
#endif
else {
return -1;
}
Works.
--
Felipe Contreras
--
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 2/5] OMAP4 HSMMC: Adding hsmmc support to board file
On Fri, May 14, 2010 at 02:56:51PM -0700, Tony Lindgren wrote: > * kishore kadiyala [100513 13:06]: > > Support for MMC1 & MMC2 controllers is added to the board file. > > Also includes configuration of MMC1 Card detect initially. > > This patch does not seem to apply, I don't know where you're getting > the sdp4430_vmmc_supply in this patch? > > I suggest you forget about the card detect patches for now and > first produce a minimal set of patches to get the MMC working > for board-4430sdp.c. The card detect patches should be applied > only after board-4430sdp.c works for MMC. And we're running out > of time for this merge window. Absolutely - we _really_ _really_ _really_ need to get MMC usable on the 4430SDP for this merge window - don't care about the card detection provided the system can find a MMC card which is left plugged in. To do this makes the overall 4430SDP more usable than it currently is with mainline kernels. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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 2/5] OMAP4 HSMMC: Adding hsmmc support to board file
* kishore kadiyala [100513 13:06]:
> Support for MMC1 & MMC2 controllers is added to the board file.
> Also includes configuration of MMC1 Card detect initially.
This patch does not seem to apply, I don't know where you're getting
the sdp4430_vmmc_supply in this patch?
I suggest you forget about the card detect patches for now and
first produce a minimal set of patches to get the MMC working
for board-4430sdp.c. The card detect patches should be applied
only after board-4430sdp.c works for MMC. And we're running out
of time for this merge window.
Regards,
Tony
> Signed-off-by: Kishore Kadiyala
> ---
> arch/arm/mach-omap2/Makefile|3 +-
> arch/arm/mach-omap2/board-4430sdp.c | 64
> +++
> include/linux/i2c/twl.h | 44
> 3 files changed, 103 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index ffe600a..65d8d11 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -140,7 +140,8 @@ obj-$(CONFIG_MACH_IGEP0020) +=
> board-igep0020.o \
> hsmmc.o
> obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
> hsmmc.o
> -obj-$(CONFIG_MACH_OMAP_4430SDP) += board-4430sdp.o
> +obj-$(CONFIG_MACH_OMAP_4430SDP) += board-4430sdp.o \
> +hsmmc.o
>
> obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
>
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c
> b/arch/arm/mach-omap2/board-4430sdp.c
> index d86e22d..70c8ab7 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -32,6 +32,8 @@
> #include
> #include
> #include
> +#include
> +#include "hsmmc.h"
>
> static struct platform_device sdp4430_lcd_device = {
> .name = "sdp4430_lcd",
> @@ -68,24 +70,71 @@ static struct omap_musb_board_data musb_board_data = {
> .power = 100,
> };
>
> -static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
> - {
> - .supply = "vmmc",
> - },
> +static struct omap2_hsmmc_info mmc[] = {
> {
> - .supply = "vmmc",
> + .mmc= 1,
> + .wires = 8,
> + .gpio_cd= TWL6030_IRQ_BASE + MMCDETECT_INTR_OFFSET,
> + .cd_type= NON_GPIO,
> + .gpio_wp= -EINVAL,
> },
> {
> - .supply = "vmmc",
> + .mmc= 2,
> + .wires = 8,
> + .gpio_cd= -EINVAL,
> + .gpio_wp= -EINVAL,
> + .nonremovable = true,
> },
> + {} /* Terminator */
> +};
> +
> +static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
> {
> .supply = "vmmc",
> + .dev_name = "mmci-omap-hs.0",
> },
> {
> .supply = "vmmc",
> + .dev_name = "mmci-omap-hs.1",
> },
> };
>
> +static int omap4_twl6030_hsmmc_late_init(struct device *dev)
> +{
> + int ret = 0;
> + struct platform_device *pdev = container_of(dev,
> + struct platform_device, dev);
> + struct omap_mmc_platform_data *pdata = dev->platform_data;
> +
> + /* MMC1 Card detect Configuration */
> + if (pdev->id == 0) {
> + ret = omap4_hsmmc1_card_detect_config();
> + if (ret < 0)
> + pr_err("Unable to configure Card detect for MMC1\n");
> + pdata->slots[0].card_detect_irq = TWL6030_IRQ_BASE +
> + MMCDETECT_INTR_OFFSET;
> + }
> + return ret;
> +}
> +
> +static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
> +{
> + struct omap_mmc_platform_data *pdata = dev->platform_data;
> +
> + pdata->init = omap4_twl6030_hsmmc_late_init;
> +}
> +
> +static int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info
> *controllers)
> +{
> + struct omap2_hsmmc_info *c;
> +
> + omap2_hsmmc_init(controllers);
> + for (c = controllers; c->mmc; c++)
> + omap4_twl6030_hsmmc_set_late_init(c->dev);
> +
> + return 0;
> +}
> +
> static struct regulator_init_data sdp4430_vaux1 = {
> .constraints = {
> .min_uV = 100,
> @@ -137,7 +186,7 @@ static struct regulator_init_data sdp4430_vmmc = {
> | REGULATOR_CHANGE_MODE
> | REGULATOR_CHANGE_STATUS,
> },
> - .num_consumer_supplies = 5,
> + .num_consumer_supplies = 2,
> .consumer_supplies = sdp4430_vmmc_supply,
> };
>
> @@ -256,6 +305,7 @@ static void __init omap_4430sdp_init(void)
> omap4_i2c_init();
> platform_add_devices(sdp4430_devices, ARRAY_SIZE(sd
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Friday 14 May 2010, Kevin Hilman wrote: > Kevin Hilman writes: > > > "Rafael J. Wysocki" writes: > > > >> On Thursday 13 May 2010, Tony Lindgren wrote: > >>> * Rafael J. Wysocki [100513 14:16]: > > > > [...] > > > >>> > >>> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved > >>> > differently, while there's a growing number of out-of-tree drivers > >>> > depending > >>> > on this framework. We need those drivers in and because we don't have > >>> > any > >>> > viable alternative at hand, we have no good reason to reject it. > >>> > >>> Nothing is preventing merging the drivers can be merged without > >>> these calls. > >> > >> And yet, there _is_ a growing nuber of drivers that don't get merge because > >> of that. That's _reality_. Are you going to discuss with facts, or what? > > > > It may be reality, but IMO, "preventing other drivers" isn't a good > > *technical* argument for merging a feature. It feels like these "for > > the 'good' of the community" arguments are being used to trump the > > technical arguments. Maybe we need to keep the separate. > > To continue along the "for the good of the community" path... > > If it truly is the lack of a suspend blocker API that is preventing > the merge of these out of tree drivers, I second Mark's proposal[1] to > merge a noop version of the API while the technical issues continue to > be discussed. I'm against that, sorry. > Then we would see how many drivers get submitted and merged. > > Personally, I suspect that lack of this feature is not the real > obstacle to getting these out-of-tree drivers upstream. Having this > API upstream will not change the product schedules and corporate > cultures that have prevented code from making its way upstream. But apparently it is considered as a suitable excuse. Rafael -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
Kevin Hilman writes: > "Rafael J. Wysocki" writes: > >> On Thursday 13 May 2010, Tony Lindgren wrote: >>> * Rafael J. Wysocki [100513 14:16]: > > [...] > >>> >>> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved >>> > differently, while there's a growing number of out-of-tree drivers >>> > depending >>> > on this framework. We need those drivers in and because we don't have any >>> > viable alternative at hand, we have no good reason to reject it. >>> >>> Nothing is preventing merging the drivers can be merged without >>> these calls. >> >> And yet, there _is_ a growing nuber of drivers that don't get merge because >> of that. That's _reality_. Are you going to discuss with facts, or what? > > It may be reality, but IMO, "preventing other drivers" isn't a good > *technical* argument for merging a feature. It feels like these "for > the 'good' of the community" arguments are being used to trump the > technical arguments. Maybe we need to keep the separate. To continue along the "for the good of the community" path... If it truly is the lack of a suspend blocker API that is preventing the merge of these out of tree drivers, I second Mark's proposal[1] to merge a noop version of the API while the technical issues continue to be discussed. Then we would see how many drivers get submitted and merged. Personally, I suspect that lack of this feature is not the real obstacle to getting these out-of-tree drivers upstream. Having this API upstream will not change the product schedules and corporate cultures that have prevented code from making its way upstream. Kevin [1] https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025501.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 0/3] Some am3517 related patches [V4]
* Stanley.Miao [100513 05:24]: > Changes from V3: > 1, refresh the the patches against the current omap-for-linus branch > 2, Added "features" in mmc->slot[i]. > > Stanley.Miao (3): > AM3517: rename the i2c boardinfo to make it more readable > omap: init the gpio pinmux for mmc > omap hsmmc: fix the hsmmc driver for am3517 > > arch/arm/mach-omap2/board-am3517evm.c | 20 ++-- > arch/arm/mach-omap2/devices.c |9 + > arch/arm/mach-omap2/hsmmc.c | 27 +-- > arch/arm/plat-omap/include/plat/mmc.h |4 > 4 files changed, 44 insertions(+), 16 deletions(-) Thanks, I've added all three into omap for-next branch. 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
[PATCH 06/10] OMAP4: Ethernet: KS8851 Board Support
From: Abraham Arce
Enable Micrel KS8851 SPI network chip for OMAP4430
Signed-off-by: Abraham Arce
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c | 81 +++
1 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index b88f28c..be7a786 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -32,6 +33,75 @@
#include
#include
+#define ETH_KS8851_IRQ 34
+#define ETH_KS8851_POWER_ON48
+#define ETH_KS8851_QUART 138
+
+static struct spi_board_info sdp4430_spi_board_info[] __initdata = {
+ {
+ .modalias = "ks8851",
+ .bus_num= 1,
+ .chip_select= 0,
+ .max_speed_hz = 2400,
+ .irq= ETH_KS8851_IRQ,
+ },
+};
+
+static int omap_ethernet_init(void)
+{
+ int status;
+
+ /* Request of GPIO lines */
+
+ status = gpio_request(ETH_KS8851_POWER_ON, "eth_power");
+ if (status) {
+ pr_err("Cannot request GPIO %d\n", ETH_KS8851_POWER_ON);
+ return status;
+ }
+
+ status = gpio_request(ETH_KS8851_QUART, "quart");
+ if (status) {
+ pr_err("Cannot request GPIO %d\n", ETH_KS8851_QUART);
+ goto error1;
+ }
+
+ status = gpio_request(ETH_KS8851_IRQ, "eth_irq");
+ if (status) {
+ pr_err("Cannot request GPIO %d\n", ETH_KS8851_IRQ);
+ goto error2;
+ }
+
+ /* Configuration of requested GPIO lines */
+
+ status = gpio_direction_output(ETH_KS8851_POWER_ON, 1);
+ if (status) {
+ pr_err("Cannot set output GPIO %d\n", ETH_KS8851_IRQ);
+ goto error3;
+ }
+
+ status = gpio_direction_output(ETH_KS8851_QUART, 1);
+ if (status) {
+ pr_err("Cannot set output GPIO %d\n", ETH_KS8851_QUART);
+ goto error3;
+ }
+
+ status = gpio_direction_input(ETH_KS8851_IRQ);
+ if (status) {
+ pr_err("Cannot set input GPIO %d\n", ETH_KS8851_IRQ);
+ goto error3;
+ }
+
+ return 0;
+
+error3:
+ gpio_free(ETH_KS8851_IRQ);
+error2:
+ gpio_free(ETH_KS8851_QUART);
+error1:
+ gpio_free(ETH_KS8851_POWER_ON);
+ return status;
+}
+
static struct platform_device sdp4430_lcd_device = {
.name = "sdp4430_lcd",
.id = -1,
@@ -113,6 +183,8 @@ static struct omap_musb_board_data musb_board_data = {
static void __init omap_4430sdp_init(void)
{
+ int status;
+
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
/* OMAP4 SDP uses internal transceiver so register nop transceiver */
@@ -120,6 +192,15 @@ static void __init omap_4430sdp_init(void)
/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
if (!cpu_is_omap44xx())
usb_musb_init(&musb_board_data);
+
+ status = omap_ethernet_init();
+ if (status) {
+ pr_err("Ethernet initialization failed: %d\n", status);
+ } else {
+ sdp4430_spi_board_info[0].irq = gpio_to_irq(ETH_KS8851_IRQ);
+ spi_register_board_info(sdp4430_spi_board_info,
+ ARRAY_SIZE(sdp4430_spi_board_info));
+ }
}
static void __init omap_4430sdp_map_io(void)
--
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 10/10] AM3517: rename the i2c boardinfo to make it more readable
From: stanley.miao
There are three i2c buses on am3517, and each i2c bus has several devices
on it, so we can't name the i2c boardinfo structures with one of these
devices. In order to make it more readable, now rename these three boardinfo
structures based on i2c indexes.
Signed-off-by: Stanley.Miao
Acked-By: Vaibhav Hiremath
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-am3517evm.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 19b9e41..af383a8 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -136,7 +136,7 @@ void am3517_evm_ethernet_init(struct emac_platform_data
*pdata)
#define LCD_PANEL_BKLIGHT_PWR 182
#define LCD_PANEL_PWM 181
-static struct i2c_board_info __initdata am3517evm_i2c_boardinfo[] = {
+static struct i2c_board_info __initdata am3517evm_i2c1_boardinfo[] = {
{
I2C_BOARD_INFO("s35390a", 0x30),
.type = "s35390a",
@@ -166,7 +166,7 @@ static void __init am3517_evm_rtc_init(void)
gpio_free(GPIO_RTCS35390A_IRQ);
return;
}
- am3517evm_i2c_boardinfo[0].irq = gpio_to_irq(GPIO_RTCS35390A_IRQ);
+ am3517evm_i2c1_boardinfo[0].irq = gpio_to_irq(GPIO_RTCS35390A_IRQ);
}
/*
@@ -177,7 +177,7 @@ static void __init am3517_evm_rtc_init(void)
static struct pca953x_platform_data am3517evm_gpio_expander_info_0 = {
.gpio_base = OMAP_MAX_GPIO_LINES,
};
-static struct i2c_board_info __initdata am3517evm_tca6416_info_0[] = {
+static struct i2c_board_info __initdata am3517evm_i2c2_boardinfo[] = {
{
I2C_BOARD_INFO("tca6416", 0x21),
.platform_data = &am3517evm_gpio_expander_info_0,
@@ -191,7 +191,7 @@ static struct pca953x_platform_data
am3517evm_ui_gpio_expander_info_1 = {
static struct pca953x_platform_data am3517evm_ui_gpio_expander_info_2 = {
.gpio_base = OMAP_MAX_GPIO_LINES + 32,
};
-static struct i2c_board_info __initdata am3517evm_ui_tca6416_info[] = {
+static struct i2c_board_info __initdata am3517evm_i2c3_boardinfo[] = {
{
I2C_BOARD_INFO("tca6416", 0x20),
.platform_data = &am3517evm_ui_gpio_expander_info_1,
@@ -205,10 +205,10 @@ static struct i2c_board_info __initdata
am3517evm_ui_tca6416_info[] = {
static int __init am3517_evm_i2c_init(void)
{
omap_register_i2c_bus(1, 400, NULL, 0);
- omap_register_i2c_bus(2, 400, am3517evm_tca6416_info_0,
- ARRAY_SIZE(am3517evm_tca6416_info_0));
- omap_register_i2c_bus(3, 400, am3517evm_ui_tca6416_info,
- ARRAY_SIZE(am3517evm_ui_tca6416_info));
+ omap_register_i2c_bus(2, 400, am3517evm_i2c2_boardinfo,
+ ARRAY_SIZE(am3517evm_i2c2_boardinfo));
+ omap_register_i2c_bus(3, 400, am3517evm_i2c3_boardinfo,
+ ARRAY_SIZE(am3517evm_i2c3_boardinfo));
return 0;
}
@@ -455,8 +455,8 @@ static void __init am3517_evm_init(void)
/* RTC - S35390A */
am3517_evm_rtc_init();
- i2c_register_board_info(1, am3517evm_i2c_boardinfo,
- ARRAY_SIZE(am3517evm_i2c_boardinfo));
+ i2c_register_board_info(1, am3517evm_i2c1_boardinfo,
+ ARRAY_SIZE(am3517evm_i2c1_boardinfo));
/*Ethernet*/
am3517_evm_ethernet_init(&am3517_evm_emac_pdata);
}
--
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/10] omap4: Move SOC specific code from board file
From: Santosh Shilimkar
This patch moves OMAP4 soc specific code from 4430sdp board file.
The change is necessary so that newer board support can be added
with minimal changes. This will be also problematic for
multi-board, multi-omap builds.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Makefile|2 -
arch/arm/mach-omap2/board-4430sdp.c | 47 ---
arch/arm/mach-omap2/include/mach/omap4-common.h | 26
arch/arm/mach-omap2/omap-smp.c |2 -
arch/arm/mach-omap2/omap4-common.c | 72 +++
arch/arm/plat-omap/common.c |3 -
arch/arm/plat-omap/include/plat/common.h|3 -
7 files changed, 101 insertions(+), 54 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/omap4-common.h
create mode 100644 arch/arm/mach-omap2/omap4-common.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 7d2cf0f..203a414 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -22,7 +22,7 @@ obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
# SMP support ONLY available for OMAP4
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
obj-$(CONFIG_LOCAL_TIMERS) += timer-mpu.o
-obj-$(CONFIG_ARCH_OMAP4) += omap44xx-smc.o
+obj-$(CONFIG_ARCH_OMAP4) += omap44xx-smc.o omap4-common.o
AFLAGS_omap44xx-smc.o :=-Wa,-march=armv7-a
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index be7a786..6cce6f2 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include
#include
#include
@@ -30,8 +31,6 @@
#include
#include
#include
-#include
-#include
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON48
@@ -119,50 +118,6 @@ static struct omap_board_config_kernel sdp4430_config[]
__initdata = {
{ OMAP_TAG_LCD, &sdp4430_lcd_config },
};
-#ifdef CONFIG_CACHE_L2X0
-static int __init omap_l2_cache_init(void)
-{
- extern void omap_smc1(u32 fn, u32 arg);
- void __iomem *l2cache_base;
-
- /* To avoid code running on other OMAPs in
-* multi-omap builds
-*/
- if (!cpu_is_omap44xx())
- return -ENODEV;
-
- /* Static mapping, never released */
- l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K);
- BUG_ON(!l2cache_base);
-
- /* Enable PL310 L2 Cache controller */
- omap_smc1(0x102, 0x1);
-
- /* 32KB way size, 16-way associativity,
- * parity disabled
- */
- l2x0_init(l2cache_base, 0x0e05, 0xcfff);
-
- return 0;
-}
-early_initcall(omap_l2_cache_init);
-#endif
-
-static void __init gic_init_irq(void)
-{
- void __iomem *base;
-
- /* Static mapping, never released */
- base = ioremap(OMAP44XX_GIC_DIST_BASE, SZ_4K);
- BUG_ON(!base);
- gic_dist_init(0, base, 29);
-
- /* Static mapping, never released */
- gic_cpu_base_addr = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_512);
- BUG_ON(!gic_cpu_base_addr);
- gic_cpu_init(0, gic_cpu_base_addr);
-}
-
static void __init omap_4430sdp_init_irq(void)
{
omap_board_config = sdp4430_config;
diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
b/arch/arm/mach-omap2/include/mach/omap4-common.h
new file mode 100644
index 000..423af3a
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -0,0 +1,26 @@
+/*
+ * omap4-common.h: OMAP4 specific common header file
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Santosh Shilimkar
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef OMAP_ARCH_OMAP4_COMMON_H
+#define OMAP_ARCH_OMAP4_COMMON_H
+
+#ifdef CONFIG_CACHE_L2X0
+extern void __iomem *l2cache_base;
+#endif
+
+extern void __iomem *gic_cpu_base_addr;
+extern void __iomem *gic_dist_base_addr;
+
+extern void __init gic_init_irq(void);
+extern void omap_smc1(u32 fn, u32 arg);
+
+#endif
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 38153e5..1cf5231 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -24,7 +24,7 @@
#include
#include
#include
-#include
+#include
/* SCU base address */
static void __iomem *scu_base;
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
new file mode 100644
index 000..13dc979
--- /dev/null
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -0,0 +1,72 @@
+/*
+ * OMAP4 specific common source file.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Author:
+ * Santosh Shilimkar
+ *
+ *
+ * This program is free soft
[PATCH 09/10] omap: GPIO: Fix OMAP4 GPIO reg access issues
From: Tony Lindgren
Access to some of the OMAP4 GPIO registers are not properly handled.
This patch fixes it.
This patch is tested on 3430SDP and 4430SDP boards
Signed-off-by: Charulatha V
cc: Kevin Hilman
Acked-by: Kevin Hilman
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/gpio.c | 59 -
1 files changed, 47 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 955597f..dc2ac42 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -138,7 +138,11 @@
#define OMAP4_GPIO_IRQSTATUSCLR1 0x0040
#define OMAP4_GPIO_IRQWAKEN0 0x0044
#define OMAP4_GPIO_IRQWAKEN1 0x0048
-#define OMAP4_GPIO_SYSSTATUS 0x0104
+#define OMAP4_GPIO_SYSSTATUS 0x0114
+#define OMAP4_GPIO_IRQENABLE1 0x011c
+#define OMAP4_GPIO_WAKE_EN 0x0120
+#define OMAP4_GPIO_IRQSTATUS2 0x0128
+#define OMAP4_GPIO_IRQENABLE2 0x012c
#define OMAP4_GPIO_CTRL0x0130
#define OMAP4_GPIO_OE 0x0134
#define OMAP4_GPIO_DATAIN 0x0138
@@ -149,6 +153,10 @@
#define OMAP4_GPIO_FALLINGDETECT 0x014c
#define OMAP4_GPIO_DEBOUNCENABLE 0x0150
#define OMAP4_GPIO_DEBOUNCINGTIME 0x0154
+#define OMAP4_GPIO_CLEARIRQENABLE1 0x0160
+#define OMAP4_GPIO_SETIRQENABLE1 0x0164
+#define OMAP4_GPIO_CLEARWKUENA 0x0180
+#define OMAP4_GPIO_SETWKUENA 0x0184
#define OMAP4_GPIO_CLEARDATAOUT0x0190
#define OMAP4_GPIO_SETDATAOUT 0x0194
/*
@@ -591,12 +599,16 @@ static int _get_gpio_dataout(struct gpio_bank *bank, int
gpio)
reg += OMAP7XX_GPIO_DATA_OUTPUT;
break;
#endif
-#ifdef CONFIG_ARCH_OMAP2PLUS
+#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
case METHOD_GPIO_24XX:
- case METHOD_GPIO_44XX:
reg += OMAP24XX_GPIO_DATAOUT;
break;
#endif
+#ifdef CONFIG_ARCH_OMAP4
+ case METHOD_GPIO_44XX:
+ reg += OMAP4_GPIO_DATAOUT;
+ break;
+#endif
default:
return -EINVAL;
}
@@ -1213,11 +1225,17 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
#endif
if (!cpu_class_is_omap1()) {
if (!bank->mod_usage) {
+ void __iomem *reg = bank->base;
u32 ctrl;
- ctrl = __raw_readl(bank->base + OMAP24XX_GPIO_CTRL);
- ctrl &= 0xFFFE;
+
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ reg += OMAP24XX_GPIO_CTRL;
+ else if (cpu_is_omap44xx())
+ reg += OMAP4_GPIO_CTRL;
+ ctrl = __raw_readl(reg);
/* Module is enabled, clocks are not gated */
- __raw_writel(ctrl, bank->base + OMAP24XX_GPIO_CTRL);
+ ctrl &= 0xFFFE;
+ __raw_writel(ctrl, reg);
}
bank->mod_usage |= 1 << offset;
}
@@ -1239,22 +1257,34 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
__raw_writel(1 << offset, reg);
}
#endif
-#ifdef CONFIG_ARCH_OMAP2PLUS
- if ((bank->method == METHOD_GPIO_24XX) ||
- (bank->method == METHOD_GPIO_44XX)) {
+#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
+ if (bank->method == METHOD_GPIO_24XX) {
/* Disable wake-up during idle for dynamic tick */
void __iomem *reg = bank->base + OMAP24XX_GPIO_CLEARWKUENA;
__raw_writel(1 << offset, reg);
}
#endif
+#ifdef CONFIG_ARCH_OMAP4
+ if (bank->method == METHOD_GPIO_44XX) {
+ /* Disable wake-up during idle for dynamic tick */
+ void __iomem *reg = bank->base + OMAP4_GPIO_IRQWAKEN0;
+ __raw_writel(1 << offset, reg);
+ }
+#endif
if (!cpu_class_is_omap1()) {
bank->mod_usage &= ~(1 << offset);
if (!bank->mod_usage) {
+ void __iomem *reg = bank->base;
u32 ctrl;
- ctrl = __raw_readl(bank->base + OMAP24XX_GPIO_CTRL);
+
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ reg += OMAP24XX_GPIO_CTRL;
+ else if (cpu_is_omap44xx())
+ reg += OMAP4_GPIO_CTRL;
+ ctrl = __raw_readl(reg);
/* Module is disabled, clocks are gated */
ctrl |= 1;
- __raw_writel(ctrl, bank->base + OMAP24XX_GPIO_CTRL);
+ __raw_writel(ctrl, reg);
}
}
_reset_gpio(bank, bank->chip.base + offset);
@@ -1583,9 +1613,1
[PATCH 07/10] OMAP4: Networking: Defconfig Support
From: Abraham Arce Enable KS8851 SPI support + Networking Support - Packet Socket - TCP/IP Network Filesystems - NFS Client - Root Filesystem on NFS Signed-off-by: Abraham Arce Signed-off-by: Tony Lindgren --- arch/arm/configs/omap_4430sdp_defconfig | 57 ++- 1 files changed, 55 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index a96bca2..d87a349 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -343,7 +343,34 @@ CONFIG_BINFMT_MISC=y # # CONFIG_PM is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y -# CONFIG_NET is not set +CONFIG_NET=y + +# +# Networking options +# +CONFIG_PACKET=y +CONFIG_XFRM=y +CONFIG_INET=y +CONFIG_IP_FIB_HASH=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_IP_PNP_RARP=y +CONFIG_INET_XFRM_MODE_TRANSPORT=y +CONFIG_INET_XFRM_MODE_TUNNEL=y +CONFIG_INET_XFRM_MODE_BEET=y +CONFIG_INET_LRO=y +CONFIG_INET_DIAG=y +CONFIG_INET_TCP_DIAG=y +CONFIG_TCP_CONG_CUBIC=y +CONFIG_DEFAULT_TCP_CONG="cubic" +# CONFIG_IPV6 is not set + +# +# Network testing +# +# CONFIG_WIRELESS is not set + # # Device Drivers @@ -386,6 +413,13 @@ CONFIG_HAVE_IDE=y # CONFIG_ATA is not set # CONFIG_MD is not set # CONFIG_PHONE is not set +CONFIG_NETDEVICES=y +CONFIG_NET_ETHERNET=y +CONFIG_MII=y +CONFIG_KS8851=y +# CONFIG_NETDEV_1000 is not set +# CONFIG_NETDEV_1 is not set +# CONFIG_WLAN is not set # # Input device support @@ -457,7 +491,13 @@ CONFIG_HW_RANDOM=y # CONFIG_RAW_DRIVER is not set # CONFIG_TCG_TPM is not set # CONFIG_I2C is not set -# CONFIG_SPI is not set +CONFIG_SPI=y +CONFIG_SPI_MASTER=y + +# +# SPI Master Controller Drivers +# +CONFIG_SPI_OMAP24XX=y # # PPS support @@ -634,6 +674,19 @@ CONFIG_MISC_FILESYSTEMS=y # CONFIG_ROMFS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set +CONFIG_NETWORK_FILESYSTEMS=y +CONFIG_NFS_FS=y +CONFIG_NFS_V3=y +CONFIG_NFS_V3_ACL=y +CONFIG_NFS_V4=y +CONFIG_ROOT_NFS=y +CONFIG_LOCKD=y +CONFIG_LOCKD_V4=y +CONFIG_NFS_ACL_SUPPORT=y +CONFIG_NFS_COMMON=y +CONFIG_SUNRPC=y +CONFIG_SUNRPC_GSS=y +CONFIG_RPCSEC_GSS_KRB5=y # # Partition Types -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/10] OMAP4: SPI: Fix Driver Kconfig
From: Syed Rafiuddin Change dependency to ARCH_OMAP2PLUS to allow systems based on omap24xx, omap34xx or omap44xx Cc: spi-devel-gene...@lists.sourceforge.net Signed-off-by: Syed Rafiuddin Signed-off-by: Abraham Arce Signed-off-by: Tony Lindgren --- drivers/spi/Kconfig |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index a191fa2..f950b63 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -180,10 +180,10 @@ config SPI_OMAP_UWIRE This hooks up to the MicroWire controller on OMAP1 chips. config SPI_OMAP24XX - tristate "McSPI driver for OMAP24xx/OMAP34xx" - depends on ARCH_OMAP2 || ARCH_OMAP3 + tristate "McSPI driver for OMAP" + depends on ARCH_OMAP2PLUS help - SPI master controller for OMAP24xx/OMAP34xx Multichannel SPI + SPI master controller for OMAP24XX and later Multichannel SPI (McSPI) modules. config SPI_OMAP_100K -- 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 04/10] omap: hsmmc: fix the hsmmc driver for am3517
From: stanley.miao
AM3517 don't have the register OMAP343X_CONTROL_PBIAS_LITE and the regulators
like "vmmc", so we set a noop "set_power" function for it.
Signed-off-by: Stanley.Miao
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/hsmmc.c | 27 +--
arch/arm/plat-omap/include/plat/mmc.h |4
2 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 9ad2295..2d36f3a 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -139,6 +139,12 @@ static void hsmmc23_before_set_reg(struct device *dev, int
slot,
}
}
+static int nop_mmc_set_power(struct device *dev, int slot, int power_on,
+ int vdd)
+{
+ return 0;
+}
+
static struct omap_mmc_platform_data *hsmmc_data[OMAP34XX_NR_MMC] __initdata;
void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
@@ -216,11 +222,18 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
*/
mmc->slots[0].ocr_mask = c->ocr_mask;
+ if (cpu_is_omap3517() || cpu_is_omap3505())
+ mmc->slots[0].set_power = nop_mmc_set_power;
+ else
+ mmc->slots[0].features |= HSMMC_HAS_PBIAS;
+
switch (c->mmc) {
case 1:
- /* on-chip level shifting via PBIAS0/PBIAS1 */
- mmc->slots[0].before_set_reg = hsmmc1_before_set_reg;
- mmc->slots[0].after_set_reg = hsmmc1_after_set_reg;
+ if (mmc->slots[0].features & HSMMC_HAS_PBIAS) {
+ /* on-chip level shifting via PBIAS0/PBIAS1 */
+ mmc->slots[0].before_set_reg =
hsmmc1_before_set_reg;
+ mmc->slots[0].after_set_reg =
hsmmc1_after_set_reg;
+ }
/* Omap3630 HSMMC1 supports only 4-bit */
if (cpu_is_omap3630() && c->wires > 4) {
@@ -235,9 +248,11 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
c->wires = 4;
/* FALLTHROUGH */
case 3:
- /* off-chip level shifting, or none */
- mmc->slots[0].before_set_reg = hsmmc23_before_set_reg;
- mmc->slots[0].after_set_reg = NULL;
+ if (mmc->slots[0].features & HSMMC_HAS_PBIAS) {
+ /* off-chip level shifting, or none */
+ mmc->slots[0].before_set_reg =
hsmmc23_before_set_reg;
+ mmc->slots[0].after_set_reg = NULL;
+ }
break;
default:
pr_err("MMC%d configuration not supported!\n", c->mmc);
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index a1bac07..c835f1e 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -102,6 +102,10 @@ struct omap_mmc_platform_data {
/* Regulator off remapped to sleep */
unsigned vcc_aux_disable_is_sleep:1;
+ /* we can put the features above into this variable */
+#define HSMMC_HAS_PBIAS(1 << 0)
+ unsigned features;
+
int switch_pin; /* gpio (card detect) */
int gpio_wp;/* gpio (write protect) */
--
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/10] omap: init the gpio pinmux for mmc
From: stanley.miao
There is two gpio for mmc use, one is for card detecting, another is
used for checking write protect. Intialize its pinmux in case the bootloader
doesn't set it.
Signed-off-by: Stanley.Miao
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/devices.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 10f3a3c..3d30f22 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -591,6 +591,15 @@ static inline void omap_hsmmc_reset(void) {}
static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
int controller_nr)
{
+ if ((mmc_controller->slots[0].switch_pin > 0) && \
+ (mmc_controller->slots[0].switch_pin < OMAP_MAX_GPIO_LINES))
+ omap_mux_init_gpio(mmc_controller->slots[0].switch_pin,
+ OMAP_PIN_INPUT_PULLUP);
+ if ((mmc_controller->slots[0].gpio_wp > 0) && \
+ (mmc_controller->slots[0].gpio_wp < OMAP_MAX_GPIO_LINES))
+ omap_mux_init_gpio(mmc_controller->slots[0].gpio_wp,
+ OMAP_PIN_INPUT_PULLUP);
+
if (cpu_is_omap2420() && controller_nr == 0) {
omap_cfg_reg(H18_24XX_MMC_CMD);
omap_cfg_reg(H15_24XX_MMC_CLKI);
--
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 02/10] omap: DMA: Fix multi-line comments
From: manjugk manjugk
Multi line comments are fixed as per CodingStyle
guidelines.
Cc: Tony Lindgren
Cc: Kevin Hilman
Signed-off-by: Manjunatha GK
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/dma.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index ad42ec3..f7f571e 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -501,7 +501,8 @@ void omap_set_dma_src_burst_mode(int lch, enum
omap_dma_burst_mode burst_mode)
burst = 0x2;
break;
}
- /* not supported by current hardware on OMAP1
+ /*
+* not supported by current hardware on OMAP1
* w |= (0x03 << 7);
* fall through
*/
@@ -510,7 +511,8 @@ void omap_set_dma_src_burst_mode(int lch, enum
omap_dma_burst_mode burst_mode)
burst = 0x3;
break;
}
- /* OMAP1 don't support burst 16
+ /*
+* OMAP1 don't support burst 16
* fall through
*/
default:
@@ -604,7 +606,8 @@ void omap_set_dma_dest_burst_mode(int lch, enum
omap_dma_burst_mode burst_mode)
burst = 0x3;
break;
}
- /* OMAP1 don't support burst 16
+ /*
+* OMAP1 don't support burst 16
* fall through
*/
default:
@@ -1285,8 +1288,10 @@ int omap_request_dma_chain(int dev_id, const char
*dev_name,
return -EINVAL;
}
- /* Allocate a queue to maintain the status of the channels
-* in the chain */
+ /*
+* Allocate a queue to maintain the status of the channels
+* in the chain
+*/
channels = kmalloc(sizeof(*channels) * no_of_chans, GFP_KERNEL);
if (channels == NULL) {
printk(KERN_ERR "omap_dma: No memory for channel queue\n");
@@ -1915,7 +1920,8 @@ static int omap2_dma_handle_ch(int ch)
printk(KERN_INFO "DMA transaction error with device %d\n",
dma_chan[ch].dev_id);
if (cpu_class_is_omap2()) {
- /* Errata: sDMA Channel is not disabled
+ /*
+* Errata: sDMA Channel is not disabled
* after a transaction error. So we explicitely
* disable the channel
*/
--
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/10] OMAP2/3/4: DMA: disable channel interrupts in omap_init_dma()
From: Mika Westerberg
If we are softbooting another kernel using kexec, DMA controller state is not
known when we are performing omap_init_dma(). It is possible that some DMA
channels are already active. For example after kexec we get:
<4>IRQ 0020 for non-allocated DMAchannel 5
<4>IRQ 0020 for non-allocated DMAchannel 5
<4>IRQ 0020 for non-allocated DMAchannel 5
<4>IRQ 0020 for non-allocated DMAchannel 5
<4>IRQ 0020 for non-allocated DMAchannel 5
To prevent any weird things happening, we disable all channel interrupts during
init.
Signed-off-by: Mika Westerberg
Acked-by: Kevin Hilman
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/dma.c | 27 +++
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 1d95996..ad42ec3 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -709,6 +709,21 @@ static inline void omap2_enable_irq_lch(int lch)
spin_unlock_irqrestore(&dma_chan_lock, flags);
}
+static inline void omap2_disable_irq_lch(int lch)
+{
+ u32 val;
+ unsigned long flags;
+
+ if (!cpu_class_is_omap2())
+ return;
+
+ spin_lock_irqsave(&dma_chan_lock, flags);
+ val = dma_read(IRQENABLE_L0);
+ val &= ~(1 << lch);
+ dma_write(val, IRQENABLE_L0);
+ spin_unlock_irqrestore(&dma_chan_lock, flags);
+}
+
int omap_request_dma(int dev_id, const char *dev_name,
void (*callback)(int lch, u16 ch_status, void *data),
void *data, int *dma_ch_out)
@@ -807,14 +822,7 @@ void omap_free_dma(int lch)
}
if (cpu_class_is_omap2()) {
- u32 val;
-
- spin_lock_irqsave(&dma_chan_lock, flags);
- /* Disable interrupts */
- val = dma_read(IRQENABLE_L0);
- val &= ~(1 << lch);
- dma_write(val, IRQENABLE_L0);
- spin_unlock_irqrestore(&dma_chan_lock, flags);
+ omap2_disable_irq_lch(lch);
/* Clear the CSR register and IRQ status register */
dma_write(OMAP2_DMA_CSR_CLEAR_MASK, CSR(lch));
@@ -2107,6 +2115,9 @@ static int __init omap_init_dma(void)
for (ch = 0; ch < dma_chan_count; ch++) {
omap_clear_dma(ch);
+ if (cpu_class_is_omap2())
+ omap2_disable_irq_lch(ch);
+
dma_chan[ch].dev_id = -1;
dma_chan[ch].next_lch = -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 00/10] omap platform init patches for 2.6.35 merge window
Hi all, Here are some omap patches mostly to get some more devices initialized. With these the omap4 Ethernet should work, the drivers related patches are queued too. Regards, Tony --- Abraham Arce (2): OMAP4: Ethernet: KS8851 Board Support OMAP4: Networking: Defconfig Support Mika Westerberg (1): OMAP2/3/4: DMA: disable channel interrupts in omap_init_dma() Santosh Shilimkar (1): omap4: Move SOC specific code from board file Syed Rafiuddin (1): OMAP4: SPI: Fix Driver Kconfig Tony Lindgren (1): omap: GPIO: Fix OMAP4 GPIO reg access issues manjugk manjugk (1): omap: DMA: Fix multi-line comments stanley.miao (3): omap: init the gpio pinmux for mmc omap: hsmmc: fix the hsmmc driver for am3517 AM3517: rename the i2c boardinfo to make it more readable arch/arm/configs/omap_4430sdp_defconfig | 57 ++ arch/arm/mach-omap2/Makefile|2 arch/arm/mach-omap2/board-4430sdp.c | 128 +++ arch/arm/mach-omap2/board-am3517evm.c | 20 ++-- arch/arm/mach-omap2/devices.c |9 ++ arch/arm/mach-omap2/hsmmc.c | 27 - arch/arm/mach-omap2/include/mach/omap4-common.h | 26 + arch/arm/mach-omap2/omap-smp.c |2 arch/arm/mach-omap2/omap4-common.c | 72 + arch/arm/plat-omap/common.c |3 - arch/arm/plat-omap/dma.c| 45 ++-- arch/arm/plat-omap/gpio.c | 59 --- arch/arm/plat-omap/include/plat/common.h|3 - arch/arm/plat-omap/include/plat/mmc.h |4 + drivers/spi/Kconfig |6 + 15 files changed, 362 insertions(+), 101 deletions(-) create mode 100644 arch/arm/mach-omap2/include/mach/omap4-common.h create mode 100644 arch/arm/mach-omap2/omap4-common.c -- Signature -- 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 08/17] omap: mailbox: only compile for configured archs
>
> - if (cpu_is_omap3430()) {
> + if (false);
-- Is this statement needed ?
> +#if defined(CONFIG_ARCH_OMAP3430)
> + else if (cpu_is_omap3430()) {
> list = omap3_mboxes;
>
> list[0]->irq = res[1].start;
Thank you,
Best regards,
Hari
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Friday 14 May 2010, Kevin Hilman wrote: > "Rafael J. Wysocki" writes: > > > On Thursday 13 May 2010, Tony Lindgren wrote: > >> * Rafael J. Wysocki [100513 14:16]: > > [...] > > >> > >> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved > >> > differently, while there's a growing number of out-of-tree drivers > >> > depending > >> > on this framework. We need those drivers in and because we don't have > >> > any > >> > viable alternative at hand, we have no good reason to reject it. > >> > >> Nothing is preventing merging the drivers can be merged without > >> these calls. > > > > And yet, there _is_ a growing nuber of drivers that don't get merge because > > of that. That's _reality_. Are you going to discuss with facts, or what? > > It may be reality, but IMO, "preventing other drivers" isn't a good > *technical* argument for merging a feature. It feels like these "for > the 'good' of the community" arguments are being used to trump the > technical arguments. Maybe we need to keep the separate. > > Distros (especially embedded ones) have long had out of tree features > that create barriers to getting other drivers upstream. While it > might be nice to see all those features upstream, no one has argued > that they should get merged simply because they create a barrier. Each > feature should be merged on its own technical merit. Well, this is very much like the selinux vs apparmour (& friends) issue. One can argue we need only one of them, but in fact we're not worse off having both in. The feature is not technically unacceptable to me and since having it in would potentially make it easier to merge quite a few drivers, I regard that as a good enough argument for. YMMV. Thanks, Rafael -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
"Rafael J. Wysocki" writes: > On Thursday 13 May 2010, Tony Lindgren wrote: >> * Rafael J. Wysocki [100513 14:16]: [...] >> >> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved >> > differently, while there's a growing number of out-of-tree drivers >> > depending >> > on this framework. We need those drivers in and because we don't have any >> > viable alternative at hand, we have no good reason to reject it. >> >> Nothing is preventing merging the drivers can be merged without >> these calls. > > And yet, there _is_ a growing nuber of drivers that don't get merge because > of that. That's _reality_. Are you going to discuss with facts, or what? It may be reality, but IMO, "preventing other drivers" isn't a good *technical* argument for merging a feature. It feels like these "for the 'good' of the community" arguments are being used to trump the technical arguments. Maybe we need to keep the separate. Distros (especially embedded ones) have long had out of tree features that create barriers to getting other drivers upstream. While it might be nice to see all those features upstream, no one has argued that they should get merged simply because they create a barrier. Each feature should be merged on its own technical merit. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/6] DSPBRIDGE: fix mem+cache API issues
On 5/14/2010 2:27 PM, Felipe Contreras wrote: [...] So, I tried your patches, and a simple test app worked fine without modification, but a real video decoding hanged the device completely... some spinlock was stuck. I don't know if it's because of your patches, or because of the state of the bridge at that point. I'll try first to rebase to the latest to have a better idea of what's happening. You may want to check if you have this patch "DSPBRIDGE: Fix declaration and initialization of sync objects"[1] This is the one I know fixes a spinlock issue and which description is not clear enough to state that. File fixed was: drivers/dsp/bridge/wmd/msg_sm.c [1]http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=b3900e6df1f4e16b59d506a299cd5084c67a6ede Regards, - omar -- 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 v4 2/2] omap: rx-51: enable tsc2005
* Aaro Koskinen [100419 07:49]: > Enable TSC2005 touchscreen driver on the RX-51 board. > > Signed-off-by: Aaro Koskinen Assuming these both go in via the input patches: Acked-by: Tony Lindgren -- 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: [PATCHv3 0/4] Regulator: OMAP: Removing common code for TWL4030 from OMAP3-board-evms
* Anuj Aggarwal [100302 02:25]: > Sending version 3 of this patch-set after rebasing it against the for-next > branch in the linux-omap tree. The previous series can be found at: > http://marc.info/?l=linux-omap&m=126328763822497&w=2 > > This patch set is created to clean up various OMAP3-board-evm files > and remove common TWL4030 specific regulator suplies and init data > structs. These structures are instead placed in a new generic file - > twl4030-pmic.c - and are referenced from the OMAP3 board-evm > files depending on the platform requirements. Regulator having specific > supplies or init data structs are not changed in their respective > board-evms. > > uImage built and tested for OMAP3EVM; compile-tested for SDP3430 and all OMAP > platforms (using omap3_defconfig). > > Anuj Aggarwal (4): > Regulator: OMAP: Creating TWL4030 file having supplies & init data > Regulator: OMAP: Modifying Kconfig/Makefile to choose from available > PMICs > Regulator: OMAP: Kconfig modified to select TWL4030 for > OMAP3-platforms > Regulator: OMAP: Use common regulator supplies and init data structs > > arch/arm/mach-omap2/Kconfig | 20 +++ > arch/arm/mach-omap2/Makefile |1 + > arch/arm/mach-omap2/board-3430sdp.c | 135 ++-- > arch/arm/mach-omap2/board-cm-t35.c | 47 +-- > arch/arm/mach-omap2/board-igep0020.c | 24 +--- > arch/arm/mach-omap2/board-ldp.c | 24 +--- > arch/arm/mach-omap2/board-omap3beagle.c | 47 +-- > arch/arm/mach-omap2/board-omap3evm.c | 47 +-- > arch/arm/mach-omap2/board-omap3touchbook.c | 47 +-- > arch/arm/mach-omap2/board-overo.c| 23 +--- > arch/arm/mach-omap2/board-zoom-peripherals.c | 71 +-- > arch/arm/mach-omap2/twl4030-pmic.c | 175 > ++ > arch/arm/mach-omap2/twl4030-pmic.h | 34 + > 13 files changed, 277 insertions(+), 418 deletions(-) > create mode 100644 arch/arm/mach-omap2/twl4030-pmic.c > create mode 100644 arch/arm/mach-omap2/twl4030-pmic.h Are these patches still relevant? I'd like to see some acks on these.. 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: [RFC/PATCH 0/6] DSPBRIDGE: fix mem+cache API issues
Hi, I spent some time looking deeper into this patch series, and I have some doubts. On Sun, May 2, 2010 at 8:47 PM, Ohad Ben-Cohen wrote: > On Sun, May 2, 2010 at 4:17 PM, Felipe Contreras > wrote: >> On Sat, May 1, 2010 at 11:44 PM, Ohad Ben-Cohen wrote: >>> The patchset renames the flush ioctl to begin_dma_to_dsp and >>> the invalidate ioctl to begin_dma_from_dsp. Both functions >>> eventually call dma_map_sg, with the former requesting a >>> DMA_BIDIRECTIONAL direction, and the latter requesting a >>> DMA_FROM_DEVICE direction. >>> In addition, the patchset adds two new APIs which calls dma_unmap_sg: >>> end_dma_to_dsp and end_dma_from_dsp. >>> >>> Ideally, there would be only a single begin_dma command and a single >>> end_dma one, which would accept an additional parameter that will >>> determine the direction of the transfer. Such an approach would be more >>> versatile and cleaner, but it would also break all user space apps that >>> use dspbridge today. >> >> If I understand correctly all user-space apps would be broken anyway >> because they are not issuing the end_dma calls. At the very least they >> need to be updated to use them. > > Basically you're right, but the patches currently silently allow > today's user space > to somehow work (because if you don't use dma bounce buffers and you feel > lucky > about speculative prefetching then you might get away with not calling > dma unmap). > I did that on purpose, to ease testing & migration, but didn't > explicitely said it because > frankly it's just wrong. I looked into the dma code (I guess it's in arch/arm/mm/dma-mapping.c) and I don't understand what dma_unmap_sg is supposed to do. I see that first some "safe buffer" is searched, and if there isn't any... then it depends on the direction whether something is actually done or not. I guess it depends whether our arch has dmabounce or not, which I have no idea, but if we do, wouldn't skiping dma_unmap calls leak some massive amount of "safe buffers"? >> Also, in Nokia we patched the bridgedriver to be able to have the 3 >> operations available from user-space (clean, inv, and flush), so we >> would be very interested in having the direction of the transfer >> available. > > Thanks, that's important to know. It's not that critical, but I guess it can't hurt to do the right thing. > What do you say about the following plan then: > - I'll add a single pair of begin_dma and end_dma commands that will > take the additional > direction parameter as described above. I'll then covert the existing > flush & invalidate commands to use this begin_dma command supplying it > the appropriate direction argument. Sounds perfect, but I wonder if the deprecated flush & invalidate would really work. See previous comments. > - In a separate patch, I'll deprecate flush & invalidate entirely > (usage of this deprecated > API will fail, resulting in a guiding error message). > > We get a sane and versatile (and platform-independent) implementation > that always work, > but breaks user space. If anyone would need to work with current user space, > the deprecating patch can always be reverted locally to get back a > flush & invalidate > implementations that (somehow) work. User-space API is being broken all the time in dspbridge. The difference is that this one might require nontrivial changes. But it must be done. So, I tried your patches, and a simple test app worked fine without modification, but a real video decoding hanged the device completely... some spinlock was stuck. I don't know if it's because of your patches, or because of the state of the bridge at that point. I'll try first to rebase to the latest to have a better idea of what's happening. Also, I noticed an important problem. Your code assumes that we would always have a bunch of scattered pages, however you are not taking into account bridge_brd_mem_map() where vm_flags have VM_IO... in that case get_user_pages() is skipped completely. This code-path is important in order to mmap framebuffer memory, which is contiguous. So, in this case there are no pages too keep track at all. This use-case is very important since the dspbridge mmap operation is very expensive, and due to GStreamer design, we must do it constantly... if the memory is contiguous (VM_IO), the mmap operation is really fast (or at least should be... in theory). Reading your patches I see the ioctl to start the dmap operations would simply error out, but from the looks of it, they would be failing already, which is weird, because we are already using framebuffer memory for video decoding + rendering. In gst-dsp we are not checking the success of clean/invalidate ioctls so it might be that it has been failing all this time and seems to work by pure luck. Anyway, I'll keep investigating and let you know if I find anything. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a messag
Re: [PATCH 3/3 v2] musb: AM35x: Workaround for fifo read issue
Ajay Kumar Gupta wrote:
> AM35x supports only 32bit read operations so we need to have
> workaround for 8bit and 16bit read operations.
>
> Signed-off-by: Ajay Kumar Gupta
> ---
> drivers/usb/musb/am3517.c | 30 ++
> drivers/usb/musb/musb_core.c | 2 ++
> 2 files changed, 32 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/musb/am3517.c b/drivers/usb/musb/am3517.c
> index dd9e883..24bdc2e 100644
> --- a/drivers/usb/musb/am3517.c
> +++ b/drivers/usb/musb/am3517.c
> @@ -515,3 +515,33 @@ void musb_platform_restore_context(struct
> musb_context_registers
> phy_on();
> }
> #endif
> +
> +/* AM35x supports only 32bit read operation */
> +void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
> +{
> + void __iomem *fifo = hw_ep->fifo;
> + u32 val;
> + int i;
> +
> + /* Read for 32bit-aligned destination address */
> + if ((likely((0x03 & (unsigned long) dst) == 0)) && len >= 4) {
> + readsl(fifo, dst, len >> 2);
> + dst += (len & ~0x03);
> + len &= 0x03;
> + }
> + /* Now read the rest 1 to 3 bytes or complete length if
check multiline comments style
> + * unaligned address.
> + */
> + if (len > 4) {
> + for (i = 0; i < (len >> 2); i++) {
> + val = musb_readl(fifo, 0);
> + memcpy(dst, &val, 4);
> + dst += 4;
> + }
> + len %= 4;
> + }
> + if (len > 0) {
> + val = musb_readl(fifo, 0);
> + memcpy(dst, &val, len);
> + }
> +}
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 705cc4a..bc2cf14 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -191,6 +191,7 @@ void musb_write_fifo(struct musb_hw_ep *hw_ep, u16 len,
> const u8 *src)
> }
> }
>
> +#if !defined(CONFIG_MACH_OMAP3517EVM)
> /*
> * Unload an endpoint's FIFO
> */
> @@ -228,6 +229,7 @@ void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8
> *dst)
> readsb(fifo, dst, len);
> }
> }
> +#endif
>
> #endif /* normal PIO */
>
> --
> 1.6.2.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 2/3 v2] musb: add musb support for AM35x
Ajay Kumar Gupta wrote: > AM35x is based on OMAP35x but has an updated musb interface which > uses CPPI4.1 DMA engine. > > Current patch supports only PIO mode transfers. > > Signed-off-by: Ajay Kumar Gupta > --- > Changes from v1: (Based on Sergei's comment) > - Moved PHY clock and OTGMODE settings to board files > - Added clk_disable/put in exit path > - Removed unwanted code related to vbus > - Removed unhandled interrupt check > - Added timeout in phy_on() > I had to use MACH_OMAP3517EVM as there is no ARCH_xxx config specific to > AM3517 platforms other than ARCH_OMAP3. > > drivers/usb/musb/Kconfig | 4 +- > drivers/usb/musb/Makefile | 4 + > drivers/usb/musb/am3517.c | 517 > 3 files changed, 523 insertions(+), 2 deletions(-) > create mode 100644 drivers/usb/musb/am3517.c > > diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig > index ea3a882..5ea3d45 100644 > --- a/drivers/usb/musb/Kconfig > +++ b/drivers/usb/musb/Kconfig > @@ -10,7 +10,7 @@ comment "Enable Host or Gadget support to see Inventra > options" > config USB_MUSB_HDRC > depends on (USB || USB_GADGET) > depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523)) > - select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) > + select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN || > MACH_OMAP3517EVM) > select TWL4030_USB if MACH_OMAP_3430SDP > select USB_OTG_UTILS > tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' > @@ -140,7 +140,7 @@ config USB_MUSB_HDRC_HCD > config MUSB_PIO_ONLY > bool 'Disable DMA (always use PIO)' > depends on USB_MUSB_HDRC > - default y if USB_TUSB6010 > + default USB_TUSB6010 || MACH_OMAP3517EVM > help > All data is copied between memory and FIFO by the CPU. > DMA controllers are ignored. > diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile > index 3a485da..52a8cf6 100644 > --- a/drivers/usb/musb/Makefile > +++ b/drivers/usb/musb/Makefile > @@ -19,7 +19,11 @@ ifeq ($(CONFIG_ARCH_OMAP2430),y) > endif > > ifeq ($(CONFIG_ARCH_OMAP3430),y) > + ifeq ($(CONFIG_MACH_OMAP3517EVM),y) > + musb_hdrc-objs += am3517.o > + else > musb_hdrc-objs += omap2430.o > + endif > endif > > ifeq ($(CONFIG_BF54x),y) > diff --git a/drivers/usb/musb/am3517.c b/drivers/usb/musb/am3517.c > new file mode 100644 > index 000..dd9e883 > --- /dev/null > +++ b/drivers/usb/musb/am3517.c > @@ -0,0 +1,517 @@ > +/* > + * Texas Instruments AM3517 "glue layer" > + * > + * Copyright (c) 2010, by Texas Instruments > + * > + * Based on the DA8xx "glue layer" code. > + * Copyright (C) 2005-2006 by Texas Instruments > + * Copyright (c) 2008, MontaVista Software, Inc. > + * > + * This file is part of the Inventra Controller Driver for Linux. > + * > + * The Inventra Controller Driver for Linux is free software; you > + * can redistribute it and/or modify it under the terms of the GNU > + * General Public License version 2 as published by the Free Software > + * Foundation. > + * > + * The Inventra Controller Driver for Linux is distributed in > + * the hope that it will be useful, but WITHOUT ANY WARRANTY; > + * without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public > + * License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with The Inventra Controller Driver for Linux ; if not, > + * write to the Free Software Foundation, Inc., 59 Temple Place, > + * Suite 330, Boston, MA 02111-1307 USA > + * > + */ > + > +#include > +#include > +#include > + > +#include > +#include > + > +#include "musb_core.h" > + > +/* > + * AM3517 specific definitions > + */ > +/* USB 2.0 OTG module registers */ > +#define USB_REVISION_REG 0x00 > +#define USB_CTRL_REG 0x04 > +#define USB_STAT_REG 0x08 > +#define USB_EMULATION_REG 0x0c > +/* 0x10 Reserved */ > +#define USB_AUTOREQ_REG 0x14 > +#define USB_SRP_FIX_TIME_REG 0x18 > +#define USB_TEARDOWN_REG 0x1c > +#define EP_INTR_SRC_REG 0x20 > +#define EP_INTR_SRC_SET_REG 0x24 > +#define EP_INTR_SRC_CLEAR_REG 0x28 > +#define EP_INTR_MASK_REG 0x2c > +#define EP_INTR_MASK_SET_REG 0x30 > +#define EP_INTR_MASK_CLEAR_REG 0x34 > +#define EP_INTR_SRC_MASKED_REG 0x38 > +#define CORE_INTR_SRC_REG 0x40 > +#define CORE_INTR_SRC_SET_REG 0x44 > +#define CORE_INTR_SRC_CLEAR_REG 0x48 > +#define CORE_INTR_MASK_REG 0x4c > +#define CORE_INTR_MASK_SET_REG 0x50 > +#define CORE_INTR_MASK_CLEAR_REG 0x54 > +#define CORE_INTR_SRC_MASKED_REG 0x58 > +/* 0x5c Reserved */ > +#define USB_END_OF_INTR_REG 0x60 > + > +/* Control register bits */ > +#define USB_SOFT_RESET_MASK 1 > + > +/* USB interrupt register bits */ > +#define USB_INTR_
Re: linux-next: manual merge of the omap_dss2 tree with the omap tree
* Tomi Valkeinen [100512 01:54]:
> Hi,
>
> On Mon, 2010-05-10 at 22:20 +0200, ext Tony Lindgren wrote:
> > * Stephen Rothwell [100506 22:05]:
> > > Hi Tomi,
> > >
> > > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > > arch/arm/mach-omap2/board-rx51-peripherals.c between commit
> > > e87da74e34ad151e6ae75ebb7a7bf447f02c0004 ("omap: rx51: Add supplies for
> > > the tlv320aic3x codec driver") from the omap tree and commit
> > > a693839eab0292aa234d7a6f48d40389389baebb ("OMAP: RX51: Add "vdds_sdi"
> > > supply voltage for SDI") from the omap_dss2 tree.
> > >
> > > Just overlapping additions. I fixed it up (see below) and can carry the
> > > fix as necessary.
> >
> > Thanks again Stephen. We will move the conflicting DSS board-*.c
> > file changes over to omap for next.
> >
> > Tomi, do you want to do a branch of board-*.c patches for me to
> > pull, or do you want me to just pick this one?
>
> I think it's ok to pick just this one. It's just adds a regulator
> supply, and doesn't interfere with anything. I just need to make sure
> linux-omap's for-next is merged first, before I send my pull request.
Thanks, I've picked this patch.
> I made a branch for it, based on linux-omap/for-next:
> git://gitorious.org/linux-omap-dss2/linux.git for-tony
>
> And I dropped the patch from my for-next branch.
Tomi, next time please check that your branch is based on
either the most recent tag by Linus, or in the conflicting
cases you can base on omap-for-linus branch. Please don't
base on for-next or other branches that are not yet
static, we don't want the merge history of duplicate branches.
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: omap iommu: patch for v2.6.34-rc7
* Hiroshi DOYU [100514 00:36]: > Hi Tony, > > The patches was sent on: > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg27968.html > > The following changes since commit b57f95a38233a2e73b679bea4a5453a1cc2a1cc9: > > Linux 2.6.34-rc7 (2010-05-09 18:36:28 -0700) > > are available in the git repository at: > git://gitorious.org/~doyu/lk/mainline.git v2.6.34-rc7.iommu > > Hiroshi DOYU (5): > omap iommu: Introduce iteration macro for iotlb entry scan > omap iommu: Make CONFIG_OMAP_IOMMU_DEBUG selectable > omap iommu: Insert a gap page between IOVMAs against override > omap iommu: Exit iteration if no possibility of available area > omap iommu: Reject unaligned addresses at setting page table entry > > Kanigeri, Hari (4): > omap iommu: renamed omap3-iommu to omap-iommu > omap iommu: support for OMAP4 > omap iommu: missing check for TLB valid entry > omap iommu: add TLB preservation support > > arch/arm/mach-omap2/Makefile |5 +- > arch/arm/mach-omap2/iommu2.c |6 +- > arch/arm/mach-omap2/omap-iommu.c | 157 > > arch/arm/mach-omap2/omap3-iommu.c | 105 --- > arch/arm/plat-omap/Kconfig |9 ++- > arch/arm/plat-omap/include/plat/omap44xx.h |3 + > arch/arm/plat-omap/iommu.c | 101 -- > arch/arm/plat-omap/iovmm.c |9 +- > 8 files changed, 244 insertions(+), 151 deletions(-) > create mode 100644 arch/arm/mach-omap2/omap-iommu.c > delete mode 100644 arch/arm/mach-omap2/omap3-iommu.c Thanks, I've pulled this into omap-for-linus. 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 00/17] omap: mailbox: reorganize init
On Fri, May 14, 2010 at 6:09 PM, Ohad Ben-Cohen wrote: > Hi Felipe, > > On Fri, May 14, 2010 at 6:01 PM, Felipe Contreras > wrote: >> The main purpose of this patch series is to be able to compile mach platform >> data as built-in. Otherwise, client modules such as bridgedriver will load >> the >> platform code, but not the mach code when mailbox is built as a module. >> >> Unfortunately, there's no easy way to do that since plat and mach code are >> deepely interrelated. So the first patches try to separate the mailbox >> registering through a defined omap_mbox_platform_data. > > Have you considered converting mailbox to hwmod + omap_device ? I don't know what's that... so no. Is there any good source of information, or a good example? I think there is further tidying up possible after this patch series independent of that, but I would like to concentrate on getting this in first. -- Felipe Contreras -- 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 v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature
Nishanth Menon wrote: > On 05/10/2010 07:31 AM, Venkatraman S wrote: >> >> Nishanth Menon wrote: > > Please see [1] for SOC specific feature handling. any reasons we can't > handle it by adding a new feature? > > [1] > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/plat-omap/include/plat/cpu.h#l439 > Thanks. I can add a new feature here, but I see that the API is tied to OMAP3, whereas the DMA feature is common to 3630, OMAP4 and mostly everything after that. I can work on an upgrade, but do you see that as a dependency and done on the context of this patch ? Regards, Venkat. >>> >>> Yes, I am aware that the current APIs are tied to OMAP3, no reason that >>> we >>> cant introduce a OMAP version independent feature.. Yes, IMHO, this is an >>> SOC specific feature that has no place in a platform data.. lets not >>> misuse >>> that. >>> Regards, >>> NM >> Just a note that I have updated my patch series based on all the comments except that the 'features' framework has to be created to be utilised by this patch series. That would be a separate patch, which I am working on, and will post on monday. Regards, Venkat. -- 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 1/2] omap3 nand: cleanup for not to use GPMC virtual address
On Fri, May 14, 2010 at 8:53 PM, Sukumar Ghorai wrote:
[...]
> diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
> b/arch/arm/mach-omap2/gpmc-onenand.c
> index 7bb6922..5d66817
> --- a/arch/arm/mach-omap2/gpmc-onenand.c
> +++ b/arch/arm/mach-omap2/gpmc-onenand.c
> @@ -301,7 +301,7 @@ static int omap2_onenand_set_sync_mode(struct
> omap_onenand_platform_data *cfg,
> (GPMC_CONFIG1_WAIT_READ_MON |
> GPMC_CONFIG1_WAIT_PIN_SEL(0))) |
> GPMC_CONFIG1_DEVICESIZE_16 |
> - GPMC_CONFIG1_DEVICETYPE_NOR |
> + GPMC_CONFIG1_DEVICETYPE(GPMC_DEVICETYPE_NOR) |
> GPMC_CONFIG1_MUXADDDATA);
Please do not dp OneNAND changes in NAND patch.
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 5bc3ca0..a3fd1ed
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -29,27 +29,27 @@
> #include
>
> /* GPMC register offsets */
> -#define GPMC_REVISION 0x00
> -#define GPMC_SYSCONFIG 0x10
> -#define GPMC_SYSSTATUS 0x14
> -#define GPMC_IRQSTATUS 0x18
> -#define GPMC_IRQENABLE 0x1c
> -#define GPMC_TIMEOUT_CONTROL 0x40
> -#define GPMC_ERR_ADDRESS 0x44
> -#define GPMC_ERR_TYPE 0x48
> -#define GPMC_CONFIG 0x50
> -#define GPMC_STATUS 0x54
> -#define GPMC_PREFETCH_CONFIG1 0x1e0
> -#define GPMC_PREFETCH_CONFIG2 0x1e4
> -#define GPMC_PREFETCH_CONTROL 0x1ec
> -#define GPMC_PREFETCH_STATUS 0x1f0
> -#define GPMC_ECC_CONFIG 0x1f4
> -#define GPMC_ECC_CONTROL 0x1f8
> -#define GPMC_ECC_SIZE_CONFIG 0x1fc
> -
> -#define GPMC_CS0 0x60
> -#define GPMC_CS_SIZE 0x30
> -
> +#define GPMC_REVISION 0x00
> +#define GPMC_SYSCONFIG 0x10
> +#define GPMC_SYSSTATUS 0x14
> +#define GPMC_IRQSTATUS 0x18
> +#define GPMC_IRQENABLE 0x1c
> +#define GPMC_TIMEOUT_CONTROL 0x40
> +#define GPMC_ERR_ADDRESS 0x44
> +#define GPMC_ERR_TYPE 0x48
> +#define GPMC_CONFIG 0x50
> +#define GPMC_STATUS 0x54
> +#define GPMC_PREFETCH_CONFIG1 0x1e0
> +#define GPMC_PREFETCH_CONFIG2 0x1e4
> +#define GPMC_PREFETCH_CONTROL 0x1ec
> +#define GPMC_PREFETCH_STATUS 0x1f0
> +#define GPMC_ECC_CONFIG 0x1f4
> +#define GPMC_ECC_CONTROL 0x1f8
> +#define GPMC_ECC_SIZE_CONFIG 0x1fc
> +#define GPMC_ECC1_RESULT 0x200
> +
> +#define GPMC_CS0_BASE 0x60
> +#define GPMC_CS_SIZE 0x30
> #define GPMC_MEM_START 0x
> #define GPMC_MEM_END 0x3FFF
> #define BOOT_ROM_SPACE 0x10 /* 1MB */
> @@ -108,11 +108,27 @@ static u32 gpmc_read_reg(int idx)
> return __raw_readl(gpmc_base + idx);
> }
>
> +static void gpmc_cs_write_byte(int cs, int idx, u8 val)
> +{
> + void __iomem *reg_addr;
> +
> + reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
> + __raw_writeb(val, reg_addr);
> +}
> +
> +static u8 gpmc_cs_read_byte(int cs, int idx)
> +{
> + void __iomem *reg_addr;
> +
> + reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
> + return __raw_readb(reg_addr);
> +}
> +
I do not think we need these functions.
> void gpmc_cs_write_reg(int cs, int idx, u32 val)
> {
> void __iomem *reg_addr;
>
> - reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
> + reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
> __raw_writel(val, reg_addr);
> }
>
> @@ -120,7 +136,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
> {
> void __iomem *reg_addr;
>
> - reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
> + reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
> return __raw_readl(reg_addr);
> }
>
> @@ -419,6 +435,96 @@ void gpmc_cs_free(int cs)
> EXPORT_SYMBOL(gpmc_cs_free);
>
> /**
> + * gpmc_hwcontrol - hardware specific access (read/ write) to control
> + * @write: need 1 for configure; 0 for reading the complete register
> + * @cs: chip select number
> + * @cmd: Command type
> + * @wval: value/information to write
> + * @rval: pointer to get the value back
> + */
> +int gpmc_hwcontrol(int write, int cs, int cmd, int wval, int *rval)
> +{
> + u32 reg = 0;
> + u32 regval = 0;
> +
> + switch (cmd) {
> +
> + case GPMC_GET_SET_STATUS:
> + reg = GPMC_STATUS;
> + if (write)
> + gpmc_write_reg(GPMC_STATUS, regval);
> + break;
> +
> + case GPMC_GET_SET_IRQ_STATUS:
> + reg = GPMC_IRQSTATUS;
> + if (write)
> + gpmc_write_reg(GPMC_IRQSTATUS, regval);
> + break;
> +
> + case GPMC_GET_PREF_STATUS:
> + reg = GPMC_PREFETCH_STATUS;
> + break;
> +
> + case GPMC_CONFIG_WP:
Re: [PATCH] omap: rx51: Move peripheral OMAP gpio setups to rx51_omapgpio_setup function
On Fri, 14 May 2010 08:33:51 -0700 Tony Lindgren wrote: > * Jarkko Nikula [100514 05:32]: > > Idea is to combine peripheral OMAP gpio setups in single function like what > > rx51_twlgpio_setup is doing for TWL4030 GPIOs. > > > > Currently this is mostly cleanup for wl1251 gpio setup as not testing the > > gpiolib return values and setting the wl1251_pdata statically. The wl1251 > > driver seems to cope well with uninitialized gpios or with negative irq > > number. > > We should check the return values always. If gpio_request handling > changes then we have to fix it all over the place. > Yeah, true and actually Documentation/gpio.txt is even insisting it. I was somehow recalling that checking is not necessary in early init code for soc gpios and counting only that they would fail only if CONFIG_GPIOLIB is not set or if mixing up with the same numbers in same early init code. So let's discard this one. -- Jarkko -- 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] OMAP3: PM: Workaround for DPLL3 Lock issue
shweta gulati writes:
> From: Vishwanath Sripathy
>
> OMAP3430/3630 has a Silicon bug because of which SDRC is
> released from IDLE even before Core DPLL has locked. This leads
> to undefined behaviour of SDRC DLL.
>
> This patch has workaround for the same.
>
> Description of WA for 3430:
> Initialization:
> Disable DPLL3 automatic mode by default. Issue will not be faced as
> DPLL3
> is always locked.
>
> Before CORE Voltage Domain (VDD2) Sleep Transition to RETENTION or OFF mode:
> 1.Reduce DPLL3 M2 Frequency to get L3 running at OPP2 Frequency
> (by changing M2 Divider value). This is increasing the period duration
> of
> one L3 clock cycle.
> o In case of CORE is at OPP3 (166...@1.15v):
> " Lower the frequency to 83MHz.
>
> o In case of CORE is at OPP2 (83...@1.05v):
> " Keep the frequency as it is (83MHz).
>
> 2.Increase CORE Voltage to 1.2V. This is reducing the timing duration of
> the
> critical path signal which will now fit to one L3 clock cycle.
>
> 3.Enable DPLL3 Automatic mode. This will ensure proper transition to
> RETENTION or OFF mode.
>
> After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
> 1.Disable DPLL3 Automatic mode.
> 2.Restore previous DPLL3 M2 Frequency and CORE Voltage values.
>
> Description of WA for 3630:
> Initialization:
> Disable DPLL3 automatic mode by default. Issue will not be faced as
> DPLL3 is always locked.
>
> Before CORE Voltage Domain(VDD2) Sleep Transition to RETENTION or OFF mode:
> 1.Reduce DPLL3 M2 Frequency to get L3 running at OPP50 Frequency
> (by changing M2 Divider value) and set VDD2 Voltage for OPP100.
> This is increasing the period duration of one L3 clock cycle and
> reducing
> the timing duration of the critical path signal which will now fit to
> one
> L3 clock cycle.
> o In case of CORE is at OPP100 (L3=200MHz, VDD2=1.1375V):
> " Lower the frequency to 100MHz.
> " Keep the voltage as it is (1.1375V).
>
> o In case of CORE is at OPP50 (L3=100MHz, VDD2=0.93V):
> " Keep the frequency as it is (100MHz).
> " Increase the voltage to 1.1375V.
>
> 2.Enable DPLL3 Automatic mode. This will ensure proper transition to
> RETENTION or OFF mode.
>
> After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
> 1.Disable DPLL3 Automatic mode.
> 2.Restore previous DPLL3 M2 Frequency and CORE Voltage values.
>
> Also OSWR should not be attempted if DPLL3 has locked. This should be done as
> part of OSWR patch series.
>
> Patch tested on 3430SDP and 3630 ZOOM3.
>
> Signed-off-by: Vishwanath Sripathy
> Signed-off-by: Shweta Gulati
> ---
This patch appears to depend on Thara's SR series. Please state
dependencies here.
>
> Index: linux-omap-pm/arch/arm/mach-omap2/pm.h
> ===
> --- linux-omap-pm.orig/arch/arm/mach-omap2/pm.h
> +++ linux-omap-pm/arch/arm/mach-omap2/pm.h
> @@ -60,6 +60,10 @@ struct prm_setup_vc {
>
> extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
> extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
> +extern int program_vdd2_opp_3430(void);
> +extern int reprogram_vdd2_opp_3430(int restore);
> +extern int program_vdd2_opp_3630(void);
> +extern int reprogram_vdd2_opp_3630(int restore);
>
> extern u32 wakeup_timer_seconds;
> extern struct omap_dm_timer *gptimer_wakeup;
> Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
> ===
> --- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c
> +++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
> @@ -56,6 +56,7 @@
> #include "sdrc.h"
> #include "omap3-opp.h"
>
> +
stray whitespace change
> #ifdef CONFIG_SUSPEND
> static suspend_state_t suspend_state = PM_SUSPEND_ON;
> static inline bool is_suspending(void)
> @@ -363,6 +364,8 @@ void omap_sram_idle(void)
> u32 sdrc_pwr = 0;
> int per_state_modified = 0;
> unsigned int start =0, end = 0;
> + u32 fclk_status = 0;
> + int restore = 1;
> if (!_omap_sram_idle)
> return;
>
> @@ -415,15 +418,6 @@ void omap_sram_idle(void)
> if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
> omap2_clkdm_deny_idle(mpu_pwrdm->pwrdm_clkdms[0]);
>
> - /*
> - * Disable smartreflex before entering WFI.
> - * Only needed if we are going to enter retention or off.
> - */
> - if (mpu_next_state <= PWRDM_POWER_RET)
> - omap_smartreflex_disable(VDD1, 1);
> - if (core_next_state <= PWRDM_POWER_RET)
> - omap_smartreflex_disable(VDD2, 1);
> -
> /* CORE */
> if (core_next_state < PWRDM_POWER_ON) {
> omap_uart_prepare_idle(0);
> @@ -447,6 +441,31 @@ void omap_sram_idl
Re: [PATCH v3 OMAP3 PM]: Remove IVA state conflict between PM and DspBridge code
shweta gulati writes:
> From: Shweta Gulati
>
> This version of patch incorporates review comments which includes
> shifting the code change in specific function 'omap3_iva_idle' and
> removing iva_pwrdm from pwrst_list rather than checking all the pwrdms
> in list to exclude iva_pwrdm.
Comments about the version history of a patch don't belong here. They
belong after the '---' so they are not picked up in the git history.
> The PM code should not set latency on IVA power state based on
> the flag 'enable_off_mode'.
Why? A changelog is about answering *both* 'what' and 'why'
Also the SRF change should be a separate patch since SRF is PM branch
only. The primary change here should be targetted for mainline.
> This is taken care of in this version.
>
> Signed-off-by: Sripathy Vishwanath
> Signed-off-by: Shweta Gulati
> ---
I *strongly* recommend using git-format-patch, then manually editing
this part to add patch version history.
> Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
> ===
> --- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c
> +++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
> @@ -786,6 +786,12 @@ static void __init omap3_iva_idle(void)
> OMAP3430_RST2_IVA2 |
> OMAP3430_RST3_IVA2,
> OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
> + /* Put the IVA2 In Idle */
> + prm_rmw_mod_reg_bits(OMAP3430_LASTPOWERSTATEENTERED_MASK, 0,
> + OMAP3430_IVA2_MOD, OMAP2_PM_PWSTCTRL);
huh?
this is confusing for multiple reasons
1. The comment is wrong. You're setting the nex powerstate to OFF.
2. LASTPOWERSTATEENTERED is a field in PM_PREPWSTST, not in PM_PWSTCTRL,
so the field your changing is the POWERSTATE field of PM_PWRSTCTRL.
3. setting this state is already done in pwrdms_setup()
> + /* Make Clock transition Automatic*/
nit: need a space before the '*/'
> + cm_rmw_mod_reg_bits(OMAP3430_CLKTRCTRL_IVA2_MASK, 0x3,
> + OMAP3430_IVA2_MOD, OMAP2_CM_CLKSTCTRL);
> }
>
> static void __init omap3_d2d_idle(void)
> @@ -1074,8 +1080,11 @@ static int __init pwrdms_setup(struct po
> if (!pwrst)
> return -ENOMEM;
> pwrst->pwrdm = pwrdm;
> - pwrst->next_state = PWRDM_POWER_RET;
> - list_add(&pwrst->node, &pwrst_list);
> + if (strcmp("iva2_pwrdm", pwrdm->name)) {
> + pwrst->next_state = PWRDM_POWER_RET;
> + list_add(&pwrst->node, &pwrst_list);
> + } else
> + pwrst->next_state = PWRDM_POWER_OFF;
See Documentation/CodingStyle about use of {}. If one part
of an 'if' has {}s, the other(s) should as well.
> if (pwrdm_has_hdwr_sar(pwrdm))
> pwrdm_enable_hdwr_sar(pwrdm);
> Index: linux-omap-pm/arch/arm/mach-omap2/resource34xx.c
> ===
> --- linux-omap-pm.orig/arch/arm/mach-omap2/resource34xx.c
> +++ linux-omap-pm/arch/arm/mach-omap2/resource34xx.c
> @@ -140,7 +140,8 @@ int set_pd_latency(struct shared_resourc
> }
>
> if (!enable_off_mode && pd_lat_level == PD_LATENCY_OFF)
> - pd_lat_level = PD_LATENCY_RET;
> + if (strcmp("iva2_pwrdm", pwrdm->name))
> + pd_lat_level = PD_LATENCY_RET;
>
> resp->curr_level = pd_lat_level;
> set_pwrdm_state(pwrdm, pd_lat_level);
This change should be a separate patch including a changelog that
answers "why?"
Kevin
--
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: [PATCHv3 12/22] OMAP3: PM: Minimizing the passing around of sr id in smartreflex.c
"Gopinath, Thara" writes: >>> >>>Thara Gopinath writes: >>> This patch ensures that sr id is passed as a parameter only to public APIs in smartreflex.c and other APIs in smartreflex.c uses the omap_sr strucutres. Signed-off-by: Thara Gopinath >>> >>>Good change, but... >>> [...] >>> >>>... the class3 layer is still taking SR ID as a parameter and it >>>should also just take an sr_info ptr. > > sr_info is an internal structure for smartreflex driver. The > intention behind this patch is all external API's pass the srid and > internally the driver static APIs take sr_info as parameter. OK, that makes sense. I though I saw the usage of _sr_lookup() inside the class driver which made me think it should just take sr_info. But looking again now, I see it's only using the id. > I did not realize this point till now when I was doing the actual > changes and hence the late reply :-) no worries, thanks for clarifying. Kevin -- 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: [PATCHv2 1/2]OMAP3: PM: To put all the powerdomains in OFF mode instead of Ret
shweta gulati writes: > From: Shweta Gulati > > According to Defect OMAPS00210499 CAM, DSS and USBHOST should stay > in OFF state instead of Retention in OS Idle Path. Please summarize the above defect. > This Patch puts all the powerdomain in OFF state by default > in pm init code and ensures that Mpu next state is OFF only > before it goes to Suspend/Idle and RET initiallly as that > could have caused system to hang if ROM code issues WFI. That's a long sentence that is not clear. It attempts to explain _what_ is happening, but is not clear about why. IIUC, this same patch could be done with a one-liner patch[1] > Signed-off-by: Vishwanath BS > Signed-off-by: Shweta Gulati > --- -EDOESNOTAPPLY Please state what this patch applies to. It does not apply to mainline, linux-omap or the PM branch. I see OSWR related code in this patch which means it's clearly against an internal tree. Because of that, I didn't read the rest of the patch. Kevin [1] diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 5039b35..5b93a84 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -74,7 +74,7 @@ static inline bool is_suspending(void) #define OMAP343X_TABLE_VALUE_OFFSET 0x30 #define OMAP343X_CONTROL_REG_VALUE_OFFSET 0x32 -u32 enable_off_mode; +u32 enable_off_mode = 1; u32 sleep_while_idle; u32 wakeup_timer_seconds; u32 wakeup_timer_milliseconds; -- 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] MMC: OMAP HS-MMC: convert to dev_pm_ops
Matt Fleming writes: > On Tue, 11 May 2010 14:57:16 -0700, Kevin Hilman > wrote: >> >> Note that dev_pm_ops version of the suspend hook no longer takes a >> 'state' argument. However, the MMC core function mmc_suspend_host() >> still takes a 'state' argument, but it is unused, so a dummy >> state variable was created to pass to the MMC core. > > Hmm.. instead of passing this dummy state argument why don't we just > remove the argument from mmc_suspend_host()? Like you said, it's unused, > so I don't see a reason to keep it around? I don't see a reason either, but it requires patching the MMC core as well as all the users. As I'm not an MMC core person, I thought this best left to someone in that domain. Fixing the core and callers could easily be done on top of this patch. Kevin -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, 2010-05-13 at 14:46 -0700, Greg KH wrote: > On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote: > > On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote: > > > > > Because someone would have to remove suspend blockers (or rather > > > wakelocks) > > > from the drivers, test that they work correctly without suspend blockers > > > and > > > submit the modified versions. Going forward, every party responsible for > > > such > > > a driver would have to maintain an out-of-tree version with suspend > > > blockers > > > (or wakelocks) anyway, so the incentive to do that is zero. > > > > They should work without wakelock since wakelock are optional .. I mean > > there's nothing in suspend blockers I've seen that indicates it's > > required for some drivers to work. So it's just a matter of patching out > > the wakelocks, with no need to re-test anything. > > > > You get the driver mainlined, then maintain a small patch to add > > wakelocks. Not hard at all , with lots of incentive to do so since you > > don't have to maintain such a large block of code out of tree. > > Sorry, but it doesn't seem to work that way. Look at the large number > of out-of-tree android device drivers that remain sitting there because > of the lack of this interface being in the kernel. I don't think that's due to this interface tho. During your CELF presentation you noted several bits of code that could go in right now but haven't (and still haven't as far as I've seen). I'm actively pushing code related to Android (with wakelocks removed).. Putting a wakelock contingency on everything to me doesn't make much sense. > Also note that such a driver, without wakelocks, would never get tested, > and so, things start quickly diverging. That's not totally true. For example the MMC driver had wakelocks (I think, or for sure mmc core does), and the MMC driver has been tested for G1 and works fine so far without them. I have code that is queued for my tree that will enable MMC on G1. I can merge Nexus one support through my tree also which would allow all the drivers for that device to eventually be used. With that device support in mainline then those drivers become nice things to have with or with out wakelocks. You don't need wakelocks to run Debian or anything else except Android. Daniel -- 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 v4] OMAP3: Registering sgx device and it's platform data
Manjunatha GK writes:
> The SGX powervr_device is registered with it's platform specific
> data to provide information about setting constraint through
> omap_pm_set_min_bus_tput.
Now the patch content doesn't match the description as you no
longer call omap_pm_set_min_bus_tput()...
> Signed-off-by: Preshit Agarwal
> Signed-off-by: Manjunatha GK
> Cc: Tony Lindgren
> Cc: Kevin Hilman
> Cc: Mike Turquette
> Cc: Hemanth V
> ---
> arch/arm/mach-omap2/devices.c | 21 +++--
> arch/arm/mach-omap2/include/mach/omap_sgxdef.h | 11 +++
> 2 files changed, 30 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/mach-omap2/include/mach/omap_sgxdef.h
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 2271b9b..6349ee5 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -26,7 +26,7 @@
> #include
> #include
> #include
> -
> +#include
> #include "mux.h"
>
> #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
> @@ -786,6 +786,23 @@ static inline void omap_hdq_init(void)
> static inline void omap_hdq_init(void) {}
> #endif
>
> +struct sgx_platform_data omap_sgx_data = {
> + .set_min_bus_tput = NULL,
> +};
When I suggested you remove the #ifdef CONFIG_PM, I was expecting
you to leave the omap_pm_set_min_bus_tput() part.
The point was that the driver itself should choose whether or not to call
pdata->set_min_bus_tput() using #ifdef or other runtime decisions.
Kevin
--
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: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
* Andrew Morton [100512 15:19]: > > I'd have thought that sysfs was an appropriate place for this info. > Perhaps under /sys/devices/platform? Or /sys/devices/system? Peter's > original patch didn't tell us where in the hierarchy the file was > placed, nor why it was placed there, not what its contents look like. > But crappy changelogs are the norm :( To me both proc and sys work, I'm fine either way. > The objections stated in this email: > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg17630.html > appear to still apply to this version of the patches? > > Kevin didn't explain why he said "Please export these via debugfs". > Tony didn't clearly explain why he said "I don't think we want to > export unique chip identifiers by default". The issue I had was with the unique silicon ID getting exposed by default to avoid the Pentium id number situation :) It's now handled with a Kconfig and cmdline option, basically the same way as the id on x86. So the issues in the email thread above are sorted out. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
Magnus Damm writes: > Still not sure how the system wide suspend is different from Runtime > PM and CPUidle from the hardware perspective... At least on OMAP and other embedded SoCs I'm familiar with, there is no difference from the hardware perspecitve. However, I understand that on ACPI-based systems, there are low-power that are only reachable via system-wide suspsend since ACPI does not provide the kernel with fine-grained control to hit those states during idle. That being said, I don't think this should be an issue since opportunistic suspend is currently targetted primarily at embedded HW which has much more fine-grained power control than traditional ACPI-based systems. To me the only real difference between system-wide suspend and runtime PM + CPUidle is the freezing of userspace. As has been discussed elsewhere in this discussion, any alternative solution must address the freezing/idling of userspace. Kevin -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
Matthew Garrett writes: > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: > >> The system stays running because there's something to do. The system >> won't suspend until all the processors hit the kernel idle loop and >> the next_timer_interrupt_critical() returns nothing. > > At which point an application in a busy loop cripples you. I think we > could implement your suggestion more easily by just giving untrusted > applications an effectively infinite amount of timer slack, > > but it still doesn't handle the case where an app behaves > excrutiatingly badly. Is design for exruciatingly bad apps a design requirement? If so, opportunistic suspend + suspend blockers fails as well. An app could easily hold a suspend blocker during its entire execution crippling PM. Using opportunistic suspend may possibly allow you contain bad apps/drivers, but at the cost of having to patch already working and trusted apps and known-working kernel code with suspend blockers. IMO, rather than accepting a solution that allows bad apps to run wild, it would be much better to _continue_ focus on tools for finding and containing bad apps. This approach has the added bonus of solving problems on *every* linux-based system, not just Android. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Initial attempt to make ARM use LMB
* Shilimkar, Santosh [100514 08:28]: > > > > Yeah, that missing patch was it. Compiles and boots now: > > > > Tested-by: Tony Lindgren > > Did you get the frame buffer with lmb ?? I've never gotten a DSS2 frame buffer yet with the code that's in omap for-next, but I believe Tomi has the missing pieces queued up. My tested-by was for the patch not breaking the current behaviour, basically to make sure things boot. So since it's really half tested, maybe acked-by would be more suitable. 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] omap: rx51: Move peripheral OMAP gpio setups to rx51_omapgpio_setup function
* Jarkko Nikula [100514 05:32]: > Idea is to combine peripheral OMAP gpio setups in single function like what > rx51_twlgpio_setup is doing for TWL4030 GPIOs. > > Currently this is mostly cleanup for wl1251 gpio setup as not testing the > gpiolib return values and setting the wl1251_pdata statically. The wl1251 > driver seems to cope well with uninitialized gpios or with negative irq > number. We should check the return values always. If gpio_request handling changes then we have to fix it all over the place. 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: [RFC] Initial attempt to make ARM use LMB
Tony, > -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony > Lindgren > Sent: Friday, May 14, 2010 8:52 PM > To: Russell King - ARM Linux > Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; Tomi > Valkeinen > Subject: Re: [RFC] Initial attempt to make ARM use LMB > > * Russell King - ARM Linux [100513 15:07]: > > On Thu, May 13, 2010 at 03:01:39PM -0700, Tony Lindgren wrote: > > > * Russell King - ARM Linux [100513 14:53]: > > > > On Thu, May 13, 2010 at 02:19:51PM -0700, Tony Lindgren wrote: > > > > > * Russell King - ARM Linux [100513 10:35]: > > > > > > And here's a patch which converts the OMAP FB code to use > > > > > > lmb_reserve > > > > > > instead of poking about with bootmem stuff. Untested, so I'd like > > > > > > to > > > > > > hear back whether it works. > > > > > > > > > > Did a quick test with the following patches picked from your lmb > > > > > branch on top of omap for-next branch: > > > > > > > > > > ARM: Remove useless linux/bootmem.h includes > > > > > ARM: Ensure meminfo is sorted prior to sanity_check_meminfo > > > > > ARM: initial LMB trial > > > > > ARM: Move platform LMB memory reservations out of generic code > > > > > > > > > > and then this patch. > > > > > > > > > > It does not boot.. It seems to be related to the patch > > > > > "ARM: initial LMB trial". If I only apply the first two patches > > > > > above the system boots. > > > > > > > > Hmm, I'm sure it worked for me when I tested it out. Could you try > > > > booting with lmb=debug please? > > > > > > No other output with that it seems. > > > > Hang on, you didn't pick up ARM: Move memory mapping into mmu.c ? > > Hmm, looks like I did not send a reply yesterday.. Here's a > second attempt. > > Yeah, that missing patch was it. Compiles and boots now: > > Tested-by: Tony Lindgren Did you get the frame buffer with lmb ?? -- 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 1/2] omap3 nand: cleanup for not to use GPMC virtual address
* Sukumar Ghorai [100514 08:18]: > Necessary function added in GPMC module and used by nand driver. This is for > not to use GPMC address directly from nand driver. Also it was passing GPMC > base address from board files and that is removed. Great, this is starting to look good! I'll take a closer look today, some quick comments below. > --- a/arch/arm/mach-omap2/gpmc.c > +++ b/arch/arm/mach-omap2/gpmc.c > @@ -29,27 +29,27 @@ > #include > > /* GPMC register offsets */ > -#define GPMC_REVISION0x00 > -#define GPMC_SYSCONFIG 0x10 > -#define GPMC_SYSSTATUS 0x14 > -#define GPMC_IRQSTATUS 0x18 > -#define GPMC_IRQENABLE 0x1c > -#define GPMC_TIMEOUT_CONTROL 0x40 > -#define GPMC_ERR_ADDRESS 0x44 > -#define GPMC_ERR_TYPE0x48 > -#define GPMC_CONFIG 0x50 > -#define GPMC_STATUS 0x54 > -#define GPMC_PREFETCH_CONFIG10x1e0 > -#define GPMC_PREFETCH_CONFIG20x1e4 > -#define GPMC_PREFETCH_CONTROL0x1ec > -#define GPMC_PREFETCH_STATUS 0x1f0 > -#define GPMC_ECC_CONFIG 0x1f4 > -#define GPMC_ECC_CONTROL 0x1f8 > -#define GPMC_ECC_SIZE_CONFIG 0x1fc > - > -#define GPMC_CS0 0x60 > -#define GPMC_CS_SIZE 0x30 > - > +#define GPMC_REVISION 0x00 > +#define GPMC_SYSCONFIG 0x10 > +#define GPMC_SYSSTATUS 0x14 > +#define GPMC_IRQSTATUS 0x18 > +#define GPMC_IRQENABLE 0x1c > +#define GPMC_TIMEOUT_CONTROL0x40 > +#define GPMC_ERR_ADDRESS0x44 > +#define GPMC_ERR_TYPE 0x48 > +#define GPMC_CONFIG 0x50 > +#define GPMC_STATUS 0x54 > +#define GPMC_PREFETCH_CONFIG1 0x1e0 > +#define GPMC_PREFETCH_CONFIG2 0x1e4 > +#define GPMC_PREFETCH_CONTROL 0x1ec > +#define GPMC_PREFETCH_STATUS0x1f0 > +#define GPMC_ECC_CONFIG 0x1f4 > +#define GPMC_ECC_CONTROL0x1f8 > +#define GPMC_ECC_SIZE_CONFIG0x1fc > +#define GPMC_ECC1_RESULT0x200 > + > +#define GPMC_CS0_BASE0x60 > +#define GPMC_CS_SIZE0x30 > #define GPMC_MEM_START 0x > #define GPMC_MEM_END 0x3FFF > #define BOOT_ROM_SPACE 0x10/* 1MB */ These defines should not be modified that much, looks like some spaces sneaked in instead of tabs? Maybe also split this patch into two: First add the new functions, then remove and convert everything to use the new functions. 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
[PATCH v2 1/2] omap3 nand: cleanup for not to use GPMC virtual address
Necessary function added in GPMC module and used by nand driver. This is for
not to use GPMC address directly from nand driver. Also it was passing GPMC
base address from board files and that is removed.
Signed-off-by: Sukumar Ghorai
---
arch/arm/mach-omap2/board-cm-t35.c |4 -
arch/arm/mach-omap2/board-devkit8000.c |9 -
arch/arm/mach-omap2/board-omap3beagle.c|8 -
arch/arm/mach-omap2/board-omap3touchbook.c |9 -
arch/arm/mach-omap2/board-overo.c |7 -
arch/arm/mach-omap2/gpmc-nand.c| 38 ++
arch/arm/mach-omap2/gpmc-onenand.c |2 +-
arch/arm/mach-omap2/gpmc.c | 244
arch/arm/plat-omap/include/plat/gpmc.h | 36 -
arch/arm/plat-omap/include/plat/nand.h |6 +-
drivers/mtd/nand/omap2.c | 190 ++
11 files changed, 301 insertions(+), 252 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index f4e8063..87bed2a
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -61,8 +61,6 @@
#define SB_T35_SMSC911X_GPIO 65
#define NAND_BLOCK_SIZESZ_128K
-#define GPMC_CS0_BASE 0x60
-#define GPMC_CS0_BASE_ADDR (OMAP34XX_GPMC_VIRT + GPMC_CS0_BASE)
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
#include
@@ -223,8 +221,6 @@ static struct omap_nand_platform_data cm_t35_nand_data = {
.nr_parts = ARRAY_SIZE(cm_t35_nand_partitions),
.dma_channel= -1, /* disable DMA in OMAP NAND driver */
.cs = 0,
- .gpmc_cs_baseaddr = (void __iomem *)GPMC_CS0_BASE_ADDR,
- .gpmc_baseaddr = (void __iomem *)OMAP34XX_GPMC_VIRT,
};
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 6d910df..ef9b677
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -58,9 +58,6 @@
#include "mux.h"
#include "hsmmc.h"
-#define GPMC_CS0_BASE 0x60
-#define GPMC_CS_SIZE 0x30
-
#define NAND_BLOCK_SIZESZ_128K
#define OMAP_DM9000_GPIO_IRQ 25
@@ -581,8 +578,6 @@ static void __init devkit8000_flash_init(void)
u8 cs = 0;
u8 nandcs = GPMC_CS_NUM + 1;
- u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
-
/* find out the chip-select on which NAND exists */
while (cs < GPMC_CS_NUM) {
u32 ret = 0;
@@ -604,10 +599,6 @@ static void __init devkit8000_flash_init(void)
if (nandcs < GPMC_CS_NUM) {
devkit8000_nand_data.cs = nandcs;
- devkit8000_nand_data.gpmc_cs_baseaddr = (void *)
- (gpmc_base_add + GPMC_CS0_BASE + nandcs * GPMC_CS_SIZE);
- devkit8000_nand_data.gpmc_baseaddr = (void *)
- (gpmc_base_add);
printk(KERN_INFO "Registering NAND on CS%d\n", nandcs);
if (platform_device_register(&devkit8000_nand_device) < 0)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 5df89f6..e90dd2a
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -47,9 +47,6 @@
#include "mux.h"
#include "hsmmc.h"
-#define GPMC_CS0_BASE 0x60
-#define GPMC_CS_SIZE 0x30
-
#define NAND_BLOCK_SIZESZ_128K
static struct mtd_partition omap3beagle_nand_partitions[] = {
@@ -377,8 +374,6 @@ static void __init omap3beagle_flash_init(void)
u8 cs = 0;
u8 nandcs = GPMC_CS_NUM + 1;
- u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
-
/* find out the chip-select on which NAND exists */
while (cs < GPMC_CS_NUM) {
u32 ret = 0;
@@ -400,9 +395,6 @@ static void __init omap3beagle_flash_init(void)
if (nandcs < GPMC_CS_NUM) {
omap3beagle_nand_data.cs = nandcs;
- omap3beagle_nand_data.gpmc_cs_baseaddr = (void *)
- (gpmc_base_add + GPMC_CS0_BASE + nandcs * GPMC_CS_SIZE);
- omap3beagle_nand_data.gpmc_baseaddr = (void *) (gpmc_base_add);
printk(KERN_INFO "Registering NAND on CS%d\n", nandcs);
if (platform_device_register(&omap3beagle_nand_device) < 0)
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index c59050d..4a6c984
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -54,9 +54,6 @@
#include
-#define GPMC_CS0_BASE 0x60
-#define GPMC_CS_SIZE 0x30
-
#define NAND_BLOCK_SIZESZ_128K
#define OMAP3_AC_GPIO 136
@@ -459,8 +456,6 @@ static void __init omap3touchbook_flash_init(void)
u8 cs = 0;
u8 nandcs = GPMC_CS_NUM + 1;
- u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
-
/* find out the chip-select on which NAND e
[PATCH v2 2/2] omap3 nand: fix issue in board file to detect the nand
Board file modified to pass the GMPC phys_base address to nand driver. This is
required to adopt the _prob function as in omap2.c
Signed-off-by: Sukumar Ghorai
---
arch/arm/mach-omap2/board-cm-t35.c | 16 +---
arch/arm/mach-omap2/board-devkit8000.c | 16 +---
arch/arm/mach-omap2/board-omap3beagle.c| 16 +---
arch/arm/mach-omap2/board-omap3touchbook.c | 16 +---
arch/arm/mach-omap2/board-overo.c | 17 +
5 files changed, 5 insertions(+), 76 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index fb23122..0544294
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -224,23 +224,9 @@ static struct omap_nand_platform_data cm_t35_nand_data = {
};
-static struct resource cm_t35_nand_resource = {
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device cm_t35_nand_device = {
- .name = "omap2-nand",
- .id = -1,
- .num_resources = 1,
- .resource = &cm_t35_nand_resource,
- .dev= {
- .platform_data = &cm_t35_nand_data,
- },
-};
-
static void __init cm_t35_init_nand(void)
{
- if (platform_device_register(&cm_t35_nand_device) < 0)
+ if (gpmc_nand_init(&cm_t35_nand_data) < 0)
pr_err("CM-T35: Unable to register NAND device\n");
}
#else
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index ca4e409..9a8135d
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -101,20 +101,6 @@ static struct omap_nand_platform_data devkit8000_nand_data
= {
.dma_channel= -1, /* disable DMA in OMAP NAND driver */
};
-static struct resource devkit8000_nand_resource = {
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device devkit8000_nand_device = {
- .name = "omap2-nand",
- .id = -1,
- .dev= {
- .platform_data = &devkit8000_nand_data,
- },
- .num_resources = 1,
- .resource = &devkit8000_nand_resource,
-};
-
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
@@ -601,7 +587,7 @@ static void __init devkit8000_flash_init(void)
devkit8000_nand_data.cs = nandcs;
printk(KERN_INFO "Registering NAND on CS%d\n", nandcs);
- if (platform_device_register(&devkit8000_nand_device) < 0)
+ if (gpmc_nand_init(&devkit8000_nand_data) < 0)
printk(KERN_ERR "Unable to register NAND device\n");
}
}
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index becaebe..bf31b7c
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -89,20 +89,6 @@ static struct omap_nand_platform_data omap3beagle_nand_data
= {
.dev_ready = NULL,
};
-static struct resource omap3beagle_nand_resource = {
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device omap3beagle_nand_device = {
- .name = "omap2-nand",
- .id = -1,
- .dev= {
- .platform_data = &omap3beagle_nand_data,
- },
- .num_resources = 1,
- .resource = &omap3beagle_nand_resource,
-};
-
#include "sdram-micron-mt46h32m32lf-6.h"
static struct omap2_hsmmc_info mmc[] = {
@@ -397,7 +383,7 @@ static void __init omap3beagle_flash_init(void)
omap3beagle_nand_data.cs = nandcs;
printk(KERN_INFO "Registering NAND on CS%d\n", nandcs);
- if (platform_device_register(&omap3beagle_nand_device) < 0)
+ if (gpmc_nand_init(&omap3beagle_nand_data) < 0)
printk(KERN_ERR "Unable to register NAND device\n");
}
}
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index d6f1b12..e8ad30c
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -103,20 +103,6 @@ static struct omap_nand_platform_data
omap3touchbook_nand_data = {
.dev_ready = NULL,
};
-static struct resource omap3touchbook_nand_resource = {
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device omap3touchbook_nand_device = {
- .name = "omap2-nand",
- .id = -1,
- .dev= {
- .platform_data = &omap3touchbook_nand_data,
- },
- .num_resources = 1,
- .resource = &omap3touchbook_nand_resource,
-};
-
#include "sdram-micron-mt46h32m32lf-6.h"
static struct omap2_hsmmc_info mmc[] = {
@@ -479,7 +465,7 @@ static void __init omap3touchbook_flash_init(void)
omap3touchbook_nan
[PATCH v2 0/2] omap3 nand: cleanup exiting platform related code
v2: The following set of patches applies on top of master branch. http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git Patches verified on: omap3430-SDP, omap3630-sdp, zoom3 and beagle board And these are the patches required to address the following input - 1. The NAND driver needs to stop tinkering with the GPMC registers The omap General Purpose Memory Controller (GPMC) registers are omap specific, and not driver specific. Tinkering with these registers can cause issues with the other devices on the GPMC. 2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files Passing hardcoded GPMC virtual addressess is sure way to mess up things. This should all become unnecessary once the NAND drivers stops messing with the GPMC registers directly. v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28164.html Sukumar Ghorai (2): omap3 nand: cleanup for not to use GPMC virtual address omap3 nand: fix issue in board file to detect the nand arch/arm/mach-omap2/board-cm-t35.c | 20 +--- arch/arm/mach-omap2/board-devkit8000.c | 25 +--- arch/arm/mach-omap2/board-omap3beagle.c| 24 +--- arch/arm/mach-omap2/board-omap3touchbook.c | 25 +--- arch/arm/mach-omap2/board-overo.c | 24 +--- arch/arm/mach-omap2/gpmc-nand.c| 38 ++ arch/arm/mach-omap2/gpmc-onenand.c |2 +- arch/arm/mach-omap2/gpmc.c | 244 arch/arm/plat-omap/include/plat/gpmc.h | 36 - arch/arm/plat-omap/include/plat/nand.h |6 +- drivers/mtd/nand/omap2.c | 190 ++ 11 files changed, 306 insertions(+), 328 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: [RFC] Initial attempt to make ARM use LMB
* Russell King - ARM Linux [100513 15:07]: > On Thu, May 13, 2010 at 03:01:39PM -0700, Tony Lindgren wrote: > > * Russell King - ARM Linux [100513 14:53]: > > > On Thu, May 13, 2010 at 02:19:51PM -0700, Tony Lindgren wrote: > > > > * Russell King - ARM Linux [100513 10:35]: > > > > > And here's a patch which converts the OMAP FB code to use lmb_reserve > > > > > instead of poking about with bootmem stuff. Untested, so I'd like to > > > > > hear back whether it works. > > > > > > > > Did a quick test with the following patches picked from your lmb > > > > branch on top of omap for-next branch: > > > > > > > > ARM: Remove useless linux/bootmem.h includes > > > > ARM: Ensure meminfo is sorted prior to sanity_check_meminfo > > > > ARM: initial LMB trial > > > > ARM: Move platform LMB memory reservations out of generic code > > > > > > > > and then this patch. > > > > > > > > It does not boot.. It seems to be related to the patch > > > > "ARM: initial LMB trial". If I only apply the first two patches > > > > above the system boots. > > > > > > Hmm, I'm sure it worked for me when I tested it out. Could you try > > > booting with lmb=debug please? > > > > No other output with that it seems. > > Hang on, you didn't pick up ARM: Move memory mapping into mmu.c ? Hmm, looks like I did not send a reply yesterday.. Here's a second attempt. Yeah, that missing patch was it. Compiles and boots now: Tested-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/17] omap: mailbox: reorganize init
Hi Felipe, On Fri, May 14, 2010 at 6:01 PM, Felipe Contreras wrote: > Hi, > > The main purpose of this patch series is to be able to compile mach platform > data as built-in. Otherwise, client modules such as bridgedriver will load the > platform code, but not the mach code when mailbox is built as a module. > > Unfortunately, there's no easy way to do that since plat and mach code are > deepely interrelated. So the first patches try to separate the mailbox > registering through a defined omap_mbox_platform_data. Have you considered converting mailbox to hwmod + omap_device ? Thanks, Ohad. > > Also, it's worth noting that mailboxes are not a one-to-one mapping to > resources; that is, some resources belong to multiple mboxes. So it's best to > think of mailboxes as fake devices. That is why custom platform_data is > required. > > Finally, a bunch of cleaning up is done in the very first patches, specially > for > OMAP1. > > The initial RFC included comments from Felipe Balbi, and this proposal > includes > comments from Tony Lindgren. > > v2: > * Rebased on top of Hiroshi's v2.6.34-rc7.mailbox > * A bit more extra cleanups > > v1 was tested on OMAP3 (beagleboard), and compiled-tested for OMAP1. > v2 was compile-tested for OMAP3 and 1. > > Felipe Contreras (17): > omap: mailbox: trivial whitespace cleanups > omap: mailbox: trivial cleanups > omap: mailbox: reorganize structures > omap: mailbox: 2420 should be detected at run-time > omap: mailbox: use correct config for omap1 > omap: mailbox: update omap1 probing > omap: mailbox: reorganize registering > omap: mailbox: only compile for configured archs > omap: mailbox: reorganize omap platform_device > omap: mailbox: move more stuff to omap_mbox_init() > omap: mailbox: trivial sync between omap1 and 2 > omap: mailbox: split platform driver > omap: mailbox: always built-in platform data > omap: mailbox: reorganize headers > omap: mailbox: don't export unecessary symbols > omap: mailbox: mark some resources as __initdata > omap: mailbox: don't export register/unregister > > arch/arm/mach-omap1/Makefile | 6 +- > arch/arm/mach-omap1/devices.c | 40 - > arch/arm/mach-omap1/mailbox.c | 118 -- > arch/arm/mach-omap2/Makefile | 5 +- > arch/arm/mach-omap2/devices.c | 92 --- > arch/arm/mach-omap2/mailbox.c | 254 > - > arch/arm/plat-omap/include/plat/mailbox.h | 10 +- > arch/arm/plat-omap/mailbox.c | 89 +++--- > 8 files changed, 290 insertions(+), 324 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/15] omap: mailbox: reorganize init
On Fri, May 14, 2010 at 12:12 PM, Hiroshi DOYU wrote: > Can you rebase them against the following? > > git://gitorious.org/~doyu/lk/mainline.git v2.6.34-rc7.mailbox Done. > The above includes the unmerged patches for omap mailbox, and it seems > that yours can be applied to neither v2.6.34-rc7 or omap/master now. Yeah, I didn't know where to rebase to, so I just used what I was running: v2.6.33. -- Felipe Contreras -- 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 17/17] omap: mailbox: don't export register/unregister
No need for that now.
Signed-off-by: Felipe Contreras
---
arch/arm/plat-omap/include/plat/mailbox.h |3 ---
arch/arm/plat-omap/mailbox.c |6 ++
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index cbde52a..e01be54 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -78,9 +78,6 @@ void omap_mbox_init_seq(struct omap_mbox *);
struct omap_mbox *omap_mbox_get(const char *);
void omap_mbox_put(struct omap_mbox *);
-int omap_mbox_register(struct device *parent, struct omap_mbox *);
-int omap_mbox_unregister(struct omap_mbox *);
-
static inline void omap_mbox_save_ctx(struct omap_mbox *mbox)
{
if (!mbox->ops->save_ctx) {
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index c7d28fa..88d67c4 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -347,7 +347,7 @@ void omap_mbox_put(struct omap_mbox *mbox)
}
EXPORT_SYMBOL(omap_mbox_put);
-int omap_mbox_register(struct device *parent, struct omap_mbox *mbox)
+static int omap_mbox_register(struct device *parent, struct omap_mbox *mbox)
{
int ret = 0;
struct omap_mbox **tmp;
@@ -372,9 +372,8 @@ int omap_mbox_register(struct device *parent, struct
omap_mbox *mbox)
err_find:
return ret;
}
-EXPORT_SYMBOL(omap_mbox_register);
-int omap_mbox_unregister(struct omap_mbox *mbox)
+static int omap_mbox_unregister(struct omap_mbox *mbox)
{
struct omap_mbox **tmp;
@@ -393,7 +392,6 @@ int omap_mbox_unregister(struct omap_mbox *mbox)
return -EINVAL;
}
-EXPORT_SYMBOL(omap_mbox_unregister);
static int __devinit omap_mbox_probe(struct platform_device *pdev)
{
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 16/17] omap: mailbox: mark some resources as __initdata
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/mailbox.c |2 +-
arch/arm/mach-omap2/mailbox.c |6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 7e6aea3..aa661a1 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -144,7 +144,7 @@ struct omap_mbox mbox_dsp_info = {
struct omap_mbox *omap1_mboxes[] = { &mbox_dsp_info, NULL };
#if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX)
-static struct resource omap1_mbox_resources[] = {
+static struct resource __initdata omap1_mbox_resources[] = {
{
.start = OMAP16XX_MAILBOX_BASE,
.end= OMAP16XX_MAILBOX_BASE, /* to be updated */
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index f230edb..ddaf7f0 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -389,7 +389,7 @@ struct omap_mbox *omap4_mboxes[] = { &mbox_1_info,
&mbox_2_info, NULL };
#endif
#ifdef CONFIG_ARCH_OMAP2420
-static struct resource omap2_mbox_resources[] = {
+static struct resource __initdata omap2_mbox_resources[] = {
{
.start = OMAP24XX_MAILBOX_BASE,
.end= OMAP24XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
@@ -407,7 +407,7 @@ static struct resource omap2_mbox_resources[] = {
#endif
#ifdef CONFIG_ARCH_OMAP3430
-static struct resource omap3_mbox_resources[] = {
+static struct resource __initdata omap3_mbox_resources[] = {
{
.start = OMAP34XX_MAILBOX_BASE,
.end= OMAP34XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
@@ -421,7 +421,7 @@ static struct resource omap3_mbox_resources[] = {
#endif
#ifdef CONFIG_ARCH_OMAP4
-static struct resource omap4_mbox_resources[] = {
+static struct resource __initdata omap4_mbox_resources[] = {
{
.start = OMAP44XX_MAILBOX_BASE,
.end= OMAP44XX_MAILBOX_BASE + OMAP4_MBOX_REG_SIZE -
1,
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 15/17] omap: mailbox: don't export unecessary symbols
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/mailbox.c |1 -
arch/arm/mach-omap2/mailbox.c |3 ---
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index f6376b9..7e6aea3 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -140,7 +140,6 @@ struct omap_mbox mbox_dsp_info = {
.ops= &omap1_mbox_ops,
.priv = &omap1_mbox_dsp_priv,
};
-EXPORT_SYMBOL(mbox_dsp_info);
struct omap_mbox *omap1_mboxes[] = { &mbox_dsp_info, NULL };
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index c1a732e..f230edb 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -306,7 +306,6 @@ struct omap_mbox mbox_dsp_info = {
.ops= &omap2_mbox_ops,
.priv = &omap2_mbox_dsp_priv,
};
-EXPORT_SYMBOL(mbox_dsp_info);
#endif
#if defined(CONFIG_ARCH_OMAP3430)
@@ -363,7 +362,6 @@ struct omap_mbox mbox_1_info = {
.ops= &omap2_mbox_ops,
.priv = &omap2_mbox_1_priv,
};
-EXPORT_SYMBOL(mbox_1_info);
static struct omap_mbox2_priv omap2_mbox_2_priv = {
.tx_fifo = {
@@ -386,7 +384,6 @@ struct omap_mbox mbox_2_info = {
.ops= &omap2_mbox_ops,
.priv = &omap2_mbox_2_priv,
};
-EXPORT_SYMBOL(mbox_2_info);
struct omap_mbox *omap4_mboxes[] = { &mbox_1_info, &mbox_2_info, NULL };
#endif
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 13/17] omap: mailbox: always built-in platform data
Signed-off-by: Felipe Contreras --- arch/arm/mach-omap1/Makefile |6 +++--- arch/arm/mach-omap2/Makefile |5 +++-- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile index b6a537c..c1e1ae5 100644 --- a/arch/arm/mach-omap1/Makefile +++ b/arch/arm/mach-omap1/Makefile @@ -14,9 +14,9 @@ obj-$(CONFIG_OMAP_32K_TIMER) += timer32k.o # Power Management obj-$(CONFIG_PM) += pm.o sleep.o -# DSP -obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o -mailbox_mach-objs := mailbox.o +ifneq ($(CONFIG_OMAP_MBOX_FWK),) +obj-y += mailbox.o +endif i2c-omap-$(CONFIG_I2C_OMAP):= i2c.o obj-y += $(i2c-omap-m) $(i2c-omap-y) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 4b9fc57..c9757fb 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -86,8 +86,9 @@ obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_3xxx_data.o # EMU peripherals obj-$(CONFIG_OMAP3_EMU)+= emu.o -obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o -mailbox_mach-objs := mailbox.o +ifneq ($(CONFIG_OMAP_MBOX_FWK),) +obj-y += mailbox.o +endif iommu-y+= iommu2.o iommu-$(CONFIG_ARCH_OMAP3) += omap3-iommu.o -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 14/17] omap: mailbox: reorganize headers
Signed-off-by: Felipe Contreras --- arch/arm/mach-omap1/mailbox.c |3 --- arch/arm/mach-omap2/mailbox.c |1 - arch/arm/plat-omap/include/plat/mailbox.h |3 ++- arch/arm/plat-omap/mailbox.c |5 ++--- 4 files changed, 4 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c index f29ba8e..f6376b9 100644 --- a/arch/arm/mach-omap1/mailbox.c +++ b/arch/arm/mach-omap1/mailbox.c @@ -9,13 +9,10 @@ * for more details. */ -#include -#include #include #include #include #include -#include #define MAILBOX_ARM2DSP1 0x00 #define MAILBOX_ARM2DSP1b 0x04 diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index a54898a..c1a732e 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -10,7 +10,6 @@ * for more details. */ -#include #include #include #include diff --git a/arch/arm/plat-omap/include/plat/mailbox.h b/arch/arm/plat-omap/include/plat/mailbox.h index b68fdc3..cbde52a 100644 --- a/arch/arm/plat-omap/include/plat/mailbox.h +++ b/arch/arm/plat-omap/include/plat/mailbox.h @@ -3,9 +3,10 @@ #ifndef MAILBOX_H #define MAILBOX_H -#include +#include #include #include +#include #include typedef u32 mbox_msg_t; diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c index 6b2f3b3..c7d28fa 100644 --- a/arch/arm/plat-omap/mailbox.c +++ b/arch/arm/plat-omap/mailbox.c @@ -21,10 +21,9 @@ * */ -#include -#include #include -#include +#include +#include #include #include #include -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 12/17] omap: mailbox: split platform driver
This will allow the current 'mailbox_mach' to be built-in.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/mailbox.c | 50 +
arch/arm/mach-omap2/mailbox.c | 50 +
arch/arm/plat-omap/include/plat/mailbox.h |4 ++
arch/arm/plat-omap/mailbox.c | 46 +-
4 files changed, 64 insertions(+), 86 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 91780a0..f29ba8e 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -161,51 +161,13 @@ static struct resource omap1_mbox_resources[] = {
};
#endif
-static int __devinit omap1_mbox_probe(struct platform_device *pdev)
-{
- struct resource *res;
- int ret;
- int i;
-
- res = pdev->resource;
-
- for (i = 0; list[i]; i++) {
- ret = omap_mbox_register(&pdev->dev, list[i]);
- if (ret)
- goto err_out;
- }
- return 0;
-
-err_out:
- while (i--)
- omap_mbox_unregister(list[i]);
- return ret;
-}
-
-static int __devexit omap1_mbox_remove(struct platform_device *pdev)
-{
- int i;
-
- for (i = 0; list[i]; i++)
- omap_mbox_unregister(list[i]);
-
- return 0;
-}
-
-static struct platform_driver omap1_mbox_driver = {
- .probe = omap1_mbox_probe,
- .remove = __devexit_p(omap1_mbox_remove),
- .driver = {
- .name = "omap1-mailbox",
- },
-};
-
static int __init omap1_mbox_init(void)
{
int err;
struct platform_device *pdev;
struct resource *res;
unsigned num;
+ struct omap_mbox_platform_data pdata;
if (false);
#if defined(CONFIG_ARCH_OMAP15XX)
@@ -233,7 +195,7 @@ static int __init omap1_mbox_init(void)
return -ENODEV;
}
- pdev = platform_device_alloc("omap1-mailbox", -1);
+ pdev = platform_device_alloc("omap-mailbox", -1);
if (!pdev) {
err = -ENOMEM;
goto err_out;
@@ -243,6 +205,11 @@ static int __init omap1_mbox_init(void)
if (err)
goto err_out;
+ pdata.list = list;
+ err = platform_device_add_data(pdev, &pdata, sizeof(pdata));
+ if (err)
+ goto err_out;
+
err = platform_device_add(pdev);
if (err)
goto err_out;
@@ -253,7 +220,7 @@ static int __init omap1_mbox_init(void)
return -ENOMEM;
}
- return platform_driver_register(&omap1_mbox_driver);
+ return 0;
err_out:
return err;
@@ -261,7 +228,6 @@ err_out:
static void __exit omap1_mbox_exit(void)
{
- platform_driver_unregister(&omap1_mbox_driver);
iounmap(mbox_base);
}
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index adbf5d7..a54898a 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -438,51 +438,13 @@ static struct resource omap4_mbox_resources[] = {
};
#endif
-static int __devinit omap2_mbox_probe(struct platform_device *pdev)
-{
- struct resource *res;
- int ret;
- int i;
-
- res = pdev->resource;
-
- for (i = 0; list[i]; i++) {
- ret = omap_mbox_register(&pdev->dev, list[i]);
- if (ret)
- goto err_out;
- }
- return 0;
-
-err_out:
- while (i--)
- omap_mbox_unregister(list[i]);
- return ret;
-}
-
-static int __devexit omap2_mbox_remove(struct platform_device *pdev)
-{
- int i;
-
- for (i = 0; list[i]; i++)
- omap_mbox_unregister(list[i]);
-
- return 0;
-}
-
-static struct platform_driver omap2_mbox_driver = {
- .probe = omap2_mbox_probe,
- .remove = __devexit_p(omap2_mbox_remove),
- .driver = {
- .name = "omap2-mailbox",
- },
-};
-
static int __init omap2_mbox_init(void)
{
int err;
struct platform_device *pdev;
struct resource *res;
unsigned num;
+ struct omap_mbox_platform_data pdata;
if (false);
#if defined(CONFIG_ARCH_OMAP3430)
@@ -519,7 +481,7 @@ static int __init omap2_mbox_init(void)
return -ENODEV;
}
- pdev = platform_device_alloc("omap2-mailbox", -1);
+ pdev = platform_device_alloc("omap-mailbox", -1);
if (!pdev) {
err = -ENOMEM;
goto err_out;
@@ -529,6 +491,11 @@ static int __init omap2_mbox_init(void)
if (err)
goto err_out;
+ pdata.list = list;
+ err = platform_device_add_data(pdev, &pdata, sizeof(pdata));
+ if (err)
+ goto err_out;
+
err = platform_device_add(pdev);
if (err)
goto err_out;
@@ -539,7 +506,7 @@ static int __init omap2_mbox_init(void)
return -ENOMEM;
}
[PATCH v2 10/17] omap: mailbox: move more stuff to omap_mbox_init()
Will be needed to split the platform_driver.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/mailbox.c | 23 +++
arch/arm/mach-omap2/mailbox.c | 49 +++--
2 files changed, 31 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 25f1f89..8c1b83f 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -169,14 +169,6 @@ static int __devinit omap1_mbox_probe(struct
platform_device *pdev)
res = pdev->resource;
- mbox_base = ioremap(res[0].start, resource_size(&res[0]));
- if (!mbox_base)
- return -ENOMEM;
-
- list = omap1_mboxes;
-
- list[0]->irq = res[1].start;
-
for (i = 0; list[i]; i++) {
ret = omap_mbox_register(&pdev->dev, list[i]);
if (ret)
@@ -187,7 +179,6 @@ static int __devinit omap1_mbox_probe(struct
platform_device *pdev)
err_out:
while (i--)
omap_mbox_unregister(list[i]);
- iounmap(mbox_base);
return ret;
}
@@ -198,7 +189,6 @@ static int __devexit omap1_mbox_remove(struct
platform_device *pdev)
for (i = 0; list[i]; i++)
omap_mbox_unregister(list[i]);
- iounmap(mbox_base);
return 0;
}
@@ -222,14 +212,20 @@ static int __init omap1_mbox_init(void)
else if (cpu_is_omap15xx()) {
res = omap1_mbox_resources;
num = ARRAY_SIZE(omap1_mbox_resources);
+ list = omap1_mboxes;
+
res[1].end += 0x23;
+ list[0]->irq = res[1].start;
}
#endif
#if defined(CONFIG_ARCH_OMAP16XX)
else if (cpu_is_omap16xx()) {
res = omap1_mbox_resources;
num = ARRAY_SIZE(omap1_mbox_resources);
+ list = omap1_mboxes;
+
res[1].end += 0x2f;
+ list[0]->irq = res[1].start;
}
#endif
else {
@@ -251,6 +247,12 @@ static int __init omap1_mbox_init(void)
if (err)
goto err_out;
+ mbox_base = ioremap(res[0].start, resource_size(&res[0]));
+ if (!mbox_base) {
+ platform_device_put(pdev);
+ return -ENOMEM;
+ }
+
return platform_driver_register(&omap1_mbox_driver);
err_out:
@@ -260,6 +262,7 @@ err_out:
static void __exit omap1_mbox_exit(void)
{
platform_driver_unregister(&omap1_mbox_driver);
+ iounmap(mbox_base);
}
module_init(omap1_mbox_init);
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 59e85fd..4f3b84e 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -448,35 +448,6 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
res = pdev->resource;
- mbox_base = ioremap(res[0].start, resource_size(&res[0]));
- if (!mbox_base)
- return -ENOMEM;
-
- if (false);
-#if defined(CONFIG_ARCH_OMAP3430)
- else if (cpu_is_omap3430()) {
- list = omap3_mboxes;
-
- list[0]->irq = res[1].start;
- }
-#endif
-#if defined(CONFIG_ARCH_OMAP2420)
- else if (cpu_is_omap2420()) {
- list = omap2_mboxes;
-
- list[0]->irq = res[1].start;
- list[1]->irq = res[2].start;
- }
-#endif
-#if defined(CONFIG_ARCH_OMAP4)
- else if (cpu_is_omap44xx()) {
- list = omap4_mboxes;
-
- list[0]->irq = res[1].start;
- list[1]->irq = res[1].start;
- }
-#endif
-
for (i = 0; list[i]; i++) {
ret = omap_mbox_register(&pdev->dev, list[i]);
if (ret)
@@ -487,7 +458,6 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
err_out:
while (i--)
omap_mbox_unregister(list[i]);
- iounmap(mbox_base);
return ret;
}
@@ -498,7 +468,6 @@ static int __devexit omap2_mbox_remove(struct
platform_device *pdev)
for (i = 0; list[i]; i++)
omap_mbox_unregister(list[i]);
- iounmap(mbox_base);
return 0;
}
@@ -522,18 +491,29 @@ static int __init omap2_mbox_init(void)
else if (cpu_is_omap3430()) {
res = omap3_mbox_resources;
num = ARRAY_SIZE(omap3_mbox_resources);
+ list = omap3_mboxes;
+
+ list[0]->irq = res[1].start;
}
#endif
#if defined(CONFIG_ARCH_OMAP2420)
else if (cpu_is_omap2420()) {
res = omap2_mbox_resources;
num = ARRAY_SIZE(omap2_mbox_resources);
+ list = omap2_mboxes;
+
+ list[0]->irq = res[1].start;
+ list[1]->irq = res[2].start;
}
#endif
#if defined(CONFIG_ARCH_OMAP4)
else if (cpu_is_omap44xx()) {
res = omap4_mbox_resources;
num = ARRAY_SIZE(omap4_mbox_resources);
+ list =
[PATCH v2 11/17] omap: mailbox: trivial sync between omap1 and 2
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/mailbox.c |2 +-
arch/arm/mach-omap2/mailbox.c |6 ++
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 8c1b83f..91780a0 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -1,5 +1,5 @@
/*
- * Mailbox reservation modules for DSP
+ * Mailbox reservation modules for OMAP1
*
* Copyright (C) 2006-2009 Nokia Corporation
* Written by: Hiroshi DOYU
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 4f3b84e..adbf5d7 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -18,8 +18,6 @@
#include
#include
-#define DRV_NAME "omap2-mailbox"
-
#define MAILBOX_REVISION 0x000
#define MAILBOX_SYSCONFIG 0x010
#define MAILBOX_SYSSTATUS 0x014
@@ -475,7 +473,7 @@ static struct platform_driver omap2_mbox_driver = {
.probe = omap2_mbox_probe,
.remove = __devexit_p(omap2_mbox_remove),
.driver = {
- .name = DRV_NAME,
+ .name = "omap2-mailbox",
},
};
@@ -560,4 +558,4 @@ MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("omap mailbox: omap2/3/4 architecture specific functions");
MODULE_AUTHOR("Hiroshi DOYU ");
MODULE_AUTHOR("Paul Mundt");
-MODULE_ALIAS("platform:"DRV_NAME);
+MODULE_ALIAS("platform:omap2-mailbox");
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 09/17] omap: mailbox: reorganize omap platform_device
Makes more sense to register in the mach file, plus it will allow more
functionality later on.
Also, this probably enables multi-omap for real.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/devices.c | 38
arch/arm/mach-omap1/mailbox.c | 56
arch/arm/mach-omap2/devices.c | 92 ---
arch/arm/mach-omap2/mailbox.c | 96 +++--
4 files changed, 148 insertions(+), 134 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index da796f2..093dd13 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -63,43 +63,6 @@ static void omap_init_rtc(void)
static inline void omap_init_rtc(void) {}
#endif
-#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
-
-#if defined(CONFIG_ARCH_OMAP15XX)
-# define OMAP1_MBOX_SIZE 0x23
-# define INT_DSP_MAILBOX1 INT_1510_DSP_MAILBOX1
-#elif defined(CONFIG_ARCH_OMAP16XX)
-# define OMAP1_MBOX_SIZE 0x2f
-# define INT_DSP_MAILBOX1 INT_1610_DSP_MAILBOX1
-#endif
-
-static struct resource mbox_resources[] = {
- {
- .start = OMAP16XX_MAILBOX_BASE,
- .end= OMAP16XX_MAILBOX_BASE + OMAP1_MBOX_SIZE,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = INT_DSP_MAILBOX1,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device mbox_device = {
- .name = "omap1-mailbox",
- .id = -1,
- .num_resources = ARRAY_SIZE(mbox_resources),
- .resource = mbox_resources,
-};
-
-static inline void omap_init_mbox(void)
-{
- platform_device_register(&mbox_device);
-}
-#else
-static inline void omap_init_mbox(void) { }
-#endif
-
/*-*/
#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)
@@ -293,7 +256,6 @@ static int __init omap1_init_devices(void)
* in alphabetical order so they're easier to sort through.
*/
- omap_init_mbox();
omap_init_rtc();
omap_init_spi100k();
omap_init_sti();
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index d81b238..25f1f89 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -147,6 +147,20 @@ EXPORT_SYMBOL(mbox_dsp_info);
struct omap_mbox *omap1_mboxes[] = { &mbox_dsp_info, NULL };
+#if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX)
+static struct resource omap1_mbox_resources[] = {
+ {
+ .start = OMAP16XX_MAILBOX_BASE,
+ .end= OMAP16XX_MAILBOX_BASE, /* to be updated */
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = 10,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+#endif
+
static int __devinit omap1_mbox_probe(struct platform_device *pdev)
{
struct resource *res;
@@ -198,7 +212,49 @@ static struct platform_driver omap1_mbox_driver = {
static int __init omap1_mbox_init(void)
{
+ int err;
+ struct platform_device *pdev;
+ struct resource *res;
+ unsigned num;
+
+ if (false);
+#if defined(CONFIG_ARCH_OMAP15XX)
+ else if (cpu_is_omap15xx()) {
+ res = omap1_mbox_resources;
+ num = ARRAY_SIZE(omap1_mbox_resources);
+ res[1].end += 0x23;
+ }
+#endif
+#if defined(CONFIG_ARCH_OMAP16XX)
+ else if (cpu_is_omap16xx()) {
+ res = omap1_mbox_resources;
+ num = ARRAY_SIZE(omap1_mbox_resources);
+ res[1].end += 0x2f;
+ }
+#endif
+ else {
+ pr_err("%s: platform not supported\n", __func__);
+ return -ENODEV;
+ }
+
+ pdev = platform_device_alloc("omap1-mailbox", -1);
+ if (!pdev) {
+ err = -ENOMEM;
+ goto err_out;
+ }
+
+ err = platform_device_add_resources(pdev, res, num);
+ if (err)
+ goto err_out;
+
+ err = platform_device_add(pdev);
+ if (err)
+ goto err_out;
+
return platform_driver_register(&omap1_mbox_driver);
+
+err_out:
+ return err;
}
static void __exit omap1_mbox_exit(void)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2271b9b..eac0e0f 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -136,97 +136,6 @@ static inline void omap_init_camera(void)
}
#endif
-#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
-
-#define MBOX_REG_SIZE 0x120
-
-#ifdef CONFIG_ARCH_OMAP2
-static struct resource omap2_mbox_resources[] = {
- {
- .start = OMAP24XX_MAILBOX_BASE,
- .end= OMAP24X
[PATCH v2 08/17] omap: mailbox: only compile for configured archs
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap2/mailbox.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 5dda11c..04b70ba 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -286,6 +286,7 @@ static struct omap_mbox_ops omap2_mbox_ops = {
/* FIXME: the following structs should be filled automatically by the user id
*/
+#if defined(CONFIG_ARCH_OMAP3430) || defined(CONFIG_ARCH_OMAP2420)
/* DSP */
static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.tx_fifo = {
@@ -309,11 +310,13 @@ struct omap_mbox mbox_dsp_info = {
.priv = &omap2_mbox_dsp_priv,
};
EXPORT_SYMBOL(mbox_dsp_info);
+#endif
+#if defined(CONFIG_ARCH_OMAP3430)
struct omap_mbox *omap3_mboxes[] = { &mbox_dsp_info, NULL };
+#endif
#if defined(CONFIG_ARCH_OMAP2420)
-
/* IVA */
static struct omap_mbox2_priv omap2_mbox_iva_priv = {
.tx_fifo = {
@@ -340,6 +343,7 @@ static struct omap_mbox mbox_iva_info = {
struct omap_mbox *omap2_mboxes[] = { &mbox_iva_info, &mbox_dsp_info, NULL };
#endif
+#if defined(CONFIG_ARCH_OMAP4)
/* OMAP4 */
static struct omap_mbox2_priv omap2_mbox_1_priv = {
.tx_fifo = {
@@ -388,6 +392,7 @@ struct omap_mbox mbox_2_info = {
EXPORT_SYMBOL(mbox_2_info);
struct omap_mbox *omap4_mboxes[] = { &mbox_1_info, &mbox_2_info, NULL };
+#endif
static int __devinit omap2_mbox_probe(struct platform_device *pdev)
{
@@ -401,11 +406,14 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
if (!mbox_base)
return -ENOMEM;
- if (cpu_is_omap3430()) {
+ if (false);
+#if defined(CONFIG_ARCH_OMAP3430)
+ else if (cpu_is_omap3430()) {
list = omap3_mboxes;
list[0]->irq = res[1].start;
}
+#endif
#if defined(CONFIG_ARCH_OMAP2420)
else if (cpu_is_omap2420()) {
list = omap2_mboxes;
@@ -414,12 +422,14 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
list[1]->irq = res[2].start;
}
#endif
+#if defined(CONFIG_ARCH_OMAP4)
else if (cpu_is_omap44xx()) {
list = omap4_mboxes;
list[0]->irq = res[1].start;
list[1]->irq = res[1].start;
}
+#endif
else {
pr_err("%s: platform not supported\n", __func__);
return -ENODEV;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/17] omap: mailbox: reorganize registering
This is a step forward to split the mbox registers.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/mailbox.c | 41 +
arch/arm/mach-omap2/mailbox.c | 102 +
2 files changed, 64 insertions(+), 79 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 211b9fc..d81b238 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -29,6 +29,8 @@
static void __iomem *mbox_base;
+static struct omap_mbox **list;
+
struct omap_mbox1_fifo {
unsigned long cmd;
unsigned long data;
@@ -143,44 +145,45 @@ struct omap_mbox mbox_dsp_info = {
};
EXPORT_SYMBOL(mbox_dsp_info);
+struct omap_mbox *omap1_mboxes[] = { &mbox_dsp_info, NULL };
+
static int __devinit omap1_mbox_probe(struct platform_device *pdev)
{
struct resource *res;
int ret;
+ int i;
- /* MBOX base */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (unlikely(!res)) {
- dev_err(&pdev->dev, "invalid mem resource\n");
- return -ENODEV;
- }
+ res = pdev->resource;
- mbox_base = ioremap(res->start, resource_size(res));
+ mbox_base = ioremap(res[0].start, resource_size(&res[0]));
if (!mbox_base)
return -ENOMEM;
- /* DSP IRQ */
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (unlikely(!res)) {
- dev_err(&pdev->dev, "invalid irq resource\n");
- ret = -ENODEV;
- goto err_out;
- }
- mbox_dsp_info.irq = res->start;
+ list = omap1_mboxes;
- ret = omap_mbox_register(&pdev->dev, &mbox_dsp_info);
- if (ret)
- goto err_out;
+ list[0]->irq = res[1].start;
+
+ for (i = 0; list[i]; i++) {
+ ret = omap_mbox_register(&pdev->dev, list[i]);
+ if (ret)
+ goto err_out;
+ }
return 0;
err_out:
+ while (i--)
+ omap_mbox_unregister(list[i]);
iounmap(mbox_base);
return ret;
}
static int __devexit omap1_mbox_remove(struct platform_device *pdev)
{
- omap_mbox_unregister(&mbox_dsp_info);
+ int i;
+
+ for (i = 0; list[i]; i++)
+ omap_mbox_unregister(list[i]);
+
iounmap(mbox_base);
return 0;
}
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 7afc9aa..5dda11c 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -56,6 +56,8 @@
static void __iomem *mbox_base;
+static struct omap_mbox **list;
+
struct omap_mbox2_fifo {
unsigned long msg;
unsigned long fifo_stat;
@@ -308,6 +310,8 @@ struct omap_mbox mbox_dsp_info = {
};
EXPORT_SYMBOL(mbox_dsp_info);
+struct omap_mbox *omap3_mboxes[] = { &mbox_dsp_info, NULL };
+
#if defined(CONFIG_ARCH_OMAP2420)
/* IVA */
@@ -332,6 +336,8 @@ static struct omap_mbox mbox_iva_info = {
.ops= &omap2_mbox_ops,
.priv = &omap2_mbox_iva_priv,
};
+
+struct omap_mbox *omap2_mboxes[] = { &mbox_iva_info, &mbox_dsp_info, NULL };
#endif
/* OMAP4 */
@@ -381,89 +387,65 @@ struct omap_mbox mbox_2_info = {
};
EXPORT_SYMBOL(mbox_2_info);
+struct omap_mbox *omap4_mboxes[] = { &mbox_1_info, &mbox_2_info, NULL };
+
static int __devinit omap2_mbox_probe(struct platform_device *pdev)
{
struct resource *res;
int ret;
+ int i;
- /* MBOX base */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (unlikely(!res)) {
- dev_err(&pdev->dev, "invalid mem resource\n");
- return -ENODEV;
- }
- mbox_base = ioremap(res->start, resource_size(res));
+ res = pdev->resource;
+
+ mbox_base = ioremap(res[0].start, resource_size(&res[0]));
if (!mbox_base)
return -ENOMEM;
- /* DSP or IVA2 IRQ */
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (cpu_is_omap3430()) {
+ list = omap3_mboxes;
- if (unlikely(!res)) {
- dev_err(&pdev->dev, "invalid irq resource\n");
- ret = -ENODEV;
- goto err_dsp;
+ list[0]->irq = res[1].start;
}
- if (cpu_is_omap44xx()) {
- mbox_1_info.irq = res->start;
- ret = omap_mbox_register(&pdev->dev, &mbox_1_info);
- } else {
- mbox_dsp_info.irq = res->start;
- ret = omap_mbox_register(&pdev->dev, &mbox_dsp_info);
+#if defined(CONFIG_ARCH_OMAP2420)
+ else if (cpu_is_omap2420()) {
+ list = omap2_mboxes;
+
+ list[0]->irq = res[1].start;
+ list[1]->irq = res[2].start;
}
- if (ret)
- goto err_dsp;
+#endif
+ else if (cpu_is_omap44xx()) {
+ list = omap4_mboxes;
- if (cpu_is_omap44xx()) {
-
[PATCH v2 06/17] omap: mailbox: update omap1 probing
Based on omap2 code.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/mailbox.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 15bf2a2..211b9fc 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -146,12 +146,7 @@ EXPORT_SYMBOL(mbox_dsp_info);
static int __devinit omap1_mbox_probe(struct platform_device *pdev)
{
struct resource *res;
-
- if (pdev->num_resources != 2) {
- dev_err(&pdev->dev, "invalid number of resources: %d\n",
- pdev->num_resources);
- return -ENODEV;
- }
+ int ret;
/* MBOX base */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -161,27 +156,32 @@ static int __devinit omap1_mbox_probe(struct
platform_device *pdev)
}
mbox_base = ioremap(res->start, resource_size(res));
- if (!mbox_base) {
- dev_err(&pdev->dev, "ioremap failed\n");
- return -ENODEV;
- }
+ if (!mbox_base)
+ return -ENOMEM;
/* DSP IRQ */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (unlikely(!res)) {
dev_err(&pdev->dev, "invalid irq resource\n");
- iounmap(mbox_base);
- return -ENODEV;
+ ret = -ENODEV;
+ goto err_out;
}
mbox_dsp_info.irq = res->start;
- return omap_mbox_register(&pdev->dev, &mbox_dsp_info);
+ ret = omap_mbox_register(&pdev->dev, &mbox_dsp_info);
+ if (ret)
+ goto err_out;
+ return 0;
+
+err_out:
+ iounmap(mbox_base);
+ return ret;
}
static int __devexit omap1_mbox_remove(struct platform_device *pdev)
{
omap_mbox_unregister(&mbox_dsp_info);
-
+ iounmap(mbox_base);
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/17] omap: mailbox: use correct config for omap1
CONFIG_OMAP_DSP is not in mainline, CONFIG_OMAP_MBOX_FWK is.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/devices.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 462b59c..da796f2 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -63,7 +63,7 @@ static void omap_init_rtc(void)
static inline void omap_init_rtc(void) {}
#endif
-#if defined(CONFIG_OMAP_DSP) || defined(CONFIG_OMAP_DSP_MODULE)
+#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
#if defined(CONFIG_ARCH_OMAP15XX)
# define OMAP1_MBOX_SIZE 0x23
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/17] omap: mailbox: reorganize structures
OMAP4 ones messed up the organization.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap2/mailbox.c | 68 +
1 files changed, 35 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index c9f3d39..7d42034 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -283,6 +283,7 @@ static struct omap_mbox_ops omap2_mbox_ops = {
*/
/* FIXME: the following structs should be filled automatically by the user id
*/
+
/* DSP */
static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.tx_fifo = {
@@ -300,8 +301,40 @@ static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.irqdisable = MAILBOX_IRQENABLE(0),
};
-/* OMAP4 specific data structure. Use the cpu_is_omap4xxx()
-to use this*/
+struct omap_mbox mbox_dsp_info = {
+ .name = "dsp",
+ .ops= &omap2_mbox_ops,
+ .priv = &omap2_mbox_dsp_priv,
+};
+EXPORT_SYMBOL(mbox_dsp_info);
+
+#if defined(CONFIG_ARCH_OMAP2420)
+
+/* IVA */
+static struct omap_mbox2_priv omap2_mbox_iva_priv = {
+ .tx_fifo = {
+ .msg= MAILBOX_MESSAGE(2),
+ .fifo_stat = MAILBOX_FIFOSTATUS(2),
+ },
+ .rx_fifo = {
+ .msg= MAILBOX_MESSAGE(3),
+ .msg_stat = MAILBOX_MSGSTATUS(3),
+ },
+ .irqenable = MAILBOX_IRQENABLE(3),
+ .irqstatus = MAILBOX_IRQSTATUS(3),
+ .notfull_bit= MAILBOX_IRQ_NOTFULL(2),
+ .newmsg_bit = MAILBOX_IRQ_NEWMSG(3),
+ .irqdisable = MAILBOX_IRQENABLE(3),
+};
+
+static struct omap_mbox mbox_iva_info = {
+ .name = "iva",
+ .ops= &omap2_mbox_ops,
+ .priv = &omap2_mbox_iva_priv,
+};
+#endif
+
+/* OMAP4 */
static struct omap_mbox2_priv omap2_mbox_1_priv = {
.tx_fifo = {
.msg= MAILBOX_MESSAGE(0),
@@ -325,13 +358,6 @@ struct omap_mbox mbox_1_info = {
};
EXPORT_SYMBOL(mbox_1_info);
-struct omap_mbox mbox_dsp_info = {
- .name = "dsp",
- .ops= &omap2_mbox_ops,
- .priv = &omap2_mbox_dsp_priv,
-};
-EXPORT_SYMBOL(mbox_dsp_info);
-
static struct omap_mbox2_priv omap2_mbox_2_priv = {
.tx_fifo = {
.msg= MAILBOX_MESSAGE(3),
@@ -355,30 +381,6 @@ struct omap_mbox mbox_2_info = {
};
EXPORT_SYMBOL(mbox_2_info);
-#if defined(CONFIG_ARCH_OMAP2420) /* IVA */
-static struct omap_mbox2_priv omap2_mbox_iva_priv = {
- .tx_fifo = {
- .msg= MAILBOX_MESSAGE(2),
- .fifo_stat = MAILBOX_FIFOSTATUS(2),
- },
- .rx_fifo = {
- .msg= MAILBOX_MESSAGE(3),
- .msg_stat = MAILBOX_MSGSTATUS(3),
- },
- .irqenable = MAILBOX_IRQENABLE(3),
- .irqstatus = MAILBOX_IRQSTATUS(3),
- .notfull_bit= MAILBOX_IRQ_NOTFULL(2),
- .newmsg_bit = MAILBOX_IRQ_NEWMSG(3),
- .irqdisable = MAILBOX_IRQENABLE(3),
-};
-
-static struct omap_mbox mbox_iva_info = {
- .name = "iva",
- .ops= &omap2_mbox_ops,
- .priv = &omap2_mbox_iva_priv,
-};
-#endif
-
static int __devinit omap2_mbox_probe(struct platform_device *pdev)
{
struct resource *res;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/17] omap: mailbox: 2420 should be detected at run-time
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap2/mailbox.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 7d42034..7afc9aa 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -455,7 +455,8 @@ err_dsp:
static int __devexit omap2_mbox_remove(struct platform_device *pdev)
{
#if defined(CONFIG_ARCH_OMAP2420)
- omap_mbox_unregister(&mbox_iva_info);
+ if (cpu_is_omap2420())
+ omap_mbox_unregister(&mbox_iva_info);
#endif
if (cpu_is_omap44xx()) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 02/17] omap: mailbox: trivial cleanups
And fix a few compilation warnings.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/devices.c |6 ++
arch/arm/mach-omap1/mailbox.c |2 +-
arch/arm/mach-omap2/mailbox.c |8 +---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 379100c..462b59c 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -73,12 +73,10 @@ static inline void omap_init_rtc(void) {}
# define INT_DSP_MAILBOX1 INT_1610_DSP_MAILBOX1
#endif
-#define OMAP1_MBOX_BASEOMAP16XX_MAILBOX_BASE
-
static struct resource mbox_resources[] = {
{
- .start = OMAP1_MBOX_BASE,
- .end= OMAP1_MBOX_BASE + OMAP1_MBOX_SIZE,
+ .start = OMAP16XX_MAILBOX_BASE,
+ .end= OMAP16XX_MAILBOX_BASE + OMAP1_MBOX_SIZE,
.flags = IORESOURCE_MEM,
},
{
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 4f5b3da..15bf2a2 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -83,7 +83,7 @@ static int omap1_mbox_fifo_full(struct omap_mbox *mbox)
struct omap_mbox1_fifo *fifo =
&((struct omap_mbox1_priv *)mbox->priv)->rx_fifo;
- return (mbox_read_reg(fifo->flag));
+ return mbox_read_reg(fifo->flag);
}
/* irq */
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 763272c..c9f3d39 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -300,8 +300,6 @@ static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.irqdisable = MAILBOX_IRQENABLE(0),
};
-
-
/* OMAP4 specific data structure. Use the cpu_is_omap4xxx()
to use this*/
static struct omap_mbox2_priv omap2_mbox_1_priv = {
@@ -357,7 +355,6 @@ struct omap_mbox mbox_2_info = {
};
EXPORT_SYMBOL(mbox_2_info);
-
#if defined(CONFIG_ARCH_OMAP2420) /* IVA */
static struct omap_mbox2_priv omap2_mbox_iva_priv = {
.tx_fifo = {
@@ -443,6 +440,11 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
#endif
return 0;
+#if defined(CONFIG_ARCH_OMAP2420) /* IVA */
+err_iva1:
+ omap_mbox_unregister(&mbox_dsp_info);
+#endif
+
err_dsp:
iounmap(mbox_base);
return ret;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/17] omap: mailbox: trivial whitespace cleanups
Signed-off-by: Felipe Contreras
---
FWIW I think this should be squashed to the commits that introduced these
problems.
arch/arm/plat-omap/mailbox.c | 32
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index c549af3..8cb82c7 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -142,14 +142,14 @@ static void mbox_rx_work(struct work_struct *work)
struct omap_mbox_queue *mq =
container_of(work, struct omap_mbox_queue, work);
mbox_msg_t msg;
- int len;
-
- while (kfifo_len(&mq->fifo) >= sizeof(msg)) {
- len = kfifo_out(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
- WARN_ON(len != sizeof(msg));
-
- if (mq->callback)
- mq->callback((void *)msg);
+ int len;
+
+ while (kfifo_len(&mq->fifo) >= sizeof(msg)) {
+ len = kfifo_out(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
+ WARN_ON(len != sizeof(msg));
+
+ if (mq->callback)
+ mq->callback((void *)msg);
}
}
@@ -165,12 +165,12 @@ static void __mbox_tx_interrupt(struct omap_mbox *mbox)
static void __mbox_rx_interrupt(struct omap_mbox *mbox)
{
- struct omap_mbox_queue *mq = mbox->rxq;
+ struct omap_mbox_queue *mq = mbox->rxq;
mbox_msg_t msg;
- int len;
+ int len;
while (!mbox_fifo_empty(mbox)) {
- if (unlikely(kfifo_avail(&mq->fifo) < sizeof(msg))) {
+ if (unlikely(kfifo_avail(&mq->fifo) < sizeof(msg))) {
omap_mbox_disable_irq(mbox, IRQ_RX);
rq_full = true;
goto nomem;
@@ -178,8 +178,8 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
msg = mbox_fifo_read(mbox);
- len = kfifo_in(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
- WARN_ON(len != sizeof(msg));
+ len = kfifo_in(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
+ WARN_ON(len != sizeof(msg));
if (mbox->ops->type == OMAP_MBOX_TYPE1)
break;
@@ -278,11 +278,11 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
return 0;
- fail_alloc_rxq:
+fail_alloc_rxq:
mbox_queue_free(mbox->txq);
- fail_alloc_txq:
+fail_alloc_txq:
free_irq(mbox->irq, mbox);
- fail_request_irq:
+fail_request_irq:
if (mbox->ops->shutdown)
mbox->ops->shutdown(mbox);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/17] omap: mailbox: reorganize init
Hi, The main purpose of this patch series is to be able to compile mach platform data as built-in. Otherwise, client modules such as bridgedriver will load the platform code, but not the mach code when mailbox is built as a module. Unfortunately, there's no easy way to do that since plat and mach code are deepely interrelated. So the first patches try to separate the mailbox registering through a defined omap_mbox_platform_data. Also, it's worth noting that mailboxes are not a one-to-one mapping to resources; that is, some resources belong to multiple mboxes. So it's best to think of mailboxes as fake devices. That is why custom platform_data is required. Finally, a bunch of cleaning up is done in the very first patches, specially for OMAP1. The initial RFC included comments from Felipe Balbi, and this proposal includes comments from Tony Lindgren. v2: * Rebased on top of Hiroshi's v2.6.34-rc7.mailbox * A bit more extra cleanups v1 was tested on OMAP3 (beagleboard), and compiled-tested for OMAP1. v2 was compile-tested for OMAP3 and 1. Felipe Contreras (17): omap: mailbox: trivial whitespace cleanups omap: mailbox: trivial cleanups omap: mailbox: reorganize structures omap: mailbox: 2420 should be detected at run-time omap: mailbox: use correct config for omap1 omap: mailbox: update omap1 probing omap: mailbox: reorganize registering omap: mailbox: only compile for configured archs omap: mailbox: reorganize omap platform_device omap: mailbox: move more stuff to omap_mbox_init() omap: mailbox: trivial sync between omap1 and 2 omap: mailbox: split platform driver omap: mailbox: always built-in platform data omap: mailbox: reorganize headers omap: mailbox: don't export unecessary symbols omap: mailbox: mark some resources as __initdata omap: mailbox: don't export register/unregister arch/arm/mach-omap1/Makefile |6 +- arch/arm/mach-omap1/devices.c | 40 - arch/arm/mach-omap1/mailbox.c | 118 -- arch/arm/mach-omap2/Makefile |5 +- arch/arm/mach-omap2/devices.c | 92 --- arch/arm/mach-omap2/mailbox.c | 254 - arch/arm/plat-omap/include/plat/mailbox.h | 10 +- arch/arm/plat-omap/mailbox.c | 89 +++--- 8 files changed, 290 insertions(+), 324 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: [RFC PATCHv2 2/7] OMAP SSI: Introducing OMAP SSI driver
Hi Carlos,
Please see my comments inlined.
On Friday 07 May 2010 17:18:32 Carlos Chinea wrote:
[strip]
> diff --git a/drivers/hsi/controllers/omap_ssi.c
[strip]
> +
> +/**
> + * struct omap_ssm_ctx - OMAP synchronous serial module (TX/RX) context
> + * @mode: Bit transmission mode
> + * @channels: Number of channels
> + * @framesize: Frame size in bits
> + * @timeout: RX frame timeout
> + * @divisot: TX divider
Typo: s/divisot/divisor
> + * @arb_mode: Arbitration mode for TX frame (Round robin, priority)
> + */
> +struct omap_ssm_ctx {
> + u32 mode;
> + u32 channels;
> + u32 frame_size;
> + union {
> + u32 timeout; /* Rx Only */
> + struct {
> + u32 arb_mode;
> + u32 divisor;
> + }; /* Tx only */
> + };
> +};
> +
> +/**
> + * struct omap_ssi_port - OMAP SSI port data
> + * @dev: device associated to the port (HSI port)
> + * @sst_dma: SSI transmitter physical base address
> + * @ssr_dma: SSI receiver physical base address
> + * @sst_base: SSI transmitter base address
> + * @ssr_base: SSI receiver base address
wk_lock description is missing here
> + * @lock: Spin lock to serialize access to the SSI port
> + * @channels: Current number of channels configured (1,2,4 or 8)
> + * @txqueue: TX message queues
> + * @rxqueue: RX message queues
> + * @brkqueue: Queue of incoming HWBREAK requests (FRAME mode)
> + * @irq: IRQ number
> + * @wake_irq: IRQ number for incoming wake line (-1 if none)
> + * @pio_tasklet: Bottom half for PIO transfers and events
> + * @wake_tasklet: Bottom half for incoming wake events
> + * @wkin_cken: Keep track of clock references due to the incoming wake
> line
> + * @wake_refcount: Reference count for output wake line
s/wake_refcount/wk_refcount
> + * @sys_mpu_enable: Context for the interrupt enable register for irq 0
> + * @sst: Context for the synchronous serial transmitter
> + * @ssr: Context for the synchronous serial receiver
> + */
> +struct omap_ssi_port {
> + struct device *dev;
> + dma_addr_t sst_dma;
> + dma_addr_t ssr_dma;
> + unsigned long sst_base;
> + unsigned long ssr_base;
> + spinlock_t wk_lock;
> + spinlock_t lock;
> + unsigned intchannels;
> + struct list_headtxqueue[SSI_MAX_CHANNELS];
> + struct list_headrxqueue[SSI_MAX_CHANNELS];
> + struct list_headbrkqueue;
> + unsigned intirq;
> + int wake_irq;
> + struct tasklet_struct pio_tasklet;
> + struct tasklet_struct wake_tasklet;
> + unsigned intwkin_cken:1; /* Workaround */
> + int wk_refcount;
> + /* OMAP SSI port context */
> + u32 sys_mpu_enable; /* We use only one irq */
> + struct omap_ssm_ctx sst;
> + struct omap_ssm_ctx ssr;
> +};
> +
[strip]
> +
> +static void ssi_pio_complete(struct hsi_port *port, struct list_head
> *queue) +{
> + struct hsi_controller *ssi =
> to_hsi_controller(port->device.parent); + struct omap_ssi_controller
> *omap_ssi = hsi_controller_drvdata(ssi); + struct omap_ssi_port
> *omap_port = hsi_port_drvdata(port);
> + struct hsi_msg *msg;
> + u32 *buf;
> + u32 val;
> +
> + spin_lock(&omap_port->lock);
> + msg = list_first_entry(queue, struct hsi_msg, link);
> + if ((!msg->sgt.nents) || (!msg->sgt.sgl->length)) {
> + msg->actual_len = 0;
> + msg->status = HSI_STATUS_PENDING;
> + }
> + if (msg->status == HSI_STATUS_PROCEDING) {
> + buf = sg_virt(msg->sgt.sgl) + msg->actual_len;
> + if (msg->ttype == HSI_MSG_WRITE)
> + __raw_writel(*buf, omap_port->sst_base +
> +
> SSI_SST_BUFFER_CH_REG(msg->channel)); +else
> + *buf = __raw_readl(omap_port->ssr_base +
> +
> SSI_SSR_BUFFER_CH_REG(msg->channel)); +
> dev_dbg(&port->device, "ch %d ttype %d 0x%08x\n", msg->channel, +
> msg->ttype, *buf); +
> msg->actual_len += sizeof(*buf);
> + if (msg->actual_len >= msg->sgt.sgl->length)
> + msg->status = HSI_STATUS_COMPLETED;
> + /*
> +* Wait for the last written frame to be really sent before
> +* we call the complete callback
> +*/
> + if ((msg->status == HSI_STATUS_PROCEDING) ||
> + ((msg->status == HSI_STATUS_COMPLETED) &&
> + (msg->ttype == HSI_MSG_WRITE)))
> +
Re: [RFC PATCHv2 1/7] HSI: Introducing HSI framework
Hi Carlos,
After review, I do not have many comments on the interface, as we already
aligned on most of it.
Please see my comments inlined below.
On Friday 07 May 2010 17:18:31 Carlos Chinea wrote:
[strip]
> diff --git a/include/linux/hsi/hsi.h b/include/linux/hsi/hsi.h
[strip]
> +/**
> + * hsi_start_tx - Signal the port that the client wants to start a TX
> + * @cl: Pointer to the HSI client
> + *
> + * Return -errno on failure, 0 on success
> + */
> +static inline int hsi_start_tx(struct hsi_client *cl)
> +{
> + if (!hsi_port_claimed(cl))
> + return -EACCES;
> + return hsi_get_port(cl)->start_tx(cl);
> +}
> +
> +/**
> + * hsi_stop_tx - Signal the port that the client no longer wants to
> transmit + * @cl: Pointer to the HSI client
> + *
> + * Return -errno on failure, 0 on success
> + */
> +static inline int hsi_stop_tx(struct hsi_client *cl)
> +{
> + if (!hsi_port_claimed(cl))
> + return -EACCES;
> + return hsi_get_port(cl)->stop_tx(cl);
> +}
As I can see, these two I/F functions are the way an HSI protocol layer can
play with Tx_wake lines if it has to, right?
I suppose it allows more flexibility with regards to 3/4 wires HSI flavors
management and avoids additional callbacks to Tx_wake related events?
--
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 RFC 2/2] usb: ehci-omap: add suspend/resume support
Alan Stern wrote:
> On Thu, 13 May 2010, Anand Gadiyar wrote:
>
> > Add support for suspend and resume to the ehci-omap driver.
> > Added routines for platform_driver suspend/resume and
> > wrappers around ehci_bus_suspend/resume.
>
> > +#ifdef CONFIG_PM
> >
> /*-*/
> > +static int ehci_omap_dev_suspend(struct device *dev)
> > +{
> > + struct ehci_hcd_omap *omap = dev_get_drvdata(dev);
> > +
> > + if (!omap->suspended)
> > + ehci_omap_enable(omap, 0);
> > + return 0;
> > +}
> > +
> > +static int ehci_omap_dev_resume(struct device *dev)
> > +{
> > + struct ehci_hcd_omap *omap = dev_get_drvdata(dev);
> > +
> > + if (omap->suspended)
> > + ehci_omap_enable(omap, 1);
> > + return 0;
> > +}
> > +
> > +static int ehci_omap_bus_suspend(struct usb_hcd *hcd)
> > +{
> > + struct usb_bus *bus = hcd_to_bus(hcd);
> > + int ret;
> > +
> > + ret = ehci_bus_suspend(hcd);
> > +
> > + ehci_omap_dev_suspend(bus->controller);
> > +
> > + return ret;
> > +}
> > +static int ehci_omap_bus_resume(struct usb_hcd *hcd)
> > +{
> > + struct usb_bus *bus = hcd_to_bus(hcd);
> > + int ret;
> > +
> > + ehci_omap_dev_resume(bus->controller);
> > +
> > + ret = ehci_bus_resume(hcd);
> > +
> > + return ret;
> > +}
>
> You could use the runtime-PM interface instead of explicitly suspending
> and resuming the controller. It is now standard.
>
Will work on this. I'll be out for a while, so it could be some time
before I repost.
Thanks,
Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB video capture shuts up
si...@santesteban.eu wrote: > > si...@santesteban.eu wrote: > >> Hi I am using a v4l2 usb video capturer (em28xx based), and it is working > >> fine for around 5 minutes. However, it stops capturing after this time. > >> > >> There is no error message sent to kmsg ot the application, which > >> apparently waits for more data to be received. > >> > >> The debug dump from usbmon is: > >> > > > > > >> > >> I am using kernel 2.6.34-rc7, and now the E messages are shown. In kernels > >> 2.6.33 and 2.6.32 the bus went on sending callbacks with 0s. > >> I assume that there is still some work in progress on the ehci module, and > >> eventually this issue will be solved. > >> > >> Also, when I stop the application the following message is shown: > >> > >> em28xx #0: cannot change alternate number to 0 (error=-110) > >> > > > > Which processor and which board are you running this on? What is the > > transceiver you are using? (We had issues due to inadequate capacitance > > on some power rails, and poor board design). This could be one source > > of your problem. > > > > Then again, you might be hitting an OMAP errata. > > > > Are you able to use the device after you load the EHCI module again? > > > > I am using gumstix overo air board. > > I am using a hub attached to the overo, and the capturer > attached to the device. > > Once I reload the ehci-hcd module, I have to replug either the usb hub or > the capturer so that it is detected again by ehci. > I mean, when I reload the ehci-hcd module the root hub is detected, but > not the devices attached to it. > What happens if you have the video capture device and another USB device (a flash drive maybe) connected to the external hub? Does the other device also stop working when the video capture device fails? - Anand
RE: USB video capture shuts up
> si...@santesteban.eu wrote: >> Hi I am using a v4l2 usb video capturer (em28xx based), and it is >> working >> fine for around 5 minutes. However, it stops capturing after this time. >> >> There is no error message sent to kmsg ot the application, which >> apparently waits for more data to be received. >> >> The debug dump from usbmon is: >> > > >> >> I am using kernel 2.6.34-rc7, and now the E messages are shown. In >> kernels >> 2.6.33 and 2.6.32 the bus went on sending callbacks with 0s. >> I assume that there is still some work in progress on the ehci module, >> and >> eventually this issue will be solved. >> >> Also, when I stop the application the following message is shown: >> >> em28xx #0: cannot change alternate number to 0 (error=-110) >> > > Which processor and which board are you running this on? What is the > transceiver you are using? (We had issues due to inadequate capacitance > on some power rails, and poor board design). This could be one source > of your problem. > > Then again, you might be hitting an OMAP errata. > > Are you able to use the device after you load the EHCI module again? > > - Anand > I am using gumstix overo air board. I am using a hub attached to the overo, and the capturer attached to the device. Once I reload the ehci-hcd module, I have to replug either the usb hub or the capturer so that it is detected again by ehci. I mean, when I reload the ehci-hcd module the root hub is detected, but not the devices attached to it. Thanks, Simon -- 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: USB video capture shuts up
si...@santesteban.eu wrote: > Hi I am using a v4l2 usb video capturer (em28xx based), and it is working > fine for around 5 minutes. However, it stops capturing after this time. > > There is no error message sent to kmsg ot the application, which > apparently waits for more data to be received. > > The debug dump from usbmon is: > > > I am using kernel 2.6.34-rc7, and now the E messages are shown. In kernels > 2.6.33 and 2.6.32 the bus went on sending callbacks with 0s. > I assume that there is still some work in progress on the ehci module, and > eventually this issue will be solved. > > Also, when I stop the application the following message is shown: > > em28xx #0: cannot change alternate number to 0 (error=-110) > Which processor and which board are you running this on? What is the transceiver you are using? (We had issues due to inadequate capacitance on some power rails, and poor board design). This could be one source of your problem. Then again, you might be hitting an OMAP errata. Are you able to use the device after you load the EHCI module again? - Anand
USB video capture shuts up
Hi I am using a v4l2 usb video capturer (em28xx based), and it is working fine for around 5 minutes. However, it stops capturing after this time. There is no error message sent to kmsg ot the application, which apparently waits for more data to be received. The debug dump from usbmon is: cee45c00 2165674255 C Zi:1:004:2 0:1:2008:0 40 0:0:644 0:1448:644 0:2896:644 0:4344:644 0:5792:604 25224 = 16811781 11883b82 4d8b4e7d 4b8f4e7a 4d8c5077 4f885077 4f885179 cee45c00 2165675109 S Zi:1:004:2 -115:1:2008 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cffdac00 2165679260 C Zi:1:004:2 0:1:0:0 40 0:0:612 0:1448:608 0:2896:608 0:4344:644 0:5792:644 25656 = 39a13c74 3aa33a75 39a23776 3a9f3b78 3a9e3c78 3c9f3e77 449c4374 cffdac00 2165680145 S Zi:1:004:2 -115:1:0 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cff3a800 2165684234 C Zi:1:004:2 0:1:40:0 40 0:0:644 0:1448:644 0:2896:644 0:4344:644 0:5792:644 25420 = 10831081 10892f82 4487437f 3e87437f 468b437d 428f447a 46924379 cff3a800 2165685089 S Zi:1:004:2 -115:1:40 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cee45400 2165773132 C Zi:1:004:2 0:1:80:0 40 0:0:608 0:1448:608 0:2896:608 0:4344:608 0:5792:608 25504 = 43823c7e 39863380 2e853281 34833883 3a843e84 40814380 4280467e cee45400 2165773651 S Zi:1:004:2 -115:1:80 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cee45000 2165773773 C Zi:1:004:2 0:1:120:0 40 -18:0:0 -18:1448:0 -18:2896:0 -18:4344:0 -18:5792:0 0 cee45000 2165773803 S Zi:1:004:2 -115:1:120 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cee45c00 2165773895 C Zi:1:004:2 0:1:160:0 40 -18:0:0 -18:1448:0 -18:2896:0 -18:4344:0 -18:5792:0 0 cee45c00 2165773895 S Zi:1:004:2 -115:1:160 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cffdac00 2165774017 C Zi:1:004:2 0:1:200:0 40 -18:0:0 -18:1448:0 -18:2896:0 -18:4344:0 -18:5792:0 0 cffdac00 2165774017 S Zi:1:004:2 -115:1:200 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cff3a800 2165774108 C Zi:1:004:2 0:1:240:0 40 -18:0:0 -18:1448:0 -18:2896:0 -18:4344:0 -18:5792:0 0 cff3a800 2165774139 S Zi:1:004:2 -115:1:240 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cee45400 2165774230 C Zi:1:004:2 0:1:280:0 40 -18:0:0 -18:1448:0 -18:2896:0 -18:4344:0 -18:5792:0 0 cee45400 2165774230 S Zi:1:004:2 -115:1:280 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cee45000 2165774353 C Zi:1:004:2 0:1:320:0 40 -18:0:0 -18:1448:0 -18:2896:0 -18:4344:0 -18:5792:0 0 cee45000 2165774353 S Zi:1:004:2 -115:1:320 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cee45c00 216577 C Zi:1:004:2 0:1:360:0 40 -18:0:0 -18:1448:0 -18:2896:0 -18:4344:0 -18:5792:0 0 cee45c00 2165774475 S Zi:1:004:2 -115:1:360 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cffdac00 2165774566 C Zi:1:004:2 0:1:400:0 40 -18:0:0 -18:1448:0 -18:2896:0 -18:4344:0 -18:5792:0 0 cffdac00 2165774597 S Zi:1:004:2 -115:1:400 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cff3a800 2165774688 C Zi:1:004:2 0:1:440:0 40 -18:0:0 -18:1448:0 -18:2896:0 -18:4344:0 -18:5792:0 0 cff3a800 2165774688 S Zi:1:004:2 -115:1:440 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cff3a800 2165774719 E Zi:1:004:2 -27 0 cee45400 2165774749 C Zi:1:004:2 0:1:480:0 40 -18:0:0 -18:1448:0 -18:2896:0 -18:4344:0 -18:5792:0 0 cee45400 2165774780 S Zi:1:004:2 -115:1:480 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cee45400 2165774780 E Zi:1:004:2 -27 0 cee45000 2165774810 C Zi:1:004:2 0:1:520:0 40 -18:0:0 -18:1448:0 -18:2896:0 -18:4344:0 -18:5792:0 0 cee45000 2165774871 S Zi:1:004:2 -115:1:520 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cee45000 2165774871 E Zi:1:004:2 -27 0 cee45c00 2165774902 C Zi:1:004:2 0:1:560:0 40 -18:0:0 -18:1448:0 -18:2896:0 -18:4344:0 -18:5792:0 0 cee45c00 2165774932 S Zi:1:004:2 -115:1:560 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cee45c00 2165774932 E Zi:1:004:2 -27 0 cffdac00 2165774993 C Zi:1:004:2 0:1:600:0 40 -18:0:0 -18:1448:0 -18:2896:0 -18:4344:0 -18:5792:0 0 cffdac00 2165774993 S Zi:1:004:2 -115:1:600 40 -18:0:1448 -18:1448:1448 -18:2896:1448 -18:4344:1448 -18:5792:1448 57920 < cffdac00 2165775024 E Zi:1:004:2 -27 0 I am using kernel 2.6.34-rc7, and now the E messages are shown. In kernels 2.6.33 and 2.6.32 the bus went on sending callbacks with 0s. I assume that there is still some work in progress on the ehci module, and eventually this issue will be solved. Also, when I stop the application the following message is shown: em28xx #0: cannot change alternate number to 0 (error=-110) And when I rmmod ehci-hcd: rmmod ehci-hcd ehci-omap
RE: [PATCH v2 0/2] DSS2:Allow FB to build without VRFB
On Fri, 2010-05-14 at 12:03 +0200, ext Guruswamy, Senthilvadivu wrote: > > > -Original Message- > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > Sent: Friday, May 14, 2010 12:54 PM > > To: Guruswamy, Senthilvadivu > > Cc: linux-omap@vger.kernel.org; linux-fb...@vger.kernel.org; > > t...@atomide.com; Hiremath, Vaibhav > > Subject: Re: [PATCH v2 0/2] DSS2:Allow FB to build without VRFB > > The patch set makes VRFB optional. What happens if VRFB is turned off, > > and the user uses VRFB for a framebuffer? > [Senthil] This patch keeps VRFB=y for ARCH_OMAP2 and ARCH_OMAP3. > User would have got an option to turn it OFF if it had appeared in > the menuconfig selections. I did not give that option in menuconfig > explicitly. > ie config OMAP2_VRFB > bool > > Suppose on a build the user deliberately gives "CONFIG_OMAP2_VRFB not set", > then VRFB functions are made as empty functions by the compiler. > > This is fine as long as the user does not say omapfb.vrfb=1. > > But if the user sets omapfb.vrfb=1, then it is a wrong usage of the bootargs > as he has already deliberately changed the defconfig to say "VRFB not set". > > The result of his experiment: No bootup on the board as the vaddr of VRFB > is populated nor of the normal RAM buffer. The kernel should be able to cope with that. While giving wrong boot arguments to the kernel causing it to not boot is bad, it could be somewhat acceptable. But if the user changes the rotation type via sysfs file, and the kernel crashes (which is what I fear will happen), it's totally unacceptable. If it's possible to turn VRFB off, then the code should handle the case where VRFB is not there. Meaning, returning error values or somehow else failing gracefully, and informing the user of wrong arguments. Tomi -- 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/2] DSS2:Allow FB to build without VRFB
On Fri, 2010-05-14 at 13:18 +0200, ext Koen Kooi wrote: > Op 14 mei 2010, om 12:58 heeft Nishanth Menon het volgende geschreven: > > But why use bootargs? > > Because (for some unknown reason) you can't toggle vrfb at runtime. If you > realize you need rotation you need to reboot. I guess it's because the memory > layout for vrfb is completely different, but again, I'm not a kernel hacker :) > You can. There's rotate_type in the framebuffer sysfs directory. But I think you need to release memories etc before that, and reallocate after changing the rotation type. Tomi -- 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: rx51: Move peripheral OMAP gpio setups to rx51_omapgpio_setup function
Idea is to combine peripheral OMAP gpio setups in single function like what
rx51_twlgpio_setup is doing for TWL4030 GPIOs.
Currently this is mostly cleanup for wl1251 gpio setup as not testing the
gpiolib return values and setting the wl1251_pdata statically. The wl1251
driver seems to cope well with uninitialized gpios or with negative irq
number.
Signed-off-by: Jarkko Nikula
Cc: Kalle Valo
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 73 +++--
1 files changed, 21 insertions(+), 52 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 8179d55..27d2767 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -47,7 +47,14 @@ enum {
RX51_SPI_WL1251,
};
-static struct wl12xx_platform_data wl1251_pdata;
+static void rx51_wl1251_set_power(bool enable)
+{
+ gpio_set_value(RX51_WL1251_POWER_GPIO, enable);
+}
+
+static struct wl12xx_platform_data wl1251_pdata = {
+ .set_power = rx51_wl1251_set_power,
+};
static struct omap2_mcspi_device_config wl1251_mcspi_config = {
.turbo_mode = 0,
@@ -454,6 +461,18 @@ static struct regulator_init_data rx51_vio = {
.consumer_supplies = rx51_vio_supplies,
};
+static void __init rx51_omapgpio_setup(void)
+{
+ int irq;
+
+ gpio_request(RX51_WL1251_POWER_GPIO, "wl1251 power");
+ gpio_direction_output(RX51_WL1251_POWER_GPIO, 0);
+ gpio_request(RX51_WL1251_IRQ_GPIO, "wl1251 irq");
+ gpio_direction_input(RX51_WL1251_IRQ_GPIO);
+ irq = gpio_to_irq(RX51_WL1251_IRQ_GPIO);
+ rx51_peripherals_spi_board_info[RX51_SPI_WL1251].irq = irq;
+}
+
static int rx51_twlgpio_setup(struct device *dev, unsigned gpio, unsigned n)
{
/* FIXME this gpio setup is just a placeholder for now */
@@ -783,63 +802,13 @@ static inline void board_smc91x_init(void)
#endif
-static void rx51_wl1251_set_power(bool enable)
-{
- gpio_set_value(RX51_WL1251_POWER_GPIO, enable);
-}
-
-static void __init rx51_init_wl1251(void)
-{
- int irq, ret;
-
- ret = gpio_request(RX51_WL1251_POWER_GPIO, "wl1251 power");
- if (ret < 0)
- goto error;
-
- ret = gpio_direction_output(RX51_WL1251_POWER_GPIO, 0);
- if (ret < 0)
- goto err_power;
-
- ret = gpio_request(RX51_WL1251_IRQ_GPIO, "wl1251 irq");
- if (ret < 0)
- goto err_power;
-
- ret = gpio_direction_input(RX51_WL1251_IRQ_GPIO);
- if (ret < 0)
- goto err_irq;
-
- irq = gpio_to_irq(RX51_WL1251_IRQ_GPIO);
- if (irq < 0)
- goto err_irq;
-
- wl1251_pdata.set_power = rx51_wl1251_set_power;
- rx51_peripherals_spi_board_info[RX51_SPI_WL1251].irq = irq;
-
- return;
-
-err_irq:
- gpio_free(RX51_WL1251_IRQ_GPIO);
-
-err_power:
- gpio_free(RX51_WL1251_POWER_GPIO);
-
-error:
- printk(KERN_ERR "wl1251 board initialisation failed\n");
- wl1251_pdata.set_power = NULL;
-
- /*
-* Now rx51_peripherals_spi_board_info[1].irq is zero and
-* set_power is null, and wl1251_probe() will fail.
-*/
-}
-
void __init rx51_peripherals_init(void)
{
rx51_i2c_init();
board_onenand_init();
board_smc91x_init();
+ rx51_omapgpio_setup();
rx51_add_gpio_keys();
- rx51_init_wl1251();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
omap2_hsmmc_init(mmc);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] DSS2:Allow FB to build without VRFB
Koen Kooi had written, on 05/14/2010 06:18 AM, the following: Op 14 mei 2010, om 12:58 heeft Nishanth Menon het volgende geschreven: Koen Kooi had written, on 05/14/2010 05:39 AM, the following: Op 14 mei 2010, om 12:03 heeft Guruswamy, Senthilvadivu het volgende geschreven: -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Friday, May 14, 2010 12:54 PM To: Guruswamy, Senthilvadivu Cc: linux-omap@vger.kernel.org; linux-fb...@vger.kernel.org; t...@atomide.com; Hiremath, Vaibhav Subject: Re: [PATCH v2 0/2] DSS2:Allow FB to build without VRFB Hi, On Thu, 2010-05-13 at 17:20 +0200, ext Senthilvadivu Guruswamy wrote: From: Senthilvadivu Guruswamy Hi all, This patch series replaces the patch "DSS2 Include VRFB into omap2-3build only" Thanks for the review comments. The intent of this series is to split the patch into 2 logical patches and also to incorporate the comments on multi-omap build. In this series, Kconfig is changed to have OMAP2_VRFB depend on ARCH_OMAP2 and ARCH_OMAP3. This change takes care of the multi-omap builds. This patch would allow successful build of omap_4430sdp_defconfig when OMAP2_DSS and FB_OMAP2 is enabled from menuconfig. For verification: Generated the .config on omap3_defconfig with DSS and FB enabled. Generated .config is same with and without the patch. List of Changed Files: arch/arm/plat-omap/include/plat/vrfb.h drivers/video/omap2/Kconfig drivers/video/omap2/omapfb/Kconfig The patch set makes VRFB optional. What happens if VRFB is turned off, and the user uses VRFB for a framebuffer? [Senthil] This patch keeps VRFB=y for ARCH_OMAP2 and ARCH_OMAP3. User would have got an option to turn it OFF if it had appeared in the menuconfig selections. I did not give that option in menuconfig explicitly. ie config OMAP2_VRFB bool Suppose on a build the user deliberately gives "CONFIG_OMAP2_VRFB not set", then VRFB functions are made as empty functions by the compiler. This is fine as long as the user does not say omapfb.vrfb=1. But if the user sets omapfb.vrfb=1, then it is a wrong usage of the bootargs as he has already deliberately changed the defconfig to say "VRFB not set". The result of his experiment: No bootup on the board as the vaddr of VRFB is populated nor of the normal RAM buffer. And that is unacceptable when working with customers (or users in the open source world). Instead of the kernel hacker spending an hour or 2 on a proper solution we now need to waste a whole lot more time supporting customers who pass vrfb in bootargs without knowing that it's turned off in the kernel. But why use bootargs? Because (for some unknown reason) you can't toggle vrfb at runtime. If you realize > you need rotation you need to reboot. I guess it's because the memory layout for >vrfb is completely different, but again, I'm not a kernel hacker :) Sorry, I am no DSS hacker myself, but looking at mainline 2.6.34-rc6 kernel drivers/video/omap2/omapfb/omapfb-main.c, as part of late_init, omapfb_init gets called -> which causes probe to be called if there is a display around, which calls create_framebuffers and based on the rotation flag DMA or VRFB bootargs call to allocate goes to drivers/video/omap2/vrfb.c, i see request_mem_region and release_mem_region from a physical address mapped - so ok.. we loose some of our memory map.. Since this entire fuss is about being able to select the type of rotation... how about changing vrfb to rotation_type which defaults to best possible for the silicon as indicated by FEATURES as I have been mentioning so far.. just an idea about what I am talking about, here is an illustration patch: diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS index 0af0e9e..b3df400 100644 --- a/Documentation/arm/OMAP/DSS +++ b/Documentation/arm/OMAP/DSS @@ -279,8 +279,11 @@ omapfb.test= - Draw test pattern to framebuffer whenever framebuffer settings change. You need to have OMAPFB debug support enabled in kernel config. -omapfb.vrfb= - - Use VRFB rotation for all framebuffers. +omapfb.rotation_type= 0|1|2 +- Select rotation type on hardware + 0 - Default: Use Optimal rotation style for the silicon + 1 - Force use VRFB rotation for all framebuffers if available + 2 - Use DSS to rotate all framebuffers omapfb.rotate= - Default rotation applied to all framebuffers. diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 7514174..52aebae 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -444,6 +444,7 @@ extern u32 omap3_features; #define OMAP3_HAS_NEON BIT(3) #define OMAP3_HAS_ISP BIT(4) #define OMAP3_HAS_192MHZ_CLK BIT(5) +#define OMAP3_HAS_VRFB BIT(6) #define OMAP3_HAS_FEATURE(feat,flag) \ static inline unsigned int om
Re: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
On Thu, May 13, 2010 at 2:39 PM, Felipe Contreras wrote: > On Thu, May 13, 2010 at 12:09 AM, Guzman Lugo, Fernando > wrote: >>> If you are referring to this patch: >>> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap- >>> 2.6.git;a=commit;h=26ad62f03578a12e942d8bb86d0e52ef1afdee22 >> >> Yes, that's the patch. Could you make sure that the GPT8 interrupt is >> generated before acking MMU fault interrupt? > > I'll try tomorrow when I have access to the hw. I should see "GPTimer interrupt failed" if it doesn't... right? Then yes, the GPT8 interrupt is generated. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap: 3630: disable TLL SAR on 3630 ES1
USBTLL Save-and-Restore is broken in 3630 ES1.0. Having it
enabled could result in incorrect register restores as
the OMAP exits off-mode. This could potentially result in
unexpected wakeup events.
This is fixed in ES1.1. So disable it for ES1.0s.
Signed-off-by: Anand Gadiyar
---
Not using the errata framework for this - but if it does
get implemented, then this is a candidate to add to it.
arch/arm/mach-omap2/powerdomains34xx.h |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/powerdomains34xx.h
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/powerdomains34xx.h
+++ linux-omap-2.6/arch/arm/mach-omap2/powerdomains34xx.h
@@ -80,7 +80,8 @@ static struct powerdomain core_3xxx_pre_
.prcm_offs= CORE_MOD,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1 |
CHIP_IS_OMAP3430ES2 |
- CHIP_IS_OMAP3430ES3_0),
+ CHIP_IS_OMAP3430ES3_0 |
+ CHIP_IS_OMAP3630ES1),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 2,
@@ -97,7 +98,8 @@ static struct powerdomain core_3xxx_pre_
static struct powerdomain core_3xxx_es3_1_pwrdm = {
.name = "core_pwrdm",
.prcm_offs= CORE_MOD,
- .omap_chip= OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES3_1),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES3_1 |
+ CHIP_GE_OMAP3630ES1_1),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.flags= PWRDM_HAS_HDWR_SAR, /* for USBTLL only */
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] omap: 3630: introduce CHIP_GE_3630ES1_1
Introduce CHIP_GE_3630ES1_1 macro to cover 3630ES1.1 and later silicon reviesions. (Currently this is set to 3630 ES1.1 only). This is needed for at least one feature that is broken in 3630ES1.0 but exists on older (3430 ES3.1) and newer revisions. Signed-off-by: Anand Gadiyar --- Okay with me to fold this into the patch [1] that adds 3630 silicon revision support. [1] https://patchwork.kernel.org/patch/95684/ arch/arm/plat-omap/include/plat/cpu.h |1 + 1 file changed, 1 insertion(+) Index: linux-omap-2.6/arch/arm/plat-omap/include/plat/cpu.h === --- linux-omap-2.6.orig/arch/arm/plat-omap/include/plat/cpu.h +++ linux-omap-2.6/arch/arm/plat-omap/include/plat/cpu.h @@ -431,6 +431,7 @@ IS_OMAP_TYPE(3517, 0x3517) CHIP_IS_OMAP3630ES1) #define CHIP_GE_OMAP3430ES3_1 (CHIP_IS_OMAP3430ES3_1 | \ CHIP_IS_OMAP3630ES1) +#define CHIP_GE_OMAP3630ES1_1 (CHIP_IS_OMAP3630ES1_1) int omap_chip_is(struct omap_chip_id oci); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3 v2] musb: add musb support for AM35x
AM35x is based on OMAP35x but has an updated musb interface which uses CPPI4.1 DMA engine. Current patch supports only PIO mode transfers. Signed-off-by: Ajay Kumar Gupta --- Changes from v1: (Based on Sergei's comment) - Moved PHY clock and OTGMODE settings to board files - Added clk_disable/put in exit path - Removed unwanted code related to vbus - Removed unhandled interrupt check - Added timeout in phy_on() I had to use MACH_OMAP3517EVM as there is no ARCH_xxx config specific to AM3517 platforms other than ARCH_OMAP3. drivers/usb/musb/Kconfig |4 +- drivers/usb/musb/Makefile |4 + drivers/usb/musb/am3517.c | 517 + 3 files changed, 523 insertions(+), 2 deletions(-) create mode 100644 drivers/usb/musb/am3517.c diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index ea3a882..5ea3d45 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -10,7 +10,7 @@ comment "Enable Host or Gadget support to see Inventra options" config USB_MUSB_HDRC depends on (USB || USB_GADGET) depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523)) - select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) + select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN || MACH_OMAP3517EVM) select TWL4030_USB if MACH_OMAP_3430SDP select USB_OTG_UTILS tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' @@ -140,7 +140,7 @@ config USB_MUSB_HDRC_HCD config MUSB_PIO_ONLY bool 'Disable DMA (always use PIO)' depends on USB_MUSB_HDRC - default y if USB_TUSB6010 + default USB_TUSB6010 || MACH_OMAP3517EVM help All data is copied between memory and FIFO by the CPU. DMA controllers are ignored. diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile index 3a485da..52a8cf6 100644 --- a/drivers/usb/musb/Makefile +++ b/drivers/usb/musb/Makefile @@ -19,7 +19,11 @@ ifeq ($(CONFIG_ARCH_OMAP2430),y) endif ifeq ($(CONFIG_ARCH_OMAP3430),y) + ifeq ($(CONFIG_MACH_OMAP3517EVM),y) + musb_hdrc-objs += am3517.o + else musb_hdrc-objs += omap2430.o + endif endif ifeq ($(CONFIG_BF54x),y) diff --git a/drivers/usb/musb/am3517.c b/drivers/usb/musb/am3517.c new file mode 100644 index 000..dd9e883 --- /dev/null +++ b/drivers/usb/musb/am3517.c @@ -0,0 +1,517 @@ +/* + * Texas Instruments AM3517 "glue layer" + * + * Copyright (c) 2010, by Texas Instruments + * + * Based on the DA8xx "glue layer" code. + * Copyright (C) 2005-2006 by Texas Instruments + * Copyright (c) 2008, MontaVista Software, Inc. + * + * This file is part of the Inventra Controller Driver for Linux. + * + * The Inventra Controller Driver for Linux is free software; you + * can redistribute it and/or modify it under the terms of the GNU + * General Public License version 2 as published by the Free Software + * Foundation. + * + * The Inventra Controller Driver for Linux is distributed in + * the hope that it will be useful, but WITHOUT ANY WARRANTY; + * without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public + * License for more details. + * + * You should have received a copy of the GNU General Public License + * along with The Inventra Controller Driver for Linux ; if not, + * write to the Free Software Foundation, Inc., 59 Temple Place, + * Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include +#include +#include + +#include +#include + +#include "musb_core.h" + +/* + * AM3517 specific definitions + */ +/* USB 2.0 OTG module registers */ +#define USB_REVISION_REG 0x00 +#define USB_CTRL_REG 0x04 +#define USB_STAT_REG 0x08 +#define USB_EMULATION_REG 0x0c +/* 0x10 Reserved */ +#define USB_AUTOREQ_REG0x14 +#define USB_SRP_FIX_TIME_REG 0x18 +#define USB_TEARDOWN_REG 0x1c +#define EP_INTR_SRC_REG0x20 +#define EP_INTR_SRC_SET_REG0x24 +#define EP_INTR_SRC_CLEAR_REG 0x28 +#define EP_INTR_MASK_REG 0x2c +#define EP_INTR_MASK_SET_REG 0x30 +#define EP_INTR_MASK_CLEAR_REG 0x34 +#define EP_INTR_SRC_MASKED_REG 0x38 +#define CORE_INTR_SRC_REG 0x40 +#define CORE_INTR_SRC_SET_REG 0x44 +#define CORE_INTR_SRC_CLEAR_REG0x48 +#define CORE_INTR_MASK_REG 0x4c +#define CORE_INTR_MASK_SET_REG 0x50 +#define CORE_INTR_MASK_CLEAR_REG 0x54 +#define CORE_INTR_SRC_MASKED_REG 0x58 +/* 0x5c Reserved */ +#define USB_END_OF_INTR_REG0x60 + +/* Control register bits */ +#define USB_SOFT_RESET_MASK1 + +/* USB interrupt register bits */ +#define USB_INTR_USB_SHIFT 16 +#define USB_INTR_USB_MASK (0x1ff << USB_INTR_USB_SHIFT) +#define USB_INTR_DRVVBUS 0x100 +#define USB_INTR_RX_SHIFT 16 +#define USB_INTR_TX_SHIFT 0 +#define AM3517_TX_EP_MASK 0x /* EP0 + 15 Tx EPs */ +#define AM3517_RX_EP_MA
