Mike Williamson <michael.william...@criticallink.com> writes: > On Wed, Mar 17, 2010 at 8:17 AM, Steve Chen <sc...@mvista.com> wrote: >> On Fri, Mar 12, 2010 at 7:06 PM, Mike Williamson >> <michael.william...@criticallink.com> wrote: >>> >>> >>> On Fri, Mar 12, 2010 at 5:18 PM, Kevin Hilman <khil...@deeprootsystems.com> >>> wrote: >>>> >>>> "Nori, Sekhar" <nsek...@ti.com> writes: >>>> >>>> > On Thu, Mar 11, 2010 at 11:45:47, Jon Povey wrote: >>>> >> Steve Chen wrote: >>>> >> > On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey >>>> >> > <jon.po...@racelogic.co.uk> wrote: >>>> >> >>>> >> >> We have 3 different boards using DM355, with different gpio / pinmux >>>> >> >> setups. So far, our device drivers are modules which fiddle the >>>> >> >> pinmux registers directly. >>>> >> >>>> >> >> At the moment I am thinking that I might want to split up >>>> >> >> davinci_cfg_reg into two functions so it's not hardwired to >>>> >> >> soc_info->pinmux_pins, and I could pass my own mux_config structs >>>> >> >> in. If this is of interest I can have a go at doing this and >>>> >> >> submitting the patch here. >>>> >> > >>>> >> > For board specific pinmux, you can put them in board-dm355-*.c. >>>> >> > There are some board specific pinmux setup in board-da830-evm.c. >>>> >> > Look for da8xx_pinmux_setup. >>>> >> >>>> >> Thanks, I see this. I have also been looking at the gpiolib support and >>>> >> something like that would be useful. >>>> >> >>>> >> At minimum it would be helpful to split out the davinci_cfg_reg stuff >>>> >> as >>>> >> described above so that driver modules can use the same functions. >>>> > >>>> > Methods of handing pinmux were debated at length on this list. I think >>>> > this >>>> > thread captures most of it: >>>> > >>>> > >>>> > http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11281.html >>>> > >>>> > It's a long thread, but very useful read. >>>> > >>>> > I don't think having drivers handle pinmux directly is acceptable at >>>> > all. >>>> >>>> Correct. Drivers should not do muxing. This should be done by SoC or >>>> board init code. If your bootloader is doing it, that suggests that it is >>>> init-time only, and should be done in init code. >>>> >>> >>> Would it be possible to architect the pin-mux logic to accept boot >>> arguments to >>> configure the SoC devices wanted? We are struggling with porting a kernel >>> to >>> a davinci based System-on-Module type board that would allow end users to >>> select what interfaces (e.g., UARTS vs. SPI ports) to use on these devices. >>> >> >> With the pinmux stuff in the board specific code, u-boot passes the >> board type into the kernel, so only the code that matches the specific >> board type is executed. I realized that I'm repeating my last post. >> Perhaps I don't fully understand your requirements. >> >> Regarding your comment about passing pinmux setting as a kernel >> parameter. Of course that can be done. you got the source code ;) >> The dangers are >> >> 1. The change would not be accepted by the community. >> 2. Potential maintenance issue with custom kernel. >> > > Understood, and I have no desire to go this route. > >>> Having a pile of custom machines (kernel configurations) for every >>> permutation seems >>> painful if all they are doing is enabling different devices. I sort of >>> thought the >> >> Kevin's tree supports single binary that boots multiple DaVinci SoC. >> In other words, you can have a single binary with multiple boards (or >> SoCs) enabled. You can have a specific pinmux setting depends on the >> board type u-boot pass to the kernel in a single binary. >> > > My concern spawns from the fact that I can foresee maybe as many as > 20 unique pinmux configurations for 1 specific davinci based SoM. This > is based on real experience with older SoM's (not running a linux OS). > These devices support a lot of permutations of pin assignments. > > If the right way is really to register 20 different machines over time and > make 20 different board init files and submit them up, no problem. But it > seems like it would become a headache managing that over time.
Is there any way in SW to determine between the variants? If so, you don't need 20 different machine types, just a single one with runtime detection in the board file. > I had a brief experience working with FreeScale parts that used a ROM > device tree block, where this sort of configuration was read in at init and > provided a way to define which peripherals on a SoC you wanted to use > without having to rebuild the kernel (or "worse", make a new machine type). > It was't perfect, but seemed to work. I thought perhaps there was a > similar approach available for the davincis. > > Thanks for the insight. One way or the other, you have to maintain *something* different for each variant. A separate u-boot, separate device tree or a separate pin-mux init in the kernel. Since we don't have device trees for ARM/Linux (not unique to davinci), I strongly prefer the latter. If you cannot detect the variant boards in SW, an alternate might be to use a single machine type but add a custom command-line option that just lists the variant. The kernel board file would use that option to set init the muxing. Kevin _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
