diff mbox

powerpc/85xx: fix PHYS_64BIT selection for P1022DS

Message ID 1316806370-21067-1-git-send-email-agust@denx.de (mailing list archive)
State Accepted, archived
Delegated to: Kumar Gala
Headers show

Commit Message

Anatolij Gustschin Sept. 23, 2011, 7:32 p.m. UTC
Remove wrong CONFIG_ prefix in Kconfig file.

Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
 arch/powerpc/platforms/85xx/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Comments

Tabi Timur-B04825 Sept. 25, 2011, 5:06 p.m. UTC | #1
On Fri, Sep 23, 2011 at 2:32 PM, Anatolij Gustschin <agust@denx.de> wrote:

> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index 1b393f4..b29d4f2 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -80,7 +80,7 @@ config P1010_RDB
>  config P1022_DS
>        bool "Freescale P1022 DS"
>        select DEFAULT_UIMAGE
> -       select CONFIG_PHYS_64BIT        # The DTS has 36-bit addresses
> +       select PHYS_64BIT       # The DTS has 36-bit addresses

I have no idea how this happened, but I wonder if it's a good idea.
On the Freescale BSP, the default config for the P1022DS is 32-bit,
not 36-bit, so one day we might have a 32-bit config in the upstream
repository.

PHYS_64BIT is already covered by the defconfig.  I wonder if we should
just delete the bad line, and let the defconfig select the address
size.
Kumar Gala Sept. 26, 2011, 10:12 p.m. UTC | #2
On Sep 25, 2011, at 12:06 PM, Tabi Timur-B04825 wrote:

> On Fri, Sep 23, 2011 at 2:32 PM, Anatolij Gustschin <agust@denx.de> wrote:
> 
>> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
>> index 1b393f4..b29d4f2 100644
>> --- a/arch/powerpc/platforms/85xx/Kconfig
>> +++ b/arch/powerpc/platforms/85xx/Kconfig
>> @@ -80,7 +80,7 @@ config P1010_RDB
>>  config P1022_DS
>>        bool "Freescale P1022 DS"
>>        select DEFAULT_UIMAGE
>> -       select CONFIG_PHYS_64BIT        # The DTS has 36-bit addresses
>> +       select PHYS_64BIT       # The DTS has 36-bit addresses
> 
> I have no idea how this happened, but I wonder if it's a good idea.
> On the Freescale BSP, the default config for the P1022DS is 32-bit,
> not 36-bit, so one day we might have a 32-bit config in the upstream
> repository.
> 
> PHYS_64BIT is already covered by the defconfig.  I wonder if we should
> just delete the bad line, and let the defconfig select the address
> size.

Why, the way this patch makes it will work both with a 32-bit or 36-bit address map.   The comment should be fixed since its wrong.

- k
Timur Tabi Sept. 26, 2011, 10:14 p.m. UTC | #3
Kumar Gala wrote:
> Why, the way this patch makes it will work both with a 32-bit or 36-bit address map.   The comment should be fixed since its wrong.

I think the BSP team had said that there is a significant performance
improvement in some benchmark when 36-bit support is disabled.  That's why they
like to keep 32-bit and 36-bit environments for both, and why they default to
32-bit.
Scott Wood Sept. 26, 2011, 10:24 p.m. UTC | #4
On 09/26/2011 05:12 PM, Kumar Gala wrote:
> 
> On Sep 25, 2011, at 12:06 PM, Tabi Timur-B04825 wrote:
> 
>> On Fri, Sep 23, 2011 at 2:32 PM, Anatolij Gustschin <agust@denx.de> wrote:
>>
>>> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
>>> index 1b393f4..b29d4f2 100644
>>> --- a/arch/powerpc/platforms/85xx/Kconfig
>>> +++ b/arch/powerpc/platforms/85xx/Kconfig
>>> @@ -80,7 +80,7 @@ config P1010_RDB
>>>  config P1022_DS
>>>        bool "Freescale P1022 DS"
>>>        select DEFAULT_UIMAGE
>>> -       select CONFIG_PHYS_64BIT        # The DTS has 36-bit addresses
>>> +       select PHYS_64BIT       # The DTS has 36-bit addresses
>>
>> I have no idea how this happened, but I wonder if it's a good idea.
>> On the Freescale BSP, the default config for the P1022DS is 32-bit,
>> not 36-bit, so one day we might have a 32-bit config in the upstream
>> repository.
>>
>> PHYS_64BIT is already covered by the defconfig.  I wonder if we should
>> just delete the bad line, and let the defconfig select the address
>> size.
> 
> Why, the way this patch makes it will work both with a 32-bit or 36-bit address map.   The comment should be fixed since its wrong.

"select" should not be used for things that you think make good
defaults.  It should be used for things that are required.  It's just
like "depends on", except for user interface considerations (and the
whole transitive dependency mess).

-Scott
Kumar Gala Oct. 12, 2011, 4:53 a.m. UTC | #5
On Sep 23, 2011, at 2:32 PM, Anatolij Gustschin wrote:

> Remove wrong CONFIG_ prefix in Kconfig file.
> 
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ---
> arch/powerpc/platforms/85xx/Kconfig |    2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)

applied

- k
Tabi Timur-B04825 Oct. 13, 2011, 2:14 p.m. UTC | #6
On Tue, Oct 11, 2011 at 11:53 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Sep 23, 2011, at 2:32 PM, Anatolij Gustschin wrote:
>
>> Remove wrong CONFIG_ prefix in Kconfig file.
>>
>> Signed-off-by: Anatolij Gustschin <agust@denx.de>
>> ---
>> arch/powerpc/platforms/85xx/Kconfig |    2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> applied

