Hello Kenji-san,
Kenji Kaneshige wrote:
Felix, I think assigning hpXXsize at boot time is the simpler solution,
if it is acceptable workaround for you. And as Yinghai suggested in the
another email, removing slot's parent bridge first should be one of the
workaround. But the problem is whether
Yinghai Lu wrote:
On Sun, Mar 28, 2010 at 2:13 AM, Felix Radensky wrote:
Hello, Kenji-san
I've tried Jesse's tree with Yinghai's patches, but they don't seem to help.
Memory for bridge is not allocated after insertion of hotplug device and
bus rescan. Attached dmesg output in case of success a
On Sun, Mar 28, 2010 at 2:13 AM, Felix Radensky wrote:
> Hello, Kenji-san
>
> I've tried Jesse's tree with Yinghai's patches, but they don't seem to help.
> Memory for bridge is not allocated after insertion of hotplug device and
> bus rescan. Attached dmesg output in case of success and failure.
Hi Ben,
Benjamin Herrenschmidt wrote:
On Sun, 2010-03-28 at 12:13 +0300, Felix Radensky wrote:
I've tried Jesse's tree with Yinghai's patches, but they don't seem to help.
Memory for bridge is not allocated after insertion of hotplug device and
bus rescan. Attached dmesg output in case of s
On Sun, 2010-03-28 at 12:13 +0300, Felix Radensky wrote:
> I've tried Jesse's tree with Yinghai's patches, but they don't seem to help.
> Memory for bridge is not allocated after insertion of hotplug device and
> bus rescan. Attached dmesg output in case of success and failure.
I'd recommend that
Hello, Kenji-san
Kenji Kaneshige wrote:
Felix Radensky wrote:
Hello, Kenji-san
Kenji Kaneshige wrote:
I misunderstood the problem.
My understanding was memory resource was not enabled even though
Linux set
the Memory Space bit in the command register. But it was not
correct. The
bridge mem
> > This is Jesse tree with the default Canyonlands defconfig ? Hrm... I'll
> > have to take a look, somebody mucking with PCI resource allocation is
> > very likely to break something :-)
> >
> >
> >
>
> Yep, default Canyonlands defconfig and default DTS.
Ok so Jesse is innocent :-)
See the
> > This is Jesse tree with the default Canyonlands defconfig ? Hrm... I'll
> > have to take a look, somebody mucking with PCI resource allocation is
> > very likely to break something :-)
> >
> >
> >
>
> Yep, default Canyonlands defconfig and default DTS.
Which branch of Jesse tree btw ? "ma
Hi Ben,
Benjamin Herrenschmidt wrote:
On Wed, 2010-03-17 at 09:38 +0200, Felix Radensky wrote:
Hello Kenj-san
Kenji Kaneshige wrote:
By the way, I think Yinghai's bridge resource reallocation patch series
might help you. It is in Jesse's PCI tree. Please take a look.
I've tr
On Wed, 2010-03-17 at 09:38 +0200, Felix Radensky wrote:
> Hello Kenj-san
>
> Kenji Kaneshige wrote:
> >
> >
> > By the way, I think Yinghai's bridge resource reallocation patch series
> > might help you. It is in Jesse's PCI tree. Please take a look.
> >
> >
> I've tried Jesse's tree on my custom
Hello Kenj-san
Kenji Kaneshige wrote:
By the way, I think Yinghai's bridge resource reallocation patch series
might help you. It is in Jesse's PCI tree. Please take a look.
I've tried Jesse's tree on my custom board and on 460EX evaluation board
(Canyonlands). In both cases the kernel doesn
Felix Radensky wrote:
Hello, Kenji-san
Kenji Kaneshige wrote:
I misunderstood the problem.
My understanding was memory resource was not enabled even though Linux
set
the Memory Space bit in the command register. But it was not correct. The
bridge memory window was marked unused and Linux did
Hello, Kenji-san
Kenji Kaneshige wrote:
I misunderstood the problem.
My understanding was memory resource was not enabled even though Linux
set
the Memory Space bit in the command register. But it was not correct. The
bridge memory window was marked unused and Linux didn't try to set Memory
S
Hello, Kenji-san
Kenji Kaneshige wrote:
I misunderstood the problem.
My understanding was memory resource was not enabled even though Linux
set
the Memory Space bit in the command register. But it was not correct. The
bridge memory window was marked unused and Linux didn't try to set Memory
S
Felix Radensky wrote:
Hello, Kenji-san
I think the device is expected to be ready to work if pci_enable_device()
returns without error. So I think pci_enable_device() should return an
error if it fails to enable the device (device is not ready to work). In
this case, detecting your bridge's fai
Hello, Kenji-san
I think the device is expected to be ready to work if pci_enable_device()
returns without error. So I think pci_enable_device() should return an
error if it fails to enable the device (device is not ready to work). In
this case, detecting your bridge's failure seems PPC specific
Felix Radensky wrote:
Hello Kenji-san,
Kenji Kaneshige wrote:
Felix Radensky wrote:
Hello Kenji-san,
Kenji Kaneshige wrote:
I'm not sure, but I guess pci_setup_bridge() didn't update IO
base/limit
and Mem base/limit of the bridge (:00:02.0) because of the
following
lines.
static void
Hello Kenji-san,
Kenji Kaneshige wrote:
Felix Radensky wrote:
Hello Kenji-san,
Kenji Kaneshige wrote:
I'm not sure, but I guess pci_setup_bridge() didn't update IO
base/limit
and Mem base/limit of the bridge (:00:02.0) because of the
following
lines.
static void pci_setup_bridge(struct
On Mon, 2010-03-15 at 16:46 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2010-03-15 at 14:39 +0900, Kenji Kaneshige wrote:
> >
> > > Yes, with these lines removed bridge memory window is properly
> > allocated.
> >
> > These lines are to prevent updating IO or memory windows when there
> > are
On Mon, 2010-03-15 at 14:39 +0900, Kenji Kaneshige wrote:
>
> > Yes, with these lines removed bridge memory window is properly
> allocated.
>
> These lines are to prevent updating IO or memory windows when there
> are
> some devices working behind the bridge. So please note that removing
> these
Felix Radensky wrote:
Hello Kenji-san,
Kenji Kaneshige wrote:
I'm not sure, but I guess pci_setup_bridge() didn't update IO base/limit
and Mem base/limit of the bridge (:00:02.0) because of the following
lines.
static void pci_setup_bridge(struct pci_bus *bus)
{
struct pci_dev *brid
Hello Kenji-san,
Kenji Kaneshige wrote:
I'm not sure, but I guess pci_setup_bridge() didn't update IO base/limit
and Mem base/limit of the bridge (:00:02.0) because of the following
lines.
static void pci_setup_bridge(struct pci_bus *bus)
{
struct pci_dev *bridge = bus->self;
I'm not sure, but I guess pci_setup_bridge() didn't update IO base/limit
and Mem base/limit of the bridge (:00:02.0) because of the following
lines.
static void pci_setup_bridge(struct pci_bus *bus)
{
struct pci_dev *bridge = bus->self;
struct resource *res;
struct pci_bu
On Thu, 2010-03-11 at 23:41 +0200, Felix Radensky wrote:
> I'm fine with creating a minimal hotplug driver. The device I'm
> dealing with
> partially implements Compact PCI hotplug. It generates ENUM#
> interrupt, but
> Hotswap Control register layout does not completely follow the
> standard.
>
>
Hi Ben,
Benjamin Herrenschmidt wrote:
Yes, we need to do a resource allocation pass, setup DMA, etc... and
that is not done in that manual rescan case I suppose. I have to look.
Part of the problem is that there is no "proper" hooks in the generic
PCI code that I know of for that, but I'll have
On Thu, 2010-03-11 at 09:45 +0200, Felix Radensky wrote:
> Hi Alex,
>
> Thanks a lot for replying.
>
> Alex Chiang wrote:
> > * Felix Radensky :
> >
> > > The problem arises when device is plugged in after boot. After doing
> > > echo 1 > /sys/bus/pci/rescan
> > > the device is identified, bu
Hi Alex,
Thanks a lot for replying.
Alex Chiang wrote:
* Felix Radensky :
The problem arises when device is plugged in after boot. After doing
echo 1 > /sys/bus/pci/rescan
the device is identified, but bridge memory window is not allocated,
and reads from device memory regions r
Hi Alex,
Resending, previous attempt was erroneously send as HTML.
Thanks a lot for replying.
Alex Chiang wrote:
* Felix Radensky :
The problem arises when device is plugged in after boot. After doing
echo 1 > /sys/bus/pci/rescan
the device is identified, but bridge memory window is not al
Hi,
I'm running linux-2.6.33 on a custom board based on 460EX.
There's a PCI-PCI bridge on this board, PLX 6254, and a single
hot-pluggable device behind the bridge.
When this device is plugged in before system boots everything works
fine: bridge and device are properly recognized by kernel, res
29 matches
Mail list logo
