* Florian Fainelli | 2012-10-19 15:40:29 [+0200]:
>On Friday 19 October 2012 11:36:25 Fainelli wrote:
>> Sebastian Andrzej Siewior linutronix.de> writes:
>> >
>> > No. You do have a compatible entry. It first appeared on the ce4100
>> > CPU. If it happens to also work on the n450 then it seems
* Florian Fainelli | 2012-10-19 15:40:29 [+0200]:
On Friday 19 October 2012 11:36:25 Fainelli wrote:
Sebastian Andrzej Siewior bigeasy at linutronix.de writes:
No. You do have a compatible entry. It first appeared on the ce4100
CPU. If it happens to also work on the n450 then it seems to
On Friday 19 October 2012 11:36:25 Fainelli wrote:
> Sebastian Andrzej Siewior linutronix.de> writes:
> >
> > No. You do have a compatible entry. It first appeared on the ce4100
> > CPU. If it happens to also work on the n450 then it seems to be
> > compatible with that one. "This" is
Sebastian Andrzej Siewior linutronix.de> writes:
>
> No. You do have a compatible entry. It first appeared on the ce4100
> CPU. If it happens to also work on the n450 then it seems to be
> compatible with that one. "This" is documented somewhere…
> Usually you add 'compatible = "your cpu",
Sebastian Andrzej Siewior bigeasy at linutronix.de writes:
No. You do have a compatible entry. It first appeared on the ce4100
CPU. If it happens to also work on the n450 then it seems to be
compatible with that one. This is documented somewhere…
Usually you add 'compatible = your cpu,
On Friday 19 October 2012 11:36:25 Fainelli wrote:
Sebastian Andrzej Siewior bigeasy at linutronix.de writes:
No. You do have a compatible entry. It first appeared on the ce4100
CPU. If it happens to also work on the n450 then it seems to be
compatible with that one. This is documented
On Sat, Aug 11, 2012 at 07:26:38PM +0200, Sebastian Andrzej Siewior wrote:
> * Thierry Reding | 2012-08-08 14:07:37 [+0200]:
>
> >With that in place, the driver code can match on "intel,hpet" to catch
> >all implementations and use the more specific entries if quirks are
> >required for the
On Sat, Aug 11, 2012 at 07:26:38PM +0200, Sebastian Andrzej Siewior wrote:
* Thierry Reding | 2012-08-08 14:07:37 [+0200]:
With that in place, the driver code can match on intel,hpet to catch
all implementations and use the more specific entries if quirks are
required for the specific
* Thierry Reding | 2012-08-08 14:07:37 [+0200]:
>With that in place, the driver code can match on "intel,hpet" to catch
>all implementations and use the more specific entries if quirks are
>required for the specific hardware.
from http://lkml.org/lkml/2011/2/16/350:
|"intel,ioapic" is probably
* Thierry Reding | 2012-08-08 14:07:37 [+0200]:
With that in place, the driver code can match on intel,hpet to catch
all implementations and use the more specific entries if quirks are
required for the specific hardware.
from http://lkml.org/lkml/2011/2/16/350:
|intel,ioapic is probably too
On Wed, Aug 08, 2012 at 01:51:36PM +0200, Sebastian Andrzej Siewior wrote:
> On 08/08/2012 12:46 PM, Thierry Reding wrote:
> >On another note, I saw that you've used the "intel,ce4100" prefix in
> >various places and I wonder if it would be useful to replace them with
> >something more generic
On 08/08/2012 12:46 PM, Thierry Reding wrote:
+ id = irq_domain_add_linear(np, num,
+ _irq_domain_ops,
+ (void *)ioapic_num);
This fits on two lines instead of three.
k
+ pr_err("Error creating mapping for the
On Mon, Aug 06, 2012 at 09:38:11AM +0200, Sebastian Andrzej Siewior wrote:
> The former conversion to irq_domain_add_legacy() did not fully work
> since we miss the irq decs for NR_IRQS_LEGACY+.
> Ideally we could use irq_domain_add_simple() or the no-map variant (and
> program the virq <-> line
On Mon, Aug 06, 2012 at 09:38:11AM +0200, Sebastian Andrzej Siewior wrote:
The former conversion to irq_domain_add_legacy() did not fully work
since we miss the irq decs for NR_IRQS_LEGACY+.
Ideally we could use irq_domain_add_simple() or the no-map variant (and
program the virq - line mapping
On 08/08/2012 12:46 PM, Thierry Reding wrote:
+ id = irq_domain_add_linear(np, num,
+ ioapic_irq_domain_ops,
+ (void *)ioapic_num);
This fits on two lines instead of three.
k
+ pr_err(Error creating mapping for
On Wed, Aug 08, 2012 at 01:51:36PM +0200, Sebastian Andrzej Siewior wrote:
On 08/08/2012 12:46 PM, Thierry Reding wrote:
On another note, I saw that you've used the intel,ce4100 prefix in
various places and I wonder if it would be useful to replace them with
something more generic like
On Mon, Aug 06, 2012 at 09:38:11AM +0200, Sebastian Andrzej Siewior wrote:
> The former conversion to irq_domain_add_legacy() did not fully work
> since we miss the irq decs for NR_IRQS_LEGACY+.
> Ideally we could use irq_domain_add_simple() or the no-map variant (and
> program the virq <-> line
The former conversion to irq_domain_add_legacy() did not fully work
since we miss the irq decs for NR_IRQS_LEGACY+.
Ideally we could use irq_domain_add_simple() or the no-map variant (and
program the virq <-> line mapping directly into ioapic) but this would
require a different irq lookup in
The former conversion to irq_domain_add_legacy() did not fully work
since we miss the irq decs for NR_IRQS_LEGACY+.
Ideally we could use irq_domain_add_simple() or the no-map variant (and
program the virq - line mapping directly into ioapic) but this would
require a different irq lookup in
On Mon, Aug 06, 2012 at 09:38:11AM +0200, Sebastian Andrzej Siewior wrote:
The former conversion to irq_domain_add_legacy() did not fully work
since we miss the irq decs for NR_IRQS_LEGACY+.
Ideally we could use irq_domain_add_simple() or the no-map variant (and
program the virq - line mapping
20 matches
Mail list logo
