davinci gpio driver

[liuyue18301]

hello everybody:
  recently i want to take  GPIO1  as interrupt source in my driver,the work 
flow as follow:
 1 set GPIO1 as input mode
 2 set the trigger mode 
 3 request_irq(gpio_to_irq(GPIO1),void *)hander,SA_INTERRUPT,xx,xx);
 4 do the work in the interrupt process.
 i do not know whether it is validate?
 
 
 
 

 ___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

The DM355 AEW is very sensitive to YELLOW color?

[Han Jun-peng]

Hi,all
I use the APPRO IPNC as my development platform.
The IPNC provides two 2A function:the appro 2A and the TI 2A.
I find if I use the TI 2A, the video is very sensitive to YELLOW color,that
means if I place a piece of yellow paper before the sensor,
the whole video view will become very blue, and if I remove it, the view
will recover to be normal.
How can I solve this problem? Is there any other guys meet this problem?
Thank you very much! Any help or tips will be appreciated!
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: The DM355 AEW is very sensitive to YELLOW color?

[Saxena, Anshuman]

Hi,
Can you please post this query on TI E2E forum 
(http://e2e.ti.com) in Davinci Video Processors section? I 
have anyways forwarded your question to our team and we will reply on the forum 
itself, so that other users can also benefit from this reply at a later point 
of time.

Regards,
Anshuman


From: davinci-linux-open-source-bounces+anshuman=ti@linux.davincidsp.com 
[mailto:davinci-linux-open-source-bounces+anshuman=ti@linux.davincidsp.com] 
On Behalf Of Han Jun-peng
Sent: Thursday, May 13, 2010 1:16 PM
To: Davinci-linux-open-source@linux.davincidsp.com
Subject: The DM355 AEW is very sensitive to YELLOW color?

Hi,all
I use the APPRO IPNC as my development platform.
The IPNC provides two 2A function:the appro 2A and the TI 2A.
I find if I use the TI 2A, the video is very sensitive to YELLOW color,that 
means if I place a piece of yellow paper before the sensor,
the whole video view will become very blue, and if I remove it, the view will 
recover to be normal.
How can I solve this problem? Is there any other guys meet this problem?
Thank you very much! Any help or tips will be appreciated!
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: The DM355 AEW is very sensitive to YELLOW color?

[Saxena, Anshuman]

Please ignore my last email... Just realized that you have already posted it on 
E2E forum :( Sorry for unnecessary emails.

Regards,
Anshuman


From: Saxena, Anshuman
Sent: Thursday, May 13, 2010 1:44 PM
To: 'Han Jun-peng'; Davinci-linux-open-source@linux.davincidsp.com
Subject: RE: The DM355 AEW is very sensitive to YELLOW color?

Hi,
Can you please post this query on TI E2E forum 
(http://e2e.ti.com) in Davinci Video Processors section? I 
have anyways forwarded your question to our team and we will reply on the forum 
itself, so that other users can also benefit from this reply at a later point 
of time.

Regards,
Anshuman


From: davinci-linux-open-source-bounces+anshuman=ti@linux.davincidsp.com 
[mailto:davinci-linux-open-source-bounces+anshuman=ti@linux.davincidsp.com] 
On Behalf Of Han Jun-peng
Sent: Thursday, May 13, 2010 1:16 PM
To: Davinci-linux-open-source@linux.davincidsp.com
Subject: The DM355 AEW is very sensitive to YELLOW color?

Hi,all
I use the APPRO IPNC as my development platform.
The IPNC provides two 2A function:the appro 2A and the TI 2A.
I find if I use the TI 2A, the video is very sensitive to YELLOW color,that 
means if I place a piece of yellow paper before the sensor,
the whole video view will become very blue, and if I remove it, the view will 
recover to be normal.
How can I solve this problem? Is there any other guys meet this problem?
Thank you very much! Any help or tips will be appreciated!
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 06/34] RTC: DaVinci RTC driver

[Russell King - ARM Linux]

This should also go to the RTC people.

On Thu, May 06, 2010 at 04:23:57PM -0700, Kevin Hilman wrote:
> From: Miguel Aguilar 
> 
> This driver features:
> 
> * Alarm support.
> * Periodic interrupt by using a timer include into the RTC module.
> * The update interrupt is not supported by this RTC module.
> 
> This driver was tested on a DM365 EVM by using the rtc-test application
> from the Documentation/rtc.txt.
> 
> Signed-off-by: Miguel Aguilar 
> Signed-off-by: Kevin Hilman 
> Acked-by: Alessandro Zummo 
> ---
>  drivers/rtc/Kconfig   |   10 +
>  drivers/rtc/Makefile  |1 +
>  drivers/rtc/rtc-davinci.c |  673 
> +
>  3 files changed, 684 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/rtc/rtc-davinci.c
> 
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 6a13037..50ac047 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -620,6 +620,16 @@ config RTC_DRV_NUC900
>  
>  comment "on-CPU RTC drivers"
>  
> +config RTC_DRV_DAVINCI
> + tristate "TI DaVinci RTC"
> + depends on ARCH_DAVINCI_DM365
> + help
> +   If you say yes here you get support for the RTC on the
> +   DaVinci platforms (DM365).
> +
> +   This driver can also be built as a module. If so, the module
> +   will be called rtc-davinci.
> +
>  config RTC_DRV_OMAP
>   tristate "TI OMAP1"
>   depends on ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730 || 
> ARCH_DAVINCI_DA8XX
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 44ef194..245311a 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_RTC_DRV_BQ32K) += rtc-bq32k.o
>  obj-$(CONFIG_RTC_DRV_BQ4802) += rtc-bq4802.o
>  obj-$(CONFIG_RTC_DRV_CMOS)   += rtc-cmos.o
>  obj-$(CONFIG_RTC_DRV_COH901331)  += rtc-coh901331.o
> +obj-$(CONFIG_RTC_DRV_DAVINCI)+= rtc-davinci.o
>  obj-$(CONFIG_RTC_DRV_DM355EVM)   += rtc-dm355evm.o
>  obj-$(CONFIG_RTC_DRV_DS1216) += rtc-ds1216.o
>  obj-$(CONFIG_RTC_DRV_DS1286) += rtc-ds1286.o
> diff --git a/drivers/rtc/rtc-davinci.c b/drivers/rtc/rtc-davinci.c
> new file mode 100644
> index 000..92a8f6c
> --- /dev/null
> +++ b/drivers/rtc/rtc-davinci.c
> @@ -0,0 +1,673 @@
> +/*
> + * DaVinci Power Management and Real Time Clock Driver for TI platforms
> + *
> + * Copyright (C) 2009 Texas Instruments, Inc
> + *
> + * Author: Miguel Aguilar 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program 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 this program; 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * The DaVinci RTC is a simple RTC with the following
> + * Sec: 0 - 59 : BCD count
> + * Min: 0 - 59 : BCD count
> + * Hour: 0 - 23 : BCD count
> + * Day: 0 - 0x7FFF(32767) : Binary count ( Over 89 years )
> + */
> +
> +/* PRTC interface registers */
> +#define DAVINCI_PRTCIF_PID   0x00
> +#define PRTCIF_CTLR  0x04
> +#define PRTCIF_LDATA 0x08
> +#define PRTCIF_UDATA 0x0C
> +#define PRTCIF_INTEN 0x10
> +#define PRTCIF_INTFLG0x14
> +
> +/* PRTCIF_CTLR bit fields */
> +#define PRTCIF_CTLR_BUSY BIT(31)
> +#define PRTCIF_CTLR_SIZE BIT(25)
> +#define PRTCIF_CTLR_DIR  BIT(24)
> +#define PRTCIF_CTLR_BENU_MSB BIT(23)
> +#define PRTCIF_CTLR_BENU_3RD_BYTEBIT(22)
> +#define PRTCIF_CTLR_BENU_2ND_BYTEBIT(21)
> +#define PRTCIF_CTLR_BENU_LSB BIT(20)
> +#define PRTCIF_CTLR_BENU_MASK(0x00F0)
> +#define PRTCIF_CTLR_BENL_MSB BIT(19)
> +#define PRTCIF_CTLR_BENL_3RD_BYTEBIT(18)
> +#define PRTCIF_CTLR_BENL_2ND_BYTEBIT(17)
> +#define PRTCIF_CTLR_BENL_LSB BIT(16)
> +#define PRTCIF_CTLR_BENL_MASK(0x000F)
> +
> +/* PRTCIF_INTEN bit fields */
> +#define PRTCIF_INTEN_RTCSS   BIT(1)
> +#define PRTCIF_INTEN_RTCIF   BIT(0)
> +#define PRTCIF_INTEN_MASK(PRTCIF_INTEN_RTCSS \
> + | PRTCIF_INTEN_RTCIF)
> +
> +/* PRTCIF_INTFLG bit fields */
> +#define PRTCIF_INTFLG_RTCSS  BIT(1)
> +#define PRTCIF_INTFLG_RTCIF  BIT(0)
> +#define PRTCIF_INTFLG_MASK   (PRTCIF_INTFLG_RTCSS 

