summaryrefslogtreecommitdiff
path: root/arch/arm/mach-mvebu/serdes
AgeCommit message (Collapse)Author
2018-06-05mvebu: a38x: Force receiver detected on PCIe lanesRabeeh Khoury
Some QCA988x based modules presence is not detected by the SERDES lanes, so force this detection which will trigger the LTSSM state machine to negotiate link. An example of such a card is WLE900VX. Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Tested-by: Chris Packham <judge.packham@gmail.com> Tested-by: Mario Six <mario.six@gdsys.cc> Signed-off-by: Stefan Roese <sr@denx.de>
2018-05-14ARM: mvebu: a38x: move sys_env_device_rev_getChris Packham
Move sys_env_device_rev_get() from the ddr training code to sys_env_lib.c (which currently resides with the serdes code). This brings sys_env_device_rev_get() into line with sys_env_device_id_get() and sys_env_model_get(). Signed-off-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Stefan Roese <sr@denx.de>
2018-05-14ARM: mvebu: a38x: move definition of PEX_CFG_DIRECT_ACCESSChris Packham
PEX_CFG_DIRECT_ACCESS was defined in ddr3_hws_hw_training_def.h despite only being used in the serdes code. Move this definition to ctrl_pex.h where all the other PEX defines are. Also remove the duplicate definition of PEX_DEVICE_AND_VENDOR_ID which is already defined in ctrl_pex.h. Signed-off-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Stefan Roese <sr@denx.de>
2018-05-07SPDX: Convert all of our single license tags to Linux Kernel styleTom Rini
When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
2017-08-13arm: mvebu: avoid possible NULL dereferencexypron.glpk@gmx.de
It does not make sense to check if info is NULL after dereferencing it. The problem was indicated by cppcheck. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Stefan Roese <sr@denx.de>
2017-05-09arm: mvebu: Minor fixes in the AXP / A38x SERDES codeUwe Kleine-König
- Fix spelling error of SERDES_VERSION - Remove superfluous definition of this macro - Remove unnecessary include of i2c.h Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Stefan Roese <sr@denx.de>
2017-03-23arm: mvebu: AXP: Add possiblity to configure PEX detection pulse widthStefan Roese
Tests have shown that on some boards the default width of the configuration pulse for the PEX link detection might lead to non-established PCIe links (link down). Especially under certain conditions (higher temperature) and with specific PCIe devices (in the case on the theadorable board its a Atheros PCIe WLAN device). To enable a board-specific detection pulse width this weak array "serdes_pex_pulse_width[4]" is introduced which can be overwritten if needed by a board-specific version. If the board code does not provide a non-weak version of this variable, the default value will be used. So nothing is changed from the current setup on the supported board. Many thanks to Adam from Marvell for all his insights here and his suggestion about testing with a changed detection pulse width. Signed-off-by: Stefan Roese <sr@denx.de> Suggested-by: Adam Shobash <adams@marvell.com> Cc: Adam Shobash <adams@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Cc: Konstantin Porotchkin <kostap@marvell.com> Signed-off-by: Stefan Roese <sr@denx.de>
2017-02-01mvebu: Add board_pex_config()Mario Six
Allow boards to do some initialization when PCIe comes up. Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc> Signed-off-by: Mario Six <mario.six@gdsys.cc> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Stefan Roese <sr@denx.de>
2016-09-24arm: mvebu: create generic 88F6820 config optionChris Packham
88F6820 is a specific Armada-38x chip that is used on the DB-88F6820-GP board. Rather than having DB_88F6820_GP and TARGET_DB_88F6820_GP which selects the former. Rename DB_88F6820_GP to 88F6820 so that other boards using the 88F6820 can be added. Stefan: Change 88F6820 for clearfog as well. Signed-off-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Stefan Roese <sr@denx.de>
2016-08-26arm: mvebu: a38x: typo fix cpabilities -> capbilitiesChris Packham
Signed-off-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Stefan Roese <sr@denx.de>
2016-08-26arm: mvebu: a38x: update serdes error handlingChris Packham
Ensure appropriate error messages are generated. Previously all errors indicated that the serdes was already in use. Now appropriate error messages are given. Signed-off-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Stefan Roese <sr@denx.de>
2016-01-14mvebu: Support Synology DS414Phil Sutter
This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error. Sadly, support is far from perfect. The major parts I have failed in are SATA and XHCI support. Details about these and some other things follow: Device Tree ----------- The device tree file armada-xp-synology-ds414.dts has been copied from Linux and enhanced by recent U-Boot specific changes to armada-xp-gp.dts. SATA Support ------------ There is a Marvell 88SX7042 controller attached to PCIe which is supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv. I'm not sure if extending the latter to support PCI devices is worth the effort at all. Porting sata_mv from Linux exceeded my brain's capacities. :( XHCI Support ------------ There is an EtronTech EJ168A XHCI controller attached to PCIe which drives the two rear USB3 ports. After a bit of playing around I managed to get it recognized by xhci-pci, but never was able to access any devices attached to it. Enabling it in ds414 board config shows that it does not respond to commands for whatever reason. The (somewhat) bright side to it is that it is not even supported in Synology's customized U-Boot, but that also means nowhere to steal the relevant bits from. EHCI Support ------------ This seems functional after issuing 'usb start'. At least it detects USB storage devices, and IIRC reading from them was OK. OTOH Linux fails to register the controller if 'usb start' wasn't given before in U-Boot. According to Synology sources, this board seems to support USB device (gadget?) mode. Though I didn't play around with it. PCIe Support ------------ This is fine, but trying to gate the clocks of unused lanes will hang PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI. DDR3 Training ------------- Marvell/Synology uses eight PUPs instead of four. Does not look like this is meant to be customized in mainline U-Boot at all. OTOH I have no idea what a "PUP" actually is. PEX Init -------- Synology uses different values than mainline U-Boot with this patch: pex_max_unit_get returns 2, pex_max_if_get returns 7 and max_serdes_lines is set to 7. Not changing this seems to not have an impact, although I'm not entirely sure it does not cause issues I am not aware of. Static Environment ------------------ This allows to boot stock Synology firmware at least. In order to be a little more flexible when it comes to booting custom kernels, do not only load zImage partition, but also rd.gz into memory. This way it is possible to use about 7MB for kernel with piggyback initramfs. Signed-off-by: Phil Sutter <phil@nwl.cc> Acked-by: Stefan Roese <sr@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-14mvebu: Add rudimental MV78230 supportPhil Sutter
This adds basic support for Marvell's MV78230 SoC which belongs to the Armada XP series. Signed-off-by: Phil Sutter <phil@nwl.cc> Acked-by: Stefan Roese <sr@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-14mvebu: axp: refactor board_sat_r_get() and callerPhil Sutter
Instead of calling board_sat_r_get() only for those boards providing the satr11 value via I2C, call it for all boards and return static values for those not using I2C. In addition to that, make this a weak function to allow for board code to override it. Signed-off-by: Phil Sutter <phil@nwl.cc> Acked-by: Stefan Roese <sr@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-14arm: mvebu: Make serdes setup on Armada XP less noisyStefan Roese
Change some of the PEX configuration output lines from always output to only ouput upon specific debug enabling. This changes the SPL output from: U-Boot SPL 2016.01-rc2-00037-g9353a7f (Dec 10 2015 - 10:27:42) High speed PHY - Version: 2.1.5 (COM-PHY-V20) Update Device ID PEX0782611ab Update Device ID PEX1782611ab Update Device ID PEX2782611ab Update Device ID PEX3782611ab Update Device ID PEX8782611ab Update PEX Device ID 0x78260 High speed PHY - Ended Successfully DDR3 Training Sequence - Ver 5.7.4 DDR3 Training Sequence - Ended Successfully to: U-Boot SPL 2016.01-rc2-00037-g9353a7f-dirty (Dec 10 2015 - 10:32:04) High speed PHY - Version: 2.1.5 (COM-PHY-V20) High speed PHY - Ended Successfully DDR3 Training Sequence - Ver 5.7.4 DDR3 Training Sequence - Ended Successfully Resulting in a little faster bootup time. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Luka Perkov <luka.perkov@sartura.hr>
2016-01-14arm: mvebu: Add support for MV78260Stefan Roese
This patch adds support for the dual core Armada XP variant, the MV78260. It has some minor differences to the 4-core MV78460, e.g. only 12 serdes lanes. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Luka Perkov <luka.perkov@sartura.hr> Cc: Phil Sutter <phil@nwl.cc>
2016-01-14arm: mvebu: Don't use 0 as board ID as its used for the custom boardsStefan Roese
Using board ID 0 is reserved for the non-Marvell "custom" boards. So move the board ID's to reflect this. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Luka Perkov <luka.perkov@sartura.hr> Cc: Phil Sutter <phil@nwl.cc>
2015-11-17arm: mvebu: a38x: serdes specification cleanupKevin Smith
Instead of allocating space in the driver for the serdes specification table, just allow the board file to set a pointer to it. Also, allow the board to only specify the lanes that are used instead of including unused lanes. Signed-off-by: Kevin Smith <kevin.smith@elecsyscorp.com> Acked-by: Stefan Roese <sr@denx.de> Cc: Dirk Eibach <eibach@gdsys.de> Cc: Luka Perkov <luka.perkov@sartura.hr>
2015-11-17arm: mvebu: a38x: Add const to some function callsKevin Smith
Functions that do not modify the pointer passed should declare it as const. Signed-off-by: Kevin Smith <kevin.smith@elecsyscorp.com> Acked-by: Stefan Roese <sr@denx.de> Cc: Dirk Eibach <eibach@gdsys.de> Cc: Luka Perkov <luka.perkov@sartura.hr>
2015-11-17arm: mvebu: a38x: Remove unsupported topologiesKevin Smith
A lot of extra configuration information was left over in the Marvell serdes and DDR3 initialization code for boards that U-boot does not support. Remove this extra config information, and the concept of fixing up board topologies with information loaded from an EEPROM. If this needs to be done, it should be handled in the board file, not in core code. Signed-off-by: Kevin Smith <kevin.smith@elecsyscorp.com> Acked-by: Stefan Roese <sr@denx.de> Cc: Dirk Eibach <eibach@gdsys.de> Cc: Luka Perkov <luka.perkov@sartura.hr>
2015-07-23arm: mvebu: a38x: Use correct PEX register access macrosStefan Roese
Remove the incorrect PEX macros from the DDR header. And insert the correct ones in ctrl_pex.h instead. Signed-off-by: Stefan Roese <sr@denx.de>
2015-07-23arm: mvebu: drivers/ddr: Move Armada XP DDR init code into new directoryStefan Roese
With the upcoming addition of the Armada 38x DDR support, which is not compatible to the Armada XP DDR init code, we need to introduce a new directory infrastructure. To support multiple Marvell DDR controller. This will be the new structure: drivers/ddr/marvell/axp Supporting Armada XP (AXP) devices (and perhaps Armada 370) drivers/ddr/marvell/a38x Supporting Armada 38x devices (and perhaps Armada 39x) Signed-off-by: Stefan Roese <sr@denx.de>
2015-07-23arm: mvebu: Add Armada 38x SERDES / PHY init code from Marvell bin_hdrStefan Roese
This code is ported from the Marvell bin_hdr code into mainline SPL U-Boot. It needs to be executed very early so that the devices connected to the serdes PHY are configured correctly. Signed-off-by: Stefan Roese <sr@denx.de>
2015-07-23arm: mvebu: serdes: Move Armada XP SERDES / PHY init code into new directoryStefan Roese
With the upcoming addition of the Armada 38x SPL support, which is not compatible to the Armada XP SERDES init code, we need to introduce a new directory infrastructure. So lets move the AXP serdes init code into a new directory. This way the A38x code can be added in a clean way. Signed-off-by: Stefan Roese <sr@denx.de>
2015-05-05arm: mvebu: Move mvebu-common into mach-mvebuStefan Roese
Now that the mach-mvebu directory exists and is used by Armada XP we can move the mvebu-common files into this directory as well. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com> Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>