Re: [PATCH v2 1/3] pinctrl: exynos: add exynos5250 SoC specific data

[Linus Walleij]

On Thu, Mar 7, 2013 at 12:09 PM, Kukjin Kim  wrote:
> [Me]
>> So shall I merge these three patches to the pinctrl tree or not?
>>
> Hi Linus, this series is already in Samsung tree with your ack.

OK good, thanks!

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: State of pinctrl and exynos5250?

[Doug Anderson]

Linus,

On Thu, Mar 7, 2013 at 6:04 PM, Linus Walleij  wrote:
> On Thu, Mar 7, 2013 at 5:13 PM, Doug Anderson  wrote:
>
>> ...I think the most important issue at hand is the device tree
>> bindings for pinmux on this device.  It sounds like you are in
>> agreement that the best thing is to have a pinmux specified per-slot.
>
> I don't know, Stephen's point to have one single pinctrl set-up for the
> entire device seems perfectly valid, why do you need to specify it
> per-slot at all?

OK by me.  It seemed more "pure" to specify it per-slot (in case we
ever did have a struct device per slot, it would make live easier).
...but it doesn't seem incorrect to have it once for the entire
device.

:)

-Doug

P.S. sorry for double mail for some people...
--
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: State of pinctrl and exynos5250?

[Linus Walleij]

On Thu, Mar 7, 2013 at 5:13 PM, Doug Anderson  wrote:

> ...I think the most important issue at hand is the device tree
> bindings for pinmux on this device.  It sounds like you are in
> agreement that the best thing is to have a pinmux specified per-slot.

I don't know, Stephen's point to have one single pinctrl set-up for the
entire device seems perfectly valid, why do you need to specify it
per-slot at all?

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 00/23] RFC: exynos multiplatform support

[Tomasz Figa]

On Thursday 07 of March 2013 08:22:03 Thierry Reding wrote:
> On Thu, Mar 07, 2013 at 03:02:46AM +, Arnd Bergmann wrote:
> > On Wednesday 06 March 2013, Thierry Reding wrote:
> > > > Option 2 would probably come down to having a trivial MFD driver
> > > > exposing a regmap. You can probably reuse drivers/mfd/syscon.c
> > > > for this and make the node compatible with "syscon" to designate
> > > > the clock registers as a system-wide resource, making the other
> > > > device nodes register-less.> > 
> > > I think option 2 is the standard method if one hardware block
> > > provides
> > > several logical devices. I find it to be a pretty nice solution to
> > > this
> > > problem. We also have precedent in the PWM subsystem. The TWL chips
> > > for
> > > instance use it to create a platform device which is later driven by
> > > a
> > > PWM driver.
> > 
> > One difference though is that the TWL chip is a heterogenous MFD that
> > has a lot of different sub-devices, where in case of Exynos the timer
> > device has a set of identical units, each of which can be used either
> > as a PWM or as a clocksource or other timer.
> 
> I didn't know that. However I still making this an MFD driver is a good
> fit because it'll move the logic of defining the mode of each unit is
> kept in a parent driver which can instantiate the proper child devices
> for the corresponding subsystems.
> 
> One big disadvantage of this approach is that if this is continued there
> is a risk that MFD will turn into a dump for all kinds of devices that
> provide more than a single service.
> 
> So if people prefer option 3 I'm fine with it as well.

I have a question regarding making this an MFD driver.

As you know, the main clocksource driver must be initialized early, from 
init_time callback of machine_desc. How does using the MFD subsystem fit 
into this scheme?

P.S. I'm still not convinced about any benefits of options 2 and 3 over 
option 1, which has the obvious advantage of requiring least amount of 
changes to existing code and not binding the PWM and clocksource drivers 
together (on Exynos SoCs only the PWM driver is used, clocksource is 
handled by different hardware block - MCT).

Best regards,
Tomasz

--
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: State of pinctrl and exynos5250?

[Stephen Warren]

On 03/07/2013 09:27 AM, Doug Anderson wrote:
> +the proper address for Will.  Sorry...
> 
> 
> On Thu, Mar 7, 2013 at 8:13 AM, Doug Anderson  > wrote:
> 
> Linus,
> 
> +dw_mmc folks and Stephen Warren : for context here, we are discussing
> device tree bindings for pinmux for dw_mmc.  The issue at hand is
> whether they belong under the slot node or under the top-level device
> node.

There's no need for dynamic pin-muxing for MMC AFAIK, so I'd expect a
single pinctrl state "default" to exist that covers any/all requirements
of both slots' pinmux configuration.

