Platform devices on MPC8245

Platform devices on MPC8245

[Mark Brown]

I'm having some trouble using the platform device support for the
MPC8245 using memory map B, set up using mpc10x_bridge_init().  When
that function registers the host bridge it registers addresses
0x80000000-0xfebfffff for the bridge but by default (with EUMB mapped to
MPC10X_MAPB_EUMB_BASE) the platform devices on the chip are also within
this address range.  The problem I'm seeing is that when
platform_device_register() comes to call request_resource() on the
devices that call fails because the addresses have already been
allocated to the PCI host bridge.

I'm sure I must be missing something really obvious about how this is
supposed to work but I can't for the life of me see what.  Changing the
platform code to use insert_resource() rather than request_resource()
allows the devices to register and be used but that seems rather too
drastic to be it.

Thanks for any help.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: Platform devices on MPC8245

[Mark Brown]

On Wed, Aug 31, 2005 at 01:26:00PM +0100, Mark Brown wrote:

> I'm having some trouble using the platform device support for the
> MPC8245 using memory map B, set up using mpc10x_bridge_init().  When
> that function registers the host bridge it registers addresses
> 0x80000000-0xfebfffff for the bridge but by default (with EUMB mapped to
> MPC10X_MAPB_EUMB_BASE) the platform devices on the chip are also within
> this address range.  The problem I'm seeing is that when
> platform_device_register() comes to call request_resource() on the
> devices that call fails because the addresses have already been
> allocated to the PCI host bridge.

Does anyone have any suggestions as to what I'm doing wrong with this?
Using kernel 2.6.13 I am currently working around the issue by making
the platform bus use insert_resource() rather than request_resource() as
in the patch below but this really seems like the wrong solution.

--- linux-2.6.13/drivers/base/platform.c        2005-08-29 00:41:01.000000000 +0100
+++ linux/drivers/base/platform.c       2005-09-07 17:26:10.459969600 +0100
@@ -149,7 +149,7 @@
                                p = &ioport_resource;
                }

-               if (p && request_resource(p, r)) {
+               if (p && insert_resource(p, r)) {
                        printk(KERN_ERR
                               "%s: failed to claim resource %d\n",
                               pdev->dev.bus_id, i);


-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: Platform devices on MPC8245

[Vitaly Bordug]

Mark Brown wrote:
> On Wed, Aug 31, 2005 at 01:26:00PM +0100, Mark Brown wrote:
> 
> 
>>I'm having some trouble using the platform device support for the
>>MPC8245 using memory map B, set up using mpc10x_bridge_init().  When
>>that function registers the host bridge it registers addresses
>>0x80000000-0xfebfffff for the bridge but by default (with EUMB mapped to
>>MPC10X_MAPB_EUMB_BASE) the platform devices on the chip are also within
>>this address range.  The problem I'm seeing is that when
>>platform_device_register() comes to call request_resource() on the
>>devices that call fails because the addresses have already been
>>allocated to the PCI host bridge.
> 
> 
> Does anyone have any suggestions as to what I'm doing wrong with this?
> Using kernel 2.6.13 I am currently working around the issue by making
> the platform bus use insert_resource() rather than request_resource() as
> in the patch below but this really seems like the wrong solution.
> 
Yes, that's right. The proper solution (I guess) will be reconfiguration 
  in  mpc10x_bridge_init() so that memory covered by the bridge do not 
intercept anything what pdevs request. Or (less probably) there's 
something odd in pdevs descriptions - if so you need to find out what 
exactly is intercepted with the bridge area.



-- 
Sincerely,
Vitaly

Re: Platform devices on MPC8245

[Mark Brown]

On Wed, Sep 07, 2005 at 08:42:38PM +0400, Vitaly Bordug wrote:

> Yes, that's right. The proper solution (I guess) will be reconfiguration 
>  in  mpc10x_bridge_init() so that memory covered by the bridge do not 
> intercept anything what pdevs request. Or (less probably) there's 
> something odd in pdevs descriptions - if so you need to find out what 
> exactly is intercepted with the bridge area.

Setting the parent for the on-chip devices to be the PCI bridge ought to
do the trick, I think.  The thing that's worrying me is that I can't see
how existing users of this code manage to do so successfully.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."