public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Lukas Schneider <lukas.s.schneider@fau.de>
Cc: kim.jamie.bradley@gmail.com, pakki001@umn.edu,
	colin.king@canonical.com, devel@driverdev.osuosl.org,
	linux-kernel@vger.kernel.org,
	Jannik Moritz <jannik.moritz@fau.de>,
	linux-kernel@i4.cs.fau.de
Subject: Re: [PATCH 4/4] rts5208: Fix usleep range is preferred over udelay
Date: Fri, 21 Jun 2019 13:04:05 +0200	[thread overview]
Message-ID: <20190621110405.GG24145@amd> (raw)
In-Reply-To: <20190619154648.13840-4-lukas.s.schneider@fau.de>

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]

On Wed 2019-06-19 17:46:48, Lukas Schneider wrote:
> This patch fixes the issue reported by checkpatch:
> 
> CHECK: usleep_range is preferred over udelay;
> see Doucmentation/timers/timers-howto.txt
> 
> It's save to sleep here instead of using busy waiting,
> because we are not in an atomic context.

Is it good idea? How can the system really sleep for 50 usec?

      	   	     	     	    	   	     Pavel

> @@ -865,7 +865,7 @@ static int sd_change_phase(struct rtsx_chip *chip, u8 sample_point, u8 tune_dir)
>  						     PHASE_CHANGE);
>  			if (retval)
>  				return retval;
> -			udelay(50);
> +			usleep_range(50, 60);
>  			retval = rtsx_write_register(chip, SD_VP_CTL, 0xFF,
>  						     PHASE_CHANGE |
>  						     PHASE_NOT_RESET |
> @@ -877,14 +877,14 @@ static int sd_change_phase(struct rtsx_chip *chip, u8 sample_point, u8 tune_dir)
>  						     CHANGE_CLK, CHANGE_CLK);
>  			if (retval)
>  				return retval;
> -			udelay(50);
> +			usleep_range(50, 60);
>  			retval = rtsx_write_register(chip, SD_VP_CTL, 0xFF,
>  						     PHASE_NOT_RESET |
>  						     sample_point);
>  			if (retval)
>  				return retval;
>  		}
> -		udelay(100);
> +		usleep_range(100, 110);
>  
>  		rtsx_init_cmd(chip);
>  		rtsx_add_cmd(chip, WRITE_REG_CMD, SD_DCMPS_CTL, DCMPS_CHANGE,
> @@ -918,7 +918,7 @@ static int sd_change_phase(struct rtsx_chip *chip, u8 sample_point, u8 tune_dir)
>  				return retval;
>  		}
>  
> -		udelay(50);
> +		usleep_range(50, 60);
>  	}
>  
>  	retval = rtsx_write_register(chip, SD_CFG1, SD_ASYNC_FIFO_NOT_RST, 0);
> @@ -1416,7 +1416,7 @@ static int sd_wait_data_idle(struct rtsx_chip *chip)
>  			retval = STATUS_SUCCESS;
>  			break;
>  		}
> -		udelay(100);
> +		usleep_range(100, 110);
>  	}
>  	dev_dbg(rtsx_dev(chip), "SD_DATA_STATE: 0x%02x\n", val);
>  

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2019-06-21 11:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-19 15:46 [PATCH 1/4] rts5208: Fix usleep_range is preferred over udelay Lukas Schneider
2019-06-19 15:46 ` [PATCH 2/4] " Lukas Schneider
2019-06-19 15:46 ` [PATCH 3/4] " Lukas Schneider
2019-06-19 15:46 ` [PATCH 4/4] rts5208: Fix usleep range " Lukas Schneider
2019-06-21 11:04   ` Pavel Machek [this message]
2019-06-21 13:01     ` Lukas Schneider

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=20190621110405.GG24145@amd \
    --to=pavel@ucw.cz \
    --cc=colin.king@canonical.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=jannik.moritz@fau.de \
    --cc=kim.jamie.bradley@gmail.com \
    --cc=linux-kernel@i4.cs.fau.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.s.schneider@fau.de \
    --cc=pakki001@umn.edu \
    /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