Hi Ulf,
CC'ed pyra kernel guys
On Tue, Jul 3, 2018 at 11:23 AM Ulf Hansson ulf.hansson@linaro.org wrote:
On 3 July 2018 at 08:47, Belisko Marek marek@goldelico.com 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.
Kind regards Uffe
BR,
marek
On 3 July 2018 at 20:45, Belisko Marek marek.belisko@gmail.com wrote:
Hi Ulf,
CC'ed pyra kernel guys
On Tue, Jul 3, 2018 at 11:23 AM Ulf Hansson ulf.hansson@linaro.org wrote:
On 3 July 2018 at 08:47, Belisko Marek marek@goldelico.com 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?
No.
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
Did you read this?
If you need any further explainations, please just ask.
Let me elaborate a bit on the problems.
1. Serialization of requests (several request sent after each other, with delays, changing clocks etc), is managed by the core, because it implements the SD/SDIO/(e)MMC specs. This does not belong in a host driver. -> A kind of mmc bus slot lock is needed in the core. Not a big deal, we can probably hide it below mmc_claim|release_host().
2. What if there is an SD card that can cope with high-speed mode in one slot with a clock freq at 50 MHz. Then in the other slot, there is an eMMC using HS200 mode, running at 200 MHz. Can the HW guarantee all kind of different combinations, with clock glitches etc?
3. The biggest problem: You can *not* provide any service guarantees in regards to latency or bandwidth for any of the storage media in the slots, because of the bus slot lock. That because the upper layers runs I/O scheduling separately for each storage device, thus request for one slot can starve requests on another.
Kind regards Uffe
Hi Ulf,
Am 04.07.2018 um 13:06 schrieb Ulf Hansson ulf.hansson@linaro.org:
On 3 July 2018 at 20:45, Belisko Marek marek.belisko@gmail.com wrote:
Hi Ulf,
CC'ed pyra kernel guys
On Tue, Jul 3, 2018 at 11:23 AM Ulf Hansson ulf.hansson@linaro.org wrote:
On 3 July 2018 at 08:47, Belisko Marek marek@goldelico.com 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?
No.
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
Did you read this?
Yes, we did study it and understand the concerns. But concerns don't help to solve problems.
We have a hardware with this sdio switch chip is connected to some omap5 mmc port and multiplexes an internal eMMC and an external µSD slot.
Currently we use a user-space script that ejects the current drive, toggles the control gpio and partprobes the other sd device:
http://git.goldelico.com/?p=letux-kernel.git;a=blob;f=Letux/root/txs;h=a40a2...
This is slow. And is not transparent for user-space software (e.g. file managers). And you can't copy data from one device to the other with standard cp commands or without temporary storage.
So we would be happy with any improvement over this situation and are not immediately looking at perfection. This is why we want to find a kernel driver solution for the txa02612 chip.
If you need any further explainations, please just ask.
Let me elaborate a bit on the problems.
- Serialization of requests (several request sent after each other,
with delays, changing clocks etc), is managed by the core, because it implements the SD/SDIO/(e)MMC specs. This does not belong in a host driver. -> A kind of mmc bus slot lock is needed in the core. Not a big deal, we can probably hide it below mmc_claim|release_host().
Our goal would be to encapsulate this completely in the txs02612 driver so that we do not have to touch the mmc core at all. If that is possible with existing API.
- What if there is an SD card that can cope with high-speed mode in
one slot with a clock freq at 50 MHz. Then in the other slot, there is an eMMC using HS200 mode, running at 200 MHz. Can the HW guarantee all kind of different combinations, with clock glitches etc?
We would be happy in a first step if it would work at all. Even with certain constraints like same clock freq for everyone so that no clock switching is involved. And yes, the txs02612 chip introduces its own speed limits.
- The biggest problem: You can *not* provide any service guarantees
in regards to latency or bandwidth for any of the storage media in the slots, because of the bus slot lock. That because the upper layers runs I/O scheduling separately for each storage device, thus request for one slot can starve requests on another.
Yes, we are aware of this limitation. It is not possible to achieve the same speed in multiplexed mode as with a dedicated mmc port for each client. But I expect the problem is not much different from a hard disk which may have significant latency while spinning up the motor.
And we have the same (even worse) with our current eject/partprobe approach which also does sort of serialization.
So we just want to know about the hurdles towards upstreaming before we have to turn the driver code upside down. And how to setup the driver architecture to get it basically working.
BR and thanks, Nikolaus
On 4 July 2018 at 14:58, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Ulf,
Am 04.07.2018 um 13:06 schrieb Ulf Hansson ulf.hansson@linaro.org:
On 3 July 2018 at 20:45, Belisko Marek marek.belisko@gmail.com wrote:
Hi Ulf,
CC'ed pyra kernel guys
On Tue, Jul 3, 2018 at 11:23 AM Ulf Hansson ulf.hansson@linaro.org wrote:
On 3 July 2018 at 08:47, Belisko Marek marek@goldelico.com 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?
No.
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
Did you read this?
Yes, we did study it and understand the concerns. But concerns don't help to solve problems.
We have a hardware with this sdio switch chip is connected to some omap5 mmc port and multiplexes an internal eMMC and an external µSD slot.
Currently we use a user-space script that ejects the current drive, toggles the control gpio and partprobes the other sd device:
http://git.goldelico.com/?p=letux-kernel.git;a=blob;f=Letux/root/txs;h=a40a2...
This is slow. And is not transparent for user-space software (e.g. file managers). And you can't copy data from one device to the other with standard cp commands or without temporary storage.
So we would be happy with any improvement over this situation and are not immediately looking at perfection. This is why we want to find a kernel driver solution for the txa02612 chip.
If you need any further explainations, please just ask.
Let me elaborate a bit on the problems.
- Serialization of requests (several request sent after each other,
with delays, changing clocks etc), is managed by the core, because it implements the SD/SDIO/(e)MMC specs. This does not belong in a host driver. -> A kind of mmc bus slot lock is needed in the core. Not a big deal, we can probably hide it below mmc_claim|release_host().
Our goal would be to encapsulate this completely in the txs02612 driver so that we do not have to touch the mmc core at all. If that is possible with existing API.
Sorry, but the core needs to be involved. However, I think adding a mmc bus lock, somehow, can be done.
- What if there is an SD card that can cope with high-speed mode in
one slot with a clock freq at 50 MHz. Then in the other slot, there is an eMMC using HS200 mode, running at 200 MHz. Can the HW guarantee all kind of different combinations, with clock glitches etc?
We would be happy in a first step if it would work at all. Even with certain constraints like same clock freq for everyone so that no clock switching is involved. And yes, the txs02612 chip introduces its own speed limits.
This is too hand-wavy. I need to know how you plan to solve this, because to me, it's really a tricky problem.
Of course, it depends also on how much the HW offers to help.
- The biggest problem: You can *not* provide any service guarantees
in regards to latency or bandwidth for any of the storage media in the slots, because of the bus slot lock. That because the upper layers runs I/O scheduling separately for each storage device, thus request for one slot can starve requests on another.
Yes, we are aware of this limitation. It is not possible to achieve the same speed in multiplexed mode as with a dedicated mmc port for each client. But I expect the problem is not much different from a hard disk which may have significant latency while spinning up the motor.
This is not only about poor performance. It's about things being entirely unpredictable.
Maybe we can figure something out to release the bus lock in between every request (that's not what we do today for the host lock), but it may be messy. You simply will have to post patches for me to look at, before I can decide what to do with them.
And we have the same (even worse) with our current eject/partprobe approach which also does sort of serialization.
So we just want to know about the hurdles towards upstreaming before we have to turn the driver code upside down. And how to setup the driver architecture to get it basically working.
Fair enough. I hope my comments have given some answers to you.
Kind regards Uffe
Hi Ulf,
Am 05.07.2018 um 13:55 schrieb Ulf Hansson ulf.hansson@linaro.org:
On 4 July 2018 at 14:58, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Ulf,
Am 04.07.2018 um 13:06 schrieb Ulf Hansson ulf.hansson@linaro.org:
On 3 July 2018 at 20:45, Belisko Marek marek.belisko@gmail.com wrote:
Hi Ulf,
CC'ed pyra kernel guys
On Tue, Jul 3, 2018 at 11:23 AM Ulf Hansson ulf.hansson@linaro.org wrote:
On 3 July 2018 at 08:47, Belisko Marek marek@goldelico.com 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?
No.
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
Did you read this?
Yes, we did study it and understand the concerns. But concerns don't help to solve problems.
We have a hardware with this sdio switch chip is connected to some omap5 mmc port and multiplexes an internal eMMC and an external µSD slot.
Currently we use a user-space script that ejects the current drive, toggles the control gpio and partprobes the other sd device:
http://git.goldelico.com/?p=letux-kernel.git;a=blob;f=Letux/root/txs;h=a40a2...
This is slow. And is not transparent for user-space software (e.g. file managers). And you can't copy data from one device to the other with standard cp commands or without temporary storage.
So we would be happy with any improvement over this situation and are not immediately looking at perfection. This is why we want to find a kernel driver solution for the txa02612 chip.
If you need any further explainations, please just ask.
Let me elaborate a bit on the problems.
- Serialization of requests (several request sent after each other,
with delays, changing clocks etc), is managed by the core, because it implements the SD/SDIO/(e)MMC specs. This does not belong in a host driver. -> A kind of mmc bus slot lock is needed in the core. Not a big deal, we can probably hide it below mmc_claim|release_host().
Our goal would be to encapsulate this completely in the txs02612 driver so that we do not have to touch the mmc core at all. If that is possible with existing API.
Sorry, but the core needs to be involved. However, I think adding a mmc bus lock, somehow, can be done.
- What if there is an SD card that can cope with high-speed mode in
one slot with a clock freq at 50 MHz. Then in the other slot, there is an eMMC using HS200 mode, running at 200 MHz. Can the HW guarantee all kind of different combinations, with clock glitches etc?
We would be happy in a first step if it would work at all. Even with certain constraints like same clock freq for everyone so that no clock switching is involved. And yes, the txs02612 chip introduces its own speed limits.
This is too hand-wavy. I need to know how you plan to solve this, because to me, it's really a tricky problem.
Of course, it depends also on how much the HW offers to help.
- The biggest problem: You can *not* provide any service guarantees
in regards to latency or bandwidth for any of the storage media in the slots, because of the bus slot lock. That because the upper layers runs I/O scheduling separately for each storage device, thus request for one slot can starve requests on another.
Yes, we are aware of this limitation. It is not possible to achieve the same speed in multiplexed mode as with a dedicated mmc port for each client. But I expect the problem is not much different from a hard disk which may have significant latency while spinning up the motor.
This is not only about poor performance. It's about things being entirely unpredictable.
Maybe we can figure something out to release the bus lock in between every request (that's not what we do today for the host lock), but it may be messy.
Yes, that is basically my view: if each request is locked but released after being served, the other channel gets a chance (if there is a pending request). With such a scheme, two processes accessing the two channels concurrently would alternate the switch and share bandwidth. Like two USB clients sitting on a remote hub which is connected to a single USB host port. Well, this analogy isn't perfect as the USB protocol and hub already takes care of this situation.
You simply will have to post patches for me to look at, before I can decide what to do with them.
Ok, that is fine. Thanks!
And we have the same (even worse) with our current eject/partprobe approach which also does sort of serialization.
So we just want to know about the hurdles towards upstreaming before we have to turn the driver code upside down. And how to setup the driver architecture to get it basically working.
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...
Best regards and thanks, Nikolaus
Hi Marek,
Am 05.07.2018 um 14:26 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Ulf,
Am 05.07.2018 um 13:55 schrieb Ulf Hansson ulf.hansson@linaro.org:
On 4 July 2018 at 14:58, H. Nikolaus Schaller hns@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...
It shows significant signs of being working:
root@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@letux:~# root@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@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
Hi Nikolaus, On Thu, Jul 19, 2018 at 7:54 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Marek,
Am 05.07.2018 um 14:26 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Ulf,
Am 05.07.2018 um 13:55 schrieb Ulf Hansson ulf.hansson@linaro.org:
On 4 July 2018 at 14:58, H. Nikolaus Schaller hns@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...
It shows significant signs of being working:
root@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@letux:~# root@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@letux:~#
So what is there:
- registering two new mmc_host ports
- locating the mmc driver matching the phandle [currently disabled]
- capturing the mmc_request (triggered by mmc core when trying a mmc_rescan on new devices)
- 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
Hi Nikolaus, On Thu, Jul 19, 2018 at 7:54 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Marek,
Am 05.07.2018 um 14:26 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Ulf,
Am 05.07.2018 um 13:55 schrieb Ulf Hansson ulf.hansson@linaro.org:
On 4 July 2018 at 14:58, H. Nikolaus Schaller hns@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...
Can you please share in which branch those changes are? It took me a while but I cannot find it ;). Thanks.
It shows significant signs of being working:
root@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@letux:~# root@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@letux:~#
So what is there:
- registering two new mmc_host ports
- locating the mmc driver matching the phandle [currently disabled]
- capturing the mmc_request (triggered by mmc core when trying a mmc_rescan on new devices)
- 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
Hi Marek,
Am 24.07.2018 um 07:33 schrieb Belisko Marek marek.belisko@gmail.com:
Hi Nikolaus, On Thu, Jul 19, 2018 at 7:54 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Marek,
Am 05.07.2018 um 14:26 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Ulf,
Am 05.07.2018 um 13:55 schrieb Ulf Hansson ulf.hansson@linaro.org:
On 4 July 2018 at 14:58, H. Nikolaus Schaller hns@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...
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/le...
BR, Nikolaus
It shows significant signs of being working:
root@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@letux:~# root@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@letux:~#
So what is there:
- registering two new mmc_host ports
- locating the mmc driver matching the phandle [currently disabled]
- capturing the mmc_request (triggered by mmc core when trying a mmc_rescan on new devices)
- 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
Hi Nikolaus. On Tue, Jul 24, 2018 at 7:38 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Marek,
Am 24.07.2018 um 07:33 schrieb Belisko Marek marek.belisko@gmail.com:
Hi Nikolaus, On Thu, Jul 19, 2018 at 7:54 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Marek,
Am 05.07.2018 um 14:26 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Ulf,
Am 05.07.2018 um 13:55 schrieb Ulf Hansson ulf.hansson@linaro.org:
On 4 July 2018 at 14:58, H. Nikolaus Schaller hns@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...
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/le...
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@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@letux:~# root@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@letux:~#
So what is there:
- registering two new mmc_host ports
- locating the mmc driver matching the phandle [currently disabled]
- capturing the mmc_request (triggered by mmc core when trying a mmc_rescan on new devices)
- 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
Hi Marek,
Am 24.07.2018 um 08:20 schrieb Belisko Marek marek.belisko@gmail.com:
Hi Nikolaus. On Tue, Jul 24, 2018 at 7:38 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Marek,
Am 24.07.2018 um 07:33 schrieb Belisko Marek marek.belisko@gmail.com:
Hi Nikolaus, On Thu, Jul 19, 2018 at 7:54 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Marek,
Am 05.07.2018 um 14:26 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Ulf,
Am 05.07.2018 um 13:55 schrieb Ulf Hansson ulf.hansson@linaro.org:
On 4 July 2018 at 14:58, H. Nikolaus Schaller hns@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...
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/le...
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
-
Belisko Marek -
H. Nikolaus Schaller -
Ulf Hansson