Mark Brown <broo...@kernel.org> 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. G
ice discovery process, invoking our port_start() handler &
>> @@ -1331,6 +1348,7 @@ static int sata_dwc_probe(struct platform_device
>> *ofdev)
>> return 0;
>>
>> error_out:
>> +phy_exit(hsdev->phy);
>> iounmap(base);
>> return err;
>> }
> [...]
>
> MBR, Sergei
>
--
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/
interrupt-parent = <>;
- interrupts = <0x0 0x4 /* SATA */
- 0x5 0x4>; /* AHBDMA */
+ interrupts = <0x0 0x4>;
+ dmas = < 0 0 1>;
+ dma-names =
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...@v
reg = <4 0xbffd1000 0x800>;
interrupt-parent = <>;
- interrupts = <0x0 0x4 /* SATA */
- 0x5 0x4>; /* AHBDMA */
+ interrupts = <0x0 0x4>;
+ dmas = <
er had the registers 32bit apart. 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
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
a/Kconfig
> index a3c7106fdf85e78f..8ba7f8ff3434000f 100644
> --- a/drivers/net/ethernet/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
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
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);
>>>
>&
Mason <slash@free.fr> 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 <n...@fluxnic.net> writes:
> On Thu, 26 Nov 2015, Måns Rullgård wrote:
>
>> Russell King - ARM Linux <li...@arm.linux.org.uk> writes:
>>
>> > On Thu, Nov 26, 2015 at 12:50:08AM +, Måns Rullgård wrote:
>> >> If not calling
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 cou
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
>
ally 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 operand
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
--
To uns
s 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...@mansr.
Nicolas Pitre <n...@fluxnic.net> writes:
> On Thu, 26 Nov 2015, Måns Rullgård wrote:
>
>> Nicolas Pitre <n...@fluxnic.net> writes:
>>
>> > 3) In fact I was wondering if the overhead of the branch and back is
>> >really signif
and back is
>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
Russell King - ARM Linux <li...@arm.linux.org.uk> 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
>>
= intc_readl(chip, 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
of the existing 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
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:
>> >
Russell King - ARM Linux writes:
> On Tue, Nov 24, 2015 at 12:10:02PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Tue, Nov 24, 2015 at 11:38:53AM +0100, Arnd Bergmann wrote:
>> >> I suggested using -mcpu=cortex-a1
, Rd , CRn , CRm, 4
> |
> |for PJ4B is the same as:
> |
> |SDIV Rd , Rn, Rm
> |
> | on ARM cores.
> |
> |And:
> |
> |MRC p6, 1, Rd , CRn , CRm, 0
> |
> |for PJ4B is the same as:
> |
> |UDIV Rd , Rn, Rm
> |
> |on ARM cores.
> |
> |This is docum
a test
> build to check that -march=armv7ve or what-not really does work
> through both GCC and GAS.
If the compiler accepts the option but doesn't actually emit any div
instructions, is there any real harm?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the l
kernel in this form: we need to run a test
> build to check that -march=armv7ve or what-not really does work
> through both GCC and GAS.
If the compiler accepts the option but doesn't actually emit any div
instructions, is there any real harm?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe
Russell King - ARM Linux <li...@arm.linux.org.uk> writes:
> On Tue, Nov 24, 2015 at 12:10:02PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux <li...@arm.linux.org.uk> writes:
>>
>> > On Tue, Nov 24, 2015 at 11:38:53AM +0100, Arnd Bergmann wrote:
>
.
> |
> |This is documented in the "Extended instructions" section of the
> |PJ4B datasheet.
>
> I assume what he meant was that this is true for both PJ4 and PJ4B
> but not for PJ4B-MP, which has the normal udiv/sdiv instructions.
>
> IOW, anything with CPU implementer 0x56 part 0x581 should use those,
> while part 0x584 can use the sdiv/udiv that it reports correctly.
Or we could simply ignore those and they'd be no worse off than they are
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/
Russell King - ARM Linux <li...@arm.linux.org.uk> writes:
> On Tue, Nov 24, 2015 at 12:29:06PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux <li...@arm.linux.org.uk> writes:
>>
>> > On Tue, Nov 24, 2015 at 12:10:02PM +, Måns Rullgård wrote
Stephen Boyd writes:
> On 11/21, Måns Rullgård wrote:
>> Stephen Boyd writes:
>>
>> > +static int module_patch_aeabi_uidiv(unsigned long loc, const Elf32_Sym
>> > *sym)
>> > +{
>> > + extern char __aeabi_uidiv[], __aeabi_idiv[];
>> &g
Stephen Boyd <sb...@codeaurora.org> writes:
> On 11/21, Måns Rullgård wrote:
>> Stephen Boyd <sb...@codeaurora.org> writes:
>>
>> > +static int module_patch_aeabi_uidiv(unsigned long loc, const Elf32_Sym
>> > *sym)
>> > +{
>> > +
;0: fbb0 f0f1 udivr0, r0, r1
>4: 4770bx lr
>6: bf00nop
>
> 0008 :
>8: fb90 f0f1 sdivr0, r0, r1
>c: 4770bx lr
>e: bf00nop
Your compiler seems to default to
https://groups.google.com/a/dartlang.org/forum/#!topic/reviews/9wvsJvq0YYY
>just misinterpreted the flags
>
> b) the dartlag.org folks are correct, and it supports neither
>idivt nor idiva, and the /proc/cpuinfo flag is just wrong
>and requires a fixup
>
> c) like Krai
and requires a fixup
>
> c) like Krait, it actually implements both idiva and idivt but
>gets the reporting wrong.
It's trivial to test for someone who has one.
--
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/
t;
> :
>0: fbb0 f0f1 udivr0, r0, r1
>4: 4770bx lr
>6: bf00nop
>
> 0008 :
>8: fb90 f0f1 sdivr0, r0, r1
>c: 4770bx lr
>e: bf00nop
Your compiler see
Arnd Bergmann writes:
> On Saturday 21 November 2015 20:45:38 Måns Rullgård wrote:
>> On 21 November 2015 20:39:58 GMT+00:00, Arnd Bergmann wrote:
>> >On Friday 20 November 2015 17:23:14 Stephen Boyd wrote:
>> >> This is a respin of a patch series from about
complete configuration matrix. IIRC, all CPUs that support
>virtualization also do lpae (they have to) and all CPUs that
>do lpae also do idiv, but the opposite is not true.
>
> Arnd
The ARM ARM says anything with virt has idiv, lpae doesn't matter. ARMv7-R also
has idiv. I'
++--
> drivers/i2c/busses/i2c-xlr.c | 81
> +---
> 2 files changed, 80 insertions(+), 7 deletions(-)
Any comments on these patches?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
unsigned long *inst = *p;
> + *inst = udiv_insn;
> + }
> + for (p = __start_idiv_loc; p < __stop_idiv_loc; p++) {
> + unsigned long *inst = *p;
> + *inst = sdiv_insn;
> + }
> + }
> +}
These
Arnd Bergmann <a...@arndb.de> writes:
> On Saturday 21 November 2015 20:45:38 Måns Rullgård wrote:
>> On 21 November 2015 20:39:58 GMT+00:00, Arnd Bergmann <a...@arndb.de> wrote:
>> >On Friday 20 November 2015 17:23:14 Stephen Boyd wrote:
>> >> This is a
cores any more, to create the
>complete configuration matrix. IIRC, all CPUs that support
>virtualization also do lpae (they have to) and all CPUs that
>do lpae also do idiv, but the opposite is not true.
>
> Arnd
The ARM ARM says anything with virt has idiv, lpae doesn't matter. ARMv7-R al
s/i2c/busses/Kconfig | 6 ++--
> drivers/i2c/busses/i2c-xlr.c | 81
> +---
> 2 files changed, 80 insertions(+), 7 deletions(-)
Any comments on these patches?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the lin
unsigned long *inst = *p;
> + *inst = udiv_insn;
> + }
> + for (p = __start_idiv_loc; p < __stop_idiv_loc; p++) {
> + unsigned long *inst = *p;
> + *inst = sdiv_insn;
> + }
&g
too.
>
> Do you expect to have many different variations here? If not, I would
> get rid of all the child nodes and just hard code it in the driver.
Then how will other DT nodes reference the correct one?
--
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/
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 a single
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
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/
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_mapp
> select IRQ_DOMAIN
>> select 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.
--
blem?)
>
> tango3 was a 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 sam
>
> Your driver defines these offsets too.
>
> Do you expect to have many different variations here? If not, I would
> get rid of all the child nodes and just hard code it in the driver.
Then how will other DT nodes reference the correct one?
--
Måns Rullgård
m...@mansr.co
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år
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
;
> + "umlal %Q0, %R0, %R1, %R2"
> + : "+" (res)
> + : "r" (m), "r" (n)
> + : "cc");
> + } else {
> + asm ( "umlal %R0, %
er, 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/
uenter Roeck <li...@roeck-us.net>
>
> Did you send the bindings document 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://art
urn off 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/
sm ( "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"
> + : "+" (res), "+" (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 <nicolas.pi...@linaro.org> writes:
> On Thu, 19 Nov 2015, Måns Rullgård wrote:
>
>> Nicolas Pitre <nicolas.pi...@linaro.org> writes:
>>
>> > +static inline uint64_t __arch_xprod_64(uint64_t m, uint64_t n, bool bias)
>> > +{
>>
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/
s 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
s yours,
> may see benefits in having all drivers use the same APIs; and there may
> be other savings for ARCH_MULTIPLATFORM builds with lots of platforms.
I think the patch is good. If there are issues with clocksource_mmio
those should addressed separately.
--
Måns Rullgård
m...@mansr.c
delay_us))
>
> platdata->itc_setting = 1;
Drop that if(). Since we're ignoring of_property_read_u32() failing,
there is no need to test its return value, and code above incorrectly
makes the next statement conditional.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this lis
platdata->phy_clkgate_delay_us = pval;
You don't need to use the pval temporary as of_property_read_u32 only
modifies the destination on success.
--
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/
how a different perspective, such as yours,
> may see benefits in having all drivers use the same APIs; and there may
> be other savings for ARCH_MULTIPLATFORM builds with lots of platforms.
I think the patch is good. If there are issues with clocksource_mmio
those should addressed separ
-delay-us",
> + ))
> + platdata->phy_clkgate_delay_us = pval;
You don't need to use the pval temporary as of_property_read_u32 only
modifies the destination on success.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "
,
> + >phy_clkgate_delay_us))
>
> platdata->itc_setting = 1;
Drop that if(). Since we're ignoring of_property_read_u32() failing,
there is no need to test its return value, and code above incorrectly
makes the next statement conditional.
--
David Miller writes:
> From: Måns Rullgård
> Date: Mon, 16 Nov 2015 20:59:18 +
>
>> Anything else?
>
> Sorry, when I find one problem I give you the feedback for that
> and move on to the 100s of other patches I have in my queue.
Some people prefer to commen
et_device *dev, unsigned i, unsigned len)
> ...
>> +err = nb8800_alloc_rx(dev, i, true);
>
> It comes from an 'unsigned' value.
>
> Please pick one type and use it consistently.
Darn, missed one.
> Also, always fully spell out "unsigned int" rather than
David Miller <da...@davemloft.net> writes:
> From: Måns Rullgård <m...@mansr.com>
> Date: Mon, 16 Nov 2015 20:59:18 +
>
>> Anything else?
>
> Sorry, when I find one problem I give you the feedback for that
> and move on to the 100s of other patches I h
ly spell out "unsigned int" rather than use "unsigned"
> as a shorthand.
OK
Anything else?
--
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/
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 compatible at all. Ne
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 dozen SMP86xx, SMP87
on/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...@mansr.com
--
To unsubscribe from this list: send the line
ted 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...@mansr.com
--
To unsubscribe
s'
> before the function 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
ing list. Either 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 mig
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
3x_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'll send an inform
>
> 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 that t
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:
>>>
>>>>
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 remember
_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:
> 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
ng 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/patch/9
Mason <slash@free.fr> 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:
>>>>>
Mason <slash@free.fr> 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.
>>>
nclude/asm/spinlock.h
>> @@ -140,7 +140,7 @@ static inline 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();
&g
>
To: linux-m...@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/937/
Signed-off-by: Ralf Baechle <r...@linux-mips.org>
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
uld expand to
> something lighter weight than "SYNC"
>
> 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
Mason <slash@free.fr> 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
Måns Rullgård <m...@mansr.com> writes:
> Mason <slash@free.fr> 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:
>>
>&g
ad_status,
>> +.ack_interrupt = at803x_ack_interrupt,
>> +.config_intr= at803x_config_intr,
>> .driver = {
>> .owner = THIS_MODULE,
>> },
>
>Shouldn't we take the opportunity to clean up the duplicated
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.
>>
>>>
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: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: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 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 so
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 +
>>&g
401 - 500 of 818 matches
Mail list logo
