[Skiboot] [PATCH v6 4/9] Catalog parser function to detect Nest units
Madhavan Srinivasan
maddy at linux.vnet.ibm.com
Wed Feb 24 14:54:41 AEDT 2016
On Tuesday 23 February 2016 08:56 AM, Sukadev Bhattiprolu wrote:
> Madhavan Srinivasan [maddy at linux.vnet.ibm.com] wrote:
>> Catalog have "group" structure to group events with similiar functions.
>> All the events within a group will be from same nest unit or domain.
>> A Nest unit can have multiple groups for its events in the catalog.
>> But, device tree will have only one node for a nest units and all the
> nit. s/units/unit/.
>
>> events supported by that nest units should end up under it.
> ditto
>
> Also, since the DT nodes are also under our control, can you rephrase
> this to:
>
> Create a single DT node for each nest unit and under that node,
> create one node for each event-group supported by that nest-unit.
>
> From what I understand, we are parsing the catalog to locate nest units,
> and their event groups and then creating device tree nodes for both of
> them. Along the way, we have to tweak the nest unit names from the catalog
> to be suitable for their dt-node names.
Yes.
>
> If my understaing is correct, renaming some the variables/function names
> for consistency will help. Feel free to ignore the nits below.
>
>> Two data structures are added:
>> 1)struct "lookup_grp_name_to_device_name"
> Since this table maps event group names to DT node names, how about
> renaming this to 'map_grp_name_to_dt_name'?
>
>> 2)struct "nest_catalog_grps_device"
> and this to 'map_nest_unit_to_dt_node'?
>
> While shortening "group" to "grp", we could also shorten "device" to
> "dev" without ambiguity.
Yes. can change these.
>> Function detect_nest_units(), scans all the chip groups in the
>> catalog file and passes each chip group to update_catalog_to_devices().
>> update_catalog_to_devices() routine using lookup table identify the
>> group to a nest unit. Function then save the group address in
>> the "nest_catalog_grps_device" structure under the identified nest unit.
> Explanation of the functions could go into the function headers?
I have added comments in the code. But this is just to sum up.
>
>> Signed-off-by: Madhavan Srinivasan <maddy at linux.vnet.ibm.com>
>> ---
>> hw/nest.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> include/nest.h | 29 +++++++++++++++++++++
>> 2 files changed, 108 insertions(+)
>>
>> diff --git a/hw/nest.c b/hw/nest.c
>> index 4aa5fa0e5332..23a61d80f101 100644
>> --- a/hw/nest.c
>> +++ b/hw/nest.c
>> @@ -33,6 +33,24 @@
>> struct nest_catalog_desc *catalog_desc;
>>
>> /*
>> + * Lookup table to map the catalog nest group to
>> + * hardware nest unit.
>> + */
>> +struct lookup_grp_name_to_device_name lookup_table[] = {
>> + {"PowerBus", "powerbus", 8, POWERBUS},
>> + {"Pumps_and_Retries", "powerbus", 17, POWERBUS},
>> + {"MCS_Read", "mcs_read",8, MCS_READ},
>> + {"MCS_Write", "mcs_write", 9, MCS_WRITE},
>> + {"X-link", "xbus", 6, XBUS},
>> + {"A-link", "abus", 6, ABUS},
> Nit. Align the columns to make it easier to read?
>
>> +};
>> +
>> +/*
>> + * Structure to hold catalog groups information for each nest unit
>> + */
>> +struct nest_catalog_grps_device dev_grp_map[NEST_DT_DEVICE_MAX];
>> +
>> +/*
>> * Catalog Page-0 (each page is 4K bytes long) contains
>> * information about event, group, formula structure offsets
>> * in the catalog. Cache these offsets in struct nest_catalog_page_0
>> @@ -40,6 +58,60 @@ struct nest_catalog_desc *catalog_desc;
>> */
>> struct nest_catalog_page_0 *page0_desc;
>>
>> +static void update_catalog_to_devices(struct nest_catalog_group_data *gptr)
> How about 'add_grp_to_nest_unit_dt()?'
>
> and s/gptr/grp/ or group?
>
>> +{
>> + int i, rc, dev_id, cnt;
> Doesn't dev_id represent a nest_unit index? If so call it 'unit'?
>
>> + int len;
>> +
>> + for (i=0; i< NEST_DT_DEVICE_MAX; i++) {
> Nit. Spaces around operators = and <?
>
>> + len = lookup_table[i].length;
>> + if (len > gptr->group_name_len)
>> + len = gptr->group_name_len;
>> +
>> + rc = strncmp(gptr->remainder, lookup_table[i].catalog_grp_name,len);
> s/remainder/name/?
>
> space after comma.
>
>
>> + if (!rc) {
>> + dev_id = lookup_table[i].devices_id;
>> + cnt = dev_grp_map[dev_id].nest_device_grps_cnt;
>> + dev_grp_map[dev_id].grp_ptr_arr[cnt] = (u64) gptr;
>> + dev_grp_map[dev_id].nest_device_grps_cnt++;
>> +
>> + /*
>> + * Link the device name if not linked already.
>> + * This is needed when creating the device tree.
>> + */
>> + if (!dev_grp_map[dev_id].name)
>> + dev_grp_map[dev_id].name = lookup_table[i].dt_device_name;
> This is the "nest unit name" correct?
>
> BTW, we seem to be discarding the event-group name during this
> processing right? Can we preserve the group name as another
> property of the group's dt-node?
Because just incase if we want to map to catalog?
Will think about it.
>
>> + }
>> + }
>> +}
>> +
>> +static int detect_nest_units(struct dt_node *ima)
>> +{
>> + struct nest_catalog_group_data *group_ptr;
> s/_ptr//?
>
>> + char *marker;
>> + int rc = 0;
>> +
>> + /*
>> + * Scan all available groups in the chip domain from
>> + * the CATALOG and update the nest_catalog_grps_device struct.
> s/struct/table/.
>
>> + * Reason for this 1) Catalog can have multiple groups for a
> s/Reason for this/Note that/
>> + * same nest unit. 2) All the events for a nest unit should end up
> Do we add events or event groups to the nest unit?
We add the all the events to the nest unit.
>
>> + * in the same dt node even though they are placed in different groups.
>> + * ex. Catalog could have groups like "X-link_data" and "X-link_idle",
>> + * but events from both these groups should end up in the device tree
>> + * node of "xbus".
>> + */
>> + marker = CHIP_GROUP_ENTRY(catalog_desc);
>> + group_ptr = (struct nest_catalog_group_data *)marker;
>> + while(group_ptr->domain == DOMAIN_CHIP) {
> Space after 'while'
>> + update_catalog_to_devices(group_ptr);
>> + marker += group_ptr->length;
>> + group_ptr = (struct nest_catalog_group_data *)marker;
>> + };
>> +
>> + return rc;
>> +}
>> +
>> int preload_catalog_lid()
>> {
>> struct proc_chip *chip = get_chip(this_cpu()->chip_id);
>> @@ -177,6 +249,13 @@ void nest_pmu_init(int loaded)
>> dt_add_property_cells(chip_dev, "#size-cells", 1);
>> dt_add_property_cells(chip_dev, "ranges", 0, hi32(addr),
>> lo32(addr), SLW_IMA_SIZE);
>> +
>> + /*
>> + * Now parse catalog and add nest units and their events
> again, adding events or groups to DT?
Will changes it.
>
>
>> + * to the device tree.
>> + */
>> + if (detect_nest_units(chip_dev))
>> + goto fail;
>> }
>>
>> return;
>> diff --git a/include/nest.h b/include/nest.h
>> index a27907fdf62a..b464e5b72c0e 100644
>> --- a/include/nest.h
>> +++ b/include/nest.h
>> @@ -204,6 +204,35 @@ struct nest_catalog_desc {
>> /*Size of Nest Catalog LID (256KBytes) */
> Space after the '*'.
>
>> #define NEST_CATALOG_SIZE 0x40000
>>
>> +/* Max number of groups for a nest units in catalog */
> s/units/unit/
>
>> +#define MAX_GRPS_PER_DEVICE 5
>> +
>> +/*
>> + * If new nest units are added to catalog then append to the enum.
>> + */
>> +enum nest_dt_devices {
> How about "nest_unit_types"?
sure.
>
>> + POWERBUS,
>> + MCS_READ,
>> + MCS_WRITE,
>> + XBUS,
>> + ABUS,
>> + NEST_DT_DEVICE_MAX,
>> +};
>> +
>> +struct lookup_grp_name_to_device_name {
> Rename to 'map_nest_unit_to_dt_node'?
>
>> + char catalog_grp_name[32];
> s/catalog_//
>
>> + char dt_device_name[32];
> dt_node_name?
>
>> + u32 length;
>> + u32 devices_id;
> nest_unit?
>
>> +};
>> +
>> +struct nest_catalog_grps_device {
> As mentioned above, rename to 'map_grp_name_to_dt_name'?
>
>> + char *name;
> nest_unit_name?
>
>> + u64 grp_ptr_arr[MAX_GRPS_PER_DEVICE];
> s/grp_ptr_arr/groups/? or event_groups?
>
>> + u32 nest_device_grps_cnt;
> grp_count?
>
>> + struct dt_node *ptr;
> s/ptr/node/ or dt_node?
>
>> +};
>> +
>> /*
>> * Function prototypes
>> */
>> --
More information about the Skiboot
mailing list