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