OMAP usb1 Master clk not generating
Hi, I am working on omap3430,linux 2.6.29 kernel.I am using USB3320 transceiver.I have configured the ehci module. My problem is the USB1 clk is not generating.The mux configuration has done properly. can anyone guide me the steps i have to look. Regards and Thanks Thomas Scariah -- 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 confusion
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Felipe Balbi > Sent: Tuesday, September 01, 2009 9:58 PM > To: ext Gary Thomas > Cc: linux-omap@vger.kernel.org; Paul Walmsley > Subject: Re: USB confusion > > On Tue, Sep 01, 2009 at 02:20:13PM +0200, ext Gary Thomas wrote: > > Following up on this, I made sure that CONFIG_USB_EHCI_HCD was defined. > > > > Now I see these messages: > >ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > >Clock usbhost_48m_fck didn't enable in 10 tries > >ehci-omap: probe of ehci-omap.0 failed with error -22 > > > > Any ideas what else I might be missing? > > check what happens with that clock. Why is that timing out ? > > I believe that message comes from clk fw. Maybe Paul could > give us some hint. Paul ? I faced similar issue and it got solved with increased timeout value. Patch is already submitted for this: [PATCH 5/9] ehci: increase timeout to fix ehci failure http://marc.info/?l=linux-omap&m=124956053919660&w=2 -Ajay > > -- > balbi > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] OMAP3: PM: Adding OSWR support
Sripathy, Vishwanath wrote: OSWR stands for Open Switch With Retention. Not to split hairs, but the OMAP3430 Technical Reference Manual states that OSwR means Open Switch Retention. So no "with". This W always bother me too! Cheers Jon -- 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] OMAP3: PM: Adding OSWR support
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of > Sripathy, Vishwanath > Subject: RE: [PATCH][RFC] OMAP3: PM: Adding OSWR support > > OSWR stands for Open Switch With Retention. > This is one of the target power states where logic is lost for all the > modules in the power domain > except for the ones with Built in retention Flip Flops. This is the main > difference between OFF and So, this's supported for CORE, PER and MPU? -Girish -- 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
ARM: OMAP3: Beagleboard: Fix EHCI initialization
Enable USB power, use correct gpio for usb_ehci_init Signed-off-by: Steve Sakoman --- arch/arm/mach-omap2/board-omap3beagle.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 07aee90..65934ea 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -161,7 +161,7 @@ static int beagle_twl_gpio_setup(struct device *dev, /* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */ gpio_request(gpio + TWL4030_GPIO_MAX, "nEN_USB_PWR"); - gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1); + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); /* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */ gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1; @@ -412,7 +412,8 @@ static void __init omap3_beagle_init(void) gpio_direction_output(170, true); usb_musb_init(); - usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61); + usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, false, true, + -EINVAL, 147); omap3beagle_flash_init(); /* Ensure SDRC pins are mux'd for self-refresh */ -- 1.6.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB confusion
On 09/01/2009 12:14 PM, Steve Sakoman wrote: On Tue, Sep 1, 2009 at 4:42 AM, Gary Thomas wrote: What are the options to have USB Host support on the "normal" USB channels (i.e. not the OTG port)? This used to work on my platform but things stopped when I upgraded to the latest kernel :-( I had the same experience with Overo and posted a patch a couple of weeks ago to get it working (ARM: OMAP3: Overo: Fix EHCI initialization) That fixed it (more precisely, the indirectly referenced patch 'fix phy_reset' fixed my problem) Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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 confusion
On Tue, Sep 1, 2009 at 4:42 AM, Gary Thomas wrote: > What are the options to have USB Host support on the "normal" > USB channels (i.e. not the OTG port)? > > This used to work on my platform but things stopped when I > upgraded to the latest kernel :-( I had the same experience with Overo and posted a patch a couple of weeks ago to get it working (ARM: OMAP3: Overo: Fix EHCI initialization) Beagle EHCI is also broken on top of tree and requires a couple of changes in the board file. I'll try to submit that patch in the next day or so. Steve -- 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 confusion
On Tue, Sep 01, 2009 at 02:20:13PM +0200, ext Gary Thomas wrote: > Following up on this, I made sure that CONFIG_USB_EHCI_HCD was defined. > > Now I see these messages: >ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver >Clock usbhost_48m_fck didn't enable in 10 tries >ehci-omap: probe of ehci-omap.0 failed with error -22 > > Any ideas what else I might be missing? check what happens with that clock. Why is that timing out ? I believe that message comes from clk fw. Maybe Paul could give us some hint. Paul ? -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] OMAP: DSS2: Intro
* Artem Bityutskiy [090901 00:11]: > On 08/31/2009 06:55 PM, Tony Lindgren wrote: >> * Hiremath, Vaibhav [090831 07:44]: >>> -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Syed Mohammed, Khasim Sent: Monday, August 31, 2009 8:11 PM To: Steve Sakoman; Artem Bityutskiy; linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org Mailing List Cc: Andrew Morton; Tony Lindgren; Tomi Valkeinen Subject: RE: [PATCH 00/18] OMAP: DSS2: Intro > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Steve > Sakoman > Sent: Monday, August 31, 2009 7:50 PM > To: Artem Bityutskiy > Cc: Andrew Morton; Tony Lindgren; Tomi Valkeinen; linux- ker...@vger.kernel.org; linux- > o...@vger.kernel.org Mailing List > Subject: Re: [PATCH 00/18] OMAP: DSS2: Intro > > On Mon, Aug 31, 2009 at 2:23 AM, Artem Bityutskiy wrote: > >> We are using DSS2 in Nokia for about a year already. N900 is using this >> code, for example. Other (non-Nokia) projects are using DSS2 as well. >> The code was public for long time and was sent several times for review. >> >> In any case, >> >> Tested-by: Artem Bityutskiy > > Gumstix has also been shipping with DSS2 on their Overo product for > many months now. > > Tested-by: Steve Sakoman If there is a concern on OMAP2 support, I can confirm that there is no difference between OMAP2 and OMAP3 Display Subsystem from Register level. So what ever works on OMAP3 DSS2 should straight away work for OMAP2 as well. I agree with rest of the folks here, we should get DSS2 merged in mainline. It is being extensively used on all OMAP3 platforms. >>> [Hiremath, Vaibhav] I am also agreeing with the point that we should merge >>> the DSS2; it's now almost year we have migrated to DSS2. Most of our >>> customers are based out of it. >> >> Yeh I agree this should get merged. >> >> I think it's best to merge this via the fb list and I've acked the >> patches that I'm concerned with already. > > This would be a good suggestion if the fb list was alive, but it is not. > Do you have a specific name of a maintainer? Bummer, I don't know who should ack this then. > Andrew, > > could you please help with merging this piece of (well written) code? > Could you give your blessing to include it into linux-next now, and > merge this during the next merge window? Alternatively I can also pile it into the omap for-next branch if Andrew prefers that. It would be nice to get some fb people to ack the drivers/video/omap/ parts of the patch series though. 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: [DSPBRIDGE RFC] Combining Reserve and Map into a new IOCTL
On 09/01/2009 04:35 PM, Ameya Palande wrote: Current approach has following problems: 0. It is brain-dead. 1. Caller has to perform 4 system calls in order to map and unmap a buffer. 2. Kernel has no idea about the type of buffer (input/output). So depending on buffer type caller has to explicitly call DSPProcessor_FlushMemory() or DSPProcessor_InvalidateMemory(). Proposed approach: Introduce 2 new IOCTLs which combine (reserve, map) and (unmap, unreserve). Caller should also specify buffer type (input/output) attribute as a parameter to new mapping IOCTL. Benefits of new approach: 1. Saves 2 system calls per map and unmap pair. 2. By implementing lazy unreserve we can introduce cache of reserved mappings, which can skip reserve, unreserve operations. 3. Kernel can take care of flushing/invalidating cache depending on buffer type, which saves system call overhead and removed explicit cache control from user space. These IOCTLs can be added to the current set of API which doesn't break compatibility with old applications. Waiting for comments! Ideas proposed in this document are from: 1. Hiroshi Doyu 2. Felipe Contreras Sounds good for an non-expert. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH]: Adding support for omap-serail driver
govindraj
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
>Govindraj
>Sent: Tuesday, September 01, 2009 2:14 AM
>To: HU TAO-TGHK48
>Cc: vimal singh; linux-omap@vger.kernel.org; LKML;
>linux-ser...@vger.kernel.org; Ye Yuan.Bo-A22116;
>Chen Xiaolong-A21785
>Subject: Re: [RFC][PATCH]: Adding support for omap-serail driver
>
>On Mon, Aug 31, 2009 at 5:20 PM, HU TAO-TGHK48 wrote:
>>
>> 1. Shall we cleanup PM related stuff in arch/arm/mach-omap2/serial.c as
>> well?
>> Originally serail.c register UART IRQ to decide if UART idle for a
>> while and is able to enter low power mode (e.g. retention).
>> To work with original 8250 driver, it is probably the only way since
>> 8250 is not aware of OMAP PM.
>>
>> However it would be more reasonable to merge PM stuff to
>> omap-serial.c. since the new driver is already OMAP specific
>>
>> 2. There is an issue for DMA with current implementation in serial.c
>> When Rx DMA is active NO Rx IRQ will be generated.
>> So serial.c will easily set uart->can_sleep with "1" even there is
>> Rx DMA ongoing
>> + if ((iir & 0x4) && up->use_dma) {
>> + up->ier &= ~UART_IER_RDI;
>> + serial_out(up, UART_IER, up->ier
>>
>> In my view, the best way is to do the idle detection in
>> omap_serial.c.
>
>Yes I understand that we cannot adapt 8250 PM model for omap-serial
>driver in DMA mode I am currently working on that adaption with dma
>mode and will be posting a separate patch for changes on serial.c.
>
>Wouldn't it be cleaner to inherit and adapt the Serial-PM framework
>from serial.c rather than redefining the PM changes in the driver.
>
>As Serial-PM framework already has support for interrupt mode and we
>have to adapt the same for DMA mode.
>
>Also defining PM changes in omap-serial would need changes in PM framework.
>As PM framework calls functions from serail.c file if we are defining
>PM framework in our driver then we may need to redefine the functions
>as in serial.c or modify the PM-framework for uart-activity check.
>I feel adapting the existing serial-PM framework for DMA mode would be
>better rather than
>doing these changes.
You can take reference of how to integrate omap-serial driver PM
with mach-omap2/serial.c as follows, for reference ---
---
>From 69112426bd6009cb11e104b9aafcc65429d662f0 Mon Sep 17 00:00:00 2001
From: Vikram Pandita
Date: Fri, 21 Aug 2009 11:15:58 -0500
Subject: [RFC PATCH] OMAP: Serial: Keep uart in no idle mode when DMA ongoing
Keep UART in NoIdle mode when DMA is going on.
Only once UART transfers are complete, switch to smart idle and
allow OsIdle to kick in
Signed-off-by: Vikram Pandita
---
arch/arm/mach-omap2/serial.c | 12
drivers/serial/omap-serial.c |2 +-
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ff9beb7..a6ee6ab 100755
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -359,9 +359,21 @@ static void omap_uart_allow_sleep(struct omap_uart_state
*uart)
del_timer(&uart->timer);
}
+extern int are_driveromap_uarts_active(int *);
+
static void omap_uart_idle_timer(unsigned long data)
{
struct omap_uart_state *uart = (struct omap_uart_state *)data;
+ int dummy;
+
+ if (are_driveromap_uarts_active(&dummy)){
+ /* Keep UART on NoIdle when DMA channel is enabled in omap
+* serial: do not allow UART to goto Smart-idle till its done
+* dma'ing
+*/
+ omap_uart_block_sleep(uart);
+ return;
+ }
omap_uart_allow_sleep(uart);
}
diff --git a/drivers/serial/omap-serial.c b/drivers/serial/omap-serial.c
index 938f29f..f105e24 100644
--- a/drivers/serial/omap-serial.c
+++ b/drivers/serial/omap-serial.c
@@ -1641,6 +1641,7 @@ int omap24xx_uart_cts_wakeup(int uart_no, int state)
return 0;
}
EXPORT_SYMBOL(omap24xx_uart_cts_wakeup);
+#endif
/**
* are_driver8250_uarts_active() - Check if any ports managed by this
* driver are currently busy. This should be called with interrupts
@@ -1709,7 +1710,6 @@ int are_driveromap_uarts_active(int *driver8250_managed)
}
EXPORT_SYMBOL(are_driveromap_uarts_active);
-#endif
static void serial_omap_display_reg(struct uart_port *port)
{
--
1.6.3.3.334.g916e1
--
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]: Adding support for omap-serail driver
Govindraj
>From: Govindraj R
>
>This patch adds support for OMAP3430-HIGH SPEED UART Controller.
>
>It currently adds support for the following features.
>
>1. Supports Interrupt Mode for all three UARTs on SDP/ZOOM2.
>2. Supports DMA Mode for all three UARTs on SDP/ZOOM2.
>3. Supports Hardware flow control (CTS/RTS) on SDP/ZOOM2.
>4. Supports 3.6Mbps baudrate on SDP/ZOOM2.
>5. Debug Console support on all UARTs on SDP/ZOOM2.
>6. Support for quad uart on ZOOM2 board.
What about UART3 supporting IRDA and CIR modes?
Is that planned to be added?
>
>+
>+static unsigned int check_modem_status(struct uart_omap_port *up)
What is the use case for modem_status?
>+{
>+
>+/*
>+ * This handles the interrupt from one port.
>+ */
>+static inline irqreturn_t serial_omap_irq(int irq, void *dev_id)
>+{
>+ struct uart_omap_port *up = dev_id;
>+ unsigned int iir, lsr;
>+
>+ iir = serial_in(up, UART_IIR);
>+ if (iir & UART_IIR_NO_INT)
>+ return IRQ_NONE;
>+ lsr = serial_in(up, UART_LSR);
>+ if ((iir & 0x4) && up->use_dma) {
>+ up->ier &= ~UART_IER_RDI;
>+ serial_out(up, UART_IER, up->ier);
>+ serial_omap_start_rxdma(up);
>+ } else if (lsr & UART_LSR_DR)
>+ receive_chars(up, &lsr);
>+ check_modem_status(up);
>+ if ((lsr & UART_LSR_THRE) && (iir & 0x2))
>+ transmit_chars(up);
>+ up_activity = jiffies;
>+
>+ return IRQ_HANDLED;
>+}
>+
Query:
>+static void serial_omap_rx_timeout(unsigned long uart_no)
>+{
>+ struct uart_omap_port *up = ui[uart_no - 1];
>+ unsigned int curr_dma_pos;
>+ curr_dma_pos = omap_readl(OMAP34XX_DMA4_BASE +
>+OMAP_DMA4_CDAC(up->uart_dma.rx_dma_channel));
>+ if ((curr_dma_pos == up->uart_dma.prev_rx_dma_pos) ||
>+ (curr_dma_pos == 0)) {
>+ if (jiffies_to_msecs(jiffies - up_activity) < 1) {
>+ mod_timer(&up->uart_dma.rx_timer, jiffies +
>+ usecs_to_jiffies(up->uart_dma.rx_timeout));
Is this a 10 second timeout? Is this acceptable way?
This has to be done in conjunction with the inactivity timer in
mach-omap2/serial.c
>+ } else {
>+ serial_omap_stop_rxdma(up);
>+ up->ier |= UART_IER_RDI;
>+ serial_out(up, UART_IER, up->ier);
>+ }
>+
>+ return;
>+ } else {
>+ unsigned int curr_transmitted_size = curr_dma_pos -
>+ up->uart_dma.prev_rx_dma_pos;
>+ up->port.icount.rx += curr_transmitted_size;
>+ tty_insert_flip_string(up->port.info->port.tty,
>+ up->uart_dma.rx_buf +
>+ (up->uart_dma.prev_rx_dma_pos -
>+ up->uart_dma.rx_buf_dma_phys),
>+ curr_transmitted_size);
>+ tty_flip_buffer_push(up->port.info->port.tty);
>+ up->uart_dma.prev_rx_dma_pos = curr_dma_pos;
>+ if (up->uart_dma.rx_buf_size +
>+ up->uart_dma.rx_buf_dma_phys == curr_dma_pos)
>+ serial_omap_start_rxdma(up);
>+ else
>+ mod_timer(&up->uart_dma.rx_timer, jiffies +
>+ usecs_to_jiffies(up->uart_dma.rx_timeout));
>+ up_activity = jiffies;
>+
>+ }
--
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]: Adding support for omap-serail driver
On Fri, Aug 28, 2009 at 7:35 PM, Alan Cox wrote:
>> +#define UART_BASE(uart_no) (uart_no == UART1) ? OMAP_UART1_BASE :\
>> + (uart_no == UART2) ? OMAP_UART2_BASE :\
>> + OMAP_UART3_BASE
>
> Would be cleaner if this was simply an array (and probably faster)
>
>> +
>> +#define UART_MODULE_BASE(uart_no) (UART1 == uart_no ? \
>> + IO_ADDRESS(OMAP_UART1_BASE) :\
>> + (UART2 == uart_no ? \
>> + IO_ADDRESS(OMAP_UART2_BASE) :\
>> + IO_ADDRESS(OMAP_UART3_BASE)))
>
> Ditto
>
>> +extern unsigned int fcr[MAX_UARTS];
>> +extern char *saved_command_line;
>
> We really don't wang globals floating around with names like fcr - and
> why is saved command line needed when we have module option parsing
> functions ?
>
>
>> +unsigned int fcr[MAX_UARTS];
>> +unsigned long up_activity;
>
> Not acceptable as global names - too big a risk of clashes
>
>
>
>> +static int serial_omap_startup(struct uart_port *port)
>> +{
>> + struct uart_omap_port *up = (struct uart_omap_port *)port;
>> + unsigned long flags;
>> + int irq_flags = 0;
>> + int retval;
>> +
>> + /* Zoom2 has GPIO_102 connected to Serial device:
>> + * Active High
>> + */
>> + if (up->port.flags & UPF_IOREMAP)
>> + irq_flags |= IRQF_TRIGGER_HIGH;
>
> Don't hijack flags here - especially as a patch is pending that adds a
> separate field for IRQ flags to clean that up properly. Build on top of
> that fix instead
Can you provide me the link to that patch.
-
Regards,
Govindraj.R
--
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
[DSPBRIDGE RFC] Combining Reserve and Map into a new IOCTL
Hi, Current DSPBridge MPU side API provides following IOCTLs which are related to reserving and mapping DSP address space: 1. DSPProcessor_ReserveMemory(): Reserve a virtually contiguous region of DSP address space. 2. DSPProcessor_Map(): Maps an MPU buffer to the DSP virtual address space. 3. DSPProcessor_UnMap(): Remove an MPU buffer mapping from the DSP virtual address space. 4. DSPProcessor_UnReserveMemory(): Frees a previously reserved region of the DSP virtual address space. Typical call sequence is: DSPProcessor_ReserveMemory() DSPProcessor_Map() DSPProcessor_UnMap() DSPProcessor_UnReserveMemory() Current approach has following problems: 1. Caller has to perform 4 system calls in order to map and unmap a buffer. 2. Kernel has no idea about the type of buffer (input/output). So depending on buffer type caller has to explicitly call DSPProcessor_FlushMemory() or DSPProcessor_InvalidateMemory(). Proposed approach: Introduce 2 new IOCTLs which combine (reserve, map) and (unmap, unreserve). Caller should also specify buffer type (input/output) attribute as a parameter to new mapping IOCTL. Benefits of new approach: 1. Saves 2 system calls per map and unmap pair. 2. By implementing lazy unreserve we can introduce cache of reserved mappings, which can skip reserve, unreserve operations. 3. Kernel can take care of flushing/invalidating cache depending on buffer type, which saves system call overhead and removed explicit cache control from user space. These IOCTLs can be added to the current set of API which doesn't break compatibility with old applications. Waiting for comments! Ideas proposed in this document are from: 1. Hiroshi Doyu 2. Felipe Contreras Cheers, Ameya. -- 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][RFC] OMAP4: sDMA driver: descriptor autoloading feature
Santosh,
> -Original Message-
> From: Shilimkar, Santosh
> Sent: Monday, August 31, 2009 11:41 PM
> To: S, Venkatraman; linux-omap@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Subject: RE: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor
> autoloading feature
> >
> > 2) Pause / resume of transfers
> >A transfer can be paused after a descriptor set has been
> > loaded, provided the 'pause bit' is set in the linked list element.
> > An ongoing transfer cannot be paused. If the 'pause bit' is set,
> > transfer is not started after loading the register set from memory.
> > Such a transfer can be resumed later.
> Would it be good if we move this description just above those
> APIs. Even though this information is good to be here but
> later once merged, this would go in commit history.
> Somebody reading code also would benefit from this info. I
> leave that decision to you.
Agreed partly. Consistent with rest of the source tree,
I don't like to fit a complete user guide in here.
But I'll repost the patch with some brief API comments.
> > 3) Descriptor types
> >3 possible configurations of descriptors (initialized as linked
> > list elements) are possible. Type 1 provides the maximum flexibility,
> > which contains most register definitions of a DMA logical channel.
> > Fewer options are present in type 2. Type 3 can just modify
> > source/destinations address of transfers. In all transfers, unmodified
> > registers settings are maintained for the next transfer.
>
> This information too should be in source code somewhere.
Ditto
> > +int omap_request_dma_sglist(int dev_id, const char *dev_name,
> > + void (*callback) (int channel_id, u16 ch_status, void *data),
> > + int *listid, int nelem, struct omap_dma_sglist_node **elems) {
> > + struct omap_dma_list_config_params *lcfg;
> > + struct omap_dma_sglist_node *desc;
> > + int dma_lch;
> > + int rc, i;
> > +
> > + if (unlikely((dma_caps0_status &
> DMA_CAPS_SGLIST_SUPPORT) == 0)) {
> > + printk(KERN_ERR "omap DMA: sglist feature not
> supported\n");
> > + return -EPERM;
> > + }
> Don't you need this check in all exported Descriptor API's ?
>
Just adds clutter. The request_* API is the first one to be called,
and the driver above has to respect the error code and not make
further configuration requests.
If not, it is equally likely on OMAP4 and the check would pass, but create
havoc.
Short answer: Can't defend against poor programming.
Perhaps a omap_dma_is_sg_capable() API is needed ? That doesn't scale for
all the drivers & capabilities. Please comment.
> > + if (unlikely(nelem <= 2)) {
> > + printk(KERN_ERR "omap DMA: Need >2 elements in
> the list\n");
> > + return -EINVAL;
> > + }
> > + rc = omap_request_dma(dev_id, dev_name,
> > + callback, NULL, &dma_lch);
> > + if (rc < 0) {
> > + printk(KERN_ERR "omap_dma_list: Request failed
> %d\n", rc);
> > + return rc;
> > + }
> > + *listid = dma_lch;
> > + dma_chan[dma_lch].state = DMA_CH_NOTSTARTED;
> You have updated channel status here but below allocations
> can still fail.
> Safer is to update this once all allocation and variable
> population done.
It doesn't matter. It's the earliest possible state, that seems to apply to
a unconfigured channel as well.
> > extern void omap_set_dma_priority(int lch, int dst_port, int
> > priority); extern int omap_request_dma(int dev_id, const char
> > *dev_name, @@ -656,6 +739,21 @@ extern int
> > omap_modify_dma_chain_params(int chain_id, extern int
> > omap_dma_chain_status(int chain_id); #endif
>
> > +extern int omap_request_dma_sglist(int dev_id, const char *dev_name,
> > + void (*callback) (int channel_id, u16 ch_status, void *data),
> > + int *listid, int nelem, struct omap_dma_sglist_node **elems);
> With this code callback after fewer nodes is not supported right ?
I suppose you mean the interrupt callback.
The controller & the interrupt management are clever enough to call back when
you have set a pause in the middle.
A fine grained control is available if the DMA user provides a TYPE 1
descriptor.
Not usually needed - it beats the purpose of providing a list.
--
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 confusion
On 09/01/2009 05:42 AM, Gary Thomas wrote: What are the options to have USB Host support on the "normal" USB channels (i.e. not the OTG port)? This used to work on my platform but things stopped when I upgraded to the latest kernel :-( n.b. OTG host and gadget still work fine. Thanks Following up on this, I made sure that CONFIG_USB_EHCI_HCD was defined. Now I see these messages: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver Clock usbhost_48m_fck didn't enable in 10 tries ehci-omap: probe of ehci-omap.0 failed with error -22 Any ideas what else I might be missing? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
USB confusion
What are the options to have USB Host support on the "normal" USB channels (i.e. not the OTG port)? This used to work on my platform but things stopped when I upgraded to the latest kernel :-( n.b. OTG host and gadget still work fine. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
dspbridge: draft: get rid of services/list.c
Hello. Here are two patches which change driver's own circular linked list implementation to native one in linux kernel. The initial idea was come from Hiroshi Doyu. P.S. Please, ignore mail with 'Message-ID: <1251793647-14569-1-git-send-email-andy.shevche...@gmail.com>' -- With Best Regards, Andy Shevchenko -- 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] DSPBRIDGE: Get rid of services/list.c (step 1)
From: Andy Shevchenko
* Remove LST_Init() and LST_Exit() calls because they are doing nothing except
tracing, Thus, remove tracing as well.
* Remove DBC_* calls. It's internal kernel business whether to have those
assertions.
* Switch to list_head structure instead of LST_ELEM. Remove redudant code that
uses head->self pointer.
* Use native list methods where it's possible in the list.c.
Signed-off-by: Andy Shevchenko
---
arch/arm/plat-omap/include/dspbridge/list.h | 43 +--
drivers/dsp/bridge/services/list.c | 108 +-
drivers/dsp/bridge/services/mem.c |2 -
drivers/dsp/bridge/services/services.c |9 +--
4 files changed, 10 insertions(+), 152 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/list.h
b/arch/arm/plat-omap/include/dspbridge/list.h
index 2e3f995..f9bbd13 100644
--- a/arch/arm/plat-omap/include/dspbridge/list.h
+++ b/arch/arm/plat-omap/include/dspbridge/list.h
@@ -24,11 +24,9 @@
* Public Functions:
* LST_Create
* LST_Delete
- * LST_Exit
* LST_First
* LST_GetHead
* LST_InitElem
- * LST_Init
* LST_InsertBefore
* LST_IsEmpty
* LST_Next
@@ -51,14 +49,10 @@
#define LIST_
#include
+#include
-#define LST_IsEmpty(l) (((l)->head.next == &(l)->head))
-
- struct LST_ELEM {
- struct LST_ELEM *next;
- struct LST_ELEM *prev;
- struct LST_ELEM *self;
- } ;
+#define LST_ELEMlist_head
+#define LST_IsEmpty(l) list_empty(&(l)->head)
struct LST_LIST {
struct LST_ELEM head;
@@ -111,20 +105,6 @@
extern void LST_Delete(IN struct LST_LIST *pList);
/*
- * LST_Exit
- * Purpose:
- * Discontinue usage of module; free resources when reference count
- * reaches 0.
- * Parameters:
- * Returns:
- * Requires:
- * LST initialized.
- * Ensures:
- * Resources used by module are freed when cRef reaches zero.
- */
- extern void LST_Exit(void);
-
-/*
* LST_First
* Purpose:
* Returns a pointer to the first element of the list, or NULL if the list
@@ -160,7 +140,6 @@
* Pointer to element that was at the head of the list (success)
* NULL No elements in list
* Requires:
- * - head.self must be correctly set to &head.
* - LST initialized.
* - pList != NULL.
* Ensures:
@@ -172,19 +151,6 @@
extern struct LST_ELEM *LST_GetHead(IN struct LST_LIST *pList);
/*
- * LST_Init
- * Purpose:
- * Initializes private state of LST module.
- * Parameters:
- * Returns:
- * TRUE if initialized; FALSE otherwise.
- * Requires:
- * Ensures:
- * LST initialized.
- */
- extern bool LST_Init(void);
-
-/*
* LST_InitElem
* Purpose:
* Initializes a list element to default (cleared) values
@@ -262,15 +228,12 @@
* Void
* Requires:
* *pElem and *pList must both exist.
- * pElem->self = pElem before pElem is passed to this function.
* LST initialized.
* Ensures:
* Notes:
* Because the tail is always "just before" the head of the list (the
* tail's "next" pointer points at the head of the list, and the head's
* "prev" pointer points at the tail of the list), the list is circular.
- * Warning: if pElem->self is not set beforehand, LST_GetHead() will
- * return an erroneous pointer when it is called for this element.
*/
extern void LST_PutTail(IN struct LST_LIST *pList,
IN struct LST_ELEM *pListElem);
diff --git a/drivers/dsp/bridge/services/list.c
b/drivers/dsp/bridge/services/list.c
index 7fa3e76..b215b68 100644
--- a/drivers/dsp/bridge/services/list.c
+++ b/drivers/dsp/bridge/services/list.c
@@ -23,10 +23,8 @@
* Public Functions:
* LST_Create
* LST_Delete
- * LST_Exit
* LST_First
* LST_GetHead
- * LST_Init
* LST_InitElem
* LST_InsertBefore
* LST_Next
@@ -51,21 +49,12 @@
#include
#include
-/* --- Trace & Debug */
-#include
-#include
-
/* --- OS Adaptation Layer */
#include
/* --- This */
#include
-/* --- Globals */
-#if GT_TRACE
-static struct GT_Mask LST_debugMask = { NULL, NULL }; /* GT trace var. */
-#endif
-
/*
* LST_Create
* Purpose:
@@ -75,14 +64,10 @@ struct LST_LIST *LST_Create(void)
{
struct LST_LIST *pList;
- GT_0trace(LST_debugMask, GT_ENTER, "LST_Create: entered\n");
-
pList = (struct LST_LIST *) MEM_Calloc(sizeof(struct LST_LIST),
MEM_NONPAGED);
if (pList != NULL) {
- pList->head.next = &pList->head;
- pList->head.prev = &pList->head;
- pL
[PATCH 2/2] DSPBRIDGE: Get rid of services/list.c (step 2)
From: Andy Shevchenko
* Use native list_empty() method instead of LST_IsEmpty() inside list.c. Remove
extra local variables.
* Move methods from list.c as inline functions in the list.h. Get rid of list.c
at all.
* Use list_head natively instead of LST_ELEM in the list.h.
Signed-off-by: Andy Shevchenko
---
arch/arm/plat-omap/include/dspbridge/list.h | 86 ++---
drivers/dsp/bridge/Kbuild |2 +-
drivers/dsp/bridge/services/list.c | 187 ---
3 files changed, 70 insertions(+), 205 deletions(-)
delete mode 100644 drivers/dsp/bridge/services/list.c
diff --git a/arch/arm/plat-omap/include/dspbridge/list.h
b/arch/arm/plat-omap/include/dspbridge/list.h
index f9bbd13..c9d9e49 100644
--- a/arch/arm/plat-omap/include/dspbridge/list.h
+++ b/arch/arm/plat-omap/include/dspbridge/list.h
@@ -49,14 +49,16 @@
#define LIST_
#include
+/* MEM_Calloc(), MEM_NONPAGED, MEM_Free() */
+#include
#include
#define LST_ELEMlist_head
#define LST_IsEmpty(l) list_empty(&(l)->head)
- struct LST_LIST {
- struct LST_ELEM head;
- } ;
+struct LST_LIST {
+ struct list_head head;
+};
/*
* LST_Create
@@ -80,7 +82,17 @@
* "empty" element, because its "next" and "prev" pointers point at
* the same location (the element itself).
*/
- extern struct LST_LIST *LST_Create(void);
+static inline struct LST_LIST *LST_Create(void)
+{
+ struct LST_LIST *pList;
+
+ pList = (struct LST_LIST *) MEM_Calloc(sizeof(struct LST_LIST),
+ MEM_NONPAGED);
+ if (pList != NULL)
+ INIT_LIST_HEAD(&pList->head);
+
+ return pList;
+}
/*
* LST_Delete
@@ -102,7 +114,10 @@
* chain of list elements. Calling this function on a non-empty list
* will cause a memory leak.
*/
- extern void LST_Delete(IN struct LST_LIST *pList);
+static inline void LST_Delete(struct LST_LIST *pList)
+{
+ MEM_Free(pList);
+}
/*
* LST_First
@@ -118,7 +133,12 @@
* - pList != NULL.
* Ensures:
*/
- extern struct LST_ELEM *LST_First(IN struct LST_LIST *pList);
+static inline struct list_head *LST_First(struct LST_LIST *pList)
+{
+ if (!list_empty(&pList->head))
+ return pList->head.next;
+ return NULL;
+}
/*
* LST_GetHead
@@ -148,7 +168,19 @@
* the head of the list, and the head of the list points backward (its
* "prev" pointer) to the tail of the list, this list is circular.
*/
- extern struct LST_ELEM *LST_GetHead(IN struct LST_LIST *pList);
+static inline struct list_head *LST_GetHead(struct LST_LIST *pList)
+{
+ struct list_head *pElem;
+
+ if (list_empty(&pList->head))
+ return NULL;
+
+ pElem = pList->head.next;
+ pList->head.next = pElem->next;
+ pElem->next->prev = &pList->head;
+
+ return pElem;
+}
/*
* LST_InitElem
@@ -166,7 +198,13 @@
* of a list chain -- that would break the chain.
*
*/
- extern void LST_InitElem(IN struct LST_ELEM *pListElem);
+static inline void LST_InitElem(struct list_head *pElem)
+{
+ if (pElem) {
+ pElem->next = NULL;
+ pElem->prev = NULL;
+ }
+}
/*
* LST_InsertBefore
@@ -184,9 +222,12 @@
* - pElemExisting != NULL.
* Ensures:
*/
- extern void LST_InsertBefore(IN struct LST_LIST *pList,
-IN struct LST_ELEM *pElem,
-IN struct LST_ELEM *pElemExisting);
+static inline void LST_InsertBefore(struct LST_LIST *pList,
+ struct list_head *pElem,
+ struct list_head *pElemExisting)
+{
+ list_add_tail(pElem, pElemExisting);
+}
/*
* LST_Next
@@ -204,8 +245,13 @@
* - pCurElem != NULL.
* Ensures:
*/
- extern struct LST_ELEM *LST_Next(IN struct LST_LIST *pList,
-IN struct LST_ELEM *pCurElem);
+static inline struct list_head *LST_Next(struct LST_LIST *pList,
+struct list_head *pCurElem)
+{
+ if (!list_empty(&pList->head) && (pCurElem->next != &pList->head))
+ return pCurElem->next;
+ return NULL;
+}
/*
* LST_PutTail
@@ -235,8 +281,10 @@
* tail's "next" pointer points at the head of the list, and the head's
* "prev" pointer points at the tail of the list), the list is circular.
*/
- extern void LST_PutTail(IN struct LST_LIST *pList,
- IN struct LST_ELEM *pListElem);
+static inline void LST_PutTail(struct LST_LIST *pList, struct list_head *pElem)
+{
+ list_add_tail(pElem, &pList->head);
+}
/*
* LST_RemoveElem
@@ -253,7 +301,11 @@
*
Re: Question on ISPs CFA interpolation coefficients
2009/8/27 Matthias Schwarz : > Hi all, > > i just wondered how the camera interface's, especially the previewer > module's CFA coefficients are setup on OMAP3530. > > The TRM also does not give too much information about it: >> >> In the generic mode, CFA interpolation is implemented using programmable >> filter coefficients that operate >> on a 5x5 grid: >> · Each coefficient is coded in S8Q6 format. >> · Each output color , G, and B) has its own set of coefficients. >> · There are 4 phases. Each pixel is associated with a phase. >> · Different sets of filter coefficients are provided, depending on the >> tendency (gradient in the data: >> horizontal, vertical, or neutral). >> · So there are 3 color x 4 phase x 3 tendencies x 16 taps = 576 >> coefficients (each coefficient is 8 bits >> wide). >> Note: Coefficients are based on sensor type. However, users can use a >> different methods of >> defining an optimal coefficient set. > > Also drivers/media/video/isp/cfa_coef_table.h does not provide information > on what the inserted values mean and how they are arrenged. > > My question now is: is there anyone on the list who would provide me with > information on how to compose these coefficients correctly? > > Thank you very much, > Matthias > What i guess from no answers is that this part clearly lacks information. I also created a thread in TI's e2e forums: http://e2e.ti.com/forums/t/9565.aspx Best regards, Matthias -- 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
several OMAP newbie questions
Hi all,
I've recently started to work on adding support for a custom OMAP3 board.
Several things in the arch/arm/mach-omap2/board-* caught my attention:
1) omap_xxx_map_io and omap_xxx_init_irq are mostly the same in all board-*
files, the only difference is omap_sdrc_params passed to omap2_init_common_hw.
Probably it'd make sense to have omap_map_io_{242x,243x,343x} as the initializer
of .map_io and move the common part of omap_xxx_map_io to some common place?
2) Boards that use NAND flash have the very same NAND chip select detection
code. Is this code necessary, or, if I know for sure that NAND is connected to
nCS0 I can skip the chip select detection? And, again, if several boards use the
same code for chip select detection, wouldn't it be wise to move it to some
common place?
3) If I'm not much mistaken, board specific pin mux configuration has to deal
with arch/arm/plat-omap/include/mach/mux.h and arch/arm/mach-omap2/mux.c. For
instance, if my board uses ULPI pins that have not been defined already, I need
to patch those file with my pin mux definitions. Am I right here, or have I
missed something?
--
Sincerely yours,
Mike.
--
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][RFC] OMAP4: sDMA driver: descriptor autoloading feature
- Original Message - From: "S, Venkatraman" To: Cc: ; "Shilimkar, Santosh" Sent: Thursday, August 27, 2009 4:41 PM Subject: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading feature (Updated version of previous patch: http://marc.info/?l=linux-omap&m=125012097403050&w=2) Add sDMA driver support for descriptor autoloading feature. Descriptor autoloading is OMAP4 sDMA hardware capability that can be exploited for scatter gather scenarios. The feature works as described below 1) A sDMA channel is programmed to be in 'linked list' mode 2) The client (sDMA user) provides a list of descriptors in a linked list format 3) Each of the 'descriptor' (element in the linked list) contains an updated set of DMA configuration register values 4) Client starts DMA transfer 5) sDMA controller loads the first element to its register configuration memory and executes the transfer 6) After completion, loads the next element (in linked list) to configuration memory and executes the transfer, without MCU intervention. 7) Interrupt is generated after all transfers are completed; this can be configured to be done differently. Configurations and additional features 1) Fast mode & non-fast mode Fast mode/non-fast decides on how the first transfer begins. In non-fast mode, the first element in the linked list is loaded only after completing the transfer according to the configurations already in the sDMA channel registers. In fast mode, the loading of the first element precedes the transfer. 2) Pause / resume of transfers A transfer can be paused after a descriptor set has been loaded, provided the 'pause bit' is set in the linked list element. An ongoing transfer cannot be paused. If the 'pause bit' is set, transfer is not started after loading the register set from memory. Such a transfer can be resumed later. 3) Descriptor types 3 possible configurations of descriptors (initialized as linked list elements) are possible. Type 1 provides the maximum flexibility, which contains most register definitions of a DMA logical channel. Fewer options are present in type 2. Type 3 can just modify source/destinations address of transfers. In all transfers, unmodified registers settings are maintained for the next transfer. Patch provides options / API for 1) Setting up a descriptor loading for DMA channel for sg type transfers 2) configuration with linked list elements 3) Starting / pause and resume of the said transfers, query state 4) Closing/Releasing the DMA channel The patches are generated against kernel 2.6.31-rc1, tested on OMAP4 simulator platform. It might be easier to understand the APIs if you could provide an example. Could you take example of a contiguous/non-contiguous buffer and explain how the desciptor based DMA could be used on this. -- 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] OMAP3: Add support for NAND on ZOOM2/LDP boards
Adding NAND support for ZOOM2 and LDP board. I have tested it for ZOOM2
boards, someone can verify it for LDP, hopefully it should not have any
problem.
The size of the U-Boot environment partition was increased to 1.25MB.
Singned-off-by: Vimal Singh
---
arch/arm/mach-omap2/Makefile|2
arch/arm/mach-omap2/board-ldp-flash.c | 196
arch/arm/mach-omap2/board-ldp.c |2
arch/arm/mach-omap2/board-zoom2.c |2
arch/arm/plat-omap/include/mach/board-ldp.h | 36 +
arch/arm/plat-omap/include/mach/nand.h |1
6 files changed, 239 insertions(+)
Index: linux-omap-2.6/arch/arm/mach-omap2/Makefile
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/Makefile
+++ linux-omap-2.6/arch/arm/mach-omap2/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_MACH_OMAP_APOLLON) += boar
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
+ board-ldp-flash.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
mmc-twl4030.o
@@ -69,6 +70,7 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-
board-rx51-peripherals.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
+ board-ldp-flash.o \
mmc-twl4030.o \
board-zoom-debugboard.o
Index: linux-omap-2.6/arch/arm/mach-omap2/board-ldp-flash.c
===
--- /dev/null
+++ linux-omap-2.6/arch/arm/mach-omap2/board-ldp-flash.c
@@ -0,0 +1,196 @@
+/*
+ * arch/arm/mach-omap2/board-ldp-flash.c
+ *
+ * Copyright (C) 2008-09 Texas Instruments Inc.
+ *
+ * Modified from mach-omap2/board-2430sdp-flash.c
+ * Author(s): Rohit Choraria
+ *Vimal Singh
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define NAND_CMD_UNLOCK1 0x23
+#define NAND_CMD_UNLOCK2 0x24
+/**
+ * @brief platform specific unlock function
+ *
+ * @param mtd - mtd info
+ * @param ofs - offset to start unlock from
+ * @param len - length to unlock
+ *
+ * @return - unlock status
+ */
+static int omap_ldp_nand_unlock(struct mtd_info *mtd, loff_t ofs, size_t len)
+{
+ int ret = 0;
+ int chipnr;
+ int status;
+ unsigned long page;
+ struct nand_chip *this = mtd->priv;
+ printk(KERN_INFO "nand_unlock: start: %08x, length: %d!\n",
+ (int)ofs, (int)len);
+
+ /* select the NAND device */
+ chipnr = (int)(ofs >> this->chip_shift);
+ this->select_chip(mtd, chipnr);
+ /* check the WP bit */
+ this->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
+ if ((this->read_byte(mtd) & 0x80) == 0) {
+ printk(KERN_ERR "nand_unlock: Device is write protected!\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if ((ofs & (mtd->writesize - 1)) != 0) {
+ printk(KERN_ERR "nand_unlock: Start address must be"
+ "beginning of nand page!\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (len == 0 || (len & (mtd->writesize - 1)) != 0) {
+ printk(KERN_ERR "nand_unlock: Length must be a multiple of "
+ "nand page size!\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ /* submit address of first page to unlock */
+ page = (unsigned long)(ofs >> this->page_shift);
+ this->cmdfunc(mtd, NAND_CMD_UNLOCK1, -1, page & this->pagemask);
+
+ /* submit ADDRESS of LAST page to unlock */
+ page += (unsigned long)((ofs + len) >> this->page_shift) ;
+ this->cmdfunc(mtd, NAND_CMD_UNLOCK2, -1, page & this->pagemask);
+
+ /* call wait ready function */
+ status = this->waitfunc(mtd, this);
+ udelay(1000);
+ /* see if device thinks it succeeded */
+ if (status & 0x01) {
+ /* there was an error */
+ printk(KERN_ERR "nand_unlock: error status =0x%08x ", status);
+ ret = -EIO;
+ goto out;
+ }
+
+ out:
+ /* de-select the NAND device */
+ this->select_chip(mtd, -1);
+ return ret;
+}
+
+static struct mtd_partition ldp_nand_partitions
[PATCH 1/2] OMAP2/3: Add support for flash on SDP boards
Add support for flash on SDP boards. NAND, NOR and OneNAND are supported. Only tested on 3430SDP (ES2 and ES3.1), somebody please test on 2430SDP and check the chips select for 2430SDP. Also note that: For OneNAND: in the earlier 2430SDP code the kernel partition was set to only 1MB instead of 2MB on 3430SDP. If people want the old partition sizes back on 2430SDP, please provide a patch. For NAND: 'U-Boot', 'Boot Env' and 'Kernel' partitions sizes increased by few blocks to provide few spare blocks for NAND bab block management in u-boot. If people want old partition sizes, please provide a patch. Signed-off-by: Vimal Singh Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/Makefile |2 arch/arm/mach-omap2/board-2430sdp.c|2 arch/arm/mach-omap2/board-3430sdp.c|2 arch/arm/mach-omap2/board-sdp-flash.c | 326 + arch/arm/mach-omap2/board-sdp.h| 15 + arch/arm/plat-omap/include/mach/gpmc.h |2 6 files changed, 349 insertions(+) Index: linux-omap-2.6/arch/arm/mach-omap2/Makefile === --- linux-omap-2.6.orig/arch/arm/mach-omap2/Makefile +++ linux-omap-2.6/arch/arm/mach-omap2/Makefile @@ -48,6 +48,7 @@ obj-$(CONFIG_OMAP_IOMMU) += $(iommu-y) obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o \ + board-sdp-flash.o \ mmc-twl4030.o obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \ @@ -61,6 +62,7 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-om obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ mmc-twl4030.o obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \ + board-sdp-flash.o \ mmc-twl4030.o obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \ Index: linux-omap-2.6/arch/arm/mach-omap2/board-2430sdp.c === --- linux-omap-2.6.orig/arch/arm/mach-omap2/board-2430sdp.c +++ linux-omap-2.6/arch/arm/mach-omap2/board-2430sdp.c @@ -38,6 +38,7 @@ #include #include +#include "board-sdp.h" #include "mmc-twl4030.h" #define SDP2430_CS0_BASE 0x0400 @@ -210,6 +211,7 @@ static void __init omap_2430sdp_init(voi twl4030_mmc_init(mmc); usb_musb_init(); board_smc91x_init(); + sdp_flash_init(); /* Turn off secondary LCD backlight */ ret = gpio_request(SECONDARY_LCD_GPIO, "Secondary LCD backlight"); Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c === --- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c +++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c @@ -41,6 +41,7 @@ #include #include +#include "board-sdp.h" #include "sdram-qimonda-hyb18m512160af-6.h" #include "mmc-twl4030.h" @@ -494,6 +495,7 @@ static void __init omap_3430sdp_init(voi omap_serial_init(&sdp3430_uart_config); usb_musb_init(); board_smc91x_init(); + sdp_flash_init(); usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61); } Index: linux-omap-2.6/arch/arm/mach-omap2/board-sdp-flash.c === --- /dev/null +++ linux-omap-2.6/arch/arm/mach-omap2/board-sdp-flash.c @@ -0,0 +1,326 @@ +/* + * arch/arm/mach-omap2/board-sdp-flash.c + * + * Copyright (C) 2009 Nokia Corporation + * Copyright (C) 2009 Texas Instruments + * + * Modified from mach-omap2/board-3430sdp-flash.c + * Author: Vimal Singh + * + * 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. + */ + +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#define REG_FPGA_REV 0x10 +#define REG_FPGA_DIP_SWITCH_INPUT2 0x60 +#define MAX_SUPPORTED_GPMC_CONFIG 3 + +/* various memory sizes */ +#define FLASH_SIZE_SDPV1 SZ_64M +#define FLASH_SIZE_SDPV2 SZ_128M + +#define FLASH_BASE_SDPV1 0x0400 /* NOR flash (64 Meg aligned) */ +#define FLASH_BASE_SDPV2 0x1000 /* NOR flash (256 Meg aligned) */ + +#define DEBUG_BASE 0x0800 /* debug board */ + +#define PDC_NOR1 +#define PDC_NAND 2 +#define PDC_ONENAND3 +#define DBG_MPDB 4 + +/* REVISIT: Does for some x, chip_sel_sdp[x] maches for 2430 SDP ? */ + +/* SDP3430 V2 Board CS organization + * Differe
[PATCH 0/2] OMAP: Adding flash support to SDP, ZOOM2 and LDP boards
This patch series adds flash support for NAND (in sdp, zoom2 and ldp), OneNAND and NOR (in sdp). [PATCH 1/2] OMAP2/3: Add support for flash on SDP boards [PATCH 2/2] OMAP3: Add support for NAND on ZOOM2/LDP boards These patches were submitted earlier too.. But putting them in a single list now. --- Thanks and Regards, Vimal Singh -- 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] DSPBRIDGE: Get rid of services/LST_* (step 1)
From: Andy Shevchenko
- Remove LST_Init() and LST_Exit() calls because they are doing nothing except
tracing, Thus, remove tracing as well.
- Remove DBC_* calls. It's internal kernel business whether to have those
assertions.
- Switch to list_head structure instead of LST_ELEM. Remove redudant code that
uses head->self pointer.
- Use native list methods where it's possible in the list.c.
Signed-off-by: Andy Shevchenko
---
arch/arm/plat-omap/include/dspbridge/list.h | 43 +--
drivers/dsp/bridge/services/list.c | 108 +-
drivers/dsp/bridge/services/mem.c |2 -
drivers/dsp/bridge/services/services.c |9 +--
4 files changed, 10 insertions(+), 152 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/list.h
b/arch/arm/plat-omap/include/dspbridge/list.h
index 2e3f995..f9bbd13 100644
--- a/arch/arm/plat-omap/include/dspbridge/list.h
+++ b/arch/arm/plat-omap/include/dspbridge/list.h
@@ -24,11 +24,9 @@
* Public Functions:
* LST_Create
* LST_Delete
- * LST_Exit
* LST_First
* LST_GetHead
* LST_InitElem
- * LST_Init
* LST_InsertBefore
* LST_IsEmpty
* LST_Next
@@ -51,14 +49,10 @@
#define LIST_
#include
+#include
-#define LST_IsEmpty(l) (((l)->head.next == &(l)->head))
-
- struct LST_ELEM {
- struct LST_ELEM *next;
- struct LST_ELEM *prev;
- struct LST_ELEM *self;
- } ;
+#define LST_ELEMlist_head
+#define LST_IsEmpty(l) list_empty(&(l)->head)
struct LST_LIST {
struct LST_ELEM head;
@@ -111,20 +105,6 @@
extern void LST_Delete(IN struct LST_LIST *pList);
/*
- * LST_Exit
- * Purpose:
- * Discontinue usage of module; free resources when reference count
- * reaches 0.
- * Parameters:
- * Returns:
- * Requires:
- * LST initialized.
- * Ensures:
- * Resources used by module are freed when cRef reaches zero.
- */
- extern void LST_Exit(void);
-
-/*
* LST_First
* Purpose:
* Returns a pointer to the first element of the list, or NULL if the list
@@ -160,7 +140,6 @@
* Pointer to element that was at the head of the list (success)
* NULL No elements in list
* Requires:
- * - head.self must be correctly set to &head.
* - LST initialized.
* - pList != NULL.
* Ensures:
@@ -172,19 +151,6 @@
extern struct LST_ELEM *LST_GetHead(IN struct LST_LIST *pList);
/*
- * LST_Init
- * Purpose:
- * Initializes private state of LST module.
- * Parameters:
- * Returns:
- * TRUE if initialized; FALSE otherwise.
- * Requires:
- * Ensures:
- * LST initialized.
- */
- extern bool LST_Init(void);
-
-/*
* LST_InitElem
* Purpose:
* Initializes a list element to default (cleared) values
@@ -262,15 +228,12 @@
* Void
* Requires:
* *pElem and *pList must both exist.
- * pElem->self = pElem before pElem is passed to this function.
* LST initialized.
* Ensures:
* Notes:
* Because the tail is always "just before" the head of the list (the
* tail's "next" pointer points at the head of the list, and the head's
* "prev" pointer points at the tail of the list), the list is circular.
- * Warning: if pElem->self is not set beforehand, LST_GetHead() will
- * return an erroneous pointer when it is called for this element.
*/
extern void LST_PutTail(IN struct LST_LIST *pList,
IN struct LST_ELEM *pListElem);
diff --git a/drivers/dsp/bridge/services/list.c
b/drivers/dsp/bridge/services/list.c
index 7fa3e76..b215b68 100644
--- a/drivers/dsp/bridge/services/list.c
+++ b/drivers/dsp/bridge/services/list.c
@@ -23,10 +23,8 @@
* Public Functions:
* LST_Create
* LST_Delete
- * LST_Exit
* LST_First
* LST_GetHead
- * LST_Init
* LST_InitElem
* LST_InsertBefore
* LST_Next
@@ -51,21 +49,12 @@
#include
#include
-/* --- Trace & Debug */
-#include
-#include
-
/* --- OS Adaptation Layer */
#include
/* --- This */
#include
-/* --- Globals */
-#if GT_TRACE
-static struct GT_Mask LST_debugMask = { NULL, NULL }; /* GT trace var. */
-#endif
-
/*
* LST_Create
* Purpose:
@@ -75,14 +64,10 @@ struct LST_LIST *LST_Create(void)
{
struct LST_LIST *pList;
- GT_0trace(LST_debugMask, GT_ENTER, "LST_Create: entered\n");
-
pList = (struct LST_LIST *) MEM_Calloc(sizeof(struct LST_LIST),
MEM_NONPAGED);
if (pList != NULL) {
- pList->head.next = &pList->head;
- pList->head.prev = &pList->head;
- pL
[PATCH] dspbridge: Check pointer before usage
From: Andy Shevchenko
Check list pointer at every itteration because it could be deleted before we go
into the for loop.
Reworked version of the previous attempts.
Signed-off-by: Andy Shevchenko
---
drivers/dsp/bridge/rmgr/drv.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index d21071c..7e41669 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -1543,8 +1543,9 @@ DSP_STATUS DRV_ReleaseResources(u32 dwContext, struct
DRV_OBJECT *hDrvObject)
* The following will over write the status.
*/
for (pszdevNode = (struct DRV_EXT *)DRV_GetFirstDevExtension();
- pszdevNode != NULL; pszdevNode = (struct DRV_EXT *)
- DRV_GetNextDevExtension((u32)pszdevNode)) {
+ pszdevNode != NULL && pDRVObject->devNodeString != NULL;
+ pszdevNode = (struct DRV_EXT *)
+ DRV_GetNextDevExtension((u32) pszdevNode)) {
if ((u32)pszdevNode == dwContext) {
/* Found it */
/* Delete from the Driver object list */
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dspbridge: Check pointer before usage
From: Andy Shevchenko
Theoretically list could be deleted before we go into the for loop.
Additionally we could delete list immediately if it becomes empty.
Signed-off-by: Andy Shevchenko
---
drivers/dsp/bridge/rmgr/drv.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index d21071c..9f726a6 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -1545,18 +1545,23 @@ DSP_STATUS DRV_ReleaseResources(u32 dwContext, struct
DRV_OBJECT *hDrvObject)
for (pszdevNode = (struct DRV_EXT *)DRV_GetFirstDevExtension();
pszdevNode != NULL; pszdevNode = (struct DRV_EXT *)
DRV_GetNextDevExtension((u32)pszdevNode)) {
+ if (!pDRVObject->devNodeString)
+ /* List already deleted */
+ break;
+
if ((u32)pszdevNode == dwContext) {
/* Found it */
/* Delete from the Driver object list */
LST_RemoveElem(pDRVObject->devNodeString,
- (struct LST_ELEM *)pszdevNode);
+ (struct LST_ELEM *) pszdevNode);
MEM_Free((void *) pszdevNode);
- break;
}
+
/* Delete the List if it is empty */
if (LST_IsEmpty(pDRVObject->devNodeString)) {
LST_Delete(pDRVObject->devNodeString);
pDRVObject->devNodeString = NULL;
+ break;
}
}
return status;
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: Zoom2: provide default MTD partitions
On Tue, Sep 1, 2009 at 12:42 PM, Maxime Petazzoni wrote: > * vimal singh [2009-09-01 12:34:26]: > >> > Yes, I am aware of the mtdparts command line arguments, which works >> > great. I think a "default", sensible partition layout for the Zoom2 >> > would be nice though. >> >> I agree. Keeping it in the mind that mtdparts command line arguments >> will be given higher precedence anyway... > > Exactly. I would recommend that your patch gets merged in. Although I'm > a bit curious of the rationale behind a 30M kernel partition? > > Also, given a 512MB NAND, we could easily affect 256MB or more to the > system partition (as well as a bit more space for the userdata > partition). > > But that's just nitpicking. As we said, mtdparts can be used to take > precedence over the default settings if they don't match the > user/system's needs. I'll re-submit this patch along with one that I mentioned earlier: http://marc.info/?l=linux-omap&m=125065707704826&w=2 in a series of patches. -- Regards, Vimal Singh -- 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] OMAP3: Zoom2: provide default MTD partitions
* vimal singh [2009-09-01 12:34:26]: > > Yes, I am aware of the mtdparts command line arguments, which works > > great. I think a "default", sensible partition layout for the Zoom2 > > would be nice though. > > I agree. Keeping it in the mind that mtdparts command line arguments > will be given higher precedence anyway... Exactly. I would recommend that your patch gets merged in. Although I'm a bit curious of the rationale behind a 30M kernel partition? Also, given a 512MB NAND, we could easily affect 256MB or more to the system partition (as well as a bit more space for the userdata partition). But that's just nitpicking. As we said, mtdparts can be used to take precedence over the default settings if they don't match the user/system's needs. - Maxime -- Maxime Petazzoni Linux kernel & software dev MontaVista Software, Inc signature.asc Description: Digital signature
Re: [PATCH 00/18] OMAP: DSS2: Intro
On 08/31/2009 06:55 PM, Tony Lindgren wrote: * Hiremath, Vaibhav [090831 07:44]: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Syed Mohammed, Khasim Sent: Monday, August 31, 2009 8:11 PM To: Steve Sakoman; Artem Bityutskiy; linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org Mailing List Cc: Andrew Morton; Tony Lindgren; Tomi Valkeinen Subject: RE: [PATCH 00/18] OMAP: DSS2: Intro -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Steve Sakoman Sent: Monday, August 31, 2009 7:50 PM To: Artem Bityutskiy Cc: Andrew Morton; Tony Lindgren; Tomi Valkeinen; linux- ker...@vger.kernel.org; linux- o...@vger.kernel.org Mailing List Subject: Re: [PATCH 00/18] OMAP: DSS2: Intro On Mon, Aug 31, 2009 at 2:23 AM, Artem Bityutskiy wrote: We are using DSS2 in Nokia for about a year already. N900 is using this code, for example. Other (non-Nokia) projects are using DSS2 as well. The code was public for long time and was sent several times for review. In any case, Tested-by: Artem Bityutskiy Gumstix has also been shipping with DSS2 on their Overo product for many months now. Tested-by: Steve Sakoman If there is a concern on OMAP2 support, I can confirm that there is no difference between OMAP2 and OMAP3 Display Subsystem from Register level. So what ever works on OMAP3 DSS2 should straight away work for OMAP2 as well. I agree with rest of the folks here, we should get DSS2 merged in mainline. It is being extensively used on all OMAP3 platforms. [Hiremath, Vaibhav] I am also agreeing with the point that we should merge the DSS2; it's now almost year we have migrated to DSS2. Most of our customers are based out of it. Yeh I agree this should get merged. I think it's best to merge this via the fb list and I've acked the patches that I'm concerned with already. This would be a good suggestion if the fb list was alive, but it is not. Do you have a specific name of a maintainer? Andrew, could you please help with merging this piece of (well written) code? Could you give your blessing to include it into linux-next now, and merge this during the next merge window? -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: Zoom2: provide default MTD partitions
On Thu, Aug 27, 2009 at 7:36 PM, Maxime Petazzoni wrote: > Hi, > > * Pandita, Vikram [2009-08-27 19:16:27]: > >> Why? >> >> I know of an implementation by Vimal Singh that introduces a common >> flash file for Zoom1 and Zoom2. >> There is reuse of code there. > > Thanks for your comments. > > There are indeed other implentations around using a common flash file > for Zoom1 and Zoom2 boards. I didn't know of this specific > implementation by Vimal Singh, but we use something very similar > internally. > > Since linux-omap didn't had any MTD partitions definitions for either > boards, I decided to go for the smallest change: only partitions for > Zoom2. > >> Please discuss and get a converged approach on handling NAND >> partitions on Zoom1 and Zoom2. > > Agreed. We should use a common file for Zoom1 and Zoom2 flash, with > Zoom2 specific partition sizes. But I'm not sure I deserve the right to > propose Vimal Singh's patch (by the way, why hasn't it been merged in > the linux-omap tree?). How should we proceed then? > >> Also the Systerm/User/Cache partition definitions are more from Android >> perspective. >> >> Given that each system may have a different NAND partition requirement, >> have you looked at bootargs passing the MTD partition info: Eg: >> >> mtdparts=omap2-nand.0:5...@0(xloader),\ >> 15...@512k(bootloader),\ >> 2...@2m(kernel),\ >> 1...@32m(system),\ >> 3...@192m(userdata),\ >> 3...@224m(cache) > > Yes, I am aware of the mtdparts command line arguments, which works > great. I think a "default", sensible partition layout for the Zoom2 > would be nice though. I agree. Keeping it in the mind that mtdparts command line arguments will be given higher precedence anyway... -vimal > > - Maxime > > -- > Maxime Petazzoni > Linux kernel & software dev > MontaVista Software, Inc > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkqWktkACgkQ7KsOe4Pmrg28zwCdHvKdX9NDgWVoUOx6Mc8kA6+7 > rx8An1NMQg5aEUHrEgGBZM/1YoFTvQtz > =4L+0 > -END PGP SIGNATURE- > > -- Regards, Vimal Singh -- 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
