|
From: Jan K. <jan...@si...> - 2010-10-07 10:52:39
|
Am 07.10.2010 11:41, Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Am 07.10.2010 11:27, Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: >>>> Am 07.10.2010 11:13, Gilles Chanteperdrix wrote: >>>>> Jan Kiszka wrote: >>>>>> Am 04.10.2010 22:13, Edward Hoffman wrote: >>>>>>> I am attempting to port the Broadcom tg3 NetXtreme linux driver to >>>>>>> rtnet. >>>>>> Your port will be welcome! >>>>>> >>>>>>> The Broadcom driver internally utilizes >>>>>>> spin_lock_bh/spin_unlock_bh to disable/enable software interrupts. >>>>>>> There is no rtdm lock equivalent. >>>>>>> I believe that software interrupts are used by the driver for the >>>>>>> following reasons: >>>>>>> 1. To allow for simultaneous DMA read write operations >>>>>>> 2. To use shared local variables in a critical section of the driver. >>>>>>> 3. To receive changes to settings variables in realtime from the >>>>>>> userpace Nextreme utilities. (not sure about this one). >>>>>>> >>>>>>> What RTDM lock functions should I use to substitute for >>>>>>> spin_lock_bh/spin_unlock_bh? Should I substitute >>>>>>> rtdm_lock_get_irqsave/rtdm_lock_put_irqrestore? Or does rtdm need to ne >>>>>>> extended for softirqs used internally by the driver? >>>>>>> >>>>>>> I looked through the other device drivers and could not detect the >>>>>>> correct substitute. >>>>>> As RTDM provides no abstraction of bottom-halves, there are also no >>>>>> specific locking services to disable them. You have to use IRQ-disabling >>>>>> services unless you are in IRQ context. >>>>> Maybe if you want to only exclude the driver's irq, you may only disable >>>>> the irq line at IC level, with rtdm_irq_disable? >>>> Usually discouraged due to potentially slow line-disabling services and >>>> the breakage this will cause when the line is shared. >>> Why would this cause breakage when the line is shared? >> >> If the disabling context is preemptible (which is normally the >> motivation when avoiding irqsave), the line may remain off until that >> task happens to be scheduled in again. That can easily cause >> prio-inversions to other devices sharing the line. > > Yes, we should obviously disable preemption when doing that. What would > probably work is: > - disabling preemption > - disabling the irq line > - locking the spinlock. > > Maybe that could be bundled in rtdm_lock_get_disable_irq(lock, irq) ? > Disabling an irq line should be pretty fast on non-x86, besides, if the > original code used spin_lock_bh, it is maybe because the critical > section is expected to be lengthy, so irqsave/irqrestore may cause high > latencies in the rest of the system. Generally spoken, disabling preemption can cause high latencies as well as most critical paths include a task switch. However, anything that is more light-weight than irqsave/restore and has compatible semantics would still be welcome. It just requires some relevant performance and/or latency gain to justify complications in the locking model. We actually have two or so cases in RTnet where drivers contain long locked code paths (orders of a few hundred microseconds). In those cases, disabling the IRQ line without any preemption lock is the only way to keep system latencies in reasonable limits. But those are still corner cases. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux |
