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

Belisko Marek marek.belisko at gmail.com
Thu Jul 19 09:00:50 CEST 2018


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:
Cool I plan to look on this topic this week as I don't get reply from
Peter about AESS FW but I got it yesterday so I'll continue with
audio.
I'll look on your branch and check + test.
>
> http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/mmc/txs02612.c;h=aae3f70bda7df9bab31b2a238648a09d255e8ff5;hb=dbc4f4a860b842f8b4823bea29742cc04d57dd09
>
> 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).
OK will do. Thanks.
>
> 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