1. introduce helper to find array of gpiochips
2. Add support for Cherryview GPIO controller based on helper 1.
I already validated them on Rock PI X board.
hongzha1 (2):
drivers/gpio: core: introduce helper to find array of gpiochips
driver/gpio: cherryview: introduce gpio driver for pinctl
To find array of gpiochips for non-OF platform
Signed-off-by: hongzha1
---
include/cobalt/kernel/rtdm/gpio.h | 4
kernel/drivers/gpio/gpio-core.c | 19 +++
2 files changed, 23 insertions(+)
diff --git a/include/cobalt/kernel/rtdm/gpio.h
Add support for Intel Cherryview pin controller driver
Signed-off-by: hongzha1
---
kernel/drivers/gpio/Kconfig | 7 +
kernel/drivers/gpio/Makefile | 2 ++
kernel/drivers/gpio/gpio-cherryview.c | 43 +++
3 files changed, 52 insertions(+)
create
Thanks Jan.
I experimented with a few of the Linux 4.9 kernels with 32-bit but all
with the same result. It is time for me to abandon x86_32 development.
Unfortunately, the BIOS will not allow me to put a 64-bit kernel onto
the hardware so that hardware is now obsolete. I'll have to think
On 12.05.21 14:57, François Legal via Xenomai wrote:
> This patch enables retrieving, in realtime application, of RTNET enabled
> adapters packet timestamps.
> It uses the linux semantic SO_TIMESTAMPNS, and the linux code to put the
> timestamp in the control_msg structure.
>
Thanks for the
This patch enables retrieving, in realtime application, of RTNET enabled
adapters packet timestamps.
It uses the linux semantic SO_TIMESTAMPNS, and the linux code to put the
timestamp in the control_msg structure.
I tested this patch with af_packet sockets only. UDP & TCP might be a little
From: Philippe Gerum
set_fs() is on its way out, so we cannot open code a file read
operation by calling the VFS handler directly anymore, faking a user
address space.
We do have kernel interfaces for loading files though, particularly
kernel_read_file(). So let's use that one for loading the
From: Philippe Gerum
Since kernel v5.8, __vmalloc() does not take protection bits as
PROT_KERNEL is now wired in. Therefore we cannot disable the cache for
the UMM segment via the allocation call directly anymore.
This said, we don't support any CPU architecture exhibiting cache
aliasing
From: Philippe Gerum
The legacy x86_32 architecture is on its way out, with no support from
Dovetail. Besides, it went untested with I-pipe configurations for
many moons.
We still keep 32bit compat mode available for building the user-space
libraries and executables though, along with
This prepares drivers for kernel 5.10 and removes the obsolete x32 ABI
as well as support for 32-bit x86 kernels.
After this, the dovetail queue should only contain directly
dovetail-related changes, nothing that could affect older kernels with
I-pipe.
Jan
CC: Philippe Gerum
Philippe Gerum
From: Philippe Gerum
Signed-off-by: Philippe Gerum
---
kernel/drivers/testing/heapcheck.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/kernel/drivers/testing/heapcheck.c
b/kernel/drivers/testing/heapcheck.c
index 023a06ca64..207f20921f 100644
---
From: Philippe Gerum
Signed-off-by: Philippe Gerum
---
testsuite/smokey/main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/testsuite/smokey/main.c b/testsuite/smokey/main.c
index 5702e825a0..f24c1e990b 100644
--- a/testsuite/smokey/main.c
+++ b/testsuite/smokey/main.c
@@ -31,6 +31,7 @@
From: Philippe Gerum
After raising the topic of (dis)continuing support for the x32 ABI
multiple times on the mailing list, it turned out that Xenomai has no
known users of this dying ABI. So let's remove it.
Signed-off-by: Philippe Gerum
---
.../x86/include/asm/xenomai/uapi/syscall.h| 8
From: Philippe Gerum
Since v5.9-rc1, csum_partial_copy_nocheck() forces a zero seed as its
last argument to csum_partial(). According to #cc44c17baf7f3, passing
a non-zero value would not even yield the proper result on some
architectures. However, other locations still expect a non-zero csum
Le 12/05/2021 à 08:57, Jan Kiszka a écrit :
On 11.05.21 18:05, Jean-Baptiste Trédez via Xenomai wrote:
Update fec driver for xenomai 3 and linux kernel 5.4 and add I.MX8 support
Patch 1 to 27 : rtnet-mcast+vlan branch from Philippe Gerum with updated
driver for 4.18.85 kernel
Patch 28 to
From: Jan Kiszka
Ordering for pure aesthetic reasons, naming to align with the branch
names from the main Xenomai repo. The latter will help with setting
triggers.
Signed-off-by: Jan Kiszka
---
ci/child_pipelines_artifacts.yml| 12 ++--
ci/child_pipelines_no_artifacts.yml | 12
From: Jan Kiszka
This couples pushing to next and stable branches with running
xenomai-images, and then only the affected child pipeline. Precondition
is setting XENOMAI_IMAGES_TOKEN as protected CI/CD variable.
Signed-off-by: Jan Kiszka
---
.gitlab-ci.yml | 13 +
1 file changed,
From: Jan Kiszka
Only adds verbosity but no information. Keep it for the resource groups,
though, as they are board-related.
Signed-off-by: Jan Kiszka
---
ci/gitlab-ci-base.yml | 20 +++---
ci/kernel_4_19_xenomai_next.yml | 48 -
From: Jan Kiszka
Already done by including only one of the two files.
Signed-off-by: Jan Kiszka
---
ci/artifacts.yml| 4
ci/no-artifacts.yml | 3 ---
2 files changed, 7 deletions(-)
diff --git a/ci/artifacts.yml b/ci/artifacts.yml
index fb1549f..9d6b0e1 100644
--- a/ci/artifacts.yml
From: Jan Kiszka
Further reduces the duplicate parts in
child_pipelines_[no_]artifacts.yml.
Signed-off-by: Jan Kiszka
---
ci/child_pipelines_artifacts.yml| 14 ++
ci/child_pipelines_common.yml | 19 +++
ci/child_pipelines_no_artifacts.yml | 14
From: Jan Kiszka
This allows to set a filter variable when triggering the pipeline,
effectively running only one of the currently three child pipelines.
Will permit automatic triggering from the Xenomai repo on pushes to the
corresponding branches.
Signed-off-by: Jan Kiszka
---
From: Jan Kiszka
Also refactor a bit for better readability.
Signed-off-by: Jan Kiszka
---
ci/artifacts.yml | 8
ci/gitlab-ci-base.yml | 12
ci/no-artifacts.yml | 9 +
3 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/ci/artifacts.yml
From: Jan Kiszka
Variables do not propagate automatically to child pipelines. So define
this one in the artifact version of the child pipeline file.
Signed-off-by: Jan Kiszka
---
.gitlab-ci-artifacts.yml | 3 ---
ci/artifacts.yml | 4
2 files changed, 4 insertions(+), 3
This brings a number of improvements for our CI/CT:
- resource groups for board to avoid spinning actively on busy ones
- filter variable to run only for a specific Xenomai branch
- consolidation of the artifact/no-artifact cases
- fix for artifact child pipeline
With this and an upcoming CI
From: Jan Kiszka
By checking for USE_GITLAB_ARTIFACTS, we can share the scripts section.
This leaves the variation to the addition of artifacts.
Signed-off-by: Jan Kiszka
---
ci/artifacts.yml | 6 +-
ci/gitlab-ci-base.yml | 8
ci/no-artifacts.yml | 7 +--
3 files
From: Jan Kiszka
We currently have only one instance per board in our lab. So far, test
jobs requesting the same one can start in parallel and will then wait on
the LAVA cli, consuming job time. Avoid this at CI level already.
Signed-off-by: Jan Kiszka
---
ci/gitlab-ci-base.yml | 6 ++
1
On 12.05.21 00:04, Peter Laurich via Xenomai wrote:
> Hi,
>
> I am hoping that someone can help me to solve a problem that I am having
> with the Xenomai latency test.
>
> Here is my set up:
>
> * 4.9.146 kernel with ipipe patch (this is the last kernel version
> that supports 32-bit x86 and
On 11.05.21 18:05, Jean-Baptiste Trédez via Xenomai wrote:
> Update fec driver for xenomai 3 and linux kernel 5.4 and add I.MX8 support
>
> Patch 1 to 27 : rtnet-mcast+vlan branch from Philippe Gerum with updated
> driver for 4.18.85 kernel
> Patch 28 to 29 : update driver for 5.4 kernel and
On 12.05.21 04:08, Fangsuo Wu wrote:
> yes, to be more accurate, the issue is found in the libc file under
> gcc-linaro-arm-linux-gnueabihf-4.9-2014.08_linux/arm-linux-gnueabihf/libc/usr/include/pthread.h.
>
> The glibc is accompanied with the gcc I downloaded from
>
987 bytes
Desc: xenomai3-gdb-test.tar.gz
URL:
<http://xenomai.org/pipermail/xenomai/attachments/20210512/325958b3/attachment.bin>
30 matches
Mail list logo