Re: [PATCH v7 00/24] i2c mux cleanup and locking update
Wolfram Sang wrote: > > The problem with waiting until 4.8 with the rest of the series is that it > > will likely go stale, e.g. patch 22 ([media] rtl2832: change the i2c gate > > to be mux-locked) touches a ton of register accesses in that driver since > > it removes a regmap wrapper that is rendered obsolete. Expecting that > > patch to work for 4.8 is overly optimistic, and while patching things up > > Okay, that can be argued, I understand that. So, what about this > suggestion: I pull in patches 1-15 today, and we schedule the rest of > the patches for like next week or so. That still gives the first set of > patches some time in linux-next for further exposure and testing whilst > the whole series should arrive in 4.7. That sounds really good, thanks! > However, I need help with that. There are serious locking changes > involved and ideally these patches are reviewed by multiple people, > especially patches 16-19. I first want to say that the collaboration > experience with this series was great so far, lots of testing and > reporting back. Thanks for that already. Yet, if we want to have this in > 4.7, this needs to be a group effort. So, if people interested could > review even a little and report back this would be extremly helpful. Yes please! > > Third, should we deprecate the old i2c_add_mux_adapter, so that new > > users do not crop up behind our backs in the transition? Or not bother? > > Usually it is fine to change in-kernel-APIs when you take care that all > current users are converted. But I am also fine with being nice and > keeping the old call around for a few cycles. It is your call. Ok, I'm a bit fed up with this series and will ignore it then. > > Fourth, I forgot to change patch 8 (iio: imu: inv_mpu6050: convert to > > use an explicit i2c mux core) to not change i2c_get_clientdata() -> > > dev_get_drvdata() as requested by Jonathan Cameron. How should I handle > > that? > > I'll pull in the first patches this eveneing. You can choose to send me > an incremental patch or resend patch 8. I am fine with both, but it > should appear on the mailing list somehow. I just sent a v8 of 08/24 (not sending a whole v8 for that though) > > There are also some new Tested-by tags that I have added to my > > local branch but have not pushed anywhere. I'm ready to push all that > > to a new branch once you are ready to take it. > > For the patches 1-15, I am ready when you are :) Ok, I pushed out v8, see below. Pick what you want :-) Cheers, Peter The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: https://github.com/peda-r/i2c-mux.git mux-core-and-locking-8 for you to fetch changes up to b9a0ea3a309a3a4051c7c0cc54ade0eb5a877896: [media] rtl2832: regmap is aware of lockdep, drop local locking hack (2016-04-22 12:18:45 +0200) Antti Palosaari (1): [media] si2168: change the i2c gate to be mux-locked Peter Rosin (23): i2c-mux: add common data for every i2c-mux instance i2c: i2c-mux-gpio: convert to use an explicit i2c mux core i2c: i2c-mux-pinctrl: convert to use an explicit i2c mux core i2c: i2c-arb-gpio-challenge: convert to use an explicit i2c mux core i2c: i2c-mux-pca9541: convert to use an explicit i2c mux core i2c: i2c-mux-pca954x: convert to use an explicit i2c mux core i2c: i2c-mux-reg: convert to use an explicit i2c mux core iio: imu: inv_mpu6050: convert to use an explicit i2c mux core [media] m88ds3103: convert to use an explicit i2c mux core [media] rtl2830: convert to use an explicit i2c mux core [media] rtl2832: convert to use an explicit i2c mux core [media] si2168: convert to use an explicit i2c mux core [media] cx231xx: convert to use an explicit i2c mux core of/unittest: convert to use an explicit i2c mux core i2c-mux: drop old unused i2c-mux api i2c: allow adapter drivers to override the adapter locking i2c: muxes always lock the parent adapter i2c-mux: relax locking of the top i2c adapter during mux-locked muxing i2c-mux: document i2c muxes and elaborate on parent-/mux-locked muxes iio: imu: inv_mpu6050: change the i2c gate to be mux-locked [media] rtl2832: change the i2c gate to be mux-locked [media] rtl2832_sdr: get rid of empty regmap wrappers [media] rtl2832: regmap is aware of lockdep, drop local locking hack Documentation/i2c/i2c-topology | 370 +++ MAINTAINERS | 1 + drivers/i2c/i2c-core.c | 66 +++-- drivers/i2c/i2c-mux.c| 297 - drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 47 ++-- drivers/i2c/muxes/i2c-mux-gpio.c | 73 +++--- drivers/i2c/muxes/i2c-mux-pca9541.c | 58
Re: [PATCH v7 00/24] i2c mux cleanup and locking update
Wolfram Sang wrote: > > The problem with waiting until 4.8 with the rest of the series is that it > > will likely go stale, e.g. patch 22 ([media] rtl2832: change the i2c gate > > to be mux-locked) touches a ton of register accesses in that driver since > > it removes a regmap wrapper that is rendered obsolete. Expecting that > > patch to work for 4.8 is overly optimistic, and while patching things up > > Okay, that can be argued, I understand that. So, what about this > suggestion: I pull in patches 1-15 today, and we schedule the rest of > the patches for like next week or so. That still gives the first set of > patches some time in linux-next for further exposure and testing whilst > the whole series should arrive in 4.7. That sounds really good, thanks! > However, I need help with that. There are serious locking changes > involved and ideally these patches are reviewed by multiple people, > especially patches 16-19. I first want to say that the collaboration > experience with this series was great so far, lots of testing and > reporting back. Thanks for that already. Yet, if we want to have this in > 4.7, this needs to be a group effort. So, if people interested could > review even a little and report back this would be extremly helpful. Yes please! > > Third, should we deprecate the old i2c_add_mux_adapter, so that new > > users do not crop up behind our backs in the transition? Or not bother? > > Usually it is fine to change in-kernel-APIs when you take care that all > current users are converted. But I am also fine with being nice and > keeping the old call around for a few cycles. It is your call. Ok, I'm a bit fed up with this series and will ignore it then. > > Fourth, I forgot to change patch 8 (iio: imu: inv_mpu6050: convert to > > use an explicit i2c mux core) to not change i2c_get_clientdata() -> > > dev_get_drvdata() as requested by Jonathan Cameron. How should I handle > > that? > > I'll pull in the first patches this eveneing. You can choose to send me > an incremental patch or resend patch 8. I am fine with both, but it > should appear on the mailing list somehow. I just sent a v8 of 08/24 (not sending a whole v8 for that though) > > There are also some new Tested-by tags that I have added to my > > local branch but have not pushed anywhere. I'm ready to push all that > > to a new branch once you are ready to take it. > > For the patches 1-15, I am ready when you are :) Ok, I pushed out v8, see below. Pick what you want :-) Cheers, Peter The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: https://github.com/peda-r/i2c-mux.git mux-core-and-locking-8 for you to fetch changes up to b9a0ea3a309a3a4051c7c0cc54ade0eb5a877896: [media] rtl2832: regmap is aware of lockdep, drop local locking hack (2016-04-22 12:18:45 +0200) Antti Palosaari (1): [media] si2168: change the i2c gate to be mux-locked Peter Rosin (23): i2c-mux: add common data for every i2c-mux instance i2c: i2c-mux-gpio: convert to use an explicit i2c mux core i2c: i2c-mux-pinctrl: convert to use an explicit i2c mux core i2c: i2c-arb-gpio-challenge: convert to use an explicit i2c mux core i2c: i2c-mux-pca9541: convert to use an explicit i2c mux core i2c: i2c-mux-pca954x: convert to use an explicit i2c mux core i2c: i2c-mux-reg: convert to use an explicit i2c mux core iio: imu: inv_mpu6050: convert to use an explicit i2c mux core [media] m88ds3103: convert to use an explicit i2c mux core [media] rtl2830: convert to use an explicit i2c mux core [media] rtl2832: convert to use an explicit i2c mux core [media] si2168: convert to use an explicit i2c mux core [media] cx231xx: convert to use an explicit i2c mux core of/unittest: convert to use an explicit i2c mux core i2c-mux: drop old unused i2c-mux api i2c: allow adapter drivers to override the adapter locking i2c: muxes always lock the parent adapter i2c-mux: relax locking of the top i2c adapter during mux-locked muxing i2c-mux: document i2c muxes and elaborate on parent-/mux-locked muxes iio: imu: inv_mpu6050: change the i2c gate to be mux-locked [media] rtl2832: change the i2c gate to be mux-locked [media] rtl2832_sdr: get rid of empty regmap wrappers [media] rtl2832: regmap is aware of lockdep, drop local locking hack Documentation/i2c/i2c-topology | 370 +++ MAINTAINERS | 1 + drivers/i2c/i2c-core.c | 66 +++-- drivers/i2c/i2c-mux.c| 297 - drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 47 ++-- drivers/i2c/muxes/i2c-mux-gpio.c | 73 +++--- drivers/i2c/muxes/i2c-mux-pca9541.c | 58
Re: [PATCH v7 00/24] i2c mux cleanup and locking update
> The problem with waiting until 4.8 with the rest of the series is that it > will likely go stale, e.g. patch 22 ([media] rtl2832: change the i2c gate > to be mux-locked) touches a ton of register accesses in that driver since > it removes a regmap wrapper that is rendered obsolete. Expecting that > patch to work for 4.8 is overly optimistic, and while patching things up Okay, that can be argued, I understand that. So, what about this suggestion: I pull in patches 1-15 today, and we schedule the rest of the patches for like next week or so. That still gives the first set of patches some time in linux-next for further exposure and testing whilst the whole series should arrive in 4.7. However, I need help with that. There are serious locking changes involved and ideally these patches are reviewed by multiple people, especially patches 16-19. I first want to say that the collaboration experience with this series was great so far, lots of testing and reporting back. Thanks for that already. Yet, if we want to have this in 4.7, this needs to be a group effort. So, if people interested could review even a little and report back this would be extremly helpful. > Third, should we deprecate the old i2c_add_mux_adapter, so that new > users do not crop up behind our backs in the transition? Or not bother? Usually it is fine to change in-kernel-APIs when you take care that all current users are converted. But I am also fine with being nice and keeping the old call around for a few cycles. It is your call. > Fourth, I forgot to change patch 8 (iio: imu: inv_mpu6050: convert to > use an explicit i2c mux core) to not change i2c_get_clientdata() -> > dev_get_drvdata() as requested by Jonathan Cameron. How should I handle > that? I'll pull in the first patches this eveneing. You can choose to send me an incremental patch or resend patch 8. I am fine with both, but it should appear on the mailing list somehow. > There are also some new Tested-by tags that I have added to my > local branch but have not pushed anywhere. I'm ready to push all that > to a new branch once you are ready to take it. For the patches 1-15, I am ready when you are :) Thanks, Wolfram signature.asc Description: PGP signature
Re: [PATCH v7 00/24] i2c mux cleanup and locking update
> The problem with waiting until 4.8 with the rest of the series is that it > will likely go stale, e.g. patch 22 ([media] rtl2832: change the i2c gate > to be mux-locked) touches a ton of register accesses in that driver since > it removes a regmap wrapper that is rendered obsolete. Expecting that > patch to work for 4.8 is overly optimistic, and while patching things up Okay, that can be argued, I understand that. So, what about this suggestion: I pull in patches 1-15 today, and we schedule the rest of the patches for like next week or so. That still gives the first set of patches some time in linux-next for further exposure and testing whilst the whole series should arrive in 4.7. However, I need help with that. There are serious locking changes involved and ideally these patches are reviewed by multiple people, especially patches 16-19. I first want to say that the collaboration experience with this series was great so far, lots of testing and reporting back. Thanks for that already. Yet, if we want to have this in 4.7, this needs to be a group effort. So, if people interested could review even a little and report back this would be extremly helpful. > Third, should we deprecate the old i2c_add_mux_adapter, so that new > users do not crop up behind our backs in the transition? Or not bother? Usually it is fine to change in-kernel-APIs when you take care that all current users are converted. But I am also fine with being nice and keeping the old call around for a few cycles. It is your call. > Fourth, I forgot to change patch 8 (iio: imu: inv_mpu6050: convert to > use an explicit i2c mux core) to not change i2c_get_clientdata() -> > dev_get_drvdata() as requested by Jonathan Cameron. How should I handle > that? I'll pull in the first patches this eveneing. You can choose to send me an incremental patch or resend patch 8. I am fine with both, but it should appear on the mailing list somehow. > There are also some new Tested-by tags that I have added to my > local branch but have not pushed anywhere. I'm ready to push all that > to a new branch once you are ready to take it. For the patches 1-15, I am ready when you are :) Thanks, Wolfram signature.asc Description: PGP signature
Re: [PATCH v7 00/24] i2c mux cleanup and locking update
Hi Wolfram, Wolfram Sang wrote: > This was the diff of v6: > > > 32 files changed, 1277 insertions(+), 915 deletions(-) > > This is v7: > > > 32 files changed, 1225 insertions(+), 916 deletions(-) > > So, we gained a little overall. And while the individual drivers have a > few lines more now, I still think it is more readable. > > So, thanks for doing that! Most, if not all, of these ~50 lines gained in v7 come from removing i2c_mux_reserve_adapters and realloc. I.e., I think we might even have lost a few lines with the i2c_mux_one_adapter removal, but not that many. If the doc patch is taken out of the equation, we gain new functionality, fix a bug and lose lines of code. Feels good! However, this is not why I'm writing this message... > I'll give people some time for testing. I'll have a further look, too. > Hopefully, I can pick up patches 1-14 by the end of the week. The reason for this message is that I just realized a couple of things. First, you have suggested to merge patches 1-14 about now, and I assumed that implied merging with Linus for 4.6, but on rereading I realize that you have consistently targeted 4.7. I must be sloppy, and that had escaped me. Is it really necessary to be that cautious? Maybe I'm overly confident, but is 1-14 really such a big deal that it has to float in next for a whole cycle? The problem with waiting until 4.8 with the rest of the series is that it will likely go stale, e.g. patch 22 ([media] rtl2832: change the i2c gate to be mux-locked) touches a ton of register accesses in that driver since it removes a regmap wrapper that is rendered obsolete. Expecting that patch to work for 4.8 is overly optimistic, and while patching things up is (probably) easy, it also renders any previous testing suspect. That said, maybe I'm just impatient and reckless? Second, should we not add 15-24 to the next branch now as well to get testing going asap, even if we do not intend to merge it just yet or even in that exact form? Or is that abusing the next branch? Third, should we deprecate the old i2c_add_mux_adapter, so that new users do not crop up behind our backs in the transition? Or not bother? Fourth, I forgot to change patch 8 (iio: imu: inv_mpu6050: convert to use an explicit i2c mux core) to not change i2c_get_clientdata() -> dev_get_drvdata() as requested by Jonathan Cameron. How should I handle that? There are also some new Tested-by tags that I have added to my local branch but have not pushed anywhere. I'm ready to push all that to a new branch once you are ready to take it. Cheers, Peter
Re: [PATCH v7 00/24] i2c mux cleanup and locking update
Hi Wolfram, Wolfram Sang wrote: > This was the diff of v6: > > > 32 files changed, 1277 insertions(+), 915 deletions(-) > > This is v7: > > > 32 files changed, 1225 insertions(+), 916 deletions(-) > > So, we gained a little overall. And while the individual drivers have a > few lines more now, I still think it is more readable. > > So, thanks for doing that! Most, if not all, of these ~50 lines gained in v7 come from removing i2c_mux_reserve_adapters and realloc. I.e., I think we might even have lost a few lines with the i2c_mux_one_adapter removal, but not that many. If the doc patch is taken out of the equation, we gain new functionality, fix a bug and lose lines of code. Feels good! However, this is not why I'm writing this message... > I'll give people some time for testing. I'll have a further look, too. > Hopefully, I can pick up patches 1-14 by the end of the week. The reason for this message is that I just realized a couple of things. First, you have suggested to merge patches 1-14 about now, and I assumed that implied merging with Linus for 4.6, but on rereading I realize that you have consistently targeted 4.7. I must be sloppy, and that had escaped me. Is it really necessary to be that cautious? Maybe I'm overly confident, but is 1-14 really such a big deal that it has to float in next for a whole cycle? The problem with waiting until 4.8 with the rest of the series is that it will likely go stale, e.g. patch 22 ([media] rtl2832: change the i2c gate to be mux-locked) touches a ton of register accesses in that driver since it removes a regmap wrapper that is rendered obsolete. Expecting that patch to work for 4.8 is overly optimistic, and while patching things up is (probably) easy, it also renders any previous testing suspect. That said, maybe I'm just impatient and reckless? Second, should we not add 15-24 to the next branch now as well to get testing going asap, even if we do not intend to merge it just yet or even in that exact form? Or is that abusing the next branch? Third, should we deprecate the old i2c_add_mux_adapter, so that new users do not crop up behind our backs in the transition? Or not bother? Fourth, I forgot to change patch 8 (iio: imu: inv_mpu6050: convert to use an explicit i2c mux core) to not change i2c_get_clientdata() -> dev_get_drvdata() as requested by Jonathan Cameron. How should I handle that? There are also some new Tested-by tags that I have added to my local branch but have not pushed anywhere. I'm ready to push all that to a new branch once you are ready to take it. Cheers, Peter
Re: [PATCH v7 00/24] i2c mux cleanup and locking update
On 04/20/2016 06:17 PM, Peter Rosin wrote: > v7 compared to v6: > - Removed i2c_mux_reserve_adapters, and all realloc attempts in > i2c_mux_add_adapter. Supply a maximum number of adapters in i2c_mux_alloc > instead. > - Removed i2c_mux_one_adapter since it is was hard to use correctly, which > was evident from the crash in the mpu6050 driver (on a mpu9150 chip) > reported > by Crestez Dan Leonard. Also, it didn't make things all that much simpler > anyway (even if used correctly). > - Rename i2c_mux_core:adapters into i2c_mux_core:num_adapters. > - Some grammar and spelling fixes. I tested this new version on mpu9150 and there are no more obvious deadlocks or crashes. The magnetometer and accel/gyro can be used at the same time without issues.
Re: [PATCH v7 00/24] i2c mux cleanup and locking update
On 04/20/2016 06:17 PM, Peter Rosin wrote: > v7 compared to v6: > - Removed i2c_mux_reserve_adapters, and all realloc attempts in > i2c_mux_add_adapter. Supply a maximum number of adapters in i2c_mux_alloc > instead. > - Removed i2c_mux_one_adapter since it is was hard to use correctly, which > was evident from the crash in the mpu6050 driver (on a mpu9150 chip) > reported > by Crestez Dan Leonard. Also, it didn't make things all that much simpler > anyway (even if used correctly). > - Rename i2c_mux_core:adapters into i2c_mux_core:num_adapters. > - Some grammar and spelling fixes. I tested this new version on mpu9150 and there are no more obvious deadlocks or crashes. The magnetometer and accel/gyro can be used at the same time without issues.
Re: [PATCH v7 00/24] i2c mux cleanup and locking update
On 04/20/2016 06:17 PM, Peter Rosin wrote: Retested all the previously tested + now I tested also cx231xx with Hauppauge 930C HD device having eeprom other mux port and demod on the other port. [media] si2168: change the i2c gate to be mux-locked [media] m88ds3103: convert to use an explicit i2c mux core [media] rtl2830: convert to use an explicit i2c mux core [media] rtl2832: convert to use an explicit i2c mux core [media] si2168: convert to use an explicit i2c mux core [media] cx231xx: convert to use an explicit i2c mux core [media] rtl2832: change the i2c gate to be mux-locked [media] rtl2832_sdr: get rid of empty regmap wrappers [media] rtl2832: regmap is aware of lockdep, drop local locking hack I really hope that this whole patch series will arrive asap to mainline. regards Antti -- http://palosaari.fi/
Re: [PATCH v7 00/24] i2c mux cleanup and locking update
On 04/20/2016 06:17 PM, Peter Rosin wrote: Retested all the previously tested + now I tested also cx231xx with Hauppauge 930C HD device having eeprom other mux port and demod on the other port. [media] si2168: change the i2c gate to be mux-locked [media] m88ds3103: convert to use an explicit i2c mux core [media] rtl2830: convert to use an explicit i2c mux core [media] rtl2832: convert to use an explicit i2c mux core [media] si2168: convert to use an explicit i2c mux core [media] cx231xx: convert to use an explicit i2c mux core [media] rtl2832: change the i2c gate to be mux-locked [media] rtl2832_sdr: get rid of empty regmap wrappers [media] rtl2832: regmap is aware of lockdep, drop local locking hack I really hope that this whole patch series will arrive asap to mainline. regards Antti -- http://palosaari.fi/
Re: [PATCH v7 00/24] i2c mux cleanup and locking update
This was the diff of v6: > 32 files changed, 1277 insertions(+), 915 deletions(-) This is v7: > 32 files changed, 1225 insertions(+), 916 deletions(-) So, we gained a little overall. And while the individual drivers have a few lines more now, I still think it is more readable. So, thanks for doing that! I'll give people some time for testing. I'll have a further look, too. Hopefully, I can pick up patches 1-14 by the end of the week. Wolfram signature.asc Description: PGP signature
Re: [PATCH v7 00/24] i2c mux cleanup and locking update
This was the diff of v6: > 32 files changed, 1277 insertions(+), 915 deletions(-) This is v7: > 32 files changed, 1225 insertions(+), 916 deletions(-) So, we gained a little overall. And while the individual drivers have a few lines more now, I still think it is more readable. So, thanks for doing that! I'll give people some time for testing. I'll have a further look, too. Hopefully, I can pick up patches 1-14 by the end of the week. Wolfram signature.asc Description: PGP signature
[PATCH v7 00/24] i2c mux cleanup and locking update
Hi! I have a pair of boards with this i2c topology: GPIO ---| -- BAT1 | v / I2C -+--B---+ MUX | \ EEPROM -- BAT2 (B denotes the boundary between the boards) The problem with this is that the GPIO controller sits on the same i2c bus that it MUXes. For pca954x devices this is worked around by using unlocked transfers when updating the MUX. I have no such luck as the GPIO is a general purpose IO expander and the MUX is just a random bidirectional MUX, unaware of the fact that it is muxing an i2c bus. Extending unlocked transfers into the GPIO subsystem is too ugly to even think about. But the general hw approach is sane in my opinion, with the number of connections between the two boards minimized. To put it plainly, I need support for it. So, I observe that while it is needed to have the i2c bus locked during the actual MUX update in order to avoid random garbage on the slave side, it is not strictly a must to have it locked over the whole sequence of a full select-transfer-deselect operation. The MUX itself needs to be locked, so transfers to clients behind the mux are serialized, and the MUX needs to be stable during all i2c traffic (otherwise individual mux slave segments might see garbage). This series accomplishes this by adding code to i2c-mux-gpio and i2c-mux-pinctrl that determines if all involved devices used to update the mux are controlled by the same root i2c adapter that is muxed. When this is the case, the select-transfer-deselect operations should be locked individually to avoid the deadlock. The i2c bus *is* still locked during muxing, since the muxing happens as part of i2c transfers. This is true even if the MUX is updated with several transfers to the GPIO (at least as long as *all* MUX changes are using the i2c master bus). A lock is added to i2c adapters that muxes on that adapter grab, so that transfers through the muxes are serialized. Concerns: - The locking is perhaps too complex? - I worry about the priority inheritance aspect of the adapter lock. When the transfers behind the mux are divided into select-transfer-deselect all locked individually, low priority transfers get more chances to interfere with high priority transfers. - When doing an i2c_transfer() in_atomic() context or with irqs_disabled(), there is a higher possibility that the mux is not returned to its idle state after a failed (-EAGAIN) transfer due to trylock. - Is the detection of i2c-controlled gpios and pinctrls sane (i.e. the usage of the new i2c_root_adapter() function in 18/24)? To summarize the series, there's some i2c-mux infrastructure cleanup work first (I think that part stands by itself as desireable regardless), the locking changes are in 16/24 and after with the real meat in 18/24. There is some documentation added in 19/24 while 20/24 and after are cleanups to existing drivers utilizing the new stuff. PS. needs a bunch of testing, I do not have access to all the involved hw. Thanks to those who have ested this series so far. At this point, only patches 01 through 15 are planned for 4.6, and the rest will hopefully follow later, so lets focus of the cleanup work that enables the real work later in the series. Antti, you reviewed 09 through 12 for v5, and even though they changed slightly due to the changes in v7 I have kept your reviewed tags, since I classified the changes as mechanical. I hope this is ok. Similarly, Jonathan and Rob acked patch 08 and 14 respectively, and these patches have the same kind of mechanical changes so I have kept the acks. I hope this is also ok. I have also kept the acks and review tags on patches 20 and forward since the fixups to adjust to the changes earlier in the series were completely trivial. This series can also be pulled from github, if that is preferred: - The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: https://github.com/peda-r/i2c-mux.git mux-core-and-locking-7 for you to fetch changes up to f725ef789ff0eb2663f1cff2b29d8196a7f0fd0b: [media] rtl2832: regmap is aware of lockdep, drop local locking hack (2016-04-20 14:49:00 +0200) - v7 compared to v6: - Removed i2c_mux_reserve_adapters, and all realloc attempts in i2c_mux_add_adapter. Supply a maximum number of adapters in i2c_mux_alloc instead. - Removed i2c_mux_one_adapter since it is was hard to use correctly, which was evident from the crash in the mpu6050 driver (on a mpu9150 chip) reported by Crestez Dan Leonard. Also, it didn't make things all that much simpler anyway (even if used correctly). - Rename i2c_mux_core:adapters into i2c_mux_core:num_adapters. - Some grammar and spelling fixes. v6 compared to v5: - Rebase on top of v4.6-rc1 - Adjust to gpio subsystem
[PATCH v7 00/24] i2c mux cleanup and locking update
Hi! I have a pair of boards with this i2c topology: GPIO ---| -- BAT1 | v / I2C -+--B---+ MUX | \ EEPROM -- BAT2 (B denotes the boundary between the boards) The problem with this is that the GPIO controller sits on the same i2c bus that it MUXes. For pca954x devices this is worked around by using unlocked transfers when updating the MUX. I have no such luck as the GPIO is a general purpose IO expander and the MUX is just a random bidirectional MUX, unaware of the fact that it is muxing an i2c bus. Extending unlocked transfers into the GPIO subsystem is too ugly to even think about. But the general hw approach is sane in my opinion, with the number of connections between the two boards minimized. To put it plainly, I need support for it. So, I observe that while it is needed to have the i2c bus locked during the actual MUX update in order to avoid random garbage on the slave side, it is not strictly a must to have it locked over the whole sequence of a full select-transfer-deselect operation. The MUX itself needs to be locked, so transfers to clients behind the mux are serialized, and the MUX needs to be stable during all i2c traffic (otherwise individual mux slave segments might see garbage). This series accomplishes this by adding code to i2c-mux-gpio and i2c-mux-pinctrl that determines if all involved devices used to update the mux are controlled by the same root i2c adapter that is muxed. When this is the case, the select-transfer-deselect operations should be locked individually to avoid the deadlock. The i2c bus *is* still locked during muxing, since the muxing happens as part of i2c transfers. This is true even if the MUX is updated with several transfers to the GPIO (at least as long as *all* MUX changes are using the i2c master bus). A lock is added to i2c adapters that muxes on that adapter grab, so that transfers through the muxes are serialized. Concerns: - The locking is perhaps too complex? - I worry about the priority inheritance aspect of the adapter lock. When the transfers behind the mux are divided into select-transfer-deselect all locked individually, low priority transfers get more chances to interfere with high priority transfers. - When doing an i2c_transfer() in_atomic() context or with irqs_disabled(), there is a higher possibility that the mux is not returned to its idle state after a failed (-EAGAIN) transfer due to trylock. - Is the detection of i2c-controlled gpios and pinctrls sane (i.e. the usage of the new i2c_root_adapter() function in 18/24)? To summarize the series, there's some i2c-mux infrastructure cleanup work first (I think that part stands by itself as desireable regardless), the locking changes are in 16/24 and after with the real meat in 18/24. There is some documentation added in 19/24 while 20/24 and after are cleanups to existing drivers utilizing the new stuff. PS. needs a bunch of testing, I do not have access to all the involved hw. Thanks to those who have ested this series so far. At this point, only patches 01 through 15 are planned for 4.6, and the rest will hopefully follow later, so lets focus of the cleanup work that enables the real work later in the series. Antti, you reviewed 09 through 12 for v5, and even though they changed slightly due to the changes in v7 I have kept your reviewed tags, since I classified the changes as mechanical. I hope this is ok. Similarly, Jonathan and Rob acked patch 08 and 14 respectively, and these patches have the same kind of mechanical changes so I have kept the acks. I hope this is also ok. I have also kept the acks and review tags on patches 20 and forward since the fixups to adjust to the changes earlier in the series were completely trivial. This series can also be pulled from github, if that is preferred: - The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: https://github.com/peda-r/i2c-mux.git mux-core-and-locking-7 for you to fetch changes up to f725ef789ff0eb2663f1cff2b29d8196a7f0fd0b: [media] rtl2832: regmap is aware of lockdep, drop local locking hack (2016-04-20 14:49:00 +0200) - v7 compared to v6: - Removed i2c_mux_reserve_adapters, and all realloc attempts in i2c_mux_add_adapter. Supply a maximum number of adapters in i2c_mux_alloc instead. - Removed i2c_mux_one_adapter since it is was hard to use correctly, which was evident from the crash in the mpu6050 driver (on a mpu9150 chip) reported by Crestez Dan Leonard. Also, it didn't make things all that much simpler anyway (even if used correctly). - Rename i2c_mux_core:adapters into i2c_mux_core:num_adapters. - Some grammar and spelling fixes. v6 compared to v5: - Rebase on top of v4.6-rc1 - Adjust to gpio subsystem