Re: [PATCH 07/34] rtc: omap: let device wakeup capability be configured from chip init logic

[Russell King - ARM Linux]

-> rtc people

On Thu, May 06, 2010 at 04:23:58PM -0700, Kevin Hilman wrote:
> From: Sekhar Nori 
> 
> The rtc-omap driver currently hardcodes the RTC wakeup capability
> to be "not capable". While this seems to be true for existing OMAP1
> boards which are not wired for this, the DA850/OMAP-L138 SoC, the
> RTC can always be wake up source from its "deep sleep" mode.
> 
> This patch lets the wakeup capability to be set from platform data and
> does not override the setting from the driver. For DA850/OMAP-L138, this
> is done from arch/arm/mach-davinci/devices-da8xx.c:da8xx_register_rtc()
> 
> Note that this patch does not change the behavior on any existing OMAP1
> board since the platform device registration sets the wakeup capability
> to 0 by default.
> 
> Signed-off-by: Sekhar Nori 
> Signed-off-by: Kevin Hilman 
> ---
>  drivers/rtc/rtc-omap.c |   12 +++-
>  1 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 64d9727..73377b0 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -34,7 +34,8 @@
>   * Board-specific wiring options include using split power mode with
>   * RTC_OFF_NOFF used as the reset signal (so the RTC won't be reset),
>   * and wiring RTC_WAKE_INT (so the RTC alarm can wake the system from
> - * low power modes).  See the BOARD-SPECIFIC CUSTOMIZATION comment.
> + * low power modes) for OMAP1 boards (OMAP-L138 has this built into
> + * the SoC). See the BOARD-SPECIFIC CUSTOMIZATION comment.
>   */
>  
>  #define OMAP_RTC_BASE0xfffb4800
> @@ -401,16 +402,17 @@ static int __init omap_rtc_probe(struct platform_device 
> *pdev)
>  
>   /* BOARD-SPECIFIC CUSTOMIZATION CAN GO HERE:
>*
> -  *  - Boards wired so that RTC_WAKE_INT does something, and muxed
> -  *right (W13_1610_RTC_WAKE_INT is the default after chip reset),
> -  *should initialize the device wakeup flag appropriately.
> +  *  - Device wake-up capability setting should come through chip
> +  *init logic. OMAP1 boards should initialize the "wakeup capable"
> +  *flag in the platform device if the board is wired right for
> +  *being woken up by RTC alarm. For OMAP-L138, this capability
> +  *is built into the SoC by the "Deep Sleep" capability.
>*
>*  - Boards wired so RTC_ON_nOFF is used as the reset signal,
>*rather than nPWRON_RESET, should forcibly enable split
>*power mode.  (Some chip errata report that RTC_CTRL_SPLIT
>*is write-only, and always reads as zero...)
>*/
> - device_init_wakeup(&pdev->dev, 0);
>  
>   if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT)
>   pr_info("%s: split power mode\n", pdev->name);
> -- 
> 1.7.0.2
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Why failed to open mp3 which stored my live555MediaServer?

