summaryrefslogtreecommitdiffstats
path: root/board/embest/mx6boards/mx6boards.c
Commit message (Collapse)AuthorAgeFilesLines
* mx6boards: Fix error handling in board_mmc_init()Fabio Estevam2014-11-241-4/+6
| | | | | | | | | When an invalid USDHC port is passed we should return -EINVAL instead of 0. Also, return the error immediately on fsl_esdhc_initialize() failure. Cc: Eric Benard <eric@eukrea.com> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
* ARM: i.MX: provide declaration for board_spi_cs_gpioEric Nelson2014-10-211-0/+1
| | | | | | | | Provide a public declaration of the board_spi_cs_gpio() callback for i.MX SPI chip selects to prevent the warning "Should it be static?" when compiling with "make C=1". Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
* spi: mxc: fix sf probe when using mxc_spiNikita Kiryanov2014-09-241-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MXC SPI driver has a feature whereas a GPIO line can be used to force CS high across multiple transactions. This is set up by embedding the GPIO information in the CS value: cs = (cs | gpio << 8) This merge of cs and gpio data into one value breaks the sf probe command: if the use of gpio is required, invoking "sf probe <cs>" will not work, because the CS argument doesn't have the GPIO information in it. Instead, the user must use "sf probe <cs | gpio << 8>". For example, if bank 2 gpio 30 is used to force cs high on cs 0, bus 0, then instead of typing "sf probe 0" the user now must type "sf probe 15872". This is inconsistent with the description of the sf probe command, and forces the user to be aware of implementaiton details. Fix this by introducing a new board function: board_spi_cs_gpio(), which will accept a naked CS value, and provide the driver with the relevant GPIO, if one is necessary. Cc: Eric Nelson <eric.nelson@boundarydevices.com> Cc: Eric Benard <eric@eukrea.com> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Tim Harvey <tharvey@gateworks.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Marek Vasut <marex@denx.de> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il> Reviewed-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
* embest/mx6boards: only toggle eMMC usdhc3 RST line on MarSboardIain Paton2014-08-131-0/+1
| | | | | | | | | On MarS usdhc3 is eMMC, on RIoT usdhc3 is uSD and eMMC is usdhc4. Don't run the MarS specific eMMC reset code on usdhc3 when board_type == BOARD_IS_RIOTBOARD Signed-off-by: Iain Paton <ipaton0@gmail.com>
* embest/mx6boards: use common detect_hdmiEric Benard2014-04-151-6/+0
| | | | Signed-off-by: Eric Bénard <eric@eukrea.com>
* RiOTboard and MarSBoard: add new boards supportEric Benard2014-04-151-0/+607
RiOTboard is produced by Embest/Element 14 and is based on i.MX6 Solo The following features are tested : - UART2 (console) - eMMC - SDCard - uSDCard - Ethernet - USB Host (through 4 ports hub) - HDMI output - I2C 1/2/3 - LVDS TFT with LCD8000-97C from Embest/Element 14 Boot on eMMC and through USB loader are tested. For more informations on this board : http://www.riotboard.org/ MarSBoard is produced by Embest/Element 14 and is based on i.MX6 Dual The following features are tested : - UART2 (console) - eMMC - uSDCard - Ethernet - USB Host (through 2 ports hub) - HDMI output - I2C 1/2 - SPI NOR Flash - LVDS TFT with LCD8000-97C from Embest/Element 14 Boot on SPI NOR and through USB loader are tested. For more informations on this board : http://www.embest-tech.com/shop/star/marsboard.html Both boards are supported by the same code base as they are based on a common trunk of schematics. Signed-off-by: Eric Bénard <eric@eukrea.com> Acked-by: Stefano Babic <sbabic@denx.de>
OpenPOWER on IntegriCloud