On 05/01/2011 08:41 PM, Kushwaha Prabhakar-B32579 wrote:
Hi,
I have no comments about coding and architecture. It looks fine.
Only have a query about its use case..
"Any application intended to use message interrupt requires to
know
reg_num because of struct mpic_msgr* mpic_msgr_get(unsigned int
reg_num) API"
It will be good to search available unit internally and provide
its
pointer. It will make application more flexible.
The problem is that you fundamentally cannot implement an allocator
for MSG registers if you're going to communicate with another kernel
(how would both kernels' allocators be synchronized?). So the
message register allocation must be decided at design time, not run time.
I agree with you.. It is true while communicating with another kernel.
But message interrupts can be used by different independent drivers
within same kernel. For eg. PCIe and Ethernet driver.
As per current design both drivers needs to be in sync before
requesting any message unit for avoiding any conflict. As these drivers
are completely independent. It is very difficult.
Can it be possible to provide new API to take care it.
Do you have a real use case in mind where these message registers (not
MSIs) are used internally in this manner?
Yes, we use for PCIe host/agent test case scenario.
Host usage message register to interrupt Agent...
Agent uses message register to generate irq_out (automatically generate MSI) to
interrupt master. Please see RM for more details about irq_out
Note: PCIe host/agent test scenario is used internally and we are working on
pushing it out..
I believe this has been true for several years.
Perhaps an allocator could be added in the same patchset that adds such a
user.
Yaa. It can be done. Otherwise module has to query each message unit for its
availability.
No, instead the system designer should pick one. If it doesn't matter
which one, then the designer is free to pick any.
An allocator can't work if you're going to mix drivers. For example,
driver A needs MSRG0, and driver B doesn't care. Driver B loads first,
the allocator selects MSGR0; driver A loads and fails. Having an
allocator at all will create this conflict.
To prevent this scenario, either don't use a MSGR (can you configure
anything else for irq_out?), or have the system designer choose all MSGRs.
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
