Loongson display controller IP has been integrated in both Loongson
North Bridge chipset(ls7a1000 and ls7a2000) and Loongson SoCs(ls2k1000
and ls2k2000 etc), it even has been included in Loongson BMC products.
This display controller is a PCI device, it has two display pipe. For
the DC in LS7A1000 and LS2K1000 each way has a DVO output interface
which provide RGB888 signals, vertical & horizontal synchronisations,
and the pixel clock. Each CRTC is able to support 1920x1080@60Hz,
the maximum resolution is 2048x2048 according to the hardware spec.
For the DC in LS7A2000, each display pipe is equipped with a built-in
HDMI encoder which is compliant with HDMI 1.4 specification, thus it
support 3840x2160@30Hz. The first display pipe is also equipped with
a transparent vga encoder which is parallel with the HDMI encoder.
The DC in LS7A2000 is more complete, besides above feature, it has
two hardware cursors, two hardware vblank counter and two scanout
position recorders.
v1 -> v2:
1) Use hpd status reg when polling for ls7a2000
2) Fix all warnings emerged when compile with W=1
v2 -> v3:
1) Add COMPILE_TEST in Kconfig and make the driver off by default
2) Alphabetical sorting headers (Thomas)
3) Untangle register access functions as much as possible (Thomas)
4) Switch to TTM based memory manager and prefer cached mapping
for Loongson SoC (Thomas)
5) Add chip id detection method, now all models are distinguishable.
6) Revise builtin HDMI phy driver, nearly all main stream mode
below 4K@30Hz is tested, this driver supported these mode very
well including clone display mode and extend display mode.
v3 -> v4:
1) Quickly fix a small mistake.
v4 -> v5:
1) Drop potential support for Loongson 2K series SoC temporary,
this part should be resend with the DT binding patch in the future.
2) Add per display pipe debugfs support to the builtin HDMI encoder.
3) Rewrite atomic_update() for hardware cursors plane(Thomas)
4) Rewrite encoder and connector initialization part, untangle it
according to the chip(Thomas).
v5 -> v6:
1) Remove stray code which didn't get used, say lsdc_of_get_reserved_ram
2) Fix all typos I could found, make sentences and code more readable
3) Untange lsdc_hdmi*_connector_detect() function according to the pipe
4) After a serious consideration, we rename this driver as loongson.
Because we also have drivers toward the LoongGPU IP in LS7A2000 and
LS2K2000. Besides, there are also drivers about the external encoder,
HDMI audio driver and vbios support etc. This patch only provide DC
driver part, my teammate Li Yi believe that loongson will be more
suitable for loongson graphics than lsdc in the long run.
loongson.ko = LSDC + LoongGPU + encoders driver + vbios/DT ...
v6 -> v7:
1) Add prime support, self-sharing is works. sharing buffer with etnaviv
is also tested, and its works with limitation.
2) Implement buffer objects tracking with list_head.
3) S3(sleep to RAM) is tested on ls3a5000+ls7a2000 evb and it works.
4) Rewrite lsdc_bo_move, since ttm core stop allocating resources
during BO creation. Patch V1 ~ V6 of this series no longer works
on Linux 6.3.0-rc2. Thus, we send V7 to revival them.
5) Remove depends on LOONGARCH || MIPS || COMPILE_TEST and other
improvements to help review on x86 machine and add a cover letter
to help patchwork tracking my patch.
V1 ~ V4 can be found at link [1], V5 at link [2], V6 at link [3]
[1] https://patchwork.freedesktop.org/series/113566/
[2] https://patchwork.freedesktop.org/series/114386/
[3] https://patchwork.freedesktop.org/patch/524532/
suijingfeng (2):
MAINTAINERS: add maintainers for DRM LOONGSON driver
drm: add kms driver for loongson display controller
MAINTAINERS | 8 +
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/loongson/Kconfig | 15 +
drivers/gpu/drm/loongson/Makefile | 16 +
drivers/gpu/drm/loongson/lsdc_crtc.c | 384 ++++++++++++++++
drivers/gpu/drm/loongson/lsdc_debugfs.c | 261 +++++++++++
drivers/gpu/drm/loongson/lsdc_drv.c | 502 +++++++++++++++++++++
drivers/gpu/drm/loongson/lsdc_drv.h | 319 ++++++++++++++
drivers/gpu/drm/loongson/lsdc_gem.c | 291 ++++++++++++
drivers/gpu/drm/loongson/lsdc_gem.h | 26 ++
drivers/gpu/drm/loongson/lsdc_i2c.c | 172 ++++++++
drivers/gpu/drm/loongson/lsdc_irq.c | 88 ++++
drivers/gpu/drm/loongson/lsdc_irq.h | 11 +
drivers/gpu/drm/loongson/lsdc_output.c | 564 ++++++++++++++++++++++++
drivers/gpu/drm/loongson/lsdc_output.h | 14 +
drivers/gpu/drm/loongson/lsdc_plane.c | 409 +++++++++++++++++
drivers/gpu/drm/loongson/lsdc_pll.c | 338 ++++++++++++++
drivers/gpu/drm/loongson/lsdc_pll.h | 76 ++++
drivers/gpu/drm/loongson/lsdc_probe.c | 85 ++++
drivers/gpu/drm/loongson/lsdc_probe.h | 11 +
drivers/gpu/drm/loongson/lsdc_regs.h | 370 ++++++++++++++++
drivers/gpu/drm/loongson/lsdc_ttm.c | 422 ++++++++++++++++++
drivers/gpu/drm/loongson/lsdc_ttm.h | 71 +++
24 files changed, 4456 insertions(+)
create mode 100644 drivers/gpu/drm/loongson/Kconfig
create mode 100644 drivers/gpu/drm/loongson/Makefile
create mode 100644 drivers/gpu/drm/loongson/lsdc_crtc.c
create mode 100644 drivers/gpu/drm/loongson/lsdc_debugfs.c
create mode 100644 drivers/gpu/drm/loongson/lsdc_drv.c
create mode 100644 drivers/gpu/drm/loongson/lsdc_drv.h
create mode 100644 drivers/gpu/drm/loongson/lsdc_gem.c
create mode 100644 drivers/gpu/drm/loongson/lsdc_gem.h
create mode 100644 drivers/gpu/drm/loongson/lsdc_i2c.c
create mode 100644 drivers/gpu/drm/loongson/lsdc_irq.c
create mode 100644 drivers/gpu/drm/loongson/lsdc_irq.h
create mode 100644 drivers/gpu/drm/loongson/lsdc_output.c
create mode 100644 drivers/gpu/drm/loongson/lsdc_output.h
create mode 100644 drivers/gpu/drm/loongson/lsdc_plane.c
create mode 100644 drivers/gpu/drm/loongson/lsdc_pll.c
create mode 100644 drivers/gpu/drm/loongson/lsdc_pll.h
create mode 100644 drivers/gpu/drm/loongson/lsdc_probe.c
create mode 100644 drivers/gpu/drm/loongson/lsdc_probe.h
create mode 100644 drivers/gpu/drm/loongson/lsdc_regs.h
create mode 100644 drivers/gpu/drm/loongson/lsdc_ttm.c
create mode 100644 drivers/gpu/drm/loongson/lsdc_ttm.h
--
2.25.1
Hi,
This small patchset adds three new IOCTLs that can be used to attach,
detach, or transfer from/to a DMABUF object.
This was surprisingly easy to add, as the functionfs code only uses
scatterlists for transfers and allows specifying the number of bytes to
transfer. The bulk of the code is then for general DMABUF accounting.
The patchset isn't tagged RFC but comments are very welcome, there are
some things I am not 100% sure about: ffs_dma_resv_lock (with no
ww_acquire_ctx), and I'm using pr_debug which feels wrong. Also, I
should probably add documentation? The current IOCTLs for functionfs
were not documented, as far as I can tell.
We use it with DMABUFs created with udmabuf, that we attach to the
functionfs interface and to IIO devices (with a DMABUF interface for
IIO, on its way to upstream too), to transfer samples from high-speed
transceivers to USB in a zero-copy fashion.
Cheers,
-Paul
Paul Cercueil (2):
usb: gadget: Support already-mapped DMA SGs
usb: gadget: functionfs: Add DMABUF import interface
drivers/usb/gadget/function/f_fs.c | 398 ++++++++++++++++++++++++++++
drivers/usb/gadget/udc/core.c | 7 +-
include/linux/usb/gadget.h | 2 +
include/uapi/linux/usb/functionfs.h | 14 +-
4 files changed, 419 insertions(+), 2 deletions(-)
--
2.39.2
'bulk' description taken from another in the same file.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_bo.c:98: warning: Function parameter or member 'bulk' not described in 'ttm_bo_set_bulk_move'
drivers/gpu/drm/ttm/ttm_bo.c:768: warning: Function parameter or member 'placement' not described in 'ttm_bo_mem_space'
drivers/gpu/drm/ttm/ttm_bo.c:768: warning: Excess function parameter 'proposed_placement' description in 'ttm_bo_mem_space'
Cc: Christian Koenig <christian.koenig(a)amd.com>
Cc: Huang Rui <ray.huang(a)amd.com>
Cc: David Airlie <airlied(a)gmail.com>
Cc: Daniel Vetter <daniel(a)ffwll.ch>
Cc: Sumit Semwal <sumit.semwal(a)linaro.org>
Cc: dri-devel(a)lists.freedesktop.org
Cc: linux-media(a)vger.kernel.org
Cc: linaro-mm-sig(a)lists.linaro.org
Signed-off-by: Lee Jones <lee(a)kernel.org>
---
drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 459f1b4440daa..d056d28f8758a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -84,6 +84,7 @@ EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
* ttm_bo_set_bulk_move - update BOs bulk move object
*
* @bo: The buffer object.
+ * @bulk: bulk move structure
*
* Update the BOs bulk move object, making sure that resources are added/removed
* as well. A bulk move allows to move many resource on the LRU at once,
@@ -748,7 +749,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
*
* @bo: Pointer to a struct ttm_buffer_object. the data of which
* we want to allocate space for.
- * @proposed_placement: Proposed new placement for the buffer object.
+ * @placement: Proposed new placement for the buffer object.
* @mem: A struct ttm_resource.
* @ctx: if and how to sleep, lock buffers and alloc memory
*
--
2.40.0.rc1.284.g88254d51c5-goog
From: Rob Clark <robdclark(a)chromium.org>
Inspired by https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vetter@ff…
it seemed like a good idea to get rid of memory allocation in job_run()
by embedding the hw dma_fence in the job/submit struct.
Applies on top of https://patchwork.freedesktop.org/series/93035/ but I
can re-work it to swap the order. I think the first patch would be
useful to amdgpu and perhaps anyone else embedding the hw_fence in the
struct containing drm_sched_job.
Rob Clark (2):
dma-buf/dma-fence: Add dma_fence_init_noref()
drm/msm: Embed the hw_fence in msm_gem_submit
drivers/dma-buf/dma-fence.c | 43 +++++++++++++++++++-------
drivers/gpu/drm/msm/msm_fence.c | 45 +++++++++++-----------------
drivers/gpu/drm/msm/msm_fence.h | 2 +-
drivers/gpu/drm/msm/msm_gem.h | 10 +++----
drivers/gpu/drm/msm/msm_gem_submit.c | 8 ++---
drivers/gpu/drm/msm/msm_gpu.c | 4 +--
drivers/gpu/drm/msm/msm_ringbuffer.c | 4 +--
include/linux/dma-fence.h | 2 ++
8 files changed, 66 insertions(+), 52 deletions(-)
--
2.39.2
From: Rob Clark <robdclark(a)chromium.org>
Inspired by https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vetter@ff…
it seemed like a good idea to get rid of memory allocation in job_run()
and use lockdep annotations to yell at us about anything that could
deadlock against shrinker/reclaim. Anything that can trigger reclaim,
or block on any other thread that has triggered reclaim, can block the
GPU shrinker from releasing memory if it is waiting the job to complete,
causing deadlock.
The first two patches avoid memory allocation for the hw_fence by
embedding it in the already allocated submit object. The next three
decouple various allocations that were done in the hw_init path, but
only the first time, to let lockdep see that they won't happen in the
job_run() path. (The hw_init() path re-initializes the GPU after runpm
resume, etc, which can happen in the job_run() path.)
The remaining patches clean up locking issues in various corners of PM
and interconnect which happen in the runpm path. These fixes can be
picked up independently by the various maintainers. In all cases I've
added lockdep annotations to help keep the runpm resume path deadlock-
free vs reclaim, but I've broken those out into their own patches.. it
is possible that these might find issues in other code-paths not hit on
the hw I have. (It is a bit tricky because of locks held across call-
backs, such as devfreq->lock held across devfreq_dev_profile callbacks.
I've audited these and other callbacks in icc, etc, to look for problems
and fixed one I found in smd-rpm. But that took me through a number of
drivers and subsystems that I am not familiar with so it is entirely
possible that I overlooked some problematic allocations.)
There is one remaining issue to resolve before we can enable the job_run
annotations, but it is entirely self contained in drm/msm/gem. So it
should not block review of these patches. So I figured it best to send
out what I have so far.
Rob Clark (13):
dma-buf/dma-fence: Add dma_fence_init_noref()
drm/msm: Embed the hw_fence in msm_gem_submit
drm/msm/gpu: Move fw loading out of hw_init() path
drm/msm/gpu: Move BO allocation out of hw_init
drm/msm/a6xx: Move ioremap out of hw_init path
PM / devfreq: Drop unneed locking to appease lockdep
PM / devfreq: Teach lockdep about locking order
PM / QoS: Fix constraints alloc vs reclaim locking
PM / QoS: Decouple request alloc from dev_pm_qos_mtx
PM / QoS: Teach lockdep about dev_pm_qos_mtx locking order
soc: qcom: smd-rpm: Use GFP_ATOMIC in write path
interconnect: Fix locking for runpm vs reclaim
interconnect: Teach lockdep about icc_bw_lock order
drivers/base/power/qos.c | 83 ++++++++++++++++------
drivers/devfreq/devfreq.c | 52 +++++++-------
drivers/dma-buf/dma-fence.c | 43 ++++++++---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 48 ++++++-------
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 18 +++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 46 ++++++------
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 9 +--
drivers/gpu/drm/msm/msm_fence.c | 43 +++++------
drivers/gpu/drm/msm/msm_fence.h | 2 +-
drivers/gpu/drm/msm/msm_gem.h | 10 +--
drivers/gpu/drm/msm/msm_gem_submit.c | 8 +--
drivers/gpu/drm/msm/msm_gpu.c | 4 +-
drivers/gpu/drm/msm/msm_gpu.h | 6 ++
drivers/gpu/drm/msm/msm_ringbuffer.c | 4 +-
drivers/interconnect/core.c | 18 ++++-
drivers/soc/qcom/smd-rpm.c | 2 +-
include/linux/dma-fence.h | 2 +
18 files changed, 237 insertions(+), 167 deletions(-)
--
2.39.2