[PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD

[PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD

[Philip Rakity]

[PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD

[Arnd Bergmann]

On Wednesday 22 December 2010 08:09:58 Philip Rakity wrote:
> The PXA168, PXA910, and MMP2 are not the same SOC.  The family
> of embedded processors have slightly different internal blocks
> for SD, I2C, etc.  Sometimes it is important to know which SOC
> is being used due to differences in the silicon.  Sometimes it
> is important to know evaluation boards should be selected based
> on the SOC on the board.

This looks like you're moving in the wrong direction.

If the chips are just slightly different, you'd certainly
want to make sure that you can detect the difference at runtime,
and be able to use the same kernel on all of the variants.

Instead, you promote each of the SOCs to a top-level family
in this patch, which makes it impossible to build a kernel
for more than one of them at a time.

	Arnd

[PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD

[Philip Rakity]

On Dec 22, 2010, at 6:10 AM, Arnd Bergmann wrote:

> On Wednesday 22 December 2010 08:09:58 Philip Rakity wrote:
>> The PXA168, PXA910, and MMP2 are not the same SOC.  The family
>> of embedded processors have slightly different internal blocks
>> for SD, I2C, etc.  Sometimes it is important to know which SOC
>> is being used due to differences in the silicon.  Sometimes it
>> is important to know evaluation boards should be selected based
>> on the SOC on the board.
> 
> This looks like you're moving in the wrong direction.
> 
> If the chips are just slightly different, you'd certainly
> want to make sure that you can detect the difference at runtime,
> and be able to use the same kernel on all of the variants.

MMP2 used PJ4 core --- PXA168/PXA910 use PJ1 so rather different architecture.

PXA168/PXA910 have slightly different internal peripherals with different quirks.
Certainly possible to tell this apart at runtime but not all peripherals are the same
and startup files ARE different.


> 
> Instead, you promote each of the SOCs to a top-level family
> in this patch, which makes it impossible to build a kernel
> for more than one of them at a time.

That was the intent to handle the case of development board selection.
it is meaningless to select MMP2 development board with say PXA168 SoC.

Open to other way to handle this problem.  Suggestions welcome.

> 
> 	Arnd

[PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD

[Haojian Zhuang]

On Thu, Dec 23, 2010 at 6:58 AM, Philip Rakity <prakity@marvell.com> wrote:
>
> On Dec 22, 2010, at 6:10 AM, Arnd Bergmann wrote:
>
>> On Wednesday 22 December 2010 08:09:58 Philip Rakity wrote:
>>> The PXA168, PXA910, and MMP2 are not the same SOC. ?The family
>>> of embedded processors have slightly different internal blocks
>>> for SD, I2C, etc. ?Sometimes it is important to know which SOC
>>> is being used due to differences in the silicon. ?Sometimes it
>>> is important to know evaluation boards should be selected based
>>> on the SOC on the board.
>>
>> This looks like you're moving in the wrong direction.
>>
>> If the chips are just slightly different, you'd certainly
>> want to make sure that you can detect the difference at runtime,
>> and be able to use the same kernel on all of the variants.
>
> MMP2 used PJ4 core --- PXA168/PXA910 use PJ1 so rather different architecture.
>
> PXA168/PXA910 have slightly different internal peripherals with different quirks.
> Certainly possible to tell this apart at runtime but not all peripherals are the same
> and startup files ARE different.
>
>
MMP2 and PJ4 are different SoC silicons. But they're using similar SD
IP, so we can share same driver to them. Different quirks can be
handled by different flags in run time.

There's no reason to copy driver for each silicon.

>>
>> Instead, you promote each of the SOCs to a top-level family
>> in this patch, which makes it impossible to build a kernel
>> for more than one of them at a time.
>
> That was the intent to handle the case of development board selection.
> it is meaningless to select MMP2 development board with say PXA168 SoC.
>
> Open to other way to handle this problem. ?Suggestions welcome.
>
Again, you did wrong. You couldn't make patch for top-level family. It
will introduce a lot of error to maintainers.

Your patches will make them mess.

Thanks
Haojian

>>
>> ? ? ? Arnd
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

[PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD

[Philip Rakity]

On Dec 30, 2010, at 9:46 PM, Haojian Zhuang wrote:

> On Thu, Dec 23, 2010 at 6:58 AM, Philip Rakity <prakity@marvell.com> wrote:
>> 
>> On Dec 22, 2010, at 6:10 AM, Arnd Bergmann wrote:
>> 
>>> On Wednesday 22 December 2010 08:09:58 Philip Rakity wrote:
>>>> The PXA168, PXA910, and MMP2 are not the same SOC.  The family
>>>> of embedded processors have slightly different internal blocks
>>>> for SD, I2C, etc.  Sometimes it is important to know which SOC
>>>> is being used due to differences in the silicon.  Sometimes it
>>>> is important to know evaluation boards should be selected based
>>>> on the SOC on the board.
>>> 
>>> This looks like you're moving in the wrong direction.
>>> 
>>> If the chips are just slightly different, you'd certainly
>>> want to make sure that you can detect the difference at runtime,
>>> and be able to use the same kernel on all of the variants.
>> 
>> MMP2 used PJ4 core --- PXA168/PXA910 use PJ1 so rather different architecture.
>> 
>> PXA168/PXA910 have slightly different internal peripherals with different quirks.
>> Certainly possible to tell this apart at runtime but not all peripherals are the same
>> and startup files ARE different.
>> 
>> 
> MMP2 and PJ4 are different SoC silicons. But they're using similar SD
> IP, so we can share same driver to them. Different quirks can be
> handled by different flags in run time.
> 

The SD IP is not the same.  One uses SD controller 3.0 and the other is 2.0.

They are the same in the sense that they public registers adhere to the appropriate SD spec 2.0/3.0 but
these accesses are handled by sdhci.c.  (SD 3.0 extends the SD 2.0 spec by adding new registers and adding some bit definitions
in a compatible manner inside the public space).  

The private registers that need to be programmed are not extensions but are at different locations and bit fields do not have exactly the same meaning.

The code to handle the differences is rather small and is not NOT placed in arch/arm/ directory but rather in the
drivers/mmc/host directory and follows the conventions to handle this. 


> There's no reason to copy driver for each silicon

> 
>>> 
>>> Instead, you promote each of the SOCs to a top-level family
>>> in this patch, which makes it impossible to build a kernel
>>> for more than one of them at a time.
>> 
>> That was the intent to handle the case of development board selection.
>> it is meaningless to select MMP2 development board with say PXA168 SoC.
>> 
>> Open to other way to handle this problem.  Suggestions welcome.
>> 
> Again, you did wrong. You couldn't make patch for top-level family. It
> will introduce a lot of error to maintainers.

The patch selects ARCH-MMP (as now) but adds the ability
to also know which specific SoC was chosen.  (This is sort of done by choosing the development board today).


> 
> Your patches will make them mess.

suggest a solution.  

The current mechanism of having the development board select the CPU does not seem right.
One can select a development board for MMP2 and PXA168 and yet the arch files to support each CPU
are different and not compatible.  (for example cache handling).  

> 
> Thanks
> Haojian
> 
>>> 
>>>       Arnd
>> 
>> 
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> 

[PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD

[Haojian Zhuang]

On Fri, Dec 31, 2010 at 2:03 PM, Philip Rakity <prakity@marvell.com> wrote:
>
> On Dec 30, 2010, at 9:46 PM, Haojian Zhuang wrote:
>
>> On Thu, Dec 23, 2010 at 6:58 AM, Philip Rakity <prakity@marvell.com> wrote:
>>>
>>> On Dec 22, 2010, at 6:10 AM, Arnd Bergmann wrote:
>>>
>>>> On Wednesday 22 December 2010 08:09:58 Philip Rakity wrote:
>>>>> The PXA168, PXA910, and MMP2 are not the same SOC. ?The family
>>>>> of embedded processors have slightly different internal blocks
>>>>> for SD, I2C, etc. ?Sometimes it is important to know which SOC
>>>>> is being used due to differences in the silicon. ?Sometimes it
>>>>> is important to know evaluation boards should be selected based
>>>>> on the SOC on the board.
>>>>
>>>> This looks like you're moving in the wrong direction.
>>>>
>>>> If the chips are just slightly different, you'd certainly
>>>> want to make sure that you can detect the difference at runtime,
>>>> and be able to use the same kernel on all of the variants.
>>>
>>> MMP2 used PJ4 core --- PXA168/PXA910 use PJ1 so rather different architecture.
>>>
>>> PXA168/PXA910 have slightly different internal peripherals with different quirks.
>>> Certainly possible to tell this apart at runtime but not all peripherals are the same
>>> and startup files ARE different.
>>>
>>>
>> MMP2 and PJ4 are different SoC silicons. But they're using similar SD
>> IP, so we can share same driver to them. Different quirks can be
>> handled by different flags in run time.
>>
>
> The SD IP is not the same. ?One uses SD controller 3.0 and the other is 2.0.
>
> They are the same in the sense that they public registers adhere to the appropriate SD spec 2.0/3.0 but
> these accesses are handled by sdhci.c. ?(SD 3.0 extends the SD 2.0 spec by adding new registers and adding some bit definitions
> in a compatible manner inside the public space).
>
Yes, you confirmed that they're same in the sense. It's enough. User
needn't care whether it's SD2.0 or SD3.0. It's the business of silicon
engineer.

> The private registers that need to be programmed are not extensions but are at different locations and bit fields do not have exactly the same meaning.
>
> The code to handle the differences is rather small and is not NOT placed in arch/arm/ directory but rather in the
> drivers/mmc/host directory and follows the conventions to handle this.
>
In your patch, you divide them into silicon depedant files. I think
that putting them into arch/arm is better.

>
>> There's no reason to copy driver for each silicon
>
>>
>>>>
>>>> Instead, you promote each of the SOCs to a top-level family
>>>> in this patch, which makes it impossible to build a kernel
>>>> for more than one of them at a time.
>>>
>>> That was the intent to handle the case of development board selection.
>>> it is meaningless to select MMP2 development board with say PXA168 SoC.
>>>
>>> Open to other way to handle this problem. ?Suggestions welcome.
>>>
>> Again, you did wrong. You couldn't make patch for top-level family. It
>> will introduce a lot of error to maintainers.
>
> The patch selects ARCH-MMP (as now) but adds the ability
> to also know which specific SoC was chosen. ?(This is sort of done by choosing the development board today).
>
If you want to change mmc code, push it into mmc tree. If you want to
change pxa code, push it into pxa tree. If they're dependant, please
make sure the sequence is right.
>
>>
>> Your patches will make them mess.
>
> suggest a solution.
>
> The current mechanism of having the development board select the CPU does not seem right.
> One can select a development board for MMP2 and PXA168 and yet the arch files to support each CPU
> are different and not compatible. ?(for example cache handling).
>
Only one SoC can be installed on one board. If silicons are
pin-compatible to one board, we can register different boards. For
example, we can divide saarb as saarb_pv and saarb_mg.

If MMP2 and PXA168 are both installed on one board, it means that you
must run two kernel images on two APs. Actually, I don't think anyone
will design system like this way. If so, why not adopt the above
policy? You can divide the board into two sub-board on naming policy.
>>
>> Thanks
>> Haojian
>>
>>>>
>>>> ? ? ? Arnd
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>
>

[PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD

[Mark Brown]

On Dec 31, 2010, at 1:46 AM, Haojian Zhuang wrote:

> On Fri, Dec 31, 2010 at 2:03 PM, Philip Rakity <prakity@marvell.com> wrote:
>> 
>> On Dec 30, 2010, at 9:46 PM, Haojian Zhuang wrote:
>> 
>>> On Thu, Dec 23, 2010 at 6:58 AM, Philip Rakity <prakity@marvell.com> wrote:
>>>> 
>>>> On Dec 22, 2010, at 6:10 AM, Arnd Bergmann wrote:
>>>> 
>>>>> On Wednesday 22 December 2010 08:09:58 Philip Rakity wrote:
>>>>>> The PXA168, PXA910, and MMP2 are not the same SOC.  The family
>>>>>> of embedded processors have slightly different internal blocks
>>>>>> for SD, I2C, etc.  Sometimes it is important to know which SOC
>>>>>> is being used due to differences in the silicon.  Sometimes it
>>>>>> is important to know evaluation boards should be selected based
>>>>>> on the SOC on the board.
>>>>> 
>>>>> This looks like you're moving in the wrong direction.
>>>>> 
>>>>> If the chips are just slightly different, you'd certainly
>>>>> want to make sure that you can detect the difference at runtime,
>>>>> and be able to use the same kernel on all of the variants.
>>>> 
>>>> MMP2 used PJ4 core --- PXA168/PXA910 use PJ1 so rather different architecture.
>>>> 
>>>> PXA168/PXA910 have slightly different internal peripherals with different quirks.
>>>> Certainly possible to tell this apart at runtime but not all peripherals are the same
>>>> and startup files ARE different.
>>>> 
>>>> 
>>> MMP2 and PJ4 are different SoC silicons. But they're using similar SD

I think you meant MMP2 and PJ1 there. MMP2 is a PJ4 core.

>>> IP, so we can share same driver to them. Different quirks can be
>>> handled by different flags in run time.

Technically all of these SDHCI controllers are extremely similar. The point of the SDHCI-* family of drivers
are there to specify the implementation differences.

sdhci-pxa codebase is currently minimal it performs two operations:
1. Register sdhci instance using platform data.
2. Define common quirks.
3. Provides clock control callback 

The PXA168/PXA910 (PJ1) versions would have specific needs:
1. There is a difference in clock control and power up sequencing
2. There is a specific I/O accessor needed to access registers
3. There are workarounds for SDIO that are needed.
4. There specific quirks needed for the PXA168/PXA910.

Even if we were to write a separate driver for PXA168/910 and MMP2 there would be no code duplication except for
the code to interpret the platform data.

In Philip's code he took the duplication into account and further abstracted it so that the platform data interpretation is done in 
sdhci-pxa.c and the differences are exposed in the sdhci-pxa168 and sdhci-mmp2 modules.

There is already precedence for this already in sdhci-of-* implementation.

I am not sure why people think combining all of these differences into one massive sdhci-pxa driver would make maintenance simpler when the 
relevant commonality is already abstracted away in sdhci.c.
 
>>> 
>> 
>> The SD IP is not the same.  One uses SD controller 3.0 and the other is 2.0.
>> 
>> They are the same in the sense that they public registers adhere to the appropriate SD spec 2.0/3.0 but
>> these accesses are handled by sdhci.c.  (SD 3.0 extends the SD 2.0 spec by adding new registers and adding some bit definitions
>> in a compatible manner inside the public space).
>> 
> Yes, you confirmed that they're same in the sense. It's enough. User
> needn't care whether it's SD2.0 or SD3.0. It's the business of silicon
> engineer.
> 
>> The private registers that need to be programmed are not extensions but are at different locations and bit fields do not have exactly the same meaning.
>> 
>> The code to handle the differences is rather small and is not NOT placed in arch/arm/ directory but rather in the
>> drivers/mmc/host directory and follows the conventions to handle this.
>> 
> In your patch, you divide them into silicon depedant files. I think
> that putting them into arch/arm is better.
> 
>> 
>>> There's no reason to copy driver for each silicon
>> 
>>> 
>>>>> 
>>>>> Instead, you promote each of the SOCs to a top-level family
>>>>> in this patch, which makes it impossible to build a kernel
>>>>> for more than one of them at a time.
>>>> 
>>>> That was the intent to handle the case of development board selection.
>>>> it is meaningless to select MMP2 development board with say PXA168 SoC.
>>>> 
>>>> Open to other way to handle this problem.  Suggestions welcome.
>>>> 
>>> Again, you did wrong. You couldn't make patch for top-level family. It
>>> will introduce a lot of error to maintainers.
>> 
>> The patch selects ARCH-MMP (as now) but adds the ability
>> to also know which specific SoC was chosen.  (This is sort of done by choosing the development board today).
>> 
> If you want to change mmc code, push it into mmc tree. If you want to
> change pxa code, push it into pxa tree. If they're dependant, please
> make sure the sequence is right.
>> 
>>> 
>>> Your patches will make them mess.
>> 
>> suggest a solution.
>> 
>> The current mechanism of having the development board select the CPU does not seem right.
>> One can select a development board for MMP2 and PXA168 and yet the arch files to support each CPU
>> are different and not compatible.  (for example cache handling).
>> 
> Only one SoC can be installed on one board. If silicons are
> pin-compatible to one board, we can register different boards. For
> example, we can divide saarb as saarb_pv and saarb_mg.
> 
> If MMP2 and PXA168 are both installed on one board, it means that you
> must run two kernel images on two APs. Actually, I don't think anyone
> will design system like this way. If so, why not adopt the above
> policy? You can divide the board into two sub-board on naming policy.
>>> 
>>> Thanks
>>> Haojian
>>> 
>>>>> 
>>>>>       Arnd
>>>> 
>>>> 
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>> 
>> 
>> 

[PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD

[zhangfei gao]

On Fri, Dec 31, 2010 at 5:08 PM, Mark Brown <markb@marvell.com> wrote:
> On Dec 31, 2010, at 1:46 AM, Haojian Zhuang wrote:
>
>> On Fri, Dec 31, 2010 at 2:03 PM, Philip Rakity <prakity@marvell.com> wrote:
>>>
>>> On Dec 30, 2010, at 9:46 PM, Haojian Zhuang wrote:
>>>
>>>> On Thu, Dec 23, 2010 at 6:58 AM, Philip Rakity <prakity@marvell.com> wrote:
>>>>>
>>>>> On Dec 22, 2010, at 6:10 AM, Arnd Bergmann wrote:
>>>>>
>>>>>> On Wednesday 22 December 2010 08:09:58 Philip Rakity wrote:
>>>>>>> The PXA168, PXA910, and MMP2 are not the same SOC. ?The family
>>>>>>> of embedded processors have slightly different internal blocks
>>>>>>> for SD, I2C, etc. ?Sometimes it is important to know which SOC
>>>>>>> is being used due to differences in the silicon. ?Sometimes it
>>>>>>> is important to know evaluation boards should be selected based
>>>>>>> on the SOC on the board.
>>>>>>
>>>>>> This looks like you're moving in the wrong direction.
>>>>>>
>>>>>> If the chips are just slightly different, you'd certainly
>>>>>> want to make sure that you can detect the difference at runtime,
>>>>>> and be able to use the same kernel on all of the variants.
>>>>>
>>>>> MMP2 used PJ4 core --- PXA168/PXA910 use PJ1 so rather different architecture.
>>>>>
>>>>> PXA168/PXA910 have slightly different internal peripherals with different quirks.
>>>>> Certainly possible to tell this apart at runtime but not all peripherals are the same
>>>>> and startup files ARE different.
>>>>>
>>>>>
>>>> MMP2 and PJ4 are different SoC silicons. But they're using similar SD
>
> I think you meant MMP2 and PJ1 there. MMP2 is a PJ4 core.
>
>>>> IP, so we can share same driver to them. Different quirks can be
>>>> handled by different flags in run time.
>
> Technically all of these SDHCI controllers are extremely similar. The point of the SDHCI-* family of drivers
> are there to specify the implementation differences.
>
> sdhci-pxa codebase is currently minimal it performs two operations:
> 1. Register sdhci instance using platform data.
> 2. Define common quirks.
> 3. Provides clock control callback
>
> The PXA168/PXA910 (PJ1) versions would have specific needs:
> 1. There is a difference in clock control and power up sequencing
> 2. There is a specific I/O accessor needed to access registers
> 3. There are workarounds for SDIO that are needed.
> 4. There specific quirks needed for the PXA168/PXA910.

For mmp2 and pxa910, they are same ip in fact, same silicon bug, and
same workaround, and fixed together in updated version.
That's the reason they worked well in currently code base with same
quirk, same driver.
pxa168 may be different since no future stepping.

It is true, one is v2, the other is v3, but this is handled in sdhci.c
and transparent for specific driver.
The only difference is different private register, that may because
when define v2 and can not foresee v3 definition.
Still not find strong reason to add more specific driver only handle
different private register, if so more driver will be added for mmp2x,
for example, though same ip are used.

BTW, brownstone with mmc support is already added if work based on
pxa-linux-2.6.git, devel branch.

>
> Even if we were to write a separate driver for PXA168/910 and MMP2 there would be no code duplication except for
> the code to interpret the platform data.
>
> In Philip's code he took the duplication into account and further abstracted it so that the platform data interpretation is done in
> sdhci-pxa.c and the differences are exposed in the sdhci-pxa168 and sdhci-mmp2 modules.
>
> There is already precedence for this already in sdhci-of-* implementation.
>
> I am not sure why people think combining all of these differences into one massive sdhci-pxa driver would make maintenance simpler when the
> relevant commonality is already abstracted away in sdhci.c.
>
>>>>
>>>
>>> The SD IP is not the same. ?One uses SD controller 3.0 and the other is 2.0.
>>>
>>> They are the same in the sense that they public registers adhere to the appropriate SD spec 2.0/3.0 but
>>> these accesses are handled by sdhci.c. ?(SD 3.0 extends the SD 2.0 spec by adding new registers and adding some bit definitions
>>> in a compatible manner inside the public space).
>>>
>> Yes, you confirmed that they're same in the sense. It's enough. User
>> needn't care whether it's SD2.0 or SD3.0. It's the business of silicon
>> engineer.
>>
>>> The private registers that need to be programmed are not extensions but are at different locations and bit fields do not have exactly the same meaning.
>>>
>>> The code to handle the differences is rather small and is not NOT placed in arch/arm/ directory but rather in the
>>> drivers/mmc/host directory and follows the conventions to handle this.
>>>
>> In your patch, you divide them into silicon depedant files. I think
>> that putting them into arch/arm is better.
>>
>>>
>>>> There's no reason to copy driver for each silicon
>>>
>>>>
>>>>>>
>>>>>> Instead, you promote each of the SOCs to a top-level family
>>>>>> in this patch, which makes it impossible to build a kernel
>>>>>> for more than one of them at a time.
>>>>>
>>>>> That was the intent to handle the case of development board selection.
>>>>> it is meaningless to select MMP2 development board with say PXA168 SoC.
>>>>>
>>>>> Open to other way to handle this problem. ?Suggestions welcome.
>>>>>
>>>> Again, you did wrong. You couldn't make patch for top-level family. It
>>>> will introduce a lot of error to maintainers.
>>>
>>> The patch selects ARCH-MMP (as now) but adds the ability
>>> to also know which specific SoC was chosen. ?(This is sort of done by choosing the development board today).
>>>
>> If you want to change mmc code, push it into mmc tree. If you want to
>> change pxa code, push it into pxa tree. If they're dependant, please
>> make sure the sequence is right.
>>>
>>>>
>>>> Your patches will make them mess.
>>>
>>> suggest a solution.
>>>
>>> The current mechanism of having the development board select the CPU does not seem right.
>>> One can select a development board for MMP2 and PXA168 and yet the arch files to support each CPU
>>> are different and not compatible. ?(for example cache handling).
>>>
>> Only one SoC can be installed on one board. If silicons are
>> pin-compatible to one board, we can register different boards. For
>> example, we can divide saarb as saarb_pv and saarb_mg.
>>
>> If MMP2 and PXA168 are both installed on one board, it means that you
>> must run two kernel images on two APs. Actually, I don't think anyone
>> will design system like this way. If so, why not adopt the above
>> policy? You can divide the board into two sub-board on naming policy.
>>>>
>>>> Thanks
>>>> Haojian
>>>>
>>>>>>
>>>>>> ? ? ? Arnd
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> linux-arm-kernel mailing list
>>>>> linux-arm-kernel at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>>>
>>>
>>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>

[PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD

[Arnd Bergmann]

On Friday 31 December 2010, Philip Rakity wrote:
> The patch selects ARCH-MMP (as now) but adds the ability
> to also know which specific SoC was chosen.  (This is sort of done by choosing the development board today).

On a larger scale, we try to go in the opposite direction: make it possible to
have kernels run on as many boards as possible by decreasing the code differences
between SoCs and even SoC families.
 
> > Your patches will make them mess.
> 
> suggest a solution.  
> 
> The current mechanism of having the development board select the CPU does not seem right.
> One can select a development board for MMP2 and PXA168 and yet the arch files to support each CPU
> are different and not compatible.  (for example cache handling).  

The optimal solution would be to make sure that working support for both CPUs can be built into
a single kernel. There is a lot of infrastructure in arch/arm/mm/* that tries to do this, but
I don't know of that actually works for the combination of CPU_MOHAWK and CPU_V6. It does
work for some other combinations of CPU cores though, so it's certainly possible.
For instance, arch/arm/include/asm/cacheflush.h has abstractions to select the cache handling
at boot time.

To go even further, it might make sense to combine the PXA and MMP platforms, since they already
share some code through the plat-pxa directory.

Getting it running for MMP with mohawk and v6 cores could be a significant amount of work if
nobody has tries this in that platform, so for now, I would recommend you just keep ARCH_MMP as
a global option in arch/arm/Kconfig for now and add another 'choice' statement in
arch/arm/mach-mmp/Kconfig to select the CPU core, with the board selection depending on that.

	Arnd

[PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD

[Philip Rakity]

On Jan 6, 2011, at 11:29 AM, Arnd Bergmann wrote:

> On Friday 31 December 2010, Philip Rakity wrote:
>> The patch selects ARCH-MMP (as now) but adds the ability
>> to also know which specific SoC was chosen.  (This is sort of done by choosing the development board today).
> 
> On a larger scale, we try to go in the opposite direction: make it possible to
> have kernels run on as many boards as possible by decreasing the code differences
> between SoCs and even SoC families.
> 
>>> Your patches will make them mess.
>> 
>> suggest a solution.  
>> 
>> The current mechanism of having the development board select the CPU does not seem right.
>> One can select a development board for MMP2 and PXA168 and yet the arch files to support each CPU
>> are different and not compatible.  (for example cache handling).  
> 
> The optimal solution would be to make sure that working support for both CPUs can be built into
> a single kernel. There is a lot of infrastructure in arch/arm/mm/* that tries to do this, but
> I don't know of that actually works for the combination of CPU_MOHAWK and CPU_V6. It does
> work for some other combinations of CPU cores though, so it's certainly possible.
> For instance, arch/arm/include/asm/cacheflush.h has abstractions to select the cache handling
> at boot time.
> 
> To go even further, it might make sense to combine the PXA and MMP platforms, since they already
> share some code through the plat-pxa directory.
> 
> Getting it running for MMP with mohawk and v6 cores could be a significant amount of work if
> nobody has tries this in that platform, so for now, I would recommend you just keep ARCH_MMP as
> a global option in arch/arm/Kconfig for now and add another 'choice' statement in
> arch/arm/mach-mmp/Kconfig to select the CPU core, with the board selection depending on that.
> 


Thanks for the suggestion.  Let me see if I can implement this.  

A couple of points first

a) current implementation once PXA168/910 is selected will no longer show MMP2 boards so it is also broken.  Play around and you will see the issues

My proposed patch did the following
a) ARCH_MMP is set when PXA168, PXA910 or MMP2 are selected (from arch/arm)
b) Board selection uses the PXA168/PXA910/MMP2 to show correct board.

If I understand what you are suggesting is the following
a) leave ARCH_MMP is system selection alone -- 
b) move speciific CPU selection to where board selection is now (cpu/arch/mach-mmp)
c) what do with development boards ?  select all of them for the CPU Type ?  

Point me to a Kconfig that does what you are suggesting as an example and I can try out the suggestion.


> 	Arnd
> 

[PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD

[Arnd Bergmann]

On Friday 07 January 2011, Philip Rakity wrote:
> Thanks for the suggestion.  Let me see if I can implement this.  
> 
> A couple of points first
> 
> a) current implementation once PXA168/910 is selected will no longer show MMP2 boards so it is also broken.  Play around and you will see the issues

I didn't see it on the version I'm looking at now, but if it's inconsistent or
allows you to select combinationst that cannot be built, then it should be fixed.

> My proposed patch did the following
> a) ARCH_MMP is set when PXA168, PXA910 or MMP2 are selected (from arch/arm)
> b) Board selection uses the PXA168/PXA910/MMP2 to show correct board.

Yes, that is what I thought, but it is inconsistent with how other platforms do this.
Usually, the top-level selection chooses one source directory, and anything specific
to that platform is handled by that Kconfig.

> If I understand what you are suggesting is the following
> a) leave ARCH_MMP is system selection alone -- 
> b) move speciific CPU selection to where board selection is now (cpu/arch/mach-mmp)

Right.

> c) what do with development boards ?  select all of them for the CPU Type ?  
>
> Point me to a Kconfig that does what you are suggesting as an example and I can try out the suggestion.

Just put it below the CPU selection.

OMAP does something like this -- you first select either OMAP1 or OMAP2/3/4, then
the families in the latter case, and finally the boards.

You can do the same by first giving the choice between ARMv6 and PXA168/910, and
then showing the boards below the CPU. There are multiple ways of doing this
that lead to the same result.

	Arnd

[PATCH 1/2] mach-mmp: MMP2 Drive Strength FAST using wrong value

[Philip Rakity]

Drive strength for MMP2 is a 2 bit value but because of the mapping in
plat-pxa/mfp.h needs to be shifted up one bit to handle real
location in mfp registers.  (MMP2 and PXA910 drive strength start
at bit 11 while PXA168 starts at bit 10).

Values 0, 1, 2, and 3 effectively need to be
0, 2, 4, and 6 to fit into register.  8 does not work.

Signed-off-by: Philip Rakity <prakity@marvell.com>
Tested-by: John Watlington <wad@laptop.org>
---
 arch/arm/mach-mmp/include/mach/mfp-mmp2.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-mmp/include/mach/mfp-mmp2.h b/arch/arm/mach-mmp/include/mach/mfp-mmp2.h
index 117e303..4ad3862 100644
--- a/arch/arm/mach-mmp/include/mach/mfp-mmp2.h
+++ b/arch/arm/mach-mmp/include/mach/mfp-mmp2.h
@@ -6,7 +6,7 @@
 #define MFP_DRIVE_VERY_SLOW	(0x0 << 13)
 #define MFP_DRIVE_SLOW		(0x2 << 13)
 #define MFP_DRIVE_MEDIUM	(0x4 << 13)
-#define MFP_DRIVE_FAST		(0x8 << 13)
+#define MFP_DRIVE_FAST		(0x6 << 13)
 
 /* GPIO */
 #define GPIO0_GPIO	MFP_CFG(GPIO0, AF0)
-- 
1.7.0.4

[PATCH 2/2] mach-mmp: PXA910 Drive Strength FAST using wrong value

[Philip Rakity]

Drive strength for PXA910 is a 2 bit value but because of the mapping in
plat-pxa/mfp.h needs to be shifted up one bit to handle real
location in mfp registers.  (MMP2 and PXA910 drive strength start
at bit 11 while PXA168 starts at bit 10).

Values 0, 1, 2, and 3 effectively need to be
0, 2, 4, and 6 to fit into register.  8 does not work.

Signed-off-by: Philip Rakity <prakity@marvell.com>
---
 arch/arm/mach-mmp/include/mach/mfp-pxa910.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-mmp/include/mach/mfp-pxa910.h b/arch/arm/mach-mmp/include/mach/mfp-pxa910.h
index 7e8a80f..fbd7ee8 100644
--- a/arch/arm/mach-mmp/include/mach/mfp-pxa910.h
+++ b/arch/arm/mach-mmp/include/mach/mfp-pxa910.h
@@ -6,7 +6,7 @@
 #define MFP_DRIVE_VERY_SLOW	(0x0 << 13)
 #define MFP_DRIVE_SLOW		(0x2 << 13)
 #define MFP_DRIVE_MEDIUM	(0x4 << 13)
-#define MFP_DRIVE_FAST		(0x8 << 13)
+#define MFP_DRIVE_FAST		(0x6 << 13)
 
 /* UART2 */
 #define GPIO47_UART2_RXD	MFP_CFG(GPIO47, AF6)
-- 
1.7.0.4

[PATCH] mach-mmp: Fix Kconfig to allow correct PXA Selections

[Philip Rakity]

The following items are fixed:

a) inconsistent behavior when board is selected and if
menu item is reselected board has disappeard

b) Ability to select options that will not build
	MMP2 and say PXA168

The behavior maps what is done by the mach-omap
(thanks to Anrd Bergmann for his help and suggestions)

Mach-MMP is (as now) the sytem type.  Once selected
the user can then select the SoC on the board and
only the boards that support that SoC are shown.

Signed-off-by: Philip Rakity <prakity@marvell.com>
---
 arch/arm/mach-mmp/Kconfig |   96 ++++++++++++++++++++++-----------------------
 1 files changed, 47 insertions(+), 49 deletions(-)

diff --git a/arch/arm/mach-mmp/Kconfig b/arch/arm/mach-mmp/Kconfig
index 67793a6..4739d27 100644
--- a/arch/arm/mach-mmp/Kconfig
+++ b/arch/arm/mach-mmp/Kconfig
@@ -1,99 +1,97 @@
 if ARCH_MMP
 
-menu "Marvell PXA168/910/MMP2 Implmentations"
+menu "Marvell PXA168/PXA910/MMP2 Specific Features"
+
+choice
+	prompt "SoC (System on Chip)"
+	help
+	  Type of System on Chip (SoC) used
+
+config CPU_PXA168
+	bool "PXA168 Based System"
+	select CPU_MOHAWK
+	help
+	  Say 'Y' here if System has a Marvell PXA168 SoC
+
+config CPU_PXA910
+	bool "PXA910 Based System"
+	select CPU_MOHAWK
+	help
+	  Say 'Y' here if System has a Marvell PXA910 SoC
+
+config CPU_MMP2
+	bool "MMP2 Based System"
+	select CPU_PJ4
+	help
+	  Say 'Y' here if System has a Marvell MMP2 SoC
+
+endchoice
+
+comment "Development Board"
 
 config MACH_ASPENITE
 	bool "Marvell's PXA168 Aspenite Development Board"
-	select CPU_PXA168
+	depends on CPU_PXA168
 	help
 	  Say 'Y' here if you want to support the Marvell PXA168-based
 	  Aspenite Development Board.
 
 config MACH_ZYLONITE2
 	bool "Marvell's PXA168 Zylonite2 Development Board"
-	select CPU_PXA168
+	depends on CPU_PXA168
 	help
 	  Say 'Y' here if you want to support the Marvell PXA168-based
 	  Zylonite2 Development Board.
 
 config MACH_AVENGERS_LITE
 	bool "Marvell's PXA168 Avengers Lite Development Board"
-	select CPU_PXA168
+	depends on CPU_PXA168
 	help
 	  Say 'Y' here if you want to support the Marvell PXA168-based
 	  Avengers Lite Development Board.
 
+config MACH_TETON_BGA
+	bool "Marvell's PXA168 Teton BGA Development Board"
+	depends on CPU_PXA168
+	help
+	  Say 'Y' here if you want to support the Marvell PXA168-based
+	  Teton BGA Development Board.
+
 config MACH_TAVOREVB
 	bool "Marvell's PXA910 TavorEVB Development Board"
-	select CPU_PXA910
+	depends on CPU_PXA910
 	help
 	  Say 'Y' here if you want to support the Marvell PXA910-based
 	  TavorEVB Development Board.
 
 config MACH_TTC_DKB
-	bool "Marvell's PXA910 TavorEVB Development Board"
-	select CPU_PXA910
+	bool "Marvell's PXA910 TTC DKB Development Board"
+	depends on CPU_PXA910
 	help
 	  Say 'Y' here if you want to support the Marvell PXA910-based
 	  TTC_DKB Development Board.
 
 config MACH_BROWNSTONE
 	bool "Marvell's Brownstone Development Platform"
-	depends on !CPU_MOHAWK
-	select CPU_MMP2
+	depends on CPU_MMP2
 	help
 	  Say 'Y' here if you want to support the Marvell MMP2-based
-	  Brown Development Platform.
-	  MMP2-based board can't be co-existed with PXA168-based &
-	  PXA910-based development board. Since MMP2 is compatible to
-	  ARMv7 architecture.
+	  Brownstone Development Board.
 
 config MACH_FLINT
 	bool "Marvell's Flint Development Platform"
-	depends on !CPU_MOHAWK
-	select CPU_MMP2
+	depends on CPU_MMP2
 	help
 	  Say 'Y' here if you want to support the Marvell MMP2-based
-	  Flint Development Platform.
-	  MMP2-based board can't be co-existed with PXA168-based &
-	  PXA910-based development board. Since MMP2 is compatible to
-	  ARMv7 architecture.
+	  Flint Development Board.
 
 config MACH_MARVELL_JASPER
 	bool "Marvell's Jasper Development Platform"
-	depends on !CPU_MOHAWK
-	select CPU_MMP2
+	depends on CPU_MMP2
 	help
 	  Say 'Y' here if you want to support the Marvell MMP2-base
-	  Jasper Development Platform.
-	  MMP2-based board can't be co-existed with PXA168-based &
-	  PXA910-based development board. Since MMP2 is compatible to
-	  ARMv7 architecture.
-
-config MACH_TETON_BGA
-	bool "Marvell's PXA168 Teton BGA Development Board"
-	select CPU_PXA168
-	help
-	  Say 'Y' here if you want to support the Marvell PXA168-based
-	  Teton BGA Development Board.
+	  Jasper Development Board.
 
 endmenu
 
-config CPU_PXA168
-	bool
-	select CPU_MOHAWK
-	help
-	  Select code specific to PXA168
-
-config CPU_PXA910
-	bool
-	select CPU_MOHAWK
-	help
-	  Select code specific to PXA910
-
-config CPU_MMP2
-	bool
-	select CPU_PJ4
-	help
-	  Select code specific to MMP2. MMP2 is ARMv7 compatible.
 endif
-- 
1.7.0.4

[PATCH 2/2] mach-mmp: PXA910 Drive Strength FAST using wrong value

[Eric Miao]

On Fri, Jan 7, 2011 at 1:27 PM, Philip Rakity <prakity@marvell.com> wrote:
>
> Drive strength for PXA910 is a 2 bit value but because of the mapping in
> plat-pxa/mfp.h needs to be shifted up one bit to handle real
> location in mfp registers. ?(MMP2 and PXA910 drive strength start
> at bit 11 while PXA168 starts at bit 10).
>
> Values 0, 1, 2, and 3 effectively need to be
> 0, 2, 4, and 6 to fit into register. ?8 does not work.
>
> Signed-off-by: Philip Rakity <prakity@marvell.com>

Applied.

> ---
> ?arch/arm/mach-mmp/include/mach/mfp-pxa910.h | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-mmp/include/mach/mfp-pxa910.h b/arch/arm/mach-mmp/include/mach/mfp-pxa910.h
> index 7e8a80f..fbd7ee8 100644
> --- a/arch/arm/mach-mmp/include/mach/mfp-pxa910.h
> +++ b/arch/arm/mach-mmp/include/mach/mfp-pxa910.h
> @@ -6,7 +6,7 @@
> ?#define MFP_DRIVE_VERY_SLOW ? ?(0x0 << 13)
> ?#define MFP_DRIVE_SLOW ? ? ? ? (0x2 << 13)
> ?#define MFP_DRIVE_MEDIUM ? ? ? (0x4 << 13)
> -#define MFP_DRIVE_FAST ? ? ? ? (0x8 << 13)
> +#define MFP_DRIVE_FAST ? ? ? ? (0x6 << 13)
>
> ?/* UART2 */
> ?#define GPIO47_UART2_RXD ? ? ? MFP_CFG(GPIO47, AF6)
> --
> 1.7.0.4
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

[PATCH 1/2] mach-mmp: MMP2 Drive Strength FAST using wrong value

[Eric Miao]

On Fri, Jan 7, 2011 at 1:26 PM, Philip Rakity <prakity@marvell.com> wrote:
>
> Drive strength for MMP2 is a 2 bit value but because of the mapping in
> plat-pxa/mfp.h needs to be shifted up one bit to handle real
> location in mfp registers. ?(MMP2 and PXA910 drive strength start
> at bit 11 while PXA168 starts at bit 10).
>
> Values 0, 1, 2, and 3 effectively need to be
> 0, 2, 4, and 6 to fit into register. ?8 does not work.
>
> Signed-off-by: Philip Rakity <prakity@marvell.com>
> Tested-by: John Watlington <wad@laptop.org>

Applied.

> ---
> ?arch/arm/mach-mmp/include/mach/mfp-mmp2.h | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-mmp/include/mach/mfp-mmp2.h b/arch/arm/mach-mmp/include/mach/mfp-mmp2.h
> index 117e303..4ad3862 100644
> --- a/arch/arm/mach-mmp/include/mach/mfp-mmp2.h
> +++ b/arch/arm/mach-mmp/include/mach/mfp-mmp2.h
> @@ -6,7 +6,7 @@
> ?#define MFP_DRIVE_VERY_SLOW ? ?(0x0 << 13)
> ?#define MFP_DRIVE_SLOW ? ? ? ? (0x2 << 13)
> ?#define MFP_DRIVE_MEDIUM ? ? ? (0x4 << 13)
> -#define MFP_DRIVE_FAST ? ? ? ? (0x8 << 13)
> +#define MFP_DRIVE_FAST ? ? ? ? (0x6 << 13)
>
> ?/* GPIO */
> ?#define GPIO0_GPIO ? ? MFP_CFG(GPIO0, AF0)
> --
> 1.7.0.4
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>