[PATCH] mmc: dt: Add 'broken-cd' DT binding
'broken-cd' binding lets mmc controller device node to indicate that the card detect line is broken. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- The 'broken-cd' DT binding for MMC controllers is picked up from the OLPC project git repo and was originally conceived by Chris Ball c...@laptop.org. Documentation/devicetree/bindings/mmc/mmc.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 8a6811f..1aa527a 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -16,6 +16,8 @@ Optional properties: - wp-inverted: when present, polarity on the wp gpio line is inverted - non-removable: non-removable slot (like eMMC) - max-frequency: maximum operating clock frequency +- broken-cd: when present, indicates that the cd-gpios line is not + connected to the card-detect pad of the MMC host controller. Example: -- 1.6.6.rc2 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: dt: Add 'broken-cd' DT binding
'broken-cd' binding lets mmc controller device node to indicate that the card detect line is broken. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- The 'broken-cd' DT binding for MMC controllers is picked up from the OLPC project git repo and was originally conceived by Chris Ball c...@laptop.org. Documentation/devicetree/bindings/mmc/mmc.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 8a6811f..1aa527a 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -16,6 +16,8 @@ Optional properties: - wp-inverted: when present, polarity on the wp gpio line is inverted - non-removable: non-removable slot (like eMMC) - max-frequency: maximum operating clock frequency +- broken-cd: when present, indicates that the cd-gpios line is not + connected to the card-detect pad of the MMC host controller. Example: -- 1.6.6.rc2 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
On Tuesday 21 August 2012, Thomas Abraham wrote: diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 8a6811f..1aa527a 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -16,6 +16,8 @@ Optional properties: - wp-inverted: when present, polarity on the wp gpio line is inverted - non-removable: non-removable slot (like eMMC) - max-frequency: maximum operating clock frequency +- broken-cd: when present, indicates that the cd-gpios line is not + connected to the card-detect pad of the MMC host controller. What is the difference between listing the cd line as broken and listing no cd line at all? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
Hi, On Tue, Aug 21 2012, Arnd Bergmann wrote: On Tuesday 21 August 2012, Thomas Abraham wrote: diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 8a6811f..1aa527a 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -16,6 +16,8 @@ Optional properties: - wp-inverted: when present, polarity on the wp gpio line is inverted - non-removable: non-removable slot (like eMMC) - max-frequency: maximum operating clock frequency +- broken-cd: when present, indicates that the cd-gpios line is not + connected to the card-detect pad of the MMC host controller. What is the difference between listing the cd line as broken and listing no cd line at all? I think the documentation's incorrect here -- broken-cd should be used without a cd-gpios node, and tells the driver that there is no working WP and we'll need to poll the host (SDHCI_QUIRK_BROKEN_CARD_DETECTION): diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c index 25733ef..23ebdbb 100644 --- a/drivers/mmc/host/sdhci-pxav3.c +++ b/drivers/mmc/host/sdhci-pxav3.c @@ -198,6 +198,9 @@ static struct sdhci_pxa_platdata *pxav3_get_mmc_pdata(struct device *dev) if (clk_delay_cycles 0) pdata-clk_delay_cycles = clk_delay_cycles; + if (of_find_property(np, broken-cd, NULL)) + pdata-quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION; + return pdata; } #else So, I'd say: - broken-cd: when present, indicates that there is no card-detect line available on the host; polling should be used instead. Thanks, - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
On 21 August 2012 16:31, Arnd Bergmann a...@arndb.de wrote: On Tuesday 21 August 2012, Thomas Abraham wrote: diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 8a6811f..1aa527a 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -16,6 +16,8 @@ Optional properties: - wp-inverted: when present, polarity on the wp gpio line is inverted - non-removable: non-removable slot (like eMMC) - max-frequency: maximum operating clock frequency +- broken-cd: when present, indicates that the cd-gpios line is not + connected to the card-detect pad of the MMC host controller. What is the difference between listing the cd line as broken and listing no cd line at all? I am trying to have a way to represent a gpio line as card detect line that is not connected to the card-detect pad of the mmc controller but instead used as a gpio interrupt line or polled gpio line. 'broken-cd' would imply that the card-detect pad of the mmc controller is not connected to the card-detect pin at the slot. The 'cd-gpios' property in that case would let the driver code to use the 'cd-gpios' line as the external gpio interrupt or poll it. Thanks, Thomas. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] pinctrl: add samsung pinctrl and gpiolib driver
On Wed, Aug 15, 2012 at 9:57 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
Add a new device tree enabled pinctrl and gpiolib driver for Samsung
SoC's.
Thanks for doing this Thomas, great work!
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
I don't understand the rules around bindings very well, I would
suggest you include
devicetree-disc...@lists.ozlabs.org on the mails, besides you know
this stuff way
better than me anyway :-)
+ The child node can also optionally specify one or more of the pin
+ configuration that should be applied on all the pins listed in the
+ samsung,pins property of the child node. The following pin configuration
+ properties are supported.
+
+ - samsung,pin-pud: Pull up/down configuration.
+ - samsung,pin-drv: Drive strength configuration.
+ - samsung,pin-pud-pdn: Pull up/down configuration in power down mode.
+ - samsung,pin-drv-pdn: Drive strength configuration in power down mode.
This looks a bit scary, as it seems to be orthogonal to the pin config
interface. I.e. this will be programmed behind the back of the
pin config system. However as long as the pin config implementation
reads back these things from the registers it will work, too.
In the U300 and Ux500 I explicitly use pin config hogs to set up
the pin configuration, and when we enter a state such as
default the mux setting and config settings are set from the
framework separately.
See for example:
arch/arm/mach-ux500/board-mop500-pins.c
This example is using platform data but it should be trivial to do with
device tree.
I think the Tegra also works this way. Can you elaborate on
why you need this static setup from the device tree instead
of using default states?
I also think this looks like it could use generic pin config to stash
the configs, just expand the stuff in linux/pinctrl/pinconf-generic.h
(...)
+Example 1:
The examples seem to only pertain to the pin controller per se, maybe you
could include a DT entry for a uart or something showing how the
uart device binds to a certain pinctrl setting.
+ pinctrl_0: pinctrl@1140 {
+ compatible = samsung,pinctrl-exynos4210;
+ reg = 0x1140 0x1000;
+ interrupts = 0 47 0;
+
+ uart0_data: uart0-data {
+ samsung,pins = gpa0-0, gpa0-1;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
This setup needs to be associated with a certain state, it's possible to
do in the code or directly in the device tree.
I.e. these settings for pin-pud and pin-drv needs to belong to a
certain pin config state, typically the state named default
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
+config PINCTRL_SAMSUNG
+ bool Samsung pinctrl driver
+ depends on OF
I don't understand how this can even compile. Do you need:
select PINMUX
select PINCONF
to get the framework files you need to compile?
Or are you selecting thes in some platform Kconfig or so?
In that case please move them here.
+/* list of all possible config options supported */
+struct pin_config {
+ char*prop_cfg;
+ unsigned intcfg_type;
+} pcfgs[] = {
+ { samsung,pin-pud, PINCFG_TYPE_PUD },
+ { samsung,pin-drv, PINCFG_TYPE_DRV },
+ { samsung,pin-pud-pdn, PINCFG_TYPE_CON_PND },
+ { samsung,pin-drv-pdn, PINCFG_TYPE_PUD_PND },
+};
Hm it looks very much like this controller could make use of
the generic pinconf library, but it's not mandatory so just a suggestion.
(...)
+/* create pinctrl_map entries by parsing device tree nodes */
+static int samsung_dt_node_to_map(struct pinctrl_dev *pctldev,
+ struct device_node *np, struct pinctrl_map **maps,
+ unsigned *nmaps)
+{
(...)
+ /* Allocate memory for pin group name. The pin group name is derived
+* from the node name from which these map entries are be created.
+*/
+ gname = kzalloc(strlen(np-name) + 4, GFP_KERNEL);
Why +4? I would have suspected +1 for the null terminator...
+ if (!gname) {
+ dev_err(dev, failed to alloc memory for group name\n);
+ goto free_map;
+ }
+ sprintf(gname, %s-grp, np-name);
The rest of the pinmux implementation looks nice!
(...)
+/* set the pull up/down and driver strength settings for a specified pin */
+static int samsung_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
+ unsigned long config)
+{
+ struct samsung_pinctrl_drv_data *drvdata;
+ unsigned long pin_offset;
+ struct samsung_pin_bank *bank;
+ void __iomem *reg;
+
+ drvdata = pinctrl_dev_get_drvdata(pctldev);
+ pin_to_reg_bank(drvdata-gc, pin - drvdata-ctrl-base, reg,
+
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
Hi, On Tue, Aug 21 2012, Thomas Abraham wrote: I am trying to have a way to represent a gpio line as card detect line that is not connected to the card-detect pad of the mmc controller but instead used as a gpio interrupt line or polled gpio line. 'broken-cd' would imply that the card-detect pad of the mmc controller is not connected to the card-detect pin at the slot. The 'cd-gpios' property in that case would let the driver code to use the 'cd-gpios' line as the external gpio interrupt or poll it. How about this? broken-cd: No CD available, use polling. cd-gpios: The CD pin on the host is working and brought out to a GPIO. external-cd-gpios: The CD pin on the host is broken, but there's an independent external GPIO available. (Each host should only have one of these properties.) Thanks, - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] pinctrl: add exynos4210 specific extensions for samsung pinctrl driver
On Wed, Aug 15, 2012 at 9:57 PM, Thomas Abraham thomas.abra...@linaro.org wrote: Add information about the Exynos4210 pin banks and driver data which is used by the Samsung pinctrl driver. In addition to this, the support for external gpio and wakeup interrupt support is included and hooked up with the Samsung pinctrl driver. OK... diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig +config PINCTRL_EXYNOS4 + bool Pinctrl driver data for Exynos4 SoC + depends on ARCH_EXYNOS4 OF Since you depend on PINCTRL_SAMSUNG which depends on OF you don't need to depend on OF here. + depends on PINCTRL_SAMSUNG + select PINMUX + select PINCONF So as noted in the main driver, let PINCTRL_SAMSUNG select PINMUX and PINCONF and you need only select PINCTRL_SAMSUNG here. diff --git a/drivers/pinctrl/pinctrl-exynos.c b/drivers/pinctrl/pinctrl-exynos.c (...) +#include linux/interrupt.h +#include linux/irqdomain.h +#include linux/irq.h +#include linux/of_irq.h Do you need these includes? Didn't you put them all in pinctrl-samsung.h? Overall this looks good and straight-forward, but I cannot figure out how the samsung_pinctrl_soc_data is passed to the main driver, it seems to be through some DT node but I cannot figure this out. Can you explain this? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] ARM: EXYNOS: skip wakeup interrupt setup if pinctrl driver is used
On Wed, Aug 15, 2012 at 9:57 PM, Thomas Abraham thomas.abra...@linaro.org wrote: Pinctrl driver includes support for configuring the external wakeup interrupts. On exynos platforms that use pinctrl driver, the setup of wakeup interrupts in the exynos platform code can be skipped. Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Thomas Abraham thomas.abra...@linaro.org +#ifdef CONFIG_OF Don't you actually want to use: #fidef CONFIG_PINCTRL_SAMSUNG here? CONFIG_OF is a bit vague. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] gpio: exynos4: skip gpiolib registration if pinctrl driver is used
On Wed, Aug 15, 2012 at 9:57 PM, Thomas Abraham thomas.abra...@linaro.org wrote: Pinctrl driver, when enabled, registers all the gpio pins and hence the registration of gpio pins by this driver can be skipped. Acked-by: Grant Likely grant.lik...@secretlab.ca Acked-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Thomas Abraham thomas.abra...@linaro.org +#ifdef CONFIG_OF Wouldn't it be better to use #ifdef CONFIG_PINCTRL_SAMSUNG? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
On Tuesday 21 August 2012, Chris Ball wrote: How about this? broken-cd: No CD available, use polling. cd-gpios: The CD pin on the host is working and brought out to a GPIO. external-cd-gpios: The CD pin on the host is broken, but there's an independent external GPIO available. (Each host should only have one of these properties.) The fsl-imx-esdhc.txt binding already has all three cases, but describes them differently: fsl,cd-internal: when present, the CD pin on the host is working cd-gpios: when present, contains the gpio line that CD is connected to If both are absent, it has to use polling. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
On 21 August 2012 17:26, Chris Ball c...@laptop.org wrote: Hi, On Tue, Aug 21 2012, Thomas Abraham wrote: I am trying to have a way to represent a gpio line as card detect line that is not connected to the card-detect pad of the mmc controller but instead used as a gpio interrupt line or polled gpio line. 'broken-cd' would imply that the card-detect pad of the mmc controller is not connected to the card-detect pin at the slot. The 'cd-gpios' property in that case would let the driver code to use the 'cd-gpios' line as the external gpio interrupt or poll it. How about this? broken-cd: No CD available, use polling. cd-gpios: The CD pin on the host is working and brought out to a GPIO. external-cd-gpios: The CD pin on the host is broken, but there's an independent external GPIO available. (Each host should only have one of these properties.) How about a property using 'cd-external' property in place of 'external-cd-gpios'. 'cd-external' would mean that the gpio listed by 'cd-gpios' is a gpio line which is not connected the card-detect pad of the mmc controller. This can simplfy the dt parsing code since it is required to look for only one gpio property, which is 'cd-gpios' which implies lesser error handling code. 'cd-external' can qualify it further as an external cd pin. Either way, I am fine with the binding you have proposed. If you post a patch for these new bindings, I will base the sdhci-s3c dt patch on top of that patch. Thanks, Thomas. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: EXYNOS: Enable PINCTRL config option for Exynos4 device tree enabled platform
On Wed, Aug 15, 2012 at 10:10 PM, Thomas Abraham thomas.abra...@linaro.org wrote: This enables support for Samsung and Exynos4 pinctrl driver for device tree enabled Exynos4 platforms. Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- arch/arm/mach-exynos/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index b5b4c8c..ad96c59 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -405,6 +405,7 @@ config MACH_EXYNOS4_DT select USE_OF select ARM_AMBA select HAVE_SAMSUNG_KEYPAD if INPUT_KEYBOARD + select PINCTRL I don't think this works, since PINCTRL_SAMSUNG is not default y (nor should it be). For the platforms I converted I had to select both the subsystem and the indivudual driver, as is already done for some GPIO controllers for example: select PINCTRL select PINCTRL_SAMSUNG Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: Add pinctrl node entries for Samsung Exynos4210 SoC
On Wed, Aug 15, 2012 at 10:10 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
+ pinctrl@1140 {
+ uart0_data: uart0-data {
+ samsung,pins = gpa0-0, gpa0-1;
+ samsung,pin-function = 0x2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
Apart from the pin-pud and pin-drv stuff this patch looks fine. These two
things I want to discuss in the other mail thread (controller core) first.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
On 08/21/2012 07:08 AM, Arnd Bergmann wrote: On Tuesday 21 August 2012, Chris Ball wrote: How about this? broken-cd: No CD available, use polling. cd-gpios: The CD pin on the host is working and brought out to a GPIO. external-cd-gpios: The CD pin on the host is broken, but there's an independent external GPIO available. (Each host should only have one of these properties.) The fsl-imx-esdhc.txt binding already has all three cases, but describes them differently: fsl,cd-internal: when present, the CD pin on the host is working cd-gpios: when present, contains the gpio line that CD is connected to If both are absent, it has to use polling. This makes the most sense to me. However, I prefer broken-cd over cd-internal. The binding should add properties for exceptions, not SDHCI spec compliant implementations. Rob -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
Hi, adding Shawn and Wolfram,
On Tue, Aug 21 2012, Arnd Bergmann wrote:
On Tuesday 21 August 2012, Chris Ball wrote:
How about this?
broken-cd: No CD available, use polling.
cd-gpios: The CD pin on the host is working and brought out to a GPIO.
external-cd-gpios: The CD pin on the host is broken, but there's an
independent external GPIO available.
(Each host should only have one of these properties.)
The fsl-imx-esdhc.txt binding already has all three cases, but
describes them differently:
fsl,cd-internal: when present, the CD pin on the host is working
cd-gpios: when present, contains the gpio line that CD is connected to
If both are absent, it has to use polling.
Aside: the bindings do not match the code. The bindings document says
to use fsl,cd-internal, and imx51-babbage.dts does so -- but the code
doesn't check for fsl,cd-internal, it checks for fsl,cd-controller:
if (of_get_property(np, fsl,cd-controller, NULL))
boarddata-cd_type = ESDHC_CD_CONTROLLER;
The same confusion is present for fsl,wp-{controller,internal}.
Ignoring that, these bindings are similar, but not the same -- imx-esdhc
only allows one of the cd_type cases to be true, so you either have
cd-internal or you have cd-gpios:
if (of_get_property(np, fsl,cd-controller, NULL))
boarddata-cd_type = ESDHC_CD_CONTROLLER;
boarddata-cd_gpio = of_get_named_gpio(np, cd-gpios, 0);
if (gpio_is_valid(boarddata-cd_gpio))
boarddata-cd_type = ESDHC_CD_GPIO;
This differs from Thomas's binding -- he wants a way to say the cd-gpio
mentioned in cd-gpios is [internal/external] to the card's CD pin.
Rob Herring said:
This makes the most sense to me. However, I prefer broken-cd over
cd-internal. The binding should add properties for exceptions, not SDHCI
spec compliant implementations.
Agreed, I was going to say the same thing. Putting it all together, it
sounds like we want:
no extra properties: the CD pin on the host just works.
broken-cd:the CD pin on the host is broken; use polling.
cd-gpios: the GPIO listed is the CD pin on the host being
brought out directly to a GPIO.
cd-external: when used with cd-gpios, specifies that the GPIO
in cd-gpios is external to the CD pin on the host.
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.
Shawn, I guess I'll leave it up to you on whether/when you'd like to
move away from the fsl, properties to the new common ones?
If this looks okay to everyone, I'll send a patch soon.
Thanks!
- Chris.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
On 08/21/2012 09:48 AM, Chris Ball wrote: Hi, adding Shawn and Wolfram, snip... Rob Herring said: This makes the most sense to me. However, I prefer broken-cd over cd-internal. The binding should add properties for exceptions, not SDHCI spec compliant implementations. Agreed, I was going to say the same thing. Putting it all together, it sounds like we want: no extra properties: the CD pin on the host just works. broken-cd:the CD pin on the host is broken; use polling. cd-gpios: the GPIO listed is the CD pin on the host being brought out directly to a GPIO. cd-external: when used with cd-gpios, specifies that the GPIO in cd-gpios is external to the CD pin on the host. 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. Rob -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
On 21 August 2012 20:33, Rob Herring robherri...@gmail.com wrote: On 08/21/2012 09:48 AM, Chris Ball wrote: Hi, adding Shawn and Wolfram, snip... Rob Herring said: This makes the most sense to me. However, I prefer broken-cd over cd-internal. The binding should add properties for exceptions, not SDHCI spec compliant implementations. Agreed, I was going to say the same thing. Putting it all together, it sounds like we want: no extra properties: the CD pin on the host just works. broken-cd:the CD pin on the host is broken; use polling. cd-gpios: the GPIO listed is the CD pin on the host being brought out directly to a GPIO. cd-external: when used with cd-gpios, specifies that the GPIO in cd-gpios is external to the CD pin on the host. 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. There should be way to distinguish between the two types of 'cd-gpios' value. (A) a 'cd-gpios' line that connects the card-detect pin of the mmc physical slot to the card-detect pad to the mmc host controller. (B) a 'cd-gpios' line that is connected to the card-detect pin of the slot but not to the card-detect pad of the mmc host controller (used either as gpio interrupt or polled gpio line). So the binding 'cd-external' can act as an additional qualifier to value of 'cd-gpios' to represent the second type. Hence, the bindings proposed by Chris does support all the possible combinations of card-detection used by the Samsung sdhci controller driver. Thanks, Thomas. Rob -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
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. Rob Thanks, - Chris. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
On 21 August 2012 21:31, Rob Herring robherri...@gmail.com 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-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
On 8/21/2012 7:33 AM, Thomas Abraham wrote: On 21 August 2012 21:31, Rob Herring robherri...@gmail.com 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. Matrix encoding is too complicated; my brain froze when trying to decode the message above. I favor properties that can be understood in isolation. The following proberties are mutually-exclusive. no properties present: The standard SDHCI register bit just works. No additional setup is necessary (either the system is hardwired to work correctly or external software has already done any necessary setup). broken-cd no value: CD is just not available - neither via the standard SDHCI register bit/interrupt, nor by an external GPIO. cd-gpios gpio, active_low : The standard SDHCI register bit does not work, but CD is available via the specified GPIO. If active_low is 0, reading 1 from the GPIO pin means that the card is present, otherwise reading 0 from the GPIO pin means that the card is present. I must emphasize that this is an external GPIO, accessed via GPIO mechanisms, not a connection of a multipurpose pin to the SDHCI core. cd-pin pin : The standard SDHCI register bit works, but the SDHCI driver must ask for the indicated multipurpose pin to be connected to the SDHCI controller as the CD pin. I don't know what pin is, exactly, as I haven't been paying attention to the pinmux discussions. Thanks, Thomas. ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- To unsubscribe from this list: send the line
Re: [PATCH v2 1/4] pinctrl: add samsung pinctrl and gpiolib driver
On 08/21/2012 05:25 AM, Linus Walleij wrote: On Wed, Aug 15, 2012 at 9:57 PM, Thomas Abraham thomas.abra...@linaro.org wrote: Add a new device tree enabled pinctrl and gpiolib driver for Samsung SoC's. ... + The child node can also optionally specify one or more of the pin + configuration that should be applied on all the pins listed in the + samsung,pins property of the child node. The following pin configuration + properties are supported. + + - samsung,pin-pud: Pull up/down configuration. + - samsung,pin-drv: Drive strength configuration. + - samsung,pin-pud-pdn: Pull up/down configuration in power down mode. + - samsung,pin-drv-pdn: Drive strength configuration in power down mode. This looks a bit scary, as it seems to be orthogonal to the pin config interface. I.e. this will be programmed behind the back of the pin config system. However as long as the pin config implementation reads back these things from the registers it will work, too. In the U300 and Ux500 I explicitly use pin config hogs to set up the pin configuration, and when we enter a state such as default the mux setting and config settings are set from the framework separately. I know that some HW has a separate set of registers (or fields) for the awake and sleep configuration, and the HW switches between the two automatically when sleeping. I have no idea if the Samsung SoCs do this, but I think if this were the case, it'd be quite legitimate to define both these HW states as separate sets of properties within a single pinctrl SW state. So, that might be the explanation here? -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] pinctrl: add samsung pinctrl and gpiolib driver
Hi Linus,
Thanks for your time to review the Samsung pinctrl driver patches. I
have inlined the reply to your comments.
On 21 August 2012 16:55, Linus Walleij linus.wall...@linaro.org wrote:
On Wed, Aug 15, 2012 at 9:57 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
Add a new device tree enabled pinctrl and gpiolib driver for Samsung
SoC's.
Thanks for doing this Thomas, great work!
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
I don't understand the rules around bindings very well, I would
suggest you include
devicetree-disc...@lists.ozlabs.org on the mails, besides you know
this stuff way
better than me anyway :-)
Yes, I missed Cc'ing devicetree-disc...@lists.ozlabs.org. I will do
that in the post of this patch set.
+ The child node can also optionally specify one or more of the pin
+ configuration that should be applied on all the pins listed in the
+ samsung,pins property of the child node. The following pin configuration
+ properties are supported.
+
+ - samsung,pin-pud: Pull up/down configuration.
+ - samsung,pin-drv: Drive strength configuration.
+ - samsung,pin-pud-pdn: Pull up/down configuration in power down mode.
+ - samsung,pin-drv-pdn: Drive strength configuration in power down mode.
This looks a bit scary, as it seems to be orthogonal to the pin config
interface. I.e. this will be programmed behind the back of the
pin config system. However as long as the pin config implementation
reads back these things from the registers it will work, too.
These properties are converted to a PIN_MAP_TYPE_CONFIGS_GROUP map
type and stored in a instance of 'struct pinctrl_map'. These can be
read back from the registers and reverse-mapped as well.
All the dt bindings defined and used in the Samsung pinctrl driver are
first translated into pinctrl subystem defined data structures and
then used. Hence, there are no register configurations done that skip
over the pinctrl subsystem (except for the gpio/wakeup interrupts).
In the U300 and Ux500 I explicitly use pin config hogs to set up
the pin configuration, and when we enter a state such as
default the mux setting and config settings are set from the
framework separately.
See for example:
arch/arm/mach-ux500/board-mop500-pins.c
This example is using platform data but it should be trivial to do with
device tree.
I think the Tegra also works this way. Can you elaborate on
why you need this static setup from the device tree instead
of using default states?
Sorry, I did not understand this question.
I also think this looks like it could use generic pin config to stash
the configs, just expand the stuff in linux/pinctrl/pinconf-generic.h
(...)
+Example 1:
The examples seem to only pertain to the pin controller per se, maybe you
could include a DT entry for a uart or something showing how the
uart device binds to a certain pinctrl setting.
Yes, such an example will be informative here. I will add an example for this.
+ pinctrl_0: pinctrl@1140 {
+ compatible = samsung,pinctrl-exynos4210;
+ reg = 0x1140 0x1000;
+ interrupts = 0 47 0;
+
+ uart0_data: uart0-data {
+ samsung,pins = gpa0-0, gpa0-1;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
This setup needs to be associated with a certain state, it's possible to
do in the code or directly in the device tree.
I.e. these settings for pin-pud and pin-drv needs to belong to a
certain pin config state, typically the state named default
Yes, I agree. So, for example, the uart device node would have
uart@1380 {
compatilble = ;
rest of the properties here
pinctrl-names = default;
pinctrl-0 - uart0_data;
};
The uart driver during probe can then call
devm_pinctrl_get_select_default(pdev-dev);
For the example above, this call will set the 'mux', 'pud' and 'drv'
values to gpa-0 and gpa-1 pins.
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
+config PINCTRL_SAMSUNG
+ bool Samsung pinctrl driver
+ depends on OF
I don't understand how this can even compile. Do you need:
select PINMUX
select PINCONF
to get the framework files you need to compile?
Or are you selecting thes in some platform Kconfig or so?
In that case please move them here.
These were selected if PINCTRL_EXYNOS4 config option is selected. This
is in the 2/4 patch of this series. But, as you said, PINMUX and
PINCONF should be selected with PINCTRL_SAMSUNG config option. I will
fix this.
+/* list of all possible config options supported */
+struct pin_config {
+ char*prop_cfg;
+ unsigned
Re: [PATCH v2 2/4] pinctrl: add exynos4210 specific extensions for samsung pinctrl driver
On 21 August 2012 17:32, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Aug 15, 2012 at 9:57 PM, Thomas Abraham thomas.abra...@linaro.org wrote: Add information about the Exynos4210 pin banks and driver data which is used by the Samsung pinctrl driver. In addition to this, the support for external gpio and wakeup interrupt support is included and hooked up with the Samsung pinctrl driver. OK... diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig +config PINCTRL_EXYNOS4 + bool Pinctrl driver data for Exynos4 SoC + depends on ARCH_EXYNOS4 OF Since you depend on PINCTRL_SAMSUNG which depends on OF you don't need to depend on OF here. Ok. + depends on PINCTRL_SAMSUNG + select PINMUX + select PINCONF So as noted in the main driver, let PINCTRL_SAMSUNG select PINMUX and PINCONF and you need only select PINCTRL_SAMSUNG here. Ok. diff --git a/drivers/pinctrl/pinctrl-exynos.c b/drivers/pinctrl/pinctrl-exynos.c (...) +#include linux/interrupt.h +#include linux/irqdomain.h +#include linux/irq.h +#include linux/of_irq.h Do you need these includes? Didn't you put them all in pinctrl-samsung.h? Yes, I will fix this. Overall this looks good and straight-forward, but I cannot figure out how the samsung_pinctrl_soc_data is passed to the main driver, it seems to be through some DT node but I cannot figure this out. Can you explain this? The main driver uses the .data field of the of_device_id structure to pass the pointer of the SoC data. So, upon match of a compatible value which is supported by the main driver with that in dt, the of_match_node() call can be used to find out the corresponding SoC data. There are included in the first patch (reference: samsung_pinctrl_get_soc_data() function and samsung_pinctrl_dt_mach structure). Yours, Linus Walleij Thanks, Thomas. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] gpio: exynos4: skip gpiolib registration if pinctrl driver is used
On 21 August 2012 17:35, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Aug 15, 2012 at 9:57 PM, Thomas Abraham thomas.abra...@linaro.org wrote: Pinctrl driver, when enabled, registers all the gpio pins and hence the registration of gpio pins by this driver can be skipped. Acked-by: Grant Likely grant.lik...@secretlab.ca Acked-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Thomas Abraham thomas.abra...@linaro.org +#ifdef CONFIG_OF Wouldn't it be better to use #ifdef CONFIG_PINCTRL_SAMSUNG? Yes, this would be better. I will fix this. Yours, Linus Walleij Thanks, Thomas. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] ARM: EXYNOS: skip wakeup interrupt setup if pinctrl driver is used
On 21 August 2012 17:34, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Aug 15, 2012 at 9:57 PM, Thomas Abraham thomas.abra...@linaro.org wrote: Pinctrl driver includes support for configuring the external wakeup interrupts. On exynos platforms that use pinctrl driver, the setup of wakeup interrupts in the exynos platform code can be skipped. Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Thomas Abraham thomas.abra...@linaro.org +#ifdef CONFIG_OF Don't you actually want to use: #fidef CONFIG_PINCTRL_SAMSUNG here? CONFIG_OF is a bit vague. Ok. I will use CONFIG_PINCTRL_SAMSUNG here. Yours, Linus Walleij Thanks, Thomas. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: EXYNOS: Enable PINCTRL config option for Exynos4 device tree enabled platform
On 21 August 2012 18:01, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Aug 15, 2012 at 10:10 PM, Thomas Abraham thomas.abra...@linaro.org wrote: This enables support for Samsung and Exynos4 pinctrl driver for device tree enabled Exynos4 platforms. Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- arch/arm/mach-exynos/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index b5b4c8c..ad96c59 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -405,6 +405,7 @@ config MACH_EXYNOS4_DT select USE_OF select ARM_AMBA select HAVE_SAMSUNG_KEYPAD if INPUT_KEYBOARD + select PINCTRL I don't think this works, since PINCTRL_SAMSUNG is not default y (nor should it be). I think I got this wrong. PINCTRL_SAMSUNG depends of OF, which is not correct. The correct way would be select PINCTRL_SAMSUNG from PINCTRL_EXYNOS4. I will fix this. For the platforms I converted I had to select both the subsystem and the indivudual driver, as is already done for some GPIO controllers for example: select PINCTRL select PINCTRL_SAMSUNG Yours, Linus Walleij Thanks, Thomas. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] pinctrl: add samsung pinctrl and gpiolib driver
On 22 August 2012 03:08, Stephen Warren swar...@wwwdotorg.org wrote: On 08/21/2012 05:25 AM, Linus Walleij wrote: On Wed, Aug 15, 2012 at 9:57 PM, Thomas Abraham thomas.abra...@linaro.org wrote: Add a new device tree enabled pinctrl and gpiolib driver for Samsung SoC's. ... + The child node can also optionally specify one or more of the pin + configuration that should be applied on all the pins listed in the + samsung,pins property of the child node. The following pin configuration + properties are supported. + + - samsung,pin-pud: Pull up/down configuration. + - samsung,pin-drv: Drive strength configuration. + - samsung,pin-pud-pdn: Pull up/down configuration in power down mode. + - samsung,pin-drv-pdn: Drive strength configuration in power down mode. This looks a bit scary, as it seems to be orthogonal to the pin config interface. I.e. this will be programmed behind the back of the pin config system. However as long as the pin config implementation reads back these things from the registers it will work, too. In the U300 and Ux500 I explicitly use pin config hogs to set up the pin configuration, and when we enter a state such as default the mux setting and config settings are set from the framework separately. I know that some HW has a separate set of registers (or fields) for the awake and sleep configuration, and the HW switches between the two automatically when sleeping. I have no idea if the Samsung SoCs do this, but I think if this were the case, it'd be quite legitimate to define both these HW states as separate sets of properties within a single pinctrl SW state. So, that might be the explanation here? Hi Stephen, Yes, Samsung SoC support the awake and sleep configuration in that way you described. Thanks, Thomas. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
On Tue, Aug 21, 2012 at 11:03:59PM +0530, Thomas Abraham wrote: 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. The following is what I have on my mind. broken-cd cd-gpiosimplication --- no no SDHCI CD no yes GPIO CD yes no NO CD / Broken CD yes yes Invalid yes: property presents no: property does not present -- Regards, Shawn -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
