LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Netpoll controller support for PPC EMAC driver
From: Ruslan V. Sushko @ 2005-12-08 12:34 UTC (permalink / raw)
  To: ebs; +Cc: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 123 bytes --]

This patch adds netpoll controller support for PPC EMAC driver

Signed-off-by: Ruslan V. Sushko <rsushko@ru.mvista.com>




[-- Attachment #2: ppc_emac_napi_netpoll.patch --]
[-- Type: text/x-patch, Size: 4097 bytes --]

This patch adds netpoll controller support for PPC EMAC driver

---
commit a482261f165edb7e6af363d13ea94e8e7429f085
tree b5bee5eb8a971c3f40867946225051e1ff320763
parent e4f5c82a92c2a546a16af1614114eec19120e40a
author Ruslan V. Sushko <rsushko@ru.mvista.com> Thu, 08 Dec 2005 15:22:38 +0300
committer Ruslan V. Sushko <rsushko@ru.mvista.com> Thu, 08 Dec 2005 15:22:38 +0300

 drivers/net/ibm_emac/ibm_emac_core.c |   42 +++++++++++++++++++++++++++++++++-
 drivers/net/ibm_emac/ibm_emac_mal.c  |   14 -----------
 drivers/net/ibm_emac/ibm_emac_mal.h  |   12 ++++++++++
 3 files changed, 53 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -1071,8 +1071,16 @@ static int emac_start_xmit(struct sk_buf
 	struct ocp_enet_private *dev = ndev->priv;
 	unsigned int len = skb->len;
 	int slot;
+	u16 ctrl;
 
-	u16 ctrl = EMAC_TX_CTRL_GFCS | EMAC_TX_CTRL_GP | MAL_TX_CTRL_READY |
+#ifdef CONFIG_NET_POLL_CONTROLLER
+	if (unlikely(dev->tx_cnt == NUM_TX_BUFF)) {
+		netif_stop_queue(ndev);
+		return -EBUSY;
+	}
+#endif
+
+	ctrl = EMAC_TX_CTRL_GFCS | EMAC_TX_CTRL_GP | MAL_TX_CTRL_READY |
 	    MAL_TX_CTRL_LAST | emac_tx_csum(dev, skb);
 
 	slot = dev->tx_slot++;
@@ -1938,6 +1946,33 @@ static int emac_ioctl(struct net_device 
 		return -EOPNOTSUPP;
 	}
 }
+#ifdef CONFIG_NET_POLL_CONTROLLER
+void
+poll_ctrl(struct net_device *dev)
+{
+	int budget = 16;
+	struct ibm_ocp_mal *mal = ((struct ocp_enet_private*)(dev->priv))->mal;
+	struct net_device *poll_dev = &(mal->poll_dev);
+
+	/* disable  MAL interrupts */
+	mal_disable_eob_irq(mal);
+	netif_poll_disable(poll_dev);
+
+	emac_poll_rx(dev->priv, budget);
+	emac_poll_tx(dev->priv);
+
+	netif_poll_enable(poll_dev);
+	/* Enable mal interrupts */
+	mal_enable_eob_irq(mal);
+}
+
+int
+poll_fake(struct net_device *dev, int *budget)
+{
+	/* It will be never invoked */
+	return 0;
+}
+#endif
 
 static int __init emac_probe(struct ocp_device *ocpdev)
 {
@@ -2188,6 +2223,11 @@ static int __init emac_probe(struct ocp_
 	netif_carrier_off(ndev);
 	netif_stop_queue(ndev);
 
+#ifdef CONFIG_NET_POLL_CONTROLLER
+	ndev->poll_controller = poll_ctrl;
+	ndev->poll = poll_fake;
+#endif
+
 	err = register_netdev(ndev);
 	if (err) {
 		printk(KERN_ERR "emac%d: failed to register net device (%d)!\n",
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.c b/drivers/net/ibm_emac/ibm_emac_mal.c
--- a/drivers/net/ibm_emac/ibm_emac_mal.c
+++ b/drivers/net/ibm_emac/ibm_emac_mal.c
@@ -155,20 +155,6 @@ void mal_poll_del(struct ibm_ocp_mal *ma
 	local_bh_enable();
 }
 
-/* synchronized by mal_poll() */
-static inline void mal_enable_eob_irq(struct ibm_ocp_mal *mal)
-{
-	MAL_DBG2("%d: enable_irq" NL, mal->def->index);
-	set_mal_dcrn(mal, MAL_CFG, get_mal_dcrn(mal, MAL_CFG) | MAL_CFG_EOPIE);
-}
-
-/* synchronized by __LINK_STATE_RX_SCHED bit in ndev->state */
-static inline void mal_disable_eob_irq(struct ibm_ocp_mal *mal)
-{
-	set_mal_dcrn(mal, MAL_CFG, get_mal_dcrn(mal, MAL_CFG) & ~MAL_CFG_EOPIE);
-	MAL_DBG2("%d: disable_irq" NL, mal->def->index);
-}
-
 static irqreturn_t mal_serr(int irq, void *dev_instance, struct pt_regs *regs)
 {
 	struct ibm_ocp_mal *mal = dev_instance;
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h b/drivers/net/ibm_emac/ibm_emac_mal.h
--- a/drivers/net/ibm_emac/ibm_emac_mal.h
+++ b/drivers/net/ibm_emac/ibm_emac_mal.h
@@ -216,6 +216,18 @@ static inline void set_mal_dcrn(struct i
 	mtdcr(mal->dcrbase + reg, val);
 }
 
+/* synchronized by mal_poll() */
+static inline void mal_enable_eob_irq(struct ibm_ocp_mal *mal)
+{
+	set_mal_dcrn(mal, MAL_CFG, get_mal_dcrn(mal, MAL_CFG) | MAL_CFG_EOPIE);
+}
+
+/* synchronized by __LINK_STATE_RX_SCHED bit in ndev->state */
+static inline void mal_disable_eob_irq(struct ibm_ocp_mal *mal)
+{
+	set_mal_dcrn(mal, MAL_CFG, get_mal_dcrn(mal, MAL_CFG) & ~MAL_CFG_EOPIE);
+}
+
 /* Register MAL devices */
 int mal_init(void) __init;
 void mal_exit(void) __exit;


\f
!-------------------------------------------------------------flip-



^ permalink raw reply

* Re: Fix boot on some 12" powerbooks, need testers on others
From: Michael Hanselmann @ 2005-12-08 11:12 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: Guy Yasko, linuxppc-dev list
In-Reply-To: <1134038881.11760.11.camel@gaston>

[-- Attachment #1: Type: text/plain, Size: 208 bytes --]

> However, I need urgently some testers with other models of powerbooks
> and mac mini to tell me if it causes any regression [...]

Works for me on a PowerBook5,8 (15", 1.67 GHz, Oct 2005).

Greets,
Michael

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Fix boot on some 12" powerbooks, need testers on others
From: Benjamin Herrenschmidt @ 2005-12-08 10:48 UTC (permalink / raw)
  To: Guy Yasko; +Cc: linuxppc-dev list
In-Reply-To: <87bqzs5cio.fsf@oedipa.disorg>

This patch against 2.6.15-rc5 might help fixing boot on some recent
powerbooks like some 12" aluminium. However, I need urgently some
testers with other models of powerbooks and mac mini to tell me if it
causes any regression (that is before tomorrow) so it _might_ have a
chance to make it in 2.6.15.

Index: linux-work/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/feature.c	2005-11-19 10:56:07.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/feature.c	2005-12-08 21:45:30.000000000 +1100
@@ -1650,11 +1650,17 @@
 	 */
 
 	if (macio->type == macio_intrepid) {
-		if (enable)
-			UN_OUT(UNI_N_CLOCK_SPREADING, 2);
-		else
-			UN_OUT(UNI_N_CLOCK_SPREADING, 0);
-		mdelay(40);
+		struct device_node *clock =
+			of_find_node_by_path("/uni-n@f8000000/hw-clock");
+		if (clock && get_property(clock, "platform-do-clockspreading",
+					  NULL)) {
+			if (enable)
+				UN_OUT(UNI_N_CLOCK_SPREADING, 2);
+			else
+				UN_OUT(UNI_N_CLOCK_SPREADING, 0);
+			mdelay(40);
+		}
+		of_node_put(clock);
 	}
 
 	while (machine_is_compatible("PowerBook5,2") ||
Index: linux-work/arch/ppc/platforms/pmac_feature.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_feature.c	2005-11-14 20:32:16.000000000 +1100
+++ linux-work/arch/ppc/platforms/pmac_feature.c	2005-12-08 21:45:48.000000000 +1100
@@ -1606,11 +1606,17 @@
 	 */
 
 	if (macio->type == macio_intrepid) {
-		if (enable)
-			UN_OUT(UNI_N_CLOCK_SPREADING, 2);
-		else
-			UN_OUT(UNI_N_CLOCK_SPREADING, 0);
-		mdelay(40);
+		struct device_node *clock =
+			of_find_node_by_path("/uni-n@f8000000/hw-clock");
+		if (clock && get_property(clock, "platform-do-clockspreading",
+					  NULL)) {
+			if (enable)
+				UN_OUT(UNI_N_CLOCK_SPREADING, 2);
+			else
+				UN_OUT(UNI_N_CLOCK_SPREADING, 0);
+			mdelay(40);
+		}
+		of_node_put(clock);
 	}
 
 	while (machine_is_compatible("PowerBook5,2") ||

^ permalink raw reply

* mpc823 SCC3 flow control bug
From: debora liu @ 2005-12-08  9:04 UTC (permalink / raw)
  To: denx; +Cc: Linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

Hello denx:

I found one bug when SCC3 as UART, my cpu is mpc823.
cts/cd config as:
	CTS PC5
	CD  PC4

your ELDK-3.1.1 linux-2.4.25 uart.c set pcpar,pcso, pcdir:
	immap->im_ioport.iop_pcpar &= ~iobits;
	immap->im_ioport.iop_pcso |=  iobits;
	immap->im_ioport.iop_pcdir &= ~iobits;
but MPC823UM tell me CD3 and CTS3 is bit6 and bit7 on PCSO register, so I modify:
	fix_pcso = iobits;
	#if defined(CONFIG_UART_CTS_CONTROL_SCC3)
  		fix_pcso &=~(1 << (15 - CONFIG_CTS3_PIN));
		fix_pcso |= 0x0100;
	#endif
	#if defined(CONFIG_UART_CD_CONTROL_SCC3)
 		fix_pcso &=~(1 << (15 - CONFIG_CD3_PIN));
		fix_pcso |= 0x0200;
	#endif

	immap->im_ioport.iop_pcpar &= ~iobits;
	immap->im_ioport.iop_pcso |=  fix_pcso;
	immap->im_ioport.iop_pcdir &= ~iobits;

My board have success communication to moderm with SCC3 hard flow control.

        debora liu
        deboraliu@tom.com
          2005-12-08

[-- Attachment #2: fox.gif --]
[-- Type: image/gif, Size: 9519 bytes --]

^ permalink raw reply

* HR posix timers on mpc8xx??
From: David Jander @ 2005-12-08  8:55 UTC (permalink / raw)
  To: linuxppc-embedded


Hi all,

With 2.6 now relatively stable running on mpc8xx, I was wondering if someone 
has tried to patch in support for High-resolution Posix-timers, as from here:
http://sourceforge.net/projects/high-res-timers

It sounds really attractive, and I wonder why this still isn't officially part 
of 2.6?

There is a patch for 2.6.10 for ppc, but I wonder if someone managed to port 
it to 2.6.14 (or later) and runs it on an mpc8xx.

Greetings,

-- 
David Jander

^ permalink raw reply

* Re: [PATCH] ppc32: Add TQM85xx (8540/8541/8555/8560) board support
From: Kumar Gala @ 2005-12-08  7:13 UTC (permalink / raw)
  To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200512011430.48271.sr@denx.de>

On Dec 1, 2005, at 7:30 AM, Stefan Roese wrote:

> This patch adds support for the TQ Components TQM85xx modules.  
> Currently the
> modules TQM8540/8541/8555/8560 are supported.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
>
> Best regards,
> Stefan
> <add-tqm85xx-board-support-2.patch>

Had a question on this, any reason you have to hookup the rtc with an  
late_initcall()?

- kumar

^ permalink raw reply

* Re: patches in powerpc.git tree
From: Stephen Rothwell @ 2005-12-08  6:48 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <17303.53564.160668.376061@cargo.ozlabs.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 305 bytes --]

On Thu, 8 Dec 2005 17:22:52 +1100 Paul Mackerras <paulus@samba.org> wrote:
>
> Stephen Rothwell:
>       powerpc: remove arch/powerpc/include hack for 64 bit

That one is in Linus' tree ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* patches in powerpc.git tree
From: Paul Mackerras @ 2005-12-08  6:22 UTC (permalink / raw)
  To: linuxppc64-dev, linuxppc-dev

Here is a list of patches currently in the powerpc.git tree that
aren't already in Linus' tree.

Paul.

Adrian Bunk:
      PPC_PREP: remove unneeded exports

Andy Whitcroft:
      powerpc: powermac adb fix dependency on btext_drawchar
      powerpc: powermac adb fix udbg_adb_use_btext warning
      powerpc32: clean up available memory models
      powerpc32: fix definition of distribute_irqs

Arnd Bergmann:
      spufs: The SPU file system, base
      spufs: cooperative scheduler support
      spufs: Make all exports GPL-only
      spufs: fix local store page refcounting
      spufs: Fix oops when spufs module is not loaded
      spufs: Turn off debugging output
      spufs: Improved SPU preemptability.
      spufs: Improved SPU preemptability [part 2].
      spufs: fix mailbox polling
      cell: add platform detection code

Benjamin Herrenschmidt:
      powerpc: Merge align.c (#2)
      powerpc: Add OF address parsing code (#2)
      powerpc: serial port discovery (#2)
      powerpc: Unify udbg (#2)
      powerpc: Add back support for booting from BootX (#2)
      powerpc: convert macio_asic to use prom_parse
      powerpc: Fix g5 build with xmon
      powerpc: More serial probe fixes (#2)
      powerpc: udbg updates
      powerpc: Update OF address parsers
      powerpc: Fix a huge page bug
      powerpc: Remove debug code in hash path

David Gibson:
      powerpc: Remove imalloc.h
      powerpc: Make hugepage mappings respect hint addresses
      is_aligned_hugepage_range() cleanup
      powerpc: Remove ItLpRegSave area from the paca
      powerpc: Remove some unneeded fields from the paca

David Woodhouse:
      syscall entry/exit revamp
      ppc64 syscall_exit_work: call the save_nvgprs function, not its descriptor.
      powerpc: serial port discovery: cope with broken firmware
      Save NVGPRS in 32-bit signal frame
      Fix code that saves NVGPRS in 32-bit signal frame
      ppc: Make ARCH=ppc build again with new syscall path

Heiko J Schick:
      powerpc: IBMEBUS bus support

Hugh Dickins:
      mm: powerpc ptlock comments
      mm: powerpc init_mm without ptlock

Kumar Gala:
      powerpc: moved ipic code to arch/powerpc
      powerpc: Add support for building uImages
      powerpc: Fix suboptimal uImage target

linas:
      powerpc/pseries: dlpar-add crash on null pointer deref
      powerpc: minor cleanup of void ptr deref

Linas Vepstas:
      powerpc: PCI hotplug common code elimination
      powerpc: make pcibios_claim_one_bus available to other code
      powerpc: migrate common PCI hotplug code
      PCI Error Recovery: header file patch
      powerpc: PCI Error Recovery: PPC64 core recovery routines
      powerpc: Split out PCI address cache to its own file
      powerpc: Add "partitionable endpoint" support
      powerpc: remove bogus printk
      powerpc: Remove duplicate code
      powerpc: bugfix: fill in uninitialized field
      powerpc: Use PE configuration address consistently
      powerpc: set up the RTAS token just like the rest of them.
      powerpc: Don't continue with PCI Error recovery if slot reset failed.
      powerpc: handle multifunction PCI devices properly
      powerpc: IOMMU: don't ioremap null addresses
      powerpc: Save device BARs much earlier in the boot sequence
      powerpc: get rid of per_cpu EEH counters

Marcelo Tosatti:
      ppc32: m8xx watchdog update
      powerpc/8xx: Fix m8xx_wdt issues

Mark Nutter:
      spufs: switchable spu contexts
      kernel-side context switch code for spufs
      spufs: add spu-side context switch code

Michael Ellerman:
      powerpc: Merge kexec
      powerpc: Propagate regs through to machine_crash_shutdown
      powerpc: Add a is_kernel_addr() macro
      powerpc: Separate usage of KERNELBASE and PAGE_OFFSET
      powerpc: Add CONFIG_CRASH_DUMP
      powerpc: Create a trampoline for the fwnmi vectors
      powerpc: Reroute interrupts from 0 + offset to PHYSICAL_START + offset
      powerpc: Fixups for kernel linked at 32 MB
      powerpc: Add arch dependent basic infrastructure for Kdump.
      powerpc: Parse crashkernel= parameter in first kernel
      powerpc: Add arch-dependent copy_oldmem_page
      powerpc: Add support for "linux,usable-memory" on memory nodes

Michal Ostrowski:
      powerpc/pseries: Fix TCE building with 64k pagesize

Mike Kravetz:
      Remove SPAN_OTHER_NODES config definition
      powerpc: Minor numa memory code cleanup
      powerpc: Minor numa memory code cleanup
      powerpc: numa placement for dynamically added memory
      powerpc/pseries: boot failures on numa if no memory on node

Olaf Hering:
      powerpc: correct the NR_CPUS description text

Olof Johansson:
      powerpc: remove redundant code in stab init

Otavio Salvador:
      ppc: removed unused variable i from code.

Paul Mackerras:
      powerpc: Update __NR_syscalls to account for SPU syscalls
      ppc: remove duplicate bseip.h
      powerpc: Fix up some compile errors in the PCI error recovery code
      powerpc/pseries: Optimize IOMMU setup
      ppc: Build in all three of powermac, PREP and CHRP support
      Revert "powerpc: Minor numa memory code cleanup"
      powerpc: Fix typo in head_64.S

Stephen Rothwell:
      powerpc: remove arch/powerpc/include hack for 64 bit
      powerpc: cleanup iseries irq.c
      powerpc: use end_IRQ for iseries irqs
      powerpc: partly merge iseries do_IRQ
      powerpc: reduce include in irq.c
      powerpc: more iseries irq work
      powerpc: fix for "Update OF address parsers"

^ permalink raw reply

* Re: Video Card to Lite5200
From: White @ 2005-12-08  5:59 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20051207172321.77464.qmail@web53515.mail.yahoo.com>

Am Wed, 7 Dec 2005 09:23:21 -0800 (PST) schrieb roger blofeld
<blofeldus@yahoo.com> :

> What is the status of the mpc5200 support? I see Sylvain's repository
> is still at 2.6.12 (5 months old).
> 
> http://gitbits.246tnt.com/gitweb.cgi?p=linux-2.6-mpc52xx.git;a=summary
> 
> The current kernel.org kernel doesn't appear to support fec/DMA. Is
> there a plan to get networking support into the mainstream kernel?
> 
> Thanks
> -rb
> 


i think Sylvians should be update in some days. I hope.
you can pull his rep. without problems on current 2.6.15-rc4.

DMA is a problem, because the implementation from Freescale use binary
data, and has some dirty points. This would never be included in the
mainstream kernel. Sylvian has included the new DMA .. works fine for
FEC.

If someone get this new implementtion running with AC97 or PCI would be
fine.

^ permalink raw reply

* Re: Video Card to Lite5200
From: Alessandro Rubini @ 2005-12-08  0:25 UTC (permalink / raw)
  To: blofeldus; +Cc: linuxppc-embedded
In-Reply-To: <20051207172321.77464.qmail@web53515.mail.yahoo.com>


> What is the status of the mpc5200 support? I see Sylvain's repository
> is still at 2.6.12 (5 months old).

I just published what I've done (on a previous 2.6.14-rc3 tree by Denx).
It's in ftp://gnudd.com/pub/patches/mpc5200/ (also http://).

I used Sylvain's FEC support, hacked a mb() to make PCI initialize
and ported PIO-mode IDE from 2.4 (with a gross hack about port addresses),
enabled some MTD configurations so cmdlineparts work fine.

/alessandro, who doesn't have a 5200 with him any more.

^ permalink raw reply

* Re: Help needed : MCC driver for MPC8260 ADS
From: Manish Joshi @ 2005-12-08  0:09 UTC (permalink / raw)
  To: Stevan Ignjatovic, linuxppc-embedded
In-Reply-To: <1133959955.3248.1.camel@stevan.iritel.co.yu>

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

This would also help you a lot.
   
  http://www.ibiblio.org/gferg/ldp/MPC8260-MCC-HOWTO.txt
   
  -Manish

Stevan Ignjatovic <stevan@iritel.com> wrote:
  Start point for your MCC driver could be at 

http://sourceforge.net/projects/mcc8260/

On Wed, 2005-12-07 at 11:41, s.maiti@tcs.com wrote:
> Hello All,
> 
> For our project we need to have a MCC driver for MPC8260 ADS board. I
> couldn't find any driver in the linux source tree for the same. 
> Any help in this regard will be highly appreciated.
> Thanks and regards,
> 
> Souvik Maiti
> Tata Consultancy Services Limited
> Bengal Intelligent Park
> Bldg. - D, Plots - A2, M2 & N2
> Block - GP, Sector V 
> Salt Lake Electronics Complex
> Kolkata - 700091, West Bengal
> India
> Mailto: s.maiti@tcs.com
> Website: http://www.tcs.com
> Notice: The information contained in this e-mail message and/or
> attachments to it may contain confidential or privileged information.
> If you are not the intended recipient, any dissemination, use, review,
> distribution, printing or copying of the information contained in this
> e-mail message and/or attachments to it are strictly prohibited. If
> you have received this communication in error, please notify us by
> reply e-mail or telephone and immediately and permanently delete the
> message and any attachments. Thank you
> 
> ______________________________________________________________________
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded


_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
  


			
---------------------------------
Yahoo! Shopping
 Find Great Deals on Gifts at Yahoo! Shopping 

[-- Attachment #2: Type: text/html, Size: 2463 bytes --]

^ permalink raw reply

* Re: Video Card to Lite5200
From: Wolfgang Denk @ 2005-12-07 22:53 UTC (permalink / raw)
  To: Frank Bennett; +Cc: linuxppc-embedded
In-Reply-To: <439752BE.9030207@digis.net>

In message <439752BE.9030207@digis.net> you wrote:
>
> The denx.de web site looks great.

Thanks :-)

> Where can someone get this PCI card?  Do I have to contact Fujitsu 
> directly? Cost?

I guess you have to contact Fujitsu directly; we worked with  Fujitsu
Microelectronics Europe.

> The Fujitsu CoralP evaluation board MB86295EB01? or did you use the 

Yes.

> Coral PA?

No.

> I saw a posting that you also had some streaming video running.  Tell me 
> more.

See ftp://ftp.denx.de/pub/fujitsu/Coral-P/README.html

> What resolution? 4CIF (full DVD)
> What display?  LCD SVGA (800x600) and/or VGA analog port?

We used a 1024 x 768 LCD.

> Software MPEG decoder or does the Coral  have a decoder?

There was no decoder involved at all. The  CoralP  can  stream  video
directly,  without  any CPU load :-) We used the "zvideo" application
for demos - see above.

> Which player did you use?

None. Just a video source like a standard DVD player or a camera.

> Is all this covered in some release notes?

See the README.html

> Was the katix stuff ever integrated into linux_2_4_development?

Yes, it was. See the drivers/spi/ diretory in our  linuxppc_2_4_devel
tree, or
http://www.denx.de/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git;a=tree;h=464f005880de29947ee7d2d8941446c4ba76b0f8;hb=95300e1ab7d8a330784a882db868e355af6d638a;f=drivers/spi

> How does Wolfgang make a living if he spends all his time answering our 
> questions?

Dunno. Next question, please :-)


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Bradley's Bromide: If computers get too  powerful,  we  can  organize
them into a committee - that will do them in.

^ permalink raw reply

* ppc4xx DMA fixes for simultaneous sg transfers
From: ductusrhe @ 2005-12-07 21:33 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 12046 bytes --]

Linux 2.4.20 (probably 2.6 as well?)
 
Conclusion:
Scatter/gather DMA is not thread safe.
 
Background:
1. We run all four dma channels simultaneously in SG mode on the PPC440EP, starting and stopping them in different threads.
2. Also we need to change channel configs between different transfers, i.e. run ppc4xx_init_dma_channel() to set read or write mode.
 
Problem and cause:
1. All is well when running one channel at a time, but when starting/stopping a new channel during the time another is active can - if you are unlucky - cause problems.
   Because all channels SG start/stop bits are in the same register (ASGC), it must not be read then changed and written to the way it was done.
   That can cause a channel that is just done, to start again, or a newly started channel to stop.
   The register includes a feature that can be used as a semaphore - the read enable (mask) bits, but it was not used correctly in the code, it was enabled for all channels in the start-up.
2. It is said in the comment of ppc4xx_init_dma_channel() that it should only be used once in the start-up. If you comply, you will not have any problem with it.
   However, when running this for a channel when other channels are active, can cause channels to stop or maybe never give an interrupt or false interrupts. The method clears the entire status register, not only the bits for the given channel.
 
Solution:
1. - In ppc4xx_alloc_dma_handle(), do not touch the ASGC register!
   - In ppc4xx_enable_dma_sgl() and ppc4xx_disable_dma_sgl(), when setting the ASGC register, only change the given channel.
     That's done without reading the register at all, just set/clear the enable bit of the channel to change, then set the MASK_ENABLE for the same channel.
   Probably this is the way the register was intended to be handled?
2. - In ppc4xx_init_dma_channel(), only clear the correct bits of the DMASR register, not the whole register.
     (The polarity was also not set as it's supposed to in this function, but there exists a patch for that)
 
I can send a patch with our changes, that works very well and stable, but there are many changes and not all of them in line with the current official version of the files (we handle the sg descriptor list differently). Maybe someone feeling for it will take a look at the changes and make them into the real code, since the above fixes does not interfere with the usage, only improves thread safety.
 
I have no idea if this has been fixed in some patch already... but I have not seen it on this list anyway.
I'm not a regular poster, just want to help others avoid some of the struggle when running many channels.
 
/Ronnie Hedlund

Our changed code:
In "ppc4xx_dma.c"
-----------------------
/*
 *  The comment states that this function should only be run at start-up, and never more.
 *  That is unacceptable, with the fix it can be run anywhere as long as the given channel is not running.
 */
int ppc4xx_init_dma_channel(unsigned int dmanr, ppc_dma_ch_t * p_init)
{
        unsigned int status_bits[] = { DMA_CS0 | DMA_TS0 | DMA_CH0_ERR,
                                       DMA_CS1 | DMA_TS1 | DMA_CH1_ERR,
                                       DMA_CS2 | DMA_TS2 | DMA_CH2_ERR,
                                       DMA_CS3 | DMA_TS3 | DMA_CH3_ERR};
        unsigned int polarity;
        uint32_t control = 0;
        ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
       
        DMA_MODE_READ = (unsigned long) DMA_TD; /* Peripheral to Memory */
        DMA_MODE_WRITE = 0;     /* Memory to Peripheral */
        if (!p_init) {
                printk("ppc4xx_init_dma_channel: NULL p_init\n");
                return DMA_STATUS_NULL_POINTER;
        }
        if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
                printk("ppc4xx_init_dma_channel: bad channel %d\n", dmanr);
                return DMA_STATUS_BAD_CHANNEL;
        }
#if DCRN_POL > 0
        polarity = mfdcr(DCRN_POL);
#else
        polarity = 0;
#endif
        /* Setup the control register based on the values passed to
         * us in p_init.  Then, over-write the control register with this
         * new value.
         */
        control |= SET_DMA_CONTROL;
        switch (dmanr) {
        case 0:
                /* clear all polarity signals and then "or" in new signal levels */
                polarity &= ~GET_DMA_POLARITY(0);
                polarity |= p_init->polarity;
#if DCRN_POL > 0
                mtdcr(DCRN_POL, polarity);
#endif
                mtdcr(DCRN_DMACR0, control);
                break;
        case 1:
                polarity &= ~GET_DMA_POLARITY(1);
                polarity |= p_init->polarity;
#if DCRN_POL > 0
                mtdcr(DCRN_POL, polarity);
#endif
                mtdcr(DCRN_DMACR1, control);
                break;
        case 2:
                polarity &= ~GET_DMA_POLARITY(2);
                polarity |= p_init->polarity;
#if DCRN_POL > 0
                mtdcr(DCRN_POL, polarity);
#endif
                mtdcr(DCRN_DMACR2, control);
                break;
        case 3:
                polarity &= ~GET_DMA_POLARITY(3);
                polarity |= p_init->polarity;
#if DCRN_POL > 0
                mtdcr(DCRN_POL, polarity);
#endif
                mtdcr(DCRN_DMACR3, control);
                break;
        default:
                return DMA_STATUS_BAD_CHANNEL;
        }
        /* save these values in our dma channel structure */
        memcpy(p_dma_ch, p_init, sizeof (ppc_dma_ch_t));
       
        /*
         * The peripheral width values written in the control register are:
         *   PW_8                 0
         *   PW_16                1
         *   PW_32                2
         *   PW_64                3
         *
         *   Since the DMA count register takes the number of "transfers",
         *   we need to divide the count sent to us in certain
         *   functions by the appropriate number.  It so happens that our
         *   right shift value is equal to the peripheral width value.
         */
        p_dma_ch->shift = p_init->pwidth;
        /*
         * Save the control word for easy access.
         */
        p_dma_ch->control = control;
        /*
         * clear status register for the channel
         * only TS, CS and RI needs to be cleared.
         */
        mtdcr(DCRN_DMASR, status_bits[dmanr]);
       
        return DMA_STATUS_GOOD;
}

In "ppc4xx_sgdma.c"
-----------------------
int
ppc4xx_alloc_dma_handle(sgl_handle_t * phandle, unsigned int mode, unsigned int dmanr)
{
        sgl_list_info_t *psgl = NULL;
        ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
        //uint32_t sg_command;
        if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
                printk("ppc4xx_alloc_dma_handle: invalid channel 0x%x\n", dmanr);
                return DMA_STATUS_BAD_CHANNEL;
        }
        if (!phandle) {
                printk("ppc4xx_alloc_dma_handle: null handle pointer\n");
                return DMA_STATUS_NULL_POINTER;
        }
        /* Get memory for the listinfo struct */
        psgl = kmalloc(sizeof(sgl_list_info_t), GFP_KERNEL);
        if (psgl == NULL) {
                *phandle = (sgl_handle_t) NULL;
                return DMA_STATUS_OUT_OF_MEMORY;
        }
        memset(psgl, 0, sizeof(sgl_list_info_t));
       
        /* dma_addr is unused now */
        psgl->dmanr = dmanr;
        /*
         * Modify and save the control word. These words will be
         * written to each sgl descriptor.  The DMA engine then
         * loads this control word into the control register
         * every time it reads a new descriptor.
         */
        psgl->control = p_dma_ch->control;
        /* Clear all mode bits */
        psgl->control &= ~(DMA_TM_MASK | DMA_TD);
        /* Save control word and mode */
        psgl->control |= (mode | DMA_CE_ENABLE);
         /* PPC Errata? DMA else ignore count on first in list */
        psgl->control |= SET_DMA_TCE(1);
       
        /* In MM mode, we must set ETD/TCE */
        if (mode == DMA_MODE_MM)
                psgl->control |= DMA_ETD_OUTPUT | DMA_TCE_ENABLE;
        if (p_dma_ch->int_enable) {
                /* Enable channel interrupt */
                psgl->control |= DMA_CIE_ENABLE;
        } else {
                psgl->control &= ~DMA_CIE_ENABLE;
        }
        /* we must not touch the SGC, it can cause problems to other channels! */
         
        psgl->sgl_control = SG_LINK;
        if (p_dma_ch->int_enable) {
                if (p_dma_ch->tce_enable)
                {       
                         /* reuse as Terminal Count Interrupt Enable on all descr. */
                        psgl->sgl_control |= SG_TCI_ENABLE;
                }
                psgl->sgl_control |= SG_ERI_ENABLE | SG_ETI_ENABLE;
        }
        *phandle = (sgl_handle_t) psgl;
        return DMA_STATUS_GOOD;
}
void
ppc4xx_enable_dma_sgl(sgl_handle_t handle)
{
        sgl_list_info_t *psgl = (sgl_list_info_t *) handle;
        ppc_dma_ch_t *p_dma_ch;
        uint32_t sg_command;
        if (!handle) {
                printk("ppc4xx_enable_dma_sgl: null handle\n");
                return;
        } else if (psgl->dmanr > (MAX_PPC4xx_DMA_CHANNELS - 1)) {
                printk("ppc4xx_enable_dma_sgl: bad channel in handle %d\n",
                       psgl->dmanr);
                return;
        } else if (!psgl->phead) {
                printk("ppc4xx_enable_dma_sgl: sg list empty\n");
                return;
        }
        p_dma_ch = &dma_channels[psgl->dmanr];
        psgl->ptail->control_count &= ~SG_LINK; /* make this the last dscrptr */
        if (p_dma_ch->int_enable)
        {
                /* Require Terminal Count interrupt on last */
                psgl->ptail->control_count |= SG_TCI_ENABLE;
        }
       
        /* No more changes to tail object allowed */
        //dma_cache_wback((unsigned long)psgl->ptail, sizeof(ppc_sgl_t));
        dma_cache_wback_inv((unsigned long)psgl->ptail, sizeof(ppc_sgl_t));
       
        ppc4xx_set_sg_addr(psgl->dmanr, virt_to_phys(psgl->phead));
       
        sg_command = 0;
        switch (psgl->dmanr) {
        case 0:
                sg_command = SSG0_ENABLE | SSG0_MASK_ENABLE;
                break;
        case 1:
                sg_command = SSG1_ENABLE | SSG1_MASK_ENABLE;
                break;
        case 2:
                sg_command = SSG2_ENABLE | SSG2_MASK_ENABLE;
                break;
        case 3:
                sg_command = SSG3_ENABLE | SSG3_MASK_ENABLE;
                break;
        default:
                printk("ppc4xx_enable_dma_sgl: bad channel: %d\n", psgl->dmanr);
        }
       
        mtdcr(DCRN_ASGC, sg_command);   /* start transfer */
}
void
ppc4xx_disable_dma_sgl(sgl_handle_t handle)
{
        sgl_list_info_t *psgl = (sgl_list_info_t *) handle;
        uint32_t sg_command;
        if (!handle) {
                printk("ppc4xx_disable_dma_sgl: null handle\n");
                return;
        } else if (psgl->dmanr > (MAX_PPC4xx_DMA_CHANNELS - 1)) {
                printk("ppc4xx_disable_dma_sgl: bad channel in handle %d\n",
                       psgl->dmanr);
                return;
        }
        sg_command = 0; //disable dma
        switch (psgl->dmanr) {
        case 0:
                sg_command = SSG0_MASK_ENABLE;
                break;
        case 1:
                sg_command = SSG1_MASK_ENABLE;
                break;
        case 2:
                sg_command = SSG2_MASK_ENABLE;
                break;
        case 3:
                sg_command = SSG3_MASK_ENABLE;
                break;
        default:
                printk("ppc4xx_disable_dma_sgl: bad channel: %d\n", psgl->dmanr);
        }
        mtdcr(DCRN_ASGC, sg_command);   /* stop transfer */
}
 

[-- Attachment #2: Type: text/html, Size: 28296 bytes --]

^ permalink raw reply

* Re: Video Card to Lite5200
From: bennett78 @ 2005-12-07 21:23 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20051205203515.51D4C353F5E@atlas.denx.de>

[-- Attachment #1: Type: text/plain, Size: 2354 bytes --]

Wolfgang Denk wrote:

>Dear Alan,
>
>in message <dc70db7d0512051130s498f7d5fk42a0f4886c006efd@mail.gmail.com> you wrote:
>  
>
>>I am just looking for a cheaper video card to use with Lite5200 board.
>>CoralP is very expansive, then I will use ATI Rage Mobility.
>>    
>>
>
>Make sure that you don't need to run any (x86) BIOS code on your card
>to initialize it. This is the main issue with most graphics cards.
>
>  
>
>>Well, my video card is not ATI Rage Mobility M1 EVA, it has not 723
>>regulator, it use MTD3302 as regulator, do you know if I need change
>>something on the Lite5200's PCI slot to it work with this video card?
>>    
>>
>
>If your card is a true 3.3V PCI card it should be at  least  possible
>to  attach  and  test it. Chances are that it does not work (at least
>not without some amount of work).
>
>  
>
>>My Lite5200 is Version 2.0, and Freescale connected some wire (small cables)
>>to PCI slot, maybe to fix some PCI problems.
>>    
>>
>
>You probably want to ask FS about this.
>
>  
>
>>I am using linux kernel 2.6.14, downloaded from denx's web site. Linux is
>>    
>>
>
>Note that the 5200 code in the kernel is work in progress. I  do  not
>cleaim  that it does work in any way. If you want stable code use our
>2.4.25 kernel instead.
>
>  
>
>>running fine in this board, but until now I am using only serial console.
>>Now I want use a video card with it.
>>    
>>
>
>Well, if your time is worth anything you  might  find  out  that  the
>CoralP  is the cheaper solution - or using a graphics controller that
>can be attached directly to the bus.
>  
>
Wolfgang:
The denx.de web site looks great.

Where can someone get this PCI card?  Do I have to contact Fujitsu 
directly? Cost?
The Fujitsu CoralP evaluation board MB86295EB01? or did you use the 
Coral PA?
I saw a posting that you also had some streaming video running.  Tell me 
more.
What resolution? 4CIF (full DVD)
What display?  LCD SVGA (800x600) and/or VGA analog port?
Software MPEG decoder or does the Coral  have a decoder?
Which player did you use?
Is all this covered in some release notes?
Was the katix stuff ever integrated into linux_2_4_development?
How does Wolfgang make a living if he spends all his time answering our 
questions?

thanks,
Frank Bennett

>Best regards,
>
>Wolfgang Denk
>  
>
*//* <mailto:frank.bennett@triadsyseng.com>


[-- Attachment #2: Type: text/html, Size: 3658 bytes --]

^ permalink raw reply

* Re: Video Card to Lite5200
From: Wolfgang Denk @ 2005-12-07 19:51 UTC (permalink / raw)
  To: roger blofeld; +Cc: linuxppc-embedded
In-Reply-To: <20051207172321.77464.qmail@web53515.mail.yahoo.com>

In message <20051207172321.77464.qmail@web53515.mail.yahoo.com> you wrote:
> 
> The current kernel.org kernel doesn't appear to support fec/DMA. Is
> there a plan to get networking support into the mainstream kernel?

I don;t know - the patches were submitted to this list  a  long  time
ago; we added them to our repository without any additional problems;
see http://www.denx.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If ignorance is bliss, why aren't there more happy people?

^ permalink raw reply

* Re: Video Card to Lite5200
From: Alan Carvalho @ 2005-12-07 18:53 UTC (permalink / raw)
  To: roger blofeld; +Cc: linuxppc-embedded
In-Reply-To: <20051207172321.77464.qmail@web53515.mail.yahoo.com>

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

Hi Roger,

On 12/7/05, roger blofeld <blofeldus@yahoo.com> wrote:
>
> What is the status of the mpc5200 support? I see Sylvain's repository
> is still at 2.6.12 (5 months old).
>
> http://gitbits.246tnt.com/gitweb.cgi?p=linux-2.6-mpc52xx.git;a=summary
>
> The current kernel.org kernel doesn't appear to support fec/DMA. Is
> there a plan to get networking support into the mainstream kernel?


I am using linux kernel 2.6.14, downloaded from denx site, it is supporting
FEC correctly, well it show a silly error msg, but work fine.


Thanks
> -rb


Cheers,

Alan

[-- Attachment #2: Type: text/html, Size: 1175 bytes --]

^ permalink raw reply

* Re: Transmit timeouts on 440GX Ocotea on 10baseT-HD network
From: Wade Farnsworth @ 2005-12-07 18:00 UTC (permalink / raw)
  To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20051207173554.GA21578@gate.ebshome.net>

On Wed, 2005-12-07 at 10:35, Eugene Surovegin wrote:
> Hmm, I think this should have been fixed in the latest 2.6. Check 
> that you tree has this patch:
> 
> 	[PATCH] ibm_emac: fix graceful stop timeout handling
> 
> It went in on 01 Dec. Although this fix assumed FDX operation for 
> timeouts, without collisions. Maybe I was too optimistic thinking that 
> nobody uses 10/HDX :).

That was my first thought as well, but I've tried it with the patch, and
still get the timeouts.

> 
> Try making STOP_TIMEOUT_10 bigger, say twice as big.

That doesn't seem to help any.

> 
> If this doesn't help, I'll send you patch with enables some additional 
> debugging, so I can check that stop you are experiencing is the same 
> problem I had last month.

Much appreciated.  Thanks!

Regards,

Wade Farnsworth

^ permalink raw reply

* Re: Transmit timeouts on 440GX Ocotea on 10baseT-HD network
From: Eugene Surovegin @ 2005-12-07 17:35 UTC (permalink / raw)
  To: Wade Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <1133968527.8299.50.camel@rhino.az.mvista.com>

On Wed, Dec 07, 2005 at 08:15:28AM -0700, Wade Farnsworth wrote:
> Hi Eugene,
> 
> I'm seeing some "NETDEV WATCHDOG: eth0: transmit timed out" messages on
> the Ocotea when it's connected to a 10baseT hub, and it's put under
> heavy load.  I'm using the most current 2.6 git tree.
> 
> This can be reproduced by ssh'ing into the Ocotea and running the
> command "ping <host-machine> -A -s 1200", then also doing the same ping
> command from the host to the Ocotea.  The pings will be successful for a
> short time, then all transmits on the Ocotea will stop for a few seconds
> (usually preceded by a few duplicate packets).  Transmits begin again
> once the timeout occurs. /proc/net/dev doesn't report any errors, just a
> few dropped packets.
> 
> Do you know what might be causing the EMAC to stop transmitting in this
> situation?

Hmm, I think this should have been fixed in the latest 2.6. Check 
that you tree has this patch:

	[PATCH] ibm_emac: fix graceful stop timeout handling

It went in on 01 Dec. Although this fix assumed FDX operation for 
timeouts, without collisions. Maybe I was too optimistic thinking that 
nobody uses 10/HDX :).

Try making STOP_TIMEOUT_10 bigger, say twice as big.

If this doesn't help, I'll send you patch with enables some additional 
debugging, so I can check that stop you are experiencing is the same 
problem I had last month.

-- 
Eugene

^ permalink raw reply

* Re: Video Card to Lite5200
From: roger blofeld @ 2005-12-07 17:23 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20051205203941.GA16695@mail.gnudd.com>

What is the status of the mpc5200 support? I see Sylvain's repository
is still at 2.6.12 (5 months old).

http://gitbits.246tnt.com/gitweb.cgi?p=linux-2.6-mpc52xx.git;a=summary

The current kernel.org kernel doesn't appear to support fec/DMA. Is
there a plan to get networking support into the mainstream kernel?

Thanks
-rb

--- Alessandro Rubini <rubini@gnudd.com> wrote:

> 
> > Note that the 5200 code in the kernel is work in progress. I  do 
> not
> > cleaim  that it does work in any way. If you want stable code use
> our
> > 2.4.25 kernel instead.
> 
> FWIW, I have your 2.6.14 happily running on the lite5200, with PCI,
> IDE (no DMA though) and flash.
> 
> I can publish the patches, if anyone is interested. Until now I
> didn't,
> as Sylvain's work is considered the official one (but it didn't have
> IDE last time I checked -- and I don't have bitkeeper to pull it).
> 
> /alessandro
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 



		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

^ permalink raw reply

* Re: Transmit timeouts on 440GX Ocotea on 10baseT-HD network
From: Wade Farnsworth @ 2005-12-07 16:54 UTC (permalink / raw)
  To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <1133968527.8299.50.camel@rhino.az.mvista.com>

On Wed, 2005-12-07 at 08:15, Wade Farnsworth wrote:
> Hi Eugene,
> 
> I'm seeing some "NETDEV WATCHDOG: eth0: transmit timed out" messages on
> the Ocotea when it's connected to a 10baseT hub, and it's put under
> heavy load.  I'm using the most current 2.6 git tree.
> 
> This can be reproduced by ssh'ing into the Ocotea and running the
> command "ping <host-machine> -A -s 1200", then also doing the same ping
> command from the host to the Ocotea.  The pings will be successful for a
> short time, then all transmits on the Ocotea will stop for a few seconds
> (usually preceded by a few duplicate packets).  Transmits begin again
> once the timeout occurs. /proc/net/dev doesn't report any errors, just a
> few dropped packets.
> 
> Do you know what might be causing the EMAC to stop transmitting in this
> situation?

One more data point to consider:  I ran this test on an Ebony board, but
don't encounter any timeouts.  Do you know of any 440GX-specific issues
that might cause this?

Thanks again,

Wade Farnsworth

^ permalink raw reply

* Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware
From: Kumar Gala @ 2005-12-07 16:54 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev, Arnd Bergmann, linuxppc64-dev
In-Reply-To: <20051207001720.GB25533@localhost.localdomain>


On Dec 6, 2005, at 6:17 PM, David Gibson wrote:

> On Tue, Dec 06, 2005 at 08:48:55PM +0100, Arnd Bergmann wrote:
>> On Maandag 05 Dezember 2005 22:06, Jon Loeliger wrote:
>>> Included below is a proposed Revision 0.5 of the
>>> "Booting the Linux/ppc kernel without Open Firmware"
>>> document.  This modification primarily extends the
>>> Revision 0.4 by adding definitions for OF Nodes that
>>> cover the System-On-a-Chip features found on PPC parts.
>>> It also generalizes some earlier wording that pertained
>>> to only PPC64 parts and covers the new, merged PPC 32
>>> and 64 parts together.  Finally, minor typos, style
>>> consistency and grammar problems were corrected.
>>
>> A few points are not clear yet, either because I don't understand the
>> document or one it references correctly or because I might have
>> different requirements:
>
> All comments below IMHO, and subject to persuasion otherwise.
>
>> - Do we need a way to identify the type of soc bus? There are  
>> different
>>   standards for this, e.g. PLB4 on PPC440 or the EIB on the Cell BE.
>>   My initial idea was to have different device-type properties for  
>> these,
>>   but I now think that device_type = "soc" makes sense for all of  
>> them.
>>   Maybe we could add a model or compatible property for them.
>
> It think it would be a good idea to have something labelling the
> specific type of SOC bus, though I'm not immediately sure where.
> "model" perhaps, if it rarely has an effect on how to operate the bus.

I think this should be optional since it rarely has an effect on usage.

>> - It does not really belong into this document, but is related  
>> anyway:
>>   how do you want to represent this in Linux? Currently, most of  
>> these
>>   would be of_platform_device, but I think it would be good to have
>>   a new bus_type for it. The advantage would be that you can see the
>>   devices in /sys/devices/soc@xxx/ even if the driver is not loaded
>>   and the driver can even be autoloaded by udev.
>>   Also, which properties should show up in sysfs? All of them or just
>>   those specified in this document or a subset of them?
>
> I concur - I believe we already have a bus_type for on-chip devices on
> 4xx.

Not, sure what the 4xx reference is but, we have be using the  
platform bus in the kernel for "soc" connected devices.  I dont see  
the need to invent a new bus type unless there is a specific reason to.

>> - What do we do with pci root devices? They are often physically  
>> connected
>>   to the internal CPU bus, so it would make sense to represent them
>>   this way in the device tree. Should we add them to the  
>> specification
>>   here? Would it even work the expected way in Linux?
>
> The host bridges should sit on the soc bus then, as you suggest (just
> as the PCI busses hang off HyperTransport on the G5).  I think you
> need to refer to the OF docs for how to represent the PCI host bridge
> and devices themselves.

We need to provide some details on PCI nodes based on the OF docs.   
Ben and I have talked a little about this.  Its mainly about what  
parts of the OF spec are truly required.  We will probably add some  
additional information that the OF spec doesnt handle for host  
bridges setup.

>> - For some devices, you mandate a model property, for others you  
>> don't.
>>   Is this intentional? It might be easier to find the right device
>>   driver if the match string always contains a model name.
>
> You rarely want to match model name to find a device - generally you
> want to match either on "compatible" or "device_type", or possibly
> both.
>
>> - How would I represent nested interrupt controllers? E.g. suppose I
>>   have a Cell internal interrupt controller on one SOC bus and
>>   and an external interrupt controller on another SOC bus but have
>>   that deliver interrupts to the first one.
>
> Again, I believe this is in the OF docs - interrupt controllers have
> an interrupt-parent property IIRC, which gives the phandle of the next
> interrupt controller up the chain.

Yep, you need to check out the "Interrupt Mapping" OF spec for  
details.  It handles describing the chaining you speak of.  However,  
you will need to provide some "spec" for any properties of the  
interrupt controllers that you may need.

>> - Should it mention nested SOC buses, e.g. a PLB4 bus connected to a
>>   PLB5 bus?
>
> Yes.

Is there anything special about this? are these PLB4/5 busses  
software visible?

>
>> - The title says 'without Open Firmware', but it should also be  
>> allowed
>>   to use the same SOC bus layout when using SLOF or some other OF
>>   implementation, right?
>
> I guess so.
>
>> - Also not new in this version, but still: Should there be support  
>> for
>>   specifying CPUs with multiple SMT threads?
>
> Umm.. maybe.

- kumar

^ permalink raw reply

* Re: MPC8245 with its internal UART
From: Kumar Gala @ 2005-12-07 16:39 UTC (permalink / raw)
  To: Dan Malek; +Cc: HappyPhot, linuxppc-embedded
In-Reply-To: <03f747f66110e0d5976c2c03a76945aa@embeddededge.com>


On Dec 6, 2005, at 10:43 PM, Dan Malek wrote:

>
> On Dec 6, 2005, at 7:44 PM, HappyPhot wrote:
>
>> Who can tell me which flatform is similar to mine ? I've tried
>> "make sandpoint_defconfig", but seems not the right one.
>
> That's the one I would have recommended.  I don't think there
> is any Linux platform port that uses the 8245 internal DUART,
> at least not in the public source tree.  The DUART is actually
> pretty easy, just use the generic 8250 driver and point the address
> to the Embedded Utilities Block DUART.

The 2.6 kernel tree has support for the DUART on 8245 Sandpoint  
systems.  (We added it in the last few months).

- kumar

^ permalink raw reply

* Transmit timeouts on 440GX Ocotea on 10baseT-HD network
From: Wade Farnsworth @ 2005-12-07 15:15 UTC (permalink / raw)
  To: Eugene Surovegin; +Cc: linuxppc-embedded

Hi Eugene,

I'm seeing some "NETDEV WATCHDOG: eth0: transmit timed out" messages on
the Ocotea when it's connected to a 10baseT hub, and it's put under
heavy load.  I'm using the most current 2.6 git tree.

This can be reproduced by ssh'ing into the Ocotea and running the
command "ping <host-machine> -A -s 1200", then also doing the same ping
command from the host to the Ocotea.  The pings will be successful for a
short time, then all transmits on the Ocotea will stop for a few seconds
(usually preceded by a few duplicate packets).  Transmits begin again
once the timeout occurs. /proc/net/dev doesn't report any errors, just a
few dropped packets.

Do you know what might be causing the EMAC to stop transmitting in this
situation?

Thanks,

Wade Farnsworth

^ permalink raw reply

* Re: Help needed : MCC driver for MPC8260 ADS
From: Stevan Ignjatovic @ 2005-12-07 12:52 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <OFE97B5EA0.D9C1175E-ON652570D0.00392019-652570D0.003AB2EA@tcs.com>

Start point for your MCC driver could be at 

http://sourceforge.net/projects/mcc8260/

On Wed, 2005-12-07 at 11:41, s.maiti@tcs.com wrote:
> Hello All,
> 
> For our project we need to have a MCC driver for MPC8260 ADS board. I
> couldn't find any driver in the linux source tree for the same. 
> Any help in this regard will be highly appreciated.
> Thanks and regards,
> 
> Souvik Maiti
> Tata Consultancy Services Limited
> Bengal Intelligent Park
> Bldg. - D, Plots - A2, M2 & N2
> Block - GP, Sector V 
> Salt Lake Electronics Complex
> Kolkata - 700091, West Bengal
> India
> Mailto: s.maiti@tcs.com
> Website: http://www.tcs.com
> Notice: The information contained in this e-mail message and/or
> attachments to it may contain confidential or privileged information.
> If you are not the intended recipient, any dissemination, use, review,
> distribution, printing or copying of the information contained in this
> e-mail message and/or attachments to it are strictly prohibited. If
> you have received this communication in error, please notify us by
> reply e-mail or telephone and immediately and permanently delete the
> message and any attachments. Thank you
> 
> ______________________________________________________________________
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply

* Re: Help required on mpc8260 kernel boot
From: Wolfgang Denk @ 2005-12-07 12:19 UTC (permalink / raw)
  To: batsayan.das; +Cc: linuxppc-embedded
In-Reply-To: <OFCBD37606.7E278616-ON652570D0.0028C041-652570D0.00360A00@tcs.com>

In message <OFCBD37606.7E278616-ON652570D0.0028C041-652570D0.00360A00@tcs.com> you wrote:
> 
> I am using customs board with MPC8260 processor. I have RAM version of 
> U-Boot and I am able to get U-Boot prompt when I load and run u-bbot.srec 
> by TRACE32. My memory map is as follows
> 
> SDRAM start address :0x30000000  and 128MB
> Flash start address: 0x00000000    and 1MB

One of your fellows (mail address pritha.bhattacharya@tcs.com) posted
this before, and received pretty clear hints that your  configuration
is not correct.

Also, you continue to ignore answers from the FAQs.

Please read the answers you received before, and  follow  the  advice
given.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
panic: can't find /

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox