Re: [PATCH] ARM: DaVinci: ASoC: Define AIC3x setup info

2009-08-26 Thread Kevin Hilman 
Chaithrika U S  writes:

> The codec setup data structure has to be defined for
> successful probe.
>
> Signed-off-by: Chaithrika U S 
> ---
> Applies to temp/asoc branch of DaVinci GIT tree.

Thanks Chaithrika,

OK, I pushed a new 'temp/asoc' branch with Chaithrika's changes folded
into mine, changing the author to Chaithrika.

Now there's one patch for DaVinci git and the other for ASoC.

I'll pull the one into DaVinci git master today and add it to my
for-next.  Mark can merge the other and then we should be back to
building/working audio in linux-next.

Kevin


>  sound/soc/davinci/davinci-evm.c |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
> index 81628ac..67414f6 100644
> --- a/sound/soc/davinci/davinci-evm.c
> +++ b/sound/soc/davinci/davinci-evm.c
> @@ -206,27 +206,33 @@ static struct snd_soc_card da850_snd_soc_card = {
>   .num_links = 1,
>  };
>  
> +static struct aic3x_setup_data aic3x_setup;
> +
>  /* evm audio subsystem */
>  static struct snd_soc_device evm_snd_devdata = {
>   .card = &snd_soc_card_evm,
>   .codec_dev = &soc_codec_dev_aic3x,
> + .codec_data = &aic3x_setup,
>  };
>  
>  /* evm audio subsystem */
>  static struct snd_soc_device dm6467_evm_snd_devdata = {
>   .card = &dm6467_snd_soc_card_evm,
>   .codec_dev = &soc_codec_dev_aic3x,
> + .codec_data = &aic3x_setup,
>  };
>  
>  /* evm audio subsystem */
>  static struct snd_soc_device da830_evm_snd_devdata = {
>   .card = &da830_snd_soc_card,
>   .codec_dev = &soc_codec_dev_aic3x,
> + .codec_data = &aic3x_setup,
>  };
>  
>  static struct snd_soc_device da850_evm_snd_devdata = {
>   .card   = &da850_snd_soc_card,
>   .codec_dev  = &soc_codec_dev_aic3x,
> + .codec_data = &aic3x_setup,
>  };
>  
>  static struct platform_device *evm_snd_device;
> -- 
> 1.5.6

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

davinci vs. v4l2: lots of conflicts in merge for linux-next

2009-08-26 Thread Kevin Hilman 
OK, this has gotten a bit out of control, to the point where I cannot
solve this myself.  This is partially due to me being on the road and
not keeping a close enough eye on the various video patches.

I've pushed a new 'davinci-next' branch to davinci git[1] which is
what I would like to make available for linux-next.  This includes all
the patches from davinci git master which touch
arch/arm/mach-davinci/*.

I then went to do a test a merge of the master branch of Mauro's
linux-next tree, and there are lots of conflicts.  Some are trivial to
resolve (the various I2C_BOARD_INFO() conflicts) but others are more
difficult, and someone more familar with the video drivers should sort
them out.

The two patches from davinci master that seem to be causing all the
problems are:

  ARM: DaVinci: DM646x Video: Platform and board specific setup
  davinci: video: restructuring to support vpif capture driver

These cause the conflicts with the v4l2 next tree.  So, in
davinci-next I've dropped these two patches.

I think the way to fix this is for someone to take all the board
changes from the v4l2 tree and rebase them on top of my davinci-next,
dropping them from v4l2 next. I'll then merge them into davinci-next,
and this should make the two trees merge properly in linux-next.

We need to get this sorted out soon so that they can be merged for the
next merge window.

Going forward, I would prefer that all changes to arch/arm/* stuff go
through davinci git and all drivers/* stuff goes through V4L2.  This
will avoid this kind of overlap/conflict in the future since DaVinci
core code is going through lots of changes.

Kevin

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

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

[PATCH] Add platform Support for DM646x USB.

2009-08-26 Thread Swaminathan S 
 This patch adds platform support for USB controller on DM6467 platform.  The
 patch sets up the clock, memory map, USB VBUS control logic.

 Signed-off-by: Swaminathan S 

---
 arch/arm/mach-davinci/board-dm646x-evm.c |   34 ++
 arch/arm/mach-davinci/dm646x.c   |8 +++
 2 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c 
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 8c88fd0..c48b0a4 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -59,6 +59,7 @@
 /* CPLD Register 0 bits to control ATA */
 #define DM646X_EVM_ATA_RST BIT(0)
 #define DM646X_EVM_ATA_PWD BIT(1)
+#define DM646X_EVM_USB_VBUSBIT(7)
 
 #define DM646X_EVM_PHY_MASK(0x2)
 #define DM646X_EVM_MDIO_FREQUENCY  (220) /* PHY bus frequency */
@@ -80,10 +81,13 @@ static struct davinci_uart_config uart_config __initdata = {
.enabled_uarts = (1 << 0),
 };
 
