This PR adds the existing Goodix GT9XX Touch Panel Driver to the Bringup Function for PINE64 PinePhone.
With this PR, LVGL Touchscreen Apps will respond to Touch Input on PinePhone.
### Modified Files
`boards/arm64/a64/pinephone/src/pinephone_bringup.c`: Added GT9XX Touch Panel Driver to PinePhone Bringup Function
`boards/arm64/a64/pinephone/src/Makefile`: Added `pinephone_touch.c` to the Makefile
`include/nuttx/input/gt9xx.h`: Fixed a comment in GT9XX Touch Panel Driver
### New Files
`boards/arm64/a64/pinephone/src/pinephone_touch.c`, `pinephone_touch.h`: Register GT9XX Touch Panel Driver on PinePhone
`boards/arm64/a64/pinephone/configs/lvgl/defconfig`: Added PinePhone Board Config `lvgl` to support LVGL Touchscreen Apps
### Updated Documentation
`Documentation/platforms/arm/a64/boards/pinephone/index.rst`: Added PinePhone Board Config `lvgl` for LVGL Touchscreen Apps
The dual core STM32H747 / STM32H757 there is an additional option to
select SMPS rather than LDO as the power selection.
This commit adds this option to the STM32H747 config and the
stm32h7x7xx source.
Signed-off-by: Julian Oes <julian@oes.ch>
Summary:
- This commit adds knetnsh64 and knetnsh64_smp
Impact:
- None
Testing:
- Tested with ping, telnet and iperf on QEMU-7.1
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
The memalign is special to multiple mempool because multiple mempool
doesn't support split and shrink chunk operate. So When you alloc a
memory block and find an aligned address in this block, you need to
occupy 8 bytes before the address to save the address of the padding
size and pool to ensure correct use in realloc and free operations.
So we will use bit1 in the previous address of the address to represent
that it is applied by memalign.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
kasan_report (addr=0xf3c68618, size=1, is_write=false) at
kasan/kasan.c:106
0x56585fbf in __asan_loadN_noabort (addr=0xf3c68618, size=1) at
kasan/kasan.c:300
0x565860ac in __asan_load1_noabort (addr=0xf3c68618) at
kasan/kasan.c:354
0x565843af in memcpy (dest=0xf3de9d6c, src=0xf3c685cc, n=3) at
string/lib_memcpy.c:44
0x56587ae8 in mempool_multiple_realloc (mpool=0xf3c670fc,
oldblk=0xf3c685cc, size=416) at mempool/mempool_multiple.c:218
0x5658707a in mm_realloc (heap=0xf3c67000, oldmem=0xf3c685cc,
size=416) at mm_heap/mm_realloc.c:98
0x5658524e in realloc (oldmem=0xf3c685cc, size=416) at
umm_heap/umm_realloc.c:97
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
This delta describes the relationship between the block size of each
mempool in multiple mempool by user initialized. It is automatically
detected by the mempool_multiple_init function. If the delta is not
equal to 0, the block size of the pool in the multiple mempool is an
arithmetic progressions, otherwise it is an increasing progressions.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
Let's specify size instead of number, so that we can unify the size of
expansion memory in the multiple mempool.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
the crash backtrace:
kasan_report (addr=0xf3d02fd4, size=4, is_write=false) at
kasan/kasan.c:106
0x5658518d in __asan_loadN_noabort (addr=0xf3d02fd4, size=4) at
kasan/kasan.c:300
0x565851ee in __asan_load4_noabort (addr=0xf3d02fd4) at
kasan/kasan.c:334
0x56580b02 in sq_remfirst (queue=0xf3d02b08) at
queue/sq_remfirst.c:45
0x565e0e0b in mempool_alloc (pool=0xf3d02aec) at
mempool/mempool.c:161
0x566033d2 in mempool_multiple_alloc (mpool=0xf3d02a30, size=16) at
mempool/mempool_multiple.c:147
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
struct stm32_i2c_inst_s instance is allocated on every call to
stm32_i2cbus_initialize, and that instance is supposed to be deleted on every
call to stm32_i2cbus_uninitialize.
The "refs" counter just keeps track on when the last one is deleted, and
everything is unregisterd/disabled.
This reverts commit 8098c80338.
Summary:
- It is applicable to esp32 products and uses the himem part
of 8M psram by creating character devices.
Impact:
- None
Testing:
- Use esp32-wrover series products for more than 1000 functional verifications.
Allocate the device buffer only if the protocol really need to send data.
not all protocols require the driver to prepare additional iob before
sending, especially UDP, each iob reserves l2/l3 header in advance
after prepare write buffer, net device could reuse this entry to send directly
Signed-off-by: chao an <anchao@xiaomi.com>
- Also remove the nuttx private shm.h file nuttx/mm/shm.h, which became redundant
- Also remove the gran allocator initialization/release in binfmt since common
vpage allocator is initialized in group_create/group_leave
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
The dependency should be vice versa; the MM_SHM should depend on the
existence of the virtual memory range allocator.
Create a new CONFIG flag CONFIG_ARCH_VMA_MAPPING, which will define that
there is a virtual memory range allocator. Make MM_SHM select that flag
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
ligd