- 20 May, 2018 5 commits
-
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
- 16 May, 2018 10 commits
-
-
Raptor Engineering Development Team authored
Note that RPM mode is only used here to engage the legacy code paths that use scaled native PWM access. This should be changed to use the new PWM direct access code at some point in the future.
-
Raptor Engineering Development Team authored
-
Matt Spinler authored
The openpower-occ-control code needs to know the power supply derating factor, but will default to a value if one isn't supplied externally in do_configure. Since other will also need to use that same value, use a common variable for it defined in openpower.inc, and now pass it into the configure step. This derating factor is an OpenPower concept used by the Power processor's OCC thermal control subsystem. Tested: Check that the derating factor variable in config.h in the openenpower-occ-control repo follows the variable in openpower.inc. Change-Id: I259b6086ebe70b2ac6eccdd244e43a7d36a28a77 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
-
Marri Devender Rao authored
Extend recipe for native recipe which installs error yaml files to shared location Partially resolves openbmc/openbmc#2705 Change-Id: I02405a24353a565dbd34fdca06098be8337cd921 Signed-off-by: Marri Devender Rao <devenrao@in.ibm.com>
-
Marri Devender Rao authored
All the packages that copy error yaml files to shared location for error log processing need to inherit phosphor-dbus-yaml base class. The error yaml files that are copied to the shared location need to be packaged, base class caters for packaging the files with the openpower-occ-control. Change-Id: Ia1d37b58e5f27d1237adcb0d550a4ae6d61e2f18 Signed-off-by: Marri Devender Rao <devenrao@in.ibm.com>
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Joel Stanley authored
We have 236 commits, 127 files changed, 17766 insertions(+), 2128 deletions(-). Some of these are backports from upstream. This list does not include patches from the 4.13 stable releases, but we do include those in the dev-4.13 branch. 1 Alexey Khoroshilov 34 Andrew Jeffery 1 Arnd Bergmann 1 Benjamin Herrenschmidt 1 Bhumika Goyal 1 Brad Bishop 1 Brendan Higgins 11 Christopher Bostic 1 Cyril Bur 14 Cédric Le Goater 49 Edward A. James 3 Gavin Shan 1 Guenter Roeck 8 Ivan Mikhaylov 1 Jacek Anaszewski 1 James Feist 7 Jeremy Kerr 72 Joel Stanley 2 Julia Lawall 1 Ken Chen 6 Lei YU 3 Milton Miller 1 Mykola Kostenok 1 Patrick Venture 2 Philipp Zabel 1 Rick Altherr 11 Samuel Mendoza-Jonas 2 Wei Yongjun 1 Xo Wang 1 Yong Li Note that the 4.13 branch is EOL'd by the Linux community, and as such should not be used for any products beyond development. React to removal of occ hwmon instances from device trees with a new startup/shutdown mechanism for phosphor-hwmon. To fix this, a helper script will be used to start the service that will pass the service the device tree name if it is present, or the udev device path if it isn't. This script will still run from the udev rule as before, but it will stop and start the service itself without using the SYSTEMD_WANTS attribute. As the path to the hwmon environment file matches the service template argument, the paths for the OCC .conf files need to change to match the device path instead of the previous device tree path. Note that the pure device path would have the hwmon instance number in it, but since that can't be known ahead of time it is stripped off by the script that starts the service. In addition, the pure device path for the OCCs contain several ':'s, meaning the associated environment files would also need to. However, Yocto/Bitbake cannot handle a ':' in a file path, so they are converted to '--'s by the script that starts the service and phosphor-hwmon will convert them back internally when it starts. The service file also needed some changes now that the service lifetime is no longer controlled by systemd via SYSTEMD_WANTS. This script will be called by a udev rule to start and stop phosphor-hwmon when the hwmon device driver is started and stopped. It is passed both the device path and the OF_FULLNAME device tree attribute. If OF_FULLNAME is present, it will start the service with that as its template argument, otherwise it will use the device path. This is to handle devices that aren't in the device tree so they won't have OF_FULLNAME. If a '/hwmon/hwmonN' is in the path it is removed, as this path is also used as a path to an environment file and so must be known ahead of time, which the hwmon instance N is not. If there is a ':' in the path name, it is converted to a '--'. Yocto/Bitbake cannot handle a ':' in file paths. Resolves openbmc/openbmc#2953 Change-Id: I815be4d6d9e1cbea8428bb1bb8c332776ee71ece Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Matt Spinler <spinler@us.ibm.com> Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
-
Raptor Engineering Development Team authored
This reverts commit 7e96d183. The FSI driver is now stable enough that this patch is no longer needed
-
- 14 May, 2018 4 commits
-
-
Raptor Engineering Development Team authored
Enable LED PWM support - NOTE: PWM is software driven and not yet suitable for general use
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
This works around more FSI bus failures due to binding while host skiroot kernel is still starting
-
Raptor Engineering Development Team authored
-
- 13 May, 2018 14 commits
-
-
Raptor Engineering Development Team authored
Add CPU1 ambient sensor and PCIe ambient sensor to fan control ambient temperature sensor group on Talos II
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
Retune PID loop for new sensor locations
-
Raptor Engineering Development Team authored
Talos has three on-board sensors, two high resolution sensors and one low resolution sensor. The two high resolution sensors are mounted near the front edge of the PCB, to monitor intake temperatures on the card. The low resolution sensor is mounted near the rear of the PCB, in the PCIe card area.
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
- 11 May, 2018 1 commit
-
-
Raptor Engineering Development Team authored
-
- 10 May, 2018 1 commit
-
-
Raptor Engineering Development Team authored
-
- 09 May, 2018 5 commits
-
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-