Re: [RFC] arch/powerpc: Remove duplicate/redundant Altivec entries
On Tue, Sep 07, 2010 at 01:56:55PM -0500, Matthew McClintock wrote: > In lieu of having multiple similiar lines, we can just have one > generic cpu-as line for CONFIG_ALTIVEC > > --- > Was hoping to get comments about this change and if anyone sees any potential > problems? I have a memory that we can get some altivec instructions even with CONFIG_ALTIVEC = n, though presumably they never get executed. We would have to check that before applying your patch. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kexec on ppc64
> I'm trying to determine how kexec'ing works on 64 bit powerpc. When > allocating a region for the kexec'ed kernel is it ever the same as the > currently running kernel or do you always boot the kexec'ed kernel > from a different memory region? I understand that a crash kernel will > be in a different region, however I was hoping to confirm the behavior > for a normal "kexec -e". The kernel will be loaded at a non zero address, but it will copy itself to zero before it starts running. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] sdhci: Move real work out of an atomic context
On Wed, 14 Jul 2010 17:07:28 +0400 Anton Vorontsov wrote: > Hi all, > > Currently the sdhci driver does everything in the atomic context. > And what is worse, PIO transfers are made from the IRQ handler. > > This causes huge latencies (up to 120 ms). On some P2020 SOCs, > DMA and card detection is broken, which means that kernel polls > for the card via PIO transfers every second. Needless to say > that this is quite bad. > > So, this patch set reworks sdhci code to avoid atomic context, > almost completely. We only do two device memory operations > in the atomic context, and all the rest is threaded. > > I noticed no throughput drop neither with PIO transfers nor > with DMA (tested on MPC8569E CPU), while latencies should be > greatly improved. > This patchset isn't causing any problems yet, but may do so in the future and will impact the validity of any testing. It seems to be kind of stuck. Should I drop it all? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: drivers/ata/sata_dwc_460ex.c fails to build
Dear Rupjyoti Sarmah, In message <5205dc59ca0e0fd65e50d80eeff60...@mail.gmail.com> you wrote: > > The current mainline 2.6.36-rc3 does not report any error while building > the SATA driver. It reports a lot of warnings, though: -> git describe v2.6.36-rc3 In file included from drivers/ata/sata_dwc_460ex.c:38: drivers/ata/libata.h:31:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c:44:1: warning: "DRV_VERSION" redefined drivers/ata/libata.h:32:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_exec_command_by_tag': drivers/ata/sata_dwc_460ex.c:1356: warning: passing argument 1 of 'ata_get_cmd_descript' makes integer from pointer without a cast drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_qc_issue': drivers/ata/sata_dwc_460ex.c:1476: warning: 'err' is used uninitialized in this function drivers/ata/sata_dwc_460ex.c:1465: note: 'err' was declared here drivers/scsi/constants.c: In function 'scsi_print_sense': drivers/scsi/constants.c:1407: warning: zero-length printf format string drivers/scsi/constants.c:1413: warning: zero-length printf format string drivers/scsi/constants.c: In function 'scsi_print_result': drivers/scsi/constants.c:1456: warning: zero-length printf format string drivers/scsi/sd.c: In function 'sd_print_sense_hdr': drivers/scsi/sd.c:2628: warning: zero-length printf format string drivers/scsi/sd.c:2630: warning: zero-length printf format string drivers/scsi/sd.c: In function 'sd_print_result': drivers/scsi/sd.c:2636: warning: zero-length printf format string And the ``'err' is used uninitialized'' warning is indeed a valid one. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What is mind? No matter. What is matter? Never mind. -- Thomas Hewitt Key, 1799-1875 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mpc8308_p1m: support for MPC8308 P1M board
On Tue, 7 Sep 2010 12:09:03 +0200
Ilya Yanok wrote:
> + compatible = "mpc8308_p1m";
This needs a vendor prefix.
> + i...@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cell-index = <0>;
> + compatible = "fsl-i2c";
> + reg = <0x3000 0x100>;
> + interrupts = <14 0x8>;
> + interrupt-parent = <&ipic>;
> + dfsrr;
> + f...@50 {
> + compatible = "ramtron,24c64";
> + reg = <0x50>;
> + };
> + };
> +
> + i...@3100 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cell-index = <0>;
> + compatible = "fsl-i2c";
> + reg = <0x3100 0x100>;
> + interrupts = <15 0x8>;
> + interrupt-parent = <&ipic>;
> + dfsrr;
> + p...@28 {
> + compatible = "maxim,ds1050";
> + reg = <0x28>;
> + };
> + sens...@48 {
> + compatible = "maxim,max6625";
> + reg = <0x48>;
> + };
> + sens...@49 {
> + compatible = "maxim,max6625";
> + reg = <0x49>;
> + };
> + sens...@4b {
> + compatible = "maxim,max6625";
> + reg = <0x4b>;
> + };
> + };
Why "i...@3000" and "i...@3100" rather than "i...@3000" and "i...@3100"?
Likewise for the sensor nodes.
Drop cell-index; it's not part of the fsl i2c binding (plus, they
probably shouldn't both be zero...).
> + enet0: ether...@24000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x24000 0x1000>;
> +
> + cell-index = <0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <0x24000 0x1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <32 0x8 33 0x8 34 0x8>;
> + interrupt-parent = <&ipic>;
> + phy-handle = < &phy1 >;
> + fsl,magic-packet;
8308 does not have magic packet.
> + g...@c00 {
> + #gpio-cells = <2>;
> + device_type = "gpio";
> + compatible = "fsl,mpc8308-gpio", "fsl,mpc8349-gpio";
> + reg = <0xc00 0x18>;
> + interrupts = <74 0x8>;
> + interrupt-parent = <&ipic>;
> + gpio-controller;
> + };
Drop device_type.
> + pci0: p...@e0009000 {
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + device_type = "pci";
> + compatible = "fsl,mpc8308-pcie", "fsl,mpc8314-pcie";
> + reg = <0xe0009000 0x1000
> + 0xb000 0x0100>;
> + ranges = <0x0200 0 0xa000 0xa000 0 0x1000
> + 0x0100 0 0x 0xb100 0 0x0080>;
> + bus-range = <0 0>;
> + interrupt-map-mask = <0xf800 0 0 7>;
> + interrupt-map = <0 0 0 1 &ipic 1 8
> + 0 0 0 2 &ipic 1 8
> + 0 0 0 3 &ipic 1 8
> + 0 0 0 4 &ipic 1 8>;
Should interrupt-map-mask be <0 0 0 7>? Or possibly <0 0 0 0> with
just one map entry?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Small issue at init with spi_mpc8xxx.c with CPM1
On Tue, 7 Sep 2010 11:17:17 +0200 LEROY Christophe wrote: > > Dear Kumar, > > I have a small issue in the init of spi_mpc8xxx.c with MPC866 (CPM1) > > Unlike cpm_uart that maps the parameter ram directly using > of_iomap(np,1), spi_mpc8xxx.c uses cpm_muram_alloc_fixed(). > > This has two impacts in the .dts file: > * The driver must be declared with pram at 1d80 instead of 3d80 whereas > it is not a child of mu...@2000 but a child of c...@9c0 > * mu...@2000/d...@0 must be declared with reg = <0x0 0x2000> whereas > is should be reg=<0x0 0x1c00> to avoid cpm_muram_alloc() to allocate > space from parameters ram. > > Maybe I misunderstood something ? Don't make the device tree lie, fix the driver instead. The allocator should not be given any chunks of muram that are dedicated to a fixed purpose -- it might hand it out to something else before you reserve it. I don't think that cpm_muram_alloc_fixed() has any legitimate use at all. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-2.6.36-rc3 bug report
Hello there, I just tried out cppcheck-1.44 on the linux-2.6.36-rc3 source code. It said Checking arch/powerpc/kernel/ppc970-pmu.c... [arch/powerpc/kernel/ppc970-pmu.c:171]: (style) Redundant assignment of "mask" in switch The source code is case PM_VPU: mask = 0x4c; /* byte 0 bits 2,3,6 */ case PM_LSU0: /* byte 2 bits 0,2,3,4,6; all of byte 1 */ mask = 0x085dff00; case PM_LSU1L: mask = 0x50 << 24; /* byte 3 bits 4,6 */ break; It looks to me like a missing break on the first and second cases. Suggest code rework. Regards David Binderman ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC] arch/powerpc: Remove duplicate/redundant Altivec entries
In lieu of having multiple similiar lines, we can just have one generic cpu-as line for CONFIG_ALTIVEC --- Was hoping to get comments about this change and if anyone sees any potential problems? arch/powerpc/Makefile |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index e07d499..4e88b42 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -131,8 +131,7 @@ KBUILD_CFLAGS += -mno-sched-epilog endif cpu-as-$(CONFIG_4xx) += -Wa,-m405 -cpu-as-$(CONFIG_6xx) += -Wa,-maltivec -cpu-as-$(CONFIG_POWER4)+= -Wa,-maltivec +cpu-as-$(CONFIG_ALTIVEC) += -Wa,-maltivec cpu-as-$(CONFIG_E500) += -Wa,-me500 cpu-as-$(CONFIG_E200) += -Wa,-me200 -- 1.6.6.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
kexec on ppc64
All, I'm trying to determine how kexec'ing works on 64 bit powerpc. When allocating a region for the kexec'ed kernel is it ever the same as the currently running kernel or do you always boot the kexec'ed kernel from a different memory region? I understand that a crash kernel will be in a different region, however I was hoping to confirm the behavior for a normal "kexec -e". Thanks, Matthew ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] mpc8308_p1m: support for MPC8308 P1M board
This patch adds support for MPC8308 P1M board.
Supported devices:
DUART
Dual Ethernet
NOR flash
Both I2C controllers
USB in peripheral mode
PCI Express
Signed-off-by: Ilya Yanok
---
arch/powerpc/boot/dts/mpc8308_p1m.dts | 340 +
arch/powerpc/platforms/83xx/Kconfig |4 +-
arch/powerpc/platforms/83xx/mpc830x_rdb.c |3 +-
3 files changed, 344 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8308_p1m.dts
diff --git a/arch/powerpc/boot/dts/mpc8308_p1m.dts
b/arch/powerpc/boot/dts/mpc8308_p1m.dts
new file mode 100644
index 000..159a0d0
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8308_p1m.dts
@@ -0,0 +1,340 @@
+/*
+ * mpc8308_p1m Device Tree Source
+ *
+ * Copyright 2010 Ilya Yanok, Emcraft Systems, ya...@emcraft.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ compatible = "mpc8308_p1m";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ serial0 = &serial0;
+ serial1 = &serial1;
+ pci0 = &pci0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8...@0 {
+ device_type = "cpu";
+ reg = <0x0>;
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ d-cache-size = <16384>;
+ i-cache-size = <16384>;
+ timebase-frequency = <0>; // from bootloader
+ bus-frequency = <0>;// from bootloader
+ clock-frequency = <0>; // from bootloader
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x0800>; // 128MB at 0
+ };
+
+ local...@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8315-elbc", "fsl,elbc", "simple-bus";
+ reg = <0xe0005000 0x1000>;
+ interrupts = <77 0x8>;
+ interrupt-parent = <&ipic>;
+
+ ranges = <0x0 0x0 0xfc00 0x0400
+ 0x1 0x0 0xfbff 0x8000
+ 0x2 0x0 0xfbff8000 0x8000>;
+
+ fl...@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x400>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ u-b...@0 {
+ reg = <0x0 0x6>;
+ read-only;
+ };
+ e...@6 {
+ reg = <0x6 0x2>;
+ };
+ e...@8 {
+ reg = <0x8 0x2>;
+ };
+ ker...@a {
+ reg = <0xa 0x20>;
+ };
+ d...@2a {
+ reg = <0x2a 0x2>;
+ };
+ ramd...@2c {
+ reg = <0x2c 0x64>;
+ };
+ u...@70 {
+ reg = <0x70 0x390>;
+ };
+ };
+
+ c...@1,0 {
+ compatible = "nxp,sja1000";
+ reg = <0x1 0x0 0x80>;
+ interrupts = <18 0x8>;
+ interrups-parent = <&ipic>;
+ };
+
+ c...@2,0 {
+ compatible = "cpld";
+ reg = <0x2 0x0 0x8>;
+ interrupts = <48 0x8>;
+ interrups-parent = <&ipic>;
+ };
+ };
+
+ i...@e000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,mpc8308-immr", "simple-bus";
+ ranges = <0 0xe000 0x0010>;
+ reg = <0xe000 0x0200>;
+ bus-frequency = <0>;
+
+ i...@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x3000 0x100>;
+ int
Re: pci_request_regions() failure
Ravi Gupta wrote:
> Hi Tiejun,
>
> Thanks for the reply. I am sending you the updated dmesg O/P(after enabling
> CONFIG_PCI_DEBUG) as attachment as well as at the end of the mail.
>
> As far as driver is concern, I am trying the pci_skel driver available as
> example with LDD book with slight modifications.
Current LDD 3rd may be old for 2.6.35 on some sections :)
>
> Driver Code:
>
> #include
> #include
> #include
>
> /* PCI IDs */
> static struct pci_device_id ids[] = {
> { PCI_DEVICE(0x1204, 0xe250) },
> { 0, }
> };
> MODULE_DEVICE_TABLE(pci, ids);
>
> static unsigned char skel_get_revision(struct pci_dev *dev)
> {
> u8 revision;
>
> pci_read_config_byte(dev, PCI_REVISION_ID, &revision);
> return revision;
> }
>
> static u16 skel_get_vendor_id(struct pci_dev *dev)
> {
> u16 vendor_id;
>
> pci_read_config_word(dev, PCI_VENDOR_ID, &vendor_id);
> return vendor_id;
> }
>
> static u16 skel_get_device_id(struct pci_dev *dev)
> {
> u16 device_id;
>
> pci_read_config_word(dev, PCI_DEVICE_ID, &device_id);
> return device_id;
> }
>
> static int probe(struct pci_dev *dev, const struct pci_device_id *id)
> {
> /* Do probing type stuff here.
>* Like calling request_region();
>*/
> int err, i;
> printk(KERN_ALERT "PCI driver: Probe function\n");
>
> /*
>* Enable the bus-master bit values.
>* Some PCI BIOSes fail to set the master-enable bit.
>* Some demos support being an initiator, so need bus master ability.
>*/
> err = pci_request_regions(dev, "pci_skell");
> if (err) {
> printk(KERN_ERR "request region failed :%d\n", err);
> return err;
> }
>
> pci_set_master(dev);
>
> if ((err = pci_enable_device(dev)) != 0) {
> printk(KERN_ERR "Unable to Enable PCI device:%d\n", err);
> return err;
> }
>
> printk(KERN_ALERT "PCI driver Vendor ID = %x\n", skel_get_vendor_id(dev));
> printk(KERN_ALERT "PCI driver Device ID = %x\n", skel_get_device_id(dev));
> printk(KERN_ALERT "PCI driver Revision = %d\n", skel_get_revision(dev));
> return 0;
> }
>
> static void remove(struct pci_dev *dev)
> {
> /* clean up any allocated resources and stuff here.
>* like call release_region();
>*/
> }
>
> static struct pci_driver pci_driver = {
> .name = "pci_skel",
> .id_table = ids,
> .probe = probe,
> .remove = remove,
> };
>
> static int __init pci_skel_init(void)
> {
> printk(KERN_ALERT "PCI driver: Init function\n");
> return pci_register_driver(&pci_driver);
> }
>
> static void __exit pci_skel_exit(void)
> {
> printk(KERN_ALERT "PCI driver: Exit function\n");
> pci_unregister_driver(&pci_driver);
> }
>
> MODULE_LICENSE("GPL");
>
> module_init(pci_skel_init);
> module_exit(pci_skel_exit);
>
>
> The above code fails at the pci_request_regions(dev, "pci_skell"); call,
> with -EBUSY(-16) i.e resource busy error. If I don't request for resources
> and directly enable the pci device by calling pci_device_enable(), it gives
> the error message
>
> PCI driver: Init function
> PCI driver: Probe function
> pci_skel 0001:02:00.0: device not available (can't reserve [mem
> 0x-0x0003])
> Unable to Enable PCI device:-22
> pci_skel: probe of 0001:02:00.0 failed with error -22
Your PCI device should be one virtual device so I think the above should be as
we understood. You know 0x ~ 0x3 should not be allowed to
reserved.
>
>
>
>> Especially I want to know how/where you get
>> these two range, a800-a803 and a804-a807. You wired them
> firstly
>> on the driver or allocated by the kernel?
>
> Actually as I said before, I tried my device on i386 machine and there I got
> two ranges fe90-fe93 and fe94-fe97, so from there I am
> guessing that on PowerPC also, it should allocate two ranges
> a800-a803 and a804-a807 resp.
I think you should do the following sequence in the probe function of your PCI
driver.
1. pci_enable_device(pdev);
2. pci_request_regions(pdev, DRV_NAME);
3. pci_set_master(pdev);
..
>
>
>
> lspci output
>
> :00:00.0 Power PC: Freescale Semiconductor Inc Unknown device 00c6 (rev
> 21)
> 0001:01:00.0 PCI bridge: Freescale Semiconductor Inc Unknown device 00c6
> (rev 21)
> 0001:02:00.0 Non-VGA unclassified device: Lattice Semiconductor Corporation
> Unknown device e250 --> My device
>
>
> Dmesg with CONFIG_PCI_DEBUG enable.
>
> Using MPC837x RDB/WLAN machine description
> Initializing cgroup subsys cpuset
> Initializing cgroup subsys cpu
> Linux version 2.6.35 (ok...@okapi) (gcc version 4.2.3 (Sourcery G++ Lite
> 4.2-171)) #13 Tue Sep 7 11:37:47 IST 2010
> Found initrd at 0xcf46d000
Small issue at init with spi_mpc8xxx.c with CPM1
Dear Kumar, I have a small issue in the init of spi_mpc8xxx.c with MPC866 (CPM1) Unlike cpm_uart that maps the parameter ram directly using of_iomap(np,1), spi_mpc8xxx.c uses cpm_muram_alloc_fixed(). This has two impacts in the .dts file: * The driver must be declared with pram at 1d80 instead of 3d80 whereas it is not a child of mu...@2000 but a child of c...@9c0 * mu...@2000/d...@0 must be declared with reg = <0x0 0x2000> whereas is should be reg=<0x0 0x1c00> to avoid cpm_muram_alloc() to allocate space from parameters ram. Maybe I misunderstood something ? Regards Christophe Leroy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pci_request_regions() failure
Hi Tiejun,
Thanks for the reply. I am sending you the updated dmesg O/P(after enabling
CONFIG_PCI_DEBUG) as attachment as well as at the end of the mail.
As far as driver is concern, I am trying the pci_skel driver available as
example with LDD book with slight modifications.
Driver Code:
#include
#include
#include
/* PCI IDs */
static struct pci_device_id ids[] = {
{ PCI_DEVICE(0x1204, 0xe250) },
{ 0, }
};
MODULE_DEVICE_TABLE(pci, ids);
static unsigned char skel_get_revision(struct pci_dev *dev)
{
u8 revision;
pci_read_config_byte(dev, PCI_REVISION_ID, &revision);
return revision;
}
static u16 skel_get_vendor_id(struct pci_dev *dev)
{
u16 vendor_id;
pci_read_config_word(dev, PCI_VENDOR_ID, &vendor_id);
return vendor_id;
}
static u16 skel_get_device_id(struct pci_dev *dev)
{
u16 device_id;
pci_read_config_word(dev, PCI_DEVICE_ID, &device_id);
return device_id;
}
static int probe(struct pci_dev *dev, const struct pci_device_id *id)
{
/* Do probing type stuff here.
* Like calling request_region();
*/
int err, i;
printk(KERN_ALERT "PCI driver: Probe function\n");
/*
* Enable the bus-master bit values.
* Some PCI BIOSes fail to set the master-enable bit.
* Some demos support being an initiator, so need bus master ability.
*/
err = pci_request_regions(dev, "pci_skell");
if (err) {
printk(KERN_ERR "request region failed :%d\n", err);
return err;
}
pci_set_master(dev);
if ((err = pci_enable_device(dev)) != 0) {
printk(KERN_ERR "Unable to Enable PCI device:%d\n", err);
return err;
}
printk(KERN_ALERT "PCI driver Vendor ID = %x\n", skel_get_vendor_id(dev));
printk(KERN_ALERT "PCI driver Device ID = %x\n", skel_get_device_id(dev));
printk(KERN_ALERT "PCI driver Revision = %d\n", skel_get_revision(dev));
return 0;
}
static void remove(struct pci_dev *dev)
{
/* clean up any allocated resources and stuff here.
* like call release_region();
*/
}
static struct pci_driver pci_driver = {
.name = "pci_skel",
.id_table = ids,
.probe = probe,
.remove = remove,
};
static int __init pci_skel_init(void)
{
printk(KERN_ALERT "PCI driver: Init function\n");
return pci_register_driver(&pci_driver);
}
static void __exit pci_skel_exit(void)
{
printk(KERN_ALERT "PCI driver: Exit function\n");
pci_unregister_driver(&pci_driver);
}
MODULE_LICENSE("GPL");
module_init(pci_skel_init);
module_exit(pci_skel_exit);
The above code fails at the pci_request_regions(dev, "pci_skell"); call,
with -EBUSY(-16) i.e resource busy error. If I don't request for resources
and directly enable the pci device by calling pci_device_enable(), it gives
the error message
PCI driver: Init function
PCI driver: Probe function
pci_skel 0001:02:00.0: device not available (can't reserve [mem
0x-0x0003])
Unable to Enable PCI device:-22
pci_skel: probe of 0001:02:00.0 failed with error -22
> Especially I want to know how/where you get
> these two range, a800-a803 and a804-a807. You wired them
firstly
> on the driver or allocated by the kernel?
Actually as I said before, I tried my device on i386 machine and there I got
two ranges fe90-fe93 and fe94-fe97, so from there I am
guessing that on PowerPC also, it should allocate two ranges
a800-a803 and a804-a807 resp.
lspci output
:00:00.0 Power PC: Freescale Semiconductor Inc Unknown device 00c6 (rev
21)
0001:01:00.0 PCI bridge: Freescale Semiconductor Inc Unknown device 00c6
(rev 21)
0001:02:00.0 Non-VGA unclassified device: Lattice Semiconductor Corporation
Unknown device e250 --> My device
Dmesg with CONFIG_PCI_DEBUG enable.
Using MPC837x RDB/WLAN machine description
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.35 (ok...@okapi) (gcc version 4.2.3 (Sourcery G++ Lite
4.2-171)) #13 Tue Sep 7 11:37:47 IST 2010
Found initrd at 0xcf46d000:0xcf7b15b7
Found legacy serial port 0 for /i...@e000/ser...@4500
mem=e0004500, taddr=e0004500, irq=0, clk=39996, speed=0
Found legacy serial port 1 for /i...@e000/ser...@4600
mem=e0004600, taddr=e0004600, irq=0, clk=39996, speed=0
bootconsole [udbg0] enabled
Found FSL PCI host bridge at 0xe0008500. Firmware bus number: 0->0
PCI host bridge /p...@e0008500 (primary) ranges:
MEM 0x9000..0x9fff -> 0x9000
MEM 0x8000..0x8fff -> 0x8000 Prefetch
IO 0xe030..0xe03f -> 0x
No pci config register base in dev tree, using default
Found FSL PCI host bridge at 0xe0009000. Firmware bus number:
