mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Zubair Lutfullah <zubair.lutfullah@gmail.com>,
	sameo@linux.intel.com, linux-kernel@vger.kernel.org,
	gregkh@linuxfoundation.org
Subject: Re: [PATCH] mfd: ti_am335x_tscadc: fix spin lock and reg_cache
Date: Tue, 22 Oct 2013 16:48:46 +0100	[thread overview]
Message-ID: <20131022154846.GA24024@lee--X1> (raw)
In-Reply-To: <52667A6C.6000301@linutronix.de>

On Tue, 22 Oct 2013, Sebastian Andrzej Siewior wrote:

> On 08/07/2013 10:40 AM, Lee Jones wrote:
> > On Mon, 05 Aug 2013, Zubair Lutfullah wrote:
> > 
> >> Reg_cache variable is used to lock step enable register
> >> from being accessed and written by both TSC and ADC
> >> at the same time.
> >> However, it isn't updated anywhere in the code at all.
> >>
> >> If both TSC and ADC are used, eventually 1FFFF is always
> >> written enabling all 16 steps uselessly causing a mess.
> >>
> >> Patch fixes it by correcting the locks and updates the
> >> variable by reading the step enable register
> >>
> >> Signed-off-by: Zubair Lutfullah <zubair.lutfullah@gmail.com>
> >> ---
> >>  drivers/mfd/ti_am335x_tscadc.c |    4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > Better that it comes from somewhere.
> 
> I don't understand. All three functions are used before the patch has
> been applied:
> 
> $ git grep -l am335x_tsc_se_set
> drivers/iio/adc/ti_am335x_adc.c
> drivers/input/touchscreen/ti_am335x_tsc.c
> drivers/mfd/ti_am335x_tscadc.c
> 
> $ git grep -l am335x_tsc_se_clr
> drivers/iio/adc/ti_am335x_adc.c
> drivers/input/touchscreen/ti_am335x_tsc.c
> drivers/mfd/ti_am335x_tscadc.c
> 
> $ git grep -l am335x_tsc_se_update
> drivers/iio/adc/ti_am335x_adc.c
> drivers/input/touchscreen/ti_am335x_tsc.c
> drivers/mfd/ti_am335x_tscadc.c
> include/linux/mfd/ti_am335x_tscadc.h

Okay. So what does this mean?

> It has been initialized to 0 by time the mfd part was loaded and
> updated via …_set() from both parts (TSC & ADC). 
> The lock ensured that
> we never lose or add bits due to a race. So I don't understand why we
> end up with 0x1FFFF.
> Could some please explain to me how this can happen?

I don't have any h/w to actually test this, so you two are going to
have to fudge this out by yourselves.

> I added reg_se_cache to cache the content of REG_SE once and
> synchronize it among TSC & ADC access. REG_SE is set to 0 by the HW
> after "work" has been done. So you need to know the old value or TSC may
> disable ADC and the other way around.
> 
> In tree (staging-next) I see that reg_se_cache ended being pointless.
> am335x_tsc_se_update() is no longer used from TSC or ADC. Only the
> _set() and _clr() functions are used which (both) read back the content
> of the REG_SE register before calling am335x_tsc_se_update().

Not sure I get this point.

> That makes me think that we might cut of one part by accident. On the
> other hand Zubair said that he tested using ADC & TSC at the same time
> and it worked. So I have to double check if the HW really resets the
> content back to zero or not; maybe there is another explanation :)
> 
> One thing that is an issue is that now the _set() function is using the
> lock without disabling interrupts and is called from non-IRQ
> (tiadc_read_raw()) and IRQ (titsc_irq()) context which might lead to
> deadlock. I'm going to send a patch for this.

I see the patch, but let's sort this out first, before I apply it.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2013-10-22 15:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-05 19:10 Zubair Lutfullah
2013-08-07  8:40 ` Lee Jones
2013-10-22 13:15   ` Sebastian Andrzej Siewior
2013-10-22 15:48     ` Lee Jones [this message]
2013-10-22 16:28       ` Sebastian Andrzej Siewior
2013-10-25 15:53         ` Zubair Lutfullah :
2013-10-22 16:05     ` Lee Jones
2013-10-22 16:38       ` Sebastian Andrzej Siewior
2013-10-22 17:06         ` Lee Jones
2013-10-22 17:17           ` Sebastian Andrzej Siewior
2013-10-22 17:36             ` Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131022154846.GA24024@lee--X1 \
    --to=lee.jones@linaro.org \
    --cc=bigeasy@linutronix.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sameo@linux.intel.com \
    --cc=zubair.lutfullah@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome