On Monday 13 September 2010 05:09:15 pm Cyril Chemparathy wrote:
> Hi Caglar,
>
> [...]
>
> > Unfortunately emac driver is not stable after this series. I face
> > lock-ups time to time, followed by attached kernel trace.
>
> Could you elaborate on your test scenario so that I can try and
> repr
Hi Caglar,
[...]
> Assuming that the DMA got stuck at some point leading up to the transmit
> timeout, any ideas as to why a host error was not thrown? To help
> debug, I'll post out a set of patches that dump out the MAC (and DMA)
> registers on timeout. That should give us some visibility into
Hi Caglar,
[...]
> Unfortunately emac driver is not stable after this series. I face lock-ups
> time to time, followed by attached kernel trace.
Could you elaborate on your test scenario so that I can try and
reproduce the problem at my end? Also, did you have the contents of my
commit stack in
Hi Cyril,
On 09/10/2010 06:59 PM, Cyril Chemparathy wrote:
> Hi Mike,
>
> I have merged your latest two emails and responded to both here.
>
[...]
> One of the patches posted on my repo [1] replaces the dumb mdelay() with
> a bit more logic that calculates the worst-case access time. This
> mec
On Friday 10 September 2010 06:23:52 pm Caglar Akyuz wrote:
> On Friday 10 September 2010 12:25:40 am Michael Williamson wrote:
> > Hi Cyril,
> >
> > On 09/09/2010 03:51 PM, Cyril Chemparathy wrote:
> > > Hi Mike,
> > >
> > > [...]
> > >
> > >> The hang is in wait_for_user_access() in the davinci_m
Hi Mike,
I have merged your latest two emails and responded to both here.
[...]
> Your patch doesn't work with my board. It does attempt to reset the bus on
> the read call,
> but following wait_for_user_access() calls are timing out and the _read() and
> _write() calls punt.
> I bumped up
On Friday 10 September 2010 12:25:40 am Michael Williamson wrote:
> Hi Cyril,
>
> On 09/09/2010 03:51 PM, Cyril Chemparathy wrote:
> > Hi Mike,
> >
> > [...]
> >
> >> The hang is in wait_for_user_access() in the davinci_mdio_read() call.
> >> Looks like the state machine got put back into IDLE so
On 09/09/2010 05:24 PM, Cyril Chemparathy wrote:
> Hi Mike,
>
> [...]
>> An EMAC soft-reset clobbering the MDIO controller state is a
>> possibility. I will poll TI designers to see if this could be the case.
>
> To test this theory out, I hacked up a crude
> beat-it-to-death-and-see-if-it-break
Hi Cyril,
On 09/09/2010 03:51 PM, Cyril Chemparathy wrote:
> Hi Mike,
>
> [...]
>> The hang is in wait_for_user_access() in the davinci_mdio_read() call.
>> Looks like
>> the state machine got put back into IDLE somewhere between the MDIO probe
>> and the
>> EMAC probe. Seems like there shoul
Hi Mike,
[...]
> An EMAC soft-reset clobbering the MDIO controller state is a
> possibility. I will poll TI designers to see if this could be the case.
To test this theory out, I hacked up a crude
beat-it-to-death-and-see-if-it-breaks kinda patch (attached). This
tests 1 mdio read cycles wh
Hi Mike,
[...]
> The hang is in wait_for_user_access() in the davinci_mdio_read() call. Looks
> like
> the state machine got put back into IDLE somewhere between the MDIO probe and
> the
> EMAC probe. Seems like there should be some sort of time-out and error
> message
> in the wait_for_user
On 9/8/2010 8:47 PM, Michael Williamson wrote:
> Hi Cyril,
>
> On 09/08/2010 05:59 PM, Cyril Chemparathy wrote:
>> Hi Mike,
>>
>
> So I went in and set the debug_level to netif_msg_init() to -1 in the
> davinci_emac
> driver. The only thing I get during the boot process is:
>
> net eth0: DaVi
Hi Cyril,
On 09/08/2010 05:59 PM, Cyril Chemparathy wrote:
> Hi Mike,
>
> [...]
>> So I just pulled this to test it out on a da850 based board
>> (mitydspl138), and I'm having some problems. I'm hoping it's just
>> operator error.
>
> Probably not, considering that this series had not been test
Hi Mike,
[...]
> So I just pulled this to test it out on a da850 based board
> (mitydspl138), and I'm having some problems. I'm hoping it's just
> operator error.
Probably not, considering that this series had not been tested on da8xx
platforms. Thanks for jumping in!
> I have a TI TLK100PHP P
On 09/07/2010 09:18 PM, Kevin Hilman wrote:
> Cyril Chemparathy writes:
>
>> Davinci's EMAC device has an in-built MDIO controller and a CPDMA engine.
>> These hardware modules are not restricted to EMAC device alone. For example,
>> CPSW3G (3-port gigabit ethernet switch) hardware uses these ve
Cyril Chemparathy writes:
> Davinci's EMAC device has an in-built MDIO controller and a CPDMA engine.
> These hardware modules are not restricted to EMAC device alone. For example,
> CPSW3G (3-port gigabit ethernet switch) hardware uses these very same modules
> internally. This patch series se
Davinci's EMAC device has an in-built MDIO controller and a CPDMA engine.
These hardware modules are not restricted to EMAC device alone. For example,
CPSW3G (3-port gigabit ethernet switch) hardware uses these very same modules
internally. This patch series separates out EMAC's MDIO and CPDMA
fu
17 matches
Mail list logo
