LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
From: Mohammad Sadegh Sadri @ 2008-03-17  9:03 UTC (permalink / raw)
  To: Stephen Neuendorffer, Koss, Mike (Mission Systems),
	linuxppc-embedded
In-Reply-To: <20080316214832.3F77A538046@mail141-sin.bigfish.com>

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


Ok, thanks for guidance,

by the way it is interesting for me to hear about EDK 10.1 from u steve, 
EDK 9.2 has been around just for a little time and you are going to 10.1?

What about future plan of xilinx about Virtex-5 FX? does this tool consider that? 
the future plan is really important for our development team. let me give a simple example, our dev team worked on the design of our system based on PLB and OPB buses for some thing near 6 month, just then EDK 9.2.02 released and suddenly we forced to change all of the designs and to define new activities specially focusing on MPMC. we did never consider MPMC before, but the release of EDK 9.2 changed every thing. 

Now, that would be nice, if we can know your future plan a little, that would help us to generate correct and real gant charts. and to assign human resources correctly. this is also true for the project budget. We know that Virtex-5 devices are really capable of doing better things than Virtex-4, specially the PCI express option is great and very usable for us, but we have not moved to virtex-5 yet, because there is no FX series or at least we do not know your plan about it. Our managers we seriously asking us if we have to move to Virtex-5 soon, we did not have any reasonable answer for them because we do not have any info from u at all.

thanks

Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
Date: Sun, 16 Mar 2008 14:43:33 -0700
From: stephen.neuendorffer@xilinx.com
To: mike.koss@ngc.com; mamsadegh@hotmail.com; linuxppc-embedded@ozlabs.org





RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC









Ah, thanks mike...  you knocked the answer loose out of my brain...



In EDK 9.2., the ll_temac generates either SDMA or FIFO defines, as necessary.

The platform data structure contains entries for both, with the correct ones being ignored.  In order to get the code to compile, there are some defines in xparameters.h which have:



#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR

#define XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR 0xdeadbeef

#endif

#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR

#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR 0xdeadbeef

#endif

#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR

#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR 0xdeadbeef

#endif



after including xparameter_ml403.h



I'm guessing maybe you overwrote the xparameters.h file and got rid of these redefines?  You can define it to be whatever you want, since the value will be ignored if you are using SDMA.



In EDK 10.1, the BSP generator will always generate all the defines (even ones which are not sensible in the current configuration), which avoids the above annoyances.



Steve



-----Original Message-----

From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of Koss, Mike (Mission Systems)

Sent: Sat 3/15/2008 9:12 PM

To: Mohammad Sadegh Sadri; linuxppc-embedded@ozlabs.org

Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC



That interrupt is defined if you build a xps_ll_temac with the

xps_ll_fifo interface. Since you already stated that you're using the

mpmc, I'm going to assume that you have it connected to a SDMA

controller on the mpmc. As such the driver should be looking for that

definition, and not the FIFO interrupt. I don't have your version of the

virtex_devices.c to have a reference as to how the platform device is

being defined, so hopefully either Stephen N can chime in w/ more

information, or point me to the version of the virtex_devices.c that

you're using and I can try to provide some more assistance.



-- Mike



________________________________



From: Mohammad Sadegh Sadri [mailto:mamsadegh@hotmail.com]

Sent: Saturday, March 15, 2008 4:31 AM

To: linuxppc-embedded@ozlabs.org

Subject: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC





All,



that should be a small problem, and i think that its solution should be

simple,



I generate a base system using EDK 9.2.02 , the base system contains

XPS_LL_TEMAC , MPMC and other components,

I generate the software libraries and copy xparameters file into proper

kernel folder. I configure that kernel and add kernel support for

XPS_LL_TEMAC.



while doing make I encounter this error:



arch/ppc/syslib/virtex_devices.c:455: error:

'XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR' undeclared here (not in a

function)



I think that this definition should be available in xparameters_ml403.h

file but i see that there is no such definition.

I added a dummy definition for myself there to complete kernel

compilation, don't know the correct value for it of course.



thanks







________________________________



Access your files from anywhere with Windows Live SkyDrive! Sign up now

and get 5GB of space FREE! <http://g.msn.ca/ca55/209> 








_________________________________________________________________
Like solving puzzles? Then you'll love Flexicon! Play now!
http://g.msn.ca/ca55/213

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

^ permalink raw reply

* Re: simple MPC5200B system
From: André Schwarz @ 2008-03-17  9:35 UTC (permalink / raw)
  To: Grant Likely; +Cc: linux-ppc list
In-Reply-To: <fa686aa40803161301r1685f2cale75d67b8a203cca3@mail.gmail.com>

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

Grant Likely wrote:
> On Sun, Mar 16, 2008 at 1:15 PM, André Schwarz
> <Andre.Schwarz@matrix-vision.de> wrote:
>   
>> All,
>>
>>  I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+
>>  ... maybe someone could give me some hints.
>>  Up to now the systems have been running on 2.6.19 without any problems.
>>
>>  This is what I've done so far :
>>
>>  - get a recent system with 2.6.19 running and keep the toolchain (gcc
>>  4.0) including RFS uImage.
>>  - latest bootloader (u-boot 1.3.2) is running fine with dtb support.
>>  - Kernel and RFS images are available via bootp/tftp
>>  - device tree blob seems ok, i.e. u-boot can display the blob and fill
>>  in all clocks correctly.
>>  - Kernel gets called with Kernel, RFS and dtb on suitable adresses
>>  (0x100000, 0x600000, 0x5F0000).
>>  - nothing more happens. It looks like the console isn't working properly
>>  - maybe worse ...
>>     
>
> Can you either halt the processor or reset the board and access memory
> after this point?  You should see if you can access __log_buf (Look in
> System.map for the address and subtract 0xc0000000 to get the physical
> address).   __log_buf should give you clues about how far booting
> progresses.
>
>   
As soon as my abatron debugger is back I'll give it a try - currently 
it's out for an update ...
Are there any restrictions for the memory locations of the kernel, 
initrd and dtb images ?

Thanks for the help. I'll post the __log_buf tomorrow ... propably.

>>  The kernel has been build using the "MPC5200 simple" setup. I've added
>>  our board identifier "mv,mvbluecougar" to the list of supported boards
>>  in the "mpc52xx_simple.c" file. This identifier is used in the dtb as
>>  well of course. This should be enough along with a valid device tree
>>  blob, isn't it ? Did I miss anything already ?
>>     
>
> Yes, this should be enough (on a side note; it should probably be
> "matrix-vision,bluecougar" unless of''mv' is your company's stock
> ticker symbol).
>
>   
>>  As far as I did understand by reading the docs it should be possible
>>  running a general MPC52xx kernel with a custom dtb ? Is this correct ?
>>     
>
> That is correct.
>
>   
>>  The dts file has already been reduced to a minimum, i.e. only the cpu,
>>  pic, xlb and a few nodes like psc1 and psc2 are present. No bestcomm,
>>  pci, ata or "advanced" features like mtd partitions. All I want to get
>>  working is the serial console on "/dev/ttyPSC0".
>>     
>
> Cheers,
> g.
>
>   
regards,
André


MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

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

^ permalink raw reply

* [PATCH] arch/powerpc/platforms/iseries/pci.c: Use time_* macros
From: S.Çağlar Onur @ 2008-03-17  9:36 UTC (permalink / raw)
  To: linux-kernel; +Cc: linuxppc-dev, Andrew Morton, Paul Mackerras
In-Reply-To: <1205746593-24820-3-git-send-email-caglar@pardus.org.tr>

The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values.

So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly

Cc: linuxppc-dev@ozlabs.org
Cc: Paul Mackerras <paulus@samba.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr>
---
 arch/powerpc/platforms/iseries/pci.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/iseries/pci.c b/arch/powerpc/platforms/iseries/pci.c
index cc562e4..02a634f 100644
--- a/arch/powerpc/platforms/iseries/pci.c
+++ b/arch/powerpc/platforms/iseries/pci.c
@@ -23,6 +23,7 @@
 
 #undef DEBUG
 
+#include <linux/jiffies.h>
 #include <linux/kernel.h>
 #include <linux/list.h>
 #include <linux/string.h>
