Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.
Signed-off-by: matt mooney
---
arch/powerpc/kernel/vdso32/Makefile |6 +++---
arch/powerpc/kernel/vdso64/Makefile |6 +++---
arch/powerpc/kvm/Makefile |2 +-
arch/powerpc/lib/Makefile
> posting patches beats waiting for an indefinite amount of time :)
>
>Kim
Well, yes I suppose so.. Only I have noticed that only 1-2 people post
these kind of patches, so I thought maybe there were some kind of
unwritten agreement that no one else were to tamper with their work.
I will dig into
On Wed, 2010-09-22 at 16:04 +1000, Michael Neuling wrote:
> When irqblance attempts writes to the IPI smp_affinity (ie.
> /proc/irq/16/smp_affinity in the above example) it fails but irqbalance
> ignores currently ignores this.
>
> This patch catches these write fails and in this case adds that IR
Hi Matt,
On Wed, 22 Sep 2010 23:51:09 -0700 matt mooney wrote:
>
> Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.
This looks good. One comment below ...
> --- a/arch/powerpc/platforms/pseries/Makefile
> +++ b/arch/powerpc/platforms/pseries/Makefile
> @@ -1,10 +1,5 @@
> -i
> > + if (fwrite(line, strlen(line) - 1, 1, file) == 0)
>
> if (fputs(line, file) == EOF)
Good point thanks... new patch below
Mikey
irqbalance, powerpc: add IRQs without settable SMP affinity to banned list
On pseries powerpc, IPIs are registered with an IRQ number so
/proc/interru
On Thu, 2010-09-23 at 05:21 +0200, Chen, Tiejun wrote:
> > I can get the device to show up on the host's PCI bus, I can
>
> This only ensure you can access the PCIe configure space.
Not quite: I can also read the BARs that I program, and the memory
behind them on the PPC.
>
> > program the inbou
Running modules_install from a newly built 2.6.36-rc5 kernel
on my 32-bit PowerMac results in:
WARNING: Module
/lib/modules/2.6.36-rc5/kernel/drivers/i2c/busses/i2c-powermac.ko ignored, due
to loop
WARNING: Loop detected: /lib/modules/2.6.36-rc5/kernel/drivers/i2c/i2c-core.ko
needs of_i2c.ko wh
> -Original Message-
> From: Shawn Jin [mailto:shawnx...@gmail.com]
> Sent: Thursday, September 23, 2010 4:23 AM
> To: Chen, Tiejun
> Cc: Scott Wood; ppcdev; uboot
> Subject: Re: [U-Boot] cuImage and multi image?
>
> >> I have a large ramdisk image. The size of the image itself
> (i.e. t
On Thu, Sep 23, 2010 at 08:57:20PM +1000, Michael Neuling wrote:
>
> > > + if (fwrite(line, strlen(line) - 1, 1, file) == 0)
> >
> > if (fputs(line, file) == EOF)
>
> Good point thanks... new patch below
>
> Mikey
>
> irqbalance, powerpc: add IRQs without settable SMP affinity to banne
> -Original Message-
> From: David Hagood [mailto:david.hag...@gmail.com]
> Sent: Thursday, September 23, 2010 7:11 PM
> To: Chen, Tiejun; linuxppc-...@ozlabs.org
> Subject: RE: MPC8641D PEX: programming OWBAR in Endpoint mode?
>
> On Thu, 2010-09-23 at 05:21 +0200, Chen, Tiejun wrote:
>
>> -Original Message-
via the BARs.
>
> I read your email again and something hint me. I notice you clarify you
> already condigure InBound successfully.
I am programming BOTH the inbound ATMUs to make PPC memory available to
the root complex, AND programming outbound ATMUs to enable the
I've implemented a working driver on my 460EX. it allocates a couple
of buffers of 4MB each. I have a custom memcmp algorithm in asm that
is extremely fast in user space, but 1/2 as fast when run on these
buffers.
my tests are showing that the algorithm seems to be memory bandwidth
bound. my gu
Here is the sixth version of my patch set adding PTP hardware clock
support to the Linux kernel. The main difference to v5 is that the
character device interface has been replaced with one based on the
posix clock system calls.
The first three patches add necessary background support in the posix
This patch augments the POSIX clock code to offer a dynamic clock
creation method. Instead of registering a hard coded clock ID, modules
may call create_posix_clock(), which returns a new clock ID.
Signed-off-by: Richard Cochran
---
include/linux/posix-timers.h |7 ++-
include/linux/time
A new syscall is introduced that allows tuning of a POSIX clock. The
syscall is implemented for four architectures: arm, blackfin, powerpc,
and x86.
The new syscall, clock_adjtime, takes two parameters, the clock ID,
and a pointer to a struct timex. The semantics of the timex struct
have been expa
This patch adds a 'timesource' class into sysfs. Each registered POSIX
clock appears by name under /sys/class/timesource. The idea is to
expose to user space the dynamic mapping between clock devices and
clock IDs.
Signed-off-by: Richard Cochran
---
Documentation/ABI/testing/sysfs-timesource |
This patch adds an infrastructure for hardware clocks that implement
IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a
registration method to particular hardware clock drivers. Each clock is
presented as a standard POSIX clock.
The ancillary clock features are exposed in two di
This patch adds a driver that simulates a PTP hardware clock. The
driver serves as a simple example for writing real clock driver and
can be used for testing the PTP clock API.
The basic clock operations are implemented using the system clock,
and the ancillary clock operations are simulated.
Sig
The eTSEC includes a PTP clock with quite a few features. This patch adds
support for the basic clock adjustment functions, plus two external time
stamps, one alarm, and the PPS callback.
Signed-off-by: Richard Cochran
---
Documentation/powerpc/dts-bindings/fsl/tsec.txt | 57 +++
arch/powerpc/
This patch adds a driver for the hardware time stamping unit found on the
IXP465. The basic clock operations and an external trigger are implemented.
Signed-off-by: Richard Cochran
---
arch/arm/mach-ixp4xx/include/mach/ixp46x_ts.h | 78 ++
drivers/net/arm/ixp4xx_eth.c | 1
This patch adds support for the PTP clock found on the DP83640.
The basic clock operations and one external time stamp have
been implemented.
Signed-off-by: Richard Cochran
---
drivers/net/phy/Kconfig | 29 ++
drivers/net/phy/Makefile |1 +
drivers/net/phy/dp83640.c | 887 +
On Thu, 23 Sep 2010, Richard Cochran wrote:
> Support for obtaining timestamps from a PHC already exists via the
> SO_TIMESTAMPING socket option, integrated in kernel version 2.6.30.
> This patch set completes the picture by allow user space programs to
> adjust the PHC and to control its
On 20:19 Thu 23 Sep , Stephen Rothwell wrote:
> Hi Matt,
>
> On Wed, 22 Sep 2010 23:51:09 -0700 matt mooney wrote:
> >
> > Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.
>
> This looks good. One comment below ...
>
> > --- a/arch/powerpc/platforms/pseries/Makefile
> >
On Thu, 23 Sep 2010, Jacob Keller wrote:
> > There is a reason for not being able to shift posix clocks: The system has
> > one time base. The various clocks are contributing to maintaining that
> > sytem wide time.
> >
> > Adjusting clocks is absolutely essential for proper functioning of the PTP
On Thu, 23 Sep 2010 13:53:18 +0200 Mikael Pettersson wrote:
> Running modules_install from a newly built 2.6.36-rc5 kernel
> on my 32-bit PowerMac results in:
>
> WARNING: Module
> /lib/modules/2.6.36-rc5/kernel/drivers/i2c/busses/i2c-powermac.ko ignored,
> due to loop
> WARNING: Loop detected:
* Nathan Fontenot [2010-09-22 09:15:43]:
> This set of patches decouples the concept that a single memory
> section corresponds to a single directory in
> /sys/devices/system/memory/. On systems
> with large amounts of memory (1+ TB) there are performance issues
> related to creating the large
On Thu, 2010-09-23 at 12:53 -0500, Christoph Lameter wrote:
> On Thu, 23 Sep 2010, Richard Cochran wrote:
> > In contrast to the standard Linux system clock, a PHC is
> > adjustable in hardware, for example using frequency compensation
> > registers or a VCO. The ability to directly tun
On Thu, 2010-09-23 at 19:30 +0200, Richard Cochran wrote:
> Here is the sixth version of my patch set adding PTP hardware clock
> support to the Linux kernel. The main difference to v5 is that the
> character device interface has been replaced with one based on the
> posix clock system calls.
>
>
On Thu, 23 Sep 2010, john stultz wrote:
> This was my initial gut reaction as well, but in the end, I agree with
> Richard that in the case of one or multiple PTP hardware clocks, we
> really can't abstract over the different time domains.
My (arguably still superficial) review of the source does
On Thu, 23 Sep 2010, Richard Cochran wrote:
> +* Gianfar PTP clock nodes
> +
> +General Properties:
> +
> + - compatible Should be "fsl,etsec-ptp"
> + - reg Offset and length of the register set for the device
> + - interrupts There should be at least two interrupts. Some devices
>
On Thu, 2010-09-23 at 19:31 +0200, Richard Cochran wrote:
> A new syscall is introduced that allows tuning of a POSIX clock. The
> syscall is implemented for four architectures: arm, blackfin, powerpc,
> and x86.
>
> The new syscall, clock_adjtime, takes two parameters, the clock ID,
> and a point
From: Tiejun Chen
There exists a four line chunk of code, which when configured for
64 bit address space, can incorrectly set certain page flags during
the TLB creation. It turns out that this is legacy code that is no
longer required, but since it isn't obvious why this is legacy code
or why it
>So as far as the POSIX standard is concerned, offering a clock id
>to represent the PHC would be acceptable.
But completely useless as you may have more than one entirely different
time managed by PTP and in which you are not master but must work with
the timebases provided.
> /sys/
Randy Dunlap writes:
> On Thu, 23 Sep 2010 13:53:18 +0200 Mikael Pettersson wrote:
>
> > Running modules_install from a newly built 2.6.36-rc5 kernel
> > on my 32-bit PowerMac results in:
> >
> > WARNING: Module
> > /lib/modules/2.6.36-rc5/kernel/drivers/i2c/busses/i2c-powermac.ko ignored
> Please do not introduce useless additional layers for clock sync. Load
> these ptp clocks like the other regular clock modules and make them sync
> system time like any other clock.
I don't think you understand PTP. PTP has masters, a system can need to
be honouring multiple conflicting masters
On Thu, 2010-09-23 at 14:15 -0500, Christoph Lameter wrote:
> On Thu, 23 Sep 2010, john stultz wrote:
>
> > This was my initial gut reaction as well, but in the end, I agree with
> > Richard that in the case of one or multiple PTP hardware clocks, we
> > really can't abstract over the different ti
On Fri, Sep 17, 2010 at 6:42 PM, wrote:
> From: Tirumala Marri
> This patch combines drivers/dma/ppc4xx/xor.h and driver/dma/dma/ppc4xx/dma.h
> into drivers/dma/ppc4xx/ppx440spe-dma.h .
>
Is this just code churn, or do we gain anything by combining these
header files? Don't add "ppc440spe-" ba
On 9/17/2010 6:42 PM, tma...@apm.com wrote:
From: Tirumala Marri
This patch generalizes the existing drver/dma/ppc4xx/adma.c, so that
common code can be shared between different similar DMA engine
drivers in other SoCs.
Signed-off-by: Tirumala R Marri
---
drivers/dma/ppc4xx/adma.c| 43
On Thu, 23 Sep 2010, Alan Cox wrote:
> > Please do not introduce useless additional layers for clock sync. Load
> > these ptp clocks like the other regular clock modules and make them sync
> > system time like any other clock.
>
> I don't think you understand PTP. PTP has masters, a system can nee
On Thu, 23 Sep 2010 16:10:15 -0400
Paul Gortmaker wrote:
> So the possibility exists to wrongly assign the user MAS3_U bits
> to kernel (PAGE_KERNEL_X) address space via the following code fragment:
>
> if (flags & _PAGE_USER) {
>TLBCAM[index].MAS3 |= MAS3_UX | MAS3_UR;
>
On Thu, 2010-09-23 at 21:36 +0100, Alan Cox wrote:
> >So as far as the POSIX standard is concerned, offering a clock id
> >to represent the PHC would be acceptable.
>
> But completely useless as you may have more than one entirely different
> time managed by PTP and in which you are not ma
On Thu, 23 Sep 2010, john stultz wrote:
> > The HPET or pit timesource are also quite slow these days. You only need
> > access periodically to essentially tune the TSC ratio.
>
> If we're using the TSC, then we're not using the PTP clock as you
> suggest. Further the HPET and PIT aren't used to s
>
> > In contrast to the standard Linux system clock, a PHC is
> > adjustable in hardware, for example using frequency compensation
> > registers or a VCO. The ability to directly tune the PHC is
> > essential to reap the benefit of hardware timestamping.
>
> There is a reason for n
O> I don't see how this is a problem, as it exposes the multiple hardware
> clocks via different posix clock ids. So in the boundary clock case, you
> can configure which side is the client and which side is the master in a
> config file and the PTPd will appropriately steer them individually.
The
> There is no other scalable time source available for fast timer access
> than the time stamp counter in the cpu. Other time source require
> memory accesses which is inherently slower.
On what hardware ?
> An accurate other time source is used to adjust this clock. NTP does that
> via the clock
Alan Cox wrote:
Please do not introduce useless additional layers for clock sync. Load
these ptp clocks like the other regular clock modules and make them sync
system time like any other clock.
I don't think you understand PTP. PTP has masters, a system can need to
be honouring multiple conflic
Alan Cox wrote:
It implies clock tuning in userspace for a potential sub microsecond
accurate clock. The clock accuracy will be limited by user space
latencies and noise. You wont be able to discipline the system clock
accurately.
Noise matters, latency doesn't.
Well put! That's why we need
On Thu, 2010-09-23 at 15:49 -0500, Christoph Lameter wrote:
> On Thu, 23 Sep 2010, john stultz wrote:
>
> > > The HPET or pit timesource are also quite slow these days. You only need
> > > access periodically to essentially tune the TSC ratio.
> >
> > If we're using the TSC, then we're not using t
On Thu, 2010-09-23 at 15:33 -0500, Scott Wood wrote:
> I don't see a generic accessor that can test PTE flags for user
> access -- in the absence of one, I guess we need an ifdef here. Or at
> least put in a comment so anyone who adds a userspace use knows they
> need to fix it.
We could make up
On Thu, 2010-09-23 at 10:12 -0500, Ayman El-Khashab wrote:
> I've implemented a working driver on my 460EX. it allocates a couple
> of buffers of 4MB each. I have a custom memcmp algorithm in asm that
> is extremely fast in user space, but 1/2 as fast when run on these
> buffers.
>
> my tests ar
On Thu, 2010-09-23 at 22:30 +0100, Alan Cox wrote:
> O> I don't see how this is a problem, as it exposes the multiple hardware
> > clocks via different posix clock ids. So in the boundary clock case, you
> > can configure which side is the client and which side is the master in a
> > config file an
On Thu, 2010-09-23 at 19:31 +0200, Richard Cochran wrote:
> A new syscall is introduced that allows tuning of a POSIX clock. The
> syscall is implemented for four architectures: arm, blackfin, powerpc,
> and x86.
>
> The new syscall, clock_adjtime, takes two parameters, the clock ID,
> and a point
On Thu, 23 Sep 2010 22:16:32 +0200 Mikael Pettersson wrote:
> Randy Dunlap writes:
> > On Thu, 23 Sep 2010 13:53:18 +0200 Mikael Pettersson wrote:
> >
> > > Running modules_install from a newly built 2.6.36-rc5 kernel
> > > on my 32-bit PowerMac results in:
> > >
> > > WARNING: Module
> /
On Tue, Sep 21, 2010 at 10:41 PM, Kumar Gala wrote:
>
> On Sep 21, 2010, at 5:34 PM, Timur Tabi wrote:
>
>> On Tue, Sep 21, 2010 at 5:17 PM, Scott Wood wrote:
>>
>>> It needs to be the actual device that is performing the DMA -- the
>>> platform may need to do things such as IOMMU manipulation wh
From: Tirumala Marri
This patch creates new file with SoC dependent functions.
Signed-off-by: Tirumala R Marri
---
V1:
* Remove all 440SPe specific references.
* Move some of the code from header file to c file.
---
drivers/dma/ppc4xx/ppc4xx-adma.c | 1658 ++
From: Tirumala Marri
This patch merges dma.h and xor.h to create ppc440spe-dma.h
Signed-off-by: Tirumala R Marri
---
V1:
* No change.
---
drivers/dma/ppc4xx/dma.h | 223 -
drivers/dma/ppc4xx/ppc440spe-dma.h | 318
drive
On Fri, 24 Sep 2010, Benjamin Herrenschmidt wrote:
> On Thu, 2010-09-23 at 19:31 +0200, Richard Cochran wrote:
> > The new syscall, clock_adjtime, takes two parameters, the clock ID,
> > and a pointer to a struct timex. The semantics of the timex struct
> > have been expanded by one additional mode
On Fri, Sep 24, 2010 at 08:01:04AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2010-09-23 at 10:12 -0500, Ayman El-Khashab wrote:
> > I've implemented a working driver on my 460EX. it allocates a couple
> > of buffers of 4MB each. I have a custom memcmp algorithm in asm that
> > is extremely f
>
> Will both versions of this driver exist in the same kernel build? For
> example the iop-adma driver supports iop13xx and iop3xx, but we select
> the archtitecture at build time? Or, as I assume in this case, will
> the
> two (maybe more?) ppc4xx adma drivers all be built in the same image,
>
>
> Did you look at this changelog before sending? It just deletes 4000
> lines of code??
[Marri] The reason I have to send it in different file is the size of the
patch.
There seem to be issue with patch sizes 200k or more.
___
Linuxppc-dev mailing list
On 9/23/2010 3:10 PM, tma...@apm.com wrote:
From: Tirumala Marri
This patch generalizes the existing drver/dma/ppc4xx/adma.c, so that
common code can be shared between different similar DMA engine
drivers in other SoCs. Also Makefile and Kconfig changed to accommodate
PPC4XX.
Signed-off-by: Tir
On 9/23/2010 3:11 PM, tma...@apm.com wrote:
From: Tirumala Marri
This patch creates new file with SoC dependent functions.
Signed-off-by: Tirumala R Marri
---
V1:
* Remove all 440SPe specific references.
Maybe it renames ppc440spe to ppc4xx but it adds things like...
+#if defined(CONFIG_
On 9/23/2010 3:44 PM, Tirumala Marri wrote:
Did you look at this changelog before sending? It just deletes 4000
lines of code??
[Marri] The reason I have to send it in different file is the size of the
patch.
There seem to be issue with patch sizes 200k or more.
Read the rest of what I wrote
On Thu, 2010-09-23 at 17:35 -0500, Ayman El-Khashab wrote:
> Anything you allocate with kmalloc() is going to be mapped by bolted
> > 256M TLB entries, so there should be no TLB misses happening in the
> > kernel case.
> >
>
> Hi Ben, can you or somebody elaborate? I saw the pinned tlb in
> 44x_
On Fri, 2010-09-24 at 00:12 +0200, Thomas Gleixner wrote:
> > This list is getting way too much unrelated stuff, which I find
> > annoying, it would be nice if we were all a bit more careful here
> with
> > our CC lists.
>
> Says the guy who missed to trim the useless context of the original
> mai
On Fri, Sep 24, 2010 at 11:07:24AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2010-09-23 at 17:35 -0500, Ayman El-Khashab wrote:
> > Anything you allocate with kmalloc() is going to be mapped by bolted
> > > 256M TLB entries, so there should be no TLB misses happening in the
> > > kernel case.
> > No. The first pinned entry (0...256M) is inserted by the asm code in
> > head_44x.S. The code in 44x_mmu.c will later map the rest of lowmem
> > (typically up to 768M but various settings can change that) using more
> > 256M entries.
>
> Thanks Ben, appreciate all your wisdom and insight.
>
> -Original Message-
> From:
> linuxppc-dev-bounces+tiejun.chen=windriver@lists.ozlabs.or
> g
> [mailto:linuxppc-dev-bounces+tiejun.chen=windriver@lists.o
zlabs.org] On Behalf Of Scott Wood
> Sent: Friday, September 24, 2010 4:34 AM
> To: Gortmaker, Paul
> Cc: linuxppc-dev@lists.o
On Thu, 2010-09-23 at 09:13 -0400, Neil Horman wrote:
> On Thu, Sep 23, 2010 at 08:57:20PM +1000, Michael Neuling wrote:
> >
> > > > + if (fwrite(line, strlen(line) - 1, 1, file) == 0)
> > >
> > > if (fputs(line, file) == EOF)
> >
> > Good point thanks... new patch below
> >
> > M
> -Original Message-
> From:
> linuxppc-dev-bounces+tiejun.chen=windriver@lists.ozlabs.or
> g
> [mailto:linuxppc-dev-bounces+tiejun.chen=windriver@lists.o
> zlabs.org] On Behalf Of Benjamin Herrenschmidt
> Sent: Friday, September 24, 2010 5:59 AM
> To: Scott Wood
> Cc: Gortmaker,
> -Original Message-
> From: david.hag...@gmail.com [mailto:david.hag...@gmail.com]
> Sent: Thursday, September 23, 2010 10:44 PM
> To: Chen, Tiejun
> Cc: David Hagood; linuxppc-...@ozlabs.org
> Subject: RE: MPC8641D PEX: programming OWBAR in Endpoint mode?
>
> >> -Original Message---
> > > size_t size =3D 0;
> > > FILE *file;
> > > sprintf(buf, "/proc/irq/%i/smp_affinity", number);
> > > - file =3D fopen(buf, "r");
> > > + file =3D fopen(buf, "r+");
> > > if (!file)
> > >
On Friday 24 September 2010 00:39:47 Tirumala Marri wrote:
> > Will both versions of this driver exist in the same kernel build? For
> > example the iop-adma driver supports iop13xx and iop3xx, but we select
> > the archtitecture at build time? Or, as I assume in this case, will
> > the
> > two (
73 matches
Mail list logo
