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 <[email protected]> > >>> > >> [...] > >> > >>> 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 _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
