For the host build the local_irq_save/_restore is a NOOP
and the compiler warns about the unused flags variable. Cast
it to void to avoid compiler warning.
This is Dieter's sync method adapted to the new TPU stuff.
Not perfect, but should work for TS[0:7] as long as you
leave a free frame between each TS changes ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
It's up to L23 to change the parameters using the appropriate
L1CTL call.
This is a mix between Harald's version and Dieter's version of
the TX control code.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Instead of each primitive doing it independently, if there is a TPU
scenario in one of the item, we do a common setup with the base tn
returned by rfch_get_params.
Then each rx / tx window setup is relative to that 'base tn'. For
TX window, you have to explicitely request an offset of 3. (this
would allow for some test code to TX on ts=0 for eg.)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
If those flags are set in one of the item of the current frame,
we end the tpu & dsp scenario in common code.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Each item has a priority associated to it. The standard is :
-4 -> Responses processing
-3 -> L1S parameters changes
-2 -> [Reserved for TPU window setup]
-1 -> (anything)
0..7 -> Commands relative to time slot n
(relative to current l1s main timeslot)
8 -> (anything)
9 -> [Reserved for TPU window cleanup]
10 -> (anthing)
Note that with this modification, an item scheduled for the
current frame from within a call back won't have its priority
respected !
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
While releasing dedicated mode, pending SDCCH and SACCH messages need to be
flushed. Without it, it would also cause old pending messages to be sent
during next dedicated mode.
During IRQ handling, disabling and enabling IRQ may cause the same IRQ to
fire again. This is because the condition for this IRQ may be fullfilled
again, while still handling it. Using local_firq_save() and
local_irq_resore() intead, the IRQ handling will be completed before it is
cleared, and may then fire again.
The problem was detected during process of messages from layer23 to layer1.
In the IRQ context, the TX-functions of l23_api.c are called. There,
messages are queued and events are scheduled. During access to a queue or
a scheduler from any IRQ context or from normal context, interrupts must be
locked to prevent nested calls.
If it is not desired to call l23_api.c inside IRQ context, a message queue
must be used. If a message is written to that queue, it must be locked.
Afterwards a signal must be sent to the main process. The main process
locks the queue and de-queues the message. This is how it is done by all
layer 1 drivers of mISDN.
The given new frequency set will be used at given frame number.
If the frame number is already reached, the frequency set will be changed
directly.
The functionality has been successfully tested.
The layer23 will now set crypto mode and key when CIPHERING MODE COMMAND is
received. After crypto mode has been set, CIPHERING MODE COMPLETE is sent.
NOTE: Layer1 implements only the interface, there is no functionality to it
yet.
The interface between l1 and upper layer is called by several
name. IMHO l1ctl is shorted and sounds good so try to unify
using that.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Holger Hans Peter Freyther
Dieter Spaar
Sylvain Munaut
Harald Welte
Steve Markgraf