<div dir="ltr"><div>There are some pretty serious issues regarding the current hardware strategy of the txs02612 mmc mux and compatibility with the Linux mmc stack.  I would first like to propose disabling its functionality with the following patch and supporting just the eMMC until a viable method of handling it can be found.  The reasoning is as follows.</div><div><br></div><div>The mmc subsystem does not directly support multiplexing like other subsystems do (ie i2c).  The current strategy involves intercepting mmc request operations to the cards on the downstream side of the mux and switching the mux before calling the parent host's request op.  <br></div><div><br></div><div>Ideally the tx02612 device node would be a subnode of the root mmc host node.  However, the mmc host driver does not directly probe child nodes without first performing a handshake on the bus.  Therefore the subdriver would only be probed if a valid device was connected in the default state of the mux at the time the root host is probed.  Therefore, in order to guarantee the txs02612 driver is probed, the bootloader and kernel would need to ensure that a valid device is connected on the SDIO lines to ensure the mux driver came up.  This should work as the tx02612 driver would be registered as a card on the root host and the tx02612 driver would allocate and register two new hosts for the eMMC and uSD which would properly go through the SDIO/SD/MMC initialization procedures when they are registered.  There also may be an issue if the default card used for detection goes through the full probe procedure and is registered on the root host AND the new host.  However, since the driver even being probed in the first place relies on the default state of the GPIO set by the bootloader, this implementation seems shaky to me.</div><div><br></div><div>Another option is to register the tx02612 driver as a platform driver and link in the device_node in the dts in a method similar to the one below.  This way we can be sure the driver is always probed, regardless of the mmc handshake.<br></div><div><br></div><div>txs02612 {<br>     compatible = "ti,txs02612";<br>     select-gpio = <&gpio3 18 0>;    /* gpio3_82 soft-select */</div><div>     host = <&mmc2>;<br></div><div>     status = "disabled";<br> };</div><div><br></div><div>With this sort of link, the mmc device_node can be grabbed using 
of_parse_phandle.  However, getting the device and then mmc_host from 
this device_node is not easy since the mmc subsystem doesn't currently 
provide a method of accessing host nodes from their of_node by iterating
 through the class devices like some other subsystems provide (ie gpio, 
fpga-mgr).  So far, I have not found a viable method to access the 
linked node as we don't have access to the correct resources within the 
mmc subsystem.  This method also poses the same issue exhibted by the first method, where the card may be registered on both the root host and the newly registered host.</div><div><br></div><div>The current implementation allows for manual switching between the eMMC and uSD from userspace using a sysfs hook.  This works, but I worry about its behavior when interfacing with the mmc subsystem.  The subsystem is not aware of the switching and so this method will likely pose issues with regard to filesystem cache sync and similar.  The host is using polling to handle card detect, and so if the card disappears due to unsynchronized userland switching, it may view this as a card disconnect, even though the card is still powered.  Because of this, a number of risks are possible including improper handling of the card itself (potentially causing damage), improper or missed filesystem cache synchronization, and data corruption.<br></div><div><br></div><div>Until I or someone else can find a safe and (hopefully) graceful solution to this issue, I am proposing to simply disable the tx02612 driver and hardcode the mux to the eMMC for now with the following patch.</div><div><br></div><div>Signed-off-by: Nick Elsmore <<a href="mailto:nicholaselsmore@gmail.com">nicholaselsmore@gmail.com</a>></div><div>---</div><div><pre style="margin:0px;line-height:125%">index d59d9fd4c8af..60822100bcdf 100644
--- a/arch/arm/boot/dts/omap5-letux-cortex15-common.dtsi
+++ b/arch/arm/boot/dts/omap5-letux-cortex15-common.dtsi
@@ -248,6 +248,7 @@ mmcmux: txs02612@0 {
 
                #adress-cells = <1>;
                #size-cells = <0>;
+               status = <span style="font-style:italic">"disabled"</span>;
 
                eMMC: port@0 {
                        reg = <0>;
@@ -268,9 +269,25 @@ / { <span style="font-style:italic">/* eMMC / uSD-card */</span>
        txs02612 {
                compatible = <span style="font-style:italic">"ti,txs02612"</span>;
                select-gpio = <&gpio3 18 0>;  <span style="font-style:italic">/* gpio3_82 soft-select */</span>
+               status = <span style="font-style:italic">"disabled"</span>;
        };
 };
 
+<span style="font-style:italic">/* hardcode txs02612 mmc mux to eMMC input for now */</span>
+&gpio3 {
+       txs02612_soft_control {
+               gpio-hog;
+               gpios = <18 GPIO_ACTIVE_HIGH>;
+               output-low;
+               label = <span style="font-style:italic">"txs02612-soft-control"</span>;
+       };
+};
+
+&mmc3 { <span style="font-style:italic">/* WiFi-SDIO */</span>
+ <span style="font-style:italic">/* has been predefined for a wl1271 in ompa5-common.dtsi */</span>
+};
+
+
 &mmc3 { <span style="font-style:italic">/* WiFi-SDIO */</span>
        <span style="font-style:italic">/* has been predefined for a wl1271 in ompa5-common.dtsi */</span>
 };</pre></div></div>