Patchwork [v3,0/6] mmc: sdhci-s3c: Rework platform data and add device tree support

login
register
mail settings
Submitter Kukjin Kim
Date Feb. 21, 2012, 11:37 a.m.
Message ID <00b901ccf08d$2fc18b50$8f44a1f0$%kim@samsung.com>
Download mbox
Permalink /patch/142290/
State New
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git

Comments

Kukjin Kim - Feb. 21, 2012, 11:37 a.m.
Chris Ball wrote:
> 
> Hi,
> 
Hi,

> On Thu, Feb 16 2012, Kukjin Kim wrote:
> > I mean if I or you create topic branch for this whole series, can be
> > merged into both tree for avoiding conflicts with further working. Of
> > course, the topic branch don't have to rebase after merging into each
> > tree.
> >
> > If you're ok on this and my opinion, let me create the topic branch.
> 
> Okay, sure.  Thanks,
> 
I created topic branch for this we talked. You can pull that following:
  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v3.4-for-cjb

If any problems, please kindly let me know.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

The following changes since commit d65b4e98d7ea3038b767b70fe8be959b2913f16d:

  Linux 3.3-rc3 (2012-02-08 19:21:53 -0800)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v3.4-for-cjb

Thomas Abraham (6):
      mmc: sdhci-s3c: Remove usage of clk_type member in platform data
      ARM: EXYNOS: use 'exynos4-sdhci' as device name for sdhci controllers
      ARM: SAMSUNG: remove all uses of clk_type member in sdhci platform
data
      mmc: sdhci-s3c: derive transfer width host capability from max_width
in platform data
      mmc: sdhci-s3c: Keep a copy of platform data and use it
      mmc: sdhci-s3c: Add device tree support

 .../devicetree/bindings/mmc/samsung-sdhci.txt      |   70 ++++++
 arch/arm/mach-exynos/clock.c                       |   24 +-
 arch/arm/mach-exynos/common.c                      |    5 +
 arch/arm/mach-exynos/mach-armlex4210.c             |    3 -
 arch/arm/mach-exynos/mach-nuri.c                   |    3 -
 arch/arm/mach-exynos/mach-origen.c                 |    2 -
 arch/arm/mach-exynos/mach-smdk4x12.c               |    2 -
 arch/arm/mach-exynos/mach-smdkv310.c               |    4 -
 arch/arm/mach-exynos/mach-universal_c210.c         |    2 -
 arch/arm/plat-samsung/devs.c                       |    4 -
 arch/arm/plat-samsung/include/plat/sdhci.h         |   35 +++-
 arch/arm/plat-samsung/platformdata.c               |    2 -
 drivers/mmc/host/sdhci-s3c.c                       |  235
+++++++++++++++++++-
 13 files changed, 341 insertions(+), 50 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
Chris Ball - Feb. 21, 2012, 1:17 p.m.
Hi,

On Tue, Feb 21 2012, Kukjin Kim wrote:
> I created topic branch for this we talked. You can pull that following:
>   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> v3.4-for-cjb
>
> If any problems, please kindly let me know.

Pushed to mmc-next, thanks.  (I'm expecting that you'll do the merge
to Linus.)

- Chris.
Mark Brown - Feb. 22, 2012, 12:58 p.m.
On Tue, Feb 21, 2012 at 08:17:41AM -0500, Chris Ball wrote:

> Pushed to mmc-next, thanks.  (I'm expecting that you'll do the merge
> to Linus.)

I've been sending patches adding runtime PM support to this driver for a
while with no response - are there any issues with those?
Chris Ball - March 2, 2012, 8:40 p.m.
Hi,

On Wed, Feb 22 2012, Mark Brown wrote:
> On Tue, Feb 21, 2012 at 08:17:41AM -0500, Chris Ball wrote:
>
>> Pushed to mmc-next, thanks.  (I'm expecting that you'll do the merge
>> to Linus.)
>
> I've been sending patches adding runtime PM support to this driver for a
> while with no response - are there any issues with those?

