[EMAIL PROTECTED];[EMAIL PROTECTED];[EMAIL PROTECTED]
hi, all I bought a SMC1500 stepper motor card. And it can connect with host through parallel port. My target board is PowerPC 440, which hasn't parrallel port. So I bought a PCI to Parallel line for SMC1500. But when I run the stepper motor, I find it's not stable. I doubt there are somthing wrong with my PCI to Parallel line. So I beg somebody can tell me where I can bought the appropriate conversion line from PCI to parallel, and does somebody give me some idea about how to control my stepper motor through PowerPC 440? thx all Best Regards! Buroc -- Add: Tianshui South Road 222, Lanzhou, P.R.China Tel: +86-931-8912025 Zip Code: 73 URL: oss.lzu.edu.cn Email: [EMAIL PROTECTED], [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-usb-devel] [PATCH 1/5] USB: Make usb_hcd_irq work for multi-role USB controllers w/ shared irq
On Fri, 23 Nov 2007 21:10:39 -0800 Greg KH [EMAIL PROTECTED] wrote: On Fri, Nov 23, 2007 at 05:24:31PM -0700, Grant Likely wrote: From: Peter Korsgaard [EMAIL PROTECTED] Some multi-role (host/peripheral) USB controllers use a shared interrupt line for all parts of the chip. Export usb_hcd_irq so drivers can call it from their interrupt handler instead of duplicating code. Drivers pass an irqnum of 0 to usb_add_hcd to signal that the interrupt handler shouldn't be registerred by the core. What about for platforms where irq 0 is a valid irq? There are no such platforms. Linus made that absolutely clear every time this came up before 0 - No IRQ A platform with a physical or bus IRQ of 0 needs to remap it to a different constant. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
Hi Vitaly, + printk(KERN_ERR %s(): Not able to issue CPM command\n, + __FUNCTION__); + return -EIO; Do these need to be protected with a spin lock? Even that might be not enough - we may have simultaneous call of this func in non-smp case... I was thinking of some kind of refcount, so one that is going to issue CPM command, must do say pq_cpmp_get() and another driver won't be able to mangle with cpcr while it's not done with previous request. Yet I am not telling it was better the way it used to be - this approach looks okay but needs some efforts to defend against deadlocks while we are at it Wouldn't spin_lock_irqsave() prevent a deadlock? Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] PowerPC 74xx: Katana Qp base support
On Friday 16 November 2007, Andrei Dolnikov wrote:
+static int __init katanaqp_is_monarch(void)
+{
+ return !(in_8((volatile char *)(cpld_base + KATANAQP_CPLD_PSR))
+ KATANAQP_CPLD_PSR_PMCM);
+}
The pointer here needs to be __iomem, not volatile. Same in other places.
Please use 'sparse' to check your code for bugs like this.
+
+static void __init katanaqp_setup_arch(void)
+{
+ struct device_node *cpld;
+ const unsigned int *reg;
+
+ /*
+ * ioremap cpld registers in case they are later
+ * needed by katanaqp_reset_board().
+ */
+ cpld = of_find_node_by_path(/[EMAIL PROTECTED]/[EMAIL PROTECTED]);
It doesn't sounds good to hardcode the path for this device.
Instead, it would be much better to look for the 'compatible' property
here.
+static int __init katanaqp_of_init(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, cfi-flash);
+ if (np)
+ of_platform_device_create(np, of-flash, NULL);
+
+ return 0;
+}
+
+device_initcall(katanaqp_of_init);
This should be done automatically using of_platform_bus_probe().
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Review request: Cypress c67x00 OTG controller
On Friday 23 November 2007, Grant Likely wrote: This patch series is based on the c67x00 work done by Peter Korsgaard and posted back in April this year. What's changed since that version? Were the comments sent at that time addressed? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCHv2] powerpc: Move CPM command handling into the cpm drivers
On Saturday 24 November 2007, Jochen Friedrich wrote:
This patch moves the CPM command handling into commproc.c
for CPM1 and cpm2_common.c. This is yet another preparation
to get rid of drivers accessing the CPM via the global cpmp.
good stuff, just a little nitpicking below:
+DEFINE_SPINLOCK(cmd_lock);
This should probably be a static variable. The name is too generic
for a global identifier. If every use of the command register
goes through the cpm_command function, you could even make it
a static variable in that function.
+int cpm_command(u32 command, u8 opcode)
+{
+ int i;
+ unsigned long flags;
+
+ if (command 0xff0f)
+ return -EINVAL;
+
+ spin_lock_irqsave(cmd_lock, flags);
+
+ out_be16(cpmp-cp_cpcr, command | CPM_CR_FLG | (opcode 8));
+ for (i = 0; i MAX_CR_CMD_LOOPS; i++)
+ if ((in_be16(cpmp-cp_cpcr) CPM_CR_FLG) == 0) {
+ spin_unlock_irqrestore(cmd_lock, flags);
+ return 0;
+ }
Error handling in here is nicer if you do a goto that jumps to the
unlock below. If the code ever gets more complex, this makes it easier
to check if it's correct regarding locking.
+ printk(KERN_ERR %s(): Not able to issue CPM command\n, __FUNCTION__);
+ spin_unlock_irqrestore(cmd_lock, flags);
+ return -EIO;
+}
+EXPORT_SYMBOL(cpm_command);
Why not EXPORT_SYMBOL_GPL?
+DEFINE_SPINLOCK(cmd_lock);
see above
+
+#define MAX_CR_CMD_LOOPS1
+
+int cpm_command(u32 command, u8 opcode)
+{
+ int i;
+ unsigned long flags;
+
+ spin_lock_irqsave(cmd_lock, flags);
+
+ out_be32(cpmp-cp_cpcr, command | opcode | CPM_CR_FLG);
+ for (i = 0; i MAX_CR_CMD_LOOPS; i++)
+ if ((in_be32(cpmp-cp_cpcr) CPM_CR_FLG) == 0) {
+ spin_unlock_irqrestore(cmd_lock, flags);
+ return 0;
+ }
+
+ printk(KERN_ERR %s(): Not able to issue CPM command\n, __FUNCTION__);
+ spin_unlock_irqrestore(cmd_lock, flags);
+ return -EIO;
+}
+EXPORT_SYMBOL(cpm_command);
see above
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH 0/3] OF-platform PATA driver
On Friday 23 November 2007, Anton Vorontsov wrote: Here is the PATA Platform driver using OF infrastructure. Mostly it's just a wrapper around a bit modified pata_platform driver. Thanks a lot for doing this. Patches 2/3 are what I tried to get people to do for some time now but was too lazy to do myself. As a further thought, do the drivers now still need to be pata specific, or should the OF part be called ata_of_platform instead and also be used for sata devices? Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce pata node, make use pata_of_platform driver
On Friday 23 November 2007, Anton Vorontsov wrote:
+static struct of_device_id mpc834x_ids[] = {
+ { .compatible = pata-platform, },
+ {},
+};
+
+static int __init mpc834x_declare_of_platform_devices(void)
+{
+ if (!machine_is(mpc834x_itx))
+ return 0;
+
+ of_platform_bus_probe(NULL, mpc834x_ids, NULL);
+
+ return 0;
+}
+device_initcall(mpc834x_declare_of_platform_devices);
This is not really how of_platform_bus_probe was meant to be used.
Instead of listing the device you want to probe, you should list
all buses that potentially contain a device that you are probing.
Normally, an ata controller is not a top-level device but instead
the child of an SOC bus device, and then you just probe all
SOC devices, which means their children get added to the device
tree.
In your case, that would probably mean that you have to another
entry in the ranges of the soc8349 node, or add a second soc
node that has the 0xf000 ranges, depending on the actual layout
of the SOC.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] IB/ehca: Fix static rate regression
thanks, applied. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] PowerPC 74xx: Katana Qp base support
On Sat, 2007-11-24 at 19:51 +0100, Arnd Bergmann wrote: This should be done automatically using of_platform_bus_probe(). Not necessarily. of_platform_bus_probe() is an optional facility that is common used by SoCs that have lots of otherwise non-probable on chip devices, but for platforms with more classic setups, it's totally acceptable to have the platform code explicitely register only those devices it wants exposed. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Access to PCI Expansion ROMs on PPC
Following up from initial conversation with benh in #ppc64, I did a bit of testing (and then a bit more). Two PCIe cards for my testing: a) sata_sil24 eSATA (x86 BIOS) b) ATI X700 graphics (x86 BIOS) I put the card into an amd64 box, found the relevant 'rom' node ($ROM) under /sys/device/pci*, and dumped it as follows: # echo 1$ROM # cat $ROM /tmp/dump # echo 0$ROM On amd64, this produced the ROM for the cards fine (contained recognizable strings). I then repeated the same on my G5 (PM11,2), while the $ROM files have a non-zero size in sysfs (that corresponds to the size shown by lspci -vv), reading them always results in a 0-byte output. Is the PPC kernel broken? Does something in the PPC architecture forbid this? Instructions to muck with PCI code welcome. This was under 2.6.24_rc3-git1, kernel .config available if needed. Why am I trying to access the PCI ROM? To make my newer X1900 card work under at least one of the newer (ati,radeonhd,avivo) drivers, that all try to access the ATI AtomBIOS for varying data. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpHxeypjr2ZP.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
Here's what I've gotten so far:
Hard_Ethernet_MAC: [EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
[EMAIL PROTECTED] {
compatible = xlnx,xps-ll-temac-1.00.a,
xlnx,xps-ll-temac;
interrupt-parent = xps_intc_0;
interrupts = 3 0 ;
llink-connected = PIM3;
reg = 81c0 40 ;
xlnx,bus2core-clk-ratio = 1;
xlnx,phy-type = 1;
xlnx,phyaddr = 1;
xlnx,rxcsum = 0;
xlnx,rxfifo = 1000;
xlnx,temac-type = 0;
xlnx,txcsum = 0;
xlnx,txfifo = 1000;
} ;
} ;
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
compatible = xlnx,mpmc-3.00.a, xlnx,mpmc;
PIM3: [EMAIL PROTECTED] {
compatible = xlnx,ll-dma-1.00a, xlnx,ll-dma;
interrupt-parent = xps_intc_0;
interrupts = 1 0 0 0 ;
reg = 84600180 80 ;
} ;
} ;
DDR2_SDRAM: [EMAIL PROTECTED] {
device_type = memory;
reg = 9000 1000 ;
} ;
So: the mpmc generates a 'memory' node, corresponding to it's memory interface.
It also gets a separate entry which contains the (optional, not present in
this example) slave management interface (for ECC and performance information),
and any sdma ports. In this case, this node is [EMAIL PROTECTED], because
there is no management interface. If a management interface was present, then
it would be @ the management address.
The mpmc gets a compatible string that describes its management interface.
The sdma port has information about the tx and rx interrupts and the slave
management interface. Note that the slave management interface has the correct
baseaddress for port3, generated from the base SDMA_CTRL_ address from the mpmc
+ the port 3 offset. Note that sdma has an artificial compatible name. I'm
not sure whether the ll_dma driver can be easily convinced to bind to this, or
whether the ll_temac driver will just traverse the device tree and then do a
match against this.
The temac works similarly, although the temac itself doesn't have a slave
interface, so no compatible node for it. The sub nodes get the compatible
string for the ll_temac driver. In this case, there is only one temac port
active. Some of the parameters are specific to port 0, in which case the
parameter names (e.g. phyaddr) are generated by stripping off the complete
C_TEMAC0 prefix. Other parameters (e.g. phy-type) are common to both sub
nodes, but are duplicated to make it easier for the driver to get the
information out. At runtime, the driver has to follow the llink-connected path
to find what it is connected to, and use the dma code, or the fifo code.
the xps-ll-fifo structure is a bit simpler, with llink-connected pointing to
the fifo, which looks like a 'normal' peripheral.
Points for comment:
1) I don't like the PIM3 label, which is artificial (i.e. it doesn't
correspond to a name in the .mhs) and not guaranteed to be unique. However, in
the BSP generator it seems awkward to generate path references easily in a
single pass. What I'd might prefer is:
DDR2_SDRAM: [EMAIL PROTECTED] {
[EMAIL PROTECTED] {
and refer to the sdma port using something like DDR2_SDRAM/[EMAIL
PROTECTED], but I don't think you can do that in dtc?
2) Not sure whether this is really simpler than just having a 'simple' node
with both temacs and letting the driver sort everything out. In particular,
I'm concerned about maintaining a bunch of semantic information about the
ll_temac driver outside of the driver itself.
3) All of this is very different in structure from the way that the xparameters
are organized. The ll_temac BSP code copies the xparameters out of the MPMC
and they are simply other parameters of the ll_temac driver. Although the
above structure better represents the actual system, there is another
organization for people to be confused about.
Steve
-Original Message-
From: [EMAIL PROTECTED] on behalf of Stephen Neuendorffer
Sent: Tue 11/20/2007 11:44 AM
To: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; Grant Likely; Michal Simek
Subject: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
I've updated some code from Michel Simek to generate Flat Device Trees
from Xilinx EDK projects.
