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