>> So calling rt_intr_enable from user space would not always do the same
>> as xnarch_end_irq from the kernel, wouldn't it ?
>>
>
> No it would not, and this is what we want. The patch makes sure that calling
> rt_intr_enable/disable() will actually unmask/mask the interrupt at PIC level,
>
Gilles Chanteperdrix wrote:
>> Some embedded platforms have small TLB compared to the vm hungriness
of
>> certain real-time tasks. H_HUGETLB would reply on HugeTLB[1] backing
for
>> allocation. Scattered accesses to this memory would benefit in the
lower
>> pressure of minor page-faults/TLB ref
Tomas Kalibera wrote:
>
> Hi Philippe,
>
> thank you for the patch !
>
>> xnarch_end_irq() basically calls the ->unmask() method of the
>> interrupt chip
>> descriptor, which is the same as calling rt_intr_enable(). Before you
>> do that,
>>
> If I read the sources correctly, for "edge" and "
Hi Philippe,
thank you for the patch !
> xnarch_end_irq() basically calls the ->unmask() method of the interrupt chip
> descriptor, which is the same as calling rt_intr_enable(). Before you do that,
>
If I read the sources correctly, for "edge" and "simple" interrupt,
xnarch_end_irq() calls
On Thu, Apr 24, 2008 at 3:47 PM, Fillod Stephane
<[EMAIL PROTECTED]> wrote:
> Gilles Chanteperdrix wrote:
> >> PS: any plan on a H_HUGETLB one of those days?
> >
> >What would this do ?
>
> Some embedded platforms have small TLB compared to the vm hungriness of
> certain real-time tasks. H_HU
Gilles Chanteperdrix wrote:
>> PS: any plan on a H_HUGETLB one of those days?
>
>What would this do ?
Some embedded platforms have small TLB compared to the vm hungriness of
certain real-time tasks. H_HUGETLB would reply on HugeTLB[1] backing for
allocation. Scattered accesses to this memory woul
On Thu, Apr 24, 2008 at 2:01 PM, Fillod Stephane
<[EMAIL PROTECTED]> wrote:
> Gilles Chanteperdrix wrote:
> > This patch adds architecture independent support for non cached memory
> > mappings. This is necessary on ARM architecture with VIVT cache to
> share a
> >mapping between kernel and use
Gilles Chanteperdrix wrote:
> This patch adds architecture independent support for non cached memory
> mappings. This is necessary on ARM architecture with VIVT cache to
share a
>mapping between kernel and user-space, but may be used in other
situations
> (who knows).
So, the difference between H
Tomas Kalibera wrote:
> Hi,
>
> I think that when I handle interrupts from user space, I cannot
> correctly use I_NOAUTOENA. The thing is that this flag in fact means "do
> not call automatically xnarch_end_irq". The xnarch_end_irq call usually
> maps to unmasking the interrupt, but not always
On Thu, Apr 24, 2008 at 9:37 AM, Gilles Chanteperdrix
<[EMAIL PROTECTED]> wrote:
>
> On Thu, Apr 24, 2008 at 9:09 AM, Jan Kiszka <[EMAIL PROTECTED]> wrote:
> > Gilles Chanteperdrix wrote:
> > > Hi,
> > >
> > > the patch series to come for review adds support for user-space mutexes
> to the
On Thu, Apr 24, 2008 at 9:09 AM, Jan Kiszka <[EMAIL PROTECTED]> wrote:
> Gilles Chanteperdrix wrote:
> > Hi,
> >
> > the patch series to come for review adds support for user-space mutexes to
> the
> > posix skin. Since I wanted this support to be available on my AT91RM9200,
> the
> > patch
Gilles Chanteperdrix wrote:
> Hi,
>
> the patch series to come for review adds support for user-space mutexes to the
> posix skin. Since I wanted this support to be available on my AT91RM9200, the
> patch series start with patches which are mainly for the ARM architecture, to
> end with reimplemen
12 matches
Mail list logo
