u-boot.git/drivers/misc, branch v2010.06-rc3 Unnamed repository; edit this file 'description' to name the repository. misc: add gpio based status led driver 2010-05-28T14:56:03+00:00 Thomas Chou thomas@wytron.com.tw 2010-04-30T03:34:14+00:00 3e6b86b5552840bb4147871a753840eb3923374c This patch adds a status led driver followed the GPIO access conventions of Linux. The led mask is used to specify the gpio pin. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Tested-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Scott McNutt <smcnutt@psyent.com> 
This patch adds a status led driver followed the GPIO access
conventions of Linux. The led mask is used to specify the gpio pin.

Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Tested-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Scott McNutt <smcnutt@psyent.com>
MX: Added Freescale Power Management Driver 2010-05-05T07:48:41+00:00 Stefano Babic sbabic@denx.de 2010-04-04T21:08:03+00:00 28bb6d34d3f431b7b00444e2f829b2c04f5daf4d The patch add supports for the Freescale's Power Management Controller (known as Atlas) used together with i.MX31/51 processors. It was tested with a MC13783 (MX31) and MC13892 (MX51). Signed-off-by: Stefano Babic <sbabic@denx.de> 
The patch add supports for the Freescale's Power
Management Controller (known as Atlas) used together with i.MX31/51
processors. It was tested with a MC13783 (MX31) and
MC13892 (MX51).

Signed-off-by: Stefano Babic <sbabic@denx.de>
85xx: Added various P1012/P1013/P1021/P1022 defines 2010-04-07T05:21:22+00:00 Kumar Gala galak@kernel.crashing.org 2010-03-31T04:06:53+00:00 216082754f6da5359ea0db9b0cc03ad531ac6e45 There are various locations that we have chip specific info: * Makefile for which ddr code to build * Added P1012/P1013/P1021/P1022 to cpu_type_list and SVR list * Added number of LAWs for P1012/P1013/P1021/P1022 * Set CONFIG_MAX_CPUS to 2 for P1021/P1022 * PCI port config Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com> Signed-off-by: Srikanth Srinivasan <srikanth.srinivasan@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
There are various locations that we have chip specific info:

* Makefile for which ddr code to build
* Added P1012/P1013/P1021/P1022 to cpu_type_list and SVR list
* Added number of LAWs for P1012/P1013/P1021/P1022
* Set CONFIG_MAX_CPUS to 2 for P1021/P1022
* PCI port config

Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
Signed-off-by: Srikanth Srinivasan <srikanth.srinivasan@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
TWL4030: make LEDs selectable for twl4030_led_init() 2010-01-04T14:48:15+00:00 Grazvydas Ignotas notasas@gmail.com 2009-12-10T15:10:21+00:00 ead39d7aa3ddccb2e374217aeab23bd65cedb762 Not all boards have both LEDs hooked, so enabling both on boards with single LED will just waste power. Make it possible to choose LEDs by adding argument to twl4030_led_init(). Using this turn on only LEDB for pandora, leave both LEDs on for all other boards, as it was before this patch. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> 
Not all boards have both LEDs hooked, so enabling both on
boards with single LED will just waste power. Make it
possible to choose LEDs by adding argument to
twl4030_led_init().

Using this turn on only LEDB for pandora, leave both LEDs
on for all other boards, as it was before this patch.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
ppc/85xx: get_law_entry isn't used in CONFIG_NAND_SPL 2009-09-30T13:42:12+00:00 Kumar Gala galak@kernel.crashing.org 2009-09-30T13:39:44+00:00 24b17d8a3c3a4b9ceaf6363ebe0021011b0b8bd8 Don't include get_law_entry as part of the NAND_SPL build since the code isnt used. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
Don't include get_law_entry as part of the NAND_SPL build since the
code isnt used.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
ppc/p4080: Add various p4080 related defines (and p4040) 2009-09-24T17:05:28+00:00 Kumar Gala galak@kernel.crashing.org 2009-03-19T07:39:17+00:00 7e4259bba4c56536760e42d32dacfb3233f216fd There are various locations that we have chip specific info: * Makefile for which ddr code to build * Added p4080 & p4040 to cpu_type_list and SVR list * Added number of LAWs for p4080 * Set CONFIG_MAX_CPUS to 8 for p4080 Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
There are various locations that we have chip specific info:

* Makefile for which ddr code to build
* Added p4080 & p4040 to cpu_type_list and SVR list
* Added number of LAWs for p4080
* Set CONFIG_MAX_CPUS to 8 for p4080

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
ppc/p4080: Add support for CoreNet style platform LAWs 2009-09-24T17:05:28+00:00 Kumar Gala galak@kernel.crashing.org 2009-03-19T07:32:23+00:00 418ec8584343f04048e2cc7ee96b6b29be54ad97 On CoreNet based platforms the LAW address is split between an high & low register and we no longer shift the address. Also, the target IDs on CoreNet platforms have been completely re-assigned. Additionally, added a new find_law() API to which LAW an address hits in. This is need for the CoreNet style boot release code since it will need to determine what the target ID should be set to for boot window translation. Finally, enamed LAWAR_EN to LAW_EN and moved to header so we can use it elsewhere. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
On CoreNet based platforms the LAW address is split between an high &
low register and we no longer shift the address.  Also, the target IDs
on CoreNet platforms have been completely re-assigned.

