[PATCHv2 0/3] Lost key-up interrupt handling for omap4-keypad

[PATCHv2 0/3] Lost key-up interrupt handling for omap4-keypad

[Tony Lindgren]

Hi all,

This series updates omap4-keypad to configure the interrupt level and
disables unused long interrupts. And then it implements the missing parts
for the lost key-up interrupt quirk as described in the silicon errata pdf.

I can still reproduce one issue where a fast shift-shift-j can produce an
upper case J instead of j for example. This seems unrelated to the controller
idling with state issue probably, maybe it's some debouncing related issue.
So far playing with the debouncing configuration has not helped with this
issue though. Anyways, please test if you're seeing stuck keys on droid4.

Regards,

Tony


Tony Lindgren (3):
  Input: omap4-keypad - configure interrupt as level
  Input: omap4-keypad - disable unused long interrupts
  Input: omap4-keypad - check state again for lost key-up interrupts

 drivers/input/keyboard/omap4-keypad.c | 64 ++++++++++++++++++++++-----
 1 file changed, 54 insertions(+), 10 deletions(-)

-- 
2.25.1

[PATCH 1/3] Input: omap4-keypad - configure interrupt as level

[Tony Lindgren]

The interrupt should be level high for SoC internal devices.
Otherwise interrupts may not be seen after a wake-up event.

Cc: Arthur Demchenkov <spinal.by@gmail.com>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: ruleh <ruleh@gmx.de>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 drivers/input/keyboard/omap4-keypad.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -344,7 +344,8 @@ static int omap4_keypad_probe(struct platform_device *pdev)
 	}
 
 	error = request_threaded_irq(keypad_data->irq, omap4_keypad_irq_handler,
-				     omap4_keypad_irq_thread_fn, IRQF_ONESHOT,
+				     omap4_keypad_irq_thread_fn,
+				     IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
 				     "omap4-keypad", keypad_data);
 	if (error) {
 		dev_err(&pdev->dev, "failed to register interrupt\n");
-- 
2.25.1

[PATCH 2/3] Input: omap4-keypad - disable unused long interrupts

[Tony Lindgren]

We are not using the long interrupts and they produce extra interrupts.
Let's not enable them at all.

Note that also the v3.0.8 Linux Android kernel has long interrupts
disabled.

Cc: Arthur Demchenkov <spinal.by@gmail.com>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: ruleh <ruleh@gmx.de>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 drivers/input/keyboard/omap4-keypad.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -176,10 +176,9 @@ static int omap4_keypad_open(struct input_dev *input)
 	kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS,
 			 kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS));
 	kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
-			OMAP4_DEF_IRQENABLE_EVENTEN |
-				OMAP4_DEF_IRQENABLE_LONGKEY);
+			OMAP4_DEF_IRQENABLE_EVENTEN);
 	kbd_writel(keypad_data, OMAP4_KBD_WAKEUPENABLE,
-			OMAP4_DEF_WUP_EVENT_ENA | OMAP4_DEF_WUP_LONG_KEY_ENA);
+			OMAP4_DEF_WUP_EVENT_ENA);
 
 	enable_irq(keypad_data->irq);
 
-- 
2.25.1

[PATCH 3/3] Input: omap4-keypad - check state again for lost key-up interrupts

[Tony Lindgren]

We only have partial errata i689 implemented with Commit 6c3516fed7b6
("Input: omap-keypad - fix keyboard debounce configuration"). We are
still missing the check for lost key-up interrupts as described in the
omap4 silicon errata documentation as Errata ID i689 "1.32 Keyboard Key
Up Event Can Be Missed":

"When a key is released for a time shorter than the debounce time,
 in-between 2 key press (KP1 and KP2), the keyboard state machine will go
 to idle mode and will never detect the key release (after KP1, and also
 after KP2), and thus will never generate a new IRQ indicating the key
 release."

Let's check the keyboard state with delayed_work after each event. And
if the problem state is detect, let's clear all events.

Cc: Arthur Demchenkov <spinal.by@gmail.com>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 drivers/input/keyboard/omap4-keypad.c | 56 ++++++++++++++++++++++++---
 1 file changed, 50 insertions(+), 6 deletions(-)

diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -71,6 +71,8 @@ struct omap4_keypad {
 	void __iomem *base;
 	bool irq_wake_enabled;
 	unsigned int irq;
+	struct delayed_work key_work;
+	struct mutex lock;		/* for key scan */
 
 	unsigned int rows;
 	unsigned int cols;
@@ -119,16 +121,22 @@ static irqreturn_t omap4_keypad_irq_handler(int irq, void *dev_id)
 	return IRQ_NONE;
 }
 
-static irqreturn_t omap4_keypad_irq_thread_fn(int irq, void *dev_id)
+static bool omap4_keypad_scan_keys(struct omap4_keypad *keypad_data, bool clear)
 {
-	struct omap4_keypad *keypad_data = dev_id;
 	struct input_dev *input_dev = keypad_data->input;
 	unsigned char key_state[ARRAY_SIZE(keypad_data->key_state)];
 	unsigned int col, row, code, changed;
-	u32 *new_state = (u32 *) key_state;
-
-	*new_state = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
-	*(new_state + 1) = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
+	u32 *rows_lo = (u32 *)key_state;
+	u32 *rows_hi = rows_lo + 1;
+
+	mutex_lock(&keypad_data->lock);
+	if (clear) {
+		*rows_lo = 0;
+		*rows_hi = 0;
+	} else {
+		*rows_lo = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
+		*rows_hi = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
+	}
 
 	for (row = 0; row < keypad_data->rows; row++) {
 		changed = key_state[row] ^ keypad_data->key_state[row];
@@ -151,6 +159,20 @@ static irqreturn_t omap4_keypad_irq_thread_fn(int irq, void *dev_id)
 
 	memcpy(keypad_data->key_state, key_state,
 		sizeof(keypad_data->key_state));
+	mutex_unlock(&keypad_data->lock);
+
+	return *rows_lo || *rows_hi;
+}
+
+static irqreturn_t omap4_keypad_irq_thread_fn(int irq, void *dev_id)
+{
+	struct omap4_keypad *keypad_data = dev_id;
+	bool events;
+
+	events = omap4_keypad_scan_keys(keypad_data, false);
+	if (events)
+		schedule_delayed_work(&keypad_data->key_work,
+				      msecs_to_jiffies(50));
 
 	/* clear pending interrupts */
 	kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS,
@@ -159,6 +181,25 @@ static irqreturn_t omap4_keypad_irq_thread_fn(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+/*
+ * Errata ID i689 "1.32 Keyboard Key Up Event Can Be Missed".
+ * Interrupt may not happen for key-up events.
+ */
+static void omap4_keypad_work(struct work_struct *work)
+{
+	struct omap4_keypad *keypad_data =
+		container_of(work, struct omap4_keypad, key_work.work);
+	bool events;
+	u32 active;
+
+	active = kbd_readl(keypad_data, OMAP4_KBD_STATEMACHINE);
+	if (active)
+		return;
+
+	dev_dbg(keypad_data->input->dev.parent, "idle with events\n");
+	events = omap4_keypad_scan_keys(keypad_data, true);
+}
+
 static int omap4_keypad_open(struct input_dev *input)
 {
 	struct omap4_keypad *keypad_data = input_get_drvdata(input);
@@ -251,6 +292,8 @@ static int omap4_keypad_probe(struct platform_device *pdev)
 	}
 
 	keypad_data->irq = irq;
+	mutex_init(&keypad_data->lock);
+	INIT_DELAYED_WORK(&keypad_data->key_work, omap4_keypad_work);
 
 	error = omap4_keypad_parse_dt(&pdev->dev, keypad_data);
 	if (error)
@@ -387,6 +430,7 @@ static int omap4_keypad_remove(struct platform_device *pdev)
 	struct resource *res;
 
 	free_irq(keypad_data->irq, keypad_data);
+	cancel_delayed_work_sync(&keypad_data->key_work);
 
 	pm_runtime_disable(&pdev->dev);
 
-- 
2.25.1

Re: [PATCH 3/3] Input: omap4-keypad - check state again for lost key-up interrupts

[Dmitry Torokhov]

On Fri, Feb 28, 2020 at 09:12:23AM -0800, Tony Lindgren wrote:
> We only have partial errata i689 implemented with Commit 6c3516fed7b6
> ("Input: omap-keypad - fix keyboard debounce configuration"). We are
> still missing the check for lost key-up interrupts as described in the
> omap4 silicon errata documentation as Errata ID i689 "1.32 Keyboard Key
> Up Event Can Be Missed":
> 
> "When a key is released for a time shorter than the debounce time,
>  in-between 2 key press (KP1 and KP2), the keyboard state machine will go
>  to idle mode and will never detect the key release (after KP1, and also
>  after KP2), and thus will never generate a new IRQ indicating the key
>  release."
> 
> Let's check the keyboard state with delayed_work after each event. And
> if the problem state is detect, let's clear all events.
> 
> Cc: Arthur Demchenkov <spinal.by@gmail.com>
> Cc: Merlijn Wajer <merlijn@wizzup.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sebastian Reichel <sre@kernel.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  drivers/input/keyboard/omap4-keypad.c | 56 ++++++++++++++++++++++++---
>  1 file changed, 50 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> @@ -71,6 +71,8 @@ struct omap4_keypad {
>  	void __iomem *base;
>  	bool irq_wake_enabled;
>  	unsigned int irq;
> +	struct delayed_work key_work;
> +	struct mutex lock;		/* for key scan */

I think having threaded interrupt and delayed work together defeats the
purpose of having threaded interrupt. If you want to add a delay before
repeating scan I think you can add it directly in
omap4_keypad_irq_thread_fn(). Or is there a concern that we will not
rely quickly enough on additional key presses? It is unclear to me if
additional key press within the debounce time will result in additional
interrupt.

Thanks.

-- 
Dmitry

Re: [PATCH 3/3] Input: omap4-keypad - check state again for lost key-up interrupts

[Tony Lindgren]

* Dmitry Torokhov <dmitry.torokhov@gmail.com> [200306 19:11]:
> On Fri, Feb 28, 2020 at 09:12:23AM -0800, Tony Lindgren wrote:
> > We only have partial errata i689 implemented with Commit 6c3516fed7b6
> > ("Input: omap-keypad - fix keyboard debounce configuration"). We are
> > still missing the check for lost key-up interrupts as described in the
> > omap4 silicon errata documentation as Errata ID i689 "1.32 Keyboard Key
> > Up Event Can Be Missed":
> > 
> > "When a key is released for a time shorter than the debounce time,
> >  in-between 2 key press (KP1 and KP2), the keyboard state machine will go
> >  to idle mode and will never detect the key release (after KP1, and also
> >  after KP2), and thus will never generate a new IRQ indicating the key
> >  release."
> > 
> > Let's check the keyboard state with delayed_work after each event. And
> > if the problem state is detect, let's clear all events.
> > 
> > Cc: Arthur Demchenkov <spinal.by@gmail.com>
> > Cc: Merlijn Wajer <merlijn@wizzup.org>
> > Cc: Pavel Machek <pavel@ucw.cz>
> > Cc: Sebastian Reichel <sre@kernel.org>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> >  drivers/input/keyboard/omap4-keypad.c | 56 ++++++++++++++++++++++++---
> >  1 file changed, 50 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
> > --- a/drivers/input/keyboard/omap4-keypad.c
> > +++ b/drivers/input/keyboard/omap4-keypad.c
> > @@ -71,6 +71,8 @@ struct omap4_keypad {
> >  	void __iomem *base;
> >  	bool irq_wake_enabled;
> >  	unsigned int irq;
> > +	struct delayed_work key_work;
> > +	struct mutex lock;		/* for key scan */
> 
> I think having threaded interrupt and delayed work together defeats the
> purpose of having threaded interrupt. If you want to add a delay before
> repeating scan I think you can add it directly in
> omap4_keypad_irq_thread_fn(). Or is there a concern that we will not
> rely quickly enough on additional key presses? It is unclear to me if
> additional key press within the debounce time will result in additional
> interrupt.

Well if we wait in threaded interrupt, we won't see a new interrupt.
So yes, an additional key press will still produce an interrupt.

After a key press has been detected, we need to set a timer that checks
the keyboard controller state after it has idled. Then check for a
potentially stuck state, and clear all down events if the state is
idle with keys down.

I don't think we can really use runtime PM autosuspend delay here as we
already keep the device enabled with clock autogated so there's nothing
to do. If we now added runtime PM calls, we'd end up in mode with
clocks completely disabled. Maybe some tinkering of usage counts in
the interrupt handler would allow using PM runtime though :)

Regards,

Tony

[PATCHv2 4/3] Input: omap4-keypad - scan the keys in two phases to detect lost key-up

[Tony Lindgren]

In addition to handling errata i689 for idle with state, we must also
check for lost key up interrupts on fast key presses.

For example rapidly pressing shift-shift-j can sometimes produce a J
instead of j. Let's fix the issue by scanning the keyboard in two
phases. First we scan for any key up events that we may have missed,
and then we scan for key down events.

Cc: Arthur Demchenkov <spinal.by@gmail.com>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 drivers/input/keyboard/omap4-keypad.c | 48 ++++++++++++++++++---------
 1 file changed, 32 insertions(+), 16 deletions(-)

diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -109,6 +109,34 @@ static void kbd_write_irqreg(struct omap4_keypad *keypad_data,
 		     keypad_data->base + keypad_data->irqreg_offset + offset);
 }
 
+static void omap4_keypad_scan_state(struct omap4_keypad *keypad_data,
+				    unsigned char *key_state,
+				    bool down)
+{
+	struct input_dev *input_dev = keypad_data->input;
+	unsigned int col, row, code, changed;
+	bool key_down;
+
+	for (row = 0; row < keypad_data->rows; row++) {
+		changed = key_state[row] ^ keypad_data->key_state[row];
+		if (!changed)
+			continue;
+
+		for (col = 0; col < keypad_data->cols; col++) {
+			if (changed & (1 << col)) {
+				code = MATRIX_SCAN_CODE(row, col,
+						keypad_data->row_shift);
+				key_down = key_state[row] & (1 << col);
+				if (key_down != down)
+					continue;
+				input_event(input_dev, EV_MSC, MSC_SCAN, code);
+				input_report_key(input_dev,
+						 keypad_data->keymap[code],
+						 key_down);
+			}
+		}
+	}
+}
 
 /* Interrupt handlers */
 static irqreturn_t omap4_keypad_irq_handler(int irq, void *dev_id)
@@ -125,7 +153,6 @@ static bool omap4_keypad_scan_keys(struct omap4_keypad *keypad_data, bool clear)
 {
 	struct input_dev *input_dev = keypad_data->input;
 	unsigned char key_state[ARRAY_SIZE(keypad_data->key_state)];
-	unsigned int col, row, code, changed;
 	u32 *rows_lo = (u32 *)key_state;
 	u32 *rows_hi = rows_lo + 1;
 
@@ -138,22 +165,11 @@ static bool omap4_keypad_scan_keys(struct omap4_keypad *keypad_data, bool clear)
 		*rows_hi = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
 	}
 
-	for (row = 0; row < keypad_data->rows; row++) {
-		changed = key_state[row] ^ keypad_data->key_state[row];
-		if (!changed)
-			continue;
+	/* Scan for key up evetns for lost key-up interrupts */
+	omap4_keypad_scan_state(keypad_data, key_state, false);
 
-		for (col = 0; col < keypad_data->cols; col++) {
-			if (changed & (1 << col)) {
-				code = MATRIX_SCAN_CODE(row, col,
-						keypad_data->row_shift);
-				input_event(input_dev, EV_MSC, MSC_SCAN, code);
-				input_report_key(input_dev,
-						 keypad_data->keymap[code],
-						 key_state[row] & (1 << col));
-			}
-		}
-	}
+	/* Scan for key down events */
+	omap4_keypad_scan_state(keypad_data, key_state, true);
 
 	input_sync(input_dev);
 
-- 
2.25.1

Re: [PATCHv2 4/3] Input: omap4-keypad - scan the keys in two phases to detect lost key-up

[Dmitry Torokhov]

On Fri, Feb 28, 2020 at 10:02:43AM -0800, Tony Lindgren wrote:
> In addition to handling errata i689 for idle with state, we must also
> check for lost key up interrupts on fast key presses.
> 
> For example rapidly pressing shift-shift-j can sometimes produce a J
> instead of j. Let's fix the issue by scanning the keyboard in two
> phases. First we scan for any key up events that we may have missed,
> and then we scan for key down events.
> 
> Cc: Arthur Demchenkov <spinal.by@gmail.com>
> Cc: Merlijn Wajer <merlijn@wizzup.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sebastian Reichel <sre@kernel.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  drivers/input/keyboard/omap4-keypad.c | 48 ++++++++++++++++++---------
>  1 file changed, 32 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> @@ -109,6 +109,34 @@ static void kbd_write_irqreg(struct omap4_keypad *keypad_data,
>  		     keypad_data->base + keypad_data->irqreg_offset + offset);
>  }
>  
> +static void omap4_keypad_scan_state(struct omap4_keypad *keypad_data,
> +				    unsigned char *key_state,
> +				    bool down)
> +{
> +	struct input_dev *input_dev = keypad_data->input;
> +	unsigned int col, row, code, changed;
> +	bool key_down;
> +
> +	for (row = 0; row < keypad_data->rows; row++) {
> +		changed = key_state[row] ^ keypad_data->key_state[row];
> +		if (!changed)
> +			continue;
> +
> +		for (col = 0; col < keypad_data->cols; col++) {
> +			if (changed & (1 << col)) {


Looking at all too this, key state is 64 bit value, so if we make it a
bitmap and use "for_each_set_bit()" we can simplify this scanning code.

Thanks.

-- 
Dmitry

Re: [PATCHv2 4/3] Input: omap4-keypad - scan the keys in two phases to detect lost key-up

[Tony Lindgren]

* Dmitry Torokhov <dmitry.torokhov@gmail.com> [200306 19:05]:
> On Fri, Feb 28, 2020 at 10:02:43AM -0800, Tony Lindgren wrote:
> > In addition to handling errata i689 for idle with state, we must also
> > check for lost key up interrupts on fast key presses.
> > 
> > For example rapidly pressing shift-shift-j can sometimes produce a J
> > instead of j. Let's fix the issue by scanning the keyboard in two
> > phases. First we scan for any key up events that we may have missed,
> > and then we scan for key down events.
> > 
> > Cc: Arthur Demchenkov <spinal.by@gmail.com>
> > Cc: Merlijn Wajer <merlijn@wizzup.org>
> > Cc: Pavel Machek <pavel@ucw.cz>
> > Cc: Sebastian Reichel <sre@kernel.org>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> >  drivers/input/keyboard/omap4-keypad.c | 48 ++++++++++++++++++---------
> >  1 file changed, 32 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
> > --- a/drivers/input/keyboard/omap4-keypad.c
> > +++ b/drivers/input/keyboard/omap4-keypad.c
> > @@ -109,6 +109,34 @@ static void kbd_write_irqreg(struct omap4_keypad *keypad_data,
> >  		     keypad_data->base + keypad_data->irqreg_offset + offset);
> >  }
> >  
> > +static void omap4_keypad_scan_state(struct omap4_keypad *keypad_data,
> > +				    unsigned char *key_state,
> > +				    bool down)
> > +{
> > +	struct input_dev *input_dev = keypad_data->input;
> > +	unsigned int col, row, code, changed;
> > +	bool key_down;
> > +
> > +	for (row = 0; row < keypad_data->rows; row++) {
> > +		changed = key_state[row] ^ keypad_data->key_state[row];
> > +		if (!changed)
> > +			continue;
> > +
> > +		for (col = 0; col < keypad_data->cols; col++) {
> > +			if (changed & (1 << col)) {
> 
> 
> Looking at all too this, key state is 64 bit value, so if we make it a
> bitmap and use "for_each_set_bit()" we can simplify this scanning code.

OK good idea, I'll take a look.

Regards,

Tony

Re: [PATCHv2 0/3] Lost key-up interrupt handling for omap4-keypad

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [200228 17:13]:
> I can still reproduce one issue where a fast shift-shift-j can produce an
> upper case J instead of j for example. This seems unrelated to the controller
> idling with state issue probably, maybe it's some debouncing related issue.
> So far playing with the debouncing configuration has not helped with this
> issue though. Anyways, please test if you're seeing stuck keys on droid4.

Oh so turns out this can be dealt with by first scanning for any lost
key-up events. I just sent out patch 4/3 to this series to fix that.

Regards,

Tony