From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@deeprootsystems.com (Kevin Hilman) Date: Tue, 10 Aug 2010 07:29:26 -0700 Subject: [PATCH v3] davinci: Add MityDSP-L138/MityARM-1808 SOM support In-Reply-To: <4C5B1B6C.2040601@criticallink.com> (Michael Williamson's message of "Thu, 05 Aug 2010 16:13:32 -0400") References: <4C45AE5E.7070905@criticallink.com> <4C4D8449.9040706@criticallink.com> <87mxt0ubnr.fsf@deeprootsystems.com> <4C5B1378.7080400@criticallink.com> <4C5B1B6C.2040601@criticallink.com> Message-ID: <87r5i68rsp.fsf@deeprootsystems.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Michael Williamson writes: > On 8/5/2010 4:01 PM, Ben Gardiner wrote: > >> On Thu, Aug 5, 2010 at 3:39 PM, Michael Williamson >> wrote: >>> On 8/5/2010 3:01 PM, Kevin Hilman wrote: >>> >>>> Michael Williamson 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 >>>>>>> --- >>>>>> >>>>>> [...] >>>>>> >>>>>>> >>>>>>> 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 at 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