[PATCH v8 1/9] davinci: EMAC support for Omapl138-Hawkboard

[PATCH v8 1/9] davinci: EMAC support for Omapl138-Hawkboard

[vm.rod25 at gmail.com]

From: Victor Rodriguez <victor.rodriguez@sasken.com>

This patch adds EMAC support for the Hawkboard-L138 system

Signed-off-by: Victor Rodriguez <victor.rodriguez@sasken.com>
Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
---
 arch/arm/mach-davinci/board-omapl138-hawk.c |   43 +++++++++++++++++++++++++++
 1 files changed, 43 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index c472dd8..62d35f0 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -19,6 +19,47 @@
 
 #include <mach/cp_intc.h>
 #include <mach/da8xx.h>
+#include <mach/mux.h>
+
+#define HAWKBOARD_PHY_ID		"0:07"
+
+static short omapl138_hawk_mii_pins[] __initdata = {
+	DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
+	DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
+	DA850_MII_CRS, DA850_MII_RXCLK, DA850_MII_RXDV, DA850_MII_RXD_3,
+	DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0, DA850_MDIO_CLK,
+	DA850_MDIO_D,
+	-1
+};
+
+static __init void omapl138_hawk_config_emac(void)
+{
+	void __iomem *cfgchip3 = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
+	int ret;
+	u32 val;
+	struct davinci_soc_info *soc_info = &davinci_soc_info;
+
+	val = __raw_readl(cfgchip3);
+	val &= ~BIT(8);
+	ret = davinci_cfg_reg_list(omapl138_hawk_mii_pins);
+	if (ret) {
+		pr_warning("%s: cpgmac/mii mux setup failed: %d\n",
+			__func__, ret);
+		return;
+	}
+
+	/* configure the CFGCHIP3 register for MII */
+	__raw_writel(val, cfgchip3);
+	pr_info("EMAC: MII PHY configured\n");
+
+	soc_info->emac_pdata->phy_id = HAWKBOARD_PHY_ID;
+
+	ret = da8xx_register_emac();
+	if (ret)
+		pr_warning("%s: emac registration failed: %d\n",
+			__func__, ret);
+}
+
 
 static struct davinci_uart_config omapl138_hawk_uart_config __initdata = {
 	.enabled_uarts = 0x7,
@@ -30,6 +71,8 @@ static __init void omapl138_hawk_init(void)
 
 	davinci_serial_init(&omapl138_hawk_uart_config);
 
+	omapl138_hawk_config_emac();
+
 	ret = da8xx_register_watchdog();
 	if (ret)
 		pr_warning("omapl138_hawk_init: "
-- 
1.7.0.4

[PATCH v8 2/9] davinci: EDMA support for Omapl138-Hawkboard

[vm.rod25 at gmail.com]

From: Victor Rodriguez <victor.rodriguez@sasken.com>

This patch adds EDMA support for the Hawkboard-L138 system

Signed-off-by: Victor Rodriguez <victor.rodriguez@sasken.com>
Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
---
 arch/arm/mach-davinci/board-omapl138-hawk.c |   54 +++++++++++++++++++++++++++
 1 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 62d35f0..114fc9b 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -60,6 +60,55 @@ static __init void omapl138_hawk_config_emac(void)
 			__func__, ret);
 }
 