@@ -586,7 +587,7 @@ static inline struct device_node *xlate_iomm_address(
 		static unsigned long last_jiffies;
 		static int num_printed;
 
-		if ((jiffies - last_jiffies) > 60 * HZ) {
+		if (time_after(jiffies, last_jiffies + 60 * HZ)) {
 			last_jiffies = jiffies;
 			num_printed = 0;
 		}
-- 
1.5.4.3

^ permalink raw reply related

* [PATCH 11/11] hvcbeat: fix buffer manipulation
From: Ishizaki Kou @ 2008-03-17 10:05 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev

This patch fixes a potential bug at drivers/char/hvc_beat.c.
 - hvc_put_term_char routine will decrement "rest" variable twice,
   and forget to advance "buf" pointer by "nlen" bytes.
This bug was not hit because the output handler in
drivers/char/hvc_console.c splits given output into 16 bytes
at maximum.

This patch is one of a series that I posted on Mar.14, "celleb:
patchset for 2.6.26 (take2)". I send this again because it
would be lost.

Reported-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/char/hvc_beat.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/drivers/char/hvc_beat.c
===================================================================
--- a/drivers/char/hvc_beat.c	2008-03-10 14:11:57.000000000 +0900
+++ b/drivers/char/hvc_beat.c	2008-03-10 14:13:40.000000000 +0900
@@ -78,8 +78,8 @@
 	for (rest = cnt; rest > 0; rest -= nlen) {
 		nlen = (rest > 16) ? 16 : rest;
 		memcpy(kb, buf, nlen);
-		beat_put_term_char(vtermno, rest, kb[0], kb[1]);
-		rest -= nlen;
+		beat_put_term_char(vtermno, nlen, kb[0], kb[1]);
+		buf += nlen;
 	}
 	return cnt;
 }

^ permalink raw reply

* Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
From: Jeff Garzik @ 2008-03-17 12:08 UTC (permalink / raw)
  To: Stefan Roese; +Cc: netdev, linuxppc-dev
In-Reply-To: <1205488348-22536-1-git-send-email-sr@denx.de>

Stefan Roese wrote:
> From: Pravin M. Bathija <pbathija@amcc.com>
> 
> Problem Description and Fix
> ---------------------------
> When a pause packet(with destination as reserved Multicast address) is
> received by the EMAC hardware to control the flow of frames being
> transmitted by it, it is dropped by the hardware unless the reserved
> Multicast address is hashed in to the GAHT[1-4] registers. This code fix
> adds the default reserved multicast address to the GAHT[1-4] registers
> in the EMAC(s) present on the chip. The flow control with Pause packets
> will only work if the following register bits are programmed in EMAC:
> EMACx_MR1[APP] = 1
> EMACx_RMR[BAE] = 1
> EMACx_RMR[MAE] = 1
> 
> Behavior that may be observed in a running system
> -------------------------------------------------
> A host transferring data from a PPC based system may send a Pause packet
> to the PPC EMAC requesting it to slow down the flow of packets. If the
> default reserved multicast MAC address is not programmed into the
> GAHT[1-4] registers this Pause packet will be dropped by PPC EMAC and no
> Flow Control will be done.
> 
> Signed-off-by: Pravin M. Bathija <pbathija@amcc.com>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
>  drivers/net/ibm_newemac/core.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)

applied

^ permalink raw reply

* Re: [PATCH] net: NEWEMAC: Add compatible "ibm,tah" to tah matching table
From: Jeff Garzik @ 2008-03-17 12:08 UTC (permalink / raw)
  To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1205423983-21142-1-git-send-email-sr@denx.de>

Stefan Roese wrote:
> Add "ibm,tah" to the compatible matching table of the ibm_newemac
> tah driver. The type "tah" is still preserved for compatibility reasons.
> New dts files should use the compatible property though.
> 
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
>  drivers/net/ibm_newemac/tah.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)

applied

^ permalink raw reply

* Re: [PATCH 1/4] Emerson ATCA-C125 bootwrapper
From: Alexandr Smirnov @ 2008-03-17 12:19 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080315001036.GA3487@localhost.localdomain>

David,
>> +	/* Unfortunately, the specific model number is encoded in the
>> +	 * soc node name in existing dts files -- once that is fixed,
>> +	 * this can do a simple path lookup.
>> +	 */
>>     
>
> Since this is a new board, couldn't you name the soc node /soc and
> dispense with this more complicated way of doing things?  Or would
> that break other versions of u-boot that are in use?
>   
As I understand you would like to rename /soc8548 node to /soc and make 
a simple path lookup like following:
- soc = find_node_by_devtype(NULL, "soc");
+ soc = finddevice("/soc");
Is this correct?

But fsl_soc code still uses of_find_node_by_type so we can't remove 
device_type property from node /soc and therefor simplify device tree.


Thanks,
Alexandr

^ permalink raw reply

* [PATCH v2] MTD support for the AMCC Taishan
From: Imre Kaloz @ 2008-03-17 13:48 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <200802081532.42717.sr@denx.de>

Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
---
 arch/powerpc/boot/dts/taishan.dts      |   29 +++++++++++-
 arch/powerpc/configs/taishan_defconfig |   79 +++++++++++++++++++++++++++++++-
 2 files changed, 106 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
index 8278068..db102e9 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -174,7 +174,34 @@
 				interrupts = <5 4>;
 				interrupt-parent = <&UIC1>;
 
-				/* TODO: Add other EBC devices */
+				nor_flash@0,0 {
+					compatible = "cfi-flash";
+					bank-width = <4>;
+					device-width = <2>;
+					reg = <0 000000 4000000>;
+					#address-cells = <1>;
+					#size-cells = <1>;
+					partition@0 {
+						label = "kernel";
+						reg = <0 180000>;
+					};
+					partition@180000 {
+						label = "root";
+						reg = <180000 200000>;
+					};
+					partition@380000 {
+						label = "user";
+						reg = <380000 3bc0000>;
+					};
+					partition@3f40000 {
+						label = "env";
+						reg = <3f40000 80000>;
+					};
+					partition@3fc0000 {
+						label = "u-boot";
+						reg = <3fc0000 40000>;
+					};
+				};
 			};
 
 
diff --git a/arch/powerpc/configs/taishan_defconfig b/arch/powerpc/configs/taishan_defconfig
index 087aedc..e53c926 100644
--- a/arch/powerpc/configs/taishan_defconfig
+++ b/arch/powerpc/configs/taishan_defconfig
@@ -348,7 +348,83 @@ CONFIG_FW_LOADER=y
 # CONFIG_SYS_HYPERVISOR is not set
 CONFIG_CONNECTOR=y
 CONFIG_PROC_EVENTS=y
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+CONFIG_MTD_CMDLINE_PARTS=y
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+# CONFIG_MTD_BLKDEVS is not set
+# CONFIG_MTD_BLOCK is not set
+# CONFIG_MTD_BLOCK_RO is not set
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+# CONFIG_MTD_OOPS is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+# CONFIG_MTD_JEDECPROBE is not set
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+# CONFIG_MTD_CFI_INTELEXT is not set
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+# CONFIG_MTD_PHYSMAP is not set
+CONFIG_MTD_PHYSMAP_OF=y
+# CONFIG_MTD_INTEL_VR_NOR is not set
+# CONFIG_MTD_PLATRAM is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_PMC551 is not set
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_PHRAM is not set
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+# CONFIG_MTD_NAND is not set
+# CONFIG_MTD_ONENAND is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI is not set
 CONFIG_OF_DEVICE=y
 # CONFIG_PARPORT is not set
 CONFIG_BLK_DEV=y
@@ -660,6 +736,7 @@ CONFIG_TMPFS=y
 # CONFIG_BEFS_FS is not set
 # CONFIG_BFS_FS is not set
 # CONFIG_EFS_FS is not set
+# CONFIG_JFFS2_FS is not set
 CONFIG_CRAMFS=y
 # CONFIG_VXFS_FS is not set
 # CONFIG_MINIX_FS is not set
-- 
1.5.2.5

^ permalink raw reply related

* Re: [PATCH v2] MTD support for the AMCC Taishan
From: Imre Kaloz @ 2008-03-17 14:27 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <12057617031716-git-send-email-kaloz@openwrt.org>

On Mon, 17 Mar 2008 14:48:23 +0100, Imre Kaloz <kaloz@openwrt.org> wrote:

<snip>

Sorry, forgot to note that this version removes the "kozio" and extends  
the "user" partition accordingly, as Stefan asked.


Imre

^ permalink raw reply

* RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
From: Rick Moleres @ 2008-03-17 15:24 UTC (permalink / raw)
  To: Mohammad Sadegh Sadri, Stephen Neuendorffer,
	Koss, Mike(Mission Systems), linuxppc-embedded
In-Reply-To: <BAY115-W53AE071415B85C1E71AAD1B2050@phx.gbl>

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

You should be able to contact your Xilinx sales rep for details on
Virtex-5 FX as well as roadmap information.  The Virtex-5 FXT product is
coming soon and should be announced within the next month or so.  I
can't provide details, but your technical sales contact should be able
to give you more info on timelines etc...

 

As for EDK releases, Xilinx typically releases two per year (e.g., EDK
9.1 and 9.2 were both released in 2007).  EDK 10.1 is scheduled for
release before summer, and should be the only release in 2008 (with some
service packs throughout the year).   There shouldn't be any major
differences from EDK 9.2.02 regarding IP/drivers.

 

-Rick

 

________________________________

From: linuxppc-embedded-bounces+moleres=xilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+moleres=xilinx.com@ozlabs.org] On
Behalf Of Mohammad Sadegh Sadri
Sent: Monday, March 17, 2008 3:04 AM
To: Stephen Neuendorffer; Koss, Mike(Mission Systems);
linuxppc-embedded@ozlabs.org
Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS
LLTEMAC

 

Ok, thanks for guidance,

by the way it is interesting for me to hear about EDK 10.1 from u steve,

EDK 9.2 has been around just for a little time and you are going to
10.1?

What about future plan of xilinx about Virtex-5 FX? does this tool
consider that? 
the future plan is really important for our development team. let me
give a simple example, our dev team worked on the design of our system
based on PLB and OPB buses for some thing near 6 month, just then EDK
9.2.02 released and suddenly we forced to change all of the designs and
to define new activities specially focusing on MPMC. we did never
consider MPMC before, but the release of EDK 9.2 changed every thing. 

Now, that would be nice, if we can know your future plan a little, that
would help us to generate correct and real gant charts. and to assign
human resources correctly. this is also true for the project budget. We
know that Virtex-5 devices are really capable of doing better things
than Virtex-4, specially the PCI express option is great and very usable
for us, but we have not moved to virtex-5 yet, because there is no FX
series or at least we do not know your plan about it. Our managers we
seriously asking us if we have to move to Virtex-5 soon, we did not have
any reasonable answer for them because we do not have any info from u at
all.

thanks

________________________________

Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS
LLTEMAC
Date: Sun, 16 Mar 2008 14:43:33 -0700
From: stephen.neuendorffer@xilinx.com
To: mike.koss@ngc.com; mamsadegh@hotmail.com;
linuxppc-embedded@ozlabs.org


Ah, thanks mike...  you knocked the answer loose out of my brain...

In EDK 9.2., the ll_temac generates either SDMA or FIFO defines, as
necessary.
The platform data structure contains entries for both, with the correct
ones being ignored.  In order to get the code to compile, there are some
defines in xparameters.h which have:

#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR 0xdeadbeef
#endif
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR 0xdeadbeef
#endif
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR 0xdeadbeef
#endif

after including xparameter_ml403.h

I'm guessing maybe you overwrote the xparameters.h file and got rid of
these redefines?  You can define it to be whatever you want, since the
value will be ignored if you are using SDMA.

In EDK 10.1, the BSP generator will always generate all the defines
(even ones which are not sensible in the current configuration), which
avoids the above annoyances.

Steve

-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on
behalf of Koss, Mike (Mission Systems)
Sent: Sat 3/15/2008 9:12 PM
To: Mohammad Sadegh Sadri; linuxppc-embedded@ozlabs.org
Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS
LLTEMAC

That interrupt is defined if you build a xps_ll_temac with the
xps_ll_fifo interface. Since you already stated that you're using the
mpmc, I'm going to assume that you have it connected to a SDMA
controller on the mpmc. As such the driver should be looking for that
definition, and not the FIFO interrupt. I don't have your version of the
virtex_devices.c to have a reference as to how the platform device is
being defined, so hopefully either Stephen N can chime in w/ more
information, or point me to the version of the virtex_devices.c that
you're using and I can try to provide some more assistance.

-- Mike

________________________________

From: Mohammad Sadegh Sadri [mailto:mamsadegh@hotmail.com]
Sent: Saturday, March 15, 2008 4:31 AM
To: linuxppc-embedded@ozlabs.org
Subject: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC


All,

that should be a small problem, and i think that its solution should be
simple,

I generate a base system using EDK 9.2.02 , the base system contains
XPS_LL_TEMAC , MPMC and other components,
I generate the software libraries and copy xparameters file into proper
kernel folder. I configure that kernel and add kernel support for
XPS_LL_TEMAC.

while doing make I encounter this error:

arch/ppc/syslib/virtex_devices.c:455: error:
'XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR' undeclared here (not in a
function)

I think that this definition should be available in xparameters_ml403.h
file but i see that there is no such definition.
I added a dummy definition for myself there to complete kernel
compilation, don't know the correct value for it of course.

thanks



________________________________

Access your files from anywhere with Windows Live SkyDrive! Sign up now
and get 5GB of space FREE! <http://g.msn.ca/ca55/209> 



 

________________________________

Is your lingo strong enough to ace these new word puzzles from Live
Search Games? Click here to test your vocab! <http://g.msn.ca/ca55/214> 


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

^ permalink raw reply

* Re: Trouble with SCC UART ports when moving from ppc to powerpc
From: Scott Wood @ 2008-03-17 15:33 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200803101317.04455.laurentp@cse-semaphore.com>

On Mon, Mar 10, 2008 at 01:17:01PM +0100, Laurent Pinchart wrote:
> On Friday 07 March 2008 17:21, Scott Wood wrote:
> > cpm2_reset() doesn't currently actually reset the CPM, for some reason
> > (unlike cpm1).  This should probably be fixed, though then we'd have to
> > deal with assigning SMC parameter RAM addresses ourselves.
> 
> I had overlooked that. Resetting the CPM in cpm2_reset() helps. Is there any 
> reason not to rset the CPM in cpm2_reset() ?

The only issue I'm aware of other than the SMC parameter RAM relocation is
that the reset can't happen if the early udbg printk is being used.

> How should SMC parameter RAM assignment be handled ? I'm not very familiar 
> with the CPM1, 

CPM1 has hardcoded SMC parameter RAM addresses, so it's not relevant here.

> but for CPM2 the cpm_uart driver could easily cpm_dpalloc() parameter RAM.

It can, yes.  Patches welcome. :-)

-Scott

^ permalink raw reply

* RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
From: Stephen Neuendorffer @ 2008-03-17 15:49 UTC (permalink / raw)
  To: Mohammad Sadegh Sadri, Koss, Mike (Mission Systems),
	linuxppc-embedded
In-Reply-To: <BAY115-W53AE071415B85C1E71AAD1B2050@phx.gbl>


Sorry, but I'm not in a position to discuss product roadmaps.  The kinds
of technical questions are best handled by regular sales channels.

Steve

> -----Original Message-----
> From: Mohammad Sadegh Sadri [mailto:mamsadegh@hotmail.com]
> Sent: Monday, March 17, 2008 2:04 AM
> To: Stephen Neuendorffer; Koss, Mike (Mission Systems);
linuxppc-embedded@ozlabs.org
> Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS
LLTEMAC
>=20
> Ok, thanks for guidance,
>=20
> by the way it is interesting for me to hear about EDK 10.1 from u
steve,
> EDK 9.2 has been around just for a little time and you are going to
10.1?
>=20
> What about future plan of xilinx about Virtex-5 FX? does this tool
consider that?
> the future plan is really important for our development team. let me
give a simple example, our dev
> team worked on the design of our system based on PLB and OPB buses for
some thing near 6 month, just
> then EDK 9.2.02 released and suddenly we forced to change all of the
designs and to define new
> activities specially focusing on MPMC. we did never consider MPMC
before, but the release of EDK 9.2
> changed every thing.
>=20
> Now, that would be nice, if we can know your future plan a little,
that would help us to generate
> correct and real gant charts. and to assign human resources correctly.
this is also true for the
> project budget. We know that Virtex-5 devices are really capable of
doing better things than Virtex-
> 4, specially the PCI express option is great and very usable for us,
but we have not moved to virtex-
> 5 yet, because there is no FX series or at least we do not know your
plan about it. Our managers we
> seriously asking us if we have to move to Virtex-5 soon, we did not
have any reasonable answer for
> them because we do not have any info from u at all.
>=20
> thanks
>=20
>=20
>=20
> ________________________________
>=20
> 	Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for
XPS LLTEMAC
> 	Date: Sun, 16 Mar 2008 14:43:33 -0700
> 	From: stephen.neuendorffer@xilinx.com
> 	To: mike.koss@ngc.com; mamsadegh@hotmail.com;
linuxppc-embedded@ozlabs.org
>=20
>=20
>=20
> 	Ah, thanks mike...  you knocked the answer loose out of my
brain...
>=20
> 	In EDK 9.2., the ll_temac generates either SDMA or FIFO defines,
as necessary.
> 	The platform data structure contains entries for both, with the
correct ones being ignored.  In
> order to get the code to compile, there are some defines in
xparameters.h which have:
>=20
> 	#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR
> 	#define XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR 0xdeadbeef
> 	#endif
> 	#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR
> 	#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR 0xdeadbeef
> 	#endif
> 	#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR
> 	#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR 0xdeadbeef
> 	#endif
>=20
> 	after including xparameter_ml403.h
>=20
> 	I'm guessing maybe you overwrote the xparameters.h file and got
rid of these redefines?  You
> can define it to be whatever you want, since the value will be ignored
if you are using SDMA.
>=20
> 	In EDK 10.1, the BSP generator will always generate all the
defines (even ones which are not
> sensible in the current configuration), which avoids the above
annoyances.
>=20
> 	Steve
>=20
> 	-----Original Message-----
> 	From:
linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org on =
behalf
of Koss, Mike
> (Mission Systems)
> 	Sent: Sat 3/15/2008 9:12 PM
> 	To: Mohammad Sadegh Sadri; linuxppc-embedded@ozlabs.org
> 	Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for
XPS LLTEMAC
>=20
> 	That interrupt is defined if you build a xps_ll_temac with the
> 	xps_ll_fifo interface. Since you already stated that you're
using the
> 	mpmc, I'm going to assume that you have it connected to a SDMA
> 	controller on the mpmc. As such the driver should be looking for
that
> 	definition, and not the FIFO interrupt. I don't have your
version of the
> 	virtex_devices.c to have a reference as to how the platform
device is
> 	being defined, so hopefully either Stephen N can chime in w/
more
> 	information, or point me to the version of the virtex_devices.c
that
> 	you're using and I can try to provide some more assistance.
>=20
> 	-- Mike
>=20
> 	________________________________
>=20
> 	From: Mohammad Sadegh Sadri [mailto:mamsadegh@hotmail.com]
> 	Sent: Saturday, March 15, 2008 4:31 AM
> 	To: linuxppc-embedded@ozlabs.org
> 	Subject: Compile time error, compiling Xilinx Linux 2.6 for XPS
LLTEMAC
>=20
>=20
> 	All,
>=20
> 	that should be a small problem, and i think that its solution
should be
> 	simple,
>=20
> 	I generate a base system using EDK 9.2.02 , the base system
contains
> 	XPS_LL_TEMAC , MPMC and other components,
> 	I generate the software libraries and copy xparameters file into
proper
> 	kernel folder. I configure that kernel and add kernel support
for
> 	XPS_LL_TEMAC.
>=20
> 	while doing make I encounter this error:
>=20
> 	arch/ppc/syslib/virtex_devices.c:455: error:
> 	'XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR' undeclared here (not
in a
> 	function)
>=20
> 	I think that this definition should be available in
xparameters_ml403.h
> 	file but i see that there is no such definition.
> 	I added a dummy definition for myself there to complete kernel
> 	compilation, don't know the correct value for it of course.
>=20
> 	thanks
>=20
>=20
>=20
> 	________________________________
>=20
> 	Access your files from anywhere with Windows Live SkyDrive! Sign
up now
> 	and get 5GB of space FREE! <http://g.msn.ca/ca55/209>
>=20
>=20
>=20
>=20
>=20
> ________________________________
>=20
> Is your lingo strong enough to ace these new word puzzles from Live
Search Games? Click here to test
> your vocab! <http://g.msn.ca/ca55/214>

^ permalink raw reply

* RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
From: Stephen Neuendorffer @ 2008-03-17 15:58 UTC (permalink / raw)
  To: Qin Lin, linuxppc-embedded