[huangsw]

I have succeeded to cross compile live555 (version is 2010-04-09),and i run it 
on my dm6446 ,and i stored a mp3 file on the same dir,

on my pc ,i filed to open the mp3 using  Realplayer and VLC p;ayer,

can you give me some advice?



2010-05-13 



huangsw 
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 06/34] RTC: DaVinci RTC driver

[Kevin Hilman]

Russell King - ARM Linux  writes:

> This should also go to the RTC people.

Forgot the Cc here, but this has already been discussed ack'd by RTC folks
and agreed that it should merge via my tree.

Kevin

> On Thu, May 06, 2010 at 04:23:57PM -0700, Kevin Hilman wrote:
>> From: Miguel Aguilar 
>> 
>> This driver features:
>> 
>> * Alarm support.
>> * Periodic interrupt by using a timer include into the RTC module.
>> * The update interrupt is not supported by this RTC module.
>> 
>> This driver was tested on a DM365 EVM by using the rtc-test application
>> from the Documentation/rtc.txt.
>> 
>> Signed-off-by: Miguel Aguilar 
>> Signed-off-by: Kevin Hilman 
>> Acked-by: Alessandro Zummo 
>> ---
>>  drivers/rtc/Kconfig   |   10 +
>>  drivers/rtc/Makefile  |1 +
>>  drivers/rtc/rtc-davinci.c |  673 
>> +
>>  3 files changed, 684 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/rtc/rtc-davinci.c
>> 
>> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
>> index 6a13037..50ac047 100644
>> --- a/drivers/rtc/Kconfig
>> +++ b/drivers/rtc/Kconfig
>> @@ -620,6 +620,16 @@ config RTC_DRV_NUC900
>>  
>>  comment "on-CPU RTC drivers"
>>  
>> +config RTC_DRV_DAVINCI
>> +tristate "TI DaVinci RTC"
>> +depends on ARCH_DAVINCI_DM365
>> +help
>> +  If you say yes here you get support for the RTC on the
>> +  DaVinci platforms (DM365).
>> +
>> +  This driver can also be built as a module. If so, the module
>> +  will be called rtc-davinci.
>> +
>>  config RTC_DRV_OMAP
>>  tristate "TI OMAP1"
>>  depends on ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730 || 
>> ARCH_DAVINCI_DA8XX
>> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
>> index 44ef194..245311a 100644
>> --- a/drivers/rtc/Makefile
>> +++ b/drivers/rtc/Makefile
>> @@ -27,6 +27,7 @@ obj-$(CONFIG_RTC_DRV_BQ32K)+= rtc-bq32k.o
>>  obj-$(CONFIG_RTC_DRV_BQ4802)+= rtc-bq4802.o
>>  obj-$(CONFIG_RTC_DRV_CMOS)  += rtc-cmos.o
>>  obj-$(CONFIG_RTC_DRV_COH901331) += rtc-coh901331.o
>> +obj-$(CONFIG_RTC_DRV_DAVINCI)   += rtc-davinci.o
>>  obj-$(CONFIG_RTC_DRV_DM355EVM)  += rtc-dm355evm.o
>>  obj-$(CONFIG_RTC_DRV_DS1216)+= rtc-ds1216.o
>>  obj-$(CONFIG_RTC_DRV_DS1286)+= rtc-ds1286.o
>> diff --git a/drivers/rtc/rtc-davinci.c b/drivers/rtc/rtc-davinci.c
>> new file mode 100644
>> index 000..92a8f6c
>> --- /dev/null
>> +++ b/drivers/rtc/rtc-davinci.c
>> @@ -0,0 +1,673 @@
>> +/*
>> + * DaVinci Power Management and Real Time Clock Driver for TI platforms
>> + *
>> + * Copyright (C) 2009 Texas Instruments, Inc
>> + *
>> + * Author: Miguel Aguilar 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program 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 this program; 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 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/*
>> + * The DaVinci RTC is a simple RTC with the following
>> + * Sec: 0 - 59 : BCD count
>> + * Min: 0 - 59 : BCD count
>> + * Hour: 0 - 23 : BCD count
>> + * Day: 0 - 0x7FFF(32767) : Binary count ( Over 89 years )
>> + */
>> +
>> +/* PRTC interface registers */
>> +#define DAVINCI_PRTCIF_PID  0x00
>> +#define PRTCIF_CTLR 0x04
>> +#define PRTCIF_LDATA0x08
>> +#define PRTCIF_UDATA0x0C
>> +#define PRTCIF_INTEN0x10
>> +#define PRTCIF_INTFLG   0x14
>> +
>> +/* PRTCIF_CTLR bit fields */
>> +#define PRTCIF_CTLR_BUSYBIT(31)
>> +#define PRTCIF_CTLR_SIZEBIT(25)
>> +#define PRTCIF_CTLR_DIR BIT(24)
>> +#define PRTCIF_CTLR_BENU_MSBBIT(23)
>> +#define PRTCIF_CTLR_BENU_3RD_BYTE   BIT(22)
>> +#define PRTCIF_CTLR_BENU_2ND_BYTE   BIT(21)
>> +#define PRTCIF_CTLR_BENU_LSBBIT(20)
>> +#define PRTCIF_CTLR_BENU_MASK   (0x00F0)
>> +#define PRTCIF_CTLR_BENL_MSBBIT(19)
>> +#define PRTCIF_CTLR_BENL_3RD_BYTE   BIT(18)
>> +#define PRTCIF_CTLR_BENL_2ND_BYTE   BIT(17)
>> +#define PRTCIF_CTLR_BENL_LSBBIT(16)
>> +#define PRTCIF_CTLR_BENL_MASK   (0x000F)
>> +
>> +/* PRTCIF_INTEN bit fields */
>> +#define PRTCIF_INTEN_RTCSS  BIT(1)
>> +#define PRTCIF_

