[Xenomai] [PATCH] fixes for rpi 2b build
Small fix ups to enable building multi_v7_defconfig --- drivers/gpio/gpio-mvebu.c | 1 + drivers/gpio/gpio-pl061.c | 1 + drivers/gpio/gpio-zynq.c | 2 +- drivers/irqchip/irq-atmel-aic5.c | 6 -- drivers/irqchip/irq-bcm7120-l2.c | 15 +-- drivers/irqchip/irq-brcmstb-l2.c | 10 ++ drivers/irqchip/irq-dw-apb-ictl.c | 1 + drivers/pinctrl/pinctrl-rockchip.c | 8 drivers/soc/dove/pmu.c | 1 + 9 files changed, 28 insertions(+), 17 deletions(-) diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c index 50242fa..058362c 100644 --- a/drivers/gpio/gpio-mvebu.c +++ b/drivers/gpio/gpio-mvebu.c @@ -50,6 +50,7 @@ #include #include #include +#include #include "gpiolib.h" diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c index 97b093e..5f9be96 100644 --- a/drivers/gpio/gpio-pl061.c +++ b/drivers/gpio/gpio-pl061.c @@ -261,6 +261,7 @@ static void pl061_irq_mask_ack(struct irq_data *d) writeb(gpioie, pl061->base + GPIOIE); raw_spin_unlock(&pl061->lock); } +#endif static void pl061_irq_unmask(struct irq_data *d) { diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c index f961274..4dd3627 100644 --- a/drivers/gpio/gpio-zynq.c +++ b/drivers/gpio/gpio-zynq.c @@ -225,7 +225,6 @@ static int zynq_gpio_get_value(struct gpio_chip *chip, unsigned int pin) u32 data; unsigned int bank_num, bank_pin_num; struct zynq_gpio *gpio = gpiochip_get_data(chip); - unsigned long flags; zynq_gpio_get_bank_pin(pin, &bank_num, &bank_pin_num, gpio); @@ -306,6 +305,7 @@ static int zynq_gpio_dir_in(struct gpio_chip *chip, unsigned int pin) u32 reg; unsigned int bank_num, bank_pin_num; struct zynq_gpio *gpio = gpiochip_get_data(chip); + unsigned long flags; zynq_gpio_get_bank_pin(pin, &bank_num, &bank_pin_num, gpio); diff --git a/drivers/irqchip/irq-atmel-aic5.c b/drivers/irqchip/irq-atmel-aic5.c index 699a7be..4bbdd31 100644 --- a/drivers/irqchip/irq-atmel-aic5.c +++ b/drivers/irqchip/irq-atmel-aic5.c @@ -194,6 +194,7 @@ static void aic5_suspend(struct irq_data *d) struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d); int i; u32 mask; + unsigned long flags; if (smr_cache) for (i = 0; i < domain->revmap_size; i++) { @@ -201,7 +202,7 @@ static void aic5_suspend(struct irq_data *d) smr_cache[i] = irq_reg_readl(bgc, AT91_AIC5_SMR); } - irq_gc_lock(bgc); + flags = irq_gc_lock(bgc); for (i = 0; i < dgc->irqs_per_chip; i++) { mask = 1 << i; if ((mask & gc->mask_cache) == (mask & gc->wake_active)) @@ -224,8 +225,9 @@ static void aic5_resume(struct irq_data *d) struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d); int i; u32 mask; + unsigned long flags; - irq_gc_lock(bgc); + flags = irq_gc_lock(bgc); if (smr_cache) { irq_reg_writel(bgc, 0x, AT91_AIC5_SPU); diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c index 983640e..1224980 100644 --- a/drivers/irqchip/irq-bcm7120-l2.c +++ b/drivers/irqchip/irq-bcm7120-l2.c @@ -61,6 +61,7 @@ static void bcm7120_l2_intc_irq_handle(struct irq_desc *desc) struct bcm7120_l2_intc_data *b = data->b; struct irq_chip *chip = irq_desc_get_chip(desc); unsigned int idx; + unsigned long flags; chained_irq_enter(chip, desc); @@ -71,11 +72,11 @@ static void bcm7120_l2_intc_irq_handle(struct irq_desc *desc) unsigned long pending; int hwirq; - irq_gc_lock(gc); + flags = irq_gc_lock(gc); pending = irq_reg_readl(gc, b->stat_offset[idx]) & gc->mask_cache & data->irq_map_mask[idx]; - irq_gc_unlock(gc); + irq_gc_unlock(gc, flags); for_each_set_bit(hwirq, &pending, IRQS_PER_WORD) { generic_handle_irq(irq_find_mapping(b->domain, @@ -90,22 +91,24 @@ static void bcm7120_l2_intc_suspend(struct irq_chip_generic *gc) { struct bcm7120_l2_intc_data *b = gc->private; struct irq_chip_type *ct = gc->chip_types; +unsigned long flags; - irq_gc_lock(gc); + flags = irq_gc_lock(gc); if (b->can_wake) irq_reg_writel(gc, gc->mask_cache | gc->wake_active, ct->regs.mask); - irq_gc_unlock(gc); + irq_gc_unlock(gc, flags); } static void bcm7120_l2_intc_resume(struct irq_chip_generic *gc) { struct irq_chip_type *ct = gc->chip_types; +unsigned long flags; /* Restore the saved mask */ - irq_gc_lock(gc); + flags = irq_gc_lock(gc);
Re: [Xenomai] Reference Board
On 02/05/2018 05:22 PM, Greg Gallagher wrote: Hi, After the recent meet up we had, I had an idea to help with a couple of issues that we identified. One issue that was brought up is new users don't know how to get started with Xenomai, this impacts the community of users and downstream feedback we get. To help this problem I'm proposing we choose one hardware board (maybe more later) that we would ensure has proper Xenomai support. This would ensure that new users are able to try out Xenomai on real hardware and we (the Xenomai community) can make sure that it works well and gives new users a great experience as they get started with Xenomai. Based on popularity and availability I suggest we start with the Raspberry PI family of boards. They are pretty common and most people of this list probably have one or two (because of an office clean out at work, I now have almost one of each variant). The wide availability would make it easy to (eventually) distribute the testing across interested contributors and new Xenomai users. The other nice benefit is the ability to test and maintain a good set of example drivers for the raspberry PI platform. We can ensure that these RTDM drivers are using the most up to date interfaces and best practices. These could be examples that we point developers to when they try to create RTDM drivers for their own platform. I did a quick audit of what we currently support today in Xenomai for raspberry pi and we are only 3-4 drivers away from supporting most of what's on the board. Video drivers, GPU etc would be left to only the Linux domain for now. Creating and easy to use getting started wiki around the raspberry pi would give us the ability to create interesting examples using Xenomai that controls real hardware. We could provide pre-built images based on either buildroot or Ubuntu (I've done both of these for different pi boards with good success). This would give new users the ability to get their hands dirty pretty quickly and with out having to build everything from scratch. Once they get comfortable with Xenomai then they can move into building it from scratch and replacing bits and pieces of the stock images. The cost of doing this may seem steep at first, but I'm willing to take on a good chunk of the work and then hopefully the maintenance and testing won't prove to be too bad. As the idea becomes more clear hopefully other users or developers will help out. The benefit of doing this I believe will help with the ability to build a community around Xenomai and start to create a larger base of downstream users. If we think this is a good path to go down, I can post some more information on what I've already started and what needs to be done. Discussion and feedback would be appreciated :) I would definitely support this effort, RPI seems a good showcase for illustrating how the dual kernel architecture can be leveraged to get good latency figures with little overhead from the rt machinery on the whole system. I have a couple of RPIs I can test on. -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Reference Board
Technically we should be able to hit them all. The drivers don't really differ, most of them target the bcm2835. The larger work would be testing, we would need to build and test for v6, v7 and v8. Currently I've tested the Rpi2b and rpi zero w on Philippe's latest I-ipipe branch. I still need to verify RPI3 boots and works properly with the newest ipipe for ARM64. For the short term I'd like to start with 4.14 since it's that latest LTS kernel and then we can look at supporting older ones. I'd like to support the SLTS kernel if we port the ipipe to it. -Greg On Mon, Feb 5, 2018 at 11:52 AM, Lennart Sorensen wrote: > On Mon, Feb 05, 2018 at 11:22:46AM -0500, Greg Gallagher wrote: >> Hi, >>After the recent meet up we had, I had an idea to help with a >> couple of issues that we identified. One issue that was brought up is >> new users don't know how to get started with Xenomai, this impacts the >> community of users and downstream feedback we get. To help this >> problem I'm proposing we choose one hardware board (maybe more later) >> that we would ensure has proper Xenomai support. >>This would ensure that new users are able to try out Xenomai on >> real hardware and we (the Xenomai community) can make sure that it >> works well and gives new users a great experience as they get started >> with Xenomai. Based on popularity and availability I suggest we start >> with the Raspberry PI family of boards. They are pretty common and >> most people of this list probably have one or two (because of an >> office clean out at work, I now have almost one of each variant). The >> wide availability would make it easy to (eventually) distribute the >> testing across interested contributors and new Xenomai users. >>The other nice benefit is the ability to test and maintain a good >> set of example drivers for the raspberry PI platform. We can ensure >> that these RTDM drivers are using the most up to date interfaces and >> best practices. These could be examples that we point developers to >> when they try to create RTDM drivers for their own platform. I did a >> quick audit of what we currently support today in Xenomai for >> raspberry pi and we are only 3-4 drivers away from supporting most of >> what's on the board. Video drivers, GPU etc would be left to only the >> Linux domain for now. >> Creating and easy to use getting started wiki around the raspberry pi >> would give us the ability to create interesting examples using Xenomai >> that controls real hardware. We could provide pre-built images based >> on either buildroot or Ubuntu (I've done both of these for different >> pi boards with good success). This would give new users the ability >> to get their hands dirty pretty quickly and with out having to build >> everything from scratch. Once they get comfortable with Xenomai then >> they can move into building it from scratch and replacing bits and >> pieces of the stock images. >>The cost of doing this may seem steep at first, but I'm willing to >> take on a good chunk of the work and then hopefully the maintenance >> and testing won't prove to be too bad. As the idea becomes more clear >> hopefully other users or developers will help out. The benefit of >> doing this I believe will help with the ability to build a community >> around Xenomai and start to create a larger base of downstream users. >> >>If we think this is a good path to go down, I can post some more >> information on what I've already started and what needs to be done. >> Discussion and feedback would be appreciated :) > > So would that be the Pi, Pi 2 or Pi 3? A, or B or Zero? > > -- > Len Sorensen ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Reference Board
On Mon, Feb 05, 2018 at 11:22:46AM -0500, Greg Gallagher wrote: > Hi, >After the recent meet up we had, I had an idea to help with a > couple of issues that we identified. One issue that was brought up is > new users don't know how to get started with Xenomai, this impacts the > community of users and downstream feedback we get. To help this > problem I'm proposing we choose one hardware board (maybe more later) > that we would ensure has proper Xenomai support. >This would ensure that new users are able to try out Xenomai on > real hardware and we (the Xenomai community) can make sure that it > works well and gives new users a great experience as they get started > with Xenomai. Based on popularity and availability I suggest we start > with the Raspberry PI family of boards. They are pretty common and > most people of this list probably have one or two (because of an > office clean out at work, I now have almost one of each variant). The > wide availability would make it easy to (eventually) distribute the > testing across interested contributors and new Xenomai users. >The other nice benefit is the ability to test and maintain a good > set of example drivers for the raspberry PI platform. We can ensure > that these RTDM drivers are using the most up to date interfaces and > best practices. These could be examples that we point developers to > when they try to create RTDM drivers for their own platform. I did a > quick audit of what we currently support today in Xenomai for > raspberry pi and we are only 3-4 drivers away from supporting most of > what's on the board. Video drivers, GPU etc would be left to only the > Linux domain for now. > Creating and easy to use getting started wiki around the raspberry pi > would give us the ability to create interesting examples using Xenomai > that controls real hardware. We could provide pre-built images based > on either buildroot or Ubuntu (I've done both of these for different > pi boards with good success). This would give new users the ability > to get their hands dirty pretty quickly and with out having to build > everything from scratch. Once they get comfortable with Xenomai then > they can move into building it from scratch and replacing bits and > pieces of the stock images. >The cost of doing this may seem steep at first, but I'm willing to > take on a good chunk of the work and then hopefully the maintenance > and testing won't prove to be too bad. As the idea becomes more clear > hopefully other users or developers will help out. The benefit of > doing this I believe will help with the ability to build a community > around Xenomai and start to create a larger base of downstream users. > >If we think this is a good path to go down, I can post some more > information on what I've already started and what needs to be done. > Discussion and feedback would be appreciated :) So would that be the Pi, Pi 2 or Pi 3? A, or B or Zero? -- Len Sorensen ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] Reference Board
Hi, After the recent meet up we had, I had an idea to help with a couple of issues that we identified. One issue that was brought up is new users don't know how to get started with Xenomai, this impacts the community of users and downstream feedback we get. To help this problem I'm proposing we choose one hardware board (maybe more later) that we would ensure has proper Xenomai support. This would ensure that new users are able to try out Xenomai on real hardware and we (the Xenomai community) can make sure that it works well and gives new users a great experience as they get started with Xenomai. Based on popularity and availability I suggest we start with the Raspberry PI family of boards. They are pretty common and most people of this list probably have one or two (because of an office clean out at work, I now have almost one of each variant). The wide availability would make it easy to (eventually) distribute the testing across interested contributors and new Xenomai users. The other nice benefit is the ability to test and maintain a good set of example drivers for the raspberry PI platform. We can ensure that these RTDM drivers are using the most up to date interfaces and best practices. These could be examples that we point developers to when they try to create RTDM drivers for their own platform. I did a quick audit of what we currently support today in Xenomai for raspberry pi and we are only 3-4 drivers away from supporting most of what's on the board. Video drivers, GPU etc would be left to only the Linux domain for now. Creating and easy to use getting started wiki around the raspberry pi would give us the ability to create interesting examples using Xenomai that controls real hardware. We could provide pre-built images based on either buildroot or Ubuntu (I've done both of these for different pi boards with good success). This would give new users the ability to get their hands dirty pretty quickly and with out having to build everything from scratch. Once they get comfortable with Xenomai then they can move into building it from scratch and replacing bits and pieces of the stock images. The cost of doing this may seem steep at first, but I'm willing to take on a good chunk of the work and then hopefully the maintenance and testing won't prove to be too bad. As the idea becomes more clear hopefully other users or developers will help out. The benefit of doing this I believe will help with the ability to build a community around Xenomai and start to create a larger base of downstream users. If we think this is a good path to go down, I can post some more information on what I've already started and what needs to be done. Discussion and feedback would be appreciated :) Thanks Greg ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] Isolation of CPU (isolcpus=1). Unexpected better performance when RT thread is on core0.
thanks for your work on Xenomai :) Yann -- next part -- A non-text attachment was scrubbed... Name: NoIsolation.png Type: image/png Size: 15937 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20180205/771a79a2/attachment.png> -- next part -- A non-text attachment was scrubbed... Name: Core0.png Type: image/png Size: 15550 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20180205/771a79a2/attachment-0001.png> -- next part -- A non-text attachment was scrubbed... Name: Core1.png Type: image/png Size: 16104 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20180205/771a79a2/attachment-0002.png> ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai