Page MenuHomeFreeBSD

Add interrupt line for EHCI USB errors in Armada38x
AbandonedPublic

Authored by bsz_semihalf.com on Dec 4 2015, 12:36 PM.
Tags
Referenced Files
Unknown Object (File)
Fri, Dec 13, 12:07 AM
Unknown Object (File)
Sat, Nov 30, 5:02 PM
Unknown Object (File)
Fri, Nov 29, 1:57 AM
Unknown Object (File)
Oct 23 2024, 7:31 PM
Unknown Object (File)
Oct 22 2024, 11:37 AM
Unknown Object (File)
Oct 22 2024, 11:37 AM
Unknown Object (File)
Oct 22 2024, 11:37 AM
Unknown Object (File)
Oct 22 2024, 11:24 AM
Subscribers

Details

Reviewers
imp
ian
Summary

FreeBSD EHCI driver for Marvell platforms requires dedicated interrupt lines
for error handling. USB2.0 attaches and works properly after this commit.

Obtained from: Semihalf
Sponsored by: Stormshield
Submitted by: Bartosz Szczepanek <bsz@semihalf.com>

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

bsz_semihalf.com retitled this revision from to Add interrupt line for EHCI USB errors in Armada38x.
bsz_semihalf.com updated this object.
bsz_semihalf.com edited the test plan for this revision. (Show Details)
bsz_semihalf.com added reviewers: ian, imp.
bsz_semihalf.com set the repository for this revision to rS FreeBSD src repository - subversion.
bsz_semihalf.com added a project: ARM.
bsz_semihalf.com added a subscriber: zbb.

andrew, we decided to do raw import from Linux in first commit, and then introduce all neccessary changes explicitly in seperate commits.

So why don't you fix the code to only need one interrupt in this case?

Interrupt line for errors exists in hardware and is documented Armada38x family functional specifications, so better to say that dts was incomplete, than the code needed fix.

This makes our local copy of the dts different than the published linux copy, that seems like a step in the wrong direction. The linux driver must be able to work without this interrupt? (I hate that linux just leaves hardware descriptions out of dts files if their driver doesn't care about that detail, is that the case here?)

In D4370#94235, @ian wrote:

This makes our local copy of the dts different than the published linux copy, that seems like a step in the wrong direction. The linux driver must be able to work without this interrupt? (I hate that linux just leaves hardware descriptions out of dts files if their driver doesn't care about that detail, is that the case here?)

Exactly, the interrupt is in hardware but Linux doesn't need it. Our driver needed, but I changed it according to Andrew's remarks: https://reviews.freebsd.org/D4369
So as for now this commit is not neccessary, I'll try to close it.