> On Wed, Mar 6, 2013 at 11:57 PM, Linus Walleij
> mailto:linus.wall...@linaro.org>> wrote:
> > I don't quite understand the above. Is it such that there is one
> device,
> > with two slots, and in the device model you have represented this
> > two-slot device with a single struct device?
> 
> Yes, that's the issue.  That's dw_mmc that has been in the kernel for
> a bit of time now (looks like Jan 2011) and has had a single struct
> device for as long as I've been looking at it.
> 
> Relevant links for convenience:
> *
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/mmc/host/dw_mmc.c
> *
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
> *
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos5250.dtsi#n243
> *
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/cros5250-common.dtsi#n92
> 
> 
> > Have you considered just registering one device for each slot?
> >
> > That would make things quite a lot simpler, just a single pinctrl
> > handle per device, right?
> 
> I don't know why the original decision was made to just have one
> struct device.  ...that would be a pretty big code change at this
> point, I think.
> 
> ...I think the most important issue at hand is the device tree
> bindings for pinmux on this device.  It sounds like you are in
> agreement that the best thing is to have a pinmux specified per-slot.
> If the code is a bit awkward now (due to not having a struct device
> per slot) then that's just something we have to live with.
> 
> 
> -Doug
> 
> 

--
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: State of pinctrl and exynos5250?

[Doug Anderson]

Linus,

+dw_mmc folks and Stephen Warren : for context here, we are discussing
device tree bindings for pinmux for dw_mmc.  The issue at hand is
whether they belong under the slot node or under the top-level device
node.


On Wed, Mar 6, 2013 at 11:57 PM, Linus Walleij  wrote:
> I don't quite understand the above. Is it such that there is one device,
> with two slots, and in the device model you have represented this
> two-slot device with a single struct device?

Yes, that's the issue.  That's dw_mmc that has been in the kernel for
a bit of time now (looks like Jan 2011) and has had a single struct
device for as long as I've been looking at it.

Relevant links for convenience:
* 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/mmc/host/dw_mmc.c
* 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
* 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos5250.dtsi#n243
* 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/cros5250-common.dtsi#n92


> Have you considered just registering one device for each slot?
>
> That would make things quite a lot simpler, just a single pinctrl
> handle per device, right?

I don't know why the original decision was made to just have one
struct device.  ...that would be a pretty big code change at this
point, I think.

...I think the most important issue at hand is the device tree
bindings for pinmux on this device.  It sounds like you are in
agreement that the best thing is to have a pinmux specified per-slot.
If the code is a bit awkward now (due to not having a struct device
per slot) then that's just something we have to live with.


-Doug
--
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/4] cpufreq: exynos: Adding cpufreq driver for exynos5440

[Russell King - ARM Linux]

On Thu, Mar 07, 2013 at 04:28:00PM +0100, Sylwester Nawrocki wrote:
> On 03/07/2013 05:13 AM, Amit Daniel Kachhap wrote:
> > +   dvfs_info->cpu_clk = devm_clk_get(dvfs_info->dev, "armclk");
> > +   if (IS_ERR_OR_NULL(dvfs_info->cpu_clk)) {
> 
> devm_clk_get() return value needs to be checked with IS_ERR(),
> not IS_ERR_OR_NULL().
> 
> > +   pr_err("Failed to get cpu clock\n");
> > +   ret = PTR_ERR(dvfs_info->cpu_clk);
> > +   goto err_free_table;

Amit, to illustrate why this is wrong, consider this:
1. Set cpu_clk to NULL.
2. Realise IS_ERR_OR_NULL(NULL) is true.
3. What is the value of PTR_ERR(NULL) ?
4. What effect does that have when you jump to err_free_table ?
5. What value is returned from this function in that case ?
6. What does that return value mean to the driver core ?
--
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: SAMSUNG: Set clock parent if provided

[Sylwester Nawrocki]

On 03/07/2013 06:31 AM, Shaik Ameer Basha wrote:
> s3c_set_clksrc() updates the clock source as per u-boot settings.
> This patch adds the functionality to overwrite u-boot settings,
> if user provides the clock parent field. In case of wrong source
> provided by the user, it will retain the u-boot settings.
> 
> Signed-off-by: Shaik Ameer Basha 
> ---
>  arch/arm/plat-samsung/clock-clksrc.c |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/plat-samsung/clock-clksrc.c 
> b/arch/arm/plat-samsung/clock-clksrc.c
> index 786a410..4fecd80 100644
> --- a/arch/arm/plat-samsung/clock-clksrc.c
> +++ b/arch/arm/plat-samsung/clock-clksrc.c
> @@ -150,7 +150,12 @@ void __init_or_cpufreq s3c_set_clksrc(struct clksrc_clk 
> *clk, bool announce)
>   return;
>   }
>  
> - clk->clk.parent = srcs->sources[clksrc];
> + if (clk->clk.parent) {
> + if (s3c_setparent_clksrc(&clk->clk, clk->clk.parent))
> + clk->clk.parent = srcs->sources[clksrc];
> + } else {
> + clk->clk.parent = srcs->sources[clksrc];
> + }

May I ask what do you need this for ? This code won't be used for
Exynos4 and Exynos5 SoCs starting from 3.10. And it is going to be
removed once other platforms are converted to the new Samsung clocks
driver.

Regards,
Sylwester
--
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/4] cpufreq: exynos: Adding cpufreq driver for exynos5440

[Sylwester Nawrocki]

On 03/07/2013 05:13 AM, Amit Daniel Kachhap wrote:
> +/* Register definations */

s/definations/definitions

