@@ -80,7 +80,7 @@ config P1010_RDBconfigP1022_DSbool"Freescale P1022 DS"selectDEFAULT_UIMAGE-selectCONFIG_PHYS_64BIT# The DTS has 36-bit addresses+selectPHYS_64BIT# The DTS has 36-bit addressesselectSWIOTLBhelpThisoptionenablessupportfortheFreescaleP1022DSreferenceboard.
+ =A0 =A0 =A0 select PHYS_64BIT =A0 =A0 =A0 # The DTS has 36-bit addresse=
s
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.
--=20
Timur Tabi
Linux kernel developer at Freescale=
@@ -80,7 +80,7 @@ config P1010_RDBconfigP1022_DSbool"Freescale P1022 DS"selectDEFAULT_UIMAGE-selectCONFIG_PHYS_64BIT# The DTS has 36-bit =
addresses
quoted
+ select PHYS_64BIT # The DTS has 36-bit addresses
=20
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.
=20
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=
From: Timur Tabi <hidden> Date: 2011-09-26 22:15:51
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.
--
Timur Tabi
Linux kernel developer at Freescale
@@ -80,7 +80,7 @@ config P1010_RDBconfigP1022_DSbool"Freescale P1022 DS"selectDEFAULT_UIMAGE-selectCONFIG_PHYS_64BIT# The DTS has 36-bit addresses+selectPHYS_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
From: Timur Tabi <hidden> Date: 2011-10-13 15:35:18
Kumar Gala wrote:
quoted
quoted
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.
--
Timur Tabi
Linux kernel developer at Freescale
From: Kumar Gala <hidden> Date: 2011-10-13 15:42:03
On Oct 13, 2011, at 10:35 AM, Timur Tabi wrote:
Kumar Gala wrote:
quoted
quoted
quoted
Why did you apply this patch? Both Scott and I rejected it.
=20
quoted
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.
=20
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=
From: Timur Tabi <hidden> Date: 2011-10-13 15:45:19
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.
--
Timur Tabi
Linux kernel developer at Freescale
On Thu, 13 Oct 2011 10:35:04 -0500
Timur Tabi [off-list ref] wrote:
Kumar Gala wrote:
quoted
quoted
quoted
Why did you apply this patch? Both Scott and I rejected it.
quoted
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
On Thu, 13 Oct 2011 10:45:04 -0500
Timur Tabi [off-list ref] wrote:
Kumar Gala wrote:
quoted
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
From: Timur Tabi <hidden> Date: 2011-10-13 15:59:24
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.
--
Timur Tabi
Linux kernel developer at Freescale