[...] > A bit remark for better understanding: > > All card settings change are serialized too. These settings are applied > after slot switch before execution of new request for this slot. > > So situations like calling any host_0 ops while another host (host_1) is active > are handled by current code. > > This is example of simultaneous ops calls for both slots: > > host (slot) 0 | host (slot) 1 > ----------------------------------- > h0->set_ios() | h1->set_ios() > h0->request() | h1->request() > h0->set_ios() | h1->set_ios() > h0->request() | h1->request() > h0->request() | > h0->request() | > h0->request() | > > How it will be serialized in the mmc driver: > > h0->set_ios() // h0 settings save > h1->set_ios() // h1 settings save > h0->request() // apply settings for h0 and do request This doesn't work as it would mean violation of the specs in some scenarios. Particular during the card initialization and card power off. > ------ slot switch to h1 ------ > h1->request() // apply settings for h1 and do request Ditto. Etc... > h0->set_ios() // h0 settings save > h1->set_ios() // h1 settings save > ------ slot switch to h0 ------ > h0->request() // apply settings for h0 and do request > ------ slot switch to h1 ------ > h1->request() // apply settings for h1 and do request > ------ slot switch to h0 ------ > h0->request() // do request (no new settings to apply) > h0->request() // do request (no new settings to apply) > h0->request() // do request (no new settings to apply) > Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
