Josh Boyer writes:
> + status = of_get_property(device, "status", NULL);
> + if (status == NULL)
> + return 1;
> +
> + if (!strcmp(status, "okay") || !strcmp(status, "ok"))
It would probably be good to defend against the possibility that the
property isn't null-terminated
Olof Johansson writes:
> Here's a set of updates for pasemi_mac for 2.6.26. Some of them touch
> the dma_lib in the platform code as well, but it's easier if it's all
> merged through netdev to avoid dependencies.
>
> Major highlights are jumbo frame support and ethtool basics, the rest
> is most
Martin Langer writes:
> Thanks for the hint. Inspired by that I did the logic the other way
> round. So we have the same default cases as we had before and
> additionally it will fit for the cores mentioned in the doc.
Care to resend this with a proper description and a Signed-off-by
line?
> +
Hi Kumar,
On Tue, Feb 26, 2008 at 01:39:20AM -0600, Kumar Gala wrote:
>
> On Feb 23, 2008, at 4:25 AM, Johannes Berg wrote:
>
>>
>>> But as I said in the same mail, processes still dies unexpectedly.
>>
>> Yeah, no idea though. I guess you could try putting that into the
>> arch/ppc Makefile, but
On Wed, 2008-02-20 at 20:57 -0600, Olof Johansson wrote:
> plain text document attachment (in-progress)
> Also stop both rx and tx sections before changing the configuration of
> the dma device during init.
>
> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
>
> Index: k.org/arch/powerpc/platfo
I have created a powerpc-next branch in the powerpc.git tree, which
has the following commits on it so far. The master branch is at the
same point. I've pulled in Dave Miller's tree (for the LMB changes)
and applied some other patches from the list.
I'm expecting that platform/subarchitecture ma
Josh Boyer wrote:
> On Fri, 22 Feb 2008 22:28:17 +0300
> Valentine Barshak <[EMAIL PROTECTED]> wrote:
>
>> This patch adds ibm_newemac phy clock workaround for 440EP/440GR emacs.
>> The code is based on the previous ibm_emac driver stuff. The 440EP/440GR
>> allows controlling each EMAC clock spear
Hi,
On Tue, Feb 26, 2008 at 10:46:06PM +1100, Michael Ellerman wrote:
> On Wed, 2008-02-20 at 20:57 -0600, Olof Johansson wrote:
> > + i = 1000;
> > + pasemi_write_dma_reg(PAS_DMA_COM_RXCMD, 0);
> > + while ((i > 0) && (pasemi_read_dma_reg(PAS_DMA_COM_RXSTA) & 1))
> > + i--;
> > +
On Tue, Feb 26, 2008 at 08:49:58PM +1100, Paul Mackerras wrote:
> Olof Johansson writes:
>
> > Here's a set of updates for pasemi_mac for 2.6.26. Some of them touch
> > the dma_lib in the platform code as well, but it's easier if it's all
> > merged through netdev to avoid dependencies.
> >
> > M
>>> +static inline void emac_rx_clk_default(struct emac_instance *dev)
>>> +{
>>> + if (emac_has_feature(dev, EMAC_FTR_440EP_PHY_CLK_FIX)) {
>>> + unsigned long flags;
>>> +
>>> + local_irq_save(flags);
>>> + mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) &
>>> +
On Feb 26, 2008, at 6:03 AM, Paul Mackerras wrote:
> I have created a powerpc-next branch in the powerpc.git tree, which
> has the following commits on it so far. The master branch is at the
> same point. I've pulled in Dave Miller's tree (for the LMB changes)
> and applied some other patches f
Benjamin Herrenschmidt wrote:
On Mon, 2008-02-25 at 19:47 -0600, Maynard Johnson wrote:
Hi,
I'm developing a kernel module that needs to parse the in-memory ELF
objects for a shared library (libc, to be specific). When running my
test on a 32-bit library, it works fine, but for a 64-bit libra
In order to get the proper boad info (bd_info) structure defined in ppcboot.h
both TARGET_4xx and TARGET_44x should be defined for all PowerPC 440 boards.
The 440GX boards also need TARGET_440GX defined since they have 4 EMACs and
there are 4 MAC addesses in bd_info passed by u-boot.
Signed-off-by
Maynard Johnson wrote:
>
> static long lib_addr;
> module_param(lib_addr, long, 0);
Should be unsigned long?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Tue, 26 Feb 2008 09:10:06 -0500
"Steven A. Falco" <[EMAIL PROTECTED]> wrote:
> When I saw Josh's question, I thought the irq save/restore was there to
> make the read-modify-write atomic; i.e. read SDR0_MFR, "AND" out some
> bits, then write it back without the possibility of anything else
> to
On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote:
> Hi,
>
> The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config option,
> the .config has been attached.
>...
Builds fine here.
Local problem (e.g. disk full) on your machine?
cu
Adrian
--
"Is there not
This patch from the 20th of February has not been taken into the latest
powerpc.git
Mvh,
Dag Rognlien
Date: Wed, 20 Feb 2008 12:33:38 -0600
From: Scott Wood <[EMAIL PROTECTED]>
Subject: [PATCH] Fix wrapper platform for adder875, and combine
defconfigs.
To: [EMAIL PROTECTED]
Cc: linuxpp
Nathan Lynch wrote:
> Maynard Johnson wrote:
> >
> > static long lib_addr;
> > module_param(lib_addr, long, 0);
>
> Should be unsigned long?
ulong, rather, but that doesn't fix it.
In any case, lib_addr is a user virtual address; doesn't the kernel
need to do get_us
Nathan Lynch wrote:
> Maynard Johnson wrote:
>> static long lib_addr;
>> module_param(lib_addr, long, 0);
>
> Should be unsigned long?
Right. I switched this to 'ulong', but that didn't make a difference in
my test results.
>
__
On Tue, Feb 26, 2008 at 11:39:55AM +1100, David Gibson wrote:
> > diff --git a/Makefile b/Makefile
> > index 8a47c34..d4d935c 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -16,7 +16,7 @@ LOCAL_VERSION =
> > CONFIG_LOCALVERSION =
> >
> > CPPFLAGS = -I libfdt
> > -CFLAGS = -Wall -g -Os
> >
Adrian Bunk wrote:
> On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote:
>> Hi,
>>
>> The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config option,
>> the .config has been attached.
>> ...
>
> Builds fine here.
>
> Local problem (e.g. disk full) on your machine?
>
>
Olof Johansson wrote:
> On Tue, Feb 26, 2008 at 08:49:58PM +1100, Paul Mackerras wrote:
>> Olof Johansson writes:
>>
>>> Here's a set of updates for pasemi_mac for 2.6.26. Some of them touch
>>> the dma_lib in the platform code as well, but it's easier if it's all
>>> merged through netdev to avoid
On Tue, Feb 26, 2008 at 11:48:29PM +0530, Kamalesh Babulal wrote:
> Adrian Bunk wrote:
> > On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote:
> >> Hi,
> >>
> >> The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config
> >> option,
> >> the .config has been attached.
> >
On Tue, Feb 26, 2008 at 01:21:00PM -0500, Jeff Garzik wrote:
> Olof Johansson wrote:
> > On Tue, Feb 26, 2008 at 08:49:58PM +1100, Paul Mackerras wrote:
> >> What route do you think these should take upstream? I'm happy to take
> >> them if Jeff is OK with that.
> >
> > I've sent them through Je
Hi All,
In order to define CONFIG_PPC_NEW_BINDING, which kernel configuration
parameters should be selected (i.e. .config file)?
Thanks in advance,
Bizhan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc
On Tue, Feb 26, 2008 at 10:31:21AM -0800, Bizhan Gholikhamseh (bgholikh) wrote:
> Hi All,
> In order to define CONFIG_PPC_NEW_BINDING, which kernel configuration
> parameters should be selected (i.e. .config file)?
The kconfig entry for your board should contain the line
"select PPC_CPM_NEW_BINDIN
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Tue, 26 Feb 2008 20:04:12 +1100
> It would probably be good to defend against the possibility that the
> property isn't null-terminated (for example if its length is zero).
FWIW, when I pull in the device tree on sparc I eliminate any need for
those
On Tue, 2008-02-26 at 13:34 -0800, David Miller wrote:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Tue, 26 Feb 2008 20:04:12 +1100
>
> > It would probably be good to defend against the possibility that the
> > property isn't null-terminated (for example if its length is zero).
>
> FWIW, w
Hi everybody, how to port ISP1760 USB host controller driver to Virtex ppc405
arch linux?
It has been ported to blackfin arch
http://blackfin.uclinux.org/gf/project/linux-kernel/scmsvn/?action=browse&path=%2Ftrunk%2Fdrivers%2Fusb%2Fhost%2Fpehcd%2Fhost%2F&pathrev=2763
--
View this message in conte
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Wed, 27 Feb 2008 08:45:37 +1100
> I doubt we do that. Properties that contain things like ranges, or "reg"
> properties are expected to be of a size that is a multiple of
> #size-cells/#address-cells and I'm not sure that won't break things he
On Tue, 2008-02-26 at 14:44 -0800, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Wed, 27 Feb 2008 08:45:37 +1100
>
> > I doubt we do that. Properties that contain things like ranges, or "reg"
> > properties are expected to be of a size that is a multiple of
> > #s
On Tue, 2008-02-26 at 08:49 -0600, Maynard Johnson wrote:
> 2. Compile C program as 32-bit; then run it. While the program is
> waiting for input, obtain its PID and do 'cat /proc//maps' to
> get
> the address of where libc is loaded.
> 3. From the dir where you build the uaccess_test kernel mo
On Tue, 26 Feb 2008 14:44:23 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Wed, 27 Feb 2008 08:45:37 +1100
>
> > I doubt we do that. Properties that contain things like ranges, or "reg"
> > properties are expected to be of a size th
On Tue, 2008-02-26 at 23:03 +1100, Paul Mackerras wrote:
> Benjamin Herrenschmidt (1):
> [POWERPC] Fix thinko in cpu_thread_mask_to_cores()
>
Any reason why this isn't going into .25 ?
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Benjamin Herrenschmidt writes:
> On Tue, 2008-02-26 at 23:03 +1100, Paul Mackerras wrote:
> > Benjamin Herrenschmidt (1):
> > [POWERPC] Fix thinko in cpu_thread_mask_to_cores()
> >
>
> Any reason why this isn't going into .25 ?
I thought you said nothing uses it.
Paul.
__
On Wed, 2008-02-27 at 11:43 +1100, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > On Tue, 2008-02-26 at 23:03 +1100, Paul Mackerras wrote:
> > > Benjamin Herrenschmidt (1):
> > > [POWERPC] Fix thinko in cpu_thread_mask_to_cores()
> > >
> >
> > Any reason why this isn't going
Kumar Gala writes:
> How do you plan on managing the powerpc-next branch in the future?
> For example, I assume at some point linus will pull it into what would
> be 2.6.26. Would you rebase this branch? etc.
Yes, it is basically the for-2.6.26 branch. I will try very hard not
to rebase i
This patch adds checks to the checking framework to verify that node
and property names contain only legal characters, and in the case of
node names there is at most one '@'.
At present when coming from dts input, this is mostly already ensured
by the grammer, however putting the check later means
Make some preliminary changes to cell_iommu_alloc_ptab() to allow it to
take the page size as a parameter rather than assuming IOMMU_PAGE_SIZE.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c | 28
1 files changed, 16 inse
It's called the fixed mapping, not the static mapping.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c
b/arch/powerpc/platforms/cell/iom
There's no need to allocate the pad page unless we're going to actually
use it - so move the allocation to where we know we're going to use it.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c | 12 ++--
1 files changed, 6 insertions(+), 6 dele
We use n_pte_pages to calculate the stride through the page tables, but
we also use it to set the NPPT value in the segment table entry. That is
defined as the number of 4K pages per segment, so we should calculate
it as such regardless of the IOMMU page size.
Signed-off-by: Michael Ellerman <[EMA
The only tricky part is we need to adjust the PTE insertion loop to
cater for holes in the page table. The PTEs for each segment start on
a 4K boundary, so with 16M pages we have 16 PTEs per segment and then
a gap to the next 4K page boundary.
It might be possible to allocate the PTEs for each seg
The cell IOMMU tce build and free routines use pte_offset to convert
the index passed from the generic IOMMU code into a page table offset.
This takes into account the SPIDER_DMA_OFFSET which sets the top bit
of every DMA address.
However it doesn't cater for the IOMMU window starting at a non-ze
Currently the cell IOMMU code allocates the entire IOMMU page table in a
contiguous chunk. This is nice and tidy, but for machines with larger
amounts of RAM the page table allocation can fail due to it simply being
too large.
So split the segment table and page table setup routine, and arrange to
The cell IOMMU code no longer needs to save the pte_offset variable
separately, it is incorporated into tbl->it_offset.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/pow
46 matches
Mail list logo
