Mpu6050 impr3 add cdev#31
Conversation
dmytrokirtoka
force-pushed
the
mpu6050_impr3_cdev
branch
from
e10217d to
51ebcf7
Compare
|
finished the driver, ready for review |
dmytrokirtoka
force-pushed
the
mpu6050_impr3_cdev
branch
from
51ebcf7 to
a01f6a5
Compare
|
three dependent commits for mpu6050 practics:
|
dmytrokirtoka
force-pushed
the
mpu6050_impr3_cdev
branch
from
a01f6a5 to
c8643dd
Compare
|
Driver change: |
|
I'm tested last changes and work at fix it |
added ring buffer with 10 elm added timer with module parameter rate, default is 1000 msec added work for periodic read data from device sheduled by time
added dinamic add/remove device in /dev added support read only fops for mpu6050 module limitation: read data by only READ_REG_NUM blocks supported only one device
dmytrokirtoka
force-pushed
the
mpu6050_impr3_cdev
branch
from
c8643dd to
181bde6
Compare
|
Check on device, apply kernel code style. |
Signed-off-by: dmytro.kirtoka <dimk334@gmail.com>
dmytrokirtoka
force-pushed
the
mpu6050_impr3_cdev
branch
from
181bde6 to
2374c33
Compare
|
@dmytrokirtoka , is this PR is still relevant? |
|
is this PR is still relevant?
|
|
this pull request have another realization of buffering, see branch "added buffered read data by time", |
AleksandrBulyshchenko
left a comment
AleksandrBulyshchenko
left a comment
There was a problem hiding this comment.
👍
I haven't tested - only reviewed.
Good exercise implementation (timer, completion, etc).
Nitpicks:
- Commit messages could be improved (following kernel recommendations, SOB, etc.)
- Changes of "mpu6050: apply kernel code style" which fixes previous commits are better to include in place.
| return 0; | ||
| } | ||
|
|
||
| static int mpu6050_get_data(int *values, int is_buffered) |
There was a problem hiding this comment.
IMO, there's no need to make is_buffered a parameter here.
If you check is_buf inside mpu6050_read_data(), I believe mpu6050_get_data() should follow the same.
| g_mpu6050_data.data[head].values.temperature = (temp + 12420 + 170) / 340; | ||
|
|
||
| if ((is_buf && count < READ_DEPTH) || (!is_buf && !count)) | ||
| complete(&has_data); |
There was a problem hiding this comment.
Just to note: I haven't made deep analyse bu afraid of possibility of some race with mpu6050_get_data(),
which may cause has_data became desynchronized with g_mpu6050_data.count.
3 participants
complete mpu6050 dev for next use.