meta-facebook: yosemite5: add T22 GPIO event monitoring

Description:
- Add phosphor-multi-gpio-monitor-t22.json (95 GPIO entries) and select
  it in multi-gpios-sys-init by the PDB CPLD SKU register, so T22 no
  longer falls back to the EVT/default config.
- Mark the active low pins in the T22 config with ActiveLow and move
  their assert targets to RISING. For a both-edge request the kernel
  derives the reported edge from the logical line value, so with
  ActiveLow an _N pin driven low is reported as a rising edge: the
  daemon now logs "Asserted" instead of "Deasserted" and the target
  lists have to follow. The pins that are active high (Fault,
  PWRGD_CPU_PWROK, UART_MUX_SEL) keep the plain edge mapping. Which
  physical edge runs which target is unchanged.
- Drive the event loggers that were consolidated into the meta-facebook
  layer with their new argument form: <board>-<gpio_name> for the power
  rail and VR fault loggers, <type>-<device>-<gpio_name> for the thermal
  logger, and the shared assert-post-end / deassert-post-end units for
  FM_BIOS_POST_CMPLT_N. smc-event-logger is still yosemite5 local, so
  its targets keep the <board>_<gpio_name> form it parses.
- Name the owning drive directly in the power rail targets of the U.2
  fault pins: the connector index the schematic uses is not the drive
  index entity-manager exposes, so U2_1 and U2_2 log against ssd24 and
  ssd25 and U2_3..U2_26 against ssd0..ssd23. Reporting the drive rather
  than the whole backplane needs no logger change now that the board
  name comes from the config.
- Add drive-fault-led to drive the drive<N>_fault LED group of the
  storage expansion board (Rio Grande) from the U.2 P12V / P3V3_AUX
  fault pins, keeping the LED on while any other fault pin of the same
  drive is still asserted.
- Add hsc-fault-logger, which reads the alerting HSC over PMBus and
  carries its status registers in FAILURE_DATA. Bus, address and vendor
  come from entity-manager, so a SKU that moves or re-vendors the HSCs
  needs no change here.
- Add get_sku and the SKU_T2/T11/T1/T22 constants to
  yosemite5-common-functions and use it in both multi-gpios-sys-init and
  yosemite5-early-sys-init, so T22 detection has one source of truth.
  This also moves the SKU read from the MB CPLD (bus 11, register 0x19,
  bits [6:4]) to the PDB CPLD (bus 8, register 0x12, bits [3:0]).
- Add the pins the T22 config newly routes to fault-led to the latch
  list that script walks on deassert: the two storage expansion board
  SMBus temperature sensor alerts and the two MB P12V_0A_0B faults.

Motivation:
- T22 pairs Yosemite5 with the storage expansion board (Rio Grande),
  which adds U.2 drive faults and HSC alerts that the existing GPIO
  configs and event loggers do not cover.
- Report each fault against the board or drive that owns it and, for HSC
  alerts, record why the controller tripped, so a tech can locate the
  faulty part from the event log alone.

Test:
- Confirmed multi-gpios-sys-init links
  phosphor-multi-gpio-monitor-t22.json on a T22 system.
- Manually triggered each new target and checked the event log entry,
  the inventory path it points at and the drive fault LED state:

    systemctl start power-rail-assert-log@ssd24-ALT_P12V_U2_1_N.service
    systemctl start drive-fault-led-assert@ALT_P12V_U2_1_N.service
    systemctl start \
      hsc-fault-assert-log@Yosemite5_3KW_Paddle_Board-ALRT_HSC_SLOT_5_N.service
    systemctl start smc-assert-log@mb_ALERT_CLKMUX_0_LOSS_N.service

  then the matching *-deassert-* units, and confirmed the assert entries
  were resolved and the LED turned off.

Change-Id: Ibe551a3baa2164fb73598c65fa43cb3173b861b1
Signed-off-by: Zane Li <zane.li.wiwynn@gmail.com>

0 files changed, 0 insertions, 0 deletions