[Letux-kernel] RFC sdio expander driver thoughts (TXS02612)

H. Nikolaus Schaller hns at goldelico.com
Tue Jul 24 08:32:06 CEST 2018


Hi Marek,

> Am 24.07.2018 um 08:20 schrieb Belisko Marek <marek.belisko at gmail.com>:
> 
> Hi Nikolaus.
> On Tue, Jul 24, 2018 at 7:38 AM H. Nikolaus Schaller <hns at goldelico.com> wrote:
>> 
>> Hi Marek,
>> 
>>> Am 24.07.2018 um 07:33 schrieb Belisko Marek <marek.belisko at gmail.com>:
>>> 
>>> Hi Nikolaus,
>>> On Thu, Jul 19, 2018 at 7:54 AM H. Nikolaus Schaller <hns at goldelico.com> wrote:
>>>> 
>>>> Hi Marek,
>>>> 
>>>>> Am 05.07.2018 um 14:26 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>>>> 
>>>>> Hi Ulf,
>>>>> 
>>>>>> Am 05.07.2018 um 13:55 schrieb Ulf Hansson <ulf.hansson at linaro.org>:
>>>>>> 
>>>>>> On 4 July 2018 at 14:58, H. Nikolaus Schaller <hns at 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;h=aae3f70bda7df9bab31b2a238648a09d255e8ff5;hb=dbc4f4a860b842f8b4823bea29742cc04d57dd09
>>> 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/letux-base/hns/mmc/txs02612
> 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



More information about the Letux-kernel mailing list