Re: [PATCH] testsuite/psxclock: Check setting realtime clock

2022-08-03 Thread Chris Johns
On 4/8/2022 3:56 pm, Sebastian Huber wrote:
> Hello Chris,
> 
> On 02/08/2022 02:42, chr...@rtems.org wrote:
>> This patch adds a test to make sure threads sleeping on a
>> clock_nanosleep(CLOCK_REALTIME) call are not effected by a
>> change in the realtime clock via the clock_settime(CLOCK_REALTIME).
>>
>> The tests checks the sleeping thread's period using clock ticks.
>>
>> I have checked the test and Sebastian's patch on:
>>
>>   arm/xilinx_zynq_a9_qemu
>>   sparc/erc32
>>   aarch64/xilinx_zynqmp_lp64_zu3eg
> 
> I checked in the fix for relative CLOCK_REALTIME sleeps.

Great. I was waiting for you to merge that change before pushing this. :)

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] testsuite/psxclock: Check setting realtime clock

2022-08-03 Thread Sebastian Huber

Hello Chris,

On 02/08/2022 02:42, chr...@rtems.org wrote:

This patch adds a test to make sure threads sleeping on a
clock_nanosleep(CLOCK_REALTIME) call are not effected by a
change in the realtime clock via the clock_settime(CLOCK_REALTIME).

The tests checks the sleeping thread's period using clock ticks.

I have checked the test and Sebastian's patch on:

  arm/xilinx_zynq_a9_qemu
  sparc/erc32
  aarch64/xilinx_zynqmp_lp64_zu3eg


I checked in the fix for relative CLOCK_REALTIME sleeps.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: i2c device initialization on MVME3100 RTEMS5 (presumably also in 6?)

2022-08-03 Thread Chris Johns
On 3/8/2022 9:52 pm, Heinz Junkes wrote:
> We had a problem initialising the i2c devices on the MVME3100.
> Unfortunately, I still don't understand the order of initialisation.
> 
> However, the direct driver initialisation from bspstart no longer worked as 
> it did with older versions. 
> 
> My workaround therefore looks like this:
> 
> rtems@rtems-dev:~/MVME3100/kernel$ git diff 
> bsps/powerpc/mvme3100/start/bspstart.c
> diff --git a/bsps/powerpc/mvme3100/start/bspstart.c 
> b/bsps/powerpc/mvme3100/start/bspstart.c
> index 0ec215e33b..96d6e2f9cd 100644
> --- a/bsps/powerpc/mvme3100/start/bspstart.c
> +++ b/bsps/powerpc/mvme3100/start/bspstart.c
> @@ -52,6 +52,8 @@
>  extern unsigned long __rtems_end[];
>  extern unsigned  ppc_exc_lock_std, ppc_exc_gpr3_std;
> 
> +extern bool _IO_All_drivers_initialized;
> +
>  /*
>   * Copy Additional boot param passed by boot loader
>   */
> @@ -419,7 +421,14 @@ void bsp_start( void )
> 
>  static void mvme3100_i2c_initialize(void)
>  {
> +  printk(" call BSP_i2c_initialize() with 
> _IO_All_drivers_initialized = true\n");
> +  /*
> +   * we need the drivers registered as they appear, due to get
> +   * the i2c devices ready
> +   */
> +  _IO_All_drivers_initialized = true;
>BSP_i2c_initialize();
> +  _IO_All_drivers_initialized = false;
>  }

Where is this being called? I cannot see it in the patch. If it is BSP start I
think it is too early to make these calls.

>  RTEMS_SYSINIT_ITEM(
> 
> 
> You can find this in cpukit/sapi/src/ioregisterdriver.c:
> 
> 
>  if ( _IO_All_drivers_initialized ) {
> /* Other drivers have already been initialized, we initialize
>  * the driver directly.
>  */
> return rtems_io_initialize( major, 0, NULL );
>   } else {
> /* The driver will be initialized together with all other drivers
>  * in a later stage by _IO_Initialize_all_drivers().
>  */
> return RTEMS_SUCCESSFUL;
>   }
> 
> 
> I can imagine that this is not an elegant way, but it's the best I could do. 
> Is there any idea how to do it "right"?
> Or should I submit this patch?
I suspect touching that internal variable is not great. That variable could go
away or be made static.

There maybe another BSP hook that could be used or a SYSINIT hook maybe be 
needed.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel