Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1601606 > unrolled thread

Re: [PATCH v2 2/4] pinctrl: rockchip: convert to raw spinlock

Started byJohn Keeping <john@metanate.com>
First post2017-03-15 19:10 +0100
Last post2017-03-15 19:50 +0100
Articles 4 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 2/4] pinctrl: rockchip: convert to raw spinlock John Keeping <john@metanate.com> - 2017-03-15 19:10 +0100
    Re: [PATCH v2 2/4] pinctrl: rockchip: convert to raw spinlock Heiko Stuebner <heiko@sntech.de> - 2017-03-15 19:20 +0100
      Re: [PATCH v2 2/4] pinctrl: rockchip: convert to raw spinlock Julia Cartwright <julia@ni.com> - 2017-03-15 19:30 +0100
        Re: [PATCH v2 2/4] pinctrl: rockchip: convert to raw spinlock John Keeping <john@metanate.com> - 2017-03-15 19:50 +0100

#1601606 — Re: [PATCH v2 2/4] pinctrl: rockchip: convert to raw spinlock

FromJohn Keeping <john@metanate.com>
Date2017-03-15 19:10 +0100
SubjectRe: [PATCH v2 2/4] pinctrl: rockchip: convert to raw spinlock
Message-ID<tllx0-2TA-15@gated-at.bofh.it>
On Wed, 15 Mar 2017 13:01:37 -0500, Julia Cartwright wrote:
> On Wed, Mar 15, 2017 at 05:46:52PM +0000, John Keeping wrote:
> > This lock is used from rockchip_irq_set_type() which is part of the
> > irq_chip implementation and thus must use raw_spinlock_t as documented
> > in Documentation/gpio/driver.txt.
> > 
> > Signed-off-by: John Keeping <john@metanate.com>
> > Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> > Tested-by: Heiko Stuebner <heiko@sntech.de>
> > ---
> > v2: unchanged
> > ---
> >  drivers/pinctrl/pinctrl-rockchip.c | 30 +++++++++++++++---------------
> >  1 file changed, 15 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
> > index 128c383ea7ba..8c1cae6d78d7 100644
> > --- a/drivers/pinctrl/pinctrl-rockchip.c
> > +++ b/drivers/pinctrl/pinctrl-rockchip.c
> > @@ -163,7 +163,7 @@ struct rockchip_pin_bank {
> >  	struct irq_domain		*domain;
> >  	struct gpio_chip		gpio_chip;
> >  	struct pinctrl_gpio_range	grange;
> > -	spinlock_t			slock;
> > +	raw_spinlock_t			slock;
> >  	u32				toggle_edge_mode;
> >  };
> >  
> > @@ -1295,14 +1295,14 @@ static int rockchip_set_pull(struct rockchip_pin_bank *bank,
> >  
> >  	switch (ctrl->type) {
> >  	case RK2928:
> > -		spin_lock_irqsave(&bank->slock, flags);
> > +		raw_spin_lock_irqsave(&bank->slock, flags);
> >  
> >  		data = BIT(bit + 16);
> >  		if (pull == PIN_CONFIG_BIAS_DISABLE)
> >  			data |= BIT(bit);  
> 
> This should be lifted out from under the lock.
> 
> >  		ret = regmap_write(regmap, reg, data);  
> 
> How is this legal?  The regmap_write() here is going to end up acquiring
> the regmap mutex.

It's not, the spinlock can be deleted here.  I only have RK3288 hardware
to test and I missed this when checking the uses of slock.


John

[toc] | [next] | [standalone]

#1601612

FromHeiko Stuebner <heiko@sntech.de>
Date2017-03-15 19:20 +0100
Message-ID<tllGF-2YN-9@gated-at.bofh.it>
In reply to#1601606
Am Mittwoch, 15. März 2017, 18:08:06 CET schrieb John Keeping:
> On Wed, 15 Mar 2017 13:01:37 -0500, Julia Cartwright wrote:
> > On Wed, Mar 15, 2017 at 05:46:52PM +0000, John Keeping wrote:
> > > This lock is used from rockchip_irq_set_type() which is part of the
> > > irq_chip implementation and thus must use raw_spinlock_t as documented
> > > in Documentation/gpio/driver.txt.
> > > 
> > > Signed-off-by: John Keeping <john@metanate.com>
> > > Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> > > Tested-by: Heiko Stuebner <heiko@sntech.de>
> > > ---
> > > v2: unchanged
> > > ---
> > > 
> > >  drivers/pinctrl/pinctrl-rockchip.c | 30 +++++++++++++++---------------
> > >  1 file changed, 15 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/drivers/pinctrl/pinctrl-rockchip.c
> > > b/drivers/pinctrl/pinctrl-rockchip.c index 128c383ea7ba..8c1cae6d78d7
> > > 100644
> > > --- a/drivers/pinctrl/pinctrl-rockchip.c
> > > +++ b/drivers/pinctrl/pinctrl-rockchip.c
> > > @@ -163,7 +163,7 @@ struct rockchip_pin_bank {
> > > 
> > >  	struct irq_domain		*domain;
> > >  	struct gpio_chip		gpio_chip;
> > >  	struct pinctrl_gpio_range	grange;
> > > 
> > > -	spinlock_t			slock;
> > > +	raw_spinlock_t			slock;
> > > 
> > >  	u32				toggle_edge_mode;
> > >  
> > >  };
> > > 
> > > @@ -1295,14 +1295,14 @@ static int rockchip_set_pull(struct
> > > rockchip_pin_bank *bank,> > 
> > >  	switch (ctrl->type) {
> > > 
> > >  	case RK2928:
> > > -		spin_lock_irqsave(&bank->slock, flags);
> > > +		raw_spin_lock_irqsave(&bank->slock, flags);
> > > 
> > >  		data = BIT(bit + 16);
> > >  		if (pull == PIN_CONFIG_BIAS_DISABLE)
> > >  		
> > >  			data |= BIT(bit);
> > 
> > This should be lifted out from under the lock.
> > 
> > >  		ret = regmap_write(regmap, reg, data);
> > 
> > How is this legal?  The regmap_write() here is going to end up acquiring
> > the regmap mutex.
> 
> It's not, the spinlock can be deleted here.  I only have RK3288 hardware
> to test and I missed this when checking the uses of slock.

That part could very well also use regmap_update_bits like the other parts.
Not really sure, why we use regmap_write here, but I'm also not sure, if it 
matters at all.

[toc] | [prev] | [next] | [standalone]

#1601625

FromJulia Cartwright <julia@ni.com>
Date2017-03-15 19:30 +0100
Message-ID<tllQm-32M-11@gated-at.bofh.it>
In reply to#1601612

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 15, 2017 at 07:16:53PM +0100, Heiko Stuebner wrote:
> Am Mittwoch, 15. März 2017, 18:08:06 CET schrieb John Keeping:
> > On Wed, 15 Mar 2017 13:01:37 -0500, Julia Cartwright wrote:
> > > On Wed, Mar 15, 2017 at 05:46:52PM +0000, John Keeping wrote:
> > > > This lock is used from rockchip_irq_set_type() which is part of the
> > > > irq_chip implementation and thus must use raw_spinlock_t as documented
> > > > in Documentation/gpio/driver.txt.
> > > > 
> > > > Signed-off-by: John Keeping <john@metanate.com>
> > > > Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> > > > Tested-by: Heiko Stuebner <heiko@sntech.de>
> > > > ---
> > > > v2: unchanged
> > > > ---
> > > > 
> > > >  drivers/pinctrl/pinctrl-rockchip.c | 30 +++++++++++++++---------------
> > > >  1 file changed, 15 insertions(+), 15 deletions(-)
> > > > 
> > > > diff --git a/drivers/pinctrl/pinctrl-rockchip.c
> > > > b/drivers/pinctrl/pinctrl-rockchip.c index 128c383ea7ba..8c1cae6d78d7
> > > > 100644
[..]
> > > > @@ -1295,14 +1295,14 @@ static int rockchip_set_pull(struct
> > > > rockchip_pin_bank *bank,> > 
> > > >  	switch (ctrl->type) {
> > > > 
> > > >  	case RK2928:
> > > > -		spin_lock_irqsave(&bank->slock, flags);
> > > > +		raw_spin_lock_irqsave(&bank->slock, flags);
> > > > 
> > > >  		data = BIT(bit + 16);
> > > >  		if (pull == PIN_CONFIG_BIAS_DISABLE)
> > > >  		
> > > >  			data |= BIT(bit);
> > > 
> > > This should be lifted out from under the lock.
> > > 
> > > >  		ret = regmap_write(regmap, reg, data);
> > > 
> > > How is this legal?  The regmap_write() here is going to end up acquiring
> > > the regmap mutex.
> > 
> > It's not, the spinlock can be deleted here.  I only have RK3288 hardware
> > to test and I missed this when checking the uses of slock.
> 
> That part could very well also use regmap_update_bits like the other parts.
> Not really sure, why we use regmap_write here, but I'm also not sure, if it 
> matters at all.

regmap_update_bits also acquires the regmap lock, which would similarly
be a problem here.[1]

But, if we could pull this entire operation out of the lock (and
convince ourselves that it's okay to do so), then even better!

   Julia

1: Why is this a problem?  Because we're in the middle of a
   raw_spinlock_t protected critical region: if there were contention on
   the nested mutex (the "regmap mutex"), then we'd attempt to sleep in
   atomic context.

[toc] | [prev] | [next] | [standalone]

#1601657

FromJohn Keeping <john@metanate.com>
Date2017-03-15 19:50 +0100
Message-ID<tlm9K-3am-65@gated-at.bofh.it>
In reply to#1601625
On Wed, 15 Mar 2017 13:23:09 -0500, Julia Cartwright wrote:
> On Wed, Mar 15, 2017 at 07:16:53PM +0100, Heiko Stuebner wrote:
> > Am Mittwoch, 15. März 2017, 18:08:06 CET schrieb John Keeping:  
> > > On Wed, 15 Mar 2017 13:01:37 -0500, Julia Cartwright wrote:  
> > > > On Wed, Mar 15, 2017 at 05:46:52PM +0000, John Keeping wrote:  
> > > > > This lock is used from rockchip_irq_set_type() which is part of the
> > > > > irq_chip implementation and thus must use raw_spinlock_t as documented
> > > > > in Documentation/gpio/driver.txt.
> > > > > 
> > > > > Signed-off-by: John Keeping <john@metanate.com>
> > > > > Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> > > > > Tested-by: Heiko Stuebner <heiko@sntech.de>
> > > > > ---
> > > > > v2: unchanged
> > > > > ---
> > > > > 
> > > > >  drivers/pinctrl/pinctrl-rockchip.c | 30 +++++++++++++++---------------
> > > > >  1 file changed, 15 insertions(+), 15 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/pinctrl/pinctrl-rockchip.c
> > > > > b/drivers/pinctrl/pinctrl-rockchip.c index 128c383ea7ba..8c1cae6d78d7
> > > > > 100644  
> [..]
> > > > > @@ -1295,14 +1295,14 @@ static int rockchip_set_pull(struct
> > > > > rockchip_pin_bank *bank,> > 
> > > > >  	switch (ctrl->type) {
> > > > > 
> > > > >  	case RK2928:
> > > > > -		spin_lock_irqsave(&bank->slock, flags);
> > > > > +		raw_spin_lock_irqsave(&bank->slock, flags);
> > > > > 
> > > > >  		data = BIT(bit + 16);
> > > > >  		if (pull == PIN_CONFIG_BIAS_DISABLE)
> > > > >  		
> > > > >  			data |= BIT(bit);  
> > > > 
> > > > This should be lifted out from under the lock.
> > > >   
> > > > >  		ret = regmap_write(regmap, reg, data);  
> > > > 
> > > > How is this legal?  The regmap_write() here is going to end up acquiring
> > > > the regmap mutex.  
> > > 
> > > It's not, the spinlock can be deleted here.  I only have RK3288 hardware
> > > to test and I missed this when checking the uses of slock.  
> > 
> > That part could very well also use regmap_update_bits like the other parts.
> > Not really sure, why we use regmap_write here, but I'm also not sure, if it 
> > matters at all.  
> 
> regmap_update_bits also acquires the regmap lock, which would similarly
> be a problem here.[1]
> 
> But, if we could pull this entire operation out of the lock (and
> convince ourselves that it's okay to do so), then even better!

Yes, we can delete the lock here for the same reason as all of the
others that are removed in patch 1.

I don't think it makes much difference whether we use regmap_write or
regmap_update_bits here (although consistently using regmap_update_bits
might be nice) so I won't change it as part of this series, especially
since I don't have an RK2928 to test.


John

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web