From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <473484C6.6050101@domain.hid> Date: Fri, 09 Nov 2007 11:03:18 -0500 From: "Steven A. Falco" MIME-Version: 1.0 References: <473391B0.5040809@domain.hid> <4733A2B8.8070100@domain.hid> <47344759.4020505@domain.hid> In-Reply-To: <47344759.4020505@domain.hid> Content-Type: multipart/mixed; boundary="------------080406050901060305010202" Subject: Re: [Xenomai-core] User space drivers on PPC440 List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: xenomai@xenomai.org This is a multi-part message in MIME format. --------------080406050901060305010202 Content-Type: multipart/alternative; boundary="------------050505000005030305050109" --------------050505000005030305050109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Your patch makes sense. I have some results, but I'm not sure I understand what they mean. I've attached the test program that I am using. Here is what it outputs: bash-3.00# ./o2 Trying to free nonexistent resource <0000000000000000-00000000c0000001> get leds: -16 Device or resource busy put leds: 0 Success Trying to free nonexistent resource <0000000000000000-ffffffffffffffff> get low_mem: -16 Device or resource busy put low_mem: 0 Success I am a little unclear on request_resource() - the return code is backwards of what I would have expected. Looking at examples in the kernel, it appears that request_resource() returns EBUSY when things go well, and it returns 0 when things go badly. Like I said, that seems backwards, but I guess it makes sense - EBUSY apparently means that the resource is _now_ busy? Anyway, following the kernel examples, my program considers a non-zero return as success. At that point I release the region. If instead, I get a zero return, then I treat that as a failure, and don't release the region. The part I don't understand is why I get the "Trying to free nonexistent resource" messages. Since I am getting an EBUSY, I thought that meant I owned the resource, and that I should release it... Also, the addresses printed above are a bit strange. For example, I would have thought that instead of "<0000000000000000-00000000c0000001>", it would print "<00000001c0000000-00000001c0000013>". Perhaps that is a clue - maybe the start and length are not being passed correctly. One more question. It appears that if my program crashes, that the region will never be released. So, the normal behavior of an exiting process freeing all its resources doesn't seem to be guaranteed. Steve Philippe Gerum wrote: > Philippe Gerum wrote: > >> Steven A. Falco wrote: >> >>> The rt_misc_get_io_region() has the "start" argument as an unsigned >>> long. On the PPC440, we have a 36-bit address space, where the I/O >>> registers are generally above the 4GB area. For example, the UART is at >>> address 0x1ef600300. >>> >>> The Linux request_region call has "start" typed as a resource_size_t, >>> which is a u64 on the PPC440 (i.e. CONFIG_RESOURCES_64BIT is set even >>> though this is a 23-bit processor). >>> >>> Is this something that should be handled by xeno-config? It could >>> append a CFLAG indicating the size of a resource. >>> >> Or use a 64bit long unconditionally, to keep the same kernel-based >> implementation, since there is no performance issue for this call. In >> any case, we need to fix the API before 2.4 final is out -- which will >> also affect the ABI, but it already changed during the 2.4 development >> phase anyway. >> >> > > Does this patch work for you? > > --------------050505000005030305050109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Your patch makes sense.

I have some results, but I'm not sure I understand what they mean.  I've attached the test program that I am using.  Here is what it outputs:

bash-3.00# ./o2
Trying to free nonexistent resource <0000000000000000-00000000c0000001>
get leds: -16 Device or resource busy
put leds: 0 Success

Trying to free nonexistent resource <0000000000000000-ffffffffffffffff>
get low_mem: -16 Device or resource busy
put low_mem: 0 Success

I am a little unclear on request_resource() - the return code is backwards of what I would have expected.  Looking at examples in the kernel, it appears that request_resource() returns EBUSY when things go well, and it returns 0 when things go badly.  Like I said, that seems backwards, but I guess it makes sense - EBUSY apparently means that the resource is _now_ busy?

Anyway, following the kernel examples, my program considers a non-zero return as success.  At that point I release the region.  If instead, I get a zero return, then I treat that as a failure, and don't release the region.

The part I don't understand is why I get the "Trying to free nonexistent resource" messages.  Since I am getting an EBUSY, I thought that meant I owned the resource, and that I should release it...

Also, the addresses printed above are a bit strange.  For example, I would have thought that instead of "<0000000000000000-00000000c0000001>", it would print "<00000001c0000000-00000001c0000013>".  Perhaps that is a clue - maybe the start and length are not being passed correctly.

One more question.  It appears that if my program crashes, that the region will never be released.  So, the normal behavior of an exiting process freeing all its resources doesn't seem to be guaranteed.

    Steve


Philippe Gerum wrote: 
Philippe Gerum wrote:
  
Steven A. Falco wrote:
    
The rt_misc_get_io_region() has the "start" argument as an unsigned 
long.  On the PPC440, we have a 36-bit address space, where the I/O 
registers are generally above the 4GB area.  For example, the UART is at 
address 0x1ef600300.

The Linux request_region call has "start" typed as a resource_size_t, 
which is a u64 on the PPC440 (i.e. CONFIG_RESOURCES_64BIT is set even 
though this is a 23-bit processor).

Is this something that should be handled by xeno-config?  It could 
append a CFLAG indicating the size of a resource.
      
Or use a 64bit long unconditionally, to keep the same kernel-based
implementation, since there is no performance issue for this call. In
any case, we need to fix the API before 2.4 final is out -- which will
also affect the ABI, but it already changed during the 2.4 development
phase anyway.

    

Does this patch work for you?
--------------050505000005030305050109-- --------------080406050901060305010202 Content-Type: text/x-csrc; name="o2.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="o2.c" #include #include #include #include #include #include #include #include #include #include #include #include #define LED 0x1c0000002ULL #define LEN 13 #define BS 128 test_it(unsigned long long addr, unsigned long len, char *name) { int rv_get; int rv_put; char *bp; char buf[BS]; rv_get = rt_misc_get_io_region(addr, len, name); if(rv_get) { rv_put = rt_misc_put_io_region(addr, len); } bp = strerror_r(-rv_get, buf, BS); fprintf(stderr, "get %s: %d %s\n", name, rv_get, bp); bp = strerror_r(-rv_put, buf, BS); fprintf(stderr, "put %s: %d %s\n", name, rv_put, bp); } main() { test_it(LED, LEN, "leds"); test_it(0, LEN, "low_mem"); } --------------080406050901060305010202--