| Age | Commit message (Collapse) | Author |
|---|
|
RTL8103E, from FreeBSD.
ok sthen@
|
|
|
|
Arrandale (on laptop i3 and i5) was already doing this, but Clarkdale (the
desktop chipsets) wasn't. This gives mikeb@'s desktop a chance to get the video
back on resume.
While here, remove the vendor/subvendor ids from the Arrandale entry.
Just because someone doesn't have the same laptops as tested doesn't
mean inteldrm magically has the ability to restore the graphics chip.
This is possible to do without repost but fiddly and will take me a
while to sort out, so just repost the whole sodding lot for now.
ok ketteis@, deraadt@, mikeb@
|
|
ok miod@
|
|
Updating state LED only when necessary.
ok krw@
|
|
when leaving. when you're handling an interrupt it is masked.
whacking the chip is work for no gain.
modify the interrupt handler so it only processes the rings once,
rather than looping over them until it runs out of work to do.
looping in the isr is bad for several reasons:
firstly, the chip does interrupt mitigation so you have a
decent/predictable amount of work to do in the isr. your first loop
will do that chunk of work (ie, it pulls off 50ish packets), and
then the successive looping aggressively pull one or two packets
off the rx ring. these extra loops work against the benefit that
interrupt mitigation provides.
bus space reads are slow. we should avoid doing them where possible
(but we should always do them when necessary).
doing the loop 5 times per isr works against the mclgeti semantics.
it knows a nic is busy and therefore needs more rx descriptors by
watching to see when the nic uses all of its descriptors between
interrupts. if we're aggressively pulling packets off by looping
in the isr then we're skewing this check.
ok henning@ krw@
testing by sthen@
|
|
|
|
discipline should always reflect the correct status. This fixes unexpected
state changes jordan saw.
|
|
ok miod@
|
|
Synchronization operations are expressed from the perspective of the host
RAM, e.g., a device -> memory operation is a READ and a memory -> device
operation is a WRITE.
the status block that the isr reads is written to by the device.
the chip writes to memory, it is therefore a READ.
this also adds the preread sync when the map is set up and the postread
sync when the map is torn down for better symmetry. there are probably
more issues like this in the code, but this is a start.
discovered while discussing another diff with claudio@
|
|
rather than looping over them until it runs out of work to do.
looping in the isr is bad for several reasons:
firstly, the chip does interrupt mitigation so you have a
decent/predictable amount of work to do in the isr. your first loop
will do that chunk of work (ie, it pulls off 50ish packets), and
then the successive looping aggressively pull one or two packets
off the rx ring. these extra loops work against the benefit that
interrupt mitigation provides.
bus space reads are slow. we should avoid doing them where possible
(but we should always do them when necessary).
doing the loop 5 times per isr works against the mclgeti semantics.
it knows a nic is busy and therefore needs more rx descriptors by
watching to see when the nic uses all of its descriptors between
interrupts. if we're aggressively pulling packets off by looping
in the isr then we're skewing this check.
ok deraadt@ claudio@
this is like src/sys/dev/pci/if_ix.c r1.50.
|
|
than looping over them until it runs out of work to do.
in my testing i have found that under what i consider high pps
(>160kpps) ix would loop 4 or 5 times in the interrupt handler,
where each loop does a bus_space_read and the mclgeti loop (ie, rx
dequeue followed by rx ring fill).
looping in the isr is bad for several reasons:
firstly, the chip does interrupt mitigation so you have a
decent/predictable amount of work to do in the isr. your first loop
will do that chunk of work (ie, it pulls off 50ish packets), and
then the successive looping aggressively pull one or two packets
off the rx ring. these extra loops work against the benefit that
interrupt mitigation provides.
bus space reads are slow. we should avoid doing them where possible
(but we should always do them when necessary).
doing the loop 5 times per isr works against the mclgeti semantics.
it knows a nic is busy and therefore needs more rx descriptors by
watching to see when the nic uses all of its descriptors between
interrupts. if we're aggressively pulling packets off by looping
in the isr then we're skewing this check.
ok deraadt@ claudio@
testing by phessler@ bluhm@ and me in production
|
|
|
|
|
|
some broken intel chipsets that require longer delays, we will cope with
that later hopefully.
ok kettenis
|
|
to possibly favor the mirror instead of the main ccd by incorrectly
considering the main ccd is in the failure state, for interleaved+mirrored
ccds.
ok deraadt@
|
|
Discovered, narrowed down, and tested by jmc@.
"definitely commit that" deraadt@, ok miod@
|
|
means the data size of a frame can be calculated if the dimensions
are known.
* calculate frame data sizes for uncompressed formats instead of believing
what the hardware says. the UVC spec changed between 1.0 and 1.1, and
as a result, some devices return bogus information.
* skip under-sized as well as over-sized uncompressed frames; there is
only one correct size for uncompressed frames.
* remove quirk to fix uncompressed frame sizes on certain devices,
since that now always happens.
* check that the device is actually using the parameters we think it's
using.
|
|
Pluses:
- Add support SMBus for VT82C596, VT82C596B, VT82C686A, VT8231
- Add support ACPI timer for all VIA South Bridges
ok deraadt@, tested sthen@
|
|
detach happens after the hardware is gone, so don't try to touch
the hardware in the detach path
but azalia_pci_detach is called if the device coiuld not be initialized.
in that case, shut the hardware down.
|
|
ok deraadt
|
|
|
|
is 0.
ok deraadt.
|
|
by claudio to be related to this commit) until jakemsr has time to fix it
|
|
|
|
|
|
prompted by deraadt
|
|
prodded and ok deraadt
|
|
|
|
|
|
Update to use dma_malloc for I/O blocks
ok marco@
|
|
|
|
coming soon after this revert.
ok jordan
|
|
1.32. ok marco@
|
|
ok matthew@ tedu@, also eyeballed by at least krw@ oga@ kettenis@ jsg@
|
|
ok miod@
|
|
ITExpress chipsets. (similar to 1.243, with a deja vu)
|
|
ar9380_spur_mitigate_ofdm().
|
|
|
|
- ACPI spec. says _DOD is not required for brightness controls,
- The list returned by _DOD might be wrong,
- It's an unnecessary work to do.
Instead, decision to attach will be based on the actual methods
found, similarly like in the other ACPI drivers.
Tested by several on tech@.
OK kettenis@, marco@, pirofti@.
pirofti@ asked me to note here that devices not supporting brightness
controls won't attach from now on. This shouldn't be a concern for
you, since such devices weren't doing anything at all, anyway.
|
|
|
|
ok jsing
|
|
scheduled better, ioctl paths are more reliable, and it removes NO_CCB.
ok krw@
|
|
it up by using the usb devices iSerial thing.
ok deraadt@
|
|
|
|
|
|
|
|
but for now this allows us to move forward.
|
|
the siop command buffers and add dmaable buffers for sense data.
matthew@ found that siop used to try to dma to the xs->sense bufer, which
is not guaranteed to be dma safe.
tested by matthew@ kettenis@
|
|
ok mikeb@ deraadt@
|
