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

H. Nikolaus Schaller hns at goldelico.com
Tue Jul 24 07:38:41 CEST 2018


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

BR,
Nikolaus


>> 
>> It shows significant signs of being working:
>> 
>> root at 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 at letux:~#
>> root at 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 at letux:~#
>> 
>> So what is there:
>> 1. registering two new mmc_host ports
>> 2. locating the mmc driver matching the phandle [currently disabled]
>> 3. capturing the mmc_request (triggered by mmc core when trying a mmc_rescan on new devices)
>> 4. 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
> -- 
> as simple and primitive as possible
> -------------------------------------------------
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
> 
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com



More information about the Letux-kernel mailing list