regs->r20 = 0;
> stack = ((struct switch_stack *) regs) - 1;
> *childstack = *stack;
> childstack->r26 = (unsigned long) ret_from_fork;
> --
> 1.9.3
>
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubsc
Richard Henderson writes:
> On 07/30/2014 12:04 PM, Måns Rullgård wrote:
>> Richard Henderson writes:
>>
>>> The assignment to regs->r20 kills the original tls_val input
>>> to the clone syscall, which means that clone can no longer be
>>> restart
one as well?
You say that like user-selectable options are somehow evil. The kernel
is not Gnome.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
addr 0x%lx" "
> [0x%lx:0x%lx]\n",
> vaddr, kaddr, kstart, kend);
> #endif
If you're doing this, you should merge the strings too.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe
get the flags part correct.
>>
>> Now lets look at what you did. For the size you had:
>
> That should have read "For the count you had:"
>
> Oh well, you get my point anyway.
I have some doubts about the last bit.
--
Måns Rullgård
m...@mansr.com
--
To unsubs
Nick Krause writes:
> On Thu, Jul 24, 2014 at 12:15 PM, Måns Rullgård wrote:
>> Steven Rostedt writes:
>>
>>> On Thu, 24 Jul 2014 10:47:25 -0400
>>> Steven Rostedt wrote:
>>>
>>>> The three parameters are the number of elements, the size o
Nick Krause writes:
> On Thu, Jul 24, 2014 at 12:34 PM, Måns Rullgård wrote:
>> Nick Krause writes:
>>
>>> On Thu, Jul 24, 2014 at 12:15 PM, Måns Rullgård wrote:
>>>> Steven Rostedt writes:
>>>>
>>>>> On Thu, 24 Jul 2014 10:
ually makes real device interrupt overhead
>> lower), but I'd be very wary of using it in production.
>
> Darn it. I was actually hoping that someone else could have the
> reputation of doing "I can't believe they actually did this" code in the
> kernel.
Hey, I
R61801 wrong-code bug.
Are there any that with reasonable confidence do not?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ble is that most of the heavy-weight kernel developers don't
seem to care at all about what goes on in userspace.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordo
Peter Zijlstra writes:
> On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote:
>> Steven Rostedt writes:
>>
>> > Nice rant, I sympathize with you (just complaining about this on G+).
>>
>> Made my day.
>>
>> > I'm just wait
Peter Zijlstra writes:
> On Wed, Aug 13, 2014 at 10:24:58AM +0100, Måns Rullgård wrote:
>> Beware, even Gentoo will pull in systemd, if in a dormant state, unless
>> you are very careful.
>
> Right so I've not tried yet (busy see), but I meant to remove all the
> *Ki
Martin Steigerwald writes:
> Am Mittwoch, 13. August 2014, 10:27:56 schrieb Peter Zijlstra:
>> On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote:
>> > Steven Rostedt writes:
>> > > Nice rant, I sympathize with you (just complaining about this
azy argument.)
- It would be specific to Linux, so software can't rely on it anyway.
(This is an even lazier argument.)
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
sequence point
before a function call, after the arguments have been evaluated. Thus
all side-effects, such as the post-increment, must be complete before
the function is called, just like in the example.
There is no "re-arranging" here. The code is simply wrong.
--
Måns Rullgård
m..
Greg Kroah-Hartman writes:
> On Thu, Nov 06, 2014 at 08:49:01PM +0000, Måns Rullgård wrote:
>> Greg Kroah-Hartman writes:
>>
>> > On Thu, Nov 06, 2014 at 12:39:59PM +0100, Christian Riesch wrote:
>> >> The current implementation of put_tty_queue() causes a r
Greg Kroah-Hartman writes:
> On Thu, Nov 06, 2014 at 09:01:36PM +0000, Måns Rullgård wrote:
>> Greg Kroah-Hartman writes:
>>
>> > On Thu, Nov 06, 2014 at 08:49:01PM +, Måns Rullgård wrote:
>> >> Greg Kroah-Hartman writes:
>> >>
>> &g
Greg Kroah-Hartman writes:
> On Thu, Nov 06, 2014 at 09:38:59PM +0000, Måns Rullgård wrote:
>> Greg Kroah-Hartman writes:
>>
>> > On Thu, Nov 06, 2014 at 09:01:36PM +, Måns Rullgård wrote:
>> >> Greg Kroah-Hartman writes:
>> >>
>&g
Greg Kroah-Hartman writes:
> On Thu, Nov 06, 2014 at 10:12:54PM +0000, Måns Rullgård wrote:
>> Greg Kroah-Hartman writes:
>>
>> > On Thu, Nov 06, 2014 at 09:38:59PM +, Måns Rullgård wrote:
>> >> Greg Kroah-Hartman writes:
>> >>
>&g
Christian Riesch writes:
> On Thu, Nov 6, 2014 at 9:56 PM, Greg Kroah-Hartman
> wrote:
>> On Thu, Nov 06, 2014 at 08:49:01PM +, Måns Rullgård wrote:
>>> Greg Kroah-Hartman writes:
>>>
>>> > On Thu, Nov 06, 2014 at 12:39:59PM +0100, Christian Riesc
.) These sizes should be
selected properly to ensure error-free bus transfers. It is required
that the DMA write burst transfer does not cross the 8192-byte Data
FIS boundary, because the Transport Layer maintains the DMA state for
the duration of the Data FIS transmission.
--
Måns Rullgård
ps, build failure. Reverted for now.
>
> I suppose you have to pull material from Vinod.
The failure the build bot reported is due to the DMA patches not being
in the tree.
--
Måns Rullgård
amp;& DMADEVICES
> select DW_DMAC_CORE
> default y if 460EX
> help
> --
Isn't the proper fix here to have DW_DMAC_CORE select DMADEVICES?
--
Måns Rullgård
Arnd Bergmann writes:
> On Wednesday 11 May 2016 13:57:08 Måns Rullgård wrote:
>> > diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
>> > index 41b0725e58ad..8f7a4a4d2566 100644
>> > --- a/drivers/ata/Kconfig
>> > +++ b/drivers/ata/Kconfig
&
David Miller writes:
> From: Måns Rullgård
> Date: Wed, 11 Nov 2015 00:40:09 +
>
>> When the DMA complete interrupt arrives, the next chain should be
>> kicked off as quickly as possible, and I don't see why that would
>> benefit from being done in napi c
Måns Rullgård writes:
> David Miller writes:
>
>> From: Måns Rullgård
>> Date: Wed, 11 Nov 2015 00:40:09 +
>>
>>> When the DMA complete interrupt arrives, the next chain should be
>>> kicked off as quickly as possible, and I don't see why
Eric Dumazet writes:
> On Wed, 2015-11-11 at 13:04 +0000, Måns Rullgård wrote:
>
>> I tried that, and throughput (as measured by iperf3) dropped by 2%.
>> Maybe I did something wrong.
>
> What link speed have you used, what was the throughput you got,
> and is the
Mason writes:
> On 10/11/2015 22:51, Eric Dumazet wrote:
>
>> On Tue, 2015-11-10 at 21:21 +, Måns Rullgård wrote:
>>
>>> Even ixgbe uses napi_complete() while netdevice.h says one should
>>> "consider using napi_complete_done() instead." Did th
Eric Dumazet writes:
> On Wed, 2015-11-11 at 13:48 +0000, Måns Rullgård wrote:
>> Eric Dumazet writes:
>>
>> > On Wed, 2015-11-11 at 13:04 +, Måns Rullgård wrote:
>> >
>> >> I tried that, and throughput (as measured by iperf3) dro
Måns Rullgård writes:
> Eric Dumazet writes:
>
>> On Wed, 2015-11-11 at 13:48 +, Måns Rullgård wrote:
>>> Eric Dumazet writes:
>>>
>>> > On Wed, 2015-11-11 at 13:04 +, Måns Rullgård wrote:
>>> >
>>> >> I tried that,
David Miller writes:
> From: Måns Rullgård
> Date: Wed, 11 Nov 2015 13:04:07 +
>
>> Måns Rullgård writes:
>>
>>> David Miller writes:
>>>
>>>> From: Måns Rullgård
>>>> Date: Wed, 11 Nov 2015 00:40:09 +
>>>&
David Miller writes:
> From: Måns Rullgård
> Date: Wed, 11 Nov 2015 18:25:05 +
>
>> If the TX DMA channel is idle when start_xmit is called, it can be
>> started immediately. Checking the DMA status and starting it if
>> idle has to be done atomically somehow
David Miller writes:
> From: Måns Rullgård
> Date: Wed, 11 Nov 2015 19:09:19 +
>
>> David Miller writes:
>>
>>> From: Måns Rullgård
>>> Date: Wed, 11 Nov 2015 18:25:05 +
>>>
>>>> If the TX DMA channel is idle when start_x
David Miller writes:
> From: Måns Rullgård
> Date: Wed, 11 Nov 2015 19:17:07 +
>
>> David Miller writes:
>>
>>> From: Måns Rullgård
>>> Date: Wed, 11 Nov 2015 19:09:19 +
>>>
>>>> David Miller writes:
>>>>
David Miller writes:
> From: Måns Rullgård
> Date: Wed, 11 Nov 2015 19:25:46 +
>
>> David Miller writes:
>>
>>> From: Måns Rullgård
>>> Date: Wed, 11 Nov 2015 19:17:07 +
>>>
>>>> David Miller writes:
>>>>
David Miller writes:
> From: Måns Rullgård
> Date: Wed, 11 Nov 2015 19:35:05 +
>
>>> I don't think it's silly at all.
>>
>> I'm sure I read somewhere that the time spent spinning on a lock should
>> be kept as small as possible.
>&g
eduling on multi-issue CPUs
On a 12 CPU 750MHz Octeon cn5750 this patch improves ipv4 UDP packet
forwarding rates from 3.58*10^6 PPS to 3.99*10^6 PPS, or about 11%.
Signed-off-by: David Daney
To: linux-m...@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/pa
Mason writes:
> On 10/11/2015 20:25, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> On 10/11/2015 17:14, Mans Rullgard wrote:
>>>
>>>> This adds a driver for the Aurora VLSI NB8800 Ethernet controller.
>>>> It is an almost complete
void arch_spin_lock(arch_spinlock_t *lock)
>> static inline void arch_spin_unlock(arch_spinlock_t *lock)
>> {
>> unsigned int serving_now = lock->h.serving_now + 1;
>> -wmb();
>> +smp_mb();
>> lock->h.serving_now = (u16)serving_now;
>
Mason writes:
> [ CCing a few knowledgeable people ]
>
> Despite the subject, this is about an Atheros 8035 PHY :-)
>
> On 12/11/2015 15:04, Måns Rullgård wrote:
>
>> Mason wrote:
>>
>>> BTW, you're not using the PHY IRQ, right? I think I rem
Måns Rullgård writes:
> Mason writes:
>
>> [ CCing a few knowledgeable people ]
>>
>> Despite the subject, this is about an Atheros 8035 PHY :-)
>>
>> On 12/11/2015 15:04, Måns Rullgård wrote:
>>
>>> Mason wrote:
>>>
>>>>
t;
>
> Certainly we can load up the code with "SYNC" all over the place, but
> it will kill performance on SMP systems. So, my vote would be to make
> it as light weight as possible, but no lighter. That will mean
> inventing the proper barrier primitives.
It seems to me t
= at803x_ack_interrupt,
>> +.config_intr= at803x_config_intr,
>> .driver = {
>> .owner = THIS_MODULE,
>> },
>
>Shouldn't we take the opportunity to clean up the duplicated register
>definitions? (I&#x
Mason writes:
> On 12/11/2015 20:14, Florian Fainelli wrote:
>> On 12/11/15 11:09, Måns Rullgård wrote:
>>> On 12 November 2015 19:06:23 GMT+00:00, Mason wrote:
>>>> On 12/11/2015 18:40, Mans Rullgard wrote:
>>>>> Commit 77a993942 "phy/at8031: en
;vsc82xx_config_intr,
>
> I expected Documentation/CodingStyle to forbid taking the address
> of functions.
I can't find anything to that effect. That said, it's not something I
would normally do, but all the other phy_driver entries in that file
look like that.
--
Måns Rullgård
m.
tion returns.
Writing 1 to the counter asserts the reset immediately.
>> +static const struct of_device_id tangox_wdt_dt_ids[] = {
>> +{ .compatible = "sigma,smp8642-wdt" },
>
> So this is really for smp8642 only, not for any other chips in the series ?
It's for about a
er case, I think it would
> be either something like "sigma,smp86xx-wdt" or a list of all of them,
> but not "sigma,smp8642-wdt" to be used for all chips.
The general advice is to not use wildcards in DT bindings since the next
chip matching the pattern might not be compa
t/aurora/Kconfig
> +++ b/drivers/net/ethernet/aurora/Kconfig
> @@ -13,6 +13,7 @@ if NET_VENDOR_AURORA
>
> config AURORA_NB8800
> tristate "Aurora AU-NB8800 support"
> + depends on HAS_DMA
> select PHYLIB
> help
>Support for the AU
reg = <4 0xbffd1000 0x800>;
interrupt-parent = <&UIC3>;
- interrupts = <0x0 0x4 /* SATA */
- 0x5 0x4>; /* AHBDMA */
+ interrupts = <0x0 0x4>;
+ dmas = <&
;> +
>> +err = phy_power_on(hsdev->phy);
>> +if (err)
>> +goto error_out;
>> +
>> /*
>> * Now, register with libATA core, this will also initiate the
>> * device discovery process, invoking our port_start() handler &am
mpatible: "wlf,wm8974"
> + - reg: the I2C address or SPI chip select number of the device
> +
> +Examples:
> +
> +codec: wm8974@1a {
> + compatible = "wlf,wm8974";
> + reg = <0x1a>;
> +};
> --
> 2.6.3
>
--
Måns Rullgård
--
To uns
Mark Brown writes:
> On Wed, Dec 16, 2015 at 01:31:30PM +0000, Måns Rullgård wrote:
>
>> This is the 1/1 you were missing.
>
> I need the patch in a form I can apply.
I assumed your email client had some way of displaying the message I
replied to. Guess I was wrong.
>&g
Andy Shevchenko writes:
> On Tue, 2015-12-15 at 23:34 +0000, Måns Rullgård wrote:
>> Mans Rullgard writes:
>>
>> > Currently this driver only works with a DesignWare DMA engine which
>> > it
>> > registers manually using the second "reg" addr
. Is that the warnings
you refer to? I'm not getting any regular compiler warnings.
--
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
Sebastian Frias writes:
> - reading/writing to UART_DLL/UART_DLM directly are converted to using
> the read_dl/write_dl callbacks.
This should be an obvious fix. Please send that as a separate patch.
--
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe l
Andy Shevchenko writes:
> On Thu, 2015-12-17 at 15:19 +0000, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>> > On Tue, 2015-12-15 at 23:25 +, Mans Rullgard wrote:
>> > > This moves all global data into the driver private struct, thus
>> >
t(p, UART_DLL, old_dll);
> -serial_out(p, UART_DLM, old_dlm);
> serial_out(p, UART_LCR, old_lcr);
>
> return id;
> --
If you left the blank lines alone, the patch would end up much easier to
understand. In this diff, some of the lines listed as added or removed
hav
Andy Shevchenko writes:
> On Thu, 2015-12-17 at 15:13 +0000, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>> > On Tue, 2015-12-15 at 23:34 +, Måns Rullgård wrote:
>> > > Mans Rullgard writes:
>> > >
>> > > >
hat since it unconditionally
dereferences a null pointer in the probe function. My patch fixes that
as a side-effect.
--
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vge
t;
> The old code had some blank lines, which I suppose were there for clarity.
> I attempted to follow the same idea.
> But I don't mind changing the code as you wish.
It could well be that your patch results in a clearer final version, but
the diff is harder to parse when unchanged
Julian Margetson writes:
> On 12/17/2015 1:59 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> I have been running my machine mostly configured for pciex1 thus with
>>> the sata_dwc disabled.
>>> The changes to sata_dwc-460ex do cause an
Julian Margetson writes:
> On 12/17/2015 2:51 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/17/2015 1:59 PM, Måns Rullgård wrote:
>>>> Julian Margetson writes:
>>>>
>>>>> I have been running my machine most
Julian Margetson writes:
> On 12/17/2015 3:53 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/17/2015 2:51 PM, Måns Rullgård wrote:
>>>> Julian Margetson writes:
>>>>
>>>>> On 12/17/2015 1:59 PM, Måns Rullgård wro
Julian Margetson writes:
> On 12/17/2015 8:06 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/17/2015 3:53 PM, Måns Rullgård wrote:
>>>> Julian Margetson writes:
>>>>
>>>>> On 12/17/2015 2:51 PM, Måns Rullgård
Andy Shevchenko writes:
> On Thu, 2015-12-17 at 17:41 -0400, Julian Margetson wrote:
>> On 12/17/2015 3:53 PM, Måns Rullgård wrote:
>> > Julian Margetson writes:
>> >
>> > > On 12/17/2015 2:51 PM, Måns Rullgård wrote:
>> > > > Julian Marg
Julian Margetson writes:
> On 12/17/2015 8:06 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/17/2015 3:53 PM, Måns Rullgård wrote:
>>>> Julian Margetson writes:
>>>>
>>>>> On 12/17/2015 2:51 PM, Måns Rullgård
> [5.228546] Faulting instruction address: 0xc043a2c8
>>> [5.248577] Vector: 300 (Data Access) at [eddafae0]
>>> [5.268658] pc: c043a2c8: sata_dwc_qc_issue+0xb8/0x204
>> Well, that's not good. Can you translate that address to a line of code?
>>
7; to the kernel cmdline?
Enabling debug messages in the sata_dwc driver might also be informative.
--
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Julian Margetson writes:
> On 12/18/2015 8:45 AM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>>>> Builds now. Using my own .config.
>>>> What changed?
>>> I may have messed up the patch initially .
>> Probably. Let'
kes the code a bit simpler.
You really need to get used to that construct.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
the
counter, otherwise leave it running?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
asm ( "umlal %R0, %Q0, %R2, %Q3\n\t"
> + "umlal %R0, %1, %Q2, %R3\n\t"
> + "mov%R0, #0\n\t"
> + "adds %Q0, %1, %Q0\n\t"
> + "adc%R0, %R0, #0\n\t"
> + "umlal %Q0, %R0, %R2, %R3"
> + : "+&r" (res), "+&r" (tmp)
> + : "r" (m), "r" (n)
> + : "cc");
> + }
> +
> + return res;
> +}
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nicolas Pitre writes:
> On Thu, 19 Nov 2015, Måns Rullgård wrote:
>
>> Nicolas Pitre writes:
>>
>> > +static inline uint64_t __arch_xprod_64(uint64_t m, uint64_t n, bool bias)
>> > +{
>> > + unsigned long long res;
>> > + unsigned int tm
cument to some other mailing list (only) ?
> I see "PATCH 2/2" in some of your submissions, but I seem to be missing
> patch 1/2.
Blame scripts/get_maintaintainer.pl for that. Anyway, here it is:
http://article.gmane.org/gmane.linux.drivers.devicetree/144423
--
Måns Rullgård
m.
vel_irq,
>> + 0, 0, 0);
>> +if (err)
>> +panic("%s: failed to allocate irqchip", node->name);
>> +
>> +tangox_irq_domain_init(dom);
>> +
>> +for (i = 0; i < 64; i++)
>> +irq_create_mapping(dom, i);
>
> /me puzzled. What's that for? You really should never need something
> like this.
I had some reason for doing when I first wrote this code (MIPS, no DT),
but it's not needed now.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ect STMP_DEVICE
>> +
>> +config TANGOX_IRQ
>
> Question: Kevin Hilman said I should use tango instead of tangox
> for the arch directory. Does that advice extend to Kconfig names?
I suppose the same logic applies to all names.
--
Måns Rullgård
m...@mansr.com
--
To unsu
MIPS-based design
> tango4 is an ARM-based design (with one MIPS-based outlier).
> tango5 is an ARM-based design
>
> Although Mans is against the idea, I believe there should be one
> different clk driver for each arch.
It's essentially the same clock generator. It should be
part. Now
> you can deal with 8bit. Is this configurable on this SoC?
It's all 32 bits. The XLR driver uses a u32 * to access the registers.
--
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
Russell King - ARM Linux writes:
> On Tue, Nov 24, 2015 at 12:29:06PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Tue, Nov 24, 2015 at 12:10:02PM +, Måns Rullgård wrote:
>> >> Russell King - ARM Linux writes:
>> >
ing entries say just IRQ or something completely ad
hoc, only 4 IRQCHIP.
>> +bool
>> +select IRQ_DOMAIN
>> +select GENERIC_IRQ_CHIP
>
> Could you sort alphabetically, like the mach Kconfig?
Tell that to all the other ones. Oh well, whatever.
--
Måns Rullgård
m
chip->ctl + IRQ_CTL_LO + IRQ_STATUS);
> status_hi = intc_readl(chip, chip->ctl + IRQ_CTL_HI + IRQ_STATUS);
>
> (I'm a sucker for symmetry)
Nothing wrong with a little symmetry, though in this case I think the
extra macro only confuses matters.
--
Måns Rullgård
m...@mansr.com
--
T
really significant compared to the non trivial cost of a idiv
>instruction and all the complex infrastructure required to patch
>those branches directly, and consequently if the performance
>difference is actually worth it versus simply doing (2) alone.
Depending on the op
Nicolas Pitre writes:
> On Thu, 26 Nov 2015, Måns Rullgård wrote:
>
>> Nicolas Pitre writes:
>>
>> > 3) In fact I was wondering if the overhead of the branch and back is
>> >really significant compared to the non trivial cost of a idiv
>
Russell King - ARM Linux writes:
> On Thu, Nov 26, 2015 at 12:50:08AM +0000, Måns Rullgård wrote:
>> If not calling the function saves an I-cache miss, the benefit can be
>> substantial. No, I have no proof of this being a problem, but it's
>> something that
Mason writes:
> On 25/11/2015 13:12, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>>> + status_lo = intc_readl(chip, chip->ctl + IRQ_STATUS);
>>>> + status_hi = intc_readl(chip, chip->ctl + IRQ_CTL_HI + IRQ_STATUS);
>>>
>&
Nicolas Pitre writes:
> On Thu, 26 Nov 2015, Måns Rullgård wrote:
>
>> Russell King - ARM Linux writes:
>>
>> > On Thu, Nov 26, 2015 at 12:50:08AM +, Måns Rullgård wrote:
>> >> If not calling the function saves an I-cache miss, the benefit can be
>
t;
> Since you are implementing ethtool please add a driver
> info function.
I don't know what I'd set there that the fallback code doesn't.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
ead ARC) but IMHO this change may
> benefit other architectures as well.
I tried something similar for MIPS a while ago after noticing a similar
perf report. Adapting Nico's ARM code gave some nice speedups, but only
when I used MIPS assembly for the long multiplies. Apparently gcc is
Alexey Brodkin writes:
> Hi mans,
>
> On Thu, 2015-10-29 at 12:52 +0000, Måns Rullgård wrote:
>> Alexey Brodkin writes:
>>
>> > Existing default implementation of __div64_32() for 32-bit arches unfolds
>> > into huge routine with tons of arithmetics lik
Marc Gonzalez writes:
> On 20/01/2016 17:38, Måns Rullgård wrote:
>
>> Marc Gonzalez writes:
>>
>>> On 20/01/2016 17:25, Måns Rullgård wrote:
>>>
>>>> Marc Zyngier writes:
>>>>
>>>>> On 20/01/16 16:10, Måns R
Andy Shevchenko writes:
>> Tested on AVR32 (DMA driver) and Sigma SMP8642 (SATA driver).
>>
>> Code here:
>> https://bitbucket.org/mansr/linux-dwc/branch/dwc-sata
>
> Thanks for testing!
Have you had time to look any more at these patches?
--
Måns Rullgård
Andy Shevchenko writes:
> On Wed, 2016-01-20 at 18:50 +0000, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>> > > Tested on AVR32 (DMA driver) and Sigma SMP8642 (SATA driver).
>> > >
>> > > Code here:
>> > > https://bitb
Andy Shevchenko writes:
> On Wed, Jan 20, 2016 at 9:24 PM, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>>> On Wed, 2016-01-20 at 18:50 +, Måns Rullgård wrote:
>>>> Andy Shevchenko writes:
>>>>
>>>> >
Andy Shevchenko writes:
> On Wed, Jan 20, 2016 at 9:46 PM, Måns Rullgård wrote:
>
>>>>> One comment still regarding to lli types. We can avoid warnings by
>>>>> using (__force u32) in macros.
>>>>
>>>> But that won't give the be
writes:
> From: Alan Tull
>
> Add documentation for new FPGA bridge class's sysfs interface.
>
> Signed-off-by: Alan Tull
I don't see a patch in this email.
--
Måns Rullgård
IW ;-)
In my particular case, I can put whatever pinmux I want in the DT and
bring out the SPI signals, but I simply don't know what device will be
connected.
--
Måns Rullgård
Andy Shevchenko writes:
> On Wed, 2016-01-20 at 20:07 +0000, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>> > > > > > One comment still regarding to lli types. We can avoid
>> > > > > > warnings by
>> > > > >
Andy Shevchenko writes:
> On Fri, 2016-01-22 at 11:13 +0000, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>> > On Wed, 2016-01-20 at 20:07 +0000, Måns Rullgård wrote:
>> > > Andy Shevchenko writes:
>
>> > In DWC_DEFAULT_CTLLO() can we do tab i
Marc Gonzalez writes:
> On 20/01/2016 19:09, Måns Rullgård wrote:
>
>> Marc Gonzalez writes:
>>
>>> On 20/01/2016 17:38, Måns Rullgård wrote:
>>>
>>>> Marc Gonzalez writes:
>>>>
>>>>> On 20/01/2016 17:25, Måns Rullgård
> 100, 300).
I could've sworn I'd made that change. Too many versions of this patch
floating about...
> Otherwise,
>
> Acked-by: Rob Herring
>
>> +reg = <0x000 0x100>;
>> +interrupt-controller;
>> +#interrupt-cel
101 - 200 of 433 matches
Mail list logo
