[PATCH v3] davinci: Add MityDSP-L138/MityARM-1808 SOM support

[Michael Williamson]

 On 8/5/2010 4:01 PM, Ben Gardiner wrote:

> On Thu, Aug 5, 2010 at 3:39 PM, Michael Williamson
> <michael.williamson at criticallink.com> wrote:
>>  On 8/5/2010 3:01 PM, Kevin Hilman wrote:
>>
>>> Michael Williamson <michael.williamson at criticallink.com> writes:
>>>
>>>>  On 7/26/2010 5:29 AM, Nori, Sekhar wrote:
>>>>
>>>>>
>>>>> Hi Michael,
>>>>>
>>>>> On Tue, Jul 20, 2010 at 19:40:38, Michael Williamson wrote:
>>>>>>  This patch adds support for the MityDSP-L138 and MityARM-1808 system on
>>>>>> module (SOM) under the registered machine "mityomapl138".  These SOMs
>>>>>> are based on the da850 davinci CPU architecture.  Information on these
>>>>>> SOMs may be found at http://www.mitydsp.com.
>>>>>>
>>>>>> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
>>>>>> ---
>>>>>
>>>>> [...]
>>>>>
>>>>>>
>>>>>>  arch/arm/configs/da8xx_omapl_defconfig             |  291 ++++++--
>>>>>>  arch/arm/include/asm/setup.h                       |    5 +
>>>>>>  arch/arm/mach-davinci/Kconfig                      |    7 +
>>>>>>  arch/arm/mach-davinci/Makefile                     |    1 +
>>>>>>  arch/arm/mach-davinci/board-mityomapl138.c         |  793 ++++++++++++++++++++
>>>>>>  .../mach-davinci/include/mach/cb-mityomapl138.h    |  125 +++
>>>>>>  arch/arm/mach-davinci/include/mach/da8xx.h         |    1 +
>>>>>>  arch/arm/mach-davinci/include/mach/uncompress.h    |    1 +
>>>>>>  8 files changed, 1181 insertions(+), 43 deletions(-)
>>>>>>
>>>>>
>>>>> [...]
>>>>>
>>>>>> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
>>>>>> index f392fb4..d6b1a47 100644
>>>>>> --- a/arch/arm/include/asm/setup.h
>>>>>> +++ b/arch/arm/include/asm/setup.h
>>>>>> @@ -143,6 +143,11 @@ struct tag_memclk {
>>>>>>      __u32 fmemclk;
>>>>>>  };
>>>>>>
>>>>>> +/** MityDSP-L138 peripheral configuration info,
>>>>>> +  *  see arch/arm/mach-davinci/include/mach/cb-mityomapl138.h
>>>>>> +  */
>>>>>> +#define ATAG_PERIPHERALS 0x42000101
>>>>>
>>>>> Instead of naming this so generic, can you call this ATAG_MITYDSPL138 or
>>>>> something like that?
>>>>
>>>>
>>>>
>>>> Yes.  I would be glad to rename it, assuming some other approach is not
>>>> used instead.
>>>>
>>>>>
>>>>> Since passing peripheral configuration from bootloader is a first for
>>>>> DaVinci, can you please explain why this is the best suited method for this
>>>>> board and why methods used on other boards wont work?
>>>>>
>>>>
>>>>
>>>>
>>>> Well, the problem we are struggling with is that we'd like to avoid
>>>> generating a pile of separate machine types for the different boards
>>>> that are needed to support for this common SOM part with regards
>>>> to the peripheral selection.  There are already have 4 different
>>>> boards with slightly different peripherals already being used with this SOM,
>>>> and it's a challenge enough just to try to get one configuration through
>>>> this cycle (which I am new to).  We are expecting many more (10's per
>>>> year).
>>>>
>>>> In general, the only real difference on any of these boards will be in regards
>>>> to peripheral selection/configuration.  E.G., using RMII vs. MII, or using
>>>> different McASP pins or different numbers of channels, or adding a couple
>>>> of SPI devices on different chip selects, LCD settings, etc.
>>>> Seems like we shouldn't need to make a whole new machine up to support
>>>> these kinds of things.
>>>>
>>>> This came up in a thread on this mailing list, see
>>>>
>>>> http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg17042.html
>>>>
>>>> The approach here was pretty much what Kevin suggested as an alternate
>>>> to trying to port a flat device tree implementation like the powerpc
>>>> folks use.  The only difference was that I didn't think I could jam
>>>> everything I wanted onto the kernel command line without it getting out
>>>> of hand, so I am proposing a separate ATAG to provide the peripheral
>>>> configuration.  It's not perfect, but I wanted to get something out
>>>> there as if it's rejected then we only have a few boards to rewrite code
>>>> for.
>>>>
>>>> Other than device trees, the only other approaches I've seen so far to
>>>> sort out altering peripheral configuration is:
>>>>
>>>> a) Make a new board (a new board file, etc., KConfig option, etc.)
>>>>
>>>> b) Start in with a pile of #ifdefs, etc., and add a lot of peripheral
>>>> on/off options to the KConfig/Make system.  That means supporting
>>>> many variants of kernels for the different host boards, not
>>>> just an EVM.  I'd like to avoid that if I could, as the regression
>>>> testing for new options might get out of hand.  And it didn't seem
>>>> consistent with making a flexible kernel.
>>>>
>>>> c) Allow peripheral drivers to probe and initialize pins, etc. in the
>>>> modules, then load the right drivers up for your board.  There are a lot
>>>> of threads about why letting drivers mess with the pins is bad.  So this
>>>> is a non-starter.
>>>
>>> d) use ATAG_REVISION and a single board file
>>>
>>> There is currently a tag called ATAG_REVISION which sets a global
>>> variable 'system_rev' based on this tagq.  This tag was intended for
>>> exactly this purpose.
>>>
>>> You can then have a single machine type, a single board file and the
>>> boot loader can change ATAG_REVISION based on the board specifics.  The
>>> board file can then check 'system_rev' and handle specifics that way.
>>>
>>> This is also much clearer as all the things that are unique to that
>>> board will be contained in the board file and not hidden away in the
>>> bootloader.
>>
>>
>>
>> So, if for example, we have 3 boards that use this SOM, and they
>> vary by desired peripheral:
>>
>> Host Board 1 Peripherals = UARTS 0 and 1, SPI0 CS2, RMII, etc.
>> Host Board 2 Peripherals = UARTS 1 and 2, SPI1 CS1, MII, etc.
>> Host Board 3 Peripherals = UARTS 0, 1 and 2, SPI1 CS1, MII, etc.
>>
>> Then by this approach we would have:
>>
>> mityomapl138_init()
>> {
>>   /* Common NAND/NOR Init */
>>
>>   switch (system_rev) {
>>      case 1:
>>          /* setup uarts 0 & 1, SPI0 CS2, RMII */
>>      case 2:
>>          /* setup uarts 1 & 2, SPI1 CS1, MII */
>>      case 3:
>>      default:
>>          /* setup uarts 0 & 1 & 2, SPI1 CS1, MII */
>>          /* and so forth.... */
>>   }
>>
>>   /* Common Peripheral Init */
>> }
>>
>> Each time a new board is developed to use the SOM, you then grow the init
>> code accordingly?  I was hoping not to have to continuously drop patches
>> for new boards using this SOM.  I was really trying to have one binary
>> kernel that would be flexible enough to support the peripherals that
>> need to be handed to the device framework for any host board using this
>> SOM (properly configured via bootloader).  Is this not possible?
>
> Michael, could you pack the available peripherals into the bits of
> ATAG_REVISION?
>
> #define MIGHTYDSP_UART0 BIT(0)
> #define MIGHTYDSP_UART1 BIT(1)
> #define MIGHTYDSP_UART2 BIT(2)
> #define MIGHTYDSP_SPI1 BIT(3)
>
> mityomapl138_init()
> {
>   /* Common NAND/NOR Init */
>
>   if(system_rev & MIGHTYDSP_UART0) { /* setup uart0 */ }
>
>   if(system_rev & MIGHTYDSP_SPI1) { /*setup spi1*/ }
>
>   /* Common Peripheral Init */
> }
>
> Kevin, is that legal use of ATAG_REVISION?
>



It's unlikely.  There are strings to pass to the framebuffer device
for the da850, multiple CS pin assignments as well as multiple McASP
channel configurations.  I'll look into it. Thanks.

-Mike