> +#define XMU_DVFS_CTRL0x0060
> +#define XMU_PMU_P0_7 0x0064
> +#define XMU_C0_3_PSTATE  0x0090
> +#define XMU_P_LIMIT  0x00A0
> +#define XMU_P_STATUS 0x00A4
> +#define XMU_PMUEVTEN 0x00D0
> +#define XMU_PMUIRQEN 0x00D4
> +#define XMU_PMUIRQ   0x00D8

Keeping all hex numbers lower case might be a good idea.

> +
> +/* PMU mask and shift definations */
> +#define P_VALUE_MASK 0x7
> +
> +#define XMU_DVFS_CTRL_EN_SHIFT   0
> +
> +#define P0_7_CPUCLKDEV_SHIFT 21
> +#define P0_7_CPUCLKDEV_MASK  0x7
> +#define P0_7_ATBCLKDEV_SHIFT 18
> +#define P0_7_ATBCLKDEV_MASK  0x7
> +#define P0_7_CSCLKDEV_SHIFT  15
> +#define P0_7_CSCLKDEV_MASK   0x7
> +#define P0_7_CPUEMA_SHIFT28
> +#define P0_7_CPUEMA_MASK 0xf
> +#define P0_7_L2EMA_SHIFT 24
> +#define P0_7_L2EMA_MASK  0xf
...
> +static int exynos_cpufreq_probe(struct platform_device *pdev)
> +{
> + int ret = -EINVAL;
> + struct device_node *np;
> + struct resource res;
> +
> + np =  of_find_compatible_node(NULL, NULL, "samsung,exynos5440-cpufreq");
> + if (!np)
> + return -ENODEV;
> +
> + dvfs_info = devm_kzalloc(&pdev->dev, sizeof(*dvfs_info), GFP_KERNEL);
> + if (!dvfs_info) {
> + ret = -ENOMEM;
> + goto err_put_node;
> + }
> +
> + dvfs_info->dev = &pdev->dev;
> + dvfs_info->dev->of_node = np;
> +
> + ret = of_address_to_resource(np, 0, &res);
> + if (ret)
> + goto err_put_node;
> +
> + dvfs_info->base = devm_ioremap(dvfs_info->dev, res.start,

There is a devm_ioremap_resource() function that has been introduced
recently. It could simplify this code a bit and is preferred over
devm_ioremap().

> + resource_size(&res));
> + if (!dvfs_info->base) {
> + pr_err("No cpufreq memory map found\n");
> + ret = -ENODEV;
> + goto err_put_node;
> + }
> +
> + dvfs_info->irq = irq_of_parse_and_map(np, 0);
> + if (dvfs_info->irq == 0) {
> + pr_err("No cpufreq irq found\n");

Wouldn't dev_err() be more appropriate here ?

> + ret = -ENODEV;
> + goto err_put_node;
> + }
> +
> + ret = of_init_opp_table(dvfs_info->dev);
> + if (ret) {
> + pr_err("failed to init OPP table: %d\n", ret);
> + goto err_put_node;
> + }
> +
> + ret = opp_init_cpufreq_table(dvfs_info->dev, &dvfs_info->freq_table);
> + if (ret) {
> + pr_err("failed to init cpufreq table: %d\n", ret);
> + goto err_put_node;
> + }
> + dvfs_info->freq_count = opp_get_opp_count(dvfs_info->dev);
> + exynos_sort_descend_freq_table();
> +
> + if (of_property_read_u32(np, "clock-latency", &dvfs_info->latency))
> + dvfs_info->latency = DEF_TRANS_LATENCY;
> +
> + dvfs_info->cpu_clk = devm_clk_get(dvfs_info->dev, "armclk");
> + if (IS_ERR_OR_NULL(dvfs_info->cpu_clk)) {

devm_clk_get() return value needs to be checked with IS_ERR(),
not IS_ERR_OR_NULL().

> + pr_err("Failed to get cpu clock\n");
> + ret = PTR_ERR(dvfs_info->cpu_clk);
> + goto err_free_table;
> + }
> +
> + dvfs_info->cur_frequency = clk_get_rate(dvfs_info->cpu_clk);
> + if (!dvfs_info->cur_frequency) {
> + pr_err("Failed to get clock rate\n");
> + ret = -EINVAL;
> + goto err_free_table;
> + }
> + dvfs_info->cur_frequency /= 1000;
> +
> + INIT_WORK(&dvfs_info->irq_work, exynos_cpufreq_work);
> + if (devm_request_irq(dvfs_info->dev, dvfs_info->irq, exynos_cpufreq_irq,
> + IRQF_TRIGGER_NONE, CPUFREQ_NAME, dvfs_info)) {
> + pr_err("Failed to register IRQ\n");
> + ret = -ENODEV;
> + goto err_free_table;
> + }
> +
> + ret = init_div_table();
> + if (ret) {
> + pr_err("Failed to initialise div table\n");
> + goto err_free_table;
> + }
> +
> + exynos_enable_dvfs();
> + ret = cpufreq_register_driver(&exynos_driver);
> + if (ret) {
> + pr_err("%s: failed to register cpufreq driver\n", __func__);
> + goto err_free_table;
> + }
> +
> + of_node_put(np);
> + dvfs_info->dvfs_enable = true;
> + pr_info("exynos5440 DVFS initialized.\n");

dev_info() ?

> + return 0;
> +
> +err_free_table:
> + opp_free_cpufreq_table(dvfs_info->dev, &dvfs_info->freq_table);
> +err_put_node:
> + of_node_put(np);
> + pr_err("%s: failed initialization\n", __func__);

Is this really needed ? This failure will be logged by the driver core
anyway.

> + return ret;
> +
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordom

Re: [PATCH] ARM: EXYNOS: change HAVE_SAMSUNG_KEYPAD to KEYBOARD_SAMSUNG

[Paul Bolle]

On Thu, 2013-03-07 at 10:02 +0900, Kukjin Kim wrote:
> BTW, just to use only 8~12 digits of commit ID, "Commit 6b5ab4f4" is
> enough instead of full commit ID.

I used to do that but now I actually prefer to use 40 hex character
strings.

Sure, they're ugly, but so are strings of 10, or 12 hex characters. But
they're easier to use (I can just copy/paste them from the output of,
say, "git log"), I do not have to worry about uniqueness, ever (some
commits now already need at least 8 characters), and some git web
interfaces automagically linkify 40 character hex strings in commit
explanations (which is quite nice).


