- 09 Jun, 2014 5 commits
-
-
Thierry Reding authored
The number of HBLANK and VBLANK symbols can be computed at runtime so that they can be set appropriately depending on the video mode and DP link. These values are used by the packet generation logic to determine how many audio samples can be transferred during the blanking intervals. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The currently hardcoded link parameters don't work on all eDP panels, so compute the parameters at runtime depending on the mode and panel type to allow the driver to cope with a wider variety of panels. Note that the number of bits per pixel of the panel is still hardcoded, but this can be addressed in a separate patch. This is largely based on a patch by Stéphane Marchesin but the algorithm was largely rewritten to be more readable and concise. Signed-off-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Stéphane Marchesin authored
Lanes are powered up in decreasing order. Power them down in increasing order for consistency. Signed-off-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Stéphane Marchesin authored
The comment above mentions link A/B but this isn't what the code does, so let's fix that. Signed-off-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Stéphane Marchesin authored
The code currently rounds up the clock to the next MHZ, which is rounding up a 69.5MHz clock to 70MHz on my machine. This in turn prevents the display from syncing. Removing this rounding fixes eDP for me. Signed-off-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
- 06 Jun, 2014 2 commits
-
-
Thierry Reding authored
Other output drivers set up debugfs slightly differently. Bring the SOR driver in line with those for consistency. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Removing only the root directory will fail when there are still files in it. Instead of manually removing all files, remove the whole directory recursively. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
- 05 Jun, 2014 33 commits
-
-
Thierry Reding authored
Doing so allows the hotplug events generated by the connector to be properly handled by the DRM poll helpers. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Calling the drm_helper_hpd_irq_event() helper can sleep, so instead of invoking it directly from the interrupt handler, schedule a work queue and run it from there. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Enable hardware cursor support on Tegra124. Earlier generations support the hardware cursor to some degree as well, but not in a way that can be generically exposed. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The DRM core can now cope with drivers that don't have an associated struct drm_bus, so the host1x implementation is no longer useful. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
With the recent addition of the drm_set_unique() function, devices can now be registered without requiring a drm_bus. Add a brief description to the DRM docbook to show how that can be achieved. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Describe how devices are registered using the drm_*_init() functions. Adding this to docbook requires a largish set of changes to the comments in drm_{pci,usb,platform}.c since they are doxygen-style rather than proper kernel-doc and therefore mess with the docbook generation. While at it, mark usage of drm_put_dev() as discouraged in favour of calling drm_dev_unregister() and drm_dev_unref() directly. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Add a helper function that allows drivers to statically set the unique name of the device. This will allow platform and USB drivers to get rid of their DRM bus implementations and directly use drm_dev_alloc() and drm_dev_register(). Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The internal host1x_{,un}register_client() functions can potentially be confused with public the host1x_client_{,un}register() functions. Rename them to host1x_{add,del}_client() to remove some of the possible confusion. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The function is never used outside of the source file and therefore can be locally scoped. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Tegra124 is mostly backwards-compatible with Tegra114. However, Tegra124 supports a few more features (e.g. interlacing, ...). Introduce a new compatible string and TMDS tables to cope with these differences. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Accessing the CRC debugfs file will hang the system if the SOR is not enabled, so make sure that it is stays enabled until the CRC has been read. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
In some cases the pixel clock used to not be correct, which is why it had to be recomputed. It turns out that the reason why it wasn't correct is that it was used wrongly. If used correctly there's not need for the recomputation. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The shift clock divider is highly dependent on the type of output, so push computation of it down into the output drivers. The old code used to work merely by accident. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Program the shift clock divider in tegra_crtc_setup_clk() since that's where the divider is computed, so passing it around can be avoided. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Assert the DSI controller's reset when the driver is unloaded to reduce power consumption and to put the controller into a known state for subsequent driver reloads. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
When disabling the DSI controller, the code wasn't really doing what it was supposed to. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
To prevent the enable or disable operations to potentially be run multiple times, add guards to return early when the output is already in the targetted state. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The packet sequencer needs to be programmed depending on the video mode of the attached peripheral. Add support for non-burst video modes with sync events (as opposed to sync pulses) and select either sequence depending on the video mode. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The DSI controllers are powered by a (typically 1.2V) regulator. Usually this is always on, so there was no need to support enabling or disabling it thus far. But in order not to consume any power when DSI is inactive, give the driver a chance to enable or disable the supply as needed. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
A bunch of registers are initialized to 0 upon during driver probe. It turns out that none of these are actually needed, so they can simply be dropped. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The pixel format enumeration values used by the Tegra DSI controller don't match those defined by the DSI framework. Make sure to convert them to the internal format before writing it to the register. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
For some reason when the PW*_ENABLE and PM*_ENABLE fields are cleared during disable, the HDMI output stops working properly. Resetting and initializing doesn't help. Comment out those accesses for now until it has been determined what to do about them. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Disable LVDS mode according to register documentation. It seems like this has no effect on the operation of HDMI, but it's probably a good idea to do this anyway. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
This reflects the power-up sequence as described in the documentation, but it doesn't seem to be strictly necessary to get HDMI to work. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Clocks are never enabled or disabled in atomic context, so we can use the clk_prepare_enable() and clk_disable_unprepare() helpers instead. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Schematics indicate that the AVDD_HDMI_PLL supply should be enabled prior to the AVDD_HDMI supply. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The generic Tegra output code already sets up the clocks properly, so there's no need to do it again when the HDMI output is enabled. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Revert commit 18ebc0f4 "drm/tegra: hdmi: Enable VDD earlier for hotplug/DDC" and instead add a new supply for the +5V pin on the HDMI connector. The vdd-supply property refers to the regulator that supplies the AVDD_HDMI input on Tegra, rather than the +5V HDMI connector pin. This was never a problem before, because all boards had that pin hooked up to a regulator that was always on. Starting with Dalmore and continuing with Venice2, the +5V pin is controllable via a GPIO. For reasons unknown, the GPIO ended up as the controlling GPIO of the AVDD_HDMI supply in the Dalmore and Venice2 DTS files. But that's not correct. Instead, a separate supply must be introduced so that the +5V pin can be controlled separately from the supplies that feed the HDMI block within Tegra. A new hdmi-supply property is introduced that takes the place of the vdd-supply and vdd-supply is only enabled when HDMI is enabled rather than all the time. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
For HDMI compliance both of these values need to be set to 1. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Setting the bits in this register is dependent on the output type driven by the display controller. All output drivers already set these properly so there is no need to do it here again. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The tegra_dc_format() and tegra_dc_setup_window() functions are only used internally by the display controller driver. Move them upwards in order to make them static and get rid of the function prototypes. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
V_DIRECTION is the name of the field in the documentation, so use that for consistency. Also add the H_DIRECTION field for completeness. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The SOR allows the computation of a 32 bit CRC of the content that it transmits. This functionality is exposed via debugfs and is useful to verify proper operation of the SOR. Signed-off-by: Thierry Reding <treding@nvidia.com>
-