2009-02-05 10:49:43     PHY Link is Up/Down priority

Document created by Aaronwu Employee on Aug 13, 2013
Version 1Show Document
  • View in full screen mode

2009-02-05 10:49:43     PHY Link is Up/Down priority

Daniele Pagani (ITALY)

Message: 68908   

 

Dear sirs,

 

I've a problem.

 

I've developer a kernelspace/userspace project, in order to send to audio output what I receive from audio input.

 

All works fine.

 

But, when I disconnect the CAT5 cable from the ethernet port (BF537 Ezkit) I see on the terminal the message:

 

PHY: 0:01 - Link is Down - 100/Full and

 

PHY: 0:01 - Link is Up - 100/Full

 

This is ok for me, but, the problem is that I loose interrupt on sport.

 

My priority setting is to have Sportrx with high priority and mac rx with less priority.

 

What can I debug? What happen at kernel level when I disconnect the cable?

 

Best regards,

 

Daniele.

TranslateQuoteReplyEditDelete

 

 

2009-02-05 10:52:23     Re: PHY Link is Up/Down priority

Mike Frysinger (UNITED STATES)

Message: 68911   

 

are you sure it's the MAC and not the serial port ?

 

try running `dmesg -n 1` first

QuoteReplyEditDelete

 

 

2009-02-05 11:01:08     Re: PHY Link is Up/Down priority

Daniele Pagani (ITALY)

Message: 68915   

 

Dear Mike,

 

thank you very much, you've solved my problem.

 

But, what exactly means 'dmesg -n 1'? that is, why serial port is "most important" than my driver?

 

Best regards,

 

Daniele.

TranslateQuoteReplyEditDelete

 

 

2009-02-05 11:08:24     Re: PHY Link is Up/Down priority

Mike Frysinger (UNITED STATES)

Message: 68916   

 

if you want to know about `dmesg`, read the dmesg man page

 

look at your interrupt priorities and see if the UART is above the SPORT.  things dont print out the UART for free.

QuoteReplyEditDelete

 

 

2009-02-11 02:51:28     Re: PHY Link is Up/Down priority

Daniele Pagani (ITALY)

Message: 69232   

 

Dear sirs,

 

I've done some tests.

 

First of all I have uart priority less than sport priority, of course. This is also the default configuration for my board.

 

Then, I use an oscilloscope in order to see what happen.

 

Well, I'm using the Ezkit bf537 and I set an interrupt sport rx at 16/48000 sec, that means 334uS.

 

My audio algorithm, in kernelspace (I know that it is not correct, but today is the only solution that works fine for me), uses 37uS.

 

When in kernelspace I've the interrupt I put the PF13 to 1.

 

When my audio algorithm finished, I set the PF13 to 0.

 

I connect the oscilloscope to PF13, so I can see the timing.

 

Then, if I run a command:

 

/ du

 

I see the my audio alghoritm spends a little more time. I don't understand why; it spends something like 10 or 20 uS more.

 

If I remove the cat5, then I see that my interrupt sport rx comes later, so I loose samples.

 

If I execute 'dmesg -n 1' I've no problem.

 

But, I don't understand why uart could have more priority than sport.

 

Best regards,

 

Daniele.

Attachments

    Outcomes