Why did you apply this patch?  Both Scott and I rejected it.
Kumar Gala Oct. 13, 2011, 3:31 p.m. UTC | #7
On Oct 13, 2011, at 9:14 AM, Tabi Timur-B04825 wrote:

> On Tue, Oct 11, 2011 at 11:53 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>> 
>> On Sep 23, 2011, at 2:32 PM, Anatolij Gustschin wrote:
>> 
>>> Remove wrong CONFIG_ prefix in Kconfig file.
>>> 
>>> Signed-off-by: Anatolij Gustschin <agust@denx.de>
>>> ---
>>> arch/powerpc/platforms/85xx/Kconfig |    2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>> 
>> applied
> 
> Why did you apply this patch?  Both Scott and I rejected it.

Because its fixing a real issue.  If we want to remove PHYS_64BIT support or make it optional for the board feel free to send another patch.

- k
Timur Tabi Oct. 13, 2011, 3:35 p.m. UTC | #8
Kumar Gala wrote:
>> > Why did you apply this patch?  Both Scott and I rejected it.

> Because its fixing a real issue.  If we want to remove PHYS_64BIT support or make it optional for the board feel free to send another patch.

Ok, so if someone posts a patch that works but does things the wrong way, and
that patch gets rejected during reviews, but the submitter doesn't post a
follow-up patch that does things the right way, you're going to apply the first
patch anyway?

What about the BSP team's contention that enabling 64-bit support in the kernel
can drop performance by up to 25% in some situations?  We talked about that on
an internal mailing list several months ago.
Kumar Gala Oct. 13, 2011, 3:41 p.m. UTC | #9
On Oct 13, 2011, at 10:35 AM, Timur Tabi wrote:

> Kumar Gala wrote:
>>>> Why did you apply this patch?  Both Scott and I rejected it.
> 
>> Because its fixing a real issue.  If we want to remove PHYS_64BIT support or make it optional for the board feel free to send another patch.
> 
> Ok, so if someone posts a patch that works but does things the wrong way, and
> that patch gets rejected during reviews, but the submitter doesn't post a
> follow-up patch that does things the right way, you're going to apply the first
> patch anyway?

Leaving the code 'broken' I consider worse than slightly improving the situation which the patch does.  The original patch for this board port introduced it with CONFIG_PHYS_64BIT set, thus I think it reasonable to take a patch that fixed an issue w/o anyone else putting out a patch.

If you really don't want it selected by default send me a patch to remove it and I'll apply.  That is far more productive than this discussion.

> What about the BSP team's contention that enabling 64-bit support in the kernel
> can drop performance by up to 25% in some situations?  We talked about that on
> an internal mailing list several months ago.

I think this 25% number is bogus.  There are cases where it also improves performance.

- k
Timur Tabi Oct. 13, 2011, 3:45 p.m. UTC | #10
Kumar Gala wrote:
> I think this 25% number is bogus.  There are cases where it also improves performance.

I don't think we ever ship a P1022 system with more than 2GB of DDR, so I can't
see how performance is ever improved.

I will post a patch that removes the Kconfig option, but I don't understand why
you couldn't do that when you applied the patch.
Anatolij Gustschin Oct. 13, 2011, 3:50 p.m. UTC | #11
On Thu, 13 Oct 2011 10:35:04 -0500
Timur Tabi <timur@freescale.com> wrote:

> Kumar Gala wrote:
> >> > Why did you apply this patch?  Both Scott and I rejected it.
> 
> > Because its fixing a real issue.  If we want to remove PHYS_64BIT support or make it optional for the board feel free to send another patch.
> 
> Ok, so if someone posts a patch that works but does things the wrong way, and
> that patch gets rejected during reviews, but the submitter doesn't post a
> follow-up patch that does things the right way, you're going to apply the first
> patch anyway?

there is no 32bit address map DTS file for P1022DS in the mainline
tree. A proper patch should then also add appropriate 32bit address
map DTS file. I'm not in the position to do it currently since it would
require testing, I do not have this board to test patches for it.

Anatolij
Anatolij Gustschin Oct. 13, 2011, 3:52 p.m. UTC | #12
On Thu, 13 Oct 2011 10:45:04 -0500
Timur Tabi <timur@freescale.com> wrote:

> Kumar Gala wrote:
> > I think this 25% number is bogus.  There are cases where it also improves performance.
> 
> I don't think we ever ship a P1022 system with more than 2GB of DDR, so I can't
> see how performance is ever improved.
> 
> I will post a patch that removes the Kconfig option, but I don't understand why
> you couldn't do that when you applied the patch.

please also post a patch providing a working 32bit address
map DTS for this board, then.

Anatolij
Timur Tabi Oct. 13, 2011, 3:59 p.m. UTC | #13
Anatolij Gustschin wrote:
> there is no 32bit address map DTS file for P1022DS in the mainline
> tree. A proper patch should then also add appropriate 32bit address
> map DTS file. I'm not in the position to do it currently since it would
> require testing, I do not have this board to test patches for it.

The defconfig already enables CONFIG_PHYS_64BIT for the P1022DS and all other
85xx parts.  If you look at the Kconfig, you'll see that most boards don't
enable it.  So by default, everything is 64-bit capable.

Adding the Kconfig option will *prevent* anyone from creating a 32-bit kernel.
This is my problem with the patch.
diff mbox

Patch

diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 1b393f4..b29d4f2 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -80,7 +80,7 @@  config P1010_RDB
 config P1022_DS
 	bool "Freescale P1022 DS"
 	select DEFAULT_UIMAGE
-	select CONFIG_PHYS_64BIT	# The DTS has 36-bit addresses
+	select PHYS_64BIT	# The DTS has 36-bit addresses
 	select SWIOTLB
 	help
 	  This option enables support for the Freescale P1022DS reference board.