Hi,
On Sat, Jan 3, 2009 at 3:38 PM, Dasgupta, Romit <romit@xxxxxx> wrote:
> PCI defines its own communication protocol. Your target firmware should implement the mandatory PCI Config space protocol and what you want to do on accessing the PCI I/O space. At this point of time I think you should ask what type of device is your target going to look like. If your target device falls among one of the standard devices (like network card, sound card etc.) then Linux kernel supports those infrastructure and you do not have to necessarily create /dev nodes (though nothing prevents you to have a non-standard device model for which you can create /dev nodes).
My device does not fall under standard devices like network card or sound card.
The dev nodes are just mechanism to manipulate or communicate with the
target card devices for me. The target is running u-boot and host is
running linux.
All the communication passing should be done using command packets. The
target should take the command and execute with the data provided
along with that and
provide response to host through PCI interrupts.
A simple example is this.
Assume from host I want to execute U-boot commands.
1) I open a device /dev/uboot from target
2) Then I do write(fd,"tftp 0x80000000 uImage",sizeof("tftp 0x80000000 uImage")
3) Then the driver should form a command packet and write to the shared buffer
between host and target
4) Then it signals the target for the command.
5) The target should execute the command and write the result back to
a shared buffer
Similarly for all the devices found on target I have to do the same thing.
Does anybody have any pointers?
>
> On the other hand, I have seen a non-standard PCI model where a 21555 non-transparent PCI to PCI bridge was used and on top of that a virtual network driver was created. Note that in this case their was no pre-designated master, slave in the bus. You could access the memory of one side from the other through the virtual network interface. You can see this in http://www.kwaak.net/~ard/fotos/epcbin/kernel/celinux-040503.q/Documentation/networking/mvnet.txt though I do not think this type of device is what you have in mind.
This link is not working for me
>
> Thanks,
> -Romit
>
>>-----Original Message-----
>>From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-
>>owner@xxxxxxxxxxxxxxx] On Behalf Of arun c
>>Sent: Saturday, January 03, 2009 3:17 PM
>>To: linux-pci@xxxxxxxxxxxxxxx
>>Subject: Communication protocol through PCI between host and target
>>
>>Hi all,
>>
>>I am a newbie here please bear with me.
>>
>>In my custom board the communication between host and target
>>should happen through PCI interface.
>>
>>The target processor runs u-boot, and host processor is running linux.
>>
>>The target devices will be accessed from the host by /dev nodes.
>>
>>To reduce the workload on host all the target calls like
>>open, read ,write ,ioctl are passed directly to the target.
>>
>>There will be a common PCI buffer between host
>>and target and target will take commands from this buffer
>>and execute. The result of executed API also will be put to a shared buffer
>>between host and target. [This is what I am planning to implement]
>>
>>Anybody has come across similar sort of scenario?
>>Any ideas or any pointers will be highly appreciated.
>>
>>Regards,
>>Arun C
>>--
>>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>the body of a message to majordomo@xxxxxxxxxxxxxxx
>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
