On Tue, May 12, 2009 at 08:40:05AM +0200, Takashi Iwai wrote:
> At Mon, 11 May 2009 21:54:51 +0200,
> Roel Kluin wrote:
> >
> > To avoid direct access to the driver_data pointer in struct device, the
> > functions dev_get_drvdata() and dev_set_drvdata() should be used.
> >
> > Signed-off-by: Roel
Hi all,
On Mon, 11 May 2009 22:37:09 +0530 Sachin Sant wrote:
>
> Jiri Pirko wrote:
> > Fri, May 08, 2009 at 09:57:22PM CEST, da...@davemloft.net wrote:
> >
> >> From: Sachin Sant
> >> Date: Fri, 08 May 2009 18:22:48 +0530
> >>
> >>
> >>> Todays Next failed to boot on a Power6 JS22 blade
I am working on changes to xilinx_lltemac.c that support both
the SDMA and FIFO TEMAC's.
I was wondering if anyone else had done anything already ?
I have it pretty much working with a few issues:
every so often the read FIFO gets out of sync and I have to
reset
At Mon, 11 May 2009 23:57:43 -0700,
Greg KH wrote:
>
> On Tue, May 12, 2009 at 08:40:05AM +0200, Takashi Iwai wrote:
> > At Mon, 11 May 2009 21:54:51 +0200,
> > Roel Kluin wrote:
> > >
> > > To avoid direct access to the driver_data pointer in struct device, the
> > > functions dev_get_drvdata()
On Mon, May 11, 2009 at 06:04:16PM -0600, Grant Likely wrote:
> > David: If you would like to have a discussion regarding particular
> > design tradeoffs, I'd be happy to, but since I doubt there is anyone on
> > this list who is interested in the vagaries of FPGA configuration
> > methods, I sugg
Hi Dave,
This fixes it (I wonder if this bug is lurking in any other drivers):
From: Stephen Rothwell
Date: Tue, 12 May 2009 17:24:02 +1000
Subject: [PATCH] net/ibmveth: fix panic in probe
netdev->dev_addr changed from being an array to being a pointer, so we
should not take its address for mem
Fixes a trivial spelling error in powerpc code comments.
Signed-off-by: Sankar P
---
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index 89497fb..3b52c80 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -2,7 +2,7 @@
* PowerPC64 SLB support.
*
* Copyright (C)
* Chris Friesen wrote:
> This started out as a thread on the ppc list, but on the
> suggestion of DaveM and Paul Mackerras I'm expanding the receiver
> list a bit.
>
> Currently, if a softirq is raised in process context the
> TIF_RESCHED_PENDING flag gets set and on return to userspace we
Tue, May 12, 2009 at 09:44:51AM CEST, s...@canb.auug.org.au wrote:
>Hi Dave,
>
>This fixes it (I wonder if this bug is lurking in any other drivers):
Grepping the sources I see some other places suffering this problem. I'll send
patch for this.
>
>From: Stephen Rothwell
>Date: Tue, 12 May 2009 17:
This is a re-post of patch series which adds MMIO support to Linux
RapidIO and fixes a few nits.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
The RIO memory map functions are used to support direct IO memory access
to RapidIO space. The patch adds its support for Freescale RapidIO block
driver.
Signed-off-by: Zhang Wei
Signed-off-by: Li Yang
---
arch/powerpc/sysdev/fsl_rio.c | 217 -
1 files
Instead of fixed address in old code.
Signed-off-by: Li Yang
---
arch/powerpc/sysdev/fsl_rio.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index abdb124..fa0720f 100644
--- a/arch/powerpc/sysdev
Signed-off-by: Li Yang
---
drivers/rapidio/rio-scan.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/rapidio/rio-scan.c b/drivers/rapidio/rio-scan.c
index 0838fb2..e29be3c 100644
--- a/drivers/rapidio/rio-scan.c
+++ b/drivers/rapidio/rio-scan.c
@@ -296,7 +29
Through the newly added IO memory access of RapidIO, sender can
write directly to recipient's rx buffer, either by cpu or DMA engine.
Signed-off-by: Zhang Wei
Signed-off-by: Li Yang
---
drivers/net/Kconfig | 10 ++
drivers/net/rionet.c | 365 +
Adding failure path for the following two cases.
warning: ignoring return value of 'device_add', declared with attribute
warn_unused_result
warning: ignoring return value of 'sysfs_create_bin_file', declared with
attribute warn_unused_result
Signed-off-by: Li Yang
---
drivers/rapidio/rio-scan
Add the mapping functions used to support direct IO memory access of
rapidIO.
Signed-off-by: Zhang Wei
Signed-off-by: Li Yang
---
drivers/rapidio/rio.c | 95 +++
include/linux/rio.h | 25
include/linux/rio_drv.h | 24 +
Hallo
we'd likes to use a RapidIO as a general communication bus on our new
product, and so I have some questions about general design of Linux RIO
subsystem. I did not find any better mailing list for RapidIO
discussion.
[1] - we'd like to implement following features
* Hot-plug (hot-inse
* Peter Zijlstra wrote:
> On Tue, 2009-05-12 at 10:12 +0200, Ingo Molnar wrote:
> > * Chris Friesen wrote:
> >
> > > This started out as a thread on the ppc list, but on the
> > > suggestion of DaveM and Paul Mackerras I'm expanding the receiver
> > > list a bit.
> > >
> > > Currently, if a
On Tue, 2009-05-12 at 10:12 +0200, Ingo Molnar wrote:
> * Chris Friesen wrote:
>
> > This started out as a thread on the ppc list, but on the
> > suggestion of DaveM and Paul Mackerras I'm expanding the receiver
> > list a bit.
> >
> > Currently, if a softirq is raised in process context the
On Tue, 2009-05-12 at 11:23 +0200, Ingo Molnar wrote:
>
> Yeah, that would be "nice". A single IRQ thread plus the process
> context(s) doing networking might perform well.
>
> Multiple IRQ threads (softirq and hardirq threads mixed) i'm not so
> sure about - it's extra context-switching cost.
On Tue, 12 May 2009, Sankar P wrote:
> Fixes a trivial spelling error in powerpc code comments.
>
> Signed-off-by: Sankar P
Applied to trivial tree, thanks.
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozla
Stephen Rothwell wrote:
Hi Dave,
This fixes it (I wonder if this bug is lurking in any other drivers):
Yes, there are some other exists. This spatch script can help to found this.
(http://www.emn.fr/x-info/coccinelle/)
# cat netdev_dev_addr.cocci
@@
struct net_device *dev;
@@
memcpy(
- &de
On Tue, May 12, 2009 at 01:33:55AM +0530, K.Prasad wrote:
>Hi PPC Dev folks,
> Please find a patch below that implements the proposed Hardware
>Breakpoint interfaces for PPC64 architecture.
>
>As a brief introduction, the proposed Hardware Breakpoint
>infrastructure provides generic in-kernel
On Tue, 12 May 2009, Peter Zijlstra wrote:
> On Tue, 2009-05-12 at 11:23 +0200, Ingo Molnar wrote:
> >
> > Yeah, that would be "nice". A single IRQ thread plus the process
> > context(s) doing networking might perform well.
> >
> > Multiple IRQ threads (softirq and hardirq threads mixed) i'm
I hate open ends, so for those interested.
I made a small change in u-boot and kernel and it works now.
btw. it makes a huge performance difference. The kernel boots
much slower and my user-space calculation now runs in 44 secs
(no data-cache) instead of 2.8 secs (with data-cache).
in u-boot th
On Tue, May 12, 2009 at 1:20 AM, David H. Lynch Jr. wrote:
> Anyway is there any interest in an LL FIFO TEMAC driver ?
> Or adding the FIFO code to the SDMA TEMAC code ? It only adds a
> couple of dozen lines to the driver.
yes to both.
BTW, when discussing the lltemac driver, you sh
Ingo Molnar wrote:
> * Chris Friesen wrote:
>>I think I see a possible problem with this. Suppose I have a
>>SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT set. Under
>>the scenario above, schedule() would re-run the spinning task
>>rather than ksoftirqd, thus preventing any incoming
On Tue, May 12, 2009 at 07:51:49AM -0400, Josh Boyer wrote:
> On Tue, May 12, 2009 at 01:33:55AM +0530, K.Prasad wrote:
> >- The patch is currently implemented only for PPC64 architecture. Other
> > architectures (especially Book-E implementations are expected to
> > happen in due course).
>
> D
This issue was resolved by flashing tot u-boot on the board. An engineer
at AMCC helped me solve this problem. It looks like even though we
bought the board very recently, somehow the u-boot version on the board
was much older.
Thanks
Shubhada
-Original Message-
From: Shubhada Pugaonkar
The current device tree for the MPC8272ADS assumes a mapping of 32 MB
of NOR flash at 0xFE00., while there are actually only 8 MB on
the boards, mapped at 0xFF80.. When booting an uImage with such a
device tree, the kernel crashes because 0xFE00. is not mapped.
Also introduce aliases f
On Tue, May 12, 2009 at 10:56:04AM +1000, Michael Neuling wrote:
> > Hi PPC Dev folks,
> > Please find a patch below that implements the proposed Hardware
> > Breakpoint interfaces for PPC64 architecture.
> >
> > As a brief introduction, the proposed Hardware Breakpoint
> > infrastructure prov
On Tue, May 12, 2009 at 07:51:49AM -0400, Josh Boyer wrote:
> On Tue, May 12, 2009 at 01:33:55AM +0530, K.Prasad wrote:
> >Hi PPC Dev folks,
> > Please find a patch below that implements the proposed Hardware
> >Breakpoint interfaces for PPC64 architecture.
> >
> >As a brief introduction, the p
On Tue, May 12, 2009 at 11:47:38AM -0500, Scott Wood wrote:
> On Tue, May 12, 2009 at 07:51:49AM -0400, Josh Boyer wrote:
> > On Tue, May 12, 2009 at 01:33:55AM +0530, K.Prasad wrote:
> > >- The patch is currently implemented only for PPC64 architecture. Other
> > > architectures (especially Book-
I have a device that I need to access via SPI. I am running 2.6.27 on
the MPC8313. I have configured the kernel with both CONFIG_SPI_MPC83xx
and CONFIG_SPI_SPIDEV. I hand made a character device with a major
number of 153 and a minor number of 0.
I need some guidance on how to make the SPI slav
The MPC8568/9 chips support MSIs on PCIe so no reason not to enable them.
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/mpc8568mds.dts | 16
arch/powerpc/boot/dts/mpc8569mds.dts | 16
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch
Previouslly we just always set the inbound window to 2G. This was
broken for systems with >2G. If a system has >=4G we will need
SWIOTLB support to handle that case.
We now allocate PCICSRBAR/PEXCSRBAR right below the lowest PCI outbound
address for MMIO or the 4G boundary (if the lowest PCI add
Its feasible based on how the PCI address map is setup that the region
of PCI address space used for MSIs differs for each PHB on the same SoC.
Instead of assuming that the address mappes to CCSRBAR 1:1 we read
PEXCSRBAR (BAR0) for the PHB that the given pci_dev is on.
Signed-off-by: Kumar Gala
In these configuration we expect to have large amounts of memory (> 4G)
and thus will bounce via swiotlb some region of PCI address space.
The outbound windows were wasting 512M of address space by leaving a
gap between the top of the outbound window and the 4G boundary. By
moving the top of the
On Tue, 12 May 2009 16:36:00 +0800
Li Yang wrote:
> + align = (size < 0x1000) ? 0x1000 : 1 << (__ilog2(size - 1) + 1);
> +
> + /* Align the size */
> + if ((lstart + size) > (_ALIGN_DOWN(lstart, align) + align)) {
__ilog2() and _ALIGN_DOWN() are powerpc-specific functions. It would
On Tue, 12 May 2009 16:36:01 +0800
Li Yang wrote:
> Through the newly added IO memory access of RapidIO, sender can
> write directly to recipient's rx buffer, either by cpu or DMA engine.
>
> ...
>
> +/* Definitions for rionet memory map driver */
> +#define RIONET_DRVID 0x101
> +#define
On Tue, 12 May 2009 16:36:02 +0800
Li Yang wrote:
> + if (rswitch) {
> + if (rswitch->route_table)
this `if' is unneeded.
> + kfree(rswitch->route_table);
> + kfree(rswitch);
> + }
___
Linuxppc-dev m
There already is a "default-on" trigger but there are problems with it.
For one, it's a inefficient way to do it and requires led trigger support
to be compiled in.
But the real reason is that is produces a glitch on the LED. The GPIO is
allocate with the LED *off*, then *later* when the trigger
On Tue, May 12, 2009 at 09:23:47AM +0200, Takashi Iwai wrote:
> At Mon, 11 May 2009 23:57:43 -0700,
> Greg KH wrote:
> >
> > On Tue, May 12, 2009 at 08:40:05AM +0200, Takashi Iwai wrote:
> > > At Mon, 11 May 2009 21:54:51 +0200,
> > > Roel Kluin wrote:
> > > >
> > > > To avoid direct access to th
On Tue, 12 May 2009 15:33:12 -0700
Trent Piepho wrote:
> + if (!strcmp(state, "keep")) {
> + led.default_state =
> LEDS_GPIO_DEFSTATE_KEEP;
> + } else if(!strcmp(state, "on")) {
> + led.default_state =
On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote:
> On Mon, May 11, 2009 at 7:12 PM, David Gibson
> wrote:
> > On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote:
> >> In other words; having your bootloader support FDT is preferred, but
> >> not required.
> >
> > I wouldn't e
On Tue, May 12, 2009 at 5:24 PM, David Gibson
wrote:
> On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote:
>> ... but I do agree that hard linking the .dtb into firmware, or making
>> the .dtb hard to upgrade is the way of madness.
>
> Ah, we're talking at cross purposes a bit then. Yea
Another possibility is to pad the DTB with a DESYNC command and the correct pad
frame, just in case it cannot be prevented.
Steve
> -Original Message-
> From: Grant Likely [mailto:grant.lik...@secretlab.ca]
> Sent: Monday, May 11, 2009 10:30 PM
> To: Stephen Neuendorffer
> Cc: David H.
Are we all using the same meaning of firmware ?
While firmware == BIOS is the norm for PC's
atleast in the embedded FPGA space firmware could mean the FPGA
programing that creates the hardware.
For an FPGA based system a dtb generated by the same software that
created the "firmw
Whenever I say firmware I mean executable code that executes when the
processor comes out of reset.
When I mean the FPGA bitstream, I say bitstream. :-)
g.
On Tue, May 12, 2009 at 6:13 PM, David H. Lynch Jr. wrote:
>
>
> Are we all using the same meaning of firmware ?
>
> While firmware
On Tue, May 12, 2009 at 08:13:19PM -0400, David H. Lynch Jr. wrote:
>
>
> Are we all using the same meaning of firmware ?
>
> While firmware == BIOS is the norm for PC's
Well, BIOS, or bootloader is what I'm meaning here.
> atleast in the embedded FPGA space firmware could mean th
On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote:
>
> Another possibility is to pad the DTB with a DESYNC command and the
> correct pad frame, just in case it cannot be prevented.
Um.. one thing I'm missing in this discussion of attaching the dtb to
the bitstream: I don't see
On Tue, May 12, 2009 at 8:36 PM, David Gibson
wrote:
> On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote:
>>
>> Another possibility is to pad the DTB with a DESYNC command and the
>> correct pad frame, just in case it cannot be prevented.
>
> Um.. one thing I'm missing in this d
From: Ingo Molnar
Date: Tue, 12 May 2009 11:23:48 +0200
>> Wouldn't the even better solution be to get rid of softirqs
>> all-together?
>>
>> I see the recent work by Thomas to get threaded interrupts
>> upstream as a good first step towards that goal, once the RX
>> processing is moved to a
From: Steven Rostedt
Date: Tue, 12 May 2009 08:20:51 -0400 (EDT)
> I'm going to be playing around with bypassing the net-rx/tx with my
> network drivers. I'm going to add threaded irqs for my network cards and
> have the driver threads do the work to get through the tcp/ip stack.
>
> I'll stil
On Wed, May 13, 2009 at 12:57:17PM +1000, David Gibson wrote:
> On Wed, May 13, 2009 at 01:55:45AM +0530, K.Prasad wrote:
> > On Tue, May 12, 2009 at 07:51:49AM -0400, Josh Boyer wrote:
> > > On Tue, May 12, 2009 at 01:33:55AM +0530, K.Prasad wrote:
> [snip]
> > I do see that Book-E processors will
On Wed, May 13, 2009 at 01:55:45AM +0530, K.Prasad wrote:
> On Tue, May 12, 2009 at 07:51:49AM -0400, Josh Boyer wrote:
> > On Tue, May 12, 2009 at 01:33:55AM +0530, K.Prasad wrote:
[snip]
> I do see that Book-E processors will have severe memory footprint
> constraints (in embedded environment) an
David Miller writes:
> I fully expected us to be, at this point, talking about putting the
> pending softirq check back into the trap return path :-/
Would that actually do any good, in the case where the system has
decided that ksoftirqd is handling soft irqs at the moment?
Paul.
__
From: Paul Mackerras
Date: Wed, 13 May 2009 15:15:34 +1000
> David Miller writes:
>
>> I fully expected us to be, at this point, talking about putting the
>> pending softirq check back into the trap return path :-/
>
> Would that actually do any good, in the case where the system has
> decided
At Tue, 12 May 2009 16:05:14 -0700,
Greg KH wrote:
>
> On Tue, May 12, 2009 at 09:23:47AM +0200, Takashi Iwai wrote:
> > At Mon, 11 May 2009 23:57:43 -0700,
> > Greg KH wrote:
> > >
> > > On Tue, May 12, 2009 at 08:40:05AM +0200, Takashi Iwai wrote:
> > > > At Mon, 11 May 2009 21:54:51 +0200,
> >
David Gibson wrote:
> On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote:
>
>> Another possibility is to pad the DTB with a DESYNC command and the
>> correct pad frame, just in case it cannot be prevented.
>>
>
> Um.. one thing I'm missing in this discussion of attaching t
On Wed, May 13, 2009 at 02:11:33AM -0400, David H. Lynch Jr. wrote:
> David Gibson wrote:
> > On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote:
> >
> >> Another possibility is to pad the DTB with a DESYNC command and the
> >> correct pad frame, just in case it cannot be preve
Hi Dave,
On Tue, 12 May 2009 17:44:51 +1000 Stephen Rothwell
wrote:
>
> From: Stephen Rothwell
> Date: Tue, 12 May 2009 17:24:02 +1000
> Subject: [PATCH] net/ibmveth: fix panic in probe
>
> netdev->dev_addr changed from being an array to being a pointer, so we
> should not take its address for
Hello Wolfgang,
> The current device tree for the MPC8272ADS assumes a mapping of 32 MB
> of NOR flash at 0xFE00., while there are actually only 8 MB on
> the boards, mapped at 0xFF80.. When booting an uImage with such a
> device tree, the kernel crashes because 0xFE00. is not mapped.
Hi.
On Tue, May 12, 2009 at 11:12:58AM +0200, Peter Zijlstra
(a.p.zijls...@chello.nl) wrote:
> Wouldn't the even better solution be to get rid of softirqs
> all-together?
And move tasklets into some thread context?
Only if we are ready to fix 7 times rescheduling regressions compared to
kernel
64 matches
Mail list logo