+/*
+ * The following EDMA channels/slots are not being used by drivers (for
+ * example: Timer, GPIO, UART events etc) on da850/omap-l138 EVM/Hawkboard,
+ * hence they are being reserved for codecs on the DSP side.
+ */
+static const s16 da850_dma0_rsv_chans[][2] = {
+	/* (offset, number) */
+	{ 8,  6},
+	{24,  4},
+	{30,  2},
+	{-1, -1}
+};
+
+static const s16 da850_dma0_rsv_slots[][2] = {
+	/* (offset, number) */
+	{ 8,  6},
+	{24,  4},
+	{30, 50},
+	{-1, -1}
+};
+
+static const s16 da850_dma1_rsv_chans[][2] = {
+	/* (offset, number) */
+	{ 0, 28},
+	{30,  2},
+	{-1, -1}
+};
+
+static const s16 da850_dma1_rsv_slots[][2] = {
+	/* (offset, number) */
+	{ 0, 28},
+	{30, 90},
+	{-1, -1}
+};
+
+static struct edma_rsv_info da850_edma_cc0_rsv = {
+	.rsv_chans	= da850_dma0_rsv_chans,
+	.rsv_slots	= da850_dma0_rsv_slots,
+};
+
+static struct edma_rsv_info da850_edma_cc1_rsv = {
+	.rsv_chans	= da850_dma1_rsv_chans,
+	.rsv_slots	= da850_dma1_rsv_slots,
+};
+
+static struct edma_rsv_info *da850_edma_rsv[2] = {
+	&da850_edma_cc0_rsv,
+	&da850_edma_cc1_rsv,
+};
 
 static struct davinci_uart_config omapl138_hawk_uart_config __initdata = {
 	.enabled_uarts = 0x7,
@@ -73,6 +122,11 @@ static __init void omapl138_hawk_init(void)
 
 	omapl138_hawk_config_emac();
 
+	ret = da850_register_edma(da850_edma_rsv);
+	if (ret)
+		pr_warning("%s: EDMA registration failed: %d\n",
+			__func__, ret);
+
 	ret = da8xx_register_watchdog();
 	if (ret)
 		pr_warning("omapl138_hawk_init: "
-- 
1.7.0.4

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[vm.rod25 at gmail.com]

From: Victor Rodriguez <victor.rodriguez@sasken.com>

This patch defines Pin Mux configuration for MacASP
used on the Hawkboard-L138 system in order to add Audio support

Signed-off-by: Victor Rodriguez <victor.rodriguez@sasken.com>
Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
---
 arch/arm/mach-davinci/da850.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 63916b9..f033a0a 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -591,7 +591,7 @@ const short da850_cpgmac_pins[] __initdata = {
 const short da850_mcasp_pins[] __initdata = {
 	DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
 	DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
-	DA850_AXR_11, DA850_AXR_12,
+	DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,
 	-1
 };
 
-- 
1.7.0.4

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Nori, Sekhar]

Hi Victor,

On Sat, Nov 13, 2010 at 04:08:50, vm.rod25 at gmail.com wrote:
> From: Victor Rodriguez <victor.rodriguez@sasken.com>
>
> This patch defines Pin Mux configuration for MacASP
> used on the Hawkboard-L138 system in order to add Audio support
>
> Signed-off-by: Victor Rodriguez <victor.rodriguez@sasken.com>
> Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
> ---
>  arch/arm/mach-davinci/da850.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 63916b9..f033a0a 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -591,7 +591,7 @@ const short da850_cpgmac_pins[] __initdata = {
>  const short da850_mcasp_pins[] __initdata = {
>       DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
>       DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
> -     DA850_AXR_11, DA850_AXR_12,
> +     DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,

Looks like I missed pointing this out previously, but extending
this list to take care of all boards will not be right since
(for example) AXR13 and AXR14 pins could be used for different
purpose on different boards.

The right way would be to make this a per-board list. Since it
is marked __initdata, that wouldn't lead to bloat.

Thanks,
Sekhar

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Sergei Shtylyov]

On 15.11.2010 14:10, Nori, Sekhar wrote:

>> This patch defines Pin Mux configuration for MacASP
>> used on the Hawkboard-L138 system in order to add Audio support

>> Signed-off-by: Victor Rodriguez<victor.rodriguez@sasken.com>
>> Tested-by: Rene Gonzalez<renegs.2378@gmail.com>

>> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
>> index 63916b9..f033a0a 100644
>> --- a/arch/arm/mach-davinci/da850.c
>> +++ b/arch/arm/mach-davinci/da850.c
>> @@ -591,7 +591,7 @@ const short da850_cpgmac_pins[] __initdata = {
>>   const short da850_mcasp_pins[] __initdata = {
>>        DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
>>        DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
>> -     DA850_AXR_11, DA850_AXR_12,
>> +     DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,

> Looks like I missed pointing this out previously, but extending
> this list to take care of all boards will not be right since
> (for example) AXR13 and AXR14 pins could be used for different
> purpose on different boards.

    This is correct as the list in da850.c is a *generic* module's pin list. 
If the board needs less pins (and the pins it does not use for McASP are used 
differently), it should define its own pin list.

> The right way would be to make this a per-board list. Since it
> is marked __initdata, that wouldn't lead to bloat.

    This patch is correct anyway. Unless DA850 EVM board can't use these pins 
for McASP -- but in this case the corresponding board file needs the specific 
pin list added.

> Thanks,
> Sekhar

WBR, Sergei

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Nori, Sekhar]

Hi Sergei,

On Mon, Nov 15, 2010 at 17:46:46, Sergei Shtylyov wrote:
> On 15.11.2010 14:10, Nori, Sekhar wrote:
>
> >> This patch defines Pin Mux configuration for MacASP
> >> used on the Hawkboard-L138 system in order to add Audio support
>
> >> Signed-off-by: Victor Rodriguez<victor.rodriguez@sasken.com>
> >> Tested-by: Rene Gonzalez<renegs.2378@gmail.com>
>
> >> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> >> index 63916b9..f033a0a 100644
> >> --- a/arch/arm/mach-davinci/da850.c
> >> +++ b/arch/arm/mach-davinci/da850.c
> >> @@ -591,7 +591,7 @@ const short da850_cpgmac_pins[] __initdata = {
> >>   const short da850_mcasp_pins[] __initdata = {
> >>        DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
> >>        DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
> >> -     DA850_AXR_11, DA850_AXR_12,
> >> +     DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,
>
> > Looks like I missed pointing this out previously, but extending
> > this list to take care of all boards will not be right since
> > (for example) AXR13 and AXR14 pins could be used for different
> > purpose on different boards.
>
>     This is correct as the list in da850.c is a *generic* module's pin list.
> If the board needs less pins (and the pins it does not use for McASP are used
> differently), it should define its own pin list.
>
> > The right way would be to make this a per-board list. Since it
> > is marked __initdata, that wouldn't lead to bloat.
>
>     This patch is correct anyway. Unless DA850 EVM board can't use these pins
> for McASP -- but in this case the corresponding board file needs the specific
> pin list added.

Okay. I guess you are saying we will keep adding pins to the generic list
as long as *all* supported boards don't get a conflict and if we run into
a conflict we will spawn separate list for the affected board.

The only issue I see with this approach is it puts too much burden on the
developer to verify that none of the supported boards break.

Since it is highly unlikely that any board will need all the McASP pins,
the generic list will likely remain unused. It might just be easier to
start using board specific lists right away. This is especially true for
McASP where usage of pins across boards will likely vary widely.

Thanks,
Sekhar

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Victor Rodriguez]

On Mon, Nov 15, 2010 at 7:07 AM, Nori, Sekhar <nsekhar@ti.com> wrote:
> Hi Sergei,
>
> On Mon, Nov 15, 2010 at 17:46:46, Sergei Shtylyov wrote:
>> On 15.11.2010 14:10, Nori, Sekhar wrote:
>>
>> >> This patch defines Pin Mux configuration for MacASP
>> >> used on the Hawkboard-L138 system in order to add Audio support
>>
>> >> Signed-off-by: Victor Rodriguez<victor.rodriguez@sasken.com>
>> >> Tested-by: Rene Gonzalez<renegs.2378@gmail.com>
>>
>> >> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
>> >> index 63916b9..f033a0a 100644
>> >> --- a/arch/arm/mach-davinci/da850.c
>> >> +++ b/arch/arm/mach-davinci/da850.c
>> >> @@ -591,7 +591,7 @@ const short da850_cpgmac_pins[] __initdata = {
>> >> ? const short da850_mcasp_pins[] __initdata = {
>> >> ? ? ? ?DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
>> >> ? ? ? ?DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
>> >> - ? ? DA850_AXR_11, DA850_AXR_12,
>> >> + ? ? DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,
>>
>> > Looks like I missed pointing this out previously, but extending
>> > this list to take care of all boards will not be right since
>> > (for example) AXR13 and AXR14 pins could be used for different
>> > purpose on different boards.
>>
>> ? ? This is correct as the list in da850.c is a *generic* module's pin list.
>> If the board needs less pins (and the pins it does not use for McASP are used
>> differently), it should define its own pin list.
>>
>> > The right way would be to make this a per-board list. Since it
>> > is marked __initdata, that wouldn't lead to bloat.
>>
>> ? ? This patch is correct anyway. Unless DA850 EVM board can't use these pins
>> for McASP -- but in this case the corresponding board file needs the specific
>> pin list added.
>
> Okay. I guess you are saying we will keep adding pins to the generic list
> as long as *all* supported boards don't get a conflict and if we run into
> a conflict we will spawn separate list for the affected board.
>
> The only issue I see with this approach is it puts too much burden on the
> developer to verify that none of the supported boards break.
>
> Since it is highly unlikely that any board will need all the McASP pins,
> the generic list will likely remain unused. It might just be easier to
> start using board specific lists right away. This is especially true for
> McASP where usage of pins across boards will likely vary widely.
>
> Thanks,
> Sekhar
>
>
Hi All

Please confirme me if the path is rigth or if I should make a McASP
list for the board.

Regards

Victor Rodriguez

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Sergei Shtylyov]

Hello.

Nori, Sekhar wrote:

>>>> This patch defines Pin Mux configuration for MacASP
>>>> used on the Hawkboard-L138 system in order to add Audio support
>>>> Signed-off-by: Victor Rodriguez<victor.rodriguez@sasken.com>
>>>> Tested-by: Rene Gonzalez<renegs.2378@gmail.com>
>>>> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
>>>> index 63916b9..f033a0a 100644
>>>> --- a/arch/arm/mach-davinci/da850.c
>>>> +++ b/arch/arm/mach-davinci/da850.c
>>>> @@ -591,7 +591,7 @@ const short da850_cpgmac_pins[] __initdata = {
>>>>   const short da850_mcasp_pins[] __initdata = {
>>>>        DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
>>>>        DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
>>>> -     DA850_AXR_11, DA850_AXR_12,
>>>> +     DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,

>>> Looks like I missed pointing this out previously, but extending
>>> this list to take care of all boards will not be right since
>>> (for example) AXR13 and AXR14 pins could be used for different
>>> purpose on different boards.

>>     This is correct as the list in da850.c is a *generic* module's pin list.
>> If the board needs less pins (and the pins it does not use for McASP are used
>> differently), it should define its own pin list.

>>> The right way would be to make this a per-board list. Since it
>>> is marked __initdata, that wouldn't lead to bloat.

>>     This patch is correct anyway. Unless DA850 EVM board can't use these pins
>> for McASP -- but in this case the corresponding board file needs the specific
>> pin list added.

> Okay. I guess you are saying we will keep adding pins to the generic list
> as long as *all* supported boards don't get a conflict

    No, I don't care about conflicts as long as da850.c is concerned.

> and if we run into
> a conflict we will spawn separate list for the affected board.

    Yes.

> The only issue I see with this approach is it puts too much burden on the
> developer to verify that none of the supported boards break.

    That should be verified by the owners of that board. They shouldn't even 
have used the generic pin lists in the first place. The conception behind pin 
lists in da850.c was celarly misunderstood when DA850 EVM code was developed.

> Since it is highly unlikely that any board will need all the McASP pins,
> the generic list will likely remain unused.

    At least for now, Hawkboard will use all the defined pins -- I don't know if 
there are any more undefined yet...

> It might just be easier to
> start using board specific lists right away. This is especially true for
> McASP where usage of pins across boards will likely vary widely.

    Well, that depends on how complete the new generic McASP pin list is. If 
it's still not, then board specific pin list looks preferable indeed...

> Thanks,
> Sekhar

WBR, Sergei

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Victor Rodriguez]

On Mon, Nov 15, 2010 at 9:47 AM, Sergei Shtylyov <sshtylyov@mvista.com> wrote:
> Hello.
>
> Nori, Sekhar wrote:
>
>>>>> This patch defines Pin Mux configuration for MacASP
>>>>> used on the Hawkboard-L138 system in order to add Audio support
>>>>> Signed-off-by: Victor Rodriguez<victor.rodriguez@sasken.com>
>>>>> Tested-by: Rene Gonzalez<renegs.2378@gmail.com>
>>>>> diff --git a/arch/arm/mach-davinci/da850.c
>>>>> b/arch/arm/mach-davinci/da850.c
>>>>> index 63916b9..f033a0a 100644
>>>>> --- a/arch/arm/mach-davinci/da850.c
>>>>> +++ b/arch/arm/mach-davinci/da850.c
>>>>> @@ -591,7 +591,7 @@ const short da850_cpgmac_pins[] __initdata = {
>>>>> ?const short da850_mcasp_pins[] __initdata = {
>>>>> ? ? ? DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
>>>>> ? ? ? DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
>>>>> - ? ? DA850_AXR_11, DA850_AXR_12,
>>>>> + ? ? DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,
>
>>>> Looks like I missed pointing this out previously, but extending
>>>> this list to take care of all boards will not be right since
>>>> (for example) AXR13 and AXR14 pins could be used for different
>>>> purpose on different boards.
>
>>> ? ?This is correct as the list in da850.c is a *generic* module's pin
>>> list.
>>> If the board needs less pins (and the pins it does not use for McASP are
>>> used
>>> differently), it should define its own pin list.
>
>>>> The right way would be to make this a per-board list. Since it
>>>> is marked __initdata, that wouldn't lead to bloat.
>
>>> ? ?This patch is correct anyway. Unless DA850 EVM board can't use these
>>> pins
>>> for McASP -- but in this case the corresponding board file needs the
>>> specific
>>> pin list added.
>
>> Okay. I guess you are saying we will keep adding pins to the generic list
>> as long as *all* supported boards don't get a conflict
>
> ? No, I don't care about conflicts as long as da850.c is concerned.
>
>> and if we run into
>> a conflict we will spawn separate list for the affected board.
>
> ? Yes.
>
>> The only issue I see with this approach is it puts too much burden on the
>> developer to verify that none of the supported boards break.
>
> ? That should be verified by the owners of that board. They shouldn't even
> have used the generic pin lists in the first place. The conception behind
> pin lists in da850.c was celarly misunderstood when DA850 EVM code was
> developed.
>
>> Since it is highly unlikely that any board will need all the McASP pins,
>> the generic list will likely remain unused.
>
> ? At least for now, Hawkboard will use all the defined pins -- I don't know
> if there are any more undefined yet...
>
>> It might just be easier to
>> start using board specific lists right away. This is especially true for
>> McASP where usage of pins across boards will likely vary widely.
>
> ? Well, that depends on how complete the new generic McASP pin list is. If
> it's still not, then board specific pin list looks preferable indeed...
>
>> Thanks,
>> Sekhar
>
> WBR, Sergei
>

HI Sergei and Sekhar

Thanks for check the patch

What I can do if you agree with this change is to leave da850.c as it
is, and declare

static short hawk_mcasp_pins[] __initdata = {
	DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
	DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
	DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,
	-1
};

on the hawkboard file and call it insted of da850_mcasp_pins.

	ret = davinci_cfg_reg_list(hawk_mcasp_pins);
	if (ret)
		pr_warning("%s: mcasp mux setup failed: %d\n", __func__, ret);

Please tell me if you agree with this change, I think is better
because I do not touch any other file besides my board file.

Thanks

Regards

Victor Rodriguez

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Sergei Shtylyov]

Hello.

Victor Rodriguez wrote:

>>>>>> This patch defines Pin Mux configuration for MacASP
>>>>>> used on the Hawkboard-L138 system in order to add Audio support

>>>>>> Signed-off-by: Victor Rodriguez<victor.rodriguez@sasken.com>
>>>>>> Tested-by: Rene Gonzalez<renegs.2378@gmail.com>

>>>>>> diff --git a/arch/arm/mach-davinci/da850.c
>>>>>> b/arch/arm/mach-davinci/da850.c
>>>>>> index 63916b9..f033a0a 100644
>>>>>> --- a/arch/arm/mach-davinci/da850.c
>>>>>> +++ b/arch/arm/mach-davinci/da850.c
>>>>>> @@ -591,7 +591,7 @@ const short da850_cpgmac_pins[] __initdata = {
>>>>>>  const short da850_mcasp_pins[] __initdata = {
>>>>>>       DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
>>>>>>       DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
>>>>>> -     DA850_AXR_11, DA850_AXR_12,
>>>>>> +     DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,

>>>>> Looks like I missed pointing this out previously, but extending
>>>>> this list to take care of all boards will not be right since
>>>>> (for example) AXR13 and AXR14 pins could be used for different
>>>>> purpose on different boards.

>>>>    This is correct as the list in da850.c is a *generic* module's pin
>>>> list.
>>>> If the board needs less pins (and the pins it does not use for McASP are
>>>> used
>>>> differently), it should define its own pin list.

>>>>> The right way would be to make this a per-board list. Since it
>>>>> is marked __initdata, that wouldn't lead to bloat.

>>>>    This patch is correct anyway. Unless DA850 EVM board can't use these
>>>> pins
>>>> for McASP -- but in this case the corresponding board file needs the
>>>> specific
>>>> pin list added.

>>> Okay. I guess you are saying we will keep adding pins to the generic list
>>> as long as *all* supported boards don't get a conflict

>>   No, I don't care about conflicts as long as da850.c is concerned.

>>> and if we run into
>>> a conflict we will spawn separate list for the affected board.

>>   Yes.

>>> The only issue I see with this approach is it puts too much burden on the
>>> developer to verify that none of the supported boards break.

>>   That should be verified by the owners of that board. They shouldn't even
>> have used the generic pin lists in the first place. The conception behind
>> pin lists in da850.c was celarly misunderstood when DA850 EVM code was
>> developed.

>>> Since it is highly unlikely that any board will need all the McASP pins,
>>> the generic list will likely remain unused.

>>   At least for now, Hawkboard will use all the defined pins -- I don't know
>> if there are any more undefined yet...

>>> It might just be easier to
>>> start using board specific lists right away. This is especially true for
>>> McASP where usage of pins across boards will likely vary widely.

>>   Well, that depends on how complete the new generic McASP pin list is. If
>> it's still not, then board specific pin list looks preferable indeed...

>>> Thanks,
>>> Sekhar

>> WBR, Sergei

> HI Sergei and Sekhar

> Thanks for check the patch

> What I can do if you agree with this change is to leave da850.c as it
> is,

    No, please don't.

> and declare

> static short hawk_mcasp_pins[] __initdata = {
> 	DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
> 	DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
> 	DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,
> 	-1
> };

> on the hawkboard file and call it insted of da850_mcasp_pins.

> 	ret = davinci_cfg_reg_list(hawk_mcasp_pins);
> 	if (ret)
> 		pr_warning("%s: mcasp mux setup failed: %d\n", __func__, ret);

> Please tell me if you agree with this change, I think is better
> because I do not touch any other file besides my board file.

    No, it's not really better. The generic list in da850.c should be more 
complete, regardless... Ideally, you should go thru the DA850 manual and put in 
that list all McASP pins that aren't already there. Then you can use your own 
pin list if that *complete* pin list can't be used on your board.

> Thanks

> Regards

> Victor Rodriguez

WBR, Sergei

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Nori, Sekhar]

On Tue, Nov 16, 2010 at 21:34:03, Sergei Shtylyov wrote:

>
> > HI Sergei and Sekhar
>
> > Thanks for check the patch
>
> > What I can do if you agree with this change is to leave da850.c as it
> > is,
>
>     No, please don't.
>
> > and declare
>
> > static short hawk_mcasp_pins[] __initdata = {
> >     DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
> >     DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
> >     DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,
> >     -1
> > };
>
> > on the hawkboard file and call it insted of da850_mcasp_pins.
>
> >     ret = davinci_cfg_reg_list(hawk_mcasp_pins);
> >     if (ret)
> >             pr_warning("%s: mcasp mux setup failed: %d\n", __func__, ret);
>
> > Please tell me if you agree with this change, I think is better
> > because I do not touch any other file besides my board file.
>
>     No, it's not really better. The generic list in da850.c should be more
> complete, regardless... Ideally, you should go thru the DA850 manual and put in
> that list all McASP pins that aren't already there. Then you can use your own
> pin list if that *complete* pin list can't be used on your board.

That will cause a bunch of pin conflicts on the EVM so it will need
its own list too.

Thanks,
Sekhar

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Victor Rodriguez]

On Tue, Nov 16, 2010 at 10:37 AM, Nori, Sekhar <nsekhar@ti.com> wrote:
> On Tue, Nov 16, 2010 at 21:34:03, Sergei Shtylyov wrote:
>
>>
>> > HI Sergei and Sekhar
>>
>> > Thanks for check the patch
>>
>> > What I can do if you agree with this change is to leave da850.c as it
>> > is,
>>
>> ? ? No, please don't.
>>
>> > and declare
>>
>> > static short hawk_mcasp_pins[] __initdata = {
>> > ? ? DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
>> > ? ? DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
>> > ? ? DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,
>> > ? ? -1
>> > };
>>
>> > on the hawkboard file and call it insted of da850_mcasp_pins.
>>
>> > ? ? ret = davinci_cfg_reg_list(hawk_mcasp_pins);
>> > ? ? if (ret)
>> > ? ? ? ? ? ? pr_warning("%s: mcasp mux setup failed: %d\n", __func__, ret);
>>
>> > Please tell me if you agree with this change, I think is better
>> > because I do not touch any other file besides my board file.
>>
>> ? ? No, it's not really better. The generic list in da850.c should be more
>> complete, regardless... Ideally, you should go thru the DA850 manual and put in
>> that list all McASP pins that aren't already there. Then you can use your own
>> pin list if that *complete* pin list can't be used on your board.
>
> That will cause a bunch of pin conflicts on the EVM so it will need
> its own list too.
>
> Thanks,
> Sekhar
>
>

So do you think that the peer-board list (as I am implementing ) would
be a better idea ?


Regards

Victor Rodriguez

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Michael Williamson]

On 11/16/2010 11:37 AM, Nori, Sekhar wrote:

> On Tue, Nov 16, 2010 at 21:34:03, Sergei Shtylyov wrote:
> 
>>
>>> HI Sergei and Sekhar
>>
>>> Thanks for check the patch
>>
>>> What I can do if you agree with this change is to leave da850.c as it
>>> is,
>>
>>     No, please don't.
>>
>>> and declare
>>
>>> static short hawk_mcasp_pins[] __initdata = {
>>>     DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
>>>     DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
>>>     DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,
>>>     -1
>>> };
>>
>>> on the hawkboard file and call it insted of da850_mcasp_pins.
>>
>>>     ret = davinci_cfg_reg_list(hawk_mcasp_pins);
>>>     if (ret)
>>>             pr_warning("%s: mcasp mux setup failed: %d\n", __func__, ret);
>>
>>> Please tell me if you agree with this change, I think is better
>>> because I do not touch any other file besides my board file.
>>
>>     No, it's not really better. The generic list in da850.c should be more
>> complete, regardless... Ideally, you should go thru the DA850 manual and put in
>> that list all McASP pins that aren't already there. Then you can use your own
>> pin list if that *complete* pin list can't be used on your board.
> 
> That will cause a bunch of pin conflicts on the EVM so it will need
> its own list too.
> 


Help me out.  Why do we need generic pin lists?

It seems to me that the "generic pin list" for da850.c isn't practical for most 
(if not all) of the peripherals.  They should be done using __initdata in
each board file.  

Just a cursory glance at what's in da850.c highlights several items being set 
up for the EVM and not generically.  For example:

- da850_uart1_pins and da850_uart2_pins: I believe both have RTS/CTS pins which
  for a generic definition should be included as for UART0, but would then 
  be unused as the EVM doesn't use these pins in this function.

- da850_mcasp_pins: if generic, must include all 16 AXR pins.  I think you'd 
  be hard pressed to find a board configuration that would use all 16 AXR pins
  for the McASP.  I'm fairly sure the EVM uses the pins called out, and uses 
  other pins for other functions.  So it's likely this structure wouldn't get used.

- da850_mmcsd0_pins : includes 2 GPIO pins (specific to the EVM, though possible for 
  other boards) for the card detect and write protect signals.  These pins are 
  completely arbitrary for that particular board design. I also believe that
  the complete mmcsd0 port has 4 more data lines as part of it's peripheral, although
  the driver doesn't support using them. 

- da850_emif25_pins interface doesn't include the generic pins for some of 
  the SDRAM functions.

- da850_cpgmac_pins defines both RMII and MII pins.  I don't think any board 
  would want to configure both sets at the same time.  Seems like this should
  never get used...

It's also incomplete.  What about the uPP pin list?  Or the VPIF?  Etc.

I think a board file author should be familiar enough with the SoC to understand
what peripheral pins he should be configuring for his/her particular hardware setup
and explicitly specify them in the board file.

If you remove the common pin-mux lists and move them to a board file, then once you 
configure your specific platform, is there any more memory used than with
the common scheme?  Of course, there would be replication of pin-mux code in the board
files that had identical configurations.  Is that the driver for the current implementation?

Is there a thread that hashes through the decisions on this that I should be googling?

Thanks for any insight.  

-Mike

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Victor Rodriguez]

________________________________________
From: Michael Williamson [michael.williamson at criticallink.com]
Sent: Tuesday, November 16, 2010 2:42 PM
To: Nori, Sekhar
Cc: Sergei Shtylyov; Victor Rodriguez; davinci-linux-open-source at linux.davincidsp.com; Russell King; Victor Rodriguez; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

On 11/16/2010 11:37 AM, Nori, Sekhar wrote:

> On Tue, Nov 16, 2010 at 21:34:03, Sergei Shtylyov wrote:
>
>>
>>> HI Sergei and Sekhar
>>
>>> Thanks for check the patch
>>
>>> What I can do if you agree with this change is to leave da850.c as it
>>> is,
>>
>>     No, please don't.
>>
>>> and declare
>>
>>> static short hawk_mcasp_pins[] __initdata = {
>>>     DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
>>>     DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
>>>     DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,
>>>     -1
>>> };
>>
>>> on the hawkboard file and call it insted of da850_mcasp_pins.
>>
>>>     ret = davinci_cfg_reg_list(hawk_mcasp_pins);
>>>     if (ret)
>>>             pr_warning("%s: mcasp mux setup failed: %d\n", __func__, ret);
>>
>>> Please tell me if you agree with this change, I think is better
>>> because I do not touch any other file besides my board file.
>>
>>     No, it's not really better. The generic list in da850.c should be more
>> complete, regardless... Ideally, you should go thru the DA850 manual and put in
>> that list all McASP pins that aren't already there. Then you can use your own
>> pin list if that *complete* pin list can't be used on your board.
>
> That will cause a bunch of pin conflicts on the EVM so it will need
> its own list too.
>


Help me out.  Why do we need generic pin lists?

It seems to me that the "generic pin list" for da850.c isn't practical for most
(if not all) of the peripherals.  They should be done using __initdata in
each board file.

Just a cursory glance at what's in da850.c highlights several items being set
up for the EVM and not generically.  For example:

- da850_uart1_pins and da850_uart2_pins: I believe both have RTS/CTS pins which
  for a generic definition should be included as for UART0, but would then
  be unused as the EVM doesn't use these pins in this function.

- da850_mcasp_pins: if generic, must include all 16 AXR pins.  I think you'd
  be hard pressed to find a board configuration that would use all 16 AXR pins
  for the McASP.  I'm fairly sure the EVM uses the pins called out, and uses
  other pins for other functions.  So it's likely this structure wouldn't get used.

- da850_mmcsd0_pins : includes 2 GPIO pins (specific to the EVM, though possible for
  other boards) for the card detect and write protect signals.  These pins are
  completely arbitrary for that particular board design. I also believe that
  the complete mmcsd0 port has 4 more data lines as part of it's peripheral, although
  the driver doesn't support using them.

- da850_emif25_pins interface doesn't include the generic pins for some of
  the SDRAM functions.

- da850_cpgmac_pins defines both RMII and MII pins.  I don't think any board
  would want to configure both sets at the same time.  Seems like this should
  never get used...

It's also incomplete.  What about the uPP pin list?  Or the VPIF?  Etc.

I think a board file author should be familiar enough with the SoC to understand
what peripheral pins he should be configuring for his/her particular hardware setup
and explicitly specify them in the board file.

If you remove the common pin-mux lists and move them to a board file, then once you
configure your specific platform, is there any more memory used than with
the common scheme?  Of course, there would be replication of pin-mux code in the board
files that had identical configurations.  Is that the driver for the current implementation?

Is there a thread that hashes through the decisions on this that I should be googling?

Thanks for any insight.

-Mike


Hi Mike thanks for the comments I agree with the part of replication

So do you recommend that the best way to solve this problem is to make a  pin list that has all the 16 pins on da850.c ?

I have checked and on the file

arch/arm/mach-davinci/include/mach/mux.h

are declared

        /* McASP function */
        DA850_ACLKR,
        DA850_ACLKX,
        DA850_AFSR,
        DA850_AFSX,
        DA850_AHCLKR,
        DA850_AHCLKX,
        DA850_AMUTE,
        DA850_AXR_15,
        DA850_AXR_14,
        DA850_AXR_13,
        DA850_AXR_12,
        DA850_AXR_11,
        DA850_AXR_10,
        DA850_AXR_9,
        DA850_AXR_8,
        DA850_AXR_7,
        DA850_AXR_6,
        DA850_AXR_5,
        DA850_AXR_4,
        DA850_AXR_3,
        DA850_AXR_2,
        DA850_AXR_1,
        DA850_AXR_0,

I have changed the pin list to


const short da850_mcasp_pins[] __initdata = {
        DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
        DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
        DA850_AXR_11, DA850_AXR_12,DA850_AXR_13, DA850_AXR_14, DA850_AXR_15,
        -1
};

and after checked with the hawk board it works fine

I have put on the list all the available pins for McASP even if hawkboard does not need the last one DA850_AXR_15 , and is still working

Please tell me which way do you recommend me

Regards

Victor Rodriguez




SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email.
Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Victor Rodriguez]

On Tue, Nov 16, 2010 at 2:42 PM, Michael Williamson
<michael.williamson@criticallink.com> wrote:
> On 11/16/2010 11:37 AM, Nori, Sekhar wrote:
>
>> On Tue, Nov 16, 2010 at 21:34:03, Sergei Shtylyov wrote:
>>
>>>
>>>> HI Sergei and Sekhar
>>>
>>>> Thanks for check the patch
>>>
>>>> What I can do if you agree with this change is to leave da850.c as it
>>>> is,
>>>
>>> ? ? No, please don't.
>>>
>>>> and declare
>>>
>>>> static short hawk_mcasp_pins[] __initdata = {
>>>> ? ? DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
>>>> ? ? DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
>>>> ? ? DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,
>>>> ? ? -1
>>>> };
>>>
>>>> on the hawkboard file and call it insted of da850_mcasp_pins.
>>>
>>>> ? ? ret = davinci_cfg_reg_list(hawk_mcasp_pins);
>>>> ? ? if (ret)
>>>> ? ? ? ? ? ? pr_warning("%s: mcasp mux setup failed: %d\n", __func__, ret);
>>>
>>>> Please tell me if you agree with this change, I think is better
>>>> because I do not touch any other file besides my board file.
>>>
>>> ? ? No, it's not really better. The generic list in da850.c should be more
>>> complete, regardless... Ideally, you should go thru the DA850 manual and put in
>>> that list all McASP pins that aren't already there. Then you can use your own
>>> pin list if that *complete* pin list can't be used on your board.
>>
>> That will cause a bunch of pin conflicts on the EVM so it will need
>> its own list too.
>>
>
>
> Help me out. ?Why do we need generic pin lists?
>
> It seems to me that the "generic pin list" for da850.c isn't practical for most
> (if not all) of the peripherals. ?They should be done using __initdata in
> each board file.
>
> Just a cursory glance at what's in da850.c highlights several items being set
> up for the EVM and not generically. ?For example:
>
> - da850_uart1_pins and da850_uart2_pins: I believe both have RTS/CTS pins which
> ?for a generic definition should be included as for UART0, but would then
> ?be unused as the EVM doesn't use these pins in this function.
>
> - da850_mcasp_pins: if generic, must include all 16 AXR pins. ?I think you'd
> ?be hard pressed to find a board configuration that would use all 16 AXR pins
> ?for the McASP. ?I'm fairly sure the EVM uses the pins called out, and uses
> ?other pins for other functions. ?So it's likely this structure wouldn't get used.
>
> - da850_mmcsd0_pins : includes 2 GPIO pins (specific to the EVM, though possible for
> ?other boards) for the card detect and write protect signals. ?These pins are
> ?completely arbitrary for that particular board design. I also believe that
> ?the complete mmcsd0 port has 4 more data lines as part of it's peripheral, although
> ?the driver doesn't support using them.
>
> - da850_emif25_pins interface doesn't include the generic pins for some of
> ?the SDRAM functions.
>
> - da850_cpgmac_pins defines both RMII and MII pins. ?I don't think any board
> ?would want to configure both sets at the same time. ?Seems like this should
> ?never get used...
>
> It's also incomplete. ?What about the uPP pin list? ?Or the VPIF? ?Etc.
>
> I think a board file author should be familiar enough with the SoC to understand
> what peripheral pins he should be configuring for his/her particular hardware setup
> and explicitly specify them in the board file.
>
> If you remove the common pin-mux lists and move them to a board file, then once you
> configure your specific platform, is there any more memory used than with
> the common scheme? ?Of course, there would be replication of pin-mux code in the board
> files that had identical configurations. ?Is that the driver for the current implementation?
>
> Is there a thread that hashes through the decisions on this that I should be googling?
>
> Thanks for any insight.
>
> -Mike
>
>
>
>
>
>
>


Hi Mike thanks for the comments I agree with the part of replication

So do you recommend that the best way to solve this problem is to make
a  pin list that has all the 16 pins on da850.c ?

I have checked and on the file

arch/arm/mach-davinci/include/mach/mux.h

are declared

        /* McASP function */
        DA850_ACLKR,
        DA850_ACLKX,
        DA850_AFSR,
        DA850_AFSX,
        DA850_AHCLKR,
        DA850_AHCLKX,
        DA850_AMUTE,
        DA850_AXR_15,
        DA850_AXR_14,
        DA850_AXR_13,
        DA850_AXR_12,
        DA850_AXR_11,
        DA850_AXR_10,
        DA850_AXR_9,
        DA850_AXR_8,
        DA850_AXR_7,
        DA850_AXR_6,
        DA850_AXR_5,
        DA850_AXR_4,
        DA850_AXR_3,
        DA850_AXR_2,
        DA850_AXR_1,
        DA850_AXR_0,

I have changed the pin list to


const short da850_mcasp_pins[] __initdata = {
        DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
        DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
        DA850_AXR_11, DA850_AXR_12,DA850_AXR_13, DA850_AXR_14, DA850_AXR_15,
        -1
};

and after checked with the hawk board it works fine

I have put on the list all the available pins for McASP even if
hawkboard does not need the last one DA850_AXR_15 , and is still
working

Please tell me which way do you recommend me

Regards

Victor Rodriguez

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Nori, Sekhar]

Hi Michael,

On Wed, Nov 17, 2010 at 02:12:53, Michael Williamson wrote:
>
> Help me out.  Why do we need generic pin lists?
>

They might help in cases where all boards will use the same set of
pins. For example, every one who uses I2C will most likely both the
clock and data pins from the IP. For more complex peripherals with
different pins options they serve a documentation purpose at best.

> It seems to me that the "generic pin list" for da850.c isn't practical for most
> (if not all) of the peripherals.  They should be done using __initdata in
> each board file.

Yes, agreed.

>
> Just a cursory glance at what's in da850.c highlights several items being set
> up for the EVM and not generically.  For example:
>
> - da850_uart1_pins and da850_uart2_pins: I believe both have RTS/CTS pins which
>   for a generic definition should be included as for UART0, but would then
>   be unused as the EVM doesn't use these pins in this function.

Yes, the generic pin list should have RTS and CTS pins defined for UART1
and UART2. This needs fixing.

>
> - da850_mcasp_pins: if generic, must include all 16 AXR pins.  I think you'd
>   be hard pressed to find a board configuration that would use all 16 AXR pins
>   for the McASP.  I'm fairly sure the EVM uses the pins called out, and uses
>   other pins for other functions.  So it's likely this structure wouldn't get used.

Yes, the generic pin list should either be completed or removed
altogether and the existing pin list da850_mcasp_pins should be
copied into the board file and called da850_evm_mcasp_pins.

>
> - da850_mmcsd0_pins : includes 2 GPIO pins (specific to the EVM, though possible for
>   other boards) for the card detect and write protect signals.  These pins are
>   completely arbitrary for that particular board design. I also believe that
>   the complete mmcsd0 port has 4 more data lines as part of it's peripheral, although
>   the driver doesn't support using them.

This is incorrect again. The generic pin list should be completed
(or removed) and the existing list should be copied into the EVM board
file as da850_evm_mmcsd0_pins.

>
> - da850_emif25_pins interface doesn't include the generic pins for some of
>   the SDRAM functions.

Yes, this should be completed (or removed). This list is unused anyway.

>
> - da850_cpgmac_pins defines both RMII and MII pins.  I don't think any board
>   would want to configure both sets at the same time.  Seems like this should
>   never get used...

Agreed.

>
> It's also incomplete.  What about the uPP pin list?  Or the VPIF?  Etc.

These should be added as the drivers for these devices are
supported.

>
> I think a board file author should be familiar enough with the SoC to understand
> what peripheral pins he should be configuring for his/her particular hardware setup
> and explicitly specify them in the board file.

Agree.

>
> If you remove the common pin-mux lists and move them to a board file, then once you
> configure your specific platform, is there any more memory used than with
> the common scheme?  Of course, there would be replication of pin-mux code in the board

There is no memory wastage. All the pin lists are init data.

I too prefer all generic pin lists which are most likely not
going to be used at all to be removed. Unused stuff like this
will only make code difficult to read.

Thanks,
Sekhar

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Victor Rodriguez]

On Thu, Nov 18, 2010 at 10:21 AM, Nori, Sekhar <nsekhar@ti.com> wrote:
> Hi Michael,
>
> On Wed, Nov 17, 2010 at 02:12:53, Michael Williamson wrote:
>>
>> Help me out. ?Why do we need generic pin lists?
>>
>
> They might help in cases where all boards will use the same set of
> pins. For example, every one who uses I2C will most likely both the
> clock and data pins from the IP. For more complex peripherals with
> different pins options they serve a documentation purpose at best.
>
>> It seems to me that the "generic pin list" for da850.c isn't practical for most
>> (if not all) of the peripherals. ?They should be done using __initdata in
>> each board file.
>
> Yes, agreed.
>
>>
>> Just a cursory glance at what's in da850.c highlights several items being set
>> up for the EVM and not generically. ?For example:
>>
>> - da850_uart1_pins and da850_uart2_pins: I believe both have RTS/CTS pins which
>> ? for a generic definition should be included as for UART0, but would then
>> ? be unused as the EVM doesn't use these pins in this function.
>
> Yes, the generic pin list should have RTS and CTS pins defined for UART1
> and UART2. This needs fixing.
>
>>
>> - da850_mcasp_pins: if generic, must include all 16 AXR pins. ?I think you'd
>> ? be hard pressed to find a board configuration that would use all 16 AXR pins
>> ? for the McASP. ?I'm fairly sure the EVM uses the pins called out, and uses
>> ? other pins for other functions. ?So it's likely this structure wouldn't get used.
>
> Yes, the generic pin list should either be completed or removed
> altogether and the existing pin list da850_mcasp_pins should be
> copied into the board file and called da850_evm_mcasp_pins.
>
>>
>> - da850_mmcsd0_pins : includes 2 GPIO pins (specific to the EVM, though possible for
>> ? other boards) for the card detect and write protect signals. ?These pins are
>> ? completely arbitrary for that particular board design. I also believe that
>> ? the complete mmcsd0 port has 4 more data lines as part of it's peripheral, although
>> ? the driver doesn't support using them.
>
> This is incorrect again. The generic pin list should be completed
> (or removed) and the existing list should be copied into the EVM board
> file as da850_evm_mmcsd0_pins.
>
>>
>> - da850_emif25_pins interface doesn't include the generic pins for some of
>> ? the SDRAM functions.
>
> Yes, this should be completed (or removed). This list is unused anyway.
>
>>
>> - da850_cpgmac_pins defines both RMII and MII pins. ?I don't think any board
>> ? would want to configure both sets at the same time. ?Seems like this should
>> ? never get used...
>
> Agreed.
>
>>
>> It's also incomplete. ?What about the uPP pin list? ?Or the VPIF? ?Etc.
>
> These should be added as the drivers for these devices are
> supported.
>
>>
>> I think a board file author should be familiar enough with the SoC to understand
>> what peripheral pins he should be configuring for his/her particular hardware setup
>> and explicitly specify them in the board file.
>
> Agree.
>
>>
>> If you remove the common pin-mux lists and move them to a board file, then once you
>> configure your specific platform, is there any more memory used than with
>> the common scheme? ?Of course, there would be replication of pin-mux code in the board
>
> There is no memory wastage. All the pin lists are init data.
>
> I too prefer all generic pin lists which are most likely not
> going to be used at all to be removed. Unused stuff like this
> will only make code difficult to read.
>
> Thanks,
> Sekhar
>
>

HI Sekhar

Let me see if I understand, you prefer to remove the unused pin list,
but that will produce a lot of changes on each board that used these
pin list. I do not have those boards, in order to test if that works
:(

I want to help to fix it and give a complete and right support to the
hawk board.

Please give me a tip of how to do it

Regards

Victor Rodriguez

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Nori, Sekhar]

Hi Victor,

On Thu, Nov 18, 2010 at 22:08:34, Victor Rodriguez wrote:

[...]

> HI Sekhar
>
> Let me see if I understand, you prefer to remove the unused pin list,
> but that will produce a lot of changes on each board that used these
> pin list. I do not have those boards, in order to test if that works
> :(
>
> I want to help to fix it and give a complete and right support to the
> hawk board.
>
> Please give me a tip of how to do it

If you make the changes and post the patches,
we can ack for the EVM. Mike would be able
to test on the Mity-DSP platform.

Anyway, I expect the changes to be fairly innocuous.

Thanks,
Sekhar

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Kevin Hilman]

"Nori, Sekhar" <nsekhar@ti.com> writes:

> Hi Michael,
>
> On Wed, Nov 17, 2010 at 02:12:53, Michael Williamson wrote:
>>
>> Help me out.  Why do we need generic pin lists?
>>
>
> They might help in cases where all boards will use the same set of
> pins. For example, every one who uses I2C will most likely both the
> clock and data pins from the IP. For more complex peripherals with
> different pins options they serve a documentation purpose at best.
>
>> It seems to me that the "generic pin list" for da850.c isn't practical for most
>> (if not all) of the peripherals.  They should be done using __initdata in
>> each board file.
>
> Yes, agreed.
>
>>
>> Just a cursory glance at what's in da850.c highlights several items being set
>> up for the EVM and not generically.  For example:
>>
>> - da850_uart1_pins and da850_uart2_pins: I believe both have RTS/CTS pins which
>>   for a generic definition should be included as for UART0, but would then
>>   be unused as the EVM doesn't use these pins in this function.
>
> Yes, the generic pin list should have RTS and CTS pins defined for UART1
> and UART2. This needs fixing.
>
>>
>> - da850_mcasp_pins: if generic, must include all 16 AXR pins.  I think you'd
>>   be hard pressed to find a board configuration that would use all 16 AXR pins
>>   for the McASP.  I'm fairly sure the EVM uses the pins called out, and uses
>>   other pins for other functions.  So it's likely this structure wouldn't get used.
>
> Yes, the generic pin list should either be completed or removed
> altogether and the existing pin list da850_mcasp_pins should be
> copied into the board file and called da850_evm_mcasp_pins.
>
>>
>> - da850_mmcsd0_pins : includes 2 GPIO pins (specific to the EVM, though possible for
>>   other boards) for the card detect and write protect signals.  These pins are
>>   completely arbitrary for that particular board design. I also believe that
>>   the complete mmcsd0 port has 4 more data lines as part of it's peripheral, although
>>   the driver doesn't support using them.
>
> This is incorrect again. The generic pin list should be completed
> (or removed) and the existing list should be copied into the EVM board
> file as da850_evm_mmcsd0_pins.
>
>>
>> - da850_emif25_pins interface doesn't include the generic pins for some of
>>   the SDRAM functions.
>
> Yes, this should be completed (or removed). This list is unused anyway.
>
>>
>> - da850_cpgmac_pins defines both RMII and MII pins.  I don't think any board
>>   would want to configure both sets at the same time.  Seems like this should
>>   never get used...
>
> Agreed.
>
>>
>> It's also incomplete.  What about the uPP pin list?  Or the VPIF?  Etc.
>
> These should be added as the drivers for these devices are
> supported.
>
>>
>> I think a board file author should be familiar enough with the SoC to understand
>> what peripheral pins he should be configuring for his/her particular hardware setup
>> and explicitly specify them in the board file.
>
> Agree.
>
>>
>> If you remove the common pin-mux lists and move them to a board file, then once you
>> configure your specific platform, is there any more memory used than with
>> the common scheme?  Of course, there would be replication of pin-mux code in the board
>
> There is no memory wastage. All the pin lists are init data.
>
> I too prefer all generic pin lists which are most likely not
> going to be used at all to be removed. Unused stuff like this
> will only make code difficult to read.

FWIW, I agree.

Now, who wants to tackle it?

Kevin

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Victor Rodriguez]

On Thu, Nov 18, 2010 at 5:57 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> "Nori, Sekhar" <nsekhar@ti.com> writes:
>
>> Hi Michael,
>>
>> On Wed, Nov 17, 2010 at 02:12:53, Michael Williamson wrote:
>>>
>>> Help me out. ?Why do we need generic pin lists?
>>>
>>
>> They might help in cases where all boards will use the same set of
>> pins. For example, every one who uses I2C will most likely both the
>> clock and data pins from the IP. For more complex peripherals with
>> different pins options they serve a documentation purpose at best.
>>
>>> It seems to me that the "generic pin list" for da850.c isn't practical for most
>>> (if not all) of the peripherals. ?They should be done using __initdata in
>>> each board file.
>>
>> Yes, agreed.
>>
>>>
>>> Just a cursory glance at what's in da850.c highlights several items being set
>>> up for the EVM and not generically. ?For example:
>>>
>>> - da850_uart1_pins and da850_uart2_pins: I believe both have RTS/CTS pins which
>>> ? for a generic definition should be included as for UART0, but would then
>>> ? be unused as the EVM doesn't use these pins in this function.
>>
>> Yes, the generic pin list should have RTS and CTS pins defined for UART1
>> and UART2. This needs fixing.
>>
>>>
>>> - da850_mcasp_pins: if generic, must include all 16 AXR pins. ?I think you'd
>>> ? be hard pressed to find a board configuration that would use all 16 AXR pins
>>> ? for the McASP. ?I'm fairly sure the EVM uses the pins called out, and uses
>>> ? other pins for other functions. ?So it's likely this structure wouldn't get used.
>>
>> Yes, the generic pin list should either be completed or removed
>> altogether and the existing pin list da850_mcasp_pins should be
>> copied into the board file and called da850_evm_mcasp_pins.
>>
>>>
>>> - da850_mmcsd0_pins : includes 2 GPIO pins (specific to the EVM, though possible for
>>> ? other boards) for the card detect and write protect signals. ?These pins are
>>> ? completely arbitrary for that particular board design. I also believe that
>>> ? the complete mmcsd0 port has 4 more data lines as part of it's peripheral, although
>>> ? the driver doesn't support using them.
>>
>> This is incorrect again. The generic pin list should be completed
>> (or removed) and the existing list should be copied into the EVM board
>> file as da850_evm_mmcsd0_pins.
>>
>>>
>>> - da850_emif25_pins interface doesn't include the generic pins for some of
>>> ? the SDRAM functions.
>>
>> Yes, this should be completed (or removed). This list is unused anyway.
>>
>>>
>>> - da850_cpgmac_pins defines both RMII and MII pins. ?I don't think any board
>>> ? would want to configure both sets at the same time. ?Seems like this should
>>> ? never get used...
>>
>> Agreed.
>>
>>>
>>> It's also incomplete. ?What about the uPP pin list? ?Or the VPIF? ?Etc.
>>
>> These should be added as the drivers for these devices are
>> supported.
>>
>>>
>>> I think a board file author should be familiar enough with the SoC to understand
>>> what peripheral pins he should be configuring for his/her particular hardware setup
>>> and explicitly specify them in the board file.
>>
>> Agree.
>>
>>>
>>> If you remove the common pin-mux lists and move them to a board file, then once you
>>> configure your specific platform, is there any more memory used than with
>>> the common scheme? ?Of course, there would be replication of pin-mux code in the board
>>
>> There is no memory wastage. All the pin lists are init data.
>>
>> I too prefer all generic pin lists which are most likely not
>> going to be used at all to be removed. Unused stuff like this
>> will only make code difficult to read.
>
> FWIW, I agree.
>
> Now, who wants to tackle it?
>
> Kevin
>

I could but I will need a little help and from all of you. :)

Regards

Victor Rodriguez


> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Victor Rodriguez]

