[PATCH linux dev-4.10] drivers/fsi: Break and set pin states on GPIO master remove

[PATCH linux dev-4.10] drivers/fsi: Break and set pin states on GPIO master remove

[Christopher Bostic]

Update GPIO remove behavior to match dev-4.7.

On gpio remove: Send a break
		clock, translator, mux = 0
		data, enable = 1

Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com>
---
 drivers/fsi/fsi-master-gpio.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c
index 2a6a812..47eaf61 100644
--- a/drivers/fsi/fsi-master-gpio.c
+++ b/drivers/fsi/fsi-master-gpio.c
@@ -585,17 +585,23 @@ static int fsi_master_gpio_probe(struct platform_device *pdev)
 	return 0;
 }
 
-
 static int fsi_master_gpio_remove(struct platform_device *pdev)
 {
 	struct fsi_master_gpio *master = platform_get_drvdata(pdev);
 
+	fsi_master_gpio_break(&master->master, 0);
+
+	gpiod_set_value(master->gpio_clk, 0);
 	devm_gpiod_put(&pdev->dev, master->gpio_clk);
+	gpiod_set_value(master->gpio_data, 1);
 	devm_gpiod_put(&pdev->dev, master->gpio_data);
+	gpiod_set_value(master->gpio_trans, 0);
 	if (master->gpio_trans)
 		devm_gpiod_put(&pdev->dev, master->gpio_trans);
+	gpiod_set_value(master->gpio_enable, 1);
 	if (master->gpio_enable)
 		devm_gpiod_put(&pdev->dev, master->gpio_enable);
+	gpiod_set_value(master->gpio_mux, 0);
 	if (master->gpio_mux)
 		devm_gpiod_put(&pdev->dev, master->gpio_mux);
 	fsi_master_unregister(&master->master);
-- 
1.8.2.2

Re: [PATCH linux dev-4.10] drivers/fsi: Break and set pin states on GPIO master remove

[Jeremy Kerr]

Hi Chris,

> Update GPIO remove behavior to match dev-4.7.
> 
> On gpio remove: Send a break
> 		clock, translator, mux = 0
> 		data, enable = 1

While this change itself seems okay (leaving GPIOs in a defined state),
I'm concerned about *why* we need this.

If there is other code that need GPIOs in a certain state, then that
code should be doing the required init itself.

Could you add a comment on why this is required?

Cheers,


Jeremy

Re: [PATCH linux dev-4.10] drivers/fsi: Break and set pin states on GPIO master remove

[Christopher Bostic]

On 6/6/17 10:22 PM, Jeremy Kerr wrote:
> Hi Chris,
>
>> Update GPIO remove behavior to match dev-4.7.
>>
>> On gpio remove: Send a break
>> 		clock, translator, mux = 0
>> 		data, enable = 1
> While this change itself seems okay (leaving GPIOs in a defined state),
> I'm concerned about *why* we need this.
>
> If there is other code that need GPIOs in a certain state, then that
> code should be doing the required init itself.
Hi Jeremy,

The pins are set here mainly for the benefit of the Cronus debug 
tools.   Its common practice in test and bringup labs to switch back and 
forth between BMC and FSP-2 with Cronus to access the host processor 
CFAMs over FSI.  Without the remove pin state changes Cronus cannot access.

Cronus is a user space layer and presently doesn't modify gpio directly 
in this situation.   It could do this work I suppose but all designers 
involved will need to come to an agreement as to which is the proper 
approach.

Thanks,
Chris

> Could you add a comment on why this is required?
>
> Cheers,
>
>
> Jeremy
>

Re: [PATCH linux dev-4.10] drivers/fsi: Break and set pin states on GPIO master remove

[Alistair Popple]

On Wed, 7 Jun 2017 08:55:45 AM Christopher Bostic wrote:
> 
> On 6/6/17 10:22 PM, Jeremy Kerr wrote:
> > Hi Chris,
> >
> >> Update GPIO remove behavior to match dev-4.7.
> >>
> >> On gpio remove: Send a break
> >> 		clock, translator, mux = 0
> >> 		data, enable = 1
> > While this change itself seems okay (leaving GPIOs in a defined state),
> > I'm concerned about *why* we need this.
> >
> > If there is other code that need GPIOs in a certain state, then that
> > code should be doing the required init itself.
> Hi Jeremy,
> 
> The pins are set here mainly for the benefit of the Cronus debug 
> tools.   Its common practice in test and bringup labs to switch back and 
> forth between BMC and FSP-2 with Cronus to access the host processor 
> CFAMs over FSI.  Without the remove pin state changes Cronus cannot access.

As far as I know you have to run "systemctl start fsi-disable.service" to switch
over to Cronus mode. I think Jeremy's point is that it should be that service
which explicitly sets up the hardware in a suitable mode rather than relying on
side-effects from removing the kernel driver.

- Alistair

> Cronus is a user space layer and presently doesn't modify gpio directly 
> in this situation.   It could do this work I suppose but all designers 
> involved will need to come to an agreement as to which is the proper 
> approach.
> 
> Thanks,
> Chris
> 
> > Could you add a comment on why this is required?
> >
> > Cheers,
> >
> >
> > Jeremy
> >
> 

Re: [PATCH linux dev-4.10] drivers/fsi: Break and set pin states on GPIO master remove

[Jeremy Kerr]

Hi Alistair & Chris,

>> The pins are set here mainly for the benefit of the Cronus debug 
>> tools.   Its common practice in test and bringup labs to switch back and 
>> forth between BMC and FSP-2 with Cronus to access the host processor 
>> CFAMs over FSI.  Without the remove pin state changes Cronus cannot access.
> 
> As far as I know you have to run "systemctl start fsi-disable.service"
> to switch over to Cronus mode. I think Jeremy's point is that it
> should be that service which explicitly sets up the hardware in a
> suitable mode rather than relying on side-effects from removing the
> kernel driver.

Yep, spot on.

Also, those side-effects might not be how the GPIOs need to configured
for the next usage of the FSI bus (which could be Cronus, but could also
be any other tool). So, let those tools handle the init correctly,
rather than the kernel making a guess at it.

Cheers,


Jeremy

Re: [PATCH linux dev-4.10] drivers/fsi: Break and set pin states on GPIO master remove

[Andrew Geissler]

I think we had this same discussion last time Chris put this on the
mailing list for 4.7 :)   I think we can do better here but we also
(as usual) have a big time crunch.  Can we agree to put this in for
now since our main goal is to just get 4.10 merged and of equal (or
better) function to 4.7?  Chris can create an issue to come up with a
final solution?  Without this change, cronus via the FSP debug does
not work, which is a non-starter for picking this release up by IBM
(and a lot of partners).

I know, in theory, this is easy to fix, but it will require new
testing, potentially new documentation for our users, and is just
adding new function when we're mostly looking to just get a stable
base going.

Andrew

On Thu, Jun 8, 2017 at 5:00 AM, Jeremy Kerr <jk@ozlabs.org> wrote:
> Hi Alistair & Chris,
>
>>> The pins are set here mainly for the benefit of the Cronus debug
>>> tools.   Its common practice in test and bringup labs to switch back and
>>> forth between BMC and FSP-2 with Cronus to access the host processor
>>> CFAMs over FSI.  Without the remove pin state changes Cronus cannot access.
>>
>> As far as I know you have to run "systemctl start fsi-disable.service"
>> to switch over to Cronus mode. I think Jeremy's point is that it
>> should be that service which explicitly sets up the hardware in a
>> suitable mode rather than relying on side-effects from removing the
>> kernel driver.
>
> Yep, spot on.
>
> Also, those side-effects might not be how the GPIOs need to configured
> for the next usage of the FSI bus (which could be Cronus, but could also
> be any other tool). So, let those tools handle the init correctly,
> rather than the kernel making a guess at it.
>
> Cheers,
>
>
> Jeremy

Re: [PATCH linux dev-4.10] drivers/fsi: Break and set pin states on GPIO master remove

[Milton Miller II]

Around 06/21/2017, Andrew Geissler wrote:
>I think we had this same discussion last time Chris put this on the
>mailing list for 4.7 :)   I think we can do better here but we also
>(as usual) have a big time crunch.  Can we agree to put this in for
>now since our main goal is to just get 4.10 merged and of equal (or
>better) function to 4.7?  Chris can create an issue to come up with a
>final solution?  Without this change, cronus via the FSP debug does
>not work, which is a non-starter for picking this release up by IBM
>(and a lot of partners).
>
>I know, in theory, this is easy to fix, but it will require new
>testing, potentially new documentation for our users, and is just
>adding new function when we're mostly looking to just get a stable
>base going.
>
>Andrew
>
>On Thu, Jun 8, 2017 at 5:00 AM, Jeremy Kerr <jk@ozlabs.org> wrote:
>> Hi Alistair & Chris,
>>
>>>> The pins are set here mainly for the benefit of the Cronus debug
>>>> tools.   Its common practice in test and bringup labs to switch
>back and
>>>> forth between BMC and FSP-2 with Cronus to access the host
>processor
>>>> CFAMs over FSI.  Without the remove pin state changes Cronus
>cannot access.
>>>
>>> As far as I know you have to run "systemctl start
>fsi-disable.service"
>>> to switch over to Cronus mode. I think Jeremy's point is that it
>>> should be that service which explicitly sets up the hardware in a
>>> suitable mode rather than relying on side-effects from removing
>the
>>> kernel driver.
>>
>> Yep, spot on.
>>
>> Also, those side-effects might not be how the GPIOs need to
>configured
>> for the next usage of the FSI bus (which could be Cronus, but could
>also
>> be any other tool). So, let those tools handle the init correctly,
>> rather than the kernel making a guess at it.
>>

Actually I think there are well defined "Idle" states and I would expect 
those to be asserted.

I would expect the gpios to be set such that changing the mux does not 
glitch the signals to the chip.

Is this the state that is being set in the patch?

milton

[catching up after vacation]