[Skiboot] [PATCH V2 2/6] phb3: Load CAPP ucode to both CAPP units on Naples
Stewart Smith
stewart at linux.vnet.ibm.com
Thu Feb 25 15:10:37 AEDT 2016
Philippe Bergheaud <felix at linux.vnet.ibm.com> writes:
> diff --git a/hw/phb3.c b/hw/phb3.c
> index adff5bc..087f3e0 100644
> --- a/hw/phb3.c
> +++ b/hw/phb3.c
> @@ -2314,6 +2314,10 @@ static struct {
>
> #define CAPP_UCODE_MAX_SIZE 0x20000
>
> +#define CAPP_UCODE_LOADED(chip, p) \
> + ((p->rev < PHB3_REV_NAPLES_DD10) ? chip->capp_ucode_loaded : \
> + (chip->capp_ucode_loaded & (1 << p->index)))
> +
Why not just treat it as a bitmap for everything? Sure, for not Naples,
it'll just be one bit, but that's okay and probably simpler to
understand.
Also, are we *sure* that rev < PHB3_REV_NAPLES_DD10 is going to always
be true? Do we have docs somewhere saying how the revision numbers are
allocated? I couldn't find it from a quick look at docs...
> @@ -2346,12 +2350,18 @@ static int64_t capp_load_ucode(struct phb3 *p)
> struct capp_ucode_data *data;
> struct capp_lid_hdr *lid;
> uint64_t rc, val, addr;
> - uint32_t chunk_count, offset;
> + uint32_t chunk_count, offset, reg_offset;
> int i;
>
> - if (chip->capp_ucode_loaded)
> + if (CAPP_UCODE_LOADED(chip, p))
> return OPAL_SUCCESS;
>
> + /* Return if PHB not attached to a CAPP unit */
> + if (p->rev == PHB3_REV_NAPLES_DD10 && p->index > 1)
> + return OPAL_HARDWARE;
> + if (p->index > 2)
> + return OPAL_HARDWARE;
Should we have a MAX_PHBs define somewhere?
--
Stewart Smith
OPAL Architect, IBM.
More information about the Skiboot
mailing list