On Thu, Nov 18, 2010 at 6:17 PM, Victor Rodriguez <vm.rod25@gmail.com> wrote:
> On Thu, Nov 18, 2010 at 5:57 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> "Nori, Sekhar" <nsekhar@ti.com> writes:
>>
>>> Hi Michael,
>>>
>>> On Wed, Nov 17, 2010 at 02:12:53, Michael Williamson wrote:
>>>>
>>>> Help me out. ?Why do we need generic pin lists?
>>>>
>>>
>>> They might help in cases where all boards will use the same set of
>>> pins. For example, every one who uses I2C will most likely both the
>>> clock and data pins from the IP. For more complex peripherals with
>>> different pins options they serve a documentation purpose at best.
>>>
>>>> It seems to me that the "generic pin list" for da850.c isn't practical for most
>>>> (if not all) of the peripherals. ?They should be done using __initdata in
>>>> each board file.
>>>
>>> Yes, agreed.
>>>
>>>>
>>>> Just a cursory glance at what's in da850.c highlights several items being set
>>>> up for the EVM and not generically. ?For example:
>>>>
>>>> - da850_uart1_pins and da850_uart2_pins: I believe both have RTS/CTS pins which
>>>> ? for a generic definition should be included as for UART0, but would then
>>>> ? be unused as the EVM doesn't use these pins in this function.
>>>
>>> Yes, the generic pin list should have RTS and CTS pins defined for UART1
>>> and UART2. This needs fixing.
>>>
>>>>
>>>> - da850_mcasp_pins: if generic, must include all 16 AXR pins. ?I think you'd
>>>> ? be hard pressed to find a board configuration that would use all 16 AXR pins
>>>> ? for the McASP. ?I'm fairly sure the EVM uses the pins called out, and uses
>>>> ? other pins for other functions. ?So it's likely this structure wouldn't get used.
>>>
>>> Yes, the generic pin list should either be completed or removed
>>> altogether and the existing pin list da850_mcasp_pins should be
>>> copied into the board file and called da850_evm_mcasp_pins.
>>>
>>>>
>>>> - da850_mmcsd0_pins : includes 2 GPIO pins (specific to the EVM, though possible for
>>>> ? other boards) for the card detect and write protect signals. ?These pins are
>>>> ? completely arbitrary for that particular board design. I also believe that
>>>> ? the complete mmcsd0 port has 4 more data lines as part of it's peripheral, although
>>>> ? the driver doesn't support using them.
>>>
>>> This is incorrect again. The generic pin list should be completed
>>> (or removed) and the existing list should be copied into the EVM board
>>> file as da850_evm_mmcsd0_pins.
>>>
>>>>
>>>> - da850_emif25_pins interface doesn't include the generic pins for some of
>>>> ? the SDRAM functions.
>>>
>>> Yes, this should be completed (or removed). This list is unused anyway.
>>>
>>>>
>>>> - da850_cpgmac_pins defines both RMII and MII pins. ?I don't think any board
>>>> ? would want to configure both sets at the same time. ?Seems like this should
>>>> ? never get used...
>>>
>>> Agreed.
>>>
>>>>
>>>> It's also incomplete. ?What about the uPP pin list? ?Or the VPIF? ?Etc.
>>>
>>> These should be added as the drivers for these devices are
>>> supported.
>>>
>>>>
>>>> I think a board file author should be familiar enough with the SoC to understand
>>>> what peripheral pins he should be configuring for his/her particular hardware setup
>>>> and explicitly specify them in the board file.
>>>
>>> Agree.
>>>
>>>>
>>>> If you remove the common pin-mux lists and move them to a board file, then once you
>>>> configure your specific platform, is there any more memory used than with
>>>> the common scheme? ?Of course, there would be replication of pin-mux code in the board
>>>
>>> There is no memory wastage. All the pin lists are init data.
>>>
>>> I too prefer all generic pin lists which are most likely not
>>> going to be used at all to be removed. Unused stuff like this
>>> will only make code difficult to read.
>>
>> FWIW, I agree.
>>
>> Now, who wants to tackle it?
>>
>> Kevin
>>
>
> I could but I will need a little help and from all of you. :)
>
> Regards
>
> Victor Rodriguez
>

