Hi All,
I am developing driver for a chip, which supports two ports. I have used resource manager and called resmgr_attach() two times to make port entry in the pathname space. ( for each port number) /dev/ser1 and /dev/ser2.
Application can access both ports and driver needs to facilitate the write and read for each port. But how does driver come to know that application called write /read for which port ???
I wants to understand, if application calls second port of chip then driver write / recv data to second port not to first port ???
When you do the resmgr_attach you pass an attribute structure. Depending on which “port” is accessed, the matching attribute structure gets pass down to all the callbacks. Inside that attribute structure you need to put every information relevant to the port or device, buffers, status, hardware information. That way when a callback is called it doesn’t care the port it handles, is just uses the information in the attribute structure.
Hi Mario,
I have used a global structure in my driver implementation which helps me to determine which port registers shall be used for write and read operation. Thats why i need to determine different port no. in resource manager.
Consider in a driver resmgr_attach() called two times for Port 1 and Port 2.
Application side :
Port1 = open("/dev/Port1",O_RDWR);
Port2 = open("/dev/Port2",O_RDWR);
…
…
write(Port1,buffer,sizeof(buffer));
write(Port2,buffer,sizeof(buffer));
On driver side, Resource manager framework used for driver implementation and write calls goes like this,
int write(resmgr_context_t *ctp, io_write_t *msg, RESMGR_OCB_T *ocb)
{
…
if(writing to Port1)
dev = &global_devices[0];
if(writing to Port2)
dev = &global_devices[1];
.......................................................
}
I hope you understand now why i need port number in Resource manager. Do you know any structure in resource manager which indicate port number during write and read callback.
I think you missed my post. In your io_write fonction, you get passed an ocb, in the ocb there is a pointer to an attribute structure. It`s the same attribute structures specified in the resmgr_attach call.
For the resmgr framework to work you must have must different attributes for each call to resmgr_attach. That attribute structure can be expended (it’s all well documented) to hold whatever you need. In your case it could be pointer to the global_device[x]. Or even better the extended attribute could hold your global_device data.
Hence your code would look like:
int write(resmgr_context_t *ctp, io_write_t *msg, RESMGR_OCB_T *ocb)
{
…
dev = &ocb->attr->global_device;
…
}
Much cleaner, you code will work with what ever number port you driver may support being one or one hundred.
Thanks alot mario for clear cut idea.
During debugging, i knew that something needs to be done for rdev field of attr. I have modified following field for both ports like
ioattr_Port1.rdev = 1;
ioattr_Port2.rdev = 2;
now i can determine that write / read calls refer to which port.I think you missed the point, the idea is to make it so your code DOES NOT CARE which port it is working on.
That being said I`m not sure you can use the rdev field for your own use, check the documentation.