Re: [PATCH v3 0/8] pre-tnetv107x ioremap series

[Kevin Hilman]

Cyril Chemparathy  writes:

> With this patch, various davinci modules (gpio, timer, psc, etc.) now use
> ioremap() instead of having virtual addresses passed in via davinci_soc_info.
> Based on this cleanup, davinci_ioremap() has been modified to search through
> the iotable instead of mapping based on IO_PHYS and IO_VIRT.

Looks good.  Applying.  Adding to davinci-next for 2.6.35.

Thanks again for this major cleanup and improvement!

Kevin


> Cyril Chemparathy (8):
>   Davinci: gpio - use ioremap()
>   Davinci: da8xx: rtc - use ioremap
>   Davinci: jtag_id - use ioremap()
>   Davinci: timer - use ioremap()
>   Davinci: psc - use ioremap()
>   Davinci: aintc/cpintc - use ioremap()
>   Davinci: pinmux - use ioremap()
>   Davinci: iotable based ioremap() interception
>
>  arch/arm/mach-davinci/board-da830-evm.c  |   10 +
>  arch/arm/mach-davinci/board-da850-evm.c  |   10 +
>  arch/arm/mach-davinci/board-dm355-evm.c  |7 +---
>  arch/arm/mach-davinci/board-dm355-leopard.c  |7 +---
>  arch/arm/mach-davinci/board-dm365-evm.c  |7 +---
>  arch/arm/mach-davinci/board-dm644x-evm.c |7 +---
>  arch/arm/mach-davinci/board-dm646x-evm.c |9 +---
>  arch/arm/mach-davinci/board-neuros-osd2.c|7 +---
>  arch/arm/mach-davinci/board-sffsdr.c |7 +---
>  arch/arm/mach-davinci/clock.c|   14 +-
>  arch/arm/mach-davinci/common.c   |   54 ++---
>  arch/arm/mach-davinci/cp_intc.c  |   18 +---
>  arch/arm/mach-davinci/da830.c|   26 +
>  arch/arm/mach-davinci/da850.c|   27 +
>  arch/arm/mach-davinci/devices-da8xx.c|   11 -
>  arch/arm/mach-davinci/devices.c  |4 +-
>  arch/arm/mach-davinci/dm355.c|   12 ++---
>  arch/arm/mach-davinci/dm365.c|   12 ++---
>  arch/arm/mach-davinci/dm644x.c   |   12 ++---
>  arch/arm/mach-davinci/dm646x.c   |   12 ++---
>  arch/arm/mach-davinci/gpio.c |   18 +---
>  arch/arm/mach-davinci/include/mach/common.h  |   21 +++---
>  arch/arm/mach-davinci/include/mach/cp_intc.h |3 +-
>  arch/arm/mach-davinci/io.c   |   20 +++--
>  arch/arm/mach-davinci/irq.c  |7 +++-
>  arch/arm/mach-davinci/mux.c  |   17 ++--
>  arch/arm/mach-davinci/psc.c  |7 ++-
>  arch/arm/mach-davinci/time.c |   22 +++
>  28 files changed, 192 insertions(+), 196 deletions(-)
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v6 1/6] Davinci: generalized debug macros

[Kevin Hilman]

Cyril Chemparathy  writes:

> This patch adopts a debug uart selection similar to the OMAP model.  During
> the boot process, the uncompress code determines the physical and virtual base
> addresses of the board-specific debug uart.  These addresses are then passed
> on to the in-kernel debug macros through a small chunk of memory placed just
> below the page tables (@0x80003ff8).
>
> Signed-off-by: Cyril Chemparathy 

Tony's updated version[1] for OMAP is not using 0x3ffc offset since only
4 bytes are used.

Any objection to making and testing that change?

Kevin

[1] 
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=96554d70775e936e870f61d9523c9bab3fd54ad6

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: live555

[Jimmy Blair]

Date: Thu, 13 May 2010 20:13:51 +0800
From: "huangsw" 

I have succeeded to cross compile live555 (version is 2010-04-09),and i run it 
on my dm6446 ,and i stored a mp3 file on the same dir,

on my pc ,i filed to open the mp3 using  Realplayer and VLC p;ayer,

can you give me some advice?




