2009/5/16 Daniel Ribeiro :
> Yes, I think that tty_ops is the best. It is already used for MUX -> IPC
> write(), and it should be used for the read() too.
there is no read() in tty drivers. tty driver only adds data to buffer.
--
wbr, Ilya
ICQ: none, Jabber: ilya.muro...@jabber.ru
Em Sáb, 2009-05-16 às 13:04 +0300, Ilya Petrov escreveu:
> >it will go a little crazy with the CIEV flood, but whatever. :)
>
> not really. CIEV flood should start only after BP will register to network.
>
> on gen2 bp waiting for AT+EPOM before do anyting even with SIM PIN disabled.
> how it is
Em Sáb, 2009-05-16 às 12:07 +0200, Michael 'Mickey' Lauer escreveu:
> In the absence of true reference material on that, my gut feeling is that it
> would be better to have unused channels also closed on the DLCI layer.
>
> However -- if we already have to open all the DLCIs at handshake time to
2009/5/16 Michael 'Mickey' Lauer :
> However -- if we already have to open all the DLCIs at handshake time to make
> sure the BP does not panic, then we might as well keep them open and
> virtualize it just as Daniel recommended.
ok
--
wbr, Ilya
ICQ: none, Jabber: ilya.muro...@jabber.ru
On Saturday 16 May 2009 11:58:11 Ilya Petrov wrote:
> > Do nothing to warn bp about open()/close(). Make it fully virtual, let
> > bp think that all the lines are always opened.
>
> ok. this looks good to prevent bp from panic, but is this correct way?
In the absence of true reference material on
2009/5/16 Daniel Ribeiro :
> This is not a good idea. Some messages are sent only once just after
> open().
yep. for example BT address
>it will go a little crazy with the CIEV flood, but whatever. :)
not really. CIEV flood should start only after BP will register to network.
on gen2 bp waiting
would_ be different and
we should handle this in userspace.
> Same as AT lines? :)
AFAIK, mux driver should know, which type dlci is:
if (iscmdtty[line]) {
TS0710_DEBUGSTR(&d_buf[1], c);
TS0710_DEBUG("CMDTAG");
d_buf[0] = CMDTAG;
} else {
TS0710_DEBUG("DATATAG"
Hi Daniel,
> > > Use dlci lines as device numbers. No mapping, use a standard from
> > the
> > > kernel so userspace doesnt need to be different between the phones.
> >
> > sounds like a bad idea since you will limit yourself to one MUX
> > instance
> > on the system. In theory you can have multi
Em Sex, 2009-05-15 às 17:38 -0700, Marcel Holtmann escreveu:
> > Use dlci lines as device numbers. No mapping, use a standard from
> the
> > kernel so userspace doesnt need to be different between the phones.
>
> sounds like a bad idea since you will limit yourself to one MUX
> instance
> on the s
Hi Daniel,
> > I`m hacking mux driver now.
> > I`m doing some cleanup to make it looking not so hmm... strange.
> >
> > In moto code mux driver is splitted to ipc-usb driver (tty) and
> > ts07.10 multiplexer.
> > As wyrm said, on some old phones bp was
Em Sex, 2009-05-15 às 20:15 +0300, Ilya Petrov escreveu:
> Hi!
>
> I`m hacking mux driver now.
> I`m doing some cleanup to make it looking not so hmm... strange.
>
> In moto code mux driver is splitted to ipc-usb driver (tty) and
> ts07.10 multiplexer.
> As wyrm said, o
Em Sáb, 2009-05-16 às 01:34 +0300, Ilya Petrov escreveu:
> > That's unacceptable. BP should not panic even if there is just an init
> > process
> > running (yes, the initial handshake time may be an exception).
>
> AFAIK, for this we need to open first 8 dlcis or hack bp.
> but even after we open
Hello.
On Sat, 2009-05-16 at 01:50, Ilya Petrov wrote:
> 2009/5/16 Stefan Schmidt :
>
>
> > Yes. A clean separation between the hardware driver, speak ipc-usb, and the
> > protocol, speak ts0710. I see three usage scenarios here:
> >
> > 1) Keep the ts0710 implementations we have with all the sp
2009/5/16 Michael 'Mickey' Lauer :
> I know which kind of panic you mean, but after the initial handshake of ezxd,
> I never had a problem with leaving channels closed -- even for hours.
i was about kernel handshake, not userspace.
and i`m not using ezxd at all, i`m using qtopia with AT in fat a
rs (exported symbols) of each other.
> I really can't remember. The first thing that comes
> into my mind is to design the function in a way that they also can be used in
> the struct uart_ops.
dont understand here at all :)
>We could then have option 1 & 2 together in place.
On Saturday 16 May 2009 00:34:00 Ilya Petrov wrote:
> 2009/5/16 Michael 'Mickey' Lauer :
> > I can't answer these question, until more things are clear. For one, I
> > have yet to see a proof that some commands only work on some channels.
>
> r...@a1200:~# cat /dev/mux0 &
> r...@a1200:~# cat /dev
2009/5/16 Michael 'Mickey' Lauer :
> I can't answer these question, until more things are clear. For one, I have
> yet to see a proof that some commands only work on some channels.
r...@a1200:~# cat /dev/mux0 &
r...@a1200:~# cat /dev/mux6 &
r...@a1200:~# echo -ne 'AT+CGACT=0\r\n\r' > /dev/mux
On Friday 15 May 2009 19:15:38 Ilya Petrov wrote:
> I`m hacking mux driver now.
> I`m doing some cleanup to make it looking not so hmm... strange.
Great!
> 1) should we keep ipc-usb and ts0710 as two separate drivers?
> 2) if yes, how they should interact?
> 3) do we have any p
mebody starts it. :)
> In moto code mux driver is splitted to ipc-usb driver (tty) and
> ts07.10 multiplexer.
> As wyrm said, on some old phones bp was connected via uart.
He refers to pre-gen0 here? Like the A760, etc? I would say we should not care
to much about them as we simply do
Some more about mappings and data lines:
tty 12 is data tty and used for gprs (on gen2. not sure about gen1).
on gen1 its dlci channel 12, on gen2 its dlci channel 6.
this is for what mappings are used in moto code.
btw, gprs net device implemented via ldisc and its code
is _very_ different from
Hi!
I`m hacking mux driver now.
I`m doing some cleanup to make it looking not so hmm... strange.
In moto code mux driver is splitted to ipc-usb driver (tty) and
ts07.10 multiplexer.
As wyrm said, on some old phones bp was connected via uart.
So some questions:
1) should we keep ipc-usb and
21 matches
Mail list logo
