Hi Marek,
Am 24.07.2018 um 08:20 schrieb Belisko Marek marek.belisko@gmail.com:
Hi Nikolaus. On Tue, Jul 24, 2018 at 7:38 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Marek,
Am 24.07.2018 um 07:33 schrieb Belisko Marek marek.belisko@gmail.com:
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 is now rebased on latest letux-base branch (wasn't before) so that the above commit may no longer be valid:
http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work/le...
Thanks looks like I have similar output:
fine!
dmesg | grep txs [ 1.736174] txs02612 txs02612: probe [ 1.760078] txs02612 txs02612: could not get access to host port, using manual mode
this is because I return NULL when looking up the host port - because the function does not yet return the proper struct mmc_host pointer.
And it continues because the test for NULL is disabled.
[ 1.793295] txs02612_request: current=1 client=0 [ 1.819471] txs02612 txs02612: probed [ 1.823317] txs02612_request: current=0 client=1
This seems to be some mmc core trying to rescan the devices and issuing a request for each one. I guess since the code does not touch the requests they are tagged as "failed"or "unfinished" and the core does not try to identify partitions etc.
ls -l /sys/class/mmc_host total 0 lrwxrwxrwx 1 root root 0 Jan 19 21:17 mmc0 -> ../../devices/platform/44000000.ocp/480b4000.mmc/mmc_host/mmc0 lrwxrwxrwx 1 root root 0 Jan 19 21:17 mmc1 -> ../../devices/platform/txs02612/mmc_host/mmc1 lrwxrwxrwx 1 root root 0 Jan 19 21:17 mmc2 -> ../../devices/platform/txs02612/mmc_host/mmc2 lrwxrwxrwx 1 root root 0 Jan 19 21:17 mmc3 -> ../../devices/platform/44000000.ocp/4809c000.mmc/mmc_host/mmc3 lrwxrwxrwx 1 root root 0 Jan 19 21:17 mmc4 -> ../../devices/platform/44000000.ocp/480ad000.mmc/mmc_host/mmc4 lrwxrwxrwx 1 root root 0 Jan 19 21:17 mmc5 -> ../../devices/platform/44000000.ocp/480d1000.mmc/mmc_host/mmc5
I'll try to look to code to get an overview and continue.
Good!
BR, Nikolaus