I thought about the control bit method. However again it is not obvious to me how the receive side know when to use nget or ncget. I suppose you can monitor the MSR carry bit to tell a control bit is set when using nget. It just seems awkward to make the driver to handle it.
I spent a couple days trying to use a second FSL channel to send the file size without success. I thought the driver can read through all channels. However I got a BUG message about "scheduling while atomic" when I have two channels enabled. Do you know what could have caused this issue?
Now my new approach is what you described last. I am trying to insert
the file size at the beginning. It will work for my demo since I will always read from a file. But for a HW guy like me, writing the integer length count to a char device is a challenge already. :O<
----- Original Message ----
From: John Williams <jwilliams@xxxxxxxxxxxxxx>
To: microblaze-uclinux@xxxxxxxxxxxxxx
Sent: Thursday, April 3, 2008 6:01:25 PM
Subject: Re: [microblaze-uclinux] FSLFIFO driver usage examples
Hi
Simon,
Simon
Tam
wrote:
>
Hi
Hans/John,
>
>
I
have
a
FSL
link
between
two
MB
processors.
I
modified
fslcat
so
that
>
it
becomes
a
receiver
(fslrcv)
on
the
processor.
The
code
is
attached.
I
>
am
having
trouble
to
get
fslrcv
working
properly.
Basically
it
does
not
>
terminate
after
completing
the
transfer.
However
I
suspect
the
root
>
cause
is
in
the
driver
instead.
It
is
not
obvious
to
me
how
fsl_read()
>
can
tell
when
to
quit
hence
causing
the
problem.
Do
you
have
suggestion
>
how
to
fix
this?
You
have
correctly
identified
the
problem
-
how
can
the
receiving
FSL
driver
correctly
identify
and
end-of-file
condition
at
the
originator?
One
way
might
be
to
use
the
FSL
control
bit,
but
will
require
clever
driver
tweaking.
The
write()
method
will
need
to
know
somehow
when
the
file
descriptor
has
been
closed,
and
send
the
last
data
with
control
bit
set.
In
this
sense
the
device
driver
is
more
like
a
linux
pipe
than
a
proper
character
device.
On
the
receive
side,
when
a
control
bit
is
detected,
it
signifies
EOF
to
the
reader
after
the
final
word
is
read
out.
Not
easy
to
implement
actually
because
there
are
a
lot
of
subtleties,
and
it
also
introduces
protocol
to
the
driver,
which
previously
just
worried
about
the
low
level
transport
issues.
A
simpler
idea
would
be
to
tweak
fslcat
/
fslrcv
so
interpret
the
first
two
words
as
a
length
token.
Problem
there
is
of
course
that
fslcat
may
not
know
in
advance
how
long
its
input
is
(if
it's
coming
from
stdin
rather
than
a
file).
Some
ideas
to
play
with.
Cheers,
John
___________________________
microblaze-uclinux
mailing
list
microblaze-uclinux@xxxxxxxxxxxxxxProject
Home
Page
:
http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinuxMailing
List
Archive
:
http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/