Paul Bolle

--
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: remove EXYNOS_DEV_SYSMMU entirely

[Paul Bolle]

On Thu, 2013-03-07 at 10:12 +0900, Kukjin Kim wrote:
> Actually, to update iommu for exynos is on-going. And as I know, it
> will be done this time for v3.10 by KyongHo Cho, so it would be better
> to handle this cleanup with that at the same time.

You mean I should try to recheck the status of EXYNOS_DEV_SYSMMU around
(say) v3.10-rc1? If so, that's fine with me.


Paul Bolle

--
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/3] pinctrl: exynos: add exynos5250 SoC specific data

[Kukjin Kim]

Linus Walleij wrote:
> 
> On Wed, Mar 6, 2013 at 12:18 PM, Thomas Abraham
>  wrote:
> 
> > Add Samsung Exynos5250 SoC specific data to enable pinctrl support for
> > all platforms based on Exynos5250.
> >
> > Signed-off-by: Thomas Abraham 
> > Reviewed-by: Tomasz Figa 
> > Acked-by: Linus Walleij 
> 
> So shall I merge these three patches to the pinctrl tree or not?
> 
Hi Linus, this series is already in Samsung tree with your ack.

Thanks.

- Kukjin

--
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: S5PV210: Fix PL330 DMA controller clkdev entries

[Kukjin Kim]

Sylwester Nawrocki wrote:
> 
> On 03/04/2013 02:00 PM, Kukjin Kim wrote:
> > Looks good to me, applied into -fixes.
> >
> > Sylwester, why did you want to re-send this patch?
> 
> Only to add
> 
> Tested-by: Lonsn 
> Cc: sta...@vger.kernel.org # 3.7
> 
> tags, and any other in case someone else tests the patch.
> 
> I think we would need this fix for stable 3.7 as well.
> 
> Thanks for applying it.
> 
I already added above when I applied ;-)

Thanks for your confirmation.

- Kukjin

--
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: dwmmc: let device core setup the default pin configuration

[Seungwon Jeon]

Hi Thomas,

On Wednesday, March 06, 2013, Thomas Abraham wrote:
> With device core now able to setup the default pin configuration,
> the pin configuration code based on the deprecated Samsung specific
> gpio bindings is removed.

'setup_bus' callback is still useful in dw_mci_drv_data?
Considering the purpose, it would be good to remove.
And, could you change commit prefix for consistency?
dwmmc -> dw_mmc

