On Thu, 2009-08-13 at 16:44 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-08-05 at 14:08 +0900, FUJITA Tomonori wrote:
>
> > The above swiotlb patchset was merged in -tip so I think that merging
> > this patchset via -tip too is the easiest way to handle this patchset.
> >
> > The patchset
On Wed, 2009-08-05 at 14:08 +0900, FUJITA Tomonori wrote:
> The above swiotlb patchset was merged in -tip so I think that merging
> this patchset via -tip too is the easiest way to handle this patchset.
>
> The patchset also is available via a git tree:
>
> git://git.kernel.org/pub/scm/linux/ker
On Tue, 2009-08-11 at 11:39 +0200, Bastian Blank wrote:
> The build of a PowerMac 32bit kernel currently fails with
>
> error: #warning "WARNING, CPUFREQ not recommended on SMP kernels"
>
> This patch just disables this driver on SMP kernels, as it is obviously
> not supported.
>
> Signed-off-by
Hi,
Feng Kan wrote:
This patch adds support for the AMCC (AppliedMicro) PPC460SX Eiger evaluation
board.
Signed-off-by: Tai Tri Nguyen
Acked-by: Feng Kan
Acked-by: Tirumala Marri
---
arch/powerpc/boot/dts/eiger.dts| 421 ++
arch/powerpc/configs/44x/eiger_defconfig |
Hello Anton,
i am trying to use the arch/powerpc/sysdev/simple_gpio.c driver,
for accessing some gpios, and found, that u8_gpio_get()
returns not only a 1 or a 0, instead it returns the real bit
position from the gpio:
gpioreturn
basevalue
0 0/0x01
1 0/0x02
2 0/0x04
3
On Sat, 2009-07-18 at 15:06 +0200, Michael Buesch wrote:
> This patch fixes a memory and semaphore leak in the viotape driver's
> char device write op. It leaks the DMA memory and the semaphore lock
> in case the device was opened with O_NONBLOCK.
>
> This patch is only compile tested, because I d
On Wed, Aug 12, 2009 at 08:45:18PM -0400, Len Brown wrote:
> On Thu, 13 Aug 2009, Dipankar Sarma wrote:
> > In a native system, I think we should the platform-specific code
> > export what makes sense. That may be just the lowest possible
> > state only. Or may be more than one.
>
> For x86, it is
On Thu, 2009-08-13 at 00:40 +0100, Russell King wrote:
> Maybe - and since you're just starting to look at clkdev, I'll point
> out that it's actually not intuitive which way around the "wildcard"
> matching works in clkdev. The clk_get() arguments aren't the
> wildcards, they're in the clk_looku
On Thu, 13 Aug 2009, Dipankar Sarma wrote:
> On Wed, Aug 12, 2009 at 01:58:06PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > May be having (to pick a number) 3 possible offline states for all
> > > platforms with one for halt equivalent and one for deepest possible that
> > > CPU can handle and o
We don't actually want kmemleak to track the lmb allocations, so we
pass min_count as 0. However telling kmemleak about lmb allocations
allows it to scan that memory for pointers to other memory that is
tracked by kmemleak, ie. slab allocations etc.
Signed-off-by: Michael Ellerman
---
lib/lmb.c
On Fri, Aug 07, 2009 at 11:39:58PM +, Kim Phillips wrote:
> don't do request->src vs. assoc pointer math - it's the same as adding
> assoclen and ivsize (just with more effort).
>
> Signed-off-by: Kim Phillips
All 3 patches applied. Thanks Kim!
--
Visit Openswan at http://www.openswan.org/
On Mon, 2009-08-10 at 15:05 +1000, Michael Ellerman wrote:
> We don't actually want kmemleak to track the lmb allocations, so we
> pass min_count as 0. However telling kmemleak about lmb allocations
> allows it to scan that memory for pointers to other memory that is
> tracked by kmemleak, ie. slab
This patch adds support for the AMCC (AppliedMicro) PPC460SX Eiger evaluation
board.
Signed-off-by: Tai Tri Nguyen
Acked-by: Feng Kan
Acked-by: Tirumala Marri
---
arch/powerpc/boot/dts/eiger.dts| 421 ++
arch/powerpc/configs/44x/eiger_defconfig | 1200 ++
On Mon, Aug 10, 2009 at 07:43:51PM +0530, M. Mohan Kumar wrote:
> [PATCH 1/2] Make dtstruct variable to be 8 byte aligned
>
> kexec is creating a version 3 device tree to be backwards compatible. This
> version of the struct has 8-byte alignment for properties whose value is 8 or
> more bytes. As
On Mon, Aug 10, 2009 at 07:44:42PM +0530, M. Mohan Kumar wrote:
> [PATCH 2/2] Support R_PPC64_REL32 relocation type
>
> gcc-4.4 compiler creates R_PPC64_REL32 relocation type in the ppc64
> purgatory code. Add support to handle R_PPC64_REL32 relocation type.
>
> Signed-off-by: M. Mohan Kumar
Th
> > Ok. So I may have misunderstood what names were for. In my mind, those
> > were the name of the clock input on the HW device :-)
>
> Oh, I do hope I didn't say that was wrong, because that is quite
> correct. What the idea with passing a NULL 'name' with drivers
> which only had one input was
On Thu, Aug 13, 2009 at 08:52:49AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-08-12 at 23:28 +0100, Russell King wrote:
>
> > On Thu, Aug 13, 2009 at 07:56:32AM +1000, Benjamin Herrenschmidt wrote:
> > > Maybe we can make clock-names non-optional though in the DT as an
> > > incentive not
> The problem is that you've got a chip which has a clock tree of its own
> which could benefit from using the clock API internally (in this case
> because it helps generalisation to the case where it's on the CPU for
> the MMC block to be able to just use the clock API for its clocks).
I see.
>
On Thu, Aug 13, 2009 at 08:32:53AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-08-12 at 23:20 +0100, Mark Brown wrote:
> > There was a recent thread on linux-kernel (last week) about the tmio_mmc
> > drivers - it's a MMC controller which is present in both some SH CPUs
> > and some MFD chi
Jonathan Haws wrote:
> All,
>
> I am having some issues with my target and was hoping that someone
> could lend a hand. I am using an AMCC 405EX (Kilauea) board running
> Linux kernel 2.6.31.
>
> Here is the problem. I have some code that receives jumbo frames via
> the EMAC, sticks the data in
On Wed, 2009-08-12 at 23:28 +0100, Russell King wrote:
> On Thu, Aug 13, 2009 at 07:56:32AM +1000, Benjamin Herrenschmidt wrote:
> > Maybe we can make clock-names non-optional though in the DT as an
> > incentive not to use the simple 1-clock "NULL" path.
>
> We used to pass names. Everyone got
On Wed, Aug 12, 2009 at 11:28:43PM +0100, Russell King wrote:
> We used to pass names. Everyone got the idea that they could ignore
> the struct device argument, and chaos ensued in drivers - people wanted
> to name each of their individual clk structures uniquely, and pass
> clock names, or even
On Wed, 2009-08-12 at 23:20 +0100, Mark Brown wrote:
> ...which is much easier if you discourage people from using the NULL
> name in the first place :)
Agreed.
> My concern is more about new device tree and
> older driver code than the other way round (which wouldn't suprise me,
> if only dur
On Thu, Aug 13, 2009 at 07:56:32AM +1000, Benjamin Herrenschmidt wrote:
> Maybe we can make clock-names non-optional though in the DT as an
> incentive not to use the simple 1-clock "NULL" path.
We used to pass names. Everyone got the idea that they could ignore
the struct device argument, and ch
On Thu, Aug 13, 2009 at 07:56:32AM +1000, Benjamin Herrenschmidt wrote:
> Maybe we can make clock-names non-optional though in the DT as an
> incentive not to use the simple 1-clock "NULL" path.
Yeah, that was more what I was thinking - apply some pressure on people
not to use the NULL clock feat
This patch adds support for the AMCC (AppliedMicro) PPC460SX Eiger evaluation
board.
Signed-off-by: Tai Tri Nguyen
Acked-by: Feng Kan
Acked-by: Tirumala Marri
---
arch/powerpc/boot/dts/eiger.dts| 421 ++
arch/powerpc/configs/44x/eiger_defconfig | 1200 ++
All,
I am having some issues with my target and was hoping that someone could lend a
hand. I am using an AMCC 405EX (Kilauea) board running Linux kernel 2.6.31.
Here is the problem. I have some code that receives jumbo frames via the EMAC,
sticks the data in a buffer, and writes the data out
All,
I am having some issues with my target and was hoping that someone could lend a
hand. I am using an AMCC 405EX (Kilauea) board running Linux kernel 2.6.31.
Here is the problem. I have some code that receives jumbo frames via the EMAC,
sticks the data in a buffer, and writes the data out
On Wed, 2009-08-12 at 22:44 +0100, Mark Brown wrote:
> On Thu, Aug 13, 2009 at 07:34:07AM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2009-08-12 at 13:35 +0100, Mark Brown wrote:
>
> > > What happens if another clock gets added or the list gets reordered for
> > > some reason?
>
> > The devi
On Thu, Aug 13, 2009 at 07:34:07AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-08-12 at 13:35 +0100, Mark Brown wrote:
> > What happens if another clock gets added or the list gets reordered for
> > some reason?
> The device-tree is mostly static in that regard. I'm not sure what you
> me
On Wed, 2009-08-12 at 13:35 +0100, Mark Brown wrote:
> On Wed, Aug 12, 2009 at 05:57:05PM +1000, Benjamin Herrenschmidt wrote:
>
> > - From the above, question: Do we want to keep that parent pointer ?
> > Does it make sense ? Will we have objects that are clock providers and
> > themselves sourc
On Wed, 2009-08-12 at 07:31 -1000, Mitch Bradley wrote:
> Padding a string violates a core principle of property representation,
> namely the "no alignment assumptions" one. The reason for that
> principle was the fact that alignment needs are not stable across
> processor families, or even wi
On Wed, 2009-08-12 at 08:40 -0500, Kumar Gala wrote:
> I'm in the same boat as you Josh. I think there is value and utility
> here but not sure what problem Ben's trying to solve.
Well, there's several things here.
First, it would be nice to improve clock management on some existing
SoCs. I'
Anton Vorontsov wrote:
> On Wed, Aug 12, 2009 at 04:45:55PM -0400, Michael Barkowski wrote:
>> Hello Anton,
>>
>> Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
>>
>> Then shouldn't you have the following change as well, near the end of
>> the function?
>>
>> -} else
On Wed, Aug 12, 2009 at 04:45:55PM -0400, Michael Barkowski wrote:
> Hello Anton,
>
> Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
>
> Then shouldn't you have the following change as well, near the end of
> the function?
>
> - } else if (data->nr_parts)
> + }
Hello Anton,
Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
Then shouldn't you have the following change as well, near the end of
the function?
- } else if (data->nr_parts)
+ } else if (data && data->nr_parts)
dev_warn(&spi->dev, "ignoring %
On Wed, Aug 12, 2009 at 01:58:06PM +0200, Pavel Machek wrote:
> Hi!
>
> > May be having (to pick a number) 3 possible offline states for all
> > platforms with one for halt equivalent and one for deepest possible that
> > CPU can handle and one for deepest possible that platform likes for
> > C-st
On Tue, 11 Aug 2009, Li Yang wrote:
> Change the F entry for file rename, and make it also cover fsl_qe_udc
> driver. Update the name accordingly.
>
> Signed-off-by: Li Yang
> ---
> Liakhovetski,
>
> Is it ok that it also covers your fsl_mx3_udc.c file. It's much easier
> to use the wildcard.
Hello,
I'm trying to understand the rationale behind "ppc_spurious_interrupts" without
luck so far. I'm seeing the BAD interrupt counter incrementing with kernels of
different ages (2.6.5, 2.6.16, 2.6.27) and on different hardware (IBM P5 and P6
64 bit, Apple PPC 32 bit). Here is the code snip tha
The WDIOC_SETTIMEOUT argument is supposed to be a "seconds" value.
However, the book E wdt currently treats it as a "period" which is
interpreted in a board-specific way.
This patch allows the user to pass in a "seconds" value and the driver
will set the smallest timeout that is at least as large
On Wed, 2009-08-12 at 17:57 +1000, Benjamin Herrenschmidt wrote:
> - Device-tree: The idea on top of my mind would be to define a
> clock-map property that has the following format:
>
> A list of:
>- zero terminated string clock ID, padded with zeros
> to a cell boundary
Hi,
Is there any changes on PCI Device tree binding has happened? Because i
am trying to port linux 2.6.30 to my MPC7448 based custom board. The
target is getting hanged at ethernet initialization. Also i have seen on
the debug message of kernel that the PCI MEM/IO resources are not getting
With flash partition entries in the DTS file, MTD might as well
be enabled in the defconfig. In a similar vein, enable USB and
enough related options (SCSI/ext2/ext3) so that a user can read
and write to a generic USB flash drive as well.
Also, this board only has the two default SOC UARTs, so ad
From: Liang Li
There is 8MB flash, 8kB EEPROM and 128MB SDRAM on the sbc834x
local bus, so add a localbus node in DTS with MTD partitions.
The recent U-boot commit fe613cdd4eb moves u-boot to the beginning
of flash, hence the legacy label on the partition at the end of flash.
Signed-off-by: Lia
From: Liang Li
Allows interrupts to occur on the sbc834x. Currently PCI devices
get assigned an incorrect IRQ and so the interrupt count never
increases. This was tested with the 82546GB based dual port E1000
PCI-X NIC which uses two distinct IRQ lines on the one card.
r...@localhost:/root> cat
From: Liang Li
Since only one of the SoC USB devices is brought out to a physical
connector on the board, remove the 2nd (USB-DR) node from the DTS.
Having it present and USB enabled will cause a hang at boot.
Signed-off-by: Liang Li
Signed-off-by: Yang Shi
Signed-off-by: Paul Gortmaker
---
This is a handful of small sbc834x patches, entirely limited in
scope to this board's DTS/defconfig. Aside from the PCI IRQ
mis-assignment fix, the other changes are aimed at improving the
general functionality of the board out of the box, by enabling
MTD and USB storage.
Paul.
_
Ben,
The following commit breaks the previous definition of flash
partitions according to Documentation/powerpc/dts-bindings/mtd-
physmap.txt. Using the 'name' field is bad practice. What was going
on w/the SLOF case?
- k
commit 4b08e149c0e02e97ec49c2a31d14a0d3a02f8074
Author: Benjamin
Hi,
I need some clarification on powerpc linux-2.6.30 kernels PCI
enumeration. Please correct me if i am wrong on this. I am having mpc7448
based custom board on which i am trying to port linux 2.6.30(Note : Earlier
i have ported linux2.6.23 kernel for this board and its successfully
booted
On Aug 12, 2009, at 6:19 AM, Josh Boyer wrote:
On Wed, Aug 12, 2009 at 05:57:05PM +1000, Benjamin Herrenschmidt
wrote:
Hi folks !
(Russell, let us know if you want to dropped from the CC list, but I
felt you may have some useful input to provide here).
So I think it would be valuable to pro
On Wed, Aug 12, 2009 at 05:57:05PM +1000, Benjamin Herrenschmidt wrote:
> - From the above, question: Do we want to keep that parent pointer ?
> Does it make sense ? Will we have objects that are clock providers and
> themselves source from multiple parent ? Or we don't care and it becomes
That
On Wed, 2009-08-12 at 13:58 +0200, Pavel Machek wrote:
> Hi!
>
> > May be having (to pick a number) 3 possible offline states for all
> > platforms with one for halt equivalent and one for deepest possible that
> > CPU can handle and one for deepest possible that platform likes for
> > C-states ma
Hi!
> May be having (to pick a number) 3 possible offline states for all
> platforms with one for halt equivalent and one for deepest possible that
> CPU can handle and one for deepest possible that platform likes for
> C-states may make sense. Will keeps things simpler in terms of usage
> expecta
On Wed, Aug 12, 2009 at 05:57:05PM +1000, Benjamin Herrenschmidt wrote:
>Hi folks !
>
>(Russell, let us know if you want to dropped from the CC list, but I
>felt you may have some useful input to provide here).
>
>So I think it would be valuable to provide the ARM clock API exposed by
>include/linu
On Wed, 2009-08-12 at 00:20 -0500, Kumar Gala wrote:
> It is suppose to. I would recommend updating u-boot to something
> newer and see what you get on that side.
>
> Also I'll try see if we have a PCIe board w/a p2p bridge on it. I'm
> guessing no one has tried PCIe on 83xx w/a p2p bridge o
On Tue, 2009-08-11 at 23:25 -0400, B.J. Buchalter wrote:
> I don't know the model of the board off the top of my head.
>
> I do know that it uses the Texas Instruments XIO2000A/XIO2200 PCI
> Express-to-PCI Bridge (rev 03), with the TSB82AA2 OHCI Link behind the
> bridge.
>
> The same board d
On Wed, 2009-08-12 at 17:57 +1000, Benjamin Herrenschmidt wrote:
> - Device-tree: The idea on top of my mind would be to define a
> clock-map property that has the following format:
>
> A list of:
> - zero terminated string clock ID, padded with zeros
> to a cell boundary
>
Hi folks !
(Russell, let us know if you want to dropped from the CC list, but I
felt you may have some useful input to provide here).
So I think it would be valuable to provide the ARM clock API exposed by
include/linux/clk.h on various PowerPC embedded hardware.
However, that brings various iss
58 matches
Mail list logo
