[PATCH v3] davinci: Add MityDSP-L138/MityARM-1808 SOM support
Kevin Hilman
khilman at deeprootsystems.com
Tue Aug 10 10:29:26 EDT 2010
Michael Williamson <michael.williamson at criticallink.com> writes:
> 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,
For the framebuffer, there are existing command-line options to be used
and/or expanded.
> multiple CS pin assignments as well as multiple McASP
> channel configurations. I'll look into it. Thanks.
I would advise using the ATAG_REVISION for basic setup, but consider
using/expanding the command-line options for specific drivers.
Kevin
More information about the linux-arm-kernel
mailing list