[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 at 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
>>