Thanks,
Seungwon Jeon
> 
> Signed-off-by: Thomas Abraham 
> ---
>  drivers/mmc/host/dw_mmc-exynos.c |   38 
> --
>  1 files changed, 0 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/mmc/host/dw_mmc-exynos.c 
> b/drivers/mmc/host/dw_mmc-exynos.c
> index 72fd0f2..467d043 100644
> --- a/drivers/mmc/host/dw_mmc-exynos.c
> +++ b/drivers/mmc/host/dw_mmc-exynos.c
> @@ -152,43 +152,6 @@ static int dw_mci_exynos_parse_dt(struct dw_mci *host)
>   return 0;
>  }
> 
> -static int dw_mci_exynos_setup_bus(struct dw_mci *host,
> - struct device_node *slot_np, u8 bus_width)
> -{
> - int idx, gpio, ret;
> -
> - if (!slot_np)
> - return -EINVAL;
> -
> - /* cmd + clock + bus-width pins */
> - for (idx = 0; idx < NUM_PINS(bus_width); idx++) {
> - gpio = of_get_gpio(slot_np, idx);
> - if (!gpio_is_valid(gpio)) {
> - dev_err(host->dev, "invalid gpio: %d\n", gpio);
> - return -EINVAL;
> - }
> -
> - ret = devm_gpio_request(host->dev, gpio, "dw-mci-bus");
> - if (ret) {
> - dev_err(host->dev, "gpio [%d] request failed\n", gpio);
> - return -EBUSY;
> - }
> - }
> -
> - 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"))
> - 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 |
> @@ -205,7 +168,6 @@ static const struct dw_mci_drv_data exynos5250_drv_data = 
> {
>   .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[] = {
> --
> 1.6.6.rc2
> 
> --
> 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] ARM: SAMSUNG: Set clock parent if provided

[Rahul Sharma]

On Thu, Mar 7, 2013 at 3:12 PM, Shaik Ameer Basha
 wrote:
> Hi Rahul,
>
> On Thu, Mar 7, 2013 at 2:58 PM, Rahul Sharma  wrote:
>> On Thu, Mar 7, 2013 at 11:01 AM, Shaik Ameer Basha
>>  wrote:
>>> s3c_set_clksrc() updates the clock source as per u-boot settings.
>>> This patch adds the functionality to overwrite u-boot settings,
>>> if user provides the clock parent field. In case of wrong source
>>> provided by the user, it will retain the u-boot settings.
>>>
>>> Signed-off-by: Shaik Ameer Basha 
>>> ---
>>>  arch/arm/plat-samsung/clock-clksrc.c |7 ++-
>>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/plat-samsung/clock-clksrc.c 
>>> b/arch/arm/plat-samsung/clock-clksrc.c
>>> index 786a410..4fecd80 100644
>>> --- a/arch/arm/plat-samsung/clock-clksrc.c
>>> +++ b/arch/arm/plat-samsung/clock-clksrc.c
>>> @@ -150,7 +150,12 @@ void __init_or_cpufreq s3c_set_clksrc(struct 
>>> clksrc_clk *clk, bool announce)
>>> return;
>>> }
>>>
>>> -   clk->clk.parent = srcs->sources[clksrc];
>>> +   if (clk->clk.parent) {
>>> +   if (s3c_setparent_clksrc(&clk->clk, clk->clk.parent))
>>> +   clk->clk.parent = srcs->sources[clksrc];
>>
>> IMO, it make sense to return the error value if failed. Now you
>> are masking the failed cases (due to invalid parent clk) and proceeding
>> with uboot values which is not the intention when parent clock
>> is provided.
>
> yes you are right. But as the function s3c_set_clksrc() is not
> expected to return any error codes,
> I tried to use default u-boot settings.
> We can add a warning message to let user know in case of wrong parent
> assignment.
>

Agreed. Printing error val with KERN_ERR and return would be better.

> Regards,
> Shaik Ameer Basha
>
>>
>> Regards,
>> Rahul Sharma,
>>
>>> +   } else {
>>> +   clk->clk.parent = srcs->sources[clksrc];
>>> +   }
>>>
>>> if (announce)
>>> printk(KERN_INFO "%s: source is %s (%d), rate is %ld\n",
>>> --
>>> 1.7.9.5
>>>
>>> --
>>> 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
>>
>> --



-- 
Regards,
Rahul Sharma,
email to: rahul.sha...@samsung.com
Samsung India.
--
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 RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver

[Rahul Sharma]

On Thu, Mar 7, 2013 at 12:37 PM, Stéphane Marchesin
 wrote:
> On Wed, Mar 6, 2013 at 8:43 PM, Inki Dae  wrote:
>> 2013/3/7 김승우 :
>>>
>>>
>>> On 2013년 03월 04일 23:05, Rahul Sharma wrote:
 Thanks Sean,

 On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul  wrote:
> On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma  
> wrote:
>> Right now hdmiphy operations and configs are kept inside hdmi driver. 
>> hdmiphy related
>> code is tightly coupled with hdmi ip driver. Physicaly they are 
>> different devices and
>
> s/Physicaly/Physically/
>
>> should be instantiated independently.
>>
>> In terms of versions/mapping/configurations Hdmi and hdmiphy are 
>> independent of each
>> other. It is preferred to isolate them and maintained independently.
>>
>> This implementations is tested for:
>> 1) Resolutions supported by exynos4 and 5 hdmi.
>> 2) Runtime PM and S2R scenarions for exynos5.
>>
>
> I don't like the idea of spawning off yet another driver in here. It
> adds more globals, more suspend/resume ordering issues, and more
> implicit dependencies. I understand, however, that this is the Chosen
> Way for the exynos driver, so I will save my rant.
>

 I agree to it. splitting phy to a new driver will complicate the power 
 related
 scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of
 config values, mapping (i2c/platform bus) etc. Handling this diversity
 inside hdmi driver is complicating it with unrelated changes.
>>>
>>> Basically, I agree with the idea to split hdmiphy from hdmi. And it
>>> seems that already existing hdmiphy i2c device is just reused and
>>> hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling
>>> flow of power operations is reordered.
>>>
>>> But I'm not sure exynos_hdmiphy_driver_register() really need to be
>>> called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to
>>> call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy
>>> is only used from hdmi.
>>>
>>
>> I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem.
>>
>
> But this is probably going to break dpms and/or suspend/resume
> functionality. Has that been tested?
>
> Stéphane
>
Hi Stéphane

