Summary:
- I noticed that QEMU shows high CPU usage if the number of
CPUs does not match the kernel configuration. (e.g. -smp 8
and CONFIG_SMP_NCPUS=2)
- This commit fixes this issue.
Impact:
- qemu-rv only
Testing:
- Tested with the following configs
- rv-virt:smp64 (CONFIG_NCPUS=1/2/8)
- rv-virt:nsh64
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.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).
In order to better test the lcdddev driver and framebuffer, newer
board configs (for the TTGO T-Display and for the simulator) were
added.
Adjusted references of the sim:lvgl_(fb/lcd) config.
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.
This commit adds support for GPIO driver based encoder for SAMv7 boards.
This encoder do not use the microcontroller's dedicated driver but two
GPIO pins with interrupts. The position is calculated based on those
interrupts.
This can be used for boards that do not have pins routed to the dedicated
driver.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
Summary:
- This commit applies the following imxrt_enet.c changes to imx_enet.c
commit 522a949ed5
Author: David Sidrane <David.Sidrane@NscDg.com>
Date: Wed Jul 13 11:00:11 2022 -0700
imxrt:enet Better interrupt state handeling
- NOTE: I also fixed typo and compile error in the above commit
Impact:
- imx_enet.c
Testing:
- Tested with qemu-6.2
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- This commit applies the following imxrt_enet.c changes to imx_enet.c
commit 81f03a9151
Author: David Sidrane <David.Sidrane@NscDg.com>
Date: Tue Mar 15 14:27:51 2022 -0700
imxrt:ETH Add Support for ETH2
Impact:
- imx_enet.c
Testing:
- Tested with qemu-6.2
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
It is not really needed; g_hart_stacks is only used during SBI init as
a temporary stack area. We can use the scratch area buffers for this, as
the scratch areas define almost 4K of extra space, which is used for
exception stacks anyway.
This change adds support for the following features:
- injected channels (default: 0)
- ADC resolution (default: 12bit)
- ADC low-level operations
- ADC external triggers
- custom ADC interrupts
- ADC sample time configuration
- configurable ADC SCAN mode (default on if DMA)
- configurable ADC DMA mode (default: one shot mode)
- reset the ADC block only if all ADC instances are closed
The L3 table address was calculated incorrectly. For every 2MiB of
mapped memory, an offset of 4KiB is needed from the base of the L3
table. The old calculation failed if paddr was not aligned to a 2MiB
boundary.
This change adds support for the following features:
1. PWM complementary outputs
2. interface for low-level PWM operations
3. support for all PWM channel modes
4. support for internal PWM channels (TIM1/TIM8)
5. support for PWM channel polarity and IDLE state
6. support for TRGO and BREAK
