On Sat, Dec 3, 2016 at 3:52 PM, Greg KH wrote:
> On Sat, Dec 03, 2016 at 03:41:19PM +0530, Chinmay VS wrote:
>> From: ChinmayVS
>>
>> Macros with multiple statements should be enclosed in a do - while loop
>>
>> Signed-off-by: ChinmayVS
>> ---
>> drivers/staging/greybus/loopback.c | 4 +++-
>>
Thanks for your quick response Mike.
> Try without the proprietary modules. You may also want to audit futex
> fixes if you can't use a maintained stable tree. 3.2 has a bunch that
> 3.1 does not.
I see that futex.c has 17 patches in 3.2.y that are missing in my tree.
http://git.kernel.org/cgit/
Hello everyone,
TL;DR: In Linux RT scheduler, how can rt_nr_running be non-zero AND
active-bitmap NOT have any valid bit set?
Details:
Recently i encountered the following BUG() within the realtime
scheduler (sched_rt.c) on 3.1.10 kernel.
[101640.492840] kernel BUG at kernel/sched_rt.c:1126!
Thi
On Wed, Nov 20, 2013 at 11:28 PM, J. Bruce Fields wrote:
> On Wed, Nov 20, 2013 at 10:41:54PM +0530, Chinmay V S wrote:
>> On Wed, Nov 20, 2013 at 9:25 PM, J. Bruce Fields
>> wrote:
>> > Some SSD's are also claim the ability to flush the cache on power loss:
On Wed, Nov 20, 2013 at 9:25 PM, J. Bruce Fields wrote:
> Some SSD's are also claim the ability to flush the cache on power loss:
>
>
> http://www.intel.com/content/www/us/en/solid-state-drives/ssd-320-series-power-loss-data-protection-brief.html
>
> Which should in theory let them respon
Hi Stefan,
> thanks for your great and detailed reply. I'm just wondering why an
> intel 520 ssd degrades the speed just by 2% in case of O_SYNC. intel 530
> the newer model and replacement for the 520 degrades speed by 75% like
> the crucial m4.
>
> The Intel DC S3500 instead delivers also nearly
Hi Stefan,
Christoph is bang on right. To further elaborate upon this, here is
what is happening in the above case :
By using DIRECT, SYNC/DSYNC flags on a block device (i.e. bypassing
the file-systems layer), essentially you are enforcing a CMD_FLUSH on
each I/O command sent to the disk. This is
de is here
> in my driver. This is running on quad core cortex A9 Thats why I have point.
> If there are 4 cpu cores, then there must be parallelism. Now Tajun, what do
> you say?
>
> Regards,
> Deepa
>
> On Monday, September 24, 2012, Chinmay V S wrote:
>>
>> T
12bit it IS then. :-)
LGTM. +1.
On Thu, Aug 23, 2012 at 4:45 PM, AnilKumar, Chimata wrote:
> Chinmay,
>
> On Thu, Aug 23, 2012 at 15:53:10, Chinmay V S wrote:
>> > Note from datasheet, "1LSb=4g/4096 at 12bit representation,
>> > ±2g Full-scale"
>>
>&
> Note from datasheet, "1LSb=4g/4096 at 12bit representation,
> ±2g Full-scale"
Precisely my point. All the datasheet says is :
1. It is +/-2G mode --> so Numerator is 4G.
2. We are using 12bits --> so Denominator is 2^12 = 4096.
There is no clear reason/justification as to why 12bits was chosen
> Look at this application note which talks about the outdata values
> for 2G range (page 12/31)
> http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00215823.pdf
Had been through the application note earlier. The table5 (on page 12)
that you refer to, does
Hmmm. Interesting. As i understand LIS331DLH provides 16bit data
irrespective of the full-scale/sensitivity configuration. Hence we
could effectively map +/-2G to +/-32768(signed 16bit 2's complement).
According to the current-patch right-shifting the register values by
4(i.e. reducing 16bit --> 12
Hi All,
A few nitpicks.
> + * LIS3331DLH spec says 1LSBs corresponds 4G/1024 -> 1LSB is 1000/1024 mG.
> + * Sensitivity values for +/-2G, outdata in 12 bits for +/-2G scale. so 4
> + * bits adjustment is required
Shouldn't it be "1LSB is 4000/1024 mG" ?
Also "outdata in 12bits" (typo. in->is?)
O
13 matches
Mail list logo
