since we can query this value by MTDIOC_ERASESTATE after:
commit 30cb497fe1
Author: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
Date: Tue Jul 13 19:33:12 2021 -0300
mtd: Add MTDIOC_ERASESTATE command for retrieving erase state value
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Summary:
- I noticed that the latest ifconfig command shows nothing
- Finally, I found that gs2200m.c needs to handle SIOCGIFFLAGS
- This commit fixes this issue
Impact:
- gs2200m only
Testing:
- Tested with spresense:wifi
- NOTE: gs2200m_main.c will be updated later
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
This patch fixes unbuffered mode so it actually works.
Also, patch contains fixes for possible bugs that could result in
deadlock or system hang in certain situations.
Signed-off-by: Michał Łyszczek <michal.lyszczek@bofc.pl>
since it is impossible to track producer and consumer
correctly if TCP/IP stack pass IOB directly to netdev
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
0c3db448bb
added the option to generate the waveforms to drive ws2812 and similar LEDs using different
hardware (e.g. RP2040 PIO instead of SPI).
For that new mode, the concept of CONFIG_WS2812_FREQUENCY is different. Instead of
the SPI frequency (commonly a few MHz), it is the frequency of the actual output waveform
(commonly 400 or 800 kHz).
There was an attempt to express the SPI frequency divided by 10, but it's not actually the
case either (it would be divided by 8).
I think it is clearer to explain in Kconfig what CONFIG_WS2812_FREQUENCY means for each mode
and go back to the previous behaviour for the original SPI mode (also to avoid breaking
out-of-tree boards).
The commit 664d45dcba updated the
behavior of the framebuffer's putarea callback enabling it to be
used to draw a particular area of the display. Previously, putarea
was only used to draw the entire area of the display. Any different
area was drawn, row by row, by putrun. Also, before checking for
which callback to call, the framebuffer driver adjusted the buffer
reference that was going to be used for calling the driver's callback
to point to the init of the relevant data. After that commit, the
framebuffer's buffer reference passed to the driver's putarea now
contains the data to draw the entire display. Unlike the previous
version of that implementation, only the putrun's callback buffer
was being referenced from the address that contains the data that
actually is being drawn.
This commit fixes it by adjusting the reference for the run buffer
passed to the putrun/putarea callback. It always starts from the
beginning of the relevant data that is actually being drawn. That is
necessary because lcddev (which uses the same LCD display driver
callbacks) actually don't allocate a buffer containing the data to
draw the whole display, so the same putarea implementation of the
LCD drivers would'n be able to work for both lcddev and framebuffer.
Also it's necessary to pass the stride argument to the LCD drivers
in order to enable them to do partial writes by calculating the
buffer offset while sending row-by-row. The stride is equal the
width multiplied by the bytes per pixel (may add some padding)
for framebuffer and is equal to the lenght of the row being drawn
(multiplied by the same BPP) for lcddev.
Why this approach?
Other possible approaches would be:
1) modify lcddev driver to translate received buffer data to a
buffer similar to the framebuffer. That wouldn't be efficient
considering memory allocation.
2) Create a new callback function. While possible, it'd be confusing
to create a different callback to draw the whole screen and another
to draw only an area of the screen. Also, these callbacks would
differ themselves only from the way the buffer is filled.
3) Simply reverting 664d45dcba would
break the usage of the putarea callback to draw an area of the
display, which would also be inefficient.
This approach is based on the Zephyr's implementation of the ST7789
driver: the buffer starts from the beginiing of the region that would
be drawn. The display device driver's putarea implementation should
check if the operation refers to a full screen/full row and implement
(if possible) a single operation to send the data to be drawn more
efficiently.
Finally, this approach requires that the drivers which implement
the putarea callback and expects the entire framebuffer buffer
to be modified. They don't need to calculate where the data begins
as the new buffer represents the data from the address that is
actually being drawn. This includes adjusting the LCD drivers
GC9A01 and ST7789 and the driver for APA102-based LED matrix display.
In file included from /home/archer/code/nuttx/n4/incubator-nuttx/drivers/rc/lirc_dev.c:29:
drivers/rc/lirc_dev.c: In function 'lirc_raw_event':
drivers/rc/lirc_dev.c:959:14: warning: format '%u' expects argument of type 'unsigned int',
but argument 3 has type 'uint32_t' {aka 'long unsigned int'} [-Wformat=]
959 | rcinfo("delivering %uus %d to lirc\n", ev.duration, ev.pulse ? 1 : 0);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
| |
| uint32_t {aka long unsigned int}
drivers/rc/lirc_dev.c:959:27: note: format string is defined here
959 | rcinfo("delivering %uus %d to lirc\n", ev.duration, ev.pulse ? 1 : 0);
| ~^
| |
| unsigned int
| %lu
Signed-off-by: chao.an <anchao@xiaomi.com>
1. about interval:
If interval is not set, generation is increased by 1 along with
publish and copy, multi-copy is continuous.
If interval is set, pick proper samples from buffer based on
mainline/user generation, multi-copy is one-by-one.
2. about bufferpos:
user->bufferpos always point to next position to check.
data user last read
----------v--------------------------
| | | |
-------------------^-----------------
bufferpos
If buffer is full, bufferpos point to buffer.head
Examples:
If a buffer contains 4 samples, newest generatoin is 40.
-------------------------------------
|10 |20 |30 |40
------------------------------^------
|
if user's next generation is 42, notify user to copy No.40 sample,
because 42 is closer to 40 than 50.
-------------------------------------
|10 |20 |30 |40
----------------------------------^--
|
if user's next generation is 48, do not notify user,
because 48 is closer to 50, which is next mainline sample.
Signed-off-by: jihandong <jihandong@xiaomi.com>
Signed-off-by: Jiuzhu Dong <dongjiuzhu1@xiaomi.com>
This patch adds upper half driver for IPCC character driver. IPCC
is a Inter Processor Communication Controller.
Driver is still immature and not thoroughly tested, thus
CONFIG_EXPERIMENTAL is required.
Signed-off-by: Michał Łyszczek <michal.lyszczek@bofc.pl>
Certain variants of the W25QxxxJV Quad SPI NOR flash ICs have the Quad
SPI mode disabled after reset. As the w25qxxxjv driver is operating the
device in Quad SPI mode, make sure it gets enabled if required during
device initialization.
Signed-off-by: Michael Jung <michael.jung@secore.ly>
power/pm_procfs.c:282:27: warning: format specifies type 'unsigned long' but the argument has type 'time_t' (aka 'unsigned int') [-Wformat]
dom->wake[state].tv_sec,
^~~~~~~~~~~~~~~~~~~~~~~
make[2]: Entering directory '/home/ligd/platform/m2/audio/frameworks/media'
power/pm_procfs.c:283:27: warning: format specifies type 'unsigned long' but the argument has type 'unsigned int' [-Wformat]
100 * dom->wake[state].tv_sec / sum,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
power/pm_procfs.c:284:27: warning: format specifies type 'unsigned long' but the argument has type 'time_t' (aka 'unsigned int') [-Wformat]
dom->sleep[state].tv_sec,
^~~~~~~~~~~~~~~~~~~~~~~~
power/pm_procfs.c:285:27: warning: format specifies type 'unsigned long' but the argument has type 'unsigned int' [-Wformat]
100 * dom->sleep[state].tv_sec / sum,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
power/pm_procfs.c:286:27: warning: format specifies type 'unsigned long' but the argument has type 'time_t' (aka 'unsigned int') [-Wformat]
total.tv_sec,
^~~~~~~~~~~~
power/pm_procfs.c:287:27: warning: format specifies type 'unsigned long' but the argument has type 'unsigned int' [-Wformat]
100 * total.tv_sec / sum);
^~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: ligd <liguiding1@xiaomi.com>
1.Allow multi users to access the same sensor device simultaneously.
2.Get real state of sensor device by cmd SNIOC_GET_STATE for users.
3.Get update state since last read by poll without timeout for users.
4.Sensor device will be activated when first user open and will close when
last user closed.
5.When multi users to access device, driver always set the minimum
sampling interval and latency to the sensor device and allow
downsampled for users above the minimum sampling interval.
6.The circbuffer will overwrite old data when buffer is full, so if users
don't read data soon, data will be lost, and the oldest data in circbuffer
are returned to the users.
7.Always read the last data in the circbuffer as initial value for new
users when the sensor device has not yet generated new data.
8.when user uses poll, if subscription interval is satisfied, the POLLIN
events is returned for each users.
9.When new user generate or the state of sensor device changed, the POLLPRI
will notify to all users.
10.Support multi advertisers to subscribe their own data as loop test.
Signed-off-by: Jiuzhu Dong <dongjiuzhu1@xiaomi.com>
1.cmd:SNIOC_REGISTER with struct sensor_reginfo_s to register user sensor
2.cmd:SNIOC_UNREGISTER to unregister user sensor
Signed-off-by: Jiuzhu Dong <dongjiuzhu1@xiaomi.com>
1.Simplify buffer opeations to avoid frequent resize for batch and no-batch mode.
2.When sensor event is first generated, the buffer is initialized.
3.Remove and merge batch_number to buffer_number when device support batch mode.
Signed-off-by: Jiuzhu Dong <dongjiuzhu1@xiaomi.com>
'putarea' function now has to select the appropriate values from the
whole frame buffer instead of the previous expectation of having just
specified rectangle passed to it.
This required extension of WRRAM handling function as we now are not
writing simply buffer but we want to skip some values and do that
multiple times. Having two implementation in this case is worst as this
function is actually called only twice in the whole code (thus making
dedicated function for every call if we would have two variants).
Calling `st7789_wrram` multiple times is not an option as command
ST7789_RAMWR resets the position and thus calling it multiple times just
overwrites the previous values.
I found an issue in the APA102 framebuffer that wasn't spot
before by fb test because this application draw symetric squares
Normally in a display each line starts at left and increase to the
right, however for this APA102 matrix the next line starts at the
end of previous line and move the opposite direction, forming a
zig-zag pattern.
