Hi Nikolaus, On Thu, Jul 19, 2018 at 7:54 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Marek,
Am 05.07.2018 um 14:26 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Ulf,
Am 05.07.2018 um 13:55 schrieb Ulf Hansson ulf.hansson@linaro.org:
On 4 July 2018 at 14:58, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Ulf,
My approach would be that the driver registers two new host controllers, e.g. like mmc1 and mmc2 on the omap5.
I.e. calls in its probe function
mmc[i] = mmc_alloc_host(sizeof(struct omap_hsmmc_host), &pdev->dev); mmc[i]->ops = txs02612_ops; // other setup mmc_add_host(mmc[i]);twice for each of the two txs channels. This should create two new user-space mmc ports that receive requests and other callbacks.
It then should takes control of the real host controller to sit in the middle.
So basically we should do something like:
host_mmc = sarch_by_of_handle(...)And then make the txs02612_ops like:
txs02612_request(mmc, ...) { find out which port if(different from current) { try to get mutex throw the switch } host_mmc->request(host_mmc, ...) if(was different) release the mutex }in this case we don't need to touch mmc core and also bus locking will be done in driver. Do you think we can get some success with upstreaming by this approach?
No.
Fair enough. I hope my comments have given some answers to you.
Yes they do. We will start experimenting a little with our ideas. And then share them. Or come up with specific questions...
I have hacked something along this basic idea:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/mmc/txs02612.c...
Can you please share in which branch those changes are? It took me a while but I cannot find it ;). Thanks.
It shows significant signs of being working:
root@letux:~# dmesg|fgrep txs [ 5.938811] txs02612 txs02612: probe [ 6.080918] txs02612 txs02612: could not get access to host port, using manual mode [ 6.148614] txs02612_request: current=1 client=0 [ 6.178659] txs02612 txs02612: probed [ 6.182767] txs02612_request: current=0 client=1 root@letux:~# root@letux:~# ls -l /sys/class/mmc_host total 0 lrwxrwxrwx 1 root root 0 Jan 2 17:18 mmc0 -> ../../devices/platform/44000000.ocp/480b4000.mmc/mmc_host/mmc0 lrwxrwxrwx 1 root root 0 Jan 2 17:18 mmc1 -> ../../devices/platform/44000000.ocp/4809c000.mmc/mmc_host/mmc1 lrwxrwxrwx 1 root root 0 Jan 2 17:18 mmc2 -> ../../devices/platform/44000000.ocp/480ad000.mmc/mmc_host/mmc2 lrwxrwxrwx 1 root root 0 Jan 2 17:18 mmc3 -> ../../devices/platform/44000000.ocp/480d1000.mmc/mmc_host/mmc3 lrwxrwxrwx 1 root root 0 Jan 2 17:18 mmc4 -> ../../devices/platform/txs02612/mmc_host/mmc4 lrwxrwxrwx 1 root root 0 Jan 2 17:18 mmc5 -> ../../devices/platform/txs02612/mmc_host/mmc5 root@letux:~#
So what is there:
- registering two new mmc_host ports
- locating the mmc driver matching the phandle [currently disabled]
- capturing the mmc_request (triggered by mmc core when trying a mmc_rescan on new devices)
- switching between clients (incl. switching the gpio)
#2 isn't working perfectly yet (finds the driver but does not properly return the struct mmc_host), so it is disabled.
What I don't know is if timing, locking and concurrent processes (DMA?) are handled properly. And there is no voltage, clock and bus width switching. And the driver does not protect the mmc subsystem or users to access the omap mmc port directly.
Please comment, review, test, expand the code (I'll include this and required DTS changes in letux-4.18-rc5).
BR, Nikolaus
BR,
marek