In-Reply-To: <16089631.post@talk.nabble.com>


It should...  (I use it regularly on the xup board)
Did you remember to connect the interrupt line in your design?

Steve

> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Qin Lin
> Sent: Monday, March 17, 2008 12:36 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
>=20
>=20
> HI all,
>=20
> Is anyone have the opb_emac (no DMA) work with the kernel
linux-2.6-xlnx
> from git.xilinx.com.
> the message seams that it does work ,but the command ping return
nothing!
>=20
> Could you kindly suggest me what to do?
>=20
> ps:
> the kernel booting message
> [    0.258674] net_namespace: 64 bytes
> [    0.269780] NET: Registered protocol family 16
> [    0.290415] Registering device xilinx_emac:0
> [    0.381687] NET: Registered protocol family 2
> [    0.392324] IP route cache hash table entries: 2048 (order: 1, 8192
> bytes)
> [    0.399556] TCP established hash table entries: 8192 (order: 4,
65536
> bytes)
> [    0.403403] TCP bind hash table entries: 8192 (order: 3, 32768
bytes)
> [    0.405409] TCP: Hash tables configured (established 8192 bind
8192)
> [    0.405489] TCP reno registered
> [    0.412758] sysctl table check failed: /kernel/l2cr .1.31 Missing
> strategy
> [    0.413189] Call Trace:
> [    0.413244] [cf41feb0] [c0008178] show_stack+0x48/0x184
(unreliable)
> [    0.413467] [cf41fed0] [c00303c8] set_fail+0x50/0x68
> [    0.413640] [cf41fef0] [c0030b54] sysctl_check_table+0x64c/0x698
> [    0.413724] [cf41ff20] [c0030b68] sysctl_check_table+0x660/0x698
> [    0.413802] [cf41ff50] [c001e810] register_sysctl_table+0x64/0xb4
> [    0.414141] [cf41ff70] [c01e4b1c]
register_ppc_htab_sysctl+0x18/0x2c
> [    0.414311] [cf41ff80] [c01de1e4] kernel_init+0xc8/0x284
> [    0.414384] [cf41fff0] [c0004ab8] kernel_thread+0x44/0x60
>=20
> [    1.116395] xilinx_emac xilinx_emac.0: MAC address is now  2: 0: 0:
0: 0:
> 0
> [    1.123790] XEmac: using fifo mode.
> [    1.128188] XEmac: Detected PHY at address 0, ManufID 0x0013, Rev.
> 0x78e2.
> [    1.135715] eth0: Dropping NETIF_F_SG since no checksum feature.
> [    1.151038] eth0: Xilinx 10/100 EMAC at 0x40C00000 mapped to
0xD0020000,
> irq=3D2
> [    1.158713] eth0: XEmac id 1.4a, block id 128, type 1
> [    1.194661] TCP cubic registered
> [    1.198647] NET: Registered protocol family 1
> [    1.203728] NET: Registered protocol family 17
>=20
>=20
> #ping 192.168.26.1 &
> # ifconfig eth0
> eth0      Link encap:Ethernet  HWaddr 02:00:00:00:00:00
>           inet addr:192.168.26.127  Bcast:192.168.26.255
Mask:255.255.255.0
>           UP BROADCAST RUNNING  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:0 (0.0 B)  TX bytes:672 (672.0 B)
>           Interrupt:2 Memory:40c00000-40c0ffff
>=20
> Regards
>=20
> Qin Lin
> --
> View this message in context:
http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-
> xlnx-tp16089631p16089631.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply

* Re: Interrupt handling documentation
From: Laurent Pinchart @ 2008-03-17 16:13 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <200803131456.26722.laurentp@cse-semaphore.com>

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

On Thursday 13 March 2008 14:56, Laurent Pinchart wrote:
> Hi Michael,
>
> On Wednesday 12 March 2008 01:51, Michael Ellerman wrote:
> > On Tue, 2008-03-11 at 11:58 +0100, Laurent Pinchart wrote:
> > > Hi everybody,
> > >
> > > is there any documentation describing interrupt handling for the
> > > powerpc architecture ? I'm writing a driver for a cascaded interrupt
> > > controller and the only source of information I found was the code.
> >
> > I don't think there's much documentation.
>
> I feared so :-)
>
> > You might want to look at arch/powerpc/platforms/cell/axon_msi.c, it's a
> > reasonably simple example of how to setup an irq_host and so on - well I
> > think so :D
>
> Thanks for the pointer.
>
> > > I'm particularly interested in information about irq hosts (allocation
> > > and initialisation, especially the map and unmap callbacks) and irq
> > > chaining. Different drivers seem to implement cascaded irqs differently
> > > (for instance arch/powerpc/sysdev/uic.c uses setup_irq to register the
> > > cascaded irq handler, while
> > > arch/powerpc/platforms/82xx/pq2ads-pci-pic.c uses
> > > set_irq_chained_handler) so I'm a bit lost here.
> >
> > uic.c uses set_irq_chained_handler() now, so that probably answers that
> > question. I don't think it makes all that much difference if you set it
> > up by hand, but set_irq_chained_handler() is the neat way to do it.
>
> That pretty much answers my question. It's always a bit disturbing when
> different drivers use different APIs to accomplish the same task,
> especially when the lack of documentation doesn't clearly state which API
> should be used and which API is internal/deprecated.

I've been struggling with spurious interrupts related to my irq host for a 
day. Now that I've been able to solve the problem I thought I'd share the 
results here.

The PIC I am working with is linked to a falling-edge external irq on the 
CPM2. When the first PIC interrupt was generated the kernel called the PIC 
chained irq handler endlessly.

After some investigation it turned out the external interrupt bit in the CPM2 
interrupt pending register never got cleared. set_irq_chained_handler() 
registers the chained irq handler at the lowest level in the irq stack, 
bypassing all the interrupt acknowledgement/masking logic.

The fix was easy, all I had to do was to call desc->chip->ack(irq) at the 
beginning on the chained irq handler and desc->chip->eoi(irq) at the end. 
However, I'm wondering if this really belongs in the PIC code, or if PICs 
shouldn't be registered at a higher level (setup_irq or even request_irq) so 
that they would reuse the handle_*_irq handlers. Any opinion on this ?

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

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

^ permalink raw reply

