Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus
On Thu, Aug 17, 2017 at 11:09 AM, Russell King - ARM Linux wrote: > On Fri, Aug 11, 2017 at 11:16:20AM +0200, Linus Walleij wrote: >> writel() should be guaranteeing that the values hit the hardware, wmb() is >> spelled out "write memory barrier" I don't see what you're after here. > > Incorrect. writel() has a barrier which ensures that data written to > memory (eg, dma coherent memory) is visible to the hardware prior to > the write hitting the hardware. > > There is no barrier to ensure that the write hits the hardware in a > timely manner - the write can be buffered by the buses, which will > delay it before it hits its destination. > > PCI particularly buffers MMIO writes, and the requirement there has > always been that if you need the write to hit the hardware in a timely > fashion, you must perform a read-back to force the bus to deliver the > write (since a read is not allowed to overlap a write.) > > The solution is never to use barrier() - barrier() is a _compiler_ > barrier and does nothing for posted writes on hardware buses. Thanks Russell. I tend to forget things over time even though I have some memory of this being spelled out to me in the past :( Yours, Linus Walleij
Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus
On 2017-08-17 15:01, Russell King - ARM Linux wrote: On Thu, Aug 17, 2017 at 12:51:33PM +0200, Danilo Krummrich wrote: That having the correct execution order is not enough on some buses because of buffering is really something to be aware of, thanks again for pointing this out. PCI guarantees the order of writes to a device, but there are situations on SoCs where you can't rely on that - for instance, if the writes go over different buses to different devices (eg, write to a peripheral vs write to an interrupt controller.) Even then, with interrupts delivered by message (eg, MSI) there's issues. So for the scenario I was concerned about I would expect the irqchip driver guarantees the write actually hits the the hardware (if necessary read it back) before the function (disable_irq_nosync()) returns, is that correct? Though, having the need should be very unlikely. Well, disable_irq_nosync() doesn't guarantee that the interrupt handler isn't running - a CPU may have just received the interrupt and is just entering the interrupt handler when disable_irq_nosync() returns. The hint is the "nosync" - there's no synchronisation. If you need to guarantee that the interrupt handler is not running, disable_irq() does that. By implication, however, disable_irq() can not be called from within the same interrupt handler for the interrupt that is being disabled. Thanks again, I'm aware of that. As in my case the code could be called from atomic context disable_irq() is not an option. My main point is if it can be assumed that after disable_irq_nosync() returns it is guaranteed, by convention, that the hardware was hit. But I really would think so.
Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus
On Thu, Aug 17, 2017 at 12:51:33PM +0200, Danilo Krummrich wrote: > That having the correct execution order is not enough on some buses because > of buffering is really something to be aware of, thanks again for pointing > this out. PCI guarantees the order of writes to a device, but there are situations on SoCs where you can't rely on that - for instance, if the writes go over different buses to different devices (eg, write to a peripheral vs write to an interrupt controller.) Even then, with interrupts delivered by message (eg, MSI) there's issues. > So for the scenario I was concerned about I would expect the irqchip driver > guarantees the write actually hits the the hardware (if necessary read it > back) before the function (disable_irq_nosync()) returns, is that correct? > Though, having the need should be very unlikely. Well, disable_irq_nosync() doesn't guarantee that the interrupt handler isn't running - a CPU may have just received the interrupt and is just entering the interrupt handler when disable_irq_nosync() returns. The hint is the "nosync" - there's no synchronisation. If you need to guarantee that the interrupt handler is not running, disable_irq() does that. By implication, however, disable_irq() can not be called from within the same interrupt handler for the interrupt that is being disabled. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus
On 2017-08-17 11:09, Russell King - ARM Linux wrote: On Fri, Aug 11, 2017 at 11:16:20AM +0200, Linus Walleij wrote: writel() should be guaranteeing that the values hit the hardware, wmb() is spelled out "write memory barrier" I don't see what you're after here. Incorrect. writel() has a barrier which ensures that data written to memory (eg, dma coherent memory) is visible to the hardware prior to the write hitting the hardware. There is no barrier to ensure that the write hits the hardware in a timely manner - the write can be buffered by the buses, which will delay it before it hits its destination. PCI particularly buffers MMIO writes, and the requirement there has always been that if you need the write to hit the hardware in a timely fashion, you must perform a read-back to force the bus to deliver the write (since a read is not allowed to overlap a write.) The solution is never to use barrier() - barrier() is a _compiler_ barrier and does nothing for posted writes on hardware buses. Thanks for clarification. I thought I just need a wmb() to make sure writel() can not be reordered with another store operation. I wasn't aware that writel() is defined to guarantee this on every arch. That having the correct execution order is not enough on some buses because of buffering is really something to be aware of, thanks again for pointing this out. So for the scenario I was concerned about I would expect the irqchip driver guarantees the write actually hits the the hardware (if necessary read it back) before the function (disable_irq_nosync()) returns, is that correct? Though, having the need should be very unlikely.
Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus
On Fri, Aug 11, 2017 at 11:16:20AM +0200, Linus Walleij wrote: > writel() should be guaranteeing that the values hit the hardware, wmb() is > spelled out "write memory barrier" I don't see what you're after here. Incorrect. writel() has a barrier which ensures that data written to memory (eg, dma coherent memory) is visible to the hardware prior to the write hitting the hardware. There is no barrier to ensure that the write hits the hardware in a timely manner - the write can be buffered by the buses, which will delay it before it hits its destination. PCI particularly buffers MMIO writes, and the requirement there has always been that if you need the write to hit the hardware in a timely fashion, you must perform a read-back to force the bus to deliver the write (since a read is not allowed to overlap a write.) The solution is never to use barrier() - barrier() is a _compiler_ barrier and does nothing for posted writes on hardware buses. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus
On 2017-08-11 11:16, Linus Walleij wrote:
On Thu, Aug 10, 2017 at 4:38 PM, Danilo Krummrich
wrote:
On 2017-08-07 18:22, Danilo Krummrich wrote:
> +static int ps2_gpio_write(struct serio *serio, unsigned char val)
> +{
> + struct ps2_gpio_data *drvdata = serio->port_data;
> +
> + drvdata->mode = PS2_MODE_TX;
> + drvdata->tx_byte = val;
> + /* Make sure ISR running on other CPU notice changes. */
> + barrier();
This seems overengineered, is this really needed?
If we have races like this, the error is likely elsewhere, and
should be
fixed in the GPIO driver MMIO access or so.
Yes, seems it can be removed. I didn't saw any explicit barriers in
the
GPIO
driver (I'm testing on bcm2835), but it seems MMIO operations on SMP
archs
does contain barriers. Not sure if all do. If some do not this
barrier
might
be needed to ensure ISR on other CPU notice the correct mode and byte
to
send.
I couldn't find any guarantee that the mode and tx_byte change is
implicitly
covered by a barrier in this case. E.g. the bcm2835 driver does not
make
sure stores are completed before the particular interrupt is enabled,
except by
the fact that writel on ARM contains a wmb(). But this is nothing to
rely on.
(Please tell me if I miss something.)
writel() should be guaranteeing that the values hit the hardware, wmb()
is
spelled out "write memory barrier" I don't see what you're after here.
Sorry for confusing wording. What I actually meant is if writel() is
guaranteed
to make sure there's no reordering happening with other store
operations. Of
course, in case of ARM it is sufficient as it contains a wmb. But I
wasn't aware
that all writel() implementations guarantee this (if needed).
Thanks for clarification.
If you think writel() doesn't do its job on some platform, then fix
writel()
on that platform.
We can't randomly sprinkle things like this all over the kernel it
makes
no sense.
Therefore I would like to keep this barrier and replace it with
smp_wmb() if
you are fine with that.
I do not think this is proper.
As you explained writel() should guarantee no reordering with other
store operations
(like drvdata->mode = PS2_MODE_TX in my case) is happening, I totally
agree and will
fix this.
Yours,
Linus Walleij
Thanks,
Danilo
Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus
On Thu, Aug 10, 2017 at 4:38 PM, Danilo Krummrich
wrote:
> On 2017-08-07 18:22, Danilo Krummrich wrote:
>>>
>>> > +static int ps2_gpio_write(struct serio *serio, unsigned char val)
>>> > +{
>>> > + struct ps2_gpio_data *drvdata = serio->port_data;
>>> > +
>>> > + drvdata->mode = PS2_MODE_TX;
>>> > + drvdata->tx_byte = val;
>>> > + /* Make sure ISR running on other CPU notice changes. */
>>> > + barrier();
>>>
>>> This seems overengineered, is this really needed?
>>>
>>> If we have races like this, the error is likely elsewhere, and should be
>>> fixed in the GPIO driver MMIO access or so.
>>>
>> Yes, seems it can be removed. I didn't saw any explicit barriers in the
>> GPIO
>> driver (I'm testing on bcm2835), but it seems MMIO operations on SMP archs
>> does contain barriers. Not sure if all do. If some do not this barrier
>> might
>> be needed to ensure ISR on other CPU notice the correct mode and byte to
>> send.
>>
> I couldn't find any guarantee that the mode and tx_byte change is implicitly
> covered by a barrier in this case. E.g. the bcm2835 driver does not make
> sure stores are completed before the particular interrupt is enabled, except
> by
> the fact that writel on ARM contains a wmb(). But this is nothing to rely on.
> (Please tell me if I miss something.)
writel() should be guaranteeing that the values hit the hardware, wmb() is
spelled out "write memory barrier" I don't see what you're after here.
If you think writel() doesn't do its job on some platform, then fix writel()
on that platform.
We can't randomly sprinkle things like this all over the kernel it makes
no sense.
> Therefore I would like to keep this barrier and replace it with smp_wmb() if
> you are fine with that.
I do not think this is proper.
Yours,
Linus Walleij
Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus
Hi Linus,
On 2017-08-07 18:22, Danilo Krummrich wrote:
> +static int ps2_gpio_write(struct serio *serio, unsigned char val)
> +{
> + struct ps2_gpio_data *drvdata = serio->port_data;
> +
> + drvdata->mode = PS2_MODE_TX;
> + drvdata->tx_byte = val;
> + /* Make sure ISR running on other CPU notice changes. */
> + barrier();
This seems overengineered, is this really needed?
If we have races like this, the error is likely elsewhere, and should
be
fixed in the GPIO driver MMIO access or so.
Yes, seems it can be removed. I didn't saw any explicit barriers in the
GPIO
driver (I'm testing on bcm2835), but it seems MMIO operations on SMP
archs
does contain barriers. Not sure if all do. If some do not this barrier
might
be needed to ensure ISR on other CPU notice the correct mode and byte
to send.
I couldn't find any guarantee that the mode and tx_byte change is
implicitly
covered by a barrier in this case. E.g. the bcm2835 driver does not make
sure
stores are completed before the particular interrupt is enabled, except
by the
fact that writel on ARM contains a wmb(). But this is nothing to rely
on. (Please
tell me if I miss something.)
Therefore I would like to keep this barrier and replace it with
smp_wmb() if you
are fine with that.
Regards,
Danilo
Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus
On Mon, Aug 07, 2017 at 11:03:53AM +0200, Linus Walleij wrote: > On Tue, Aug 1, 2017 at 12:24 AM, Danilo Krummrich > wrote: > > > +config SERIO_GPIO_PS2 > > + tristate "GPIO PS/2 bit banging driver" > > + help > > + Say Y here if you want PS/2 bit banging support via GPIO. > > + > > + To compile this driver as a module, choose M here: the > > + module will be called gpio-ps2. > > + > > + If you are unsure, say N. > > As mentioned > > depends on GPIOLIB > depends on OF I do not think this driver has to depend on OF. It should use gpiod and generic device properties. Thanks. -- Dmitry
Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus
Hi Linus,
thanks for reviewing. Commented the ones which still holds.
On Mon, 7 Aug 2017 11:03:53 +0200
Linus Walleij wrote:
> On Tue, Aug 1, 2017 at 12:24 AM, Danilo Krummrich
> wrote:
>
>
> When you add DT bindings you have to CC devicet...@vger.kernel.org
>
I will do prospectively.
> > +#include
>
> Use only:
>
> #include
>
Done in v6.
> > +#include
>
> Should not be needed.
>
>
Removed in v6.
> > +static int ps2_gpio_write(struct serio *serio, unsigned char val)
> > +{
> > + struct ps2_gpio_data *drvdata = serio->port_data;
> > +
> > + drvdata->mode = PS2_MODE_TX;
> > + drvdata->tx_byte = val;
> > + /* Make sure ISR running on other CPU notice changes. */
> > + barrier();
>
> This seems overengineered, is this really needed?
>
> If we have races like this, the error is likely elsewhere, and should be
> fixed in the GPIO driver MMIO access or so.
>
Yes, seems it can be removed. I didn't saw any explicit barriers in the GPIO
driver (I'm testing on bcm2835), but it seems MMIO operations on SMP archs
does contain barriers. Not sure if all do. If some do not this barrier might
be needed to ensure ISR on other CPU notice the correct mode and byte to send.
--
Danilo Krummrich
Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus
On Tue, Aug 1, 2017 at 12:24 AM, Danilo Krummrich
wrote:
> This driver provides PS2 serio bus support by implementing bit banging
> with the GPIO API. The GPIO pins, data and clock, can be configured with
> a node in the device tree or by static platform data.
>
> Writing to a device is supported as well, though it is not recommended as
> the timings to be halt given by libps2 are very tough and difficult to
> reach with bit banging. Therefore it can be configured (also in DT and
> pdata) whether the serio write function should be available for clients.
>
> This driver is for development purposes and not for productive use.
> However, this driver can be useful e.g. when no USB port is available or
> using old peripherals is desired as PS2 controllers getting rare.
>
> This driver was tested on a RPI1 and on Hikey960 and it worked well
> together with the atkbd driver.
>
> Signed-off-by: Danilo Krummrich
> +++ b/Documentation/devicetree/bindings/serio/ps2-gpio.txt
When you add DT bindings you have to CC devicet...@vger.kernel.org
> @@ -0,0 +1,20 @@
> +Device-Tree bindings for ps2 gpio driver
> +
> +Required properties:
> + - compatible = "ps2-gpio";
> + - gpios: data and clock gpio
> +
> +Optional properties:
> + - ps2-gpio,write-enable: Indicates whether write function is provided
> + to serio device. Most probably providing the write fn will not work,
> + because of the tough timing libps2 requires.
> +
> +Example nodes:
> +
> +ps2@0 {
> + compatible = "ps2-gpio";
> + gpios = <&gpio 24 0 /* data */
> +&gpio 23 0 /* clock */
> + >;
> + i2c-gpio,write-enable = <0>;
> +};
These look fine to me though.
> diff --git a/Documentation/gpio/drivers-on-gpio.txt
> b/Documentation/gpio/drivers-on-gpio.txt
Thanks for patching this!
> +config SERIO_GPIO_PS2
> + tristate "GPIO PS/2 bit banging driver"
> + help
> + Say Y here if you want PS/2 bit banging support via GPIO.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called gpio-ps2.
> +
> + If you are unsure, say N.
As mentioned
depends on GPIOLIB
depends on OF
> +#include
Use only:
#include
> +#include
Should not be needed.
> +struct ps2_gpio_data {
> + struct device *dev;
> + struct serio *serio;
> + unsigned char mode;
> + unsigned int gpio_clk;
> + unsigned int gpio_data;
> + unsigned int write_enable;
Do not use the global GPIO number space, use GPIO descriptors.
Example:
drivers/input/keyboard/gpio_keys.c
> +static int ps2_gpio_write(struct serio *serio, unsigned char val)
> +{
> + struct ps2_gpio_data *drvdata = serio->port_data;
> +
> + drvdata->mode = PS2_MODE_TX;
> + drvdata->tx_byte = val;
> + /* Make sure ISR running on other CPU notice changes. */
> + barrier();
This seems overengineered, is this really needed?
If we have races like this, the error is likely elsewhere, and should be
fixed in the GPIO driver MMIO access or so.
> + disable_irq_nosync(drvdata->irq);
> + gpio_direction_output(drvdata->gpio_clk, 0);
No use GPIO descriptors please.
> + // dev_info(drvdata->dev, "recv bit %u: %u\n", cnt, data);
Delete comments or convert to dev_dbg()
> +static int of_ps2_gpio_get_props(struct device *dev,
> +struct ps2_gpio_data *drvdata)
> +{
> + if (of_gpio_count(dev->of_node) < 2)
> + return -ENODEV;
> +
> + drvdata->gpio_data = of_get_gpio(dev->of_node, 0);
> + drvdata->gpio_clk = of_get_gpio(dev->of_node, 1);
> +
> + if (drvdata->gpio_data == -EPROBE_DEFER ||
> + drvdata->gpio_clk == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
> + if (!gpio_is_valid(drvdata->gpio_data) ||
> + !gpio_is_valid(drvdata->gpio_clk)) {
> + dev_err(dev, "invalid GPIOs, data=%d, clk=%d\n",
> + drvdata->gpio_data, drvdata->gpio_clk);
> + return -ENODEV;
> + }
With GPIO descriptors you should just gpiod_get(dev, "foo", FLAG);
No need to poke around in the device tree like this.
Error checks and deferrals apply as usual though.
> + error = devm_gpio_request(dev, drvdata->gpio_clk, "ps2 clk");
> + if (error) {
> + dev_err(dev, "failed to request gpio %u: %d",
> + drvdata->gpio_clk, error);
> + goto err_free_serio;
> + }
> +
> + error = devm_gpio_request(dev, drvdata->gpio_data, "ps2 data");
> + if (error) {
> + dev_err(dev, "failed to request gpio %u: %d",
> + drvdata->gpio_data, error);
> + goto err_free_serio;
> + }
So devm_gpiod_get(...)
> + gpio_direction_input(drvdata->gpio_clk);
> + gpio_direction_input(drvdata->gpio_data);
And incidentallt then you can just specify GPIOD_IN as flag
