|
From: Gilles C. <gil...@xe...> - 2010-10-07 09:41:35
|
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. -- Gilles. |
