New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 917153 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

Grabbiter ATL devices require CQ allocation

Project Member Reported by stevenh@google.com, Dec 20

Issue description

b/120502397 informs the following:

"To enable CQ testing can only be done with the blessing of TPMs and (device owner can file a ticket at go/cros-infra-bug and request the CQ allocation) .  We will assign the DUTs to pool:suites for now and once CQ is enabled then CrOS Infra team can perform the DUT reallocation."


 
Summary: Grabbiter ATL devices require CQ allocation (was: Orbatrix ATL devices require CQ allocation)
Change issue title to match allocation in ATL.
Cc: bhthompson@google.com
Is Grabbiter the device from GLK we want to represent all of GLK?

In general we only need one representative in the CQ for a given SOC family, and it tends to be whatever one is most common or easily obtained, or available earliest. To some extend this choice should be driven by the reference design owners.

From a deployment perspective, we just need to ensure we have sufficient additional devices allocated to support the CQ pool. 

Actually turning on the CQ for these is a matter of two CLs on chromite, one to add them (to verify they work) and one to make them important (so they actually block bad CLs).
Cc: kblairh@google.com vineeths@google.com
+ Vineeth, + Blair to provide guidance on CQ allocation for Octopus devices.
@Bernie - we are using Phaser360 as our "lead." If you need extra devices to allocate, grabbiter is almost the same as phaser360, just a different ODM/OEM.
I think either would be fine as long as it has the superset of the features, so I would say whatever device we think we can easily get the extra allocation for.

Sign in to add a comment