Re: several OMAP newbie questions
Kevin Hilman wrote: Mike Rapoport wrote: Hi Kevin, Kevin Hilman wrote: There is lots of agreement around the various shortcomings of the current mux framework for OMAP. All that's missing is someone to step up and do the work. :/ I started a new wiki topic at elinux.org for linux-omap wishlist items: http://elinux.org/OMAP_wishlist here I created a pin-mux section where we could start to keep track of the important features needed in a new mux framework. Adding pointers summaries to some other platforms might be useful here as well. If you'd like to I can add a brief description of what PXA does. Sure, could be useful. Done. :) Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: several OMAP newbie questions
Mike Rapoport wrote: Hi Kevin, Kevin Hilman wrote: There is lots of agreement around the various shortcomings of the current mux framework for OMAP. All that's missing is someone to step up and do the work. :/ I started a new wiki topic at elinux.org for linux-omap wishlist items: http://elinux.org/OMAP_wishlist here I created a pin-mux section where we could start to keep track of the important features needed in a new mux framework. Adding pointers summaries to some other platforms might be useful here as well. If you'd like to I can add a brief description of what PXA does. Sure, could be useful. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: several OMAP newbie questions
Hi Kevin, Kevin Hilman wrote: There is lots of agreement around the various shortcomings of the current mux framework for OMAP. All that's missing is someone to step up and do the work. :/ I started a new wiki topic at elinux.org for linux-omap wishlist items: http://elinux.org/OMAP_wishlist here I created a pin-mux section where we could start to keep track of the important features needed in a new mux framework. Adding pointers summaries to some other platforms might be useful here as well. If you'd like to I can add a brief description of what PXA does. This will help us get a start so when someone is ready to step up and do the work, we'll have a starting point. Kevin -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: several OMAP newbie questions
Cliff Brake cliff.br...@gmail.com writes: On Tue, Sep 1, 2009 at 6:34 AM, Mike Rapoportm...@compulab.co.il wrote: 3) If I'm not much mistaken, board specific pin mux configuration has to deal with arch/arm/plat-omap/include/mach/mux.h and arch/arm/mach-omap2/mux.c. For instance, if my board uses ULPI pins that have not been defined already, I need to patch those file with my pin mux definitions. Am I right here, or have I missed something? It seems to me there should be a global mux configuration per CPU, but should be configurable per board, group of boards, etc. What I would like is a set of routines can be used to configure the mux that is then called by the board files (similar to PXA). Especially once we get into supporting multiple base boards with things like beagle and overo, it would be nice to have have all this logic both places (kernel/uboot), but maybe its needed there anyway. There is lots of agreement around the various shortcomings of the current mux framework for OMAP. All that's missing is someone to step up and do the work. :/ I started a new wiki topic at elinux.org for linux-omap wishlist items: http://elinux.org/OMAP_wishlist here I created a pin-mux section where we could start to keep track of the important features needed in a new mux framework. Adding pointers summaries to some other platforms might be useful here as well. This will help us get a start so when someone is ready to step up and do the work, we'll have a starting point. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: several OMAP newbie questions
Cliff Brake wrote: On Tue, Sep 1, 2009 at 6:34 AM, Mike Rapoportm...@compulab.co.il wrote: 3) If I'm not much mistaken, board specific pin mux configuration has to deal with arch/arm/plat-omap/include/mach/mux.h and arch/arm/mach-omap2/mux.c. For instance, if my board uses ULPI pins that have not been defined already, I need to patch those file with my pin mux definitions. Am I right here, or have I missed something? It seems to me there should be a global mux configuration per CPU, but should be configurable per board, group of boards, etc. What I would like is a set of routines can be used to configure the mux that is then called by the board files (similar to PXA). Yeah, I actually was missing pxa_mfp_config()... The omap34xx_pins seems somewhat sparse... Cliff -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: several OMAP newbie questions
On Tue, Sep 1, 2009 at 6:34 AM, Mike Rapoportm...@compulab.co.il wrote: 3) If I'm not much mistaken, board specific pin mux configuration has to deal with arch/arm/plat-omap/include/mach/mux.h and arch/arm/mach-omap2/mux.c. For instance, if my board uses ULPI pins that have not been defined already, I need to patch those file with my pin mux definitions. Am I right here, or have I missed something? It seems to me there should be a global mux configuration per CPU, but should be configurable per board, group of boards, etc. What I would like is a set of routines can be used to configure the mux that is then called by the board files (similar to PXA). Especially once we get into supporting multiple base boards with things like beagle and overo, it would be nice to have have all this logic both places (kernel/uboot), but maybe its needed there anyway. Cliff -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
several OMAP newbie questions
Hi all,
I've recently started to work on adding support for a custom OMAP3 board.
Several things in the arch/arm/mach-omap2/board-* caught my attention:
1) omap_xxx_map_io and omap_xxx_init_irq are mostly the same in all board-*
files, the only difference is omap_sdrc_params passed to omap2_init_common_hw.
Probably it'd make sense to have omap_map_io_{242x,243x,343x} as the initializer
of .map_io and move the common part of omap_xxx_map_io to some common place?
2) Boards that use NAND flash have the very same NAND chip select detection
code. Is this code necessary, or, if I know for sure that NAND is connected to
nCS0 I can skip the chip select detection? And, again, if several boards use the
same code for chip select detection, wouldn't it be wise to move it to some
common place?
3) If I'm not much mistaken, board specific pin mux configuration has to deal
with arch/arm/plat-omap/include/mach/mux.h and arch/arm/mach-omap2/mux.c. For
instance, if my board uses ULPI pins that have not been defined already, I need
to patch those file with my pin mux definitions. Am I right here, or have I
missed something?
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
