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

Belisko Marek marek.belisko at gmail.com
Tue Jul 24 08:20:39 CEST 2018


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:
dmesg | grep txs
[    1.736174] txs02612 txs02612: probe
[    1.760078] txs02612 txs02612: could not get access to host port,
using manual mode
[    1.793295] txs02612_request: current=1 client=0
[    1.819471] txs02612 txs02612: probed
[    1.823317] txs02612_request: current=0 client=1

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.
>
> BR,
> Nikolaus
>

BR,

marek

>
> >>
> >> 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
>


-- 
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