* [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization
From: John Linn @ 2008-03-17 16:41 UTC (permalink / raw)
  To: linuxppc-dev, jwboyer; +Cc: John Linn

The UART 16550 initialization was not setting up the registers
correctly. Code was added to pull the frequency and speed from
the device tree and initialize the registers using those values.

The boot code was not and is still not using the cmd line
to setup up the uart. The frequency of the clock driving the
UART must be specified in the device tree so that the baud
rate generator can be setup.

---

Please pull this patch for 2.6.26.
---
 arch/powerpc/boot/ns16550.c |   69 +++++++++++++++++++++++++++++++++---------
 1 files changed, 54 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
index f8f1b2f..d8edd48 100644
--- a/arch/powerpc/boot/ns16550.c
+++ b/arch/powerpc/boot/ns16550.c
@@ -15,23 +15,47 @@
 #include "io.h"
 #include "ops.h"
 
-#define UART_DLL	0	/* Out: Divisor Latch Low */
-#define UART_DLM	1	/* Out: Divisor Latch High */
-#define UART_FCR	2	/* Out: FIFO Control Register */
-#define UART_LCR	3	/* Out: Line Control Register */
-#define UART_MCR	4	/* Out: Modem Control Register */
-#define UART_LSR	5	/* In:  Line Status Register */
-#define UART_LSR_THRE	0x20	/* Transmit-hold-register empty */
-#define UART_LSR_DR	0x01	/* Receiver data ready */
-#define UART_MSR	6	/* In:  Modem Status Register */
-#define UART_SCR	7	/* I/O: Scratch Register */
-
-static unsigned char *reg_base;
-static u32 reg_shift;
+#define UART_DLL		0	/* Out: Divisor Latch Low */
+#define UART_DLM		1	/* Out: Divisor Latch High */
+#define UART_FCR		2	/* Out: FIFO Control Register */
+#define UART_FCR_CLEAR_RCVR 	0x02 	/* Clear the RCVR FIFO */
+#define UART_FCR_CLEAR_XMIT	0x04 	/* Clear the XMIT FIFO */
+#define UART_LCR		3	/* Out: Line Control Register */
+#define UART_MCR		4	/* Out: Modem Control Register */
+#define UART_MCR_RTS		0x02 	/* RTS complement */
+#define UART_MCR_DTR		0x01 	/* DTR complement */
+#define UART_LSR		5	/* In:  Line Status Register */
+#define UART_LSR_THRE		0x20	/* Transmit-hold-register empty */
+#define UART_LSR_DR		0x01	/* Receiver data ready */
+#define UART_LCR_DLAB		0x80 	/* Divisor latch access bit */
+#define UART_LCR_WLEN8		0x03 	/* Wordlength: 8 bits */
+#define UART_MSR		6	/* In:  Modem Status Register */
+#define UART_SCR		7	/* I/O: Scratch Register */
+
+volatile static unsigned char *reg_base;
+volatile static u32 reg_shift;
+volatile static u16 divisor;
 
 static int ns16550_open(void)
 {
-	out_8(reg_base + (UART_FCR << reg_shift), 0x06);
+
+	/* Access baud rate */
+	out_8(reg_base + (UART_LCR << reg_shift), UART_LCR_DLAB);
+
+	/* Baud rate based on input clock */
+	out_8(reg_base + (UART_DLL << reg_shift), divisor & 0xFF);
+	out_8(reg_base + (UART_DLM << reg_shift), divisor >> 8);
+
+	/* 8 data, 1 stop, no parity */
+	out_8(reg_base + (UART_LCR << reg_shift), UART_LCR_WLEN8);
+
+	/* RTS/DTR */
+	out_8(reg_base + (UART_MCR << reg_shift), UART_MCR_RTS | UART_MCR_DTR);
+
+	/* Clear transmitter and receiver */
+	out_8(reg_base + (UART_FCR << reg_shift), 
+				UART_FCR_CLEAR_XMIT | UART_FCR_CLEAR_RCVR);
+
 	return 0;
 }
 
@@ -56,6 +80,7 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
 {
 	int n;
 	unsigned long reg_phys;
+	u32 clk, spd;
 
 	n = getprop(devp, "virtual-reg", &reg_base, sizeof(reg_base));
 	if (n != sizeof(reg_base)) {
@@ -65,9 +90,23 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
 		reg_base = (void *)reg_phys;
 	}
 
-	n = getprop(devp, "reg-shift", &reg_shift, sizeof(reg_shift));
+	n = getprop(devp, "reg-shift", (void *)&reg_shift, sizeof(reg_shift));
 	if (n != sizeof(reg_shift))
 		reg_shift = 0;
+	
+	/* the base address has to change for devices with odd reg spacing */
+	reg_base = reg_base + ((1 << reg_shift) - 1); 
+
+	n = getprop(devp, "current-speed", (void *)&spd, sizeof(spd));
+	if (n != sizeof(spd))
+		spd = 9600;
+
+	/* should there be a default clock rate?*/
+	n = getprop(devp, "clock-frequency", (void *)&clk, sizeof(clk));
+	if (n != sizeof(clk))
+		return -1;
+
+	divisor = clk / (16 * spd);
 
 	scdp->open = ns16550_open;
 	scdp->putc = ns16550_putc;
-- 
1.5.2.1

^ permalink raw reply related

* [PATCH 2/3] Xilinx: hwicap: Verify sync before reading idcode.
From: Stephen Neuendorffer @ 2008-03-17 17:36 UTC (permalink / raw)
  To: grant.likely, git-dev, linuxppc-dev, linux-kernel
In-Reply-To: <1205775392-32222-2-git-send-email-stephen.neuendorffer@xilinx.com>

It appears that in some cases, the sync word might not be recognized
by the hardware correctly.  If this happens, then attempting to read
from the port results in an unrecoverable error because of the design
of the FPGA core.  This patch updates the code to check the status of
the device before reading the IDCODE, in order to avoid entering this
unrecoverable state.  This patch also adds additional NOOP commands
into the sychronization sequence, which appears to be necessary to
avoid the condition on some hardware.

Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
 drivers/char/xilinx_hwicap/xilinx_hwicap.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
index 304727d..5b8d646 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
@@ -250,8 +250,26 @@ static int hwicap_get_configuration_register(struct hwicap_drvdata *drvdata,
 	 * Create the data to be written to the ICAP.
 	 */
 	buffer[index++] = XHI_DUMMY_PACKET;
+	buffer[index++] = XHI_NOOP_PACKET;
 	buffer[index++] = XHI_SYNC_PACKET;
 	buffer[index++] = XHI_NOOP_PACKET;
+	buffer[index++] = XHI_NOOP_PACKET;
+
+	/*
+	 * Write the data to the FIFO and initiate the transfer of data present
+	 * in the FIFO to the ICAP device.
+	 */
+	status = drvdata->config->set_configuration(drvdata,
+						    &buffer[0], index);
+	if (status)
+		return status;
+
+	/* If the syncword was not found, then we need to start over. */
+	status = drvdata->config->get_status(drvdata);
+	if ((status & XHI_SR_DALIGN_MASK) != XHI_SR_DALIGN_MASK)
+		return -EIO;
+
+	index = 0;
 	buffer[index++] = hwicap_type_1_read(reg) | 1;
 	buffer[index++] = XHI_NOOP_PACKET;
 	buffer[index++] = XHI_NOOP_PACKET;
-- 
1.5.3.4-dirty

^ permalink raw reply related

* [PATCH 0/3] Xilinx hwicap updates
From: Stephen Neuendorffer @ 2008-03-17 17:36 UTC (permalink / raw)
  To: grant.likely, git-dev, linuxppc-dev, linux-kernel

The following sequence of patches makes the icap driver more robust,
by making better use of the status information from the cores.  In
addition, Lanana has assigned Major 259 for FPGA configuration
interfaces, so we now use it, rather than dynamically finding a major
number.

Grant: please pick these up for 2.6.26.  Do you think it's worth
patching virtex_devices.c at this point, or just punt on ARCH=ppc?

Steve

^ permalink raw reply

* [PATCH 3/3] Xilinx: hwicap: Use fixed device major.
From: Stephen Neuendorffer @ 2008-03-17 17:36 UTC (permalink / raw)
  To: grant.likely, git-dev, linuxppc-dev, linux-kernel
In-Reply-To: <1205775392-32222-3-git-send-email-stephen.neuendorffer@xilinx.com>

Major 259 has been assigned by lanana.  Use it.  Also, publish
/dev/icap[0-k] as the device entries, and register platform devices
named 'icap' to be consistent.

Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
 drivers/char/xilinx_hwicap/xilinx_hwicap.c |   43 +++++++++-------------------
 1 files changed, 14 insertions(+), 29 deletions(-)

diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
index 5b8d646..016f905 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
@@ -36,7 +36,7 @@
  *****************************************************************************/
 
 /*
- * This is the code behind /dev/xilinx_icap -- it allows a user-space
+ * This is the code behind /dev/icap* -- it allows a user-space
  * application to use the Xilinx ICAP subsystem.
  *
  * The following operations are possible:
@@ -67,7 +67,7 @@
  * user-space application code that uses this device.  The simplest
  * way to use this interface is simply:
  *
- * cp foo.bit /dev/xilinx_icap
+ * cp foo.bit /dev/icap0
  *
  * Note that unless foo.bit is an appropriately constructed partial
  * bitstream, this has a high likelyhood of overwriting the design
@@ -105,18 +105,14 @@
 #include "buffer_icap.h"
 #include "fifo_icap.h"
 
-#define DRIVER_NAME "xilinx_icap"
+#define DRIVER_NAME "icap"
 
 #define HWICAP_REGS   (0x10000)
 
-/* dynamically allocate device number */
-static int xhwicap_major;
-static int xhwicap_minor;
+#define XHWICAP_MAJOR 259
+#define XHWICAP_MINOR 0
 #define HWICAP_DEVICES 1
 
-module_param(xhwicap_major, int, S_IRUGO);
-module_param(xhwicap_minor, int, S_IRUGO);
-
 /* An array, which is set to true when the device is registered. */
 static bool probed_devices[HWICAP_DEVICES];
 static struct mutex icap_sem;
@@ -605,7 +601,7 @@ static int __devinit hwicap_setup(struct device *dev, int id,
 	probed_devices[id] = 1;
 	mutex_unlock(&icap_sem);
 
-	devt = MKDEV(xhwicap_major, xhwicap_minor + id);
+	devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR + id);
 
 	drvdata = kzalloc(sizeof(struct hwicap_drvdata), GFP_KERNEL);
 	if (!drvdata) {
@@ -710,7 +706,7 @@ static int __devexit hwicap_remove(struct device *dev)
 	dev_set_drvdata(dev, NULL);
 
 	mutex_lock(&icap_sem);
-	probed_devices[MINOR(dev->devt)-xhwicap_minor] = 0;
+	probed_devices[MINOR(dev->devt)-XHWICAP_MINOR] = 0;
 	mutex_unlock(&icap_sem);
 	return 0;		/* success */
 }
@@ -850,23 +846,12 @@ static int __init hwicap_module_init(void)
 	icap_class = class_create(THIS_MODULE, "xilinx_config");
 	mutex_init(&icap_sem);
 
-	if (xhwicap_major) {
-		devt = MKDEV(xhwicap_major, xhwicap_minor);
-		retval = register_chrdev_region(
-				devt,
-				HWICAP_DEVICES,
-				DRIVER_NAME);
-		if (retval < 0)
-			return retval;
-	} else {
-		retval = alloc_chrdev_region(&devt,
-				xhwicap_minor,
-				HWICAP_DEVICES,
-				DRIVER_NAME);
-		if (retval < 0)
-			return retval;
-		xhwicap_major = MAJOR(devt);
-	}
+	devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR);
+	retval = register_chrdev_region(devt,
+					HWICAP_DEVICES,
+					DRIVER_NAME);
+	if (retval < 0)
+		return retval;
 
 	retval = platform_driver_register(&hwicap_platform_driver);
 
@@ -891,7 +876,7 @@ static int __init hwicap_module_init(void)
 
 static void __exit hwicap_module_cleanup(void)
 {
-	dev_t devt = MKDEV(xhwicap_major, xhwicap_minor);
+	dev_t devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR);
 
 	class_destroy(icap_class);
 
-- 
1.5.3.4-dirty

^ permalink raw reply related

* [PATCH 1/3] Xilinx: hwicap: Refactor status handling code.
From: Stephen Neuendorffer @ 2008-03-17 17:36 UTC (permalink / raw)
  To: grant.likely, git-dev, linuxppc-dev, linux-kernel
In-Reply-To: <1205775392-32222-1-git-send-email-stephen.neuendorffer@xilinx.com>

Both the buffer-based and fifo-based icap cores have a status
register.  Previously, this was only used internally to check whether
transactions have completed.  However, the status can be useful to the
main driver as well.  This patch exposes these status functions to the
main driver along with some masks for the differnet bits.

Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
 drivers/char/xilinx_hwicap/buffer_icap.c   |   22 ++++---------------
 drivers/char/xilinx_hwicap/buffer_icap.h   |    5 ++-
 drivers/char/xilinx_hwicap/fifo_icap.c     |   31 ++++++++++++++++++++-------
 drivers/char/xilinx_hwicap/fifo_icap.h     |    1 +
 drivers/char/xilinx_hwicap/xilinx_hwicap.c |    2 +
 drivers/char/xilinx_hwicap/xilinx_hwicap.h |   24 +++++++++++++++++++++
 6 files changed, 58 insertions(+), 27 deletions(-)

diff --git a/drivers/char/xilinx_hwicap/buffer_icap.c b/drivers/char/xilinx_hwicap/buffer_icap.c
index f577dae..aa7f796 100644
--- a/drivers/char/xilinx_hwicap/buffer_icap.c
+++ b/drivers/char/xilinx_hwicap/buffer_icap.c
@@ -74,7 +74,7 @@
 
 /**
  * buffer_icap_get_status - Get the contents of the status register.
- * @base_address: is the base address of the device
+ * @drvdata: a pointer to the drvdata.
  *
  * The status register contains the ICAP status and the done bit.
  *
@@ -88,9 +88,9 @@
  * D1 - Always 1
  * D0 - Done bit
  **/
-static inline u32 buffer_icap_get_status(void __iomem *base_address)
+u32 buffer_icap_get_status(struct hwicap_drvdata *drvdata)
 {
-	return in_be32(base_address + XHI_STATUS_REG_OFFSET);
+	return in_be32(drvdata->base_address + XHI_STATUS_REG_OFFSET);
 }
 
 /**
@@ -117,20 +117,8 @@ static inline u32 buffer_icap_get_bram(void __iomem *base_address,
  **/
 static inline bool buffer_icap_busy(void __iomem *base_address)
 {
-	return (buffer_icap_get_status(base_address) & 1) == XHI_NOT_FINISHED;
-}
-
-/**
- * buffer_icap_busy - Return true if the icap device is not busy
- * @base_address: is the base address of the device
- *
- * The queries the low order bit of the status register, which
- * indicates whether the current configuration or readback operation
- * has completed.
- **/
-static inline bool buffer_icap_done(void __iomem *base_address)
-{
-	return (buffer_icap_get_status(base_address) & 1) == XHI_FINISHED;
+	u32 status = in_be32(base_address + XHI_STATUS_REG_OFFSET);
+	return (status & 1) == XHI_NOT_FINISHED;
 }
 
 /**
diff --git a/drivers/char/xilinx_hwicap/buffer_icap.h b/drivers/char/xilinx_hwicap/buffer_icap.h
index 0318495..c5b1840 100644
--- a/drivers/char/xilinx_hwicap/buffer_icap.h
+++ b/drivers/char/xilinx_hwicap/buffer_icap.h
@@ -44,8 +44,6 @@
 #include <asm/io.h>
 #include "xilinx_hwicap.h"
 
-void buffer_icap_reset(struct hwicap_drvdata *drvdata);
-
 /* Loads a partial bitstream from system memory. */
 int buffer_icap_set_configuration(struct hwicap_drvdata *drvdata, u32 *data,
 			     u32 Size);
@@ -54,4 +52,7 @@ int buffer_icap_set_configuration(struct hwicap_drvdata *drvdata, u32 *data,
 int buffer_icap_get_configuration(struct hwicap_drvdata *drvdata, u32 *data,
 			     u32 Size);
 
+u32 buffer_icap_get_status(struct hwicap_drvdata *drvdata);
+void buffer_icap_reset(struct hwicap_drvdata *drvdata);
+
 #endif
diff --git a/drivers/char/xilinx_hwicap/fifo_icap.c b/drivers/char/xilinx_hwicap/fifo_icap.c
index 6f45dbd..776b505 100644
--- a/drivers/char/xilinx_hwicap/fifo_icap.c
+++ b/drivers/char/xilinx_hwicap/fifo_icap.c
@@ -78,13 +78,6 @@
 #define XHI_CR_READ_MASK 0x00000002 /* Read from ICAP to FIFO */
 #define XHI_CR_WRITE_MASK 0x00000001 /* Write from FIFO to ICAP */
 
-/* Status Register (SR) */
-#define XHI_SR_CFGERR_N_MASK 0x00000100 /* Config Error Mask */
-#define XHI_SR_DALIGN_MASK 0x00000080 /* Data Alignment Mask */
-#define XHI_SR_RIP_MASK 0x00000040 /* Read back Mask */
-#define XHI_SR_IN_ABORT_N_MASK 0x00000020 /* Select Map Abort Mask */
-#define XHI_SR_DONE_MASK 0x00000001 /* Done bit Mask  */
-
 
 #define XHI_WFO_MAX_VACANCY 1024 /* Max Write FIFO Vacancy, in words */
 #define XHI_RFO_MAX_OCCUPANCY 256 /* Max Read FIFO Occupancy, in words */
@@ -152,13 +145,35 @@ static inline void fifo_icap_start_readback(struct hwicap_drvdata *drvdata)
 }
 
 /**
+ * fifo_icap_get_status - Get the contents of the status register.
+ * @drvdata: a pointer to the drvdata.
+ *
+ * The status register contains the ICAP status and the done bit.
+ *
+ * D8 - cfgerr
+ * D7 - dalign
+ * D6 - rip
+ * D5 - in_abort_l
+ * D4 - Always 1
+ * D3 - Always 1
+ * D2 - Always 1
+ * D1 - Always 1
+ * D0 - Done bit
+ **/
+u32 fifo_icap_get_status(struct hwicap_drvdata *drvdata)
+{
+	u32 status = in_be32(drvdata->base_address + XHI_SR_OFFSET);
+	dev_dbg(drvdata->dev, "Getting status = %x\n", status);
+	return status;
+}
+
+/**
  * fifo_icap_busy - Return true if the ICAP is still processing a transaction.
  * @drvdata: a pointer to the drvdata.
  **/
 static inline u32 fifo_icap_busy(struct hwicap_drvdata *drvdata)
 {
 	u32 status = in_be32(drvdata->base_address + XHI_SR_OFFSET);
-	dev_dbg(drvdata->dev, "Getting status = %x\n", status);
 	return (status & XHI_SR_DONE_MASK) ? 0 : 1;
 }
 
diff --git a/drivers/char/xilinx_hwicap/fifo_icap.h b/drivers/char/xilinx_hwicap/fifo_icap.h
index 4d3068d..ffabd3b 100644
--- a/drivers/char/xilinx_hwicap/fifo_icap.h
+++ b/drivers/char/xilinx_hwicap/fifo_icap.h
@@ -56,6 +56,7 @@ int fifo_icap_set_configuration(
 		u32 *FrameBuffer,
 		u32 NumWords);
 
+u32 fifo_icap_get_status(struct hwicap_drvdata *drvdata);
 void fifo_icap_reset(struct hwicap_drvdata *drvdata);
 void fifo_icap_flush_fifo(struct hwicap_drvdata *drvdata);
 
diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
index 2284fa2..304727d 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
@@ -664,12 +664,14 @@ static int __devinit hwicap_setup(struct device *dev, int id,
 static struct hwicap_driver_config buffer_icap_config = {
 	.get_configuration = buffer_icap_get_configuration,
 	.set_configuration = buffer_icap_set_configuration,
+	.get_status = buffer_icap_get_status,
 	.reset = buffer_icap_reset,
 };
 
 static struct hwicap_driver_config fifo_icap_config = {
 	.get_configuration = fifo_icap_get_configuration,
 	.set_configuration = fifo_icap_set_configuration,
+	.get_status = fifo_icap_get_status,
 	.reset = fifo_icap_reset,
 };
 
diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.h b/drivers/char/xilinx_hwicap/xilinx_hwicap.h
index 405fee7..1f9c8b0 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.h
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.h
@@ -65,10 +65,27 @@ struct hwicap_drvdata {
 };
 
 struct hwicap_driver_config {
+	/* Read configuration data given by size into the data buffer.
+	   Return 0 if successful. */
 	int (*get_configuration)(struct hwicap_drvdata *drvdata, u32 *data,
 			u32 size);
+	/* Write configuration data given by size from the data buffer.
+	   Return 0 if successful. */
 	int (*set_configuration)(struct hwicap_drvdata *drvdata, u32 *data,
 			u32 size);
+	/* Get the status register, bit pattern given by:
+	 * D8 - 0 = configuration error
+	 * D7 - 1 = alignment found
+	 * D6 - 1 = readback in progress
+	 * D5 - 0 = abort in progress
+	 * D4 - Always 1
+	 * D3 - Always 1
+	 * D2 - Always 1
+	 * D1 - Always 1
+	 * D0 - 1 = operation completed
+	 */
+	u32 (*get_status)(struct hwicap_drvdata *drvdata);
+	/* Reset the hw */
 	void (*reset)(struct hwicap_drvdata *drvdata);
 };
 
@@ -163,6 +180,13 @@ struct config_registers {
 /* Constant to use for CRC check when CRC has been disabled */
 #define XHI_DISABLED_AUTO_CRC       0x0000DEFCUL
 
+/* Meanings of the bits returned by get_status */
+#define XHI_SR_CFGERR_N_MASK 0x00000100 /* Config Error Mask */
+#define XHI_SR_DALIGN_MASK 0x00000080 /* Data Alignment Mask */
+#define XHI_SR_RIP_MASK 0x00000040 /* Read back Mask */
+#define XHI_SR_IN_ABORT_N_MASK 0x00000020 /* Select Map Abort Mask */
+#define XHI_SR_DONE_MASK 0x00000001 /* Done bit Mask  */
+
 /**
  * hwicap_type_1_read - Generates a Type 1 read packet header.
  * @reg: is the address of the register to be read back.
-- 
1.5.3.4-dirty

^ permalink raw reply related

* [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
From: Anton Vorontsov @ 2008-03-17 17:52 UTC (permalink / raw)
  To: linuxppc-dev

MDIO-less PHYs should use CONFIG_FIXED_PHY driver and appropriate
fixed-link property in the device tree.

If not, ethernet will not work:
  e0024520:03 not found
  eth1: Could not attach to PHY
  IP-Config: Failed to open eth1

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 arch/powerpc/boot/dts/mpc8377_rdb.dts      |    8 +-------
 arch/powerpc/boot/dts/mpc8378_rdb.dts      |    8 +-------
 arch/powerpc/boot/dts/mpc8379_rdb.dts      |    8 +-------
 arch/powerpc/configs/mpc837x_rdb_defconfig |    2 +-
 4 files changed, 4 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index d2332fb..476f65a 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -164,12 +164,6 @@
 				reg = <0x2>;
 				device_type = "ethernet-phy";
 			};
-			phy3: ethernet-phy@3 {
-				interrupt-parent = <&ipic>;
-				interrupts = <18 0x8>;
-				reg = <0x3>;
-				device_type = "ethernet-phy";
-			};
 		};
 
 		enet0: ethernet@24000 {
@@ -195,7 +189,7 @@
 			interrupts = <35 0x8 36 0x8 37 0x8>;
 			phy-connection-type = "mii";
 			interrupt-parent = <&ipic>;
-			phy-handle = <&phy3>;
+			fixed-link = <1 1 1000 0 0>;
 		};
 
 		serial0: serial@4500 {
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 711f9a3..0e872a6 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -164,12 +164,6 @@
 				reg = <0x2>;
 				device_type = "ethernet-phy";
 			};
-			phy3: ethernet-phy@3 {
-				interrupt-parent = <&ipic>;
-				interrupts = <18 0x8>;
-				reg = <0x3>;
-				device_type = "ethernet-phy";
-			};
 		};
 
 		enet0: ethernet@24000 {
@@ -195,7 +189,7 @@
 			interrupts = <35 0x8 36 0x8 37 0x8>;
 			phy-connection-type = "mii";
 			interrupt-parent = <&ipic>;
-			phy-handle = <&phy3>;
+			fixed-link = <1 1 1000 0 0>;
 		};
 
 		serial0: serial@4500 {
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index c11ceb7..1eb8def 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -164,12 +164,6 @@
 				reg = <0x2>;
 				device_type = "ethernet-phy";
 			};
-			phy3: ethernet-phy@3 {
-				interrupt-parent = <&ipic>;
-				interrupts = <18 0x8>;
-				reg = <0x3>;
-				device_type = "ethernet-phy";
-			};
 		};
 
 		enet0: ethernet@24000 {
@@ -195,7 +189,7 @@
 			interrupts = <35 0x8 36 0x8 37 0x8>;
 			phy-connection-type = "mii";
 			interrupt-parent = <&ipic>;
-			phy-handle = <&phy3>;
+			fixed-link = <1 1 1000 0 0>;
 		};
 
 		serial0: serial@4500 {
diff --git a/arch/powerpc/configs/mpc837x_rdb_defconfig b/arch/powerpc/configs/mpc837x_rdb_defconfig
index 91d291e..c429a33 100644
--- a/arch/powerpc/configs/mpc837x_rdb_defconfig
+++ b/arch/powerpc/configs/mpc837x_rdb_defconfig
@@ -425,7 +425,7 @@ CONFIG_MARVELL_PHY=y
 # CONFIG_SMSC_PHY is not set
 # CONFIG_BROADCOM_PHY is not set
 # CONFIG_ICPLUS_PHY is not set
-# CONFIG_FIXED_PHY is not set
+CONFIG_FIXED_PHY=y
 # CONFIG_MDIO_BITBANG is not set
 CONFIG_NET_ETHERNET=y
 CONFIG_MII=y
-- 
1.5.2.2

^ permalink raw reply related

* Help getting USB keyboard active on MPC5200B
From: Edward Jubenville @ 2008-03-17 17:42 UTC (permalink / raw)
  To: Linuxppc-Embedded

I would appreciate a little help getting a USB keyboard working on a
MPC5200B-based Lite5200 clone board.

I'm working with the 2.4.25 kernel from ELDK 3.1.  I've tweaked my kernel
configuration parameters enough to have gotten a some USB functionality
working (memory stick, and mouse), but I cannot get any keyboard-related
device name to show up in the /dev tree.

I have USB debug enabled for verbose messages.  When I plug in a keyboard I
see:

  hub.c: new USB device 0-1.4, assigned address 5
  Manufacturer: Dell
  Product: Dell USB Keyboard
  usb.c: USB device 5 (vend/prod 0x413c/0x2003) is not claimed by any active
driver.
    Length              = 18
    DescriptorType      = 01
    USB version         = 1.10
    Vendor:Product      = 413c:2003
    MaxPacketSize0      = 8
    NumConfigurations   = 1
    Device version      = 3.01
    (remainder omitted)

I assume the message "... is not claimed by any driver" is the problem I
need to address.

I've compared my configuration parameters to those used in the Lite5200
CoralP configuration that supports USB, and I don't see any differences
related to the keyboard that might explain what's wrong.

When I diff my configuration to non-USB
arch/ppc/configs/icecube_5200_defconfig, these parameters stand out:

	CONFIG_INPUT=y
	CONFIG_INPUT_KEYBDEV=y
	CONFIG_INPUT_MOUSEDEV=y
	CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
	CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
	CONFIG_INPUT_EVDEV=y
	CONFIG_VT=y
	CONFIG_VT_CONSOLE=y
	CONFIG_MOUSE=y
	CONFIG_USB=y
	CONFIG_USB_DEBUG=y
	CONFIG_USB_DEVICEFS=y
	CONFIG_USB_OHCI_5xxx=y
	CONFIG_USB_OHCI_BIG_ENDIAN=y
	CONFIG_USB_OHCI=y
	CONFIG_USB_STORAGE=y
	CONFIG_USB_STORAGE_DEBUG=y
	CONFIG_USB_HID=y
	CONFIG_USB_HIDINPUT=y
	CONFIG_USB_HIDDEV=y

Can anyone point me in the right direction to get access to the USB
keyboard?  I'm using a serial system console and wish to keep it that way,
so the keyboard needs to be available an application input device.

Thanks,

Ed Jubenville

^ permalink raw reply

* Re: [PATCH v2] pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
From: Dan Williams @ 2008-03-17 18:46 UTC (permalink / raw)
  To: Olof Johansson
  Cc: linuxppc-dev, pasemi-linux, shannon.nelson, linux-kernel,
	hskinnemoen
In-Reply-To: <20080316213002.GA2589@lixom.net>

On Sun, Mar 16, 2008 at 2:30 PM, Olof Johansson <olof@lixom.net> wrote:
> pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
>
>  DMA copy offload driver for PA Semi PWRficient. It uses the
>
> platform-specific functions to allocate channels, etc.
>
>  Signed-off-by: Olof Johansson <olof@lixom.net>
>
>  ---
>
>  Changes since last post:
>
>  * Add DMA_INTERRUPT support and handling of the interrupt flag
>  * Fix interrupt handler for above and add tasklet
>  * Switch to spin_lock_bh() where possible
>  * Remove empty dependency_added() function since it's no longer
>   used in the framework.
>  * Fix bug in "ring full" estimation.
>

Hi Olof,

Looks good, makes me want to go back and cleanup iop-adma a bit.  A
few fyi's below, but no other review comments.

>  Note that this still needs to go on top of the powerpc.git tree due to the
>  pasemi_dma.h updates that this driver depends on. I suggest merging this
>  through pasemi.git->powerpc.git->linus with an Acked-by from the DMA guys.

Ok, it still may not compile in mainline until after 2.6.26-rc1 due to
additional dmaengine cleanups like the ack-to-flags change I posted
earlier.  Any better way to handle this?  Go through -mm?

>
>  -Olof
>

Acked-by: Dan Williams <dan.j.williams@intel.com>

> --- /dev/null
>  +++ b/drivers/dma/pasemi_dma.c
[..]
>  +static void pasemi_dma_clean(struct pasemi_dma_chan *chan)
>  +{
>  +       int old, new, i;
>
> +       struct pasemi_dma_desc *desc;
>  +       dma_async_tx_callback callback;
>  +
>  +restart:
>  +       spin_lock_bh(&chan->desc_lock);
>
> +
>  +       old = chan->next_to_clean;
>  +
>  +       new = *chan->chan.status & PAS_STATUS_PCNT_M;
>  +       new <<= 2;
>  +       new &= (RING_SZ-1);
>  +
>  +       if (old > new)
>  +               new += RING_SZ;
>  +
>  +       for (i = old; i < new; i += 4) {
>  +               if (unlikely(chan->chan.ring_virt[i & (RING_SZ-1)] & XCT_COPY_O))
>  +                       break;
>  +               desc = chan->ring_info[i & (RING_SZ-1)];
>  +
>  +               callback = desc->async_tx.callback;
>  +               if (callback) {
>  +                       /* Can't re-lock and just loop, since another cpu
>  +                        * might have came in here while we released the lock.
>  +                        * Instead, start all over again to re-read status words.
>  +                        */
>
> +                       chan->next_to_clean = i & (RING_SZ-1);
>  +                       spin_unlock_bh(&chan->desc_lock);
>  +                       callback(desc->async_tx.callback_param);
>  +                       goto restart;
>  +               }

Clients do not submit new operations in their callback routines so it
is "ok" to hold this lock over the callback.

Also, if your platform will need to support channel switching at some
point you can go ahead and add a call to async_tx_run_dependencies()
here.

^ permalink raw reply

* [PATCH] [POWERPC] Xilinx: Serial: Adding 8250 console support to OF serial
From: John Linn @ 2008-03-17 19:09 UTC (permalink / raw)
  To: linuxppc-dev, jwboyer; +Cc: John Linn

This change adds code to serial_of.c to support the 8250 console.
Initialization was added to get the UART data from the device tree
and setup the UART and console for the 8250.

The cmd line was not being used for the baud rate and is still not
being used as the speed for the uart is being pulled from the UART
properties in the device tree. The input clock frequency for the
UART must be specified in the device tree so the baud rate generator
can be setup.

<Signed-off-by: John Linn <john.linn@xilinx.com>

---

Please pull this patch for 2.6.26.
---
 drivers/serial/8250.c      |   20 ++++++--
 drivers/serial/of_serial.c |  128 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 144 insertions(+), 4 deletions(-)

diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index f94109c..7b32af1 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2366,7 +2366,7 @@ serial8250_type(struct uart_port *port)
 	return uart_config[type].name;
 }
 
-static struct uart_ops serial8250_pops = {
+struct uart_ops serial8250_pops = {
 	.tx_empty	= serial8250_tx_empty,
 	.set_mctrl	= serial8250_set_mctrl,
 	.get_mctrl	= serial8250_get_mctrl,
@@ -2519,10 +2519,13 @@ serial8250_console_write(struct console *co, const char *s, unsigned int count)
 static int __init serial8250_console_setup(struct console *co, char *options)
 {
 	struct uart_port *port;
+
+#ifndef CONFIG_SERIAL_OF_PLATFORM
 	int baud = 9600;
 	int bits = 8;
 	int parity = 'n';
 	int flow = 'n';
+#endif
 
 	/*
 	 * Check whether an invalid uart number has been specified, and
@@ -2535,10 +2538,13 @@ static int __init serial8250_console_setup(struct console *co, char *options)
 	if (!port->iobase && !port->membase)
 		return -ENODEV;
 
+#ifndef CONFIG_SERIAL_OF_PLATFORM
 	if (options)
 		uart_parse_options(options, &baud, &parity, &bits, &flow);
-
 	return uart_set_options(port, co, baud, parity, bits, flow);
+#else
+	return 0;
+#endif
 }
 
 static int serial8250_console_early_setup(void)
@@ -2547,7 +2553,7 @@ static int serial8250_console_early_setup(void)
 }
 
 static struct uart_driver serial8250_reg;
-static struct console serial8250_console = {
+struct console serial8250_console = {
 	.name		= "ttyS",
 	.write		= serial8250_console_write,
 	.device		= uart_console_device,
@@ -2558,13 +2564,19 @@ static struct console serial8250_console = {
 	.data		= &serial8250_reg,
 };
 
-static int __init serial8250_console_init(void)
+int __init serial8250_console_init(void)
 {
 	serial8250_isa_init_ports();
 	register_console(&serial8250_console);
 	return 0;
 }
+
+/* when OF is being used with the 8250 console, the OF hooks in the 
+   8250 console
+*/
+#if defined(CONFIG_SERIAL_8250_CONSOLE) && !defined(CONFIG_SERIAL_OF_PLATFORM)
 console_initcall(serial8250_console_init);
+#endif
 
 int serial8250_find_port(struct uart_port *p)
 {
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..eed245a 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -13,9 +13,11 @@
 #include <linux/module.h>
 #include <linux/serial_core.h>
 #include <linux/serial_8250.h>
+#include <linux/console.h>
 
 #include <asm/of_platform.h>
 #include <asm/prom.h>
+#include <asm/io.h>
 
 struct of_serial_info {
 	int type;
@@ -158,6 +160,132 @@ static void __exit of_platform_serial_exit(void)
 };
 module_exit(of_platform_serial_exit);
 
+#if defined(CONFIG_SERIAL_8250_CONSOLE)
+
+/* when an 8250 console is being used and OF, the OF needs to
+   setup the uart before the 8250 console initializes
+*/
+extern struct console serial8250_console;
+extern int serial8250_console_init(void);
+extern int early_serial_console_setup(struct uart_port *);
+extern struct uart_ops serial8250_pops;
+
+static struct uart_port of_uart_port;
+
+static struct of_device_id __devinit uart_of_match[] = {
+	{ .type = "serial", .compatible = "ns16550", },
+	{},
+};
+
+static unsigned int *spd;
+
+/*
+ * Setup the uart based on OF properties
+ */
+static int __init uart_of_setup(struct device_node *np,
+					struct uart_port *port)
+{
+	struct resource resource;
+	const unsigned int *clk, *regshift;
+	int ret;
+
+	memset(port, 0, sizeof *port);
+	spd = of_get_property(np, "current-speed", NULL);
+	regshift = of_get_property(np, "reg-shift", NULL);
+	clk = of_get_property(np, "clock-frequency", NULL);
+	if (!clk) {
+		return -ENODEV;
+	}
+
+	ret = of_address_to_resource(np, 0, &resource);
+	if (ret) {
+		return ret;
+	}
+
+	spin_lock_init(&port->lock);
+	port->irq = irq_of_parse_and_map(np, 0);
+	port->iotype = UPIO_MEM;
+	port->type = PORT_16550;
+	port->uartclk = *clk;
+	port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
+		| UPF_FIXED_PORT;
+	if (!spd)
+		*spd = 9600;
+		
+	port->custom_divisor = *clk / (16 * (*spd));
+
+	if (regshift) {
+		port->regshift = *regshift;
+		port->mapbase = resource.start + ((1 << *regshift) - 1);
+	} else {
+		port->mapbase = resource.start;
+	}
+	return 0;
+}
+
+static struct device_node __init *console_of_find_device(int id)
+{
+	struct device_node *np;
+        const struct of_device_id *matches = uart_of_match;
+
+	while (matches->compatible[0]) {
+		for_each_compatible_node(np, NULL, matches->compatible) {
+			if (!of_match_node(matches, np))
+				continue;
+
+                        of_node_put(np);
+                        return np;
+		}
+		matches++;
+	}
+	return 0;
+}
+
+static int __init console_setup(struct console *co)
+{
+	struct device_node *np;
+	int bits = 8;
+	int parity = 'n';
+	int flow = 'n';
+
+	/* Find a matching uart port in the device tree */
+	np = console_of_find_device(co->index);
+	if (!np)
+		return -ENODEV;
+		
+	if (uart_of_setup(np, &of_uart_port))
+		return -ENODEV;
+
+	/* registers mapped yet? */
+	if (!of_uart_port.membase) {
+		of_uart_port.membase = ioremap(of_uart_port.mapbase, 64);
+		if (!of_uart_port.membase)
+			return -ENODEV;
+	}
+
+	of_uart_port.ops = &serial8250_pops;
+	uart_set_options(&of_uart_port, co, *spd, parity, bits, flow);
+
+	return 0;
+}
+
+/* This function sets up the 8250 console by getting the OF data at 
+   console init time and then setting up the 8250 uart and console. 
+   This solves the problem of the OF uart not being setup in time 
+   for the 8250 console to use it.
+*/
+static int __init of_console_init(void)
+{
+	if (!console_setup(&serial8250_console)) {
+		early_serial_setup(&of_uart_port);	
+		serial8250_console_init();	
+	}
+	return 0;
+}
+
+console_initcall(of_console_init);
+#endif
+
 MODULE_AUTHOR("Arnd Bergmann <arnd@arndb.de>");
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Serial Port driver for Open Firmware platform devices");
-- 
1.5.2.1

^ permalink raw reply related

* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-03-17 19:19 UTC (permalink / raw)
  To: Bartlomiej Sieka; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <47DE94F4.90804@semihalf.com>

On Mon, Mar 17, 2008 at 9:57 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
> Grant Likely wrote:
>  > Paul, here is a bug fix that needs to go in for 2.6.25.
>
>  Hi Grant,
>
>  What is the status of the various MPC5200-related patches (support for
>  TQM5200, CM5200 and Motion-PRO boards, few drivers, etc) posted some
>  time ago by Marian Balakowicz? There's been some comments to the patches
>  on the list, which were addressed and no further discussion occurred, so
>  we were hoping that the changes would go upstream (in 2.6.25). I can see
>  that the .dts files for those boards are in the mainline already, but I
>  see no trace of for example _defconfig files -- could you shed some
>  light on this?

Yes, the separate dts files have been dropped in preference for a
single mpc5200_defconfig for all 5200 boards.

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* powerpc: cuImage.* creation error
From: Adrian Bunk @ 2008-03-17 19:36 UTC (permalink / raw)
  To: Kumar Gala, Grant Likely, Paul Mackerras, Paul Gortmaker
  Cc: linuxppc-dev, linux-kernel

When building all powerpc defconfigs in 2.6.25-rc6 exactly three of 
them fail to build, and all with similar problems:


mpc85xx_defconfig:

<--  snip  -->

...
  WRAP    arch/powerpc/boot/cuImage.tqm8540
DTC: dts->dtb  on file "/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/tqm8540.dts"
powerpc64-linux-ld: arch/powerpc/boot/cuboot-tqm8540.o: No such file: No such file or directory
make[2]: *** [arch/powerpc/boot/cuImage.tqm8540] Error 1

<--  snip  -->


sbc8548_defconfig:

<--  snip  -->

...
Entry Point:  0x00000000
make[2]: *** No rule to make target `arch/powerpc/boot/cuImage.tqm8548', needed by `arch/powerpc/boot/zImage'.  Stop.

<--  snip  -->


tqm8540_defconfig:

<--  snip  -->

...
  WRAP    arch/powerpc/boot/cuImage.tqm8540
DTC: dts->dtb  on file "/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/tqm8540.dts"
powerpc64-linux-ld: arch/powerpc/boot/cuboot-tqm8540.o: No such file: No such file or directory
make[2]: *** [arch/powerpc/boot/cuImage.tqm8540] Error 1

<--  snip  -->


Is this a problem on my side or is there a bug that should be fixed?


TIA
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

^ 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