RISC-V's FPU arch has the flag to permit/forbid using FPU. In Zephyr, this flag is set to
forbid side if thread was declared as not using FPU. And CPU raise interrupt when using
any FPU instruction at FPU forbidden state.

Katsuhiro Suzuki wrote:

Newer switching sets NEW thread handle into _current_cpu.current
BEFORE calling arch_switch().  This implementation will face a
problem in RISC-V environment if thread calls do_swap() explicitly
and switch to thread B (use FPU) from thread A (not use FPU)
because...

So... this is the very middle of a context switch.  The expectation of the kernel is that no exception/interrupt handlers are going to fire, because (by definition) if they do they will see corrupt/inconsistent thread state.  Or rather, if an architecture wants to allow that, it needs to be prepared to do the work.
I mean, the information is available to you: you know what the new thread is, because you're handed its switch handle which you created yourself.  You likewise know the old thread, because you're passed the address of its switch_handle field from which you can extract a pointer to the enclosing thread struct.  You know you're in the middle of a context switch, because arch_switch() was called.  You COULD write an FPU exception handler to detect this state and do the right thing.  I don't necessarily think this would be a good design, but it's possible.

Can you explain why you need to take an FPU exception in the middle of a context switch?  That seems a little questionable to me.  Why are you hitting lazy-saved FPU registers in a situation where it would be faster to just check the mask state to see if they are populated or not?  (Forgive me: I don't know the RISC-V FPU architecture, but I assume that's the situation you're in: the FPU registers may or may not be in use and using them if they aren't will trap.)

Andy

Hi,
On Wed, Sep 8, 2021 at 10:23 AM Katsuhiro Suzuki
<katsuhiro@...> wrote:

I have question about newer version of context switching (CONFIG_USE_SWITCH=y).

Does RISC-V support USE_SWITCH?

Newer switching sets NEW thread handle into _current_cpu.current BEFORE calling arch_switch().
This implementation will face a problem in RISC-V environment if thread calls do_swap() explicitly and switch to thread B (use FPU) from thread A (not use FPU) because...

AFAICS, even with v1.11, we are setting `_current` to `new_thread` in
`_Swap()` before calling `_arch_switch()`.
What version are you referring to as "older"?

Why do you `use _current_cpu` at all? `_arch_switch()` or
`arch_switch()` on the main branch takes
both new and old thread handles.

Best,

I have question about newer version of context switching (CONFIG_USE_SWITCH=y).

Newer switching sets NEW thread handle into _current_cpu.current BEFORE calling arch_switch().
This implementation will face a problem in RISC-V environment if thread calls do_swap() explicitly and switch to thread B (use FPU) from thread A (not use FPU) because...

Reminder: Zephyr Project: APIs

When:
09/07/2021
4:00pm to 5:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

Description:

Cancelled: Zephyr: Networking Forum

This event has been cancelled.

When:
Tuesday, September 7, 2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: tsc@...

Description:

Reminder: Zephyr: Networking Forum

When:
09/07/2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: tsc@...

An RSVP is requested. Click here to RSVP

Description:

Hi everyone

I am currently trying to write a driver for an STMicroelectronics LIS3DHH accelerometer. I based my code on the existing LIS2DH code that is already integrated in Zephyr and tried to adapt it to the LIS3DHH. Now when I try to build my project I get an error that i can't quite figure out where it is coming or originating from since it is occurring in an automatically generated file:

from /home/markus/driver_test_lis3dhh/my-workspace/zephyr/drivers/sensor/spi_lis3dhh/lis3dhh.c:7:
/home/markus/driver_test_lis3dhh/my-workspace/iots-fiso-id-p2-zephyr/build/zephyr/include/generated/devicetree_unfixed.h:24457:36: error: 'DT_N_S_soc_S_spi_40003800_S_lis3dhh_11_P_spi_max_frequency' undeclared here (not in a function); did you mean 'DT_N_S_soc_S_spi_40003800_S_lis3dhh_11_P_compatible_IDX_0'?
24457 | #define DT_N_INST_0_st_lis3dhh     DT_N_S_soc_S_spi_40003800_S_lis3dhh_11

I guess it looks like it is coming from the devicetree, but I can't see anything wrong with that one. I am doing all this on a custom board, so the devicetree I wrote myself - so I guess chances are high I did something wrong there, but I don't know what it could be.

So here is the relevant part of my devicetree if that helps:

&spi2 {
    pinctrl-0 = <&spi2_sck_pb13 &spi2_miso_pb14 &spi2_mosi_pb15>;/*PIN34,PIN35,PIN36*/
    cs-gpios = <&gpioc 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;/* PC6, Acc_CS */
    status = "okay";
 
    lis3dhh: lis3dhh@11 {
        compatible = "st,lis3dhh","st,spi_lis3dhh";
        reg = <0x11>;
        label = "LIS3DHH";
        spi-max-frequency = <10000000>; /*max. 10MHz*/
        int1-gpios = <&gpioc 7 GPIO_ACTIVE_HIGH>; /*PC7*/
        int2-gpios = <&gpioc 8 GPIO_ACTIVE_HIGH>;  /*PC8 */
    };
};

Any suggestions, hints or directions are very welcome.
Thanks in advance,
Markus

Zephyr: Toolchain Working Group

When:
09/06/2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: Torsten Rasmussen

Description:

Reminder: Zephyr: Toolchain Working Group

When:
09/06/2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: Torsten Rasmussen

An RSVP is requested. Click here to RSVP

Description: