aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2017-03-10drm: bridge: dw-hdmi: Switch to regmap for register accessNeil Armstrong2-51/+59
The Synopsys Designware HDMI TX Controller does not enforce register access on platforms instanciating it. The current driver supports two different types of memory-mapped flat register access, but in order to support the Amlogic Meson SoCs integration, and provide a more generic way to handle all sorts of register mapping, switch the register access to use the regmap infrastructure. In the case of registers that are not flat memory-mapped or do not conform to the current driver implementation, a regmap struct can be given in the plat_data and be used at probe or bind. Since the AHB audio driver is only available with direct memory access, only allow the I2S audio driver to be registered is directly memory-mapped. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-10-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Remove device type from platform dataKieran Bingham4-12/+0
The device type isn't used anymore now that workarounds and PHY-specific operations are performed based on version information read at runtime. Remove it. Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-9-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Add support for custom PHY configurationKieran Bingham2-35/+81
The DWC HDMI TX controller interfaces with a companion PHY. While Synopsys provides multiple standard PHYs, SoC vendors can also integrate a custom PHY. Modularize PHY configuration to support vendor PHYs through platform data. The existing PHY configuration code was originally written to support the DWC HDMI 3D TX PHY, and seems to be compatible with the DWC MLP PHY. The HDMI 2.0 PHY will require a separate configuration function. Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-8-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Create PHY operationsLaurent Pinchart2-31/+82
The HDMI TX controller support different PHYs whose programming interface can vary significantly, especially with vendor PHYs that are not provided by Synopsys. To support them, create a PHY operation structure that can be provided by the platform glue layer. The existing PHY handling code (limited to Synopsys PHY support) is refactored into a set of default PHY operations that are used automatically when the platform glue doesn't provide its own operations. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170305233615.11993-1-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Fix the PHY power up sequenceLaurent Pinchart1-28/+37
When powering the PHY up we need to wait for the PLL to lock. This is done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register (interrupt-based wait could be implemented as well but is likely overkill). The bit is asserted when the PLL locks, but the current code incorrectly waits for the bit to be deasserted. Fix it, and while at it, replace the udelay() with a sleep as the code never runs in non-sleepable context. To be consistent with the power down implementation move the poll loop to the power off function. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170305233557.11945-1-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Fix the PHY power down sequenceLaurent Pinchart1-9/+43
The PHY requires us to wait for the PHY to switch to low power mode after deasserting TXPWRON and before asserting PDDQ in the power down sequence, otherwise power down will fail. The PHY power down can be monitored though the TX_READY bit, available through I2C in the PHY registers, or the TX_PHY_LOCK bit, available through the HDMI TX registers. As the two are equivalent, let's pick the easier solution of polling the TX_PHY_LOCK bit. The power down code is currently duplicated in multiple places. To avoid spreading multiple calls to a TX_PHY_LOCK poll function, we have to refactor the power down code and group it all in a single function. Tests showed that one poll iteration was enough for TX_PHY_LOCK to become low, without requiring any additional delay. Retrying the read five times with a 1ms to 2ms delay between each attempt should thus be more than enough. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170305233539.11898-1-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Enable CSC even for DVINeil Armstrong1-2/+2
If the input pixel format is not RGB, the CSC must be enabled in order to provide valid pixel to DVI sinks. This patch removes the hdmi only dependency on the CSC enabling. Reviewed-by: Jose Abreu <joabreu@synopsys.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-4-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Move CSC configuration out of PHY codeLaurent Pinchart1-15/+10
The color space converter isn't part of the PHY, move its configuration out of PHY code. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-3-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Remove unused functionsLaurent Pinchart1-26/+0
Most of the hdmi_phy_test_*() functions are unused. Remove them. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Tested-by: Nickey Yang <nickey.yang@rock-chips.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-2-laurent.pinchart+renesas@ideasonboard.com
2017-03-09drm: Extract drm_file.hDaniel Vetter4-127/+178
I'm torn on whether drm_minor really should be here or somewhere else. Maybe with more clarity after untangling drmP.h more this is easier to decide, for now I've put a FIXME comment right next to it. Right now we need struct drm_minor for the inline drm_file type helpers, and so it does kinda make sense to have them here. Next patch will kerneldoc-ify the entire pile. Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-10-daniel.vetter@ffwll.ch
2017-03-09drm: Remove DRM_MINOR_CNTDaniel Vetter1-1/+0
This was originally added by David Herrmann for range checks, but entirely unused. It confused me, so let's remove it. Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-9-daniel.vetter@ffwll.ch
2017-03-09drm: rename drm_fops.c to drm_file.cDaniel Vetter5-8/+5
It's not just file ops, but drm_file stuff in general. This is prep work to extracting a drm_file.h header in the next patch. Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-8-daniel.vetter@ffwll.ch
2017-03-09drm/doc: document fallback behaviour for atomic eventsDaniel Vetter1-0/+6
Worst case if the hw can't support completion signalling in a race-free way we want the event to be too late, not too early. Text adapted from a proposal from Laurent - the other side of how to make hw work correctly where it's possible is imo already sufficiently documented. v2: Review from Laurent. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-7-daniel.vetter@ffwll.ch
2017-03-09drm: Remove drmP.h include from drm_kms_helper_common.cDaniel Vetter1-2/+1
An easy one as a drive-by. Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-6-daniel.vetter@ffwll.ch
2017-03-09drm: Extract drm_pci.hDaniel Vetter3-39/+89
Just another step in finally making drmP.h obsolete. Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-5-daniel.vetter@ffwll.ch
2017-03-09drm: Move drm_lock_data out of drmP.hDaniel Vetter2-15/+17
And remove the semi-kernel-doc stuff, to make sure no one uses this. Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-4-daniel.vetter@ffwll.ch
2017-03-09drm: Extract drm_prime.hDaniel Vetter6-31/+91
Plus a little bit more documentation. v2: Untangle the missing forward decls to make drm_prime|gem.h free-standing. Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-3-daniel.vetter@ffwll.ch
2017-03-09drm/doc: Add todo about connector_list_iterDaniel Vetter1-0/+13
At least radeon, amdgpu and nouveau should be converted. We have patches for i915 already. v2: Spelling (Sean). Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-2-daniel.vetter@ffwll.ch
2017-03-09drm/qxl: Remove qxl_debugfs_remove_files()Noralf Trønnes3-15/+0
drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so it's not necessary to call drm_debugfs_remove_files(). Cc: airlied@linux.ie Cc: kraxel@redhat.com Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170307204924.1002-4-noralf@tronnes.org [ kraxel: solved conflict ] Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-03-08drm/debugfs: Remove the drm_driver.debugfs_cleanup callbackNoralf Trønnes2-6/+0
Remove the .debugfs_cleanup() callback now that all the users are gone. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170307204924.1002-3-noralf@tronnes.org
2017-03-08drm/msm: Remove msm_debugfs_cleanup()Noralf Trønnes7-26/+9
Move the contents of msm_debugfs_cleanup() to msm_drm_uninit() to free up the drm_driver->debugfs_cleanup callback. Also remove the mdp_kms_funcs->debugfs_cleanup callback which has no users. Cc: robdclark@gmail.com Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170307204924.1002-2-noralf@tronnes.org
2017-03-07drm/dp: Add missing description to parameterTomeu Vizoso1-0/+1
Gabriel Krisman reported these warnings when building the documentation: ./drivers/gpu/drm/drm_dp_helper.c:1165: warning: No description found for parameter 'crtc' ./drivers/gpu/drm/drm_dp_helper.c:1166: warning: No description found for parameter 'crtc' Reported-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170307203511.14258-1-tomeu.vizoso@collabora.com
2017-03-07drm/nouveau/fb/gf100-: rework ram detectionBen Skeggs8-101/+179
This commit reworks the RAM detection algorithm, using RAM-per-LTC to determine whether a board has a mixed-memory configuration instead of using RAM-per-FBPA. I'm not certain the algorithm is perfect, but it should handle all currently known configurations in the very least. This should fix GTX 970 boards with 4GiB of RAM where the last 512MiB isn't fully accessible, as well as only detecting half the VRAM on GF108 boards. As a nice side-effect, GP10x memory detection now reuses the majority of the code from earlier chipsets. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/fb/gm200: split ram implementation from gm107Ben Skeggs4-1/+44
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/fb/gf108: split implementation from gf100Ben Skeggs6-1/+87
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/fb/gf100-: modify constructors to allow more customisationBen Skeggs4-52/+81
GF108/GM107 implementations will want slightly different functions for the upcoming RAM detection improvements. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithmBen Skeggs1-2/+3
I'm not entirely sure NVKM needs to support this now, but I haven't removed it as of yet just in case it's needed from DEVINIT scripts where DRM isn't available. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/i2c/g94-: return REPLY_M value on readsBen Skeggs2-0/+2
This value represents the actual number of bytes recieved on the AUX channel as the result of a read transaction. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/i2c: modify aux interface to return length actually transferredBen Skeggs7-26/+29
Apparently sinks are allows to respond with ACK even if they didn't fully complete a transaction... It seems like a missed opportunity for DEFER to me, but what do I know :) Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/gp10x: enable secboot and GRAlexandre Courbot1-0/+15
All the bricks are in place for secure boot to be enabled. This in turn makes GR usable so enable them all. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/gr/gp102: initial supportBen Skeggs9-4/+183
Differences from GP100: - 3 PPCs/GPC. - Another random reg to calculate/write. - Attrib CB setup a little different. - PascalB - PascalComputeB Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/falcon: support for gp10x msgqueueAlexandre Courbot4-0/+268
Add support for the msgqueue firmware used to process SEC2 commands for gp10x chips. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: add gp102/gp104/gp106/gp107 supportAlexandre Courbot3-0/+253
These gp10x chips are supporting using (roughly) the same firmware. Compared to previous secure chips, ACR runs on SEC2 and so does the low-secure msgqueue. ACR for these chips is based on r367. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: put HS code loading code into own fileAlexandre Courbot5-124/+182
We will also need to load HS blobs outside of acr_r352 (for instance, to run the NVDEC VPR scrubber), so make this code reusable. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: support for r375 ACRAlexandre Courbot3-0/+167
r375 ACR uses a unified bootloader descriptor for the GR and PMU firmwares. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: support for r367 ACRAlexandre Courbot4-0/+425
r367 uses a different hsflcn_desc layout and LS firmware signature format, requiring a rewrite of some functions. It also makes use of the shadow region, and uses SEC as the boot falcon. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: support for r364 ACRAlexandre Courbot3-0/+119
r364 is similar to r361, but uses a different hsflcn_desc structure to introduce the shadow region address (even though it is not yet used by this version). Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: workaround bug when starting SEC2 firmwareAlexandre Courbot1-0/+33
For some unknown reason the LS SEC2 firmware needs to be started twice to operate. Detect and address that condition. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: support standard NVIDIA HS binariesAlexandre Courbot1-8/+52
I had the brilliant idea to "improve" the binary format by removing a useless indirection in the HS binary files. In the end it just makes things more complicated than they ought to be as NVIDIA-provided files need to be adapted. Since the format used can be identified by the header, support both. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: support for unload blob bootloaderAlexandre Courbot2-30/+37
If the load and unload falcons are different, then a different bootloader must also be used. Support this case. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: let callers interpret return value of blobsAlexandre Courbot2-12/+21
Since the HS blobs are provided and signed by NVIDIA, we cannot expect always-consistent behavior. In this case, on GP10x the unload blob may return 0x1d even though things have run perfectly well. This behavior has been confirmed by NVIDIA. So let the callers of the run_blob() hook receive the blob return's value (a positive integer) and decide what it means. This allows us to workaround the 0x1d code instead of issuing an error. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: support for different load and unload falconsAlexandre Courbot7-14/+18
On some secure boot instances (e.g. gp10x) the load and unload blobs do not run on the same falcon. Support this case by introducing a new member to the ACR structure and making related functions take the falcon to use as an argument instead of assuming the boot falcon is to be used. The rule is that the load blob can be run on either the SEC or PMU falcons, but the unload blob must be always run on PMU. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: share r361 BL structures and functionsAlexandre Courbot2-39/+74
Share elements of r361 that will be reused in other ACRs. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: add support for SEC LS firmwareAlexandre Courbot4-0/+77
Support running a message queue firmware on SEC. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: support running ACR on SECAlexandre Courbot3-4/+25
Add support for running the ACR binary on the SEC falcon. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: get start address of blob from ACRAlexandre Courbot3-10/+9
The start address used for secure blobs is not unique to the ACR, but rather blob-dependent. Remove the unique member stored in the ACR structure and make the load function return the start address for the current blob instead. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: add shadow blob argumentAlexandre Courbot2-2/+15
ACR firmware from r364 on need a shadow region for the ACR to copy the WPR region into. Add a flag to indicate that a shadow region is required and manage memory allocations accordingly. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/falcon/msgqueue: add SEC2 supportAlexandre Courbot1-0/+3
Add support for running a msgqueue on the SEC2 falcon. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/falcon: support for EMEMAlexandre Courbot3-0/+65
On SEC, DMEM is unaccessible by the CPU when the falcon is running in LS mode. This makes communication with the firmware using DMEM impossible. For this purpose, a new kind of memory (EMEM) has been added. It works similarly to DMEM, with the difference that its address space starts at 0x1000000. For this reason, it makes sense to treat it like a special case of DMEM. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/falcon: fix base address of FBIF registersAlexandre Courbot1-5/+20
All falcons have their FBIF registers starting at offset 0x600, with the exception of the PMU and NVENC engines. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.