I don't have s3c hardware, so I've been waiting for a Tested-by or ACK
from someone who does -- Kukjin, any objection if I take this into
mmc-next with a plan to merge it, to provoke some testing?  Is it
possible for you to test/review the patch?

Thanks,

- Chris.
Kukjin Kim - March 3, 2012, 12:44 a.m.
On 03/03/12 05:40, Chris Ball wrote:
> Hi,
>
> On Wed, Feb 22 2012, Mark Brown wrote:
>> On Tue, Feb 21, 2012 at 08:17:41AM -0500, Chris Ball wrote:
>>
>>> Pushed to mmc-next, thanks.  (I'm expecting that you'll do the merge
>>> to Linus.)
>>
>> I've been sending patches adding runtime PM support to this driver for a
>> while with no response - are there any issues with those?
>
> I don't have s3c hardware, so I've been waiting for a Tested-by or ACK
> from someone who does -- Kukjin, any objection if I take this into
> mmc-next with a plan to merge it, to provoke some testing?  Is it
> possible for you to test/review the patch?
>
Hi Chris,

Maybe I lost Mark's runtime PM supporting patches. I couldn't find it in 
my mail box. Sorry for that :(

Mark, could you please send it to me again?

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
Jaehoon Chung - March 5, 2012, 10:24 a.m.
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>

On 03/03/2012 09:46 AM, Mark Brown wrote:

> This matches current best practice as one can have runtime PM enabled
> without system sleep and CONFIG_PM is defined for both.
> 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
>  drivers/mmc/host/sdhci-s3c.c |    9 +++++----
>  1 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index ea0767e..46152d6 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -22,6 +22,7 @@
>  #include <linux/module.h>
>  #include <linux/of.h>
>  #include <linux/of_gpio.h>
> +#include <linux/pm.h>
>  
>  #include <linux/mmc/host.h>
>  
> @@ -807,8 +808,7 @@ static int __devexit sdhci_s3c_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> -#ifdef CONFIG_PM
> -
> +#ifdef CONFIG_PM_SLEEP
>  static int sdhci_s3c_suspend(struct device *dev)
>  {
>  	struct sdhci_host *host = dev_get_drvdata(dev);
> @@ -822,10 +822,11 @@ static int sdhci_s3c_resume(struct device *dev)
>  
>  	return sdhci_resume_host(host);
>  }
> +#endif
>  
> +#ifdef CONFIG_PM
>  static const struct dev_pm_ops sdhci_s3c_pmops = {
> -	.suspend	= sdhci_s3c_suspend,
> -	.resume		= sdhci_s3c_resume,
> +	SET_SYSTEM_SLEEP_PM_OPS(sdhci_s3c_suspend, sdhci_s3c_resume)
>  };
>  
>  #define SDHCI_S3C_PMOPS (&sdhci_s3c_pmops)
Jaehoon Chung - March 5, 2012, 10:48 a.m.
Hi Mark,

On 03/03/2012 09:46 AM, Mark Brown wrote:

> Since most of the work is already done by the core we just need to add
> runtime suspend methods and tell the PM core that runtime PM is enabled
> for this device.
> 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
>  drivers/mmc/host/sdhci-s3c.c |   28 ++++++++++++++++++++++++++++
>  1 files changed, 28 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 46152d6..6926ac9 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -23,6 +23,7 @@
>  #include <linux/of.h>
>  #include <linux/of_gpio.h>
>  #include <linux/pm.h>
> +#include <linux/pm_runtime.h>
>  
>  #include <linux/mmc/host.h>
>  
> @@ -721,6 +722,11 @@ static int __devinit sdhci_s3c_probe(struct platform_device *pdev)
>  	if (pdata->host_caps2)
>  		host->mmc->caps2 |= pdata->host_caps2;
>  
> +	pm_runtime_enable(&pdev->dev);
> +	pm_runtime_set_autosuspend_delay(&pdev->dev, 50);

Could you explain why use 50ms? 

> +	pm_runtime_use_autosuspend(&pdev->dev);
> +	pm_suspend_ignore_children(&pdev->dev, 1);

Is there reason that ignore_children use to set the true?

> +
>  	ret = sdhci_add_host(host);
>  	if (ret) {
>  		dev_err(dev, "sdhci_add_host() failed\n");
> @@ -740,6 +746,8 @@ static int __devinit sdhci_s3c_probe(struct platform_device *pdev)
>  
>   err_add_host:
>  	release_resource(sc->ioarea);
> +	pm_runtime_forbid(&pdev->dev);
> +	pm_runtime_get_noresume(&pdev->dev);
>  	kfree(sc->ioarea);
>  
>   err_req_regs:
> @@ -784,6 +792,8 @@ static int __devexit sdhci_s3c_remove(struct platform_device *pdev)
>  
>  	sdhci_remove_host(host, 1);
>  
> +	pm_runtime_disable(&pdev->dev);
> +
>  	for (ptr = 0; ptr < 3; ptr++) {
>  		if (sc->clk_bus[ptr]) {
>  			clk_disable(sc->clk_bus[ptr]);
> @@ -824,9 +834,27 @@ static int sdhci_s3c_resume(struct device *dev)
>  }
>  #endif
>  
> +#ifdef CONFIG_PM_RUNTIME
> +static int sdhci_s3c_runtime_suspend(struct device *dev)
> +{
> +	struct sdhci_host *host = dev_get_drvdata(dev);
> +
> +	return sdhci_runtime_suspend_host(host);
> +}
> +
> +static int sdhci_s3c_runtime_resume(struct device *dev)
> +{
> +	struct sdhci_host *host = dev_get_drvdata(dev);
> +
> +	return sdhci_runtime_resume_host(host);
> +}
> +#endif
> +
>  #ifdef CONFIG_PM
>  static const struct dev_pm_ops sdhci_s3c_pmops = {
>  	SET_SYSTEM_SLEEP_PM_OPS(sdhci_s3c_suspend, sdhci_s3c_resume)
> +	SET_RUNTIME_PM_OPS(sdhci_s3c_runtime_suspend, sdhci_s3c_runtime_resume,
> +			   NULL)
>  };
>  
>  #define SDHCI_S3C_PMOPS (&sdhci_s3c_pmops)
Mark Brown - March 5, 2012, 11:52 a.m.
On Mon, Mar 05, 2012 at 07:48:42PM +0900, Jaehoon Chung wrote:
> On 03/03/2012 09:46 AM, Mark Brown wrote:

> > +	pm_runtime_set_autosuspend_delay(&pdev->dev, 50);

> Could you explain why use 50ms? 

It's essentially a random number, some other devices use the same one.
We're just trying to avoid suspending between back to back requests.

> > +	pm_runtime_use_autosuspend(&pdev->dev);
> > +	pm_suspend_ignore_children(&pdev->dev, 1);

> Is there reason that ignore_children use to set the true?

So that we can suspend the host without having to have the MMC card
suspended (the host suspend is not visible to the card).
Jaehoon Chung - March 6, 2012, 6:40 a.m.
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
 
On 03/05/2012 08:52 PM, Mark Brown wrote:

> On Mon, Mar 05, 2012 at 07:48:42PM +0900, Jaehoon Chung wrote:
>> On 03/03/2012 09:46 AM, Mark Brown wrote:
> 
>>> +	pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
> 
>> Could you explain why use 50ms? 
> 
> It's essentially a random number, some other devices use the same one.
> We're just trying to avoid suspending between back to back requests.
> 
>>> +	pm_runtime_use_autosuspend(&pdev->dev);
>>> +	pm_suspend_ignore_children(&pdev->dev, 1);
> 
>> Is there reason that ignore_children use to set the true?
> 
> So that we can suspend the host without having to have the MMC card
> suspended (the host suspend is not visible to the card).
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Chris Ball - March 9, 2012, 4:56 a.m.
Hi Mark,

On Fri, Mar 02 2012, Mark Brown wrote:
> This matches current best practice as one can have runtime PM enabled
> without system sleep and CONFIG_PM is defined for both.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
>  drivers/mmc/host/sdhci-s3c.c |    9 +++++----
>  1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index ea0767e..46152d6 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -22,6 +22,7 @@
>  #include <linux/module.h>
>  #include <linux/of.h>
>  #include <linux/of_gpio.h>
> +#include <linux/pm.h>
>  
>  #include <linux/mmc/host.h>
>  
> @@ -807,8 +808,7 @@ static int __devexit sdhci_s3c_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> -#ifdef CONFIG_PM
> -
> +#ifdef CONFIG_PM_SLEEP
>  static int sdhci_s3c_suspend(struct device *dev)
>  {
>  	struct sdhci_host *host = dev_get_drvdata(dev);
> @@ -822,10 +822,11 @@ static int sdhci_s3c_resume(struct device *dev)
>  
>  	return sdhci_resume_host(host);
>  }
> +#endif
>  
> +#ifdef CONFIG_PM
>  static const struct dev_pm_ops sdhci_s3c_pmops = {
> -	.suspend	= sdhci_s3c_suspend,
> -	.resume		= sdhci_s3c_resume,
> +	SET_SYSTEM_SLEEP_PM_OPS(sdhci_s3c_suspend, sdhci_s3c_resume)
>  };
>  
>  #define SDHCI_S3C_PMOPS (&sdhci_s3c_pmops)

Thanks, pushed to mmc-next for 3.4 with Jaehoon's ACK.

- Chris.
Chris Ball - March 9, 2012, 4:57 a.m.
Hi Mark,

On Fri, Mar 02 2012, Mark Brown wrote:
> Since most of the work is already done by the core we just need to add
> runtime suspend methods and tell the PM core that runtime PM is enabled
> for this device.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
>  drivers/mmc/host/sdhci-s3c.c |   28 ++++++++++++++++++++++++++++
>  1 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 46152d6..6926ac9 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -23,6 +23,7 @@
>  #include <linux/of.h>
>  #include <linux/of_gpio.h>
>  #include <linux/pm.h>
> +#include <linux/pm_runtime.h>
>  
>  #include <linux/mmc/host.h>
>  
> @@ -721,6 +722,11 @@ static int __devinit sdhci_s3c_probe(struct platform_device *pdev)
>  	if (pdata->host_caps2)
>  		host->mmc->caps2 |= pdata->host_caps2;
>  
> +	pm_runtime_enable(&pdev->dev);
> +	pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
> +	pm_runtime_use_autosuspend(&pdev->dev);
> +	pm_suspend_ignore_children(&pdev->dev, 1);
> +
>  	ret = sdhci_add_host(host);
>  	if (ret) {
>  		dev_err(dev, "sdhci_add_host() failed\n");
> @@ -740,6 +746,8 @@ static int __devinit sdhci_s3c_probe(struct platform_device *pdev)
>  
>   err_add_host:
>  	release_resource(sc->ioarea);
> +	pm_runtime_forbid(&pdev->dev);
> +	pm_runtime_get_noresume(&pdev->dev);
>  	kfree(sc->ioarea);
>  
>   err_req_regs:
> @@ -784,6 +792,8 @@ static int __devexit sdhci_s3c_remove(struct platform_device *pdev)
>  
>  	sdhci_remove_host(host, 1);
>  
> +	pm_runtime_disable(&pdev->dev);
> +
>  	for (ptr = 0; ptr < 3; ptr++) {
>  		if (sc->clk_bus[ptr]) {
>  			clk_disable(sc->clk_bus[ptr]);
> @@ -824,9 +834,27 @@ static int sdhci_s3c_resume(struct device *dev)
>  }
>  #endif
>  
> +#ifdef CONFIG_PM_RUNTIME
> +static int sdhci_s3c_runtime_suspend(struct device *dev)
> +{
> +	struct sdhci_host *host = dev_get_drvdata(dev);
> +
> +	return sdhci_runtime_suspend_host(host);
> +}
> +
> +static int sdhci_s3c_runtime_resume(struct device *dev)
> +{
> +	struct sdhci_host *host = dev_get_drvdata(dev);
> +
> +	return sdhci_runtime_resume_host(host);
> +}
> +#endif
> +
>  #ifdef CONFIG_PM
>  static const struct dev_pm_ops sdhci_s3c_pmops = {
>  	SET_SYSTEM_SLEEP_PM_OPS(sdhci_s3c_suspend, sdhci_s3c_resume)
> +	SET_RUNTIME_PM_OPS(sdhci_s3c_runtime_suspend, sdhci_s3c_runtime_resume,
> +			   NULL)
>  };
>  
>  #define SDHCI_S3C_PMOPS (&sdhci_s3c_pmops)

Thanks, pushed to mmc-next for 3.4 with Jaehoon's ACK.

- Chris.
Mark Brown - March 9, 2012, 12:26 p.m.
On Fri, Mar 09, 2012 at 12:08:58AM -0500, Chris Ball wrote:

> The reworked patch is below, please let me know if it looks incorrect:

That looks about right, I'll find out soon enough if it doesn't work in
-next as my main development system has the rootfs on this device :)
Chris Ball - March 27, 2012, 3:50 p.m.
Hi Kukjin,

On Tue, Feb 21 2012, Chris Ball wrote:
> On Tue, Feb 21 2012, Kukjin Kim wrote:
>> I created topic branch for this we talked. You can pull that following:
>>   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v3.4-for-cjb
>>
>> If any problems, please kindly let me know.
>
> Pushed to mmc-next, thanks.  (I'm expecting that you'll do the merge
> to Linus.)

I was expecting you to merge these patches, but they aren't in the
arm-soc tree and haven't been sent to Linus, and we're in the last few
days of the merge window.

As a result I'm dropping this tree -- and all of the patches that I
have on top of it -- from mmc-next so that I can get a pull request
out.  This means that I'm dropping:

mmc: sdhci-s3c: Add device tree support
mmc: sdhci-s3c: Keep a copy of platform data and use it
mmc: sdhci-s3c: derive transfer width host capability from max_width in 
ARM: SAMSUNG: remove all uses of clk_type member in sdhci platform data
ARM: EXYNOS: use 'exynos4-sdhci' as device name for sdhci controllers
mmc: sdhci-s3c: Remove usage of clk_type member in platform data

.. which I was expecting you to merge, and also:

mmc: sdhci-s3c: fix broken compilation for non-Exynos SoCs
mmc: sdhci-s3c: Enable runtime power management
mmc: sdhci-s3c: Use CONFIG_PM_SLEEP to ifdef system suspend
mmc: sdhci-s3c: use devm_ functions

.. which were merged on top of the above patches.

We'll have to try again with 3.5 for the new features, and post-rc1 for
the fixes.  Please let me know what happened with this merge.  Thanks,

- Chris.
Mark Brown - March 28, 2012, 9:54 a.m.
On Tue, Mar 27, 2012 at 11:50:24AM -0400, Chris Ball wrote:
> On Tue, Feb 21 2012, Chris Ball wrote:
> > On Tue, Feb 21 2012, Kukjin Kim wrote:

> >> I created topic branch for this we talked. You can pull that following:
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> >> v3.4-for-cjb

> >> If any problems, please kindly let me know.

> > Pushed to mmc-next, thanks.  (I'm expecting that you'll do the merge
> > to Linus.)

> I was expecting you to merge these patches, but they aren't in the
> arm-soc tree and haven't been sent to Linus, and we're in the last few
> days of the merge window.

> As a result I'm dropping this tree -- and all of the patches that I
> have on top of it -- from mmc-next so that I can get a pull request
> out.  This means that I'm dropping:

If they're already in your tree why not just send them to Linus?  Given
that everything's in git I don't understand why you'd need Kukjin to
push them separately or what the benefit of that would be?

This is all extremely frustrating fromm the contributor point of view.
Kukjin Kim - March 29, 2012, 3:15 a.m.
On 03/28/12 02:54, Mark Brown wrote:
> On Tue, Mar 27, 2012 at 11:50:24AM -0400, Chris Ball wrote:
>> On Tue, Feb 21 2012, Chris Ball wrote:
>>> On Tue, Feb 21 2012, Kukjin Kim wrote:
>
>>>> I created topic branch for this we talked. You can pull that following:
>>>>    git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>> v3.4-for-cjb
>
>>>> If any problems, please kindly let me know.
>
>>> Pushed to mmc-next, thanks.  (I'm expecting that you'll do the merge
>>> to Linus.)
>
>> I was expecting you to merge these patches, but they aren't in the
>> arm-soc tree and haven't been sent to Linus,

(Cc'ed Olof and Arnd)

Chris, Yeah, it is not in arm-soc tree now. Because I sent a pull 
request of samsung-mmc which is including this v3.4-for-cjb but Olof 
wanted to merge only arch/arm/ part for samsung mmc because they are not 
unrelated to the branch, v3.4-for-cjb sent to you. Since I thought the 
branch would be sent to upstream via your tree and you were included in 
the mailing loop, I agreed. So there is no it in arm-soc.

>> and we're in the last few
>> days of the merge window.
>
Yeah...it means not closed yet ;)

>> As a result I'm dropping this tree -- and all of the patches that I
>> have on top of it -- from mmc-next so that I can get a pull request
>> out.  This means that I'm dropping:
>
Hmm, I think, if you're ok, you can send a second pull request to Linus 
for it and actually, it is in linux-next for a long time via mmc and 
samsung tree.

Note, please don't rebase it because its resolution for conflicts is in 
linux-next and I think Linus will use it when happens conflicts...Or I 
can provide new tree on top of latest mainline. But I'm not sure about 
latter.

> If they're already in your tree why not just send them to Linus?  Given
> that everything's in git I don't understand why you'd need Kukjin to
> push them separately or what the benefit of that would be?
>
Yes, I already agreed its merging in the mmc tree :)

> This is all extremely frustrating fromm the contributor point of view.

If any my effort is required, feel free to contact me.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
Chris Ball - April 1, 2012, 1:12 a.m.
Hi Kukjin,

On Wed, Mar 28 2012, Kukjin Kim wrote:
>>> As a result I'm dropping this tree -- and all of the patches that I
>>> have on top of it -- from mmc-next so that I can get a pull request
>>> out.  This means that I'm dropping:
>>
> Hmm, I think, if you're ok, you can send a second pull request to
> Linus for it and actually, it is in linux-next for a long time via mmc
> and samsung tree.
>
> Note, please don't rebase it because its resolution for conflicts is
> in linux-next and I think Linus will use it when happens
> conflicts...Or I can provide new tree on top of latest mainline. But
> I'm not sure about latter.

I can't send the tree as it is to Linus now, because Arnd has asked us
to hold off on these device tree bindings and work with the unified
bindings he's proposing instead.  (Rebasing to drop that patch will
introduce new conflicts.)

I'm going to send Mark Brown's two patches to Linus now, even though it
will cause a conflict in -next.  The rest (other than the device tree
bindings) are mergable after -rc1, because they're fixes, so we'll
eventually get everything except DT in to 3.4.  I think you should
just drop this patchset from your tree in linux-next entirely now.

Thanks,

- Chris.
Kukjin Kim - April 2, 2012, 7:08 p.m.
Chris Ball wrote:
> Hi Kukjin,
>
Hi,

Sorry for late response.

[...]

>
> I can't send the tree as it is to Linus now, because Arnd has asked us
> to hold off on these device tree bindings and work with the unified
> bindings he's proposing instead.  (Rebasing to drop that patch will
> introduce new conflicts.)
>
OK, I see.

> I'm going to send Mark Brown's two patches to Linus now, even though it
> will cause a conflict in -next.  The rest (other than the device tree
> bindings) are mergable after -rc1, because they're fixes, so we'll
> eventually get everything except DT in to 3.4.  I think you should
> just drop this patchset from your tree in linux-next entirely now.
>
Yep, I dropped it in my -next.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.