Hi Kim,
u-boot assigns the IMMR to 0xff40 in TQM834x.h, whereas the device
tree you picked has it at 0xe000 (it's defined in the soc node).
Don't forget to match up the PCI addresses too. patches welcome, of
course (we don't have tqm boards).
Thanks for this important information!
Hello
I would like to setup my IDE controller. It uses a generic mapping. And he
is located at the adress 0x20003000.
How can I specifie this adress to the ide driver ?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Hello.
Sébastien Chrétien wrote:
I would like to setup my IDE controller. It uses a generic mapping.
And he is located at the adress 0x20003000.
What kin of controller, and what do you mean by generic mapping?
How can I specifie this adress to the ide driver ?
The usual ways is via
Have I to rewrite a IDE driver ?
2008/9/10, Sergei Shtylyov [EMAIL PROTECTED]:
Hello.
Sébastien Chrétien wrote:
I would like to setup my IDE controller. It uses a generic mapping. And he
is located at the adress 0x20003000.
What kin of controller, and what do you mean by generic
It is a common ide controller :
offset 0x0 Data
offset 0x1 error
offset 0x2 Sector count
offset 0x3 sector No
offset 0x4 Cylinder low
offset 0x5 Cylinder High
offset 0x6 Head
offset 0x7 status
2008/9/10, Sergei Shtylyov [EMAIL PROTECTED]:
Hello.
Sébastien Chrétien wrote:
I would like to
Hello.
Sébastien Chrétien wrote:
Have I to rewrite a IDE driver ?
Most probably you can use the existing platform drivers:
drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c.
Create/register a platform device named pata_platform with 2 memory
and 1 IRQ resource, and enable
On Wednesday 10 September 2008, Sergei Shtylyov wrote:
Most probably you can use the existing platform drivers:
drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c.
Create/register a platform device named pata_platform with 2 memory
and 1 IRQ resource, and enable one of those
I looked falconide.c, it uses hw_regs_t hw; and ide_hwif_t *hwif.
Is it a good way ?
2008/9/10, Arnd Bergmann [EMAIL PROTECTED]:
On Wednesday 10 September 2008, Sergei Shtylyov wrote:
Most probably you can use the existing platform drivers:
drivers/ide/egacy/ide_platform.c or
On Wednesday 10 September 2008, Sébastien Chrétien wrote:
I looked falconide.c, it uses hw_regs_t hw; and ide_hwif_t *hwif.
Is it a good way ?
No, that uses the legacy IDE drivers, not the current ATA drivers,
and it is not based on the device tree information.
Just use
Arnd Bergmann wrote:
Most probably you can use the existing platform drivers:
drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c.
Create/register a platform device named pata_platform with 2 memory
and 1 IRQ resource, and enable one of those drivers.
For new boards using a
Hi again,
u-boot assigns the IMMR to 0xff40 in TQM834x.h, whereas the device
tree you picked has it at 0xe000 (it's defined in the soc node).
Don't forget to match up the PCI addresses too. patches welcome, of
course (we don't have tqm boards).
So I modified the dts to match the
When a QP goes into error state, it is required that flush CQEs are
delivered to the application for any outstanding work requests. eHCA does not
do this in hardware, so this patch adds software flush CQE generation to the
ehca driver.
Whenever a QP gets into error state, it is added to the QP
On Wed, 10 Sep 2008 10:46:39 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
I must admit that none of my test configs I think has module support
turned off (even if I tend to have all the stuff I need built-in).
And our allnoconfig turns off CONFIG_64BIT, so we didn't see it in any of
ok I will use the flat device tree.
Do you utils in order to use ata and check ata link ?
For example, to read some information of my compact flash
2008/9/10, Sergei Shtylyov [EMAIL PROTECTED]:
Arnd Bergmann wrote:
Most probably you can use the existing platform drivers:
This patch allows the 4xx (conventional) PCI bridge to be disabled
via the device tree. This is needed for 4xx PCI adapter hardware.
Use the PCI node's status property to disable the PCI bridge.
Signed-off-by: Matthias Fuchs [EMAIL PROTECTED]
---
arch/powerpc/sysdev/ppc4xx_pci.c |9
mpc5200 interrupts have three cells in the device tree. How are these
interpreted?
Middle one is the interrupt number. Last one seems to always be zero.
What does the first one do, edge/level?
I searched through /Documentation and could find anything about three
cells for interrupts.
I
Jon Smirl wrote:
mpc5200 interrupts have three cells in the device tree. How are these
interpreted?
Middle one is the interrupt number. Last one seems to always be zero.
What does the first one do, edge/level?
I searched through /Documentation and could find anything about three
cells for
On Wed, 10 Sep 2008 16:12:22 +0200
Oliver Rutsch [EMAIL PROTECTED] wrote:
model = tqc,tqm834x;
compatible = tqc,tqm834x;
you need a arch/powerpc/platforms/83xx/tqm834x.c file that matches this.
Kim
___
Linuxppc-dev mailing list
On Wed, Sep 10, 2008 at 12:54 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
mpc5200 interrupts have three cells in the device tree. How are these
interpreted?
Middle one is the interrupt number. Last one seems to always be zero.
What does the first one do, edge/level?
I
The current 64 bit csum_partial_copy_generic function is based on the 32
bit version and never was optimized for 64 bit. This patch takes the 64 bit
memcpy and adapts it to also do the sum. It has been tested on a variety
of input sizes and alignments on Power5 and Power6 processors. It
Hi,
I was looking at the arch/powerpc/boot/.gitignore file.
Why are all of those non-local-directory files listed there?
E.g., empty.c, inf*.c, inf*.h, zconf.h, zlib.h, zutil.h, etc.
And what is dtc? I see a dtc-src directory, but dtc is MIA.
Same for kernel-vmlinux.strip.*
Thanks,
~Randy
On Wed, 10 Sep 2008 12:24:05 -0700
Randy Dunlap [EMAIL PROTECTED] wrote:
Hi,
I was looking at the arch/powerpc/boot/.gitignore file.
Why are all of those non-local-directory files listed there?
E.g., empty.c, inf*.c, inf*.h, zconf.h, zlib.h, zutil.h, etc.
And what is dtc? I see a
Dear Sean MacLennan,
In message [EMAIL PROTECTED] you wrote:
I believe if the dts is built into u-boot, the dtc is not built.
This is never the case. The device tree is considered to be part of
and provided to the boot loader by the kernel.
Best regards,
Wolfgang Denk
--
DENX Software
Wolfgang Denk wrote:
Dear Sean MacLennan,
In message [EMAIL PROTECTED] you wrote:
I believe if the dts is built into u-boot, the dtc is not built.
This is never the case. The device tree is considered to be part of
and provided to the boot loader by the kernel.
No, it's provided to the
Randy Dunlap wrote:
I was looking at the arch/powerpc/boot/.gitignore file.
Why are all of those non-local-directory files listed there?
E.g., empty.c, inf*.c, inf*.h, zconf.h, zlib.h, zutil.h, etc.
Why would these files be listed in arch/powerpc/boot/.gitignore ??
Because they're created
This adds support for selecting page size on PPC 44x.
However there are still number of problems:
1. We can't use default PKMAP_BASE definition with 64KB/256KB pages so we
change it. Not sure that it's optimal. Then redefined PKMAP_BASE is not
aligned on (1PMD_SHIFT), don't know if it is really
This patch adds support for page sizes bigger than 4KB (16KB/64KB/256KB) on
PPC 44x.
Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED]
Signed-off-by: Ilya Yanok [EMAIL PROTECTED]
---
arch/powerpc/Kconfig| 23 +
arch/powerpc/include/asm/highmem.h |8 +++-
ENTRIES_PER_PAGEPAGE define in mm/shmem.c becomes zero if page size is
256KB. This patch fixes this.
Signed-off-by: Ilya Yanok [EMAIL PROTECTED]
---
mm/shmem.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index 04fb4f1..c603427 100644
---
Scott Wood wrote:
Randy Dunlap wrote:
I was looking at the arch/powerpc/boot/.gitignore file.
Why are all of those non-local-directory files listed there?
E.g., empty.c, inf*.c, inf*.h, zconf.h, zlib.h, zutil.h, etc.
Why would these files be listed in arch/powerpc/boot/.gitignore ??
Hi Josh,
I have few questions.
Should I base my patch from your master branch or your 'next' branch?
The 'next' branch would be best.
I saw that both your master and next branches have removed the 4xx dma and USB
drivers.
The dma drivers for 4xx used to under: drivers/dma/ppc440spe-adma.c
On Wed, 10 Sep 2008 16:47:48 -0700
Prodyut Hazarika [EMAIL PROTECTED] wrote:
Hi Josh,
I have few questions.
Should I base my patch from your master branch or your 'next' branch?
The 'next' branch would be best.
I saw that both your master and next branches have removed the 4xx dma and
Hi Josh,
Do you know the reason why these drivers were removed? Also, are there
plans to get these drivers back?
Please let me know.
Perhaps they are in the DENX kernel? If so, someone would need to submit
them for inclusion.
Yes those drivers were in the Denx kernel. I was in the
On Tue, Sep 09, 2008 at 02:09:56PM +0200, Christoph Hellwig wrote:
On Tue, Sep 09, 2008 at 03:04:47PM +1000, David Gibson wrote:
The typesafe version of the powerpc pagetable handling (with
USE_STRICT_MM_TYPECHECKS defined) has bitrotted again. This patch
makes a bunch of small fixes to
On Mon, 8 Sep 2008 08:44:59 -0400
Josh Boyer [EMAIL PROTECTED] wrote:
The following patch series adds things needed to support the PowerPC 405EZ
SoC. I've incorporated the suggestions and fixes from the previous round
of patches and barring any further comments these should be ready to go.
Dear Paul,
I would like to ask you a few things:
* which is the official dtc git repository?
I ask it here because dtc.ozlabs.org doesn't seem to work, but this is
what is linked to from the page http://ozlabs.org/ and the
device-tree-compiler package on Debian has an outdated page (it
On Wednesday 10 September 2008, Matthias Fuchs wrote:
This patch allows the 4xx (conventional) PCI bridge to be disabled
via the device tree. This is needed for 4xx PCI adapter hardware.
Use the PCI node's status property to disable the PCI bridge.
Signed-off-by: Matthias Fuchs [EMAIL
On Thursday 11 September 2008, Prodyut Hazarika wrote:
Do you know the reason why these drivers were removed? Also, are there
plans to get these drivers back? Please let me know.
Perhaps they are in the DENX kernel? If so, someone would need to submit
them for inclusion.
Yes those
37 matches
Mail list logo
