Re: RFC sdio expander driver thoughts (TXS02612)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ulf,

CC'ed pyra kernel guys

On Tue, Jul 3, 2018 at 11:23 AM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
>
> On 3 July 2018 at 08:47, Belisko Marek <marek@xxxxxxxxxxxxx> wrote:
> > Hello,
> >
> > on pyra device [0] we're using txs02612 sdio expander to have
> > possibility to connect SD card and also eMMC. We have some version of
> > driver (gpio for switching bus is controlled via sysfs) which probably
> > won't accepted. We want to do it correct way so we was thinking about
> > same approach as i2c-mux is using (i2c device connected on mux buses
> > are transparent to user so switching is done completely in driver). I
> > would like to maybe get some initial thoughts if this is good idea to
> > go this way and don't be a problem for future upstreaming. Thanks for
> > any comments.
>
> Sorry, but I doubt we ever get to add proper upstream support for mmc
> hosts managing multiple slots. Simply because all the efforts it takes
> isn't worth it.
>
> Today there are some host trying to support this, but those are hacks,
> which is working very poorly. I don't want to maintain more of those,
> then it's better those are managed by vendors out of tree.

Thanks for quick reply.

(just copy part of internal discussion):
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?
Thanks.
>
> There have been several discussions on this topic, this is just one
> that I found while searching.
> https://lkml.org/lkml/2017/10/6/710
>
> If you need any further explainations, please just ask.
>
> >
> > 0 - https://pyra-handheld.com/boards/pages/pyra/
> >
>
> Kind regards
> Uffe

BR,

marek
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux