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