| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
display rework fixes lots of displayport issues.
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (43 commits)
drm/nouveau/disp/dp: fix tmds passthrough on dp connector
drm/nouveau/dp: probe dpcd to determine connectedness
drm/nv50-: trigger update after all connectors disabled
drm/nv50-: prepare for attaching a SOR to multiple heads
drm/gf119-/disp: fix debug output on update failure
drm/nouveau/disp/dp: make use of postcursor when its available
drm/g94-/disp/dp: take max pullup value across all lanes
drm/nouveau/bios/dp: parse lane postcursor data
drm/nouveau/dp: fix support for dpms
drm/nouveau: register a drm_dp_aux channel for each dp connector
drm/g94-/disp: add method to power-off dp lanes
drm/nouveau/disp/dp: maintain link in response to hpd signal
drm/g94-/disp: bash and wait for something after changing lane power regs
drm/nouveau/disp/dp: split link config/power into two steps
drm/nv50/disp: train PIOR-attached DP from second supervisor
drm/nouveau/disp/dp: make use of existing output data for link training
drm/gf119/disp: start removing direct vbios parsing from supervisor
drm/nv50/disp: start removing direct vbios parsing from supervisor
drm/nouveau/disp/dp: maintain receiver caps in response to hpd signal
drm/nouveau/disp/dp: create subclass for dp outputs
...
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
We were sending the necessary state changes to unset the mode, but
never actually hit the big GO button unless another modeset happens
afterwards.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| |
| |
| | |
And at the same time, obey the spec better wrt out-of-range requests.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
SOR_PWR has no effect to power-off DP links, unlike other SOR protocols.
Instead, on the source side, we cut power to the lanes after having put
the sink into D3. Link training takes care of everything required to
bring it back again.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This previously worked for the most part due to userspace doing a
modeset in response to HPD interrupts. This will allow us to
properly handle cases where sync is lost for other reasons, or if
userspace isn't caring.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| |
| |
| | |
Some kind of update? Needed to make the power-down take effect at least.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| |
| |
| | |
We want to be able to power down the lanes for DPMS off.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| |
| |
| | |
Same place as for SOR, between detach and attach phases.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This will, at some point, be used to replace various bits and pieces of
code doing direct bios parsing. For now, it'll just be used for some
DP improvements.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There's also provisions to allow a pad to be locked with a specific
routing, for an indefinite period of time. This will be used in
future patches.
The G94+ pad driver will now also power-down pads when not required.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was a half-finished hack before, just enough to handle the shared
aux/i2c pad thing on G94 and up.
We got lucky with locking etc up until now, as this was (generally) all
protected by the DRM mode_config lock. It's about to become a lot more
likely to hit the races.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| |
| |
| |
| | |
Re-uses the implementation's accessor functions rather than requiring
and init/fini implementation for each chipset.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| |
| |
| | |
We really want this for, at least, MST devices.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| |
| |
| |
| | |
Not enabled at the backends yet, but will read status and send back max
reached at level 0.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
into drm-next
Destage IPUv3
* 'topic/ipu-destaging' of git://git.pengutronix.de/git/pza/linux:
gpu: ipu-v3: Register the CSI modules
gpu: ipu-v3: Add CSI and SMFC module enable wrappers
gpu: ipu-v3: Add ipu_idmac_get_current_buffer function
gpu: ipu-v3: Add SMFC code
gpu: ipu-v3: Move i.MX IPUv3 core driver out of staging
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch registers the two CSI platform devices per IPU.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
IPU_CONF_..._EN bits are implementation details, not to be made public.
Add wrappers around ipu_module_enable/disable, so the CSI V4L2 driver
can enable/disable the CSI and SMFC modules.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This function returns the currently active buffer (0 or 1)
of a double buffered IDMAC channel. It is to be used by the
CSI driver.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The Sensor Multi Fifo Controller (SMFC) is used as a buffer between
the two CSIs (writing simultaneously) and up to four IDMAC channels.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The i.MX Image Processing Unit (IPU) contains a number of image processing
blocks that sit right in the middle between DRM and V4L2. Some of the modules,
such as Display Controller, Processor, and Interface (DC, DP, DI) or CMOS
Sensor Interface (CSI) and their FIFOs could be assigned to either framework,
but others, such as the dma controller (IDMAC) and image converter (IC) can
be used by both.
The IPUv3 core driver provides an internal API to access the modules, to be
used by both DRM and V4L2 IPUv3 drivers.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|