On 21 August 2012 21:31, Rob Herring <robherring2@xxxxxxxxx> wrote: > On 08/21/2012 10:18 AM, Chris Ball wrote: >> Hi, >> >> On Tue, Aug 21 2012, Rob Herring wrote: >>>> cd-gpios and cd-external can be present on the same node. if broken-cd >>>> is present, it must be the only one of these nodes used. >>> >>> I don't see the point of cd-external. Either you just use the CD >>> interrupt defined within the SDHCI or you have a gpio line independent >>> of the SDHCI and use cd-gpios. >> >> You've described two of the possible cases, but not the third. In the >> third case, you have a gpio line that is not independent of the SDHCI, >> because it is the SDHCI's CD pin brought out to be directly accessible >> via a GPIO. > > That is covered by absence of cd-gpios and broken-cd. Any *-gpios > property means the signal is a GPIO line controlled by a GPIO controller. > > I suppose you could have the CD state readable via the SDHCI, but the > interrupt comes from a GPIO controller. Or vice-versa, but that's a > pretty broken use case if you can't pick which way you are going to use > things. > >> >> The difference is in the handling of the interrupt -- if you don't have >> "cd-external" then you're just using the SDHCI's interrupt, but if you >> have an independent line then you're going to need to register your own >> IRQ handler on it, and "cd-external" signifies that. >> >> Thomas wrote this explanation earlier in the thread: >>> "samsung,sdhci-cd-gpio" means that the cd-gpio line is not connected >>> to the card-detect pad of the sdhci controller. Instead, it identifies >>> cd-gpio as a gpio pin, connected to the card-detect pin of the "card >>> slot" and it can used as a source of external interrupt. The driver >>> can register card insert/remove handler for this interrupt and get >>> notified about the changes in card state. >>> >>> "sdhci-cd-internal" means that the "cd-gpio" line is used to connect >>> the card-detect pin of the card slot and the card-detect pad of the >>> sdhci controller. The controller is then aware of any changes in card >>> state and the controller generates appropriate interrupts to notify >>> changes in card-state. >> > > It seems you are mixing pin muxing and who controls/handles the CD > detect signal. Pin muxing is a separate issue and should be addressed by > pin mux bindings. Either the signal functions as a GPIO or it functions > as a CD as part of the SDHCI. You may have muxing on the CD pin that > allows it to function either way, but the DT binding should describe how > you want it to be configured and used. Ok, I agree with Rob. I was mixing pin muxing here. So if we have 'cd-gpios' and 'broken-cd' as generic bindings, would the following be valid? [A] cd-gpios not present , broken-cd not present : This means that there is no card detect pin available. Controller drivers are free to infer this as "card detection is broken" and use implementation specific behavior. [B] cd-gpio not present , broken-cd present : This means that there is nothing connected to the card-detect pad of the mmc host controller. Controller drivers are free to use implementation specific behavior to deal with card detection. [C] cd-gpio present, broken-cd not present : This means that 'cd-gpio' line connects card-detect pad of the controller to the card-detect pin of the mmc slot. [D] cd-gpio present, broken-cd present : This means that there is nothing connected to the card-detect pad of the mmc host controller. Controller drivers are free to use the 'cd-gpio' line in any implementation specific way. Thanks, Thomas. -- 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
