All of lore.kernel.org
 help / color / mirror / Atom feed
From: Subash Patel <subash.ramaswamy@linaro.org>
To: Kukjin Kim <kgene.kim@samsung.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>,
	Cho KyongHo <pullip.cho@samsung.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	'Younglak Kim' <younglak1004.kim@samsung.com>,
	'Kyungmin Park' <kyungmin.park@samsung.com>,
	'Sanghyun Lee' <sanghyun75.lee@samsung.com>
Subject: Re: [PATCH v12 2/3] ARM: EXYNOS: Change System MMU platform device definitions
Date: Fri, 16 Mar 2012 15:00:41 +0530	[thread overview]
Message-ID: <4F630841.2070307@linaro.org> (raw)
In-Reply-To: <4F61FF1D.5000502@samsung.com>

Hi KyongHo, Kukjin,

On 03/15/2012 08:09 PM, Kukjin Kim wrote:
> On 03/15/12 04:12, Joerg Roedel wrote:
>> On Thu, Mar 15, 2012 at 05:32:39PM +0900, Cho KyongHo wrote:
>
> KyongHo, I looked at 'Cho KyongHo <pullip.cho ...>' and 'KyongHo Cho 
> <pullip.cho ...>' in this series, which one do you want to use?
>
>>> Handling System MMUs with an identifier is not flexible to manage
>>> System MMU platform devices because of the following reasons:
>>> 1. A device driver which needs to handle System MMU must know the ID.
>>> 2. A System MMU may not present in some implementations of Exynos 
>>> family.
>>> 3. Handling System MMU with IOMMU API does not require an ID.
>>>
>>> This patch is the result of removing ID of System MMUs.
>>> Instead, a device driver that needs to handle its System MMU must
>>> use IOMMU API while its descriptor of platform device is given.
>>>
>>> This patch also includes the following enhancements:
>>> - A System MMU device becomes a child if its power domain device.
>>> - clkdev
>>>
>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>> Signed-off-by: KyongHo Cho<pullip.cho@samsung.com>
>>> ---
>>>   arch/arm/mach-exynos/Kconfig                    |   10 +-
>>>   arch/arm/mach-exynos/Makefile                   |    2 +-
>>>   arch/arm/mach-exynos/clock-exynos4.c            |   79 ++--
>>>   arch/arm/mach-exynos/clock-exynos4.h            |    2 +
>>>   arch/arm/mach-exynos/clock-exynos4210.c         |   11 +
>>>   arch/arm/mach-exynos/clock-exynos4212.c         |   28 ++-
>>>   arch/arm/mach-exynos/clock-exynos5.c            |   90 +++++
>>>   arch/arm/mach-exynos/dev-sysmmu.c               |  457 
>>> ++++++++++++----------
>>>   arch/arm/mach-exynos/include/mach/irqs.h        |   25 +-
>>>   arch/arm/mach-exynos/include/mach/map.h         |   38 ++
>>>   arch/arm/mach-exynos/include/mach/regs-clock.h  |    5 +
>>>   arch/arm/mach-exynos/include/mach/regs-sysmmu.h |   28 --
>>>   arch/arm/mach-exynos/include/mach/sysmmu.h      |   88 +++--
>>>   arch/arm/mach-exynos/mach-armlex4210.c          |    1 -
>>>   arch/arm/mach-exynos/mach-smdkv310.c            |    1 -
>>>   15 files changed, 529 insertions(+), 336 deletions(-)
>>>   delete mode 100644 arch/arm/mach-exynos/include/mach/regs-sysmmu.h
>>
>> This patch doesn't apply cleanly against upstream Linux (v3.3-rcX).
>> Please rebase to upstream and resend. The other 2 patches apply fine.
>>
>
> Yes, as KyoungHo said, this has been created on top of Samsung tree 
> for-next because this touches many exynos stuff which has been changed 
> from Samsung tree for upcoming merge window. So if you're ok on this, 
> 1st patch and this should be sent to upstream via samsung tree even 
> though I can't find any topic branch for this yet. And if you want 
> topic branch for your tree, let me know, I can provide it.
>
> Thanks.
Wouldn't it be good to send exynos4 SYSMMU patches now, and send only 
the exynos5 delta when your for-next(exynos5) changes
get merged to mainline? Manually editing the patches is really pain-some 
and sometimes error-some :( Can this patch in particular
be split?
>
> Best regards,
> Kgene.
> -- 
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
Regards,
Subash

WARNING: multiple messages have this Message-ID (diff)
From: subash.ramaswamy@linaro.org (Subash Patel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v12 2/3] ARM: EXYNOS: Change System MMU platform device definitions
Date: Fri, 16 Mar 2012 15:00:41 +0530	[thread overview]
Message-ID: <4F630841.2070307@linaro.org> (raw)
In-Reply-To: <4F61FF1D.5000502@samsung.com>

Hi KyongHo, Kukjin,

On 03/15/2012 08:09 PM, Kukjin Kim wrote:
> On 03/15/12 04:12, Joerg Roedel wrote:
>> On Thu, Mar 15, 2012 at 05:32:39PM +0900, Cho KyongHo wrote:
>
> KyongHo, I looked at 'Cho KyongHo <pullip.cho ...>' and 'KyongHo Cho 
> <pullip.cho ...>' in this series, which one do you want to use?
>
>>> Handling System MMUs with an identifier is not flexible to manage
>>> System MMU platform devices because of the following reasons:
>>> 1. A device driver which needs to handle System MMU must know the ID.
>>> 2. A System MMU may not present in some implementations of Exynos 
>>> family.
>>> 3. Handling System MMU with IOMMU API does not require an ID.
>>>
>>> This patch is the result of removing ID of System MMUs.
>>> Instead, a device driver that needs to handle its System MMU must
>>> use IOMMU API while its descriptor of platform device is given.
>>>
>>> This patch also includes the following enhancements:
>>> - A System MMU device becomes a child if its power domain device.
>>> - clkdev
>>>
>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>> Signed-off-by: KyongHo Cho<pullip.cho@samsung.com>
>>> ---
>>>   arch/arm/mach-exynos/Kconfig                    |   10 +-
>>>   arch/arm/mach-exynos/Makefile                   |    2 +-
>>>   arch/arm/mach-exynos/clock-exynos4.c            |   79 ++--
>>>   arch/arm/mach-exynos/clock-exynos4.h            |    2 +
>>>   arch/arm/mach-exynos/clock-exynos4210.c         |   11 +
>>>   arch/arm/mach-exynos/clock-exynos4212.c         |   28 ++-
>>>   arch/arm/mach-exynos/clock-exynos5.c            |   90 +++++
>>>   arch/arm/mach-exynos/dev-sysmmu.c               |  457 
>>> ++++++++++++----------
>>>   arch/arm/mach-exynos/include/mach/irqs.h        |   25 +-
>>>   arch/arm/mach-exynos/include/mach/map.h         |   38 ++
>>>   arch/arm/mach-exynos/include/mach/regs-clock.h  |    5 +
>>>   arch/arm/mach-exynos/include/mach/regs-sysmmu.h |   28 --
>>>   arch/arm/mach-exynos/include/mach/sysmmu.h      |   88 +++--
>>>   arch/arm/mach-exynos/mach-armlex4210.c          |    1 -
>>>   arch/arm/mach-exynos/mach-smdkv310.c            |    1 -
>>>   15 files changed, 529 insertions(+), 336 deletions(-)
>>>   delete mode 100644 arch/arm/mach-exynos/include/mach/regs-sysmmu.h
>>
>> This patch doesn't apply cleanly against upstream Linux (v3.3-rcX).
>> Please rebase to upstream and resend. The other 2 patches apply fine.
>>
>
> Yes, as KyoungHo said, this has been created on top of Samsung tree 
> for-next because this touches many exynos stuff which has been changed 
> from Samsung tree for upcoming merge window. So if you're ok on this, 
> 1st patch and this should be sent to upstream via samsung tree even 
> though I can't find any topic branch for this yet. And if you want 
> topic branch for your tree, let me know, I can provide it.
>
> Thanks.
Wouldn't it be good to send exynos4 SYSMMU patches now, and send only 
the exynos5 delta when your for-next(exynos5) changes
get merged to mainline? Manually editing the patches is really pain-some 
and sometimes error-some :( Can this patch in particular
be split?
>
> Best regards,
> Kgene.
> -- 
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
Regards,
Subash

  reply	other threads:[~2012-03-16  9:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-15  8:32 [PATCH v12 2/3] ARM: EXYNOS: Change System MMU platform device definitions Cho KyongHo
2012-03-15  8:32 ` Cho KyongHo
2012-03-15  8:32 ` Cho KyongHo
2012-03-15 11:12 ` Joerg Roedel
2012-03-15 11:12   ` Joerg Roedel
2012-03-15 11:12   ` Joerg Roedel
2012-03-15 14:39   ` Kukjin Kim
2012-03-15 14:39     ` Kukjin Kim
2012-03-16  9:30     ` Subash Patel [this message]
2012-03-16  9:30       ` Subash Patel
2012-03-16 20:47       ` Kukjin Kim
2012-03-16 20:47         ` Kukjin Kim
     [not found]         ` <4F63A6F6.9050506-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2012-03-18 13:27           ` Joerg Roedel
2012-03-18 13:27             ` Joerg Roedel
2012-03-18 13:27             ` Joerg Roedel
2012-03-29  1:23             ` Kukjin Kim
2012-03-29  1:23               ` Kukjin Kim
     [not found]               ` <4F73B9A3.30605-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2012-03-29  1:43                 ` KyongHo Cho
2012-03-29  1:43                   ` KyongHo Cho
2012-03-29  1:43                   ` KyongHo Cho
2012-04-10 19:34             ` Kukjin Kim
2012-04-10 19:34               ` Kukjin Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F630841.2070307@linaro.org \
    --to=subash.ramaswamy@linaro.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joerg.roedel@amd.com \
    --cc=kgene.kim@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=pullip.cho@samsung.com \
    --cc=sanghyun75.lee@samsung.com \
    --cc=younglak1004.kim@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.