[PATCH linux dev-4.7] drivers/fsi: Adjust slave ID based on address in command send

Christopher Bostic cbostic at linux.vnet.ibm.com
Fri Feb 10 02:00:29 AEDT 2017



On 2/8/17 8:54 PM, Alistair Popple wrote:
> On Thu, 9 Feb 2017 10:48:13 AM Joel Stanley wrote:
>> On Thu, Feb 9, 2017 at 10:03 AM, Christopher Bostic
>> <cbostic at linux.vnet.ibm.com> wrote:
>>> In order to access slave address ranges > 0x1FFFFF the slave ID
>>> must be adjusted accordingly in the command encoding:
>>>
>>> ID 0: 0x00000000 - 0x001FFFFF
>>> ID 1: 0x00200000 - 0x003FFFFF
>>> ID 2: 0x00400000 - 0x005FFFFF
>>> ID 3: 0x00600000 - 0x007FFFFF
>> Alistair and Eddie, can I please get an ack from both of you on this?
>>
>>> Signed-off-by: Christopher Bostic <cbostic at linux.vnet.ibm.com>
>>> ---
>>>   drivers/fsi/fsi-master-gpio.c | 20 ++++++++++++++++----
>>>   1 file changed, 16 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c
>>> index 73d9985..428f3db 100644
>>> --- a/drivers/fsi/fsi-master-gpio.c
>>> +++ b/drivers/fsi/fsi-master-gpio.c
>>> @@ -30,7 +30,9 @@
>>>   #define        FSI_GPIO_CMD_READ       0x0400000000000000ULL
>>>   #define        FSI_GPIO_CMD_SLAVE_MASK 0xC000000000000000ULL
>>>   #define        FSI_GPIO_CMD_ADDR_SHIFT 37
>>> -#define        FSI_GPIO_CMD_ADDR_MASK  0x001FFFFF
>>> +#define        FSI_GPIO_CMD_ADR8_MASK  0x001FFFFF
>>> +#define        FSI_GPIO_CMD_ADR16_MASK 0x001FFFFE
>>> +#define        FSI_GPIO_CMD_ADR32_MASK 0x001FFFFC
>>>   #define        FSI_GPIO_CMD_SLV_SHIFT  62
>>>   #define        FSI_GPIO_CMD_SIZE_16    0x0000001000000000ULL
>>>   #define        FSI_GPIO_CMD_SIZE_32    0x0000003000000000ULL
>>> @@ -40,6 +42,9 @@
>>>   #define        FSI_GPIO_CMD_DFLT_LEN   28
>>>   #define        FSI_GPIO_CMD_CRC_SHIFT  60
>>>
>>> +#define        FSI_SLAVE_SHIFT         21
>>> +#define        FSI_SLAVE_MASK          0x3
>>> +
>>>   /* Bus errors */
>>>   #define        FSI_GPIO_ERR_BUSY       1       /* Slave stuck in busy state */
>>>   #define        FSI_GPIO_RESP_ERRA      2       /* Any (misc) Error */
>>> @@ -301,15 +306,17 @@ static void build_abs_ar_command(struct fsi_gpio_msg *cmd, uint64_t mode,
> Do we need to expose the slave-id outside of this function? Ie. does
> anything currently (or is expected to in future) pass anything other
> than slave=0 to this function? If not we should drop slave-id from the
> function parameters imho.
>
There are cases where the core scan code will need to pass in slave-id 3 
during
link initialization.  Also the core is structured to deal with the 
eventual case
where we may have multiple CFAMs per link so I think it makes sense to
keep it as a parameter.

>>>                  const void *data)
>>>   {
>>>          uint8_t crc;
>>> +       uint32_t addr_mask;
>>>
>>>          cmd->bits = FSI_GPIO_CMD_DFLT_LEN;
>>>          cmd->msg = FSI_GPIO_CMD_DEFAULT;
>>>          cmd->msg |= mode;
>>> -       cmd->msg &= ~FSI_GPIO_CMD_SLAVE_MASK;
>>> +       if (!slave)
>>> +               slave = (addr >> FSI_SLAVE_SHIFT) & FSI_SLAVE_MASK;
>>>          cmd->msg |= (((uint64_t)slave) << FSI_GPIO_CMD_SLV_SHIFT);
>>> -       addr &= FSI_GPIO_CMD_ADDR_MASK;
>>> -       cmd->msg |= (((uint64_t)addr) << FSI_GPIO_CMD_ADDR_SHIFT);
>>> +
>>>          if (size == sizeof(uint8_t)) {
>>> +               addr_mask = FSI_GPIO_CMD_ADR8_MASK;
>>>                  if (data) {
>>>                          uint8_t cmd_data = *((uint8_t *)data);
>>>
>>> @@ -317,6 +324,7 @@ static void build_abs_ar_command(struct fsi_gpio_msg *cmd, uint64_t mode,
>>>                                  ((uint64_t)cmd_data) << FSI_GPIO_CMD_DT8_SHIFT;
>>>                  }
>>>          } else if (size == sizeof(uint16_t)) {
>>> +               addr_mask = FSI_GPIO_CMD_ADR16_MASK;
>>>                  cmd->msg |= FSI_GPIO_CMD_SIZE_16;
>>>                  if (data) {
>>>                          uint16_t cmd_data;
>>> @@ -326,6 +334,7 @@ static void build_abs_ar_command(struct fsi_gpio_msg *cmd, uint64_t mode,
>>>                                  ((uint64_t)cmd_data) << FSI_GPIO_CMD_DT16_SHIFT;
>>>                  }
>>>          } else {
>>> +               addr_mask = FSI_GPIO_CMD_ADR32_MASK;
>>>                  cmd->msg |= FSI_GPIO_CMD_SIZE_32;
>>>                  if (data) {
>>>                          uint32_t cmd_data;
>>> @@ -336,6 +345,9 @@ static void build_abs_ar_command(struct fsi_gpio_msg *cmd, uint64_t mode,
>>>                  }
>>>          }
>>>
>>> +       addr &= addr_mask;
> How is the masking of the address different now that you are setting
> the slave-id? Ie. this change looks more general than just setting the
> slave-id so is it fixing a different probelm? Or is somehow related to
> setting the slave-id?
>
Its not directly related to the slave ID.  I added this to ensure that 
any callers
that request odd alignments, i.e.  32 bit write aligned on address 0xFFFF is
properly masked.

Since it is separate conceptually I'll break this part out into a 
separate patch.

Thanks,
Chris

> Regards,
>
> Alistair
>
>>> +       cmd->msg |= (((uint64_t)addr) << FSI_GPIO_CMD_ADDR_SHIFT);
>>> +
>>>          if (mode == FSI_GPIO_CMD_WRITE)
>>>                  cmd->bits += (8 * size);
>>>
>>> --
>>> 1.8.2.2
>>>



More information about the openbmc mailing list