I couldn't get Live555 to stream, either.  Try
an RTSP server called 'feng'.  Just google "libnemesi" and you'll
get to the Lscube website.  There are a few libraries to download
and build.  I use feng to stream from a Linux PC.  Try it that
way first before you cross compile for Davinci.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v2 1/2] davinci: edma: use BIT() wherever possible

[Kevin Hilman]

Sekhar Nori  writes:

> This patch replaces occurences of (1 << x) with
> BIT(x) as it makes for much better reading.
>
> Signed-off-by: Sekhar Nori 

Looks good, applying both patches and queuing for 2.6.35 in davinci-next.

Kevin
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v6 1/6] Davinci: generalized debug macros

[Kevin Hilman]

Kevin Hilman  writes:

> Cyril Chemparathy  writes:
>
>> This patch adopts a debug uart selection similar to the OMAP model.  During
>> the boot process, the uncompress code determines the physical and virtual 
>> base
>> addresses of the board-specific debug uart.  These addresses are then passed
>> on to the in-kernel debug macros through a small chunk of memory placed just
>> below the page tables (@0x80003ff8).
>>
>> Signed-off-by: Cyril Chemparathy 
>
> Tony's updated version[1] for OMAP is not using 0x3ffc offset since only
> 4 bytes are used.
>
> Any objection to making and testing that change?

fwiw, I boot tested using 0x3ffc on DMx (dm6446, dm355, dm6467 EVMs)
as well DA8xx (da830 and da850 EVMs) and it works fine for all.

> Kevin
>
> [1] 
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=96554d70775e936e870f61d9523c9bab3fd54ad6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v6 3/6] Davinci: tnetv107x soc support

[Kevin Hilman]

Cyril Chemparathy  writes:

> TNETV107X is a Texas Instruments SOC that shares a number of common features
> with the Davinci architecture.  Some of the key differences between
> traditional Davincis and this new SOC are as follow:
>
> 1. The SOCs clock architecture includes a new spread-spectrum PLL.  Some
> elements of the clock architecture are reused from Davinci (e.g. LPSC), but
> the PLL related code is overridden using existing interfaces in "struct clk".
>
> 2. The MMR layout on this SOC is substantially different from Davinci.
> Consequently, the fixed I/O map is a whole lot more convoluted (more so than
> DA8xx).  The net impact here is that IO_ADDRESS() will not work on this SoC,
> and therefore all mappings have to be through ioremap().
>
> Signed-off-by: Cyril Chemparathy 

[...]

> diff --git a/arch/arm/mach-davinci/include/mach/tnetv107x.h 
> b/arch/arm/mach-davinci/include/mach/tnetv107x.h
> new file mode 100644
> index 000..cc44678
> --- /dev/null
> +++ b/arch/arm/mach-davinci/include/mach/tnetv107x.h
> @@ -0,0 +1,56 @@
> +/*
> + * Texas Instruments TNETV107X SoC Specific Defines
> + *
> + * Copyright (C) 2010 Texas Instruments
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#ifndef __ASM_ARCH_DAVINCI_TNETV107X_H
> +#define __ASM_ARCH_DAVINCI_TNETV107X_H
> +
> +#include 
> +
> +#define TNETV107X_DDR_BASE   0x8000
> +
> +/*
> + * Fixed mapping for early init starts here. If low-level debug is enabled,
> + * this area also gets mapped via io_pg_offset and io_phys by the boot code.
> + * To fit in with the io_pg_offset calculation, the io base address selected
> + * here _must_ be a multiple of 2^20.
> + */
> +#define TNETV107X_IO_BASE0x0800
> +#define TNETV107X_IO_VIRT(IO_VIRT + SZ_1M)
> +
> +#define PINMUX(x)(4 * (x))

minor nit...

Isn't this a duplicate of what is now in  ?

Kevin
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v6 4/6] Davinci: tnetv107x initial gpio support

[Kevin Hilman]

Cyril Chemparathy  writes:

> This patch adds support for the tnetv107x gpio controller.
>
> Key differences between davinci and tnetv107x controllers:
>  - register map - davinci's controller is organized into banks of 32 gpios,
>tnetv107x has a single space with arrays of registers for in, out,
>direction, etc.
>  - davinci's controller has separate set/clear registers for output, tnetv107x
>has a single direct mapped register.
>
> This patch does not yet add gpio irq support on this controller.
>
> Signed-off-by: Cyril Chemparathy 

I know Sergei isn't used to me agreeing with him ;) but I tend to
agree with him on the increased bulk of gpio_set_value().

It's not simply the increased size that is an issue here.  The point
of these inlines (as the comment suggests) is for low-overhead
bit-banging.  With the introduction of different methods depending on
GPIO type, as well as the locking for the tnetv style, this is no
longer low-overhead in my mind.

Below is an alternate solution.

[...]

> @@ -97,14 +98,30 @@ static inline void gpio_set_value(unsigned gpio, int 
> value)
>  {
>   if (__builtin_constant_p(value) && gpio < davinci_soc_info.gpio_num) {

Here add '&& (ctlr->set_data != ctlr->clr_data)' to the if clause

>   struct davinci_gpio_controller *ctlr;
> - u32 mask;
> + u32 mask, data;
> + unsigned long   flags;
>  
>   ctlr = __gpio_to_controller(gpio);
>   mask = __gpio_mask(gpio);
> - if (value)
> - __raw_writel(mask, ctlr->set_data);
> - else
> - __raw_writel(mask, ctlr->clr_data);

and then this part can stay as is for the traditional style...

> +
> + if (ctlr->set_data != ctlr->clr_data) {
> + /* traditional set/clear registers */
> + if (value)
> + __raw_writel(mask, ctlr->set_data);
> + else
> + __raw_writel(mask, ctlr->clr_data);
> + } else {
> + /* tnetv107x style single out register */
> + spin_lock_irqsave(&ctlr->lock, flags);
> + data = __raw_readl(ctlr->set_data);
> + if (value)
> + data |= mask;
> + else
> + data &= ~mask;
> + __raw_writel(data, ctlr->set_data);
> + spin_unlock_irqrestore(&ctlr->lock, flags);
> + }
> +
>   return;
>   }

Then just drop all of this part and let the tnetv-style fall through
to the __gpio_set_value() which will call the GPIO chip's ->set()
method.

Kevin
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v6 0/6] Davinci: initial tnetv107x patch series

