| Message ID | 1253656999-18598-1-git-send-email-chaithrika@ti.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
Hello. Chaithrika U S wrote: > DA850/OMAP-L138 EVM has a RMII Ethernet PHY on the UI daughter card. The PHY > is enabled by proper programming of the IO Expander (TCA6416) ports. Also for > RMII PHY to work, the MDIO clock of MII PHY has to be disabled since both the > PHYs have the same address. This is done via the GPIO2[6] pin. This patch adds > support for RMII PHY. > > This patch also adds a menuconfig option to select UI card and peripherals > present on it. Currently, the only sub-option in this menu is RMII. > This menuconfig option is similar to the one present for UI card on > DA830/OMAP-L137 EVM. > > Signed-off-by: Chaithrika U S <chaithrika@ti.com> [...] > diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig > index 7b6dddf..4ee61cc 100644 > --- a/arch/arm/mach-davinci/Kconfig > +++ b/arch/arm/mach-davinci/Kconfig > @@ -129,6 +129,32 @@ config MACH_DAVINCI_DA850_EVM > help > Say Y here to select the TI DA850/OMAP-L138 Evaluation Module. > > +config DA850_UI > + bool "DA850/OMAP-L138 UI (User Interface) board support" > + depends on MACH_DAVINCI_DA850_EVM > + help > + Say Y here if you have the DA850/OMAP-L138 UI > + (User Interface) board installed and you want to > + enable the peripherals located on User Interface > + board. > + > +choice > + prompt "Select DA850/OMAP-L138 UI board peripheral" > + depends on DA850_UI Are the devices on the UI board really mutually exclusive? > + > +config DA850_UI_RMII > + bool "RMII Ethernet PHY" > + help > + Say Y if you want to use the RMII PHY on the DA850/OMAP-L138 EVM. > + This PHY is found on the UI daughter card that is supplied with > + the EVM. > + NOTE: Please take care while choosing this option, MII PHY will > + not be functional if RMII mode is selected. This also affects > + the operation of video devices as they are pin multiplexed with > + RMII pins. Perhaps it's worth printing out a message about this when DA850_UI_RMII is enabled? > diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c > index 25ae007..43cc629 100644 > --- a/arch/arm/mach-davinci/board-da850-evm.c > +++ b/arch/arm/mach-davinci/board-da850-evm.c [...] > @@ -43,6 +44,8 @@ > #define DA850_MMCSD_CD_PIN GPIO_TO_PIN(4, 0) > #define DA850_MMCSD_WP_PIN GPIO_TO_PIN(4, 1) > > +#define DA850_MII_MDIO_CLKEN_PIN GPIO_TO_PIN(2, 6) > + > static struct mtd_partition da850_evm_norflash_partition[] = { > { > .name = "NOR filesystem", > @@ -270,11 +273,141 @@ static const short da850_evm_lcdc_pins[] = { > -1 > }; > > +#ifdef CONFIG_DA850_UI > +static int da850_evm_ui_expander_setup(struct i2c_client *client, unsigned gpio, > + unsigned ngpio, void *c) > +{ > + struct davinci_soc_info *soc_info = &davinci_soc_info; > + int sel_a, sel_b, sel_c, ret; > + > + sel_a = gpio + 7; > + sel_b = gpio + 6; > + sel_c = gpio + 5; > + > + ret = gpio_request(sel_a, "sel_a"); > + if (ret) { > + pr_warning("Cannot open UI expander pin %d\n", sel_a); > + goto exp_setup_sela_fail; > + } > + > + ret = gpio_request(sel_b, "sel_b"); > + if (ret) { > + pr_warning("Cannot open UI expander pin %d\n", sel_b); > + goto exp_setup_selb_fail; > + } > + > + ret = gpio_request(sel_c, "sel_c"); > + if (ret) { > + pr_warning("Cannot open UI expander pin %d\n", sel_c); > + goto exp_setup_selc_fail; > + } > + > + /* deselect all fucntionalities */ > + gpio_direction_output(sel_a, 1); > + gpio_direction_output(sel_b, 1); > + gpio_direction_output(sel_c, 1); > + > + if (soc_info->emac_pdata->rmii_en) > + /* enable RMII */ > + gpio_direction_output(sel_a, 0); gpio_set_value() is enough. > +static int da850_evm_ui_expander_teardown(struct i2c_client *client, > + unsigned gpio, unsigned ngpio, void *c) > +{ > + /* deselect all fucntionalities */ Functionalities. :-) > +static int __init da850_evm_config_emac(u8 rmii_en) > +{ > + void __iomem *cfg_chip3_base; > + int ret; > + u32 val; > + > + cfg_chip3_base = DA8XX_SYSCFG_VIRT(DA8XX_CFGCHIP3_REG); > + > + /* configure the CFGCHIP3 register for RMII or MII */ > + val = __raw_readl(cfg_chip3_base); > + if (rmii_en) > + val |= BIT(8); > + else > + val &= ~BIT(8); > + > + __raw_writel(val, cfg_chip3_base); > + > + if (!rmii_en) > + ret = da8xx_pinmux_setup(da850_cpgmac_pins); > + else > + ret = da8xx_pinmux_setup(da850_rmii_pins); > + if (ret) > + pr_warning("da850_evm_init: cpgmac/rmii mux setup failed: %d\n", > + ret); > + > + if (rmii_en) { > + /* Disable MII MDIO clock */ > + ret = davinci_cfg_reg(DA850_GPIO2_6); > + if (ret) > + pr_warning("da850_evm_init:GPIO(2,6) mux setup " > + "failed\n"); > + > + ret = gpio_request(DA850_MII_MDIO_CLKEN_PIN, "mdio_clk_en"); > + if (ret) { > + pr_warning("Cannot open GPIO %d\n", > + DA850_MII_MDIO_CLKEN_PIN); > + return ret; > + } > + > + gpio_direction_output(DA850_MII_MDIO_CLKEN_PIN, 1); > + } I guess you need to request GPIO2[6] anyway (and then set it to 0) also in case when rmii_en is 0... WBR, Sergei
On Tue, Sep 22, 2009 at 18:35:12, Sergei Shtylyov wrote: > Hello. > > Chaithrika U S wrote: > > > DA850/OMAP-L138 EVM has a RMII Ethernet PHY on the UI daughter card. The PHY > > is enabled by proper programming of the IO Expander (TCA6416) ports. Also for > > RMII PHY to work, the MDIO clock of MII PHY has to be disabled since both the > > PHYs have the same address. This is done via the GPIO2[6] pin. This patch adds > > support for RMII PHY. > > > > This patch also adds a menuconfig option to select UI card and peripherals > > present on it. Currently, the only sub-option in this menu is RMII. > > This menuconfig option is similar to the one present for UI card on > > DA830/OMAP-L137 EVM. > > > > Signed-off-by: Chaithrika U S <chaithrika@ti.com> > > [...] > > > diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig > > index 7b6dddf..4ee61cc 100644 > > --- a/arch/arm/mach-davinci/Kconfig > > +++ b/arch/arm/mach-davinci/Kconfig > > @@ -129,6 +129,32 @@ config MACH_DAVINCI_DA850_EVM > > help > > Say Y here to select the TI DA850/OMAP-L138 Evaluation Module. > > > > +config DA850_UI > > + bool "DA850/OMAP-L138 UI (User Interface) board support" > > + depends on MACH_DAVINCI_DA850_EVM > > + help > > + Say Y here if you have the DA850/OMAP-L138 UI > > + (User Interface) board installed and you want to > > + enable the peripherals located on User Interface > > + board. > > + > > +choice > > + prompt "Select DA850/OMAP-L138 UI board peripheral" > > + depends on DA850_UI > > Are the devices on the UI board really mutually exclusive? What is the purpose of the UI board configuration? Is it just to provide one place where all UI board peripherals can be disabled? Each of the modules already have a menuconfig item. Drivers (at least NAND and NOR) can bail out if they can't detect the device. Most of the choice on the UI card arises from SoC pinmux limitations. Other boards are handling this using warnings printed at boot-time. It can be done the same way for DA830/DA850. Thanks, Sekhar
Hello. Nori, Sekhar wrote: >>> is enabled by proper programming of the IO Expander (TCA6416) ports. Also for >>> RMII PHY to work, the MDIO clock of MII PHY has to be disabled since both the >>> PHYs have the same address. This is done via the GPIO2[6] pin. This patch adds >>> support for RMII PHY. >>> >>> This patch also adds a menuconfig option to select UI card and peripherals >>> present on it. Currently, the only sub-option in this menu is RMII. >>> This menuconfig option is similar to the one present for UI card on >>> DA830/OMAP-L137 EVM. >>> >>> Signed-off-by: Chaithrika U S <chaithrika@ti.com> >>> >> [...] >> >>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig >>> index 7b6dddf..4ee61cc 100644 >>> --- a/arch/arm/mach-davinci/Kconfig >>> +++ b/arch/arm/mach-davinci/Kconfig >>> @@ -129,6 +129,32 @@ config MACH_DAVINCI_DA850_EVM >>> help >>> Say Y here to select the TI DA850/OMAP-L138 Evaluation Module. >>> >>> +config DA850_UI >>> + bool "DA850/OMAP-L138 UI (User Interface) board support" >>> + depends on MACH_DAVINCI_DA850_EVM >>> + help >>> + Say Y here if you have the DA850/OMAP-L138 UI >>> + (User Interface) board installed and you want to >>> + enable the peripherals located on User Interface >>> + board. >>> + >>> +choice >>> + prompt "Select DA850/OMAP-L138 UI board peripheral" >>> + depends on DA850_UI >>> >> Are the devices on the UI board really mutually exclusive? >> > > What is the purpose of the UI board configuration? Is it just to > provide one place where all UI board peripherals can be disabled? > In case of DA830 EVM, it's a place where the UI board support can be disabled -- you can't do that with the 'choice' statement which would alwys select at least one item. But it's not only that. The board has the GPIO expander which we need not support (and setup) if the board is absent. It was not clear to me where the TCA6414 GPIO expander is situated on DA850 EVM -- on the board itself or on the UI daughter board... > Each of the modules already have a menuconfig item. Not just a 'config' item currently but a 'choice' which always selects *one* item. You can't select "none" without another option. > Drivers (at least NAND and NOR) can bail out if they can't detect the device. On DA830 EVM NAND and NOR flashes use AEMIF resources (paticularly CE3 signal, IIRC) in an incompatible way, so you can only have one of them enabled at a time; there's no PinMux conflict between NAND and NOR as they both use the AEMIF module -- hence was the use of the 'choice' to select between NAND, NOR and LCD support. > Most of the choice on the UI card arises from SoC pinmux limitations. Not really... > Other boards are handling this using warnings printed at boot-time. Frankly speaking, I don't at all find those warnings appealing. I would have preferred something more smart but it was decided against "overloading" clk_enable() with the PinMux conflict resolution. We still could teach davinci_cfg_reg() to check for the conflicts as it can return error. Mark, Steve, are there any plans to do that; Kevin, do you have anything against this? Frankly speaking, I was kind of thinking it's been somehow implemented already because otherwise checking the results of da8xx_pinmux_setup() and davinci_cfg_reg() doesn't make much sense... > It can be done the same way for DA830/DA850. > No, I don't at all think this is a good idea -- at least not for DA830 EVM... > Thanks, > Sekhar > WBR, Sergei
On Tue, Sep 22, 2009 at 18:35:12, Sergei Shtylyov wrote: > Hello. > > Chaithrika U S wrote: > > > DA850/OMAP-L138 EVM has a RMII Ethernet PHY on the UI daughter card. The PHY > > is enabled by proper programming of the IO Expander (TCA6416) ports. Also for > > RMII PHY to work, the MDIO clock of MII PHY has to be disabled since both the > > PHYs have the same address. This is done via the GPIO2[6] pin. This patch adds > > support for RMII PHY. > > > > This patch also adds a menuconfig option to select UI card and peripherals > > present on it. Currently, the only sub-option in this menu is RMII. > > This menuconfig option is similar to the one present for UI card on > > DA830/OMAP-L137 EVM. > > > > Signed-off-by: Chaithrika U S <chaithrika@ti.com> > > [...] > > > diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig > > index 7b6dddf..4ee61cc 100644 > > --- a/arch/arm/mach-davinci/Kconfig > > +++ b/arch/arm/mach-davinci/Kconfig > > @@ -129,6 +129,32 @@ config MACH_DAVINCI_DA850_EVM > > help > > Say Y here to select the TI DA850/OMAP-L138 Evaluation Module. > > > > +config DA850_UI > > + bool "DA850/OMAP-L138 UI (User Interface) board support" > > + depends on MACH_DAVINCI_DA850_EVM > > + help > > + Say Y here if you have the DA850/OMAP-L138 UI > > + (User Interface) board installed and you want to > > + enable the peripherals located on User Interface > > + board. > > + > > +choice > > + prompt "Select DA850/OMAP-L138 UI board peripheral" > > + depends on DA850_UI > > Are the devices on the UI board really mutually exclusive? > Yes, the devices are mutually exclusive. > > + > > +config DA850_UI_RMII > > + bool "RMII Ethernet PHY" > > + help > > + Say Y if you want to use the RMII PHY on the DA850/OMAP-L138 EVM. > > + This PHY is found on the UI daughter card that is supplied with > > + the EVM. > > + NOTE: Please take care while choosing this option, MII PHY will > > + not be functional if RMII mode is selected. This also affects > > + the operation of video devices as they are pin multiplexed with > > + RMII pins. > > Perhaps it's worth printing out a message about this when DA850_UI_RMII > is enabled? > OK. > > diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c > > index 25ae007..43cc629 100644 > > --- a/arch/arm/mach-davinci/board-da850-evm.c > > +++ b/arch/arm/mach-davinci/board-da850-evm.c > [...] > > @@ -43,6 +44,8 @@ > > #define DA850_MMCSD_CD_PIN GPIO_TO_PIN(4, 0) > > #define DA850_MMCSD_WP_PIN GPIO_TO_PIN(4, 1) > > > > +#define DA850_MII_MDIO_CLKEN_PIN GPIO_TO_PIN(2, 6) > > + > > static struct mtd_partition da850_evm_norflash_partition[] = { > > { > > .name = "NOR filesystem", > > @@ -270,11 +273,141 @@ static const short da850_evm_lcdc_pins[] = { > > -1 > > }; > > > > +#ifdef CONFIG_DA850_UI > > +static int da850_evm_ui_expander_setup(struct i2c_client *client, unsigned gpio, > > + unsigned ngpio, void *c) > > +{ > > + struct davinci_soc_info *soc_info = &davinci_soc_info; > > + int sel_a, sel_b, sel_c, ret; > > + > > + sel_a = gpio + 7; > > + sel_b = gpio + 6; > > + sel_c = gpio + 5; > > + > > + ret = gpio_request(sel_a, "sel_a"); > > + if (ret) { > > + pr_warning("Cannot open UI expander pin %d\n", sel_a); > > + goto exp_setup_sela_fail; > > + } > > + > > + ret = gpio_request(sel_b, "sel_b"); > > + if (ret) { > > + pr_warning("Cannot open UI expander pin %d\n", sel_b); > > + goto exp_setup_selb_fail; > > + } > > + > > + ret = gpio_request(sel_c, "sel_c"); > > + if (ret) { > > + pr_warning("Cannot open UI expander pin %d\n", sel_c); > > + goto exp_setup_selc_fail; > > + } > > + > > + /* deselect all fucntionalities */ > > + gpio_direction_output(sel_a, 1); > > + gpio_direction_output(sel_b, 1); > > + gpio_direction_output(sel_c, 1); > > + > > + if (soc_info->emac_pdata->rmii_en) > > + /* enable RMII */ > > + gpio_direction_output(sel_a, 0); > > gpio_set_value() is enough. > > > +static int da850_evm_ui_expander_teardown(struct i2c_client *client, > > + unsigned gpio, unsigned ngpio, void *c) > > +{ > > + /* deselect all fucntionalities */ > > Functionalities. :-) > > > +static int __init da850_evm_config_emac(u8 rmii_en) > > +{ > > + void __iomem *cfg_chip3_base; > > + int ret; > > + u32 val; > > + > > + cfg_chip3_base = DA8XX_SYSCFG_VIRT(DA8XX_CFGCHIP3_REG); > > + > > + /* configure the CFGCHIP3 register for RMII or MII */ > > + val = __raw_readl(cfg_chip3_base); > > + if (rmii_en) > > + val |= BIT(8); > > + else > > + val &= ~BIT(8); > > + > > + __raw_writel(val, cfg_chip3_base); > > + > > + if (!rmii_en) > > + ret = da8xx_pinmux_setup(da850_cpgmac_pins); > > + else > > + ret = da8xx_pinmux_setup(da850_rmii_pins); > > + if (ret) > > + pr_warning("da850_evm_init: cpgmac/rmii mux setup failed: %d\n", > > + ret); > > + > > + if (rmii_en) { > > + /* Disable MII MDIO clock */ > > + ret = davinci_cfg_reg(DA850_GPIO2_6); > > + if (ret) > > + pr_warning("da850_evm_init:GPIO(2,6) mux setup " > > + "failed\n"); > > + > > + ret = gpio_request(DA850_MII_MDIO_CLKEN_PIN, "mdio_clk_en"); > > + if (ret) { > > + pr_warning("Cannot open GPIO %d\n", > > + DA850_MII_MDIO_CLKEN_PIN); > > + return ret; > > + } > > + > > + gpio_direction_output(DA850_MII_MDIO_CLKEN_PIN, 1); > > + } > > I guess you need to request GPIO2[6] anyway (and then set it to 0) also > in case when rmii_en is 0... > > WBR, Sergei > Will post an updated patch soon. Regards, Chaithrika
On Wed, Sep 23, 2009 at 02:10:13, Sergei Shtylyov wrote: > Hello. > > Nori, Sekhar wrote: > > >>> is enabled by proper programming of the IO Expander (TCA6416) ports. Also for > >>> RMII PHY to work, the MDIO clock of MII PHY has to be disabled since both the > >>> PHYs have the same address. This is done via the GPIO2[6] pin. This patch adds > >>> support for RMII PHY. > >>> > >>> This patch also adds a menuconfig option to select UI card and peripherals > >>> present on it. Currently, the only sub-option in this menu is RMII. > >>> This menuconfig option is similar to the one present for UI card on > >>> DA830/OMAP-L137 EVM. > >>> > >>> Signed-off-by: Chaithrika U S <chaithrika@ti.com> > >>> > >> [...] > >> > >>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig > >>> index 7b6dddf..4ee61cc 100644 > >>> --- a/arch/arm/mach-davinci/Kconfig > >>> +++ b/arch/arm/mach-davinci/Kconfig > >>> @@ -129,6 +129,32 @@ config MACH_DAVINCI_DA850_EVM > >>> help > >>> Say Y here to select the TI DA850/OMAP-L138 Evaluation Module. > >>> > >>> +config DA850_UI > >>> + bool "DA850/OMAP-L138 UI (User Interface) board support" > >>> + depends on MACH_DAVINCI_DA850_EVM > >>> + help > >>> + Say Y here if you have the DA850/OMAP-L138 UI > >>> + (User Interface) board installed and you want to > >>> + enable the peripherals located on User Interface > >>> + board. > >>> + > >>> +choice > >>> + prompt "Select DA850/OMAP-L138 UI board peripheral" > >>> + depends on DA850_UI > >>> > >> Are the devices on the UI board really mutually exclusive? > >> > > > > What is the purpose of the UI board configuration? Is it just to > > provide one place where all UI board peripherals can be disabled? > > > > In case of DA830 EVM, it's a place where the UI board support can be > disabled -- you can't do that with the 'choice' statement which would > alwys select at least one item. But it's not only that. The board has > the GPIO expander which we need not support (and setup) if the board is > absent. It was not clear to me where the TCA6414 GPIO expander is > situated on DA850 EVM -- on the board itself or on the UI daughter board... > TCA6416 is present on the UI card for DA850/OMAP-L138 EVM. Regards, Chaithrika
On Wed, Sep 23, 2009 at 02:10:13, Sergei Shtylyov wrote: > Hello. > > Nori, Sekhar wrote: > > >>> is enabled by proper programming of the IO Expander (TCA6416) ports. Also for > >>> RMII PHY to work, the MDIO clock of MII PHY has to be disabled since both the > >>> PHYs have the same address. This is done via the GPIO2[6] pin. This patch adds > >>> support for RMII PHY. > >>> > >>> This patch also adds a menuconfig option to select UI card and peripherals > >>> present on it. Currently, the only sub-option in this menu is RMII. > >>> This menuconfig option is similar to the one present for UI card on > >>> DA830/OMAP-L137 EVM. > >>> > >>> Signed-off-by: Chaithrika U S <chaithrika@ti.com> > >>> > >> [...] > >> > >>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig > >>> index 7b6dddf..4ee61cc 100644 > >>> --- a/arch/arm/mach-davinci/Kconfig > >>> +++ b/arch/arm/mach-davinci/Kconfig > >>> @@ -129,6 +129,32 @@ config MACH_DAVINCI_DA850_EVM > >>> help > >>> Say Y here to select the TI DA850/OMAP-L138 Evaluation Module. > >>> > >>> +config DA850_UI > >>> + bool "DA850/OMAP-L138 UI (User Interface) board support" > >>> + depends on MACH_DAVINCI_DA850_EVM > >>> + help > >>> + Say Y here if you have the DA850/OMAP-L138 UI > >>> + (User Interface) board installed and you want to > >>> + enable the peripherals located on User Interface > >>> + board. > >>> + > >>> +choice > >>> + prompt "Select DA850/OMAP-L138 UI board peripheral" > >>> + depends on DA850_UI > >>> > >> Are the devices on the UI board really mutually exclusive? > >> > > > > What is the purpose of the UI board configuration? Is it just to > > provide one place where all UI board peripherals can be disabled? > > > > In case of DA830 EVM, it's a place where the UI board support can be > disabled -- you can't do that with the 'choice' statement which would > alwys select at least one item. But it's not only that. The board has > the GPIO expander which we need not support (and setup) if the board is > absent. It was not clear to me where the TCA6414 GPIO expander is > situated on DA850 EVM -- on the board itself or on the UI daughter board... On DA830, you can link working on the expander to selection of NAND/NOR/LCD/MMC MMC/SD is an example where expander operation affects peripherals on baseboard. You want to drive the mux_mode low when MMC/SD is selected. I don't see that happening in the current code though. It will be interesting to see if expander access can bail out gracefully if UI card is not connected. In which case there is no real need to protect expander access with DA830_UI > > > Each of the modules already have a menuconfig item. > > Not just a 'config' item currently but a 'choice' which always > selects *one* item. You can't select "none" without another option. Having a separate UI menu confuses because now there are two selections to be made when selecting an LCD for example. Once in the FB menu and once in the ARCH menu. People generally tend to miss out on the ARCH menu. > > > Drivers (at least NAND and NOR) can bail out if they can't detect the device. > > On DA830 EVM NAND and NOR flashes use AEMIF resources (paticularly > CE3 signal, IIRC) in an incompatible way, so you can only have one of > them enabled at a time; there's no PinMux conflict between NAND and NOR > as they both use the AEMIF module -- hence was the use of the 'choice' > to select between NAND, NOR and LCD support. Right, conflicts could be other kind.. > > > Most of the choice on the UI card arises from SoC pinmux limitations. > > Not really... > > > Other boards are handling this using warnings printed at boot-time. > > Frankly speaking, I don't at all find those warnings appealing. I > would have preferred something more smart but it was decided against > "overloading" clk_enable() with the PinMux conflict resolution. We still > could teach davinci_cfg_reg() to check for the conflicts as it can > return error. Mark, Steve, are there any plans to do that; Kevin, do you > have anything against this? Frankly speaking, I was kind of thinking > it's been somehow implemented already because otherwise checking the > results of da8xx_pinmux_setup() and davinci_cfg_reg() doesn't make much > sense... > > > It can be done the same way for DA830/DA850. > > > > No, I don't at all think this is a good idea -- at least not for > DA830 EVM... I think it is better not to create an exception for DA830/DA850. At least it will make it easy for the guy changing the conflict resolution mechanism. He wont have to think differently when changing DA8xx code. Thanks, Sekhar
Hello. Nori, Sekhar wrote: >>>>> is enabled by proper programming of the IO Expander (TCA6416) ports. Also for >>>>> RMII PHY to work, the MDIO clock of MII PHY has to be disabled since both the >>>>> PHYs have the same address. This is done via the GPIO2[6] pin. This patch adds >>>>> support for RMII PHY. >>>>> >>>>> This patch also adds a menuconfig option to select UI card and peripherals >>>>> present on it. Currently, the only sub-option in this menu is RMII. >>>>> This menuconfig option is similar to the one present for UI card on >>>>> DA830/OMAP-L137 EVM. >>>>> >>>>> Signed-off-by: Chaithrika U S <chaithrika@ti.com> >>>>> >>>>> >>>> [...] >>>> >>>> >>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig >>>>> index 7b6dddf..4ee61cc 100644 >>>>> --- a/arch/arm/mach-davinci/Kconfig >>>>> +++ b/arch/arm/mach-davinci/Kconfig >>>>> @@ -129,6 +129,32 @@ config MACH_DAVINCI_DA850_EVM >>>>> help >>>>> Say Y here to select the TI DA850/OMAP-L138 Evaluation Module. >>>>> >>>>> +config DA850_UI >>>>> + bool "DA850/OMAP-L138 UI (User Interface) board support" >>>>> + depends on MACH_DAVINCI_DA850_EVM >>>>> + help >>>>> + Say Y here if you have the DA850/OMAP-L138 UI >>>>> + (User Interface) board installed and you want to >>>>> + enable the peripherals located on User Interface >>>>> + board. >>>>> + >>>>> +choice >>>>> + prompt "Select DA850/OMAP-L138 UI board peripheral" >>>>> + depends on DA850_UI >>>>> >>>>> >>>> Are the devices on the UI board really mutually exclusive? >>>> >>>> >>> What is the purpose of the UI board configuration? Is it just to >>> provide one place where all UI board peripherals can be disabled? >>> >>> >> In case of DA830 EVM, it's a place where the UI board support can be >> disabled -- you can't do that with the 'choice' statement which would >> alwys select at least one item. But it's not only that. The board has >> the GPIO expander which we need not support (and setup) if the board is >> absent. It was not clear to me where the TCA6414 GPIO expander is >> situated on DA850 EVM -- on the board itself or on the UI daughter board... >> > > On DA830, you can link working on the expander to selection of NAND/NOR/LCD/MMC > MMC resides on EVM board itself, while the expander resides on the UI board. You only need to touch the expander if the UI board is plugged in. > MMC/SD is an example where expander operation affects peripherals on > baseboard. You want to drive the mux_mode low when MMC/SD is selected. > Then you can't have neither NAND nor NOR caches. You must select LCD in this case. We can add a help text about it. I'd prefer not to add more #ifdef-driven messages as we could use da8xx_pinmux_setup()'s ability to return error to check for the PinMux reservation conflict. > I don't see that happening in the current code though. > > It will be interesting to see if expander access can bail out gracefully > if UI card is not connected. If I remember correctly (maybe not), there will be error message from the I2C driver about a timeout in this case. > In which case there is no real need to protect expander access with DA830_UI > > >>> Each of the modules already have a menuconfig item. >>> >> Not just a 'config' item currently but a 'choice' which always >> selects *one* item. You can't select "none" without another option. >> > > Having a separate UI menu confuses because now there are two selections > to be made when selecting an LCD for example. Once in the FB menu and > once in the ARCH menu. People generally tend to miss out on the ARCH menu. > Unfortunately, I don't see what can be done about this. Having things depend on the drivers configured instead doesn't solve the issue because you can have both LCD and NAND/NOR drivers enabled, and you can have both NAND and NOR drivers enabled -- despite you can't have both NAND and NOR platform devices at once (due to the AEMIF usage conflict); that approach would only entail more ugly #ifdef'ery. The 'choice' was introduced for that exact reason -- to be able to select only one of LCD/NAND/NOR. >>> Drivers (at least NAND and NOR) can bail out if they can't detect the device. >>> >> On DA830 EVM NAND and NOR flashes use AEMIF resources (paticularly >> CE3 signal, IIRC) in an incompatible way, so you can only have one of >> them enabled at a time; there's no PinMux conflict between NAND and NOR >> as they both use the AEMIF module -- hence was the use of the 'choice' >> to select between NAND, NOR and LCD support. >> > > Right, conflicts could be other kind.. > > >>> Most of the choice on the UI card arises from SoC pinmux limitations. >>> >> Not really... >> >> >>> Other boards are handling this using warnings printed at boot-time. >>> >> Frankly speaking, I don't at all find those warnings appealing. I >> would have preferred something more smart but it was decided against >> "overloading" clk_enable() with the PinMux conflict resolution. We still >> could teach davinci_cfg_reg() to check for the conflicts as it can >> return error. Mark, Steve, are there any plans to do that; Kevin, do you >> have anything against this? Frankly speaking, I was kind of thinking >> it's been somehow implemented already because otherwise checking the >> results of da8xx_pinmux_setup() and davinci_cfg_reg() doesn't make much >> sense... >> >> >>> It can be done the same way for DA830/DA850. >>> >>> >> No, I don't at all think this is a good idea -- at least not for >> DA830 EVM... >> > > I think it is better not to create an exception for DA830/DA850. At least > it will make it easy for the guy changing the conflict resolution mechanism. > I don't think I undestand you... > He wont have to think differently when changing DA8xx code. > I think instead we really should move away from the #ifdef-driven warning messages to something more intelligent. That approach scales badly. > Thanks, > Sekhar WBR, Sergei
On Thu, Sep 24, 2009 at 01:56:44, Sergei Shtylyov wrote: > Hello. > > Nori, Sekhar wrote: > > >>>>> is enabled by proper programming of the IO Expander (TCA6416) ports. Also for > >>>>> RMII PHY to work, the MDIO clock of MII PHY has to be disabled since both the > >>>>> PHYs have the same address. This is done via the GPIO2[6] pin. This patch adds > >>>>> support for RMII PHY. > >>>>> > >>>>> This patch also adds a menuconfig option to select UI card and peripherals > >>>>> present on it. Currently, the only sub-option in this menu is RMII. > >>>>> This menuconfig option is similar to the one present for UI card on > >>>>> DA830/OMAP-L137 EVM. > >>>>> > >>>>> Signed-off-by: Chaithrika U S <chaithrika@ti.com> > >>>>> > >>>>> > >>>> [...] > >>>> > >>>> > >>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig > >>>>> index 7b6dddf..4ee61cc 100644 > >>>>> --- a/arch/arm/mach-davinci/Kconfig > >>>>> +++ b/arch/arm/mach-davinci/Kconfig > >>>>> @@ -129,6 +129,32 @@ config MACH_DAVINCI_DA850_EVM > >>>>> help > >>>>> Say Y here to select the TI DA850/OMAP-L138 Evaluation Module. > >>>>> > >>>>> +config DA850_UI > >>>>> + bool "DA850/OMAP-L138 UI (User Interface) board support" > >>>>> + depends on MACH_DAVINCI_DA850_EVM > >>>>> + help > >>>>> + Say Y here if you have the DA850/OMAP-L138 UI > >>>>> + (User Interface) board installed and you want to > >>>>> + enable the peripherals located on User Interface > >>>>> + board. > >>>>> + > >>>>> +choice > >>>>> + prompt "Select DA850/OMAP-L138 UI board peripheral" > >>>>> + depends on DA850_UI > >>>>> > >>>>> > >>>> Are the devices on the UI board really mutually exclusive? > >>>> > >>>> > >>> What is the purpose of the UI board configuration? Is it just to > >>> provide one place where all UI board peripherals can be disabled? > >>> > >>> > >> In case of DA830 EVM, it's a place where the UI board support can be > >> disabled -- you can't do that with the 'choice' statement which would > >> alwys select at least one item. But it's not only that. The board has > >> the GPIO expander which we need not support (and setup) if the board is > >> absent. It was not clear to me where the TCA6414 GPIO expander is > >> situated on DA850 EVM -- on the board itself or on the UI daughter board... > >> > > > > On DA830, you can link working on the expander to selection of NAND/NOR/LCD/MMC > > > > MMC resides on EVM board itself, while the expander resides on the UI > board. You only need to touch the expander if the UI board is plugged in. > > > MMC/SD is an example where expander operation affects peripherals on > > baseboard. You want to drive the mux_mode low when MMC/SD is selected. > > > > Then you can't have neither NAND nor NOR caches. You must select LCD > in this case. We can add a help text about it. Irrespective of the help, choosing LCD on UI card to get the MMC/SD on baseboard working is not intuitive. > I'd prefer not to add more #ifdef-driven messages as we could use > da8xx_pinmux_setup()'s ability to return error to check for the PinMux > reservation conflict. Pinmux conflict detection is useful and possible on all SoCs, not just DA8xx. But, as we discussed earlier, not all conflicts are pinmux related. > > > I don't see that happening in the current code though. > > > > It will be interesting to see if expander access can bail out gracefully > > if UI card is not connected. > > If I remember correctly (maybe not), there will be error message from > the I2C driver about a timeout in this case. Fast expander access bailout will be really useful; I will check it when I am done with the current patch I am working on. Thanks, Sekhar
Hello. Nori, Sekhar wrote: >>>>>>> RMII PHY to work, the MDIO clock of MII PHY has to be disabled since both the >>>>>>> PHYs have the same address. This is done via the GPIO2[6] pin. This patch adds >>>>>>> support for RMII PHY. >>>>>>> >>>>>>> This patch also adds a menuconfig option to select UI card and peripherals >>>>>>> present on it. Currently, the only sub-option in this menu is RMII. >>>>>>> This menuconfig option is similar to the one present for UI card on >>>>>>> DA830/OMAP-L137 EVM. >>>>>>> >>>>>>> Signed-off-by: Chaithrika U S <chaithrika@ti.com> >>>>>>> >>>>>> [...] >>>>>> >>>>>> >>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig >>>>>>> index 7b6dddf..4ee61cc 100644 >>>>>>> --- a/arch/arm/mach-davinci/Kconfig >>>>>>> +++ b/arch/arm/mach-davinci/Kconfig >>>>>>> @@ -129,6 +129,32 @@ config MACH_DAVINCI_DA850_EVM >>>>>>> help >>>>>>> Say Y here to select the TI DA850/OMAP-L138 Evaluation Module. >>>>>>> >>>>>>> +config DA850_UI >>>>>>> + bool "DA850/OMAP-L138 UI (User Interface) board support" >>>>>>> + depends on MACH_DAVINCI_DA850_EVM >>>>>>> + help >>>>>>> + Say Y here if you have the DA850/OMAP-L138 UI >>>>>>> + (User Interface) board installed and you want to >>>>>>> + enable the peripherals located on User Interface >>>>>>> + board. >>>>>>> + >>>>>>> +choice >>>>>>> + prompt "Select DA850/OMAP-L138 UI board peripheral" >>>>>>> + depends on DA850_UI >>>>>>> >>>>>>> >>>>>>> >>>>>> Are the devices on the UI board really mutually exclusive? >>>>>> >>>>> What is the purpose of the UI board configuration? Is it just to >>>>> provide one place where all UI board peripherals can be disabled? >>>>> >>>> In case of DA830 EVM, it's a place where the UI board support can be >>>> disabled -- you can't do that with the 'choice' statement which would >>>> alwys select at least one item. But it's not only that. The board has >>>> the GPIO expander which we need not support (and setup) if the board is >>>> absent. It was not clear to me where the TCA6414 GPIO expander is >>>> situated on DA850 EVM -- on the board itself or on the UI daughter board... >>>> >>>> >>> On DA830, you can link working on the expander to selection of NAND/NOR/LCD/MMC >>> >> MMC resides on EVM board itself, while the expander resides on the UI >> board. You only need to touch the expander if the UI board is plugged in. >> >> >>> MMC/SD is an example where expander operation affects peripherals on >>> baseboard. You want to drive the mux_mode low when MMC/SD is selected. >>> >> Then you can't have neither NAND nor NOR caches. You must select LCD >> in this case. We can add a help text about it. >> > > Irrespective of the help, choosing LCD on UI card to get the MMC/SD on > baseboard working is not intuitive. > Well, it isn't. Could add a message in the NAND specific code for the time being... >> I'd prefer not to add more #ifdef-driven messages as we could use >> da8xx_pinmux_setup()'s ability to return error to check for the PinMux >> reservation conflict. >> > > Pinmux conflict detection is useful and possible on all SoCs, not just > DA8xx. Sure. da8xx_pinmux_setup() is just badly named, it actually would work on DaVincis, as well as davinci_cfg_reg()... > But, as we discussed earlier, not all conflicts are pinmux related. > Well, at least in this case, the conflict between AEMIF and MMC0 *is* PinMux related. >>> I don't see that happening in the current code though. >>> >>> It will be interesting to see if expander access can bail out gracefully >>> if UI card is not connected. >>> >> If I remember correctly (maybe not), there will be error message from >> the I2C driver about a timeout in this case. >> Although I may misremember: we certainly had such message from I2C1 due to its pins being disabled... WBR, Sergei
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig index 7b6dddf..4ee61cc 100644 --- a/arch/arm/mach-davinci/Kconfig +++ b/arch/arm/mach-davinci/Kconfig @@ -129,6 +129,32 @@ config MACH_DAVINCI_DA850_EVM help Say Y here to select the TI DA850/OMAP-L138 Evaluation Module. +config DA850_UI + bool "DA850/OMAP-L138 UI (User Interface) board support" + depends on MACH_DAVINCI_DA850_EVM + help + Say Y here if you have the DA850/OMAP-L138 UI + (User Interface) board installed and you want to + enable the peripherals located on User Interface + board. + +choice + prompt "Select DA850/OMAP-L138 UI board peripheral" + depends on DA850_UI + +config DA850_UI_RMII + bool "RMII Ethernet PHY" + help + Say Y if you want to use the RMII PHY on the DA850/OMAP-L138 EVM. + This PHY is found on the UI daughter card that is supplied with + the EVM. + NOTE: Please take care while choosing this option, MII PHY will + not be functional if RMII mode is selected. This also affects + the operation of video devices as they are pin multiplexed with + RMII pins. + +endchoice + config DAVINCI_MUX bool "DAVINCI multiplexing support" depends on ARCH_DAVINCI diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index 25ae007..43cc629 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -17,6 +17,7 @@ #include <linux/console.h> #include <linux/i2c.h> #include <linux/i2c/at24.h> +#include <linux/i2c/pca953x.h> #include <linux/gpio.h> #include <linux/platform_device.h> #include <linux/mtd/mtd.h> @@ -43,6 +44,8 @@ #define DA850_MMCSD_CD_PIN GPIO_TO_PIN(4, 0) #define DA850_MMCSD_WP_PIN GPIO_TO_PIN(4, 1) +#define DA850_MII_MDIO_CLKEN_PIN GPIO_TO_PIN(2, 6) + static struct mtd_partition da850_evm_norflash_partition[] = { { .name = "NOR filesystem", @@ -270,11 +273,141 @@ static const short da850_evm_lcdc_pins[] = { -1 }; +#ifdef CONFIG_DA850_UI +static int da850_evm_ui_expander_setup(struct i2c_client *client, unsigned gpio, + unsigned ngpio, void *c) +{ + struct davinci_soc_info *soc_info = &davinci_soc_info; + int sel_a, sel_b, sel_c, ret; + + sel_a = gpio + 7; + sel_b = gpio + 6; + sel_c = gpio + 5; + + ret = gpio_request(sel_a, "sel_a"); + if (ret) { + pr_warning("Cannot open UI expander pin %d\n", sel_a); + goto exp_setup_sela_fail; + } + + ret = gpio_request(sel_b, "sel_b"); + if (ret) { + pr_warning("Cannot open UI expander pin %d\n", sel_b); + goto exp_setup_selb_fail; + } + + ret = gpio_request(sel_c, "sel_c"); + if (ret) { + pr_warning("Cannot open UI expander pin %d\n", sel_c); + goto exp_setup_selc_fail; + } + + /* deselect all fucntionalities */ + gpio_direction_output(sel_a, 1); + gpio_direction_output(sel_b, 1); + gpio_direction_output(sel_c, 1); + + if (soc_info->emac_pdata->rmii_en) + /* enable RMII */ + gpio_direction_output(sel_a, 0); + + return 0; + +exp_setup_selc_fail: + gpio_free(sel_b); +exp_setup_selb_fail: + gpio_free(sel_a); +exp_setup_sela_fail: + return ret; +} + +static int da850_evm_ui_expander_teardown(struct i2c_client *client, + unsigned gpio, unsigned ngpio, void *c) +{ + /* deselect all fucntionalities */ + gpio_direction_output(gpio + 5, 1); + gpio_direction_output(gpio + 6, 1); + gpio_direction_output(gpio + 7, 1); + + gpio_free(gpio + 5); + gpio_free(gpio + 6); + gpio_free(gpio + 7); + + return 0; +} + +static struct pca953x_platform_data da850_evm_ui_expander_info = { + .gpio_base = DAVINCI_N_GPIO, + .setup = da850_evm_ui_expander_setup, + .teardown = da850_evm_ui_expander_teardown, +}; +#endif + +static struct i2c_board_info __initdata i2c_info[] = { +#ifdef CONFIG_DA850_UI + { + I2C_BOARD_INFO("tca6416", 0x20), + .platform_data = &da850_evm_ui_expander_info, + }, +#endif +}; + +static int __init da850_evm_config_emac(u8 rmii_en) +{ + void __iomem *cfg_chip3_base; + int ret; + u32 val; + + cfg_chip3_base = DA8XX_SYSCFG_VIRT(DA8XX_CFGCHIP3_REG); + + /* configure the CFGCHIP3 register for RMII or MII */ + val = __raw_readl(cfg_chip3_base); + if (rmii_en) + val |= BIT(8); + else + val &= ~BIT(8); + + __raw_writel(val, cfg_chip3_base); + + if (!rmii_en) + ret = da8xx_pinmux_setup(da850_cpgmac_pins); + else + ret = da8xx_pinmux_setup(da850_rmii_pins); + if (ret) + pr_warning("da850_evm_init: cpgmac/rmii mux setup failed: %d\n", + ret); + + if (rmii_en) { + /* Disable MII MDIO clock */ + ret = davinci_cfg_reg(DA850_GPIO2_6); + if (ret) + pr_warning("da850_evm_init:GPIO(2,6) mux setup " + "failed\n"); + + ret = gpio_request(DA850_MII_MDIO_CLKEN_PIN, "mdio_clk_en"); + if (ret) { + pr_warning("Cannot open GPIO %d\n", + DA850_MII_MDIO_CLKEN_PIN); + return ret; + } + + gpio_direction_output(DA850_MII_MDIO_CLKEN_PIN, 1); + } + + return 0; +} + static __init void da850_evm_init(void) { struct davinci_soc_info *soc_info = &davinci_soc_info; int ret; +#ifdef CONFIG_DA850_UI_RMII + soc_info->emac_pdata->rmii_en = 1; +#else + soc_info->emac_pdata->rmii_en = 0; +#endif + ret = da8xx_pinmux_setup(da850_nand_pins); if (ret) pr_warning("da850_evm_init: nand mux setup failed: %d\n", @@ -295,6 +428,7 @@ static __init void da850_evm_init(void) pr_warning("da850_evm_init: edma registration failed: %d\n", ret); + i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info)); ret = da8xx_pinmux_setup(da850_i2c0_pins); if (ret) pr_warning("da850_evm_init: i2c0 mux setup failed: %d\n", @@ -307,12 +441,9 @@ static __init void da850_evm_init(void) soc_info->emac_pdata->phy_mask = DA850_EVM_PHY_MASK; soc_info->emac_pdata->mdio_max_freq = DA850_EVM_MDIO_FREQUENCY; - soc_info->emac_pdata->rmii_en = 0; - - ret = da8xx_pinmux_setup(da850_cpgmac_pins); + ret = da850_evm_config_emac(soc_info->emac_pdata->rmii_en); if (ret) - pr_warning("da850_evm_init: cpgmac mux setup failed: %d\n", - ret); + pr_warning("da850_evm_init: emac setup failed: %d\n", ret); ret = da8xx_register_emac(); if (ret) diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c index a62863c..da20b4f 100644 --- a/arch/arm/mach-davinci/da850.c +++ b/arch/arm/mach-davinci/da850.c @@ -411,6 +411,14 @@ static const struct mux_config da850_pins[] = { MUX_CFG(DA850, MII_RXD_0, 3, 28, 15, 8, false) MUX_CFG(DA850, MDIO_CLK, 4, 0, 15, 8, false) MUX_CFG(DA850, MDIO_D, 4, 4, 15, 8, false) + MUX_CFG(DA850, RMII_TXD_0, 14, 12, 15, 8, false) + MUX_CFG(DA850, RMII_TXD_1, 14, 8, 15, 8, false) + MUX_CFG(DA850, RMII_TXEN, 14, 16, 15, 8, false) + MUX_CFG(DA850, RMII_CRS_DV, 15, 4, 15, 8, false) + MUX_CFG(DA850, RMII_RXD_0, 14, 24, 15, 8, false) + MUX_CFG(DA850, RMII_RXD_1, 14, 20, 15, 8, false) + MUX_CFG(DA850, RMII_RXER, 14, 28, 15, 8, false) + MUX_CFG(DA850, RMII_MHZ_50_CLK, 15, 0, 15, 0, false) /* McASP function */ MUX_CFG(DA850, ACLKR, 0, 0, 15, 1, false) MUX_CFG(DA850, ACLKX, 0, 4, 15, 1, false) @@ -513,6 +521,7 @@ 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_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, GPIO4_0, 10, 28, 15, 8, false) @@ -554,6 +563,14 @@ const short da850_cpgmac_pins[] __initdata = { -1 }; +const short da850_rmii_pins[] __initdata = { + DA850_RMII_TXD_0, DA850_RMII_TXD_1, DA850_RMII_TXEN, + DA850_RMII_CRS_DV, DA850_RMII_RXD_0, DA850_RMII_RXD_1, + DA850_RMII_RXER, DA850_RMII_MHZ_50_CLK, DA850_MDIO_CLK, + DA850_MDIO_D, + -1 +}; + const short da850_mcasp_pins[] __initdata = { DA850_AHCLKX, DA850_ACLKX, DA850_AFSX, DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE, diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h index a152261..d79b814 100644 --- a/arch/arm/mach-davinci/include/mach/da8xx.h +++ b/arch/arm/mach-davinci/include/mach/da8xx.h @@ -119,6 +119,7 @@ extern const short da850_uart2_pins[]; extern const short da850_i2c0_pins[]; extern const short da850_i2c1_pins[]; extern const short da850_cpgmac_pins[]; +extern const short da850_rmii_pins[]; extern const short da850_mcasp_pins[]; extern const short da850_lcdcntl_pins[]; extern const short da850_mmcsd0_pins[]; diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h index fc8eb16..4854065 100644 --- a/arch/arm/mach-davinci/include/mach/mux.h +++ b/arch/arm/mach-davinci/include/mach/mux.h @@ -765,6 +765,14 @@ enum davinci_da850_index { DA850_MII_RXD_0, DA850_MDIO_CLK, DA850_MDIO_D, + DA850_RMII_TXD_0, + DA850_RMII_TXD_1, + DA850_RMII_TXEN, + DA850_RMII_CRS_DV, + DA850_RMII_RXD_0, + DA850_RMII_RXD_1, + DA850_RMII_RXER, + DA850_RMII_MHZ_50_CLK, /* McASP function */ DA850_ACLKR, @@ -872,6 +880,7 @@ enum davinci_da850_index { DA850_NEMA_CS_2, /* GPIO function */ + DA850_GPIO2_6, DA850_GPIO2_8, DA850_GPIO2_15, DA850_GPIO4_0,
DA850/OMAP-L138 EVM has a RMII Ethernet PHY on the UI daughter card. The PHY is enabled by proper programming of the IO Expander (TCA6416) ports. Also for RMII PHY to work, the MDIO clock of MII PHY has to be disabled since both the PHYs have the same address. This is done via the GPIO2[6] pin. This patch adds support for RMII PHY. This patch also adds a menuconfig option to select UI card and peripherals present on it. Currently, the only sub-option in this menu is RMII. This menuconfig option is similar to the one present for UI card on DA830/OMAP-L137 EVM. Signed-off-by: Chaithrika U S <chaithrika@ti.com> --- arch/arm/mach-davinci/Kconfig | 26 +++++ arch/arm/mach-davinci/board-da850-evm.c | 141 +++++++++++++++++++++++++++- arch/arm/mach-davinci/da850.c | 17 ++++ arch/arm/mach-davinci/include/mach/da8xx.h | 1 + arch/arm/mach-davinci/include/mach/mux.h | 9 ++ 5 files changed, 189 insertions(+), 5 deletions(-)