From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <44F8379E.4040801@domain.hid> Date: Fri, 01 Sep 2006 15:37:34 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Xenomai-help] IRQ Enable/Disable References: <44F6E774.2000701@domain.hid> <44F72F35.4070109@domain.hid> <1157099348.4322.32.camel@domain.hid> In-Reply-To: <1157099348.4322.32.camel@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAF13BB38908A480033F74771" Sender: jan.kiszka@domain.hid List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: Xenomai help This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAF13BB38908A480033F74771 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Philippe Gerum wrote: > On Thu, 2006-08-31 at 20:49 +0200, Jan Kiszka wrote: >> Marcelo Coelho wrote: >>> Hi! >>> >>> >>> I've found out in RTAI's 16550a driver, that uses RTDM, the following= >>> comment: >>> >>> /*We should disable the line now, but this requires counting >>> * enable/disable, something not yet implemented by the core. >>> * At the moment this call could starve other users sharing the >>> * same line. >>> rtdm_irq_disable(&ctx->irq_handle);*/ >>> rtdm_irq_free(&ctx->irq_handle); >> In fact, you find the same in Xenomai as RTAI just mirrors the origina= l. :) >> >>> Is this still true? I mean, if i free the device at device close, sho= uld >>> i expect that i need to request the irq again? >> It is still true. Xenomai does not support a nesting counter for >> irq_disable/enable yet, therefore RTDM did not change its interface in= >> this regard as well. >> >>> I'm trying to ckeck what to expect about these calls. >>> >> For now the situation is like this: rtdm_irq_request allocates an IRQ,= >> but doesn't necessarily enables it. So you have to call rtdm_irq_enabl= e >> afterwards. To release it, just switch off IRQ generation in your devi= ce >> and call rtdm_irq_free. >> >> That's true unless the IRQ is shared. Then some other driver may have >> already enabled it (which doesn't releases your from the duty to do it= >> again - you cannot predict the load order). Therefore, if writing a >> driver with shared IRQ support, you should not rely on the fact that t= he >> IRQ line is disabled right after rtdm_irq_request. Neither should you >> disable the line on release (only in the hardware). Otherwise, you wou= ld >> cut off persisting users of that line. >> >> >> Mmh, your question makes me wonder if we shouldn't enable the line in >> rtdm_irq_request automatically. I do not recall any urging use-case fo= r >> the current behaviour... Does anyone else? >> >> Dmitry, Philippe, what's the reason for the split up in the core? Does= >> any skin require this? >> >=20 > In short, the split up is there because the nucleus is expected to > provide mechanisms, not policies, and enabling the channel implicitely > upon attachment would impose some kind of policy downstream. Since > finding a standard for interrupt handling among OS and platforms is > impossible, the core only provides the LEGO bricks, it's up to the uppe= r > layers to build the big and flashy red fireman truck with those... >=20 Ok, makes sense for the core (though it prevents nested irq_enable/disable). But I'm convinced now, also when considering RTDM over -rt, that RTDM should undergo a change: rtdm_irq_request should always return the line enabled. The first step is now to move rtdm_irq_request and rtdm_irq_enabled close to each other in all existing (and publicly known) drivers. Then we will see, if this change can be part of 2.3 or is rather something for a farther release. Jan --------------enigAF13BB38908A480033F74771 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE+DeeniDOoMHTA+kRAo2sAJ0Ul68+F5vl1wkJzagi5vagJsopbwCeKKts ZuuI+eUKkj5KsLxHMRZxRe8= =aoLV -----END PGP SIGNATURE----- --------------enigAF13BB38908A480033F74771--