This has been tested for dpms and suspend/resume scenarios for exynos5. I
have yet to try with hdmi, mixer, phy driver registration moved to
common-drm-hdmi.

regards,
Rahul Sharma.

>> Thanks,
>> Inki Dae
>>
>>> Thanks and Regards,
>>> - Seung-Woo Kim
>>>

 I have tested this RFC for Runtime PM / S2R. But if we see any major 
 roadblock
 we should re-factor this by explicitly calling power related callbacks
 of mixer, phy,
 hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf
 device. AFAIR something like this is already in place in chrome-kernel.

> I've made some comments below.
>
>> This patch is dependent on
>> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34733.html
>> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34861.html
>> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34862.html
>>
>> Signed-off-by: Rahul Sharma 
>> ---
>> It is based on exynos-drm-next-todo branch at
>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   8 +
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |   6 +
>>  drivers/gpu/drm/exynos/exynos_drm_hdmi.c |  58 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_hdmi.h |  11 +
>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++--
>>  drivers/gpu/drm/exynos/exynos_hdmi.h |   1 -
>>  drivers/gpu/drm/exynos/exynos_hdmiphy.c  | 586 
>> ++-
>>  drivers/gpu/drm/exynos/regs-hdmiphy.h|  61 
>>  8 files changed, 738 insertions(+), 368 deletions(-)
>>  create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
>>
>>>
>>> 
>>>
>>> --
>>> Seung-Woo Kim
>>> Samsung Software R&D Center
>>> --
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-de...@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> --
> 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



-- 
Regards,
Rahul Sharma,
email to: rahul.sha...@samsung.com
Samsung India.
--
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-

Re: [PATCH] ARM: SAMSUNG: Set clock parent if provided

[Shaik Ameer Basha]

Hi Rahul,

On Thu, Mar 7, 2013 at 2:58 PM, Rahul Sharma  wrote:
> On Thu, Mar 7, 2013 at 11:01 AM, Shaik Ameer Basha
>  wrote:
>> s3c_set_clksrc() updates the clock source as per u-boot settings.
>> This patch adds the functionality to overwrite u-boot settings,
>> if user provides the clock parent field. In case of wrong source
>> provided by the user, it will retain the u-boot settings.
>>
>> Signed-off-by: Shaik Ameer Basha 
>> ---
>>  arch/arm/plat-samsung/clock-clksrc.c |7 ++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/plat-samsung/clock-clksrc.c 
>> b/arch/arm/plat-samsung/clock-clksrc.c
>> index 786a410..4fecd80 100644
>> --- a/arch/arm/plat-samsung/clock-clksrc.c
>> +++ b/arch/arm/plat-samsung/clock-clksrc.c
>> @@ -150,7 +150,12 @@ void __init_or_cpufreq s3c_set_clksrc(struct clksrc_clk 
>> *clk, bool announce)
>> return;
>> }
>>
>> -   clk->clk.parent = srcs->sources[clksrc];
>> +   if (clk->clk.parent) {
>> +   if (s3c_setparent_clksrc(&clk->clk, clk->clk.parent))
>> +   clk->clk.parent = srcs->sources[clksrc];
>
> IMO, it make sense to return the error value if failed. Now you
> are masking the failed cases (due to invalid parent clk) and proceeding
> with uboot values which is not the intention when parent clock
> is provided.

yes you are right. But as the function s3c_set_clksrc() is not
expected to return any error codes,
I tried to use default u-boot settings.
We can add a warning message to let user know in case of wrong parent
assignment.

Regards,
Shaik Ameer Basha

>
> Regards,
> Rahul Sharma,
>
>> +   } else {
>> +   clk->clk.parent = srcs->sources[clksrc];
>> +   }
>>
>> if (announce)
>> printk(KERN_INFO "%s: source is %s (%d), rate is %ld\n",
>> --
>> 1.7.9.5
>>
>> --
>> 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] ARM: S3C24XX: drop "select MACH_N35"

[Russell King - ARM Linux]

On Thu, Mar 07, 2013 at 10:14:19AM +0900, Kukjin Kim wrote:
> Russell King - ARM Linux wrote:
> > And deleting entries from it is pointless if they've ever been in the
> > kernel.
> 
> OK, I see and agree.

The issue is that the database system "locks" an entry into the file as
soon as support is merged into mainline for the platform.  The reason
for this is that as soon as the support gets merged into a kernel verison,
that symbol is then referenced.

If anyone goes to the website to download a new copy of the file, it then
must continue to contain that symbol because they may be using the file
with any kernel version - maybe a version of the kernel with your platform
support in - and maybe they're using something that references the
generated ID/macros from your entry.

Updates to the file in the mainline kernel are merely re-downloads of the
file from the website and committed.

So, deleting entries once used in mainline is extremely problematical.  If
someone commits such a patch, my next update from the website/database to
the file will put it back.  Hence the problem.
--
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: SAMSUNG: Set clock parent if provided