[Kevin Hilman]

Cyril Chemparathy  writes:

> This patch series adds support for TNETV107X - a Texas Instruments SOC that
> shares a number of common features with the Davinci architecture.
>
> This version includes minor fixes over the v5 series posted earlier

Hi Cyril,

I had some minor comments on a couple of the patches here, but have
one other question.

Is there anything in the DaVinci-specific parts now that is preventing
a single kernel shared between DMx an tnetv?

I know about the ARM-generic code that has problems when both ARMv5
and ARMv6 are enabled, but am curious about any remaining blocks in
the arch/arm/mach-davinci/* code.

Thanks,

Kevin
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 0/3] More PINMUX definitions

[Kevin Hilman]

thomas.koel...@baslerweb.com writes:

> From: Thomas Koeller 
>
> Patch series is against Kevin's tree this time. They
> introduce new PINMUX settings that are required to support
> the board I am working on.
>
> Thomas Koeller (3):
>   DM365: Added PINMUX definitions for GPIO30..32
>   DM365: Make CLKOUTx available
>   DM365: Added more PINMUX configurations for AEMIF
>
>  arch/arm/mach-davinci/dm365.c|   12 +++-
>  arch/arm/mach-davinci/include/mach/mux.h |   13 -
>  2 files changed, 23 insertions(+), 2 deletions(-)

Looks good, applying and queuing for 2.6.35 in davinci-next.

In the future, please report which platforms this was tested on.
Because these are simple enough changes and they passed a visual
sanity check, I'll just apply them this time.

Kevin



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH RFC v8] MUSB: DA8xx/OMAP-L1x glue layer

[Sergei Shtylyov]

Sergei Shtylyov wrote:

Texas Instruments DA8xx/OMAP-L1x glue layer for the MUSBMHRDC driver.

Signed-off-by: Sergei Shtylyov 
Signed-off-by: Yadviga Grigorieva 

---
The patch is against the recent Linus' tree.


  Felipe, I forgot to both CC you and drop RFC from the subject. Please 
queue/ack this.


WBR, Sergei


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH] DA830: fix USB 2.0 clock entry

[Sergei Shtylyov]

DA8xx OHCI driver fails to load due to failing clk_get() call for the USB 2.0
clock. Arrange matching USB 2.0 clock by the clock name instead of the device.
(Adding another CLK() entry for "ohci.0" device won't do -- in the future I'll
also have to enable USB 2.0 clock to configure CPPI 4.1 module, in which case
I won't have any device at all.)

Signed-off-by: Sergei Shtylyov 

---
The patch is against the recent DaVinci tree.

 arch/arm/mach-davinci/da830.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-davinci/arch/arm/mach-davinci/da830.c
===
--- linux-davinci.orig/arch/arm/mach-davinci/da830.c
+++ linux-davinci/arch/arm/mach-davinci/da830.c
@@ -411,7 +411,7 @@ static struct clk_lookup da830_clks[] = 
CLK("davinci-mcasp.0",  NULL,   &mcasp0_clk),
CLK("davinci-mcasp.1",  NULL,   &mcasp1_clk),
CLK("davinci-mcasp.2",  NULL,   &mcasp2_clk),
-   CLK("musb_hdrc",NULL,   &usb20_clk),
+   CLK(NULL,   "usb20",&usb20_clk),
CLK(NULL,   "aemif",&aemif_clk),
CLK(NULL,   "aintc",&aintc_clk),
CLK(NULL,   "secu_mgr", &secu_mgr_clk),
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH] DA830: fix USB 2.0 clock entry

[Sergei Shtylyov]

Hello.

I wrote:

DA8xx OHCI driver fails to load due to failing clk_get() call for the USB 2.0
clock. Arrange matching USB 2.0 clock by the clock name instead of the device.
(Adding another CLK() entry for "ohci.0" device won't do -- in the future I'll
also have to enable USB 2.0 clock to configure CPPI 4.1 module, in which case
I won't have any device at all.)
  


  This was actually a part of CPPI 4.1 platform init. patch, but I've 
just realized it's necessary for OHCI too. Didn't notice it before. :-/



Signed-off-by: Sergei Shtylyov 

---
The patch is against the recent DaVinci tree.
  


  Kevin, could we squeeze it into 2.6.34?


 arch/arm/mach-davinci/da830.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-davinci/arch/arm/mach-davinci/da830.c
===
--- linux-davinci.orig/arch/arm/mach-davinci/da830.c
+++ linux-davinci/arch/arm/mach-davinci/da830.c
@@ -411,7 +411,7 @@ static struct clk_lookup da830_clks[] = 
 	CLK("davinci-mcasp.0",	NULL,		&mcasp0_clk),

CLK("davinci-mcasp.1",NULL,   &mcasp1_clk),
CLK("davinci-mcasp.2",NULL,   &mcasp2_clk),
-   CLK("musb_hdrc",  NULL,   &usb20_clk),
+   CLK(NULL,   "usb20",  &usb20_clk),
CLK(NULL,   "aemif",  &aemif_clk),
CLK(NULL,   "aintc",  &aintc_clk),
CLK(NULL,   "secu_mgr",   &secu_mgr_clk),


WBR, Sergei

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH 4/20] arch/arm/mach-davinci: Use kzalloc

[Julia Lawall]

From: Julia Lawall 

Use kzalloc rather than the combination of kmalloc and memset.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
expression x,size,flags;
statement S;
@@

-x = kmalloc(size,flags);
+x = kzalloc(size,flags);
 if (x == NULL) S
-memset(x, 0, size);
// 

Signed-off-by: Julia Lawall 

---
 arch/arm/mach-davinci/dma.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff -u -p a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -1419,12 +1419,11 @@ static int __init edma_probe(struct plat
goto fail1;
}
 
-   edma_cc[j] = kmalloc(sizeof(struct edma), GFP_KERNEL);
+   edma_cc[j] = kzalloc(sizeof(struct edma), GFP_KERNEL);
if (!edma_cc[j]) {
status = -ENOMEM;
goto fail1;
}
-   memset(edma_cc[j], 0, sizeof(struct edma));
 
edma_cc[j]->num_channels = min_t(unsigned, info[j].n_channel,
EDMA_MAX_DMACH);
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

question about using DMA for davinci SPI controller

[Bi Junxiao]

Hi all,

I am trying to fix a bug about full duplex DMA transfer for SPI
controller hang on ti-omapl138 ref borad.
I read the DMA setting code of davinci SPI controller. It's in
drivers/spi/davinci_spi.c:davinci_spi_bufs_dma().
There is a code snippet which I don't understand. List below:


if (t->tx_buf) {
t->tx_dma = dma_map_single(&spi->dev, (void *)t->tx_buf, count,
DMA_TO_DEVICE);
if (dma_mapping_error(&spi->dev, t->tx_dma)) {
dev_dbg(sdev, "Unable to DMA map a %d bytes"
" TX buffer\n", count);
return -ENOMEM;
}
temp_count = count;
} else {
/* We need TX clocking for RX transaction */
t->tx_dma = dma_map_single(&spi->dev,
(void *)davinci_spi->tmp_buf, count + 1,
DMA_TO_DEVICE);
if (dma_mapping_error(&spi->dev, t->tx_dma)) {
dev_dbg(sdev, "Unable to DMA map a %d bytes"
" TX tmp buffer\n", count);
return -ENOMEM;
}
temp_count = count + 1;
}
--
My question is why the transfer count in else logic is count+1 but in if
logic it's only count?
When I changed it from count＋1 to count and use a test program to read
a spi flash, I found the DMA rx interrupt can not be triggered.
The test program hung for ever.