+struct i2c_client *cple_reg0_client;
+
 /* CPLD Register 0 Client: used for I/O Control */
 static int cpld_reg0_probe(struct i2c_client *client,
   const struct i2c_device_id *id)
 {
+   cple_reg0_client = client;
if (HAS_ATA) {
u8 data;
struct i2c_msg msg[2] = {
@@ -107,9 +111,39 @@ static int cpld_reg0_probe(struct i2c_client *client,
i2c_transfer(client->adapter, msg + 1, 1);
}
 
+   setup_usb(500, 8);
+
return 0;
 }
 
+void usb_vbus_control(u8 on)
+{
+   u8 data;
+   struct i2c_msg msg[2] = {
+   {
+   .addr = cple_reg0_client->addr,
+   .flags = I2C_M_RD,
+   .len = 1,
+   .buf = &data,
+   },
+   {
+   .addr = cple_reg0_client->addr,
+   .flags = 0,
+   .len = 1,
+   .buf = &data,
+   },
+   };
+
+   i2c_transfer(cple_reg0_client->adapter, msg, 1);
+   if (on)
+   data |= DM646X_EVM_USB_VBUS;
+   else
+   data &= ~DM646X_EVM_USB_VBUS;
+
+   i2c_transfer(cple_reg0_client->adapter, msg + 1, 1);
+}
+EXPORT_SYMBOL(usb_vbus_control);
+
 static const struct i2c_device_id cpld_reg_ids[] = {
{ "cpld_reg0", 0, },
{ },
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index a9b20e5..633a25b 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -315,6 +315,13 @@ static struct clk vpif1_clk = {
.flags = ALWAYS_ENABLED,
 };
 
+static struct clk usb_clk = {
+   .name = "usb",
+   .parent = &pll1_sysclk3,
+   .lpsc = DAVINCI_LPSC_USB,
+   .flags = ALWAYS_ENABLED,
+};
+
 struct davinci_clk dm646x_clks[] = {
CLK(NULL, "ref", &ref_clk),
CLK(NULL, "aux", &aux_clkin),
@@ -355,6 +362,7 @@ struct davinci_clk dm646x_clks[] = {
CLK("palm_bk3710", NULL, &ide_clk),
CLK(NULL, "vpif0", &vpif0_clk),
CLK(NULL, "vpif1", &vpif1_clk),
+   CLK(NULL, "usb", &usb_clk),
CLK(NULL, NULL, NULL),
 };
 
-- 
1.6.0.rc1.64.g61192

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

[PATCH] MUSB: Add support for DM646x USB.

2009-08-26 Thread Swaminathan S 
DM646x USB controller is based on Mentor USB Controller (MUSB).  This patch
adds support for DM646x USB controller to the MUSB driver. DM646x USB controller
doest not support OTG and hence the roles(Host/Device) need to be specified
as part of Kernel compile and the same needs to be set up when DM646x boots up.
The VBUS is controlled through a CPLD on the DM646x EVM.  This patch implements
the VBUS control accordingly.

Signed-off-by: Swaminathan S 

---
---
 drivers/usb/musb/davinci.c |   32 
 drivers/usb/musb/davinci.h |6 ++
 2 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 6691381..87bbd7c 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -41,7 +41,7 @@
 
 #include "musb_core.h"
 
-#ifdef CONFIG_MACH_DAVINCI_EVM
+#if defined(CONFIG_MACH_DAVINCI_EVM) || defined(CONFIG_MACH_DAVINCI_DM6467_EVM)
 #define GPIO_nVBUS_DRV 160
 #endif
 
@@ -65,6 +65,13 @@ static inline void phy_on(void)
/* power everything up; start the on-chip PHY and its PLL */
phy_ctrl &= ~(USBPHY_OSCPDWN | USBPHY_OTGPDWN | USBPHY_PHYPDWN);
phy_ctrl |= USBPHY_SESNDEN | USBPHY_VBDTCTEN | USBPHY_PHYPLLON;
+   if (cpu_is_davinci_dm646x()) {
+   phy_ctrl |= USBPHY_NDATAPOL | USBPHY_SESSION_VBUS;
+   phy_ctrl |= is_peripheral_enabled() ? USBPHY_PERI_USBID :
+   phy_ctrl;
+   phy_ctrl &= ~USBPHY_VBDTCTEN;
+   }
+
__raw_writel(phy_ctrl, USB_PHY_CTRL);
 
/* wait for PLL to lock before proceeding */
@@ -152,7 +159,7 @@ void musb_platform_disable(struct musb *musb)
  * when J10 is out, and TI documents it as handling OTG.
  */
 
-#ifdef CONFIG_MACH_DAVINCI_EVM
+#if defined(CONFIG_MACH_DAVINCI_EVM) || defined(CONFIG_MACH_DAVINCI_DM6467_EVM)
 
 static int vbus_state = -1;
 
@@ -162,7 +169,12 @@ static int vbus_state = -1;
  */
 static void evm_deferred_drvvbus(struct work_struct *ignored)
 {
-   gpio_set_value_cansleep(GPIO_nVBUS_DRV, vbus_state);
+   if (machine_is_davinci_evm())
+   gpio_set_value_cansleep(GPIO_nVBUS_DRV, vbus_state);
+
+   if (machine_is_davinci_dm6467_evm())
+   usb_vbus_control(vbus_state);
+
vbus_state = !vbus_state;
 }
 
@@ -170,7 +182,7 @@ static void evm_deferred_drvvbus(struct work_struct 
*ignored)
 
 static void davinci_source_power(struct musb *musb, int is_on, int immediate)
 {
-#ifdef CONFIG_MACH_DAVINCI_EVM
+#if defined(CONFIG_MACH_DAVINCI_EVM) || defined(CONFIG_MACH_DAVINCI_DM6467_EVM)
if (is_on)
is_on = 1;
 
@@ -178,12 +190,16 @@ static void davinci_source_power(struct musb *musb, int 
is_on, int immediate)
return;
vbus_state = !is_on;/* 0/1 vs "-1 == unknown/init" */
 
-   if (machine_is_davinci_evm()) {
+   if (machine_is_davinci_evm() || machine_is_davinci_dm6467_evm()) {
static DECLARE_WORK(evm_vbus_work, evm_deferred_drvvbus);
 
-   if (immediate)
-   gpio_set_value_cansleep(GPIO_nVBUS_DRV, vbus_state);
-   else
+   if (immediate) {
+   if (machine_is_davinci_evm())
+   gpio_set_value_cansleep(GPIO_nVBUS_DRV,
+   vbus_state);
+   if (machine_is_davinci_dm6467_evm())
+   usb_vbus_control(vbus_state);
+   } else
schedule_work(&evm_vbus_work);
}
if (immediate)
diff --git a/drivers/usb/musb/davinci.h b/drivers/usb/musb/davinci.h
index 046c844..b802b83 100644
--- a/drivers/usb/musb/davinci.h
+++ b/drivers/usb/musb/davinci.h
@@ -16,6 +16,9 @@
 
 /* Integrated highspeed/otg PHY */
 #define USBPHY_CTL_PADDR   (DAVINCI_SYSTEM_MODULE_BASE + 0x34)
+#define USBPHY_NDATAPOLBIT(18)
+#define USBPHY_SESSION_VBUSBIT(17)
+#define USBPHY_PERI_USBID  BIT(16)
 #define USBPHY_DATAPOL BIT(11) /* (dm355) switch D+/D- */
 #define USBPHY_PHYCLKGDBIT(8)
 #define USBPHY_SESNDEN BIT(7)  /* v(sess_end) comparator */
@@ -104,4 +107,7 @@
 
 #define DAVINCI_BASE_OFFSET0x400
 
+#ifdef CONFIG_MACH_DAVINCI_DM6467_EVM
+extern void usb_vbus_control(u8 on);
+#endif
 #endif /* __MUSB_HDRDF_H__ */
-- 
1.6.0.rc1.64.g61192

___
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] Add platform Support for DM646x USB.

2009-08-26 Thread Sergei Shtylyov 

Hello.

Swaminathan S wrote:


 This patch adds platform support for USB controller on DM6467 platform.  The
 patch sets up the clock, memory map, USB VBUS control logic.

 Signed-off-by: Swaminathan S 
  

[...]

diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c 
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 8c88fd0..c48b0a4 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
  

[...]

@@ -80,10 +81,13 @@ static struct davinci_uart_config uart_config __initdata = {
.enabled_uarts = (1 << 0),
 };
 
+struct i2c_client *cple_reg0_client;
  


  'cple', not 'cpld'? Also, Kevin has already told you to make it 
'static'...



diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index a9b20e5..633a25b 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -315,6 +315,13 @@ static struct clk vpif1_clk = {
.flags = ALWAYS_ENABLED,
 };
 
+static struct clk usb_clk = {

+   .name = "usb",
+   .parent = &pll1_sysclk3,
+   .lpsc = DAVINCI_LPSC_USB,
+   .flags = ALWAYS_ENABLED,
  


  Kevin has already told you to drop ALWAYS_ENABLED

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

Re: [PATCH] MUSB: Add support for DM646x USB.

2009-08-26 Thread Sergei Shtylyov 

Hello.

Swaminathan S wrote:


DM646x USB controller is based on Mentor USB Controller (MUSB).  This patch
adds support for DM646x USB controller to the MUSB driver. DM646x USB controller
doest not support OTG and hence the roles(Host/Device) need to be specified
as part of Kernel compile and the same needs to be set up when DM646x boots up.
The VBUS is controlled through a CPLD on the DM646x EVM.  This patch implements
the VBUS control accordingly.

Signed-off-by: Swaminathan S 


 Again, Kevin has already told you to rework the way VBUS is handled to 
avoid using machine_is_*()...


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

RE: [PATCH] MUSB: Add support for DM646x USB.

2009-08-26 Thread Subbrathnam, Swaminathan 
My mistake that I did not read through his comments at the end of his response. 
 Thanks for pointing it out.

-Original Message-
From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com] 
Sent: Wednesday, August 26, 2009 3:26 PM
To: Subbrathnam, Swaminathan
Cc: linux-...@vger.kernel.org; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH] MUSB: Add support for DM646x USB.

Hello.

Swaminathan S wrote:

> DM646x USB controller is based on Mentor USB Controller (MUSB).  This patch
> adds support for DM646x USB controller to the MUSB driver. DM646x USB 
> controller
> doest not support OTG and hence the roles(Host/Device) need to be specified
> as part of Kernel compile and the same needs to be set up when DM646x boots 
> up.
> The VBUS is controlled through a CPLD on the DM646x EVM.  This patch 
> implements
> the VBUS control accordingly.
>
> Signed-off-by: Swaminathan S 

  Again, Kevin has already told you to rework the way VBUS is handled to 
avoid using machine_is_*()...

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] Add platform Support for DM646x USB.

2009-08-26 Thread Swaminathan S 
This patch adds platform support for USB controller on DM6467 platform.  The
patch sets up the clock, memory map, USB VBUS control logic.

Signed-off-by: Swaminathan S 

--
 arch/arm/mach-davinci/board-dm646x-evm.c |   34 ++
 arch/arm/mach-davinci/dm646x.c   |7 ++
 2 files changed, 41 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c 
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 8c88fd0..aeb4641 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -59,6 +59,7 @@
 /* CPLD Register 0 bits to control ATA */
 #define DM646X_EVM_ATA_RST BIT(0)
 #define DM646X_EVM_ATA_PWD BIT(1)
+#define DM646X_EVM_USB_VBUSBIT(7)
 
 #define DM646X_EVM_PHY_MASK(0x2)
 #define DM646X_EVM_MDIO_FREQUENCY  (220) /* PHY bus frequency */
@@ -80,10 +81,13 @@ static struct davinci_uart_config uart_config __initdata = {
.enabled_uarts = (1 << 0),
 };
 
+static struct i2c_client *cpld_reg0_client;
+
 /* CPLD Register 0 Client: used for I/O Control */
 static int cpld_reg0_probe(struct i2c_client *client,
   const struct i2c_device_id *id)
 {
+   cpld_reg0_client = client;
if (HAS_ATA) {
u8 data;
struct i2c_msg msg[2] = {
@@ -107,9 +111,39 @@ static int cpld_reg0_probe(struct i2c_client *client,
i2c_transfer(client->adapter, msg + 1, 1);
}
 
+   setup_usb(500, 8);
+
return 0;
 }
 
+void usb_vbus_control(u8 on)
+{
+   u8 data;
+   struct i2c_msg msg[2] = {
+   {
+   .addr = cpld_reg0_client->addr,
+   .flags = I2C_M_RD,
+   .len = 1,
+   .buf = &data,
+   },
+   {
+   .addr = cpld_reg0_client->addr,
+   .flags = 0,
+   .len = 1,
+   .buf = &data,
+   },
+   };
+
+   i2c_transfer(cpld_reg0_client->adapter, msg, 1);
+   if (on)
+   data |= DM646X_EVM_USB_VBUS;
+   else
+   data &= ~DM646X_EVM_USB_VBUS;
+
+   i2c_transfer(cpld_reg0_client->adapter, msg + 1, 1);
+}
+EXPORT_SYMBOL(usb_vbus_control);
+
 static const struct i2c_device_id cpld_reg_ids[] = {
{ "cpld_reg0", 0, },
{ },
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index a9b20e5..edfc22f 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -315,6 +315,12 @@ static struct clk vpif1_clk = {
.flags = ALWAYS_ENABLED,
 };
 
+static struct clk usb_clk = {
+   .name = "usb",
+   .parent = &pll1_sysclk3,
+   .lpsc = DAVINCI_LPSC_USB,
+};
+
 struct davinci_clk dm646x_clks[] = {
CLK(NULL, "ref", &ref_clk),
CLK(NULL, "aux", &aux_clkin),
@@ -355,6 +361,7 @@ struct davinci_clk dm646x_clks[] = {
CLK("palm_bk3710", NULL, &ide_clk),
CLK(NULL, "vpif0", &vpif0_clk),
CLK(NULL, "vpif1", &vpif1_clk),
+   CLK(NULL, "usb", &usb_clk),
CLK(NULL, NULL, NULL),
 };
 
-- 
1.6.0.rc1.64.g61192

___
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] ARM: DaVinci: ASoC: Define AIC3x setup info

2009-08-26 Thread Chaithrika U S 
On Wed, Aug 26, 2009 at 14:58:02, Mark Brown wrote:
> On Wed, Aug 26, 2009 at 12:08:10PM -0400, Chaithrika U S wrote:
> > The codec setup data structure has to be defined for
> > successful probe.
> 
> This would be better fixed in the CODEC driver - if there's nothing in
> the setup data it should cope.  Please try the patch below, it should
> eliminate the need for the setup data but I've not even compile tested
> it:
> 

Mark,

Agree. I did a quick try of this patch on DA850/OMAP-L138 EVM and
it is working fine. Thank you for the patch.

Regards, 
Chaithrika

> diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
> index 5d54767..3395cf9 100644
> --- a/sound/soc/codecs/tlv320aic3x.c
> +++ b/sound/soc/codecs/tlv320aic3x.c
> @@ -1385,15 +1385,14 @@ static int aic3x_probe(struct platform_device *pdev)
>   socdev->card->codec = codec;
>   setup = socdev->codec_data;
>  
> - if (!setup) {
> - dev_err(&pdev->dev, "No setup data supplied\n");
> - return -EINVAL;
> + if (setup) {
> + /* setup GPIO functions */
> + aic3x_write(codec, AIC3X_GPIO1_REG,
> + (setup->gpio_func[0] & 0xf) << 4);
> + aic3x_write(codec, AIC3X_GPIO2_REG,
> + (setup->gpio_func[1] & 0xf) << 4);
>   }
>  
> - /* setup GPIO functions */
> - aic3x_write(codec, AIC3X_GPIO1_REG, (setup->gpio_func[0] & 0xf) << 4);
> - aic3x_write(codec, AIC3X_GPIO2_REG, (setup->gpio_func[1] & 0xf) << 4);
> -
>   /* register pcms */
>   ret = snd_soc_new_pcms(socdev, SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1);
>   if (ret < 0) {
> 


___
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] MUSB: Add support for DM646x USB.

2009-08-26 Thread Subbrathnam, Swaminathan 
Kevin,
I will re-organize the vbus control as suggested as a separate patch.

It will have to be tested across DaVinci, OMAP platforms (probably 
Blackfin) as at that point it will be a generic way of controlling the Vbus 
line.

Regards
swami

-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com] 
Sent: Tuesday, August 25, 2009 5:29 PM
To: Subbrathnam, Swaminathan
Cc: linux-...@vger.kernel.org; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH] MUSB: Add support for DM646x USB.

Swaminathan S  writes:

Again, need a descriptive changelog please.

>  Signed-off-by: Swaminathan S 
>
> ---
>  drivers/usb/musb/davinci.c |   30 +++---
>  drivers/usb/musb/davinci.h |6 ++
>  2 files changed, 29 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
> index 6691381..2b8345a 100644
> --- a/drivers/usb/musb/davinci.c
> +++ b/drivers/usb/musb/davinci.c
> @@ -65,6 +65,13 @@ static inline void phy_on(void)
>   /* power everything up; start the on-chip PHY and its PLL */
>   phy_ctrl &= ~(USBPHY_OSCPDWN | USBPHY_OTGPDWN | USBPHY_PHYPDWN);
>   phy_ctrl |= USBPHY_SESNDEN | USBPHY_VBDTCTEN | USBPHY_PHYPLLON;
> + if (cpu_is_davinci_dm646x()) {
> + phy_ctrl |= USBPHY_NDATAPOL | USBPHY_SESSION_VBUS;
> + phy_ctrl |= is_peripheral_enabled() ? USBPHY_PERI_USBID :
> + phy_ctrl;
> + phy_ctrl &= ~USBPHY_VBDTCTEN;
> + }
> +
>   __raw_writel(phy_ctrl, USB_PHY_CTRL);
>  
>   /* wait for PLL to lock before proceeding */
> @@ -152,7 +159,7 @@ void musb_platform_disable(struct musb *musb)
>   * when J10 is out, and TI documents it as handling OTG.
>   */
>  
> -#ifdef CONFIG_MACH_DAVINCI_EVM
> +#if defined(CONFIG_MACH_DAVINCI_EVM) || 
> defined(CONFIG_MACH_DAVINCI_DM6467_EVM)
>  
>  static int vbus_state = -1;
>  
> @@ -162,7 +169,12 @@ static int vbus_state = -1;
>   */
>  static void evm_deferred_drvvbus(struct work_struct *ignored)
>  {
> - gpio_set_value_cansleep(GPIO_nVBUS_DRV, vbus_state);
> + if (machine_is_davinci_evm())
> + gpio_set_value_cansleep(GPIO_nVBUS_DRV, vbus_state);
> +
> + if (machine_is_davinci_dm6467_evm())
> + usb_vbus_control(vbus_state);
> +

OK, this I don't like.  The current hack of board-specific code in
this file was bad enought, but it's time to fix this instead of
extending the hack.

What we need is a board-specific vbus control function, defined in the
board files and passed in platform_data.

That will allow us to get rid of board-specific code from this file.

>   vbus_state = !vbus_state;
>  }
>  
> @@ -170,7 +182,7 @@ static void evm_deferred_drvvbus(struct work_struct 
> *ignored)
>  
>  static void davinci_source_power(struct musb *musb, int is_on, int immediate)
>  {
> -#ifdef CONFIG_MACH_DAVINCI_EVM
> +#if defined(CONFIG_MACH_DAVINCI_EVM) || 
> defined(CONFIG_MACH_DAVINCI_DM6467_EVM)
>   if (is_on)
>   is_on = 1;
>  
> @@ -178,12 +190,16 @@ static void davinci_source_power(struct musb *musb, int 
> is_on, int immediate)
>   return;
>   vbus_state = !is_on;/* 0/1 vs "-1 == unknown/init" */
>  
> - if (machine_is_davinci_evm()) {
> + if (machine_is_davinci_evm() || machine_is_davinci_dm6467_evm()) {
>   static DECLARE_WORK(evm_vbus_work, evm_deferred_drvvbus);
>  
> - if (immediate)
> - gpio_set_value_cansleep(GPIO_nVBUS_DRV, vbus_state);
> - else
> + if (immediate) {
> + if (machine_is_davinci_evm())
> + gpio_set_value_cansleep(GPIO_nVBUS_DRV,
> + vbus_state);
> + if (machine_is_davinci_dm6467_evm())
> + usb_vbus_control(vbus_state);
> + } else
>   schedule_work(&evm_vbus_work);

ditto... we shouldn't have any machine_is_* code in this driver.

>   }
>   if (immediate)
> diff --git a/drivers/usb/musb/davinci.h b/drivers/usb/musb/davinci.h
> index 046c844..b802b83 100644
> --- a/drivers/usb/musb/davinci.h
> +++ b/drivers/usb/musb/davinci.h
> @@ -16,6 +16,9 @@
>  
>  /* Integrated highspeed/otg PHY */
>  #define USBPHY_CTL_PADDR (DAVINCI_SYSTEM_MODULE_BASE + 0x34)
> +#define USBPHY_NDATAPOL  BIT(18)
> +#define USBPHY_SESSION_VBUS  BIT(17)
> +#define USBPHY_PERI_USBIDBIT(16)
>  #define USBPHY_DATAPOL   BIT(11) /* (dm355) switch D+/D- */
>  #define USBPHY_PHYCLKGD  BIT(8)
>  #define USBPHY_SESNDEN   BIT(7)  /* v(sess_end) comparator */
> @@ -104,4 +107,7 @@
>  
>  #define DAVINCI_BASE_OFFSET  0x400
>  
> +#ifdef CONFIG_MACH_DAVINCI_DM6467_EVM
> +extern void usb_vbus_control(u8 on);
> +#endif

then this can disappear as well.

>  #endif   /

Re: [PATCH] Add platform Support for DM646x USB.

2009-08-26 Thread Kevin Hilman 
Swaminathan S  writes:

> This patch adds platform support for USB controller on DM6467 platform.  The
> patch sets up the clock, memory map, USB VBUS control logic.
>
> Signed-off-by: Swaminathan S 

I'll wait on this one until you sort out the vbus control generalization.

Kevin

> --
>  arch/arm/mach-davinci/board-dm646x-evm.c |   34 
> ++
>  arch/arm/mach-davinci/dm646x.c   |7 ++
>  2 files changed, 41 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c 
> b/arch/arm/mach-davinci/board-dm646x-evm.c
> index 8c88fd0..aeb4641 100644
> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
> @@ -59,6 +59,7 @@
>  /* CPLD Register 0 bits to control ATA */
>  #define DM646X_EVM_ATA_RST   BIT(0)
>  #define DM646X_EVM_ATA_PWD   BIT(1)
> +#define DM646X_EVM_USB_VBUS  BIT(7)
>  
>  #define DM646X_EVM_PHY_MASK  (0x2)
>  #define DM646X_EVM_MDIO_FREQUENCY(220) /* PHY bus frequency */
> @@ -80,10 +81,13 @@ static struct davinci_uart_config uart_config __initdata 
> = {
>   .enabled_uarts = (1 << 0),
>  };
>  
> +static struct i2c_client *cpld_reg0_client;
> +
>  /* CPLD Register 0 Client: used for I/O Control */
>  static int cpld_reg0_probe(struct i2c_client *client,
>  const struct i2c_device_id *id)
>  {
> + cpld_reg0_client = client;
>   if (HAS_ATA) {
>   u8 data;
>   struct i2c_msg msg[2] = {
> @@ -107,9 +111,39 @@ static int cpld_reg0_probe(struct i2c_client *client,
>   i2c_transfer(client->adapter, msg + 1, 1);
>   }
>  
> + setup_usb(500, 8);
> +
>   return 0;
>  }
>  
> +void usb_vbus_control(u8 on)
> +{
> + u8 data;
> + struct i2c_msg msg[2] = {
> + {
> + .addr = cpld_reg0_client->addr,
> + .flags = I2C_M_RD,
> + .len = 1,
> + .buf = &data,
> + },
> + {
> + .addr = cpld_reg0_client->addr,
> + .flags = 0,
> + .len = 1,
> + .buf = &data,
> + },
> + };
> +
> + i2c_transfer(cpld_reg0_client->adapter, msg, 1);
> + if (on)
> + data |= DM646X_EVM_USB_VBUS;
> + else
> + data &= ~DM646X_EVM_USB_VBUS;
> +
> + i2c_transfer(cpld_reg0_client->adapter, msg + 1, 1);
> +}
> +EXPORT_SYMBOL(usb_vbus_control);
> +
>  static const struct i2c_device_id cpld_reg_ids[] = {
>   { "cpld_reg0", 0, },
>   { },
> diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
> index a9b20e5..edfc22f 100644
> --- a/arch/arm/mach-davinci/dm646x.c
> +++ b/arch/arm/mach-davinci/dm646x.c
> @@ -315,6 +315,12 @@ static struct clk vpif1_clk = {
>   .flags = ALWAYS_ENABLED,
>  };
>  
> +static struct clk usb_clk = {
> + .name = "usb",
> + .parent = &pll1_sysclk3,
> + .lpsc = DAVINCI_LPSC_USB,
> +};
> +
>  struct davinci_clk dm646x_clks[] = {
>   CLK(NULL, "ref", &ref_clk),
>   CLK(NULL, "aux", &aux_clkin),
> @@ -355,6 +361,7 @@ struct davinci_clk dm646x_clks[] = {
>   CLK("palm_bk3710", NULL, &ide_clk),
>   CLK(NULL, "vpif0", &vpif0_clk),
>   CLK(NULL, "vpif1", &vpif1_clk),
> + CLK(NULL, "usb", &usb_clk),
>   CLK(NULL, NULL, NULL),
>  };
>  
> -- 
> 1.6.0.rc1.64.g61192
>
> ___
> 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

Regarding dynamic memory allocation on DSP side of DM6446.

2009-08-26 Thread Sandeep YEDIRE 


 Hello,
Can we allocate Dynamic memory on DSP side of DM6446?

Many Thanks,
Sandeep.Yedire


  See the Web's breaking stories, chosen by people like you. Check out 
Yahoo! Buzz. http://in.buzz.yahoo..com/___
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 vs. v4l2: lots of conflicts in merge for linux-next

2009-08-26 Thread Karicheri, Muralidharan 
Kevin,

Ok, I see you have merged vpif capture architecture part to master branch
of davinci. 

So what you are suggesting is to remove all vpif/vpfe patches from 
arch/arm/davinci of v4l linux-next tree (So I guess this is what Mauro should 
do on linux-next). So architecture part of all future video patches are to be 
re-created and re-submitted based on davinci-next and will be merged only to 
davinci tree and Mauro will merge the v4l part.

Kevin & Mauro,

So only concern I have is that these patches may not compile (either 
architecture part or v4l part) until the counter part becomes available on the 
tree. Is this fine? 

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com

>-Original Message-
>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: Wednesday, August 26, 2009 5:00 AM
>To: Karicheri, Muralidharan; Mauro Carvalho Chehab
>Cc: linux-me...@vger.kernel.org; Hans Verkuil; DaVinci
>Subject: davinci vs. v4l2: lots of conflicts in merge for linux-next
>
>OK, this has gotten a bit out of control, to the point where I cannot
>solve this myself.  This is partially due to me being on the road and
>not keeping a close enough eye on the various video patches.
>
>I've pushed a new 'davinci-next' branch to davinci git[1] which is
>what I would like to make available for linux-next.  This includes all
>the patches from davinci git master which touch
>arch/arm/mach-davinci/*.
>
>I then went to do a test a merge of the master branch of Mauro's
>linux-next tree, and there are lots of conflicts.  Some are trivial to
>resolve (the various I2C_BOARD_INFO() conflicts) but others are more
>difficult, and someone more familar with the video drivers should sort
>them out.
>
>The two patches from davinci master that seem to be causing all the
>problems are:
>
>  ARM: DaVinci: DM646x Video: Platform and board specific setup
>  davinci: video: restructuring to support vpif capture driver
>
>These cause the conflicts with the v4l2 next tree.  So, in
>davinci-next I've dropped these two patches.
>
>I think the way to fix this is for someone to take all the board
>changes from the v4l2 tree and rebase them on top of my davinci-next,
>dropping them from v4l2 next. I'll then merge them into davinci-next,
>and this should make the two trees merge properly in linux-next.
>
>We need to get this sorted out soon so that they can be merged for the
>next merge window.
>
>Going forward, I would prefer that all changes to arch/arm/* stuff go
>through davinci git and all drivers/* stuff goes through V4L2.  This
>will avoid this kind of overlap/conflict in the future since DaVinci
>core code is going through lots of changes.
>
>Kevin
>
>[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git

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

RE: Problem with the current EDMA driver in the DaVinci GIT kernel

2009-08-26 Thread Paulraj, Sandeep 

> 
> On Tuesday 25 August 2009, Paulraj, Sandeep wrote:
> > Soon TI will support a DVSDK release based on the DaVinci GIT
> > kernel for DM355 and DM365.
> >
> > The entire DVSDK release uses EDAM API's for some resource
> > management and to acquire resources(Channels, PARAMS).
> >
> > But under the current implementation very few channels can be
> > acquired by the "Linuxutils" component of the DVSDK which manages
> > EDMA resources.
> 
> So why not just fix that "Linuxutils" stuff??
[Sandeep] That's done by other teams within TI and we want to re use as much as 
possible.
If features need to be added it has to be in the EDMA kernel driver
> 
> 
> > In DM355 very few channels can be acquired using the EDMA_CHANNEL_ANY
> > and in DM365 0 channels can be acquired with this option.
> 
> Right; there are only so many EDMA channels that aren't wired up to any
> hardware, and that's what CHANNEL_ANY provides.
[Sandeep] NO. I know for DM355 you are referring to pages 36-37 in
http://focus.ti.com/lit/ug/spruee4a/spruee4a.pdf

which says that channels 12, 13, 24, 56-63 are "reserved".
These do have hardware events associated with them and are used by the IMCOP in 
DM355. So the name "dma_chan_dm355_no_event" which suggest that there is no 
hardware event associated with the channels (in that structure) is not true.

Maybe just add a comment what we are trying to achieve should serve the purpose.

Or we can rename the struct to "dma_chan_dm355_hw_unused" and make 
corresponding meaningful changes in the driver to reflect the same.

> 
> 
> > Thus I propose to use 2 patches
> >
> > [deleted]
> >
> > What this will effectively do is to change the meaning of th
> > e "dma_chan_dm355_no_event" structure. Other channels do have
> > events associated with them but we "intentionally" add them to
> > this structure so that it can be acquired by the DVSDK.
> 
> Seems like an especially ugly hack.  Why not just define some
> new EDMA_CHANNEL_* selector with new semantics?
[Sandeep] its not a hack at all
> 
> What's unclear is just why you chose those numbers.  I suspect
> the issue is that you just want to avoid channels which are
> (a) used by Linux drivers, and (b) the board uses the relevant
> driver.
[Sandeep] yes
  Suggesting a name like EDMA_CHANNEL_HW_UNUSED.
[Sandeep] I don't think this is needed
> 
> So if for example the UART driver doesn't use EDMA the UART
> channels could be candidates ... as could GPIO banks in most
> cases, and "direct" GPIOs on a more board-specific basis.
[Sandeep] that's correct
> 
> - Dave
> 

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

Re: Problem with the current EDMA driver in the DaVinci GIT kernel

2009-08-26 Thread David Brownell 
> > So why not just fix that "Linuxutils" stuff??

> [Sandeep] That's done by other teams within TI and we want
> to re use as much as possible.

Fine, but from what you said, their stuff basically does
not work today.  So there's nothing to reuse.


> If features need to be added it has to be in the EDMA kernel driver

And "adding" features means working with that team so
everyone agrees on the interface.  


> > > In DM355 very few channels can be acquired using the EDMA_CHANNEL_ANY
> > > and in DM365 0 channels can be acquired with this option.
> > 
> > Right; there are only so many EDMA channels that aren't wired up to any
> > hardware, and that's what CHANNEL_ANY provides.
>
> [Sandeep] NO. I know for DM355 you are referring to pages 36-37 in
> http://focus.ti.com/lit/ug/spruee4a/spruee4a.pdf
> 
> which says that channels 12, 13, 24, 56-63 are "reserved".
> These do have hardware events associated with them and are
> used by the IMCOP in DM355.

Sounds like a doc bug to me.  It should at least say which
channels are used by IMCOP, vs which are free for use by
software triggering (or chaining), vs being e.g. broken.


> So the name "dma_chan_dm355_no_event" which suggest that
> there is no hardware event associated with the channels
> (in that structure) is not true.

It's as accurate as possible given that doc bug...


> Maybe just add a comment what we are trying to achieve
> should serve the purpose. 

There already *is* a description of what CHANNEL_ANY
is supposed to deliver... if you're going to redefine
those semantics, do it properly.  My default assumption
is, FWIW, that new semantics need a new EDMA_CHANNEL_*
symbol.  In this case one might argue that we don't
want the old semantics, just the new ones.  Which
still requires updating the interface spec.


> > What's unclear is just why you chose those numbers.  I suspect
> > the issue is that you just want to avoid channels which are
> > (a) used by Linux drivers, and (b) the board uses the relevant
> > driver.
> [Sandeep] yes
>   Suggesting a name like EDMA_CHANNEL_HW_UNUSED.
> [Sandeep] I don't think this is needed

Maybe not.  If all devices associated with DMA drivers can
be relied on to (i) register by a certain point in the init
sequence, and (ii) properly list the DMA channels they use
in their platform resources, then it's obviously possible
to construct a set of all DMA channels "potentially in use"
by drivers on that particular board.  

And the list of channels available for use with software
triggering, or chaining, or whatever this LinuxUtils thing
is ... would be the inverse of that set.  At that point
in the init sequence -- and before drivers are expected
to make CHANNEL_ allocations -- feed the set
of "free" channels to the EDMA infrastructure.

IMCOP and similar codec drivers would of course need to
claim the channels they need; same deal.

That would maximize the number of channels available for
dynamic use by triggering and chaining.

- Dave


> > So if for example the UART driver doesn't use EDMA the UART
> > channels could be candidates ... as could GPIO banks in most
> > cases, and "direct" GPIOs on a more board-specific basis.
> [Sandeep] that's correct
> > 
> > - Dave
> > 
> 
> 



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

RE: Problem with the current EDMA driver in the DaVinci GIT kernel

2009-08-26 Thread Paulraj, Sandeep 


> Fine, but from what you said, their stuff basically does
> not work today.  So there's nothing to reuse.
[Sandeep] they can re use quite a lot. The APIs need to be changed and they 
have to take care of the fact that the way we acquire TCC's has chnaged
> 
> 
> > If features need to be added it has to be in the EDMA kernel driver
> 
> And "adding" features means working with that team so
> everyone agrees on the interface.
> 
> 
> > > > In DM355 very few channels can be acquired using the
> EDMA_CHANNEL_ANY
> > > > and in DM365 0 channels can be acquired with this option.
> > >
> > > Right; there are only so many EDMA channels that aren't wired up to
> any
> > > hardware, and that's what CHANNEL_ANY provides.
> >
> > [Sandeep] NO. I know for DM355 you are referring to pages 36-37 in
> > http://focus.ti.com/lit/ug/spruee4a/spruee4a.pdf
> >
> > which says that channels 12, 13, 24, 56-63 are "reserved".
> > These do have hardware events associated with them and are
> > used by the IMCOP in DM355.
> 
> Sounds like a doc bug to me. 
[Sandeep] that's true
> It should at least say which
> channels are used by IMCOP, vs which are free for use by
> software triggering (or chaining), vs being e.g. broken.
[Sandeep] all 64 channels are available for either hardware events or for us by 
software triggering

> 
> 
> > So the name "dma_chan_dm355_no_event" which suggest that
> > there is no hardware event associated with the channels
> > (in that structure) is not true.
> 
> It's as accurate as possible given that doc bug...
[Sandeep] that's also true
> 
> 
> > Maybe just add a comment what we are trying to achieve
> > should serve the purpose.
> 
> There already *is* a description of what CHANNEL_ANY
> is supposed to deliver... if you're going to redefine
> those semantics, do it properly.  My default assumption
> is, FWIW, that new semantics need a new EDMA_CHANNEL_*
> symbol.  In this case one might argue that we don't
> want the old semantics, just the new ones.  Which
> still requires updating the interface spec.
[Sandeep] I can replace the EDMA_CHANNEL_ANY with EDMA_CHANNEL_HW_UNUSED. IMHO 
there is no point having another option especially since they will do exactly 
the same thing, i.e try to acquire channels that are not being used by the 
kernel drivers. WE can have one of the 2 mentioned but not both.
> 
> 
> > > What's unclear is just why you chose those numbers.  I suspect
> > > the issue is that you just want to avoid channels which are
> > > (a) used by Linux drivers, and (b) the board uses the relevant
> > > driver.
> > [Sandeep] yes
> >   Suggesting a name like EDMA_CHANNEL_HW_UNUSED.
> > [Sandeep] I don't think this is needed
> 
> Maybe not.  If all devices associated with DMA drivers can
> be relied on to (i) register by a certain point in the init
> sequence, and (ii) properly list the DMA channels they use
> in their platform resources, then it's obviously possible
> to construct a set of all DMA channels "potentially in use"
> by drivers on that particular board.
[Sandeep] this can also be achieved by updating the structure appropriately as 
I have done in the patches whose links I had given earlier
> 
> And the list of channels available for use with software
> triggering, or chaining, or whatever this LinuxUtils thing
> is ... would be the inverse of that set.  At that point
> in the init sequence -- and before drivers are expected
> to make CHANNEL_ allocations -- feed the set
> of "free" channels to the EDMA infrastructure.
> 
> IMCOP and similar codec drivers would of course need to
> claim the channels they need; same deal.
[Sandeep] how the IMCOP deals with its channels is handled by other components 
of the DVSDK. I am not sure of how exactly it is handled and I don't even know 
if the IMCOP actually used hardware triggering.
> 
> That would maximize the number of channels available for
> dynamic use by triggering and chaining.
[Sandeep] basically the objective is to atleast allow all channels not being 
used by the kernel to be acquired by the linuxutils/DVSDK. How they then use 
these channels is the responsibility of these other components.
> 
> - Dave
> 
> 
> > > So if for example the UART driver doesn't use EDMA the UART
> > > channels could be candidates ... as could GPIO banks in most
> > > cases, and "direct" GPIOs on a more board-specific basis.
> > [Sandeep] that's correct
> > >
> > > - Dave
> > >
> >
> >
> 
> 
- Sandeep

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

Re: Problem with the current EDMA driver in the DaVinci GIT kernel

2009-08-26 Thread David Brownell 
On Wednesday 26 August 2009, Paulraj, Sandeep wrote:
> 
> > > > What's unclear is just why you chose those numbers.  I suspect
> > > > the issue is that you just want to avoid channels which are
> > > > (a) used by Linux drivers, and (b) the board uses the relevant
> > > > driver.
> > > [Sandeep] yes
> > >   Suggesting a name like EDMA_CHANNEL_HW_UNUSED.
> > > [Sandeep] I don't think this is needed
> > 
> > Maybe not.  If all devices associated with DMA drivers can
> > be relied on to (i) register by a certain point in the init
> > sequence, and (ii) properly list the DMA channels they use
> > in their platform resources, then it's obviously possible
> > to construct a set of all DMA channels "potentially in use"
> > by drivers on that particular board.
>
> [Sandeep] this can also be achieved by updating the structure
> appropriately as I have done in the patches whose links I had given earlier 

No; that's not maintainable.  Each time a new driver starts
to use a channel, someone has to remember to update that
table.  That's why it's just a hack.  People WILL forget
to update that stuff, and then things WILL break.

Plus, notice that your static updates won't accomodate
board-specific differences either ... like a board not
using one peripheral, and thereby making its DMA channels
available for other use.

 
> > And the list of channels available for use with software
> > triggering, or chaining, or whatever this LinuxUtils thing
> > is ... would be the inverse of that set.  At that point
> > in the init sequence -- and before drivers are expected
> > to make CHANNEL_ allocations -- feed the set
> > of "free" channels to the EDMA infrastructure.
> > 
> > IMCOP and similar codec drivers would of course need to
> > claim the channels they need; same deal.
>
> [Sandeep] how the IMCOP deals with its channels is handled
> by other components of the DVSDK. I am not sure of how exactly
> it is handled and I don't even know if the IMCOP actually used
> hardware triggering.   

If those components don't say that they use those DMA channels,
then something other than IMCOP will be able to allocate them...
trouble.  So you'd better *find out* how it allocates those
resources, if you're trying to redefine the semantics of
the mechanism you identified.  Or at least, you need to make
sure they use the right allocation scheme.


> > That would maximize the number of channels available for
> > dynamic use by triggering and chaining.
>
> [Sandeep] basically the objective is to atleast allow all
> channels not being used by the kernel to be acquired by the
> linuxutils/DVSDK. How they then use these channels is the
> responsibility of these other components.   

If they want a channel they need to use the allocation calls.

The "how they use them" is irrelevant ... but if as you said
some of them (IMCOP etc) need *specific* channels, usually
because they're hard-wired to some peripheral but maybe just
because some firmware doesn't understand dynamic allocation,
it's got to request those specific channels.

The reason to use CHANNEL_ANY is because you don't have a
requirement for a specific channel.

- Dave



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

Re: Problem with USB host mode + audio on DM6446

2009-08-26 Thread Sergei Shtylyov 

Hello.

Brian Rhodes wrote:

I just got my audio working this evening with a TLV320DAC32 DAC on a 
near-copy of the DM6446 EVM board (we use the TLV320DAC32 instead of 
the TLV320AIC33 and drop the I2C port expanders).  I've had USB host 
mode working for a while, but now when I try to use audio after 
mounting a flash disk, or mount a flashdisk after using audio, I'm 
getting various errors as shown below.


I thought I read a post here somewhere about a problem along these 
lines, but I can't seem to find it in the archives.  Is this anything 
new?  This is 2.6.31-rc7.  CPPI DMA is enabled.


  I constantly see alike messages when running USB test #12 (testusb.c 
can be found at http://www.linux-usb.org/usbtest/).


We recently had this problem with one of our boards, but it appears to 
have been completely a circuitry issue, though the driver may also 
have a couple issues when there are some problems with the signals.  
The board layout had some issues where the impedance was not being 
maintained properly either because of distance between traces, or 
switching layers on the board.  I believe the major problem was a 
couple of right angle turns in the traces which were causing signal 
reflection.  I have not heard that it was reproduced since our layout 
issues were fixed.


I think the impedance between the differential pairs should be 90 
ohms.  We had one spot where that was not maintained to avoid a 
through hole and a couple right angles in the traces close to the 
connector.


  That's interesting point...

The git kernel version which I was using was 2.6.30-rc7.  I was 
thinking perhaps musb_h_tx_flush_fifo should simply clear 
MUSB_TXCSR_FLUSHFIFO from MUSB_TXCSR if it failed


 This bit is self-clearing, and the register readback show it as 
cleared, so there's no point.



so that at least USB could become usable again.


  It is usable regardless.

  Trying to recreate it just now is not proving easy.  Even before it 
was a fairly rare occurrence.


  Try to use the aforementioned test suite...


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


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

Re: Problem with USB host mode + audio on DM6446

2009-08-26 Thread Brian Rhodes 

J.C. Wren wrote:
I just got my audio working this evening with a TLV320DAC32 DAC on a 
near-copy of the DM6446 EVM board (we use the TLV320DAC32 instead of 
the TLV320AIC33 and drop the I2C port expanders).  I've had USB host 
mode working for a while, but now when I try to use audio after 
mounting a flash disk, or mount a flashdisk after using audio, I'm 
getting various errors as shown below.


I thought I read a post here somewhere about a problem along these 
lines, but I can't seem to find it in the archives.  Is this anything 
new?  This is 2.6.31-rc7.  CPPI DMA is enabled. 



We recently had this problem with one of our boards, but it appears to 
have been completely a circuitry issue, though the driver may also have 
a couple issues when there are some problems with the signals.  The 
board layout had some issues where the impedance was not being 
maintained properly either because of distance between traces, or 
switching layers on the board.  I believe the major problem was a couple 
of right angle turns in the traces which were causing signal 
reflection.  I have not heard that it was reproduced since our layout 
issues were fixed.


I think the impedance between the differential pairs should be 90 ohms.  
We had one spot where that was not maintained to avoid a through hole 
and a couple right angles in the traces close to the connector.


The git kernel version which I was using was 2.6.30-rc7.  I was thinking 
perhaps musb_h_tx_flush_fifo should simply clear MUSB_TXCSR_FLUSHFIFO 
from MUSB_TXCSR if it failed so that at least USB could become usable 
again.  Trying to recreate it just now is not proving easy.  Even before 
it was a fairly rare occurrence.


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

Re: Problem with USB host mode + audio on DM6446

2009-08-26 Thread J.C. Wren 
Replies inline.

On Wed, Aug 26, 2009 at 3:59 PM, Sergei Shtylyov wrote:

> Hello.
>
> Brian Rhodes wrote:
>
>  I just got my audio working this evening with a TLV320DAC32 DAC on a
>>> near-copy of the DM6446 EVM board (we use the TLV320DAC32 instead of the
>>> TLV320AIC33 and drop the I2C port expanders).  I've had USB host mode
>>> working for a while, but now when I try to use audio after mounting a flash
>>> disk, or mount a flashdisk after using audio, I'm getting various errors as
>>> shown below.
>>>
>>> I thought I read a post here somewhere about a problem along these lines,
>>> but I can't seem to find it in the archives.  Is this anything new?  This is
>>> 2.6.31-rc7.  CPPI DMA is enabled.
>>>
>>
>  I constantly see alike messages when running USB test #12 (testusb.c can
> be found at http://www.linux-usb.org/usbtest/).
>
>  We recently had this problem with one of our boards, but it appears to
>> have been completely a circuitry issue, though the driver may also have a
>> couple issues when there are some problems with the signals.  The board
>> layout had some issues where the impedance was not being maintained properly
>> either because of distance between traces, or switching layers on the board.
>>  I believe the major problem was a couple of right angle turns in the traces
>> which were causing signal reflection.  I have not heard that it was
>> reproduced since our layout issues were fixed.
>>
>> I think the impedance between the differential pairs should be 90 ohms.
>>  We had one spot where that was not maintained to avoid a through hole and a
>> couple right angles in the traces close to the connector.
>>
>
>  That's interesting point...


I know the engineer spent a lot of time checking impedances and such.  I
know most of the clocks are modeled down to around 10 picoseconds.
Obsessive-compulsive as a description comes to mind.

I will load this on the Davinci DVEVM board and check for it also.  If it
occurs on that board also, I'd be more inclined to say it's a software
issue.  USB is touchy, but not THAT touchy.  I've run USB 2.0 at full speed
over a few inches of wire-wrap wire with success.  And I can reproduce this
problem every time.

>
>
>  The git kernel version which I was using was 2.6.30-rc7.  I was thinking
>> perhaps musb_h_tx_flush_fifo should simply clear MUSB_TXCSR_FLUSHFIFO from
>> MUSB_TXCSR if it failed
>>
>
>  This bit is self-clearing, and the register readback show it as cleared,
> so there's no point.
>
>  so that at least USB could become usable again.
>>
>
>  It is usable regardless.


I'm not what "usable" means, as it seems to take at least a few minutes to
recover.

>
>
>   Trying to recreate it just now is not proving easy.  Even before it was a
>> fairly rare occurrence.
>>
>
>  Try to use the aforementioned test suite...
>
>  ___
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source@linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>
>
> 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 v2 2/6] DaVinci: DM355: Updates for SPI for DM355 SOC

2009-08-26 Thread s-paulraj 
From: Sandeep Paulraj 

this patch does the following
1) minor update to the clocks for SPI
2) Adds platform data for DM355 SPI0

Signed-off-by: Sandeep Paulraj 
---
 arch/arm/mach-davinci/dm355.c |   20 
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 4f42169..3eaf2c0 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-
 #include 
 
 #include 
@@ -31,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "clock.h"
 #include "mux.h"
@@ -365,9 +365,9 @@ static struct davinci_clk dm355_clks[] = {
CLK("davinci-asp.1", NULL, &asp1_clk),
CLK("davinci_mmc.0", NULL, &mmcsd0_clk),
CLK("davinci_mmc.1", NULL, &mmcsd1_clk),
-   CLK(NULL, "spi0", &spi0_clk),
-   CLK(NULL, "spi1", &spi1_clk),
-   CLK(NULL, "spi2", &spi2_clk),
+   CLK("spi_davinci.0", NULL, &spi0_clk),
+   CLK("spi_davinci.1", NULL, &spi1_clk),
+   CLK("spi_davinci.2", NULL, &spi2_clk),
CLK(NULL, "gpio", &gpio_clk),
CLK(NULL, "aemif", &aemif_clk),
CLK(NULL, "pwm0", &pwm0_clk),
@@ -406,12 +406,24 @@ static struct resource dm355_spi0_resources[] = {
 */
 };
 
+static struct davinci_spi_platform_data dm355_spi0_pdata = {
+   .version= SPI_VERSION_1,
+   .num_chipselect = 2,
+   .clk_internal   = 1,
+   .cs_hold= 1,
+   .intr_level = 0,
+   .poll_mode  = 1,
+   .c2tdelay   = 8,
+   .t2cdelay   = 8,
+};
+
 static struct platform_device dm355_spi0_device = {
.name = "spi_davinci",
.id = 0,
.dev = {
.dma_mask = &dm355_spi0_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
+   .platform_data = &dm355_spi0_pdata,
},
.num_resources = ARRAY_SIZE(dm355_spi0_resources),
.resource = dm355_spi0_resources,
-- 
1.6.0.4

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

[PATCH v2 4/6] DaVinci: DM365: Adding SPI support in the DM365 EVM.

2009-08-26 Thread s-paulraj 
From: Sandeep Paulraj 

This patch enables SPI 0 and the DM365 EVM. SPI instance 0 is connected
to an ATMEL EEPROM on the DM365 EVM from Spectrum Digital.

Signed-off-by: Sandeep Paulraj 
---
 arch/arm/mach-davinci/board-dm365-evm.c |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index f6adf79..26fb6d6 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -24,6 +24,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -464,6 +467,24 @@ static void __init dm365_evm_map_io(void)
dm365_init();
 }
 
+static struct spi_eeprom at25640 = {
+   .byte_len   = SZ_64K / 8,
+   .name   = "at25640",
+   .page_size  = 32,
+   .flags  = EE_ADDR2,
+};
+
+static struct spi_board_info dm365_evm_spi_info[] __initconst = {
+   {
+   .modalias   = "at25",
+   .platform_data  = &at25640,
+   .max_speed_hz   = 10 * 1000 * 1000, /* at 3v3 */
+   .bus_num= 0,
+   .chip_select= 0,
+   .mode   = SPI_MODE_0,
+   },
+};
+
 static __init void dm365_evm_init(void)
 {
evm_init_i2c();
@@ -476,6 +497,9 @@ static __init void dm365_evm_init(void)
 
/* maybe setup mmc1/etc ... _after_ mmc0 */
evm_init_cpld();
+
+   dm365_init_spi0(BIT(0), dm365_evm_spi_info,
+   ARRAY_SIZE(dm365_evm_spi_info));
 }
 
 static __init void dm365_evm_irq_init(void)
-- 
1.6.0.4

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

[PATCH v2 3/6] DaVinci: DM365: Add SPI support in DM365 SOC

2009-08-26 Thread s-paulraj 
From: Sandeep Paulraj 

This patch adds SPI support in the DM365 SOC. The patch adds
platform data for DM365 SPI0 and the resources for
the DM365

Signed-off-by: Sandeep Paulraj 
---
 arch/arm/mach-davinci/dm365.c  |   58 
 arch/arm/mach-davinci/include/mach/dm365.h |3 +
 2 files changed, 61 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index e815174..5f17bf8 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -32,6 +33,8 @@
 #include 
 #include 
 #include 
+#include 
+
 
 #include "clock.h"
 #include "mux.h"
@@ -606,6 +609,61 @@ INT_CFG(DM365,  INT_NSF_DISABLE, 25,1,0, 
false)
 #endif
 };
 
+static u64 dm365_spi0_dma_mask = DMA_BIT_MASK(32);
+
+static struct davinci_spi_platform_data dm365_spi0_pdata = {
+   .version= SPI_VERSION_1,
+   .num_chipselect = 2,
+   .clk_internal   = 1,
+   .cs_hold= 1,
+   .intr_level = 0,
+   .poll_mode  = 1,
+   .c2tdelay   = 8,
+   .t2cdelay   = 8,
+};
+
+static struct resource dm365_spi0_resources[] = {
+   {
+   .start = 0x01c66000,
+   .end   = 0x01c667ff,
+   .flags = IORESOURCE_MEM,
+   },
+   {
+   .start = IRQ_DM365_SPIINT0_0,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+
+static struct platform_device dm365_spi0_device = {
+   .name = "spi_davinci",
+   .id = 0,
+   .dev = {
+   .dma_mask = &dm365_spi0_dma_mask,
+   .coherent_dma_mask = DMA_BIT_MASK(32),
+   .platform_data = &dm365_spi0_pdata,
+   },
+   .num_resources = ARRAY_SIZE(dm365_spi0_resources),
+   .resource = dm365_spi0_resources,
+};
+
+void __init dm365_init_spi0(unsigned chipselect_mask,
+   struct spi_board_info *info, unsigned len)
+{
+   davinci_cfg_reg(DM365_SPI0_SCLK);
+   davinci_cfg_reg(DM365_SPI0_SDI);
+   davinci_cfg_reg(DM365_SPI0_SDO);
+
+   /* not all slaves will be wired up */
+   if (chipselect_mask & BIT(0))
+   davinci_cfg_reg(DM365_SPI0_SDENA0);
+   if (chipselect_mask & BIT(1))
+   davinci_cfg_reg(DM365_SPI0_SDENA1);
+
+   spi_register_board_info(info, len);
+
+   platform_device_register(&dm365_spi0_device);
+}
+
 static struct emac_platform_data dm365_emac_pdata = {
.ctrl_reg_offset= DM365_EMAC_CNTRL_OFFSET,
.ctrl_mod_reg_offset= DM365_EMAC_CNTRL_MOD_OFFSET,
diff --git a/arch/arm/mach-davinci/include/mach/dm365.h 
b/arch/arm/mach-davinci/include/mach/dm365.h
index 09db434..61cfd30 100644
--- a/arch/arm/mach-davinci/include/mach/dm365.h
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -25,5 +25,8 @@
 #define DM365_EMAC_CNTRL_RAM_SIZE  (0x2000)
 
 void __init dm365_init(void);
+struct spi_board_info;
+void dm365_init_spi0(unsigned chipselect_mask,
+   struct spi_board_info *info, unsigned len);
 
 #endif /* __ASM_ARCH_DM365_H */
-- 
1.6.0.4

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

[PATCH v2 1/6] SPI:DaVinci: Adding SPI support for DaVinci/DA8xx

2009-08-26 Thread s-paulraj 
From: Sandeep Paulraj 

This patch adds initial SPI driver support for the DaVinci
series of SOC's.

Signed-off-by: Sandeep Paulraj 
---
Thanks to David Brownell for all his suggestions/ refinements which
we were in the form of patches.
This initial support does not have support for multiple chipselects nor
does it have EDMA support.
 arch/arm/mach-davinci/include/mach/spi.h |   45 ++
 drivers/spi/Kconfig  |7 +
 drivers/spi/Makefile |1 +
 drivers/spi/davinci_spi.c|  757 ++
 drivers/spi/davinci_spi.h|  163 +++
 5 files changed, 973 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-davinci/include/mach/spi.h
 create mode 100644 drivers/spi/davinci_spi.c
 create mode 100644 drivers/spi/davinci_spi.h

diff --git a/arch/arm/mach-davinci/include/mach/spi.h 
b/arch/arm/mach-davinci/include/mach/spi.h
new file mode 100644
index 000..ff021e5
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/spi.h
@@ -0,0 +1,45 @@
+/*
+ * Copyright 2009 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; 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __ARCH_ARM_DAVINCI_SPI_H
+#define __ARCH_ARM_DAVINCI_SPI_H
+
+#define SPI_INTERN_CS  0xFF
+
+enum {
+   SPI_VERSION_1, /* For DM355/DM365/DM6467*/
+   SPI_VERSION_2, /* For DA8xx */
+};
+
+struct davinci_spi_platform_data {
+   u8  version;
+   u16 num_chipselect;
+   u32 wdelay;
+   u32 odd_parity;
+   u32 parity_enable;
+   u32 wait_enable;
+   u32 timer_disable;
+   u32 clk_internal;
+   u32 cs_hold;
+   u32 intr_level;
+   u32 poll_mode;
+   u8  c2tdelay;
+   u8  t2cdelay;
+};
+
+#endif /* __ARCH_ARM_DAVINCI_SPI_H */
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 2c733c2..7fe9211 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -77,6 +77,13 @@ config SPI_AU1550
  This driver can also be built as a module.  If so, the module
  will be called au1550_spi.
 
+config SPI_DAVINCI
+   tristate "SPI controller driver for DaVinci/DA8xx SoC's"
+   depends on SPI_MASTER && ARCH_DAVINCI
+   select SPI_BITBANG
+   help
+ SPI master controller for DaVinci and DA8xx SPI modules.
+
 config SPI_BITBANG
tristate "Utilities for Bitbanging SPI masters"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 3de408d..910ac6d 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_SPI_S3C24XX) += spi_s3c24xx.o
 obj-$(CONFIG_SPI_TXX9) += spi_txx9.o
 obj-$(CONFIG_SPI_XILINX)   += xilinx_spi.o
 obj-$(CONFIG_SPI_SH_SCI)   += spi_sh_sci.o
+obj-$(CONFIG_SPI_DAVINCI)  += davinci_spi.o
 #  ... add above this line ...
 
 # SPI protocol drivers (device/link on bus)
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
new file mode 100644
index 000..4d84127
--- /dev/null
+++ b/drivers/spi/davinci_spi.c
@@ -0,0 +1,757 @@
+/*
+ * Copyright (C) 2009 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; 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 
+
+#include 
+
+#include "davinci_spi.h"
+
+
+static void davinci_spi_rx_buf_u8(u32 data, struct davinci_spi *davinci_spi)
+{
+   u8 *rx = davinci_spi->rx;
+
+   *rx++ = (u8)data;
+   davinci_spi->rx = rx;
+}
+
+static void davinci_spi_rx_buf_u16(u32 data, struct davinci_spi *davinci_spi)
+{
+   u16 *rx = davinci_

[PATCH v2 5/6] DaVinci: DM646x: Adding SPI support for DM646x SOC

2009-08-26 Thread s-paulraj 
From: Sandeep Paulraj 

This patch adds support for SPI in the DM646x SOC.

Signed-off-by: Sandeep Paulraj 
---
 arch/arm/mach-davinci/dm646x.c  |   53 +++
 arch/arm/mach-davinci/include/mach/dm646x.h |2 +
 2 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 0976049..571af13 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -28,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "clock.h"
 #include "mux.h"
@@ -262,6 +264,12 @@ static struct clk emac_clk = {
.lpsc = DM646X_LPSC_EMAC,
 };
 
+static struct clk spi0_clk = {
+   .name = "spi0",
+   .parent = &pll1_sysclk3,
+   .lpsc = DM646X_LPSC_SPI,
+};
+
 static struct clk pwm0_clk = {
.name = "pwm0",
.parent = &pll1_sysclk3,
@@ -347,6 +355,7 @@ struct davinci_clk dm646x_clks[] = {
CLK("davinci-mcasp.1", NULL, &mcasp1_clk),
CLK(NULL, "aemif", &aemif_clk),
CLK("davinci_emac.1", NULL, &emac_clk),
+   CLK("spi_davinci.0", NULL, &spi0_clk),
CLK(NULL, "pwm0", &pwm0_clk),
CLK(NULL, "pwm1", &pwm1_clk),
CLK(NULL, "timer0", &timer0_clk),
@@ -358,6 +367,50 @@ struct davinci_clk dm646x_clks[] = {
CLK(NULL, NULL, NULL),
 };
 
+static u64 dm646x_spi0_dma_mask = DMA_BIT_MASK(32);
+
+static struct davinci_spi_platform_data dm646x_spi0_pdata = {
+   .version= SPI_VERSION_1,
+   .num_chipselect = 2,
+   .clk_internal   = 1,
+   .cs_hold= 1,
+   .intr_level = 0,
+   .poll_mode  = 1,
+   .c2tdelay   = 8,
+   .t2cdelay   = 8,
+};
+
+static struct resource dm646x_spi0_resources[] = {
+   {
+   .start = 0x01c66800,
+   .end   = 0x01c66fff,
+   .flags = IORESOURCE_MEM,
+   },
+   {
+   .start = IRQ_DM646X_SPINT0,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+
+static struct platform_device dm646x_spi0_device = {
+   .name = "spi_davinci",
+   .id = 0,
+   .dev = {
+   .dma_mask = &dm646x_spi0_dma_mask,
+   .coherent_dma_mask = DMA_BIT_MASK(32),
+   .platform_data = &dm646x_spi0_pdata,
+   },
+   .num_resources = ARRAY_SIZE(dm646x_spi0_resources),
+   .resource = dm646x_spi0_resources,
+};
+
+void __init dm646x_init_spi0(struct spi_board_info *info, unsigned len)
+{
+   spi_register_board_info(info, len);
+
+   platform_device_register(&dm646x_spi0_device);
+}
+
 static struct emac_platform_data dm646x_emac_pdata = {
.ctrl_reg_offset= DM646X_EMAC_CNTRL_OFFSET,
.ctrl_mod_reg_offset= DM646X_EMAC_CNTRL_MOD_OFFSET,
diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h 
b/arch/arm/mach-davinci/include/mach/dm646x.h
index 8cec746..9b47256 100644
--- a/arch/arm/mach-davinci/include/mach/dm646x.h
+++ b/arch/arm/mach-davinci/include/mach/dm646x.h
@@ -30,6 +30,8 @@ void __init dm646x_init(void);
 void __init dm646x_init_ide(void);
 void __init dm646x_init_mcasp0(struct snd_platform_data *pdata);
 void __init dm646x_init_mcasp1(struct snd_platform_data *pdata);
+struct spi_board_info;
+void dm646x_init_spi0(struct spi_board_info *info, unsigned len);
 
 void dm646x_video_init(void);
 
-- 
1.6.0.4

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

[PATCH v2 6/6] DaVinci: DM646x: Adding support for SPI in DM646x EVM

2009-08-26 Thread s-paulraj 
From: Sandeep Paulraj 

This patch adds support for SPI 0 that is connected to
EEPROM on the DM646x EVM.

Signed-off-by: Sandeep Paulraj 
---
 arch/arm/mach-davinci/board-dm646x-evm.c |   23 +++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c 
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 434253e..0f99180 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -34,6 +34,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -636,6 +639,24 @@ static void __init davinci_map_io(void)
dm646x_init();
 }
 
+static struct spi_eeprom at25640a = {
+   .byte_len   = SZ_64K / 2,
+   .name   = "at25640a",
+   .page_size  = 64,
+   .flags  = EE_ADDR2,
+};
+
+static struct spi_board_info dm646x_evm_spi_info[] __initconst = {
+   {
+   .modalias   = "at25",
+   .platform_data  = &at25640a,
+   .max_speed_hz   = 10 * 1000 * 1000, /* at 3v3 */
+   .bus_num= 0,
+   .chip_select= 0,
+   .mode   = SPI_MODE_0,
+   },
+};
+
 static __init void evm_init(void)
 {
struct davinci_soc_info *soc_info = &davinci_soc_info;
@@ -651,6 +672,8 @@ static __init void evm_init(void)
soc_info->emac_pdata->phy_mask = DM646X_EVM_PHY_MASK;
soc_info->emac_pdata->mdio_max_freq = DM646X_EVM_MDIO_FREQUENCY;
evm_init_video();
+
+   dm646x_init_spi0(dm646x_evm_spi_info, ARRAY_SIZE(dm646x_evm_spi_info));
 }
 
 static __init void davinci_dm646x_evm_irq_init(void)
-- 
1.6.0.4

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

RE: Regarding dynamic memory allocation on DSP side of DM6446.

2009-08-26 Thread Ring, Chris 
Yes, BIOS, the OS on the DSP, provides a MEM_alloc() fxn.  See the BIOS docs 
for details.

(If you're an algorithm, and care about XDAIS compliancy, you get dynamic 
memory, but you only get one chance to ask for it... via memTabs during your 
alg initialization.)

Chris


From: davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com 
[mailto:davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com] On 
Behalf Of Sandeep YEDIRE
Sent: Wednesday, August 26, 2009 6:08 AM
To: davinci-linux-open-source@linux.davincidsp.com
Cc: Sandeep Yedire
Subject: Regarding dynamic memory allocation on DSP side of DM6446.


 Hello,
Can we allocate Dynamic memory on DSP side of DM6446?
Many Thanks,
Sandeep.Yedire





Looking for 24 hour chemists in your area? Try Yahoo! India 
Local
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: Problem with the current EDMA driver in the DaVinci GIT kernel

2009-08-26 Thread Tivy, Robert 
It seems that arriving at a consensus for reserved channels isn't going to be 
easy.

I'd like to suggest a scheme involving some sort of driver-controlled unlocking 
of reserved channels, intended to be used late in the EDMA acquisition 
timeline.  The LinuxUtils EDMA driver has a strong need for EDMA_ANY type of 
allocation, to support memory-to-memory transfers by codecs, mostly.  It could 
call a kernel API when it's first open()'ed, that tells the EDMA driver to 
transfer all unallocated reserved channels over to the EDMA_ANY bitmask.  Most 
EDMA allocations will have already happened at that point, and even if more 
fixed-channel request are coming, there's more than a small chance that it will 
still be available (not picked for an EDMA_ANY request).  There could be a 
"priority" to the EDMA_ANY acquisition, whereby certain reserved channels are 
deemed to be more or less likely to be requested later on, affecting how soon a 
channel is chosen for EDMA_ANY.

There could also be an API for a driver to request that a certain channel not 
be allowed to be transferred to the EDMA_ANY list, or some sort of a 
notification of future usage.

It would be nice to also solve the issue of "raw" EDMA usage through mmap()'ing 
the EDMA register set and directly writing registers.  Perhaps the /dev/mem 
driver can intercept these requests and somehow negotiate or control access to 
those registers (I'm just tossing this out there with not much idea of how to 
solve it).

Regards,

- Rob


From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com 
[davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com] On Behalf 
Of David Brownell [davi...@pacbell.net]
Sent: Wednesday, August 26, 2009 12:00 PM
To: Paulraj, Sandeep
Cc: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Problem with the current EDMA driver in the DaVinci GIT kernel

On Wednesday 26 August 2009, Paulraj, Sandeep wrote:
>
> > > > What's unclear is just why you chose those numbers.  I suspect
> > > > the issue is that you just want to avoid channels which are
> > > > (a) used by Linux drivers, and (b) the board uses the relevant
> > > > driver.
> > > [Sandeep] yes
> > >   Suggesting a name like EDMA_CHANNEL_HW_UNUSED.
> > > [Sandeep] I don't think this is needed
> >
> > Maybe not.  If all devices associated with DMA drivers can
> > be relied on to (i) register by a certain point in the init
> > sequence, and (ii) properly list the DMA channels they use
> > in their platform resources, then it's obviously possible
> > to construct a set of all DMA channels "potentially in use"
> > by drivers on that particular board.
>
> [Sandeep] this can also be achieved by updating the structure
> appropriately as I have done in the patches whose links I had given earlier

No; that's not maintainable.  Each time a new driver starts
to use a channel, someone has to remember to update that
table.  That's why it's just a hack.  People WILL forget
to update that stuff, and then things WILL break.

Plus, notice that your static updates won't accomodate
board-specific differences either ... like a board not
using one peripheral, and thereby making its DMA channels
available for other use.


> > And the list of channels available for use with software
> > triggering, or chaining, or whatever this LinuxUtils thing
> > is ... would be the inverse of that set.  At that point
> > in the init sequence -- and before drivers are expected
> > to make CHANNEL_ allocations -- feed the set
> > of "free" channels to the EDMA infrastructure.
> >
> > IMCOP and similar codec drivers would of course need to
> > claim the channels they need; same deal.
>
> [Sandeep] how the IMCOP deals with its channels is handled
> by other components of the DVSDK. I am not sure of how exactly
> it is handled and I don't even know if the IMCOP actually used
> hardware triggering.

If those components don't say that they use those DMA channels,
then something other than IMCOP will be able to allocate them...
trouble.  So you'd better *find out* how it allocates those
resources, if you're trying to redefine the semantics of
the mechanism you identified.  Or at least, you need to make
sure they use the right allocation scheme.


> > That would maximize the number of channels available for
> > dynamic use by triggering and chaining.
>
> [Sandeep] basically the objective is to atleast allow all
> channels not being used by the kernel to be acquired by the
> linuxutils/DVSDK. How they then use these channels is the
> responsibility of these other components.

If they want a channel they need to use the allocation calls.

The "how they use them" is irrelevant ... but if as you said
some of them (IMCOP etc) need *specific* channels, usually
because they're hard-wired to some peripheral but maybe just
because some firmware doesn't understand dynamic allocation,
it's got to request those specific channels.

The reason to use CHANNEL_ANY i

Re: Regarding dynamic memory allocation on DSP side of DM6446.

2009-08-26 Thread Yedire, Sandeep 
Thank you very much.
Regards,
Sandeep.Yedire

--



2009/8/27 Ring, Chris 

>  Yes, BIOS, the OS on the DSP, provides a MEM_alloc() fxn.  See the BIOS
> docs for details.
>
> (If you're an algorithm, and care about XDAIS compliancy, you get dynamic
> memory, but you only get one chance to ask for it... via memTabs during your
> alg initialization.)
>
> Chris
>
>  --
> *From:* davinci-linux-open-source-bounces+cring=ti.com@
> linux.davincidsp.com 
> [mailto:davinci-linux-open-source-bounces+cring
> =ti@linux.davincidsp.com] *On Behalf Of *Sandeep YEDIRE
> *Sent:* Wednesday, August 26, 2009 6:08 AM
> *To:* davinci-linux-open-source@linux.davincidsp.com
> *Cc:* Sandeep Yedire
> *Subject:* Regarding dynamic memory allocation on DSP side of DM6446.
>
>
>  Hello,
> Can we allocate Dynamic memory on DSP side of DM6446?
> Many Thanks,
> Sandeep.Yedire
>
>
>
> --
> Looking for 24 hour chemists in your area? Try Yahoo! India 
> Local
>
>
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

DHCP server in target filesystem

2009-08-26 Thread saravanan . s 

Hi,

I am using DM6467 target and our application sends the data through  
Gbit Ethernet interface to Windows PC. Right now we are using static  
IPs in target as well in PC. But we want to run DHCP server in target  
filesystem(ramdisk) and PC will act as a client to get one fixed IP  
and start the communication. Please could you share the information  
about configuring the DHCP server in target filesystem?


Thanks,
Saravanan S


This message was sent using IMP, the Internet Messaging Program.


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