[Rahul Sharma]

On Thu, Mar 7, 2013 at 11:01 AM, Shaik Ameer Basha
 wrote:
> s3c_set_clksrc() updates the clock source as per u-boot settings.
> This patch adds the functionality to overwrite u-boot settings,
> if user provides the clock parent field. In case of wrong source
> provided by the user, it will retain the u-boot settings.
>
> Signed-off-by: Shaik Ameer Basha 
> ---
>  arch/arm/plat-samsung/clock-clksrc.c |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/plat-samsung/clock-clksrc.c 
> b/arch/arm/plat-samsung/clock-clksrc.c
> index 786a410..4fecd80 100644
> --- a/arch/arm/plat-samsung/clock-clksrc.c
> +++ b/arch/arm/plat-samsung/clock-clksrc.c
> @@ -150,7 +150,12 @@ void __init_or_cpufreq s3c_set_clksrc(struct clksrc_clk 
> *clk, bool announce)
> return;
> }
>
> -   clk->clk.parent = srcs->sources[clksrc];
> +   if (clk->clk.parent) {
> +   if (s3c_setparent_clksrc(&clk->clk, clk->clk.parent))
> +   clk->clk.parent = srcs->sources[clksrc];

IMO, it make sense to return the error value if failed. Now you
are masking the failed cases (due to invalid parent clk) and proceeding
with uboot values which is not the intention when parent clock
is provided.

Regards,
Rahul Sharma,

> +   } else {
> +   clk->clk.parent = srcs->sources[clksrc];
> +   }
>
> if (announce)
> printk(KERN_INFO "%s: source is %s (%d), rate is %ld\n",
> --
> 1.7.9.5
>
> --
> 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 RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver

[Inki Dae]

> -Original Message-
> From: 김승우 [mailto:sw0312@samsung.com]
> Sent: Thursday, March 07, 2013 4:04 PM
> To: Rahul Sharma
> Cc: Inki Dae; linux-samsung-soc@vger.kernel.org; Sean Paul; sunil joshi;
> dri-de...@lists.freedesktop.org; Rahul Sharma; sw0312@samsung.com
> Subject: Re: [PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to
> hdmiphy driver
> 
> 
> 
> On 2013년 03월 07일 15:45, Rahul Sharma wrote:
> > Thanks Seung Woo, Mr. Dae,
> >
> > On Thu, Mar 7, 2013 at 10:13 AM, Inki Dae  wrote:
> >> 2013/3/7 김승우 :
> >>>
> >>>
> >>> On 2013년 03월 04일 23:05, Rahul Sharma wrote:
>  Thanks Sean,
> 
>  On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul 
> wrote:
> > On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma
>  wrote:
> >> Right now hdmiphy operations and configs are kept inside hdmi
> driver. hdmiphy related
> >> code is tightly coupled with hdmi ip driver. Physicaly they are
> different devices and
> >
> > s/Physicaly/Physically/
> >
> >> should be instantiated independently.
> >>
> >> In terms of versions/mapping/configurations Hdmi and hdmiphy are
> independent of each
> >> other. It is preferred to isolate them and maintained
independently.
> >>
> >> This implementations is tested for:
> >> 1) Resolutions supported by exynos4 and 5 hdmi.
> >> 2) Runtime PM and S2R scenarions for exynos5.
> >>
> >
> > I don't like the idea of spawning off yet another driver in here. It
> > adds more globals, more suspend/resume ordering issues, and more
> > implicit dependencies. I understand, however, that this is the
> Chosen
> > Way for the exynos driver, so I will save my rant.
> >
> 
>  I agree to it. splitting phy to a new driver will complicate the
> power related
>  scenarios. But in upcoming SoC,s, Phy is changing considerably in
> terms of
>  config values, mapping (i2c/platform bus) etc. Handling this
> diversity
>  inside hdmi driver is complicating it with unrelated changes.
> >>>
> >>> Basically, I agree with the idea to split hdmiphy from hdmi. And it
> >>> seems that already existing hdmiphy i2c device is just reused and
> >>> hdmiphy_power_on is reorganized to hdmiphy dpms operation: even
> calling
> >>> flow of power operations is reordered.
> >>>
> >>> But I'm not sure exynos_hdmiphy_driver_register() really need to be
> >>> called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough
> to
> >>> call exynos_hdmiphy_driver_register() from hdmi_probe() because
> hdmiphy
> >>> is only used from hdmi.
> >>>
> >>
> >> I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem.
> >>
> >
> > I agree to the Seung Woo's point that hdmi-phy used to be solely
> accessed by
> > hdmi driver.  But in this RFC, hdmi-phy is not called by hdmi driver
> > anymore. Phy
> > ops will be called from drm-common-hdmi platform driver along with mixer
> and
> > hdmi ops.
> 
> Considering this, exynos_drm_hdmi_probe() is more proper position.
> 
> >
> > The rational behind my implementation is that I am projecting hdmi-phy
> as
> > a device which is peer to hdmi ip and mixer. These 3 devices together
> makes
> > DRM HDMI subsystem.
> >
> > Even physically hdmi-phy doesn't seems to be a part of hdmi ip though
> > configurations are listed under hdmi ip user manual. It looks like a
> > isolated module accessed by i2c.
> >
> > Though I don't find anything wrong with Seung Woo suggestion but above
> > placement of hdmi-phy (parallel to hdmi and mixer) makes more sense
> > to me.
> >
> > Please have a another look at it and let me know your opinion.
> >
> > Another things which bothers me is registering mixer, hdmi driver inside
> > exynos_drm_init(). If we strictly follow the hierarchy inside drm,
> > exynos_drm_init()
> > should register drm-common-hdmi only. drm-common-hdmi should register
> > mixer and hdmi (or hdmi-phy as well).
> 
> Yes, it makes sense. All real hw blocks for hdmi including mixer, hdmi,
> and hdmiphy shoulde be registered in exynos_drm_hdmi (drm-common-hdmi
> for exynos).
> 

