Re: [Outreachy kernel] [PATCH] staging: android: ion: Fix parenthesis alignment
On Wed, 1 Apr 2020 18:25:15 -0700 "John B. Wyatt IV" wrote: > Fix 2 parenthesis alignment issues. > > Reported by checkpatch. > > Signed-off-by: John B. Wyatt IV Reviewed-by: Stefano Brivio -- Stefano ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range
On Mon, 30 Mar 2020 15:03:55 -0700 "John B. Wyatt IV" wrote: > On Mon, 2020-03-30 at 19:40 +0200, Stefano Brivio wrote: > > On Sun, 29 Mar 2020 12:37:18 +0200 (CEST) > > Julia Lawall wrote: > > > > > On Sun, 29 Mar 2020, Soumyajit Deb wrote: > > > > > > > I had the same doubt the other day about the replacement of > > > > udelay() with > > > > usleep_range(). The corresponding range for the single argument > > > > value of > > > > udelay() is quite confusing as I couldn't decide the range. But > > > > as much as I > > > > noticed checkpatch.pl gives warning for replacing udelay() with > > > > usleep_range() by checking the argument value of udelay(). In the > > > > documentation, it is written udelay() should be used for a sleep > > > > time of at > > > > most 10 microseconds but between 10 microseconds and 20 > > > > milliseconds, > > > > usleep_range() should be used. > > > > I think the range is code specific and will depend on what range > > > > is > > > > acceptable and doesn't break the code. > > > > Please correct me if I am wrong. > > > > > > The range depends on the associated hardware. > > > > John, by the way, here you could have checked the datasheet of this > > LCD > > controller. It's a pair of those: > > https://www.sparkfun.com/datasheets/LCD/ks0108b.pdf > > No I have not. This datasheet is a little over my head honestly. > > What would you recommend to get familiar with datasheets like this? Well, you don't necessarily have to, there are many subsystems in the kernel which are almost completely abstracted away from hardware. If you're interested, look around yourself for something simple chip, or get something that you can easily plug on a "maker board", Raspberry Pi, something like that. Perhaps via I²C or SPI. Some types of sensors (temperature, pressure) have very simple datasheets. If you are allergic to hardware, try: $ ls -Ssl drivers/iio/* pick the smallest sensor driver in the category that is the most likely to spark your interest, and go through it, checking it against the datasheet, at some point it will make sense. -- Stefano ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range
On Sun, 29 Mar 2020 12:37:18 +0200 (CEST) Julia Lawall wrote: > On Sun, 29 Mar 2020, Soumyajit Deb wrote: > > > I had the same doubt the other day about the replacement of udelay() with > > usleep_range(). The corresponding range for the single argument value of > > udelay() is quite confusing as I couldn't decide the range. But as much as I > > noticed checkpatch.pl gives warning for replacing udelay() with > > usleep_range() by checking the argument value of udelay(). In the > > documentation, it is written udelay() should be used for a sleep time of at > > most 10 microseconds but between 10 microseconds and 20 milliseconds, > > usleep_range() should be used. > > I think the range is code specific and will depend on what range is > > acceptable and doesn't break the code. > > Please correct me if I am wrong. > > The range depends on the associated hardware. John, by the way, here you could have checked the datasheet of this LCD controller. It's a pair of those: https://www.sparkfun.com/datasheets/LCD/ks0108b.pdf reset time is 1µs minimum, which is the only actual constraint here. The rise time should then be handled by power supply and reflected with some appropriate usage of the regulator framework. That 120ms delay, however, must be there for a reason, that is, most likely to develop this quickly without exposing a proper model of the power supplies to the driver. So... in this case, with the datasheet alone, you won't go very far, you would need the actual module (probably connected to a Raspberry Pi to catch a typical usage). Still, it's usually worth a check. In any case, most likely, as Andy suggested, this function can eventually be dropped. -- Stefano ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