Would anybody have any idea about this?

Thanks.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v6 1/6] Davinci: generalized debug macros

[Cyril Chemparathy]

Hi Kevin,

[...]
>> Tony's updated version[1] for OMAP is not using 0x3ffc offset since only
>> 4 bytes are used.

I see that Tony's patch passes just one word through this area.  The
davinci code on the other hand passes both phys and virt, hence the
extra word of allocation.

>> Any objection to making and testing that change?
> 
> fwiw, I boot tested using 0x3ffc on DMx (dm6446, dm355, dm6467 EVMs)
> as well DA8xx (da830 and da850 EVMs) and it works fine for all.

Interesting.  I would think that it would end up clobbering the word @4000.

Regards
Cyril.

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v6 3/6] Davinci: tnetv107x soc support

[Cyril Chemparathy]

Hi Kevin,

[...]
>> +#define PINMUX(x)   (4 * (x))
> 
> minor nit...
> 
> Isn't this a duplicate of what is now in  ?

Yes, I will remove this unfortunate left over.

Regards
Cyril.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v6 4/6] Davinci: tnetv107x initial gpio support

[Cyril Chemparathy]

Hi Kevin,

[...]
> I know Sergei isn't used to me agreeing with him ;) but I tend to
> agree with him on the increased bulk of gpio_set_value().
> 
> It's not simply the increased size that is an issue here.  The point
> of these inlines (as the comment suggests) is for low-overhead
> bit-banging.  With the introduction of different methods depending on
> GPIO type, as well as the locking for the tnetv style, this is no
> longer low-overhead in my mind.
> 
> Below is an alternate solution.

Agreed on the solution.  This is (somewhat) similar to an earlier
tnetv107x series, in which the inline gpio code wouldn't kick in on the
tnetv107x controller.  Looks like we've gone full circle on this.

I will post an updated series.  Thanks.

Regards
Cyril.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v6 0/6] Davinci: initial tnetv107x patch series

[Cyril Chemparathy]

Hi Kevin,

[...]
> Is there anything in the DaVinci-specific parts now that is preventing
> a single kernel shared between DMx an tnetv?

No, at least not by design :-)