Ideally, right. But the reason I designed and implemented hdmi subsystem
framework like this, is that there was one issue that
platform_device_register() can't be called at probe(). On other words, when
one platform device driver is being probed, anyone can't be probed. Anyway,
existing way needs to be improved. So let's find better way and improve the
hdmi subsystem framework this time. :)

Thanks,
Inki Dae

> Thanks and Regards,
> - Seung-Woo Kim
> 
> >
> > regards,
> > Rahul Sharma.
> >
> >> Thanks,
> >> Inki Dae
> >>
> >>> Thanks and Regards,
> >>> - Seung-Woo Kim
> >>>
> 
>  I have tested this RFC for Runtime PM / S2R. But if we see any major
> roadblock
>  we should re-factor this by explicitly calling power related
> callbacks
>  of mixer, phy,
>  hdmi drivers in a required order. We can call them from exynos-drm-
> hdmi plf
>  device. AFAIR something like this is alr

Re: [PATCH 0/2] ARM: dts: Add default pin states for client nodes on Exynos4/5 platforms

[Linus Walleij]

On Wed, Mar 6, 2013 at 1:36 PM, Thomas Abraham
 wrote:

> This patch series populates the default pin states in client nodes
> of Exynos4 and Exynos5 platforms. Exynos4/5 platforms are migrating
> to use pinctrl framework and having the default pin states listed
> in the client nodes allows the device core to setup the default
> pin configuration for all the controllers.

The series:
Acked-by: Linus Walleij 

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] ASoC: samsung: let device core setup the default pin configuration

[Linus Walleij]

On Wed, Mar 6, 2013 at 12:55 PM, Thomas Abraham
 wrote:

> With device core now able to setup the default pin configuration,
> the pin configuration code based on the deprecated Samsung specific
> gpio bindings in i2s driver is removed.
>
> Signed-off-by: Thomas Abraham 

Acked-by: Linus Walleij 

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: dwmmc: let device core setup the default pin configuration

[Linus Walleij]

On Wed, Mar 6, 2013 at 1:04 PM, Thomas Abraham
 wrote:

> With device core now able to setup the default pin configuration,
> the pin configuration code based on the deprecated Samsung specific
> gpio bindings is removed.
>
> Signed-off-by: Thomas Abraham 

Acked-by: Linus Walleij 

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] input: samsung-keypad: let device core setup the default pin configuration

[Linus Walleij]

On Wed, Mar 6, 2013 at 12:49 PM, Thomas Abraham
 wrote:

> With device core now able to setup the default pin configuration,
> the pin configuration code based on the deprecated Samsung specific
> gpio bindings is removed.
>
> Signed-off-by: Thomas Abraham 

Acked-by: Linus Walleij 

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] spi: s3c64xx: let device core setup the default pin configuration

[Linus Walleij]

On Wed, Mar 6, 2013 at 12:42 PM, Thomas Abraham
 wrote:

> With device core now able to setup the default pin configuration,
> the pin configuration code based on the deprecated Samsung specific
> gpio bindings is removed.
>
> Signed-off-by: Thomas Abraham 

Acked-by: Linus Walleij 

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: sdhci-s3c: let device core setup the default pin configuration

[Linus Walleij]

On Wed, Mar 6, 2013 at 12:36 PM, Thomas Abraham
 wrote:

> With device core now able to setup the default pin configuration,
> the call to devm_pinctrl_get_select_default can be removed. And
> the pin configuration code based on the deprecated Samsung specific
> gpio bindings is also removed.
>
> Signed-off-by: Thomas Abraham 

Acked-by: Linus Walleij 

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 1/3] pinctrl: exynos: add exynos5250 SoC specific data

[Linus Walleij]

On Wed, Mar 6, 2013 at 12:18 PM, Thomas Abraham
 wrote:

> Add Samsung Exynos5250 SoC specific data to enable pinctrl support for
> all platforms based on Exynos5250.
>
> Signed-off-by: Thomas Abraham 
> Reviewed-by: Tomasz Figa 
> Acked-by: Linus Walleij 

So shall I merge these three patches to the pinctrl tree or not?

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