Additionally, added a new find_law() API to which LAW an address hits in.
This is need for the CoreNet style boot release code since it will need
to determine what the target ID should be set to for boot window
translation.

Finally, enamed LAWAR_EN to LAW_EN and moved to header so we can use
it elsewhere.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
ppc/85xx: add boot from NAND/eSDHC/eSPI support 2009-09-16T02:30:09+00:00 Mingkai Hu Mingkai.hu@freescale.com 2009-09-11T06:19:10+00:00 7da53351d817c6d77364cfde922891f37d0e5ed8 The MPC8536E is capable of booting form NAND/eSDHC/eSPI, this patch implements these three bootup methods in a unified way - all of these use the general cpu/mpc85xx/start.S, and load the main image to L2SRAM which lets us use the SPD to initialize the SDRAM. For all three bootup methods, the bootup process can be divided into two stages: the first stage will initialize the corresponding controller, configure the L2SRAM, then copy the second stage image to L2SRAM and jump to it. The second stage image is just like the general U-Boot image to configure all the hardware and boot up to U-Boot command line. When boot from NAND, the eLBC controller will first load the first stage image to internal 4K RAM buffer because it's also stored on the NAND flash. The first stage image, also call 4K NAND loader, will initialize the L2SRAM, load the second stage image to L2SRAM and jump to it. The 4K NAND loader's code comes from the corresponding nand_spl directory, along with the code twisted by CONFIG_NAND_SPL. When boot from eSDHC/eSPI, there's no such a first stage image because the CPU ROM code does the same work. It will initialize the L2SRAM according to the config addr/word pairs on the fixed address and initialize the eSDHC/eSPI controller, then load the second stage image to L2SRAM and jump to it. The macro CONFIG_SYS_RAMBOOT is used to control the code to produce the second stage image for all different bootup methods. It's set in the board config file when one of the bootup methods above is selected. Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
The MPC8536E is capable of booting form NAND/eSDHC/eSPI, this patch
implements these three bootup methods in a unified way - all of these
use the general cpu/mpc85xx/start.S, and load the main image to L2SRAM
which lets us use the SPD to initialize the SDRAM.

For all three bootup methods, the bootup process can be divided into two
stages: the first stage will initialize the corresponding controller,
configure the L2SRAM, then copy the second stage image to L2SRAM and
jump to it. The second stage image is just like the general U-Boot image
to configure all the hardware and boot up to U-Boot command line.

When boot from NAND, the eLBC controller will first load the first stage
image to internal 4K RAM buffer because it's also stored on the NAND
flash. The first stage image, also call 4K NAND loader, will initialize
the L2SRAM, load the second stage image to L2SRAM and jump to it. The 4K
NAND loader's code comes from the corresponding nand_spl directory, along
with the code twisted by CONFIG_NAND_SPL.

When boot from eSDHC/eSPI, there's no such a first stage image because
the CPU ROM code does the same work. It will initialize the L2SRAM
according to the config addr/word pairs on the fixed address and
initialize the eSDHC/eSPI controller, then load the second stage image
to L2SRAM and jump to it.

The macro CONFIG_SYS_RAMBOOT is used to control the code to produce the
second stage image for all different bootup methods. It's set in the
board config file when one of the bootup methods above is selected.

Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
fsl: add register read-back to set_law() 2009-09-08T14:10:06+00:00 Timur Tabi timur@freescale.com 2009-09-04T22:05:24+00:00 74c5dfd81f94a2a1f0d6990d17c491d718e8b9ea After programming a new LAW, we should read-back the LAWAR register so that we sync the writes. Otherwise, code that attempts to use the new LAW-mapped memory might fail right away. Signed-off-by: Timur Tabi <timur@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
After programming a new LAW, we should read-back the LAWAR register so that
we sync the writes.  Otherwise, code that attempts to use the new LAW-mapped
memory might fail right away.

Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
85xx: Added single core members of FSL P1xx/P2xx processors series 2009-08-28T22:12:41+00:00 Poonam Aggrwal poonam.aggrwal@freescale.com 2009-08-20T13:27:45+00:00 a713ba926b45da9a6f923f1ac9e60a66852e5f2d P1011 - Single core variant of P1020 P2010 - Single core variant of P2020 Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
P1011 - Single core variant of P1020
P2010 - Single core variant of P2020

Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>