> I know about the ARM-generic code that has problems when both ARMv5
> and ARMv6 are enabled, but am curious about any remaining blocks in
> the arch/arm/mach-davinci/* code.

Regards
Cyril.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

davinci linux kernel updata

[liuyue18301]

hello everybody:
   if i want to updata the davinci linux kernel to the higher.what should i 
do,i think the  gcc version has to update.now,i have download the kernle 
version:2.6.32 and gcc 4.3.3,what i do is just update the gcc and linux kernel 
in the SEED-SDK.the flow is ok?
  thank you  

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: davinci linux kernel updata

[stanley.miao]

git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git

liuyue18301 wrote:

hello everybody:
if i want to updata the davinci linux kernel to the higher.what should 
i do,i think the gcc version has to update.now,i have download the 
kernle version:2.6.32 and gcc 4.3.3,what i do is just update the gcc 
and linux kernel in the SEED-SDK.the flow is ok?

thank you




?? 


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
  


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: davinci linux kernel updata

[Jon Povey]

liuyue18301 wrote:
>if i want to updata the davinci linux kernel to the
> higher.what should i do,i think the  gcc version has to update.now,i
> have download the kernle version:2.6.32 and gcc 4.3.3,what i do is
> just update the gcc and linux kernel in the SEED-SDK.the flow is ok?

I don't know what the SEED-SDK is.
For the git kernel I have been using the CodeSourcery toolchain:

http://www.codesourcery.com/sgpp/lite/arm/portal/release858

As recommended here:

http://processors.wiki.ti.com/index.php?title=DaVinci_GIT_Linux_Kernel#Overview

Hope this helps.


--
Jon Povey
jon.po...@racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 
.
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, 
MK18 1TB .

The information contained in this electronic mail transmission is intended by 
Racelogic Ltd for the use of the named individual or entity to which it is 
directed and may contain information that is confidential or privileged. If you 
have received this electronic mail transmission in error, please delete it from 
your system without copying or forwarding it, and notify the sender of the 
error by reply email so that the sender's address records can be corrected. The 
views expressed by the sender of this communication do not necessarily 
represent those of Racelogic Ltd. Please note that Racelogic reserves the right 
to monitor e-mail communications passing through its network


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: [PATCH RFC v8] MUSB: DA8xx/OMAP-L1x glue layer

[Gupta, Ajay Kumar]

Hi,
> -Original Message-
> From: davinci-linux-open-source-
> bounces+ajay.gupta=ti@linux.davincidsp.com [mailto:davinci-linux-open-
> source-bounces+ajay.gupta=ti@linux.davincidsp.com] On Behalf Of Sergei
> Shtylyov
> Sent: Wednesday, May 12, 2010 11:42 PM
> To: linux-...@vger.kernel.org
> Cc: davinci-linux-open-source@linux.davincidsp.com
> Subject: [PATCH RFC v8] MUSB: DA8xx/OMAP-L1x glue layer
> 
> Texas Instruments DA8xx/OMAP-L1x glue layer for the MUSBMHRDC driver.
> 
> Signed-off-by: Sergei Shtylyov 
> Signed-off-by: Yadviga Grigorieva 
> 
> ---
> The patch is against the recent Linus' tree.
> 
> WARNING: the MUSB and OHCI drivers will only work if your boot loader
> leaves
> the DA8xx boot configuration registers unlocked, otherwise they will lock
> up
> the kernel!
> 
> Changes since the previous version:
> - removed DMA related code (to be added back by a later patch);
> - removed spurious interrupt message from da8xx_interrupt();
> - added a check for USB 1.1 being clocked from USB 2.0 PHY to phy_off();
> - moved USB register #define's from cppi41_dma.h in another patch, adding
>   'DA8XX_' prefix to them;
> - s/DA8XX_[RT]X_EP_MASK/DA8XX_USB_[RT]X_EP_MASK/, s/DA8XX_[RT]X_INTR_MASK/
>   DA8XX_INTR_[RT]X_MASK/, also reordered these macros;
> - used IO_ADDRESS() macro in #define CFGCHIP2 to avoid having to export
>   'da8xx_syscfg0_base' for modular build;
> - removed setting 'musb->is_active' from the code handling DRVVBUS
> interrupt;
> - moved the transceiver initialization further down in
> musb_platform_init();
> - moved s/ARCH_DAVINCI/ARCH_DAVINCI_DMx/ change into the separate patch;
> - fixed up some comments;
> - fixed reject in musb_core.h...
> 
>  drivers/usb/musb/Kconfig |5
>  drivers/usb/musb/Makefile|4
>  drivers/usb/musb/da8xx.c |  492
> +++
>  drivers/usb/musb/musb_core.h |1
>  4 files changed, 501 insertions(+), 1 deletion(-)
> 
[..]
> + * REVISIT (PM): we should be able to keep the PHY in low power mode most
> + * of the time (24 MHz oscillator and PLL off, etc.) by setting POWER.D0
> + * and, when in host mode, autosuspending idle root ports... PHY_PLLON
> + * (overriding SUSPENDM?) then likely needs to stay off.
> + */
> +
> +static inline void phy_on(void)
> +{
> + u32 cfgchip2 = __raw_readl(CFGCHIP2);
> +
> + /*
> +  * Start the on-chip PHY and its PLL.
> +  */
> + cfgchip2 &= ~(CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN |
> CFGCHIP2_OTGPWRDN);
> + cfgchip2 |= CFGCHIP2_PHY_PLLON;

How about values USB0REF-FREQ, USB0DATPOL, USB0OTGMODE bits ? Are they
Getting set elsewhere or default value is good to go?

> + __raw_writel(cfgchip2, CFGCHIP2);
> +
> + pr_info("Waiting for USB PHY clock good...\n");
> + while (!(__raw_readl(CFGCHIP2) & CFGCHIP2_PHYCLKGD))
> + cpu_relax();

It's good to have a timeout here. I have seen this bit not
getting updated in some scenarios on AM3517 and also on
PUMA5 platforms which would cause a system lockup here.

-Ajay
> +}
> +
> +static inline void phy_off(void)
> +{
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source