Hey I have sent the first patch in order to fix UARTs on da850. please
check if this is right

Regards

Victor Rodriguez

>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>
>

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Nori, Sekhar]

Hi Victor,

On Sat, Nov 13, 2010 at 04:08:50, vm.rod25 at gmail.com wrote:
> From: Victor Rodriguez <victor.rodriguez@sasken.com>
>
> This patch defines Pin Mux configuration for MacASP
> used on the Hawkboard-L138 system in order to add Audio support
>
> Signed-off-by: Victor Rodriguez <victor.rodriguez@sasken.com>
> Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
> ---
>  arch/arm/mach-davinci/da850.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 63916b9..f033a0a 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -591,7 +591,7 @@ const short da850_cpgmac_pins[] __initdata = {
>  const short da850_mcasp_pins[] __initdata = {
>       DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
>       DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
> -     DA850_AXR_11, DA850_AXR_12,
> +     DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,

To speed up acceptance of this series, can you please drop this
patch and submit the rest of the patches as a reduced series?

Audio support can be revisited as a separate patch.

Thanks,
Sekhar

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Victor Rodriguez]

On Wed, Dec 1, 2010 at 7:32 AM, Nori, Sekhar <nsekhar@ti.com> wrote:
> Hi Victor,
>
> On Sat, Nov 13, 2010 at 04:08:50, vm.rod25 at gmail.com wrote:
>> From: Victor Rodriguez <victor.rodriguez@sasken.com>
>>
>> This patch defines Pin Mux configuration for MacASP
>> used on the Hawkboard-L138 system in order to add Audio support
>>
>> Signed-off-by: Victor Rodriguez <victor.rodriguez@sasken.com>
>> Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
>> ---
>> ?arch/arm/mach-davinci/da850.c | ? ?2 +-
>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
>> index 63916b9..f033a0a 100644
>> --- a/arch/arm/mach-davinci/da850.c
>> +++ b/arch/arm/mach-davinci/da850.c
>> @@ -591,7 +591,7 @@ const short da850_cpgmac_pins[] __initdata = {
>> ?const short da850_mcasp_pins[] __initdata = {
>> ? ? ? DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
>> ? ? ? DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
>> - ? ? DA850_AXR_11, DA850_AXR_12,
>> + ? ? DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,
>
> To speed up acceptance of this series, can you please drop this
> patch and submit the rest of the patches as a reduced series?
>
> Audio support can be revisited as a separate patch.
>
> Thanks,
> Sekhar
>

Yes Sekhar I will do it  right now, sorry for the delay with the other
patch that fix this

Regards

Victor Rodriguez

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Nori, Sekhar]

On Wed, Dec 01, 2010 at 20:50:04, Victor Rodriguez wrote:
>
> Yes Sekhar I will do it  right now, sorry for the delay with the other
> patch that fix this

The issue was not yours to fix. The generic pin lists need to be cleaned
up regardless. So, don't be sorry :)

Thanks,
Sekhar

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Victor Rodriguez]

By the way I will eliminate 3 of my patches

[PATCH v8 3/9] davinci: ASoC support for Omapl138-Hawkboard
[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard
[PATCH v8 5/9] davinci: Audio support for Omapl138-Hawkboard

Because if I eliminate the  McASP configuration I can not enable the
audio support for the board, the kernel compiles and the sound card is
recognized but when I try to play any file on the board it will not
produce any error but no sound will be produced either

So in order to do not give a wrong support I will eliminate the audio
support for hawk board

Regards

Victor Rodriguez




On Wed, Dec 1, 2010 at 10:04 AM, Nori, Sekhar <nsekhar@ti.com> wrote:
> On Wed, Dec 01, 2010 at 20:50:04, Victor Rodriguez wrote:
>>
>> Yes Sekhar I will do it ?right now, sorry for the delay with the other
>> patch that fix this
>
> The issue was not yours to fix. The generic pin lists need to be cleaned
> up regardless. So, don't be sorry :)
>
> Thanks,
> Sekhar
>
>

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Sergei Shtylyov]

Hello.

Nori, Sekhar wrote:

> On Sat, Nov 13, 2010 at 04:08:50, vm.rod25 at gmail.com wrote:
>> From: Victor Rodriguez <victor.rodriguez@sasken.com>

>> This patch defines Pin Mux configuration for MacASP
>> used on the Hawkboard-L138 system in order to add Audio support

>> Signed-off-by: Victor Rodriguez <victor.rodriguez@sasken.com>
>> Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
>> ---
>>  arch/arm/mach-davinci/da850.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)

>> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
>> index 63916b9..f033a0a 100644
>> --- a/arch/arm/mach-davinci/da850.c
>> +++ b/arch/arm/mach-davinci/da850.c
>> @@ -591,7 +591,7 @@ const short da850_cpgmac_pins[] __initdata = {
>>  const short da850_mcasp_pins[] __initdata = {
>>       DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
>>       DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
>> -     DA850_AXR_11, DA850_AXR_12,
>> +     DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,

> To speed up acceptance of this series, can you please drop this
> patch and submit the rest of the patches as a reduced series?

    BTW, I've seen more AXR pins in DA850, so this patch is far from being 
complete anyway.

> Thanks,
> Sekhar

WBR, Sergei

[PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard

[Victor Rodriguez]

On Wed, Dec 1, 2010 at 10:32 AM, Sergei Shtylyov <sshtylyov@mvista.com> wrote:
> Hello.
>
> Nori, Sekhar wrote:
>
>> On Sat, Nov 13, 2010 at 04:08:50, vm.rod25 at gmail.com wrote:
>>>
>>> From: Victor Rodriguez <victor.rodriguez@sasken.com>
>
>>> This patch defines Pin Mux configuration for MacASP
>>> used on the Hawkboard-L138 system in order to add Audio support
>
>>> Signed-off-by: Victor Rodriguez <victor.rodriguez@sasken.com>
>>> Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
>>> ---
>>> ?arch/arm/mach-davinci/da850.c | ? ?2 +-
>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
>>> diff --git a/arch/arm/mach-davinci/da850.c
>>> b/arch/arm/mach-davinci/da850.c
>>> index 63916b9..f033a0a 100644
>>> --- a/arch/arm/mach-davinci/da850.c
>>> +++ b/arch/arm/mach-davinci/da850.c
>>> @@ -591,7 +591,7 @@ const short da850_cpgmac_pins[] __initdata = {
>>> ?const short da850_mcasp_pins[] __initdata = {
>>> ? ? ?DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
>>> ? ? ?DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
>>> - ? ? DA850_AXR_11, DA850_AXR_12,
>>> + ? ? DA850_AXR_11, DA850_AXR_12, DA850_AXR_13, DA850_AXR_14,
>
>> To speed up acceptance of this series, can you please drop this
>> patch and submit the rest of the patches as a reduced series?
>
> ? BTW, I've seen more AXR pins in DA850, so this patch is far from being
> complete anyway.

Ok Sergei we will need to work hard on it

By the way is there any other comment to my patches with out this from
audio and McASP pins ?

Regards

Victor Rodriguez


>> Thanks,
>> Sekhar
>
> WBR, Sergei
>

[PATCH v8 5/9] davinci: Audio support for Omapl138-Hawkboard

[vm.rod25 at gmail.com]

From: Victor Rodriguez <victor.rodriguez@sasken.com>

This patch adds sound support for the Hawkboard-L138 system

Signed-off-by: Victor Rodriguez <victor.rodriguez@sasken.com>
Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
---
Notes:

This patch works with da8xx_omapl_defconfig

In order to test ALSA utils select in menuconfig like insmodule:

Sound card support  --->
      Advanced Linux Sound Architecture  --->
              ALSA for SoC audio support  --->
              SoC Audio for the TI DAVINCI chip
              SoC Audio support for DA850/OMAP-L138 EVM/Hawkboard

 arch/arm/mach-davinci/board-omapl138-hawk.c |   46 +++++++++++++++++++++++++++
 1 files changed, 46 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 114fc9b..115dac0 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -13,6 +13,7 @@
 #include <linux/init.h>
 #include <linux/console.h>
 #include <linux/gpio.h>
+#include <linux/i2c.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -110,6 +111,38 @@ static struct edma_rsv_info *da850_edma_rsv[2] = {
 	&da850_edma_cc1_rsv,
 };
 
+static struct i2c_board_info __initdata omapl138_hawk_i2c_devices[] = {
+	{
+		I2C_BOARD_INFO("tlv320aic3x", 0x18),
+	},
+};
+
+static struct davinci_i2c_platform_data omapl138_hawk_i2c_0_pdata = {
+	.bus_freq	= 100,	/* kHz */
+	.bus_delay	= 0,	/* usec */
+};
+
+/* davinci Hawkboard audio machine driver */
+static u8 da850_iis_serializer_direction[] = {
+	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,
+	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,
+	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,
+	INACTIVE_MODE,	TX_MODE,	RX_MODE,	INACTIVE_MODE,
+};
+
+static struct snd_platform_data omapl138_hawk_snd_data = {
+	.tx_dma_offset	= 0x2000,
+	.rx_dma_offset	= 0x2000,
+	.op_mode	= DAVINCI_MCASP_IIS_MODE,
+	.num_serializer	= ARRAY_SIZE(da850_iis_serializer_direction),
+	.tdm_slots	= 2,
+	.serial_dir	= da850_iis_serializer_direction,
+	.asp_chan_q	= EVENTQ_1,
+	.version	= MCASP_VERSION_2,
+	.txnumevt	= 1,
+	.rxnumevt	= 1,
+};
+
 static struct davinci_uart_config omapl138_hawk_uart_config __initdata = {
 	.enabled_uarts = 0x7,
 };
@@ -127,6 +160,19 @@ static __init void omapl138_hawk_init(void)
 		pr_warning("%s: EDMA registration failed: %d\n",
 			__func__, ret);
 
+	i2c_register_board_info(1, omapl138_hawk_i2c_devices,
+			ARRAY_SIZE(omapl138_hawk_i2c_devices));
+
+	ret = da8xx_register_i2c(0, &omapl138_hawk_i2c_0_pdata);
+	if (ret)
+		pr_warning("%s: i2c0 registration failed: %d\n",
+			__func__, ret);
+
+	ret = davinci_cfg_reg_list(da850_mcasp_pins);
+	if (ret)
+		pr_warning("%s: mcasp mux setup failed: %d\n", __func__, ret);
+	da8xx_register_mcasp(0, &omapl138_hawk_snd_data);
+
 	ret = da8xx_register_watchdog();
 	if (ret)
 		pr_warning("omapl138_hawk_init: "
-- 
1.7.0.4

[PATCH v8 6/9] davinci: MMC/SD and USB-OHCI configuration for Omapl138-Hawkboard

[vm.rod25 at gmail.com]

From: Victor Rodriguez <victor.rodriguez@sasken.com>

This patch defines Pin Mux configuration to enable MMC/SD
and USB-OHCI on the Hawkboard-L138 system

Signed-off-by: Victor Rodriguez <victor.rodriguez@sasken.com>
Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
---
 arch/arm/mach-davinci/da850.c            |    4 ++++
 arch/arm/mach-davinci/include/mach/mux.h |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index f033a0a..4458bff 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -543,11 +543,15 @@ static const struct mux_config da850_pins[] = {
 	MUX_CFG(DA850, EMA_WAIT_1,	6,	24,	15,	1,	false)
 	MUX_CFG(DA850, NEMA_CS_2,	7,	0,	15,	1,	false)
 	/* GPIO function */
+	MUX_CFG(DA850, GPIO2_4,		6,	12,	15,	8,	false)
 	MUX_CFG(DA850, GPIO2_6,		6,	4,	15,	8,	false)
 	MUX_CFG(DA850, GPIO2_8,		5,	28,	15,	8,	false)
 	MUX_CFG(DA850, GPIO2_15,	5,	0,	15,	8,	false)
+	MUX_CFG(DA850, GPIO3_12,	7,	12,	15,	8,	false)
+	MUX_CFG(DA850, GPIO3_13,	7,	8,	15,	8,	false)
 	MUX_CFG(DA850, GPIO4_0,		10,	28,	15,	8,	false)
 	MUX_CFG(DA850, GPIO4_1,		10,	24,	15,	8,	false)
+	MUX_CFG(DA850, GPIO6_13,	13,	8,	15,	8,	false)
 	MUX_CFG(DA850, RTC_ALARM,	0,	28,	15,	2,	false)
 #endif
 };
diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h
index de11aac..5d4e0fe 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h
@@ -908,11 +908,15 @@ enum davinci_da850_index {
 	DA850_NEMA_CS_2,
 
 	/* GPIO function */
+	DA850_GPIO2_4,
 	DA850_GPIO2_6,
 	DA850_GPIO2_8,
 	DA850_GPIO2_15,
+	DA850_GPIO3_12,
+	DA850_GPIO3_13,
 	DA850_GPIO4_0,
 	DA850_GPIO4_1,
+	DA850_GPIO6_13,
 	DA850_RTC_ALARM,
 };
 
-- 
1.7.0.4

[PATCH v8 7/9] davinci: MMC/SD support for Omapl138-Hawkboard

[vm.rod25 at gmail.com]

From: Victor Rodriguez <victor.rodriguez@sasken.com>

This patch adds MMC/SD support for the Hawkboard-L138 system

Signed-off-by: Victor Rodriguez <victor.rodriguez@sasken.com>
Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
---
Notes:

This patch works with da8xx_omapl_defconfig
In order to test it select in menuconfig like insmodule

MMC/SD/SDIO card support  --->
      MMC block device driver
      Use bounce buffer for simple hosts
      TI DAVINCI Multimedia Card Interface support

 arch/arm/mach-davinci/board-omapl138-hawk.c |   63 +++++++++++++++++++++++++++
 1 files changed, 63 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 115dac0..02e54fa 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -23,6 +23,8 @@
 #include <mach/mux.h>
 
 #define HAWKBOARD_PHY_ID		"0:07"
+#define DA850_HAWK_MMCSD_CD_PIN		GPIO_TO_PIN(3, 12)
+#define DA850_HAWK_MMCSD_WP_PIN		GPIO_TO_PIN(3, 13)
 
 static short omapl138_hawk_mii_pins[] __initdata = {
 	DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
@@ -143,6 +145,65 @@ static struct snd_platform_data omapl138_hawk_snd_data = {
 	.rxnumevt	= 1,
 };
 
+static const short hawk_mmcsd0_pins[] = {
+	DA850_MMCSD0_DAT_0, DA850_MMCSD0_DAT_1, DA850_MMCSD0_DAT_2,
+	DA850_MMCSD0_DAT_3, DA850_MMCSD0_CLK, DA850_MMCSD0_CMD,
+	DA850_GPIO3_12, DA850_GPIO3_13,
+	-1
+};
+
+static int da850_hawk_mmc_get_ro(int index)
+{
+	return gpio_get_value(DA850_HAWK_MMCSD_WP_PIN);
+}
+
+static int da850_hawk_mmc_get_cd(int index)
+{
+	return !gpio_get_value(DA850_HAWK_MMCSD_CD_PIN);
+}
+
+static struct davinci_mmc_config da850_mmc_config = {
+	.get_ro		= da850_hawk_mmc_get_ro,
+	.get_cd		= da850_hawk_mmc_get_cd,
+	.wires		= 4,
+	.max_freq	= 50000000,
+	.caps		= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
+	.version	= MMC_CTLR_VERSION_2,
+};
+
+static __init void omapl138_hawk_mmc_init(void)
+{
+	int ret;
+
+	ret = davinci_cfg_reg_list(hawk_mmcsd0_pins);
+	if (ret) {
+		pr_warning("%s: MMC/SD0 mux setup failed: %d\n",
+			__func__, ret);
+		return;
+	}
+
+	ret = gpio_request_one(DA850_HAWK_MMCSD_CD_PIN,
+			GPIOF_DIR_IN, "MMC CD");
+	if (ret < 0) {
+		pr_warning("%s: can not open GPIO %d\n",
+			__func__, DA850_HAWK_MMCSD_CD_PIN);
+		return;
+	}
+
+	ret = gpio_request_one(DA850_HAWK_MMCSD_WP_PIN,
+			GPIOF_DIR_IN, "MMC WP");
+	if (ret < 0) {
+		pr_warning("%s: can not open GPIO %d\n",
+			__func__, DA850_HAWK_MMCSD_WP_PIN);
+		return;
+	}
+
+	ret = da8xx_register_mmcsd0(&da850_mmc_config);
+	if (ret)
+		pr_warning("%s: MMC/SD0 registration failed: %d\n",
+			__func__, ret);
+}
+
 static struct davinci_uart_config omapl138_hawk_uart_config __initdata = {
 	.enabled_uarts = 0x7,
 };
@@ -173,6 +234,8 @@ static __init void omapl138_hawk_init(void)
 		pr_warning("%s: mcasp mux setup failed: %d\n", __func__, ret);
 	da8xx_register_mcasp(0, &omapl138_hawk_snd_data);
 
+	omapl138_hawk_mmc_init();
+
 	ret = da8xx_register_watchdog();
 	if (ret)
 		pr_warning("omapl138_hawk_init: "
-- 
1.7.0.4

[PATCH v8 8/9] davinci: USB clocks for Omapl138-Hawkboard

[vm.rod25 at gmail.com]

From: Victor Rodriguez <victor.rodriguez@sasken.com>

This patch adds USB1.1 and USB2.0 clocks for the Hawkboard-L138 system

Signed-off-by: Victor Rodriguez <victor.rodriguez@sasken.com>
Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
---
 arch/arm/mach-davinci/da850.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 4458bff..b3b1adb 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -345,6 +345,20 @@ static struct clk aemif_clk = {
 	.flags		= ALWAYS_ENABLED,
 };
 
+static struct clk usb11_clk = {
+	.name		= "usb11",
+	.parent		= &pll0_sysclk4,
+	.lpsc		= DA8XX_LPSC1_USB11,
+	.gpsc		= 1,
+};
+
+static struct clk usb20_clk = {
+	.name		= "usb20",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_USB20,
+	.gpsc		= 1,
+};
+
 static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"ref",		&ref_clk),
 	CLK(NULL,		"pll0",		&pll0_clk),
@@ -387,6 +401,8 @@ static struct clk_lookup da850_clks[] = {
 	CLK("davinci_mmc.0",	NULL,		&mmcsd0_clk),
 	CLK("davinci_mmc.1",	NULL,		&mmcsd1_clk),
 	CLK(NULL,		"aemif",	&aemif_clk),
+	CLK(NULL,		"usb11",	&usb11_clk),
+	CLK(NULL,		"usb20",	&usb20_clk),
 	CLK(NULL,		NULL,		NULL),
 };
 
-- 
1.7.0.4

[PATCH v8 9/9] davinci: USB1.1 support for Omapl138-Hawkboard

[vm.rod25 at gmail.com]

From: Victor Rodriguez <victor.rodriguez@sasken.com>

This patch adds USB1.1 support for the Hawkboard-L138 system

Signed-off-by: Victor Rodriguez <victor.rodriguez@sasken.com>
Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
---
Notes:

This patch works with da8xx_omapl_defconfig
In order to test it select in menuconfig like insmodule

 Device Drivers  --->
    SCSI device support  --->
       SCSI device support
       legacy /proc/scsi/ support
       SCSI disk support
       SCSI low-level drivers

       USB support  --->
               Support for Host-side USB
               OHCI HCD support (NEW)
               USB Mass Storage support (NEW)
               USB Gadget Support  --->
               USB Gadget Drivers (Ethernet Gadget\
                (with CDC Ethernet support))  --->
               NOP USB Transceiver Driver

And you will be able to mount and USB pen drive

In order to connect a keyboard or a mouse on a USB-hub
select in menuconfig like insmodule

HID Devices  --->
       Generic HID support
       USB Human Interface Device (full HID) support

 arch/arm/mach-davinci/board-omapl138-hawk.c |  106 +++++++++++++++++++++++++++
 1 files changed, 106 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 02e54fa..ec3d95e 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -26,6 +26,9 @@
 #define DA850_HAWK_MMCSD_CD_PIN		GPIO_TO_PIN(3, 12)
 #define DA850_HAWK_MMCSD_WP_PIN		GPIO_TO_PIN(3, 13)
 
+#define DA850_USB1_VBUS_PIN		GPIO_TO_PIN(2, 4)
+#define DA850_USB1_OC_PIN		GPIO_TO_PIN(6, 13)
+
 static short omapl138_hawk_mii_pins[] __initdata = {
 	DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
 	DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
@@ -204,6 +207,107 @@ static __init void omapl138_hawk_mmc_init(void)
 			__func__, ret);
 }
 
+static irqreturn_t omapl138_hawk_usb_ocic_irq(int irq, void *dev_id);
+static da8xx_ocic_handler_t hawk_usb_ocic_handler;
+
+static const short da850_hawk_usb11_pins[] = {
+	DA850_GPIO2_4, DA850_GPIO6_13,
+	-1
+};
+
+static int hawk_usb_set_power(unsigned port, int on)
+{
+	gpio_set_value(DA850_USB1_VBUS_PIN, on);
+	return 0;
+}
+
+static int hawk_usb_get_power(unsigned port)
+{
+	return gpio_get_value(DA850_USB1_VBUS_PIN);
+}
+
+static int hawk_usb_get_oci(unsigned port)
+{
+	return !gpio_get_value(DA850_USB1_OC_PIN);
+}
+
+static int hawk_usb_ocic_notify(da8xx_ocic_handler_t handler)
+{
+	int irq         = gpio_to_irq(DA850_USB1_OC_PIN);
+	int error       = 0;
+
+	if (handler != NULL) {
+		hawk_usb_ocic_handler = handler;
+
+		error = request_irq(irq, omapl138_hawk_usb_ocic_irq,
+					IRQF_DISABLED | IRQF_TRIGGER_RISING |
+					IRQF_TRIGGER_FALLING,
+					"OHCI over-current indicator", NULL);
+		if (error)
+			pr_err(KERN_ERR "%s: could not request IRQ to watch "
+				"over-current indicator changes\n", __func__);
+	} else {
+		free_irq(irq, NULL);
+	}
+	return error;
+}
+
+static struct da8xx_ohci_root_hub omapl138_hawk_usb11_pdata = {
+	.set_power      = hawk_usb_set_power,
+	.get_power      = hawk_usb_get_power,
+	.get_oci        = hawk_usb_get_oci,
+	.ocic_notify    = hawk_usb_ocic_notify,
+	/* TPS2087 switch @ 5V */
+	.potpgt         = (3 + 1) / 2,  /* 3 ms max */
+};
+
+static irqreturn_t omapl138_hawk_usb_ocic_irq(int irq, void *dev_id)
+{
+	hawk_usb_ocic_handler(&omapl138_hawk_usb11_pdata, 1);
+	return IRQ_HANDLED;
+}
+
+static __init void omapl138_hawk_usb_init(void)
+{
+	int ret;
+	u32 cfgchip2;
+
+	ret = davinci_cfg_reg_list(da850_hawk_usb11_pins);
+	if (ret) {
+		pr_warning("%s: USB 1.1 PinMux setup failed: %d\n",
+			__func__, ret);
+		return;
+	}
+
+	/* Setup the Ref. clock frequency for the HAWK at 24 MHz. */
+
+	cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+	cfgchip2 &= ~CFGCHIP2_REFFREQ;
+	cfgchip2 |=  CFGCHIP2_REFFREQ_24MHZ;
+	__raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+	ret = gpio_request_one(DA850_USB1_VBUS_PIN,
+			GPIOF_DIR_OUT, "USB1 VBUS");
+	if (ret < 0) {
+		pr_err(KERN_ERR "%s: failed to request GPIO for USB 1.1 port "
+			"power control: %d\n", __func__, ret);
+		return;
+	}
+
+	ret = gpio_request_one(DA850_USB1_OC_PIN,
+			GPIOF_DIR_IN, "USB1 OC");
+	if (ret < 0) {
+		pr_err(KERN_ERR "%s: failed to request GPIO for USB 1.1 port "
+			"over-current indicator: %d\n", __func__, ret);
+		return;
+	}
+
+	ret = da8xx_register_usb11(&omapl138_hawk_usb11_pdata);
+	if (ret)
+		pr_warning("%s: USB 1.1 registration failed: %d\n",
+			__func__, ret);
+}
+
 static struct davinci_uart_config omapl138_hawk_uart_config __initdata = {
 	.enabled_uarts = 0x7,
 };
@@ -236,6 +340,8 @@ static __init void omapl138_hawk_init(void)
 
 	omapl138_hawk_mmc_init();
 
+	omapl138_hawk_usb_init();
+
 	ret = da8xx_register_watchdog();
 	if (ret)
 		pr_warning("omapl138_hawk_init: "
-- 
1.7.0.4