[PATCH] ARM: SAMSUNG: Fix HDMI related warnings
Silences the following warnings: arch/arm/plat-samsung/devs.c:765:31: warning: symbol 's5p_hdmi_def_platdata' was not declared. Should it be static? arch/arm/plat-samsung/devs.c:767:13: warning: symbol 's5p_hdmi_set_platdata' was not declared. Should it be static? Signed-off-by: Sachin Kamat --- arch/arm/plat-samsung/devs.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c index 6ff45d5..565cea7 100644 --- a/arch/arm/plat-samsung/devs.c +++ b/arch/arm/plat-samsung/devs.c @@ -51,6 +51,7 @@ #include #include #include +#include #include #include #include @@ -762,7 +763,7 @@ void __init s5p_i2c_hdmiphy_set_platdata(struct s3c2410_platform_i2c *pd) &s5p_device_i2c_hdmiphy); } -struct s5p_hdmi_platform_data s5p_hdmi_def_platdata; +static struct s5p_hdmi_platform_data s5p_hdmi_def_platdata; void __init s5p_hdmi_set_platdata(struct i2c_board_info *hdmiphy_info, struct i2c_board_info *mhl_info, int mhl_bus) -- 1.7.4.1 -- 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 28 August 2012 04:52, Linus Walleij wrote:
> On Tue, Aug 21, 2012 at 9:22 PM, Thomas Abraham
> wrote:
[...]
+/* 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.
>>
>> Ok. The last two entries in the above table are Samsung specific and
>> not covered by generic-pinconf. So, I am not sure if it can be added
>> to generic-pinconf.
>
> What is so Samsung-specific about them?
>
> If you tell us the electrical property of setting them we can figure out
> if they should be generic or not...
>
The PINCFG_TYPE_CON_PND and PINCFG_TYPE_PUD_PND are "mux function" and
"pull up/down" settings that are automatically applied to the pin in
powert-down mode. It is same as the usual "mux function" and "pull
up/down" settings, but just that it is applied at suspend.
[...]
>
> OK whatever... looking formward to next iteration!
I have posted the updated version of this patch series based on your
comments (https://lkml.org/lkml/2012/8/23/183).
The only pending comment to be addressed at this point is about the
use of generic-pinconf as mentioned in the comment above. If
PINCFG_TYPE_CON_PND and PINCFG_TYPE_PUD_PND is available in
generic-pinconf, I wil switch to using generic-pinconf. Will that
qualify this Samsung pinctrl driver to be merged into your -devel
branch?
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 v4 9/9] mmc: dw_mmc: add support for exynos specific implementation of dw-mshc
On 28 August 2012 10:46, Jaehoon Chung wrote:
> On 08/28/2012 02:10 PM, Thomas Abraham wrote:
>> On 28 August 2012 10:40, Thomas Abraham wrote:
>>> On 28 August 2012 10:25, Jaehoon Chung wrote:
Hi Thomas,
On 08/28/2012 01:48 PM, Thomas Abraham wrote:
> On 27 August 2012 14:28, Jaehoon Chung wrote:
>> Hi Thomas,
>>
>>> + gpio = of_get_named_gpio(slot_np, "wp-gpios", 0);
>>> + if (gpio_is_valid(gpio)) {
>>> + if (devm_gpio_request(host->dev, gpio, "dw-mci-wp"))
>>> + dev_info(host->dev, "gpio [%d] request failed\n",
>>> + gpio);
>>> + } else {
>>> + dev_info(host->dev, "wp gpio not available");
>>> + host->pdata->quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
>>> + }
>>> +
>>> + if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
>>> + return 0;
>>> +
>>> + gpio = of_get_named_gpio(slot_np, "samsung,cd-pinmux-gpio", 0);
>>> + if (gpio_is_valid(gpio)) {
>>> + if (devm_gpio_request(host->dev, gpio, "dw-mci-cd"))
>> I'm not sure, but i saw mmc_gpio_request_cd() into
>> drivers/mmc/core/slot-gpio.c.
>> Can we use this? i think we can use them.
>> Just my opinion.
>
> Thanks for letting me know about this, I was not aware of this.
> Looking into this code, it is usable for controllers that use a gpio
> (specified using cd-gpios property) as card-detect line. As you know,
> the dw-mmc driver does not support this feature yet. In case of
> exynos, the card-detect pin of the mmc slot is connected to the
> card-detect pad of the dw-mmc controller using pinmux, which is not
> considered as a gpio. Hence, mmc_gpio_request_cd() is not applicable
> in this case.
But In case of external card-detect-pin, we can use the
mmc_gpio_request_cd().
>>>
>>> Yes, we can use. But the current dw-mmc controller driver does not
>>> support this feature yet. The existing driver considers that (a)
>>> card-detect line is connected to the card-detect pad of the controller
>>> or (b) it is broken. For Exynos5250, it is case (a). There is no
>>
>> Sorry, I meant smdk5250, not Exynos5250.
> Already i tested with my exynos5 board.
> If you want, i will share the patch.
But did you use "samsung,cd-pinmux-gpio" binding or "cd-gpios" binding
for specifying the card-detect line. I think, for your board, you have
to use "cd-gpios". But this patch series does not add support for
"cd-gpios".
Sure, I will like to have a look at your patch and understand more.
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 v4 9/9] mmc: dw_mmc: add support for exynos specific implementation of dw-mshc
On 08/28/2012 02:10 PM, Thomas Abraham wrote:
> On 28 August 2012 10:40, Thomas Abraham wrote:
>> On 28 August 2012 10:25, Jaehoon Chung wrote:
>>> Hi Thomas,
>>>
>>> On 08/28/2012 01:48 PM, Thomas Abraham wrote:
On 27 August 2012 14:28, Jaehoon Chung wrote:
> Hi Thomas,
>
>> + gpio = of_get_named_gpio(slot_np, "wp-gpios", 0);
>> + if (gpio_is_valid(gpio)) {
>> + if (devm_gpio_request(host->dev, gpio, "dw-mci-wp"))
>> + dev_info(host->dev, "gpio [%d] request failed\n",
>> + gpio);
>> + } else {
>> + dev_info(host->dev, "wp gpio not available");
>> + host->pdata->quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
>> + }
>> +
>> + if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
>> + return 0;
>> +
>> + gpio = of_get_named_gpio(slot_np, "samsung,cd-pinmux-gpio", 0);
>> + if (gpio_is_valid(gpio)) {
>> + if (devm_gpio_request(host->dev, gpio, "dw-mci-cd"))
> I'm not sure, but i saw mmc_gpio_request_cd() into
> drivers/mmc/core/slot-gpio.c.
> Can we use this? i think we can use them.
> Just my opinion.
Thanks for letting me know about this, I was not aware of this.
Looking into this code, it is usable for controllers that use a gpio
(specified using cd-gpios property) as card-detect line. As you know,
the dw-mmc driver does not support this feature yet. In case of
exynos, the card-detect pin of the mmc slot is connected to the
card-detect pad of the dw-mmc controller using pinmux, which is not
considered as a gpio. Hence, mmc_gpio_request_cd() is not applicable
in this case.
>>> But In case of external card-detect-pin, we can use the
>>> mmc_gpio_request_cd().
>>
>> Yes, we can use. But the current dw-mmc controller driver does not
>> support this feature yet. The existing driver considers that (a)
>> card-detect line is connected to the card-detect pad of the controller
>> or (b) it is broken. For Exynos5250, it is case (a). There is no
>
> Sorry, I meant smdk5250, not Exynos5250.
Already i tested with my exynos5 board.
If you want, i will share the patch.
Best Regards,
Jaehoon Chung
>
>> support for using a gpio as an card-detect line.
>>
>> Thanks,
>> Thomas.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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 v4 9/9] mmc: dw_mmc: add support for exynos specific implementation of dw-mshc
On 28 August 2012 10:40, Thomas Abraham wrote:
> On 28 August 2012 10:25, Jaehoon Chung wrote:
>> Hi Thomas,
>>
>> On 08/28/2012 01:48 PM, Thomas Abraham wrote:
>>> On 27 August 2012 14:28, Jaehoon Chung wrote:
Hi Thomas,
> + gpio = of_get_named_gpio(slot_np, "wp-gpios", 0);
> + if (gpio_is_valid(gpio)) {
> + if (devm_gpio_request(host->dev, gpio, "dw-mci-wp"))
> + dev_info(host->dev, "gpio [%d] request failed\n",
> + gpio);
> + } else {
> + dev_info(host->dev, "wp gpio not available");
> + host->pdata->quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
> + }
> +
> + if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
> + return 0;
> +
> + gpio = of_get_named_gpio(slot_np, "samsung,cd-pinmux-gpio", 0);
> + if (gpio_is_valid(gpio)) {
> + if (devm_gpio_request(host->dev, gpio, "dw-mci-cd"))
I'm not sure, but i saw mmc_gpio_request_cd() into
drivers/mmc/core/slot-gpio.c.
Can we use this? i think we can use them.
Just my opinion.
>>>
>>> Thanks for letting me know about this, I was not aware of this.
>>> Looking into this code, it is usable for controllers that use a gpio
>>> (specified using cd-gpios property) as card-detect line. As you know,
>>> the dw-mmc driver does not support this feature yet. In case of
>>> exynos, the card-detect pin of the mmc slot is connected to the
>>> card-detect pad of the dw-mmc controller using pinmux, which is not
>>> considered as a gpio. Hence, mmc_gpio_request_cd() is not applicable
>>> in this case.
>> But In case of external card-detect-pin, we can use the
>> mmc_gpio_request_cd().
>
> Yes, we can use. But the current dw-mmc controller driver does not
> support this feature yet. The existing driver considers that (a)
> card-detect line is connected to the card-detect pad of the controller
> or (b) it is broken. For Exynos5250, it is case (a). There is no
Sorry, I meant smdk5250, not Exynos5250.
> support for using a gpio as an card-detect line.
>
> 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 v4 9/9] mmc: dw_mmc: add support for exynos specific implementation of dw-mshc
On 28 August 2012 10:25, Jaehoon Chung wrote:
> Hi Thomas,
>
> On 08/28/2012 01:48 PM, Thomas Abraham wrote:
>> On 27 August 2012 14:28, Jaehoon Chung wrote:
>>> Hi Thomas,
>>>
+ gpio = of_get_named_gpio(slot_np, "wp-gpios", 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host->dev, gpio, "dw-mci-wp"))
+ dev_info(host->dev, "gpio [%d] request failed\n",
+ gpio);
+ } else {
+ dev_info(host->dev, "wp gpio not available");
+ host->pdata->quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
+ }
+
+ if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
+ return 0;
+
+ gpio = of_get_named_gpio(slot_np, "samsung,cd-pinmux-gpio", 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host->dev, gpio, "dw-mci-cd"))
>>> I'm not sure, but i saw mmc_gpio_request_cd() into
>>> drivers/mmc/core/slot-gpio.c.
>>> Can we use this? i think we can use them.
>>> Just my opinion.
>>
>> Thanks for letting me know about this, I was not aware of this.
>> Looking into this code, it is usable for controllers that use a gpio
>> (specified using cd-gpios property) as card-detect line. As you know,
>> the dw-mmc driver does not support this feature yet. In case of
>> exynos, the card-detect pin of the mmc slot is connected to the
>> card-detect pad of the dw-mmc controller using pinmux, which is not
>> considered as a gpio. Hence, mmc_gpio_request_cd() is not applicable
>> in this case.
> But In case of external card-detect-pin, we can use the mmc_gpio_request_cd().
Yes, we can use. But the current dw-mmc controller driver does not
support this feature yet. The existing driver considers that (a)
card-detect line is connected to the card-detect pad of the controller
or (b) it is broken. For Exynos5250, it is case (a). There is no
support for using a gpio as an card-detect line.
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 v3 3/3] ARM: dts: Add nodes for dw_mmc controllers for Samsung Exynos5250 platforms
On 28 August 2012 04:16, Kukjin Kim wrote:
> On 08/26/12 04:59, Thomas Abraham wrote:
>>
>> Add device nodes for the four instances of dw_mmc controllers in
>> Exynos5250
>> and enable instance 0 and 2 for the smdk5250 board.
>>
>> Signed-off-by: Thomas Abraham
>> ---
>> arch/arm/boot/dts/exynos5250-smdk5250.dts | 57
>> -
>> arch/arm/boot/dts/exynos5250.dtsi | 32
>> 2 files changed, 88 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> index 8a5e348..6dc9faf 100644
>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> @@ -16,12 +16,19 @@
>> model = "SAMSUNG SMDK5250 board based on EXYNOS5250";
>> compatible = "samsung,smdk5250", "samsung,exynos5250";
>>
>> + aliases {
>> + mshc0 =&mshc_0;
>> + mshc1 =&mshc_1;
>> + mshc2 =&mshc_2;
>> + mshc3 =&mshc_3;
>> + };
>> +
>> memory {
>> reg =<0x4000 0x8000>;
>> };
>>
>> chosen {
>> - bootargs = "root=/dev/ram0 rw ramdisk=8192
>> console=ttySAC1,115200";
>> + bootargs = "root=/dev/ram0 rw ramdisk=8192
>> initrd=0x4100,8M console=ttySAC2,115200 init=/linuxrc";
>
>
> Yes, we need to sort out the 'bootargs' for using uart2 as a console, but
> you know, this should be separated :-)
>
Sorry, that was never intended to be in this patch. My mistake.
>
>> };
>>
>> i2c@12C6 {
>> @@ -72,6 +79,54 @@
>> status = "disabled";
>> };
>>
>> + mshc_0: dwmmc0@1220 {
>
>
> How about to keep the consistent naming? dwmmc or dw_mmc? I think, 'dw_mmc'
> makes more sense?
Ok.
>
>
>> + num-slots =<1>;
>> + supports-highspeed;
>> + broken-cd;
>> + fifo-depth =<0x80>;
>> + card-detect-delay =<200>;
>> + samsung,dw-mshc-sdr-timing =<2 3 3>;
>> + samsung,dw-mshc-ddr-timing =<1 2 3>;
>
>
> We need to think again the name of dw-mshc-sdr-timing, dw-mshc-ddr-timing?
Synopsis calls this controller "Mobile Storage Host Controller (MSHC)"
in their online data sheets. Hence, all the bindings (which are used
on non-samsung platforms as well) follow the this name. For any
Samsung specific code for this controller, we are free to choose any
name.
>
> [...]
>
>
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>> b/arch/arm/boot/dts/exynos5250.dtsi
>> index 004aaa8..f69e389 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -182,6 +182,38 @@
>> #size-cells =<0>;
>> };
>>
>> + dwmmc0@1220 {
>> + compatible = "samsung,exynos5250-dw-mshc";
>
>
> I'm not sure, 'exynos5250-dw-mshc' is right here. Because it is just dw_mmc
> controller on exynos5250. So...hmm...
There are differences in the implementation of the dw-mmc controller
in Exynos SoC's. So it has to be exynos5250-dw-mshc.
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 v3 2/3] ARM: Exynos5: Add AUXDATA support for MSHC controllers
On 28 August 2012 04:41, Kukjin Kim wrote:
> On 08/26/12 04:59, Thomas Abraham wrote:
>>
>> Add entries if MSHC controllers in AUXDATA table for correct device name
>> initialization.
>>
>> Signed-off-by: Abhilash Kesavan
>> Signed-off-by: Thomas Abraham
>> ---
>> arch/arm/mach-exynos/include/mach/map.h |1 +
>> arch/arm/mach-exynos/mach-exynos5-dt.c |8
>> 2 files changed, 9 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/include/mach/map.h
>> b/arch/arm/mach-exynos/include/mach/map.h
>> index 9d1f3ac..5b0ee41 100644
>> --- a/arch/arm/mach-exynos/include/mach/map.h
>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>> @@ -172,6 +172,7 @@
>>
>> #define EXYNOS4_PA_HSMMC(x) (0x1251 + ((x) * 0x1))
>> #define EXYNOS4_PA_DWMCI 0x1255
>> +#define EXYNOS5_PA_DWMCI(x)(0x1220 + ((x) * 0x1))
>
>
> Just, how about EXYNOS5_PA_DWMMC0, EXYNOS5_PA_DWMMC1, ... EXYNOS_PA_DWMMC3?
Ok.
>
> And if the addresses are different on other EXYNOS5 SoC, how do we handle it
> for auxdata?
I hope that does not happen. So do you suggest that I change this to
EYNOS5250_PA_DWMMC0 ?
>
>
>>
>> #define EXYNOS4_PA_HSOTG 0x1248
>> #define EXYNOS4_PA_USB_HSPHY 0x125B
>> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
>> b/arch/arm/mach-exynos/mach-exynos5-dt.c
>> index ef770bc..4257cc1 100644
>> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
>> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
>> @@ -47,6 +47,14 @@ static const struct of_dev_auxdata
>> exynos5250_auxdata_lookup[] __initconst = {
>> "s3c2440-i2c.0", NULL),
>> OF_DEV_AUXDATA("samsung,s3c2440-i2c", EXYNOS5_PA_IIC(1),
>> "s3c2440-i2c.1", NULL),
>> + OF_DEV_AUXDATA("samsung,exynos5250-dw-mshc", EXYNOS5_PA_DWMCI(0),
>
>
> As I commented, how about just 'samsung,dw-mmc'? but I'm not sure.
The dw-mmc controllers on Exynos 4210/4412/5250 have incremental
features. So different compatible strings are required to identify the
type of the controller.
Thanks for reviewing this patch series.
Regards,
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 v3 1/3] ARM: Samsung: Add support for MSHC controller clocks
On 28 August 2012 04:45, Kukjin Kim wrote:
> On 08/26/12 04:59, Thomas Abraham wrote:
>>
>> Add clock instances for bus interface unit clock and card interface unit
>> clock of the all four MSHC controller instances.
>>
>> Signed-off-by: Abhilash Kesavan
>> Signed-off-by: Thomas Abraham
>> ---
>> arch/arm/mach-exynos/clock-exynos5.c | 45
>> --
>> 1 files changed, 16 insertions(+), 29 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/clock-exynos5.c
>> b/arch/arm/mach-exynos/clock-exynos5.c
>> index 3b00e29..16d8bef 100644
>> --- a/arch/arm/mach-exynos/clock-exynos5.c
>> +++ b/arch/arm/mach-exynos/clock-exynos5.c
>> @@ -564,35 +564,30 @@ static struct clk exynos5_init_clocks_off[] = {
>> .enable = exynos5_clk_ip_peris_ctrl,
>> .ctrlbit= (1<< 19),
>> }, {
>> - .name = "hsmmc",
>> - .devname= "exynos4-sdhci.0",
>> + .name = "biu",
>
>
> I have no idea why we change the clock name to 'biu' (bus interface unit).
> Just let me know.
The dw-mmc controller requires two clocks - bus interface unit and
card interface unit clock. Since this controller driver can be used on
platforms other than exynos, the name of the clock has to be generic.
Hence the name of the clocks used are "biu" and "ciu" as the per the
dw-mmc data sheet.
>
> [...]
>
>
>> static struct clksrc_clk exynos5_clk_sclk_mmc0 = {
>> .clk= {
>> - .name = "sclk_mmc",
>> - .devname= "exynos4-sdhci.0",
>> + .name = "ciu",
>
>
> Same as above.
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 v4 9/9] mmc: dw_mmc: add support for exynos specific implementation of dw-mshc
Hi Thomas,
On 08/28/2012 01:48 PM, Thomas Abraham wrote:
> On 27 August 2012 14:28, Jaehoon Chung wrote:
>> Hi Thomas,
>>
>>> + gpio = of_get_named_gpio(slot_np, "wp-gpios", 0);
>>> + if (gpio_is_valid(gpio)) {
>>> + if (devm_gpio_request(host->dev, gpio, "dw-mci-wp"))
>>> + dev_info(host->dev, "gpio [%d] request failed\n",
>>> + gpio);
>>> + } else {
>>> + dev_info(host->dev, "wp gpio not available");
>>> + host->pdata->quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
>>> + }
>>> +
>>> + if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
>>> + return 0;
>>> +
>>> + gpio = of_get_named_gpio(slot_np, "samsung,cd-pinmux-gpio", 0);
>>> + if (gpio_is_valid(gpio)) {
>>> + if (devm_gpio_request(host->dev, gpio, "dw-mci-cd"))
>> I'm not sure, but i saw mmc_gpio_request_cd() into
>> drivers/mmc/core/slot-gpio.c.
>> Can we use this? i think we can use them.
>> Just my opinion.
>
> Thanks for letting me know about this, I was not aware of this.
> Looking into this code, it is usable for controllers that use a gpio
> (specified using cd-gpios property) as card-detect line. As you know,
> the dw-mmc driver does not support this feature yet. In case of
> exynos, the card-detect pin of the mmc slot is connected to the
> card-detect pad of the dw-mmc controller using pinmux, which is not
> considered as a gpio. Hence, mmc_gpio_request_cd() is not applicable
> in this case.
But In case of external card-detect-pin, we can use the mmc_gpio_request_cd().
Best Regards,
Jaehoon Chung
>
> Thanks,
> Thomas.
>
>
>>
>> Best Regards,
>> Jaehoon Chung
>>> + dev_err(host->dev, "gpio [%d] request failed\n",
>>> gpio);
>>> + } else {
>>> + dev_info(host->dev, "cd gpio not available");
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/* Exynos5250 controller specific capabilities */
>>> +static unsigned long exynos5250_dwmmc_caps[4] = {
>>> + MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
>>> + MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23,
>>> + MMC_CAP_CMD23,
>>> + MMC_CAP_CMD23,
>>> + MMC_CAP_CMD23,
>>> +};
>>> +
>>> +static struct dw_mci_drv_data exynos5250_drv_data = {
>>> + .caps = exynos5250_dwmmc_caps,
>>> + .init = dw_mci_exynos_priv_init,
>>> + .prepare_command= dw_mci_exynos_prepare_command,
>>> + .set_ios= dw_mci_exynos_set_ios,
>>> + .parse_dt = dw_mci_exynos_parse_dt,
>>> + .setup_bus = dw_mci_exynos_setup_bus,
>>> +};
>>> +
>>> +static const struct of_device_id dw_mci_exynos_match[] = {
>>> + { .compatible = "samsung,exynos5250-dw-mshc",
>>> + .data = (void *)&exynos5250_drv_data, },
>>> + {},
>>> +};
>>> +MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
>>> +
>>> +int dw_mci_exynos_probe(struct platform_device *pdev)
>>> +{
>>> + struct dw_mci_drv_data *drv_data;
>>> + const struct of_device_id *match;
>>> +
>>> + match = of_match_node(dw_mci_exynos_match, pdev->dev.of_node);
>>> + drv_data = match->data;
>>> + return dw_mci_pltfm_register(pdev, drv_data);
>>> +}
>>> +
>>> +static struct platform_driver dw_mci_exynos_pltfm_driver = {
>>> + .probe = dw_mci_exynos_probe,
>>> + .remove = __exit_p(dw_mci_pltfm_remove),
>>> + .driver = {
>>> + .name = "dwmmc_exynos",
>>> + .of_match_table = of_match_ptr(dw_mci_exynos_match),
>>> + .pm = &dw_mci_pltfm_pmops,
>>> + },
>>> +};
>>> +
>>> +module_platform_driver(dw_mci_exynos_pltfm_driver);
>>> +
>>> +MODULE_DESCRIPTION("Samsung Specific DW-MSHC Driver Extension");
>>> +MODULE_AUTHOR("Thomas Abraham >> +MODULE_LICENSE("GPL v2");
>>> +MODULE_ALIAS("platform:dwmmc-exynos");
>>>
>>
>
--
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 v4 0/9] mmc: dw_mmc: add support for device tree based instantiation
On 27 August 2012 15:01, Will Newton wrote: > On Sun, Aug 26, 2012 at 12:51 PM, Thomas Abraham > wrote: >> This is the fourth version of the patch series that adds device tree support >> for Synopsis Designware Mobile Storage Host Controller. In this version, the >> significant change is the spliting of Exynos specific code into a seperate >> file, as suggested by Seungwon Jeon . Spliting the >> Exynos specific code into a seperate file did infact keeps the core driver >> code clean, which otherwise was littered with Exynos specific code. I hope >> the changes look sane, though. This has been tested only on smdk5250 board. >> >> Thomas Abraham (9): >> mmc: dw_mmc: convert copy of struct device in struct dw_mci to a reference >> mmc: dw_mmc: Use devm_* functions in dw_mmc platform driver >> mmc: dw_mmc: allow probe to succeed even if one slot is initialized >> mmc: dw_mmc: lookup for optional biu and ciu clocks >> mmc: dw_mmc: add quirk to indicate missing write protect line >> mmc: dw_mmc: add device tree support >> mmc: dw_mmc: prepare functions in dw_mmc-pltfm for reuse >> mmc: dw_mmc: add support for implementation specific callbacks >> mmc: dw_mmc: add support for exynos specific implementation of dw-mshc >> >> .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 79 ++ >> .../devicetree/bindings/mmc/synposis-dw-mshc.txt | 90 ++ >> drivers/mmc/host/Kconfig |9 + >> drivers/mmc/host/Makefile |3 +- >> drivers/mmc/host/dw_mmc-exynos.c | 247 + >> drivers/mmc/host/dw_mmc-pci.c |2 +- >> drivers/mmc/host/dw_mmc-pltfm.c| 62 +++-- >> drivers/mmc/host/dw_mmc-pltfm.h| 20 ++ >> drivers/mmc/host/dw_mmc.c | 287 >> >> drivers/mmc/host/dw_mmc.h | 22 ++ >> include/linux/mmc/dw_mmc.h | 13 +- >> 11 files changed, 757 insertions(+), 77 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt >> create mode 100644 >> Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt >> create mode 100644 drivers/mmc/host/dw_mmc-exynos.c >> create mode 100644 drivers/mmc/host/dw_mmc-pltfm.h > > This series looks good to me, although I am not familiar enough with > the device tree stuff to review it in a meaningful way. > > Acked-by: Will Newton > > Note that the platform driver changes will conflict with Jaehoon > Chung's patch to fix a section mismatch in that file. Have you tried > building this as a module and with section mismatch debugging to make > sure the new code does not add any mismatches? Thanks Will for reviewing this patch series. I tried building dw-mmc, dw-mmc-pltfm and dw-mmc-exynos as modules with section mismatch debugging enabled, and there were no warnings. But, I did find a problem with the Kconfig entry I made for dw-mmc-exynos file, instead of 'bool', I should have used 'tristate'. I will fix this and other comments and repost. 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 v4 9/9] mmc: dw_mmc: add support for exynos specific implementation of dw-mshc
On 27 August 2012 14:28, Jaehoon Chung wrote:
> Hi Thomas,
>
>> + gpio = of_get_named_gpio(slot_np, "wp-gpios", 0);
>> + if (gpio_is_valid(gpio)) {
>> + if (devm_gpio_request(host->dev, gpio, "dw-mci-wp"))
>> + dev_info(host->dev, "gpio [%d] request failed\n",
>> + gpio);
>> + } else {
>> + dev_info(host->dev, "wp gpio not available");
>> + host->pdata->quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
>> + }
>> +
>> + if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
>> + return 0;
>> +
>> + gpio = of_get_named_gpio(slot_np, "samsung,cd-pinmux-gpio", 0);
>> + if (gpio_is_valid(gpio)) {
>> + if (devm_gpio_request(host->dev, gpio, "dw-mci-cd"))
> I'm not sure, but i saw mmc_gpio_request_cd() into
> drivers/mmc/core/slot-gpio.c.
> Can we use this? i think we can use them.
> Just my opinion.
Thanks for letting me know about this, I was not aware of this.
Looking into this code, it is usable for controllers that use a gpio
(specified using cd-gpios property) as card-detect line. As you know,
the dw-mmc driver does not support this feature yet. In case of
exynos, the card-detect pin of the mmc slot is connected to the
card-detect pad of the dw-mmc controller using pinmux, which is not
considered as a gpio. Hence, mmc_gpio_request_cd() is not applicable
in this case.
Thanks,
Thomas.
>
> Best Regards,
> Jaehoon Chung
>> + dev_err(host->dev, "gpio [%d] request failed\n", gpio);
>> + } else {
>> + dev_info(host->dev, "cd gpio not available");
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +/* Exynos5250 controller specific capabilities */
>> +static unsigned long exynos5250_dwmmc_caps[4] = {
>> + MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
>> + MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23,
>> + MMC_CAP_CMD23,
>> + MMC_CAP_CMD23,
>> + MMC_CAP_CMD23,
>> +};
>> +
>> +static struct dw_mci_drv_data exynos5250_drv_data = {
>> + .caps = exynos5250_dwmmc_caps,
>> + .init = dw_mci_exynos_priv_init,
>> + .prepare_command= dw_mci_exynos_prepare_command,
>> + .set_ios= dw_mci_exynos_set_ios,
>> + .parse_dt = dw_mci_exynos_parse_dt,
>> + .setup_bus = dw_mci_exynos_setup_bus,
>> +};
>> +
>> +static const struct of_device_id dw_mci_exynos_match[] = {
>> + { .compatible = "samsung,exynos5250-dw-mshc",
>> + .data = (void *)&exynos5250_drv_data, },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
>> +
>> +int dw_mci_exynos_probe(struct platform_device *pdev)
>> +{
>> + struct dw_mci_drv_data *drv_data;
>> + const struct of_device_id *match;
>> +
>> + match = of_match_node(dw_mci_exynos_match, pdev->dev.of_node);
>> + drv_data = match->data;
>> + return dw_mci_pltfm_register(pdev, drv_data);
>> +}
>> +
>> +static struct platform_driver dw_mci_exynos_pltfm_driver = {
>> + .probe = dw_mci_exynos_probe,
>> + .remove = __exit_p(dw_mci_pltfm_remove),
>> + .driver = {
>> + .name = "dwmmc_exynos",
>> + .of_match_table = of_match_ptr(dw_mci_exynos_match),
>> + .pm = &dw_mci_pltfm_pmops,
>> + },
>> +};
>> +
>> +module_platform_driver(dw_mci_exynos_pltfm_driver);
>> +
>> +MODULE_DESCRIPTION("Samsung Specific DW-MSHC Driver Extension");
>> +MODULE_AUTHOR("Thomas Abraham > +MODULE_LICENSE("GPL v2");
>> +MODULE_ALIAS("platform:dwmmc-exynos");
>>
>
--
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] gpio: samsung: add devicetree init for s3c24xx arches
On 27 August 2012 13:31, Heiko Stübner wrote:
> Hi Thomas,
>
> thanks for your review:
>
> Am Montag, 27. August 2012, 06:20:49 schrieb Thomas Abraham:
>> Hi Heiko,
>>
>> On 26 August 2012 03:23, Heiko Stübner wrote:
>> > Until now the Exynos-SoC was the only Samsung-SoC supporting the GPIOs
>> > via the device tree. This patch implements dt-support for the
>> > s3c24xx arches.
>> >
>> > The controllers contain only 3 cells, as the underlying gpio controller
>> > does not support controlling the drive strength on a gpio level.
>> >
>> > Tested with the gpio-keys driver on a s3c2416 based machine.
>> >
>> > Signed-off-by: Heiko Stuebner
>> > ---
>> >
>> > .../devicetree/bindings/gpio/gpio-samsung.txt | 38
>> > drivers/gpio/gpio-samsung.c| 63
>> > 2 files changed, 101 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
>> > b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt index
>> > 5375625..ce6a7d4 100644
>> > --- a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
>> > +++ b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
>> >
>> > @@ -39,3 +39,41 @@ Example:
>> > #gpio-cells = <4>;
>> > gpio-controller;
>> >
>> > };
>> >
>> > +
>> > +
>> > +Samsung S3C24XX GPIO Controller
>> > +
>> > +Required properties:
>> > +- compatible: Compatible property value should be
>> > "samsung,s3c24xx-gpio".
>>
>> This is debatable, but I would choose to be specific here and use
>> "samsing,s3c2416-gpio". For instance, SoC's in s3c24xx family have
>> differing value for pull none/down/up.
>
> Hmmm, but the logic to drive the gpio controller is the same for all arches.
> The only difference is the number to use for the different pull up/down
> settings. So I think the "samsung,s3c24xx-gpio" is ok but the documentation
> should simply reflect the different pull settings.
Ok.
>
>
>> > +
>> > +- reg: Physical base address of the controller and length of memory
>> > mapped + region.
>> > +
>> > +- #gpio-cells: Should be 3. The syntax of the gpio specifier used by
>> > client nodes + should be the following with values derived from the SoC
>> > user manual. + <[phandle of the gpio controller node]
>> > + [pin number within the gpio controller]
>> > + [mux function]
>> > + [flags and pull up/down]
>> > +
>> > + Values for gpio specifier:
>> > + - Pin number: depending on the controller a number from 0 up to 15.
>> > + - Flags and Pull Up/Down: 0 - Pull Up/Down Disabled.
>> > +1 - Pull Down Enabled.
>> > +3 - Pull Up Enabled.
>>
>> As per s3c2416 user manual, 2 is used for Pull Up and 3 is listed as
>> reserved value. Any particular reason to use 3 here for pull up and
>> not 2 as per the user manual?
>
> Sorry, copy and paste error :-)
Ok.
>
>
>> > + Bit 16 (0x0001) - Input is active low.
>> > +
>> > +- gpio-controller: Specifies that the node is a gpio controller.
>> > +- #address-cells: should be 1.
>> > +- #size-cells: should be 1.
>>
>> It would be informative to add information about the 'mux function'
>> cell here as well. Specifically, on how to handle the banks that have
>> an extended GPxSEL register that allow additional pin function
>> selection.
>
> Will add a mux function description.
>
> Until now I've never realised the existence of the GPxSEL registers, so thanks
> for the pointer :-).
>
> But is this used in the driver at all? All the setcfg/getcfg functions in
> gpio-samsung.c only handle the GPxCON registers - I haven't found code to
> handle the GPxSEL registers at all. So my guess is that this was never
> implemented - or that I'm blind ;-) .
You are right, there is no code that is handling the GPxCON registers.
Thanks,
Thomas.
>
>
>> > +
>> > +Example:
>> > +
>> > + gpa: gpio-controller@5600 {
>> > + #address-cells = <1>;
>> > + #size-cells = <1>;
>> > + compatible = "samsung,s3c24xx-gpio";
>> > + reg = <0x5600 0x10>;
>> > + #gpio-cells = <3>;
>> > + gpio-controller;
>> > + };
>> > diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
>> > index a150d2e..80a2817 100644
>> > --- a/drivers/gpio/gpio-samsung.c
>> > +++ b/drivers/gpio/gpio-samsung.c
>> > @@ -938,6 +938,67 @@ static void __init samsung_gpiolib_add(struct
>> > samsung_gpio_chip *chip)
>> >
>> > s3c_gpiolib_track(chip);
>> >
>> > }
>> >
>> > +#if defined(CONFIG_PLAT_S3C24XX) && defined(CONFIG_OF)
>> > +static int s3c24xx_gpio_xlate(struct gpio_chip *gc,
>> > + const struct of_phandle_args *gpiospec, u32
>> > *flags) +{
>> > + unsigned int pin;
>> > +
>> > + if (WARN_ON(gc->of_gpio_n_cells < 3))
>> > + return -EINVAL;
>> > +
>> > + if (WARN_ON(gpiospec->args_count < gc->of_gp
Re: [PATCH 0/3] Removal of obsolete s3c2410_* GPIO API
On Mon, Aug 27, 2012 at 4:33 PM, Kukjin Kim wrote: > Linus, this series should be sent to upstream via both trees, samsung and > gpio to avoid useless merge conflicts. How do you think? Take it all in the Samsung tree. You just need my ACK, which you have. I don't have any big Samsung patches in my tree, just fixes that will go into the -rc:s anyway. 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 0/3] Removal of obsolete s3c2410_* GPIO API
On Sat, Aug 25, 2012 at 5:20 AM, Sylwester Nawrocki wrote: > This short patch series converts remaining users of the s3c24xx SoC > specific gpiolib functions to the gpiolib API and finally removes > all s3c2410_* functions from drivers/gpio/gpio-samsung.c. I'm fine with this as long as the Samsung maintainer is, so Acked-by: Linus Walleij But I suspect this will be merged through the Samsung SoC tree? 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 0/3] Removal of obsolete s3c2410_* GPIO API
On 08/25/12 05:20, Sylwester Nawrocki wrote: This short patch series converts remaining users of the s3c24xx SoC specific gpiolib functions to the gpiolib API and finally removes all s3c2410_* functions from drivers/gpio/gpio-samsung.c. Sylwester Nawrocki (3): ARM: S3C24XX: Convert users of s3c2410_gpio_setpin to gpiolib API ARM: S3C24XX: Remove obsolete GPIO API declarations gpio-samsung: Remove now unused s3c2410_gpio* API arch/arm/mach-s3c24xx/mach-anubis.c |3 +- arch/arm/mach-s3c24xx/mach-jive.c | 12 ++-- arch/arm/mach-s3c24xx/mach-mini2440.c |4 +- arch/arm/mach-s3c24xx/mach-nexcoder.c | 22 +++--- arch/arm/mach-s3c24xx/mach-osiris.c |7 +- arch/arm/plat-samsung/include/plat/gpio-fns.h | 97 - drivers/gpio/gpio-samsung.c | 40 -- 7 files changed, 25 insertions(+), 160 deletions(-) Nice cleanup. Accordingly, we need to sort out the 'Documentation/arm/Samsung-S3C24XX/GPIO.txt' later? Linus, this series should be sent to upstream via both trees, samsung and gpio to avoid useless merge conflicts. How do you think? Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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 Tue, Aug 21, 2012 at 9:22 PM, Thomas Abraham
wrote:
>>> + - 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.
OK
> 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).
OK fine.
>> 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.
You answered above, no problem.
>>> + 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 = " ";
>
>
>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.
OK perfect, that's how it should work.
>>> +/* 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.
>
> Ok. The last two entries in the above table are Samsung specific and
> not covered by generic-pinconf. So, I am not sure if it can be added
> to generic-pinconf.
What is so Samsung-specific about them?
If you tell us the electrical property of setting them we can figure out
if they should be generic or not...
> For now, since you are not enforcing the use of
> generic-pinconf, I will keep it the way it is now.
Sure that's OK.
>>> + /* 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...
>
> The name of the pin group is derived from the node name and hence
> strlen(np->name). To this name, "-grp" is appended to imply that this
> is a group. Hence +4 is used. I will replace +4 with probably
> strlen(PINGRP_SUFFIX) where PINGRP_SUFFIX is defined as "-grp".
Aha OK I get it.
>>> +/* reading pin pull up/down and driver strength settings not implemented */
>>
>> OK why not? It seems very simple and straight-forward.
>> Just read the same registers and switch() then return...
>
> Ok, I will do that. I did not see how those would be used and hence skipped
> it.
One good usecase is to look at
Re: [PATCH v3 1/3] ARM: Samsung: Add support for MSHC controller clocks
On 08/26/12 04:59, Thomas Abraham wrote:
Add clock instances for bus interface unit clock and card interface unit
clock of the all four MSHC controller instances.
Signed-off-by: Abhilash Kesavan
Signed-off-by: Thomas Abraham
---
arch/arm/mach-exynos/clock-exynos5.c | 45 --
1 files changed, 16 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index 3b00e29..16d8bef 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -564,35 +564,30 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_peris_ctrl,
.ctrlbit= (1<< 19),
}, {
- .name = "hsmmc",
- .devname= "exynos4-sdhci.0",
+ .name = "biu",
I have no idea why we change the clock name to 'biu' (bus interface
unit). Just let me know.
[...]
static struct clksrc_clk exynos5_clk_sclk_mmc0 = {
.clk= {
- .name = "sclk_mmc",
- .devname= "exynos4-sdhci.0",
+ .name = "ciu",
Same as above.
[...]
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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 v3 2/3] ARM: Exynos5: Add AUXDATA support for MSHC controllers
On 08/26/12 04:59, Thomas Abraham wrote:
Add entries if MSHC controllers in AUXDATA table for correct device name
initialization.
Signed-off-by: Abhilash Kesavan
Signed-off-by: Thomas Abraham
---
arch/arm/mach-exynos/include/mach/map.h |1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |8
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 9d1f3ac..5b0ee41 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -172,6 +172,7 @@
#define EXYNOS4_PA_HSMMC(x) (0x1251 + ((x) * 0x1))
#define EXYNOS4_PA_DWMCI 0x1255
+#define EXYNOS5_PA_DWMCI(x)(0x1220 + ((x) * 0x1))
Just, how about EXYNOS5_PA_DWMMC0, EXYNOS5_PA_DWMMC1, ... EXYNOS_PA_DWMMC3?
And if the addresses are different on other EXYNOS5 SoC, how do we
handle it for auxdata?
#define EXYNOS4_PA_HSOTG 0x1248
#define EXYNOS4_PA_USB_HSPHY 0x125B
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index ef770bc..4257cc1 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -47,6 +47,14 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
"s3c2440-i2c.0", NULL),
OF_DEV_AUXDATA("samsung,s3c2440-i2c", EXYNOS5_PA_IIC(1),
"s3c2440-i2c.1", NULL),
+ OF_DEV_AUXDATA("samsung,exynos5250-dw-mshc", EXYNOS5_PA_DWMCI(0),
As I commented, how about just 'samsung,dw-mmc'? but I'm not sure.
+ "dw_mmc.0", NULL),
+ OF_DEV_AUXDATA("samsung,exynos5250-dw-mshc", EXYNOS5_PA_DWMCI(1),
+ "dw_mmc.1", NULL),
+ OF_DEV_AUXDATA("samsung,exynos5250-dw-mshc", EXYNOS5_PA_DWMCI(2),
+ "dw_mmc.2", NULL),
+ OF_DEV_AUXDATA("samsung,exynos5250-dw-mshc", EXYNOS5_PA_DWMCI(3),
+ "dw_mmc.3", NULL),
OF_DEV_AUXDATA("samsung,exynos4210-spi", EXYNOS5_PA_SPI0,
"exynos4210-spi.0", NULL),
OF_DEV_AUXDATA("samsung,exynos4210-spi", EXYNOS5_PA_SPI1,
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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: ASoC: SAMSUNG: Change Kconfig to support all EXYNOSs
On 08/27/12 11:08, Mark Brown wrote: On Mon, Aug 27, 2012 at 11:06:47AM -0700, Kukjin Kim wrote: Hmm, all of Samsung stuff is available...so how about? + depends on PLAT_SAMSUNG Yes, that's a very good idea! Mark, thanks. Sangsu, could you please re-submit as per my suggestion? Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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] ARM: S3C24XX: Add .get_rate callback for "camif-upll" clock
On 08/27/12 13:12, Sylwester Nawrocki wrote:
Add missing get_rate callback for the "camif-upll" clock, so frequency
of this clock is properly reported with clk_get_rate().
Signed-off-by: Sylwester Nawrocki
---
arch/arm/mach-s3c24xx/clock-s3c2440.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2440.c
b/arch/arm/mach-s3c24xx/clock-s3c2440.c
index cb2883d..749220f 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2440.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2440.c
@@ -87,6 +87,19 @@ static int s3c2440_camif_upll_setrate(struct clk *clk,
unsigned long rate)
return 0;
}
+static unsigned long s3c2440_camif_upll_getrate(struct clk *clk)
+{
+ unsigned long parent_rate = clk_get_rate(clk->parent);
+ unsigned long camdivn = __raw_readl(S3C2440_CAMDIVN);
+
+ if (!(camdivn& S3C2440_CAMDIVN_CAMCLK_SEL))
+ return parent_rate;
+
+ camdivn&= S3C2440_CAMDIVN_CAMCLK_MASK;
+
+ return parent_rate / (camdivn + 1) / 2;
Well, why do we need '/ 2' here?
+}
+
/* Extra S3C2440 clocks */
static struct clk s3c2440_clk_cam = {
@@ -99,6 +112,7 @@ static struct clk s3c2440_clk_cam_upll = {
.name = "camif-upll",
.ops=&(struct clk_ops) {
.set_rate = s3c2440_camif_upll_setrate,
+ .get_rate = s3c2440_camif_upll_getrate,
.round_rate = s3c2440_camif_upll_round,
},
};
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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 v3 3/3] ARM: dts: Add nodes for dw_mmc controllers for Samsung Exynos5250 platforms
On 08/26/12 04:59, Thomas Abraham wrote:
Add device nodes for the four instances of dw_mmc controllers in Exynos5250
and enable instance 0 and 2 for the smdk5250 board.
Signed-off-by: Thomas Abraham
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 57 -
arch/arm/boot/dts/exynos5250.dtsi | 32
2 files changed, 88 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 8a5e348..6dc9faf 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -16,12 +16,19 @@
model = "SAMSUNG SMDK5250 board based on EXYNOS5250";
compatible = "samsung,smdk5250", "samsung,exynos5250";
+ aliases {
+ mshc0 =&mshc_0;
+ mshc1 =&mshc_1;
+ mshc2 =&mshc_2;
+ mshc3 =&mshc_3;
+ };
+
memory {
reg =<0x4000 0x8000>;
};
chosen {
- bootargs = "root=/dev/ram0 rw ramdisk=8192
console=ttySAC1,115200";
+ bootargs = "root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC2,115200 init=/linuxrc";
Yes, we need to sort out the 'bootargs' for using uart2 as a console,
but you know, this should be separated :-)
};
i2c@12C6 {
@@ -72,6 +79,54 @@
status = "disabled";
};
+ mshc_0: dwmmc0@1220 {
How about to keep the consistent naming? dwmmc or dw_mmc? I think,
'dw_mmc' makes more sense?
+ num-slots =<1>;
+ supports-highspeed;
+ broken-cd;
+ fifo-depth =<0x80>;
+ card-detect-delay =<200>;
+ samsung,dw-mshc-sdr-timing =<2 3 3>;
+ samsung,dw-mshc-ddr-timing =<1 2 3>;
We need to think again the name of dw-mshc-sdr-timing, dw-mshc-ddr-timing?
[...]
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 004aaa8..f69e389 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -182,6 +182,38 @@
#size-cells =<0>;
};
+ dwmmc0@1220 {
+ compatible = "samsung,exynos5250-dw-mshc";
I'm not sure, 'exynos5250-dw-mshc' is right here. Because it is just
dw_mmc controller on exynos5250. So...hmm...
[...]
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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] ASoC: SAMSUNG: Add SND_SOC_DAIFMT_CONT option for snd_soc_set_fmt()
On Sun, Aug 26, 2012 at 05:45:54PM +0900, �ڻ��� wrote: > SND_SOC_DAIFMT_CONT option is now needed because of below commit: > > ASoC: Allow DAI formats to be specified in the dai_link Clearly it's not a direct consequence of this commit, that just introduces a new optional facility which... > /* Set the cpu DAI configuration */ > ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_B > + | SND_SOC_DAIFMT_CONT > | SND_SOC_DAIFMT_IB_NF > | SND_SOC_DAIFMT_CBS_CFS); ...isn't being used by the driver. Looking at the above it looks like the PCM driver is doing something very odd - _CONT doesn't make a whole lot of sense on the slave side, it's related to the clock generation so should have no effect at all on the slave side. The driver code looks reasonably sensible though. What specifically is going wrong 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
[PATCH] ARM: S3C24XX: Add .get_rate callback for "camif-upll" clock
Add missing get_rate callback for the "camif-upll" clock, so frequency
of this clock is properly reported with clk_get_rate().
Signed-off-by: Sylwester Nawrocki
---
arch/arm/mach-s3c24xx/clock-s3c2440.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2440.c
b/arch/arm/mach-s3c24xx/clock-s3c2440.c
index cb2883d..749220f 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2440.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2440.c
@@ -87,6 +87,19 @@ static int s3c2440_camif_upll_setrate(struct clk *clk,
unsigned long rate)
return 0;
}
+static unsigned long s3c2440_camif_upll_getrate(struct clk *clk)
+{
+ unsigned long parent_rate = clk_get_rate(clk->parent);
+ unsigned long camdivn = __raw_readl(S3C2440_CAMDIVN);
+
+ if (!(camdivn & S3C2440_CAMDIVN_CAMCLK_SEL))
+ return parent_rate;
+
+ camdivn &= S3C2440_CAMDIVN_CAMCLK_MASK;
+
+ return parent_rate / (camdivn + 1) / 2;
+}
+
/* Extra S3C2440 clocks */
static struct clk s3c2440_clk_cam = {
@@ -99,6 +112,7 @@ static struct clk s3c2440_clk_cam_upll = {
.name = "camif-upll",
.ops= &(struct clk_ops) {
.set_rate = s3c2440_camif_upll_setrate,
+ .get_rate = s3c2440_camif_upll_getrate,
.round_rate = s3c2440_camif_upll_round,
},
};
--
1.7.4.1
--
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: [RESEND][PATCH] ARM: Exynos4: fixed SYSMMU setup definition to mate parameter name
On 08/27/12 04:59, KyongHo Cho wrote:
On Mon, Aug 27, 2012 at 4:11 PM, Seung-Woo Kim wrote:
This is trivial patch to mate parameter name between iommu api enabled case and
disabled case.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
Sorry about typo in previous patch.
arch/arm/mach-exynos/include/mach/sysmmu.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/sysmmu.h
b/arch/arm/mach-exynos/include/mach/sysmmu.h
index 998daf2..81e4c66 100644
--- a/arch/arm/mach-exynos/include/mach/sysmmu.h
+++ b/arch/arm/mach-exynos/include/mach/sysmmu.h
@@ -58,7 +58,7 @@ static inline void platform_set_sysmmu(
#endif
#else /* !CONFIG_EXYNOS_DEV_SYSMMU */
-#define platform_set_sysmmu(dev, sysmmu) do { } while (0)
+#define platform_set_sysmmu(sysmmu, dev) do { } while (0)
#endif
Thank you for your correction.
OK, applied with KyongHo's ack.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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: ASoC: SAMSUNG: Change Kconfig to support all EXYNOSs
On Mon, Aug 27, 2012 at 11:06:47AM -0700, Kukjin Kim wrote: > Hmm, all of Samsung stuff is available...so how about? > > + depends on PLAT_SAMSUNG Yes, that's a very good idea! -- 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: ASoC: SAMSUNG: Change Kconfig to support all EXYNOSs
On 08/26/12 01:04, 박상수 wrote: > All EXYNOSs use SND_SOC_SAMSUNG configuration. > This patch change Kconfig to support all EXYNOSs like EXYNOS4 and EXYNOS5. > > Signed-off-by: Sangsu Park > --- > sound/soc/samsung/Kconfig |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig > index f17dd25..9e64ae6 100644 > --- a/sound/soc/samsung/Kconfig > +++ b/sound/soc/samsung/Kconfig > @@ -1,6 +1,6 @@ > config SND_SOC_SAMSUNG > tristate "ASoC support for Samsung" > - depends on ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5PC100 || ARCH_S5PV210 > || ARCH_S5P64X0 || > ARCH_EXYNOS4 > + depends on ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5PC100 || ARCH_S5PV210 > || ARCH_S5P64X0 || > ARCH_EXYNOS Hmm, all of Samsung stuff is available...so how about? + depends on PLAT_SAMSUNG Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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] spi/s3c64xx: Drop extra calls to spi_master_get in suspend/remove functions
On Thu, Aug 16, 2012 at 08:14:25PM -0700, Guenter Roeck wrote: > Suspend and resume functions call spi_master_get() without matching > spi_master_put(). The extra references are unnecessary and cause subsequent > module unload attempts to fail. Drop the calls. Applied, thanks. -- 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: ASoC: SAMSUNG: Change Kconfig to support all EXYNOSs
On Sun, Aug 26, 2012 at 05:04:37PM +0900, �ڻ��� wrote: > All EXYNOSs use SND_SOC_SAMSUNG configuration. > This patch change Kconfig to support all EXYNOSs like EXYNOS4 and EXYNOS5. git can't figure out how to apply your patch due to your character set: fatal: cannot convert from ks_c_5601-1987 to UTF-8 -- 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: [RESEND][PATCH] ARM: Exynos4: fixed SYSMMU setup definition to mate parameter name
On Mon, Aug 27, 2012 at 4:11 PM, Seung-Woo Kim wrote:
> This is trivial patch to mate parameter name between iommu api enabled case
> and
> disabled case.
>
> Signed-off-by: Seung-Woo Kim
> Signed-off-by: Kyungmin Park
> ---
> Sorry about typo in previous patch.
>
> arch/arm/mach-exynos/include/mach/sysmmu.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/include/mach/sysmmu.h
> b/arch/arm/mach-exynos/include/mach/sysmmu.h
> index 998daf2..81e4c66 100644
> --- a/arch/arm/mach-exynos/include/mach/sysmmu.h
> +++ b/arch/arm/mach-exynos/include/mach/sysmmu.h
> @@ -58,7 +58,7 @@ static inline void platform_set_sysmmu(
> #endif
>
> #else /* !CONFIG_EXYNOS_DEV_SYSMMU */
> -#define platform_set_sysmmu(dev, sysmmu) do { } while (0)
> +#define platform_set_sysmmu(sysmmu, dev) do { } while (0)
> #endif
>
Thank you for your correction.
KyongHo
--
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] ARM: EXYNOS: Add MFC device tree support
Hi Kgene,
Thank you for the review comments.
Please find my response inline.
On Thu, Aug 23, 2012 at 1:46 PM, Kukjin Kim wrote:
> Arun Kumar K wrote:
>>
>> Hi Thomas,
>> Thank you for the comments.
>> Please find my response inline.
>>
>> --- Original Message ---
>> Sender : Thomas Abraham
>> Date : Aug 16, 2012 17:12 (GMT+05:30)
>> Title : Re: [PATCH] ARM: EXYNOS: Add MFC device tree support
>>
>> On 16 August 2012 18:01, Arun Kumar K wrote:
>> > From: Naveen Krishna Chatradhi
>> >
>> > This patch adds device tree entry for MFC in the Exynos
>> > machines. Exynos4 SoCs support MFC v5 version and Exynos5 has
>> > MFC v6.x version. So making the required changes in the clock
>
> Since v6.1 is not used anywhere so just MFC v6 should be ok.
>
Ok.
>> > files and adds MFC to the DT device list.
>> >
>> > Signed-off-by: Naveen Krishna Chatradhi
>> > Signed-off-by: Arun Kumar K
>> > ---
>> > .../devicetree/bindings/media/s5p-mfc.txt | 24
>>
>> > arch/arm/boot/dts/exynos4210.dtsi | 10
>> > arch/arm/boot/dts/exynos5250.dtsi | 10
>> > arch/arm/mach-exynos/clock-exynos5.c |2 +-
>> > arch/arm/mach-exynos/mach-exynos4-dt.c | 22
>> ++
>> > arch/arm/mach-exynos/mach-exynos5-dt.c | 22
>> ++
>> > 6 files changed, 89 insertions(+), 1 deletions(-)
>> > create mode 100644 Documentation/devicetree/bindings/media/s5p-mfc.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
>> b/Documentation/devicetree/bindings/media/s5p-mfc.txt
>> > new file mode 100644
>> > index 000..b9bd266
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
>> > @@ -0,0 +1,24 @@
>> > +* Samsung Multi Format Codec (MFC)
>> > +
>> > +Mult Format Codec (MFC) is the IP present in Samsung SoCs which
>> > +supports high resolution decoding and encoding functionalities.
>> >
>> > In addition to this, specifying that mfc is used for video
>> > encode/decode would be informative.
>>
>> Ok. I will make it more descriptive.
>>
>> > +
>> > +Required properties:
>> > + - compatible : value should be either one among the following
>> > + (a) "samsung,s5p-mfc-v5" for MFC v5 present in Exynos4 SoCs
>> > + (b) "samsung,s5p-mfc-v6" for MFC v6.x present in Exynos5 SoCs
>> >
>> > "s5p" should be dropped from the compatible values. For example, it
>> > should be "samsung,mfc-v5", which is sufficient to identify the
>> > version of the mfc controller.
>>
>> Ok will remove s5p.
>>
> Yeah, I agree, just 'mfc-vX' is enough.
>
Ok. Will change it.
>> > +
>> > + - reg : Physical base address of the IP registers and length of
>> memory
>> > + mapped region.
>> > +
>> > + - interrupts : MFC interupt number to the CPU.
>> > +
>> > + - samsung,mfc-r : Base address of the first memory bank used by MFC
>> > + for DMA contiguous memory allocation.
>> > +
>> > + - samsung,mfc-r-size : Size of the first memory bank.
>> >
>> > It is not allowed to pass buffer base address and size from device
>> > tree. Device tree node should describe only the MFC controller
>> > hardware. Any memory management related information should be handled
>> > outside of device tree. This helps the bindings to be reusable across
>> > multiple operating systems.
>>
>> The mfc-l and mfc-r base address and size is board specific info which has
>> to
>> be passed to the driver. This is used for DMA contiguous allocation by
>> driver and this value
>> can change on a different board.
>> So in that case, i will pass it as platform data to the driver from mach-
>> exynos5-dt.c file.
>> I hope that would be ok.
>>
> I don't think so. The mach-exynos5-dt is for all EXYNOS5 SoCs not
> platform_data. As I know, the addresses and sizes for buffer passed via
> platform data before, so it can be passed via device tree for board(.dtsi)?
> not SoC. In addition, it depends on board.
>
Ok. So as suggested the best option would be to move the mfc-l and r
base address and size information to board dts file
(exynos5250-smdk5250.dts) from exynos5250.dtsi. Hope this would be
good.
>> > +
>> > + - samsung,mfc-l : Base address of the second memory bank used by MFC
>> > + for DMA contiguous memory allocation.
>> > +
>> > + - samsung,mfc-l-size : Size of the second memory bank.
>> >
>> > Same comment as above. And the bindings documentation is usually
>> > included in the same patch that adds device tree support for the
>> > driver.
>>
>> Ok
>>
>> > diff --git a/arch/arm/boot/dts/exynos4210.dtsi
>> b/arch/arm/boot/dts/exynos4210.dtsi
>> > index 02891fe..b5ee43d 100644
>> > --- a/arch/arm/boot/dts/exynos4210.dtsi
>> > +++ b/arch/arm/boot/dts/exynos4210.dtsi
>> > @@ -56,6 +56,16 @@
>> > interrupts = <0 43 0>;
>> > };
>> >
>> > + mfc {
>> > + compatible = "samsung,s5p-mfc";
>
> Maybe
>
Re: [PATCH] gpio: samsung: add devicetree init for s3c24xx arches
Am Montag, 27. August 2012, 11:51:27 schrieb Vasily Khoruzhick:
> On Mon, Aug 27, 2012 at 12:44 PM, Heiko Stübner wrote:
> > Hi Vasily,
> >
> > I'm not sure I follow :-) .
> >
> > The compatible property here only sets the mechanism on how to handle the
> > gpios defined in the devicetree - here to use the s3c24xx-style. As you
> > can see in gpio-samsung.c the handling is already unified for all the
> > s3c24xx architectures.
> >
> > The definition of what gpio banks exist is then done in the respective
> > devicetree file for the individual SoC. And of course here one would have
> > individual definitions, depending on the banks present.
> >
> > For reference my quite empty s3c2416.dtsi file currently looks like:
> >
> > /include/ "skeleton.dtsi"
> >
> > / {
> >
> > compatible = "samsung,s3c2416";
> >
> > cpus {
> >
> > cpu@0 {
> >
> > compatible = "arm,arm926ejs";
> >
> > };
> >
> > };
> >
> > gpio-controllers {
> >
> > #address-cells = <1>;
> > #size-cells = <1>;
> > gpio-controller;
> > ranges;
> >
> > gpa: gpio-controller@5600 {
> >
> > compatible = "samsung,s3c24xx-gpio";
> > reg = <0x5600 0x10>;
> > #gpio-cells = <3>;
> >
> > };
> >
> > gpb: gpio-controller@5610 {
> >
> > compatible = "samsung,s3c24xx-gpio";
> > reg = <0x5610 0x10>;
> > #gpio-cells = <3>;
> >
> > };
[ ... ]
> > };
> >
> > };
> >
> > Other s3c24xx SoCs would of course need to define their own.
>
> I see. But how does it handle GPA bank (which is output-only, and
> GPACON differs a bit from GP{B-J}CON? And some banks has lower number
> (not 16) of GPIOs, like GPH.
>
> Also, what would be value for S3C_GPIO_END?
The creation of the banks is still done in gpio-samsung.c and the special
handling of bank-a is still sitting in the s3c24xx_gpios[] array there.
In general the gpios are still created completely like before and the
devicetree information is only attached to them so that dt-devices can
reference them.
As you can see in the original patch, after the respective chip got created in
s3c24xx_gpiolib_add_chips, s3c24xx_gpiolib_attach_ofnode searches for the
representation of it in the device tree and attaches this to the chip.
So nothing really changed, except that dt-devices can now reference gpios and
if they do s3c24xx_gpio_xlate will get called to configure them with the
target values from the dt.
Currently I'm also only using it in a mixed mode configuration [1],
supplementing a normal machine file with some devices from the devicetree -
especially as I still need to figure out, what to do about the interrupt
controller.
Heiko
[1] https://github.com/mmind/linux-es600/blob/topic/es600-
devel/arch/arm/boot/dts/s3c24xx-sg06.dts
--
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] gpio: samsung: add devicetree init for s3c24xx arches
On Mon, Aug 27, 2012 at 12:44 PM, Heiko Stübner wrote:
> Hi Vasily,
>
> I'm not sure I follow :-) .
>
> The compatible property here only sets the mechanism on how to handle the
> gpios defined in the devicetree - here to use the s3c24xx-style. As you can
> see in gpio-samsung.c the handling is already unified for all the s3c24xx
> architectures.
>
> The definition of what gpio banks exist is then done in the respective
> devicetree file for the individual SoC. And of course here one would have
> individual definitions, depending on the banks present.
>
> For reference my quite empty s3c2416.dtsi file currently looks like:
>
> /include/ "skeleton.dtsi"
>
> / {
> compatible = "samsung,s3c2416";
>
> cpus {
> cpu@0 {
> compatible = "arm,arm926ejs";
> };
> };
>
> gpio-controllers {
> #address-cells = <1>;
> #size-cells = <1>;
> gpio-controller;
> ranges;
>
> gpa: gpio-controller@5600 {
> compatible = "samsung,s3c24xx-gpio";
> reg = <0x5600 0x10>;
> #gpio-cells = <3>;
> };
>
> gpb: gpio-controller@5610 {
> compatible = "samsung,s3c24xx-gpio";
> reg = <0x5610 0x10>;
> #gpio-cells = <3>;
> };
>
> gpc: gpio-controller@5620 {
> compatible = "samsung,s3c24xx-gpio";
> reg = <0x5620 0x10>;
> #gpio-cells = <3>;
> };
>
> gpd: gpio-controller@5630 {
> compatible = "samsung,s3c24xx-gpio";
> reg = <0x5630 0x10>;
> #gpio-cells = <3>;
> };
>
> gpe: gpio-controller@5640 {
> compatible = "samsung,s3c24xx-gpio";
> reg = <0x5640 0x10>;
> #gpio-cells = <3>;
> };
>
> gpf: gpio-controller@5650 {
> compatible = "samsung,s3c24xx-gpio";
> reg = <0x5650 0x10>;
> #gpio-cells = <3>;
> };
>
> gpg: gpio-controller@5660 {
> compatible = "samsung,s3c24xx-gpio";
> reg = <0x5660 0x10>;
> #gpio-cells = <3>;
> };
>
> gph: gpio-controller@5670 {
> compatible = "samsung,s3c24xx-gpio";
> reg = <0x5670 0x10>;
> #gpio-cells = <3>;
> };
>
> /* s3c2443 and later */
> gpj: gpio-controller@56D0 {
> compatible = "samsung,s3c24xx-gpio";
> reg = <0x56D0 0x10>;
> #gpio-cells = <3>;
> };
>
> gpk: gpio-controller@56E0 {
> compatible = "samsung,s3c24xx-gpio";
> reg = <0x56E0 0x10>;
> #gpio-cells = <3>;
> };
>
> gpl: gpio-controller@56F0 {
> compatible = "samsung,s3c24xx-gpio";
> reg = <0x56F0 0x10>;
> #gpio-cells = <3>;
> };
>
> gpm: gpio-controller@56000100 {
> compatible = "samsung,s3c24xx-gpio";
> reg = <0x56000100 0x10>;
> #gpio-cells = <3>;
> };
> };
> };
>
> Other s3c24xx SoCs would of course need to define their own.
I see. But how does it handle GPA bank (which is output-only, and
GPACON differs a bit from GP{B-J}CON? And some banks has lower number
(not 16) of GPIOs, like GPH.
Also, what would be value for S3C_GPIO_END?
Regards
Vasily
--
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] gpio: samsung: add devicetree init for s3c24xx arches
Hi Vasily,
Am Montag, 27. August 2012, 10:57:04 schrieb Vasily Khoruzhick:
> Hi,
>
> On Mon, Aug 27, 2012 at 11:01 AM, Heiko Stübner wrote:
> > Hi Thomas,
> >
> > thanks for your review:
> >
> > Hmmm, but the logic to drive the gpio controller is the same for all
> > arches. The only difference is the number to use for the different pull
> > up/down settings. So I think the "samsung,s3c24xx-gpio" is ok but the
> > documentation should simply reflect the different pull settings.
>
> Also s3c2410 and s3c2440 has different count of GPIOs. And that could
> be a problem on machines
> with GPIO-expanders (h1940 machine)
I'm not sure I follow :-) .
The compatible property here only sets the mechanism on how to handle the
gpios defined in the devicetree - here to use the s3c24xx-style. As you can
see in gpio-samsung.c the handling is already unified for all the s3c24xx
architectures.
The definition of what gpio banks exist is then done in the respective
devicetree file for the individual SoC. And of course here one would have
individual definitions, depending on the banks present.
For reference my quite empty s3c2416.dtsi file currently looks like:
/include/ "skeleton.dtsi"
/ {
compatible = "samsung,s3c2416";
cpus {
cpu@0 {
compatible = "arm,arm926ejs";
};
};
gpio-controllers {
#address-cells = <1>;
#size-cells = <1>;
gpio-controller;
ranges;
gpa: gpio-controller@5600 {
compatible = "samsung,s3c24xx-gpio";
reg = <0x5600 0x10>;
#gpio-cells = <3>;
};
gpb: gpio-controller@5610 {
compatible = "samsung,s3c24xx-gpio";
reg = <0x5610 0x10>;
#gpio-cells = <3>;
};
gpc: gpio-controller@5620 {
compatible = "samsung,s3c24xx-gpio";
reg = <0x5620 0x10>;
#gpio-cells = <3>;
};
gpd: gpio-controller@5630 {
compatible = "samsung,s3c24xx-gpio";
reg = <0x5630 0x10>;
#gpio-cells = <3>;
};
gpe: gpio-controller@5640 {
compatible = "samsung,s3c24xx-gpio";
reg = <0x5640 0x10>;
#gpio-cells = <3>;
};
gpf: gpio-controller@5650 {
compatible = "samsung,s3c24xx-gpio";
reg = <0x5650 0x10>;
#gpio-cells = <3>;
};
gpg: gpio-controller@5660 {
compatible = "samsung,s3c24xx-gpio";
reg = <0x5660 0x10>;
#gpio-cells = <3>;
};
gph: gpio-controller@5670 {
compatible = "samsung,s3c24xx-gpio";
reg = <0x5670 0x10>;
#gpio-cells = <3>;
};
/* s3c2443 and later */
gpj: gpio-controller@56D0 {
compatible = "samsung,s3c24xx-gpio";
reg = <0x56D0 0x10>;
#gpio-cells = <3>;
};
gpk: gpio-controller@56E0 {
compatible = "samsung,s3c24xx-gpio";
reg = <0x56E0 0x10>;
#gpio-cells = <3>;
};
gpl: gpio-controller@56F0 {
compatible = "samsung,s3c24xx-gpio";
reg = <0x56F0 0x10>;
#gpio-cells = <3>;
};
gpm: gpio-controller@56000100 {
compatible = "samsung,s3c24xx-gpio";
reg = <0x56000100 0x10>;
#gpio-cells = <3>;
};
};
};
Other s3c24xx SoCs would of course need to define their own.
> >> It would be informative to add information about the 'mux function'
> >> cell here as well. Specifically, on how to handle the banks that have
> >> an extended GPxSEL register that allow additional pin function
> >> selection.
> >
> > Will add a mux function description.
> >
> > Until now I've never realised the existence of the GPxSEL registers, so
> > thanks for the pointer :-).
> >
> > But is this used in the driver at all? All the setcfg/getcfg functions in
> > gpio-samsung.c only handle the GPxCON registers - I haven't found code to
> > handle the GPxSEL registers at all. So my guess is that this was never
> > implemented - or that I'm blind ;-) .
>
> There're no GPxSEL register
Re: [PATCH v4 0/9] mmc: dw_mmc: add support for device tree based instantiation
On Sun, Aug 26, 2012 at 12:51 PM, Thomas Abraham wrote: > This is the fourth version of the patch series that adds device tree support > for Synopsis Designware Mobile Storage Host Controller. In this version, the > significant change is the spliting of Exynos specific code into a seperate > file, as suggested by Seungwon Jeon . Spliting the > Exynos specific code into a seperate file did infact keeps the core driver > code clean, which otherwise was littered with Exynos specific code. I hope > the changes look sane, though. This has been tested only on smdk5250 board. > > Thomas Abraham (9): > mmc: dw_mmc: convert copy of struct device in struct dw_mci to a reference > mmc: dw_mmc: Use devm_* functions in dw_mmc platform driver > mmc: dw_mmc: allow probe to succeed even if one slot is initialized > mmc: dw_mmc: lookup for optional biu and ciu clocks > mmc: dw_mmc: add quirk to indicate missing write protect line > mmc: dw_mmc: add device tree support > mmc: dw_mmc: prepare functions in dw_mmc-pltfm for reuse > mmc: dw_mmc: add support for implementation specific callbacks > mmc: dw_mmc: add support for exynos specific implementation of dw-mshc > > .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 79 ++ > .../devicetree/bindings/mmc/synposis-dw-mshc.txt | 90 ++ > drivers/mmc/host/Kconfig |9 + > drivers/mmc/host/Makefile |3 +- > drivers/mmc/host/dw_mmc-exynos.c | 247 + > drivers/mmc/host/dw_mmc-pci.c |2 +- > drivers/mmc/host/dw_mmc-pltfm.c| 62 +++-- > drivers/mmc/host/dw_mmc-pltfm.h| 20 ++ > drivers/mmc/host/dw_mmc.c | 287 > > drivers/mmc/host/dw_mmc.h | 22 ++ > include/linux/mmc/dw_mmc.h | 13 +- > 11 files changed, 757 insertions(+), 77 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt > create mode 100644 Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt > create mode 100644 drivers/mmc/host/dw_mmc-exynos.c > create mode 100644 drivers/mmc/host/dw_mmc-pltfm.h This series looks good to me, although I am not familiar enough with the device tree stuff to review it in a meaningful way. Acked-by: Will Newton Note that the platform driver changes will conflict with Jaehoon Chung's patch to fix a section mismatch in that file. Have you tried building this as a module and with section mismatch debugging to make sure the new code does not add any mismatches? -- 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 v4 9/9] mmc: dw_mmc: add support for exynos specific implementation of dw-mshc
Hi Thomas,
> + gpio = of_get_named_gpio(slot_np, "wp-gpios", 0);
> + if (gpio_is_valid(gpio)) {
> + if (devm_gpio_request(host->dev, gpio, "dw-mci-wp"))
> + dev_info(host->dev, "gpio [%d] request failed\n",
> + gpio);
> + } else {
> + dev_info(host->dev, "wp gpio not available");
> + host->pdata->quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
> + }
> +
> + if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
> + return 0;
> +
> + gpio = of_get_named_gpio(slot_np, "samsung,cd-pinmux-gpio", 0);
> + if (gpio_is_valid(gpio)) {
> + if (devm_gpio_request(host->dev, gpio, "dw-mci-cd"))
I'm not sure, but i saw mmc_gpio_request_cd() into drivers/mmc/core/slot-gpio.c.
Can we use this? i think we can use them.
Just my opinion.
Best Regards,
Jaehoon Chung
> + dev_err(host->dev, "gpio [%d] request failed\n", gpio);
> + } else {
> + dev_info(host->dev, "cd gpio not available");
> + }
> +
> + return 0;
> +}
> +
> +/* Exynos5250 controller specific capabilities */
> +static unsigned long exynos5250_dwmmc_caps[4] = {
> + MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
> + MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23,
> + MMC_CAP_CMD23,
> + MMC_CAP_CMD23,
> + MMC_CAP_CMD23,
> +};
> +
> +static struct dw_mci_drv_data exynos5250_drv_data = {
> + .caps = exynos5250_dwmmc_caps,
> + .init = dw_mci_exynos_priv_init,
> + .prepare_command= dw_mci_exynos_prepare_command,
> + .set_ios= dw_mci_exynos_set_ios,
> + .parse_dt = dw_mci_exynos_parse_dt,
> + .setup_bus = dw_mci_exynos_setup_bus,
> +};
> +
> +static const struct of_device_id dw_mci_exynos_match[] = {
> + { .compatible = "samsung,exynos5250-dw-mshc",
> + .data = (void *)&exynos5250_drv_data, },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
> +
> +int dw_mci_exynos_probe(struct platform_device *pdev)
> +{
> + struct dw_mci_drv_data *drv_data;
> + const struct of_device_id *match;
> +
> + match = of_match_node(dw_mci_exynos_match, pdev->dev.of_node);
> + drv_data = match->data;
> + return dw_mci_pltfm_register(pdev, drv_data);
> +}
> +
> +static struct platform_driver dw_mci_exynos_pltfm_driver = {
> + .probe = dw_mci_exynos_probe,
> + .remove = __exit_p(dw_mci_pltfm_remove),
> + .driver = {
> + .name = "dwmmc_exynos",
> + .of_match_table = of_match_ptr(dw_mci_exynos_match),
> + .pm = &dw_mci_pltfm_pmops,
> + },
> +};
> +
> +module_platform_driver(dw_mci_exynos_pltfm_driver);
> +
> +MODULE_DESCRIPTION("Samsung Specific DW-MSHC Driver Extension");
> +MODULE_AUTHOR("Thomas Abraham +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:dwmmc-exynos");
>
--
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] gpio: samsung: add devicetree init for s3c24xx arches
Hi, On Mon, Aug 27, 2012 at 11:01 AM, Heiko Stübner wrote: > Hi Thomas, > > thanks for your review: > > Hmmm, but the logic to drive the gpio controller is the same for all arches. > The only difference is the number to use for the different pull up/down > settings. So I think the "samsung,s3c24xx-gpio" is ok but the documentation > should simply reflect the different pull settings. > Also s3c2410 and s3c2440 has different count of GPIOs. And that could be a problem on machines with GPIO-expanders (h1940 machine) >> It would be informative to add information about the 'mux function' >> cell here as well. Specifically, on how to handle the banks that have >> an extended GPxSEL register that allow additional pin function >> selection. > > Will add a mux function description. > > Until now I've never realised the existence of the GPxSEL registers, so thanks > for the pointer :-). > > But is this used in the driver at all? All the setcfg/getcfg functions in > gpio-samsung.c only handle the GPxCON registers - I haven't found code to > handle the GPxSEL registers at all. So my guess is that this was never > implemented - or that I'm blind ;-) . There're no GPxSEL registers on s3c2410/s3c2440/s3c2442. Is it something s3c2412/sec2416 specific? Regards Vasily -- 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] gpio: samsung: add devicetree init for s3c24xx arches
Hi Thomas,
thanks for your review:
Am Montag, 27. August 2012, 06:20:49 schrieb Thomas Abraham:
> Hi Heiko,
>
> On 26 August 2012 03:23, Heiko Stübner wrote:
> > Until now the Exynos-SoC was the only Samsung-SoC supporting the GPIOs
> > via the device tree. This patch implements dt-support for the
> > s3c24xx arches.
> >
> > The controllers contain only 3 cells, as the underlying gpio controller
> > does not support controlling the drive strength on a gpio level.
> >
> > Tested with the gpio-keys driver on a s3c2416 based machine.
> >
> > Signed-off-by: Heiko Stuebner
> > ---
> >
> > .../devicetree/bindings/gpio/gpio-samsung.txt | 38
> > drivers/gpio/gpio-samsung.c| 63
> > 2 files changed, 101 insertions(+), 0 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
> > b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt index
> > 5375625..ce6a7d4 100644
> > --- a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
> > +++ b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
> >
> > @@ -39,3 +39,41 @@ Example:
> > #gpio-cells = <4>;
> > gpio-controller;
> >
> > };
> >
> > +
> > +
> > +Samsung S3C24XX GPIO Controller
> > +
> > +Required properties:
> > +- compatible: Compatible property value should be
> > "samsung,s3c24xx-gpio".
>
> This is debatable, but I would choose to be specific here and use
> "samsing,s3c2416-gpio". For instance, SoC's in s3c24xx family have
> differing value for pull none/down/up.
Hmmm, but the logic to drive the gpio controller is the same for all arches.
The only difference is the number to use for the different pull up/down
settings. So I think the "samsung,s3c24xx-gpio" is ok but the documentation
should simply reflect the different pull settings.
> > +
> > +- reg: Physical base address of the controller and length of memory
> > mapped + region.
> > +
> > +- #gpio-cells: Should be 3. The syntax of the gpio specifier used by
> > client nodes + should be the following with values derived from the SoC
> > user manual. + <[phandle of the gpio controller node]
> > + [pin number within the gpio controller]
> > + [mux function]
> > + [flags and pull up/down]
> > +
> > + Values for gpio specifier:
> > + - Pin number: depending on the controller a number from 0 up to 15.
> > + - Flags and Pull Up/Down: 0 - Pull Up/Down Disabled.
> > +1 - Pull Down Enabled.
> > +3 - Pull Up Enabled.
>
> As per s3c2416 user manual, 2 is used for Pull Up and 3 is listed as
> reserved value. Any particular reason to use 3 here for pull up and
> not 2 as per the user manual?
Sorry, copy and paste error :-)
> > + Bit 16 (0x0001) - Input is active low.
> > +
> > +- gpio-controller: Specifies that the node is a gpio controller.
> > +- #address-cells: should be 1.
> > +- #size-cells: should be 1.
>
> It would be informative to add information about the 'mux function'
> cell here as well. Specifically, on how to handle the banks that have
> an extended GPxSEL register that allow additional pin function
> selection.
Will add a mux function description.
Until now I've never realised the existence of the GPxSEL registers, so thanks
for the pointer :-).
But is this used in the driver at all? All the setcfg/getcfg functions in
gpio-samsung.c only handle the GPxCON registers - I haven't found code to
handle the GPxSEL registers at all. So my guess is that this was never
implemented - or that I'm blind ;-) .
> > +
> > +Example:
> > +
> > + gpa: gpio-controller@5600 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "samsung,s3c24xx-gpio";
> > + reg = <0x5600 0x10>;
> > + #gpio-cells = <3>;
> > + gpio-controller;
> > + };
> > diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
> > index a150d2e..80a2817 100644
> > --- a/drivers/gpio/gpio-samsung.c
> > +++ b/drivers/gpio/gpio-samsung.c
> > @@ -938,6 +938,67 @@ static void __init samsung_gpiolib_add(struct
> > samsung_gpio_chip *chip)
> >
> > s3c_gpiolib_track(chip);
> >
> > }
> >
> > +#if defined(CONFIG_PLAT_S3C24XX) && defined(CONFIG_OF)
> > +static int s3c24xx_gpio_xlate(struct gpio_chip *gc,
> > + const struct of_phandle_args *gpiospec, u32
> > *flags) +{
> > + unsigned int pin;
> > +
> > + if (WARN_ON(gc->of_gpio_n_cells < 3))
> > + return -EINVAL;
> > +
> > + if (WARN_ON(gpiospec->args_count < gc->of_gpio_n_cells))
> > + return -EINVAL;
> > +
> > + if (gpiospec->args[0] > gc->ngpio)
> > + return -EINVAL;
> > +
> > + pin = gc->base + gpiospec->args[0];
> > +
> > + if (s3c_gpio_cfgpin(pin, S3C_GPIO_SFN(gpiospec->args[1]
[RESEND][PATCH] ARM: Exynos4: fixed SYSMMU setup definition to mate parameter name
This is trivial patch to mate parameter name between iommu api enabled case and
disabled case.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
Sorry about typo in previous patch.
arch/arm/mach-exynos/include/mach/sysmmu.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/sysmmu.h
b/arch/arm/mach-exynos/include/mach/sysmmu.h
index 998daf2..81e4c66 100644
--- a/arch/arm/mach-exynos/include/mach/sysmmu.h
+++ b/arch/arm/mach-exynos/include/mach/sysmmu.h
@@ -58,7 +58,7 @@ static inline void platform_set_sysmmu(
#endif
#else /* !CONFIG_EXYNOS_DEV_SYSMMU */
-#define platform_set_sysmmu(dev, sysmmu) do { } while (0)
+#define platform_set_sysmmu(sysmmu, dev) do { } while (0)
#endif
#define SYSMMU_CLOCK_DEVNAME(ipname, id) (SYSMMU_DEVNAME_BASE "." #id)
--
1.7.4.1
--
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] ARM: Exynos4: fixed SYSMMU setup definition to mate parameter name
This is trivial patch to mate parameter name between iommu api enabled case and
disabled case.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
arch/arm/mach-exynos/include/mach/sysmmu.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/sysmmu.h
b/arch/arm/mach-exynos/include/mach/sysmmu.h
index 998daf2..81e4c66 100644
--- a/arch/arm/mach-exynos/include/mach/sysmmu.h
+++ b/arch/arm/mach-exynos/include/mach/sysmmu.h
@@ -58,7 +58,7 @@ static inline void platform_set_sysmmu(
#endif
#else /* !CONFIG_EXYNOS_DEV_SYSMMU */
-#define platform_set_sysmmu(dev, sysmmu) do { } while (0)
+#define platform_set_sysmmu(sysmu, dev) do { } while (0)
#endif
#define SYSMMU_CLOCK_DEVNAME(ipname, id) (SYSMMU_DEVNAME_BASE "." #id)
--
1.7.4.1
--
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
